Damit dem Windows-Team nichts mehr entgeht – Allesfresser check_logfiles

Posted on February 26th, 2010 by lausser

Folgende Anfrage wurde von einem Kunden an mich gerichtet:

Jetzt kam von den Admin die Anfrage ob es nicht möglich ist alle Meldungen (winwarncrit) erstmal als Warning an Nagios zu melden, um dann bestimmte Meldungen nach und nach als Critical einzustufen, oder komplett zu verwerfen (exclude).
Geht das?

Vor dieser Aufgabenstellung dürften auch andere Nagios-Administratoren stehen. Die Windows-Leute sind durchaus an Nagios-Alarmen interessiert und wollen gerne alle Fehlermeldungen (WARNING und ERROR) aus dem Eventlog gemeldet bekommen. Da allerdings von vornherein noch nicht bekannt ist, was da alles an Meldungen auftaucht und man nicht um drei Uhr morgens von einem Alarm geweckt werden will, der im Eventlog als ERROR drinsteht, aber im Grunde harmlos ist, sollen zunächst sämtliche Events als Warnung eingestuft werden. (Es wird davon ausgegangen, daß zu nachtschlafener Zeit keine Notifications vom Typ WARNING an das Bereitschaftshandy geschickt werden).

Also werden folgende Rahmenbedingungen in der Konfiguration von check_logfiles abgebildet:

Man möchte grundsätzlich alles mitbekommen, was im Eventlog als WARNING oder ERROR auftaucht.
Das geht, indem man einen entsprechenden includefilter setzt.
Man möchte nicht um drei Uhr morgens durch einen Alarm geweckt werden, der im Eventlog als ERROR steht, aber im Grunde harmlos ist.
Das erreicht man, indem man eine “catch-all”-Regexp ‘.*‘ in warningpatterns definiert.
Man möchte manche Meldungen, die im Eventlog als WARNING oder ERROR stehen, komplett verwerfen.
Dazu trägt man diese Meldungen in warningexceptions ein.
Meldungen, die wirklich kritisch sind, sollen den Nagios-Status CRITICAL erhalten und somit auch in der Nacht einen Alarm auslösen.
Dazu trägt man diese Meldungen in criticalpatterns ein.

Einen Schönheitsfehler hat die Sache aber noch. Findet check_logfiles einen Event, der in criticalpatterns aufgeführt wurde, so wird er als CRITICAL gezählt. Zugleich schlägt aber immer noch das ‘.*‘ in den warningpatterns zu. Das bedeutet, daß die Ausgabe von check_logfiles in dem Fall so aussehen wird:

CRITICAL - (1 errors, 1 warnings) - Suelzomat reports fatal error

Das erfüllt zwar seinen Zweck, ist aber ein wenig irreführend. Richtigerweise dürfte keine WARNING gezählt werden. Aus diesem Grund gibt es die Option preferredlevel, die dafür sorgt, daß bei so einem Mehrfachtreffer dieser nur einmal, entweder als WARNING oder als CRITICAL, gezählt wird. In diesem Fall ist die WARNING überflüssig, deshalb setzt man preferredlevel auf critical. Damit erscheint dann bei der gleichen Fehlersituation die Ausgabe:

CRITICAL - (1 errors) - Suelzomat reports fatal error

Eine vollständige Konfiguration sieht dann so aus:

@searches = ({
  tag => 'sysevt',
  type => 'eventlog',
  eventlog => {
    eventlog => 'system',
    include => {
      eventtype => 'error,warning',
    },
  },
  options => 'preferredlevel=critical,eventlogformat="id:%i so:%s ca:%c msg:%m"',
  criticalpatterns => [
      # hier stehen die Events (die im Eventlog vom Typ Warning oder Error sein können)
      # bei deren Auftauchen sofort gehandelt werden muss, die also Nagios-seitig
      # als CRITICAL eingestuft werden sollen.
      'id:7034 so:Service_Control_Manager .* msg:Dienst .* wurde unerwartet beendet',
      'id:7000 so:Service_Control_Manager .* msg:Der Dienst .* wurde .* nicht gestartet',
      'id:1069 so:ClusSvc .* msg:Cluster Resource .* in Ressourcengruppe .* ist fehlgeschlagen',
      ...
  ],
  warningexceptions => [
      # die hier aufgeführten Events, sollen nicht weiter beachtet werden. 
      'id:1111 so:TermServDevices .* msg:Der für den Drucker .* erforderliche Treiber .* ist unbekannt',
      ...
  ],
  warningpatterns => [
      # sämtliche anderen Events (auch solche, die noch niemals vorgekommen sind)
      # erscheinen in Nagios als WARNING.
      '.*'
  ],
})

