A 06-04 vas muntar el primer pilar de l'observabilitat. AlpinaShop té ara un tauler, comprovacions de disponibilitat des de quatre continents i tres alertes que arriben al mòbil de la Marta. És un salt enorme respecte a esperar el correu d'un client.

Però fixa't en què passa quan aquesta alerta salta de veritat. Són les onze de la nit i el mòbil de la Marta mostra: «Taxa d'error 5xx per sobre del 2 % durant 5 minuts». La Marta obre el tauler. Ho confirma: el 4,3 % de les peticions fallen, la latència p95 ha pujat de 400 ms a 3,2 segons, i va començar fa uns vint minuts. I ara, què?

La mètrica li ha dit que alguna cosa va malament. No li diu què. No li diu quina excepció s'està llançant, ni a quins clients els passa, ni si és al catàleg o al carret, ni si el culpable és l'aplicació, la base de dades o una crida a una API externa. Per a això calen els altres dos pilars.

Aquesta lliçó els construeix. I acaba amb el recorregut complet d'aquest incident, des de l'alerta fins a la línia de codi exacta, perquè aquesta correlació —saltar de l'alerta a la mètrica, de la mètrica al registre i del registre a la traça— és la raó per la qual existeix l'observabilitat.

1. L'entrada de registre estructurada
2. D'on surten els registres automàticament
3. Emetre registres bé des de l'aplicació Flask
4. L'explorador de registres i el seu llenguatge de consultes
5. Consultes que resolen incidents reals d'AlpinaShop
6. Buckets, retenció, vistes i àmbits
7. Sortidors: exportar a BigQuery, Cloud Storage i Pub/Sub
8. Filtres d'exclusió: no pagar per soroll
9. Mètriques basades en registres
10. Cloud Trace: què és el rastreig distribuït
11. Instrumentar Flask amb OpenTelemetry
12. Llegir una cascada i trobar la consulta lenta
13. Mostreig i cost de les traces
14. Cloud Profiler: perfilatge continu
15. La correlació que ho uneix tot: un incident de principi a fi
16. Cost per volum i les tres decisions que el controlen

Un registre no és una línia de text. A Cloud Logging, una entrada de registre és un objecte amb camps, i entendre aquests camps és el que converteix els registres d'un abocador en una base de dades consultable.

La diferència entre textPayload i jsonPayload és la diferència entre poder investigar i no poder.

Sense estructura:

És llegible per a un humà i opac per a una màquina. Per respondre a «quantes comandes van fallar per timeout de la passarel·la l'última hora, i de quin import?» cal analitzar text amb expressions regulars, i n'hi ha prou que algú canviï el missatge perquè tot es trenqui.

Amb estructura:

Ara aquesta pregunta és un filtre. I la penúltima línia permet una cosa encara més potent: saltar directament a la traça completa d'aquesta petició, amb tot el que va passar abans i després. Hi tornarem.

Igual que amb les mètriques, hi ha una bona notícia: bona part dels registres ja s'estan recollint sense que hagis fet res.

Dues caselles mereixen atenció.

Els registres del balancejador no estan activats per defecte, i són dels més valuosos que existeixen: contenen cada petició a la botiga amb la seva latència, el seu codi, el seu país d'origen i el resultat de la memòria cau de CDN. Activar-los:

El --logging-sample-rate=1.0 registra el 100 % de les peticions. És el correcte mentre el volum sigui moderat; amb milions de peticions diàries es baixa a 0,1 o 0,05 i s'accepta perdre detall a canvi de cost. Comença per 1.0 i ajusta quan vegis la factura.

Els VPC Flow Logs registren les connexions de xarxa i són imprescindibles per diagnosticar problemes de connectivitat i per investigar incidents de seguretat. El seu volum és alt, així que s'activen amb mostreig:

I els registres d'auditoria mereixen una menció amb remissió: els d'activitat d'administració —qui va crear, modificar o esborrar un recurs— estan sempre actius i són gratuïts. Els d'accés a dades —qui va llegir què— cal activar-los, generen un volum enorme i es paguen. La política d'auditoria a nivell d'organització, amb les seves implicacions de compliment, és tema de 07-07; aquí n'hi ha prou de saber que existeixen i que responen a la pregunta «qui va esborrar aquest recurs?».

Aquí és on l'equip d'AlpinaShop té més marge de millora. El catàleg avui fa això:

Funciona en el sentit que el text acaba a Cloud Logging —a GKE, tot el que va a stdout es recull—. Però produeix entrades amb textPayload, totes amb severitat INFO encara que siguin errors, sense cap camp consultable i sense identificador de traça.

La forma correcta, amb la biblioteca client:

I el seu ús, amb els camps com a dades i no com a text:

Les cinc regles d'un registre útil, que valen més que qualsevol biblioteca:

La tercera regla no és negociable i va més enllà del bon gust. Els registres es retenen, s'exporten a BigQuery, els llegeixen diverses persones i sobreviuen mesos. Un correu electrònic o un número de targeta escrit en un registre és una fuita de dades personals amb implicacions de RGPD, coherent amb tot el que s'ha vist a 04-07 sobre DLP. Si necessites identificar un client als registres, fes servir un hash estable que permeti correlacionar sense identificar.

Sobre la severitat, un criteri pràctic que evita discussions eternes:

La distinció entre WARNING i ERROR és la que es fa malament més sovint: un reintent que després funciona és WARNING —l'usuari no se'n va assabentar—; un reintent esgotat que retorna un error al client és ERROR.

L'explorador de registres és la interfície de consulta, i el seu llenguatge és senzill però té detalls que convé conèixer.

Els operadors bàsics:

Tres consells de rendiment que canvien molt l'experiència, perquè una consulta mal escrita sobre setmanes de registres triga minuts:

1. Acota sempre el temps primer. És el filtre més eficient amb diferència.
2. Filtra per resource.type aviat. Redueix l'espai de cerca de cop.
3. Evita la cerca global de text lliure si pots filtrar per un camp concret: cercar a jsonPayload.causa és ordres de magnitud més ràpid que cercar la paraula en tot el contingut.

Des de la línia de comandes, per a guions i per automatitzar:

La teoria és curta; l'útil són els patrons. Aquestes cinc consultes cobreixen la majoria de les investigacions reals.

Consulta 1 — Els errors 500 des de l'últim desplegament. La primera pregunta davant de qualsevol incident:

I refinada, per veure si el problema és d'una versió concreta —el que enllaça amb el $COMMIT_SHA de 06-01—:

Consulta 2 — Aïllar la petició d'un client que s'ha queixat. Un client escriu dient que la seva compra va fallar a les 20:34:

Aquí es veu el valor de la regla de les dades personals: el hash permet trobar el client sense haver escrit mai el seu correu en un registre. Atenció al client converteix el correu en hash amb la mateixa funció, i la investigació funciona igual.

Consulta 3 — Qui va esborrar un recurs. Els registres d'auditoria, que responen a la pregunta més incòmoda:

La resposta inclou protoPayload.authenticationInfo.principalEmail —qui— i protoPayload.resourceName —què—. És la consulta que resol en trenta segons discussions que d'una altra manera duren una tarda.

Consulta 4 — Peticions lentes del balancejador amb el seu origen. Sobre el registre d'accés de l'apartat 2:

I el mateix registre respon una pregunta de cost de 03-03, la ràtio d'encerts de la CDN:

Consulta 5 — Errors de la funció d'imatges. Tancant el cercle amb 06-03:

I la que hauria detectat el bucle infinit de l'exercici d'aquella lliçó, comptant invocacions per hora:

Els registres s'emmagatzemen en buckets de registres, que no tenen res a veure amb els de Cloud Storage.

Tot projecte en té dos per defecte:

I es poden crear buckets propis, que és el que cal quan diferents tipus de registre necessiten un tractament diferent:

Triar la retenció té dues dimensions que convé separar:

Guardar anys de registres en un bucket de registres és la forma més cara de conservar-los. Per a retenció llarga, el patró correcte és exportar a Cloud Storage amb classe d'emmagatzematge freda, que és el tema de l'apartat següent.

Les vistes de registre (log views) permeten donar accés a un subconjunt d'un bucket. És la peça que resol un problema real de permisos: donar a la Lucía accés als registres de l'aplicació sense exposar-li els registres d'auditoria ni els de pagaments.

Sense vistes, el permís de lectura de registres és tot o res, i «tot» inclou els registres d'auditoria. Amb vistes, l'accés s'acota, coherent amb el mínim privilegi de 03-04.

Un sortidor (sink) és una regla que diu: «les entrades que compleixin aquest filtre, envia-les també a aquest destí». És el mecanisme que connecta els registres amb la resta de la plataforma.

A BigQuery, per analitzar. El cas d'AlpinaShop: analitzar el registre d'accés del balancejador amb SQL, creuant-lo amb les dades d'alpinashop_analitica:

El pas del writerIdentity s'oblida constantment: el sortidor es crea, sembla funcionar, i no arriba res al destí perquè falta el permís. És el primer lloc on mirar si un sortidor no lliura.

El --use-partitioned-tables és important per cost: particiona per data, així que una consulta sobre un dia no escaneja mesos, aplicant el que s'ha après a 04-01.

I aleshores es poden fer anàlisis que amb l'explorador serien impossibles:

A Cloud Storage, per arxivar barat. El destí de la retenció llarga:

Amb una regla de cicle de vida al bucket (02-02) que baixi a Nearline als 30 dies, a Coldline als 90 i a Archive a l'any, set anys de registres de pagaments costen una fracció minúscula del que costarien en un bucket de registres.

