El mòdul 4 va acabar amb una frase incòmoda: està tot muntat, i ningú no ho està mirant. MercadoFresco té una botiga que escala sola, una base de dades replicada, una CDN que serveix el 96 % del trànsit, identitats mínimes, dades xifrades i dos tallafocs d'aplicació. I tanmateix, si divendres a les 19:10 la botiga comença a retornar errors, la primera persona a assabentar-se'n serà un client per Twitter.

Amazon CloudWatch és el servei que resol això. No és «els gràfics d'AWS»: és el repositori central on tots els serveis que has muntat escriuen el que els passa, el lloc on s'emmagatzemen els registres de la teva aplicació, i el motor que decideix quan despertar algú. La Marta el fa servir de reüll des de 02-01 —cada vegada que hem mirat CPUUtilization o hem creat una alarma érem a CloudWatch— però mai no l'hem muntat de debò.

Aquesta lliçó el munta de debò. Al final, MercadoFresco tindrà un tauler que la Marta obre cada matí amb el cafè, mètriques de negoci pròpies, tots els seus registres en un sol lloc consultables amb un llenguatge tipus SQL i —el més important— la certesa comprovada que un avís arriba a un telèfon a les quatre de la matinada.

Avís de cost. CloudWatch és dels serveis d'AWS que més fàcilment es descontrolen, i gairebé mai per les mètriques: pels registres. Un grup de registres amb retenció infinita, o una aplicació amb DEBUG activat en producció, poden costar més que les instàncies EC2 que els generen. Cada secció d'aquesta lliçó n'indica el cost, i hi ha una secció sencera dedicada a això.

1. Què és CloudWatch i què no és
2. Els tres pilars
3. Mètriques: espais de noms i dimensions
4. Resolució estàndard enfront d'alta resolució
5. Estadístiques: per què la mitjana menteix
6. Períodes, agregació i retenció
7. Les mètriques que importen de debò del que ja està muntat
8. Per què EC2 no publica l'ús de memòria
9. Publicar mètriques personalitzades amb boto3
10. PutMetricData per lots i valors estadístics
11. L'agent unificat de CloudWatch a les instàncies de l'ASG
12. Embedded Metric Format des de Lambda
13. Registres: grups, fluxos i retenció
14. Els registres que MercadoFresco té dispersos
15. Logs Insights: sintaxi i consultes reals
16. Respondre a «per què va trigar vuit segons aquella comanda?»
17. Filtres de mètriques: d'un patró de registre a una alarma
18. Subscripcions i exportació a S3
19. Alarmes: llindars, avaluació i dades absents
20. Alarmes compostes
21. Detecció d'anomalies
22. Accions d'alarma
23. Comprovar que l'avís arriba de debò
24. El tauler mercadofresco-produccion
25. ServiceLens i Synthetics
26. Cost de CloudWatch i com es dispara
27. Neteja

CloudWatch és un servei regional d'observabilitat que fa tres coses: emmagatzemar sèries temporals numèriques (mètriques), emmagatzemar text amb marca de temps (registres), i avaluar condicions sobre això per disparar accions (alarmes).

Allò que no és, i convé fixar-ho des del principi perquè evita molta confusió:

La confusió més habitual és la primera. Si el Luis busca «qui ha esborrat el bucket», això no és a CloudWatch: és a CloudTrail. CloudWatch desa el que la teva aplicació i els serveis diuen d'ells mateixos, no qui ha parlat amb l'API d'AWS.

Històricament el bus d'esdeveniments es va dir «CloudWatch Events» i encara veuràs aquest nom en documentació antiga i en algunes respostes de la CLI. Avui és EventBridge i s'estudia a 07-03; aquesta lliçó no el toca.

Fixa't en la fletxa que va de registres a mètriques: un filtre de mètriques converteix un patró de text en una sèrie numèrica. És el pont que permet alarmar sobre alguna cosa que només apareix en un registre, com ERROR pago rechazado. I fixa't també que l'ALB escriu els registres d'accés a S3, no a CloudWatch Logs: això tindrà conseqüències a la secció de Logs Insights.

Una mètrica és una sèrie temporal identificada per tres coses:

• Espai de noms (namespace): el contenidor. Els d'AWS comencen per AWS/ (AWS/EC2, AWS/ApplicationELB, AWS/RDS, AWS/Lambda, AWS/S3, AWS/CloudFront). El teu no pot començar per AWS/: MercadoFresco fa servir MercadoFresco/Tienda.
• Nom de la mètrica: CPUUtilization, TargetResponseTime, PedidosConfirmados.
• Dimensions: fins a 30 parells clau/valor que identifiquen de què és la mesura. InstanceId=i-0abc..., LoadBalancer=app/alb-mercadofresco-tienda/..., DBInstanceIdentifier=mercadofresco-pedidos.

El detall que més despista al principi: cada combinació diferent de dimensions és una mètrica diferent i es factura per separat. Aquestes són tres mètriques, no una:

I CloudWatch no agrega automàticament entre elles. Si publiques només la tercera i després consultes la primera, no hi haurà dades. Això té dues conseqüències pràctiques:

1. Si vols el total i també el desglossament, publica'ls tots dos.
2. No facis servir mai com a dimensió res de cardinalitat alta. Posar PedidoId com a dimensió crea una mètrica nova per comanda: 900 mètriques a l'hora, 650.000 al mes, a 0,30 USD cadascuna. Això són més de 190.000 USD mensuals per un descuit d'una línia. La identitat d'una comanda va en un registre o en una anotació d'X-Ray (05-02), mai en una dimensió.

Regla de MercadoFresco: les dimensions són categories tancades i petites —entorn, component, tipus de pagament, província— mai identificadors.

L'alta resolució serveix per a processos que canvien en segons: una cua que s'omple, un pic de latència de 20 segons que a resolució de minut queda diluït en la mitjana. MercadoFresco no la fa servir: els seus problemes es veuen perfectament a un minut, i les alarmes de 10 segons generen soroll nocturn. És una eina de diagnòstic puntual, no un valor per defecte.

Les mètriques bàsiques d'EC2 són de 5 minuts llevat que activis el monitoratge detallat (2,10 USD per instància i mes a eu-west-1, aproximadament), que les baixa a 1 minut. Per a l'ASG de MercadoFresco sí que val la pena: amb dades de 5 minuts, l'escalat reacciona tard al pic dels divendres.

CloudWatch no desa cada punt individual: desa agregats per període. En consultar tries quin agregat vols:

L'error clàssic —i el que amaga més incidents— és alarmar sobre l'Average d'una latència. Un minut real de la botiga de MercadoFresco:

Average = 0,17 s. Perfecte. Verd. No salta cap alarma.

p99 = 9,4 s. Deu clients per minut estan veient una roda girar durant gairebé deu segons mentre intenten pagar. Són exactament els clients que importen: els que estan comprant.

Regla: per a qualsevol mètrica de latència, alarma sobre p95 o p99, mai sobre Average. La mitjana et diu com va el servidor; el percentil et diu com ho viu el client.

