A la lliçó anterior vas configurar les configuracions de diagnòstic i tot va començar a fluir cap a log-contoso-pro. Ara hi ha dades: peticions HTTP del web de reserves, consultes lentes de db-reservas, accessos a kv-contoso-pro, registres dels contenidors d'aks-contoso-operaciones i el registre d'activitat de les dues subscripcions. Emmagatzemar-los no serveix de res si ningú no els sap interrogar, i aquest és exactament el punt on molts equips es queden: paguen la ingesta i no exploten la dada.

Aquesta lliçó ensenya KQL —el llenguatge de consulta de Kusto— des de zero i de manera progressiva, sempre sobre dades reals de Contoso Airlines. Acabaràs resolent-hi la queixa que va obrir el mòdul: «he pagat i no m'ha arribat la targeta d'embarcament». I aprendràs a controlar la factura, perquè la ingesta i la retenció a Log Analytics són la partida que més sorprèn quan arriba el mes següent.

1. Què és una àrea de treball de Log Analytics
2. Disseny de l'àrea: una o diverses, i RBAC
3. Les taules que t'hi trobaràs
4. KQL des de zero: filtrar, projectar i estendre
5. Agregar: summarize, bin() i sèries temporals
6. Combinar i transformar: join, union, let, parse i mv-expand
7. La investigació completa d'una targeta que no va arribar
8. Funcions desades i alertes de cerca de registres
9. Consultes entre àrees i exportació de dades
10. Plans de taula, retenció i les tres palanques del cost
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

Una àrea de treball és el contenidor on es guarden i es consulten els registres: un recurs d'Azure, en una regió concreta, amb el seu RBAC, la seva retenció i la seva factura. A dins hi ha taules, cadascuna amb un esquema fix de columnes tipades, i sobre elles es consulta amb KQL, un llenguatge de només lectura, d'estil canonada, pensat per a volums enormes de dades de sèries temporals.

log-contoso-pro viu a rg-contoso-seguridad-pro i és deliberadament el punt únic de convergència. Allà arriben els registres de recurs de tota la plataforma, la telemetria d'Application Insights (07-03), les dades de Container Insights d'AKS, el registre d'activitat i les alertes de Microsoft Defender for Cloud del mòdul 4. Aquesta convergència és el que permet escriure una sola consulta que creua la petició HTTP del passatger amb l'excepció de la funció i amb el missatge de la cua. Si aquestes dades estiguessin en quatre àrees diferents, la investigació seria un exercici de copiar i enganxar entre pestanyes.

La primera decisió d'arquitectura és quantes àrees crear:

Contoso fa servir una sola àrea de producció. Abans de decidir-ho, l'argument en contra era el control d'accés: no tothom ha de veure els registres de kv-contoso-pro. La resposta és en els dos modes d'accés:

• Context d'àrea: qui té permís sobre l'àrea veu totes les taules i tots els recursos; és el que necessita l'equip central d'operacions.
• Context de recurs: l'usuari consulta des del full del recurs, o amb resource(), i veu només els registres dels recursos sobre els quals té RBAC. Un desenvolupador amb Lector sobre app-contoso-reservas-dev veu aquests i cap més, encara que siguin a la mateixa àrea.

S'activa amb az monitor log-analytics workspace update --workspace-name log-contoso-pro --resource-group rg-contoso-seguridad-pro --set properties.features.enableLogAccessUsingOnlyResourcePermissions=true. Amb aquesta opció, el permís sobre el recurs governa i el de l'àrea deixa de donar accés universal: el grup Contoso-Desarrollo rep Lector sobre rg-contoso-reservas-dev i veu el que és seu; Contoso-Operaciones rep el rol Lector de Log Analytics sobre l'àrea i ho veu tot. Una sola àrea, permisos per recurs: exactament l'RBAC del mòdul 4 aplicat a l'observabilitat.

Dues advertències. AzureDiagnostics és una taula ampla i compartida per molts serveis, amb columnes del tipus campo_s, campo_d o campo_b i un límit de columnes que pot provocar pèrdues: prefereix sempre les taules dedicades amb --export-to-resource-specific true, com vas fer a 07-01. I els noms App* són els d'un recurs d'Application Insights basat en àrea de treball: la telemetria viu a log-contoso-pro i es consulta al costat de la resta, que és justament el que fa possible l'apartat 7.