Tags: check_logfiles, Eventlog, Nagios
Filed under Nagios |

7 Responses to “Damit dem Windows-Team nichts mehr entgeht – Allesfresser check_logfiles”

Thomas Says:
March 2nd, 2010 at 10:09
Hallo Gerhard,

ich habe vor ein paar Tagen versucht check_logfiles.exe auf einem W2K8 R2 (64Bit) Server zum Laufen zu bringen. Leider ist es mir nicht gelungen. Hast Du oder jemand aus eurem Windows-Admin-Team bei Consol schon Erfahrungen mit W2K8 und check_logfiles?

Ich habe check_logfiles über NSClient++ auf, es findet aber keinen einzigen Eintrag vom Typ WARNING, oder CRITICAL. Bei W2K3 habe ich mit der gleichen Konfigurationsdatei von check_logfiles keine Probleme.

MfG Thomas

[Reply]
lausser Reply:
March 3rd, 2010 at 16:05
Hallo Thomas, kannst du bitte mal in einem CMD-Fenster den folgenden Aufruf probieren?
check_logfiles --type "eventlog:eventlog=system" --winwarncrit --lookback 30d
Was mich interessiert, ist der Eintrag default_lines= in den Performancedaten. Der gibt an, wieviele Events überhaupt aus dem Eventlog gelesen wurden. Der lookback-Parameter bedeutet dabei “schau 30 Tage in die Vergangenheit zurück”. Ich nahme mal an, daß in den letzten 30 Tagen einige Ereignisse ins system-Eventlog geschrieben wurden, die Zahl sollte also größer 0 sein. Wenn tatsächlich 0 rauskommt, gibt es womöglich ein Kompatibilitätsproblem mit dem 32bit/XP-Executable unter 64bit/W2K8. Gerhard
[Reply]
lausser Says:
March 8th, 2010 at 22:52
Ich habe mir ein 64bit/W2K8-System aufgesetzt, um dein Problem nachzustellen, aber … alles funktioniert so, wie es soll.

[Reply]
Thomas Says:
March 15th, 2010 at 7:27
Danke für den Tip. Der Kommandozeilenaufruf funktioniert wie erwartet. Eventuell war ich nur zu ungeduldig, weil länger als 5 Tage kein Fehler in den EventlLogs gefunden wurde. ;-)

DANKE nochmals

[Reply]
Thomas Says:
March 15th, 2010 at 9:31
ich habe noch ein weing getestet und dabei festgestellt, dass zwar Fehler im System EventLog gefunden werden, nicht aber im Application EventLog.

die aktuelle Konfigdatei von check_logfiles schaut so aus:

@searches = ({ tag => ‘EventLog’, type => ‘eventlog’, eventlog => { eventlog => ‘system’,'application’, }, options => ‘winwarncrit’,'eventlogformat=%w %s ID:%id %m’,'noperfdata’, })

Fällt Dir etwas dazu ein?!

[Reply]
Thomas Says:
March 15th, 2010 at 9:56
jetzt habe ich folgende Zeile in der Konfigdatei von check_eventlog geändert

eventlog => { eventlog => ‘system,application’, },

und jeweils einen Fehler im System- und einen im ApplicationLog generiert. check_eventlog.exe erkennt aber lediglich den neuen Eintrag in ApplicationLog. Der im SystemLog wird nicht gefunden.

hm?

[Reply]
lausser Reply:
March 18th, 2010 at 23:31
Bei eventlog=>eventlog kann man nicht einfach eine Liste angeben. Wenn sowohl System- als auch Application-Eventlog in einer Konfiguration untersucht werden sollen, muss man dafür zwei Einträge im @searches-Array anlegen.

[Reply]

Damit dem Windows-Team nichts mehr entgeht – Allesfresser check_logfiles

7 Responses to “Damit dem Windows-Team nichts mehr entgeht – Allesfresser check_logfiles”

Leave a Reply

Projects

Forum

Tags