Un matís important: els percentils només estan disponibles si la mètrica es publica amb dades suficients. Les mètriques de l'ALB els admeten de manera nativa. Per a mètriques pròpies, cal publicar valors individuals o fer servir StatisticValues amb compte (ho veurem: els StatisticValues no permeten percentils, perquè ja arriben agregats).

El període és la finestra d'agregació de la consulta o de l'alarma: 60 s, 300 s, 3600 s… És independent de la freqüència amb què publiques. Si publiques cada 10 segons i consultes amb període 300, CloudWatch agrega 30 punts en un.

La retenció és automàtica, gratuïta i no configurable:

Dues conseqüències operatives:

• No pots consultar amb període 60 un dia de fa dos mesos. Les dades ja estan agregades a 5 minuts. Si necessites comparar el Black Friday de l'any passat al minut, l'has d'haver exportat abans.
• La Marta exporta cada mes les mètriques de negoci (PedidosConfirmados) a mercadofresco-informes-analitica amb get-metric-data, precisament perquè la Sara pugui comparar campanyes d'anys diferents.

Aquesta és la taula que la Marta s'ha imprès. Dels centenars de mètriques que publiquen els serveis de MercadoFresco, aquestes són les que de debò decideixen alguna cosa:

Tres observacions que separen qui entén això de qui copia llindars:

