17 okt Van Monitoring naar Observability: waarom Zabbix niet meer goed werkte
Het Guardian360 Lighthouse platform valt of staat met de goede werking van de scanner probes en hacker alert appliances. Deze probes en hacker alert appliances draaien op kleine servertjes in het netwerk van de klant, de zogenaamde ‘appliances’. De goede werking hiervan is dus essentieel. Maar hoe weten we of een appliance goed werkt en is voorzien van de laatste updates? En als het stuk is, hoe weten we dan wat te doen?
Afscheid van Zabbix. Het hoe en waarom
Het Guardian360 Lighthouse platform bestaat al sinds 2015. Eerst gebruikten we voor het monitoren van dit platform en alle appliances het Zabbix platform – en dat doen we nog steeds, maar wel minder. In het begin en feitelijk tot nog niet zo heel lang geleden werkte Zabbix redelijk goed voor onze use case. Maar met de forse groei van het aantal partners en klanten en de bijbehorende groei van het aantal appliances kwamen we er achter dat Zabbix eigenlijk niet goed mee kan groeien en dat we uiteindelijk afscheid moeten gaan nemen van Zabbix.
Zabbix is gebaseerd op blackbox monitoring. Je bekijkt van buitenaf wat de status is van een server, hoeveel CPU en geheugen gebruikt wordt, hoe vol een disk is. Functioneert het goed, of is het stuk?. Als je een alarm krijgt omdat er iets niet in orde lijkt te zijn, dan ga je kijken wat er dan precies mis is, op basis van kennis en ervaring van de engineer.
2 dagen queue teveel, de rek was eruit
Uiteindelijk gingen we Zabbix meer verantwoordelijk maken voor status van de appliance, want als die niet juiste status heeft, dan kunnen de probes niet scannen, worden criminelen niet in netwerken betrapt, wordt de appliance niet bijgewerkt en dan kom je heel snel in de problemen. Maar ook wilden we CPU en memorygebruik liefst ‘live’ bij laten werken. Er werden triggers op dat soort metrics gezet en waardes afgebeeld op het Lighthouse dashboard. In het begin was dat erg leuk, maar door alle checks, actions, triggers gooit Zabbix alles in een wachtrij (de ‘queue’). Deze moet worden uitgelezen door ‘workers’. Er werden te veel checks uitgevoerd, waardoor de taken in de queue opstapelden tot ongekende hoeveelheden. We hebben daar als technisch team veel aan getunden getweakt, maar het schaalde uiteindelijk toch niet. Het bijwerken van statussen is heel belangrijk, maar werd steeds verder weggeduwd in de wachtrij. Het kon soms wel tot 2 dagen duren voordat updates werden uitgevoerd. En dat is uiteraard heel ongewenst.
Van blackbox naar whitebox monitoring
De cloud platform migratie was de feitelijke trigger om een tool te bouwen op de appliance zelf. Dus om weg te gaan bij het blackbox – extern – monitoren van appliances. We gaan dus van blackbox monitoring naar whitebox monitoring: van reactief naar voorspellend. Deze tool is dan verantwoordelijk voor het laten zien wat de exacte status is van de appliance. Ook voor de klant zelf, met veel meer inzicht dan eerst. Deze tool hebben we liefkozend ‘ApMon’ genoemd, wat een afkorting is voor ‘Appliance Monitor’.
Doorontwikkelen ApMon en Lighthouse dashboard
De eerste versie draaide afgelopen december (2022) al op de probes. Nu wordt er gewerkt aan het verder uitbreiden van ‘ApMon’ om meer observability mogelijkheden hier in op te nemen. Opvolgend zullen deze observability metrics een onderdeel worden in het Lighthouse dashboard. Alle appliances eigen monitoring geven werkt veel beter dan een ‘Single point of failure’ als Zabbix. Klanten kunnen uiteindelijk ook intervallen van observability zelf bepalen, de status van een appliance wordt live en realtime bijgewerkt, enzovoorts. Dat dus in plaats van 2 dagen wachten!
Het fenomeen ‘Observability’
Je zou kunnen denken dat Monitoring en Observability feitelijk hetzelfde is. Toch is er een fundamenteel verschil.
Monitoring is een meer traditionele aanpak en richt zich op het verzamelen van gegevens over bekende, vooraf gedefinieerde variabelen of toestanden van een systeem. Denk aan bijvoorbeeld CPU-gebruik, geheugengebruik, netwerklatency of andere duidelijke indicatoren. Monitoring is vaak gericht op het verzamelen van dit soort gegevens om te waarschuwen wanneer bepaalde drempelwaarden worden overschreden. Het doel is meestal het opsporen en snel reageren op problemen om de beschikbaarheid en prestaties van het systeem te handhaven.
Observability is een breder concept en biedt meer diepgaande inzichten in de interne toestand van een systeem, vaak in real-time. Het gaat erom het systeem te begrijpen vanuit de uitvoer die het genereert. In een “observable” systeem kunnen gebruikers vragen stellen die ze vooraf niet noodzakelijkerwijs hebben bedacht. Dit kan helpen bij het begrijpen en vaststellen van onverwachte problemen of gedrag van een systeem van meer kanten te kunnen bekijken. Observability kan gebruik maken van metrics en logs om een overzichtelijk beeld te geven van de toestand van een systeem.
Alle voorbereidingen voor de grote uitrol van ApMon zijn al klaar. We hebben beslist om te wachten tot de cloud platform migratie, niet eerst op het oude platform alles uit te rollen en dan weer te moeten migreren. Duurt dus nog even, maar het komt eraan (echt waar J).
Observability zorgt voor hogere uptime
Een kleine set aan nieuwe features: ApMon wordt interactief: de klant kan scans opnieuw laten uitvoeren en uiteindelijk via de website de appliance besturen. Dit grijpt dan weer in met Teleport, maar werkt dankzij de lokale installatie op de appliance ook als je geen internet hebt. ApMon zal uiteindelijk het ‘grote brein’ worden dat appliances bewaakt en bestuurt op basis van actuele inzichten die live verzameld worden. Observability leidt dus tot uiteindelijk hogere uptime en meer mogelijkheden. Dat wil je toch?
Sorry, het is niet mogelijk om te reageren.