Pregunta-li avui a la Marta com sap que la botiga d'AlpinaShop funciona. La resposta honesta és: perquè ningú no s'ha queixat. I si alguna cosa va malament, se n'assabenta d'una d'aquestes tres maneres: un client escriu a atenció al client, en Dani obre el web per casualitat i el nota lent, o la Lucía veu l'endemà que les vendes d'ahir van ser estranyes.

Les tres tenen el mateix defecte: la detecció la fa una persona, tard i per casualitat. I el cost d'aquella manera d'assabentar-se és alt i silenciós. Un incident de vint minuts en plena campanya de tardor pot passar completament desapercebut i endur-se per davant centenars de comandes.

Aquesta lliçó canvia això. En acabar, AlpinaShop tindrà un tauler que mostra l'estat de la botiga d'un cop d'ull, comprovacions que la vigilen des de quatre continents, alertes que arriben al mòbil de la Marta abans que cap client escrigui, i un agrupador automàtic d'excepcions que avisa quan un desplegament introdueix un error nou.

Una nota prèvia sobre el nom. Stackdriver va ser una empresa que Google va adquirir el 2014 i el producte de la qual va donar origen a tota la suite d'operacions. El nom es va retirar el 2020 i avui els serveis es diuen Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler i Error Reporting. Veuràs "Stackdriver" en documentació antiga, en noms de biblioteques heretades i en converses de gent amb certa veterania; convé reconèixer-lo, però és un nom històric.

1. Observabilitat i els seus tres pilars
2. El model de dades de mètriques
3. L'espai de mètriques: veure els tres projectes alhora
4. Mètriques de plataforma que ja tens gratis
5. Explorar: alineadors, agregacions i per què la mitjana menteix
6. El tauler de la campanya de tardor
7. El tauler com a JSON versionable
8. MQL i PromQL per a consultes avançades
9. Alertes: anatomia d'una política
10. Canals de notificació i les tres alertes d'AlpinaShop
11. Fatiga d'alertes: la conversa incòmoda
12. Mètriques personalitzades des de l'aplicació
13. Comprovacions de disponibilitat
14. Error Reporting: excepcions agrupades
15. L'agent d'operacions a les VM del MIG
16. Cost de l'observabilitat

Monitoratge és comprovar si les coses que sabies que podien fallar estan fallant. Observabilitat és la propietat d'un sistema que permet entendre què li està passant per dins a partir del que emet cap a fora, incloses les fallades que no vas anticipar.

La diferència no és acadèmica. Un tauler amb la CPU de les VM és monitoratge: respon a "està alta la CPU?". Poder respondre a "per què els clients de Canàries tenen el checkout lent des de dimarts?" sense desplegar res nou és observabilitat.

Es recolza en tres pilars:

Cadascun té un perfil diferent de cost i d'utilitat, i per això conviuen:

• Les mètriques són barates d'emmagatzemar i consultar perquè són agregats, permeten veure mesos d'història i són la base natural de les alertes. Però no et diuen què li va passar a un client concret: et diuen que el p95 va pujar.
• Els registres tenen tot el detall de cada esdeveniment, i per això són cars i cal ser selectiu. Responen preguntes concretes sobre casos concrets.
• Les traces mostren com es reparteix el temps d'una petició entre serveis, i són l'única cosa que respon a "qui està trigant?" en un sistema amb diverses peces.

El recorregut típic d'un incident els utilitza tots tres en ordre: una alerta sobre una mètrica avisa que passa alguna cosa, el tauler de mètriques acota què i on, els registres diuen què està fallant exactament, i la traça explica per què. Aquell recorregut complet es fa de principi a fi a 06-06.

Un avís d'abast: aquí es construeixen mètriques, taulers i alertes. Els objectius de nivell de servei (SLO) i els pressupostos d'error —definir formalment què significa "funcionar bé" i quanta fallada és tolerable— arriben a 07-06. Aquí s'instal·len els instruments; allà es decideix quins nombres són acceptables.

Gairebé tots els problemes que la gent té amb Cloud Monitoring vénen de no tenir clar aquest model. Mereix cinc minuts.

Una sèrie temporal és la unitat fonamental, i s'identifica per la combinació de tres coses:

Aquell disseny explica una cosa que sorprèn al principi: el nombre de sèries temporals es multiplica amb les etiquetes. Si una mètrica té 3 classes de codi de resposta, 5 rutes i 2 regions, són 30 sèries. Si algú afegeix una etiqueta amb l'identificador de client, i hi ha 50.000 clients, són 1.500.000 sèries. Això s'anomena explosió de cardinalitat, es paga i pot arribar a fer inutilitzable la mètrica. Hi tornarem a l'apartat 12, que és on es comet l'error.

Distingir-los és imprescindible perquè cadascun es consulta de manera diferent:

El comptador és el que més confusió causa. request_count del balancejador és acumulat: el seu valor creix indefinidament. Si el pintes tal qual, veus una rampa ascendent que no diu res. El que vols és la taxa: quantes peticions per segon. Per això als comptadors se'ls aplica sempre un alineador rate o delta.

