[Check_mk (deutsch)] Logwatch unter Linux: Fehlerstatus einer Meldung zurücksetzen

[Jörg Stelzle]

Hallo,

ich Ìberwache Logfiles unter Linux mit Logwatch und möchte auf bestimmte
Fehler (Verbindungstimeout) aufmerksam gemacht werden. Soweit kein Problem.

In gewissem Umfang hat der Ìberwachte Dienst aber SelbstheilungskrÀfte,
die sich ein paar Zeilen spÀter im Logfile zeigen (Connection
established). In diesem Fall soll der Logwatch-Status wieder auf "OK"
wechseln. Der Logwatch-Service-Check soll nur dann Critical sein, wenn
nicht sofort eine "Connection established"-Meldung folgt.

Ich dachte, dass könnte man Ìber "Reclassify state matching regex
pattern" in einer Logwach-Pattern-Rule erledigen. Allerdings wird dann
zwar die "established"-Meldung im Logfile grÃŒn markiert, der Status des
Logwatch-Service-Checks bleibt aber CRITICAL, wenn ich nicht in der
Regel fÃŒr den Regex "established" die Option "Reclassify complete state"
aktiviere und damit einen "CRITICAL"-State auf "OK" setze.

Der Nachteil dieser Variante ist, dass ein vorangegangener
Fehler-Status, der nichts mit diesen Verbindungsproblemen zu tun hat,
verloren geht.

Als letzte Idee hÀtte ich jetzt noch die Weiterleitung an die
Eventconsole, aber wÌrde das tatsÀchlich etwas bringen?


