Check Paramter in check_mk setzen und überschreiben.

Update: Die­se Anlei­tun­gen gilt für älte­re Ver­sio­nen von Check_MK. Die Kon­fi­gu­ra­ti­on kann in den neu­en Ver­sio­nen bequem in Wato, dem Web­ad­mi­nis­tra­ti­ons­tool durch­ge­führt wer­den.

Auf den ers­ten Blick könn­te es even­tu­ell etwas kom­pli­ziert wir­ken für Checks in check_mk neue Para­me­ter zu set­zen. In der Pra­xis jedoch erweist es sich als über­aus ein­fach und vor­al­lem prak­tisch.

Anders als im klas­si­schen Ansatz ist es erst ein­mal nicht nötig, in check_mk irgend­wel­che Para­me­ter zu set­zen, da das meis­te bereits durch Stan­dart­pa­ra­me­ter abge­deckt wird. Will ich die­se jedoch ändern, habe ich wie immer die Mög­lich­keit, dies jeweils für Hosts oder Host­tags durch­zu­füh­ren. Zu die­sem Zweck steht die Varia­ble check_parameters zur Ver­fü­gung. Vom Daten­typ ist dies eine Lis­te, wel­che für jeden Ein­trag aus einem Tupel mit je nach­dem 3 oder 4 Wer­ten besteht:

Wie im Bei­spiel zu sehen besteht der ers­te Wert wie­der aus einem Tupel. In die­sem ste­hen nun genau unse­re Para­me­ter. Die­se sind im Bei­spiel genau 2 Wer­te. Das aber ist je nach Check unter­schied­lich, dafür in der jewei­li­gen Doku­men­ta­ti­on zum Check beschrie­ben.

Die Doku­men­ta­ti­on zu Checks kann man sich auf der Kon­so­le durch ein:

ganz ein­fach anzei­gen las­sen.

Nun zum zwei­ten Wert. Die­ser ist eine Lis­te, die aus den Rech­ner­na­men oder eben aus Hos­tags besteht. Nun ist es wie­der so, dass, wenn es sich um eine Lis­te von Host­tags han­delt, das als wei­te­rer Para­me­ter ALL_HOSTS
gesetzt wer­den muss.

Nun bleibt auch nur noch ein Para­me­ter übrig. Mit die­sem beschrei­be ich dann für wel­che Ser­vices ich den über­haupt die neu­en Wer­te set­zen möch­te. Der Para­me­ter ist nun wie­der eine Lis­te in der ich alle Ser­vice Descrip­ti­ons ein­fach auf­füh­re. Hier muss ich übri­gens auch wie­der nicht den gan­zen Namen aus­schrei­ben. Nach hin­ten wird auto­ma­tisch auf­ge­füllt. So wirkt ein fs_ auf alle Ser­vices, die mit fs_ anfan­gen. Aus­nah­men wie im Bei­spiel fs_C: müs­sen dann in der Rei­hen­fol­ge ein­fach zuerst kom­men.

Das war auch schon alles, nur den Restart nicht ver­ges­sen :)

Checks zuweisen die keine Inventur besitzen am Beispiel einer Prozessüberwachung

Update: Die­se Anlei­tun­gen gilt für älte­re Ver­sio­nen von Check_MK. Die Kon­fi­gu­ra­ti­on kann in den neu­en Ver­sio­nen bequem in Wato, dem Web­ad­mi­nis­tra­ti­ons­tool durch­ge­führt wer­den.

Am Bei­spiel einer Pro­zess­über­wa­chung erklä­re ich in die­sem Arti­kel, wie checks in der main.mk ein­ge­tra­gen wer­den kön­nen, wel­che nicht auto­ma­tisch inven­ta­ri­siert wer­den.

Einen Pro­zess mit check_mk zu über­wa­chen, for­dert mit check_mk kei­ne wei­te­re Kon­fi­gu­ra­ti­on auf dem Ziel­rech­ner. Eine kom­plet­te Lis­te der lau­fen­den Pro­zes­se wer­den dem Nagi­os Ser­ver bereits durch den Agent gelie­fert.

Es muss also nur noch ange­ge­ben wer­den, wel­che Pro­zes­se man über­wa­chen will. Die­se Kon­fi­gu­ra­ti­on kann wie bereits in mei­nem Arti­kel Ein­stieg in den Benut­zung von check_mk dann jeweils einem oder meh­re­ren Hosts zuge­ord­net wer­den oder eben einem Host­tag. Um das Bei­spiel des ande­ren Arti­kels auf­zu­grei­fen, möch­te ich nun auf srvweb1 den Dienst Apa­che über­wa­chen. In der Kon­fi­gu­ra­ti­on des Bei­spiels habe ich bereits einen Host­tag mit dem Namen apa­che ein­ge­tra­gen, um ggf. auch auf ande­ren Ser­vern die­sen Dienst durch ein­fa­ches zufü­gen des Host­tags über­wa­chen zu kön­nen.

Das pas­siert hier: Ich erwei­te­re die Lis­te checks um einen check,dazu muss ich ein soge­nann­tes Tup­le ein­tra­gen. Pro Zei­le kann ich für jeden Check jeweils ein Tup­le ein­tra­gen. Inner­halb des Tup­le erfolgt mit den ers­ten bei­den Wer­tun­gen die Zuwei­sung an den Host. Im Bei­spiel sind dies Alle Hosts mit dem Tag apa­che. Will ich etwas direkt an einen Host­na­men zuord­nen, schrei­be ich den Host­na­men anstel­le des Tags. , ALL_HOSTS fällt dabei weg. Meh­re­re Hosts oder Tags wer­den übri­gens so zuge­ord­net: [“eintrag1”,“eintrag2].

Jetzt folgt die Anga­be des checks, den ich benut­zen will: Im Bei­spiel ps. Will ich übri­gens die Pro­zes­se auch Per­for­mance Gra­phen über­wa­chen, hilft uns der check ps.perf.

Als vor­letz­tes nun die Ser­vice Descrip­ti­on für Nagi­os. Dies ist der Name, mit wel­chem der Ser­vice spä­ter in Nagi­os ange­zeigt wird.

Zuletzt ein Tup­le mit den check-Para­me­tern. Bis auf den Inhalt die­ser inne­ren Tup­le ist die Syn­tax zur Zuwei­sun­gen ande­rer checks immer gleich.

Bei den ps checks besteht die­ser Tup­le nun aus 5 oder 6 Wer­ten. Der ers­te Wert ist hier nun der Name des Pro­zes­ses, wie er in der ps Lis­te des Sys­tems auf­taucht. Das Tol­le hier­bei ist, dass regu­lä­re Aus­drü­cke mög­lich sind .