La distribució és la més valuosa i la més desaprofitada. Una mètrica de latència com a distribució no guarda un nombre per interval: guarda un histograma complet. Això permet preguntar el percentil 50, el 95 i el 99 a posteriori, sense haver decidit per endavant quin t'interessava. Si en el seu lloc guardessis només la latència mitjana, hauries perdut la informació per sempre, i la mitjana és precisament l'estadístic menys útil aquí, com veurem a l'apartat 5.

AlpinaShop té els seus recursos repartits en tres projectes: la botiga a alpinashop-prod, les proves a alpinashop-dev i l'analítica a alpinashop-datos. Per defecte, cada projecte té la seva pròpia vista de mètriques, cosa que obliga a saltar entre tres consoles per entendre un incident. Insostenible.

Un espai de mètriques (metrics scope) resol això: un projecte actua de projecte d'àmbit i agrega les mètriques de diversos projectes monitorats.

Un detall de disseny que convé pensar abans d'executar: quin ha de ser el projecte d'àmbit? Utilitzar alpinashop-prod és el més habitual i el més simple. L'alternativa —crear un projecte dedicat, per exemple alpinashop-observabilidad— és més neta conceptualment perquè separa "operar la plataforma" de "ser la plataforma", i permet donar accés de lectura a les mètriques sense donar cap accés a producció. Per a AlpinaShop, amb tres projectes i tres persones, alpinashop-prod és suficient; en una organització amb vint projectes, el projecte dedicat guanya clarament.

I un advertiment important: l'espai de mètriques unifica la vista, no els permisos. Qui consulta un tauler que mostra mètriques d'alpinashop-datos necessita permisos de lectura de monitoratge sobre aquell projecte. És coherent amb 03-04, i evita que agregar la vista es converteixi en una via indirecta d'exposar informació.

Aquí hi ha una bona notícia que molta gent desconeix: GCP ja està recollint centenars de mètriques dels teus recursos, sense que hagis fet res i sense cost afegit. Tota la infraestructura dels mòduls 2, 3 i 4 porta mesos emetent dades que ningú no ha mirat.

Les que importen per a AlpinaShop:

La taula que de debò s'utilitza en un incident és la inversa: del símptoma a la mètrica.

Aquella última fila connecta directament amb 03-03: si la ràtio d'encerts de Cloud CDN cau, el trànsit va al backend, la factura de sortida puja i la latència empitjora. És una fallada silenciosa perfecta —res no es trenca, tot es degrada— i només es detecta mirant la mètrica.

L'explorador de mètriques és l'eina de consulta interactiva. El seu model té quatre passos i convé entendre'ls perquè són els mateixos que després apareixen a taulers i alertes.

Alinear converteix els punts crus de cada sèrie en punts regulars d'un interval fix. Agregar combina diverses sèries en menys sèries o en una de sola. L'ordre importa i confondre'ls produeix nombres sense sentit.

Aquest és el concepte més important de l'apartat, i probablement el que més vegades s'explica malament al sector.

Imagina 1.000 peticions al catàleg en un minut. 950 triguen 100 ms i 50 triguen 8 segons. La mitjana és:

Un tauler amb la mitjana mostra 495 ms. Sembla acceptable. I tanmateix 50 clients per minut estan esperant vuit segons, que és temps de sobres per anar-se'n a un altre web. La mitjana ha ocultat exactament el problema que buscaves.

Els percentils expliquen una altra història:

Tres regles pràctiques que convé adoptar sense excepcions:

1. Per a latència, sempre percentils, mai mitjana. El p50 diu com és l'experiència típica; el p95 i el p99 diuen com de malament està el dolent.
2. No promitgis mai percentils entre sèries. La mitjana dels p95 de deu instàncies no és el p95 del conjunt: és un nombre sense significat estadístic. Cloud Monitoring calcula el percentil sobre la distribució combinada si li demanes percentile_95 com a alineador i sum com a agregació de distribucions; fer-ho al revés produeix escombraries.
3. El p99 importa més del que el seu nom suggereix. Amb un milió de peticions al dia, el p99 són 10.000 peticions. I no toquen a l'atzar a 10.000 clients diferents: solen concentrar-se en els que tenen cistelles grans o històrics llargs, és a dir, els millors clients.

La campanya de tardor és el pic comercial d'AlpinaShop. La Marta vol una pantalla que respongui d'un cop d'ull a "està bé la botiga?".

El principi de disseny, importat de la pràctica d'SRE: un tauler ha d'explicar una història de dalt a baix, començant pel que percep el client i acabant per les causes tècniques. Si en mirar-lo cal pensar, el tauler està malament.

Dues decisions de disseny que mereixen explicació.

La CPU del MIG es mostra dues vegades, mean i max. Si deu instàncies estan al 20 % i una al 98 %, la mitjana diu 27 % —aparentment sa— mentre aquella instància està saturada i servint peticions lentíssimes. És el mateix error conceptual que promitjar latències, aplicat a la capacitat. La mitjana oculta els desequilibris; el màxim els delata.

