(function(d,s,i,r) { if (d.getElementById(i)){return;} var n=d.createElement(s),e=d.getElementsByTagName(s)[0]; n.id=i;n.src='//js.hs-analytics.net/analytics/'+(Math.ceil(new Date()/r)*r)+'/554273.js'; e.parentNode.insertBefore(n, e); })(document,"script","hs-analytics",300000);

APM3: een kijkje onder de motorkap

In een vorig artikel heb ik het over het nieuwe uiterlijk en mogelijkheden van APM gehad. Ik heb toen aangegeven dat voor de filtering- en groeperingsopties meer nodig is geweest dan een nieuw jasje. Ook onder de motorkap is APM volledig op de schop gegaan. In dit vervolgartikel vertel ik wat over de techniek achter het nieuwe APM v3.

Open source

Wij bij APM omarmen open source software. Zo draaien onze systemen Linux (Debian) en de APM infrastructuur volledig provisioned via SaltStack. De monitoring core van APM is gebaseerd op Nagios. Nagios is een van de meest betrouwbare, flexibele monitoringsoplossingen. Maar net als elk softwarepakket zijn er met Nagios grenzen aan de schaalbaarheid. Dit hebben wij opgelost door het inzetten van monitoring silo's.

APM_onder_de_motorkap.jpeg

Monitoring silo's

Op basis van Docker werken wij met losse containers per klant. Binnen zo'n 'monitoring silo' draait Nagios inclusief gerelateerde plugins/addons voor onder andere de verwerking van grafiekdata. Op deze manier combineren wij de kracht van Nagios met de schaalbaarheid van Docker. De silo's kunnen enkel van binnen naar buiten communiceren, niet andersom. Maar hoe kan de APM web client de monitoring data dan presenteren? De verzamelde monitoring data wordt vanuit de silo's naar een SQL- en ElasticSearch omgeving verstuurd.

API

De APM web client kan niet direct met de backend van APM communiceren. Alle data wordt via een API als 'doorgeefluik' (interface) opgehaald. Deze API is gebaseerd op het Django web framework. De achterkant van de API is gekoppeld aan Celery: een job queuing systeem voor realtime processing. Celery maakt gebruik van zogenaamde workers die de monitoring data uit de diverse bronsystemen halen.

Eén van die bronsystemen is ElasticSearch. ElasticSearch maakt realtime data direct doorzoekbaar. Voor nog meer efficiëntie en snelheid maken wij ook nog gebruik van Redis, een in-memory caching laag.

Resultaat

In een grote op Nagios gebaseerde omgeving met enkele jaren aan historische data duurt het opvragen van de host/service history (duizenden events) al snel een minuut(!). In APM3 duurt eenzelfde query door de inzet van ElasticSearch en slimme caching slechts 1 tot 2 seconden. Ook is het eenvoudig om een lijst met soms wel meer dan 1000 hosts te groeperen op basis van bijvoorbeeld omgeving of host type.

Wil je meer weten over de architectuur van APM en zelf ervaren hoe snel het systeem is? Schrijf je dan in voor het APM3 launch event op donderdag 13 oktober. Er zijn nog enkele plaatsen beschikbaar! 

Kom naar de officiële lancering op 13 oktober!

Gerelateerde artikelen