Hoe pak je de monitoring van kritische applicaties in een hybrid cloud omgeving aan?

Al je systemen zijn ingericht en draaien. Dus waarom is monitoring dan zo belangrijk? Een goede vraag. Als er in je omgeving niets verandert en/of er geen afhankelijkheden zijn, dan is monitoring niet nodig. Maar dit soort omgevingen bestaan vandaag de dag niet meer. Kritisch applicaties en omgevingen maken vaak deel uit van een (informatie)keten en systemen worden constant belast en bevraagd. Om continu inzicht te hebben in de gezondheid van je systemen en je gehele technische en functionele keten, is de monitoring stack van (levens)belang.

Maar wat bedoelen we precies met monitoring? Bij monitoring moet je denken aan een grote diversiteit aan informatie die jou via tooling inzicht geeft in je omgeving. Dat inzicht vertaalt zich in sommige gevallen naar acties in de vorm van alerting bij ‘verdachte’ situaties. Wat een verdachte situatie is, is erg afhankelijk van de context van de omgeving. Dit kan beginnen bij basis zaken als het vollopen van storage of geheugen, maar ook het wel/niet afleveren van data (informatie) binnen een keten.

Een steeds belangrijker onderdeel binnen monitoring is security monitoring. Waar dit vaak als los onderdeel wordt gezien, is het belangrijk om dit in het basis ontwerp van je monitoring oplossing mee te nemen. Informatiebronnen als antivirus, intrusion detectie systemen en vulnerability scanning horen bij de databronnen die gebruikt worden om een volledig overzicht te creëren binnen je monitoring oplossing.

De data uit al deze bronnen worden in monitoring oplossingen inzichtelijk gemaakt, maar voor wie eigenlijk? Het is belangrijk bij de inrichting en keuze van tooling om na te denken voor wie deze inzichten eigenlijk bedoeld zijn. Zo kan een dashboard voor een engineer er anders uitzien dan voor een manager. Binnen kritische landschappen is inzicht voor een Operations Center, zoals bij Conclusion Mission Critical, ook een doelgroep die hierin wordt meegenomen. Hierover later meer.

Zoals beschreven zijn er veel onderdelen om over na te denken bij het kiezen en inrichten van je monitoring oplossing. Een hybride omgeving maakt de context waarin je deze oplossing neerzet complexer. Er komen dan ook andere zaken bij kijken waar rekening mee gehouden moet worden. Denk hierbij aan:

• Meer afhankelijkheden in informatieketens;
• Inrichting en monitoring van connectiviteit;
• Afweging welke diensten je monitort;
• Agent of agentless monitoring.

Door de combinatie van cloud omgevingen waarbij bijvoorbeeld meerdere private en public clouds worden gecombineerd, ontstaan er vaak meer afhankelijkheden in informatieketens. Deze moeten binnen de monitoring oplossing extra aandacht krijgen. Daarin is connectiviteit een belangrijk onderdeel. Niet enkel moet deze betrouwbaar zijn ingericht in hybride omgevingen, ook de connectiviteit moet worden gemonitord. Dit moet niet alleen op beschikbaarheid van de connectie (active), maar ook zaken als bandbreedte en latency kunnen daarin belangrijk zijn.

Uniformiteit binnen clouds is een lastig onderwerp. Hoewel functioneel er in de private en public clouds veel overlap is, is de technische uitwerking vaak anders. En daarmee dus ook de manier om deze cloud native oplossing (bijv. AWS Lambda) te monitoren. Serverless monitoren vereist bijvoorbeeld een hele andere manier van monitoren. Hier gaat het er meer om of de taak is uitgevoerd dan dat het component beschikbaar is. Je moet ook de afweging maken of je de diensten gaat monitoren, en het kan zijn dat het systeem of de situatie om verschillende monitoring oplossingen vraagt. Moet deze bijvoorbeeld agent of agentless zijn? Daar waar netwerkapparaten vaak (dan wel niet altijd) agentless worden gemonitord, is dit voor andere systemen niet het geval.