Latència i errors són a dalt, la infraestructura a baix. L'ordre reflecteix la pregunta que es fa de debò en un incident: primer "pateixen els clients?" i només després "per què?". Un tauler que comença per la CPU convida a mirar mètriques d'infraestructura que poden estar perfectes mentre la botiga està caiguda.

Un tauler construït a clics a la consola és un actiu fràgil: ningú no sap qui el va canviar, no es pot replicar en un altre projecte i desapareix si algú l'esborra. Tot tauler de Cloud Monitoring té una representació en JSON que es pot exportar, versionar a Git —seguint 06-02— i recrear.

Un fragment amb els dos gràfics de la fila 1, que mostra l'estructura sense aclaparar:

Fixa't en la correspondència amb l'apartat 5: perSeriesAligner és l'alineador —ALIGN_RATE per al comptador, ALIGN_PERCENTILE_99 per a la distribució— i crossSeriesReducer és l'agregació. El JSON no és més que la forma escrita del que vas fer a l'explorador.

La manera pràctica de treballar és construir el tauler a la consola fins que quedi bé, exportar-lo, guardar-lo a alpinashop-infra/paneles/ i a partir d'aquí gestionar-lo com a codi. I quan arribi Terraform a 06-07, el recurs google_monitoring_dashboard consumeix exactament aquest JSON, de manera que el tauler passa a crear-se al costat de la infraestructura que monitora.

La interfície de filtres i agregacions cobreix la majoria dels casos, però hi ha preguntes que no expressa: proporcions entre dues mètriques, unions, càlculs derivats. Per a això hi ha dos llenguatges.

MQL (Monitoring Query Language) és el llenguatge propi de Cloud Monitoring, amb sintaxi de canonada:

I el cas on MQL es torna imprescindible, la taxa d'error com a proporció:

Això —dividir dues sèries diferents— no es pot expressar amb filtres i agregacions. I és just el que vols per alertar: el 2 % d'errors és el rellevant, no "200 errors", perquè 200 errors sobre 100.000 peticions és soroll i sobre 500 és una catàstrofe.

PromQL és el llenguatge de Prometheus, suportat a Cloud Monitoring a través de Managed Service for Prometheus. La mateixa consulta:

Per a AlpinaShop, que té la botiga a GKE i aspira a no lligar-se en excés a un proveïdor, PromQL és l'aposta més assenyada a mitjà termini. MQL continua sent útil per a consultes puntuals sobre mètriques de plataforma que no tenen equivalent Prometheus.

Un tauler només serveix si algú el mira. Una alerta treballa per tu.

Una política d'alerta té quatre peces, i cadascuna respon a una pregunta diferent:

La durada és la peça més infravalorada. Sense ella, qualsevol pic instantani dispara una alerta. Un pic de latència de 15 segons perquè l'autoescalador va arrencar una instància no és un incident: és el sistema funcionant. Una alerta que salta per això ensenya l'equip a ignorar-la, que és el pitjor que li pot passar a una alerta.

El criteri per triar la durada és honest i senzill: quant temps ha d'estar malament això perquè mereixi despertar algú? Si la resposta és "cinc minuts", posa cinc minuts.

Una política completa en JSON, la de la taxa d'error d'AlpinaShop:

El camp documentation és el que separa una alerta útil d'una alerta que genera ansietat. Arriba al mòbil d'algú a les onze de la nit; sense instruccions, aquella persona comença des de zero, amb son i amb pressa. Amb les quatre primeres comprovacions escrites, sap què mirar. I l'autoClose de 30 minuts evita que un incident ja resolt deixi un incident obert per sempre.

Un canal defineix com arriba l'alerta:

El canal de Pub/Sub mereix una menció pel que habilita: una alerta pot publicar en un topic i una Cloud Function de 06-03 pot reaccionar automàticament —crear una incidència, executar un diagnòstic, o fins i tot una acció correctora acotada—. És la porta a la resposta automàtica, amb la precaució evident que una automatització que actua sobre producció ha d'estar molt ben acotada.

Deliberadament tres. No trenta.

Alerta 1 — Taxa d'error 5xx > 2 % durant 5 minuts. Canal: Slack + SMS a la Marta.

Raonament del llindar: la taxa d'error normal de la botiga és del 0,1-0,3 %, dominada per peticions a URL que ja no existeixen. El 2 % és un ordre de magnitud per damunt del soroll: no salta per variació natural, i a aquell nivell hi ha clients veient errors. És proporció, no valor absolut, pel que s'ha dit a l'apartat 8. Cinc minuts filtren els pics d'un desplegament.

Alerta 2 — Latència p95 > 2 segons durant 10 minuts. Canal: Slack.

Raonament: el p95 habitual de la botiga ronda els 400 ms. Dos segons és el punt on la percepció canvia de "va bé" a "va lent" i l'abandonament de cistella comença a pujar. Es tria p95 i no p99 perquè el p99 és més volàtil i generaria més soroll; i es tria una durada llarga, 10 minuts, perquè la lentitud transitòria és habitual i no requereix acció immediata. Sense SMS: és un problema que s'atén en horari laboral.

