Container Healthcheck sinnvoll?

[buanet]

Container Healthcheck sinnvoll?

[jpawlowski]

Die Überwachung der Web-Instanzen machen wir im FHEM Container Image ebenfalls.

[JoschaMiddendorf]

Ich habe das in meinem FHEM Container implementiert. So lässt sich beispielsweise der container Neustarten wenn sich mal etwas aufgehängt hat. Außerdem lässt sich die uptime ganz gut auswerten und man sieht sofort ob der Container erreichbar ist. Ich halte das für sinnvoll.

[fzzybllz]

Könnte man damit sowohl den State "Enable/Disabled" als auch "alive" der Admin-Instanz überwachen?

Ich habe gestern versehentlich den hostname meines iobroker Containers geändert und anschließend stundenlang den Fehler gesucht wieso die Weboberfläche nicht mehr erreichbar ist.

[Springjunky]

Ein health-Check ist m.E eine fachliche Aussage, die bei einem Application-Server nicht viel Sinn macht eben wegen den ganzen fachlichen Modulen die einzeln für sich "unhealthy" sein könnten.
Wenn eine Instanz kaputt ist, gilt dann der ganze IOBroker als kaputt ?

Bei Docker gilt ja eigentlich EIN Container EIN Prozess, da ist der Health-Check mit einer klaren Aussage verbunden.

Rein techn. finde ich die Implementierung etwas komplizierter, nur http://localhost:8081 auf HTTP 200 OK abzufragen könnte schon scheitern bei https / Username Password ... ok, da könnte man noch 401 und 403 abfragen.

Allerdings kann ja eigenlich auch jeder seinen Health-Check selber definieren, wie er will von dieser Seite https://howchoo.com/g/zwjhogrkywe/how-to-add-a-health-check-to-your-docker-container das Snippet

version: '3.1'
services:
  web:
    image: docker-flask
    ports:
      - '5000:5000'
    healthcheck:
      test: curl --fail -s http://localhost:5000/ || exit 1
      interval: 1m30s
      timeout: 10s
      retries: 3

legt das zumindest nahe, muss halt nur curl im Container sein .. dann würde ich mal sehen, ob ich nicht aus dem Simple-Api Modul https://github.com/ioBroker/ioBroker.simple-api einen komplexen Health-Check basteln kann und zwar genau für mich der auch mehrere Curls mach und die für mich wichtigen Instanzen abfragt.

[Apollon77]

Wie zuletzt geschrieben wurde mus man überlegen was genau Ziel ist und was healthy bedeutet. Theoretisch ist es der js-Controller oder das eine bestimmte listens Adaptern läuft oder sonstwas. Das muss man mal schauen.

Nur Admin Port oder api requests per simple-api ist gg nicht zielführend.

[JoschaMiddendorf]

Prinzipiell soll der Health State des Containers eine Aussage darüber treffen ob der Container noch funktioniert. Wenn das frontend noch funktioniert, würde ich sagen das der Container healthy ist. Eine Fehlkonfiguration einzelner Adapter zu überwachen halte ich nicht für sinnvoll, da hier ein automatisches killen des Containers mit anschließendem Neustart eh nichts bringen würde. Ich benötige das frontend ja um die Fehlkonfiguration zu beheben.
Korrigiert mich gerne wenn ihr da anderer Meinung seit oder andere Aktionen bei einem unhealthy state durchführen würdet.

PS: Der Health State wird unter anderem auch verwendet um bei einem Docker Swarm Cluster mit mehreren Hosts an unterschiedlichen Standorten auf einen anderen Host umzusteigen, wenn ein Service nicht mehr erreichbar ist z.B. wegen Internet Ausfall. Aber auch das hat nichts mit fehlerhaften Adaptern zu tun.

[Apollon77]

Naja genau das ist die Thematik: Wenn Dein ganzes Haus tut wenn hm-* und javascript Adapter laufen weil darüber alles umgesetzt ist (Beispiel) dann hat Admin für "mein Haus funktioniert wie es soll" nichts zu sagen ...

Der Basisdienst ohne den gar nichts tut ist der js-controller ...

Und sehr viele der Adapter haben externe Abhängkeiten - wenn CCU weg ist dann ist hm-rpc ggf "gelb" oder so. Ja, da ist Admin der mit wenig solchen Abhängkeiten.

