Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Ein ehemaliger Benutzer]

@oliverio sagte in Fehler beim schreiben auf influxdb:

@ben1983

jetzt braucht man nur noch den richtigen zeitpunkt
2023-05-20 15:07:26.817

Moin,

ist UTC 2023-05-20T13:31:09.637615Z + 2 sollte dann 15:31Uhr

VG
Bernd

[OliverIO]

@dp20eic
dann startet es 15:21
wir benötigen aber 15:07
also das vorgänger log wahrscheinlich,
je nachdem wie oft neugestartet wurde

falls da auch nicht viel drin steht, dann das loglevel erhöhen, sollte aber schon

[Ein ehemaliger Benutzer]

@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

[Ben1983]

@oliverio

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"}

[OliverIO]

@ben1983

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.

[Ben1983]

@oliverio sagte in Fehler beim schreiben auf influxdb:

@ben1983

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]

@ben1983

docker oder portainer?

shell öffnen und dann den date befehl ausführen

shell öffnen mit docker:
docker exec -it <container name> /bin/bash

shell öffnen mit portainer
den container auswählen und dann link zu console
und console öffnen

[OliverIO]

@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

[OliverIO]

@ben1983

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

[Ben1983]

@oliverio Es war heute das erste mal .... es läuft seit ca. 7 Wochen

[OliverIO]

@ben1983

dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen muss

[Ben1983]

@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                                                                                                             

[Ein ehemaliger Benutzer]

@oliverio sagte in Fehler beim schreiben auf influxdb:

@ben1983

dann weiter beobachten.
aber das mit der uhrzeit noch prüfen, damit man in zukunft nicht nochmal suchen muss

Moin,

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

[Homoran]

@dp20eic sagte in Fehler beim schreiben auf influxdb:

Eine Minute Zeitdifferenz

zwei Stunden!

[Ein ehemaliger Benutzer]

@homoran

Moin,

CEST und UTC, ja ist etwas daneben, sollte man mal angleichen.

VG
Bernd

[Ben1983]

@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

[OliverIO]

@homoran

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 Time

Aber die eine Minute erklärt leider nicht,
Entweder das Nicht vorkommen im log
Oder der Zeitunterschied von ca 35 Minuten
Der log Ereignisse

[OliverIO]

@ben1983
Nein nix anpassen, die Zeitzonen sind egal
Es sind docker Container
Da kannst du nicht so einfach anpassen
Ist auch nicht wirklich notwendig

Zum synced mit dem host kannst du als volume das eintragen
-v /etc/localtime:/etc/localtime:ro

[Ben1983]

@oliverio welche 35 min?

[Homoran]

@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 Time

das ist mir klar, aber dann sind (nur) die Zeitzonen falsch?