"Warn" Logeinträge InfluxDB-Adapter
-
Hallo Zusammen,
mir werden im Influx-DB-Adapter folgende Logs angezeigt:
influxdb.0 98056 2023-03-06 10:40:04.668 warn Error in query "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)": RequestTimedOutError: Request timed outWo kann der Fehler liegen?
Danke schon mal
-
Moin,
Du gehst auch mit Informationen sehr Sparrsam um
Ich habe noch nie gesehen, dass im Log File des
iobroker influxdb Adapterseine Warnung bezüglich einer Flux (Abfragesprache voninfluxdb V2.x) auftaucht.Du hast irgendwo, schätze in
Grafanaeine Query am Laufen, die auf ein Time out stößt.Query: 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)Error: RequestTimedOutError: Request timed outAlso ohne genau zu sagen, was Du wie machst, kann Dir hier wohl keiner helfen.
VG
BerndEdit*
das hier beherzigen https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge -
@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. -
@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, ... -
@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 -
@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.
-
@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?
-
@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:
-
@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.
-
@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
-
@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.
-
@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.
-
@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.
-
@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.
-
@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. -
@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.
-
@blacksheep587
Du könntest mal das böse Query in das userinterface von Influx eingeben und schauen, was passiertfrom(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. -
@ostfrieseunterwegs Hat er doch schon (siehe oben) und die Ausführung hat ~53 Sek gedauert.
-
@blacksheep587 sagte in "Warn" Logeinträge InfluxDB-Adapter:
Naja erstmal nichts, außer dass beide Programme auf die InfluxDB zugreifen.
Moin,
auch
influxDBist ein 3rd Party Produkt und hat nur indirekt etwas mit demioBrokerzu tun.Ich würde Dir raten, die
influxDBnicht auf demselben System zu betreiben, auf dem auchioBrokerläuft und wie oben schon gesagt wurde, reduziere die Daten.VG
Bernd -
@haus-automatisierung Stimmt wohl.
Wenn das Query so von Flot generiert wird, kann man wohl nichts machen.