Ein Health Check (auch ggf um zu entscheiden ob man den Container verschieben muss) ist in dem Umfeld, wie oben schon geschrieben, extrem schwierig.
Ich denke es ist sehr spezifisch und User-Abhängig was "der" health Check sein muss

[JoschaMiddendorf]

Das würde heißen das die Überwachung des js-controllers ausreichend ist. Alles andere sind extra Features die nicht unter Docker sondern eine Ebene höher unter dem js-Controller laufen dessen Überwachung der Administrator selber sicher stellen muss. Damit er das kann braucht er ein Frontend. Daher würde ich das überwachen und gut ist. Wenn das läuft läuft nämlich auch der js-controller.

[Springjunky]

...tatsächlich stimme ich JoschaMiddendorf hier zu ... auf jeden Fall würde eine Überwachung des js-Controllers dann auch Sinn machen, wenn die Aussage getroffen wird "grundsätzlich läuft's" alles weiter obliegt dann dem Admin. Ich bin hier ein wenig gespalten .. zugegeben.

[fzzybllz]

@JoschaMiddendorf Prinzipiell bin ich bei dir. Ich wäre auch dafür den Admin zu checken. Korrekt ist es zwar eigentlich nicht, da ich jedoch selbst bereits in meinem Container bereits in einem funktionierenden js-controller mit "defekter" Admin-Instanz gelaufen bin. Prinzipiell interessiert einen User in erster Linie die Funktion des Frontends/Admins und damit wäre auch der js-controller hinreichend geprüft.

[Apollon77]

Bedenkt aber bitte eins (und ich denke das wird vor allem im Docker Umfeld - und wenn oben schon von Docker Swarm die Rede ist - interessant): Admin läuft üblicherweidse nur auf einem der "Hosts". Sobald ein System Multi-Host ist und daher die Installation auf mehrere Container aufgeteilt ist, geht das instant kaputt weil dann beim Slave kein Admin läuft.

Daher zurück zu: Was ist der Usecase Zielgruppe für den Health check? Für mich wäre der generell lauffähig. Und damit stelle ich mir folgendes System vor meinem Inneren Auge vor:

• iobroker läuft komplett auf Redis
  • Redis-DBs als eigene Container, idealerweise mit js-controller 2.0 im Redis-Sentinel "HA"-Setup - Vorteil von "alles Redis" ist das ioBroker selbst nahzu keine lokale persistenz mehr hat (ausser bei History oder solchen Adaptern)
  • Am Ende aber egal weil wenn kein Redis dann ist ein "Host" der Master und stellt die DBs bereit und auch hier gilt das nur "üblicherweise" der Admin auf diesem Master-Host läuft
• mehrere iobroker-Container auf die die Adapter verteilt sind (am Ende quasi alles Slaves sobald alle DBs per Redis laufen) connecten zu dem "Redis-Sentinel-Cluster"

Bitte versteht mich nicht falsch (und am Ende kommentiere ich hier nur als Beobachter): Ich möchte das Thema nicht aufblähen, aber möchte auch gern das was sinnvolles rauskommt :)

[buanet]

Hallo Zusammen,

ich freue mich gerade ungemein über diese interessante und fachliche Diskussion. :) Wirklich vielen Dank dafür!

Was mich allerdings bei der Frage nach der Sinnhaftigkeit des Healthchecks vor allem interessiert, sind die konkreten Anwendugsfälle.
Klar, Docker Swarm wäre eine nette Sache. Load balancing und Redundanz hören sich immer gut an. Aber ist das für ioBroker, eine Software die viele für ihr Eigenheim auf einem Entwicklerboard mit SD-Karte betreiben, nach heutigem Stand überhaupt relevant? :)

Da wir Docker für ioBroker aktuell ja gar nicht entsprechend des Docker Gedanken nutzen (dann müsste nämlich jeder Adapter/ Prozess seinen eigenen Container haben), sind dann Features wie Docker Swarm überhaupt sinnvoll nutzbar?

Vielleicht habt ihr dazu noch ein paar Gedanken für mich.
Vielen Dank.