• HTTPCode_ELB_5XX_Count i HTTPCode_Target_5XX_Count no són el mateix. El primer significa que el balancejador no va poder lliurar la petició a ningú (no hi ha destins sans, temps d'espera exhaurit). El segon significa que la teva aplicació ha respost 500. Confondre'ls fa perdre hores buscant al lloc equivocat.
• FreeStorageSpace d'RDS està en bytes. El llindar de 20 GB s'escriu 21474836480. Un zero de més i l'alarma no salta mai.
• Throttles de Lambda amb llindar > 0, no > 10. Un sol estrangulament significa que has tocat el sostre de concurrència i hi ha clients veient errors. No hi ha un «poc de throttling acceptable».

És la pregunta que fa tothom en arribar aquí, i la resposta explica com funciona el núvol.

L'hipervisor d'AWS veu la màquina virtual des de fora. Pot mesurar CPU consumida, trànsit de xarxa, operacions de disc del volum EBS: tot això passa per la seva capa. Però la memòria lliure és un concepte del sistema operatiu convidat. Només Linux sap quanta RAM hi ha a buff/cache i es podria alliberar, i això l'hipervisor no ho pot saber sense entrar-hi.

El mateix passa amb l'espai lliure del disc: EBS és un dispositiu de blocs, i només el sistema de fitxers de dins sap què està ocupat.

Conseqüència pràctica: per a memòria i disc d'EC2 necessites instal·lar un agent dins de la instància. Es fa més avall. I conseqüència de disseny: per això Lambda, Fargate i RDS —on AWS gestiona el sistema operatiu— sí que publiquen memòria sense que facis res.

Les mètriques d'infraestructura diuen com va la màquina. Les de negoci diuen com va l'empresa, i són les que de debò detecten incidents. A 04-04 vam veure per què: si arriben 5.000 peticions per segon i PedidosPorHora no es mou, no són clients.

MercadoFresco ja publicava PedidosPorHora. Ara hi afegim les dues que falten:

El codi, a la botiga:

Detalls que importen i que no són obvis:

• Timestamp és opcional; si no el poses, CloudWatch fa servir l'hora de recepció. Pots publicar dades de fins a 2 setmanes d'antiguitat i fins a 2 hores en el futur. Això permet recuperar mètriques d'un procés per lots que ha fallat.
• La unitat importa poc a CloudWatch però molt a les alarmes. Si publiques en Milliseconds i l'alarma espera Seconds, l'alarma no troba dades i es queda en INSUFFICIENT_DATA per sempre. Sigues coherent.
• Publicar Value: 1 repetidament és correcte. CloudWatch suma els valors del període quan consultes amb Sum. No cal que l'aplicació mantingui un comptador.
• provincia no es fa servir com a dimensió en aquest exemple. Espanya té 52 províncies: seria acceptable, però multiplicaria per 52 el nombre de mètriques (15,60 USD/mes només per això). La Marta va decidir que aquest desglossament viu als informes de la Sara sobre mercadofresco-informes-analitica, no a CloudWatch.

El codi anterior fa una crida HTTPS a l'API de CloudWatch dins de la ruta crítica d'una compra. Amb 900 comandes/hora funciona; amb un pic seriós, aquesta crida de 40 ms se suma al temps de resposta que el client percep, i si l'API de CloudWatch s'alenteix, la teva botiga s'alenteix.

Tres solucions, de pitjor a millor:

1. Embolcallar-ho en un try/except i no fallar mai. Mínim indispensable: una mètrica no ha de tombar una venda.
2. Acumular en memòria i publicar per lots cada 20 segons des d'un fil a part (secció següent).
3. Escriure la mètrica al registre en format EMF i deixar que CloudWatch l'extregui (secció de Lambda). Cost zero a la ruta crítica.

PutMetricData accepta fins a 1.000 punts per crida (amb un límit d'1 MB de cos). Publicar per lots redueix el cost d'API (0,01 USD per cada 1.000 crides) i treu la latència de la ruta crítica.

Si només necessites Sum, Average, Min i Max, pots preagregar-ho tu i enviar un únic punt amb StatisticValues. Una crida en lloc de nou-centes:

El preu d'aquesta optimització: amb StatisticValues perds els percentils. CloudWatch només rep quatre números; no pot calcular un p99 a partir d'ells. Com que el p95 de TiempoConfirmacionPedido és precisament el que la Marta vol vigilar, MercadoFresco no fa servir StatisticValues per a aquesta mètrica. Sí que la fa servir per a ImportePedido, on el Sum i el Maximum són tot el que interessa.

Una tercera opció, intermèdia, és el camp Values + Counts, que envia valors diferents amb la seva multiplicitat i sí que conserva percentils:

Per a memòria i disc cal un agent dins de la instància. L'agent unificat de CloudWatch (amazon-cloudwatch-agent) fa dues feines alhora: publica mètriques del sistema i envia fitxers de registre a CloudWatch Logs. Substitueix els antics scripts de Perl i l'awslogs, ja en desús.

El rol rol-mercadofresco-tienda necessita això afegit a pol-mercadofresco-tienda:

Fixa't en dues coses. cloudwatch:PutMetricData no admet ARN de recurs —per això "Resource": "*" amb la condició d'espai de noms, exactament el patró que vam estudiar a 04-01—. I la configuració de l'agent es desa a Parameter Store (04-03), que és la manera neta que totes les instàncies de l'ASG en comparteixin la mateixa sense coure-la a l'AMI.

Repàs de les decisions preses allà, perquè cadascuna té el seu motiu:

• namespace propi MercadoFresco/Sistema, separat de MercadoFresco/Tienda. Mètriques de màquina i mètriques de negoci no es barregen: facilita els permisos i els taulers.
• append_dimensions amb ${aws:AutoScalingGroupName}: l'agent resol aquestes variables sol, consultant les metadades de la instància. No cal generar un fitxer per instància.
• aggregation_dimensions amb [] (llista buida) publica també la mètrica agregada de tot el grup. És la que es fa servir al tauler: a la Marta li interessa «memòria mitjana de l'ASG», no la de la instància i-0abc.
• multi_line_start_pattern: sense això, una traça de Python de 30 línies es converteix en 30 esdeveniments de registre inconnexos i les consultes d'Insights no troben res.
• retention_in_days a la configuració mateixa: l'agent crea el grup amb retenció finita des del primer dia. És la línia que més diners estalvia de tot el fitxer.
• procstat vigila el procés gunicorn concret. Si el procés mor i systemd el reinicia en bucle, la CPU de la instància sembla normal però procstat el delata.

I el fragment que s'afegeix al user data de la plantilla lt-mercadofresco-tienda (02-01):

Després d'actualitzar el user data cal crear una nova versió de la plantilla de llançament i fer un instance refresh de l'ASG:

Cost de l'agent: el programari és gratuït; es paga pel que publica. Amb 4 mètriques del sistema agregades a nivell d'ASG més les de cada instància, MercadoFresco publica unes 20 mètriques personalitzades: 6 USD al mes. La verificació importa: si deixes les dimensions per instància sense agregar i l'ASG rota instàncies tot el dia, cada InstanceId nou crea mètriques noves. Són mètriques que deixen de rebre dades —i per tant de facturar-se després del període de facturació—, però embruten els taulers.

A Lambda, cridar PutMetricData és especialment car: la funció està facturada per mil·lisegon, així que esperar 40 ms l'API de CloudWatch es paga literalment. I si la Lambda s'invoca 50.000 vegades al dia, són 50.000 crides d'API.

L'Embedded Metric Format (EMF) resol això de manera elegant: escrius un JSON amb una estructura especial a stdout, i CloudWatch Logs extreu les mètriques automàticament en ingerir-lo. Cost a la funció: el d'un print.

La clau conceptual és a les dues últimes seccions del document:

És a dir: EMF et permet tenir la clau de l'objecte d'S3 i l'ID de la petició al costat de la mètrica, sense pagar el preu de la cardinalitat. Quan el p99 de TiempoProceso es dispari, una consulta d'Insights et dirà exactament quins fitxers van ser els lents. Això amb PutMetricData és impossible.

Nota pràctica: la biblioteca aws-embedded-metrics d'AWS fa tot això per tu amb un decorador. Aquí s'ha escrit el JSON a mà perquè es vegi l'estructura, que és el que cal entendre.

Cost d'EMF: es paga la ingesta del registre (uns 0,63 USD/GB a eu-west-1) i les mètriques extretes (0,30 USD cadascuna). No es paguen crides d'API. Per a funcions d'alta freqüència surt clarament a compte.

La jerarquia és simple i convé tenir-la clara:

• Grup de registres (log group): el contenidor. Aquí es configura la retenció, el xifratge amb KMS i les subscripcions. Exemple: /mercadofresco/tienda/aplicacion.
• Flux de registres (log stream): una seqüència d'esdeveniments d'una sola font. Una instància, una execució de Lambda. Exemple: i-0abc123def456.
• Esdeveniment: una línia amb marca de temps i missatge. Màxim 256 KB.

Per defecte, un grup de registres es crea amb retenció Never expire. Ningú no ho canvia. Tres anys després, MercadoFresco tindria 400 GB de registres d'nginx de 2023 costant 0,03 USD/GB/mes —12 USD mensuals per dades que ningú no llegirà mai— i creixent.

I hi ha una cosa pitjor que el cost: una consulta de Logs Insights escaneja el que li demanis, i a 0,0063 USD per GB escanejat, una cerca descuidada sobre tres anys de registres costa més que la cerca mateixa.

La política de MercadoFresco:

I l'ordre que cal executar el mateix dia que es crea un grup:

Una auditoria útil que la Marta executa un cop al mes, per trobar els grups que se li han colat sense retenció:

A 05-04 veurem com AWS Config converteix aquesta auditoria manual en una regla que salta sola.

CloudWatch Logs té dues classes d'emmagatzematge:

Per a flowlogs-mercadofresco, que es consulta només quan hi ha una investigació de xarxa, la classe Infrequent Access estalvia la meitat. Per a /mercadofresco/tienda/aplicacion, del qual depenen filtres de mètriques i alarmes, cal quedar-se a Standard.

Aquesta era una de les cinc preguntes obertes del mòdul 4: «els registres de WAF, VPC, ALB i Lambda s'acumulen en cinc llocs sense correlacionar». Vegem el mapa real:

L'honestedat importa aquí: CloudWatch Logs no ho centralitza tot. Els registres d'accés de l'ALB i de CloudFront van a S3 per disseny, perquè el seu volum faria prohibitiva la ingesta a Logs. La centralització real de MercadoFresco és a dos nivells:

• Diagnòstic en calent (últims dies): CloudWatch Logs Insights.
• Anàlisi històrica i forense: S3 + Athena, que es veu a 05-03.

Activar els registres de PostgreSQL a la instància RDS, que sí que falta:

Aquest log_min_duration_statement=1000 serà decisiu a la secció de la comanda de vuit segons.

CloudWatch Logs Insights és un llenguatge de consulta sobre els registres. No és SQL, tot i que s'hi assembla: és una canonada d'ordres separades per |.

Els camps @timestamp, @message, @logStream i @log existeixen sempre. Si el teu registre és JSON, Insights el descompon sol i pots referir-te a nivel, pedido_id, duracion_ms directament. Aquesta és la raó número u per registrar en JSON des del primer dia.

bin(5m) agrupa per finestres de cinc minuts: és el que converteix una llista d'errors en un gràfic de tendència. En executar-la, Insights ofereix «Visualization» i aquest resultat es pot afegir directament al tauler.

Aquesta és la consulta que a 04-05 decidia el pas de Count a Block. Ara saps exactament on s'executa.

Els camps @duration, @billedDuration, @maxMemoryUsed i @initDuration els genera Lambda automàticament a la línia REPORT de cada invocació. @maxMemoryUsed enfront de la memòria configurada és la manera més directa d'ajustar la mida d'una funció: si en fa servir 80 MB de 512 configurats, estàs pagant de més.

Algú intentant arribar al port 5432 i sent rebutjat per sg-mercadofresco-basedatos. Si aquesta IP és interna, és un error de configuració. Si és externa, és un escaneig.

parse amb expressió regular i grups amb nom converteix el registre d'accés d'nginx en camps consultables. És el rescat per a tot el programari que no registra en JSON.

Avís de cost: cada execució cobra per GB escanejats, no per resultats retornats. Acotar el rang temporal és el que decideix la factura: la mateixa consulta sobre 1 hora o sobre 30 dies costa 720 vegades més en el segon cas. Redueix sempre la finestra abans de refinar la consulta.

Aquesta és la segona pregunta que va deixar oberta el mòdul 4. Un client escriu: «dijous a la tarda vaig trigar uns vuit segons a tenir la comanda confirmada». La Marta té el seu correu i l'hora aproximada.

Requisit previ: un identificador de correlació que travessi tots els components. Sense ell, això és impossible. MercadoFresco afegeix a nginx una capçalera X-Peticion-Id que l'aplicació propaga a la Lambda i escriu a cada línia de registre.

Pas 1. Confirmar que el problema existeix i acotar-lo.

Apareixen 34 peticions lentes dijous entre les 18:40 i les 19:20. No era cosa d'un client.

Pas 2. Trobar la petició concreta.

En surt una: peticion_id = 7f3a9b2c, duracion_ms = 8140.

Pas 3. Seguir aquest identificador per tots els grups alhora. Insights permet consultar fins a 50 grups de registres en una sola consulta, i aquesta és la resposta real a «els registres són en cinc llocs sense correlacionar»:

Pas 4. Llegir la cronologia.

Trobat. No era la botiga (27 + 57 + 52 + 10 + 34 = 180 ms), ni la Lambda (550 ms): eren 7,4 segons dins de PostgreSQL. Els registres de log_min_duration_statement que vam activar abans són els que han cantat.

Pas 5. Veure quina consulta era.

I apareix una consulta que fa un SELECT de preu per cada línia de la comanda, en un bucle, en lloc d'un sol SELECT ... WHERE id IN (...). És el patró N+1: una comanda amb 38 productes executa 39 consultes.

Què acabem de fer i què no. Hem localitzat el problema amb registres correlacionats, i ha funcionat perquè MercadoFresco tenia un identificador de petició propagat a mà. Però fixa't en l'esforç: quatre consultes, una cronologia muntada manualment, i tot recolzat en el fet que algú es va recordar de propagar la capçalera. Existeix una eina dissenyada exactament per a això, que fa el pas 4 automàticament i en un gràfic: és X-Ray, i és la lliçó 05-02. Tornarem a aquesta mateixa comanda de 8,14 segons allà.

No es pot alarmar sobre un registre; sí sobre una mètrica. Un filtre de mètriques és la conversió.

Tres detalls de camp:

• La sintaxi de --filter-pattern no és la d'Insights. Per a registres JSON fes servir { $.camp = "valor" } amb &&, ||, =, !=, >, <. Per a text pla, cometes i termes: "ERROR" -"ERROR de prueba".
• defaultValue=0 és imprescindible. Sense ell, quan no hi ha errors no es publica cap dada, l'alarma es queda en INSUFFICIENT_DATA i la mètrica té buits que trenquen la detecció d'anomalies. Amb defaultValue=0 la sèrie és contínua.
• Els filtres només s'apliquen a esdeveniments nous. No hi ha efecte retroactiu sobre el ja ingerit.

També es pot extreure un valor numèric del registre en lloc de comptar:

I provar el patró abans de crear-lo, contra esdeveniments reals, cosa que evita el clàssic filtre que no coincideix mai:

Dues maneres de treure registres de CloudWatch, amb propòsits diferents:

Subscripció en temps real cap a una Lambda que reenvia a Slack el que és crític:

Exportació a S3 per a arxiu barat dels flow logs, que es miraran un cop l'any:

El bucket necessita una política que permeti escriure a logs.eu-west-1.amazonaws.com. I compte: només pot haver-hi una tasca d'exportació activa per compte alhora, i no és incremental. Per a arxivat continu, l'opció moderna és una subscripció cap a Data Firehose amb destí S3.

Una alarma té tres estats:

I quatre paràmetres que gairebé ningú no configura bé a la primera:

• --period: la finestra d'agregació. 60, 300…
• --evaluation-periods: quants períodes es miren.
• --datapoints-to-alarm: quants d'aquests han d'incomplir. Si s'omet, són tots.
• --treat-missing-data: què fer amb els buits.

La combinació evaluation-periods + datapoints-to-alarm s'anomena «M de N» i és l'eina contra el soroll. Compara:

Amb «2 de 3», un pic d'un sol minut —un desplegament, un garbage collector, una còpia de seguretat— no desperta ningú, però un problema real que oscil·la sí que es detecta. La configuració «3 de 3» es perd exactament aquests problemes intermitents.

I --treat-missing-data, quatre opcions:

El cas que ho explica tot: l'alarma sobre PedidosConfirmados. Si la botiga cau del tot, deixa de publicar-se la mètrica. Amb notBreaching, l'alarma es queda en OK mentre la botiga està morta. És la fallada silenciosa més habitual de CloudWatch, i per això aquesta alarma concreta porta --treat-missing-data breaching.

Les alarmes que MercadoFresco crea en aquesta lliçó:

Nota sobre --ok-actions a l'alarma 1: enviar també la recuperació. Sense ella, algú rep un avís de matinada i no té manera de saber si continua passant. Amb --ok-actions, el segon missatge diu «ja està bé». És un detall petit que canvia molt l'experiència d'estar de guàrdia.

I una advertència sobre l'alarma 8: PedidosConfirmados < 1 en 15 minuts és correcte per a l'horari comercial, però a les 4 del matí un diumenge pot ser perfectament normal que no hi hagi comandes. Aquesta alarma genera falsos positius nocturns. La manera correcta de resoldre-ho no és pujar el període: és la detecció d'anomalies, dues seccions més avall.

Una alarma composta s'avalua sobre altres alarmes, amb AND, OR i NOT. Serveix per a dues coses diferents:

1. Reduir soroll: avisar només si diversos senyals coincideixen.
2. Suprimir alarmes filles durant un manteniment conegut.

El problema real de MercadoFresco: quan la base de dades se satura un divendres, salten alhora mercadofresco-rds-conexiones-altas, mercadofresco-alb-latencia-alta i mercadofresco-pedidos-fallidos. Tres SMS a les 19:15 descrivint el mateix incident.

I ara el pas que la majoria oblida: treure l'acció d'SNS de les alarmes filles. Si no, continues rebent quatre avisos en lloc de tres.

L'alarma filla continua existint, continua canviant d'estat i continua veient-se al tauler: simplement ja no notifica. L'avís el dona la composta, que conté el diagnòstic.

Supressió durant manteniment: el paràmetre --actions-suppressor permet indicar una altra alarma —per exemple, una que la Marta posa en ALARM a mà durant un desplegament— que silencia la composta mentre estigui activa.

Cost: 0,50 USD per alarma composta i mes. Sol sortir a compte només per deixar de despertar algú tres vegades.

En lloc d'un llindar fix, CloudWatch entrena un model amb fins a dues setmanes d'història i aprèn el patró: els pics dels divendres, les valls de la matinada, el cicle setmanal. L'alarma salta quan el valor surt de la banda esperada.

És exactament el que resol el fals positiu nocturn de mercadofresco-sin-pedidos: a les 4 de la matinada el model espera 3 comandes, i 0 és anòmal; a les 19:00 n'espera 900, i 400 també ho és. Un llindar fix no pot expressar això.

Detalls clau:

• LessThanLowerThreshold: només avisa si hi ha menys comandes de les esperades. Que n'hi hagi més és una bona notícia, no una alarma. També existeixen GreaterThanUpperThreshold i LessThanLowerOrGreaterThanUpperThreshold.
• El 2 d'ANOMALY_DETECTION_BAND(m1, 2) és el nombre de desviacions. Més alt = banda més ampla = menys avisos. Comença a 2 i ajusta amb dades reals.
• Necessita història. Els primers dies la banda és enorme i l'alarma no serveix de res. Cal crear-la i esperar.
• Es pot excloure un període de l'entrenament amb --configuration i ExcludedTimeRanges: si hi ha hagut un incident de 6 hores, no vols que el model aprengui que això és normal.

Cost: 0,30 USD per mètrica analitzada i mes, més 0,30 USD per alarma d'anomalia.

I una advertència honesta: la detecció d'anomalies no és màgia. Detecta desviacions del patró històric, no problemes. Una degradació lenta i constant durant tres setmanes es converteix en el nou «normal» i deixa d'avisar. Complementa els llindars fixos; no els substitueix.

Les accions automàtiques d'EC2 són útils però perilloses. arn:aws:automate:eu-west-1:ec2:recover sobre StatusCheckFailed_System migra la instància a un altre amfitrió quan falla el maquinari subjacent, conservant IP i volums: això és clarament bo. En canvi arn:aws:automate:eu-west-1:ec2:reboot sobre memòria alta és una mala idea: reinicies en bucle una instància amb una fuita de memòria i amagues el problema en lloc d'arreglar-lo.

Per a les instàncies de l'ASG, a més, l'acció correcta gairebé mai és reiniciar: és deixar que fallin la comprovació de salut /salud i que el mateix ASG les reemplaci, que és el que vam muntar a 02-01 i 03-03.

Aquí hi ha la primera pregunta oberta del mòdul 4, i la més important d'aquesta lliçó: ningú no ha comprovat que un avís d'SNS arribi a un telèfon a les quatre de la matinada.

Una alarma que dispara cap a un tema d'SNS sense subscriptors confirmats és pitjor que no tenir alarma: dona una falsa sensació de cobertura.

Pas 1. Veure qui està subscrit de debò.

Si a la columna SubscriptionArn apareix PendingConfirmation, aquesta subscripció no rep res. És la troballa més freqüent quan es fa aquesta comprovació per primera vegada: algú va crear la subscripció fa mesos, el correu de confirmació va anar a la carpeta de correu brossa, i ningú no ho va saber.

Pas 2. Subscriure els destins que falten.

Nota sobre SMS. Des de fa uns anys, enviar SMS amb SNS a moltes regions exigeix sortir del «sandbox» d'SMS i, per a números espanyols, registrar remitent i cas d'ús. Si el teu SMS de prova no arriba, revisa l'estat del sandbox abans de donar per trencada l'alarma. El detall complet d'SNS —temes FIFO, polítiques de lliurament, filtres de subscripció— és la lliçó 07-02.

Pas 3. El simulacre. Forçar l'estat de l'alarma.

Aquesta és l'ordre que tanca la pregunta del mòdul 4:

Això no toca la mètrica: força l'estat de l'alarma i dispara les seves accions de debò. L'SMS i el correu surten. És l'única manera honesta de saber que el canal funciona.

Després es torna a la realitat:

Al següent període d'avaluació, CloudWatch recalcula l'estat real amb les dades de la mètrica i el corregeix sol si calgués.

Pas 4. El protocol que adopta MercadoFresco.

I una comprovació més, que sol descobrir el problema real: fer el simulacre a les 4 de la matinada de debò, una vegada. La Marta ho va fer. Va descobrir que el mòbil de guàrdia estava en «no molestar» i que els SMS de números curts no trencaven el silenci. La solució no va ser d'AWS: va ser configurar una excepció al telèfon. La cadena d'avís inclou el telèfon, i el telèfon també s'ha de provar.

Un tauler de CloudWatch és un document JSON amb una quadrícula de 24 columnes d'ample. Els ginys es posicionen amb x, y, width, height.

El criteri amb què la Marta l'ha dissenyat —i que és el que cal copiar, més que el JSON— és: a dalt allò que respon «va bé el negoci?», al mig «quin component falla?», a baix el detall. Quan sona el telèfon, es mira de dalt a baix i en 30 segons se sap on anar.

I la creació:

Detalls del JSON que mereixen explicació:

• "start": "-PT3H" fixa la finestra per defecte en les últimes 3 hores. Sintaxi ISO 8601 de durada: -PT1H, -P1D, -P7D.
• ["...", { "stat": "p95" }] repeteix la mètrica anterior canviant només l'estadística. Estalvia repetir l'ARN llarg tres vegades.
• El giny de la vora porta "region": "us-east-1". Les mètriques de CloudFront i de la Web ACL de CloudFront viuen allà, el mateix parany de 03-04 i 04-05. Un tauler pot barrejar regions giny a giny, i això el converteix en l'únic lloc on MercadoFresco ho veu tot junt.
• Les annotations horitzontals dibuixen la línia del llindar. Veure el gràfic acostar-se a la línia vermella abans que salti l'alarma és la meitat del valor d'un tauler.
• El giny log executa una consulta d'Insights cada vegada que es carrega el tauler. Compte: això costa diners cada vegada, i si el tauler està en una pantalla de l'oficina refrescant cada minut, són 1.440 consultes al dia. La Marta li va posar limit 20 i una finestra curta per aquesta raó.

Cost dels taulers: els 3 primers són gratuïts; a partir d'aquí, 3 USD per tauler i mes. MercadoFresco en té dos: mercadofresco-produccion i mercadofresco-negocio (el de la Sara, amb comandes i imports). Cost: 0 USD.

Dues funcions de CloudWatch que s'esmenten aquí i s'aprofiten a 05-02:

ServiceLens uneix mètriques, registres i traces d'X-Ray en un mapa de serveis únic. Necessita que X-Ray estigui actiu, així que es veu a la lliçó següent.

CloudWatch Synthetics executa «canaris»: petits scripts que es comporten com un client, des de fora, cada N minuts. És monitoratge sintètic: no espera que hi hagi un client real per detectar que la botiga està trencada. Amb 900 comandes/hora això no sembla important, però a les 3 de la matinada un diumenge poden passar dues hores sense una sola compra, i aquest és exactament el forat pel qual s'escola una caiguda.

El canari de MercadoFresco, canario-mercadofresco-compra, s'executa cada 5 minuts i fa el recorregut complet: portada, cercar «tomàquet», obrir la fitxa, afegir a la cistella, arribar al formulari de pagament (sense pagar). Si algun pas falla, dispara alertas-mercadofresco.

Dues advertències pràctiques:

• Un canari que compra de debò genera comandes de debò. El de MercadoFresco s'atura abans de confirmar, i l'usuari de prova està marcat perquè la Sara l'exclogui dels seus informes.
• Cost: 0,0012 USD per execució. Cada 5 minuts són 8.640 execucions al mes: 10,37 USD, més les captures de pantalla a S3 i les traces. No és menyspreable; és la partida més cara d'aquesta lliçó després dels registres.

Preus de referència a eu-west-1 (aproximats; consulta sempre la calculadora oficial):

El càlcul de MercadoFresco:

Les cinc maneres de disparar aquesta factura, per ordre de freqüència real:

1. Retenció infinita als grups de registres. Creix sense parar i mai no ho notes de cop.
2. DEBUG activat en producció. Multiplica la ingesta per deu d'un dia per l'altre. La ingesta és la partida cara: 0,63 USD/GB.
3. Una dimensió de cardinalitat alta. PedidoId com a dimensió: desenes de milers d'USD. És l'error més car que es pot cometre a CloudWatch, i es comet en una línia.
4. Consultes d'Insights sobre 30 dies per depurar. Cada refinament de la consulta torna a escanejar-ho tot.
5. Un tauler amb ginys de registre en una pantalla d'oficina. Executa consultes cada minut per sempre.

I la defensa: un pressupost d'AWS Budgets filtrat pel servei CloudWatch (mòdul 11) amb avís al 80 %. A 05-04 veurem a més com AWS Config detecta automàticament els grups de registres sense retenció.

Dos avisos:

• Les mètriques personalitzades no es poden esborrar. Deixen de facturar-se quan deixen de rebre dades (després del període corresponent), però romanen visibles un temps. És una raó més per no crear dimensions a la lleugera.
• Esborrar un grup de registres n'elimina les dades de manera irreversible. Si hi pot haver una obligació de conservació, exporta'l a S3 primer i consulta-ho amb qui porti el compliment.

1. Alarmar sobre la mitjana d'una latència. És l'error número u. L'Average de TargetResponseTime es queda pla mentre el p99 és a 9 segons. Fes servir --extended-statistic p95 o p99 per a tot el que sigui temps.

2. Deixar la retenció de registres en «Never expire». És el valor per defecte. És l'error més car a mitjà termini. Posa retenció el mateix dia que crees el grup, i audita mensualment amb describe-log-groups.

3. Fer servir un identificador com a dimensió. PedidoId, UserId, RequestId en una dimensió creen una mètrica nova cada vegada. Milers d'USD. Aquestes dades van al registre o en una anotació d'X-Ray.

4. --treat-missing-data mal triat. Per a una mètrica l'absència de la qual és el problema —PedidosConfirmados, HealthyHostCount— cal posar breaching. Amb notBreaching l'alarma està tranquil·la mentre la botiga està morta.

5. Confondre HTTPCode_ELB_5XX_Count amb HTTPCode_Target_5XX_Count. El primer és del balancejador (no hi ha destins sans, temps d'espera); el segon és la teva aplicació. Buscar al lloc equivocat costa hores.

6. Llindars en unitats equivocades. FreeStorageSpace està en bytes; Duration de Lambda en mil·lisegons; TargetResponseTime en segons. Un zero de més o de menys i l'alarma no salta mai.

7. Crear una alarma sense comprovar la subscripció d'SNS. Si l'ARN és correcte però ningú no ha confirmat la subscripció, l'alarma dispara al buit. Comprova-ho amb list-subscriptions-by-topic i fes un simulacre amb set-alarm-state.

8. No configurar --ok-actions. Qui rep un avís de matinada necessita saber quan s'ha recuperat. Sense la notificació de tornada a OK, algú s'aixeca per no res o, pitjor, no s'aixeca quan ho hauria de fer.

9. Buscar a CloudWatch qui ha esborrat un recurs. Això és a CloudTrail (05-03). CloudWatch registra el que la teva aplicació diu d'ella mateixa.

10. Mètriques de CloudFront buscades a eu-west-1. Són a us-east-1, sempre. Igual que els certificats d'ACM (03-04) i la Web ACL de CloudFront (04-05).

11. Consultes d'Insights sobre rangs enormes mentre es depura. Comença per 15 minuts, afina la consulta, i només llavors amplia la finestra. Es paga per GB escanejat a cada execució.

12. Registrar text pla en lloc de JSON. Amb JSON, Insights descompon els camps sol i les consultes són trivials. Amb text pla cal escriure expressions regulars amb parse. Canviar el format del registre el primer dia costa una hora; fer-ho tres anys després, setmanes.

13. Un filtre de mètriques sense defaultValue=0. La sèrie té buits, l'alarma es queda en INSUFFICIENT_DATA i la detecció d'anomalies no funciona.

14. Oblidar treure les accions de les alarmes filles en crear-ne una de composta. S'acaba rebent un avís més, no menys.

Consell final: la mètrica més valuosa d'un sistema gairebé mai és tècnica. PedidosConfirmados detecta més incidents reals que CPUUtilization, perquè pot haver-hi mil maneres que la botiga falli amb la CPU al 30 %, però només n'hi ha una que les comandes caiguin a zero.

MercadoFresco desplega una versió nova de la botiga un dimarts a les 11:00. La versió té un error que només afecta les comandes pagades amb targeta d'un banc concret: aproximadament el 12 % de les compres. La resta funciona amb normalitat.

Dades de l'incident: CPUUtilization sense canvis (42 %), HealthyHostCount a 2, TargetResponseTime p95 estable a 0,6 s, HTTPCode_Target_5XX_Count amb 3 errors cada 5 minuts (abans: 1). PedidosConfirmados passa de 900/h a 792/h. Als registres apareixen línies {"nivel":"ERROR","tipo_error":"PAGO_RECHAZADO","pasarela":"banco-x"}.

No salta cap alarma actual. L'error es descobreix 6 hores després per una queixa a les xarxes socials.

Dissenya la detecció: quina mètrica o mètriques faries servir, com les obtindries (filtre de mètriques, mètrica personalitzada, expressió), quin tipus d'alarma i amb quins paràmetres exactes de període, avaluació i dades absents. Escriu les ordres. Justifica per què la teva proposta hauria saltat en menys de 30 minuts sense generar falsos positius la resta del mes.

La Sara pregunta si el cercador de la botiga funciona bé. L'aplicació escriu una línia JSON per cerca:

Escriu:

• a) Una consulta d'Insights que doni, per hora, el nombre de cerques, la durada mitjana, el p95 i el percentatge de cerques sense resultats.
• b) Una consulta que llisti els 20 termes més cercats que retornen zero resultats (són productes que MercadoFresco hauria de tenir al catàleg: valor directe per a la Sara).
• c) Un filtre de mètriques i una alarma que avisin si el percentatge de cerques sense resultats supera el 20 % durant 15 minuts, que és el senyal que l'índex de cerca s'ha corromput. Compte: un filtre de mètriques compta, no calcula percentatges. Necessitaràs una expressió de mètrica a l'alarma.

