La lliçó anterior va acabar amb un problema que no admet ajornament: totes les mètriques de CicloUrbana viuen en memòria i moren amb el procés. Cada desplegament automàtic de 08-05 les esborra; /actuator/metrics retorna l'acumulat d'ara mateix i no té història; no hi ha cap gràfic, no hi ha comparació amb la setmana passada i, sobretot, no hi ha ni una sola alerta. Els SLO que vam definir amb RED i USE estan escrits i ningú no els vigila.

Aquesta lliçó tanca aquest buit amb les dues eines que s'han convertit en l'estàndard de facto: Prometheus, que recull i emmagatzema sèries temporals, i Grafana, que les representa. Veurem per què Prometheus va a buscar les dades en lloc d'esperar-les, com exposar les mètriques de Micrometer en el seu format, com llegir aquest format de text —incloses les cubetes d'histograma que vam configurar a 09-03—, PromQL de debò fins a poder calcular el p95 real de la xarxa de Ribalta agregant les tres instàncies, el quadre de comandament de CicloUrbana panell a panell i, el que de debò canvia la vida de l'equip, les regles d'alerta que converteixen un número en una trucada de telèfon quan —i només quan— cal.

1. Per què cal un sistema extern
2. El model pull davant del push
3. L'arquitectura de monitoratge de CicloUrbana
4. Exposar /actuator/prometheus
5. Llegir el format de text
6. El model de dades de Prometheus
7. prometheus.yml per a CicloUrbana
8. Descobriment d'objectius a Kubernetes
9. Retenció i emmagatzematge
10. PromQL: el que cal saber
11. Les consultes de CicloUrbana, una a una
12. Aixecar la pila amb docker-compose
13. Grafana: origen de dades i quadres de comandament importats
14. El quadre de comandament de CicloUrbana, panell a panell
15. Regles d'alerta
16. Alertmanager: rutes, agrupació i silencis
17. Bones pràctiques d'alertes
18. Alternatives gestionades
19. Errors Comuns i Consells
20. Exercicis

El MeterRegistry de 09-03 és un conjunt de comptadors en memòria. Això implica quatre mancances que cap configuració d'Actuator no pot resoldre:

Un sistema de monitoratge extern resol les quatre: recull periòdicament, emmagatzema amb retenció, agrega entre instàncies i avalua regles per alertar. L'aplicació només ha d'exposar els seus números en un format que aquest sistema entengui, i amb Micrometer això costa una dependència.

Prometheus va a buscar les dades: cada 15 segons fa una petició HTTP a cada instància i desa el que li retorna. És la decisió de disseny que més el distingeix de sistemes com Datadog o StatsD, on és l'aplicació la que empeny les seves mètriques cap a un col·lector.

L'avantatge decisiu a la pràctica és el tercer: amb pull, Prometheus genera automàticament una mètrica up per objectiu, de manera que «l'aplicació està caiguda» és una consulta, no una inferència. I per al cas que el model no cobreix —tasques efímeres com la importació nocturna de 07-03, que pot acabar entre dues recollides— existeix el Pushgateway, un intermediari on el procés diposita les seves mètriques i del qual Prometheus estira després. És l'excepció, i convé tractar-la com a tal: fer-lo servir per a serveis normals anul·la la detecció de caigudes.

Cinc peces i una responsabilitat cadascuna. L'aplicació només exposa un endpoint de text. Prometheus recull, emmagatzema i avalua les regles: fixa't que les alertes es disparen a Prometheus, no a Grafana. Alertmanager rep les alertes disparades i decideix a qui avisar, agrupant, silenciant i evitant repeticions. Grafana només consulta i dibuixa: no emmagatzema res. I els exporters —com postgres_exporter— publiquen en el mateix format les mètriques de sistemes que no parlen Prometheus, cosa que interessa perquè a 09-01 va quedar clar que bona part dels problemes de CicloUrbana són a la base de dades.

Només amb aquesta dependència, Micrometer registra un PrometheusMeterRegistry i Actuator afegeix l'endpoint. Falta exposar-lo:

