Kubernetes monitoring: van node-metrics naar checkout-latency

Bij Laravel zit het meeste risico in achtergrondwerk. Orders worden via jobs naar het ERP gestuurd, mails gaan via de queue, imports draaien 's nachts. Horizon geeft je een dashboard, maar dat dashboard belt niemand op. Daarom exporteren we de queue-lengte en wachttijd naar Prometheus, per queue. Op Redis of Valkey gaat dat via de lengte van de lijsten die Laravel gebruikt. Dezelfde metric voedt ook de autoscaling met KEDA.

De scheduler draait als CronJob met php artisan schedule:run, of als Deployment met schedule:work. In beide gevallen wil je weten of taken echt draaien. Kubernetes meldt alleen of de container slaagde, niet of jouw taak iets deed. We laten belangrijke taken een heartbeat sturen, of we meten de leeftijd van de laatste succesvolle run. Een alert op 'nachtelijke import is meer dan 26 uur oud' is concreter dan een alert op een mislukte pod.

Draai je Laravel Octane met FrankenPHP, Swoole of RoadRunner, dan veranderen de metrics. Er is geen PHP-FPM-pool meer, wel workers die lang leven. Daar letten we op geheugengroei per worker en op het aantal requests per worker voordat die herstart. Een geheugenlek dat bij PHP-FPM onzichtbaar bleef, wordt bij Octane een OOMKill.

Loki slaat logs op zonder de volledige tekst te indexeren. Het indexeert alleen labels zoals namespace, app en container, en zet de logregels zelf gecomprimeerd op object storage. Dat maakt het goedkoper in beheer dan een eigen Elasticsearch- of OpenSearch-cluster voor logs. Zoeken in de tekst gebeurt bij het opvragen, met LogQL.

De collector is Grafana Alloy, als DaemonSet op elke node. Promtail is door Grafana op 2 maart 2026 end-of-life verklaard. Bestaande Promtail-configuraties zetten we om met de conversietool van Alloy. Alloy kan tegelijk OTLP-traces ontvangen, zodat je één agent per node hebt in plaats van drie.

Het belangrijkste werk zit in de applicatie. Magento en Laravel schrijven standaard naar bestanden in var/log of storage/logs. In een container willen we logs op stdout, gestructureerd als JSON. Bij Laravel is dat een kanaal met de stderr-driver en een JSON-formatter. Bij Magento passen we de Monolog-handlers aan via di.xml. Daarna voegen we een trace-ID toe aan elke regel, zodat je vanuit een foutmelding in Loki direct naar de trace springt.

Labels houden we bewust klein. Order-ID's, klant-ID's en URL's horen in de logregel, niet in een label. Elk uniek label maakt een nieuwe stream, en duizenden streams maken Loki traag. Meer over wat je uit security-oogpunt moet loggen staat in ons artikel over security logging.

Prometheus meet wat je servers doen. Het meet niet wat je bezoeker ervaart. Tussen een responstijd van 200 milliseconden in het cluster en een pagina die op een middenklasse-telefoon interactief wordt, zitten CDN, netwerk, JavaScript en afbeeldingen. Daarvoor heb je real user monitoring nodig.

Als RUMvision Gold Partner koppelen we die twee. RUMvision meet Core Web Vitals en laadtijden bij echte bezoekers, per paginatype en apparaat. Wij leggen een deploy-marker in zowel Grafana als RUMvision. Zakt de INP op de productpagina na een release, dan zie je in Grafana of de server veranderde of dat het aan de frontend ligt.

In de praktijk vangt RUM problemen die serverside onzichtbaar blijven: een tracking-script dat de main thread blokkeert, een afbeelding zonder afmetingen, een Varnish-miss die alleen mobiele bezoekers raakt. En andersom laten servermetrics zien waarom de TTFB in RUM ineens oploopt. Lees ook ons stuk over Core Web Vitals voor wat je in RUM terugziet.