Im Bei­spiel wird jeder Pro­zess über­wacht, wel­cher im Namen apache2 ent­hält. Möch­te ich nicht auf den Pro­zess­na­men gehen, son­dern auf den Besit­zer des Pro­zes­ses, muss ich anstel­le “~.*apache2” ein None schrei­ben, dann ein Kom­ma und den Benut­zer­na­men in Anfüh­rungs­zei­chen. Die fol­gen­den 4 Zif­fern sind die jetzt die Schwell­wer­te ent­spre­chend der Zahl der lau­fen­den Pro­zes­se. Warn­min, OKmin, OKmax, Warn­max.

Im Bei­spiel bedeu­tet das nun: zwi­schen 5 und 50 erscheint Warning, zwi­schen 50 und 80 ist alles OK, zwi­schen 80 und 85 wie­der Warning und alles klei­ner 5 und grö­ßer 85 ist Cri­ti­cal.

Will ich das z.B. ein Pro­zess nur ein­mal läuft, wäre es 1,1,1,1.

Jetzt nur noch eine Inven­tur des Sys­tems, und unser Pro­zess taucht in der Über­wa­chung auf.

Mehrere ähnliche Prozesse automatisch generieren

Zum Abschluss noch ein klei­nes “Schman­kerl”, wie uns check_mk auch hier wie­der Arbeit abneh­men kann.

In man­chen Fäl­len hat man meh­re­re Diens­te, die man über­wa­chen will, z.B. jeder Dienst mit dem Pfad /usr/bin/notes/. Jetzt muss ich nicht für jeden Pro­zess einen eige­nen Ein­trag schrei­ben, son­dern kann dies auto­ma­tisch machen las­sen:

Wie im Bei­spiel zu sehen, erwei­te­re ich die Ser­vice Descrip­ti­on nur um ein %s. Wir erin­nern uns, dass in der Kon­fi­gu­ra­ti­on des Pro­zess­na­mens regu­lä­re Aus­drü­cke erlaubt sind. Klam­me­re ich nun hier was ein, wird %s auto­ma­tisch durch den geklam­mer­ten Teil ersetzt. Hier klam­me­re ich (.*) ein, das bedeu­tet eine belie­bi­ge Anzahl von Zei­chen, eben alles was nach /usr/bin/notes/ kommt.

Also, viel Spass damit :)

Einbidung alter NRPE Checks in den check_mk_agent

Wie ver­spro­chen behand­le ich nun das The­ma NRPE checks in check_mk ein­bin­den. Nicht sel­ten lie­gen bei der Migra­ti­on zu check_mk noch alte NRPE checks vor, die man natür­lich ger­ne mit den check_mk-Vor­tei­len ver­hei­ra­ten will.

Dies ist nicht wei­ter schwer, denn dafür wur­de MRPE geschaf­fen.

Wie funktioniert MRPE?

MRPE ermög­licht den loka­len Auf­ruf von Nagi­os checks direkt durch den Agent. Der Agent sorgt auto­ma­tisch für die pas­sen­de Umwand­lung deren Aus­ga­be und hängt die­se an sei­ne Aus­ga­be an. Das prak­ti­sche: der Agent unter­stützt die­ses bereits von Haus aus.

Wie konfiguriere ich MRPE

Kon­fi­gu­riert wird es auf dem zu über­wa­chen­den Rech­ner unter /etc/check_mk/ in der mrpe.cfg. In die­ser wer­den nun zei­len­wei­se die Checks ein­ge­tra­gen. Die Form besteht dabei aus einem Ser­vice­na­men (ohne Leer­zei­chen, im Bei­spiel SERVICE_DESC1 +2), dem kom­plet­ten Pfad sowie allen Para­me­tern des NRPE Plug­ins:

Führt man nun auf dem Nagi­os Ser­ver eine Inven­tur beim ent­spre­chen­den Ziel­host durch, wer­den die MRPE checks auto­ma­tisch erkannt.

Einstieg in die Benutzung von check_mk

Update: Die­se Anlei­tun­gen gilt für älte­re Ver­sio­nen von Check_MK. Die Kon­fi­gu­ra­ti­on kann in den neu­en Ver­sio­nen bequem in Wato, dem Web­ad­mi­nis­tra­ti­ons­tool durch­ge­führt wer­den.

Nach­dem ich in mei­nem letz­ten Arti­kel die Funk­tio­nen von check_mk beschrie­ben habe, möch­te ich heu­te mehr ins Detail gehen, wie ich check_mk kon­kret kon­fi­gu­rie­re.

Beispiel

Ich beschrei­be es anhand eines fik­ti­ven Bei­spiels drei­er Rech­ner, die über­wacht wer­den sol­len. Rech­ner 1, srvfile1: Linux File­ser­ver. Nor­mal erreich­bar. Rech­ner 2, srvweb1: Ein Linux Web Ser­ver mit Apa­che und einem nrpe Check, der wei­ter benutzt wer­den soll. Rech­ner 3, srvdmz1: Ein Ser­ver in einer DMZ, der nur per SSH zu errei­chen ist.

check_mk soll­te bereits kon­fi­gu­riert sein. Am ein­fachs­ten arbei­ten wir wie­der mit OMD, da ist schon alles dabei. Da die Pfa­de je nach Instal­la­ti­on woan­ders sein kön­nen, bit­te beach­ten, dass ich die Pfad­an­ga­be ent­spre­chend OMD beschrei­be. Lässt sich aber leicht ablei­ten.

Los gehts:

Pfade

OMD Nut­zer wech­seln als root durch su — site­na­me in ihre OMD site. In den Bei­spie­len heisst mei­ne site moni­tor. Alle Kon­fi­gu­ra­tio­nen zu check_mk befin­den sich unter ~/etc/check_mk .

main.mk

Für uns ist die main.mk inter­es­sant. Sie ist die Haupt­kon­fi­gu­ra­ti­ons­da­tei. Es ist natür­lich mög­lich, die Kon­fi­gu­ra­ti­on auf meh­re­re Datei­en auf­zu­tei­len. Die­se kön­nen mit der Endung .mk in den Ord­ner conf.d abge­legt wer­den. Beim Auf­tei­len auf meh­re­re Datei­en muss nur beach­tet wer­den, dass man die Kon­fi­gu­ra­tio­nen in Python, also einer Pro­gram­mier­spra­che schreibt. D.h. in Varia­blen, an die mehr­fach etwas ange­hängt wird, also in der Regel mit +=. Ich erklär es gleich im Bei­spiel.

In der main.mk neh­men wir als ers­ten Schritt die drei Rech­ner auf, wel­che wir über­wa­chen wol­len:

