Doel
Bij een verstoring wil ik in de terminal zeggen: "kijk even mee". Mijn eigen model zoekt dan uit wat er aan de hand is, met metrics en logs, zonder dat logdata naar een externe AI gaat.
Ontwerp
Een MCP-server met een handvol vaste tools, alleen bereikbaar via het thuisnetwerk:
| Tool | Wat het doet |
|---|---|
prom_query | Vaste vragen aan Prometheus: hoststatus, herstarts, voorspelling van volle schijven, actieve alerts |
k8s_status | Alleen-lezen clusterstatus: pods die niet ready zijn, recente events |
log_templates | Logregels gegroepeerd tot sjablonen (Drain3), met de variabelen gemaskeerd |
log_counts | Aantallen per sjabloon per tijdsvak |
/storing | Een vast stappenplan dat het model doorloopt |
Waarom sjablonen en een recept
- Kleine modellen doen het beter met een recept. Een vast stappenplan (eerst alerts, dan wat er veranderde, dan logs rond dat moment) geeft betere resultaten dan "zoek het uit".
- Sjablonen houden de context klein. Duizenden regels worden een paar tientallen patronen met aantallen. Een lokaal model kan geen 20 MB logs verwerken, maar wel een tabel.
- Sjablonen zijn veiliger. Moet er toch geëscaleerd worden naar Claude, dan gaan alleen sjablonen en tellingen mee. De escalatietool weigert ruwe logregels.
Gefaseerd
- Metrics en Kubernetes-status: dat kan nu al.
- VM-logs in Loki via Alloy. Dan werken de logtools vanzelf, en komt er een dekkingscheck: welke hosts zijn wel in Prometheus maar niet in Loki?
- Koppeling met de tijdlijn bij storingen, zodat het model begint bij wat er veranderde.
Runbooks die een model kan lezen
In mijn homelab heeft elke alert al een runbook in een vast formaat: PromQL-blokken met labelvariabelen ($instance, $mountpoint) en oorzaken met "Herken je aan …" om af te strepen. Een validatiestap in CI faalt bij een alert zonder runbook. Dat formaat is bewust machineleesbaar, als voorbereiding op dit concept.