• Expertises

    Door middel van welke expertises we jouw organisatie ondersteunen

  • Hoe we met succes voor een scala aan klanten van betekenis zijn geweest

  • Over Application Innovation, onze werkwijze en wat we voor je kunnen betekenen

  • Nieuws, events en artikelen van Application Innovation

  • Nieuwsgierig geworden? Kom werken bij Conclusion Application Innovation

Van on-prem naar serverless applicatie error monitoring

In missie kritische omgevingen is het belangrijk om applicaties en componenten goed te monitoren. Een van de mogelijke tools hiervoor is SCOM. Collega Raymon legt in dit blog uit hoe SCOM precies werkt en hoe wij dit voor onze klanten inzetten.

12 juli 2021   |   Blog   |   Door: Conclusion Application Innovation

Deel

Ik ben Raymon, ontwikkelaar in het CloudOps-Enablement (CE) team van Conclusion Application Innovation. Binnen dit CE team doen wij het pionierswerk voor de overige ontwikkelteams en maken wij hen het leven zo makkelijk mogelijk. Als onderdeel van deze functie zijn wij medeverantwoordelijk voor het inrichten van monitoring op de omgevingen van Conclusion Application Innovation. Samen met een teamgenoot heb ik recent een project aangepakt om een monitoring oplossing met SCOM beter te laten aansluiten op de huidige cloud-native realiteit.

Veel van onze opdrachtgevers komen van een situatie waar de meeste van hun applicaties in een lokaal serverpark draaien. Voor een van onze grootste opdrachtgevers is dat niet anders. Uiteraard is het belangrijk om alle applicaties en componenten goed te monitoren, zeker in een hoog beschikbare en missie kritische omgeving. Een van de meest gebruikte tools in dit soort situaties is Microsofts eigen monitoring suite: SCOM.

SCOM wordt in ons geval bijvoorbeeld gebruikt om applicatie foutmeldingen te ontvangen, verwerken en naar het 24/7 Operating Centrum te versturen ter beoordeling. Op deze manier kunnen fouten in applicaties in productie snel gespot en afgehandeld worden, om minimale downtime te veroorzaken. Door de migratie naar AWS is hier een klein probleem ontstaan, aangezien SCOM niet ontwikkeld is voor Cloud oplossingen. Tegelijkertijd is SCOM zo’n integraal onderdeel geworden van de monitoring strategie voor deze opdrachtgever, dat het eigenlijk onmogelijk is dit op korte termijn te vervangen.

Het resultaat werd een oplossing waarbij SCOM toch gevoed kan worden met foutmeldingen uit applicaties die in AWS leven.

Het voordeel van een AWS Kinesis stream is dat er meerdere gebruikers van de binnenkomende data aan gekoppeld kunnen worden. Zo is er dus een gebruiker die de data naar ons ElasticSearch cluster brengt. Maar ook andere gebruikers, zoals voor monitoring op andere plekken, kunnen moeiteloos toegevoegd worden."

.
Het landschap

De situatie voor deze opdrachtgever is vrij complex. Vanwege de weg die zij jaren geleden hebben gekozen, is een situatie ontstaan met verschillende Business Units die in veel gevallen met elkaar gegevens uitwisselen, maar toch onafhankelijk zijn. Om dit ontwerp in stand te houden zijn alle applicaties verdeeld over 10 AWS accounts. Alle accounts hebben eigen logging en monitoring, welke geconsolideerd worden in een centraal monitoring account. Hier leeft een AWS Kinesis stream welke de data van alle accounts ontvangt, en doorstuurt naar een ElasticSearch oplossing met Kibana, welke ook in dit account leven. Zo kunnen ontwikkelaars en technische specialisten altijd bij de data van verschillende accounts om hun omgevingen en applicaties te monitoren en troubleshooten.

Het voordeel van een AWS Kinesis stream is dat er meerdere gebruikers van de binnenkomende data aan gekoppeld kunnen worden. Zo is er dus een gebruiker die de data naar ons ElasticSearch cluster brengt. Maar ook andere gebruikers, zoals voor monitoring op andere plekken, kunnen moeiteloos toegevoegd worden.

Ronde 1: SCOM voorzien van foutmeldingen

Dankzij de opzet met deze AWS Kinesis stream, was het ook mogelijk om via een kleine omweg de data die in de Cloud leeft toch naar SCOM te vertalen. Dit hebben wij opgelost door een eigen service te schrijven die een aantal taken verrichte.

