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

[mifh]

Moin
meine FHEM Produktivinstanz, die ich im docker-Container betreibe, hat den Dienst eingestellt (natürlich war ich auf Dienstreise und meine Frau hatte 1 Woche keine Samrthome-Funktionen. Tolle Werbung).
Ich habe das Problem dann untersucht:
- es wurden keine Schaltvorgänge durchgeführt
- die WEB-GUI war nicht erreichbar
- ins Log wurden Einträge geschrieben
- Neustart des Containers brachte nix
- nach Ersetzen der fhem.cfg durch die demo.cfg war die GUI wieder erreichbar

Ich habe dann schrittweise die ursprüngliche fhem.cfg reduziert, bis ich herausgefunden habe, dass InfluxDBLog die Ursache war: die DB war nicht verfügbar. Restart hat geholfen, FHEM ist wieder da.

Damit ist die Störung beseitigt, und die Problemlösung beginnt:

Ich habe 2 Fragen:
1. gibt es eine schnellere Methode, als durch sukzessives Auskommentieren herauszufinden, wo der Prozess hängt, bei nicht laufender GUI? Bei > 3000 Zeilen Konfiguration eher mühsam.
2. Es kann immer mal sein, dass eine Komponente im Hausnetz wegfliegt (z.B. die InfluxDB). Wenn dann der gesamte Smarthomeserver ebenfalls wegfliegt, ist das für einen Produktivbetrieb aus meiner Sicht nicht akzeptabel. Habe ich einen Fehler bei der InfluxDB Konfiguration gemacht? Ich habe schon früher beobachtet, dass FHEM etwas zickig war, wenn IP-Verbindungen nicht verfügbar waren. Kann ich da etwas machen oder ist das halt so in FHEM?

So sieht mein InfluxDB define aus:

Code Auswählen Erweitern

defmod InfLog InfluxDBLog rancher 8086 fhem fhem XXXXXX  Vers_GasZaehler:.*|\
SPK_Temperatur:Temperatur:.*|Sonoff_Pow1:.*|Garten.DHT22:.*|HWR_FroniusPow:Body_Data_Site_P_PV.*|\
HWR_FroniusPow:Body_Data_Site_P_Load.*|HWR_FroniusPow:Body_Data_Site_P_Grid.*|Hzg_Therme.*|\
Hzg_TempRuecklauf:Temperatur.*|Hzg_TempVorlauf:Temperatur.*|WHZ_GOS01.*|WHZ_GOS02.*|WHZ_GOS03.*|WHZ_GOS04.*|\
AZ_ThermometerServer.*|Whz_Thermometer.*|BAD_OG_Thermometer.*|SCHLAFZ_Thermometer.*|Whz_Decklicht.*|GartenLicht_2.*|WHZ_GOS03.*|\
GartenLicht_3.*|Garten_SENS1.*|Garten_SENS2.*|Garten_SENS3.*|Hzg_WarmwasserTemp:.*|AZ_thermometer4:.*|AZ_CO2:.*|\
GRT_BEW_Cocktail1.*|GRT_BEW_Cocktail2.*|GRT_BEW_Chili.*|GRT_BEW_Freiland.*|GRT_BEW_GelbeTomate.*|GRT_BEW_Cocktail1.*|GRT_BEW_Sensor.*|GRT_BEW.*\


Hat jemand einen Hinweis für mich?

[Wernieman]

Würde Dir dann noch ein unabhängiges Monitoring empfehlen. Bevor ich bei FHEM auf die Fehlersuche gehe, reicht ein Blick aufs Monitoring, ob es denn Grundsätzlich läuft. Deine InfluxDB (Muß jetzt gestehen, kenne ich nicht) ist doch ein Basisdienst. Also sollte man bei Problemen vorher gucken, ob die grundlagen vorhanden sind.

Btw: Wofür nutzt Du die DB? Wie eingebunden? Sollte nicht FHEM auch ohne DB laufen?

[mifh]

Moin,

danke für die fixe Antwort 

Generell ist ein Monitoring sicher eine gute Idee, nur hilft mir das wenig, wenn das System abstürzt und ich nicht da bin.
Inzwischen habe ich gesehen, dass das von mir verwendete Modul wohl nicht mehr gepflegt wird und in der Tat wohl die main-loop blockiert. Das scheint ja ein unsicheres Verfahren zu sein, um das man besser einen Bogen macht. Kann man - ohne intensives Sourcecode-Studium - herausfinden, ob man noch andere dieser Module einsetzt? Die würde ich dann halt ersetzen oder in eigene Instanzen auslagern.