La Marta rep la factura i CloudWatch ha passat de 44 a 610 USD en un mes. El desglossament:

Pistes de la investigació:

• El grup /mercadofresco/tienda/aplicacion ha passat de 8 GB a 620 GB en el mes.
• L'espai MercadoFresco/Tienda té ara 320 mètriques; el mes passat en tenia 8.
• Hi ha 11.200 execucions d'Insights, totes amb finestra de 30 dies.
• Hi ha un canari nou, canario-mercadofresco-admin, executant-se cada minut.
• El Luis va desplegar fa tres setmanes una funció de «comandes recomanades» que registra l'activitat de cada client.

Diagnostica cada partida, digues exactament què va fer malament el Luis en cada cas, escriu les accions correctives amb les ordres, i proposa tres controls preventius perquè no torni a passar. Estima la factura resultant.

Solució 1

Per què no va saltar res. Totes les alarmes actuals miren la infraestructura, i la infraestructura està perfecta. Una fallada del 12 % en una passarel·la concreta és invisible per a la CPU, per al nombre de destins sans i per al p95 de latència (un pagament rebutjat respon ràpid, fins i tot més ràpid que un de correcte). I la caiguda de comandes de 900 a 792 —un 12 %— queda dins de la variació normal d'un dimarts. Cap llindar fix raonable no detecta un 12 %.

