NEWS
[gelöst] Fehler beim schreiben auf influxdb
-
Opened file {"log_id": "0hvK92MG000", "service": "storage-engine", "engine": "tsm1", "service": "filestore", "path": "/var/lib/influxdb2/engine/data/1bb9099d3b7c3e2b/autogen/4/000000007-000000002.tsm", "id": 0, "duration": "10.483ms"} 2023-05-20T13:06:39.732140Z info Opened shard {"log_id": "0hvK92MG000", "service": "storage-engine", "service": "store", "op_name": "tsdb_open", "index_version": "tsi1", "path": "/var/lib/influxdb2/engine/data/1bb9099d3b7c3e2b/autogen/4", "duration": "1615.077ms"} 2023-05-20T13:06:40.087887Z info loading changes (end) {"log_id": "0hvK92MG000", "service": "storage-engine", "engine": "tsm1", "op_name": "field indices", "op_event": "end", "op_elapsed": "899.816ms"} 2023-05-20T13:06:40.088551Z info Reading file {"log_id": "0hvK92MG000", "service": "storage-engine", "engine": "tsm1", "service": "cacheloader", "path": "/var/lib/influxdb2/engine/wal/7218bd3b5168e452/autogen/6/_00001.wal", "size": 1359140} 2023-05-20T13:06:40.675328Z info Opened shard {"log_id": "0hvK92MG000", "service": "storage-engine", "service": "store", "op_name": "tsdb_open", "index_version": "tsi1", "path": "/var/lib/influxdb2/engine/data/7218bd3b5168e452/autogen/6", "duration": "1510.816ms"} 2023-05-20T13:06:40.675775Z info Open store (end) {"log_id": "0hvK92MG000", "service": "storage-engine", "service": "store", "op_name": "tsdb_open", "op_event": "end", "op_elapsed": "4409.592ms"} 2023-05-20T13:06:40.675870Z info Starting retention policy enforcement service {"log_id": "0hvK92MG000", "service": "retention", "check_interval": "30m"} 2023-05-20T13:06:40.675935Z info Starting precreation service {"log_id": "0hvK92MG000", "service": "shard-precreation", "check_interval": "10m", "advance_period": "30m"} 2023-05-20T13:06:40.677588Z info Starting query controller {"log_id": "0hvK92MG000", "service": "storage-reads", "concurrency_quota": 1024, "initial_memory_bytes_quota_per_query": 9223372036854775807, "memory_bytes_quota_per_query": 9223372036854775807, "max_memory_bytes": 0, "queue_size": 1024} 2023-05-20T13:06:40.682348Z info Configuring InfluxQL statement executor (zeros indicate unlimited). {"log_id": "0hvK92MG000", "max_select_point": 0, "max_select_series": 0, "max_select_buckets": 0} 2023-05-20T13:06:42.173468Z info Starting {"log_id": "0hvK92MG000", "service": "telemetry", "interval": "8h"} 2023-05-20T13:06:42.218552Z info Listening {"log_id": "0hvK92MG000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086} 2023-05-20T13:20:43.289848Z warn internal error not returned to client {"log_id": "0hvK92MG000", "handler": "error_logger", "error": "context canceled"} 2023-05-20T13:20:43.296515Z warn internal error not returned to client {"log_id": "0hvK92MG000", "handler": "error_logger", "error": "context canceled"}kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
das warn internal error not returned könnte passen, aber die zeit passt nicht. da ist der unterschied zu groß
hab auch ein issue gefunden der passen könnte
https://github.com/influxdata/influxdb/issues/24055
allerdings geht es da um große datenmengen.
das schreiben eines datenpunkts ist jetzt wirklich kein großer act
daher könnte es schon sein, das genau zu diesem zeitpunkt die hostmaschine gut ausgelastet ist.
wann läuft dein backup von iobroker oder eines anderen containers?aber du kannst mal schauen ob man am adapter irgendwo den timeout anpassen kann.
-
kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
das warn internal error not returned könnte passen, aber die zeit passt nicht. da ist der unterschied zu groß
hab auch ein issue gefunden der passen könnte
https://github.com/influxdata/influxdb/issues/24055
allerdings geht es da um große datenmengen.
das schreiben eines datenpunkts ist jetzt wirklich kein großer act
daher könnte es schon sein, das genau zu diesem zeitpunkt die hostmaschine gut ausgelastet ist.
wann läuft dein backup von iobroker oder eines anderen containers?aber du kannst mal schauen ob man am adapter irgendwo den timeout anpassen kann.
@oliverio sagte in Fehler beim schreiben auf influxdb:
kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
wie genau mache ich das? :-)
Das Backup läuft nachts um 3 Uhr. Also daran kann es nicht gelegen haben.
-
@oliverio sagte in Fehler beim schreiben auf influxdb:
kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
wie genau mache ich das? :-)
Das Backup läuft nachts um 3 Uhr. Also daran kann es nicht gelegen haben.
docker oder portainer?
shell öffnen und dann den date befehl ausführen
shell öffnen mit docker:
docker exec -it <container name> /bin/bashshell öffnen mit portainer
den container auswählen und dann link zu console
und console öffnen -
@oliverio sagte in Fehler beim schreiben auf influxdb:
kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
wie genau mache ich das? :-)
Das Backup läuft nachts um 3 Uhr. Also daran kann es nicht gelegen haben.
-
@oliverio sagte in Fehler beim schreiben auf influxdb:
kannst du bitte mal schauen ob die uhren in beiden containern gleich laufen? also die minuten reichen aus.
wie genau mache ich das? :-)
Das Backup läuft nachts um 3 Uhr. Also daran kann es nicht gelegen haben.
ich dachte ich habe es schon geschrieben, was du auch noch untersuchen kannst:
ist es immer um die ähnliche uhrzeit wo der fehler auftritt?
ggfs. musst du mal eine kontinuierliche leistungsaufzeichnung starten.
dein screenshot ist ja nur eine momentaufnahme und zeigt bspw nicht die auslastung zu höchstzeiten an.
auch kannst mal deine skripte prüfen, ob es da welche gibt die um die besagten uhrzeiten irgendwas größeres machen. kann ja auch ein skriptfehler sein, der die ressourcen (cpu, ram, netzkapazität) überbeansprucht auch wenn scheinbar genug da sind.
oder auch bspw ein jdownloader der cpu und/oder netz zumacht -
ich dachte ich habe es schon geschrieben, was du auch noch untersuchen kannst:
ist es immer um die ähnliche uhrzeit wo der fehler auftritt?
ggfs. musst du mal eine kontinuierliche leistungsaufzeichnung starten.
dein screenshot ist ja nur eine momentaufnahme und zeigt bspw nicht die auslastung zu höchstzeiten an.
auch kannst mal deine skripte prüfen, ob es da welche gibt die um die besagten uhrzeiten irgendwas größeres machen. kann ja auch ein skriptfehler sein, der die ressourcen (cpu, ram, netzkapazität) überbeansprucht auch wenn scheinbar genug da sind.
oder auch bspw ein jdownloader der cpu und/oder netz zumacht -
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen mussMeine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen muss -
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen muss@oliverio sagte in Fehler beim schreiben auf influxdb:
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen mussMoin,
sorry Fußball ;)
Wie sieht es denn aktuell aus, nach den Neustarts? Ist es aktuell ruhig?
Und am besten wie @OliverIO schon schrieb, Langzeitmonitoring, von CPU, RAM, Netzwerk machen.
Welche Hardware setzt Du denn ein, NAS, oder Bare Metal?Eine Minute Zeitdifferenz finde ich schon viel, dafür, dass die beiden auf der gleichen Maschine laufen.
VG
Bernd -
@oliverio sagte in Fehler beim schreiben auf influxdb:
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen mussMoin,
sorry Fußball ;)
Wie sieht es denn aktuell aus, nach den Neustarts? Ist es aktuell ruhig?
Und am besten wie @OliverIO schon schrieb, Langzeitmonitoring, von CPU, RAM, Netzwerk machen.
Welche Hardware setzt Du denn ein, NAS, oder Bare Metal?Eine Minute Zeitdifferenz finde ich schon viel, dafür, dass die beiden auf der gleichen Maschine laufen.
VG
Berndkein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
-
-
Ne
UTC ist Zeitzone 0. so wie England, Greenwich Zeit
D ist eine Zone weiter und dann kommt noch die Sommerzeit =CEST central european summtet TimeAber die eine Minute erklärt leider nicht,
Entweder das Nicht vorkommen im log
Oder der Zeitunterschied von ca 35 Minuten
Der log EreignisseMeine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
@dp20eic Wie passe ich es denn an und sind es jetzt 2 stunden?
die minuten und sekunden sind fast gleich. der versatz kam nur durch unterschiedliche eingaben -
Ne
UTC ist Zeitzone 0. so wie England, Greenwich Zeit
D ist eine Zone weiter und dann kommt noch die Sommerzeit =CEST central european summtet TimeAber die eine Minute erklärt leider nicht,
Entweder das Nicht vorkommen im log
Oder der Zeitunterschied von ca 35 Minuten
Der log Ereignisse -
Ne
UTC ist Zeitzone 0. so wie England, Greenwich Zeit
D ist eine Zone weiter und dann kommt noch die Sommerzeit =CEST central european summtet TimeAber die eine Minute erklärt leider nicht,
Entweder das Nicht vorkommen im log
Oder der Zeitunterschied von ca 35 Minuten
Der log Ereignisse@oliverio sagte in Fehler beim schreiben auf influxdb:
UTC ist Zeitzone 0. so wie England, Greenwich Zeit
D ist eine Zone weiter und dann kommt noch die Sommerzeit =CEST central european summtet Timedas ist mir klar, aber dann sind (nur) die Zeitzonen falsch?
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@ben1983 sagte in Fehler beim schreiben auf influxdb:
@oliverio welche 35 min?
Moin,
im ersten Post, das Log vom
ioBrokerwar von 15:07Uhr, die Logs vominfluxDBDocker aber von ~15:30Uhr.VG
Bernd -
@oliverio sagte in Fehler beim schreiben auf influxdb:
UTC ist Zeitzone 0. so wie England, Greenwich Zeit
D ist eine Zone weiter und dann kommt noch die Sommerzeit =CEST central european summtet Timedas ist mir klar, aber dann sind (nur) die Zeitzonen falsch?
@homoran sagte in Fehler beim schreiben auf influxdb:
das ist mir klar, aber dann sind (nur) die Zeitzonen falsch?
Nicht falsch, evtl Optimierungfähig
Die zeitreferenz ist ja schon identisch(bis auf die eine Minute)
Da das aber für die Funktionsfähigkeit von influx nicht relevant ist muss es nicht geändert werden.
Manche docker Autoren bieten an die Zeitzone als Environment Parameter mitzugeben.Aber wie gesagt hier irrelevant. Ja beim log prüfen müssen wir einen Tick mehr überlegen.
Die Zeit wird ja intern immer in ms seit 1970 gespeichert. Jegliche Anzeige wird immer anhand der eingestellten locale und Zeitzone berechnet,
Also nix mit was wir hier Anfänger noch belasten müssenBei Systemen die nah am Anwender sind sollte man es schon korrekt einstellen. Ist hier ja auch so der Fall
-
Ergänzung zur Zeitzone
https://stackoverflow.com/questions/57620589/docker-influxdb-runs-in-utc-timezone
Also das mit utc ist Absicht von den influx Leuten
-
@ben1983 sagte in Fehler beim schreiben auf influxdb:
@oliverio welche 35 min?
Moin,
im ersten Post, das Log vom
ioBrokerwar von 15:07Uhr, die Logs vominfluxDBDocker aber von ~15:30Uhr.VG
Bernd
Support us
291
Online32.6k
Benutzer82.3k
Themen1.3m
Beiträge