Hallo Matthias,
du kannst das mit der Begrenzung auf meinem Wolf bitte gerne einrichten.
Beste Grüße
Jens
NEU! UPGRADE IP 10 verfügbar!
Timberwolf VISU jetzt mit Graphic V Upgrade
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074
NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
Timberwolf VISU jetzt mit Graphic V Upgrade
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074
NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[Problem] [V1.5.3] "unable to retrieve container logs" nach Update
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
blaubaerli
- Reactions:
- Beiträge: 2322
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 894 Mal
- Danksagung erhalten: 700 Mal
-
blaubaerli
- Reactions:
- Beiträge: 2322
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 894 Mal
- Danksagung erhalten: 700 Mal
Hallo Matthias (@ms20de),
hast du hier schon etwas erreichen können?
Beste Grüße
Jens
hast du hier schon etwas erreichen können?
Beste Grüße
Jens
-
blaubaerli
- Reactions:
- Beiträge: 2322
- Registriert: Sa Sep 15, 2018 10:26 am
- Wohnort: Kerpen
- Hat sich bedankt: 894 Mal
- Danksagung erhalten: 700 Mal
Hallo zusammen,
nachdem das ja hier noch ein wenig in der Luft hing.....
Ich hatte mich gewundert, woher diese Unmengen an Loginfos plötzlich kommen sollten.... Da ich mir die aber auch nicht ansehen konnte, habe ich den Container dann einfach mal neu deployed. Damit ware die alten Logs zwar alle weg, aber ich hatte wieder Zugriff auf die Loganzeige und habe dann jede Menge Einträge gesehen, die nicht nativ aus meinem eigenen Plugincode geschrieben wurden.
Im Rahmen eines anderen Problems hatte ich jedoch in Zusammenspiel mit den Kollegen der EalbNET die Log- und Tracelevel in der plugins.conf umkonfiguriert. Das erzeugte dann ungewohnt viel Logoutput und produzierte schließlich hier die enormen Logmengen.
Ursprünglich dachte ich, dass man die Größe des Ringpuffers für die Loginformationen durch das Setzen des "Lines"-Parameters hier:
selbst beeinfluss kann. Aber das scheint in der Tat nur die Einstellung für den eigentlichen "Log viewer" zu sein. Ich verstehe aktuell die Ursache des Problems damit aber immer noch nicht ganz. Matthias hat im Post 10 signalisiert, dass das ein Timing Problem sei. Auf der anderen Seite sieht es auch nach einem Problem mit der Größe des tatsächlich geschriebenen Logfiles aus.
Bei den Linux-Systemen mit denen ich im Alltag zu schaffen habe, ist das mit der Anzeige der letzten n Zeilen eines Logfiles üblicherweise was für das Kommando "tail". Da habe ich aber solche massiven Performance-Differenzen auch bei extrem großen Logfiles noch nicht erlebt.
Ist das ggf. noch ein Thema der Implementierung bei portainer?
Egal wie ich den Tracelevel ja nun eingestellt habe, dann ist das ja nun nur ein Problem der Zeit bis das Log wieder soooooo voll ist und dann das Thema von vorne beginnt, oder?
Beste Grüße
Jens
nachdem das ja hier noch ein wenig in der Luft hing.....
Ich hatte mich gewundert, woher diese Unmengen an Loginfos plötzlich kommen sollten.... Da ich mir die aber auch nicht ansehen konnte, habe ich den Container dann einfach mal neu deployed. Damit ware die alten Logs zwar alle weg, aber ich hatte wieder Zugriff auf die Loganzeige und habe dann jede Menge Einträge gesehen, die nicht nativ aus meinem eigenen Plugincode geschrieben wurden.
Im Rahmen eines anderen Problems hatte ich jedoch in Zusammenspiel mit den Kollegen der EalbNET die Log- und Tracelevel in der plugins.conf umkonfiguriert. Das erzeugte dann ungewohnt viel Logoutput und produzierte schließlich hier die enormen Logmengen.
Ursprünglich dachte ich, dass man die Größe des Ringpuffers für die Loginformationen durch das Setzen des "Lines"-Parameters hier:
selbst beeinfluss kann. Aber das scheint in der Tat nur die Einstellung für den eigentlichen "Log viewer" zu sein. Ich verstehe aktuell die Ursache des Problems damit aber immer noch nicht ganz. Matthias hat im Post 10 signalisiert, dass das ein Timing Problem sei. Auf der anderen Seite sieht es auch nach einem Problem mit der Größe des tatsächlich geschriebenen Logfiles aus.
Bei den Linux-Systemen mit denen ich im Alltag zu schaffen habe, ist das mit der Anzeige der letzten n Zeilen eines Logfiles üblicherweise was für das Kommando "tail". Da habe ich aber solche massiven Performance-Differenzen auch bei extrem großen Logfiles noch nicht erlebt.
Ist das ggf. noch ein Thema der Implementierung bei portainer?
Egal wie ich den Tracelevel ja nun eingestellt habe, dann ist das ja nun nur ein Problem der Zeit bis das Log wieder soooooo voll ist und dann das Thema von vorne beginnt, oder?
Beste Grüße
Jens