Aanleiding
Bij een storing met foutmeldingen over de hele linie kostte het een uur om vast te stellen dat er vlak daarvoor een deploy was geweest. Een nieuwe versie probeerde een bestaande message-queue opnieuw aan te maken met een extra argument; de broker weigerde, de healthcheck van de berichtenbus werd Unhealthy en de load balancer haalde alle servers uit de pool.
De informatie bestond allemaal, maar verspreid: de deploy in de CI, de herstart in Kubernetes-events, de fout in de brokerlogs en de 502's in de load balancer. Niemand had ze naast elkaar.
Het voorstel
- Wijzigingen als gebeurtenis. Elke deploy, elke Flux-reconcile en elke configuratiewijziging schrijft een regel naar Loki met
source="change": wat, waar, door wie, welke versie. - Kubernetes-events centraal. Alloy verzamelt nu alleen podlogs. Events (herstarts, evictions, failed probes) gaan er ook bij, met dezelfde labels.
- VM-logs in dezelfde Loki. Zodat een databasefout en een herstart in het cluster in één query staan.
- Een tijdlijnscript.
tijdlijn --van 13:20 --tot 13:40 --dienst apizet alle gebeurtenissen uit die bronnen op volgorde, met wijzigingen bovenaan gemarkeerd.
Bewuste grenzen
- Geen automatisch herstel en geen paging. Het doel is sneller begrijpen, niet sneller ingrijpen.
- Privacy eerst. Applicatie- en webserverlogs gaan pas mee na een toets door security, met maskering in de pipeline.
- Klein beginnen. Eerst wijzigingen en events; dat zijn kleine volumes met de meeste waarde.
Status
Ter bespreking met het ontwikkelteam, security en de hostingpartij. Een deel van de bouwstenen staat al: Loki met negentig dagen retentie, Alloy op de monitoringhost en de migratie van applicatielogs naar Loki. Dit concept sluit aan op het idee om een lokaal taalmodel mee te laten kijken bij storingen, dat dezelfde tijdlijn als startpunt kan gebruiken.