Una consulta KQL comença per una taula i encadena operadors amb la barra vertical |. Cada operador rep una taula i en retorna una altra.

Línia a línia:

1. AppServiceHTTPLogs — la taula d'origen. Comença sempre per una taula concreta, mai per search.
2. where TimeGenerated > ago(1h) — filtre temporal; admet 5m, 7d, 30d. Va sempre el primer: és el que redueix el volum escanejat i, per tant, el cost i el temps de la consulta.
3. Els where successius filtren per lloc i per codi d'estat: == distingeix majúscules, =~ no.
4. project selecciona columnes i descarta la resta, reduint el que viatja al navegador; order by ... desc ordena —sense això l'ordre no està garantit— i take 20 retalla el resultat.

L'operador search "XR7742" busca un text a totes les taules: útil una vegada, quan no saps on és la dada, i caríssim perquè ho escaneja tot. Tan bon punt sàpigues la taula, fes-la servir directament. Per la seva banda, extend afegeix columnes calculades sense perdre les existents:

• between (datetime(...) .. datetime(...)) acota una finestra absoluta, per reconstruir un incident ja tancat. Altres operadors de temps freqüents: startofday(now()), startofweek(), now()-2d.
• extend crea SegonsResposta a partir de mil·lisegons; el .0 força la divisió decimal.
• case(...) avalua condicions en ordre i retorna el primer encert; l'últim valor és el «si no».

summarize és l'operador que converteix milions de files en una resposta.

• count() compta files; countif(condició) compta només les que compleixen alguna cosa, evitant una segona consulta.
• avg() dona la mitjana, que menteix amb les latències: unes poques peticions de 20 segons a penes mouen la mitjana. percentile(DurationMs, 95) és el valor per sota del qual queda el 95 % de les peticions: la mètrica honesta, i la que sosté l'SLO de 07-01.
• dcount() compta valors diferents de manera aproximada —algorisme probabilístic, error al voltant de l'1 %—, cosa que el fa rapidíssim sobre milers de milions de files; dcount(UserId, 4) puja la precisió a costa de recursos.
• by Name agrupa per operació: una fila per punt de connexió.

Per veure l'evolució en el temps cal bin(), que arrodoneix cada marca temporal a un múltiple de l'interval:

bin(TimeGenerated, 5m) agrupa tot el que ha passat al mateix tram de 5 minuts; el resultat és una sèrie temporal. render timechart la dibuixa al portal —també existeixen barchart, columnchart, piechart i areachart—. I top 10 by P95 desc és la drecera d'order by més take.

let declara constants i subconsultes reutilitzables —let finestra = 2h; o let apps = dynamic(["app-contoso-reservas-pro", "app-contoso-api-disponibilidad-pro"]);, després utilitzable amb where AppRoleName in (apps)—: fa llegibles les consultes llargues i és imprescindible en la investigació de l'apartat 7. union apila taules amb esquemes diferents —les columnes que falten en una queden buides—: union AppExceptions, ContainerLogV2 barreja excepcions d'aplicació i sortida de contenidors en una sola línia de temps. Dins d'un union, $table retorna de quina taula venia cada fila i coalesce() pren el primer valor no buit entre diverses columnes equivalents.

join creua dos conjunts per una clau comuna. Els seus tipus:

L'innerunique per defecte és la font número u de resultats desconcertants a KQL: deduplica silenciosament i els recomptes surten més baixos del que s'esperava. Escriu sempre el tipus de manera explícita.

Aquesta consulta respon a la pregunta del negoci amb una precisió que cap mètrica no podria donar: quins localitzadors s'han pagat i no tenen targeta. leftanti conserva exactament les files de l'esquerra sense parella a la dreta.

Finalment, parse extreu camps d'una cadena sense escriure expressions regulars:

El patró de parse es llegeix literalment: l'* inicial ignora el que hi hagi abans, després busca el text vol=, captura fins a seients= a Vol, i així successivament. Si el format del missatge canvia, la captura retorna buit en lloc de fallar, així que convé validar-ho.

El seu company és mv-expand, que converteix un camp amb diversos valors —normalment un JSON imbricat llegit amb todynamic()— en diverses files, una per element. Una reserva amb tres trams produeix tres files, i així es poden agregar rutes encara que la dada vingués imbricada; ho aplicaràs a l'exercici 3.

Aquest és el recorregut que va obrir el mòdul. El passatger dona el seu localitzador, XR7742. Cinc passos encadenats.

