Re: [Python-de] Unittests vs Monitoring-Checks
Moin, Marcel Hellkamp schrieb:
On 06/23/2017 10:31 AM, Thomas Güttler wrote:
Meinst du, dass die Health-Checks getestet werden wie alle anderen Code-Bereiche auch?
Richtig. Sie sind Teil der API eines Dienstes und werden genau so entwickelt und getestet wie alle anderen Kernfunktionen auch.
Falls der Health-Check auch die Erreichbarkeit benötigter Dienste (Datenbanken, Queues, andere REST-Schnittstellen, ...) prüft, ist es sehr ratsam auch zu testen, ob der wirklich auf "rot" geht, wenn der Dienst nicht da ist. Das klingt so banal, aber nichts ist - insbesondere wenn Automatismen wie Restarts oder Alarme dran hängen - schlechter als nicht funktionierende Checks... Das geht ja fließend über in das Thema Resilienz/Robustheit der Anwendung: Erholt die sich z.B. davon, wenn die DB mal kurz nicht da war? Man muss ja nicht gleich größere Geschütze wie Pumba[0] oder die Simian Army[1] nehmen. Einfach mal Container/Prozesse killen und gucken was passiert. Aus dem gleichen Grund sollte man seine Checks so stricken, das die auch anschlagen, wenn die Überwachung selbst in einen Timeout läuft. Wenn irgendwas gar nicht läuft, bekommt man das schnell mit. Aber nichts ist fieser als Dienste die Antworten "verschlucken" oder nur sporadisch langsam antworten. Apropos benötigte Dienste: Kubernetes unterscheidet aktiv (liveness) und einsatzbereit (readyness). Letzteres kann genutzt werden, um zu schauen ob auch alles da ist was die Anwendung braucht. Die Unterscheidung wird eben relevant, wenn ich das automatisiert interpretieren möchte. Restarts der Applikation helfen zur Wiederherstellung des Betriebs nix, wenn die ein Problem hat, weil sie ihr Backend nicht erreicht.
Nimmst du ein Framework, oder sind es einfache Scripte die in Nagios-typischer Weise 0, 1, 2 oder 3 zurückliefern?
Bei einem REST-Service würde man z.B. eine "/api/health" Ressource implementieren, die json zurück gibt.
Noch was banales, das gerne vergessen wird: Genau wie bei einer guten REST-API sollte zusätzlich zum Status-Code auch ggfs. ein erklärender Text zurückgegeben werden. Fehlermeldungen, Link auf Doku, Ansprechpartner, etc. Das soll und darf maschinenlesbare Statuscodes nicht ersetzen, hilft aber oft weiter, das Problem schneller zu finden.
Das geht in die Richtung Service-Discovery und Konfigurations-Management: Dabei meldet jeder Dienst (oder sein Deploy-Job) während des Starts selbständig bei einer zentralen Stelle, was für ein Dienst er ist und welche Schnittstellen er anbietet. Der Monitoring-Server lauscht auf Änderungen in dieser Datenbank und konfiguriert den Monitoring-Dienst wenn nötig automatisch neu.
Wenn man möchte lauscht da auch der Proxy-Server (Backend hinzufügen bzw. entfernen), die Tools für das Operating usw. Für weitere Anregungen hier ein Vortrag von der Euro-Python: https://ep2016.europython.eu/media/conference/slides/service-discovery-for-d... Das Thema wird erheblich aus dem Cloud- und Container-Umfeld getrieben, weil es da völlig normal ist, das Instanzen kommen und gehen. Beides ist aber keine Voraussetzung. Wir bauen (im Java-Umfeld) gerade in einer "normalen" Server-Umgebung was mit Consul, damit man für neue Instanzen möglichst wenig manuell anfassen muss. Auch da kann man sich verrennen[2], aber das Risiko gehört dazu. :-) Grüße, Bernd [0] https://hackernoon.com/pumba-chaos-testing-for-docker-1b8815c6b61e [1] https://github.com/Netflix/SimianArmy/wiki [2] https://xkcd.com/1319/
participants (1)
-
Bernd Waterkamp