@Apollon77
Redis ist so ein Thema dass ich auch immer wieder auf dem Schirm habe und gerne noch viel weiter integrieren würde.
Habe aktuell die Möglichkeit geschaffen beim Start des Containers bereits eine ENV für die Konfiguration von redis als States-DB mit zu geben. Das wiederum schafft die Möglichkeit per docker compose in einem Schritt ioBroker und Redis in zwei containern zu deployen und direkt auf ioBroker-Ebene zu verheiraten... Vielleicht können wir an anderer Stelle/ auf einem anderen Kanal mal über deine Visionen vor deinem inneren Auge plaudern... :)

MfG,
André

[AlCalzone]

Mal als weitere Idee, um die Diskussion um "was ist relevant für healthy" anzufeuern: Wie wäre es mit einem Docker-Healthcheck-Adapter, der im Docker-Image standardmäßig installiert ist und mit dem User selbst definieren können, was für ihr System außer JS-Controller noch essentiell ist? Z.B. bestimmte Adapter-Instanzen, einzelne Skripte, ...
Dieser Adapter würde dann die Gegenstelle für den Check darstellen.

[Apollon77]

Das was du ansprichst meine ich mit der Zielgruppe und so. Wenn für Euch alle klar ist das es so ist wie Du beschrieben hast und ein "Docker cluster" die Ausnahme ist und am Ende eh nur einen Container durch die gegen schieben würde wo wiederum alles drin ist dann alles ok. js-controller und ggf Admin überwachen und ok.

In meinen Augen ist aber jetzt schon die Realität das viele User spätestens bei der Nutzung von lokalen Schnittstellen (der Strom/Wasserzähler im Keller oder der Zigbee Stick der idealerweise zentraler als im keller stehen sollte oder sowas) die Option nutzen nen zweiten Raspi hinzustellen - und schon hat man ein Master-Slave System.
Dann hätte man zwei "Lokale" Docker-Container die beide getrennt laufen. Einer als Master, einer als Slave - und beim Slave läuft kein Admin. Also wäre der nicht healthy :-(
Wenn aktuell das Docker-Image gar keinen Slave abbilden kann, dann sind wir wieder bei obigem "Admin checken reicht".

Ich mag irgendwie die Idee von @AlCalzone ... würde es eher einen "System-Status-Adapter" nennen der auf einem Port einen HTTP endpunkt anbietet und idealerweise direkt genutzt werden kann weil das kann Docker glaube ich von Hause aus.

@buanet Gern... eigenes Issue? Whatsapp? Telergam? :-) E-mail ([email protected])

[GermanBluefox]

Man darf nicht vergessen, dass admin und js-controller upgedatet werden. Und während Update sind natürlich die Ports nicht erreichbar.
Die Idee mit dem Special Adapter für Docker finde ich super. Mit email/telegram/sms Benachrichtigung.

[Apollon77]

Also ein "System Status" Adapter der Adapter und Sytemteile überwachen kann und die Ergebnisse wahlweise per HTTP-Port (Health), oder Kommunikationsadapter (pushover, telegram, email, sms wenn. ich meinen gsm Adapter mal fertig hab) bereitstellt :-)

js-controller adapter würe ich bei docker weniger Problematisch sehen. Aber Admin update ja ... wärhre blöd wenn der COntainer gekillt und restartet wird wenn man gerade Admin updatet :-) (was aber auch auf einen Status Adapter zutreffen würde!!)

[GermanBluefox]

js-controller adapter würe ich bei docker weniger Problematisch sehen. Aber Admin update ja ... wärhre blöd wenn der COntainer gekillt und restartet wird wenn man gerade Admin updatet :-) (was aber auch auf einen Status Adapter zutreffen würde!!)

Natürlich sollte ein Timeout von 1-2 Minuten akzeptabel sein.

[fzzybllz]

@Apollon77 Ich glaube da hat @buanet nicht unrecht. Ich bin vermutlich genau so ein durchschnitts-User, der seinen Master im Container auf seinem NAS betreibt und aufgrund von Lokations-/Reichweitenthemen einen Slave auf einem Pi (dort allerdings direkt auf Raspbian). Du bringst mich nun auf ganz neue Ideen, an die ich nie gedacht habe...

[Springjunky]

