Les dues lliçons anteriors et van donar la vista de la infraestructura: quanta CPU consumeix el VMSS, quants errors 5xx retorna el web, quins registres ha escrit cada recurs. Això respon a «està sa, el sistema?», però no a «què li va passar al passatger del localitzador XR7742?». Entre totes dues preguntes hi ha un salt: la infraestructura pot estar perfecta i el passatger continuar sense la seva targeta d'embarcament.

Application Insights cobreix aquest buit. És la part d'Azure Monitor que observa l'aplicació des de dins: cada petició amb la seva durada i el seu resultat, cada crida a la base de dades, cada excepció amb la seva pila, i —el que és decisiu— el fil que uneix tot això a través dels sis components pels quals passa una reserva. Aquesta lliçó t'ensenya a instrumentar-lo, a correlacionar-lo, a no arruïnar-te amb el volum i a extreure'n dades de negoci, no només tècniques.

1. Què afegeix sobre les mètriques d'infraestructura
2. El model de telemetria
3. Instrumentació: automàtica, SDK i recurs basat en àrea de treball
4. Correlació distribuïda: el fil que uneix la reserva
5. Mapa de l'aplicació, transaccions i cerca en directe
6. Rendiment, dependències i errors
7. Mostreig: imprescindible i traïdor
8. Telemetria personalitzada, inicialitzadors i processadors
9. Proves de disponibilitat
10. Detecció intel·ligent i alertes d'aplicació
11. Consultar la telemetria amb KQL i controlar el cost
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

La diferència de fons és el subjecte de la mesura. Les mètriques de plataforma mesuren recursos; Application Insights mesura operacions de negoci i usuaris. Per això pot dir «el 3,2 % dels intents de compra falla al pas d'emissió de targeta, i afecta 148 passatgers diferents en l'última hora», una frase que cap mètrica de CPU no pot formular.

Tot el que Application Insights recull encaixa en uns pocs tipus. Conèixer-los és imprescindible perquè cadascun té la seva taula a log-contoso-pro, el seu cost i el seu paper en la investigació.

La distinció clau, i la que més es confon: una petició és feina entrant, una dependència és feina sortint. La mateixa crida HTTP entre el web i l'API apareix dues vegades: com a dependència al web i com a petició a l'API. Correlacionar-les totes dues és el que permet veure el recorregut complet.

Hi ha dues maneres d'instrumentar, i no són excloents:

La recomanació pràctica és començar per l'automàtica a tot arreu, i afegir l'SDK només on necessitis telemetria de negoci o control fi.

Abans de res, el recurs. Contoso fa servir un recurs basat en àrea de treball, que envia tota la telemetria a log-contoso-pro. És el que va fer possible l'apartat 7 de la lliçó anterior: les taules App* conviuen amb AzureDiagnostics i AzureActivity, i es poden creuar en una consulta. Els recursos clàssics, no basats en àrea, guardaven les dades a part i estan retirats.

Sobre la cadena de connexió: substitueix l'antiga clau d'instrumentació i no és opcional, perquè a més de l'identificador porta els punts de connexió regionals d'ingesta. Conté un identificador, no una credencial d'accés a dades, però continua sent un valor de configuració: a Contoso viu a kv-contoso-pro i arriba a l'aplicació per referència de Key Vault, com qualsevol altre ajust (mòdul 4).

Els altres dos casos de Contoso:

A cae-contoso-pro convé distingir dues coses que se superposen: l'entorn de Container Apps ja envia registres i mètriques del sistema a log-contoso-pro, mentre que Application Insights aporta les peticions, dependències i correlació de l'aplicació. Es complementen i tots dos són necessaris per seguir la reserva de punta a punta.

Aquest és el cor de la lliçó i la resposta al problema que va obrir el mòdul. Quan un passatger compra, hi intervenen sis components. Sense correlació, cadascun genera telemetria aïllada i no hi ha manera de saber què pertany a quina compra.

La solució és el context de traça del W3C, un estàndard que Azure implementa: cada crida sortint porta una capçalera traceparent amb el format 00-<trace-id>-<span-id>-<flags>. El receptor la llegeix, la propaga a les seves pròpies crides i etiqueta amb ella tota la seva telemetria. A les taules de Log Analytics això apareix com tres columnes:

