BUG: mk_logwatch ab 2.1.0p10 auf Windows komplett funktionsunfähig

Hi, nach dem Update von 2.1p6 auf p10 sind alle Checks für Text basierte Logs verschwunden.
Auf dem Host wird noch ausgegeben:

<<<logwatch>>>
[[[c:\TCPOS.net_TEST\FrontEnd\Executables\4.5.14.3\pepper-20210115-0000-00.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
[[[c:\TCPOS.net_TEST\FrontEnd\Executables\7.1\pepper-20210611-0000-00.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
[[[c:\TCPOS.net_TEST_7.1.5.565\FrontEnd\Executables\7.1\pepper-20220818-0000-00.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
[[[c:\TCPOS.net_TEST_OLD\FrontEnd\Executables\4.5.14.3\pepper-20210115-0000-00.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
[[[c:\TCPOS.net_TEST_OLD\FrontEnd\Executables\7.1\pepper-20210301-0000-00.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
[[[c:\temp\logtest.log]]]
BATCH: 1661517860-147161144134253097056084064247008073110151156179
W arnung11Warnung1 22222
. 
<<<>

Aber am Server scheint ausser den Windows Eventlogs nichts anzukommen…

 <<<logwatch>>>
[[[Application]]]
[[[HardwareEvents]]]
[[[Internet Explorer]]]
[[[Key Management Service]]]
[[[Security]]]
[[[System]]]
[[[Windows PowerShell]]]
<<<dotnet_clrmemory:sep(124)>>>

Wenn ich das richtig sehe ist in p9 & p10 jeweils am Logwatch etwas gemacht worden, hat noch jemand dieses Problem?!

Hi Marc,
ich habe in unserer Umgebung das selbe Problem.
Agent gibt mit check_mk_agent.exe test die Logfiles richtig aus

<<<logwatch>>>
[[[C:\X\XXX.log]]]
BATCH: 1661952263-026138142122145095154194196056024202089068089032

Auf dem checkmk-Server kommen jedoch scheinbar nur die Windows-Logs an

<<<logwatch>>>
[[[Application]]]
[[[HardwareEvents]]]
[[[Internet Explorer]]]
[[[Key Management Service]]]
[[[Security]]]
[[[System]]]
[[[Windows PowerShell]]]

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.

Also Site auf p11 mit Agent p10 scheint auf den ersten Blick keine Besserung zu zeigen…

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

Diese Zeile mit “Batch” am Anfang fehlt.

Agent p11 hat den Bug auch noch.

Die Zeile die mit BATCH beginnt, kommt von folgendem Werk:

Diese Geschichte mit den Batches ist dafür da, dass keine Logs mehr “geklaut” werden können.

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 :wink:
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.

6 Likes

Das kann ich nur voll und ganz unterschreiben…

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.

3 Likes

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 :wink:

FYI, ich lasse das Thema im nächsten Sprint bearbeiten. Ich kann nicht sagen, wann es gefixt ist, aber wir schauen es uns an.

2 Likes

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 :wink:

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.

Gruß

Michael

2 Likes

The error is confirmed.
The source of error had been also found.
The solution will be available during a week(I hope) - need a bit more time.

Cheers,
Sergej

3 Likes

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.

Just underlines what we discussed above regards automated testing :wink:

1 Like

Yea, you are right. This is an error. I will fix it ASAP.

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.