Sie wer­den ein­fach in eine Lis­te mit dem Namen all_hosts gehängt. Tei­le ich die Kon­fi­gu­ra­ti­on nun auf meh­re­re Dati­en auf, darf  ich in denen natür­lich nicht wie­der all_hosts = schrei­ben, son­dern muss += ver­wen­den.

Wich­tig ist auch die kor­rek­te Syn­tax beim schrei­ben. Die Klam­mern müs­sen wie ich es im Bei­spiel zei­ge gesetzt wer­den. Die ers­te nach dem =, die let­ze in eine neue Zei­le. Dies liegt an Python, denn für Python ist nor­mal new­li­ne das Zei­len­en­de, außer ein Ele­ment ist eben noch offen. Dann ist das Zei­len­en­de da, wenn das Ele­ment wie­der geschlos­sen wird.

In unse­rem Bei­spiel gehen wir nun davon aus, das srvfile1 und srvweb1 im DNS auf­ge­löst wer­den. Hier muss ich also nichts wei­ter tun.

Extra IP Addressen

Anders sieht es aber nun mit dem srvdmz1 aus. Die­ser steht nicht im DNS. Für die­sen müs­sen wir die IP Adres­se manu­ell zuwei­sen. Die funk­tio­niert über ein Python Dict:

Wich­tig wie­der die Syn­tax und noch etwas: wenn man IP Adress-Zuwei­sung in meh­re­ren Datei­en durch­füh­ren will, geht dies nicht über +=. Man muss es mit

zusam­men­hän­gen.

Andere Datenquellen

Jetzt erin­nern wir uns aber auch noch, das srvdmz1 nur über SSH zu errei­chen war. Dazu müs­sen wir dem Rech­ner eine neue Data­sour­ce zuwei­sen.

In der main.mk schrei­ben wir dazu:

Wir kon­fi­gu­rie­ren damit, dass srvsdmz1 über ssh als root und einem bestimm­ten key­fi­le kon­tak­tiert wird. Platz­hal­ter hier ist

Konfigurationen an Hostags und mehrere Rechner zuweisen

Die Rech­ner-Lis­te kann auch meh­re­re Rech­ner ent­hal­ten:

oder gar einen (oder meh­re­re) Host­tags ent­hal­ten:

Den Host­tag ord­ne ich ein­ach mit einem | dem Rech­ner zu:

Host­tags kön­nen für alle Kon­fi­gu­ra­tio­nen ver­wen­det wer­den. Erkannt wer­den sie durch das Schlüs­sel­wort ALL_HOSTS. Wür­de das hier feh­len, wür­de dmz als Rech­ner­na­me gesucht und nicht als Host­tag Name.

Für unser Bei­spiel habe ich dem srvweb1 auch gleich apa­che zuge­ord­net. Das bent­z­ten wir spä­ter. Das Tag lnx habe ich nur zuge­ord­net, um zu zei­gen, dass man auch meh­re­re Tags zuord­nen kann.

Agents einrichten

Jetzt machen wir aber erst mal den dmz Rech­ner zu Ende: damit wir ihn kon­tak­ten kön­nen muss mit ssh-key­gen ein Schlüs­sel­paar erzeugt wer­den. Dafür schrei­be ich aber auch noch einen eige­nen Bei­trag. Ich setz­te nun mal das ssh-Wis­sen vor­raus.

Auf srvdmz1 muss nun ein­fach in /root/.ssh/authorized_keys der pas­sen­de public_key zum pri­va­te­key­fi­le aus unse­re Datesour­ce lie­gen. Da wir natür­lich nicht wol­len, dass man sich vom Nagi­os Ser­ver ein­fach als root auf srvdmz1 ver­bin­det, hin­ter­le­gen wir in aut­ho­ri­zed_keys für Key­fi­le noch einen com­mand. command=”/usr/bin/check_mk_agent”. Dann wird bei einer Ver­bin­dung mit dem Key immer nur der Agent aus­ge­führt. Ein inter­ak­ti­ver Log­in mit dem Key fin­det nicht statt. Der Agent muss natür­lich noch nach /usr/bin kopiert wer­den.

Auf srvfile1 und srvweb2 haben wir es etwas ein­fa­cher. Auf die­sen bei­den Ser­ver kön­nen wir ein­fach das nor­ma­le Agent Paket instal­lie­ren. Die­ses legt auto­ma­tisch einen Ein­trag in xin­ted an, wel­ches den Agent über TCP Post 6556 erreich­bar macht.

Damit wäre die Grund­kon­fi­gu­ra­ti­on und die Agent-Instal­la­ti­on geschafft.

Inventur

Nun kön­nen wir auch schon eine Iven­tur machen:

Ohne jedes wei­te­re Para­me­ter wird jetzt eine Iven­tur über alle Rech­ner durch­ge­führt, wel­che in der Kon­fi­gu­ra­ti­on ein­ge­tra­gen wur­den. Es wird ermit­telt, was für jeden Rech­ner über­wacht wer­den könn­te.

Natür­lich lässt sich auch eine mit Leer­zei­chen getrenn­te Lis­te ange­ben, wenn ich nur bestimm­te Rech­ner inven­tu­ri­sie­ren will. Bei­spiel­haft sieht das nun so aus:

Dabei wer­den aber immer nur checks ange­zeigt, wel­che noch nicht bei einer frü­he­ren Iven­tur ent­deckt wur­den. Das funk­tio­niert, da jede Inven­tur im Order ~/var/check_mk/autochecks abge­legt wird.

Das ist wich­tig zu wis­sen, denn über­wa­che ich z.B. ein File­sys­tem, wel­ches spä­ter ent­fernt wird oder durch einen Feh­ler nicht mehr gefun­den wird, merkt sich dies check_mk, um es mel­den zu kön­nen. Will ich bewusst dafür sor­gen, dass es nicht mehr dazu gehört, muss es aus auto­ch­ecks gelöscht wer­den. Dies geht mit check_mk -II rech­ner­na­me. Zwei­mal II sorgt dafür, dass die auto­ch­ecks zu den ange­ge­ben Rech­nern vor der Iven­tur gelöscht wer­den.

Will ich übri­gens nur ein­zel­ne Diens­te inven­tu­ri­sie­ren, hilft der Para­me­ter –checks check­na­me.

Alles im Nagios

Ist die Inven­tur geschafft, kön­nen wir uns das Ergeb­nis auch schon gleich mal in Nagi­os anschau­en. Dazu muss aber check_mk die Nagi­os-Kon­fi­gu­ra­ti­on erstel­len und Nagi­os neu gestar­tet wer­den.

Dies kann nun mit einem Rutsch pas­sie­ren, in dem man check_mk -R macht oder man kann Nagi­os nach einem check_mk -U auch selbst neu star­ten.