Het is dus belangrijk om goed inzichtelijk te hebben hoe je omgeving eruit ziet en gaat veranderen in de toekomst, om een duurzame monitoring oplossing te kiezen en in te richten. We hebben al een paar uitgangspunten en aandachtspunten de revue laten passeren. Maar er zijn nog een aantal zaken belangrijk om mee te nemen in de keuze voor je monitoring oplossing.

De kosten
Natuurlijk zijn daarbij de kosten voor de oplossing niet onbelangrijk. Daarin zijn SaaS oplossingen (van leveranciers) vaak opportuun, maar moet er wel goed nagedacht worden over de afhankelijkheid van deze dienst, de SLA, de schaalbaarheid, mogelijke lockin en dus het kostenmodel. Tevens moet er goed gekeken worden naar de retentie van data en aantal hosts / componenten die worden gemonitord door een realistisch prognose te maken van je omgeving en de groei (dan wel krimp) hiervan.

De topologie
Vaak wordt er bij de inrichting van de monitoring weinig rekening gehouden met de daadwerkelijke context van de monitoring. Deze is vaak te vangen in de topologie van de omgeving. Deze topologie kan engineers helpen bij incidenten om snel tot een RCA (Root Cause Analyse) te komen. De topologie moet daarbij niet enkel uit de componenten bestaan, maar ook waar deze voor is. Denk daarbij aan de applicatie waar deze componenten bij horen, of de keten waarin deze applicatie een rol speelt.

De doelgroep
Wanneer je de context van de doelgroep meeneemt in je monitoring, maak je deze nog effectiever. Daarin is het goed om na te denken voor wie je welk overzicht maakt. Er is namelijk ander inzicht nodig voor iemand binnen je Operations Center, om snel de impact te kunnen inschatten en de regievoering te kunnen doen, dan voor een engineer die de RCA uitvoert en het incident gaat oplossen. Dit principe kun je ook toepassen op dashboarding voor een directie en/of de klant zelf.

Conclusion Mission Critical is verantwoordelijk voor een grote diversiteit aan omgevingen waar kritische applicaties draaien. Daarin hebben we gekozen voor een monitoring oplossing die uit verschillende onderdelen bestaat. De tooling die wij hiervoor gebruiken is A-label, opensource en in-house ontwikkelde software.

Platform agnostische inrichting
Doordat we binnen de klantomgevingen niet afhankelijk kunnen zijn van de monitoring tooling van externe dienstverleners voor de beschikbaarheid van de omgeving, is er voor gekozen om de monitoring oplossing platform agnostisch in te richten en binnen de klantomgeving te plaatsen. Daarin is de basis geborgd in oplossingen als Zabbix en de ELK Stack. Door flexibiliteit in configuratie kan er per klantomgeving worden gekozen voor verdere integratie en alerting door middel van bijvoorbeeld Telegram of Microsoft Teams.

Om een helder en volledig overzicht te hebben over alle klantomgevingen heen, gebruiken we StackState om een “Single pane of glass” te creëren. Hierin gebruiken diverse bronnen als Zabbix, ServiceNow en platform informatie (eq. AWS), om een topologisch volledig automatisch overzicht te creëren voor onze engineers.

Dankzij de integratie met bijvoorbeeld VMware leest StackState de topologie uit en krijgt de informatie over welke VM op welke vSphere host draait en op welke datastore de disks van die VM staan. De integratie met Zabbix zorgt ervoor dat alle checks en triggers die je hebt gedefinieerd op een VM ook in StackState zichtbaar zijn wanneer er een event plaats vindt. En de ServiceNow integratie zorgt ervoor dat de relaties die in ServiceNow zijn gedefinieerd door komen in StackState en dus dat VMx onderdeel is van App x/Dienst x/Team x.

Het is dus belangrijk om goed inzichtelijk te hebben wat je voor wie monitort met welk doel. Door deze zaken mee te nemen en monitoring te zien als kritisch onderdeel van je beheeromgeving kun je in een hybride situatie je kritische applicaties op een duurzame manier in de gaten houden.