A Pub/Sub, per reaccionar. El sortidor més interessant conceptualment, perquè tanca el cercle amb 06-03:

Cada vegada que algú toca una regla de tallafoc o una política d'IAM, arriba un missatge al topic, i una Cloud Function de 06-03 pot publicar-ho al canal de seguretat de Slack. D'un registre a una reacció automàtica, sense intervenció humana.

Un sortidor copia; un filtre d'exclusió descarta. I és la palanca més directa sobre la factura de logging.

El raonament és senzill: hi ha registres que es generen en volum enorme i no aporten res al diagnòstic. A AlpinaShop, els principals són les comprovacions d'estat —hc-catalogo colpeja /salud cada pocs segons des de diverses sondes, generant desenes de milers d'entrades idèntiques al dia— i les peticions a recursos estàtics que serveix la CDN.

El paràmetre percent=95 és molt útil i poc conegut: exclou una mostra aleatòria en lloc de tot. Conservar el 5 % permet continuar veient tendències i detectar problemes amb els estàtics, pagant-ne la vintena part.

I l'advertiment imprescindible: una entrada exclosa no es desa enlloc i no es pot recuperar. Si exclous alguna cosa que després resulta necessària per investigar un incident, no hi ha marxa enrere. Revisa cada exclusió amb la pregunta: podria necessitar això durant una investigació? Davant del dubte, mostreja en lloc d'excloure del tot.

Aquí es tanca el vincle amb 06-04. Una mètrica basada en registres converteix entrades que compleixen un filtre en una mètrica de Cloud Monitoring, sense tocar el codi de l'aplicació.

És la tècnica més ràpida per instrumentar alguna cosa que ja s'està registrant.

Mètrica de comptador, per comptar ocurrències:

Amb etiquetes per poder desglossar, definida des d'un fitxer:

Fixa't en l'etiqueta version: permet respondre immediatament a «aquestes fallades van començar amb el desplegament d'ahir?», correlacionant amb el SHA de 06-01. I respecta la regla de cardinalitat de 06-04: canal té tres valors, version unes desenes. Mai extreguis id_pedido com a etiqueta.

Mètrica de distribució, per a valors numèrics:

Això permet pintar el p50 i el p95 de l'import mitjà de comanda, una dada de negoci pura obtinguda sense escriure una línia d'instrumentació específica.

La recomanació pràctica: comença amb mètriques basades en registres per validar ràpid què val la pena mesurar, i promociona a mètriques personalitzades les que resultin importants de veritat. I tingues present el risc: si algú reanomena un camp del jsonPayload, la mètrica deixa de comptar silenciosament i l'alerta associada deixa de saltar. Un canvi en el format d'un registre és un canvi amb conseqüències, i mereix menció en la revisió de codi.

Les mètriques diuen que el p95 és de 3,2 segons. Els registres diuen que hi va haver errors. Cap dels dos diu on van anar aquests 3,2 segons.

Aquest és el buit que omple el rastreig distribuït, i la seva necessitat creix amb el nombre de peces. Una petició al catàleg d'AlpinaShop travessa avui: el balancejador, Cloud Armor, la CDN, el pod de GKE, una consulta a Cloud SQL, una lectura de Firestore per al carret i potser una crida a la Vision API. Si triga tres segons, qui en té la culpa?

Dos conceptes:

• Una traça representa una petició completa a través de tot el sistema, identificada per un trace_id.
• Un tram (span) representa una operació dins d'aquesta traça, amb inici, fi i un tram pare. Els trams formen un arbre.

Amb només mirar el diagrama, la resposta salta a la vista: SELECT stock_por_talla triga 3.020 dels 3.240 ms. Cap mètrica i cap registre haurien assenyalat això amb aquesta claredat.

La propagació del context és el que permet que els trams de serveis diferents formin una sola traça. El servei que inicia la petició genera un trace_id i l'envia en una capçalera; cada servei que la rep la llegeix, crea els seus trams com a fills i la propaga al seu torn.

El balancejador de GCP afegeix X-Cloud-Trace-Context automàticament a cada petició entrant, així que AlpinaShop ja té identificadors de traça circulant sense haver fet res. El que falta és que l'aplicació els faci servir.

OpenTelemetry és l'estàndard del sector per a instrumentació —mètriques, traces i registres—, independent del proveïdor. Instrumentar amb OpenTelemetry i exportar a Cloud Trace significa que, si demà AlpinaShop canvia de destí, es canvia l'exportador i no la instrumentació.

Amb aquestes tres últimes línies ja tens traces útils sense modificar cap funció de negoci. Per al detall propi, trams manuals:

I la peça que ho canvia tot: incloure el trace_id als registres. És el que permetrà el recorregut de l'apartat 15:

Aquestes claus especials logging.googleapis.com/trace i .../spanId no són camps qualssevol: Cloud Logging les reconeix i emplena els camps trace i spanId de l'entrada. I amb això, la consola mostra un enllaç directe de cada registre a la seva traça, i de cada traça als seus registres.

Amb la instrumentació posada, així es llegeix una traça lenta del catàleg d'AlpinaShop:

El diagnòstic és immediat, i les tres coses que cal mirar en qualsevol cascada són sempre les mateixes:

1. Quin tram ocupa el percentatge més gran? Aquí, stock_por_talla amb el 93 %. Optimitzar qualsevol altra cosa és perdre el temps.
2. Hi ha buits sense cobrir? Un interval dins del tram pare que cap fill no explica sol ser temps d'espera: bloquejos, contenció de pool de connexions o codi no instrumentat.
3. Hi ha trams repetits? Cinquanta trams SELECT idèntics consecutius són la signatura inconfusible del problema N+1: una consulta per cada element d'una llista, en lloc d'una consulta per a tots.

Amb l'atribut SQL que afegeix la instrumentació de SQLAlchemy, la traça inclou la consulta:

I a partir d'aquí, la investigació és de base de dades: EXPLAIN ANALYZE sobre aquesta consulta, revisar índexs, mirar els registres de consultes lentes de Cloud SQL. La traça no arregla el problema; el localitza en trenta segons en lloc de en tres hores, i això és exactament el que se li demana.

Un patró que mereix menció a part: si aquesta mateixa consulta triga 40 ms en un entorn de proves i 3.020 ms en producció, el problema probablement no és la consulta sinó la contenció —el pool de connexions esgotat, amb la petició esperant que se'n alliberi una—. Allà la mètrica de connexions de Cloud SQL de 06-04 i la traça es reforcen mútuament: la traça diu on s'espera, la mètrica diu per què.

Traçar el 100 % de les peticions té dos costos: el d'ingesta de trams, que es factura, i el de rendiment a l'aplicació, que encara que petit no és nul. Per això es mostreja.

La combinació ParentBased(TraceIdRatioBased(0.1)) de l'apartat 11 és la correcta per defecte, i mereix explicació: TraceIdRatioBased(0.1) mostreja el 10 % de les traces noves, i ParentBased garanteix que si una traça es va mostrejar al principi, tots els serveis que la reben també la mostregen. Sense ParentBased, cada servei decidiria pel seu compte i obtindries traces incompletes amb forats, que són pitjors que no tenir traces.

El mostreig basat en la cua és el que tothom voldria —guardar el 100 % de les traces lentes o amb error, i l'1 % de les normals— perquè les traces interessants són precisament les anòmales. Requereix un col·lector d'OpenTelemetry que retingui els trams fins al final de la petició per decidir. Per a AlpinaShop avui és complexitat excessiva; convé saber que existeix per quan el sistema creixi.

Recomanació per entorn:

Que la proporció sigui una variable d'entorn (TRACE_SAMPLE_RATE) és deliberat: permet pujar-la al 100 % durant una investigació sense redesplegar codi, i baixar-la després.

Una traça diu que una funció triga 800 ms. No diu què fa durant aquests 800 ms. Per a això hi ha el perfilatge.

Cloud Profiler recull contínuament mostres de CPU i memòria de l'aplicació en producció, amb una sobrecàrrega molt baixa —de l'ordre d'un percentatge petit—, i mostra un gràfic de flames amb on es consumeix el temps i la memòria.

Els tres casos on Profiler resol el que cap altre pilar no pot:

El tercer mereix un advertiment: la intuïció sobre on és el coll d'ampolla sol ser errònia. És habitual passar dos dies optimitzant una funció que consumeix el 3 % del temps total mentre el 60 % se l'endú una serialització JSON que ningú no va mirar. Profiler evita aquest malbaratament amb dades en lloc de conjectures.

I la comparació per versió és on brilla: amb service_version fixat al SHA de la imatge, es pot comparar el perfil de dues versions i veure exactament què va introduir una regressió de rendiment.

Aquest apartat és la raó de ser de tot el mòdul. Tornem al moment amb què va començar la lliçó.

23:14 — L'alerta. Arriba al mòbil de la Marta. Porta el camp documentation amb els quatre primers passos, així que no comença de zero.

23:15 — El tauler. Ho confirma: 4,3 % d'errors, p95 de 3,2 s davant dels 400 ms habituals, i la CPU del MIG baixa. Aquesta última dada és informativa per si sola: si hi hagués un pic de trànsit, la CPU estaria alta. No ho està, així que el problema no és de capacitat.

23:17 — Els registres. Primera consulta, la de l'apartat 5:

Apareixen unes 800 entrades. La Marta en mira una:

