Loggen en monitoren lijken op elkaar, maar doen iets anders. Loggen is vastleggen wat er gebeurt, zodat je het achteraf kunt uitzoeken. Monitoren is continu kijken of er iets afwijkt, zodat je het merkt voordat een klant het meldt. Het een werkt niet goed zonder het ander.
Kernpunt: een alarm helpt alleen als iemand het ziet, en een log helpt alleen als er het juiste in staat.
Een applicatie moet te monitoren zijn. Monitoring begint bij de applicatie zelf. We bouwen applicaties zo dat ze kunnen aangeven of ze gezond zijn (health checks), en dat een fout onderin ook bovenin zichtbaar wordt. Anders geeft een pagina die netjes laadt terwijl de backend eronder stuk is, een groen lampje bij een kapot systeem. Meldingen komen op een gedeelde plek binnen en niet bij één persoon, zodat niet afhangt van wie er toevallig is of ze worden gezien.
In de praktijk gebruiken we:
- Grafana om logs op één centrale plek samen te brengen en er dashboards van te maken;
- de monitoring van DigitalOcean voor uptime, health checks en controles op de geldigheid van SSL-certificaten, met waarschuwingen voordat een certificaat verloopt;
- CI/CD met GitHub Actions, zodat ook bouwen, testen en uitrollen zichtbaar en terug te zien zijn.
Een logregel schrijven. De waarde van onze monitoring hangt af van de kwaliteit van de logs van de applicatie zelf. Voor ontwikkelaars hebben we daarom een korte checklist:
- Elke regel begint met het niveau: error, warning, info of debug.
- Info en debug gaan naar de gewone uitvoerstroom, fouten en waarschuwingen naar de foutstroom, zodat je ze apart kunt filteren.
- Bij een fout staat wat er misging en waarom. "Er ging iets mis" helpt niemand om drie uur 's nachts.
- Aanroepen naar externe diensten, zoals het versturen van e-mail, worden gelogd.
- Debug-logging staat in productie uit.
Wat er niet in hoort. Een log kan zelf een risico zijn. Daarom gaan geheimen, persoonsgegevens en bedrijfsgegevens er niet in. Voorzichtig zijn we met:
- e-mailadressen;
- IP-adressen;
- volledige request-bodies;
- volledige databasequery's, want de parameters daarvan bevatten vaak persoonsgegevens.
Dat is een bewuste keuze: we leggen genoeg vast om te kunnen reconstrueren wat er gebeurd is, en niet meer dan dat. Logs worden bovendien beschermd tegen onbevoegde toegang, wijziging en verwijdering en blijven bewaard als een container of server herstart. Uitzetten van logging mag alleen met toestemming.
Een vast moment om te kijken. Ernaar kijken is een vaste gewoonte en niet iets wat we doen als we een vermoeden hebben: we zoeken naar dingen die opvallen, zoals dezelfde fout die opvallend vaak terugkomt of gedrag dat niet past bij normaal gebruik. Een daarvoor aangewezen persoon kijkt ook naar tekenen van misbruik en houdt de regels voor waarschuwingen actueel. Dat doen we in een vast ritme, ook als er niets is gemeld. Naast de logs en uptime-controles controleren we periodiek de systemen zelf: werken de beveiligingsmaatregelen nog, is het onderhoud uitgevoerd en is de toegang zoals bedoeld? Zo vangen we ook dingen op die niet vanzelf in een log verschijnen.
Een waarschuwing is pas klaar als iemand hem heeft opgepakt; de meldingen horen bij ons incidentproces. En wat we daarbij leren, nemen we mee in onze aanpak voor continu verbeteren: een melding die te laat kwam of een logregel waar iets in ontbrak, wordt een verbetering met een eigenaar.