• OperationId: identifica l'operació completa de negoci. És el mateix valor als sis components.
• Id: identifica el tram concret, únic per component.
• ParentId: apunta al tram que el va provocar, i és el que construeix l'arbre.

El pas fràgil és el de la cua. HTTP propaga traceparent tot sol; els missatges no, llevat que l'emissor l'escrigui com a propietat del missatge i el consumidor el llegeixi. Els SDK moderns de Service Bus ho fan automàticament, però una cua d'Azure Storage com cola-emision-tarjetas requereix fer-ho a mà. Si el rastre es talla a la cua, el mapa es parteix en dos i tornes a la situació de partida. Comprovar-ho és el primer pas de qualsevol implantació:

Un percentatge alt d'execucions sense ParentId significa exactament això: correlació trencada al salt asíncron.

Sobre aquesta correlació es construeixen tres eines que es fan servir cada dia:

• Mapa de l'aplicació: un graf generat automàticament amb tots els components, les seves crides, el volum, la latència mitjana i el percentatge d'error de cada aresta. Revela tres coses que ningú no havia dibuixat: dependències que no sabies que existien, la que realment va lenta, i components que ja no crida ningú. A Contoso va destapar que el web consultava cosmos-contoso-tarifas-pro dues vegades per reserva per una fallada de memòria cau.
• Transaccions d'extrem a extrem: en clicar una petició concreta, la línia de temps en cascada de tot el que va passar, amb la durada de cada tram. Una petició de 4,2 segons es descompon en 120 ms del web, 3,8 s esperant sql-contoso-reservas-pro i 280 ms de serialització: el culpable queda a la vista sense conjectures.
• Cerca en directe (Live Metrics): telemetria amb latència d'un segon i sense mostreig, que a més no s'emmagatzema i per tant no es factura com a ingesta. És l'eina del desplegament: en Diego publica a la ranura preproduccion, intercanvia, i observa en directe peticions, errors i dependències durant els dos minuts crítics. Si alguna cosa es dispara, reverteix abans que una alerta arribi a avaluar-se.

El tauler de rendiment ordena les operacions per durada i permet veure la distribució completa, no només la mitjana. La lectura correcta és sempre per percentils: si la p50 és de 180 ms i la p95 de 3.400 ms, no tens un problema de rendiment general, tens un problema amb un subconjunt de peticions —normalment, les d'un cas d'ús concret o les que topen amb un bloqueig.

El desglossament de dependències és on sol ser la resposta. La regla empírica: en aplicacions de negoci, el 80 % de la latència és fora del teu codi, a la base de dades o en un servei extern. El tauler d'errors complementa amb els codis de resposta fallits, les excepcions més freqüents i les dependències que fallen.

Una aplicació amb trànsit real genera un volum de telemetria que no té sentit emmagatzemar íntegre. El mostreig conserva una fracció dels elements i anota quants en representa cadascun.

Dues propietats que cal entendre bé. Primera: el mostreig és coherent per operació. Si es conserva una petició, es conserven també les seves dependències, traces i excepcions; mai no veuràs una traça òrfena. Segona, i aquí hi ha el parany: cada element conservat porta un camp ItemCount amb el nombre d'elements que representa. Les vistes del portal l'apliquen soles, però les teves consultes KQL no:

Amb un mostreig del 20 %, la primera consulta retorna 2.000 i la realitat són 10.000. Aquesta discrepància entre el tauler i una consulta pròpia és una de les confusions més habituals, i es resol amb sum(ItemCount). A Contoso, el mostreig adaptatiu està actiu al web amb un objectiu de cinc elements per segon, i desactivat a func-contoso-tarjetas-pro, perquè el seu volum és baix i cada execució importa individualment. Les excepcions s'exclouen sempre del mostreig.

Aquí és on Application Insights deixa de ser una eina tècnica i comença a respondre preguntes de negoci. L'esdeveniment ReservaConfirmada que vas fer servir a KQL surt d'aquí:

Tres decisions deliberades en aquest codi. Les propietats són cadenes i serveixen per filtrar i agrupar (by canal); les mètriques són números i serveixen per agregar (avg(importe)). El localizador s'inclou perquè és la clau de la investigació, i no és una dada personal: identifica una reserva, no una persona. I no hi apareix ni el nom del passatger, ni el seu correu, ni el seu document d'identitat; això és intencionat i ho reforça el bloc següent.

Els inicialitzadors de telemetria afegeixen context a tot el que s'envia; els processadors filtren o modifiquen abans de l'enviament:

Aquest processador fa dues feines diferents i totes dues importen. La primera és de cost: descartar els sondejos a /salud, que a Contoso eren el 46 % de les peticions registrades. La segona és de compliment, i convé dir-ho sense embuts: la telemetria d'aplicació és una destinació habitual de fuites de dades personals, perquè una consulta SQL registrada o un missatge d'excepció poden portar a dins un correu o un document d'identitat. Sota el RGPD, això converteix log-contoso-pro en un magatzem de dades personals, amb les seves obligacions de base legal, minimització, termini de conservació i dret de supressió —i esborrar selectivament a Log Analytics és lent i limitat—. La regla de Contoso és taxativa: les dades personals s'eliminen abans de sortir del procés, al processador, mai després. Identificadors de negoci com el localitzador, sí; identitats de persones, no.

Les proves de disponibilitat són sondejos sintètics llançats des de diverses regions. Alimenten la primera alerta de la taula de 07-01 i detecten el que cap registre no pot: que l'aplicació està bé però el DNS, el certificat o l'encaminament de fd-contoso-global no.

Tres regles de disseny. Fes servir almenys cinc ubicacions i exigeix que en fallin tres abans d'alertar: amb una sola ubicació, un problema de xarxa local genera falses alarmes. Comprova el contingut, no només el codi 200 —una pàgina d'error personalitzada retorna 200 perfectament—. I valida la caducitat del certificat, que és exactament el cas que va causar l'incident de la targeta no emesa.

La detecció intel·ligent analitza la telemetria automàticament i avisa d'anomalies sense configurar llindars: augment anormal de la taxa d'errors, degradació de latència respecte a la línia base, fuites de memòria, o un patró d'excepcions que comença just després d'un desplegament. És útil pel que descobreix sense que ningú ho hagués demanat, però no substitueix les alertes explícites: no coneix els teus SLO ni la teva criticitat de negoci. Tracta-la com una segona opinió i dirigeix-la al grup ag-equipo-contoso, no al de guàrdia.

Les alertes explícites d'aplicació de Contoso, sobre les mètriques d'Application Insights: latència p95 de l'API per sobre de 800 ms, taxa de peticions fallides superior al 2 %, temps de resposta de la dependència sql-contoso-reservas-pro per sobre d'1 segon, i la disponibilitat de /salud. Totes construïdes amb el que has après a 07-01 i apuntant als grups d'accions ja definits.

Com que el recurs està basat en àrea de treball, tot l'anterior es consulta amb KQL a log-contoso-pro. Un exemple que combina el que has après:

Fixa't en l'ús sistemàtic de sum(ItemCount) en lloc de count() pel mostreig, en Measurements per a les mètriques de l'esdeveniment davant de Properties per a les cadenes, i en el join kind=leftouter explícit. El resultat és una taula que la Nuria Peña entén: quantes reserves i quants euros per canal, i quin percentatge s'està perdent.

Sobre el cost, l'advertència de 07-02 s'aplica íntegra, perquè la telemetria es factura com qualsevol altra ingesta a Log Analytics. Les palanques específiques d'Application Insights, en ordre d'impacte: mostreig adaptatiu actiu als serveis de gran volum; filtratge de sondejos d'estat i peticions a recursos estàtics al processador; desactivar les traces de nivell de depuració en producció, que és l'error més car i més freqüent; i retenció per taula, amb AppTraces a 30 dies i AppEvents a més temps pel seu valor de negoci. Amb aquestes quatre mesures Contoso va reduir el volum un 60 % sense perdre capacitat d'investigació.

