La observabilidad importa porque es la forma más honesta de ver el negocio en vivo, te lo digo como amigo, fue para mi un alivio, y creo que a Vos te servira tambien este post XD
Cada request es una persona esperando respuesta; si no medís, navegás a ciegas. Con KQL podés transformar segundos de duda en segundos de certezas: ¿se cayó el login en Android?, ¿la latencia subió sólo en Alemania?, ¿un microservicio quedó mudo? Esa velocidad baja el MTTD/MTTR (tiempo en detectar y resolver) y te evita apagar incendios a punta de intuición. En una guardia, esa diferencia entre “creo” y “sé” vale oro.
También es plata contante y sonante: con series por hora/día entendés picos y valles para planificar capacidad y ajustar autoscaling sin sobreaprovisionar. Si ves que los lunes a las 10 am explotás y a la madrugada dormís, acomodás ventanas de mantenimiento y ahorrás cómputo. KQL te deja encontrar endpoints lentos, dependencias ruidosas y consultas a la base que pegan duro; afinás performance donde paga. Y con retención y sampling bien pensados, controlás costos de logging sin perder señal.
Por último, la observabilidad te mejora la calidad de cada release y acelera el aprendizaje del producto.
Correlacionás despliegues y feature flags con errores, latencias y conversiones (requests + traces + customEvents), y si algo se tuerce, hacés rollback con datos, no con ansiedad. Tus SLI/SLO dejan de ser promesas y pasan a ser acuerdos medibles (y con error budgets sabés cuándo frenar features para estabilizar). Incluso seguridad y compliance se benefician: picos raros de 401/403, patrones de IPs, auditoría de accesos… todo cae en el mismo radar. En resumen: con KQL mirás, entendés y actuás más rápido —y eso, en producción, es la diferencia entre sufrir y liderar.
Cuando hablás de observabilidad en Azure, estás hablando de “ver” lo que realmente pasa con tu app: quién la usa, cuándo, cuánto sufre, y por qué. El motor para preguntarle eso a tus logs es KQL (Kusto Query Language), y Azure Monitor / Log Analytics te dan la cancha donde jugás. Con unas cuantas líneas podés transformar ruido en señales claras para decidir: ¿es hora de escalar?, ¿se cayó algo?, ¿por qué subió la latencia?, ¿hubo pico a las 8 pm?
Tu consulta de ejemplo es perfecta para arrancar porque simula carga y te enseña el flujo mental de KQL:let start = ago(14d);range t from start to now() step 1h| extend Day = startofday(t), Hour = hourofday(t), requests = toint(10 + rand(50))| summarize total_requests = sum(requests) by Day, Hour
Acá definís una ventana de 14 días, generás una serie horaria cada 1 h, calculás “Day” y “Hour”, inventás un volumen de requests (10–60 aprox.), y luego agregás por día y hora. ¿Qué aprendés? A construir series temporales, a enriquecer con dimensiones útiles (día/hora) y a cerrar con summarize, que es el corazón de los conteos, promedios y percentiles.
¿Para qué sirve esto en PROD? Primero, para entender patrones: horas pico, valles, y “horas muertas”. Con esa vista podés planificar capacidad (¿cuántas instancias necesito a las 10 am?), definir ventanas de mantenimiento (cuando el tráfico es bajo), y detectar anomalías (si a la hora 12 siempre tenés ~50 req/h y hoy hay 5, algo se rompió). Además, dimensionar por hora te ayuda a construir SLOs realistas y a negociar SLAs con datos, no con corazonadas.
Llevándolo a datos reales en Application Insights, cambiás el generador sintético por la tabla requests y agrupás por hora (y si querés, por servicio)
De ahí nacen alertas (Log Alerts) útiles: caída brusca de requests, subida anormal, o ausencia total (cero eventos) en un periodo. También podés cruzar con exceptions o dependencies para correlacionar “bajó el tráfico” con “falló el SQL” y disparar runbooks o escalamientos (Autoscale en App Service/VMSS o HPA en AKS). Todo eso es observabilidad accionable: ver → entender → actuar.
Tips de amigo: 1) Siempre agregá dimensiones que te sirvan para filtrar (entorno, versión, región, cloud_RoleName). 2) Para estacionalidad, usá make-series y compará contra la semana anterior. 3) Cuidá costos: logueá lo que necesitás (sampling inteligente) y retené el tiempo justo. 4) Guardá tus queries como funciones (let) y componelas; eso te da velocidad para investigar incidentes. 5) Pinchá tus consultas en Workbooks, sumá percentiles de duración (percentiles(duration, 50, 95, 99)) y tené a mano un panel “de guerra” para incidentes.
En resumen, esa consulta “de juguete” te muestra la receta base: construir la serie, enriquecer con contexto y resumir bien. En PROD, con las tablas reales y algunas dimensiones extra, eso se convierte en decisiones claras: cuándo escalar, cuándo alertar, dónde mirar primero y cómo defender tus SLOs con datos. Y como diríamos entre panas: metele KQL sin miedo, que con dos o tres patrones ya empezás a ver tu sistema con otros ojos.