Seguretat: la cadena EndpointRequest.toAnyEndpoint() de 07-01 ja cobreix aquest endpoint i exigeix ADMIN, així que Prometheus necessitarà credencials (apartat 7). És el correcte: /actuator/prometheus revela noms d'endpoints, versions i el volum de negoci de Ribalta. I continua vivint al port 8081, que no surt de la xarxa interna.

Com es llegeix, element per element. # HELP és la descripció, que ve literalment del .description(...) que vam escriure a MetriquesCicloUrbana. # TYPE declara el tipus —counter, gauge, histogram, summary—, i a partir d'ell Grafana i PromQL saben quines operacions tenen sentit. Cada línia següent és una sèrie temporal: nom, claus amb les etiquetes i valor actual; la combinació nom + etiquetes és la seva identitat, i aquí es veu per què la cardinalitat de 09-03 importa tant —cada línia és una sèrie que Prometheus indexarà i desarà per sempre—.

Els sufixos mereixen atenció especial, perquè són la traducció del que vam configurar a 09-03. Un comptador es converteix en _total per convenció de Prometheus. Un histograma produeix tres famílies: _count (quantes observacions), _sum (la suma de totes, en segons) i _bucket amb l'etiqueta le (less or equal), una sèrie per llindar. Fixa't que les cubetes són acumulatives: le="0.3" val 11.903 i inclou les 8.241 de le="0.1". L'última, le="+Inf", coincideix sempre amb _count. I aquests llindars 0,1 / 0,3 / 0,8 surten exactament del slo: que vam configurar a 09-03.

Amb _count i _sum s'obté la mitjana (_sum / _count = 1284,31 / 12801 = 100 ms), i amb les cubetes s'obté el percentil real: això és l'apartat 10.

Una mostra és un valor float64 amb una marca de temps, i pertany a una sèrie temporal identificada per un nom de mètrica i un conjunt d'etiquetes. Res més: no hi ha taules, ni esquemes, ni tipus complexos.

Els quatre tipus: counter (monòton creixent; es consulta amb rate, mai pel seu valor absolut), gauge (puja i baixa; el seu valor sí que significa alguna cosa), histogram (cubetes acumulatives, agregable) i summary (percentils precalculats; el que produeix percentiles de 09-03, no agregable).

