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

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

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

Show key headers only | View raw

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

Back to de.comp.lang.python | Previous | Next — Next in thread | Find similar

Thread

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

csiph-web