Alerta 3 — Missatges sense confirmar a pedidos-nuevos > 1.000 durant 15 minuts. Canal: Slack + correu.

Raonament: en operació normal la cua està pràcticament buida perquè els consumidors van al dia. Mil missatges acumulats quinze minuts significa que el consumidor està caigut o no dona l'abast, i això vol dir que hi ha comandes que no s'estan processant. És l'exemple d'alerta que detecta una fallada invisible des de fora: el web funciona, els clients compren, tot sembla bé, i les comandes s'estan apilant sense processar.

Fixa't en el patró: cada alerta detecta un tipus diferent de fallada —error visible, degradació visible i fallada invisible—. Deu alertes més sobre CPU no haurien afegit res, perquè la CPU alta ja es manifesta en la latència.

Això mereix un apartat propi perquè és el problema real de l'observabilitat, i gairebé mai no es diu amb claredat.

La fatiga d'alertes és l'estat en què un equip rep tantes alertes que deixa de reaccionar-hi. No és una falta de disciplina: és una resposta racional. Si de vint alertes diàries dinou són soroll, ignorar-les totes és una estratègia amb un 95 % d'encert i un cost enorme quan falla.

Com s'hi arriba, gairebé sempre pel mateix camí:

1. Algú munta una alerta per cada mètrica disponible, "per si de cas".
2. Els llindars es posen a ull, sense mirar els valors històrics.
3. No hi ha durada, així que qualsevol pic dispara.
4. Totes van al mateix canal amb la mateixa urgència.
5. Ningú no revisa ni retira les que no aporten.

Els cinc antídots, en ordre d'importància:

La primera és la més important i la més contraintuïtiva. Una CPU al 90 % no és un problema si els clients no ho noten: pot ser el sistema aprofitant bé els seus recursos. Alertar de la CPU produeix falsos positius —CPU alta sense impacte— i falsos negatius —clients patint amb CPU baixa, per exemple per un bloqueig a la base de dades—. Les causes s'investiguen amb el tauler després que un símptoma hagi avisat.

I una pregunta de control que val més que qualsevol llista, per a cada alerta que es vagi a crear:

Si aquesta alerta salta a les 3 de la matinada, hi ha alguna cosa que algú hagi de fer immediatament?

Si la resposta és no, no és una alerta: és un gràfic en un tauler. La Marta i en Dani només tenen tres alertes configurades, i aquell és deliberadament el senyal d'un sistema d'alertes sa.

Les mètriques de plataforma expliquen què fa la infraestructura. No expliquen què fa el negoci. Cap mètrica de GCP no sap quantes comandes per minut entren a AlpinaShop, i aquella és probablement la mètrica més important de totes: si les comandes cauen a zero, alguna cosa va malament encara que tots els indicadors tècnics estiguin verds.

L'advertiment sobre les etiquetes és la part crítica d'aquest apartat. És temptador afegir serie.metric.labels["id_cliente"] = cliente_id. No ho facis. Amb 50.000 clients actius crearies 50.000 sèries temporals per cada combinació de la resta d'etiquetes, i això és l'explosió de cardinalitat de l'apartat 2: cost alt, consultes lentes i una mètrica inservible.

La regla: una etiqueta de mètrica ha de tenir desenes de valors possibles, no milers. El que és d'alta cardinalitat —l'identificador de client, el de comanda— va als registres, que estan dissenyats per a això, i es consulta des d'allà. És una de les raons per les quals els tres pilars són tres i no un.

Hi ha un camí alternatiu que el 2026 sol ser millor si ja vius a Kubernetes: exposar un endpoint /metrics en format Prometheus i deixar que Managed Service for Prometheus el reculli. Evita una crida a l'API per esdeveniment, és l'estàndard del sector i encaixa amb PromQL. Per al catàleg a GKE, és l'opció que recomanaria.

També existeixen les mètriques basades en registres: comptar entrades de registre que compleixen un filtre i convertir-les en mètrica, sense tocar el codi de l'aplicació. És una tècnica molt potent per instrumentar ràpid el que ja s'està registrant, i es desenvolupa a 06-06.

Tot l'anterior mesura el sistema des de dins. Les comprovacions de disponibilitat (uptime checks) el mesuren des de fora: Google llança peticions des de diverses regions del món i comprova que la botiga respon.

Aquella diferència de punt de vista detecta classes senceres de fallades que cap mètrica interna no veu: un certificat TLS caducat, un registre DNS mal propagat, una regla de Cloud Armor massa agressiva que bloqueja clients legítims, un balancejador mal configurat o una caiguda completa de la regió.

Quatre decisions que convé entendre:

• La ruta /salud és el mateix endpoint que la comprovació d'estat hc-catalogo del balancejador de 03-02. Reutilitzar-lo té sentit, però amb un matís important: la comprovació del balancejador decideix si una instància rep trànsit i ha de ser ràpida i superficial; la de disponibilitat mesura si el servei està sa de debò. Un /salud que només retorna 200 OK sense comprovar res donarà verd amb la base de dades caiguda. L'endpoint hauria de verificar almenys la connectivitat amb Cloud SQL, amb un timeout curt per no convertir-se ell mateix en un problema.
• --content-matchers-content comprova que la resposta conté el que s'espera, no només que el codi és 200. Un servidor que retorna una pàgina d'error amb codi 200 —més comú del que sembla— es detecta així.
• Quatre regions repartides distingeixen un problema global d'un de regional. Si només falla la comprovació des d'Àsia, el problema és de xarxa o de DNS, no de l'aplicació.
• Període d'1 minut és l'equilibri raonable entre detecció ràpida i cost.

I l'alerta associada, amb un detall deliberat:

La condició exigeix fallada des de dues regions o més. Una fallada des d'una sola regió sol ser un problema de la xarxa intermèdia, no de la botiga, i alertar-ne genera exactament el soroll de l'apartat 11. Exigir dues regions converteix aquesta en l'alerta més fiable de tot el sistema: si la botiga no respon des de dos continents, la botiga està caiguda. És l'única alerta d'AlpinaShop que va directa a SMS sense passar per Slack.

Quan el catàleg Flask llança una excepció no capturada, el rastreig de pila acaba als registres. Amb milers de peticions al dia, trobar als registres que hi ha un error nou és buscar una agulla en un paller.

Error Reporting resol exactament això: recull les excepcions, les agrupa per la seva signatura —el tipus d'excepció i la pila, no el missatge literal— i presenta una llista de problemes diferents amb la seva freqüència, la seva primera aparició i la seva última.

La diferència pràctica: en lloc de 4.000 línies de registre, veus "KeyError: 'talla' a catalogo/carrito.py:87, 340 ocurrències, primera vegada fa 2 hores, afecta 89 usuaris". I aquell "primera vegada fa 2 hores" és or pur, perquè sol coincidir amb un desplegament.

Instrumentar Flask és senzill:

El paràmetre version és més important del que sembla: en passar el SHA de la imatge desplegada, Error Reporting sap en quina versió va aparèixer cada error. Això connecta directament amb 06-01 i converteix una pregunta difícil —"aquest error és nou?"— en una dada. Amb aquella informació, Error Reporting notifica les regressions: avisa quan apareix un tipus d'error que no existia, i quan reapareix un que s'havia marcat com a resolt.

Un consell important sobre el disseny de les excepcions: Error Reporting agrupa per la signatura de la pila, així que un error genèric repetit en vint llocs diferents s'agrupa malament. Excepcions específiques i missatges amb context —però sense dades personals— fan que l'agrupació sigui útil.

Hi ha una llacuna a les mètriques de plataforma que sorprèn tothom la primera vegada: Google no pot veure dins de les teves màquines virtuals. Sap la CPU, la xarxa i les operacions de disc, perquè això ho mesura l'hipervisor. No sap la memòria utilitzada, l'espai lliure al disc ni els processos que corren, perquè això només es veu des de dins del sistema operatiu.

L'agent d'operacions (Ops Agent) és un únic agent que recull mètriques del sistema i envia registres des de les VM. Substitueix els antics agents separats de Stackdriver de monitoratge i de logging.

Instal·lar-lo a les plantilles del MIG alpinashop-web-mig, mitjançant l'startup script de 02-01:

I la seva configuració, a /etc/google-cloud-ops-agent/config.yaml:

El que apareix a Cloud Monitoring un cop instal·lat:

La memòria mereix èmfasi: una fuita de memòria a l'aplicació acaba amb el sistema matant el procés. Des de fora es veu com a reinicis aleatoris i peticions perdudes, sense cap mètrica que ho expliqui. Sense l'agent, aquell diagnòstic és pràcticament impossible.

I una nota de futur: quan AlpinaShop mogui el catàleg a Cloud Run (DA-001, 07-02), l'agent deixa de caldre perquè la plataforma exposa aquelles mètriques per si mateixa. És un avantatge real dels serveis gestionats que rarament s'esmenta.

És fàcil que la factura d'observabilitat creixi sense que ningú se n'adoni. Convé conèixer el model —sempre amb els preus vigents de la documentació oficial—:

Que els taulers, les alertes i les mètriques de plataforma siguin gratuïts és la millor notícia d'aquesta lliçó: tot el que s'ha construït als apartats 4 a 11 no afegeix cost. El que es paga és el que tu ingereixes: mètriques personalitzades i, sobretot, registres.

Els cinc consells perquè no es dispari:

1. Vigila la cardinalitat de les mètriques personalitzades. És el parany número u: un identificador de client com a etiqueta multiplica el cost per milers.
2. No inventis mètriques que ja existeixen. Abans d'instrumentar, comprova si GCP ja l'emet. Moltes mètriques personalitzades dupliquen mètriques gratuïtes.
3. Exclou el soroll dels registres. Els sondejos de salut i els assets estàtics generen un volum enorme sense valor de diagnòstic. Els filtres d'exclusió són el tema de 06-06.
4. Ajusta la retenció. No tots els registres necessiten guardar-se 30 dies; alguns, amb 7 n'hi ha prou, i el que cal conservar molt de temps surt més barat exportat a Cloud Storage.
5. Posa una alerta de pressupost sobre el propi cost d'observabilitat, amb el que s'ha après a 01-04. És irònic i és exactament el correcte.