Això és el que s'anomena una fallada parcial, i és el tipus d'incident que més triga a detectar-se en sistemes reals.

Detecció proposada: tres capes.

Capa 1 — el senyal directe. Filtre de mètriques sobre l'error concret, desglossat per passarel·la.

Capa 2 — l'alarma de proporció, que és la bona. Un llindar absolut de «més de N rebuigs» falla en tots dos sentits: de nit 3 rebuigs són moltíssim, al pic del divendres no són res. El correcte és alarmar sobre el percentatge, amb una expressió de mètrica:

Amb un 12 % de rebuigs enfront d'un llindar del 5 %, i «2 de 3» períodes de 5 minuts, aquesta alarma salta en 10-15 minuts. El requisit és publicar també IntentosPago (un segon filtre de mètriques o una mètrica personalitzada); sense denominador no hi ha proporció.

Capa 3 — la xarxa de seguretat genèrica: detecció d'anomalies sobre PedidosConfirmados. Una caiguda del 12 % sostinguda durant 6 hores sí que surt de la banda d'anomalia, perquè el model coneix el patró d'un dimarts al matí amb precisió. És l'alarma mercadofresco-pedidos-anomalos que ja vam crear: hauria saltat, probablement a la primera hora. És més lenta que la capa 2, però és l'única que detecta problemes que ningú no ha anticipat.

