Netwerk- en serverdiensten monitoren met Check_MK
Netwerk- en serverdiensten monitoren met Check_MK
Serverexploitanten weten hoe praktisch het is om als eerste op de hoogte te zijn van een op hol geslagen proces, een binnenkort volle schijf of een ventilatoruitval. Een monitoringsysteem kan je daarbij helpen. Check_MK begon als Nagiosuitbreiding, maar is inmiddels een zelfstandig, makkelijk te installeren en beheren product.
Om een oogje op je server of andere computers te houden, die eigenlijk onbewaakt draaien, is monitoringsoftware handig. Die controleert regelmatig de vitale data, bijvoor beeld de vrije schijfruimte, het ventilatortoerental en de temperatuursensoren en kijkt of die binnen vooraf aangegeven grenzen liggen. Als dat niet zo is, alarmeert de software ingestelde contactadressen. In het ideale geval worden de data verzameld en grafisch weergegeven, zodat je op grond daarvan kunt inschatten of een server ondergedimensioneerd is of sinds wanneer hij de belasting nauwelijks aankan. Het gratis bruikbare Check_MK kan dat allemaal (zie het kader op de laatste pagina van dit artikel over de afkomst van Check_MK).
Het configureren van Check_MK is inmiddels compleet via een webgui te doen – als je je weg weet te vinden in de warboel aan links tenminste. We laten in dit artikel zien hoe je snel een minimaal Linux systeem installeert en kunt uitbreiden met de gratis bruikbare Check_MK Raw Edition. Vervolgens laten we een voorbeeld zien van hoe je de monitoring met een browser kunt configureren en perfectioneren.
Check_MK is met veel gangbare Linuxdistributies te gebruiken. Mathias Kettner stelt kantenklare pakketten en een virtuele appliance (als demo) beschikbaar om te downloaden (zie de link onderaan dit artikel). We gaan er vanuit dat je de stableversie van de Raw Edition gaat installeren (op het moment van schrijven was dat 1.4.0p33). Je kunt een al bestaande Linuxinstallatie gebruiken, maar dan moet je er wel rekening mee houden dat Check_MK een eigen webserverinstantie op poort 80 start en configureert – dat kan botsen met andere daar al aanwezige diensten.
Met een netinstallimage van de huidige versie van Debian Stretch kun je een nieuwe installatie starten, bijvoorbeeld in een virtuele machine. Download het ongeveer 300 MB grote ISObestand en boot het medium in een nieuwe virtuele machine, die minstens 1 GB RAM en een 16 GB grote harde schijf moet hebben. Kies voor de gewone installatieprocedure, niet de grafische, en laat alles op één partitie installeren. Deactiveer de desktopomgeving en printerserver en selecteer in plaats daarvan de SSHserver om te installeren.
Na een succesvolle installatie maak je met het ingestelde gebruikersaccount via SSH verbinding met het systeem in de virtuele machine (die we nu ter onderscheiding van andere hosts de monitoringhost zullen noemen). Maak jezelf root met su of meld je op de console als root aan. Download met het commando
wget https://mathias-kettner.de/ support/1.4.0p33/check-mk-raw-
1.4.0p33_0.stretch_amd64.deb
het ongeveer 80 MB grote installatiepakket en start het installeren daarvan met
dpkg -i check-mk-raw-1.4.0p33_0.
stretch_amd64.deb
Pas wel het versienummer aan.
Het uitvoeren van dpkg -i zal tot een foutmelding leiden omdat hij afhankelijke pakketten mist. Met apt-get install -f meld je het pakketbeheer van Debian dat de ontbrekende pakketten automatisch geïnstalleerd moeten worden – dat zal even duren. Als het installeren afgerond is, moet je op de commandline van de monitoringhost met
omd create test omd start test
een monitoringinstantie met de naam 'test' aanmaken en starten. Een monitoringhost kan meerdere van dergelijke onafhankelijke instanties beheren, die door Check_MK 'site' worden genoemd. Het eerst omdcommando toont een wachtwoord dat je met het gebruikersaccount 'cmkadmin' nodig hebt voor het aanmelden met de browser bij de site.
Installeer daarnaast het programma Nullmailer met apt-get install nullmailer. Dat gaat later helpen om alarmmeldingen van Check_MK via mail naar de ingestelde gebruikers te sturen. De installatie vraagt om een smarthost met de bijbehorende toegangsgegevens en heeft dus een SMTPserver nodig die mail kan aannemen. Met
echo "Testbericht" | sendmail -v
ik@example.com
Kun je testen of het versturen van mail lukt (het adres is natuurlijk te vervangen). Indien noodzakelijk pas je de configuratie aan met dpkg-reconfigure nullmailer tot het lukt.
Eerste contact
Vanaf dan kun je verder met de browser op een clientsysteem. Typ in de adresbalk van de browser het ipadres van de monitoringhost gevolgd door de naam van de site, bijvoorbeeld '192.168.2.23/test'. Typ de eerder aangemaakte aanmeldingsgegevens in dan zie je het overzichtelijke beginscherm van Check_MK. Maar laat je door die eerste indruk niet bedriegen.
Ter oriëntatie: de linkerkolom en het deel rechts zijn apart te scrollen. Links kun je data opvragen of de configuratie starten. Rechts laat Check_MK de bij het monitoren opgeslagen data zien. Door het aanklikken van de afzonderlijke elementen kun je daar meer details van te zien krijgen. Met de normale navigatiemogelijkheden van je browser kun je door de applicatie heen wandelen. In het rechter deel biedt Check_MK extra navigatiemogelijkheden.
We zullen ons hier wat meer bezighouden met twee blokken in de linkerkolom. Met 'Views' kun je de monitoringdata vanuit allerlei mogelijke perspectieven bekijken en beïnvloeden – met dat deel zul je waarschijnlijk dagelijks mee aan de slag gaan. De Web Administration Tool WATO helpt je bij het inrichten en configureren van de gemonitorde systemen en dient er dus voor om Check_MK verschillende werktaken te laten verrichten.
Om bij een nieuwe installatie überhaupt wat te zien te krijgen, heb je een slachtoffer nodig dat zich laat observeren. Daar moet je een Check_MKagent voor instellen. Gebruik om te beginnen bijvoorbeeld de monitoringhost zelf: scroll links in de webinterface naar beneden tot je de box met de naam WATO ziet en klik dan op het één na laatste item 'Monitoring Agents'. Dan laat Check_MK alle beschikbare agents voor de betreffende gangbare besturingssystemen zien. Kopieer het eerste item onder 'Packaged Agents' naar het klembord. Dan kom je er meteen achter dat er achter onschuldige zwarte tekst vaak ook links zitten.
Agents binnensluizen
Op de commandline van de monitoringhost voeg je die link in achter het wgetcommando, zodat je de volgende opdracht krijgt:
wget http://localhost/test/check_mk/ agents/check-mk-agent_1.4.0p33-1
_all.deb
Let ook hier weer even op het juiste versienummer. Installeer de agent met
dpkg -i check-mk-agent_1.4.0p33-1
_all.deb
Dat was het al. In de browser op het clientsysteem kun je nu de monitoringhost invoegen bij de configuratie van Check_MK. Daarvoor zijn er – zoals wel vaker bij Check_MK – meerdere manieren. De onze gaat als volgt: klik onder WATO op 'Hosts' en dan bovenaan in het rechterdeel op 'New host' of 'Create a new host'. De webinterface vraagt dan naar de naam waarmee de monitoring naar de host moet gaan. Gebruik daar hier 'localhost' voor. Bij de 'Basic settings' kun je een IPv4adres invullen – IPv6 kan echter ook. Voor localhost is dat echter niet nodig.
Klik vervolgens op de knop 'Save & go to Services' onderaan en let verder even niet op alle andere opties. Na een korte denkpauze laat Check_MK dan zien welke afzonderlijke details hij op de toegevoegde host kan monitoren, bijvoorbeeld de geheugen en processorbelasting. Check_ MK noemt dat 'services'. Meestal hebben sommige de status 'OK' en andere 'PEND' – afhankelijk van de door de servicetest geleverde data kan Check_MK op dat moment nog niet overal de status van achterhalen. WATO stelt voor om alle gevonden services in de monitoring op te nemen. Dat doe je door op 'Monitor' te klikken.
Normaal gesproken selecteer je na het automatisch herkennen van de services welke je wilt monitoren en welke niet. Probeer gerust een paar dingen uit. Als je een service mist, kan dat liggen aan het feit dat er op de host software ontbreekt. SMARTdata van harde schijven vergen bijvoorbeeld smartmontools, IPMIdata vereist freeipmi enzovoort. Bovendien kan het nodig zijn op de host plugins voor de Check_MKagents toe te voegen.
Let op: bovenaan staat na een klik op 'Save & go to Services' een oranje gemarkeerde knop '1 change' (het aantal kan variëren). WATO voert configuratieveranderingen niet meteen uit, maar verzamelt die alleen, zodat er nog een handmatige actie voor nodig is om die door te voeren. Doe daar het volgende voor: als je op die oranje knop klikt, verschijnt er een nieuwe pagina waarbij je op de knop 'Acti vate affected' moet klikken. Als je dan met een klik op het Check_MKlogo linksboven naar de beginpagina teruggaat, moeten er bij de 'Service Statistics' een paar services (bij)gekomen zijn.
Eerste oogst
Als je bij 'Views / Hosts' op 'All hosts' klikt, toont Check_MK een lijst van de hosts die op dat moment gemonitord worden. Als je op de naam van een ervan klikt (in dit geval alleen nog 'localhost' van de door jou toegevoegde monitoringhost), krijg je de daarop beschikbare diensten te zien. Na een korte tijd komt er wat leven in het monitoren en ontstaan er aanklikbare grafieken voor 'CPU load' en verschillende andere vitale parameters, waaronder in eerste instantie altijd die van Check_MK zelf voor het aanroepen van de agents.
Geheel in overeenstemming met Nagios kent Check_MK drie toestanden voor services: 'OK' als alles goed gaat, 'WARN' betekent dat je wat moet doen, en 'CRIT' is een indicatie voor serieuze problemen. Er zijn er nog meer, maar die zijn voor het basisprincipe niet zo belangrijk. Grenswaarden voor de afzonderlijke services dan wel servicetypen bepalen wanneer een toestand verandert. Bij het overgaan naar een andere toestand kan Check_MK alarmen genereren, bijvoorbeeld emails versturen. Bovendien worden dergelijke toestandsveranderingen bewaard en kun je ze via 'Views / Other' bij 'Host and Service events' dan wel 'Hostand Service notifications' nog bekijken.
Om de sporen die je nu achtergelaten hebt te wissen en concreet met het opbouwen van een aan jouw doeleinden voldoende monitoring te beginnen, kun je op de monitoringhost nog een keer als gebruiker root op de commandline het commando omd stop test uitvoeren. Dan stop de testsite, waarna je die met omd remove test kunt wissen. Maak dan een nieuwe site aan. Probeer ook andere omdcommando's eens uit, bijvoorbeeld voor het kopiëren en backuppen. Achter het nietige omd blijkt een flink potentieel schuil te gaan. Met omd kun je sites kopiëren en in nieuwere Check_MKversies ook op dezelfde monitoringhost testen (ook de pakketten van de minorversies zijn parallel te installeren). Onder de motorkap maakt omd voor elke site een eigen gebruikersaccount op de monitoringhost aan. De bestanden inclusief de homefolder van de aangemaakte gebruikersaccounts komen in /omd te staan. Die elegante kunstgreep zorgt ervoor dat je Check_MK eerder op deze manier en niet via Docker en dergelijke zult gebruiken, die vergelijkbare updatehulp beloven.
Structuur opbouwen
Terug naar het inrichten van een monitoringsite. Je moet alles structureren wat bij een monitoring hoort. Wie moet er gealarmeerd worden? Hoe moeten meldingen verstuurd worden? Zijn services, hosts en gebruikers zinvol samen te voegen tot groepen? Welke host is afhankelijk van andere hosts? Waar zitten de uitzonderingen? Welke alarmgrenzen zijn afwijkend van de standaarden in te stellen, is dat individueel, apparaat of organisatiespecifiek?
Voor al die vragen biedt Check_MK hulp – met één uitzondering: wat er überhaupt zinvol gemonitord moet worden, moet je zelf beslissen. De automatische serviceherkenning maakt het makkelijk, maar ook snel onoverzichtelijk. Aan de andere kant schaadt het niet om services te monitoren waarvan het nut niet meteen duidelijk is – zolang die maar niet de hele tijd alarmmeldingen produceren.
Met WATO kun je meer gebruikers aanmaken ('Users') en hen verschillende rechten geven. Als de te monitoren hosts door verschillende groepen beheerd worden, kun je daar 'Contact Groups' van maken. De emailadressen dienen alleen voor het versturen van emails. Andere technieken zijn als 'Notifications' aan te maken, bijvoorbeeld voor pushberichten en sms, en die hangen normaal aan groepen.
Om de afhankelijkheden van de hosts van elkaar in Check_MK duidelijk te maken, kun je 'Folders' gebruiken, die WATO ook onder 'Hosts' kan aanmaken. Voor de in een folder staande host is een parent te definiëren. Als die niet bereikbaar is, dan worden de alarmmeldingen voor de ondergeschikte hosts uitgezet. Dat is bijvoorbeeld handig voor virtuele machines op een virtualisatieserver of een netwerksegment achter een router – je wordt bij het uitvallen van zo'n component dan niet overspoeld door allerlei alarmmeldingen.
Regelwerk
De belangrijkste organisatiehulp bij Check_MK om services en hosts te classificeren zijn de 'Host Tags'. Dat zijn niet meer dan labels die services, hosts en folders kenmerken. Speciale 'Auxiliary tags' kunnen meerdere tags samenvoegen tot een nieuw label. De tags verbinden individuele configuratieopties met hosts, folders et cetera. Een tak kan een simpele checkbox zijn of een selectie van meerdere opties.
Bij 'Host & Service Parameters' zijn de tags verschillend te gebruiken: 'Grouping' dient ervoor contacten en servicelevels in groepen onder te verdelen. 'Monitoring Configuration' overruled de standaardwerking van services en vervangt bijvoorbeeld de techniek waarmee Check_MK de bereikbaarheid van een host controleert als de standaardping niet mogelijk is, of verandert de frequentie waarmee de servicecontroles worden uitgevoerd. 'Access to Agent' stelt de parameters in voor bijvoorbeeld toegang tot SNMPhosts.
Bij 'Active checks' biedt Check_MK kantenklare tests voor gangbare diensten, bijvoorbeeld een die het versturen en ontvangen van emails test. Die tests hebben geen agent op de gemonitorde systemen nodig. Met 'Parameters for discovered services' kun je de standaard door services aangegeven alarmgrenzen aanpassen aan je eigen wensen voor bijvoorbeeld de minimaal vrij te houden ruimte op een schijf of de schijftemperatuur waarbij Check_MK waarschuwingen verstuurt.
De 'Datasource Programs' gaan over extra software om data te verzamelen. Daar biedt Check_MK bijvoorbeeld het monitoren van VMwareinstallaties ('Check state of VMWare ESX via vSphere') en het aanroepen van externe programma's ('Individual program call instead of agent access'). Dat laatste is te gebruiken om Check_MKagentaanroepen via een SSHverbinding te sturen.
Onafhankelijk van om welke van de aangeboden 'Host & Service Parameters' het gaat, de benodigde configuratie werkt altijd hetzelfde: je maakt een nieuwe regel aan waarmee je de details configureert. In de regel ken je tags, hosts en folders toe. Als je je hosts consequent met folders structureert, kun je onder omstandigheden zelfs helemaal zonder tags toe. Check_MK voert voor de opgegeven objecten de regel respectievelijk de operatie uit.
Check_MK herkent een inhoudelijke tegenstrijdigheid tussen regels overigens niet, die moet je zelf oplossen. De knop 'Ineffective rules' op de beginpagina spoort regels op die niet gebruikt worden. Met de knop 'Used Rulesets' krijg je de ingestelde en gebruikte regels te zien. Ook het zoekveld op de webpagina is handig om bepaalde functies gericht op te sporen. Het intypen van 'fritz' laat dan ' Check state of Fritz!Box Devices' uit de 'Datasource Programs' zien.
Werking
Deze opsomming van mogelijkheden stapt op zich wel heel nonchalant over de subtiele verschillen tussen de afzonderlijke methoden. Die leer je pas echt kennen als je zelf intensief regels gaat aanmaken en bepaalde diensten gericht wilt monitoren. Het is belangrijk dat je eerst weet op welke manier Check_MK de hosts aan de tand voelt: via een Check_MKagent, via SNMP of met een van de net genoemde 'Active checks'. Met passieve checks zijn nog extra data aan de monitoring toe te voegen.
Een korte blik op wat achter de coulissen gebeurt: de monitoringhost communiceert regelmatig met de agents op de te monitoren systemen. Dat gebeurt in een lokaal netwerk normaal gesproken via TCP op poort 6556. Je kunt op de host zelf de agents aanroepen of de tekstuitvoer van een Unixsysteem via Telnet bekijken (telnet localhost 6556 op de monitoringhost). Bij openbare netwerken is dat niet zo geschikt, daar kun je het verkeer en de toegang in het ideale geval veiliger via SSH laten lopen. Dat werkt bij de andere methoden grotendeels analoog: veel 'Active checks' leveren tekstdata, bijvoorbeeld voor mailrequests via IMAP. De monitoringhost verwekt de tekstuitvoer met daarop afgestemde Pythonscripts. Een Checkplugin bundelt de voor de agent en host benodigde scripts en informatie. Die helpen ook om de statistische data te verzamelen en voor te bereiden. Extra plugins komen via uitbreidingspakketten van Check_MK (MKP's) op de monitoringhost. De Raw Edition beheert die via mp op de commandline.
WATO levert een duidelijk overzicht van alle 'Check Plugins' met een gedetailleerde beschrijving van verwijzingen naar de bijbehorende regels. Dit is een goede plek om te achterhalen of er in het aanbod van Check_MK voor bepaalde monitoringtaken al kantenklare Checks bestaan. Het zoekveld is daar handig bij. Hier kom je er ook achter welke extra software er voor een Check eventueel nog op de gemonitorde host nodig is en of je de configuratie van de Check_MKagent daarvoor met een plugin moet uitbreiden.
Simpele regels
Genoeg theorie – tijd om eigen regels aan te maken. Een veel voorkomende taak is het aanpassen van alarmgrenzen voor bijvoorbeeld het schijfruimtegebruik van schijven.
Open een host, bijvoorbeeld via 'Views' onder 'Hosts' en 'All hosts' de als localhost aangemaakte monitoringhost zelf. Zoek een serviceregel die begint met 'Filesystem' en klik op het witte vierkant met een groene pijl erin. Dan opent een actiemenu, wat je ook op veel andere plekken bij Check_MK zult tegenkomen.
In het actiemenu staat de optie 'Parameters for this service', die je naar de parameterweergave voor deze service brengt. Bij 'Check Origin and Parameters' staat als tweede item weer een van die onduidelijke links met de naam 'Filesystems (used space and growth)' met daarachter in het grijs 'Default value'. Klik op de link voor een nieuwe dialoog, waarin je alleen een nieuwe regel kunt aanmaken. Klik daar op de knop 'Create rule in folder'.
Je komt dan bij een formulier waarop je de details van de regel kunt definiëren. Je moet altijd een zinnige beschrijving geven om het overzichtelijk te houden. Bij 'Parameters' kun je met het aanvinken van de checkbox voor 'Levels for filesystem' de alarmgrenzen aangeven. Zet de grenzen expres maar eens een stuk lager om een alarm te provoceren.
In de echte praktijk zou je bij 'Conditions' de regel beperken tot een host of het type van het bestandssysteem om bijvoorbeeld onder 'Mount Point' voor /var andere regels in te stellen dan voor / of in de Windowswereld andere voor C: dan voor D:. Om uit te proberen kun je de regels voor alle hosts laten gelden. Met de 'Save'knop onderaan bewaar je de regel. Om ervoor te zorgen dat Check_MK die kan gebruiken, moet je alle 'changes' weer activeren.
Na een tijdje of na een geforceerde 'Reschedule 'Check_MK' service' in het actiemenu moeten alle schijven die onder de ingestelde grens komen een 'Service Problem' melden. Als je dan weer naar 'Parameters for this service' gaat en de niet meteen duidelijke link aanklikt, dan laat Check_MK de actieve regels voor dat object zien. Als er meerdere regels gedefinieerd zijn, zullen gekleurde punten aangeven welke matchen (groen), welke complementeren (lichtgroen) en welke niet matchen (grijs). Dat is bij gecompliceerde regelsets erg handig.
Speciale regels
Regels worden ook gebruikt als je testoperaties wilt laten uitvoeren die geen onderdeel van agents zijn en daar ook niet met plugins mee uit te breiden zijn of als daarmee aanroepen van de te testen host niet zinvol is, bijvoorbeeld het regelmatig oproepen van een website of het testen van de bereikbaarheid van een IMAPmailbox. Check_MK gebruikt daar onder andere de monitoringplugin uit de Nagioswereld voor (van bijvoorbeeld www.monitoringplugins.org).
Het instellen van dergelijke 'Active Checks' is snel gedaan: zoek een bijpassende regel uit, vul de benodigde velden in en activeer de regel. Via namen of tags verbind je de regel met een of meerdere hosts. Als dat de enige test voor het betreffende systeem is, dan maak je de host aan en geef je als 'Agenttype' de optie 'No agent' aan. Check_MK controleert dan alleen de bereikbaarheid via ping.
Als geen van de voorgedefinieerde regels voor je geschikt is, kun je met ' Classical active and passive monitoring checks' op de monitoringhost eigen software uitvoeren en vervolgens door Check_MK laten verwerken. De output daarvan moet zich aan de gangbare conventies houden, die in de documentatie gedetailleerd beschreven is. Tot zo ver redelijk logisch allemaal. De integratie met bijzondere databronnen is in Check_MK echter wat meer eigenzinnig. Die is van toepassing als er wat hardere noten gekraakt moeten worden: op apparaten zoals een Fritzbox of storagesystemen kan geen Check_MKagent geïnstalleerd worden. Ze staan bij de 'Datasource Programs'. Je kunt ze vinden door naar de apparaatspecifieke interfaces te vragen. Bij een Fritzbox is dat bijvoorbeeld UPnP en voor een server IPMI. Voor dergelijke databronnen moet in de hostconfiguratie de tag 'Check_MK Agent' ingesteld zijn. Op de host hoeft geen agent ingesteld te worden, de speciale agent uit de 'Datasource Programs' krijgt die rol toebedeeld.
Veilig via SSH
Ook bij de 'Datasource Programs' is er weer een universele bron, namelijk 'Individual program call instead of agent access'. Die laat Check_MK het achterliggende commando oproepen, in plaats van een TCPverbinding naar de host, om de data bij een agent te verzamelen. Die bron is het centrale element om remote hosts met Check_MK in de gaten te kunnen houden.
SSH versleutelt de data en beschermt tegen ongewenste toegang. Check_MK biedt zelf ook versleuteling via preshared keys.
De volgende manier heeft zich bewezen voor het configureren: als 'Commandline to execute' volstaat 'ssh l root $_HOSTADDRESS_4$'. In het ideale geval stel je eerst een hosttag in waarmee je alle hosts kenmerkt die via SSH gemonitord moeten worden. Die tag selecteer je dan ook voor de SSHregel. Geef hem een bruikbare 'Description'. Dat was het dan wat Check_MK betreft, De rest regel je via de SSHconfiguratie.
Meld je via SSH als root aan op de monitoringhost en neem met su - test de rol aan van het door Check_MK voor de site aangemaakte gebruikersaccount ('test' is de gebruikers/sitenaam). Genereer een passphraseloze SSHkey op de monitoringhost met
ssh-keygen -f ~/.ssh/chkmkssh
Zet die in het bestand ~/.ssh/config als standaardidentiteit:
IdentityFile ~/.ssh/chkmkssh
Voeg voor elke host die via SSH gemonitord moet worden een blok in als volgt:
Host horst.example.com Hostname horst01.example.com Port 30201
Dan hoef je niet voor verschillende SSHpoorten telkens een nieuwe regel te definiëren en kun je ook met varianten van de hostnamen werken. Al dat configuratiewerk moet gebeuren onder het siteaccount op de monitoringhost.
Bovendien moet je op de te monitoren systemen de public key van de gegenereerde SSHsleutel (de inhoud van het bestand chmkmkssh.pub) in het bestand /root/.ssh/ authorized_keys invoegen. We adviseren dringend het uitvoerbare commando te beperken tot de Check_MKagent voor het geval de private key zonder passphrase in verkeerde handen terechtkomt:
command="/usr/bin/check_mk_agent",
no-port-forwarding ssh-rsa AAAA ...
Denk er ook aan om de na een standaardinstallatie naar poort 6556 luisterende Check_MKagent te deactiveren, bijvoorbeeld met
systemctl disable check-mk-raw-1.4.0p33 Als allerlaatste moet je ervoor zorgen dat de monitoringhost de SSHhostkey van de te monitoren host opneemt in zijn bestand known_hosts. Een SSHverbindingspoging vanuit de monitoringhost naar de te monitoren host is daar al genoeg voor.
Bij via SSH gemonitorde hosts, waar nog wat routers tussen zitten, is het aan te raden de hosttag 'Networking Segment' op 'WAN (high latency)' te zetten. Als de systemen bovendien achter een firewall staan en alleen via portforwarding te bereiken zijn, moet je voor die systemen een 'Host Check Command'regel instellen en daar 'Use the status of the Check_MK_Agent' selecteren.
Klassieke SNMP
Check_MK kan ook communiceren met apparaten die via SNMP te bevragen zijn, bijvoorbeeld switches, routers en printers. Het probeert daarbij de omvang van de opgevraagde data te minimaliseren. Net als zo vaak bij Check_MK leiden er meerdere wegen naar de data: bij de instellingen voor hosts kun je het 'Agent type' op 'SNMP (Networking device, Appliance)' zetten. Als alternatief kunnen ook beide databronnen afgeluisterd worden.
Daarnaast bestaat er bij het onderdeel 'Management Board' de mogelijkheid extra SNMPdata van een ander ipadres te halen, bijvoorbeeld een in een server ingebouwde managementboard. Die geven de al aanwezige data sowieso al aan de host door. Die optie vraagt afzonderlijk naar de communitycredentials. Voor de agents kun je die invullen met de regel 'SNMP credentials of monitored hosts'.
Veel dingen hebben we in dit artikel alleen maar even kunnen aanstippen. De documentatie staat online en is erg gedetailleerd. Geef jezelf wat tijd om Check_MK te leren kennen. Niet alles is even intuïtief te gebruiken. Een monitoringsysteem voor je eigen situatie moet altijd even rijpen: je leert van fouten, waar je vervolgens regels van kunt maken om de volgende keer niet meer verrast te worden. (nkr)
www.ct/nl/softlink/1807136