[Erledigt] FHEM Webinterface nicht erreichbar Ursache:influxdb nicht verfügbar

[Wernieman]

Also sooo viele Hinweise habe ich nicht gegeben 

Weil es vorher geschrieben wurde: Währe mit automatischen Updates auch vorsichtig. Docker-COntainer werden aktuell nur Handisch upgedatet.

Trotzdem sollte ich mir mal Watchtower ansehen ... gibt es einen guten Einstieg dafür?

[rob]

Stimmt schon: Vorsicht ist die Mutter der Porzellankiste
Ich hatte mich direkt der Doku bedient https://containrrr.dev/watchtower/introduction/  - vielleicht gibt es bessere Quellen, die kenne ich dann aber leider nicht.

Watchtower starte ich so:

Code Auswählen Erweitern


docker run -d \
    --name watchtower \
    --restart=always \
    -v /etc/timezone:/etc/timezone:ro \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
    -e WATCHTOWER_NOTIFICATION_URL="telegram://--your-telegram-token-here--@telegram?channels=123456789" \
    containrrr/watchtower:armhf-latest \
     --schedule "0 0 0 * * SUN" \
     --cleanup


Ah: sehe grad, dass Watchtower auch Metrics liefert - werd das mal gleich in Prometheus aufnehmen - immer lohnenswert, wenn man drüber "spricht" 

[Wernieman]

Weißt Du, wie man die metricen bei WatchTower abgreifen kann?

[rob]

Ja. War etwas knobeln nötig  Obige Config ergänzen:

Code Auswählen Erweitern


docker run -d \
    --name watchtower \
    --net=mydockernet \
    --network-alias mywatchtower \
    --restart=always \
    -p 8181:8080 \
    -v /etc/timezone:/etc/timezone:ro \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e WATCHTOWER_NOTIFICATIONS=shoutrrr \
    -e WATCHTOWER_NOTIFICATION_URL="telegram://--your-telegram-token-here--@telegram?channels=123456789" \
    containrrr/watchtower:armhf-latest \
     --schedule "0 0 0 * * SUN" \
     --cleanup \
     --http-api-token mysecrettoken \
     --http-api-metrics


Anmerkung zu net + network-alias + port:
- port wird nur benötigt, wenn man von außerhalb des Dockernetzes zugreifen will, befinden sich die Container in einem gemeinsamen Docker-Subnet braucht man ansonsten keine Ports spezifizieren, weil die Conatiner untereinander immer alle sehen - kann man in obigem Beispiel also weglassen (habs nur zum Testen drin)
- net + network-alias habe ich nur deshalb drin, weil meine Container alle in einem Subnetz sind, also auch Prometheus; bindet man den Container an host, erfolgt der Zugriff meist via IP

Soweit so einfach. Beim konkreten Zugriff für Prometheus musste ich etwas suchen - prometheus.yml ergänzen:

Code Auswählen Erweitern


#my endpoints
scrape_configs:
bla bla
bla bla
  - job_name: watchtower
    metrics_path: /v1/metrics
    bearer_token: mysecrettoken
    static_configs:
      - targets: ['mywatchtower:8080']


Sehr schick: in Telegram wird sogleich mitgeteilt: "Serving HTTP"  und in Prometheus sehe ich nun den Endpoint mit watchtower=up.

Fundstellen:
https://containrrr.dev/watchtower/metrics/
https://github.com/containrrr/watchtower/blob/main/docs/metrics.md
https://github.com/containrrr/watchtower/blob/main/docker-compose.yml
https://github.com/containrrr/watchtower/blob/main/prometheus/prometheus.yml

PS: ist etwas OT und mifh wundert sich womöglich, warum sein Thread einfach keine Ruhe gibt 
imho passt es hier noch recht gut und im Forum fehlt eine Rubrik "Docker", sodass viele gute Kochrezeptperlen sich an vielen Ecken verstecken

[Wernieman]

Dann muß ich mich langsam wirklich um Prometheus kümmern .... habe keinen anderen "Zugriff" für die Metricen gefunden

Edit:
Wer suchet de findet:

Code Auswählen Erweitern

curl -H "Authorization: Bearer <Token>" <Container-ip>:8080/v1/metrics

[mifh]