23:19 — El patró. Refina la consulta agrupant per causa i descobreix que el 94 % dels errors tenen causa="timeout_consulta" i tots són de rutes de catàleg. No és una fallada general: és una operació concreta.

23:21 — La traça. I aquí hi ha el salt que justifica tota la instrumentació de l'apartat 11: a la consola, el camp trace d'aquesta entrada de registre és un enllaç. Un clic i apareix la traça completa d'aquesta petició exacta, la del client concret que va patir l'error.

23:23 — La cascada. La traça és la de l'apartat 12: SELECT stock_por_talla consumeix 3.020 de 3.240 ms. Amb la consulta SQL visible als atributs del tram.

23:25 — La causa. La Marta executa la consulta 3 sobre els registres d'auditoria i sobre l'historial de Cloud Build: a les 22:50 es va aplicar una migració de base de dades que, entre altres coses, va eliminar i recrear una taula auxiliar sense tornar a crear l'índex sobre (sku, almacen). Sense aquest índex, la consulta passa d'un accés indexat a un recorregut complet.

23:31 — La mitigació. Es recrea l'índex, i en paral·lel es prepara la marxa enrere de la versió amb el pipeline de 06-01. La latència torna a la normalitat en tres minuts.

Disset minuts des de l'alerta fins a la causa arrel identificada. Sense aquest recorregut, la mateixa investigació hauria estat: assabentar-se'n per un client l'endemà al matí, mirar el web, no reproduir el problema perquè el trànsit nocturn és diferent, revisar registres sense estructura cercant text, sospitar de tres coses equivocades i, amb sort, trobar-ho al final del dia.

La lliçó que cal endur-se: cap peça no serveix sola. Una alerta sense registres només produeix ansietat. Registres sense estructura són un abocador. Traces sense registres correlacionats obliguen a cercar a cegues quina mirar entre milions. El valor és en els enllaços entre les peces, i l'enllaç concret que fa possible tot el recorregut és una línia de codi: incloure el trace_id a cada entrada de registre.

El model és senzill: es paga per GB ingerit, amb un volum gratuït mensual. La retenció dins del període per defecte no es factura a part; ampliar-la, sí. I verifica sempre els preus vigents a la documentació oficial.

Les tres decisions que controlen la factura, per ordre d'impacte:

Decisió 1: què s'ingereix. És la més important amb diferència, perquè afecta tota la resta. Els filtres d'exclusió de l'apartat 8 sobre comprovacions d'estat i estàtics solen retallar entre el 40 % i el 70 % del volum d'un lloc web típic, sense perdre res de valor diagnòstic. I a l'aplicació: DEBUG desactivat en producció i cap registre dins de bucles.

Decisió 2: quant de temps es guarda i on. Trenta dies al bucket de registres per a diagnòstic, i el que hagi de conservar-se més temps, exportat. Un sortidor a Cloud Storage amb cicle de vida a Coldline i Archive fa que set anys de registres de pagaments costin ordres de magnitud menys que ampliar la retenció del bucket.

Decisió 3: quant es mostreja. S'aplica al registre del balancejador (--logging-sample-rate), als VPC Flow Logs (--logging-flow-sampling) i a les traces (TRACE_SAMPLE_RATE). Amb volum alt, el 10 % sol bastar per detectar patrons, perquè l'estadística no necessita el cens complet.

I l'error que cal evitar per damunt de tots: excloure registres d'error per estalviar. Són un percentatge mínim del volum i el 100 % del valor durant un incident. L'estalvi és en el soroll repetitiu, mai en l'excepcional.

Una perspectiva final per calibrar: per a AlpinaShop, l'observabilitat completa —registres, traces, mètriques, alertes— és de l'ordre d'una fracció petita del cost de la infraestructura que observa. Comparat amb els disset minuts de l'apartat 15 davant d'un dia sencer d'investigació a cegues, i amb les comandes que se salven en detectar un incident en cinc minuts en lloc de en dotze hores, és de les inversions més rendibles de la plataforma.

Usar print en lloc de logging estructurat. El text acaba a Cloud Logging, sí, però sense severitat, sense camps consultables i sense trace. És la diferència entre poder investigar i no poder.

Ficar les dades al missatge en lloc de en camps. f"comanda {id} va fallar" obliga a analitzar text. "Comanda fallida" més {"id_pedido": id} permet filtrar i agregar.

Escriure dades personals als registres. Correus, noms, targetes, adreces. Els registres es retenen, s'exporten i els llegeix molta gent. Fes servir hashes estables.

Tot amb severitat INFO. Impedeix filtrar per gravetat i fa inútils les alertes basades en severity>=ERROR. I un reintent que funciona és WARNING, no ERROR.

Oblidar el writerIdentity en crear un sortidor. El sortidor es crea sense error i no lliura res. És el primer lloc on mirar quan un destí és buit.

