Proactieve server- en netwerk monitoring door nieuw monitoringsysteem van Icinga


Tijdens een intern overleg bij BIT kwamen we tot de conclusie dat het wel eens tijd werd om ons monitoringsysteem te upgraden. Sinds de installatie 8 jaar geleden zijn er betere open-source monitoringpakketten beschikbaar gekomen. Nadat we een aantal van deze pakketten hadden getest, kwam Icinga voor ons als beste uit de bus. De voornaamste reden was dat het systeem bijzonder dynamisch te configureren is en naadloos aansluit op de werking van onze administratiesystemen.

Incinga vs. Nagios
Icinga (1.x) is gebouwd met Nagios als basis en ondersteunt daarom ook één-op-één onze huidige Nagios-configuratie. Hierdoor zou het relatief eenvoudig zijn om onze configuratie over te zetten en daarmee vooral in de performance veel verbetering te zien. Met de nieuwste versie (2.x) is Icinga overgestapt naar een eigen configuratiemethode. Deze lijkt veel op de Nagios-configuratie, maar met het belangrijke verschil dat je middels scripts objecten automatisch kunt genereren en koppelen aan andere objecten. In deze configuratie kan ook gebruik worden gemaakt van variabelen die we naar wens kunnen instellen. Hierdoor is het mogelijk om bij hosts het operating system, bijvoorbeeld Linux, op te geven en vervolgens automatisch controles voor SSH en andere Linux specifieke controles toe te voegen.

Bij gebruik van een monitoringsysteem wil je niet beperkt worden door hoe vaak een check gedraaid kan worden. Onze Nagios installatie had regelmatig moeite om binnen de 5 minuten interval voor checks te blijven. Schaalvergroting van Nagios was daarmee uitgesloten. Icinga daarentegen verwerkt alles vele malen sneller, zelfs als we de minimale interval van alle controles van 5 minuten naar 30 seconden zetten draait Icinga daar zijn hand niet voor om.

Redundantie door twee actieve systemen
Verder heeft Icinga de mogelijkheid tot clustering. In onze nieuwe opstelling hebben wij twee actieve systemen die samen alle monitoringacties uitvoeren en die afzonderlijk van elkaar ook notificaties versturen. Beide systemen houden van elkaar bij waar ze mee bezig zijn zodat er niets dubbel gedaan wordt. Op het moment dat er een systeem zou wegvallen, kan er zonder verstoring gewoon doorgewerkt worden en neemt het andere systeem alle monitoringtaken over. Met twee actieve systemen weten we ook zeker dat de configuraties hierop correct zijn, zonder dat we een failover hoeven te doen zoals met Nagios.

Waar we vroeger aan NRPE gebonden waren, kunnen we nu veel eenvoudiger grote klantsystemen monitoren met remote satellites (RS). Deze remote satellites zijn indien gewenst ook weer redundant op te zetten. Satellites ontvangen hun configuraties automatisch van onze monitoringservers. Door het aanpassen van onze eigen configuratie kan ook meteen de klantconfiguratie worden bijgewerkt. De remote satellites voeren alle controles zelf uit en verwerken centraal het resultaat. Deze informatie wordt vervolgens naar onze systemen gestuurd, zodat (als dat met de klant is afgesproken) wij een oogje in het zeil kunnen houden en/of kunnen reageren op monitoringmeldingen. Onze monitoring toont deze resultaten waar onze eigen systemen zelf deze controles zou uitvoeren.