Per què no genera falsos positius. La capa 2 mira una proporció, i una proporció és independent del volum: funciona igual a les 4 de la matinada que el divendres a les 19:00. Amb «2 de 3» períodes de 5 minuts, un pic aïllat de rebuigs —un banc que reinicia la seva passarel·la un minut— no dispara res.

La lliçó de fons: les alarmes d'infraestructura detecten caigudes totals. Les fallades parcials, que són les més freqüents i les que més diners costen, només les detecten les mètriques de negoci i les proporcions.

Solució 2

a) Panorama per hores.

La clau és a sum(resultados = 0): a Insights, una expressió booleana val 1 o 0, així que sumar-la compta els casos certs. És l'idioma per calcular percentatges en aquest llenguatge.

b) Termes sense resultats: valor de negoci directe.

Això no és monitoratge tècnic: és una llista de productes que els clients cerquen i MercadoFresco no ven. La Marta l'envia a la Sara cada dilluns. És el millor exemple que els registres d'una aplicació serveixen per a molt més que depurar.

c) Filtre de mètriques i alarma de proporció.

Dos filtres, perquè calen numerador i denominador:

I l'alarma amb expressió:

Tres decisions justificades:

• MAX([total, 1]) al denominador evita la divisió per zero quan no hi ha cerques de matinada. Sense això, l'expressió produeix valors no numèrics i l'alarma es comporta de manera erràtica.
• 3 de 3 períodes de 5 minuts = 15 minuts, tal com demanava l'enunciat. Aquí sí que convé «3 de 3» i no «2 de 3»: un índex corromput no s'arregla sol, així que el senyal serà sostingut, i esperar 15 minuts evita el soroll d'un desplegament de l'índex de cerca.
• notBreaching perquè de matinada pot no haver-hi cerques, i això no és un incident.