I la perspectiva que cal mantenir: l'observabilitat és cara comparada amb res i barata comparada amb un incident. Vint minuts de botiga caiguda en campanya costen més que un mes de registres. La decisió no és "quant gastar en observabilitat", sinó "què necessito veure per no estar cec, i què estic pagant per veure que ningú no mira mai".

Utilitzar la mitjana per a la latència. L'error conceptual més estès. La mitjana oculta exactament el problema que busques. Percentils sempre: p50 per al que és típic, p95 i p99 per al que és dolent.

Promitjar percentils entre instàncies. La mitjana dels p95 no és el p95 del conjunt. És un nombre sense significat. Configura l'alineador i l'agregació correctament.

Alertar sobre causes en lloc de símptomes. Una alerta de CPU al 80 % produeix falsos positius i falsos negatius. Alerta quan els clients pateixen; investiga la causa després amb el tauler.

Alertes sense durada. Qualsevol pic dispara, l'equip aprèn a ignorar-les i el sistema d'alertes mor. Cap alerta sense finestra de temps.

Llindars absoluts en lloc de proporcions. "200 errors" no significa res sense saber quantes peticions hi va haver. Alerta sobre percentatges.

Etiquetes d'alta cardinalitat en mètriques personalitzades. Identificador de client o de comanda com a etiqueta: cost disparat i mètrica inútil. Això va als registres.

Crear trenta alertes el primer dia. La fatiga apareix ràpid i és difícil de revertir. Comença amb tres, viu-hi un mes, i afegeix només quan un incident real demostri que en faltava una.

Alertes sense documentació. Arriba al mòbil a les onze de la nit i qui la rep no sap què mirar. El camp documentation amb els quatre primers passos és obligatori.

Oblidar l'agent d'operacions a les VM. Sense ell no hi ha mètriques de memòria ni de disc, i aquelles són les causes de les fallades més difícils de diagnosticar.

Un endpoint /salud que no comprova res. Retornar 200 OK sense verificar dependències fa que la comprovació sigui verda amb la base de dades caiguda. Que comprovi l'essencial, amb timeout curt.

Taulers construïts a clics i mai exportats. Es perden, no es repliquen i ningú no sap qui els va canviar. Exporta el JSON a Git.

Consell final: el millor moment per muntar l'observabilitat és abans de l'incident. Durant un incident, amb la botiga caiguda i el telèfon sonant, ningú no té temps de construir un tauler. I l'observabilitat no es jutja per com de bonica és en un dia normal, sinó per com de ràpid et porta a la causa el pitjor dia de l'any.

AlpinaShop vol alertar sobre les connexions a alpinashop-pedidos. Les dades històriques de les últimes 4 setmanes: mediana 45 connexions, p95 120, màxim observat 180 durant una campanya de cap de setmana que va funcionar correctament, i el límit configurat de la instància és 250. Dissenya la política d'alerta completa —mètrica, llindar, durada, canal i documentació— justificant cada nombre, i explica què passaria amb un llindar de 100 i amb un de 240.

La Lucía observa que l'informe de vendes de l'última setmana mostra 40 comandes menys de l'esperat els dimarts al matí, de manera consistent. Cap alerta no ha saltat, el tauler és verd i la comprovació de disponibilitat no ha fallat mai. Proposa quines mètriques miraries, en quin ordre, i quina instrumentació nova afegiries perquè aquest tipus de problema es detecti automàticament en el futur.

Una empresa semblant a AlpinaShop té 34 alertes configurades. L'últim mes van saltar 280 vegades; d'aquelles, 11 van correspondre a incidents reals. L'equip ha silenciat el canal de Slack i revisa les alertes "quan pot". Diagnostica el problema, proposa un mètode concret per reduir el nombre d'alertes i defineix el conjunt mínim amb què arrencaries de nou, explicant quin tipus de fallada detecta cadascuna.

Solució 1

La política:

Per què 200. És el 80 % del límit dur de 250. Deixa marge per actuar abans que la instància comenci a rebutjar connexions, i està molt per damunt del màxim històric observat en operació normal (180), així que no salta per l'ús legítim més extrem conegut. La regla general: alertar en un percentatge del límit, no en un múltiple de la mediana, perquè el que fa mal és esgotar el recurs.

Amb un llindar de 100: saltaria constantment. El p95 històric és 120, és a dir, el 5 % del temps se superen 120 connexions en operació completament normal. Una alerta a 100 saltaria diverses vegades al dia sense que res estigui malament. És el camí directe a la fatiga de l'apartat 11 i que se silenciï el canal.

Amb un llindar de 240: arribaria massa tard. A 240 de 250 queden deu connexions de marge; amb la velocitat a què creix aquest comptador durant un pic, el temps entre l'alerta i l'esgotament es mesura en segons. La Marta rebria la notificació alhora que els primers errors de connexió dels clients, i l'alerta hauria deixat de ser preventiva per ser un avís que ja és tard.