Abschluss

Wenn wir jetzt ins Nagi­os schau­en, wer­den wir sehen, dass unser srvfile1 bereits fer­tig ist. Alle Datei­sys­te­me, sei­ne SAN Paths und sei­ne loka­len Raids wur­den erkannt. Fest­plat­ten­be­le­gung wird alles bereits auto­ma­tisch über­wacht.

srvdmz1 ist mitt­ler­wei­le auch per­fekt.

Bei srvweb1 schaut es zwar auch schon sehr gut aus, jedoch fehlt noch die Über­wa­chung unse­res Web­ser­vers und unser alter NRPE-Check. Dies wer­de ich in wei­te­ren Arti­keln beschrei­ben. Den Dienst des Apa­chen wer­den wir über die Pro­zess­über­wa­chung über­wa­chen.  Sei­ne Erreich­bar­keit über­wa­chen wir über einen klas­si­schen check_http, wel­chen wir mit Lega­cy Checks ein­bin­den. Sei­nen alten NRPE check wer­den wir ein­fach in die MRPE Kon­fi­gu­ra­ti­on des check_mk Agents über­neh­men.

Check_MK für Nagios. Einführung und Vorteile

Da ich bereits beschrie­ben habe, wie man check_mk Plug­ins schreibt, fehlt natür­lich noch, was check_mk eigent­lich ist.

Einführung

check_mk ist ein von Mathi­as Kett­ner ent­wi­ckel­tes Plug­in für Nagi­os. Ich wür­de sagen, es ist die bes­te Erwei­te­rung, die für Nagi­os ent­wi­ckelt wur­de. Nach mei­ner Mei­nung hät­te Nagi­os von Anfang an so funk­tio­nie­ren sol­len, wie check_mk es erwei­tert. check_mk besteht aus sei­nem eigent­li­chen Kern sowie dem Event Bro­ker Live­sta­tus und der GUI Mul­ti­si­te.

Livestatus

Jeder kennt die Wege, die es zuvor gab, um an die Daten aus Nagi­os her­an­zu­kom­men:

von Haus aus kann man die status.dat aus­le­sen. Eine je nach Instal­la­ti­on Rie­sen­da­tei, die in einem vor­ge­ge­ben Inter­vall immer und immer­wie­der neu auf die HDD geschrie­ben wird. Nicht wirk­lich opti­mal, um damit zu arbei­ten. Effi­zi­ent ist auch was ande­res.

Die nächs­te bekann­te Vari­an­te sind die NDO Tools, spe­zi­ell jene, wel­che in die Daten­bank schrei­ben. Davon abge­se­hen, dass die Tabel­len völ­lig über­nor­ma­li­siert sind, ist es doch eine ganz schö­ne Beschäf­ti­gungs­the­ra­pie für den Ser­ver.
Gehen wir von einer Check­ra­te von 200 Checks/Sekunde aus, wären das Tau­sen­de Que­rys in der Minu­te, nur um in eine sta­ti­sche Daten­bank zu schreiben,was der Stand der Din­ge ist. Und die Daten muss man dann auch noch aus­le­sen. So etwas erzeugt Disk I/O. Auch hier effi­zi­ent ist wie­der was ande­res.

Live­sta­tus hin­ge­gen geht einen ande­ren Weg. Die gesam­ten Daten von Nagi­os sind ja die gan­ze Zeit schon da. Denn sie lie­gen direkt im Spei­cher von Nagi­os. Sonst könn­te Nagi­os auch nicht arbei­ten. Live­sta­tus spei­chert die­se Daten nicht irgend­wo zwi­schen, son­der liest sie direkt aus. Und zwar wirk­lich live. Rea­li­siert wird dies über ein Event Bro­ker Modul, wel­ches einen Sockel erzeugt. Die­ser kann über eine Que­ry Lan­guage in Echt­zeit abge­fragt wer­den, kann Nag­vis  befüt­tern und über ssh und xin­ted frei­ge­ge­ben wer­den. Neben aktu­el­len Daten kann über Live­sta­tus auch auf Daten aus Nagi­os Log­files zuge­grif­fen wer­den. Com­man­ds an Nagi­os zu sen­den ist auch kein Pro­blem. Dies ist effi­zi­ent und der in mei­nen Augen logi­sche Weg.

Multisite GUI

Gera­de so neben­bei wird auch die GUI Mul­ti­si­te mit­ge­lie­fert. In die­se wur­de so alles inte­griert, was man in der Stan­dard Nagi­os GUI ver­misst. Vor allem ande­ren ist sie schnell, da sie direkt auf Live­sta­tus auf­setzt. Fil­tern nach Events, Ser­vice Namen, Sta­tu­en geht so mit nur einem Klick. Ack­now­led­ge­ments kön­nen auf belie­big vie­le Ser­vice und Diens­te gleich­zei­tig gesetzt und ent­fernt wer­den, eben­so wie Com­man­ds. Ansich­ten sind frei defi­nier­bar. Von den Tabel­len­spal­ten, Grup­pie­run­gen bis­hin zu Fil­tern kann man wirk­lich alles auf  Wunsch ein­stel­len. PNP Gra­phen wer­den auto­ma­tisch erkannt und ange­zeigt. Und noch ein Kil­ler­fea­ture: Mul­ti­si­te ist die ers­te GUI, wel­ches ein ver­teil­tes  Moni­to­ring auf  meh­re­rer Ser­ver unter­stützt. Live­sta­tus macht es mög­lich, belie­bi­ge ande­re Ser­ver so zu bedie­nen, als wäre man direkt auf einer GUI auf dem Ser­ver. Ohne Kom­pro­mis­se.

Die Mul­ti­si­te Side­bar darf auch nicht uner­wähnt blei­ben. Sie kann von jedem User für sich kon­fi­gu­riert wer­den und durch soge­nann­te Sna­pins erwei­tert wer­den. Von Pro­blem Host Über­sich­ten bis Ser­ver Per­for­mance anzei­gen ste­hen bereits vie­le Sna­pins mit der Grund­in­stal­la­ti­on bereit. Natür­lich kann von Admins kon­fi­gu­riert wer­den, wel­che Sna­pins für wel­che User sicht­bar sind oder auch nicht.

check_mk

Nun dazu, was check_mk selbst tut: Es nimmt jede Men­ge Kon­fi­gu­ra­ti­ons­ar­beit ab und opti­miert gleich­zei­tig die Ser­ver Per­for­mance. Aber wie das?

Der Ansatz von check_mk ist eine Auto­ma­ti­sie­rung der Über­wa­chung, bei der so wenig wie mög­lich kon­fi­gu­riert wer­den muss, sich alles erst­mal selbst kon­fi­gu­riert und bei Bedarf manu­ell opti­miert wer­den kann.