Flexibelere controles
Een van onze grootste ergernissen was het gebruik van SNMP voor het monitoren van processen op servers. Diverse situaties zorgden voor allerlei valse meldingen van het monitoringsysteem. Denk hierbij bijvoorbeeld aan een hangende NFS mount die ervoor zorgt dat SNMP niet meer werkt, alle monitoringchecks die over die NFS mount via SNMP draaien zullen falen. Of wanneer speciale wrappers nodig zijn om een script voldoende rechten te geven om alle data op te kunnen halen, maar SNMPd niet voldoende rechten krijgt. Om dit op te lossen hebben we een agent (bit-monitoring agent) gemaakt in Perl zodat we het gebruik van SNMP kunnen minimaliseren en veel flexibeler nieuwe (niet standaard) controles kunnen toevoegen. Deze agent stuurt versleuteld middels een JSON-call de resultaten van de lokaal uitgevoerde controles naar onze monitoringsystemen.

Op het moment dat bit-monitoring geïnstalleerd is, zal de ‘UP’ status van een server niet meer via de standaard ICMP check verlopen, maar stuurt bit-monitoring zelf een bericht dat het systeem nog draait. Dit is vele malen interessanter om te weten. Als een server uit geheugen is gelopen, zal deze veelal nog wel via ICMP bereikbaar zijn, maar functioneert hij eigenlijk niet meer. Op het moment dat de bit-monitoring agent zich niet meer meldt bij onze monitoringservers, gaan deze automatisch over naar een ICMP controle zodat we een beter beeld krijgen van wat er precies mis is.

Zelfstandig onderhoud aan eigen servers inplannen
Een van de laatste interessante verbeteringen in het platform is dat we intern gebruik kunnen maken van het LiveStatus protocol. Hiermee kunnen we gegevens met andere BIT systemen uitwisselen en kunnen we in de toekomst bijvoorbeeld de status van de servers van klanten in de portal pagina weergeven en kunnen klanten ook zelfstandig onderhoud in onze monitoringsystemen inplannen voor hun servers.

Templates
Voor ons genoeg redenen om over te stappen. Met het voorstel van de nieuwe configuratie zijn we begonnen met een project dat uiteindelijk een jaar heeft geduurd. Hierbij zijn de bijna 25.000 objecten die ons monitoringsysteem uitvoert omgezet naar een nieuwe Icinga opstelling. Zaken die we met regelmaat gebruiken hebben we in templates gezet en middels simpele variabele kunnen we ze activeren.

Migratie
Verder moeten ook alle bestaande en complexe Nagios opties, zoals SMS-, telefonische-, IRC- en e-mailnotificaties overgezet worden. Nadat we enkele maanden op zowel een Nagios- als een Icinga (zonder notificaties) systeem actief hebben gedraaid, om te controleren of de configuratie correct is overgezet, hebben we eind vorig jaar de knop omgezet en draaien we nu volledig op onze nieuwe Icinga platform.

We zijn erg blij met het resultaat en de enorme snelheid van ons nieuwe monitoringsysteem.

Geschreven door Bart Vrancken (BIT)

Dit ingezonden artikel is geschreven door Bart Vrancken van BIT.

Lees ook de onderstaande artikelen van BIT

Stuur ook uw blog, achtergrond artikel of andere bijdrage in!

Indien u zelf een interessante bijdrage, zoals een blog, how-to of achtergrond heeft, dan plaatsen wij die graag en dat kost u niks. Neem contact op met de ISPam.nl redactie via [email protected] of kijk op deze pagina voor meer informatie over het leveren van een bijdrage aan ISPam.nl.

Marin Heideman, 10 maart 2016 11:07 am

Wij gebruiken al geruime tijd Icinga, en naar volle tevredenheid. Echt een top systeem. Duidelijke overzichten. Momenteel zijn wij aan het kijken hoe wij onze klanten kunnen voorzien van duidelijke rapportages met dit systeem.

Jeroen, 10 maart 2016 11:22 am

Nagios is ook goed te clusteren/HA'en/schalen, kijk daarvoor eens naar mod_gearman. Omdat Nagios met text config files werkt kun je met eigen scripting ook prima geautomatiseerd checks toevoegen afhankelijk van het OS, of iets fysiek of virtueel is etc. Voor de echte Nagios liefhebbers ;)

Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.