Pas 1: trobar la compra i el seu identificador d'operació.

OperationId és la clau de tot: identifica l'operació de negoci completa i es propaga entre components. El veuràs en detall a 07-03.

Pas 2: seguir aquesta operació per tots els components.

toscalar() redueix una subconsulta a un valor únic reutilitzable, i el union ordenat per temps produeix la línia de temps completa d'aquella reserva: la petició web, la crida a sql-contoso-reservas-pro, l'escriptura a cola-emision-tarjetas i el que passés després.

Pas 3: comprovar si la funció va arribar a executar-se. N'hi ha prou de filtrar AppRequests per AppRoleName == "func-contoso-tarjetas-pro" i Name == "GenerarTarjetaEmbarque" amb el mateix localitzador. Si no retorna files, el missatge es va encuar però ningú no el va processar i el problema és al desencadenador; si les retorna amb Success == false, continua pel pas 4.

Passos 4 i 5: l'error i la seva causa arrel.

make_set(columna, N) recull fins a N valors diferents en una llista: revela de cop si la fallada afecta només XR7742 o dues-centes reserves més. Si l'excepció és d'accés denegat, la causa és a un pas, als registres d'auditoria de Key Vault:

El desenllaç real de Contoso: el certificat de signatura de PDF de kv-contoso-pro havia caducat, la identitat administrada id-contoso-api-pro rebia un error en recuperar-lo, la funció fallava després de cinc reintents i el missatge acabava a la cua de missatges amb problemes de lliurament. Cinc consultes, de la queixa a la causa arrel, sense obrir ni una sola sessió en un servidor.

Aquest recorregut no s'ha de reinventar cada vegada. Una funció desada converteix una consulta en un operador nou, amb paràmetres, disponible per a tot l'equip:

Amb la funció desada a la categoria «Contoso - Operaciones», qualsevol del grup Contoso-Operaciones escriu SeguirLocalizador("XR7742") i obté el recorregut complet. És la diferència entre que la investigació depengui de la Marta Ríos i que la faci el primer que atengui la trucada. Aquestes funcions i les consultes d'exemple compartides es versionen al repositori contoso-infra, al costat dels llibres i les plantilles Bicep del mòdul 5.

Qualsevol consulta KQL que retorni files es pot convertir en una alerta. És el que permet alertar sobre coses que cap mètrica de plataforma no expressa:

Tres decisions. Una --window-size més gran que la freqüència dona marge a la latència d'ingesta —les dades triguen d'un a cinc minuts a estar disponibles, i una finestra ajustada genera falsos negatius—. --evaluation-frequency 15m en lloc d'1m perquè aquestes alertes es facturen per regla i freqüència. I gravetat 2 amb ag-equipo-contoso: cinc targetes sense emetre és un problema real, però no justifica un SMS de matinada.

Encara que Contoso faci servir una sola àrea, hi ha dues maneres de sortir-ne. workspace("log-contoso-millas").AppRequests apunta a una altra àrea per nom o identificador i es combina amb union per consultar-ne diverses alhora; resource("/subscriptions/.../sites/app-contoso-reservas-pro") consulta els registres d'un recurs concret sense anomenar l'àrea, i és la manera natural de treballar en context de recurs.

L'exportació de dades de l'àrea envia taules senceres i en continu a un compte d'emmagatzematge o a un Event Hubs, sense escriure codi. Contoso exporta AzureActivity i AppServiceHTTPLogs a stlagocontosopro, capa bronce: compliment a set anys a preu d'emmagatzematge en fred i disponibilitat per a Synapse (mòdul 3) sense tornar a pagar la ingesta. La combinació que cal interioritzar és aquesta: Log Analytics per als últims 30-90 dies, que és quan s'investiga; emmagatzematge barat per a la resta.

Aquí hi ha l'advertència central del mòdul. La ingesta i la retenció a Log Analytics és una de les factures que més sorprèn a Azure. No hi ha cap avís: actives uns registres de depuració durant una investigació, se t'oblida desactivar-los, i trenta dies després la línia de Log Analytics supera la del còmput que la genera. Cada taula té un pla que fixa què s'hi pot fer i quant costa:

La retenció, a més, es divideix en dos trams: la interactiva (consultable immediatament, més cara) i l'arxiu a llarg termini (molt més barat, fins a 12 anys, del qual cal «rehidratar» o consultar amb treballs de cerca). Amb això ja es poden accionar les tres palanques del cost, en ordre d'impacte:

1. Què s'ingereix. La palanca dominant; els registres de depuració i de consola en són els grans culpables. Les transformacions a les DCR permeten descartar en el moment de la ingesta els batecs, els sondejos d'estat i les peticions a recursos estàtics, que no aporten res i són la meitat del volum.
2. En quin pla. Moure ContainerLogV2 a Basic quan només es fa servir per llegir els últims dies retalla dràsticament la factura de la taula més voluminosa de Contoso.
3. Quant de temps es guarda. La retenció es fixa per taula, no només per àrea: AzureActivity a 365 dies per compliment, AppTraces a 30.

La taula Usage és gratuïta i diu exactament on se'n van els diners:

Quantity ve en megabytes, d'aquí la divisió. El cost estimat és orientatiu —el preu real depèn del pla i del compromís—, però n'hi ha prou per ordenar per impacte. A Contoso, aquesta consulta va revelar que AppServiceConsoleLogs era el 41 % del volum total i no el consultava ningú. Canviant el summarize per by bin(TimeGenerated, 1d), DataType i renderitzant en columnchart es veu, a més, el dia exacte en què alguna cosa es va disparar. Aplicar la retallada:

Finalment, el model de preus de l'àrea: pagament per gigabyte davant de compromís de capacitat. A partir d'uns 100 GB al dia, comprometre un nivell diari fix aplica un descompte notable, i a partir d'aquí creix per esglaons. La regla de Contoso: mesurar tres mesos amb Usage, retallar primer el que no es consulta, i només després comprometre capacitat sobre el volum ja optimitzat. Comprometre capacitat sobre dades inútils és pagar un descompte per escombraries. Un límit diari d'ingesta actua a més com a xarxa de seguretat davant d'un bucle de registre descontrolat, encara que cal assumir que, assolit el sostre, es deixen de rebre dades fins l'endemà: no el posis a les taules de seguretat.

• No filtrar per temps al principi, o fer servir search en producció. Són els dos errors que més costen en rendiment: posa sempre where TimeGenerated > ago(...) com a primer operador i parteix d'una taula concreta, perquè search les escaneja totes.
• Deixar el join per defecte. innerunique deduplica en silenci i produeix recomptes incorrectes. Escriu kind= sempre.
• Alertar sobre una finestra igual a la freqüència. La latència d'ingesta et farà perdre esdeveniments: la finestra ha de ser més gran.
• Confondre mitjana amb percentil. La mitjana de latència amaga la cua llarga, que és la que veu el passatger.
• Oblidar registres de depuració activats. L'origen número u de factures sorpresa: revisa Usage cada mes i posa-ho al calendari.
• Consell: fes servir | take 10 mentre desenvolupes i treu-lo al final; iterar sobre 10 files és instantani. I prefereix les taules dedicades (--export-to-resource-specific), que migren fora d'AzureDiagnostics amb millor esquema i plans per taula.
• Consell: desa com a funció tota consulta que hagis escrit dues vegades. El coneixement d'investigació ha d'estar a l'àrea, no a l'historial d'algú.

Exercici 1. Escriu una consulta KQL que, sobre l'última setmana, retorni per cada operació d'app-contoso-api-disponibilidad-pro el nombre de peticions, el percentatge d'error i el percentil 95 de la durada, mostrant només les operacions amb més de 1.000 peticions i p95 superior a 800 ms. Explica cada línia.

Exercici 2. La factura mensual de log-contoso-pro ha passat de 400 a 1.750 euros sense que s'hagi desplegat res nou. Descriu com investigar-ho amb KQL i proposa quatre mesures concretes, indicant quina palanca acciona cadascuna.

Exercici 3. La Nuria Peña vol un informe setmanal amb les cinc rutes més reservades i el seu ingrés mitjà, per al projecte Contoso Millas (centro-coste=CC-2077). Les dades són en esdeveniments personalitzats amb un camp tramos imbricat. Escriu la consulta i explica com la lliuraries de manera recurrent.

Solució 1:

El filtre temporal va primer per reduir el volum escanejat. El segon where acota a l'API. summarize agrega per operació amb by Name, fent servir countif per no necessitar una segona consulta i percentile en lloc d'avg perquè la mitjana amaga la cua. extend calcula el percentatge amb 100.0 per forçar decimals. El filtre de volum i latència va després de summarize, perquè opera sobre columnes que abans no existien; posar-lo abans donaria error. order by deixa a dalt el que és més greu.

