I can confirm that behavior.
When I edit a logfile with Notepad++, it adds an CR at the end and the log entry appears in checkmk GUI.
Somehow if I use the Windows-Builtin Notepad it doesn’t add the CR at the end and the log-entry doesn’t appear in checkmk-GUI.
Could be an explaination for the different outcome of my first two tries mentioned 13 days ago.
Thanks, I will fix it ASAP. May be tomorrow.
1 Like
We have one problem here, guys.
I can’t process lines without Carriage Return. At least, it may be quite annoying
Use Case
Logger writes every line in few steps, for example, "CRITICAL: " and “System Down\n”.
tick 1 - "CRITICAL: " is written by logger
tick 2 - mk_logwatch finds CRITICAL: but content is empty and mk_logwatch reports just CRITICAL:
tick 3 - "CRITICAL: " is written by logger
You will lose data from CRITICAL.
The entry in the log file is valid only when it ends CR.
As long as there is no CR, the entry is treated as an entry in progress.
I will talk with management and consulting to see what we could do or what we could not do
I tested this on Windows Workstation and neither Notepad++ nor built in Notepad adds anything to the end of the line.
At least syslog only adds a LF:
@SergejKipnis Maybe also see discussion in SUP-10952
regards
Michael
syslog doesn’t work?
No, thats not what I want to say, I just refer to what you wrote.
In any case, logwatch looks for \n, i.e. 0x0A, aka Line Feed in text. No \n(0x0A) - no processing.
This behavior is correct and logical and rather will be not changed in the future.
Windows specific \r, i.e. 0xD, aka Carriage Return is ignored.
It can’t be changed.
If a line contains no end of line symbol(in the case of logwatch it is 0x0A for all OS), then this line will not be processed by logwatch.
At least for the application I currently work on I can confirm that CR LF is added to end of the line:
Looking for 0x0A (LF) works then for any OS.
Correct. \x0A had been chosen as a safe option: on Windows, some app also do not follow Windows convention and use only \x0A.
Content of file:
ERROR: error 1\x0A
ERROR:
The line 1 will be reported
The line 2 never. This is because logwatch wait for end of logging operation, i.e. \x0A
Hmmm i have one file that is monitored by logwatch with no LF at the end of the last line.
It is a XML from a webserver with weather data, with only two lines…
At the moment this file is without error, i am not sure if there will be a LF in case of error.
I dont think so… maybe the error is not written in the last line…
I only know that it worked in the past. Is the LF behavior new?! Since p9/p10?!
Ich hänge mich hier mal mit rein, da ich die situation noch nicht so ganz überrissen habe.
Ich lese hier, dass nur der letzte Eintrag fehlen soll, muss aber bei mir feststellen, dass zumindest mit p13 meine Logs gar nicht mehr ausgewertet werden. Ich kann nicht betiteln ob es mit p2 auch schon der Fall war, da es mir soeben erst auffällt.
Mit einem alten <2.1.x Agent kann aber auch CheckMK 2.1.0p15 die Logs auslesen.
Gibt es denn dazu in naher Zukunft einen Bugfix?
Die Fixes waren in der P14 enthalten.
Also mit dem mk_logwatch.py in der aktuellen Version sollte es hier eigentlich keine Probleme mehr geben. Bedingung ist die letzte Zeile wird mit einem LF abgeschlossen. Ansonsten wird diese Zeile erst übertragen wenn eine weitere Zeile dazu kommt.
1 Like
Guten Morgen,
entschuldige bitte, ich habe deine Antwort erst jetzt gesehen.
Die letzte Zeile in der mk_logwatch.py oder im Eventlog?
Ich bin stecke da leider nicht so tief drin wie ihr, seh jetzt aber auch nicht wo standardmaessig die logfiles für den Agent abgelegt sind?
Danke für deine Hilfe!
Im Eventog. Also die Files die Du überwachen lässt müssen ihre Zeilen mit einem LF beenden.
sprechen wir hier noch von den *.evtx files?
ich spreche explizit von den windows event logs… und ich glaube ich hab hier den falschen Faden erwischt, kann das sein?
Es geht hier um die Überwachung von Textfiles als “Logfiles”… also z.B. c:\temp\log.txt
Das “echte” Windows Eventlog war glaube ich nie betroffen.
verdammt! danke -.-
dann muss ich eine neue Topic öffnen.
Sry für die Mühen
Kann passieren 
kein Ding.
Hier noch ein paar Feature Requests um das logwatch besser zu machen - jeder vote zählt
Zeigen wohl auch ein paar Allgemeine Probleme auf.