Also ich stimme @buanet hier auch zu, wir reden von Heimanwendern die allenfalls ein oder 2 PI's (oder andere Hardware) laufen haben, sei es mit Client /Server oder eben auch Single.
Aber was auch schon bei den Diskussionen irgendwie rauskam: Jeder möchte es aber jeder irgendwie anders.
Ich denke, das Problem besteht in dem Konzeptbruch (oder wie man so schön sagt: Use the right tool for the job) Docker ist halt nach dem Prinzip 1 Container 1 Prozess gebaut.
IObroker ist ein Application Server und da denkt eigentlich keiner dran, den auf Kubernetes oder so zu bringen; m.E. ist ein Swarm/K8s eher für Microservices.

Die einzige, sozusagen offizielle Ausnahme, die mir hier spontan noch so einfällt ist GitLab als Docker-Container mit Prometheus und Redis und Elastic Search und und im Container... wobei die hatten wohl ähnliche Gedanken; in der Doku zum Health-Check steht dazu folgendes

Checks whether the application server is running. It does not verify the database or other services are running. .

Was damit eigentlich der Idee "ich prüfe den Admin-Controller" entspricht.

Die Idee des System Status Adapter finde ich allerdings auch sehr gut, denn wenn hier eine verteilte Infrastruktur vorliegt kann der Health-Check pro Container definiert werden und ist nicht von dem Admin-Knoten abhängig; außerdem haben auch schon andere eine ähnliche Idee ganz gut etabliert. (das Microservices Framework SpringBoot macht genau das; die Möglichkeit geben über eine standardtisierte Schnittstelle ein Health zu implementiern)

[Apollon77]

Es ist halt das Thema wie und ob man die Zielgruppe wirklich so einschränken will/muss.

Wenn ich mal meine Rolle als Entwickler und so wegdenke sehe ich mich an sich immer noch als (fortgeschrittenen) Heimanwender. Wegen "Strom/Wasser/Heizungszähler im Keller" und "Zigbee Stick im Wohnzimmer" und Hauptsystem im Arbeitszimmer habe ich drei Hosts im Multi-Host im Einsatz. Das das inzwischen Intel Nucs sind /früher Cubietrucks) und keine Raspis sollte denke nicht der Unterschied sein. Auch das ich Redis nutze ist hier egal ...

Wenn ich von VMs auf Docker umstellen wollte würde mich ein Health Check mit nur Admin dann dazu bringen es nicht nutzen zu können ...

Aber wie oben gesagt: Wenn das die Zielgruppe ist alles ok ...

[Springjunky]

Also ich denke für den ersten Wurf wäre der Health-Check auf den Admin-Adapter ja doch ok, man müsste ihn ja nicht nutzen bzw. könnte ihn "wegkonfigurierbar" machen.
Natürlich müßte bei einem Multi-Host jeder Host dann irgendwie einen Health-Check haben, da stimme ich @Apollon77 zu.
Dazu ist ja die Idee des "System Status Adapter" geboren worden .... in einer der nächsten Ausbaustufen ... der könnte ja dann bestimmt auf jedem Host laufen (oder geht das nicht, da kenne ich mich noch zu wenig aus mit IOBroker).

[Apollon77]

Hey all,

I have an update on this because as written above also an adapter has it's pitfalls.

While planning on an other topic for js.controller 2.3 iI came to the clue that this could be the solution for this topic.

We plan to introduce a "flexible plugin system" where plugins as npm packages can be defined and configured to run in the scope of an adapter and (more relevant for here) on js-controller level.
Idea see ioBroker/ioBroker.js-controller#637 ...

This would mean for this idea:
One could write a "health check" plugin which gets e.g. a list of adapter instances to monitor if they are running and offer a port with an HTTP page with the status - or whatever idea to check it (e.g. write regulary a file which is then read or or or). This plugin runs as soon as the js-controller is running.

What do you think on this?

Once the API for plugins is finalized someone could already start to develop the plugin and then it could be available as soon as js-controller 2.3 is released approx end of march for testing.

[dwm66]