Allereerst is een server nodig waar de SCOM agent op kan draaien om data te vergaren en versturen. Deze stap is nog vrij eenvoudig op te lossen door simpelweg een EC2 instantie op te starten met de SCOM agent geïnstalleerd. Puntje van aandacht: deze instantie kan nooit uitgezet worden, want iedere keer dat een instantie uit gaat en opnieuw opstart heeft deze een nieuw IP-Adres. Daarmee zou deze iedere keer opnieuw aangemeld moeten worden in SCOM.

De SCOM agent haalt zijn logging data uit de Windows event logs. Om iedere applicatie te kunnen monitoren is daarom voor elke applicatie die voorbijkomt in de AWS Kinesis stream een groep aangemaakt in de Windows event log. Zo kunnen alle error berichten die van een bepaalde applicatie komen ergens landen.

Om de Windows event log te kunnen vullen, schreven wij een service die rechtstreeks de AWS Kinesis stream aanspreekt om te zien of daar nog nieuwe data op staat. Vervolgens filtert de service de berichten met foutmeldingen eruit en negeert de rest. Nadat een bericht van een bepaalde applicatie is opgepikt, kan de service een groep aanmaken in de Windows event log voor deze applicatie. Vervolgens worden alle foutmeldingen in de bijbehorende groep geplaatst. De SCOM agent zal iedere 15 minuten de Windows event logs scannen om te zien of er nieuwe groepen aangemaakt zijn. Alle groepen die zijn opgemerkt door de SCOM agent worden continu gemonitord en foutmeldingen worden via SCOM naar het 24/7 Operating Centrum gestuurd.

Door alarmen in te stellen in AWS CloudWatch zijn we direct een stuk meer op de hoogte van eventuele haperingen in de verwerking en kunnen we daar meteen op handelen."

.
Ronde 2: gemiste foutmeldingen

Deze oplossing bracht na verloop van tijd een paar aandachtspunten met zich mee. Door de werking van de SCOM agent, welke iedere 15 minuten een scan uitvoert naar nieuwe event sources (de eerder genoemde groepen), worden er sporadisch logs gemist. Wanneer bijvoorbeeld een foutmelding binnenkomt voor een nieuwe applicatie, net nadat een scan is gepasseerd, kan het tot 15 minuten duren voordat de event source is gescand en de bijbehorende foutmeldingen door komen.

Ditzelfde probleem zorgt er ook voor dat wanneer een event source gescand wordt nadat de foutmeldingen zijn weggeschreven, de foutmeldingen niet meer worden meegenomen door de SCOM agent. De agent gaat namelijk vanaf dat moment ‘luisteren’ naar binnenkomende berichten. Eerder binnen gekomen berichten worden zo nog wel eens gemist.

Omdat de service op een EC2 instantie draait en de AWS Kinesis stream bevraagd wordt voor nieuwe data, valt er nog wel eens een bericht tussen wal en schip. De precieze oorzaak hiervan hebben we nooit goed vast kunnen stellen. De service zet in ieder geval een verbinding op met de AWS Kinesis stream, bevraagt deze een minuut lang voor nieuwe data en gaat deze dan verwerken. Als er geen nieuwe data binnen komt, gaat de verbinding uit en wordt een nieuwe opgezet om wederom een minuut lang te bevragen. Het lijkt erop dat er af en toe data tussen de momenten van uitvraag in vallen en op die manier niet aan komen op de instantie bij de SCOM agent. Wellicht omdat een verbinding niet slaagt of ergens anders fouten optreden, maar dat is niet zichtbaar.

Buiten deze problemen, voldoet dit design niet aan de principes die AWS voorstelt voor het ontwikkelen van serverless oplossingen. En dus was het tijd dit ontwerp eens op de schop te gooien.

Ronde 3: van pull naar push

Een van de onderdelen in het ontwerp waar wij niet blij mee zijn, is het constant moeten draaien van een EC2 instantie. Omdat een vers opgestarte SCOM agent iedere keer moet worden aangemeld in SCOM, is het eigenlijk niet goed mogelijk om hier een andere oplossing voor te vinden. Voor nu accepteren we het feit dat we een instantie moeten blijven draaien tot daarvoor een betere oplossing is gevonden.

Dan is er nog het issue van nieuw aangemaakte event sources die niet op tijd worden opgemerkt door de SCOM agent, waardoor berichten verloren kunnen gaan. En het issue dat tijdens het bevragen van de Kinesis stream nog wel eens wat berichten verloren lijken te gaan.

