Guías · Nivel 4

Azure Monitor y Log Analytics: el área de trabajo, el agente, las alertas y un servidor que deja de enviar datos

Cómo diseñar un área de trabajo, recoger eventos, contadores y syslog con el agente de Azure Monitor y reglas de recopilación, traer los servidores locales con Azure Arc, consultar con KQL, alertar con un grupo de acciones, controlar retención y coste, y resolver el ticket de un servidor que ya no informa.

Qué vas a conseguir

Un área de trabajo de Log Analytics que recibe los datos de tus servidores, en Azure y en el CPD, con reglas que dicen exactamente qué se recoge. Las consultas KQL que usas a diario, una alerta que llega al equipo de guardia y no al buzón de nadie, una factura que entiendes por tabla, y el procedimiento para cuando un servidor deja de aparecer.

Antes de empezar

  • Una suscripción para la monitorización y el rol Monitoring Contributor (alertas y reglas) y Log Analytics Contributor (área de trabajo) sobre su grupo de recursos.
  • Para los servidores locales, salida HTTPS (443) hacia los puntos de conexión de Azure Arc y de Azure Monitor, directa o por proxy.
  • El agente de Log Analytics (MMA/OMS) está retirado desde agosto de 2024. Si aún queda alguno, la migración al agente de Azure Monitor va antes que cualquier otra cosa de esta guía.

1. Un área de trabajo, no veinte

La regla general es una área de trabajo por región de datos, no una por equipo ni por aplicación.

  • Acceso: con el modo usar permisos de recurso o de área de trabajo, quien tiene acceso a una VM ve sus registros sin ver los de las demás. Para tablas delicadas existe RBAC por tabla.
  • Cuándo separar: datos que por ley deben quedarse en otra región, otro tenant, o la decisión de no mezclar con Sentinel. Si Sentinel está activado en un área de trabajo, cobra sobre los datos facturables de esa área; muchos equipos dejan los contadores de rendimiento en un área de operaciones aparte por ese motivo.

2. El agente y las reglas de recopilación

El agente de Azure Monitor (AMA) no tiene configuración propia: recoge lo que dicen las reglas de recopilación de datos (DCR) asociadas a la máquina. Una máquina puede tener varias reglas; una regla puede aplicarse a cientos de máquinas.

Azure portal · Monitor · Regla de recopilación de datos
MonitorConfiguraciónReglas de recopilación de datosCrear
Nombredcr-windows-base · Región: West Europe · Tipo de plataforma: Windows
Recursosgrupo rg-servidores-prod (12 VM) y rg-arc-cpd (31 servidores Arc)
Origen 1 · Registros de eventos de WindowsSistema y Aplicación, Crítico, Error y Advertencia
Origen 2 · Contadores de rendimientoCPU, memoria, disco lógico, red · cada 60 s
DestinoRegistros de Azure Monitor → law-contoso-ops-weu
Revisar y crear
  • Los eventos van a la tabla Event, los contadores a Perf y el syslog de Linux a Syslog (con su propia regla: auth, daemon y kern desde Warning suele bastar). Los eventos de seguridad de Windows van a SecurityEvent y se configuran desde el conector de Sentinel.
  • La regla admite XPath para afinar: System!*[System[(Level=1 or Level=2)]] deja solo críticos y errores.
  • El agente se instala como extensión (AzureMonitorWindowsAgent / AzureMonitorLinuxAgent). Al asociar una regla desde el portal, la extensión se instala sola; a escala, se asigna la iniciativa de Azure Policy que instala el agente y asocia la regla a todo lo nuevo.

3. Los servidores del CPD con Azure Arc

Un servidor local no puede tener la extensión del agente sin existir antes en Azure. Azure Arc (agente Connected Machine, azcmagent) lo convierte en un recurso de Azure con identidad administrada, etiquetas, políticas y extensiones.

  1. En Azure Arc › Máquinas › Agregar o crear, genera el script para varios servidores con una entidad de servicio que solo tenga el rol Azure Connected Machine Onboarding en rg-arc-cpd.
  2. Si hay proxy, configúralo antes de conectar: azcmagent config set proxy.url "http://proxy.contoso.local:8080".
  3. Ejecuta azcmagent check para probar los puntos de conexión y despliega el script con MECM, GPO o Ansible.
  4. Cuando el servidor aparece como Conectado, la iniciativa de Azure Policy instala el agente y le asocia dcr-windows-base.

4. Las consultas de cada día

Log Analytics · law-contoso-ops-weu
# Quién ha dejado de informar en los últimos 15 minutosHeartbeat| summarize Ultimo = max(TimeGenerated) by Computer, ComputerEnvironment| where Ultimo < ago(15m)Computer         ComputerEnvironment   Ultimosrv-file02       Non-Azure             28/10/2026 06:41srv-print01      Non-Azure             27/10/2026 22:03# Discos con menos del 10 % librePerf| where TimeGenerated > ago(1h) and ObjectName == "LogicalDisk" and CounterName == "% Free Space" and InstanceName != "_Total"| summarize Libre = round(min(CounterValue), 1) by Computer, InstanceName| where Libre < 10Computer      InstanceName   Libresrv-sql03     E:             6.4srv-app07     D:             8.9
  • Event responde a "¿qué pasó en esta máquina anoche?": Event | where Computer == "srv-app07" and EventLevelName == "Error" | summarize count() by Source, EventID.