Solució 3

Diagnòstic partida per partida.

1. Ingesta de registres: 412 USD (8 GB → 620 GB). La funció de «comandes recomanades» del Luis registra l'activitat de cada client en cada visita. Probablement escriu una línia per producte vist, i molt probablement amb nivel: DEBUG perquè així ho va deixar després de depurar. 612 GB extra a 0,63 USD/GB són 386 USD. És la causa principal.

Error del Luis: deixar DEBUG en producció i escriure al registre d'aplicació un flux d'esdeveniments d'analítica que no és un registre d'aplicació.

Correcció, en dos temps:

De fons: els esdeveniments de comportament de client no van a CloudWatch Logs. Van a mercadofresco-informes-analitica a S3, via Firehose, on l'emmagatzematge costa 0,023 USD/GB en lloc dels 0,63 USD/GB d'ingesta. És 27 vegades més barat i és on la Sara els vol de totes maneres.

2. Mètriques personalitzades: 96 USD (8 → 320 mètriques). 320 × 0,30 = 96 USD. Gairebé amb seguretat, la funció de recomanacions publica una mètrica amb una dimensió de cardinalitat mitjana —CategoriaProducto amb 300 valors, o ModeloRecomendador—.

Error del Luis: fer servir com a dimensió una cosa que no és una categoria petita i tancada.

Correcció: treure aquesta dimensió i, si cal el desglossament, posar-lo com a propietat EMF, que és consultable amb Insights i no costa 0,30 USD per valor. Nota important per a l'examen mental: la factura de mètriques no baixa fins al mes següent, perquè les mètriques ja creades es facturen mentre rebin dades. No es poden esborrar; cal deixar de publicar-les.

I la prevenció de debò, a la política IAM del rol —el patró de 04-01—:

Això no limita la cardinalitat —IAM no pot—, però sí que impedeix que una aplicació creï espais de noms nous sense control, que és l'altra meitat del problema.

3. Logs Insights: 71 USD (11.200 execucions a 30 dies). 11.200 consultes escanejant volums enormes. Dues causes superposades: algú depurant amb la finestra en «30 dies» sense canviar-la, i molt probablement un giny de registre en un tauler obert en una pantalla que reexecuta la consulta cada vegada que es refresca.

Correcció: reduir la finestra per defecte dels ginys de registre, posar un limit baix, i establir la norma de començar sempre per 15 minuts. Com que el grup baixa de 620 GB a ~8 GB en arreglar el punt 1, aquesta partida cau sola en més d'un 95 %.

4. Synthetics: 27 USD. canario-mercadofresco-admin cada minut són 43.200 execucions al mes. Per a un tauler d'administració que fan servir tres persones en horari d'oficina, és absurd.

Correcció:

