Contoso Airlines té avui una plataforma repartida entre aplicacions web, una API en un conjunt d'escalat, contenidors, funcions efímeres, cues, temes, bases de dades i serveis d'IA. Quan alguna cosa va malament, la pregunta ja no és «està caigut el servidor?», sinó «quina part d'aquesta cadena està fallant, des de quan, per a quants passatgers i per què». Respondre-hi exigeix que el sistema emeti informació i que algú l'hagi recollida abans que passés el problema. Aquesta és la disciplina que obre el mòdul.

Aquesta lliçó és el mapa. Entendràs què és l'observabilitat i les seves tres senyals, com Azure Monitor les agrupa totes sota un mateix paraigua, com es configuren les mètriques de plataforma i la peça que gairebé tothom oblida —la configuració de diagnòstic—, i com es construeix un sistema d'alertes que desperta algú només quan val la pena. Tot sobre els recursos reals de Contoso.

1. Observabilitat: tres senyals, no una alerta de CPU
2. Azure Monitor com a paraigua
3. Mètriques de plataforma i l'explorador de mètriques
4. Configuració de diagnòstic: la peça oblidada
5. Registre d'activitat, registres de recurs i registres del sistema operatiu
6. Alertes: tipus, condicions i llindars
7. Grups d'accions i regles de processament
8. El conjunt d'alertes de Contoso
9. SLI, SLO i pressupost d'error
10. Taulers i llibres
11. Cost del monitoratge
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

Monitorar és comprovar que uns indicadors coneguts continuen dins de rang. L'observabilitat és la propietat d'un sistema que permet respondre a preguntes que ningú no havia previst, sense desplegar codi nou. La diferència importa: una alerta de CPU al 90 % és monitoratge, i no hauria dit absolutament res sobre el passatger que va pagar i no va rebre la seva targeta d'embarcament.

Les tres senyals clàssiques:

La regla pràctica: les mètriques detecten, els registres expliquen, les traces localitzen. Un sistema que només té mètriques sap que alguna cosa va malament i no sap què. Un que només té registres paga una fortuna i busca a cegues. Contoso necessita les tres, i cadascuna té la seva lliçó en aquest mòdul.

Azure Monitor no és un producte: és el nom del conjunt. Convé veure el mapa complet des del principi per saber on encaixa cada lliçó.

Tres idees del diagrama: hi ha dues plataformes de dades —mètriques i registres— amb preus, retencions i llenguatges de consulta diferents; les dades no arriben soles als registres, cal una configuració de diagnòstic o un agent, i aquest és l'oblit més freqüent; i els Insights (Application, Container, VM) no són magatzems separats, sinó experiències visuals muntades sobre aquestes mateixes dades.

Les mètriques de plataforma les emet Azure automàticament, sense configurar res i sense cost, per a gairebé tots els recursos. Les seves propietats:

• Granularitat d'un minut en la majoria de recursos, agregades després a intervals més grans.
• Retenció de 93 dies. Passat aquest termini desapareixen, llevat que les exportis a Log Analytics.
• Dimensions: atributs que permeten desglossar una mètrica. Http5xx d'un App Service es pot desglossar per instància; les peticions de Storage, per tipus d'API o per codi de resposta.
• Agregacions: mitjana, mínim, màxim, total i recompte. Triar malament l'agregació és l'error clàssic —la mitjana de latència d'una hora amaga el pic que va enfadar els passatgers.

Consulta des de la CLI el temps de resposta del web de reserves:

• --metric accepta diverses mètriques alhora; els seus noms són els interns, no els del portal. Per descobrir-los: az monitor metrics list-definitions --resource "$APP_ID".
• --interval PT5M és notació ISO 8601 de durada: 5 minuts. PT1H seria una hora.
• --aggregation demana les tres agregacions per poder comparar mitjana i màxim a la mateixa taula.