Spannende Diskussion hier 

Ich habe in den letzten Tagen mal etwas aufgeräumt und schaue mir jetzt prometheus an. Habt Ihr zufällig einen Tipp, wie ich damit meinen MQTT Server überwachen kann? Wenn der ausfällt, ist mein Smarthome nicht mehr allzu smart...

[Wernieman]

Soweit ich weiß ist Prometheus eine Anzeigemöglichkeit, kein Monitoring-Tool. Fürs Monitoring müsstest Du dann auf klassische Monitoringtools wie Nagios, zabbix (checkmk) etc. ausweichen ...

[rob]

Wenn Du den MQTT2-Server von FHEM nutzt, hast Du imho auch gute Möglichkeiten, um auf Ausfälle von Devices usw. zu reagieren z.B. via LWT-Technik und sogar die Prüfung, ob Readings noch aktualisiert werden, habe ich als Diskussion schon gesehen (unabhängig von MQTT). Vielleicht ist auch da schon etwas dabei.

Ansonsten habe ich auf der Prometheus Seite https://prometheus.io/docs/instrumenting/exporters/#messaging-systems u.a. einen MQTT-Exporter gesehen: https://github.com/hikhvar/mqtt2prometheus, aber selber nicht im Einsatz.
Interessant ist dabei, dass auch die up-Metrik mitkommen sollte. Dafür sollte es reichen ein paar Basistopics abzugreifen und nicht gleich alle MQTT-Messages redundant vorzuhalten.

Für das Thema "echtes" Monitoring, wie Wernieman schreibt, wäre m.E. ein neuer Fred lohnenswert. Ich kann ja nur etwas zu Prometheus klugscheißen und wäre ansonsten doch überfragt 

VG
rob


PS: FHEM als endpoint zu haben wäre klasse, sodass man die Erreichbarkeit direkt checken könnte. Es gibt auch eine lib für perl https://metacpan.org/pod/Net::Prometheus. Ich weiß aber leider nicht, wie man das in ein Modul gießt oder wenigstens in die myUtils packt (reinpacken geht schnell, aber es muss ja ein http-Pfad zur Verfügung gestellt werden usw.).
Vielleicht hat doch ein FHEM Entwickler Interesse + Lust dafür was zu machen. Ich könnte immerhin testend unterstützen.

[mifh]

Wenn Du den MQTT2-Server von FHEM nutzt, hast Du imho auch gute Möglichkeiten, um auf Ausfälle von Devices usw. zu reagieren z.B. via LWT-Technik und sogar die Prüfung, ob Readings noch aktualisiert werden, habe ich als Diskussion schon gesehen (unabhängig von MQTT). Vielleicht ist auch da schon etwas dabei.

Da bin ich vielleicht etwas dogmatisch, aber ich bevorzuge einen separaten MQTT-Server ausserhalb von FHEM. Bin halt mit Unix groß geworden, da arbeitet man halt mit Spezialisten, nicht mit Generalisten. Ich gebe zu, das ist Geschmackssache.

PS: FHEM als endpoint zu haben wäre klasse, sodass man die Erreichbarkeit direkt checken könnte. Es gibt auch eine lib für perl https://metacpan.org/pod/Net::Prometheus. Ich weiß aber leider nicht, wie man das in ein Modul gießt oder wenigstens in die myUtils packt (reinpacken geht schnell, aber es muss ja ein http-Pfad zur Verfügung gestellt werden usw.).
Vielleicht hat doch ein FHEM Entwickler Interesse + Lust dafür was zu machen. Ich könnte immerhin testend unterstützen.

Ich habe noch mal etwas geschaut. Wenn man - wie ich - mit blackbox-Tests zufrieden ist und keine Metriken braucht (könnte man sicher auch Nagios nehmen), kriegt man das mit dem blackbox-exporter (https://prometheus.io/docs/guides/multi-target-exporter/ und https://github.com/prometheus/blackbox_exporter) auch hin. Damit kann man auch prüfen, ob der MQTT-Dienst da ist (module TCP_connect). FHEM-Metriken (gibt es die eigentlich ?) könntest Du ja auch mit InfluxDBLog in die InfluxDB schreiben (womit sich der Kreis geschlossen hätte).