Proactieve server- en netwerk monitoring door nieuw monitoringsysteem van Icinga

Tijdens een intern overleg 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 gemaakt worden 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 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.


Door: Bart Vrancken