Al portal, l'explorador de mètriques fa el mateix de manera visual: tries recurs, mètrica, agregació, i hi afegeixes una divisió per dimensió. El flux típic de la Marta Ríos davant d'una queixa de lentitud és: HttpResponseTime en mitjana i en percentil, dividit per instància. Si només una instància va lenta, és un problema d'aquella instància; si ho estan totes, el problema és al darrere —normalment a sql-contoso-reservas-pro.

Les mètriques de plataforma existeixen soles. Els registres de recurs, no. Un App Service no envia enlloc els seus registres HTTP, ni SQL Database les seves consultes lentes, ni Key Vault qui va accedir a què, fins que crees una configuració de diagnòstic que digui quines categories s'exporten i cap a on. És habitual descobrir-ho el dia de l'incident, quan ja és tard: els registres no existeixen retroactivament.

Cada tipus de recurs publica les seves pròpies categories. Exemples reals:

I tres destinacions possibles, combinables:

Crear la configuració de diagnòstic del web de reserves:

Dos paràmetres mereixen atenció. --export-to-resource-specific true fa que les dades aterrin en taules dedicades (AppServiceHTTPLogs) en lloc de a la taula genèrica AzureDiagnostics; és millor esquema, millor rendiment i permet plans de taula diferents, i ho aprofitaràs a 07-02. --metrics AllMetrics duplica les mètriques de plataforma als registres: útil per correlacionar i conservar-les més enllà de 93 dies, però és ingesta que es paga, així que activa-ho només on ho necessitis.

Fer això recurs a recurs no escala. Per això Contoso ja té, dins de la iniciativa «Base de governança de Contoso» del mòdul 4, l'assignació diagnostico-app-service amb efecte DeployIfNotExists: qualsevol App Service nou rep automàticament la seva configuració apuntant a log-contoso-pro. El compliment es comprova amb az policy state summarize --resource-group rg-contoso-reservas-pro. La política és el que converteix «recorda't d'activar els diagnòstics» en una garantia. Recorda que DeployIfNotExists només actua sobre recursos nous o en executar una tasca de correcció sobre els existents.

Tres capes que es confonen constantment:

El registre d'activitat respon sempre a la pregunta «què va canviar just abans que es trenqués?», que resol una part notable dels incidents:

Per a les màquines virtuals, l'agent d'Azure Monitor substitueix els agents antics i no decideix pel seu compte què recollir: ho determina una regla de recopilació de dades (DCR), un recurs independent i reutilitzable que diu quins orígens es llegeixen, com es transformen i a quina àrea van. Aquesta separació permet canviar la recopilació de cent màquines editant un únic objecte: es crea la DCR dcr-contoso-servidores una vegada i s'associa a cada màquina amb az monitor data-collection rule association create.

Un detall de cost amb conseqüències: una DCR mal filtrada que reculli tot el syslog d'un servidor loquaç pot costar més que la mateixa màquina virtual. Les DCR admeten transformacions KQL en el moment de la ingesta per descartar l'irrellevant abans de pagar-lo; hi tornarem a 07-02.

Una alerta és una regla que avalua un origen de dades i, si es compleix la condició, dispara un grup d'accions. Els tipus disponibles:

Les d'estat del servei i estat del recurs són gratuïtes i gairebé ningú no les configura, tot i ser les que distingeixen «hem trencat alguna cosa» de «Azure té un problema a la regió». Configura-les sempre.

Sobre els llindars:

• Estàtic: tu fixes el número. Predictible i auditable. Adequat quan hi ha un compromís —l'SLO diu 800 ms, alertes a 800 ms.
• Dinàmic: Azure aprèn el patró històric, inclosa l'estacionalitat diària i setmanal, i alerta davant de desviacions. Ideal per a mètriques amb cicle natural: el trànsit d'app-contoso-reservas-pro cau de matinada, i un llindar estàtic de «menys de 100 peticions per minut» dispararia cada nit.