Excloure registres sense pensar-s'ho dues vegades. L'exclòs no es desa enlloc i no es recupera. Davant del dubte, mostreja amb percent en lloc d'excloure del tot. I no excloguis mai errors ni registres d'auditoria.

Guardar anys de registres en un bucket de registres. És la forma més cara. Per a retenció llarga, sortidor a Cloud Storage amb cicle de vida.

Etiquetes d'alta cardinalitat en mètriques basades en registres. El mateix error de 06-04: EXTRACT(jsonPayload.id_pedido) crea una sèrie temporal per comanda. Extreu dimensions amb desenes de valors, no milers.

Traçar sense ParentBased al mostrejador. Cada servei decideix pel seu compte i obtens traces incompletes amb forats, que confonen més que no ajuden.

No incloure el trace_id als registres. És una línia de codi i és la peça que converteix tres eines independents en un sistema de diagnòstic. Sense ella, saltar del registre a la traça és impossible.

Optimitzar per intuïció en lloc de per perfil. Dos dies millorant una funció que consumeix el 3 % del temps. Mesura primer amb Profiler.

Consell final: la instrumentació es prova abans de l'incident. Provoca un error a propòsit a alpinashop-dev, cerca'n el registre, salta a la seva traça i comprova que el recorregut complet funciona. Descobrir a les onze de la nit que el camp trace és buit és descobrir-ho en el pitjor moment possible.

Aquest és el codi real d'una funció del catàleg d'AlpinaShop:

Reescriu-lo amb logging estructurat corregint tots els problemes que detectis, justifica cada canvi, i escriu la consulta de l'explorador de registres que respongui a «quantes devolucions es van rebutjar per estat incorrecte aquesta setmana, i de quin import mitjà?».

AlpinaShop genera aproximadament: 80 GB/mes de registres del balancejador, 15 GB/mes de registres de l'aplicació, 30 GB/mes de VPC Flow Logs, 2 GB/mes de registres d'auditoria d'administració i 5 GB/mes de registres de Cloud SQL. Requisits: els registres de transaccions de pagament s'han de conservar 7 anys per normativa; l'equip necessita 30 dies per a diagnòstic; la Lucía vol analitzar el registre d'accés amb SQL durant els últims 12 mesos; i cal reduir el cost tant com sigui possible sense perdre capacitat de diagnòstic. Dissenya la configuració completa de buckets, sortidors i exclusions, amb una estimació qualitativa de l'estalvi.

Un client informa que la pàgina d'un producte triga 8 segons. En cercar la traça, la Marta troba: tram arrel GET /catalogo/crampon-02 de 8.100 ms; a dins, consultar_producto de 120 ms i render_plantilla de 90 ms; i res més. Els 7.890 ms restants no estan coberts per cap tram fill. Els registres d'aquesta petició només mostren una entrada INFO al principi. Explica què significa aquest buit, enumera almenys quatre hipòtesis amb el que les distingiria, i detalla quina instrumentació afegiries perquè aquest cas sigui diagnosticable la propera vegada.

Solució 1

Problemes del codi original, set en total:

Versió reescrita:

Justificació dels canvis més importants:

• El hash del correu resol la fuita sense perdre capacitat d'investigació: atenció al client aplica la mateixa funció i troba les entrades.
• WARNING per al rebuig per estat. És una decisió deliberada: el sistema va fer el correcte, no hi ha avaria. Si fos ERROR, l'alerta de 06-04 saltaria per devolucions perfectament normals, alimentant la fatiga de l'apartat 11 d'aquella lliçó.
• El camp resultado amb valors acotats (completada, rechazada, error) permet construir un embut complet amb una sola mètrica basada en registres.
• Excepcions específiques abans que la genèrica. Cadascuna registra la seva causa, la qual cosa permet distingir un problema de la passarel·la d'un error de programació, que requereixen respostes molt diferents.
• raise als errors reals. El codi original retornava False tant si la comanda no era retornable com si la passarel·la estava caiguda, i això fa impossible distingir-los des de fora.
• campos_traza() a totes les entrades. El que permet el salt de l'apartat 15.

Consulta demanada:

Per a l'import mitjà, l'explorador compta però no fa mitjanes bé. Dues opcions. La ràpida, una mètrica de distribució basada en registres sobre jsonPayload.importe_pedido_eur amb aquest filtre, que dona el p50 i la mitjana a Cloud Monitoring. La completa, un sortidor a BigQuery i SQL:

I una observació que va més enllà de l'exercici: aquest desglossament per estado_pedido és informació de producte, no d'infraestructura. Si resulta que la majoria dels rebutjos són de comandes en estat en_transito, la troballa no és tècnica: és que hi ha clients intentant retornar alguna cosa que encara no han rebut, i probablement la interfície no els ho està explicant bé. Un bon logging estructurat acaba responent preguntes de negoci que ningú no havia pensat a fer.

