[vz-users] Puffer vzlogger

[Daniel Lauckner]

Gut's neu's,


am Mittwoch, 30. Dezember 2020 um 18:02 hat Thomas Höpfner geschrieben:
>> Wenn nicht mal ein Blick ins Log werfen.
> Das ist ein Problem. Ich möchte kein log auf die SD schreiben.

Dazu muss das Log nicht auf Platte geschrieben sein. Die Datei kann man 
(z.B. mit cat) auch anzeigen lassen während vzlogger läuft.

> Aktuell ist verbosity =3.

Dann hast du ja ein Log in das man schauen könnte. Fehlende Verbindung 
ist ein kritischer Fehler der auch bei Loglevel 0 auftaucht.

> Dann war ich wahrscheinlich zu ungeduldig. 

Ich hab gerade ein System bei dem die WLAN-Verbindung schlechter 
geworden ist. Ich schätze da steckten 160000 Datensätze im Queue fest.
Ich hab noch nicht alle in der MW weil die Verbindung nur sporadisch 
gut genug ist, von daher kann ich leider nicht genauer sagen wie lange 
es dauert bis so ein Puffer wieder geleert ist. Habe aber auch den 
Eindruck das es mit der Aggtime zusammenhängt, dann wäre meine 
Beobachtung eh nicht universell gültig.

> Bleibt meine Frage welche Grenzen es gibt

Ich schätze die fehlende Antwort ist Antwort genug?

Hab's leider verpasst zu Beginn zu schauen wie viel RAM von vzlogger 
belegt war. Als ich top aufrief schätze ich die Hälfte der Daten war 
in der MW gelandet, da belegte vzlogger auf einem Rpi B 4% Speicher.

> und ob mann irgendwie
> sehen kann was noch nicht übertragen ist.

Nicht direkt. Was im Puffer steckt wird in hohen verbosity (10+ ?) ins 
Log geschrieben, das hat man bei laufendem System aber üblicherweise 
schon Richtung 0 gestellt. Also keine Hilfe.

Die Erfahrung zeigt aber: vzlogger betreibt streng FiFo. Die alten 
Daten werden zuerst abgeliefert. Gibt es im Frontend eine Lücke zu 
&to=now stecken die Daten hoffentlich noch im vzlogger fest.
Wobei in Bezug auf UUID keine Reihenfolge gilt, die Daten werden 
parallel abgearbeitet. Aber nicht gleichmäßig.

Für alle anderen Lücken gilt: Sind jüngere Daten vorhanden ist da auch 
nix mehr im vzlogger.


mfg Daniel