Dos paràmetres governen el soroll: la freqüència d'avaluació (cada quant es comprova) i la finestra d'agregació (quant temps s'agrega en cada comprovació). Avaluar cada minut sobre una finestra d'un minut dispara davant de qualsevol pic transitori. Contoso fa servir avaluació cada 5 minuts amb finestra de 15 per a la latència, i cada minut amb finestra de 5 per a la disponibilitat.

Un grup d'accions és la llista de a qui s'avisa i què s'executa. Es defineix una vegada i es reutilitza en totes les regles.

• --short-name (màxim 12 caràcters) és el que apareix com a remitent a l'SMS.
• useCommonAlertSchema força l'esquema comú d'alertes, un JSON amb la mateixa forma per a tots els tipus. Sense això, cada tipus d'alerta envia una càrrega diferent i el consumidor esdevé immantenible. Activa-ho sempre.

Els tipus d'acció disponibles: correu, SMS, notificació push, trucada de veu, correu a un rol d'Azure Resource Manager, webhook, webhook segur amb Entra ID, Logic App, Azure Function, runbook d'Automation i connector ITSM. Contoso fa servir tres grups:

Les regles de processament d'alertes actuen sobre les alertes ja generades, sense tocar les regles. Serveixen per a dues coses: silenciar durant una finestra de manteniment i afegir un grup d'accions a un conjunt d'alertes de cop.

Sense això, la nit del desplegament mensual l'equip rep quaranta SMS, i a la tercera vegada algú silencia el telèfon de guàrdia de manera permanent. El soroll no és una molèstia: és la manera com un sistema d'alertes es mor.

Aquesta és la taula real que manté la Marta, i el seu valor és tant en el que conté com en el que deliberadament no conté:

Fixa't en el que no hi ha: cap alerta de CPU, cap de memòria, cap de disc d'aplicació. No perquè no importin, sinó perquè són causes, no símptomes. Una CPU al 95 % amb la latència dins de l'objectiu i sense errors no és un problema: és una màquina ben aprofitada. Alertar sobre causes produeix despertades inútils i, pitjor, entrena l'equip a ignorar el telèfon. S'alerta sobre el que el passatger nota; les causes s'investiguen després, amb mètriques i registres, que per això hi són.

Una regla de mètrica per CLI, per fixar el patró (les etiquetes obligatòries també aquí: una regla d'alerta és un recurs facturable i s'ha d'atribuir a CC-1042):

Sense aquests tres conceptes, els llindars es trien per intuïció i es discuteixen per sempre.

• SLI (indicador de nivell de servei): la mesura concreta. «Percentatge de peticions a /api/disponibilidad respostes correctament en menys de 800 ms.»
• SLO (objectiu de nivell de servei): el valor compromès. «99,5 % mensual.»
• Pressupost d'error: el que l'SLO et permet fallar. Un 99,5 % mensual són 3 hores i 39 minuts d'incompliment.

El pressupost d'error converteix una discussió d'opinions en una d'aritmètica: si la primera setmana se n'ha consumit el 70 %, es congelen els canvis arriscats i l'esforç va a la fiabilitat; si a final de mes en sobra, es desplega amb més alegria. I respon a la pregunta incòmoda que la Nuria Peña farà al mòdul 8: passar del 99,5 % al 99,99 % no costa una mica més, costa multiplicar la infraestructura.

Dues eines que s'assemblen i no són el mateix:

El tauler d'operacions de Contoso viu en una pantalla del centre de control i mostra sis elements: disponibilitat del punt de salut, peticions per minut i latència p95 de l'API, errors 5xx del web, profunditat de cola-emision-tarjetas, DTU de db-reservas i alertes actives per gravetat. Res més: un tauler amb trenta gràfiques no el mira ningú. El llibre parametritzat «Salut de reserves» és, en canvi, l'eina d'investigació, amb tres paràmetres —interval, entorn i localitzador— que omplen les consultes KQL de la lliçó següent; la mateixa plantilla serveix per a producció i desenvolupament canviant un desplegable, i es versiona al repositori contoso-infra al costat de les plantilles Bicep. Les proves de disponibilitat que alimenten la primera alerta de la taula pertanyen a Application Insights i s'expliquen a 07-03.

Un avís que convé interioritzar ja, encara que el detall arribi a 07-02: la ingesta i la retenció de dades a Log Analytics és una de les factures d'Azure que més sorprèn. Res no t'avisa que has deixat activats els registres de depuració en producció; simplement, a final de mes la línia de Log Analytics és la més gran de la subscripció. Contoso ho va viure: activar AppServiceConsoleLogs a les quatre aplicacions durant una investigació i oblidar-se de desactivar-lo va costar més que el pla d'App Service que ho generava.

Dues conseqüències pràctiques: una alerta de registres avaluada cada minut en cinquanta recursos és una factura considerable, així que ajusta la freqüència al que realment necessites detectar; i les alertes amb destinació SMS convé reservar-les per a gravetats 0 i 1, que és justament el que fa ag-guardia-contoso.

• Creure que els registres existeixen sense configuració de diagnòstic. El dia de l'incident descobreixes que no hi ha res, i els registres no apareixen retroactivament. Activa'ls amb política, no a mà.
• Alertar sobre causes. CPU, memòria i disc generen soroll; alerta sobre símptomes visibles per al passatger.
• Triar malament l'agregació. La mitjana amaga els pics. Per a latència, percentils; per a errors, totals.
• No configurar les alertes gratuïtes. Estat del servei i estat del recurs no costen res i eviten investigar durant una hora un problema que és d'Azure.
• Finestres d'avaluació massa curtes o manteniment sense silenciar. Totes dues produeixen soroll previsible, i el soroll mata la credibilitat del sistema: fes servir regles de processament d'alertes.
• Consell: defineix l'SLO abans que el llindar. Si no saps què has promès, qualsevol número és discutible.
• Consell: tota alerta ha de portar a la seva descripció un enllaç al procediment d'actuació; una alerta a les 3 de la matinada sense instruccions és una alerta a mitges. I revisa trimestralment quines s'han disparat i què se n'ha fet: les que mai no han portat a una acció, s'esborren.

Exercici 1. Contoso vol vigilar la nova API pública de «Contoso Millas» (centro-coste=CC-2077), desplegada en un App Service de rg-contoso-reservas-dev. Defineix: quines senyals activaries, amb quina configuració de diagnòstic, tres alertes amb la seva gravetat i grup d'accions, i una decisió de cost justificada.

Exercici 2. Durant dues setmanes l'equip ha rebut 340 alertes i ha actuat sobre 6. Analitza què està passant, proposa quatre mesures concretes i explica el risc de no fer res.

Exercici 3. El negoci demana per a db-reservas un SLO de disponibilitat del 99,99 %. Calcula el pressupost d'error mensual, indica què implica tècnicament i quina contraproposta faries.

Solució 1:

• Senyals i diagnòstic: mètriques de plataforma (gratuïtes, ja existeixen); registres de recurs via configuració de diagnòstic amb AppServiceHTTPLogs i AppServiceAppLogs —no AppServiceConsoleLogs, que és el que dispara la factura— cap a log-contoso-pro amb --export-to-resource-specific true i retenció curta per ser un assaig; i traces amb Application Insights (07-03). Si l'assignació diagnostico-app-service arriba a rg-contoso-reservas-dev, la configuració es desplega sola: convé verificar-ho.
• Alertes: (1) estat del recurs, gravetat 1, ag-guardia-contoso, gratuïta; (2) Http5xx > 25 en 5 min, gravetat 2, ag-equipo-contoso, perquè un projecte secundari no justifica despertar ningú; (3) HttpResponseTime amb llindar dinàmic, gravetat 3, ag-registro-contoso, perquè encara no hi ha línia base coneguda.
• Cost: notificacions per correu, sense SMS, i avaluació cada 15 minuts en lloc de cada minut. Etiquetes entorno=desarrollo, proyecto=contoso-millas, centro-coste=CC-2077, propietario.

Solució 2: la ràtio és d'1 acció per cada 57 avisos: el sistema ha deixat de ser informatiu i l'equip ja ha après a ignorar-lo. Causes habituals: alertes sobre causes (CPU, memòria), finestres d'avaluació d'un minut que capturen pics transitoris, absència de silenciament durant desplegaments i manteniment, i una mateixa incidència que dispara deu regles alhora. Mesures: (1) eliminar tota alerta que no hagi provocat una acció en tres mesos; (2) ampliar finestres d'agregació a 15 minuts en mètriques sorolloses i passar a llindars dinàmics on hi ha estacionalitat; (3) crear regles de processament d'alertes per a les finestres de desplegament i manteniment; (4) reassignar gravetats perquè només 0 i 1 facin servir SMS, deixant la resta en correu o incidència. El risc de no actuar és concret: la propera caiguda real arribarà com l'avís número 341 i ningú no el mirarà.

Solució 3: el 99,99 % mensual deixa 4 minuts i 23 segons de pressupost d'error al mes —menys del que triga una commutació per error manual—. Tècnicament implica commutació automàtica amb fg-contoso-reservas, un nivell de servei amb l'SLA corresponent, redundància de zona, reintents amb lògica de reconnexió a l'aplicació i desplegaments sense temps d'inactivitat, a més que l'SLA d'Azure per a un únic servidor lògic ja no basta. Contraproposta raonable: 99,95 % per a la base de dades (21 minuts i 54 segons de pressupost) combinat amb un SLO d'experiència —«el passatger pot consultar la seva reserva»— recolzat en una memòria cau de només lectura durant la commutació. Costa una fracció i protegeix el que el negoci realment valora. I, a més, el compromís s'ha de mesurar sobre un SLI acordat, no sobre la disponibilitat declarada pel proveïdor.

Ja tens el mapa complet. Saps que l'observabilitat es recolza en tres senyals —mètriques per detectar, registres per explicar, traces per localitzar— i que Azure Monitor és el paraigua que agrupa les dues plataformes de dades, les experiències d'Insights i el consum mitjançant alertes, llibres i taulers. Coneixes les mètriques de plataforma, gratuïtes, amb granularitat d'un minut i 93 dies de retenció, les seves dimensions i agregacions, i com explorar-les sobre app-contoso-reservas-pro. I, sobretot, domines la peça que gairebé tothom oblida: la configuració de diagnòstic, les seves categories per tipus de recurs, les seves tres destinacions i el seu desplegament a escala mitjançant l'assignació diagnostico-app-service amb DeployIfNotExists.

Distingeixes el registre d'activitat —qui va canviar què— dels registres de recurs i dels del sistema operatiu, recollits per l'agent d'Azure Monitor amb les seves regles de recopilació de dades. Has vist els cinc tipus d'alerta, incloses les gratuïtes que gairebé ningú no activa, els llindars estàtics davant dels dinàmics i el paper de la freqüència d'avaluació; has creat ag-guardia-contoso amb l'esquema comú d'alertes i saps silenciar el manteniment amb regles de processament. El conjunt d'alertes de Contoso t'ha ensenyat la regla que sosté tota la resta —alertar sobre símptomes, mai sobre causes—, amb SLI, SLO i pressupost d'error com a criteri per triar llindars en lloc de discutir-los, i amb taulers i llibres parametritzats com a superfície de consulta. I t'endus l'advertència de cost: mètriques i alertes de plataforma són gairebé de franc, els SMS es paguen i la ingesta de registres és la partida que sorprèn.

Precisament cap allà va la lliçó següent. Tot el que has enviat amb les configuracions de diagnòstic ha aterrat a log-contoso-pro, i fins ara només ho has emmagatzemat. A 07-02, Log Analytics i consultes KQL, aprendràs a interrogar-lo: les taules que t'hi trobaràs, el llenguatge KQL des de zero i explicat línia a línia, el recorregut complet per investigar la queixa del passatger que va pagar i no va rebre la seva targeta d'embarcament, i les tres palanques —què s'ingereix, en quin pla i quant de temps es guarda— amb què es controla aquesta factura que acabem d'anunciar.