Solució 2

Volum total: 132 GB/mes. El registre del balancejador és el 61 % i els Flow Logs el 23 %: entre tots dos, el 84 %. Aquí hi ha tot el marge.

Pas 1 — Exclusions (la palanca principal):

Volum ingerit resultant: uns 70 GB/mes, prop de la meitat. I sense perdre capacitat de diagnòstic: les comprovacions d'estat ja estan cobertes per les mètriques de 06-04, els estàtics conserven una mostra del 5 % suficient per veure tendències, i el 25 % de Flow Logs continua detectant patrons de connectivitat.

Pas 2 — Buckets amb retenció diferenciada:

La decisió clau, i és contraintuïtiva: el bucket logs-pagos no es configura amb 7 anys de retenció. Guardar set anys en un bucket de registres és l'opció més cara amb diferència. La normativa exigeix conservar, no exigeix que estiguin consultables a l'explorador de registres. Per això:

Pas 3 — Sortidors:

Amb el cicle de vida del bucket d'arxiu: Nearline a 30 dies, Coldline a 90, Archive a 365, esborrat a 2.555 dies (7 anys). I a BigQuery, caducitat de partició a 365 dies per al requisit de la Lucía.

Estimació qualitativa de l'estalvi:

L'estalvi gruixut ve de dos llocs: la meitat del volum ingerit i, sobretot, treure la retenció llarga del servei car al barat, on la diferència de preu per GB-mes entre un bucket de registres i Archive és de dos ordres de magnitud.

I tres advertiments que completen el disseny. Primer: mai excloure errors ni auditoria; són un percentatge mínim del volum i el 100 % del valor. Segon: verificar que el sortidor de pagaments captura tot el que la normativa exigeix abans de reduir la retenció del bucket, perquè si el filtre està malament, el requisit legal s'incompleix en silenci. Tercer: posar una alerta sobre el volum ingerit amb el de 06-04, per assabentar-se si algú introdueix un registre en un bucle abans que arribi la factura.

Solució 3

Què significa el buit. 7.890 ms dels 8.100 no estan coberts per cap tram. I això té un significat molt concret: està passant alguna cosa que la instrumentació no veu. Només hi ha dues famílies d'explicació —codi no instrumentat, o temps d'espera que no és una operació— i distingir-les és tot l'exercici.

És important notar una cosa: els dos trams que sí que existeixen són ràpids. Si el problema fos a la consulta o al renderitzat, es veuria. El temps se'n va en l'espai entre trams, i això és el que cal investigar.

Quatre hipòtesis, amb el que les distingeix:

Quina és la més probable i per què. La hipòtesi 1, i per un raonament que convé explicitar: la instrumentació automàtica d'OpenTelemetry cobreix Flask, requests i SQLAlchemy. Si el codi usa qualsevol altre client —urllib3 directament, un SDK d'un proveïdor de pagaments, un client de Redis, la biblioteca de Firestore— aquestes crides són completament invisibles. I vuit segons amb un patró tan net fa olor de timeout d'una crida externa, molt probablement un configurat en 8 segons exactes.

La hipòtesi 2 és la segona candidata i té una signatura reconeixible: es manifesta sota càrrega i desapareix quan el trànsit baixa. Si el problema només passa en hores punta, és aquesta.

Instrumentació a afegir, per ordre de prioritat:

1. Instrumentar tots els clients sortints. La mesura que resol el cas:

2. Un tram explícit al voltant de cada operació de negoci. La regla general: si una operació pot trigar, embolcalla-la en un tram. És barat i elimina buits per construcció:

El tram obtener_conexion_bd és especialment valuós perquè separa el temps d'espera del temps de treball, que és justament el que confon la hipòtesi 2 amb la 1.

3. Un registre en entrar i en sortir de cada operació llarga, amb duracion_ms. Encara que falti el tram, dues entrades de registre amb marca de temps acoten on se'n va anar el temps.

4. Timeouts explícits i agressius en tot client extern, i registre quan salten:

Aquesta quarta mesura és la més important a llarg termini, i va més enllà del diagnòstic. Sense timeout explícit, la majoria dels clients HTTP esperen indefinidament o el temps per defecte del sistema operatiu, que pot ser molt llarg. Un servei del qual depens i que es degrada arrossega el teu, i vuit segons d'espera és exactament això. Amb timeout curt i degradació elegant, una API de valoracions caiguda produeix una fitxa sense valoracions en 3 segons en lloc d'una pàgina que no carrega en 8.

I la lliçó general de l'exercici: un buit en una traça no és una fallada de la traça, és informació. T'està dient amb precisió que hi ha una part del sistema que no estàs observant. La reacció correcta no és desconfiar de l'eina, sinó preguntar-se què fa el codi en aquest interval que ningú no va instrumentar. En aquest cas, gairebé segur, esperar algú que no contesta.

