[gelöst] Fehler beim schreiben auf influxdb
-
@dp20eic der Verbraucht gerade nur 108MB. Ist unbegrenzt
-
jetzt braucht man nur noch den richtigen zeitpunkt
2023-05-20 15:07:26.817 -
@oliverio sagte in Fehler beim schreiben auf influxdb:
jetzt braucht man nur noch den richtigen zeitpunkt
2023-05-20 15:07:26.817Moin,
ist UTC 2023-05-20T13:31:09.637615Z + 2 sollte dann 15:31Uhr
VG
Bernd -
@dp20eic
dann startet es 15:21
wir benötigen aber 15:07
also das vorgänger log wahrscheinlich,
je nachdem wie oft neugestartet wurdefalls da auch nicht viel drin steht, dann das loglevel erhöhen, sollte aber schon
-
@ben1983 sagte in Fehler beim schreiben auf influxdb:
2023-05-20T13:30:14.998921Z warn internal error not returned to client {"log_id": "0hvKzKT0000", "handler": "error_logger", "error": "context canceled"}
2023-05-20T13:30:35.214408Z warn internal error not returned to client {"log_id": "0hvKzKT0000", "handler": "error_logger", "error": "context canceled"}Moin,
schau mal hier https://community.influxdata.com/t/execution-of-heavy-queries-result-in-a-crash/22637 da steht einiges, lese aber auch erst noch.
VG
Bernd -
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.
-
@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 -
@ben1983 sagte in Fehler beim schreiben auf influxdb:
Das Backup läuft nachts um 3 Uhr. Also daran kann es nicht gelegen haben
nachts oder nachmittags? am oder pm
der Fehler trat 15:07 auf -
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 -
@oliverio Es war heute das erste mal .... es läuft seit ca. 7 Wochen
-
dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen muss -
@oliverio das kommt raus:
root@buanet-iobroker:/opt/iobroker# date Sa 20. Mai 20:17:24 CEST 2023 root@buanet-iobroker:/opt/iobroker#root@influxdb:/# date Sat May 20 18:18:22 UTC 2023 -
@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 -
-
-
@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 -
@ben1983
Nein nix anpassen, die Zeitzonen sind egal
Es sind docker Container
Da kannst du nicht so einfach anpassen
Ist auch nicht wirklich notwendigZum synced mit dem host kannst du als volume das eintragen
-v /etc/localtime:/etc/localtime:ro