Der Agent

Wer jetzt die checks per SSH oder NRPE kennt, bei denen auf Cli­ent und Ser­ver­sei­te kon­fi­gu­riert wer­den muss­te, wird sich gleich ärgern, wie viel Zeit und Ner­ven er dafür schon ver­schwen­det hat. Der Agent ist ein Shell Script. Es liegt ein­fach da, war­tet bis es mal auf­ge­ru­fen wird und gibt dann was aus. Im Detail: Das Shell­script des Agent liegt unter /usr/bin/check_mk_agent und ruft ein­fach nur eine gan­ze Lis­te von Shell Kom­man­dos aus. Von Pro­zess­lis­ten, Mounts, df,  Mail­ques, File­sys­te­men, Ether­net Infor­ma­tio­nen bis hin zu Raid Devices ist alles dabei. Oder eben auch nicht, wenn es etwas auf der Kis­te nicht gibt. Erzeugt wird nun ein­fach eine kom­plet­te Text­aus­ga­be. Das war es schon. Die­se Text­aus­ga­be wird vom Nagi­os Ser­ver abge­holt. Und zwar auf ein­mal. Hat­te man damals mit NRPE pro zu über­wa­chen­den Ser­vice einen Con­nect auf den Cli­ent, gibt es jetzt nur noch eine. Die­se holt auch nur die Text­aus­ga­be ab, ohne dass aktiv ein Kom­man­do über­ge­ben wer­den kann. Der Nagi­os Ser­ver kann also kei­ner­lei Befeh­le an den Cli­ent schleu­sen. Das nächs­te ist der Weg, wie die­se Text­aus­ga­be zum Nagi­os Ser­ver kom­men soll, spielt kei­ne Rol­le.
Von einem Livezu­griff via xinetd oder ssh wäre ein cat auf eine von einem cron­job erzeug­te Text­da­tei genau­so denk­bar wie eine Text­da­tei, die per FTP, Mail oder sonst wie dem Nagi­os Ser­ver in ein Ver­zeich­nis über­mit­telt wird. Der Fan­ta­sie wird hier kei­ne Gren­zen gesetzt. Über alle mög­li­che Umwe­ge kann also mit dem Agent über­wacht wer­den. Fehlt übri­gens was, kann der Agent ein­fach durch ein Plug­in erwei­tert wer­den. Wie das geht, beschreib ich sogar schon hier.

Die Inventur

Jetzt wis­sen wir, dass der Nagi­os Ser­ver jede Men­ge Text gelie­fert bekommt. Was macht man damit? Eine Inven­tur. Und das macht check_mk für uns. Er schaut die­se Text­da­tei in einer Inven­tur durch und erkennt auto­ma­tisch alle Diens­te, die über­wacht wer­den kön­nen. Sinn­vol­le Stan­dard-Schwell­wer­te wer­den bereits vor­ein­ge­stellt. Die kom­plet­te Nagi­os Kon­fi­gu­ra­ti­on wird auto­ma­tisch erzeugt und somit lässt sich in nicht mal einer Minu­te ganz dyna­misch ein Cli­ent in die Über­wa­chung mit­auf­neh­men.

Die Konfiguration

Beden­ken, dass man die Kon­trol­le ver­liert, braucht man dabei aber nicht zu haben. Alles lässt sich bei Bedarf kon­fi­gu­rie­ren. Als Ansatz gilt: “Mit so wenig Kon­fi­gu­ra­ti­on wie mög­lich so vie­le Fäl­le wie mög­lich abzu­de­cken”. Mei­ne Erfah­rung zeigt, dass das recht gut funk­tio­niert.

Hosts wer­den mit Ihrem Namen in eine Lis­te ein­ge­tra­gen. Besteht Bedarf, hin­ter­le­ge ich in einer zwei­ten Lis­te die IP Adres­sen. Hin­ter­le­ge ich kei­ne IP Adres­sen, wird ein DNS Look­up auto­ma­tisch mit einem Restart aus­ge­löst. Also kei­ne Angst vor alten Adres­sen.

Einem Host kann ich dann wie­der­um direkt Tags, soge­nann­te Host­tags, zuord­nen. Die­se las­sen sich dann nut­zen, um Kon­fi­gu­ra­tio­nen zu ver­tei­len. Bei­spie­le: Alle Rech­ner mit Host­tag Linux kom­men in die Host­grup­pe Linux. Oder alle Rech­ner mit Host­tag Apa­che sol­len den Apa­che Ser­vice über­wa­chen. Alle Rech­ner mit Host­tag File­ser­ver bekom­men ande­re Schwell­wer­te für File­sys­tem checks. Anstel­le Host­tags lässt sich natür­lich auch immer der Rech­ner­na­me selbst kon­fi­gu­rie­ren.

Will ich z.B. Ser­vices über­wa­chen, tra­ge ich die­se ein­fach in eine Varia­ble ein. Die­se las­sen sich dann wie­der einem Host­tag zuord­nen. Da man beim Ser­vice Namen auch mit RegEx arbei­ten kann, las­sen sich auch mit einer Zei­le meh­re­re Ser­vice abfan­gen.

Clus­ter­über­wa­chun­gen sind nun auch kein Pro­blem. Man trägt alle Ser­ver des Clus­ters nor­mal ein. Dann fasst man sie ein­fach unter einem vir­tu­el­len Namen zusam­men und zuletzt (RegEx wie­der erlaubt) defi­niert man noch, wel­che Ser­vices Res­sour­cen des Clus­ters sind. check_mk küm­mert sich nun um den Rest. Die Clus­ter Res­sour­cen wer­den unter dem vir­tu­el­len Namen zusam­men­ge­fasst und check_mk schaut, dass sie auf einem der Ser­vers des Clus­ters zur Ver­fü­gung ste­hen.

Die Arbeit damit

Wie arbei­te ich nun damit: Auf einem Cli­ent instal­lie­re ich nur den Agent. Auf dem Nagi­os Ser­ver tra­ge ich den Cli­ent­na­men in die Kon­fi­gu­ra­ti­on ein (eine Zei­le) und füh­re auf der Shell die Inven­tur mit

durch. Alle Ser­vices wer­den erkannt. Mit einem

kann ich mir jetzt schon gleich auf der Shell anschau­en, ob alles funk­tio­niert (es wer­den alle Ser­vices und deren Aus­ga­be dar­ge­stellt). An Nagi­os wur­de bis jetzt noch nichts gemacht. Jetzt folgt ein

dadurch wer­den auto­ma­tisch die Nagi­os Kon­fi­gu­ra­ti­ons­files erstellt und Nagi­os neu­ge­star­tet. Der Ser­ver befin­det sich nun in der Über­wa­chung.

