A la lliçó anterior vam instal·lar metrics-server i per fi vam saber quant consumeix cada component de Rutas Norte ara mateix. També en vam descobrir el límit infranquejable: no recorda res. La pregunta "què va passar ahir a la nit a les tres de la matinada?" continua sense resposta, i amb ella totes les que de debò importen: quantes reserves per minut estem confirmant?, ha pujat la latència des de l'últim desplegament?, quant falta perquè s'ompli el disc de postgres-reserves?

Aquesta lliçó desplega Prometheus, l'estàndard de facto per monitorar Kubernetes i el segon projecte graduat de la CNCF després del mateix Kubernetes. Anem a entendre el seu model de dades, d'on surten realment les mètriques d'un clúster (una de les majors fonts de confusió per a qui comença), com instrumentar api-reserves amb mètriques de negoci, com desplegar l'estoc amb l'operador que vam anunciar a 06-07, i com escriure PromQL que respongui a preguntes reals de Rutas Norte. En acabar, la plataforma tindrà memòria.

1. Què aporta Prometheus davant de metrics-server
2. El model d'extracció (pull) i els endpoints /metrics
3. El model de dades: sèries, etiquetes i els quatre tipus de mètrica
4. D'on surten les mètriques d'un clúster: la taula que aclareix la confusió
5. Instrumentar api-reserves amb mètriques de negoci
6. Desplegar el kube-prometheus-stack amb Helm
7. El Prometheus Operator i els seus recursos personalitzats
8. ServiceMonitor de Rutas Norte i diagnòstic d'objectius
9. PromQL des de zero i amb sentit
10. Els quatre indicadors daurats aplicats a Rutas Norte
11. Emmagatzematge, retenció i els límits de Prometheus
12. Errors comuns i consells
13. Exercicis

Tres coses, i les tres són les que ens faltaven.

Històric. Prometheus desa cada mostra en una base de dades de sèries temporals al disc. Amb la retenció per defecte de l'estoc tindrem uns quants dies; configurant l'emmagatzematge, setmanes o mesos. La pregunta de les tres de la matinada té resposta.

Consultes. PromQL és un llenguatge complet per agregar, filtrar, derivar i comparar sèries. No és "veure un número": és "dóna'm la taxa d'errors 5xx d'api-reserves a l'entorn de producció, agrupada per ruta, durant l'última hora".

Alertes. Prometheus avalua expressions periòdicament i, quan es compleixen durant un temps sostingut, dispara alertes que Alertmanager encamina a qui correspongui. Això és el que fa que algú se n'assabenti a les tres de la matinada sense estar mirant una pantalla.

I una quarta, menys òbvia però decisiva: qualsevol cosa pot exposar mètriques. metrics-server només sap de CPU i memòria. Prometheus recull el que sigui que un endpoint HTTP li ofereixi: peticions per ruta, reserves confirmades, mida de la cua de correus, connexions actives de PostgreSQL, certificats a punt de caducar.

Tots dos conviuen. No substituïm metrics-server: el complementem.

Aquí hi ha la decisió de disseny que defineix tota la resta.

La majoria de sistemes de monitoratge tradicionals funcionen per empenta (push): l'aplicació envia les seves mètriques a un servidor central. Prometheus fa el contrari: extracció (pull). Prometheus té una llista d'objectius (targets) i, cada cert interval (típicament 30 segons), fa un GET a cadascun.

Per què és millor extreure que rebre?

• Prometheus sap si un objectiu ha caigut. Si el GET falla, la mètrica sintètica up val 0. Amb push, l'absència de dades és ambigua: l'aplicació ha caigut o simplement no ha enviat res?
• El control del ritme el té el sistema de monitoratge, no les aplicacions. Cent aplicacions mal programades no el poden inundar.
• Descobriment automàtic. Prometheus consulta l'API de Kubernetes per saber quins pods existeixen. Un pod nou apareix com a objectiu automàticament, sense configurar res a l'aplicació.
• Depuració trivial. Pots fer curl a l'endpoint /metrics des del teu portàtil i veure exactament el mateix que veu Prometheus.

L'excepció són els processos de vida molt curta, com el nostre CronJob informes-ocupacio: pot acabar abans que Prometheus l'escanegi. Per a aquests casos existeix el Pushgateway, un intermediari al qual el job empeny les seves mètriques i que Prometheus escaneja després. És l'única excepció legítima i convé fer-la servir amb moderació.