Om dat laatste aan te pakken, hebben we ervoor gekozen om over te stappen op een push-constructie in plaats van een pull-constructie. De AWS Kinesis stream bestond al, dus het enige dat daaraan toegevoegd diende te worden is een gebruiker van de data op de stream. Om die gebruiker te bewerkstelligen hebben wij een AWS Lambda functie geschreven. De stream meldt zich bij deze functie wanneer er nieuwe data te verwerken is, waarna de Lambda functie aan het werk gaat. Bijkomend voordeel is hiermee dat er monitoring is in te richten op de Lambda functie zelf, maar ook in de AWS Kinesis stream op het al dan niet verwerken van data door de gebruiker. Door alarmen in te stellen in AWS CloudWatch zijn we direct een stuk meer op de hoogte van eventuele haperingen in de verwerking en kunnen we daar meteen op handelen.

Het resultaat van deze monitoring inrichting is dat wij in staat zijn vroeg te signaleren wanneer ergens data verloren dreigt te gaan. Waar voorheen ontwikkelteams achteraf lieten weten dat er ergens in het proces een foutmelding verloren was gegaan, zitten we daar nu bovenop."

.

De AWS Lambda functie heeft in de praktijk twee taken. Allereerst neemt het een deel van het werk dat de service voorheen deed over. Het filtert de berichten op foutmeldingen en negeert de overige berichten. Daardoor hoeft niet meer alle data van de Kinesis stream naar de EC2 instantie gestuurd te worden, maar gaan alleen nog de daadwerkelijk relevante berichten er heen.

We zijn meteen ook in staat om een ander probleem op te lossen: niet op tijd aangemaakte event sources. Deze Lambda functie filtert direct de berichten op eventueel aanwezige applicatie logs, en haalt daar de applicatiegegevens uit. Deze worden doorgegeven aan de EC2 instantie waar de SCOM agent op draait, zodat daar alvast een event source voor de applicatie kan worden aangemaakt als die nog niet bestaat. Omdat zelden de eerste logs van een applicatie al direct foutmeldingen zijn, voorkomen we op die manier de meeste van de problemen met niet op tijd gescande event sources. De event source staat immers alvast klaar voor het geval er ooit foutmeldingen binnen komen. Hierbij is uiteraard goed gekeken naar de impact van het hebben van event sources voor applicaties die wellicht nooit foutmeldingen gaan genereren. Deze bleek zo verwaarloosbaar klein te zijn dat de voordelen wat ons betreft overduidelijk opwegen tegen de nadelen.

Omdat we met deze oplossing zijn overgestapt naar een mechanisme waarbij de data binnen komt in plaats van opgehaald gaat worden, moest de Windows service die verantwoordelijk was voor het verwerken aangepast worden naar een webservice. In deze webservice bieden we twee endpoints aan: één voor nieuw aan te melden event sources en één voor daadwerkelijke foutmeldingen. Hierdoor is het ook aan de kant van de EC2 instantie makkelijker geworden om taken te scheiden. Als een bericht op het ene endpoint aankomt hoeft het namelijk alleen maar een event source aan te maken. En wanneer een bericht op het andere endpoint aankomt hoeft het enkel de foutmelding weg te schrijven naar de Windows event log.

Ronde 4: monitoring op de monitoring

Nu het ontwerp is aangepast, kan meteen signalering worden ingericht voor gevallen waarin er toch iets niet goed werkt. Zo is een alarm ingesteld op de AWS Kinesis stream, waarbij we gewaarschuwd worden zodra de verwerking van data op de stream begint achter te lopen. Op deze manier kwamen we tot de ontdekking dat de Kinesis stream niet optimaal was ingericht en hebben we meteen wat optimalisatie kunnen toepassen.

De AWS Lambda functie is ook van meerdere alarmen voorzien. Daardoor is het team direct op de hoogte als berichten om welke reden dan ook niet kunnen worden afgeleverd op de EC2 instantie die de SCOM monitoring verzorgt.

Als laatste is ook de instantie zelf van extra monitoring voorzien, zodat we snel op de hoogte zijn als de instantie niet gezond is of de webservice zelf foutmeldingen veroorzaakt.

Het resultaat van deze monitoring inrichting is dat wij in staat zijn vroeg te signaleren wanneer ergens data verloren dreigt te gaan. Waar voorheen ontwikkelteams achteraf lieten weten dat er ergens in het proces een foutmelding verloren was gegaan, zitten we daar nu bovenop. Als er al ergens iets in de soep loopt, zijn wij er vaak nog snel genoeg bij om zonder dataverlies de dienst weer te herstellen.

Terug naar het nieuwsoverzicht
Bekijk onze vacatures
Wil je hier meer over weten?

Neem contact op met Raymon. Hij vertelt je er graag meer over.

Raymon Marsman

Ontwikkelaar in het CloudOps-Enablement Team
rmarsman@conclusion.nl
Business Done Differently Powered by Conclusion
© Conclusion 2021   |  De kleine lettertjes  |  Privacy & Security
  • Expertises
© Conclusion 2021   |  De kleine lettertjes  |  Privacy & Security