Eine Heartbeat-Prüfung löst aus, wenn sich ein Prozess nicht mehr meldet. Ist ihr Timeout zu kurz, wird jedes verspätete Paket und jeder Deploy zum Fehlalarm; ist er zu lang, erfahren Sie eine Stunde zu spät von einem Ausfall. Geben Sie Ihr Setup ein und erhalten Sie einen Timeout, der normales Rauschen toleriert — und sehen Sie, wie schnell ein echter Ausfall erkannt würde.
Das Modell ist bewusst einfach, damit Sie es von Hand nachprüfen können:
Für Hangfire sendet der QueueHawk-Agent alle 30 Sekunden einen Heartbeat pro Hangfire-Server (HeartbeatIntervalSeconds). Jede neue Application bekommt eine Heartbeat-Regel mit 90 Sekunden Timeout, ausgewertet etwa einmal pro Minute, und die Regel betrachtet die Application als Ganzes — sie löst nur aus, wenn kein Server dieser Application mehr sendet, Rolling Deploys lösen sie also nicht aus. Beide Werte lassen sich pro Application ändern. Mehr zur Idee dahinter unter Das Ausbleiben eines Signals überwachen.
Ein üblicher Startwert ist das Dreifache des Heartbeat-Intervalls plus ein kleiner Puffer — bei einem 30-Sekunden-Heartbeat also etwa 90 bis 100 Sekunden. Damit dürfen zwei Heartbeats ausbleiben, ohne Fehlalarm, und ein echter Ausfall wird trotzdem innerhalb weniger Minuten erkannt.
Weil Heartbeats nie ganz pünktlich sind. Netzwerkverzögerungen, Garbage-Collection-Pausen und Batching lassen manche ein paar Sekunden zu spät ankommen; mit einem Timeout gleich dem Intervall wird jeder verspätete Heartbeat zum Alarm — und das Team lernt schnell, sie zu ignorieren.
Stoppt ein Deploy die einzige Instanz, bevor die neue startet, entsteht eine Lücke ohne Heartbeats. Entweder den Timeout länger als diese Lücke wählen oder mit mehreren Replicas und Rolling Updates deployen, sodass immer mindestens eine Instanz Heartbeats sendet — und Heartbeats pro Anwendung bewerten, nicht pro Server.
Bewertet pro Application, nicht pro Server. Kostenlos für eine Application.