És text pla. Cada línia és nom{etiquetes} valor. Les línies # HELP i # TYPE són metadades: descripció i tipus. Aquest format, deliberadament simple, és tot el contracte entre una aplicació i Prometheus.

Una sèrie temporal a Prometheus s'identifica de manera única pel seu nom de mètrica més el conjunt exacte de les seves etiquetes. Això és fonamental:

Canviar el valor d'una sola etiqueta crea una sèrie completament nova. Cada sèrie ocupa memòria i disc, i d'aquí neix el perill més citat de Prometheus: la cardinalitat.

Regla d'or de la cardinalitat: no facis servir mai com a etiqueta un valor amb molts valors possibles. Res d'identificadors d'usuari, de reserva, de sessió, adreces IP de client, marques de temps o missatges d'error complets.

Un exemple real del perill. Si api-reserves etiquetés cada petició amb el dni del client:

Amb 200 000 clients i 15 rutes, tindries 3 milions de sèries només d'aquella mètrica. Prometheus es quedaria sense memòria en minuts. I, a més, estaries ficant dades personals al sistema de monitoratge, amb les implicacions que veurem a 07-05.

Etiquetes que Prometheus afegeix per si mateix a tot el que recull a Kubernetes (i que farem servir constantment):

counter (comptador). Un valor que només creix: peticions ateses, errors, bytes enviats, reserves confirmades. No es consulta mai directament. El valor absolut 184203 no diu res: són moltes? des de quan? Es consulta sempre amb rate() o increase(), que calculen quant ha crescut per unitat de temps. Per convenció, el seu nom acaba en _total.

Prometheus detecta automàticament els reinicis del comptador (quan un pod es recrea, el comptador torna a 0) i rate() els compensa. No te n'has de preocupar.

gauge (mesurador). Un valor que puja i baixa: connexions actives, temperatura, memòria en ús, mida d'una cua. Es consulta directament. És el tipus de gairebé tot el que exposa cAdvisor sobre memòria.

histogram (histograma). El tipus més potent i el pitjor entès. En lloc de desar cada valor individual, l'aplicació classifica cada observació en cubetes acumulatives predefinides. Una mètrica d'histograma exposa en realitat tres coses:

Lectura: 8140 peticions van trigar menys de 50 ms; 9210 van trigar menys de 100 ms (incloses les 8140 anteriors: són acumulatives); 9821 en total, per tant 9 peticions van trigar més d'1 segon.

Amb aquestes dades, la funció histogram_quantile() pot estimar qualsevol percentil. L'avantatge enorme davant del summary: com que les cubetes són comptadors normals, es poden sumar entre pods. Pots calcular el percentil 95 de latència de tot api-reserves agregant les seves sis rèpliques. Amb un summary això és matemàticament impossible.

El cost: cada cubeta és una sèrie. Un histograma amb 10 cubetes i 15 rutes són 150 sèries per pod. Tria les cubetes amb criteri, ajustades a la latència real del teu servei.

summary (resum). L'aplicació calcula els percentils ella mateixa i els exposa. Barat de consultar, però no agregable entre instàncies: el percentil 95 del pod A i el del pod B no es poden combinar per obtenir el del servei. A Kubernetes, on tot té diverses rèpliques, això el descarta gairebé sempre. Fes-lo servir només si necessites un percentil exacte d'una única instància.

Prometheus té convencions que convé respectar perquè les eines i els quadres de comandament les assumeixen:

• Prefix amb el nom del sistema: rutasnorte_.
• Unitat base al nom i sempre en unitats base del SI: _segons no _ms, _bytes no _mb.
• Els comptadors acaben en _total.
• Noms en snake_case, sense majúscules.

Aquesta és la secció que resol el dubte que té tothom la primera setmana: "per què necessito quatre coses diferents per monitorar Kubernetes?".

La resposta curta: perquè són quatre capes de realitat diferents i cap d'elles pot veure les altres.

Anem una a una, perquè la distinció importa moltíssim a l'hora d'escriure consultes.

És la mateixa font que alimenta metrics-server (07-02), però Prometheus la llegeix directament i amb molt més detall. Mètriques clau:

Fixa't en la tercera: el comptador de períodes estrangulats que a 07-02 vam dir que kubectl top no ens pot donar. Aquí està, i és la que confirmarà el diagnòstic de throttling d'api-reserves.