2018-11-16T10:01:38.346+0100 ERROR logstash/async.go:256 Failed to
publish events caused by: read tcp 1.2.3.4:45018->1.2.3.5:5044: i/o
timeout    ===> CRITICAL
2018-11-16T10:01:38.347+0100 ERROR logstash/async.go:256 Failed to
publish events caused by: client is not connected
2018-11-16T10:01:39.347+0100 ERROR pipeline/output.go:121 Failed to
publish events: client is not connected
2018-11-16T10:01:39.347+0100 INFO pipeline/output.go:95 Connecting to
backoff(async(tcp://1.2.3.5:5044))
2018-11-16T10:01:39.498+0100 INFO pipeline/output.go:105 Connection to
backoff(async(tcp://1.2.3.5:5044)) established        ====>
VERBINDUNGSPROBLEM WIEDER GUT

[Eckstein, Andre]

Hallo,

das gewÃŒnschte Feature wird genau so von der Event Console unterstÃŒtzt :

https://mathias-kettner.de/cms_ec.html#cancelling

Mit freundlichen GrÌßen,

Andre Eckstein
Bechtle GmbH IT-Systemhaus
Piepersberg 42
D-42653 Solingen
Tel. +49 / 212 / 33 90 - 275
Fax: +49 / 212 / 33 90 - 290
Sitz Solingen, Amtsgericht Wuppertal HRB 16622, Ust-Id.Nr. DE213159972, GeschÀftsfÌhrer Bernhard Margos


Von: checkmk-de <checkmk-de-***@lists.mathias-kettner.de> im Auftrag von
Datum: Donnerstag, 22. November 2018 um 08:42
Cc: Daniel MÃŒhl <***@smartservice.de>

Hallo,

ich Ìberwache Logfiles unter Linux mit Logwatch und möchte auf bestimmte Fehler (Verbindungstimeout) aufmerksam gemacht werden. Soweit kein Problem.

In gewissem Umfang hat der Ìberwachte Dienst aber SelbstheilungskrÀfte, die sich ein paar Zeilen spÀter im Logfile zeigen (Connection established). In diesem Fall soll der Logwatch-Status wieder auf "OK" wechseln. Der Logwatch-Service-Check soll nur dann Critical sein, wenn nicht sofort eine "Connection established"-Meldung folgt.

Ich dachte, dass könnte man Ìber "Reclassify state matching regex pattern" in einer Logwach-Pattern-Rule erledigen. Allerdings wird dann zwar die "established"-Meldung im Logfile grÌn markiert, der Status des Logwatch-Service-Checks bleibt aber CRITICAL, wenn ich nicht in der Regel fÌr den Regex "established" die Option "Reclassify complete state" aktiviere und damit einen "CRITICAL"-State auf "OK" setze.

Der Nachteil dieser Variante ist, dass ein vorangegangener Fehler-Status, der nichts mit diesen Verbindungsproblemen zu tun hat, verloren geht.

Als letzte Idee hÀtte ich jetzt noch die Weiterleitung an die Eventconsole, aber wÌrde das tatsÀchlich etwas bringen?


2018-11-16T10:01:38.346+0100 ERROR logstash/async.go:256 Failed to publish events caused by: read tcp 1.2.3.4:45018->1.2.3.5:5044: i/o timeout ===> CRITICAL
2018-11-16T10:01:38.347+0100 ERROR logstash/async.go:256 Failed to publish events caused by: client is not connected
2018-11-16T10:01:39.347+0100 ERROR pipeline/output.go:121 Failed to publish events: client is not connected
2018-11-16T10:01:39.347+0100 INFO pipeline/output.go:95 Connecting to backoff(async(tcp://1.2.3.5:5044))
2018-11-16T10:01:39.498+0100 INFO pipeline/output.go:105 Connection to backoff(async(tcp://1.2.3.5:5044)) established ====> VERBINDUNGSPROBLEM WIEDER GUT

[Groshert, Kai (FII6)]

Hallo Jörg,

das geht mit der Event-Console ganz gut, auch wenn es nicht ganz einfach ist die
Regeln richtig zu bauen.

Wir haben z.B. diese Problemmeldungen:
Jan 01 01:01:01 server01 webmon[2523]: nodename=server01 msgseverity=major msgtext=webmon testservice01: service check failed: curl error: 28, Operation timeout.
Jan 01 02:01:01 server01 webmon[2523]: nodename=server01 msgseverity=critical msgtext=webmon testservice01: service check failed: no space left on device.

und diese Meldung soll das wieder canceln:
Jan 01 03:01:01 server01 webmon[2523]: nodename=server01 msgseverity=info msgtext=webmon testservice01: service check OK

Die Regel sieht dann so aus:

Text to match:
webmon.* msgseverity=(?:major|critical) msgtext=webmon (.*?): (.*)

Text to cancel event(s):
msgtext=webmon (.*?): service check OK

Count messages in defined interval:
Count until triggered: 3
Time period: 30 min

Rewrite message Text:
\1 \2


Die Klammern sorgen dafÃŒr, dass nur testservice01 eine Meldung von testservice01 wieder canceln kann, weil die Matchgroups
zusammenpassen (die Klammer mit dem (?:...) ist ein Sonderfall und erzeugt keine Matchgroup - die Klammer ist nur da damit man ein Oder-Matching
mit dem Pipe machen kann (...|...).

Gruss,
Kai
--
Kai W. Groshert

FII6 Compute & Middleware Services

Dr. Ing. h.c. F. Porsche AG
Porscheplatz 1, D-70435 Stuttgart-Zuffenhausen

Besucheradresse:
Mittlerer Pfad 15
70499 Stuttgart Weilimdorf

Telefon: [phone]
Fax: [phone]
E-Mail: ***@porsche.de<mailto:***@porsche.de>


Dr. Ing. h.c. F. Porsche Aktiengesellschaft
Sitz der Gesellschaft: Stuttgart
Registergericht: Amtsgericht Stuttgart HRB-Nr. 730623
Vorsitzender des Aufsichtsrats: Dr. Wolfgang Porsche
Vorstand: Oliver Blume, Vorsitzender
Lutz Meschke, stv. Vorsitzender
Andreas Haffner, Detlev von Platen, Albrecht Reimold, Uwe-Karsten StÀdter, Michael Steiner

Die vorgenannten Angaben werden jeder E-Mail automatisch hinzugefÃŒgt. Dies ist kein Anerkenntnis,
dass es sich beim Inhalt dieser E-Mail um eine rechtsverbindliche ErklÀrung der Porsche AG handelt.
ErklÀrungen, die die Porsche AG verpflichten, bedÌrfen jeweils der Unterschrift durch zwei zeichnungs-
berechtigte Personen der AG.





From: checkmk-de <checkmk-de-***@lists.mathias-kettner.de> On Behalf Of Jörg Stelzle
Sent: Donnerstag, 22. November 2018 08:42
To: Check_MK DE Mailing-List <checkmk-***@lists.mathias-kettner.de>
Cc: Daniel MÃŒhl <***@smartservice.de>
Subject: [Check_mk (deutsch)] Logwatch unter Linux: Fehlerstatus einer Meldung zurÃŒcksetzen

Hallo,

ich Ìberwache Logfiles unter Linux mit Logwatch und möchte auf bestimmte Fehler (Verbindungstimeout) aufmerksam gemacht werden. Soweit kein Problem.

In gewissem Umfang hat der Ìberwachte Dienst aber SelbstheilungskrÀfte, die sich ein paar Zeilen spÀter im Logfile zeigen (Connection established). In diesem Fall soll der Logwatch-Status wieder auf "OK" wechseln. Der Logwatch-Service-Check soll nur dann Critical sein, wenn nicht sofort eine "Connection established"-Meldung folgt.

Ich dachte, dass könnte man Ìber "Reclassify state matching regex pattern" in einer Logwach-Pattern-Rule erledigen. Allerdings wird dann zwar die "established"-Meldung im Logfile grÌn markiert, der Status des Logwatch-Service-Checks bleibt aber CRITICAL, wenn ich nicht in der Regel fÌr den Regex "established" die Option "Reclassify complete state" aktiviere und damit einen "CRITICAL"-State auf "OK" setze.

Der Nachteil dieser Variante ist, dass ein vorangegangener Fehler-Status, der nichts mit diesen Verbindungsproblemen zu tun hat, verloren geht.

Als letzte Idee hÀtte ich jetzt noch die Weiterleitung an die Eventconsole, aber wÌrde das tatsÀchlich etwas bringen?


2018-11-16T10:01:38.346+0100 ERROR logstash/async.go:256 Failed to publish events caused by: read tcp 1.2.3.4:45018->1.2.3.5:5044: i/o timeout ===> CRITICAL
2018-11-16T10:01:38.347+0100 ERROR logstash/async.go:256 Failed to publish events caused by: client is not connected
2018-11-16T10:01:39.347+0100 ERROR pipeline/output.go:121 Failed to publish events: client is not connected
2018-11-16T10:01:39.347+0100 INFO pipeline/output.go:95 Connecting to backoff(async(tcp://1.2.3.5:5044))
2018-11-16T10:01:39.498+0100 INFO pipeline/output.go:105 Connection to backoff(async(tcp://1.2.3.5:5044)) established ====> VERBINDUNGSPROBLEM WIEDER GUT