[Python-de] Unittests vs Monitoring-Checks

[Bernd Waterkamp]

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-dynamic-python-applications.pdf

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/