Documentació associada, que és la meitat del valor:

I una recomanació addicional que millora bastant el disseny: afegir una segona condició sobre la tendència, no només el nivell. Un salt de 45 a 190 connexions en cinc minuts és un senyal de fuita moltíssim més fiable que el valor absolut, i avisaria abans. La majoria de les fuites de connexions es manifesten com una rampa que puja i mai no baixa, i això és detectable molt abans d'arribar al 80 % del límit.

Solució 2

El primer és reconèixer quin tipus de problema és: una fallada parcial i silenciosa. No hi ha caiguda, no hi ha errors massius, no hi ha lentitud generalitzada. Alguna cosa falla per a un subconjunt d'usuaris o d'operacions, i tots els indicadors agregats ho dilueixen. Són les fallades més cares perquè duren setmanes.

Mètriques a mirar, en aquest ordre:

La hipòtesi principal, i per què. La regularitat —dimarts al matí, sistemàticament— apunta amb força a alguna cosa programada que s'executa els dimarts: una còpia de seguretat, un procés de reindexació, un informe pesat sobre alpinashop_analitica, una tasca de manteniment. Aquell procés competeix per recursos amb la botiga: satura la CPU de Cloud SQL, ocupa connexions o bloqueja taules, i durant aquella estona una fracció dels intents de compra falla o s'abandona per lentitud.

El pas 1 és especialment informatiu i mereix detallar-se: si el trànsit és normal però les comandes cauen, el problema és a l'embut de compra; si el trànsit també cau, el problema és d'accés —DNS, CDN, una campanya de màrqueting que no va sortir—. Són diagnòstics completament diferents i aquella única comparació els separa.

Instrumentació nova a afegir, que és l'objectiu real de l'exercici:

La mètrica d'embut és la clau de l'exercici. Amb comptadors per etapa, la pregunta "on es perden les comandes?" té resposta immediata: si les vistes de producte són normals, les cistelles són normals i els pagaments confirmats cauen, el problema és a la passarel·la o al pas final. Sense ella, cal reconstruir-ho a mà des dels registres cada vegada.

I l'alerta correcta no és de llindar fix, sinó comparativa. "Menys de X comandes per hora" és inservible perquè el volum varia enormement entre les 4 de la matinada i les 8 del vespre, i entre un dimarts de juliol i un dissabte de campanya. El que funciona és comparar amb la mateixa franja horària de la setmana anterior i alertar davant d'una desviació superior al 30 %. Aquella comparació absorbeix l'estacionalitat diària i setmanal.

I la lliçó de fons: tots els indicadors tècnics estaven verds mentre es perdien 40 comandes setmanals. L'observabilitat tècnica no substitueix l'observabilitat de negoci. La mètrica més important d'una botiga és quantes comandes entren, i cap mètrica de plataforma no la coneix. Aquest cas és el millor argument possible a favor de les mètriques personalitzades de l'apartat 12.

Solució 3

Diagnòstic numèric, que és demolidor. 280 alertes per a 11 incidents reals significa una precisió del 3,9 %: 96 de cada 100 alertes són soroll. Amb aquella proporció, silenciar el canal és la decisió racional, i l'equip no ha fet res retretable. El sistema d'alertes està trencat, no les persones.

El cost real no són les 280 interrupcions: és que els 11 incidents reals van quedar enterrats. Un sistema amb aquella precisió no només és inútil, és pitjor que no tenir alertes, perquè genera la il·lusió d'estar vigilat.

Les causes gairebé segures, deduïbles del patró:

Mètode concret de reducció, en cinc passos:

Pas 1, mesurar cada alerta. Per a cadascuna de les 34: quantes vegades va saltar, quantes van correspondre a un incident real i quina acció va provocar. És un exercici d'una tarda amb les dades de Cloud Monitoring.

Pas 2, aplicar la pregunta de les 3 de la matinada. Per a cada alerta: si això salta de matinada, hi ha alguna cosa que algú hagi de fer immediatament? Totes les que responguin "no" es retiren. La meva aposta: de 34 en cauen unes 20.

Pas 3, classificar les supervivents.

Pas 4, recalibrar amb dades. Per a cada supervivent, mirar el valor real de les últimes quatre setmanes i posar el llindar per damunt del p99 històric o en un percentatge del límit dur, amb durada mínima de 5 minuts.

Pas 5, començar de zero amb el conjunt mínim. I aquí ve la part que costa acceptar: és preferible desactivar les 34 i arrencar amb 4 que intentar arreglar les 34. Un sistema d'alertes ja desacreditat no recupera la confiança retocant-lo; cal refundar-lo.

El conjunt mínim amb què arrencar, cadascuna detectant una classe diferent de fallada:

Quatre alertes. I el criteri per afegir la cinquena és estricte i molt útil: només s'afegeix una alerta quan un incident real ha ocorregut i cap de les existents no l'ha detectat. Cada alerta nova s'ha de justificar amb un incident concret, no amb un "per si de cas". Així el sistema creix guiat per la realitat, i cada alerta que existeix té una història que la sosté.