Prometheus afegeix a més unes etiquetes pròpies a cada mostra: job (el nom del grup d'objectius), instance (host:port) i les que es defineixin a la configuració. Per això, encara que les tres rèpliques publiquin el mateix comptador, les seves sèries són distingibles.

Les decisions que importen. metrics_path és obligatori perquè Prometheus busca /metrics per defecte i Actuator publica a /actuator/prometheus: és l'error de configuració número u. L'interval de 15 segons és un compromís —més freqüent dóna més resolució i més emmagatzematge; per sota de 10 s rarament compensa, i per sobre de 60 s es perden els pics curts—. scrape_timeout menor que scrape_interval, o les recollides se solapen. L'autenticació és la contrapartida d'haver assegurat Actuator, amb la contrasenya en un fitxer i no al YAML. I el port 8081, que és el de gestió: Prometheus mai no toca el port del trànsit dels ciutadans.

La llista estàtica deixa de servir tan bon punt l'HPA de 08-04 escala de tres a set rèpliques: els pods nous no apareixerien. La solució és el descobriment dinàmic:

I al Deployment de 08-04, la plantilla del pod s'anota:

El mecanisme és elegant: Prometheus pregunta a l'API de Kubernetes quins pods existeixen i el relabel_configs filtra i transforma aquesta llista. Cada pod nou que neixi amb aquestes anotacions comença a ser recollit al cicle següent, i cada pod que mori deixa de ser-ho, sense tocar la configuració. Aquest és el motiu real pel qual Prometheus encaixa tan bé amb Kubernetes.

Prometheus desa les dades a la seva pròpia base de sèries temporals, en disc local, amb blocs de dues hores comprimits. Els paràmetres d'arrencada:

Una estimació útil: cada mostra ocupa aproximadament 1-2 bytes un cop comprimida. Amb 15.000 sèries i una recollida cada 15 segons, surten uns 86 milions de mostres al dia, és a dir, de l'ordre de 100-170 MB diaris i uns 3-5 GB al mes. La conclusió operativa: el consum depèn del nombre de sèries, no del trànsit, cosa que retorna un altre cop a la cardinalitat de 09-03 —duplicar les etiquetes duplica el disc i la memòria, encara que el nombre de peticions no canviï—.

Trenta dies són suficients per operar. Per a informes anuals a l'ajuntament cal emmagatzematge de llarga durada —Thanos, Cortex o Mimir—, que se situen darrere de Prometheus i desen els blocs en emmagatzematge d'objectes. I un avís important: el volum de Prometheus ha de ser persistent (un PersistentVolumeClaim a Kubernetes); si viu al sistema de fitxers del contenidor, cada reinici esborra la història i tornem al problema de l'apartat 1.

Selectors i comparadors. La forma bàsica és el nom de la mètrica amb un filtre d'etiquetes entre claus:

Els quatre comparadors són =, !=, =~ i !~; els dos últims són expressions regulars ancorades a la cadena completa, així que status=~"5.." capta exactament els 5xx.

rate(): la funció més important. Un comptador només creix, així que el seu valor absolut no diu res útil —«hem servit 18.422 lloguers des que va arrencar el procés» no es pot comparar amb una altra instància ni amb ahir—. El que interessa és a quin ritme creix:

rate calcula l'increment per segon dins de la finestra i, crucialment, gestiona els reinicis: si el comptador es posa a zero perquè l'aplicació s'ha reiniciat, rate ho detecta i no produeix un valor negatiu absurd. És exactament el que fa usable el model de comptadors monòtons.

irate() fa servir només els dos últims punts: reacciona molt de pressa i és molt sorollós. La regla pràctica: rate per a gràfics i alertes, irate només per depurar un pic en directe. I una condició que s'oblida: la finestra ha de contenir almenys quatre mostres, així que amb recollida cada 15 s, mai menys de [1m].

Agregació. Els operadors (sum, avg, max, min, count, topk) col·lapsen sèries:

sum by (...) conserva només les etiquetes anomenades; sum without (...) conserva totes menys aquestes. La segona és sovint més pràctica: without (instance) agrega les rèpliques mantenint la resta del context.

histogram_quantile(): el p95 real. Aquí es cobra la decisió de 09-03 de fer servir histogrames:

Es llegeix de dins cap enfora: rate sobre les cubetes dóna el ritme d'observacions per cubeta; sum by (le, uri) suma les tres instàncies conservant el llindar i l'endpoint; histogram_quantile interpola el percentil. El le dins del by és obligatori: sense ell es destrueix l'estructura de l'histograma i el resultat no significa res. I aquest és el p95 agregat que era impossible amb percentils calculats a la JVM.

Altres funcions útils. increase(x[1h]) dóna l'increment total a la finestra —increase és rate × segons, i serveix per a «quants lloguers en l'última hora»—. avg_over_time(x[10m]) fa la mitjana d'un gauge en el temps. changes(x[1h]) compta canvis de valor, útil per detectar reinicis. I absent(x) val 1 quan la sèrie no existeix, que és la manera d'alertar que alguna cosa ha deixat de publicar-se.

Operacions entre sèries. Es poden dividir dues consultes si les seves etiquetes casen, que és com es calcula una proporció:

Amb sum(...) a banda i banda el resultat és un escalar i no hi ha problema d'aparellament; sense agregar, cal fer servir on(...) o ignoring(...) per indicar per quines etiquetes casen les sèries.

Cinc d'elles mereixen comentari perquè amaguen una idea:

La taxa d'error s'expressa com a proporció, no com a número absolut: 20 errors per minut és una catàstrofe amb 100 peticions i soroll amb 100.000. Un detall pràctic: al numerador convé sumar outcome="SERVER_ERROR" i no status=~"5..", perquè outcome ja distingeix els errors nostres dels 4xx del client —un 409 per intentar un segon lloguer és la regla de negoci funcionant, no una fallada—.

El p95 per endpoint és la consulta que justifica tot el mòdul: agrega les tres instàncies, conserva el desglossament per endpoint i dóna el número que es va prometre com a SLO a 09-03.

Els lloguers per minut i tarifa són el pols del negoci, i el * 60 és només per llegir-los en unitats humanes: rate sempre retorna per segon.

L'ús del pool és una utilització (USE), i n'hi ha prou de comparar amb 0,8. hikaricp_connections_pending és la saturació, i el seu llindar és zero.

La taxa d'encerts de memòria cau tanca 09-02: la regla del by (cache) al numerador i al denominador fa que la divisió casi sèrie amb sèrie i doni un valor per memòria cau.

Al costat del docker-compose.yml de 07-04, un fitxer d'observabilitat:

S'arrenca al costat del principal amb docker compose -f docker-compose.yml -f docker-compose.observabilitat.yml up -d. Quatre detalls: els volums amb nom conserven la història i els quadres de comandament entre reinicis; --web.enable-lifecycle permet recarregar regles sense reiniciar; la contrasenya de Grafana és obligatòria —deixar admin/admin exposat és un clàssic—; i el postgres_exporter porta les mètriques de la base de dades que a 09-01 calia consultar a mà amb pg_stat_statements.

Grafana es configura per interfície, però la configuració que sobreviu és la aprovisionada per fitxer, versionada al repositori:

Importar abans que construir. Abans de dibuixar un sol panell, convé importar dos quadres de comandament de la comunitat, indicant-ne l'identificador a Dashboards → Import:

La comparació honesta: importar dóna el 80 % del valor en cinc minuts, cobreix tot el genèric —JVM, GC, pool, HTTP— i està molt més ben construït del que un faria a mà. El que no et pot donar és l'específic de Ribalta: lloguers per tarifa, bicicletes per estació, encerts de memòria cau. L'estratègia sensata és importar el genèric i construir un únic quadre de comandament propi amb el de negoci, en lloc de reinventar el gràfic de memòria de la JVM.

Un avís: els quadres importats suposen noms d'etiquetes concrets, gairebé sempre application i instance. Si les teves etiquetes comunes de 09-03 no inclouen application, els panells sortiran buits i semblarà que alguna cosa està trencada.

Un bon quadre de comandament respon en cinc segons a la pregunta «està bé el servei?» i permet aprofundir després. S'organitza en files, del que veu el ciutadà al que consumeix la màquina:

Fila 1 — Estat del servei (RED). Quatre panells: Taxa (sum(rate(http_server_requests_seconds_count[5m])), gràfic de línies), Errors (la proporció de l'apartat 11, en stat amb llindars de color: verd < 0,5 %, ambre < 1 %, vermell per sobre), Latència p50/p95/p99 (tres consultes superposades en un gràfic, amb el SLO de 800 ms dibuixat com a línia de llindar) i Disponibilitat (avg(up{job="ciclourbana"}), en stat).

Fila 2 — Per endpoint. Una taula amb topk(10, sum by (uri) (rate(...))) i un gràfic del p95 per uri. Aquesta fila respon «quin endpoint és el culpable?» immediatament després que la fila 1 digui que alguna cosa va malament.

Fila 3 — JVM i recursos (USE). Memòria de heap després de GC, rate(jvm_gc_pause_seconds_sum[5m]), fils vius, hikaricp_connections_active davant de max al mateix gràfic, i hikaricp_connections_pending com a stat amb llindar a 1. És la fila de les causes.

Fila 4 — Negoci. Lloguers per minut i tarifa (barres apilades), bicicletes disponibles per estació (mapa de calor o taula ordenada ascendentment, per veure primer les estacions buides), durada mitjana del trajecte i taxa d'encerts per memòria cau. És la fila que l'ajuntament entén sense traducció, i la que detecta un desplegament que va trencar el lloguer.

Variables de plantilla. En lloc de duplicar el quadre per entorn, es defineixen variables: entorn com a query label_values(up, entorn), i instancia com a label_values(up{entorn="$entorn"}, instance) amb l'opció All activada. Després, totes les consultes fan servir {entorn="$entorn", instance=~"$instancia"}. Un sol quadre serveix per a pre i prod, i permet aïllar una rèplica sospitosa amb un desplegable.

Bones pràctiques de visualització, que separen un quadre útil d'un de decoratiu: unitats sempre (segons, peticions/s, bytes, per cent) perquè un número sense unitat indueix a error; els percentils al mateix gràfic que la mediana, per veure la separació entre l'experiència típica i la dolenta; llindars dibuixats com a línia, de manera que el SLO sigui visible i no una dada de la documentació; escala logarítmica en latències, que solen abastar ordres de magnitud; res de gràfics de sectors per a sèries temporals; i com a màxim uns 12 panells, perquè un quadre de 40 no es mira mai.

Les regles s'avaluen a Prometheus, cada evaluation_interval, i viuen als fitxers de rule_files:

Els quatre camps d'una regla i el seu paper. expr és una consulta PromQL: l'alerta està activa mentre retorni alguna sèrie. for és l'element més subestimat: exigeix que la condició es mantingui durant aquest temps abans de disparar, i és el que elimina el 90 % del soroll —un pic de dos segons no desperta ningú—. labels classifica l'alerta i és el que Alertmanager farà servir per encaminar. I annotations és el missatge per a l'humà, amb plantilles Go ({{ $value }}, {{ $labels.instance }}) i, molt recomanable, un runbook_url: a les quatre de la matinada, un enllaç als passos de diagnòstic val més que qualsevol gràfic.

L'última regla mereix deteniment perquè és la més valuosa i la més difícil d'escriure: alerta que no està passant una cosa que hauria de passar. Requereix acotar l'horari —hour() retorna l'hora UTC, d'aquí el desfasament— perquè no dispari a les quatre de la matinada, quan zero lloguers és el normal a Ribalta.

Prometheus dispara; Alertmanager decideix què fer:

Tres mecanismes que eviten l'infern de notificacions. L'agrupació converteix tres alertes idèntiques de les tres rèpliques en un sol missatge. Les regles d'inhibició callen les alertes derivades: si l'aplicació està caiguda, no té sentit avisar a més que la seva latència és estranya. I els silencis, que es creen des de la interfície d'Alertmanager amb una durada i un motiu, serveixen per a una finestra de manteniment coneguda —una migració de Flyway pesada, per exemple—; convé que siguin sempre temporals, perquè un silenci permanent és una alerta esborrada sense dir-ho.

Alertar sobre símptomes, no sobre causes. «La latència p99 supera 1 s» és un símptoma que el ciutadà nota; «la CPU està al 85 %» és una causa que pot ser perfectament normal. Si s'alerta de causes, l'equip rep avisos de coses que no afecten ningú i deixa de mirar-los, que és exactament com es perd una alerta important.

Cada alerta ha d'exigir una acció humana i immediata. La pregunta que decideix és: si això arriba a les quatre de la matinada, hi ha alguna cosa a fer ara? Si la resposta és «mirar-ho demà», no és una alerta: és un panell del quadre de comandament o, com a molt, un avís en horari laboral. La distinció severity: critica davant de severity: avis de l'apartat 15 és exactament això, amb destinacions diferents.

Combatre la fatiga d'alertes. Un equip que rep trenta notificacions al dia deixa de llegir-les en dues setmanes, i a partir d'aquí el sistema d'alertes no existeix encara que continuï funcionant. Les eines: for generós, agrupació, inhibició i esborrar sense pietat les alertes que mai no han portat a una acció.

Posar sempre un runbook_url. Qui rep l'alerta a les quatre de la matinada pot no ser qui va escriure el codi. Tres línies de «comprova això, mira allò, si és això fes allò altre» canvien completament el resultat.

Alertar també sobre l'absència. Els sistemes trencats de vegades deixen d'emetre en lloc d'emetre errors. absent() i la regla de «sense lloguers en hora punta» cobreixen aquest buit.

Provar les alertes. Prometheus porta promtool test rules, que permet escriure proves unitàries de les regles amb sèries simulades. Una alerta que mai no s'ha vist disparar-se és una hipòtesi, no una alerta.

El criteri. La pregunta no és quin és millor, sinó qui operarà això i amb quin pressupost. Prometheus autogestionat és gratuït en llicències i car en atenció; els gestionats inverteixen els termes. Per a CicloUrbana —tres instàncies, unes 15.000 sèries, un equip que ja opera Kubernetes— la pila pròpia és l'elecció correcta, amb una sortida natural cap a Grafana Cloud si el manteniment comença a pesar, perquè el llenguatge de consulta i els quadres de comandament es conserven. Aquest és, de fet, l'argument estratègic més fort a favor de l'ecosistema Prometheus: no tanca portes.

I una nota que anticipa el final del mòdul: OpenTelemetry s'està convertint en l'estàndard comú per emetre mètriques, logs i traces, amb un protocol (OTLP) que gairebé totes les destinacions accepten. Prometheus ja sap ingerir OTLP, Micrometer té pont cap a ell i els backends comercials el suporten. És la direcció cap a la qual convergeix tot, i és la que prendrem a 09-06 per a la traçabilitat distribuïda.

Oblidar metrics_path: /actuator/prometheus. Prometheus busca /metrics, l'objectiu apareix en vermell i tota la resta sembla trencada. És la fallada número u: comprova-ho a Status → Targets.

Fer servir el valor absolut d'un comptador. ciclourbana_lloguers_iniciats_total sense rate() dóna un número que només creix i que es posa a zero a cada desplegament. Sobre un comptador, sempre rate o increase.

Oblidar le al sum by d'histogram_quantile. El resultat és un número sense significat que a més sembla plausible. Sempre sum by (le, ...).

Finestra de rate massa curta. Amb recollida cada 15 s, rate(x[30s]) no té mostres suficients i produeix buits. Regla: la finestra, almenys quatre vegades l'interval de recollida.

Alertar sense for. Un pic de dos segons desperta algú. Gairebé tota alerta necessita un for d'entre 2 i 15 minuts.

Alertar sobre causes. CPU al 85 %, memòria al 70 %, GC freqüent: són diagnòstics, no problemes. Alerta sobre el que pateix l'usuari i fes servir aquestes altres mètriques per investigar.

No persistir el volum de Prometheus ni el de Grafana. Un reinici esborra la història i els quadres de comandament construïts a mà. Volums amb nom i, millor encara, quadres aprovisionats per fitxer al repositori.

Deixar Grafana amb admin/admin accessible. Els quadres de comandament revelen volums de negoci, endpoints i versions. Contrasenya obligatòria i registre deshabilitat.

Consell: aprovisiona per fitxer els orígens de dades, els quadres i les regles, i versiona'ls al repositori al costat del codi. Un quadre de comandament construït a mà a la interfície és infraestructura sense control de versions.

Consell: comença important el 4701 i el 12900 i construeix un únic quadre propi amb el de negoci de Ribalta. Reinventar el gràfic de memòria de la JVM no aporta res.

Consell: escriu l'alerta alhora que la mètrica. Una mètrica de negoci sense alerta es converteix en un panell que ningú no mira.

Escriu la consulta PromQL per a cada pregunta de l'ajuntament i explica cada funció que facis servir: (a) quants lloguers s'han iniciat avui a l'estació «Universitat»; (b) quin percentatge de les peticions a /api/v1/estacions es respon en menys de 300 ms —el SLO de 09-03—; (c) quina instància consumeix més memòria de heap; (d) la taxa d'encerts de la memòria cau estacions en l'última hora; (e) si alguna rèplica fa més de cinc minuts que té el tallacircuits de pagaments obert.

L'equip va definir aquesta regla i, durant una caiguda real de 20 minuts en què l'API va retornar 500 a tot, no va arribar cap notificació. Troba els tres motius possibles i explica com verificaries cadascun.

L'ajuntament demana una pantalla que es projecti a la sala d'operacions i que permeti a algú sense coneixements tècnics saber si la xarxa de Ribalta funciona. Dissenya aquest quadre de comandament: tria sis panells com a màxim, indica la consulta PromQL de cadascun, el tipus de visualització, les unitats i els llindars de color, i justifica què has deixat fora i per què.

Solució 1.

(a) Lloguers d'avui a «Universitat»:

increase dóna l'increment total del comptador a la finestra —a diferència de rate, que dóna el ritme per segon—, i sum col·lapsa les tres rèpliques i els tres tipus de tarifa en un únic número. Advertiment honest: [24h] és «les últimes 24 hores», no «des de mitjanit»; per a això cal ajustar el rang del panell o fer servir una regla de registre diària.

(b) Percentatge per sota de 300 ms:

Aquí es cobra la configuració slo: 300ms de 09-03: com que les cubetes són acumulatives, la de le="0.3" conté exactament les peticions que van complir l'objectiu, i dividir-la pel total dóna la proporció de compliment. És la manera correcta de mesurar un SLO, millor que histogram_quantile, perquè respon a la pregunta contractual: «quin percentatge va complir», no «quin és el percentil». Requisit imprescindible: que existeixi una cubeta exactament a 0.3.

(c) Instància amb més heap:

sum by (instance) agrega els diferents pools de memòria (Eden, Survivor, Old) de cada JVM, i topk(1, ...) retorna la més gran conservant l'etiqueta instance, que és la resposta buscada.

(d) Taxa d'encerts de la memòria cau:

El denominador inclou encerts i fallades perquè no filtra per result. Si el resultat és per sota de 0,2, cal revisar la clau o l'autoinvocació de 09-02; en un panell convé mostrar-ho com a percentatge amb llindars.

(e) Tallacircuits obert més de cinc minuts:

min_over_time sobre la finestra val 1 només si la sèrie ha valgut 1 durant tota la finestra, cosa que expressa exactament «fa cinc minuts que és obert» i no «es va obrir en algun moment». L'alternativa idiomàtica és expr: ... == 1 amb for: 5m en una regla d'alerta, que és com s'escriuria en producció.

Solució 2.

Motiu 1 — l'expressió fa servir un comptador sense rate. http_server_requests_seconds_count és acumulatiu des de l'arrencada, així que > 100 es compleix sempre en qualsevol aplicació amb trànsit... i per això, paradoxalment, no distingeix una caiguda d'un dia normal. A més, si la caiguda va provocar reinicis, el comptador es va posar a zero i va baixar de 100. El correcte és una proporció amb rate. Com verificar-ho: executar l'expressió a la interfície de Prometheus i veure que retorna un valor gran fins i tot en un moment sa.

Motiu 2 — for: 30m és més llarg que la incidència. La caiguda va durar 20 minuts, així que l'alerta va estar en estat pending tot aquest temps i es va resoldre abans de passar a firing: mai no va arribar a Alertmanager. Com verificar-ho: mirar l'estat històric a Alerts o consultar la mètrica ALERTS{alertstate="pending"}. Regla pràctica: el for ha de ser bastant menor que la durada de l'incident que es vol detectar; 5 minuts és un valor raonable.

Motiu 3 — severity: info probablement no s'encamina a cap receptor. Les rutes de l'apartat 16 encaminen critica a la guàrdia i equip=producte al seu canal; una etiqueta que no casa amb cap ruta específica cau al receptor per defecte, i si l'equip el té apuntat a un canal que ningú no llegeix, l'efecte pràctic és el mateix que no alertar. Com verificar-ho: fer servir amtool config routes test severity=info o l'eina d'encaminament de la interfície d'Alertmanager.

A més, l'anotació «Errors a l'API» no diu quants, ni on, ni què fer, i no hi ha runbook_url. Versió corregida:

Solució 3.

Principi de disseny: l'audiència no és tècnica, així que cada panell ha de respondre una pregunta en llenguatge de servei, amb color com a informació principal i el número com a detall. Sis panells:

Què es deixa fora i per què. Memòria de heap, pauses de GC, fils de Tomcat, ús del pool, taxa d'encerts de memòria cau i latència per endpoint: tot això són causes, no símptomes, i el seu públic és l'equip tècnic. Un operari de l'ajuntament no pot fer res amb «GC pause 180 ms», i la seva presència només aconsegueix que els panells que sí que importen es perdin entre soroll. Viuen al quadre de comandament tècnic de l'apartat 14 i al 4701 importat, a un clic de distància.

Dues decisions addicionals. La segona fila del quart panell dibuixa el SLO com a línia de llindar, perquè «va lent» sigui visible sense interpretar números. I el panell de lloguers per minut és deliberadament el més gran: és l'únic que detecta un servei funcionalment trencat amb tots els indicadors tècnics en verd, el cas que a 09-03 vam identificar com el que les mètriques tècniques no veuen mai. Convé a més fixar el rang temporal per defecte en 6 hores i activar el refresc automàtic cada 30 segons, coherent amb l'interval de recollida.

Les mètriques de CicloUrbana han sortit del procés. Entens per què calia un sistema extern —persistència, història, agregació entre instàncies i avaluació contínua— i per què Prometheus va a buscar les dades en lloc d'esperar-les, amb l'avantatge decisiu que «la instància està caiguda» es converteix en una consulta (up == 0) en lloc d'una inferència, i amb el Pushgateway com a excepció acotada per a processos efímers. Saps exposar les mètriques amb micrometer-registry-prometheus al port de gestió de 07-01, i llegir el format de text: # HELP, # TYPE, les sèries amb les seves etiquetes i els sufixos _count, _sum i _bucket amb l'etiqueta le acumulativa, que són la traducció literal dels histogrames que vas configurar a 09-03.

Tens un prometheus.yml complet per a Ribalta —amb el metrics_path que gairebé tothom oblida, l'autenticació que exigeix la cadena de seguretat d'Actuator i els intervals triats amb criteri— i saps substituir la llista estàtica per descobriment a Kubernetes amb anotacions i relabel_configs, de manera que cada rèplica que creï l'HPA de 08-04 comenci a mesurar-se sola. Coneixes el cost real de l'emmagatzematge i la seva dependència del nombre de sèries, no del trànsit, cosa que retorna una vegada més a la cardinalitat.

I saps PromQL de debò: selectors amb els seus quatre comparadors, rate sempre sobre un comptador i per què irate només serveix per depurar, sum by i sum without per agregar les tres instàncies, histogram_quantile amb el le obligatori per obtenir el p95 real que era impossible amb percentils calculats a la JVM, més increase, avg_over_time, absent i les operacions entre sèries que produeixen proporcions. Amb aquestes peces has escrit les consultes concretes de CicloUrbana: trànsit i latència per endpoint, taxa d'error com a proporció, lloguers per minut i tarifa, bicicletes per estació, pool d'HikariCP, pauses de GC i encerts de memòria cau.

Del costat operatiu, tens la pila aixecada amb docker-compose al costat de la de 07-04, amb volums persistents i el postgres_exporter; Grafana aprovisionat per fitxer, amb l'estratègia d'importar el genèric (4701, 12900) i construir només el de negoci; el quadre de comandament de Ribalta organitzat en quatre files del que veu el ciutadà al que consumeix la màquina, amb variables de plantilla per entorn i instància; i les regles d'alerta amb expr, for, labels i annotations, inclosa la més valuosa i la més difícil d'escriure —la que avisa que no està passant una cosa que hauria de passar—. Alertmanager agrupa, inhibeix i silencia, i tens les regles d'or de les alertes: símptomes i no causes, cada alerta amb una acció possible, runbook_url sempre, i esborrar sense pietat el que només produeix fatiga.

Amb això, dos dels tres pilars són drets. Les mètriques diuen que alguna cosa va malament i des de quan; els quadres de comandament ho mostren i les alertes ho avisen. Però quan l'alerta arriba a les quatre de la matinada dient que la taxa d'error de l'inici de lloguer és del 3 %, la pregunta següent —què ha fallat exactament, en quina petició, amb quin usuari, amb quin missatge— no la respon cap gràfic. La respon el pilar que fem servir des de la primera lliçó sense haver-lo tractat mai seriosament: el registre d'esdeveniments. La lliçó següent, Gestió de Registres i Logs, el converteix en una eina de debò: nivells amb criteri, logback-spring.xml per perfil, logs estructurats en JSON, el rastreId del FiltreRastreig de 03-06 propagat i consultable, el que mai no s'ha de registrar sobre els ciutadans de Ribalta, i l'agregació centralitzada que permet buscar als logs de les tres instàncies com si fossin un de sol.