Servus,
in Bezug auf einen use-case ... ich hatte vor kurzem das Problem, dass der ioBroker pünktlich um Mitternacht abgeraucht war - andere Baustelle, gelöst.
Aber - kurzfristig hab ich da einfach eine "alte" Version des Containers gestartet.
Was ich mir vorstelle, wär Container als "blue/green" deployment zu betreiben - sprich die letzte "gute" Version ist green, normal läuft "blue". Wenn irgendwas schief geht, ist ein Fallback nach "green" einfach - dafür hab ich mir mal ein Script gebastelt.
Macht alle Upgrades - auch bei node.js Version usw. doch deutlich entspannter, wenn man einfach sagen kann "docker stop iobroker-blue && docker start iobroker-green"

Der nächste Schritt wäre jetzt ein "Watchdog", der den laufenden "blue" Container auf health überprüft, bei einem Fehler einen "docker restart" versucht, und dann - wenn das ... sagen wir mehr als 3x fehlschlägt, als Fallback den "green" startet.

Ich mag da die Idee für einen "health" adapter - damit könnte man nämlich recht granular einstellen, was für einen selbst die betriebskritischen Adapter sind, die laufen müssen.

[Apollon77]

A plugion system will be introduces in js-controller 3.0 (release planned April-ish) and will have an included Plugin system: ioBroker/ioBroker.js-controller#743

So as described above with this it is possible todevelop an easy health check plugin that runs together with the js-controller and offers a http port with a simply /health endpoint and could check if a defined number of instances are alive and report that back as response ...

[buanet]

Hallo zusammen,
ich hab da jetzt mal was zum Thema zusammen geschustert. :)

Habe vor einigen Wochen meinen Multihost-Slave mit der aktuellen Beta zu Docker migriert.
(Habe jetzt also einen Master und einen Slave (Raspberry mit Docker) als Container laufen.)

Jetzt macht mein Master jeden Montag früh eine komplettes Backup inkl. Datenbanken usw. woraufhin sich der js-controller im Slave aufgrund der längeren Ausfallzeit von Redis und Master zuverlässig selbst beendet. (Bug oder Feature sei mal dahin gestellt) :)

Lange Rede kurzer Sinn, um dieses Verhalten ab zu fangen habe ich in die aktuelle Beta (Build läuft gerade noch) einen relativ simplen Docker Healthcheck eingebaut. Der macht aktuell nichts weiter als zu prüfen ob der js-controller läuft oder nicht.
Wenn der js-controller beendet wird, wird der container "unhealthy" und mein "Docker-Watchdog" startet ihn neu....
Damit das nicht passiert wenn ich nur mal eben den js-controller update habe ich auch noch einen maintenance modus mit eingebaut (Details dazu in der beta readme.md)

Sicherlich werde ich da in nächster Zeit noch ein wenig dran feilen müssen, aber als Basis für weitere Checks scheint das schon mal gut zu laufen....

Jetzt aber zum eigentlichen Kern:
Die Idee mit dem js-controller plugin von @Apollon77 zur Bereitstellung eines http Endpunkts für den Healthcheck finde ich klasse. Soweit ich das verfolgt habe sind auch alle Voraussetzungen dafür geschaffen. Allerdings sehe ich mich aktuell außerstande solch ein Plugin zu entwickeln. Daher wäre ich hier auf Hilfe angewiesen...

MfG,
André

[Apollon77]

Kurz zu denen was du geschrieben hast:
Sobald die Datenbank ein redis ist gibt es faktisch keinen Master und keinen Slave mehr. Es sind beides „gleichberechtigte“ js-Controller die sich über redis als dB synchronisieren. Der redis ist quasi der neue „Master“

Wenn du also die Backup Zeit des redis so kurz wie möglich hältst (<90s ganz grob) dann laufen die Controller weiter. Erst wenn der redis länger weg ist laufen die Daten und fehlenden object/state Updates zu weit auseinander und der Controller beendet sich (und startet sind idealerweise selbst neu).
Redis kannst du per „BGSAVE“ Kommando anweisen ein dump.rdb file zu erzeugen. Das ist Dein dB Backup. Das geht an sich zur Laufzeit. ;-)

Und ja, der Controller 3.0+ hat das Plugin System drin. Denke das Plugin ist auch nicht die Welt von Aufwand. Wenn jemand mal ein js-Controller issue mit nem Vorschlag für die Daten die der Endpunkt ausgeben soll anlegt ist sowas bestimmt machbar.