"Warn" Logeinträge InfluxDB-Adapter

[blacksheep587]

@dp20eic said in "Warn" Logeinträge InfluxDB-Adapter:

Du hast irgendwo, schätze in Grafana eine Query am Laufen, die auf ein Time out stößt.

Ich denke im FLOT-Adapter. Hier habe ich eine Abfrage auf die Datenbank.
In Grafana greife ich aber auch diese Daten ab.
Ich habe erst umgestellt von SQL auf Influx, und es läuft noch nicht so rund.

[haus-automatisierung]

@dp20eic sagte in "Warn" Logeinträge InfluxDB-Adapter:

Du hast irgendwo, schätze in Grafana eine Query am Laufen, die auf ein Time out stößt.

Und wie soll die Meldung dann im Adapter vom ioBroker landen?

Ich nehme an, dass irgendwo im ioBroker das Statement zusammengebaut wird. Und dass Du so viele Daten hast (keine Retention Time festgelegt?), dass das zu lange dauert und einen Timeout liefert. 2 Jahre sind ja schon ... viel. Gerade bei der aktuellen PV-Leistung wird ja sicher öfter etwas geschrieben.

Insgesamt ist das Statement aber nicht besonders schön gebaut. Da müsste man mal gucken woher das kommt. Alle Daten abzurufen, dann andersrum zu sortieren und nur einen Wert zu holen ist ja extrem ineffizient. Besser wäre last().

Ich denke mal, da wird irgend ein anderer Adapter getHistory() aufrufen und daraus das Statement gebaut. Das könnte der Admin-Adapter sein, FLOT, eCharts, ...

[A Former User]

@haus-automatisierung sagte in "Warn" Logeinträge InfluxDB-Adapter:

Und wie soll die Meldung dann im Adapter vom ioBroker landen?

Moin,

das war ja mein ansinnen, mit nur so wenig Informationen und einer Zeile Log, kann mal nicht helfen, wenn dort gleich gestanden hätte, dass es um eChart, FLOT geht, dann hätte ich mich gleich still verhalten, weil keine Ahnung

VG
Bernd

[Homoran]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Ich denke im FLOT-Adapter. Hier habe ich eine Abfrage auf die Datenbank.
In Grafana greife ich aber auch diese Daten ab.

dass Flot Warnung von Queries generiert wäre mir neu (aber nicht auszuschließen).

Wie mehrfach gesagt: es braucht mehr Informationen, insbesondere wenn auch noch Grafana im Spiel ist.

Bitte systematisch vorgehen, u.a.

• mögliche Ursachen getrennt abschalten
• beteiligte Instanzen auf Logstufe debug schalten
• versuchen die Meldung zu provozieren.

[haus-automatisierung]

@homoran sagte in "Warn" Logeinträge InfluxDB-Adapter:

dass Flot Warnung von Queries generiert wäre mir neu (aber nicht auszuschließen).

Naja Flot wird einfach nur getHistory gegen den InfluxDB-Adapter aufrufen. Und läuft dann wegen sehr vielen Daten in einen Timeout. Wobei das schon extrem viel sein muss, wenn die 30 Sekunden im Standard erreicht werden. Oder wurde da etwas anderes konfiguriert?

[blacksheep587]

@haus-automatisierung Ne, iobroker hat mir angeboten, das Timeout auf 60s zu verlängern; "eine langsame Verbindung wurde erkannt"
Ich habe aber ohnehin seit der Installation von InfluxDB Probleme mit meinem System. Wenn ich in der InfluxDB arbeiten will, oder Daten abrufen, dann geht der Raspberry in die Knie.
Ich hatte bei der Blockzeit bis dato 0 drin stehen und habe dann manuell auf 5000ms gestellt um die Datenmengen zu reduzieren.
Im Masterkurs hatte ich ja gefragt, wegen der großen Datenmengen und dem Migrationsskript. Vielleicht muss ich meine Datenbanken nochmal komplett löschen?!

"Warn" Logeinträge InfluxDB-Adapter:

Insgesamt ist das Statement aber nicht besonders schön gebaut. Da müsste man mal gucken woher das kommt. Alle Daten abzurufen, dann andersrum zu sortieren und nur einen Wert zu holen ist ja extrem ineffizient. Besser wäre last().

Kann ich das standardmäßig irgendwo konfigurieren, dass ich last() drinstehen hab? ich habe das in Grafana jetzt immer erst "per Hand" umgeschrieben.

@Homoran Die Meldung kann ich provozieren, wenn ich in Flot von sql auf influx umstelle:

[haus-automatisierung]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Ne, iobroker hat mir angeboten, das Timeout auf 60s zu verlängern

Das war aber der Admin-Adaper und nicht der InfluxDB-Adapter

Du kannst das Statement von oben ja mal kopieren und manuell im Data Explorer von InfluxDb ausführen. Dann siehst Du wie lange es braucht um ein Ergebnis zu liefern.

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Im Masterkurs hatte ich ja gefragt, wegen der großen Datenmengen und dem Migrationsskript.

Ja, und darauf hatte ich geantwortet, dass man die Daten ggf. während der Migration direkt aggrieren sollte, wenn es sehr viele sind. Würde sich ja anbieten nur den Durchschnitt oder den Maximalwert alle x Minuten zu behalten.

[blacksheep587]

@haus-automatisierung said in "Warn" Logeinträge InfluxDB-Adapter:

Ja, und darauf hatte ich geantwortet, dass man die Daten ggf. während der Migration direkt aggrieren sollte, wenn es sehr viele sind. Würde sich ja anbieten nur den Durchschnitt oder den Maximalwert alle x Minuten zu behalten.