Abschluss

Die­ser Blog-Ein­trag lie­fert erst mal einen nicht­tech­ni­schen Über­blick dar­über, was check_mk ist. Alle Fea­tures und Funk­tio­nen decke ich hier jedoch weit­aus nicht ab. Check_mk wird stän­dig ver­bes­sert und um sinn­vol­le Funk­tio­nen erwei­tert. Alle aktu­el­len Infos gibts auf check-mk.org.

 

Verteiltes Nagios Monitoring mit Livestatus und Multisite

Update: Die­se Anlei­tun­gen gilt für älte­re Ver­sio­nen von Check_MK. Die Kon­fi­gu­ra­ti­on kann in den neu­en Ver­sio­nen bequem in Wato, dem Web­ad­mi­nis­tra­ti­ons­tool durch­ge­führt wer­den.

The­ma heu­te ist das Ein­rich­ten eines Ver­teil­ten Nagi­os Moni­to­rings. In der Ver­gan­gen­heit war dies immer mit viel Kon­fi­gu­ra­ti­on und ein paar Ein­schrän­kun­gen ver­bun­den. Durch das in check_mk ent­hal­te­ne Live­sta­tus wird dies zusam­men mit der check_mk Mul­ti­si­te GUI aber fast zum Kin­der­spiel.

Zur Begriffs­klä­rung: wenn ich ab hier von Moni­to­ring Site spre­che, mei­ne ich damit jeweils die Rech­ner mit Nagi­os Instanz die über­wa­chen, bzw die OMD Sites, wel­che über­wa­chen. Wenn ich von Viewing Site spre­che, mei­ne ich damit den Rech­ner oder die Site mit der Mul­ti­si­te GUI, wel­che alles anzei­gen sol­len.

Ich erklä­re hier die Ein­rich­tung mit und ohne OMD. Ich per­sön­lich bevor­zu­ge OMD.

Zuerst die Vor­be­rei­tung der Moni­to­ring Sites:

Bei der Ver­wen­dung von OMD:
mit omd con­fig bei jeder Instanz bei Dis­tri­bu­t­ed Moni­to­ring den Live­sta­tus TCP Socket akti­vie­ren. Lie­gen meh­re­re Sites auf der glei­chen Maschi­ne, muss für jeden Socket einen eige­ner Port fest­ge­legt wer­den. Unter ~/etc/apache/conf.d soll­te für jede Site die auth.conf ange­passt wer­den. Und zwar muss der Wert Auth­Na­me auf jeder Moni­to­ring Site gleich gesetzt sein. Soweit die Vor­be­rei­tung OMD.

Vor­be­rei­tun­gen nur mit Nagi­os:
Hier ist etwas mehr zu tun. Dabei set­ze ich hier noch vor­aus, dass check_mk mit Live­sta­tus instal­liert wur­de. Nutzt man pnp4nagios, muss in des­sen Apa­che Kon­fi­gu­ra­ti­on bei Ali­as jeweils ein Pre­fix hin­zu­ge­fügt wer­den. Der Pre­fix muss für jede Site unter­schied­lich sein.

Als Bei­spiel:

Bei allen Moni­to­ring Sites dar­auf ach­ten, dass der Auth­Na­me auch auf ein und den­sel­ben Wert ein­ge­stellt wur­de.

Der nächs­te Schritt ist es, den Live­sta­tus Socket durch xinetd auf einen TCP-Port zu legen, damit die Viewing Site spä­ter dar­auf zugrei­fen kann. In das Ver­zeich­nis /etc/xinetd.d muss eine Datei mit fol­gen­dem Inhalt abge­legt wer­den:

Der Name der Datei spielt kei­ne Rol­le. Wich­tig hier sind nur die server_args, wel­che auf den Live­sta­tus Socket zei­gen müs­sen (wie beim check_mk Set­up fest­ge­legt) und user, wel­chem man einen loka­len User angibt, der auf dem Socket Zugriff hat (idr. den Nagi­os User). Mit only_from lässt sich der Zugriff noch auf eine mit Leer­zei­chen getrenn­te Lis­te von IPs ein­schrän­ken.

Zum Abschluss nicht ver­ges­sen, Apa­che und xinetd neu zu star­ten.

Ein­rich­ten der Viewing Site

Dies läuft nun mit und ohne OMD fast gleich. Auch hier set­ze ich vor­aus, das die Mul­ti­si­te GUi bereits auf­ge­setzt ist. Auch in der Apa­che Con­fig zu der GUI soll­te der glei­che Auth­Na­me wie bei den Moni­to­ring sites gesetzt wer­den.
Bei einer nor­ma­len Instal­la­ti­on liegt die Con­fig dafür unter /etc/apache/conf.d/zzz_check_mk.conf, bei OMD wie bereits beschrie­ben in der ent­spre­chen­den auth.conf Datei.

In der multisite.mk set­ze ich nun noch mei­ne Moni­to­ring Site. Gehen wir hier mal von zwei Sites aus:

Um die Wer­te mal kurz zu erklä­ren:  Socket soll­te klar sei, Adres­se des Ser­vers und Port wie in xin­ted fest­ge­legt bzw. wie mit omd con­fig ein­ge­stellt. url_prefix ist nun wich­tig. Hier kommt bei OMD jeweils der Site­na­me der Moni­to­ring Site rein, bei einer nor­ma­len Instal­la­ti­on der besag­te Pre­fix, wel­chen wir bei der Vor­ein­rich­tung gesetzt haben. Wie gesagt, der Pre­fix muss immer unter­schied­lich sein. Som­mit dür­fen auch die Moni­to­ring Sites im OMD nicht gleich benannt sein.

Und nun kommt der Trick, damit wir Daten (pnp Gra­phen) in der Viewing Site sehen kön­nen, obwohl sie auf der Moni­to­ring Site lie­gen. Wir sagen dem Apa­chen auf der Viewing Site: bekommst du eine Anfra­ge auf den Pfad http://viewingsite/path2, lei­te das im Hin­ter­grund auf http://monitoringsite/path2 um. Spä­tes­tens jetzt ist ver­ständ­lich, war­um wir zuvor auf den Moni­to­ring Sites, den Ali­as um einen Pre­fix erwei­tert haben (path2 im Bei­spiel).

Und wie funk­tio­niert das nun? Mit fol­gen­den zusätz­li­chen Ein­trä­gen in der Apa­che Con­fig (z.B. als multisite.conf in /etc/apache2/conf.d)

Apa­che restart nicht ver­ges­sen.

