Unittests vs Monitoring-Checks
Hallo, seit vielen Monaten nutze ich TDD (Test Driven Development). Nicht immer, aber meistens gehe ich nach dem Prinzip "Red, Green, Refactor" vor. Bei der Entwicklung ist zusammen mit CI (Continuous Integration) alles prima. 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. Wir nutzen dafür ein Nagios-ähnliches Tool, wie wohl die meisten Menschen, die für die Verfügbarkeit von Systemen verantwortlich sind. Derzeit gibt es hier einen großen Bruch. Entwickler schreiben Unittests flüssig und regelmäßig. Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks. Damit es kein einseitiges pro/contra zu meinem Lösungsvorschlag gibt, stelle ich hier erst mal das Problem vor - ohne Lösungsansatz. Erste Frage: Könnt ihr nachvollziehen, wenn ich mir das wünsche? Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks. Zweite Frage: Wie läuft das bei euch mit Checks: Entwicklung, Deployment, Ausführung, Weiterleitung, ...? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Schade, null Feedback ... Ich frage mich warum .... Gruß, Thomas Am 16.06.2017 um 08:59 schrieb Thomas Güttler:
Hallo,
seit vielen Monaten nutze ich TDD (Test Driven Development).
Nicht immer, aber meistens gehe ich nach dem Prinzip "Red, Green, Refactor" vor.
Bei der Entwicklung ist zusammen mit CI (Continuous Integration) alles prima.
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.
Wir nutzen dafür ein Nagios-ähnliches Tool, wie wohl die meisten Menschen, die für die Verfügbarkeit von Systemen verantwortlich sind.
Derzeit gibt es hier einen großen Bruch.
Entwickler schreiben Unittests flüssig und regelmäßig.
Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks.
Damit es kein einseitiges pro/contra zu meinem Lösungsvorschlag gibt, stelle ich hier erst mal das Problem vor - ohne Lösungsansatz.
Erste Frage: Könnt ihr nachvollziehen, wenn ich mir das wünsche?
Genauso locker und leicht hätte ich gerne das Erstellen neuer Checks.
Zweite Frage: Wie läuft das bei euch mit Checks: Entwicklung, Deployment, Ausführung, Weiterleitung, ...?
Gruß, Thomas
-- Thomas Guettler http://www.thomas-guettler.de/
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, ...?
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. 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. 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. Frage beantwortet? mfg, Marcel
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/
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
Am 23.06.2017 um 13:12 schrieb Marcel Hellkamp:
....
Danke Marcel für deine Hinweise - Das war aufschlussreich. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
participants (2)
-
Marcel Hellkamp
-
Thomas Güttler