Meine trivialen Fragen zeigen dir, dass das meine aktuelle Kompetenz überschreitet

[blacksheep587]

@haus-automatisierung said in "Warn" Logeinträge InfluxDB-Adapter:

Dann siehst Du wie lange es braucht um ein Ergebnis zu liefern.

52,53Sekunden. Ein nochmaliges Aufrufen der Daten habe ich nach 2min abgebrochen.

[haus-automatisierung]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

52,53Sekunden.

Okay, und das ist mindestens 50 Sekunden zu viel. Die Frage wäre, wo man hier am besten ansetzt. Was genau möchtest du denn in flot wissen? Klingt irgendwie ziemlich unnötig, dass der gesamte Zeitraum von 2 Jahren geladen wird, nur um den letzten Wert zu holen.

Also entweder ein "Bug" im InfluxDB-Adapter (ineffizienter Query) oder Optimierungspotenzial von flot.

[blacksheep587]

@haus-automatisierung said in "Warn" Logeinträge InfluxDB-Adapter:

Also entweder ein "Bug" im InfluxDB-Adapter (ineffizienter Query)

Ich tippe auf Bug, weil auch mit der Standardabfrage in InfluxDB hat sich der Raspberry grad aufgehängt.
Du siehst im Flot-Graph auch die Logging-Ausfälle durch den Datenbank-Zugriff
Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

Aktuell visualisiere ich meine PV Anlage und diverse Messwerte in- und um das Haus.

[haus-automatisierung]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

Flot wird (soweit ich weiß) auch nicht mehr weiter entwickelt. eCharts die Ablösung dafür innerhalb von ioBroker. Klar, mit Grafana kannst Du noch mehr machen - musst aber auch mehr wissen und können.

[Homoran]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

was hat das miteinander zu tun?
Grafana hat nichts mit ioBroker zu tun. Das ist ein professionelles 3rd Party Programm.

[blacksheep587]

@haus-automatisierung said in "Warn" Logeinträge InfluxDB-Adapter:

Flot wird (soweit ich weiß) auch nicht mehr weiter entwickelt. eCharts die Ablösung dafür innerhalb von ioBroker. Klar, mit Grafana kannst Du noch mehr machen - musst aber auch mehr wissen und können.

Okay, gute Info bzgl. Flot.

Die deutlich höhere Komplexität von Grafana ist mir bewusst, es gibt aber auch sehr viel Input im Netz, die meine Usecases gut abdecken.
Mein Problem bleibt aber scheinbar weiterhin meine Datenbank. Wie beschrieben, geht beim Datenabgriff mein komplettes System in die Knie. Jetzt wäre meine Frage: Wie kann ich mehr Input liefern, um den Root Cause zu ermitteln? Die Installation habe ich nach "Masterkurs" durchgeführt, die Migration der Daten habe ich nach einem Versuch sein lassen.

@homoran said in "Warn" Logeinträge InfluxDB-Adapter:

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Flot soll eigentlich sterben, da Grafana deutlich mehr Möglichkeiten hat.

was hat das miteinander zu tun?
Grafana hat nichts mit ioBroker zu tun. Das ist ein professionelles 3rd Party Programm.

Naja erstmal nichts, außer dass beide Programme auf die InfluxDB zugreifen.

[OstfrieseUnterwegs]

@blacksheep587
Du könntest mal das böse Query in das userinterface von Influx eingeben und schauen, was passiert

from(bucket: "iobroker_data") 
    |> range(start: 2021-03-05T23:00:00.000Z, stop: 2023-03-05T22:59:59.999Z) 
    |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Photovoltaik.DC-Leistung_gesamt") 
    |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") 
    |> group() |> sort(columns: ["_time"], desc: true) 
    |> limit(n: 1)

von oben kopiert...
Das Pivot könnte influx in die Knie zwingen.

[haus-automatisierung]

@ostfrieseunterwegs Hat er doch schon (siehe oben) und die Ausführung hat ~53 Sek gedauert.

[A Former User]

@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:

Naja erstmal nichts, außer dass beide Programme auf die InfluxDB zugreifen.

Moin,

auch influxDB ist ein 3rd Party Produkt und hat nur indirekt etwas mit dem ioBroker zu tun.

Ich würde Dir raten, die influxDB nicht auf demselben System zu betreiben, auf dem auch ioBroker läuft und wie oben schon gesagt wurde, reduziere die Daten.

VG
Bernd

[OstfrieseUnterwegs]

@haus-automatisierung Stimmt wohl.
Wenn das Query so von Flot generiert wird, kann man wohl nichts machen.

[haus-automatisierung]

@ostfrieseunterwegs Naja, man könnte jetzt schauen warum der Flot-Adapter den gesamten Zeitraum von 2 Jahren abfragt, nur um den letzten Wert zu holen (Bug im Flot-Adapter ?) oder den Aufbau des Statements im InfluxDB Adapter in getHistory ändern, sodass das Statement performanter aufgebaut wird.

[OstfrieseUnterwegs]

@haus-automatisierung Ja genau, aber das ist wahrscheinlich nichts, was wir end-user machen können. Das müsste jemand analysieren, der den Adapter kennt. So, wie in diesem Fall, wenn nur ein Attribut geholt wird, scheint mir das Pivot überflüssig zu sein. Auch beim Schreiben nach influxdb wird meiner Meinung nach nicht unbedingt das Optimale herausgeholt. Führt in diesem Thread aber zuweit.