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


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

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

From Thomas Güttler <guettliml@thomas-guettler.de>
Newsgroups de.comp.lang.python
Subject Re: [Python-de] Unittests vs Monitoring-Checks
Date 2017-06-23 10:31 +0200
Message-ID <mailman.222.1498206703.10125.python-de@python.org> (permalink)
References <03e3b2fd-9b09-ea7c-0c6c-b33f2ece2412@thomas-guettler.de> <87b8359c-24ae-8cef-96d1-51c9d5c1c297@gsites.de> <eb0f7961-1807-8b52-0fa9-5b1a00c5354d@thomas-guettler.de>

Show all headers | View raw



Am 22.06.2017 um 18:00 schrieb Marcel Hellkamp:
> Hi Liste,
> 
> On 06/16/2017 08:59 AM, Thomas Güttler wrote:
>> Jetzt gibt es aber noch einen anderen Bereich: Monitoring-Checks. Also
>> Prüfungen,
>> die nicht im Rahmen vom CI passieren, sondern Prüfungen, die für
>> produktive Systeme sind.
>> [...]
>> Zweite Frage: Wie läuft das bei euch mit Checks: Entwicklung,
>> Deployment, Ausführung, Weiterleitung, ...?

Erstmal "Danke", dass eine Antwort geschrieben hast.

> Im Idealfall ist jeder Dienst oder Service für die Interpretation seine
> eigenen Metriken selbst verantwortlich und liefert nur einen
> Ampel-Status ans Monitoring zurück: Also grün (alles gut), geb
> (überlastet oder instabil) oder rot (fehlerhaft oder offline). 


> Die
> Health-Checks sind dabei Teil der zu entwickelnden Software und werden
> ihrerseits durch Unit- oder Integrations-Tests abgedeckt. Ihre
> Entwicklung unterscheidet sich nicht großartig von der anderer
> Funktionalitäten.

Vermutlich verstehe ich hier etwas nicht richtig.

Du sagst "Die Health-Checks .. werden .. durch Unit- oder Integrations-Tests abgedeckt"

Meinst du, dass die Health-Checks getestet werden wie alle anderen Code-Bereiche auch?

Dann ja. Das macht Sinn.



> Beispiel: Wenn ich den Auth-Service mit falschen LDAP Konfiguration
> starte und keine Verbindung zustande kommt, sollte sein Health-Check rot
> sein. Außerdem sollte eine bestimmte Warnung im Log auf tauchen. Das
> kann ich lokal und unabhängig vom verwendeten Monitoring-Tool entwickeln
> und automatisiert in einem einfach Integrations-Test prüfen.
> 
> Das Monitoring-Tool hat dann nur noch eine liste von Diensten, die es
> prüfen soll und braucht keinerlei Detailwissen mehr. Auch Abhängigkeiten
> zwischen Diensten müssen nicht mehr mühsam gepflegt werden, da jeder
> Dienst seine eigenen Abhängigkeiten selbst prüft. Wenn was gelb oder rot
> ist, schau ich ins (zentrale) log und sehe dort die Details.

Ja, klingt plausibel



> Der Zustand der VMs (Auslastung, Ram-Verbrauch u.s.w.) ist völlig
> unabhängig davon und wird mit Standard-Tools (nagios,
> telegraf+influxdb+grafana) protokolliert. Diese Checks sind allerdings
> relativ simpel und überall gleich, daher muss dort nicht viel entwickelt
> oder getestet werden.

Ja, diese Low-Level Sachen spielen bei meiner aktuellen Betrachtung keine Rolle.
Ich denke an health-Checks, die spezifisch für eine Anwendung sind. Also diese Situation:
Entwickler entwickelt und merkt dabei, dass fehlerhafte Zustände nicht ausgeschlossen werden können.
Diese fehlerhaften Zustände sollen nicht übersehen werden ...


> Frage beantwortet?

Ja, Marcel -  danke. Zum größten Teil ist meine Frage beantwortet ...

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?

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


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"


Zum Hintergrund der Frage:

Wir haben in der Firma aktuell hier eine stabile Bastellösung. Früher oder später will ich mal davon weg kommen.

Ich möchte jetzt nicht von der einen Bastellösung zur nächsten.

Ich habe hier noch keine sane-default-Lösung gefunden. Anders bei Tests+CI. Das ist inzwischen halbwegs passend.

Darum denke ich, dass Reden aktuell sinnvoller ist als Handeln. Auch wenn dieses Vorgehen für Informatiker eher unüblich 
ist :-)

Gruß,
   Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/

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


Thread

Re: [Python-de] Unittests vs Monitoring-Checks Thomas Güttler <guettliml@thomas-guettler.de> - 2017-06-23 10:31 +0200

csiph-web