Die Mul­ti­si­te GUI auf der Viewing Site soll­te nun alle Nagi­os-Objek­te der Moni­to­ring Sites sehen. Vor allem pnp Gra­phen soll­ten ohne Error 404 ange­zeigt wer­den. Auch darf dabei nicht wie­der ein Pass­wort abge­fragt wer­den (die htpasswd Datei­en müss­ten natür­lich syn­chron sein).

Ist die Doku unklar oder lässt Fra­gen, ein­fach mel­den.

Grafiken mit TypoScript zusammenbauen und in Marker legen

Wer schon mal ver­sucht hat, eine Home­page zu bau­en, wel­che z.B. unter­schied­li­che Hea­der-Gra­fi­ken, aber immer das Logo an der­sel­ben Stel­le und dazu noch einen belie­bi­gen Text an einer ande­ren haben soll­te, kennt das Pro­blem. Man braucht ein Bild­be­ar­bei­tungs­pro­gramm, ein Script oder sonst etwas, um die­se Gra­fik immer sau­ber zusam­men­zu­bau­en.

Ein­fa­cher gin­ge es natür­lich, wenn uns das das Typo3 abnäh­me. Und das ist leich­ter als man denkt. In mei­nem Bei­spiel arbei­te ich mit dem Mar­ker GRAFIK Das Beson­de­re dar­an, durch ein Exten­si­on Tem­pla­te kann ich die­sen für Zwei­ge der Home­page wie­der über­schrei­ben. Unter­schied­li­che Hin­ter­grund­bil­der sind so näm­lich auch kein Pro­blem:

Begin­nen wir damit, den Mar­ker als Bild anzu­le­gen:

Gleich zum Anfang legen wir sei­ne Grö­ße fest: Brei­te, Höhe. Jetzt begin­nen wir ihn schicht­wei­se zu bele­gen (10,20,30..)

Ers­te Schicht: das Hin­ter­grund­bild:

Etwas län­ger ist die Text­schicht. Als Text wird das Ele­ment sub­tit­le von der Page mit der ID 79 gezo­gen, es folgt die Aus­rich­tung, der Pfad zum Fonts File, die Schrift­grö­ße, Far­be, nice­Text für schö­ne­re Dar­stel­lung und dann das Wich­ti­ge,
der off­set, wel­cher die Posi­ti­on angibt.

Jetzt kön­nen wir z.B. auch ein Logo an immer glei­cher Stel­le ein­bau­en:

Hier noch mal das Gan­ze am Stück:

Check Plugin Entwicklung für check_mk Teil 3

UPDATE:  02.02.2014 — Anpas­sung an aktu­el­len Stand der Din­ge.

In Teil 1 haben wir nun das Agent Plug­in gebaut, in Teil 2 die Inven­tur geschrie­ben. Jetzt fehlt nur noch der Rest: die check Funk­ti­on.

Die check Funk­ti­on wird von check_mk nun für jedes Item ein­mal auf­ge­ru­fen, über­ge­ben wird eben die­ses Item, Para­me­ter und wie­der die Agent Aus­ga­be als info. Hat man mal kei­ne Para­me­ter, kenn­zeich­net man dies mit _no_params als Varia­blen­na­me.

Das Item ist nun jetzt hier jeweils den Varia­blen­na­me der MyS­QL Sta­tus Varia­ble, in params, dann jeweils unser Tup­le  mit den warn oder crit schwel­len die für die­ses Item gel­ten. D.h. wur­de über check_parameters oder Wato nichts gegen­tei­li­ges fest­ge­legt, sind es die Default levels.

Jetzt erst mal wie­der das sel­be Spiel wie in der Inven­tur Funk­ti­on. In Info wird erst zei­len­wei­se nach unse­rem Item gesucht. Wird es gefun­den, legen wir der Les­bar­keit hal­ber den aktu­el­len Sta­tus aus line[1] nach current_stat.

Nun haben wir auch alle Daten um die Tup­le perf der Per­for­mance­da­ten vor­zu­be­rei­ten.

Es reicht uns eine Varia­ble, somit auch nur eine Tup­le in perf. Das Lis­te besteht aus

  • Einem Varia­blen Name
  • Dem Aktu­el­len Wert
  • Dem Warning level des checks
  • Dem Cri­ti­cal level
  • Dem Maxi­mal mög­li­chen Wert
  • Dem Mini­mal mög­li­chen Wert

Alle nicht benö­ti­gen Wer­te wer­den durch ” ” über­sprun­gen, oder kön­nen gleich (wenn man ende) weg­ge­las­sen wer­den. Nur der Varia­blen­na­me und der aktu­el­le Wert sind Pflicht. Einen Teil der Aus­ga­be kön­nen wir nun auch schon vor­be­rei­ten und in out­put spei­chern. Die Schwell­wer­te schrei­ben wir in einen levels String, damit wir die­se nur im Feh­ler­fall als Infor­ma­ti­on für den Benut­zer zurück­ge­ben müs­sen.

Jetzt kommt das eigent­li­che Prü­fen. Wie ihr seht wer­den jeweils nur der Sta­tus­code, unser Aus­ga­be Text sowie die Per­for­mance Daten zurück­ge­ge­ben. Der Sta­tus als Zahl ori­en­tiert sich hier an Nagi­os, 0 = OK, 1 = Warning, 2 = Cri­ti­cal, 3 = Unknown.

Wich­tig ist auch der Return 3, der kommt näm­lich immer dann, wenn das Item in der Agent Aus­ga­be nicht mehr gefun­den wird. Dann stimmt was nicht.

So, das war auch schon die check Funk­ti­on.

Aber Ach­tung: damit allein pas­siert noch nichts, der Check muss nun noch regis­triert wer­den.  In den aktu­el­len Check_MK Ver­sio­nen pas­siert die­ses über in Dic­tiona­ry in check_info:

Inter­es­sant ist hier das %s in der service_description, die­ses wird von Check_MK auto­ma­tisch mit dem Namen des Items ver­se­hen.

Dem­nächst nun noch der Teil 4: Wie kann ich Schwell­wer­te über Wato fes­tel­gen.

 

Check Plugin Entwicklung für check_mk Teil 2

UPDATE:  02.02.2014 — Anpas­sung an aktu­el­len Stand der Din­ge.

So, aus­ge­hend von Teil 1 gehts nun wei­ter mit der Ent­wick­lung eines check_mk Plug­ins, am Bei­spiel eines MyS­QL check.

Wenn in Teil 1 nun alles geklappt hat, lie­fert uns der Agent des Ser­vers nun die Sek­ti­on mysql_status mit aus. Dies lässt sich ein­fach mit cmk -d Host­na­me prü­fen. Die Aus­ga­be soll­te nun einen Abschnitt ähn­lich die­sem:

