jelmer/gpx-afsluitingen
Watch
1
0
Fork
You've already forked gpx-afsluitingen
 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Gebruiksmonitoring en of de setup het houdt bij groei #24

New issue
Closed
opened 2026-07-20 14:46:25 +02:00 by jelmer · 0 comments
jelmer commented 2026-07-20 14:46:25 +02:00
Owner
Copy link

Gemigreerd uit backlog/ naar issues op 2026-07-20 — oorspronkelijk TASK-19.
Labels in het oude bord: monitoring, onderzoek.

De site staat nu publiek op omleidingchecker.nl en de verwachting is dat het
gebruik hard kan lopen. Twee vragen die we nu niet kunnen beantwoorden:
hoeveel wordt het gebruikt, en houdt de opzet het?

Gebruik in beeld brengen — Matomo meet bezoeken, maar niet wat het kost:

  • aantal checks per dag, en hoeveel daarvan uit cache komen
  • aantal LLM-oordelen en de kosten per dag (er is een daglimiet
    LLM_MAX_CALLS_PER_DAG=200, ±$0,16/dag; wat gebeurt er als die vol raakt?)
  • hoeveel verzoeken we bij Melvin doen (relevant: dat is andermans dienst,
    daarom is TASK-12 gedaan)
  • MapTiler-tegelverbruik tegen de limiet van het gratis plan

Houdt de opzet het — bekende zwakke plekken:

  • Uberspace draait onder een cgroup-limiet van 1,5 GB; de eerste versie werd
    al eens ge-SIGKILLed. Wat gebeurt er bij meerdere gelijktijdige checks?
    De situatie-cache is nu per datum plus een detail-cache per id — die groeit.
  • Het is één Python-proces met ThreadingHTTPServer. Waar ligt het plafond?
  • De single-flight-lock serialiseert zware fetches; bij drukte betekent dat
    wachten in plaats van omvallen, maar hoe lang?
  • Wat doet een piek met de OpenRouter-daglimiet: netjes degraderen of stil
    minder oordelen tonen?

Aanpak: eerst meten (kosten- en volumeteller in /api/health of een apart
endpoint, plus Kuma-monitoring daarop), dan een belastingproef om het plafond
te vinden voordat een bezoekerspiek dat voor ons doet.

Praktisch punt vooraf: er is nu geen enkel alarm op kosten. Een onverwachte
piek in LLM-gebruik merk je pas op de rekening.

Definition of Done

Hoe het is opgelost

Afgerond (2026-07-20).

/api/status toont per dag: checks, LLM-calls, cache-treffers, ophalingen per
bron, resterende OpenRouter-credits en de maandlimiet van de eigen key. Geeft
503 als het saldo onder $5 zakt of de daglimiet vol is. Kuma-monitor
"Omleidingchecker — AI-budget" (id 92) polt elk uur en alarmeert via ntfy.

Bewust los van /api/health: health gaat over "doet de site het" en voedt de
deploybewaking. Een leeg saldo is iets anders — de site blijft werken, alleen
zonder inschattingen. Samenvoegen zou alarmen op de verkeerde vraag geven.

Saldo wordt met de EIGEN app-key opgevraagd. /credits en /key werken met een
gewone key, dus de management-key uit de vault hoeft niet op een server te
staan. Die key wel eenmalig gebruikt voor de nulmeting en daarna verwijderd.

Nulmeting, en meteen de belangrijkste uitkomst.

  • Account: $170 gekocht, $166,65 op, nog $3,35. Bij het accountbrede tempo
    (circa $0,76-1,30 per dag, met een piek van $7,94 op 17 juli) is dat enkele
    dagen.
  • De app zelf is de kostenpost NIET: 18 juli $0,062 voor 119 requests, 19 juli
    $0,003. Het account loopt leeg door andere keys (Hermes $106, test $34).
  • De app-key heeft een eigen maandplafond van $5 (nog $4,94); dat begrenst de
    schade als het hier onverwacht druk wordt.

De belangrijkste bevinding is dus niet "de app wordt te duur" maar "de app hangt
aan een gedeeld account dat bijna leeg is". Vandaar monitoring op het saldo en
niet op ons eigen verbruik. De monitor stond bij aanzetten meteen op down; dat
is terecht.

