Bij DIJ zorgen we er op verschillende manieren voor dat we altijd op de hoogte blijven van de status van onze applicaties. We verzamelen en monitoren data via diverse kanalen en op verschillende niveaus, zodat we altijd zo snel en gedetailleerd mogelijk weten of, waar en waarom er problemen optreden.
Alerting
Op het moment dat er iets misgaat nemen klanten contact met ons op. Maar het is natuurlijk veel beter dat we zelf al weten dat er iets niet goed gaat, zodat we ervoor kunnen zorgen dat eindgebruikers geen last hebben van een eventuele bug. Doordat wij notificaties krijgen van de eventuele problemen kunnen we deze oplossen voordat gebruikers hier last van hebben.
Door het integreren van Bugsnag in onze applicaties krijgen we live berichten over errors en waarschuwingen die voorkomen. Deze meldingen komen uiteraard in het dashboard van Bugsnag zelf terecht, maar we krijgen hier ook een melding van via onze Slack kanalen en Monitoring dashboards, later meer hierover.
Doordat deze meldingen direct naar ons gepusht worden, kunnen we snel reageren op eventuele fouten en zo zorgen we ervoor dat gebruikers zo min mogelijk ongemak ondervinden van een bug of fout.
Een andere tool die ons actieve alerting biedt over de status van onze applicaties is Pingdom. Deze tool bekijkt elke minuut of de webservers waarop wij onze applicaties hosten nog bereikbaar zijn. Op het moment dat er iets mis lijkt te zijn, krijgen wij meldingen binnen via Slack of de mobiele app van Pingdom.
Monitoring
Naast de actieve meldingen die we ontvangen wanneer er zich fouten voordoen, hebben we ook een aantal passieve monitoring tools.
Het grote voordeel van deze extra laag aan logging en monitoring is dat we snel meer info kunnen krijgen over het gedrag en de performance van specifieke functionaliteiten zoals bijvoorbeeld het aanroepen van API endpoints, synchronisatie processen tussen applicaties en het verwerken van data. Ook hebben deze tools een grote meerwaarde bij het verhelpen van problemen. Door op een veel dieper niveau te kunnen inzoomen hebben we snel meer duidelijkheid over waar het probleem zich voordoet.
Een paar voorbeelden van de pakketten die we hiervoor gebruiken zijn:
• Kibana, voor het bekijken van de verdeling van het gebruik van een applicatie
• Grafana, voor het bekijken van de load op onze servers
• StatsD, voor het bekijken van de performance van pagina's en API endpoints
Voor meer info over Kibana en Grafana kun je de post van Arjan bekijken.
En wil je nou meer weten over StatsD dan helpt Bart je hier met de eerste stappen in dit blog.
Monitoring en alerting in het echte leven
In de screenshot hieronder zie je de grafiek die voortkomt uit het loggen van de queue lengte van een proces dat data naar een externe partij pushed. Er was op dat moment geen verbinding met de externe API waardoor de queue vol bleef lopen met data die nog gepushed moest worden.
De drie verticale lijnen op de grafiek geven aan wanneer de queue langer werd dan gewenst (oranje), het moment dat er een alert verstuurd is, omdat de queue gedurende 5 minuten boven die treshold zat (rood), en het moment dat er een alert verstuurd is omdat het probleem weer verholpen is (groen).
Deze drie momenten zijn zo ingesteld om ervoor te zorgen dat we zo snel mogelijk op de hoogte zijn wanneer er zich mogelijke problemen voordoen en zodat er geen onnodige meldingen binnenkomen bij normale pieken in het gebruik van de applicatie.
Deze principes gebruiken wij ook om de alerting in te stellen op bijvoorbeeld de gemiddelde request looptijd of het percentage van bepaalde http-errors, maar ook voor de load op de server of database queries die langzamer zijn dan de norm.
Dit allemaal om ervoor te zorgen dat de applicaties van onze klanten allemaal exact doen wat ervan verwacht wordt. En dat mogelijke problemen sneller en beter opgelost kunnen worden.
Dashboards
Om al deze verschillende bronnen samen te voegen voor een goed overzicht is elk team voorzien van een beeldscherm met daarop een Dashboard gebouwd met Geckoboard. Hierop komt alle data van Bugsnag, onze End to End tests, de support vragen en server statussen samen.
Per team hebben we dus in één oogopslag een overzicht van de status van onze applicaties en kunnen we bij problemen direct actie ondernemen. Zo zorgen we ervoor dat onze applicaties goed blijven draaien.
Iedere ochtend bespreken we bij de dagaftrap de openstaande issues en bepaalt ieder team welke issue door welk teamlid opgepakt wordt, zodat ze zo snel mogelijk opgelost zijn. We streven elke naar om de dag te eindigen zonder openstaande issues, zodat de "alert functie" behouden wordt en we altijd snel zien wanneer zich nieuwe issues voordoen.
Resource
https://docs.bugsnag.com/
https://www.geckoboard.com/