[Wernieman]

So lange man Deine Umgebung nicht kennt, ist eine Aussage nicht möglich.

Also bitte:
- Wofür verwendest Du die DB?
- Was hast Du sonst am Laufen?
- Welche Version von FHEM bzw. wann das letzte mal upgedatet?

[mifh]

Moin

Vielen Dank, dass Du mir helfen willst!
Ich glaube aber, dass meine Fragen nicht so viel mit meiner konkreten Umgebung zu tun haben. Ich bin ja so weit, dass ich das Modul InfluxDBLog als Verursacher ermittelt habe.
Und hier https://forum.fhem.de/index.php/topic,114860.0.html gibt es ja auch den Hinweis, dass das Modul die Main-Loop blockieren kann. Ich vermute mal, genau das ist bei mir passiert.

Daher werde ich das Modul rauswerfen.

Meine verbleibende Frage ist nur noch, wie ich mögliche andere Module erkennen kann, die das selbe Problem haben. Alle von mir verwendeten Module hier im Forum von Hand aufzulisten klingt nach ziemlich Handarbeit, der server meldet 344 defined entities. Ich denke, so 20-40 Module werden da wohl über die Jahre zusammengekommen sein.

Ich vermute mal, am Ende lautete die Antwort auf meine Frage lautet daher: das kriegt man nur raus, wenn man den Quellcode aller  Moduls anschaut.

Zu Deiner Frage, was InfluxDBLog macht: das Modul erlaubt es, Messwerte nach InfluxDB zu pumpen. InfluxDB ist ein time series database. Platt gesagt, speichert die zeitbasierte Messwerte deutlich effizienter als eine normale Datenbank. Mit Auswertungstools wie Grafana kann man diese Daten auswerten. Ich verwende das für Temperaturdaten und andere Sensorwerte.

[Wernieman]

Fürs speichern von Werten in eine DB giebt es das DBLog Modul. Weiß nicht, mit welchen DBs es genau zusammenarbeitet. Dort ist auch ein Async Modus, also Weiterarbeiten wenn DB weg ist, implementiert.

Pauschal gibt es keine Möglichkeit zu sagen, welche Module blockieren und welche nicht.

40 Module würe michd ann doch seeehr wundern... was Du nicht beantwortet hast, wie "alt" ist Dein FHEM? Wenn dieses nicht beantwortet wird, werd ich immer seeeehr hellhörig ...

[mifh]

Ok,

jetzt packt mich der sportliche Ehrgeiz.
Mein fhem ist eine docker-Installation, ca 3 Monate alt. So lange ist wohl auch das letzte update her.
Und was die Anzahl der Module angeht:

Code Auswählen Erweitern

ms@srv1:~/docker/fhem-main/fhem-main$ awk '/define/ {print $3}' *.cfg| sort| uniq -c
      1 AlarmAnNF
      2 alexa
      2 AptToDate
    107 at
      2 autocreate
      2 autoload_undefined_devices
      2 CUL_HM
      7 DbLog
      2 DbRep
      4 define
      2 DockerImageInfo
     92 dummy
      1 eventTypes
     14 expandJSON
      2 FHEM2FHEM
      8 FHEMWEB
     26 FileLog
      1 FileLogConvert
      3 gassistant
      2 gcmsend
     37 GenShellSwitch
      2 gute
      2 holiday
      6 HourCounter
      6 HTTPMOD
      2 HTTPSRV
     29 HUEDevice
      2 InfluxDBLog
      2 Installer
      2 livetracking
      1 MilightBridge
      1 MilightDevice
     12 MQTT
      5 MQTT2_CLIENT
     78 MQTT2_DEVICE
     44 MQTT_BRIDGE
     97 MQTT_DEVICE
    127 notify
      2 npmjs
     15 pilight
      8 pilight_ctrl
      2 PROPLANTA
      2 RandomTimer
      5 readingsProxy
     22 SVG
      4 TASMOTA_DEVICE
      3 TelegramBot
      2 telnet
      1 tradfri
      2 Twilight
      2 weblink
      2 WeekdayTimer
      4 WifiLight
      2 Yeelight
      4 yowsup