Tancament de l'exercici, amb la lliçó que se n'endú un: un sistema d'alertes es jutja per la seva precisió, no per la seva cobertura. Quatre alertes amb un 80 % de precisió valen infinitament més que trenta-quatre amb un 4 %, perquè les primeres s'atenen i les segones se silencien. I una alerta silenciada no protegeix res.

AlpinaShop ja no s'assabenta dels seus problemes per correu electrònic d'un client.

Saps què és l'observabilitat —entendre què li passa per dins a un sistema des del que emet cap a fora, incloses les fallades que no vas anticipar— i els seus tres pilars, amb el seu perfil diferent: mètriques barates i agregades per a tendències i alertes, registres amb detall per a casos concrets, traces per saber on se'n va anar el temps. I saps que Stackdriver és només un nom històric.

Domines el model de dades: una sèrie temporal és tipus de mètrica + recurs monitorat + etiquetes, amb la conseqüència que les etiquetes multipliquen sèries i produeixen explosió de cardinalitat. Distingeixes mesurador, comptador i distribució, amb les implicacions pràctiques: un comptador cal derivar-lo amb rate o no significa res, i una distribució conserva l'histograma complet per poder demanar percentils a posteriori.

Tens els tres projectes en un sol espai de mètriques, amb l'advertiment que unifica la vista però no els permisos. Coneixes les mètriques de plataforma gratuïtes que porten mesos acumulant-se sense que ningú les miri, i la taula que de debò s'utilitza en un incident: del símptoma a la mètrica.

Saps explorar amb alineadors i agregacions en l'ordre correcte, i sobretot per què la mitjana menteix: 495 ms de mitjana mentre 50 clients per minut esperen vuit segons. Percentils sempre, mai promitjar percentils entre sèries, i el p99 importa més del que el seu nom suggereix perquè sol tocar als millors clients.

Tens el tauler de la campanya de tardor construït per explicar una història de dalt a baix —primer si pateixen els clients, després per què— amb la CPU del MIG mostrada en mitjana i màxim perquè la mitjana oculta la instància calenta. I el tens com a JSON versionable a Git, llest per passar a Terraform a 06-07. Coneixes MQL per al que els filtres no expressen —la taxa d'error com a proporció— i PromQL com a aposta més portable si vius a Kubernetes.

Saps muntar una política d'alerta amb les seves quatre peces, amb la durada com a peça infravalorada i el camp documentation com el que separa una alerta útil d'una que genera ansietat. Tens les tres alertes d'AlpinaShop, cadascuna amb el seu llindar raonat i cadascuna detectant un tipus diferent de fallada: error visible, degradació visible i fallada invisible des de fora. I has tingut la conversa incòmoda sobre la fatiga d'alertes, amb la pregunta de control que val per tot l'apartat: si això salta a les 3 de la matinada, hi ha alguna cosa a fer immediatament? Si no, és un gràfic, no una alerta.

Saps emetre mètriques personalitzades de negoci —les comandes per minut que cap mètrica de GCP no coneix— amb la regla d'or sobre les etiquetes: desenes de valors, mai milers, i el que és d'alta cardinalitat va als registres. Tens comprovacions de disponibilitat des de quatre continents que detecten el que cap mètrica interna no veu, amb la condició de dues regions que les converteix en l'alerta més fiable del sistema. Tens Error Reporting agrupant excepcions de Flask per signatura i notificant regressions, amb el version que enllaça cada error amb el desplegament que el va introduir. I tens l'agent d'operacions a les VM del MIG, sense el qual no hi ha mètriques de memòria ni de disc i els reinicis inexplicables es queden inexplicables.

I coneixes el cost: taulers, alertes i mètriques de plataforma són gratuïts; el que es paga és el que tu ingereixes, amb la cardinalitat i el volum de registres com els dos paranys. Amb la perspectiva correcta: l'observabilitat és cara comparada amb res i barata comparada amb vint minuts de botiga caiguda en campanya.

Però fixa't en el que les mètriques no poden fer. Quan l'alerta d'errors 5xx salta a les onze de la nit, et diu que el 4 % de les peticions fallen. No et diu què falla. No et diu a quin client li va passar, ni amb quin producte, ni en quina línia de codi. I quan la latència p99 es dispara, la mètrica et diu que alguna cosa triga tres segons, però no qui triga: l'aplicació, la base de dades, la crida a la Vision API, la xarxa?

Per a això calen els altres dos pilars. A 06-06 arriben Cloud Logging i Cloud Trace: els registres que responen què va passar exactament en aquest cas, i les traces que responen on se'n va anar el temps. I amb ells, el recorregut complet d'un incident d'AlpinaShop des de l'alerta fins a la línia de codi.

Abans, però, hi ha un deute pendent que ja no es pot ajornar. Tota aquesta infraestructura —la VPC, el balancejador, el clúster, les alertes que acabes de crear— continua existint únicament perquè algú va executar les comandes correctes en l'ordre correcte, i aquell algú va ser la Marta, i el registre del que va fer és a l'historial del seu terminal. A 06-05 s'ataca aquell problema de front.