De 43.200 a 2.880 execucions: de 51,84 a 3,46 USD. I si només importa en horari d'oficina, es pot programar amb una expressió cron en lloc de rate.

5. Alarmes i taulers: 4 USD. Correcte. No es toca.

Factura estimada després de les correccions:

Tres controls preventius:

1. Pressupost d'AWS Budgets filtrat per servei = CloudWatch, amb llindar de 60 USD i avís al 80 % a [email protected]. Detecta la desviació en dies, no a la factura del mes següent. Es veu al mòdul 11.
2. Regla d'AWS Config que marqui com a no conforme qualsevol grup de registres sense retentionInDays, amb remediació automàtica que li posi 30 dies. És exactament el cas d'ús de la lliçó 05-04.
3. Revisió al procés de desplegament: ningú no desplega codi que escriu registres nous sense que una altra persona revisi el volum estimat i el nivell de registre. És una casella a la revisió de codi, no una eina. El mòdul 8 la integra al pipeline.

I un quart, cultural, que és el que de debò funciona: ensenyar la factura. Quan el Luis va veure que els seus registres de depuració costaven 386 USD al mes —més que les instàncies EC2 que els generaven— no va tornar a deixar DEBUG activat.

MercadoFresco ja té una mirada. Saps que CloudWatch són tres coses —mètriques, registres i alarmes— i saps què no és: ni el registre de qui ha cridat l'API (CloudTrail, 05-03), ni el rastrejador de peticions (X-Ray, 05-02), ni l'avaluador de compliment (Config, 05-04), ni el bus d'esdeveniments (EventBridge, 07-03).

Domines el model de mètriques: espai de noms, nom i dimensions, amb la regla d'or que cada combinació de dimensions és una mètrica facturable i que un identificador en una dimensió és l'error més car d'aquest servei. Saps triar l'estadística —Sum per a comptadors, Average per a utilització, p95/p99 sempre per a latència— i per què la mitjana de 0,17 s amagava que deu clients per minut esperaven nou segons per pagar. Coneixes la retenció automàtica que agrega les dades a 5 minuts després de 15 dies, i la taula de les mètriques que de debò decideixen alguna cosa a cada servei que has muntat, amb la diferència crítica entre HTTPCode_ELB_5XX_Count i HTTPCode_Target_5XX_Count.

Has publicat les mètriques de negoci PedidosConfirmados i TiempoConfirmacionPedido a MercadoFresco/Tienda, primer amb PutMetricData directe i després per lots des d'un fil a part per treure la crida de la ruta crítica d'una compra. Saps per què EC2 no publica memòria —l'hipervisor no veu dins del sistema operatiu convidat— i has desplegat l'agent unificat a lt-mercadofresco-tienda amb la seva configuració a Parameter Store, les seves append_dimensions resoltes soles i el seu retention_in_days posat des del primer dia. I coneixes l'Embedded Metric Format, que a Lambda et dona mètriques gratis a la ruta crítica i —això és el més important— et permet desar la clau d'S3 i l'ID de petició al costat de la mètrica sense pagar cardinalitat.

En registres, has centralitzat el que es podia centralitzar i saps el que no: els accessos de l'ALB i de CloudFront viuen a S3 i es consulten amb Athena. Tens la política de retenció per grup, la classe Infrequent Access per als flow logs, i les consultes de Logs Insights que responen preguntes reals —els bloquejos de WAF per regla, el p99 d'una Lambda amb @duration, els rebuigs al port 5432, i parse amb expressió regular per al programari que no registra en JSON—. I, sobretot, has respost la pregunta de la comanda de vuit segons: quatre grups de registres consultats alhora amb un identificador de correlació, una cronologia muntada esdeveniment a esdeveniment, i el culpable identificat —7.402 ms dins de PostgreSQL, un patró N+1 amb 39 consultes per a una comanda de 38 productes—.

Saps convertir un patró de registre en mètrica amb un filtre de mètriques (i per què defaultValue=0 no és opcional), i treure registres amb subscripcions en temps real o exportació a S3.

En alarmes, domines el que separa una alarma útil d'una font de soroll: la combinació «M de N» amb --datapoints-to-alarm 2 --evaluation-periods 3, el tractament de dades absents —amb breaching per a les mètriques l'absència de les quals és l'incident, com PedidosConfirmados—, les alarmes compostes que converteixen tres SMS en un i que exigeixen treure les accions de les filles, i la detecció d'anomalies que sap que 0 comandes a les 4 de la matinada és normal i a les 19:00 és una catàstrofe. Has muntat vuit alarmes noves —que se sumen a les dels mòduls 2 i 4 fins a tretze en total—, la composta mercadofresco-tienda-degradada i el detector d'anomalies sobre PedidosConfirmados.

I has respost la primera pregunta que va deixar oberta el mòdul 4, que era la més incòmoda de totes: l'avís arriba de debò. Has comprovat les subscripcions buscant el temut PendingConfirmation, has subscrit el correu i el telèfon de guàrdia, i has fet el simulacre amb set-alarm-state, que dispara les accions reals sense tocar la mètrica. I saps que la cadena inclou el telèfon: el «no molestar» d'un mòbil ha silenciat més alarmes que qualsevol error de configuració d'AWS.

Tot això es veu junt al tauler mercadofresco-produccion, ordenat de dalt a baix —negoci, components, detall—, amb les mètriques de CloudFront al seu giny d'us-east-1, les línies d'anotació que ensenyen com de prop estàs del llindar abans que salti, i el giny de registre amb els últims errors. I amb el canari canario-mercadofresco-compra recorrent la botiga cada cinc minuts perquè un diumenge de matinada, sense ni un sol client real, algú continuï comprovant que es pot comprar. Tot plegat per uns 44 USD al mes, amb les cinc maneres de disparar aquesta xifra identificades i la retenció posada el mateix dia que es crea cada grup.

Queda, però, una insatisfacció concreta. La investigació de la comanda de vuit segons va funcionar, però va costar quatre consultes, una cronologia muntada a mà en un full de càlcul, i va dependre per complet que algú s'hagués recordat de propagar la capçalera X-Peticion-Id per tots els components. Si demà el coll d'ampolla és dins de la Lambda, o a la crida a la passarel·la de pagament, o al temps de connexió a la base de dades, caldrà repetir la feina sencera i endevinar un altre cop on mirar.

Existeix una eina que fa aquesta feina sola, que dibuixa la cronologia en un gràfic i que diu, per a una petició concreta, quant va trigar cada tram del recorregut: AWS X-Ray. A la lliçó 05-02, «AWS X-Ray i traçabilitat distribuïda», veurem què és una traça, un segment i un subsegment, com es propaga l'identificador amb X-Amzn-Trace-Id, per què no es tracen totes les peticions i com es configura el mostreig, com instrumentar la botiga amb aws_xray_sdk i activar el rastreig a mercadofresco-estado-pedido amb una casella i un permís, com llegir el mapa de serveis i cercar amb filtres com annotation.pedido_id, i tornarem a aquesta mateixa comanda de 8,14 segons per veure-la, aquesta vegada, en un sol gràfic.