Nieuws

Achter de schermen: Monitoring

Gepubliceerd op dinsdag, 06 mei 2014 door Robin Mulder

Wij krijgen regelmatig de vraag van klanten hoe wij bepaalde technische zaken geregeld hebben. Automatisering speelt daarbij een grote rol. Het zal u misschien verbazen dat wij net zoveel developers als support engineers in dienst hebben. Door het automatiseren van eenvoudige taken kunnen onze support engineers zich volledig richten op het contact met de klant om specifieke vraagstukken en problemen op te lossen.

In een nieuwe serie van artikelen willen wij een kijkje achter de schermen geven, met als eerste onderwerp: monitoring. De monitoring van onze diensten is een essentieel onderdeel van onze dienstverlening. Hiermee zijn wij direct op de hoogte als er een storing is of als die dreigt plaats te vinden (bijvoorbeeld doordat de performance niet aan onze eisen voldoet).

Monitoring

Een essentiële tool hiervoor is Nagios. Een opensource monitoring tool waarmee wij onze faciliteiten en servers met een SLA in de gaten houden op diverse aspecten. De unieke configuratie per server genereren wij dynamisch gebaseerd op de uitgebreide server informatie die wij bijhouden in onze administratie. Bij een virtuele server monitoren wij bijvoorbeeld of bepaalde services (zoals HTTP en SMTP) bereikbaar zijn maar ook wat de belasting van een server is of hoeveel schijfruimte er in gebruik is. Wij monitoren dit vanuit diverse locaties in andere datacenters en netwerken dan waar onze apparatuur staat. Zo zijn wij ook altijd direct op de hoogte als er een probleem in ons datacenter of netwerk is.

Notificaties

Zodra er een probleem wordt geconstateerd krijgen wij op kantoor direct een melding via webnotificaties en op TV schermen die door het hele kantoor hangen. Deze schermen laten gelijk relevante statistieken en informatie over die server zien zodat wij snel inzicht hebben in waar het probleem kan liggen. Als er geen storingen zijn dan laten deze schermen andere informatie zien, zoals de performance van ons Cloud Platform, inkomende telefoongesprekken, gemiddelde ticket responstijd en andere nuttige statistieken.

Buiten kantooruren

Buiten kantooruren maken wij gebruik van push berichten naar de telefoons van de dienstdoende engineers. Als er niet op tijd wordt gereageerd dan zal de dienstdoende engineer gebeld worden. Wordt er dan nog niet gereageerd dan wordt het probleem automatisch geëscaleerd naar de volgende engineer totdat iemand aangeeft er mee bezig te zijn. Dit zorgt ervoor dat wij altijd zo snel mogelijk een storing oplossen en dat wij nooit afhankelijk zijn van enkele personen, ook wanneer dit midden in de nacht is. Om dit proces goed te laten verlopen maken wij naast onze eigen tools ook gebruik van diensten zoals PagerDuty en Pushover.

Softwareversies

Een ander belangrijk aspect die wij monitoren bij een SLA is of alle software waar een server gebruik van maakt geen bekende lekken heeft. Hiervoor hebben wij eigen software geschreven die elke dag onder andere de geïnstalleerde softwareversies op een server doorgeeft aan onze administratie. Zodra er bijvoorbeeld in een bepaalde versie van PHP een lek bekend wordt gemaakt dan kunnen wij dat aangeven in onze administratie en zien wij meteen welke servers een update nodig hebben.

Onlangs hebben we dit systeem nog gebruikt om snel inzichtelijk te maken welke servers vatbaar waren voor het kritieke lek in OpenSSL. Mede hierdoor konden we gericht servers bijwerken en hadden we het lek al grotendeels gedicht voordat het bekend werd bij het grote publiek.

In een volgend artikel zullen wij nog verder ingaan op welke monitoring informatie er allemaal te zien is op onze TV schermen, de implementatie hiervan en hoe deze in de praktijk gebruikt worden om storingen te voorkomen.