Das Problem tritt bei uns auch seit 2.1.0p9 auf (haben kürzlich von 2.0.0p26 aktualisiert).
Derzeit sind Server und Client auf Stand 2.1.0p10.
Spiele demnächst 2.1.0p11 ein. Schreibe danach nochmal ob das Problem behoben ist. In den Werks steht dazu aber nichts.
Es scheint am Agent zu liegen.
Ich habe die produktive Site auf p10, die dazu passende alte Kopie auf p3 und eine neue Test Site mit p11. Der Agent ist immer p10.
Ich habe noch eine neue Test Site mit p3 erstellt, weil mit der alten Kopie keine Agents mehr erzeugt werden können und ich keine Lust auf Fehler suche habe.
Wenn ich den p3 Agent jetzt wieder auf einem PC installiere, klappt es auf allen Sites.
Der Output des Agents ist auch minimal anders:
<<<logwatch>>>
[[[c:\temp\logtest.log]]]
C Kritisch 3333
W Warnung 11111
C Kritisch 2255
W Warnung 11111
C Kritisch 2222
Hi,
das mag den Output erklären, aber nicht das die Checks der Logfiles nicht mehr im Monitoring erscheinen.
Jemand eine Idee, ohne jetzt ältere Agents installieren zu müssen?
@sebkir nur scheint es niemand dem Check auf dem Server mitgeteilt zuhaben
Auch wenn es etwas traurig ist das wir heutzutage noch auf einen textbasierten Logfile Check unter Windows angewiesen sind, aber wir sind es. Wir haben fast 300 Windows-Devices auf denen wir Logfiles auf diese Art monitoren.
@sebkir im derzeitigen Zustand ist mk_logwatch unter Windows komplett kaputt. Das ist schon ein arg trauriger Zustand was vor allem das Thema Qualitätskontrolle angeht bevor etwas released wird.
Ach kommt, es hat sich doch schon sauviel verbessert, was die Release Prozesse angeht. Natuerlich sollte das trotzdem mit nem realistischen Testszenario auffallen, natuerlich gibt’s noch nervige Sachen, aber ich finde es gut zu wissen, dass es zwar noch offene Stellen gibt, aber das Gesamtsystem heute so viel mehr Tests durchlaeuft.
Ehrlich gesagt - stört mich hier in dem Fall mehr das es halt 0 Reaktion gibt.
Das Thema Tests ist halt auch ein zweischneidiges Schwert - siehe sinnlose Tests bei Checkplugins.
Wenn ich dort einfach falsche Daten zum Testen verwende hilft es halt nix das der Test klappt aber der Check in der echten Welt immer fehlschlägt.
Bei dem Problem mit mk_logwatch schlägt auch noch ein Problem zu welches ich nach der Ankündigung des Features ganz argwöhnig betrachtet hab → Python Plugins direkt unter Windows verwenden. Das bringt gar nix wenn die dort nicht auch getestet werden.
Mit der p12 keine Besserung, stand ja auch nichts im Changelog, aber die Hoffnung stirbt bekanntlich ja zuletzt, evtl. ist es in der Eile ja vergessen worden
Ich kann das nur unterstreichen. Für mich sind die automatisierten Tests die ja in der Software Industrie so angepriesen und gelobt werden nur eine weitere Fehlerquelle. Da verlässt man sich voll und ganz auf diese automatisierten Tests aber wer testet denn dass diese Tests auch korrekt und vollständig sind? Und wenn getestet wird dann doch bitte schön in allen Umgebungen, also auch auf Windows.
In meiner letzten Firma haben wir Software für Kuvertiermaschinen entwickelt. Die neuen Releases wurden regelmäßig von unserem Vertriebler getestet, weil der am wenigsten Ahnung hatte und damit die ‘Bedienungsfehler’ gemacht hat auf die ein kundiger Bediener gar nicht erst gekommen wäre
Zurück zum Thema:
Es sollte doch möglich sein eine ältere, funktionierende Version des logwatch plugins in die local Struktur zu kopieren um das Problem erstmal in der produktiven Umgebung zu beheben.
Next error inside the actual mk_logwatch.py
This will also happen inside Linux not only Windows.
The function who writes the batch_file is checking the written string for utf-8 encoding. In case you have a string what is not utf-8 conform the complete mk_logwatch crashes and does this again and again.
proposed change
Inside “ensure_text_type” set “errors” to replace. Then you get a ? instead of a crashed script.
Could I get failing logwatch config, i.e. programdata\checkmk\agent\config\logwatch.cfg and log files where logwatch is failing?
For example, all c:\test*.log or as in the first post c:\temp\logtest.log
Thank you in advance.