5. Una alerta que llega a alguien

Azure portal · Monitor · Regla de alerta
MonitorAlertasCrearRegla de alerta
Ámbitolaw-contoso-ops-weu · Señal: búsqueda de registros personalizada
ConsultaHeartbeat | summarize Ultimo = max(TimeGenerated) by Computer | where Ultimo < ago(10m)
Mediciónrecuento de filas · Dividir por dimensiones: Computer · Umbral: mayor que 0
Evaluacióncada 5 minutos, periodo de 24 horas · Gravedad: 1 – Error
Grupo de accionesag-ops-guardia (correo al buzón del equipo, webhook a Jira Service Management)
Revisar y crear
  • Dividir por Computer genera una alerta por servidor, con su nombre en el aviso, en lugar de un único "hay servidores caídos".
  • El grupo de acciones se reutiliza en todas las reglas: notificación al buzón compartido, webhook a la herramienta de tickets o una aplicación lógica que publica en Teams. Nunca el correo personal de quien creó la regla.
  • Para las ventanas de mantenimiento, una regla de procesamiento de alertas suprime las notificaciones de un grupo de recursos durante el horario del cambio, sin desactivar las reglas.

6. Retención y coste

  • La retención analítica por defecto es de 30 días (31 incluidos en el precio de ingesta). Por tabla puedes ampliarla hasta dos años y añadir retención a largo plazo hasta 12 años, consultable con trabajos de búsqueda.
  • Planes por tabla: Analytics para lo que alimenta alertas y paneles, Basic para lo que se consulta en una investigación, Auxiliary para registros verbosos de auditoría. Las alertas dejan de funcionar en una tabla Auxiliary.
  • Usage | where IsBillable | summarize GB = sum(Quantity) / 1000 by DataType dice qué tabla pesa. Lo habitual: contadores cada 10 segundos o Información en todos los registros de eventos. Se corrige en la regla, no en el área de trabajo.
  • Un límite diario evita sorpresas, pero al alcanzarlo deja de entrar todo, alertas incluidas. Úsalo como red de seguridad con un umbral alto y una alerta al 80 %.

7. El ticket: "srv-file02 ha dejado de enviar datos"

La alerta de latido salta a las 06:51. El servidor responde al ping y los usuarios abren sus carpetas.

  1. ¿Desde cuándo? La consulta de Heartbeat dice 06:41. Si el resto de servidores de la sede también calla, es la red o el proxy, no la máquina.
  2. ¿Arc está conectado?
srv-file02 · PowerShell (administrador)
azcmagent showResource Name                           : srv-file02Resource Group Name                     : rg-arc-cpdAgent Status                            : ConnectedAgent Last Heartbeat                    : 2026-10-28T07:02:14ZUsing HTTPS Proxy                       : http://proxy.contoso.local:8080Dependent Service Status  Agent Service (himds)                 : running  Extension Service (extensionservice)  : running  GC Service (gcarcservice)             : runningaz monitor data-collection rule association list --resource "/subscriptions/<id>/resourceGroups/rg-arc-cpd/providers/Microsoft.HybridCompute/machines/srv-file02" --query "[].name" -o tsv# Sin resultados: el servidor no tiene ninguna regla asociada
  1. ¿El agente está instalado y vivo? En Extensiones del servidor Arc, AzureMonitorWindowsAgent debe estar en Correcto, y el proceso MonAgentCore.exe en ejecución. Los registros de la extensión están en C:\ProgramData\GuestConfig\extension_logs\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent.
  2. ¿Tiene regla asociada? Aquí estaba el fallo: la noche anterior se recreó dcr-windows-base con otro ámbito y srv-file02 quedó fuera. Sin regla, el agente no tiene nada que enviar, ni siquiera el latido. Se vuelve a asociar y el latido aparece en unos minutos.
  3. Si la regla está bien, mira la red: el agente necesita global.handler.control.monitor.azure.com, westeurope.handler.control.monitor.azure.com y <id-del-área>.ods.opinsights.azure.com, sin inspección TLS. Recuerda que la extensión del agente puede no heredar el proxy de Arc: tiene su propia configuración de proxy.

Cierra el ticket con la causa y la prevención: las asociaciones las gestiona Azure Policy, no el portal a mano.

Siguientes pasos

  • La guía de Microsoft Sentinel usa esta misma área de trabajo para la seguridad: conectores, reglas en KQL e incidentes.
  • La guía de Terraform para declarar áreas de trabajo, reglas de recopilación y alertas como código.
  • La guía de Backup y DR/BCP: la alerta de trabajos de copia fallidos es la siguiente que merece una regla.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.

Apúntate y llévate las 33 ideas →