Avís pràctic: aquestes mètriques també apareixen amb container="" (el valor agregat del pod, inclòs el contenidor pause d'infraestructura). Gairebé sempre voldràs filtrar amb container!="" per no comptar el doble.

És un DaemonSet (un pod per node, com vam estudiar a 06-02) que llegeix /proc i /sys del sistema amfitrió. Veu coses que cap contenidor no pot veure:

És el que t'avisa que el disc del node s'està omplint, que la càrrega mitjana està pels núvols o que la targeta de xarxa està saturada. Cap contenidor no et pot dir això de si mateix.

Aquesta és la que més costa entendre i la que més falta fa. No mesura el consum de res. Es connecta a l'API de Kubernetes i converteix l'estat dels objectes en mètriques:

Amb aquestes mètriques pots alertar de coses que cap de les altres fonts no coneix: un Deployment amb menys rèpliques disponibles de les desitjades, un pod reiniciant-se en bucle, un Job que ha fallat, un PVC que porta vint minuts en Pending.

I una cosa molt útil: kube_pod_container_resource_requests exposa les requests declarades. Creuant-la amb container_memory_working_set_bytes de cAdvisor obtens, en una sola consulta PromQL, exactament l'anàlisi de recalibració que a 07-02 vam haver de fer amb un script de bash.

PostgreSQL no parla el format de Prometheus. Un exportador és un procés que es connecta al programari, consulta les seves estadístiques internes i les tradueix a /metrics.

I aquí connectem amb 06-04: ja el tenim desplegat. Quan vam afegir el sidecar exportador de mètriques al pod de postgres-reserves, vam dir explícitament que Prometheus el consumiria en aquesta lliçó. Ha arribat el moment.

El que exposa, i que ens farà falta:

Existeixen exportadors per a pràcticament tot: redis_exporter per a redis-cache, nginx-prometheus-exporter per a botiga-web, blackbox_exporter per comprovar des de fora que https://www.rutasnorte.example respon.

Cap de les quatre fonts anteriors no et pot dir quants bitllets has venut. Això només ho sap el teu codi. És la secció següent.

La instrumentació pròpia és el que separa un quadre de comandament d'infraestructura d'un que li importa al negoci. "El pod fa servir 300 Mi de RAM" no interessa al director de Rutas Norte. "Estem confirmant 12 reserves per minut, un 40 % menys que ahir a aquesta hora" sí.

api-reserves està en Node.js, així que fem servir la llibreria client oficial prom-client. Existeixen llibreries equivalents per a Java, Go, Python, .NET i pràcticament qualsevol llenguatge.

I el middleware que ho connecta amb Express:

Dues decisions a subratllar:

1. Ruta normalitzada, no URL real. req.route.path dóna /api/reserves/:id, amb la qual cosa totes les reserves comparteixen sèrie. Fer servir req.originalUrl donaria /api/reserves/48213, /api/reserves/48214... una sèrie per reserva. És l'error de cardinalitat més freqüent del món.
2. /metrics al mateix port que l'aplicació, o en un a part. Aquí el deixem al 8080 per simplicitat. En producció és preferible exposar-lo en un port diferent (per exemple 9090) que no estigui publicat a l'Ingress, perquè les mètriques no siguin accessibles des d'internet. Les NetworkPolicies de rutas-norte-pro (04-06) hauran de permetre el trànsit des del namespace de monitoratge a aquell port: recorda que tota conversa nova necessita la seva política.

Instal·lar Prometheus a mà a Kubernetes significa gestionar una vintena d'objectes entre Deployments, ConfigMaps, Services, RBAC i emmagatzematge. La comunitat ha empaquetat tot això en un chart de Helm anomenat kube-prometheus-stack.

Nota: Helm és el gestor de paquets de Kubernetes i l'estudiarem a fons a 10-03. Aquí el fem servir com a eina d'instal·lació; per ara n'hi ha prou d'entendre que un chart és una plantilla parametritzable de manifests i que helm install els genera i els aplica.

Fitxer de valors adaptat a Rutas Norte:

Què acabem d'instal·lar:

Accés a la interfície de Prometheus:

Aquí es materialitza el que vam anunciar a 06-07. El Prometheus Operator és l'exemple canònic del patró operador: un controlador que observa recursos personalitzats i reconcilia l'estat real fins que coincideixi.

Sense operador, afegir un objectiu nou a Prometheus significa editar un fitxer prometheus.yml, ficar-lo en un ConfigMap, recarregar la configuració i esperar. Un procés manual, centralitzat i propens a errors.

Amb operador, l'equip que desplega api-reserves crea un objecte ServiceMonitor al costat de la seva pròpia aplicació, al seu propi namespace, i l'operador el detecta i regenera la configuració de Prometheus automàticament. El monitoratge passa a ser responsabilitat descentralitzada, versionada a Git juntament amb la resta de manifests.

I AlertmanagerConfig, per configurar l'encaminament d'alertes per namespace. També a 07-04.

Com vam veure a 06-06, tots aquests són CRDs. I com Certificate de cert-manager o VolumeSnapshot, es gestionen amb kubectl exactament igual que un Deployment.

Requisit imprescindible: el ServiceMonitor referencia el port pel seu nom, així que el Service l'ha de tenir anomenat.

Com que postgres-reserves és un StatefulSet amb Service headless (06-01), necessitem un Service addicional específic per a mètriques. Un Service headless (clusterIP: None) funciona igual de bé com a origen d'un ServiceMonitor, perquè l'operador fa servir els Endpoints, no la ClusterIP.

Amb això, el sidecar que vam afegir a 06-04 comença a alimentar Prometheus. La promesa es compleix.

La nostra convenció és clara: a rutas-norte-pro hi ha una deny-all i cada conversa s'autoritza una a una. Prometheus viu a monitoratge i vol parlar amb els ports de mètriques de rutas-norte-pro. Sense política, tots els objectius apareixeran caiguts.

A la interfície de Prometheus, Status → Targets. O per línia d'ordres:

És la pregunta d'aquesta lliçó. Llista de comprovació per ordre de freqüència:

El punt 3 mereix detall perquè és traïdor. El recurs Prometheus té un serviceMonitorSelector. Si el chart el va deixar amb release: monitoratge, només recollirà ServiceMonitor amb aquella etiqueta, i el teu serà ignorat en silenci: no hi ha esdeveniment, no hi ha error, simplement no apareix.

Dues solucions: posar serviceMonitorSelectorNilUsesHelmValues: false als valors (el que hem fet), o afegir l'etiqueta release: monitoratge a tots els teus ServiceMonitor.

Comprovar directament si l'objectiu està sent escanejat:

Un array buit significa que l'objectiu no està configurat (problemes 1-4). Un resultat amb value: ["...", "0"] significa que està configurat però no respon (problemes 5-7).

PromQL espanta al principi i és més senzill del que sembla si s'aprèn per capes.

La consulta més simple és el nom d'una mètrica:

Retorna totes les sèries amb aquell nom: una per cada combinació d'etiquetes de cada pod. Per filtrar, es fan servir les claus:

Els quatre operadors de comparació d'etiquetes:

Combinables, amb AND implícit:

Lectura: peticions a /api/reserves en producció que van retornar un codi 5xx.

Afegint [5m] obtens, en lloc d'un valor per sèrie, tots els valors dels últims 5 minuts:

Això s'anomena vector de rang i no es pot dibuixar directament: és matèria primera per a les funcions del nivell següent.

rate() — la funció més important de PromQL.

Calcula l'increment per segon d'un comptador dins d'una finestra. És el que converteix un comptador inútil (184203) en una dada amb sentit (12,4 peticions per segon).

Tres coses que cal saber sobre rate():

• Només funciona amb comptadors. Aplicar-la a un gauge dóna resultats sense sentit.
• Compensa automàticament els reinicis del comptador quan un pod es recrea.
• La finestra ha de contenir almenys 4 mostres. Amb interval: 30s, la finestra mínima raonable és [2m]; l'habitual és [5m]. Amb [1m] i escanejos de 30 s tindries dues mostres i resultats erràtics.

increase() — igual que rate() però dóna l'increment total de la finestra en lloc de per segon. És literalment rate() * segons_de_la_finestra. Més llegible per a preguntes humanes:

sum by i sum without — agregació.

rate() retorna una sèrie per pod i per combinació d'etiquetes. Gairebé mai vols això: vols el total del servei.

sum by (a, b) conserva només les etiquetes a i b. sum without (pod, instance) conserva totes menys aquestes. La segona forma sol ser més robusta davant de canvis.

Altres agregacions: avg, min, max, count, stddev, topk, bottomk.

topk() — els N més grans. Perfecte per a "qui s'està menjant el clúster?":

histogram_quantile() — percentils a partir d'histogrames.

Descomponent, de dins cap enfora:

1. rate(..._bucket[5m]) → taxa d'increment de cada cubeta.
2. sum by (le, ruta) → suma les cubetes de tots els pods, conservant le (el límit de la cubeta) i ruta. L'etiqueta le és obligatòria: sense ella, histogram_quantile no pot funcionar. És l'error més comú amb aquesta funció.
3. histogram_quantile(0.95, ...) → estima el percentil 95.

El resultat és en segons: 0.412 significa que el 95 % de les peticions es resolen en menys de 412 ms.

Precisió: el resultat és una estimació per interpolació lineal dins de la cubeta. Si les teves cubetes són [0.1, 0.5, 1] i el p95 real està en 0,42 s, l'estimació pot desviar-se bastant. Per això vam triar cubetes ajustades a la nostra latència real a l'apartat 5.

Operadors aritmètics i comparació entre mètriques.

Prometheus aparella sèries de tots dos costats per les seves etiquetes comunes. Si les etiquetes no coincideixen, el resultat és buit: és la causa de la meitat de les consultes que "no retornen res". on() i ignoring() permeten controlar l'aparellament.

Peticions per segon per ruta:

Taxa d'error (proporció de 5xx sobre el total):

Retorna un número entre 0 i 1. Multiplicat per 100 és el percentatge. Advertiment: si el denominador és 0 (sense trànsit), el resultat és NaN i desapareix del gràfic. És un comportament correcte: sense trànsit no hi ha taxa d'error a mesurar.

Percentil 95 de latència per ruta:

Reserves confirmades per minut (la mètrica del negoci):

Saturació de CPU respecte al límit configurat:

Un valor de 0.95 significa que el pod està fent servir el 95 % del seu límit: candidat immediat a throttling.

Confirmar el throttling que a 07-02 no podíem veure:

És la fracció de períodes de planificació en què el contenidor va ser estrangulat. Per sobre de 0.25 (25 %) hi ha un problema real de rendiment. Aquesta és exactament la consulta que hauria diagnosticat el problema d'api-reserves a 07-02 en deu segons.

Comparar consum real amb les requests: la recalibració de 07-02, ara automatitzada:

Amb Prometheus, aquesta consulta sobre 30 dies d'històric substitueix per complet l'script de bash de 07-02, i a més permet demanar el percentil real fent servir quantile_over_time.

Rèpliques no disponibles (fa servir kube-state-metrics):

Objectiu caigut:

Pods reiniciant-se en bucle:

Connexions de PostgreSQL respecte al màxim (del sidecar de 06-04):

Errors de la passarel·la de pagaments externa:

Aquesta consulta permet distingir "la nostra plataforma falla" de "el proveïdor extern falla", que és una distinció molt valuosa a les tres de la matinada.

Els quatre indicadors daurats (golden signals), popularitzats pel llibre d'SRE de Google, són el marc que evita l'error de monitorar-ho tot i no entendre res.

Un matís essencial sobre la latència: cal mesurar per separat la de les peticions que fallen. Un error 500 retornat en 3 ms baixa artificialment la latència mitjana i pot fer que un servei que falla massivament sembli rapidíssim.

Les consultes concretes per a api-reserves, que seran la base del quadre de comandament de 07-04:

Aquesta última consulta tanca un cercle del mòdul: és exactament el fenomen que a 07-01 deixava api-reserves viva però inservible. Aleshores només teníem una readiness que apartava el pod; ara tenim a més la dada registrada i consultable a posteriori.

Consultes com el p95 són cares: recorren moltes sèries. Si un quadre de comandament l'executa cada 15 segons amb 8 panells oberts, Prometheus pateix.

Les regles de gravació (recording rules) precalculen una consulta periòdicament i desen el resultat com una mètrica nova:

Ara els quadres de comandament i les alertes consulten apireserves:latencia_p95:5m, que és una única sèrie ja calculada. A 07-04 les farem servir intensivament.

Prometheus escriu a la seva pròpia base de dades de sèries temporals (TSDB):

1. Les mostres noves van a un bloc en memòria i a un registre d'escriptura anticipada (WAL) al disc, que protegeix davant de caigudes.
2. Cada 2 hores, aquell bloc es persisteix com un directori immutable al disc.
3. Un procés de compactació va fusionant blocs petits en blocs majors.
4. Els blocs que superen la retenció s'esborren sencers.

Conseqüència important: la retenció no esborra mostres soltes, esborra blocs complets. Amb retention: 30d pots tenir puntualment una mica més de 30 dies.

La regla pràctica acceptada: entre 1 i 2 bytes per mostra després de la compressió.

Amb 50 GiB de PVC anem de sobres, fins i tot amb marge per a la compactació (que necessita espai temporal). Per això vam posar també retentionSize: 45GiB: és el fre d'emergència si la cardinalitat creix més del previst.

Veure la cardinalitat real:

Aquesta segona consulta és la primera que cal executar quan Prometheus comença a consumir massa memòria.

Tres limitacions de disseny, deliberades:

1. Emmagatzematge local, no distribuït. Les dades viuen al disc d'un pod. Sense replicació entre instàncies.
2. No escala horitzontalment per si mateix. Dos Prometheus no comparteixen dades: cadascun té les seves.
3. La retenció llarga és cara. Desar dos anys en local significa centenars de GB en un disc ràpid i un consum de memòria considerable en consultar.

Per a retenció llarga i visió multiclúster existeixen dos projectes que estenen Prometheus:

Tots dos permeten anys de retenció barata i consultar diversos clústers alhora. Per a Rutas Norte amb un sol clúster, 30 dies són suficients avui; quan el mòdul 11-05 abordi la gestió multiclúster, Thanos serà l'evolució natural.

Configurar remote_write des de l'operador és senzill:

1. Explosió de cardinalitat. L'error més greu i el més car. Etiquetar amb identificadors de reserva, DNI, IP de client o URL sense normalitzar multiplica les sèries per milers i tomba Prometheus per falta de memòria. Abans d'afegir una etiqueta, pregunta't quants valors diferents pot tenir. Si la resposta és "no ho sé", no l'afegeixis.

2. Consultar un comptador sense rate(). rutasnorte_peticions_total a seques retorna un valor acumulat des que va arrencar el pod. És un gràfic que només puja i no significa res. Sempre rate() o increase().

3. Finestra de rate() massa curta. Amb interval: 30s, un rate(...[1m]) té dues mostres i produeix soroll o forats. Regla: la finestra ha de ser almenys 4 vegades l'interval d'escaneig.

4. Oblidar le a sum by abans d'histogram_quantile. Si agregues sense conservar l'etiqueta le, la funció no pot reconstruir l'histograma i retorna NaN o res. És l'error número u amb percentils.

5. El ServiceMonitor selecciona etiquetes de pod en lloc de Service. El selector d'un ServiceMonitor es compara amb les etiquetes de l'objecte Service. Com que a Rutas Norte els Service porten les mateixes etiquetes que els pods, és fàcil no adonar-se'n fins que un Service té etiquetes diferents.

6. L'etiqueta release de l'operador. Si el recurs Prometheus té serviceMonitorSelector: {matchLabels: {release: monitoratge}}, els teus ServiceMonitor sense aquella etiqueta s'ignoren sense cap missatge d'error. Comprovar-ho és el primer quan un objectiu no apareix.

7. Prometheus sense emmagatzematge persistent. Sense storageSpec, el chart fa servir un emptyDir i cada reinici del pod esborra tot l'històric. És exactament el problema que veníem a resoldre.

8. Sense retentionSize. Només amb retention: 90d, si la cardinalitat creix, el disc s'omple, Prometheus entra en CrashLoopBackOff i et quedes sense monitoratge justament quan més falta fa. Posa sempre un límit de mida, i que sigui un 80-85 % del PVC.

9. Alertar sobre mètriques d'un summary. No són agregables entre pods. Si la teva alerta fa servir el p99 d'un summary amb sis rèpliques, el número no significa res útil.

10. Monitorar el node amb mètriques de contenidor. cAdvisor no veu el sistema de fitxers del node ni la seva càrrega mitjana. Per a això hi ha node-exporter. Confondre'ls porta a alertes que no disparen mai.

11. Oblidar les NetworkPolicies. A rutas-norte-pro hi ha una deny-all. Si Prometheus no pot arribar als ports de mètriques, tots els objectius apareixen caiguts i l'error (context deadline exceeded) no és gens evident.

12. Instrumentar massa tard. La instrumentació de negoci s'afegeix al codi, així que requereix un cicle de desenvolupament. Com abans s'incorpori com a part del "llest per a producció", millor. Improvisar-la durant un incident és impossible.

L'equip ha desplegat redis-cache amb un exportador i ha creat aquests manifests. A la pàgina de targets de Prometheus no apareix res.

1. Identifica tres errors diferents.
2. Escriu els manifests corregits.
3. Escriu l'ordre PromQL o curl que confirma que el problema està resolt.

El dissabte del pont, entre les 12:00 i les 13:30, els clients es van queixar que el web anava lentíssim i algunes compres fallaven. Ja ha passat, ningú va prendre notes, i el director demana explicacions el dilluns.

Escriu les consultes PromQL que responen a cada pregunta. Indica de quina font (cAdvisor, kube-state-metrics, node-exporter, exportador o instrumentació pròpia) surt cada mètrica.

1. Quantes peticions per segon atenia api-reserves en aquell interval, comparat amb el dissabte anterior?
2. Quin va ser el percentil 99 de latència de /api/reserves durant l'incident?
3. Estava api-reserves patint throttling de CPU?
4. Es va quedar postgres-reserves sense connexions disponibles?
5. Va fallar la passarel·la de pagaments externa, o l'error era nostre?
6. Quantes reserves es van deixar de confirmar respecte al que s'esperava?

worker-notificacions consumeix d'una cua de Redis i envia correus de confirmació. Actualment no exposa cap mètrica. Dissenya la seva instrumentació:

1. Enumera les mètriques que ha d'exposar, amb el seu nom complet, el seu tipus (counter, gauge, histogram) i les seves etiquetes, justificant la cardinalitat de cada etiqueta.
2. Escriu el ServiceMonitor corresponent (el worker no té Service perquè no rep trànsit: resol aquest problema).
3. Escriu les consultes PromQL dels quatre indicadors daurats per a aquest component.

Solució 1

1. Els tres errors.

Error A — El selector del ServiceMonitor no casa amb les etiquetes del Service. El ServiceMonitor busca Services amb app: redis-cache i entorn: pro, però el Service té app.kubernetes.io/name: redis-cache i app.kubernetes.io/part-of: rutas-norte. No en coincideix cap. El spec.selector del Service (que sí que fa servir app/entorn) selecciona pods, no és el que mira el ServiceMonitor.

Error B — El port del Service no té nom, i l'endpoint referencia metrics. El ServiceMonitor busca un port anomenat metrics al Service; el Service defineix el port 9121 sense camp name. L'operador no troba el port i descarta l'endpoint.

Error C — El ServiceMonitor està a monitoratge sense namespaceSelector. Per defecte, un ServiceMonitor busca Services al seu propi namespace. Estant a monitoratge i el Service a rutas-norte-pro, no es trobaran mai. Dues solucions vàlides: moure el ServiceMonitor al namespace de l'aplicació (preferible, manté el monitoratge al costat del codi) o afegir namespaceSelector.

2. Manifests corregits.

I la NetworkPolicy, perquè a rutas-norte-pro hi ha deny-all:

3. Verificació.

"1" és la confirmació. Si donés "0", l'objectiu està configurat però no respon: revisa la NetworkPolicy i que l'exportador escolti al 9121.

Comprovació addicional que l'operador l'ha recollit:

Solució 2

Nota general: totes les consultes fan servir el modificador offset o un rang temporal explícit, ja que l'incident va passar. Aquí hi ha l'avantatge decisiu sobre kubectl top de 07-02: aquestes dades existeixen.

1. Trànsit durant l'incident, comparat amb el dissabte anterior.

Font: instrumentació pròpia d'api-reserves.

Un resultat de 5.8 significa que el dissabte del pont hi va haver gairebé sis vegades més trànsit que el dissabte normal: coherent amb el que sabem dels pics de ponts.

2. Percentil 99 de latència de /api/reserves.

Font: instrumentació pròpia (histograma).

Es compara amb el p95 i amb la mitjana (_sum / _count) per veure si el problema afectava totes les peticions o només la cua:

Si la mitjana està bé i el p99 disparat, el problema afecta un subconjunt (per exemple, les peticions que toquen la passarel·la de pagaments). Si tots dos pugen, és sistèmic.

3. Throttling de CPU.

Font: cAdvisor / kubelet.

Un valor sostingut per sobre de 0.30 durant l'incident confirma que el límit de CPU estava frenant l'aplicació. Complementària, per veure si estava enganxada al sostre:

(La segona part ve de kube-state-metrics: és l'exemple perfecte de per què calen les dues fonts.)

4. Connexions de PostgreSQL.

Font: exportador sidecar de 06-04, més les mètriques pròpies del pool.

Un numbackends / max_connections proper a 1 confirma que la base de dades estava saturada de connexions.

5. Va fallar la passarel·la externa o vam fallar nosaltres?

Font: instrumentació pròpia.

Interpretació: si la taxa d'error de la passarel·la puja al 40 % mentre el nostre ratio_errors general també puja, l'error és del proveïdor i cal reclamar-l'hi. Si la passarel·la està al 0,1 % d'errors i nosaltres retornem 5xx, el problema és nostre. Aquesta distinció, impossible sense instrumentació, és el que es porta a la reunió del dilluns.

6. Reserves deixades de confirmar.

Font: instrumentació pròpia (mètrica de negoci).

I un encreuament especialment revelador: si el trànsit es va multiplicar per 5,8 però les reserves confirmades només per 1,3, la diferència entre tots dos factors és una estimació directa del negoci perdut. Aquest número, en euros, és el que justifica el pressupost d'infraestructura.

Solució 3

1. Mètriques del component.

Cardinalitat total: unes 43 sèries per pod. Perfectament assumible.

Etiquetes descartades deliberadament i per què:

• destinatari (correu del client): cardinalitat il·limitada i, sobretot, dada personal al sistema de monitoratge. Prohibit. Hi tornarem a 07-05.
• id_reserva: cardinalitat il·limitada. Aquella dada pertany als logs, no a les mètriques. Les mètriques agreguen; els logs detallen.
• missatge_error complet: cardinalitat impredictible. Se substitueix per motiu, un conjunt tancat de categories.

2. ServiceMonitor per a un component sense Service.

worker-notificacions no rep trànsit, així que no té Service. Dues opcions vàlides:

Opció A (recomanada): PodMonitor. És exactament el recurs dissenyat per a aquest cas.

Amb el port declarat al Deployment:

Opció B: crear un Service headless només per a mètriques i fer servir un ServiceMonitor normal. Funciona, però crea un objecte que no aporta res més. El PodMonitor és més net.

I la NetworkPolicy corresponent:

3. Els quatre indicadors daurats.

Consulta addicional de cobertura, molt valuosa per al negoci: relaciona dos components diferents per detectar correus perduts.

Aquest tipus de consulta —que creua mètriques de dos components per verificar una invariant del negoci— és de les més útils que es poden escriure, i a 07-04 la convertirem en alerta.

Rutas Norte ha passat de no recordar res a tenir memòria, llenguatge i capacitat de pregunta. En aquesta lliçó hem:

• Entès el model d'extracció i per què és superior al d'empenta en un entorn dinàmic com Kubernetes.
• Après el model de dades: sèries identificades per nom i etiquetes, l'amenaça permanent de la cardinalitat, i els quatre tipus de mètrica, amb l'histogram com l'únic que permet calcular percentils agregats entre rèpliques.
• Aclarit la confusió clàssica sobre d'on surten les mètriques: cAdvisor mesura el consum real dels contenidors, node-exporter el sistema operatiu del node, kube-state-metrics l'estat dels objectes de l'API, els exportadors tradueixen programari de tercers —inclòs el sidecar de postgres-reserves que vam afegir a 06-04, ara per fi connectat— i la instrumentació pròpia és l'única que sap de negoci.
• Instrumentat api-reserves amb peticions per ruta i codi, latència en histograma, reserves confirmades i l'estat del pool de connexions, tenint cura de la cardinalitat en cada decisió.
• Desplegat el kube-prometheus-stack i treballat amb el Prometheus Operator que vam anunciar a 06-07, creant ServiceMonitor que viuen al costat de cada aplicació i sabent diagnosticar per què un objectiu no apareix.
• Escrit PromQL de debò: rate, increase, sum by, topk, histogram_quantile, i les consultes concretes dels quatre indicadors daurats de cada component. Entre elles, la que confirma el throttling que a 07-02 només podíem sospitar.
• Dimensionat l'emmagatzematge i la retenció, i entès per què Prometheus no és un arxiu etern i quan tocarà mirar cap a Thanos o Mimir.

Però continuem tenint un problema pràctic: tot això viu en una interfície web austera on cal escriure consultes a mà, i ningú l'està mirant a les tres de la matinada. Tenir la dada no serveix de res si ningú la veu ni ningú rep l'avís.

A 07-04 farem aquest salt: construirem amb Grafana el quadre de comandament de Rutas Norte, panell a panell, amb variables que serveixin per als tres entorns; escriurem el catàleg d'alertes de la plataforma amb PrometheusRule —inclosa la que prediu quan s'omplirà el disc de postgres-reserves abans que passi—; i configurarem Alertmanager perquè l'alerta correcta arribi a la persona correcta, agrupada, sense soroll i amb un enllaç al procediment que cal seguir.