• Comptar sense ItemCount. Amb mostreig actiu, count() infravalora sistemàticament. Fes servir sum(ItemCount).
• Correlació trencada a la cua. Si el traceparent no viatja al missatge, el rastre es parteix. Comprova-ho amb el percentatge de peticions sense ParentId.
• Registrar dades personals. Correus i documents acaben a les traces i a les consultes registrades. Filtra'ls al processador, abans de l'enviament.
• Deixar el nivell de depuració en producció. La causa número u de factures de telemetria desbocades.
• Prova de disponibilitat des d'una sola ubicació. Genera falses alarmes; fes-ne servir cinc i exigeix que en fallin tres.
• Confiar només en la detecció intel·ligent. No coneix els teus SLO; complementa, no substitueix.
• Consell: fixa Cloud.RoleName en un inicialitzador. Sense això, el mapa de l'aplicació mostra noms genèrics i deixa de ser llegible.
• Consell: emet esdeveniments de negoci des del primer dia. Instrumentar el que és tècnic es pot afegir després; reconstruir un històric de negoci que no es va capturar, no.
• Consell: fes servir la cerca en directe a cada desplegament. És gratuïta, no es mostreja i dona dos minuts d'avantatge sobre qualsevol alerta.

Exercici 1. El web mostra al mapa de l'aplicació una latència mitjana de 2,3 s cap a sql-contoso-reservas-pro, però el tauler de mètriques de la base de dades indica un ús de DTU del 35 % i cap consulta lenta registrada. Explica les causes possibles i com distingir-les amb les eines d'aquesta lliçó.

Exercici 2. En Diego ha instrumentat func-contoso-tarjetas-pro i en veu les execucions, però en fer servir SeguirLocalizador("XR7742") de 07-02 la funció no apareix a la línia de temps. Diagnostica el problema i descriu-ne la solució.

Exercici 3. L'equip de Contoso Millas (centro-coste=CC-2077) vol mesurar quants socis bescanvien punts, l'import mitjà del bescanvi i quin percentatge abandona a mitja tramitació. Dissenya la instrumentació completa, incloent-hi la consulta KQL i les precaucions de privacitat i cost.

Solució 1: hi ha tres causes possibles i es distingeixen bé. (a) El temps no és a la base de dades sinó a arribar-hi: esgotament del grup de connexions, resolució DNS o latència de xarxa. S'identifica perquè a les transaccions d'extrem a extrem la dependència dura molt però la consulta executada és trivial, i perquè AppDependencies mostra durada alta amb Success == true. (b) Bloquejos i esperes: la consulta és ràpida però espera una altra transacció; l'ús de DTU és baix precisament perquè ningú no treballa, tots esperen. Es confirma amb els registres de Deadlocks i Timeouts de la configuració de diagnòstic de SQL (07-01). (c) Una mitjana enganyosa: unes poques consultes molt lentes eleven la mitjana del mapa. Es descarta consultant AppDependencies amb percentile(DurationMs, 50) i percentile(DurationMs, 95) agrupat per Data: si la p50 és baixa i la p95 altíssima, el problema afecta una consulta concreta i no el conjunt. L'ordre d'investigació és sempre aquest: primer percentils, després transaccions d'extrem a extrem d'un cas lent concret, i només llavors mirar la base de dades.

Solució 2: la correlació s'ha trencat al salt asíncron. El web escriu a cola-emision-tarjetas, que és una cua d'Azure Storage i no propaga automàticament el context de traça del W3C, a diferència d'HTTP o de Service Bus. La funció engega, per tant, una operació nova, amb el seu propi OperationId, i SeguirLocalizador —que filtra per OperationId == op— no la troba. Diagnòstic: la consulta de peticions sense ParentId de l'apartat 4 retornarà a prop del 100 % per a aquesta funció. Solució: incloure el traceparent com a propietat del missatge en encuar i, a la funció, iniciar l'activitat amb aquest context com a pare abans d'emetre telemetria. Comprovació: després del canvi, el mapa de l'aplicació ha de mostrar l'aresta de la cua cap a la funció, i la línia de temps d'extrem a extrem ha d'arribar fins a GenerarTarjetaEmbarque. Com a xarxa de seguretat mentrestant, afegir el localizador com a propietat a tota la telemetria de la funció permet localitzar-la per aquest camp encara que la correlació falli.