ent­hal­ten. Ist das der Fall, sind wir nun fer­tig für Schritt zwei. Pfad­an­ga­ben die nun fol­gen, gehen von einer  Instal­la­ti­on mit OMD aus. Soll­test du OMD (Open Moni­to­ring Dis­tri­bu­ti­on) noch nicht ken­nen, schau sie dir unbe­dingt mal an. Einen ein­fa­chen Weg, ein per­fekt kon­fi­gu­rier­tes Nagios/ Icin­ga inklu­si­ve ver­schie­de­ner Plug­ins und Guis auf­zu­set­zen, gibt es nicht. Also los: Wir legen nun unter ~/local/share/check_mk/checks/ das eigent­li­che check Skript mit dem Namen mysql_status an. Hier ist nun Python nötig.

Ein nor­ma­ler Agent basie­ren­der Check besteht pri­mär aus zwei Funk­tio­nen. Zum einen aus einer Inven­to­ry Funk­ti­on zum ande­ren aus der Check Funk­ti­on. Begin­nen wir mit der Inven­to­ry Funk­ti­on:

Der Name der Funk­ti­on soll­te immer inventory_check_name ent­spre­chen. Über­ge­ben wird ein Wert: Die soge­nann­te info . Die­se ent­hält eine Lis­te bestehen aller Zei­len unse­rer Agen­ten Sek­ti­on. Prak­ti­scher­wei­se sind die Zei­len auch gleich an den Leerzeichen/ Tabs gesplit­tet. An die­sem Bei­spiel seht ihr was ich mei­ne:

Und damit kön­nen wir jetzt arbei­ten. Gera­de bei der Aus­ga­be des SHOW STATUS; que­rys gibt es nun ziem­lich vie­le Wer­te die uns gar nicht inter­es­sie­ren. Und jeder hat natür­lich ande­re Inter­es­sen. Somit soll­te es für jeden kon­fi­gu­rier­bar sein, wel­che Wer­te er über­wa­chen will. Hier kommt nun die Varia­ble mysq_status_inventory ins Spiel. Die­se ist am  Anfang des Che­ckes ein­mal leer defi­niert:

Sol­len nun bestimm­te Varia­blen Inven­tu­ri­siert wer­den, pas­sen wir aber nicht die Lis­te im Check an, son­dern über­schrei­ben die­se in der main.mk (Eine Beschrei­bung für WATO folgt)

Wei­ter nun in der Inven­to­ry Funk­ti­on. Nach der Defi­ni­ti­on legen wir uns zuerst eine lee­re Lis­te als Hilfs­va­ria­ble an. Wir nen­nen sie inv,  da wir in ihr spä­ter alle Über­ein­stim­mun­gen able­gen.

Wir begin­nen nun jeden Wert, der uns vom Agent gelie­fert wird, zu durch­lau­fen.

Und für jeden Wert müs­sen wir natür­lich auch schon gleich nach­se­hen, ob eine Inven­tur gewünscht wird.  Wenn ja:

In line[0] steht nun der Name der SQL Varia­ble, so wie wir ihn auch in unse­rer mysq_status_inventory lis­te ver­merkt haben und als Schwell­wer­te wer­den die Default Levels über­ge­ben.

Die Default Level Varia­ble ist auch im Kopf des Checks fest­ge­legt. Aber auch die­se ändern wir nicht mehr im Check, son­dern Über­schrei­ben sie in der main.mk.
Durch iventory.append((item,(params)) kön­nen wir nun Item und Para­me­ter in check_mk Form zusam­men­stel­len. Aber erst mal lan­det es natür­lich in der Lis­te inv. Ist die for Schlei­fe durch info durch, geben wir nun unse­re Lis­te im inv end­gül­tig zurück an check_mk.

bei einem check_mk -I Rech­ner­na­me wer­den nun alle unse­re Wer­te gefun­den und in die Auto­ch­ecks auf­ge­nom­men. Was bedeu­tet, jetzt sind sie im Moni­to­ring. Nun kön­nen wir zur check Funk­ti­on wei­ter. Aber das dann erst in Teil 3.

Check Plugin Entwicklung für check_mk Teil 1

UPDATE:  02.02.2014 — Anpas­sung an aktu­el­len Stand der Din­ge.

Heu­te der ers­te Teil zur Step by Step Check Plug­in Ent­wick­lung für check_mk.

Der Ablauf in Kür­ze: der check_mk Agent wird um eine Sek­ti­on erwei­tert,  Check_MK  um ein Plug­in, wel­ches die­se aus­wer­tet. In die­sem Arti­kel geht es um die Erwei­te­rung des Agents durch eine Sek­ti­on.

Eine Sek­ti­on im Agent ist nichts wei­ter als ein Text­ab­schnitt, wel­cher mit «<NAME»> ein­ge­lei­tet wird und bis zur nächs­ten Sek­ti­on führt. Errei­chen lässt sich das am ein­fachs­ten durch ein Shell Script, wel­ches in den Plug­in Order des check_mk_agents abge­legt wird. Nor­ma­ler­wei­se befin­det sich die­ser unter /usr/lib/check_mk_agents/plugins. Er kann aber auch rela­tiv ein­fach ermit­telt wer­den. Er ist als Plug­ins­Di­rec­to­ry direkt in der Agents Aus­ga­be hin­ter­legt:
Ein­fach mal check_mk_agent | head ein­ge­ben:

Der Name der Datei spielt kei­ne Rol­le. Wich­tig ist nur, das sie aus­führ­bar ist. Als Bei­spiel bau­en wir nun einen Check, der den Sta­tus eines MyS­QL Ser­vers über­prüft.

Hier eigent­lich Plug­in, wel­ches ich mys­ql nen­ne.
Inhalt:

Das ist schon alles:

«<mys­ql»> lei­tet nun die Sek­ti­on ein und direkt dar­auf folgt der mys­ql Befehl. Ich über­ge­be ihm das root Pass­wort (es kann natür­lich auch ein Extrau­ser ohne Pass­wort ange­legt wer­den). Der Pass­wort Pro­ble­ma­tik und deren Lösung beschrei­be ich noch in einem eige­nen Arti­kel. Mit dem IF wird schlicht nur gepüft, ob der MyS­QL befehlt ver­füg­bar ist. Wenn nicht, bleibt die Aus­ga­be leer.

Jetzt nicht ver­ges­sen mit chmod +x mys­ql datei aus­führ­bar zu machen.

Ein check_mk -d vom Nagi­os Ser­ver aus, soll­tet nun schon die neue Sek­tio­nen mit der Aus­ga­be des MyS­QL Sta­tus­be­fehls ent­hal­ten.

Wie ich nun das Gegen­stück zum Plug­in auf dem Moni­tor Ser­ver ent­wick­le
folgt in Teil 2.