Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #4819 > unrolled thread

Re: [Python-de] Unittests vs Monitoring-Checks

Back to article view | Back to de.comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Python-de] Unittests vs Monitoring-Checks Marcel Hellkamp <marc@gsites.de> - 2017-06-23 13:12 +0200
    Re: [Python-de] Unittests vs Monitoring-Checks Bernd Waterkamp <Bernd-Waterkamp@web.de> - 2017-06-24 17:47 +0200

#4819 — Re: [Python-de] Unittests vs Monitoring-Checks

Hi Thomas,

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.

> Wie schreibst du nun genau einen Health-Check?
>
> 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. Dazu passend ein kleines
Nagios-Plugin das diese Ressource abfragt und in Nagios-Zustände
übersetzt. Das Nagios-Plugin kann man für den nächsten REST-Service
natürlich wieder verwenden. Hat ein Dienst keine REST-Schnittstelle,
kann man die mit Bottle[3] oder Flask recht einfach nachrüsten.

Um die Metriken innerhalb des Dienstes zu erfassen und zu sammeln gibt
es zahlreiche Ansätze. In der Java-Welt gibt es z.B. dropwizard-metrics
[1], für Python entsprechende alternativen [2].

Nagios-Plugins sind simpel genug das man da kein Framework für braucht.
Ein paar Zeilen bash+curl+jq oder Python reichen völlig.

> Wie und wann werden die Checks aufgerufen? Den einen Check will man
> vielleicht öfter aufrufen als einen anderen ...

Das konfiguriert man im Monitoring-Tool je nach Bedarf.
Performance-Metriken (Füllstände von Queues, durchschnittliche
Antwortzeiten u.s.w.) sammle ich z.B. alle 10 Sekunden ein (telegraf +
inputs.httpjson). Da Nagios ein bisschen schwerfälliger ist, werden dort
nur alle 5-10 Minuten Checks eingeholt. Sind Checks besonders teuer,
weil sie z.B. komplexe SQL Querys benötigen, werden sie Dienst-Seitig
gecached und eben nur alle X Minuten neu berechnet. So kann man aus
Monitoring-Sicht alle Dienste über einen Kamm scheren und braucht keine
Rücksicht auf bestimmte Dienste nehmen.

> Meine Wunschvorstellung: Der Entwickler schreibt einen health-Check.
> Er macht das im gleichen Repo, also dort wo auch
> der produktive Code ist. Viel mehr sollte eigentlich nicht nötig sein,
> damit nach dem nächsten Deploy der
> health-Check aktiv ist. Also per default "no config needed"

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 Puppet einsetzt, hat man im Prinzip schon alles was man dafür
braucht. Ansonsten ließe sich das auch z.B. mit etcd[4] und confd[5]
realisieren oder mit einer x-beliebigen Datenbank selbst basteln. Ob
sich der Aufwand lohnt, ist natürlich immer die Frage.

[1]: http://metrics.dropwizard.io/3.2.2/
[2]: https://github.com/Cue/scales
[3]: https://bottlepy.org/
[4]: https://coreos.com/etcd/docs/latest/
[5]: http://www.confd.io/

mfg, Marcel

[toc] | [next] | [standalone]

#4822

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/

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.python

csiph-web