Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!news.szaf.org!fu-berlin.de!uni-berlin.de!not-for-mail
From: Marcel Hellkamp <marc@gsites.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] Unittests vs Monitoring-Checks
Date: Fri, 23 Jun 2017 13:12:09 +0200
Lines: 67
Message-ID: <mailman.226.1498216331.10125.python-de@python.org>
References: <03e3b2fd-9b09-ea7c-0c6c-b33f2ece2412@thomas-guettler.de> <87b8359c-24ae-8cef-96d1-51c9d5c1c297@gsites.de> <eb0f7961-1807-8b52-0fa9-5b1a00c5354d@thomas-guettler.de> <67f44a43-5640-024d-ad81-0ba21398662b@gsites.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
In-Reply-To: <eb0f7961-1807-8b52-0fa9-5b1a00c5354d@thomas-guettler.de>
Content-Language: de-DE
Precedence: list
Xref: csiph.com de.comp.lang.python:4819

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