Solució 2: s'investiga amb Usage, agrupant per DataType i per bin(TimeGenerated, 1d) sobre 60 dies i renderitzant en columnes; el gràfic mostra el dia exacte del salt i quina taula el causa. Sol ser una de tres coses: registres de depuració activats en una investigació i oblidats, una configuració de diagnòstic nova desplegada per l'assignació diagnostico-app-service sobre recursos acabats de crear, o un bucle d'excepcions que genera milers de traces per minut. Contrastar amb AzureActivity què va canviar aquells dies. Mesures: (1) desactivar les categories de diagnòstic que ningú no consulta —palanca «què s'ingereix», la de més impacte—; (2) afegir una transformació a la DCR que descarti sondejos d'estat i batecs —mateixa palanca, a l'origen—; (3) passar ContainerLogV2 a pla Basic —palanca «en quin pla»—; (4) baixar la retenció d'AppTraces a 30 dies mantenint AzureActivity a 365 —palanca «quant de temps»—. I un límit diari d'ingesta com a xarxa de seguretat, mai sobre taules de seguretat.

Solució 3:

mv-expand desdobla cada tram a la seva pròpia fila i strcat compon la ruta llegible. Lliurament recurrent: la consulta es desa com a funció a log-contoso-pro, s'incrusta en un llibre parametritzat amb l'interval com a paràmetre, i aquest llibre s'envia automàticament cada dilluns. L'automatització de l'enviament es resol amb un runbook d'Azure Automation o una Logic App —la comparació entre totes dues opcions és exactament el tema de la lliçó 07-04—. Etiquetes del recurs implicat: entorno, proyecto=contoso-millas, centro-coste=CC-2077 i propietario.

Ja saps què és una àrea de treball de Log Analytics i per què log-contoso-pro és el punt únic on convergeix tot: registres de recurs, registre d'activitat, telemetria d'aplicació i alertes de seguretat, amb l'avantatge decisiu de poder creuar-los en una sola consulta. Coneixes el criteri per separar o unificar àrees, i la peça que fa viable l'àrea única —el context de recurs davant del context d'àrea, amb enableLogAccessUsingOnlyResourcePermissions, perquè cada equip vegi només el que és seu amb l'RBAC que ja té—, a més del mapa de les taules que t'hi trobaràs, amb la recomanació de preferir les dedicades a AzureDiagnostics. Sobretot, saps KQL: filtrar amb where i els operadors de temps, seleccionar amb project, calcular amb extend i case, agregar amb summarize fent servir count, countif, avg, percentile i dcount, construir sèries temporals amb bin() i dibuixar-les amb render, combinar amb union, let i els sis tipus de join —amb l'advertència sobre innerunique—, i extreure estructura amb parse i mv-expand. Ho has aplicat al recorregut d'investigació complet que va obrir el mòdul: de la queixa del localitzador XR7742 a un certificat caducat a kv-contoso-pro, en cinc consultes encadenades, i ho has convertit en la funció compartida SeguirLocalizador perquè la investigació no depengui d'una sola persona. Has construït una alerta de cerca de registres sobre una consulta, alerta-tarjetas-no-emitidas, i saps exportar dades a stlagocontosopro per conservar barat allò que ja no investigues.

I t'endus la lliçó de diners, que és la que més vegades s'aprèn tard: els plans de taula Analytics, Basic i Auxiliary, la retenció interactiva davant de l'arxiu a llarg termini, i les tres palanques —què s'ingereix, en quin pla i quant de temps es guarda— amb la taula Usage com a instrument per saber on se'n van els diners abans de tocar res, i el compromís de capacitat només després d'haver retallat. Queda un buit. Totes les consultes de l'apartat 7 es recolzaven en OperationId, en taules AppRequests i AppDependencies, i en propietats com localizador que algú va haver d'emetre des del codi. Aquesta dada no apareix per art de màgia: la genera Application Insights, i d'ell tracta la lliçó següent —el model de telemetria, la instrumentació d'app-contoso-reservas-pro i func-contoso-tarjetas-pro, la correlació distribuïda amb el context de traça del W3C, el mapa de l'aplicació, el mostreig i la telemetria personalitzada que converteix una reserva confirmada en una dada consultable—.