AlpinaShop té els tres pilars de l'observabilitat complets, i —més important— té els enllaços entre ells.

Saps què és una entrada de registre estructurada i per què la diferència entre textPayload i jsonPayload és la diferència entre poder investigar i no poder. Coneixes tots els seus camps, i saps quin és el decisiu: trace, el que enllaça el registre amb la seva traça.

Saps d'on surten els registres automàticament i quins cal activar explícitament: els del balancejador —dels més valuosos que existeixen, amb la seva latència, el seu país i el seu resultat de CDN— i els VPC Flow Logs. I saps emetre'ls bé des de Flask, amb les cinc regles: les dades van en camps i no al missatge, la severitat ha de ser correcta, mai dades personals, context suficient per actuar i sense soroll. Amb el criteri de severitat que més es falla: un reintent que funciona és WARNING; un d'esgotat, ERROR.

Domines l'explorador de registres i el seu llenguatge —amb el : que és «conté» i no «igual»—, els tres consells de rendiment, i cinc patrons de consulta que resolen incidents reals: els errors des d'un desplegament, la petició d'un client concret localitzada pel seu hash, qui va esborrar un recurs segons els registres d'auditoria, les peticions lentes del balancejador i els errors de la funció d'imatges.

Coneixes els buckets de registres amb _Required i _Default, la retenció amb els seus tres horitzons —diagnòstic, anàlisi i compliment, cadascun al seu lloc— i les vistes que permeten donar accés a un subconjunt sense exposar els registres d'auditoria. Saps crear sortidors a BigQuery per analitzar amb SQL, a Cloud Storage per arxivar barat amb cicle de vida i a Pub/Sub per reaccionar amb una funció de 06-03, amb el writerIdentity que tothom oblida. I saps usar els filtres d'exclusió amb el percent que mostreja en lloc de descartar, amb l'advertiment que l'exclòs no es recupera mai i que els errors i l'auditoria no s'exclouen mai.

Tens les mètriques basades en registres —comptadors i distribucions— que instrumenten sense tocar el codi i alimenten les alertes de 06-04, amb l'etiqueta version que respon a «això va començar amb el desplegament d'ahir?» i la mateixa regla de cardinalitat de sempre.

Saps què és el rastreig distribuït: traça i tram, la propagació del context amb traceparent de W3C i X-Cloud-Trace-Context que el balancejador ja està afegint. Saps instrumentar Flask amb OpenTelemetry —estàndard, no propietari—, amb la instrumentació automàtica de Flask, requests i SQLAlchemy, trams manuals per al detall, i la peça clau: incloure el trace_id a cada registre. Saps llegir una cascada mirant les tres coses que importen —quin tram domina, si hi ha buits i si hi ha trams repetits que delatin un N+1—, i saps mostrejar amb ParentBased(TraceIdRatioBased(...)) per no acabar amb traces incompletes. Coneixes Cloud Profiler i els seus tres casos, amb l'advertiment que la intuïció sobre on és el coll d'ampolla sol fallar.

I tens el recorregut complet de l'apartat 15: de l'alerta a la mètrica, de la mètrica al registre, del registre a la traça i de la traça a la línia de codi, en disset minuts. Amb la lliçó que resumeix tot el mòdul: cap peça no serveix sola; el valor és en els enllaços, i l'enllaç que ho fa possible cap en una línia de codi.

Finalment, coneixes el cost i les tres decisions que el controlen —què s'ingereix, quant es guarda i on, quant es mostreja— amb l'error que mai no s'ha de cometre: estalviar excloent errors, que són el mínim del volum i el màxim del valor.

Mira ara on és AlpinaShop. El codi és a GitHub i es revisa. El pipeline construeix, prova i desplega sol. Les funcions reaccionen a esdeveniments. Hi ha taulers, alertes, comprovacions des de quatre continents, registres estructurats, traces i perfils. Quan alguna cosa falla, se sap en cinc minuts i es diagnostica en vint.

I tanmateix, tota la infraestructura que sosté això —la VPC, el balancejador, el clúster, les alertes que acabes de crear, els sortidors que acabes de configurar— continua existint perquè algú va executar les comandes correctes. A 06-05 vas veure el problema amb claredat, vas entendre què és la infraestructura com a codi, vas conèixer Deployment Manager i vas aprendre el procediment de migració. El que falta és l'eina.

A 06-07, l'última lliçó del mòdul, arriba Terraform: l'estat i per què no va mai a Git, el flux plan i apply, el codi real d'AlpinaShop en HCL, els mòduls, la importació de tot el creat a mà i el plan automàtic a cada pull request. I amb això, la infraestructura d'AlpinaShop deixa per fi de viure a l'historial d'un terminal.