Solució 3: instrumentació amb tres esdeveniments personalitzats —CanjeIniciado, CanjeConfirmado i CanjeAbandonado—, tots amb les propietats idCanje (un identificador propi, no el número de soci), tipoPremio, paso i entorno, i les mètriques puntos i importeEquivalente. L'embut es calcula amb AppEvents | where Name startswith "Canje" | summarize Total = sum(ItemCount) by Name, i l'abandonament com 1 - Confirmados/Iniciados; l'import mitjà, amb summarize avg(todouble(Measurements["importeEquivalente"])) sobre els confirmats, ponderant sempre per ItemCount. Privacitat: no s'emet el número de soci, ni el seu nom, ni el seu correu; es fa servir un identificador de bescanvi sense significat extern, i el processador de telemetria emmascara qualsevol correu que es coli en traces o dependències, segons el RGPD i la política de la lliçó. Cost: mostreig adaptatiu desactivat si el volum de bescanvis és baix —convé conservar cada esdeveniment—, però traces de depuració desactivades i sondejos d'estat filtrats; retenció d'AppEvents àmplia pel seu valor de negoci i AppTraces a 30 dies. Etiquetes del recurs: entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario.

Ja saps què afegeix Application Insights sobre les mètriques d'infraestructura: canvia el subjecte de la mesura, de recursos a operacions de negoci i usuaris. Coneixes el seu model de telemetria —petició, dependència, excepció, traça, esdeveniment personalitzat, mètrica personalitzada, visualització de pàgina i disponibilitat—, cadascun amb la seva taula, i la distinció que més es confon: petició és feina entrant, dependència és feina sortint. Saps instrumentar sense codi i amb SDK, i per què Contoso fa servir un recurs basat en àrea de treball que envia tot a log-contoso-pro, unificant aquesta lliçó amb l'anterior; l'has activat a app-contoso-reservas-pro, a func-contoso-tarjetas-pro i als contenidors de cae-contoso-pro, amb la cadena de connexió guardada a kv-contoso-pro.

El centre de la lliçó era la correlació distribuïda: el context de traça del W3C, OperationId, Id i ParentId, i el punt fràgil del salt asíncron per la cua, que és exactament on es partia el rastre de la reserva que va obrir el mòdul. Sobre aquesta correlació has vist el mapa de l'aplicació, les transaccions d'extrem a extrem que descomponen una petició lenta tram a tram, i la cerca en directe per vigilar un desplegament en viu i sense cost. Domines el mostreig —adaptatiu, fix i d'ingesta—, per què és imprescindible i el parany d'ItemCount que fa que les teves consultes comptin de menys. Has emès telemetria personalitzada de negoci en C#, i has escrit un inicialitzador que enriqueix i un processador que filtra sondejos i elimina dades personals abans que surtin del procés, amb l'advertència del RGPD que això comporta. I tanques amb proves de disponibilitat des de diverses ubicacions, detecció intel·ligent com a segona opinió, les alertes d'aplicació i el control del cost amb les quatre palanques que van reduir el volum de Contoso un 60 %.

Amb això, la plataforma de Contoso és per fi observable: una queixa es converteix en una consulta, i una consulta en una causa arrel. Però observar no és operar. Cada matí algú encén els entorns de desenvolupament i cada nit algú els hauria d'apagar; hi ha instantànies velles que ningú no neteja, credencials per rotar, informes per generar i servidors per apedaçar, i tot això continua consumint les hores de l'equip de la Marta Ríos. La lliçó 07-04, Azure Automation i runbooks, s'ocupa d'aquesta feina repetitiva: comptes d'Automation amb identitat administrada, runbooks en PowerShell amb les seves programacions i els seus actius, Hybrid Runbook Worker per actuar sobre l'oficina de Barcelona, disparar un runbook des d'una alerta d'Azure Monitor —tancant el cercle amb 07-01— i Azure Update Manager per a l'apedaçament.