Niet gedaan, bewust: de belastingproef om het plafond van de opzet te meten.
Dat vraagt verkeer genereren op productie en is een aparte sessie waard. De
bekende zwakke plekken staan in de taakomschrijving; de tellers in /api/status
maken nu wel zichtbaar wanneer het druk wordt.

> Gemigreerd uit `backlog/` naar issues op 2026-07-20 — oorspronkelijk **TASK-19**. > Labels in het oude bord: `monitoring`, `onderzoek`. De site staat nu publiek op omleidingchecker.nl en de verwachting is dat het gebruik hard kan lopen. Twee vragen die we nu niet kunnen beantwoorden: hoeveel wordt het gebruikt, en houdt de opzet het? **Gebruik in beeld brengen** — Matomo meet bezoeken, maar niet wat het kost: - aantal checks per dag, en hoeveel daarvan uit cache komen - aantal LLM-oordelen en de kosten per dag (er is een daglimiet LLM_MAX_CALLS_PER_DAG=200, ±$0,16/dag; wat gebeurt er als die vol raakt?) - hoeveel verzoeken we bij Melvin doen (relevant: dat is andermans dienst, daarom is TASK-12 gedaan) - MapTiler-tegelverbruik tegen de limiet van het gratis plan **Houdt de opzet het** — bekende zwakke plekken: - Uberspace draait onder een cgroup-limiet van 1,5 GB; de eerste versie werd al eens ge-SIGKILLed. Wat gebeurt er bij meerdere gelijktijdige checks? De situatie-cache is nu per datum plus een detail-cache per id — die groeit. - Het is één Python-proces met ThreadingHTTPServer. Waar ligt het plafond? - De single-flight-lock serialiseert zware fetches; bij drukte betekent dat wachten in plaats van omvallen, maar hoe lang? - Wat doet een piek met de OpenRouter-daglimiet: netjes degraderen of stil minder oordelen tonen? Aanpak: eerst meten (kosten- en volumeteller in /api/health of een apart endpoint, plus Kuma-monitoring daarop), dan een belastingproef om het plafond te vinden voordat een bezoekerspiek dat voor ons doet. Praktisch punt vooraf: er is nu geen enkel alarm op kosten. Een onverwachte piek in LLM-gebruik merk je pas op de rekening. ## Definition of Done - [x] #1 Werkend op https://omleidingchecker.nl - [x] #2 Documentatie bijgewerkt ## Hoe het is opgelost Afgerond (2026-07-20). /api/status toont per dag: checks, LLM-calls, cache-treffers, ophalingen per bron, resterende OpenRouter-credits en de maandlimiet van de eigen key. Geeft 503 als het saldo onder $5 zakt of de daglimiet vol is. Kuma-monitor "Omleidingchecker — AI-budget" (id 92) polt elk uur en alarmeert via ntfy. Bewust los van /api/health: health gaat over "doet de site het" en voedt de deploybewaking. Een leeg saldo is iets anders — de site blijft werken, alleen zonder inschattingen. Samenvoegen zou alarmen op de verkeerde vraag geven. Saldo wordt met de EIGEN app-key opgevraagd. /credits en /key werken met een gewone key, dus de management-key uit de vault hoeft niet op een server te staan. Die key wel eenmalig gebruikt voor de nulmeting en daarna verwijderd. **Nulmeting, en meteen de belangrijkste uitkomst.** - Account: $170 gekocht, $166,65 op, nog $3,35. Bij het accountbrede tempo (circa $0,76-1,30 per dag, met een piek van $7,94 op 17 juli) is dat enkele dagen. - De app zelf is de kostenpost NIET: 18 juli $0,062 voor 119 requests, 19 juli $0,003. Het account loopt leeg door andere keys (Hermes $106, test $34). - De app-key heeft een eigen maandplafond van $5 (nog $4,94); dat begrenst de schade als het hier onverwacht druk wordt. De belangrijkste bevinding is dus niet "de app wordt te duur" maar "de app hangt aan een gedeeld account dat bijna leeg is". Vandaar monitoring op het saldo en niet op ons eigen verbruik. De monitor stond bij aanzetten meteen op down; dat is terecht. **Niet gedaan, bewust:** de belastingproef om het plafond van de opzet te meten. Dat vraagt verkeer genereren op productie en is een aparte sessie waard. De bekende zwakke plekken staan in de taakomschrijving; de tellers in /api/status maken nu wel zichtbaar wanneer het druk wordt.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jelmer/gpx-afsluitingen#24
No description provided.