Es sind sogar ~50 (so perfekt war mein awk-Skript wohl nicht).

Wie gesagt, vielen Dank für Deine Unterstützung. Es ist wirklich toll, einen Gesprächspartner zu haben und nicht alleine vor dem Problem zu sitzen. Danke sehr!

[Wernieman]

Ups .. viele der Module kenne ich gar nicht ...

Wobei natürlich at und dummy z.B. unkritisch ist.

Ist das der "offizielle FHEM-.Container"?

[Beta-User]

Und was die Anzahl der Module angeht:

fheminfo ist evtl. aufschlussreicher bei der Frage, was grade aktuell wirklich definiert ist. (Es gibt für CUL_HM-Nutzer dann noch eine gepatchte Variante hier: https://forum.fhem.de/index.php/topic,123298.msg1180984.html#msg1180984)

Grundsätzlich schaut das aus wie Kraut und Rüben, was du da an MQTT-Zeug aufgeführt hast, macht den Eindruck, wie wenn dir auf halbem Weg die Lust ausgegangen ist, alles auf MQTT2_DEVICE umzustellen.

MQTT_BRIDGE würde ich an deiner Stelle asap rauswerfen => MQTT_GENERIC_BRIDGE.

Just my2ct.

[rob]

Hallo mifh.

Influxdb via Docker habe ich auch im Einsatz. Per Watchtower erfolgen Updateprüfungen jeden Sonntag um 1Uhr. Liegt eins vor, wird der Container beendet, gelöscht, ein neuer Pull ausgeführt und neu gestartet - FHEM stört das nicht. Inzwischen bist ja schon auf das aktuelle Modul gewechselt. Ich meine, das dürfte nun geräuschlos laufen

Wenn ich Deinen Post richtig verstehe: beschreibst Du die Wirkungen. Die Ursache, warum die DB weg war, habe ich nicht rausgelesen. Ich würde deswegen nicht ganz so pessimistisch rangehen und allen Modulen tendenziell blockierendes Verhalten unterstellen. In aller Regel investieren Modulautoren viel Aufwand, um alles nonblocking hinzukriegen

Trotzdem kann es klar zu Problemen kommen aus verschiedensten Gründen. Ist imho selten - natürlich nach Murphys Law genau dann, wenn man nicht eingreifen kann.
Werniemans Anregung würde ich Dir dennoch ans Herz legen: als externes Monitoring verwende ich z.B. Prometheus. Influx + Docker überwache ich direkt und FHEM indirekt via Systemauslastung (Nodeexporter). Dadurch hast Du noch mehr im Blick, was nicht unbedingt mit FHEM zu tun haben muss z.B. IO-Errors uvm.
In Grafana lassen sich Alarme besonders einfach per Telegram versenden.

Weil in diesem Fall ein Restart ausreichte, hättest Du so die Chance entspr. Vorkehrungen für solche Fälle zu treffen z.B. Login via VPN oder watchdog etc. pp.
Wenn Du noch andere Ideen/ Vorkehrungen hast: ich lerne auch gern dazu und lass mich inspirieren 

Viele Grüße
rob

[mifh]

fheminfo ist evtl. aufschlussreicher bei der Frage, was grade aktuell wirklich definiert ist. (Es gibt für CUL_HM-Nutzer dann noch eine gepatchte Variante hier: https://forum.fhem.de/index.php/topic,123298.msg1180984.html#msg1180984)

Grundsätzlich schaut das aus wie Kraut und Rüben, was du da an MQTT-Zeug aufgeführt hast, macht den Eindruck, wie wenn dir auf halbem Weg die Lust ausgegangen ist, alles auf MQTT2_DEVICE umzustellen.

MQTT_BRIDGE würde ich an deiner Stelle asap rauswerfen => MQTT_GENERIC_BRIDGE.

Just my2ct.

Ertappt 
Ein Teil des Durcheinanders kommt daher, dass das awk-Skript nicht wirklich passt. fheminfo kannte ich nicht, das sieht schon besser aus:

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 25167
OS: linux
Perl: 5.28.1
uniqueId: 5e0...

Modules Model Count
AptToDate 1
DbLog
MYSQL 2
DockerImageInfo 1
FHEMWEB 4
FileLog 10
HTTPMOD 3
HTTPSRV 1
HUEDevice 8
TRADFRI bulb GU10 WS 400lm 6
TRADFRI on/off switch 1
TRADFRI SHORTCUT Button 1
TRADFRI control outlet 1
TRADFRI Driver 10W 1
TRADFRI bulb E14 WS opal 600lm 5
FLOALT panel WS 30x90 1
TRADFRI remote control 3
Remote Control N2 2
HourCounter 2
Installer 1
MQTT 2
MQTT2_CLIENT 3
MQTT2_DEVICE 12
SHSW-25 2
zigbee2mqtt_wireless_button_old 6
L_01_zigbee2mqtt_bridge 1
shelly1 3
tasmota_basic_state_power1 5
L_02a_zigbee2mqtt_bulb 6
zigbee2mqtt_light_cct 7
zigbee2mqtt_light_dimmer 1
zigbee2mqtt_Wireless_Button 5
zigbee2mqtt_TempHumSensor 6
MQTT_BRIDGE 23
MQTT_DEVICE 44
SVG 9
TASMOTA_DEVICE 4
TelegramBot 1
alexa 1
at 20
autocreate 1
dummy 42
expandJSON 7
gassistant 1
holiday 1
livetracking 1
notify 71
npmjs 1
readingsProxy 3
telnet 1
tradfri 1
weblink 1

In der Tat ist MQTT die Basis meines Smarthomes. Ein bisschen Homematic ist noch übrig, aber alles was neu ist, mache ich mit MQTT.

Ich hatte mit MQTT angefangen, bevor MQTT2 rauskam. Solange das alte MQTT-Modul noch läuft, habe ich nicht all zu viel Lust, ca. 60 Devices von Hand umzustellen. Wäre zwar auch eine Gelegenheit, mal aufzuräumen, aber es läuft ja. Warum rätst Du, die MQTT_BRIDGES zu ersetzen?

[mifh]

Influxdb via Docker habe ich auch im Einsatz. Per Watchtower erfolgen Updateprüfungen jeden Sonntag um 1Uhr. Liegt eins vor, wird der Container beendet, gelöscht, ein neuer Pull ausgeführt und neu gestartet - FHEM stört das nicht. Inzwischen bist ja schon auf das aktuelle Modul gewechselt. Ich meine, das dürfte nun geräuschlos laufen

Wenn ich Deinen Post richtig verstehe: beschreibst Du die Wirkungen. Die Ursache, warum die DB weg war, habe ich nicht rausgelesen. Ich würde deswegen nicht ganz so pessimistisch rangehen und allen Modulen tendenziell blockierendes Verhalten unterstellen. In aller Regel investieren Modulautoren viel Aufwand, um alles nonblocking hinzukriegen

Die DB war weg, weil die VM auf meinem NAS runtergefallen ist. Keine Ahnung warum, das habe ich noch nie beobachtet.

Ich will auch keinem Autor etwas unterstellen, schließlich nutze ich den ganzen Kram hier ja und profitiere von deren Arbeit. Und ich habe nun wirklich selbst genug fehlerhaftes Zeug in meiner Zeit als Entwickler erzeugt, da werfe ich bestimmt keine Steine auf andere.

Mir geht es um Folgendes: Dieses FHEM-System ist ein produktives System. Wenn das nicht läuft, gibt es kein Warmwasser und Teile der Beleuchtung funktionieren nicht mehr. Daher brauche ich eine gewisse Zuverlässigkeit, sonst kriege ich Ärger mit meiner Frau .Und ein Modul, dass diese Zuverlässigkeit nicht aufweist (weil es z.B. eine Exception schmeisst, die nicht abgefangen wird und das System komplett anhält oder die die Main-Loop so verstopft, dass nix mehr durchgeht) möchte lieber ich nicht einsetzen. Da suche ich mir dann lieber eine andere Lösung.

Ein gutes Monitoring ist ab einer gewissen Komplexität der System sinnvoll, da stimme ich Dir zu. Nur gibt es ja nix umsonst und ein Monitoring aufsetzen und zu pflegen, kostet auch Zeit. Und ob das für meine Systemumgebung nicht etwas überdimensioniert ist? Und letztlich kann man Monitoring auch nur auf bekannte Probleme schnell reagieren. Ich denke, da ist eine robuste Software einfach der bessere Weg.

Letztlich gibt es ja auch das neuere InfluxDB-Modul, ich denke, ich werde dem einfach mal eine Chance geben.

Ich würde gerne noch mal auf meine ursprüngliche Frage zurückkehren: hat man irgendwie eine Chance, ein blockierendes Modul zu erkennen, wenn es denn blockt? Schrittweises Auskommentieren ist zwar erfolgreich aber mühsam?

Wie sind eigentlich Deine Erfahrungen mit Auto-Updates über Watchtower? Ich habe schon Container erlebt, die nach einem Update nicht mehr funktionierten (was sogar in der Beschreibung im Hub angekündigt war). Ist halt blöd, wenn man sich damit ein System wegschießt. Daher mache ich das lieber manuell (mit all den Nachteilen, wenn man mehrere Versionen überspringt).

[Beta-User]

Warum rätst Du, die MQTT_BRIDGES zu ersetzen?

MQTT_BRIDGE ist (seit langem) deprecated und seit 6.1 dann auch nur noch in contrib.

MQTT_GENERIC_BRIDGE ist universeller,  von der Syntax her sehr ähnlich, und man kann es mit MQTT oder MQTT2_CLIENT als IO-Modul verwenden. (Fast) alle MQTT-relevanten Angaben werden da aber direkt beim "Zieldevice" gemacht, von daher ist es auch übersichtlicher.
Die Umstellung bei Gelegenheit verhindert daher Frust "irgendwann".

Ich hatte mit MQTT angefangen, bevor MQTT2 rauskam. Solange das alte MQTT-Modul noch läuft, habe ich nicht all zu viel Lust, ca. 60 Devices von Hand umzustellen. Wäre zwar auch eine Gelegenheit, mal aufzuräumen, aber es läuft ja.

Das alte IO-Modul wird m.E. noch lange funktionieren, das ist nicht das Thema. "Gefährlicher" sind externe Module wie TASMOTA_DEVICE - solche "Exoten" würde ich tendenziell auch beseitigen, und ob noch alle expandJSON-Instanzen erforderlich sind, kannst du dir auch mal ansehen (und v.a.: ob die ggf. was ins Log schreiben).

Das eilt ja nicht...


Blockierende Module kann man z.B. mit freezemon finden, das ist zumindest ein Indikator. Von den Modulen her sieht mir das aber im Moment eher ungefährlich aus, zumindest, wenn die Namensauflösung bei/für HTTPMOD optimiert ist.
Am besten mal den Stecker bei deinem Router ziehen und schauen, was passiert, wenn du "reread" ausführst (bzw. das ganze mal eine Zeitlang so lassen ).

[rob]

Wie sind eigentlich Deine Erfahrungen mit Auto-Updates über Watchtower?

Durchweg positiv. Natürlich ist meine Erfahrung nicht repräsentativ. Dafür gibt es zu viele Container/ Varianten. Und ja, man ist immer auf die Qualität vom "Hersteller" angewiesen
Folgende funktionieren 1A
- deConz/Phoscon
- Grafana
- Prometheus
- InfluxDB
- Nodeexporter
- owserver
- zigbee2mqtt

Per Telegram weiß ich immer, was aktualisiert wurde und ob es geklappt hat. Sonntags hätte ich dann auch Zeit, falls es mal hakt.

...da werfe ich bestimmt keine Steine auf andere.

Hätte ich auch garnicht so aufgefasst, sondern dass Du aufgrund der unschönen Auswirkung sehr vorsichtig geworden bist Wollte nur sagen, die gesteigerte Sorge ist nicht unbedingt nötig. Habe jetzt aber aufgrund der geschilderten Abhängigkeiten verstanden, dass Du für mehr Ausfallsicherheit sensibilisiert wurdest   


Für Interessierte: InfluxDB ist eine feine Sache, um performant Messungen Richtung z.B. Grafana zur Verfügung zu stellen.
Das Modul wird hier besprochen: https://forum.fhem.de/index.php/topic,114860.0.html Details/ Einsatzzweck etc. finden sich dort.

[mifh]

Hallo zusammen,

vielen Dank für die guten, sachdienlichen Hinweise. Es ist immer wieder klasse, was für gute Hinweise man hier bekommt.
FHEM wäre ohne dieses Forum mit diesen Mitgliedern deutlich ärmer dran.