Azure Monitor

Contents
Documentación sobre Azure Monitor

Información general
¿Qué es Azure Monitor?
Preguntas más frecuentes
Novedades
Guías de inicio rápido
Supervisión de un recurso de Azure
Envío del registro de actividad a un área de trabajo
Azure portal
Plantilla ARM
Supervisión de máquinas virtuales
Máquinas virtuales de Azure
Equipo con Linux
Equipo de Windows
Supervisión de aplicaciones
Aplicación .NET
Aplicación .NET Core
Aplicación Node.js
Aplicación para dispositivos móviles
Aplicación web
Tutoriales
Creación de un gráfico de métricas
Recopilación de registros de un recurso de Azure
Escritura de consultas de registros
Creación de un panel a partir de una consulta de registro
Creación de una alerta a partir de una consulta de registro
Escalado automático del rendimiento y programación
Application Insights
Búsqueda de excepciones del entorno de ejecución de la aplicación
Búsqueda de problemas de rendimiento de las aplicaciones
Alerta sobre el estado de la aplicación
Descripción de los usuarios de aplicaciones
Panel con datos de aplicación
Ejemplos
Plantillas de Resource Manager
Agentes
Alertas
Reglas de alertas de registro
Reglas de alertas de métricas
Grupos de acciones
Creación de un recurso
Azure App Service
Azure Functions
Configuración de diagnóstico
Áreas de trabajo de Log Analytics
Consultas de registros
Workbooks
Azure Monitor para contenedores
Azure Monitor para máquinas virtuales
Azure CLI
Azure PowerShell
Conceptos
¿Qué se puede supervisar?
Supervisión continua
Orígenes de datos
Plataforma de datos
Ubicaciones de datos
Métricas
Registros
Tiempo de ingesta de datos de registro
Transmisión de datos a Event Hubs
Información detallada
Seguridad de los datos
Datos de registro
Claves administradas por el cliente
Redes de Private Link
Almacenamiento privado
Control de datos de registro personales
Recopilación, retención y almacenamiento de datos de aplicaciones
Alertas
Alertas de métricas
Alertas de registro
Alertas de registros de actividad
Visualización de datos
Integraciones de asociados
Seguridad
Línea de base de seguridad
Controles de seguridad de Azure Policy
Guías paso a paso
Escenarios
Supervisión de un recurso de Azure
Supervisión de máquinas virtuales de Azure
Implementación
Implementación de Azure Monitor
Implementación a escala
Administración y configuración
Permisos de roles y seguridad
Direcciones IP
Uso y costo
Uso y costos estimados
Uso y costos de aplicaciones
Registro del uso y los costos de los datos
Registros de plataforma
Registro de actividades
Registros del recurso
Log Analytics
Introducción a las consultas de registros
Experiencia de registros simplificada
Consultas del registro de auditoría
Tutoriales
Tutorial de Log Analytics
Tutorial de consultas de registros
Datos de registro
Ámbito de la consulta
Columnas estándar
Grupos de equipos
Lenguaje de consulta
Documentación sobre lenguaje de consulta
Diferencias entre los lenguajes
Operadores útiles
Functions
Transición desde la búsqueda de registros
Lecciones
Operaciones de cadena
Operaciones de fecha y hora
Funciones de agregación
Agregaciones avanzadas
Combinaciones
JSON y estructuras de datos
Escritura de consultas avanzadas
Gráficos y diagramas
Consultas de búsqueda
Hojas de características clave
SQL
Splunk
Entre recursos
Consultas entre recursos
expresión de aplicación
expresión de área de trabajo
expresión de recurso
Unificación de los recursos de datos de la aplicación
Ejemplos y guía
Consultas de ejemplo
Ejemplos de consultas de registro
Ejemplos de análisis inteligente
Optimización de consultas
Análisis de datos de texto
Áreas de trabajo
Diseño de una implementación de área de trabajo
Crear un área de trabajo
Usar Azure Portal
Uso de CLI de Azure
Uso de PowerShell
Eliminación y recuperación de áreas de trabajo
Desplazamiento de un área de trabajo
Diseño de proveedores de servicios
Administración del acceso
Explorador de métricas
Introducción al Explorador de métricas
Características avanzadas del Explorador de métricas
Ejemplos de gráficos de métricas
Solución de problemas de gráficos de métricas
Recopilación de datos
Reglas de recopilación de datos
Orígenes de datos de agentes
Eventos de Windows
Personalización de datos JSON
Datos de rendimiento de CollectD
syslog
Contadores de rendimiento
Rendimiento de aplicaciones de Linux
Registros IIS
Registros personalizados
Custom Fields
Métricas personalizadas
API REST de métricas
Data Collector API de Log Analytics
Ejemplo de canalización de Data Collector API de Log Analytics
Logic Apps
Búsqueda de Azure Monitor Logs
Conector de Application Insights
Agentes
Agente de Azure Monitor
Recopilación de datos
Agente de Log Analytics
Agentes de Windows
Agentes de Linux
Extensión de VM para Windows
Extensión de VM para Linux
Puerta de enlace de Log Analytics
Administración de agentes
Estado de mantenimiento de los agentes
Extensión de Diagnósticos de Azure
Windows
Instalar y configurar
Opción de instalación
PowerShell
Plantilla de Resource Manager
Envío a métricas de Azure Monitor
Máquina virtual
Conjunto de escalado de máquina virtual
Máquina virtual clásica
servicio en la nube
Envío a Event Hubs
Envío a Logs
Envío a Application Insights
Historial de versiones
Solución de problemas
Linux
Recopilación de métricas con Telegraf
Extensión de máquina virtual de Log Analytics
Agente de Windows de Log Analytics
Agente Linux de Log Analytics
Escalado automático
Tutorial
Parámetros de configuración
Procedimientos recomendados
Métricas comunes
Patrones comunes
Escalado con métricas personalizadas
Escalado de conjuntos de escalado de máquinas virtuales
Escalado de conjuntos de escalado de máquinas virtuales mediante plantillas de
Resource Manager
Uso de notificaciones por correo electrónico y webhooks
Esquemas del registro de recursos
Alertas
Administración de alertas de métricas
Disponibilidad
Uso de umbrales dinámicos
Alertas individuales para muchas series temporales
Alertas de métricas en registros
Uso de la plantilla de Resource Manager
Solución de problemas de alertas de métricas
Reglas de alertas de registro
Configuración de alertas en las consultas de análisis
Consultas
Acciones de webhook
Solución de problemas de alertas del registro
Reglas de alertas de registro de actividad
Alerta de un evento del registro de actividades
Migración de eventos de administración a alertas del registro de actividad
Esquema de Webhook
Alertas del estado del servicio
Ver notificaciones
Configuración de alertas en eventos de notificación
Notificaciones y acciones
Reglas de acción (versión preliminar)
Creación de un grupo de acciones
Esquema de alertas comunes
Definiciones de esquemas de alertas comunes
Integración del esquema común de alertas con Logic Apps
Comportamiento de alertas por SMS
Limitación del número de notificaciones
Creación de grupos de acciones con Resource Manager
Implementación de una acción de Logic App
Interfaz de usuario para alertas
Acerca de grupos inteligentes
Administración de instancias de alertas
Administración de grupos inteligentes
Administración de estados de alertas y de grupos inteligentes
Administración de alertas de otros servicios de supervisión
API de alerta
Alertas de solución de problemas
Alertas y cambios de región
Administración de servicios de TI
IT Service Management Connector
Conexiones de IT Service Management
Integración con exportación segura
Creación de aplicación web de Service Manager
Solución de problemas de sincronización de ITSM de ServiceNow
Solución de Alert Management
Migración de las reglas de alertas clásicas
Acerca de alertas clásicas
Preparación para la migración
Descripción de la herramienta de migración
Uso de la herramienta de migración
Proceso de automático de migración
Administración de alertas de métricas clásicas
Alerta de métricas clásica mediante una plantilla de Resource Manager
Llamada de una alerta métrica clásica a un webhook
Introducción sobre Application Insights
Supervisión basada en código
ASP.NET Core
Supervisión de aplicaciones de ASP.NET Core
ILogger
ASP.NET
Aplicaciones que no son de HTTP y aplicaciones en segundo plano
Consola de .NET
Java
Aplicaciones web
Aplicaciones de Docker
Seguimientos de registro
Métricas de Unix
Dependencias
Telemetría de filtro
Micrometer Metrics
Aplicación de Spring Boot
Node.js
Python
Dependencias
Requests
JavaScript
JavaScript del lado cliente
Mapa de origen para JavaScript
Complementos
Complemento React
Complemento React Native
Error de carga de SDK
Resumen de API de Application Insights
Solución de problemas de ASP.NET
Eliminación de Application Insights
Supervisión sin código
Máquina virtual de Azure y conjunto de escalado de máquinas virtuales
Azure App Service
Azure Cloud Services
Azure Functions
Azure Kubernetes Service
Independiente: cualquier entorno
Java (versión preliminar)
Opciones de configuración
Configuración de argumentos de JVM
Servidores locales
ASP.NET
Introducción
Instrucciones detalladas
Referencia de API
Monitor de estado (heredado)
Java
OpenTelemetry
Creación de un recurso (clásico)
Creación de un recurso (basado en el área de trabajo)
Migración a un recurso basado en área de trabajo
Panel de la aplicación
Mapa de aplicación
Diagnósticos de la transacción
Disponibilidad
Pruebas de direcciones URL
Pruebas de varios pasos
Disponibilidad + Azure Functions
Alertas de disponibilidad
Pruebas de rendimiento
Seguimiento distribuido
Correlación de telemetría
Live Metrics Stream
Métricas
Métricas basadas en registros y agregadas previamente
Definiciones de métricas basadas en registros
Search
Generador de perfiles
Habilitar el generador de perfiles para una instancia de App Service
Habilitar el generador de perfiles para un servicio en la nube
Habilitar el generador de perfiles para una aplicación de Service Fabric
Habilitar el generador de perfiles para una máquina virtual de Azure
Generador de perfiles para App Service de Linux (versión preliminar)
Configuración del generador de perfiles
Seguimiento de las solicitudes de generación de perfiles
Configuración de BYOS (Traiga su propio almacenamiento)
Solución de problemas del generador de perfiles
Depurador de instantáneas
Habilitar Snapshot Debugger para una instancia de App Service
Habilitar Snapshot Debugger para otros entornos
Actualización de Snapshot Debugger
Configuración de BYOS (Traiga su propio almacenamiento)
Solución de problemas de Snapshot Debugger
Detección inteligente
Anomalías de error
Anomalías de rendimiento
Degradación de seguimiento
Volumen de excepción
Fuga de memoria
Detección de seguridad
Administración de reglas de detección inteligente
Notificación por correo electrónico
Uso (análisis de comportamiento de usuario)
Envío de contexto de usuario
Usuarios, sesiones, eventos
Embudos
Cohortes
Impacto
Retención
Flujos de usuario
Análisis de uso
Azure DevOps
Anotaciones de la versión
Supervisión continua
Configuración avanzada
Control de acceso
Recopilación de direcciones IP
muestreo
TelemetryChannels
TelemetryProcessors
Seguimiento de operaciones personalizadas en el SDK de .NET
Personalización de informes de correo electrónico
Excepciones
Seguimientos de registro
EventCounters
Dependencias
ApplicationInsights.config
Poner en correlación orígenes de datos personalizados
Cadenas de conexión
GetMetric
Temas especiales
Diagnósticos detallados para servicios y aplicaciones web
Supervisar el rendimiento de aplicaciones web
Separación de desarrollo, prueba y producción
¿Cómo ... en Application Insights?
Administración de Application Insights
Administración de Azure Cloud Services
Exportación
Exportación continua
Exportación a Stream Analytics
Exportación a SQL con Stream Analytics
Modelo de exportación de datos
Visual Studio
Información detalla sobre F5
Tendencias
CodeLens
Otras plataformas
Sitios de SharePoint
Escritorio de Windows
Otras herramientas
Análisis de cambios
Preguntas frecuentes acerca de la disponibilidad general
Configuración del área de trabajo
Instalación de agentes
Azure portal
Azure PowerShell
Plantillas de ARM
Azure Policy
Máquinas virtuales híbridas
Actualización de Dependency Agent
Asignación de dependencias
Supervisión del rendimiento
Análisis de datos con consultas de registros
Visualización de datos con libros
Creación de reglas de alerta
Deshabilitar la supervisión
Habilitar supervisión
Habilitar información general de la supervisión
Habilitación para un clúster de AKS nuevo
Habilitación para un clúster de AKS existente
Habilitación para un clúster habilitado para Arc
Habilitar para un clúster híbrido
Habilitación para Red Hat OpenShift en Azure, versión 3
Habilitación para Red Hat OpenShift en Azure, versión 4
Asignaciones de regiones
Supervisión del rendimiento
Supervisión del rendimiento de GPU
Supervisión de implementaciones y HPA
Visualización de datos en directo
Introducción a los datos en directo (versión preliminar)
Configurar
Visualización de métricas de clúster
Visualización de implementaciones
Análisis de datos con consultas de registros
Alertas
Creación de reglas de alertas del registro
Creación de reglas de alertas de métricas
Administración de agentes
Configuración del recopilación de métricas de Prometheus
Configuración de los valores de colección del agente
Actualización para habilitar las métricas
Administración de costo y uso
Deshabilitar la supervisión
Deshabilitación del AKS de supervisión
Deshabilitación de supervisión de Red Hat OpenShift, versión 3
Deshabilitación de supervisión de Red Hat OpenShift, versión 4
Deshabilitación de supervisión de clúster híbrido
Otra información
Azure Cache for Redis (versión preliminar)
Azure Cosmos DB
Redes
Key Vault
Storage
Grupos de recursos
Información sobre la solución de problemas
Soluciones
Soluciones de destino
Soluciones disponibles
Valoración del estado de AD
Estado de replicación de AD
Solución Capacidad y rendimiento
Supervisión de contenedores de Docker y Windows
Redes
Análisis de redes
DNS
Monitor de rendimiento de red
Información general de la solución
Monitor de rendimiento
Monitor de conectividad de servicio
ExpressRoute
Precios
Office 365
Solución Service Map
Service Map y Operations Manager
Azure SQL
SQL Server
Surface Hub
Solución de análisis de VMWare
Solución Wire Data
Workbooks
Visualizaciones
Texto
Gráfico
Cuadrícula
Tile
Árbol
Grafo
Barra compuesta
Orígenes de datos
Parámetros
Resumen de parámetros
Parámetros desplegables
Parámetros interactivos
Parámetros de tiempo
Parámetros de texto
Configuración
Control de acceso
Implementación con Azure Resource Manager
Traslado de libros a otra región
Traslado de plantillas de libros a otra región
Conversión de vistas en libros
Introducción a la conversión
Opciones de conversión
Introducción y acceso
Tareas comunes
Conversiones de iconos
Ejemplos
Otras visualizaciones
Power BI
Exportación de datos de registro
Exportación de datos de aplicación
Paneles
Panel mediante datos de registro
Panel mediante datos de aplicación
Actualización de paneles de Log Analytics
Envío de datos a Grafana
Integración de System Center
Conexión de Operations Manager
Evaluación de Operations Manager
Conexión con Configuration Manager
Referencia
Límites de servicio
Cambios de terminología
Referencia de datos
Métricas compatibles
Métricas de la plataforma
Métricas en la configuración de diagnóstico
Métricas en alertas
Esquema de registro de actividad
Esquemas del registro de recursos
Categorías del registro de recursos admitidas
Esquemas de extensión de Diagnostics
Extensión Diagnostics de Windows
Recopilación automática de dependencias
Paquetes NuGet
Compatibilidad con plataformas
Invalidaciones de puntos de conexión
Azure Functions
Notas de la versión
SDK de supervisión con código
Extensión de aplicación web
Modelo de datos
Solicitud
Dependencia
Excepción
Seguimiento
Evento
Métrica
Context
Integración con Azure Functions
Esquema basado en el área de trabajo
Azure PowerShell
Azure Monitor
Registros de Azure Monitor
Azure CLI
Azure Monitor
Registros de actividad
Log Analytics
API DE REST
Azure Monitor
Tutorial de API REST
Azure Monitor
Elementos integrados de Azure Policy
Características y retirada de API
API clásica de escalado automático y métricas
Alertas y supervisión clásicas
Cambio en la preferencia de API de la alerta de registro
Solución de análisis de aplicaciones web
Application Insights Connector
Application Insights para AKS sin código
Supervisión de aplicaciones de Docker
Desuso del portal de OMS
Desuso de las métricas de disco
Cambio al formato de almacenamiento de blobs
Key Vault Analytics (en desuso)
Vistas
Diseñador de vistas
Referencia de iconos
Referencia de los elementos de visualización
Filtros
Recursos
Azure Roadmap
Precios
Calculadora de precios
Disponibilidad regional
Noticias
Introducción a Azure Monitor
23/09/2020 • 20 minutes to read • Edit Online
Azure Monitor maximiza la disponibilidad y el rendimiento de las aplicaciones y servicios con una completa
solución que permite recopilar, analizar y administrar datos telemétricos tanto en la nube como en entornos
locales. Esta solución le ayudará a entender cómo funcionan las aplicaciones y le permitirá identificar de
manera proactiva los problemas que les afectan y los recursos de los que dependen.
Entre los ejemplos de lo que puede hacer con Azure Monitor se incluyen:
Detección y diagnóstico de problemas en aplicaciones y dependencias con Application Insights.
Correlación de problemas de infraestructura con Azure Monitor para máquinas virtuales y Azure
Monitor para contenedores.
Profundización en sus datos de supervisión con Log Analytics para la solución de problemas y
diagnósticos profundos.
Soporte técnico de operaciones a escala con alertas inteligentes y acciones automatizadas.
Creación de visualizaciones con paneles y libros de Azure.
NOTE
Este servicio admite Azure Lighthouse, que permite a los proveedores de servicios iniciar sesión en su propio
inquilino para administrar las suscripciones y los grupos de recursos que los clientes hayan delegado.
El siguiente diagrama proporciona una visión general de Azure Monitor. En el centro del diagrama están los
almacenes de datos de las métricas y los registros, que son los dos tipos fundamentales de datos que se
utilizan en Azure Monitor. En la parte izquierda están los orígenes de datos de supervisión que rellenan
estos almacenes de datos. En la derecha, puede ver las diferentes funciones que realiza Azure Monitor con
los datos recopilados, como la realización de análisis, la elaboración de alertas y la transmisión a sistemas
externos.
Supervisión de la plataforma de datos
Todos los datos recopilados por Azure Monitor pueden clasificarse como uno de los dos tipos
fundamentales: métricas y registros. Las métricas son valores numéricos que describen algún aspecto de un
sistema en un momento dado. Las métricas son ligeras y capaces de admitir escenarios de tiempo casi real.
Los registros contienen distintos tipos de datos organizados en grupos de registros, donde cada tipo tiene
diferentes conjuntos de propiedades. Los datos de telemetría, como los eventos y los seguimientos, se
almacenan como registros junto con los datos de rendimiento para poder analizarlos de forma combinada.
En muchos recursos de Azure, los datos recopilados por Azure Monitor aparecen directamente en la página
de información general de Azure Portal. Eche un vistazo a cualquier máquina virtual, por ejemplo, y verá
varios gráficos en los que aparecen métricas de rendimiento. Haga clic en cualquiera de los gráficos para
abrir los datos en el explorador de métricas de Azure Portal, lo que le permitirá crear gráficos con los
valores de diversas métricas a lo largo del tiempo. Puede ver los gráficos de forma interactiva o anclarlos a
un panel para verlos con otras visualizaciones.
Los datos de registro recopilados por Azure Monitor se pueden analizar con consultas que recuperan,
consolidan y analizan rápidamente los datos recopilados. Puede crear y probar consultas mediante Log
Analytics en Azure Portal y después analizar los datos directamente con otras herramientas o guardar las
consultas para usarlas con las visualizaciones o las reglas de alertas.
Azure Monitor utiliza una versión del lenguaje de consulta Kusto utilizado por Azure Data Explorer, que es
adecuado para realizar búsquedas de registros simples, pero también dispone de funciones avanzadas,
como agregaciones, combinaciones y análisis inteligentes. Puede aprender rápidamente el lenguaje de
consulta con diversas lecciones. Se proporciona orientación concreta a los usuarios que ya están
familiarizados con SQL y Splunk.
¿Qué datos recopila Azure Monitor?

Azure Monitor puede recopilar datos de diversos orígenes. Puede pensar en supervisar datos para las
aplicaciones en niveles que abarcan desde la aplicación hasta el sistema operativo y los servicios en los que
se basa, pasando por la propia plataforma. Azure Monitor recopila datos de cada uno de los siguientes
niveles:
Datos de super visión de aplicaciones : datos sobre el rendimiento y la funcionalidad del código que
ha escrito, independientemente de la plataforma.
Datos de super visión del sistema operativo invitado : datos sobre el sistema operativo en el que
se ejecuta la aplicación. La aplicación se puede ejecutar en Azure, en otra nube o en el entorno local.
Super visión de recursos de Azure : datos sobre el funcionamiento de un recurso de Azure.
Datos de super visión de la suscripción de Azure : datos sobre el funcionamiento y la
administración de una suscripción de Azure, así como sobre el estado y el funcionamiento del propio
Azure.
Datos de super visión de inquilino de Azure : datos sobre el funcionamiento de los servicios de
Azure en el nivel del inquilino, como Azure Active Directory.
En cuanto crea una suscripción a Azure y empieza a agregar recursos, como máquinas virtuales y
aplicaciones web, Azure Monitor comienza a recopilar datos. Los registros de actividad registran la creación
y modificación de recursos. Las métricas indican cómo está funcionando un recurso y los recursos que
consume.
Amplíe los datos que recopila y obtenga información sobre el funcionamiento real de los recursos
habilitando diagnósticos y agregando un agente a los recursos de proceso. De este modo, recopilará datos
de telemetría sobre el funcionamiento interno de un recurso y podrá configurar diferentes orígenes de
datos para recopilar registros y métricas del sistema operativo invitado Windows y Linux.
Habilite la supervisión de la aplicación de App Services o de la máquina virtual y aplicación del conjunto de
escalado de máquinas virtuales para permitir que Application Insights recopile información detallada acerca
de la aplicación, como vistas de página, solicitudes de aplicación y excepciones. Compruebe de forma más
exhaustiva la disponibilidad de la aplicación configurando una prueba de disponibilidad para simular el
tráfico de usuarios.
Orígenes personalizados
Azure Monitor puede recopilar datos de registro de cualquier cliente de REST mediante Data Collector API.
Esto permite crear escenarios de supervisión personalizados y ampliar la supervisión a los recursos que no
exponen datos de telemetría en otros orígenes.
Los datos de supervisión solo resultan útiles si aportan una mayor visibilidad sobre el funcionamiento del
entorno informático. Azure Monitor cuenta con varias características y herramientas que proporcionan
valiosa información sobre las aplicaciones y los recursos de los que dependen. Las características y las
soluciones de supervisión, como Application Insights y Azure Monitor para contenedores, proporcionan
información exhaustiva sobre diferentes aspectos de la aplicación y determinados servicios de Azure.
Application Insights supervisa la disponibilidad, el rendimiento y el uso de las aplicaciones web, tanto si
están hospedadas en la nube como en un entorno local. Esta solución utiliza la eficaz plataforma de análisis
de datos de Azure Monitor para proporcionarle información exhaustiva sobre las operaciones de la
aplicación y diagnosticar errores sin esperar a que un usuario lo notifique. Application Insights incorpora
puntos de conexión con una serie de herramientas de desarrollo y se integra con Visual Studio para admitir
los procesos de DevOps.

Azure Monitor para contenedores es una característica diseñada para supervisar el rendimiento de las
cargas de trabajo de contenedor implementadas en clústeres de Kubernetes administrados y hospedados
en Azure Kubernetes Service (AKS). Proporciona información sobre el rendimiento recopilando métricas del
procesador y de la memoria procedentes de los controladores, los nodos y los contenedores disponibles en
Kubernetes mediante Metrics API. También se recopilan registros del contenedor. Una vez habilitada la
supervisión de clústeres de Kubernetes, estas métricas y registros se recopilan automáticamente mediante
una versión en contenedor del agente de Log Analytics para Linux.
La solución Azure Monitor para VM supervisa las máquinas virtuales de Azure a escala y analiza el
rendimiento y el estado de las máquinas virtuales de Windows y Linux, incluidos los diferentes procesos y
las dependencias interconectadas con otros recursos y con procesos externos. La solución permite
supervisar el rendimiento y las dependencias de las aplicaciones en máquinas virtuales hospedadas en el
entorno local o en otro proveedor en la nube.
Soluciones de supervisión
Las soluciones de supervisión de Azure Monitor son conjuntos empaquetados de lógica que proporcionan
información sobre una determinada aplicación o servicio. Incluyen la lógica para recopilar datos de
supervisión para la aplicación o servicio, consultas para analizar esos datos y vistas para su visualización.
Las soluciones de supervisión están disponibles en Microsoft y otros asociados, y ofrecen herramientas de
supervisión para distintos servicios de Azure y otras aplicaciones.
Respuesta a situaciones críticas

Además de permitirle analizar de forma interactiva los datos de supervisión, una solución de supervisión
eficaz debe ser capaz de responder proactivamente a condiciones críticas que se den en los datos que
recopila. Esto podría hacerse enviando un mensaje o correo a un administrador responsable de investigar
un problema. O también podría hacerse iniciando un proceso automatizado que intente corregir una
condición de error.
Alertas
Las alertas de Azure Monitor informan de forma proactiva de los estados críticos e intentan aplicar acciones
correctivas. Las reglas de alertas basadas en métricas proporcionan avisos casi en tiempo real que se
generan en función de unos valores numéricos, mientras que las reglas basadas en registros permiten
aplicar una lógica compleja entre datos de diversos orígenes.
Las reglas de alertas de Azure Monitor utilizan grupos de acciones, que contienen diferentes conjuntos de
destinatarios y acciones que pueden compartirse entre varias reglas. En función de los requisitos, los grupos
de acciones pueden realizar diferentes acciones, como utilizar webhooks para que las alertas inicien
acciones externas o se integren con las herramientas de administración de servicios de TI.
Gracias al escalado automático, puede ejecutar la cantidad correcta de recursos para administrar la carga de
la aplicación. Permite crear reglas que usan las métricas recopiladas por Azure Monitor para determinar
cuándo deben agregarse automáticamente recursos que controlen el aumento de la carga y permitan
ahorrar dinero quitando recursos inactivos. Tiene que especificar un número mínimo y máximo de
instancias y la lógica para decidir cuándo deben aumentar o disminuir los recursos.
Visualización de los datos de supervisión

Las visualizaciones, como los gráficos y las tablas, son herramientas eficaces para resumir los datos de
supervisión y presentarlos a distintos destinatarios. Azure Monitor cuenta con sus propias características
para visualizar los datos de supervisión y utiliza otros servicios de Azure para publicarlos ante diferentes
destinatarios.
Paneles
Los paneles de Azure permiten combinar distintos tipos de datos, como métricas y registros, en un único
panel de Azure Portal. Si lo desea, también compartir el panel con otros usuarios de Azure. Los elementos
que componen Azure Monitor pueden agregarse a un panel de Azure, así como a la salida de cualquier
consulta de registro o gráfico de métricas. Por ejemplo, puede crear un panel que contenga diferentes
iconos que muestren un gráfico de métricas, una tabla de registros de actividad, un gráfico de uso de
Application Insights y la salida de una consulta de registro.
Vistas
Las vistas representan visualmente los datos de registro de Azure Monitor. Cada vista contiene un icono que
da acceso a una combinación de visualizaciones, como gráficos de barras y líneas, así como a listas en las
que resumen los datos críticos. Las soluciones de supervisión contienen vistas en las que se resumen los
datos de una determinada aplicación. Puede crear sus propias vistas para presentar los datos de cualquier
consulta de registros. Al igual que otros elementos de Azure Monitor, las vistas se pueden agregar a los
paneles de Azure.
Power BI
Power BI es un servicio de análisis empresarial que proporciona visualizaciones interactivas en una serie de
orígenes de datos y que constituye un mecanismo eficaz para poner los datos a disposición de personas
que están dentro y fuera de la organización. Puede configurar Power BI para que los datos de registro se
importen automáticamente desde Azure Monitor y utilizar estas otras visualizaciones.
Integración y exportación de datos

A menudo, necesitará integrar Azure Monitor con otros sistemas y crear soluciones personalizadas que
utilicen los datos de supervisión. Otros servicios de Azure funcionan con Azure Monitor para proporcionar
esta integración.
Centro de eventos
Azure Event Hubs es una plataforma de streaming y un servicio de ingesta de eventos que puede
transformar y almacenar los datos utilizando cualquier proveedor de análisis en tiempo real o adaptadores
de procesamiento por lotes y almacenamiento de datos. Utilice Event Hubs para transmitir datos de Azure
Monitor a herramientas de supervisión y administración de eventos e información de seguridad de
asociados.
Logic Apps
Logic Apps es un servicio que le permite automatizar tareas y procesos de negocio mediante flujos de
trabajo que se integran con diferentes sistemas y servicios. Hay actividades disponibles que leen y escriben
registros y métricas en Azure Monitor, lo que le permite crear flujos de trabajo que se integran con muchos
otros sistemas.
API
Existen varias API para leer y escribir métricas y registros en Azure Monitor, que además proporcionan
acceso a las alertas generadas. También puede configurar y recuperar alertas. De este modo, dispone de
unas posibilidades prácticamente ilimitadas para crear soluciones personalizadas que se integren con Azure
Monitor.
Pasos siguientes
Más información sobre:
Las métricas y registros de los datos que recopila Azure Monitor.
Los orígenes de datos de la forma en que los distintos componentes de la aplicación envían la telemetría.
Las consultas de registros para analizar los datos recopilados.
Procedimientos recomendados para supervisar los servicios y las aplicaciones en la nube.
Preguntas más frecuentes sobre Azure Monitor
En este artículo de preguntas frecuentes de Microsoft, se presenta una lista con las preguntas frecuentes sobre
Azure Monitor.
General
Azure Monitor es un servicio de Azure que proporciona supervisión del rendimiento y la disponibilidad para
aplicaciones y servicios en Azure, en otros entornos en la nube o en el entorno local. Azure Monitor recopila datos
de varios orígenes en una plataforma de datos común en la que se pueden analizar las tendencias y las anomalías.
Las características enriquecidas de Azure Monitor ayudan a identificar y responder rápidamente ante situaciones
críticas que pueden afectar a la aplicación.
¿Cuál es la diferencia entre Azure Monitor, Log Analytics y Application Insights?
En septiembre de 2018, Microsoft combinó Azure Monitor, Log Analytics y Application Insights en un único servicio
para proporcionar una eficaz supervisión de un extremo a otro de las aplicaciones y los componentes en los que se
basan. Las características de Log Analytics y Application Insights no han cambiado, aunque algunas características
han cambiado su marca por Azure Monitor para reflejar mejor su nuevo ámbito. El motor de datos de registro y el
lenguaje de consulta de Log Analytics se denominan ahora Registros de Azure Monitor. Consulte Actualizaciones de
terminología de Azure Monitor.
¿Cuánto cuesta Azure Monitor?
Las características de Azure Monitor que están habilitadas automáticamente, como la recopilación de métricas y los
registros de actividad, se proporcionan sin costo alguno. Hay un costo asociado a otras características, como las
consultas de registro y las alertas. Para obtener información detallada sobre los precios, consulte la página de
precios de Azure Monitor.
¿Cómo puedo habilitar Azure Monitor?
Azure Monitor está habilitado en el momento en que se crea una nueva suscripción de Azure y se recopilan
automáticamente el registro de actividad y las métricas de la plataforma. Puede crear una configuración de
diagnóstico para recopilar información más detallada sobre el funcionamiento de los recursos de Azure y agregar
soluciones de supervisión e información detallada para proporcionar un análisis adicional de los datos recopilados
de servicios específicos.
¿Cómo puedo acceder a Azure Monitor?
Puede acceder a todas las características y los datos de Azure Monitor desde el menú Monitor de Azure Portal. La
sección Super visión del menú de los distintos servicios de Azure proporciona acceso a las mismas herramientas
con datos filtrados para un recurso determinado. También se puede acceder a los datos de Azure Monitor para una
variedad de escenarios mediante la CLI, PowerShell y una API REST.
¿Existe una versión local de Azure Monitor?
No. Azure Monitor es un servicio en la nube escalable que procesa y almacena grandes cantidades de datos,
aunque Azure Monitor puede supervisar los recursos que están en el entorno local y en otras nubes.
¿Azure Monitor puede supervisar los recursos locales?
Sí, además de recopilar datos de supervisión de recursos de Azure, Azure Monitor puede recopilar datos de
máquinas virtuales y aplicaciones en otras nubes y en el entorno local. Consulte Orígenes de datos de supervisión
para Azure Monitor.
¿Azure Monitor se integra con System Center Operations Manager?
Puede conectar el grupo de administración de System Center Operations Manager existente a Azure Monitor para
recopilar datos de los agentes en los registros de Azure Monitor. Esto le permite usar consultas de registros y
soluciones para analizar los datos recopilados de los agentes. También puede configurar los agentes de System
Center Operations Manager existentes para enviar los datos directamente a Azure Monitor. Consulte Conexión de
Operations Manager con Azure Monitor.
¿Qué direcciones IP utiliza Azure Monitor?
Consulte Direcciones IP utilizadas por Application Insights y Log Analytics para obtener una lista de las direcciones
IP y los puertos necesarios para que los agentes y otros recursos externos puedan acceder a Azure Monitor.
Supervisión de datos
¿De dónde obtiene Azure Monitor los datos?
Azure Monitor recopila datos de diversos orígenes, incluidos los registros y las métricas de la plataforma y los
recursos de Azure, las aplicaciones personalizadas y los agentes que se ejecutan en máquinas virtuales. Otros
servicios como Azure Security Center y Network Watcher recopilan datos en un área de trabajo de Log Analytics de
modo que se puedan analizar con los datos de Azure Monitor. También puede enviar datos personalizados a Azure
Monitor mediante la API REST para registros o métricas. Consulte Orígenes de datos de supervisión para Azure
Monitor.
Azure Monitor recopila datos de una variedad de orígenes en los registros o las métricas. Cada tipo de datos tiene
sus propias ventajas relativas y cada uno admite un conjunto determinado de características de Azure Monitor. Hay
una sola base de datos de métricas para cada suscripción de Azure, aunque puede crear varias áreas de trabajo de
Log Analytics para recopilar registros en función de sus requisitos. Consulte Plataforma de datos de Azure Monitor.
¿Hay una cantidad máxima de datos que puedo recopilar en Azure Monitor?
No hay límite en la cantidad de datos de métricas que se pueden recopilar, pero estos datos se almacenan durante
un máximo de 93 días. Consulte Retención de métricas. No hay límite en la cantidad de datos de registro que se
pueden recopilar, pero puede verse afectado por el plan de tarifa que elija para el área de trabajo de Log Analytics.
Consulte los detalles de los precios.
¿Cómo puedo acceder a los datos recopilados por Azure Monitor?
Insights y las soluciones proporcionan una experiencia personalizada para trabajar con los datos almacenados en
Azure Monitor. Puede trabajar directamente con los datos de registro mediante una consulta de registro escrita en
el lenguaje de consulta Kusto (KQL). En Azure Portal, puede escribir y ejecutar consultas y analizar los datos de
forma interactiva mediante Log Analytics. Puede analizar las métricas en Azure Portal con el Explorador de métricas.
Consulte Análisis de los datos de registro en Azure Monitor e Introducción al Explorador de métricas de Azure.
Soluciones e Insights
¿Qué es una conclusión en Azure Monitor?
Insights proporciona una experiencia de supervisión personalizada para determinados servicios de Azure. Usa las
mismas métricas y registros que otras características de Azure Monitor, pero puede recopilar datos adicionales y
proporcionar una experiencia única en Azure Portal. Consulte Insights en Azure Monitor.
Para ver información detallada en Azure Portal, consulte la sección Insights del menú Monitor o la sección
Super visión del menú del servicio.
¿Qué es una solución en Azure Monitor?
Las soluciones de supervisión son conjuntos empaquetados de lógica para la supervisión de una determinada
aplicación o servicio que se basan en las características de Azure Monitor. Recopilan datos de registro en Azure
Monitor y proporcionan consultas y vistas de registro para su análisis con una experiencia común en Azure Portal.
Consulte Soluciones de supervisión en Azure Monitor.
Para ver las soluciones en Azure Portal, haga clic en Más en la sección Insights del menú Monitor . Haga clic en
Agregar para agregar más soluciones al área de trabajo.
Registros
¿Cuál es la diferencia entre los registros de Azure Monitor y Azure Data Explorer?
El Explorador de datos de Azure es un servicio de exploración de datos altamente escalable y rápido para datos de
telemetría y registro. Los registros de Azure Monitor se basan en Azure Data Explorer y usan el mismo lenguaje de
consulta Kusto (KQL) con algunas diferencias menores. Consulte Diferencias en el lenguaje de consulta de los
registros de Azure Monitor.
¿Cómo puedo recuperar los datos de registro?
Todos los datos se recuperan de un área de trabajo de Log Analytics mediante una consulta de registro escrita en el
lenguaje de consulta Kusto (KQL). Puede escribir sus propias consultas o usar soluciones e Insights que incluyan
consultas de registro para una aplicación o servicio determinados. Consulte Introducción a las consultas de registro
en Azure Monitor.
¿Puedo eliminar datos de un área de trabajo de Log Analytics?
Los datos se eliminan de un área de trabajo en función del período de retención. Puede eliminar datos específicos
por motivos de privacidad o de cumplimiento. Consulte Cómo exportar y eliminar datos privados para más
información.
¿Qué es un área de trabajo de Log Analytics?
Todos los datos de registro que recopila Azure Monitor se almacenan en un área de trabajo de Log Analytics. Un
área de trabajo es esencialmente un contenedor donde los datos de registro se recopilan de diversos orígenes.
Puede tener una sola área de trabajo de Log Analytics para todos los datos de supervisión o puede tener requisitos
para varias áreas de trabajo. Consulte Diseño de la implementación de registros de Azure Monitor.
¿Puedo trasladar un área de trabajo de Log Analytics existente a otra suscripción de Azure?
Puede trasladar un área de trabajo entre grupos de recursos o suscripciones, pero no a otra región. Consulte
Traslado de un área de trabajo de Log Analytics a otro grupo de recursos o suscripción.
¿Por qué no puedo ver los botones Explorador de consultas y Guardar en Log Analytics?
Los botones Explorador de consultas , Guardar y Nueva aler ta de reglas no están disponibles cuando el
ámbito de la consulta se establece en un recurso específico. Para crear alertas o guardar o cargar una consulta, Log
Analytics se debe enfocar a un área de trabajo. Para abrir Log Analytics en un contexto de área de trabajo,
seleccione Registros en el menú Azure Monitor . Se selecciona la última área de trabajo usada, pero puede
seleccionar cualquier otra área de trabajo. Consulte Ámbito e intervalo de tiempo de una consulta de registro en
Log Analytics de Azure Monitor.
¿Por qué recibo el error: "Debe registrar el proveedor de recursos 'Microsoft.Insights' de esta suscripción para
habilitar esta consulta" al abrir Log Analytics desde una máquina virtual?
Muchos proveedores de recursos se registran automáticamente. Sin embargo, debe registrar manualmente algunos
de ellos. El ámbito de registro es siempre la suscripción. Para más información, consulte Proveedores de recursos y
sus tipos.
¿Por qué no recibo un mensaje de error de acceso cuando abro Log Analytics desde una máquina virtual?
Para ver los registros de la VM, debe tener permiso de lectura para aquellos espacios de trabajo que almacenan los
registros de VM. En esos casos, su administrador debe otorgarle permisos en Azure.
Métricas
¿Por qué las métricas del sistema operativo invitado de la máquina virtual de Azure no aparecen en el Explorador
de métricas?
Las métricas de plataforma se recopilan automáticamente para los recursos de Azure. Pero se debe realizar cierta
configuración para recopilar métricas del sistema operativo invitado de una máquina virtual. En el caso de una
máquina virtual Windows, instale la extensión de diagnóstico y configure el receptor de Azure Monitor, tal como se
describe en Instalación y configuración de la extensión de Azure Diagnostics (WAD) para Windows. En el caso de
Linux, instale el agente Telegraf, tal como se describe en Recopilación de métricas personalizadas para una máquina
virtual Linux con el agente de InfluxData Telegraf.
Alertas
¿Qué es una alerta en Azure Monitor?
Las alertas le informan de forma proactiva cuando se detectan condiciones importantes en los datos que supervisa.
Le permiten identificar y solucionar los problemas antes de que los usuarios del sistema puedan verlos. Hay varios
tipos de alertas:
Métrica: el valor de una métrica supera un umbral.
Consulta de registro: los resultados de una consulta de registro coinciden con los criterios definidos.
Registro de actividad: un evento del registro de actividad coincide con los criterios definidos.
Prueba web: los resultados de la prueba de disponibilidad coinciden con los criterios definidos.
Consulte Introducción a las alertas en Microsoft Azure.
¿Qué es un grupo de acciones?
Un grupo de acciones es una colección de notificaciones y acciones que pueden ser desencadenados por una alerta.
Varias alertas pueden usar un solo grupo de acciones, lo que le permite aprovechar conjuntos comunes de
notificaciones y acciones. Consulte Creación y administración de grupos de acciones en Azure Portal.
¿Qué es una regla de acción?
Una regla de acción le permite modificar el comportamiento de un conjunto de alertas que coinciden con
determinados criterios. Esto permite satisfacer requisitos como la desactivación de las acciones de alerta durante
una ventana de mantenimiento. También puede aplicar un grupo de acciones a un conjunto de alertas en lugar de
aplicarlo directamente a las reglas de alertas. Consulte Reglas de acción.
Agentes
¿Azure Monitor requiere un agente?
Solo es necesario un agente para recopilar datos del sistema operativo y las cargas de trabajo de las máquinas
virtuales. Las máquinas virtuales pueden encontrarse en Azure, en otro entorno en la nube o en el entorno local.
Consulte Introducción a los agentes de Azure Monitor.
¿Qué diferencia hay entre los agentes de Azure Monitor?
La extensión de diagnósticos de Azure es para máquinas virtuales de Azure y recopila datos para las métricas de
Azure Monitor, Azure Storage y Azure Event Hubs. El agente de Log Analytics es para máquinas virtuales de Azure,
otro entorno en la nube o el entorno local y recopila datos para los registros de Azure Monitor. El agente de
dependencias requiere el agente de Log Analytics y recopila detalles de procesos y dependencias. Consulte
Introducción a los agentes de Azure Monitor.
¿El tráfico del agente usa la conexión de ExpressRoute?
El tráfico a Azure Monitor utiliza el circuito de ExpressRoute de emparejamiento de Microsoft. En la documentación
de ExpressRoute, se describen los distintos tipos de tráfico de ExpressRoute.
¿Cómo puedo confirmar que el agente de Log Analytics puede comunicarse con Azure Monitor?
En el panel de control del equipo del agente, seleccione Seguridad y configuración ,
**Microsoft Monitoring Agent. En la pestaña Azure Log Analytics (OMS) , un icono de marca de verificación
verde confirma que el agente puede comunicarse con Azure Monitor. Un icono de advertencia amarillo significa que
el agente tiene problemas. Una causa habitual es que el servicio Microsoft Monitoring Agent se ha detenido.
Use el Administrador de control de servicios para reiniciar el servicio.
¿Cómo puedo detener la comunicación del agente de Log Analytics con Azure Monitor?
En el caso de los agentes conectados a Log Analytics directamente, abra el panel de control y seleccione Seguridad
y configuración , Microsoft Monitoring Agent . Elimine todas las áreas de trabajo enumeradas en la pestaña
Azure Log Analytics (OMS) . En System Center Operations Manager, quite el equipo de la lista de equipos que
administra Log Analytics. Operations Manager actualiza la configuración del agente para que ya no informe a Log
Analytics.
¿Qué cantidad de datos se envía por agente?
La cantidad de datos enviada por agente depende de:
Las soluciones habilitadas
El número de registros y contadores de rendimiento recopilados
El volumen de datos de los registros
Consulte Administración del uso y los costos con los registros de Azure Monitor para más información.
En el caso de los equipos capaces de ejecutar el agente de WireData, use la siguiente consulta para ver la cantidad
de datos enviada:
WireData
| where ProcessName == "C:\\Program Files\\Microsoft Monitoring Agent\\Agent\\MonitoringHost.exe"
| where Direction == "Outbound"
| summarize sum(TotalBytes) by Computer
¿Cuánto ancho de banda de red usa Microsoft Monitoring Agent (MMA ) al enviar datos a Azure Monitor?
El ancho de banda equivale a una función de la cantidad de datos enviados. Los datos se comprimen al enviarse por
la red.
¿Cómo se puede recibir una notificación cuando se detiene la recopilación de datos del agente de
Log Analytics?
Siga los pasos explicados en Crear una nueva alerta de registro para recibir una notificación cuando se detenga la
recopilación de datos. Use la siguiente configuración para la regla de alertas:
Definición de la condición de la aler ta : especifique el área de trabajo de Log Analytics como el destino del
recurso.
Criterios de aler ta
Nombre de señal : Búsqueda de registros personalizada
Consulta de búsqueda :
Heartbeat | summarize LastCall = max(TimeGenerated) by Computer | where LastCall < ago(15m)
Lógica de aler ta : En función del número de resultados, Condición mayor que, Valor de umbral 0
Evaluado según : Período (en minutos) 30, Frecuencia (en minutos) 10
Definición de detalles de la aler ta
Name : Recopilación de datos detenida
Gravedad : Warning (ADVERTENCIA)
Especifique un grupo de acciones existente o nuevo para que cuando la alerta de registro coincida con los criterios,
se le notifique si faltan latidos durante más de 15 minutos.
¿Cuáles son los requisitos de firewall para los agentes de Azure Monitor?
Consulte Requisitos del firewall de red para más información sobre los requisitos de firewall.
Visualizaciones
¿Por qué no puedo ver el Diseñador de vistas?
El Diseñador de vistas solo está disponible para los usuarios asignados que tengan permiso de colaborador o
superior en el área de trabajo de Log Analytics.
Problemas de configuración
Tengo problemas con la configuración de:
Aplicación .NET
Supervisión de una aplicación que ya se está ejecutando
Diagnóstico de Azure
Aplicaciones web de Java
No recibo datos de mi servidor:
Establecer excepciones del firewall
Configurar un servidor ASP.NET
Configurar un servidor de Java
Cuántos recursos de Application Insights se deben implementar:
¿Cómo diseñar la implementación de Application Insights: uno frente a muchos recursos?
¿Se puede usar Application Insights con...?
Aplicaciones web en un servidor IIS en una máquina virtual de Azure o conjunto de escalado de máquinas
virtuales de Azure
Aplicaciones web en un servidor de IIS: local o en una máquina virtual
Aplicaciones de Node.js
Aplicaciones web de Azure
Cloud Services en Azure
Servidores de aplicaciones que se ejecutan en Docker
Aplicaciones web de una sola página
SharePoint
Aplicación de escritorio de Windows
Otras plataformas
¿Es gratis?
Sí, para su uso experimental. En el plan de precios básico, la aplicación puede enviar una determinada asignación de
datos cada mes de forma gratuita. La asignación disponible es lo suficientemente amplia como para abarcar el
desarrollo y la publicación de una aplicación para un número reducido de usuarios. Puede establecer un límite para
evitar que se procese más de una determinada cantidad de datos.
Los volúmenes más grandes de telemetría se cobran por GB. Se proporcionan algunas sugerencias sobre cómo
limitar los gastos.
El plan Enterprise cobra por cada día que cada nodo de servidor web envía telemetría. Resulta adecuado si desea
usar exportación continua a gran escala.
Lea el plan de precios.
¿Cuánto cuesta?
Abra la página Uso y costos estimados en un recurso de Application Insights. Hay un gráfico de uso reciente.
Puede establecer un límite de volumen de datos, si quiere.
Abra la hoja de facturación de Azure para ver las facturas de todos los recursos.
¿Qué modifica Application Insights en mi proyecto?
Los detalles dependen del tipo de proyecto. Para una aplicación web:
Agregue estos archivos al proyecto:
ai.js
Instale estos paquetes de NuGet:
API de Application Insights : la API central.
API de Application Insights para aplicaciones web : se usa para enviar la telemetría del servidor.
API de Application Insights para aplicaciones JavaScript : se usa para enviar la telemetría del cliente.
El paquete incluye estos ensamblados:
Microsoft.ApplicationInsights
Microsoft.ApplicationInsights.Platform
Inserta elementos en:
Web.config
packages.config
(Solo nuevos proyectos: si agrega Application Insights a un proyecto existente, tiene que hacerlo manualmente).
Inserte fragmentos de código en el código de cliente y servidor para inicializarlos con el identificador de
recursos de Application Insights. Por ejemplo, en una aplicación MVC, el código se inserta en la página maestra
Views/Shared/_Layout.cshtml
¿Cómo se puede actualizar desde versiones anteriores de SDK?
Consulte las notas de la versión del SDK adecuado para el tipo de aplicación.
¿Cómo puedo cambiar el recurso de Azure al que mi proyecto envía datos?
En el Explorador de soluciones, haga clic con el botón derecho en ApplicationInsights.config y elija Actualizar
Application Insights . Puede enviar los datos a un recurso nuevo o existente en Azure. El Asistente para
actualización cambia la clave de instrumentación en ApplicationInsights.config, que determina dónde el SDK del
servidor envía los datos. A menos que desactive la opción "Actualizar todo", también cambiará la clave donde
aparece en las páginas web.
¿Puedo usar providers('Microsoft.Insights', 'components').apiVersions[0] en las implementaciones de Azure
Resource Manager?
No se recomienda usar este método para rellenar la versión de la API. La versión más reciente puede representar
versiones preliminares que pueden contener cambios importantes. Incluso con versiones más recientes que no son
de versión preliminar, las versiones de API no siempre son compatibles con versiones anteriores de plantillas
existentes o, en algunos casos, puede que la versión de la API no esté disponible para todas las suscripciones.
¿Qué es el Monitor de estado?
Una aplicación de escritorio que puede usar en el servidor web de IIS para ayudar a configurar Application Insights
en aplicaciones web. No recopila telemetría: puede detenerla cuando no vaya a configurar una aplicación.
Más información.
¿Qué telemetría recopila Application Insights?
De las aplicaciones web de servidor:
Solicitudes HTTP
Dependencias. Llamadas a: instancias de SQL Database; llamadas HTTP a servicios externos; Azure Cosmos DB,
tabla, almacenamiento de blobs y colas.
Excepciones y seguimientos de pila.
Contadores de rendimiento: si usa el Monitor de estado, la supervisión de Azure para App Services, la
supervisión de Azure para la máquina virtual o el conjunto de escalado de máquinas virtuales o el escritor de
collectd de Application Insights.
Eventos y métricas personalizados que puede crear mediante código.
Registros de seguimiento si configura el recopilador adecuado.
De las páginas web de cliente:
Recuentos de vistas de página
Llamadas AJAX: solicitudes realizadas desde un script en funcionamiento
Datos de carga de vista de página
Recuentos de usuarios y sesiones
Id. de usuario autenticados.
De otros orígenes, si los configura:
Importación a Analytics
Log Analytics
Logstash
¿Puedo filtrar o modificar algunos datos de telemetría?
Sí, en el servidor puede escribir:
Procesador de telemetría para filtrar o agregar propiedades a los elementos de telemetría seleccionados antes
de que se envíen desde su aplicación.
Inicializador de telemetría para agregar propiedades a todos los elementos de telemetría.
Más información sobre ASP.NET o Java.
¿Cómo se calculan los datos de ciudad, país o región y otra información de ubicación geográfica?
Buscamos la dirección IP (IPv4 o IPv6) del cliente web mediante GeoLite2.
Telemetría del explorador: recopilamos la dirección IP del remitente.
Telemetría del servidor: el módulo de Application Insights recopila la dirección IP del cliente. No se recopila si
X-Forwarded-For está establecido.
Para obtener más información sobre cómo se recopilan la dirección IP y los datos de geolocalización en
Application Insights, vea este artículo.
Puede configurar ClientIpHeaderTelemetryInitializer para tomar la dirección IP de un encabezado distinto. En
algunos sistemas, por ejemplo, se mueve mediante un servidor proxy, un equilibrador de carga o la red CDN
X-Originating-IP . Más información.
También puede usar Power BI para mostrar la telemetría de solicitudes en un mapa.

¿Cuánto tiempo se retienen los datos en el portal? ¿Es seguro?
Eche un vistazo a Privacidad y retención de los datos.
¿Qué ocurre con los datos de telemetría de Application Insights cuando un servidor o dispositivo pierde la
conexión con Azure?
Todos nuestros SDK, incluido el SDK web, incluyen "transporte confiable" o "transporte eficaz". Cuando el servidor o
el dispositivo pierde la conexión con Azure, los datos de telemetría se almacenan localmente en el sistema de
archivos (los SDK de servidor) o en el almacenamiento de la sesión HTML5 (SDK web). El SDK volverá a intentar
periódicamente enviar estos datos de telemetría hasta que nuestro servicio de ingesta los considere "obsoletos"
(48 horas en el caso de los registros y 30 minutos en el caso de las métricas). Los datos de telemetría obsoletos se
eliminarán. En algunos casos, como cuando el almacenamiento local está lleno, no se realizará ningún reintento.
¿Se podrían enviar datos personales en la telemetría?
Es posible si el código envía tales datos. También puede ocurrir si las variables de los seguimientos de pila incluyen
datos personales. El equipo de desarrollo debe llevar a cabo las evaluaciones de riesgo para asegurarse de que los
datos personales se tratan correctamente. Más información sobre la retención y la privacidad de los datos.
Todos los octetos de la dirección web del cliente siempre se establecen en 0 después de que se buscan los atributos
de ubicación geográfica.
Mi clave de instrumentación es visible en el origen de mi página web.
Esta es una práctica común en las soluciones de supervisión.
No se puede usar para robar sus datos.
Se podría usar para sesgar los datos o desencadenar alertas.
No hemos tenido noticias de que algún cliente haya tenido esos problemas.
Podría:
Usar dos claves de instrumentación independientes (recursos independientes de Application Insights) para los
datos de cliente y servidor. Or
Escribir un servidor proxy que se ejecute en el servidor y hacer que el cliente web envíe datos a través de dicho
servidor proxy.
¿Cómo puedo ver datos POST en Búsqueda de diagnóstico?
Los datos POST no se registran automáticamente, pero se puede usar una llamada TrackTrace: incluya los datos en
el parámetro de mensaje. Este tiene un límite de tamaño superior al de las propiedades de cadena, aunque no se
puede filtrar por él.
¿Debo usar uno o varios recursos de Application Insights?
Utilice un único recurso para todos los componentes o funciones en un sistema de negocio individual. Use recursos
independientes para las versiones de desarrollo, prueba y lanzamiento, y para aplicaciones independientes.
Consulte la explicación aquí.
Ejemplo: servicio en la nube con roles web y de trabajo
¿Cómo se cambia de forma dinámica la clave de instrumentación?
La explicación aquí
¿Qué son los recuentos de usuarios y sesiones?
El SDK de JavaScript establece una cookie de usuario en el cliente web para identificar los usuarios que vuelven
y una cookie de sesión para agrupar las actividades.
Si no hay ningún script de cliente, puede establecer cookies en el servidor.
Si un usuario real usa su sitio en exploradores diferentes o usa la exploración InPrivate o de incógnito, o distintas
máquinas, entonces se contabilizará más de una vez.
Para identificar un usuario que ha iniciado sesión en todas las máquinas y exploradores, agregue una llamada a
setAuthenticatedUserContext().
¿He habilitado todo en Application Insights?
Q UÉ DEB ERÍA VER C Ó M O C O N SEGUIRLO RA Z O N ES PA RA Q UERERLO
Gráficos de disponibilidad Pruebas web Saber que la aplicación web funciona
Rendimiento de la aplicación de Agregue Application Insights a su Detectar problemas de rendimiento

servidor: tiempos de respuesta, etc. proyecto o instale el Monitor de estado
de Application Insights en un servidor
(o escriba su propio código para realizar
un seguimiento de las dependencias).
Telemetría de dependencia Instalar el Monitor de estado de Diagnosticar problemas con las bases de
Application Insights en el servidor datos u otros componentes externos
Obtener seguimientos de pila de las Insertar llamadas TrackException en el Detectar y diagnosticar excepciones
excepciones código (aunque algunas se notifican
automáticamente)
Buscar seguimientos del registro Agregar un adaptador de registro Diagnosticar excepciones, problemas de
rendimiento
Aspectos básicos del uso de cliente: Inicializador de JavaScript en páginas Análisis de uso
vistas de página, sesiones,... web
Métricas personalizadas de cliente Seguimiento de llamadas en páginas Mejorar la experiencia del usuario
web
Métricas personalizadas de servidor Seguimiento de llamadas en el código Business intelligence

de servidor
¿Por qué los recuentos de los gráficos de búsqueda y métrica no son iguales?
El muestreo reduce el número de elementos de telemetría (solicitudes, eventos personalizados, etc.) que se envían
realmente desde su aplicación al portal. En el gráfico de búsqueda, ve el número de elementos realmente recibidos.
En los gráficos de métrica que muestran un recuento de eventos, ve el número de eventos originales que se han
producido.
Cada elemento que se transmite lleva una propiedad itemCount que muestra cuántos eventos originales
representa ese elemento. Para ver el muestreo en funcionamiento, puede ejecutar esta consulta en Analytics:
requests | summarize original_events = sum(itemCount), transmitted_events = count()
Automation
Configuración de Application Insights
También puede escribir scripts de PowerShell mediante el Monitor de recursos de Azure para:
Crear y actualizar recursos de Application Insights
Consultar el plan de precios
Obtener la clave de instrumentación
Agregar una alerta de métrica
Agregar una prueba de disponibilidad.
No puede configurar un informe del Explorador de métricas ni configurar la exportación continua.
Consulta de la telemetría
Use la API de REST para ejecutar consultas de Analytics.
¿Cómo puedo establecer una alerta sobre un evento?
Las alertas de Azure solo se establecen sobre métricas. Cree una métrica personalizada que cruce un umbral de
valor cada vez que se produzca el evento. A continuación, establezca una alerta sobre la métrica. Recibirá una
notificación cada vez que la métrica cruce el umbral en cualquier dirección; no recibirá una notificación hasta que se
cruza por primera vez, sin importar si el valor inicial es alto o bajo; siempre hay una latencia de algunos minutos.
¿Existen cargos por transferencia de datos entre una aplicación web de Azure y Application Insights?
Si la aplicación web de Azure se hospeda en un centro de datos donde hay un punto de conexión de recopilación
de Application Insights, no hay ningún cargo.
Si no hay ningún punto de conexión de recopilación en el centro de datos host, se le cobrarán los cargos
salientes de Azure de la telemetría de la aplicación.
Esto no depende de dónde se encuentre hospedado su recurso de Application Insights. Simplemente depende de la
distribución de nuestros puntos de conexión.
¿Puedo enviar telemetría al portal de Application Insights?
Se recomienda usar nuestros SDK y la API de SDK. Hay variantes del SDK para distintas plataformas. Estos SDK
controlan el almacenamiento en búfer, la compresión, la limitación, los reintentos, etc. Sin embargo, el esquema de
ingesta y el protocolo de punto de conexión son públicos.
¿Puedo supervisar un servidor web de una intranet?
Sí, pero será necesario permitir el tráfico en nuestros servicios mediante excepciones de firewall o redirecciones del
proxy.
QuickPulse https://rt.services.visualstudio.com:443
ApplicationIdProvider https://dc.services.visualstudio.com:443
TelemetryChannel https://dc.services.visualstudio.com:443
Consulte nuestra lista completa de servicios y direcciones IP aquí.
Excepción de firewall
Permita que el servidor web envíe telemetría a nuestros puntos de conexión.
Redirección de la puerta de enlace
Redirija el tráfico desde su servidor a una puerta de enlace de su intranet mediante la sobrescritura de los puntos
de conexión en la configuración. Si estas propiedades de "punto de conexión" no están presentes en la
configuración, estas clases usarán los valores predeterminados que se muestran en el ejemplo
ApplicationInsights.config siguiente.
La puerta de enlace debe redirigir el tráfico a la dirección base del punto de conexión. En la configuración,
reemplace los valores predeterminados por http://<your.gateway.address>/<relative path> .
Ej e m p l o d e A p p l i c a t i o n I n si g h t s.c o n fi g c o n p u n t o s d e c o n e x i ó n p r e d e t e r m i n a d o s:
<ApplicationInsights>
...
<TelemetryModules>
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModule,
Microsoft.AI.PerfCounterCollector">
<QuickPulseServiceEndpoint>https://rt.services.visualstudio.com/QuickPulseService.svc</QuickPulseServiceEndpoin
t>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
<EndpointAddress>https://dc.services.visualstudio.com/v2/track</EndpointAddress>
</TelemetryChannel>
...
<ApplicationIdProvider
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsApplicationId
Provider, Microsoft.ApplicationInsights">
<ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndpoint>
</ApplicationIdProvider>
...
</ApplicationInsights>
NOTE
ApplicationIdProvider está disponible a partir de la versión 2.6.0.
Paso a través de proxy

El paso a través de proxy se puede lograr mediante la configuración de un proxy de nivel de equipo o de nivel de
aplicación. Para obtener más información, vea el artículo de dotnet sobre DefaultProxy.
Ejemplo de Web.config:
<system.net>
<defaultProxy>
<proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
</defaultProxy>
</system.net>
¿Puedo ejecutar pruebas web de disponibilidad en un servidor de intranet?

Nuestras pruebas web se ejecutan en puntos de presencia que están repartidos por todo el mundo. Hay dos
soluciones:
Puerta de firewall: permitir solicitudes al servidor desde la lista larga y modificable de agentes de prueba web.
Escribir su propio código para enviar solicitudes periódicas a su servidor desde dentro de la intranet. Con este
fin, puede ejecutar pruebas web de Visual Studio. El evaluador puede enviar los resultados a Application Insights
mediante la API TrackAvailability().
¿Cuánto tiempo tarda la recopilación de telemetría?
La mayoría de los datos de Application Insights tienen una latencia de menos de 5 minutos. Algunos datos pueden
tardar más tiempo, sobre todo, los archivos de registro más grandes. Para más información, consulte Acuerdo de
Nivel de Servicio de Application Insights.
Application Insights no siempre captura las respuestas HTTP 502 y 503
Application Insights no siempre captura los errores "502 Puerta de enlace incorrecta" y "503 Servicio no
disponible". Si solo se usa JavaScript del lado cliente para la supervisión, este sería el comportamiento esperado, ya
que la respuesta de error se devuelve antes que la página que contiene el encabezado HTML con el fragmento de
código de JavaScript de supervisión que se está representando.
Si la respuesta 502 o 503 se ha enviado desde un servidor con la supervisión del lado servidor habilitada, el SDK de
Application Insights recopila los errores.
Pero todavía hay casos en los que, incluso con la supervisión del lado servidor habilitada en el servidor web de una
aplicación, Application Insights no captura un error 502 o 503. Muchos servidores web modernos no permiten a un
cliente comunicarse directamente, sino que emplean soluciones como los servidores proxy inversos para pasar
información entre el cliente y los servidores web front-end.
En este escenario, se puede devolver una respuesta 502 o 503 a un cliente debido a un problema en la capa de
proxy inverso que no sería capturado de serie por Application Insights. Para ayudar a detectar problemas en esta
capa, es posible que tenga que reenviar registros desde el proxy inverso a Log Analytics y crear una regla
personalizada para buscar respuestas 502/503. Para obtener más información sobre las causas comunes de los
errores 502 y 503, vea el artículo de solución de problemas de Azure App Service "502 Puerta de enlace no válida"
y "503 Servicio no disponible".

Azure Monitor para contenedores. Si tiene alguna otra pregunta sobre esta solución, vaya al foro de discusión y
publíquela. Si una pregunta es frecuente, se agrega a este artículo para que se pueda encontrar de forma rápida y
sencilla.
La característica de mantenimiento se encuentra en versión preliminar privada
Estamos planeando realizar varios cambios para agregar funcionalidad y dar respuesta a los comentarios. La
característica de mantenimiento va a pasar a una versión preliminar privada a finales de junio de 2020. Para
obtener información adicional, revise el siguiente Anuncio de actualizaciones de Azure.
¿Qué representa Otros procesos en la vista de nodo?
Otros procesos está diseñado para ayudarle a entender claramente la causa principal del uso elevado de recursos
en el nodo. Esto le permite distinguir el uso entre los procesos en contenedores y los procesos fuera de
contenedores.
¿Qué son estos Otros procesos ?
Representan procesos fuera de contenedores que se ejecutan en el nodo.
¿Cómo se calcula esto?
Otros procesos = Uso total de CAdvisor - Uso del proceso en contenedores
Otros procesos incluye:
Procesos fuera de contenedores de Kubernetes administrados o autoadministrados
Procesos en contenedores en tiempo de ejecución
Kubelet
Procesos del sistema que se ejecutan en el nodo
Otras cargas de trabajo que no son de Kubernetes que se ejecutan en hardware de nodo o VM
No veo que los valores de propiedad Name e Image se rellenen cuando consulto la tabla ContainerLog.
En el caso de la versión del agente ciprod12042019 y versiones posteriores, estas dos propiedades no se rellenan
de forma predeterminada en cada línea de registro con el fin de reducir el costo generado en los datos de registro
recopilados. Hay dos opciones para consultar la tabla que incluyen estas propiedades con sus valores:
Opción 1
Combinar otras tablas para incluir estos valores de propiedad en los resultados.
Modifique las consultas para que incluyan las propiedades Image e ImageTag de la tabla ContainerInventory
mediante la combinación de la propiedad ContainerID. Puede incluir la propiedad Name (como aparecía
anteriormente en la tabla ContainerLog ) del campo ContaineName de la tabla KubepodInventory mediante la
combinación de la propiedad ContainerID. Esta es la opción recomendada.
El ejemplo siguiente es una consulta detallada de ejemplo que explica cómo obtener estos valores de campo con
combinaciones.
//lets say we are querying an hour worth of logs

let startTime = ago(1h);
let endTime = now();
//below gets the latest Image & ImageTag for every containerID, during the time window
let ContainerInv = ContainerInventory | where TimeGenerated >= startTime and TimeGenerated < endTime |
summarize arg_max(TimeGenerated, *) by ContainerID, Image, ImageTag | project-away TimeGenerated | project
ContainerID1=ContainerID, Image1=Image ,ImageTag1=ImageTag;
//below gets the latest Name for every containerID, during the time window
let KubePodInv = KubePodInventory | where ContainerID != "" | where TimeGenerated >= startTime | where
TimeGenerated < endTime | summarize arg_max(TimeGenerated, *) by ContainerID2 = ContainerID,
Name1=ContainerName | project ContainerID2 , Name1;
//now join the above 2 to get a 'jointed table' that has name, image & imagetag. Outer left is safer in-case
there are no kubepod records are if they are latent
let ContainerData = ContainerInv | join kind=leftouter (KubePodInv) on $left.ContainerID1 ==
$right.ContainerID2;
//now join ContainerLog table with the 'jointed table' above and project-away redundant fields/columns and
rename columns that were re-written
//Outer left is safer so you dont lose logs even if we cannot find container metadata for loglines (due to
latency, time skew between data types etc...)
ContainerLog
| where TimeGenerated >= startTime and TimeGenerated < endTime
| join kind= leftouter (
ContainerData
) on $left.ContainerID == $right.ContainerID2 | project-away ContainerID1, ContainerID2, Name, Image, ImageTag
| project-rename Name = Name1, Image=Image1, ImageTag=ImageTag1
Opción 2
Volver a habilitar la recopilación para estas propiedades en cada línea de registro de contenedor.
Si la primera opción no es conveniente debido a los cambios de consulta relacionados, puede volver a habilitar la
recopilación de estos campos si habilita el valor log_collection_settings.enrich_container_logs en el mapa de
configuración del agente, como se describe en los valores de configuración de recopilación de datos.
NOTE
La segunda opción no se recomienda con clústeres de gran tamaño que tengan más de 50 nodos, ya que genera llamadas del
servidor de API desde cada nodo del clúster para realizar este enriquecimiento. Esta opción también aumenta el tamaño de
los datos de cada línea de registro recopilada.
¿Puedo ver las métricas recopiladas en Grafana?

Azure Monitor para contenedores admite la visualización de métricas almacenadas en el área de trabajo de Log
Analytics en los paneles de Grafana. Hemos proporcionado una plantilla que puede descargar del repositorio del
panel de Grafana para empezar a trabajar y como referencia para obtener información sobre cómo consultar datos
adicionales de los clústeres supervisados para visualizarlos en paneles de Grafana personalizados.
¿Puedo supervisar el clúster con el motor de AKS con Azure Monitor para contenedores?
Azure Monitor para contenedores admite la supervisión de cargas de trabajo de contenedor implementadas en
clústeres con el motor de AKS (anteriormente conocido como motor de ACS) hospedados en Azure. Para más
información y una introducción a los pasos necesarios para habilitar la supervisión de este escenario, consulte Uso
de Azure Monitor para contenedores de para el motor de AKS.
¿Por qué no veo datos en mi área de trabajo de Log Analytics?
Si no puede ver ningún dato en el área de trabajo de Log Analytics en un momento determinado cada día, puede
deberse a que ha alcanzado el límite predeterminado de 500 MB, o bien el límite diario especificado para controlar
la cantidad de datos que se recopila a diario. Cuando se alcanza el límite diario, la recopilación de datos se detiene y
solo se reanuda al día siguiente. Para revisar el uso que hace de los datos y actualizar a un plan de tarifa distinto en
función de los patrones de uso que tenga previstos, vea Uso de datos de Log Analytics y costes.
¿Cuáles son los estados de contenedor especificados en la tabla ContainerInventory?
La tabla ContainerInventory contiene información sobre los contenedores detenidos y en ejecución. La tabla se
rellena con un flujo de trabajo dentro del agente que consulta el docker de todos los contenedores (en ejecución y
detenidos) y reenvía dichos datos al área de trabajo de Log Analytics.
¿Cómo se resuelve el error que indica que falta el registro de suscripción?
Si recibe el error Missing Subscription registration for Microsoft.OperationsManagement (Falta el registro
de suscripción de Microsoft.OperationsManagement), puede resolverlo registrando el proveedor de recursos
Microsoft.OperationsManagement en la suscripción en la que está definida el área de trabajo. La
documentación sobre cómo hacer esto se puede encontrar aquí.
¿Se admiten clústeres de AKS con RBAC habilitado?
La solución de supervisión de contenedores no admite RBAC, pero Azure Monitor para contenedores sí. La página
de detalles de la solución no puede mostrar la información correcta en las hojas que muestran datos para estos
clústeres.
¿Cómo habilitar la recopilación de registros para contenedores en el espacio de nombres kube -system mediante
Helm?
La recopilación de registros de contenedores en el espacio de nombres kube-system está deshabilitada de forma
predeterminada. La recopilación de registros puede habilitarse mediante la configuración de una variable de
entorno en omsagent. Para obtener más información, vea la página de GitHub sobre Azure Monitor para
contenedores.
¿Cómo se puede actualizar el complemento omsagent a la última versión?
Para obtener información sobre cómo actualizar el agente, vea la información sobre la administración del agente.
¿Cómo se puede habilitar el registro de varias líneas?
Actualmente, Azure Monitor para contenedores no admite el registro de varias líneas, pero hay soluciones
alternativas disponibles. Puede configurar todos los servicios para que escriban en formato JSON y, a continuación,
Docker/Moby los escribirán como una sola línea.
Por ejemplo, puede ajustar el registro como un objeto JSON como se muestra en el ejemplo siguiente para una
aplicación de Node.js de ejemplo:
console.log(json.stringify({
"Hello": "This example has multiple lines:",
"Docker/Moby": "will not break this into multiple lines",
"and you will receive":"all of them in log analytics",
"as one": "log entry"
}));
Estos datos tendrán un aspecto similar al del siguiente ejemplo en Azure Monitor cuando se realiza una consulta en
los registros:
LogEntry : ({"Hello": "This example has multiple lines:","Docker/Moby": "will not break this into multiple
lines", "and you will receive":"all of them in log analytics", "as one": "log entry"}
Para obtener una visión detallada del problema, visite el siguiente vínculo de GitHub.
¿Cómo se resuelven los errores de Azure AD al habilitar los registros dinámicos?
Puede ver el siguiente error: la dirección URL de respuesta especificada en la solicitud no coincide con
las direcciones URL de respuesta configuradas para la aplicación "<identificador de la aplicación>" .
La solución para resolver esto puede encontrase en el artículo Vista de los datos de contenedor en tiempo real con
Azure Monitor para contenedores.
¿Por qué no se puede actualizar el clúster después de incorporarlo?
Si, después de habilitar Azure Monitor para contenedores en un clúster de AKS, elimina el área de trabajo de Log
Analytics a la que el clúster enviaba datos, se producirá un error cuando intente actualizar dicho clúster. Para
solucionar este problema, tendrá que deshabilitar la supervisión y, después, volver a habilitarla, pero de forma que
haga referencia a otra área de trabajo válida de la suscripción. Tras ello, cuando intente llevar a cabo la actualización
del clúster de nuevo, debería procesarse y completarse correctamente.
¿Qué puertos y dominios debo abrir o permitir para el agente?
Consulte los requisitos del firewall de red para obtener la información de configuración del servidor proxy y el
firewall necesaria para el agente en contenedor con las nubes de Azure, Azure US Government y Azure China
21Vianet.

Azure Monitor para VM. Si tiene alguna otra pregunta sobre esta solución, vaya al foro de discusión y publíquela. Si
una pregunta es frecuente, se agrega a este artículo para que se pueda encontrar de forma rápida y sencilla.
¿Puede incorporarse a un área de trabajo existente?
Si las máquinas virtuales ya están conectadas a un área de trabajo de Log Analytics, puede seguir usando esa área
de trabajo cuando se incorpore a Azure Monitor para VM, siempre que se encuentre en una de las regiones
compatibles.
¿Puede incorporarse a una nueva área de trabajo?
Si las máquinas virtuales no están conectadas actualmente a un área de trabajo de Log Analytics existente, deberá
crear un área de trabajo para almacenar los datos. Un área de trabajo predeterminada se crea automáticamente si
configura una sola máquina virtual de Azure para Azure Monitor para máquinas virtuales a través de Azure Portal.
Si decide usar el método basado en scripts, estos pasos se describen en el artículo Habilitar Azure Monitor para VM
mediante Azure PowerShell o una plantilla de Resource Manager.
¿Qué puedo hacer si mi máquina virtual ya está generando informes para un área de trabajo?
Si ya está recopilando datos de las máquinas virtuales, es posible que ya las haya configurado para que generen
ubfirnes de datos a un área de trabajo de Log Analytics existente. Siempre y cuando el área de trabajo se encuentre
en una de nuestras regiones admitidas, podrá habilitar Azure Monitor para máquinas virtuales en esa área de
trabajo preexistente. Si el área de trabajo que ya está usando no está en una de nuestras regiones admitidas, no
podrá incorporar Azure Monitor para VM en este momento. Estamos trabajando para admitir más regiones.
¿Por qué no se pudo incorporar mi máquina virtual?
Al incorporar una máquina virtual de Azure desde Azure Portal, se producen los pasos siguientes:
Se crea un área de trabajo de Log Analytics predeterminada si se ha seleccionado la opción.
Se instala el agente de Log Analytics en las máquinas virtuales de Azure mediante la extensión de máquina
virtual si se determina que es necesario.
Se instala el agente de la dependencia de asignación de Azure Monitor para máquinas virtuales mediante una
extensión si se determina que es necesario.
Durante el proceso de incorporación, comprobamos el estado de cada uno de los pasos anteriores para devolver un
estado de notificación en el portal. La configuración del área de trabajo y la instalación del agente normalmente
tarda de 5 a 10 minutos. La visualización de los datos de supervisión en el portal tarda otros 5 o 10 minutos.
Si ha iniciado la incorporación y puede ver los mensajes que indican que la máquina virtual debe incorporarse,
espere hasta 30 minutos para que la máquina virtual pueda completar el proceso.
No veo algunos o ninguno de los datos en el gráfico de rendimiento de la VM
Los gráficos de rendimiento se han actualizado para usar los datos almacenados en la tabla InsightsMetrics. Si desea
ver los datos en estos diagramas, es necesario que los actualice para poder usar la solución VM Insights. Consulte
las preguntas frecuentes sobre disponibilidad general para más información.
Si no ve los datos de rendimiento en la tabla del disco o en algunos de los gráficos de rendimiento, es posible que
los contadores de rendimiento en el área de trabajo no estén configurados. Para solucionar este problema, ejecute
el siguiente script de PowerShell.
¿En qué se diferencian la característica de asignación de Azure Monitor para máquinas virtuales y Service Map?
La característica de asignación de Azure Monitor para máquinas virtuales está basada en Service Map, pero se
diferencia en los siguientes aspectos:
Se puede acceder a la vista de asignación desde la hoja de máquina virtual y desde Azure Monitor para
máquinas virtuales en Azure Monitor.
Ahora se puede hacer clic sobre las conexiones en la asignación y, en el panel lateral, muestran una vista de los
datos de métricas de la conexión seleccionada.
Hay una nueva API que se usa para crear las asignaciones, lo que ofrece una mejor compatibilidad con
asignaciones más complejas.
Ahora se incluyen máquinas virtuales supervisadas en el nodo de grupo del cliente y el gráfico de anillos
muestra la proporción de máquinas virtuales no supervisadas frente a las supervisadas en el grupo. También
puede usarse para filtrar la lista de máquinas cuando el grupo está expandido.
Ahora se incluyen las máquinas virtuales supervisadas en los nodos de grupo de los puertos del servidor, y el
gráfico de anillos muestra la proporción de máquinas supervisadas frente a las no supervisadas en el grupo.
También puede usarse para filtrar la lista de máquinas cuando el grupo está expandido.
El estilo de la asignación se actualizó para que sea más coherente con el mapa de aplicación de Application
Insights.
Los paneles laterales se han actualizado y aún no tienen el conjunto completo de integración que era compatible
con Service Map: Update Management, Change Tracking, seguridad y Service Desk.
La opción para elegir los grupos y máquinas que se asignarán se ha actualizado y ahora es compatible con las
suscripciones, grupos de recursos, conjuntos de escalado de máquinas virtuales de Azure y servicios en la nube.
No puede crear grupos de máquinas de Service Map en la característica de asignación de Azure Monitor para
máquinas virtuales.
¿Por qué mi gráficos de rendimiento muestran líneas punteadas?
Esto puede ocurrir por varios motivos. En los casos donde hay una discontinuidad en la recopilación de datos, las
líneas se muestran punteadas. Si ha modificado la frecuencia de muestreo de datos para los contadores de
rendimiento habilitados (el valor predeterminado es recopilar datos cada 60 segundos), podrá ver líneas punteadas
en el gráfico si elige un intervalo de tiempo reducido para el gráfico y su frecuencia de muestreo es menor que el
tamaño de depósito utilizado en el gráfico (por ejemplo, la frecuencia de muestreo es cada 10 minutos y cada
depósito en el gráfico es de 5 minutos). En este caso, elegir un intervalo de tiempo más amplio para la visualización
debe hacer que las líneas del gráfico sean sólidas en lugar de punteadas.
¿Los grupos son compatibles con Azure Monitor para máquinas virtuales?
Sí, una vez que se instala Dependency Agent recopilamos información de las máquinas virtuales para mostrar los
grupos por suscripción, grupo de recursos,conjunto de escalado de máquinas virtuales y servicios en la nube. Si ha
usado Service Map y ha creado grupos de máquinas, también se muestran. Los grupos de equipos también
aparecerán en el filtro de grupos si los ha creado para el área de trabajo que ve.
¿Cómo puedo ver los detalles de lo que está aumentando la línea del percentil 95 en los gráficos de rendimiento
agregado?
De forma predeterminada, la lista está ordenada para mostrar las máquinas virtuales con el valor de percentil 95
más alto de la métrica seleccionada, con la excepción del gráfico de memoria disponible, que muestra las máquinas
con el valor más bajo de percentil 5. Al hacer clic en el gráfico, se abrirá la vista Top N List (Lista de N más altos)
con la métrica adecuada seleccionada.
¿Cómo administra la característica de asignación las direcciones IP duplicadas entre distintas redes virtuales y
subredes?
Si va a duplicar los intervalos de IP con máquinas virtuales o conjuntos de escalado de máquinas virtuales de Azure
entre subredes y redes virtuales, puede hacer que la asignación de Azure Monitor para máquinas virtuales muestre
información incorrecta. Se trata de un problema conocido y estamos investigando opciones para mejorar esta
experiencia.
¿La característica de asignación es compatible con IPv6?
Por el momento, la característica de asignación solo es compatible con IPv4 y estamos investigando la
compatibilidad con IPv6. También es compatible con IPv4 que se tuneliza dentro de IPv6.
Cuando cargo una asignación para un grupo de recursos o algún otro grupo grande me resulta difícil verla.
Aunque hemos realizado mejoras a la asignación para que controle configuraciones grandes y complejas, somos
conscientes de que una asignación puede tener una gran cantidad de nodos, conexiones y nodos que funcionen
como un clúster. Nos comprometemos a seguir mejorando la compatibilidad para aumentar la escalabilidad.
¿Por qué el gráfico de red de la pestaña Rendimiento es distinta al gráfico de red de la página Información
general de la máquina virtual de Azure?
La página de información general de una máquina virtual de Azure muestra gráficos basados en la medición de
actividad de la máquina virtual invitada que realiza el host. En el gráfico de red de la información general de la
máquina virtual de Azure, solo se muestra el tráfico de red que se facturará. Esto no incluye el tráfico entre redes
virtuales. Los datos y gráficos que se muestran en Azure Monitor para VM se basan en los datos de la máquina
virtual invitada y el gráfico de red muestra todo el tráfico TCP/IP entrante y saliente de esa máquina virtual, incluido
el que fluye entre redes virtuales.
¿Cómo se mide el tiempo de respuesta de los datos almacenados en VMConnection y mostrados en el panel de
conexión y los libros?
El tiempo de respuesta es una aproximación. Puesto que no se instrumenta el código de la aplicación, no sabemos
realmente cuándo comienza una solicitud y cuándo llega la respuesta. En su lugar, observamos el envío de datos en
una conexión y, posteriormente, la devolución de los datos por esa conexión. Nuestro agente realiza un seguimiento
de estos envíos y recepciones e intenta emparejarlos: una secuencia de envíos seguida de una secuencia de
recepciones se interpreta como un par de solicitud y respuesta. El tiempo que transcurre entre estas operaciones es
el tiempo de respuesta. Incluye la latencia de red y el tiempo de procesamiento del servidor.
Esta aproximación funciona bien para protocolos que se basan en solicitud/respuesta: una única solicitud sale por la
conexión y se recibe una única respuesta. Este es el caso de HTTP(S) (sin canalización), pero no es así para otros
protocolos.
¿Existen limitaciones si estoy en el plan de tarifa gratis de Log Analytics?
Si ha configurado Azure Monitor con un área de trabajo de Log Analytics mediante el plan de tarifa gratis, la
característica de asignación de Azure Monitor para máquinas virtuales solo admitirá cinco máquinas conectadas. Si
tiene cinco máquinas virtuales conectadas a un área de trabajo gratuita, desconecte una para poder conectar otra
nueva. La nueva máquina virtual que conecte no se supervisará ni se reflejará en la página de asignación.
En esta condición, verá la opción Probar ahora al abrir la VM y seleccionar la opción Insights en el panel
izquierdo, incluso después de que se haya instalado en la VM. Sin embargo, no se le presentarán opciones como
ocurriría si estas VM no estuvieran incorporadas en Azure Monitor para VM.
Pasos siguientes
Si su pregunta no se ha respondido aquí, puede consultar los siguientes foros para obtener preguntas y respuestas
adicionales.
Log Analytics
Para comentarios generales sobre Azure Monitor, visite el foro de comentarios.
Novedades en la documentación de Azure Monitor
En este artículo se enumeran los artículos de Azure Monitor que son nuevos o que se han actualizado de forma
significativa. Se actualizará la primera semana de cada mes para que incluya las actualizaciones de artículos del
mes anterior.
Agosto de 2020
Contenedores
Implementación y métricas de HPA con Azure Monitor para contenedores: nuevo artículo.
Julio de 2020
General
Implementación de Azure Monitor: reestructuración del contenido de la incorporación de Azure Monitor para
VM.
Uso de Azure Private Link para conectar redes a Azure Monitor de forma segura: se agrega la sección en los
límites.
Alertas
Reglas de acción para alertas de Azure Monitor: se han agregado procesos de la CLI.
Creación y administración de grupos de acciones en Azure Portal: se ha actualizado para reflejar los cambios en
la interfaz de usuario.
Consultas guardadas en Log Analytics de Azure Monitor: artículo nuevo.
Solución de problemas de alertas de registro en Azure Monitor: se ha agregado la sección de la cuota de reglas
de alerta.
Solución de problemas en las alertas de métricas de Azure Monitor: se ha agregado la sección sobre la regla de
alerta de una métrica personalizada que todavía no se ha emitido.
Descripción del funcionamiento de las alertas de métricas en Azure Monitor. : se ha agregado una
recomendación para seleccionar la granularidad de la agregación.
Notas de la versión para la extensión de Azure Web Apps - Application Insights: nuevo artículo.
Ejemplos de plantilla de Resource Manager para la creación de recursos de Application Insights: nuevo artículo.
Solución de problemas con Azure Application Insights Profiler: se ha agregado una nota sobre el error al
ejecutar Profiler para aplicaciones de ASP.NET Core en Azure App Service.
Contenedores
Alertas de registro de Azure Monitor para contenedores: nuevo artículo.
Alertas de métricas de Azure Monitor para contenedores: nuevo artículo.
Registros
Clave administrada por el cliente de Azure Monitor: se agrega el mensaje de error y la sección Configuración de
CMK para las consultas.
HTTP Data Collector API de Azure Monitor: se ha agregado el ejemplo de Python 3.
Optimización de las consultas de registro en Azure Monitor: se ha agregado la sección para evitar varios análisis
de datos al usar subconsultas.
Tutorial: Introducción a las consultas de Log Analytics: se ha agregado un vídeo.
Creación de una configuración de diagnóstico para enviar los registros y las métricas de la plataforma a
diferentes destinos: se ha agregado un vídeo.
Ejemplos de plantillas de Resource Manager para Azure Monitor: se ha agregado un ejemplo de ARM con el tipo
de destino Logs.
Soluciones
Soluciones de supervisión en Azure Monitor: se han agregado procesos de la CLI.
Solución de administración de Office 365 en Azure: se ha cambiado la fecha de retirada.
Máquinas virtuales
Artículos nuevos y actualizados desde la reestructuración del contenido de Azure Monitor para VM
¿Qué es Azure Monitor para VM?
Configuración del área de trabajo de Log Analytics para Azure Monitor para VM
Conexión de equipos Linux a Azure Monitor
Habilitar Azure Monitor para un entorno híbrido
Habilitar Azure Monitor para VM para una sola máquina virtual o un conjunto de escalado de máquinas
virtuales mediante Azure Portal
Habilitación de Azure Monitor para VM mediante Azure Policy
Información general sobre la habilitación de Azure Monitor para VM
Habilitar Azure Monitor para VM mediante PowerShell
Habilitación de Azure Monitor para VM mediante plantillas de Resource Manager
Habilitar Azure Monitor para VM mediante PowerShell o plantillas
Visualizaciones
Actualización de las visualizaciones del panel de Log Analytics: se ha actualizado la frecuencia de actualización.
Visualización de datos de Azure Monitor: se ha agregado un vídeo.
Junio de 2020
General
Implementación de Azure Monitor. Nuevo artículo.
Clave administrada por el cliente de Azure Monitor. Propiedad billingtype actualizada. Comandos PowerShell
incorporados.
Agentes
Introducción al agente de Log Analytics. Requisito de Python 2 incorporado.
Alertas
Actualización de reglas de alertas o reglas de acción cuando su recurso de destino se mueve a otra región de
Azure. Nuevo artículo.
Solución de problemas en las alertas de métricas de Azure Monitor. Nuevo artículo.
Solución de problemas de alertas de registro en Azure Monitor. Nuevo artículo.
Azure Application Insights para aplicaciones web de JavaScript. Actualización de la sección del SDK de
JavaScript. Fragmento de código actualizado para informar sobre errores de carga.
Configuración de BYOS (Traiga su propio almacenamiento) para Profiler y Snapshot Debugger. Nuevo artículo.
Seguimiento de las solicitudes entrantes en Azure Application Insights con OpenCensus para Python. Registro y
configuración actualizadas para OpenCensus.
Supervisión de una aplicación web de ASP.NET en vivo con Azure Application Insights: se ha actualizado la fecha
de entrada en desuso de Status Monitor v1.
Supervisión de servicios de node. js con Azure Application Insights. Varias actualizaciones, incluida la migración
desde versiones anteriores y la configuración del SDK
Supervisión de aplicaciones de Python con Azure Monitor (versión preliminar). Incorporación de una sección
sobre la configuración de los exportadores de Azure Monitor.
Supervisión de las aplicaciones sin cambios de código: instrumentación automática para Azure Monitor
Application Insights. Nuevo artículo.
Solución de problemas de errores de carga del SDK para aplicaciones web de JavaScript. Nuevo artículo.
Contenedores
Cómo detener la supervisión del clúster híbrido de Kubernetes. Sección agregada para Kubernetes habilitado
para Arc.
Configuración de un clúster de Kubernetes habilitado para Azure Arc con Azure Monitor para contenedores.
Nuevo artículo.
Configuración de la versión 4.x de Red Hat OpenShift en Azure con Azure Monitor para contenedores.Requisitos
previos actualizados.
Configuración de datos en directo (versión preliminar) de Azure Monitor para contenedores. Eliminación de
nota sobre la característica que no está disponible en Azure US Government.
Preguntas más frecuentes: Solución Network Performance Monitor en Azure. Incorporación de preguntas más
frecuentes sobre Supervisión de ExpressRoute.
Registros
Eliminación y recuperación de un área de trabajo de Azure Log Analytics. Incorporación de un comando de
PowerShell. Actualización de Solución de problemas.
Administración de áreas de trabajo de Log Analytics en Azure Monitor. Incorporación de ejemplo para tablas no
permitidas en la sección RBAC.
Administración del uso y los costos con los registros de Azure Monitor. Detalles adicionales sobre el cálculo del
tamaño de los datos. Se actualizó la configuración de alertas de volumen de datos. Detalles sobre los datos de
seguridad recopilados por Azure Sentinel. Aclaración sobre el límite de datos.
Uso de Azure Monitor Logs con Azure Logic Apps y Power Automate: se han agregado límites del conector.
Métricas
Métricas compatibles de Azure Monitor por tipo de recurso. Actualización de métricas de SQL Server.
Ejemplos de plantillas de Resource Manager para la configuración de diagnóstico. Corrección de la
configuración de diagnóstico del registro de actividad.
Envío del registro de actividad de Azure al área de trabajo de Log Analytics mediante Azure Portal. Nuevo
artículo.
Envío del registro de actividad de Azure al área de trabajo de Log Analytics mediante una plantilla de Azure
Resource Manager. Nuevo artículo.
Artículos nuevos y actualizados sobre reestructuración y consolidación del contenido de registros de plataforma
Archivado de registros de recursos de Azure en la cuenta de almacenamiento
Esquema de eventos del registro de actividad de Azure
Registro de actividad de Azure
Ejemplos de la CLI de Azure Monitor
Ejemplos de PowerShell de Azure Monitor
Tutorial sobre la API de REST de supervisión de Azure
Servicios y esquemas admitidos de los registros de recursos de Azure
Registros de recursos de Azure
Recopilación y análisis del registro de actividad de Azure en Azure Monitor
Recopilación de registros de recursos de Azure en el área de trabajo de Log Analytics
Creación de una configuración de diagnóstico para enviar registros de plataforma y métricas a diferentes
destinos
Exportación del registro de actividad de Azure
Introducción a los registros de plataforma Azure
Transmisión de registros de plataforma de Azure a un centro de eventos
Visualización de eventos del registro de actividad de Azure en Azure Monitor
Máquinas virtuales
Habilitación de Azure Monitor para VM en Azure Portal. Actualización para incluir Azure Arc.
Información general sobre la habilitación de Azure Monitor para VM. Actualización para incluir Azure Arc.
¿Qué es Azure Monitor para VM? Actualización para incluir Azure Arc.
Visualizaciones
Orígenes de datos de libros de Azure Monitor. Incorporación de las secciones de Alertas y Punto de conexión
personalizado.
Solución de problemas de conclusiones basadas en libros de Azure Monitor. Nuevo artículo.
Actualización de las visualizaciones del panel de Log Analytics. Nuevo artículo.
Mayo de 2020
General
Preguntas más frecuentes de Azure Monitor: se ha agregado una sección de métricas.
Clave administrada por el cliente de Azure Monitor: varios cambios en la preparación para la disponibilidad
general.
Definiciones de directivas integradas para Azure Monitor: nuevo artículo.
Cuentas de almacenamiento de propiedad del cliente para la ingesta de registros: nuevo artículo.
Administrar el uso y los costos con los registros de Azure Monitor: se ha agregado la facturación proporcional
de los clústeres.
Uso de Azure Private Link para conectar redes a Azure Monitor de forma segura: nuevo artículo.
Nuevos ejemplos de plantillas de Resource Manager
Ejemplos de plantillas de Resource Manager para Azure Monitor
Ejemplos de plantillas de Resource Manager para grupos de acciones
Ejemplos de plantillas de Resource Manager para agentes
Ejemplos de plantillas de Resource Manager para Azure Monitor para contenedores
Ejemplos de plantillas de Resource Manager para Azure Monitor para VM
Ejemplos de plantillas de Resource Manager para la configuración de diagnóstico
Ejemplos de plantillas de Resource Manager para áreas de trabajo de Log Analytics
Ejemplos de plantillas de Resource Manager para consultas de registros
Ejemplos de plantillas de Resource Manager para reglas de alertas de consultas de registros
Ejemplos de plantillas de Resource Manager para reglas de alertas de métricas
Ejemplos de plantillas de Resource Manager para libros
Agentes
Instalación y configuración de la extensión de Diagnósticos de Azure para Windows (WAD): detalle agregado
sobre la configuración de diagnóstico.
Información general del agente de Log Analytics: se han agregado versiones de Linux compatibles.
Supervisión de aplicaciones que se ejecutan en Azure Functions con Application Insights: Azure Monitor: nuevo
artículo.
Supervisión de los servicios de Node.js con Azure Application Insights: actualizaciones generales, incluida la
nueva sección sobre la migración desde versiones anteriores.
Direcciones IP usadas por Application Insights y Log Analytics: se han agregado direcciones IP para webhooks y
US Government.
Supervisión de aplicaciones en Azure Kubernetes Service (AKS) con Application Insights: Azure Monitor: nuevo
artículo.
Solución de problemas cuando no hay datos: Application Insights para .NET: se ha agregado una sección sobre
la recopilación de registros con dotnet-trace.
Uso de Application Change Analysis en Azure Monitor para detectar problemas de la aplicación web: varias
actualizaciones en la característica Change Analysis.
Artículos nuevos y actualizados para la versión preliminar de aplicaciones basadas en el área de trabajo
Esquema de recursos basado en el área de trabajo de Application Insights de Azure Monitor
Creación de nuevos recursos basados en área de trabajo de Application Insights de Azure Monitor
Expresión app() en consultas de registro de Azure Monitor
Ámbito de la consulta de registro en Log Analytics de Azure Monitor
Consulta entre recursos con Azure Monitor
Propiedades estándar de los registros de Azure Monitor
Estructura de registros de Azure Monitor
Contenedores
Cómo habilitar Azure Monitor para contenedores: se ha actualizado la tabla de configuración del firewall.
Cómo actualizar Azure Monitor para contenedores para habilitar métricas: actualización para usar identidades
administradas para recopilar métricas.
Costos de supervisión por Azure Monitor para contenedores: nuevo artículo.
Configuración de Azure Monitor para datos en directo de contenedores (versión preliminar): soporte técnico
para el nuevo enlace de rol de clúster.
Azure Monitor para Azure Cache for Redis (versión preliminar): nuevo artículo.
Supervisión de Key Vault con Azure Monitor para Key Vault (versión preliminar): nuevo artículo.
Registros
Creación y configuración de Log Analytics con PowerShell: se ha agregado una sección de solución de
problemas.
Creación de un área de trabajo de Log Analytics en Azure Portal: se ha agregado una sección de solución de
problemas.
Creación de un área de trabajo de Log Analytics mediante la CLI de Azure: se ha agregado una sección de
solución de problemas.
Eliminación y recuperación de un área de trabajo de Azure Log Analytics: se ha actualizado la información sobre
la recuperación de un área de trabajo eliminada.
Funciones de las consultas de registros de Azure Monitor: se ha quitado la nota sobre las funciones que no
contienen otras funciones.
Estructura de registros de Azure Monitor: se han aclarado las descripciones de propiedades de la tabla de
Application Insights.
Uso de Azure Monitor Logs con Azure Logic Apps y Power Automate: se ha agregado una sección de límites.
Uso de PowerShell para crear y configurar un área de trabajo de Log Analytics: se ha agregado una sección de
Métricas
Métricas compatibles de Azure Monitor por tipo de recurso: se han aclarado las métricas de invitado y el
enrutamiento de métricas.
Soluciones
Optimización del entorno de Active Directory con Azure Monitor: se ha agregado Windows Server 2019 a las
versiones compatibles.
Optimización del entorno de SQL Server con Azure Monitor: se ha agregado a las versiones compatibles de SQL
Server.
Máquinas virtuales
Información general sobre la habilitación de Azure Monitor para VM: se ha agregado a las versiones
compatibles de Ubuntu Server. Se han agregado regiones admitidas para el área de trabajo de Log Analytics.
Cómo representar el rendimiento en gráficos con Azure Monitor para VM: se ha agregado una sección de
limitaciones para las métricas no disponibles.
Visualizaciones
Libros de Azure Monitor y plantillas de Azure Resource Manager: se ha agregado una actualización de Resource
Manager para implementar una plantilla de libro.
Grupos en los libros de Azure Monitor: nuevo artículo.
Libros de Azure Monitor: transformación de datos JSON con JSONPath: nuevo artículo.
Abril de 2020
General
Configuración de la clave administrada por el cliente de Azure Monitor: se ha agregado una sección sobre
operaciones asincrónicas.
Administración del acceso a los datos de registro y las áreas de trabajo en Azure Monitor: se ha actualizado la
sección de registros personalizados.
Alertas
Reglas de acción (versión preliminar): se ha agregado un vídeo.
Información general sobre las alertas en Microsoft Azure: se ha agregado un vídeo.
Mapa de aplicación: Evaluación de prioridades de las aplicaciones distribuidas: se ha agregado la configuración
de nombres de roles de nube para el agente de Java.
Referencia de la API del agente de .NET de Azure Application Insights: se ha consolidado la referencia de la API.
Direcciones IP que emplean Application Insights y Log Analytics: se han actualizado las direcciones IP para App
Insights y las API de Log Analytics, webhooks de grupo de acciones, Azure US Government.
Supervisión de aplicaciones de Java en cualquier sitio: nuevo artículo.
Supervisión de aplicaciones de Java en cualquier entorno: nuevo artículo.
Supervisión de aplicaciones de Java que se ejecutan en cualquier entorno: nuevo artículo.
Supervisión de aplicaciones de Java que se ejecutan en el entorno local: nuevo artículo.
Procedimiento para quitar Application Insights en Visual Studio: nuevo artículo.
Muestreo en Application Insights: se ha corregido el ejemplo de frecuencia fija en Python.
Contenedores
Configuración de la versión 4.x de Red Hat OpenShift en Azure con Azure Monitor para contenedores: nuevo
artículo.
Cómo corregir manualmente los problemas de sincronización de ServiceNow: nuevo artículo.
Cómo detener la supervisión del clúster de Azure y Red Hat OpenShift v4: nuevo artículo.
Cómo detener la supervisión del clúster de Red Hat OpenShift en Azure v3: nuevo artículo.
Cómo detener la supervisión del clúster de Kubernetes híbrido: nuevo artículo.
Supervisión de Azure Key Vault con Azure Monitor para Key Vault (versión preliminar): nuevo artículo.
Registros
Límites de servicio de Azure Monitor: se ha agregado la limitación de consultas de usuario.
Administrar el uso y los costos con los registros de Azure Monitor: se ha agregado la facturación de los clústeres
de registros. Se ha agregado una consulta de Kusto para que los clientes con el plan de tarifa por nodo
heredado puedan determinar si deben cambiar a un nivel de reserva de capacidad o por GB.
Métricas
Características avanzadas del Explorador de métricas de Azure: se ha agregado la sección de agregación.
Workbooks
Libros de Azure Monitor y plantillas de Azure Resource Manager: se ha agregado una plantilla de Resource
Manager para implementar una plantilla de libro.
Marzo de 2020
General
Introducción a Azure Monitor: se ha agregado un vídeo de introducción a Azure Monitor.
Configuración de la clave administrada por el cliente de Azure Monitor: actualizaciones generales.
Referencia de datos de Azure Monitor: nuevo sitio.
Alertas
Crear, ver y administrar las alertas del registro de actividad mediante Azure Monitor: explicación adicional de la
plantilla de Resource Manager.
Descripción del funcionamiento de las alertas de métricas en Azure Monitor. : se ha actualizado para la
compatibilidad con la Administración Pública.
Solución de problemas de alertas y notificaciones de Azure Monitor: nuevo artículo.
Automatización de Azure Application Insights con PowerShell: se han agregado ejemplos de ARMClient.
Exportación continua de telemetría desde Application Insights:se ha agregado una tabla con detalles de la
estructura de exportación.
Habilitación de Snapshot Debugger para aplicaciones de .NET en Azure App Service: se ha agregado una
plantilla de Resource Manager de ejemplo.
Administración del uso y los costos de Application Insights: se ha agregado información sobre la alerta de límite
de datos.
Supervisión de aplicaciones de Python con Azure Monitor (versión preliminar): se han agregado métricas
estándar.
Compatibilidad del mapa de origen con las aplicaciones de JavaScript: Application Insights para Azure Monitor:
nuevo artículo.
Contenedores
Preguntas más frecuentes sobre Azure Monitor: actualización de Azure Monitor para contenedores.
Configuración de la supervisión de GPU con Azure Monitor para contenedores: nuevo artículo.
Solución de administración de Office 365 en Azure: fecha de desuso actualizada.
Registros
Optimización de las consultas de registro en Azure Monitor: se ha agregado la condición de CPU para el análisis
de XML y JSON.
Eliminación y recuperación de un área de trabajo de Azure Log Analytics: se ha agregado información de
Uso de registros de Azure Monitor con Azure Logic Apps y Power Automate: se ha actualizado con un nuevo
conector de Azure Monitor.
Métricas
Desuso de métricas de disco en Azure Portal: nuevo artículo.
Tutorial: Creación de un gráfico de métricas en Azure Monitor: se ha agregado un vídeo.
Recopilación y análisis del registro de actividad de Azure en Azure Monitor: se ha redactado de nuevo para
explicar mejor la recopilación del registro de actividad con configuración de diagnóstico.
Máquinas virtuales
Supervisión de máquinas virtuales de Azure con Azure Monitor: nuevo artículo.
Inicio rápido: Supervisión de máquinas virtuales de Azure con Azure Monitor: se ha actualizado para agregar
Azure Monitor para máquinas virtuales.
Alertas de Azure Monitor para VM: nuevo artículo.
Información general sobre la habilitación de Azure Monitor para VM: actualización de los vínculos de descarga
de agentes.
Actualizaciones generales para disponibilidad general de Azure Monitor para VM
¿Qué es Azure Monitor para VM?
Preguntas frecuentes sobre Azure Monitor para VM (GA)
Habilitación de Azure Monitor para VM mediante Azure Policy
Cómo representar el rendimiento en gráficos con Azure Monitor para VM
Cómo consultar registros de Azure Monitor para VM
Visualización de las dependencias de aplicación con Azure Monitor para VM
Visualizaciones
Visualización de datos de Azure Monitor: se ha actualizado para indicar el desuso planeado del Diseñador de
vistas.
Febrero de 2020
Agentes
Actualizaciones múltiples como parte de la reescritura del contenido de la extensión de diagnóstico.
Introducción a los agentes de supervisión de Azure: reestructuración de las tablas para aclarar mejor las
características únicas de cada agente.
Introducción a las extensiones de Azure Diagnostics: se ha reescrito en su totalidad.
Uso de Blob Storage para IIS y Table Storage para eventos en Azure Monitor: reescritura general con fines de
actualización y claridad.
Instalación y configuración de Windows Azure Diagnostics Extension (WAD): artículo nuevo.
Esquema de Windows Diagnostics Extension: se ha reorganizado.
Envío de datos desde la extensión de Diagnósticos de Windows Azure a Azure Event Hubs: se ha reescrito y
actualizado por completo.
Almacenamiento y visualización de datos de diagnóstico en Azure Storage: se ha reescrito y actualizado por
completo.
Extensión de máquina virtual de Log Analytics para Windows: aclara la relación con el agente de Log Analytics.
Extensión de máquina virtual de Azure Monitor para Linux: aclara la relación con el agente de Log Analytics.
Cadenas de conexión en Azure Application Insights: artículo nuevo.
Conclusiones y soluciones
Integración de Azure Active Directory con Azure Kubernetes Service: se ha agregado una nota para crear una
aplicación cliente que admita clústeres habilitados para RBAC con el fin de admitir Azure Monitor para
contenedores.
Preguntas frecuentes sobre Azure Monitor para VM (disponibilidad general): cambia el modo en que se
almacenan los datos de rendimiento.
Office 365
Solución de administración de Office 365 en Azure: fecha de desuso actualizada.
Registros
Optimización de las consultas de registro en Azure Monitor: artículo nuevo.
Administración del uso y los costos de los registros de Azure Monitor: mejora de las consultas de ejemplo para
ayudarle a comprender el uso.
Métricas
Métricas de plataforma de Azure Monitor exportables a través de la configuración del diagnóstico: se ha
agregado una sección sobre el cambio en el comportamiento de los valores NULL y cero.
Visualizaciones
Varios artículos nuevos para la guía de conversión del diseñador de vistas a libros.
Guía de transición del diseñador de vistas a los libros de Azure Monitor: artículo nuevo.
Opciones de conversión del diseñador de vistas a los libros de Azure Monitor: artículo nuevo.
Conversión de elementos del diseñador de vistas a los libros de Azure Monitor: artículo nuevo.
Resumen y acceso a la conversión del diseñador de vistas a libros de Azure Monitor: artículo nuevo.
Tareas comunes de la conversión del diseñador de vistas a libros de Azure Monitor: artículo nuevo.
Ejemplos de conversión del diseñador de vistas a libros de Azure Monitor: artículo nuevo.
Enero de 2020
General
¿Qué supervisa Azure Monitor? - Nuevo artículo.
Agentes
Recopilación de datos de registro con el agente de Azure Log Analytics: se ha actualizado la tabla de requisitos
del firewall de red.
Alertas
Creación y administración de grupos de acciones en Azure Portal: se ha eliminado la configuración de las
funciones v2 que ya no es necesaria.
Creación de una alerta de métrica con una plantilla de Resource Manager: se ha agregado un ejemplo para el
parámetro ignoreDataBefore. Se han agregado restricciones sobre las reglas de varios criterios.
Uso de la API REST de alertas de Log Analytics: se ha corregido el ejemplo de JSON.
Direcciones IP que emplean Application Insights y Log Analytics: se ha actualizado la sección de prueba de
disponibilidad con la incorporación de una regla de puerto de entrada que permite el tráfico mediante grupos
de seguridad de red de Azure.
Solución de problemas relacionados con Azure Application Insights Profiler: se ha actualizado la solución de
problemas general.
Muestreo de telemetría en Azure Application Insights: se ha actualizado y reestructurado para mejorar la
legibilidad en función de los comentarios de los clientes.
Seguridad de los datos
Configuración de la clave administrada por el cliente de Azure Monitor: nuevo artículo.
Configuración de la recopilación de datos del agente de Azure Monitor para contenedores: se han agregado
detalles para la actualización del agente en Red Hat OpenShift en Azure e información adicional para distinguir
los métodos de actualización del agente.
Creación de alertas de rendimiento para Azure Monitor para contenedores: se ha revisado la información y se
han actualizado los pasos para crear una alerta en los datos de rendimiento almacenados en el área de trabajo
mediante alertas de contexto del área de trabajo.
Supervisión de Kubernetes con Azure Monitor para contenedores: se ha actualizado el artículo introductorio y el
de análisis relacionado con la compatibilidad de los clústeres de Windows Kubernetes.
Configuración de clústeres de Red Hat OpenShift en Azure con Azure Monitor para contenedores: se han
agregado detalles para la actualización del agente en Red Hat OpenShift en Azure e información adicional para
distinguir los métodos de actualización del agente.
Configuración de los clústeres híbridos de Kubernetes con Azure Monitor para contenedores: se ha actualizado
para reflejar la compatibilidad agregada para el puerto seguro 10250 con Kubelet's cAdvisor.
Administración de Azure Monitor para el agente de contenedores: se han actualizado los detalles relacionados
con el comportamiento y la configuración de la recopilación de métricas de Red Hat OpenShift en Azure en
comparación con otros tipos de clústeres de Kubernetes.
Configurar la integración de Prometheus con Azure Monitor para contenedores: se han actualizado los detalles
relacionados con el comportamiento y la configuración de la recopilación de métricas de Red Hat OpenShift en
Azure en comparación con otros tipos de clústeres de Kubernetes.
Actualización de Azure Monitor para contenedores para habilitar métricas: se han actualizado los detalles
relacionados con el comportamiento y la configuración de la recopilación de métricas de Red Hat OpenShift en
Azure en comparación con otros tipos de clústeres de Kubernetes.
Preguntas frecuentes sobre Azure Monitor para VM (disponible de forma general): se ha agregado información
sobre la actualización del área de trabajo y los agentes a la nueva versión.
Office 365
Solución de administración de Office 365 en Azure: se han agregado detalles y preguntas frecuentes sobre la
migración a una solución de Office 365 en Azure Sentinel. Se ha eliminado la sección de incorporación.
Registros
Administración de áreas de trabajo de Log Analytics en Azure Monitor: se ha actualizado la sección de "No
acciones".
Administración del uso y los costos de los registros de Azure Monitor: se ha agregado claridad al cálculo del
volumen de datos en la sección Modelo de precios.
Uso de las plantillas de Azure Resource Manager para crear y configurar un área de trabajo de Log Analytics: se
ha actualizado la plantilla con nuevos planes de tarifa.
Recopilación del registro de actividad de Azure con configuración de diagnóstico: Azure Monitor: se ha agregado
información adicional sobre las propiedades modificadas.
Exportación del registro de actividad de Azure: se ha actualizado con los cambios de la interfaz de usuario.
Diciembre de 2019
Agentes
Conexión de equipos Linux a Azure Monitor: nuevo artículo.
Alertas
Creación de una alerta de métrica con una plantilla de Resource Manager: se ha agregado un ejemplo para
métricas personalizadas.
Creación de alertas con umbrales dinámicos en Azure Monitor: se ha agregado una sección sobre la
interpretación de gráficos de umbrales dinámicos.
Información general de alertas y supervisión de notificaciones en Azure: se ha actualizado la consulta de
Resource Graph.
Recursos compatibles para las alertas de métricas de Azure Monitor: actualización sobre las métricas y
dimensiones admitidas.
Cambio de la API heredada de alertas de Log Analytics a la nueva API de Alertas de Azure: se ha agregado una
nota sobre el nombre de alerta modificado.
Descripción del funcionamiento de las alertas de métricas en Azure Monitor. se han agregado los tipos de
recursos admitidos para la supervisión a escala.
Application Insights para las aplicaciones de servicio de trabajo (aplicaciones sin HTTP): se ha agregado un nivel
de registro predeterminado al código de C#. Se ha actualizado la versión de referencia del paquete.
Referencia de ApplicationInsights.config: Azure: se ha actualizado el código de ejemplo.
Automatización de Azure Application Insights con PowerShell: se ha actualizado la plantilla de Resource
Manager.
Paquetes NuGet de Application Insights de Azure Monitor: se han agregado otras versiones de paquetes.
Creación de un recurso de Azure Application Insights: se ha agregado una nota al nombre único global.
Diagnóstico con Live Metrics Stream: Azure Application Insights: se ha actualizado el requisito de versión del
SDK de ASP.NET Core.
Contadores de eventos en Application Insights: se ha actualizado la categoría y la tabla de customMetrics.
Exploración de registros de seguimiento de Java en Azure Application Insights: se ha agregado la configuración
del umbral de registro del agente de Java.
Direcciones IP que emplean Application Insights y Log Analytics: se han actualizado las direcciones IP para Live
Metrics Stream.
Supervisar el rendimiento de Azure App Services: se ha agregado compatibilidad con ASP.NET Core 3.0.
Supervisión de aplicaciones de Python con Azure Monitor (versión preliminar): se ha agregado una aclaración
para la asignación de esquemas de Python para OpenCensus en Azure. Esquema de Monitor
Notas de la versión de Azure Application Insights: se han agregado notas para las versiones más antiguas.
Canales de telemetría en Azure Application Insights: se ha actualizado la duración de los datos descartados
durante el período ampliado de la conexión perdida.
Muestreo de telemetría en Azure Application Insights: se ha corregido un fragmento de código del elemento
TelemetryInitializer.
Solución de problemas de Application Insights en un proyecto web de Java: se ha eliminado una instrucción
acerca de la no admisión de la recopilación de dependencias en JDK 9.
Preguntas más frecuentes sobre Azure Monitor para contenedores: se ha agregado una pregunta sobre los
campos Image y Name.
Solución Azure SQL Analytics en Azure Monitor: se han actualizado los tiempos de espera de la base de datos
para la compatibilidad con Instancia administrada.
Configuración de la recopilación de datos del agente de Azure Monitor para contenedores: se ha agregado la
configuración de enrich_container_logs.
Configuración de los clústeres híbridos de Kubernetes con Azure Monitor para contenedores: se ha agregado la
sección de solución de problemas.
Supervisión de Active Directory Replication Status con Azure Monitor: se ha actualizado el requisito previo de
.NET Framework.
Solución Network Performance Monitor en Azure: se han agregado regiones compatibles.
Optimización del entorno de Active Directory con Azure Monitor: se ha actualizado el requisito previo de .NET
Framework.
Optimización del entorno de SQL Server con Azure Monitor: se ha actualizado el requisito previo de .NET
Framework.
Optimización del entorno de System Center Operations Manager con Azure Log Analytics: se ha actualizado el
requisito previo de .NET Framework.
Conexiones compatibles con IT Service Management Connector en Azure Log Analytics: se ha agregado "New
York" al requisito previo de id. de cliente y secreto de cliente.
Registros
Eliminación y recuperación de un área de trabajo de Azure Log Analytics: se ha agregado un método con
PowerShell.
Diseño de la implementación de registros de Azure Monitor: se ha aumentado la velocidad de ingesta de un
área de trabajo.
Métricas
Métricas de plataforma de Azure Monitor que pueden exportarse con la configuración de diagnóstico: nuevo
artículo.
Se han actualizado varios artículos como parte de la reestructuración de contenido de los registros de la
plataforma en función de la nueva característica para configurar el registro de actividad mediante la configuración
de diagnóstico.
Archivado de registros de recursos de Azure en la cuenta de almacenamiento
Esquema de eventos del registro de actividad de Azure
Límites de servicio de Azure Monitor
Recopilación y análisis de los registros de actividad de Azure en un área de trabajo de Log Analytics
Recopilación del registro de actividad de Azure con configuración de diagnóstico (versión preliminar): Azure
Monitor
Recopilación de registros de actividad de Azure en un área de trabajo de Log Analytics entre inquilinos de Azure
Recopilación de registros de recursos de Azure en el área de trabajo de Log Analytics
Creación de la configuración de diagnóstico en Azure con una plantilla de Resource Manager
Creación de una configuración de diagnóstico para recopilar registros y métricas en Azure
Exportación del registro de actividad de Azure
Transmisión de datos de supervisión de Azure a un centro de eventos
Transmisión de registros de plataforma de Azure a un centro de eventos
Guías de inicio rápido y tutoriales
Creación de un gráfico de métricas en Azure Monitor: nuevo artículo.
Recopilación de registros de recurso de un recurso de Azure y análisis con Azure Monitor: nuevo artículo.
Supervisión de recursos de Azure con Azure Monitor: nuevo artículo.
Pasos siguientes
Para colaborar en la documentación de Azure Monitor, consulte la Guía para colaboradores de Microsoft Docs.
Inicio rápido: Supervisión de recursos de Azure con
Azure Monitor
Azure Monitor comienza a recopilar datos de los recursos de Azure en el momento en que se crean. Este inicio
rápido proporciona un breve tutorial de los datos que se recopilan automáticamente para un recurso y de cómo
verlos en la instancia de Azure Portal de un recurso determinado. Posteriormente puede agregar la configuración
necesaria para recopilar datos adicionales y puede ir al menú de Azure Monitor para usar las mismas
herramientas para acceder a los datos recopilados de todos los recursos de la suscripción.
Para obtener descripciones más detalladas de los datos de supervisión recopilados de los recursos de Azure,
consulte Supervisión de recursos de Azure con Azure Monitor.
Inicio de sesión en Azure Portal

Inicie sesión en Azure Portal en https://portal.azure.com.
Página de información general

Muchos servicios incluirán datos de supervisión en su página Información general para una vista rápida de su
funcionamiento. Esto se basará, normalmente, en un subconjunto de métricas de plataforma almacenadas en
Métricas de Azure Monitor.
1. Busque un recurso de Azure en su suscripción.
2. Vaya a la página Información general y observe si se muestran datos de rendimiento. Estos datos los
datos proporcionará Azure Monitor. El ejemplo siguiente es la página Información general de una cuenta
de Azure Storage y puede ver que se muestran varias métricas.
3. Puede hacer clic en cualquiera de los gráficos para abrir los datos en el explorador de métricas, que se
describe a continuación.
Visualización del registro de actividad

El registro de actividad proporciona información sobre las operaciones de los recursos de Azure de la suscripción.
Aquí se incluirá información como cuándo se crea o modifica un recurso, cuándo se inicia un trabajo o cuándo se
produce una operación determinada.
1. En la parte superior del menú del recurso, seleccione Registro de actividad .
2. El filtro actual se establece en los eventos relacionados con el recurso. Si no ve ningún evento, pruebe a
cambiar el valor de Inter valo de tiempo para aumentar el ámbito de tiempo.
3. Si desea ver los eventos de otros recursos de la suscripción, cambie los criterios del filtro o incluso quite las
propiedades del filtro.
Visualización de métricas
Las métricas son valores numéricos que describen algún aspecto de un recurso en un momento concreto. Azure
Monitor recopila automáticamente métricas de la plataforma a intervalos de un minuto desde todos los recursos
de Azure. Estas métricas también se pueden ver mediante el explorador de métricas.
1. En la sección Super visión del menú de su recurso, seleccione Métricas . Se abrirá el explorador de
métricas con el ámbito establecido en el recurso.
2. Haga clic en Agregar métrica para agregar una métrica al gráfico.
3. Seleccione una métrica en la lista desplegable y, después, una agregación . Así se define cómo se
muestrearán los valores recopilados en cada intervalo de tiempo.
4. Haga clic en Agregar métrica para agregar más combinaciones de métricas y agregaciones al gráfico.
Pasos siguientes
En este inicio rápido, ha visto el registro de actividad y las métricas de un recurso de Azure que Azure Monitor
recopilan automáticamente. Continúe con el siguiente inicio rápido, en el que se muestra cómo recopilar el
registro de actividad en un área de trabajo de Log Analytics, donde se puede analizar con consultas de registro.
Envío del registro de actividad de Azure a un área de trabajo de Log Analytics
Envío del registro de actividad de Azure al área de
trabajo de Log Analytics mediante Azure Portal
El registro de actividad es un registro de la plataforma de Azure que proporciona información de los eventos en el
nivel de suscripción. Este registro incluye información como, por ejemplo, cuándo se modificó un recurso o cuándo
se inició una máquina virtual. Puede ver el registro de actividad en Azure Portal o recuperar entradas con
PowerShell y la CLI. En este inicio rápido se muestra cómo usar Azure Portal para crear un área de trabajo de Log
Analytics y una configuración de diagnóstico para enviar el registro de actividad a los registros de Azure Monitor
donde podrá analizarlo mediante consultas de registro y habilitar otras características como alertas de registro y
libros.

Creación de un área de trabajo de Log Analytics

En Azure Portal, busque y seleccione Áreas de trabajo de Log Analytics .
Haga clic en Agregar y proporcione los valores de Grupo de recursos , Nombre del área de trabajo y
Ubicación . El nombre del área de trabajo debe ser único en todas las suscripciones de Azure.
Haga clic en Revisar y crear para revisar la configuración y, a continuación, en Crear para crear el área de
trabajo. Se seleccionará el plan de tarifa predeterminado Pago por uso , que no incurrirá en ningún cargo hasta
que comience a recopilar una cantidad de datos suficiente. No se aplica ningún cargo por la recopilación del
registro de actividad.
Creación de la configuración de diagnóstico

En Azure Portal, busque y seleccione Monitor .
Seleccione Registro de actividad . Verá los eventos recientes de la suscripción actual. Haga clic en
Configuración de diagnóstico para ver la configuración de diagnóstico de la suscripción.
Haga clic en Agregar configuración de diagnóstico para crear una nueva configuración.
Escriba un nombre, por ejemplo, Enviar el registro de actividad al área de trabajo. Seleccione cada una de las
categorías. Seleccione Enviar a Log Analytics como único destino y, a continuación, especifique el área de
trabajo que ha creado. Haga clic en Guardar para crear la configuración de diagnóstico y cierre la página.
Generación de datos del registro
Solo se enviarán las nuevas entradas del registro de actividad al área de trabajo de Log Analytics, por lo que
deberá realizar algunas acciones en la suscripción para que se registren, como iniciar o detener una máquina
virtual, o crear o modificar otro recurso. Es posible que tenga que esperar unos minutos para que se cree la
configuración de diagnóstico y los datos se escriban inicialmente en el área de trabajo. Después de este retraso,
todos los eventos escritos en el registro de actividad se enviarán al área de trabajo en cuestión de segundos.
Recuperación de datos con una consulta de registro

Seleccione Registros en el menú Azure Monitor . Cierre la página Consultas de ejemplo . Si el ámbito no está
establecido en el área de trabajo que ha creado, haga clic en Seleccionar ámbito y búsquelo.
En la ventana de consulta, escriba AzureActivity y haga clic en Ejecutar . Se trata de una consulta simple que
devuelve todos los registros de la tabla AzureActivity, que contiene todos los registros enviados desde el registro
de actividad.
Expanda uno de los registros para ver sus propiedades detalladas.
Pruebe una consulta más compleja, como AzureActivity | summarize count() by CategoryValue , que proporcione
un recuento de eventos resumidos por categoría.
Pasos siguientes
En este inicio rápido, ha configurado el registro de actividad que se va a enviar a un área de trabajo de Log
Analytics. Ahora puede configurar el resto de datos que se van a recopilar en el área de trabajo, donde podrá
analizarlos juntos mediante consultas de registro de Azure Monitor y podrá aprovechar características como
alertas de registro y libros. A continuación, debe recopilar registros de recursos de los recursos de Azure que
complementen los datos del registro de actividad lo cual proporcionará información sobre las operaciones que se
realizaron en cada recurso.
Recopilación y análisis de registros de recurso con Azure Monitor
Inicio rápido: Envío del registro de actividad de Azure
al área de trabajo de Log Analytics mediante una
plantilla de Resource Manager
El registro de actividad es un registro de la plataforma de Azure que proporciona información de los eventos en el
nivel de suscripción. Este registro incluye información como, por ejemplo, cuándo se modificó un recurso o cuándo
se inició una máquina virtual. Puede ver el registro de actividad en Azure Portal o recuperar entradas con
PowerShell y la CLI. En este inicio rápido se muestra cómo usar plantillas de Resource Manager para crear un área
de trabajo de Log Analytics y una configuración de diagnóstico para enviar el registro de actividad a los registros
de Azure Monitor donde podrá analizarlo mediante consultas de registro y habilitar otras características como
alertas de registro y libros.
Una plantilla de Resource Manager es un archivo de notación de objetos JavaScript (JSON) que define la
infraestructura y la configuración del proyecto. La plantilla usa sintaxis declarativa, lo que permite establecer lo que
pretende implementar sin tener que escribir la secuencia de comandos de programación para crearla.
Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Para ejecutar los comandos desde la máquina local, instale la CLI de Azure o los módulos de Azure PowerShell.
Para más información, consulte Instalación de la CLI de Azure e Instalar Azure Powershell.

Revisión de la plantilla
La siguiente plantilla permite crear una área de trabajo de Log Analytics vacía. Guarde esta plantilla como
CreateWorkspace.json.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
"description": "Name of the workspace."
}
},
"sku": {
"type": "string",
"allowedValues": [
"pergb2018",
"Free",
"Standalone",
"PerNode",
"Standard",
"Premium"
],
"defaultValue": "pergb2018",
"metadata": {
"description": "Pricing tier: PerGB2018 or legacy tiers (Free, Standalone, PerNode, Standard or
Premium) which are not available to all customers."
}
},
"location": {
"type": "string",
"allowedValues": [
"australiacentral",
"australiaeast",
"australiasoutheast",
"brazilsouth",
"canadacentral",
"centralindia",
"centralus",
"eastasia",
"eastus",
"eastus2",
"francecentral",
"japaneast",
"koreacentral",
"northcentralus",
"northeurope",
"southafricanorth",
"southcentralus",
"southeastasia",
"switzerlandnorth",
"switzerlandwest",
"uksouth",
"ukwest",
"westcentralus",
"westeurope",
"westus",
"westus2"
],
"metadata": {
"description": "Specifies the location for the workspace."
}
},
"retentionInDays": {
"type": "int",
"defaultValue": 120,
"metadata": {
"description": "Number of days to retain data."
}
},
"resourcePermissions": {
"type": "bool",
"defaultValue": true,
"metadata": {
"description": "true to use resource or workspace permissions. false to require workspace
permissions."
}
}
},
"resources": [
{
"type": "Microsoft.OperationalInsights/workspaces",
"apiVersion": "2020-03-01-preview",
"name": "[parameters('workspaceName')]",
"location": "[parameters('location')]",
"properties": {
"sku": {
"name": "[parameters('sku')]"
},
"retentionInDays": "[parameters('retentionInDays')]",
"features": {
"searchVersion": 1,
"legacy": 0,
"enableLogAccessUsingOnlyResourcePermissions": "[parameters('resourcePermissions')]"
}
}
}
]
}
Esta plantilla define un recurso:

Microsoft.OperationalInsights/workspaces
Implementación de la plantilla
Implemente la plantilla mediante cualquier método estándar de implementación de una plantilla de Resource
Manager como en los ejemplos siguientes con la CLI y PowerShell. Reemplace los valores de ejemplo del grupo
de recursos , nombre del área de trabajo y ubicación por los valores adecuados para su entorno. El nombre
del área de trabajo debe ser único entre todas las suscripciones de Azure.
CLI
PowerShell
az login
az deployment group create \
--name CreateWorkspace \
--resource-group my-resource-group \
--template-file CreateWorkspace.json \
--parameters workspaceName='my-workspace-01' location='eastus'
Validación de la implementación
Para comprobar que se ha creado el área de trabajo, utilice uno de los comandos siguientes. Reemplace los valores
de ejemplo del grupo de recursos y el nombre del área de trabajo por los valores que usó anteriormente.
CLI
PowerShell
az monitor log-analytics workspace show --resource-group my-workspace-01 --workspace-name my-resource-group
Creación de la configuración de diagnóstico

Revisión de la plantilla
La siguiente plantilla crea una configuración de diagnóstico que envía el registro de actividad a un área de trabajo
de Log Analytics. Guarde esta plantilla como CreateDiagnosticSetting.json.
{
"parameters": {
"settingName": {
"type": "String"
},
"workspaceId": {
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Insights/diagnosticSettings",
"name": "[parameters('settingName')]",
"dependsOn": [],
"properties": {
"workspaceId": "[parameters('workspaceId')]",
"logs": [
{
"category": "Administrative",
"enabled": true
},
{
"category": "Alert",
"enabled": true
},
{
"category": "Autoscale",
"enabled": true
},
{
"category": "Policy",
"enabled": true
},
{
"category": "Recommendation",
"enabled": true
},
{
"category": "ResourceHealth",
"enabled": true
},
{
"category": "Security",
"enabled": true
},
{
"category": "ServiceHealth",
"enabled": true
}
]
}
}
]
}
Esta plantilla define un recurso:

Microsoft.Insights/diagnosticSettings
Implementación de la plantilla
Implemente la plantilla mediante cualquier método estándar de implementación de una plantilla de Resource
Manager como en los ejemplos siguientes con la CLI y PowerShell. Reemplace los valores de ejemplo del grupo
de recursos , nombre del área de trabajo y ubicación por los valores adecuados para su entorno. El nombre
del área de trabajo debe ser único entre todas las suscripciones de Azure.
CLI
PowerShell
az deployment sub create --name CreateDiagnosticSetting --location eastus --template-file

CreateDiagnosticSetting.json --parameters settingName='Send Activity log to workspace'
workspaceId='/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-
group/providers/microsoft.operationalinsights/workspaces/my-workspace-01'
Validación de la implementación
Para comprobar que se ha creado la configuración de diagnóstico, utilice uno de los comandos siguientes.
Reemplace los valores de ejemplo de la suscripción y el nombre de la configuración por los valores que usó
anteriormente.
NOTE
Actualmente no se puede recuperar la configuración de diagnóstico en el nivel de suscripción mediante PowerShell.
az monitor diagnostic-settings show --resource '/subscriptions/00000000-0000-0000-0000-000000000000' --name

'Send Activity log to workspace'
Generación de datos del registro

Solo se enviarán las nuevas entradas del registro de actividad al área de trabajo de Log Analytics, por lo que
deberá realizar algunas acciones en la suscripción para que se registren, como iniciar o detener una máquina
virtual, o crear o modificar otro recurso. Es posible que tenga que esperar unos minutos para que se cree la
configuración de diagnóstico y los datos se escriban inicialmente en el área de trabajo. Después de este retraso,
todos los eventos escritos en el registro de actividad se enviarán al área de trabajo en cuestión de segundos.
Recuperación de datos con una consulta de registro

Use Azure Portal para que utilice Log Analytics para recuperar datos del área de trabajo. En Azure Portal, busque y
seleccione Monitor .
Seleccione Registros en el menú Azure Monitor . Cierre la página Consultas de ejemplo . Si el ámbito no está
establecido en el área de trabajo que ha creado, haga clic en Seleccionar ámbito y búsquelo.
En la ventana de consulta, escriba AzureActivity y haga clic en Ejecutar . Se trata de una consulta simple que
devuelve todos los registros de la tabla AzureActivity, que contiene todos los registros enviados desde el registro
de actividad.
Expanda uno de los registros para ver sus propiedades detalladas.
Pruebe una consulta más compleja, como AzureActivity | summarize count() by CategoryValue , que proporcione
un recuento de eventos resumidos por categoría.
Limpieza de recursos
Si planea seguir trabajando en otros inicios rápidos y tutoriales, considere la posibilidad de dejar estos recursos
activos. Cuando ya no lo necesite, elimine el grupo de recursos; de este modo, se eliminarán también la regla de
alertas y los recursos relacionados. Para eliminar el grupo de recursos mediante la CLI de Azure o Azure
PowerShell
CLI
PowerShell
az group delete --name my-resource-group
Pasos siguientes
En este inicio rápido, ha configurado el registro de actividad que se va a enviar a un área de trabajo de Log
Analytics. Ahora puede configurar el resto de datos que se van a recopilar en el área de trabajo, donde podrá
analizarlos juntos mediante consultas de registro de Azure Monitor y podrá aprovechar características como
alertas de registro y libros. A continuación, debe recopilar registros de recursos de los recursos de Azure que
complementen los datos del registro de actividad lo cual proporcionará información sobre las operaciones que se
realizaron en cada recurso.
Recopilación y análisis de registros de recurso con Azure Monitor
Inicio rápido: Supervisión de máquinas virtuales de
Azure con Azure Monitor
Azure Monitor comienza a recopilar datos de las máquinas virtuales de Azure en el momento en que se crean. En
este inicio rápido se proporciona un breve tutorial de los datos que se recopilan automáticamente para una
máquina virtual de Azure y de cómo verlos en Azure Portal. A continuación, habilitará Azure Monitor para VM para
la máquina virtual, lo que permitirá a los agentes de la máquina virtual recopilar y analizar los datos del sistema
operativo invitado, incluidos los procesos y sus dependencias.
En esta guía de inicio rápido se da por supuesto que tiene una máquina virtual de Azure. De no ser así, puede crear
una máquina virtual Windows o Linux con los pasos que se describen en nuestros inicios rápidos para máquinas
virtuales.
Para obtener descripciones más detalladas de los datos de supervisión recopilados de los recursos de Azure,
consulte Supervisión de máquinas virtuales de Azure con Azure Monitor.
Completar el inicio rápido de la supervisión de recursos de Azure

Complete Supervisión de recursos de Azure con Azure Monitor para ver la página de información general, el
registro de actividad y las métricas de una máquina virtual de su suscripción. Las máquinas virtuales de Azure
recopilan los mismos datos de supervisión que cualquier otro recurso de Azure, pero esto sucede solo para la
máquina virtual de host. El resto de este inicio rápido se centrará en la supervisión del sistema operativo invitado
y sus cargas de trabajo.
Habilitar Azure Monitor para VM

Mientras se recopilan las métricas y los registros de actividad para la máquina virtual de host, necesita un agente y
algunas configuraciones para recopilar y analizar los datos de supervisión del sistema operativo invitado y sus
cargas de trabajo. Azure Monitor para VM instala estos agentes y proporciona unas características adicionales más
eficaces para la supervisión de las máquinas virtuales.
1. Vaya al menú de la máquina virtual.
2. Haga clic en Ir a Insights en el icono de la página Introducción o haga clic en Insights en el menú
Super visión .
3. Si aún no se ha habilitado Azure Monitor para VM para la máquina virtual, haga clic en Habilitar .
4. Si la máquina virtual no está aún conectada a un área de trabajo de Log Analytics, se le pedirá que
seleccione un área de trabajo existente o que cree una. Seleccione el valor predeterminado que es un área
de trabajo con un nombre único en la misma región que la máquina virtual.
5. La incorporación tardará unos minutos, ya que las extensiones se habilitan y los agentes se instalan en la
máquina virtual. Cuando haya finalizado, recibirá un mensaje que indica que Insights se ha implementado
correctamente. Haga clic en Azure Monitor para abrir Azure Monitor para VM.
6. Verá que están incorporadas la máquina virtual con otras máquinas virtuales de la suscripción. Seleccione
la pestaña Sin super visión si desea ver las máquinas virtuales de la suscripción que no están
incorporadas.

Al crear una nueva área de trabajo de Log Analytics, es necesario configurarla para recopilar registros. Esta
configuración solo se debe realizar una vez, ya que se envía a cualquier máquina virtual que se conecte a ella.
1. Seleccione Configuración del área de trabajo y después el área de trabajo.
2. Seleccione Configuración avanzada .
Recopilación de datos de VM Windows
2. Seleccione Datos y, a continuación, Registros de eventos de Windows .
3. Para agregar un registro de eventos, escriba el nombre del registro. Escriba Sistema y, luego, seleccione el
signo más + .
4. En la tabla, compruebe los niveles de gravedad Error y Adver tencia .
5. Seleccione Guardar en la parte superior de la página para guardar la configuración.
Recopilación de datos de VM Linux
1. Seleccione Syslog .
2. Para agregar un registro de eventos, escriba el nombre del registro. Escriba Syslog y, luego, seleccione el
signo más + .
3. En la tabla, deseleccione los niveles de gravedad Información , Aviso y Depurar .
Ver datos recopilados

7. Haga clic en la máquina virtual y seleccione la pestaña Rendimiento situada bajo el icono Insights del
menú Super visión . Esto muestra un grupo seleccionado de contadores de rendimiento recopilados del
sistema operativo invitado de la máquina virtual. Desplácese hacia abajo para ver más contadores, y mueva
el mouse sobre un gráfico para ver el promedio y los percentiles en momentos diferentes.
8. Seleccione Mapa para abrir la característica de mapas que muestra los procesos que se ejecutan en la
máquina virtual y sus dependencias. Seleccione Propiedades para abrir el panel de propiedades si aún no
está abierto.
9. Expanda los procesos de la máquina virtual. Seleccione uno de los procesos para ver sus detalles y resaltar
sus dependencias.
10. Vuelva a seleccionar la máquina virtual y, luego, seleccione Registrar eventos .

11. Verá una lista de tablas que se almacenan en el área de trabajo de Log Analytics de la máquina virtual. Esta
lista será diferente en función de si usa una máquina virtual Windows o Linux. Haga clic en la tabla Evento .
Esto incluye todos los eventos del registro de eventos de Windows. Se abre Log Analytics con una consulta
simple para recuperar las entradas del registro de eventos.
Pasos siguientes
En este inicio rápido, ha habilitado Azure Monitor para VM para una máquina virtual y ha configurado el área de
trabajo de Log Analytics para recopilar eventos del sistema operativo invitado. Para obtener información sobre
cómo ver y analizar los datos, continúe con el tutorial.
Ver o analizar datos en Log Analytics
Inicio rápido: Recopilación de datos de un equipo
Linux en un entorno híbrido con Azure Monitor
Azure Monitor puede recopilar datos directamente de los equipos Linux físicos o virtuales del entorno en un
área de trabajo de Log Analytics para una correlación y un análisis detallados. La instalación del agente de Log
Analytics permite a Azure Monitor recopilar datos de un centro de datos o de otro entorno en la nube. En esta
guía de inicio rápido se muestra cómo configurar y recopilar datos del servidor Linux con unos pasos
sencillos. Para más información sobre las máquinas virtuales Linux de Azure, consulte Recopilación de datos
acerca de máquinas virtuales de Azure.
Para conocer la configuración admitida, consulte Sistemas operativos admitidos y Configuración del firewall
de red.


1. En Azure Portal, seleccione Todos los ser vicios . En la lista de recursos, escriba Log Analytics .
Cuando comience a escribir, la lista se filtrará en función de la entrada. Seleccione Áreas de trabajo
de Log Analytics .
2. Seleccione Crear y, después, seleccione opciones para los elementos siguientes:

Proporcione el nombre de la nueva área de trabajo de Log Analytics como, por ejemplo,
DefaultLAWorkspace.
Seleccione una suscripción a la que vincularlo en la lista desplegable si la opción
predeterminada seleccionada no es adecuada.
Para Grupo de recursos , seleccione un grupo de recursos existente que contenga una o más
máquinas virtuales de Azure.
Seleccione la Ubicación en que están implementadas las VM. Para obtener más información,
consulte en qué regiones está disponible Log Analytics.
Si va a crear un área de trabajo en una nueva suscripción creada después del 2 de abril de 2018,
esta utilizará automáticamente el plan de precios Por GB y la opción para seleccionar un plan de
tarifas no estará disponible. Si va a crear un área de trabajo para una suscripción existente creada
antes del 2 de abril o para una suscripción asociada a una inscripción de EA existente, seleccione
el plan de tarifa que prefiera. Para obtener más información sobre planes concretos, consulte los
detalles de precios de Log Analytics.
3. Después de proporcionar la información necesaria en el panel Área de trabajo de Log Analytics ,

seleccione Aceptar .
Mientras se comprueba la información y se crea el espacio de trabajo, puede realizar un seguimiento de su
progreso en Notificaciones en el menú.
Obtención de la clave y el identificador de área de trabajo

Antes de instalar el agente Log Analytics para Linux, necesita la clave y el identificador de área de trabajo para
el área de trabajo de Log Analytics. El script contenedor del agente necesita esta información para configurar
el agente de la forma adecuada y asegurarse de que puede comunicarse correctamente con Azure Monitor.
NOTE
Como parte de la transición en curso de Microsoft Operations Management Suite (OMS) a Azure Monitor, se hará
referencia al agente de Operations Management Suite para Windows o Linux como el agente de Log Analytics para
Windows y el agente de Log Analytics para Linux.
1. En la esquina superior izquierda de Azure Portal, seleccione Todos los ser vicios . En el cuadro de
búsqueda, escriba Log Analytics . La lista se filtra en función de lo que escriba. Seleccione Áreas de
trabajo de Log Analytics .
2. En la lista de áreas de trabajo de Log Analytics, seleccione la que creó anteriormente. (Puede que le
haya asignado el nombre DefaultL AWorkspace ).
4. Seleccione Orígenes conectados y Ser vidores Linux .
5. Encontrará los valores a la derecha de Id. del área de trabajo y Clave principal . Copie y pegue
ambos valores en el editor que prefiera.
Instalación del agente para Linux

Los pasos siguientes configuran la instalación del agente de Log Analytics en Azure y en la nube de Azure
Government.
NOTE
No se puede configurar el agente de Log Analytics para Linux para informar a varias áreas de trabajo de Log Analytics.
Si el equipo Linux necesita comunicarse mediante un servidor proxy con Log Analytics, la configuración del
proxy puede especificarse en la línea de comandos mediante la inclusión de
-p [protocol://][user:password@]proxyhost[:port] . La propiedad proxyhost acepta un nombre de dominio
completo o la dirección IP del servidor proxy.
Por ejemplo: https://user01:password@proxy01.contoso.com:30443
1. Para configurar el equipo Linux de modo que se conecte a un área de trabajo de Log Analytics, ejecute
el comando siguiente con el identificador del área de trabajo y la clave principal que ha copiado
anteriormente. El siguiente comando descarga el agente, valida su suma de comprobación y lo instala.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s
<YOUR WORKSPACE PRIMARY KEY>
El siguiente comando incluye el parámetro de proxy -p y la sintaxis de ejemplo necesaria cuando el

servidor proxy requiere autenticación:
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]
[user:password@]proxyhost[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY>
2. Para configurar el equipo Linux de modo que se conecte con un área de trabajo de Log Analytics en la
nube de Azure Government, ejecute el comando siguiente con el identificador del área de trabajo y la
clave principal que ha copiado anteriormente. El siguiente comando descarga el agente, valida su suma
de comprobación y lo instala.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s
<YOUR WORKSPACE PRIMARY KEY> -d opinsights.azure.us

Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]
[user:password@]proxyhost[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY> -d
opinsights.azure.us
3. Ejecute el comando siguiente para reiniciar el agente:
sudo /opt/microsoft/omsagent/bin/service_control restart [<workspace id>]
Recopilación de datos de eventos y rendimiento

Azure Monitor puede recopilar eventos de Linux Syslog y de los contadores de rendimiento que especifique
para el análisis y la generación de informes a más largo plazo. También puede realizar acciones cuando
detecta una condición determinada. Siga estos pasos para configurar la recopilación de eventos desde Syslog
de Linux, así como desde varios contadores de rendimiento comunes, para empezar.
1. En Azure Portal, seleccione Todos los ser vicios . En la lista de recursos, escriba Log Analytics. La lista
se filtra en función de lo que escriba. Seleccione Áreas de trabajo de Log Analytics y, en la lista,
seleccione el área de trabajo que busca y elija Configuración avanzada del área de trabajo de Log
Analytics .
2. Seleccione Datos y, después, seleccione Syslog .
3. Para agregar una instancia de syslog, escriba el nombre del registro. Escriba Syslog y, luego, seleccione
el signo más + .
4. En la tabla, desactive los niveles de gravedad Información , Aviso y Depurar .
6. Seleccione Linux Performance Data (Datos de rendimiento de Linux) para habilitar la recopilación de
contadores de rendimiento en un equipo Linux.
7. La primera vez que se configuran los contadores de rendimiento Linux para un área de trabajo de Log
Analytics nueva, se ofrece la opción de crear rápidamente varios contadores comunes. Se muestran
todos con una casilla junto a cada uno.
Seleccione Aplicar la configuración siguiente a mis máquinas y, luego, Agregar los
contadores de rendimiento seleccionados . Se agregan con el valor preestablecido de un intervalo
de ejemplo de recopilación de diez segundos.
Ver datos recopilados

Ahora que ya ha habilitado la recopilación de datos, vamos a ver un sencillo ejemplo de búsqueda de registros
para consultar algunos datos del equipo de destino.
1. En el área de trabajo seleccionada, en el panel izquierdo, seleccione Registros .
2. En la página de consulta de registros, escriba Perf en el editor de consultas y seleccione Ejecutar .
Por ejemplo, la consulta de la imagen siguiente ha devuelto 10 000 registros de rendimiento. Sus
resultados serán significativamente inferiores.
Cuando ya no lo necesite, puede quitar el agente del equipo Linux y eliminar el área de trabajo de Log
Analytics.
Para quitar el agente, ejecute el siguiente comando en el equipo Linux. El argumento --purge quita
completamente el agente y su configuración.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh --purge
Para eliminar el área de trabajo, seleccione el área de trabajo de Log Analytics que ha creado anteriormente y,
en la página de recursos, seleccione Eliminar .
Pasos siguientes
Ahora que ya recopila datos sobre el funcionamiento y el rendimiento del equipo Linux local, le resultará muy
fácil empezar a explorar y analizar los datos que se recopilan, además de tomar las medidas correspondientes
a partir de estos. Todo ello, de forma gratuita.
Para obtener información sobre cómo ver y analizar los datos, continúe con el tutorial.
Recopilación de datos de un equipo Windows en un
entorno híbrido con Azure Monitor
Azure Monitor puede recopilar datos directamente de los equipos Windows físicos o virtuales de su entorno en un
área de trabajo de Log Analytics para lograr una correlación y un análisis detallados. La instalación del agente de
Log Analytics permite a Azure Monitor recopilar datos de un centro de datos o de otro entorno en la nube. En esta
guía de inicio rápido se muestra cómo configurar y recopilar datos de equipos Windows con unos pasos sencillos.
Para información sobre las máquinas virtuales Windows de Azure, consulte Recopilación de datos acerca de
Para conocer la configuración admitida, consulte Sistemas operativos admitidos y Configuración del firewall de
red.


1. En Azure Portal, seleccione Todos los ser vicios . En la lista de recursos, escriba Log Analytics . Cuando
comience a escribir, la lista se filtrará en función de la entrada. Seleccione Áreas de trabajo de Log
Analytics .
2. Seleccione Crear y, después, seleccione opciones para los elementos siguientes:

DefaultLAWorkspace.
Seleccione una suscripción a la que vincularlo en la lista desplegable si la opción predeterminada
seleccionada no es adecuada.
Para Grupo de recursos , seleccione un grupo de recursos existente que contenga una o más
Seleccione la Ubicación en que están implementadas las VM. Para obtener más información,
consulte en qué regiones está disponible Log Analytics.
Si va a crear un área de trabajo en una nueva suscripción creada después del 2 de abril de 2018, esta
utilizará automáticamente el plan de precios Por GB y la opción para seleccionar un plan de tarifas no
estará disponible. Si va a crear un área de trabajo para una suscripción existente creada antes del 2 de
abril o para una suscripción asociada a una inscripción de EA existente, seleccione el plan de tarifa
que prefiera. Para obtener más información sobre planes concretos, consulte los detalles de precios
de Log Analytics.

Obtención de la clave y el identificador del área de trabajo

Antes de instalar el agente de Log Analytics para Windows (también denominado Microsoft Monitoring Agent
(MMA)), necesita la clave y el identificador del área de trabajo de Log Analytics. El Asistente para la instalación
necesita esta información a fin de configurar el agente de la forma adecuada y asegurarse de que pueda
comunicarse con Azure Monitor.
1. En la esquina superior izquierda de Azure Portal, seleccione Todos los ser vicios . En el cuadro de
búsqueda, escriba Log Analytics . La lista se filtra en función de lo que escriba. Seleccione Áreas de
trabajo de Log Analytics .
2. En la lista de áreas de trabajo de Log Analytics, seleccione la que creó anteriormente. (Puede que le haya
asignado el nombre DefaultL AWorkspace ).
4. Seleccione Orígenes conectados y Ser vidores Windows .
5. Copie los valores que aparecen a la derecha de Id. del área de trabajo y Clave principal . Péguelos en el
editor que prefiera.
Instalación del agente para Windows

En los pasos siguientes se instala y configura el agente para Log Analytics en Azure y Azure Government. Usará el
programa de instalación de Microsoft Monitoring Agent para instalar al agente en el equipo.
1. Continuando desde el conjunto anterior de pasos, en la página Ser vidores de Windows , seleccione la
versión de Descargar el agente de Windows deseada. Seleccione la versión adecuada para la
arquitectura de procesador del sistema operativo Windows.
2. Ejecute el programa de instalación para instalar al agente en el equipo.
3. En la página principal , seleccione Siguiente .
4. En la página Términos de licencia , lea la licencia y seleccione Acepto .
5. En la página Carpeta de destino , cambie o mantenga la carpeta de instalación predeterminada y
seleccione Siguiente .
6. En la página Opciones de instalación del agente , conecte el agente a Azure Log Analytics y, luego,
seleccione Siguiente .
7. En la página Azure Log Analytics , haga lo siguiente:
a. Pegue el identificador del área de trabajo y la clave del área de trabajo (clave principal) que
copió anteriormente. Si el equipo debe informar a un área de trabajo de Log Analytics en Azure
Government, seleccione Azure Gobierno de EE UU. en la lista Azure Cloud .
b. Si el equipo necesita comunicarse a través de un servidor proxy con el servicio de Log Analytics,
seleccione Avanzado y proporcione la dirección URL y el número de puerto del servidor proxy. Si el
servidor proxy requiere autenticación, escriba el nombre de usuario y la contraseña para la autenticación
con el servidor proxy y, luego, seleccione Siguiente .
8. Después de agregar los valores de configuración, seleccione Siguiente :
9. En la página Listo para instalar , revise las opciones elegidas y seleccione Instalar .
10. En la página Configuración completada correctamente , seleccione Finalizar .
Cuando finalice la instalación, Microsoft Monitoring Agent aparece en el Panel de Control. Puede revisar la
configuración y verificar que el agente esté conectado al área de trabajo de Log Analytics. Al conectarse, en la
pestaña Azure Log Analytics , el agente muestra este mensaje: Microsoft Monitoring Agent se ha
conectado correctamente al ser vicio Microsoft Log Analytics.
Recopilación de datos de eventos y rendimiento
Azure Monitor puede recopilar eventos que especifique del registro de eventos de Windows y de contadores de
rendimiento para el análisis y la generación de informes a largo plazo. También puede realizar acciones cuando
detecta una condición determinada. Siga estos pasos para configurar la colección de eventos desde el Registro de
eventos de Windows, así como desde varios contadores de rendimiento comunes, para empezar.
1. En la esquina inferior izquierda de Azure Portal, seleccione Más ser vicios . En el cuadro de búsqueda,
escriba Log Analytics . La lista se filtra en función de lo que escriba. Seleccione Áreas de trabajo de Log
Analytics .
3. Seleccione Datos y, a continuación, Registros de eventos de Windows .
4. Para agregar un registro de eventos, escriba el nombre del registro. Escriba Sistema y, luego, seleccione el
signo más ( + ).
5. En la tabla, seleccione los niveles de gravedad Error y Adver tencia .
6. En la parte superior de la página, seleccione Guardar .
7. Seleccione Windows Performance Counters (Contadores de rendimiento de Windows) para habilitar la
recopilación de contadores de rendimiento en un equipo Windows.
8. La primera vez que se configuran los contadores de rendimiento de Windows para una nueva área de
trabajo de Log Analytics, se ofrece la opción de crear rápidamente varios contadores comunes. Cada opción
que se muestra tiene al lado una casilla de verificación:
.
Seleccione Agregar los contadores de rendimiento seleccionados . Los contadores se agregan con un
valor preestablecido de un intervalo de ejemplo de recopilación de diez segundos.
9. En la parte superior de la página, seleccione Guardar .
Visualización de los datos recopilados

Ahora que ya ha habilitado la recopilación de datos, vamos a ver una búsqueda de registros sencilla para consultar
algunos datos del equipo de destino.
1. En el área de trabajo seleccionada, en el panel izquierdo, seleccione Registros .
2. En la página de consulta de registros, escriba Perf en el editor de consultas y seleccione Ejecutar .
Por ejemplo, la consulta de esta imagen ha devuelto 10 000 registros de rendimiento. Sus resultados serán
significativamente inferiores.
Cuando ya no los necesite, puede quitar el agente del equipo y eliminar el área de trabajo de Log Analytics.
Para quitar al agente, haga lo siguiente:
1. Abra el Panel de control.
2. Abra Programas y características .
3. En Programas y características , seleccione Microsoft Monitoring Agent y, luego, haga clic en
Desinstalar .
Para eliminar el área de trabajo de Log Analytics que creó anteriormente, selecciónela y, en la página de recursos,
seleccione Eliminar :
Pasos siguientes
Ahora que ha recopilado datos operativos y de rendimiento del equipo Windows, puede comenzar a explorar,
analizar e interpretar esos datos fácilmente de forma gratuita.
Para saber cómo ver y analizar los datos, continúe con el tutorial:
Inicio de la supervisión de la aplicación web ASP.NET
Con Azure Application Insights puede supervisar fácilmente la disponibilidad, el rendimiento y el uso de su
aplicación web. También puede identificar y diagnosticar errores en la aplicación rápidamente sin tener que esperar
a que un usuario informe de ellos. Con la información que recopile de Application Insights sobre el rendimiento y la
eficacia de la aplicación, puede tomar decisiones informadas para hacer el mantenimiento de la aplicación y
mejorarla.
En esta guía de inicio rápido se muestra cómo agregar Application Insights a una aplicación web ASP.NET existente
y empezar a analizar las estadísticas en vivo, que es solo uno de los distintos métodos que puede usar para
analizar la aplicación. Si no tiene una aplicación web ASP.NET, puede seguir el artículo de Inicio rápido de creación
de aplicaciones web ASP.NET para crear una.
Prerequisites
Para completar esta guía de inicio rápido:
Instale Visual Studio 2019 con las cargas de trabajo siguientes:
ASP.NET y desarrollo web
Desarrollo de Azure
Habilitación de Application Insights

1. Abra el proyecto en Visual Studio 2019.
2. Seleccione Configurar Application Insights desde el menú Proyecto. Visual Studio agregará el SDK de
Application Insights a la aplicación.
IMPORTANT
El proceso para agregar Application Insights varía según el tipo de plantilla de ASP.NET. Si usa la plantilla Vacía o
Aplicación móvil de Azure , seleccione Proyecto > Agregar telemetría de Application Insights . Para las
demás plantillas de ASP.NET, consulte las instrucciones del paso anterior.
3. Haga clic en Iniciar (en versiones anteriores de Visual Studio, haga clic en el botón Inicio gratis ).
4. Seleccione su suscripción y haga clic en Registrarse .
5. Seleccione Proyecto > Administrar paquetes NuGet > Origen de paquete: Nuget.org > Actualizar
para actualizar los paquetes del SDK de Application Insights a la versión estable más reciente.
6. Para ejecutar la aplicación, seleccione Iniciar depuración desde el menú Depurar o presionando la tecla
F5.
Confirmación de la configuración de la aplicación

Application Insights recopila datos de telemetría para la aplicación, independientemente de dónde se ejecute. Siga
estos pasos para empezar a ver los datos.
1. Abra Application Insights haciendo clic en Ver -> Otras ventanas -> Búsqueda de Application
Insights . Se mostrará la telemetría de la sesión actual.
2. Haga clic en la primera solicitud de la lista (en el ejemplo, GET Home/Index) para ver sus detalles. Observe
que, junto con otra información valiosa acerca de la solicitud, se incluye el código de estado y la hora de
respuesta.
Inicio de la supervisión en Azure Portal

Ya puede abrir Application Insights en Azure Portal para ver distintos detalles acerca de la aplicación en ejecución.
1. Expanda la carpeta Ser vicios conectados en el Explorador de soluciones y haga clic con el botón derecho
en la carpeta Application Insights y, después, en Abrir por tal de Application Insights . Se mostrará
cierta información acerca de la aplicación, así como varias opciones.
2. Haga clic en Mapa de aplicación para mostrar un diseño visual de las relaciones de dependencia entre los
componentes de la aplicación. Cada componente muestra KPI como la carga, el rendimiento, errores y
alertas.
3. Haga clic en el icono App Analytics Ver en Registros (Analytics) , en uno de los componentes de la
aplicación. Se abrirá Registros (Analytics) , que proporciona un lenguaje de consulta avanzado para
analizar todos los datos recopilados por Application Insights. En este caso, se genera una consulta que
representa el número de solicitudes en un gráfico. Puede escribir sus propias consultas para analizar otros
datos.
4. Haga clic en Live Metrics Stream a la izquierda Investigar. Se mostrarán estadísticas en vivo sobre la
aplicación mientras se ejecuta. Esto incluye información como el número de solicitudes entrantes, la
duración de estas y los errores que se producen. También puede inspeccionar las métricas de rendimiento
crítico, como el procesador y la memoria.
Si está listo para hospedar su aplicación en Azure, puede publicarla ahora. Siga los pasos que se describen
en la guía de inicio rápido para crear una aplicación web de ASP.NET.
5. Si usa Visual Studio para agregar la supervisión de Application Insights, puede agregar automáticamente la
supervisión de cliente. Para agregar manualmente la supervisión de cliente a una aplicación, agregue el
siguiente código de JavaScript a esta:

<script type="text/javascript">
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c=
{config:a},d=document,e=window;setTimeout(function(){var
b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTag
Name("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=
["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthentic
atedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPag
e"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var
g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<your instrumentation key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
</script>
Para más información, visite el repositorio de GitHub para nuestro SDK para JavaScript de código abierto.
Cuando haya realizado las pruebas, puede eliminar el grupo de recursos y todos los recursos relacionados. Para
ello, siga estos pasos.
1. En el menú izquierdo de Azure Portal, haga clic en Grupos de recursos y en myResourceGroup .
2. En la página del grupo de recursos, haga clic en Eliminar , escriba myResourceGroup en el cuadro de texto y
haga clic en Eliminar .
Pasos siguientes
En este inicio rápido, ha habilitado la aplicación para que Azure Application Insights la supervise. Continúe con las
guías de inicio rápido para aprender a usarlo para supervisar las estadísticas y detectar problemas en la aplicación.
Tutoriales de Azure Application Insights
Inicio de la supervisión de la aplicación web ASP.NET
Core
a que un usuario informe de ellos.
Esta guía de inicio rápido le ayudará a agregar el SDK de Application Insights a una aplicación web ASP.NET Core
existente. Para información sobre cómo configurar Application Insights sin Visual Studio, consulte este artículo.
Prerrequisitos
Para completar esta guía de inicio rápido:
Desarrollo de Azure
Instalación del SDK de .NET Core 2.0
Necesitará una suscripción de Azure y una aplicación web .NET Core existente.
Si no tiene una aplicación web ASP.NET Core, puede usar nuestra guía detallada para crear una aplicación ASP.NET
Core y agregar Application Insights.

Inicie sesión en Azure Portal.

Application Insights recopila datos de telemetría desde cualquier aplicación conectada a Internet,
independientemente de si se está ejecutando localmente o en la nube. Siga estos pasos para empezar a ver los
datos.
1. Seleccione Crear un recurso > Herramientas de desarrollo > Application Insights .
NOTE
Si esta es la primera vez que crea un recurso de Application Insights, puede obtener más información visitando la
documentación Creación de recursos en Application Insights.
Aparece un cuadro de configuración, use la tabla siguiente para rellenar los campos de entrada.
C O N F IGURA C IÓ N VA L UE DESC RIP C IÓ N
Nombre Nombre único global Nombre que identifica la aplicación

que se está supervisando
Grupo de recursos myResourceGroup Nombre del nuevo grupo de recursos

que hospedará los datos de
Application Insights. puede crear un
grupo de recursos o use uno
existente.
Ubicación Este de EE. UU. Elija una ubicación cerca de usted o

de donde se hospeda la aplicación
2. Haga clic en Crear .
Configuración del SDK de Application Insights

1. Abra el proyecto de la aplicación web ASP.NET Core en Visual Studio > haga clic con el botón derecho en el
nombre de la aplicación en el Explorador de soluciones > seleccione Agregar > Telemetría de
Application Insights .
2. Haga clic en el botón Comenzar

3. Seleccione su cuenta y su suscripción > Seleccione el recurso existente que creó en Azure Portal > Haga
clic en Registrar .
4. Seleccione Proyecto > Administrar paquetes NuGet > Origen de paquete: Nuget.org > Actualizar
para actualizar los paquetes del SDK de Application Insights a la versión estable más reciente.
5. Seleccione Depurar > Iniciar sin depurar (Ctrl + F5) para iniciar la aplicación.
NOTE
Los datos tardan unos 3-5 minutos en empezar a aparecer en el portal. Si se trata de una aplicación de prueba de poco
tráfico, tenga en cuenta que la mayoría de las métricas se capturan solo cuando hay solicitudes u operaciones activas.

1. Vuelva a abrir la Información general de Application Insights en Azure Portal; para ello, seleccione Inicio
y, bajo los recursos recientes, seleccione el recurso que creó anteriormente para ver los detalles acerca de la
aplicación que se ejecuta actualmente.
2. Haga clic en Mapa de la aplicación para ver un diseño visual de las relaciones de dependencia entre los
alertas.
3. Haga clic en el icono App Analytics Ver en Analytics . Se abrirá Application Insights Analytics , que
proporciona un lenguaje de consulta avanzado para analizar todos los datos recopilados por Application
Insights. En este caso, se genera una consulta que representa el número de solicitudes en un gráfico. Puede
escribir sus propias consultas para analizar otros datos.
4. Vuelva a la página Información general y examine los paneles de indicadores clave de rendimiento. Este
panel proporciona estadísticas sobre el estado de aplicación, incluido el número de solicitudes entrantes, la
duración de las solicitudes y los errores que se producen.
5. A la izquierda, haga clic en Métrica . Utilice el Explorador de métricas para investigar el estado y la utilización
del recurso. Puede hacer clic en Agregar nuevo gráfico para crear vistas personalizadas adicionales o
seleccionar Editar para modificar los tipos de gráfico existentes, el alto, la paleta de colores, las
agrupaciones o las métricas. Por ejemplo, puede hacer un gráfico que muestre el tiempo de carga de
páginas promedio del explorador si selecciona "Tiempo de carga de páginas del explorador" en la lista
desplegable de las métricas y "Promedio" en la agregación. Para más información acerca del Explorador de
métricas de Azure, consulte Introducción al Explorador de métricas de Azure.
Cuando haya realizado las pruebas, puede eliminar el grupo de recursos y todos los recursos relacionados. Para
NOTE
Si ha usado un grupo de recursos existente, las instrucciones siguientes no funcionarán y solo necesitará eliminar el recurso
individual de Application Insights. Tenga en cuenta que, cada vez que elimine un grupo de recursos, se eliminarán todos los
recursos subyacentes que sean miembros de ese grupo.
1. En el menú izquierdo de Azure Portal, haga clic en Grupos de recursos y en myResourceGroup .

2. En la página del grupo de recursos, haga clic en Eliminar , escriba myResourceGroup en el cuadro de texto y
haga clic en Eliminar .
Pasos siguientes
Búsqueda y diagnóstico de excepciones en tiempo de ejecución
Inicio rápido: Empiece a supervisar su aplicación web
creada con Node.js con Azure Application Insights
En este inicio rápido, se agrega la versión 0.22 del SDK de Application Insights para Node.js a una aplicación web
de Node.js existente.
a que un usuario informe de ellos. Con la versión 0.20 del SDK y posteriores, puede supervisar los paquetes
externos comunes, como MongoDB, MySQL y Redis.
Prerrequisitos
Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Una aplicación de Node.js en funcionamiento.

Application Insights puede recopilar datos de telemetría de cualquier aplicación conectada a Internet,
independientemente de que se ejecute en un entorno local o en la nube. Siga estos pasos para empezar a ver los
datos.
1. Inicie sesión en Azure Portal.
NOTE
Aparece una página de configuración, use la tabla siguiente para rellenar los campos de entrada.
Nombre Nombre único global Nombre que identifica la aplicación

que está supervisando.
Grupo de recursos myResourceGroup Nombre del nuevo grupo de recursos

que hospedará los datos de
AppInsights. puede crear un grupo
de recursos o use uno existente.

3. Seleccione Crear .
Configuración del SDK de AppInsights

1. Seleccione Información general y copie la clave de instrumentación de la aplicación.
2. Agregue el SDK de Application Insights para Node.js a la aplicación. Desde la carpeta raíz de la aplicación,
ejecute:
npm install applicationinsights --save
3. Edite el primer archivo .js de la aplicación y agregue las dos líneas siguientes al principio del script. Si usa la
aplicación del inicio rápido de Node.js, se modificará el archivo index.js. Reemplace <instrumentation_key>
por la clave de instrumentación de la aplicación.
const appInsights = require('applicationinsights');

appInsights.setup('<instrumentation_key>').start();
4. Reinicie la aplicación.
NOTE
Los datos tardan unos 3-5 minutos en empezar a aparecer en el portal. Si se trata de una aplicación de prueba de poco
tráfico, tenga en cuenta que la mayoría de las métricas se capturan solo cuando hay solicitudes u operaciones activas.

1. Ahora puede volver a abrir la página Introducción de Application Insights en Azure Portal; para ello, de
donde recuperó la clave de instrumentación, para ver los detalles de la aplicación en ejecución.
2. Seleccione Mapa de la aplicación para ver un diseño visual de las relaciones de dependencia entre los
alertas.
3. Seleccione el icono App Analytics Ver en Analytics . Esta acción abre Application Insights Analytics ,
que proporciona un lenguaje de consulta avanzado para analizar todos los datos recopilados por
Application Insights. En este caso, se genera una consulta que representa el número de solicitudes en un
gráfico. Puede escribir sus propias consultas para analizar otros datos.
4. Vuelva a la página Información general y examine los gráficos de indicadores clave de rendimiento. Este
panel proporciona estadísticas sobre el estado de aplicación, incluido el número de solicitudes entrantes, la
duración de las solicitudes y los errores que se producen.
Para habilitar el gráfico Tiempo de carga de la vista de página que se rellenará con los datos de
Telemetría del lado cliente , agregue este script para cada página de las que desee realizar el
seguimiento:

var appInsights=window.appInsights||function(config){
function i(config){t[config]=function(){var i=arguments;t.queue.push(function()
{t[config].apply(t,i)})}}var t=
{config:config},u=document,e=window,o="script",s="AuthenticatedUserContext",h="start",c="stop",l="Track"
,a=l+"Event",v=l+"Page",y=u.createElement(o),r,f;y.src=config.url||"https://az416426.vo.msecnd.net/scrip
ts/a/ai.0.js";u.getElementsByTagName(o)[0].parentNode.appendChild(y);try{t.cookie=u.cookie}catch(p)
{}for(t.queue=[],t.version="1.0",r=
["Event","Exception","Metric","PageView","Trace","Dependency"];r.length;)i("track"+r.pop());return
i("set"+s),i("clear"+s),i(h+a),i(c+a),i(h+v),i(c+v),i("flush"),config.disableExceptionTracking||
(r="onerror",i("_"+r),f=e[r],e[r]=function(config,i,u,e,o){var s=f&&f(config,i,u,e,o);return
s!==!0&&t["_"+r](config,i,u,e,o),s}),t
}({
instrumentationKey:"<insert instrumentation key>"
});
window.appInsights=appInsights;
appInsights.trackPageView();
</script>
5. En el lado izquierdo, seleccione Métrica . Utilice el Explorador de métricas para investigar el estado y la
utilización del recurso. Puede seleccionar Agregar nuevo gráfico para crear vistas personalizadas
adicionales o seleccionar Editar para modificar los tipos de gráfico existentes, el alto, la paleta de colores,
las agrupaciones o las métricas. Por ejemplo, puede hacer un gráfico que muestre el tiempo de carga de
páginas promedio del explorador si selecciona "Tiempo de carga de páginas del explorador" en la lista
desplegable de las métricas y "Promedio" en la agregación. Para más información acerca del Explorador de
métricas de Azure, consulte Introducción al Explorador de métricas de Azure.
Para más información sobre la supervisión de Node.js, consulte la documentación adicional de Node.js con
Cuando haya finalizado las pruebas, puede eliminar el grupo de recursos y todos los recursos relacionados. Para
NOTE
Si ha usado un grupo de recursos existente, las instrucciones siguientes no funcionarán y solo necesitará eliminar el recurso
individual de Application Insights. Tenga esto en cuenta que cada vez que se elimina un grupo de recursos, se eliminarán
todos los recursos de subyacente que sean miembros de ese grupo.
1. En el menú izquierdo de Azure Portal, seleccione Grupos de recursos y myResourceGroup .

2. En la página del grupo de recursos, seleccione Eliminar , escriba myResourceGroup en el cuadro de texto y,
después, seleccione Eliminar .
Pasos siguientes
Búsqueda y diagnóstico de problemas de rendimiento
Comience a analizar la aplicación móvil con App
Center y Application Insights.
Esta guía de inicio rápido le orienta a través de la conexión de la instancia de App Center de la aplicación a
Application Insights. Con Application Insights, puede consultar, segmentar, filtrar y analizar la telemetría con
herramientas más eficaces que las disponibles en el servicio Analytics de App Center.
Requisitos previos
Para completar este inicio rápido necesita instalar:
Suscripción a Azure.
Una aplicación iOS, Android, Xamarin, Universal Windows o React Native.
Registro en App Center

Para empezar, cree una cuenta y regístrese en App Center.
Incorporación a App Center

Antes de poder usar Application Insights con su aplicación móvil, debe integrar la aplicación en App Center.
Application Insights no recibe datos de telemetría de su aplicación móvil directamente. En su lugar, la aplicación
envía telemetría de eventos personalizada a App Center. A continuación, App Center exporta continuamente
copias de estos eventos personalizados a Application Insights a medida que se reciben los eventos. (Esto no es
válido para el SDK de Application Insights JS ni para el complemento React Native, donde la telemetría se envía
directamente a Application Insights).
Para incorporar la aplicación, siga la guía de inicio rápido de App Center para cada plataforma que admita la
aplicación. Cree instancias de App Center independientes para cada plataforma:
iOS.
Android.
Xamarin.
Universal Windows.
React Native.
Seguimiento de eventos en la aplicación

Una vez que la aplicación esté incorporada a App Center, se debe modificar para que envíe telemetría de eventos
personalizados con el SDK de App Center. Los eventos personalizados son el único tipo de telemetría de App
Center que se exporta a Application Insights.
Para enviar eventos personalizados desde aplicaciones iOS, utilice los métodos trackEvent o
trackEvent:withProperties en el SDK de App Center. Más información sobre el seguimiento de eventos de las
aplicaciones iOS.
MSAnalytics.trackEvent("Video clicked")
Para enviar eventos personalizados desde aplicaciones Android, utilice el método trackEvent en el SDK de App
Center. Más información sobre el seguimiento de eventos de las aplicaciones Android.
Analytics.trackEvent("Video clicked")
Para enviar eventos personalizados desde otras plataformas de aplicaciones, use los métodos trackEvent en los
SDK de App Center.
Para asegurarse de que se reciben los eventos personalizados, vaya a la pestaña Eventos de la sección Analytics
de App Center. Los eventos pueden tardar un par de minutos en aparecer desde que se enviaron desde la
aplicación.
Creación de recursos en Application Insights

Cuando la aplicación envía eventos personalizados y App Center los recibe, tiene que crear un recurso de
Application Insights para App Center en Azure Portal:
NOTE
Aparecerá un cuadro de configuración. Use la tabla siguiente para rellenar los campos de entrada.
Nombre Algún valor único global, como Nombre que identifica la aplicación
"myApp-iOS" que se está supervisando
Grupo de recursos Un grupo de recursos nuevo o uno El grupo de recursos en que se va a

existente desde el menú crear el recurso de Application
Insights
Ubicación Una ubicación en el menú Elija una ubicación cerca de usted o


Si la aplicación admite varias plataformas (iOS, Android, etc.), es mejor crear recursos de Application Insights
independientes, uno para cada plataforma.
Exportación a Application Insights

En el nuevo recurso de Application Insights, en la página Introducción . Copie la clave de instrumentación del
recurso.
En la instancia de App Center de la aplicación:
1. En la página Configuración , haga clic en Expor tar .
2. Elija Nueva expor tación , seleccione Application Insights y después haga clic en Personalizar .
3. Pegue la clave de instrumentación de Application Insights en el cuadro.
4. Dé su consentimiento para aumentar el uso de la suscripción de Azure que contiene el recurso de Application
Insights. El primer GB de datos recibidos al mes de cada recurso de Application Insights es gratis. Más
información sobre los precios de Application Insights
Recuerde que debe repetir este proceso para cada plataforma que su aplicación admita.
Una vez configurada la exportación, cada evento personalizado que recibe App Center se copia en Application
Insights. Los eventos pueden tardar varios minutos en llegar a Application Insights, así que, si no aparecen
inmediatamente, espere un poco antes de realizar otro diagnóstico.
Para proporcionarle más datos cuando se conecte por primera vez, las 48 horas más recientes de eventos
personalizados de App Center se exportan automáticamente a Application Insights.
Inicio de la supervisión de la aplicación

Application Insights puede consultar, segmentar, filtrar y analizar la telemetría de eventos personalizada desde las
aplicaciones, de forma más exhaustiva que las herramientas de análisis que App Center ofrece.
1. Consulte la telemetría de eventos personalizados. En la página de información general de
Application Insights, seleccione Logs (Analytics) .
Se abre el portal Logs (Analytics) de Application Insights asociado con el recurso de Application Insights. El
portal de Logs (Analytics) permite consultar directamente los datos mediante el lenguaje de consulta de
Log Analytics, por lo que puede hacer preguntas arbitrariamente complejas sobre la aplicación y sus
usuarios.
Abra una pestaña nueva en el portal de Logs (Analytics) y después pegue la siguiente consulta. Devuelve
un recuento de cuántos usuarios distintos han enviado cada evento personalizado desde la aplicación en
las últimas 24 horas, ordenados por estos recuentos distintivos.
customEvents
| where timestamp >= ago(24h)
| summarize dcount(user_Id) by name
| order by dcount_user_Id desc
a. Seleccione la consulta haciendo clic en cualquier parte de la consulta en el editor de texto.
b. Después haga clic en Ir para ejecutar la consulta.
Obtenga más información sobre Analytics en Application Insights y el lenguaje de consulta de Log
Analytics.
2. Segmente y filtre la telemetría de eventos personalizados. En la página de información general
de Application Insights, seleccione Usuarios en la tabla de contenido.
La herramienta Usuarios muestra cuántos usuarios de la aplicación hicieron clic en determinados botones,
visitaron determinadas pantallas o realizaron cualquier otra acción de la que se realiza un seguimiento
como evento con el SDK de App Center. Si busca una forma de segmentar y filtrar los eventos de App
Center, la herramienta Usuarios es una excelente opción.
Por ejemplo, segmente el uso por zona geográfica; para ello, elija País o región en el menú desplegable
Dividido por .
3. Analice los patrones de conversión, retención y navegación de la aplicación. En la página de
información general de Application Insights, seleccione Flujos de usuario en la tabla de contenido.
En la herramienta Flujos de usuario se visualizan los eventos que los usuarios envían después de algún
evento inicial. Es útil para obtener una visión general de cómo los usuarios navegan por la aplicación.
También puede indicar los lugares que muchos usuarios recorren desde la aplicación o repiten las mismas
acciones una y otra vez.
Además de Flujos de usuario, Application Insights dispone de otras herramientas de análisis de
comportamiento de usuarios para responder a preguntas específicas:
Embudos para analizar y supervisar las tasas de conversión.
Retención para analizar el grado en que la aplicación retiene a los usuarios con el paso del tiempo.
Workbooks para combinar visualizaciones y texto en un informe que se pueda compartir.
Cohor tes para nombrar y guardar grupos de usuarios o eventos específicos, para poder hacer
referencia a ellos fácilmente desde otras herramientas de análisis.
Si no desea continuar utilizando Application Insights con App Center, desactive la exportación en App Center y
elimine el recurso de Application Insights. Esto evitará que se le cobren cargos adicionales por Application
Insights para este recurso.
Para desactivar la exportación en App Center:
1. En App Center, vaya a Configuración y elija Expor tar .
2. Haga clic en la exportación de Application Insights que desee eliminar y después haga clic en Eliminar
expor tación en la parte inferior y confirme.
Para eliminar el recurso de Application Insights:
1. En el menú izquierdo de Azure Portal, haga clic en Grupos de recursos y después elija el grupo de recursos
en que se creó el recurso de Application Insights.
2. Abra el recurso de Application Insights que desea eliminar. Después haga clic en Eliminar en el menú
superior del recurso y confirme. Se eliminará de forma permanente la copia de los datos exportados a
Pasos siguientes
Información sobre la forma en que los clientes usan la aplicación
Inicio rápido: Empezar a supervisar un sitio web con
Azure Monitor Application Insights
En este inicio rápido, aprenderá a agregar el SDK de JavaScript para Application Insights de código abierto a un
sitio web. También aprenderá a conocer mejor la experiencia de lado cliente/explorador de los visitantes de su sitio
web.
Con Application Insights de Azure Monitor puede supervisar fácilmente la disponibilidad, el rendimiento y el uso
del sitio web. También puede identificar y diagnosticar errores en la aplicación rápidamente sin tener que esperar a
que un usuario informe de ellos. Application Insights proporciona funcionalidades de supervisión tanto del lado
servidor como del lado cliente/explorador.
Prerrequisitos
Un sitio web al que puede agregar el SDK de JavaScript para Application Insights.

Application Insights puede recopilar datos de telemetría desde cualquier aplicación conectada a Internet que se
ejecute tanto en la nube como en un entorno local. Para ver estos datos, siga estos pasos:
2. Seleccione Crear un recurso > Herramientas de administración > Application Insights .
NOTE
Si es la primera vez que crea un recurso de Application Insights, consulte Creación de recursos en Application
Insights.
3. Cuando aparezca el cuadro de configuración, use la tabla siguiente para completar los campos de entrada:
Nombre Nombre único global El nombre que identifica la aplicación

que está supervisando.
Grupo de recursos myResourceGroup El nombre del nuevo grupo de

recursos que hospeda los datos de
Application Insights. puede crear un
grupo de recursos o use uno
existente.

de donde se hospeda la aplicación.
4. Seleccione Crear .
Creación de un archivo HTML
1. En el equipo local, cree un archivo llamado hello_world.html . En este ejemplo, cree el archivo en la raíz de
la unidad C, así que debe ser algo como C:\hello_world.html .
2. Copie y pegue el siguiente script en hello_world.html :
<!DOCTYPE html>
<html>
<head>
<title>Azure Monitor Application Insights</title>
</head>
<body>
<h1>Azure Monitor Application Insights Hello World!</h1>
<p>You can use the Application Insights JavaScript SDK to perform client/browser-side monitoring of
your website. To learn about more advanced JavaScript SDK configurations, visit the <a
href="https://github.com/Microsoft/ApplicationInsights-JS/blob/master/API-reference.md" title="API
Reference">API reference</a>.</p>
</body>
</html>

1. Seleccione Información general > Información esencial y copie la clave de instrumentación de la
aplicación.
2. Agregue el siguiente script al archivo hello_world.html antes de la etiqueta de cierre </head> :

!function(T,l,y){var
S=T.location,u="script",k="instrumentationKey",D="ingestionendpoint",C="disableExceptionTracking",E="ai
.device.",I="toLowerCase",b="crossOrigin",w="POST",e="appInsightsSDK",t=y.name||"appInsights";
(y.name||T[e])&&(T[e]=t);var n=T[t]||function(d){var g=!1,f=!1,m={initialize:!0,queue:
[],sv:"4",version:2,config:d};function v(e,t){var n={},a="Browser";return n[E+"id"]=a[I]
(),n[E+"type"]=a,n["ai.operation.name"]=S&&S.pathname||"_unknown_",n["ai.internal.sdkVersion"]="javascr
ipt:snippet_"+(m.sv||m.version),{time:function(){var e=new Date;function t(e){var t=""+e;return
1===t.length&&(t="0"+t),t}return e.getUTCFullYear()+"-"+t(1+e.getUTCMonth())+"-
"+t(e.getUTCDate())+"T"+t(e.getUTCHours())+":"+t(e.getUTCMinutes())+":"+t(e.getUTCSeconds())+"."+
((e.getUTCMilliseconds()/1e3).toFixed(3)+"").slice(2,5)+"Z"}
(),iKey:e,name:"Microsoft.ApplicationInsights."+e.replace(/-/g,"")+"."+t,sampleRate:100,tags:n,data:
{baseData:{ver:2}}}}var h=d.url||y.src;if(h){function a(e){var t,n,a,i,r,o,s,c,p,l,u;g=!0,m.queue=
[],f||(f=!0,t=h,s=function(){var e={},t=d.connectionString;if(t)for(var
n=t.split(";"),a=0;a<n.length;a++){var i=n[a].split("=");2===i.length&&(e[i[0][I]()]=i[1])}if(!e[D])
{var r=e.endpointsuffix,o=r?e.location:null;e[D]="https://"+(o?o+".":"")+"dc."+
(r||"services.visualstudio.com")}return e}(),c=s[k]||d[k]||"",p=s[D],l=p?
p+"/v2/track":config.endpointUrl,(u=[]).push((n="SDK LOAD Failure: Failed to load Application Insights
SDK script (See stack for details)",a=t,i=l,(o=
(r=v(c,"Exception")).data).baseType="ExceptionData",o.baseData.exceptions=
[{typeName:"SDKLoadFailed",message:n.replace(/\./g,"-"),hasFullStack:!1,stack:n+"\nSnippet failed to
load ["+a+"] -- Telemetry is disabled\nHelp Link: https://go.microsoft.com/fwlink/?
linkid=2128109\nHost: "+(S&&S.pathname||"_unknown_")+"\nEndpoint: "+i,parsedStack:
[]}],r)),u.push(function(e,t,n,a){var i=v(c,"Message"),r=i.data;r.baseType="MessageData";var
o=r.baseData;return o.message='AI (Internal): 99 message:"'+("SDK LOAD Failure: Failed to load
Application Insights SDK script (See stack for details) ("+n+")").replace(/\"/g,"")+'"',o.properties=
{endpoint:a},i}(0,0,t,l)),function(e,t){if(JSON){var n=T.fetch;if(n&&!y.useXhr)n(t,
{method:w,body:JSON.stringify(e),mode:"cors"});else if(XMLHttpRequest){var a=new
XMLHttpRequest;a.open(w,t),a.setRequestHeader("Content-
type","application/json"),a.send(JSON.stringify(e))}}}(u,l))}function i(e,t){f||setTimeout(function()
{!t&&m.core||a()},500)}var e=function(){var n=l.createElement(u);n.src=h;var
e=y[b];return!e&&""!==e||"undefined"==n[b]||
(n[b]=e),n.onload=i,n.onerror=a,n.onreadystatechange=function(e,t)
{"loaded"!==n.readyState&&"complete"!==n.readyState||i(0,t)},n}();y.ld<0?l.getElementsByTagName("head")
[0].appendChild(e):setTimeout(function(){l.getElementsByTagName(u)
[0].parentNode.appendChild(e)},y.ld||0)}try{m.cookie=l.cookie}catch(p){}function t(e)
{for(;e.length;)!function(t){m[t]=function(){var e=arguments;g||m.queue.push(function()
{m[t].apply(m,e)})}}(e.pop())}var
n="track",r="TrackPage",o="TrackEvent";t([n+"Event",n+"PageView",n+"Exception",n+"Trace",n+"DependencyD
ata",n+"Metric",n+"PageViewPerformance","start"+r,"stop"+r,"start"+o,"stop"+o,"addTelemetryInitializer"
,"setAuthenticatedUserContext","clearAuthenticatedUserContext","flush"]),m.SeverityLevel=
{Verbose:0,Information:1,Warning:2,Error:3,Critical:4};var s=(d.extensionConfig||
{}).ApplicationInsightsAnalytics||{};if(!0!==d[C]&&!0!==s[C]){method="onerror",t(["_"+method]);var
c=T[method];T[method]=function(e,t,n,a,i){var r=c&&c(e,t,n,a,i);return!0!==r&&m["_"+method]
({message:e,url:t,lineNumber:n,columnNumber:a,error:i}),r},d.autoExceptionInstrumented=!0}return m}
(y.cfg);(T[t]=n).queue&&0===n.queue.length&&n.trackPageView({})}(window,document,{
src: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js", // The SDK URL Source
//name: "appInsights", // Global SDK Instance name defaults to "appInsights" when not supplied
//ld: 0, // Defines the load delay (in ms) before attempting to load the sdk. -1 = block page load and
add to head. (default) = 0ms load after timeout,
//useXhr: 1, // Use XHR instead of fetch to report failures (if available),
//crossOrigin: "anonymous", // When supplied this will add the provided value as the cross origin
attribute on the script tag
cfg: { // Application Insights Configuration
instrumentationKey: "YOUR_INSTRUMENTATION_KEY_GOES_HERE"
/* ...Other Configuration Options... */
}});
</script>
3. Modifique hello_world.html y agregue la clave de instrumentación.

4. Abra hello_world.html en una sesión de explorador local. Esta acción crea una vista de página individual.
Puede actualizar el explorador para generar varias vistas de páginas de prueba.
Supervisión de un sitio web en Azure Portal

1. Vuelva a abrir la página de información general de Application Insights en Azure Portal para ver los
detalles de la aplicación en ejecución. La página de información general es donde ha recuperado la clave
de instrumentación.
Los cuatro gráficos predeterminados de la página de introducción se extienden a los datos de la aplicación
del lado servidor. Dado que vamos a instrumentar las interacciones del lado cliente/explorador con el SDK
de JavaScript, esta vista concreta no se aplica, salvo que también tengamos instalado un SDK del lado
servidor.
2. Seleccione Analytics . Esta acción abre Analytics , que proporciona un lenguaje de consulta avanzado
para analizar todos los datos recopilados por Application Insights. Para ver los datos relacionados con las
solicitudes de explorador del lado cliente, ejecute la siguiente consulta:
// average pageView duration by name

let timeGrain=1s;
let dataset=pageViews
// additional filters can be applied here
| where timestamp > ago(15m)
| where client_Type == "Browser" ;
// calculate average pageView duration for all pageViews
dataset
| summarize avg(duration) by bin(timestamp, timeGrain)
| extend pageView='Overall'
// render result in a chart
| render timechart
3. Vuelva a la página Introducción . En el encabezado Investigar , seleccione Explorador y, después,

seleccione Rendimiento . Aparecen las métricas relacionadas con el rendimiento de su sitio web. Hay una
vista correspondiente para analizar los errores y excepciones del sitio web. Puede seleccionar Ejemplos
para acceder a los detalles de la transacción de un extremo a otro.
4. En el menú principal de Application Insights, en el encabezado Uso , seleccione Usuarios para empezar a
explorar las herramientas de análisis del comportamiento del usuario. Dado que las pruebas se realizan
desde una sola máquina, solo se verán los datos de un usuario. En el caso de un sitio web en vivo, la
distribución de los usuarios podría ser como esta:
5. En el caso de un sitio web más complejo con varias páginas, puede usar la herramienta Flujos de usuario
para realizar el seguimiento del recorrido que realizan los visitantes en las distintas partes del sitio web.
Para más información acerca de configuraciones avanzadas para supervisar sitios web, consulte la referencia a
JavaScript SDK API.
Si planea seguir trabajando con otros inicios rápidos o tutoriales, no limpie los recursos creados en este inicio
rápido. De lo contrario, realice los siguientes pasos para eliminarlos en Azure Portal.
NOTE
Si ha usado un grupo de recursos existente, las siguientes instrucciones no funcionarán. En su lugar, puede eliminar el
recurso de Application Insights individual. Tenga esto en cuenta que cuando se elimina un grupo de recursos, se eliminan
también todos los recursos subyacentes que sean miembros del grupo.
1. En el menú de la izquierda de Azure Portal, seleccione Grupos de recursos y luego myResourceGroup , o el

nombre de un grupo de recursos temporal.
2. En la página del grupo de recursos, seleccione Eliminar , escriba myResourceGroup en el cuadro de texto y,
después, seleccione Eliminar .
Pasos siguientes
Búsqueda y diagnóstico de problemas de rendimiento
Tutorial: Creación de un gráfico de métricas en Azure
Monitor
El explorador de métricas es una característica de Azure Monitor de Azure Portal que permite crear gráficos a
partir de valores de métricas, correlacionar visualmente las tendencias e investigar los repuntes o las caídas en los
valores de las métricas. Utilice el explorador de métricas para investigar el estado y el uso de los recursos de
Azure o para trazar gráficos a partir de métricas personalizadas.
En este tutorial, aprenderá a:
Seleccionar una métrica para la que trazar un gráfico
Realizar agregaciones diferentes de valores de métricas
Modificar el intervalo de tiempo y la granularidad del gráfico
El siguiente es un vídeo que muestra un escenario más amplio que el procedimiento descrito en este artículo. Si
no está familiarizado con las métricas, le recomendamos que lea este artículo primero y que vea después el vídeo
para conocer más detalles.
Prerrequisitos
Para completar este tutorial, necesitará un recurso de Azure para supervisarlo. Puede usar cualquier recurso de la
suscripción de Azure que admita métricas. Para determinar si un recurso es compatible con las métricas, vaya a su
menú en Azure Portal y busque la opción Métricas en la sección Super visión del menú.
Inicio de sesión en Azure

Apertura del explorador de métricas y selección de un ámbito

Puede abrir el explorador de métricas desde el menú de Azure Monitor o desde el menú de un recurso en Azure
Portal. Las métricas de todos los recursos están disponibles independientemente de la opción que use.
1. Seleccione Métricas en el menú de Azure Monitor o en la sección Super visión del menú de un recurso.
2. Seleccione Ámbito , que es el recurso del cual desea ver las métricas. El ámbito aparece ya relleno al abrir
el explorador de métricas desde el menú de un recurso.
3. Seleccione Espacio de nombres si el ámbito tiene más de uno. El espacio de nombres es una forma de
organizar las métricas para que se puedan encontrar fácilmente. Por ejemplo, las cuentas de
almacenamiento tienen espacios de nombres aparte para almacenar las métricas de File service, Table
service, Blob service y Queue service. Muchos tipos de recursos solo tienen un espacio de nombres.
4. Seleccione una métrica de una lista de métricas disponibles para el ámbito y el espacio de nombres
seleccionados.
5. Si lo desea, cambie el valor de Agregación de la métrica. Esto define cómo se agregarán los valores de las
métricas en la granularidad de tiempo del gráfico. Por ejemplo, si la granularidad de tiempo se establece en
15 minutos y la agregación se establece en Suma, cada punto del gráfico será la suma de todos los valores
recopilados en cada segmento de 15 minutos.
6. Use el botón Agregar métrica y repita estos pasos si quiere ver varias métricas trazadas en el mismo
gráfico. Seleccione el botón Nuevo gráfico para ver varios gráficos en una vista.
Selección de un intervalo de tiempo y granularidad

El gráfico muestra las últimas 24 horas de los datos de métricas de forma predeterminada. Use el selector de
tiempo para cambiar el inter valo de tiempo del gráfico o la granularidad de tiempo que define el intervalo
de tiempo para cada punto de datos. El gráfico utiliza la agregación especificada para calcular todos los valores
muestreados a lo largo de la granularidad de tiempo especificada.
Use la herramienta del pincel de tiempo para investigar un área interesante del gráfico, como un repunte o una
caída. Coloque el puntero del mouse al principio del área, haga clic y mantenga presionado el botón izquierdo,
arrastre al otro lado del área y suelte el botón. El gráfico acercará el intervalo de tiempo.
Aplicar filtros de dimensión y divisiones

Consulte las siguientes referencias para características avanzadas que permiten realizar análisis adicionales de las
métricas e identificar posibles valores atípicos en los datos.
El filtrado permite elegir qué valores de dimensión se van a incluir en el gráfico. Por ejemplo, puede que le
interese mostrar las solo las solicitudes correctas al representar gráficamente una métrica de tiempo de
respuesta del servidor.
Las divisiones controlan si el gráfico va a mostrar líneas independientes por cada valor de una dimensión, o
si por el contrario va a agregar los valores en una sola línea. Por ejemplo, puede ver una línea
correspondiente a un tiempo de respuesta promedio de todas las instancias de servidor, o ver líneas
independientes para cada servidor.
Vea ejemplos de gráficos que tienen filtrado y divisiones aplicados.
Configuración gráfico avanzada

Se puede personalizar el estilo y el título de un gráfico, así como modificar la configuración de gráfico avanzada.
Cuando haya terminado de personalizarlo, puede anclarlo a un panel para guardar el trabajo. También se pueden
configurar alertas de métricas. Consulte Características avanzadas del Explorador de métricas de Azure para
aprender sobre estas y otras características avanzadas del explorador de métricas de Azure Monitor.
Pasos siguientes
Ahora que ha aprendido a trabajar con métricas en Azure Monitor, aprenda a usar métricas para enviar alertas
proactivas.
Creación, visualización y administración de alertas de métricas mediante Azure Monitor
Tutorial: Recopilación y análisis de registros de
recurso desde un recurso de Azure
Los registros de recurso proporcionan información minuciosa sobre los detalles de funcionamiento de un recurso
de Azure y son útiles para supervisar su estado y disponibilidad. Los recursos de Azure generan registros de
recurso automáticamente, pero debe configurar el lugar donde recopilarlos. Este tutorial le guiará por el proceso
de creación de una configuración de diagnóstico para recopilar registros de recurso de un recurso en la
suscripción de Azure y de análisis con una consulta de registro.
Crear un área de trabajo de Log Analytics en Azure Monitor
Crear una configuración de diagnóstico para recopilar registros de recurso
Crear una consulta de registro simple para analizar registros
Prerrequisitos
Para completar este tutorial, necesitará un recurso de Azure para supervisarlo. Puede usar cualquier recurso de la
suscripción de Azure que admita la configuración de diagnóstico. Para determinar si un recurso es compatible con
la configuración de diagnóstico, vaya a su menú en Azure Portal y busque la opción Configuración de
diagnóstico en la sección Super visión del menú.


Un área de trabajo de Log Analytics en Azure Monitor recopila e indexa los datos de registro de una variedad de
orígenes y permite el análisis avanzado con un lenguaje de consulta eficaz. El área de trabajo Log Analytics debe
existir antes de la configuración de diagnóstico para enviar datos a ella. Puede usar un área de trabajo existente
en la suscripción de Azure o crear una con el procedimiento siguiente.
NOTE
Aunque puede trabajar con datos en el área de trabajo de Log Analytics en el menú de Azure Monitor , las áreas de
trabajo se crean y se administran en el menú Áreas de trabajo de Log Analytics .
1. En Todos los ser vicios , seleccione Áreas de trabajo de Log Analytics .

2. Haga clic en Agregar en la parte superior de la pantalla y proporcione los detalles siguientes para el área
de trabajo:
Área de trabajo de Log Analytics : nombre para la nueva área de trabajo. Este nombre debe ser
único globalmente en todas las suscripciones de Azure Monitor.
Suscripción : donde almacenar el área de trabajo. No es necesario que sea la misma suscripción que la
del recurso bajo supervisión.
Grupo de recursos : seleccione uno existente o haga clic en Crear para crear un grupo de recursos
nuevo. No es necesario que sea el mismo grupo de recursos que el del recurso bajo supervisión.
Ubicación : seleccione una región de Azure o cree una. No es necesario que sea la misma ubicación que
la del recurso bajo supervisión.
Plan de tarifa : Seleccione Pago por uso como plan de tarifa. Puede cambiar el plan de tarifa más
adelante. Haga clic en el vínculo Precios de Log Analytics para más información sobre los distintos
planes de tarifa.
3. Haga clic en Aceptar para crear el área de trabajo.
Creación de una configuración de diagnóstico

La configuración de diagnóstico define dónde se deben enviar los registros de recurso y de un recurso
determinado. Un solo valor de configuración de diagnóstico puede tener varios destinos, pero en este tutorial
solo usaremos un área de trabajo de Log Analytics.
1. En la sección Super visión del menú del recursos, seleccione Configuración de diagnóstico .
2. Debería recibir el mensaje "No se ha definido ninguna configuración de diagnóstico". Haga clic en Agregar
configuración de diagnóstico .
3. Cada configuración de diagnóstico tiene tres partes básicas:
Name : no afecta en nada y debe ser simplemente descriptivo.
Destinos : Uno o más destinos para enviar los registros. Todos los servicios de Azure comparten el
mismo conjunto de tres destinos posibles. Cada configuración de diagnóstico puede definir uno o más
destinos, pero no más de uno de un tipo determinado.
Categorías : categorías de registros que se van a enviar a cada uno de los destinos. Este conjunto de
categorías variará para cada servicio de Azure.
4. Seleccione Enviar a Log Analytics y el área de trabajo que ha creado.
5. Seleccione las categorías que desea recopilar. Consulte la documentación de cada servicio para una
definición de sus categorías disponibles.
6. Haga clic en Guardar para guardar la configuración de diagnóstico.
Uso de una consulta de registro para recuperar registros

Los datos se recuperan de un área de trabajo de Log Analytics mediante una consulta de registro escrita en el
lenguaje de consulta de Kusto (KQL). La información y las soluciones de Azure Monitor proporcionarán consultas
de registro para recuperar datos de un servicio determinado, pero puede trabajar directamente con las consultas
de registro y sus resultados en Azure Portal con Log Analytics.
1. En la sección Super visión del menú de su recurso, seleccione Registros .
2. Log Analytics se abre con una ventana de consulta vacía con el ámbito establecido en el recurso. Las
consultas incluirán solo los registros de ese recurso.
NOTE
Si ha abierto registros desde el menú de Azure Monitor, el ámbito se establecerá como el área de trabajo de Log
Analytics. En este caso, las consultas incluirán todos los registros del área de trabajo.
3. El servicio que se muestra en el ejemplo escribe los registros de recurso en la tabla AzureDiagnostics ,
pero otros servicios pueden escribir en tablas distintas. Consulte Servicios, esquemas y categorías
admitidos en los registros de recursos de Azure para conocer las tablas que usan los distintos servicios de
Azure.
NOTE
Varios servicios escriben registros de recurso en la tabla AzureDiagnostics. Si inicia Log Analytics desde el menú de
Azure Monitor, tendrá que agregar una instrucción where con la columna ResourceProvider para especificar el
servicio concreto. Al iniciar Log Analytics desde el menú de un recurso, el ámbito se establece solo en los registros
de este recurso, por lo que esta columna no es necesaria. Consulte la documentación del servicio para ver consultas
de ejemplo.
4. Escriba una consulta y haga clic en Ejecutar para inspeccionar los resultados.
5. Para un tutorial sobre cómo escribir consultas de registro, consulte Introducción a las consultas de registro
en Azure Monitor.
Pasos siguientes
Ahora que ha aprendido a recopilar registros de recurso en un área de trabajo Log Analytics, complete un tutorial
sobre cómo escribir consultas de registro para analizar estos datos.
Introducción a las consultas de registro en Azure Monitor
Introducción a las consultas de registro en Azure
Monitor
NOTE
Puede trabajar en este ejercicio en su propio entorno si va a recopilar datos de al menos una máquina virtual. Si no es así, use
nuestro entorno de demostración, que incluye gran cantidad de datos de ejemplo. Si ya sabe cómo realizar consultas en KQL,
pero solo necesita crear rápidamente consultas útiles basadas en tipos de recursos, vea el panel de consultas de ejemplo
guardado.
En este tutorial aprenderá a escribir consultas de registro en Azure Monitor. Le mostrará cómo:
Comprender la estructura de las consultas
Ordenar los resultados de la consulta
Filtrar los resultados de la consulta
Especificar un intervalo de tiempo
Seleccionar los campos que incluir en los resultados
Definir y usar campos personalizados
Agregar y agrupar los resultados
Para obtener un tutorial sobre el uso de Log Analytics en Azure Portal, consulte Introducción a Log Analytics de
Azure Monitor.
Para más información sobre las consultas de registro en Azure Monitor, consulte Introducción a las consultas de
registro en Azure Monitor.
Siga con una versión en vídeo de este tutorial:
Escribir una nueva consulta

Las consultas pueden comenzar por un nombre de tabla o el comando search. Debe empezar por un nombre de
tabla, ya que define un ámbito claro para la consulta y mejora el rendimiento de las consultas y la pertinencia de los
resultados.
NOTE
El lenguaje de consulta de Kusto que usa Azure Monitor distingue entre mayúsculas y minúsculas. Las palabras clave del
lenguaje se suelen escribir en minúsculas. Al usar nombres de tablas o columnas en una consulta, asegúrese de usar las
mayúsculas y minúsculas correctas, tal como se muestra en el panel de esquema.
Consultas basadas en tablas

Azure Monitor organiza los datos de registro en tablas, compuestas de varias columnas. Todas las tablas y columnas
se muestran en el panel de esquema en Log Analytics en el portal de Analytics. Identifique una tabla que le interese
y observe algunos datos:
SecurityEvent
| take 10
La consulta anterior devuelve 10 resultados de la tabla SecurityEvent, sin orden específico. Se trata de una forma
muy común para echar un vistazo a una tabla y comprender su estructura y contenido. Vamos a examinar su
estructura:
La consulta comienza por el nombre de la tabla, SecurityEvent; esta parte define el ámbito de la consulta.
El carácter de barra vertical (|) separa los comandos,de manera que la salida del primero sea la entrada del
siguiente. Puede agregar cualquier cantidad de elementos canalizados.
Después de la canalización se encuentra el comando take , que devuelve un número concreto de registros
arbitrarios de la tabla.
En realidad podríamos ejecutar la consulta incluso sin agregar | take 10 , seguiría siendo válida, pero podría
devolver hasta 10 000 resultados.
Las consultas de búsqueda están menos estructuradas y por lo general son más adecuadas para buscar registros
con un valor específico en cualquiera de sus columnas:
search in (SecurityEvent) "Cryptographic"

| take 10
Esta consulta busca en la tabla SecurityEvent los registros que contienen la expresión "Cryptographic". De esos
registros, se devuelven y se muestran 10. Si se omite la parte in (SecurityEvent) y solo se ejecuta
search "Cryptographic" , la búsqueda recorrerá todas las tablas, lo que podría tardar más tiempo y ser menos
eficiente.
WARNING
Las consultas de búsqueda son normalmente más lentas que las consultas basadas en tablas porque tienen que procesar más
datos.
sort y top
Mientras que take resulta útil para obtener algunos registros, los resultados no se seleccionan ni se muestran en un
orden concreto. Para obtener una vista ordenada a partir de la columna preferida, use sor t :
SecurityEvent
| sort by TimeGenerated desc
No obstante, esto podría devolver demasiados resultados y tardar un tiempo. En la consulta anterior se ordena toda
la tabla SecurityEvent a partir de la columna TimeGenerated. En el portal de Analytics se limita la presentación para
mostrar solo 10 000 registros. Es obvio que este enfoque no es el mejor.
La mejor manera de obtener solo los 10 registros más recientes es usar top , que ordena toda la tabla en el servidor
y devuelve los registros principales:
SecurityEvent
| top 10 by TimeGenerated
El criterio de ordenación descendente es el valor predeterminado, por lo que se suele omitir el argumento desc . La
salida tendrá este aspecto:
where: filtrado por una condición

Los filtros, tal como indica su nombre, filtran los datos por una condición específica. Se trata de la manera más
común para limitar los resultados de la consulta a la información pertinente.
Para agregar un filtro a una consulta, use el operador where seguido por una o varias condiciones. Por ejemplo, la
siguiente consulta devuelve solo los registros de SecurityEvent donde Level sea igual a 8:
SecurityEvent
| where Level == 8
Al escribir las condiciones de filtro, puede usar las siguientes expresiones:
EXP RESSIO N DESC RIP C IÓ N E JEM P LO
== Coincidencia con igualdad Level == 8

(distingue mayúsculas y minúsculas)
=~ Coincidencia con igualdad EventSourceName =~ "microsoft-

(no distingue mayúsculas y minúsculas) windows-security-auditing"
!=, <> Coincidencia sin igualdad Level != 4

(ambas expresiones son idénticas)
and, or Necesario entre condiciones Level == 16 or CommandLine != ""
Para filtrar con varias condiciones, puede usar and :
SecurityEvent
| where Level == 8 and EventID == 4672
o canalizar varios elementos where uno tras otro:
SecurityEvent
| where Level == 8
| where EventID == 4672
NOTE
Los valores pueden ser de tipos distintos, por lo que quizá deba convertirlos para realizar la comparación en el tipo correcto.
Por ejemplo, la columna Level de SecurityEvent es de tipo cadena, por lo que debe convertirla a un tipo numérico, como int o
long para usar operadores numéricos: SecurityEvent | where toint(Level) >= 10

Selector de hora
El selector de hora está junto al botón Ejecutar e indica que solo consultamos registros de las últimas 24 horas. Este
es el intervalo de tiempo predeterminado que se aplica a todas las consultas. Para obtener solo los registros de la
última hora, seleccione Last hour (Última hora) y vuelva a ejecutar la consulta.
Filtro de tiempo en las consultas

También puede definir su propio intervalo de tiempo mediante la incorporación de un filtro de tiempo a la consulta.
Lo mejor es colocar el filtro de tiempo inmediatamente después del nombre de la tabla:
SecurityEvent
| where TimeGenerated > ago(30m)
| where toint(Level) >= 10
En el filtro de tiempo anterior, ago(30m) significa "hace 30 minutos", por lo que esta consulta devuelve solo los
registros de los últimos 30 minutos. Otras unidades de tiempo son los días (2 d), los minutos (25 m) y los segundos
(10 s).
project y extend: seleccionar y procesar columnas

Use project para seleccionar columnas concretas que incluir en los resultados:
SecurityEvent
| project TimeGenerated, Computer, Activity
En el ejemplo anterior se genera esta salida:

También puede usar project para cambiar el nombre de las columnas y definir otras nuevas. En el ejemplo
siguiente se utiliza project para hacer lo siguiente:
Seleccionar solo las columnas originales Computer y TimeGenerated.
Cambiar el nombre de la columna Activity a EventDetails.
Crear una nueva columna denominada EventCode. La función substring() se utiliza para obtener solo los
primeros cuatro caracteres del campo Activity.
SecurityEvent
| project Computer, TimeGenerated, EventDetails=Activity, EventCode=substring(Activity, 0, 4)
extend mantiene todas las columnas originales en el conjunto de resultados y define otras adicionales. La consulta
siguiente usa extend para agregar la columna EventCode. Tenga en cuenta que es posible que esta columna no se
muestre al final de los resultados de la tabla, en cuyo caso sería necesario expandir los detalles de un registro para
verlo.
SecurityEvent
| extend EventCode=substring(Activity, 0, 4)
summarize: incorporación de grupos de filas

Use summarize para identificar grupos de registros, según una o varias columnas, y aplicarles agregaciones. El uso
más habitual de summarize es con count, lo que devuelve el número de resultados de cada grupo.
En la consulta siguiente se revisan todos los registros Perf de la última hora, se agrupan por ObjectName y se
cuentan los registros de cada grupo:
Perf
| where TimeGenerated > ago(1h)
| summarize count() by ObjectName
A veces tiene sentido definir los grupos según varias dimensiones. Cada combinación única de estos valores define
un grupo independiente:
Perf
| summarize count() by ObjectName, CounterName
Otro uso común es para realizar cálculos matemáticos o estadísticos en cada grupo. Por ejemplo, a continuación se
calcula el promedio de CounterValue para cada equipo:
Perf
| summarize avg(CounterValue) by Computer
Lamentablemente, los resultados de esta consulta no tienen sentido, ya que hemos mezclado diferentes contadores
de rendimiento. Para que esto tenga más sentido, debemos calcular el promedio por separado para cada
combinación de CounterName y Computer:
Perf
| summarize avg(CounterValue) by Computer, CounterName
Resumen por una columna de tiempo

La agrupación de resultados también puede basarse en una columna de tiempo o con cualquier otro valor continuo.
Sin embargo, simplemente resumir por by TimeGenerated crearía grupos para cada milisegundo del intervalo de
tiempo, ya que son valores únicos.
Para crear grupos basados en valores continuos es mejor dividir el intervalo en unidades manejables mediante bin .
En la siguiente consulta se analizan los registros Perf que miden la memoria libre (Available MBytes) en un equipo
específico. Se calcula el valor promedio de cada período de 1 hora durante los últimos 7 días:
Perf
| where TimeGenerated > ago(7d)
| where Computer == "ContosoAzADDS2"
| where CounterName == "Available MBytes"
| summarize avg(CounterValue) by bin(TimeGenerated, 1h)
Para que la salida sea más clara, elija mostrarla como gráfico de tiempo, que muestre la memoria disponible a lo
largo del tiempo:
Pasos siguientes
Puede encontrar más información sobre el uso de datos de cadena en una consulta de registro en Trabajo con
cadenas en las consultas de registro de Azure Monitor.
Puede encontrar más información sobre la agregación de datos en una consulta de registro en Agregaciones
avanzadas en las consultas de registro de Azure Monitor.
Obtenga información sobre cómo combinar datos de varias tablas en Combinaciones en consultas de registros
de Azure Monitor.
Obtenga la documentación completa sobre el lenguaje de consulta de Kusto en Referencia del lenguaje KQL.
Creación y uso compartido de paneles de datos de
Log Analytics
Los paneles de Log Analytics permiten visualizar todas las consultas de registro guardadas, lo que le proporciona la
posibilidad de buscar, correlacionar y compartir datos operativos de TI en la organización. Este tutorial trata la
creación de una consulta de registro que se usará para admitir un panel compartido al que accederá su equipo de
soporte técnico de operaciones de TI. Aprenderá a:
Crear un panel compartido en Azure Portal.
Visualizar una consulta de registro de rendimiento.
Agregar una consulta de registro a un panel compartido.
Personalizar un icono en un panel compartido.
Para completar el ejemplo en este tutorial, debe disponer de una máquina virtual existente conectada al área de
trabajo de Log Analytics.

Creación de un panel compartido

Seleccione Panel para abrir el panel predeterminado. El panel tendrá un aspecto distinto al ejemplo siguiente.
Aquí puede agrupar los datos operacionales que sean más importantes para la TI en todos los recursos de Azure,
incluidos los datos de telemetría de Azure Log Analytics. Antes de que pasemos a la visualización de una consulta de
registro, creemos primero un panel y compartámoslo. Luego, podemos centrarnos en la consulta de registro de
rendimiento de ejemplo, que se representará como un gráfico de líneas, y lo agregaremos al panel.
NOTE
Los siguientes tipos de gráficos se admiten en los paneles de Azure mediante consultas de registro:
areachart
columnchart
piechart (se representará en el panel como un anillo)
scatterchart
timechart
Para crear un panel, haga clic en el botón Panel nuevo situado junto al nombre del panel actual.
Esta acción crea un panel nuevo, vacío y privado, y activa el modo de personalización, donde puede asignar un
nombre al panel y agregar o reorganizar los iconos. Edite el nombre del panel y especifique Panel de ejemplo para
este tutorial y, después, seleccione Personalización finalizada .
Al crear un panel, será privado de forma predeterminada, lo que significa que usted será la única persona que
puede verlo. Para que puedan verlo otros usuarios, utilice el botón Compar tir que aparece junto al resto de los
comandos del panel.
Se le pedirá que elija una suscripción y un grupo de recursos en el que se vaya a publicar el panel. Para mayor
comodidad, la experiencia de publicación del portal lo guiará por un patrón donde colocará paneles en un grupo de
recursos denominado " paneles ". Compruebe la suscripción seleccionada y, después, haga clic en Publicar . El
acceso a la información mostrada en el panel se controla con el control de acceso basado en rol (Azure RBAC) de
Azure.
Visualización de una consulta de registro

Log Analytics es un portal dedicado que se usa para trabajar con consultas de registro y sus resultados. Las
características incluyen la capacidad para editar una consulta en varias líneas, ejecutar código de forma selectiva,
Intellisense sensible al contexto y análisis inteligente. En este tutorial, usará Log Analytics para crear una vista de
rendimiento en formato gráfico, la guardará para una consulta futura y la anclará al panel compartido creado
anteriormente.
Seleccione Registros en el menú Azure Monitor para abrir Log Analytics. Se inicia con una nueva consulta en
blanco.
Escriba la siguiente consulta para devolver registros de uso del procesador para los equipos de Windows y Linux,
agrupada por Equipo y TimeGenerated, y mostrada en un gráfico visual. Haga clic en Ejecutar para ejecutar la
consulta y ver el gráfico resultante.
Perf
| where CounterName == "% Processor Time" and ObjectName == "Processor" and InstanceName == "_Total"
| summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 1hr), Computer
| render timechart
Para guardar la consulta, seleccione el botón Guardar en la parte superior de la página.

En el panel de control Guardar consulta , escriba un nombre como Máquinas virtuales de Azure: uso del
procesador y una categoría como Paneles y, luego, haga clic en Guardar . De este modo, puede crear una biblioteca
con las consultas comunes que puede usar y modificar. Por último, ánclela al panel compartido que se creó
anteriormente. Para ello, seleccione el botón Anclar al panel en la esquina superior derecha de la página y
seleccione el nombre del panel.
Ahora que tenemos una consulta anclada al panel, podrá observar que tiene un título genérico y un comentario
debajo de él.
Debemos cambiarle el nombre a uno descriptivo que permita que las personas que lo vean lo entiendan fácilmente.
Haga clic en el botón Editar para personalizar el título y el subtítulo del icono y, a continuación, haga clic en
Actualizar . Aparecerá un banner en el que se le preguntará si desea publicar los cambios o rechazarlos. Haga clic en
Guardar una copia .
Pasos siguientes
En este tutorial aprendió a crear un panel en Azure Portal y a agregarle una consulta de registro. Vaya al siguiente
tutorial para conocer las diferentes respuestas que puede implementar según los resultados de consulta de registro.
Respuesta a eventos con las alertas de Log Analytics
Respuesta a eventos con las alertas de Azure
Monitor
Las alertas de Azure Monitor pueden identificar información importante en el repositorio de Log Analytics. Se
crean mediante reglas de alerta que ejecutan automáticamente búsquedas de registro en intervalos regulares y, si
los resultados de la búsqueda de registro coinciden con criterios determinados, se crea un registro de alerta y se
puede configurar para realizar una respuesta automatizada. Este tutorial es la continuación del tutorial Creación y
uso compartido de paneles de datos de Log Analytics.
Crear una regla de alerta
Configurar un grupo de acciones para enviar una notificación por correo electrónico
Para completar el ejemplo en este tutorial, debe disponer de una máquina virtual existente conectada al área de

Creación de alertas
Las alertas se crean mediante reglas de alertas en Azure Monitor y pueden ejecutar automáticamente consultas
guardadas o búsquedas de registros personalizadas a intervalos regulares. Puede crear alertas basadas en métricas
de rendimiento específicas o cuando se creen determinados eventos, haya un evento ausente o se cree una serie
de eventos dentro de una ventana de tiempo determinada. Por ejemplo, se pueden usar alertas para avisarle
cuando el uso medio de la CPU supere un determinado umbral, cuando se detecta una actualización que falta o
cuando se genera un evento al detectar que un servicio de Windows específico o un demonio de Linux no
funcionan. Si los resultados de la búsqueda de registros coinciden con determinados criterios, se crea una alerta.
Luego, la regla puede ejecutar automáticamente una o varias acciones, como notificarle de la alerta o invocar otro
proceso.
En el ejemplo siguiente, se crea una regla de alertas de medidas de métricas basada en la consulta guardada
Máquinas virtuales de Azure: uso de procesador del Tutorial de visualización de datos. Se crea una alerta para cada
máquina virtual que supera el umbral del 90 %.
1. En Azure Portal, haga clic en Todos los ser vicios . En la lista de recursos, escriba Log Analytics . Cuando
comience a escribir, la lista se filtrará en función de la entrada. Seleccione Log Analytics .
2. En el panel izquierdo, seleccione Aler tas y, a continuación, haga clic en Nueva regla de aler tas en la
parte superior de la página para crear una nueva alerta.
3. Como primer paso, en la sección Crear aler ta , seleccione el área de trabajo de Log Analytics como el
recurso, ya que se trata de una señal de alerta basada en el registro. Filtre los resultados seleccionando la
Suscripción específica en la lista desplegable si tiene más de una, la cual contiene la máquina virtual y el
área de trabajo de Log Analytics creados anteriormente. Filtre el Tipo de recurso seleccionando Log
Analytics en la lista desplegable. Por último, seleccione el recurso DefaultL AWorkspace y haga clic en
Listo .
4. En la sección Criterios de aler ta , haga clic en Agregar criterios para seleccionar la consulta guardada y,
a continuación, especifique la lógica que sigue la regla de alertas. En el panel Configurar lógica de señal ,
seleccione Máquinas virtuales de Azure: uso de procesador en la lista. El panel se actualiza para presentar los
valores de configuración de la alerta. En la parte superior, se muestran los resultados de los últimos 30
minutos de la señal seleccionada y la propia consulta de búsqueda.
5. Configure la alerta con la siguiente información:
a. En la lista desplegable Basado en , seleccione Unidades métricas . Una medida de métricas creará una
alerta por cada objeto de la consulta con un valor que supere el umbral especificado.
b. Para Condición , seleccione Mayor que y escriba 90 para Umbral .
c. En la sección Desencadenar alerta según, seleccione Infracciones consecutivas y, en la lista
desplegable, seleccione Mayor que y escriba un valor de 3.
d. En la sección Evaluation based on (Evaluación basada en), modifique el valor de Period (Período) a 30
minutos. La regla se ejecutará cada cinco minutos y devolverá los registros que se crearon dentro de los
últimos 30 minutos desde la hora actual. El hecho de establecer el período de tiempo en una ventana más
amplia justifica la posibilidad de latencia en los datos y garantiza que la consulta devuelve datos para evitar
un falso negativo en aquellos casos en los que la alerta nunca se activa.
6. Haga clic en Listo para finalizar la regla de alertas.
7. Ahora, en el segundo paso, proporcione un nombre para la alerta en el campo Nombre de la regla de
aler tas , como Porcentaje de CPU supera el 90% . Especifique una Descripción con los detalles
específicos de la alerta y seleccione Crítico (Gravedad 0) para el valor Gravedad de las opciones
proporcionadas.
8. Para activar inmediatamente la regla de alertas en la creación, acepte el valor predeterminado de Habilitar
regla tras la creación .
9. En el paso tercero y último, especifique un Grupo de acciones , lo que garantiza que se realizan las mismas
acciones cada vez que se desencadena una alerta y se puede utilizar para cada regla que se define. Configure
un nuevo grupo de acciones con la información siguiente:
a. Seleccione Nuevo grupo de acciones y aparecerá el panel Agregar grupo de acciones .
b. En Nombre del grupo de acciones , especifique un nombre, como Notificar las operaciones de TI -
y un Nombre cor to , como itops-n .
c. Compruebe que los valores predeterminados de Suscripción y Grupo de recursos son correctos. Si no
es así, seleccione los valores correctos en la lista desplegable.
d. En la sección Acciones, especifique un nombre para la acción, como Enviar correo electrónico y en
Tipo de acción , seleccione Correo electrónico/SMS/Push/Voz en la lista desplegable. El panel de
propiedades Correo electrónico/SMS/Push/Voz se abrirá a la derecha para proporcionar información
adicional.
e. En el panel Correo electrónico/SMS/Push/Voz , habilite Correo electrónico y proporcione una
dirección SMTP válida para entregar el mensaje de correo electrónico.
f. Haga clic en Aceptar para guardar los cambios.
10. Seleccione Aceptar para crear el grupo de acciones.
11. Haga clic en Crear regla de aler tas para finalizar la regla de alertas. Se iniciará la ejecución de inmediato.
Visualización de las alertas en Azure Portal
Ahora que ha creado una alerta, puede ver las alertas de Azure en un solo panel y administrar todas las reglas de
alertas de las suscripciones de Azure. Se enumeran todas las reglas de alertas (habilitadas o deshabilitadas), que se
pueden ordenar según los recursos de destino, los grupos de recursos, el nombre de regla o el estado. Se incluye
el resumen agregado de todas las alertas desencadenadas, así como el total de reglas de alertas configuradas y
habilitadas.
Cuando se desencadena la alerta, la tabla refleja la condición y el número de veces que se ha producido dentro del
intervalo de tiempo seleccionado (el valor predeterminado es las últimas seis horas). Debería haber un correo
electrónico correspondiente en la Bandeja de entrada similar al siguiente ejemplo, que muestra la máquina virtual
causante del error y los primeros resultados que coinciden con la consulta de búsqueda, en este caso.
Pasos siguientes
En este tutorial ha aprendido cómo las reglas de alerta pueden identificar un problema y resolverlo de forma
proactiva cuando se ejecuten búsquedas de registro en intervalos programados y coincidan con criterios
determinados.
Siga este vínculo para ver ejemplos de scripts de Log Analytics creados previamente.
Ejemplos de scripts de Log Analytics
Creación de una configuración de escalado
automático de recursos de Azure basado en los datos
de rendimiento o una programación
La configuración de escalado automático le permite agregar o quitar instancias de servicio según condiciones
predefinidas. Esta configuración puede crearse a través del portal. Este método proporciona una interfaz de usuario
basada en explorador para crear y establecer una configuración de escalado automático.
En este tutorial, aprenderá lo siguiente:
Creación de una aplicación web y un plan de App Service
Configuración de reglas de escalado automático para reducción horizontal y escalado horizontal de solicitudes
que recibe una aplicación web
Activación de una acción de escalado horizontal y visualización del número de aumento de instancias
Activación de una acción de reducción horizontal y visualización del número de reducción de instancias
Limpiar los recursos
Iniciar sesión en Azure Portal

Creación de una aplicación web y un plan de App Service

1. Haga clic en la opción Crear un recurso en el panel de navegación izquierdo.
2. Busque y seleccione el elemento Aplicación web y haga clic en Crear .
3. Seleccione un nombre de aplicación, como MyTestScaleWebApp. Cree un nuevo grupo de recursos
*myResourceGroup" y colóquelo en un grupo de recursos de su elección.
En el plazo de unos minutos, los recursos deberían aprovisionarse. Utilice la aplicación web y el plan de App
Service correspondiente a lo largo de este tutorial.
Navegación a la configuración de escalado automático
1. En el panel de navegación izquierdo, seleccione la opción Monitor . Una vez que la página se cargue,
seleccione la pestaña Escalado automático .
2. Aquí se muestra una lista de los recursos de la suscripción que admiten el escalado automático. Busque el
plan de App Service que se creó anteriormente en el tutorial y haga clic en él.
3. En la configuración de escalado automático, haga clic en el botón Habilitar escalado automático .

Los pasos siguientes le ayudarán a rellenar la pantalla de escalado automático para que tenga un aspecto como el
de la imagen siguiente:
Configuración del perfil predeterminado
1. Escriba un Nombre para la configuración de escalado automático.
2. En el perfil predeterminado, asegúrese de que el Modo de escala esté establecido en “Escalar a un número
específico de instancias”.
3. Establezca el recuento de instancias en 1 . Este valor garantiza que, cuando ningún otro perfil esté activo o en
vigor, el perfil predeterminado devuelve el recuento de instancias a 1.
Creación del perfil de periodicidad
1. Haga clic en el vínculo Add a scale condition (Agregar una condición de escalado) bajo el perfil
predeterminado.
2. Edite el nombre de este perfil para que sea “Monday to Friday profile”.
3. Asegúrese de que en Modo de escala se haya seleccionado "Escalado basado en una métrica".
4. Para Límites de instancia , establezca el Mínimo en 1, el Máximo en 2 y el valor Predeterminado en 1.
Esta configuración garantiza que este perfil no escale automáticamente el plan de servicio para que tenga
menos de 1 instancia ni más de 2 instancias. Si el perfil no tiene suficientes datos para tomar una decisión,
utiliza el número predeterminado de instancias (en este caso, 1).
5. Para Programación , seleccione "Repetir en días específicos".
6. Establezca el perfil para repetirse de lunes a viernes, de 09:00 PST a 18:00 PST. Esta configuración garantiza
que este perfil solo esté activo y se aplique de lunes a viernes de 09:00 18:00 h. Durante el resto del tiempo,
el perfil “Predeterminado” será la configuración de escalado automático que utilice el perfil.
Creación de una regla de escalado horizontal

1. En “Monday to Friday profile”.
2. Haga clic en el vínculo Agregar una regla .
3. Establezca el Origen de métrica en “Otro recurso”. Establezca Tipo de recurso en “App Services” y
Recurso en la aplicación web creada anteriormente en este tutorial.
4. Establezca Agregación de tiempo en “Total”, Nombre de métrica en “Solicitudes” y la Estadística de
inter valo de agregación en “Suma”.
5. Establezca Operador en “Mayor que”, Umbral en 10 y Duración en 5 minutos.
6. Seleccione la Operación como "Aumentar el número en", Recuento de instancias en 1 y Tiempo de
finalización en 5 minutos.
7. Haga clic en el botón Agregar .
Esta regla garantiza que, si la aplicación web recibe más de 10 solicitudes en 5 minutos o menos, se agrega una
instancia adicional al plan de App Service para administrar la carga.
Creación de una regla de reducción horizontal
Se recomienda tener siempre una regla de reducción horizontal que acompañe la regla de escalado horizontal. La
existencia de ambas garantiza que los recursos no se aprovisionen en exceso. El aprovisionamiento en exceso
significa tener más instancias en ejecución de las necesarias para administrar la carga actual.
1. En “Monday to Friday profile”.
2. Haga clic en el vínculo Agregar una regla .
3. Establezca el Origen de métrica en “Otro recurso”. Establezca Tipo de recurso en “App Services” y
Recurso en la aplicación web creada anteriormente en este tutorial.
4. Establezca Agregación de tiempo en “Total”, Nombre de métrica en “Solicitudes” y la Estadística de
inter valo de agregación en “Promedio”.
5. Establezca Operador en “Menor que”, Umbral en 5 y Duración en 5 minutos.
6. Establezca la Operación en"Reducir el recuento en", el Recuento de instancias en 1 y el Tiempo de
finalización en 5 minutos.
7. Haga clic en el botón Agregar .
8. Guarde la configuración de escalado automático.

Desencadenamiento de una acción de escalado horizontal
Para desencadenar la condición de escalado horizontal en la configuración de escalado automático que acaba de
crear, la aplicación web debe tener más de 10 solicitudes en menos de 5 minutos.
1. Abra una ventana del explorador y navegue a la aplicación web que creó anteriormente en este tutorial. Para
encontrar la dirección URL de la aplicación web en Azure Portal, vaya al recurso de la aplicación web y haga
clic en el botón Examinar en la pestaña “Información general”.
2. En rápida sucesión, vuelva a cargar la página más de 10 veces.
4. En la lista, seleccione el plan de App Service usado a lo largo de este tutorial.
5. En la configuración de escalado automático, haga clic en la pestaña Historial de ejecución .
6. Verá un gráfico que refleja el recuento de instancias del plan de App Service a lo largo del tiempo.
7. En unos minutos, el recuento de instancias debería aumentar de 1 a 2.
8. Debajo del gráfico, verá las entradas del registro de actividad para cada acción de escalado realizada por
esta configuración de escalado automático.
Desencadenamiento de una acción de reducción horizontal

La condición de reducción horizontal en la configuración de escalado automático se desencadena si hay menos de
5 solicitudes a la aplicación web durante un período de 10 minutos.
1. Asegúrese de que no se envíe ninguna solicitud a la aplicación web.
2. Cargue Azure Portal.
4. En la lista, seleccione el plan de App Service usado a lo largo de este tutorial.
5. En la configuración de escalado automático, haga clic en la pestaña Historial de ejecución .
6. Verá un gráfico que refleja el recuento de instancias del plan de App Service a lo largo del tiempo.
7. En unos minutos, el recuento de instancias debería disminuir de 2 a 1. El proceso tarda al menos 100
minutos.
8. Debajo del gráfico, verá el conjunto correspondiente de entradas del registro de actividad para cada acción
de escalado realizada por esta configuración de escalado automático.
1. Desde el menú de la izquierda en Azure Portal, haga clic en Todos los recursos y luego seleccione la
aplicación web creada en este tutorial.
2. En la página de recursos, haga clic en Eliminar , escriba sí en el cuadro de texto para confirmar la
eliminación y haga clic en Eliminar .
3. A continuación, seleccione el recurso del plan de App Service y haga clic en Eliminar .
4. Escriba sí en el cuadro de texto para confirmar la eliminación y haga clic en Eliminar .
Pasos siguientes
En este tutorial, hizo lo siguiente:
Creó una aplicación web y un plan de App Service.
Configuró reglas de escalado automático para reducción horizontal y escalado horizontal de solicitudes que
recibe una aplicación web.
Activó una acción de escalado horizontal y visualizó el número de aumento de instancias.
Activó una acción de reducción horizontal y visualizó el número reducción de instancias.
Limpió los recursos.
Para obtener más información sobre la configuración del escalado automático, continúe con la información general
del escalado automático.
Archivado de los datos de supervisión
Búsqueda y diagnóstico de excepciones en tiempo de
ejecución con Azure Application Insights
Azure Application Insights recopila datos de telemetría de cualquier aplicación para ayudarle a identificar y
diagnosticar excepciones en tiempo de ejecución. Este tutorial le guiará por este proceso en la aplicación. Aprenderá
a:
Modifica el proyecto para habilitar el seguimiento de excepciones
Identificar excepciones en los distintos componentes de una aplicación
Ver los detalles de una excepción
Descargar una instantánea de la excepción en Visual Studio para su depuración
Analizar los detalles de las solicitudes con errores mediante un lenguaje de consulta
Crear un nuevo elemento de trabajo para corregir el código con errores
Prerequisites
Para completar este tutorial:
Desarrollo de Azure
Descargue e instale Visual Studio Snapshot Debugger.
Habilite Visual Studio Snapshot Debugger.
Implemente una aplicación de .NET en Azure y habilite el SDK de Application Insights.
El tutorial realiza un seguimiento de la identificación de una excepción en la aplicación, así que modifique el
código en los entornos de desarrollo o prueba para generar una excepción.

Análisis de errores
Application Insights recopila los errores de la aplicación y permite ver su frecuencia en las diferentes operaciones,
lo que le ayudarán a centrar sus esfuerzos en los que tienen el mayor impacto. Más adelante puede profundizar en
los detalles de dichos errores para identificar la causa principal.
1. Seleccione Application Insights y, después, la suscripción.
2. Para abrir el panel Errores , seleccione Errores en el menú Investigar o haga clic en el grafo Solicitudes
con errores .
3. El panel Solicitudes con errores muestra el número de solicitudes con errores y el número de usuarios
afectados para cada operación en la aplicación. Si ordenar esta información por usuario, puede identificar los
errores que más afectan a los usuarios. En este ejemplo, GET Employees/Create y GET
Customers/Details son probables candidatos a los que investigar debido al gran número de errores y a la
gran cantidad de usuarios afectados. Al seleccionar cualquier operación, se muestra más información acerca
de la misma en el panel derecho.
4. Reduzca la ventana de tiempo para acercar el periodo en el que la frecuencia de errores muestra un pico.
5. Consulte los ejemplos relacionados haciendo clic en el botón con el número de resultados filtrados. Los
ejemplos "sugeridos" tienen telemetría relacionada de todos los componentes, incluso si se ha aplicado el
muestreo en cualquiera de ellos. Haga clic en un resultado de búsqueda para ver los detalles del error.
6. Los detalles de la solicitud con errores muestran el gráfico de Gantt que indica que había dos errores de
dependencia en esta transacción, que también se atribuyen a más del 50 % de la duración total de la
transacción. Esta experiencia presenta toda la telemetría, a través de los componentes de una aplicación
distribuida que están relacionados con este identificador de operación. Más información acerca de la nueva
experiencia. Puede seleccionar cualquiera de los elementos para ver sus detalles en el lado derecho.
7. Los detalles de las operaciones también muestran la excepción FormatException, que parece que es lo que
ha generado el error. Puede ver que se debe a un código postal no válido. Puede abrir la instantánea de
depuración para ver información de depuración de nivel de código en Visual Studio.
Identificación de código con errores

Snapshot Debugger recopila instantáneas de las excepciones que se producen con más frecuencia en la aplicación
para ayudarle a diagnosticar su causa principal en producción. Puede ver las instantáneas de depuración en el
portal para examinar la pila de llamadas e inspeccionar las variables en cada marco de pila de llamadas.
Posteriormente, puede depurar el código fuente descargando la instantánea y abriéndola en Visual Studio 2019
Enterprise.
1. En las propiedades de la excepción, haga clic en Abrir instantánea de depuración .
2. Se abre el panel Depurar instantánea con la pila de llamadas de la solicitud. Haga clic en cualquiera de los
métodos para ver los valores de todas las variables locales en el momento de la solicitud. Si empezamos por
el primero de los métodos de este ejemplo, podemos ver variables locales que no tienen ningún valor.
3. La primera llamada que tiene valores válidos es ValidZipCode y podemos ver que se especificó un código
postal con letras que no se puede convertir en un número entero. Parece que este es el error que hay en el
código y que debe corregirse.
4. Puede descargar esta instantánea en Visual Studio, donde se puede buscar el código que se debe corregir.
Para ello, haga clic en Descargar instantánea .
5. La instantánea se carga en Visual Studio.
6. A partir de ese momento se puede ejecutar una sesión de depuración en Visual Studio Enterprise que
identifique rápidamente la línea de código que provocó la excepción.
Uso de datos de análisis
Todos los datos que recopila Application Insights se almacenan en Azure Log Analytics, lo que proporciona un
lenguaje de consulta completo que permite analizar los datos de varias formas. Dichos datos se pueden usar para
analizar las solicitudes que generaron la excepción que investigamos.
1. Haga clic en la información de CodeLens que encontrará encima del código para ver los datos de telemetría
que proporciona Application Insights.
2. Haga clic en Analizar impacto para abrir Application Insights Analytics. Contiene varias consultas que
proporcionan detalles acerca de las solicitudes con errores, como los usuarios afectados, los exploradores
usados y las regiones.
Incorporación de elemento de trabajo
Si conecta Application Insights a un sistema de seguimiento, como GitHub y Azure DevOps, puede crear un
elemento de trabajo directamente desde Application Insights.
1. Vuelva al panel Exception Proper ties (Propiedades de la excepción) de Application Insights.
2. Haga clic en Nuevo elemento de trabajo .
3. Se abre el panel Nuevo elemento de trabajo con detalles acerca la excepción ya rellenados. Además,
antes de guardarlo puede agregar toda la información adicional que desee.
Pasos siguientes
Ahora que ha aprendido a identificar las excepciones en tiempo de ejecución, pase al siguiente tutorial, donde
aprenderá a identificar y diagnosticar problemas de rendimiento.
Identificar problemas de rendimiento
Búsqueda y diagnóstico de problemas de
rendimiento con Azure Application Insights
Azure Application Insights recopila datos de telemetría de cualquier aplicación para ayudarle a analizar su
funcionamiento y rendimiento. Esta información se puede usar para identificar los problemas que se pueden
producir o las mejoras en la aplicación que más afectarían a los usuarios. En este tutorial se recorre todo el proceso
de análisis del rendimiento tanto de los componentes de servidor de una aplicación como de la perspectiva del
cliente. Aprenderá a:
Identificar el rendimiento de las operaciones del servidor
Analizar las operaciones del servidor para determinar la causa principal de un bajo rendimiento
Identificar las operaciones del cliente más lentas
Analizar los detalles de las vistas de página mediante el lenguaje de consulta
Requisitos previos
Desarrollo de Azure
Habilite el generador de perfiles de Application Insights de la aplicación.

Identificación de operaciones lentas del servidor

Application Insights recopila datos de rendimiento de las distintas operaciones en la aplicación. Mediante la
identificación de las operaciones que más tardan en completarse, es posible diagnosticar problemas potenciales o
enfocar mejor el desarrollo en curso para mejorar el rendimiento general de la aplicación.
1. Seleccione Application Insights y, a continuación, seleccione la suscripción.
2. Para abrir el panel Rendimiento , seleccione Rendimiento en el menú Investigar o haga clic en el grafo
Tiempo de respuesta del ser vidor .
3. El panel Rendimiento muestra el número de operaciones de la aplicación y la duración media de cada una
de ellas. Esta información se puede usar para identificar las operaciones que más afectan a los usuarios. En
este ejemplo, GET Customers/Details y GET Home/Index son probables candidatos a los que investigar,
ya que su duración es relativamente alta y se las llama en numerosas ocasiones. Otras operaciones pueden
tener una duración superior, pero rara vez se les llama, por lo que el efecto de su mejora sería mínimo.
4. Actualmente, el grafo muestra la duración media de las operaciones a lo largo del tiempo. Puede cambiar al
percentil 95 para detectar los problemas de rendimiento. Para agregar las operaciones que le interesen,
ánclelas al grafo. Esto muestra que hay algunos valores máximos que merece la pena investigar. Y para
aislarlos aún más, puede reducir la ventana de tiempo del grafo.
5. El panel de rendimiento de la derecha muestra la distribución de duraciones de distintas solicitudes para la
operación seleccionada. Reduzca la ventana para empezar alrededor del percentil 95. La tarjeta de
información "3 dependencias principales" puede indicarle de un vistazo que las dependencias externas
probablemente estén coadyuvando a que se produzcan las transacciones lentas. Haga clic en el botón con el
número de ejemplos para ver una lista de los ejemplos. A continuación, puede seleccionar cualquier
ejemplo para ver los detalles de transacción.
6. Puede ver a simple vista que la llamada a la tabla de Azure Fabrikamaccount es la que más contribuye a la
duración total de la transacción. También puede ver que una excepción ha provocado un error. Puede hacer
clic en cualquier elemento de la lista para ver sus detalles en el lado derecho. Más información acerca de la
experiencia de diagnósticos de transacción
7. Profiler ayuda a profundizar en los diagnósticos de nivel de código al mostrar el código real que se ejecutó
para la operación y el tiempo necesario para cada paso. Es posible que no se pueda realizar un seguimiento
de algunas operaciones, ya que el generador de perfiles se ejecuta periódicamente. Con el tiempo, más
operaciones deben tener seguimientos. Para iniciar el generador de perfiles de la operación, haga clic en
Seguimientos de Profiler .
8. El seguimiento muestra los eventos individuales de cada operación, por lo que puede diagnosticar la causa
principal por la duración de la operación global. Haga clic en uno de los ejemplos superiores, que son los
que tienen una duración mayor.
9. Haga clic en Ruta de acceso activa para resaltar la ruta de acceso específica de los eventos que más
contribuyen a la duración total de la operación. En este ejemplo, puede ver que la llamada más lenta procede
del método FabrikamFiberAzureStorage.GetStorageTableData. La parte que tiene la mayor parte del tiempo
es el método CloudTable.CreateIfNotExist. Si esta línea de código se ejecuta cada vez que se llama a la
función, se consumirán recursos de CPU y llamadas de red innecesarios. La mejor manera de corregir el
código es poner esta línea en algún método de inicio que solo se ejecute una vez.
10. La sugerencia que se muestra en Consejo de rendimiento , en la parte superior de la pantalla, es

compatible con la evaluación de que la duración excesiva se debe a la espera. Haga clic en el vínculo de
espera para obtener documentación acerca de cómo interpretar los diferentes tipos de eventos.
11. Para un análisis más profundo, haga clic en Descargar seguimiento para descargar el seguimiento. Puede
ver estos datos mediante PerfView.
Uso de datos de registros para el servidor

Los registros proporcionan un lenguaje de consulta completo que le permite analizar todos los datos recopilados
por Application Insights. Con ello se puede realizar un análisis profundo de los datos de solicitud y rendimiento.
1. Vuelva al panel de detalles de la operación y haga clic en el Ver en registros (Analytics)
2. Los registros se abren con una consulta en cada una de las vistas del panel. Dichas consultas se pueden
ejecutar tal cual, o bien se pueden modificar para ajustarlas a los requisitos. La primera consulta muestra la
duración de esta operación a lo largo del tiempo.
Identificación de operaciones lentas del cliente

Además de identificar los procesos del servidor que se deben optimizar, Application Insights puede analizar la
perspectiva de los exploradores cliente. Esto puede ayudarle a identificar posibles mejoras en los componentes de
cliente, e incluso identificar problemas con distintos exploradores o ubicaciones diferentes.
1. Seleccione Explorador en Investigar y, después, haga clic en Rendimiento del explorador o seleccione
Rendimiento en Investigar y cambie a la pestaña Explorador ; para ello, haga clic en el botón de
alternancia servidor/explorador situado en la parte superior derecha para abrir el resumen del rendimiento
del explorador. Esto proporciona un resumen visual de los distintos datos de telemetría de la aplicación
desde la perspectiva del explorador.
2. Seleccione uno de los nombres de la operación y, después, haga clic en el botón de ejemplos azul en la
parte inferior derecha y seleccione una operación. Se mostrarán los detalles de la transacción completa y, en
el lado derecho, podrá ver las propiedades de la vista de página . Esto te permite ver los detalles del
cliente que solicita la página incluido, lo que incluye el tipo de explorador y su ubicación. Esta información
puede ayudarle a determinar si ciertos tipos de clientes tienen problemas de rendimiento.
Uso de datos de registros para el cliente

Al igual que los datos recopilados relativos al rendimiento del servidor, Application Insights hace que todos los
datos de cliente estén disponibles para un análisis profundo mediante Registros.
1. Vuelva al resumen del explorador y haga clic en el icono Ver en Registros (Analytics)
2. Los registros se abren con una consulta en cada una de las vistas del panel. La primera consulta muestra la
duración de distintas vistas de la página a lo largo del tiempo.
3. Smart Diagnostics es una característica de Registros que identifica patrones únicos en los datos. Al hacer
clic en el punto de Smart Diagnostics en el gráfico de líneas, la misma consulta se ejecuta sin los registros
que causaron las anomalías. Los detalles de dichos registros se muestran en la sección de comentarios de
consulta para que pueda identificar las propiedades de las vistas de página que provocan que la duración
sea excesiva.
Pasos siguientes
Ahora que ha aprendido a identificar las excepciones en tiempo de ejecución, pase al siguiente tutorial, donde
aprenderá a crear alertas en respuesta a errores.
Alerta por el estado de una aplicación
Supervise el estado de la aplicación y envíe alertas
con Azure Application Insights.
Azure Application Insights le permite supervisar su aplicación y le envía alertas cuando no está disponible,
experimenta errores o sufre problemas de rendimiento. En este tutorial recorrerá el proceso de creación de pruebas
para comprobar de forma continua la disponibilidad de una aplicación.
Aprenderá a:
Crear una prueba de disponibilidad para comprobar continuamente la respuesta de la aplicación
Enviar un correo electrónico a los administradores cuando se produzca un problema
Prerequisites
Cree un recurso de Application Insights.

Creación de una prueba de disponibilidad

Las pruebas de disponibilidad en Application Insights le permiten probar automáticamente la aplicación desde
diferentes ubicaciones de todo el mundo. En este tutorial, realizará una prueba de una dirección URL para
asegurarse de que la aplicación web está disponible. También puede crear un tutorial completo para probar su
funcionamiento detallado.
2. Seleccione Disponibilidad en el menú Investigar y, a continuación, haga clic en Crear prueba .
3. Escriba un nombre para la prueba y deje las demás opciones en sus valores predeterminados. Esta selección
desencadenará solicitudes para la dirección URL de aplicación cada 5 minutos desde cinco ubicaciones
geográficas diferentes.
4. Seleccione Aler tas para abrir la lista desplegable Aler tas , donde puede definir los detalles relativos a
responder si se produce un error en la prueba. Elija Prácticamente en tiempo real y establezca el estado
en Habilitado.
Escriba una dirección de correo electrónico a la que enviar los mensajes cuando se cumplan los criterios de
alerta. También puede escribir la dirección de un webhook al que llamar cuando se cumplan los criterios de
alerta.
5. Vuelva al panel de prueba, seleccione el botón de puntos suspensivos y edite la alerta para especificar la
configuración de la alerta prácticamente en tiempo real.
6. Seleccione que el valor de ubicaciones con error sea mayor o igual a 3. Cree un grupo de acciones para
configurar quiénes reciben notificaciones al superarse el umbral de alerta.
7. Una vez configurada la alerta, haga clic en el nombre de la prueba para ver los detalles de cada ubicación.
Las pruebas pueden verse en forma tanto de gráfico de líneas como de gráfico de dispersión y de gráfico
para visualizar los aciertos/errores de un intervalo de tiempo determinado.
8. Puede profundizar en los detalles de cualquier prueba; para ello, haga clic en su punto en el gráfico de
dispersión. Esto iniciará la vista de detalles de una transacción completa. En el ejemplo siguiente se
muestran los detalles de una solicitud con error.
Pasos siguientes
Ahora que ha aprendido cómo alertar sobre problemas, continúe con el siguiente tutorial para aprender a analizar
el modo en que los usuarios interactúan con la aplicación.
Entender a los usuarios
Use Azure Application Insights para entender la
forma en que los clientes utilizan su aplicación
Azure Application Insights recopila información de uso que le ayuda a entender la forma en que los usuarios
interactúan con su aplicación. Este tutorial le guía a través de los diferentes recursos disponibles para analizar esta
información. Aprenderá a:
Analizar los detalles de los usuarios que accedan a su aplicación
Usar información de la sesión para analizar la forma en que los clientes usan su aplicación
Definir embudos que le permitan comparar la actividad de usuario deseada con la actividad de usuario real
Crear un libro para consolidar visualizaciones y consultas en un solo documento
Agrupar usuarios similares para analizarlos juntos conjuntamente
Saber qué usuarios vuelven a su aplicación
Inspeccionar la forma en que los usuarios navegan por la aplicación
Prerequisites
Desarrollo de Azure
Descargue e instale Visual Studio Snapshot Debugger.
Envíe telemetría desde su aplicación para agregar eventos personalizados o vistas de página
Enviar el contexto del usuario para realizar un seguimiento de lo que un usuario hace con el tiempo y utilizar
plenamente las características de uso.

Obtención de información acerca de los usuarios

El panel Usuarios le permite conocer detalles importantes acerca de los usuarios de varias formas. Este panel se
puede utilizar para saber desde dónde se conectan los usuarios, conocer detalles de sus clientes y las áreas de la
aplicación a las que acceden.
2. Seleccione Usuarios en el menú.
3. La vista predeterminada muestra el número de usuarios únicos que se han conectado a la aplicación en las
últimas 24 horas. Puede cambiar la ventana de tiempo y establezca otros criterios para filtrar esta
información.
4. Haga clic en la lista desplegable Durante y cambie la ventana de tiempo a 7 días. Así aumentan los datos
que se incluyen en los distintos gráficos del panel.
5. Haga clic en la lista desplegable Dividido por para agregar al grafo un desglose por una propiedad del
usuario. Seleccione País o región . El grafo incluye los mismos datos, pero permite ver un desglose del
número de usuarios de cada país o región.
6. Coloque el cursor sobre las distintas barras del gráfico y tenga en cuenta que el recuento de cada país o
región refleja solo la ventana de tiempo representada por dicha barra.
7. Eche un vistazo a la columna Insights a la derecha, en la que se realiza el análisis de los datos de usuario.
Proporciona información como el número de sesiones únicas a lo largo del período de tiempo, y registros
con propiedades comunes significativas de los datos del usuario
Análisis de sesiones del usuario
El panel Sesiones es similar al panel Usuarios . Mientras que Usuarios le ayuda a conocer los detalles acerca de
los usuarios que acceden a su aplicación, Sesiones le ayuda a saber la forma en que dichos usuarios han utilizado
su aplicación.
1. Seleccione Sesiones en el menú.
2. Eche un vistazo al grafo y tenga en cuenta que cuenta con las mismas opciones para filtrar y desglosar los
datos que en el panel Usuarios .
3. El panel Ejemplo de estas sesiones de la derecha enumera las sesiones que incluyen un gran número de
eventos. Son sesiones cuyo análisis es interesante.
4. Haga clic en una de las sesiones para ver su escala de tiempo , que muestra todas las acciones de las
sesiones. Esto puede ayudarle a identificar información como las sesiones con un gran número de
excepciones.
Agrupar usuarios similares

Una cohor te es un conjunto de usuarios agrupados por tener características similares. Las cohortes se pueden
usar para filtrar datos de otros paneles, lo que le permite analizar grupos de usuarios concretos. Por ejemplo, puede
desear analizar solo aquellos usuarios que han realizado una compra.
1. Seleccione Cohor tes en el menú.
2. Haga clic en Nuevo para crear una cohorte nueva.
3. Seleccione la lista desplegable Que usaron y seleccione una acción. Solo se incluirán los usuarios que
realizaron esta acción dentro de la ventana de tiempo del informe.
4. Seleccione Usuarios en el menú.

5. En la lista desplegable Mostrar , seleccione la cohorte que acaba de crear. Los datos del gráfico se limitan a
dichos usuarios.
Comparación de la actividad deseada con la realidad

Mientras que los paneles anteriores se centran en lo que han hecho los usuarios de la aplicación, Embudos se
centra en lo que desea que hagan los usuarios. Un embudo representa un conjunto de pasos de una aplicación y el
porcentaje de usuarios que se mueven entre dichos pasos. Por ejemplo, puede crear un embudo que mida el
porcentaje de usuarios que se conectan a una aplicación que buscan un producto. A continuación, puede ver el
porcentaje de usuarios que agregan dicho producto a un carro de la compra y, después, el porcentaje de ellos que
completan una compra.
1. Seleccione Embudos en el menú y haga clic en Nuevo .
2. Escriba un nombre de embudo .
3. Cree un embudo con un mínimo de dos pasos y seleccione una acción para cada paso. La lista de acciones se
crea a partir de los datos de uso recopilados por Application Insights.
4. Haga clic en Guardar para guardar el embudo y, después, vea sus resultados. La ventana a la derecha del
embudo muestra los eventos más comunes antes de la primera actividad y después de la última actividad
para ayudarle a conocer las tendencias del usuario alrededor de la secuencia determinada.
Información acerca de los clientes que vuelven
Retención le ayuda a saber qué usuarios vuelven a una aplicación.
1. Seleccione Retención en el menú.
2. De forma predeterminada, la información analizada incluye aquellos usuarios que realizaron alguna acción
y volvieron para llevar a cabo alguna acción. Este filtro se puede cambiar para que incluya a cualquiera, por
ejemplo, solo aquellos usuarios que hayan vuelto después de completar una compra.
3. Los usuarios que vuelven que coinciden con los criterios se muestran tanto en forma de gráfico como de
tabla en distintas duraciones. El patrón más frecuente es una caída gradual en la vuelta de los usuarios con el
paso del tiempo. Una caída repentina de un período de tiempo al siguiente puede provocar un problema.
Análisis de la navegación del usuario
Un flujo de usuarios visualiza la forma en que los usuarios navegan entre las páginas y características de la
aplicación. Esto le ayuda a responder a preguntas como a qué lugar se suelen mover los usuarios desde una página
concreta, cómo salen habitualmente de su aplicación y si hay acciones que se repitan de manera regular.
1. Seleccione Flujos de usuarios en el menú.
2. Haga clic en Nuevo para crear un nuevo flujo de usuario y, a continuación, haga clic en Editar para editar
sus detalles.
3. Aumente el valor de Inter valo de tiempo a 7 días y, luego, seleccione un evento inicial. El flujo hará un
seguimiento de las sesiones de usuario que empiezan por ese evento.
4. Se muestra el flujo de usuario y puede ver las rutas de acceso de los diferentes usuarios y el número de
sesiones. Las líneas azules indican una acción que el usuario ha realizado después de la acción actual. Una
línea roja indica el final de la sesión del usuario.
5. Para quitar un evento del flujo, haga clic en la x de la esquina de la acción y, después, en Crear gráfico . El
grafo se vuelve a dibujar sin ninguna de las instancias de dicho evento. Haga clic en Editar para ver que el
evento se ha agregado a Eventos excluidos .
Consolidación de datos de uso

Los libros combinan las visualizaciones de datos, las consultas de Analytics y texto en documentos interactivos. Se
pueden usar para agrupar la información de uso común, consolidar la información de un incidente determinado o
informar al equipo sobre el uso de la aplicación.
1. Seleccione Libros en el menú.
2. Haga clic en Nuevo para crear un libro nuevo.
3. Ya se proporciona una consulta que incluye todos los datos de uso en el último día que se muestra como un
gráfico de barras. Puede usar esta consulta, editarla manualmente o hacer clic en Consultas de ejemplo
para seleccionar otras consultas útiles.
4. Haga clic en Edición finalizada .
5. Haga clic en Editar en el panel superior para editar el texto de la parte superior del libro. Para darle formato
se usa Markdown.
6. Haga clic en Agregar usuarios para agregar un grafo con información del usuario. Si lo desea, edite los
detalles del grafo y, después, haga clic en Edición finalizada para guardarlo.
Pasos siguientes
Ahora que ha aprendido a analizar a los usuarios, pase al siguiente tutorial para aprender a crear paneles
personalizados que combinan esta información con otros datos útiles de la aplicación.
Creación de paneles personalizados
Creación de paneles de indicadores clave de
rendimiento (KPI) personalizados con Azure
Puede crear varios paneles en Azure Portal de manera que cada uno incluya iconos en los que se visualicen datos
procedentes de varios recursos de Azure en diferentes suscripciones y grupos de recursos. Puede anclar distintos
gráficos y vistas de visión de Azure Application Insights para crear paneles personalizados que le proporcionen una
descripción completa del estado y el rendimiento de la aplicación. Este tutorial le guía a través de la creación de un
panel personalizado que incluye varios tipos de datos y visualizaciones de Azure Application Insights.
Aprenderá a:
Crear un panel personalizado en Azure
Agregar un icono desde la Galería de iconos
Agregar métricas estándar de Application Insights al panel
Agregar un gráfico de métricas personalizado de Application Insights al panel
Agregar los resultados de una consulta de Registros (Analytics) al panel
Prerequisites
NOTE
Los permisos necesarios para trabajar con paneles se describen en el artículo Descripción del control de acceso para los
paneles.

Creación de un nuevo panel

WARNING
Si mueve el recurso de Application Insights a un grupo de recursos o una suscripción diferentes, tendrá que actualizar
manualmente el panel; para ello, deberá quitar los iconos antiguos y anclar otros nuevos del mismo recurso de Application
Insights en la nueva ubicación.
Un solo panel puede contener recursos de varias aplicaciones, grupos de recursos y suscripciones. Comience el
tutorial creando un nuevo panel para la aplicación.
1. En el panel, seleccione Nuevo panel .
2. Escriba un nombre para el panel.
3. Eche un vistazo a la Galería de iconos para ver la variedad de iconos que se pueden agregar al panel.
Además de agregar iconos de la galería, puede anclar gráficos y otras vistas directamente desde Application
Insights al panel.
4. Busque el icono Markdown y arrástrelo hasta el panel. Este icono le permite agregar texto en formato
Markdown, que es idóneo para agregar texto descriptivo al panel.
5. Agregue texto a las propiedades del icono y cambie su tamaño en el lienzo del panel.
6. Haga clic en Personalización finalizada en la parte superior de la pantalla para salir del modo de
personalización de iconos.
Adición de información general de estado

Un panel con texto estático no resulta muy interesante; así pues, agregue ahora un icono de Application Insights
para mostrar información acerca de la aplicación. Puede agregar iconos de Application Insights desde la Galería de
iconos, o puede anclarlos directamente desde las pantallas de Application Insights. Esto le permite configurar
gráficos y vistas con las que ya está familiarizado antes de anclarlos al panel. Empiece por agregar la información
general de estado estándar para la aplicación. Esto no requiere configuración y permite una personalización mínima
en el panel.
1. Seleccione el recurso de Application Insights en la pantalla de inicio.
2. En el panel Información general , haga clic en el icono de la chincheta para agregar el icono al último
panel que ha visto.
3. En la esquina superior derecha aparecerá una notificación que indica que el icono estaba anclado al panel.
Haga clic en Anclada al panel en la notificación para volver al panel o use el panel.
4. El icono ya se ha agregado al panel. Seleccione Editar para cambiar el posicionamiento del icono. Haga clic y
arrástrelo hasta su posición y haga clic en Personalización finalizada . Ahora, el panel tiene un icono con
información útil.
Adición del gráfico de métricas personalizado

El panel Métricas panel le permite representar una métrica recopilada por Application Insights a lo largo del
tiempo con filtros opcionales y agrupación. Al igual que todo lo demás en Application Insights, puede agregar este
gráfico al panel. Para ello se requiere antes un poco de personalización.
2. Seleccione Métricas .
3. Ya se ha creado un gráfico vacío, y se le pedirá que agregue una métrica. Agregue una métrica al gráfico y,
opcionalmente, agregue un filtro y una agrupación. En el ejemplo siguiente se muestra el número de
solicitudes de servidor agrupadas según se hayan completado correctamente o no. De este modo se obtiene
una vista de ejecución de las solicitudes correctas e incorrectas.
4. Seleccione Anclar al panel a la derecha. De este modo, se agrega la vista al último panel con el que estaba
trabajando.
5. En la esquina superior derecha aparecerá una notificación que indica que el icono estaba anclado al panel.
Haga clic en Anclada al panel en la notificación para volver al panel o use el panel del panel.
6. El icono ya se ha agregado al panel. Seleccione Editar para cambiar el posicionamiento del icono. Haga clic y
arrástrelo hasta su posición y haga clic en Personalización finalizada .
Adición de consultas de Registros (Analytics)

Registros (Analytics) de Azure Application Insights proporciona un lenguaje de consulta completo que le permite
analizar todos los datos recopilados por Application Insights. Al igual que los gráficos y otras vistas, puede agregar
el resultado de una consulta de registros al panel.
Dado que Logs (Analytics) de Azure Applications Insights es un servicio independiente, debe compartir el panel
para que incluya una consulta de registros. Al compartir un panel de Azure, se publica como un recurso de Azure
que puede poner a disposición de otros usuarios y recursos.
1. En la parte superior de la pantalla del panel, haga clic en Compar tir .
2. Mantenga el mismo Nombre del panel y seleccione el Nombre de la suscripción para compartir el
panel. Haga clic en Publicar . El panel ahora está disponible para otros servicios y suscripciones. Si lo desea,
puede definir los usuarios específicos que deben tener acceso al panel.
4. Haga clic en Registros (Analytics) en la parte izquierda debajo de Supervisión para abrir el portal de
Registros (Analytics).
5. Escriba la siguiente consulta, que devuelve las 10 páginas más solicitadas y su número de solicitudes:
requests
| summarize count() by name
| sort by count_ desc
| take 10
6. Haga clic en Ejecutar para validar los resultados de la consulta.

7. Hacer clic en el icono de chincheta y seleccione el nombre del panel. La razón por la que esta opción le
solicita que seleccione un panel, a diferencia de los pasos anteriores en los que se utilizaba el último panel, es
que la consola de Registros (Analytics) es un servicio independiente y debe seleccionar entre todos los
paneles compartidos disponibles.
8. Antes de volver al panel, agregue otra consulta, pero esta vez represéntela como un gráfico para ver las
distintas maneras de visualizar una consulta de registros en un panel. Comience con la siguiente consulta,
que resume las 10 operaciones principales con la mayoría de las excepciones.
exceptions
| summarize count() by operation_Name
| sort by count_ desc
| take 10
9. Seleccione Gráfico y, a continuación, cambie a Anillo para visualizar el resultado.

10. Hacer clic en el icono de chincheta en la parte superior derecha para anclar el gráfico al panel y, esta vez,
seleccione el vínculo para volver al panel.
11. Los resultados de las consultas se agregan ahora al panel en el formato que seleccionó. Haga clic todos ellos
y arrástrelos hasta su posición, y haga clic en Personalización finalizada .
12. Seleccione el icono de lápiz en cada título para darles un título descriptivo.
13. Seleccione Compar tir para volver a publicar los cambios en el panel, que ahora incluye una serie de
gráficos y visualizaciones de Application Insights.
Pasos siguientes
Ahora que ha aprendido a crear paneles personalizados, eche un vistazo al resto de la documentación de
Application Insights, que incluye un caso práctico.
Diagnósticos detallados
Ejemplos de plantillas de Resource Manager para
Azure Monitor
Azure Monitor se puede implementar y configurar a gran escala mediante una plantilla de Azure Resource
Manager. Los artículos siguientes ofrecen plantillas de ejemplo para diferentes características de
Azure Monitor. Estos ejemplos se pueden modificar con arreglo a sus requisitos y se pueden aplicar
utilizando cualquier método estándar para implementar plantillas de Resource Manager.
Implementación de plantillas de ejemplo

A continuación, se incluyen los pasos básicos para utilizar las plantillas de ejemplo:
1. Copie la plantilla y guárdela como un archivo JSON.
2. Modifique los parámetros de su entorno y guárdelos como un archivo JSON.
3. Implemente la plantilla mediante cualquier método de implementación de plantillas de
Resource Manager.
Por ejemplo, use los siguientes comandos para implementar el archivo de plantilla y parámetros en un
grupo de recursos mediante PowerShell o la CLI de Azure.
Connect-AzAccount
Select-AzSubscription -SubscriptionName my-subscription
New-AzResourceGroupDeployment -Name AzureMonitorDeployment -ResourceGroupName my-resource-group -
TemplateFile azure-monitor-deploy.json -TemplateParameterFile azure-monitor-deploy.parameters.json
az login
az deployment group create \
--name AzureMonitorDeployment \
--resource-group ResourceGroupofTargetResource \
--template-file azure-monitor-deploy.json \
--parameters azure-monitor-deploy.parameters.json
Lista de plantillas de ejemplo

Agentes: implemente y configure la extensión de diagnóstico y el agente de Log Analytics.
Alertas
Reglas de alertas de registro: alertas de las consultas de registros y del registro de actividad de
Azure.
Reglas de alertas de métricas: alertas de métricas que usan diferentes tipos de lógica.
Configuración de diagnóstico: cree una configuración de diagnóstico para reenviar los registros y las
métricas desde diferentes tipos de recursos.
Consultas de registros: cree consultas de registros guardadas, en un área de trabajo de Log Analytics.
Área de trabajo de Log Analytics: cree el área de trabajo Log Analytics y configure la recopilación de
diferentes orígenes de datos a partir del agente de Log Analytics.
Libros: cree libros.
Azure Monitor para contenedores: incorpore clústeres a Azure Monitor para contenedores.
Azure Monitor para VM: incorpore máquinas virtuales a Azure Monitor para VM.
Pasos siguientes
Obtenga más información sobre las plantillas de Resource Manager.
Ejemplos de plantillas de Azure Resource Manager
para agentes en Azure Monitor
Este artículo incluye plantillas de Azure Resource Manager de ejemplo para implementar y configurar la extensión
de diagnóstico y el agente de Log Analytics para máquinas virtuales en Azure Monitor. Cada ejemplo incluye un
archivo de plantilla y un archivo de parámetros con valores de ejemplo para la plantilla.
NOTE
Consulte los ejemplos de Resource Manager para Azure Monitor para obtener una lista de ejemplos disponibles e
instrucciones sobre cómo implementarlos en su suscripción de Azure.
Agente de Log Analytics para Windows

En el ejemplo siguiente, se instala el agente de Log Analytics en una máquina virtual de Microsoft Azure. Para ello,
se habilita la extensión de máquina virtual de Log Analytics para Windows.
Archivo de plantilla
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "Name of the virtual machine."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location of the virtual machine"
}
},
"workspaceId": {
"type": "string",
"metadata": {
"description": "Id of the workspace."
}
},
"workspaceKey": {
"type": "string",
"metadata": {
"description": "Primary or secondary workspace key."
}
}
},
"resources": [
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[parameters('vmName')]",
"resources": [
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'), '/Microsoft.Insights.LogAnalyticsAgent')]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"workspaceId": "[parameters('workspaceId')]"
},
"protectedSettings": {
"workspaceKey": "[parameters('workspaceKey')]"
}
}
}
]
}
]
}
Archivo de parámetros
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"parameters": {
"vmName": {
"value": "my-windows-vm"
},
"location": {
"value": "westus"
},
"workspaceId": {
"value": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
},
"workspaceKey": {
"value": "Tse-gj9CemT6A80urYa2hwtjvA5axv1xobXgKR17kbVdtacU6cEf+SNo2TdHGVKTsZHZd1W9QKRXfh+$fVY9dA=="
}
}
}
Agente de Log Analytics para Linux

En el ejemplo siguiente, se instala el agente de Log Analytics en una máquina virtual de Linux en Azure. Para ello,
se habilita la extensión de máquina virtual de Log Analytics para Windows.
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
"description": "Location of the virtual machine"
}
},
"workspaceId": {
"type": "string",
"metadata": {
"description": "Id of the workspace."
}
},
"workspaceKey": {
"type": "string",
"metadata": {
"description": "Primary or secondary workspace key."
}
}
},
"resources": [
{
"apiVersion": "2018-10-01",
"resources": [
{
"name": "[concat(parameters('vmName'), '/Microsoft.Insights.LogAnalyticsAgent')]",
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "OmsAgentForLinux",
"settings": {
"workspaceId": "[parameters('workspaceId')]"
},
"workspaceKey": "[parameters('workspaceKey')]"
}
}
}
]
}
]
}
{
"parameters": {
"vmName": {
"value": "my-linux-vm"
},
"location": {
"value": "westus"
},
"workspaceId": {
},
"workspaceKey": {
"value": "Tse-gj9CemT6A80urYa2hwtjvA5axv1xobXgKR17kbVdtacU6cEf+SNo2TdHGVKTsZHZd1W9QKRXfh+$fVY9dA=="
}
}
}
Windows Diagnostic Extension

En el ejemplo siguiente, se habilita y configura la extensión de diagnóstico en una máquina virtual de Microsoft
Azure. Para obtener más información sobre la configuración, vea Esquema de Windows Diagnostic Extension.
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
"description": "Location for the virtual machine."
}
},
"storageAccountName": {
"type": "string",
"metadata": {
"description": "Name of the storage account."
}
},
"storageAccountId": {
"type": "string",
"metadata": {
"description": "Resource ID of the storage account."
}
},
"workspaceResourceId": {
"type": "string",
"metadata": {
"description": "Resource ID of the workspace."
}
}
},
"resources": [
{
"apiVersion": "2018-10-01",
"resources": [
{
"name": "[concat(parameters('vmName'), '/Microsoft.Insights.VMDiagnosticsSettings')]",
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Diagnostics",
"type": "IaaSDiagnostics",
"settings": {
"WadCfg": {
"DiagnosticMonitorConfiguration": {
"overallQuotaInMB": 10000,
"DiagnosticInfrastructureLogs": {
"scheduledTransferLogLevelFilter": "Error"
},
"PerformanceCounters": {
"scheduledTransferPeriod": "PT1M",
"sinks": "AzureMonitorSink",
"PerformanceCounterConfiguration": [
{
"counterSpecifier": "\\Processor(_Total)\\% Processor Time",
"sampleRate": "PT1M",
"unit": "percent"
}
]
},
"WindowsEventLog": {
"DataSource": [
{
"name": "System!*[System[Provider[@Name='Microsoft
Antimalware']]]"
},
{
"name": "System!*[System[Provider[@Name='NTFS'] and
(EventID=55)]]"
},
{
"name": "System!*[System[Provider[@Name='disk'] and (EventID=7 or
EventID=52 or EventID=55)]]"
}
]
}
},
"SinksConfig": {
"Sink": [
{
"name": "AzureMonitorSink",
"AzureMonitor":
{
"ResourceId": "[parameters('workspaceResourceId')]"
}
}
]
}
},
"storageAccount": "[parameters('storageAccountName')]"
},
"storageAccountName": "[parameters('storageAccountName')]",
"storageAccountName": "[parameters('storageAccountName')]",
"storageAccountKey": "[listkeys(parameters('storageAccountId'), '2015-05-01-
preview').key1]",
"storageAccountEndPoint": "https://core.windows.net" }
}
}
]
},
{
"name": "[concat(parameters('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2018-06-01",
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"settings": {
"port": 50342
}
}
}
]
}
{
"parameters": {
"vmName": {
"value": "my-windows-vm"
},
"location": {
"value": "westus"
},
"value": "mystorageaccount"
},
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-
group/providers/Microsoft.Storage/storageAccounts/my-windows-vm"
},
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/my-resource-
group/providers/microsoft.operationalinsights/workspaces/my-workspace"
},
"workspaceKey": {
"value": "Npl#3y4SmqG4R30ukKo3oxfixZ5axv1xocXgKR17kgVdtacU4cEf+SNr2TdHGVKTsZHZv3R8QKRXfh+ToVR9dA-="
}
}
}
Configuración de diagnóstico de Linux

En el ejemplo siguiente, se habilita y configura la extensión de diagnóstico en una máquina virtual de Linux en
Azure. Para obtener más información sobre la configuración, vea Esquema de Windows Diagnostic Extension.
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
}
},
"vmId": {
"type": "string",
"metadata": {
"description": "Resource ID of the virtual machine."
}
},
"location": {
"type": "string",
"metadata": {
"description": "Location for the virtual machine."
}
},
"type": "string",
"metadata": {
"description": "Name of the storage account."
}
},
"storageSasToken": {
"type": "string",
"metadata": {
"description": "Resource ID of the storage account."
}
},
"eventHubUrl": {
"type": "string",
"metadata": {
"description": "URL of the event hub."
}
}
},
"resources": [
{
"apiVersion": "2018-10-01",
"resources": [
{
"name": "[concat(parameters('vmName'), '/Microsoft.Insights.VMDiagnosticsSettings')]",
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "LinuxDiagnostic",
"settings": {
"StorageAccount": "[parameters('storageAccountName')]",
"ladCfg": {
"sampleRateInSeconds": 15,
"diagnosticMonitorConfiguration":
{
"performanceCounters":
{
"sinks": "MyMetricEventHub,MyJsonMetricsBlob",
"performanceCounterConfiguration": [
{
"unit": "Percent",
"type": "builtin",
"counter": "PercentProcessorTime",
"counterSpecifier": "/builtin/Processor/PercentProcessorTime",
"annotation": [
{
"locale": "en-us",
"displayName": "Aggregate CPU %utilization"
}
],
"condition": "IsAggregate=TRUE",
"class": "Processor"
},
{
"unit": "Bytes",
"type": "builtin",
"counter": "UsedSpace",
"counterSpecifier": "/builtin/FileSystem/UsedSpace",
"annotation": [
{
"locale": "en-us",
"displayName": "Used disk space on /"
}
],
"condition": "Name=\"/\"",
"class": "Filesystem"
}
]
},
"metrics": {
"metricAggregation": [
{
"scheduledTransferPeriod": "PT1H"
},
{
"scheduledTransferPeriod": "PT1M"
}
],
"resourceId": "[parameters('vmId')]"
},
"eventVolume": "Large",
"syslogEvents": {
"sinks": "MySyslogJsonBlob,MyLoggingEventHub",
"syslogEventConfiguration": {
"LOG_USER": "LOG_INFO"
}
}
}
},
"perfCfg": [
{
"query": "SELECT PercentProcessorTime, PercentIdleTime FROM
SCX_ProcessorStatisticalInformation WHERE Name='_TOTAL'",
"table": "LinuxCpu",
"frequency": 60,
"sinks": "MyLinuxCpuJsonBlob,MyLinuxCpuEventHub"
}
],
"fileLogs": [
{
"file": "/var/log/myladtestlog",
"table": "MyLadTestLog",
"sinks": "MyFilelogJsonBlob,MyLoggingEventHub"
}
]
},
"storageAccountName": "yourdiagstgacct",
"storageAccountSasToken": "[parameters('storageSasToken')]",
"sinksConfig": {
"sink": [
{
"name": "MySyslogJsonBlob",
"type": "JsonBlob"
},
{
"name": "MyFilelogJsonBlob",
"type": "JsonBlob"
},
{
"name": "MyLinuxCpuJsonBlob",
"type": "JsonBlob"
},
{
"name": "MyJsonMetricsBlob",
"type": "JsonBlob"
},
{
"name": "MyLinuxCpuEventHub",
"type": "EventHub",
"sasURL": "[parameters('eventHubUrl')]"
},
{
"name": "MyMetricEventHub",
"type": "EventHub",
},
{
"name": "MyLoggingEventHub",
"type": "EventHub",
}
]
}
}
}
}
]
}
]
}
{
"parameters": {
"vmName": {
"value": "my-linux-vm"
},
"vmId": {
group/providers/Microsoft.Compute/virtualMachines/my-linux-vm"
},
"location": {
"value": "westus"
},
"value": "mystorageaccount"
},
"storageSasToken": {
"value": "?sv=2019-10-10&ss=bfqt&srt=sco&sp=rwdlacupx&se=2020-04-26T23:06:44Z&st=2020-04-
26T15:06:44Z&spr=https&sig=1QpoTvrrEW6VN2taweUq1BsaGkhDMnFGTfWakucZl4%3D"
},
"eventHubUrl": {
"value": "https://my-eventhub-namespace.servicebus.windows.net/my-eventhub?sr=my-eventhub-
namespace.servicebus.windows.net%2fmy-eventhub&sig=4VEGPTg8jxUAbTcyeF2kwOr8XZdfgTdMWEQWnVaMSqw=&skn=manage"
}
}
}
Pasos siguientes
Otras plantillas de ejemplo para Azure Monitor.
Más información sobre el agente de Log Analytics.
Más información sobre la extensión de diagnóstico.
para reglas de alertas de registros en Azure Monitor
Este artículo incluye ejemplos de plantillas de Azure Resource Manager para crear y configurar alertas de
consultas de registros en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros
con valores de ejemplo para la plantilla.
NOTE
Regla de alerta para número de resultados

En el ejemplo siguiente se crea una regla de alerta para número de resultados.
Notas
En este ejemplo se incluye una carga de webhook. Si la regla de alerta no debe desencadenar un webhook,
quite el elemento customWebhookPayload .
{
"parameters": {
"sourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Resource ID of the Log Analytisc workspace."
}
},
"location": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Location for the alert. Must be the same location as the workspace."
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "The ID of the action group that is triggered when the alert is activated."
}
}
},
"resources":[
{
"type":"Microsoft.Insights/scheduledQueryRules",
"name":"Sample log query alert",
"apiVersion": "2018-04-16",
"properties":{
"description": "Sample log query alert",
"enabled": "true",
"source": {
"query": "Event | where EventLevelName == \"Error\" | summarize count() by Computer",
"dataSourceId": "[parameters('sourceId')]",
"queryType":"ResultCount"
},
"schedule":{
"frequencyInMinutes": 15,
"timeWindowInMinutes": 60
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resource
s.ScheduledQueryRules.AlertingAction",
"severity": "4",
"aznsAction":{
"actionGroup": "[array(parameters('actionGroupId'))]",
"emailSubject": "Alert mail subject",
"customWebhookPayload":"{ \"alertname\":\"#alertrulename\",
\"IncludeSearchResults\":true }"
},
"trigger":{
"thresholdOperator": "GreaterThan",
"threshold": 1
}
}
}
}
]
}
{
"parameters": {
"sourceId": {
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/bw-samples-
arm/providers/microsoft.operationalinsights/workspaces/bw-arm-01"
},
"location": {
"value": "westus"
},
"actionGroupId": {
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/bw-samples-
arm/providers/microsoft.insights/actionGroups/ARM samples group 01"
}
}
}
Alerta para medición de métricas

En el ejemplo siguiente se crea una regla de alerta de medición de métricas.
{
"parameters": {
"sourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Resource ID of the Log Analytics workspace."
}
},
"location": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Location for the alert. Must be the same location as the workspace."
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "The ID of the action group that is triggered when the alert is activated."
}
}
},
"resources":[
{
"name":"Sample metric measurement log query alert",
"apiVersion": "2018-04-16",
"properties":{
"description": "Sample metric measurement query alert rule",
"enabled": "true",
"source": {
"query": "Event | where EventLevelName == \"Error\" | summarize AggregatedValue = count()
by bin(TimeGenerated,1h), Computer",
"dataSourceId": "[parameters('sourceId')]",
"queryType":"ResultCount"
},
"schedule":{
"schedule":{
"frequencyInMinutes": 15,
"timeWindowInMinutes": 60
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resource
s.ScheduledQueryRules.AlertingAction",
"severity": "4",
"aznsAction":{
"actionGroup": "[array(parameters('actionGroupId'))]",
"emailSubject": "Alert mail subject"
},
"trigger":{
"thresholdOperator": "GreaterThan",
"threshold": 10,
"metricTrigger":{
"thresholdOperator": "Equal",
"threshold": 1,
"metricTriggerType": "Consecutive",
"metricColumn": "Computer"
}
}
}
}
}
]
}
{
"parameters": {
"sourceId": {
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/bw-samples-
arm/providers/microsoft.operationalinsights/workspaces/bw-arm-01"
},
"location": {
"value": "westus"
},
"actionGroupId": {
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/bw-samples-
arm/providers/microsoft.insights/actionGroups/ARM samples group 01"
}
}
}
Pasos siguientes
Más información sobre reglas de alertas.
para reglas de alertas de métrica en Azure Monitor
En este artículo se proporcionan ejemplos de uso de las plantillas de Azure Resource Manager para configurar las
reglas de alertas de métricas en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de
parámetros con valores de ejemplo para la plantilla.
NOTE
Consulte Recursos compatibles para las alertas de métricas de Azure Monitor para obtener una lista de los
recursos que se pueden usar con las reglas de alertas de métricas. La explicación del esquema y de las
propiedades de una regla de alertas está disponible en Alertas de métricas: creación o actualización.
NOTE
Plantilla de recursos para la creación de alertas de métricas para el tipo de recurso: El área de trabajo de Azure Log Analytics
(es decir, Microsoft.OperationalInsights/workspaces ) requiere pasos adicionales. Para más información, consulte Alerta
de métrica para registros: plantilla de recursos.
Referencias de plantilla
Microsoft.Insights metricAlerts
Criterio único, umbral estático

En el ejemplo siguiente se crea una regla de alertas de métricas con un único criterio y un umbral estático.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the alert"
}
},
"alertDescription": {
"type": "string",
"defaultValue": "This is a metric alert",
"metadata": {
"description": "Description of alert"
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
"description": "Severity of alert {0,1,2,3,4}"
}
},
"isEnabled": {
"type": "bool",
"metadata": {
"description": "Specifies whether the alert is enabled"
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Full Resource ID of the resource emitting the metric that will be used for the
comparison. For example /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName/providers/Microsoft.compute/virtualMachines/VM_xyz"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric used in the comparison to activate the alert."
}
},
"operator": {
"type": "string",
"defaultValue": "GreaterThan",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"GreaterThanOrEqual",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
"description": "Operator comparing the current value with the threshold value."
}
},
"threshold": {
"type": "string",
"defaultValue": "0",
"metadata": {
"description": "The threshold value at which the alert is activated."
}
},
"timeAggregation": {
"type": "string",
"defaultValue": "Average",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
"description": "How the data that is collected should be combined over time."
}
},
"windowSize": {
"type": "string",
"defaultValue": "PT5M",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
"description": "Period of time used to monitor alert activity based on the threshold. Must be
between one minute and one day. ISO 8601 duration format."
}
},
"evaluationFrequency": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
"description": "how often the metric alert is evaluated represented in ISO 8601 duration
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "The ID of the action group that is triggered when the alert is activated or
deactivated"
}
}
},
"variables": { },
"resources": [
{
"name": "[parameters('alertName')]",
"type": "Microsoft.Insights/metricAlerts",
"location": "global",
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"description": "[parameters('alertDescription')]",
"severity": "[parameters('alertSeverity')]",
"enabled": "[parameters('isEnabled')]",
"scopes": ["[parameters('resourceId')]"],
"evaluationFrequency":"[parameters('evaluationFrequency')]",
"windowSize": "[parameters('windowSize')]",
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria",
"allOf": [
{
"name" : "1st criterion",
"metricName": "[parameters('metricName')]",
"dimensions":[],
"operator": "[parameters('operator')]",
"threshold" : "[parameters('threshold')]",
"timeAggregation": "[parameters('timeAggregation')]"
}
]
},
"actions": [
{
"actionGroupId": "[parameters('actionGroupId')]"
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New Metric Alert"
},
"value": "New metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resourceGroup-
name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
"value": "Percentage CPU"
},
"operator": {
"value": "GreaterThan"
},
"threshold": {
"value": "80"
},
"value": "Average"
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.Insights/actionGroups/replace-with-action-group"
}
}
}
Criterios únicos, umbral dinámico

En el ejemplo siguiente se crea una regla de alertas de métricas con un único criterio y un umbral dinámico.
Para este tutorial, guarde el archivo JSON siguiente como simpledynamicmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"defaultValue": "GreaterOrLessThan",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"alertSensitivity": {
"type": "string",
"defaultValue": "Medium",
"allowedValues": [
"High",
"High",
"Medium",
"Low"
],
"metadata": {
"description": "Tunes how 'noisy' the Dynamic Thresholds alerts will be: 'High' will result in
more alerts while 'Low' will result in fewer alerts."
}
},
"numberOfEvaluationPeriods": {
"type": "string",
"metadata": {
"description": "The number of periods to check in the alert evaluation."
}
},
"minFailingPeriodsToAlert": {
"type": "string",
"metadata": {
"description": "The number of unhealthy periods to alert on (must be lower or equal to
numberOfEvaluationPeriods)."
}
},
"ignoreDataBefore": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Use this option to set the date from which to start learning the metric
historical data and calculate the dynamic thresholds (in ISO8601 format, e.g. '2019-12-31T22:00:00Z')."
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
between five minutes and one hour. ISO 8601 duration format."
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.MultipleResourceMultipleMetricCriteria",
"allOf": [
{
"criterionType": "DynamicThresholdCriterion",
"dimensions":[],
"alertSensitivity": "[parameters('alertSensitivity')]",
"failingPeriods": {
"numberOfEvaluationPeriods": "[parameters('numberOfEvaluationPeriods')]",
"minFailingPeriodsToAlert": "[parameters('minFailingPeriodsToAlert')]"
},
"ignoreDataBefore": "[parameters('ignoreDataBefore')]",
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New Metric Alert with Dynamic Thresholds"
},
"value": "New metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
},
"operator": {
"value": "GreaterOrLessThan"
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": ""
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Varios criterios, umbral estático

Las alertas de métrica más recientes admiten las alertas relacionadas con métricas de varias dimensiones además
de hasta cinco criterios por cada regla de alerta. La siguiente plantilla de ejemplo crea una regla de alerta de
métrica relacionada con métricas dimensionales y se especifican varios criterios.
Tenga en cuenta las restricciones siguientes cuando use dimensiones en una regla de alerta que contenga varios
criterios:
Solo puede seleccionar un valor por dimensión dentro de cada criterio.
No se puede usar "*" como valor de dimensión.
Cuando las métricas configuradas con distintos criterios admiten la misma dimensión, se debe establecer de
forma explícita un valor de dimensión configurado de la misma manera para todas esas métricas, en los
criterios pertinentes.
En el ejemplo siguiente, como las métricas Transactions y SuccessE2ELatency tienen una dimensión
ApiName , y criterion1 especifica el valor "GetBlob" para la dimensión ApiName , criterion2 también
debe establecer un valor "GetBlob" para la dimensión ApiName .
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Resource ID of the resource emitting the metric that will be used for the
comparison."
}
},
"criterion1":{
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an operator.
The alert rule fires when ALL criteria are met"
}
},
"criterion2": {
"type": "object",
"metadata": {
}
},
"windowSize": {
"type": "string",
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"criterion1": "[array(parameters('criterion1'))]",
"criteria": "[concat(variables('criterion1'),variables('criterion2'))]"
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": "[variables('criteria')]"
},
"actions": [
{
}
]
}
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert (Replace with your alert name)"
},
"value": "New multi-dimensional metric alert created via template (Replace with your alert
description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resourcegroup-
name/providers/Microsoft.Storage/storageAccounts/replace-with-storage-account"
},
"criterion1": {
"value": {
"name": "1st criterion",
"metricName": "Transactions",
"dimensions": [
{
"name":"ResponseType",
"operator": "Include",
"values": ["Success"]
},
{
"name":"ApiName",
"values": ["GetBlob"]
}
],
"operator": "GreaterThan",
"threshold": "5",
"timeAggregation": "Total"
}
},
"criterion2": {
"value":{
"name": "2nd criterion",
"metricName": "SuccessE2ELatency",
"dimensions": [
{
"name":"ApiName",
}
],
"threshold": "250",
"timeAggregation": "Average"
}
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-
name/providers/Microsoft.Insights/actionGroups/replace-with-actiongroup-name"
}
}
}
Varias dimensiones, umbral estático
Una sola regla de alerta puede supervisar varias series temporales de métricas a la vez, por lo que habrá menos
reglas de alerta para administrar. El ejemplo siguiente crea una regla de alerta de métrica estática con las métricas
dimensionales.
En el ejemplo siguiente, la regla de alerta supervisa las combinaciones de valores de dimensión de las
dimensiones ResponseType y ApiName para la métrica Transactions :
1. ResponseType : el carácter comodín "*" significa que para cada valor de la dimensión ResponseType ,
incluidos los valores futuros, se supervisa individualmente una serie temporal diferente.
2. ApiName : se supervisa una serie temporal distinta solo para los valores de dimensión GetBlob y PutBlob .
Por ejemplo, algunas de las series temporales que se pueden supervisar con esta regla de alertas son:
Métrica = Transactions, ResponseType = Success, ApiName = GetBlob
Métrica = Transactions, ResponseType = Success, ApiName = PutBlob
Métrica = Transactions, ResponseType = Server Timeout, ApiName = GetBlob
Métrica = Transactions, ResponseType = Server Timeout, ApiName = PutBlob
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion":{
"type": "object",
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"criteria": "[array(parameters('criterion'))]"
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New multi-dimensional metric alert rule (replace with your alert name)"
},
"value": "New multi-dimensional metric alert rule created via template (replace with your alert
description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
},
"criterion": {
"value": {
"name": "Criterion",
"dimensions": [
{
"values": ["*"]
},
{
"name":"ApiName",
"values": ["GetBlob", "PutBlob"]
}
],
"threshold": "5",
}
},
"actionGroupId": {
}
}
}
Varias dimensiones, umbrales dinámicos
Una sola regla de alertas de umbrales dinámicos puede crear umbrales personalizados para cientos de series
temporales de métricas (incluso de distintos tipos) a la vez, por lo que habrá menos reglas de alerta para
administrar. El ejemplo siguiente crea una regla de alerta de métrica de umbrales dinámicos con las métricas
dimensionales.
1. ResponseType : para cada valor de la dimensión ResponseType , incluidos los valores futuros, se supervisa
individualmente una serie temporal diferente.
NOTE
Actualmente no se admiten varios criterios para las reglas de alertas de métricas que usan umbrales dinámicos.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion":{
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an operator."
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert with Dynamic Thresholds (Replace with your alert
name)"
},
"value": "New multi-dimensional metric alert with Dynamic Thresholds created via template (Replace
with your alert description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
},
"criterion": {
"value": {
"dimensions": [
{
"values": ["*"]
},
{
"name":"ApiName",
}
],
"operator": "GreaterOrLessThan",
"alertSensitivity": "Medium",
"failingPeriods": {
"numberOfEvaluationPeriods": "4",
"minFailingPeriodsToAlert": "3"
},
}
},
"actionGroupId": {
}
}
}
Métrica personalizada, umbral estático

Puede usar la siguiente plantilla para crear una regla de alertas de métrica de umbral estático más avanzada sobre
una métrica personalizada.
Para más información sobre las métricas personalizadas en Azure Monitor, consulte Métricas personalizadas en
Azure Monitor.
Al crear una regla de alertas sobre una métrica personalizada, debe especificar tanto el nombre de la métrica
como el espacio de nombres de la métrica. También debe asegurarse de que ya se está notificando la métrica
personalizada, ya que no se puede crear una regla de alertas en una métrica personalizada que todavía no existe.
Para este tutorial, guarde el archivo JSON siguiente como customstaticmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricNamespace": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Namespace of the metric used in the comparison to activate the alert."
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
"description": "How often the metric alert is evaluated represented in ISO 8601 duration
format"
}
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"metricNamespace": "[parameters('metricNamespace')]",
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "New alert rule on a custom metric"
},
"value": "New alert rule on a custom metric created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
name/providers/microsoft.insights/components/replace-with-application-insights-resource-name"
},
"metricName": {
"value": "The custom metric name"
},
"value": "Azure.ApplicationInsights"
},
"operator": {
},
"threshold": {
"value": "80"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
NOTE
Para buscar el espacio de nombres de la métrica de una métrica personalizada específica, vaya a las métricas personalizadas
en Azure Portal.
Varios recursos
Azure Monitor admite ahora la supervisión de varios recursos del mismo tipo con una sola regla de alertas de
métricas para los recursos de la misma región de Azure. En este momento, esta característica solo se admite en la
nube pública de Azure y para máquinas virtuales, bases de datos de SQL Server, grupos elásticos de SQL Server y
dispositivos Data Box Edge. Asimismo, solo puede emplearse con métricas de plataforma, y no con métricas
personalizadas.
La regla de alertas de los umbrales dinámicos también puede ayudar a crear umbrales personalizados para
cientos de métricas (incluso a distintos tipos) a la vez, lo que reduce el número de reglas de alertas que hay que
administrar.
En esta sección se describen las plantillas de Azure Resource Manager de tres escenarios para supervisar varios
recursos con una sola regla.
Supervisión de todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de recursos.
Supervisión de todas las máquinas virtuales (de una región de Azure) en una suscripción.
Supervisión de una lista de máquinas virtuales (de una región de Azure) en una suscripción.
NOTE
En una regla de alerta de métrica que supervisa varios recursos solo se permite una condición.
Alerta de umbral estático en todas las máquinas virtuales de uno o varios grupos de recursos
Esta plantilla creará una regla de alerta de métrica de umbral estático que supervise el valor de Porcentaje de CPU
de todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de recursos.
Guarde el archivo JSON siguiente como all-vms-in-resource-group-static.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"targetResourceGroup":{
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored are
in. For example - /subscriptions/00000000-0000-0000-0000-0000-00000000/resourceGroups/ResourceGroupName"
}
},
"targetResourceRegion":{
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"GermanyWestCentral",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaSoutheast",
"AustraliaCentral",
"AustraliaCentral2",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
"description": "Azure region in which target resources to be monitored are in (without
spaces). For example: EastUS"
}
},
"targetResourceType": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Resource type of target resources to be monitored. Currently only supported
resource type is Microsoft.Compute/virtualMachines"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M"
],
"metadata": {
format"
}
},
"actionGroupId": {
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceGroup')]",
"targetResourceType": "[parameters('targetResourceType')]",
"targetResourceRegion": "[parameters('targetResourceRegion')]",
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-
name1",
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-name2"
]
},
"value": "SouthCentralUS"
},
"targetResourceType":{
"value": "Microsoft.Compute/virtualMachines"
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
name/providers/Microsoft.Insights/actionGroups/replace-with-action-group-name"
}
}
}
Alerta de umbrales dinámicos en todas las máquinas virtuales de uno o varios grupos de recursos
Esta plantilla creará una regla de alertas de la métrica de umbrales dinámicos que supervise el valor de Porcentaje
de CPU de todas las máquinas virtuales de una región de Azure en uno o varios grupos de recursos.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored are
in. For example - /subscriptions/00000000-0000-0000-0000-0000-00000000/resourceGroups/ResourceGroupName"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1",
"/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-group-name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Alerta de umbral estático en todas las máquinas virtuales de una suscripción

Esta plantilla crea una regla de alertas de métrica de umbral estático que supervisa el valor de Porcentaje de CPU
de todas las máquinas virtuales de una región de Azure en una suscripción.
{
"parameters": {
"alertName": {
"type": "string",
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"targetSubscription":{
"type": "string",
"minLength": 1,
"metadata": {
"description": "Azure Resource Manager path up to subscription ID. For example -
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": ["[parameters('targetSubscription')]"],
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource sub level metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": "/subscriptions/replace-with-subscription-id"
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Alerta de umbrales dinámicos en todas las máquinas virtuales de una suscripción

Esta plantilla crea una regla de alertas de métrica de umbrales dinámicos que supervisa el valor de Porcentaje de
CPU de todas las máquinas virtuales (de una región de Azure) en una suscripción.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert with Dynamic Thresholds via Azure Resource Manager
template"
},
"value": "New Multi-resource sub level metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Alerta de umbral estático en una lista de máquinas virtuales

Este ejemplo crea una regla de alertas de métrica de umbral estático que supervisa el valor de Porcentaje de CPU
de una lista de máquinas virtuales de una región de Azure en una suscripción.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"targetResourceId":{
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-0000-
0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"scopes": "[parameters('targetResourceId')]",
"criteria": {
"allOf": [
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert by list via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1/Microsoft.Compute/virtualMachines/replace-with-vm-name1",
name2/Microsoft.Compute/virtualMachines/replace-with-vm-name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Alerta de umbrales dinámicos en una lista de máquinas virtuales

Este ejemplo crea una regla de alertas de métrica de umbrales dinámicos que supervisa el valor de Porcentaje de
CPU de una lista de máquinas virtuales de una región de Azure en una suscripción.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-0000-
0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds by list via Azure Resource Manager
template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Prueba de disponibilidad con alerta de métrica

Las pruebas de disponibilidad de Application Insights le ayudan a supervisar la disponibilidad del sitio web o la
aplicación desde varias ubicaciones de todo el mundo. Las alertas de la prueba de disponibilidad le avisan cuando
se producen errores en las pruebas desde un determinado número de ubicaciones. Estas alertas corresponden al
mismo tipo de recurso que las alertas de métricas (Microsoft.Insights/metricAlerts). En el ejemplo siguiente se crea
una prueba de disponibilidad simple y una alerta asociada.
NOTE
&amp ; es la referencia de entidad HTML para &. Los parámetros de dirección URL se siguen separando con un solo símbolo
&, pero si se menciona la dirección URL en HTML, es necesario codificarla. Por lo tanto, si tiene un símbolo "&" en el valor del
parámetro pingURL, tiene que agregarle un escape con " &amp ;".
{
"parameters": {
"appName": {
"type": "string"
},
"pingURL": {
"type": "string"
},
"pingText": {
"type": "string",
"defaultValue": ""
},
"actionGroupId": {
"type": "string"
},
"location": {
"type": "string"
}
},
"variables": {
"pingTestName": "[concat('PingTest-', toLower(parameters('appName')))]",
"pingAlertRuleName": "[concat('PingAlert-', toLower(parameters('appName')), '-',
subscription().subscriptionId)]"
},
"resources": [
{
"name": "[variables('pingTestName')]",
"type": "Microsoft.Insights/webtests",
"apiVersion": "2014-04-01",
"tags": {
"[concat('hidden-link:', resourceId('Microsoft.Insights/components', parameters('appName')))]":
"Resource"
},
"properties": {
"Name": "[variables('pingTestName')]",
"Description": "Basic ping test",
"Enabled": true,
"Frequency": 300,
"Timeout": 120,
"Kind": "ping",
"RetryEnabled": true,
"Locations": [
{
"Id": "us-va-ash-azr"
},
{
"Id": "emea-nl-ams-azr"
},
{
"Id": "apac-jp-kaw-edge"
}
],
"Configuration": {
"WebTest": "[concat('<WebTest Name=\"', variables('pingTestName'), '\" Enabled=\"True\"
CssProjectStructure=\"\" CssIteration=\"\" Timeout=\"120\" WorkItemIds=\"\"
xmlns=\"http://microsoft.com/schemas/VisualStudio/TeamTest/2010\" Description=\"\"
CredentialUserName=\"\" CredentialPassword=\"\" PreAuthenticate=\"True\" Proxy=\"default\"
StopOnError=\"False\" RecordedResultFile=\"\" ResultsLocale=\"\"> <Items> <Request Method=\"GET\"
Version=\"1.1\" Url=\"', parameters('pingURL'), '\" ThinkTime=\"0\" Timeout=\"300\"
ParseDependentRequests=\"True\" FollowRedirects=\"True\" RecordResult=\"True\" Cache=\"False\"
ResponseTimeGoal=\"0\" Encoding=\"utf-8\" ExpectedHttpStatusCode=\"200\" ExpectedResponseUrl=\"\"
ReportingName=\"\" IgnoreHttpStatusCode=\"False\" /> </Items> <ValidationRules> <ValidationRule
Classname=\"Microsoft.VisualStudio.TestTools.WebTesting.Rules.ValidationRuleFindText,
Microsoft.VisualStudio.QualityTools.WebTestFramework, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a\" DisplayName=\"Find Text\" Description=\"Verifies the existence of
the specified text in the response.\" Level=\"High\" ExecutionOrder=\"BeforeDependents\">
<RuleParameters> <RuleParameter Name=\"FindText\" Value=\"', parameters('pingText'), '\" />
<RuleParameter Name=\"IgnoreCase\" Value=\"False\" /> <RuleParameter Name=\"UseRegularExpression\"
Value=\"False\" /> <RuleParameter Name=\"PassIfTextFound\" Value=\"True\" /> </RuleParameters>
</ValidationRule> </ValidationRules> </WebTest>')]"
},
"SyntheticMonitorId": "[variables('pingTestName')]"
}
},
{
"name": "[variables('pingAlertRuleName')]",
"apiVersion": "2018-03-01",
"dependsOn": [
"[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]"
],
"tags": {
"Resource",
"[concat('hidden-link:', resourceId('Microsoft.Insights/webtests', variables('pingTestName')))]":
"Resource"
},
"properties": {
"description": "Alert for web test",
"severity": 1,
"enabled": true,
"scopes": [
"[resourceId('Microsoft.Insights/webtests',variables('pingTestName'))]",
"[resourceId('Microsoft.Insights/components',parameters('appName'))]"
],
"evaluationFrequency": "PT1M",
"windowSize": "PT5M",
"templateType": 0,
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.WebtestLocationAvailabilityCriteria",
"webTestId": "[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]",
"componentId": "[resourceId('Microsoft.Insights/components', parameters('appName'))]",
"failedLocationCount": 2
},
"actions": [
{
}
]
}
}
]
}
{
"parameters": {
"appName": {
"value": "Replace with your Application Insights resource name"
},
"pingURL": {
"value": "https://www.yoursite.com"
},
"actionGroupId": {
name/providers/microsoft.insights/actiongroups/replace-with-action-group-name"
},
"location": {
"value": "Replace with the location of your Application Insights resource"
}
}
}
Pasos siguientes
Obtenga más información sobre alertas.
Obtenga un ejemplo para crear un grupo de acciones con plantillas de Resource Manager
para grupos de acciones en Azure Monitor
Este artículo incluye ejemplos de plantillas de Azure Resource Manager para crear grupos de acciones en Azure
Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con valores de ejemplo para la
plantilla.
NOTE
Creación de un grupo de acciones

En el ejemplo siguiente se crea un grupo de acciones.
{
"parameters": {
"actionGroupName": {
"type": "string",
"metadata": {
"description": "Unique name within the resource group for the Action group."
}
},
"actionGroupShortName": {
"type": "string",
"metadata": {
"description": "Short name up to 12 characters for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/actionGroups",
"apiVersion": "2018-03-01",
"name": "[parameters('actionGroupName')]",
"location": "Global",
"properties": {
"groupShortName": "[parameters('actionGroupShortName')]",
"enabled": true,
"smsReceivers": [
{
"name": "contosoSMS",
"countryCode": "1",
"phoneNumber": "5555551212"
},
{
"name": "contosoSMS2",
"countryCode": "1",
}
],
"emailReceivers": [
"emailReceivers": [
{
"name": "contosoEmail",
"emailAddress": "devops@contoso.com"
},
{
"name": "contosoEmail2",
"emailAddress": "devops2@contoso.com"
}
],
"webhookReceivers": [
{
"name": "contosoHook",
"serviceUri": "http://requestb.in/1bq62iu1"
},
{
"name": "contosoHook2",
}
]
}
}
],
"outputs":{
"actionGroupId":{
"type":"string",
"value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
}
}
}
{
"parameters": {
"value": "My Action Group"
},
"value": "mygroup"
}
}
}
Pasos siguientes
Más información sobre los grupos de acciones
Ejemplos de plantilla de Resource Manager para la
creación de recursos de Application Insights
En este artículo se incluyen plantillas de Azure Resource Manager de ejemplo para implementar y configurar
recursos de Application Insights clásicos y los nuevos recursos de Application Insights basados en el área de
trabajo en versión preliminar. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con valores
de ejemplo para la plantilla.
NOTE
Recurso de Application Insights clásico

En el ejemplo siguiente se crea un recurso de Application Insights clásico.
{
"$schema": "http://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
"parameters": {
"name": {
"type": "string",
"metadata": {
"description": "Name of Application Insights resource."
}
},
"type": {
"type": "string",
"metadata": {
"description": "Type of app you are deploying. This field is for legacy reasons and will not
impact the type of App Insights resource you deploy."
}
},
"regionId": {
"type": "string",
"metadata": {
"description": "Which Azure Region to deploy the resource to. This must be a valid Azure
regionId."
}
},
"tagsArray": {
"type": "object",
"metadata": {
"description": "See documentation on tags:https://docs.microsoft.com/azure/azure-resource-
manager/management/tag-resources."
}
},
"requestSource": {
"type": "string",
"metadata": {
"description": "Source of Azure Resource Manager deployment"
}
}
},
"resources": [
{
"name": "[parameters('name')]",
"type": "microsoft.insights/components",
"location": "[parameters('regionId')]",
"tags": "[parameters('tagsArray')]",
"apiVersion": "2014-08-01",
"properties": {
"ApplicationId": "[parameters('name')]",
"Application_Type": "[parameters('type')]",
"Flow_Type": "Redfield",
"Request_Source": "[parameters('requestSource')]"
}
}
]
}
{
"parameters": {
"type": {
"value": "web"
},
"name": {
"value": "my_app_insights_resource"
},
"regionId": {
"value": "westus2"
},
"tagsArray": {
"value": {}
},
"requestSource": {
"value": "CustomDeployment"
}
}
}
Recurso de Application Insights basado en área de trabajo

En el ejemplo siguiente se crea un recurso de Application Insights basado en el área de trabajo. Los recursos de
Application Insights basados en el área de trabajo están actualmente en versión preliminar .
{
"parameters": {
"name": {
"type": "string",
"metadata": {
"description": "Name of Application Insights resource."
}
},
"type": {
"type": "string",
"metadata": {
"description": "Type of app you are deploying. This field is for legacy reasons and will not
impact the type of App Insights resource you deploy."
}
},
"regionId": {
"type": "string",
"metadata": {
"description": "Which Azure Region to deploy the resource to. This must be a valid Azure
regionId."
}
},
"tagsArray": {
"type": "object",
"metadata": {
"description": "See documentation on tags:https://docs.microsoft.com/azure/azure-resource-
manager/management/tag-resources."
}
},
"requestSource": {
"type": "string",
"metadata": {
"description": "Source of Azure Resource Manager deployment"
}
},
"type": "string",
"metadata": {
"description": "Log Analytics workspace ID to associate with your Application Insights resource."
}
}
},
"resources": [
{
"properties": {
"Request_Source": "[parameters('requestSource')]",
"WorkspaceResourceId": "[parameters('workspaceResourceId')]"
}
}
]
}
{
"parameters": {
"name": {
"value": "my_workspace_based_resource"
},
"type": {
"value": "web"
},
"regionId": {
"value": "westus2"
},
"tagsArray": {
"value": {}
},
"requestSource": {
"value": "CustomDeployment"
},
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcegroups/testxxxx/providers/microsoft.operationalinsights/workspaces/testworkspace"
}
}
}
Pasos siguientes
Más información sobre los recursos de Application Insights clásicos.
Más información sobre los recursos de Application Insights basados en el área de trabajo.
crear aplicaciones web de Azure App Services con la
supervisión de Application Insights
recursos clásicos de Application Insights junto con una aplicación web de Azure App Services. Cada ejemplo incluye
un archivo de plantilla y un archivo de parámetros con valores de ejemplo para la plantilla.
NOTE
Tiempo de ejecución de .NET Core

En el ejemplo siguiente se crea una aplicación web de Azure App Service básica con el entorno de ejecución de .NET
Core y un recurso clásico de Application Insights con la supervisión habilitada.
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"parameters": {
"subscriptionId": {
"type": "string"
},
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"hostingPlanName": {
"type": "string"
},
"serverFarmResourceGroup": {
"type": "string"
},
"alwaysOn": {
"type": "bool"
},
"currentStack": {
"type": "string"
},
"phpVersion": {
"type": "string"
},
"errorLink": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2018-11-01",
"apiVersion": "2018-11-01",
"type": "Microsoft.Web/sites",
"tags": {},
"dependsOn": [
"microsoft.insights/components/web-app-name-01"
],
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "[reference('microsoft.insights/components/web-app-name-01', '2015-05-
01').InstrumentationKey]"
},
{
"name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
01').ConnectionString]"
},
{
"name": "ApplicationInsightsAgent_EXTENSION_VERSION",
"value": "~2"
},
{
"name": "XDT_MicrosoftApplicationInsights_Mode",
"value": "default"
},
{
"name": "ANCM_ADDITIONAL_ERROR_PAGE_LINK",
"value": "[parameters('errorLink')]"
}
],
"metadata": [
{
"name": "CURRENT_STACK",
"value": "[parameters('currentStack')]"
}
],
"phpVersion": "[parameters('phpVersion')]",
"alwaysOn": "[parameters('alwaysOn')]"
},
"serverFarmId": "[concat('/subscriptions/', parameters('subscriptionId'),'/resourcegroups/',
parameters('serverFarmResourceGroup'), '/providers/Microsoft.Web/serverfarms/',
parameters('hostingPlanName'))]",
"clientAffinityEnabled": true
}
},
{
"apiVersion": "2015-05-01",
"name": "web-app-name-01",
"location": "centralus",
"tags": {},
"properties": {
"Request_Source": "IbizaWebAppExtensionCreate"
}
}
]
}
{
"parameters": {
"subscriptionId": {
},
"name": {
"value": "web-app-name-01"
},
"location": {
"value": "Central US"
},
"value": "WebApplication2720191003010920Plan"
},
"value": "Testwebapp01"
},
"alwaysOn": {
"value": true
},
"currentStack": {
"value": "dotnetcore"
},
"phpVersion": {
"value": "OFF"
},
"errorLink": {
"value": "https://web-app-name-01.scm.azurewebsites.net/detectors?type=tools&name=eventviewer"
}
}
}
Entorno de ejecución de ASP.NET

En el ejemplo siguiente se crea una aplicación web de Azure App Service básica con el entorno de ejecución de
ASP.NET y un recurso clásico de Application Insights con la supervisión habilitada.
{
"parameters": {
"subscriptionId": {
"type": "string"
},
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"type": "string"
},
"type": "string"
},
"alwaysOn": {
"type": "bool"
},
"currentStack": {
"currentStack": {
"type": "string"
},
"phpVersion": {
"type": "string"
},
"netFrameworkVersion": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2018-11-01",
"tags": {},
"dependsOn": [
],
"properties": {
"siteConfig": {
"appSettings": [
{
},
{
},
{
"value": "~2"
},
{
"value": "default"
}
],
"metadata": [
{
"name": "CURRENT_STACK",
"value": "[parameters('currentStack')]"
}
],
"phpVersion": "[parameters('phpVersion')]",
"netFrameworkVersion": "[parameters('netFrameworkVersion')]",
},
}
},
{
"apiVersion": "2015-05-01",
"tags": {},
"properties": {
}
}
}
]
}
{
"parameters": {
"subscriptionId": {
},
"name": {
},
"location": {
},
},
},
"alwaysOn": {
"value": true
},
"currentStack": {
"value": "dotnet"
},
"phpVersion": {
"value": "OFF"
},
"netFrameworkVersion": {
"value": "v4.0"
}
}
}
Entorno de ejecución de Node.js (Linux)

En el ejemplo siguiente se crea una aplicación web en Linux de Azure App Service básica con el entorno de
ejecución de Node.js y un recurso clásico de Application Insights con la supervisión habilitada.
{
"parameters": {
"subscriptionId": {
"type": "string"
},
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"type": "string"
},
"type": "string"
},
"alwaysOn": {
"type": "bool"
},
"linuxFxVersion": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2018-11-01",
"tags": {},
"dependsOn": [
],
"properties": {
"siteConfig": {
"appSettings": [
{
},
{
},
{
"value": "~2"
},
{
"value": "default"
}
],
"linuxFxVersion": "[parameters('linuxFxVersion')]",
},
"clientAffinityEnabled": false
}
},
{
"apiVersion": "2015-05-01",
"tags": null,
"properties": {
}
}
]
}
{
"parameters": {
"subscriptionId": {
},
"name": {
},
"location": {
},
"value": "App-planTest01-916e"
},
"value": "app_resource_group_custom"
},
"alwaysOn": {
"value": true
},
"linuxFxVersion": {
"value": "NODE|12-lts"
}
}
}
Pasos siguientes
Ejemplo de plantilla de Resource Manager para crear
aplicaciones de funciones de Azure con la supervisión
de Application Insights
recursos clásicos de Application Insights junto con una aplicación de funciones de Azure. El ejemplo incluye un
archivo de plantilla y un archivo de parámetros con valores de ejemplo para la plantilla.
NOTE
Aplicación de función de Azure

En el ejemplo siguiente se crea una aplicación de funciones de Azure con .NET Core 3.1 que se ejecuta en un plan
de App Service en Windows y un recurso clásico de Application Insights con la supervisión habilitada.
{
"parameters": {
"subscriptionId": {
"type": "string"
},
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"type": "string"
},
"type": "string"
},
"alwaysOn": {
"type": "bool"
},
"type": "string"
}
},
"resources": [
{
"apiVersion": "2018-11-01",
"kind": "functionapp",
"tags": {},
"dependsOn": [
"dependsOn": [
"microsoft.insights/components/function-app-01",
"[concat('Microsoft.Storage/storageAccounts/', parameters('storageAccountName'))]"
],
"properties": {
"siteConfig": {
"appSettings": [
{
"name": "FUNCTIONS_EXTENSION_VERSION",
"value": "~3"
},
{
"name": "FUNCTIONS_WORKER_RUNTIME",
"value": "dotnet"
},
{
"value": "[reference('microsoft.insights/components/function-app-01', '2015-05-
},
{
"value": "[reference('microsoft.insights/components/function-app-01', '2015-05-
},
{
"name": "AzureWebJobsStorage",
"value": "
[concat('DefaultEndpointsProtocol=https;AccountName=',parameters('storageAccountName'),';AccountKey=',listKeys(
resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2019-06-
01').keys[0].value,';EndpointSuffix=','core.windows.net')]"
}
],
},
}
},
{
"apiVersion": "2015-05-01",
"name": "function-app-01",
"tags": {},
"properties": {
}
},
{
"apiVersion": "2019-06-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "[parameters('storageAccountName')]",
"tags": {},
"sku": {
"name": "Standard_LRS"
},
"properties": {
"supportsHttpsTrafficOnly": true
}
}
]
}
{
"parameters": {
"subscriptionId": {
},
"name": {
"value": "function-app-01"
},
"location": {
},
},
},
"alwaysOn": {
"value": true
},
"value": "storageaccountest93"
}
}
}
Pasos siguientes
Ejemplos de plantillas de Resource Manager para la
configuración de diagnóstico en Azure Monitor
Este artículo incluye plantillas de Azure Resource Manager de ejemplos para crear una configuración de
diagnóstico en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con
valores de ejemplo para la plantilla.
Para crear una configuración de diagnóstico para un recurso de Azure, agregue a la plantilla un recurso de tipo
<resource namespace>/providers/diagnosticSettings . Este artículo ofrece ejemplos de algunos tipos de recursos,
pero se puede utilizar el mismo patrón con otros tipos de recursos. La recopilación de registros y métricas que
están permitidos variará en función de cada tipo de recurso.
NOTE
Configuración de diagnóstico para el registro de actividad

En el ejemplo siguiente se crea una configuración de diagnóstico para un registro de actividad mediante la
adición de un recurso de tipo Microsoft.Insights/diagnosticSettings a la plantilla.
IMPORTANT
La configuración de diagnóstico de los registros de actividad se crea para una suscripción, no para un grupo de recursos,
como la configuración de los recursos de Azure. Para implementar la plantilla de administración de recursos, use
New-AzSubscriptionDeployment para PowerShell o az deployment sub create para la CLI de Azure.
{
"parameters": {
"settingName": {
"type": "String"
},
"workspaceId": {
"type": "String"
},
"type": "String"
},
"eventHubAuthorizationRuleId": {
"type": "String"
},
"eventHubName": {
"type": "String"
}
},
"resources": [
{
"name": "[parameters('settingName')]",
"properties": {
"storageAccountId": "[parameters('storageAccountId')]",
"eventHubAuthorizationRuleId": "[parameters('eventHubAuthorizationRuleId')]",
"eventHubName": "[parameters('eventHubName')]",
"logs": [
{
"category": "Administrative",
"enabled": true
},
{
"enabled": true
},
{
"category": "ServiceHealth",
"enabled": true
},
{
"category": "Alert",
"enabled": true
},
{
"category": "Recommendation",
"enabled": true
},
{
"category": "Policy",
"enabled": true
},
{
"category": "Autoscale",
"enabled": true
},
{
"category": "ResourceHealth",
"enabled": true
}
]
}
}
]
}
{
"parameters": {
"settingName": {
"value": "Send to all locations"
},
"workspaceId": {
xxxxxxxxxxxx/resourcegroups/MyResourceGroup/providers/microsoft.operationalinsights/workspaces/MyWorkspace"
},
xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount"
},
xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.EventHub/namespaces/MyNameSpace/authorization
rules/RootManageSharedAccessKey"
},
"eventHubName": {
"value": "my-eventhub"
}
}
}
Configuración de diagnóstico para Azure Key Vault

En el ejemplo siguiente se crea una configuración de diagnóstico para Azure Key Vault mediante la adición de un
recurso de tipo Microsoft.KeyVault/vaults/providers/diagnosticSettings a la plantilla.
{
"parameters": {
"settingName": {
"type": "String"
},
"vaultName": {
"type": "String"
},
"workspaceId": {
"type": "String"
},
"type": "String"
},
"type": "String"
},
"eventHubName": {
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.KeyVault/vaults/providers/diagnosticSettings",
"name": "[concat(parameters('vaultName'), '/Microsoft.Insights/', parameters('settingName'))]",
"dependsOn": [],
"properties": {
"logs": [
{
"category": "AuditEvent",
"enabled": true
}
],
"metrics": [
{
"category": "AllMetrics",
"enabled": true
}
]
}
}
]
}
{
"parameters": {
"settingName": {
},
"vaultName": {
"value": "MyVault"
},
"workspaceId": {
},
},
},
"eventHubName": {
}
}
}
Configuración de diagnóstico para Azure SQL Database

En el ejemplo siguiente se crea una configuración de diagnóstico para una base de datos de Azure SQL mediante
la adición de un recurso de tipo microsoft.sql/servers/databases/providers/diagnosticSettings a la plantilla.
{
"parameters": {
"settingName": {
"type": "String"
},
"serverName": {
"type": "String"
},
"dbName": {
"type": "String"
},
"workspaceId": {
"type": "String"
},
"type": "String"
},
"type": "String"
},
"eventHubName": {
"type": "String"
}
},
"resources": [
{
{
"type": "microsoft.sql/servers/databases/providers/diagnosticSettings",
"name": "[concat(parameters('serverName'),'/',parameters('dbName'),'/microsoft.insights',
parameters('settingName'))]",
"dependsOn": [],
"properties": {
"logs": [
{
"category": "SQLInsights",
"enabled": true
},
{
"category": "AutomaticTuning",
"enabled": true
},
{
"category": "QueryStoreRuntimeStatistics",
"enabled": true
},
{
"category": "QueryStoreWaitStatistics",
"enabled": true
},
{
"category": "Errors",
"enabled": true
},
{
"category": "DatabaseWaitStatistics",
"enabled": true
},
{
"category": "Timeouts",
"enabled": true
},
{
"category": "Blocks",
"enabled": true
},
{
"category": "Deadlocks",
"enabled": true
}
],
"metrics": [
{
"category": "Basic",
"enabled": true
},
{
"category": "InstanceAndAppAdvanced",
"enabled": true
},
{
"category": "WorkloadManagement",
"enabled": true
}
]
}
}
]
}
{
"parameters": {
"settingName": {
},
"serverName": {
"value": "MySqlServer"
},
"dbName": {
"value": "MySqlDb"
},
"workspaceId": {
},
},
},
"eventHubName": {
}
}
}
Configuración de diagnóstico para el almacén de Recovery Services

En el ejemplo siguiente se crea una configuración de diagnóstico para un almacén de Azure Recovery Services;
para ello, se agrega a la plantilla un recurso de tipo
microsoft.recoveryservices/vaults/providers/diagnosticSettings . Este ejemplo especifica el modo de recopilación
tal como se describe en Registros de recursos de Azure. Especifique Dedicated o AzureDiagnostics para la
propiedad logAnalyticsDestinationType .
{
"parameters": {
"recoveryServicesName": {
"type": "String"
},
"settingName": {
"type": "String"
},
"workspaceId": {
"type": "String"
},
"type": "String"
},
"type": "String"
},
"eventHubName": {
"type": "String"
}
},
"resources": [
{
"type": "microsoft.recoveryservices/vaults/providers/diagnosticSettings",
"name": "[concat(parameters('recoveryServicesName'), '/Microsoft.Insights/',
"dependsOn": [],
"properties": {
"metrics": [],
"logs": [
{
"category": "AzureBackupReport",
"enabled": false
},
{
"category": "CoreAzureBackup",
"enabled": true
},
{
"category": "AddonAzureBackupJobs",
"enabled": true
},
{
"category": "AddonAzureBackupAlerts",
"enabled": true
},
{
"category": "AddonAzureBackupPolicy",
"enabled": true
},
{
"category": "AddonAzureBackupStorage",
"enabled": true
},
{
"category": "AddonAzureBackupProtectedInstance",
"enabled": true
},
{
"category": "AzureSiteRecoveryJobs",
"enabled": false
},
{
"category": "AzureSiteRecoveryEvents",
"enabled": false
},
{
"category": "AzureSiteRecoveryReplicatedItems",
"enabled": false
},
{
"category": "AzureSiteRecoveryReplicationStats",
"enabled": false
},
{
"category": "AzureSiteRecoveryRecoveryPoints",
"enabled": false
},
{
"category": "AzureSiteRecoveryReplicationDataUploadRate",
"enabled": false
},
{
"category": "AzureSiteRecoveryProtectedDiskDataChurn",
"enabled": false
}
],
"logAnalyticsDestinationType": "Dedicated"
}
}
]
}
{
"parameters": {
"settingName": {
},
"recoveryServicesName": {
"value": "my-vault"
},
"workspaceId": {
},
},
},
"eventHubName": {
}
}
}
Configuración de diagnóstico para el área de trabajo de Log Analytics

En el ejemplo siguiente se crea una configuración de diagnóstico para un área de trabajo de Log Analytics
mediante la adición de un recurso de tipo Microsoft.OperationalInsights/workspaces/providers/diagnosticSettings
a la plantilla. Este ejemplo envía datos de auditoría sobre las consultas ejecutadas en el área de trabajo a la misma
área de trabajo.
{
"parameters": {
"workspaceName": {
"type": "String"
},
"settingName": {
"type": "String"
},
"workspaceId": {
"type": "String"
},
"type": "String"
},
"type": "String"
},
"eventHubName": {
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.OperationalInsights/workspaces/providers/diagnosticSettings",
"name": "[concat(parameters('workspaceName'), '/Microsoft.Insights/',
"dependsOn": [],
"properties": {
"metrics": [],
"logs": [
{
"category": "LAQueryLogs",
"enabled": true
}
]
}
}
]
}
{
"parameters": {
"settingName": {
},
"workspaceName": {
"value": "MyWorkspace"
},
"workspaceId": {
},
},
},
"eventHubName": {
}
}
}
Pasos siguientes
Más información sobre la configuración de diagnóstico.
áreas de trabajo de Log Analytics en Azure Monitor
Este artículo incluye plantillas de Azure Resource Manager de ejemplo para crear y configurar área de trabajo de
Log Analytics en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con
valores de ejemplo para la plantilla.
NOTE
Microsoft.OperationalInsights/workspaces
Microsoft.OperationalInsights workspaces/dataSources

En el ejemplo siguiente, se crea una nueva área de trabajo de Log Analytics vacía.
Notas
Si especifica el plan de tarifa gratis , quite el elemento retentionInDays .
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"sku": {
"type": "string",
"allowedValues": [
"pergb2018",
"Free",
"Standalone",
"PerNode",
"Standard",
"Premium"
],
"defaultValue": "pergb2018",
"metadata": {
"description": "Pricing tier: PerGB2018 or legacy tiers (Free, Standalone, PerNode, Standard or
Premium) which are not available to all customers."
}
},
"location": {
"type": "string",
"allowedValues": [
"allowedValues": [
"australiacentral",
"australiaeast",
"australiasoutheast",
"brazilsouth",
"canadacentral",
"centralindia",
"centralus",
"eastasia",
"eastus",
"eastus2",
"francecentral",
"japaneast",
"koreacentral",
"northcentralus",
"northeurope",
"southafricanorth",
"southcentralus",
"southeastasia",
"switzerlandnorth",
"switzerlandwest",
"uksouth",
"ukwest",
"westcentralus",
"westeurope",
"westus",
"westus2"
],
"metadata": {
"description": "Specifies the location for the workspace."
}
},
"type": "int",
"metadata": {
"description": "Number of days to retain data."
}
},
"type": "bool",
"metadata": {
"description": "true to use resource or workspace permissions. false to require workspace
permissions."
}
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"properties": {
"sku": {
"name": "[parameters('sku')]"
},
"retentionInDays": "[parameters('retentionInDays')]",
"features": {
"searchVersion": 1,
"legacy": 0,
"enableLogAccessUsingOnlyResourcePermissions": "[parameters('resourcePermissions')]"
}
}
}
]
}
{
"parameters": {
"workspaceName": {
},
"sku": {
"value": "pergb2018"
},
"location": {
"value": "eastus"
},
"value": true
}
}
}
Recopilación de eventos de Windows

En el ejemplo siguiente, se agrega una recopilación de eventos de Windows a un área de trabajo existente.
Notas
Agregue un elemento datasources para que cada registro de eventos lo recopile. Puede especificar diferentes
tipos de evento para cada registro.
{
"parameters": {
"workspaceName": {
"type": "string"
},
"location": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"type": "datasources",
"apiVersion": "2020-08-01",
"name": "WindowsEventsSystem",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'))]"
],
"kind": "WindowsEvent",
"properties": {
"eventLogName": "System",
"eventTypes": [
{
"eventType": "Error"
},
{
"eventType": "Warning"
}
]
}
},
{
"apiVersion": "2020-08-01",
"name": "WindowsEventsApplication",
"dependsOn": [
],
"kind": "WindowsEvent",
"properties": {
"eventLogName": "Application",
"eventTypes": [
{
"eventType": "Error"
},
{
"eventType": "Warning"
},
{
"eventType": "Information"
}
]
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Recopilación de syslog
En el ejemplo siguiente, se agrega una recopilación de eventos de syslog a un área de trabajo existente.
Notas
Agregue un elemento datasources para que cada recurso lo recopile. Puede especificar diferentes gravedades
para cada recurso.
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
"description": "Specifies the location in which to create the workspace."
}
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"name": "SyslogKern",
"dependsOn": [
],
"kind": "LinuxSyslog",
"properties": {
"syslogName": "kern",
"syslogSeverities": [
{
"severity": "emerg"
},
{
"severity": "alert"
"severity": "alert"
},
{
"severity": "crit"
},
{
"severity": "err"
},
{
"severity": "warning"
},
{
"severity": "notice"
},
{
"severity": "info"
},
{
"severity": "debug"
}
]
}
},
{
"apiVersion": "2020-08-01",
"name": "SyslogDaemon",
"dependsOn": [
],
"kind": "LinuxSyslog",
"properties": {
"syslogName": "daemon",
"syslogSeverities": [
{
"severity": "emerg"
},
{
"severity": "alert"
},
{
"severity": "crit"
},
{
"severity": "err"
},
{
"severity": "warning"
}
]
}
},
{
"apiVersion": "2020-08-01",
"name": "SyslogCollection",
"dependsOn": [
],
"kind": "LinuxSyslogCollection",
"properties": {
"state": "Enabled"
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Recopilación de contadores de rendimiento de Windows

En el ejemplo siguiente, se agrega una recopilación de contadores de rendimiento de Windows a un área de
trabajo existente.
Notas
Agregue un elemento datasources para que cada contador e instancia lo recopilen. Puede establecer una tasa
de recopilación diferente para cada combinación de contador e instancia.
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
"description": "Location of the workspace."
}
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"name": "WindowsPerfMemoryAvailableBytes",
"dependsOn": [
],
"kind": "WindowsPerformanceCounter",
"properties": {
"objectName": "Memory",
"instanceName": "*",
"intervalSeconds": 10,
"counterName": "Available MBytes "
"counterName": "Available MBytes "
}
},
{
"apiVersion": "2020-08-01",
"name": "WindowsPerfMemoryPercentageBytes",
"dependsOn": [
],
"properties": {
"objectName": "Memory",
"counterName": "% Committed Bytes in Use"
}
},
{
"apiVersion": "2020-08-01",
"name": "WindowsPerfProcessorPercentage",
"dependsOn": [
],
"properties": {
"objectName": "Processor",
"instanceName": "_Total",
"counterName": "% Processor Time"
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Recopilación de contadores de rendimiento de Linux

En el ejemplo siguiente, se agrega una recopilación de contadores de rendimiento de Linux a un área de trabajo
existente.
Notas
Agregue un elemento datasources para que cada objeto e instancia lo recopilen. Puede establecer diferentes
contadores para cada combinación de objeto e instancia, pero solo puede especificar una tasa para todos los
contadores.
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
}
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"name": "LinuxPerformanceLogicalDisk",
"dependsOn": [
],
"kind": "LinuxPerformanceObject",
"properties": {
"objectName": "Logical Disk",
"performanceCounters": [
{
"counterName": "% Used Inodes"
},
{
"counterName": "Free Megabytes"
},
{
"counterName": "% Used Space"
},
{
"counterName": "Disk Transfers/sec"
},
{
"counterName": "Disk Reads/sec"
},
{
"counterName": "Disk Writes/sec"
}
]
}
},
{
"apiVersion": "2020-08-01",
"name": "LinuxPerformanceProcessor",
"dependsOn": [
],
"kind": "LinuxPerformanceObject",
"properties": {
"objectName": "Processor",
{
"counterName": "% Processor Time"
},
{
"counterName": "% Privileged Time"
}
]
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Recopilación de registros personalizados

En el ejemplo siguiente, se agrega una recopilación de registros personalizados a un área de trabajo existente.
Notas
La configuración de delimitadores y extracciones puede resultar compleja. Para obtener ayuda, puede definir un
registro personalizado mediante Azure Portal y, después, recuperar su configuración mediante Get-
AzOperationalInsightsDataSource con Tipo establecido en CustomLog .
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
}
}
},
"resources": [
{
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"type": "dataSources",
"name": "[concat(parameters('workspaceName'), 'armlog_timedelimited')]",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', '/', parameters('workspaceName'))]"
],
"kind": "CustomLog",
"properties": {
"customLogName": "arm_log_timedelimited",
"description": "this is a description",
"inputs": [
{
"location": {
"fileSystemLocations": {
"linuxFileTypeLogPaths": [ "/var/logs" ],
"windowsFileTypeLogPaths": ["c:\\Windows\\Logs\\*.txt"]
}
},
"recordDelimiter": {
"regexDelimiter": {
"matchIndex": 0,
"numberdGroup": null,
"pattern": "(^.*((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))\\s((\\d)|([0-
1]\\d)|(2[0-4])):[0-5][0-9]:[0-5][0-9].*$)"
}
}
}
],
"extractions": [
{
"extractionName": "TimeGenerated",
"extractionProperties": {
"dateTimeExtraction": {
"regex": [
{
"matchIndex": 0,
"numberdGroup": null,
"pattern": "((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))\\s((\\d)|([0-
1]\\d)|(2[0-4])):[0-5][0-9]:[0-5][0-9]"
}
]
}
},
"extractionType": "DateTime"
}
]
}
},
{
"apiVersion": "2020-08-01",
"type": "dataSources",
"name": "[concat(parameters('workspaceName'), 'armlog_newline')]",
"dependsOn": [
"[concat('Microsoft.OperationalInsights/workspaces/', '/', parameters('workspaceName'))]"
],
"kind": "CustomLog",
"properties": {
"customLogName": "armlog_newline",
"description": "this is a description",
"extractions": [],
"inputs": [
{
"location": {
"location": {
"linuxFileTypeLogPaths": [ "/var/logs" ],
"windowsFileTypeLogPaths": ["c:\\Windows\\Logs\\*.txt"]
}
},
"regexDelimiter": {
"pattern": "\\n",
"matchIndex": 0,
"numberdGroup": null
}
}
}
],
"extractions": [
{
"extractionType": "DateTime",
"regex": null,
"joinStringRegex": null
}
}
}
]
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Recopilación de registros de IIS

En el ejemplo siguiente, se agrega una recopilación de registros de IIS a un área de trabajo existente.
{
"parameters": {
"workspaceName": {
"type": "string",
"metadata": {
}
},
"location": {
"type": "string",
"metadata": {
}
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"name": "IISLog",
"dependsOn": [
],
"kind": "IISLogs",
"properties": {
"state": "OnPremiseEnabled"
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Pasos siguientes
Más información sobre las áreas de trabajo de Log Analytics.
Más información sobre los orígenes de datos de agente.
consultas de registros en Azure Monitor
Este artículo incluye plantillas de Azure Resource Manager de ejemplo para crear y configurar consultas de
registros en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con valores
de ejemplo para la plantilla.
NOTE
Microsoft.OperationalInsights/workspaces/savedSearches
Consulta de registro sencilla

En el ejemplo siguiente, se agrega una consulta de registro a un área de trabajo de Log Analytics.
{
"parameters": {
"workspaceName": {
"type": "string"
},
"location": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"type": "savedSearches",
"apiVersion": "2015-03-20",
"name": "VMSS query",
"dependsOn": [
],
"properties": {
"eTag": "*",
"displayName": "VMSS Instance Count",
"category": "VMSS",
"query": "Event | where Source == \"ServiceFabricNodeBootstrapAgent\" | summarize AggregatedValue
= count() by Computer",
"version": 1
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Consulta de registro como una función

En el ejemplo siguiente, se agrega una consulta de registro como una función a un área de trabajo de
Log Analytics.
{
"parameters": {
"workspaceName": {
"type": "string"
},
"location": {
"type": "string"
}
},
"resources": [
{
"resources": [
{
"apiVersion": "2020-08-01",
"name": "Cross workspace query",
"dependsOn": [
],
"properties": {
"etag": "*",
"displayName": "Failed Logon Events",
"FunctionAlias": "failedlogonsecurityevents",
"query": "
union withsource=SourceWorkspace
workspace('workspace1').SecurityEvent,
| where EventID == 4625",
"version": 1
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Función con parámetros

En el ejemplo siguiente, se agrega una consulta de registro como una función que utiliza un parámetro para un
área de trabajo de Log Analytics. Se incluye una segunda consulta de registro que utiliza la función con parámetro.
NOTE
La plantilla de recursos es actualmente el único método que se puede aplicar a las funciones con parámetros. Cualquier
consulta de registro puede usar la función una vez que se instala en el área de trabajo.
{
"parameters": {
"workspaceName": {
"type": "string"
},
"location": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2020-08-01",
"resources": [
{
"apiVersion": "2020-08-01",
"name": "Parameterized function",
"dependsOn": [
],
"properties": {
"etag": "*",
"displayName": "Unavailable computers function",
"category": "Samples",
"FunctionAlias": "UnavailableComputers",
"FunctionParameters": "argSpan: timespan",
"query": " Heartbeat | summarize LastHeartbeat=max(TimeGenerated) by Computer| where
LastHeartbeat < ago(argSpan)"
}
},
{
"apiVersion": "2020-08-01",
"name": "Query using function",
"dependsOn": [
],
"properties": {
"etag": "*",
"displayName": "Unavailable computers",
"category": "Samples",
"query": "UnavailableComputers(7days)"
}
}
]
}
]
}
{
"parameters": {
"workspaceName": {
},
"location": {
"value": "eastus"
}
}
}
Pasos siguientes
Más información sobre las consultas de registro.
Más información sobre las funciones.
para libros en Azure Monitor
Este artículo incluye ejemplos de plantillas de Azure Resource Manager para crear libros en Azure Monitor. Cada
ejemplo incluye un archivo de plantilla y un archivo de parámetros con valores de ejemplo para la plantilla.
NOTE
Los libros pueden ser complejos, por lo que una estrategia típica es crear el libro en Azure Portal y, a continuación,
generar una plantilla de Resource Manager. Consulte los detalles de este método en Plantilla de Azure Resource
Manager para implementar libros.
Creación de un libro
En el ejemplo siguiente se crean cuatro libros sencillos.
{
"parameters": {
"workbookDisplayName": {
"type":"string",
"defaultValue": "My Workbook",
"metadata": {
"description": "The friendly name for the workbook that is used in the Gallery or Saved List.
Needs to be unique in the scope of the resource group and source"
}
},
"workbookType": {
"type":"string",
"defaultValue": "tsg",
"metadata": {
"description": "The gallery that the workbook will been shown under. Supported values include
workbook, `tsg`, Azure Monitor, etc."
}
},
"workbookSourceId": {
"type":"string",
"defaultValue": "<insert-your-resource-id-here>",
"metadata": {
"description": "The id of resource instance to which the workbook will be associated"
}
},
"workbookId": {
"type":"string",
"defaultValue": "[newGuid()]",
"metadata": {
"description": "The unique guid for this workbook instance"
}
}
},
"resources": [
{
"name": "[parameters('workbookId')]",
"type": "Microsoft.Insights/workbooks",
"location": "[resourceGroup().location]",
"kind": "shared",
"dependsOn": [],
"properties": {
"displayName": "[parameters('workbookDisplayName')]",
"serializedData": "{\"version\":\"Notebook/1.0\",\"items\":[{\"type\":1,\"content\":\"
{\\\"json\\\":\\\"Hello World!\\\"}\",\"conditionalVisibility\":null}],\"isLocked\":false}",
"version": "1.0",
"sourceId": "[parameters('workbookSourceId')]",
"category": "[parameters('workbookType')]"
}
}
],
"outputs": {
"workbookId": {
"type": "string",
"value": "[resourceId( 'Microsoft.Insights/workbooks', parameters('workbookId'))]"
}
}
}
{
"parameters": {
"workbookDisplayName": {
"value": "Sample Hello World workbook"
},
"workbookType": {
"value": "workbook"
},
"workbookSourceId": {
"value": "Azure Monitor"
}
}
}
Pasos siguientes
Este artículo incluye plantillas de Azure Resource Manager de ejemplo para implementar y configurar el agente de
Log Analytics para máquinas virtuales en Azure Monitor. Cada ejemplo incluye un archivo de plantilla y un archivo
de parámetros con valores de ejemplo para la plantilla.
NOTE
Habilitación para un clúster de AKS

En el ejemplo siguiente, se habilita Azure Monitor para contenedores en un clúster de AKS.
{
"parameters": {
"aksResourceId": {
"type": "string",
"metadata": {
"description": "AKS Cluster Resource ID"
}
},
"aksResourceLocation": {
"type": "string",
"metadata": {
"description": "Location of the AKS resource e.g. \"East US\""
}
},
"aksResourceTagValues": {
"type": "object",
"metadata": {
"description": "Existing all tags on AKS Cluster Resource"
}
},
"type": "string",
"metadata": {
"description": "Azure Monitor Log Analytics Resource ID"
}
}
},
"resources": [
{
"name": "[split(parameters('aksResourceId'),'/')[8]]",
"type": "Microsoft.ContainerService/managedClusters",
"location": "[parameters('aksResourceLocation')]",
"tags": "[parameters('aksResourceTagValues')]",
"apiVersion": "2018-03-31",
"properties": {
"mode": "Incremental",
"id": "[parameters('aksResourceId')]",
"addonProfiles": {
"omsagent": {
"enabled": true,
"config": {
"logAnalyticsWorkspaceResourceID": "[parameters('workspaceResourceId')]"
}
}
}
}
}
]
}
{
"parameters": {
"aksResourceId": {
"value":
"/subscriptions/<SubscriptionId>/resourcegroups/<ResourceGroup>/providers/Microsoft.ContainerService/managedCl
usters/<ResourceName>"
},
"aksResourceLocation": {
"value": "<aksClusterLocation>"
},
"value":
"/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroup>/providers/Microsoft.OperationalInsights/worksp
aces/<workspaceName>"
},
"aksResourceTagValues": {
"value": {
"<existing-tag-name1>": "<existing-tag-value1>",
"<existing-tag-name2>": "<existing-tag-value2>",
"<existing-tag-nameN>": "<existing-tag-valueN>"
}
}
}
}
Habilitación para un nuevo clúster de Red Hat OpenShift v3 en Azure

{
"parameters": {
"location": {
"type": "string",
"metadata": {
"description": "Location"
}
},
"clusterName": {
"type": "string",
"metadata": {
"description": "Unique name for the cluster"
}
},
"masterNodeCount": {
"type": "int",
"defaultValue": 3,
"metadata": {
"description": "number of master nodes"
}
},
"computeNodeCount": {
"type": "int",
"defaultValue": 3,
"metadata": {
"description": "number of compute nodes"
}
},
"infraNodeCount": {
"type": "int",
"defaultValue": 3,
"metadata": {
"description": "number of infra nodes"
}
},
"aadTenantId": {
"type": "string",
"metadata": {
"description": "The ID of an Azure Active Directory tenant"
}
},
"aadClientId": {
"type": "string",
"metadata": {
"description": "The ID of an Azure Active Directory client application"
}
},
"aadClientSecret": {
"type": "securestring",
"metadata": {
"description": "The secret of an Azure Active Directory client application"
}
},
"aadCustomerAdminGroupId": {
"type": "string",
"metadata": {
"description": "The Object ID of an Azure Active Directory Group that memberships will get synced into
the OpenShift group 'osa-customer-admins'. If not specified, no cluster admin access will be granted."
}
},
"type": "string",
"metadata": {
"description": "Azure ResourceId of an existing Log Analytics Workspace"
}
}
},
"resources": [
{
"name": "[parameters('clusterName')]",
"type": "Microsoft.ContainerService/openShiftManagedClusters",
"properties": {
"openShiftVersion": "v3.11",
"fqdn": "[concat(parameters('clusterName'), '.', parameters('location'), '.', 'cloudapp.azure.com')]",
"networkProfile": {
"vnetCidr": "10.0.0.0/8"
},
"authProfile": {
"identityProviders": [
{
"name": "Azure AD",
"provider": {
"kind": "AADIdentityProvider",
"clientId": "[parameters('aadClientId')]",
"secret": "[parameters('aadClientSecret')]",
"tenantId": "[parameters('aadTenantId')]",
"customerAdminGroupId": "[parameters('aadCustomerAdminGroupId')]"
}
}
]
},
"masterPoolProfile": {
"name": "master",
"count": "[parameters('masterNodeCount')]",
"subnetCidr": "10.0.0.0/24",
"vmSize": "Standard_D4s_v3",
"osType": "Linux"
},
"agentPoolProfiles": [
{
"role": "compute",
"name": "compute",
"count": "[parameters('computeNodeCount')]",
"subnetCidr": "10.0.0.0/24",
"osType": "Linux"
},
{
"role": "infra",
"name": "infra",
"count": "[parameters('infraNodeCount')]",
"subnetCidr": "10.0.0.0/24",
"osType": "Linux"
}
],
"routerProfiles": [
{
"name": "default"
}
],
"monitorProfile": {
"workspaceResourceID": "[parameters('workspaceResourceId')]",
"enabled": true
}
}
}
]
}
{
"parameters": {
"location": {
"value": "<azure region of the cluster e.g. westcentralus>"
},
"clusterName": {
"value": "<name of the aro cluster>"
},
"aadTenantId": {
"value": "<id of an azure active directory tenant>"
},
"aadClientId": {
"value": "<id of an azure active directory client application>"
},
"aadClientSecret": {
"value": "<secret of an azure active directory client application >"
},
"aadCustomerAdminGroupId": {
"value": "<customer admin group id>"
},
"value": "<resource id of an existing log analytics workspace>"
},
"masterNodeCount": {
"value": "<number of master node e.g. 3>"
},
"computeNodeCount": {
"value": "<number of compute nodes in agent pool profile e.g. 3>"
},
"infraNodeCount": {
"value": "<number of infra nodes in agent pool profile e.g. 3>"
}
}
}
Habilitación para un clúster existente de Red Hat OpenShift v3 en

Azure
{
"parameters": {
"aroResourceId": {
"type": "string",
"metadata": {
"description": "ARO Cluster Resource ID"
}
},
"aroResourceLocation": {
"type": "string",
"metadata": {
"description": "Location of the aro cluster resource e.g. westcentralus"
}
},
"type": "string",
"metadata": {
"description": "Azure Monitor Log Analytics Resource ID"
}
}
},
"resources": [
{
"name": "[split(parameters('aroResourceId'),'/')[8]]",
"type": "Microsoft.ContainerService/openShiftManagedClusters",
"location": "[parameters('aroResourceLocation')]",
"properties": {
"id": "[parameters('aroResourceId')]",
"monitorProfile": {
"enabled": true,
"workspaceResourceID": "[parameters('workspaceResourceId')]"
}
}
}
]
}
{
"parameters": {
"aroResourceId": {
"value":
"/subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.ContainerService/openShiftManagedClusters/
<clusterName>"
},
"aroResourceLocation": {
"value": "<azure region of the cluster e.g. westcentralus>"
},
"value":
"/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroup>/providers/Microsoft.OperationalInsights/worksp
aces/<workspaceName>"
}
}
}
Pasos siguientes
Más información sobre Azure Monitor para contenedores
para Azure Monitor para VM
Este artículo incluye ejemplos de plantillas de Azure Resource Manager para habilitar Azure Monitor para VM en
máquinas virtuales. Cada ejemplo incluye un archivo de plantilla y un archivo de parámetros con valores de
ejemplo para la plantilla.
NOTE

El siguiente ejemplo habilita Azure Monitor para VM para un área de trabajo de Log Analytics.
{
"parameters": {
"type": "String",
"metadata": {
"description": "Resource ID of the workspace."
}
},
"workspaceLocation": {
"type": "String",
"metadata": {
"description": "Location of the workspace."
}
}
},
"resources": [
{
"type": "Microsoft.Resources/deployments",
"apiVersion": "2017-05-10",
"name": "VMISolutionDeployment",
"properties": {
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"resources": [
{
"type": "Microsoft.OperationsManagement/solutions",
"location": "[parameters('workspaceLocation')]",
"name": "[concat('VMInsights', '(', split(parameters('workspaceResourceId'),'/')
[8], ')')]",
"properties": {
"workspaceResourceId": "[parameters('WorkspaceResourceId')]"
},
"plan": {
"name": "[concat('VMInsights', '(',
split(parameters('workspaceResourceId'),'/')[8], ')')]",
"product": "[concat('OMSGallery/', 'VMInsights')]",
"promotionCode": "",
"publisher": "Microsoft"
}
}
]
}
},
"subscriptionId": "[split(parameters('workspaceResourceId'),'/')[2]]",
"resourceGroup": "[split(parameters('workspaceResourceId'),'/')[4]]"
}
]
}
{
"parameters": {
},
"workspaceLocation": {
"value": "eastus"
}
}
}
Incorporación de una máquina virtual de Azure

En el ejemplo siguiente se agrega una máquina virtual de Azure a Azure Monitor para VM.
{
"parameters": {
"VmResourceId": {
"type": "String",
"metadata": {
"description": "VM Resource ID."
}
},
"VmLocation": {
"type": "String",
"metadata": {
"description": "The Virtual Machine Location."
}
},
"osType": {
"type": "String",
"metadata": {
"description": "OS Type, Example: Linux / Windows"
}
},
"WorkspaceResourceId": {
"type": "String",
"metadata": {
"description": "Workspace Resource ID."
}
}
},
"variables": {
"VmName": "[split(parameters('VmResourceId'),'/')[8]]",
"DaExtensionName": "[if(equals(toLower(parameters('osType')), 'windows'), 'DependencyAgentWindows',
'DependencyAgentLinux')]",
"DaExtensionType": "[if(equals(toLower(parameters('osType')), 'windows'), 'DependencyAgentWindows',
"DaExtensionVersion": "9.5",
"MmaExtensionName": "[if(equals(toLower(parameters('osType')), 'windows'), 'MMAExtension',
'OMSExtension')]",
"MmaExtensionType": "[if(equals(toLower(parameters('osType')), 'windows'), 'MicrosoftMonitoringAgent',
'OmsAgentForLinux')]",
"MmaExtensionVersion": "[if(equals(toLower(parameters('osType')), 'windows'), '1.0', '1.4')]"
},
"resources": [
{
"apiVersion": "2018-10-01",
"apiVersion": "2018-10-01",
"name": "[variables('VmName')]",
"location": "[parameters('VmLocation')]",
"resources": [
{
"type": "extensions",
"apiVersion": "2018-10-01",
"name": "[variables('DaExtensionName')]",
"dependsOn": [
"[concat('Microsoft.Compute/VirtualMachines/', variables('VmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "[variables('DaExtensionType')]",
"typeHandlerVersion": "[variables('DaExtensionVersion')]",
"autoUpgradeMinorVersion": true
}
},
{
"apiVersion": "2018-10-01",
"name": "[variables('MmaExtensionName')]",
"dependsOn": [
"[concat('Microsoft.Compute/VirtualMachines/', variables('VmName'))]"
],
"properties": {
"type": "[variables('MmaExtensionType')]",
"typeHandlerVersion": "[variables('MmaExtensionVersion')]",
"autoUpgradeMinorVersion": "true",
"settings": {
"workspaceId": "[reference(parameters('WorkspaceResourceId'), '2015-03-
20').customerId]",
"azureResourceId": "[parameters('VmResourceId')]",
"stopOnMultipleConnections": "true"
},
"workspaceKey": "[listKeys(parameters('WorkspaceResourceId'), '2015-03-
20').primarySharedKey]"
}
}
}
]
}
]
}
{
"parameters": {
"vmResourceId": {
group/providers/Microsoft.Compute/virtualMachines/my-linux-vm"
},
"vmLocation": {
"value": "westus"
},
"osType": {
"value": "linux"
},
}
}
}
Incorporación de un conjunto de escalado de máquinas virtuales de

Azure
En el ejemplo siguiente se agrega un conjunto de escalado de máquinas virtuales de Azure a Azure Monitor para
VM.
{
"parameters": {
"VmssResourceId": {
"type": "String",
"metadata": {
"description": "VM Resource ID."
}
},
"VmssLocation": {
"type": "String",
"metadata": {
"description": "The Virtual Machine Location."
}
},
"osType": {
"type": "String",
"metadata": {
"description": "OS Type, Example: Linux / Windows"
}
},
"type": "String",
"metadata": {
"description": "Workspace Resource ID."
}
}
},
"variables": {
"VmssName": "[split(parameters('VmssResourceId'),'/')[8]]",
"DaExtensionName": "[if(equals(toLower(parameters('osType')), 'windows'), 'DependencyAgentWindows',
"DaExtensionType": "[if(equals(toLower(parameters('osType')), 'windows'), 'DependencyAgentWindows',
"DaExtensionVersion": "9.5",
"MmaExtensionName": "[if(equals(toLower(parameters('osType')), 'windows'), 'MMAExtension',
'OMSExtension')]",
"MmaExtensionType": "[if(equals(toLower(parameters('osType')), 'windows'), 'MicrosoftMonitoringAgent',
'OmsAgentForLinux')]",
"MmaExtensionVersion": "[if(equals(toLower(parameters('osType')), 'windows'), '1.0', '1.4')]"
},
"resources": [
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"apiVersion": "2018-10-01",
"name": "[variables('VmssName')]",
"location": "[parameters('VmssLocation')]",
"resources": [
{
"apiVersion": "2018-10-01",
"name": "[variables('DaExtensionName')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachineScaleSets/', variables('VmssName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "[variables('DaExtensionType')]",
"typeHandlerVersion": "[variables('DaExtensionVersion')]",
"autoUpgradeMinorVersion": true
}
},
{
"apiVersion": "2018-10-01",
"name": "[variables('MmaExtensionName')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachineScaleSets/', variables('VmssName'))]"
],
"properties": {
"type": "[variables('MmaExtensionType')]",
"typeHandlerVersion": "[variables('MmaExtensionVersion')]",
"autoUpgradeMinorVersion": "true",
"settings": {
"workspaceId": "[reference(parameters('WorkspaceResourceId'), '2015-03-
20').customerId]",
"azureResourceId": "[parameters('VmssResourceId')]",
"stopOnMultipleConnections": "true"
},
"workspaceKey": "[listKeys(parameters('WorkspaceResourceId'), '2015-03-
20').primarySharedKey]"
}
}
}
]
}
]
}
{
"parameters": {
"VmssResourceId": {
group/providers/Microsoft.Compute/virtualMachines/my-windows-vmss"
},
"VmssLocation": {
"value": "westus"
},
"OsType": {
"value": "windows"
},
}
}
}
Pasos siguientes
Más información sobre Azure Monitor para VM.
Ejemplos de la CLI de Azure Monitor
En este artículo se muestran comandos de la interfaz de la línea de comandos (CLI) de ejemplo que lo ayudarán a
acceder a las características de supervisión de Azure Monitor. Azure Monitor permite escalar automáticamente
Cloud Services, Virtual Machines y Web Apps para enviar notificaciones de alerta o llamar a direcciones URL web
en función de los valores de datos de telemetría configurados.
Requisitos previos
Si aún no ha instalado la CLI de Azure, siga las instrucciones para instalar la CLI de Azure. También puede usar
Azure Cloud Shell para ejecutar la CLI como una experiencia interactiva en el explorador. Consulte una referencia
completa de todos los comandos disponibles en la referencia de la CLI de Azure Monitor.

El primer paso consiste en iniciar sesión en su cuenta de Azure.
az login
Después de ejecutar este comando, tendrá que iniciar sesión siguiendo las instrucciones de la pantalla. Todos los
comandos funcionan en el contexto de la suscripción predeterminada.
Muestre los detalles de la suscripción actual.
az account show
Cambie el contexto de trabajo a una suscripción diferente.
az account set -s <Subscription ID or name>
Vea una lista de todos los comandos de Azure Monitor admitidos.
az monitor -h
Ver el registro de actividades

Vea una lista de eventos del registro de actividad.
az monitor activity-log list
Vea todas las opciones disponibles.
az monitor activity-log list -h
Muestre los registros por grupo de recursos.

az monitor activity-log list --resource-group <group name>
Muestre los registros por autor de llamada.
az monitor activity-log list --caller myname@company.com
Muestre los registros por autor de llamada en un tipo de recurso, dentro de un intervalo de fechas.
az monitor activity-log list --resource-provider Microsoft.Web \

--caller myname@company.com \
--start-time 2016-03-08T00:00:00Z \
--end-time 2016-03-16T00:00:00Z
Uso de alertas
NOTE
Solo las alertas (clásicas) se admiten en la CLI en este momento.
Obtención de reglas de alerta (clásicas) en un grupo de recursos
az monitor activity-log alert list --resource-group <group name>

az monitor activity-log alert show --resource-group <group name> --name <alert name>
Creación de una regla de alerta (clásica) de métrica
az monitor alert create --name <alert name> --resource-group <group name> \

--action email <email1 email2 ...> \
--action webhook <URI> \
--target <target object ID> \
--condition "<METRIC> {>,>=,<,<=} <THRESHOLD> {avg,min,max,total,last} ##h##m##s"
Eliminación de una regla de alerta (clásica)
az monitor alert delete --name <alert name> --resource-group <group name>
Perfiles de registro
Utilice la información de esta sección para usar perfiles de registro.
Obtención de un perfil de registro
az monitor log-profiles list

az monitor log-profiles show --name <profile name>
Adición de un perfil de registro con retención de datos

az monitor log-profiles create --name <profile name> --location <location of profile> \
--locations <locations to monitor activity in: location1 location2 ...> \
--categories <categoryName1 categoryName2 ...> \
--days <# days to retain> \
--enabled true \
--storage-account-id <storage account ID to store the logs in>
Adición de un perfil de registro con retención y EventHub
az monitor log-profiles create --name <profile name> --location <location of profile> \

--locations <locations to monitor activity in: location1 location2 ...> \
--categories <categoryName1 categoryName2 ...> \
--days <# days to retain> \
--enabled true
--storage-account-id <storage account ID to store the logs in>
--service-bus-rule-id <service bus rule ID to stream to>
Eliminación de un perfil de registro
az monitor log-profiles delete --name <profile name>
Diagnóstico
Utilice la información de esta sección para usar la configuración de diagnóstico.
Obtención de la configuración de diagnóstico
az monitor diagnostic-settings list --resource <target resource ID>
Creación de una configuración de diagnóstico
az monitor diagnostic-settings create --name <diagnostic name> \

--storage-account <storage account ID> \
--resource <target resource object ID> \
--logs '[
{
"category": <category name>,
"enabled": true,
"retentionPolicy": {
"days": <# days to retain>,
"enabled": true
}
}]'
Eliminación de la configuración de diagnóstico
az monitor diagnostic-settings delete --name <diagnostic name> \

--resource <target resource ID>
Utilice la información de esta sección para usar la configuración de escalado automático. Tendrá que modificar
estos ejemplos.
Obtención de la configuración de escalado automático de un grupo de recursos
az monitor autoscale list --resource-group <group name>
Obtención de valores de escalado automático por su nombre en un grupo de recursos
az monitor autoscale show --name <settings name> --resource-group <group name>
Configuración del escalado automático
az monitor autoscale create --name <settings name> --resource-group <group name> \

--count <# instances> \
--resource <target resource ID>
Ejemplos de PowerShell de Azure Monitor
En este artículo se muestran comandos de PowerShell de ejemplo para ayudarle a acceder a las características de
Azure Monitor.
NOTE
Azure Monitor es el nuevo nombre de lo que se conocía como "Azure Insights" hasta el 25 de septiembre de 2016. Sin
embargo, los espacios de nombres y, por tanto, los siguientes comandos, aún contienen el término insights.
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.
Configurar PowerShell
Si no lo ha hecho ya, configure PowerShell para que se ejecute en el equipo. Para más información, consulte el
artículo de instalación y configuración de PowerShell.
Ejemplos de este artículo

Los ejemplos de este artículo muestran cómo puede usar cmdlets de Azure Monitor. También puede consultar
toda la lista de cmdlets de PowerShell de Azure Monitor en Azure Monitor Cmdlets (Cmdlets de Azure Monitor).
Inicio de sesión y uso de suscripciones

Primero, inicie sesión en la suscripción de Azure.
Connect-AzAccount
Verá una pantalla de inicio de sesión. Una vez que inicie sesión, se muestran el identificador predeterminado de la
suscripción, el identificador de inquilino y la cuenta. Todos los cmdlets de Azure funcionan en el contexto de la
suscripción predeterminada. Para ver la lista de suscripciones a las que tiene acceso, use el siguiente comando:
Get-AzSubscription
Para ver el contexto de trabajo (en qué suscripción se ejecutan los comandos), use el siguiente comando:
Get-AzContext
Para cambiar el contexto de trabajo a una suscripción diferente, utilice el siguiente comando:
Set-AzContext -SubscriptionId <subscriptionid>
Recuperación del registro de actividad

Use el cmdlet Get AzLog. A continuación se muestran algunos ejemplos comunes. El registro de actividad contiene
los últimos 90 días de operaciones. El uso de las fechas anteriores a ese período provoca un mensaje de error.
Vea cuál es la fecha y hora actual para comprobar qué períodos se deben usar en el siguiente comando:
Get-Date
Obtención de entradas de registro desde esta fecha y hora hasta la actual:
Get-AzLog -StartTime 2019-03-01T10:30
Obtención de entradas de registro entre un intervalo de fecha y hora:
Get-AzLog -StartTime 2019-01-01T10:30 -EndTime 2015-01-01T11:30
Obtención de entradas de registro de un grupo de recursos específico:
Get-AzLog -ResourceGroup 'myrg1'
Obtención de entradas de registro de un proveedor de recursos específico entre un intervalo de fecha y hora:
Get-AzLog -ResourceProvider 'Microsoft.Web' -StartTime 2015-01-01T10:30 -EndTime 2015-01-01T11:30
Obtener todas las entradas de registro con un llamador concreto:
Get-AzLog -Caller 'myname@company.com'
El comando siguiente recupera los últimos 1000 eventos desde el registro de actividades:
Get-AzLog -MaxRecord 10
Get-AzLog es compatible con muchos otros parámetros. Consulte la referencia Get-AzLog para obtener más
información.
NOTE
Get-AzLog solo proporciona 15 días de historial. El parámetro -MaxRecords permite consultar los últimos eventos N más
allá de 15 días. Para acceder a eventos de hace más de 15 días, use el SDK o la API de REST (ejemplo de C# usando el SDK).
Si no incluye Star tTime , el valor predeterminado será EndTime menos una hora. Si no incluye EndTime , el valor
predeterminado será la hora actual. Todas las horas se muestran en UTC.
Recuperación del historial de alertas

Para ver todos los eventos de alerta, puede consultar los registros de Azure Resource Manager con los ejemplos
siguientes.
Get-AzLog -Caller "Microsoft.Insights/alertRules" -DetailedOutput -StartTime 2015-03-01
Para ver el historial de una regla de alerta específica, puede utilizar el cmdlet Get-AzAlertHistory , con lo que se
transmitirá el id. de recurso de la regla de alerta.
Get-AzAlertHistory -ResourceId
/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/alertrules/myalert -StartTime 2016-03-1 -
Status Activated
El cmdlet Get-AzAlertHistory admite varios parámetros. Puede obtener más información en Get-AlertHistory.
Recuperación de información sobre reglas de alerta

Todos los comandos siguientes se realizan en un grupo de recursos denominado "montest".
Consulta de todas las propiedades de la regla de alerta:
Get-AzAlertRule -Name simpletestCPU -ResourceGroup montest -DetailedOutput
Recuperación de todas las alertas de un grupo de recursos:
Get-AzAlertRule -ResourceGroup montest
Recuperación de todas las reglas de alerta de un recurso de destino. Por ejemplo, todas las reglas de alerta se
establecen en una máquina virtual.
Get-AzAlertRule -ResourceGroup montest -TargetResourceId

/subscriptions/s1/resourceGroups/montest/providers/Microsoft.Compute/virtualMachines/testconfig
Get-AzAlertRule es compatible con otros parámetros. Consulte Get AlertRule para obtener más información.
Creación de alertas de métrica

Puede usar el cmdlet Add-AlertRule para crear, actualizar o deshabilitar una regla de alerta.
Puede crear propiedades de correo electrónico y webhook mediante New-AzAlertRuleEmail y
New-AzAlertRuleWebhook respectivamente. En el cmdlet de regla de alerta, asigne estas propiedades como acciones
a la propiedad Actions de la regla de alerta.
En la tabla siguiente se describen los parámetros y valores utilizados para crear una alerta con una métrica.
PA RÁ M ET RO VA L UE
Nombre simpletestdiskwrite
Ubicación (Location) de esta regla de alerta Este de EE. UU.
ResourceGroup montest
TargetResourceId /subscriptions/s1/resourceGroups/montest/providers/Microso
ft.Compute/virtualMachines/testconfig
Nombre de la métrica (MetricName) de la alerta que se crea \PhysicalDisk(_Total)\Disk Writes/sec. See the
Get-MetricDefinitions cmdlet about how to retrieve the
exact metric names
operator GreaterThan
Valor de umbral (número por segundo para esta métrica) 1
WindowSize (formato hh:mm:ss) 00:05:00
aggregator (estadística de la métrica que, en este caso, usa el Average

recuento medio)
mensajes de correo electrónico personalizados (matriz de 'foo@example.com','bar@example.com'

cadenas)
enviar correo electrónico a los propietarios, colaboradores y -SendToServiceOwners

lectores
Creación de una acción de correo electrónico
$actionEmail = New-AzAlertRuleEmail -CustomEmail myname@company.com
Crear una acción de Webhook
$actionWebhook = New-AzAlertRuleWebhook -ServiceUri https://example.com?token=mytoken
Creación de la regla de alerta de la métrica CPU% en una máquina virtual clásica
Add-AzMetricAlertRule -Name vmcpu_gt_1 -Location "East US" -ResourceGroup myrg1 -TargetResourceId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.ClassicCompute/virtualMachines/my_vm1 -MetricName
"Percentage CPU" -Operator GreaterThan -Threshold 1 -WindowSize 00:05:00 -TimeAggregationOperator Average -
Action $actionEmail, $actionWebhook -Description "alert on CPU > 1%"
Recuperación de la regla de alerta
Get-AzAlertRule -Name vmcpu_gt_1 -ResourceGroup myrg1 -DetailedOutput
El cmdlet Add alert también actualiza la regla si ya existe una para las propiedades determinadas. Para deshabilitar
una regla de alerta, incluya el parámetro -DisableRule .
Obtención de una lista de métricas disponibles para las alertas

Puede usar el cmdlet Get-AzMetricDefinition para ver la lista de todas las métricas de un recurso específico.
Get-AzMetricDefinition -ResourceId <resource_id>

En el ejemplo siguiente se genera una tabla con el nombre y la unidad de la métrica.
Get-AzMetricDefinition -ResourceId <resource_id> | Format-Table -Property Name,Unit
Hay disponible una lista completa de opciones para Get-AzMetricDefinition en Get-MetricDefinitions.
Creación y administración de alertas del registro de actividades

Puede usar el cmdlet Set-AzActivityLogAlert para establecer una alerta de registro de actividad. Una alerta de
registro de actividad requiere que primero defina las condiciones como un diccionario de condiciones, y luego
cree una alerta que utilice esas condiciones.
$condition1 = New-AzActivityLogAlertCondition -Field 'category' -Equal 'Administrative'

$condition2 = New-AzActivityLogAlertCondition -Field 'operationName' -Equal
'Microsoft.Compute/virtualMachines/write'
$additionalWebhookProperties = New-Object
"System.Collections.Generic.Dictionary``2[System.String,System.String]"
$additionalWebhookProperties.Add('customProperty', 'someValue')
$actionGrp1 = New-AzActionGroup -ActionGroupId '/subscriptions/<subid>/providers/Microsoft.Insights/actiongr1'
-WebhookProperty $additionalWebhookProperties
Set-AzActivityLogAlert -Location 'Global' -Name 'alert on VM create' -ResourceGroupName 'myResourceGroup' -
Scope '/subscriptions/<subid>' -Action $actionGrp1 -Condition $condition1, $condition2
Las propiedades de webhook adicionales son opcionales. Puede volver el contenido de una alerta de registro de
actividad con Get-AzActivityLogAlert .
Creación y administración de la configuración de escalado automático

NOTE
Para Cloud Services (Microsoft.ClassicCompute), el escalado automático admite un intervalo de tiempo de 5 minutos
(PT5M). En el caso de los demás servicios, el escalado automático admite un intervalo de tiempo mínimo de 1 minuto
(PT1M).
Los recursos (aplicaciones web, las máquinas virtuales, los servicios en la nube o los conjuntos de escalado de
máquinas virtuales) solo pueden tener una configuración de escalado automático. Sin embargo, cada
configuración de escalado automático puede tener varios perfiles. Por ejemplo, uno para un perfil de escalado
basado en el rendimiento y otro para uno basado en la programación. Cada perfil puede tener varias reglas
configuradas. Para obtener más información sobre el escalado automático, consulte Escalado automático de una
aplicación.
Estos son los pasos que debe seguir:
1. Cree reglas.
2. Cree perfiles que asignen las reglas que ha creado anteriormente a los perfiles.
3. Opcional: cree notificaciones de escalado automático configurando las propiedades de Webhook y correo
electrónico.
4. Cree una configuración de escalado automático con un nombre en el recurso de destino mediante la
asignación de los perfiles y las notificaciones que creó en los pasos anteriores.
En los ejemplos siguientes se muestra cómo crear una configuración de escalado automático para un conjunto de
escalado de máquinas virtuales de un sistema operativo de Windows mediante la métrica de uso de CPU.
En primer lugar, cree una regla de escalado horizontal con aumento del recuento de instancias.
$rule1 = New-AzAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -Operator
GreaterThan -MetricStatistic Average -Threshold 60 -TimeGrain 00:01:00 -TimeWindow 00:10:00 -
ScaleActionCooldown 00:10:00 -ScaleActionDirection Increase -ScaleActionValue 1
Después, cree una regla de reducción de escalado con una disminución del recuento de instancias.
$rule2 = New-AzAutoscaleRule -MetricName "Percentage CPU" -MetricResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -Operator
GreaterThan -MetricStatistic Average -Threshold 30 -TimeGrain 00:01:00 -TimeWindow 00:10:00 -
ScaleActionCooldown 00:10:00 -ScaleActionDirection Decrease -ScaleActionValue 1
Después, cree un perfil para las reglas.
$profile1 = New-AzAutoscaleProfile -DefaultCapacity 2 -MaximumCapacity 10 -MinimumCapacity 2 -Rules

$rule1,$rule2 -Name "My_Profile"
Cree una propiedad de Webhook.
$webhook_scale = New-AzAutoscaleWebhook -ServiceUri "https://example.com?mytoken=mytokenvalue"
Cree la propiedad de notificación para la configuración de escalado automático, incluidas las de correo electrónico
y Webhook que creó anteriormente.
$notification1= New-AzAutoscaleNotification -CustomEmails ashwink@microsoft.com -

SendEmailToSubscriptionAdministrators SendEmailToSubscriptionCoAdministrators -Webhooks $webhook_scale
Finalmente, cree la configuración de escalado automático para agregar el perfil que creó antes.
Add-AzAutoscaleSetting -Location "East US" -Name "MyScaleVMSSSetting" -ResourceGroup big2 -TargetResourceId

/subscriptions/s1/resourceGroups/big2/providers/Microsoft.Compute/virtualMachineScaleSets/big2 -
AutoscaleProfiles $profile1 -Notifications $notification1
Para obtener más información sobre cómo administrar la configuración de escalado automático, consulte Get-
AutoscaleSetting.
Historial de escalado automático

En el ejemplo siguiente se muestra cómo puede ver los eventos de alerta y escalado automático recientes. Utilice
la búsqueda de registros de actividades para ver el historial de escalado automático.
Get-AzLog -Caller "Microsoft.Insights/autoscaleSettings" -DetailedOutput -StartTime 2015-03-01
Puede usar el cmdlet Get-AzAutoScaleHistory para recuperar el historial de escalado automático.
Get-AzAutoScaleHistory -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/microsoft.insights/autoscalesettings/myScaleSetting -
StartTime 2016-03-15 -DetailedOutput
Para obtener más información, consulte Get-AutoscaleHistory.

Consulta de los detalles de una configuración de escalado automático
Puede usar el cmdlet Get-Autoscalesetting para recuperar más información sobre la configuración de escalado
automático.
En el ejemplo siguiente se muestra información sobre todas las configuraciones de escalado automático del grupo
de recursos "myrg1".
Get-AzAutoscalesetting -ResourceGroup myrg1 -DetailedOutput
En el ejemplo siguiente se muestra información sobre todas las configuraciones de escalado automático del grupo
de recursos "myrg1" y, en concreto, la configuración de escalado automático con el nombre
"MyScaleVMSSSetting".
Get-AzAutoscalesetting -ResourceGroup myrg1 -Name MyScaleVMSSSetting -DetailedOutput
Eliminación de una configuración de escalado automático

Puede usar el cmdlet Remove-Autoscalesetting para eliminar una configuración de escalado automático.
Remove-AzAutoscalesetting -ResourceGroup myrg1 -Name MyScaleVMSSSetting
Administración de perfiles de registro para el registro de actividades

Puede crear un perfil de registro y exportar los datos de su registro de actividades a una cuenta de
almacenamiento y configurar la retención de datos. Si lo desea, también puede transmitir los datos al Centro de
eventos. Esta característica se encuentra actualmente en la fase de vista previa y solo puede crear un perfil de
registro por suscripción. Puede utilizar los siguientes cmdlets con su suscripción actual para crear y administrar
perfiles de registro. También puede elegir una suscripción específica. Aunque PowerShell tiene como valor
predeterminado la suscripción actual, puede cambiarla cuando quiera con Set-AzContext . Puede configurar el
registro de actividades para enrutar los datos a cualquier cuenta de almacenamiento o al centro de eventos de
dicha suscripción. Los datos se escriben como archivos blob en formato JSON.
Obtención de un perfil de registro
Para capturar los perfiles de registro existentes, use el cmdlet Get-AzLogProfile .
Adición de un perfil de registro sin retención de datos
Add-AzLogProfile -Name my_log_profile_s1 -StorageAccountId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -Location
global,westus,eastus,northeurope,westeurope,eastasia,southeastasia,japaneast,japanwest,northcentralus,southcen
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia
Eliminación de un perfil de registro
Remove-AzLogProfile -name my_log_profile_s1
Adición de un perfil de registro con retención de datos

Puede especificar la propiedad -RetentionInDays con el número de días, como un entero positivo, que se
conservarán los datos.
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -Location
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia -
RetentionInDays 90
Adición de un perfil de registro retención y EventHub

Además de enrutar los datos a la cuenta de almacenamiento, también puede transmitirlos a un Centro de eventos.
En esta versión preliminar, la configuración de la cuenta de almacenamiento es obligatoria; sin embargo, la
configuración del Centro de eventos es opcional.

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -
serviceBusRuleId /subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessKey -
Location
tralus,eastus2,centralus,australiaeast,australiasoutheast,brazilsouth,centralindia,southindia,westindia -
RetentionInDays 90
Configuración de registros de diagnóstico

Muchos servicios de Azure proporcionan registros adicionales y telemetría que pueden realizar una o varias de las
siguientes acciones:
configurarse para guardar los datos en su cuenta de Azure Storage.
enviarse a Event Hubs.
enviarse a un área de trabajo de Log Analytics.
La operación solo puede realizarse en un nivel de recursos. La cuenta de almacenamiento o el centro de eventos
debe encontrarse en la misma región que el recurso de destino donde se ha ajustado la configuración de
diagnóstico.
Obtención de la configuración de diagnóstico
Get-AzDiagnosticSetting -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Logic/workflows/andy0315logicapp
Deshabilitación de la configuración de diagnóstico
Set-AzDiagnosticSetting -ResourceId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Logic/workflows/andy0315logicapp -StorageAccountId
/subscriptions/s1/resourceGroups/Default-Storage-
WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $false
Habilitación de la configuración de diagnóstico sin retención
WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $true
Habilitación la configuración de diagnóstico con retención

WestUS/providers/Microsoft.Storage/storageAccounts/mystorageaccount -Enable $true -RetentionEnabled $true -
RetentionInDays 90
Habilitación de la configuración de diagnóstico con retención para una categoría de registro específica
Set-AzDiagnosticSetting -ResourceId /subscriptions/s1/resourceGroups/insights-

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -StorageAccountId
/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/sakteststorage -Categories
NetworkSecurityGroupEvent -Enable $true -RetentionEnabled $true -RetentionInDays 90
Habilitación de la configuración de diagnóstico para Event Hubs

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -serviceBusRuleId
/subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessKey -Enable
$true
Habilitación de la configuración de diagnóstico para Log Analytics

integration/providers/Microsoft.Network/networkSecurityGroups/viruela1 -WorkspaceId
/subscriptions/s1/resourceGroups/insights-
integration/providers/providers/microsoft.operationalinsights/workspaces/myWorkspace -Enabled $true
Tenga en cuenta que la propiedad WorkspaceId usa el id. de recurso del área de trabajo. Puede obtener el
identificador de recurso de su área de trabajo de Log Analytics con el comando siguiente:
(Get-AzOperationalInsightsWorkspace).ResourceId
Estos comandos se pueden combinar para enviar datos a varios destinos.

¿Qué supervisa Azure Monitor?
En este artículo se describen las distintas aplicaciones y servicios que se supervisan mediante Azure Monitor.
Conclusiones y soluciones principales

Las conclusiones y soluciones principales se consideran parte de Azure Monitor y siguen los acuerdos de nivel
de servicio y soporte técnico de Azure. Se admiten en todas las regiones de Azure donde Azure Monitor está
disponible.
Insights proporciona una experiencia de supervisión personalizada para determinadas aplicaciones y servicios.
Recopilan y analizan tanto los registros como las métricas.
C O N C L USIÓ N DESC RIP C IÓ N
Application Insights Servicio de administración del rendimiento de aplicaciones

(APM) extensible para supervisar una aplicación web activa
en cualquier plataforma.
Azure Monitor para contenedores Supervisa el rendimiento de las cargas de trabajo de

contenedor implementadas en Azure Container Instances o
en clústeres de Kubernetes administrados hospedados en
Azure Kubernetes Service (AKS).
Azure Monitor para Cosmos DB Proporciona una vista del rendimiento general, los errores, la
capacidad y el estado operativo de todos los recursos de
Azure Cosmos DB en una experiencia interactiva unificada.
Azure Monitor para Networks (versión preliminar) Proporciona una vista completa del estado y las métricas de
todos los recursos de red. La capacidad de búsqueda
avanzada ayuda a identificar dependencias de recursos, lo
que habilita escenarios como la identificación de recursos
que hospedan el sitio web con una simple búsqueda del
nombre del sitio web.
Azure Monitor para grupos de recursos (versión preliminar) Clasifica y diagnostica cualquier problema que encuentren
sus recursos individuales, a la vez que ofrece un contexto en
cuanto al estado y el rendimiento del grupo de recursos
como un todo.
Azure Monitor para Storage Proporciona una supervisión completa de las cuentas de
Azure Storage al ofrecer una vista unificada del rendimiento,
la capacidad y la disponibilidad de los servicios de Azure
Storage.
Azure Monitor para VM Supervisa las máquinas virtuales (VM) y los conjuntos de
escalado de máquinas virtuales de Azure. El servicio analiza
el rendimiento y el estado de las VM Windows y Linux, y
supervisa sus procesos y dependencias en otros recursos y
procesos externos.
C O N C L USIÓ N DESC RIP C IÓ N
Azure Monitor para Key Vault (versión preliminar) Proporciona una supervisión completa de los almacenes de
claves proporcionando una vista unificada del rendimiento,
los errores, la latencia y las solicitudes de Key Vault.
Azure Monitor para Azure Cache for Redis (versión Proporciona una vista unificada e interactiva del rendimiento
preliminar) general, los errores, la capacidad y el mantenimiento
operativo.
Soluciones principales
Las soluciones se basan en consultas de registros y vistas personalizadas para una aplicación o servicio en
particular. Recopilan y analizan solo los registros y están cayendo en desuso a favor de las conclusiones.
SO L UC IÓ N DESC RIP C IÓ N
Estado del agente Analice el estado y la configuración de los agentes de Log

Analytics.
Administración de alertas Analice las alertas recopiladas de System Center Operations

Manager, Nagios o Zabbix.
Mapa de servicio Detecta automáticamente los componentes de la aplicación

en sistemas Windows y Linux, y asigna la comunicación entre
servicios.
Servicios de Azure
En la tabla siguiente se enumeran los servicios de Azure y los datos que estos recopilan en Azure Monitor.
Métricas: El servicio recopila automáticamente métricas en Métricas de Azure Monitor.
Registros: El servicio admite la configuración de diagnóstico que puede recopilar registros y métricas de la
plataforma para Registros de Azure Monitor.
Insight: Hay una conclusión disponible para el servicio, que proporciona una experiencia de supervisión
personalizada para el servicio.
SERVIC IO M ÉT RIC A S REGIST RO S C O N C L USIÓ N N OTA S
Active Directory No Sí Sí
Active Directory B2C No No No
Active Directory No Sí No
Domain Services
Registro de No Sí No
actividades
Protección contra No No No
amenazas avanzada
Advisor No No No
AI Builder No No No
Analysis Services Sí Sí No
API for FHIR No No No
API Management Sí Sí No
App Service Sí Sí No
AppConfig No No No
Application Gateway Sí Sí No
Servicio de No No No
atestación
Automation Sí Sí No
Azure Service No No No
Manager (RDFE)
Copia de seguridad No Sí No
Bastion No No No
Batch Sí Sí No
Batch AI No No No
Blockchain Service No Sí No
Planos técnicos No No No
Servicio de bots No No No
Cloud Services Sí Sí No Agente necesario

para supervisar los
flujos de trabajo y el
sistema operativo
invitado.
Cloud Shell No No No
Cognitive Services Sí Sí No
Azure Container Sí No No
Instances
Container Registry Sí Sí No
Content Delivery No Sí No
Network (CDN)
Cosmos DB Sí Sí Sí
Administración de No No No
costos
Data Box No No No
Data Catalog Gen2 No No No
Data Explorer Sí Sí No
Data Factory Sí Sí No
Data Factory v2 No Sí No
Recurso compartido No No No
de datos
Database for Sí Sí No
MariaDB
Database for MySQL Sí Sí No
Database for Sí Sí No
PostgreSQL
Database Migration No No No
Service
Databricks No Sí No
Protección contra Sí Sí No
DDOS
DevOps No No No
DNS Sí No No
Nombres de dominio No No No
DPS No No No
Dynamics 365 No No No
Customer
Engagement
Dynamics 365 No No No
Finance y Operations
Event Grid Sí No No
Event Hubs Sí Sí No
ExpressRoute Sí Sí No
Firewall Sí Sí No
Front Door Sí Sí No
Functions Sí Sí No
HDInsight No Sí No
HPC Cache No No No
Information No Sí No
Protection
Intune No Sí No
IoT Central No No No
IoT Hub Sí Sí No
Key Vault Sí Sí Sí
Kubernetes Service No No Sí
(AKS)
Load Balancer Sí No No
Logic Apps Sí Sí No
Machine Learning Se No No No
rvice
Aplicaciones No No No
administradas
Mapas No No No
Media Services Sí Sí No
Microsoft Flow No No No
Escritorio No No No
administrado de
Microsoft
Microsoft PowerApps No No No
Microsoft Social No No No
Engagement
Microsoft Stream Sí Sí No
Migrar No No No
Multi-Factor No Sí No
Authentication
Network Watcher Sí Sí No
Notification Hubs Sí No No
Open Datasets No No No
Directiva No No No
Power BI Embedded Sí Sí No
Private Link No No No
Plataforma de No No No
comunicación de
Project Spool
Red Hat OpenShift No No No
Redis Cache Sí Sí Sí
Gráfico de recursos No No No
Resource Manager No No No
Búsqueda minorista: No No No
por Bing
Search Sí Sí No
Azure Service Bus Sí Sí No
Service Fabric No Sí No Agente necesario

para supervisar los
sistema operativo
invitado.
Portal de suscripción No No No
Site Recovery No Sí No
Servicio Spring Cloud No No No
Azure Synapse Sí Sí No
Analytics
SQL Database Sí Sí No
SQL Server Stretch Sí Sí No

Database
Pila No No No
Storage Sí No Sí
Almacenamiento No No No
caché
Servicios de No No No
sincronización de
almacenamiento
Stream Analytics Sí Sí No
Time Series Insights Sí Sí No
TINA No No No
Traffic Manager Sí Sí No
Impresión universal No No No
Virtual Machine Scale No Sí Sí Agente necesario

Sets para supervisar los
sistema operativo
invitado.
Virtual Machines Sí Sí Sí Agente necesario

para supervisar los
sistema operativo
invitado.
Virtual Network Sí Sí Sí
Virtual Network: No Sí No
registros de flujo de
NSG
VPN Gateway Sí Sí No
Windows Virtual No No No
Desktop
Integraciones de productos
Los servicios y las soluciones de la tabla siguiente almacenan sus datos en un área de trabajo de Log Analytics
para que se puedan analizar con otros datos de registro recopilados por Azure Monitor.
P RO DUC TO O SERVIC IO DESC RIP C IÓ N
Azure Automation Administre las actualizaciones del sistema operativo y realice

un seguimiento de los cambios en equipos Windows y Linux.
Consulte Change Tracking y Update Management.
Azure Information Protection Clasifique y, opcionalmente, proteja documentos y correos

electrónicos. Consulte Informes centrales para Azure
Information Protection.
Azure Security Center Recopile y analice eventos de seguridad y complete análisis

de amenazas. Consulte Recopilación de datos en Azure
Security Center.
Azure Sentinel Se conecta a orígenes diferentes, incluido Office 365 y

Amazon Web Services CloudTrail. Consulte Conexión con
orígenes de datos.
Microsoft Intune Cree una configuración de diagnóstico para enviar registros

a Azure Monitor. Consulte Envío de datos de registro al
almacenamiento, a Event Hubs o a Log Analytics en Intune
(versión preliminar).
Red Network Performance Monitor: Supervisa la conectividad de

red y el rendimiento de los puntos de conexión de servicios
y aplicaciones.
Azure Application Gateway: Analice registros y métricas de
Azure Application Gateway.
Análisis de tráfico: Analiza los registros de flujo del grupo de
seguridad de red (NSG) de Network Watcher para
proporcionar conclusiones sobre el flujo de tráfico en la nube
de Azure.
Office 365 Supervise su entorno de Office 365. Versión actualizada con

incorporación mejorada disponible a través de Azure
Sentinel.
SQL Analytics Supervise el rendimiento de Azure SQL Database y SQL

Managed Instance a escala y entre varias suscripciones.
Surface Hub Realice un seguimiento del estado y el uso de los dispositivos

Surface Hub.
System Center Operations Manager Recopile datos de agentes de Operations Manager mediante
la conexión de su grupo de administración a Azure Monitor.
Consulte Conexión de Operations Manager con Azure
Monitor.
Evalúe el riesgo y el estado del grupo de administración de
System Center Operations Manager con la solución
Operations Manager Assessment.
Salas de Microsoft Teams Administración integrada de un extremo a otro de los

dispositivos de Salas de Microsoft Teams.
Visual Studio App Center Compile, pruebe y distribuya aplicaciones y, a continuación,

supervise su estado y uso. Consulte Comience a analizar la
aplicación móvil con App Center y Application Insights.
P RO DUC TO O SERVIC IO DESC RIP C IÓ N
Windows Windows Update Compliance: Evalúe las actualizaciones del

escritorio de Windows.
Análisis de escritorio: Se integra en Configuration Manager
para proporcionar conclusiones e inteligencia para tomar
decisiones más informadas sobre la preparación de las
actualizaciones de los clientes Windows.
Otras soluciones
Hay otras soluciones disponibles para supervisar diferentes aplicaciones y servicios, pero el desarrollo activo se
ha detenido y puede que no estén disponibles en todas las regiones. Están cubiertas por el acuerdo de nivel de
servicio de ingesta de datos de Azure Log Analytics.
Comprobación de mantenimiento de Active Directory Evalúe el riesgo y el estado de los entornos de Active
Directory.
Estado de replicación de Active Directory Supervisa periódicamente el entorno de Active Directory

para comprobar si existen errores de replicación.
Activity Log Analytics Entradas del registro de actividad de Azure.
DNS Analytics (versión preliminar) Recopila, analiza y correlaciona los registros analíticos y de
auditoría de Windows DNS y otros datos relacionados a
partir de los servidores DNS.
Cloud Foundry Recopile, vea y analice las métricas de rendimiento y estado

de sistema de Cloud Foundry entre varias implementaciones.
Contenedores Vea y administre hosts de contenedor de Docker y Windows.
Evaluaciones a petición Evalúe y optimice la disponibilidad, la seguridad y el

rendimiento de los entornos de tecnología de Microsoft
locales, híbridos y en la nube.
Comprobación de mantenimiento de SQL Evalúe el riesgo y el estado de los entornos de SQL Server.
Datos de conexión Datos consolidados de rendimiento y de red recopilados de

equipos conectados a Windows y Linux con el agente de Log
Analytics.
Integración de terceros
ITSM El Conector de Administración de servicios de TI (ITSMC) le

permite conectar Azure y un producto o servicio de
Administración de servicios de TI (ITSM) compatibles.
Recursos fuera de Azure

Azure Monitor puede recopilar datos de recursos fuera de Azure mediante los métodos que se enumeran en la
tabla siguiente.
RESO URC E M ÉTO DO
APLICACIONES Supervise las aplicaciones web fuera de Azure mediante

Application Insights. Vea ¿Qué es Application Insights?.
Máquinas virtuales Use los agentes para recopilar datos del sistema operativo
invitado de máquinas virtuales en otros entornos en la nube
o locales. Consulte Información general sobre los agentes de
Azure Monitor.
Cliente de API de REST Hay API independientes disponibles para escribir datos en
Registros y Métricas de Azure Monitor desde cualquier
cliente de API de REST. Consulte Envío de datos de registro a
Azure Monitor con HTTP Data Collector API (versión
preliminar pública) para Registros y Envío de métricas
personalizadas de un recurso de Azure al almacén de
métricas de Azure Monitor mediante la API REST para
Métricas.
Pasos siguientes
Obtenga más información sobre la plataforma de datos de Azure Monitor, que almacena los registros y las
métricas recopilados por conclusiones y soluciones.
Complete un tutorial sobre la supervisión de un recurso de Azure.
Complete un tutorial sobre la escritura de una consulta de registro para analizar datos en Registros de Azure
Monitor.
Complete un tutorial sobre la creación de un gráfico de métricas para analizar datos en Métricas de Azure
Monitor.
Supervisión continua con Azure Monitor
La supervisión continua hace referencia al proceso y la tecnología necesarios para incorporar la supervisión en
cada fase los ciclos de vida de las operaciones de TI y DevOps. Contribuye a garantizar de forma continua el
mantenimiento, el rendimiento y la fiabilidad de su aplicación e infraestructura, ya que abarca desde el desarrollo
hasta la producción. La supervisión continua se basa en los conceptos de integración continua e implementación
continua (CI/CD) que le ayudan a desarrollar y ofrecer software más rápido y de forma más fiable para
proporcionar valor continuo a sus usuarios.
Azure Monitor es la solución de supervisión unificada de Azure que proporciona observabilidad de pila completa
entre las aplicaciones y la infraestructura en la nube y el entorno local. Funciona perfectamente con Visual Studio y
Visual Studio Code durante el proceso de desarrollo y pruebas, y se integra con Azure DevOps para la
administración de versiones y la administración de elementos de trabajo durante la implementación y las
operaciones. Incluso se integra en las herramientas de ITSM y SIEM de su elección para ayudar a realizar un
seguimiento de problemas e incidentes en sus procesos de TI existentes.
En este artículo se describen pasos específicos para usar Azure Monitor y habilitar la supervisión continua en todos
sus flujos de trabajo. Incluye vínculos a otra documentación que proporciona detalles sobre la implementación de
distintas características.
Habilitación de la supervisión de todas sus aplicaciones

Para obtener observabilidad en todo su entorno, debe habilitar la supervisión en todos sus servicios y aplicaciones
web. Esto le permitirá visualizar con facilidad transacción y conexiones de un extremo a otro en todos los
componentes.
Azure DevOps Projects ofrece una experiencia simplificada con su código existente y el repositorio de Git, o
elegir una de las aplicaciones de ejemplo para crear una canalización de integración continua (CI) y entrega
continua (CD) en Azure.
La supervisión continua en su canalización de versión de DevOps le permite programar o revertir su
implementación en función de los datos de supervisión.
Monitor de estado le permite instrumentar una aplicación de .NET activa en Windows con Azure Application
Insights sin tener que modificar ni volver a implementar el código.
Si tiene acceso al código de su aplicación, habilite la supervisión completa con Application Insights instalando el
SDK de Application Insights de Azure Monitor para .NET, Java, Node.js o cualquier otro lenguaje de
programación. Esto le permite especificar eventos, métricas o vistas de página personalizados que son
pertinentes para su aplicación y su empresa.
Habilitación de la supervisión para toda su infraestructura

Las aplicaciones solo son tan fiables como su infraestructura subyacente. Tener habilitada la supervisión en toda su
infraestructura le ayudará a conseguir una observabilidad completa y facilitar la detección de una posible causa raíz
cuando se produce un error. Azure Monitor le ayuda a realizar un seguimiento del mantenimiento y el rendimiento
de toda su infraestructura híbrida, incluidos recursos como máquinas virtuales, contenedores, almacenamiento y
red.
Automáticamente obtendrá métricas de plataforma, registros de actividad y registros de diagnósticos desde la
mayoría de sus recursos de Azure sin ninguna configuración.
Habilite una supervisión más profunda de las máquinas virtuales con Azure Monitor para máquinas virtuales.
Habilite una supervisión más profunda de los clústeres de AKS con Azure Monitor para contenedores.
Agregue soluciones de supervisión para diferentes aplicaciones y servicios en su entorno.
La infraestructura como código es la administración de infraestructura en un modelo descriptivo, empleando las
mismas versiones usadas por los equipos de DevOps para el código fuente. Agrega fiabilidad y escalabilidad a su
entorno y le permite aprovechar procesos similares que solían administrar sus aplicaciones.
Use plantillas de Resource Manager para habilitar la supervisión y configurar alertas a través de un gran
conjunto de recursos.
Use Azure Policy para hacer cumplir distintas reglas a través de sus recursos. Esto garantiza que esos recursos
se mantengan compatibles con los estándares corporativos y los acuerdos de nivel de servicio.
Combinación de recursos en los grupos de recursos de Azure

Una aplicación típica en Azure hoy incluye varios recursos como máquinas virtuales y App Services o
microservicios hospedados en Cloud Services, clústeres de AKS o Service Fabric. Estas aplicaciones suelen usar
dependencias como Event Hubs, Storage, SQL y Service Bus.
Combine recursos en los grupos de recursos de Azure para obtener una visibilidad completa en todos sus
recursos que constituyen sus diversas aplicaciones. Azure Monitor para grupos de recursos proporciona una
forma sencilla de hacer un seguimiento del mantenimiento y el rendimiento de toda su aplicación de pila
completa y permite profundizar en los respectivos componentes para la realización de cualquier investigación o
depuración.
Garantía de calidad a través de la implementación continua

Tanto la integración continua como la implementación continua le permite integrar e implementar cambios de
código automáticamente en su aplicación en función de los resultados de las pruebas automatizadas. Optimiza el
proceso de implementación y garantiza la calidad de cualquier cambio antes de pasar a la fase de producción.
Use Azure Pipelines para implementar la implementación continua y automatizar todo su proceso desde la
confirmación del código hasta la producción en función de sus pruebas de CI/CD.
Use puertas de calidad para integrar la supervisión en su implementación anterior o posterior. Esto garantiza su
cumplimiento de las métricas de mantenimiento o rendimiento clave (KPI), ya que sus aplicaciones abarcan
desde el desarrollo hasta la producción, y ninguna diferencia en el entorno de infraestructura o escala afecta
negativamente a sus KPI.
Mantenga instancias de supervisión independientes entre sus diferentes entornos de implementación, por
ejemplo desarrollo, prueba, valor controlado y producto. Esto garantiza que los datos recopilados sean
pertinentes en las aplicaciones e infraestructura asociadas. Si debe poner datos en correlación entre entornos,
puede usar gráficos de varios recursos en el Explorador de métricas o crear consultas entre recursos en Azure
Monitor.
Creación de alertas accionables con acciones

Un aspecto fundamental de supervisión informa de forma proactiva a los administradores sobre los problemas
actuales y previstos.
Creación de alertas en Azure Monitor en función de los registros y las métricas para identificar los estados de
error previstos. Debe tener el objetivo de hacer que todas las alertas sean accionables, es decir, que representen
condiciones críticas reales y quieran reducir los falsos positivos. Use umbrales dinámicos para calcular
automáticamente líneas de base en datos métricos en lugar de definir sus propios umbrales estáticos.
Defina las acciones para que las alertas usen los medios más eficaces para informar a sus administradores. Las
acciones para la notificación disponibles son SMS, correos electrónicos, notificaciones push o llamadas de voz.
Use acciones más avanzadas para conectarse a su herramienta de ITSM u otros sistemas de administración de
alertas a través de webhooks.
Corrija también situaciones identificadas en alertas con runbooks de Azure Automation o Logic Apps que se
pueden iniciar a partir de una alerta con webhooks.
Use el escalado automático para aumentar y reducir de forma dinámica sus recursos de proceso en función de
las métricas recopiladas.
Preparación de paneles y libros

Garantizar que su desarrollo y operaciones tengan acceso a la misma telemetría y herramientas les permite ver
patrones en todo su entorno y minimizar sus instancias de Mean Time To Detect (MTTD) y Mean Time to Restore
(MTTR).
Prepare paneles personalizados en función de métricas y registros comunes para los diversos roles de su
organización. Los paneles pueden combinar datos a partir de todos los recursos de Azure.
Prepare libros para garantizar el uso compartido del conocimiento entre el desarrollo y las operaciones. Estos
podrían prepararse como informes dinámicos con gráficos de métricas y consultas de registro, o incluso como
guías para la solución de problemas preparadas por desarrolladores que ayudan a las operaciones o la
asistencia al cliente a afrontar los problemas básicos.
Optimización continua
La supervisión es uno de los aspectos fundamentales de la popular filosofía Build-Measure-Learn (crear, medir y
aprender), que recomienda realizar un seguimiento continuo de sus KPI y las métricas de comportamiento del
usuario y, a continuación, esforzarse por optimizarlos a través de iteraciones de planeación. Azure Monitor le ayuda
a recopilar métricas y registros pertinentes para su empresa y agregar nuevos puntos de datos en la próxima
implementación tal como se requiere.
Use herramientas en Application Insights para realizar un seguimiento de la involucración y el comportamiento
del usuario final.
Use el análisis de impacto para que le ayude a priorizar las áreas en las que debe centrarse para alcanzar los KPI
importantes.
Pasos siguientes
Obtenga información sobre los componentes de diferencia de Azure Monitor.
Agregue la supervisión continua a su canalización de versión.
Orígenes de datos de supervisión para Azure
Monitor
Azure Monitor se basa en una plataforma de datos de supervisión común que incluye registros y métricas.
La recopilación de datos en esta plataforma permite que los datos de múltiples recursos se analicen juntos
mediante un conjunto común de herramientas en Azure Monitor. Los datos de supervisión también pueden
enviarse a otras ubicaciones para admitir determinados escenarios, y algunos recursos pueden realizar
operaciones de escritura en otras ubicaciones para poder recopilarse en registros o métricas.
En este artículo se describen los diferentes orígenes de datos de datos de supervisión recopilados por
Azure Monitor además de los datos de supervisión creados por los recursos de Azure. Se proporcionan
vínculos a información detallada sobre la configuración necesaria para recopilar estos datos en diferentes
ubicaciones.
Niveles de aplicación
Los orígenes de datos de supervisión de las aplicaciones de Azure se pueden organizar en niveles. Los
niveles más altos son su propia aplicación y los niveles más bajos son componentes de la plataforma de
Azure. El método de acceso a los datos de cada nivel es variable. Los niveles de aplicación se resumen en la
tabla siguiente y los orígenes de datos de supervisión en cada nivel se presentan en las siguientes
secciones. Consulte Supervisión de ubicaciones de datos en Azure para obtener una descripción de cada
ubicación de datos y cómo puede acceder a sus datos.
Azure
La siguiente tabla describe brevemente los niveles de aplicación específicos de Azure. Siga el vínculo para
obtener más información sobre cada una de las secciones a continuación.
N IVEL DESC RIP C IÓ N M ÉTO DO DE REC O P IL A C IÓ N

Inquilino de Azure datos sobre el funcionamiento de los Vea los datos de AAD en el portal o
servicios de Azure en el nivel del configure la recopilación en o Azure
inquilino, como Azure Active Monitor mediante una configuración
Directory. de diagnóstico de inquilino.
Suscripción de Azure Datos relacionados con el estado y la Ver en el portal o configurar la

administración de los servicios entre colección para Azure Monitor
recursos en su suscripción de Azure, mediante perfil de registro.
como Resource Manager y Service
Health.
Recursos de Azure Datos sobre el funcionamiento y el Métricas recopiladas

rendimiento de cada recurso de automáticamente. Ver en el
Azure. explorador de métricas.
Configure las opciones de
diagnóstico para recopilar registros
en Azure Monitor.
Hay perspectivas y soluciones de
supervisión disponibles para realizar
una supervisión más detallada de
tipos de recursos específicos.
Azure, otra nube o local

La siguiente tabla describe brevemente los niveles de aplicación posibles en Azure, otra nube o local. Siga el
vínculo para obtener más información sobre cada una de las secciones a continuación.
Sistema operativo (invitado) Datos sobre el sistema operativo en Instalar el agente de Log Analytics
los recursos de proceso. para recopilar orígenes de datos de
cliente en Azure Monitor y
Dependency Agent para recopilar las
dependencias que admitan Azure
Monitor para VM.
Para Azure Virtual Machines, instale
la extensión de Azure Diagnostics
para recopilar registros y métricas en
Azure Monitor.
Código de aplicación Datos sobre el rendimiento y la Instrumentar el código para recopilar

funcionalidad de la aplicación y el datos en Application Insights.
código reales, incluidos los
seguimientos de rendimiento,
registros de aplicaciones y telemetría
de usuario.
Orígenes personalizados Datos de servicios externos u otros Recopilar datos de registro o métricas
componentes o dispositivos. en Azure Monitor desde cualquier
cliente REST.
Inquilino de Azure
Los datos de telemetría relacionados con el inquilino de Azure se recopilan desde los servicios de todos los
inquilinos, como Azure Active Directory.
Registros de auditoría de Azure Active Directory
Los informes de Azure Active Directory, contienen el historial de actividad de inicio de sesión y la traza de
auditoría de los cambios realizados en un inquilino determinado.
DEST IN AT IO N DESC RIP C IÓ N REF EREN C IA
Registros de Azure Monitor Configure registros de Azure AD Integración de registros de Azure AD

para que se recopilen en Azure con registros de Azure Monitor
Monitor para analizarlos con otros (versión preliminar)
datos de supervisión.
Azure Storage Exporte registros de Azure AD en Tutorial: Archivado de registros de

Azure Storage para realizar el Azure AD en una cuenta de Azure
procedimiento de archivado. Storage (versión preliminar)
Centro de eventos Transmita los registros de Azure AD a Tutorial: Streaming de los registros de
otras ubicaciones mediante Event Azure Active Directory a Azure Event
Hubs. Hubs (versión preliminar).
Suscripción de Azure
Telemetría relacionada con el estado y el funcionamiento de su suscripción de Azure.

El registro de actividad de Azure incluye registros de Service Health, además de registros sobre los cambios
de configuración aplicados a los recursos en su suscripción de Azure. El registro de actividad está disponible
para todos los recursos de Azure y representa su vista externa.
Registro de actividades El registro de actividad se recopila en Consulta del registro de actividad de

su propio almacén de datos, que Azure en Azure Portal
puede ver en el menú de Azure
Monitor o utilizar para crear alertas
de registro de actividad.
Registros de Azure Monitor Configure los registros de Azure Recopilación y análisis de los registros
Monitor para que recopilen el de actividad de Azure en un área de
registro de actividad para analizarlo trabajo de Log Analytics en Azure
con otros datos de supervisión. Monitor
Azure Storage Exporte el registro de actividad en Archivo del registro de actividad

Azure Storage para realizar el
procedimiento de archivado.
Event Hubs Transmita el registros de actividad a Transmisión del registro de actividad

otras ubicaciones mediante Event al centro de eventos.
Hubs.
Azure Service Health

Azure Service Health proporciona información sobre el estado de los servicios de Azure de la suscripción
de los que dependen la aplicación y los recursos.
Registro de actividades Los registros de Service Health se Visualización de notificaciones de

Registros de Azure Monitor almacenan en el registro de actividad mantenimiento del servicio mediante
de Azure, por lo que puede verlos en Azure Portal
Azure Portal o realizar otras
actividades que permita el registro
de actividad.
Recursos de Azure
Los registros de métricas y recursos proporcionan información sobre el funcionamiento interno de los
recursos de Azure. Están disponibles para la mayoría de servicios de Azure, y las perspectivas y soluciones
de administración proporcionan datos adicionales para determinados servicios.
Métricas de la plataforma
La mayoría de los servicios de Azure generarán métricas de plataforma que reflejan su rendimiento y
funcionamiento directamente en la base de datos de métricas. Las métricas específicas varían en función del
tipo de recurso.
Métricas de Azure Monitor Las métricas de la plataforma se Introducción al Explorador de

escribirán en la base de datos de métricas de Azure
métricas de Azure Monitor sin Métricas compatibles con Azure
ninguna configuración. Acceda a las Monitor
métricas de la plataforma del
Explorador de métricas.
Registros de Azure Monitor Copie las métricas de la plataforma Diagnósticos de Azure Diagnostics
en los registros para las tendencias y directos a Log Analytics
otros análisis con Log Analytics.
Event Hubs Transmita métricas a otras Flujo de datos de supervisión de

ubicaciones mediante Event Hubs. Azure a un centro de eventos para
que lo consuma una herramienta
externa
Registros del recurso

Los registros de recursos proporcionan información detallada sobre el funcionamiento interno de un
recurso de Azure. Los registros de recursos se crean automáticamente, pero debe crear una configuración
de diagnóstico para especificar un destino para que se recopilen de cada recurso.
Los requisitos de configuración y el contenido de los registros de recursos varían según el tipo de recurso, y
no todos los servicios los crean. Consulte Servicios, esquemas y categorías admitidos en los registros de
recursos de Azure para más información sobre los servicios y obtener vínculos a los procedimientos de
configuración detallados. Si el servicio no aparece en este artículo, significa que se servicio no crea
actualmente registros de recursos.
Registros de Azure Monitor Envíe registros de recursos a Recopilación de registros de recursos

registros de Azure Monitor para el de Azure en el área de trabajo de Log
análisis con otros datos de registro Analytics en Azure Monitor
recopilados.
Storage Envíe registros de recursos a Azure Archivado de registros de recursos

Storage para archivarlos. de Azure
Event Hubs Transmita registros de recursos a Transmisión de registros de recursos

otras ubicaciones mediante Event de Azure a un centro de eventos
Hubs.
Sistema operativo (invitado)

Los recursos de proceso en Azure, en otras nubes y en el entorno local tienen un sistema operativo invitado
para supervisar. Con la instalación de uno o más agentes, puede recopilar datos de telemetría del invitado
en Azure Monitor para analizarlos con las mismas herramientas de supervisión que los propios servicios de
Azure.
Extensión de diagnóstico de Azure
La habilitación de la extensión de Azure Diagnostics para Azure Virtual Machines le permite recopilar
registros y métricas del sistema operativo invitado de recursos de proceso, incluidos los roles web y de
trabajo de Azure Cloud Services (clásico), Virtual Machines, conjuntos de escalado de máquinas virtuales y
Service Fabric.
Storage La extensión Azure Diagnostics Instalación y configuración de la

almacena los datos en una cuenta de extensión Azure Diagnostics (WAD)
Azure Storage. para Windows
Uso de la extensión Diagnostics de
Linux para supervisar métricas y
registros
Métricas de Azure Monitor Cuando configure la extensión de Envío de métricas de SO invitado al

Diagnostics para recopilar los almacén de métricas de Azure
contadores de rendimiento, se Monitor con una plantilla de
escribirán en la base de datos de Resource Manager para una máquina
métricas de Azure Monitor. virtual Windows
Event Hubs Configure la extensión de Transmisión de datos de Azure

Diagnostics para transmitir los datos Diagnostics a Event Hubs
a otras ubicaciones mediante Event Uso de la extensión Diagnostics de
Hubs. Linux para supervisar métricas y
registros
Registros de Application Insights Recopile registros y contadores de Envío de datos de diagnóstico de

rendimiento a partir del recurso de Cloud Services, Virtual Machines o
proceso que admite su aplicación Service Fabric a Application Insights
para el análisis con otros datos de
aplicación.

Instale el agente de Log Analytics para la supervisión y administración completas de las máquinas virtuales
de Windows y Linux. La máquina virtual se puede ejecutar en Azure, en otra nube o en el entorno local.
Registros de Azure Monitor El agente de Log Analytics se conecta Orígenes de datos de agente en
a Azure Monitor directamente o a Azure Monitor
través de System Center Operations Conexión de Operations Manager
Manager y le permite recopilar datos con Azure Monitor
desde orígenes de datos que
configura o desde soluciones de
supervisión que proporcionan
perspectivas adicionales en
aplicaciones que se ejecutan en la
máquina virtual.
Almacenamiento de máquinas Azure Monitor para VM usa el

virtuales agente de Log Analytics para
almacenar la información de estado
de mantenimiento en una ubicación
personalizada. Consulte la siguiente
sección para más información.

Azure Monitor para VM ofrece una experiencia de supervisión personalizada para máquinas virtuales que
proporciona características más allá de la funcionalidad de Azure Monitor principal. Requiere Dependency
Agent en las máquinas virtuales de Windows y Linux que se integra con el agente de Log Analytics para
recopilar datos detectados acerca de los procesos que se ejecutan en la máquina virtual y en las
dependencias de procesos externos.
Registros de Azure Monitor Almacena los datos sobre los Uso de la asignación de Azure
procesos y dependencias en el Monitor para VM (versión preliminar)
agente. para conocer los componentes de
una aplicación
Código de aplicación
Se realiza la supervisión detallada de la aplicación en Azure Monitor con Application Insights, que recopila
datos de aplicaciones que se ejecutan en una variedad de plataformas. La aplicación se puede ejecutar en
Azure, en otra nube o en el entorno local.
Datos de aplicación
Cuando se habilita Application Insights para una aplicación mediante la instalación de un paquete de
instrumentación, recopila métricas y registros relacionados con el rendimiento y el funcionamiento de la
aplicación. Application Insights almacena los datos que recopila en la misma plataforma de datos de Azure
Monitor que utilizan otros orígenes de datos. Incluye completas herramientas para analizar estos datos,
pero también puede analizarlos con datos de otros orígenes mediante herramientas como el Explorador de
métricas y Log Analytics.
Registros de Azure Monitor Datos operativos sobre la aplicación, Análisis de datos de registro en
como vistas de página, las solicitudes Azure Monitor
de aplicación, excepciones y
seguimientos.
Información de dependencia entre Correlación de telemetría en

los componentes de aplicación para Application Insights
admitir la asignación de aplicaciones Mapa de aplicación
y la correlación de telemetría.
Resultados de las pruebas de Supervisión de la disponibilidad y la

disponibilidad que permiten probar capacidad de respuesta de cualquier
la disponibilidad y capacidad de sitio web
respuesta de la aplicación desde
diferentes ubicaciones de la red
Internet pública.
Métricas de Azure Monitor Application Insights recopila las Métricas agregadas previamente y
métricas que describen el basadas en registros en Application
rendimiento y el funcionamiento de Insights
la aplicación, además de las métricas API de Application Insights para
personalizadas que define en la eventos y métricas personalizados
aplicación en la base de datos de
métricas de Azure Monitor.
Azure Storage Envíe datos de aplicación a Azure Exportación de datos de telemetría

Storage para el procedimiento de desde Application Insights
archivado.
Los detalles de las pruebas de Supervisión de la disponibilidad y la

disponibilidad se almacenan en Azure capacidad de respuesta de cualquier
Storage. Utilice Application Insights sitio web
en Azure Portal para descargar los
análisis locales. Los resultados de las
pruebas de disponibilidad se
almacenan en los registros de Azure
Monitor.
Los datos de seguimiento del Generación de perfiles de

generador de perfiles se almacenan aplicaciones de producción en Azure
en Azure Storage. Utilice Application con Application Insights
Insights en Azure Portal para
descargar los análisis locales.
Los datos de instantáneas de Funcionamiento de las instantáneas

depuración capturados para un
subconjunto de excepciones se
almacenan en Azure Storage. Utilice
Application Insights en Azure Portal
para descargar los análisis locales.
Soluciones de supervisión y perspectivas
Las soluciones de supervisión y perspectivas recopilan datos para proporcionar conclusiones sobre el
funcionamiento de un servicio o aplicación determinados. Pueden abordar recursos en diferentes niveles de
aplicación e incluso varios niveles.
Soluciones de supervisión
Registros de Azure Monitor Las soluciones de supervisión Detalles de la recopilación de datos

recopilan datos en registros de Azure para las soluciones de supervisión en
Monitor, donde se pueden analizar Azure
mediante un lenguaje de consulta o
vistas que se suelen incluir en la
solución.

Azure Monitor para contenedores proporciona una experiencia de supervisión personalizada para Azure
Kubernetes Service (AKS). Recopila los datos adicionales sobre estos recursos que se describen en la tabla
siguiente.
Registros de Azure Monitor Almacena datos de supervisión para Comprender el rendimiento del
AKS, como inventario, registros y clúster de AKS con Azure Monitor
eventos. Los datos de métrica para contenedores
también se almacenan en los
registros para poder aprovechar su
funcionalidad de análisis en el portal.
Métricas de Azure Monitor Los datos de métricas se almacenan Visualización de métricas del
en la base de datos de métricas para contenedor en el Explorador de
favorecer la visualización y las alertas. métricas
Azure Kubernetes Service Proporciona acceso directo a los Visualización de registros de

registros de contenedor de Azure Kubernetes, eventos y métricas de
Kubernetes Service (AKS) pod en tiempo real
(stdout/stderror), eventos y métricas
de pod en el portal.

Azure Monitor para VM proporciona una experiencia personalizada para la supervisión de máquinas
virtuales. Se incluye una descripción de los datos recopilados por Azure Monitor para VM en la sección
Sistema operativo (invitado) anterior.
Orígenes personalizados
Además de los niveles estándar de una aplicación, puede que necesite supervisar otros recursos que tengan
datos de telemetría y que no puedan recopilarse con los otros orígenes de datos. Para estos recursos,
escriba estos datos en las métricas o los registros mediante la API de Azure Monitor.
DEST IN AT IO N M ÉTO DO DESC RIP C IÓ N REF EREN C IA
Registros de Azure API de recopilador de Recopile datos de registro Envío de datos de registro
Monitor datos desde cualquier cliente a Azure Monitor con HTTP
REST y almacénelos en el Data Collector API (versión
área de trabajo de Log preliminar pública)
Analytics.
Métricas de Azure Monitor API de métricas Recopile datos de métricas Envío de métricas
personalizadas desde cualquier cliente personalizadas de un
REST y almacénelos en la recurso de Azure al
base de datos de métricas almacén de métricas de
de Azure Monitor. Azure Monitor mediante la
API REST
Otros servicios
Otros servicios de Azure escriben datos en la plataforma de datos de Azure Monitor. Esto le permite analizar
los datos reunidos por estos servicios con los datos recopilados por Azure Monitor y aprovechar las
mismas herramientas de visualización y análisis.
SERVIC IO DEST IN AT IO N DESC RIP C IÓ N REF EREN C IA
Azure Security Center Registros de Azure Azure Security Center Recopilación de datos en
Monitor almacena los datos de Azure Security Center
seguridad que recopila en
el área de trabajo de Log
Analytics, que permite que
estos se analicen con otros
datos de registro
recopilados por Azure
Monitor.
Azure Sentinel Registros de Azure Azure Sentinel almacena Conexión con orígenes de
Monitor los datos que recopila a datos
partir de diferentes
orígenes de datos en el
área de trabajo de Log
Analytics, que permite que
estos se analicen con otros
datos de registro
recopilados por Azure
Monitor.
Pasos siguientes
Más información sobre la tipos de datos de supervisión recopilados por Azure Monitor y cómo ver y
analizar estos datos.
Enumere las distintas ubicaciones en las que los recursos de Azure almacenan datos y cómo acceder a
ellos.
Plataforma de datos de Azure Monitor
Para permitir visibilidad entre los entornos informáticos complejos actuales que ejecutan aplicaciones
distribuidas que se basan tanto en servicios en la nube como locales, se requiere la recopilación de
datos operativos de todas las capas y todos los componentes del sistema distribuido. Es necesario poder
extraer información detallada de estos datos y consolidarla en una única vista con distintas perspectivas
para respaldar a la ingente cantidad de partes interesadas de su organización.
Azure Monitor recopila datos de diversos orígenes y los agrega a una plataforma de datos común que
puede usarse para el análisis, la visualización y la alerta. Esta plataforma proporciona una experiencia
coherente basada en los datos de varios orígenes, que le ofrece información detallada de todos los
recursos supervisados e incluso con datos de otros servicios que almacenan sus datos en Azure
Monitor.
Datos de visibilidad en Azure Monitor

Las métricas, los registros y los seguimientos distribuidos se consideran comúnmente los tres pilares de
la visibilidad. Estos son los diferentes tipos de datos que debe recopilar y analizar una herramienta de
supervisión con el fin de proporcionar suficiente visibilidad sobre un sistema supervisado. Para
conseguir visibilidad, se pueden correlacionar los datos de varios pilares y agregar los datos de todo el
conjunto de recursos objeto de supervisión. Como Azure Monitor almacena juntos datos de varios
orígenes, los datos se pueden correlacionar y analizar mediante un conjunto común de herramientas.
También se correlacionan datos de varias suscripciones e inquilinos de Azure, además de hospedarse
datos de otros servicios.
Los recursos de Azure generan una cantidad importante de datos de supervisión. Azure Monitor
consolida estos datos junto con los datos de supervisión procedentes de otros orígenes en una
plataforma de métricas o de registros. Cada una está optimizado para unos escenarios de supervisión
determinados, y cada una admite diferentes características de Azure Monitor. Características como
análisis de datos, visualizaciones o alertas requieren que comprenda las diferencias para que puedan
implementar el escenario necesario de la manera más eficaz y rentable. Las conclusiones en Azure
Monitor, como Application Insights o Azure Monitor para VM disponen de herramientas de análisis que
le permiten centrarse en el escenario de supervisión determinado sin necesidad de comprender las
diferencias entre los dos tipos de datos.
Métricas
Las métricas son valores numéricos que describen algún aspecto de un sistema en un momento dado.
Se recopilan a intervalos regulares y se identifican con una marca de tiempo, un nombre, un valor y una
o más etiquetas de definición. Las métricas se pueden agregar con diversos algoritmos, en comparación
con otras métricas, y analizarse para ver las tendencias con el paso del tiempo.
Las métricas en Azure Monitor se almacenan en una base de datos de serie temporal que está
optimizada para el análisis de los datos con marca de tiempo. Esta situación hace que las métricas sean
especialmente adecuadas para la alerta y la detección rápida de problemas. Pueden indicar cómo
funciona el sistema, pero normalmente deben combinarse con registros para identificar la causa raíz de
los problemas.
Hay métricas disponibles para análisis interactivos en Azure Portal con el Explorador de métricas. Se
pueden agregar a un panel de Azure para su visualización en combinación con otros datos y usarse para
la alerta en tiempo real.
Conozca más sobre las métricas de Azure Monitor, incluidos sus orígenes de datos en Métricas en Azure
Monitor.
Registros
Los registros son eventos que se produjeron dentro del sistema. Pueden contener diferentes tipos de
datos y pueden estar estructurados o tener texto de formato libre con una marca de tiempo. Se pueden
crear esporádicamente como eventos en las entradas de registro de generación del entorno, y un
sistema con mucha carga normalmente genera más volumen de registro.
Los registros de Azure Monitor se almacenan en un área de trabajo de Log Analytics basado en Azure
Data Explorer que proporciona un motor de análisis eficaz y un lenguaje de consulta completo. Los
registros normalmente proporcionan información suficiente para ofrecer un contexto completo del
problema identificado y son valiosos para identificar la causa de los problemas.
NOTE
Es importante distinguir entre registros de Azure Monitor y orígenes de datos de registro de Azure. Por ejemplo,
los eventos de nivel de suscripción de Azure se escriben en un registro de actividad que puede verse en el menú
de Azure Monitor. La mayoría de los recursos escriben información operativa en un registro de recursos que se
puede reenviar a distintas ubicaciones. Los registros de Azure Monitor son una plataforma de datos de registro
que recopila los registros de actividad y los registros de recursos, junto con otros datos de supervisión, para
proporcionar un análisis profundo de todo el conjunto de recursos.
Puede trabajar con consultas de registro de manera interactiva con Log Analytics en Azure Portal o
agregar los resultados a un panel de Azure para su visualización en combinación con otros datos.
También puede crear alertas de registro, que desencadenarán una alerta según los resultados de una
consulta de programación.
Aprenda más sobre los registros de Azure Monitor, como sus orígenes de datos en Registros en Azure
Monitor.
Seguimientos distribuidos
Los seguimientos son series de eventos relacionados que siguen la solicitud de un usuario por un
sistema distribuido. Pueden usarse para determinar el comportamiento del código de aplicación y el
rendimiento de diferentes transacciones. Aunque con frecuencia los registros se crearán mediante
componentes individuales de un sistema distribuido, un seguimiento mide el funcionamiento y el
rendimiento de la aplicación en todo el conjunto de componentes.
El seguimiento distribuido en Azure Monitor se habilita con el SDK de Application Insights, y los datos
de seguimiento se almacenan con otros datos de registro de aplicaciones recopilados por Application
Insights. De esta forma están disponibles para las mismas herramientas de análisis que otros datos de
registro, como consultas de registros, paneles y alertas.
Aprenda más sobre el seguimiento distribuido en What ' s seguimiento distribuido? (¿Qué es el
seguimiento distribuido?).
Comparación de las métricas y los registros de Azure Monitor

En la tabla siguiente se comparan las métricas y los registros de Azure Monitor.
AT RIB UTO M ÉT RIC A S REGIST RO S
Ventajas Ligero y capaz de escenarios casi en Analizado con lenguaje de consulta

tiempo real, como la alerta. Ideal enriquecido. Ideal para análisis
para la detección rápida de profundo e identificación de la
problemas. causa principal.
data Solo valores numéricos Datos numéricos o texto
Estructura Conjunto estándar de propiedades, Conjunto único de propiedades que

como el tiempo de muestra, el dependen del tipo de registro.
recurso supervisado, un valor
numérico. Algunas métricas
incluyen varias dimensiones para
una mejor definición.
Colección Se recopila a intervalos regulares. Se pueden recopilar

esporádicamente cuando los
eventos desencadenan un registro
que se va a crear.
Ver en Azure Portal Explorador de métricas Log Analytics
Inclusión de orígenes de datos Métricas de la plataforma Registros de aplicaciones y recursos.

recopiladas de recursos de Azure. Soluciones de supervisión.
Aplicaciones supervisadas por Agentes y extensiones de máquina
Application Insights. virtual.
Personalización definida por la Solicitudes y excepciones de
aplicación o API. aplicación.
Azure Security Center.
API de recopilador de datos.
Recopilación de datos de supervisión

Diferentes orígenes de datos de Azure Monitor escribirán en un área de trabajo de Log Analytics
(registros), en la base de datos de métricas de Azure Monitor (métricas), o en ambos. Algunos orígenes
escribirán directamente en estos almacenes de datos, mientras que otros pueden escribir en otra
ubicación, como almacenamiento de Azure, y requieren algo de configuración para rellenar los registros
o las métricas.
Consulte Métricas en Azure Monitor y Registros en Azure Monitor para obtener una lista de diferentes
orígenes de datos que rellenan cada tipo.
Hacer streaming de datos a sistemas externos
Además de usar las herramientas de Azure para analizar datos de supervisión, es posible que necesite
reenviarlos a una herramienta externa, como un producto de administración de eventos e información
de seguridad (SIEM). Este reenvío normalmente se realiza directamente desde los recursos supervisados
a través de Azure Event Hubs. Algunos orígenes pueden configurarse para enviar datos directamente a
un centro de eventos, aunque se puede usar otro proceso, como una aplicación lógica, para recuperar
los datos necesarios. Consulte Flujo de datos de supervisión de Azure a un centro de eventos para que
lo consuma una herramienta externa para más información.
Pasos siguientes
Para más información, consulte Métricas en Azure Monitor.
Para más información, consulte Registros en Azure Monitor.
Obtenga información sobre la supervisión de datos disponible para diferentes recursos en Azure.
Ubicaciones de datos de supervisión en Azure
Monitor
Azure Monitor se basa en una plataforma de datos de Registros y Métricas, tal como se describe en la plataforma
de datos de Azure Monitor. Sin embargo, los datos de supervisión de recursos de Azure se pueden escribirse en
otras ubicaciones, ya sea antes de copiarlos en Azure Monitor o para admitir escenarios adicionales.
Ubicaciones de datos de supervisión

En la siguiente tabla se identifican las diferentes ubicaciones de Azure a las que se envían datos de supervisión y
los distintos métodos para tener acceso a estos.
LO C AT IO N DESC RIP C IÓ N M ÉTO DO S DE A C C ESO
Métricas de Azure Monitor Base de datos de serie temporal que Explorador de métricas
está optimizada para el análisis de los API de métricas de Azure Monitor
datos con marca de tiempo.
Registros de Azure Monitor Área de trabajo de Log Analytics Log Analytics

basada en Azure Data Explorer que API de Log Analytics
proporciona un motor de análisis eficaz API de Application Insights
y un lenguaje de consulta completo.
Registro de actividades Los datos del registro de actividades Azure Portal

son muy útiles cuando se envían a API de eventos de Azure Monitor
registros de Azure Monitor para
analizarlos con otros datos, pero
también se recopilan por separado de
manera que se pueden ver
directamente en Azure Portal.
Azure Storage Algunos orígenes de datos escribirán Storage Analytics

directamente en Azure Storage y Explorador de servidores
requieren una configuración para Explorador de Storage
mover datos a registros. También puede
enviar datos a Azure Storage para
archivado e integración con sistemas
externos.
Event Hubs Envíe datos a Azure Event Hubs para Captura en almacenamiento
transmitirlos a otras ubicaciones.
Azure Monitor para máquinas virtuales Azure Monitor para VM almacena Azure Portal
datos de estado de carga de trabajo en API REST de monitor de carga de
una ubicación personalizada que su trabajo
experiencia de supervisión usa en Azure API REST de Azure Resource Health
Portal.
Alertas Alertas creadas por Azure Monitor. Azure Portal

API REST de administración de alertas
Pasos siguientes
Vea las diferentes fuentes de datos de supervisión que recopila Azure Monitor.
Más información sobre la tipos de datos de supervisión recopilados por Azure Monitor y cómo ver y analizar
estos datos.
Métricas en Azure Monitor
NOTE
La plataforma de datos de Azure Monitor se basa en dos tipos de datos fundamentales: métricas y registros.
En este artículo se describen las métricas. Consulte Registros en Azure Monitor para obtener una descripción
detallada de los registros y Plataforma de datos de Azure Monitor para ver una comparación de ambos.
Las métricas en Azure Monitor son ligeras y capaces de admitir escenarios casi en tiempo real, lo que
hace que sean especialmente útiles para las alertas y una detección rápida de problemas. En este
artículo se describe cómo se estructuran las métricas, qué se puede hacer con ellas y se identifican
diferentes orígenes de datos que almacenan datos en las métricas.
¿Qué son las métricas?

Las métricas son valores numéricos que describen algunos aspectos de un sistema en un momento
dado. Las métricas se recopilan en intervalos regulares y son útiles para las alertas, dado que se
pueden muestrear con frecuencia y se puede activar una alerta con rapidez con una lógica
relativamente sencilla.
¿Qué puede hacer con las métricas de Azure Monitor?

En la tabla siguiente se enumeran las distintas formas en que se pueden usar datos de métricas en
Azure Monitor.
DESC RIP C IÓ N
Análisis Use el Explorador de métricas para analizar las

métricas recopiladas en un gráfico y compare las
métricas de diferentes recursos.
Visualizar Ancle un gráfico del Explorador de métricas en un

panel de Azure.
Cree un libro para combinar con varios conjuntos de
datos en un informe interactivo. Exporte los
resultados de una consulta a Grafana para aprovechar
sus paneles y combinarlos con otros orígenes de
datos.
Aler ta Configure una regla de alertas de métricas que envíe

una notificación o realice una acción automatizada
cuando el valor de la métrica cruce un umbral.
Automatización Use la escalabilidad automática para aumentar o

disminuir los recursos según un valor de métrica que
cruce un umbral.
DESC RIP C IÓ N
Expor tarar Redirija las métricas a los registros para analizar los
datos en las métricas en Microsoft Azure junto con los
datos en los registros de Azure Monitor y para
almacenar los valores de las métricas durante un
período superior a 93 días.
Haga streaming de métricas a un centro de eventos
para redirigirlas a sistemas externos.
Recuperar Obtenga acceso a los valores de métricas desde una

línea de comandos mediante cmdlets de PowerShell.
Obtenga acceso a los valores de métricas de
aplicaciones personalizadas con API REST.
Obtenga acceso a los valores de métricas desde una
línea de comandos mediante la CLI.
Archivar Archivar el historial de rendimiento o estado del

recurso para fines de cumplimiento, auditoría o
creación de informes sin conexión.
¿Cómo se estructuran los datos de métricas de Azure Monitor?

Los datos recopilados por las métricas en Azure Monitor se almacenan en una base de datos de serie
temporal que está optimizada para el análisis de los datos con marca de tiempo. Cada conjunto de
valores de métricas es una serie temporal con las siguientes propiedades:
Hora en que se recopiló el valor.
Recurso al que el valor está asociado.
Espacio de nombres que actúa como una categoría para la métrica.
Nombre de la métrica.
El propio valor.
Algunas métricas pueden tener varias dimensiones, como se describe en la sección Métricas
multidimensionales. Las métricas personalizadas pueden tener hasta 10 dimensiones.
Métricas multidimensionales
Uno de los desafíos de los datos de métricas es que a menudo tienen información limitada para
proporcionar contexto para los valores recopilados. Azure Monitor aborda este desafío con métricas
multidimensionales. Las dimensiones de una métrica son pares nombre-valor que transportan datos
adicionales para describir el valor de la métrica. Por ejemplo, una métrica Espacio disponible en disco
puede tener una dimensión denominada Unidad con los valores C: o D: , que permitiría ver cualquier
espacio disponible en disco de todas las unidades o de cada unidad individual.
En el ejemplo siguiente se muestran dos conjuntos de datos para una métrica hipotética
denominada Rendimiento de la red. El primer conjunto de datos no tiene ninguna dimensión. El
segundo conjunto de datos muestra los valores con dos dimensiones, Dirección IP y Dirección:
Rendimiento de la red
T IM ESTA M P VA LO R DE M ÉT RIC A
9/8/2017 8:14 1331,8 Kbps
9/8/2017 8:15 1141,4 Kbps

T IM ESTA M P VA LO R DE M ÉT RIC A
9/8/2017 8:16 1110,2 Kbps
Esta métrica no dimensional solo puede responder una pregunta básica, como “¿cuál era el
rendimiento de la red en un momento dado?”.
Rendimiento de la red + dos dimensiones (“IP” y “Dirección”)
DIM EN SIÓ N
T IM ESTA M P DIM EN SIÓ N “ IP ” “ DIREC C IÓ N ” VA LO R DE M ÉT RIC A
9/8/2017 8:14 IP="192.168.5.2" Dirección="Envío" 646,5 Kbps
9/8/2017 8:14 IP="192.168.5.2" Dirección="Recepción" 420,1 Kbps
Esta métrica puede responder a preguntas como “¿cuál era el rendimiento de la red para cada
dirección IP?” y “¿cuántos datos se enviaron en comparación los datos que se recibieron?”. Las
métricas multidimensionales llevan valores analíticos y de diagnóstico adicionales en comparación
con las métricas no dimensionales.
Interactuar con las métricas de Azure Monitor

Use el Explorador de métricas para analizar de forma interactiva los datos en la base de datos de
métricas y representar los valores de varias métricas con el tiempo. Puede anclar los gráficos a un
panel para verlos con otras visualizaciones. También puede recuperar las métricas con la API REST de
supervisión de Azure.
Orígenes de métricas de Azure Monitor
Las métricas que Azure Monitor recopila proceden de tres orígenes fundamentales. Una vez que
estas métricas se recopilan en la base de datos de métricas de Azure Monitor, se pueden evaluar
juntas independientemente de su origen.
Las métricas de plataforma se crean mediante los recursos de Azure y brindan visibilidad sobre
su estado y rendimiento. Cada tipo de recurso crea un conjunto distinto de métricas sin ninguna
configuración necesaria. Las métricas de plataforma se recopilan de los recursos de Azure con una
frecuencia de un minuto, a menos que se especifique lo contrario en la definición de la métrica.
Las métricas de SO invitado se recopilan desde el sistema operativo invitado de una máquina
virtual. Habilite las métricas de SO invitado para máquinas virtuales Windows con la extensión de
diagnóstico de Windows (WAD) y para las máquinas virtuales Linux con el agente de InfluxData
Telegraf.
Las métricas de aplicación se crean mediante Application Insights para sus aplicaciones
supervisadas y le ayudan a detectar problemas de rendimiento y a realizar un seguimiento de las
tendencias de uso de la aplicación. Incluye valores como Tiempo de respuesta del servidor y
Excepciones del explorador.
Las métricas personalizadas son métricas que se definen además de las métricas estándar que
están disponibles automáticamente. También puede definir métricas personalizadas en la aplicación
que se supervisa mediante Application Insights o crear métricas personalizadas para un servicio de
Azure con la API de métricas personalizadas.
Retención de métricas
Para la mayoría de los recursos en Azure, las métricas se almacenan durante 93 días. Hay algunas
excepciones:
Métricas de SO invitado
Métricas clásicas de SO invitado . Estos son los contadores de rendimiento que recopila la
extensión de diagnóstico de Windows (WAD) o la extensión de diagnóstico de Linux (LAD) y que
se enrutan a una cuenta de almacenamiento de Azure. La retención de estas métricas es de 14
días.
Métricas de SO invitado enviadas a las métricas de Azure Monitor . Estos son los
contadores de rendimiento recopilados por Windows Diagnostic Extension (WAD) que se envían
al receptor de datos de Azure Monitor o que se envían mediante el Agente de InfluxData Telegraf
en las máquinas Linux. La retención de estas métricas es de 93 días.
Métricas de SO invitado que recopila el agente de Log Analytics . Estos son contadores
de rendimiento que recopila el agente de Log Analytics y que se envían a un área de trabajo de
Log Analytics. La retención de estas métricas es de 31 días y se puede ampliar a un máximo de 2
años.
Métricas basadas en registros de Application Insights .
Entre bastidores, las métricas basadas en registros se traducen en consultas de registros. Su
retención coincide con la retención de eventos en registros subyacentes. Para los recursos de
Application Insights, los registros se almacenan durante 90 días.
NOTE
También puede enviar métricas de plataforma para recursos de Azure Monitor a un área de trabajo de Log
Analytics para tendencias a largo plazo.
Pasos siguientes
Más información sobre la plataforma de datos de Azure Monitor.
Más información sobre los datos de registro en Azure Monitor.
Registros en Azure Monitor
NOTE
Todos los datos recopilados por Azure Monitor pueden clasificarse como uno de los dos tipos
fundamentales: métricas y registros. En este artículo se describen los registros. Consulte Métricas en Azure
Monitor para obtener una descripción detallada de las métricas y Monitoring data collected by Azure
Monitor (Supervisión de los datos recopilados por Azure Monitor) para ver una comparación de ambos.
Los registros en Azure Monitor son especialmente útiles para llevar a cabo un análisis complejo de
datos procedentes de orígenes diversos. En este artículo se describe cómo se estructuran los
registros en Azure Monitor y qué se puede hacer con los datos, y se identifican los diferentes
orígenes de datos que almacenan datos en los registros.
NOTE
Es importante distinguir entre registros de Azure Monitor y orígenes de datos de registro de Azure. Por
ejemplo, los eventos de nivel de suscripción de Azure se escriben en un registro de actividad que puede
verse en el menú de Azure Monitor. La mayoría de los recursos escriben información operativa en un
registro de recursos que se puede reenviar a distintas ubicaciones. Los registros de Azure Monitor son una
plataforma de datos de registro que recopila los registros de actividad y los registros de recursos, junto con
otros datos de supervisión, para proporcionar un análisis profundo de todo el conjunto de recursos.
¿Qué son los registros de Azure Monitor?

Los registros de Azure Monitor contienen distintos tipos de datos organizados en registros, donde
cada tipo tiene diferentes conjuntos de propiedades. Los registros pueden contener valores
numéricos, como métricas de Azure Monitor, pero normalmente contienen datos de texto con
descripciones detalladas. Se diferencian aún más de los datos de las métricas en que varían en
cuanto a su estructura y a menudo no se recopilan a intervalos regulares. Los datos de telemetría,
como los eventos y los seguimientos, se almacenan como registros de Azure Monitor junto con los
datos de rendimiento para poder analizarlos de forma combinada.
Un tipo común de entrada de registro es un evento. Los eventos se recopilan de forma esporádica.
Una aplicación o servicio los crea, y suelen incluir suficiente información para proporcionar un
contexto completo por sí solos. Por ejemplo, un evento puede indicar que se creó o modificó un
recurso determinado, se inició un nuevo host en respuesta a un aumento de tráfico o se detectó un
error en una aplicación.
Dado que el formato de los datos puede variar, las aplicaciones pueden crear registros
personalizados con la estructura que necesiten. Los datos de métricas se pueden almacenar incluso
en registros para combinarlos con otros datos de supervisión para tendencias y otros análisis de
datos.
¿Qué puede hacer con los registros de Azure Monitor?

En la tabla siguiente se enumeran las distintas formas en que se pueden usar los registros en Azure
Monitor.
DESC RIP C IÓ N
Análisis Use Log Analytics en Azure Portal para escribir

consultas de registros y analizar los datos de registro
de forma interactiva mediante el potente motor de
análisis de Data Explorer.
Use la consola de análisis de Application Insights en
Azure Portal para escribir consultas de registros y
analizar de forma interactiva los datos de registro
desde Application Insights.
Visualizar Ancle los resultados representados como tablas o

gráficos a un panel de Azure.
Cree un libro para combinar con varios conjuntos de
datos en un informe interactivo.
Exportar los resultados de una consulta a Power BI
para usar diferentes visualizaciones y compartirlos con
usuarios fuera de Azure.
Exporte los resultados de una consulta a Grafana para
aprovechar sus paneles y combinar con otros
orígenes de datos.
Aler ta Configurar un regla de alerta de registro que envíe

una notificación o realice una acción automatizada
cuando los resultados de la consulta coincidan con un
resultado concreto.
Configure una regla de alerta de métrica en
determinados registros de datos de registro extraídos
como métricas.
Recuperar Obtenga acceso a los resultados de la consulta de

registro desde una línea de comandos mediante la CLI
de Azure.
Obtenga acceso a los resultados de la consulta de
registro desde una línea de comandos mediante
cmdlets de PowerShell.
Obtenga acceso a los resultados de la consulta de
registro de una aplicación personalizada con la API
REST.
Expor tarar Cree un flujo de trabajo para recuperar datos de

registro y cópielo en una ubicación externa mediante
Logic Apps.
¿Cómo se estructuran los registros de Azure Monitor?

Los datos recopilados por los registros de Azure Monitor se almacenan en un área de trabajo de Log
Analytics. Cada área de trabajo contiene varias tablas que almacenan datos desde un origen
determinado. Aunque todas las tablas comparten algunas propiedades comunes, cada una tiene un
único conjunto de propiedades que dependen del tipo de datos que almacena. Una nueva área de
trabajo tendrá un conjunto estándar de tablas, y las diferentes soluciones de supervisión y otros
servicios que escriben en el área de trabajo agregarán más tablas.
Los datos de registro de Application Insights utilizan el mismo motor de Log Analytics como áreas
de trabajo, pero se almacenan por separado para cada aplicación supervisada. Cada aplicación tiene
un conjunto estándar de tablas para almacenar datos, como solicitudes de aplicación, excepciones y
vistas de página.
Las consultas de registros usarán datos desde un área de trabajo de Log Analytics o una aplicación
de Application Insights. Puede usar una consulta entre recursos para analizar los datos de la
aplicación junto con otros datos de registro o para crear consultas que incluyan varias áreas de
trabajo o aplicaciones.
Consultas de registros
Los datos en los registros de Azure Monitor se recuperan mediante una consulta de registro escrita
con el lenguaje de consulta de Kusto, que le permite recuperar, consolidar y analizar rápidamente los
datos recopilados. Use Log Analytics para escribir y probar consultas de registro en Azure Portal. Le
permite trabajar con los resultados de forma interactiva o anclarlos a un panel para verlos con otras
visualizaciones.
Abra Log Analytics desde Application Insights para analizar datos de Application Insights.
También puede recuperar datos de registro mediante el uso de la API de Log Analytics y la API REST
de Application Insights.
Orígenes de registros de Azure Monitor

Azure Monitor puede recopilar datos de registro de diversos orígenes, tanto en Azure como desde
recursos locales. Las siguientes tablas enumeran los diferentes orígenes de datos disponibles de
diferentes recursos que escriben datos en los registros de Azure Monitor. Cada una tiene un vínculo
para obtener información detallada sobre cualquier configuración necesaria.
Inquilino y suscripción de Azure
DATA DESC RIP C IÓ N
Registros de auditoría de Azure Active Directory Se configuran a través de la configuración de

diagnóstico para cada directorio. Consulte Integración
de registros de Azure AD con registros de Azure
Monitor.
Registros de actividad Se almacenan por separado de forma predeterminada

y se pueden utilizar para alertas casi en tiempo real.
Instale la solución Activity Log Analytics para escribir
en el área de trabajo de Log Analytics. Consulte
Recopilar y analizar los registros de actividad de Azure
en el área de trabajo de Log Analytics en Azure
Monitor.
Recursos de Azure
Diagnóstico de recursos Configure los ajustes de diagnóstico para escribir en

los datos de diagnóstico, incluidas las métricas en un
área de trabajo de Log Analytics. Consulte
Transmisión de registros de recursos de Azure a Log
Analytics.
Soluciones de supervisión Las soluciones de supervisión escriben los datos que

recopilan en su área de trabajo de Log Analytics.
Consulte Detalles de la recopilación de inventario y
datos para la supervisión de soluciones en Azure para
ver una lista de soluciones. Consulte Soluciones de
supervisión en Azure Monitor para obtener más
información sobre la instalación y el uso de
soluciones.
Métricas Envíe las métricas de la plataforma para los recursos

de Azure Monitor a un área de trabajo de Log
Analytics para conservar los datos de registro durante
períodos más largos y realizar análisis complejos con
otros tipos de datos utilizando el lenguaje de consulta
Kusto. Consulte Transmisión de registros de recursos
de Azure a Log Analytics.
Almacenamiento de tablas de Azure Recopile datos de la instancia de Azure Storage donde

algunos recursos de Azure escriben datos de
supervisión. Consulte Use Azure blob storage for IIS
and Azure table storage for events with Log Analytics
(Uso de Azure Blob Storage para el almacenamiento
de tablas de Azure e IIS de eventos con Log
Analytics).
Virtual Machines
Orígenes de datos de agentes Los orígenes de datos recopilados de agentes de

Windows y Linux incluyen eventos, datos de
rendimiento y registros personalizados. Consulte
Orígenes de datos de agente en Azure Monitor para
obtener una lista de orígenes de datos y los detalles
de configuración.
Soluciones de supervisión Las soluciones de supervisión escriben los datos que

recopilan de los agentes en su área de trabajo de Log
Analytics. Consulte Detalles de la recopilación de
inventario y datos para la supervisión de soluciones
en Azure para ver una lista de soluciones. Consulte
Soluciones de supervisión en Azure Monitor para
obtener más información sobre la instalación y el uso
de soluciones.
System Center Operations Manager Conecte el grupo de administración de Operations

Manager a Azure Monitor para recopilar datos de
eventos y rendimiento de los agentes locales en
registros. Consulte Connect Operations Manager to
Log Analytics (Conexión de Operations Manager con
Log Analytics ) para obtener más información sobre
esta configuración.
APLICACIONES
Solicitudes y excepciones Los datos detallados sobre las solicitudes y las

excepciones de la aplicación se encuentran en las
tablas requests, pageViews y exceptions. Las llamadas
a los componentes externos están en la tabla
dependencies.
Uso y rendimiento El rendimiento de la aplicación está disponible en las

tablas requests, browserTimings y
performanceCounters. Los datos de métricas
personalizadas están en la tabla customMetrics.
Datos de seguimiento Los resultados del seguimiento distribuido se

almacenan en la tabla traces.
Pruebas de disponibilidad Los datos de resumen de pruebas de disponibilidad se

almacenan en la tabla availabilityResults. Los datos
detallados de estas pruebas se encuentran en un
almacenamiento independiente y son accesibles desde
Application Insights en Azure Portal.
Azure Monitor para contenedores Datos de inventario y de rendimiento recopilados por

Azure Monitor para contenedores. Consulte los
detalles de recopilación de datos del contenedor para
obtener una lista de las tablas.
Azure Monitor para máquinas virtuales Datos de inventario y asignación recopilados por
Azure Monitor para VM. Consulte Cómo consultar
registros de Azure Monitor para VM para obtener
más información sobre las consultas de estos datos.
Personalizado
API DE REST Escriba datos en un área de trabajo de Log Analytics

desde cualquier cliente de REST. Consulte Envío de
datos de registro a Azure Monitor con HTTP Data
Collector API para obtener más información.
Aplicación lógica Escriba cualquier dato en un área de trabajo de Log

Analytics desde un flujo de trabajo de Logic Apps con
la acción Azure Log Analytics Data Collector .
Seguridad
Azure Security Center Azure Security Center almacena los datos que recopila
en un área de trabajo de Log Analytics donde se
pueden analizar con otros datos del registro. Consulte
Recolección de datos en Azure Security Center para
obtener más información sobre la configuración del
área de trabajo.
Azure Sentinel Azure Sentinel almacena los datos de orígenes de

datos en un área de trabajo de Log Analytics.
Consulte Conexión con orígenes de datos.
Pasos siguientes
Más información sobre la plataforma de datos de Azure Monitor.
Obtenga más información acerca de las métricas en Azure Monitor.
Tiempo de la ingesta de datos de registro en Azure
Monitor
Azure Monitor es un servicio de datos a gran escala que atiende a miles de clientes que envían terabytes de datos
cada mes a un ritmo creciente. Con frecuencia se plantean preguntas sobre el tiempo necesario para que los datos
de registro estén disponibles una vez que se han recopilado. En este artículo se explican los distintos factores que
afectan a esta latencia.
Latencia típica
La latencia hace referencia al momento en el que los datos se crean en el sistema supervisado y el momento en el
que están disponibles para su análisis en Azure Monitor. La latencia típica para la ingesta de datos de registro es de
entre 2 y 5 minutos. La latencia específica para cualquier dato determinado varía en función de una serie de
factores que se explican más adelante.
Factores que afectan a la latencia

El tiempo total de ingesta para un determinado conjunto de datos puede dividirse en las siguientes áreas de alto
nivel.
Tiempo del agente: el tiempo para detectar un evento, recopilarlo y enviarlo al punto de ingesta de Azure
Monitor como una entrada de registro. En la mayoría de los casos, este proceso se controla mediante un
agente.
Tiempo de canalización: el tiempo que le lleva a la canalización de ingesta procesar la entrada del registro. Esto
incluye el análisis de las propiedades del evento y la incorporación potencial de información calculada.
Tiempo de indexación: el tiempo dedicado a la ingesta de una entrada de registro en el almacén de macrodatos
de Azure Monitor.
A continuación se describen los detalles sobre las diferentes latencias que se presentan en este proceso.
Latencia de la recopilación de agente
Los agentes y las soluciones de administración utilizan diferentes estrategias para recopilar datos de una máquina
virtual, lo que puede afectar a la latencia. A continuación se incluyen algunos ejemplos:
Los eventos de Windows, eventos de syslog y las métricas de rendimiento se recopilan inmediatamente. Los
contadores de rendimiento de Linux se sondean a intervalos de 30 segundos.
Los registros de IIS y los registros personalizados se recopilan cuando cambia su marca de tiempo. Para los
registros de IIS, esto viene determinado por la programación de sustitución configurada en IIS.
La solución de Active Directory Replication realiza su valoración cada cinco días, mientras que la solución de
Active Directory Assessment realiza una evaluación semanal de la infraestructura de Active Directory. El agente
recopilará estos registros solo cuando la evaluación esté completada.
Frecuencia de carga del agente
Para asegurarse de que el agente de Log Analytics es ligero, el agente almacena en búfer los registros y los carga
periódicamente en Azure Monitor. La frecuencia de carga varía entre 30 segundos y 2 minutos, según el tipo de
datos. La mayoría de los datos se carga en menos de 1 minuto. Las condiciones de red pueden afectar
negativamente a la latencia de estos datos para acceder al punto de ingesta de Azure Monitor.
Registros de actividad, registros de recursos y métricas de Azure
Los datos de Azure tardan más tiempo en estar disponibles en el punto de ingesta de Log Analytics para su
procesamiento:
Los datos de los registros de recursos tardan entre 2 y 15 minutos, en función del servicio de Azure. Vea esta
consulta para examinar la latencia en su entorno
Las métricas de la plataforma de Azure tardan 3 minutos en enviarse al punto de ingesta de Log Analytics.
Los datos de registro de actividad tardarán aproximadamente entre 10 y 15 minutos en enviarse al punto de
ingesta de Log Analytics.
Una vez disponibles en el punto de ingesta, tardarán entre 2 y 5 minutos más en estar disponibles para su
consulta.
Recopilación de las soluciones de administración
Algunas soluciones no recopilan los datos de un agente y pueden usar un método de recopilación que introduce
latencia adicional. Algunas soluciones recopilan los datos a intervalos regulares sin intentar la recopilación casi en
tiempo real. A continuación se incluyen algunos ejemplos específicos:
La solución Office 365 sondea los registros de actividad mediante la API de Actividad de administración de
Office 365, que actualmente no proporciona garantías de latencia casi en tiempo real.
Los datos de las soluciones de Windows Analytics (Update Compliance por ejemplo) se recopilan con una
frecuencia diaria por la solución.
Consulte la documentación de cada solución para determinar su frecuencia de recopilación.
Tiempo del proceso de canalización
Una vez que las entradas de registro se han ingerido en la canalización de Azure Monitor (como se indica en la
propiedad _TimeReceived), se escriben en un almacenamiento temporal para garantizar el aislamiento de
inquilinos y para asegurarse de que no se pierden datos. Normalmente, este proceso agrega de 5 a 15 segundos.
Algunas soluciones de administración implementan algoritmos más pesados para agregar datos y obtener
perspectivas a medida que los datos van entrando. Por ejemplo, Network Performance Monitor agrega los datos
de entrada en intervalos de 3 minutos, agregando así una latencia de 3 minutos. Otro proceso que agrega latencia
es el proceso que controla los registros personalizados. En algunos casos, este proceso puede agregar algunos
minutos de latencia a los registros recopilados de los archivos por el agente.
Aprovisionamiento de nuevos tipos de datos personalizados
Cuando se crea un nuevo tipo de datos personalizados desde un registro personalizado o la API del recopilador de
datos, el sistema crea un contenedor de almacenamiento dedicado. Se trata de una sobrecarga de un solo uso que
se produce solo con la primera aparición de este tipo de datos.
Protección para los picos de datos
La máxima prioridad de Azure Monitor es asegurarse de que no se pierda ningún dato de cliente, por ello el
sistema tiene protección integrada para los picos en los que los datos aumentan. Esto incluye los búferes para
asegurarse de que incluso con una carga enorme, el sistema seguirá funcionando. Bajo una carga normal, estos
controles agregan menos de un minuto, pero en condiciones extremas y con errores pueden agregar un tiempo
significativo mientras se aseguran de que los datos no se pierdan.
Tiempo de indexación
Hay un equilibrio integrado para cada plataforma de macrodatos entre, por un lado, proporcionar análisis y
funcionalidades de búsqueda avanzada y por otro proporcionar acceso inmediato a los datos. Azure Monitor le
permite ejecutar consultas muy eficaces en miles de millones de registros y obtener resultados en cuestión de
segundos. Esto es posible porque la infraestructura transforma los datos de forma drástica durante su ingesta y
los almacena en estructuras compactas únicas. El sistema almacena en búfer los datos hasta que haya disponibles
los suficientes para crear estas estructuras. Esto se tiene que completar antes de que aparezca la entrada de
registro en los resultados de búsqueda.
Actualmente, este proceso tarda aproximadamente 5 minutos cuando hay bajo volumen de datos, y menos tiempo
con una frecuencia de datos más alta. Esto parece contradictorio, pero este proceso permite la optimización de
latencia para cargas de trabajo de producción de gran volumen.
Comprobación del tiempo de ingesta de datos

El tiempo de ingesta puede variar para diferentes recursos en diferentes circunstancias. Puede usar consultas de
registro para identificar el comportamiento específico de su entorno. En la tabla siguiente se especifica cómo se
pueden determinar los distintos tiempos de un registro a medida que se crea y se envía a Azure Monitor.
PA SO P RO P IEDA D O F UN C IÓ N C O M EN TA RIO S
Registro creado en el origen de datos TimeGenerated

Si el origen de datos no establece este
valor, se establecerá en el mismo
tiempo que _TimeReceived.
Registro recibido por el punto de _TimeReceived

conexión de ingesta de Azure Monitor
Registro almacenado en el área de ingestion_time()

trabajo y disponible para las consultas.
Retrasos de latencia de la ingesta

Puede medir la latencia de un registro específico si compara el resultado de la función ingestion_time() con la
propiedad TimeGenerated. Estos datos se pueden usar con diversas agregaciones para conocer el funcionamiento
de la latencia de ingesta. Examine algunos percentiles del tiempo de ingesta para obtener información de grandes
cantidades de datos.
Por ejemplo, la consulta siguiente muestra los equipos que tenían el mayor tiempo de ingesta durante las ocho
horas anteriores:
Heartbeat
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer
| top 20 by percentile_E2EIngestionLatency_95 desc
Las comprobaciones de percentiles anteriores son adecuadas para buscar tendencias generales en la latencia. Para
identificar un pico a corto plazo en la latencia, puede resultar más eficaz usar el máximo ( max() ).
Si quiere profundizar en el tiempo de ingesta de un equipo específico durante un período de tiempo, use la
siguiente consulta, que también visualiza los datos del día anterior en un gráfico:
Heartbeat
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by
bin(TimeGenerated,30m)
| render timechart
Use la siguiente consulta para mostrar la hora de ingesta del equipo por el país o región en el que está ubicado
basándose en su dirección IP:
Heartbeat
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry
Los diferentes tipos de datos que se originan desde el agente pueden tener diferentes horas de latencia de
ingestión, por lo que las consultas anteriores se pueden usar con otros tipos. Use la siguiente consulta para
examinar la hora de la ingesta de diversos servicios de Azure:
AzureDiagnostics
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider
Recursos que dejan de responder

En algunos casos, un recurso pudo detener el envío de datos. Para saber si un recurso está enviando datos o no,
examine su registro más reciente que puede identificarse por el campo TimeGenerated estándar.
Use la tabla Latido para comprobar la disponibilidad de una máquina virtual, puesto que un agente envía un latido
una vez por minuto. Use la siguiente consulta para mostrar una lista de los equipos activos que no han
comunicado latidos recientemente:
Heartbeat
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer
| top 20 by NoHeartbeatPeriod desc
Pasos siguientes
Lea el Acuerdo de Nivel de Servicio (SLA) para Azure Monitor.
Transmisión de datos de supervisión de Azure a un
centro de eventos o asociado externo
Azure Monitor proporciona una solución completa de supervisión de pila para aplicaciones y servicios en Azure,
en otras nubes y locales. Asimismo, se puede usar Azure Monitor para analizar esos datos y aprovecharlos en
diferentes escenarios de supervisión, aunque es posible que deba enviarlos a otras herramientas de supervisión
de su entorno. En la mayoría de los casos, el método más efectivo para transmitir datos de supervisión a
herramientas externas, es usar Azure Event Hubs. En este artículo se proporciona una breve descripción de cómo
hacerlo y luego se enumeran algunos de los asociados en los que puede enviar datos. Algunos tienen una
integración especial con Azure Monitor y se pueden hospedar en Azure.
Creación de un espacio de nombres de Event Hubs

Antes de configurar la transmisión de cualquier origen de datos, debe crear un espacio de nombres de
Event Hubs y un centro de eventos. Estos centro de eventos y espacio de nombres son el destino de todos los
datos de supervisión. Un espacio de nombres de Event Hubs es una agrupación lógica de centros de eventos que
comparten la misma directiva de acceso, al igual que una cuenta de almacenamiento tiene blobs individuales
dentro de esa cuenta de almacenamiento. Tenga en cuenta los siguientes detalles sobre el espacio de nombres de
los centros de eventos y aquellos centros de eventos que use para transmitir los datos de supervisión:
El número de unidades de rendimiento permite aumentar la escala de rendimiento para los centros de
eventos. Solo se necesita una unidad de procesamiento normalmente. Si necesita escalar verticalmente a
medida que el uso del registro aumenta, siempre puede aumentar manualmente el número de unidades de
procesamiento del espacio de nombres o habilitar la inflación automática.
El número de particiones permite paralelizar el consumo entre muchos consumidores. Una sola partición
puede admitir hasta 20 MBps o, aproximadamente, 20 000 mensajes por segundo. Dependiendo de la
herramienta que consume los datos, puede o no puede admitir el consumo de varias particiones. Es razonable
comenzar con cuatro particiones si no está seguro acerca de la cantidad de particiones que debe configurar.
Igualmente, debe establecer la retención de mensajes en el centro de eventos durante al menos 7 días. Si la
herramienta de consumo deja de funcionar durante más de un día, esta opción garantiza que dicha
herramienta pueda continuar desde donde se quedó (en cuanto a los eventos de hasta 7 días de antigüedad).
Debe usar el grupo de consumidores predeterminado en el centro de eventos. No es necesario para crear
otros grupos de consumidores o usar un grupo de consumidores independientes a menos que piense
disponer de dos herramientas diferentes que consuman los mismos datos del mismo centro de eventos.
En cuanto al registro de actividad de Azure, se elige un espacio de nombres de Event Hubs, y Azure Monitor
crea un centro de eventos dentro de ese espacio de nombres llamado insights-logs-operational-logs. Para
otros tipos de registro, puede elegir un centro de eventos existente o hacer que Azure Monitor cree un centro
de eventos en función de la categoría de registro.
Los puertos de salida 5671 y 5672 deben estar abiertos en el equipo o red virtual que consume datos del
centro de eventos.
Datos de supervisión disponibles

En Orígenes de datos de supervisión de Azure Monitor se describen los diferentes niveles de datos de las
aplicaciones de Azure y los tipos de datos de supervisión disponibles para cada uno. En la siguiente tabla se
enumera cada uno de esos niveles y se proporciona una descripción de cómo esos datos pueden transmitirse a
un centro de eventos. Siga los vínculos proporcionados para obtener más detalles.
N IVEL DATA M ÉTO DO
Inquilino de Azure Registros de auditoría de Configure un valor de diagnóstico de

Azure Active Directory inquilino en el inquilino de AAD.
Consulte Tutorial: Streaming de los
registros de Azure Active Directory a
Azure Event Hubs para obtener más
detalles.
Suscripción de Azure Azure Activity Log Cree un perfil de registro para exportar
eventos del registro de actividades a
Event Hubs. Consulte Transmisión de
registros de plataforma de Azure a
Azure Event Hubs para más
información.
Recursos de Azure Métricas de la plataforma Ambos tipos de datos se envían a un

Registros del recurso centro de eventos mediante la
configuración de diagnóstico de
recursos. Consulte Transmisión de
registros de recursos de Azure a un
centro de eventos para más detalles.
Sistema operativo (invitado) Azure Virtual Machines Instale la extensión de

Azure Diagnostics en máquinas
virtuales de Windows y Linux en Azure.
Consulte Streaming de datos de
Azure Diagnostics en la ruta de acceso
activa mediante Event Hubs para
obtener detalles sobre las VM de
Windows y Usar la extensión de
diagnósticos de Linux para supervisar
métricas y registros para obtener
detalles sobre las VM de Linux.
Código de aplicación Application Insights Application Insights no proporciona un

método directo para transmitir datos a
LOS centros de eventos. Puede
configurar la exportación continua de
los datos de Application Insights a una
cuenta de almacenamiento y luego
usar una aplicación lógica para enviar
esos datos a un centro de eventos, tal
como se describe en Streaming manual
con la aplicación lógica.
Streaming manual con la aplicación lógica

Para los datos que no puede transmitir directamente a un centro de eventos, puede escribir en Azure Storage y
luego usar una aplicación lógica que se desencadene según tiempo y que extraiga datos de Blob Storage y los
envíe como mensaje al centro de eventos.
Herramientas de asociados con la integración de Azure Monitor

El enrutamiento de los datos de supervisión a un centro de eventos con Azure Monitor facilita la integración con
las herramientas externas de SIEM y de supervisión. Se incluyen los siguientes ejemplos de herramientas con la
integración de Azure Monitor :
H ERRA M IEN TA H O SP EDA DO EN A Z URE DESC RIP C IÓ N
IBM QRadar No Los protocolos Microsoft Azure DSM y

Microsoft Azure Even Hub se pueden
descargar en el sitio web de el sitio web
de soporte técnico de IBM. Encontrará
más información acerca de la
integración con Azure en Configuración
de QRadar DSM.
Splunk No El complemento Azure Monitor para

Splunk está disponible en Splunkbase y
es un proyecto de código abierto. La
documentación está disponible en
Complemento de Azure Monitor para
Splunk.
Si no puede instalar un complemento

en la instancia de Splunk (por ejemplo,
si usa un proxy o si se ejecuta en
Splunk Cloud), puede reenviar estos
eventos al recopilador de eventos de
HTTP de Splunk mediante esta función
de Azure para Splunk que
desencadenan los nuevos mensajes del
centro de eventos.
sumologic No Las instrucciones para configurar

SumoLogic para consumir datos de un
centro de eventos están disponibles en
Recopilar registros para la aplicación
Azure Audit desde el centro de
eventos.
ArcSight No El conector inteligente ArcSight de

Azure Event Hubs está disponible
como parte de esta colección de
conectores inteligentes de ArcSight.
Servidor de Syslog No Si quiere transmitir datos de

Azure Monitor directamente a un
servidor syslog, puede usar una
solución basada en una función de
Azure.
LogRhythm No Las instrucciones necesarias para

configurar LogRhythm con el fin de
recopilar registros de un centro de
eventos están disponibles aquí.
Logz.io Sí Para más información, consulte

Introducción a la supervisión y el
registro con Logz.io para aplicaciones
Java que se ejecutan en Azure.
También pueden estar disponibles otros asociados. Para obtener una lista completa de todos los asociados de
Azure Monitor y sus funcionalidades, consulte Integraciones de asociados de Azure Monitor.
Pasos siguientes
Archivar el registro de actividad en una cuenta de almacenamiento
Leer la introducción sobre el registro de actividad de Azure
Configurar una alerta basada en un evento del registro de actividad
Introducción a Insights en Azure Monitor
Insights proporciona una experiencia de supervisión personalizada para determinadas aplicaciones y

servicios. Almacena datos en la plataforma de datos de Azure Monitor y aprovecha otras características de
Azure Monitor para el análisis y la creación de alertas, pero puede recopilar datos adicionales y proporcionar
una experiencia de usuario única en Azure Portal. Obtener acceso a información a partir de la sección
Insights del menú de Azure Monitor en Azure Portal.
Las secciones siguientes proporcionan una breve descripción de la información actualmente disponible en
Azure Monitor. Consulte la documentación detallada para obtener información sobre cada una.
Application Insights es un servicio de Application Performance Management (APM) extensible para
desarrolladores web en varias plataformas. Úselo para supervisar la aplicación web en directo. Funciona con
diversas aplicaciones y en una amplia variedad de plataformas, como .NET, Node.js o Java EE, hospedadas en
el entorno local, de forma híbrida o en cualquier nube pública. También se integra con el proceso de DevOps y
tiene puntos de conexión a numerosas herramientas de desarrollo.
Vea ¿Qué es Application Insights?.

Azure Monitor para contenedores supervisa el rendimiento de las cargas de trabajo de contenedor
implementadas en Azure Container Instances o en clústeres de Kubernetes administrados hospedados en
Azure Kubernetes Service (AKS). La supervisión de los contenedores es fundamental, sobre todo cuando se
ejecuta un clúster de producción, a escala, con varias aplicaciones.
Vea Introducción a Azure Monitor para contenedores.
Azure Monitor para grupos de recursos (versión preliminar)
Azure Monitor para grupo de recursos ayuda a clasificar y diagnosticar cualquier problema que encuentren
sus recursos individuales, a la vez que se ofrece un contexto en cuanto al estado y el rendimiento del grupo de
recursos como un todo.
Vea Supervisar los grupos de recursos con Azure Monitor (versión preliminar).
Azure Monitor para VM (versión preliminar)

Azure Monitor para VM supervisa las máquinas virtuales (VM) y los conjuntos de escalado de máquinas
virtuales de Azure. El servicio analiza el rendimiento y el estado de las VM Windows y Linux, y supervisa sus
procesos y dependencias en otros recursos y procesos externos.
Vea ¿Qué es Azure Monitor para máquinas virtuales?
Azure Monitor for Networks (versión preliminar)

Azure Monitor for Networks proporciona una vista completa del estado y las métricas de todos los recursos
de red. La capacidad de búsqueda avanzada ayuda a identificar dependencias de recursos, lo que habilita
escenarios como la identificación de recursos que hospedan el sitio web con una simple búsqueda del nombre
del sitio web.
Pasos siguientes
Más información sobre la plataforma de datos de Azure Monitor y la información que proporciona.
Obtenga información sobre los diferentes orígenes de datos usados por Azure Monitor y los diferentes
tipos de datos recopilados por cada una de las opciones de información.
Seguridad de datos de Log Analytics
Este documento está diseñado para proporcionar información específica sobre Log Analytics, que es una
característica de Azure Monitor, para complementar la información que se halla en el Centro de confianza de Azure.
En este artículo, se explica cómo Log Analytics recopila, procesa y protege los datos. Puede usar a agentes para
conectarse al servicio web, utilizar System Center Operations Manager con el fin de recopilar datos operativos o
recuperar datos de Diagnósticos de Azure para que Log Analytics los utilice.
El servicio Log Analytics administra sus datos basados en la nube de forma segura mediante los siguientes
métodos:
Segregación de datos
Retención de datos
Seguridad física
Administración de incidentes
Cumplimiento normativo
Certificaciones de estándares de seguridad
Póngase en contacto con nosotros si tiene preguntas, sugerencias o problemas acerca de la siguiente información,
incluidas nuestras directivas de seguridad en Opciones de soporte técnico de Azure.
Envío de datos de forma segura con TLS 1.2

Para garantizar la seguridad de los datos en tránsito a Log Analytics, se recomienda encarecidamente configurar el
agente para que use al menos Seguridad de la capa de transporte (TLS) 1.2. Las versiones anteriores de TLS/Capa
de sockets seguros (SSL) han demostrado ser vulnerables y, si bien todavía funcionan para permitir la
compatibilidad con versiones anteriores, no se recomiendan , y el sector está cambiando rápidamente para
abandonar la compatibilidad de estos protocolos más antiguos.
PCI Security Standards Council ha establecido una fecha límite de 30 de junio de 2018 para deshabilitar las
versiones anteriores de TLS/SSL y actualizar a protocolos más seguros. Una vez que Azure quite la compatibilidad
heredada, si los agentes no pueden comunicarse a través de TLS 1.2 como mínimo, podría no ser capaz de enviar
datos a Log Analytics.
No se recomienda establecer explícitamente el agente para que solo use TLS 1.2, a menos que sea absolutamente
necesario, ya que esto puede interrumpir las características de seguridad a nivel de la plataforma que le permiten
detectar y aprovechar automáticamente las ventajas de los protocolos más seguros más recientes a medida que
estén disponibles, como TLS 1.3.
Guía específica para la plataforma
P L ATA F O RM A / L EN GUA JE SO P O RT E T ÉC N IC O M Á S IN F O RM A C IÓ N
Linux Las distribuciones de Linux tienden a Compruebe el registro de cambios de

basarse en OpenSSL para la OpenSSL para confirmar si su versión
compatibilidad con TLS 1.2. de OpenSSL es compatible.
Windows 8.0 a 10 Compatible y habilitado de manera Para confirmar que aún usa la
predeterminada. configuración predeterminada.
Windows Server 2012 a 2016 Compatible y habilitado de manera Para confirmar que aún usa la
predeterminada. configuración predeterminada
Windows 7 SP1 y Windows Server 2008 Compatible, pero no habilitado de Consulte la página Configuración del
R2 SP1 manera predeterminada. registro de TLS para obtener más
información sobre cómo se habilita.
Segregación de datos
Una vez que el servicio Log Analytics ha ingerido los datos, estos se mantienen de forma independiente en cada
componente del servicio. Todos los datos se etiquetan por área de trabajo. Este etiquetado persiste a lo largo del
ciclo de vida de los datos y se aplica en cada nivel del servicio. Los datos se almacenan en una base de datos
dedicada en el clúster de almacenamiento de la región que ha seleccionado.
Retención de datos
Los datos indexados de búsqueda de registros se almacenan y se conservan conforme al plan de precios. Para
obtener más información, consulte Precios de Log Analytics.
Como parte del acuerdo de suscripción, Microsoft conservará sus datos conforme a los términos del contrato.
Cuando se eliminan los datos de cliente, no se destruyen unidades físicas.
En la tabla siguiente se muestran algunas de las soluciones disponibles y se proporcionan ejemplos de los tipos de
datos que recopilan.
SO L UC IÓ N T IP O S DE DATO S
Capacidad y rendimiento Datos de rendimiento y metadatos
Administración de actualizaciones Metadatos y datos de estado
Administración de registros Registros IIS, de eventos de Windows o de eventos definidos

por el usuario
Seguimiento de cambios Inventario de software, servicio de Windows y metadatos de

demonio de Linux, y metadatos de archivo de Windows o
Linux
Evaluación de SQL y Active Directory Datos de WMI, datos de registro, datos de rendimiento y
resultados de la vista de administración dinámica de SQL
Server
La tabla siguiente muestra ejemplos de los tipos de datos:
T IP O DE DATO S F IEL DS
Alerta Alert Name, Alert Description, BaseManagedEntityId, Problem

ID, IsMonitorAlert, RuleId, ResolutionState, Priority, Severity,
Category, Owner, ResolvedBy, TimeRaised, TimeAdded,
LastModified, LastModifiedBy,
LastModifiedExceptRepeatCount, TimeResolved,
TimeResolutionStateLastModified,
TimeResolutionStateLastModifiedInDB, RepeatCount
T IP O DE DATO S F IEL DS
Configuración CustomerID, AgentID, EntityID, ManagedTypeID,

ManagedTypePropertyID, CurrentValue, ChangeDate
Evento EventId, EventOriginalID, BaseManagedEntityInternalId,

RuleId, PublisherId, PublisherName, FullNumber, Number,
Category, ChannelLevel, LoggingComputer, EventData,
EventParameters, TimeGenerated, TimeAdded
Nota: Cuando se escriben eventos con campos
personalizados en el registro de eventos de Windows, Log
Analytics los recopila.
Metadatos BaseManagedEntityId, ObjectStatus, OrganizationalUnit,

ActiveDirectoryObjectSid, PhysicalProcessors, NetworkName,
IPAddress, ForestDNSName, NetbiosComputerName,
VirtualMachineName, LastInventoryDate,
HostServerNameIsVirtualMachine, IP Address,
NetbiosDomainName, LogicalProcessors, DNSName,
DisplayName, DomainDnsName, ActiveDirectorySite,
PrincipalName, OffsetInMinuteFromGreenwichTime
Rendimiento ObjectName, CounterName, PerfmonInstanceName,

PerformanceDataId, PerformanceSourceInternalID,
SampleValue, TimeSampled, TimeAdded
State StateChangeEventId, StateId, NewHealthState, OldHealthState,

Context, TimeGenerated, TimeAdded, StateId2,
BaseManagedEntityId, MonitorId, HealthState, LastModified,
LastGreenAlertGenerated, DatabaseTimeModified
Seguridad física
El servicio Log Analytics está a cargo de personal de Microsoft y todas las actividades se registran y se pueden
auditar. Log Analytics funciona como un servicio de Azure y cumple con todos los requisitos de cumplimiento y
seguridad de Azure. Puede ver detalles acerca de la seguridad física de los recursos de Azure en la página 18 de la
Información general de la seguridad de Microsoft Azure. Los derechos de acceso físico para proteger áreas de las
personas que ya no tienen ninguna responsabilidad en el servicio de Log Analytics se cambian en un plazo de un
día hábil, incluidas la transferencia y la finalización. Puede consultar información sobre la infraestructura física
global que se utiliza en los centros de datos de Microsoft.
Administración de incidentes
Log Analytics incluye un proceso de administración de incidentes que cumplen todos los servicios de Microsoft.
Resumiendo:
Usamos un modelo de responsabilidad compartida donde una parte de la responsabilidad de seguridad reside
en Microsoft y otra parte pertenece al cliente.
Administramos los incidentes de seguridad de Azure:
Iniciamos una investigación tras la detección de un incidente.
Un miembro de guardia del equipo de respuesta a incidentes evalúa el impacto y la gravedad de un
incidente. En función de las pruebas, la evaluación puede dar lugar a que el incidente se remita al equipo
de respuesta de seguridad.
Diagnostique un incidente gracias a los expertos de respuesta de seguridad para realizar la investigación
forense o técnica, e identificar las estrategias de contención, mitigación y solución. Si el equipo de
seguridad considera que los datos de cliente pueden quedar expuestos a una persona no autorizada, la
ejecución en paralelo del proceso de notificación de incidentes de cliente.
Estabilice y recupere la infraestructura después del incidente. El equipo de respuesta a incidentes crea un
plan de recuperación para mitigar el problema. Pueden llevarse a cabo procesos de gestión de crisis,
como poner en cuarentena sistemas afectados, de inmediato y en paralelo al diagnóstico. Pueden
planearse más mitigaciones a largo plazo para realizarse después de que ha pasado el riesgo inmediato.
Cierre el incidente y realice un análisis final. El equipo de respuesta a incidentes lleva a cabo un análisis
final donde se describen los detalles del incidente con el objetivo de revisar las directivas, los
procedimientos y los procesos para evitar que se vuelva a producir el evento.
Notificamos a los clientes los incidentes de seguridad:
Determine el alcance de los incidentes y notifique de la forma más detallada posible a todos las personas
afectadas.
Cree un aviso para los clientes con la información detallada suficiente para que puedan realizar una
investigación y cumplir los compromisos con sus usuarios finales sin retrasar indebidamente el proceso
de notificación.
Confirme y declare el incidente según sea necesario.
Envíe a los clientes una notificación de incidentes puntual y de acuerdo con cualquier compromiso
contractual o jurídico. La notificación de incidentes de seguridad se entrega a uno o varios de los
administradores de un cliente por los medios que Microsoft elija, entre ellos el correo electrónico.
Formamos y preparamos al equipo:
El personal de Microsoft tiene que finalizar el curso sobre seguridad y concienciación, para que puedan
identificar y notificar los posibles problemas de seguridad.
Los operadores que trabajan en el servicio de Microsoft Azure tienen más obligaciones de aprendizaje
relacionadas con el acceso a los sistemas confidenciales que hospedan los datos de cliente.
El personal de respuesta de seguridad de Microsoft recibe cursos especializados para los roles que
desempeñan.
En caso de pérdida de datos de cualquier cliente, se notificará a cada cliente en el plazo de un día. Sin embargo, con
este servicio nunca se han perdido datos de cliente.
Para obtener más información sobre cómo Microsoft responde a los incidentes de seguridad, consulte Microsoft
Azure Security Response in the Cloud (Respuesta de seguridad de Microsoft Azure en la nube).
Cumplimiento normativo
El programa de gobernanza y seguridad de la información del equipo de servicio y desarrollo del software de Log
Analytics respalda sus requisitos empresariales y cumple las leyes y los reglamentos, tal y como se describe en el
Centro de confianza de Microsoft Azure y en Microsoft Trust Center Compliance. En estas páginas también se
describe cómo Log Analytics establece los requisitos de seguridad, identifica los controles de seguridad, y
administra y supervisa los riesgos. Cada año, revisamos las directivas, los estándares, los procedimientos y las
instrucciones.
Cada miembro del equipo de desarrollo recibe cursos formales sobre seguridad de aplicaciones. Internamente,
utilizamos un sistema de control de versiones para el desarrollo de software. Cada proyecto de software se protege
mediante el sistema de control de versiones.
Microsoft cuenta con un equipo de seguridad y cumplimiento normativo que supervisa y evalúa todos los
servicios de Microsoft. Los responsables de seguridad de la información conforman el equipo y no están
vinculados con los equipos de ingeniería que desarrollan Log Analytics. Los responsables de seguridad tienen su
propia cadena de administración y llevan a cabo evaluaciones independientes de los productos y servicios para
garantizar la seguridad y el cumplimiento normativo.
Al comité de dirección de Microsoft se le notifica mediante informes anuales sobre todos los programas de
información de seguridad de Microsoft.
Los equipos de servicio y desarrollo de software de Log Analytics trabajan de manera activa con los equipos de
cumplimiento y asuntos jurídicos de Microsoft, así como con otros asociados del sector, para adquirir diversas
certificaciones.
Certificaciones y atestaciones
Azure Log Analytics cumple los requisitos siguientes:
ISO/IEC 27001
ISO/IEC 27018:2014
ISO 22301
Conformidad con la norma Data Security Standard de PCI (PCI DSS) del PCI Security Standards Council.
Conformidad con Service Organization Control (SOC) 1, tipo 1 y SOC 2, tipo 1
HIPAA y HITECH para aquellas empresas que posean un contrato de asociación comercial según las normas
HIPAA.
Criterios de ingeniería comunes de Windows
Microsoft Trustworthy Computing
Como se trata de un servicio de Azure, los componentes que usa Log Analytics cumplen los requisitos de
cumplimiento normativo de Azure. Puede obtener más información en el artículo Microsoft Trust Center
Compliance (Cumplimiento normativo del Centro de confianza de Microsoft Azure).
NOTE
En algunas certificaciones o atestaciones, Log Analytics aparece con su nombre anterior, Operational Insights.
Flujo de datos de seguridad de informática en la nube

En el diagrama siguiente se muestra una arquitectura de seguridad en la nube como el flujo de información
proveniente de la empresa y cómo se protege a medida que se mueve al servicio Log Analytics y al que, en última
instancia, ve usted en Azure Portal. Después del diagrama aparece más información acerca de cada paso.
1. Suscripción a Log Analytics y recopilación de datos
Para que su organización envíe datos a Log Analytics, puede configurar un agente de Windows o Linux que se
ejecute en máquinas virtuales de Azure, o en equipos físicos o virtuales de su entorno o de otro proveedor en la
nube. Si usa Operations Manager, desde el grupo de administración puede configurar el agente de Operations
Manager. Los usuarios (que pueden ser usted, otros usuarios individuales o un grupo de personas) deben crear
una o más áreas de trabajo de Log Analytics y registrar los agentes mediante una de las siguientes cuentas:
Id. de organización
Cuenta de Microsoft: Outlook, Office Live, MSN
Un área de trabajo de Log Analytics es donde se recopilan, agregan, analizan y presentan los datos. Se usa
principalmente como un medio para realizar la partición de datos y cada uno de ellos es único. Por ejemplo,
recomendamos que los datos de producción se administren con un área de trabajo de Log Analytics, y los datos de
prueba, con otro diferente. Los espacios de trabajo también ayudan a un administrador a controlar el acceso de los
usuarios a los datos. Cada área de trabajo puede tener, a su vez, varias cuentas de usuario asociadas y viceversa:
cada cuenta de usuario puede tener varias áreas de trabajo de Log Analytics. Las áreas de trabajo se crean en
función de la región del centro de datos.
En lo que respecta a Operations Manager, el grupo de administración de este establece una conexión con el
servicio Log Analytics. Después, puede configurar qué sistemas administrados por un agente del grupo de
administración pueden recopilar y enviar datos al servicio. Dependiendo de la solución habilitada, los datos de
estas soluciones se envían directamente desde un servidor de administración de Operations Manager al servicio
Log Analytics o bien, debido al volumen de los datos recopilados en el sistema administrado por agentes, se envían
directamente desde el agente al servicio. En el caso de los sistemas que no supervisa Operations Manager, cada
uno se conecta directamente y de forma segura al servicio Log Analytics.
Toda la comunicación se cifra entre sistemas conectados y el servicio Log Analytics. El protocolo TLS (HTTPS) se
utiliza para el cifrado. Se sigue el proceso del SDL de Microsoft para garantizar que el servicio Log Analytics está
actualizado con los últimos avances en protocolos criptográficos.
Cada tipo de agente recopila datos para Log Analytics. El tipo de datos recopilados depende de los tipos de
soluciones usadas. Puede ver un resumen del proceso de recolección de datos en el artículo Incorporación de
soluciones de Log Analytics desde la galería de soluciones. Además, hay información más detallada disponible
sobre este tema para la mayoría de las soluciones. Una solución es una agrupación de vistas predefinidas,
consultas de búsqueda de registros, reglas de recopilación de datos y lógica de procesamiento. Solo los
administradores pueden usar Log Analytics para importar una solución. Una vez importada, la solución se
transfiere a los servidores de administración de Operations Manager (en caso de utilizarse) y, después, a los
agentes que haya elegido. Posteriormente, los agentes recopilan los datos.
2. Envío de datos desde agentes

El registro de todos los tipos de agentes se efectúa con una clave de inscripción y se establece una conexión segura
entre el agente en cuestión y el servicio Log Analytics mediante la autenticación basada en certificados y TLS con el
puerto 443. Log Analytics utiliza un almacén secreto para generar y mantener las claves. Las claves privadas se
alternan cada 90 días, y se almacenan en Azure y administran a través de las operaciones de Azure que siguen las
estrictas prácticas regulatorias y de cumplimiento normativo.
Con Operations Manager, el grupo de administración registrado con un área de trabajo de Log Analytics establece
una conexión HTTPS segura con un servidor de administración de Operations Manager.
En lo que respecta a los agentes de Windows o de Linux que se ejecutan en máquinas virtuales de Azure, se utiliza
una clave de almacenamiento de solo lectura para leer los eventos de diagnóstico en las tablas de Azure.
En el caso de agentes que envían notificaciones a un grupo de administración de Operations Manager que está
integrado con Log Analytics, si el servidor de administración no se puede comunicar con el servicio por cualquier
motivo, los datos recopilados se almacenan localmente en una memoria caché temporal del servidor de
administración. Intentarán volver a enviar los datos cada ocho minutos durante dos horas. Para los datos que
eluden el servidor de administración y se envían directamente a Log Analytics, el comportamiento es coherente
con el agente de Windows.
Los datos almacenados en la memoria caché del agente del servidor de administración o de Windows se protegen
mediante el almacén de credenciales del sistema operativo. Si el servicio no puede procesar los datos después de
dos horas, los agentes pondrán en cola los datos. Si la cola se llena, el agente empieza a quitar tipos de datos,
empezando por los datos de rendimiento. El límite de cola de los agentes es una clave de registro que puede
modificar si es necesario. Los datos recopilados se comprimen y se envían al servicio, omitiendo las bases de datos
del grupo de administración de Operations Manager, por lo que no se les agrega ninguna carga. Después de enviar
los datos recopilados, se quitan de la memoria caché.
Como se describió anteriormente, los datos del servidor de administración o de los agentes conectados
directamente se envían por TLS a los centros de datos de Microsoft Azure. También puede usar ExpressRoute para
proporcionar más seguridad a los datos. Con ExpressRoute puede conectarse directamente a Azure desde una red
WAN, como una VPN de conmutación por etiquetas multiprotocolo (MPLS) que proporcione un proveedor de
servicios de red. Para obtener más información, consulte el artículo sobre ExpressRoute.
3. Recepción y procesamiento de los datos por parte del servicio Log

Analytics
El servicio Log Analytics asegura que los datos entrantes provienen de una fuente de confianza mediante la
validación de certificados y la integridad de los datos con la autenticación de Azure. Los datos sin procesar se
almacenarán posteriormente en una instancia de Azure Event Hubs en la región en que finalmente se almacenarán
los datos en reposo. El tipo de datos que se almacena depende de los tipos de soluciones que se importaron y se
usaron para recopilar datos. Después, el servicio Log Analytics procesa los datos sin procesar y los ingiere en la
base de datos.
El período de retención de los datos recopilados que se almacenan en la base de datos depende del plan de precios
seleccionado. Para el nivel Gratis, los datos recopilados están disponibles durante siete días. Para el nivel de pago,
los datos recopilados están disponibles durante 31 días de forma predeterminada, pero se puede ampliar a 730
días. Los datos se almacenan cifrados en reposo en Azure Storage, para garantizar la confidencialidad de los datos,
y los datos se replican dentro de la región local con almacenamiento con redundancia local (LRS). Las dos últimas
semanas de datos también se almacenan en caché basada en SSD y esta caché está cifrada.
4. Uso de Log Analytics para acceder a los datos

Para acceder al área de trabajo de Log Analytics puede iniciar sesión en Azure Portal mediante la cuenta de la
organización o la cuenta Microsoft configurada anteriormente. Todo el tráfico que circula entre el portal y el
servicio Log Analytics se envía por un canal seguro HTTPS. Al usar el portal, se genera un identificador de sesión
en el cliente del usuario (explorador web) y los datos se almacenan en una caché local hasta que finalice la sesión.
Cuando termina, se elimina la memoria caché. Las cookies del cliente, que no contienen información de
identificación personal, no se quitan automáticamente. Las de sesión se marcan con HTTPOnly y se protegen.
Después de un periodo de inactividad predeterminado, se termina la sesión de Azure Portal.
Pasos siguientes
Aprenda a recopilar datos con Log Analytics para las máquinas virtuales de Azure con la guía de inicio
rápido de máquinas virtuales de Azure.
Si desea recopilar datos desde equipos físicos o virtuales de Windows o Linux del entorno, consulte la guía
de inicio rápido para equipos con Linux o la guía de inicio rápido para equipos con Windows
Clave administrada por el cliente de Azure Monitor
En este artículo se proporcionan información general y los pasos para configurar las claves administradas por
el cliente (CMK) para las áreas de trabajo de Log Analytics. Una vez configuradas, los datos enviados a sus
áreas de trabajo se cifran con su clave de Azure Key Vault.
Se recomienda revisar la sección Limitaciones y restricciones que aparece más abajo antes de proceder con la
configuración.
Información general de la clave administrada por el cliente (CMK)

El cifrado en reposo es un requisito común de privacidad y seguridad en las organizaciones. Puede dejar que
Azure administre completamente el cifrado en reposo, mientras dispone de varias opciones para administrar
minuciosamente el cifrado o las claves de cifrado.
Azure Monitor garantiza que todos los datos y las consultas guardadas se cifren en reposo mediante claves
administradas por Microsoft (MMK). Azure Monitor también proporciona una opción para el cifrado mediante
su propia clave almacenada en Azure Key Vault a la que se tiene acceso mediante la autenticación de la
identidad administrada asignada por el sistema. Esta clave (CMK) se puede proteger mediante software o con
módulos de seguridad de hardware (HSM).
El uso que hace Azure Monitor del cifrado es idéntico al del cifrado de Azure Storage .
CMK le permite controlar el acceso a los datos y revocarlos en cualquier momento. Azure Monitor Storage
siempre respeta los cambios en los permisos de las claves en el plazo de una hora. Los datos ingeridos en los
últimos 14 días también se conservan en la memoria caché activa (respaldada por SSD) para un
funcionamiento eficaz del motor de consultas. Estos datos permanecen cifrados con las claves de Microsoft,
independientemente de la configuración de CMK, pero el control sobre los datos de SSD se adhiere
a revocación de claves. Estamos trabajando para que los datos de SSD se cifren con CMK en la segunda mitad
de 2020.
La funcionalidad de CMK se proporciona en clústeres de Log Analytics dedicados. Para comprobar que
tenemos la capacidad necesaria en la región, es necesario que la suscripción esté en la lista de permitidos de
antemano. Use su contacto de Microsoft para obtener la inclusión de la suscripción en la lista de permitidos
antes de empezar a configurar CMK.
El modelo de precios de los clústeres de Log Analytics usa reservas de capacidad a partir de un nivel de 1000
GB/día.
Cómo funciona CMK en Azure Monitor

Azure Monitor aprovecha la identidad administrada asignada por el sistema para conceder acceso a su
instancia de Azure Key Vault. La identidad administrada asignada por el sistema solo se puede asociar a un
único recurso de Azure, mientras que la identidad del clúster de Log Analytics se admite en el nivel de clúster,
lo que indica que la capacidad de CMK se entrega en un clúster de Log Analytics dedicado. Para admitir CMK en
varias áreas de trabajo, un nuevo recurso de Clúster de Log Analytics debe funcionar como una conexión de
identidad intermedia entre la instancia de Key Vault y las áreas de trabajo de Log Analytics. El almacenamiento
de clúster de Log Analytics usa la identidad administrada que 'está asociada al recurso de clúster para
autenticar el acceso y acceder a Azure Key Vault mediante Azure Active Directory.
Después de la configuración de CMK, los datos ingeridos en las áreas de trabajo asociadas a su clúster recurso
se cifran con la clave en Key Vault. Puede desasociar las áreas de trabajo del recurso de clúster en cualquier
momento. Los nuevos datos se introducen en el almacenamiento de Log Analytics y se cifran con la clave de
Microsoft, mientras que puede consultar los datos nuevos y antiguos sin problemas.
1. Key Vault
2. Recurso Clúster de Log Analytics que tiene una identidad administrada con permisos para Key Vault: la
identidad se admite en el nivel del almacenamiento de clúster dedicado de Log Analytics
3. Clúster dedicado de Log Analytics
4. Áreas de trabajo del cliente asociadas al recurso Clúster para el cifrado de CMK
Operación de claves de cifrado

Hay tres tipos de claves que se usan en el cifrado de datos de Storage:
KEK : clave de cifrado de claves (CMK)
AEK : clave de cifrado de la cuenta
DEK : clave de cifrado de datos
Se aplican las reglas siguientes:
Las cuentas de almacenamiento de clúster de Log Analytics generan una clave de cifrado única para
cada cuenta de almacenamiento, lo que se conoce como AEK.
La AEK se usa para derivar DEK, que son las claves que se usa para cifrar cada bloque de datos escritos
en el disco.
Al configurar la clave en Key Vault y hacer referencia a ella en el recurso Cluster, Azure Storage envía
solicitudes a Azure Key Vault para ajustar y desajustar AEK para realizar operaciones de cifrado y
descifrado de datos.
Esta KEK nunca abandona su instancia de Key Vault y, en el caso de una clave de HSM, nunca abandona
el hardware.
Azure Storage usa la identidad administrada que está asociada al recurso de clúster para autenticar el
acceso y acceder a Azure Key Vault mediante Azure Active Directory.
Procedimiento de aprovisionamiento de CMK

1. Suscripción permitida: la funcionalidad de CMK se proporciona en clústeres de Log Analytics dedicados.
Para comprobar que tenemos la capacidad necesaria en la región, es necesario que la suscripción esté en la
lista de permitidos de antemano. Use su contacto de Microsoft para obtener la inclusión de la suscripción en
la lista de permitidos.
2. Creación de una instancia de Azure Key Vault y almacenamiento de la clave
3. Creación de un recurso de Cluster
4. Concesión de permisos a la instancia de Key Vault
5. Asociación de áreas de trabajo de Log Analytics
El procedimiento no se admite en Azure Portal y el aprovisionamiento se realiza mediante PowerShell o
solicitudes REST.
IMPORTANT
Cualquier solicitud REST debe incluir un token de autorización de portador en el encabezado de la solicitud.
Por ejemplo:
GET https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>?api-version=2020-08-01
Authorization: Bearer eyJ0eXAiO....
Donde eyJ0eXAiO.... representa el token de autorización completo.

Puede adquirir el token de las siguientes formas:
1. Use el método Registros de aplicaciones.
2. En el Portal de Azure
a. Navegue hasta Azure Portal en la "herramienta para desarrolladores" (F12).
b. Busque la cadena de autorización en "Encabezados de solicitud", en una de las instancias de "batch?
api-version". Tiene el siguiente formato: "authorization: Bearer eyJ0eXAiO....".
c. Cópielo y agréguelo a su llamada API siguiendo los ejemplos que se muestran más abajo.
3. Vaya al sitio de documentación de REST de Azure. Presione "Probar" en cualquier API y copie el token de
portador.
Operaciones asincrónicas y comprobación de estado
Algunas de las operaciones de este procedimiento de configuración se ejecutan de forma asincrónica porque
no se pueden completar rápidamente. Cuando se utilizan solicitudes REST en la configuración, la respuesta
devuelve inicialmente un código de estado HTTP 200 (Correcto) y un encabezado con la propiedad Azure-
AsyncOperation cuando se acepta:
"Azure-AsyncOperation": "https://management.azure.com/subscriptions/subscription-
id/providers/Microsoft.OperationalInsights/locations/region-name/operationStatuses/operation-id?api-
version=2020-08-01"
A continuación, puede comprobar el estado de la operación asincrónica mediante el envío de una solicitud GET
al valor del encabezado Azure-AsyncOperation:
GET https://management.azure.com/subscriptions/subscription-
id/providers/microsoft.operationalInsights/locations/region-name/operationstatuses/operation-id?api-
version=2020-08-01
Authorization: Bearer <token>
La respuesta contiene información sobre la operación y su Estado. Puede tener uno de los valores siguientes:
La operación está en curso.
{
"id": "Azure-AsyncOperation URL value from the GET operation",
"name": "operation-id",
"status" : "InProgress",
"startTime": "2017-01-06T20:56:36.002812+00:00",
}
Operación de actualización de identificador de clave en curso
{
"status" : "Updating",
"startTime": "2017-01-06T20:56:36.002812+00:00",
"endTime": "2017-01-06T20:56:56.002812+00:00",
}
La eliminación de recursos del clúster está en curso: cuando se elimina un recurso de clúster que tiene áreas de
trabajo asociadas a áreas de trabajo, se realiza una operación de desasociación para cada una de las áreas de
trabajo en operaciones asincrónicas que pueden tardar unos minutos. Esto no es relevante cuando se elimina
un Clúster sin ningún área de trabajo asociada; en este caso, el recurso de Clústerse elimina inmediatamente.
{
"status" : "Deleting",
"startTime": "2017-01-06T20:56:36.002812+00:00",
"endTime": "2017-01-06T20:56:56.002812+00:00",
}
Operación completada.
{
"status" : "Succeeded",
"startTime": "2017-01-06T20:56:36.002812+00:00",
"endTime": "2017-01-06T20:56:56.002812+00:00",
}
Error en la operación.
{
"status" : "Failed",
"startTime": "2017-01-06T20:56:36.002812+00:00",
"endTime": "2017-01-06T20:56:56.002812+00:00",
"error" : {
"code": "error-code",
"message": "error-message"
}
}
Permitir la suscripción para la implementación de CMK

La funcionalidad de CMK se proporciona en clústeres de Log Analytics dedicados. Para comprobar que
tenemos la capacidad necesaria en la región, es necesario que la suscripción esté en la lista de permitidos de
antemano. Use sus contactos de Microsoft para proporcionar los identificadores de las suscripciones.
IMPORTANT
La función de CMK es regional. La instancia de Azure Key Vault, el recurso Cluster y las áreas de trabajo de Log Analytics
asociadas deben estar en la misma región, pero pueden estar en distintas suscripciones.
Almacenamiento de la clave de cifrado de claves (KEK )

Cree un recurso de Azure Key Vault, o use uno que ya tenga, para generar o importar una clave que se usará
para el cifrado de datos. Azure Key Vault se debe configurar como recuperable para proteger su clave y el
acceso a los datos en Azure Monitor. Puede comprobar esta configuración en las propiedades de Key Vault:
tanto la Eliminación temporal como la Protección de purga deben estar habilitadas.
Esta configuración puede actualizarse a través de la CLI y PowerShell:

eliminación temporal
La Protección de purga protege contra la eliminación forzada del secreto o almacén incluso después de la
eliminación temporal.
Creación de un recurso de clúster
Este recurso se usa como conexión de identidad intermedia entre su instancia de Key Vault y sus áreas de
trabajo de Log Analytics. Después de recibir la confirmación de que las suscripciones se han incluido en la lista
de permitidos, cree un recurso de clúster de Log Analytics en la región en la que se encuentran las áreas de
trabajo.
Debe especificar el nivel (sku) de capacidad de reserva al crear un recurso de Clúster. El nivel de capacidad de
reserva puede estar en el rango de 1000 a 3000 GB por día y se puede actualizar más adelante en etapas de
100. Si necesita un nivel de reserva de capacidad superior a 3000 GB por día, comuníquese con nosotros en
LAIngestionRate@microsoft.com. Más información
La propiedad billingType determina la atribución de facturación para el recurso de Clústery sus datos:
Clúster (valor predeterminado): los costos de Reserva de capacidad para el clúster se atribuyen al recurso
de clúster.
Áreas de trabajo: los costos de Reserva de capacidad para el clúster se atribuyen proporcionalmente a las
áreas de trabajo del clúster. En este caso, se factura una parte del uso del recurso de clúster si el total de
datos ingeridos del día está por debajo de la Reserva de capacidad. Vea Clústeres dedicados de Log
Analytics para obtener más información sobre el modelo de precios del clúster.
NOTE
Después de crear el recurso de clúster, puede actualizarlo con SKU, keyVaultProperties o billingType mediante la
solicitud de REST de PATCH.
Actualmente puede actualizar billingType mediante una solicitud REST, esto no se admite en PowerShell.
Esta operación es asincrónica y puede tardar un tiempo en completarse.
IMPORTANT
Copie y guarde la respuesta, ya que necesitará los detalles en los pasos siguientes.
New-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -

Location "region-name" -SkuCapacity daily-ingestion-gigabyte
PUT https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/Microsoft.OperationalInsights/clusters/<cluster-name>?api-version=2020-08-01
Content-type: application/json
{
"identity": {
"type": "systemAssigned"
},
"sku": {
"name": "capacityReservation",
"Capacity": 1000
},
"properties": {
"billingType": "cluster",
},
"location": "<region-name>",
}
La identidad se asigna al recurso de clúster en el momento de su creación.

Respuesta
200 Correcto y encabezado.
Si bien el aprovisionamiento del clúster de Log Analytics subyacente tarda un poco en completarse, puede
comprobar el estado de aprovisionamiento de dos maneras:
1. Copie el valor de la dirección URL de Azure-AsyncOperation de la respuesta y siga la comprobación del
estado de operaciones asincrónicas.
2. Envíe una solicitud GET en el recurso Clúster y examine el valor provisioningState. Es ProvisioningAccount
mientras se realiza el aprovisionamiento y Succeeded, una vez que se completa.
GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-
Respuesta
{
"identity": {
"type": "SystemAssigned",
"tenantId": "tenant-id",
"principalId": "principal-id"
},
"sku": {
"capacity": 1000,
"lastSkuUpdate": "Sun, 22 Mar 2020 15:39:29 GMT"
},
"properties": {
"provisioningState": "ProvisioningAccount",
"clusterId": "cluster-id"
},
"id": "/subscriptions/subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
"name": "cluster-name",
"type": "Microsoft.OperationalInsights/clusters",
"location": "region-name"
}
El GUID "principalId" se genera desde el servicio de identidad administrada para el recurso Cluster.
Concesión de permisos a Key Vault
Actualice la instancia de Key Vault con una nueva directiva de acceso que conceda permisos al recurso del
clúster. Estos permisos los utiliza el almacenamiento de Azure Monitor subyacente para el cifrado de datos.
Abra su instancia de Key Vault en Azure Portal y haga clic en "Directivas de acceso" y luego en "+ Agregar
directiva de acceso" para crear una nueva directiva con esta configuración:
Permisos de clave: seleccione los permisos "Obtener", "Encapsular clave" y "Desencapsular clave".
Seleccionar entidad de seguridad: escriba el nombre de recurso de clúster o el identificador de la entidad de
seguridad que se devolvió en la respuesta del paso anterior.
El permiso Obtener es necesario para comprobar que su instancia de Azure Key Vault está configurada como
recuperable con el fin de proteger su clave y el acceso a sus datos de Azure Monitor.
Actualización del recurso de clúster con detalles del identificador de clave
Este paso se realiza durante las actualizaciones iniciales y futuras de la versión de la clave en Key Vault. Informa
al almacenamiento de Azure Monitor sobre la versión de la clave que se va a usar para el cifrado de los datos.
Cuando se actualiza, la clave nueva se usa para ajustar y desajustar la clave de almacenamiento (AEK).
Para actualizar el recurso Cluster con los detalles del identificador de clave de Key Vault, seleccione la versión
actual de la clave en Azure Key Vault para obtener detalles del identificador de clave.
Actualice el recurso de clúster "KeyVaultProperties" con los detalles del identificador de clave.
Esta operación es asincrónica cuando se actualizan los detalles del identificador de clave y puede tardar un
tiempo en completarse. Es sincrónica cuando se actualiza el valor de la capacidad.
Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-name" -

KeyVaultUri "key-uri" -KeyName "key-name" -KeyVersion "key-version"
NOTE
Puede actualizar la SKU del recurso de clúster y el valor de keyVaultProperties o billingType mediante PATCH.
PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-
{
"identity": {
},
"sku": {
"capacity": 1000
},
"properties": {
"KeyVaultProperties": {
"KeyVaultUri": "https://<key-vault-name>.vault.azure.net",
"KeyName": "<key-name>",
"KeyVersion": "<current-version>"
}
},
"location":"<region-name>"
}
"KeyVaultProperties" contiene los detalles del identificador de la clave del almacén de claves.
Respuesta
200 Correcto y encabezado. La propagación del identificador de clave tarda unos minutos en completarse.
Puede comprobar el estado de actualización de dos maneras:
2. Envíe una solicitud GET en el recurso Clúster y examine las propiedades KeyVaultProperties. Los detalles del
identificador de clave que actualizó recientemente se deben devolver en la respuesta.
Una respuesta a la solicitud GET en el recurso Clúster debe ser similar a esta cuando se complete la
actualización del identificador de clave:
{
"identity": {
"principalId": "principle-id"
},
"sku": {
"capacity": 1000,
},
"properties": {
"keyVaultProperties": {
"keyVaultUri": "https://key-vault-name.vault.azure.net",
"kyName": "key-name",
"keyVersion": "current-version"
},
"provisioningState": "Succeeded",
},
"id": "/subscriptions/subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.OperationalInsights/clusters/cluster-name",
}
Asociación del área de trabajo con el recurso de clúster

Debe tener permisos de "escritura" en el área de trabajo y en el recurso Cluster para realizar esta operación,
que incluye estas acciones:
En el área de trabajo: Microsoft.OperationalInsights/workspaces/write
En el recurso de clúster: Microsoft.OperationalInsights/clusters/write
IMPORTANT
Este paso solo debe realizarse una vez completada la Log Analytics el aprovisionamiento del clúster. Si asocia áreas de
trabajo e ingiere datos antes del aprovisionamiento, los datos ingeridos se quitarán y no se podrán recuperar.
$clusterResourceId = (Get-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -

ClusterName "cluster-name").id
Set-AzOperationalInsightsLinkedService -ResourceGroupName "resource-group-name" -WorkspaceName "workspace-
name" -LinkedServiceName cluster -WriteAccessResourceId $clusterResourceId
PUT https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/microsoft.operationalinsights/workspaces/<workspace-name>/linkedservices/cluster?api-
version=2020-08-01
{
"properties": {
"WriteAccessResourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/microsoft.operationalinsights/clusters/<cluster-name>"
}
}
Respuesta
Los datos ingeridos se almacenan cifrados con la clave administrada después de la operación de asociación,
que puede tardar hasta 90 minutos en completarse. Puede comprobar el estado de asociación del área de
trabajo de dos maneras:
2. Envíe una solicitud Áreas de trabajo: Get y observe la respuesta, el área de trabajo asociada tendrá un
elemento clusterResourceId en "características".
name>/providers/microsoft.operationalInsights/workspaces/<workspace-name>?api-version=2020-08-01
Respuesta
{
"properties": {
"source": "Azure",
"customerId": "workspace-name",
"sku": {
"name": "pricing-tier-name",
"lastSkuUpdate": "Tue, 28 Jan 2020 12:26:30 GMT"
},
"retentionInDays": 31,
"features": {
"legacy": 0,
"searchVersion": 1,
"enableLogAccessUsingOnlyResourcePermissions": true,
"clusterResourceId": "/subscriptions/subscription-id/resourceGroups/resource-group-
name/providers/Microsoft.OperationalInsights/clusters/cluster-name"
},
"workspaceCapping": {
"dailyQuotaGb": -1.0,
"quotaNextResetTime": "Tue, 28 Jan 2020 14:00:00 GMT",
"dataIngestionStatus": "RespectQuota"
}
},
"id": "/subscriptions/subscription-id/resourcegroups/resource-group-
name/providers/microsoft.operationalinsights/workspaces/workspace-name",
"name": "workspace-name",
}
Revocación de CMK (KEK)

Para revocar el acceso a los datos, deshabilite la clave o elimine la directiva de acceso del recurso Clúster en
Key Vault. El almacenamiento de clúster de Log Analytics siempre respetará los cambios en los permisos de las
claves en el plazo de una hora (normalmente antes), y Storage dejará de estar disponible. Los datos nuevos que
se ingestan en áreas de trabajo asociadas al recurso del clúster se quitan y no se pueden recuperar, no se
puede acceder a los datos y las consultas a estas áreas de trabajo generan un error. Los datos ingeridos
anteriormente permanecerán en el almacenamiento siempre que se no se elimine el recurso Clúster ni las
áreas de trabajo. Los datos inaccesibles se rigen por la directiva de retención de datos y se purgarán cuando se
alcance la retención.
Los datos ingeridos en los últimos 14 días también se conservan en la memoria caché activa (respaldada por
SSD) para un funcionamiento eficaz del motor de consultas. Esto se elimina en la operación de revocación de
claves y también se convierte en inaccesible.
Storage sondeará periódicamente su instancia de Key Vault para intentar desencapsular la clave de cifrado y,
una vez haya obtenido el acceso, procederá con la ingesta de datos y la reanudación de la consulta en un plazo
de 30 minutos.
Rotación de CMK (KEK)

La rotación de CMK necesita una actualización explícita del recurso Clúster con la nueva versión de la clave en
Azure Key Vault. Siga las instrucciones que aparecen en el paso "Actualización del recurso de clúster con
detalles del identificador de clave". Si no actualiza los detalles del identificador de clave en el recurso de clúster,
el almacenamiento de clúster de Log Analytics seguirá usando la clave anterior para cifrado. Si deshabilita o
elimina la clave anterior antes de actualizar la nueva clave en el recurso de clúster, obtendrá el estado de
revocación de clave.
Se puede acceder a todos los datos después de la operación de rotación de claves, incluidos los datos ingeridos
antes y después de la rotación, ya que todos los datos permanecen cifrados mediante la clave de cifrado de
cuenta (AEK), mientras que la AEK ahora se cifra con la nueva versión de la clave de cifrado de claves (KEK).
CMK para consultas

El lenguaje de consulta utilizado en Log Analytics es expresivo y puede contener información confidencial en
los comentarios que se agregan a las consultas o en la sintaxis de la consulta. Algunas organizaciones
requieren que dicha información se mantenga protegida como parte de la directiva de CMK y debe guardar las
consultas cifradas con su clave. Azure Monitor le permite almacenar consultas de búsquedas guardadas y de
alertas del registro cifradas con su clave en su propia cuenta de almacenamiento cuando se conecta al área de
trabajo.
NOTE
Las consultas de Log Analytics se pueden guardar en varios almacenes según el escenario usado. Las consultas
permanecen cifradas con la clave de Microsoft (MMK) en los escenarios siguientes, independientemente de la
configuración de CMK: Libros en Azure Monitor, paneles de Azure, Azure Logic Apps, Azure Notebooks y runbooks de
automatización.
Cuando traiga su propio almacenamiento (BYOS) y lo asocie a su área de trabajo, el servicio carga consultas de
búsquedas guardadas y de alertas del registro a la cuenta de almacenamiento. Esto significa que puede
controlar la cuenta de almacenamiento y la directiva de cifrado en reposo con la misma clave que se usa para
cifrar los datos en el clúster de Log Analytics o con una clave diferente. Sin embargo, será responsable de los
costos asociados a esa cuenta de almacenamiento.
Consideraciones antes de establecer CMK para las consultas
Debe tener permisos de "escritura" en el área de trabajo y la cuenta de almacenamiento.
Asegúrese de crear la cuenta de almacenamiento en la misma región en la que se encuentra el área de
Las búsquedas guardadas en el almacenamiento se consideran artefactos de servicio y su formato puede
cambiar.
Las búsquedas guardadas existentes se eliminan del área de trabajo. Copie las búsquedas guardadas que
necesite antes de la configuración. Puede ver las búsquedas guardadas mediante PowerShell.
No se admite el historial de consultas y no podrá ver las consultas que se han ejecutado.
Puede asociar una sola cuenta de almacenamiento al área de trabajo con el fin de guardar las consultas,
pero se puede usar tanto para las consultas de búsquedas guardadas como para las de alertas del registro.
No se admite el anclaje a un panel.
Configuración de BYOS para las consultas de búsquedas guardadas
Asocie la cuenta de almacenamiento de Consulta con el área de trabajo. Las consultas de búsquedas guardadas
se guardan en la cuenta de almacenamiento.
$storageAccount.Id = Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-

name"
New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName
"workspace-name" -DataSourceType Query -StorageAccountIds $storageAccount.Id
name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Query?api-
version=2020-08-01
{
"properties": {
"dataSourceType": "Query",
"storageAccountIds":
[
"/subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
]
}
}
Después de la configuración, se guardará en el almacenamiento cualquier nueva consulta de búsqueda

guardada.
Configuración de BYOS para las consultas de aler tas del registro
Asocie la cuenta de almacenamiento de Alertas con el área de trabajo. Las consultas de alertas del registro se
guardan en la cuenta de almacenamiento.
$storageAccount.Id = Get-AzStorageAccount -ResourceGroupName "resource-group-name" -Name "storage-account-

name"
New-AzOperationalInsightsLinkedStorageAccount -ResourceGroupName "resource-group-name" -WorkspaceName
"workspace-name" -DataSourceType Alerts -StorageAccountIds $storageAccount.Id
name>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>/linkedStorageAccounts/Alerts?
api-version=2020-08-01
{
"properties": {
"dataSourceType": "Alerts",
"storageAccountIds":
[
"/subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/Microsoft.Storage/storageAccounts/<storage-account-name>"
]
}
}
Después de la configuración, se guardará en el almacenamiento cualquier nueva consulta de alertas.
Administración de CMK
Obtenga todos los recursos Cluster para un grupo de recursos
Get-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name"
name>/providers/Microsoft.OperationalInsights/clusters?api-version=2020-08-01
Respuesta
{
"value": [
{
"identity": {
"principalId": "principal-Id"
},
"sku": {
"capacity": 1000,
},
"properties": {
"keyVaultProperties": {
"keyVaultUri": "https://key-vault-name.vault.azure.net",
"keyName": "key-name",
"keyVersion": "current-version"
},
},
"id": "/subscriptions/subscription-id/resourcegroups/resource-group-
name/providers/microsoft.operationalinsights/workspaces/workspace-name",
}
]
}
Obtenga todos los recursos Cluster para una suscripción
Get-AzOperationalInsightsCluster
GET https://management.azure.com/subscriptions/<subscription-
id>/providers/Microsoft.OperationalInsights/clusters?api-version=2020-08-01
Respuesta
Se obtiene la misma respuesta que para los recursos de clúster de un grupo de recursos, pero en el
ámbito de la suscripción.
Actualización de la reser va de capacidad en el recurso de clúster
Cuando cambie el volumen de datos en las áreas de trabajo asociadas con el tiempo y desee actualizar
el nivel de reserva de capacidad adecuadamente. Siga la actualización del recurso de clúster y
proporcione el valor de la nueva capacidad. Puede estar en el rango de 1000 a 3000 GB por día y en
pasos de 100. Para un nivel superior a 3000 GB por día, comuníquese con su contacto de Microsoft para
habilitarlo. Tenga en cuenta que no tiene que proporcionar el cuerpo completo de la solicitud de REST,
pero debe incluir la SKU:
Update-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-

name" -SkuCapacity "daily-ingestion-gigabyte"
{
"sku": {
"Capacity": 1000
}
}
Actualizar billingType en el recurso de clúster

La propiedad billingType determina la atribución de facturación para el recurso de Clústery sus datos:
Clúster (valor predeterminado): la facturación se atribuye a la suscripción que hospeda los recursos
de Clúster
Áreas de trabajo: la facturación se atribuye a las suscripciones que hospedan las áreas de trabajo de
forma proporcional
Siga las actualización del recurso de clúster y proporcione el valor de billingType. Tenga en cuenta que
no tiene que proporcionar el cuerpo completo de la solicitud de REST y debe incluir el billingType:
{
"properties": {
}
}
Desasociar área de trabajo

Necesita permisos de escritura en el área de trabajo y en el Clúster para realizar esta operación. Puede
desasociar las áreas de trabajo del recurso de clúster en cualquier momento. Los nuevos datos ingeridos
se almacenan en el almacenamiento compartido de Log Analytics y se cifran con la clave de Microsoft.
Puede consultar los datos ingeridos en el área de trabajo antes y después de la desasociación sin
problemas, si el recurso Clúster se aprovisiona y se configura con una clave de Key Vault válida.
Remove-AzOperationalInsightsLinkedService -ResourceGroupName "resource-group-name" -Name "workspace-
name" -LinkedServiceName cluster
DELETE https://management.azure.com/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/microsoft.operationalinsights/workspaces/<workspace-name>/linkedservices/cluster?
api-version=2020-08-01
Respuesta
Los datos ingeridos después de que la operación de desasociación se almacena en el almacenamiento
de Log Analytics, esto puede tardar 90 minutos en completarse. Puede comprobar el estado de
asociación del área de trabajo de dos maneras:
1. Copie el valor de la dirección URL de Azure-AsyncOperation de la respuesta y siga la comprobación
del estado de operaciones asincrónicas.
2. Envíe una solicitud Áreas de trabajo: observe la respuesta, el área de trabajo asociada no tendrá un
elemento clusterResourceId en características.
Comprobación del estado de la asociación del área de trabajo
Realice una operación Get en el área de trabajo y observe si la propiedad clusterResourceId presente en
la respuesta en la sección features. El área de trabajo asociada tendrá la propiedad clusterResourceId.
Get-AzOperationalInsightsWorkspace -ResourceGroupName "resource-group-name" -Name "workspace-name"
Elimine el recurso de clúster

Necesita permisos de escritura en el recurso Clúster para realizar esta operación. Se realiza una
operación de eliminación temporal para permitir la recuperación del recurso Cluster, incluidos los datos
de un período de catorce días, tanto si la eliminación fue accidental como si fue intencionada. El nombre
del recurso Cluster permanece reservado durante el período de eliminación temporal y no se puede
crear un nuevo clúster con ese nombre. Después del período de eliminación temporal, se libera el
nombre del recurso Clúster. El recurso Clúster y los datos se eliminan de forma permanente y no se
pueden recuperar. Cualquier área de trabajo asociada se desasocia del recurso Clúster en la operación
de eliminación. Los nuevos datos ingeridos se almacenan en el almacenamiento compartido de Log
Analytics y se cifran con la clave de Microsoft.
La operación de desasociar áreas de trabajo es asincrónica y puede tardar hasta 90 minutos en
completarse.
Remove-AzOperationalInsightsCluster -ResourceGroupName "resource-group-name" -ClusterName "cluster-

name"
DELETE https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group-
Respuesta
200 OK
Recuperar el recurso clúster y los datos
Un recurso Clúster que se eliminó durante los últimos 14 días se encuentra en estado de eliminación
temporal y se puede recuperar. Dado que todas las áreas de trabajo se han desasociado del recurso de
Clústercon eliminación de recursos de Clúster, debe volver a asociar las áreas de trabajo después de la
recuperación para el cifrado de CMK. Actualmente, el grupo de productos lo realiza de forma manual.
Use el canal de Microsoft para las solicitudes de recuperación.
Limitaciones y restricciones
La CMK es compatible con un clúster de Log Analytics dedicado y adecuado para los clientes que envían
1 TB al día o más.
El número máximo de los recursos Cluster por región y suscripción es 2.
Puede asociar un área de trabajo al recurso Cluster y, a continuación, desasociarla si no se requiere CMK
para el área de trabajo. El número de asociaciones del área de trabajo en un área de trabajo
determinada en un período de 30 días se limita a 2.
La asociación de los recursos Cluster al área de trabajo SOLO se debe llevar a cabo después de
comprobar que se completó el aprovisionamiento del clúster de Log Analytics. Los datos que se envíen
al área de trabajo antes de que se complete el aprovisionamiento se eliminarán y no se podrán
recuperar.
El cifrado de CMK se aplica a los datos ingeridos después de la configuración de CMK. Los datos que se
ingieren antes de la configuración de CMK permanecen cifrados con la clave de Microsoft. Puede
consultar fácilmente los datos ingeridos antes y después de la configuración de CMK.
La instancia de Azure Key Vault debe configurarse como recuperable. Las siguientes propiedades no
están habilitadas de forma predeterminada y deben configurarse mediante la CLI o PowerShell:
eliminación temporal
La protección de purgas debe estar activada si quiere tener protección frente a posibles
eliminaciones forzadas de secretos o del almacén, incluso después de su eliminación temporal.
Actualmente no se admite el traslado de un recurso de clúster a otro grupo de recursos o a otra
suscripción.
La instancia de Azure Key Vault, el recurso del clúster y las áreas de trabajo asociadas deben estar en la
misma región y en el mismo inquilino de Azure Active Directory (Azure AD), pero pueden estar en
distintas suscripciones.
Se producirá un error al asociar el área de trabajo a un recurso de clúster si está asociada a otro recurso
de clúster.
Comportamiento con la disponibilidad de Key Vault
En el funcionamiento normal, Storage almacena en caché la AEK durante breves períodos de
tiempo y vuelve regularmente a Key Vault para desajustarla.
En el caso de los errores de conexión transitorios (tiempos de espera, errores de conexión,
problemas de DNS), Storage permite que las claves permanezcan en la memoria caché durante
un período de tiempo más prolongado; así es más fácil resolver pequeños problemas de
disponibilidad. Las funciones de consulta e ingesta continúan sin interrupción.
La falta de disponibilidad de un sitio activo durante unos 30 minutos hará que la cuenta de
Storage deje de estar disponible. La función de consulta no está disponible y los datos ingeridos
se copian en caché durante varias horas mediante la clave de Microsoft para evitar la pérdida de
datos. Cuando se restaura el acceso a Key Vault, la consulta está disponible y los datos copiados
en caché temporalmente se ingieren en el almacén de datos y se cifran con CMK.
Frecuencia de acceso a Key Vault: la frecuencia con la que Azure Monitor Storage accede a Key
Vault para las operaciones de encapsulado y desencapsulado es de entre 6 y 60 segundos.
Si crea un recurso de clúster y especifica el valor de KeyVaultProperties inmediatamente, puede
producirse un error en la operación, ya que la directiva de acceso no se puede definir hasta que se
asigne la identidad del sistema al recurso de clúster.
Si actualiza el recurso existente de clúster con KeyVaultProperties y la directiva de acceso de clave
"Obtener" no se encuentra en Key Vault, se producirá un error en la operación.
Si se produce un error de conflicto al crear un recurso Clúster, es posible que haya eliminado el recurso
Clúster en los últimos 14 días y que esté en un período de eliminación temporal. El nombre del recurso
Cluster permanece reservado durante el período de eliminación temporal y no se puede crear un nuevo
clúster con ese nombre. El nombre se libera después del período de eliminación temporal cuando el
recurso Clúster se elimine de forma permanente.
Si actualiza su recurso Cluster mientras una operación está en curso, se producirá un error en dicha
operación.
Si no puede implementar el recurso de clúster, compruebe que el recurso de clúster de Azure Key Vault
y las áreas de trabajo de Log Analytics asociadas se encuentran en la misma región. Puede estar en
distintas suscripciones.
Si actualiza la versión de la clave en Key Vault y no actualiza los nuevos detalles del identificador de
clave en el recurso Clúster, el clúster de Log Analytics seguirá usando la clave anterior y los datos serán
inaccesibles. Actualice los nuevos detalles de identificador de clave del recurso de Clúster para reanudar
la ingesta de datos y la capacidad de consultar los datos.
Algunas operaciones son largas y pueden tardar un tiempo en completarse: estas operaciones son
Cluster create, Cluster key update y Cluster delete. Puede comprobar el estado de la operación de dos
maneras:
1. Cuando se utiliza REST, copie el valor de la dirección URL de Azure-AsyncOperation de la respuesta y
siga la comprobación del estado de operaciones asincrónicas.
2. Envíe una solicitud GET al clúster o al área de trabajo y observe la respuesta. Por ejemplo, un área de
trabajo sin asociar no tendrá el elemento clusterResourceId en la sección features.
Para obtener soporte técnico y ayuda relacionada con la clave administrada por el cliente, use sus
contactos en Microsoft.
Mensajes de error
Creación de un recurso Cluster:
400: El nombre del clúster no es válido. El nombre del clúster puede contener los caracteres a-z, A-Z,
0-9 y una longitud de 3 a 63.
400: El cuerpo de la solicitud es NULL o tiene un formato incorrecto.
400: El nombre de SKU no es válido. Establezca el nombre de SKU en capacityReservation.
400: Se proporcionó Capacity, pero la SKU no es capacityReservation. Establezca el nombre de la SKU
en capacityReservation.
400: Falta Capacity en la SKU. Establezca el valor de Capacity en 1000 o más en incrementos de
100 (GB).
400: Capacity en la SKU no está en el rango. Debe ser 1000 como mínimo y hasta la capacidad
máxima permitida que está disponible en "Uso y costos estimados" en el área de trabajo.
400: Capacity está bloqueado durante 30 días. Se permite la reducción de la capacidad 30 días
después de la actualización.
400: No se estableció ninguna SKU. Establezca el nombre de la SKU en capacityReservation y el valor
de Capacity en 1000 o más en incrementos de 100 (GB).
400: Identity es NULL o está vacío. Establezca Identity en el tipo systemAssigned.
400: KeyVaultProperties se estableció en la creación. Actualice KeyVaultProperties después de la
creación del clúster.
400: No se puede ejecutar la operación ahora. La operación asincrónica está en un estado distinto del
correcto. El clúster debe completar su operación antes de realizar cualquier operación de
actualización.
Actualización del recurso Cluster
400: El clúster está en estado de eliminación. La operación asincrónica está en curso. El clúster debe
completar su operación antes de realizar cualquier operación de actualización.
400: KeyVaultProperties no está vacío, pero tiene un formato incorrecto. Consulte actualización de
identificador de clave.
400: No se pudo validar la clave en Key Vault. Podría deberse a la falta de permisos o a que la clave
no existe. Verifique que estableció la clave y la directiva de acceso en Key Vault.
400: No se puede recuperar la clave. Key Vault debe establecerse para la eliminación temporal y
protección de purga. Consulte la documentación de Key Vault.
400: No se puede ejecutar la operación ahora. Espere a que se complete la operación asincrónica e
inténtelo de nuevo.
400: El clúster está en estado de eliminación. Espere a que se complete la operación asincrónica e
inténtelo de nuevo.
Obtención del recurso Cluster:
404: No se encontró el clúster, es posible que se haya eliminado. Si intenta crear un clúster con ese
nombre y obtiene un conflicto, el clúster se encuentra en eliminación temporal durante 14 días.
Puede ponerse en contacto con soporte técnico para recuperarlo o usar otro nombre para crear un
nuevo clúster.
Eliminación del recurso Cluster:
409: No se puede eliminar un clúster mientras está en estado de aprovisionamiento. Espere a que se
complete la operación asincrónica e inténtelo de nuevo.
Asociación del área de trabajo:
404: No se encuentra el área de trabajo. El área de trabajo que especificó no existe o se eliminó.
409: Operación en curso de asociación o desasociación del área de trabajo.
400: No se encontró el clúster, el clúster que especificó no existe o se eliminó. Si intenta crear un
clúster con ese nombre y obtiene un conflicto, el clúster se encuentra en eliminación temporal
durante 14 días. Puede ponerse en contacto con el soporte técnico para recuperarlo.
Desasociación del área de trabajo:
404: No se encuentra el área de trabajo. El área de trabajo que especificó no existe o se eliminó.
409: Operación en curso de asociación o desasociación del área de trabajo.
Uso de Azure Private Link para conectar redes a
Azure Monitor de forma segura
IMPORTANT
Por el momento, debe solicitar acceso para poder usar esta función. Puede solicitar acceso mediante el formulario de
suscripción.
Azure Private Link le permite vincular de forma segura los servicios PaaS de Azure a la red virtual mediante
puntos de conexión privados. Para muchos servicios, solo tiene que configurar un punto de conexión por recurso.
Sin embargo, Azure Monitor es una constelación de diferentes servicios interconectados que funcionan
conjuntamente para supervisar las cargas de trabajo. Como consecuencia de ello, hemos creado un recurso
denominado Ámbito de Private Link de Azure Monitor (AMPLS) que le permite definir los límites de la red de
supervisión y conectarse a la red virtual. En este artículo se explica cuándo usar y cómo configurar un Ámbito de
Private Link de Azure Monitor.
Ventajas
Con Private Link puede:
Conectarse de forma privada a Azure Monitor sin necesidad de abrir ningún acceso a la red pública
Asegurarse de que solo se accede a los datos de supervisión a través de redes privadas autorizadas
Impedir la filtración de datos de las redes privadas mediante la definición de recursos de Azure Monitor
específicos que se conectan a través del punto de conexión privado
Conectar de forma segura la red local privada a Azure Monitor mediante ExpressRoute y Private Link
Mantener todo el tráfico dentro de la red troncal de Microsoft Azure
Para más información, consulte Ventajas principales de Private Link.
Funcionamiento
El Ámbito de Private Link de Azure Monitor es un recurso de agrupación para conectar uno o varios puntos de
conexión privados (y, por tanto, las redes virtuales en las que se encuentran) a uno o más recursos de Azure
Monitor. Estos recursos incluyen las áreas de trabajo de Log Analytics y los componentes de Application Insights.
NOTE
Un único recurso de Azure Monitor puede pertenecer a varios AMPLS, pero no puede conectar una sola red virtual a más
de un AMPLS.
Planeación basada en la red

Antes de configurar los recursos de AMPLS, tenga en cuenta los requisitos de aislamiento de la red. Evalúe el
acceso de las redes virtuales a Internet pública y las restricciones de acceso de cada uno de los recursos de Azure
Monitor (es decir, los componentes de Application Insights y las áreas de trabajo de Log Analytics).
Evaluación de qué redes virtuales deben conectarse a Private Link
Empiece por evaluar qué redes virtuales (Vnet) tienen acceso restringido a Internet. Es posible que las redes
virtuales que tienen Internet gratis no requieran Private Link para acceder a los recursos de Azure Monitor. Los
recursos de supervisión a los que se conectan las redes virtuales pueden restringir el tráfico entrante y requerir
una conexión de Private Link (ya sea para la consulta o la ingesta de registros). En tales casos, incluso una red
virtual que tenga acceso a Internet pública necesita conectarse a estos recursos a través de Private Link y de un
AMPLS.
Evaluación de qué recursos de Azure Monitor deben tener Private Link
Revisión de cada uno de los recursos de Azure Monitor:
¿Debería el recurso permitir la ingesta de registros de recursos ubicados solo en redes virtuales específicas?
¿Deben consultar el recurso solo los clientes ubicados en redes virtuales específicas?
Si la respuesta a alguna de estas preguntas es afirmativa, establezca las restricciones tal y como se explica en
Configuración de áreas de trabajo de Log Analytics y Configuración de los componentes de Application Insights y
asocie estos recursos a uno o varios AMPLS. Las redes virtuales que deben acceder a estos recursos de
supervisión deben tener un punto de conexión privado que se conecte al AMPLS pertinente. Recuerde: puede
conectar las mismas áreas de trabajo o la misma aplicación a varios AMPLS, para permitir que las diferentes
redes puedan llegar a ellas.
Agrupación de los recursos de supervisión por accesibilidad de red
Dado que cada red virtual se puede conectar a un solo recurso de AMPLS, debe agrupar los recursos de
supervisión que deben ser accesibles a las mismas redes. La manera más sencilla de administrar esta agrupación
es crear un AMPLS por red virtual y seleccionar los recursos para conectarse a esa red. Sin embargo, para reducir
los recursos y mejorar la capacidad de administración, puede que desee reutilizar un AMPLS entre redes.
Por ejemplo, si las redes virtuales internas VNet1 y VNet2 deben conectarse a las áreas de trabajo Workspace1 y
Workspace2 y al componente Application Insights 3 de Application Insights, asocie los tres recursos al mismo
AMPLS. Si VNet3 solo accede a Workspace1, cree otro recurso de AMPLS, asocie Workspace1 a dicho recurso y
conecte VNet3 tal y como se muestra en los diagramas siguientes:
Consideración de los límites
Hay una serie de límites que se deben tener en cuenta al planear la configuración de Private Link:
Una red virtual solo puede conectarse a 1 objeto de AMPLS. Esto significa que el objeto de AMPLS debe
proporcionar acceso a todos los recursos de Azure Monitor a los que debería tener acceso la red virtual.
Un recurso de Azure Monitor (área de trabajo o componente de Application Insights) puede conectarse a 5
AMPLS como máximo.
Un objeto de AMPLS puede conectarse a 20 recursos como máximo de Azure Monitor.
Un objeto de AMPLS puede conectarse a 10 puntos de conexión privados como máximo.
En la topología siguiente:
Cada red virtual se conecta a 1 objeto de AMPLS, por lo que no se puede conectar a otros AMPLS.
AMPLS B se conecta a 2 redes virtuales: usa 2 de sus 10 conexiones posibles de punto de conexión privado.
AMPLS A se conecta a 2 áreas de trabajo y a 1 componente de Application Insights: usa 3 de sus 20 recursos
posibles de Azure Monitor.
El área de trabajo 2 se conecta a AMPLS A y AMPLS B: usa 2/5 de sus posibles conexiones AMPLS.
Conexión de ejemplo
Empiece por crear un recurso de Ámbito de Private Link de Azure Monitor.
1. Vaya a Crear un recurso en Azure Portal y busque Azure Monitor Private Link Scope (Ámbito de
Private Link de Azure Monitor).
2. Haga clic en create (crear).

3. Seleccione una suscripción y un grupo de recursos.
4. Asigne un nombre al AMPLS. Es mejor usar un nombre que deje claro qué finalidad y límite de seguridad
usará el ámbito para que alguien no rompa accidentalmente los límites de seguridad de la red. Por
ejemplo, "AppServerProdTelem".
5. Haga clic en Revisar y crear .
6. Deje que se supere la validación y luego haga clic en Crear .
Conexión de recursos de Azure Monitor

Puede conectar su AMPLS primero a los puntos de conexión privados y luego a los recursos de Azure Monitor, o
viceversa, pero el proceso de conexión es más rápido si comienza con los recursos de Azure Monitor. A
continuación se describe cómo conectamos las áreas de trabajo de Log Analytics de Azure Monitor y los
componentes de Application Insights a un AMPLS.
1. En el ámbito de Private Link de Azure Monitor, haga clic en Azure Monitor Resources (Recursos de
Azure Monitor) en el menú de la izquierda. Haga clic en el botón Agregar .
2. Agregue el área de trabajo o el componente. Al hacer clic en el botón Agregar aparece un cuadro de
diálogo en el que puede seleccionar los recursos de Azure Monitor. Puede examinar las suscripciones y los
grupos de recursos, o puede escribir su nombre para filtrarlos. Seleccione el área de trabajo o
componente y haga clic en Aplicar para agregarlos al ámbito.
Conexión a un punto de conexión privado
Ahora que tiene recursos conectados a su AMPLS, cree un punto de conexión privado para conectar nuestra red.
Puede realizar esta tarea en el centro de Private Link de Azure Portal o en el Ámbito de Private Link de Azure
Monitor, como se hace en este ejemplo.
1. En el recurso de ámbito, haga clic en Conexiones de punto de conexión privado en el menú de
recursos de la izquierda. Haga clic en Punto de conexión privado para iniciar el proceso de creación del
punto de conexión. Aquí también puede aprobar las conexiones que se iniciaron en el centro de Private
Link seleccionándolas y haciendo clic en Aprobar .
2. Seleccione la suscripción, el grupo de recursos y el nombre del punto de conexión, así como la región en
la que debe residir. La región debe ser la misma región que la red virtual a la que la conectará.
3. Haga clic en Siguiente: Resource (Siguiente: Recurso).
4. En la pantalla Recurso,
a. En Suscripción , seleccione la suscripción que contiene el recurso de Ámbito de Private Link de Azure
Monitor.
b. Para Tipo de recurso , elija Microsoft.insights/privateLinkScopes .
c. En la lista desplegable Recurso , elija el ámbito de Private Link que creó anteriormente.
d. Haga clic en Siguiente: Configuración > .
5. En el panel de configuración,
a. Elija el red vir tual y la subred a las que desea conectar los recursos de Azure Monitor.
b. Elija Sí para Integrar con la zona DNS privada y permita que cree automáticamente una nueva zona
DNS privada. Las zonas DNS reales pueden ser distintas de las que se muestran en la siguiente captura de
pantalla.
c. Haga clic en Revisar + crear .
d. Permita que la validación se supere.
e. Haga clic en Crear .
Ahora ha creado un nuevo punto de conexión privado que está conectado a este Ámbito de Private Link de Azure
Monitor.
Configuración de Log Analytics

Vaya a Azure Portal. En el recurso del área de trabajo de Log Analytics, hay un elemento de menú Network
Isolation (Aislamiento de red) en el lado izquierdo. En este menú puede controlar dos estados diferentes.
En primer lugar, puede conectar este recurso de Log Analytics a cualquier ámbito de Private Link de Azure
Monitor al que tenga acceso. Haga clic en Agregar y seleccione el Ámbito de Private Link de Azure Monitor. Haga
clic en Aplicar para conectarlo. Todos los ámbitos conectados aparecen en esta pantalla. Gracias a esta conexión,
el tráfico de red de las redes virtuales conectadas llega a esta área de trabajo. La creación de la conexión tiene el
mismo efecto realizar la conexión desde el ámbito que creamos en Conexión de recursos de Azure Monitor.
En segundo lugar, puede controlar cómo se puede acceder a este recurso desde fuera de los ámbitos de Private
Link enumerados anteriormente. Si establece Allow public network access for ingestion (Permitir el acceso
de la red pública para la ingesta) en No , las máquinas que se encuentren fuera de los ámbitos conectados no
podrán cargar datos en esta área de trabajo. Si establece Allow public network access for queries (Permitir
el acceso a la red pública para las consultas) en No , las máquinas que se encuentren fuera de los ámbitos no
podrán acceder a los datos de esta área de trabajo. Estos datos incluyen el acceso a libros, paneles, experiencias
de cliente basadas en la API de consulta, conclusiones en el Azure Portal, etc. Las experiencias que se ejecutan
fuera de Azure Portal y que consultan los datos de Log Analytics también deben ejecutarse dentro de la red
virtual vinculada privada.
Restringir el acceso de esta manera solo se aplica a los datos del área de trabajo. Los cambios de configuración,
incluida la activación o desactivación de esta configuración de acceso, se administran mediante Azure Resource
Manager. Restrinja el acceso a Resource Manager mediante las funciones, los permisos, los controles de red y la
auditoría adecuados. Para más información, consulte Roles, permisos y seguridad en Azure Monitor.
NOTE
Los registros y las métricas que se cargan en un área de trabajo a través de Configuración de diagnóstico pasan por un
canal de Microsoft privado seguro y no se controlan mediante esta configuración.

Vaya a Azure Portal. En el recurso del componente de Application Insights de Azure Monitor se encuentra el
elemento de menú Aislamiento de red en el lado izquierdo. En este menú puede controlar dos estados
diferentes.
En primer lugar, puede conectar este recurso de Application Insights a ámbitos de Private Link de Azure Monitor
a los que tenga acceso. Haga clic en Agregar y seleccione el Ámbito de Private Link de Azure Monitor .
Haga clic en Aplicar para conectarlo. Todos los ámbitos conectados aparecen en esta pantalla. Gracias a esta
conexión, el tráfico de red de las redes virtuales conectadas llega a este componente. La creación de la conexión
tiene el mismo efecto realizar la conexión desde el ámbito que creamos en Conexión de recursos de Azure
Monitor.
En segundo lugar, puede controlar cómo se puede acceder a este recurso desde fuera de los ámbitos de Private
Link enumerados anteriormente. Si establece Allow public network access for ingestion (Permitir el acceso
de la red pública para la ingesta) en No , las máquinas o los SDK que se encuentren fuera de los ámbitos
conectados no podrán cargar datos en este componente. Si establece Allow public network access for
queries (Permitir el acceso a la red pública para las consultas) en No , las máquinas que se encuentren fuera de
los ámbitos no podrán acceder a los datos de este recurso de Application Insights. Estos datos incluyen el acceso
a los registros de APM, las métricas y la transmisión de métricas en directo, así como experiencias basadas en
ellos, como libros, paneles, experiencias de cliente basadas en API de consulta, conclusiones de Azure Portal, etc.
Tenga en cuenta que las experiencias de consumo que no son del portal también tienen que ejecutarse dentro de
la red virtual vinculada privada que incluye las cargas de trabajo supervisadas.
Tendrá que agregar recursos que hospeden las cargas de trabajo supervisadas al vínculo privado. Aquí está la
documentación sobre cómo hacer esto para App Services.
Restringir el acceso de esta manera solo se aplica a los datos del recurso de Application Insights. Los cambios de
configuración, incluida la activación o desactivación de esta configuración de acceso, se administran mediante
Azure Resource Manager. En su lugar, restrinja el acceso a Resource Manager mediante las funciones, los
permisos, los controles de red y la auditoría adecuados. Para más información, consulte Roles, permisos y
seguridad en Azure Monitor.
NOTE
Para proteger completamente la instancia de Application Insights basada en el área de trabajo, debe bloquear tanto el
acceso al recurso de Application Insights como el área de trabajo de Log Analytics subyacente.
Los diagnósticos de nivel de código (Perfilador/Depurador) deben proporcionar su propia cuenta de almacenamiento para
admitir el vínculo privado. Esta es documentación sobre cómo hacerlo.
Uso de API y de la línea de comandos

Puede automatizar el proceso descrito anteriormente mediante plantillas de Azure Resource Manager y las
interfaces de la línea de comandos.
Para crear y administrar ámbitos de Private Link, use az monitor private-link-scope. Con este comando, puede
crear ámbitos, asociar áreas de trabajo de Log Analytics y componentes de Application Insights, y agregar, quitar
o aprobar puntos de conexión privados.
Para administrar el acceso a la red, utilice las marcas [--ingestion-access {Disabled, Enabled}] y
[--query-access {Disabled, Enabled}] en áreas de trabajo de Log Analytics o componentes de Application
Insights.
Recopilación de registros personalizados a través de Private Link

Las cuentas de almacenamiento se usan en el proceso de ingesta de registros personalizados. De forma
predeterminada, se usan cuentas de almacenamiento administradas por el servicio. Sin embargo, para ingerir
registros personalizados en vínculos privados, debe usar sus propias cuentas de almacenamiento y asociarlas a
áreas de trabajo de Log Analytics. Vea más detalles sobre cómo configurar tales cuentas mediante la línea de
comandos.
Para obtener más información sobre cómo traer su propia cuenta de almacenamiento, consulte Cuentas de
almacenamiento propiedad del cliente para la ingesta de registros
Restricciones y limitaciones
Agentes
Las versiones más recientes de los agentes de Windows y Linux deben usarse en redes privadas para permitir la
ingesta de telemetría segura en áreas de trabajo de Log Analytics. Las versiones anteriores no pueden cargar
datos de supervisión en una red privada.
Agente de Windows de Log Analytics
Use la versión 10.20.18038.0, o una posterior, del agente de Log Analytics.
Agente de Linux de Log Analytics
Use la versión 1.12.25, o una posterior, del agente. Si no puede, ejecute los siguientes comandos en la máquina
virtual.
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>
Azure portal
Para usar las experiencias del portal de Azure Monitor, como Application Insights y Log Analytics, debe permitir
que se pueda acceder a las extensiones de Azure Portal y Azure Monitor en las redes privadas. Agregue las
etiquetas de servicio AzureActiveDirector y , AzureResourceManager , AzureFrontDoor.FirstPar ty y
AzureFrontdoor.Frontend al firewall.
Acceso mediante programación
Para usar la API REST, la CLI o PowerShell con Azure Monitor en redes privadas, agregue las etiquetas de servicio
AzureActiveDirector y y AzureResourceManager al firewall.
La incorporación de estas etiquetas permite realizar acciones como consultar datos de registro así como crear y
administrar áreas de trabajo de Log Analytics y componentes de Application Insights.
Descargas de SDK de Application Insights desde una red de entrega de contenido
Agrupe el código JavaScript en el script para que el explorador no intente descargar código desde una red CDN.
En GitHub se proporciona un ejemplo.
Descarga de soluciones de Log Analytics
Para permitir que el agente de Log Analytics descargue paquetes de soluciones, agregue los nombres de dominio
completos correspondientes a la lista de permitidos del firewall.
EN TO RN O EN L A N UB E REC URSO DEL A GEN T E P UERTO S DIREC C IÓ N
Azure Public scadvisorcontent.blob.core. 443 Salida

windows.net
Azure Government usbn1oicore.blob.core.usgo 443 Salida

vcloudapi.net
Azure China 21Vianet mceast2oicore.blob.core.chi 443 Salida

nacloudapi.cn
Configuración de DNS del explorador

Si se va a conectar a los recursos de Azure Monitor a través de un vínculo privado, el tráfico a estos recursos
debe pasar por el punto de conexión privado que está configurado en la red. Para habilitar el extremo privado,
actualice la configuración de DNS tal como se explica en Conectarse a un punto de conexión privado. Algunos
exploradores usan su propia configuración de DNS en lugar de las que se establecen. Es posible que el
explorador intente conectarse a los puntos de conexión públicos de Azure Monitor y omitir por completo el
vínculo privado. Compruebe que la configuración de su explorador no invalide ni guarde en caché la
configuración de DNS anterior.
Pasos siguientes
Obtener información sobre el almacenamiento privado.
Cuentas de almacenamiento de propiedad del
cliente para la ingesta de registros en Azure Monitor
Azure Monitor usa cuentas de almacenamiento en el proceso de ingesta de algunos tipos de datos tales como
registros personalizados y algunos registros de Azure. Durante el proceso de ingesta, los registros se envían
primero a una cuenta de almacenamiento y, posteriormente, se ingieren en Log Analytics o Application Insights. Si
quiere controlar los datos durante la ingesta, puede usar sus propias cuentas de almacenamiento en lugar del
almacenamiento administrado por el servicio. El uso de su propia cuenta de almacenamiento le proporciona
control sobre el acceso, el contenido, el cifrado y la retención de los registros durante la ingesta. Llamamos a esto
Traiga su propio almacenamiento (BYOS).
Un escenario que requiere BYOS es el aislamiento de red a través de vínculos privados. Cuando se usa una red
virtual, el aislamiento de red suele ser un requisito y el acceso a Internet público es limitado. En tales casos, el
acceso al almacenamiento de servicio de Azure Monitor para la ingesta de registros está completamente
bloqueado o se considera como procedimiento incorrecto. En su lugar, los registros se deben ingerir a través de
una cuenta de almacenamiento propiedad del cliente dentro de la red virtual o fácilmente accesible desde ella.
Otro escenario es el cifrado de los registros con claves administradas por el cliente (CMK). Los clientes pueden
cifrar los datos registrados mediante CMK en los clústeres que almacenan los registros. También se puede usar la
misma clave para cifrar los registros durante el proceso de ingesta.
Tipos de datos compatibles

Entre los tipos de datos que se ingieren desde una cuenta de almacenamiento se incluyen los siguientes. Consulte
Recopilación de datos de Azure Diagnostics Extension en los registros de Azure Monitor para más información
sobre la ingesta de estos tipos.
T IP O IN F O RM A C IÓ N DE TA B L A
Registros IIS Blob: wad-iis-logfiles
Registros de eventos de Windows Tabla: WADWindowsEventLogsTable
syslog Tabla: LinuxsyslogVer2v0
Registros de ETW de Windows Tabla: WADETWEventTable
Service Fabric Tabla: WADServiceFabricSystemEventTable

WADServiceFabricReliableActorEventTable
WADServiceFabricReliableServicEventTable
Registros personalizados N/D
Archivos de volcado de memoria de Watson de Azure N/D

Security Center
Requisitos de la cuenta de almacenamiento

La cuenta de almacenamiento debe cumplir los requisitos siguientes:
Accesible para los recursos de la red virtual que escriben registros en el almacenamiento.
Debe estar en la misma región que el área de trabajo a la que está vinculada.
Permitir acceso de Azure Monitor: si eligió limitar el acceso de la cuenta de almacenamiento a redes
seleccionadas, asegúrese de permitir esta excepción: permitir que los servicios de Microsoft de confianza
accedan a esta cuenta de almacenamiento.
Proceso para configurar el almacenamiento propiedad del cliente

El proceso básico de usar su propia cuenta de almacenamiento para la ingesta es el siguiente:
1. Cree una cuenta de almacenamiento o seleccione una cuenta existente.
2. Vincule la cuenta de almacenamiento a un área de trabajo de Log Analytics.
3. Administre el almacenamiento revisando su carga y retención para asegurarse de que funciona según lo
previsto.
El único método disponible para crear y quitar vínculos es a través de la API REST. En las secciones siguientes se
proporcionan detalles sobre la solicitud de API específica necesaria para cada proceso.
Línea de comandos y API de REST

Línea de comandos
Para crear y administrar cuentas de almacenamiento vinculadas, use az monitor log-analytics workspace linked-
storage. Este comando puede vincular y desvincular cuentas de almacenamiento de un área de trabajo y
enumerar las cuentas de almacenamiento vinculadas.
Valores de la solicitud y la CLI
dataSourceType
AzureWatson: use este valor para los archivos de volcado de memoria de Watson de Azure Security Center.
CustomLogs: use este valor para estos tipos de datos:
Registros IIS
Eventos (Windows)
Syslog (Linux)
Registros de ETW
Eventos de Service Fabric
Datos de evaluación
storage_account_resource_id
Este valor usa la estructura siguiente:
subscriptions/{subscriptionId}/resourcesGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccount
s/{storageAccountName1}
Obtención de cuentas de almacenamiento vinculadas

Obtención de cuentas de almacenamiento vinculadas para todos los tipos de origen de datos
Solicitud a la API
GET
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micr
osoft.OperationalInsights/workspaces/{workspaceName}/linkedStorageAccounts?api-version=2019-08-01-preview
Response
{
[
{
"properties":
{
"dataSourceType": "CustomLogs",
"storageAccountIds ":
[
"<storage_account_resource_id_1>",
"<storage_account_resource_id_2>"
],
},
"id":"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/microsoft.
operationalinsights/workspaces/{resourceName}/linkedStorageAccounts/CustomLogs",
"name": "CustomLogs",
"type": "Microsoft.OperationalInsights/workspaces/linkedStorageAccounts"
},
{
"properties":
{
"dataSourceType": " AzureWatson "
[
],
},
operationalinsights/workspaces/{resourceName}/linkedStorageAccounts/AzureWatson",
"name": "AzureWatson",
}
]
}
Obtención de cuentas de almacenamiento vinculadas para un tipo de origen de datos específico

Solicitud a la API
GET
osoft.OperationalInsights/workspaces/{workspaceName}/linkedStorageAccounts/{dataSourceType}?api-version=2019-
08-01-preview
Response
{
"properties":
{
"dataSourceType": "CustomLogs",
[
],
},
}
Creación o modificación de un vínculo

Una vez que vincule una cuenta de almacenamiento a un área de trabajo, Log Analytics comenzará a usarla en
lugar de la cuenta de almacenamiento propiedad del servicio. Puede registrar una lista de cuentas de
almacenamiento al mismo tiempo y puede usar la misma cuenta de almacenamiento para varias áreas de trabajo.
Si el área de trabajo controla tanto los recursos de red virtual como los recursos fuera de una red virtual, debe
asegurarse de que no rechaza el tráfico procedente de Internet. El almacenamiento debe tener la misma
configuración que el área de trabajo y estar disponible para los recursos fuera de la red virtual.
Solicitud a la API
PUT
08-01-preview
Carga
{
"properties":
{
"storageAccountIds " :
[
],
}
}
Response
{
"properties":
{
"dataSourceType": "CustomLogs"
[
],
},
}
Desvinculación de una cuenta de almacenamiento

Si decide dejar de usar una cuenta de almacenamiento para la ingesta o reemplazar el área de trabajo que utiliza,
debe desvincular el almacenamiento del área de trabajo.
Al desvincular todas las cuentas de almacenamiento de un área de trabajo, la ingesta intentará basarse en las
cuentas de almacenamiento administradas por el servicio. Si los agentes se ejecutan en una red virtual con acceso
limitado a Internet, se espera que se produzca un error en la ingesta. El área de trabajo debe tener una cuenta de
almacenamiento vinculada que sea accesible desde los recursos supervisados.
Antes de eliminar una cuenta de almacenamiento, debe asegurarse de que todos los datos que contiene se han
ingerido en el área de trabajo. Como medida de precaución, mantenga su cuenta de almacenamiento disponible
después de vincular un almacenamiento alternativo. Elimínela solo una vez que se haya ingerido todo su
contenido y podrá ver que los datos nuevos se escriben en la cuenta de almacenamiento recién conectada.
Solicitud a la API
DELETE
08-01-preview
Reemplazo de una cuenta de almacenamiento

Para reemplazar una cuenta de almacenamiento usada para la ingesta, primero debe crear un vínculo para una
cuenta de almacenamiento nueva. Los agentes de registro obtendrán la configuración actualizada y comenzarán a
enviar datos también al almacenamiento nuevo.
Después, desvincule la cuenta de almacenamiento anterior para que los agentes dejen de escribir en la cuenta
quitada. El proceso de ingesta sigue leyendo los datos de esta cuenta hasta que se realice la ingesta de todos. No
elimine la cuenta de almacenamiento hasta que vea que se ingirieron todos los registros.
La configuración del agente se actualizará después de unos minutos y cambiarán al almacenamiento nuevo.
Administración de una cuenta de almacenamiento

Cargar
Las cuentas de almacenamiento pueden controlar cierta carga de solicitudes de lectura y escritura antes de iniciar
las solicitudes de limitación. La limitación afecta al tiempo que se tarda en ingerir registros y puede dar lugar a la
pérdida de datos. Si el almacenamiento está sobrecargado, registre cuentas de almacenamiento adicionales y
reparta la carga entre ellos.
Cargos relacionados
Las cuentas de almacenamiento se cobran según el volumen de datos almacenados, los tipos de almacenamiento
y el tipo de redundancia. Para detalles, consulte Precios de los blobs en bloques y Precios de Azure Table Storage.
Si la cuenta de almacenamiento registrada del área de trabajo está en otra región, se le cobrará por la salida
según estos Detalles de precios de ancho de banda.
Pasos siguientes
Para más información sobre cómo configurar un vínculo privado, consulte Uso de Azure Private Link para
conectar redes a Azure Monitor de forma segura.
Guía sobre datos personales almacenados en Log
Analytics y Application Insights
Log Analytics es un almacén de datos donde es probable que haya datos personales. Application Insights
almacena sus datos en una partición de Log Analytics. En este artículo se describe en qué parte de Log Analytics y
Application Insights se encuentran estos datos normalmente, así como las funcionalidades disponibles para
administrarlos.
NOTE
Para los fines de este artículo, registrar datos hace referencia a los datos enviados a un área de trabajo de Log Analytics,
mientras que datos de la aplicación hace referencia a los datos recopilados por Application Insights.
NOTE
Para más información sobre cómo ver o eliminar datos personales, consulte Solicitudes de interesados de datos de Azure
para el RGPD. Para más información sobre el Reglamento general de protección de datos, consulte la sección sobre RGPD del
Portal de confianza de servicios.
Estrategia de tratamiento de datos personales

Mientras que usted y su empresa sean los responsables en última instancia de determinar la estrategia de
tratamiento de los datos privados (si los hubiera), pueden adoptarse los siguientes enfoques. Aparecen en orden
de preferencia (de más a menos) desde un punto de vista técnico:
Siempre que sea posible, detener la recopilación de los datos, ofuscarlos o anonimizarlos, o bien ajustar la
recopilación de los datos para excluirlos por ser de carácter "privado". Este método es el preferido con
diferencia, ya que evita la necesidad de crear una estrategia de tratamiento de datos rápida y costosa.
Si no es posible, trate de normalizar los datos para reducir el impacto en el rendimiento y la plataforma de
datos. Por ejemplo, en lugar de registrar un identificador de usuario explícita, cree una búsqueda para los datos
que se correlacionarán el nombre de usuario y sus detalles con un identificador interno que luego puede
registrarse en otra parte. De este modo, si uno de los usuarios le pide eliminar su información personal, se
puede hacer suprimiendo únicamente la fila en la tabla de búsqueda correspondientes al usuario.
Por último, si se deben recopilar datos privados, cree un proceso en la ruta de acceso de la API de depuración y
en la de la API de consulta existente para cumplir con las obligaciones relativas a exportar y eliminar cualquier
dato privado asociado con un usuario.
¿Dónde se pueden buscar datos privados en Log Analytics?

Log Analytics es un almacén completamente flexible que, además de recomendar un esquema a los datos, permite
reemplazar todos los campos con valores predeterminados. Además, se puede ingerir cualquier esquema
personalizado. Por lo tanto, no podemos saber exactamente dónde se encuentran datos privados en su área de
trabajo concreta. Sin embargo, las siguientes ubicaciones son buenos puntos de partida en su inventario:
Datos de registro
Direcciones IP: Log Analytics recopila una gran variedad de información de IP en numerosas tablas diferentes.
Por ejemplo, la siguiente consulta muestra todas las tablas donde se han recopilado direcciones IPv4 en las
últimas 24 horas:
search *
| where * matches regex @'\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}\b' //RegEx originally
provided on https://stackoverflow.com/questions/5284147/validating-ipv4-addresses-with-regexp
| summarize count() by $table
Identificadores de usuario: los identificadores de usuario se encuentran en una gran variedad de soluciones y
tablas. Puede buscar un nombre de usuario determinado en el conjunto de datos completo con el comando de
búsqueda:
search "[username goes here]"
Recuerde que debe buscar no solo los nombres de usuario legible para el usuario, sino también los GUID que
se pueden rastrear directamente hasta un usuario determinado.
Identificadores de dispositivo: al igual que los identificadores de usuario, los identificadores de dispositivo a
veces se consideran "privados". Use el mismo enfoque que se indicó para los identificadores de usuario para
identificar las tablas en las que esto podría suponer un problema.
Datos personalizados: Log Analytics permite recopilar de varias maneras: registros personalizados y campos
personalizados, API de recopilador de datos HTTP y datos personalizados recopilados como parte de los
registros de eventos del sistema. Todos estos son susceptibles de contener datos privados y se deben examinar
para comprobar si es así.
Datos capturados por la solución: como el mecanismo de la solución es de extremo abierto, se recomienda
revisar todas las tablas generadas por las soluciones para garantizar el cumplimiento.
Direcciones IP: aunque Application Insights ofuscará de forma predeterminada todos los campos de
direcciones IP a "0.0.0.0", es un patrón bastante común reemplazar este valor con la dirección IP de usuario real
con el fin de mantener la información de la sesión. La siguiente consulta de Analytics puede utilizarse para
buscar cualquier tabla que contenga valores en la columna de dirección IP que no sea "0.0.0.0" en las últimas
24 horas:
search client_IP != "0.0.0.0"

| where timestamp > ago(1d)
| summarize numNonObfuscatedIPs_24h = count() by $table
Identificadores de usuario: de forma predeterminada, Application Insights usará identificadores generados de

forma aleatoria para el usuario y el seguimiento de sesión. Sin embargo, es habitual ver estos campos
reemplazos para almacenar un identificador más relevante para la aplicación. Por ejemplo: nombres de usuario,
GUID de AAD, etc. Estos identificadores suelen considerarse como datos personales y, por lo tanto, deben
tratarse de la forma adecuada. Siempre recomendamos tratar de ofuscar o anonimizar estos identificadores.
Algunos campos donde suelen encontrarse estos valores son session_Id, user_Id, user_AuthenticatedId,
user_AccountId y customDimensions.
Datos personalizados: Application Insights permite anexar un conjunto de dimensiones personalizadas a
cualquier tipo de datos. Estas dimensiones pueden ser cualquier dato. Utilice la siguiente consulta para
identificar las dimensiones personalizadas recopiladas durante las últimas 24 horas:
search *
| where isnotempty(customDimensions)
| project $table, timestamp, name, customDimensions
Datos en memoria y en tránsito: Application Insights hará un seguimiento de las excepciones, las solicitudes, las
llamadas de dependencia y los seguimientos. A menudo se pueden recopilar los datos privados en el código y
en las llamadas HTTP. Revise las excepciones, las solicitudes, las dependencias y las tablas de seguimiento para
identificar estos datos. Use inicializadores de telemetría siempre que sea posible para ofuscar estos datos.
Capturas de Snapshot Debugger: la característica Snapshot Debugger de Application Insights permite recopilar
las instantáneas de depuración cuando se detecta una excepción en la instancia de producción de la aplicación.
Las instantáneas expondrán el seguimiento de la pila completo que provoca las excepciones, así como los
valores para las variables locales en cada etapa de la pila. Por desgracia, esta característica no permite eliminar
de forma selectiva los puntos de ajuste ni acceder mediante programación a los datos dentro de la instantánea.
Por lo tanto, si la velocidad de retención de instantáneas predeterminada no satisface sus requisitos de
cumplimiento, recomendamos desactivar la característica.
Cómo exportar y eliminar datos privados

Tal y como se mencionó en la sección sobre la estrategia de tratamiento de datos personales, se recomienda
encarecidamente , siempre que sea posible, reestructurar la directiva de recopilación de datos para deshabilitar
la recopilación, ofuscación y anonimización de datos, o bien modificarlos para excluirlos por considerarse de
carácter "privado". Tanto usted como su equipo tendrán que asumir costos relacionados con la definición y
automatización de una estrategia, la creación de una interfaz para que los clientes interactúen con sus datos y el
mantenimiento continuo. Además, esto requiere que Log Analytics y Application Insights funcionen de forma
intensiva, y debido al gran volumen de llamadas simultáneas de API de purga o consulta, es posible el resto de las
interacciones con la funcionalidad de Log Analytics se vean afectadas de forma negativa. Dicho esto, hay
realmente algunos escenarios válidos en los que se deben recopilar datos privados. En estos casos, los datos
deben tratarse como se describe en esta sección.
NOTE
En este artículo se indican los pasos para eliminar los datos personales del dispositivo o del servicio y puede utilizarse para
cumplir con sus obligaciones según el Reglamento general de protección de datos (RGPD). Si quiere obtener información
general sobre este reglamento, vea la sección del RGPD del Portal de confianza de servicios.
Visualización y exportación
Para ver y exportar las solicitudes de datos, debe usarse la API de consulta de Log Analytics o la API de consulta de
Application Insights. Tendrá que decidir qué lógica implementará para convertir la forma de los datos a uno
adecuado para los usuarios. Azure Functions es un buen lugar para hospedar esta lógica.
IMPORTANT
Aunque la mayoría de las operaciones de purga pueden completarse mucho más rápido que lo establecido en el Acuerdo de
Nivel de Servicio (SLA), el SL A formal para la realización de operaciones de purga es de 30 días debido a su gran
impacto en la plataforma de datos utilizada. Se trata de un proceso automatizado; no hay ninguna forma de solicitar que
una operación se controle con mayor rapidez.
Eliminar
WARNING
Las eliminaciones en Log Analytics son destructivas y no reversibles. Por tanto, extreme las precauciones cuando las ejecute.
Como parte de un caso de tratamiento de privacidad, hemos publicado una ruta de acceso a una API de purga.
Esta ruta de acceso debe usarse con moderación debido al riesgo asociado inherente, al posible impacto en el
rendimiento y a la posibilidad de sesgar completamente agregaciones, medidas y otros aspectos de los datos de
Log Analytics. Consulte la sección Estrategia de tratamiento de datos personales para conocer otras maneras de
administrar los datos privados.
La purga es una operación con privilegios elevados que ninguna aplicación ni usuario de Azure (incluido incluso el
propietario del recurso) tiene permisos para ejecutar sin que se le haya concedido expresamente un rol en Azure
Resource Manager. Este rol es Purgador de datos y se debe delegar con cuidado debido a la posibilidad de pérdida
de datos.
IMPORTANT
Con el fin de administrar los recursos del sistema, las solicitudes de purga se limitan a 50 solicitudes por hora. Debe procesar
por lotes la ejecución de las solicitudes de purga mediante el envío de un único comando cuyo predicado incluya todas las
identidades de usuario que requieran purga. Use el operador in para especificar varias identidades. Debe ejecutar la consulta
antes de ejecutar la solicitud de purga para comprobar que se esperan los resultados.
Una vez que se ha asignado el rol de Azure Resource Manager, habrá disponibles dos nuevas rutas de acceso de
API:
Datos de registro
Purga POST: toma un objeto que especifica los parámetros de datos que se van a eliminar y devuelve un
GUID de referencia.
GET purge status: la llamada POST purge devolverá un encabezado "x-ms-status-location" que incluye una
dirección URL a la que se puede llamar para determinar el estado de la API de purga. Por ejemplo:
x-ms-status-location:
https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/provider
s/Microsoft.OperationalInsights/workspaces/[WorkspaceName]/operations/purge-[PurgeOperationId]?api-
version=2015-03-20
IMPORTANT
Aunque se espera que la mayoría de las operaciones de purga se completen mucho más rápido que lo establecido en el
Acuerdo de Nivel de Servicio (SLA), debido a su gran impacto en la plataforma de datos utilizada por Log Analytics, el SL A
formal para la realización de operaciones de purga es de 30 días .
Purga POST: toma un objeto que especifica los parámetros de datos que se van a eliminar y devuelve un
GUID de referencia.
GET purge status: la llamada POST purge devolverá un encabezado "x-ms-status-location" que incluye una
dirección URL a la que se puede llamar para determinar el estado de la API de purga. Por ejemplo:
x-ms-status-location:
https://management.azure.com/subscriptions/[SubscriptionId]/resourceGroups/[ResourceGroupName]/provider
s/microsoft.insights/components/[ComponentName]/operations/purge-[PurgeOperationId]?api-version=2015-
05-01
IMPORTANT
Aunque la mayoría de las operaciones de purga pueden completarse mucho más rápido que lo establecido en el Acuerdo de
Nivel de Servicio (SLA), debido a su gran impacto en la plataforma de datos que utiliza Application Insights, el SL A formal
para la realización de operaciones de purga es de 30 días .
Pasos siguientes
Para obtener más información sobre cómo se recopilan, procesan y protegen los datos de Log Analytics,
consulte Seguridad de datos de Log Analytics.
Para obtener más información sobre cómo se recopilan, procesan y protegen los datos de Application Insights,
vea Seguridad de datos de Application Insights.
Recopilación, retención y almacenamiento de
datos en Application Insights
Al instalar el SDK de Azure Application Insights en su aplicación, se envía telemetría sobre la aplicación a la
nube. Naturalmente, los desarrolladores responsables desean saber exactamente qué datos se envían, qué les
ocurre a los datos y cómo puede mantener el control de los mismos. En concreto, si se puede enviar
información confidencial, dónde se almacena y su nivel de seguridad.
En primer lugar, la respuesta corta:
Es improbable que los módulos de telemetría estándar que se ejecutan "de fábrica" envíen información
confidencial al servicio. La telemetría se ocupa de la carga, las métricas de rendimiento y uso, los informes
de excepciones y otros datos de diagnóstico. Los principales datos del usuario que aparecen los informes
de diagnóstico son direcciones URL; pero, en cualquier caso, la aplicación no debería colocar información
confidencial como texto sin formato en una dirección URL.
Puede escribir código que envíe telemetría personalizada adicional que le ayude con el uso de la
supervisión y el diagnóstico. (Esta extensibilidad es una excelente característica de Application Insights.)
Por error, sería posible escribir este código de modo que incluya datos personales y otra información
confidencial. Si la aplicación trabaja con estos datos, debe aplicar un proceso de revisión exhaustivo a todo
el código que escriba.
Al desarrollar y probar la aplicación, es fácil de inspeccionar lo que envía el SDK. Los datos aparecen en las
ventanas de salida de depuración tanto del IDE como del explorador.
Puede seleccionar la ubicación cuando se crea un nuevo recurso de Application Insights. Aquí encontrará
más información sobre la disponibilidad de Application Insights por región.
Revise los datos recopilados, ya que esto puede incluir datos que se permiten en algunas circunstancias,
pero no en otras. Un buen ejemplo de esto es el nombre de dispositivo. El nombre del dispositivo de un
servidor no tiene ningún impacto en la privacidad y resulta útil, pero el nombre de dispositivo de un
teléfono o portátil puede tener un impacto en la privacidad y resultar menos útil. Un SDK desarrollado
principalmente para los servidores de destino, va a recopilar el nombre del dispositivo de forma
predeterminada, por lo que es posible que deba sobrescribirse en eventos normales y excepciones.
En el resto de este artículo se describen más detalladamente estas respuestas. El artículo está diseñado para
ser independiente, por lo que puede mostrarlo a compañeros que no formen parte de su equipo.
¿Qué es Application Insights?

Azure Application Insights es un servicio que proporciona Microsoft que le ayuda a mejorar el rendimiento y
la facilidad de uso de la aplicación activa. Supervisa la aplicación durante todo el tiempo que se ejecute, tanto
durante las pruebas como después de haberla publicado o implementado. Application Insights crea gráficos y
tablas que muestran, por ejemplo, en qué horas del día se obtiene la mayoría de los usuarios, la capacidad de
respuesta de la aplicación y lo bien que la atienden los servicios externos de los que depende. Si hay
bloqueos, errores o problemas de rendimiento, puede buscar en los datos de la telemetría para diagnosticar
la causa. Y el servicio le enviará mensajes de correo electrónico si se produce cualquier tipo de cambio en la
disponibilidad y rendimiento de la aplicación.
Para obtener esta funcionalidad, instale un SDK de Application Insights en la aplicación, que se convierte en
parte de su código. Cuando se ejecuta la aplicación, el SDK supervisa su funcionamiento y envía la telemetría
al servicio Application Insights. Se trata de un servicio en la nube hospedado por Microsoft Azure. (No
obstante, Application Insights funciona con cualquier aplicación, no solo con las hospedadas en Azure).
El servicio de Application Insights almacena y analiza los datos de telemetría. Para ver el análisis o realizar
búsquedas en la telemetría almacenada, inicie sesión en su cuenta de Azure y abra el recurso Application
Insights de la aplicación. También puede compartir el acceso a los datos con otros miembros del equipo o con
determinados suscriptores de Azure.
Los datos exportados del servicio Application Insights se pueden exportar, por ejemplo a una base de datos o
a herramientas externas. Proporcione a cada herramienta una clave especial, que se obtiene desde el servicio.
Si es necesario, dicha clave se puede revocar.
Los SDK de Application Insights están disponible para varios tipos de aplicaciones: servicios web hospedados
en Azure o en sus propios servidores de Java EE o ASP.NET; clientes web (es decir, el código se ejecuta en una
página web); servicios y aplicaciones de escritorio, y aplicaciones para dispositivos, como Windows Phone,
iOS y Android. Todos ellos envían telemetría al mismo servicio.
¿Qué datos recopila?

Hay tres orígenes de datos:
El SDK, que se integra con la aplicación en la fase de desarrollo o en tiempo de ejecución. Existen
distintos SDK para los diferentes tipos de aplicaciones. También hay un SDK para páginas web, que se
carga en el explorador del usuario final junto con la página.
Cada SDK tiene varios módulos, que emplean diferentes técnicas para recopilar distintos tipos de
datos de telemetría.
Si instala el SDK en la fase de desarrollo, puede usar su API para enviar su propia telemetría,
además de los módulos estándar. Esta telemetría personalizada puede incluir los datos que desee
enviar.
En algunos servidores web, también hay agentes que se ejecutan junto con la aplicación y envían
datos de telemetría de la CPU, memoria y ocupación de la red. Por ejemplo, las máquinas virtuales de
Azure, los hosts de Docker y los servidores de Java EE pueden tener dichos agentes.
pruebas de disponibilidad son procesos que ejecuta Microsoft que envían solicitudes a una aplicación
web a intervalos regulares. Los resultados se envían al servicio Application Insights.
¿Qué tipos de datos se recopilan?
Las principales categorías son:
Telemetría de servidor web : solicitudes HTTP. Identificador URI, tiempo invertido en procesar la solicitud,
código de respuesta y dirección IP del cliente. Session id .
Páginas web : contadores de sesión, página y usuario. Tiempos de carga de las páginas. Excepciones.
Llamadas AJAX.
Contadores de rendimiento: memoria, CPU, E/S, ocupación de la red.
Contexto de cliente y servidor: SO, configuración regional, tipo de dispositivo, explorador y resolución de
pantalla.
Excepciones y bloqueos: volcados de pila , build id y tipo de CPU.
Dependencias : llamadas a servicios externos como REST, SQL y AJAX. Identificador URI o cadena de
conexión, duración, con éxito, comando.
Pruebas de disponibilidad : duración de prueba y pasos, respuestas.
Registros de seguimiento y telemetría personalizada - : todo el código que se escribe en los
registros o telemetría .
Más detalle.
¿Cómo se puede comprobar lo que se recopila?
Si desarrolla la aplicación mediante Visual Studio, ejecútela en modo de depuración (F5). Los datos de
telemetría aparecen en la ventana de salida. Desde ahí, puede copiarlos y darles formato como JSON para
facilitar su inspección.
También existe una vista más legible en la ventana Diagnóstico.

En el caso de las páginas web, abra la ventana de depuración del explorador.
¿Puedo escribir código para filtrar los datos de telemetría antes de enviarlos?
Sí, es posible, solo es preciso escribir un complemento de procesador de telemetría.
¿Cuánto tiempo se conservan los datos?

Los puntos de datos sin procesar (es decir, elementos que puede consultar en Analytics e inspeccionar en la
funcionalidad de búsqueda) se conservan hasta 730 días. Puede seleccionar una duración de retención de 30,
60, 90, 120, 180, 270, 365, 550 o 730 días. Si necesita mantener los datos más tiempo, puede usar la
exportación continua para copiarlos a una cuenta de almacenamiento durante la ingesta de datos.
Los datos que se mantengan más de 90 días generarán cargos adicionales. Más información sobre los
precios de Application Insights en la página de precios de Azure Monitor.
Los datos agregados (es decir, recuentos, promedios y otros datos estadísticos que se ven en el Explorador de
métricas) se retienen con un nivel de detalle de un minuto durante 90 días.
Las instantáneas de depuración se guardan durante 15 días. Esta directiva de retención se establece para cada
aplicación. Si necesita aumentar este valor, puede solicitar un aumento abriendo una incidencia de soporte
técnico en Azure Portal.
¿Quién puede acceder a los datos?

Usted puede ver los datos y, si tiene una cuenta de organización, también pueden los miembros del equipo.
Los puede exportar tanto usted como los miembros del equipo y pueden copiarse a otras ubicaciones y
pasarse a otras personas.
¿ Qué hace Microsoft con la información que la aplicación envía a Application Insights?
Microsoft usa los datos con el fin exclusivo de proporcionarle el servicio.
¿Donde se conservan los datos?

Puede seleccionar la ubicación cuando se crea un nuevo recurso de Application Insights. Aquí encontrará
más información sobre la disponibilidad de Application Insights por región.
¿Están seguros mis datos?

Application Insights es un servicio de Azure. Las directivas de seguridad se describen en las notas del
producto de seguridad, privacidad y cumplimiento de Azure.
Los datos se almacenan en servidores de Microsoft Azure. En el caso de las cuentas de Azure Portal, las
restricciones se describen en el documento Seguridad, privacidad y cumplimiento de Azure.
El acceso a los datos por parte del personal de Microsoft está restringido. El acceso a los datos solo se realiza
con su permiso y si es necesario para prestarle soporte en el uso de Application Insights.
Los datos que se agregan en todas las aplicaciones de nuestros clientes (por ejemplo, la velocidad de datos y
el tamaño medio de los seguimientos) se usan para mejorar Application Insights.
¿ Puede interferir la telemetría de otro usuario con mis datos de Application Insights?
Podría enviarse telemetría adicional a su cuenta mediante el uso de la clave de instrumentación, que se
encuentra en el código de las páginas web. Si tienen demasiados datos adicionales, las métricas no
representan correctamente el rendimiento y el uso de la aplicación.
Si comparte el código con otros proyectos, no olvide quitar la clave de instrumentación.
¿Se cifran los datos?

Todos los datos se cifran en reposo y al moverse entre centros de datos.
¿ Se cifran los datos en tránsito desde mi aplicación a los servidores de Application Insights?
Sí, se usa https para enviar datos al portal desde casi todos los SDK, incluidos servidores web, dispositivos y
páginas web HTTPS.
¿El SDK crea almacenamiento local temporal?

Sí, algunos canales de telemetría conservarán los datos localmente si no se puede alcanzar un punto de
conexión. Revise a continuación para ver los marcos de trabajo y los canales de telemetría afectados.
Los canales de telemetría que utilizan almacenamiento local crean archivos temporales en los directorios
TEMP o APPDATA que están restringidos a la cuenta específica que ejecuta la aplicación. Esto puede ocurrir
cuando un punto de conexión no estaba disponible temporalmente o se alcanza el límite. Una vez que se
resuelva este problema, el canal de telemetría reanudará el envío de todos los datos nuevos y conservados.
Los datos conservados no se cifran localmente. Si esto supone un problema, revise los datos y limite la
recopilación de datos privados. (Para obtener más información, consulte Cómo exportar y eliminar datos
privados).
Si un cliente necesita para configurar este directorio con requisitos de seguridad específicos, se puede
configurar para cada marco de trabajo. Asegúrese de que el proceso que ejecuta la aplicación tiene acceso de
escritura a este directorio, pero asegúrese también de que este directorio está protegido para evitar que
usuarios no deseados puedan leer datos de telemetría.
Java
C:\Users\username\AppData\Local\Temp se utiliza para guardar los datos. Esta ubicación no es configurable
desde el directorio de configuración y los permisos para acceder a esta carpeta están restringidos a un
usuario determinado con las credenciales necesarias. (Para obtener más información, consulte
Implementación).
.Net
De forma predeterminada, ServerTelemetryChannel usa la carpeta de datos de la aplicación local del usuario
actual %localAppData%\Microsoft\ApplicationInsights o la carpeta temporal %TMP% . (Consulte la
implementación aquí).
Mediante el archivo de configuración:
<TelemetryChannel
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
Microsoft.AI.ServerTelemetryChannel">
<StorageFolder>D:\NewTestFolder</StorageFolder>
</TelemetryChannel>
Mediante código:
Eliminación de ServerTelemetryChannel del archivo de configuración
Agregue este fragmento de código a la configuración:
ServerTelemetryChannel channel = new ServerTelemetryChannel();

channel.StorageFolder = @"D:\NewTestFolder";
channel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = channel;
NetCore
De forma predeterminada, ServerTelemetryChannel usa la carpeta de datos de la aplicación local del usuario
actual %localAppData%\Microsoft\ApplicationInsights o la carpeta temporal %TMP% . (Consulte la
implementación aquí). En un entorno Linux, se deshabilitará el almacenamiento local a menos que se
especifique una carpeta de almacenamiento.
El fragmento de código siguiente muestra cómo establecer ServerTelemetryChannel.StorageFolder en el
método ConfigureServices() de la clase Startup.cs :
services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel () {StorageFolder =

"/tmp/myfolder"});
(Para obtener más información, consulte Configuración personalizada de AspNetCore).

Node.js
De forma predeterminada, se utiliza %TEMP%/appInsights-node{INSTRUMENTATION KEY} para guardar los datos.
Los permisos para acceder a esta carpeta están restringidos al usuario actual y los administradores. (Consulte
la implementación aquí).
El prefijo de la carpeta appInsights-node se puede invalidar cambiando el valor en tiempo de ejecución de la
variable estática Sender.TEMPDIR_PREFIX que se encuentra en Sender.ts.
JavaScript (explorador)
Se usa almacenamiento de sesión de HTML5 para conservar los datos. Se usan dos búferes independientes:
AI_buffer y AI_sent_buffer . La telemetría por lotes y en espera de ser enviada se almacena en AI_buffer .
La telemetría que se acaba de enviar se coloca en AI_sent_buffer hasta que el servidor de ingesta responde
que se ha recibido correctamente. Una vez que la telemetría se ha recibido correctamente, se quita de todos
los búferes. En los errores transitorios (por ejemplo, un usuario pierde la conectividad de red), la telemetría
permanece en AI_buffer hasta que se recibe correctamente o el servidor de ingesta responde que no es
válida (esquema incorrecto o demasiado antiguo, por ejemplo).
Los búferes de telemetría se pueden deshabilitar si se establece enableSessionStorageBuffer en false .
Cuando se desactiva el almacenamiento de sesión, en su lugar se usa una matriz local como almacenamiento
persistente. Dado que el SDK de JavaScript se ejecuta en un dispositivo cliente, el usuario tiene acceso a esta
ubicación de almacenamiento mediante las herramientas de desarrollo del explorador.
Python para OpenCensus
De forma predeterminada, el SDK de Python para OpenCensus usa la carpeta del usuario actual
%username%/.opencensus/.azure/ . Los permisos para acceder a esta carpeta están restringidos al usuario
actual y los administradores. (Consulte la implementación aquí). La carpeta con los datos persistentes se
denominará según el archivo de Python que generó la telemetría.
Puede cambiar la ubicación del archivo de almacenamiento si pasa el parámetro storage_path en el
constructor del exportador que usa.
AzureLogHandler(
connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000',
storage_path='<your-path-here>',
)
¿Cómo se envían datos a Application Insights con TLS 1.2?

Para garantizar la seguridad de los datos en tránsito a los puntos de conexión de Application Insights, se
recomienda encarecidamente a los clientes configurar su aplicación para que use al menos Seguridad de la
capa de transporte (TLS) 1.2. Las versiones anteriores de TLS/Capa de sockets seguros (SSL) han demostrado
ser vulnerables y, si bien todavía funcionan para permitir la compatibilidad con versiones anteriores, no se
recomiendan , y el sector está cambiando rápidamente para abandonar la compatibilidad de estos
protocolos más antiguos.
PCI Security Standards Council ha establecido una fecha límite el 30 de junio de 2018 para deshabilitar las
versiones anteriores de TLS/SSL y actualizar a protocolos más seguros. Una vez que Azure quite la
compatibilidad heredada, si la aplicación o los clientes no pueden comunicarse a través de TLS 1.2 como
mínimo, podría no ser capaz de enviar datos a Application Insights. El enfoque que adopte para probar y
validar la compatibilidad con TLS de la aplicación variará según la plataforma y sistema operativo, así como el
lenguaje o marco que use la aplicación.
No se recomienda establecer explícitamente la aplicación para que solo use TLS 1.2, a menos que sea
necesario. Eso se debe a que puede interrumpir las características de seguridad a nivel de la plataforma que
le permiten detectar y aprovechar automáticamente las ventajas de los protocolos más seguros más recientes
a medida que estén disponibles, como TLS 1.3. Se recomienda realizar una auditoría completa del código de
la aplicación para comprobar la codificación rígida de versiones específicas de TLS/SSL.
Instrucciones específicas para la plataforma y el lenguaje
Azure App Services Compatible, puede requerir La compatibilidad se anunció en abril

configuración. de 2018. Lea el anuncio para obtener
los detalles de configuración.
Azure Function Apps Compatible, puede requerir La compatibilidad se anunció en abril

configuración. de 2018. Lea el anuncio para obtener
los detalles de configuración.
.NET Compatible, la configuración varía Para obtener información detallada de

según la versión. la configuración para .NET 4.7 y
versiones anteriores, consulte estas
instrucciones.
Monitor de estado Compatible, se requiere configuración Monitor de estado se basa en la

configuración del sistema operativo +
configuración de .NET para admitir
TLS 1.2.
Node.js Compatible, en v10.5.0, puede Use la documentación oficial de

requerir configuración. Node.js TLS/SSL para cualquier
configuración específica de la
aplicación.
Java Compatible, se agregó compatibilidad JDK 8 usa TLS 1.2 de forma

de JDK para TLS 1.2 en la predeterminada.
actualización 121 de JDK 6 y JDK 7.
Linux Las distribuciones de Linux tienden a Compruebe el registro de cambios de

basarse en OpenSSL para la OpenSSL para confirmar si su versión
compatibilidad con TLS 1.2. de OpenSSL es compatible.
Windows 8.0 a 10 Compatible y habilitado de manera Para confirmar que aún usa la
predeterminada. configuración predeterminada.
Windows Server 2012 a 2016 Compatible y habilitado de manera Para confirmar que aún usa la
predeterminada. configuración predeterminada
Windows 7 SP1 y Windows Server Compatible, pero no habilitado de Consulte la página Configuración del
2008 R2 SP1 manera predeterminada. registro de TLS para obtener más
información sobre cómo se habilita.
Windows Server 2008 SP2 La compatibilidad con TLS 1.2 Consulte Actualización para agregar
requiere una actualización. compatibilidad con TLS 1.2 en
Windows Server 2008 SP2.
Windows Vista No compatible. N/D
Comprobación de qué versión de OpenSSL se ejecuta para su distribución de Linux

Para comprobar qué versión de OpenSSL tiene instalada, abra el terminal y ejecute:
openssl version -a
Ejecución de una transacción de TLS 1.2 de prueba en Linux

Para ejecutar una prueba preliminar a fin de comprobar si el sistema de Linux puede comunicarse a través de
TLS 1.2, abra el terminal y ejecute lo siguiente:
openssl s_client -connect bing.com:443 -tls1_2
Datos personales almacenados en Application Insights

Nuestra Guía sobre datos personales almacenados en Application Insights trata este problema en detalle.
¿ Pueden los usuarios desactivar Application Insights?
No directamente. No se proporciona un conmutador que los usuarios puedan operar para desactivar
Sin embargo, puede implementar esta característica en la aplicación. Todos los SDK incluyen un valor de
configuración de la API que desactiva la recopilación de telemetría.
Datos enviados por Application Insights

Los SDK varían entre las distintas plataformas, y hay varios componentes que se pueden instalar. (Consulte
Introducción a Application Insights). Cada componente envía datos diferentes.
Clases de datos que se envían en distintos escenarios
A C C IÓ N DEL USUA RIO C L A SES DE DATO S REC O P IL A DO S ( VER TA B L A SIGUIEN T E)
Adición del SDK de Application Insights a un proyecto web ServerContext

de .NET Inferidos
Requests
Excepciones
Sesión
users
Instalación del Monitor de estado en IIS Dependencias

ServerContext
Inferidos
Adición del SDK de Application Insights a una aplicación ServerContext

web de Java Inferidos
Solicitud
Sesión
users
Incorporación del SDK de JavaScript a una página web ClientContext

Inferidos
Página
ClientPerf
Ajax
Definición de propiedades predeterminadas Propiedades en todos los eventos estándar y

personalizados
Llamar a TrackMetric Valores numéricos

Propiedades
Llamar a Track* Nombre del evento

Propiedades
A C C IÓ N DEL USUA RIO C L A SES DE DATO S REC O P IL A DO S ( VER TA B L A SIGUIEN T E)
Llamar a TrackException Excepciones

Volcado de la pila
Propiedades
El SDK no puede recopilar datos. Por ejemplo: Diagnóstico de SDK

- no se puede acceder a los contadores de rendimiento
- excepción en el inicializador de telemetría
En el caso de los SDK de otras plataformas, consulte los documentos correspondientes.

Clases de los datos recopilados
C L A SE DE DATO S REC O P IL A DO S SE IN C L UY EN ( N O ES UN A L ISTA EXH A UST IVA )
Propiedades Cualquier dato - determinado por el código
DeviceContext Id , IP, configuración regional, modelo de dispositivo, red,

tipo de red, nombre de OEM, resolución de pantalla,
instancia de rol, nombre de rol, tipo de dispositivo
ClientContext Sistema operativo, configuración regional, idioma, red,

resolución de ventana
Sesión session id
ServerContext Nombre del equipo, configuración regional, sistema

operativo, dispositivo, sesión de usuario, contexto de
usuario, operación
Inferidos ubicación geográfica de dirección IP, marca de tiempo,

sistema operativo, explorador
Métricas Nombre y valor de la métrica
Eventos Nombre y valor del evento
PageViews URL y nombre de página o nombre de pantalla
Rendimiento del cliente URL o nombre de página, tiempo de carga del explorador
Ajax Llamadas HTTP de la página web al servidor
Requests URL, duración, código de respuesta
Dependencias Tipo (SQL, HTTP,...), cadena de conexión o URI,

sincrónico/asincrónico, duración, éxito, instrucción SQL (con
monitor de estado)
Excepciones Tipo, mensaje , pilas de llamadas, archivo de origen,

número de línea, thread id
C L A SE DE DATO S REC O P IL A DO S SE IN C L UY EN ( N O ES UN A L ISTA EXH A UST IVA )
Bloqueos Process id , parent process id , crash thread id ;

revisión de aplicación, id , compilación; tipo de excepción,
dirección, razón; símbolos y registros confusos, direcciones
binarias inicial y final, nombre binario y ruta de acceso, tipo
de CPU
Seguimiento Mensaje y nivel de gravedad
Contadores de rendimiento Tiempo de procesador, memoria disponible, velocidad de

solicitudes, tasa de excepciones, bytes privados del proceso,
velocidad de E/S, duración de la solicitud, longitud de la
cola de solicitudes
Disponibilidad Código de respuesta de prueba web, duración de cada

paso de la prueba, nombre de la prueba, marca de tiempo,
éxito, tiempo de respuesta, ubicación de la prueba
Diagnóstico de SDK Mensaje de seguimiento o de excepción
También puede desactivar algunos de los datos mediante la edición de ApplicationInsights.config.
NOTE
La IP del cliente se usa para deducir la ubicación geográfica, pero de forma predeterminada ya no se almacenan datos
de IP y todos los ceros se escriben en el campo asociado. Para más información sobre el control de los datos
personales, se recomienda leer este artículo. Si necesita almacenar datos de direcciones IP, nuestro artículo sobre la
colección de direcciones IP le guiará por las opciones.
Créditos
Este producto incluye datos GeoLite2 creados por MaxMind, disponible en https://www.maxmind.com.
Información general sobre las alertas en
Microsoft Azure
En este artículo se explica qué son las alertas, sus beneficios y cómo empezar a utilizarlas.
¿Qué son las alertas en Microsoft Azure?

Las alertas le informan de forma proactiva cuando se detectan condiciones importantes en
los datos que supervisa. Le permiten identificar y solucionar los problemas antes de que los
usuarios del sistema puedan verlos.
En este artículo se describe la experiencia unificada de alertas en Azure Monitor, que ahora
incluye las alertas que antes administraban Log Analytics y Application Insights. La
experiencia de alerta anterior y los tipos de alertas se denominan alertas clásicas. Para ver
esta experiencia anterior y el tipo de alerta anterior, haga clic en Ver aler tas clásicas en la
parte superior de la página de alertas.
En el siguiente diagrama se representa el flujo de alertas.
Alert Rule
Target Resource
Signal
Criteria /
Logic Test
Action Group Monitor

condition
Actions to do Alert State
Las reglas de alertas están separadas de las alertas y las acciones que se realizan cuando se
activa una alerta. La regla de alertas captura el destino y los criterios para las alertas. La regla
de alertas puede tener el estado deshabilitado o habilitado. Las alertas solo se activan
cuando están habilitadas.
Los atributos clave de las reglas de alertas son:
Recurso de destino : define el ámbito y las señales disponibles para las alertas. Un destino
puede ser cualquier recurso de Azure. Destinos de ejemplo: una máquina virtual, una cuenta
de almacenamiento, un conjunto de escalado de máquinas virtuales, un área de trabajo de
Log Analytics o un recurso de Application Insights. Para determinados recursos (por ejemplo,
Virtual Machines), puede especificar varios recursos como destino de la regla de alertas.
Señal : la emite el recurso de destino. Las señales pueden ser de los siguientes tipos: métrica,
registro de actividad, Application Insights y registro.
Criterios : Combinación de señales y lógica aplicadas en un recurso de destino. Ejemplos:
Porcentaje de la CPU superior al 70 %
Tiempo de respuesta del servidor superior a 4 ms
Recuento de resultados de una consulta de registro superior a 100
Nombre de la aler ta : nombre específico para la regla de alertas que haya configurado el
usuario.
Descripción de la aler ta : descripción de la regla de alertas que haya configurado el
usuario.
Gravedad : gravedad de la alerta, una vez que se cumplen los criterios especificados en la
regla de alertas. La gravedad puede tener un valor entre 0 y 4.
Sev 0 = Crítica
Sev 1 = Error
Sev 2 - Advertencia
Sev 3 = Informativa
Sev 4 = Detallada
Acción : una acción específica llevada a cabo al desencadenarse la alerta. Para más
información, vea Grupos de acciones.
Tipo de alertas que se pueden realizar

Puede enviar alertas sobre métricas y registros tal y como se describe en el artículo sobre los
orígenes de datos de supervisión. Estas incluyen, pero no se limitan a:
Valores de métrica
Consultas de búsqueda de registros
Eventos del registro de actividad
Estado de la plataforma Azure subyacente
Pruebas de disponibilidad del sitio web
Anteriormente, las métricas de Azure Monitor, Application Insights, Log Analytics y Service
Health tenían funcionalidades independientes de generación de alertas. Con el tiempo, Azure
ha mejorado y combinado la interfaz de usuario y los distintos métodos de generación de
alertas. Esta consolidación aún está en proceso. Como resultado, algunas funcionalidades de
alertas aún no se encuentran en el nuevo sistema de alertas.
O RIGEN DE SUP ERVISIÓ N T IP O DE SEÑ A L DESC RIP C IÓ N
Estado del servicio Registro de actividades No compatible. Consulte

Creación de alertas del registro
de actividad en notificaciones
del servicio.
O RIGEN DE SUP ERVISIÓ N T IP O DE SEÑ A L DESC RIP C IÓ N
Application Insights Pruebas de disponibilidad web No compatible. Consulte

Alertas de pruebas web.
Disponible para cualquier sitio
web instrumentado para enviar
datos a Application Insights.
Reciba una notificación cuando
la disponibilidad o la capacidad
de respuesta de un sitio web
está por debajo de las
expectativas.
Administrar alertas
Puede establecer el estado de una alerta para especificar dónde se encuentra en el proceso
de resolución. Cuando se cumplen los criterios especificados en la regla de alertas, se crea o
se desencadena una alerta que tiene el estado Nueva. Puede cambiar el estado cuando se
confirma una alerta y cuando se cierra. Todos los cambios de estado se almacenan en el
historial de la alerta.
Se admiten los siguientes estados de alerta.
STAT E DESC RIP C IÓ N
Nuevo Se acaba de detectar el problema y todavía no se

ha revisado.
Confirmado Un administrador revisó la alerta y empezó a

trabajar en ella.
Closed Se resolvió el problema. Después de cerrar una

alerta, puede volver a abrirla mediante el cambio
a otro estado.
El estado de alerta es diferente e independiente de la condición de supervisión. El estado de

alerta lo establece el usuario. La condición de supervisión la establece el sistema. Cuando se
desencadena una alerta, la condición de supervisión de la alerta se establece en
desencadenada. Cuando desaparece la condición subyacente que provocó que se
desencadenara la alerta, la condición de supervisión se establece en resuelta. El estado de
alerta no cambia hasta que el usuario lo cambia. Obtenga información sobre cómo cambiar
el estado de las alertas y de los grupos inteligentes.
Grupos inteligentes
Los grupos inteligentes son agregaciones de alertas basadas en algoritmos de aprendizaje
automático que pueden ayudar a reducir el ruido de las alertas y contribuyen a la solución
de problemas. Más información acerca de los grupos inteligentes y cómo administrar los
grupos inteligentes.
Experiencia de alertas
La página de alertas predeterminada proporciona un resumen de las alertas que se crean
dentro un intervalo de tiempo determinado. Muestra el total de alertas de cada gravedad,
con columnas que identifican el número total de alertas en cada estado para cada gravedad.
Seleccione cualquiera de las gravedades para abrir la página Todas las alertas filtrada según
esa gravedad.
Como alternativa, puede enumerar mediante programación las instancias de alertas
generadas en las suscripciones mediante las API de REST.
NOTE
Solo puede acceder a las alertas generadas en los últimos 30 días.
No muestra ni realiza un seguimiento de las alertas clásicas. Puede cambiar las suscripciones
o los parámetros de filtro para actualizar la página.
Para filtrar esta vista, seleccione los valores en los menús desplegables que aparecen en la
parte superior de la página.
C O L UM N A DESC RIP C IÓ N
Subscription Seleccione las suscripciones a Azure de las que

quiere ver las alertas. Si lo desea, puede
seleccionar todas las suscripciones. Solo las alertas
a las que tiene acceso de las suscripciones
seleccionadas se incluyen en la vista.
Resource group Seleccione un solo grupo de recursos. Solo las

alertas con destinos en el grupo de recursos
seleccionado se incluyen en la vista.
Intervalo de horas Solo las alertas activadas dentro del intervalo de

tiempo seleccionado se incluyen en la vista. Los
valores compatibles son Última hora, Últimas 24
horas, Últimos 7 días y Últimos 30 días.
Seleccione los valores siguientes en la parte superior de la página de alertas para abrir otra
página:
VA L UE DESC RIP C IÓ N
Total de alertas Número total de las alertas que coinciden con los
criterios seleccionados. Seleccione este valor para
abrir sin ningún filtro la vista Todas las alertas.
VA L UE DESC RIP C IÓ N
Grupos inteligentes Número total de grupos inteligentes creados a

partir de las alertas que coinciden con los criterios
seleccionados. Seleccione este valor para abrir la
lista de grupos inteligentes en la vista Todas las
alertas.
Total de reglas de alertas Número total de reglas de alertas en la

suscripción y el grupo de recursos que seleccionó.
Seleccione este valor para abrir la vista Reglas
filtrada en la suscripción y el grupo de recursos
que seleccionó.
Administración de reglas de alerta

Haga clic en Administrar reglas de aler tas para mostrar la página Reglas . La página de
reglas es una sola página que permite administrar todas las reglas de alertas de las
suscripciones a Azure. Se enumeran todas las reglas de alertas que se pueden ordenar según
los recursos de destino, los grupos de recursos, el nombre de regla o el estado. También
puede editar, habilitar o deshabilitar las reglas de alertas desde esta página.
Crear una regla de alerta

Puede crear alertas uniformes independientemente del tipo de señal o del servicio de
supervisión.
Aquí se explica cómo crear una nueva regla de alerta:

1. Elija el destino de la alerta.
2. Seleccione la señal de las señales disponibles para el destino.
3. Especifique la lógica que se aplicará a los datos desde la señal.
Este proceso simplificado de creación ya no requiere que el usuario sepa las señales o el
origen de supervisión admitidos antes de seleccionar un recurso de Azure. La lista de señales
disponibles se filtra automáticamente según el recurso de destino que seleccione. También
en función de ese destino, se le guía por la definición de la lógica de la regla de alerta
automáticamente.
Puede obtener más información sobre cómo crear reglas de alertas en Creación,
visualización y administración de alertas mediante Azure Monitor.
Las alertas están disponibles a través de varios servicios de supervisión de Azure. Para
obtener más información sobre cómo y cuándo usar cada uno de estos servicios, consulte
Supervisión de aplicaciones y recursos de Azure.
Página Todas las alertas

Haga clic en Total de aler tas para ver la página de todas las aler tas . Aquí puede ver una
lista de las alertas que se crearon en el intervalo de tiempo seleccionado. Puede ver una lista
de las alertas individuales o una lista de los grupos inteligentes que contienen las alertas.
Seleccione el banner en la parte superior de la página para alternar entre las vistas.
Para filtrar la vista, seleccione los valores siguientes en los menús desplegables que aparecen
en la parte superior de la página:
Subscription Seleccione las suscripciones a Azure de las que

quiere ver las alertas. Si lo desea, puede
seleccionar todas las suscripciones. Solo las alertas
a las que tiene acceso de las suscripciones
seleccionadas se incluyen en la vista.
Resource group Seleccione un solo grupo de recursos. Solo las

alertas con destinos en el grupo de recursos
seleccionado se incluyen en la vista.
Tipo de recurso Seleccione uno o varios tipos de recurso. Solo las

alertas con destinos del tipo seleccionado se
incluyen en la vista. Esta columna solo está
disponible tras especificar un grupo de recursos.
Resource Seleccione un recurso. Solo las alertas con ese

recurso como destino se incluyen en la vista. Esta
columna solo está disponible tras especificar un
tipo de recurso.
severity Seleccione un nivel de gravedad de alerta o

seleccione Todo para incluir alertas de todos los
niveles de gravedad.
Condición de supervisión Seleccione una condición de supervisión o

seleccione Todo para incluir alertas de todas las
condiciones.
Estado de alerta Seleccione un estado de alerta o seleccione Todo

para incluir alertas de todos los estados.
Servicio de supervisión Seleccione un servicio o seleccione Todo para

incluir todos los servicios. Solo se incluyen las
alertas que se crean mediante las reglas que usan
ese servicio como destino.
Intervalo de horas Solo las alertas activadas dentro del intervalo de

tiempo seleccionado se incluyen en la vista. Los
valores compatibles son Última hora, Últimas 24
horas, Últimos 7 días y Últimos 30 días.
Seleccione Columnas en la parte superior de la página para seleccionar las columnas que
quiere mostrar.
Página Detalles de la alerta

Cuando seleccione una alerta, esta página le proporcionará detalles de la alerta y le permitirá
cambiar su estado.
La página de detalles de alertas incluye las secciones siguientes:
SEC C IÓ N DESC RIP C IÓ N
Resumen Muestra las propiedades y otra información

importante sobre la alerta.
Historial Muestra cada acción que realiza la alerta y los

cambios hechos en la alerta. Actualmente se
limita a cambios de estado.
Diagnóstico Información sobre el grupo inteligente en el que

se incluye la alerta. El recuento de alertas se
refiere al número de alertas incluidas en el grupo
inteligente. Incluye en el mismo grupo inteligente
otras alertas que se crearon en los últimos 30
días, con independencia del filtro de tiempo de la
página de lista de alertas. Seleccione una alerta
para ver sus detalles.
Control de acceso basado en rol (RBAC) para las instancias

de alertas
El consumo y la administración de instancias de alertas requiere que el usuario tenga los
roles integrados de Azure de colaborador de supervisión o lector de supervisión. Estos roles
se admiten en cualquier ámbito de Azure Resource Manager, desde el nivel de la suscripción
hasta las asignaciones pormenorizadas en el nivel de un recurso. Por ejemplo, si un usuario
solo tiene acceso de "colaborador de supervisión" para la máquina virtual ContosoVM1 ,
puede consumir y administrar solo las alertas generadas en ContosoVM1 .
Administrar las instancias de alertas mediante

programación
Es posible que quiera consultar mediante programación las alertas generadas en la
suscripción. Esto podría llevarse a cabo para crear vistas personalizadas fuera de
Azure Portal, o bien para analizar las alertas a fin de identificar patrones y tendencias.
Puede consultar las alertas generadas en sus suscripciones, ya sea mediante la API de REST
de Alert Management, Azure Resource Graph o la API de REST de Recursos.
La API de REST de Resource Graph para Recursos permite consultar instancias de alertas a
escala. Esto se recomienda cuando tiene que administrar las alertas generadas en muchas
suscripciones.
La siguiente solicitud de ejemplo a la API de REST de Resource Graph devuelve el recuento
de alertas de una suscripción:
{
"subscriptions": [
<subscriptionId>
],
"query": "AlertsManagementResources | where type =~ 'Microsoft.AlertsManagement/alerts'
| summarize count()"
}
También puede ver el resultado de esta consulta de Resource Graph en el portal con el
explorador de Azure Resource Graph: portal.azure.com.
Las alertas se pueden consultar para sus campos básicos.
Puede usar la API de REST de Alert Management para obtener más información sobre
alertas específicas, incluidos los campos contexto de alerta correspondientes.
Pasos siguientes
Más información sobre los grupos inteligentes
Información sobre los grupos de acciones
Administración de instancias de alertas en Azure
Más información acerca de los precios de alertas de Azure
Comprender cómo funcionan las alertas de
métricas en Azure Monitor
Las alertas de métricas en Azure Monitor funcionan en la parte superior de las métricas multidimensionales.
Estas métricas pueden ser métricas de plataforma, métricas personalizadas, registros populares de Azure
Monitor convertidos en métricas y métricas de Application Insights. Las alertas de métricas se evalúan a
intervalos regulares para comprobar si las condiciones de una o varias series temporales para las métricas son
verdaderas y recibirá una notificación cuando se cumplan las evaluaciones. Como las alertas de métricas tienen
un estado, solo envían notificaciones cuando cambia ese estado.
Cómo funcionan las alertas de métricas

Para definir una regla de alerta de métrica, especifique el recurso de destino que se supervisará, el nombre, la
condición de la métrica, el tipo de condición (estático o dinámico) y la condición (un operador y un umbral o
sensibilidad) y un grupo de acción que se activará cuando a su vez se active la regla de alerta. Los tipos de
condición afectan a la manera en que se determinan los umbrales. Más información sobre las opciones de tipo
y sensibilidad de la condición de umbrales dinámicos.
Regla de alerta con el tipo de condición estática
Supongamos que ha creado una regla de alerta de métrica de umbral estático simple de la siguiente manera:
Recurso de objetivo (el recurso de Azure que quiere supervisar): myVM
Métrica: Porcentaje de CPU
Tipo de condición: estática
Agregación de tiempo (estadística que se ejecuta sobre valores de métrica sin procesar. Las agregaciones de
tiempo compatibles son Min, Max, Avg, Total y Count): Average
Período (la ventana temporal según la cual se comprueban los valores de la métrica): En los últimos 5
minutos
Frecuencia (es decir, la frecuencia con la que la alerta de métricas comprueba si se cumplen las condiciones):
1 min
Operador: Mayor que
Umbral: 70
Desde el momento en que se crea la regla de alerta, el proceso de supervisión se ejecuta cada minuto y
examina los valores métricos de los últimos 5 minutos; además, comprueba si el promedio de esos valores es
superior a 70. Si se cumple la condición, es decir, si el porcentaje medio de la CPU supera el valor de 70 durante
los últimos 5 minutos, la regla de alerta desencadena una notificación activada. Si configuró un correo
electrónico o una acción de webhook en el grupo de acciones asociado a la regla de alerta, recibirá una
notificación activada en ambos recursos.
Si utiliza varias condiciones en una regla, la regla une las condiciones. Es decir, una alerta se desencadena
cuando todas las condiciones de regla la alerta se evalúan como true y se resuelve cuando una de las
condiciones deja de ser true. Un ejemplo de este tipo de regla de alerta sería supervisar una máquina virtual de
Azure y generar una alerta si el porcentaje de CPU supera el 90 % y la longitud de la cola es de más de 300
elementos.
Regla de alerta con el tipo de condición dinámica
Supongamos que ha creado una regla de alerta de métrica simple de umbrales dinámicos de la siguiente
manera:
Recurso de objetivo (el recurso de Azure que quiere supervisar): myVM
Tipo de condición: Dinámica
Agregación de tiempo (estadística que se ejecuta sobre valores de métrica sin procesar. Las agregaciones de
tiempo compatibles son Min, Max, Avg, Total y Count): Average
Período (la ventana temporal según la cual se comprueban los valores de la métrica): En los últimos 5
minutos
Frecuencia (es decir, la frecuencia con la que la alerta de métricas comprueba si se cumplen las condiciones):
1 min
Operador: Mayor que
Sensibilidad: Media
Períodos de retroceso: 4
Número de infracciones: 4
Una vez creada la regla de alerta, el algoritmo de aprendizaje automático de los umbrales dinámicos adquirirá
los datos históricos disponibles, calculará el umbral que mejor se adapte al patrón de comportamiento de las
series de métricas y aprenderá continuamente en función de los nuevos datos para que el umbral sea más
preciso.
Desde el momento en que se crea la regla de alerta, el monitor se ejecuta cada minuto y examina los valores de
métrica de los últimos 20 minutos agrupados en períodos de cinco minutos y comprueba si el promedio de los
valores del período en cada uno de los cuatro períodos supera el umbral esperado. Si se cumple la condición,
es decir, el porcentaje promedio de CPU en los últimos 20 minutos (cuatro períodos de cinco minutos)
desviado cuatro veces del comportamiento esperado, la regla de alerta desencadena una notificación activada.
Si configuró un correo electrónico o una acción de webhook en el grupo de acciones asociado a la regla de
alerta, recibirá una notificación activada en ambos recursos.
Visualización y resolución de alertas desencadenadas
Los ejemplos anteriores de activación de regla de alerta también se pueden ver en Azure Portal, en la hoja
Todas las aler tas .
Digamos que el uso en "myVM" continúa estando por encima del umbral en las comprobaciones posteriores;
por lo tanto, la regla de alerta no volverá a activarse hasta que se resuelvan las condiciones.
Después de algún tiempo, si el uso en "myVM" vuelve a ser normal y a estar por debajo del umbral. Debido a
ello, la regla de alerta supervisa la condición dos veces más para enviar una notificación resuelta. La regla de
alerta envía un mensaje resuelto o desactivado cuando la condición de alerta no se cumple durante tres
períodos consecutivos, para así reducir el ruido en caso de que haya una oscilación en las condiciones.
Cuando la notificación resuelta se envíe a través del webhook o del correo electrónico, el estado de la instancia
de alerta (llamada estado de supervisión) de Azure Portal también se establecerá como Resuelta.
Usar las dimensiones
Las alertas de métricas en Azure Monitor también admiten la supervisión de las combinaciones de valores de
varias dimensiones con una regla. Aquí le explicaremos por qué debería usar combinaciones de varias
dimensiones con la ayuda de un ejemplo.
Supongamos que tiene un plan de App Service para su sitio web. Quiere supervisar el uso de la CPU en varias
instancias de la aplicación o el sitio web. Puede hacerlo mediante una regla de alerta de métrica, tal como se
indica a continuación:
Recurso de destino: myAppServicePlan
Dimensions
Instance = InstanceName1, InstanceName2
Agregación de tiempo: Average
Período: En los últimos 5 minutos
Frecuencia: 1 min
Operador: GreaterThan
Umbral: 70
Igual que antes, esta regla supervisa si el uso medio de la CPU durante los últimos 5 minutos supera el 70 %.
Sin embargo, con la misma regla puede supervisar dos instancias de su sitio web. Cada instancia será
supervisada individualmente y, por consiguiente, recibirá notificaciones de forma individual.
Supongamos que tiene una aplicación web con una demanda masiva y es necesario agregar más instancias. La
regla anterior únicamente supervisa dos instancias. Sin embargo, puede crear una regla de la siguiente
manera:
Dimensions
Instancia: *
Frecuencia: 1 min
Umbral: 70
Esta regla supervisará automáticamente todos los valores de la instancia, es decir, puede supervisar sus
instancias a medida que aparecen sin necesidad de modificar su regla de alerta de métrica nuevamente.
Al supervisar varias dimensiones, las reglas de alertas de umbrales dinámicos pueden crear umbrales
personalizados para cientos de series de métricas a la vez. Los umbrales dinámicos dan como resultado menos
reglas de alertas que administrar y un ahorro de tiempo significativo en la administración y creación de reglas
de alertas.
Supongamos que tiene una aplicación web con muchas instancias y no sabe cuál es el umbral más adecuado.
Las reglas anteriores siempre utilizarán el umbral del 70 %. Sin embargo, puede crear una regla de la siguiente
manera:
Tipo de condición: Dinámica
Dimensions
Instancia: *
Frecuencia: 1 min
Sensibilidad: Media
Períodos de retroceso: 1
Número de infracciones: 1
Esta regla supervisa si el uso medio de la CPU durante los últimos cinco minutos supera el comportamiento
esperado para cada instancia. La misma regla que puede supervisar las instancias a medida que aparecen sin
necesidad de volver a modificar la regla de alerta de métrica. Cada instancia obtendrá un umbral que se ajuste
al patrón de comportamiento de las series de métricas y cambiará continuamente en función de los nuevos
datos para hacer que el umbral sea más preciso. Igual que antes, cada instancia se supervisará individualmente
y, por consiguiente, recibirá notificaciones de forma individual.
El aumento de los períodos de retroceso y del número de infracciones también puede permitir que las alertas
de filtrado solo alerten sobre la definición de una desviación significativa. Más información sobre las opciones
avanzadas de umbrales dinámicos.
NOTE
Se recomienda elegir una Granularidad de agregación (período) mayor que la Frecuencia de evaluación, con el fin de
reducir la probabilidad de que falte la primera evaluación de las series temporales agregadas en los casos siguientes:
Regla de alertas de métricas que supervisa varias dimensiones: Cuando se agrega una nueva combinación de valores
de dimensión.
Regla de alertas de métricas que supervisa varios recursos: Cuando se agrega un nuevo recurso al ámbito.
Regla de alertas de métricas que supervisa una métrica que no se emite de manera continua (métrica dispersa):
Cuando la métrica se emite después de un período de más de 24 horas en el que no se emitió.
Supervisión a escala mediante alertas de métricas en Azure Monitor

Hasta ahora, ha visto cómo se puede usar una única alerta de métrica para supervisar una o varias series
temporales de métricas relacionadas con un único recurso de Azure. Con frecuencia, es posible que desee
aplicar la misma regla de alertas a muchos recursos. Azure Monitor también permite supervisar varios
recursos (del mismo tipo) utilizando una sola regla de alertas de métricas con los recursos que se encuentran
en la misma región de Azure.
Esta característica se admite actualmente en las métricas de plataforma (no métricas personalizadas) de los
siguientes servicios en las siguientes nubes de Azure:
P UB L IC A Z URE ( A Z URE
SERVIC IO P ÚB L IC O ) GO VERN M EN T C H IN A
Máquinas virtuales Sí No No
Bases de datos de SQL Sí Sí Sí

Server
Grupos elásticos de Sí Sí Sí
SQL Server
Grupos de capacidad de Sí Sí Sí
NetApp Files
Volúmenes de NetApp Files Sí Sí Sí
Almacenes de claves Sí Sí Sí
Dispositivos Data Box Edge Sí Sí Sí
El ámbito de supervisión se puede especificar con una sola alerta de métrica de tres formas distintas. Por
ejemplo, respecto a las máquinas virtuales, el ámbito se puede especificar como:
una lista de máquinas virtuales (de una región de Azure) en una suscripción
todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de recursos de una
suscripción
todas las máquinas virtuales (de una región de Azure) en una suscripción
NOTE
El ámbito de una regla de alerta de métrica de varios recursos debe contener al menos un recurso del tipo de recurso
seleccionado.
La creación de reglas de alertas de métrica que supervisen varios recursos es similar a crear cualquier otra
alerta de métrica que supervise un único recurso. La única diferencia es que debe seleccionar todos los
recursos que desea supervisar. Estas reglas también se pueden crear mediante las plantillas de Azure Resource
Manager. Recibirá notificaciones diferentes de cada máquina virtual.
NOTE
Latencia típica
En cuanto a las alertas de métricas, normalmente recibirá una notificación en menos de 5 minutos si configura
la frecuencia de la regla de alerta en "1 min". En caso de que haya cargas pesadas en los sistemas de
notificaciones, es posible que vea una latencia más larga.
Tipos de recursos admitidos en las alertas métricas

En este artículo puede encontrar la lista completa de tipos de recursos admitidos.
Pasos siguientes
Aprenda a crear, ver y administrar las alertas de métricas en Azure
Aprenda a implementar alertas de métricas con plantillas de Azure Resource Manager
Obtenga más información sobre los grupos de acciones
Más información sobre el tipo de condición de umbrales dinámicos
Alertas de registro en Azure Monitor
Las alertas de registro son uno de los tipos de alerta que se admiten en Alertas de Azure. Las alertas de
registro permiten a los usuarios usar la plataforma de Azure Analytics como base para las alertas.
Alertas de registro consiste en reglas de búsqueda de registros creadas para los registros de Azure Monitor o
Application Insights. Para obtener más información sobre su uso, consulte creación de alertas de registro en
Azure.
NOTE
Ahora los datos de registro populares de los registros de Azure Monitor también están disponibles en la plataforma de
métricas de Azure Monitor. Para obtener más detalles, consulte Alerta de métricas de los registros.
Regla de alertas de búsqueda de registros: definición y tipos

Alertas de Azure crea las reglas de búsqueda de registros para ejecutar automáticamente consultas de
registros especificadas a intervalos regulares. Si los resultados de la consulta de registros coinciden con
determinados criterios, se crea un registro de alertas. La regla, luego, puede ejecutar de forma automática una
o varias acciones con grupos de acciones. Puede que se necesite el rol de Colaborador de supervisión de
Azure para crear, modificar y actualizar las alertas de registro. Además, debe tener los permisos de acceso y
ejecución de consultas para los destinos de análisis en la consulta o regla de alertas. Si el usuario que realice
el proceso no tiene acceso a todos los destinos de análisis en la consulta o regla de alertas, puede que la
creación de la regla devuelva un error o que la regla de alertas de registro se ejecute con resultados parciales.
Las reglas de búsqueda de registros se definen mediante los siguientes detalles:
Consulta de registro . La consulta que se ejecuta cada vez que se activa la regla de alertas. Los
registros devueltos por esta consulta se usan para determinar si se desencadena una alerta. La consulta
de Analytics puede ser para un área de trabajo específica de Log Analytics o una aplicación de
Application Insights, e incluso puede abarcar varios recursos de Log Analytics y de Application Insights
siempre que el usuario tenga derechos de acceso y de consulta a todos los recursos.
IMPORTANT
Se admiten consultas entre recursos para alertas de registro de Application Insights y para alertas de registro
de Log Analytics que se configuran únicamente mediante la API scheduledQueryRules.
Algunos comandos y combinaciones de análisis son incompatibles con el uso de las alertas de registro.
Para más información, consulte Consultas de alertas de registro en Azure Monitor.
Período de tiempo . Especifica el intervalo de tiempo para la consulta. La consulta devuelve solo los
registros que se crearon dentro de este intervalo de tiempo actual. El período de tiempo restringe los
datos capturados para la consulta de registros, a fin de evitar abusos y cualquier comando de tiempo
(como “ago”) utilizado en las consultas de registros.
Por ejemplo, si el período de tiempo se establece en 60 minutos, y la consulta se ejecuta a las 13:15, se
devuelven solo los registros creados entre las 12:15 y las 13:15 para ejecutar la consulta de registros.
Ahora, si la consulta de registros utiliza un comando de tiempo, como ago (7d), la consulta de registro
se ejecutaría solo para los datos entre las 12:15 y las 13:15, como si existieran datos solo para los
últimos 60 minutos. Y no durante siete días de datos, tal como se especifica en la consulta de registros.
Frecuencia . Especifica con qué frecuencia se debe ejecutar la consulta. Puede ser cualquier valor entre
5 minutos y 24 horas. Debe ser menor o igual que el período de tiempo. Si el valor es mayor que el
período de tiempo, se arriesga a que se pierdan registros.
Por ejemplo, considere la posibilidad de un período de tiempo de 30 minutos y una frecuencia de 60
minutos. Si la consulta se ejecuta a la 1:00, devolverá registros entre las 12:30 y la 1:00 p. m. La
próxima vez que se ejecute la consulta será a las 2:00 y devolverá los registros comprendidos entre la
1:30 y las 2:00. Nunca se evaluarían los registros creados entre la 1:00 y las 13:30.
Umbral . Los resultados de la búsqueda de registros se evalúan para determinar si se debe crear una
alerta. El umbral es diferente para los distintos tipos de reglas de alerta de búsqueda de registros.
Las reglas de búsqueda de registros de Azure Monitor o Application Insights pueden ser de dos tipos. Cada
uno de estos tipos se describe en detalle en las secciones que aparecen a continuación.
Número de resultados . Alerta única creada cuando los registros de números devueltos por la búsqueda
de registros superan un número especificado.
Unidades métricas . Alerta creada para cada objeto de los resultados de la búsqueda de registros con
valores que superan el umbral especificado.
Las diferencias entre los tipos de reglas de alerta son las siguientes.
La regla de alertas para Número de resultados crea siempre una alerta única mientras que la regla de
alertas para Unidades métricas crea una alerta para cada objeto que supere el umbral.
Las reglas de alerta para número de resultados crean una alerta cuando se supera el umbral una sola vez.
Las reglas de alerta para unidades métricas pueden crear una alerta cuando se supera el umbral un
número determinado de veces en un intervalo de tiempo determinado.
Reglas de alerta para número de resultados
Las reglas de alerta para número de resultados crean una única alerta cuando el número de registros
devueltos por la consulta de búsqueda supera el umbral especificado. Este tipo de regla de alertas es perfecto
para trabajar con eventos como, por ejemplo, registros de eventos de Windows, Syslog, respuesta de WebApp
y registros personalizados. Es posible que desee crear una alerta cuando se genere un evento de error
concreto o cuando se generen varios eventos de error durante un período de tiempo establecido.
Umbral : el umbral de una regla de alertas para un número de resultados es mayor o menor que un valor
determinado. Se crea una alerta si el número de registros devueltos por la búsqueda de registros coincide con
este criterio.
Para generar una alerta en un evento único, establezca el número de resultados en un valor mayor que 0 y
compruebe la aparición de un evento único que se creó desde la última vez que se ejecutó la consulta.
Algunas aplicaciones pueden registrar un error ocasional que no tiene por qué haber generado
necesariamente una alerta. Por ejemplo, la aplicación puede volver a intentar realizar el proceso que creó el
evento de error y completarlo correctamente la vez siguiente. En este caso, es posible que no desee crear la
alerta, a menos que se creen varios eventos en un período de tiempo determinado.
En algunos casos, quizá quiera crear una alerta sin que haya un evento. Por ejemplo, un proceso puede
registrar eventos regulares para indicar que está funcionando correctamente. Si no se registra uno de estos
eventos dentro de un período de tiempo determinado, debe crearse una alerta. En este caso, tendría que
establecer el umbral en un valor less than 1 (menor que 1).
Ejemplo de alerta de registro del tipo número de registros
Considere un escenario donde desea saber cuándo la aplicación basada en web proporciona una respuesta a
los usuarios con el código 500, un error interno del servidor. Crearía una regla de alertas con los detalles
siguientes:
Consulta: solicitudes | donde resultCode == "500"
Período de tiempo : 30 minutos
Frecuencia de aler ta: cinco minutos
Valor del umbral: mayor que 0
De ese modo, la alerta ejecutaría la consulta cada 5 minutos, con 30 minutos de datos, para buscar cualquier
registro con un código de resultado de 500. Si se encuentra aunque sea uno de estos registros, se
desencadena la alerta y la acción configurada.
Reglas de alertas para medición de métricas
Las reglas de alertas para unidades métricas crean una alerta para cada objeto de una consulta con un
valor que supera un umbral especificado y una consulta de desencadenador especificada. A diferencia de las
reglas de alertas de número de resultados , las de unidades métricas funcionan cuando los resultados de
análisis proporcionan una serie temporal. Presentan las siguientes diferencias con respecto a las reglas de
alerta para número de resultados .
Función de agregado : Determina el cálculo que se lleva a cabo y potencialmente un campo numérico
para agregar. Por ejemplo, count() devuelve el número de registros de la consulta y
avg(CounterValue) , el promedio del campo CounterValue durante el intervalo. La función de
agregado en la consulta debe recibir el siguiente nombre: AggregatedValue y proporcionar un valor
numérico.
Campo de grupo : Se crea un registro con un valor agregado para cada instancia de este campo y se
puede generar una alerta para cada una. Por ejemplo, si desea generar una alerta para cada equipo,
usaría by Computer (por Equipo). En caso de que haya varios campos de grupos especificados en la
consulta de alerta, el usuario puede especificar qué campo desea usar para clasificar los resultados
mediante el parámetro Aggregate On (metricColumn).
NOTE
El parámetro Aggregate On (metricColumn) está disponible para alertas de registro del tipo unidades métricas
para Application Insights y para alertas de registro de Log Analytics que se configuran únicamente mediante
scheduledQueryRules API.
Inter valo : Define el intervalo de tiempo durante el cual se agregan los datos. Por ejemplo, si especifica
cinco minutos , se crearía un registro para cada instancia del campo de grupo que se agrega a
intervalos de cinco minutos en el período de tiempo especificado para la alerta.
NOTE
La función Bin se debe usar en la consulta para especificar el intervalo. Como bin() puede generar intervalos de
tiempo distintos, Alertas convertirá el comando bin automáticamente en el comando bin_at con un tiempo
adecuado en el tiempo de ejecución para garantizar resultados con un punto fijo. Las alertas de registro del tipo
unidades métricas están diseñadas para trabajar con consultas que tienen un máximo de tres instancias del
comando bin().
Umbral : El umbral de las reglas de alerta para unidades métricas se define por un valor agregado y un
número de infracciones. Si cualquier punto de datos de la búsqueda de registros supera este valor, se
considera una infracción. Si el número de infracciones para cualquier objeto de los resultados supera el
valor especificado, se crea una alerta para ese objeto.
La configuración incorrecta de las opciones Aggregate On o metricColumn puede provocar que las reglas de
alertas no funcionen. Para más información, consulte la sección sobre solución de problemas cuando la regla
de alertas de unidades métricas es incorrecta.
Ejemplo de alerta de registro del tipo Unidades métricas
Considere la posibilidad de un escenario en el que desearía tener una alerta en caso de que cualquier equipo
superara el uso del procesador en un 90 % tres veces en 30 minutos. Crearía una regla de alertas con los
detalles siguientes:
Consulta: Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" |
summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer
Período de tiempo : 30 minutos
Frecuencia de aler ta: cinco minutos
Lógica de aler tas: estado y umbral: mayor que 90
Campo de grupo (Agregado en): Computer
Activación de aler ta según: infracciones totales mayores que 2
La consulta crearía un valor medio para cada equipo a intervalos de cinco minutos. Esta consulta se ejecutaría
cada 5 minutos para los datos recopilados en los 30 minutos anteriores. Puesto que la opción Campo de
grupo (Agregado en) seleccionada es la tabla "Computer" en columnas, el valor AggregatedValue se divide en
varios valores de "Computer" y se determina la utilización media del procesador para cada equipo que viene
determinada por un intervalo temporal de 5 minutos. El resultado de la consulta de ejemplo para
(supongamos) tres equipos sería el siguiente.
T IM EGEN ERAT ED [ UTC ] C O M P UT ER A GGREGAT EDVA L UE
20xx-xx-xxT01:00:00Z srv01.contoso.com 72
… … …
Si se realizara el trazado de los resultados de la consulta, este tendría el siguiente aspecto.
En este ejemplo, hemos visto en intervalos de 5 minutos para cada uno de los tres equipos la utilización
media del procesador calculada durante 5 minutos. srv01 ha infringido el umbral de 90 solo una vez en el
minuto 1:25 del intervalo. En comparación, srv02 supera el umbral de 90 en los puntos 1:10, 1:15 y 1:25 del
intervalo mientras que srv03 supera el umbral de 90 en los puntos 1:10, 1:15, 1:20 y 1:30. Puesto que la alerta
está configurada para desencadenarse si las infracciones son más de dos, vemos que srv02 y srv03 son los
únicos que cumplen este criterio. Por tanto, se crearán alertas independientes para srv02 y srv03 porque han
incumplido el umbral del 90 % dos veces en varios intervalos de tiempo. Si, en vez de eso, el parámetro
Desencadenar alerta según: se configuró para la opción Continuous breaches (Infracciones continuas), la
alerta se desencadenaría solo para srv03 ya que infringió el umbral en tres intervalos de tiempo
consecutivos, desde 1:10 a 1:20. Y no se desencadenaría para srv02, ya que este infringió el umbral en dos
intervalos de tiempo consecutivos, de 1:10 a 1:15.
Regla de alertas de búsqueda de registros: desencadenamiento y

estado
Las reglas de alertas de búsqueda de registros solo funcionan en la lógica que se crea en la consulta. El
sistema de alertas no tiene ningún otro contexto del estado del sistema, su intención o la causa principal
implícita de la consulta. Por lo tanto, las alertas del registro se conocen como sin estado. Las condiciones se
evalúan como "TRUE" o "FALSE" cada vez que se ejecutan. Se activará una alerta cada vez que la evaluación de
la condición de alerta sea "TRUE", independientemente de que se desencadene previamente.
Veamos este comportamiento en acción con un ejemplo práctico. Supongamos que tenemos una regla de
alerta de registro llamada Contoso-Log-Alert, configurada como se muestra en el ejemplo proporcionado
para la alerta de registro de tipo Número de resultados. La condición es una consulta de alertas personalizada
diseñada para buscar el código de resultado 500 en los registros. Si se encuentran uno o más códigos de
resultado 500 en los registros, se cumple la condición de la alerta.
En cada intervalo de los que se muestran a continuación, el sistema de alertas de Azure evalúa la condición de
Contoso-Log-Alert.
N ÚM ERO DE REGIST RO S
DEVUELTO S P O R L A
C O N SULTA DE B ÚSQ UEDA EVA L UA C IÓ N DE L A
T IM E DE REGIST RO S C O N DIC IÓ N DE REGIST RO RESULTA DO
1:05 p. m. 0 registros 0 no es > 0, de modo que La alerta no se

es FALSE desencadena. No se llamó a
ninguna acción.
1:10 p. m. 2 registros 2 > 0, de modo que es La alerta se desencadena y

TRUE se llama a los grupos de
acciones. Estado de alerta
ACTIVA.
1:15 p. m. 5 registros 5 > 0, de modo que es La alerta se desencadena y

TRUE se llama a los grupos de
acciones. Estado de alerta
ACTIVA.
1:20 p. m. 0 registros 0 no es > 0, de modo que La alerta no se

es FALSE desencadena. No se llamó a
ninguna acción. El estado
de la alerta queda en
ACTIVA.
Si se usa el caso anterior como ejemplo:

A las 1:15 p. m., las alertas de Azure no pueden determinar si los problemas subyacentes que se han
detectado a las 1:10 se mantienen y si los registros son errores netos nuevos o se repiten los errores
anteriores a las 1:10 p. m. Es posible que la consulta proporcionada por el usuario tenga en cuenta o no los
registros anteriores y que el sistema no lo sepa. El sistema de alertas de Azure se ha creado para que se
produzca un error por precaución y activa la alerta y las acciones asociadas de nuevo a las 1:15 p. m.
A las 1:20 p. m. cuando se ven cero registros con el código de resultado 500, las alertas de Azure no pueden
estar seguras de que la causa del código de resultado 500 que se ha detectado a las 1:10 p. m. y 1:15 p. m.
esté ya resuelta. No sabe si se producirán los problemas de error 500 por las mismas razones. Por lo tanto, el
valor de Contoso-Log-Alert no cambiará a Resolved (Resuelto) en el panel de alertas de Azure ni se envían
notificaciones para indicar que la alerta se resolvió. Solo usted, que comprende la condición o el motivo
exactos de la lógica insertada en la consulta de análisis, puede marcar la alerta como cerrada, según sea
necesario.
Precios y facturación de las alertas de registro

Los precios que se aplican a las alertas de registro están disponibles en la página Precios de Azure Monitor. En
las facturas de Azure, Alertas de registro se representa como tipo microsoft.insights/scheduledqueryrules
con:
Alertas de registro en Application Insights se muestra con el nombre exacto de la alerta junto con el grupo
de recursos y las propiedades de la alerta
Las alertas de registro de Log Analytics aparecen con el nombre exacto de la alerta junto con el grupo de
recursos y las propiedades de la alerta cuando se crean mediante scheduledQueryRules API.
La API heredada de Log Analytics dispone de acciones y programaciones de alertas como parte de la
búsqueda guardada de Log Analytics y no recursos de Azure propiamente dichos. Por tanto, para habilitar la
facturación de tales alertas de registro heredadas creadas para Log Analytics mediante Azure Portal sin
cambiar a la nueva API o mediante la API heredada de Log Analytics, se crean pseudo reglas de alertas ocultas
en microsoft.insights/scheduledqueryrules para la facturación en Azure. Las pseudo reglas de alertas ocultas
creadas para la facturación en microsoft.insights/scheduledqueryrules aparecen como
<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId> junto con las propiedades de grupo de recursos y
alerta.
NOTE
Si hay caracteres no válidos como <, >, %, &, \, ?, / , se reemplazarán por _ en el nombre de la pseudo regla de
alertas oculta y, por tanto, también en la factura de Azure.
Para eliminar los recursos scheduleQueryRules ocultos que se crearon para la facturación de reglas de alertas
mediante la API heredada de Log Analytics, el usuario puede efectuar cualquiera de las siguientes acciones:
El usuario puede cambiar la preferencia de API para las reglas de alertas del área de trabajo de Log
Analytics y sin perder sus reglas de alertas y sin supervisión puede moverlas a scheduledQueryRules API
compatible con Azure Resource Manager. Esto elimina la necesidad de crear pseudo reglas de alertas
ocultas para la facturación.
O si el usuario no desea cambiar la preferencia de API, deberá eliminar la programación original y la
acción de alerta mediante la API heredada de Log Analytics o eliminar la regla de alertas original en Azure
Portal
Además, para los recursos scheduleQueryRules ocultos que se crearon para la facturación de reglas de alertas
mediante la API heredada de Log Analytics, cualquier operación de modificación como PUT dará error. Como
las pseudo reglas de tipo microsoft.insights/scheduledqueryrules son para fines de facturación de las reglas
de alerta creadas con la API heredada de Log Analytics. Cualquier modificación de la regla de alerta se debe
realizar mediante la API heredada de Log Analytics o el usuario puede cambiar la preferencia de API para las
reglas de alerta para usar en cambio la API scheduledQueryRules.
Pasos siguientes
Más información sobre la creación de alertas de registro en Azure.
Información sobre webhooks en alertas de registro en Azure.
Más información acerca de las Alertas de Azure.
Más información sobre Application Insights.
Más información sobre Log Analytics.
Alertas de registro de actividad
Las alertas del registro de actividad son alertas que se activan cuando un nuevo evento del registro de actividad
cumple las condiciones especificadas en la alerta. Según el orden y el volumen de los eventos registrados en el
registro de actividad de Azure, se activará la regla de alerta. Las regla de alertas del registro de actividad son
recursos de Azure, por lo que pueden crearse con una plantilla de Azure Resource Manager. También se pueden
crear, actualizar o eliminar en Azure Portal. Este artículo presenta los conceptos relativos a las alertas del registro de
actividad. Para más información sobre cómo crear o usar reglas de alertas de registro de actividad, consulte
Creación y administración de alertas del registro de actividad.
NOTE
No se pueden crear alertas para eventos en la categoría Alerta del registro de actividad.
Por lo general, se crean alertas del registro de actividad para recibir notificaciones cuando:
Se produzcan operaciones específicas en los recursos de la suscripción de Azure, que abarcan normalmente
grupos de recursos o recursos en particular. Por ejemplo, si quiere que le notifiquen cuando se elimine alguna
máquina virtual de myProductionResourceGroup. O, podría querer recibir una notificación si se asigna algún rol
nuevo a un usuario de la suscripción.
Se produce un evento de mantenimiento del servicio. Los eventos de mantenimiento del servicio incluyen la
notificación de incidentes y eventos de mantenimiento que se aplican a recursos de la suscripción.
Una simple analogía para comprender las condiciones en las que se pueden crear reglas de alertas en el registro de
actividad es explorar o filtrar eventos a través del Registro de actividad en Azure Portal. En "Azure Monitor: registro
de actividad" se puede filtrar o buscar un evento necesario y crear una alerta mediante el botón Agregar aler ta
de registro de actividad .
En cualquier caso, una alerta del registro de actividad solo supervisa eventos de la suscripción en la que se ha
creado la alerta.
Puede configurar una alerta del registro de actividad según las propiedades de nivel superior del objeto JSON de
un evento del registro de actividad. Para obtener más información, consulte Categorías del Registro de actividad.
Para más información acerca de los eventos de mantenimiento del servicio, consulte Recibir alertas del registro de
actividad con las notificaciones del servicio.
Las alertas del registro de actividad tienen algunas opciones en común:
Categoría : Administración, Mantenimiento del servicio, Escalado automático, Seguridad, Directiva y
Recomendación.
Ámbito : el recurso individual o conjunto de recursos para el que se define la alerta de registro de actividad. El
ámbito de una alerta de registro de actividad se puede definir en distintos niveles:
Nivel de recurso: por ejemplo, para una máquina virtual concreta
Nivel de grupo de recursos: por ejemplo, todas las máquinas virtuales de un grupo de recursos específico
Nivel de suscripción: por ejemplo, todas las máquinas virtuales de una suscripción (o) todos los recursos
de una suscripción
Grupo de recursos : de forma predeterminada, la regla de alertas se guarda en el grupo de recursos que tiene
el destino definido en el ámbito. El usuario también puede definir el grupo de recursos donde se debe almacenar
la regla de alertas.
Tipo de recurso : Resource Manager ha definido el espacio de nombres para el destino de la alerta.
Nombre de la operación : Nombre de la operación de Azure Resource Manager utilizado por el control de
acceso basado en rol. No se pueden usar operaciones no registradas con Azure Resource Manager en una regla
de alerta de registro de actividad.
Nivel : el nivel de gravedad del evento (informativo, advertencia, error o crítico).
Estado : el estado del evento, normalmente Iniciado, Error o Correcto.
Evento iniciado por : También se denomina "llamador". La dirección de correo electrónico o el identificador de
Azure Active Directory del usuario que realizó la operación.
NOTE
En una suscripción se pueden crear hasta 100 reglas de alertas para una actividad del ámbito en el nivel: de un único recurso,
de todos los recursos de un grupo de recursos (o) de suscripción completa.
Cuando se activa una alerta del registro de actividad, usa un grupo de acciones para generar acciones o
notificaciones. Un grupo de acciones es un conjunto reutilizable de destinatarios de notificación, como direcciones
de correo electrónico, direcciones URL del webhook o números de teléfono para SMS. Se puede hacer referencia a
los receptores desde varias alertas para centralizar y agrupar los canales de notificación. Al definir la alerta del
registro de actividad, tiene dos opciones. Puede:
Usar un grupo de acciones existente en la alerta del registro de actividad.
Crear un nuevo grupo de acciones.
Para más información sobre los grupos de acciones, consulte Creación y administración de grupos de acciones en
Azure Portal.
Pasos siguientes
Obtener una Introducción a las alertas.
Obtenga información sobre la creación y modificación de las alertas del registro de actividad.
Revise el Esquema de webhook de alertas del registro de actividad.
Más información acerca de las Notificaciones del estado del servicio.
Visualizar datos de Azure Monitor
En este artículo se proporciona un resumen de los métodos disponibles para visualizar los datos de métricas y
de registro almacenados en Azure Monitor.
Visualizaciones como gráficos y diagramas pueden ayudarlo a analizar los datos de supervisión para explorar en
profundidad los problemas e identificar patrones. Según la herramienta que utilice, es posible que también tenga
la opción de compartir visualizaciones con otros usuarios dentro y fuera de su organización.
Workbooks
Los libros son documentos interactivos que proporcionan información detallada sobre los datos, la investigación
y colaboración en el equipo. Algunos ejemplos de libros útiles son las guías de resolución de problemas y los
análisis posteriores a incidentes.
Ventajas
Es compatible con las métricas y los registros.
Admite parámetros que habilitan los informes interactivos en que, al seleccionar un elemento en una tabla, se
actualizarán dinámicamente los gráficos y las visualizaciones asociados.
Flujo similar al de los documentos.
Opción de libros personales o compartidos.
Experiencia de creación sencilla y colaborativa.
Las plantillas admiten la galería de plantillas públicas basadas en GitHub.
Limitaciones
No hay actualizaciones automáticas.
No hay ningún diseño denso, como paneles, que haga que los libros tengan menos utilidad que un solo panel
de vidrio. Diseñado especialmente para proporcionar información más detallada.
Paneles de Azure
Los paneles de Azure son la tecnología de panel principal de Azure. Son especialmente útiles para proporcionar
una hoja de cristal sobre su infraestructura de Azure y servicios, lo que permite identificar rápidamente
problemas importantes.
Este es un tutorial en vídeo sobre la creación de paneles.
Ventajas
Integración profunda en Azure. Las visualizaciones se pueden anclar a paneles desde varias páginas de Azure,
que incluyen el Explorador de métricas, Log Analytics y Application Insights.
Es compatible con las métricas y los registros.
Puede combinar datos de varios orígenes, incluidos los resultados del Explorador de métricas, las consultas
del registro y los mapas, y la disponibilidad de Application Insights.
Opción de paneles personales o compartidos. Integrado con la autenticación basada en roles (RBAC) de
Azure.
Actualización automática. Las métricas se actualizan según el intervalo de tiempo con un mínimo de cinco
minutos. Registra la actualización cada hora, con una opción de actualización manual a petición mediante un
clic en el icono "Actualizar" en una visualización determinada o mediante la actualización del panel completo.
Paneles de métricas parametrizadas con marca de tiempo y parámetros personalizados.
Opciones de diseño flexibles.
Modo de pantalla completa.
Limitaciones
Control limitado sobre las visualizaciones de registros sin compatibilidad con tablas de datos. El número total
de series de datos se limita a 10 con otras series de datos agrupadas en otro depósito.
Los gráficos de registro no son compatibles con los parámetros personalizados.
Los gráficos de registro se limitan a los últimos 30 días.
Los gráficos de registro solo se pueden anclar a los paneles compartidos.
No hay interactividad con los datos del panel.
Exploración en profundidad contextual limitada.
Power BI
Power BI es particularmente útil para crear informes y paneles centrados en los negocios, así como informes de
análisis de tendencias de KPI a largo plazo. Puede importar los resultados de una consulta de registro en un
conjunto de datos de Power BI para poder beneficiarse de sus características, como la combinación de datos de
diferentes orígenes y el uso compartido de informes en la web y los dispositivos móviles.
Ventajas
Visualizaciones enriquecidas.
Amplia interactividad, incluidas las funciones de acercamiento y filtrado cruzado.
Fácil de compartir en toda la organización.
Integración con otros datos desde varios orígenes de datos.
Mejor rendimiento con los resultados almacenados en caché en un cubo.
Limitaciones
Admiten registros, pero no las métricas.
No hay integración de Azure. No puede administrar los paneles y los modelos a través de Azure Resource
Manager.
Los resultados de las consultas deben importarse en el modelo de Power BI para que se configuren.
Limitación de tamaño de los resultados y de actualización.
La actualización de datos se limita a ocho veces al día.
Grafana
Grafana es una plataforma abierta que sobresale en paneles operativos. Resulta especialmente útil para detectar,
aislar y priorizar los incidentes operativos. Puede agregar el complemento de origen de datos de Azure Monitor
en Grafana a su suscripción de Azure para visualizar los datos de métricas de Azure.
Ventajas
Visualizaciones enriquecidas.
Ecosistema enriquecido de orígenes de datos.
Interactividad de datos que incluye la función de acercamiento.
Es compatible con parámetros.
Limitaciones
No hay integración de Azure. No puede administrar los paneles y los modelos a través de Azure Resource
Manager.
Costo para admitir una infraestructura Grafana adicional o costo adicional para Grafana Cloud.
Compilar su propia aplicación personalizada

Puede tener acceso a datos de métricas y de registro en Azure Monitor mediante la API con cualquier cliente
REST, lo que le permite crear sus propios sitios web y aplicaciones personalizados.
Ventajas
Flexibilidad completa en cuanto a interfaz de usuario, visualización, interactividad y características.
Combine las métricas y los datos de registro con otros orígenes de datos.
Inconvenientes
Se requiere un trabajo de ingeniería importante.
Vistas de Azure Monitor

IMPORTANT
Las vistas están en proceso de quedar en desuso. Consulte la Guía de transición del diseñador de vistas de Azure Monitor
a libros para obtener instrucciones sobre cómo convertir vistas en libros.
Las vistas de Azure Monitor le permiten crear visualizaciones personalizadas con datos de registro. Las
soluciones de supervisión las utilizan para presentar los datos recopilados.
Ventajas
Visualizaciones enriquecidas para datos de registro.
Exporte e importe las vistas para transferirlas a otros grupos de recursos y suscripciones.
Se integran en el modelo de administración de Azure Monitor con áreas de trabajo y soluciones de
supervisión.
Filtran los parámetros personalizados.
Interactivas, admiten varios niveles de obtención de detalles (vista que explora otra vista)
Limitaciones
Admiten registros, pero no las métricas.
No hay vistas personales. Disponibles para todos los usuarios con acceso al área de trabajo.
No hay actualizaciones automáticas.
Opciones de diseño limitadas.
No se admiten las consultas a través de varias áreas de trabajo o aplicaciones de Application Insights.
El tamaño de respuesta y el tiempo de ejecución de las consultas se limitan a 8 MB y 110 segundos,
respectivamente.
Pasos siguientes
Obtenga información sobre los datos que Azure Monitor recopila.
Obtenga información sobre los paneles de Azure.
Obtenga información sobre las vistas de Azure Monitor.
Obtenga información sobre Workbooks.
Obtenga información sobre cómo importar datos de registro en Power BI.
Obtenga información sobre el complemento de origen de datos de Azure Monitor en Grafana.
Integraciones de asociados de Azure Monitor
Se enumeran en orden alfabético.
AlertLogic Log Manager
Alert Logic Log Manager recopila registros de la plataforma de Azure, aplicaciones y máquinas virtuales a efectos
de retención y análisis de seguridad. También recopila el registro de actividad de Azure a través de la API de Azure
Monitor. Esta información se utiliza para detectar conductas indebidas y satisfacer los requisitos de cumplimiento.
Vaya a la documentación.
AppDynamics
Application Performance Management (APM) de AppDynamics permite a los propietarios de aplicaciones

solucionar rápidamente los cuellos de botella de rendimiento y optimizar el rendimiento de las aplicaciones en
ejecución en el entorno de Azure. Puede supervisar Azure Cloud Services (PaaS), los roles web y de trabajo, Virtual
Machines (IaaS), Detección de servicios remotos (Microsoft Azure Service Bus), Servicios remotos de Microsoft
Azure y Colas de Microsoft Azure (Blob de Azure), Cola de Azure (Microsoft Service Bus), Almacenamiento de
datos y Microsoft Azure Blob Storage. AppDynamics APM ya está disponible en Azure Marketplace.
Atlassian JIRA
Puede crear incidencias JIRA de alertas de Azure Monitor.

Botmetric
Más información.
Circonus
Circonus es experto en inteligencia artificial de datos y proporciona la única plataforma de inteligencia artificial de
datos capaz de administrar miles de millones de flujos de métricas en tiempo real para generar un valor y unas
conclusiones empresariales sin precedentes. Use Circonus para recopilar y visualizar las métricas clave
relacionadas con la configuración de Microsoft Azure, así como para hacer su seguimiento. Consiga visibilidad en
todo el sistema con respecto a la utilización de los recursos, el rendimiento de las aplicaciones y el estado
operativo de Azure.
CloudHealth
Una y automatice la nube con una plataforma creada para ahorrar tiempo y dinero. CloudHealth proporciona
visibilidad, optimización intuitiva y prácticas de gobernanza sólidas para la administración en la nube. La
plataforma CloudHealth permite que las empresas y los MSP maximicen la rentabilidad de las inversiones en la
nube. Tome decisiones seguras relacionadas con el costo, el uso, el rendimiento y la seguridad.
Más información
CloudMonix
CloudMonix ofrece servicios de supervisión, automatización y recuperación automática para la Plataforma

Microsoft Azure.
Datadog
Datadog es el servicio de supervisión líder mundial para aplicaciones en la nube. Agrupa datos de servidores,
bases de datos, herramientas y servicios para presentar una vista unificada de toda la pila. Estas funcionalidades
se proporcionan en una plataforma de análisis de datos basada en SaaS. Este servicio permite a los equipos de
desarrollo y operaciones trabajar en colaboración para evitar tiempos de inactividad, resolver problemas de
rendimiento y asegurarse de que los ciclos de desarrollo e implementación finalizan a tiempo. Con la integración
de Datadog y Azure, puede recopilar y ver las métricas de toda la infraestructura. Correlacione las métricas de
máquina virtual con las del nivel de aplicación. Segmente y desglose las métricas mediante cualquier combinación
de propiedades y etiquetas personalizadas.
Dynatrace
Dynatrace OneAgent se integra con máquinas virtuales Azure y App Services a través del mecanismo de extensión
de Azure. De esta forma, Dynatrace OneAgent puede recopilar métricas de rendimiento sobre los hosts, la red y
los servicios. Además de simplemente mostrar las métricas, Dynatrace permite visualizar entornos de un extremo
a otro. Muestra las transacciones desde el lado cliente a la capa de base de datos. Dynatrace proporciona una
correlación de problemas basada en inteligencia artificial y un análisis de las causas principales totalmente
integrado para proporcionar información en el nivel de método sobre el código y la base de datos. Esto facilita
bastante la solución de problemas y las optimizaciones de rendimiento.
Elastic
Elastic es una empresa de búsquedas. Como creadores de Elastic Stack (Elasticsearch, Kibana, Beats, y Logstash),
Elastic crea ofertas autoadministradas y de SaaS que permiten usar los datos en tiempo real y a escala, para casos
de uso de búsqueda, registro, seguridad y análisis.
Grafana
Grafana es una aplicación de código abierto que permite visualizar datos de métricas de series temporales.
InfluxData
InfluxData es el creador de InfluxDB, la base de datos de serie temporal de código abierto. Nuestra tecnología está
diseñada específicamente para controlar los volúmenes masivos de datos con marca de tiempo generados por
dispositivos IoT, aplicaciones, redes, contenedores y equipos. Estamos en una misión para ayudar a
desarrolladores y organizaciones, como IBM, Visa, Siemens, Tesla y NASA, a almacenar y analizar datos en tiempo
real, lo que les permite compilar aplicaciones de supervisión, análisis e IoT transformadoras y escalables más
rápido. Las funcionalidades de recopilación de eventos y métricas de Microsoft Azure Monitor se pueden expandir
con el agente de InfluxData Telegraf, lo que permite a los usuarios de Microsoft beneficiarse de una solución de
base de datos de serie temporal líder y aprovechar las cada vez mayores contribuciones de código abierto a
Telegraf.
Logic Monitor
LogicMonitor® es la plataforma de supervisión de rendimiento basada en SaaS más importante para
infraestructuras de TI complejas. Con la cobertura para miles de tecnologías, LogicMonitor proporciona una visión
pormenorizada del rendimiento de infraestructuras y aplicaciones. La exhaustiva supervisión de Azure que realiza
LM Cloud permite a los usuarios poner en correlación el rendimiento de los recursos en la nube de Azure, en la
nube híbrida y locales. Todo desde la misma plataforma. La combinación de detección de recursos automática,
plantillas de supervisión integradas, umbrales de alerta preconfigurados y paneles proporciona a la TI la
velocidad, flexibilidad y visibilidad necesarias.
LogRhythm
LogRhythm, líder en SIEM de última generación, permite a las organizaciones de seis continentes reducir de forma
medible el riesgo mediante la rápida detección, respuesta y neutralización de las ciberamenazas. El flujo de trabajo
de Threat Lifecycle Management (TLM) de LogRhythm es la base de los centros de operaciones de seguridad, que
ayudan a los clientes a proteger sus infraestructuras virtuales, físicas y en la nube para entornos de TI y OT. Si es
cliente de LogRhythm y está listo para comenzar su recorrido por Azure, deberá instalar y configurar la
integración de LogRhythm Open Collector y EventHub. Puede encontrar más información, incluida la
documentación de la configuración tanto de Azure Monitor como de Open Collector, aquí.
Microfocus
ArcSight de Microfocus tiene un conector inteligente para los centros de eventos de Azure Monitor.
Más información
Bridge Operations de Microfocus supervisa automáticamente todos los recursos de TI híbridos: cualquier
dispositivo, sistema operativo, base de datos, aplicación o servicio, independientemente de dónde se ejecute y
aplique AIOps a todos los tipos de datos, ya sean eventos, métricas, registros o dependencias. Proporciona una
combinación única de supervisión de calidad de servicio, junto con análisis profundos del estado de las
aplicaciones, e incluye supervisión completa del rendimiento y la disponibilidad de los servicios de Microsoft
Azure. Operations Bridge permite a los clientes proporcionar un solo panel de visualización, disponible en
cualquier dispositivo que tenga un explorador, de una manera que las partes interesadas empresariales y de TI
puedan comprender.
Más información
Información general del conjunto de OB
Descargar
SiteScope: SiteScope es un componente del conjunto de Operations Bridge.
Moogsoft
Moogsoft AIOps acelera la ágil transformación empresarial.
Las herramientas de Microsoft Azure Automation and Control proporcionan una ventana en tiempo real en la que
se puede conocer el estado de las aplicaciones y microservicios implementados en Azure. Ayudan a coordinar
diagnósticos y runbooks para solucionar cualquier problema más rápidamente. Otras herramientas de terceros
proporcionan una ventana que permite ver el estado de la infraestructura y las aplicaciones locales.
Moogsoft AIOps automatiza el flujo de trabajo Event to Remediation sin cambiar los procesos existentes ni la
estructura de la organización.
Moogsoft se ejecuta en el entorno de Azure con integración con herramientas de supervisión y automatización del
tejido híbrido. Moogsoft
detecta activamente los incidentes que afectan a la aplicación de forma anticipada.
organiza de forma dinámica los recursos adecuados para que estén al tanto de la situación.
reduce el tiempo medio para corregir y revertir cualquier impacto negativo en la experiencia del cliente.
NewRelic
Más información.
OpsGenie
OpsGenie actúa como un distribuidor para las alertas generadas por Azure. OpsGenie determina las personas
adecuadas a las que se debe notificar según los turnos de guardia y los procesos de escalamiento. Puede
notificarles mediante correo electrónico, mensajes de texto (SMS), llamadas telefónicas o notificaciones push.
Azure genera alertas para los problemas detectados. OpsGenie garantiza que las personas adecuadas están
trabajando en el problema.
PagerDuty
PagerDuty, la solución líder de administración de incidentes, ofrece soporte de primera clase para Azure Alerts
sobre las métricas. PagerDuty admite las notificaciones de alertas de Azure Monitor, las notificaciones de
escalabilidad automática y los eventos de registro de actividad, así como las métricas a nivel de plataforma para
los servicios de Azure. Estas mejoras ofrecen una mayor visibilidad en el núcleo de la plataforma Azure. Puede
aprovechar al máximo las funcionalidades de administración de incidentes de PagerDuty para ofrecer respuestas
en tiempo real. La integración expandida de Azure se realiza a través de webhooks. Los webhooks le permiten
configurar y personalizar la solución rápida y fácilmente.
Promitor
Promitor es un extractor de Azure Monitor que pone las métricas a disposición en sistemas como Atlassian
Statuspage, Prometheus y StatsD.
Inserte todas las métricas en Azure Monitor y consúmalas cuando las necesite.
Más información.
QRadar
Los protocolos Microsoft Azure DSM y Microsoft Azure Even Hub se pueden descargar en el sitio web de el sitio
web de soporte técnico de IBM. Más información sobre la integración con Azure aquí.
ScienceLogic
ScienceLogic ofrece la plataforma de seguridad del servicio de TI de próxima generación para administrar
cualquier tecnología y en cualquier lugar. ScienceLogic ofrece la escala, seguridad, automatización y resistencia
necesarias para simplificar las tareas de administración de recursos, servicios y aplicaciones de TI. La plataforma
de ScienceLogic usa las API de Azure para comunicarse con Microsoft Azure. ScienceLogic le proporciona
visibilidad en tiempo real sobre los servicios y recursos de Azure. De este modo, podrá saber cuándo algo no
funciona y lo podrá corregir con mayor rapidez. También puede administrar Azure junto con otras nubes y otros
sistemas de centros de datos y servicios.
Más información.
Serverless360
Serverless360 es una herramienta de plataforma para operar, administrar y supervisar los componentes sin
servidor de Azure. La facilidad de uso es uno de los principales desafíos de las implementaciones sin servidor.
Existen cientos de pequeños y discretos servicios sin servidor dispersos en varios lugares; la administración y el
funcionamiento de estas soluciones son complejos. Serverless360 resuelve estos desafíos con un amplio conjunto
de herramientas sofisticadas. Puede supervisar servicios sin servidor como Azure Functions, Logic Apps, Event
Grids, colas de Service Bus, temas, Relays, Event Hubs, colas de Storage, archivos, blobs y tablas. Serverless360
está disponible en Azure Marketplace. Estas funcionalidades están disponibles en el hospedaje privado
(hospedado en su propio entorno) y de SaaS.
Más información.
ServiceNow
Reduzca los incidentes y el MTTR con la plataforma NOW AIOps para eliminar el ruido, priorizar, identificar la
detección de la causa raíz mediante ML y solucionar problemas con flujos de trabajo de ITX. Comprenda el estado
actual de los servicios IaaS/PaaS/FaaS de Azure y cree mapas de servicio a partir de etiquetas para compilar el
contexto del servicio de aplicación para el análisis del impacto empresarial.
Más información.
SignalFx
SignalFx es el líder en inteligencia operativa en tiempo real para DevOps controlado por datos. El servicio detecta
y recopila métricas de todos los componentes en la nube. Reemplaza las tradicionales herramientas de puntos y
proporciona visibilidad en tiempo real de los actuales entornos dinámicos. El aprovechamiento de la plataforma
SignalFx, que es altamente escalable, hace que la plataforma de SaaS esté optimizada para infraestructuras
basadas en contenedor y microservicios y proporcione eficaces funcionalidades de visualización, generación
proactiva de alertas y evaluación de prioridades durante la colaboración en organizaciones de todos los tamaños.
SignalFx se integra directamente con Azure Monitor, así como a través de conectores de código abierto como
Telegraf, statsD y collectd, con el fin de proporcionar los mejores paneles, análisis y alertas para Azure.
SIGNL4
SIGNL4: aplicación de alertas móviles para equipos de operaciones. Es la forma más rápida de enrutar las alertas
críticas de Azure Monitor a las personas adecuadas en el momento oportuno. En cualquier lugar mediante
notificaciones push, mensajes de texto y llamadas de voz. SIGNL4 administra las guardias y los turnos de su
equipo, hace un seguimiento del envío y la propiedad de las alertas y las escala si fuera necesario. Se proporciona
una transparencia al equipo. Mediante el sencillo webhook REST de SIGNL4 se puede conectar cualquier servicio
de Azure sin esfuerzo alguno. Con SIGNL4, verá una respuesta que es hasta 10 veces más rápida que las
notificaciones por correo electrónico y las alertas manuales.
SolarWinds
Más información.
Splunk
El complemento Azure Monitor para Splunk está disponible en Splunkbase aquí.

SquaredUp
SquaredUp para Azure hace que la visualización de las aplicaciones de Azure sea muy sencilla. Proporciona
paneles interactivos en tiempo real. Puede explorar en profundidad las suscripciones, los grupos de recursos, las
etiquetas y los recursos individuales para ver las métricas, como la CPU, la mayoría de las conexiones entrantes, el
tiempo de respuesta de Application Insights, el costo total y el estado de mantenimiento resumido, así como
obtener detalles para consultar los datos relacionados, como las alertas, los eventos de Log Analytics, y métricas
más detalladas, o para ver los datos relacionados de otras herramientas que use: como ServiceNow, Dynatrace,
PagerDuty o Pingdom, por ejemplo. Puede personalizar sus propios paneles, publicarlos y compartirlos con
personas o en páginas de la intranet.
Más información.
Sumo Logic
Sumo Logic es un servicio de análisis de datos de máquinas seguro y nativo en la nube, dado que ofrece
inteligencia continua en tiempo real a partir de datos estructurados, semiestructurados y no estructurados desde
la pila y el ciclo de vida de toda la aplicación. Más de mil clientes de todo el mundo confían en Sumo Logic para las
tareas de análisis y recopilación de datos relevantes con el objetivo de generar, ejecutar y proteger sus
aplicaciones e infraestructuras en la nube. Con Sumo Logic, los clientes obtienen una ventaja basada en un
modelo de servicio y multiinquilino para aumentar la ventaja competitiva, el valor del negocio y el crecimiento.
Más información.
Turbonomic
Turbonomic ofrece automatización de cargas de trabajo en nubes híbridas, ya que optimiza simultáneamente el
rendimiento, costo y cumplimiento en tiempo real. Turbonomic ayuda a aumentar la elasticidad del estado de
Azure de las organizaciones mediante la optimización continua del estado para garantizar que las aplicaciones
obtienen constantemente los recursos que necesitan para cumplir su Acuerdo de Nivel de Servicio y nada más en
relación con el proceso, el almacenamiento y la red para la capa de IaaS y PaaS. Las organizaciones pueden
simular migraciones, escalar cargas de trabajo correctamente y retirar recursos del centro de datos para realizar
responsablemente la migración a Azure de forma puntual y sin salirse del presupuesto, al mismo tiempo que se
garantizan el rendimiento y el cumplimiento. Turbonomic es un producto controlado por API y se ejecuta como
una VM sin agente en Azure y en local.
Más información.
Pasos siguientes
Obtener más información sobre Azure Monitor
Acceder a métricas mediante la API de REST
Transmitir el registro de actividad a un servicio que no es de Microsoft
Transmisión de los registros de recursos a un servicio que no es de Microsoft
Línea de base de seguridad de Azure para Azure
Monitor
Esta línea de base de seguridad aplica las directrices de Azure Security Benchmark a Azure Monitor. Azure Security
Benchmark proporciona recomendaciones sobre cómo puede proteger sus soluciones de nube en Azure. El
contenido se agrupa por medio de los controles de seguridad definidos por Azure Security Benchmark y las
directrices aplicables a Azure Monitor. Se han excluido los controles no aplicables a Azure Monitor. Para ver cómo
Azure Monitor se adapta por completo a Azure Security Benchmark, consulte el archivo de asignación de base de
referencia de seguridad de Azure Policy completo.
Azure Monitor forma parte de los servicios principales de Azure y no se puede implementar como un servicio por
separado. Los componentes de Azure Monitor se pueden implementar con los recursos del usuario, lo cual puede
afectar a la posición de seguridad de esos recursos.
Seguridad de las redes

Para obtener más información, consulte Azure Security Benchmark: Seguridad de redes.
1.1: Protección de los recursos de Azure dentro de las redes virtuales
Instrucciones : Habilite Azure Private Link para permitir el acceso a los servicios PaaS de Azure (por ejemplo, Azure
Monitor) y a los servicios hospedados de clientes o asociados en Azure a través de un punto de conexión privado
de la red virtual. El tráfico entre la red virtual y el servicio atraviesa la red troncal de Microsoft, eliminando la
exposición a la red pública de Internet.
Para que el tráfico llegue a Azure Monitor, utilice las etiquetas de servicio "AzureMonitor" para permitir el tráfico
entrante y saliente a través de grupos de seguridad de red. Para que el tráfico de prueba de supervisión de
disponibilidad llegue a Azure Monitor, utilice la etiqueta de servicio "ApplicationInsightsAvailability" para todo el
tráfico entrante a través de grupos de seguridad de red.
Las reglas de red virtual permiten que Azure Monitor acepte solo las comunicaciones que se envían desde
subredes seleccionadas dentro de una red virtual.
Utilice la puerta de enlace de Log Analytics para enviar datos a un área de trabajo de Log Analytics en Azure
Monitor en nombre de los equipos que no se pueden conectar directamente a Internet y evite así la necesidad de
que los equipos se conecten a Internet.
Uso de Azure Private Link para conectar redes a Azure Monitor de forma segura
Conexión de equipos sin acceso a Internet mediante la puerta de enlace de Log Analytics en Azure Monitor
Super visión de Azure Security Center : No aplicable
Responsabilidad : Customer
1.2: Supervisión y registro de la configuración y el tráfico de redes virtuales, subredes e interfaces de red
Guía : Azure Monitor es un servicio principal y no admite la implementación directa en una red virtual. La
infraestructura subyacente la administra Microsoft. No obstante, para los recursos que realizan conexiones de red
para la oferta Azure Monitor, es preciso proteger su red mediante un grupo de seguridad de red. Habilite los
registros de flujo del grupo de seguridad de red y envíelos a una cuenta de almacenamiento para auditar el tráfico.
También puede enviar los registros de flujo a un área de trabajo de Log Analytics y utilizar el análisis de tráfico para
proporcionar información sobre el flujo del tráfico en la nube de Azure. Algunas de las ventajas del Análisis de
tráfico son la capacidad de visualizar la actividad de la red e identificar las zonas activas, identificar las amenazas de
seguridad, comprender los patrones de flujo de tráfico y detectar configuraciones de red incorrectas.
Al utilizar Azure Monitor con Private Link, obtendrá acceso al registro de red. Por ejemplo, los datos procesados por
el punto de conexión privado (ENTRADA/SALIDA).
Requisitos de red para agentes de Azure Monitor
Habilitación de los registros de flujo de grupos de seguridad de red
Habilitación y uso del Análisis de tráfico
Descripción de la seguridad de red proporcionada por Azure Security Center
1.8: Minimice la complejidad y la sobrecarga administrativa de las reglas de seguridad de red
Instrucciones : Para que el tráfico llegue a Azure Monitor, utilice las etiquetas de servicio "AzureMonitor" para
permitir el tráfico entrante y saliente a través de grupos de seguridad de red. Para que el tráfico de prueba de
supervisión de disponibilidad llegue a Azure Monitor, utilice la etiqueta de servicio "ApplicationInsightsAvailability"
para todo el tráfico entrante a través de grupos de seguridad de red. Microsoft administra los prefijos de
direcciones que la etiqueta de servicio incluye y actualiza automáticamente dicha etiqueta a medida que las
direcciones cambian.
Descripción y uso de las etiquetas de servicio
1.10: Documente las reglas de configuración de tráfico
Guía : Azure Monitor forma parte de los servicios principales de Azure y no se puede implementar como un
servicio por separado. Los componentes de Azure Monitor, como el agente de Azure Monitor y el SDK de
Application Insights, se pueden implementar con los recursos del usuario, lo cual puede afectar a la posición de
seguridad de esos recursos.
Requisitos de red para agentes de Azure Monitor
Introducción a Application Insights
Cómo configurar las pruebas web de disponibilidad
1.11: Use herramientas automatizadas para supervisar las configuraciones de recursos de red y detectar cambios
Instrucciones : Utilice Azure Activity Log para supervisar las configuraciones de recursos y detectar cambios en los
recursos de red relacionados con Azure Monitor. Cree alertas en Azure Monitor para que se desencadenen al
producirse cambios en esos recursos de red críticos.
Visualización y recuperación de eventos del registro de actividad de Azure
Creación de alertas en Azure Monitor
Registro y supervisión
Para obtener más información, consulte Azure Security Benchmark: registro y supervisión.
2.2: Configuración de la administración central de registros de seguridad
Guía : Azure Monitor utiliza registros de actividad para registrar los cambios que se producen en sus recursos.
Puede exportar estos registros a Azure Storage, al centro de eventos o a un área de trabajo de Log Analytics.
Recopile registros mediante Azure Monitor para agregar datos de seguridad generados por dispositivos de punto
de conexión, recursos de red y otros sistemas de seguridad. En Azure Monitor, puede consultar y analizar los datos,
además de utilizar cuentas de Azure Storage para el almacenamiento de registros a largo plazo o con fines de
archivo.
Como alternativa, puede habilitar e incorporar datos en Azure Sentinel o en una herramienta SIEM de terceros.
Recopilación de registros y métricas de plataforma con Azure Monitor
Recopilación de registros de host internos de máquina virtual de Azure con Azure Monitor
Incorporación de Azure Sentinel
Introducción a Azure Monitor e integración con herramienta SIEM de terceros
2.3: Habilitación del registro de auditoría para recursos de Azure
Guía : Azure Monitor utiliza registros de actividad, que se habilitan automáticamente y registran las operaciones
realizadas en recursos de Azure Monitor (por ejemplo, quién inició una operación, cuándo se produjo, cuál es el
estado de esa operación y otra información de auditoría útil).
Recopilación de registros y métricas de plataforma con Azure Monitor
Descripción del registro y de los distintos tipos de registro de Azure
Super visión de Azure Security Center : no disponible actualmente
2.5: Configuración de la retención del almacenamiento de registros de seguridad
Guía : En Azure Monitor, establezca el período de retención del área de trabajo de Log Analytics de acuerdo con la
normativa de cumplimiento de su organización. Utilice las cuentas de Azure Storage para el almacenamiento de
registros a largo plazo o con fines de archivo.
Cambio del período de retención de datos en Log Analytics
Configuración de la directiva de retención para los registros de la cuenta de Azure Storage
2.6: Supervisión y revisión de registros
Guía : Analice y supervise los registros en busca de comportamientos anómalos y revise los resultados con
regularidad. Use Azure Monitor y un área de trabajo de Log Analytics para revisar los registros y realizar consultas
en los datos de dichos registros.
También puede habilitar e incorporar datos en Azure Sentinel o en una herramienta SIEM de terceros.
Introducción a las consultas de Log Analytics
Procedimiento para realizar consultas personalizadas en Azure Monitor
2.7: Habilitación de alertas para actividades anómalas
Guía : Use Azure Security Center con el área de trabajo de Log Analytics para la supervisión y alertas sobre
actividades anómalas que se encuentran en los registros y eventos de seguridad. Como alternativa, puede habilitar
e incorporar datos a Azure Sentinel.
Administración de alertas de seguridad en Azure Security Center
Alertas sobre datos de registro de Log Analytics
Control de identidades y acceso

Para obtener más información, consulte Azure Security Benchmark: Identidad y control de acceso.
3.1: Mantenga un inventario de cuentas administrativas
Guía : El control de acceso basado en roles de Azure (RBAC de Azure) permite administrar el acceso a los recursos
de Azure a través de las asignaciones de roles. Puede asignar estos roles a usuarios, grupos de entidades de
servicio e identidades administradas. Hay roles integrados predefinidos para determinados recursos, y estos roles
se pueden inventariar o consultar mediante herramientas como la CLI de Azure, Azure PowerShell o el Azure Portal.
Obtención de un rol de directorio en Azure AD con PowerShell
Obtención de los miembros de un rol de directorio en Azure AD con PowerShell
3.3: Use cuentas administrativas dedicadas
Guía : Cree procedimientos operativos estándar en torno al uso de cuentas administrativas dedicadas. Use la
administración de identidad y acceso de Azure Security Center para supervisar el número de cuentas
administrativas.
También puede habilitar el acceso Just-in-Time/Just-Enough usando roles de Azure AD Privileged Identity
Management con privilegios para los servicios de Microsoft y Azure Resource Manager.
Información general sobre Azure AD Privileged Identity Management
3.4: Uso del inicio de sesión único (SSO ) de Azure Active Directory
Instrucciones : Siempre que sea posible, use el SSO de Azure Active Directory en lugar de configurar credenciales
independientes individuales por servicio. Use las recomendaciones de administración de identidades y acceso de
Descripción del SSO con Azure AD
3.5: Uso de la autenticación multifactor para todo el acceso basado en Azure Active Directory
Instrucciones : Habilite la MFA de Azure AD y siga las recomendaciones de administración de identidades y acceso
de Azure Security Center.
Procedimiento para habilitar la MFA en Azure
Supervisión de la identidad y el acceso en Azure Security Center
Super visión de Azure Security Center : Sí
3.6: Use máquinas dedicadas (estaciones de trabajo de acceso con privilegios) para todas las tareas
administrativas
Instrucciones : use una estación de trabajo segura y administrada por Azure (también conocida como una estación
de trabajo de acceso con privilegios o PAW) para las tareas administrativas que requieren privilegios elevados.
Descripción de las estaciones de trabajo seguras administradas por Azure
Cómo habilitar MFA de Azure AD
3.7: Registro y alerta de actividades sospechosas desde cuentas administrativas
Guía : use la característica de supervisión y los informes de seguridad de Azure Active Directory para detectar
cuando se producen actividades sospechosas o no seguras en el entorno. Use Azure Security Center para
supervisar la actividad de identidad y acceso.
Procedimiento para identificar usuarios de Azure AD marcados por una actividad de riesgo
Supervisión de la actividad de identidad y acceso de los usuarios en Azure Security Center
3.8: Administre los recursos de Azure solo desde ubicaciones aprobadas
Guía : Use ubicaciones con nombre de acceso condicional para permitir el acceso solo desde agrupaciones lógicas
específicas de intervalos de direcciones IP o países o regiones.
Configuración de ubicaciones con nombre en Azure
3.9: Uso de Azure Active Directory
Instrucciones : Use Azure Active Directory (AD) como sistema central de autenticación y autorización. Azure AD
protege los datos mediante un cifrado seguro para los datos en reposo y en tránsito. Azure AD también cifra con
sal, convierte en hash y almacena de forma segura las credenciales de los usuarios.
Procedimiento para crear y configurar una instancia de Azure AD
3.10: Revise y concilie regularmente el acceso de los usuarios
Guía : Azure AD proporciona registros para ayudar a descubrir cuentas obsoletas. Además, use las revisiones de
acceso de identidad de Azure para administrar de forma eficiente las pertenencias a grupos, el acceso a las
aplicaciones empresariales y las asignaciones de roles. El acceso de los usuarios se puede revisar de forma
periódica para asegurarse de que solo las personas adecuadas tengan acceso continuado.
Descripción de los informes de Azure AD
Procedimiento para usar las revisiones de acceso de identidad de Azure
3.11: Supervisión de los intentos de acceso a credenciales desactivadas
Instrucciones : Tiene acceso a los orígenes de registro de eventos de actividad de inicio de sesión, auditoría y
riesgo de Azure AD, que permiten la integración con cualquier herramienta de SIEM o supervisión. Puede
simplificar este proceso creando una configuración de diagnóstico para las cuentas de usuario de Azure Active
Directory y enviando los registros de auditoría y los registros de inicio de sesión a un área de trabajo de Log
Analytics. Puede configurar las alertas deseadas en el área de trabajo de Log Analytics.
Integración de los registros de actividad de Azure en Azure Monitor
Super visión de Azure Security Center : Anular. Proporcione un valor para el elemento de trabajo.
3.12: Alerta sobre las desviaciones de comportamiento en los inicios de sesión de las cuentas
Instrucciones : Use las características de protección de riesgos e identidad de Azure AD para configurar las
respuestas automatizadas a las acciones sospechosas detectadas relacionadas con las identidades de los usuarios.
También puede hacer que Azure Sentinel ingiera los datos para investigarlos más.
Visualización de los inicios de sesión de riesgo de Azure AD
Configuración y habilitación de las directivas de riesgo de protección de identidad
Protección de los datos

Para obtener más información, consulte Azure Security Benchmark: Protección de datos.
4.1: Mantenimiento de un inventario de información confidencial
Guía : Utilice etiquetas cuando sea posible para facilitar el seguimiento de los recursos de Azure Monitor que
almacenan o procesan información confidencial como las áreas de trabajo de Log Analytics.
Creación y uso de etiquetas
Administración del acceso a los datos de registro y las áreas de trabajo en Azure Monitor
4.2: Aislamiento de los sistemas que almacenan o procesan información confidencial
Guía : Implemente el aislamiento mediante suscripciones independientes y grupos de administración para
dominios de seguridad individuales, como el tipo de entorno y el nivel de confidencialidad de los datos. Puede
restringir el nivel de acceso a los recursos de Azure Monitor y los recursos relacionados que necesitan sus
aplicaciones y entornos empresariales. Puede regular el acceso a los recursos de Azure Monitor mediante el control
de acceso basado en roles de Azure Active Directory.
Creación de suscripciones adicionales de Azure
Creación de grupos de administración
4.4: Cifrado de toda la información confidencial en tránsito
Guía : De manera predeterminada, Azure Monitor negocia TLS 1.2. Asegúrese de que los clientes que se conectan a
los recursos de Azure pueden negociar TLS 1.2 o superior.
Application Insights y Log Analytics continúan permitiendo la ingesta de datos de TLS 1.1 y TLS 1.0. Los datos se
pueden restringir a TLS 1.2 mediante la configuración en el cliente.
Cómo enviar datos de forma segura mediante TLS 1.2
Responsabilidad : Compartido
4.5: Uso de una herramienta de detección activa para identificar datos confidenciales
Instrucciones : Las características de identificación, clasificación y prevención de pérdida de datos todavía no están
disponibles para Azure Monitor. Implemente una solución de terceros, si es necesario, para fines de cumplimiento.
En el caso de la plataforma subyacente administrada por Microsoft, Microsoft trata todo el contenido de los clientes
como confidencial y hace grandes esfuerzos para proteger a los clientes contra la pérdida y exposición de sus
datos. Para garantizar la seguridad de los datos de los clientes dentro de Azure, Microsoft ha implementado y
mantiene un conjunto de controles y funcionalidades eficaces de protección de datos.
Descripción de la protección de datos de los clientes en Azure
4.6: Uso del control de acceso basado en rol para controlar el acceso a los recursos
Guía : Utilice el control de acceso basado en roles (RBAC) de Azure para administrar el acceso a Azure Monitor.
Roles, permisos y seguridad en Azure Monitor
Configuración de Azure RBAC
4.8: Cifrado de información confidencial en reposo
Guía : Azure Monitor garantiza que todos los datos y las consultas guardadas se cifren en reposo mediante claves
administradas por Microsoft (MMK). Azure Monitor también proporciona una opción para el cifrado mediante su
propia clave almacenada en Azure Key Vault a la que se tiene acceso mediante la autenticación de la identidad
administrada asignada por el sistema. Esta clave administrada por el cliente (CMK) se puede proteger mediante
software o hardware (HSM).
Claves administradas por el cliente de Azure Monitor
Seguridad de datos de Log Analytics
Recopilación, retención y almacenamiento de datos en Application Insights
Descripción del cifrado en reposo en Azure
4.9: Registro y alerta de cambios en los recursos críticos de Azure
Guía : Utilice Azure Monitor con Azure Activity Log para crear alertas cuando se produzcan cambios en Azure
Monitor y los recursos relacionados.
Creación de alertas para los eventos del registro de actividad de Azure
Administración de vulnerabilidades
Para obtener más información, consulte Azure Security Benchmark: Administración de vulnerabilidades.
5.5: Use un proceso de clasificación de riesgos para priorizar la corrección de las vulnerabilidades detectadas
Instrucciones : Use un programa de puntuación de riesgos común (por ejemplo, Common Vulnerability Scoring
System) o la clasificación de riesgos predeterminada proporcionada por su herramienta de análisis de terceros.
Inventario y administración de recursos

Para obtener más información, consulte Azure Security Benchmark: Administración de recursos y del inventario.
6.1: Uso de la solución de detección de recursos automatizada
Guía : Utilice la CLI de Azure para consultar y detectar recursos de Azure Monitor en sus suscripciones. Asegúrese
de que tiene los permisos adecuados (lectura) en el inquilino y enumere todas las suscripciones de Azure, así como
los recursos de las suscripciones.
CLI de Azure Monitor
Visualización de las suscripciones de Azure
Descripción de Azure RBAC
6.2: Mantenimiento de metadatos de recursos
Guía : Aplique etiquetas a los recursos de Azure Monitor que proporcionan metadatos para organizarlos de forma
lógica en una taxonomía.
6.3: Eliminación de recursos de Azure no autorizados
Guía : Utilice el etiquetado, los grupos de administración y las suscripciones independientes, según corresponda,
para organizar y hacer un seguimiento de los recursos relacionados con Azure Monitor. Concilie el inventario
periódicamente y asegúrese de que los recursos no autorizados se eliminan de la suscripción de manera oportuna.
Creación de suscripciones adicionales de Azure
Creación de grupos de administración
6.4: Definición y mantenimiento de un inventario de los recursos de Azure aprobados
Guía : Cree un inventario de los recursos de Azure aprobados y el software aprobado para los recursos de proceso
según las necesidades de la organización.
6.5: Supervisión de recursos de Azure no aprobados
Guía : use Azure Policy para establecer restricciones sobre el tipo de recursos que se pueden crear en las
suscripciones.
Use Azure Resource Graph para consultar y detectar recursos dentro de sus suscripciones. Asegúrese de que todos
los recursos de Azure presentes en el entorno estén aprobados.
Configuración y administración de Azure Policy
Creación de consultas con Azure Resource Graph Explorer
6.7: Eliminación de aplicaciones de software y recursos de Azure no aprobadas
Guía : Concilie el inventario periódicamente y asegúrese de que los recursos no autorizados relacionados con Azure
Monitor se eliminen de la suscripción de manera oportuna.
Eliminación de un área de trabajo de Azure Log Analytics
6.9: Uso exclusivo de servicios de Azure aprobados
Guía : Utilice Azure Policy para restringir los recursos relacionados con Azure Monitor que se pueden aprovisionar
en su entorno.
Denegación de un tipo de recurso específico con Azure Policy
6.11: Limitación de la capacidad de los usuarios para interactuar con Azure Resource Manager
Instrucciones : Use el acceso condicional de Azure para limitar la capacidad de los usuarios de interactuar con
Azure Resource Manager mediante la configuración de la opción "Bloquear acceso" en la aplicación "Administración
de Microsoft Azure".
Configuración del acceso condicional para bloquear el acceso a Azure Resource Manager
Configuración segura
Para obtener más información, consulte Azure Security Benchmark: Configuración segura.
7.1: Establezca configuraciones seguras para todos los recursos de Azure
Guía : Utilice definiciones personalizadas de Azure Policy para auditar o aplicar la configuración de los recursos
relacionados con Azure Monitor. También puede usar definiciones integradas de Azure Policy.
Además, Azure Resource Manager tiene la capacidad de exportar la plantilla en notación de objetos JavaScript
(JSON), que se debe revisar para asegurarse de que las configuraciones cumplan o superen los requisitos de
seguridad de la organización.
También puede usar las recomendaciones de Azure Security Center como línea de base de configuración segura
para los recursos de Azure.
Si utiliza funcionalidades de APM de streaming en vivo, proteja el canal mediante una clave de API secreta, además
de la clave de instrumentación.
Protección de Live Metrics Stream de APM
Visualización de los alias de Azure Policy disponibles
Tutorial: Creación y administración de directivas para aplicar el cumplimiento
Exportación de uno y varios recursos a una plantilla en Azure Portal
Guía de referencia sobre las recomendaciones de seguridad
7.3: Mantenga configuraciones de recursos de Azure seguras
Guía : Utilice las directivas [deny] y [deploy if not exist] de Azure Policy para aplicar una configuración segura en los
recursos relacionados con Azure Monitor. Además, puede usar plantillas de Azure Resource Manager para mantener
la configuración de seguridad de los recursos relacionados con Azure Monitor que requiere su organización.
Descripción de los efectos de Azure Policy
Creación y administración de directivas para aplicar el cumplimiento
Información general sobre plantillas de Azure Resource Manager
7.5: Almacene de forma segura la configuración de los recursos de Azure
Guía : Use Azure DevOps para almacenar y administrar de forma segura el código, como directivas personalizadas
de Azure y plantillas de Azure Resource Manager. Para acceder a los recursos que administra en Azure DevOps,
puede conceder o denegar permisos a usuarios específicos, grupos de seguridad integrados o grupos definidos en
Azure Active Directory (Azure AD) si se integran con Azure DevOps, o Active Directory si se integran con TFS.
Almacenamiento de código en Azure DevOps
Acerca de los permisos y los grupos en Azure DevOps
7.7: Implementación de herramientas de administración de configuración para recursos de Azure
Guía : Defina e implemente configuraciones de seguridad estándar para los recursos relacionados con Azure
Monitor mediante Azure Policy. Utilice definiciones de Azure Policy personalizadas para auditar o aplicar la
configuración de seguridad de los recursos relacionados con Azure Monitor. También puede usar definiciones de
directivas integradas relacionadas con recursos concretos.
Alias de Azure Policy
7.9: Implementación de la supervisión de la configuración automatizada para los recursos de Azure
Guía : Utilice Azure Security Center para realizar análisis de base de referencia para los recursos relacionados con
Azure Monitor. Además, use Azure Policy para alertar y auditar las configuraciones de recursos de Azure.
Corrección de recomendaciones en Azure Security Center
7.11: Administre los secretos de Azure de forma segura
Guía : Utilice Managed Service Identity junto con Azure Key Vault para simplificar y proteger la administración de
secretos para los recursos relacionados admitidos de Azure Monitor.
Integración con identidades administradas de Azure
Servicios que admiten identidades administradas para recursos de Azure
Creación de un almacén de claves
Cómo proporcionar la autenticación de Key Vault con una identidad administrada
7.12: Administre las identidades de forma segura y automática
Guía : Use las identidades administradas para incorporar a los servicios de Azure una identidad administrada
automáticamente en Azure AD. Las identidades administradas le permiten autenticarse en cualquier servicio que
admita la autenticación de Azure AD, como los recursos de Azure Monitor, sin necesidad de utilizar credenciales en
el código.
Configuración de identidades administradas para recursos de Azure
7.13: Elimine la exposición de credenciales no intencionada
Instrucciones : Implemente el escáner de credenciales para identificar las credenciales en el código. El escáner de
credenciales también fomenta el traslado de credenciales detectadas a ubicaciones más seguras, como Azure Key
Vault.
Cómo configurar Credential Scanner
Defensa contra malware

Para obtener más información, consulte Azure Security Benchmark: defensa contra malware.
8.2: Examine previamente los archivos que se van a cargar en recursos de Azure que no son de proceso
Guía : Microsoft Antimalware está habilitado en el host subyacente que admite servicios de Azure (por ejemplo,
recursos relacionados con Azure Monitor), pero no se ejecuta en el contenido del usuario.
Haga un análisis previo de los archivos que se van a cargar en los recursos relacionados con Azure Monitor (por
ejemplo, el área de trabajo de Log Analytics).
Use la detección de amenazas de Azure Security Center para los servicios de datos para detectar malware cargado
en cuentas de almacenamiento.
Información sobre Microsoft Antimalware para Azure Cloud Services y Virtual Machines
Descripción de la detección de amenazas de Azure Security Center para servicios de datos
Recuperación de datos
Para más información, consulte Azure Security Benchmark: recuperación de datos.
9.1: Garantía de copias de seguridad automáticas periódicas
Guía : Utilice Azure Resource Manager para exportar los recursos relacionados con Azure Monitor en una plantilla
de notación de objetos JavaScript (JSON) que se puede usar como copia de seguridad para Azure Monitor y las
configuraciones relacionadas. Use Azure Automation para ejecutar automáticamente los scripts de copia de
seguridad.
Administración del área de trabajo de Log Analytics mediante las plantillas de Azure Resource Manager
Información sobre Azure Automation
9.2: Copias de seguridad completas del sistema y copia de seguridad de las claves administradas por el cliente
Guía : Utilice Azure Resource Manager para exportar los recursos relacionados con Azure Monitor en una plantilla
de notación de objetos JavaScript (JSON) que se puede usar como copia de seguridad para Azure Monitor y las
configuraciones relacionadas. Haga una copia de seguridad de las claves administradas por el cliente en Azure Key
Vault si los recursos relacionados con Azure Monitor usan claves administradas por el cliente.
Creación de una copia de seguridad de las claves del almacén de claves en Azure
9.3: Validación de todas las copias de seguridad, incluidas las claves administradas por el cliente
Guía : garantice la restauración periódica con copias de seguridad de los archivos de plantilla de Azure Resource
Manager. Pruebe la restauración de la copia de seguridad de las claves administradas por el cliente.
Restauración de las claves del almacén de claves en Azure
9.4: Garantía de la protección de las copias de seguridad y las claves administradas por el cliente
Guía : Use Azure DevOps para almacenar y administrar de forma segura el código, como directivas personalizadas
de Azure y plantillas de Azure Resource Manager. Para proteger los recursos que administra en Azure DevOps,
puede conceder o denegar permisos a usuarios específicos, grupos de seguridad integrados o grupos definidos en
Azure Active Directory (Azure AD) si se integran con Azure DevOps, o en Active Directory si se integran con TFS.
Use el control de acceso basado en roles para proteger las claves administradas por el cliente.
Además, habilite la eliminación temporal y la protección de purga en Key Vault para proteger las claves contra la
eliminación accidental o malintencionada. Si Azure Storage se usa para almacenar las plantillas de Azure Resource
Manager, habilite la eliminación temporal para guardar y recuperar los datos cuando se eliminen blobs o
instantáneas de blobs.
Almacenamiento de código en Azure DevOps
Acerca de los permisos y los grupos en Azure DevOps
Procedimiento para habilitar la eliminación temporal y la protección de purga en Key Vault
Eliminación temporal de blobs de Azure Storage
Respuesta a los incidentes

Para obtener más información, consulte Azure Security Benchmark: Respuesta a los incidentes.
10.1: Creación de una guía de respuesta ante incidentes
Instrucciones : Cree una guía de respuesta a incidentes para su organización. Asegúrese de que haya planes de
respuesta a incidentes escritos que definan todos los roles del personal, así como las fases de administración y
gestión de los incidentes, desde la detección hasta la revisión posterior a la incidencia.
Guía para crear su propio proceso de respuesta a incidentes de seguridad
Anatomía de un incidente del Centro de respuestas de seguridad de Microsoft
Uso de la guía de control de incidentes de seguridad de equipos de NIST para la creación de su propio plan
de respuesta a incidentes
10.2: Creación de un procedimiento de priorización y puntuación de incidentes
Instrucciones : Security Center asigna una gravedad a cada alerta para ayudarle a priorizar aquellas que se deben
investigar en primer lugar. La gravedad se basa en la confianza que tiene Security Center en la búsqueda o en el
análisis utilizados para emitir la alerta, así como en el nivel de confianza de que ha habido un intento
malintencionado detrás de la actividad que ha provocado la alerta.
Además, marque claramente las suscripciones (por ejemplo, producción, no producción) con etiquetas y cree un
sistema de nomenclatura para identificar y clasificar claramente los recursos de Azure, especialmente los que
procesan datos confidenciales. Es su responsabilidad asignar prioridades a la corrección de las alertas en función de
la importancia de los recursos y el entorno de Azure donde se produjo el incidente.
Alertas de seguridad en el Centro de seguridad de Azure
Uso de etiquetas para organizar los recursos de Azure
10.3: Prueba de los procedimientos de respuesta de seguridad
Guía : Realice ejercicios para probar las funcionalidades de respuesta a los incidentes de los sistemas
periódicamente para ayudar a proteger los recursos de Azure. Identifique puntos débiles y brechas y revise el plan
según sea necesario.
Publicación de NIST: Guía para probar, entrenar y ejecutar programas para planes y funcionalidades de TI
10.4: Provisión de detalles de contacto de incidentes de seguridad y configuración de notificaciones de alerta
para incidentes de seguridad
Instrucciones : La información de contacto del incidente de seguridad la utilizará Microsoft para ponerse en
contacto con usted si Microsoft Security Response Center (MSRC) detecta que un tercero no autorizado o ilegal ha
accedido a los datos. Revise los incidentes después del hecho para asegurarse de que se resuelven los problemas.
Establecimiento del contacto de seguridad de Azure Security Center
10.5: Incorporación de alertas de seguridad en el sistema de respuesta a incidentes
Guía : Exporte las alertas y recomendaciones de Azure Security Center y mediante la característica de exportación
continua para ayudar a identificar los riesgos para los recursos de Azure. La exportación continua le permite
exportar alertas y recomendaciones de forma manual o continua. Puede usar el conector de datos de Azure
Security Center para transmitir las alertas a Azure Sentinel.
Configuración de la exportación continua
Transmisión de alertas a Azure Sentinel
10.6: Automatización de la respuesta a las alertas de seguridad
Guía : Use la característica Automatización de flujo de trabajo de Azure Security Center para desencadenar
automáticamente las respuestas a través de Logic Apps en las alertas y recomendaciones de seguridad para
proteger los recursos de Azure.
Configuración de la automatización de flujo de trabajo y Logic Apps
Pruebas de penetración y ejercicios del equipo rojo

Para obtener más información, consulte Azure Security Benchmark: Pruebas de penetración y ejercicios del equipo
rojo.
11.1: Realice pruebas de penetración periódicas de los recursos de Azure y asegúrese de corregir todos los
resultados de seguridad críticos
Guía : Siga las reglas de compromiso de Microsoft para asegurarse de que las pruebas de penetración no infrinjan
las directivas de Microsoft. Use la estrategia de Microsoft y la ejecución de pruebas de penetración de sitios activos
y ataques simulados en la infraestructura en la nube, los servicios y las aplicaciones administrados por Microsoft.
Reglas de interacción de las pruebas de penetración
Equipo rojo de Microsoft Cloud
Pasos siguientes
Consulte la prueba comparativa de seguridad de Azure.
Obtenga más información sobre las líneas de base de seguridad de Azure.
Controles de cumplimiento normativo de Azure
Policy para Azure Monitor
Cumplimiento normativo de Azure Policy proporciona definiciones de iniciativas creadas y administradas por
Microsoft, conocidas como integraciones, para los dominios de cumplimiento y los controles de seguridad
relativos a distintos estándares de cumplimiento. En esta página se enumeran los dominios de cumplimiento y
los controles de seguridad para Azure Monitor. Para que los recursos de Azure sean compatibles con el estándar
específico, puede asignar las integraciones a un control de seguridad de manera individual.
El título de cada definición de directiva integrada se vincula a la definición de directiva en Azure Portal. Use el
vínculo de la columna Versión de directiva para ver el origen en el repositorio de GitHub de Azure Policy.
IMPORTANT
Cada control que se muestra a continuación está asociado a una o varias definiciones de Azure Policy. Estas directivas pueden
ayudarle a evaluar el cumplimiento mediante el control. Sin embargo, con frecuencia no hay una correspondencia completa o
exacta entre un control y una o varias directivas. Como tal, el cumplimiento con Azure Policy solo se refiere a las propias
directivas; esto no garantiza que sea totalmente compatible con todos los requisitos de un control. Además, el estándar de
cumplimiento incluye controles que no se abordan con las definiciones de Azure Policy en este momento. Por lo tanto, el
cumplimiento en Azure Policy es solo una vista parcial del estado general de cumplimiento. Las asociaciones entre los
controles y las definiciones de cumplimiento normativo de Azure Policy para estos estándares de cumplimiento pueden
cambiar con el tiempo.
Prueba comparativa de la seguridad de Azure

Azure Security Benchmark proporciona recomendaciones sobre cómo puede proteger las soluciones en la nube en
Azure. Para ver cómo se corresponde este servicio por completo a Azure Security Benchmark, consulte Archivos de
asignación de Azure Security Benchmark.
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: Azure Security
Benchmark.
VERSIÓ N DE L A
IDEN T IF IC A DO R DE DIREC T IVA DIREC T IVA
DO M A IN C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)
Registro y supervisión 2.2 Configuración de la El perfil de registro de 1.0.0

administración central Azure Monitor debe
de registros de recopilar los registros
seguridad de las categorías
"write", "delete" y
"action"
Registro y supervisión 2.2 Configuración de la Azure Monitor debe 1.0.0

administración central recopilar los registros
de registros de de actividad de todas
seguridad las regiones
VERSIÓ N DE L A
DO M A IN C O N T RO L T ÍT ULO DE C O N T RO L
Registro y supervisión 2.3 Habilitación del Auditar la 1.0.0

registro de auditoría configuración de
para recursos de diagnóstico
Azure
Registro y supervisión 2.3 Habilitación del Los registros de 3.0.0

registro de auditoría diagnóstico de Azure
para recursos de Data Lake Store
Azure deben estar
habilitados
Registro y supervisión 2.3 Habilitación del Se deben habilitar los 3.0.0

registro de auditoría registros de
para recursos de diagnóstico en Azure
Azure Stream Analytics
Registro y supervisión 2.3 Habilitación del Se deben habilitar los 3.0.0

registro de auditoría registros de
para recursos de diagnóstico en las
Azure cuentas de Batch

registro de auditoría diagnóstico de Data
para recursos de Lake Analytics deben
Azure estar habilitados

registro de auditoría diagnóstico del centro
para recursos de de eventos deben
Azure estar habilitados

registro de auditoría diagnóstico de IoT
para recursos de Hub deben estar
Azure habilitados

registro de auditoría diagnóstico en Key
para recursos de Vault deben estar
Azure habilitados

registro de auditoría diagnóstico de Logic
para recursos de Apps deben estar
Azure habilitados

registro de auditoría diagnóstico de los
para recursos de servicios de búsqueda
Azure deben estar
habilitados
VERSIÓ N DE L A

registro de auditoría diagnóstico en Service
para recursos de Bus deben estar
Azure habilitados
Protección de datos 4,9 Registro y alerta de Azure Monitor debe 1.0.0

cambios en los recopilar los registros
recursos críticos de de actividad de todas
Azure las regiones
CIS Microsoft Azure Foundations Benchmark

corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: CIS Microsoft
Azure Foundations Benchmark 1.1.0. Para más información sobre este estándar de cumplimiento, consulte CIS
Microsoft Azure Foundations Benchmark.
VERSIÓ N DE L A
Registro y supervisión 5.1.1 Asegúrese de que Las suscripciones a 1.0.0

existe un perfil de Azure deben tener un
registro. perfil de registro para
el registro de
actividad
Registro y supervisión 5.1.2 Asegúrese de que el El registro de 1.0.0

período de retención actividad debe
del registro de conservarse durante
actividad está al menos un año
establecido en
365 días o más.
Registro y supervisión 5.1.3 Asegúrese de que el El perfil de registro de 1.0.0

perfil de auditoría Azure Monitor debe
captura todas las recopilar los registros
actividades. de las categorías
"write", "delete" y
"action"
Registro y supervisión 5.1.4 Asegúrese de que el Azure Monitor debe 1.0.0

perfil de registro recopilar los registros
captura los registros de actividad de todas
de actividad de todas las regiones
las regiones, incluida
la global.
VERSIÓ N DE L A
Registro y supervisión 5.1.6 Asegúrese de que la La cuenta de 1.0.0

cuenta de almacenamiento que
almacenamiento que contiene el
contiene el contenedor con los
contenedor con los registros de actividad
registros de actividad debe estar cifrada con
está cifrada con BYOK BYOK
(use su propia clave).
Registro y supervisión 5.1.7 Asegúrese de que el Los registros de 3.0.0

registro de Azure diagnóstico en Key
KeyVault esté Vault deben estar
habilitado. habilitados
Registro y supervisión 5.2.1 Asegúrese de que Debe existir una alerta 2.0.0
existe una alerta de de registro de
registro de actividad actividad para las
para la creación de operaciones
una asignación de específicas de la
directiva. directiva
registro de actividad actividad para
para crear o actualizar operaciones
el grupo de seguridad administrativas
de red. específicas
para eliminar el grupo operaciones
de seguridad de red. administrativas
específicas
para la regla Crear o operaciones
actualizar grupo de administrativas
seguridad de red. específicas
para la regla Eliminar operaciones
grupo de seguridad administrativas
de red. específicas
para la solución de operaciones
seguridad de creación específicas de
o actualización. seguridad
VERSIÓ N DE L A
para la solución de operaciones
seguridad de específicas de
eliminación. seguridad
para la regla de operaciones
firewall Crear, administrativas
actualizar o eliminar específicas
SQL Server.
para la regla de operaciones
firewall Crear, administrativas
actualizar o eliminar específicas
SQL Server.
para la actualización operaciones
de la directiva de específicas de
seguridad. seguridad
HIPAA/HITRUST 9.2
Con el fin de revisar el modo en que las integraciones de Azure Policy disponibles para los servicios de Azure
siguen este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: HIPAA/HITRUST 9.2. Para
más información acerca de este estándar de cumplimiento, consulte HIPAA/HITRUST 9.2.
VERSIÓ N DE L A
Registro de auditoría 1202.09aa1System.1 Se crea un registro de Los registros de 3.0.0

- 09.aa auditoría seguro para diagnóstico de Azure
todas las actividades Data Lake Store
del sistema (crear, leer, deben estar
actualizar, eliminar) habilitados
que afecten a la
información cubierta.
VERSIÓ N DE L A
Registro de auditoría 1203.09aa1System.2 Los registros de Los registros de 3.0.0

- 09.aa auditoría incluyen el diagnóstico de Logic
identificador único de Apps deben estar
usuario, el habilitados
identificador único de
titular de los datos, la
función realizada y la
fecha y hora en que
se produjo el evento.
Registro de auditoría 1204.09aa1System.3 Las actividades de los Los registros de 2.0.0

- 09.aa usuarios con diagnóstico de IoT
privilegios Hub deben estar
(administradores, habilitados
operadores, etc.)
indican el éxito o el
fracaso del evento, la
hora en que se
produjo el evento, la
cuenta afectada, los
procesos implicados e
información adicional
sobre el evento.
Registro de auditoría 1205.09aa2System.1 Los registros de Se deben habilitar los 3.0.0

- 09.aa mensajes enviados y registros de
recibidos se diagnóstico en las
conservan, incluidos cuentas de Batch
la fecha, la hora, el
origen y el destino del
mensaje, pero sin el
contenido.
Registro de auditoría 1207.09aa2System.4 Los registros de Se deben habilitar los 3.0.0

- 09.aa auditoría se registros de
conservan durante diagnóstico en Azure
90 días y los más Stream Analytics
antiguos se
almacenan durante
un año.

- 09.aa auditoría se diagnóstico del centro
conservan durante de eventos deben
90 días y los más estar habilitados
antiguos se
almacenan durante
un año.
VERSIÓ N DE L A

- 09.aa auditoría se diagnóstico de los
mantienen para las servicios de búsqueda
actividades de deben estar
administración, inicio, habilitados
apagado o errores del
sistema y de
aplicaciones, cambios
en archivos y cambios
en la directiva de
seguridad.

- 09.aa auditoría se diagnóstico en Service
mantienen para las Bus deben estar
actividades de habilitados
administración, inicio,
apagado o errores del
sistema y de
aplicaciones, cambios
en archivos y cambios
en la directiva de
seguridad.
Registro de auditoría 1210.09aa3System.3 Cualquier divulgación Auditar la 1.0.0

- 09.aa de información que se configuración de
produzca dentro o diagnóstico
fuera de la
organización queda
registrada (por
ejemplo, el tipo de
divulgación, la fecha y
la hora del evento, el
destinatario y el
remitente).
Registro de auditoría 1210.09aa3System.3 Cualquier divulgación Los registros de 3.0.0

- 09.aa de información que se diagnóstico de Data
produzca dentro o Lake Analytics deben
fuera de la estar habilitados
organización queda
registrada (por
ejemplo, el tipo de
divulgación, la fecha y
la hora del evento, el
destinatario y el
remitente).
Registro de auditoría 1211.09aa3System.4 La organización Los registros de 3.0.0

- 09.aa comprueba cada diagnóstico en Key
90 días si los datos de Vault deben estar
cada extracto de habilitados
información cubierta
registrada se han
borrado o siguen
siendo necesarios.
VERSIÓ N DE L A
Supervisión del uso 1120.09ab3System.9 Las conexiones Azure Monitor debe 1.0.0
del sistema - 09.ab remotas sin recopilar los registros
autorización para de actividad de todas
acceder a los sistemas las regiones
de información se
supervisan y se
revisan al menos
trimestralmente y se
adoptan las medidas
adecuadas si se
detecta una conexión
no autorizada.
Supervisión del uso 1212.09ab1System.1 Se cumplen todos los El perfil de registro de 1.0.0
del sistema - 09.ab requisitos legales en Azure Monitor debe
relación con la recopilar los registros
supervisión de los de las categorías
intentos de acceso "write", "delete" y
autorizado y no "action"
autorizado.
Supervisión del uso 1214.09ab2System.3 La supervisión incluye Azure Monitor debe 1.0.0
del sistema 456 - 09.ab operaciones con recopilar los registros
privilegios, los de actividad de todas
intentos de acceso las regiones
autorizado y no
autorizado, incluidos
los intentos de acceso
a cuentas
desactivadas y las
alertas o errores del
sistema.
Supervisión del uso 1219.09ab3System.1 El sistema de El perfil de registro de 1.0.0

del sistema 0 - 09.ab información puede Azure Monitor debe
procesar recopilar los registros
automáticamente de las categorías
registros de auditoría "write", "delete" y
para eventos de "action"
interés en función de
criterios para
seleccionar.
Registros de 1270.09ad1System.1 La organización Debe existir una alerta 1.0.0

administrador y 2 - 09.ad garantiza que el de registro de
operador registro correcto está actividad para
habilitado para operaciones
auditar las actividades administrativas
del administrador; y específicas
revisa los registros de
operador y
administrador del
sistema de forma
periódica.
VERSIÓ N DE L A
Registros de 1271.09ad1System.1 Se utiliza un sistema Debe existir una alerta 1.0.0

administrador y - 09.ad de detección de de registro de
operador intrusiones actividad para
administrado sin la operaciones
supervisión de administrativas
administradores del específicas
sistema y de red para
supervisar el
cumplimiento de las
actividades de
administración del
sistema y de la red.
Controles de red 0860.09m1Organizati La organización Implementar la 1.0.0

onal.9 - 09.m administra configuración de
formalmente los diagnóstico para
equipos de la red, grupos de seguridad
incluidos los equipos de red
de las áreas de
usuario.
NIST SP 800-171 R2
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: NIST SP 800-
171 R2. Para más información acerca de este estándar normativo, consulte NIST SP 800-171 R2.
VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)
Auditoría y 3.3.1 Crea y conserva Auditar la 1.0.0

responsabilidad registros y registros configuración de
de auditoría del diagnóstico
sistema en la medida
necesaria para
habilitar la
supervisión, el
análisis, la
investigación y la
generación de
informes de actividad
del sistema ilegal o no
autorizada.
Auditoría y 3.3.2 Garantiza que solo se Auditar la 1.0.0

responsabilidad pueda realizar el configuración de
seguimiento de las diagnóstico
acciones de usuarios
individuales del
sistema hasta esos
usuarios, de modo
que se les pueda
responsabilizar de sus
acciones.
VERSIÓ N DE L A
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L
Auditoría y 3.3.4 Alerta en caso de Auditar la 1.0.0

responsabilidad error en el proceso de configuración de
registro de auditoría. diagnóstico
NIST SP 800-53 R4
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: NIST SP 800-53
R4. Para más información acerca de este estándar normativo, consulte NIST SP 800-53 R4.
VERSIÓ N DE L A
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)
Auditoría y AU-5 Respuesta a errores Auditar la 1.0.0

responsabilidad de procesamiento de configuración de
auditoría diagnóstico
Auditoría y AU-12 Generación de Auditar la 1.0.0

responsabilidad auditoría configuración de
diagnóstico
Pasos siguientes
Obtenga más información sobre el cumplimiento normativo de Azure Policy.
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure Policy.
Supervisión de recursos de Azure con Azure Monitor
Si tiene aplicaciones y procesos empresariales críticos que dependen de recursos de Azure, querrá supervisar esos
recursos para su disponibilidad, rendimiento y funcionamiento. En este artículo se describen los datos de
supervisión generados por los recursos de Azure y cómo puede usar las características de Azure Monitor para
analizar y alertar sobre estos datos.
IMPORTANT
Este artículo se aplica a todos los servicios de Azure que usan Azure Monitor. Los recursos de proceso, incluidas las
máquinas virtuales y App Service, generan los mismos datos de supervisión que se describen aquí, pero también tienen un
sistema operativo invitado que puede generar asimismo registros y métricas. Consulte la documentación de supervisión de
estos servicios para más información sobre cómo recopilar y analizar estos datos.

Azure Monitor es un servicio de supervisión de pila completo de Azure, que proporciona un conjunto completo de
características para supervisar los recursos de Azure, además de los recursos locales y en otras nubes. La
Plataforma de datos de Azure Monitor recopila datos en registros y métricas, donde se pueden analizar
conjuntamente con un conjunto completo de herramientas de supervisión, tal como se describe en las secciones
siguientes.
¿Qué puede hacer con las métricas de Azure Monitor?
¿Qué puede hacer con los registros de Azure Monitor?
Al crear un recurso de Azure, se habilita Azure Monitor, y se inicia la recopilación de métricas y registros de
actividad que puede ver y analizar en Azure Portal. Con algunas opciones de configuración, puede recopilar datos
de supervisión adicionales y habilitar características adicionales. Consulte Supervisión de datos a continuación
para más información sobre los requisitos de configuración.
Costos asociados con la supervisión

El análisis de los datos de supervisión que se recopilan de forma predeterminada no supone ningún costo. Incluye
lo siguiente:
Recopilación de métricas de la plataforma y su análisis con el Explorador de métricas.
Recopilación del registro de actividad y su análisis en Azure Portal.
Creación de una regla de alerta de registro de actividad.
No hay ningún costo de Azure Monitor para recopilar y exportar registros y métricas, pero puede haber costos
relacionados asociados con el destino:
Costos asociados con la ingesta de datos y la retención al recopilar registros y métricas en el área de trabajo de
Log Analytics. Consulte Precios de Azure Monitor para Log Analytics.
Costos asociados con el almacenamiento de datos al recopilar registros y métricas en una cuenta de
almacenamiento de Azure. Consulte Precios de Azure Storage para Blob Storage.
Costos asociados con el streaming de Event Hubs al reenviar registros y métricas a Azure Event Hubs. Consulte
Precios de Azure Event Hubs.
Puede haber costos de Azure Monitor asociados con lo siguiente. Consulte Precios de Azure Monitor:
Ejecución de una consulta de registro.
Creación de una regla de alerta de consulta de registro o métrica.
Envío de una notificación desde cualquier regla de alerta.
Acceso a las métricas mediante API.
Los recursos de Azure generan registros y métricas que aparecen en el diagrama siguiente. Consulte la
documentación de cada uno de los servicios de Azure para ver los datos específicos que generan y cualquier
solución o información que proporcionen.
Métricas de plataforma: valores numéricos que se recopilan automáticamente a intervalos regulares y

describen algún aspecto de un recurso en un momento determinado.
Registros de recurso: proporcionan información de las operaciones realizadas dentro del mismo recurso de
Azure (en el plano de datos), por ejemplo, obtención de un secreto de un almacén de claves o realización de
una solicitud a una base de datos. El contenido y la estructura de estos registros de recurso varían según el
servicio de Azure y el tipo de recurso.
Registro de actividad: proporciona información general de las operaciones de cada recurso de Azure de la
suscripción desde fuera (en el plano de administración), por ejemplo, creación de un nuevo recurso o inicio de
una máquina virtual. Esta información es sobre los interrogantes qué, quién y cuándo para las operaciones de
escritura (PUT, POST, DELETE) en los recursos de la suscripción.
Requisitos de configuración
Configuración de la supervisión
Algunos datos de supervisión se recopilan automáticamente, pero es posible que tenga que configurar algunos
valores en función de sus requisitos. Consulte la información siguiente y vea la información específica para cada
tipo de datos de supervisión.
Métricas de plataforma: las métricas de plataforma se recopilan automáticamente en Métricas en Azure
Monitor sin necesidad de configuración. Cree una configuración de diagnóstico para enviar entradas a
registros de Azure Monitor o reenviarlas fuera de Azure.
Registros de recurso: los recursos de Azure generan automáticamente registros de recurso, pero estos no se
recopilan sin una configuración de diagnóstico. Cree una configuración de diagnóstico para enviar entradas a
registros de Azure Monitor o reenviarlas fuera de Azure.
Registro de actividad: el registro de actividad se recopila automáticamente sin necesidad de configuración y
puede verse en Azure Portal. Cree una configuración de diagnóstico para copiarla en registros de Azure
Monitor o reenviarla fuera de Azure.
Área de trabajo de Log Analytics
La recopilación de datos en los registros de Azure Monitor requiere un área de trabajo de Log Analytics. Puede
empezar a supervisar rápidamente el servicio creando una nueva área de trabajo, pero también puede resultar
útil usar un área de trabajo que recopila datos de otros servicios. Consulte Creación de un área de trabajo de Log
Analytics en Azure Portal, para conocer más detalles sobre cómo crear un área de trabajo, y Diseño de la
implementación de registros de Azure Monitor, como ayuda para determinar el mejor diseño de área de trabajo
para sus requisitos. Si usa un área de trabajo existente en la organización, necesitará los permisos adecuados, tal
como se describe en Administración del acceso a los datos de registro y las áreas de trabajo en Azure Monitor.
La configuración de diagnóstico define dónde se deben enviar los registros de recurso y las métricas para un
recurso determinado. Los posibles destinos son:
Área de trabajo de Log Analytics, que permite analizar datos con otros datos de supervisión recopilados por
Azure Monitor mediante unas consultas de registro eficaces y también aprovechar otras características de
Azure Monitor, como alertas de registros y visualizaciones.
Event Hubs, para transmitir datos a sistemas externos, como SIEM de terceros y otras soluciones de análisis de
registros.
Cuenta de almacenamiento de Azure, que resulta útil para la auditoría, el análisis estático o la copia de
seguridad.
Siga el procedimiento de Creación de una configuración de diagnóstico para recopilar registros de plataforma y
métricas en Azure para crear y administrar la configuración de diagnóstico mediante Azure Portal. Consulte
Creación de la configuración de diagnóstico en Azure con una plantilla de Resource Manager para definirla en una
plantilla y habilitar la supervisión completa para un recurso cuando se crea.
Supervisión en Azure Portal

Puede acceder a los datos de supervisión para la mayoría de los recursos de Azure en el menú del recurso en
Azure Portal. Esto le proporcionará acceso a los datos de un solo recurso con las herramientas de Azure Monitor
estándar. Algunos servicios de Azure proporcionarán opciones diferentes, por lo que debe consultar la
documentación de ese servicio para obtener información adicional. Use el menú Azure Monitor para analizar los
datos de todos los recursos supervisados.
Muchos servicios incluirán datos de supervisión en su página Información general para una vista rápida de su
funcionamiento. Esto se basará, normalmente, en un subconjunto de métricas de plataforma almacenadas en
Métricas de Azure Monitor. En general, habrá otras opciones de supervisión disponibles en una sección
Super visión del menú de servicio.
Insights y soluciones
Algunos servicios proporcionarán herramientas más allá de las características estándar de Azure Monitor. Insights
proporciona una experiencia de supervisión personalizada basada en la plataforma de datos de Azure Monitor y
las características estándar. Las soluciones proporcionan lógica de supervisión predefinida basada en los registros
de Azure Monitor.
Si un servicio tiene una conclusión de Azure Monitor, puede acceder a ella desde la opción Super visión en el
menú de cada recurso. Puede acceder a todas las conclusiones y las soluciones desde el menú de Azure Monitor .
Métricas
Analice las métricas en Azure Portal mediante el explorador de métricas, que está disponible en el elemento de
menú Métricas de la mayoría de los servicios. Esta herramienta permite trabajar con métricas individuales o
combinar varias para identificar correlaciones y tendencias.
Consulte Introducción al Explorador de métricas de Azure para más información sobre el Explorador de
métricas.
Consulte Características avanzadas del Explorador de métricas de Azure para ver características avanzadas del
Explorador de métricas, como el uso de varias métricas, y la aplicación de filtros y división.
Registro de actividades
Vea las entradas del registro de actividad en Azure Portal con el filtro inicial establecido en el recurso actual. Copie
el registro de actividad en un área de trabajo de Log Analytics para acceder a él, y usarlo en consultas y libros de
registro.
Consulte Visualización y recuperación de eventos del registro de actividad de Azure para más información
sobre la visualización del registro de actividad y la recuperación de entradas mediante varios métodos.
Consulte la documentación del servicio de Azure para conocer los eventos específicos que se registran.
Los registros de Azure Monitor consolidan los registros y las métricas de varios servicios, y otros orígenes de
datos para su análisis con una herramienta de consulta eficaz. Como se ha descrito anteriormente, cree una
configuración de diagnóstico para recopilar métricas de la plataforma, el registro de actividad y los registros de
recursos en un área de trabajo de Log Analytics en Azure Monitor.
Log Analytics le permite trabajar con las consultas de registros, que es una característica eficaz de Azure Monitor
que ayuda a realizar un análisis avanzado de los datos de registro mediante un lenguaje de consulta muy
completo. Abra Log Analytics en Registros en el menú Super visión para que un recurso de Azure funcione con
las consultas de registro que usan el recurso como ámbito de consulta. Esto le permite analizar datos en varias
tablas solo para ese recurso. Use Registros en el menú de Azure Monitor para acceder a los registros de todos
los recursos.
Consulte Introducción a las consultas de registro en Azure Monitor para ver un tutorial sobre el uso del
lenguaje de consulta que se utiliza para escribir consultas de registro.
Consulte Recopilación de registros de recurso de Azure en el área de trabajo de Log Analytics en Azure
Monitor para información sobre cómo se recopilan los registros de recurso en los registros de Azure Monitor y
detalles sobre cómo obtener acceso a ellos en una consulta.
Consulte Modo de recopilación para ver una explicación de cómo se estructuran los datos del registro de
recursos en los registros de Azure Monitor.
Consulte la documentación de cada servicio de Azure para más información sobre su tabla en los registros de
Azure Monitor.
Supervisión desde la línea de comandos

Puede acceder a los datos de supervisión recopilados en el recurso desde una línea de comandos o incluirlos en
un script mediante Azure PowerShell o la interfaz de la línea de comandos de Azure.
Consulte la referencia de métricas de la CLI para acceder a los datos de métricas de la CLI.
Consulte la referencia de Log Analytics de la CLI para acceder a los datos de los registros de Azure Monitor
mediante una consulta de registro desde la CLI.
Consulte la referencia de métricas de Azure PowerShell para acceder a los datos de métricas desde Azure
PowerShell.
Consulte la referencia de consulta de registro de Azure PowerShell para acceder a los datos de los registros de
Azure Monitor mediante una consulta de registro desde Azure PowerShell.
Supervisión desde una API REST
Incluya datos de supervisión recopilados desde el recurso en una aplicación personalizada mediante una API REST.
Consulte Tutorial sobre la API REST de supervisión de Azure para más información sobre el acceso a las
métricas desde la API REST de Azure Monitor.
Consulte el artículo sobre la API REST de Azure Log Analytics para obtener información sobre cómo acceder a
los datos de los registros de Azure Monitor mediante una consulta de registro desde Azure PowerShell.
Alertas
Las alertas le informan de forma proactiva y pueden tomar medidas cuando se detectan condiciones importantes
en los datos que supervisa. Cree una regla de alerta que defina un destino para la alerta, las condiciones para la
creación de una alerta y las acciones que se deben realizar en respuesta.
Se usan diferentes tipos de datos de supervisión para distintos tipos de reglas de alerta.
Alerta de registro de actividad: cree una alerta al crear una entrada en el registro de actividad que coincida con
criterios específicos. Esto le permite recibir una notificación, por ejemplo, cuando se crea un tipo determinado
de recurso o si se produce un error en un cambio de configuración.
Alerta de métrica: cree una alerta cuando un valor de métrica supere un umbral determinado. Las alertas de
métricas tienen más capacidad de respuesta que otras alertas y se pueden resolver automáticamente cuando
se corrige el problema.
Alerta de consulta de registro: ejecute una consulta de registro a intervalos regulares y cree una alerta si se
encuentra una condición determinada. Esto le permite realizar análisis complejos en varios conjuntos de datos.
Use Aler tas en el menú de un recurso para ver alertas y administrar las reglas de alerta para ese recurso. Solo las
alertas del registro de actividad y las alertas de métricas utilizan recursos individuales de Azure como destino. Las
alertas de consulta de registro usan un área de trabajo de Log Analytics como destino y se basan en una consulta
que puede acceder a los registros almacenados en esa área de trabajo. Use el menú de Azure Monitor para ver y
administrar las alertas de todos los recursos, y administrar las reglas de alerta de consultas de registro.
Consulte los artículos de los diferentes tipos de alerta anteriores para más información sobre la creación de
reglas de alerta.
Consulte Creación y administración de grupos de acciones en Azure Portal para más información sobre cómo
crear un grupo de acciones que le permita administrar las respuestas a las alertas.
Pasos siguientes
Consulte Servicios, esquemas y categorías admitidos en los registros de recursos de Azure para más
información sobre los registros de recursos para los distintos servicios de Azure.
Supervisión de máquinas virtuales de Azure con
Azure Monitor
En este artículo se describe cómo usar Azure Monitor para recopilar y analizar datos de supervisión de máquinas
virtuales de Azure para mantener su estado. Las máquinas virtuales se pueden supervisar en términos de
disponibilidad y rendimiento con Azure Monitor como cualquier otro recurso de Azure, pero se diferencian de
otros recursos en cuanto que también debe supervisar el sistema operativo invitado y las cargas de trabajo que se
ejecutan en él.
NOTE
En este artículo se proporciona información general completa de los conceptos y las opciones para la supervisión de
máquinas virtuales en Azure Monitor. Para empezar a supervisar rápidamente las máquinas virtuales sin centrarse en los
conceptos subyacentes, consulte Inicio rápido: Supervisión de máquinas virtuales de Azure con Azure Monitor.
Diferencias con respecto a otros recursos de Azure

En Supervisión de recursos de Azure con Azure Monitor se describen los datos de supervisión generados por los
recursos de Azure y cómo puede usar las características de Azure Monitor para analizar y alertar sobre estos
datos. Puede recopilar los mismos datos de supervisión de máquinas virtuales de Azure y actuar en ellos con las
diferencias siguientes:
Las métricas de plataforma se recopilan automáticamente para las máquinas virtuales, pero solo para la
máquina virtual anfitriona. Necesita un agente para recopilar los datos de rendimiento del sistema operativo
invitado.
Las máquinas virtuales no generan registros de recursos que proporcionen información sobre las operaciones
que se realizaron en un recurso de Azure. Se usa un agente para recopilar los datos de registro del sistema
operativo invitado.
Puede crear una configuración de diagnóstico para que una máquina virtual envíe métricas de plataforma a
otros destinos, como centros de eventos y de almacenamiento, pero no puede establecer esta configuración de
diagnóstico en Azure Portal.
Las máquinas virtuales de Azure generan registros y métricas, como se muestra en el diagrama siguiente.
Máquina virtual anfitriona
Las máquinas virtuales de Azure generan los datos siguientes para la máquina virtual anfitriona igual que otros
recursos de Azure, tal como se describe en Supervisión de datos.
Métricas de plataforma: valores numéricos que se recopilan automáticamente a intervalos regulares y
describen algún aspecto de un recurso en un momento determinado. Las métricas de la plataforma se
recopilan para la máquina virtual anfitriona, pero necesita la extensión de diagnóstico para recopilar métricas
del sistema operativo invitado.
Registro de actividad: proporciona una visión general de las operaciones de cada recurso de Azure de la
suscripción desde fuera (en el plano de administración). En el caso de una máquina virtual, esto incluye
información como cuándo se inició y cualquier cambio en la configuración.
Sistema operativo invitado
Para recopilar datos del sistema operativo invitado de una máquina virtual, necesita un agente, que se ejecuta
localmente en cada máquina virtual y envía datos a Azure Monitor. Hay varios agentes disponibles para Azure
Monitor, y cada uno de ellos recopila datos diferentes y escribe datos en ubicaciones diferentes. Consulte
Introducción a los agentes de Azure Monitor para ver una comparativa detallada de los diferentes agentes.
Agente de Log Analytics: disponible para máquinas virtuales de Azure, otros entornos de nube y el entorno
local. Recopila datos en los registros de Azure Monitor. Admite soluciones de Azure Monitor para VM y
supervisión. Este es el mismo agente que se usa para System Center Operations Manager.
Dependency Agent: recopila datos acerca de los procesos que se ejecutan en la máquina virtual y sus
dependencias. Se basa en el agente de Log Analytics para transmitir datos a Azure y admite Azure Monitor
para VM, Service Map y soluciones de Wire Data 2.0.
Extensión de diagnóstico de Azure: disponible solo para máquinas virtuales Azure Monitor. Puede recopilar
datos en varias ubicaciones, pero se usa principalmente para recopilar datos de rendimiento del invitado en
métricas de Azure Monitor para máquinas virtuales Windows.
Agente de Telegraf: recopila datos de rendimiento de máquinas virtuales Linux en métricas de Azure Monitor.
Requisitos de configuración
Para habilitar todas las características de Azure Monitor para la supervisión de una máquina virtual, debe
recopilar datos de supervisión desde la máquina virtual anfitriona y el sistema operativo invitado tanto en
métricas de Azure Monitor como en registros de Azure Monitor. En la tabla siguiente se muestra la configuración
que se debe aplicar para habilitar esta colección. Puede optar por no implementar todos estos pasos, en función
de sus requisitos particulares.
PA SO DE C O N F IGURA C IÓ N A C C IO N ES C O M P L ETA DA S C A RA C T ERÍST IC A S H A B IL ITA DA S
Sin configuración - Recopilación de las métricas de la - Explorador de métricas para el

plataforma en métricas de Azure anfitrión.
Monitor. - Alertas de métricas para el anfitrión.
- Recopilación del registro de actividad. - Alertas de registros de actividad.
Habilitar Azure Monitor para VM - Instalación del agente de Log - Gráficos y libros de rendimiento para
Analytics. los datos de rendimiento del invitado.
- Instalación de Dependency Agent. - Consultas de registro para los datos
- Recopilación de datos de rendimiento de rendimiento del invitado.
del invitado en registros de Azure - Alertas de registro para los datos de
Monitor. rendimiento del invitado.
- Recopilación de detalles de proceso y - Mapa de dependencias.
dependencia en registros de Azure
Monitor.
Instalación de la extensión de - Recopilación de datos de rendimiento - Explorador de métricas para el

diagnósticos y el agente de Telegraf del invitado en métricas de Azure invitado.
Monitor. - Alertas de métricas para el invitado.
Configuración de un área de trabajo de - Recopilación de eventos del invitado. - Consultas de registro para eventos
Log Analytics del invitado.
- Alertas de registro para eventos del
invitado.
Creación de la configuración de - Recopilación de métricas de la - Consultas de registros para métricas

diagnóstico de la máquina virtual plataforma en registros de Azure del anfitrión.
Monitor. - Alertas de registros para métricas del
- Recopilación del registro de actividad anfitrión.
en registros de Azure Monitor. - Consultas de registros para el registro
de actividades.
En las secciones siguientes se describen todos estos pasos de configuración.

Azure Monitor para VM es un punto de información en Azure Monitor que sirve de herramienta principal para
supervisar máquinas virtuales en Azure Monitor. Proporciona el siguiente valor adicional con respecto a las
características de Azure Monitor estándar.
Incorporación simplificada del agente de Log Analytics y de Dependency Agent para habilitar la supervisión de
un sistema operativo invitado y las cargas de trabajo de una máquina virtual.
Libros y gráficas de rendimiento de tendencias predefinidos que permiten analizar las métricas de rendimiento
básicas del sistema operativo invitado de la máquina virtual.
Mapa de dependencias que muestra los procesos que se ejecutan en cada máquina virtual y los componentes
interconectados con otras máquinas y orígenes externos.
Habilite Azure Monitor para VM en la opción Información del menú de la máquina virtual de Azure Portal. Vea
Información general sobre la habilitación de Azure Monitor para VM para obtener más información y conocer
otros métodos de configuración.
Configuración de un área de trabajo de Log Analytics
El agente de Log Analytics utilizado por Azure Monitor para VM envía datos al área de trabajo de Log Analytics.
Puede habilitar la recopilación de datos de rendimiento, eventos y otros datos de supervisión adicionales del
agente mediante la configuración del área de trabajo de Log Analytics. Solo debe configurarse una vez, ya que
cualquier agente que se conecte al área de trabajo descargará automáticamente la configuración y comenzará
inmediatamente a recopilar los datos definidos.
Puede tener acceso a la configuración del área de trabajo directamente desde Azure Monitor para VM
seleccionando Configuración del área de trabajo en Introducción . Haga clic en el nombre del área de trabajo
para abrir su menú.
Seleccione Configuración avanzada en el menú del área de trabajo y luego Datos para configurar los orígenes
de datos. En el caso de los agentes de Windows, seleccione Registros de eventos de Windows y agregue
registros de eventos comunes como Sistema y Aplicación. En el caso de los agentes de Linux, seleccione Syslog y
agregue instalaciones comunes como Kern y demonio. Consulte Orígenes de datos de agente en Azure Monitor
para obtener una lista de orígenes de datos disponibles e información sobre su configuración.
NOTE
Puede configurar los contadores de rendimiento que se van a recopilar de la configuración del área de trabajo, pero esto
puede ser redundante con los contadores de rendimiento recopilados por Azure Monitor para VM. Azure Monitor para VM
recopila el conjunto más común de contadores a una frecuencia de una vez por minuto. Configure solo los contadores de
rendimiento que se van a recopilar por el área de trabajo si desea recopilar los contadores que no se han recopilado ya por
Azure Monitor para VM o si tiene consultas existentes que usan datos de rendimiento.
Habilitación de la extensión de diagnósticos y el agente de Telegraf

Azure Monitor para VM se basa en el agente de Log Analytics que recopila datos en un área de trabajo de Log
Analytics. Esto admite varias características de Azure Monitor como las consultas de registro, las alertas de
registro y los libros. La extensión de diagnósticos recopila los datos de rendimiento del sistema operativo invitado
de las máquinas virtuales de Windows en Azure Storage y, opcionalmente, envía datos de rendimiento a las
métricas Azure Monitor. En el caso de las máquinas virtuales Linux, se necesita el agente de Telegraf para enviar
datos a las métricas de Azure. Esto habilita otras características de Azure Monitor, como el explorador de métricas y
las alertas de métricas. También puede configurar la extensión de diagnósticos para enviar eventos y datos de
rendimiento fuera de Azure Monitor mediante Azure Event Hubs.
Instale la extensión de diagnósticos para una sola máquina virtual Windows en Azure Portal desde la opción
Configuración de diagnóstico del menú de la máquina virtual. Seleccione la opción para habilitar Azure
Monitor en la pestaña Receptores . Para habilitar la extensión desde una plantilla o línea de comandos para
varias máquinas virtuales, consulte Instalación y configuración. A diferencia del agente de Log Analytics, los datos
que se van a recopilar se definen en la configuración de la extensión en cada máquina virtual.
Consulte Instalación y configuración de Telegraf para obtener más información sobre la configuración de los
agentes de Telegraf en máquinas virtuales Linux. La opción de menú Configuración de diagnóstico está
disponible para Linux, pero solo le permitirá enviar datos a Azure Storage.
Recopilación de métricas de plataforma y registro de actividad
Puede ver las métricas de la plataforma y el registro de actividad recopilados para cada máquina virtual anfitriona
en Azure Portal. Recopile estos datos en la misma área de trabajo de Log Analytics que Azure Monitor para VM
para analizarlos con los demás datos de supervisión recopilados para la máquina virtual. Esta colección se
establece con una configuración de diagnóstico. Recopile el registro de actividad con una configuración de
diagnóstico para la suscripción.
Recopile las métricas de la plataforma con una configuración de diagnóstico para la máquina virtual. A diferencia
de otros recursos de Azure, no puede crear una configuración de diagnóstico para una máquina virtual en Azure
Portal, sino que debe usar otro método. En los siguientes ejemplos se muestra cómo recopilar métricas para una
máquina virtual mediante PowerShell y la CLI.
Set-AzDiagnosticSetting -Name vm-diagnostics -ResourceId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-

xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.Compute/virtualMachines/my-vm" -Enabled
$true -MetricCategory AllMetrics -workspaceId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-
workspace"
az monitor diagnostic-settings create \

--name VM-Diagnostics
--resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-
group/providers/Microsoft.Compute/virtualMachines/my-vm \
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/my-resource-
group/providers/microsoft.operationalinsights/workspaces/my-workspace
Supervisión en Azure Portal

Una vez configurada la recopilación de los datos de supervisión para una máquina virtual, tiene varias opciones
para tener acceso a ella en Azure Portal:
Use el menú Azure Monitor para acceder a los datos de todos los recursos supervisados.
Use Azure Monitor para VM para supervisar conjuntos de máquinas virtuales a escala.
Analice los datos de una sola máquina virtual desde su menú en Azure Portal. En la tabla siguiente se
enumeran las diferentes opciones para supervisar el menú de máquinas virtuales.
O P C IÓ N DE M EN Ú DESC RIP C IÓ N
Información general Muestra las métricas de plataforma para la máquina virtual

anfitriona. Haga clic en un gráfico para trabajar con estos
datos en el explorador de métricas.
Registro de actividades Entradas del registro de actividad filtradas para la máquina

virtual actual.
Información detallada Abra Azure Monitor para VM con la asignación de la máquina

virtual actual seleccionada.
Alertas Vea las alertas para la máquina virtual actual.
Métricas Abra el explorador de métricas con el ámbito establecido en la

máquina virtual actual.
Configuración de diagnóstico Habilite y configure la extensión de diagnóstico para la

máquina virtual actual.
Recomendaciones de Advisor Recomendaciones para la máquina virtual actual desde Azure

Advisor.
Registros Abra Log Analytics con el ámbito establecido en la máquina

virtual actual.
Monitor de conexión Abra la supervisión de conexiones de Network Watcher para

supervisar las conexiones entre la máquina virtual actual y
otras máquinas virtuales.
Analizar datos de métricas

Puede analizar las métricas de las máquinas virtuales mediante el explorador de métricas abriendo Métricas en
el menú de la máquina virtual. Consulte Introducción al explorador de métricas de Azure para más información
sobre esta herramienta.
Hay tres espacios de nombres usados por las máquinas virtuales para las métricas:
ESPA C IO DE N O M B RES DESC RIP C IÓ N REQ UISITO
Máquina virtual anfitriona Métricas de la anfitriona recopiladas Se recopilan automáticamente sin

automáticamente para todas las necesidad de configuración.
máquinas virtuales de Azure. La lista
detallada de métricas en se encuentra
en Microsoft.Compute/virtualMachines.
Invitado (clásico) Conjunto limitado de datos de Extensión de diagnósticos instalada. Los

rendimiento del sistema operativo datos se leen desde Azure Storage.
invitado y de la aplicación. Está
disponible en el explorador de métricas,
pero no en otras características de
Azure Monitor, como las alertas de
métricas.
Máquina virtual invitada Datos de rendimiento del sistema En Windows, la extensión de

operativo invitado y de la aplicación diagnósticos instalada con el receptor
disponibles para todas las de Azure Monitor habilitado. Para
características de Azure Monitor Linux, el agente de Telegraf instalado.
mediante métricas.
Analizar datos de registro

Las máquinas virtuales de Azure recopilarán los datos siguientes para los registros de Azure Monitor.
Azure Monitor para VM habilita la recopilación de un conjunto predeterminado de contadores de rendimiento que
se escriben en la tabla InsightsMetrics. Se trata de la misma tabla utilizada por Azure Monitor para contenedores.
O RIGEN DE DATO S REQ UISITO S TA B L A S

O RIGEN DE DATO S REQ UISITO S TA B L A S
Azure Monitor para máquinas virtuales Habilite en cada máquina virtual. InsightsMetrics
VMBoundPort
VMComputer
VMConnection
VMProcess
Vea Cómo consultar registros de Azure
Monitor para VM para obtener
información detallada.
Registro de actividades Configuración de diagnóstico para la AzureActivity

suscripción.
Métricas de la anfitriona Configuración de diagnóstico de la AzureMetrics

máquina virtual.
Orígenes de datos del sistema Habilite el agente de Log Analytics y Consulte la documentación de cada
operativo invitado configure los orígenes de datos. origen de datos.
NOTE
Los datos de rendimiento recopilados por el agente de Log Analytics escriben en la tabla Perf, mientras que Azure Monitor
para VM los recopilará en la tabla InsightsMetrics. Se trata de los mismos datos, pero las tablas tienen una estructura
diferente. Si tiene consultas existentes basadas en Perf, deberá volver a escribirlas para usar InsightsMetrics.
Alertas
Las alertas en Azure Monitor notifican de forma proactiva las condiciones importantes que encuentran en los
datos de supervisión y pueden adoptar medidas como iniciar una aplicación lógica o llamar a un webhook. Las
reglas de alerta definen la lógica que se usa para determinar cuándo se debe crear una alerta. Azure Monitor
recopila los datos usados por las reglas de alertas, pero debe crear reglas para definir las condiciones de alerta en
su suscripción de Azure.
En las secciones siguientes se describen los tipos de reglas de alertas y recomendaciones sobre cuándo se debe
usar cada una de ellas. Esta recomendación se basa en la funcionalidad y el costo del tipo de regla de alerta. Para
más información sobre los precios de las alertas, consulte Precios de Azure Monitor.
Las reglas de alerta del registro de actividad se activan cuando se crea una entrada que coincide con
determinados criterios en el registro de actividad. No tienen ningún costo, por lo que deben ser la primera opción
si la lógica que necesita está en el registro de actividad.
El recurso de destino para las alertas del registro de actividad puede ser una máquina virtual específica, todas las
máquinas virtuales de un grupo de recursos o todas las máquinas virtuales de una suscripción.
Por ejemplo, cree una alerta si se detiene una máquina virtual crítica seleccionando Desconectar máquina virtual
para el nombre de la señal.
Las reglas de alertas de métricas se activan cuando un valor de métrica supera un umbral. Puede definir un valor
de umbral específico o permitir que Azure Monitor determine dinámicamente un umbral en función de datos
históricos. Use las alertas de métricas siempre que sea posible con los datos de métricas, ya que tienen un costo
menor y tienen más capacidad de respuesta que las reglas de alertas de registro. También tienen estado, lo que
significa que se resolverán por sí mismas cuando la métrica caiga por debajo del umbral.
El recurso de destino para las alertas del registro de actividad puede ser una máquina virtual específica o todas las
máquinas virtuales de un grupo de recursos.
Por ejemplo, para crear una alerta cuando el procesador de una máquina virtual supera un valor determinado,
cree una regla de alertas de métricas con Porcentaje de CPU como tipo de señal. Establezca un valor de umbral
específico o permita que Azure Monitor establezca un umbral dinámico.
Alertas de registro
Las reglas de alertas de registro se activan cuando los resultados de una consulta de registro programada
coinciden con determinados criterios. Las alertas de consulta de registro son las reglas de alerta más caras y con
menos capacidad de respuesta, pero tienen acceso a los datos más diversos y pueden aplicar una lógica compleja
que no se puede conseguir mediante las demás reglas de alerta.
El recurso de destino para una consulta de registro es un área de trabajo de Log Analytics. Filtre para obtener los
equipos específicos de la consulta.
Por ejemplo, para crear una alerta que compruebe si una máquina virtual de un grupo de recursos determinado
está sin conexión, use la siguiente consulta, que devuelve un registro para cada equipo que no ha tenido ningún
latido en los últimos diez minutos. Use un umbral de 1 que se desencadene si al menos a un equipo le falta un
latido.
Heartbeat
| where TimeGenerated < ago(10m)
| where ResourceGroup == "my-resource-group"
| summarize max(TimeGenerated) by Computer
Para crear una alerta si se ha producido un número excesivo de inicios de sesión con errores en las máquinas
virtuales Windows de la suscripción, utilice la siguiente consulta, que devuelve un registro para cada evento con
un inicio de sesión con errores en la última hora. Use un umbral establecido en el número de inicios de sesión con
errores que permitirá.
Event
| where TimeGenerated < ago(1hr)
System Center Operations Manager

System Center Operations Manager (SCOM) proporciona una supervisión detallada de las cargas de trabajo en
las máquinas virtuales. Consulte la guía de supervisión en la nube para obtener una comparación de las
plataformas de supervisión y las distintas estrategias de implementación.
Si ya tiene un entorno de SCOM que desea seguir usando, puede integrarlo con Azure Monitor para proporcionar
funcionalidad adicional. El agente de Log Analytics usado por Azure Monitor es el mismo que se usa para SCOM,
de modo que las máquinas virtuales puedan enviar datos a ambos. Todavía necesita agregar el agente a Azure
Monitor para VM y configurar el área de trabajo para recopilar datos adicionales, tal y como se especificó
anteriormente, pero las máquinas virtuales pueden seguir ejecutando sus módulos de administración existentes
en un entorno de SCOM sin modificación.
Entre las características de Azure Monitor que aumentan las características de SCOM existentes se incluyen las
siguientes:
Use Log Analytics para analizar interactivamente los datos de registro y rendimiento.
Utilice alertas de registro para definir condiciones de alerta en varias máquinas virtuales y usar tendencias a
largo plazo que no se pueden obtener mediante alertas en SCOM.
Consulte Conexión de Operations Manager a Azure Monitor para obtener más información sobre cómo conectar
el grupo de administración de SCOM existente al área de trabajo de Log Analytics.
Pasos siguientes
Obtenga información sobre el análisis de datos en registros de Azure Monitor mediante consultas de registro.
Obtenga información sobre las alertas que usan métricas y registros en Azure Monitor.
Implementación de Azure Monitor
Habilitar Azure Monitor para supervisar todos los recursos de Azure es una combinación de la configuración de los
componentes de Azure Monitor y la configuración de los recursos de Azure para generar datos de supervisión para
que Azure Monitor los recopile. En este artículo se describen los diferentes pasos necesarios para realizar una
implementación completa de Azure Monitor con una configuración común para supervisar todos los recursos de la
suscripción de Azure. Se proporcionan descripciones básicas de cada paso con vínculos a otra documentación para
obtener información detallada sobre los requisitos de configuración.
IMPORTANT
Las características de Azure Monitor y su configuración variarán en función de los requisitos empresariales que se equilibran
con el costo de las características habilitadas. En cada paso siguiente se identificará si existe algún costo potencial y debe
evaluar estos costos antes de continuar con ese paso. Consulte Precios de Azure Monitor para obtener información detallada
sobre los precios.
Objetivos de configuración
El objetivo de una implementación completa de Azure Monitor es recopilar todos los datos disponibles de todos
sus recursos y aplicaciones en la nube y habilitar tantas características como sea posible en Azure Monitor según
los datos.
Los datos recopilados por Azure Monitor se envían a Métricas de Azure Monitor o Registros de Azure Monitor.
Cada uno almacena distintos tipos de datos y permite diferentes tipos de análisis y alertas. Consulte Comparación
de las métricas y los registros de Azure Monitor para obtener una comparación de ambos e Información general
sobre las alertas en Microsoft Azure para obtener una descripción de los diferentes tipos de alerta.
Algunos datos se pueden enviar a las métricas y los registros para poder aprovecharlos con diferentes
características. En estos casos, puede que tenga que configurar cada uno por separado. Por ejemplo, los recursos de
Azure envían los datos de métricas a las métricas, que admite el explorador de métricas y las alertas de métricas.
Debe crear una configuración de diagnóstico para que cada recurso envíe los mismos datos de métricas a los
registros, lo que le permite analizar las tendencias de rendimiento con otros datos de registro mediante Log
Analytics. En las secciones siguientes se identifica dónde se envían los datos y se incluye cada paso necesario para
enviar datos a todas las ubicaciones posibles.
Puede tener requisitos adicionales, como la supervisión de recursos fuera de Azure y el envío de datos fuera de
Azure Monitor. Requisitos como estos se pueden lograr con la configuración adicional de las características
descritas en este artículo. Siga los vínculos a la documentación en cada paso para obtener opciones de
configuración adicionales.
Recopilación de datos a partir de recursos de Azure

NOTE
Consulte Supervisión de recursos de Azure con Azure Monitor para obtener una guía completa sobre la supervisión de
máquinas virtuales con Azure Monitor.
La supervisión de los recursos de Azure está disponible automáticamente sin necesidad de configuración, pero
debe realizar los pasos de configuración para recopilar datos de supervisión adicionales. En la tabla siguiente se
muestran los pasos de configuración necesarios para recopilar todos los datos disponibles de los recursos de
Azure, incluido el paso en el que se envían los datos a Métricas de Azure Monitor y Registros de Azure Monitor.
Cada uno de los pasos se describe en detalle en las secciones que aparecen a continuación.
Sin configuración
Las siguientes características de Azure Monitor están habilitadas sin necesidad de configuración al crear una
suscripción de Azure. No hay ningún costo asociado con esta supervisión.
Registros de Azure Active Directory: proporcionan el historial de la actividad de inicio de sesión y la traza de
auditoría de los cambios realizados en Azure Active Directory. Consulte Informes de actividad de auditoría en el
portal de Azure Active Directory e Informes de actividad de inicio de sesión en el portal de Azure Active Directory
para obtener más información sobre los registros de Azure Active Directory y cómo verlos en Azure Portal.
Registro de actividad: proporciona información sobre el grupo de administración y los eventos que se han
producido en Azure en el nivel de la suscripción. Los eventos se escriben automáticamente en el registro de
actividad al crear un nuevo recurso de Azure, modificar un recurso o realizar una actividad significativa. Puede ver
los eventos en Azure Portal y crear alertas del registro de actividad cuando se crean eventos concretos. Consulte
Registro de actividad de Azure para obtener más información sobre el registro de actividad y cómo verlo en Azure
Portal.
Métricas de plataforma: se recopilan automáticamente de los servicios de Azure en las métricas de Azure Monitor.
Estos datos se suelen presentar en la página Información general de Azure Portal de los distintos servicios.
Consulte Introducción al Explorador de métricas de Azure para obtener más información sobre el análisis de las
métricas de la plataforma en Azure Portal.
Necesita al menos un área de trabajo de Log Analytics para habilitar los registros de Azure Monitor, lo que es
necesario para recopilar estos datos como registros de recursos de Azure, recopilar datos del sistema operativo
invitado de Azure Virtual Machines y para la mayoría de la información de Azure Monitor. Otros servicios, como
Azure Sentinel y Azure Security Center, también usan un área de trabajo de Log Analytics y pueden compartir la
misma que se usa para Azure Monitor. Puede empezar con una sola área de trabajo para admitir esta supervisión,
pero consulte Diseño de la implementación de registros de Azure Monitor para obtener instrucciones sobre cuándo
usar varias áreas de trabajo.
No hay ningún costo por la creación de un área de trabajo de Log Analytics, pero se puede realizar un cargo
adicional una vez configurados los datos que se van a recopilar. Consulte Administración del uso y los costos con
los registros de Azure Monitor para más información.
Consulte Creación de un área de trabajo de Log Analytics en Azure Portal para crear un área de trabajo de Log
Analytics inicial. Consulte Administración del acceso a los datos de registro y las áreas de trabajo en Azure Monitor
para configurar el acceso.
Creación de una configuración de diagnóstico para recopilar registros de inquilinos y suscripciones
Aunque los registros de Azure Active Directory del inquilino y el registro de actividad de la suscripción se recopilan
automáticamente, al enviarlos a un área de trabajo de Log Analytics, se pueden analizar estos eventos con otros
datos de registro mediante consultas de registro en Log Analytics. Esto también le permite crear alertas de consulta
de registro, que es la única manera de alertar sobre los registros de Azure Active Directory y proporcionar una
lógica más compleja que las alertas del registro de actividad.
No hay ningún costo por enviar el registro de actividad a un área de trabajo, pero hay una ingesta de datos y un
cargo de retención para los registros de Azure Active Directory.
Consulte Integración de registros de Azure AD con registros de Azure Monitor y Creación de una configuración de
diagnóstico para enviar los registros y las métricas de la plataforma a diferentes destinos para crear una
configuración de diagnóstico para el inquilino y la suscripción para enviar entradas de registro a su área de trabajo
de Log Analytics.
Creación de una configuración de diagnóstico para recopilar registros de recursos y métricas de la plataforma
Los recursos de Azure generan automáticamente registros de recursos que proporcionan detalles de las
operaciones realizadas dentro del recurso. Sin embargo, a diferencia de las métricas de plataforma, debe configurar
los registros de recursos que se van a recopilar. Cree una configuración de diagnóstico para enviarlos a un área de
trabajo de Log Analytics para combinarlos con los demás datos usados con los registros de Azure Monitor. Se
puede usar la misma configuración de diagnóstico para enviar también las métricas de la plataforma de la mayoría
de los recursos a la misma área de trabajo, lo que permite analizar datos de métricas mediante consultas de
registro con otros datos recopilados.
Esta recopilación tiene un costo, por lo que debe consultar Precios de Azure Monitor antes de implementarla en un
número significativo de recursos. Consulte también Administrar el uso y los costos con los registros de Azure
Monitor para obtener más información sobre cómo optimizar el costo de la recopilación de registros.
Consulte Creación de una configuración de diagnóstico para recopilar registros y métricas en Azure para crear una
configuración de diagnóstico para un recurso de Azure. Dado que es necesario crear una configuración de
diagnóstico para cada recurso de Azure, consulte Implementación de Azure Monitor a gran escala para obtener
más información sobre el uso de Azure Policy para que la configuración se cree automáticamente cada vez que se
crea un recurso de Azure.
Habilitación de conclusiones y soluciones
Las conclusiones y soluciones proporcionan una supervisión especializada para un servicio o una solución en
concreto. Las conclusiones utilizan las características más recientes de Azure Monitor, como los libros, por lo que
debe usar una conclusión si está disponible para su servicio. Están disponibles automáticamente en todas las
suscripciones de Azure, pero pueden requerir cierta configuración para una funcionalidad completa. Normalmente
usarán los registros de recursos y las métricas de la plataforma que ha configurado previamente y que pueden
recopilar datos adicionales.
Las soluciones se deben agregar a cada suscripción, funcionan exclusivamente con datos de registros de Azure
Monitor y pueden recopilar datos de registro adicionales.
No hay ningún costo por las soluciones o conclusiones, pero puede que se le cobren los datos que recopilan.
Consulte ¿Qué supervisa Azure Monitor? para obtener una lista de las conclusiones y soluciones disponibles en
Azure Monitor. Consulte la documentación de cada una de las configuraciones o la información de precios.
Recopilación de datos de Virtual Machines
NOTE
Consulte Supervisión de máquinas virtuales de Azure con Azure Monitor para obtener una guía completa sobre la
supervisión de máquinas virtuales con Azure Monitor.
Las máquinas virtuales generan datos similares a otros recursos de Azure, pero necesita un agente para recopilar
datos del sistema operativo invitado. Consulte Introducción a los agentes de Azure Monitor para ver una
comparación de los agentes que usa Azure Monitor.
Azure Monitor para VM usa el agente de Log Analytics y el agente de dependencia para recopilar datos del sistema
operativo invitado de las máquinas virtuales, por lo que puede implementar estos agentes como parte de la
implementación de esta información. Esto habilita al agente de Log Analytics para otros servicios que lo usan,
como Azure Security Center.
Configuración del área de trabajo de Azure Monitor para VM

Azure Monitor para VM requiere un área de trabajo de Log Analytics, que normalmente será la misma que la
creada para recopilar datos de otros recursos de Azure. Antes de habilitar las máquinas virtuales, debe agregar la
solución necesaria para Azure Monitor para VM al área de trabajo.
Consulte Configuración del área de trabajo de Log Analytics para Azure Monitor para VM para obtener más
información sobre la configuración del área de trabajo de Log Analytics para Azure Monitor para VM.
Habilitación de Azure Monitor para VM de cada máquina virtual
Una vez configurada un área de trabajo, puede habilitar cada máquina virtual mediante la instalación del agente de
Log Analytics y Dependency Agent. Hay varios métodos para instalar estos agentes, incluido Azure Policy, que
permite configurar automáticamente cada máquina virtual a medida que se crea. Los datos de rendimiento y los
detalles del proceso recopilados por Azure Monitor para VM se almacenan en registros de Azure Monitor.
Consulte Información general sobre la habilitación de Azure Monitor para VM para ver las opciones de
implementación de los agentes en las máquinas virtuales y habilitarlas para la supervisión.
Configuración del área de trabajo para recopilar eventos
Azure Monitor para VM recopilará los datos de rendimiento y los detalles y las dependencias de los procesos del
sistema operativo invitado de cada máquina virtual. El agente de Log Analytics también puede recopilar registros
del invitado, incluido el registro de eventos de Windows y Syslog de Linux. Recupera la configuración de estos
registros del área de trabajo de Log Analytics a la que está conectado. Solo tiene que configurar el área de trabajo
una vez y, cada vez que se conecte un agente, se descargarán todos los cambios de configuración.
Consulte Orígenes de datos de agente en Azure Monitor para obtener más información sobre la configuración del
área de trabajo de Log Analytics para recopilar datos adicionales de las máquinas virtuales del agente.
NOTE
También puede configurar el área de trabajo para recopilar contadores de rendimiento, pero lo más probable es que sea
redundante con los datos de rendimiento recopilados por Azure Monitor para VM. Los datos de rendimiento recopilados por
el área de trabajo se almacenarán en la tabla Perf, mientras que los datos de rendimiento recopilados por Azure Monitor para
VM se almacenan en la tabla InsightsMetrics. Configure la recopilación de rendimiento en el área de trabajo solo si necesita
contadores que no están ya recopilados por Azure Monitor para VM.
Extensión de diagnósticos y agente de Telegraf

Azure Monitor para VM usa el agente de Log Analytics que envía datos de rendimiento a un área de trabajo de Log
Analytics, pero no a métricas de Azure Monitor. El envío de estos datos a las métricas permite analizarlos con
Explorador de métricas y usarlos con las alertas de métricas. Esto requiere la extensión de diagnósticos en
Windows y el agente de Telegraf en Linux.
Consulte Instalación y configuración de la extensión de Azure Diagnostics (WAD) para Windows y Recopilación de
métricas personalizadas para una máquina virtual Linux con el agente de InfluxData Telegraf para obtener más
información sobre la instalación y configuración de estos agentes.
Supervisión de aplicaciones
Azure Monitor supervisa las aplicaciones personalizadas con Application Insights, que debe configurar para cada
aplicación que quiera supervisar. El proceso de configuración variará en función del tipo de aplicación que se esté
supervisando y del tipo de supervisión que quiera realizar. Los datos recopilados por Application Insights se
almacenan en las métricas de Azure Monitor, los registros de Azure Monitor y Azure Blob Storage, en función de la
característica. Los datos de rendimiento se almacenan en las métricas de Azure Monitor y los registros de Azure
Monitor sin necesidad de configuración adicional.
Creación de un recurso de aplicación
Debe crear un recurso en Application Insights para cada aplicación que vaya a supervisar. Los datos de registro
recopilados por Application Insights se almacenan en los registros de Azure Monitor, pero de forma independiente
del área de trabajo de Log Analytics, tal y como se describe en ¿Cómo se estructuran los registros de Azure
Monitor?. Actualmente está en versión preliminar, aunque es la capacidad de almacenar los datos de la aplicación
directamente en un área de trabajo de Log Analytics con los demás datos. Esto simplifica la configuración y permite
que la aplicación aproveche todas las características de un área de trabajo de Log Analytics.
Al crear la aplicación, debe seleccionar si quiere usar la versión clásica o basada en el área de trabajo (versión
preliminar). Consulte Creación de recursos en Application Insights para crear una aplicación clásica. Consulte
Recursos de Application Insights basados en área de trabajo (versión preliminar) para crear una aplicación basada
en el área de trabajo.
Configuración de la supervisión no codificada o basada en código
Para habilitar la supervisión de una aplicación, debe decidir si utilizará la supervisión sin código o basada en
código. El proceso de configuración variará en función de esta decisión y del tipo de aplicación que vaya a
supervisar.
La super visión sin código es más fácil de implementar y se puede configurar después del desarrollo del código.
No requiere ninguna actualización en el código. Consulte los siguientes recursos para obtener más información
sobre cómo habilitar la supervisión en función de la aplicación.
Aplicaciones hospedadas en Azure Web Apps
Aplicaciones de Java
Aplicaciones ASP.NET hospedadas en IIS en una máquina virtual de Azure o un conjunto de escalado de
máquinas virtuales de Azure
Aplicaciones ASP.NET hospedadas en una máquina virtual en el entorno local de IIS
La super visión basada en código es más personalizable y recopila telemetría adicional, pero requiere agregar
una dependencia al código en los paquetes NuGet del SDK de Application Insights. Consulte los siguientes recursos
para obtener más información sobre cómo habilitar la supervisión en función de la aplicación.
Aplicaciones ASP.NET
Aplicación ASP.NET Core
Aplicaciones de consola .NET
Java
Node.js
Python
Otras plataformas
Configuración de las pruebas de disponibilidad
Las pruebas de disponibilidad en Application Insights son pruebas periódicas que supervisan la disponibilidad y la
capacidad de respuesta de la aplicación a intervalos regulares desde puntos de todo el mundo. Puede crear una
prueba de ping simple de forma gratuita o crear una secuencia de solicitudes web para simular las transacciones de
usuario con un costo asociado.
Consulte Supervisión de la disponibilidad de un sitio web para obtener un resumen de los diferentes tipos de
pruebas y detalles sobre cómo crearlas.
Configuración de Profiler
Profiler en Application Insights proporciona seguimientos de rendimiento para aplicaciones .NET. Le ayuda a
identificar la ruta de acceso "activa" al código que tarda más tiempo cuando se atiende una solicitud web
determinada. El proceso para configurar el generador de perfiles varía en función del tipo de aplicación.
Consulte Generación de perfiles de aplicaciones de producción en Azure con Application Insights para obtener más
información sobre la configuración de Profiler.
Configuración de Snapshot Debugger
Snapshot Debugger en Application Insights supervisa la telemetría de excepciones de la aplicación .NET y recopila
instantáneas en las principales excepciones que se producen para que tenga la información que necesita para
diagnosticar problemas en producción. El proceso para configurar Snapshot Debugger varía en función del tipo de
aplicación.
Consulte Depurar instantáneas cuando se producen excepciones en aplicaciones de .NET para obtener más
información sobre la configuración de Snapshot Debugger.
Las conclusiones y las soluciones incluirán sus propios libros y vistas para analizar sus datos. Además, puede crear
sus propias visualizaciones, incluidos libros de datos y paneles de Azure Monitor para combinar los datos de Azure
Monitor con datos de otros servicios de Azure.
Creación de libros
Los libros de Azure Monitor permiten crear informes visuales enriquecidos en Azure Portal. Puede combinar
diferentes conjuntos de datos de métricas de Azure Monitor y registros de Azure Monitor para crear experiencias
interactivas unificadas. Puede tener acceso a una galería de libros en la pestaña Libros del menú de Azure Monitor.
Consulte Libros de Azure Monitor para obtener más información sobre la creación de libros personalizados.
Crear paneles
Los paneles de Azure son la principal tecnología de paneles de Azure y permiten combinar datos de Azure Monitor
con datos de otros servicios para proporcionar un panel único a través de la infraestructura de Azure. Consulte
Creación y uso compartido de paneles de datos de Log Analytics para obtener más información sobre cómo crear
un panel que incluya datos de registros de Azure Monitor.
Consulte Creación de paneles de indicadores clave de rendimiento (KPI) personalizados con Azure Application
Insights para más información sobre cómo crear un panel que incluya datos de Application Insights.
Alertas
Las alertas de Azure Monitor notifican al usuario proactivamente sobre datos y patrones importantes identificados
en los datos de supervisión. Algunas conclusiones generarán alertas sin configuración. En el caso de otros
escenarios, debe crear reglas de alertas que incluyan los datos que se van a analizar y los criterios sobre cuándo se
debe generar una alerta, así como los grupos de acciones que definen la acción que se realizará cuando se genere
una alerta.
Creación de grupos de acciones
Los grupos de acciones son una recopilación de las preferencias de notificación que usan las reglas de alerta para
determinar la acción que se realizará cuando se desencadene una alerta. Entre los ejemplos de acciones se incluyen
el envío de un correo electrónico o un SMS, la llamada a un webhook o el envío de datos a una herramienta de
ITSM. Cada regla de alerta requiere al menos un grupo de acciones, del mismo modo que varias reglas de alerta
pueden usar un solo grupo de acciones.
Consulte Creación y administración de grupos de acciones en Azure Portal para más información sobre cómo crear
un grupo de acciones y una descripción de las distintas acciones que puede incluir.
Hay varios tipos de reglas de alerta definidos por el tipo de datos que usan. Cada una tiene capacidades y costos
diferentes. La estrategia básica que debe seguir es usar el tipo de regla de alerta con el costo más bajo que
proporciona la lógica que necesita.
Reglas del registro de actividad. Crea una alerta en respuesta a un nuevo evento de registro de actividad que
coincide con las condiciones especificadas. No hay ningún costo en estas alertas, por lo que deben ser la
primera opción. Consulte Crear, ver y administrar las alertas del registro de actividad mediante Azure Monitor
para más detalles sobre la creación de alertas de registro de actividad.
Reglas de alertas de métricas. Crea una alerta en respuesta a uno o varios valores de métrica que superan un
umbral. Las alertas de métricas tienen estado, lo que significa que la alerta se cerrará automáticamente cuando
el valor caiga por debajo del umbral y solo enviará notificaciones cuando cambie el estado. Hay un costo para
las alertas de métricas, pero es significativamente menor que para las alertas de registro. Consulte Creación,
visualización y administración de alertas de métricas mediante Azure Monitor para más detalles sobre la
creación de alertas de métricas.
Reglas de alertas de registro. Crea una alerta cuando los resultados de una consulta de programación coinciden
con los criterios especificados. Son las reglas de alertas más caras, pero permiten los criterios más complejos.
Consulte Creación, visualización y administración de alertas de registro mediante Azure Monitor para más
detalles sobre la creación de alertas de consulta de registros.
Las alertas de aplicación permiten realizar pruebas proactivas de rendimiento y disponibilidad de la aplicación
web. Puede realizar una prueba de ping simple sin costo alguno, pero hay un costo para las pruebas más
complejas. Consulte Supervisión de la disponibilidad de un sitio web para obtener una descripción de las
diferentes pruebas y detalles sobre cómo crearlas.
Pasos siguientes
Consulte Implementación de Azure Monitor a gran escala mediante Azure Policy.
Implementación de Azure Monitor a escala
mediante Azure Policy
Aunque algunas características de Azure Monitor se configuran una vez o un número limitado de veces, otras se
deben repetir para cada recurso que desee supervisar. En este artículo se describen los métodos para usar Azure
Policy para implementar Azure Monitor a escala con el fin de asegurarse de que la supervisión se configura de
forma coherente y precisa para todos los recursos de Azure.
Por ejemplo, debe crear una configuración de diagnóstico para todos los recursos de Azure existentes y para
cada recurso nuevo que cree. También debe tener un agente instalado y configurado cada vez que cree una
máquina virtual. Puede usar métodos como PowerShell o la CLI para realizar estas acciones, ya que estos
métodos están disponibles para todas las características de Azure Monitor. Con Azure Policy, puede tener en
funcionamiento una lógica que realizará automáticamente la configuración adecuada cada vez que cree o
modifique un recurso.
Azure Policy
En esta sección se proporciona una breve introducción a Azure Policy, que le permite evaluar y aplicar los
estándares de la organización en toda la suscripción de Azure o en un grupo de administración con un esfuerzo
mínimo. Para más información, consulte la documentación de Azure Policy.
Con Azure Policy puede especificar los requisitos de configuración para todos los recursos que se creen e
identificar los recursos que no son compatibles, bloquear la creación de los recursos o agregar la configuración
necesaria. Funciona mediante la interceptación de las llamadas para crear un nuevo recurso o modificar un
recurso existente. Puede responder con efectos tales como denegar la solicitud si no coincide con las
propiedades esperadas en una definición de directiva, marcarla como no compatible o implementar un recurso
relacionado. Puede corregir los recursos existentes con una definición de directiva deployIfNotExists
(implementar si no existe) o modify (modificar).
Azure Policy consta de los objetos de la tabla siguiente. Consulte Objetos de Azure Policy para una explicación
más detallada de cada uno.
EL EM EN TO DESC RIP C IÓ N
Definición de directiva Describe las condiciones de cumplimiento de los recursos y el

efecto que se debe realizar si se cumple una condición.
Puede tratarse de todos los recursos de un tipo determinado
o solo de aquellos recursos que coinciden con determinadas
propiedades. El efecto puede ser simplemente marcar el
recurso para el cumplimiento o implementar un recurso
relacionado. Las definiciones de directiva se escriben
mediante código JSON, tal como se describe en Estructura
de las definiciones de Azure Policy. Los efectos se describen
en Descripción de los efectos de Azure Policy.
EL EM EN TO DESC RIP C IÓ N
Iniciativa de directiva Grupo de definiciones de directiva que se deben aplicar

juntas. Por ejemplo, podría tener una definición de directiva
para enviar los registros de recursos a un área de trabajo de
Log Analytics y otra para enviar los registros de recursos a
Event hubs. Cree una iniciativa que incluya ambas
definiciones de directiva y aplique la iniciativa a los recursos
en lugar de a las definiciones de directiva individuales. Las
iniciativas se escriben mediante código JSON, tal como se
describe en Estructura de las iniciativas de Azure Policy.
Asignación Una definición de directiva o una iniciativa no tienen efecto

hasta que se asignan a un ámbito. Por ejemplo, asigne una
directiva a un grupo de recursos para aplicarla a todos los
recursos creados en ese recurso o aplíquela a una suscripción
para aplicarla a todos los recursos de esa suscripción. Para
más información, consulte Estructura de las asignaciones de
Azure Policy.
Definiciones de directivas integradas para Azure Monitor

Azure Policy incluye varias definiciones creadas previamente relacionadas con Azure Monitor. Puede asignar
estas definiciones de directiva a la suscripción existente o utilizarlas como base para crear sus propias
definiciones personalizadas. Para obtener una lista completa de la directivas integradas de la categoría
Super visión , consulte Definiciones de directivas integradas de Azure Policy para Azure Monitor.
Para ver las definiciones de directivas integradas relacionadas con la supervisión, realice lo siguiente:
1. Vaya a Azure Policy en Azure Portal.
2. Seleccione Definiciones .
3. En Tipo , seleccione Integrada y, en Categoría , seleccione Supervisión.
La Configuración de diagnóstico recopila registros de recursos y métricas de los recursos de Azure en varias
ubicaciones, normalmente en un área de trabajo de Log Analytics, que permite analizar los datos con consultas
de registro y alertas de registro. Use Azure Policy para crear automáticamente una configuración de diagnóstico
cada vez que cree un recurso.
Cada tipo de recurso de Azure tiene un conjunto único de categorías que se deben enumerar en la configuración
de diagnóstico. Debido a esto, cada tipo de recurso requiere una definición de directiva independiente. Algunos
tipos de recursos tienen definiciones de directivas integradas que se pueden asignar sin modificaciones. Para
otros tipos de recursos, debe crear una definición personalizada.
Definiciones de directivas integradas para Azure Monitor
Hay dos definiciones de directivas integradas para cada tipo de recurso, una para enviar datos a un área de
trabajo de Log Analytics y otra a Event Hubs. Si solo necesita una ubicación, asigne esa directiva al tipo de
recurso. Si necesita ambas, asigne ambas definiciones de directiva al recurso.
Por ejemplo, la siguiente imagen muestra las definiciones de directiva de configuración de diagnóstico
integradas para Data Lake Analytics.
Definiciones de directivas personalizadas

En el caso de los tipos de recursos que no tienen una directiva integrada, debe crear una definición de directiva
personalizada. Puede hacerlo manualmente en Azure Portal mediante la copia de una directiva integrada
existente y, a continuación, su modificación para el tipo de recurso. No obstante, es más eficaz crear la directiva
mediante programación con un script de la Galería de PowerShell.
El script Create-AzDiagPolicy crea archivos de directivas para un tipo de recurso determinado que se pueden
instalar mediante PowerShell o la CLI. Use el procedimiento siguiente para crear una definición de directiva
personalizada para la configuración de diagnóstico.
1. Asegúrese de que tiene instalado Azure PowerShell.
2. Instale el script con el comando siguiente:
Install-Script -Name Create-AzDiagPolicy
3. Ejecute el script con parámetros para especificar dónde enviar los registros. Se le pedirá que especifique
una suscripción y un tipo de recurso. Por ejemplo, para crear una definición de directiva que envíe datos a
un área de trabajo de Log Analytics y a Event Hubs, use el comando siguiente.
Create-AzDiagPolicy.ps1 -ExportLA -ExportEH -ExportDir ".\PolicyFiles"
4. Como alternativa, puede especificar una suscripción y un tipo de recurso en el comando. Por ejemplo,
para crear una definición de directiva que envíe datos a un área de trabajo de Log Analytics y a Event
Hubs para bases de datos de Azure SQL Server, use el comando siguiente.
Create-AzDiagPolicy.ps1 -SubscriptionID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -ResourceType

Microsoft.Sql/servers/databases -ExportLA -ExportEH -ExportDir ".\PolicyFiles"
5. El script crea carpetas independientes para cada definición de directiva, cada una de las cuales contiene
tres archivos llamados azurepolicy.json, azurepolicy.rules.json y azurepolicy.parameters.json. Si desea
crear la directiva manualmente en Azure Portal, puede copiar y pegar el contenido del archivo
azurepolicy.json, ya que incluye la definición de directiva completa. Use los otros dos archivos con
PowerShell o la CLI para crear la definición de directiva desde la línea de comandos.
En los siguientes ejemplos se muestra cómo instalar la definición de directiva desde PowerShell y la CLI.
Cada uno incluye metadatos para especificar la categoría Super visión para agrupar la nueva definición
de directiva con las definiciones de directivas integradas.
New-AzPolicyDefinition -name "Deploy Diagnostic Settings for SQL Server database to Log Analytics
workspace" -policy .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json -
parameter .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json -mode
All -Metadata '{"category":"Monitoring"}'
az policy definition create --name 'deploy-diag-setting-sql-database--workspace' --display-name

'Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace' --rules 'Apply-Diag-
Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json' --params 'Apply-Diag-Settings-LA-
Microsoft.Sql-servers-databases\azurepolicy.parameters.json' --subscription 'AzureMonitor_Docs' --
mode All
Iniciativa
En lugar de crear una asignación para cada definición de directiva, una estrategia habitual consiste en crear una
iniciativa que incluya las definiciones de directivas para crear la configuración de diagnóstico para cada servicio
de Azure. Cree una asignación entre la iniciativa y un grupo de administración, una suscripción o un grupo de
recursos, en función de cómo administre el entorno. Esta estrategia ofrece las siguientes ventajas:
Cree una única asignación para la iniciativa en lugar de varias asignaciones para cada tipo de recurso. Use la
misma iniciativa para varios grupos de supervisión, suscripciones o grupos de recursos.
Modifique la iniciativa cuando necesite agregar un nuevo tipo de recurso o destino. Por ejemplo, los
requisitos iniciales pueden ser enviar datos solo a un área de trabajo de Log Analytics, pero más adelante
puede que desee agregar Event Hubs. Modifique la iniciativa en lugar de crear nuevas asignaciones.
Consulte Creación y asignación de una definición de iniciativa para más información sobre cómo crear una
iniciativa. Tenga en cuenta las recomendaciones siguientes:
Establezca Categoría en Super visión para agruparla con las definiciones de directivas integradas y
personalizadas relacionadas.
En lugar de especificar los detalles del área de trabajo de Log Analytics y Event Hubs para la definición de
directiva que se incluye en la iniciativa, use un parámetro de iniciativa común. Esto le permite especificar
fácilmente un valor común para todas las definiciones de directivas y cambiar ese valor si es necesario.
Asignación
Asigne la iniciativa a un grupo de administración, una suscripción o un grupo de recursos de Azure en función
del ámbito de los recursos que se van a supervisar. Un grupo de administración es especialmente útil para dar
un ámbito a la directiva, especialmente si la organización tiene varias suscripciones.
Mediante el uso de parámetros de iniciativa, puede especificar el área de trabajo o cualquier otro detalle para
todas las definiciones de directivas de la iniciativa.
Corrección
La iniciativa se aplicará a cada máquina virtual a medida que esta se cree. Una tarea de corrección implementa
las definiciones de directivas de la iniciativa en los recursos existentes, de modo que esto le permite crear una
configuración de diagnóstico para los recursos que ya se han creado. Al crear la asignación mediante Azure
Portal, tiene la opción de crear una tarea de corrección al mismo tiempo. Consulte Corrección de los recursos no
compatibles con Azure Policy para más información sobre la corrección.

Azure Monitor para VM es la herramienta principal de Azure Monitor para supervisar máquinas virtuales. La
habilitación de Azure Monitor para VM instala el agente de Log Analytics y el agente de dependencias. En lugar
de realizar estas tareas manualmente, use Azure Policy para asegurarse de que todas las máquinas virtuales se
configuran a medida que se crean.
NOTE
Azure Monitor para VM incluye una característica denominada Cober tura de directiva de Azure Monitor para VM
que permite detectar y corregir VM no compatibles en el entorno. Puede usar esta característica en lugar de trabajar
directamente con Azure Policy para VM de Azure y para máquinas virtuales híbridas conectadas a Azure Arc. En el caso de
los conjuntos de escalado de máquinas virtuales de Azure, debe crear la asignación mediante Azure Policy.
Azure Monitor para VM incluye las siguientes iniciativas integradas que instalan ambos agentes para habilitar la
supervisión completa.
N O M B RE DESC RIP C IÓ N
Habilitar Azure Monitor para VM Instala el agente de Log Analytics y Dependency Agent en
VM de Azure y VM híbridas conectadas a Azure Arc.
Habilitar Azure Monitor para conjunto de escalado de Instala el agente de Log Analytics y Dependency Agent en el
máquinas virtuales conjunto de escalado de máquinas virtuales de Azure.
Máquinas virtuales
En lugar de crear asignaciones para estas iniciativas mediante la interfaz de Azure Policy, Azure Monitor para VM
incluye una característica que le permite inspeccionar el número de máquinas virtuales de cada ámbito para
determinar si se ha aplicado la iniciativa. A continuación, puede configurar el área de trabajo y crear las
asignaciones necesarias mediante esa interfaz.
Para más información sobre este proceso, consulte Habilitación de Azure Monitor para VM mediante Azure
Policy.
Conjuntos de escalado de máquinas virtuales

Para usar Azure Policy para habilitar la supervisión de conjuntos de escalado de máquinas virtuales, asigne la
iniciativa Habilitar Azure Monitor para conjuntos de escalado de máquinas vir tuales a un grupo de
administración, suscripción o grupo de recursos de Azure en función del ámbito de los recursos que se
supervisarán. Un grupo de administración es especialmente útil para dar un ámbito a la directiva, especialmente
si la organización tiene varias suscripciones.
Seleccione el área de trabajo a la que se enviarán los datos. Esta área de trabajo debe tener instalada la solución
VMInsights, como se describe en .
Cree una tarea de corrección si tiene un conjunto de escalado de máquinas virtuales existente al que sea
necesario asignar esta directiva.
Es posible que tenga escenarios en los que quiera instalar el agente de Log Analytics pero no Dependency Agent.
No existe ninguna iniciativa integrada solo para el agente, pero puede crear su propia iniciativa a partir de las
definiciones de directivas integradas proporcionadas por Azure Monitor para VM.
NOTE
No debería haber ninguna razón para implementar Dependency Agent por sí mismo, ya que requiere que el Log Analytics
agente entregue sus datos a Azure Monitor.
Auditoría de la implementación del agente de Log Analytics: Notifica que las máquinas virtuales no son compatibles si la
la imagen de la VM (SO) no está en la lista imagen de la máquina virtual (SO) no está definida en la lista
y el agente no está instalado.
Implementar el agente de Log Analytics en máquinas Se implementa el agente de Log Analytics en máquinas
virtuales de Linux virtuales Linux si la imagen de la máquina virtual (SO) está
en la lista definida y el agente no está instalado.
Implementar el agente de Log Analytics en máquinas Se implementa el agente de Log Analytics en máquinas
virtuales Windows virtuales Windows si la imagen de la máquina virtual (SO)
está en la lista definida y el agente no está instalado.
[Versión preliminar]: El agente de Log Analytics debe estar Informa las máquinas de Azure Arc híbridas como no
instalado en las máquinas Linux de Azure Arc compatibles con VM Linux si la imagen de la VM (SO) está
definida en la lista y el agente no está instalado.
[Versión preliminar]: El agente de Log Analytics debe estar Informa las máquinas de Azure Arc híbridas como no
instalado en las máquinas Windows de Azure Arc compatibles con VM Windows si la imagen de la VM (SO)
está definida en la lista y el agente no está instalado.
[Versión preliminar]: Implementar el agente de Log Analytics Implemente el agente de Log Analytics en las máquinas de
en máquinas de Azure Arc con Linux Azure Arc híbridas con Linux si la imagen de la VM (SO) está
definida en la lista y el agente no está instalado.
[Versión preliminar]: Implementar el agente de Log Analytics Implemente el agente de Log Analytics en las máquinas de
en máquinas de Azure Arc con Windows Azure Arc híbridas con Windows si la imagen de la VM (SO)
está definida en la lista y el agente no está instalado.
Auditoría de implementación de Dependency Agent en Notifica que los conjuntos de escalado de máquinas virtuales
conjuntos de escalado de máquinas virtuales: la imagen de la no son compatibles si la imagen de la máquina virtual (SO)
VM (SO) no está en la lista no está definida en la lista y el agente no está instalado.
Auditoría de implementación del agente de Log Analytics en Notifica que los conjuntos de escalado de máquinas virtuales
conjuntos de escalado de máquinas virtuales: la imagen de la no son compatibles si la imagen de la máquina virtual (SO)
VM (SO) no está en la lista no está definida en la lista y el agente no está instalado.
Implementar el agente de Log Analytics para conjuntos de Se implementa el agente de Log Analytics en los conjuntos
escalado de máquinas virtuales Linux de escalado de máquinas virtuales Linux si la imagen de la
máquina virtual (SO) está en la lista definida y el agente no
está instalado.
Implementar el agente de Log Analytics para conjuntos de Se implementa el agente de Log Analytics en los conjuntos
escalado de máquinas virtuales Windows de escalado de máquinas virtuales Windows si la imagen de
la máquina virtual (SO) está en la lista definida y el agente no
está instalado.
Pasos siguientes
Más información acerca de Azure Policy.
NOTE
Muchos equipos necesitan regular estrictamente el acceso a los datos y la configuración de supervisión. Por
ejemplo, si tiene miembros del equipo que trabajan exclusivamente en la supervisión (ingenieros de soporte
técnico o ingenieros de DevOps) o si usa un proveedor de servicios administrados, puede concederles acceso
solo a datos de supervisión, mientras restringe su capacidad para crear, modificar o eliminar recursos. En este
artículo se explica cómo aplicar rápidamente un rol de Azure de supervisión integrado a un usuario en Azure o
crear un rol personalizado propio para un usuario que necesita permisos de supervisión limitados. Después se
describen las consideraciones de seguridad para los recursos relacionados con Azure Monitor y cómo puede
limitar el acceso a los datos que contienen.
Roles de supervisión integrados

Los roles integrados en Azure Monitor están diseñados para ayudar a limitar el acceso a recursos de una
suscripción, sin impedir que los responsables de la infraestructura de supervisión obtengan y configuren los
datos que necesitan. Azure Monitor proporciona dos roles de fábrica: un lector de supervisión y un colaborador
de supervisión.
Lector de supervisión
Las personas asignadas al rol Lector de supervisión pueden ver todos los datos de supervisión en una
suscripción, pero no pueden modificar cualquier recurso o editar cualquier configuración relacionada con la
supervisión de recursos. Este rol es adecuado para los usuarios de una organización, como los ingenieros de
soporte técnico u operaciones que necesitan tener la capacidad de:
Ver paneles de supervisión en el portal y crear sus propios paneles de supervisión privados.
Ver las reglas de alerta definidas en Alertas de Azure
Consultar métricas con la API de REST de Azure Monitor, los cmdlets de PowerShell o la CLI multiplataforma.
Consultar el registro de actividades a través del portal, la API de REST de Azure Monitor, los cmdlets de
PowerShell o la CLI multiplataforma.
Ver la configuración de diagnóstico de un recurso.
Ver el perfil de registro de una suscripción.
Consultar la configuración de escalado automático.
Consultar la configuración y actividad de alertas.
Acceder a datos de Application Insights y ver los datos en AI Analytics.
Buscar datos del área de trabajo de Log Analytics, incluidos los datos de uso del área de trabajo.
Ver grupos de administración de Log Analytics.
Recuperar el esquema de búsqueda en el área de trabajo de Log Analytics.
Enumerar los paquetes de supervisión en el área de trabajo de Log Analytics.
Recuperar y ejecutar las búsquedas guardadas en el área de trabajo de Log Analytics.
Recuperar la configuración de almacenamiento del área de trabajo de Log Analytics.
NOTE
Este rol no otorga acceso de lectura a los datos de registro que se han transmitido a un centro de eventos o que están
almacenados en una cuenta de almacenamiento. Vea la información a continuación para saber cómo configurar el acceso a
estos recursos.
Colaborador de supervisión
Las personas asignadas al rol Colaborador de supervisión pueden ver todos los datos de supervisión en una
suscripción y crear o modificar la configuración de supervisión, pero no pueden modificar los demás recursos.
Este rol es un superconjunto del rol Lector de supervisión y es adecuado para los miembros del equipo de
supervisión de una administración o los proveedores de servicios administrados que, además de los permisos
anteriores, también necesitan tener la capacidad de:
Publicar paneles de supervisión como un panel compartido.
Determinar la configuración de diagnóstico de un recurso.*
Establecer el perfil de registro de una suscripción.*
Establecer la configuración y la actividad de las reglas de alertas a través de Alertas de Azure.
Crear componentes y pruebas web de Application Insights.
Mostrar las claves compartidas del área de trabajo de Log Analytics.
Habilitar o deshabilitar los paquetes de supervisión en el área de trabajo de Log Analytics.
Crear, eliminar y ejecutar las búsquedas guardadas en el área de trabajo de Log Analytics.
Crear y eliminar la configuración de almacenamiento del área de trabajo de Log Analytics.
*Al usuario también se le debe conceder el permiso ListKeys por separado en el recurso de destino (cuenta de
almacenamiento o espacio de nombres del centro de eventos) para definir la configuración del diagnóstico o el
perfil de registros.
NOTE
Este rol no otorga acceso de lectura a los datos de registro que se han transmitido a un centro de eventos o que están
almacenados en una cuenta de almacenamiento. Vea la información a continuación para saber cómo configurar el acceso a
estos recursos.
Permisos de supervisión y roles de Azure personalizados

Si los roles integrados anteriores no satisfacen las necesidades exactas de su equipo, puede crear un rol de Azure
personalizado con permisos más granulares. A continuación se muestran las operaciones comunes de RBAC de
Azure Monitor con sus descripciones.
O P ERA C IÓ N DESC RIP C IÓ N
Microsoft.Insights/ActionGroups/[Read, Write, Delete] Leer, escribir o eliminar grupos de acción.
Microsoft.Insights/ActivityLogAlerts/[Read, Write, Delete] Leer, escribir o eliminar alertas de registro de actividad.
Microsoft.Insights/AlertRules/[Read, Write, Delete] Leer, escribir o eliminar reglas de alertas (desde alertas
clásicas).
O P ERA C IÓ N DESC RIP C IÓ N
Microsoft.Insights/AlertRules/Incidents/Read Enumerar los incidentes (historial de la regla de alerta

desencadenada) de reglas de alerta. Solo se aplica en el
portal.
Microsoft.Insights/AutoscaleSettings/[Read, Write, Delete] Configuración de escalado automático de lectura, escritura y

eliminación.
Microsoft.Insights/DiagnosticSettings/[Read, Write, Delete] Configuración de diagnóstico de lectura, escritura y

eliminación.
Microsoft.Insights/EventCategories/Read Enumerar todas las categorías posibles en el registro de

actividad. Lo utiliza Azure Portal.
Microsoft.Insights/eventtypes/digestevents/Read Este permiso es necesario para los usuarios que necesitan

acceder a registros de actividades a través del portal.
Microsoft.Insights/eventtypes/values/Read Enumerar eventos del registro de actividades (eventos de

administración) de una suscripción. Este permiso es aplicable
para el acceso mediante programación y mediante el portal al
registro de actividades.
Microsoft.Insights/ExtendedDiagnosticSettings/[Read, Write, Leer, escribir o eliminar configuración de diagnóstico para

Delete] registros de flujo de red.
Microsoft.Insights/LogDefinitions/Read Este permiso es necesario para los usuarios que necesitan

acceder a registros de actividades a través del portal.
Microsoft.Insights/LogProfiles/[Read, Write, Delete] Leer, escribir o eliminar perfiles de registro (registro de

actividad de streaming para la cuenta de almacenamiento o
centro de eventos).
Microsoft.Insights/MetricAlerts/[Read, Write, Delete] Leer, escribir o eliminar alertas de métricas casi en tiempo real
Microsoft.Insights/MetricDefinitions/Read Leer definiciones de métrica (lista de tipos de métricas

disponibles para un recurso).
Microsoft.Insights/Metrics/Read Leer las métricas de un recurso.
Microsoft.Insights/Register/Action Registrar el proveedor de recursos de Azure Monitor.
Microsoft.Insights/ScheduledQueryRules/[Read, Write, Delete] Lea, escriba o elimine alertas de registro en Azure Monitor.
NOTE
El acceso a las alertas, la configuración de diagnóstico y las métricas de un recurso requiere que el usuario tenga acceso de
lectura al tipo de recurso y el ámbito de ese recurso. La definición (“escritura”) de una configuración de diagnóstico o un
perfil de registro que se archiva en una cuenta de almacenamiento o se transmite a centros de eventos requiere que el
usuario tenga también el permiso ListKeys en el recurso de destino.
Por ejemplo, mediante la tabla anterior se podría crear un rol de Azure personalizado para un "lector de registro
de actividades" similar al siguiente:
$role = Get-AzRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Activity Log Reader"
$role.Description = "Can view activity logs."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Insights/eventtypes/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/mySubscription")
New-AzRoleDefinition -Role $role
Consideraciones de seguridad para datos de supervisión

Los datos de supervisión, en particular los archivos de registro, pueden obtener información confidencial, como
los nombres de usuario o las direcciones IP. Los datos de supervisión de Azure se presentan en tres formatos
básicos:
1. El registro de actividades, que describe todas las acciones de plano de control en su suscripción de Azure.
2. Los registros de recursos, que son registros emitidos por un recurso.
3. Métricas, que emiten los recursos.
Estos tres tipos de datos pueden almacenarse en una cuenta de almacenamiento o transmitirse a un centro de
eventos, y ambos son recursos de Azure de uso general. Dado que son recursos de uso general, su creación,
eliminación o el acceso a ellos constituyen una operación privilegiada reservada a un administrador. Se
recomienda utilizar los procedimientos siguientes para recursos relacionados con la supervisión para impedir el
uso indebido:
Utilizar una cuenta de almacenamiento dedicada a datos de supervisión. Si necesita separar los datos de
supervisión en varias cuentas de almacenamiento, nunca comparta el uso de una cuenta de almacenamiento
entre los datos de supervisión ni de otro tipo, ya que se podría conceder acceso accidentalmente a datos no
relacionados con la supervisión a aquellos que solo necesitan tener acceso a datos que no son de supervisión
(por ejemplo, SIEM de terceros).
Utilizar un espacio de nombres exclusivo y dedicado de Service Bus o Event Hubs en toda la configuración de
diagnóstico, por la misma razón anterior.
Limitar el acceso a las cuentas de almacenamiento o a centros de eventos relacionados con la supervisión,
manteniéndolos en un grupo de recursos independiente y utilizar el ámbito en los roles de supervisión para
limitar el acceso a ese grupo de recursos exclusivamente.
No conceder nunca el permiso ListKeys para las cuentas de almacenamiento o los centros de eventos en el
ámbito de la suscripción cuando un usuario solo necesita acceso a los datos de supervisión. En su lugar,
conceder estos permisos al usuario en un ámbito de recurso o grupo de recursos (si tiene un grupo de
recursos de supervisión dedicado).
Restricción del acceso a cuentas de almacenamiento relacionadas con la supervisión
Cuando un usuario o aplicación necesita acceso a datos de supervisión en una cuenta de almacenamiento, debe
generar una SAS de la cuenta en la cuenta de almacenamiento que contenga los datos de supervisión con acceso
de solo lectura de nivel de servicio a Blob Storage. En PowerShell, podría quedar de manera similar a:
$context = New-AzStorageContext -ConnectionString "[connection string for your monitoring Storage Account]"
$token = New-AzStorageAccountSASToken -ResourceType Service -Service Blob -Permission "rl" -Context $context
Puede proporcionar el token a la entidad que necesita leer desde la cuenta de almacenamiento, y esta puede
enumerar y leer desde todos los blobs de dicha cuenta de almacenamiento.
O bien, si necesita controlar este permiso con RBAC, puede conceder a dicha entidad el permiso
Microsoft.Storage/storageAccounts/listkeys/action para esa cuenta de almacenamiento determinada. Esto es
necesario para los usuarios que necesitan tener la capacidad de definir una configuración de diagnóstico o un
perfil de registro a fin de archivar en una cuenta de almacenamiento. Por ejemplo, podría crear el siguiente rol de
Azure personalizado para un usuario o una aplicación que solo necesita leer desde una cuenta de
almacenamiento:

$role.Id = $null
$role.Name = "Monitoring Storage Account Reader"
$role.Description = "Can get the storage account keys for a monitoring storage account."
$role.Actions.Add("Microsoft.Storage/storageAccounts/listkeys/action")
$role.Actions.Add("Microsoft.Storage/storageAccounts/Read")
$role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.
Storage/storageAccounts/myMonitoringStorageAccount")
WARNING
El permiso ListKeys permite al usuario enumerar las claves de la cuenta de almacenamiento principal y secundaria. Estas
claves conceden al usuario todos los permisos firmados (leer, escribir, crear blobs, eliminar blobs, etc.) en todos los servicios
suscritos (blob, cola, tabla y archivo) en esa cuenta de almacenamiento. Se recomienda usar una SAS de cuenta, como se ha
descrito anteriormente, cuando sea posible.
Restricción del acceso a centros de eventos relacionados con la supervisión

Se puede seguir un patrón similar con los centros de eventos, pero primero debe crear una regla de autorización
de escucha dedicada. Si desea conceder acceso a una aplicación que solo necesita escuchar a centros de eventos
relacionados con la supervisión, haga lo siguiente:
1. Cree una directiva de acceso compartido en los centros de eventos que se crearon para streaming de
datos de supervisión con notificaciones de escucha exclusivamente. Esto se puede hacer en el portal. Por
ejemplo, podría llamarlo "monitoringReadOnly." Si es posible, debe proporcionar la clave directamente al
consumidor y omitir el paso siguiente.
2. Si el consumidor debe tener la capacidad de obtener la clave ad hoc, conceda al usuario la acción ListKeys
para ese centro de eventos. Esto es necesario para los usuarios que necesitan tener la capacidad de definir
una configuración de diagnóstico o un perfil de registro para realizar transmisiones a los centros de
eventos. Por ejemplo, podría crear una regla de RBAC:

$role.Id = $null
$role.Name = "Monitoring Event Hub Listener"
$role.Description = "Can get the key to listen to an event hub streaming monitoring data."
$role.Actions.Add("Microsoft.ServiceBus/namespaces/authorizationrules/listkeys/action")
$role.Actions.Add("Microsoft.ServiceBus/namespaces/Read")
$role.AssignableScopes.Add("/subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Mic
rosoft.ServiceBus/namespaces/mySBNameSpace")
Supervisión dentro de una red virtual protegida

Azure Monitor necesita acceso a los recursos de Azure para proporcionar los servicios que habilite. Si desea
supervisar los recursos de Azure a la vez que los protege del acceso a la red pública de Internet, puede habilitar la
configuración siguiente.
Cuentas de almacenamiento protegidas
Los datos de supervisión a menudo se escriben en una cuenta de almacenamiento. Es posible que desee
asegurarse de que los usuarios no autorizados no pueden tener acceso a los datos copiados en una cuenta de
almacenamiento. Para mayor seguridad, puede bloquear el acceso de red para permitir que solo los recursos
autorizados y los servicios de confianza de Microsoft accedan a una cuenta de almacenamiento mediante la
restricción del uso de "redes seleccionadas" por parte de una cuenta de almacenamiento.
Azure Monitor se considera uno de

estos "servicios de confianza de Microsoft" Si permite que los servicios de confianza de Microsoft tengan acceso
al almacenamiento protegido, Azure Monitor tendrá acceso a su cuenta de almacenamiento protegida,
permitiendo la escritura de los registros de recursos de Azure Monitor, del registro de actividad y de las métricas
en la cuenta de almacenamiento según estas condiciones protegidas. Esto también permitirá que Log Analytics
lea los registros de almacenamiento protegido.
Para obtener más información, consulte Seguridad de red y Azure Storage.
Pasos siguientes
Consulte información sobre RBAC y permisos en Resource Manager
Lea la información general sobre supervisión en Azure
Direcciones IP que emplean Application Insights
y Log Analytics
El servicio Azure Application Insights usa diversas direcciones IP. Quizás deba conocer estas direcciones
si la aplicación que está supervisando se hospeda bajo el amparo de un firewall.
NOTE
Aunque estas direcciones son estáticas, es posible que tengamos que cambiarlas de vez en cuando. Todo el
tráfico de Application Insights representa el tráfico saliente a excepción de la supervisión de la disponibilidad y los
webhooks, que requieren reglas de firewall de entrada.
TIP
Puede usar etiquetas de servicio de red de Azure para administrar el acceso si usa grupos de seguridad de red de
Azure. Si administra el acceso para recursos híbridos o locales, puede descargar las listas de direcciones IP
equivalentes como archivos JSON, que se actualizan cada semana. Para cubrir todas las excepciones de este
artículo, debería usar las etiquetas de servicio: 'ActionGroup', 'ApplicationInsightsAvailability' y 'AzureMonitor'.
También se puede suscribir a esta página como fuente RSS. Para ello, agregue
https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/azure-monitor/app/ip-
addresses.md.atom a su lector RSS/ATOM favorito para recibir notificaciones sobre los cambios más
recientes.
Puertos de salida
Debe abrir algunos puertos de salida en el firewall del servidor para permitir que el SDK de Application
Insights o el Monitor de estado envíe datos al portal:
P RO P Ó SITO URL IP P UERTO S

Telemetría dc.applicationinsights.azu 40.114.241.141 443

re.com 104.45.136.42
dc.applicationinsights.mic 40.84.189.107
rosoft.com 168.63.242.221
dc.services.visualstudio.co 52.167.221.184
m 52.169.64.244
40.85.218.175
104.211.92.54
52.175.198.74
51.140.6.23
40.71.12.231
13.69.65.22
13.78.108.165
13.70.72.233
20.44.8.7
13.86.218.248
40.79.138.41
52.231.18.241
13.75.38.7
102.133.155.50
52.162.110.67
191.233.204.248
13.69.66.140
13.77.52.29
51.107.59.180
40.71.12.235
20.44.8.10
40.71.13.169
13.66.141.156
40.71.13.170
13.69.65.23
20.44.17.0
20.36.114.207
51.116.155.246
51.107.155.178
51.140.212.64
13.86.218.255
Secuencia de métricas en live.applicationinsights.az 23.96.28.38 443

directo ure.com 13.92.40.198
rt.applicationinsights.micr 40.112.49.101
osoft.com 40.117.80.207
rt.services.visualstudio.co 157.55.177.6
m 104.44.140.84
104.215.81.124
23.100.122.113
Monitor de estado
Configuración del Monitor de estado; solo lo necesitará en caso de que tenga que hacer cambios.
Configuración management.core.windows.net 443
Configuración management.azure.com 443
Configuración login.windows.net 443

Configuración login.microsoftonline.com 443
Configuración secure.aadcdn.microsoftonline- 443

p.com
Configuración auth.gfx.ms 443
Configuración login.live.com 443
Instalación globalcdn.nuget.org , 443

packages.nuget.org ,
api.nuget.org/v3/index.json
nuget.org ,
api.nuget.org ,
dc.services.vsallin.net
Pruebas de disponibilidad
Esta es la lista de direcciones a partir de las cuales se ejecutan pruebas web de disponibilidad . Si quiere
ejecutar pruebas web en su aplicación, pero su servidor web está restringido atender únicamente las
solicitudes de clientes específicos, tendrá que permitir el tráfico entrante de nuestros servidores de
pruebas de disponibilidad.
Etiqueta de servicio
Si usa grupos de seguridad de red de Azure, basta con agregar una regla de puer to de entrada para
permitir el tráfico de las pruebas de disponibilidad de Application Insights. Para ello, seleccione Etiqueta
de ser vicio como Origen y ApplicationInsightsAvailability como Etiqueta de ser vicio de
origen .
Abra los puertos 80 (http) y 443 (https) para asumir el tráfico entrante de estas direcciones (las IP se
agrupan por ubicación):
Direcciones agrupadas por ubicación
NOTE
Estas direcciones IP se indican mediante la notación de Enrutamiento de interdominios sin clases (CIDR). Esto
significa que una entrada como 51.144.56.112/28 es equivalente a 16 direcciones IP que comienzan en
51.144.56.112 y terminan en 51.144.56.127 .
Australia East
20.40.124.176/28
20.40.124.240/28
20.40.125.80/28
Brazil South
191.233.26.176/28
191.233.26.128/28
191.233.26.64/28
France Central (Formerly France South)

20.40.129.96/28
20.40.129.112/28
20.40.129.128/28
20.40.129.144/28
France Central
20.40.129.32/28
20.40.129.48/28
20.40.129.64/28
20.40.129.80/28
East Asia
52.229.216.48/28
52.229.216.64/28
52.229.216.80/28
North Europe
52.158.28.64/28
52.158.28.80/28
52.158.28.96/28
52.158.28.112/28
Japan East
52.140.232.160/28
52.140.232.176/28
52.140.232.192/28
West Europe
51.144.56.96/28
51.144.56.112/28
51.144.56.128/28
51.144.56.144/28
51.144.56.160/28
51.144.56.176/28
UK South
51.105.9.128/28
51.105.9.144/28
51.105.9.160/28
UK West
20.40.104.96/28
20.40.104.112/28
20.40.104.128/28
20.40.104.144/28
Southeast Asia
52.139.250.96/28
52.139.250.112/28
52.139.250.128/28
52.139.250.144/28
West US
40.91.82.48/28
40.91.82.64/28
40.91.82.80/28
40.91.82.96/28
40.91.82.112/28
40.91.82.128/28
Central US
13.86.97.224/28
13.86.97.240/28
13.86.98.48/28
13.86.98.0/28
13.86.98.16/28
13.86.98.64/28
North Central US
23.100.224.16/28
23.100.224.32/28
23.100.224.48/28
23.100.224.64/28
23.100.224.80/28
23.100.224.96/28
23.100.224.112/28
23.100.225.0/28
South Central US
20.45.5.160/28
20.45.5.176/28
20.45.5.192/28
20.45.5.208/28
20.45.5.224/28
20.45.5.240/28
East US
20.42.35.32/28
20.42.35.64/28
20.42.35.80/28
20.42.35.96/28
20.42.35.112/28
20.42.35.128/28
Azure US Government (Not needed if you are an Azure Public cloud customer)
20.140.48.160/27
20.140.56.160/27
20.140.64.160/27
20.140.72.160/27
52.127.49.96/27
API de Application Insights y Log Analytics

P RO P Ó SITO URI IP P UERTO S
API api.applicationinsights.io20.37.52.188 80 443

20.37.53.231
api1.applicationinsights.io
20.36.47.130
20.40.124.0
20.43.99.158
20.43.98.234
13.70.127.61
dev.applicationinsights.io
40.81.58.225
dev.applicationinsights.microsoft.com
20.40.160.120
dev.aisvc.visualstudio.com23.101.225.155
www.applicationinsights.io52.139.8.32
13.88.230.43
www.applicationinsights.microsoft.com
www.aisvc.visualstudio.com52.230.224.237
api.loganalytics.io 52.242.230.209
*.api.loganalytics.io 52.173.249.138
dev.loganalytics.io
52.229.218.221
52.229.225.6
docs.loganalytics.io
23.100.94.221
www.loganalytics.io
52.188.179.229
52.226.151.250
52.150.36.187
40.121.135.131
20.44.73.196
20.41.49.208
40.70.23.205
20.40.137.91
20.40.140.212
40.89.189.61
52.155.118.97
52.156.40.142
23.102.66.132
52.231.111.52
52.231.108.46
52.231.64.72
52.162.87.50
23.100.228.32
40.127.144.141
52.155.162.238
137.116.226.81
52.185.215.171
40.119.4.128
52.171.56.178
20.43.152.45
20.44.192.217
13.67.77.233
51.104.255.249
51.104.252.13
51.143.165.22
13.78.151.158
51.105.248.23
40.74.36.208
40.74.59.40
13.93.233.49
52.247.202.90
Extensión de anotaciones aigs1.aisvc.visualstudio.co dinámico 443

de Azure Pipelines m
Application Insights Analytics

Portal de Analytics analytics.applicationinsigh dinámico 80 443

ts.io
CDN applicationanalytics.azure dinámico 80 443

edge.net
Medios + CDN applicationanalyticsmedia. dinámico 80 443

azureedge.net
Nota: el dominio *.applicationinsights.io es propiedad del equipo de Application Insights.
Portal de Log Analytics

Portal portal.loganalytics.io dinámico 80 443
CDN applicationanalytics.azure dinámico 80 443

edge.net
Nota: El dominio *.loganalytics.io pertenece al equipo de Log Analytics.
Extensión de Application Insights de Azure Portal

Extensión de Application stamp2.app.insightsportal dinámico 80 443

Insights .visualstudio.com
CDN de la extensión insightsportal-prod2- dinámico 80 443

Application Insights cdn.aisvc.visualstudio.com
insightsportal-prod2-
asiae-
cdn.aisvc.visualstudio.com
insightsportal-cdn-
aimon.applicationinsights.
io
SDK de Application Insights

CDN del SDK de JS de az416426.vo.msecnd.net dinámico 80 443

Webhooks de grupo de acciones

P RO P Ó SITO IP P UERTO S
P RO P Ó SITO IP P UERTO S
Alertas 13.72.19.232 443

13.106.57.181
13.106.54.3
13.106.54.19
13.106.38.142
13.106.38.148
13.106.57.196
13.106.57.197
52.244.68.117
52.244.65.137
52.183.31.0
52.184.145.166
51.4.138.199
51.5.148.86
51.5.149.19
Agente agent.azureserviceprofiler. 20.190.60.38 443

net 20.190.60.32
*.agent.azureserviceprofil 52.173.196.230
er.net 52.173.196.209
23.102.44.211
23.102.45.216
13.69.51.218
13.69.51.175
138.91.32.98
138.91.37.93
40.121.61.208
40.121.57.2
51.140.60.235
51.140.180.52
52.138.31.112
52.138.31.127
104.211.90.234
104.211.91.254
13.70.124.27
13.75.195.15
52.185.132.101
52.185.132.170
20.188.36.28
40.89.153.171
52.141.22.239
52.141.22.149
102.133.162.233
102.133.161.73
191.232.214.6
191.232.213.239
Portal gateway.azureserviceprofi dinámico 443

ler.net
Storage *.core.windows.net dinámico 443
NOTE
El generador de perfiles y Snapshot Debugger comparten el mismo conjunto de direcciones IP.
Agente ppe.azureserviceprofiler.n 20.190.60.38 443

et 20.190.60.32
*.ppe.azureserviceprofiler. 52.173.196.230
net 52.173.196.209
23.102.44.211
23.102.45.216
13.69.51.218
13.69.51.175
138.91.32.98
138.91.37.93
40.121.61.208
40.121.57.2
51.140.60.235
51.140.180.52
52.138.31.112
52.138.31.127
104.211.90.234
104.211.91.254
13.70.124.27
13.75.195.15
52.185.132.101
52.185.132.170
20.188.36.28
40.89.153.171
52.141.22.239
52.141.22.149
102.133.162.233
102.133.161.73
191.232.214.6
191.232.213.239
Portal ppe.gateway.azureservice dinámico 443

profiler.net
Storage *.core.windows.net dinámico 443

Supervisión del uso y costos estimados en Azure
Monitor
NOTE
En este artículo se describe cómo ver el uso y los costos estimados a través de varias características de supervisión de Azure.
Los artículos relacionados con componentes específicos de Azure Monitor incluyen:
En Administrar el uso y los costos con los registros de Azure Monitor se describe cómo controlar los costos cambiando el
período de retención de datos y cómo analizar y alertar sobre el uso de los datos.
En Administración del uso y los costos de Application Insights se describe cómo analizar el uso de datos en Application
Insights.
Modelo de precios de Azure Monitor

El modelo de facturación básico de Azure Monitor consta de precios basados en la nube y el consumo ("pago por
uso"). Pague solo por lo que usa. Hay detalles disponibles sobre los precios para alertas, métricas y notificaciones,
Log Analytics y Application Insights.
Además del modelo de pago por uso para los datos de registros, Log Analytics tiene niveles de Reserva de
capacidad que le permiten ahorrar hasta un 25 % en comparación con el precio de pago por uso. Los precios de la
reserva de capacidad permiten comprar una reserva a partir de 100 GB/día. Cualquier uso por encima del nivel de
reserva se facturará según la tarifa de pago por uso. Obtenga más información sobre los precios de la reserva de
capacidad.
Algunos clientes tendrán acceso a los planes de tarifa de Log Analytics heredados y el plan de tarifa de Enterprise
Application Insights heredado.
Información sobre los costos de Azure Monitor

Hay dos fases para comprender los costos. La primera es al momento de plantearse Azure Monitor como solución
de supervisión.
Estimación de los costos de administración del entorno
Si aún no usa los registros de Azure Monitor, puede usar la calculadora de precios de Azure Monitor para calcular
el costo del uso de Azure Monitor. Comience por escribir "Azure Monitor" en el cuadro de búsqueda y haga clic en
el icono de Azure Monitor resultante. Desplácese hacia abajo en la página hasta Azure Monitor y seleccione una de
las opciones de la lista desplegable Tipo:
Consultas y alertas de métricas
Log Analytics
En cada una de ellas, la calculadora de precios le ayudará a calcular los costos más probables en función del uso
esperado.
Por ejemplo, con Log Analytics puede especificar el número de máquinas virtuales y los GB de datos que espera
recopilar de cada máquina virtual. Normalmente se ingieren de 1 GB a 3 GB de datos al mes en una máquina
virtual típica de Azure. Si ya está evaluando los registros de Azure Monitor, puede usar las estadísticas de datos de
su propio entorno. Consulte a continuación cómo determinar el número de máquinas virtuales supervisadas y el
volumen de los datos que ingiere el área de trabajo.
De igual forma, para Application Insights, si habilita la funcionalidad "Estimar el volumen de datos en función de la
actividad de la aplicación", puede proporcionar entradas sobre la aplicación (solicitudes por mes y vistas de página
al mes, en caso de que se recopile la telemetría del lado cliente) y, a continuación, la calculadora le indicará el valor
medio y la cantidad de percentil 90 de los datos recopilados por aplicaciones similares. Estas aplicaciones abarcan
el intervalo de configuración de Application Insights (por ejemplo, algunas tienen el muestreo predeterminado,
otras no tienen muestreo, etc.), por lo que todavía tiene el control para reducir el volumen de datos que ingiere
muy por debajo del nivel medio con muestreo. Pero se trata de un punto de partida para comprender lo que ven
otros clientes similares. Más información sobre la estimación de costos de Application Insights.
Información sobre el uso y los costos estimados
Es importante comprender y hacer un seguimiento del uso una vez que comience a usar Azure Monitor y hay un
conjunto completo de herramientas para facilitar esta tarea.
Azure proporciona una gran cantidad de funcionalidades útiles en el centro Azure Cost Management +
Facturación. Después de abrir el centro Azure Cost Management y facturación , haga clic en Cost
Management y seleccione el ámbito (el conjunto de recursos que se van a investigar).
A continuación, para consultar los costos de Azure Monitor de los últimos 30 días, haga clic en el icono Costos
diarios , elija "Últimos 30 días" en Fechas relativas y agregue un filtro que seleccione los nombres de servicio:
1. Azure Monitor
2. Application Insights
3. Log Analytics
4. Insight and Analytics
Esto da como resultado una vista como la siguiente:
Desde aquí, puede profundizar en este resumen de costos acumulados para obtener detalles más precisos en la
vista "Costo por recurso". En los planes de tarifa actuales, los datos de registro de Azure se cobran según el mismo
conjunto de medidores independientemente de si se originan en Log Analytics o Application Insights. Para separar
los costos del uso de Log Analytics o Application Insights, puede agregar un filtro en Tipo de recurso . Para ver
todos los costos de Application Insights, filtre el tipo de recurso por "microsoft.insights/components", y para los
costos de Log Analytics, filtre el tipo de recurso por "microsoft.operationalinsights/workspaces".
Puede consultar más detalles sobre el uso mediante la descarga del uso desde Azure Portal. En la hoja de cálculo
descargada puede ver el uso por recurso de Azure al día. En esta hoja de cálculo de Excel, el uso de los recursos de
Application Insights se puede encontrar filtrando, en primer lugar, la columna "Categoría de medición" para
mostrar "Application Insights" y "Log Analytics" y, a continuación, agregando un filtro en la columna "Id. de
instancia", que es "contiene microsoft.insights/components". La mayor parte del uso de Application Insights se
muestra en medidores con la Categoría de medición de Log Analytics, ya que hay un back-end de registros único
para todos los componentes de Azure Monitor. Con una Categoría de medición de Application Insights, solo se
muestran recursos de Application Insights de los planes de tarifa heredados y las pruebas web de varios pasos. El
uso se muestra en la columna "Cantidad consumida" y la unidad de cada entrada se muestra en la columna
"Unidad de medida". Hay más detalles disponibles para ayudarle a entender la factura de Microsoft Azure.
NOTE
El uso de Cost Management en el centro de Administración de costos y facturación de Azure es el mejor método
para comprender de forma general los costos de supervisión. Las experiencias de Uso y costos estimados de Log
Analytics y Application Insights proporcionan información más detallada sobre cada una de las partes de Azure Monitor.
Otra opción para ver el uso de Azure Monitor es la página de Uso y costos estimados en el centro de
supervisión. Esto muestra el uso de características de supervisión principales como alertas, métricas,
notificaciones, Azure Log Analytics y Azure Application Insights. Para los clientes en los planes de precios
disponibles antes de abril de 2018, esto también incluye el uso de Log Analytics adquirido a través de la oferta
Insights y Analytics.
En esta página, los usuarios pueden ver el uso de sus recursos durante los últimos 31 días, agregados por
suscripción. Drill-ins muestra las tendencias de uso durante el período de 31 días. Es necesario que una gran
cantidad de datos se reúna para este cálculo, por lo que agradecemos su paciencia mientras se carga la página.
En este ejemplo se muestra la supervisión del uso y una estimación de los costos resultantes:
Seleccione el vínculo de la columna de uso mensual para abrir un gráfico que muestra las tendencias de uso en el
último período de 31 días:
Derechos de suscripción de Operations Management Suite
Los clientes que compraron Microsoft Operations Management Suite E1 y E2 son aptos para los derechos de
ingesta de datos por nodo para Log Analytics y Application Insights. Para recibir estos derechos para las áreas de
trabajo de Log Analytics o los recursos de Application Insights en una suscripción determinada:
Las áreas de trabajo de Log Analytics deben usar el plan de tarifa "por nodo (OMS)".
Los recursos de Application Insights deben utilizar el plan de tarifa "Enterprise".
En función del número de nodos del conjunto de aplicaciones que adquiriera la organización, puede ser de
utilidad mover alguna suscripción al plan de tarifa de pago por uso (por GB), pero le recomendamos que antes lo
piense detenidamente.
WARNING
Si su organización tiene las Microsoft Operations Management Suite E1 y E2 actuales, normalmente es mejor mantener sus
áreas de trabajo de Log Analytics en el plan de tarifa "por nodo (OMS)" y los recursos de Application Insights en el plan de
tarifa "Enterprise".
Administración del uso y los costos de Application
Insights
NOTE
En este artículo se describe cómo entender y controlar los costos de Application Insights. En un artículo relacionado,
Supervisión del uso y costos estimados, se describe cómo ver el uso y los costos estimados mediante varias
características de supervisión de Azure para los distintos modelos de precios.
Application Insights está diseñado para obtener todo lo que necesita para supervisar la disponibilidad, el
rendimiento y el uso de las aplicaciones web, tanto si están hospedadas en Azure como en un entorno local.
Application Insights admite lenguajes y plataformas populares, como .NET, Java y Node.js, y se integra con
procesos y herramientas DevOps como Azure DevOps, Jira y PagerDuty. Es importante comprender lo que
determina los costos de la supervisión de aplicaciones. En este artículo se revisan los costos de supervisión
de las aplicaciones y cómo puede supervisarlas y controlarlas de forma activa.
Si tiene preguntas sobre cómo funcionan los precios para Application Insights, no dude en publicar una
pregunta en nuestra página de preguntas y respuestas de Microsoft.
Modelo de precios
Los precios de Azure Application Insights son de un modelo de pago por uso , que se basa en el volumen de
datos ingeridos y, opcionalmente, para obtener una mayor retención de datos. Cada recurso de Application
Insights se cobra como un servicio independiente y contribuye a la factura de la suscripción a Azure. El
volumen de datos se mide como el tamaño del paquete de datos JSON sin comprimir que recibe Application
Insights de su aplicación. No hay ningún cargo por volumen de datos para usar Live Metrics Stream.
Las pruebas web de varios pasos conllevan un cargo adicional. Las pruebas web de varios pasos son pruebas
web que realizan una secuencia de acciones. No hay ningún cargo aparte para las pruebas de ping de una
sola página. La telemetría de las pruebas de ping y de las de varios pasos se carga igual que el resto de la
telemetría de su aplicación.
La opción Application Insights para Habilitar la creación de alertas sobre las dimensiones de las métricas
personalizadas también puede generar costos adicionales, ya que puede dar lugar a la creación de métricas
de agregación previas adicionales. Obtenga más información sobre las métricas basadas en registro y las
agregadas previamente en Application Insights y sobre los precios para las métricas personalizadas de Azure
Monitor.
Application Insights basado en áreas de trabajo
En el caso de los recursos de Application Insights que envían sus datos a un área de trabajo de Log Analytics,
denominada recursos de Application Insights basados en áreas de trabajo, la facturación de la ingesta y
retención de datos se realiza en el área de trabajo donde se encuentran los datos de Application Insights. Esto
permite a los clientes aprovechar todas las opciones del modelo de precios de Log Analytics, que incluye
Reservas de capacidad además de Pago por uso. Log Analytics también tiene más opciones para la retención
de datos, incluida la retención por tipo de datos. Los tipos de datos de Application Insights en el área de
trabajo obtienen 90 días de retención sin cargos. El uso de las pruebas web y la habilitación de las alertas
sobre las dimensiones de la métrica personalizada todavía se notifica a través de Application Insights.
Obtenga información sobre cómo realizar un seguimiento de los costos de retención y de ingesta de datos en
Log Analytics mediante el Uso y costos estimados, Administración de costos + facturación de Azure y
Consultas de Log Analytics.
Estimación de los costos de administración de la aplicación

Si aún no usa Application Insights, puede usar la calculadora de precios de Azure Monitor para calcular el
costo del uso de Application Insights. Comience por escribir "Azure Monitor" en el cuadro de búsqueda y
haga clic en el icono de Azure Monitor resultante. Desplácese hacia abajo en la página hasta Azure Monitor y
seleccione Application Insights en la lista desplegable Tipo. Aquí puede especificar el número de GB de datos
que espera recopilar al mes, por lo que la pregunta es cuántos datos recopilará Application Insights
supervisando la aplicación.
Hay dos enfoques para abordar esta cuestión: usar la supervisión predeterminada y el muestreo adaptable,
que está disponible en el SDK de ASP.NET, o calcular la probable ingesta de datos en función de lo que han
visto otros clientes similares.
Colección de datos al usar el muestreo
Con el muestreo adaptable del SDK de ASP.NET, el volumen de datos se ajusta automáticamente para
mantener una velocidad de tráfico máxima específica para la supervisión predeterminada de Application
Insights. Si la aplicación genera una cantidad baja de telemetría, como al depurar o debido a un uso bajo, el
procesador de muestreo no podrá descargar los elementos mientras el volumen se encuentre por debajo del
nivel configurado de eventos por segundo. En el caso de una aplicación de gran volumen, con el umbral
predeterminado de cinco eventos por segundo, el muestreo adaptable limitará el número de eventos diarios
a 432 000. Con un tamaño de evento promedio típico de 1 KB, corresponde a 13,4 GB de telemetría por mes
de 31 días por nodo que hospeda la aplicación (ya que el muestreo se realiza de forma local en cada nodo).
En el caso de los SDK que no admiten el muestreo adaptable, puede emplear el muestreo de ingesta, que
toma muestras cuando Application Insights recibe los datos en función de un porcentaje de datos que se
deben conservar, o el muestreo de frecuencia fija para sitios web ASP.NET, ASP.NET Core y Java para reducir el
tráfico enviado desde el servidor web y los exploradores web.
Más información sobre qué recopilan los clientes similares
En la calculadora de precios de Azure Monitor para Application Insights, si habilita la funcionalidad "Estimar el
volumen de datos en función de la actividad de la aplicación", puede proporcionar entradas sobre la
aplicación (solicitudes por mes y vistas de página al mes, en caso de que se recopile la telemetría del lado
cliente) y, a continuación, la calculadora le indicará el valor medio y la cantidad de percentil 90 de los datos
recopilados por aplicaciones similares. Estas aplicaciones abarcan el intervalo de configuración de Application
Insights (por ejemplo, algunas tienen el muestreo predeterminado, otras no tienen muestreo, etc.), por lo que
todavía tiene el control para reducir el volumen de datos que ingiere muy por debajo del nivel medio con
muestreo. Pero se trata de un punto de partida para comprender lo que ven otros clientes similares.
Información útil del uso y los costos estimados

Application Insights permite entender fácilmente cuáles serán los costos en función de patrones de uso
reciente. Para comenzar, en Azure Portal, en el recurso de Application Insights, vaya a la página Uso y costos
estimados :
A. Revise el volumen de datos para el mes. Esto incluye todos los datos recibidos y retenidos (después de
cualquier muestreo) de las aplicaciones de servidor y cliente, y de las pruebas de disponibilidad.
B. Se realiza un cargo adicional para las pruebas web de varios pasos. (Esto no incluye pruebas de
disponibilidad simples, que se incluyen en la carga de volumen de datos).
C. Vea las tendencias de volumen de datos durante el mes anterior.
D. Habilite el muestreo de ingesta de datos. E. Establezca el límite de volumen de datos diario.
(Tenga en cuenta que todos los precios mostrados en las capturas de pantalla de este artículo son solo con
fines de ejemplo. Para ver los precios vigentes actualmente en su moneda y región, consulte Precios de
Application Insights).
Para investigar el uso de Application Insights con más detalle, abra la página Métricas , agregue la métrica
denominada "Volumen de puntos de datos" y, después, seleccione la opción Aplicar división para dividir los
datos por "Tipo de elemento de telemetría".
Los cargos de Application Insights se agregarán a la factura de Azure. Puede ver los detalles de su factura de
Azure en la sección Cost Management + facturación de Azure Portal o en el Portal de facturación de
Azure. Vea más abajo para obtener información detallada sobre el uso de esto para Application Insights.
Uso de métricas de volumen de datos

Para obtener más información sobre los volúmenes de datos, seleccione Métricas para el recurso de
Application Insights y agregue un nuevo gráfico. En la métrica del gráfico, en Métricas basadas en
registros , seleccione Volumen de puntos de datos . Haga clic en Aplicar separación y seleccione el
grupo mediante el tipo Telemetryitem .
Consultas para comprender los detalles del volumen de datos

Existen dos enfoques para investigar los volúmenes de datos de Application Insights. El primero utiliza la
información agregada en la tabla systemEvents y el segundo usa la propiedad _BilledSize , que está
disponible en cada evento ingerido. systemEvents no tendrá información sobre el tamaño de datos para
Application Insights basado en el área de trabajo.
Uso de información del volumen de datos agregados
Por ejemplo, puede usar la tabla systemEvents para ver el volumen de datos ingerido en las últimas 24 horas
con la consulta:
systemEvents
| where type == "Billing"
| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes)
O bien, para ver un gráfico de volumen de datos (en bytes) por tipo de datos de los últimos 30 días, puede
usar:
systemEvents
| where timestamp >= startofday(ago(30d))
| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])
| summarize sum(BillingTelemetrySizeInBytes) by BillingTelemetryType, bin(timestamp, 1d) | render
barchart
Tenga en cuenta que esta consulta se puede usar en una alerta de registro de Azure para configurar las
alertas en los volúmenes de datos.
Para más información sobre los cambios en los datos de telemetría, se puede obtener el número de eventos
por tipo mediante la consulta:
systemEvents
| summarize count() by BillingTelemetryType, bin(timestamp, 1d)
| render barchart
Uso de la información de tamaño de datos por evento

Para más información sobre el origen de los volúmenes de datos, puede usar la propiedad _BilledSize que
se encuentra en cada evento ingerido.
Por ejemplo, para ver qué operaciones generan el mayor volumen de datos en los últimos 30 días, se puede
sumar _BilledSize de todos los eventos de dependencia:
dependencies
| summarize sum(_BilledSize) by operation_Name
| render barchart
Volumen de datos para recursos de Application Insights basados en áreas de trabajo

Para ver las tendencias de volumen de datos de todos los recursos de Application Insights basados en el área
de trabajo en un área de trabajo durante la última semana, vaya al área de trabajo Log Analytics y ejecute la
consulta siguiente:
union (AppAvailabilityResults),
(AppBrowserTimings),
(AppDependencies),
(AppExceptions),
(AppEvents),
(AppMetrics),
(AppPageViews),
(AppPerformanceCounters),
(AppRequests),
(AppSystemEvents),
(AppTraces)
| where TimeGenerated >= startofday(ago(7d) and TimeGenerated < startofday(now())
| summarize sum(_BilledSize) by _ResourceId, bin(TimeGenerated, 1d)
| render areachart
Para consultar las tendencias de volumen de datos por tipo para un recurso de Application Insights basado en
un área de trabajo específica, use lo siguiente en el área de trabajo Log Analytics:
union (AppAvailabilityResults),
(AppBrowserTimings),
(AppDependencies),
(AppExceptions),
(AppEvents),
(AppMetrics),
(AppPageViews),
(AppPerformanceCounters),
(AppRequests),
(AppSystemEvents),
(AppTraces)
| where TimeGenerated >= startofday(ago(7d) and TimeGenerated < startofday(now())
| where _ResourceId contains "<myAppInsightsResourceName>"
| summarize sum(_BilledSize) by Type, bin(TimeGenerated, 1d)
| render areachart
Visualización del uso de Application Insights en la factura de Azure
Facturación. Por ejemplo, la funcionalidad de "Análisis de costos" le permite ver los gastos de los recursos de
Azure. Al agregar un filtro por tipo de recurso (en microsoft.insights/components para Application Insights),
podrá realizar un seguimiento de los gastos. Después, para "Agrupar por", seleccione "Categoría del medidor"
o "Medidor". Para los recursos de Application Insights de los planes de precios actuales, la mayoría del uso se
mostrará como Log Analytics de la Categoría del medidor, ya que hay un back-end de registros único para
todos los componentes de Azure Monitor.
Puede obtener información sobre el uso mediante la descarga del uso desde Azure Portal. En la hoja de
cálculo descargada puede ver el uso por recurso de Azure al día. En esta hoja de cálculo de Excel, el uso de los
recursos de Application Insights se puede encontrar filtrando, en primer lugar, la columna "Categoría de
medición" para mostrar "Application Insights" y "Log Analytics" y, a continuación, agregando un filtro en la
columna "Id. de instancia", que es "contiene microsoft.insights/components". La mayor parte del uso de
Application Insights se muestra en medidores con la Categoría de medición de Log Analytics, ya que hay un
back-end de registros único para todos los componentes de Azure Monitor. Con una Categoría de medición de
Application Insights, solo se muestran recursos de Application Insights de los planes de tarifa heredados y las
pruebas web de varios pasos. El uso se muestra en la columna "Cantidad consumida" y la unidad de cada
entrada se muestra en la columna "Unidad de medida". Hay más detalles disponibles para ayudarle a
entender la factura de Microsoft Azure.
Administración del volumen de datos

El volumen de datos que envíe se puede administrar con las técnicas siguientes:
Muestreo : puede usar el muestreo para reducir la cantidad de telemetría enviada desde las
aplicaciones de servidor y de cliente, con mínima distorsión de las métricas. El muestreo es la principal
herramienta que puede usar para ajustar la cantidad de datos que envía. Obtenga más información
sobre las características de muestreo.
Limitar las llamadas Ajax : Puede limitar el número de llamadas Ajax que se pueden notificar en
cada vista de página o desactive los informes de Ajax.
Deshabilitar los módulos innecesarios : Edite ApplicationInsights.config para desactivar los
módulos de recopilación que no necesite. Por ejemplo, podría decidir que los contadores de
rendimiento o datos de dependencia no son esenciales.
Agregar métricas previamente : Si coloca llamadas a TrackMetric en su aplicación, puede reducir el
tráfico mediante la sobrecarga que acepta el cálculo de la media y la desviación estándar de un lote de
medidas. O bien, puede usar un paquete de agregación previa.
Límite diario : al crear un recurso de Application Insights en Azure Portal, el límite diario se establece
en 100 GB/día. Al crear un recurso de Application Insights en Visual Studio, la capacidad
predeterminada es pequeña (solo 32,3 MB/día). El límite diario predeterminado se establece para
facilitar las pruebas. El objetivo es que el usuario aumente el límite diario antes de implementar la
aplicación en producción.
El límite máximo es de 1,000 GB/día, a menos que solicite un máximo superior para una aplicación con
mucho tráfico.
Los correos electrónicos de advertencia sobre el límite diario se envían a cuentas que son miembros
de estos roles en el recurso de Application Insights: "ServiceAdmin", "AccountAdmin", "coadmin",
"Owner".
Tenga cuidado al establecer el límite diario. Su objetivo debe ser no alcanzar nunca el límite diario. Si lo
alcanza, perderá datos durante el resto del día y no podrá supervisar su aplicación. Para cambiar el
límite diario, use la opción Límite de volumen diario . Puede tener acceso a esta opción en el panel
Uso y costos estimados (se describe con más detalle más adelante en el artículo).
Hemos quitado la restricción en algunos tipos de suscripción con crédito que no se podía usar para
Application Insights. Anteriormente, si la suscripción tenía un límite de gasto, el cuadro de diálogo de
límite diario mostraba instrucciones sobre cómo quitarlo y habilitarlo para superar los 32,3 MB/día.
Limitación : la limitación restringe la velocidad de datos a 32 000 eventos por segundo, promediados
durante 1 minuto por clave de instrumentación. El volumen de datos que su aplicación envía se evalúa
cada minuto. Si se supera la tasa por segundo promediada por minuto, el servidor rechazará algunas
solicitudes. El SDK almacena en búfer los datos y, a continuación, intenta volver a enviarlos. Extiende
un aumento durante varios minutos. Si su aplicación envía de forma consistente un volumen de datos
que supera la tasa de limitación, es posible que algunos se eliminen (los SDK de ASP.NET, Java y
JavaScript intentan volver a enviarlos de esta manera; otros SDK pueden simplemente eliminar los
datos limitados). Si se produce la limitación, una notificación de advertencia le indica que esto ha
sucedido.
Administración del volumen de datos diario máximo

Puede usar el límite de volumen diario para restringir los datos recopilados. Sin embargo, si se alcanza el
límite, se producirá una pérdida de todas las telemetrías enviadas desde su aplicación durante el resto del día.
No es aconsejable hacer que su aplicación alcance el límite diario. No puede realizar un seguimiento del
estado y rendimiento de su aplicación una vez que alcance el límite diario.
En lugar de usar el límite de volumen diario, use el muestreo para ajustar el volumen de datos al nivel que
desee. A continuación, use el límite diario solo como "último recurso" en caso de que su aplicación empiece a
enviar de forma inesperada volúmenes de telemetría mucho más altos.
Identificación del límite diario de datos para definir
Revise el uso de Application Insights y los costos estimados para comprender la tendencia de ingesta de
datos y cuál es el límite de volumen diario que se va a definir. Se debe considerar con cuidado, ya que no
podrá supervisar los recursos una vez que se alcance el límite.
Establecer el límite diario
Para cambiar el límite diario, en la sección de Configuración del recurso de Application Insights, en la
página Uso y costos estimados , seleccione Límite diario .
Para cambiar el límite diario a través de Azure Resource Manager, la propiedad a cambiar es el dailyQuota . A
través de Azure Resource Manager también puede establecer dailyQuotaResetTime y el límite diario
warningThreshold .
Creación de alertas para el límite diario

El límite diario de Application Insights crea un evento en el registro de actividades de Azure cuando los
volúmenes de datos ingeridos alcanzan el nivel de advertencia o el nivel de límite diario. Puede crear una
alerta basada en estos eventos del registro de actividad. Los nombres de señal de estos eventos son:
Se alcanzó el umbral de advertencia de límite diario del componente Application Insights
Se alcanzó el límite diario del componente Application Insights
muestreo
El muestreo es un método que permite reducir la velocidad a la que se envían datos de telemetría a la
aplicación, al mismo tiempo que se conserva la capacidad de buscar eventos relacionados durante las
búsquedas de diagnósticos. También retiene recuentos de eventos correctos.
El muestreo es una manera efectiva de reducir los gastos y permanecer dentro de la cuota mensual. El
algoritmo de muestreo conserva elementos relacionados con la telemetría, de modo que, por ejemplo, al usar
Search se puede buscar la solicitud relacionada con una excepción determinada. El algoritmo también
conserva recuentos correctos, para que pueda ver en el Explorador de métricas los valores correctos de tasas
de solicitudes, tasas de excepciones y otros recuentos.
Existen varias formas de muestreo.
Muestreo adaptable es el valor predeterminado del SDK de ASP.NET. El muestreo adaptable se ajusta
automáticamente al volumen de telemetría que envía la aplicación. Funciona automáticamente en el SDK
de la aplicación web, de modo que se reduce el tráfico de telemetría en la red.
muestreo de ingesta es una opción alternativa que funciona en el momento en que la telemetría
procedente de su aplicación entra en el servicio Application Insights. El muestreo de ingesta no afecta al
volumen de telemetría que envía la aplicación, pero reduce el volumen que retiene el servicio. Puede
utilizar el muestreo de ingesta para reducir la cuota que utiliza la telemetría de exploradores y otros SDK.
Para establecer el muestreo de ingesta, vaya al panel Precios :
WARNING
El panel Muestreo de datos solo controla el valor de muestreo de ingesta. No refleja la velocidad de muestreo que
se aplica mediante el SDK de Application Insights en la aplicación. Si ya se ha muestreado la telemetría entrante en el
SDK, no se aplica el muestreo de ingesta.
Para conocer la frecuencia de muestreo real independientemente de dónde se ha aplicado, use una consulta
de Analytics. La consulta tiene este aspecto:
requests | where timestamp > ago(1d)

| summarize 100/avg(itemCount) by bin(timestamp, 1h)
| render areachart
En cada registro retenido, itemCount indica el número de registros originales que representa. Es igual a 1 +
el número de registros descartados anteriores.
Cambio del período de retención de datos

La retención predeterminada de los recursos de Application Insights es de 90 días. Es posible seleccionar
distintos períodos de retención para cada recurso de Application Insights. El conjunto completo de períodos
de retención disponibles es de 30, 60, 90, 120, 180, 270, 365, 550 o 730 días. Obtenga más información
sobre los precios de la retención de datos de mayor duración.
Para cambiar la retención, en el recurso de Application Insights, vaya a la página Uso y costos estimados y
seleccione la opción Retención de datos :
Cuando se reduce la retención, hay un período de gracia de varios días antes de que se quiten los datos más
antiguos.
La retención también se puede establecer mediante programación con PowerShell con el parámetro
retentionInDays . Si configura la retención de datos en 30 días, puede desencadenar una purga inmediata de
los datos más antiguos mediante el parámetro immediatePurgeDataOn30Days , que puede serle útil en los
escenarios relacionados con el cumplimiento. Esta funcionalidad de purga solo se expone con Azure Resource
Manager y debe utilizarse con extrema precaución. El tiempo de restablecimiento diario del extremo de
volumen de datos se puede configurar mediante Azure Resource Manager para establecer el parámetro
dailyQuotaResetTime .
Cargos por transferencia de datos al usar Application Insights

Al enviar datos a Application Insights se pueden aplicar ciertos cargos debido al ancho de banda de datos. Tal
como se describe en la página de precios de Azure Bandwidth, la transferencia de datos entre los servicios de
Azure ubicados en dos regiones se cobra como transferencia de datos salientes a precio normal. La
transferencia de datos entrantes es gratuita. Sin embargo, este cargo es muy pequeño (un tanto por ciento
mínimo) en comparación con los costos de la ingesta de datos de registro de Application Insights. En
consecuencia, para controlar los costos de Log Analytics, debe centrarse en el volumen de datos ingeridos;
para ello, le ofrecemos información aquí .
Resumen de límites
Hay algunos límites en el número de métricas y eventos por aplicación; es decir, por clave de instrumentación.
Los límites dependen del plan de precios que elija.
RESO URC E L ÍM IT E P REDET ERM IN A DO N OTA :
Total de datos por día 100 GB Se pueden reducir los datos si se

establece un límite. Si necesita más
datos, puede aumentar el límite en el
portal, hasta 1000 GB. Para
capacidades mayores de 1000 GB,
envíe un correo electrónico a
AIDataCap@microsoft.com.
Limitaciones 32 000 eventos por segundo El límite se mide por minuto.

Retención de datos Entre 30 y 730 días Este recurso es para Search, Analytics
y el Explorador de métricas.
Retención de resultados detallados 90 días Este recurso proporciona resultados

para la prueba de disponibilidad de detallados de cada paso.
varios pasos
Tamaño máximo de elementos de 64 KB

telemetría
Número máximo de elementos de 64 K

telemetría por lote
Longitud de nombres de propiedades 150 Consulte esquemas de tipos.

y métricas
Longitud de cadena del valor de 8192 Consulte esquemas de tipos.

propiedad
Longitud del mensaje de seguimiento 32 768 Consulte esquemas de tipos.

y excepción
Número de pruebas de disponibilidad 100

por aplicación
Retención de datos del generador de 5 días

perfiles
Datos enviados por día del generador 10 GB

de perfiles
Para más información, consulte Administración de precios y cuotas para Application Insights.
Deshabilitación de los correos electrónicos de límite diario

Para deshabilitar los correos electrónicos de límite de volumen diario, en la sección de Configuración del
recurso de Application Insights, en el panel Uso y costos estimados , seleccione Límite diario . Hay
opciones para enviar correos electrónicos cuando se alcanza el límite, así como cuando se ha alcanzado un
nivel de advertencia ajustable. Si quiere deshabilitar todos los correos electrónicos relacionados con el límite
de volumen diario, desactive ambas casillas.
Plan de tarifa de Enterprise heredado (por nodo)

Para los usuarios pioneros de Azure Application Insights, todavía hay dos planes de tarifa posibles: Básico y
Enterprise. El plan de tarifa Básico es el mismo que se describió anteriormente y es el predeterminado.
Incluye todas las características del plan Enterprise sin ningún coste adicional. En el nivel Básico, la facturación
se realiza principalmente en función del volumen de datos ingerido.
NOTE
Estos planes de tarifa heredados han cambiado de nombre. El plan de tarifa Enterprise ahora se llama Por nodo y el
plan de tarifa Básico ahora se llama Por GB . Estos nuevos nombres se usan a continuación y en Azure Portal.
El nivel Por nodo (anteriormente Enterprise) tiene un cargo por nodo y cada nodo recibe una concesión de
datos diaria. En el plan de tarifa Por nodo, se le cobrará por los datos ingeridos por encima de la concesión
incluida. Si usa Operations Management Suite, debería elegir el nivel Por nodo.
Para ver los precios vigentes actualmente en su moneda y región, consulte Precios de Application Insights.
NOTE
En abril de 2018, introdujimos un nuevo modelo de precios para la supervisión de Azure. Este modelo adopta un
modelo de "pago por uso" sencillo en toda la cartera de servicios de supervisión. Más información sobre el nuevo
modelo de precios, cómo evaluar el impacto de pasar a este modelo en función de los patrones de uso y cómo
participar en el nuevo modelo.
Derechos del nivel Por nodo y la suscripción a Operations Management Suite

Como se anunció anteriormente, los clientes que compran Operations Management Suite E1 y E2 pueden
obtener Application Insights Por nodo como componente adicional sin coste alguno. Específicamente, cada
unidad de Operations Management Suite E1 y E2 incluye el derecho de usar un nodo del nivel Application
Insights Por nodo. Cada nodo de Application Insights incluye hasta 200 MB de datos ingeridos por día
(independientes de la ingesta de datos de Log Analytics), con la retención de datos de 90 días sin costo
adicional alguno. El nivel se describe con más detalle más adelante en el artículo.
Dado que este nivel solo se aplica a clientes con una suscripción a Operations Management Suite, los clientes
sin una suscripción no verán una opción para seleccionar este nivel.
NOTE
Para garantizar que tiene este derecho, sus recursos de Application Insights deben estar en el plan de tarifa Por nodo.
Este derecho se aplica solo como nodos. Los recursos de Application Insights del nivel Por GB no consiguen ningún
beneficio. Este derecho no es visible en los costos estimados que se muestran en el panel Uso y costos estimados .
Además, si traslada una suscripción al nuevo modelo de precios de supervisión de Azure en abril de 2018, el nivel Por
GB será el único nivel disponible. El traslado de una suscripción al nuevo modelo de precios de supervisión de Azure no
es aconsejable si tiene una suscripción a Operations Management Suite.
Funcionamiento del nivel Por nodo

En el nivel Por nodo, se paga por cada nodo que envíe datos de telemetría desde cualquier aplicación.
Un nodo es un servidor físico o virtual o una instancia del rol de plataforma como servicio que
hospeda la aplicación.
Los equipos de desarrollo, los exploradores cliente y los dispositivos móviles no se cuentan como
nodos.
Si la aplicación contiene varios componentes que envían datos telemetría, como un servicio web y
un trabajo de back-end, estos componentes se cuentan por separado.
Los datos de la secuencia de métricas en directo no cuentan para calcular los precios. En una
suscripción, se cobra por nodo, no por aplicación. Si tiene cinco nodos que envían telemetría desde
12 aplicaciones, se le cobrarán 5 nodos.
Aunque los cargos se presupuestan mensualmente, solo se le cobrarán las horas en las que un nodo envíe
telemetría de una aplicación. El cargo por hora es el cargo mensual presupuestado dividido entre 744 (el
número de horas que tiene un mes de 31 días).
Cada día, se asigna un volumen de datos de 200 MB por cada nodo detectado (con una granularidad por
hora). Las asignaciones de datos que no se utilizan no se guardan de un día para otro.
Si elige el plan de tarifa Por nodo, cada suscripción recibirá una concesión de datos diaria en
función del número de nodos que envíen datos de telemetría a los recursos de Application Insights
de esa suscripción. Por tanto, si tiene cinco nodos que envían datos todo el día, tendrá una
asignación global de 1 GB para todos los recursos de Application Insights de esa suscripción. No
importa si algunos nodos envían más datos que otros, ya que los datos incluidos se comparten
entre todos los nodos. Si, un día determinado, los recursos de Application Insights reciben más
datos de los que se incluyen en la concesión de datos diaria para esta suscripción, se aplicarán los
cargos de datos por encima del límite por cada GB.
La asignación de datos diaria se calcula como el número de horas del día (de acuerdo con UTC) que
cada nodo envía datos de telemetría dividido entre 24 y multiplicado por 200 MB. Es decir, si tiene
cuatro nodos que envían datos de telemetría durante 15 de las 24 horas del día, los datos incluidos
para ese día serán ((4 × 15) / 24) × 200 MB = 500 MB. A un precio de 2,30 USD por GB en el caso
de uso por encima del límite de datos, el cargo sería de 1,15 USB si los nodos envían 1 GB de datos
ese día.
La concesión diaria del nivel Por nodo no se comparte con las aplicaciones para las que haya
elegido el nivel Por GB. La asignación que no se ha utilizado no se guarda de un día para otro.
Ejemplos acerca de cómo determinar el número de nodos
ESC EN A RIO N ÚM ERO DE N O DO S TOTA L DIA RIO
1 aplicación utiliza 3 instancias de Azure App Service y 1 4

servidor virtual
3 aplicaciones se ejecutan en 2 VM; los recursos de 2

Application Insights de estas aplicaciones están en la
misma suscripción y en el nivel Por nodo
4 aplicaciones cuyos recursos de Applications Insights 13,33

están en la misma suscripción; cada aplicación ejecuta 2
instancias durante 16 horas de poca actividad y 4
instancias durante 8 horas punta
Servicios en la nube con 1 rol de trabajo y 1 rol web; cada 4

uno ejecuta 2 instancias.
Un clúster de Azure Service Fabric con 5 nodos ejecuta 50 5

microservicios; cada microservicio ejecuta 3 instancias
El número preciso de nodos depende del SDK de Application Insights que utilice la aplicación.
En las versiones 2.2 y posteriores del SDK, tanto el SDK básico como el SDK web de Application
Insights cuentan cada host de aplicación como un nodo. Algunos ejemplos son el nombre de
equipo del servidor físico y los hosts de máquina virtual, o el nombre de instancia de los servicios
en la nube. La única excepción es una aplicación que solamente usa .NET Core y el SDK básico de
Application Insights. En ese caso, solo se cuenta un nodo para todos los hosts porque el nombre de
host no está disponible.
En las versiones anteriores del SDK, el SDK web se comporta del mismo modo que las versiones
más nuevas. Sin embargo, el SDK básico solo cuenta un nodo, independientemente del número real
de hosts de la aplicación.
Si la aplicación utiliza el SDK para establecer roleInstance en un valor personalizado, ese mismo
valor se usará de manera predeterminada para calcular el número de nodos.
Si utiliza una nueva versión del SDK con una aplicación que se ejecuta desde equipos cliente o
dispositivos móviles, es posible que el recuento de nodos devuelva un número grande (debido a la
gran cantidad de equipos cliente o de dispositivos móviles).
Automation
Puede escribir un script para establecer el plan de tarifa mediante Azure Resource Management. Más
información.
Pasos siguientes
muestreo
Administrar el uso y los costos con los registros
de Azure Monitor
NOTE
En este artículo se describe cómo entender y controlar los costos de los registros de Azure Monitor. En un artículo
relacionado, Supervisión del uso y costos estimados, se describe cómo ver el uso y los costos estimados mediante
varias características de supervisión de Azure para los distintos modelos de precios. Todos los precios y costos que
se muestran en este artículo son solo para fines de ejemplo.
Los registros de Azure Monitor están diseñados para escalar y admitir la recopilación, indexación y
almacenamiento de grandes cantidades de datos por día provenientes de cualquier origen dentro de su
empresa o implementados en Azure. Aunque esto puede ser un factor clave principal para su organización,
la rentabilidad es en última instancia el factor clave subyacente. Con este fin, es importante comprender
que el costo de un área de trabajo de Log Analytics no se basa simplemente en el volumen de datos
recopilados; también depende del plan seleccionado y de cuánto tiempo se decida almacenar los datos
generados a partir de los orígenes conectados.
En este artículo se revisa cómo supervisar de forma activa el crecimiento del volumen y el
almacenamiento de los datos ingeridos, y definir los límites para controlar esos costos asociados.
Modelo de precios
Los precios predeterminados de Log Analytics son de un modelo de Pago por uso , que se basa en el
volumen de datos ingeridos y, opcionalmente, permite obtener una mayor retención de datos. El volumen
de datos se mide como el tamaño de los datos que se almacenarán, en GB (10^9 bytes). Cada área de
trabajo de Log Analytics se cobra como un servicio independiente y contribuye a la factura de la
suscripción a Azure. La cantidad de ingesta de datos puede ser considerable dependiendo de los factores
siguientes:
Número de soluciones de administración habilitadas y su configuración
Número de máquinas virtuales supervisadas
Tipo de datos recopilados de cada máquina virtual supervisada
Además del modelo de pago por uso, Log Analytics tiene niveles de Reser va de capacidad que le
permiten ahorrar hasta un 25 % en comparación con el precio de pago por uso. Los precios de la reserva
de capacidad permiten comprar una reserva a partir de 100 GB/día. Cualquier uso por encima del nivel de
reserva se facturará según la tarifa de pago por uso. Los niveles de Reserva de capacidad tienen un
período de compromiso de 31 días. Durante el período de compromiso, puede cambiar a un nivel de
Reserva de capacidad de nivel superior (que reiniciará el período de compromiso de 31 días), pero no
podrá volver a la versión de pago por uso o a un nivel de Reserva de capacidad inferior hasta que el
período de compromiso finalice. La facturación de los niveles de reserva de capacidad se realiza cada día.
Más información sobre los precios de Pago por uso y de Reserva de capacidad de Log Analytics.
En todos los planes de tarifa, el tamaño de los datos de un evento se calcula a partir de una representación
de cadena de las propiedades que se almacenan en Log Analytics para ese evento, tanto si los datos se
envían desde un agente como si se agregan durante el proceso de ingesta. Esto incluye cualquier campo
personalizado que se agregue a medida que se recopilen datos y luego se almacenen en Log Analytics.
Varias propiedades comunes a todos los tipos de datos, incluidas algunas propiedades estándar de Log
Analytics, se excluyen del cálculo del tamaño del evento. Esto incluye _ResourceId , _ItemId , _IsBillable ,
_BilledSize y Type . Todas las demás propiedades almacenadas en Log Analytics se incluyen en el cálculo
del tamaño del evento. Algunos tipos de datos están libres de los cargos de ingesta de datos, por ejemplo,
los tipos AzureActivity, Latido y Uso. Para determinar si un evento se ha excluido de la facturación
relacionada con la ingesta de datos, puede usar la propiedad _IsBillable , como se muestra más adelante.
El uso se informa en GB (1,0E9 bytes).
Además, tenga en cuenta que algunas soluciones, como Azure Security Center, Azure Sentinel y
Administración de configuración tienen sus propios modelos de precios.
Clústeres dedicados de Log Analytics
Los clústeres dedicados de Log Analytics son colecciones de áreas de trabajo en un único clúster de Azure
Data Explorer administrado para permitir escenarios avanzados, como las claves administradas por el
cliente. Los clústeres dedicados de Log Analytics solo admiten un modelo de precios de reserva de
capacidad a partir de 1000 GB/día con un descuento del 25 % en comparación con los precios de pago por
uso. Cualquier uso por encima del nivel de reserva se facturará según la tarifa de pago por uso. La reserva
de capacidad del clúster tiene un período de compromiso de 31 días después de aumentar el nivel de
reserva. Durante el período de compromiso, no se puede reducir el nivel de reserva de capacidad, pero se
puede aumentar en cualquier momento. Más información sobre la creación de clústeres de Log Analytics y
la asociación de áreas de trabajo a ellos.
El nivel de reserva de capacidad del clúster se configura mediante programación con Azure Resource
Manager con el parámetro Capacity en Sku . El parámetro Capacity se especifica en unidades de GB y
puede tener valores de 1000 GB/día o más en incrementos de 100 GB/día. Esto se detalla en Clave
administrada por el cliente de Azure Monitor. Si el clúster necesita una reserva superior a 2000 GB/día,
póngase en contacto con nosotros en LAIngestionRate@microsoft.com.
Hay dos modos de facturación para el uso en un clúster. Estos pueden especificarse mediante el parámetro
billingType al configurar el clúster. Los dos modos son:
1. Clúster : en este caso (que es el modo predeterminado), la facturación de los datos ingeridos se
realiza en el nivel de clúster. Las cantidades de datos ingeridas desde cada área de trabajo asociada
a un clúster se suman para calcular la factura diaria del clúster. Tenga en cuenta las asignaciones por
nodo de Azure Security Center que se aplican en el nivel de área de trabajo antes de esta
agregación de datos agregados en todas las áreas de trabajo del clúster.
2. Áreas de trabajo : los costos de reserva de capacidad para el clúster se atribuyen
proporcionalmente a las áreas de trabajo del clúster (después de tener en cuenta las asignaciones
por nodo de Azure Security Center para cada área de trabajo). Si el volumen total de datos
ingeridos en un área de trabajo durante un día es menor que la reserva de capacidad, cada área de
trabajo se factura por sus datos ingeridos con la tasa de reserva de capacidad por GB efectiva y la
facturación de una fracción de la reserva de capacidad. La parte sin usar de la reserva de capacidad
se factura al recurso de clúster. Si el volumen total de datos ingeridos en un área de trabajo durante
un día es superior al de la reserva de capacidad, se factura a cada área de trabajo una fracción de la
reserva de capacidad en función de su fracción de la cantidad de datos ingeridos ese día, y también
una fracción de los datos ingeridos por encima de la reserva de capacidad. No se factura nada al
recurso de clúster si el volumen total de datos ingeridos en un área de trabajo durante un día
supera la reserva de capacidad.
En las opciones de facturación del clúster, la retención de datos se factura en el nivel del área de trabajo.
Tenga en cuenta que la facturación del clúster comienza cuando se crea este, independientemente de si las
áreas de trabajo se han asociado al clúster. Además, tenga en cuenta que las áreas de trabajo asociadas a
un clúster ya no tienen un plan de tarifa.
Estimación de los costos de administración del entorno
Si aún no usa los registros de Azure Monitor, puede usar la calculadora de precios de Azure Monitor para
calcular el costo del uso de Log Analytics. Comience por escribir "Azure Monitor" en el cuadro de
búsqueda y haga clic en el icono de Azure Monitor resultante. Desplácese hacia abajo en la página hasta
Azure Monitor y seleccione Log Analytics en la lista desplegable Tipo. Aquí puede especificar el número de
máquinas virtuales y los GB de datos que espera recopilar de cada máquina virtual. Normalmente se
ingieren de 1 a 3 GB de datos al mes en una máquina virtual típica de Azure. Si ya está evaluando los
registros de Azure Monitor, puede usar las estadísticas de datos de su propio entorno. Consulte a
continuación cómo determinar el número de máquinas virtuales supervisadas y el volumen de los datos
que ingiere el área de trabajo.
Información útil del uso y los costos estimados

Si ya usa los registros de Azure Monitor ahora, es fácil comprender cuáles serán probablemente los costos
según los patrones de uso recientes. Para ello, utilice Uso y costos estimados de Log Analytics a fin
de revisar y analizar el uso de datos. Muestra la cantidad de datos que recopila cada solución, la cantidad
de datos que se retienen y una estimación de los costos según la cantidad de datos ingeridos y cualquier
retención adicional más allá de la cantidad incluida.
Para explorar los datos más detalladamente, haga clic en el icono situado en el extremo superior derecho
de cualquiera de los gráficos de la página Uso y costos estimados . Ahora puede trabajar con esta
consulta para explorar más detalles sobre su uso.
En la página Uso y costos estimados puede revisar el volumen de datos del mes. Esto incluye todos los
datos recibidos y retenidos facturables en el área de trabajo de Log Analytics.
Los cargos de Log Analytics se agregarán a la factura de Azure. Puede consultar los detalles de su factura
de Azure en la sección de facturación de Azure Portal o en el Portal de facturación de Azure.
Visualización del uso de Log Analytics en la factura de Azure

Facturación. Por ejemplo, la funcionalidad de "Análisis de costos" le permite ver los gastos de los recursos
de Azure. En primer lugar, agregar un filtro por "tipo de recurso" (a
microsoft.operationalinsights/workspace para Log Analytics y microsoft.operationalinsights/workspace
para los clústeres de Log Analytics) le permitirá realizar un seguimiento del gasto de Log Analytics.
Después, para "Agrupar por", seleccione "Categoría del medidor" o "Medidor". Tenga en cuenta que otros
servicios, como Azure Security Center y Azure Sentinel, también se facturan por uso frente a los recursos
del área de trabajo de Log Analytics. Para ver la asignación al nombre del servicio, puede seleccionar la
vista de tabla en lugar de ver un gráfico.
Puede obtener información sobre el uso mediante la descarga del uso desde Azure Portal. En la hoja de
cálculo descargada puede ver el uso por recurso de Azure (por ejemplo, área de trabajo de Log Analytics)
al día. En esta hoja de cálculo de Excel, el uso de las áreas de trabajo de Log Analytics se puede encontrar
filtrando, en primer lugar, la columna "Categoría del medidor" para mostrar "Log Analytics", "Insights y
Analytics" (utilizado por algunos planes de tarifa heredados) y "Azure Monitor" (usado por los planes de
tarifa de reserva de capacidad) y, a continuación, agregando un filtro en la columna "Id. de instancia", que
es "contiene área de trabajo" o "contiene clúster" (este último para incluir el uso de clústeres de Log
Analytics). El uso se muestra en la columna "Cantidad consumida" y la unidad de cada entrada se muestra
en la columna "Unidad de medida". Hay más detalles disponibles para ayudarle a entender la factura de
Microsoft Azure.
Actualización del plan de tarifa

Para cambiar el plan de tarifa de Log Analytics del área de trabajo,
1. en Azure Portal, abra Uso y costos estimados en el área de trabajo donde verá una lista de cada
uno de los planes de tarifa disponibles para esta área de trabajo.
2. Revise los costos estimados para cada uno de los planes de tarifa. Esta estimación se basa en los
últimos 31 días de uso, por lo que esta estimación de costos se basa en los últimos 31 días lo que
es representativo de su uso habitual. En el ejemplo siguiente puede ver cómo, en función de los
patrones de datos de los últimos 31 días, esta área de trabajo costaría menos en el nivel de pago
por uso (n.° 1) en comparación con el nivel de Reserva de capacidad de 100 GB/día (n.° 2).
3. Después de revisar los costos estimados en función de los últimos 31 días de uso, si decide cambiar
el plan de tarifa, haga clic en Seleccionar .
También puede establecer el plan de tarifa mediante Azure Resource Manager con el parámetro sku (
pricingTier en la plantilla de Azure Resource Manager).
Planes de tarifa heredados

Las suscripciones que contenían un área de trabajo de Log Analytics o un recurso de Application Insights
antes del 2 de abril de 2018, o que están vinculadas a un Contrato Enterprise que comenzó antes del 1 de
febrero de 2019, continuarán teniendo acceso a los planes de tarifa heredados: Gratuito ,Independiente
(por GB) y Por nodo (OMS) . Las áreas de trabajo en el plan de tarifa Gratis tendrán una ingesta diaria de
datos limitada a 500 MB (excepto los tipos de datos de seguridad que recopile Azure Security Center) y la
retención de datos se limitará a 7 días. El plan de tarifa gratuito está destinado solo para fines de
evaluación. Las áreas de trabajo en los planes de tarifa independientes o por nodo tienen una retención
configurable para el usuario de 30 a 730 días.
El uso en el plan de tarifa independiente se factura por el volumen de datos ingerido. Se indica en el
servicio Log Analytics y el medidor se denomina "Datos analizados".
Los cargos del plan de tarifa por nodo y por VM supervisada (nodo) en una granularidad de hora. En cada
nodo supervisado, se asignan al área de trabajo 500 MB de datos al día que no se facturan. Esta asignación
se agrega en el nivel de área de trabajo. Los datos ingeridos por encima de la asignación de datos diaria
agregada se facturan por GB como datos con un uso por encima del límite. Tenga en cuenta que, en su
factura, el servicio será Insight and Analytics para el uso de Log Analytics si el área de trabajo se
encuentra en el plan de tarifa por nodo. El uso se muestra en tres medidores:
1. Nodo: se usa para el número de nodos supervisados (VM) en unidades de nodo*meses.
2. Data Overage per Node (Datos por encima del límite por nodo): es el número de GB de datos ingeridos
en exceso de la asignación de datos agregados.
3. Data Included per Node (Datos incluidos por nodo): es la cantidad de datos ingeridos incluidos en la
asignación de datos agregados. Este medidor también se usa cuando el área de trabajo está en todos
los planes de tarifa para mostrar la cantidad de datos incluidos en Azure Security Center.
TIP
Si el área de trabajo tiene acceso al plan de tarifa por nodo , pero se pregunta si sería menos costoso un plan de
tarifa de pago por uso, puede usar la siguiente consulta para obtener fácilmente una recomendación.
Las áreas de trabajo creadas antes de abril de 2016 también tienen acceso a los planes de tarifa Estándar
y Premium originales, que tienen una retención de datos fija de 30 y 365 días, respectivamente. No se
pueden crear áreas de trabajo en los planes de tarifa Estándar o Premium , y si un área de trabajo se saca
de estos niveles, no puede regresar a ellos. Los medidores de ingesta de datos para estos niveles
heredados se denominan "Datos analizados".
También hay algunos comportamientos entre el uso de los niveles de Log Analytics heredados y cómo se
factura el uso en Azure Security Center.
1. Si el área de trabajo se encuentra en el nivel heredado Estándar o Premium, Azure Security Center se
facturará solo por la ingesta de datos de Log Analytics, no por nodo.
2. Si el área de trabajo se encuentra en el nivel heredado Por nodo, Azure Security Center se facturará
según el modelo actual de precios basado en nodos de Azure Security Center.
3. En otros planes de tarifa (incluidas las reservas de capacidad), si Azure Security Center se habilitó antes
del 19 de junio de 2017, Azure Security Center se facturará solo por la ingesta de datos de Log
Analytics. De lo contrario, Azure Security Center se facturará según el modelo actual de precios basado
en nodos de Azure Security Center.
Puede encontrar más detalles sobre las limitaciones de los planes de tarifa en Límites, cuotas y
restricciones de suscripción y servicios de Microsoft Azure.
Ninguno de los planes de tarifa heredados tiene precios basados en la región.
NOTE
Para usar los derechos que proceden de la adquisición de OMS E1 Suite, OMS E2 Suite o un complemento de OMS
para System Center, elija el plan de tarifa Por nodo de Log Analytics.
Cambio del período de retención de datos

Los pasos siguientes describen cómo configurar cuánto tiempo se conservan los datos de registro en el
área de trabajo. La retención de datos se puede configurar entre 30 y 730 días (2 años) para todas las
áreas de trabajo a menos que usen el plan de tarifa Gratis heredado. Más información sobre los precios
para una retención de datos más prolongada.
Retención predeterminada
Para establecer la retención predeterminada del área de trabajo,
1. En Azure Portal, en el área de trabajo, seleccione Uso y costos estimados en el panel izquierdo.
2. En la página Uso y costos estimados , haga clic en Retención de datos en la parte superior de
la página.
3. En el panel, mueva el control deslizante para aumentar o disminuir el número de días y, luego, haga
clic en Aceptar . Si el nivel es gratuito, no podrá modificar el período de retención de datos y tendrá
que actualizar al nivel de pago para controlar esta configuración.
Cuando se reduce la retención, hay un período de gracia de varios días antes de que se quiten los datos
más antiguos que la nueva configuración de retención.
La retención también se puede configurar a través de Azure Resource Manager mediante el parámetro
retentionInDays . Al configurar la retención de datos en 30 días, puede desencadenar una purga inmediata
de los datos más antiguos mediante el parámetro immediatePurgeDataOn30Days , que elimina el período de
gracias de varios días. Esto puede ser útil para escenarios relacionados con el cumplimiento en los que la
eliminación de datos inmediata es imperativa. Esta funcionalidad de purga inmediata solo está expuesta a
través de Azure Resource Manager.
Las áreas de trabajo con una retención de 30 días en realidad pueden conservar los datos durante 31 días.
Si es imperativo que los datos se conserven solo durante 30 días, use Azure Resource Manager para
establecer la retención en 30 días y con el parámetro immediatePurgeDataOn30Days .
Dos tipos de datos ( Usage y AzureActivity ) se conservan durante un mínimo de 90 días de forma
predeterminada, y no se aplica ningún cargo por esta retención de 90 días. Si la retención del área de
trabajo se aumenta por encima de los 90 días, también se aumentará la retención de estos tipos de datos.
Estos tipos de datos también están libres de los cargos de ingesta de datos.
De forma predeterminada, los tipos de datos de los recursos de Application Insights basados en áreas de
trabajo ( AppAvailabilityResults , AppBrowserTimings , AppDependencies , AppExceptions , AppEvents ,
AppMetrics , AppPageViews , AppPerformanceCounters , AppRequests , AppSystemEvents y AppTraces ) también
se conservan durante 90 días, y no se aplica ningún cargo por esta retención de 90 días. Su retención se
puede ajustar mediante la funcionalidad de retención por tipo de datos.
Tenga en cuenta que la API de purga de Log Analytics no afecta a la facturación de la retención y está
pensada para usarse en casos muy limitados. Para reducir la factura de retención, el período de retención
se debe reducir para el área de trabajo o para tipos de datos específicos.
Retención por tipo de datos
También es posible especificar diferentes configuraciones de retención para tipos de datos individuales de
30 a 730 días (excepto para áreas de trabajo del plan de tarifa gratuito heredado). Cada tipo de datos es un
subrecurso del área de trabajo. Por ejemplo, la tabla SecurityEvent se puede tratar en Azure Resource
Manager como:
/subscriptions/00000000-0000-0000-0000-
00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWo
rkspaceName/Tables/SecurityEvent
Tenga en cuenta que el tipo de datos (tabla) distingue mayúsculas de minúsculas. Para obtener la
configuración actual de retención por tipo de datos de un tipo de datos determinado (en este ejemplo,
SecurityEvent), use:
GET /subscriptions/00000000-0000-0000-0000-
rkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview
Para obtener la configuración actual de retención por tipo de datos para todos los tipos de datos del área
de trabajo, solo tiene que omitir el tipo de datos específico, por ejemplo:
GET /subscriptions/00000000-0000-0000-0000-
rkspaceName/Tables?api-version=2017-04-26-preview
Para establecer la retención de un tipo de datos determinado (en este ejemplo, SecurityEvent) en 730 días,
haga
PUT /subscriptions/00000000-0000-0000-0000-
rkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview
{
"properties":
{
"retentionInDays": 730
}
}
Los valores válidos para retentionInDays oscilan entre 30 y 730.

Los tipos de datos Usage y AzureActivity no se pueden establecer con retención personalizada.
Adoptarán el máximo de la retención predeterminada del área de trabajo o 90 días.
Una herramienta excelente para conectarse directamente a Azure Resource Manager para establecer la
retención por tipo de datos es la herramienta OSS ARMclient. Más información sobre ARMclient en los
artículos de David Ebbo y Daniel Bowbyes. A continuación se muestra un ejemplo de uso de ARMClient,
estableciendo los datos de SecurityEvent con una retención de 730 días:
armclient PUT /subscriptions/00000000-0000-0000-0000-

rkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview "{properties: {retentionInDays: 730}}"
TIP
El establecimiento de la retención de tipos de datos individuales se puede usar para reducir los costos de la
retención de datos. Para los datos recopilados a partir de octubre de 2019 (fecha de publicación de esta
característica), la reducción de la retención para algunos tipos de datos puede reducir el costo de retención con el
tiempo. Para los datos recopilados anteriormente, el establecimiento de una retención más baja para un tipo
individual no afectará a los costos de retención.
Administración del volumen de datos diario máximo
Puede configurar un límite diario y limitar la ingesta diaria para el área de trabajo, pero tenga cuidado de
establecer el límite diario como el objetivo al que llegar. En caso contrario, perderá los datos para el resto
del día, lo que puede afectar a otros servicios y soluciones de Azure cuya funcionalidad puede depender
de la disponibilidad de datos actualizados en el área de trabajo. Como resultado, esto afecta a la capacidad
de observar y recibir alertas cuando cambian las condiciones de mantenimiento de los recursos que
respaldan los servicios de TI. El límite diario está pensado para usarse como una manera de administrar un
aumento inesperado del volumen de datos de los recursos administrados y permanecer dentro de su
límite, o simplemente cuando quiera limitar los cargos no planeados para el área de trabajo. No es
adecuado para establecer un límite diario para que se cumpla cada día en un área de trabajo.
A cada área de trabajo se le aplica su límite diario en una hora diferente del día. La hora de
restablecimiento se muestra en la página Límite diario (consulte más adelante). Esta hora de
restablecimiento no se puede configurar.
Poco después de alcanzar el límite diario, la recopilación de tipos de datos facturables se detiene durante el
resto del día. La latencia inherente a la aplicación del límite diario significa que el límite no se aplica con
precisión al nivel de límite diario especificado. Un mensaje emergente de advertencia aparece en la parte
superior de la página del área de trabajo de Log Analytics seleccionada, y se envía un evento de operación
para la tabla Operación en la categoría LogManagement . La recopilación de datos se reanuda después
de que se restablezca el tiempo definido en Daily limit will be set at (El límite diario se establecerá en). Se
recomienda definir una regla de alerta en función de este evento de operación que esté configurada para
notificar cuando se ha alcanzado el límite diario de datos.
NOTE
El límite diario no puede detener la recopilación de datos con la misma precisión que el nivel de límite especificado y
pueden esperarse datos sobrantes, especialmente si el área de trabajo recibe grandes volúmenes de datos.
WARNING
El límite diario no detiene la recopilación de datos de Azure Sentinel o Azure Security Center, excepto en el caso de
las áreas de trabajo en las que Azure Security Center se instaló antes del 19 de junio de 2017.
Identificación del límite diario de datos para definir

Revise el uso de Log Analytics y costos estimados para comprender la tendencia de ingesta de datos y cuál
es el límite de volumen diario para definir. Se debe examinar con detenimiento, ya que, una vez alcanzado
el límite, no podrá supervisar los recursos.
Los pasos siguientes describen cómo configurar un límite para administrar el volumen de datos que el
área de trabajo de Log Analytics ingiere por día.
1. En el área de trabajo seleccione Usage and estimated costs (Uso y costos estimados) en el panel
izquierdo.
2. En la página Usage and estimated costs (Uso y costos estimados) del área de trabajo
seleccionada, haga clic en Límite de datos en la parte superior de la página.
3. ¿Está el límite diario desactivado de forma predeterminada? Haga clic en ON (ACTIVADO) para
habilitarlo y, luego, establezca el límite de volumen diario en GB/día.
El límite diario se puede configurar mediante ARM si se establece el parámetro dailyQuotaGb en
WorkspaceCapping , como se describe en Áreas de trabajo: creación o actualización.
Alerta cuando se alcanza el límite diario

Aunque Azure Portal presenta una indicación visual cuando se alcanza el umbral de límite de datos, este
comportamiento no tiene que alinearse necesariamente con la forma en la que el usuario administra los
problemas de funcionamiento que requieren atención inmediata. Para recibir una notificación de alerta,
puede crear una nueva regla de alerta en Azure Monitor. Para obtener más información, consulte Cómo
crear, ver y administrar alertas.
Para comenzar, esta es la configuración recomendada para la alerta:
Destino: seleccione el recurso de Log Analytics
Criterios:
Nombre de señal: Búsqueda de registros personalizada
Consulta de búsqueda: Operación | donde Detalle tiene "OverQuota"
Basado en: Número de resultados
Condición: Mayor que
Umbral: 0
Período: 5 (minutos)
Frecuencia: 5 (minutos)
Nombre de regla de alertas: Límite de datos diario alcanzado
Gravedad: advertencia (gravedad 1)
Una vez que se define la alerta y se alcanza el límite, se desencadena una alerta que realiza la respuesta
que se define en el grupo de acciones. Puede notificar a su equipo a través de mensajes de correo
electrónico y de texto, o automatizar acciones mediante webhooks, runbooks de Automation o integrar
con una solución de ITSM externa.
Solución del problema de un uso mayor de lo esperado

Un mayor uso está provocado por una de estas causas o por ambas:
Más nodos de lo previsto que envían datos al área de trabajo de Log Analytics.
Se enviaron más datos de los esperados al área de trabajo de Log Analytics (quizás debido a que
empiece a usarse una solución nueva o a un cambio de configuración).
Descripción de nodos que envían datos

Para conocer el número de equipos que notificaron latidos todos los días del último mes, use lo siguiente:
Heartbeat
| where TimeGenerated > startofday(ago(31d))
| summarize nodes = dcount(Computer) by bin(TimeGenerated, 1d)
| render timechart
Para obtener un recuento de los nodos que han enviado datos en las últimas 24 horas, use la consulta:
find where TimeGenerated > ago(24h) project Computer

| extend computerName = tolower(tostring(split(Computer, '.')[0]))
| where computerName != ""
| summarize nodes = dcount(computerName)
Para obtener una lista de nodos que envían datos (y la cantidad de datos que envía cada uno) se puede
usar la consulta siguiente:
find where TimeGenerated > ago(24h) project _BilledSize, Computer

| summarize TotalVolumeBytes=sum(_BilledSize) by computerName
TIP
Use estas consultas find con moderación, ya que la ejecución de exámenes entre tipos de datos consume
muchos recursos. Si no necesita resultados por equipo , consulte el tipo de datos Usage (vea a continuación).
Descripción del volumen de datos ingeridos

En la página Uso y costos estimados , el gráfico Ingesta de datos por solución muestra el volumen total
de los datos enviados y la cantidad que envía cada solución. Esto le permite determinar tendencias tales
como si el uso global de los datos (o el uso de una solución en particular) crece, permanece constante o
disminuye.
Volumen de datos para eventos específicos
Para ver el tamaño de los datos ingeridos de un conjunto determinado de eventos, puede consultar la
tabla específica (en este ejemplo, Event ) y, a continuación, restringir la consulta a los eventos de interés
(en este ejemplo, identificador de evento 5145 o 5156):
Event
| where TimeGenerated > startofday(ago(31d)) and TimeGenerated < startofday(now())
| where EventID == 5145 or EventID == 5156
| where _IsBillable == true
| summarize count(), Bytes=sum(_BilledSize) by EventID, bin(TimeGenerated, 1d)
Tenga en cuenta que la cláusula where _IsBillable = true filtra los tipos de datos de determinadas
soluciones para las que no hay ningún cargo de ingesta. Más información sobre _IsBillable .
Data volume by solution (Volumen de datos por solución)
La consulta que se usa para ver el volumen de datos facturable por solución en el último mes (excepto el
último día parcial) es:
Usage
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())
| where IsBillable == true
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), Solution | render barchart
La cláusula con TimeGenerated solo se utiliza para asegurarse de que la experiencia de consulta en
Azure Portal examine más allá del periodo predeterminado de 24 horas. Al utilizar el tipo de datos de uso,
StartTime y EndTime representan los períodos de tiempo de los que se presentan resultados.
Volumen de datos por tipo

Puede profundizar más para ver las tendencias de datos por tipo de datos:
Usage
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType | render barchart
O bien, para ver una tabla por solución y tipo durante el último mes,
Usage
| summarize BillableDataGB = sum(Quantity) by Solution, DataType
| sort by Solution asc, DataType asc
Volumen de datos por equipo

El tipo de datos Usage no incluye información en el nivel de equipo. Para ver el tamaño de los datos
ingeridos por cada equipo, use la propiedad _BilledSize , que proporciona el tamaño en bytes:
find where TimeGenerated > ago(24h) project _BilledSize, _IsBillable, Computer

| summarize BillableDataBytes = sum(_BilledSize) by computerName
| sort by BillableDataBytes nulls last
La propiedad _IsBillable especifica si los datos ingeridos generarán gastos.

Para ver el recuento de eventos facturables que ingirió cada equipo, use:
find where TimeGenerated > ago(24h) project _IsBillable, Computer

| summarize eventCount = count() by computerName
| sort by eventCount nulls last
TIP
muchos recursos. Si no necesita resultados por equipo , consulte el tipo de datos Usage.
Volumen de datos por recurso de Azure, grupo de recursos o suscripción

Para los datos de los nodos hospedados en Azure, puede obtener el tamaño de los eventos ingeridos por
cada equipo ; para ello, use la propiedad _ResourceId, que proporciona la ruta completa al recurso:
find where TimeGenerated > ago(24h) project _ResourceId, _BilledSize, _IsBillable

| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId | sort by BillableDataBytes nulls last
Para los datos de los nodos hospedados en Azure, puede obtener el tamaño de los datos ingeridos por
cada suscripción de Azure ; obtenga el id. de suscripción de la propiedad _ResourceId como:

| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId
| extend subscriptionId = tostring(split(_ResourceId, "/")[2])
| summarize BillableDataBytes = sum(BillableDataBytes) by subscriptionId | sort by BillableDataBytes
nulls last
Del mismo modo, para obtener el volumen de datos por grupo de recursos, sería:

| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId
| extend resourceGroup = tostring(split(_ResourceId, "/")[4] )
| summarize BillableDataBytes = sum(BillableDataBytes) by resourceGroup | sort by BillableDataBytes
nulls last
Además, de ser necesario, puede analizar la propiedad _ResourceId más atentamente con:
| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/"

resourceGroup "/providers/" provider "/" resourceType "/" resourceName
TIP
muchos recursos. Si no necesita resultados por suscripción, grupo de recursos ni nombre de recurso, consulte el
tipo de datos Usage.
WARNING
Algunos de los campos del tipo de datos de uso, aunque siguen en el esquema, han quedado en desuso y ya no se
rellenarán sus valores. Estos son Computer , además de los campos relacionados con la ingesta (TotalBatches ,
BatchesWithinSla , BatchesOutsideSla , BatchesCapped y AverageProcessingTimeMs .
Consulta de los tipos de datos comunes

Para profundizar en el origen de datos de un tipo de datos concreto, estas son algunas consultas de
ejemplo útiles:
Recursos de Application Insights basados en áreas de trabajo
Obtenga más información en Administración del uso y los costos de Application Insights
Solución Security
SecurityEvent | summarize AggregatedValue = count() by EventID
Solución Log Management
Usage | where Solution == "LogManagement" and iff(isnotnull(toint(IsBillable)), IsBillable ==
true, IsBillable == "true") == true | summarize AggregatedValue = count() by DataType
Tipo de datos Perf
Perf | summarize AggregatedValue = count() by CounterPath
Perf | summarize AggregatedValue = count() by CounterName
Tipo de datos Event
Event | summarize AggregatedValue = count() by EventID
Event | summarize AggregatedValue = count() by EventLog, EventLevelName
Tipo de datos Syslog
Syslog | summarize AggregatedValue = count() by Facility, SeverityLevel
Syslog | summarize AggregatedValue = count() by ProcessName
Tipo de datos de AzureDiagnostics
AzureDiagnostics | summarize AggregatedValue = count() by ResourceProvider, ResourceId
Sugerencias para reducir el volumen de datos

Algunas sugerencias para reducir el volumen de registros recopilados incluyen:
O RIGEN DEL M AY O R VO L UM EN DE DATO S C Ó M O REDUC IR EL VO L UM EN DE DATO S
Container Insights Configure Container Insights para recopilar solo los datos
necesarios.
Eventos de seguridad Seleccione los eventos de seguridad común o mínima.

Cambie la directiva de auditoría de seguridad para
recopilar únicamente los eventos necesarios. En particular,
revise la necesidad de recopilar eventos para
- auditar plataforma de filtrado
- auditar registro
- auditar sistema de archivos
- auditar objeto de kernel
- auditar manipulación de identificadores
- auditar almacenamiento extraíble
Contadores de rendimiento Cambie la configuración de los contadores de

rendimiento para:
- Reducir la frecuencia de la colección
- Reducir el número de contadores de rendimiento
Registros de eventos Cambie la configuración del registro de eventos para:

- Reducir el número de registros de eventos recopilados
- Recopilar solo los niveles de eventos necesarios Por
ejemplo, no recopile eventos de nivel de información.
syslog Cambie la configuración de syslog para:

- Reducir el número de instalaciones recopiladas
- Recopilar solo los niveles de eventos necesarios Por
ejemplo, no recopile eventos de nivel de información y
depuración.
AzureDiagnostics Cambie la colección de registros de recursos para:

- Reducir el número de registros de recursos enviados a
Log Analytics
- Recopilar solo los registros necesarios
O RIGEN DEL M AY O R VO L UM EN DE DATO S C Ó M O REDUC IR EL VO L UM EN DE DATO S
Datos de la solución procedentes de equipos que no Use la selección de destino de solución para recopilar
necesitan la solución datos solo de los grupos de equipos necesarios.
Obtención de nodos facturados en el plan de tarifa Por nodo

Para obtener una lista de equipos que se facturarán como nodos si el área de trabajo se encuentra en el
plan de tarifa heredado de cada nodo, busque los nodos que envían tipos de datos facturados (algunos
tipos de datos son gratuitos). Para hacer esto, use la propiedad _IsBillable y el campo situado más a la
izquierda del nombre de dominio completo. De este modo se devuelve el recuento de equipos con datos
facturados por hora (que es la granularidad con la que se contabilizan y se facturan los nodos):
find where TimeGenerated > ago(24h) project Computer, TimeGenerated

| summarize billableNodes=dcount(computerName) by bin(TimeGenerated, 1h) | sort by TimeGenerated asc
Obtener recuentos de nodos de seguridad y automatización

Si se encuentra en el plan de tarifa "Por nodo (OMS)", se le cobrará en función del número de nodos y
soluciones que utilice y el número de nodos de Insight and Analytics por los que se le factura se mostrará
en la tabla de la página Uso y costos estimados .
Para ver el número de nodos de seguridad distintos, puede utilizar la consulta:
union
(
Heartbeat
| where (Solutions has 'security' or Solutions has 'antimalware' or Solutions has
'securitycenter')
| project Computer
),
(
ProtectionStatus
| where Computer !in~
(
(
Heartbeat
| project Computer
)
)
| project Computer
)
| distinct Computer
| project lowComputer = tolower(Computer)
| distinct lowComputer
| count
Para ver el número de nodos de Automation distintos, utilice la consulta:

ConfigurationData
| where (ConfigDataType == "WindowsServices" or ConfigDataType == "Software" or ConfigDataType
=="Daemons")
| extend lowComputer = tolower(Computer) | summarize by lowComputer
| join (
Heartbeat
| where SCAgentChannel == "Direct"
| extend lowComputer = tolower(Computer) | summarize by lowComputer, ComputerEnvironment
) on lowComputer
| summarize count() by ComputerEnvironment | sort by ComputerEnvironment asc
Evaluación del plan de tarifa por nodo heredado

La decisión de si las áreas de trabajo con acceso a los planes de tarifas por nodo heredados están mejor
en ese plan o en otro de pago por uso o de reser va de capacidad suele resultar difícil de evaluar para
los clientes. Implica conocer el equilibrio entre el costo fijo por nodo supervisado en el plan de tarifa por
nodo y su asignación de datos incluida de 500 MB/nodo/día, y el costo que supone pagar solo por los
datos ingeridos en la tarifa de pago por uso (por GB).
Para facilitar esta valoración, se puede usar la consulta siguiente a fin de realizar una recomendación para
el plan de tarifa óptimo en función de los patrones de uso de un área de trabajo. Esta consulta examina los
nodos supervisados y los datos ingeridos en un área de trabajo los últimos siete días y evalúa para cada
día qué plan de tarifa habría sido el óptimo. Para usar la consulta, debe especificar
1. si el área de trabajo usa Azure Security Center estableciendo workspaceHasSecurityCenter en true o
false ;
2. actualizar los precios si tiene descuentos específicos;
3. especificar el número de días que se van a buscar y analizar estableciendo daysToEvaluate . Esto resulta
útil si la consulta tarda demasiado en buscar datos para 7 días.
Esta es la consulta de recomendación del nivel de precios:
// Set these parameters before running query
let workspaceHasSecurityCenter = true; // Specify if the workspace has Azure Security Center
let PerNodePrice = 15.; // Enter your montly price per monitored nodes
let PerNodeOveragePrice = 2.30; // Enter your price per GB for data overage in the Per Node pricing
tier
let PerGBPrice = 2.30; // Enter your price per GB in the Pay-as-you-go pricing tier
let daysToEvaluate = 7; // Enter number of previous days look at (reduce if the query is taking too
long)
// ---------------------------------------
let SecurityDataTypes=dynamic(["SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary",
"SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog",
"SysmonEvent", "ProtectionStatus", "WindowsEvent", "Update", "UpdateSummary"]);
let StartDate = startofday(datetime_add("Day",-1*daysToEvaluate,now()));
let EndDate = startofday(now());
union *
| where TimeGenerated >= StartDate and TimeGenerated < EndDate
| summarize nodesPerHour = dcount(computerName) by bin(TimeGenerated, 1h)
| summarize nodesPerDay = sum(nodesPerHour)/24. by day=bin(TimeGenerated, 1d)
| join kind=leftouter (
Heartbeat
| where Computer != ""
| summarize ASCnodesPerHour = dcount(Computer) by bin(TimeGenerated, 1h)
| extend ASCnodesPerHour = iff(workspaceHasSecurityCenter, ASCnodesPerHour, 0)
| summarize ASCnodesPerDay = sum(ASCnodesPerHour)/24. by day=bin(TimeGenerated, 1d)
) on day
| join (
Usage
| extend NonSecurityData = iff(DataType !in (SecurityDataTypes), Quantity, 0.)
| extend SecurityData = iff(DataType in (SecurityDataTypes), Quantity, 0.)
| summarize DataGB=sum(Quantity)/1000., NonSecurityDataGB=sum(NonSecurityData)/1000.,
SecurityDataGB=sum(SecurityData)/1000. by day=bin(StartTime, 1d)
) on day
| extend AvgGbPerNode = NonSecurityDataGB / nodesPerDay
| extend PerGBDailyCost = iff(workspaceHasSecurityCenter,
(NonSecurityDataGB + max_of(SecurityDataGB - 0.5*ASCnodesPerDay, 0.)) * PerGBPrice,
DataGB * PerGBPrice)
| extend OverageGB = iff(workspaceHasSecurityCenter,
max_of(DataGB - 0.5*nodesPerDay - 0.5*ASCnodesPerDay, 0.),
max_of(DataGB - 0.5*nodesPerDay, 0.))
| extend PerNodeDailyCost = nodesPerDay * PerNodePrice / 31. + OverageGB * PerNodeOveragePrice
| extend Recommendation = iff(PerNodeDailyCost < PerGBDailyCost, "Per Node tier",
iff(NonSecurityDataGB > 85., "Capacity Reservation tier", "Pay-as-you-go (Per GB) tier"))
| project day, nodesPerDay, ASCnodesPerDay, NonSecurityDataGB, SecurityDataGB, OverageGB,
AvgGbPerNode, PerGBDailyCost, PerNodeDailyCost, Recommendation | sort by day asc
//| project day, Recommendation // Comment this line to see details
| sort by day asc
Esta consulta no es una replicación exacta de cómo se calcula el uso, pero funcionará para proporcionar
recomendaciones de plan de tarifa en la mayoría de los casos.
NOTE
Para usar los derechos que proceden de la adquisición de OMS E1 Suite, OMS E2 Suite o un complemento de OMS
para System Center, elija el plan de tarifa Por nodo de Log Analytics.
Creación de una alerta cuando la colección de datos es mayor

En esta sección se describe cómo crear una alerta si el volumen de datos en las últimas 24 horas ha
superado una cantidad especificada, mediante Alertas de registro de Azure Monitor.
Para generar una alerta si la ingesta del volumen de datos facturable en las últimas 24 horas fue superior
a 50 GB, siga estos pasos:
Definición de la condición de aler ta : especifique el área de trabajo de Log Analytics como el
destino del recurso.
Criterios de aler ta : especifique lo siguiente:
Nombre de señal : seleccione Custom log search (Búsqueda de registros personalizada)
Consulta de búsqueda en
Usage | where IsBillable | summarize DataGB = sum(Quantity / 1000.) | where DataGB > 50 .
El valor de Lógica de aler ta está Basado en el número de resultados, mientras que el valor de
Condición es Mayor que un Umbral de 0.
Período de tiempo de 1440 minutos y Frecuencia de aler ta cada 1440 minutos para
ejecutarse una vez al día.
Definición de los detalles de la aler ta : especifique lo siguiente:
Nombre en Billable data volume greater than 50 GB in 24 hours (Volumen de datos facturable
mayor que 50 GB en 24 horas)
Gravedad en Advertencia
Especifique un grupo de acciones existente o cree uno nuevo para que cuando la alerta de registro
coincida con criterios, se le notifique.
Cuando se recibe una alerta, siga los pasos de las secciones siguientes sobre cómo solucionar el problema
del uso mayor de lo esperado.
Cargos por transferencia de datos mediante Log Analytics

Al enviar datos a Log Analytics se pueden aplicar ciertos cargos debido al ancho de banda de datos. Tal
como se describe en la página de precios de Azure Bandwidth, la transferencia de datos entre los servicios
de Azure ubicados en dos regiones se cobra como transferencia de datos salientes a precio normal. La
transferencia de datos entrantes es gratuita. Sin embargo, este cargo es muy pequeño (un tanto por ciento
mínimo) en comparación con los costos de la ingesta de datos de Log Analytics. Por lo tanto, el control de
los costos de Log Analytics tiene que centrarse en el volumen de datos ingerido.
Solucionar que Log Analytics ya no recopile datos

Si tiene el plan de tarifa gratuito heredado y ha enviado más de 500 MB de datos en un día, la recopilación
de datos se detiene durante el resto del día. Alcanzar el límite diario es un motivo frecuente de que Log
Analytics deje de recopilar datos o de que parezca que faltan datos. Log Analytics crea un evento de tipo
Operación cuando la recopilación de datos se inicia y se detiene. Ejecute la siguiente consulta en la
búsqueda para comprobar si ha alcanzado el límite diario y faltan datos:
Operation | where OperationCategory == 'Data Collection Status'
Cuando se detiene la recopilación de datos, el valor de OperationStatus es Adver tencia . Cuando se inicia
la recopilación de datos, el valor de OperationStatus es Correcto . La tabla siguiente describe los motivos
por los que se detiene la recopilación de datos y una acción recomendada para reanudarla:
M OT IVO P O R EL Q UE SE DET IEN E L A REC O P IL A C IÓ N SO L UC IÓ N

M OT IVO P O R EL Q UE SE DET IEN E L A REC O P IL A C IÓ N SO L UC IÓ N
Se alcanzó el límite diario del área de trabajo Espere para que se reinicie automáticamente la
recopilación o aumente el límite diario de volumen de
datos que se describe en Administración del volumen de
datos diario máximo El tiempo de restablecimiento del
límite diario se muestra en la página Límite diario .
El área de trabajo ha alcanzado la tasa de volumen de En las áreas de trabajo se aplica un umbral de velocidad
ingesta de datos. de volumen de ingesta de datos de 500 MB
(comprimidos), que es aproximadamente 6 GB/min sin
comprimir (el tamaño real puede variar entre los tipos de
datos en función de la longitud del registro y su relación
de compresión). Este umbral se aplica a todos los datos
ingeridos, tanto si se envían desde recursos de Azure
mediante la configuración de diagnóstico, Data Collector
API o agentes. Cuando se envían datos a un área de
trabajo a una velocidad superior al 80 % del umbral
configurado en el área de trabajo, se envía un evento a la
tabla Operación del área de trabajo cada 6 horas
mientras se siga superando el umbral. Cuando la
velocidad de ingesta del volumen supera el umbral, se
quitan algunos datos y se envía un evento a la tabla
Operación del área de trabajo cada 6 horas mientras se
siga superando el umbral. Si la velocidad de ingesta del
sigue superando el umbral o prevé que lo va a alcanzar
pronto, puede abrir una solicitud de soporte técnico para
solicitar su aumento en su área de trabajo. Para recibir
una notificación de este evento en el área de trabajo, cree
una regla de alerta de registro mediante la siguiente
consulta que utiliza lógica de alerta basada en un número
de resultados superior a cero, un periodo de evaluación
de 5 minutos y una frecuencia de 5 minutos. La velocidad
de ingesta del volumen ha alcanzado el 80 % del umbral:
Operation | where OperationCategory ==
"Ingestion" | where Detail startswith "The data
ingestion volume rate crossed 80% of the
threshold"
. La velocidad de ingesta del volumen ha alcanzado el
umbral:
Operation | where OperationCategory ==
"Ingestion" | where Detail startswith "The data
ingestion volume rate crossed the threshold"
.
Se alcanzó el límite diario del plan de tarifa Gratis Espere hasta el día siguiente para que la recopilación se
heredado reinicie automáticamente, o cambie a un plan de tarifa de
pago.
La suscripción de Azure está en estado suspendido Cambie a una suscripción de pago

debido a: Quite el límite o espere a que se restablezca
Prueba gratuita finalizada
Pase para Azure expirado
Se ha alcanzado el límite de gasto mensual (por ejemplo,
en una suscripción de MSDN o Visual Studio)
Para recibir una notificación cuando se detenga la recopilación de datos, siga los pasos descritos en la
alerta Crear límite de datos diario para recibir una notificación cuando se detenga la recopilación de datos.
Siga los pasos descritos en Crear un grupo de acciones para configurar una acción de correo electrónico,
de webhook o de runbook para la regla de alerta.
Resumen de límites
Existen algunas limitaciones adicionales de Log Analytics, algunas de los cuales dependen del plan de
tarifa de Log Analytics. Se documentan en Límites, cuotas y restricciones de suscripción y servicios de
Microsoft Azure.
Pasos siguientes
Consulte Log searches in Azure Monitor Logs (Búsquedas de registros en el registro de Azure Monitor)
para obtener información sobre cómo usar el lenguaje de búsqueda. Puede utilizar las consultas de
búsqueda para realizar análisis adicionales sobre los datos de uso.
Siga los pasos explicados en Crear una nueva alerta de registro para recibir una notificación cuando se
cumplan los criterios de búsqueda.
Use la selección de destino de solución para recopilar datos solo de los grupos de equipos necesarios.
Para configurar una directiva eficaz de recopilación de eventos, revise la Directiva de filtrado de Azure
Security Center.
Cambie la configuración de los contadores de rendimiento.
Para modificar la configuración de recopilación de eventos, revise la configuración de registros de
eventos.
Para modificar la configuración de la recopilación de syslog, revise la configuración de syslog.
Introducción a los registros de plataforma
Azure
Los registros de plataforma proporcionan información detallada de diagnóstico y auditoría para

los recursos de Azure y la plataforma Azure de la que dependen. Se generan automáticamente,
aunque es necesario configurar determinados registros de plataforma para que se reenvíen a
uno o varios destinos para la conservación. En este artículo se proporciona información general
sobre los registros de plataforma, incluida la información que proporcionan y cómo puede
configurarlos para la recopilación y el análisis.
Tipos de registros de plataforma

En la tabla siguiente se enumeran los registros de plataforma específicos disponibles en
diferentes capas de Azure.
LO G N IVEL DESC RIP C IÓ N
Registros de recursos Recursos de Azure. Proporcionan una visión general

de las operaciones realizadas
dentro del mismo recurso de
Azure (en el plano de datos), por
ejemplo, obtener un secreto de
un almacén de claves o realizar
una solicitud en una base de
datos. El contenido de estos
registros de recurso varía según
el servicio de Azure y el tipo de
recurso.
Los registros de recurso se

conocían anteriormente como
registros de diagnóstico.
Registro de actividad Suscripción de Azure Proporciona una visión general

de las operaciones de cada
recurso de Azure de la
suscripción desde fuera (en el
plano de administración) y de las
actualizaciones de los eventos de
Service Health. Use el registro de
actividad para dar respuesta a los
interrogantes qué, quién y
cuándo de las operaciones de
escritura (PUT, POST, DELETE) en
los recursos de la suscripción.
Hay un único registro de
actividad para cada suscripción
de Azure.
LO G N IVEL DESC RIP C IÓ N
Registros de Inquilino de Azure Contienen el historial de la

Azure Active Directory actividad de inicio de sesión y la
traza de auditoría de los cambios
realizados en
Azure Active Directory para un
inquilino determinado.
NOTE
El registro de actividad de Azure sirve principalmente para las actividades que se producen en Azure
Resource Manager. No hace seguimiento de los recursos que usan el modelo Clásico/RDFE. Algunos tipos
de recursos clásicos tienen un proveedor de recursos de servidor proxy en Azure Resource Manager (por
ejemplo, Microsoft.ClassicCompute). Si interactúa con un tipo de recurso clásico a través de Azure
Resource Manager con estos proveedores de recursos de servidor proxy, las operaciones aparecen en el
registro de actividad. Si interactúa con un tipo de recurso clásico fuera de los servidores proxy de Azure
Resource Manager, sus acciones solo se registran en el registro de operaciones. Se puede examinar el
registro de operaciones en una sección independiente del portal.
Visualización de los registros de plataforma

Existen diferentes opciones para ver y analizar los distintos registros de plataforma de Azure.
Vea el registro de actividades en los eventos de acceso y Azure Portal desde PowerShell y la
CLI. Consulte Visualización del registro de actividad para más información.
Consulte los informes de actividad y seguridad de Azure Active Directory en Azure Portal.
Consulte ¿Qué son los informes de Azure Active Directory? para obtener más detalles.
Los registros de recurso los generan los recursos de Azure compatibles automáticamente,
pero su visualización no está disponible a menos que los envíe a un destino.
Destinations
Puede enviar registros de plataforma a uno o varios de los destinos de la tabla siguiente en
función de sus requisitos de supervisión. Configure los destinos para los registros de plataforma
mediante la creación de una configuración de diagnóstico.
DEST IN AT IO N DESC RIP C IÓ N

Área de trabajo de Log Analytics Analice todos los registros de

todos los recursos de Azure en
conjunto y aproveche las
ventajas de todas las
características disponibles para
los registros de Azure Monitor,
incluidas las consultas de registro
y las alertas de registro. Ancle los
resultados de una consulta de
registro a un panel de Azure o
inclúyala en un libro como parte
de un informe interactivo.
Centro de eventos Envíe datos de registro de la

plataforma fuera de Azure, por
ejemplo a un sistema SIEM de
terceros o una plataforma de
telemetría personalizada.
Almacenamiento de Azure Archive los registros para la

auditoría o la copia de seguridad.
Consulte Creación de una configuración de diagnóstico para enviar los registros y las métricas
de la plataforma a diferentes destinos para más información sobre la creación de una
configuración de diagnóstico para el registro de actividad o los registros de recursos.
Para más información sobre cómo crear una configuración de diagnóstico para los registros
de Azure Active Directory, consulte los siguientes artículos.
Integración de los registros de Azure AD con los registros de Azure Monitor
Tutorial: Transmisión de registros de Azure Active Directory a un centro de eventos de
Azure
Tutorial: Archivo de los registros de Azure AD en una cuenta de Azure Storage
Pasos siguientes
Más información acerca del registro de actividad
Más información sobre los registros de recursos
El Registro de actividad es un registro de plataforma de Azure que proporciona información de los eventos de
nivel de suscripción. Esto incluye información como cuándo se modificó un recurso o cuándo se inició una
máquina virtual. Puede ver el registro de actividad en Azure Portal o recuperar entradas con PowerShell y la
CLI. Para obtener más funciones, debe crear una configuración de diagnóstico para enviar el registro de
actividad a los registros de Azure Monitor, a Azure Event Hubs para reenviarlo fuera de Azure o a Azure
Storage para archivarlo. En este artículo se proporcionan detalles sobre cómo visualizar el registro de actividad
y enviarlo a diversos destinos.
Vea Creación de una configuración de diagnóstico para enviar registros de plataforma y métricas a diferentes
destinos para obtener más detalles sobre la creación y la configuración de las opciones de diagnóstico.
NOTE
Las entradas del registro de actividad son generadas por el sistema y no se pueden cambiar ni eliminar.
Visualización del registro de actividad

Puede acceder al registro de actividad desde la mayoría de los menús de Azure Portal. El menú en el que lo
abra determinará el filtro inicial. Si lo abre desde el menú Super visión , el único filtro estará en la suscripción.
Si lo abre desde el menú de un recurso, el filtro se establecerá en ese recurso. Aun así, siempre puede cambiar
el filtro para ver todas las demás entradas. Haga clic en Agregar filtro para agregar propiedades adicionales
al filtro.
Para obtener una descripción de las categorías del registro de actividad, vea Esquema de eventos del registro
de actividad de Azure.
Visualización del historial de cambios
En el caso de algunos eventos, puede ver el historial de cambios, en el que se muestran los cambios que se han
producido durante la hora del evento. Seleccione un evento del registro de actividad del que desee obtener
información más detallada. Seleccione la pestaña Historial de cambios (versión preliminar) para ver los
cambios asociados a ese evento.
Si hay cambios asociados con el evento, verá una lista de cambios que puede seleccionar. Se abrirá la página
Historial de cambios (versión preliminar) . En esta página verá los cambios realizados en el recurso. El
siguiente ejemplo, puede ver no solo que la máquina virtual cambió de tamaño, sino también cuál era el
tamaño de la máquina virtual antes de ese cambio y a qué cambió. Para obtener más información sobre el
historial de cambios, vea Obtención de los cambios del recurso.
Otros métodos para recuperar eventos del registro de actividad

También puede acceder a los eventos del registro de actividad mediante los métodos siguientes.
Use el cmdlet Get-AzLog para recuperar el registro de actividad de PowerShell. Vea Ejemplos de PowerShell
de Azure Monitor.
Use az monitor activity-log para recuperar el registro de actividad de la CLI. Consulte los ejemplos de CLI de
Azure Monitor.
Use la API REST de Azure Monitor para recuperar el registro de actividad de un cliente de REST.
Envío al área de trabajo de Log Analytics

Envíe el registro de actividad a un área de trabajo de Log Analytics para habilitar las características de los
registros de Azure Monitor, entre lo que se incluye lo siguiente:
Correlacionar los datos del registro de actividad con otros datos de supervisión recopilados por Azure
Monitor.
Consolidar las entradas de registro de varias suscripciones e inquilinos de Azure en una ubicación para su
análisis conjunto.
Usar las consultas de registro para realizar un análisis complejo y obtener información detallada sobre las
entradas del registro de actividad.
Usar las alertas de registro con entradas de actividad, lo que permite una lógica de alertas más compleja.
Almacenar las entradas del registro de actividad durante más de 90 días.
No se generan cargos por ingesta ni retención de datos para los datos del registro de actividad
almacenados en un área de trabajo de Log Analytics.
Cree una configuración de diagnóstico para enviar el registro de actividad a un área de trabajo de Log
Analytics. Puede enviar el registro de actividad desde cualquier suscripción única hasta un máximo de cinco
áreas de trabajo. La recopilación de registros entre inquilinos requiere Azure Lighthouse.
Los datos del registro de actividad de un área de trabajo de Log Analytics se almacenan en una tabla
denominada AzureActivity que se puede recuperar con una consulta de registro en Log Analytics. La estructura
de esta tabla varía en función de la categoría de la entrada de registro. Para obtener una descripción de las
propiedades de la tabla, vea la referencia de datos de Azure Monitor.
Por ejemplo, para ver un recuento de las entradas del registro de actividad para cada categoría, use la consulta
siguiente.
AzureActivity
| summarize count() by Category
Para recuperar todos los registros de la categoría administrativa, use la consulta siguiente.
AzureActivity
| where Category == "Administrative"
Envío a Azure Event Hubs

Envíe el registro de actividad a Azure Event Hubs para enviar entradas fuera de Azure, por ejemplo, a un SIEM
de terceros o a otras soluciones de Log Analytics. Los eventos del registro de actividad de los centros de
eventos se consumen en formato JSON con un elemento records que contiene los registros de cada carga. El
esquema depende de la categoría y se describe en Esquema de la cuenta de almacenamiento y los centros de
eventos.
A continuación se muestran datos de salida de ejemplo de Event Hubs para un registro de actividad:
{
"records": [
{
"time": "2019-01-21T22:14:26.9792776Z",
"resourceId":
"/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841
",
"operationName": "microsoft.support/supporttickets/write",
"category": "Write",
"resultType": "Success",
"resultSignature": "Succeeded.Created",
"durationMs": 2826,
"callerIpAddress": "111.111.111.11",
"correlationId": "c776f9f4-36e5-4e0e-809b-c9b3c3fb62a8",
"identity": {
"authorization": {
"scope":
"/subscriptions/s1/resourceGroups/MSSupportGroup/providers/microsoft.support/supporttickets/115012112305841
",
"action": "microsoft.support/supporttickets/write",
"evidence": {
"role": "Subscription Admin"
}
},
"claims": {
"aud": "https://management.core.windows.net/",
"iss": "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
"iat": "1421876371",
"nbf": "1421876371",
"exp": "1421880271",
"ver": "1.0",
"http://schemas.microsoft.com/identity/claims/tenantid": "00000000-0000-0000-0000-
000000000000",
"http://schemas.microsoft.com/claims/authnmethodsreferences": "pwd",
"http://schemas.microsoft.com/identity/claims/objectidentifier": "2468adf0-8211-44e3-
95xq-85137af64708",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn": "admin@contoso.com",
"puid": "20030000801A118C",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":
"9vckmEGF7zDKk1YzIY8k0t1_EAPaXoeHyPRn6f413zM",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname": "John",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname": "Smith",
"name": "John Smith",
"groups": "cacfe77c-e058-4712-83qw-f9b08849fd60,7f71d11d-4c41-4b23-99d2-
d32ce7aa621c,31522864-0578-4ea0-9gdc-e66cc564d18c",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name": " admin@contoso.com",
"appid": "c44b4083-3bq0-49c1-b47d-974e53cbdf3c",
"appidacr": "2",
"http://schemas.microsoft.com/identity/claims/scope": "user_impersonation",
"http://schemas.microsoft.com/claims/authnclassreference": "1"
}
},
"level": "Information",
"properties": {
"statusCode": "Created",
"serviceRequestId": "50d5cddb-8ca0-47ad-9b80-6cde2207f97c"
}
}
]
}
Envío a Azure Storage

Envíe el registro de actividad a una cuenta de Azure Storage si quiere conservar los datos de registro durante
más de 90 días para la auditoría, el análisis estático o la copia de seguridad. Si solo necesita conservar los
eventos durante 90 días o menos, no es necesario configurar el archivado en una cuenta de almacenamiento,
ya que los eventos del registro de actividades se conservan en la plataforma de Azure durante 90 días.
Cuando envíe el registro de actividad a Azure, se creará un contenedor de almacenamiento en la cuenta de
almacenamiento en cuanto se produzca un evento. Los blobs del contenedor usan la siguiente convención de
nomenclatura:
insights-activity-logs/resourceId=/SUBSCRIPTIONS/{subscription ID}/y={four-digit numeric year}/m={two-digit

numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
Por ejemplo, un blob podría tener un nombre similar al siguiente:
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/y=2020/m=06/d=08/h=18/m=00/PT1H.json
Cada blob PT1H.json contiene un blob JSON de eventos que se produjeron en la hora especificada en la
dirección URL del blob (por ejemplo h=12). Durante la hora en cuestión, los eventos se anexan al archivo
PT1H.json a medida que se producen. El valor en minutos (m = 00) siempre es 00, ya que los eventos del
registro de recurso se dividen en blobs individuales por hora.
Cada evento se almacena en el archivo PT1H.json con el siguiente formato que usa un esquema de nivel
superior común, pero es único para cada categoría, tal como se describe en Esquema del registro de actividad.
{ "time": "2020-06-12T13:07:46.766Z", "resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-

000000000000/RESOURCEGROUPS/MY-RESOURCE-GROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/MV-VM-01",
"correlationId": "0f0cb6b4-804b-4129-b893-70aeeb63997e", "operationName":
"Microsoft.Resourcehealth/healthevent/Updated/action", "level": "Information", "resultType": "Updated",
"category": "ResourceHealth", "properties": {"eventCategory":"ResourceHealth","eventProperties":
{"title":"This virtual machine is starting as requested by an authorized user or process. It will be online
shortly.","details":"VirtualMachineStartInitiatedByControlPlane","currentHealthStatus":"Unknown","previousH
ealthStatus":"Unknown","type":"Downtime","cause":"UserInitiated"}}}
Métodos de recopilación heredados

En esta sección se describen los métodos heredados para recopilar el registro de actividad que se usó antes de
la configuración de diagnóstico. Si usa estos métodos, debería considerar la posibilidad de realizar la transición
a la configuración de diagnóstico, ya que proporciona una mejor funcionalidad y coherencia con los registros
de recursos.
Perfiles de registro
Los perfiles de registro son el método heredado para enviar el registro de actividad a Azure Storage o Event
Hubs. Use el siguiente procedimiento para seguir trabajando con un perfil de registro o deshabilitarlo como
preparación para la migración a una configuración de diagnóstico.
1. En el menú Azure Monitor de Azure Portal, seleccione Registro de actividad .
2. Haga clic en Configuración de diagnóstico .
3. Haga clic en el banner de color púrpura de la experiencia heredada.
Configuración del perfil de registro mediante PowerShell

Si ya existe un perfil de registro, primero debe quitarlo y luego crear uno nuevo.
1. Use Get-AzLogProfile para identificar si existe un perfil de registro. Si existe un perfil de registro, busque
la propiedad name.
2. Use Remove-AzLogProfile para quitar el perfil de registro mediante el valor de la propiedad name.
# For example, if the log profile name is 'default'

Remove-AzLogProfile -Name "default"
3. Use Add-AzLogProfile para crear un nuevo perfil de registro:
Add-AzLogProfile -Name my_log_profile -StorageAccountId

/subscriptions/s1/resourceGroups/myrg1/providers/Microsoft.Storage/storageAccounts/my_storage -
serviceBusRuleId /subscriptions/s1/resourceGroups/Default-ServiceBus-
EastUS/providers/Microsoft.ServiceBus/namespaces/mytestSB/authorizationrules/RootManageSharedAccessK
ey -Location global,westus,eastus -RetentionInDays 90 -Category Write,Delete,Action
P RO P IEDA D O B L IGATO RIO DESC RIP C IÓ N
Nombre Sí Nombre de su perfil de registro.
StorageAccountId No Identificador de recurso de la

cuenta de almacenamiento donde
se debe guardar el registro de
actividad.
serviceBusRuleId No Identificador de regla de Service Bus

para el espacio de nombres de
Service Bus donde desea que se
creen centros de eventos. Se trata
de una cadena con este formato:
{service bus resource
ID}/authorizationrules/{key
name}
.
Location Sí Lista separada por comas de las

regiones para las que desea
recopilar eventos del registro de
actividad.
RetentionInDays Sí Número de días que deben

retenerse los eventos en la cuenta
de almacenamiento, entre 1 y 365.
Con el valor cero, se almacenan los
registros indefinidamente.
Category No Lista separada por comas de las

categorías de eventos que deben
recopilarse. Los valores posibles son
Write, Delete y Action.
Script de ejemplo
A continuación se muestra un script de ejemplo de PowerShell para crear un perfil de registro que escribe el
registro de actividad en una cuenta de almacenamiento y en un centro de eventos.
# Settings needed for the new log profile

$logProfileName = "default"
$locations = (Get-AzLocation).Location
$locations += "global"
$subscriptionId = "<your Azure subscription Id>"
$resourceGroupName = "<resource group name your event hub belongs to>"
$eventHubNamespace = "<event hub namespace>"
# Build the service bus rule Id from the settings above

$serviceBusRuleId =
"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.EventHub/namespaces/$
eventHubNamespace/authorizationrules/RootManageSharedAccessKey"
# Build the storage account Id from the settings above

$storageAccountId =
"/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Storage/storageAccoun
ts/$storageAccountName"
Add-AzLogProfile -Name $logProfileName -Location $locations -ServiceBusRuleId $serviceBusRuleId
Configuración del perfil de registro mediante la CLI de Azure

Si ya existe un perfil de registro, primero debe quitar el perfil de registro existente y luego crear un nuevo perfil
de registro.
1. Use az monitor log-profiles list para identificar si existe un perfil de registro.
2. Use az monitor log-profiles delete --name "<log profile name> para quitar el perfil de registro
mediante el valor de la propiedad name.
3. Use az monitor log-profiles create para crear un nuevo perfil de registro:
az monitor log-profiles create --name "default" --location null --locations "global" "eastus"
"westus" --categories "Delete" "Write" "Action" --enabled false --days 0 --service-bus-rule-id
"/subscriptions/<YOUR SUBSCRIPTION ID>/resourceGroups/<RESOURCE GROUP
NAME>/providers/Microsoft.EventHub/namespaces/<EVENT HUB NAME
SPACE>/authorizationrules/RootManageSharedAccessKey"
name Sí Nombre de su perfil de registro.
storage-account-id Sí Identificador de recurso de la

cuenta de almacenamiento donde
se deben guardar los registros de
actividades.
locations Sí Lista separada por espacios de las

regiones para las que desea
recopilar eventos del registro de
actividad. Puede ver una lista de
todas las regiones para la
suscripción con
az account list-locations --
query [].name
.
days Sí Número de días que deben

retenerse los eventos, entre 1 y
365. Con el valor cero, se
almacenarán los registros
indefinidamente (de manera
indefinida). Si el valor es cero, el
parámetro enabled se debe
establecer en false.
enabled Sí True o False. Se usa para habilitar o

deshabilitar la directiva de
retención. Si el valor es True, el
parámetro de días debe ser un valor
mayor que 0.
categories Sí Lista separada por espacios de las

categorías de eventos que deben
recopilarse. Los valores posibles son
Write, Delete y Action.
Área de trabajo de Log Analytics

El método heredado para enviar el registro de actividad en un área de trabajo de Log Analytics está conectando
el registro en la configuración del área de trabajo.
1. Desde el menú Áreas de trabajo de Log Analytics en Azure Portal, seleccione el área de trabajo para
recopilar el registro de actividad.
2. En la sección Orígenes de datos del área de trabajo del menú del área de trabajo, seleccione
Registro de actividad de Azure .
3. Haga clic en la suscripción que desea conectar.
4. Haga clic en Conectar para conectar el registro de actividad en la suscripción al área de trabajo
seleccionada. Si la suscripción ya está conectada a otra área de trabajo, haga clic en Desconectar
primero para desconectarla.
Para deshabilitar la configuración, realice el mismo procedimiento y haga clic en Desconectar para quitar la
suscripción del área de trabajo.
Cambios en la estructura de datos
La configuración de diagnóstico envía los mismos datos que el método heredado que se usa para enviar el
registro de actividad con algunos cambios en la estructura de la tabla AzureActivity.
Las columnas de la tabla siguiente están en desuso en el esquema actualizado. Todavía existen en AzureActivity,
pero no tienen datos. El reemplazo de estas columnas no es nuevo, pero contiene los mismos datos que la
columna en desuso. Tienen un formato distinto, por lo que es posible que tenga que modificar las consultas de
registro que las utilizan.
C O L UM N A EN DESUSO C O L UM N A DE REEM P L A Z O
ActivityStatus ActivityStatusValue
ActivitySubstatus ActivitySubstatusValue
OperationName OperationNameValue
ResourceProvider ResourceProviderValue
IMPORTANT
En algunos casos, los valores de estas columnas pueden estar en mayúsculas. Si tiene una consulta que incluye estas
columnas, debe usar el operador =~ para realizar una comparación sin distinguir entre mayúsculas y minúsculas.
La columna siguiente se ha agregado a AzureActivity en el esquema actualizado:

Authorization_d
Claims_d
Properties_d
Solución de supervisión de Activity Log Analytics

La solución de supervisión de Azure Log Analytics entrará en desuso pronto y se reemplazará por un libro que
use el esquema actualizado en el área de trabajo de Log Analytics. Puede seguir usando la solución si ya está
habilitada, pero solo se puede usar si va a recopilar el registro de actividad mediante la configuración
heredada.
Uso de la solución
A las soluciones de supervisión se accede desde el menú Super visar de Azure Portal. Seleccione Más en la
sección Información detallada para abrir la página Información general con los iconos de la solución. El
icono Registros de actividad de Azure muestra un recuento del número de registros AzureActivity del
área de trabajo.
Haga clic en el icono Registros de actividad de Azure para abrir la vista Registros de actividad de
Azure . La vista incluye los elementos de visualización de la tabla siguiente. Cada uno de ellos muestra hasta
otros diez elementos que coinciden con sus criterios para el intervalo de tiempo especificado. Puede ejecutar
una consulta de registros que devuelve todos los registros coincidentes; para ello, haga clic en Ver todo en la
parte inferior del elemento.
Habilitación de la solución para nuevas suscripciones
Pronto dejará de poder agregar la solución de Activity Logs Analytics a la suscripción mediante Azure Portal.
Puede agregarlo mediante el siguiente procedimiento con una plantilla de Resource Manager.
1. Copie el siguiente JSON en un archivo denominado ActivityLogTemplate
{
"$schema": "https://schema.management.azure.com/schemas/2014-04-01-
preview/deploymentTemplate.json#",
"parameters": {
"workspaceName": {
"type": "String",
"defaultValue": "my-workspace",
"metadata": {
"description": "Specifies the name of the workspace."
}
},
"location": {
"type": "String",
"allowedValues": [
"east us",
"west us",
"australia central",
"west europe"
],
"defaultValue": "australia central",
"metadata": {
}
}
},
"resources": [
{
"properties": {
"features": {
"searchVersion": 2
}
}
},
{
"type": "Microsoft.OperationsManagement/solutions",
"name": "[concat('AzureActivity(', parameters('workspaceName'),')')]",
"dependsOn": [
"[resourceId('microsoft.operationalinsights/workspaces', parameters('workspaceName'))]"
],
"plan": {
"name": "[concat('AzureActivity(', parameters('workspaceName'),')')]",
"promotionCode": "",
"product": "OMSGallery/AzureActivity",
"publisher": "Microsoft"
},
"properties": {
"workspaceResourceId": "[resourceId('microsoft.operationalinsights/workspaces',
parameters('workspaceName'))]",
"containedResources": [
"[concat(resourceId('microsoft.operationalinsights/workspaces',
parameters('workspaceName')), '/views/AzureActivity(',parameters('workspaceName'))]"
]
}
},
{
"type": "Microsoft.OperationalInsights/workspaces/datasources",
"kind": "AzureActivityLog",
"name": "[concat(parameters('workspaceName'), '/', subscription().subscriptionId)]",
"dependsOn": [
"[parameters('WorkspaceName')]"
],
"properties": {
"linkedResourceId": "[concat(subscription().Id,
'/providers/microsoft.insights/eventTypes/management')]"
}
}
]
}
2. Implemente la plantilla con los siguientes comandos de PowerShell:
Connect-AzAccount
Select-AzSubscription <SubscriptionName>
New-AzResourceGroupDeployment -Name activitysolution -ResourceGroupName <ResourceGroup> -
TemplateFile <Path to template file>
Pasos siguientes
Creación de la configuración de diagnóstico para enviar registros de actividad a otros destinos
Registros de recursos de Azure
Los registros de recursos de Azure son registros de plataforma que proporcionan información sobre las
operaciones que se realizaron en un recurso de Azure. El contenido de estos registros de recurso varía según el
servicio de Azure y el tipo de recurso. Los registros de recurso no se recopilan de forma predeterminada. Debe
crear una configuración de diagnóstico para cada recurso de Azure con el fin de enviar sus registros de recursos a
un área de trabajo Log Analytics que se usará con registros de Azure Monitor, Azure Event Hubs para reenviar
fuera de Azure o Azure Storage para el archivado.
Consulte Creación de una configuración de diagnóstico para enviar registros de plataforma y métricas a
diferentes destinos para obtener más información sobre cómo crear una configuración de diagnóstico, así como
Implementación de Azure Monitor a escala mediante Azure Policy para obtener más información sobre el uso de
Azure Policy para crear automáticamente una configuración de diagnóstico para cada recurso de Azure que cree.
Envío al área de trabajo de Log Analytics

Envíe los registros de recursos a un área de trabajo de Log Analytics para habilitar las características de los
registros de Azure Monitor, entre lo que se incluye lo siguiente:
Correlacionar los datos del registro de recurso con otros datos de supervisión recopilados por Azure Monitor.
Consolidar las entradas de registro de varios inquilinos, suscripciones y recursos de Azure en una ubicación
para su análisis conjunto.
Usar las consultas de registro para realizar un análisis complejo y obtener información detallada sobre los
datos de registro.
Usar las alertas de registro con lógicas de alertas complejas.
Cree una configuración de diagnóstico para enviar los registro de recursos a un área de trabajo de Log Analytics.
Estos datos se almacenan en tablas, tal como se describe en Estructura de registros de Azure Monitor. Las tablas
que usan los registros de recurso dependen del tipo de colección del recurso:
Azure Diagnostics: todos los datos se escriben en la tabla AzureDiagnostics.
Específicos del recurso: los datos se escriben en una tabla individual para cada categoría del recurso.
Modo Azure Diagnostics
En este modo se recopilan todos los datos de cualquier configuración de diagnóstico en la tabla
AzureDiagnostics. Este es el método heredado que usa hoy la mayoría de los servicios de Azure. Dado que varios
recursos envían datos a la misma tabla, el esquema de esta tabla es el superconjunto de los esquemas de todos
los tipos de datos diferentes que se recopilan.
Considere el ejemplo siguiente, donde se recopila la configuración de diagnóstico en la misma área de trabajo
para los siguientes tipos de datos:
Registros de auditoría del servicio 1 (con un esquema que consta de las columnas A, B y C)
Registros de errores del servicio 1 (con un esquema que consta de las columnas D, E y F)
Registros de auditoría del servicio 2 (con un esquema que consta de las columnas G, H e I)
La tabla AzureDiagnostics tendrá el siguiente aspecto:
RESO U
RC EP R
O VIDE C AT EG
R O RY A B C D E F G H I
Micros AuditL x1 y1 z1
oft.Ser ogs
vice1
Micros ErrorLo q1 w1 e1
oft.Ser gs
vice1
Micros AuditL j1 k1 l1
oft.Ser ogs
vice2
Micros ErrorLo q2 w2 e2
oft.Ser gs
vice1
Micros AuditL j3 k3 l3
oft.Ser ogs
vice2
Micros AuditL x5 y5 z5
oft.Ser ogs
vice1
Específico del recurso

En este modo se crean tablas individuales en el área de trabajo seleccionada para cada categoría seleccionada en
la configuración de diagnóstico. Se recomienda este método porque facilita el trabajo con los datos en las
consultas de registro, proporciona mejor capacidad de detección de esquemas y su estructura, mejora el
rendimiento en la latencia de ingesta y en los tiempos de consulta, y ofrece la capacidad de conceder derechos de
RBAC en un tabla específica. Todos los servicios de Azure se migrarán finalmente al modo específico del recurso.
En el ejemplo anterior, esto daría lugar a la creación de tres tablas:
Tabla Service1AuditLogs:
P RO VEEDO R DE
REC URSO S C AT EGO RY A B C
Service1 AuditLogs x1 y1 z1
Service1 AuditLogs x5 y5 z5
Tabla Service1ErrorLogs:
P RO VEEDO R DE
REC URSO S C AT EGO RY D E F
Service1 ErrorLogs q1 w1 e1
P RO VEEDO R DE
REC URSO S C AT EGO RY D E F
Service1 ErrorLogs q2 w2 e2
Tabla Service2AuditLogs:
P RO VEEDO R DE
REC URSO S C AT EGO RY G H I
Service2 AuditLogs j1 k1 l1
Service2 AuditLogs j3 k3 l3
Selección del modo de recopilación

La mayoría de los recursos de Azure escribirán los datos en el área de trabajo en modo Azure Diagnostics o
específico del recurso sin que usted pueda elegir. Consulte la documentación para cada servicio para más
información sobre el modo que usa. Todos los servicios de Azure usarán finalmente el modo específico del
recurso. Como parte de esta transición, algunos recursos permitirán seleccionar un modo en la configuración de
diagnóstico. Especifique el modo específico del recurso para las configuraciones de diagnóstico nuevas, ya que
esto facilita la administración de los datos y puede ayudar a evitar migraciones complejas posteriores.
NOTE
Para ver un ejemplo de configuración del modo de recopilación mediante una plantilla de Resource Manager, consulte
Ejemplos de plantillas de Resource Manager para la configuración de diagnóstico en Azure Monitor.
En el modo específico del recurso se puede modificar una configuración de diagnóstico existente. En este caso, los
datos que ya se han recopilado permanecerán en la tabla AzureDiagnostics hasta que se eliminen de acuerdo con
la configuración de retención del área de trabajo. Los nuevos datos se recopilarán en la tabla dedicada. Use el
operador union para consultar datos en ambas tablas.
Puede continuar por el blog Actualizaciones de Azure para ver noticias sobre los servicios de Azure que admiten
el modo específico del recurso.
Límite de columnas en AzureDiagnostics
En los registros de Azure Monitor hay un límite de 500 propiedades por tabla. Una vez alcanzado este límite,
cualquier fila que contenga datos con cualquier propiedad fuera de las primeras 500 se eliminará en el momento
de la ingesta. Estos límites afectan particularmente a la tabla AzureDiagnostics, ya que incluye propiedades para
todos los servicios de Azure que escriben en ella.
Si va a recopilar registros de recursos de varios servicios, AzureDiagnostics puede superar este límite, y se
omitirán datos. Hasta que todos los servicios de Azure admitan el modo específico del recurso, debe configurar
los recursos para escribir en varias áreas de trabajo con el fin de reducir la posibilidad de alcanzar el límite de 500
columnas.
Azure Data Factory
Azure Data Factory, debido a un conjunto detallado de registros, es un servicio del cual se sabe que escribe un
gran número de columnas y que puede provocar que AzureDiagnostics supere el límite. Para cualquier
configuración de diagnóstico configurada antes de que se habilitara el modo específico del recurso, se creará una
nueva columna para cada parámetro de usuario con nombre único en cualquier actividad. Se crearán más
columnas debido a la naturaleza detallada de las entradas y salidas de la actividad.
Debe migrar los registros para usar el modo específico del recurso lo antes posible. Si no puede hacerlo
inmediatamente, una solución alternativa provisional es aislar los registros de Azure Data Factory en su propia
área de trabajo para minimizar la posibilidad de que estos registros afecten a otros tipos de registro que se
recopilan en las áreas de trabajo.
Envío a Azure Event Hubs

Envíe los registros de recursos al centro de eventos para enviarlos fuera de Azure, por ejemplo, a un SIEM de
terceros o a otras soluciones de Log Analytics. Los registros de recursos de los centros de eventos se consumen
en formato JSON con un elemento records que contiene los registros de cada carga. El esquema depende del
tipo de recurso, tal y como se describe en Esquema específico del servicio y común para los registros de recursos
de Azure.
A continuación se muestran datos de salida de ejemplo de Event Hubs para un registro de recursos:
{
"records": [
{
"time": "2019-07-15T18:00:22.6235064Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330013509
921957/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330013509921957",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
"clientTrackingId": "08587330013509921958"
}
}
},
{
"time": "2019-07-15T18:01:15.7532989Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330012106
702630/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Information",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330012106702630",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
"clientTrackingId": "08587330012106702632"
}
}
}
]
}
Envío a Azure Storage
Envíe registros de recursos a Azure Storage para conservarlos para archivarlos. Una vez creada la configuración
de diagnóstico, en cuanto se produzca un evento en una de las categorías de registro que haya habilitado se
creará un contenedor de almacenamiento en la cuenta de almacenamiento. Los blobs del contenedor usan la
siguiente convención de nomenclatura:
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group

name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-
digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
Por ejemplo, el blob de un grupo de seguridad de red puede tener un nombre similar al siguiente:
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-
000000000000/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=2016
/m=08/d=22/h=18/m=00/PT1H.json
Cada blob PT1H.json contiene un blob JSON de eventos que se produjeron en la hora especificada en la dirección
URL del blob (por ejemplo h=12). Durante la hora en cuestión, los eventos se anexan al archivo PT1H.json a
medida que se producen. El valor en minutos (m = 00) siempre es 00, ya que los eventos del registro de recurso
se dividen en blobs individuales por hora.
En el archivo PT1H.json, los eventos se almacenan con este formato; con un esquema general común, pero único
para cada uno de los servicios de Azure, tal y como se describe en Esquema de los registros de recurso.
{"time": "2016-07-01T00:00:37.2040000Z","systemId": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category":

"NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-
890123456789/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","ope
rationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-
123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/
s1id1234-5679-0123-4567-
890123456789/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/secur
ityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}
NOTE
Los registros de plataforma se escriben en el almacenamiento de blobs en formato JSON Lines, donde cada evento es una
línea y el carácter de nueva línea indica un evento nuevo. Este formato se implementó en noviembre de 2018. Antes de
esta fecha, los registros se escribían en el almacenamiento de blobs como matriz JSON de registros, tal como se describe en
Preparación para el cambio de formato a los registros de plataforma de Azure Monitor archivados en una cuenta de
almacenamiento.
Pasos siguientes
Más información sobre los registros de recurso.
Creación de una configuración de diagnóstico para enviar registros de plataforma y métricas a diferentes
destinos.
Creación de una configuración de
diagnóstico para enviar los registros y las
métricas de la plataforma a diferentes
destinos
Los registros de plataforma de Azure, como los registros de recursos y los registros de actividad de
Azure, proporcionan información de diagnóstico y auditoría detallada sobre los recursos de Azure
y la plataforma de Azure de la que dependen. Las métricas de plataforma se recopilan de forma
predeterminada y suelen almacenarse en la base de datos de métricas de Azure Monitor. En este
artículo, se explica cómo crear y establecer la configuración de diagnóstico para enviar métricas y
registros de plataforma a diferentes destinos.
IMPORTANT
Antes de crear una configuración de diagnóstico para el registro de actividad, debe deshabilitar cualquier
configuración heredada. Para más información, consulte Métodos de recopilación heredados.
Cada recurso de Azure necesita su propia configuración de diagnóstico, que establece los
siguientes criterios:
Categorías de los datos de los registros y las métricas que se envían a los destinos definidos en
la configuración. Las categorías disponibles varían para los distintos tipos de recursos.
Uno o más destinos para enviar los registros. Los destinos actuales incluyen el área de trabajo
de Log Analytics, Event Hubs y Azure Storage.
Cada configuración de diagnóstico puede definir un único destino. Si desea enviar datos a más de
un tipo de destino determinado (por ejemplo, dos áreas de trabajo de Log Analytics diferentes),
cree varias configuraciones. Cada recurso puede tener hasta 5 configuraciones de diagnóstico.
El siguiente vídeo describe cómo enrutar registros de plataforma con una configuración de
diagnóstico.
NOTE
Las métricas de plataforma se envían automáticamente a las métricas de Azure Monitor. Las
configuraciones de diagnóstico se pueden usar para enviar métricas de determinados servicios de Azure a
los registros de Azure Monitor a fin de analizarlas con otros datos de supervisión mediante consultas de
registro con algunas limitaciones.
Actualmente no se admite el envío de métricas de varias dimensiones a través de la configuración de
diagnóstico. Las métricas con dimensiones se exportan como métricas unidimensionales planas agregadas
a través de los valores de dimensión. Por ejemplo: La métrica 'IOReadBytes' de una cadena de bloques
puede consultarse y representarse individualmente en cada nodo. Sin embargo, cuando se exporta
utilizando la configuración de diagnóstico, la métrica exportada representa los bytes de lectura de todos
los nodos. Además, debido a limitaciones internas, no todas las métricas se exportan a los registros de
Azure Monitor o Log Analytics. Para más información, consulte la lista de métricas exportables.
Para solucionar estas limitaciones de métricas específicas, se recomienda extraerlas manualmente mediante
la API REST de métricas e importarlas a los registros de Azure Monitor con Data Collector API de Azure
Monitor.
Destinations
Los registros y las métricas de plataforma se pueden enviar a los destinos de la tabla siguiente.
Área de trabajo de Log Analytics El envío de registros y métricas a un área de trabajo

de Log Analytics le permite analizar con otros datos
de supervisión recopilados por Azure Monitor
mediante consultas de registro eficaces, junto con
otras características de Azure Monitor, como las
alertas y las visualizaciones.
Event Hubs El envío de registros y métricas a Event Hubs permite

transmitir datos a sistemas externos, como SIEM de
terceros y otras soluciones de análisis de registros.
Cuenta de Almacenamiento de Azure Archivar los registros y las métricas en una cuenta de
almacenamiento de Azure resulta útil para realizar
auditorías, análisis estáticos o copias de seguridad. En
comparación con los registros de Azure Monitor y las
áreas de trabajo de Log Analytics, Azure Storage es
más económico y los registros se pueden mantener
indefinidamente.
Requisitos de destino
Se deben crear todos los destinos para la configuración de diagnóstico antes de crear la
configuración de diagnóstico. El destino no tiene que estar en la misma suscripción que la del
recurso que envía los registros, siempre que el usuario que realice la configuración tenga el acceso
RBAC adecuado a ambas suscripciones. En la tabla siguiente se proporcionan los requisitos únicos
para cada destino, incluidas las restricciones regionales.
DEST IN AT IO N REQ UISITO S
Área de trabajo de Log Analytics No es necesario que el área de trabajo esté en la

misma región que el recurso que se esté
supervisando.
DEST IN AT IO N REQ UISITO S
Centros de eventos La directiva de acceso compartido del espacio de

nombres define los permisos que tiene el mecanismo
de transmisión. Para transmitir a Event Hubs, se
necesitan permisos de administración, envío y
escucha. Para actualizar la configuración de
diagnóstico para incluir la transmisión, debe tener el
permiso ListKey sobre esa regla de autorización de
Event Hubs.
El espacio de nombres del centro de eventos debe

estar en la misma región que el recurso que se está
supervisando, si este es regional.
Cuenta de almacenamiento de Azure No debe utilizar una cuenta de almacenamiento

existente que tenga otros datos sin supervisión
almacenados en ella, para que pueda controlar mejor
el acceso a los datos. Sin embargo, si va a archivar el
registro de actividad y los registros de recurso, puede
que tenga sentido utilizar esa misma cuenta de
almacenamiento para mantener todos los datos de
supervisión en una ubicación central.
Para enviar los datos al almacenamiento inmutable,

establezca la directiva de inmutabilidad para la
cuenta de almacenamiento tal como se escribe en
Establecimiento y administración de directivas de
inmutabilidad para el almacenamiento de blobs.
Debe seguir todos los pasos que aparecen en este
artículo, incluida la habilitación de las escrituras de
blobs en anexos protegidos.
La cuenta de almacenamiento debe estar en la

misma región que el recurso que se esté
supervisando, si el recurso es regional.
NOTE
Actualmente, las cuentas de Azure Data Lake Storage Gen2 no se admiten como destino de la
configuración de diagnóstico, aunque pueden aparecer como una opción válida en Azure Portal.
Creación en Azure Portal

Puede realizar configuraciones de diagnóstico en Azure Portal desde el menú de Azure Monitor o
desde el menú del recurso.
1. El lugar de Azure Portal en el que se realiza la configuración de diagnóstico depende del
recurso.
Si se trata de un único recurso, en el menú de este recurso, haga clic en la opción
Configuración de diagnóstico de Super visar .
Si se trata de uno o varios recursos, en el menú de Azure Monitor, haga clic en la
opción Configuración de diagnóstico de Configuración y después en el recurso.
En el registro de actividad, haga clic en la opción Registro de actividad del menú

Azure Monitor y después en Configuración de diagnóstico . No olvide
deshabilitar cualquier configuración heredada del registro de actividad. Consulte
Deshabilitar la configuración existente para más información.
2. Si no existe ninguna configuración en el recurso que ha seleccionado, se le pide que cree

una. Haga clic en Agregar configuración de diagnóstico .
Si ya hay una configuración en el recurso, verá una lista de opciones que ya están
configuradas. Puede hacer clic en Agregar configuración de diagnóstico para agregar
una nueva configuración o Editar configuración para modificar una existente. Cada
configuración no puede tener más de uno de los tipos de destino.
3. Asigne un nombre a la configuración, si aún no lo tiene.
4. Detalles de la categoría (qué enrutar) : active la casilla de cada categoría de datos que
desee enviar a los destinos que especificará más adelante. La lista de categorías es diferente
en cada servicio de Azure.
AllMetrics enruta las métricas de plataforma de un recurso al almacén de registros
de Azure, pero en forma de registro. Normalmente, estas métricas solo se envían a la
base de datos de series temporales de métricas de Azure Monitor. Si se envían al
almacén de registros de Azure Monitor (que se puede buscar mediante Log
Analytics), tendrá que integrarlas en consultas que realicen búsquedas en otros
registros. Es posible que esta opción no esté disponible en todos los tipos de
recursos. Cuando sí está disponible, en las métricas compatibles con Azure Monitor,
se indica qué métricas se recopilan para cada tipo de recurso.
NOTE
Consulte las limitaciones para enrutar métricas a los registros de Azure Monitor
anteriormente en este artículo.
En Registros , se muestran las distintas categorías disponibles en función del tipo de

recurso. Seleccione las categorías que desee enrutar a un destino.
5. Detalles del destino : active la casilla de cada destino. Cuando se activa una casilla,
aparecen opciones que le permiten agregar información adicional.
a. Log Analytics : especifique la suscripción y el área de trabajo. Si no tiene ningún área
de trabajo, tendrá que crear una antes de continuar.
b. Centro de eventos : especifique los criterios siguientes:
La suscripción de la que forma parte el centro de eventos.
El espacio de nombres del centro de eventos. Si aún no lo ha hecho, tendrá que
crear uno.
El nombre del centro de eventos (opcional) al que se van a enviar todos los datos.
Si no especifica un nombre, se crea un centro de eventos para cada categoría de
registro. Si va a enviar varias categorías, puede especificar un nombre para limitar
el número de centros de eventos creados. Consulte Cuotas y límites de Azure
Event Hubs para más detalles.
La directiva del centro de eventos (opcional), una directiva que defina los
permisos que tiene el mecanismo de transmisión. Para más información, consulte
este artículo sobre las características de los centros de eventos.
c. Storage : elija una suscripción, una cuenta de almacenamiento y una directiva de
retención.
TIP
Considere la posibilidad de establecer la directiva de retención en 0 y eliminar manualmente
los datos de almacenamiento utilizando un trabajo programado para evitar posibles
confusiones en el futuro.
En primer lugar, si está usando el almacenamiento para archivar, querrá conservar los datos
durante más de 365 días. En segundo lugar, si elige una directiva de retención que sea
mayor que 0, la fecha de expiración se asociará a los registros cuando se almacenen. No se
puede cambiar la fecha de los registros una vez almacenados.
Si establece la directiva de retención de WorkflowRuntime en 180 días y 24 horas después
la establece en 365 días, los registros almacenados durante las primeras 24 horas se
eliminarán automáticamente a los 180 días, mientras que todos los registros posteriores de
ese mismo tipo se eliminarán automáticamente después de 365 días. Aunque
posteriormente se modifique la directiva de retención, los registros que se almacenaron
durante las 24 primeras horas no se conservarán 365 días.
6. Haga clic en Save (Guardar).

Transcurridos unos instantes, la nueva configuración aparece en la lista de configuraciones para
este recurso y los registros se transmiten a los destinos especificados en cuanto se generan nuevos
datos de eventos. Pueden pasar hasta quince minutos desde que se emite un evento hasta que
aparece en un área de trabajo de Log Analytics.
Creación mediante PowerShell

Use el cmdlet Set-AzDiagnosticSetting para crear una configuración de diagnóstico con Azure
PowerShell. Consulte la documentación de este cmdlet para las descripciones de sus parámetros.
IMPORTANT
No puede usar este método con el registro de actividad de Azure. En su lugar, siga las indicaciones de
Creación de la configuración de diagnóstico en Azure Monitor con una plantilla de Resource Manager para
crear una plantilla de Resource Manager e implementarla con PowerShell.
A continuación se muestra un cmdlet de PowerShell de ejemplo para crear una configuración de
diagnóstico con los tres destinos.
Set-AzDiagnosticSetting -Name KeyVault-Diagnostics -ResourceId /subscriptions/xxxxxxxx-xxxx-

xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault -
Category AuditEvent -MetricCategory AllMetrics -Enabled $true -StorageAccountId
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystor
ageaccount -WorkspaceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/oi-
default-east-us/providers/microsoft.operationalinsights/workspaces/myworkspace -
EventHubAuthorizationRuleId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub
/authorizationrules/RootManageSharedAccessKey
Creación mediante la CLI de Azure

Use el comando az monitor diagnostic-settings create para crear una configuración de diagnóstico
con la CLI de Azure. Consulte la documentación de este comando para las descripciones de sus
parámetros.
IMPORTANT
No puede usar este método con el registro de actividad de Azure. En su lugar, siga las indicaciones de
Creación de la configuración de diagnóstico en Azure Monitor con una plantilla de Resource Manager para
crear una plantilla de Resource Manager e implementarla con la CLI.
A continuación se muestra un comando de la CLI de ejemplo para crear una configuración de

diagnóstico con los tres destinos.
az monitor diagnostic-settings create \

--name KeyVault-Diagnostics \
--resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault \
--logs '[{"category": "AuditEvent","enabled": true}]' \
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--storage-account /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystor
ageaccount \
--workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/oi-default-
east-us/providers/microsoft.operationalinsights/workspaces/myworkspace \
--event-hub-rule /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub
/authorizationrules/RootManageSharedAccessKey
Creación mediante una plantilla de Resource Manager

Consulte Ejemplos de plantillas de Resource Manager para la configuración de diagnóstico en
Azure Monitor para crear o actualizar la configuración de diagnóstico con una plantilla de Resource
Manager.
Creación mediante la API REST

Consulte Configuración de diagnóstico para crear o actualizar configuraciones de diagnóstico
mediante la API REST de Azure Monitor.
Creación mediante Azure Policy
Dado que es necesario crear una configuración de diagnóstico para cada recurso de Azure, se
puede usar Azure Policy para crear automáticamente una configuración de diagnóstico a medida
que se crea cada recurso. Para más información, consulte Implementación de Azure Monitor a
escala mediante Azure Policy.
Pasos siguientes
Más información sobre los registros de plataforma de Azure
Introducción a las
consultas de registro en
Azure Monitor
Las consultas de registro ayudan a aprovechar al máximo

el valor de los datos recopilados en registros de Azure
Monitor. Un lenguaje de consulta eficaz permite combinar
datos de varias tablas, agregar grandes conjuntos de datos
y realizar operaciones complejas con una mínima cantidad
de código. Se puede responder casi cualquier pregunta y
realizar cualquier análisis, siempre y cuando se hayan
recopilado los datos de respaldo y comprenda cómo
construir la consulta adecuada.
Algunas características de Azure Monitor, como
conclusiones y soluciones procesan datos de registro sin
exponer las consultas subyacentes. Para aprovechar
completamente las otras características de Azure Monitor,
debe comprender cómo se construyen las consultas y
cómo puede usar estas para analizar de forma interactiva
los datos en registros de Azure Monitor.
Use este artículo como punto de partida para obtener más
información sobre consultas de registros en Azure
Monitor. Proporciona respuestas a preguntas comunes y
vínculos a otra documentación que ofrece más detalles y
lecciones.
¿Cómo puedo aprender cómo escribir

consultas?
Si desea comenzar de inmediato, puede empezar con los
siguientes tutoriales:
Introducción a Log Analytics en Azure Monitor.
Introducción a consultas de registros en Azure Monitor.
Cuando comprenda los conceptos básicos, realice varias
lecciones con sus propios datos o datos de nuestro
entorno de demostración, comenzando por la siguiente:
Trabajo con cadenas en consultas de registro de Azure
Monitor
¿Qué lenguaje usan las consultas de

registro?
Los registros de Azure Monitor se basan en Azure Data
Explorer y las consultas de registros se escriben con el
mismo lenguaje de consulta de Kusto (KQL). Esto es un
lenguaje enriquecido diseñado para ser fácil de leer y crear,
y debería poder empezar a usarlo con asistencia mínima.
Consulte la documentación sobre KQL de Azure Data
Explorer para obtener documentación completa sobre KQL
y referencia de las distintas funciones disponibles.
Consulte Introducción a las consultas de registro en Azure
Monitor para ver un tutorial rápido del lenguaje con los
datos de registros de Azure Monitor. Consulte Diferencias
en el lenguaje de consulta de los registros de Azure
Monitor para conocer las pequeñas diferencias en la
versión de KQL que Azure Monitor usa.
¿Qué datos están disponibles para

registrar consultas?
Todos los datos recopilados en los registros de Azure
Monitor están disponibles para recuperar y analizar en
consultas de registros. Diferentes orígenes de datos
escribirán sus datos en tablas diferentes, pero puede
incluir varias tablas en una sola consulta para analizar
datos entre varios orígenes. Cuando compila una consulta,
primero debe determinar las tablas que tienen los datos
que está buscando. Consulte Estructura de los registros de
Azure Monitor para obtener una explicación de cómo se
estructuran los datos.
¿Qué aspecto tiene una consulta de

registro?
Una consulta puede ser tan simple como un nombre de
tabla única para recuperar todos los registros de esa tabla:
Syslog
O bien, podría filtrar registros determinados, resumirlos y

visualizar los resultados en un gráfico:
SecurityEvent
| summarize count() by Computer, bin(TimeGenerated, 1h)
| render timechart
Para un análisis más complejo, puede recuperar datos de

varias tablas mediante una combinación para analizar los
resultados entre sí.
app("ContosoRetailWeb").requests
| summarize count() by bin(timestamp,1hr)
| join kind= inner (Perf
| summarize avg(CounterValue)
by bin(TimeGenerated,1hr))
on $left.timestamp == $right.TimeGenerated
Incluso si no está familiarizado con KQL, debería poder

averiguar al menos la lógica básica que estas consultas
usan. Comienzan por el nombre de una tabla y luego
agregan varios comandos para filtrar y procesar los datos.
Una consulta puede usar cualquier número de comandos y
se pueden escribir consultas más complejas a medida que
se familiarice con los distintos comandos de KQL
disponibles.
Consulte Introducción a las consultas de registro en Azure
Monitor para obtener un tutorial sobre las consultas de
registro en el que se introduce el lenguaje y las funciones
comunes.
¿Qué es Log Analytics?

Log Analytics es la herramienta principal en Azure Portal
para escribir consultas de registros y analizar sus
resultados de forma interactiva. Incluso si una consulta de
registro se usa en otro lugar en Azure Monitor,
normalmente deberá escribir y probar la consulta primero
mediante Log Analytics.
Log Analytics se puede iniciar desde varios lugares en
Azure Portal. El ámbito de los datos disponibles para Log
Analytics se determina según el modo en que se inicia.
Consulte Ámbito de la consulta para obtener más detalles.
Seleccione Registros desde el menú Azure Monitor o
el menú Áreas de trabajo de Log Analytics .
Seleccione Registros en la página Introducción de
una aplicación de Application Insights.
Seleccione Registros en el menú de un recurso de
Azure.
Consulte Introducción a Log Analytics en Azure Monitor

para obtener un tutorial sobre Log Analytics en el que se
introducen varias de sus características.
¿Dónde se usan las consultas de
registros?
Además de trabajar de manera interactiva con consultas
de registro y sus resultados en Log Analytics, entre las
áreas de Azure Monitor en las que se usan las consultas se
incluyen las siguientes:
Reglas de aler tas. Las reglas de alertas identifican de
manera proactiva los problemas de datos del área de
trabajo. Cada regla de alertas se basa en una búsqueda
de registros que se ejecuta automáticamente a
intervalos regulares. Los resultados se inspeccionan
para determinar si se debe crear una alerta.
Paneles. Puede anclar los resultados de cualquier
consulta en un panel de Azure, que le permitirá
visualizar los datos de registros y métricas en conjunto
y, opcionalmente, compartirlos con otros usuarios de
Azure.
Vistas. Puede crear visualizaciones de datos que se
incluyan en los paneles de usuario con el diseñador de
vistas. Las consultas de registros proporcionan los datos
utilizados por iconos y elementos de visualización en
cada vista.
Expor tación. Cuando importe datos de registro de
Azure Monitor en Excel o Power BI, cree una consulta de
registros para definir los datos que se van a exportar.
PowerShell. Puede ejecutar un script de PowerShell
desde una línea de comandos o un runbook de Azure
Automation que use Get-
AzOperationalInsightsSearchResults para recuperar los
datos de registro de Azure Monitor. Este cmdlet requiere
una consulta para determinar los datos que se van a
recuperar.
API de registros de Azure Monitor. La API de
registros de Azure Monitor permite que cualquier
cliente de API REST recupere datos de registro del área
de trabajo. La solicitud de API incluye una consulta que
se ejecuta en Azure Monitor para determinar los datos
que se van a recuperar.
Pasos siguientes
Realice un tutorial sobre el uso de Log Analytics en
Azure Portal.
Realice un tutorial sobre cómo escribir consultas.
Experiencia Simple Logs en Azure Monitor (versión
preliminar)
Azure Monitor proporciona una experiencia enriquecida para crear consultas de registro mediante el lenguaje KQL.
No obstante, es posible que no necesite toda la eficacia de KQL y prefiera una experiencia simplificada para los
requisitos de consulta básicos. La experiencia de Simple Logs le permite crear consultas básicas sin interactuar
directamente con KQL. También puede usar Simple Logs como herramienta de aprendizaje para KQL a medida que
necesite consultas más sofisticadas.
NOTE
Simple Logs actualmente está implementado como una prueba solo para Cosmos DB y los almacenes de claves. Comparta su
experiencia con Microsoft a través de User Voice para ayudarnos a determinar si se ampliará y publicará esta característica.
Ámbito
La experiencia de Simple Logs recupera datos de la tabla AzureDiagnostics, AzureMetrics y AzureActivity para el
recurso seleccionado.
Uso de Simple Logs

Desplácese a cualquier instancia de Cosmos DB o Key Vault de su suscripción a Azure con opciones de diagnóstico
configuradas para recopilar registros en un área de trabajo de Log Analytics. Haga clic en Registros en el menú
Super visión para abrir la experiencia de Simple Logs.
Seleccione un Campo y un Operador y especifique un Valor para la comparación. Haga clic en + y especifique
Y/O para agregar criterios adicionales.
Haga clic en Ejecutar para ver los resultados de la consulta.
Visualización y edición de KQL

Seleccione Editor de consultas para abrir el KQL generado por la consulta de Simple Logs en la experiencia
completa de Log Analytics.
Puede editar de forma directa el KQL y usar otras características de Log Analytics como filtros para refinar aún más
los resultados.
Pasos siguientes
Complete un tutorial sobre el uso de Log Analytics en Azure Portal.
Complete un tutorial sobre cómo escribir consultas de registros.
Auditoría de las consultas en los registros de Azure
Monitor (versión preliminar)
Los registros de auditoría de las consultas de registro proporcionan datos de telemetría sobre la ejecución de
consultas de registro en Azure Monitor. Esto incluye información como cuándo se ejecutó una consulta, quién la
ejecutó, qué herramienta se usó, el texto de la consulta y las estadísticas de rendimiento que describen la ejecución
de la consulta.
Limitaciones actuales
Durante la versión preliminar pública, se aplican las siguientes limitaciones:
Solo se registrarán las consultas centradas en el área de trabajo. Las consultas que se ejecutan en modo
centrado en recursos o se ejecutan en una instancia de Application Insights no configurada como basada en el
área de trabajo no se registrarán.
Configuración de la auditoría de las consultas

La auditoría de las consultas se habilita con una configuración de diagnóstico en el área de trabajo Log Analytics.
Esto le permite enviar datos de auditoría al área de trabajo actual o a cualquier otra área de trabajo de la
suscripción, a Azure Event Hubs para enviar datos fuera de Azure o a Azure Storage para su archivo.
Azure portal
Acceda a la configuración de diagnóstico de un área de trabajo de Log Analytics en Azure Portal en cualquiera de
las siguientes ubicaciones:
En el menú de Azure Monitor , seleccione Configuración de diagnóstico y, a continuación, busque y
seleccione el área de trabajo.
En el menú Áreas de trabajo de Log Analytics , seleccione el área de trabajo y, a continuación, seleccione
Configuración de diagnóstico .
Puede obtener un ejemplo de una plantilla de Resource Manager en Configuración de diagnóstico del área de
Datos de auditoría
Cada vez que se ejecuta una consulta, se crea un registro de auditoría. Si envía los datos a un área de trabajo de
Log Analytics, se almacena en una tabla llamada LAQueryLogs. En la tabla siguiente se describen las propiedades
de cada registro de los datos de auditoría.
CAMPO DESC RIP C IÓ N
TimeGenerated Hora UTC a la que se envió la consulta.
CorrelationId Identificador único para identificar la consulta. Se puede usar

en escenarios de solución de problemas al ponerse en
contacto con Microsoft para obtener ayuda.
AADObjectId Identificador de Azure Active Directory de la cuenta de usuario

que ha iniciado la consulta.
AADTenantId Identificador de inquilino de la cuenta de usuario que ha

iniciado la consulta.
AADEmail Correo electrónico del inquilino de la cuenta de usuario que ha

iniciado la consulta.
AADClientId Identificador y nombre resuelto de la aplicación utilizada para

iniciar la consulta.
RequestClientApp Nombre resuelto de la aplicación utilizada para iniciar la

consulta.
QueryTimeRangeStart Inicio del intervalo de tiempo seleccionado para la consulta.

Este valor podría no rellenarse en determinados escenarios,
como cuando la consulta se inicia desde Log Analytics y el
intervalo de tiempo se especifica dentro de la consulta en
lugar de en el selector de tiempo.
QueryTimeRangeEnd Fin del intervalo de tiempo seleccionado para la consulta. Este

valor podría no rellenarse en determinados escenarios, como
cuando la consulta se inicia desde Log Analytics y el intervalo
de tiempo se especifica dentro de la consulta en lugar de en el
selector de tiempo.
QueryText Texto de la consulta que se ha ejecutado.
RequestTarget Dirección URL de la API que se usó para enviar la consulta.
RequestContext Lista de recursos en los que se solicitó la ejecución de la

consulta. Contiene hasta tres matrices de cadenas: áreas de
trabajo, aplicaciones y recursos. Las consultas dirigidas a
grupos de recursos o suscripciones se mostrarán como
recursos. Incluye el destino implícito por RequestTarget.
RequestContextFilters Conjunto de filtros especificado como parte de la invocación

de la consulta. Incluye hasta tres matrices de cadenas posibles:
- ResourceTypes: tipo de recurso para limitar el ámbito de la
consulta.
- Workspaces: lista de áreas de trabajo para limitar la consulta.
- WorkspaceRegions: lista de regiones de áreas de trabajo para
limitar la consulta.
ResponseCode Código de respuesta HTTP que se devolvió cuando se envió la

consulta.
ResponseDurationMs Tiempo que se tardó en devolver la respuesta.
StatsCPUTimeMs Tiempo total de proceso usado para el cálculo, el análisis y la

recuperación de los datos. Solo se rellena si la consulta
devuelve el código de estado 200.
StatsDataProcessedKB Cantidad de datos a los que se accedió para procesar la

consulta. Se ve afectado por el tamaño de la tabla de destino,
el intervalo de tiempo usado, los filtros aplicados y el número
de columnas a que se hace referencia. Solo se rellena si la
consulta devuelve el código de estado 200.
StatsDataProcessedStart Hora de los datos más antiguos a los que se accedió para
procesar la consulta. Se ve influenciado por el intervalo de
tiempo explícito de la consulta y los filtros aplicados. Podría ser
mayor que el intervalo de tiempo explícito debido a la creación
de particiones de datos. Solo se rellena si la consulta devuelve
el código de estado 200.
StatsDataProcessedEnd Hora de los datos más recientes a los que se accedió para
procesar la consulta. Se ve influenciado por el intervalo de
tiempo explícito de la consulta y los filtros aplicados. Podría ser
mayor que el intervalo de tiempo explícito debido a la creación
de particiones de datos. Solo se rellena si la consulta devuelve
el código de estado 200.
StatsWorkspaceCount Número de áreas de trabajo a las que tuvo acceso la consulta.

Solo se rellena si la consulta devuelve el código de estado 200.
StatsRegionCount Número de regiones a las que tuvo acceso la consulta. Solo se

rellena si la consulta devuelve el código de estado 200.
Pasos siguientes
Más información sobre la optimización de consultas del registro.
Tutorial: Introducción a las consultas de Log
Analytics
En este tutorial se indica cómo usar Log Analytics para escribir, ejecutar y administrar consultas de
registro de Azure Monitor en Azure Portal. Las consultas de Log Analytics se pueden usar para
buscar términos, identificar tendencias, analizar patrones y proporcionar muchas otras
conclusiones basadas en los datos.
En este tutorial, aprenderá a usar Log Analytics para:
Comprender el esquema de datos del registro
Escribir y ejecutar consultas sencillas, y modificar el intervalo de tiempo de las consultas
Filtrar, ordenar y agrupar los resultados de las consultas
Ver, modificar y compartir los objetos visuales de los resultados de las consultas
Guardar, cargar, exportar y copiar consultas y resultados
Para obtener más información sobre las consultas de registro, vea Análisis de datos de registro en
Azure Monitor.
Para ver un tutorial detallado sobre cómo escribir consultas de registro, consulte Introducción a las
consultas de registro en Azure Monitor.
Apertura de Log Analytics

Para usar Log Analytics debe iniciar sesión en una cuenta de Azure. Si no tiene una cuenta de
Azure, cree una gratis.
Para completar la mayoría de los pasos de este tutorial, puede usar este entorno de demostración
que incluye gran cantidad de datos de ejemplo. En este entorno, no podrá guardar consultas ni
anclar resultados en un panel.
También puede usar su propio entorno si va a utilizar Azure Monitor para recopilar datos de
registro en al menos un recurso de Azure. Para abrir un área de trabajo de Log Analytics,
seleccione Registros en el panel de navegación izquierdo de Azure Monitor.
Información sobre el esquema

Un esquema es una colección de tablas que se agrupan en categorías lógicas. El esquema de
demostración incluye varias categorías de soluciones de supervisión. Por ejemplo, la categoría
LogManagement contiene eventos, datos de rendimiento y latidos del agente de Windows y
Syslog.
Las tablas del esquema aparecen en la pestaña Tablas del área de trabajo de Log Analytics. Las
tablas contienen columnas, cada una con un tipo de datos que muestra el icono situado junto al
nombre de la columna. Por ejemplo, la tabla Eventos contiene columnas de texto como Equipo y
columnas numéricas como EventCategor y .
Escritura y ejecución de consultas básicas
Log Analytics se abre con una nueva consulta en blanco en el Editor de consultas .
Escriba una consulta.

Las consultas de registro de Azure Monitor usan una versión del lenguaje de consulta de Kusto.
Las consultas pueden comenzar por un nombre de tabla o un comando search.
La siguiente consulta recupera todos los registros de la tabla Eventos :
Event
El carácter de barra vertical (|) separa los comandos, de manera que la salida del primer comando
es la entrada del siguiente. A una consulta se puede agregar cualquier cantidad de comandos. La
consulta siguiente recupera los registros de la tabla Eventos y, a continuación, busca en ellos el
término error en todas las propiedades:
Event
| search "error"
Un solo salto de línea hace que las consultas sean más fáciles de leer. Más de un salto de línea
divide la consulta en consultas independientes.
Esta es otra forma de escribir la misma consulta:
search in (Event) "error"
En el segundo ejemplo, el comando search solo busca en los registros de la tabla Eventos el
término error .
De forma predeterminada, Log Analytics limita las consultas a un intervalo de tiempo de las
últimas 24 horas. Para establecer un intervalo de tiempo diferente, puede agregar un filtro
TimeGenerated explícito a la consulta o utilizar el control Inter valo de tiempo .
Uso del control Intervalo de tiempo
Para utilizar el control Inter valo de tiempo selecciónelo en la barra superior y, después,
seleccione un valor de la lista desplegable o seleccione Personalizado para crear un intervalo de
tiempo personalizado.
Los valores del intervalo de tiempo están en formato UTC, el cual podría ser diferente de su
zona horaria local.
Si la consulta establece explícitamente un filtro para TimeGenerated , en el control selector de
hora aparece Establecer en la consulta y se deshabilita para evitar un conflicto.
Ejecución de una consulta
Para ejecutar una consulta, sitúe el cursor en algún lugar de esta y seleccione Ejecutar en la barra
superior o presione Mayús +Entrar . La consulta se ejecuta hasta que encuentra una línea en
blanco.
Filtrar resultados
Log Analytics limita los resultados a un máximo de 10 000 registros. Una consulta general como
Event devuelve demasiados resultados para ser útil. Puede filtrar los resultados mediante la
restricción de los elementos de la tabla de la consulta o agregando explícitamente un filtro a los
resultados. El filtrado mediante elementos de tabla devuelve un nuevo conjunto de resultados
mientras que un filtro explícito se aplica al conjunto de resultados ya existente.
Filtro mediante la restricción de elementos de tabla
Para filtrar los resultados de la consulta de Event por eventos de Error mediante la restricción de
elementos de tabla de la consulta:
1. En los resultados de la consulta, seleccione la flecha desplegable situada junto a cualquier
registro que contenga Error en la columna EventLevelName .
2. En los detalles expandidos, pase el puntero y seleccione el icono ... situado junto a
EventLevelName y, después, seleccione Incluir "Error" .
3. Observe que la consulta del Editor de consultas ha cambiado ahora a:
Event
| where EventLevelName == "Error"
4. Seleccione Ejecutar para ejecutar la nueva consulta.

Filtro mediante el filtrado explícito de los resultados
Para filtrar los resultados de la consulta de Event por eventos de Error mediante el filtrado de los
resultados de la consulta:
1. En los resultados de la consulta, seleccione el icono de Filtro situado junto al encabezado
de la columna EventLevelName .
2. En el primer campo de la ventana emergente, seleccione Es igual que y, en el siguiente
campo, escriba error.
3. Seleccione Filtro .
Ordenación, agrupación y selección de columnas

Para ordenar los resultados de una consulta por una columna específica, como TimeGenerated
[UTC] , seleccione el encabezado de la columna. Seleccione el encabezado de nuevo para cambiar
entre un orden ascendente o descendente.
Otra manera de organizar los resultados es por grupos. Para agrupar resultados por una columna
específica, arrastre el encabezado de la columna a la barra situada sobre la tabla de resultados con
la etiqueta Drag a column header and drop it here to group by that column (Arrastrar un
encabezado de columna y soltarlo aquí para agrupar por esa columna). Para crear subgrupos,
arrastre otras columnas a la barra superior. Puede reorganizar la jerarquía y ordenar los grupos y
subgrupos en la barra.
Para ocultar o mostrar las columnas de los resultados, seleccione Columnas situado encima de la
tabla y, a continuación, seleccione o anule la selección de las columnas que desee en la lista
desplegable.
Visualización y modificación de gráficos

También puede ver los resultados de la consulta en formatos visuales. Escriba la siguiente consulta
como ejemplo:
Event
| summarize count() by Source
De forma predeterminada, los resultados aparecen en una tabla. Seleccione Gráfico en la parte
superior de la tabla para ver los resultados en una vista gráfica.
Los resultados aparecen en un gráfico de barras apiladas. Seleccione otras opciones como
Columna apilada o Circular para mostrar otras vistas de los resultados.
Las propiedades de la vista, como los ejes "x" e "y", o las preferencias de agrupación y división, se
pueden cambiar manualmente en la barra de control.
También puede establecer la vista que prefiera en la propia consulta mediante el operador de
representación.
Anclaje de resultados a un panel

Para anclar una tabla o gráfico de resultados desde Log Analytics en un panel compartido de
Azure, seleccione Anclar al panel en la barra superior.
En el panel Anclar a otro panel , seleccione un panel al que realizar el anclaje, o créelo, y
seleccione Aplicar . La tabla o gráfico aparece en el panel de Azure seleccionado.
La tablas o gráficos que ancle a un panel compartido tendrán las siguientes limitaciones:
Los datos se limitan a los últimos 14 días.
Una tabla solo muestra un máximo de cuatro columnas y las siete primeras filas.
Los gráficos con muchas categorías discretas agrupan automáticamente las categorías menos
pobladas en una única categoría otros .
Guardar, cargar o exportar consultas

Después de crear una consulta, puede guardarla o compartir la consulta o los resultados con otros.
Guardado de consultas
Para guardar una consulta:
1. Seleccione Guardar en la barra superior.
2. En el cuadro de diálogo Guardar , asigne a la consulta un Nombre mediante los caracteres
a – z, A – Z, 0-9, espacio, guión, carácter de subrayado, punto, paréntesis o barra vertical.
3. Seleccione si desea guardar la consulta como Consulta o como Función . Las funciones
son consultas a las que pueden hacer referencia otras consultas.
Para guardar una consulta como una función, proporcione un Alias de función , que es un
nombre corto que otras consultas usan para llamar a esta consulta.
4. Si está en un área de trabajo de Log Analytics, proporcione una categoría para el
Explorador de consultas que se usará para la consulta. (Las categorías no están
disponibles para las consultas de Applications Insights)
5. Seleccione Guardar .
Carga de consultas
Para cargar una consulta guardada, seleccione Explorador de consultas en la esquina superior
derecha. Se abre el panel Explorador de consultas , donde se muestran todas las consultas por
categoría. Expanda las categorías o escriba un nombre de consulta en la barra de búsqueda y, a
continuación, seleccione una consulta para cargarla en el Editor de consultas . Para marcar una
consulta como Favorita , seleccione la estrella situada junto al nombre de la consulta.
Exportar y compartir consultas

Para exportar una consulta, seleccione Expor tar en la barra superior y, después, seleccione
Expor tar a CSV: todas las columnas , Expor tar a CSV: columnas mostradas o Expor tar a
Power BI (M Quer y) en la lista desplegable.
En el vídeo siguiente se muestra cómo integrar Log Analytics con Excel.
Para compartir un vínculo a una consulta, seleccione Copiar vínculo en la barra superior y, a
continuación, seleccione Copiar vínculo a la consulta , Copiar texto de la consulta o Copiar
resultados de la consulta para copiarlos en el portapapeles. Puede enviar el vínculo de la
consulta a otros usuarios que tengan acceso a la misma área de trabajo.
Pasos siguientes
Prosiga con el siguiente tutorial para más información sobre la escritura de consultas de registro
de Azure Monitor.
Escritura de consultas de registros de Azure Monitor
Introducción a las consultas de registro en
Azure Monitor
NOTE
Puede trabajar en este ejercicio en su propio entorno si va a recopilar datos de al menos una máquina virtual. Si
no es así, use nuestro entorno de demostración, que incluye gran cantidad de datos de ejemplo. Si ya sabe cómo
realizar consultas en KQL, pero solo necesita crear rápidamente consultas útiles basadas en tipos de recursos, vea
el panel de consultas de ejemplo guardado.
En este tutorial aprenderá a escribir consultas de registro en Azure Monitor. Le mostrará cómo:
Comprender la estructura de las consultas
Ordenar los resultados de la consulta
Filtrar los resultados de la consulta
Seleccionar los campos que incluir en los resultados
Definir y usar campos personalizados
Agregar y agrupar los resultados
Para obtener un tutorial sobre el uso de Log Analytics en Azure Portal, consulte Introducción a Log
Analytics de Azure Monitor.
Para más información sobre las consultas de registro en Azure Monitor, consulte Introducción a las
consultas de registro en Azure Monitor.
Siga con una versión en vídeo de este tutorial:
Escribir una nueva consulta

Las consultas pueden comenzar por un nombre de tabla o el comando search. Debe empezar por un
nombre de tabla, ya que define un ámbito claro para la consulta y mejora el rendimiento de las
consultas y la pertinencia de los resultados.
NOTE
El lenguaje de consulta de Kusto que usa Azure Monitor distingue entre mayúsculas y minúsculas. Las palabras
clave del lenguaje se suelen escribir en minúsculas. Al usar nombres de tablas o columnas en una consulta,
asegúrese de usar las mayúsculas y minúsculas correctas, tal como se muestra en el panel de esquema.
Consultas basadas en tablas

Azure Monitor organiza los datos de registro en tablas, compuestas de varias columnas. Todas las tablas
y columnas se muestran en el panel de esquema en Log Analytics en el portal de Analytics. Identifique
una tabla que le interese y observe algunos datos:
SecurityEvent
| take 10
La consulta anterior devuelve 10 resultados de la tabla SecurityEvent, sin orden específico. Se trata de
una forma muy común para echar un vistazo a una tabla y comprender su estructura y contenido.
Vamos a examinar su estructura:
La consulta comienza por el nombre de la tabla, SecurityEvent; esta parte define el ámbito de la
consulta.
El carácter de barra vertical (|) separa los comandos,de manera que la salida del primero sea la
entrada del siguiente. Puede agregar cualquier cantidad de elementos canalizados.
Después de la canalización se encuentra el comando take , que devuelve un número concreto de
registros arbitrarios de la tabla.
En realidad podríamos ejecutar la consulta incluso sin agregar | take 10 , seguiría siendo válida, pero
podría devolver hasta 10 000 resultados.
Las consultas de búsqueda están menos estructuradas y por lo general son más adecuadas para buscar
registros con un valor específico en cualquiera de sus columnas:
search in (SecurityEvent) "Cryptographic"

| take 10
Esta consulta busca en la tabla SecurityEvent los registros que contienen la expresión "Cryptographic".
De esos registros, se devuelven y se muestran 10. Si se omite la parte in (SecurityEvent) y solo se
ejecuta search "Cryptographic" , la búsqueda recorrerá todas las tablas, lo que podría tardar más tiempo
y ser menos eficiente.
WARNING
Las consultas de búsqueda son normalmente más lentas que las consultas basadas en tablas porque tienen que
procesar más datos.
sort y top
Mientras que take resulta útil para obtener algunos registros, los resultados no se seleccionan ni se
muestran en un orden concreto. Para obtener una vista ordenada a partir de la columna preferida, use
sor t :
SecurityEvent
| sort by TimeGenerated desc
No obstante, esto podría devolver demasiados resultados y tardar un tiempo. En la consulta anterior se
ordena toda la tabla SecurityEvent a partir de la columna TimeGenerated. En el portal de Analytics se
limita la presentación para mostrar solo 10 000 registros. Es obvio que este enfoque no es el mejor.
La mejor manera de obtener solo los 10 registros más recientes es usar top , que ordena toda la tabla en
el servidor y devuelve los registros principales:
SecurityEvent
El criterio de ordenación descendente es el valor predeterminado, por lo que se suele omitir el

argumento desc . La salida tendrá este aspecto:
where: filtrado por una condición

Los filtros, tal como indica su nombre, filtran los datos por una condición específica. Se trata de la
manera más común para limitar los resultados de la consulta a la información pertinente.
Para agregar un filtro a una consulta, use el operador where seguido por una o varias condiciones. Por
ejemplo, la siguiente consulta devuelve solo los registros de SecurityEvent donde Level sea igual a 8:
SecurityEvent
| where Level == 8
Al escribir las condiciones de filtro, puede usar las siguientes expresiones:
EXP RESSIO N DESC RIP C IÓ N E JEM P LO
== Coincidencia con igualdad Level == 8

(distingue mayúsculas y minúsculas)
=~ Coincidencia con igualdad EventSourceName =~

(no distingue mayúsculas y "microsoft-windows-security-
auditing"
minúsculas)
!=, <> Coincidencia sin igualdad Level != 4

(ambas expresiones son idénticas)
and, or Necesario entre condiciones Level == 16 or CommandLine !=

""
Para filtrar con varias condiciones, puede usar and :
SecurityEvent
| where Level == 8 and EventID == 4672
o canalizar varios elementos where uno tras otro:

SecurityEvent
| where Level == 8
NOTE
Los valores pueden ser de tipos distintos, por lo que quizá deba convertirlos para realizar la comparación en el
tipo correcto. Por ejemplo, la columna Level de SecurityEvent es de tipo cadena, por lo que debe convertirla a un
tipo numérico, como int o long para usar operadores numéricos: SecurityEvent | where toint(Level) >= 10

Selector de hora
El selector de hora está junto al botón Ejecutar e indica que solo consultamos registros de las últimas 24
horas. Este es el intervalo de tiempo predeterminado que se aplica a todas las consultas. Para obtener
solo los registros de la última hora, seleccione Last hour (Última hora) y vuelva a ejecutar la consulta.
Filtro de tiempo en las consultas

También puede definir su propio intervalo de tiempo mediante la incorporación de un filtro de tiempo a
la consulta. Lo mejor es colocar el filtro de tiempo inmediatamente después del nombre de la tabla:
SecurityEvent
| where toint(Level) >= 10
En el filtro de tiempo anterior, ago(30m) significa "hace 30 minutos", por lo que esta consulta devuelve
solo los registros de los últimos 30 minutos. Otras unidades de tiempo son los días (2 d), los minutos
(25 m) y los segundos (10 s).
project y extend: seleccionar y procesar columnas

Use project para seleccionar columnas concretas que incluir en los resultados:
SecurityEvent
| project TimeGenerated, Computer, Activity
En el ejemplo anterior se genera esta salida:
También puede usar project para cambiar el nombre de las columnas y definir otras nuevas. En el
ejemplo siguiente se utiliza project para hacer lo siguiente:
Seleccionar solo las columnas originales Computer y TimeGenerated.
Cambiar el nombre de la columna Activity a EventDetails.
Crear una nueva columna denominada EventCode. La función substring() se utiliza para obtener
solo los primeros cuatro caracteres del campo Activity.
SecurityEvent
| project Computer, TimeGenerated, EventDetails=Activity, EventCode=substring(Activity, 0, 4)
extend mantiene todas las columnas originales en el conjunto de resultados y define otras adicionales.
La consulta siguiente usa extend para agregar la columna EventCode. Tenga en cuenta que es posible
que esta columna no se muestre al final de los resultados de la tabla, en cuyo caso sería necesario
expandir los detalles de un registro para verlo.
SecurityEvent
| extend EventCode=substring(Activity, 0, 4)
summarize: incorporación de grupos de filas

Use summarize para identificar grupos de registros, según una o varias columnas, y aplicarles
agregaciones. El uso más habitual de summarize es con count, lo que devuelve el número de
resultados de cada grupo.
En la consulta siguiente se revisan todos los registros Perf de la última hora, se agrupan por
ObjectName y se cuentan los registros de cada grupo:
Perf
| summarize count() by ObjectName
A veces tiene sentido definir los grupos según varias dimensiones. Cada combinación única de estos
valores define un grupo independiente:
Perf
| summarize count() by ObjectName, CounterName
Otro uso común es para realizar cálculos matemáticos o estadísticos en cada grupo. Por ejemplo, a
continuación se calcula el promedio de CounterValue para cada equipo:
Perf
| summarize avg(CounterValue) by Computer
Lamentablemente, los resultados de esta consulta no tienen sentido, ya que hemos mezclado diferentes
contadores de rendimiento. Para que esto tenga más sentido, debemos calcular el promedio por
separado para cada combinación de CounterName y Computer:
Perf
Resumen por una columna de tiempo

La agrupación de resultados también puede basarse en una columna de tiempo o con cualquier otro
valor continuo. Sin embargo, simplemente resumir por by TimeGenerated crearía grupos para cada
milisegundo del intervalo de tiempo, ya que son valores únicos.
Para crear grupos basados en valores continuos es mejor dividir el intervalo en unidades manejables
mediante bin . En la siguiente consulta se analizan los registros Perf que miden la memoria libre
(Available MBytes) en un equipo específico. Se calcula el valor promedio de cada período de 1 hora
durante los últimos 7 días:
Perf
| where Computer == "ContosoAzADDS2"
| where CounterName == "Available MBytes"
| summarize avg(CounterValue) by bin(TimeGenerated, 1h)
Para que la salida sea más clara, elija mostrarla como gráfico de tiempo, que muestre la memoria
disponible a lo largo del tiempo:
Pasos siguientes
Puede encontrar más información sobre el uso de datos de cadena en una consulta de registro en
Trabajo con cadenas en las consultas de registro de Azure Monitor.
Puede encontrar más información sobre la agregación de datos en una consulta de registro en
Agregaciones avanzadas en las consultas de registro de Azure Monitor.
Obtenga información sobre cómo combinar datos de varias tablas en Combinaciones en consultas
de registros de Azure Monitor.
Obtenga la documentación completa sobre el lenguaje de consulta de Kusto en Referencia del
lenguaje KQL.
Ámbito e intervalo de tiempo de una consulta de
registro en Log Analytics de Azure Monitor
Al ejecutar una consulta de registro en Log Analytics en Azure Portal, el conjunto de datos que evalúa la
consulta depende del ámbito y el intervalo de tiempo que seleccione. En este artículo se describe el ámbito y
el intervalo de tiempo y cómo puede establecer cada uno de ellos en función de sus requisitos. También
describe el comportamiento de distintos tipos de ámbitos.
Ámbito de la consulta
El ámbito de la consulta define los registros que esta evalúa. Normalmente esto incluirá todos los registros de
una sola área de trabajo de Log Analytics o una aplicación de Application Insights. Log Analytics también
permite establecer un ámbito para un determinado recurso de Azure supervisado. Esto permite a un
propietario del recurso centrarse solamente en sus datos, incluso si ese recurso se escribe en varias áreas de
trabajo.
El ámbito siempre se muestra en la parte superior izquierda de la ventana de Log Analytics. Un icono indica si
el ámbito es un área de trabajo de Log Analytics o una aplicación de Application Insights. Cuando no aparece
ningún icono significa que se trata de otro recurso de Azure.
El ámbito lo determina el método que se utiliza para iniciar Log Analytics y, en algunos casos, puede cambiar
el ámbito haciendo clic en él. En la tabla siguiente se enumeran los diferentes tipos de ámbito utilizados y los
distintos detalles para cada uno.
IMPORTANT
Si usa APM 2,1, las aplicaciones de Application Insights se almacenan en un área de trabajo de Log Analytics con el
resto de datos de registro y el ámbito de Application Insights no está disponible. Si selecciona Registros en el menú de
Application Insights, esta opción actuará igual que el ámbito Otros recursos de Azure y solo estarán disponibles los
datos de la aplicación en las tablas de Application Insights.
C Ó M O REA L IZ A R L A
Á M B ITO DE L A C O N SULTA REGIST RO S DEL Á M B ITO SEL EC C IÓ N C A M B IO DEL Á M B ITO
Área de trabajo de Log Todos los registros del área Seleccione Registros en el Puede cambiar el ámbito a
Analytics de trabajo de Log menú Azure Monitor o el cualquier otro tipo de
Analytics. menú Áreas de trabajo recurso.
de Log Analytics .
Aplicación de Application Todos los registros de la Seleccione Analytics en la Solo se puede cambiar el
Insights aplicación de Application página Introducción de ámbito a otra aplicación de
Insights. Application Insights. Application Insights.
C Ó M O REA L IZ A R L A
Á M B ITO DE L A C O N SULTA REGIST RO S DEL Á M B ITO SEL EC C IÓ N C A M B IO DEL Á M B ITO
Resource group Recursos creados por todos Seleccione Registros en el No se puede cambiar el
los recursos del grupo de menú de grupo de ámbito.
recursos. Puede incluir recursos.
datos de varias áreas de
Suscripción Registros creados por Seleccione Registros en el No se puede cambiar el

todos los recursos de la menú de la suscripción. ámbito.
suscripción. Puede incluir
datos de varias áreas de
Otros recursos de Azure Registros creados por el Seleccione Registros en el Solo se puede cambiar el
recurso. Puede incluir datos menú de recursos. ámbito al mismo tipo de
de varias áreas de trabajo O BIEN recurso.
de Log Analytics. Seleccione Registros en el
menú Azure Monitor y
luego seleccione un nuevo
ámbito.
Limitaciones cuando el ámbito se aplica a un recurso

Cuando el ámbito de la consulta es un área de trabajo de Log Analytics o una aplicación de Application
Insights, están disponibles todas las opciones en el portal y todos los comandos de consulta. Sin embargo,
cuando el ámbito se aplica a un recurso, las siguientes opciones del portal no están disponibles porque están
asociadas a un solo área de trabajo o aplicación:
Save
Explorador de consultas
Nueva alerta de reglas
No se pueden usar los siguientes comandos en una consulta cuando el ámbito se aplica a un recurso, ya que
el ámbito de la consulta ya incluirá las áreas de trabajo con datos para ese recurso o un conjunto de recursos:
app
workspace
Límites de la consulta
Puede tener requisitos empresariales para que un recurso de Azure escriba datos en varias áreas de trabajo
de Log Analytics. No es necesario que el área de trabajo esté en la misma región que el recurso y una sola
área de trabajo puede recopilar datos de recursos de varias regiones.
El establecimiento del ámbito en un recurso o un conjunto de recursos es una característica especialmente
eficaz de Log Analytics, ya que permite consolidar automáticamente los datos distribuidos en una sola
consulta. No obstante, al rendimiento puede resultar considerablemente afectado si es necesario recuperar los
datos de las áreas de trabajo de varias regiones de Azure.
Log Analytics ayuda a protegerse frente a una sobrecarga excesiva de las consultas que abarcan las áreas de
trabajo de varias regiones mediante la generación de una advertencia o un error cuando se utiliza un
determinado número de regiones. La consulta recibirá una advertencia si el ámbito incluye áreas de trabajo
de cinco, o más, regiones. Se ejecutará, pero es posible que tarde demasiado tiempo en completarse.
Se bloqueará la ejecución de la consulta si el ámbito incluye áreas de trabajo de 20, o más, regiones. En este
caso, se le pedirá que reduzca el número de regiones del área de trabajo y que intente volver a ejecutar la
consulta. La lista desplegable mostrará todas las regiones del ámbito de la consulta, y debe reducir el número
de regiones antes de intentar volver a ejecutar la consulta.
Intervalo de horas
El intervalo de tiempo especifica el conjunto de registros que se evalúan para la consulta en función de
cuándo se creó el registro. Esto se define mediante una propiedad estándar en todos los registros del área de
trabajo o la aplicación, tal como se especifica en la tabla siguiente.
LO C AT IO N P RO P IEDA D
Área de trabajo de Log Analytics TimeGenerated
Aplicación de Application Insights timestamp
Establezca el intervalo de tiempo seleccionándolo en el selector de hora en la parte superior de la ventana de

Log Analytics. Puede seleccionar un período predefinido o seleccionar Personalizado para especificar un
intervalo de tiempo concreto.
Si establece un filtro en la consulta que utiliza la propiedad de hora estándar, tal como se muestra en la tabla
anterior, el selector de hora cambia a Establecer en la consulta y se deshabilita. En este caso, es más eficaz
colocar el filtro en la parte superior de la consulta para que cualquier procesamiento posterior solo necesite
trabajar con los registros filtrados.
Si usa el comando workspace o app para recuperar datos de otra área de trabajo o aplicación, el selector de
hora puede comportarse de manera diferente. Si el ámbito es un área de trabajo de Log Analytics y usa app , o
si el ámbito es una aplicación de Application Insights y usa workspace , es posible que Log Analytics no
entienda que la propiedad utilizada en el filtro debe determinar el filtro de tiempo.
En el ejemplo siguiente, el ámbito se establece en un área de trabajo de Log Analytics. La consulta usa
workspace para recuperar datos de otra área de trabajo de Log Analytics. El selector de hora cambia a
Establecer en la consulta porque ve un filtro que usa la propiedad TimeGenerated esperada.
Sin embargo, si la consulta utiliza app para recuperar datos de una aplicación de Application Insights, Log
Analytics no reconoce la propiedad timestamp del filtro y el selector de hora permanece sin cambios. En este
caso, se aplican ambos filtros. En el ejemplo, solo se incluyen en la consulta los registros creados en las
últimas 24 horas, aunque especifique 7 días en la cláusula where .
Pasos siguientes
Realice un tutorial sobre el uso de Log Analytics en Azure Portal.
Realice un tutorial sobre cómo escribir consultas.
Grupos de equipos en las consultas de registros de
Azure Monitor
Los grupos de equipos en Azure Monitor permiten limitar las consultas de registros a un conjunto concreto de
equipos. Cada grupo se rellena con equipos mediante una consulta que defina o a través de la importación de
grupos de diferentes orígenes. Cuando el grupo se incluye en una consulta de registros, los resultados se limitan
a los registros que coinciden con los equipos del grupo.
NOTE
Este artículo se ha actualizado recientemente para usar el término registros de Azure Monitor en lugar de Log Analytics.
Los datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen recopilándose y analizándose
por el mismo servicio de Log Analytics. Estamos actualizando la terminología para reflejar mejor el rol de los registros de
Azure Monitor. Consulte Azure Monitor terminology changes (Cambios en la terminología de Azure Monitor) para obtener
más información.
Creación de un grupo de equipos

Puede crear un grupo de equipos en Azure Monitor mediante cualquiera de los métodos de la tabla siguiente. En
las secciones siguientes se proporcionan detalles sobre cada método.
M ÉTO DO DESC RIP C IÓ N
Consulta de registro Cree una consulta de registros que devuelva una lista de
equipos.
API de búsqueda de registros Use la API de búsqueda de registros para crear mediante
programación un grupo de equipos basándose en los
resultados de una consulta de registros.
Active Directory Analice automáticamente la pertenencia al grupo de

cualquier equipo agente que sea miembro de un dominio de
Active Directory y cree un grupo en Azure Monitor para cada
grupo de seguridad. (solo máquinas de Windows)
Administrador de configuración Importe colecciones desde Microsoft Endpoint Configuration

Manager y cree un grupo en Azure Monitor para cada una.
Windows Server Update Services Analice automáticamente clientes o servidores WSUS para
grupos de destino y cree un grupo en Azure Monitor para
cada uno.
Consulta de registro
Los grupos de equipos creados a partir de una consulta de registros contendrán todos los equipos devueltos por
una consulta que defina. Esta consulta se ejecuta cada vez que se usa el grupo de equipos de forma que se
reflejen todos los cambios que se hayan producido desde la creación del grupo.
Puede usar cualquier consulta para un grupo de equipos, pero debe devolver un conjunto distinto de equipos
mediante el uso de distinct Computer . A continuación, se muestra una consulta de ejemplo típica que puede usar
para un grupo de equipos.
Heartbeat | where Computer contains "srv" | distinct Computer
Utilice el procedimiento siguiente para crear un grupo de equipos a partir de una búsqueda de registros en Azure
Portal.
1. Haga clic en Registros en el menú Azure Monitor de Azure Portal.
2. Cree y ejecute una consulta que devuelva los equipos que desee en el grupo.
3. Haga clic en Guardar en la parte superior de la pantalla.
4. Cambie Guardar como a Función y seleccione Guardar esta consulta como un grupo de equipos .
5. Proporcione valores para cada propiedad del grupo de equipos que se describe en la tabla y haga clic en
Guardar .
En la tabla siguiente, se describen las propiedades que definen un grupo de equipos.
P RO P IEDA D DESC RIP C IÓ N
Nombre Nombre de la consulta que se va a mostrar en el portal.
Alias de función Un alias único usado para identificar el grupo de equipos en

una consulta.
Category Categoría para organizar las consultas en el portal.
Active Directory
Al configurar Azure Monitor para importar pertenencias a grupos de Active Directory, se analiza la pertenencia a
grupos de todos los equipos unidos al dominio de Windows con el agente de Log Analytics. En Azure Monitor se
crea un grupo de equipos para cada grupo de seguridad de Active Directory y cada equipo de Windows se
agrega a los grupos de equipos correspondientes a los grupos de seguridad de los que son miembros. Esta
pertenencia se actualiza continuamente cada 4 horas.
NOTE
Los grupos importados de Active Directory solo contienen las máquinas de Windows.
Configure Azure Monitor para importar los grupos de seguridad de Active Directory desde Configuración
avanzada en el área de trabajo de Log Analytics de Azure Portal. Seleccione Grupos de equipos , Active
Director y y, a continuación, Impor tar per tenencias a grupos de Active Director y de los equipos . No es
necesario realizar ninguna configuración más.
Una vez importados los grupos, el menú muestra el número de equipos con la pertenencia a grupos detectada y
el número de grupos de importados. Puede hacer clic en cualquiera de estos vínculos para devolver los registros
de ComputerGroup con esta información.
Windows Server Update Services
Al configurar Azure Monitor para importar pertenencias a grupos de WSUS, se analiza la pertenencia a grupos
de destino de todos los equipos con el agente de Log Analytics. Si utiliza destinatarios del lado cliente, se
importará a Azure Monitor la pertenencia a grupos de todos los equipos conectados a Azure Monitor que
formen parte de cualquier grupo de destino de WSUS. Si usa destinatarios del lado servidor, le recomendamos
que instale el agente de Log Analytics en el servidor WSUS para que se importe la información de pertenencia a
grupos en Azure Monitor. Esta pertenencia se actualiza continuamente cada 4 horas.
Configure Azure Monitor para importar los grupos de WSUS desde Configuración avanzada en el área de
trabajo de Log Analytics en Azure Portal. Seleccione Grupos de equipos , WSUS y, a continuación, Impor tar
per tenencias a grupos de WSUS . No es necesario realizar ninguna configuración más.
Una vez importados los grupos, el menú muestra el número de equipos con la pertenencia a grupos detectada y
el número de grupos de importados. Puede hacer clic en cualquiera de estos vínculos para devolver los registros
de ComputerGroup con esta información.
Administrador de configuración
Al configurar Azure Monitor para importar miembros de la recopilación de Configuration Manager, este crea un
grupo de equipos para cada colección. La información de los miembros de la colección se recupera cada tres
horas para mantener actualizados los grupos de equipos.
Para poder importar colecciones de Configuration Manager, debe conectar Configuration Manager a Azure
Monitor.
Una vez importadas las colecciones, el menú muestra el número de equipos con la pertenencia a grupos
detectada y el número de grupos de importados. Puede hacer clic en cualquiera de estos vínculos para devolver
los registros de ComputerGroup con esta información.
Administración de grupos de equipos

Puede ver los grupos de equipos que se crearon a partir de una consulta de registros o la API de búsqueda de
registros en Configuración avanzada en el área de trabajo de Log Analytics en Azure Portal. Seleccione
Grupos de equipos y, a continuación, Grupos guardados .
Haga clic en la x de la columna Quitar para eliminar el grupo de equipos. Haga clic en el icono Ver miembros
de un grupo para ejecutar la búsqueda de registros del grupo que devuelve sus miembros. No se puede modificar
un grupo de equipos, se debe eliminar y, a continuación, volver a crear con la configuración modificada.
Uso de un grupo de equipos de una consulta de registros

Puede utilizar un grupo de equipos creado a partir de una consulta de registros en una consulta tratando su alias
como una función, normalmente con la sintaxis siguiente:
Table | where Computer in (ComputerGroup)`
Por ejemplo, podría usar lo siguiente para devolver registros UpdateSummary solo para los equipos de un grupo
de equipos llamado mycomputergroup.
UpdateSummary | where Computer in (mycomputergroup)`
Los grupos de equipos importados y sus equipos incluidos se almacenan en la tabla ComputerGroup . Por
ejemplo, la siguiente consulta devolvería una lista de equipos en el grupo Equipos del dominio de Active
Directory.
ComputerGroup | where GroupSource == "ActiveDirectory" and Group == "Domain Computers" | distinct Computer
La siguiente consulta devolvería registros UpdateSummary solo para equipos del grupo Equipos del dominio.
let ADComputers = ComputerGroup | where GroupSource == "ActiveDirectory" and Group == "Domain Computers" |
distinct Computer;
UpdateSummary | where Computer in (ADComputers)
Registros de grupos de equipos

En el área de trabajo de Log Analytics se crea un registro para cada pertenencia a grupos de equipos creada
mediante Active Directory o WSUS. Estos registros tienen el tipo ComputerGroup y sus propiedades son las que
aparecen en la tabla siguiente. Para los grupos de equipos basados en consultas de registros no se crean
registros.
Type ComputerGroup
SourceSystem SourceSystem
Computer Nombre del equipo miembro.
Group Nombre del grupo.
GroupFullName Ruta de acceso completa al grupo, incluidos el origen y el

nombre de origen.
GroupSource Origen desde el que se ha recopilado el grupo.
ActiveDirectory
WSUS
WSUSClientTargeting
GroupSourceName Nombre del origen desde el que se recopiló el grupo. En el

caso de Active Directory, es el nombre del dominio.
ManagementGroupName Nombre del grupo de administración de agentes SCOM. En el

caso de los otros agentes, es AOI-<workspace ID>
TimeGenerated Fecha y hora en la que se creó o actualizó el grupo de

equipos.
Pasos siguientes
Obtenga información acerca de las consultas de registros para analizar los datos recopilados de soluciones y
orígenes de datos.
Consultas de registros de Azure Monitor
Los registros de Azure Monitor se crean en Azure Data Explorer y las consultas de registros de Azure Monitor
usan una versión del mismo lenguaje de consulta de Kusto. La documentación del lenguaje de consulta de Kusto
incluye todos los detalles del lenguaje y debe ser el principal recurso para escribir consultas de registros de Azure
Monitor. Esta página proporciona vínculos a otros recursos para aprender a escribir consultas y conocer las
diferencias con la implementación de Azure Monitor del lenguaje.
NOTE
Este artículo se ha actualizado recientemente para usar el término registros de Azure Monitor en lugar de Log Analytics. Los
datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen recopilándose y analizándose por
el mismo servicio de Log Analytics. Estamos actualizando la terminología para reflejar mejor el rol de los registros de Azure
Monitor. Consulte Azure Monitor terminology changes (Cambios en la terminología de Azure Monitor) para obtener más
información.
Introducción
Introducción a Log Analytics de Azure Monitor es una lección sobre cómo escribir consultas y trabajar con los
resultados en Azure Portal.
Introducción a las consultas de registros de Azure Monitor es una lección sobre cómo escribir consultas con los
datos de registro de Azure Monitor.
Conceptos
El análisis de los datos de registro en Azure Monitor ofrece una breve introducción a las consultas de registros
y describe cómo se estructuran los datos de Azure Monitor.
En Visualización y análisis de datos de registro en Azure Monitor se explican los portales donde se crean y
ejecutan las consultas de registros.
Referencia
Referencia del lenguaje de consulta es la referencia completa del lenguaje de consulta de Kusto.
Diferencias del lenguaje de consulta de registros de Azure Monitor describe las diferencias entre las versiones
del lenguaje de consulta de Kusto.
Propiedades estándar de los registros de Azure Monitor describe las propiedades que son estándar para todos
los datos de registro de Azure Monitor.
Realización de consultas de registros entre recursos en Azure Monitor indica cómo escribir consultas de
registros que usan datos procedentes de varias áreas de trabajo de Log Analytics y aplicaciones de Application
Insights.
Ejemplos
Ejemplos de consultas de registros de Azure Monitor proporciona ejemplos de consultas con datos de registro
de Azure Monitor.
Lecciones
Trabajo con cadenas en consultas de registros de Azure Monitor describe cómo trabajar con datos de cadena.
Trabajar con valores de fecha y hora en consultas de registros de Azure Monitor describe cómo trabajar con
datos de fecha y hora.
Agregaciones en consultas de registros de Azure Monitor y Agregaciones avanzadas en consultas de registros
de Azure Monitor describen cómo agregar y resumir datos.
Combinaciones en consultas de registros de Azure Monitor describe cómo combinar datos de varias tablas.
Trabajo con JSON y estructuras de datos en consultas de registros de Azure Monitor describe cómo analizar
datos JSON.
Escritura de consultas de registros avanzadas en Azure Monitor describe las estrategias para crear consultas
complejas y reutilizar código.
Creación de gráficos y diagramas a partir de consultas de registros de Azure Monitor describe cómo visualizar
los datos de una consulta de registros.
Hojas de características clave

Consulta de registros de SQL en Azure Monitor ayuda a los usuarios que ya están familiarizados con SQL.
Consulta de registros de Splunk en Azure Monitor ayuda a los usuarios que ya están familiarizados con
Splunk.
Pasos siguientes
Acceda a la documentación de referencia completa del lenguaje de consulta de Kusto.
Diferencias en el lenguaje de consulta de los
registros de Azure Monitor
Aunque los registros de Azure Monitor se basan en Azure Data Explorer y usa el mismo lenguaje de consulta de
Kusto, la versión del lenguaje presenta algunas diferencias. En este artículo se identifican los elementos que son
diferentes entre la versión del lenguaje que se utiliza en Data Explorer y la versión que se utiliza en las consultas
del registro de Azure Monitor.
NOTE
Los datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen recopilándose y
analizándose por el mismo servicio de Log Analytics. Estamos actualizando la terminología para reflejar mejor el rol de los
registros de Azure Monitor. Consulte Azure Monitor terminology changes (Cambios en la terminología de Azure Monitor)
para obtener más información.
Elementos de KQL que no se admiten en Azure Monitor

En las siguientes secciones se describen los elementos del lenguaje de consulta de Kusto que no son
compatibles con Azure Monitor.
Instrucciones que no se admiten en Azure Monitor
Alias
Parámetros de consulta
Funciones que no se admiten en Azure Monitor
cluster()
cursor_after()
cursor_before_or_at()
cursor_current(), current_cursor()
database()
current_principal()
extent_id()
extent_tags()
Operadores que no se admiten en Azure Monitor
Cross-Cluster Join
Complementos que no se admiten en Azure Monitor
Complemento de Python
sql_request plugin
Operadores adicionales de Azure Monitor

Los operadores siguientes admiten características específicas de Azure Monitor que no están disponibles fuera
de Azure Monitor.
app()
workspace()
Pasos siguientes
Obtenga referencias a distintos recursos para escribir consultas de Azure Monitor.
Acceda a la documentación de referencia completa del lenguaje de consulta de Kusto.
Operadores útiles en las consultas de registros de
Azure Monitor
En la tabla siguiente se proporcionan algunas funciones comunes que se usan en diferentes escenarios de
consultas de registros de Azure Monitor.
Operadores útiles
C AT EGO RY F UN C IÓ N A P RO P IA DA DE A N A LY T IC S
Alias de columna y de selección project , project-away , extend
Constantes y tablas temporales let scalar_alias_name = …;

let table_alias_name = … … … ;
Operadores de cadena y comparación startswith , !startswith , has , !has

contains , !contains , containscs
hasprefix , !hasprefix , hassuffix , !hassuffix , in ,
!in
matches regex
== , =~ , != , !~
Funciones de cadena comunes strcat() , replace() , tolower() , toupper() ,

substring() , strlen()
Funciones matemáticas comunes sqrt() , abs()

exp() , exp2() , exp10() , log() , log2() , log10() ,
pow()
gamma() , gammaln()
Análisis de texto extract() , extractjson() , parse , split()
Limitación de la salida take , limit , top , sample
Funciones de fecha now() , ago()

datetime() , datepart() , timespan
startofday() , startofweek() , startofmonth() ,
startofyear()
endofday() , endofweek() , endofmonth() , endofyear()
dayofweek() , dayofmonth() , dayofyear()
getmonth() , getyear() , weekofyear() , monthofyear()
Agrupación y agregación summarize by

max() , min() , count() , dcount() , avg() , sum()
stddev() , countif() , dcountif() , argmax() ,
argmin()
percentiles() , percentile_array()
C AT EGO RY F UN C IÓ N A P RO P IA DA DE A N A LY T IC S
Combinaciones y uniones join kind=leftouter , inner , rightouter , fullouter ,

leftanti
union
Clasificar, ordenar sort , order
Objeto dinámico (JSON y matriz) parsejson()

makeset() , makelist()
split() , arraylength()
zip() , pack()
Operadores lógicos and , or , iff(condition, value_t, value_f)

binary_and() , binary_or() , binary_not() ,
binary_xor()
Machine Learning evaluate autocluster , basket , diffpatterns ,

extractcolumns
Pasos siguientes
Repase una lección sobre la escritura de consultas de registro en Azure Monitor.
Uso de funciones en consultas de registros de Azure
Monitor
Para usar una consulta de registro con otra consulta, puede guardarla como una función. Esto le permite
simplificar las consultas complejas al dividirlas en partes y, además, le permite reutilizar código común con varias
consultas.
Creación de una función

Para crear una función con Log Analytics en Azure Portal, haga clic en Guardar y, después, proporcione la
información de la tabla siguiente.
C O N F IGURA C IÓ N DESC RIP C IÓ N
Nombre Nombre para mostrar de la consulta en el Explorador de

consultas .
Guardar como Función
Alias de función Nombre corto para usar la función en otras consultas. No

puede contener espacios y debe ser único.
Category Categoría para organizar las consultas y funciones guardadas

en el Explorador de consultas .
Uso de una función

Use una función al incluir su alias en otra consulta. Se puede usar como cualquier otra tabla.
Parámetros de función
Puede agregar parámetros a una función para que pueda proporcionar valores de determinadas variables al
llamarla. La única manera de crear una función con parámetros es usar una plantilla de Resource Manager.
Consulte Ejemplos de plantillas de Resource Manager para consultas de registros en Azure Monitor para obtener
un ejemplo.
Ejemplo
La siguiente consulta de ejemplo devuelve todas las actualizaciones de seguridad faltantes que se notificaron en
el último día. Guarde esta consulta como función con el alias security_updates_last_day.
Update
| where Classification == "Security Updates"
| where UpdateState == "Needed"
Cree otra consulta y llame a la función security_updates_last_day para buscar las actualizaciones de seguridad
relacionadas con SQL necesarias.
security_updates_last_day | where Title contains "SQL"
Pasos siguientes
Consulte otras lecciones para escribir consultas de registro de Azure Monitor:
Combinaciones
Gráficos
Transición desde la búsqueda de registros de Log
Analytics a los registros de Azure Monitor
La búsqueda de registros en Log Analytics se ha reemplazado recientemente por una nueva experiencia para
analizar los registros de Azure Monitor. La página de búsqueda de registros sigue siendo accesible con el elemento
de menú Registros (clásicos) de la página Áreas de trabajo de Log Analytics en Azure Portal, pero se retirará
el 15 de febrero de 2019. En este artículo se describen las diferencias entre las dos experiencias para ayudar a
realizar la transición desde la búsqueda de registros.
Filtrado de los resultados de una consulta

En la búsqueda de registros, se muestra una lista de filtros cuando se entregan los resultados de búsqueda.
Seleccione un filtro y haga clic en Aplicar para ejecutar la consulta con el filtro seleccionado.
En los registros de Azure Monitor, seleccione Filter (preview) [Filtro (versión preliminar)] para mostrar los filtros.
Haga clic en el icono de filtro para mostrar los filtros de adición. Seleccione un filtro y haga clic en Apply & Run
(Aplicar y ejecutar) para ejecutar la consulta con el filtro seleccionado.
Extracción de campos personalizados
En la búsqueda de registros, los campos personalizados se extraen en la vista de lista, donde el menú de un campo
incluye la acción Extraer campos de tabla.
En los registros de Azure Monitor, los campos personalizados se extraen en la vista de tabla. Haga clic en la flecha
situada a la izquierda de un registro para expandirlo y, después, haga clic en los puntos suspensivos para acceder a
la acción Extract fields (Extraer campos).
Funciones y grupos de equipos

Para guardar una búsqueda en la búsqueda de registros, seleccione Búsquedas guardadas y Agregar para
proporcionar el nombre, la categoría y el texto de la consulta. Agregue un alias de función para crear un grupo de
equipos.
Para guardar la consulta actual en los registros de Azure Monitor, seleccione Save (Guardar). Cambie Save as
(Guardar como) a Function (Función) y proporcione un alias de función en Function Alias para crear una función.
Seleccione Guardar esta consulta como un grupo de equipos para utilizar el alias de función para un grupo de
equipos.
Consultas guardadas
En la búsqueda de registros, las consultas guardadas están disponibles en el elemento de la barra de acciones
Búsquedas guardadas . En los registros de Azure Monitor, las consultas guardadas están disponibles en el
Explorador de consultas.
Exploración en profundidad de las filas resumidas

En la búsqueda de registros, puede hacer clic en una fila de una consulta resumida para iniciar otra consulta que
muestre los registros detallados de esa fila.
En los registros de Azure Monitor, debe modificar la consulta para que devuelva estos registros. Expanda una de las
filas en los resultados y haga clic en + junto al valor para agregarlo a la consulta. A continuación, marque como
comentario el comando summarize y vuelva a ejecutar la consulta.
Realizar acción
En la búsqueda de registros, puede seleccionar Realizar acción para iniciar un runbook.
En los registros de Azure Monitor, cree una alerta para la consulta de registros. Configure un grupo de acciones con
una o varias acciones que se ejecutarán en respuesta a la alerta.
Pasos siguientes
Más información sobre la nueva experiencia de registros de Azure Monitor.
Trabajo con cadenas en consultas de registro de
Azure Monitor
NOTE
Debe completar Introducción a los análisis de registros de Azure Monitor y Introducción a las consultas de registro en
Azure Monitor antes de completar este tutorial.
NOTE
Puede hacer este ejercicio en su propio entorno de Log Analytics, o puede usar nuestro entorno de demostración, que
incluye una gran cantidad de datos de ejemplo.
En este artículo se describe cómo editar, comparar, buscar y realizar una amplia variedad de otras operaciones
con cadenas.
Cada carácter de una cadena contiene un número de índice, según su ubicación. El primer carácter está en el
índice 0, el siguiente carácter en el 1 y así sucesivamente. Varias funciones de cadena usan números de índice,
como se muestra en las secciones siguientes. Muchos de los ejemplos siguientes usan el comando print para
mostrar la manipulación de cadenas sin usar un origen de datos específico.
Cadenas y caracteres de escape

Los valores de cadena se encapsulan con los caracteres de comillas simples o dobles. La barra diagonal inversa
(\) se usa como carácter de escape para el carácter que le sigue, por ejemplo, \t para tabulación, \n para nueva
línea y " para el propio carácter de comillas.
print "this is a 'string' literal in double \" quotes"
print 'this is a "string" literal in single \' quotes'
Para evitar que "\" actúe como carácter de escape, agregue "@" como prefijo a la cadena:
print @"C:\backslash\not\escaped\with @ prefix"
Comparaciones de cadenas
DIST IN GUE M AY ÚSC UL A S
O P ERATO R DESC RIP C IÓ N DE M IN ÚSC UL A S E JEM P LO ( P RO DUC E TRUE )
== Equals Sí "aBc" == "aBc"
!= Not Equals Sí "abc" != "ABC"

=~ Equals No "abc" =~ "ABC"
!~ Not Equals No "aBc" !~ "xyz"
has El lado derecho es un No "North America" has

término completo en el lado "america"
izquierdo
!has El lado derecho no es un No "North America" !has

término completo en el lado "amer"
izquierdo
has_cs El lado derecho es un Sí "North America" has_cs

término completo en el lado "America"
izquierdo
!has_cs El lado derecho no es un Sí "North America" !has_cs

término completo en el lado "amer"
izquierdo
hasprefix El lado derecho es un prefijo No "North America"

de término en el lado hasprefix "ame"
izquierdo
!hasprefix El lado derecho no es un No "North America"

prefijo de término en el lado !hasprefix "mer"
izquierdo
hasprefix_cs El lado derecho es un prefijo Sí "North America"

de término en el lado hasprefix_cs "Ame"
izquierdo
!hasprefix_cs El lado derecho no es un Sí "North America"

prefijo de término en el lado !hasprefix_cs "CA"
izquierdo
hassuffix El lado derecho es un sufijo No "North America"

de término en el lado hassuffix "ica"
izquierdo
!hassuffix El lado derecho no es un No "North America"

sufijo de término en el lado !hassuffix "americ"
izquierdo
hassuffix_cs El lado derecho es un sufijo Sí "North America"

de término en el lado hassuffix_cs "ica"
izquierdo
!hassuffix_cs El lado derecho no es un Sí "North America"

sufijo de término en el lado !hassuffix_cs "icA"
izquierdo
contains El lado derecho aparece No "FabriKam" contains

como subsecuencia en el "BRik"
lado izquierdo
!contains El lado derecho no aparece No "Fabrikam" !contains

en el lado izquierdo "xyz"
contains_cs El lado derecho aparece Sí "FabriKam" contains_cs

como subsecuencia en el "Kam"
lado izquierdo
!contains_cs El lado derecho no aparece Sí "Fabrikam" !contains_cs

en el lado izquierdo "Kam"
startswith El lado derecho es una No "Fabrikam" startswith

subsecuencia inicial del lado "fab"
izquierdo
!startswith El lado derecho no es una No "Fabrikam" !startswith

subsecuencia inicial del lado "kam"
izquierdo
startswith_cs El lado derecho es una Sí "Fabrikam"

subsecuencia inicial del lado startswith_cs "Fab"
izquierdo
!startswith_cs El lado derecho no es una Sí "Fabrikam"

subsecuencia inicial del lado !startswith_cs "fab"
izquierdo
endswith El lado derecho es una No "Fabrikam" endswith

subsecuencia final del lado "Kam"
izquierdo
!endswith El lado derecho no es una No "Fabrikam" !endswith

subsecuencia final del lado "brik"
izquierdo
endswith_cs El lado derecho es una Sí "Fabrikam" endswith

subsecuencia final del lado "Kam"
izquierdo
!endswith_cs El lado derecho no es una Sí "Fabrikam" !endswith

subsecuencia final del lado "brik"
izquierdo
matches regex El lado izquierdo contiene a Sí "Fabrikam" matches

una coincidencia del lado regex "b.*k"
derecho
in Igual a uno de los Sí "abc" in ("123", "345",

elementos "abc")
!in No es igual a uno de los Sí "bca" !in ("123",

elementos "345", "abc")
countof
Cuenta las apariciones de una subcadena en una cadena. Puede encontrar coincidencias de cadenas sin formato
o usar expresiones regulares. Las coincidencias de cadena sin formato se pueden superponer, mientras que las
coincidencias de expresión regular no.
Sintaxis
countof(text, search [, kind])
Argumentos:
text : la cadena de entrada.
search : la cadena sin formato o la expresión regular que debe coincidir en el texto.
kind - normal | regex (valor predeterminado: normal).
Devuelve
El número de veces que la cadena de búsqueda puede coincidir en el contenedor. Las coincidencias de cadena
sin formato se pueden superponer, mientras que las coincidencias de expresión regular no.
Ejemplos
Coincidencias de cadena sin formato
print countof("The cat sat on the mat", "at"); //result: 3

print countof("aaa", "a"); //result: 3
print countof("aaaa", "aa"); //result: 3 (not 2!)
print countof("ababa", "ab", "normal"); //result: 2
print countof("ababa", "aba"); //result: 2
Coincidencias de expresiones regulares
print countof("The cat sat on the mat", @"\b.at\b", "regex"); //result: 3

print countof("ababa", "aba", "regex"); //result: 1
print countof("abcabc", "a.c", "regex"); // result: 2
extract
Obtiene una coincidencia para una expresión regular a partir de una cadena determinada. Opcionalmente,
también convierte la subcadena extraída en el tipo especificado.
Sintaxis
extract(regex, captureGroup, text [, typeLiteral])
Argumentos
regex : una expresión regular.
captureGroup : una constante de enteros positiva que indica el grupo de capturas que se va a extraer. 0
significa toda la coincidencia; 1, el valor que coincide con el primer "("paréntesis")" de la expresión regular; 2
o más, los posteriores paréntesis.
text : la cadena que se va a buscar.
typeLiteral : un literal de tipo opcional (por ejemplo, typeof(long)). Si se proporciona, la subcadena extraída
se convierte a este tipo.
Devuelve
La subcadena que coincide con el grupo de captura indicado, captureGroup, opcionalmente convertido a
typeLiteral. Si no hay ninguna coincidencia, o se produce un error en la conversión del tipo, devuelve null.
Ejemplos
En el ejemplo siguiente se extrae el último octeto de ComputerIP de un registro de latido:
Heartbeat
| where ComputerIP != ""
| take 1
| project ComputerIP, last_octet=extract("([0-9]*$)", 1, ComputerIP)
En el ejemplo siguiente se extrae el último octeto, se convierte a un tipo real (número) y se calcula el siguiente
valor de IP
Heartbeat
| where ComputerIP != ""
| take 1
| extend last_octet=extract("([0-9]*$)", 1, ComputerIP, typeof(real))
| extend next_ip=(last_octet+1)%255
| project ComputerIP, last_octet, next_ip
En el ejemplo siguiente, se busca la cadena Trace para una definición de "Duration". La coincidencia se convierte
en real y se multiplica por una constante de tiempo (1 s) que convierte la duración al tipo timespan.
let Trace="A=12, B=34, Duration=567, ...";

print Duration = extract("Duration=([0-9.]+)", 1, Trace, typeof(real)); //result: 567
print Duration_seconds = extract("Duration=([0-9.]+)", 1, Trace, typeof(real)) * time(1s); //result:
00:09:27
isempty, isnotempty, notempty

isempty devuelve true si el argumento es una cadena vacía o null (vea también isnull).
isnotempty devuelve true si el argumento no es una cadena vacía o null (vea también isnotnull). alias:
notempty.
Sintaxis
isempty(value)
isnotempty(value)
Ejemplos
print isempty(""); // result: true
print isempty("0"); // result: false
print isempty(0); // result: false
print isempty(5); // result: false
Heartbeat | where isnotempty(ComputerIP) | take 1 // return 1 Heartbeat record in which ComputerIP isn't
empty
parseurl
Divide una dirección URL en partes (protocolo, host, puerto, etc.) y devuelve un objeto de diccionario que
contiene las partes como cadenas.
Sintaxis
parseurl(urlstring)
Ejemplos
print parseurl("http://user:pass@contoso.com/icecream/buy.aspx?a=1&b=2#tag")
El resultado será:
{
"Scheme" : "http",
"Host" : "contoso.com",
"Port" : "80",
"Path" : "/icecream/buy.aspx",
"Username" : "user",
"Password" : "pass",
"Query Parameters" : {"a":"1","b":"2"},
"Fragment" : "tag"
}
replace
Reemplaza todas las coincidencias de expresiones regulares por otra cadena.
Sintaxis
replace(regex, rewrite, input_text)
Argumentos
regex : la expresión regular con la que debe coincidir. Puede contener grupos de captura entre "
("paréntesis")".
rewrite : la expresión regular de sustitución para cualquier coincidencia de la expresión regular coincidente.
Use \0 para hacer referencia a toda la coincidencia, \1 para el primer grupo de capturas, \2 y así
sucesivamente para los grupos de capturas posteriores.
input_text : la cadena de entrada que se va a buscar.
Devuelve
El texto después de reemplazar todas las coincidencias de la expresión regular por evaluaciones de rewrite. Las
coincidencias no se superponen.
Ejemplos
SecurityEvent
| take 1
| project Activity
| extend replaced = replace(@"(\d+) -", @"Activity ID \1: ", Activity)
Puede tener los resultados siguientes:
A C T IVIDA D REEM P L A Z A DO
4663: se ha intentado obtener acceso a un objeto. Identificador de actividad 4663: se ha intentado obtener
acceso a un objeto.
split
Divide una cadena determinada según un delimitador especificado y devuelve una matriz de las subcadenas
resultantes.
Sintaxis
split(source, delimiter [, requestedIndex])
Argumentos:
source : la cadena que se va a dividir según el delimitador especificado.
delimiter : el delimitador que se usará para dividir la cadena de origen.
requestedIndex : un índice opcional de base cero. Si se proporciona, la matriz de cadenas devuelta contendrá
solo ese elemento (si existe).
Ejemplos
print split("aaa_bbb_ccc", "_"); // result: ["aaa","bbb","ccc"]

print split("aa_bb", "_"); // result: ["aa","bb"]
print split("aaa_bbb_ccc", "_", 1); // result: ["bbb"]
print split("", "_"); // result: [""]
print split("a__b", "_"); // result: ["a","","b"]
print split("aabbcc", "bb"); // result: ["aa","cc"]
strcat
Concatena los argumentos de cadena (admite de 1 a 16 argumentos).
Sintaxis
strcat("string1", "string2", "string3")
Ejemplos
print strcat("hello", " ", "world") // result: "hello world"

strlen
Devuelve la longitud de una cadena.
Sintaxis
strlen("text_to_evaluate")
Ejemplos
print strlen("hello") // result: 5
substring
Extrae una subcadena de una cadena de origen determinada empezando en un índice especificado.
Opcionalmente, se puede especificar la longitud de la subcadena solicitada.
Sintaxis
substring(source, startingIndex [, length])
Argumentos:
source : la cadena de origen de la que se tomará la subcadena.
startingIndex : la posición del carácter inicial basado en cero de la subcadena solicitada.
length : un parámetro opcional que puede usarse para especificar la longitud solicitada de la subcadena
devuelta.
Ejemplos
print substring("abcdefg", 1, 2); // result: "bc"

print substring("123456", 1); // result: "23456"
print substring("123456", 2, 2); // result: "34"
print substring("ABCD", 0, 2); // result: "AB"
tolower, toupper
Convierte una cadena determinada a todo minúsculas o todo mayúsculas.
Sintaxis
tolower("value")
toupper("value")
Ejemplos
print tolower("HELLO"); // result: "hello"

print toupper("hello"); // result: "HELLO"
Pasos siguientes
Continúe con los tutoriales avanzados:
Gráficos y diagramas
Trabajar con JSON y estructuras de datos
Combinaciones: entre análisis
Trabajar con valores de fecha y hora en consultas de
registro de Azure Monitor
NOTE
Debe completar la Introducción al portal de Analytics y la Introducción a las consultas en Log Analytics antes de completar
esta lección.
NOTE
En este artículo se describe cómo trabajar con datos de fecha y hora en consultas de registro de Azure Monitor.
Conceptos básicos de fecha y hora

El lenguaje de consulta de Kusto tiene dos tipos de datos principales asociados con las fechas y horas: datetime y
timespan. Todas las fechas se expresan en formato UTC. Aunque se admiten varios formatos de datetime, se
prefiere el formato ISO8601.
Los valores timespan se expresan como un decimal seguido de una unidad de tiempo:
A B REVIAT URA UN IDA D DE T IEM P O
d day
h hour
m minute
s second
ms milisegundo
microsegundo microsegundo
tic nanosegundo
Los valores datetime se pueden crear mediante la conversión de una cadena con el operador todatetime . Por
ejemplo, para revisar los latidos de máquina virtual enviados en un período de tiempo específico, use el operador
between para especificar un intervalo de tiempo.
Heartbeat
| where TimeGenerated between(datetime("2018-06-30 22:46:42") .. datetime("2018-07-01 00:57:27"))
Otro escenario común es comparar un valor datetime hasta el presente. Por ejemplo, para ver todos los latidos
durante los últimos dos minutos, puede usar el operador now junto con un valor timespan que represente dos
minutos:
Heartbeat
| where TimeGenerated > now() - 2m
También está disponible un acceso directo para esta función:
Heartbeat
| where TimeGenerated > now(-2m)
Sin embargo, el método más corto y legible es usar el operador ago :
Heartbeat
Supongamos que en lugar de saber la hora de inicio y finalización, conoce la hora de inicio y la duración. Puede
volver a escribir la consulta como sigue:
let startDatetime = todatetime("2018-06-30 20:12:42.9");

let duration = totimespan(25m);
Heartbeat
| where TimeGenerated between(startDatetime .. (startDatetime+duration) )
| extend timeFromStart = TimeGenerated - startDatetime
Conversión de unidades de tiempo

Quizá quiera expresar un valor datetime o timespan en una unidad de tiempo distinta de la predeterminada. Por
ejemplo, si está revisando los eventos de error de los últimos 30 minutos y necesita una columna calculada que
muestre cuánto tiempo hace que se produjo el evento:
Event
| extend timeAgo = now() - TimeGenerated
La columna timeAgo contiene valores como: "00:09:31.5118992", que significa que tienen el formato
hh:mm:ss.fffffff. Si desea dar formato a estos valores en numver de minutos desde la hora de inicio, divida ese
valor por "1 minuto":
Event
| extend timeAgo = now() - TimeGenerated
| extend timeAgoMinutes = timeAgo/1m
Agregaciones y creación de cubos por intervalos de tiempo

Otro escenario común es la necesidad de obtener estadísticas de un período de tiempo determinado en un
intervalo de agregación determinado. Para este escenario, se puede usar un operador bin como parte de una
cláusula summarize.
Use la siguiente consulta para obtener el número de eventos que se produjeron cada 5 minutos durante la última
media hora:
Event
| summarize events_count=count() by bin(TimeGenerated, 5m)
Esta consulta genera la tabla siguiente:
T IM EGEN ERAT ED( UTC ) EVEN T S_C O UN T
2018-08-01T09:30:00.000 54
2018-08-01T09:35:00.000 41
2018-08-01T09:40:00.000 42
2018-08-01T09:45:00.000 41
2018-08-01T09:50:00.000 41
2018-08-01T09:55:00.000 16
Otra forma de crear cubos de resultados es usar funciones, como startofday :
Event
| summarize events_count=count() by startofday(TimeGenerated)
Esta consulta genera los resultados siguientes:
T IM ESTA M P C O UN T _
2018-07-28T00:00:00.000 7136
2018-07-29T00:00:00.000 12 315
2018-07-30T00:00:00.000 16 847
2018-07-31T00:00:00.000 12 616
2018-08-01T00:00:00.000 5416
Zonas horarias
Puesto que todos los valores datetime se expresan en formato UTC, a menudo resulta útil convertir estos valores
al formato de la zona horaria local. Por ejemplo, use este cálculo para convertir la hora UTC a la hora estándar del
Pacífico:
Event
| extend localTimestamp = TimeGenerated - 8h
Funciones relacionadas
C AT EGO RY F UN C IÓ N
Convertir tipos de datos todatetime totimespan
Redondear valor al tamaño de bin bin
Obtener una fecha u hora especificas ago now
Obtener parte del valor datetime_part getmonth monthofyear getyear dayofmonth

dayofweek dayofyear weekofyear
Obtener un valor de fecha relativa endofday endofweek endofmonth endofyear startofday

startofweek startofmonth startofyear
Pasos siguientes
Consulte otras lecciones para usar el lenguaje de consulta de Kusto con datos de registro de Azure Monitor:
Combinaciones
Gráficos
Agregaciones en consultas de registros de Azure
Monitor
NOTE
Debe completar la Introducción al portal de Analytics y la Introducción a las consultas en Log Analytics antes de completar
esta lección.
NOTE
En este artículo se describen las funciones de agregación en consultas de registro de Azure Monitor que ofrecen
maneras útiles de analizar los datos. Estas funciones usan el operador summarize que genera una tabla con
resultados agregados de la tabla de entrada.
Recuentos
count
Cuente el número de filas del conjunto de resultados después de aplicar filtros. En el ejemplo siguiente se
devuelve el número total de filas de la tabla Perf de los últimos 30 minutos. El resultado se devuelve en una
columna denominada count_ a menos que se le asigne un nombre específico:
Perf
| summarize count()
Perf
| summarize num_of_records=count()
La visualización de un gráfico de tiempo puede ser útil para ver la tendencia a lo largo del tiempo:
Perf
| summarize count() by bin(TimeGenerated, 5m)
| render timechart
La salida de este ejemplo muestra la línea de tendencia del recuento de registros de perf en intervalos de 5
minutos:
dcount, dcountif
Use dcount y dcountif para contar valores distintos en una columna específica. En la siguiente consulta se
evalúa cuántos equipos distintos enviaron latidos en la última hora:
Heartbeat
| summarize dcount(Computer)
Para contar solo los equipos Linux que enviaron latidos, use dcountif :
Heartbeat
| summarize dcountif(Computer, OSType=="Linux")
Evaluación de subgrupos
Para realizar un recuento u otras agregaciones en subgrupos de los datos, use la palabra clave by . Por ejemplo,
para contar el número de equipos Linux distintos que enviaron latidos en cada país o región:
Heartbeat
| summarize distinct_computers=dcountif(Computer, OSType=="Linux") by RemoteIPCountry
REM OT EIP C O UN T RY DIST IN C T _C O M P UT ERS
Estados Unidos 19
Canadá 3
Irlanda 0
Reino Unido 0
Países Bajos 2
Para analizar subgrupos incluso más pequeños de los datos, agregue nombres de columna adicionales a la
sección by . Por ejemplo, si desea contar los distintos equipos de cada país o región por OSType:
Heartbeat
| summarize distinct_computers=dcountif(Computer, OSType=="Linux") by RemoteIPCountry, OSType
Percentiles y varianza
Al evaluar valores numéricos, una práctica común es que calcular la media con summarize avg(expression) . Las
medias se ven afectadas por valores extremos que caracterizan a solo unos pocos casos. Para solucionar ese
problema, puede usar funciones menos sensibles, como median o variance .
Percentil
Para buscar el valor medio, utilice la función percentile con un valor para especificar el percentil:
Perf
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| summarize percentiles(CounterValue, 50) by Computer
También puede especificar percentiles diferentes para obtener un resultado agregado para cada uno:
Perf
| summarize percentiles(CounterValue, 25, 50, 75, 90) by Computer
Esto podría mostrar que algunas CPU de equipos tienen valores medios similares, pero mientras algunas son
constantes en torno al valor medio, otros equipos han informado de valores de CPU mucho menores y mayores,
lo que significa que experimentaron picos.
Variance
Para evaluar directamente la varianza de un valor, use los métodos estándar de desviación y varianza:
Perf
| summarize stdev(CounterValue), variance(CounterValue) by Computer
Una buena forma de analizar la estabilidad del uso de CPU consiste en combinar stdev con el cálculo del valor
medio:
Perf
| summarize stdev(CounterValue), percentiles(CounterValue, 50) by Computer
Combinaciones
Gráficos
Agregaciones avanzadas en consultas de registros
de Azure Monitor
NOTE
Debe completar las Agregaciones en consultas de Azure Monitor antes de completar esta lección.
NOTE
En este artículo se describen algunas de las opciones de agregación más avanzadas disponibles para las
consultas de Azure Monitor.
Generación de listas y conjuntos

Puede usar el elemento makelist para dinamizar los datos por el orden de los valores de una columna en
particular. Por ejemplo, puede explorar el orden más común en el que los eventos se producen en los equipos.
Básicamente, puede dinamizar los datos por el orden de los objetos EventID de cada máquina.
Event
| order by TimeGenerated desc
| summarize makelist(EventID) by Computer
C O M P UT ER L IST _EVEN T ID
computer1 [704,701,1501,1500,1085,704,704,701]
computer2 [326,105,302,301,300,102]
… …
El elemento makelist genera una lista en el orden en el que se le pasaron datos. Para ordenar los eventos del
más antiguo al más reciente, use el elemento asc en la instrucción order en lugar del elemento desc .
También es útil crear una lista de valores simplemente distintos. Esto se denomina un conjunto y se puede
generar con el elemento makeset :
Event
| order by TimeGenerated desc
| summarize makeset(EventID) by Computer
C O M P UT ER L IST _EVEN T ID
computer1 [704,701,1501,1500,1085]
computer2 [326,105,302,301,300,102]
… …
Igual que con el elemento makelist , el elemento makeset también funciona con datos ordenados y generará
las matrices en función del orden de las filas que se le pasen.
Expansión de listas
La operación inversa de makelist o makeset es mvexpand , que expande una lista de valores para separar las
filas. Puede expandir a cualquier número de columnas dinámicas, JSON y de matriz. Por ejemplo, puede
comprobar la tabla Heartbeat para ver las soluciones que envían datos desde los equipos que enviaron un
latido durante la última hora:
Heartbeat
| project Computer, Solutions
C O M P UT ER SO L UC IO N ES
computer1 "security", "updates", "changeTracking"
computer2 "security", "updates"
computer3 "antiMalware", "changeTracking"
… …
Use mvexpand para mostrar cada valor en una fila separada, en lugar de una lista separada por comas:
Heartbeat
| project Computer, split(Solutions, ",")
| mvexpand Solutions
computer1 "security"
computer1 "updates"
computer1 "changeTracking"
computer2 "security"
computer2 "updates"
computer3 "antiMalware"
computer3 "changeTracking"
… …
Luego puede usar makelist de nuevo para agrupar elementos y, esta vez, ver la lista de equipos por solución:
Heartbeat
| project Computer, split(Solutions, ",")
| mvexpand Solutions
| summarize makelist(Computer) by tostring(Solutions)
SO L UC IO N ES L IST _C O M P UT ER
"security" ["computer1", "computer2"]
"updates" ["computer1", "computer2"]
"changeTracking" ["computer1", "computer3"]
"antiMalware" ["computer3"]
… …
Control de la ausencia de intervalos

Una aplicación útil del elemento mvexpand es la necesidad de rellenar valores predeterminados para los
intervalos que faltan. Por ejemplo, suponga que busca el tiempo de actividad de un equipo determinado
explorando su latido. También quiere ver el origen del latido que se encuentra en la columna categoría.
Normalmente, se usaría una instrucción summarize simple, de la forma siguiente:
Heartbeat
| summarize count() by Category, bin(TimeGenerated, 1h)
C AT EGO RY T IM EGEN ERAT ED C O UN T _
Agente directo 2017-06-06T17:00:00Z 15
… … …
Aunque, en estos resultados, falta el cubo asociado con "2017-06-06T19:00:00Z" porque no hay ningún dato de
latido para esa hora. Use la función make-series para asignar un valor predeterminado a los cubos vacíos. Esto
generará una fila para cada categoría con dos columnas de matriz adicionales, una para los valores y otra para
los cubos de tiempo coincidentes:
Heartbeat
| make-series count() default=0 on TimeGenerated in range(ago(1d), now(), 1h) by Category
C AT EGO RY C O UN T _ T IM EGEN ERAT ED
Agente directo [15,60,0,55,60,57,60,...] ["2017-06-

06T17:00:00.0000000Z","2017-06-
06T18:00:00.0000000Z","2017-06-
06T19:00:00.0000000Z","2017-06-
06T20:00:00.0000000Z","2017-06-
06T21:00:00.0000000Z",...]
… … …
El tercer elemento de la matriz count_ es 0, según lo previsto, y hay una marca de tiempo coincidente de "2017-
06-06T19:00:00.0000000Z" en la matriz TimeGenerated. Aunque, este formato de matriz es difícil de leer. Use el
elemento mvexpand para expandir las matrices y producir la salida en el mismo formato que el que genera la
instrucción summarize :
Heartbeat
| make-series count() default=0 on TimeGenerated in range(ago(1d), now(), 1h) by Category
| mvexpand TimeGenerated, count_
| project Category, TimeGenerated, count_
C AT EGO RY T IM EGEN ERAT ED C O UN T _
… … …
Acotar los resultados a un conjunto de elementos: let , makeset ,

toscalar , in
Un escenario común consiste en seleccionar los nombres de algunas entidades específicas según un conjunto
de criterios y, a continuación, filtrar un conjunto de datos diferente para ese conjunto de entidades. Por ejemplo
podría buscar los equipos a los que se sabe que les faltan actualizaciones e identificar las direcciones IP que
estos equipos llaman:
let ComputersNeedingUpdate = toscalar(
Update
| summarize makeset(Computer)
| project set_Computer
);
WindowsFirewall
| where Computer in (ComputersNeedingUpdate)
Pasos siguientes
Combinaciones
Gráficos
Combinaciones en consultas de registros de Azure
Monitor
NOTE
Debe completar Introducción a Log Analytics de Azure Monitor y Consultas de registros de Azure Monitor antes de
realizar los pasos de esta lección.
NOTE
Las combinaciones permiten analizar datos de varias tablas, en la misma consulta. Combinan las filas de dos
conjuntos de datos haciendo coincidir los valores de columnas especificadas.
SecurityEvent
| where EventID == 4624 // sign-in events
| project Computer, Account, TargetLogonId, LogonTime=TimeGenerated
| join kind= inner (
SecurityEvent
| where EventID == 4634 // sign-out events
| project TargetLogonId, LogoffTime=TimeGenerated
) on TargetLogonId
| extend Duration = LogoffTime-LogonTime
| project-away TargetLogonId1
| top 10 by Duration desc
En este ejemplo, en el primer conjunto de datos se filtran todos los eventos de inicio de sesión. Esto se combina
con un segundo conjunto de datos que en el que se filtran todos los eventos de cierre de sesión. Las columnas
proyectadas son Computer, Account, TargetLogonId y TimeGenerated. Los conjuntos de datos se correlacionan
mediante una columna compartida, TargetLogonId. La salida es un único registro por correlación, que contiene
las horas de inicio de sesión y de cierre de sesión.
Si ambos conjuntos de datos tienen columnas con los mismos nombres, se da a las columnas del conjunto de
datos de la derecha un número de índice, por lo que en este ejemplo los resultados mostrarán TargetLogonId
con valores de la tabla del lado izquierdo y TargetLogonId1 con valores de la tabla de la derecha. En este caso, se
ha quitado la segunda columna TargetLogonId1 con el operador project-away .
NOTE
Para mejorar el rendimiento, conserve solo las columnas relevantes de los conjuntos de datos combinados, con el
operador project .
Use la siguiente sintaxis para unir dos conjuntos de datos; la clave combinada tiene un nombre distinto entre las
dos tablas:
Table1
| join ( Table2 )
on $left.key1 == $right.key2
Tablas de búsqueda
Un uso común de las combinaciones es la utilización de una asignación estática de valores mediante la función
datatable que puede ayudar a transformar los resultados a una forma con mejor presentación. Por ejemplo,
enriquecer los datos de eventos de seguridad con el nombre del evento para cada id. de evento.
let DimTable = datatable(EventID:int, eventName:string)

[
4625, "Account activity",
4688, "Process action",
4658, "The handle to an object was closed",
4656, "A handle to an object was requested",
4690, "An attempt was made to duplicate a handle to an object",
4663, "An attempt was made to access an object",
5061, "Cryptographic operation",
5058, "Key file operation"
];
SecurityEvent
| join kind = inner
DimTable on EventID
| summarize count() by eventName
Tipos de combinación
Especifique el tipo de combinación con el argumento kind. Cada tipo realiza a una coincidencia diferente entre
los registros de las tablas dadas, como se describe en la tabla siguiente.
T IP O DE C O M B IN A C IÓ N DESC RIP C IÓ N
innerunique Este es el modo de combinación predeterminado. En primer

lugar, se buscan los valores de la columna coincidente de la
tabla izquierda y se quitan los valores duplicados. A
continuación, el conjunto de valores únicos se compara con
la tabla derecha.
interna Solo los registros coincidentes en ambas tablas se incluyen

en los resultados.
T IP O DE C O M B IN A C IÓ N DESC RIP C IÓ N
leftouter Todos los registros de la tabla izquierda y los registros

coincidentes de la tabla derecha se incluyen en los
resultados. Las propiedades de salida sin coincidencias
contienen valores NULL.
leftanti Los registros del lado izquierdo que no tienen coincidencias

en el derecho se incluyen en los resultados. La tabla de
resultados tiene solo las columnas de la tabla izquierda.
leftsemi Los registros del lado izquierdo que tienen coincidencias en

el derecho se incluyen en los resultados. La tabla de
resultados tiene solo las columnas de la tabla izquierda.
Tenga en cuenta los siguientes puntos para obtener un rendimiento óptimo:
Utilice un filtro de tiempo en cada tabla para reducir los registros que se deben evaluar para la combinación.
Use los elementos where y project para reducir el número de filas y columnas en las tablas de entrada
antes de la combinación.
Si una tabla siempre es menor que la otra, úsela como lado izquierdo de la combinación.
Pasos siguientes
Consulte otras lecciones para usar consultas de registro de Azure Monitor:
Gráficos
Trabajo con JSON y estructuras de datos en
consultas de registro de Azure Monitor
NOTE
Antes de realizar esta lección, debe seguir los pasos de Introducción a Log Analytics de Azure Monitor e Introducción a las
consultas de registro de Azure Monitor.
NOTE
Los objetos anidados son objetos que contienen otros objetos en una matriz o un mapa de pares clave-valor.
Estos objetos se representan como cadenas JSON. En este artículo se describe cómo se usa JSON para recuperar
datos y analizar objetos anidados.
Trabajo con cadenas JSON

Use extractjson para acceder a un elemento JSON específico en una ruta de acceso conocida. Esta función
requiere una expresión de ruta de acceso que use las siguientes convenciones.
$ para hacer referencia a la carpeta raíz
Use la notación de corchetes o puntos para hacer referencia a los índices y elementos, tal como se muestra en
los ejemplos siguientes.
Use corchetes para los índices y puntos para separar los elementos:
let hosts_report='{"hosts": [{"location":"North_DC", "status":"running", "rate":5},{"location":"South_DC",

"status":"stopped", "rate":3}]}';
print hosts_report
| extend status = extractjson("$.hosts[0].status", hosts_report)
Este es el mismo resultado usando solo la notación de corchetes:
let hosts_report='{"hosts": [{"location":"North_DC", "status":"running", "rate":5},{"location":"South_DC",

"status":"stopped", "rate":3}]}';
print hosts_report
| extend status = extractjson("$['hosts'][0]['status']", hosts_report)
Si hay solo un elemento, puede usar únicamente la notación de puntos:
let hosts_report=dynamic({"location":"North_DC", "status":"running", "rate":5});

print hosts_report
| extend status = hosts_report.status
Trabajar con objetos
parsejson
Para acceder a varios elementos en la estructura JSON, es más fácil acceder como un objeto dinámico. Use
parsejson para convertir los datos de texto en un objeto dinámico. Después de la conversión en un tipo
dinámico, se pueden usar funciones adicionales para analizar los datos.
let hosts_object = parsejson('{"hosts": [{"location":"North_DC", "status":"running", "rate":5},

{"location":"South_DC", "status":"stopped", "rate":3}]}');
print hosts_object
| extend status0=hosts_object.hosts[0].status, rate1=hosts_object.hosts[1].rate
arraylength
Use arraylength para contar el número de elementos en una matriz:

print hosts_object
| extend hosts_num=arraylength(hosts_object.hosts)
mvexpand
Use mvexpand para dividir las propiedades de un objeto en filas independientes.

print hosts_object
| mvexpand hosts_object.hosts[0]
buildschema
Use buildschema para obtener el esquema que admite todos los valores de un objeto:

print hosts_object
| summarize buildschema(hosts_object)
El resultado es un esquema en formato JSON:

{
"hosts":
{
"indexer":
{
"location": "string",
"rate": "int",
"status": "string"
}
}
}
Esta salida describe los nombres de los campos del objeto y sus tipos de datos coincidentes.
Los objetos anidados pueden tener esquemas diferentes, como en el ejemplo siguiente:

{"status":"stopped", "rate":"3", "range":100}]}');
print hosts_object
| summarize buildschema(hosts_object)
Pasos siguientes
Consulte otras lecciones de uso de consultas de registro en Azure Monitor:
Combinaciones
Gráficos
Escritura de consultas avanzadas en Azure Monitor
NOTE
Debe completar Introducción a los análisis de registros de Azure Monitor e Introducción a las consultas de registros de
Azure Monitor antes de completar esta lección.
NOTE
Reutilización de código con let

Use el elemento let para asignar los resultados a una variable y hacer referencia a ella más adelante en la
consulta:
// get all events that have level 2 (indicates warning level)

let warning_events=
Event
| where EventLevel == 2;
// count the number of warning events per computer
warning_events
| summarize count() by Computer
También puede asignar valores constantes a variables. Esto es compatible con un método para configurar los
parámetros para los campos que necesite cambiar cada vez que ejecute la consulta. Modifique los parámetros
según sea necesario. Por ejemplo, para calcular el espacio libre en disco y la memoria libre (en percentiles), en un
período de tiempo determinado:
let startDate = datetime(2018-08-01T12:55:02);

let endDate = datetime(2018-08-02T13:21:35);
let FreeDiskSpace =
Perf
| where TimeGenerated between (startDate .. endDate)
| where ObjectName=="Logical Disk" and CounterName=="Free Megabytes"
| summarize percentiles(CounterValue, 50, 75, 90, 99);
let FreeMemory =
Perf
| where TimeGenerated between (startDate .. endDate)
| where ObjectName=="Memory" and CounterName=="Available MBytes Memory"
| summarize percentiles(CounterValue, 50, 75, 90, 99);
union FreeDiskSpace, FreeMemory
Facilita el cambio de la hora de inicio y finalización la próxima vez que ejecute la consulta.
Funciones y parámetros locales
Use instrucciones let para crear funciones que puedan usarse en la misma consulta. Por ejemplo, defina una
función que tome un campo de fecha y hora (en formato UTC) y lo convierta en un formato estándar de Estados
Unidos.
let utc_to_us_date_format = (t:datetime)
{
strcat(getmonth(t), "/", dayofmonth(t),"/", getyear(t), " ",
bin((t-1h)%12h+1h,1s), iff(t%24h<12h, "AM", "PM"))
};
Event
| extend USTimeGenerated = utc_to_us_date_format(TimeGenerated)
| project TimeGenerated, USTimeGenerated, Source, Computer, EventLevel, EventData
Print
La función print devolverá una tabla con una sola columna y una sola fila, que muestra el resultado de un
cálculo. Se suele usar en los casos en los que es necesario un cálculo simple. Por ejemplo, para buscar la hora
actual en la hora estándar del Pacífico y agregar una columna con EST:
print nowPst = now()-8h

| extend nowEst = nowPst+3h
Datatable
La función datatable permite definir un conjunto de datos. Se proporciona un esquema y un conjunto de
valores y, a continuación, se canaliza la tabla a cualquier otro elemento de consulta. Por ejemplo, para crear una
tabla de utilización de RAM y calcular su valor promedio por hora:
datatable (TimeGenerated: datetime, usage_percent: double)

[
"2018-06-02T15:15:46.3418323Z", 15.5,
"2018-06-02T15:45:43.1561235Z", 20.2,
"2018-06-02T16:16:49.2354895Z", 17.3,
"2018-06-02T16:46:44.9813459Z", 45.7,
"2018-06-02T17:15:41.7895423Z", 10.9,
"2018-06-02T17:44:23.9813459Z", 24.7,
"2018-06-02T18:14:59.7283023Z", 22.3,
"2018-06-02T18:45:12.1895483Z", 25.4
]
| summarize avg(usage_percent) by bin(TimeGenerated, 1h)
Las construcciones de Datatable también son muy útiles al crear una tabla de búsqueda. Por ejemplo, para
asignar datos de tabla, como los id. de eventos, de la tabla SecurityEvent a tipos de evento enumerados en otro
lugar, cree una tabla de búsqueda con los tipos de eventos mediante la función datatable y combine esta
datatable con los datos de SecurityEvent:
let eventCodes = datatable (EventID: int, EventType:string)
[
4672, "Access",
4799, "Access management",
5059, "Key operation",
4648, "A logon was attempted using explicit credentials",
4662, "Other",
4904, "Security event management",
4905, "Security event management",
];
SecurityEvent
eventCodes
) on EventID
| project TimeGenerated, Account, AccountType, Computer, EventType
Pasos siguientes
Combinaciones
Gráficos
Creación de gráficos y diagramas a partir de
consultas de Azure Monitor
NOTE
Debe completar Advanced aggregations in Azure Monitor log queries (Agregaciones avanzadas en consultas de registro
de Azure Monitor) antes de completar esta lección.
NOTE
En este artículo, se describen las distintas visualizaciones en Azure Monitor para mostrar los datos de registro de
distintas maneras.
Crear gráficos de los resultados

Comience por revisar cuántos equipos hay por sistema operativo, durante la última hora:
Heartbeat
| summarize count(Computer) by OSType
De forma predeterminada, los resultados se muestran como una tabla:
Para obtener una mejor perspectiva, seleccione Gráfico y elija la opción Circular para visualizar los resultados:
Gráficos de tiempo
Muestran los percentiles 50 y 95 promedio del tiempo de procesador en intervalos de 1 hora. La consulta genera
varias series y puede seleccionar qué series mostrar en el gráfico de tiempo:
Perf
| where CounterName == "% Processor Time"
| summarize avg(CounterValue), percentiles(CounterValue, 50, 95) by bin(TimeGenerated, 1h)
Seleccione la opción de visualización de gráfico de líneas :
Línea de referencia
Una línea de referencia puede ayudarlo a identificar fácilmente si la métrica superó un umbral específico. Para
agregar una línea a un gráfico, amplíe el conjunto de datos con una columna de constante:
Perf
| summarize avg(CounterValue), percentiles(CounterValue, 50, 95) by bin(TimeGenerated, 1h)
| extend Threshold = 20
Varias dimensiones
Varias expresiones en la cláusula by de summarize crean varias filas en los resultados, una para cada
combinación de valores.
SecurityEvent
| summarize count() by tostring(EventID), AccountType, bin(TimeGenerated, 1h)
Cuando ve los resultados como un gráfico, usa la primera columna de la cláusula by . En el ejemplo siguiente se
muestra un gráfico de columnas apiladas con el EventID. Las dimensiones deben ser del tipo string , por lo que
en este ejemplo, EventID se convierte en cadena.
Para cambiar, seleccione la lista desplegable con el nombre de la columna.

Pasos siguientes
Combinaciones
Consultas de búsqueda en registros de Azure
Monitor
Las consultas de registro de Azure Monitor pueden comenzar por un nombre de tabla o un comando de búsqueda.
Este tutorial trata las consultas de búsqueda. Cada método tiene sus ventajas.
Las consultas basadas en tablas comienzan por definir el ámbito de la consulta y, por tanto, tienden a ser más
eficaces que las de búsqueda. Las consultas de búsqueda son menos estructuradas, lo que las convierte en la mejor
opción cuando se busca un valor específico en columnas o tablas. Con search se pueden examinar todas las
columnas de una tabla determinada o en todas las tablas para encontrar el valor especificado. La cantidad de datos
que se procesa puede ser enorme, por lo que estas consultas podrían tardar más en completarse y devolver
conjuntos de resultados muy grandes.
Búsqueda de un término
El comando search normalmente se usa para buscar un término específico. En el ejemplo siguiente se examinan
todas las columnas de todas las tablas en busca del término "error":
search "error"
| take 100
Aunque sean fáciles de usar, las consultas sin ámbito como la anterior no son eficaces y pueden devolver
numerosos resultados irrelevantes. Lo más recomendable sería buscar en la tabla pertinente o incluso en una
columna específica.
Ámbito de tabla
Para buscar un término en una tabla específica, agregue in (table-name) justo después del operador search :
search in (Event) "error"

| take 100
o en varias tablas:
search in (Event, SecurityEvent) "error"

| take 100
Ámbito de tabla y columna

De forma predeterminada, search evalúa todas las columnas del conjunto de datos. Para buscar solo una columna
específica (origen con nombre en el ejemplo siguiente), use esta sintaxis:
search in (Event) Source:"error"

| take 100
TIP
Si usa == en lugar de : , los resultados incluirían los registros en los que la columna Source tienen el valor exacto "error" y
únicamente eso. El uso de ":" incluirá los registros donde Source contenga valores como "código de error 404" o "Error".
Diferenciación entre mayúsculas y minúsculas

De forma predeterminada, en la búsqueda de términos no se distingue entre mayúsculas y minúsculas, por lo que
al buscar "dns" se pueden producir resultados como "DNS", "dns" o "Dns". Para que en la búsqueda se distinga
entre mayúsculas y minúsculas, use la opción kind :
search kind=case_sensitive in (Event) "DNS"

| take 100
Uso de caracteres comodín

El comando search admite caracteres comodín, al principio, al final o en el medio de un término.
Para buscar términos que comienzan por "win":
search in (Event) "win*"

| take 100
Para buscar términos que terminan en ".com":
search in (Event) "*.com"

| take 100
Para buscar términos que contienen "www":
search in (Event) "*www*"

| take 100
Para buscar términos que comienzan por "corp" y terminan en ".com", por ejemplo, "corp.mydomain.com":
search in (Event) "corp*.com"

| take 100
También puede obtener todo el contenido de una tabla utilizando solo un carácter comodín: search in (Event) * ,
pero que sería lo mismo que escribir simplemente Event .
TIP
Aunque puede usar search * para obtener todas las columnas de todas las tablas, se recomienda siempre dirigir las
consultas a tablas específicas. Las consultas generales pueden tardar en completarse y puede que se devuelvan demasiados
resultados.
Agregue and / or a las consultas de búsqueda

Use and para buscar los registros que contengan varios términos:
search in (Event) "error" and "register"
| take 100
Use or para obtener los registros que contengan al menos uno de los términos:
search in (Event) "error" or "register"

| take 100
Si tiene varias condiciones de búsqueda, puede combinarlas en la misma consulta mediante paréntesis:
search in (Event) "error" and ("register" or "marshal*")

| take 100
Los resultados de este ejemplo serían los registros que contienen el término "error" y también "register" o algo que
empieza por "marshal".
Canalización de consultas de búsqueda

Al igual que cualquier otro comando, search se puede canalizar para filtrar, ordenar y agregar los resultados de la
búsqueda. Por ejemplo, para obtener el número de registros Event que contienen "win":
search in (Event) "win"

| count
Pasos siguientes
Consulte más tutoriales en el sitio del lenguaje de consulta de Kusto.
Hoja de referencia rápida de consultas de registro de
SQL en Azure Monitor
La tabla siguiente sirve de ayuda para que los usuarios que están familiarizados con SQL obtengan información
sobre el lenguaje de consulta de Kusto para escribir consultas de registro en Azure Monitor. Eche un vistazo al
comando T-SQL para resolver escenarios comunes y su equivalente en una consulta de registro de Azure Monitor.
De SQL a Azure Monitor

C O N SULTA DE REGIST RO DE A Z URE
DESC RIP C IÓ N C O N SULTA SQ L M O N ITO R
Seleccionar todos los datos de una SELECT * FROM dependencies dependencies

tabla
Selección de columnas específicas en SELECT name, resultCode FROM dependencies

una tabla dependencies | project name, resultCode
Seleccionar 100 registros de una tabla SELECT TOP 100 * FROM dependencies
dependencies | take 100
Evaluación de un valor nulo SELECT * FROM dependencies WHERE dependencies

resultCode IS NOT NULL | where isnotnull(resultCode)
Comparación de cadenas: igualdad SELECT * FROM dependencies WHERE dependencies

name = "abcde" | where name == "abcde"
Comparación de cadenas: subcadena SELECT * FROM dependencies WHERE dependencies

name like "%bcd%" | where name contains "bcd"
Comparación de cadenas: carácter SELECT * FROM dependencies WHERE dependencies

comodín name like "abc%" | where name startswith "abc"
Comparación de fechas: último día SELECT * FROM dependencies WHERE dependencies

timestamp > getdate()-1 | where timestamp > ago(1d)
Comparación de fechas: intervalo de SELECT * FROM dependencies WHERE dependencies

fechas timestamp BETWEEN '2016-10-01' | where timestamp between
AND '2016-11-01' (datetime(2016-10-01) ..
datetime(2016-10-01))
Comparación de valores booleanos SELECT * FROM dependencies WHERE dependencies

!(success) | where success == "False"
Sort SELECT name, timestamp FROM dependencies

dependencies ORDER BY timestamp | order by timestamp asc
asc
Distinct SELECT DISTINCT name, type FROM dependencies

dependencies | summarize by name, type
C O N SULTA DE REGIST RO DE A Z URE
DESC RIP C IÓ N C O N SULTA SQ L M O N ITO R
Agrupación, agregación SELECT name, AVG(duration) FROM dependencies

dependencies GROUP BY name | summarize avg(duration) by name
Alias de columna, extensión SELECT operation_Name as Name, dependencies

AVG(duration) as AvgD FROM | summarize AvgD=avg(duration) by
dependencies GROUP BY name operation_Name
| project Name=operation_Name,
AvgD
Primeros n registros por medida SELECT TOP 100 name, COUNT(*) as dependencies
Count FROM dependencies GROUP BY | summarize Count=count() by name
name ORDER BY Count asc | top 100 by Count asc
Union SELECT * FROM dependencies UNION union dependencies, exceptions

SELECT * FROM exceptions
Unión: con condiciones SELECT * FROM dependencies WHERE dependencies

value > 4 UNION SELECT * FROM | where value > 4
exceptions WHERE value < 5 | union (exceptions
| where value < 5)
Join SELECT * FROM dependencies JOIN dependencies

exceptions ON | join (exceptions) on
dependencies.operation_Id = operation_Id == operation_Id
exceptions.operation_Id
Pasos siguientes
Consulte las lecciones sobre la escritura de consultas de registro en Azure Monitor.
Consulta de registro de Splunk en Azure Monitor
Este artículo sirve de ayuda para que los usuarios que están familiarizados con Splunk obtengan información sobre el
lenguaje de consulta de Kusto para escribir consultas de registro en Azure Monitor. Se realizan comparaciones directas
entre ambos para conocer las principales diferencias y similitudes donde puede aprovechar los conocimientos que
posee.
Estructura y conceptos
En la tabla siguiente se comparan los conceptos y las estructuras de datos en los registros de Splunk y Azure Monitor.
C O N C EP TO SP L UN K A Z URE M O N ITO R C O M EN TA RIO
Unidad de implementación cluster cluster Azure Monitor permite

consultas arbitrarias entre
clústeres. Splunk no lo
permite.
Memorias caché de datos cubos Directivas de retención y Controla el período y el nivel

almacenamiento en caché de almacenamiento en caché
de los datos. Este valor afecta
directamente al rendimiento
de las consultas y al costo de
la implementación.
Partición lógica de los datos índice database Permite la separación lógica

de los datos. Ambas
implementaciones permiten
uniones y la combinación de
estas particiones.
Metadatos de eventos N/D table Splunk no tiene el concepto

estructurados que se expone al lenguaje de
búsqueda de metadatos de
eventos. Los registros de
Azure Monitor siguen el
concepto de tabla, con
columnas. Cada instancia de
un evento se asigna a una fila.
Registro de datos event fila Solo cambio de terminología.
Atributo de registro de datos campo columna En Azure Monitor, se

predefine como parte de la
estructura de la tabla. En
Splunk, cada evento tiene su
propio conjunto de campos.
C O N C EP TO SP L UN K A Z URE M O N ITO R C O M EN TA RIO
Tipos tipo de datos tipo de datos Los tipos de datos de Azure

Monitor son más explícitos,
ya que se establecen en las
columnas. Ambos tienen la
capacidad de trabajar
dinámicamente con tipos de
datos y con un conjunto más
o menos equivalente de tipos
de datos, lo que incluye la
compatibilidad con JSON.
Búsqueda y consulta búsqueda Query Los conceptos son

esencialmente los mismos en
Azure Monitor y Splunk.
Tiempo de ingesta de eventos Hora del sistema ingestion_time() En Splunk, cada evento
obtiene una marca de tiempo
del sistema del tiempo en que
el evento se indexó. En Azure
Monitor, se puede definir una
directiva denominada
ingestion_time que expone
una columna del sistema a la
que se puede hacer referencia
a través de la función
ingestion_time().
Functions
En la tabla siguiente se especifican las funciones de Azure Monitor que son equivalentes a funciones de Splunk.
SP L UN K A Z URE M O N ITO R C O M EN TA RIO
strcat strcat() (1)
split split() (1)
if iff() (1)
tonumber todouble() (1)

tolong()
toint()
upper toupper() (1)

lower tolower()
replace replace() (1)

Tenga también en cuenta que aunque
replace() usa tres parámetros en
ambos productos, los parámetros son
diferentes.
substr substring() (1)

Tenga en cuenta también que Splunk
utiliza índices con base uno. Azure
Monitor usa índices con base cero.
SP L UN K A Z URE M O N ITO R C O M EN TA RIO
tolower tolower() (1)
toupper toupper() (1)
match matches regex (2)
regex matches regex En Splunk, regex es un operador. En

Azure Monitor, es un operador relacional.
searchmatch == En Splunk, searchmatch permite buscar

la cadena exacta.
random rand() La función de Splunk devuelve un

rand(n) número entre cero y 231 -1. Azure
Monitor devuelve un número entre 0,0 y
1,0, o si se ha proporcionado un
parámetro, entre 0 y n-1.
ahora now() (1)
relative_time totimespan() (1)

En Azure Monitor, el equivalente de
Splunk de relative_time (datetimeVal,
offsetVal) es datetimeVal +
totimespan(offsetVal).
Por ejemplo,
search | eval
n=relative_time(now(), "-1d@d")
se convierte en
... | extend myTime = now() -
totimespan("1d")
.
(1) En Splunk, se invoca la función con el operador eval . En Azure Monitor, se usa como parte de extend o project .
(2) En Splunk, se invoca la función con el operador eval . En Azure Monitor, se puede usar con el operador where .
Operadores
En las secciones siguientes se proporcionan ejemplos del uso de distintos operadores entre Splunk y Azure Monitor.
NOTE
Para el ejemplo siguiente, el campo de Splunk rule se asigna a una tabla de Azure Monitor y la marca de tiempo predeterminada
de Splunk se asigna a la columna ingestion_time() de Logs Analytics.
Search
En Splunk se puede omitir la palabra clave search y especifique una cadena sin comillas. En Azure Monitor todas las
consultas deben comenzar por find , una cadena sin comillas es un nombre de columna y el valor de búsqueda debe
ser una cadena entre comillas.
O P ERATO R E JEM P LO
Splunk search search Session.Id="c8894ffd-e684-

43c9-9125-42adc25cd3fc" earliest=-
24h
Azure Monitor find find Session.Id=="c8894ffd-e684-

43c9-9125-42adc25cd3fc" and
ingestion_time()> ago(24h)
Filter
Las consultas de registro de Azure Monitor comienzan en un conjunto de resultados tabulares donde se establece el
filtro. En Splunk, el filtrado es la operación predeterminada del índice actual. En Splunk también se puede usar el
operador where , pero no es aconsejable.
Splunk search Event.Rule="330009.2"

Session.Id="c8894ffd-e684-43c9-
9125-42adc25cd3fc" _indextime>-24h
Azure Monitor where Office_Hub_OHubBGTaskError

| where Session_Id == "c8894ffd-
e684-43c9-9125-42adc25cd3fc" and
ingestion_time() > ago(24h)
Obtención de n eventos o filas para su inspección

Las consultas de registro de Azure Monitor también admiten take como alias para limit . En Splunk, si los
resultados están ordenados, head devolverá los primeros n resultados. En Azure Monitor, el límite no está ordenado,
pero devuelve las n primeras filas que se encuentran.
Splunk head Event.Rule=330009.2

| head 100
Azure Monitor limit Office_Hub_OHubBGTaskError

| limit 100
Obtención de los n primeros eventos o filas ordenados por una columna o campo
Para los resultados inferiores, en Splunk se usa tail . En Azure Monitor se puede especificar la dirección de
ordenación con asc .
Splunk head Event.Rule="330009.2"

| sort Event.Sequence
| head 20
Azure Monitor top Office_Hub_OHubBGTaskError

| top 20 by Event_Sequence
Extensión del conjunto de resultados con nuevos campos o columnas

Splunk también tiene una función eval , que no se debe comparar con el operador eval . Tanto el operador eval de
Splunk como el operador extend de Azure Monitor solo admiten operadores aritméticos y funciones escalares.
Splunk eval Event.Rule=330009.2

| eval state= if(Data.Exception =
"0", "success", "error")
Azure Monitor extend Office_Hub_OHubBGTaskError

| extend state =
iif(Data_Exception == 0,"success"
,"error")
Cambiar nombre
Azure Monitor usa el operador project-rename para cambiar el nombre de un campo. project-rename permite a la
consulta aprovechar los índices pregenerados para un campo. Splunk tiene el operador rename para hacer lo mismo.
Splunk rename Event.Rule=330009.2

| rename Date.Exception as
execption
Azure Monitor project-rename Office_Hub_OHubBGTaskError

| project-rename exception =
Date_Exception
Formato de resultados o proyección

Splunk no parece tener un operador similar a project-away . Puede usar la interfaz de usuario para filtrar campos y
eliminarlos.
Splunk table Event.Rule=330009.2

| table rule, state
Azure Monitor project Office_Hub_OHubBGTaskError

project-away | project exception, state
Agregación
Consulte Agregaciones en consultas de registros de Azure Monitor para conocer las distintas funciones de agregación.
Splunk stats search (Rule=120502.*)

| stats count by OSEnv, Audience
Azure Monitor summarize Office_Hub_OHubBGTaskError

| summarize count() by
App_Platform, Release_Audience
Join
En Splunk, la combinación tiene limitaciones importantes. La subconsulta tiene un límite de 10 000 resultados
(definido en el archivo de configuración de implementación), y existe un número limitado de tipos de combinación.
Splunk join Event.Rule=120103* | stats by

Client.Id, Data.Alias | join
Client.Id max=0 [search earliest=-
24h Event.Rule="150310.0"
Data.Hresult=-2147221040]
Azure Monitor join cluster("OAriaPPT").database("Office

PowerPoint").Office_PowerPoint_PPT_Exceptions
| where Data_Hresult== -2147221040
| join kind = inner
(Office_System_SystemHealthMetadata
| summarize by Client_Id, Data_Alias)on
Client_Id
Sort
En Splunk, para ordenar de forma ascendente es preciso usar el operador reverse . Azure Monitor también permite
definir dónde se colocan valores NULL, al principio o al final.
Splunk sor t Event.Rule=120103

| sort Data.Hresult
| reverse
Azure Monitor order by Office_Hub_OHubBGTaskError

| order by Data_Hresult, desc
Expansión de varios valores

Se trata de un operador similar en Splunk y Azure Monitor.
Splunk mvexpand mvexpand foo
Azure Monitor mvexpand mvexpand foo
Facetas de resultados, campos interesantes

En Log Analytics en Azure Portal, solo se expone la primera columna. Todas las columnas están disponibles a través de
la API.
Splunk fields Event.Rule=330009.2

| fields App.Version, App.Platform
Azure Monitor facets Office_Excel_BI_PivotTableCreate

| facet by App_Branch, App_Version
Desduplicación
Puede usar summarize arg_min() en su lugar para invertir el orden en que se elige el registro.
Splunk dedup Event.Rule=330009.2

| dedup device_id sortby -
batterylife
Azure Monitor summarize arg_max() Office_Excel_BI_PivotTableCreate

| summarize arg_max(batterylife,
*) by device_id
Pasos siguientes
Repase una lección sobre la escritura de consultas de registro en Azure Monitor.
Consulta de registros entre recursos en Azure
Monitor
IMPORTANT
Si usa un recurso de Application Insights basado en el área de trabajo, la telemetría se almacena en un área de trabajo
de Log Analytics con todos los demás datos del registro. Use la expresión log() para escribir una consulta que incluya la
aplicación en varias áreas de trabajo. Si tiene varias aplicaciones en la misma área de trabajo, no se necesita realizar una
consulta entre áreas de trabajo.
Anteriormente, con Azure Monitor, solo podía analizar datos desde dentro del área de trabajo actual, lo que
limitaba su capacidad de consulta a través de varias áreas de trabajo definidas en la suscripción. Además, solo
puede buscar los elementos de telemetría recopilados de la aplicación basada en web con Application
Insights directamente en Application Insights o desde Visual Studio. Esto también convirtió en un desafío
analizar de manera nativa los datos operativos y de aplicación en conjunto.
Ahora puede consultar no solo a través de varias áreas de trabajo de Log Analytics, sino también datos desde
una aplicación específica de Application Insights del mismo grupo de recursos, otro grupo de recursos u otra
suscripción. Gracias a esto se consigue una vista total del sistema de datos. Solo puede realizar estos tipos de
consultas en Log Analytics.
Límites de la consulta entre recursos

El número de recursos de Application Insights y de áreas de trabajo de Log Analytics que se pueden incluir
en una sola consulta se limita a 100.
No se admite la consulta entre recursos en el Diseñador de vistas. Puede crear una consulta en Log
Analytics y anclarla al panel de Azure para visualizar una consulta de registro.
La consulta entre recursos en las alertas de registro se admite en la nueva API scheduledQueryRules. De
forma predeterminada, Azure Monitor usa la API de alerta heredada de Log Analytics para crear nuevas
reglas de alerta de registro desde Azure Portal, a menos que cambie de API de alerta de registro heredada.
Después del cambio, la nueva API se convierte en la predeterminada para las nuevas reglas de alerta en
Azure Portal y le permite crear reglas de alertas de registro de consulta entre recursos. Puede crear reglas
de alertas de registro de consulta entre recursos sin realizar el cambio mediante la plantilla de Azure
Resource Manager para la API scheduledQueryRules; sin embargo, esta regla de alertas se puede
administrar mediante la API scheduledQueryRules y no desde Azure Portal.
Consultas a través de áreas de trabajo de Log Analytics y desde

Para hacer referencia a otra área de trabajo en la consulta, use el identificador del área de trabajo, y, para una
aplicación de Application Insights, use el identificador de la aplicación.
Identificación de los recursos del área de trabajo
En los ejemplos siguientes se muestran consultas en las áreas de trabajo de Log Analytics que devuelven
recuentos de registros resumidos desde la tabla Update en un área de trabajo denominada contosoretail-it.
La identificación de un área de trabajo se puede lograr de varias maneras:
Nombre del recurso:- es un nombre legible del área de trabajo; a veces se denomina nombre del
componente.
workspace("contosoretail-it").Update | count
Nombre completo: es el nombre completo del área de trabajo, compuesto por el nombre de la
suscripción, el grupo de recursos y el nombre del componente con este formato:
nombreSuscripción/grupoDeRecursos/nombreDeComponente.
workspace('contoso/contosoretail/contosoretail-it').Update | count
NOTE
Dado que los nombres de suscripción de Azure no son únicos, este identificador podría ser ambiguo.
Identificador del área de trabajo: es el identificador único e inmutable asignado a cada área de trabajo
que se representa como identificador único global (GUID).
workspace("b459b4u5-912x-46d5-9cb1-p43069212nb4").Update | count
Identificador de recurso de Azure: identidad única definida por Azure del área de trabajo. Se usa
cuando el nombre del recurso es ambiguo. Para las áreas de trabajo, el formato es:
/subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights
/workspaces/componentName.
Por ejemplo:
workspace("/subscriptions/e427519-5645-8x4e-1v67-
3b84b59a1985/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/cont
osoretail-it").Update | count
Identificación de una aplicación

Los ejemplos siguientes devuelven un recuento resumido de las solicitudes realizadas en una aplicación
denominada fabrikamapp de Application Insights.
Una aplicación de Application Insights se puede identificar con la expresión app(Identifier) . El argumento
Identifier especifica la aplicación que usa uno de los siguientes:
Nombre del recurso: es el nombre legible de la aplicación; a veces se denomina nombre del
componente.
app("fabrikamapp")
NOTE
En la identificación de una aplicación por nombre se da por supuesto que es único en todas las suscripciones
accesibles. Si tiene varias aplicaciones con el nombre especificado, la consulta produce un error debido a la
ambigüedad. En este caso debe usar uno de los otros identificadores.
Nombre completo: es el nombre completo de la aplicación, compuesto por el nombre de la

suscripción, el grupo de recursos y el nombre del componente con este formato:
nombreSuscripción/grupoDeRecursos/nombreDeComponente.
app("AI-Prototype/Fabrikam/fabrikamapp").requests | count
NOTE
Dado que los nombres de suscripción de Azure no son únicos, este identificador podría ser ambiguo.
ID: el identificador único global de la aplicación.

app("b459b4f6-912x-46d5-9cb1-b43069212ab4").requests | count
Identificador de recurso de Azure: identidad única definida por Azure de la aplicación. Se usa cuando el
nombre del recurso es ambiguo. El formato es:
/subscriptions/IdSuscripción/resourcegroups/grupoDeRecursos/providers/microsoft.OperationalInsig
hts/components/nombreDeComponente.
Por ejemplo:
app("/subscriptions/b459b4f6-912x-46d5-9cb1-
b43069212ab4/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").request
s | count
Realizar una consulta en varios recursos

Puede consultar varios recursos desde cualquiera de las instancias de recursos; estas pueden ser áreas de
trabajo y aplicaciones combinadas.
Ejemplo de consulta en dos áreas de trabajo:
union Update, workspace("contosoretail-it").Update, workspace("b459b4u5-912x-46d5-9cb1-

p43069212nb4").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Uso de una consulta entre recursos para varios recursos

Al usar las consultas entre recursos para correlacionar datos procedentes de varios recursos del área de
trabajo de Log Analytics y de Application Insights, la consulta puede ser compleja y difícil de mantener. Debe
aprovechar las funciones de las consultas de registro de Azure Monitor para separar la lógica de consulta del
ámbito de los recursos de la consulta, lo que simplifica la estructura de la consulta. En el ejemplo siguiente se
muestra cómo puede supervisar varios recursos de Application Insights y visualizar el número de solicitudes
erróneas por nombre de la aplicación.
Cree una consulta similar a la siguiente que haga referencia al ámbito de recursos de Application Insights. El
comando withsource= SourceApp agrega una columna que designa el nombre de la aplicación que envió el
registro. Guarde la consulta como función con el alias applicationsScoping.
// crossResource function that scopes my Application Insights resources

union withsource= SourceApp
app('Contoso-app1').requests,
app('Contoso-app5').requests
Ahora puede usar esta función en una consulta entre recursos similar a la siguiente. El alias de la función
applicationsScoping devuelve la unión de la tabla de solicitudes de todas las aplicaciones definidas. A
continuación, la consulta filtra las solicitudes erróneas y visualiza las tendencias por aplicación. El operador
parse es opcional en este ejemplo. Extrae el nombre de la aplicación de la propiedad SourceApp.
applicationsScoping
| where timestamp > ago(12h)
| where success == 'False'
| parse SourceApp with * '(' applicationName ')' *
| summarize count() by applicationName, bin(timestamp, 1h)
| render timechart
NOTE
Este método no se puede usar con alertas de registro porque la validación de acceso de los recursos para las regla de
alertas (incluidas las áreas de trabajo y las aplicaciones) se realiza en el momento de la creación de la alerta. No se
admite la adición de nuevos recursos a la función después de crear la alerta. Si prefiere usar la función para el ámbito
de los recursos en las alertas de registro, debe editar la regla de alertas en el portal o usar una plantilla de Resource
Manager para actualizar los recursos de ámbito. También puede incluir la lista de recursos en la consulta de alerta de
registro.
Pasos siguientes
Consulte Análisis de los datos de Log Analytics en Azure Monitor para obtener información general de las
consultas de registros y cómo se estructuran los datos del registro de Azure Monitor.
Consulte las consultas de registros de Azure Monitor para ver todos los recursos de las consultas de
Expresión app() de la consulta de Azure Monitor
La expresión app se usa en una consulta de Azure Monitor para recuperar datos de una aplicación de
Application Insights específica en el mismo grupo de recursos, en otro grupo de recursos o en otra suscripción.
Resulta útil para incluir datos de aplicación en una consulta de registros de Azure Monitor y para consultar datos
a través de varias aplicaciones en una consulta de Application Insights.
IMPORTANT
La expresión app() no se usa si se usa un recurso de Application Insights basado en el área de trabajo, ya que los datos de
registro se almacenan en un área de trabajo de Log Analytics. Use la expresión log() para escribir una consulta que incluya
la aplicación en varias áreas de trabajo. Si tiene varias aplicaciones en la misma área de trabajo, no se necesita realizar una
consulta entre áreas de trabajo.
Sintaxis
app( Identificador )
Argumentos
Identificador: Identifica la aplicación con uno de los formatos de la tabla siguiente.
IDEN T IF IC A DO R DESC RIP C IÓ N E JEM P LO
Nombre de recurso Nombre legible de la aplicación app("fabrikamapp")

(también conocido como "nombre del
componente")
Nombre completo Nombre completo de la aplicación en el app('AI-

formato siguiente: Prototype/Fabrikam/fabrikamapp')
"subscriptionName/resourceGroup/com
ponentName"
id GUID de la aplicación app("988ba129-363e-4415-8fe7-

8cbab5447518")
Id. de recurso de Azure Identificador del recurso de Azure app("/subscriptions/7293b69-db12-

44fc-9a66-
9c2005c3051d/resourcegroups/Fabrika
m/providers/microsoft.insights/compon
ents/fabrikamapp")
Notas
Debe tener acceso de lectura a la aplicación.
En la identificación de una aplicación por su nombre, se da por supuesto que este es único en todas las
suscripciones accesibles. Si tiene varias aplicaciones con el nombre especificado, la consulta producirá un
error debido a la ambigüedad. En este caso debe usar uno de los otros identificadores.
Utilice la expresión relacionada área de trabajo para hacer consultas entre áreas de trabajo de Log Analytics.
Actualmente, la expresión app() actualmente no se admite en la consulta de búsqueda cuando se usa Azure
Portal para crear un regla de alerta de búsqueda de registros personalizada, salvo que se use una aplicación
de Application Insights se usa como recurso para la regla de alertas.
Ejemplos
app("fabrikamapp").requests | count
app("AI-Prototype/Fabrikam/fabrikamapp").requests | count
app("b438b4f6-912a-46d5-9cb1-b44069212ab4").requests | count
app("/subscriptions/7293b69-db12-44fc-9a66-
9c2005c3051d/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count
union
(workspace("myworkspace").Heartbeat | where Computer contains "Con"),
(app("myapplication").requests | where cloud_RoleInstance contains "Con")
| count
union
(workspace("myworkspace").Heartbeat), (app("myapplication").requests)
| where TimeGenerated between(todatetime("2018-02-08 15:00:00") .. todatetime("2018-12-08 15:05:00"))
Pasos siguientes
Consulte la expresión workspace para hacer referencia al área de trabajo de Log Analytics.
Obtenga información sobre cómo se almacenan los datos de Azure Monitor.
Acceda a toda la documentación del lenguaje de consulta de Kusto.
Expresión workspace() en consultas de registro de
Azure Monitor
La expresión workspace se usa en una consulta de Azure Monitor para recuperar datos de un área de trabajo
específica en el mismo grupo de recursos, en otro grupo de recursos o en otra suscripción. Es útil para incluir
datos de registro en una consulta de Application Insights y para consultar datos a través de varias áreas de
trabajo en una consulta de registro.
Sintaxis
workspace( Identificador )
Argumentos
Identificador: identifica el área de trabajo mediante uno de los formatos de la tabla siguiente.
Nombre de recurso Nombre legible del área de trabajo workspace("contosoretail")

(también denominado "nombre del
componente")
Nombre completo Nombre completo del área de trabajo workspace("Contoso/ContosoResource

con el siguiente formato: /ContosoWorkspace")
"subscriptionName/resourceGroup/co
mponentName"
id GUID del área de trabajo workspace("b438b3f6-912a-46d5-

9db1-b42069242ab4")
Id. de recurso de Azure Identificador del recurso de Azure workspace("/subscriptions/e4227-645-

44e-9c67-
3b84b5982/resourcegroups/ContosoA
zureHQ/providers/Microsoft.Operation
alInsights/workspaces/contosoretail")
Notas
Debe tener acceso de lectura al área de trabajo.
Una expresión relacionada es app , que le permite realizar consultas en todas las aplicaciones de Application
Insights.
Ejemplos
workspace("contosoretail").Update | count
workspace("b438b4f6-912a-46d5-9cb1-b44069212ab4").Update | count
workspace("/subscriptions/e427267-5645-4c4e-9c67-
3b84b59a6982/resourcegroups/ContosoAzureHQ/providers/Microsoft.OperationalInsights/workspaces/contosoretail"
).Event | count
union
(workspace("myworkspace").Heartbeat | where Computer contains "Con"),
(app("myapplication").requests | where cloud_RoleInstance contains "Con")
| count
union
(workspace("myworkspace").Heartbeat), (app("myapplication").requests)
| where TimeGenerated between(todatetime("2018-02-08 15:00:00") .. todatetime("2018-12-08 15:05:00"))
Pasos siguientes
Consulte la expresión de aplicación para hacer referencia a una aplicación de Application Insights.
Obtenga información sobre cómo se almacenan los datos de Azure Monitor.
Expresión resource() en consultas de registro de Azure
Monitor
La expresión resource se usa en consulta de Azure Monitor con ámbito en un recurso para recuperar datos de
otros recursos.
Sintaxis
resource( Identificador )
Argumentos
Identificador: Identificador de recurso de un recurso.
Resource Incluye datos del recurso. resource("/subscriptions/xxxxxxx-xxxx-

xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresour
cegroup/providers/microsoft.compute/vi
rtualmachines/myvm")
Grupo de recursos o suscripción Incluye datos del recurso y todos los resource("/subscriptions/xxxxxxx-xxxx-
recursos que contiene. xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresour
cegroup)
Notas
Debe tener acceso de lectura al recurso.
Ejemplos
union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresourcegroup/providers/microsoft.compute/virtualmachines/myvm").Heartbeat) |
summarize count() by _ResourceId, TenantId
union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourcesgroups/myresourcegroup).Heartbeat) | summarize count() by _ResourceId, TenantId
Pasos siguientes
Consulte Ámbito e intervalo de tiempo de una consulta de registro en Log Analytics de Azure Monitor para
obtener información sobre un ámbito de consulta.
Unificación de varios recursos de Application Insights
de Azure Monitor
En este artículo se describe el proceso para consultar y ver todos los datos de registro de Application Insights en
un mismo lugar (incluso si pertenecen a suscripciones a Azure distintas) como reemplazo de Application Insights
Connector, que se encuentra en desuso. El número de recursos de Application Insights que se pueden incluir en
una sola consulta se limita a 100.
Enfoque recomendado para consultar varios recursos de Application

Insights
Enumerar varios recursos de Application Insights en una consulta puede ser pesado y difícil de mantener. En su
lugar, puede aprovechar la función para separar la lógica de consulta del ámbito de las aplicaciones.
En este ejemplo se muestra cómo puede supervisar varios recursos de Application Insights y visualizar el número
de solicitudes erróneas por nombre de la aplicación.
Cree una función mediante el operador de unión con la lista de aplicaciones y guarde la consulta como función con
el alias applicationsScoping en el área de trabajo.
Puede modificar las aplicaciones enumeradas en cualquier momento en el portal; para ello, vaya al explorador de
consultas en el área de trabajo y seleccione la función para editarla y guardarla, o use el cmdlet SavedSearch de
PowerShell.
NOTE
Este método no se puede usar con alertas de registro porque la validación de acceso de los recursos para las regla de alertas
(incluidas las áreas de trabajo y las aplicaciones) se realiza en el momento de la creación de la alerta. No se admite la adición
de nuevos recursos a la función después de crear la alerta. Si prefiere usar la función para el ámbito de los recursos en las
alertas de registro, debe editar la regla de alertas en el portal o usar una plantilla de Resource Manager para actualizar los
recursos de ámbito. También puede incluir la lista de recursos en la consulta de alerta de registro.
El comando withsource= SourceApp agrega una columna a los resultados, que designa la aplicación que envió el
registro. El operador de análisis es opcional en este ejemplo y se usa para extraer el nombre de la aplicación de la
propiedad SourceApp.
union withsource=SourceApp
app('Contoso-app5').requests
| parse SourceApp with * "('" applicationName "')" *
Ahora está listo para usar la función applicationsScoping en la consulta entre recursos:
applicationsScoping
| parse SourceApp with * '(' applicationName ')' *
| summarize count() by applicationName, bin(timestamp, 1h)
| render timechart
La consulta usa el esquema de Application Insights, aunque la consulta se ejecuta en el área de trabajo debido a
que la función applicationsScoping devuelve la estructura de datos de Application Insights. El alias de la función
devuelve la unión de las solicitudes de todas las aplicaciones definidas. A continuación, la consulta filtra las
solicitudes erróneas y visualiza las tendencias por aplicación.
NOTE
La consulta entre recursos en las alertas de registro se admite en la nueva API scheduledQueryRules. De forma
predeterminada, Azure Monitor usa la API de alerta heredada de Log Analytics para crear nuevas reglas de alerta de registro
desde Azure Portal, a menos que cambie de API de alerta de registro heredada. Después del cambio, la nueva API se
convierte en la predeterminada para las nuevas reglas de alerta en Azure Portal y le permite crear reglas de alertas de
registro de consulta entre recursos. Puede crear reglas de alertas de registro de consulta entre recursos sin realizar el cambio
mediante la plantilla de ARM de la API scheduledQueryRules; sin embargo, esta regla de alertas se puede administrar
mediante la API scheduledQueryRules y no desde Azure Portal.
Diferencias de esquema del área de trabajo de Log Analytics y

En la tabla siguiente se muestran las diferencias de esquema entre Log Analytics y Application Insights.
P RO P IEDA DES DEL Á REA DE T RA B A JO DE LO G A N A LY T IC S P RO P IEDA DES DE REC URSO S DE A P P L IC AT IO N IN SIGH T S
AnonUserId user_id
ApplicationId appId
ApplicationName appName
ApplicationTypeVersion application_Version
AvailabilityCount itemCount
AvailabilityDuration duration
AvailabilityMessage message
AvailabilityRunLocation ubicación
AvailabilityTestId id
AvailabilityTestName name
AvailabilityTimestamp timestamp
Browser client_browser
City client_city
ClientIP client_IP
Computer cloud_RoleInstance
Country client_CountryOrRegion
CustomEventCount itemCount
CustomEventDimensions customDimensions
CustomEventName name
DeviceModel client_Model
DeviceType client_Type
ExceptionCount itemCount
ExceptionHandledAt handledAt
ExceptionMessage message
ExceptionType type
OperationID operation_id
OperationName operation_Name
SO client_OS
PageViewCount itemCount
PageViewDuration duration
PageViewName name
ParentOperationID operation_Id
RequestCount itemCount
RequestDuration duration
RequestID id
RequestName name
RequestSuccess success
ResponseCode resultCode
Role cloud_RoleName
RoleInstance cloud_RoleInstance
SessionId session_Id
SourceSystem operation_SyntheticSource
TelemetryTYpe type
URL url
UserAccountId user_AccountId
Pasos siguientes
Use Búsqueda de registros para ver información detallada de las aplicaciones de Application Insights.
Consultas guardadas en Log Analytics de Azure
Monitor
Log Analytics ofrece conjuntos de consultas de ejemplo que puede ejecutar de forma independiente o usar como
punto de partida para consultas propias. En este artículo se describen las consultas de ejemplo y cómo usarlas.
Si no está familiarizado con Log Analytics o con el lenguaje de consulta KQL, las consultas de ejemplo son una
excelente manera de empezar. Pueden proporcionar conclusiones instantáneas sobre un recurso y constituyen
una manera cómoda de empezar a aprender y usar KQL, lo que reduce el tiempo que se tarda en empezar a usar
Log Analytics. Hemos recopilado y seleccionado más de 250 consultas de ejemplo diseñadas para proporcionar
un valor instantáneo y el número crece continuamente.
Consultas en contexto
La nueva experiencia filtra y sugiere consultas en contexto. Es decir, el sistema muestra de forma automática solo
las consultas pertinentes para el ámbito que haya seleccionado.
Para un solo recurso : las consultas se filtran según el tipo de recurso.
Para un grupo de recursos : las consultas se filtran según los recursos del grupo de recursos específico.
Para un área de trabajo : las consultas se filtran según las soluciones instaladas en el área de trabajo.
Este comportamiento es coherente para todos los ámbitos de Log Analytics. Si no ve una consulta de ejemplo
para el tipo de recurso que quiere, es posible que se deba a filtros locales. En una sección posterior se describe
cómo quitar el ámbito local para que pueda ver todas las consultas posibles.
TIP
Cuantos más recursos tenga en el ámbito, más tiempo tardará el portal en filtrar y mostrar el cuadro de diálogo de la
consulta de ejemplo.
Interfaz de usuario de la consulta de ejemplo

Puede obtener consultas de ejemplo de dos ubicaciones diferentes.
Cuadro de diálogo de la consulta de ejemplo
La primera vez que acceda a la experiencia de Log Analytics, se muestra de forma automática el cuadro de diálogo
Consultas de ejemplo. También se puede acceder si hace clic en la parte superior derecha de la pantalla en
Consultas de ejemplo .
El cuadro de diálogo de la consulta de ejemplo aparece como se muestra a continuación:

En la captura de pantalla anterior se muestra la pantalla de registros de una instancia de Azure Key Vault. Como se
ha mencionado antes en este artículo, las consultas se muestran en contexto. Como resultado, en la captura de
pantalla solo se muestran ejemplos relacionados con Key Vault. Si selecciona una suscripción completa, se
muestran las consultas de todos los tipos de recursos de esa suscripción.
Cada consulta de ejemplo se representa mediante una tarjeta. Puede examinar rápidamente las consultas para
encontrar lo que necesita. Puede ejecutar la consulta directamente desde el cuadro de diálogo o elegir cargarla en
el editor de consultas para ajustarla más.
Experiencia de la barra lateral
Se puede acceder a la misma funcionalidad de la experiencia del cuadro de diálogo desde el panel Consultas de la
barra lateral izquierda de Log Analytics. Puede mantener el mouse sobre el nombre de una consulta para obtener
su descripción y funciones adicionales.
Búsqueda y filtrado de consultas
Las opciones de esta sección están disponibles en la experiencia de consulta del cuadro de diálogo y la barra
lateral, pero con una interfaz de usuario ligeramente diferente.
Uso de favoritos
Puede agregar como favoritas las consultas que use con frecuencia para disponer de un acceso más rápido.
TIP
Recopilar y ver las consultas con posterioridad es una buena manera de empezar. Busque las consultas que necesita y haga
clic en la estrella situada junto a la consulta para agregarla a los favoritos. Si más adelante descubre que la consulta no le
resulta útil, puede quitarla de los favoritos.
Filtrar y Agrupar por

Aunque la experiencia del cuadro de diálogo de consulta filtra para mostrar solo las consultas con el contexto
correcto, puede optar por quitar el filtro y verlas todas.
Agrupar por
Para cambiar la agrupación de las consultas, haga clic en la lista desplegable Agrupar por:
El cuadro de diálogo admite la agrupación por:

Tipo de recurso : un recurso como se define en Azure, como una máquina virtual. Vea la Referencia de tabla
de Azure Monitor para obtener una asignación completa entra las tablas de registros de Azure Monitor y Log
Analytics, y el tipo de recurso.
Categoría : un tipo de información como Seguridad o Auditoría. Las categorías son idénticas a las que se
definen en el panel lateral Tablas. Para obtener una lista completa de las categorías, vea la referencia de tabla
de Azure Monitor.
Solución : una solución de Azure Monitor asociada a las consultas
Tema : el tema de la consulta de ejemplo, como Registros de actividad o Registros de aplicación. La propiedad
de tema es exclusiva de las consultas de ejemplo y puede diferir según el tipo de recurso específico.
Los valores de agrupación también actúan como una tabla de contenido activa. Al hacer clic en uno de los valores
en el lado izquierdo de la pantalla, la vista de consultas se desplaza directamente al elemento en el que haya
hecho clic.
Filter
También puede filtrar las consultas según los valores de agrupación mencionados antes. En el cuadro de diálogo
de la consulta de ejemplo, los filtros se encuentran en la parte superior.
Combinación de Agrupar por y Filtrar
La funcionalidad de filtrar y agrupar por está diseñada para trabajar de manera conjunta. Proporcionan
flexibilidad en el modo de organizar las consultas. Por ejemplo, si usa un grupo de recursos con varios recursos,
es posible que quiera filtrar por un tipo de recurso específico y organizar las consultas resultantes por tema.
Comportamiento de la apariencia del cuadro de diálogo de consulta

de ejemplo
Si es un profesional de KQL y prefiere ir directamente al editor de consultas, puede "desactivar" el cuadro de
diálogo de consulta. Al desactivarlo, el cuadro de diálogo de consulta de ejemplo no se abre al cargar la pantalla
de Log Analytics.
Siempre puede acceder a la experiencia del cuadro emergente de la consulta de ejemplo desde el botón Consultas
de ejemplo de la barra superior de Log Analytics.
Explorador de consultas
La experiencia del explorador de consultas para guardar y compartir consultas generadas por el usuario se
conserva sin cambios por el momento.
Pasos siguientes
Introducción a las consultas KQL
Ejemplos de consultas de registro de Azure Monitor
En este artículo se incluyen varios ejemplos de consultas que usan el lenguaje de consulta de Kusto para recuperar
distintos tipos de datos de registro de Azure Monitor. Se utilizan métodos diferentes para consolidar y analizar los
datos, por lo que puede usar estos ejemplos para identificar las diferentes estrategias que puede utilizar para sus
propios requisitos.
Consulte la referencia del lenguaje Kusto para más información sobre las diferentes palabras clave usadas en estos
ejemplos. Puede consultar una lección sobre cómo crear consultas si no está familiarizado con Azure Monitor.
Eventos
Búsqueda de eventos de nivel de aplicación descritos como "Criptográficos"
Este ejemplo busca registros en la tabla Events en los que EventLog es igual a Application y
RenderedDescription contiene cryptographic. Incluye registros de las últimas 24 horas.
Event
| where EventLog == "Application"
| where RenderedDescription contains "cryptographic"
Búsqueda de eventos relacionados con la deserialización

Búsqueda de registros en las tablas Event y SecurityEvents que mencionan unmarshaling.
search in (Event, SecurityEvent) "unmarshaling"
Latido
Gráfico de una vista semana a semana del número de equipos que envían datos
El ejemplo siguiente crea un gráfico del número de equipos distintos que envían latidos, cada semana.
Heartbeat
| where TimeGenerated >= startofweek(ago(21d))
| summarize dcount(Computer) by endofweek(TimeGenerated) | render barchart kind=default
Búsqueda de equipos obsoletos

El ejemplo siguiente busca los equipos que estaban activos en el último día, pero no han enviado latidos en la
última hora.
Heartbeat
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where isnotempty(Computer)
| where LastHeartbeat < ago(1h)
Obtención del registro de latido más reciente por dirección IP del equipo
Este ejemplo devuelve el último registro de latido por cada dirección IP de equipo.
Heartbeat
| summarize arg_max(TimeGenerated, *) by ComputerIP
Coincidencia de los registros de estado protegido con los registros de latidos

Este ejemplo busca registros de estado protegido y registros de latidos relacionados, coincidentes en equipo y
hora. Tenga en cuenta que el campo de hora se redondea al minuto más cercano. Hemos usado un cálculo binario
en tiempo de ejecución para ello: round_time=bin(TimeGenerated, 1m) .
let protection_data = ProtectionStatus

| project Computer, DetectionId, round_time=bin(TimeGenerated, 1m);
let heartbeat_data = Heartbeat
| project Computer, Category, round_time=bin(TimeGenerated, 1m);
protection_data | join (heartbeat_data) on Computer, round_time
Tasa de disponibilidad del servidor

Calcula la tasa de disponibilidad del servidor en función de los registros de latidos. La disponibilidad se define
como "al menos 1 latido por hora". Por lo tanto, si un servidor ha estado disponible 98 horas de cada 100, la tasa
de disponibilidad es un 98%.
let start_time=startofday(datetime("2018-03-01"));
let end_time=now();
Heartbeat
| where TimeGenerated > start_time and TimeGenerated < end_time
| summarize heartbeat_per_hour=count() by bin_at(TimeGenerated, 1h, start_time), Computer
| extend available_per_hour=iff(heartbeat_per_hour>0, true, false)
| summarize total_available_hours=countif(available_per_hour==true) by Computer
| extend total_number_of_buckets=round((end_time-start_time)/1h)+1
| extend availability_rate=total_available_hours*100/total_number_of_buckets
Varios tipos de datos

Gráfico del número de registros por cada tabla
El siguiente ejemplo recopila todos los registros de todas las tablas en las últimas cinco horas y realiza un recuento
de cuántos registros hay en cada tabla. Los resultados se muestran en un gráfico de tiempo.
union withsource=sourceTable *
| summarize count() by bin(TimeGenerated,10m), sourceTable
| render timechart
Recuento de todos los registros recopilados durante la última hora por tipo
El ejemplo siguiente busca todo lo que se ha notificado en la última hora y hace un recuento de los registros de
cada tabla por tipo . Los resultados se muestran en un gráfico de barras.
search *
| summarize CountOfRecords = count() by Type
| render barchart
AzureDiagnostics
Recuento de registros de diagnóstico de Azure por categoría
Este ejemplo hace un recuento de todos los registros de diagnóstico de Azure por cada categoría única.
AzureDiagnostics
| summarize count() by Category
Obtención de un registro aleatorio de cada categoría única

En este ejemplo se obtiene un único registro de diagnóstico de Azure aleatorio de cada categoría única.
AzureDiagnostics
| summarize any(*) by Category
Obtención del registro más reciente por categoría

En este ejemplo se obtiene el último registro de diagnóstico de Azure de cada categoría única.
AzureDiagnostics
| summarize arg_max(TimeGenerated, *) by Category
Supervisión de redes
Equipos con latencia en estado incorrecto
En este ejemplo se crea una lista de equipos con latencia en estado incorrecto.
NetworkMonitoring
| where LatencyHealthState <> "Healthy"
| where Computer != ""
| distinct Computer
Rendimiento
Unión de los registros de rendimiento de equipos para poner en correlación memoria y CPU
En este ejemplo se pone en correlación los registros de rendimiento de un equipo determinado y se crean dos
gráficos de tiempo: el promedio de CPU y la memoria máxima.
let StartTime = now()-5d;

let EndTime = now()-4d;
Perf
| where TimeGenerated > StartTime and TimeGenerated < EndTime
| project TimeGenerated, Computer, cpu=CounterValue
| join kind= inner (
Perf
| where CounterName == "% Used Memory"
| where TimeGenerated > StartTime and TimeGenerated < EndTime
| project TimeGenerated , Computer, mem=CounterValue
) on TimeGenerated, Computer
| summarize avgCpu=avg(cpu), maxMem=max(mem) by TimeGenerated bin=30m
| render timechart
Gráfico de rendimiento del uso de CPU por equipo

En este ejemplo se calcula y se representa gráficamente el uso de CPU de los equipos que comienzan por Contoso.
Perf
| where Computer startswith "Contoso"
| where CounterName == @"% Processor Time"
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 15m)
| render timechart
Estado de protección
Equipos con la duración del estado de protección sin informes
En este ejemplo se enumeran los equipos que tenían un estado de protección de Not Reporting y la duración en la
que se encontraban en este estado.
ProtectionStatus
| where ProtectionStatus == "Not Reporting"
| summarize count(), startNotReporting = min(TimeGenerated), endNotReporting = max(TimeGenerated) by Computer,
ProtectionStatusDetails
| join ProtectionStatus on Computer
| summarize lastReporting = max(TimeGenerated), startNotReporting = any(startNotReporting), endNotReporting =
any(endNotReporting) by Computer
| extend durationNotReporting = endNotReporting - startNotReporting
Coincidencia de los registros de estado protegido con los registros de latidos

Este ejemplo busca registros de estado protegido y registros de latidos relacionados, coincidentes en equipo y
hora. El campo de hora se redondea al minuto más cercano con bin .
let protection_data = ProtectionStatus

| project Computer, DetectionId, round_time=bin(TimeGenerated, 1m);
let heartbeat_data = Heartbeat
| project Computer, Category, round_time=bin(TimeGenerated, 1m);
protection_data | join (heartbeat_data) on Computer, round_time
Registros de seguridad
Número de eventos de seguridad por identificador de actividad
Este ejemplo se basa en la estructura fija de la columna Activity : <ID>-<Name>. Analiza el valor de Activity en
dos nuevas columnas y hace un recuento de las apariciones de cada activityID .
SecurityEvent
| project Activity
| parse Activity with activityID " - " activityDesc
| summarize count() by activityID
Número de eventos de seguridad relacionados con los permisos

En este ejemplo se muestra el número de registros securityEvent en los que la columna Activity contiene el
término completo Permissions. La consulta se aplica a los registros creados en los últimos 30 minutos.
SecurityEvent
| summarize EventCount = countif(Activity has "Permissions")
Búsqueda de cuentas en las que no se pudo iniciar sesión desde equipos con una detección de seguridad
Este ejemplo busca y hace un recuento de las cuentas en las que no se pudo iniciar sesión desde equipos en los
que se ha identificado una detección de seguridad.
let detections = toscalar(SecurityDetection

| summarize makeset(Computer));
SecurityEvent
| where Computer in (detections) and EventID == 4624
| summarize count() by Account
¿Están disponibles mis datos de seguridad?

La exploración de los datos a menudo comienza por la comprobación de la disponibilidad de los datos. En este
ejemplo se muestra el número de registros SecurityEvent en los últimos 30 minutos.
SecurityEvent
| count
Análisis del nombre y el identificador de la actividad

Los dos ejemplos siguientes se basan en la estructura fija de la columna Activity : <ID>-<Name>. El primer
ejemplo utiliza el operador parse para asignar valores a dos nuevas columnas: activityID y activityDesc .
SecurityEvent
| take 100
| project Activity
| parse Activity with activityID " - " activityDesc
Este ejemplo usa el operador split para crear una matriz de valores independientes
SecurityEvent
| take 100
| project Activity
| extend activityArr=split(Activity, " - ")
| project Activity , activityArr, activityId=activityArr[0]
Procesos de credenciales explícitas

El ejemplo siguiente muestra un gráfico circular de procesos que han usado credenciales explícitas en la última
semana
SecurityEvent
// filter by id 4648 ("A logon was attempted using explicit credentials")
| summarize count() by Process
| render piechart
Procesos de mayor ejecución

El ejemplo siguiente muestra una línea de tiempo de actividad para los cinco procesos más comunes, durante los
últimos tres días.
// Find all processes that started in the last three days. ID 4688: A new process has been created.
let RunProcesses =
SecurityEvent
| where EventID == "4688";
// Find the 5 processes that were run the most
let Top5Processes =
RunProcesses
| summarize count() by Process
| top 5 by count_;
// Create a time chart of these 5 processes - hour by hour
RunProcesses
| where Process in (Top5Processes)
| summarize count() by bin (TimeGenerated, 1h), Process
| render timechart
Búsqueda de intentos repetidos de inicio de sesión fallidos con la misma cuenta desde direcciones IP diferentes
El ejemplo siguiente busca los intentos de inicio de sesión fallidos con la misma cuenta desde más de cinco
direcciones IP diferentes en las últimas seis horas.
SecurityEvent
| where AccountType == "User" and EventID == 4625 and TimeGenerated > ago(6h)
| summarize IPCount = dcount(IpAddress), makeset(IpAddress) by Account
| where IPCount > 5
| sort by IPCount desc
Búsqueda de cuentas de usuario en las que no se pudo iniciar sesión

El ejemplo siguiente identifica las cuentas de usuario en las que no se pudo iniciar sesión más de cinco veces en el
último día y cuándo se intentó iniciar sesión por última vez.
let timeframe = 1d;

SecurityEvent
| where AccountType == 'User' and EventID == 4625 // 4625 - failed log in
| summarize failed_login_attempts=count(), latest_failed_login=arg_max(TimeGenerated, Account) by Account
| where failed_login_attempts > 5
| project-away Account1
Mediante el uso de las instrucciones join y let , podemos comprobar si las mismas cuentas sospechosas
posteriormente pudieron iniciar sesión correctamente.
let timeframe = 1d;
let suspicious_users =
SecurityEvent
| where TimeGenerated > ago(timeframe)
| where AccountType == 'User' and EventID == 4625 // 4625 - failed login
| summarize failed_login_attempts=count(), latest_failed_login=arg_max(TimeGenerated, Account) by Account
| where failed_login_attempts > 5
| project-away Account1;
let suspicious_users_that_later_logged_in =
suspicious_users
| join kind=innerunique (
SecurityEvent
| where TimeGenerated > ago(timeframe)
| where AccountType == 'User' and EventID == 4624 // 4624 - successful login,
| summarize latest_successful_login=arg_max(TimeGenerated, Account) by Account
) on Account
| extend was_login_after_failures = iif(latest_successful_login>latest_failed_login, 1, 0)
| where was_login_after_failures == 1
;
suspicious_users_that_later_logged_in
Uso
El tipo de datos Usage se puede usar para realizar un seguimiento del volumen de datos ingerido por solución o
tipo de datos. Hay otras técnicas para estudiar los volúmenes de datos ingeridos por equipo o por suscripción,
grupo de recursos o recurso de Azure.
Data volume by solution (Volumen de datos por solución )
La consulta que se usa para ver el volumen de datos facturable por solución en el último mes (excepto el último
día parcial) es:
Usage
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), Solution | render barchart
Tenga en cuenta que la cláusula where IsBillable = true filtra los tipos de datos de determinadas soluciones para
las que no hay ningún cargo de ingesta. Además, la cláusula con TimeGenerated solo se utiliza para asegurarse de
que la experiencia de consulta en Azure Portal examine más allá del periodo predeterminado de 24 horas. Al
utilizar el tipo de datos de uso, StartTime y EndTime representan los periodos de tiempo de los que se presentan
resultados.
Volumen de datos por tipo
Puede profundizar más para ver las tendencias de datos por tipo de datos:
Usage
| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType | render barchart
O bien, para ver una tabla por solución y tipo durante el último mes,
Usage
| summarize BillableDataGB = sum(Quantity) / 1000. by Solution, DataType
| sort by Solution asc, DataType asc
NOTE
Algunos de los campos del tipo de datos de uso, aunque siguen en el esquema, han quedado en desuso y ya no se
rellenarán sus valores. Estos son Computer , además de los campos relacionados con la ingesta (TotalBatches ,
BatchesWithinSla , BatchesOutsideSla , BatchesCapped y AverageProcessingTimeMs .
Actualizaciones
Equipos con actualizaciones pendientes
En este ejemplo se muestra una lista de equipos a los que les faltaban una o más actualizaciones críticas hace unos
días y todavía les faltan las actualizaciones.
let ComputersMissingUpdates3DaysAgo = Update

| where TimeGenerated between (ago(30d)..ago(1h))
| where Classification !has "Critical" and UpdateState =~ "Needed"
| summarize makeset(Computer);
Update
| where Classification has "Critical" and UpdateState =~ "Needed"
| where Computer in (ComputersMissingUpdates3DaysAgo)
| summarize UniqueUpdatesCount = dcount(Product) by Computer, OSType
Pasos siguientes
Consulte la referencia del lenguaje Kusto para más información sobre el lenguaje.
Consulte una lección sobre la escritura de consultas de registro en Azure Monitor.
Ejemplos de análisis inteligente de Log Analytics
En este ejemplo se incluyen ejemplos que usan las funciones de análisis inteligente en Log Analytics para realizar
un análisis de la actividad del usuario. Puede usar estos ejemplos para analizar sus propias aplicaciones
supervisadas por Application Insights o usar los conceptos en estas consultas para realizar un análisis similar en
otros datos.
Consulte la referencia del lenguaje Kusto para más información sobre las diferentes palabras clave usadas en estos
ejemplos. Puede consultar una lección sobre cómo crear consultas si no está familiarizado con Log Analytics.
Análisis de cohortes
El análisis de cohortes realiza un seguimiento de la actividad de determinados grupos de usuarios, conocidos como
cohortes. Intenta medir qué tan atractivo es un servicio mediante la tasa de usuarios que vuelven a usarlo. Los
usuarios se agrupan según el momento en que utilizaron el servicio por primera vez. Al analizar a las cohortes, se
espera encontrar una disminución de la actividad durante los primeros períodos sometidos a seguimiento. Cada
cohorte recibe un nombre según la semana en que sus miembros se observaron por primera vez.
En el ejemplo siguiente se analiza el número de actividades que los usuarios realizan en el transcurso de 5 semanas
a partir de su primer uso del servicio.
let startDate = startofweek(bin(datetime(2017-01-20T00:00:00Z), 1d));
let week = range Cohort from startDate to datetime(2017-03-01T00:00:00Z) step 7d;
// For each user we find the first and last timestamp of activity
let FirstAndLastUserActivity = (end:datetime)
{
customEvents
| where customDimensions["sourceapp"]=="ai-loganalyticsui-prod"
// Check 30 days back to see first time activity
| where timestamp > startDate - 30d
| where timestamp < end
| summarize min=min(timestamp), max=max(timestamp) by user_AuthenticatedId
};
let DistinctUsers = (cohortPeriod:datetime, evaluatePeriod:datetime) {
toscalar (
FirstAndLastUserActivity(evaluatePeriod)
// Find members of the cohort: only users that were observed in this period for the first time
| where min >= cohortPeriod and min < cohortPeriod + 7d
// Pick only the members that were active during the evaluated period or after
| where max > evaluatePeriod - 7d
| summarize dcount(user_AuthenticatedId))
};
week
| where Cohort == startDate
// Finally, calculate the desired metric for each cohort. In this sample we calculate distinct users but you
can change
// this to any other metric that would measure the engagement of the cohort members.
| extend
r0 = DistinctUsers(startDate, startDate+7d),
r4 = DistinctUsers(startDate, startDate+35d)
| union (week | where Cohort == startDate + 7d
| extend
r0 = DistinctUsers(startDate+7d, startDate+14d),
r3 = DistinctUsers(startDate+7d, startDate+35d) )
| extend
| extend
| extend
r0 = DistinctUsers (startDate+28d, startDate+35d) )
// Calculate the retention percentage for each cohort by weeks
| project Cohort, r0, r1, r2, r3, r4,
p0 = r0/r0*100,
p1 = todouble(r1)/todouble (r0)*100,
p2 = todouble(r2)/todouble(r0)*100,
p3 = todouble(r3)/todouble(r0)*100,
p4 = todouble(r4)/todouble(r0)*100
| sort by Cohort asc
Este ejemplo devuelve la siguiente salida.

Usuarios activos mensuales graduales y permanencia del usuario
En los ejemplos siguientes se usa el análisis de series temporales con la función series_fir, que le permite realizar
cálculos de ventana deslizante. La aplicación de ejemplo que se está supervisando es una tienda en línea que realiza
el seguimiento de actividad de los usuarios a través de eventos personalizados. La consulta realiza un seguimiento
de dos tipos de actividades de usuario, Agregar al carro y Finalización de la compra y define como usuarios activos
a aquellos que realizan una finalización de la compra al menos una vez en un día determinado.
let endtime = endofday(datetime(2017-03-01T00:00:00Z));
let window = 60d;
let starttime = endtime-window;
let interval = 1d;
let user_bins_to_analyze = 28;
// Create an array of filters coefficients for series_fir(). A list of '1' in our case will produce a simple
sum.
let moving_sum_filter = toscalar(range x from 1 to user_bins_to_analyze step 1 | extend v=1 | summarize
makelist(v));
// Level of engagement. Users will be counted as engaged if they performed at least this number of activities.
let min_activity = 1;
customEvents
| where timestamp > starttime
| where customDimensions["sourceapp"] == "ai-loganalyticsui-prod"
// We want to analyze users who actually checked-out in our web site
| where (name == "Checkout") and user_AuthenticatedId <> ""
// Create a series of activities per user
| make-series UserClicks=count() default=0 on timestamp
in range(starttime, endtime-1s, interval) by user_AuthenticatedId
// Create a new column containing a sliding sum.
// Passing 'false' as the last parameter to series_fir() prevents normalization of the calculation by the size
of the window.
// For each time bin in the *RollingUserClicks* column, the value is the aggregation of the user activities in
the
// 28 days that preceded the bin. For example, if a user was active once on 2016-12-31 and then inactive
throughout
// January, then the value will be 1 between 2016-12-31 -> 2017-01-28 and then 0s.
| extend RollingUserClicks=series_fir(UserClicks, moving_sum_filter, false)
// Use the zip() operator to pack the timestamp with the user activities per time bin
| project User_AuthenticatedId=user_AuthenticatedId , RollingUserClicksByDay=zip(timestamp, RollingUserClicks)
// Transpose the table and create a separate row for each combination of user and time bin (1 day)
| mvexpand RollingUserClicksByDay
| extend Timestamp=todatetime(RollingUserClicksByDay[0])
// Mark the users that qualify according to min_activity
| extend RollingActiveUsersByDay=iff(toint(RollingUserClicksByDay[1]) >= min_activity, 1, 0)
// And finally, count the number of users per time bin.
| summarize sum(RollingActiveUsersByDay) by Timestamp
// First 28 days contain partial data, so we filter them out.
| where Timestamp > starttime + 28d
// render as timechart
| render timechart

En el ejemplo siguiente se convierte la consulta anterior en una función reutilizable y se usa para calcular la
permanencia gradual del usuario. Los usuarios activos en esta consulta se definen únicamente como aquellos
usuarios que realizaron una finalización de la compra al menos una vez en un día determinado.
let rollingDcount = (sliding_window_size: int, event_name:string)

{
let endtime = endofday(datetime(2017-03-01T00:00:00Z));
let window = 90d;
let starttime = endtime-window;
let interval = 1d;
let moving_sum_filter = toscalar(range x from 1 to sliding_window_size step 1 | extend v=1| summarize
makelist(v));
let min_activity = 1;
customEvents
| where timestamp > starttime
| where customDimensions["sourceapp"]=="ai-loganalyticsui-prod"
| where (name == event_name)
| where user_AuthenticatedId <> ""
| make-series UserClicks=count() default=0 on timestamp
in range(starttime, endtime-1s, interval) by user_AuthenticatedId
| extend RollingUserClicks=fir(UserClicks, moving_sum_filter, false)
| project User_AuthenticatedId=user_AuthenticatedId , RollingUserClicksByDay=zip(timestamp,
RollingUserClicks)
| mvexpand RollingUserClicksByDay
| extend Timestamp=todatetime(RollingUserClicksByDay[0])
| extend RollingActiveUsersByDay=iff(toint(RollingUserClicksByDay[1]) >= min_activity, 1, 0)
| summarize sum(RollingActiveUsersByDay) by Timestamp
| where Timestamp > starttime + 28d
};
// Use the moving_sum_filter with bin size of 28 to count MAU.
rollingDcount(28, "Checkout")
| join
(
// Use the moving_sum_filter with bin size of 1 to count DAU.
rollingDcount(1, "Checkout")
)
on Timestamp
| project sum_RollingActiveUsersByDay1 *1.0 / sum_RollingActiveUsersByDay, Timestamp
| render timechart

Análisis de regresión
En este ejemplo se muestra cómo crear un detector automatizado para las interrupciones del servicio basado
exclusivamente en los registros de seguimiento de la aplicación. El detector busca aumentos repentinos y anómalos
en la cantidad relativa de seguimientos de error y de advertencia en la aplicación.
Estas dos técnicas se utilizan para evaluar el estado del servicio según los datos de los registros de seguimiento:
Use el operador make-series para convertir los registros de seguimiento de texto semiestructurados en una
métrica que represente la relación entre las líneas de seguimiento positivas y negativas.
Use series_fit_2lines y series_fit_line para realizar una detección avanzada de saltos mediante el análisis de
series temporales con una regresión lineal de 2 líneas.
let startDate = startofday(datetime("2017-02-01"));

let endDate = startofday(datetime("2017-02-07"));
let minRsquare = 0.8; // Tune the sensitivity of the detection sensor. Values close to 1 indicate very low
sensitivity.
// Count all Good (Verbose + Info) and Bad (Error + Fatal + Warning) traces, per day
traces
| where timestamp > startDate and timestamp < endDate
| summarize
Verbose = countif(severityLevel == 0),
Info = countif(severityLevel == 1),
Warning = countif(severityLevel == 2),
Error = countif(severityLevel == 3),
Fatal = countif(severityLevel == 4) by bin(timestamp, 1d)
| extend Bad = (Error + Fatal + Warning), Good = (Verbose + Info)
// Determine the ratio of bad traces, from the total
| extend Ratio = (todouble(Bad) / todouble(Good + Bad))*10000
| project timestamp , Ratio
// Create a time series
| make-series RatioSeries=any(Ratio) default=0 on timestamp in range(startDate , endDate -1d, 1d) by
'TraceSeverity'
// Apply a 2-line regression to the time series
| extend (RSquare2, SplitIdx, Variance2,RVariance2,LineFit2)=series_fit_2lines(RatioSeries)
// Find out if our 2-line is trending up or down
| extend (Slope,Interception,RSquare,Variance,RVariance,LineFit)=series_fit_line(LineFit2)
// Check whether the line fit reaches the threshold, and if the spike represents an increase (rather than a
decrease)
| project PatternMatch = iff(RSquare2 > minRsquare and Slope>0, "Spike detected", "No Match")
Pasos siguientes
Consulte la referencia del lenguaje de Data Explorer para obtener más información sobre el lenguaje.
Repase una lección sobre la escritura de consultas en Log Analytics.
Optimización de las consultas de registro en Azure
Monitor
Los registros de Azure Monitor usan Azure Data Explorer (ADX) para almacenar los datos de registro y ejecutar
consultas para analizar los datos. Crea, administra y mantiene los clústeres de ADX automáticamente y los
optimiza para la carga de trabajo de análisis de registros. Al ejecutar una consulta, se optimiza y se redirige al
clúster de ADX adecuado que almacena los datos del área de trabajo. Tanto los registros de Azure Monitor como
Azure Data Explorer usan muchos mecanismos de optimización de consultas automática. Aunque las
optimizaciones automáticas proporcionan un aumento significativo, en algunos casos se puede mejorar
drásticamente el rendimiento de las consultas. En este artículo se explican las consideraciones de rendimiento y
varias técnicas para corregirlas.
La mayoría de las técnicas son comunes a las consultas que se ejecutan directamente en Azure Data Explorer y
registros de Azure Monitor, aunque hay varias consideraciones únicas de registros de Azure Monitor que se
describen aquí. Para obtener más información sobre las sugerencias de optimización de Azure Data Explorer,
consulte Procedimientos recomendados sobre las consultas.
Las consultas optimizadas:
Se ejecutarán más rápido y reducirán la duración total de la ejecución de la consulta.
Tendrán menos posibilidades de que se limiten o rechacen.
Debe prestar especial atención a las consultas que se usan para el uso recurrente y de ráfaga, como paneles,
alertas, Logic Apps y Power BI. El impacto de una consulta ineficaz en estos casos es considerable.
Panel de rendimiento de consultas

Después de ejecutar una consulta en Log Analytics, haga clic en la flecha hacia abajo que aparece sobre los
resultados de la consulta para ver el panel rendimiento de consultas que muestra los resultados de varios
indicadores de rendimiento para la consulta. Estos indicadores de rendimiento se describen en la sección
siguiente.
Indicadores de rendimiento de consultas

Los siguientes indicadores de rendimiento de consultas están disponibles para todas las consultas que se
ejecutan:
CPU total: Proceso general usado para procesar la consulta en todos los nodos de proceso. Representa el
tiempo que se usa para la computación, el análisis y la captura de datos.
Datos usados para la consulta procesada: Datos globales a los que se obtuvo acceso para procesar la
consulta. Se ve afectado por el tamaño de la tabla de destino, el intervalo de tiempo usado, los filtros
aplicados y el número de columnas a que se hace referencia.
Intervalo de tiempo de la consulta procesada: La diferencia entre los datos más recientes y los más
antiguos a los que se obtuvo acceso para procesar la consulta. Se ve afectado por el intervalo de tiempo
explícito especificado para la consulta.
Antigüedad de los datos procesados: La diferencia entre los datos actuales y los más antiguos a los que se
obtuvo acceso para procesar la consulta. Afecta enormemente a la eficacia de la captura de datos.
Número de áreas de trabajo: Número de áreas de trabajo a las que se obtuvo acceso durante el
procesamiento de la consulta debido a una selección implícita o explícita.
Número de regiones: Número de regiones a las que se obtuvo acceso durante el procesamiento de la
consulta debido a una selección implícita o explícita de áreas de trabajo. Las consultas de varias regiones
son mucho menos eficientes y los indicadores de rendimiento presentan una cobertura parcial.
Paralelismo: Indica la cantidad de tiempo que el sistema pudo ejecutar esta consulta en varios nodos. Solo
es relevante para las consultas que tienen un uso elevado de la CPU. Se ve afectado por el uso de
funciones y operadores específicos.
CPU total
La CPU de cálculo real que se ha invertido para procesar esta consulta en todos los nodos de procesamiento de
consultas. Como la mayoría de las consultas se ejecutan en un gran número de nodos, normalmente será mucho
mayor que la duración de la ejecución de la consulta.
Si una consulta consume más de 100 segundos de CPU, se considera que consume demasiados recursos. Si una
consulta utiliza más de 1000 segundos de CPU, se considera abusiva y podría verse limitada.
El tiempo de procesamiento de consultas se emplea en:
Recuperación de datos: la recuperación de datos antiguos consumirá más tiempo que la recuperación de
datos recientes.
Procesamiento de datos: lógica y evaluación de los datos.
Aparte del tiempo dedicado a los nodos de procesamiento de consultas, hay un tiempo adicional que los
registros de Azure Monitor invierten en: autenticar el usuario y comprobar que tiene permiso para acceder a
estos datos, buscar el almacén de datos, analizar la consulta y asignar los nodos de procesamiento de consultas.
Este tiempo no se incluye en el tiempo de CPU total de la consulta.
Filtrado temprano de registros antes de usar funciones de CPU elevadas
Algunos de los comandos de consulta y las funciones realizan un gran consumo de CPU. Esto es especialmente
cierto para los comandos que analizan JSON y XML o extraen expresiones regulares complejas. Este análisis
puede producirse explícitamente a través de las funciones parse_json() o parse_xml() o implícitamente cuando se
hace referencia a columnas dinámicas.
Estas funciones consumen CPU en proporción al número de filas que están procesando. La optimización más
eficaz consiste en agregar inmediatamente condiciones where en la consulta que pueden filtrar tantos registros
como sea posible antes de que se ejecute la función de uso intensivo de la CPU.
Por ejemplo, las siguientes consultas producen exactamente el mismo resultado, pero la segunda es mucho más
eficaz, ya que la condición where antes del análisis excluye muchos registros:
//less efficient
SecurityEvent
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32" // Problem: irrelevant results are filtered
after all processing and parsing is done
| summarize count() by FileHash, FilePath
//more efficient
SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| extend Details = parse_xml(EventData)
| extend FilePath = tostring(Details.UserData.RuleAndFileData.FilePath)
| extend FileHash = tostring(Details.UserData.RuleAndFileData.FileHash)
| where FileHash != "" and FilePath !startswith "%SYSTEM32" // exact removal of results. Early filter is
not accurate enough
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before
Evitar el uso de cláusulas where evaluadas

Las consultas que contienen cláusulas where en una columna evaluada en lugar de en columnas que están
físicamente presentes en el conjunto de datos pierden eficacia. El filtrado de columnas evaluadas evita algunas
optimizaciones del sistema cuando se administran grandes conjuntos de datos. Por ejemplo, las siguientes
consultas producen exactamente el mismo resultado, pero la segunda es más eficaz, ya que la condición where
hace referencia a la columna integrada.
//less efficient
Heartbeat
| extend IPRegion = iif(RemoteIPLongitude < -94,"WestCoast","EastCoast")
| where IPRegion == "WestCoast"
| summarize count(), make_set(IPRegion) by Computer
//more efficient
Heartbeat
| where RemoteIPLongitude < -94
| extend IPRegion = iif(RemoteIPLongitude < -94,"WestCoast","EastCoast")
| summarize count(), make_set(IPRegion) by Computer
Uso de dimensiones y comandos de agregación efectivos para resúmenes y uniones

Aunque algunos comandos de agregación, como max(), sum(), count() y avg(), tienen un impacto bajo en la CPU
debido a su lógica, otros son más complejos e incluyen heurística y estimaciones que les permiten ejecutarse de
forma eficaz. Por ejemplo, dcount() usa el algoritmo HyperLogLog para proporcionar una estimación próxima
para distinguir el recuento de grandes conjuntos de datos sin contar realmente cada valor; las funciones de
percentil realizan aproximaciones similares mediante el algoritmo de percentil de clasificación más próximo.
Algunos de los comandos incluyen parámetros opcionales para reducir su impacto. Por ejemplo, la función
makeset() tiene un parámetro opcional para definir el tamaño máximo del conjunto, lo que afecta
significativamente a la CPU y la memoria.
Los comandos Join y summarize pueden provocar un uso intensivo de la CPU cuando se procesa un gran
conjunto de datos. Su complejidad está directamente relacionada con el número de valores posibles,
denominado cardinalidad, de las columnas que usan, como by en summarize o como los atributos join. Para
obtener una explicación y una optimización de join y resume, consulte sus artículos de documentación y
sugerencias de optimización.
Por ejemplo, las siguientes consultas producen exactamente el mismo resultado, porque CounterPath siempre
tiene una asignación uno a uno para CounterName y ObjectName . La segunda es más eficaz, ya que la
dimensión de agregación es más pequeña:
//less efficient
Perf
| summarize avg(CounterValue)
by CounterName, CounterPath, ObjectName
//make the group expression more compact improve the performance

Perf
| summarize avg(CounterValue), any(CounterName), any(ObjectName)
by CounterPath
El consumo de CPU también puede verse afectado por condiciones where o columnas extendidas que necesitan
una computación intensiva. Todas las comparaciones triviales de cadenas, como equal == y startswith, tienen
prácticamente el mismo impacto en la CPU, mientras que las coincidencias de texto avanzadas tienen más
impacto. En concreto, el operador has es más eficaz que el operador contains. Debido a las técnicas de control de
cadenas, es más eficaz buscar cadenas que tienen más de cuatro caracteres que cadenas cortas.
Por ejemplo, las siguientes consultas generan resultados similares en función de la directiva de nomenclatura de
procesos, pero la segunda es más eficaz:
//less efficient – due to filter based on contains

Heartbeat
| where Computer contains "Production"
| summarize count() by ComputerIP
//less efficient – due to filter based on extend

Heartbeat
| extend MyComputer = Computer
| where MyComputer startswith "Production"
//more efficient
Heartbeat
| where Computer startswith "Production"
NOTE
Este indicador solo presenta la CPU del clúster inmediato. En una consulta de varias regiones, solo representaría una de las
regiones. En una consulta de varias áreas de trabajo, es posible que no incluya todas las áreas de trabajo.
Evite el análisis XML y JSON completo cuando funcione el análisis de cadenas

El análisis completo de un objeto XML o JSON puede consumir una gran cantidad de recursos de CPU y
memoria. En muchos casos, cuando solo se necesitan uno o dos parámetros y los objetos XML o JSON son
simples, es más fácil analizarlos como cadenas mediante el operador parse u otras técnicas de análisis de texto.
La mejora del rendimiento será más significativa a medida que aumente el número de registros en el objeto XML
o JSON. Es fundamental cuando el número de registros alcanza decenas de millones.
Por ejemplo, la consulta siguiente devolverá exactamente los mismos resultados que las consultas anteriores sin
realizar un análisis XML completo. Tenga en cuenta que hace algunas suposiciones sobre la estructura del archivo
XML, como que el elemento FilePath aparece después de FileHash y que ninguno de ellos tiene atributos.
//even more efficient

SecurityEvent
| where EventID == 8002 //Only this event have FileHash
| where EventData !has "%SYSTEM32" //Early removal of unwanted records
| parse EventData with * "<FilePath>" FilePath "</FilePath>" * "<FileHash>" FileHash "</FileHash>" *
| where FileHash != "" // No need to filter out %SYSTEM32 here as it was removed before
Datos usados para la consulta procesada

Un factor crítico en el procesamiento de la consulta es el volumen de datos que se digitaliza y usa para el
procesamiento de la consulta. Azure Data Explorer usa optimizaciones agresivas que reducen en gran medida el
volumen de datos en comparación con otras plataformas de datos. Aún así, hay factores críticos en la consulta
que pueden afectar al volumen de datos que se usa.
Si una consulta procesa más de 2000 KB de datos, se considera que consume demasiados recursos. Si una
consulta procesa más de 20 000 KB de datos, se considera abusiva y podría verse limitada.
En los registros de Azure Monitor, la columna TimeGenerated se usa para indexar los datos. Si los valores de
TimeGenerated se restringen tanto como sea posible, se producirá una mejora significativa en el rendimiento
de la consulta mediante una limitación considerable de la cantidad de datos que se tienen que procesar.
Evitar el uso innecesario de los operadores search y union
Otro factor que aumenta los datos que se procesan es el uso de un gran número de tablas. Esto suele ocurrir
cuando se usan los comandos search * y union * . Estos comandos obligan al sistema a evaluar y digitalizar los
datos de todas las tablas del área de trabajo. En algunos casos, puede haber cientos de tablas en el área de
trabajo. Intente evitar en la medida de lo posible el uso de "search *" o cualquier búsqueda sin definir su ámbito a
una tabla específica.
Por ejemplo, las siguientes consultas producen exactamente el mismo resultado, pero la última es, con diferencia,
la más eficaz:
// This version scans all tables though only Perf has this kind of data
search "Processor Time"
| summarize count(), avg(CounterValue) by Computer
// This version scans all strings in Perf tables – much more efficient
Perf
| search "Processor Time"
// This is the most efficient version

Perf
Adición de filtros iniciales a la consulta

Otro método para reducir el volumen de datos es tener condiciones where rápidamente en la consulta. La
plataforma de Azure Data Explorer incluye una memoria caché que le permite saber qué particiones incluyen
datos relevantes para una condición where específica. Por ejemplo, si un consulta contiene
where EventID == 4624 , distribuirá la consulta solo en los nodos que controlan particiones con eventos
coincidentes.
Las siguientes consultas de ejemplo producen exactamente el mismo resultado, pero la última es mucho más
eficaz:
//less efficient
SecurityEvent
| summarize LoginSessions = dcount(LogonGuid) by Account
//more efficient
SecurityEvent
| where EventID == 4624 //Logon GUID is relevant only for logon event
| summarize LoginSessions = dcount(LogonGuid) by Account
Evitar varios exámenes de los mismos datos de origen mediante funciones de agregación condicional y la
función materialize
Cuando una consulta tiene varias subconsultas que se combinan mediante operadores join o union, cada
subconsulta examina todo el origen por separado y, luego, combina los resultados. Como consecuencia, se
multiplica el número de veces que se examinan los datos: un factor crítico en conjuntos de datos muy grandes.
Una técnica para evitar esta situación es usar las funciones de agregación condicional. La mayoría de las
funciones de agregación que se usan en el operador de resumen tienen una versión condicionada que le permite
usar un único operador de resumen con varias condiciones.
Por ejemplo, las siguientes consultas muestran el número de eventos de inicio de sesión y el número de eventos
de ejecución de proceso de cada cuenta. Se devuelven los mismos resultados, pero el primero examina los datos
dos veces y el segundo los examina solo una vez:
//Scans the SecurityEvent table twice and perform expensive join

SecurityEvent
| where EventID == 4624 //Login event
| summarize LoginCount = count() by Account
| join
(
SecurityEvent
| where EventID == 4688 //Process execution event
| summarize ExecutionCount = count(), ExecutedProcesses = make_set(Process) by Account
) on Account
//Scan only once with no join

SecurityEvent
| where EventID == 4624 or EventID == 4688 //early filter
| summarize LoginCount = countif(EventID == 4624), ExecutionCount = countif(EventID == 4688),
ExecutedProcesses = make_set_if(Process,EventID == 4688) by Account
Otro caso en el que las subconsultas no son necesarias es el filtrado previo del operador Parse para asegurarse
de que solo se procesan los registros que coinciden con un patrón específico. Esto no es necesario, ya que el
operador Parse y otros operadores similares devuelven resultados vacíos cuando el patrón no coincide. Estas son
dos consultas que devuelven exactamente los mismos resultados, si bien la segunda consulta examina los datos
una sola vez. En la segunda consulta, cada comando Parse solo es importante para sus eventos. Después, el
operador Extend muestra cómo hacer referencia a la situación de datos vacíos.
//Scan SecurityEvent table twice
union(
SecurityEvent
| distinct FilePath
),(
SecurityEvent
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" *
| distinct CallerProcessName1
)
//Single scan of the SecurityEvent table

SecurityEvent
| where EventID == 8002 or EventID == 4799
//Relevant only for event 8002
| parse EventData with * "CallerProcessName\">" CallerProcessName1 "</Data>" * //Relevant only for event
4799
| extend FilePath = iif(isempty(CallerProcessName1),FilePath,"")
| distinct FilePath, CallerProcessName1
Cuando la situación anterior no permite evitar el uso de subconsultas, otra técnica es sugerir al motor de
consultas que hay un único dato de origen que se usa en cada una de ellas mediante la función materialize(). Esto
resulta útil cuando los datos de origen proceden de una función que se usa varias veces dentro de la consulta.
Reducción del número de columnas que se recuperan
Dado que Azure Data Explorer es un almacén de datos en columnas, la recuperación de cada columna es
independiente de las demás. El número de columnas que se recuperan influye directamente en el volumen de
datos general. Solo se deben incluir las columnas de la salida que se necesitan para resumir los resultados o
proyectar las columnas específicas. Azure Data Explorer tiene varias optimizaciones para reducir el número de
columnas recuperadas. Si se determina que una columna no es necesaria; por ejemplo, si el comando summarize
no hace referencia a ella, no se recuperará.
Por ejemplo, la segunda consulta puede procesar tres veces más datos, ya que necesita capturar no una columna,
sino tres:
//Less columns --> Less data

SecurityEvent
| summarize count() by Computer
//More columns --> More data

SecurityEvent
| summarize count(), dcount(EventID), avg(Level) by Computer
Intervalo de tiempo de la consulta procesada

Todos los registros de Azure Monitor se dividen en particiones según la columna TimeGenerated . El número de
particiones a las que se obtiene acceso está directamente relacionado con el intervalo de tiempo. La forma más
eficaz de garantizar la ejecución de una consulta del símbolo del sistema consiste en reducir el intervalo de
tiempo.
Si una consulta tiene un intervalo de tiempo superior a 15 días, se considera que consume demasiados recursos.
Si una consulta tiene un intervalo de tiempo superior a 90 días, se considera abusiva y podría verse limitada.
El intervalo de tiempo puede establecerse con el selector de intervalo de tiempo en la pantalla de Log Analytics
tal como se describe en Ámbito e intervalo de tiempo de una consulta de registro en Log Analytics de Azure
Monitor. Se trata del método recomendado, ya que el intervalo de tiempo seleccionado se pasa al back-end
mediante los metadatos de la consulta.
Un método alternativo consiste en incluir explícitamente una condición where en TimeGenerated en la
consulta. Se debería usar este método, ya que se asegura que el intervalo de tiempo sea fijo, aunque la consulta
se use desde una interfaz diferente. Debe asegurarse de que todas las partes de la consulta tengan filtros
TimeGenerated . Cuando una consulta tiene subconsultas que capturan datos de diferentes tablas o de la
misma, cada una tiene que incluir su propia condición where.
Asegúrese de que todas las subconsultas tienen el filtro TimeGenerated
Por ejemplo, en la siguiente consulta, mientras que la tabla Perf solo se digitalizará para el último día, la tabla
Hear tbeat se digitalizará para la totalidad de su historial, que puede ser de hasta dos años:
Perf
Heartbeat
//No time span filter in this part of the query
| summarize IPs = makeset(ComputerIP, 10) by Computer
) on Computer
Un caso común en el que se produce dicho error es cuando arg_max() se usa para buscar la repetición más
reciente. Por ejemplo:
Perf
Heartbeat
//No time span filter in this part of the query
| summarize arg_max(TimeGenerated, *), min(TimeGenerated)
by Computer
) on Computer
Se puede corregir fácilmente si se agrega un filtro de tiempo en la consulta interna:
Perf
Heartbeat
| where TimeGenerated > ago(1d) //filter for this part
| summarize arg_max(TimeGenerated, *), min(TimeGenerated)
by Computer
) on Computer
Otro ejemplo de este error es cuando se realiza el filtrado del ámbito de tiempo justo después de una unión en
varias tablas. Al realizar la unión, se debe definir el ámbito de cada subconsulta. Puede usar la instrucción let para
garantizar la coherencia del ámbito.
Por ejemplo, la siguiente consulta examinará todos los datos de las tablas Heartbeat y Perf, no solo del último
día:
Heartbeat
| summarize arg_min(TimeGenerated,*) by Computer
| union (
Perf
| summarize arg_min(TimeGenerated,*) by Computer)
| summarize min(TimeGenerated) by Computer
Esta consulta debe corregirse de la siguiente manera:
let MinTime = ago(1d);

Heartbeat
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer
| union (
Perf
| where TimeGenerated > MinTime
| summarize arg_min(TimeGenerated,*) by Computer)
| summarize min(TimeGenerated) by Computer
Limitaciones de la medición de intervalos de tiempo

La medida siempre es mayor que el tiempo real especificado. Por ejemplo, si el filtro de la consulta es 7 días, el
sistema podría examinar 7,5 o 8,1 días. Esto se debe a que el sistema realiza la partición de los datos en
fragmentos de tamaño variable. Para garantizar que se analizan todos los registros pertinentes, examina toda la
partición que puede abarcar varias horas e incluso más de un día.
Hay varios casos en los que el sistema no puede proporcionar una medida precisa del intervalo de tiempo. Esto
sucede en la mayoría de los casos en los que el intervalo de la consulta es inferior a un día o en consultas de
varias áreas de trabajo.
IMPORTANT
Este indicador solo presenta los datos procesados del clúster inmediato. En una consulta de varias regiones, solo
representaría una de las regiones. En una consulta de varias áreas de trabajo, es posible que no incluya todas las áreas de
trabajo.
Antigüedad de los datos procesados

Azure Data Explorer usa varias capas de almacenamiento: en memoria, discos SSD locales y blobs de Azure
mucho más lentos. Cuanto más recientes sean los datos, más alta será la posibilidad de que se almacenen en una
capa más eficiente y con menos latencia, lo que reduce el uso de la CPU y la duración de la consulta. Al margen
de los propios datos, el sistema también tiene una memoria caché para los metadatos. Cuanto más antiguos
sean los datos, menor será la probabilidad de que sus metadatos estén en la caché.
Si una consulta procesa datos con más de 14 días de antigüedad, se considera que consume demasiados
recursos.
Mientras que algunas consultas requieren el uso de datos antiguos, hay casos en los que dichos datos se usan
por error. Esto sucede cuando las consultas se ejecutan sin proporcionar el intervalo de tiempo en sus metadatos
y no todas las referencias de tabla incluyen filtros en la columna TimeGenerated . En estos casos, el sistema
digitalizará todos los datos que estén almacenados en esa tabla. Cuando la retención de datos es larga, puede
abarcar intervalos de tiempo largos y, por lo tanto, aquellos datos que son tan antiguos como el período de
retención de datos.
A continuación, se indican algunos ejemplos de dichos casos:
No establecer el intervalo de tiempo en Log Analytics con una subconsulta que no esté limitada. Vea el
ejemplo anterior.
Usar la API sin los parámetros opcionales del intervalo de tiempo.
Usar un cliente que no fuerce un intervalo de tiempo, como el conector de Power BI.
Consulte los ejemplos y las notas de la sección anterior, ya que también son relevantes en este caso.
Número de regiones
Hay varias situaciones en las que una única consulta puede ejecutarse en diferentes regiones:
Cuando se incluyen explícitamente varias áreas de trabajo y se ubican en diferentes regiones.
Cuando una consulta con ámbito de recurso está capturando los datos y estos se almacenan en varias áreas
de trabajo ubicadas en diferentes regiones.
La ejecución de consultas en varias regiones requiere que el sistema efectúe la serialización y la transferencia en
los fragmentos grandes del back-end de los datos intermedios que suelen ser mucho mayores que los resultados
finales de la consulta. También limita la capacidad de desempeño del sistema de llevar a cabo optimizaciones,
heurísticas y usar cachés. Si no hay motivo alguno para digitalizar todas estas regiones, debe ajustar el ámbito
para que cubra menos regiones. Si el ámbito del recurso se minimiza, pero aún se usan varias regiones, puede
producirse debido a un error de configuración. Por ejemplo, la configuración de diagnóstico y los registros de
auditoría se envía a diferentes áreas de trabajo en distintas regiones o hay varias configuraciones de diagnóstico.
Si una consulta abarca más de 3 regiones, se considera una que consume demasiados recursos. Si una consulta
abarca más de 6 regiones, se considera abusiva y podría verse limitada.
IMPORTANT
Cuando una consulta se ejecuta en varias regiones, las medidas de los datos y la CPU no serán precisas y solo
representarán la medida en una de las regiones.
Número de áreas de trabajo

Las áreas de trabajo son contenedores lógicos que se usan para separar y administrar los datos de registros. El
back-end optimiza las selecciones de ubicación de las áreas de trabajo en clústeres físicos dentro de la región
seleccionada.
El uso de varias áreas de trabajo puede deberse a alguno de los siguientes casos:
Cuando se enumeran explícitamente varias áreas de trabajo.
Cuando una consulta con ámbito de recurso está capturando los datos y estos se almacenan en varias áreas
de trabajo.
La ejecución de consultas en varios clústeres y varias regiones requiere que el sistema efectúe la serialización y la
transferencia en los fragmentos grandes del back-end de los datos intermedios que suelen ser mucho mayores
que los resultados finales de la consulta. También limita la capacidad de desempeño del sistema de llevar a cabo
optimizaciones, heurísticas y usar cachés.
Si una consulta abarca más de 5 áreas de trabajo, se considera que consume demasiados recursos. Las consultas
no pueden abarcar más de 100 áreas de trabajo.
IMPORTANT
En algunos escenarios de varias áreas de trabajo, las medidas de los datos y la CPU no serán precisas y solo representarán
la medida de algunas de las áreas de trabajo.
Paralelismo
Los registros de Azure Monitor usan clústeres grandes de Azure Data Explorer para ejecutar consultas y dichos
clústeres varían según la escala, lo que puede llevar a obtener decenas de nodos de ejecución. El sistema escala
automáticamente los clústeres en función de la capacidad y la lógica de selección de ubicación del área de
trabajo.
Para ejecutar una consulta de forma eficaz, se divide en particiones y se distribuye en nodos de ejecución según
los datos necesarios para su procesamiento. Hay algunas situaciones en las que el sistema no puede hacer esto
de manera eficiente. Esto puede dar lugar a una larga duración de la consulta.
Entre los comportamientos de las consultas que pueden reducir el paralelismo se incluyen los siguientes:
Uso de las funciones de ventana y serialización, como serialize operator, next(), prev() y row. Las funciones de
análisis de usuario y serie temporal pueden usarse en algunos de estos casos. También puede producirse una
serialización ineficaz si los siguientes operadores no se usan al final de la consulta: range, sort, order, top, top-
hitters, getschema.
El uso de la función de agregación dcount() obliga al sistema a tener una copia central de los distintos valores.
Cuando la escala de datos es alta, considere la posibilidad de usar los parámetros opcionales de la función
dcount para reducir la precisión.
En muchos casos, el operador join reduce el paralelismo general. Considere la combinación de orden
aleatorio como alternativa cuando el rendimiento sea problemático.
En las consultas con ámbito de recurso, las comprobaciones de ejecución previa de RBAC pueden perdurar en
situaciones en las que hay un gran número de asignaciones de rol de Azure. Esto puede provocar
comprobaciones más largas, lo que generaría un paralelismo más bajo. Por ejemplo, una consulta se ejecuta
en una suscripción en la que hay miles de recursos y cada recurso tiene varias asignaciones de roles en el
nivel de recurso, no en la suscripción ni en el grupo de recursos.
Si una consulta está procesando fragmentos de datos pequeños, su paralelismo será inferior, ya que el
sistema no se propagará en muchos nodos de ejecución.
Pasos siguientes
Documentación de referencia del lenguaje de consulta de Kusto.
Análisis de datos de texto en registros de Azure
Monitor
Algunos datos de registro recopilados por Azure Monitor incluyen varios fragmentos de información en una sola
propiedad. El análisis de estos datos en varias propiedades facilita su uso en las consultas. Un ejemplo común es
un registro personalizado que recopila una entrada de registro completo con varios valores en una sola
propiedad. Al crear propiedades independientes para los distintos valores, puede buscar y agregar en cada uno.
En este artículo se describen distintas opciones para analizar los datos de Azure Monitor cuando estos se ingieren
y cuando se recuperan en una consulta, y se comparan las ventajas relativas para cada uno.
Análisis de métodos
Puede analizar los datos ya sea en el momento de la ingesta cuando se recopilan o bien al realizar la consulta
cuando los datos se analizan con una consulta. Cada estrategia tiene unas ventajas únicas, como se describe a
continuación.
Análisis de los datos en el momento de la recopilación
Cuando se analizan los datos en el momento de la recopilación, se configuran campos personalizados que crean
nuevas propiedades en la tabla. Las consultas no tienen que incluir ninguna lógica de análisis y simplemente se
usan estas propiedades como cualquier otro campo de la tabla.
Las ventajas que presenta este método son, entre otras:
Facilita la consulta de los datos recopilados, ya que no es necesario incluir en ella comandos de análisis.
Mejor rendimiento de las consultas dado que no precisan llevar a cabo el análisis.
Las desventajas que presenta este método son, entre otras:
Deben definirse de antemano. No puede incluir datos que ya se hayan recopilado.
Si cambia la lógica de análisis, solo se aplicará a los nuevos datos.
Menos opciones de análisis de las disponibles en las consultas.
Aumenta el tiempo de latencia para la recopilación de datos.
Los errores pueden resultar difíciles de controlar.
Análisis de los datos en el momento de la consulta
Cuando se analizan los datos al realizar las consultas, se incluye la lógica en la consulta para analizar los datos de
varios campos. No se modifica la propia tabla.
Las ventajas que presenta este método son, entre otras:
Se aplica a los datos, incluidos los que ya se han recopilado.
Los cambios en la lógica se pueden aplicar inmediatamente a todos los datos.
Opciones flexibles de opciones que incluyen la lógica predefinida para estructuras de datos determinadas.
Las desventajas que presenta este método son, entre otras:
Requiere las consultas más complejas. Esto se puede mitigar mediante el uso de funciones para simular una
tabla.
La lógica de análisis se debe replicar en varias consultas. Se puede compartir cierta lógica mediante funciones.
Puede crear una sobrecarga al ejecutar una lógica compleja en conjuntos de registros muy grandes (miles de
millones).
Los datos se analizan a medida que se recopilan.

Consulte Creación de campos personalizados en Azure Monitor para obtener más información sobre el análisis
de datos a medida que se recopilan. De esta forma se crean propiedades personalizadas en la tabla que las
consultas pueden usar como cualquier otra propiedad.
Análisis de los datos en consultas con patrones

Cuando los datos que desea analizar pueden identificarse mediante un patrón que se repite en todos los
registros, puede usar distintos operadores en el lenguaje de consulta de Kusto para extraer un dato específico de
una o varias propiedades nuevas.
Patrones de texto simple
Use el operador parse en la consulta para crear una o varias propiedades personalizadas que se puedan extraer
de una expresión de cadena. Especifique el patrón de identificación y los nombres de las propiedades que se van
a crear. Esto es especialmente útil para los datos con pares clave-valor de cadenas con un formato similar a
clave=valor.
Considere un registro personalizado con datos en el formato siguiente.
Time=2018-03-10 01:34:36 Event Code=207 Status=Success Message=Client 05a26a97-272a-4bc9-8f64-269d154b0e39

connected
Time=2018-03-10 01:33:33 Event Code=208 Status=Warning Message=Client ec53d95c-1c88-41ae-8174-92104212de5d
disconnected
Time=2018-03-10 01:35:44 Event Code=209 Status=Success Message=Transaction 10d65890-b003-48f8-9cfc-
9c74b51189c8 succeeded
Time=2018-03-10 01:38:22 Event Code=302 Status=Error Message=Application could not connect to database
Time=2018-03-10 01:31:34 Event Code=303 Status=Error Message=Application lost connection to database
La consulta siguiente analizaría estos datos en propiedades individuales. Se agrega la línea con project para
devolver solo las propiedades calculadas y no RawData, que es la única propiedad que contiene toda la entrada
del registro personalizado.
MyCustomLog_CL
| parse RawData with * "Time=" EventTime " Event Code=" Code " Status=" Status " Message=" Message
| project EventTime, Code, Status, Message
El siguiente es otro ejemplo que divide el nombre de usuario de un nombre principal de usuario en la tabla
AzureActivity.
AzureActivity
| parse Caller with UPNUserPart "@" *
| where UPNUserPart != "" //Remove non UPN callers (apps, SPNs, etc)
| distinct UPNUserPart, Caller
Expresiones regulares
Si los datos se pueden identificar con una expresión regular, puede usar funciones que usan expresiones
regulares para extraer los valores individuales. En el ejemplo siguiente, se usa extract para separar el campo UPN
de los registros AzureActivity y, a continuación, devolver usuarios distintos.
AzureActivity
| extend UPNUserPart = extract("([a-z.]*)@", 1, Caller)
| distinct UPNUserPart, Caller
Para habilitar un análisis eficiente a gran escala, Azure Monitor utiliza la versión re2 de Expresiones regulares, que
es similar, pero no idéntica a algunas de las otras variantes de las expresiones regulares. Consulte la sintaxis de
las expresiones re2 para obtener más información.
Análisis de datos delimitados en una consulta

Los datos delimitados separan los campos con un carácter común, como una coma, en un archivo CSV. Use la
función split para analizar los datos delimitados con el delimitador que especifique. Puede utilizarlo con el
operador extend para devolver todos los campos de los datos o para especificar los campos individuales que se
incluirán en la salida.
NOTE
Dado que split devuelve un objeto dinámico, es posible que los resultados tengan que convertirse explícitamente a un tipo
de datos como es el tipo cadena para usarse en los operadores y en los filtros.
Considere un registro personalizado con datos en el formato CSV siguiente.
2018-03-10 01:34:36, 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected

2018-03-10 01:33:33, 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2018-03-10 01:35:44, 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2018-03-10 01:38:22, 302,Error,Application could not connect to database
2018-03-10 01:31:34, 303,Error,Application lost connection to database
La consulta siguiente analizaría estos datos y los resumiría en dos según las propiedades calculadas. La primera
línea divide la propiedad RawData en una matriz de cadena. Cada una de las siguientes líneas da nombre a
propiedades individuales y las agrega a la salida usando funciones para convertirlas al tipo de datos adecuado.
MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend EventTime = todatetime(CSVFields[0])
| extend Code = toint(CSVFields[1])
| extend Status = tostring(CSVFields[2])
| extend Message = tostring(CSVFields[3])
| where getyear(EventTime) == 2018
| summarize count() by Status,Code
Análisis de estructuras predefinidas en una consulta

Si se da formato a los datos en una estructura conocida, es posible que se pueda usar una de las funciones en el
lenguaje de consulta de Kusto para analizar las estructuras predefinidas:
JSON
XML
IPv4
URL
Consulta URL
Ruta de acceso del archivo
Agente de usuario
Cadena de versión
En la consulta de ejemplo siguiente, se analiza el campo Properties (Propiedades) de la tabla AzureActivity
(Actividad de Azure), que se estructura en JSON. Guarda los resultados en una propiedad dinámica denominada
parsedProp, que incluye el valor con el nombre individual en JSON. Estos valores se usan para filtrar y resumir
los resultados de la consulta.
AzureActivity
| extend parsedProp = parse_json(Properties)
| where parsedProp.isComplianceCheck == "True"
| summarize count() by ResourceGroup, tostring(parsedProp.tags.businessowner)
Estas funciones de análisis pueden utilizar en gran medida el procesador, por lo que deben usarse solo cuando la
consulta emplee varias propiedades de los datos con formato. En caso contrario, el simple procesamiento de la
coincidencia de patrones será más rápido.
En el ejemplo siguiente se muestra el desglose del tipo de autenticación previa de TGT para el controlador de
dominio. El tipo existe solo en el campo EventData, que es una cadena XML, pero no ningún otro dato de este
campo es necesario. En este caso, se usa parse para seleccionar el elemento de datos requerido.
SecurityEvent
| parse EventData with * 'PreAuthType">' PreAuthType '</Data>' *
| summarize count() by PreAuthType
Uso de la función para simular una tabla

Puede tener varias consultas que realizan el mismo análisis de una tabla determinada. En este caso, cree una
función que devuelva los datos analizados, en lugar de replicar la lógica de análisis en cada consulta. A
continuación, puede utilizar el alias de función en lugar de la tabla original en otras consultas.
Considere el ejemplo de registro personalizado delimitado por comas anterior. Para poder usar los datos
analizados en varias consultas, cree una función con la consulta siguiente y guárdela con el alias
MyCustomCSVLog.
MyCustomCSVLog_CL
| extend CSVFields = split(RawData, ',')
| extend DateTime = tostring(CSVFields[0])
| extend Code = toint(CSVFields[1])
| extend Status = tostring(CSVFields[2])
| extend Message = tostring(CSVFields[3])
Ahora puede usar el alias MyCustomCSVLog en lugar del nombre de tabla real en consultas similares a la
siguiente.
MyCustomCSVLog
| summarize count() by Status,Code
Pasos siguientes
orígenes de datos.
Diseño de la implementación de registros de
Azure Monitor
Azure Monitor almacena los datos de registro en un área de trabajo de Log Analytics, que es un recurso de
Azure y un contenedor en el que los datos se recopilan y se agregan, y que sirve como límite administrativo.
Aunque puede implementar una o varias áreas de trabajo en su suscripción de Azure, hay varios aspectos
que debe comprender para asegurarse de que la implementación inicial sigue nuestras instrucciones con el
fin de que resulte una implementación rentable, fácil de administrar y escalable que satisfaga las
necesidades de su organización.
En las áreas de trabajo, los datos se organizan en tablas, cada una de las cuales almacena distintos tipos de
datos y tiene su conjunto exclusivo de propiedades según el recurso que genere los datos. En un área de
trabajo Log Analytics, la mayoría de los orígenes de datos escribirán en sus propias tablas.
Un área de trabajo de Log Analytics proporciona lo siguiente:

Una ubicación geográfica para el almacenamiento de datos.
Aislamiento de datos, ya que se conceden diferentes derechos de acceso a los usuarios en base a una de
nuestras estrategias de diseño recomendadas.
Ámbito para la configuración de opciones, como el plan de tarifa, la retención y el límite de datos.
En este artículo se proporciona información general detallada acerca de las consideraciones de diseño y
migración, información general sobre el control de acceso y una descripción de las implementaciones de
diseño que recomendamos para su organización de TI.
Consideraciones importantes para una estrategia de control de
acceso
La identificación del número de áreas de trabajo que necesita se ve afectada por uno o varios de los
siguientes requisitos:
Una empresa internacional que necesita que los datos de registro estén almacenados en regiones
concretas por motivos de soberanía de datos o cumplimiento normativo.
Un usuario de Azure que desea evitar los gastos de transferencia de datos de salida manteniendo un área
de trabajo en la misma región que los recursos de Azure que administra.
Administra varios departamentos o grupos de negocio y desea que cada uno de ellos vea sus propios
datos, pero no los de los demás. Además, no hay ningún requisito empresarial para las vistas
consolidadas entre los distintos grupos de negocio o departamentos.
En la actualidad, las organizaciones de TI siguen modelos centralizados, descentralizados o usan una
estructura híbrida. Como resultado, los siguientes modelos de implementación de áreas de trabajo se han
usado normalmente para asignarse a una de estas estructuras organizativas:
Centralizado : todos los registros se almacenan en un área de trabajo central y los administra un único
equipo, y Azure Monitor proporcionar un acceso diferenciado por equipo. En este escenario, es fácil
administrar, buscar en los recursos y correlacionar registros entre ellos. El área de trabajo puede crecer
considerablemente en función de la cantidad de datos recopilados de varios recursos de la suscripción, lo
que genera una sobrecarga administrativa adicional para mantener el control del acceso de los distintos
usuarios. Este modelo se conoce como "concentrador y radio".
Descentralizado : cada equipo tiene su propia área de trabajo creada en un grupo de recursos que
poseen y administran, y los datos de registro se segregan por recurso. En este escenario, el área de
trabajo se puede mantener seguro y el control de acceso es coherente con el acceso de los recursos, pero
es difícil correlacionar los registros. Los usuarios que necesitan una visión amplia de muchos recursos no
pueden analizar los datos de forma significativa.
Híbrido : los requisitos de cumplimiento de auditorías de seguridad complican aún más este escenario,
ya que muchas organizaciones implementan ambos modelos de implementación en paralelo.
Habitualmente, esto genera una configuración compleja, cara y difícil de mantener con brechas en la
cobertura de los registros.
Si se usan los agentes de Log Analytics para recopilar datos, es preciso conocer lo siguiente para planear la
implementación de los agentes:
Para recopilar datos de los agentes de Windows, puede configurar cada agente para que informe a una o
varias áreas de trabajo, aun cuando informen a un grupo de administración de System Center Operations
Manager. El agente de Windows puede notificar hasta cuatro áreas de trabajo.
El agente de Linux no admite el hospedaje múltiple y solo puede informar a un área de trabajo.
Si usa System Center Operations Manager 2012 R2, o cualquier versión posterior:
Cada grupo de administración de Operations Manager se puede conectar a una sola área de trabajo.
Los equipos Linux que informan a un grupo de administración deben estar configurados para informar
directamente a un área de trabajo Log Analytics. Si los equipos Linux ya están notificando directamente a
un área de trabajo y desea supervisarlos con Operations Manager, siga estos para notificar a un grupo de
administración de Operations Manager.
El agente de Windows de Log Analytics se puede instalar en el equipo Windows y se le puede indicar que
informe tanto a Operations Manager integrado con un área de trabajo como a otra área de trabajo.
Introducción al control de acceso

Con el control de acceso basado en rol (RBAC) puede conceder a los usuarios y grupos solo la cantidad de
acceso que necesitan para trabajar con los datos de supervisión en un área de trabajo. Esto le permite
alinearse con el modelo de funcionamiento de la organización de TI mediante el uso de una sola área de
trabajo para almacenar los datos recopilados habilitada en todos los recursos. Por ejemplo, puede conceder
acceso al equipo responsable de los servicios de infraestructura hospedados en máquinas virtuales (VM) de
Azure y, como consecuencia, este equipo solo tendrá acceso a los registros que hayan generados las
máquinas virtuales. Esto sigue nuestro nuevo modelo de registro del contexto de recursos. La base de este
modelo es que cada entrada de registro que emite un recurso de Azure se asocia automáticamente con este
recurso. Los registros se reenvían a un área de trabajo central que respeta el ámbito y el RBAC en función de
los recursos.
Los datos a los que un usuario tiene acceso vienen determinados por una combinación de factores que se
enumeran en la tabla siguiente. Cada uno se describe en las secciones siguientes.
FA C TO R DESC RIP C IÓ N
Modo de acceso Método que utiliza el usuario para acceder al área de

trabajo. Define el ámbito de los datos disponibles y el
modo de control de acceso que se aplica.
Modo de control de acceso Configuración en el área de trabajo que define si los

permisos se aplican en el nivel de área de trabajo o
recurso.
Permisos Permisos aplicados a individuales o grupos de usuarios

para el área de trabajo o el recurso. Define los datos a los
que el usuario tendrá acceso.
RBAC de nivel de tabla Permisos granulares opcionales que se aplican a todos los
usuarios independientemente de su modo de acceso o su
modo de control de acceso. Define a qué tipos de datos
puede tener acceso un usuario.
Modo de acceso
El modo de acceso hace referencia a cómo un usuario accede a un área de trabajo de Log Analytics y define
el ámbito de datos al que puede tener acceso.
Los usuarios tienen dos opciones para acceder a los datos:
Contexto del área de trabajo : puede ver todos los registros del área de trabajo para la que tiene
permiso. Las consultas en este modo se limitan a todos los datos de todas las tablas en el área de
trabajo. Este es el modo de acceso utilizado cuando se accede a los registros con el área de trabajo
como ámbito, como cuando se selecciona Registros desde el menú Azure Monitor en Azure Portal.
Contexto del recurso : al acceder al área de trabajo para un recurso, un grupo de recursos o una
suscripción determinados (por ejemplo, cuando se selecciona Registros en un menú de recursos de
Azure Portal), puede ver los registros solo de los recursos de todas las tablas a las que tiene acceso.
Las consultas de este modo se limitan solo a los datos asociados a ese recurso. Este modo también
permite el RBAC pormenorizado.
NOTE
Solo hay registros disponibles para las consultas de contexto del recurso si se asociaron correctamente al
recurso pertinente. Actualmente, los siguientes recursos tienen limitaciones:
Equipos fuera de Azure
Service Fabric
Para probar si los registros están asociados correctamente con su recurso, puede ejecutar una consulta e
inspeccionar los que le interesen. Si el identificador de recurso correcto se encuentra en la propiedad
_ResourceId, los datos están disponibles para las consultas basadas en el recurso.
Azure Monitor determina automáticamente el modo correcto en función del contexto desde el que se realiza
la búsqueda de registros. El ámbito siempre se presenta en la sección superior izquierda de Log Analytics.
Comparación de los modos de acceso
En la tabla siguiente se resumen los modos de acceso:
IN C IDEN C IA C O N T EXTO DEL Á REA DE T RA B A JO C O N T EXTO DEL REC URSO
¿Para quién está pensado cada Administración central. Los Equipos de la aplicación. Los
modelo? administradores que tienen que administradores de los recursos de
configurar colecciones de datos y los Azure que se están supervisando.
usuarios que necesitan acceder a una
amplia variedad de recursos. También
lo requieren actualmente los usuarios
que necesitan acceder a registros de
recursos fuera de Azure.
¿Qué requiere un usuario para ver los Permisos para el área de trabajo. Vea Acceso de lectura al recurso. Vea los
registros? los permisos del área de trabajo permisos de los recursos en
en Administración del acceso Administración del acceso mediante
mediante los permisos del área de los permisos de Azure. Los permisos
trabajo. pueden ser heredados (por ejemplo,
del grupo de recursos que los
contenga) o son asignados
directamente al recurso. Se asignará
automáticamente el permiso a los
registros para el recurso.
¿Qué es el ámbito de los permisos? Área de trabajo. Los usuarios con Recurso de Azure. Un usuario puede
acceso al área de trabajo pueden consultar los registros de recursos,
consultar todos los registros de esa grupos de recursos o suscripciones
área de trabajo desde las tablas para específicos a los que tenga acceso
las que tengan permisos. Consulte desde cualquier área de trabajo, pero
Control de acceso a la tabla no puede consultar los registros de
otros recursos.
IN C IDEN C IA C O N T EXTO DEL Á REA DE T RA B A JO C O N T EXTO DEL REC URSO
¿Cómo puede el usuario acceder a los Inicie Registros en el menú Inicie Registros en el menú
registros de acceso? de Azure Monitor . para el recurso de Azure
Inicie Registros desde Áreas Inicie Registros en el menú
de trabajo de Log de Azure Monitor .
Analytics .
Inicie Registros desde Áreas
Desde Libros de Azure de trabajo de Log
Monitor. Analytics .
Desde Libros de Azure
Monitor.
Modo de control de acceso

Modo de control de acceso es un valor que se encuentra en todas las áreas de trabajo y que define cómo se
determinan los permisos para el área de trabajo.
Requerir permisos de área de trabajo : este modo de control no admite RBAC granular. Para que
un usuario pueda acceder al área de trabajo, debe tener permisos en el área de trabajo o en tablas
específicas.
Si un usuario accede al área de trabajo en el modo de contexto del área de trabajo, tendrá acceso a
todos los datos de todas las tablas a las que se le haya concedido acceso. Si un usuario accede al área
de trabajo en el modo de contexto del recurso, tendrá acceso solo a los datos de ese recurso en todas
las tablas a las que se le haya concedido acceso.
Se trata de la configuración predeterminada para todas las áreas de trabajo creadas antes de marzo
de 2019.
Usar permisos de recurso o de área de trabajo : este modo de control permite RBAC granular. A
los usuarios se les puede conceder acceso solo a los datos asociados a los recursos que pueden ver
mediante la asignación del permiso read de Azure.
Cuando un usuario accede al área de trabajo en modo contexto del área de trabajo, se aplican los
permisos del área de trabajo. Cuando un usuario accede al área de trabajo en modo contexto del
recurso, solo se comprueban los permisos de los recursos y se omiten los del área de trabajo. Para
habilitar RBAC para un usuario, quítelos de los permisos del área de trabajo y permita que sus
permisos de recursos sean reconocidos.
Se trata de la configuración predeterminada para todas las áreas de trabajo creadas después de
marzo de 2019.
NOTE
Si un usuario solo tiene permisos de recurso en el área de trabajo, solo podrá acceder al área de trabajo
mediante el modo contexto del recurso, siempre que el modo de acceso al área de trabajo esté establecido en
Usar permisos de recurso o de área de trabajo .
Para obtener información sobre cómo cambiar el modo de control de acceso en el portal, con PowerShell o
mediante una plantilla de Resource Manager, vea Configuración del modo de control de acceso.
Límite de velocidad por volumen de ingesta

Azure Monitor es un servicio de datos a gran escala que atiende a miles de clientes que envían terabytes de
datos cada mes a un ritmo creciente. Lo que se pretende con el límite de velocidad de volumen es evitar que
los clientes de Azure Monitor tengan de picos de ingesta repentinos en entornos con varios inquilinos. En las
áreas de trabajo se define un umbral de velocidad de volumen de ingesta de datos de 500 MB
(comprimidos), lo que se traduce en, aproximadamente, 6 GB/min sin comprimir (el tamaño real puede
variar entre los tipos de datos en función de la longitud del registro y su relación de compresión). El límite de
velocidad de volumen se aplica a todos los datos ingeridos, tanto si se envían desde recursos de Azure
mediante la Configuración de diagnóstico, Data Collector API o agentes.
Cuando se envían datos a un área de trabajo a una velocidad superior al 80 % del umbral configurado en el
área de trabajo, se envía un evento a la tabla Operación del área de trabajo cada 6 horas mientras se siga
superando el umbral. Cuando la velocidad de ingesta del volumen supera el umbral, se quitan algunos datos
y se envía un evento a la tabla Operación del área de trabajo cada 6 horas mientras se siga superando el
umbral. Si la velocidad de ingesta sigue superando el umbral o prevé que lo va a alcanzar pronto, puede
abrir una solicitud de soporte técnico para solicitar su aumento.
Para recibir una notificación tanto si se acerca al límite de ingesta de datos del volumen del área de trabajo
como si lo ha alcanzado, cree una regla de alerta de registro mediante la siguiente consulta cuya base lógica
de alerta sea el número de resultados mayores que cero, un período de evaluación de 5 minutos y una
frecuencia de 5 minutos.
La velocidad de ingesta del volumen ha alcanzado el 80 % del umbral:
Operation
|where OperationCategory == "Ingestion"
|where Detail startswith "The data ingestion volume rate crossed 80% of the threshold"
La velocidad de ingesta del volumen ha alcanzado el umbral:
Operation
|where OperationCategory == "Ingestion"
|where Detail startswith "The data ingestion volume rate crossed the threshold"
Recomendaciones
En este escenario se trata un diseño de un área de trabajo único de la suscripción de una organización de TI
que no está restringido por la soberanía de los datos ni por el cumplimiento normativo, o bien que debe
asignarse a las regiones en las que se implementan los recursos. Brinda a los equipos de administración de
seguridad y de TI de la organización la posibilidad de sacar provecho de la integración mejorada con la
administración del acceso de Azure y un control del acceso más seguro.
Todos los recursos, las soluciones de supervisión y la información, como Application Insights y Azure
Monitor para VM, que dan soporte tanto a la infraestructura como a las aplicaciones que mantienen los
diferentes equipos están configurados para reenviar los datos de registro que recopilan al área de trabajo
compartida centralizada de las organizaciones de TI. A los usuarios de cada equipo se les concede acceso a
los registros de los recursos a los que se les ha dado acceso.
Una vez que haya implementado la arquitectura del área de trabajo, puede aplicarla a los recursos de Azure
con Azure Policy. Proporciona una forma de definir directivas y garantizar el cumplimiento de los recursos
de Azure para que envíen todos los registros de recursos a un área de trabajo específica. Por ejemplo, en el
caso de las máquinas virtuales de Azure o los conjuntos de escalado de máquinas virtuales, puede usar las
directivas existentes que evalúan el cumplimiento del área de trabajo y los resultados de los informes, o bien
personalizarlas para tomas las medidas necesarias si no lo cumplen.
Estrategia de migración de la consolidación de áreas de trabajo

En el caso de los clientes que ya han implementado varias áreas de trabajo y están interesados en consolidar
el modelo de acceso de contexto del recurso, se recomienda adoptar un enfoque incremental para migrar al
modelo de acceso recomendado y no intentar hacerlo de forma rápida o agresiva. Seguir un enfoque por
fases para realizar el planeamiento, la migración, la validación y la retirada siguiendo una escala de tiempo
razonable ayudará a evitar incidentes no planeado o un impacto inesperado en las operaciones en la nube. Si
no tiene una directiva de retención de datos por motivos empresariales o de cumplimiento, debe evaluar el
período adecuado durante el que se deben conservar los datos en el área de trabajo desde la que va a
realizar la migración durante el proceso. Mientras reconfigura los recursos para informar al área de trabajo
compartida, puede analizar los datos del área de trabajo original según sea necesario. Una vez completada la
migración, si se deben conservar los datos en el área de trabajo original antes del final del período de
retención, no los elimine.
Al planear la migración a este modelo, tenga en cuenta lo siguiente:
Sepa qué normativas del sector y directivas internas relativas a la retención de datos debe cumplir.
Asegúrese de que los equipos de aplicaciones pueden trabajar en la funcionalidad de contexto del recurso
existente.
Identifique el acceso concedido a los recursos de los equipos de aplicaciones y haga las pruebas
necesarias en un entorno de desarrollo antes de realizar la implementación en producción.
Configure el área de para habilitar Usar permisos de recurso o de área de trabajo .
Retire a los equipos de aplicaciones el permiso para leer y consultar el área de trabajo.
Habilite y configure las soluciones de supervisión, información como Azure Monitor para contenedores o
Azure Monitor para VM, las cuentas de Automation y las soluciones de administración como Update
Management, iniciar o detener máquinas virtuales, etc., que se implementaron en el área de trabajo
original.
Pasos siguientes
Para implementar los permisos y controles de seguridad que se recomiendan en esta guía, consulte el
artículo relativo a la administración del acceso a los registros.
en Azure Portal
Use el menú Áreas de trabajo de Log Analytics para crear un área de trabajo de Log Analytics con Azure
Portal. Un área de trabajo de Log Analytics es un entorno único de datos de registro de Azure Monitor. Cada
área de trabajo tiene su propio repositorio de datos y configuración, y las soluciones y orígenes de datos
están configurados para almacenar sus datos en una determinada área de trabajo. Necesitará un área de
trabajo de Log Analytics si tiene intención de recopilar datos de los orígenes siguientes:
Recursos de Azure de la suscripción
Equipos locales supervisados por System Center Operations Manager
Colecciones de dispositivos de Configuration Manager
Datos de diagnóstico o de registro de Azure Storage
Para otros orígenes, como las máquinas virtuales de Azure y la máquinas virtuales Windows o Linux del
entorno, consulte los temas siguientes:
Recopilación de datos de máquinas virtuales de Azure
Recopilación de datos de un equipo Linux híbrido
Recopilación de datos de un equipo Windows híbrido


1. En Azure Portal, haga clic en Todos los ser vicios . En la lista de recursos, escriba Log Analytics .
Cuando comience a escribir, la lista se filtrará en función de la entrada. Seleccione Áreas de trabajo
de Log Analytics .
2. Haga clic en Agregar y, después, seleccione las opciones de los siguientes elementos:
DefaultLAWorkspace. Este nombre debe ser único globalmente en todas las suscripciones de
Azure Monitor.
Seleccione una suscripción a la que vincularlo en la lista desplegable si la opción
predeterminada seleccionada no es adecuada.
Como Grupo de recursos puede usar un grupo de recursos existente que ya esté
configurado, o crear uno nuevo.
Seleccione una ubicación disponible. Para obtener información, consulte las regiones en las
que Log Analytics está disponible y busque Azure Monitor desde el campo Buscar un
producto .
Si va a crear un área de trabajo en una nueva suscripción creada después del 2 de abril de
2018, esta utilizará automáticamente el plan de precios Por GB y la opción para seleccionar un
plan de tarifas no estará disponible. Si va a crear un área de trabajo para una suscripción
existente creada antes del 2 de abril o para una suscripción asociada a una inscripción de
Contrato Enterprise (EA) existente, seleccione el plan de tarifa que prefiera. Para más
información sobre planes concretos, consulte los detalles de precios de Log Analytics.

haga clic en Aceptar .
Al crear un área de trabajo que se eliminó en los últimos 14 días y en estado de eliminación temporal, la
operación podría tener un resultado diferente en función de la configuración del área de trabajo:
1. Si proporciona el mismo nombre de área de trabajo, grupo de recursos, suscripción y región que en el
área de trabajo eliminado, se recuperará el área de trabajo, incluidos los datos, la configuración y los
agentes conectados.
2. Si usa el mismo nombre de área de trabajo, pero un grupo de recursos, una suscripción o una región
diferentes, obtendrá un error El nombre del área de trabajo ya esta en uso. Pruebe otro. Para invalidar la
eliminación temporal y eliminar inmediatamente el área de trabajo y crear una con el mismo nombre,
siga estos pasos para recuperar el área de trabajo primero y realizar una eliminación permanente:
Recuperar el área de trabajo
Eliminación permanente del área de trabajo
Crear una nueva área de trabajo con el mismo nombre
Pasos siguientes
Ahora que tiene un área de trabajo disponible, puede configurar la recopilación de datos de telemetría de
supervisión, realizar búsquedas en el registro para analizar dichos datos y agregar una solución de
administración que proporcione datos adicionales e información de los análisis.
Para habilitar la recopilación de datos de recursos de Azure con Azure Diagnostics o Azure Storage,
consulte Recopilación de registros y métricas de Azure para servicios de Log Analytics.
Agregue System Center Operations Manager como origen de datos para recopilar datos de agentes que
informan a su grupo de administración de Operations Manager y almacenarlos en el repositorio del área
de trabajo de Log Analytics.
Conecte Configuration Manager para importar equipos que son miembros de colecciones en la jerarquía.
Revise las soluciones de supervisión disponibles y cómo agregar o quitar una solución del área de
trabajo.
Creación de un área de trabajo de Log Analytics con
la CLI de Azure 2.0
La CLI de Azure 2.0 se usa para crear y administrar recursos de Azure desde la línea de comandos o en scripts. En
esta guía de inicio rápido se muestra cómo usar la CLI de Azure 2.0 para implementar un área de trabajo de Log
Analytics en Azure Monitor. Un área de trabajo de Log Analytics es un entorno único de datos de registro de Azure
Monitor. Cada área de trabajo tiene su propio repositorio de datos y configuración, y las soluciones y orígenes de
datos están configurados para almacenar sus datos en una determinada área de trabajo. Necesitará un área de
trabajo de Log Analytics si tiene intención de recopilar datos de los orígenes siguientes:
Recursos de Azure de la suscripción
Equipos locales supervisados por System Center Operations Manager
Colecciones de dispositivos de Configuration Manager
Datos de diagnóstico o registro de Azure Storage
Para otros orígenes, como las máquinas virtuales de Azure y la máquinas virtuales Windows o Linux del entorno,
consulte los temas siguientes:
Recopilación de datos de máquinas virtuales de Azure
Recopilación de datos de un equipo Linux híbrido
Recopilación de datos de un equipo Windows híbrido
Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:
O P C IÓ N E JEM P LO O VÍN C ULO
Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI en un entorno local, en esta guía de inicio rápido es preciso que ejecute la versión
2.0.30 de la CLI de Azure o una posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o
actualizarla, consulte Instalación de la CLI de Azure 2.0.

Cree un área de trabajo con az group deployment create. En el ejemplo siguiente se creará un área de trabajo en la
ubicación Este de EE. UU. mediante una plantilla de Resource Manager desde la máquina local. La plantilla JSON
está configurada para solicitar solo el nombre del área de trabajo y especifica un valor predeterminado para los
restantes parámetros que es probable que se utilice como configuración estándar en su entorno. O bien, puede
almacenar la plantilla en una cuenta de Azure Storage para el acceso compartido en su organización. Para más
información sobre cómo trabajar con plantillas, consulte Implementación de recursos con plantillas de Resource
Manager y la CLI de Azure.
Para obtener información sobre las regiones compatibles, consulte las regiones en las que Log Analytics está
disponible y busque Azure Monitor desde el campo Buscar un producto .
Los siguientes parámetros establecen un valor predeterminado:
Ubicación: el valor predeterminado es Este de EE. UU.
SKU: el valor predeterminado es el nuevo plan de tarifa por GB publicado en el modelo de precios de abril de
2018
WARNING
Si se crea o configura un área de trabajo de Log Analytics en una suscripción que ha elegido el nuevo modelo de precios de
abril de 2018, el único plan de tarifa válido de Log Analytics es PerGB2018 .
Creación e implementación de una plantilla

1. Copie y pegue la siguiente sintaxis JSON en el archivo:
{
"$schema": "https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#",
"parameters": {
"workspaceName": {
"type": "String",
"metadata": {
"description": "Specifies the name of the workspace."
}
},
"location": {
"type": "String",
"allowedValues": [
"eastus",
"westus"
],
"defaultValue": "eastus",
"metadata": {
}
},
"sku": {
"type": "String",
"allowedValues": [
"Standalone",
"PerNode",
"PerGB2018"
],
"defaultValue": "PerGB2018",
"metadata": {
"description": "Specifies the service tier of the workspace: Standalone, PerNode, Per-GB"
}
}
},
"resources": [
{
"properties": {
"sku": {
"Name": "[parameters('sku')]"
},
"features": {
"searchVersion": 1
}
}
}
]
}
2. Edite la plantilla para adecuarla a sus requisitos. Consulte la referencia Plantilla

Microsoft.OperationalInsights/workspaces para saber qué propiedades y valores son compatibles.
3. Guarde este archivo como deploylaworkspacetemplate.json en una carpeta local.
4. Está listo para implementar esta plantilla. Use los siguientes comandos desde la carpeta que contiene la
plantilla. Cuando se le pida un nombre de área de trabajo, proporcione un nombre que sea globalmente
único en todas las suscripciones de Azure.
az group deployment create --resource-group <my-resource-group> --name <my-deployment-name> --template-

file deploylaworkspacetemplate.json
La implementación puede demorar unos minutos en completarse. Cuando termine, verá un mensaje similar al
siguiente que incluye el resultado:
Al crear un área de trabajo que se eliminó en los últimos 14 días y en estado de eliminación temporal, la operación
podría tener un resultado diferente en función de la configuración del área de trabajo:
1. Si proporciona el mismo nombre de área de trabajo, grupo de recursos, suscripción y región que en el área de
trabajo eliminado, se recuperará el área de trabajo, incluidos los datos, la configuración y los agentes
conectados.
2. Si usa el mismo nombre de área de trabajo, pero un grupo de recursos, una suscripción o una región
diferentes, obtendrá un error El nombre del área de trabajo "nombre del área de trabajo" no es único o causa
conflicto. Para invalidar la eliminación temporal y eliminar inmediatamente el área de trabajo y crear una con el
mismo nombre, siga estos pasos para recuperar el área de trabajo primero y realizar una eliminación
permanente:
Pasos siguientes
Ahora que tiene un área de trabajo disponible, puede configurar la recopilación de datos de telemetría de
supervisión, realizar búsquedas en el registro para analizar dichos datos y agregar una solución de administración
que proporcione datos adicionales e información de los análisis.
Para habilitar la recopilación de datos de recursos de Azure con Azure Diagnostics o Azure Storage, consulte
Recopilación de registros y métricas de Azure para servicios de Log Analytics.
Agregue System Center Operations Manager como origen de datos para recopilar datos de agentes que
informan a su grupo de administración de Operations Manager y almacenarlos en el repositorio del área de
Conecte Configuration Manager para importar equipos que son miembros de colecciones en la jerarquía.
Revise las soluciones de supervisión disponibles y cómo agregar o quitar una solución del área de trabajo.
Crear y configurar el área de trabajo de Log Analytics en Azure Monitor con
PowerShell
En este artículo se proporcionan dos ejemplos de código que muestran cómo crear y configurar un área de trabajo de Log Analytics en Azure Monitor.
NOTE
Log Analytics se llamaba anteriormente Operational Insights, razón por la cual se utiliza este nombre en los cmdlets.
Prerrequisitos
Estos ejemplos funcionan con la versión 1.0.0 o posterior del módulo Az.OperationalInsights.
Creación del espacio de trabajo

El script de ejemplo siguiente crea un área de trabajo sin configuración de origen de datos.
$ResourceGroup = "my-resource-group"
$WorkspaceName = "log-analytics-" + (Get-Random -Maximum 99999) # workspace names need to be unique across all Azure subscriptions - Get-Random helps with this
for the example code
$Location = "westeurope"
# Create the resource group if needed

try {
Get-AzResourceGroup -Name $ResourceGroup -ErrorAction Stop
} catch {
New-AzResourceGroup -Name $ResourceGroup -Location $Location
}
# Create the workspace

New-AzOperationalInsightsWorkspace -Location $Location -Name $WorkspaceName -Sku Standard -ResourceGroupName $ResourceGroup
Crear área de trabajo y configurar orígenes de datos

En el ejemplo de script de ejemplo siguiente se crea un área de trabajo y se configuran varios orígenes de datos. Estos orígenes de datos solo son necesarios si va a
supervisar máquinas virtuales mediante el agente de Log Analytics.
Este script realiza las siguientes funciones:
1. Crear un área de trabajo
2. Enumerar las soluciones disponibles
3. Agregar soluciones al área de trabajo
4. Importar búsquedas guardadas
5. Exportar búsquedas guardadas
6. Crear un grupo de equipos
7. Habilitar la recopilación de registros de IIS en equipos con el agente de Windows instalado
8. Recopilar contadores de rendimiento de discos lógicos de equipos Linux (% de inodos usados; megabytes libres; % de espacio usado; transferencias de disco/seg.;
lecturas de disco/seg.; escrituras de disco/seg.)
9. Recopilar eventos de Syslog de equipos Linux
10. Recopilar eventos de error y advertencia del registro de eventos de aplicación de los equipos de Windows
11. Recopilar contadores de rendimiento de MB disponibles de equipos Windows
12. Recopilar registros personalizados
$ResourceGroup = "my-resource-group"
$WorkspaceName = "log-analytics-" + (Get-Random -Maximum 99999) # workspace names need to be unique across all Azure subscriptions - Get-Random helps with this
for the example code
$Location = "westeurope"

try {
} catch {
}

# List of solutions to enable

$Solutions = "Security", "Updates", "SQLAssessment"
# Saved Searches to import

$ExportedSearches = @"
[
{
"Category": "My Saved Searches",
"DisplayName": "WAD Events (All)",
"DisplayName": "WAD Events (All)",
"Query": "Type=Event SourceSystem:AzureStorage ",
"Version": 1
},
{
"Category": "My Saved Searches",
"DisplayName": "Current Disk Queue Length",
"Query": "Perf | where ObjectName == "LogicalDisk" and CounterName == "Current Disk Queue Length" and InstanceName == "C:"",
"Version": 1
}
]
"@ | ConvertFrom-Json
# Custom Log to collect

$CustomLog = @"
{
"customLogName": "sampleCustomLog1",
"description": "Example custom log datasource",
"inputs": [
{
"location": {
"windowsFileTypeLogPaths": [ "e:\\iis5\\*.log" ],
"linuxFileTypeLogPaths": [ "/var/logs" ]
}
},
"regexDelimiter": {
"pattern": "\\n",
"matchIndex": 0,
"matchIndexSpecified": true,
"numberedGroup": null
}
}
}
],
"extractions": [
{
"extractionType": "DateTime",
"regex": null,
"joinStringRegex": null
}
}
}
]
}
"@

try {
} catch {
}

# List all solutions and their installation status

Get-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Add solutions
foreach ($solution in $Solutions) {
Set-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -IntelligencePackName $solution -Enabled $true
}
# List enabled solutions

(Get-AzOperationalInsightsIntelligencePack -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName).Where({($_.enabled -eq $true)})
# Import Saved Searches

foreach ($search in $ExportedSearches) {
$id = $search.Category + "|" + $search.DisplayName
New-AzOperationalInsightsSavedSearch -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -SavedSearchId $id -DisplayName $search.DisplayName -
Category $search.Category -Query $search.Query -Version $search.Version
}
# Export Saved Searches

(Get-AzOperationalInsightsSavedSearch -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName).Value.Properties | ConvertTo-Json
# Create Computer Group based on a query

New-AzOperationalInsightsComputerGroup -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -SavedSearchId "My Web Servers" -DisplayName "Web
Servers" -Category "My Saved Searches" -Query "Computer=""web*"" | distinct Computer" -Version 1
# Enable IIS Log Collection using agent

Enable-AzOperationalInsightsIISLogCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Linux Perf
New-AzOperationalInsightsLinuxPerformanceObjectDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "Logical Disk" -
InstanceName "*" -CounterNames @("% Used Inodes", "Free Megabytes", "% Used Space", "Disk Transfers/sec", "Disk Reads/sec", "Disk Writes/sec") -
IntervalSeconds 20 -Name "Example Linux Disk Performance Counters"
Enable-AzOperationalInsightsLinuxPerformanceCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Linux Syslog
New-AzOperationalInsightsLinuxSyslogDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -Facility "kern" -CollectEmergency -CollectAlert
-CollectCritical -CollectError -CollectWarning -Name "Example kernel syslog collection"
Enable-AzOperationalInsightsLinuxSyslogCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
Enable-AzOperationalInsightsLinuxSyslogCollection -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName
# Windows Event
New-AzOperationalInsightsWindowsEventDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -EventLogName "Application" -CollectErrors -
CollectWarnings -Name "Example Application Event Log"
# Windows Perf
New-AzOperationalInsightsWindowsPerformanceCounterDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -ObjectName "Memory" -InstanceName
"*" -CounterName "Available MBytes" -IntervalSeconds 20 -Name "Example Windows Performance Counter"
# Custom Logs
New-AzOperationalInsightsCustomLogDataSource -ResourceGroupName $ResourceGroup -WorkspaceName $WorkspaceName -CustomLogRawJson "$CustomLog" -Name "Example

Custom Log Collection"
NOTE
El formato del parámetro CustomLogRawJson que define la configuración de un registro personalizado puede ser complejo. Utilice Get-AzOperationalInsightsDataSource para
recuperar la configuración de un registro personalizado existente. La propiedad Proper ties es la configuración necesaria para el parámetro CustomLogRawJson .
En el ejemplo anterior, regexDelimiter se definió como "\n" para la nueva línea. El delimitador de registro también puede ser una marca de tiempo. Estos son los
formatos admitidos:
EL F O RM ATO JSO N REGEX USA DO S \\ P O R C A DA \ EN UN A EXP RESIÓ N REGUL A R

F O RM ATO ESTÁ N DA R, P O R LO Q UE SI SE P RUEB A EN UN A A P L IC A C IÓ N REGEX , \\ SE REDUC E A \
YYYY-MM-DD HH:MM:SS ((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))\\s((\\d)|([0-1]\\d)|(2[0-

4])):[0-5][0-9]:[0-5][0-9]
M/D/YYYY HH:MM:SS AM/PM (([0-1]\\d)|[0-9])/(([0-3]\\d)|(\\d))/((\\d{2})|(\\d{4}))\\s((\\d)|([0-

1]\\d)|(2[0-4])):[0-5][0-9]:[0-5][0-9]\\s(AM|PM|am|pm)
dd/MMM/yyyy HH:MM:SS (([0-2][1-9]|[3][0-

1])\\/(Jan|Feb|Mar|May|Apr|Jul|Jun|Aug|Oct|Sep|Nov|Dec|jan|feb|mar|may|apr|jul|jun|aug|oct|sep|nov
[0-9][0-9]))\\s((\\d)|([0-1]\\d)|(2[0-4])):[0-5][0-9]:[0-5][0-9])
MMM dd yyyy HH:MM:SS (((?:Jan(?:uary)?|Feb(?:ruary)?|Mar(?:ch)?|Apr(?:il)?|May|Jun(?:e)?|Jul(?:y)?

|Aug(?:ust)?|Sep(?:tember)?|Sept|Oct(?:ober)?|Nov(?:ember)?
|Dec(?:ember)?)).*?((?:(?:[0-2]?\\d{1})|(?:[3][01]{1})))(?![\\d]).*?((?:(?:
[1]{1}\\d{1}\\d{1}\\d{1})|(?:[2]{1}\\d{3})))(?![\\d]).*?((?:(?:[0-1][0-9])|
(?:[2][0-3])|(?:[0-9])):(?:[0-5][0-9])(?::[0-5][0-9])?(?:\\s?
(?:am|AM|pm|PM))?))
yyMMdd HH:mm:ss ([0-9]{2}([0][1-9]|[1][0-2])([0-2][0-9]|[3][0-1])\\s\\s?([0-1]?[0-9]|[2][0-

3]):[0-5][0-9]:[0-5][0-9])
ddMMyy HH:mm:ss (([0-2][0-9]|[3][0-1])([0][1-9]|[1][0-2])[0-9]{2}\\s\\s?([0-1]?[0-9]|[2][0-

3]):[0-5][0-9]:[0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s\\s?([0]?[1-9]|[1-2][0-

9]|[3][0-1])\\s([0-1]?[0-9]|[2][0-3]):([0-5][0-9]):([0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s\\s([0]?[1-9]|[1-2][0-9]|

dos espacios después de MMM [3][0-1])\\s([0][0-9]|[1][0-2]):([0-5][0-9]):([0-5][0-9])
MMM d HH:mm:ss (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\s([0]?[1-9]|[1-2][0-9]|[3]

[0-1])\\s([0][0-9]|[1][0-2]):([0-5][0-9]):([0-5][0-9])
dd/MMM/yyyy:HH:mm:ss +zzzz (([0-2][1-9]|[3][0-

donde + es + o un - 1])\\/(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\\/((19|20)[0-9][0-
9]):([0][0-9]|[1][0-2]):([0-5][0-9]):([0-5][0-9])\\s[\\+|\\-][0-9]{4})
donde zzzz es la compensación de tiempo
yyyy-MM-ddTHH:mm:ss ((\\d{2})|(\\d{4}))-([0-1]\\d)-(([0-3]\\d)|(\\d))T((\\d)|([0-1]\\d)|(2[0-
4])):[0-5][0-9]:[0-5][0-9]
La T es una letra T literal
Al crear un área de trabajo que se eliminó en los últimos 14 días y en estado de eliminación temporal, la operación podría tener un resultado diferente en función de
la configuración del área de trabajo:
1. Si proporciona el mismo nombre de área de trabajo, grupo de recursos, suscripción y región que en el área de trabajo eliminado, se recuperará el área de trabajo,
incluidos los datos, la configuración y los agentes conectados.
2. Si usa el mismo nombre de área de trabajo, pero un grupo de recursos, una suscripción o una región diferentes, obtendrá un error El nombre del área de trabajo
"nombre del área de trabajo" no es único o causa conflicto. Para invalidar la eliminación temporal y eliminar inmediatamente el área de trabajo y crear una con el
mismo nombre, siga estos pasos para recuperar el área de trabajo primero y realizar una eliminación permanente:
Pasos siguientes
Revise los cmdlets de PowerShell de Log Analytics para obtener información adicional sobre cómo usar PowerShell para la configuración de Log Analytics.
Eliminación y recuperación de un área de trabajo
de Azure Log Analytics
En este artículo se explica el concepto de eliminación temporal de áreas de trabajo de Azure Log Analytics y
cómo recuperarlas.
Consideraciones al eliminar áreas de trabajo

Al eliminar un área de trabajo de Log Analytics, se realiza una operación de eliminación temporal para que se
pueda recuperar el área de trabajo, incluidos los datos y los agentes conectados en un plazo de 14 días, tanto si
la eliminación fue accidental como intencionada. Después del período de eliminación temporal, el recurso del
área de trabajo y sus datos no podrán recuperarse: los datos se pondrán en cola para su eliminación
permanente en un plazo de 30 días. El nombre del área de trabajo es "released" y puede usarlo para crear una
nueva área de trabajo.
NOTE
Si desea invalidar el comportamiento de eliminación temporal y eliminar el área de trabajo de forma permanente, siga los
pasos descritos en Eliminación permanente del área de trabajo.
Debe tener cuidado al eliminar un área de trabajo porque puede haber datos importantes y una configuración
que puede afectar negativamente a las operaciones de servicio. Revise qué agentes, soluciones y otros servicios
de Azure almacenan sus datos en Log Analytics. Por ejemplo:
Soluciones de administración
Azure Automation
Agentes que se ejecutan en máquinas virtuales Windows y Linux
Agentes que se ejecutan en equipos Windows y Linux en su entorno
System Center Operations Manager
La operación de eliminación temporal quita el recurso del área de trabajo y los permisos de los usuarios
asociados. Si los usuarios están asociados a otras áreas de trabajo, podrán seguir utilizando Log Analytics con
esas otras áreas de trabajo.
Comportamiento de eliminación temporal

La operación de eliminación del área de trabajo quita el recurso de Resource Manager del área de trabajo, pero
su configuración y sus datos se conservan durante 14 días (y da la sensación de que el área de trabajo se ha
eliminado). Los agentes y grupos de administración de System Center Operations Manager configurados para
enviar notificaciones al área de trabajo continúan en un estado huérfano durante el período de eliminación
temporal. El servicio proporciona además un mecanismo para recuperar el área de trabajo eliminada (incluidos
sus datos y recursos conectados), básicamente, deshaciendo la eliminación.
NOTE
Tanto las soluciones instaladas como los servicios vinculados, como la cuenta de Azure Automation, se quitan
permanentemente del área de trabajo en el momento de la eliminación y no se pueden recuperar. Deben volver a
configurarse después de la operación de recuperación para que el área de trabajo vuelva al estado en que estaba
configurado anteriormente.
Las áreas de trabajo se pueden eliminar un mediante PowerShell, API REST o en Azure Portal.
Azure portal
Analytics .
3. En la lista de áreas de trabajo de Log Analytics, seleccione un área de trabajo y, a continuación, haga clic
en Eliminar en la parte superior del panel intermedio.
4. Aparece una página de confirmación que muestra la ingesta de datos en el área de trabajo durante la
semana pasada. Escriba el nombre del área de trabajo que desea confirmar y, a continuación, haga clic en
Eliminar .
PowerShell
PS C:\>Remove-AzOperationalInsightsWorkspace -ResourceGroupName "resource-group-name" -Name "workspace-

name"

Es posible que el método de eliminación temporal no encaje en algunos escenarios como el desarrollo y las
pruebas, donde es necesario repetir una implementación con la misma configuración y el mismo nombre de
área de trabajo. En tales casos, puede eliminar el área de trabajo de forma permanente e "invalidar" el período
de eliminación temporal. La operación de eliminación permanente del área de trabajo libera el nombre del área
de trabajo y puede crear una nueva área de trabajo con el mismo nombre.
IMPORTANT
Use la operación de eliminación permanente de áreas de trabajo con precaución porque es irreversible y no podrá
recuperar el área de trabajo ni sus datos.
Agregue la etiqueta "-ForceDelete" para eliminar permanentemente el área de trabajo. La opción "-ForceDelete"
está disponible actualmente con Az.OperationalInsights 2.3.0 o versiones posteriores.
PS C:\>Remove-AzOperationalInsightsWorkspace -ResourceGroupName "resource-group-name" -Name "workspace-

name" -ForceDelete
Recuperación de áreas de trabajo

Al eliminar un área de trabajo de Log Analytics accidental o intencionadamente, el servicio coloca el área de
trabajo en un estado de eliminación temporal, lo que hace que sea inaccesible para cualquier operación. El
nombre del área de trabajo eliminada se conserva durante el periodo de eliminación temporal y no se puede
para crear un área de trabajo nueva. Después del período de eliminación temporal, el área de trabajo no es
recuperable, está programada para su eliminación permanente y su nombre se ha liberado y se puede usar para
crear una nueva área de trabajo.
Puede recuperar el área de trabajo durante el período de eliminación temporal, incluidos los datos, la
configuración y los agentes conectados. Necesita tener permisos de colaborador en la suscripción y el grupo de
recursos donde se localizó el área de trabajo antes de la operación de eliminación temporal. La recuperación del
área de trabajo se realiza mediante la creación de un área de trabajo de Log Analytics con los detalles del área
de trabajo eliminada, incluidos los siguientes:
Id. de suscripción
Nombre del grupo de recursos
Nombre del área de trabajo
Region
Azure portal
Analytics . Verá la lista de áreas de trabajo que tiene en el ámbito seleccionado.
3. Haga clic en Recuperar en el menú superior izquierdo para abrir una página con áreas de trabajo en
estado de eliminación temporal que se puedan recuperar.
4. Seleccione el área de trabajo y haga clic en Recuperar para recuperar dicha área de trabajo.
PowerShell
PS C:\>Select-AzSubscription "subscription-name-the-workspace-was-in"
PS C:\>New-AzOperationalInsightsWorkspace -ResourceGroupName "resource-group-name-the-workspace-was-in" -
Name "deleted-workspace-name" -Location "region-name-the-workspace-was-in"
El área de trabajo y todos sus datos se restauran después de la operación de recuperación. Las soluciones y los
servicios vinculados se quitaron permanentemente del área de trabajo cuando se eliminó y se deben volver a
configurar para restaurarla a su estado configurado anterior. Puede que algunos de los datos no estén
disponibles para la consulta después de la recuperación del área de trabajo hasta que se vuelvan a instalar las
soluciones asociadas y se agreguen sus esquemas al área de trabajo.
NOTE
Al volver a crear un área de trabajo durante el período de eliminación temporal, se indica que este nombre de área de
trabajo ya está en uso.
Debe tener al menos permisos de Colaborador de Log Analytics para eliminar un área de trabajo.
Si no está seguro de si el área de trabajo eliminada está en estado de eliminación temporal y se puede
recuperar, haga clic en Recuperar en la página Áreas de trabajo de Log Analytics para ver una lista de áreas
de trabajo eliminadas temporalmente por suscripción. Las áreas de trabajo eliminadas permanentemente no
se incluyen en la lista.
Si recibe el mensaje de error El nombre del área de trabajo ya está en uso o se produce un conflicto al crear
un área de trabajo, puede deberse a:
el nombre del área de trabajo no está disponible y lo está usando alguien de su organización u otro
cliente.
El área de trabajo se ha eliminado en los últimos 14 días y su nombre se mantiene reservado durante
el período de eliminación temporal. Para invalidar la eliminación temporal y eliminar inmediatamente
el área de trabajo y crear una con el mismo nombre, siga estos pasos para recuperar el área de
trabajo primero y realizar una eliminación permanente:
1. Recuperar el área de trabajo.
2. Eliminar permanentemente el área de trabajo.
3. Crear una nueva área de trabajo con el mismo nombre.
Trasladar un área de trabajo de Log Analytics a otro
grupo de recursos o suscripción
En este artículo, aprenderá los pasos para trasladar un área de trabajo de Log Analytics a otro grupo de recursos
o suscripción de la misma región. Puede obtener más información sobre cómo trasladar recursos de Azure a
través del Azure portal, PowerShell, la CLI de Azure o la API de REST. en Traslado de los recursos a un nuevo
grupo de recursos o a una nueva suscripción.
IMPORTANT
No puede trasladar un área de trabajo a otra región.
Comprobar el Inquilino de Active Directory

Las suscripciones de origen y destino del área de trabajo deben existir dentro del mismo inquilino de Azure
Active Directory. Use Azure PowerShell para verificar que ambas suscripciones tengan el mismo Identificador de
inquilino.
(Get-AzSubscription -SubscriptionName <your-source-subscription>).TenantId

(Get-AzSubscription -SubscriptionName <your-destination-subscription>).TenantId
Consideraciones sobre el movimiento del área de trabajo

Las soluciones administradas que se instalan en el área de trabajo se moverán con la operación de traslado de
área de trabajo de Log Analytics. Los agentes conectados permanecerán conectados y conservarán los datos en el
área de trabajo después de la migración. Dado que la operación de movimiento requiere que no haya ningún
servicio vinculado del área de trabajo, las soluciones que se basan en dicho vínculo deben quitarse para permitir
que el área de trabajo se mueva.
Soluciones que deben quitarse para poder desvincular la cuenta de Automation:
Administración de actualizaciones
Seguimiento de cambios
Inicio y detención de máquinas virtuales durante las horas de trabajo
Azure Security Center
IMPORTANT
Clientes de Azure Sentinel:
Una vez implementado en un área de trabajo, Azure Sentinel no admite actualmente el movimiento de esa área
de trabajo a otros grupos de recursos o suscripciones.
Si ya ha movido el área de trabajo, deshabilite todas las reglas activas en Análisis y vuelva a habilitarlas después de
cinco minutos. Esto debe ser efectivo en la mayoría de los casos; sin embargo, cabe reiterar que no se admite y se
realiza bajo su responsabilidad.
Eliminación de soluciones en Azure Portal

Use el siguiente procedimiento para eliminar las soluciones con Azure Portal:
1. Abra el menú del grupo de recursos en el que están instaladas las soluciones.
2. Seleccione la solución que quiera quitar.
3. Haga clic en Eliminar recursos y luego confirme los recursos que se eliminarán con un clic en Eliminar .
Eliminación con PowerShell

Para eliminar las soluciones con PowerShell, use el cmdlet Remove-AzResource como se muestra en el siguiente
ejemplo:
Remove-AzResource -ResourceType 'Microsoft.OperationsManagement/solutions' -ResourceName

"ChangeTracking(<workspace-name>)" -ResourceGroupName <resource-group-name>
Remove-AzResource -ResourceType 'Microsoft.OperationsManagement/solutions' -ResourceName "Updates(<workspace-
name>)" -ResourceGroupName <resource-group-name>
Remove-AzResource -ResourceType 'Microsoft.OperationsManagement/solutions' -ResourceName "Start-Stop-
VM(<workspace-name>)" -ResourceGroupName <resource-group-name>
Eliminación de reglas de alerta de la solución Start/Stop VMs

Para quitar la solución Star t/Stop VMs , también debe quitar las reglas de alerta creadas por la solución. Use el
siguiente procedimiento en Azure Portal para eliminar estas reglas.
1. Abra el menú Super visar y luego seleccione Aler tas .
2. Haga clic en Administrar regla de aler tas .
3. Seleccione las siguientes tres reglas de alerta y luego haga clic en Eliminar .
AutoStop_VM_Child
ScheduledStartStop_Parent
SequencedStartStop_Parent
Desvincular la cuenta de Automation
Use el siguiente procedimiento para desvincular la cuenta de Automation del área de trabajo con Azure Portal:
1. Abra el menú Cuentas de Automation y luego seleccione la cuenta que desea eliminar.
2. En la sección Recursos relacionados del menú, seleccione Área de trabajo vinculada .
3. Haga clic en Desvincular área de trabajo para desvincular el área de trabajo de su cuenta de
Automation.
Trasladar su área de trabajo

Azure portal
Use el siguiente procedimiento para trasladar su área de trabajo con Azure Portal:
1. Abra el menú Áreas de trabajo de Log Analytics y luego seleccione su área de trabajo.
2. En la página Descripción general , haga clic en cambiar después en Grupo de recursos o
Suscripción .
3. Se abrirá una nueva página con una lista de recursos relacionados con el área de trabajo. Seleccione los
recursos para pasar a la misma suscripción de destino y grupo de recursos que el área de trabajo.
4. Seleccione un destino Suscripción y Grupo de recursos . Si va a trasladar el área de trabajo a otro
grupo de recursos de la misma suscripción, no verá la opción Suscripción .
5. Haga clic en Aceptar para trasladar el área de trabajo y los recursos seleccionados.
PowerShell
Para trasladar el área de trabajo con PowerShell, use Move-AzResource como en el ejemplo siguiente:
Move-AzResource -ResourceId "/subscriptions/00000000-0000-0000-0000-

000000000000/resourceGroups/MyResourceGroup01/providers/Microsoft.OperationalInsights/workspaces/MyWorkspace"
-DestinationSubscriptionId "00000000-0000-0000-0000-000000000000" -DestinationResourceGroupName
"MyResourceGroup02"
IMPORTANT
Después de la operación de traslado, las soluciones eliminadas y el vínculo de la cuenta de Automation deben
reconfigurarse para que el área de trabajo vuelva a su estado anterior.
Pasos siguientes
Para una lista de qué recursos son compatibles con el traslado, consulte Compatibilidad con la operación de
traslado para recursos.
Registros de Azure Monitor para proveedores de
servicios
Las áreas de trabajo de Log Analytics de Azure Monitor pueden ayudar a proveedores de servicios administrados
(MSP), grandes empresas, proveedores de software independientes (ISV) y proveedores de servicios de hospedaje
a administrar y supervisar servidores en infraestructuras locales o en la nube del cliente.
Las grandes empresas comparten muchas similitudes con los proveedores de servicios, especialmente cuando hay
un equipo de TI centralizado que es responsable de la administración de TI de muchas unidades de negocio
diferentes. Por motivos de simplicidad, este documento utiliza el término "proveedor de servicios", pero la misma
funcionalidad también está disponible para empresas y otros clientes.
Para los asociados y proveedores de servicios que forman parte del programa Proveedor de soluciones en la nube
(CSP), Log Analytics de Azure Monitor es uno de los servicios de Azure disponibles en las suscripciones de CSP de
Azure.
Los proveedores de servicios que administran recursos de clientes a través de la funcionalidad de administración
de recursos delegados de Azure en Azure Lighthouse también pueden usar Log Analytics de Azure Monitor.
Arquitecturas de proveedores de servicios

Las áreas de trabajo de Log Analytics proporcionan un método para que el administrador controlen el flujo y el
aislamiento de los datos de registro y cree una arquitectura que aborde sus necesidades empresariales específicas.
En este artículo se explican las consideraciones de diseño, implementación y migración de un área de trabajo,
mientras que el artículo acerca de laadministración del acceso se describe cómo aplicar y administrar los permisos
para los datos de registro. Los proveedores de servicios tienen consideraciones adicionales.
Hay tres arquitecturas posibles para proveedores de servicios con respecto a las áreas de trabajo de Log Analytics:
1. Distribuida: los registros se almacenan en áreas de trabajo que se encuentran en el inquilino del cliente
En esta arquitectura, el área de trabajo se implementa en el inquilino del cliente que se usa para todos los registros
de ese cliente.
Los administradores de proveedores de servicios disponen de dos métodos para obtener acceso a un área de
trabajo de Log Analytics en un inquilino del cliente:
Un cliente puede agregar usuarios individuales desde el proveedor de servicios como usuarios invitados de
Azure Active Directory (B2B). Los administradores del proveedor de servicios tendrán que iniciar sesión en el
directorio de cada cliente en Azure Portal para poder acceder a estas áreas de trabajo. Esto también requiere que
los clientes administren el acceso individual de cada administrador del proveedor de servicios.
Para mejorar la escalabilidad y la flexibilidad, los proveedores de servicios pueden usar la funcionalidad de
administración de recursos delegados de Azure de Azure Lighthouse para acceder al inquilino del cliente. Con
este método, los administradores de proveedores de servicios se incluyen en un grupo de usuarios de Azure AD
en el inquilino del proveedor de servicios. Se concede acceso a este grupo durante el proceso de incorporación
de cada cliente. Posteriormente, estos administradores pueden acceder a las áreas de trabajo de cada cliente
desde su propio inquilino del proveedor de servicios, en lugar de tener que iniciar sesión en el inquilino de cada
cliente individualmente. Esta forma de acceder a los recursos de las áreas de trabajo de Log Analytics de los
clientes reduce el trabajo que debe llevar a cabo el cliente y puede facilitar la recopilación y el análisis de los
datos entre varios clientes administrados por el mismo proveedor de servicios a través de herramientas como
Workbooks de Azure Monitor. Para obtener más información, consulte Supervisión de los recursos del cliente a
escala.
Las ventajas de la arquitectura distribuida son las siguientes:
El cliente puede confirmar niveles específicos de permisos a través de la administración de recursos delegados
de Azure, o bien administrar el acceso a los registros mediante su propio control de acceso basado en rol (RBAC
de Azure).
Los registros se pueden recopilar en todos los tipos de recursos, no solo en datos de VM basados en agente. Por
ejemplo, registros de auditoría de Azure.
Cada cliente puede tener diferentes valores para su área de trabajo, como la retención y límite de datos.
El aislamiento entre los clientes con respecto a las disposiciones legales y el cumplimiento.
El cargo por cada área de trabajo se asignará a la suscripción del cliente.
Las desventajas de la arquitectura distribuida son las siguientes:
La visualización y el análisis de datos de forma centralizada entre los inquilinos del cliente con herramientas
como Workbooks de Azure Monitor pueden dar lugar a experiencias más lentas, especialmente al analizar datos
en más de 50 áreas de trabajo.
Si los clientes no se incorporan a la administración de recursos delegados de Azure, los administradores de
proveedores de servicios deben aprovisionarse en el directorio del cliente, y será más difícil para el proveedor
de servicios administrar un gran número de inquilinos de clientes a la vez.
2. Central: los registros se almacenan en el área de trabajo que se encuentra en el inquilino del proveedor de
servicios
En esta arquitectura, los registros no se almacenan en los inquilinos del cliente, sino solo en una ubicación central
dentro de una de las suscripciones del proveedor de servicios. Los agentes instalados en máquinas virtuales del
cliente se configuran para enviar sus registros a esta área de trabajo con el identificador de área de trabajo y la
clave secreta.
Las ventajas de la arquitectura centralizada son las siguientes:
Es fácil administrar un gran número de clientes e integrarlos en distintos sistemas back-end.
El proveedor de servicios tiene una propiedad completa a través de los registros y los distintos artefactos, como
son las funciones y las consultas guardadas.
El proveedor de servicios puede realizar análisis en todos los clientes.
Las desventajas de la arquitectura centralizada son las siguientes:
Esta arquitectura es aplicable únicamente para los datos de máquina virtual basados en un agente, no abarcará
orígenes de datos del tejido de Azure, PaaS ni SaaS.
Puede resultar dificultoso separar los datos entre los clientes cuando se mezclan en una sola área de trabajo. El
único método adecuado para ello consiste en usar el nombre del equipo de dominio completo (FQDN) o a
través del identificador de la suscripción de Azure.
Todos los datos de todos los clientes se almacenarán en la misma región con una sola factura y las mismas
opciones de configuración y de retención.
Los servicios de PaaS y de tejido de Azure, como Azure Diagnostics y los registros de auditoría de Azure,
requieren que el área de trabajo esté en el mismo inquilino que el recurso; por tanto, no pueden enviar los
registros al área de trabajo central.
Todos los agentes de VM desde todos los clientes se autenticarán en el área de trabajo central con el mismo
identificador de área de trabajo y clave. No hay ningún método para bloquear los registros desde un cliente
específico sin interrumpir a otros clientes.
3. Híbrido: los registros se almacenan en el área de trabajo que se encuentra en el inquilino del cliente y algunos
se extraen a una ubicación central.
La tercera arquitectura es una mezcla de las dos opciones. Se basa en la primera arquitectura distribuida donde los
registros son locales para cada cliente, pero con mecanismos para crear un repositorio central de registros. Una
parte de los registros se extrae en una ubicación central para los informes y el análisis. Esta parte podría ser un
número pequeño de tipos de datos o un resumen de la actividad, como la estadística diaria.
Hay dos opciones para implementar registros en una ubicación central:
1. Área de trabajo central: el proveedor de servicios puede crear un área de trabajo en su inquilino y usar un
script que use Query API con Data Collection API para traer los datos de las diversas áreas de trabajo a esta
ubicación central. Otra opción diferente del script es usar Azure Logic Apps.
2. Power BI como ubicación central: Power BI puede funcionar como ubicación central cuando las diversas
áreas de trabajo exportan datos a él mediante la integración entre el área de trabajo de Log Analytics y
Power BI.
Pasos siguientes
Automatice la creación y configuración de áreas de trabajo con plantillas de Resource Manager.
Automatice la creación de áreas de trabajo con PowerShell.
Use alertas para integrarse con sistemas existentes.
Genere informes de resumen con Power BI.
Incorpore clientes a la administración de recursos delegados de Azure.
Administración del acceso a los datos de registro y
las áreas de trabajo en Azure Monitor
Azure Monitor almacena datos de registro en un área de trabajo de Log Analytics. Un área de trabajo es un
contenedor que incluye datos e información de configuración. Para administrar el acceso a los datos de
registro, realice varias tareas administrativas relacionadas con su área de trabajo.
En este artículo se explica cómo administrar el acceso a los registros y cómo administrar las áreas de trabajo
que los contienen, lo que incluye cómo conceder acceso a:
El área de trabajo mediante los permisos del área de trabajo.
Los usuarios que necesitan acceder a los datos de registro de recursos concretos mediante el control de
acceso basado en rol de Azure (Azure RBAC), también conocido como contexto del recurso.
Los usuarios que necesitan acceder a los datos de registro de una tabla específica del área de trabajo
mediante Azure RBAC.
Para comprender los conceptos de registros relacionados con las estrategias de acceso y RBAC, consulte
Diseño de la implementación de registros de Azure Monitor
Configuración del modo de control de acceso

Puede ver el modo de control de acceso configurado en un área de trabajo desde Azure Portal o con
Azure PowerShell. Puede cambiar esta configuración con uno de estos métodos compatibles:
Azure portal
Azure PowerShell
Plantilla del Administrador de recursos de Azure
Desde Azure Portal
Puede ver el modo de control de acceso del área de trabajo actual en la página Introducción del área de
trabajo en el menú Área de trabajo de Log Analytics .
1. Inicie sesión en Azure Portal en https://portal.azure.com.

2. En Azure Portal, seleccione Áreas de trabajo de Log Analytics > su área de trabajo.
Este valor se puede cambiar en la página Propiedades del área de trabajo. No podrá cambiar la
configuración si no tiene permisos para configurar el área de trabajo.
Usar PowerShell
Use el comando siguiente para examinar el modo de control de acceso para todas las áreas de trabajo en la
suscripción:
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach

{$_.Name + ": " + $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions}
La salida debe ser similar a la siguiente:
DefaultWorkspace38917: True
DefaultWorkspace21532: False
Un valor de False significa que el área de trabajo se configura con el modo de acceso contexto del área de
trabajo. Un valor de True significa que el área de trabajo está configurada con el modo de acceso contexto
del área de trabajo.
NOTE
Si un área de trabajo se devuelve sin un valor booleano y está en blanco, también coincide con los resultados de un
valor False .
Use el siguiente script para establecer el modo de control de acceso de un área de trabajo específica al
permiso de contexto del recurso:
$WSName = "my-workspace"
$Workspace = Get-AzResource -Name $WSName -ExpandProperties
if ($Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $Workspace.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -
Force }
else
{ $Workspace.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $Workspace.ResourceId -Properties $Workspace.Properties -Force
Use el siguiente script para establecer el modo de control de acceso en todas las áreas de trabajo de la
suscripción al permiso de contexto del recurso:
Get-AzResource -ResourceType Microsoft.OperationalInsights/workspaces -ExpandProperties | foreach {
if ($_.Properties.features.enableLogAccessUsingOnlyResourcePermissions -eq $null)
{ $_.Properties.features | Add-Member enableLogAccessUsingOnlyResourcePermissions $true -Force }
else
{ $_.Properties.features.enableLogAccessUsingOnlyResourcePermissions = $true }
Set-AzResource -ResourceId $_.ResourceId -Properties $_.Properties -Force
}
Uso de una plantilla de Resource Manager

Para configurar el modo de acceso en una plantilla de Azure Resource Manager, establezca la marca de
característica enableLogAccessUsingOnlyResourcePermissions en el área de trabajo en uno de los
siguientes valores.
false : establece el área de trabajo en los permisos de contexto del área de trabajo. Se trata de la
configuración predeterminada si no se establece la marca.
true : establece el área de trabajo en los permisos de contexto del recurso.
Administración del acceso mediante los permisos del área de

trabajo
Cada área de trabajo puede tener varias cuentas asociadas, y cada cuenta puede tener acceso a varias áreas
de trabajo. El acceso se administra con el control de acceso basado en rol de Azure (Azure RBAC).
Las siguientes actividades también requieren permisos de Azure:
A C C IÓ N P ERM ISO S DE A Z URE N EC ESA RIO S N OTA S
Agregar y quitar soluciones de Microsoft.Resources/deployments/* Es necesario conceder estos permisos

supervisión Microsoft.OperationalInsights/* en el nivel de suscripción o grupo de
Microsoft.OperationsManagement/* recursos.
Microsoft.Automation/*
Microsoft.Resources/deployments/*/write
Cambiar el plan de tarifa Microsoft.OperationalInsights/workspaces/*/write
Ver los datos en los iconos de Administrador o coadministrador Accede a los recursos implementados
soluciones Backup y Site Recovery mediante el modelo de
implementación clásica
Creación de un área de trabajo en Microsoft.Resources/deployments/*

Azure Portal Microsoft.OperationalInsights/workspaces/*
Ver las propiedades básicas del área Microsoft.OperationalInsights/workspaces/read

de trabajo y especificar la hoja del
área de trabajo en el portal
Consultar registros con cualquier Microsoft.OperationalInsights/workspaces/query/read

interfaz
Acceder a todos los tipos de registros Microsoft.OperationalInsights/workspaces/query/*/read

mediante consultas
Acceder a una tabla de registro Microsoft.OperationalInsights/workspaces/query/<table_name>/read

específica
A C C IÓ N P ERM ISO S DE A Z URE N EC ESA RIO S N OTA S
Leer las claves del área de trabajo Microsoft.OperationalInsights/workspaces/sharedKeys/action

para permitir el envío de registros a
este área de trabajo
Administración del acceso mediante los permisos de Azure

Para conceder acceso al área de trabajo de Log Analytics mediante permisos de Azure, siga los pasos que se
describen en Uso de asignaciones de roles para administrar el acceso a los recursos de la suscripción de
Azure. Para ver roles personalizados de ejemplo, consulte Roles personalizados de ejemplo.
Azure tiene dos roles de usuario integrados para áreas de trabajo de Log Analytics:
Lector de Log Analytics
Colaborador de Log Analytics
Los miembros del rol Lector de Log Analytics pueden:
Ver y buscar todos los datos de supervisión
Ver la configuración de supervisión, incluida la visualización de la configuración de Azure Diagnostics en
todos los recursos de Azure.
El rol Lector de Log Analytics incluye las siguientes acciones de Azure:
T IP O P ERM ISO DESC RIP C IÓ N
Acción */read Capacidad para ver todos los recursos

de Azure y la configuración de los
recursos. Incluye la visualización de:
Estado de la extensión de la máquina
virtual
Configuración de Azure Diagnostics
en los recursos
Todas las propiedades y
configuraciones de todos los recursos
En el caso de las áreas de trabajo,
permite permisos completos sin
restricciones para leer la configuración
del área de trabajo y realizar
consultas en los datos. Consulte
opciones más específicas
anteriormente.
Acción En desuso, no es necesario asignarlos

Microsoft.OperationalInsights/workspaces/analytics/query/action
a los usuarios.
Acción En desuso, no es necesario asignarlos

Microsoft.OperationalInsights/workspaces/search/action
a los usuarios.
Acción Microsoft.Support/* Capacidad de abrir casos de soporte

técnico
T IP O P ERM ISO DESC RIP C IÓ N
No acción Evita la lectura de la clave del área de

Microsoft.OperationalInsights/workspaces/sharedKeys/read
trabajo necesaria para usar la API de
recopilación de datos e instalar
agentes. Esto impide que los usuarios
agreguen nuevos recursos al área de
trabajo.
Los miembros del rol Colaborador de Log Analytics pueden:

Incluir todos los privilegios del rol de lector de Log Analytics, lo que permite al usuario leer todos los
datos de supervisión
Crear y configurar cuentas de Automation
Agregar y eliminar soluciones de administración
NOTE
Para llevar a cabo correctamente estas dos últimas acciones, este permiso debe concederse en el nivel de
suscripción o grupo de recursos.
Leer las claves de la cuenta de almacenamiento

Configurar la recopilación de registros de Azure Storage
Editar la configuración de supervisión de los recursos de Azure:
Agregar la extensión de máquina virtual a las máquinas virtuales
Configurar Azure Diagnostics en todos los recursos de Azure
NOTE
Puede usar la capacidad para agregar una extensión de máquina virtual a una máquina virtual para obtener el control
total sobre una máquina virtual.
El rol Colaborador de Log Analytics incluye las siguientes acciones de Azure:
P ERM ISO DESC RIP C IÓ N
*/read Capacidad para ver todos los recursos y la configuración

de los recursos. Incluye la visualización de:
Estado de la extensión de la máquina virtual
Configuración de Azure Diagnostics en los recursos
Todas las propiedades y configuraciones de todos los
recursos
En el caso de las áreas de trabajo, permite conceder
permisos completos sin restricciones para leer el valor del
área de trabajo y realizar consultas en los datos. Consulte
opciones más específicas anteriormente.
Microsoft.Automation/automationAccounts/* Capacidad para crear y configurar cuentas de Azure

Automation, incluido agregar y editar runbooks
Microsoft.ClassicCompute/virtualMachines/extensions/* Agregar, actualizar y eliminar extensiones de máquina

Microsoft.Compute/virtualMachines/extensions/* virtual, incluida la extensión de Microsoft Monitoring
Agent y el agente de OMS para la extensión de Linux
Ver la clave de la cuenta de almacenamiento. Necesaria

Microsoft.ClassicStorage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/listKeys/action para configurar Log Analytics para leer los registros de
cuentas de Azure Storage
Microsoft.Insights/alertRules/* Agregar, actualizar y eliminar reglas de alertas
Microsoft.Insights/diagnosticSettings/* Agregar, actualizar y eliminar la configuración de

diagnósticos en los recursos de Azure
Microsoft.OperationalInsights/* Agregar, actualizar y eliminar la configuración de áreas de

trabajo de Log Analytics. Para editar la configuración
avanzada del área de trabajo, el usuario necesita
Microsoft.OperationalInsights/workspaces/write .
Microsoft.OperationsManagement/* Agregar y eliminar soluciones de administración
Microsoft.Resources/deployments/* Crear y eliminar implementaciones. Necesario para agregar

y eliminar soluciones, áreas de trabajo y cuentas de
Automation
Crear y eliminar implementaciones. Necesario para agregar

Microsoft.Resources/subscriptions/resourcegroups/deployments/*
y eliminar soluciones, áreas de trabajo y cuentas de
Automation
Para agregar y quitar usuarios de un rol de usuario, es necesario tener permisos

Microsoft.Authorization/*/Delete y Microsoft.Authorization/*/Write .
Use estos roles para conceder a los usuarios acceso en distintos ámbitos:
Suscripción: acceso a todas las áreas de trabajo de la suscripción
Grupo de recursos: acceso a todas las áreas de trabajo del grupo de recursos
Recurso: acceso solo al área de trabajo especificada
Se recomienda realizar las asignaciones en el nivel de recurso (área de trabajo) para asegurarse de que el
control de acceso es preciso. Use roles personalizados para crear roles con los permisos específicos
necesarios.
Permisos de recurso
Cuando los usuarios consulten los registros desde un área de trabajo mediante el acceso de contexto del
recurso, tendrán los siguientes permisos en el recurso:
Microsoft.Insights/logs/<tableName>/read Capacidad para ver todos los datos de registro para el

recurso.
Ejemplos:
Microsoft.Insights/logs/*/read
Microsoft.Insights/logs/Heartbeat/read
Microsoft.Insights/diagnosticSettings/write Capacidad para configurar diagnósticos a fin de permitir la

configuración de registros para este recurso.
El permiso /read se suele conceder desde un rol que incluye los permisos */read o * como los roles Lector y
Colaborador integrados. Los roles personalizados que contienen acciones específicas o roles integrados
dedicados no incluyen este permiso.
Consulte Definición del control de acceso por tabla a continuación, si desea crear un control de acceso
diferente para las distintas tablas.
Roles personalizados de ejemplo

1. Para conceder a un usuario acceso a los datos de registro desde sus recursos, realice lo siguiente:
Configure el modo de control de acceso del área de trabajo para usar permisos de recursos
o áreas de trabajo .
Conceda a los usuarios los permisos */read o Microsoft.Insights/logs/*/read a sus recursos.
Si ya se les ha asignado el rol de lector de Log Analytics en el área de trabajo, es suficiente.
2. Para conceder a los usuarios acceso a los datos de registro desde sus recursos y configurar estos para
que envíen registros al área de trabajo, realice lo siguiente:
Conceda a los usuarios los permisos siguientes en el área de trabajo:
Microsoft.OperationalInsights/workspaces/read y
Microsoft.OperationalInsights/workspaces/sharedKeys/action . Con estos permisos, los usuarios
no pueden realizar consultas en el nivel de área de trabajo. Solo pueden enumerar el área de
trabajo y usarla como destino para la configuración de diagnóstico o del agente.
Conceda a los usuarios los permisos siguientes a sus recursos: Microsoft.Insights/logs/*/read
y Microsoft.Insights/diagnosticSettings/write . Si ya se les ha asignado el rol de colaborador
de Log Analytics, el rol de lector o se les ha concedido permisos */read en este recurso, es
suficiente.
3. Para conceder a un usuario acceso a los datos de registro desde sus recursos sin capacidad para leer
eventos de seguridad y enviar datos, realice lo siguiente:
Conceda a los usuarios los permisos siguientes a sus recursos: Microsoft.Insights/logs/*/read .
Agregue el atributo NonAction siguiente para impedir que los usuarios lean el tipo
SecurityEvent: Microsoft.Insights/logs/SecurityEvent/read . El atributo NonAction debe estar
en el mismo rol personalizado que la acción que proporciona el permiso de lectura (
Microsoft.Insights/logs/*/read ). Si el usuario hereda la acción de lectura de otro rol asignado
a este recurso o a la suscripción o grupo de recursos, podrá leer todos los tipos de registro.
Esto también ocurre si hereda */read , que existe, por ejemplo, con el rol de lector o
colaborador.
4. Para conceder a un usuario acceso a los datos de registro desde sus recursos con posibilidad de leer
todos los datos de registro de inicio de sesión de Azure AD y de la solución Update Management
desde el área de trabajo, haga lo siguiente:
Conceda a los usuarios los permisos siguientes en el área de trabajo:
Microsoft.OperationalInsights/workspaces/read : necesario para que el usuario pueda
enumerar el área de trabajo y abrir la hoja del área de trabajo en Azure Portal
Microsoft.OperationalInsights/workspaces/query/read : necesario para todos los usuarios que
pueden ejecutar consultas
Microsoft.OperationalInsights/workspaces/query/SigninLogs/read : para poder leer los
registros de inicio de sesión de Azure AD
Microsoft.OperationalInsights/workspaces/query/Update/read : para poder leer los registros
de la solución Update Management
Microsoft.OperationalInsights/workspaces/query/UpdateRunProgress/read : para poder leer los
registros de la solución Update Management
Microsoft.OperationalInsights/workspaces/query/UpdateSummary/read : para poder leer los
registros de Update Management
Microsoft.OperationalInsights/workspaces/query/Heartbeat/read : necesario para poder usar
la solución Update Management
Microsoft.OperationalInsights/workspaces/query/ComputerGroup/read : necesario para poder
usar la solución Update Management
Conceda a los usuarios los permisos siguientes a sus recursos: */read , asignado al rol de
lector, o Microsoft.Insights/logs/*/read .
RBAC de nivel de tabla

RBAC de nivel de tabla le permite definir un control más pormenorizado de los datos de un área de
trabajo de Log Analytics, además de los restantes permisos. Este control le permite definir tipos de datos
específicos que son accesibles solo a un conjunto concreto de usuarios.
El control de acceso de la tabla se implementa con roles personalizados de Azure para conceder o denegar el
acceso a tablas específicas del área de trabajo. Estos roles se aplican a las áreas de trabajo con los modos de
control de acceso contexto del área de trabajo o contexto del recurso, independientemente del modo de
acceso del usuario.
Cree un rol personalizado con las acciones siguientes para definir el acceso al control de acceso de la tabla.
Para conceder acceso a una tabla, inclúyala en la sección Actions de la definición de rol. Para restar el
acceso desde las Acciones permitidas, inclúyalo en la sección NotActions .
Use Microsoft.OperationalInsights/workspaces/query/* para especificar todas las tablas.
Por ejemplo, para crear un rol con acceso a las tablas Heartbeat y AzureActivity, cree un rol personalizado
con las siguientes acciones:
"Actions": [
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/query/read",
"Microsoft.OperationalInsights/workspaces/query/Heartbeat/read",
"Microsoft.OperationalInsights/workspaces/query/AzureActivity/read"
],
Para crear un rol con acceso solo a la tabla SecurityBaseline, cree un rol personalizado con las siguientes
acciones:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/SecurityBaseline/read"
],
Los ejemplos anteriores definen una lista de las tablas que están permitidas. En este ejemplo se muestra la
definición de la lista de elementos bloqueados cuando un usuario puede tener acceso a todas las tablas,
salvo la tabla SecurityAlert:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/*/read"
],
"notActions": [
"Microsoft.OperationalInsights/workspaces/query/SecurityAlert/read"
],
Los registros personalizados se crean a partir de orígenes de datos, como los registros personalizados y la
API HTTP Data Collector. La manera más fácil de identificar el tipo de registro es mediante la comprobación
de las tablas que aparecen en Registros personalizados del esquema del registro.
No se puede conceder el acceso a registros personalizados individuales, pero puede conceder el acceso a
todos los registros personalizados. Para crear un rol con acceso a todos los registros personalizados, cree un
rol personalizado con las siguientes acciones:
"Actions": [
"Microsoft.OperationalInsights/workspaces/query/Tables.Custom/read"
],
Un enfoque alternativo para administrar el acceso a los registros personalizados es asignarlos a un recurso
de Azure y administrar el acceso mediante el paradigma del contexto del recurso. Para usar este método,
debe incluir el identificador de recurso; para ello, debe especificarlo en el encabezado x-ms-AzureResourceId,
donde se introducen los datos en Log Analytics mediante la API del recopilador de datos HTTP. El
identificador de recurso debe ser válido y tener reglas de acceso aplicadas. Una vez ingeridos los registros, se
puede acceder a ellos con acceso de lectura al recurso, como se explica aquí.
A veces, los registros personalizados proceden de orígenes que no están directamente asociados a un
recurso específico. En este caso, cree un grupo de recursos solo para administrar el acceso a estos registros.
El grupo de recursos no incurre en ningún costo, pero proporciona un identificador de recurso válido para
controlar el acceso a los registros personalizados. Por ejemplo, si un firewall específico envía registros
personalizados, cree un grupo de recursos denominado "MyFireWallLogs" y asegúrese de que las solicitudes
de API contienen el identificador de recurso de "MyFireWallLogs". Solo los usuarios a los que se les ha
concedido acceso a MyFireWallLogs o los que tienen acceso total al área de trabajo pueden acceder a los
registros del firewall.
Consideraciones
Si se concede a un usuario permiso de lectura global con los roles Lector o Colaborador estándar que
incluyen la acción */read, invalidará el control de acceso por tabla y les otorgará acceso a todos los datos
de registro.
Si se concede a un usuario el permiso de acceso para cada tabla, pero ningún otro, los usuarios podrían
acceder a los datos de registro de la API, pero no desde Azure Portal. Para proporcionar acceso desde
Azure Portal, use Lector de Log Analytics como su rol base.
Los administradores y propietarios de la suscripción tendrán acceso a todos los tipos de datos,
independientemente de cualquier otra configuración de permisos.
Los propietarios del área de trabajo son tratados como cualquier otro usuario para controlar el acceso por
tabla.
Se recomienda asignar roles a los grupos de seguridad en lugar de usuarios individuales para reducir el
número de asignaciones. Esto también le ayudará a usar las herramientas de administración de grupo
existentes para configurar y comprobar el acceso.
Pasos siguientes
Consulte la información general sobre el agente de Log Analytics para recopilar datos de los equipos
de su centro de datos u otro entorno de nube.
Consulte Recopilación de datos de máquinas virtuales de Azure para configurar la recopilación de
datos de máquinas virtuales de Azure.
Introducción al Explorador de métricas de
Azure
¿Por dónde empiezo?

El explorador de métricas de Azure Monitor es un componente de Microsoft Azure Portal que permite
trazar los gráficos, correlacionar visualmente las tendencias e investigar crestas y valles en valores de
las métricas. Utilice el Explorador de métricas para investigar el estado y la utilización de recursos.
Comience en el siguiente orden:
1. Seleccione un recurso y una métrica y verá un gráfico básico. Después, seleccione un intervalo
de tiempo que sea pertinente en su investigación.
2. Pruebe a aplicar filtros de dimensión y divisiones. Los filtros y las divisiones permiten analizar
qué segmentos de la métrica contribuyen al valor general de la métrica, así como a identificar
posibles valores atípicos.
3. Use la configuración avanzada para personalizar el gráfico antes de anclarlo a algún panel.
Configure alertas para recibir notificaciones cuando el valor de la métrica esté por encima o por
debajo del umbral establecido.
Crear el primer gráfico de métricas

Para crear un gráfico de métricas, abra la pestaña Métricas desde el recurso, el grupo de recursos, la
suscripción o la vista de Azure Monitor y haga lo siguiente:
1. Con el selector de recursos, seleccione el recurso del que quiera ver las métricas. El recurso
aparecerá ya seleccionado si abre Métricas en el contexto de un recurso concreto.
2. En algunos recursos, debe elegir un espacio de nombres. El espacio de nombres es una forma de
organizar las métricas para que se puedan encontrar fácilmente. Por ejemplo, las cuentas de
almacenamiento tienen espacios de nombres aparte para almacenar las métricas de File service,
Table service, Blob service y Queue service. Muchos tipos de recursos solo tienen un espacio de
nombres.
3. Seleccione una métrica de una lista de métricas que haya disponible.
4. Si lo desea, puede cambiar la agregación de la métrica. Por ejemplo, puede que quiera que el
gráfico muestre los valores mínimos, máximos o promedio de la métrica.
TIP
Use el botón Agregar métrica y repita estos pasos si quiere ver varias métricas trazadas en el mismo gráfico.
Para ver varios gráficos en una vista, seleccione el botón Agregar gráfico en la parte superior.
Selección de un intervalo de tiempo

WARNING
La mayoría de las métricas en Azure se almacenan durante 93 días. Sin embargo, no puede consultar datos de
más de 30 días en un gráfico individual. Esta limitación no se aplica a las métricas basadas en registros.
El gráfico muestra las últimas 24 horas de los datos de métricas de forma predeterminada. Use el panel
del selector de hora para cambiar el intervalo de tiempo o acercar o alejar el gráfico.
TIP
Use la herramienta del pincel de tiempo para investigar un área interesante del gráfico (un repunte o una
caída). Coloque el puntero al principio del área, haga clic y mantenga presionado el botón principal, arrastre al
otro lado del área y entonces suelte el botón. El gráfico acercará el intervalo de tiempo.
Aplicar filtros de dimensión y divisiones

El filtrado y las divisiones son herramientas de diagnóstico tremendamente eficaces con las métricas
que tienen dimensiones. Estas características ponen de manifiesto el modo en que varios segmentos de
la métrica ("valores de dimensión") influyen en el valor total de la métrica, y le permiten identificar
posibles valores atípicos.
El filtrado permite elegir qué valores de dimensión se van a incluir en el gráfico. Por ejemplo,
puede que le interese mostrar las solicitudes correctas al representar gráficamente la métrica de
Tiempo de respuesta del servidor. En tal caso, habría que aplicar el filtro en la dimensión de
solicitud correcta.
Las divisiones controlan si el gráfico va a mostrar líneas independientes por cada valor de una
dimensión, o si por el contrario va a agregar los valores en una sola línea. Por ejemplo, puede
ver una línea correspondiente a un tiempo de respuesta promedio de todas las instancias de
servidor, o ver líneas independientes de cada servidor. Para ver líneas independientes, habría que
aplicar la división en la dimensión de instancia del servidor.
Vea ejemplos de gráficos que tienen filtrado y divisiones aplicados. En el artículo se explican los pasos
que se realizaron para configurar los gráficos.
Configuración gráfico avanzada

Se puede personalizar el estilo y el título de un gráfico, así como modificar la configuración de gráfico
avanzada. Cuando haya terminado de personalizarlo, puede anclarlo a un panel para guardar el trabajo.
También se pueden configurar alertas de métricas. Consulte la documentación del producto para
obtener información sobre estas y otras características avanzadas del Explorador de métricas de Azure
Monitor.
Pasos siguientes
Obtenga información sobre las características avanzadas del Explorador de métricas
Solución de problemas del Explorador de métricas
Vea una lista de métricas disponibles para servicios de Azure
Vea ejemplos de gráficos configurados
Características avanzadas del Explorador de
métricas de Azure
NOTE
En este artículo se da por hecho que está familiarizado con las características básicas del Explorador de
métricas. Si es un nuevo usuario y desea aprender a crear su primer gráfico de métricas, consulte
Introducción al Explorador de métricas.
Métricas en Azure
Las métricas en Azure Monitor son la serie de valores medidos y recuentos que se recopilan y se
almacenan con el tiempo. Hay métricas estándar (o de la “plataforma”) y métricas personalizadas. La
misma plataforma de Azure le proporciona las métricas estándares. Las métricas estándares reflejan
las estadísticas de uso y mantenimiento de los recursos de Azure. Por otra parte, las métricas
personalizadas se envían a Azure por medio de sus aplicaciones con la API de Application Insights
para eventos y métricas personalizados, la extensión de Windows Azure Diagnostics (WAD), o por
medio de la API de REST de Azure Monitor.
Creación de vistas con varias métricas y gráficos

Puede crear gráficos que tracen varias líneas de métricas o mostrar varios gráficos de métricas a la
vez. Esta funcionalidad le permite:
poner en correlación métricas relacionadas en el mismo grupo para ver la relación de un valor
con otro,
mostrar métricas con diferentes unidades de medida muy cercanas o
agregar y comparar visualmente métricas de varios recursos.
Por ejemplo, si tiene cinco cuentas de almacenamiento y desea conocer el espacio total consumido
entre ellas, puede crear un gráfico de áreas (apiladas) que muestre el valor individual y la suma de
todos los valores en determinados momentos.
Varias métricas en el mismo gráfico
En primer lugar, cree un nuevo gráfico. Haga clic en Agregar métrica y repita los pasos para
agregar otra métrica en el mismo gráfico.
NOTE
Normalmente no querrá tener en un gráfico métricas con unidades de medida diferentes (es decir,
milisegundos y kilobytes) ni con una escala muy diferente. En su lugar, considere el uso de varios gráficos.
Haga clic en el botón Agregar gráfico para crear varios gráficos en el explorador de métricas.
Varios gráficos
Haga clic en Agregar gráfico y cree otro gráfico con una métrica diferente.
Ordenación o eliminación de varios gráficos
Para ordenar o eliminar varios gráficos, haga clic en el símbolo de puntos suspensivos ( ... ) para
abrir el menú del gráfico y elija el elemento de menú adecuado de Subir , Bajar o Eliminar .
Cambio de la agregación
Al agregar una métrica a un gráfico, el Explorador de métricas preselecciona automáticamente la
agregación predeterminada. El valor predeterminado tiene sentido en escenarios básicos, pero puede
usar una agregación diferente para obtener información adicional sobre la métrica. Para ver
diferentes agregaciones en un gráfico, es necesario comprender cómo las administra el Explorador
de métricas.
Las métricas son la serie de medidas (o "valores de métricas") capturadas durante el período de
tiempo. Al trazar un gráfico, los valores de la métrica seleccionada se agregan por separado en el
intervalo de agregación. Puede seleccionar el tamaño del intervalo de agregación mediante el panel
selector de tiempo del Explorador de métricas. Si no realiza una selección explícita del intervalo de
agregación, la granularidad del tiempo se selecciona automáticamente en función del intervalo de
tiempo seleccionado actualmente. Una vez que se determina el intervalo de agregación, los valores
de métricas que se capturaron durante cada intervalo de agregación se agregan y se colocan en el
gráfico: un punto de bits por cada intervalo de agregación.
Por ejemplo, supongamos que el gráfico muestra la métrica Tiempo de respuesta del ser vidor
con la agregación Media en el intervalo de tiempo últimas 24 horas :
Si la granularidad del tiempo se establece en 30 minutos, el gráfico se dibuja a partir de 48
puntos de datos agregados (por ejemplo, el gráfico de líneas conecta 48 puntos en el área de
trazado del gráfico). Es decir, 24 horas x 2 puntos de datos cada hora. Cada punto de datos
representa la media de todos los tiempos de respuesta capturados para las solicitudes de servidor
que se produjeron durante cada uno de los períodos de tiempo de 30 minutos correspondientes.
Si cambia la granularidad del tiempo a 15 minutos, obtendrá 96 puntos de datos agregados. Es
decir, 24 horas x 4 puntos de datos cada hora.
Hay cinco tipos de agregaciones estadísticas básicas disponibles en el Explorador de métricas: Suma ,
Recuento , Min , Max y Media . A veces, se hace referencia a la agregación Suma como agregación
Total . En el caso de muchas métricas, el Explorador de métricas ocultará las agregaciones que no son
pertinentes y no se pueden usar.
Suma : suma de todos los valores capturados en el intervalo de agregación.
Recuento : número de medidas capturadas en el intervalo de agregación. Tenga en cuenta que
Recuento será igual a Suma en el caso de que la métrica siempre se capture con el valor 1. Esto
es habitual cuando la métrica realiza un seguimiento del recuento de distintos eventos y cada
medida representa un evento (es decir, el código activa un registro de métricas cada vez que entra
una nueva solicitud).
Media : media de los valores de la métrica capturados en el intervalo de agregación.
Min : el menor valor capturado en el intervalo de agregación.
Max : el mayor valor capturado en el intervalo de agregación.
Aplicación de filtros a gráficos

Puede aplicar filtros a los gráficos que muestran métricas con dimensiones. Por ejemplo, si la métrica
“Transaction count” tiene una dimensión, “Response type”, que indica si la respuesta de las
transacciones se realizó correctamente o no, el filtrado en esta dimensión trazaría una línea de
gráfico solo para transacciones correctas (o solo con errores).
Para agregar un filtro
1. Seleccione Agregar filtro encima del gráfico
2. Seleccione qué dimensión (propiedad) quiere filtrar.
3. Seleccione qué valores de dimensión quiere incluir al trazar el gráfico (en este ejemplo se
muestra el filtrado excluyente de las transacciones de almacenamiento correctas):
4. Después de seleccionar los valores de filtro, haga clic fuera del Selector de filtro para cerrarlo.
Ahora el gráfico muestra cuántas transacciones de almacenamiento han tenido error:
5. Puede repetir los pasos del 1 al 4 para aplicar varios filtros a los gráficos mismos.
Aplicación de la división a un gráfico

Puede dividir una métrica por dimensión para visualizar cómo se comparan entre sí los distintos
segmentos de la métrica, y para identificar los segmentos no relevantes de una dimensión.
Aplicación de la división
1. Haga clic en Aplicar separación encima del gráfico.
NOTE
La división no se podrá usar con aquellos gráficos que tengan varias métricas. Asimismo, puede tener
varios filtros, pero solo una dimensión de división aplicada en un único gráfico.
2. Elija una dimensión por la que quiera segmentar el gráfico:
Ahora el gráfico muestra varias líneas, una para cada segmento de dimensión:
3. Haga clic fuera del Selector de agrupación para cerrarlo.
NOTE
Use el filtrado y la separación en la misma dimensión para ocultar los segmentos que no son
pertinentes para su escenario y facilitar la lectura de los gráficos.
Bloqueo de límites del eje y del gráfico

El bloqueo del intervalo del eje y cobra importancia cuando el gráfico muestra fluctuaciones
pequeñas de valores mayores.
Por ejemplo, cuando el volumen de solicitudes correctas cae del 99,99 % al 99,5 %, puede
representar una reducción significativa de la calidad del servicio. Sin embargo, percibir una pequeña
fluctuación de un valor numérico sería difícil, o incluso imposible, desde la configuración
predeterminada del gráfico. En ese caso podría bloquear el límite inferior del gráfico al 99 %, lo que
haría que esta pequeña caída fuera más evidente.
Otro ejemplo es una fluctuación en la memoria disponible, donde el valor técnicamente nunca
llegará a 0. El ajuste del intervalo a un valor mayor puede facilitar las detección de caídas en la
memoria disponible.
Para controlar el intervalo del eje y, use el menú "..." del gráfico y seleccione Editar gráfico para
acceder a la configuración avanzada del gráfico. Modifique los valores en la sección Intervalo del eje
Y o utilice el botón Auto para volver a los valores predeterminados.
WARNING
El bloqueo de los límites del eje Y de los gráficos que realizan el seguimiento de varios recuentos o sumas
durante un período (y, por tanto, use recuento de uso, suma y agregaciones mínima o máxima) normalmente
requiere que se especifique una granularidad de tiempo fijo, en lugar de usar los valores predeterminados
automáticos. Esto es necesario porque los valores de los gráficos cambian cuando la granularidad de tiempo
se modifica automáticamente cuando el usuario cambia el tamaño de la ventana del explorador o pasa de
una resolución de pantalla a otro. El cambio resultante en la granularidad de tiempo afecta al aspecto del
gráfico, lo que invalida la selección actual del eje Y.
Cambio de los colores de las líneas del gráfico

Después de configurar los gráficos, se asigna automáticamente a las líneas del gráfico un color de la
paleta predeterminada. Puede cambiar esos colores.
Para cambiar el color de una línea del gráfico, haga clic en la barra coloreada de la leyenda
correspondiente al gráfico. Se abrirá el cuadro de diálogo Selector de colores. Use el selector de
colores para configurar el color de la línea.
Una vez configurados los colores del gráfico, permanecerán de este modo al anclar el gráfico a un
panel. En la sección siguiente se muestra cómo anclar un gráfico.
Anclaje de gráficos a paneles
Después de configurar un gráfico, puede que quiera agregarlo a los paneles para poder volver a
verlo, posiblemente en el contexto de otra telemetría de supervisión, o compartirlo con su equipo.
Para anclar un gráfico configurado a un panel:
Después de configurar el gráfico, haga clic en el menú Char t Actions (Acciones del gráfico) en la
esquina superior derecha del gráfico y haga clic en Anclar al panel .

También puede usar los criterios que ha establecido para visualizar las métricas como la base de una
regla de alerta basada en la métrica. La nueva regla de alerta incluirá su recurso de destino, métrica,
división y dimensiones de filtro del gráfico. Podrá modificar esta configuración más adelante en el
panel de creación de la regla de alerta.
Para crear una nueva regla de alertas, haga clic en Nueva regla de alertas.
Se le dirigirá al panel de creación de reglas de alertas con las dimensiones de métricas subyacentes
desde el gráfico rellenado previamente para que resulte más fácil generar reglas de alertas
personalizadas.
Consulte este artículo para obtener más información sobre cómo configurar alertas de métricas.
No veo ningún dato en el gráfico.
Los filtros se aplican a todos los gráficos del panel. Asegúrese de que, al centrarse en un
gráfico, no ha establecido un filtro que excluya todos los datos en otro.
Si desea establecer filtros diferentes en gráficos diferentes, créelos en hojas diferentes y
guárdelos como elementos favoritos independientes. Si lo desea, puede anclarlos al panel
para verlos en paralelo.
Si segmenta un gráfico por una propiedad que no está definida en la métrica, no habrá nada
en el gráfico. Intente borrar la segmentación (división) o elija otro nombre de propiedad.
Pasos siguientes
Lea Creating custom KPI dashboards (Creación de paneles de KPI personalizados) para obtener
información sobre las prácticas recomendadas para la creación de paneles accionables con métricas.
Ejemplos de gráficos de métricas
La plataforma Azure ofrece más de mil métricas, muchas de ellas con dimensiones. Mediante el uso de filtros de
dimensión, la aplicación de divisiones, el control del tipo de gráfico y el ajuste de la configuración del gráfico
puede crear paneles y vistas de diagnóstico eficaces que proporcionan información detallada sobre el estado de
la infraestructura y las aplicaciones. En este artículo se muestran algunos ejemplos de los gráficos que se pueden
compilar mediante el Explorador de métricas y se explican los pasos necesarios para configurar cada uno de estos
gráficos.
¿Quiere compartir sus estupendos ejemplos de gráficos con todo el mundo? Contribuya con esta página en
GitHub y comparta sus propios ejemplos de gráfico aquí.
Uso de CPU del sitio web en instancias del servidor

Este gráfico muestra si la CPU de una instancia de App Service estaba dentro del rango aceptable y la desglosa
por instancia para determinar si la carga se distribuyó correctamente. Puede ver en el gráfico que la aplicación se
estaba ejecutando en una única instancia del servidor antes de las 6 a.m. y, a continuación, se escaló
verticalmente mediante la adición de otra instancia.
Cómo configurar este gráfico

Seleccione el recurso de App Service y busque la métrica de porcentaje de CPU . A continuación, haga clic en
Aplicar división y seleccione la dimensión Instancia .
Disponibilidad de la aplicación por región

Consulte la disponibilidad de la aplicación por región para identificar qué ubicaciones geográficas tienen
problemas. Este gráfico muestra la métrica de disponibilidad de Application Insights. Puede ver que la aplicación
supervisada no tiene ningún problema con la disponibilidad desde el centro de datos del Este de EE. UU., pero
está experimentando un problema de disponibilidad parcial desde el Oeste de EE. UU. y Este de Asia.
Primero deberá activar la supervisión de la disponibilidad de Application Insights para su sitio web. Después, elija
el recurso de Application Insights y seleccione la métrica de disponibilidad. Aplique la división en la dimensión
Ejecutar ubicación .
Volumen de transacciones de la cuenta de almacenamiento por

nombre de API
El recurso de la cuenta de almacenamiento está experimentando un volumen excesivo de transacciones. Puede
usar la métrica de transacciones para identificar qué API es responsable de la carga excesiva. Tenga en cuenta que
el gráfico siguiente se configura con la misma dimensión (nombre de API) en el filtrado y la división para
restringir la vista únicamente a las llamadas API del interés:

En el selector de métricas, seleccione la cuenta de almacenamiento y la métrica Transacciones . Cambie el tipo de
gráfico a Gráfico de barras . Haga clic en Aplicar división y seleccione el nombre de API de la dimensión. A
continuación, haga clic en Agregar filtro y vuelva a elegir la dimensión nombre de API . En el cuadro de
diálogo Filtro, seleccione las API que quiere trazar en el gráfico.
Pasos siguientes
Más información acerca de Azure Monitor Workbooks.
Más información acerca del Explorador de métricas.
Solución de problemas de gráficos de métricas
Use este artículo si tienen problemas al crear, personalizar o interpretar los gráficos en el Explorador de métricas de
Azure. Si no está familiarizado con las métricas, obtenga información sobre la introducción al explorador de
métricas y las características avanzadas del explorador de métricas. También puede ver ejemplos de los gráficos de
métricas configurados.
No se encuentra el recurso para seleccionarlo

Hizo clic en el botón Seleccionar un recurso , pero no ve el recurso en el cuadro de diálogo del selector de
recursos.
Solución: El explorador de métricas requiere que seleccione las suscripciones y los grupos de recursos antes de
enumerar los recursos disponibles. Si no ve el recurso:
1. Asegúrese de que ha seleccionado la suscripción correcta en la lista desplegable Suscripción . Si su
suscripción no aparece, haga clic en configuración Directorio + suscripción y agregue una suscripción
con el recurso.
2. Asegúrese de haber seleccionado el grupo de recursos correcto.
WARNING
Para obtener el mejor rendimiento, al abrir el explorador de métricas por primera vez, la lista desplegable Grupo de
recursos no tiene ningún grupo de recursos seleccionado previamente. Debe seleccionar al menos un grupo para
poder ver los recursos.
El gráfico no muestra ningún dato

En ocasiones, puede que los gráficos no muestren ningún dato después de seleccionar las métricas y los recursos
correctos. Este comportamiento puede deberse a varias de las siguientes razones:
El proveedor de recursos Microsoft.Insights no se ha registrado para la suscripción
La exploración de métricas requiere que el proveedor de recursos Microsoft.Insights esté registrado en su
suscripción. En muchos casos, se registra automáticamente (es decir, después de configurar una regla de alerta,
personalizar la configuración de diagnóstico para cualquier recurso o configurar una regla de escalado
automático). Si el proveedor de recursos Microsoft.Insights no está registrado, debe registrarlo manualmente
siguiendo los pasos descritos en Tipos y proveedores de recursos de Azure.
Solución: Abra Suscripciones , pestaña Proveedores de recursos y verifique que Microsoft.Insights esté
registrado para su suscripción.
No tiene suficientes derechos de acceso al recurso
En Azure, el acceso a las métricas se controla mediante el control de acceso basado en rol (RBAC de Azure). Debe
ser miembro del lector de supervisión, colaborador de supervisión o colaborador para explorar las métricas de
cualquier recurso.
Solución: Asegúrese de que tiene permisos suficientes para el recurso desde el que explora las métricas.
El recurso no emite métricas durante el intervalo de tiempo seleccionado
Algunos recursos no emiten constantemente sus métricas. Por ejemplo, Azure no recopilará las métricas de
máquinas virtuales detenidas. Otros recursos pueden emitir sus métricas solo cuando se produce alguna
condición. Por ejemplo, una métrica que muestra el tiempo de procesamiento de una transacción requiere al
menos una transacción. Si no hubiera ninguna transacción en el intervalo de tiempo seleccionado, el gráfico
naturalmente estará vacío. Además, si bien la mayoría de las métricas en Azure se recopilan cada minuto, hay
algunas que se recopilan con menos frecuencia. Consulte la documentación de las métricas para obtener más
detalles acerca de la métrica que quiere explorar.
Solución: Cambie la hora del gráfico a un intervalo más amplio. Puede comenzar desde "Últimos 30 días" con una
mayor granularidad de tiempo (o basarse en la opción "Automatic time granularity" [Granularidad de tiempo
automática]).
Ha elegido un intervalo de tiempo mayor que 30 días
La mayoría de las métricas en Azure se almacenan durante 93 días. Sin embargo, solo puede consultar datos para
no más de 30 días en un único gráfico. Esta limitación no se aplica a las métricas basadas en registros.
Solución: Si ve un gráfico en blanco o el gráfico solo muestra parte de los datos de métricas, verifique que la
diferencia entre las fechas de inicio y final en el selector de tiempo no supere el intervalo de 30 días.
Todos los valores de métricas estaban fuera del intervalo del eje Y bloqueado
Al bloquear los límites del eje Y del gráfico, puede hacer que por accidente el área de visualización del gráfico no
muestre la línea del gráfico. Por ejemplo, si el eje Y está bloqueado en un intervalo entre el 0 y el 50 %, y la métrica
tiene un valor constante del 100 %, la línea se representa siempre fuera del área visible, lo que hace que el gráfico
parezca estar en blanco.
Solución: Verifique que los límites del eje Y del gráfico no queden bloqueados fuera del intervalo de los valores de
las métricas. Si los límites del eje Y se bloquean, puede querer restablecerlos temporalmente para asegurarse de
que los valores de las métricas no se encuentren fuera del intervalo del gráfico. No se recomienda bloquear el
intervalo del eje Y con granularidad automática para los gráficos con agregación sum , min y max , ya que sus
valores cambiarán con la granularidad al cambiar el tamaño de la ventana del explorador o al pasar de una
resolución de pantalla a otra. Cambiar la granularidad puede hacer que el área de visualización del gráfico quede
vacía.
Ve una métrica del SO invitado, pero no ha habilitado la extensión de Azure Diagnostics
La colección de métricas del SO invitado requiere la configuración de la extensión de Azure Diagnostics o
habilitarla mediante el panel Configuración de diagnóstico para el recurso.
Solución: Si la extensión de Azure Diagnostics está habilitada, pero todavía no puede ver las métricas, siga los
pasos descritos en la guía de solución de problemas de extensión de Azure Diagnostics. Vea también los pasos de
solución de problemas para No se pueden elegir las métricas y el espacio de nombres del SO invitado.
Mensaje "Error al recuperar datos" en el panel

Este problema puede producirse si se creó el panel con una métrica que más tarde dejó de utilizarse y acabó
quitándose de Azure. Para verificar que sea así, abra la pestaña Métricas del recurso y compruebe las métricas
disponibles en el selector de métricas. Si no se muestra la métrica, se quitó de Azure. Normalmente, cuando una
métrica está en desuso, hay una nueva métrica mejor que brinda una perspectiva similar sobre el estado del
recurso.
Solución: Actualice el elemento con error; para ello, elija una métrica alternativa para el gráfico en el panel. Puede
revisar una lista de métricas disponibles para servicios de Azure.
El gráfico muestra una línea discontinua

Los gráficos de métricas de Azure usan el estilo de línea discontinua para indicar que hay un valor que falta
(también conocido como "valor null") entre dos puntos de datos de intervalo de agregación conocidos. Por
ejemplo, si en el selector de tiempo ha elegido la granularidad de tiempo "1 minuto", pero la métrica se notificó a
las 07:26, 07:27, 07:29 y 07:30 (observe la brecha de un minuto entre el segundo y el tercer punto de datos),
entonces una línea discontinua conectará 07:27 con 07:29 y una línea continua conectará todos los demás puntos
de datos. La línea discontinua cae a cero cuando la métrica usa la agregación count y sum . Para las agregaciones
avg , min o max , la línea discontinua conecta dos puntos de datos conocidos más cercanos. Además, cuando faltan
los datos en el lado más a la derecha o más a la izquierda del gráfico, la línea discontinua se expande hacia la
dirección del punto de datos faltante.
Solución: Este comportamiento es así por diseño. Resulta útil para identificar los puntos de datos que faltan. El
gráfico de líneas es una opción superior para visualizar las tendencias de las métricas de alta densidad, pero puede
ser difícil de interpretar para las métricas con valores dispersos, especialmente cuando es importante la correlación
de valores con intervalo de agregación. La línea discontinua facilita la lectura de estos gráficos, pero si el gráfico
sigue no siendo claro, considere la posibilidad de ver las métricas con otro tipo de gráfico. Por ejemplo, un gráfico
de trazado disperso de la misma métrica muestra claramente cada intervalo de agregación al mostrar solo un
punto cuando hay un valor y omite los datos de punto por completo cuando falta el valor:
NOTE
Si aún prefiere un gráfico de líneas para la métrica, mover el mouse sobre el gráfico puede ayudarle a evaluar la granularidad
de tiempo al resaltar el punto de datos en la ubicación del puntero del mouse.
El gráfico muestra una caída inesperada en los valores

En muchos casos, la caída percibida en los valores de métrica es una falta de comprensión de los datos que se
muestran en el gráfico. Puede verse confundido por un descenso en las sumas o los recuentos cuando el gráfico
muestra los minutos más recientes porque los puntos de datos más recientes de las métricas no se han recibido o
porque Azure no los ha procesado. Según el servicio, la latencia del procesamiento de métricas puede ubicarse
dentro del intervalo un par de minutos. Para los gráficos que muestran un intervalo de tiempo reciente con una
granularidad de 1 a 5 minutos, la caída del valor a lo largo de los últimos minutos se vuelve más evidente:
Solución: Este comportamiento es así por diseño. Creemos que es beneficioso mostrar los datos tan pronto como
se reciben, incluso cuando los datos son parciales o incompletos. Esto le permite llegar a conclusiones importantes
antes y comenzar a investigar de inmediato. Por ejemplo, para una métrica que muestra el número de errores, ver
un valor parcial X le indica que se produjeron al menos X errores en un minuto dado. Puede comenzar a investigar
el problema de inmediato, en lugar de esperar a ver el recuento exacto de los errores que se produjeron en este
minuto, lo que podría no ser tan importante. El gráfico se actualizará una vez que se reciba todo el conjunto de
datos, pero en ese momento puede que se muestren los nuevos puntos de datos incompletos de los minutos más
recientes.
No se pueden elegir las métricas y el espacio de nombres del SO

invitado
Las máquinas virtuales y los conjunto de escalado de máquinas virtuales tienen dos categorías de métricas: Las
métricas del host de máquina vir tual recopiladas por el entorno de hospedaje de Azure y las métricas del
sistema operativo invitado (clásico) recopiladas por el agente de supervisión que se ejecuta en las máquinas
virtuales. El agente de supervisión se instala al habilitar la extensión de Azure Diagnostics.
De forma predeterminada, las métricas del SO invitado se almacenan en la cuenta de Azure Storage, que elige en la
pestaña Configuración de diagnóstico del recurso. Si no se recopilan métricas del SO invitado o el explorador
de métricas no puede acceder a ellas, solo verá el espacio de nombres de las métricas del host de máquina
vir tual :
Solución: Si no ve el espacio de nombres y las métricas del SO invitado (clásico) en el explorador de métricas:
1. Confirme que la extensión de Azure Diagnostics esté habilitada y configurada para recopilar métricas.
WARNING
No puede usar el agente de Log Analytics (también denominado Microsoft Monitoring Agent, o "MMA") para enviar
el SO invitado a una cuenta de almacenamiento.
2. Asegúrese de que el proveedor de recursos Microsoft.Insights se ha registrado para la suscripción.

3. Verifique que la cuenta de almacenamiento no esté protegida por el firewall. Azure Portal necesita acceder a
la cuenta de almacenamiento para recuperar los datos de métricas y trazar los gráficos.
4. Use el explorador de Azure Storage para validar que las métricas fluyan hacia la cuenta de almacenamiento.
Si no se recopilan métricas, siga la guía de solución de problemas de la extensión de Azure Diagnostics.
Pasos siguientes
Más información sobre la introducción al Explorador de métricas
Más información sobre las características avanzadas del Explorador de métricas
Vea una lista de métricas disponibles para servicios de Azure
Vea ejemplos de gráficos configurados
Reglas de recopilación de datos en Azure Monitor
(versión preliminar)
Las reglas de recopilación de datos (DCR) definen los datos que entran en Azure Monitor y especifican dónde se
deben enviar los datos o almacenarlos. En este artículo se proporciona información general sobre las reglas de
recopilación de datos, incluido su contenido y su estructura, y cómo puede crearlas y trabajar con ellas.
Orígenes de entrada
Las reglas de recopilación de datos admiten actualmente los siguientes orígenes de entrada:
Máquina virtuales de Azure con el agente de Azure Monitor. Consulte Configuración de la recopilación de datos
para el agente de Azure Monitor (versión preliminar).
Componentes de una regla de recopilación de datos

Una regla de recopilación de datos incluye los siguientes componentes.
C O M P O N EN T E DESC RIP C IÓ N
Orígenes de datos Origen único de los datos de supervisión con su propio

formato y método para exponer los datos. Entre los ejemplos
de origen de datos se incluyen el registro de eventos de
Windows, los contadores de rendimiento y syslog. Cada
origen de datos coincide con un tipo de origen de datos
determinado tal y como se describe a continuación.
Secuencias Identificador único que describe un conjunto de orígenes de

datos que se transformarán y se esquematizarán como un
tipo. Cada origen de datos requiere una o varias secuencias;
varios orígenes de datos pueden utilizar una secuencia. Todos
los orígenes de datos de una secuencia comparten un
esquema común. Por ejemplo, puede usar varias secuencias si
desea enviar un origen de datos determinado a varias tablas
en el mismo área de trabajo de Log Analytics.
Destinations Conjunto de destinos donde deben enviarse los datos.

Algunos ejemplos son el área de trabajo de Log Analytics,
Métricas de Azure Monitor y Event Hubs de Azure.
Flujos de datos Definición de las secuencias que se deben enviar a los

destinos.
En el diagrama siguiente se muestran los componentes de una regla de recopilación de datos y su relación
Tipos de origen de datos
Cada origen de datos tiene un tipo de origen de datos. Cada tipo define un conjunto único de propiedades que se
deben especificar para cada origen de datos. Los tipos de orígenes de datos disponibles actualmente se muestran
en la tabla siguiente.
T IP O DE O RIGEN DE DATO S DESC RIP C IÓ N
extensión Origen de datos basado en la extensión de máquina virtual
performanceCounters Contadores de rendimiento para Windows y Linux
syslog Eventos de Syslog en Linux
windowsEventLogs Registro de eventos de Windows
Límites
En la tabla siguiente se enumeran los límites que se aplican actualmente a cada regla de recopilación de datos.
L ÍM IT E VA L UE
Número máximo de orígenes de datos 10
Número máximo de especificadores de contador en el 100

contador de rendimiento
Número máximo de nombres de utilidades en Syslog 20
Número máximo de consultas XPath en el registro de eventos 100
Número máximo de flujos de datos 10
Número máximo de flujos de datos 10
Número máximo de extensiones 10
Tamaño máximo de la configuración de la extensión 32 Kb
Número máximo de áreas de trabajo de Log Analytics 10
Creación de una regla de recopilación de datos

Actualmente hay dos métodos disponibles para crear una regla de recopilación de datos:
Use Azure Portal para crear una regla de recopilación de datos y asociarla a una o varias máquinas virtuales.
Editar directamente la regla de recopilación de datos en el archivo JSON y enviarla mediante la API de REST.
Eliminación de una regla de recopilación de datos

La siguiente regla de recopilación de datos de ejemplo es para las máquinas virtuales con el agente de
administración de Azure y tiene los detalles siguientes:
Datos de rendimiento
Recopila los contadores de procesador, memoria, disco lógico y disco físico específicos cada
15 segundos, y se carga cada minuto.
Recopila los contadores de proceso específicos cada 30 segundos y los carga cada 5 minutos.
Eventos de Windows
Recopila eventos de seguridad de Windows y los carga cada minuto.
Recopila eventos del sistema y de aplicación de Windows, y los carga cada 5 minutos.
syslog
Recopila eventos de depuración, críticos y de emergencia desde la utilidad cron.
Recopila eventos de alerta, críticos y de emergencia desde la utilidad syslog.
Destinations
Envía todos los datos a un área de trabajo de Log Analytics denominada centralWorkspace.
{
"location": "eastus",
"properties": {
"dataSources": {
{
"name": "cloudTeamCoreCounters",
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 15,
"counterSpecifiers": [
"\\Processor(_Total)\\% Processor Time",
"\\Memory\\Committed Bytes",
"\\LogicalDisk(_Total)\\Free Megabytes",
"\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"
]
},
{
"name": "appTeamExtraCounters",
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 30,
"counterSpecifiers": [
"\\Process(_Total)\\Thread Count"
]
}
],
"windowsEventLogs": [
{
"name": "cloudSecurityTeamEvents",
"streams": [
"Microsoft-WindowsEvent"
],
"xPathQueries": [
"Security!*"
]
},
{
"name": "appTeam1AppEvents",
"streams": [
],
"xPathQueries": [
"System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",
"Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"
]
}
],
"syslog": [
{
"name": "cronSyslog",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"cron"
],
"logLevels": [
"Debug",
"Critical",
"Emergency"
]
},
{
"name": "syslogBase",
"streams": [
"Microsoft-Syslog"
],
"facilityNames": [
"syslog"
],
"logLevels": [
"Alert",
"Critical",
"Emergency"
]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-
resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",
"name": "centralWorkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-Perf",
"Microsoft-Syslog",
],
"destinations": [
"centralWorkspace"
]
}
]
}
}
}
Pasos siguientes
Cree una regla de recopilación de datos y una asociación a ella desde una máquina virtual mediante el agente
de Azure Monitor.
Orígenes de datos de agente en Azure Monitor
Los orígenes de datos que configura definen los datos que recopila Azure Monitor de los agentes. Los datos de
los agentes se almacenan como datos de registro con un conjunto de registro. Cada origen de datos crea
registros de un tipo determinado, donde cada tipo tiene su propio conjunto de propiedades.
Resumen de orígenes de datos

En la tabla siguiente se enumeran los orígenes de datos de agente que actualmente se encuentran disponibles
en Azure Monitor. Cada uno de ellos tiene un vínculo a un artículo independiente, donde se proporcionan
detalles con respecto al origen de datos determinado. También se proporciona información sobre el método y
la frecuencia de recopilación.
SE EN VÍA N
LO S DATO S
DEL
A GEN T E DE
O P ERAT IO
NS
M A N A GER
¿SE A T RAVÉS
A GEN T E DE REQ UIERE DEL GRUP O F REC UEN C I
A GEN T E DE O P ERAT IO A L M A C EN O P ERAT IO DE A DE
O RIGEN DE P L ATA F O R LO G NS A M IEN TO NS A DM IN IST R REC O P IL A C
DATO S MA A N A LY T IC S M A N A GER DE A Z URE M A N A GER? A C IÓ N IÓ N
Registros Windows • a la llegada

personaliza
dos
Registros Linux • a la llegada

personaliza
dos
SE EN VÍA N
LO S DATO S
DEL
A GEN T E DE
O P ERAT IO
NS
M A N A GER
¿SE A T RAVÉS
A GEN T E DE REQ UIERE DEL GRUP O F REC UEN C I
A GEN T E DE O P ERAT IO A L M A C EN O P ERAT IO DE A DE
O RIGEN DE P L ATA F O R LO G NS A M IEN TO NS A DM IN IST R REC O P IL A C
DATO S MA A N A LY T IC S M A N A GER DE A Z URE M A N A GER? A C IÓ N IÓ N
Registros Windows • • • depende de

de IIS la
configuraci
ón de la
sustitución
incremental
de archivos
de registro
Contadores Windows • • mínimo de

de 10
rendimient segundos,
o según lo
programad
o
Contadores Linux • mínimo de

de 10
rendimient segundos,
o según lo
programad
o
Syslog Linux • Del

almacenami
ento de
Azure: 10
minutos;
del agente:
a la llegada
Registros Windows • • • • a la llegada

de eventos
de
Windows
Configuración de orígenes de datos

Los orígenes de datos se configuran en el menú Datos en Configuración avanzada del área de trabajo.
Cualquier configuración se proporciona a todos los orígenes conectados del área de trabajo. Actualmente, no
puede excluir ningún agente de esta configuración.
1. En Azure Portal, seleccione las áreas de trabajo de Log Analytics > su área de trabajo > Configuración
avanzada .
2. Seleccione Datos .
3. Haga clic en el origen de datos que quiere configurar.
4. Siga el vínculo a la documentación correspondiente a cada origen de datos de la tabla anterior para obtener
detalles sobre su configuración.
datos, recopilación
Las configuraciones de orígenes de datos se entregan en cuestión de minutos a los agentes que están
directamente conectados con Azure Monitor. Los datos especificados se recopilan desde el agente y se entregan
directamente a Azure Monitor a intervalos específicos a cada origen de datos. Consulte la documentación de
cada origen de datos para ver estas especificaciones.
En el caso de los agentes de System Center Operations Manager de un grupo de administración conectado, la
configuración de origen de datos se convierte en módulos de administración y se proporciona al grupo de
administración cada 5 minutos, de manera predeterminada. El agente descarga el módulo de administración de
la forma habitual y recopila los datos especificados. En función del origen de datos, los datos se enviarán a un
servidor de administración que los reenvía a Azure Monitor o el agente los enviará a Azure Monitor sin pasar
por el servidor de administración. Consulte Detalles de la recopilación de datos para las soluciones de
supervisión en Azure para más información. Puede leer detalles sobre cómo conectar Operations Manager y
Azure Monitor y modificar la frecuencia con que la configuración se proporciona en Configuración de
integración con System Center Operations Manager.
Si el agente no puede conectarse a Azure Monitor u Operations Manager, continuará recopilando datos para
entregarlos cuando se establezca la conexión. Si el volumen de datos alcanza el tamaño máximo de la memoria
caché del cliente o si el agente no es capaz de establecer conexión en un plazo de 24 horas, los datos pueden
perderse.
Entradas de registros
Todos los datos que recopila Azure Monitor se almacenan en el área de trabajo como registros. Los registros
que recopilan distintos orígenes de datos tendrán su propio conjunto de propiedades y se identificar por su
propiedad Type . Consulte la documentación de cada origen de datos y solución para obtener detalles sobre
cada tipo de registro.
Pasos siguientes
Conozca las soluciones de supervisión que agregan funcionalidad a Azure Monitor y que también recopilan
datos en el área de trabajo.
Obtenga información acerca de las consultas de registros para analizar los datos recopilados de soluciones
de supervisión y orígenes de datos.
Configure alertas que le notifiquen de manera proactiva acerca de los datos críticos recopilados de
soluciones de supervisión y orígenes de datos.
Orígenes de datos de registros de eventos de
Windows en Azure Monitor
Muchas aplicaciones escriben en el registro de eventos de Windows, por lo que constituye uno de los orígenes
de datos más comunes para recopilar información mediante agentes de Windows. Puede recopilar eventos de
registros estándar, como el sistema y la aplicación, además de especificar cualquier registro personalizado
creado por las aplicaciones que debe supervisar.
Configuración de registros de eventos de Windows

Configure los registros de eventos de Windows en el menú Datos en Configuración avanzada.
Azure Monitor solo recopila eventos de los registros de eventos de Windows que se especifican en la
configuración. Para agregar un registro nuevo, escriba el nombre y haga clic en + . Para cada registro, solo se
recopilan los eventos con los niveles de gravedad seleccionados. Compruebe las gravedades del registro
determinado que desea recopilar. No puede proporcionar criterios adicionales para filtrar eventos.
A medida que escribe el nombre de un registro de eventos, Azure Monitor da sugerencias de nombres comunes
de este tipo de registros. Aun cuando el registro que desea agregar no aparezca en la lista, puede incluirlo
escribiendo su nombre completo. Encontrará el nombre completo del registro en el Visor de eventos. En el Visor
de eventos, abra la página Propiedades del registro y copie la cadena del campo Nombre completo.
NOTE
Los eventos críticos del registro de eventos de Windows tendrán una gravedad de "error" en los registros de Azure
Monitor.
Azure Monitor recopila cada evento que coincide con una gravedad seleccionada de un registro de eventos
supervisado al crear el evento. El agente registra su lugar en cada registro de eventos del que recopila entradas.
Si el agente queda sin conexión durante un período, recopila los eventos desde donde quedó, aunque esos
eventos se hayan creado mientras el agente estaba sin conexión. Sin embargo, existe la posibilidad de que estos
eventos no se recopilen si el registro de eventos hace que los eventos no recopilados se sobrescriban mientras
el agente está sin conexión.
NOTE
Azure Monitor no recopila eventos de auditoría creados por SQL Server del origen MSSQLSERVER con un identificador de
evento 18453 que contenga las palabras clave Classic o Audit Success y la palabra clave 0xa0000000000000.
Propiedades de los registros de eventos de Windows

Los registros de eventos de Windows tienen un tipo Event y las propiedades que aparecen en la tabla siguiente:
Computer Nombre del equipo desde el que se recopiló el evento.
EventCategory Categoría del evento.
EventData Todos los datos con formato sin procesar.
EventId El número del evento.
EventLevel La gravedad del evento en formato numérico.
EventLevelName La gravedad del evento en formato de texto.
EventLog El nombre del registro de eventos desde el que se recopiló el

evento.
ParameterXml Los valores de parámetro de evento en formato XML.
ManagementGroupName Nombre del grupo de administración de agentes de System

Center Operations Manager. En el caso de los otros agentes,
este valor es AOI-<workspace ID> .
RenderedDescription La descripción del evento con valores de parámetro.
Source Origen del evento.

SourceSystem El tipo de agente desde el que se recopiló el evento.

OpsManager: agente de Windows, ya sea una conexión
directa o administrado por Operations Manager
Linux: todos los agentes de Linux.
AzureStorage: Diagnósticos de Azure
TimeGenerated La fecha y la hora de creación del evento en Windows.
UserName El nombre de usuario de la cuenta que registró el evento.
Consultas de registros con eventos de Windows

La tabla siguiente proporciona distintos ejemplos de consultas de registros que recuperan registros de eventos
de Windows.
C O N SULTA R DESC RIP C IÓ N
Evento Todos los eventos de Windows.
Event | where EventLevelName == "error" Todos los eventos de Windows con gravedad de error.
Event | summarize count() by Source Contador de eventos de Windows por origen.
Event | where EventLevelName == "error" | summarize Contador de eventos de error de Windows por origen.
count() by Source
Pasos siguientes
Configure Log Analytics para recopilar otros orígenes de datos para su análisis.
orígenes de datos.
Configure la recopilación de contadores de rendimiento desde los agentes de Windows.
Recopilación de orígenes de datos JSON
personalizados con el agente de Log Analytics para
Linux en Azure Monitor
NOTE
Como parte de la transición en curso de Microsoft Operations Management Suite (OMS) a Azure Monitor, se hará referencia
al agente de Operations Management Suite para Windows o Linux como el agente de Log Analytics para Windows y el
agente de Log Analytics para Linux.
Los orígenes de datos JSON personalizados se pueden recopilar en Azure Monitor mediante el agente de Log
Analytics para Linux. Estos orígenes de datos personalizados pueden ser scripts simples que devuelven JSON, como
curl o uno de los más de 300 complementos de FluentD. En este artículo se describe la configuración necesaria
para esta recopilación de datos.
NOTE
El agente de Log Analytics para Linux (versión v1.1.0-217 y posteriores) es necesario para los datos JSON personalizados.
Configuración
Configuración del complemento de entrada
Para recopilar datos JSON en Azure Monitor, agregue oms.api. al principio de una etiqueta de FluentD en un
complemento de entrada.
Por ejemplo, el siguiente es un archivo de configuración independiente exec-json.conf en
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/ . Este archivo usa el complemento exec de FuentD
para ejecutar un comando de curl cada 30 segundos. La salida de este comando se recopila mediante el
complemento de salida JSON.
<source>
type exec
command 'curl localhost/json.output'
format json
tag oms.api.httpresponse
run_interval 30s
</source>
<match oms.api.httpresponse>
type out_oms_api
log_level info
buffer_chunk_limit 5m
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms_api_httpresponse*.buffer
buffer_queue_limit 10
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
Será necesario cambiar la propiedad del archivo de configuración agregado bajo

/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/ con el siguiente comando.
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/conf/omsagent.d/exec-json.conf
Configuración del complemento de salida

Agregue la siguiente configuración de complemento de salida a la configuración principal en
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf o como un archivo de configuración independiente
colocado en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/ .
<match oms.api.**>
type out_oms_api
log_level info
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms_api*.buffer
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
Reiniciar el agente de Log Analytics para Linux

Reinicie el servicio del agente de Log Analytics para Linux con el siguiente comando.
sudo /opt/microsoft/omsagent/bin/service_control restart
Output
Los datos se recopilarán en Azure Monitor con un tipo de registro de <FLUENTD_TAG>_CL .
Por ejemplo, la etiqueta personalizada tag oms.api.tomcat en Azure Monitor con un tipo de registro de tomcat_CL .
Podría recuperar todos los registros de este tipo con la consulta de registros siguiente.
Type=tomcat_CL
Se admiten datos JSON anidados, pero se indexan en función del campo principal. Por ejemplo, se devuelven los
datos JSON siguientes desde una consulta de registro como tag_s : "[{ "a":"1", "b":"2" }] .
{
"tag": [{
"a":"1",
"b":"2"
}]
}
Pasos siguientes
orígenes de datos.
Recopilación de datos de CollectD en agentes de
CollectD es un demonio de Linux de código abierto que recopila periódicamente métricas de rendimiento de
aplicaciones e información de nivel de sistema. Las aplicaciones de ejemplo incluyen la máquina virtual Java (JVM),
MySQL Server y Nginx. En este artículo se proporciona información sobre la recopilación de datos de rendimiento
de CollectD en Azure Monitor.
Puede encontrar una lista completa de los complementos disponibles en la tabla de complementos.
La siguiente configuración de CollectD se incluye en el agente de Log Analytics para Linux con el fin de enrutar los
datos de CollectD al agente de Log Analytics para Linux.
NOTE
LoadPlugin write_http
<Plugin write_http>
<Node "oms">
URL "127.0.0.1:26000/oms.collectd"
Format "JSON"
StoreRates true
</Node>
</Plugin>
Además, si va a usar una versión de CollectD anterior a la 5.5, utilice en su lugar la siguiente configuración.
LoadPlugin write_http
<Plugin write_http>
<URL "127.0.0.1:26000/oms.collectd">
Format "JSON"
StoreRates true
</URL>
</Plugin>
La configuración de CollectD usa el complemento write_http predeterminado para enviar datos de métricas de
rendimiento al agente de Log Analytics para Linux mediante el puerto 26000.
NOTE
Este puerto se puede configurar como un puerto definido de forma personalizada, en caso necesario.
El agente de Log Analytics para Linux también escucha en el puerto 26000 las métricas de CollectD y, después, las
convierte a métricas de esquema de Azure Monitor. Esta es la configuración del agente de Log Analytics para Linux:
collectd.conf .
<source>
type http
port 26000
bind 127.0.0.1
</source>
<filter oms.collectd>
type filter_collectd
</filter>
NOTE
CollectD se configura de forma predeterminada para leer valores a un intervalo de 10 segundos. Como esto afecta
directamente al volumen de datos que se envían a los registros de Azure Monitor, puede que tenga que ajustar este intervalo
dentro de la configuración de CollectD para lograr un buen equilibrio entre los requisitos de supervisión y los costos y el uso
asociados de los registros de Azure Monitor.
Versiones admitidas
En la actualidad, Azure Monitor admite CollectD 4.8 y versiones superiores.
Para la recopilación de métricas de CollectD, se necesita el agente de Log Analytics para Linux versión 1.1.0-217
o posteriores.
Configuración
Estos son los pasos básicos para configurar la recopilación de datos de CollectD en Azure Monitor.
1. Configure CollectD para enviar datos al agente de Log Analytics para Linux mediante el complemento
write_http.
2. Configure el agente de Log Analytics para Linux de forma que escuche datos de CollectD en el puerto adecuado.
3. Reinicie CollectD y el agente de Log Analytics para Linux.
Configuración de CollectD para reenviar datos
1. Para enrutar los datos de CollectD al agente de Log Analytics para Linux, es necesario agregar oms.conf al
directorio de configuración de CollectD. El destino de este archivo depende de la distribución de Linux de su
máquina.
Si su directorio de configuración de CollectD está ubicado en /etc/collectd.d/:
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/oms.conf /etc/collectd.d/oms.conf
Si su directorio de configuración de CollectD está ubicado en /etc/collectd/collectd.conf.d/:

sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/oms.conf /etc/collectd/collectd.conf.d/oms.conf
NOTE
Para las versiones de CollectD anteriores a la 5.5, deberá modificar las etiquetas de oms.conf , como se mostró
anteriormente.
2. Copie collectd.conf en el directorio de configuración deseado de omsagent del área de trabajo.
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.d/collectd.conf
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/collectd.conf
3. Reinicie CollectD y el agente de Log Analytics para Linux con los comandos siguientes.
sudo service collectd restart

sudo /opt/microsoft/omsagent/bin/service_control restart
Conversión de métricas de CollectD en esquemas de Azure Monitor

Para mantener un modelo conocido entre las métricas de infraestructura ya recopiladas por el agente de Log
Analytics para Linux y las nuevas métricas recopiladas por CollectD, se usa la siguiente asignación de esquemas:
C A M P O DE M ÉT RIC A DE C O L L EC T D C A M P O DE A Z URE M O N ITO R
host Computer
plugin None
plugin_instance Nombre de instancia

Si plugin_instance es null, entonces InstanceName ="
_Total".
type ObjectName
type_instance CounterName
Si type_instance es null, entonces CounterName=en
blanco .
dsnames[] CounterName
dstypes None
values[] CounterValue
Pasos siguientes
orígenes de datos.
Use Campos personalizados para analizar datos de registros de Syslog en campos individuales.
Orígenes de datos de Syslog en Azure Monitor
Syslog es un protocolo de registro de eventos que es común a Linux. Las aplicaciones envían mensajes que
pueden almacenarse en la máquina local o entregarse a un recopilador de Syslog. Al instalar el agente de Log
Analytics para Linux, este configura el demonio Syslog local para que reenvíe mensajes al agente. En ese
momento, el agente envía el mensaje a Azure Monitor, donde se crea un registro correspondiente.
NOTE
Azure Monitor admite la recopilación de mensajes enviados por rsyslog o syslog-ng, donde rsyslog es el demonio
predeterminado. El demonio predeterminado de Syslog en la versión 5 de Red Hat Enterprise Linux, CentOS y Oracle Linux
(Sysklog) no se admite para la recopilación de eventos de Syslog. Para recopilar datos de Syslog de esta versión de estas
distribuciones, es necesario instalar el demonio rsyslog y configurarlo para reemplazar Sysklog.
Los recursos siguientes son compatibles con el recopilador de Syslog:

kern
usuario
mail
daemon
auth
syslog
lpr
news
uucp
cron
authpriv
ftp
local0-local7
Para cualquier otro recurso, configure un origen de datos de registros personalizados en Azure Monitor.
Configuración de Syslog
El agente de Log Analytics para Linux solo recopilará los eventos con los recursos y los niveles de gravedad que
se especifican en su configuración. Puede configurar Syslog a través de Azure Portal o mediante la
administración de archivos de configuración de sus agentes de Linux.
Configuración de Syslog en Azure Portal
Configure Syslog desde el menú de datos en la configuración avanzada. Esta configuración se entrega al archivo
de configuración de cada agente de Linux.
Para agregar una nueva instalación, seleccione primero la opción Aplicar la configuración siguiente a mis
máquinas , escriba su nombre y haga clic en + . Para cada recurso, solo se recopilarán los mensajes con los
niveles de gravedad seleccionados. Compruebe los niveles de gravedad del recurso determinado que desea
recopilar. No puede proporcionar criterios adicionales para filtrar mensajes.
De forma predeterminada, todos los cambios realizados en la configuración se insertan automáticamente en

todos los agentes. Si desea configurar Syslog manualmente en cada uno de los agentes de Linux, desactive la
casilla Aplicar la configuración siguiente a mis máquinas.
Configuración de Syslog en agente de Linux
Cuando el agente de Log Analytics se instala en un cliente Linux, instala un archivo de configuración de Syslog
predeterminado que define el recurso y la gravedad de los mensajes que se recopilan. Puede modificar este
archivo para cambiar la configuración. El archivo de configuración es diferente según el demonio Syslog que ha
instalado el cliente.
NOTE
Si modifica la configuración de Syslog, tiene que reiniciar el demonio Syslog para que los cambios surtan efecto.
rsyslog
El archivo de configuración de rsyslog se encuentra en /etc/rsyslog.d/95-omsagent.conf . A continuación se
muestra su contenido predeterminado. Recopila mensajes de Syslog enviados desde el agente local para todos
los recursos con, al menos, un nivel de advertencia.
kern.warning @127.0.0.1:25224
user.warning @127.0.0.1:25224
daemon.warning @127.0.0.1:25224
auth.warning @127.0.0.1:25224
syslog.warning @127.0.0.1:25224
uucp.warning @127.0.0.1:25224
authpriv.warning @127.0.0.1:25224
ftp.warning @127.0.0.1:25224
cron.warning @127.0.0.1:25224
local0.warning @127.0.0.1:25224
local1.warning @127.0.0.1:25224
local2.warning @127.0.0.1:25224
local3.warning @127.0.0.1:25224
local4.warning @127.0.0.1:25224
local5.warning @127.0.0.1:25224
local6.warning @127.0.0.1:25224
local7.warning @127.0.0.1:25224
Para quitar un recurso, elimine su sección del archivo de configuración. Puede limitar los niveles de gravedad
que se recopilan para un recurso determinado mediante la modificación de la entrada de ese recurso. Por
ejemplo, para limitar el recurso del usuario a mensajes con una gravedad de error o superior, debe modificar esa
línea del archivo de configuración de la siguiente manera:
user.error @127.0.0.1:25224
syslog-ng
El archivo de configuración de syslog-ng se encuentra en /etc/syslog-ng/syslog-ng.conf . A continuación se
muestra su contenido predeterminado. Recopila mensajes de Syslog enviados desde el agente local para todos
los recursos y todos los niveles de gravedad.
#
# Warnings (except iptables) in one file:
#
destination warn { file("/var/log/warn" fsync(yes)); };
log { source(src); filter(f_warn); destination(warn); };
#OMS_Destination
destination d_oms { udp("127.0.0.1" port(25224)); };
#OMS_facility = auth
filter f_auth_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(auth); };
log { source(src); filter(f_auth_oms); destination(d_oms); };
#OMS_facility = authpriv
filter f_authpriv_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(authpriv); };
log { source(src); filter(f_authpriv_oms); destination(d_oms); };
#OMS_facility = cron
filter f_cron_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(cron); };
log { source(src); filter(f_cron_oms); destination(d_oms); };
#OMS_facility = daemon
filter f_daemon_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(daemon); };
log { source(src); filter(f_daemon_oms); destination(d_oms); };
#OMS_facility = kern
filter f_kern_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(kern); };
log { source(src); filter(f_kern_oms); destination(d_oms); };
#OMS_facility = local0
filter f_local0_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local0); };
log { source(src); filter(f_local0_oms); destination(d_oms); };
#OMS_facility = local1
filter f_local1_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(local1); };
log { source(src); filter(f_local1_oms); destination(d_oms); };
#OMS_facility = mail
filter f_mail_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(mail); };
log { source(src); filter(f_mail_oms); destination(d_oms); };
#OMS_facility = syslog
filter f_syslog_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(syslog); };
log { source(src); filter(f_syslog_oms); destination(d_oms); };
#OMS_facility = user
filter f_user_oms { level(alert,crit,debug,emerg,err,info,notice,warning) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
Para quitar un recurso, elimine su sección del archivo de configuración. Puede limitar los niveles de gravedad
que se recopilan de un recurso determinado, para lo que debe eliminarlos de la lista. Por ejemplo, para limitar el
recurso del usuario solo a mensajes de alerta y críticos, debe modificar la sección del archivo de configuración de
la siguiente manera:
#OMS_facility = user
filter f_user_oms { level(alert,crit) and facility(user); };
log { source(src); filter(f_user_oms); destination(d_oms); };
Recopilación de datos de puertos de Syslog adicionales

El agente de Log Analytics escucha los mensajes de Syslog en el cliente local en el puerto 25224. Cuando se
instala el agente, se aplica una configuración de Syslog predeterminada, que se encuentra en la siguiente
ubicación:
Rsyslog: /etc/rsyslog.d/95-omsagent.conf
Syslog-ng: /etc/syslog-ng/syslog-ng.conf
Puede cambiar el número de puerto si crea dos archivos de configuración: un archivo de configuración de
FluentD y un archivo rsyslog-or-syslog-ng según el demonio Syslog que haya instalado.
El archivo de configuración de FluentD debe ser un nuevo archivo ubicado en:
/etc/opt/microsoft/omsagent/conf/omsagent.d ; reemplace el valor de la entrada por t por el número de
puerto personalizado.
<source>
type syslog
port %SYSLOG_PORT%
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>
<filter oms.syslog.**>
type filter_syslog
Para rsyslog, debe crear un archivo de configuración ubicado en: /etc/rsyslog.d/ ; reemplace el valor
%SYSLOG_PORT% por el número de puerto personalizado.
NOTE
Si modifica este valor en el archivo de configuración 95-omsagent.conf , se sobrescribirá cuando el agente aplique
una configuración predeterminada.
# OMS Syslog collection for workspace %WORKSPACE_ID%

kern.warning @127.0.0.1:%SYSLOG_PORT%
user.warning @127.0.0.1:%SYSLOG_PORT%
daemon.warning @127.0.0.1:%SYSLOG_PORT%
auth.warning @127.0.0.1:%SYSLOG_PORT%
Para modificar la configuración de syslog-ng, copie la configuración del ejemplo que se muestra a
continuación y agregue la configuración modificada personalizada al final del archivo de configuración
syslog-ng.conf ubicado en /etc/syslog-ng/ . No use la etiqueta predeterminada
%WORKSPACE_ID%_oms ni %WORKSPACE_ID_OMS ; defina una etiqueta personalizada para ayudar
a distinguir los cambios.
NOTE
Si modifica los valores predeterminados en el archivo de configuración, se sobrescribirán cuando el agente aplique
una configuración predeterminada.
filter f_custom_filter { level(warning) and facility(auth; };

destination d_custom_dest { udp("127.0.0.1" port(%SYSLOG_PORT%)); };
log { source(s_src); filter(f_custom_filter); destination(d_custom_dest); };
Después de completar los cambios, Syslog y el servicio de agente de Log Analytics deben reiniciarse para
asegurarse de que los cambios de configuración surtan efecto.
Propiedades de registros de Syslog

Los registros de Syslog tienen un tipo Syslog y las propiedades que aparecen en la tabla siguiente.
Facility Define la parte del sistema que ha generado el mensaje.
HostIP Dirección IP del sistema que envía el mensaje.
HostName Nombre del sistema que envía el mensaje.
SeverityLevel Nivel de gravedad del evento.
SyslogMessage Texto del mensaje.
ProcessID Identificador del proceso que ha generado el mensaje.
EventTime Fecha y hora en que se generó el evento.
Consultas de registro con registros de Syslog

La tabla siguiente proporciona ejemplos distintos de consultas de registro que recuperan registros de Syslog.
syslog Todos los registros de Syslog.
Syslog | where SeverityLevel == "error" Todos los registros de Syslog con gravedad de error.
Syslog | summarize AggregatedValue = count() by Computer Número de registros de Syslog por equipo.
Syslog | summarize AggregatedValue = count() by Facility Número de registros de Syslog por recurso.
Pasos siguientes
orígenes de datos.
Use Campos personalizados para analizar datos de registros de Syslog en campos individuales.
Configure agentes de Linux para recopilar otros tipos de datos.
Orígenes de datos de rendimiento de Windows y
Los contadores de rendimiento de Windows y Linux ofrecen información acerca del rendimiento de los
componentes de hardware, los sistemas operativos y las aplicaciones. Azure Monitor puede recopilar
contadores de rendimiento a intervalos frecuentes para el análisis casi en tiempo real (NRT), además de
agregar datos de rendimiento para el análisis a más largo plazo y la creación de informes.
Configuración de contadores de rendimiento

Los contadores de rendimiento se configuran en el menú Datos en Configuración avanzada.
La primera vez que se configuran los contadores de rendimiento de Windows o Linux para un área de trabajo
nueva, se proporciona la opción de crear rápidamente varios contadores comunes. Se muestran todos con una
casilla junto a cada uno. Asegúrese de que están marcados todos los contadores que desea crear inicialmente
y, luego, haga clic en Add the selected performance counters (Agregar los contadores de rendimiento
seleccionados).
Para los contadores de rendimiento de Windows, puede elegir una instancia específica para cada contador de
rendimiento. Para los contadores de rendimiento de Linux, la instancia de cada contador que elija se aplica a
todos los contadores secundarios del contador primario. La siguiente tabla muestra las instancias comunes
disponibles para los contadores de rendimiento de Windows y de Linux.
N O M B RE DE IN STA N C IA DESC RIP C IÓ N
_Total Total de todas las instancias
* Todas las instancias
(/|/var) Coincide con las instancias con nombre: / o /var
Contadores de rendimiento de Windows

Siga este procedimiento para agregar un nuevo contador de rendimiento de Windows para recopilar.
1. Escriba el nombre del contador en el cuadro de texto con el formato objeto(instancia)\contador. Cuando
empiece a escribir, aparece una lista de contadores comunes coincidentes. Puede seleccionar un
contador de la lista o escribir uno propio. También puede devolver todas las instancias de un contador
determinado, para lo que debe especificar objeto\contador.
Cuando se recopilan contadores de rendimiento de SQL Server de instancias con nombre, todos los
contadores de instancias con nombre comienzan por MSSQL$ y van seguidos del nombre de la
instancia. Por ejemplo, para recopilar el contador Frecuencia de aciertos de caché de registro para todas
las bases de datos desde el objeto de rendimiento de base de datos para la instancia de SQL con
nombre INST2, especifique MSSQL$INST2:Databases(*)\Log Cache Hit Ratio .
2. Haga clic en + o presione ENTRAR para agregar el contador a la lista.
3. Cuando se agrega un contador, se usa el valor predeterminado de 10 segundos en Inter valo de
ejemplo . Este valor se puede cambiar por otro mayor, siempre que no supere los 1800 segundos (30
minutos), en caso de que se desee reducir los requisitos de almacenamiento de los datos de
rendimiento recopilados.
4. Cuando haya terminado de agregar contadores, haga clic en el botón Guardar de la parte superior de
la pantalla para guardar la configuración.
Contadores de rendimiento de Linux
Siga este procedimiento para agregar un nuevo contador de rendimiento de Linux para recopilar.
1. De forma predeterminada, todos los cambios realizados en la configuración se insertan automáticamente
en todos los agentes. En el caso de los agentes de Linux, se envía un archivo de configuración al recopilador
de datos Fluentd. Si desea modificar este archivo manualmente en cada agente de Linux, desactive la casilla
Aplicar la configuración que aparece a continuación a mis máquinas con Linux.
2. Escriba el nombre del contador en el cuadro de texto con el formato objeto(instancia)\contador. Cuando
empiece a escribir, aparece una lista de contadores comunes coincidentes. Puede seleccionar un contador
de la lista o escribir uno propio.
3. Haga clic en + o presione ENTRAR para agregar el contador a la lista de contadores del objeto.
4. Todos los contadores de un objeto usan el mismo valor en Inter valo de ejemplo . El valor predeterminado
es 10 segundos. Este valor se puede cambiar por otro mayor, siempre que no supere los 1800 segundos
(30 minutos), en caso de que se desee reducir los requisitos de almacenamiento de los datos de
rendimiento recopilados.
5. Cuando haya terminado de agregar contadores, haga clic en el botón Guardar de la parte superior de la
pantalla para guardar la configuración.
Configuración de contadores de rendimiento de Linux en el archivo de configuración
En lugar de configurar los contadores de rendimiento de Linux mediante Azure Portal, tiene la opción de
editar archivos de configuración en el agente de Linux. Las métricas de rendimiento para recopilar se controlan
mediante la configuración en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf .
Cada objeto, o categoría, de métricas de rendimiento para recopilar debe definirse en el archivo de
configuración como un solo elemento <source> . La sintaxis sigue el modelo siguiente.
<source>
type oms_omi
object_name "Processor"
instance_regex ".*"
counter_name_regex ".*"
interval 30s
</source>
Los parámetros de este elemento se describen en la tabla siguiente.

PA RÁ M ET RO S DESC RIP C IÓ N
object_name Nombre de objeto de la colección.
instance_regex Una expresión regular que define las instancias que desea
recopilar. El valor: .* especifica todas las instancias. Para
recopilar métricas de procesador solamente de la instancia
_Total, puede especificar _Total . Para recopilar métricas
de procesamiento solamente de las instancias rond o sshd,
puede especificar (crond\|sshd) .
counter_name_regex Una expresión regular que define los contadores (para el

objeto) que desea recopilar. Para recopilar todos los
contadores para el objeto, especifique: .* . Para recopilar,
por ejemplo, solo contadores de espacio de intercambio
para el objeto de memoria, puede especificar: .+Swap.+
interval Frecuencia con la que se recopilan los contadores del

objeto.
En la tabla siguiente se enumera los objetos y contadores que pueden especificar en el archivo de
configuración. Hay contadores adicionales disponibles para determinadas aplicaciones, como se describe en
Collect performance counters for Linux applications in Azure Monitor (Recopilación de contadores de
rendimiento para aplicaciones de Linux en Azure Monitor).
N O M B RE DE O B JETO N O M B RE DEL C O N TA DO R
Disco lógico % de Inodes libres
Disco lógico % de espacio libre
Disco lógico % de Inodes usados
Disco lógico % espacio usado
Disco lógico Bytes de lectura de disco/s
Disco lógico Lecturas de disco/s
Disco lógico Transferencias de disco/s
Disco lógico Bytes de escritura en disco/s
Disco lógico Escrituras en disco/s
Disco lógico Megabytes libres
Disco lógico Bytes de disco lógico/s
Memoria % de memoria disponible
Memoria % de espacio de intercambio disponible
Memoria % de memoria usada

Memoria % de espacio de intercambio usado
Memoria MB de memoria disponibles
Memoria Intercambio de MB disponibles
Memoria Lecturas de página/s
Memoria Escrituras de página/s
Memoria Páginas/s
Memoria Espacio de intercambio de MB usado
Memoria MB de memoria usados
Red Número total de bytes transmitidos
Red Número total de bytes recibidos
Red Número total de bytes
Red Número total de paquetes transmitidos
Red Número total de paquetes recibidos
Red Errores de Rx totales
Red Errores de Tx totales
Red Colisiones totales
Disco físico Prom. Segundos de disco/lecturas
Disco físico Prom. Segundos de disco/transferencias
Disco físico Prom. Segundos de disco/escrituras
Disco físico Bytes de disco físico/s
Proceso Porcentaje de tiempo con privilegios
Proceso Porcentaje de tiempo de usuario
Proceso Kilobytes de memoria usados
Proceso Memoria compartida virtual
Procesador % de tiempo de DPC

Procesador % de tiempo de inactividad
Procesador % de tiempo de interrupción
Procesador % de tiempo de espera de E/S
Procesador % de tiempo bueno
Procesador % de tiempo con privilegios
Procesador % de tiempo de procesador
Procesador % de tiempo de usuario
Sistema Memoria física libre
Sistema Espacio libre en archivos de paginación
Sistema Memoria virtual libre
Sistema Procesos
Sistema Tamaño almacenado en archivos de paginación
Sistema Tiempo de actividad
Sistema Usuarios
Esta es la configuración predeterminada de las métricas de rendimiento.

<source>
type oms_omi
object_name "Physical Disk"
instance_regex ".*"
interval 5m
</source>
<source>
type oms_omi
object_name "Logical Disk"
instance_regex ".*
interval 5m
</source>
<source>
type oms_omi
object_name "Processor"
instance_regex ".*
interval 30s
</source>
<source>
type oms_omi
object_name "Memory"
instance_regex ".*"
interval 30s
</source>
Azure Monitor recopila todos los contadores de rendimiento especificados en su intervalo de ejemplo en
todos los agentes que tengan dicho contador instalado. Los datos no se agregan; los datos sin procesar están
disponibles en todas las vistas de consulta de registro durante el tiempo especificado por el área de trabajo
del análisis de registros.
Propiedades de registros de rendimiento

Los registros de rendimiento tienen el tipo Perf y sus propiedades son las que aparecen en la tabla siguiente.
CounterName Nombre del contador de rendimiento.
CounterPath Ruta de acceso completa del contador en el formato \\

<Computer>\objeto(instancia)\contador.
CounterValue Valor numérico del contador.
InstanceName Nombre de la instancia del evento. Vacío si no hay

instancias.
ObjectName Nombre del objeto de rendimiento

SourceSystem Tipo de agente del que se recopilaron los datos.

directa o SCOM
AzureStorage: Diagnósticos de Azure
TimeGenerated Fecha y hora en que se toma la muestra de datos.
Estimaciones de tamaño
Una estimación aproximada para la recopilación de un contador determinado a intervalos de 10 segundos es
de aproximadamente 1 MB por día y por instancia. Los requisitos de almacenamiento de un contador se
pueden calcular con la siguiente fórmula.
1 MB x (número de contadores) x (número de agentes) x (número de instancias)
Consultas de registros con registros de rendimiento

La tabla siguiente proporciona distintos ejemplos de consultas de registros que recuperan registros de
rendimiento.
Perf Todos los datos de rendimiento
Perf | where Computer == "MyComputer" Todos los datos de rendimiento de un equipo concreto
Perf | where CounterName == "Current Disk Queue Todos los datos de rendimiento de un contador concreto
Length"
Perf | where ObjectName == "Processor" and CounterName Uso medio de CPU en todos los equipos
== "% Processor Time" and InstanceName == "_Total" |
summarize AVGCPU = avg(CounterValue) by Computer
Perf | where CounterName == "% Processor Time" | Uso máximo de CPU en todos los equipos
summarize AggregatedValue = max(CounterValue) by
Computer
Perf | where ObjectName == "LogicalDisk" and Longitud media de cola de disco actual en todas las
CounterName == "Current Disk Queue Length" and instancias de un equipo dado
Computer == "MyComputerName" | summarize
AggregatedValue = avg(CounterValue) by InstanceName
Perf | where CounterName == "Disk Transfers/sec" | Percentil 95 de transferencias de disco por segundo en
summarize AggregatedValue = percentile(CounterValue, todos los equipos
95) by Computer
Perf | where CounterName == "% Processor Time" and Promedio por hora de uso de CPU en todos los equipos
InstanceName == "_Total" | summarize AggregatedValue =
avg(CounterValue) by bin(TimeGenerated, 1h), Computer
Perf | where Computer == "MyComputer" and Percentil 70 por hora de cada contador de porcentaje %
CounterName startswith_cs "%" and InstanceName == para un equipo concreto
"_Total" | summarize AggregatedValue =
percentile(CounterValue, 70) by bin(TimeGenerated, 1h),
CounterName
Perf | where CounterName == "% Processor Time" and Promedio, mínimo, máximo y percentil 75 por hora de uso
InstanceName == "_Total" and Computer == de CPU de un equipo específico
"MyComputer" | summarize ["min(CounterValue)"] =
min(CounterValue), ["avg(CounterValue)"] =
avg(CounterValue), ["percentile75(CounterValue)"] =
percentile(CounterValue, 75), ["max(CounterValue)"] =
max(CounterValue) by bin(TimeGenerated, 1h), Computer
Perf | where ObjectName == "MSSQL$INST2:Databases" Todos los datos de rendimiento del objeto de rendimiento
and InstanceName == "master" de la base de datos para la base de datos maestra (master)
de la instancia de SQL Server con nombre INST2.
Pasos siguientes
Recopilación de contadores de rendimiento desde aplicaciones de Linux, lo que incluye MySQL y Apache
HTTP Server.
Obtenga información acerca de las consultas de registros para analizar los datos recopilados de soluciones
y orígenes de datos.
Exporte los datos recopilados a Power BI para poder realizar más análisis y tener más formas de
visualizarlos.
Recopilación de contadores de rendimiento para
aplicaciones de Linux en Azure Monitor
NOTE
En este artículo se proporciona información sobre cómo configurar el agente de Log Analytics para Linux con el
fin de recopilar contadores de rendimiento para aplicaciones específicas de Azure Monitor. Las aplicaciones
incluidas en este artículo son las siguientes:
MySQL
Servidor HTTP de Apache
MySQL
Si en el equipo se detecta un servidor de MySQL o de MariaDB al instalar el agente de Log Analytics, se instalará
automáticamente un proveedor de supervisión de rendimiento para el servidor MySQL. Este proveedor se conecta
al servidor MySQL o MariaDB local para exponer las estadísticas de rendimiento. Debe configurar las credenciales
de usuario de MySQL para que el proveedor pueda tener acceso al servidor de MySQL.
Configurar las credenciales de MySQL
El proveedor de MySQL para OMI necesita un usuario de MySQL preconfigurado y bibliotecas de cliente de
MySQL instaladas para consultar la información de rendimiento y mantenimiento de la instancia de MySQL. Estas
credenciales se almacenan en un archivo de autenticación que se almacena en el agente de Linux. El archivo de
autenticación especifica la dirección de enlace y el puerto que usa la instancia de MySQL para escuchar y las
credenciales que tiene que usar para recopilar métricas.
Durante la instalación del agente de Log Analytics para Linux, el proveedor de MySQL para OMI examinará los
archivos de configuración my.cnf de MySQL (ubicaciones predeterminadas) para identificar la dirección de enlace
y el puerto, y establecer parcialmente el archivo de autenticación de MySQL para OMI.
El archivo de autenticación de MySQL se almacena en /var/opt/microsoft/mysql-cimprov/auth/omsagent/mysql-auth .
Formato del archivo de autenticación
A continuación se muestra el formato del archivo de autenticación de MySQL para OMI.
[Port]=[Bind-Address], [username], [Base64 encoded Password]

(Port)=(Bind-Address), (username), (Base64 encoded Password)
(Port)=(Bind-Address), (username), (Base64 encoded Password)
AutoUpdate=[true|false]
Las entradas del archivo de autenticación se describen en la tabla siguiente.

Port Representa el puerto actual en el que está escuchando la

instancia de MySQL. El puerto 0 especifica que las
propiedades que siguen se usan para la instancia
predeterminada.
Dirección de enlace Dirección de enlace actual de MySQL.
username Usuario de MySQL usado para supervisar la instancia del

servidor MySQL.
Contraseña codificada en Base64 Contraseña del usuario de supervisión de MySQL codificada

en Base64.
Actualización automática Especifica si se volverán a examinar los cambios en el archivo

my.cnf y si se sobrescribirá el archivo de autenticación de
MySQL para OMI cuando el proveedor de MySQL para OMI
se actualice.
Instancia predeterminada
El archivo de autenticación de MySQL para OMI puede definir una instancia predeterminada y un número de
puerto para facilitar la administración de varias instancias de MySQL en un host de Linux. La instancia
predeterminada se indica mediante una instancia con el puerto 0. Todas las instancias adicionales heredarán las
propiedades establecidas en la instancia predeterminada, a menos que se especifiquen valores diferentes. Por
ejemplo, si se agrega la instancia de MySQL que escucha en el puerto "3308", se usará la dirección de enlace, el
nombre de usuario y la contraseña codificada en Base64 de la instancia predeterminada para probar y supervisar
la instancia que escucha en 3308. Si la instancia en 3308 está enlazada a otra dirección y usa el mismo par de
nombre de usuario y contraseña que MySQL, solo se necesitará la dirección de enlace, y las demás propiedades se
heredarán.
En la tabla siguiente se indica una configuración de ejemplo de la instancia.
DESC RIP C IÓ N A RC H IVO
Instancia predeterminada e instancia con el puerto 3308. 0=127.0.0.1, myuser, cnBwdA==

3308=, ,
AutoUpdate=true
Instancia predeterminada e instancia con el puerto 3308 y 0=127.0.0.1, myuser, cnBwdA==

nombre de usuario y contraseña diferentes. 3308=127.0.1.1, myuser2,cGluaGVhZA==
AutoUpdate=true
Programa del archivo de autenticación de MySQL para OMI

Con la instalación del proveedor de MySQL para OMI se incluye un programa del archivo de autenticación de
MySQL para OMI que se puede usar para editar el archivo de autenticación de MySQL para OMI. El programa del
archivo de autenticación se encuentra en la ubicación siguiente.
/opt/microsoft/mysql-cimprov/bin/mycimprovauth
NOTE
El archivo de credenciales tiene que ser legible para la cuenta omsagent. Se recomienda ejecutar el comando mycimprovauth
como omsgent.
En la tabla siguiente se proporciona información sobre la sintaxis para usar mycimprovauth.
O P ERA C IÓ N E JEM P LO DESC RIP C IÓ N
autoupdate false o true mycimprovauth autoupdate false Establece si el archivo de autenticación

se actualizará automáticamente o no al
reiniciar o actualizar.
nombre de usuario y contraseña de la mycimprovauth default 127.0.0.1 root Establece la instancia predeterminada
dirección de enlace predeterminada pwd del archivo de autenticación de MySQL
para OMI.
El campo de contraseña debe escribirse
en texto sin formato, ya que la
contraseña del archivo de autenticación
de MySQL para OMI se codificará en
Base 64.
delete default o port_num mycimprovauth 3308 Elimina la instancia especificada, ya sea

por el valor predeterminado o por
número de puerto.
help mycimprov help Imprime una lista de comandos que se

pueden usar.
imprimir mycimprov print Imprime un archivo de autenticación de

MySQL para OMI fácil de leer.
actualizar nombre de usuario y mycimprov update 3307 127.0.0.1 root Actualiza la instancia especificada o, si
contraseña de la dirección de enlace del pwd no existe, agrega la instancia.
número de puerto
Los comandos del ejemplo siguiente definen una cuenta de usuario predeterminada para el servidor MySQL en
localhost. El campo de contraseña debe escribirse en texto sin formato, ya que la contraseña del archivo de
autenticación de MySQL para OMI se codificará en Base 64.
sudo su omsagent -c '/opt/microsoft/mysql-cimprov/bin/mycimprovauth default 127.0.0.1 <username> <password>'

sudo /opt/omi/bin/service_control restart
Permisos necesarios de la base de datos para los contadores de rendimiento de MySQL

El usuario de MySQL necesita acceso a las consultas siguientes para recopilar datos de rendimiento del servidor
MySQL.
SHOW GLOBAL STATUS;

SHOW GLOBAL VARIABLES:
El usuario de MySQL también necesita el acceso SELECT a las siguientes tablas predeterminadas.
information_schema
mysql.
Estos privilegios se pueden conceder ejecutando los siguientes comandos de concesión.
GRANT SELECT ON information_schema.* TO ‘monuser’@’localhost’;

GRANT SELECT ON mysql.* TO ‘monuser’@’localhost’;
NOTE
Para conceder permisos a un usuario de supervisión de MySQL, el usuario que concede el permiso tiene que tener el
privilegio "GRANT option", además del privilegio que se va a conceder.
Definir contadores de rendimiento

Después de configurar el agente de Log Analytics para Linux de forma que envíe datos a Azure Monitor, tendrá
que configurar los contadores de rendimiento para que recopilen datos. Use el procedimiento descrito en Orígenes
de datos de rendimiento de Windows y Linux en Azure Monitor con los contadores de la tabla siguiente.
Base de datos de MySQL Espacio en disco en bytes
Base de datos de MySQL Tablas
MySQL Server Porcentaje de conexiones anuladas
MySQL Server Porcentaje de uso de conexión
MySQL Server Uso de espacio en disco en bytes
MySQL Server Porcentaje de análisis de tabla completa
MySQL Server Porcentaje de aciertos del grupo de búferes InnoDB
MySQL Server Porcentaje de uso del grupo de búferes InnoDB
MySQL Server Porcentaje de uso del grupo de búferes InnoDB
MySQL Server Porcentaje de aciertos de la caché de claves
MySQL Server Porcentaje de uso de la caché de claves
MySQL Server Porcentaje de escritura de la caché de claves
MySQL Server Porcentaje de aciertos de la caché de consultas
MySQL Server Porcentaje de eliminaciones de la caché de consultas
MySQL Server Porcentaje de uso de la caché de consultas
MySQL Server Porcentaje de aciertos de la caché de tablas
MySQL Server Porcentaje de uso de la caché de tablas
MySQL Server Porcentaje de contención de bloqueo de tablas
Servidor HTTP de Apache

Si se detecta en el equipo un servidor HTTP de Apache cuando se instala la agrupación de omsagent, se instalará
automáticamente un proveedor de supervisión de rendimiento para el servidor HTTP de Apache. Este proveedor
se basa en un módulo de Apache que se tiene que cargar en el servidor HTTP de Apache para tener acceso a los
datos de rendimiento. Puede cargar el módulo con el comando siguiente:
sudo /opt/microsoft/apache-cimprov/bin/apache_config.sh -c
Para cargar el módulo de supervisión de Apache, ejecute el siguiente comando:
sudo /opt/microsoft/apache-cimprov/bin/apache_config.sh -u
Definir contadores de rendimiento

Después de configurar el agente de Log Analytics para Linux de forma que envíe datos a Azure Monitor, tendrá
que configurar los contadores de rendimiento para que recopilen datos. Use el procedimiento descrito en Orígenes
de datos de rendimiento de Windows y Linux en Azure Monitor con los contadores de la tabla siguiente.
Servidor HTTP de Apache Trabajadores ocupados
Servidor HTTP de Apache Trabajadores inactivos
Servidor HTTP de Apache Porcentaje de trabajadores ocupados
Servidor HTTP de Apache Porcentaje total de CPU
Host virtual de Apache Errores por minuto, cliente
Host virtual de Apache Errores por minuto, servidor
Host virtual de Apache KB por solicitud
Host virtual de Apache KB de solicitudes por segundo
Host virtual de Apache Solicitudes por segundo
Pasos siguientes
Recopilar contadores de rendimiento en agentes de Linux.
orígenes de datos.
Recopilación de registros de IIS en Azure Monitor
Internet Information Services (IIS) almacena la actividad de usuario en archivos de registro que Azure Monitor
puede recopilar y almacenar como datos de registro.
Configuración de registros de IIS

Azure Monitor recopila entradas de archivos de registro creados por IIS, por lo que debe configurar IIS para el
registro.
Azure Monitor solo admite archivos de registro de IIS almacenados en el formato W3C y no admite campos
personalizados ni Advanced Logging de IIS. No recopila registros en formato nativo IIS o NCSA.
Configure los registros de IIS en Azure Monitor e el menú Configuración avanzada. No se requiere otra
configuración que seleccionar Collect W3C format IIS log files (Recopilar archivos de registro de IIS en
formato W3C).
Azure Monitor recopila las entradas de registro IIS de todos los agentes cada vez que cambia la marca de tiempo
del registro. El registro se lee cada 5 minutos . Si por alguna razón IIS no actualiza la marca de tiempo antes de la
hora de sustitución, cuando se crea un archivo, las entradas se recopilarán después de la creación del archivo. La
frecuencia de creación de un registro se controla mediante la opción Log File Rollover Schedule
(Programación de sustitución incremental de archivos de registro) para el sitio IIS, que es una vez al día de forma
predeterminada. Si la configuración es Hourly (Por hora), Azure Monitor recopila el registro cada hora. Si la
configuración es Daily (Diario), Azure Monitor recopila el registro cada 24 horas.
Propiedades de registro de IIS

Los registros de IIS son del tipo W3CIISLog y tienen las propiedades que aparecen en la tabla siguiente:
cIP Dirección IP del cliente.
csMethod Método de la solicitud, como GET o POST.

csReferer Sitio cuyo vínculo el usuario siguió desde el sitio actual.
csUserAgent Tipo de explorador del cliente.
csUserName Nombre del usuario autenticado que obtuvo acceso al

servidor. Los usuarios anónimos se indican con un guion.
csUriStem El destino de la solicitud, como una página web.
csUriQuery La consulta que el cliente intentaba realizar, si corresponde.
ManagementGroupName Nombre del grupo de administración de agentes de

Operations Manager. En el caso de los otros agentes, es AOI-
<workspace ID>
RemoteIPCountry País o región de la dirección IP del cliente.
RemoteIPLatitude La latitud de la dirección IP del cliente.
RemoteIPLongitude La longitud de la dirección IP del cliente.
scStatus Código de estado HTTP.
scSubStatus Código de error de subestado.
scWin32Status Código de estado de Windows.
sIP Dirección IP del servidor web.
SourceSystem OpsMgr
sPort Puerto en el servidor al que está conectado el cliente.
sSiteName Nombre del sitio IIS.
TimeGenerated Fecha y hora en que se registró la entrada.
TimeTaken Duración del procesamiento de la solicitud, en milisegundos.
Consultas de registros con registros de IIS

La tabla siguiente proporciona ejemplos distintos de consultas de registro que recuperan registros de IIS.
W3CIISLog Todos los registros de IIS.
W3CIISLog | where scStatus==500 Todas las entradas de registro IIS con un estado de retorno
de 500.
W3CIISLog | summarize count() by cIP Contador de entradas de registro de IIS por dirección IP del
cliente.
W3CIISLog | where csHost=="www.contoso.com" | summarize Número de entradas de registro de IIS por dirección URL para
count() by csUriStem el host www.contoso.com.
W3CIISLog | summarize sum(csBytes) by Computer | take Total de bytes recibidos por cada equipo de IIS
500000
Pasos siguientes
Configure Azure Monitor para recopilar otros orígenes de datos para su análisis.
orígenes de datos.
Registros personalizados en Azure Monitor
El origen de datos de registros personalizados de Azure Monitor permite recopilar eventos de archivos de texto
en equipos Windows y Linux. Muchas aplicaciones registran información en archivos de texto, en lugar de los
servicios de registro estándar, como el registro de eventos de Windows o Syslog. Una vez recopilados, puede
analizar los datos en campos individuales en las consultas o extraerlos durante la recopilación de campos
individuales.
Los archivos de registro que se van a recopilar deben cumplir los criterios siguientes.
El registro debe tener una sola entrada por línea o usar una marca de tiempo que coincida con uno de
los formatos siguientes al principio de cada entrada.
AAAA-MM-DD HH:MM:SS
M/D/AAAA HH:MM:SS AM/PM
Mes DD, AAAA HH:MM:SS
aaMMdd HH:mm:ss
ddMMaa HH:mm:ss
MMM d hh:mm:ss
dd/MMM/aaaa:HH:mm:ss zzz
aaaa-MM-ddTHH:mm:ssK
El archivo de registro no debe permitir el registro circular o la rotación de registros, donde el archivo se
sobrescribe con nuevas entradas.
El archivo de registro debe utilizar la codificación ASCII o UTF-8. No se admiten otros formatos, como
UTF-16.
NOTE
Si hay entradas duplicadas en el archivo de registro, Azure Monitor las recopila. Pero los resultados de la consulta serán
incoherentes cuando los resultados del filtro muestren más eventos que el recuento de resultados. Es importante que
valide el registro para determinar si la aplicación que crea está causando este comportamiento y solucionarlo si es posible
antes de crear la definición de la colección de registros personalizada.
NOTE
Cada área de trabajo de Log Analytics admite los límites siguientes:
Solo se pueden crear 500 registros personalizados.
Una tabla solo admite hasta 500 columnas.
El número máximo de caracteres para el nombre de columna es 500.
IMPORTANT
La recopilación de registros personalizados requiere que la aplicación que escribe el archivo de registro vacíe el contenido
del registro en el disco de forma periódica. Esto se debe a que la colección de registros personalizados depende de las
notificaciones de cambios en el sistema de archivos para el archivo de registro del que se realiza el seguimiento.
Definición de un registro personalizado

Utilice el procedimiento siguiente para definir un archivo de registro personalizado. Desplácese hasta el final de
este artículo para ver un tutorial con un ejemplo de cómo agregar un registro personalizado.
Paso 1. Apertura del Asistente para registros personalizados
El Asistente para registros personalizados se ejecuta en Azure Portal y le permite definir un nuevo registro
personalizado para la recopilación.
1. En Azure Portal, seleccione las áreas de trabajo de Log Analytics > su área de trabajo > Configuración
avanzada .
2. Haga clic en Datos > Registros personalizados .
3. De forma predeterminada, todos los cambios realizados en la configuración se insertan automáticamente en
todos los agentes. En el caso de los agentes de Linux, se envía un archivo de configuración al recopilador de
datos Fluentd.
4. Haga clic en Agregar+ para abrir el Asistente para registros personalizados.
Paso 2. Carga y análisis de un registro de ejemplo
Para empezar, cargue una muestra del registro personalizado. El Asistente analizará y mostrará las entradas de
este archivo para que las valide. Azure Monitor usará el delimitador especificado para identificar cada registro.
Nueva línea es el delimitador predeterminado y se utiliza para los archivos de registro que tienen una sola
entrada por línea. Si la línea empieza con una fecha y hora en uno de los formatos disponibles, puede
especificar un delimitador de marca de tiempo que admita entradas que abarcan más de una línea.
Si se usa un delimitador de marca de tiempo, la propiedad TimeGenerated de cada registro almacenado en
Azure Monitor se rellenará con la fecha y la hora especificadas para esa entrada en el archivo de registro. Si se
usa un delimitador de nueva línea, TimeGenerated se rellena con la fecha y hora en que Azure Monitor ha
recopilado la entrada.
1. Haga clic en Browse (Examinar) y vaya a un archivo de ejemplo. Tenga en cuenta que este botón puede
llamarse Choose File (Elegir archivo) en algunos exploradores.
2. Haga clic en Next .
3. El Asistente para registros personalizados cargará el archivo y mostrará los registros que identifique.
4. Cambie el delimitador que se utiliza para identificar un registro nuevo y seleccione el delimitador que mejor
identifica las entradas en el archivo de registro.
5. Haga clic en Next .
Paso 3. Incorporación de rutas de recopilación de registros
Debe definir una o más rutas de acceso en el agente para colocar el registro personalizado. Puede proporcionar
un nombre y una ruta de acceso específicos para el archivo de registro, o bien puede especificar una ruta de
acceso con un carácter comodín para el nombre. Esto admite aplicaciones que crean un archivo nuevo cada día
o cuando un archivo alcanza un tamaño determinado. También puede proporcionar varias rutas de acceso para
un solo archivo de registro.
Por ejemplo, una aplicación puede crear un archivo de registro cada día con la fecha incluida en el nombre,
como registro20100316.txt. Un patrón para dicho registro podría ser registro*.txt, que se aplicará a cualquier
archivo de registro que siga el esquema de asignación de nombres de la aplicación.
La tabla siguiente proporciona ejemplos de patrones válidos para especificar diferentes archivos de registro.
DESC RIP C IÓ N PAT H
Todos los archivos en C:\Logs con la extensión .txt en el C:\Logs\*.txt

agente de Windows
Todos los archivos en C:\Logs con un nombre que empieza C:\Logs\log*.txt

con "registro" y una extensión .txt en el agente de Windows
Todos los archivos en /var/log/audit con la extensión .txt en /var/log/audit/*.txt

el agente de Linux
Todos los archivos en /var/log/audit con un nombre que /var/log/audit/log*.txt

empieza con "registro" y una extensión .txt en el agente de
Linux
1. Seleccione Windows o Linux para especificar qué formato de ruta de acceso va a agregar.
2. Escriba la ruta de acceso y haga clic en el botón + .
3. Repita el proceso para rutas de acceso adicionales.
Paso 4. Suministro de un nombre y una descripción del registro
El nombre que especifique se utilizará para el tipo de registro como se describió anteriormente. Siempre
finalizará con _CL para distinguirlo como un registro personalizado.
1. Escriba un nombre para el registro. El sufijo _CF se anexa automáticamente.
2. Agregue una Descripción opcional.
3. Haga clic en Next (Siguiente) para guardar la definición del registro personalizado.
Paso 5. Comprobación de que se recopilan los registros personalizados
Los datos iniciales de un nuevo registro personalizado pueden tardar hasta una hora en aparecer en Azure
Monitor. Empezará a recopilar las entradas de los registros que se encuentran en la ruta de acceso que ha
especificado a partir del punto que definió en el registro personalizado. No mantendrá las entradas que ha
cargado durante la creación de registro personalizado, pero recopilará entradas ya existentes en los archivos de
registro que encuentra.
Una vez que Azure Monitor empieza a recopilar del registro personalizado, sus registros estarán disponibles
con una búsqueda de registros. Utilice el nombre que asignó al registro personalizado como Type en la
consulta.
NOTE
Si falta la propiedad RawData en la búsqueda, es posible que tenga que cerrar y volver a abrir el explorador.
Paso 6. Análisis de las entradas del registro personalizado

La entrada de registro completa se almacenará en una sola propiedad denominada RawData . Probablemente le
interesará separar los diferentes fragmentos de información de cada entrada en propiedades individuales para
cada registro. Consulte Análisis de datos de texto en Azure Monitor para obtener opciones de análisis de
RawData en varias propiedades.
Eliminación de un registro personalizado

Use el proceso siguiente en Azure Portal para eliminar un registro personalizado que haya definido
anteriormente.
1. En el menú Datos en Configuración avanzada del área de trabajo, seleccione Registros
personalizados para enumerar todos los registros personalizados.
2. Haga clic en la opción Quitar situada junto al registro personalizado que desea quitar.
Azure Monitor recopilará nuevas entradas de cada registro personalizado aproximadamente cada cinco
minutos. El agente registrará su lugar en cada archivo de registro del que se recopila. Si el agente se desconecta
durante un período de tiempo, Azure Monitor recopilará entradas a partir de donde lo haya dejado, incluso si
se crearon mientras el agente estaba sin conexión.
Todo el contenido de la entrada del registro se escribe en una sola propiedad denominada RawData . Vea
Análisis de datos de texto en Azure Monitor para obtener métodos con el fin de analizar cada entrada de
registro importada en varias propiedades.
Propiedades de las entradas del registro personalizado

Las entradas del registro personalizado tienen un tipo con el nombre del registro que asigne y las propiedades
en la tabla siguiente.
TimeGenerated Fecha y hora en las que Azure Monitor recopiló el registro. Si

el registro usa un delimitador basado en el tiempo, es el
tiempo recopilado en la entrada.
SourceSystem Tipo de agente del que se recopiló el registro.

directa o System Center Operations Manager
RawData Texto completo de la entrada recopilada. Probablemente le

interesará analizar estos datos en propiedades individuales.
ManagementGroupName Nombre del grupo de administración de agentes de System

Center Operations Manager. En el caso de los otros agentes,
es AOI-<workspace ID>
Ejemplo de tutorial de agregar un registro personalizado

La siguiente sección le guiará por un ejemplo de creación de un registro personalizado. El registro de ejemplo
que se recopila tiene una sola entrada en cada línea que empieza con una fecha y hora, después, campos
delimitados por comas para el código, el estado y el mensaje. A continuación se muestran varias entradas de
ejemplo.
2019-08-27 01:34:36 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
2019-08-27 01:33:33 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2019-08-27 01:35:44 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2019-08-27 01:38:22 302,Error,Application could not connect to database
2019-08-27 01:31:34 303,Error,Application lost connection to database
Carga y análisis de un registro de ejemplo

Se proporciona uno de los archivos de registro, y puede ver los eventos que se recopilarán. En este caso, una
nueva línea es un delimitador suficiente. Sin embargo, si una sola entrada en el registro puede abarcar varias
líneas, es necesario usar un delimitador de marca de tiempo.
Incorporación de rutas de recopilación de registros

Los archivos de registro se colocarán en C:\MyApp\Logs. Se creará un archivo nuevo cada día con un nombre
que incluye la fecha con el patrón appAAAAMMDD.log. Un patrón suficiente para este registro sería
C:\MyApp\Logs\*.log.
Suministro de un nombre y una descripción del registro

Use el nombre MyApp_CL y escriba una descripción en el campo Descripción .
Comprobación de que se recopilan los registros personalizados
Utilice una consulta simple de Type=MyApp_CL para devolver todos los registros desde el registro recopilado.
Alternativas a los registros personalizados

Aunque los registros personalizados son útiles si los datos cumplen los criterios anteriores, en casos como los
siguientes se necesita otra estrategia:
Los datos no se ajustan a la estructura necesaria como tener la marca de tiempo en un formato diferente.
El archivo de registro no cumple los requisitos como la codificación de archivos o una estructura de carpetas
no admitida.
Los datos requieren el preprocesamiento o el filtrado antes de la colección.
En los casos donde no se pueden recopilar los datos con los registros personalizados, tenga en cuenta las
siguientes estrategias alternativas:
Use un script personalizado u otro método para escribir datos en Eventos de Windows o en Syslog que
recopila Azure Monitor.
Envíe los datos directamente a Azure Monitor mediante la API del recopilador de datos HTTP.
Pasos siguientes
Vea Análisis de datos de texto en Azure Monitor para obtener métodos con el fin de analizar cada entrada de
registro importada en varias propiedades.
orígenes de datos.
Creación de campos personalizados en un área de
trabajo de Log Analytics en Azure Monitor (versión
preliminar)
NOTE
En este artículo se describe cómo analizar los datos de texto en un área de trabajo de Log Analytics cuando se recopilan.
Se recomienda analizar los datos de texto en un filtro de consulta después de que se recopilan siguiendo las instrucciones
de Análisis de datos de texto en Azure Monitor. Proporciona varias ventajas sobre el uso de campos personalizados.
IMPORTANT
Los campos personalizados aumentan la cantidad de datos recopilados en el área de trabajo Log Analytics, lo que puede
aumentar el costo. Consulte Administración del uso y los costos con los registros de Azure Monitor para más información.
La característica Campos personalizados de Azure Monitor le permite ampliar los registros existentes del
área de trabajo de Log Analytics agregando sus propios campos de búsqueda. Los campos personalizados se
rellenan automáticamente a partir de los datos extraídos de otras propiedades del mismo registro.
Por ejemplo, en el registro que se muestra a continuación, hay información útil que está escondida en la
descripción del evento. Si estos datos se extraen en una propiedad diferente, estarán disponibles para ciertas
acciones, como la ordenación y el filtrado.
NOTE
En la versión preliminar, el área de trabajo tiene un límite de 100 campos personalizados. Este límite se ampliará cuando
esta característica esté disponible con carácter general.
Creación de un campo personalizado

Cuando se crea un campo personalizado, Log Analytics necesita saber qué datos debe usar para rellenar el valor.
Para identificar rápidamente estos datos, utiliza una tecnología de Microsoft Research denominada FlashExtract.
Azure Monitor es capaz de reconocer los datos que debe extraer a partir de los ejemplos proporcionados, por lo
que no es necesario especificar instrucciones explícitas.
En las secciones siguientes, se describe el procedimiento necesario para crear un campo personalizado. Al final
de este artículo, encontrará un tutorial con una extracción de ejemplo.
NOTE
El campo personalizado se rellena a medida que los registros que cumplen los criterios especificados se agregan al área de
trabajo de Log Analytics; por tanto, el campo personalizado solo aparecerá en los registros recopilados una vez que se
haya creado. El campo personalizado no se agregará a los registros que ya se encuentren en el almacén de datos en el
momento de su creación.
Paso 1: Identificación de los registros que incluirán el campo personalizado

El primer paso consiste en identificar los registros que incluirán el campo personalizado. Comience con una
consulta de registros estándar y, después, seleccione un registro que sirva de modelo para que Azure Monitor
aprenda de él. Cuando especifique que va a extraer los datos en un campo personalizado, se abrirá Field
Extraction Wizard y (Asistente para extraer campos) podrá validar y delimitar los criterios.
1. Vaya a Registros y utilice una consulta para recuperar los registros que incluirán el campo personalizado.
2. Seleccione el registro que Log Analytics utilizará como modelo para extraer los datos y rellenar el campo
personalizado. Deberá identificar los datos que quiere extraer de este registro. Log Analytics utilizará esa
información para determinar la lógica con la que rellenará el campo personalizado en todos los registros que
sean similares.
3. Expanda las propiedades de registro, haga clic en los puntos suspensivos a la izquierda de la propiedad
principal del registro y seleccione Extraer campos de .
4. Se abrirá el Asistente para extraer campos y el registro seleccionado aparecerá en la columna Ejemplo
principal . El campo personalizado se va a definir para aquellos recursos que tengan los mismos valores en
las propiedades seleccionadas.
5. Si la selección no coincide exactamente con sus expectativas, seleccione otros campos para restringir los
criterios. Para cambiar los valores de campo de los criterios, debe cancelar y seleccionar otro registro que
coincida con los criterios que quiere usar.
Paso 2: Ejecución de la extracción inicial.
Una vez identificados los registros que incluirán el campo personalizado, deberá identificar los datos que desea
extraer. Log Analytics utilizará esta información para identificar patrones parecidos en registros similares. En el
paso siguiente, podrá validar los resultados y proporcionar más detalles para que Log Analytics los utilice en su
análisis.
1. Resalte el texto del registro de ejemplo con el que desea rellenar el campo personalizado. A continuación,
aparecerá un cuadro de diálogo en el que tendrá que especificar un nombre y un tipo de datos para el campo
y realizar la extracción inicial. Los caracteres _CF se anexarán automáticamente.
2. Haga clic en Extract (Extraer) para realizar un análisis de los registros recopilados.
3. En las secciones Resumen y Resultados de búsqueda , se muestran los resultados de la extracción para
que pueda revisar si son correctos. Summar y (Resumen), aparecen los criterios utilizados para identificar
registros y el recuento de cada uno de los valores de datos identificados. Search Results (Resultados de
búsqueda), aparece una lista detallada de los registros que cumplen los criterios.
Paso 3: Comprobación de la precisión de la extracción y creación de un campo personalizado
Una vez realizada la extracción inicial, Log Analytics mostrará los resultados en función de los datos que ya se
han recopilado. Si los resultados parecen correctos, puede crear el campo personalizado sin necesidad de
realizar ninguna otra operación. De lo contrario, puede delimitar los resultados para que Log Analytics mejore su
lógica.
1. Si alguno de los valores de la extracción inicial no es correcto, haga clic en el icono Editar que encontrará
junto al registro incorrecto y seleccione Modificar este resaltado para poder realizar los cambios.
2. La entrada se copia en la sección Ejemplos adicionales , bajo Ejemplo principal . En esta sección, puede
ajustar el texto resaltado para ayudar a Log Analytics a entender qué selección debería haber hecho.
3. Haga clic en Extract (Extraer) si desea utilizar esta nueva información para evaluar todos los registros
existentes. Los resultados pueden modificarse en función de esta nueva información para otros registros
distintos del que acaba de modificar.
4. Continúe con las correcciones hasta que todos los registros de la extracción identifiquen correctamente los
datos que van a incluirse en el nuevo campo personalizado.
5. Haga clic en Save Extract (Guardar extracción) cuando esté satisfecho con los resultados. Ahora, el campo
personalizado está definido, pero aún no se ha agregado a ningún registro.
6. Espere a que se recopilen los registros nuevos que cumplan los criterios y vuelva a ejecutar la búsqueda de
registros. Los nuevos registros deberían incluir el campo personalizado.
7. Utilice el campo personalizado como cualquier otra propiedad del registro. Puede usarlo para agregar y
agrupar datos, e incluso para generar nueva información.
Presentación de los de campos personalizados

Puede ver una lista de todos los campos personalizados en el grupo de administración del menú
Configuración avanzada del área de trabajo de Log Analytics en Azure Portal. Seleccione Datos y después
Campos personalizados para obtener una lista de todos los campos personalizados del área de trabajo.
Eliminación de un campo personalizado

Existen dos formas de quitar un campo personalizado. La primera es a través de la opción Remove (Quitar) que
aparece en cada campo cuando se consulta la lista completa, tal y como que se describió anteriormente. El otro
método consiste en recuperar un registro y hacer clic en el botón situado a la izquierda del campo. El menú
incluirá una opción para quitar el campo personalizado.
Tutorial de ejemplo
La siguiente sección contiene un ejemplo completo que le guiará por el proceso de creación de un campo
personalizado. En este ejemplo, se extrae el nombre de servicio de los eventos de Windows que indican un
cambio de estado en el servicio. En este ejemplo, se utilizan eventos creados por el Administrador de control de
servicios durante el inicio del sistema en equipos Windows. Si desea seguir este ejemplo, debe recopilar eventos
de información del registro del sistema.
En primer lugar, escribimos la siguiente consulta para que devuelva todos los eventos del Administrador de
control de servicios que tengan el identificador 7036, que es el evento que indica el inicio o la detención de un
servicio.
A continuación, seleccionamos y expandimos cualquier registro con el identificador de evento 7036.

Definimos los campos personalizados haciendo clic en los puntos suspensivos junto a la propiedad principal.
Se abre Field Extraction Wizard (Asistente para extraer campos), donde los campos EventLog y EventID
aparecen seleccionados en la columna Ejemplo principal . Esto indica que el campo personalizado se va a
definir para los eventos del registro del sistema que tengan el identificador 7036. Como es suficiente, no es
necesario seleccionar ningún otro campo.
Ahora, resaltamos el nombre del servicio en la propiedad RenderedDescription y utilizamos Ser vicio para
identificar el nombre del servicio. El campo personalizado se llamará Ser vice_CF . En este caso, el tipo de campo
es una cadena, por lo que se puede dejar sin cambios.
Como podemos ver, el nombre del servicio se identifica correctamente en algunos registros, pero no en otros.
En Resultados de búsqueda , vemos que parte del nombre del Adaptador de rendimiento de WMI no
aparece seleccionado. El campo Resumen indica que un registro ha identificado Instalador de Módulos en
lugar de Instalador de Módulos de Windows .
Vamos a comenzar con el registro WMI Performance Adapter (Adaptador de rendimiento de WMI). Hacemos
clic en el icono de edición y luego en Modify this highlight (Modificar texto resaltado).
Ampliamos la selección para que incluya la palabra WMI y ejecutamos de nuevo la extracción.
Ahora, podemos ver que las entradas de Adaptador de rendimiento de WMI se han corregido. Log Analytics
utilizará esta información para corregir los registros de Instalador de módulos de Windows .
Ahora podemos ejecutar una consulta que compruebe que Ser vice_CF se ha creado, aunque aún no se ha
agregado a ningún registro. Eso es porque el campo personalizado no funciona con los registros existentes, así
que tenemos que esperar hasta que se recopilen registros nuevos.
A medida que pasa el tiempo, se recopilan nuevos eventos y podemos ver que el campo Ser vice_CF se va
agregando a los registros que cumplen nuestros criterios.
Ahora, podemos usar el campo personalizado como cualquier otra propiedad del registro. Para comprobarlo,
creamos una consulta que agrupe los datos en función del nuevo campo Ser vice_CF y que analice qué
servicios son los más activos.
Pasos siguientes
Si desea crear consultas con campos personalizados en función de unos criterios, obtenga más información
acerca de las consultas de registros.
Supervise los archivos de registro personalizados que se analizan con campos personalizados.
Métricas personalizadas en Azure Monitor (versión
preliminar)
A medida que implementa recursos y aplicaciones en Azure, querrá empezar a recopilar datos de telemetría
para obtener conclusiones detalladas sobre su rendimiento y mantenimiento. Azure pone algunas métricas a su
disposición de manera estándar. Estas métricas se denominan estándar o de plataforma. Sin embargo, están
limitadas por naturaleza.
Es posible que quiera recopilar algunos indicadores de rendimiento personalizados o métricas específicas del
negocio para obtener conclusiones más detalladas. Estas métricas personalizadas pueden recopilarse a través
de los datos de telemetría de la aplicación, un agente que se ejecute en sus recursos de Azure o, incluso, fuera
del sistema de supervisión y enviarse directamente a Azure Monitor. Una vez publicadas en Azure Monitor,
puede examinar, consultar y generar una alerta sobre métricas personalizadas para sus recursos y aplicaciones
de Azure en paralelo con las métricas estándar emitidas por Azure.
Las métricas personalizadas en Azure Monitor están actualizadas en la versión preliminar pública.
Métodos para enviar métricas personalizadas

Las métricas personalizadas pueden enviarse a Azure Monitor a través de distintos métodos:
Instrumente la aplicación con el SDK de Azure Application Insights y envíe datos de telemetría
personalizados a Azure Monitor.
Instale el agente de Azure Monitor (versión preliminar) en la máquina virtual de Azure Windows o Linux y
use una regla de recopilación de datos para enviar contadores de rendimiento a las métricas de Azure
Monitor.
Instale la extensión Windows Azure Diagnostics (WAD) en su máquina virtual Azure, conjunto de escalado
de máquinas virtuales, máquina virtual clásica o Cloud Services clásico, y envíe los contadores de
rendimiento a Azure Monitor.
Instale el agente de InfluxData Telegraf en su máquina virtual Linux de Azure y envíe las métricas mediante
el complemento de salida de Azure Monitor.
Envíe las métricas personalizadas directamente a la API REST de Azure Monitor,
https://<azureregion>.monitoring.azure.com/<AzureResourceID>/metrics .
Modelo de precios y retención

Consulte la página de tarifas de Azure Monitor para más información sobre cuándo se habilitará la facturación
para las consultas de métricas y las métricas personalizadas. Los detalles de precios específicos de todas las
métricas, incluidas las métricas personalizadas y las consultas de métricas, están disponibles en esta página. En
resumen, no hay ningún costo por ingerir métricas estándar (métricas de plataforma) en el almacén de
métricas de Azure Monitor, pero las métricas personalizadas tendrán un costo cuando sean de disponibilidad
general. Las consultas de la API de métricas supondrán un costo.
Las métricas personalizadas se conservan durante el mismo tiempo que las métricas de plataforma.
NOTE
Las métricas enviadas a Azure Monitor mediante el SDK de Application Insights se facturan como datos de registro
ingeridos. Los cargos de métricas adicionales solo tienen un costo si se ha seleccionado la característica Application
Insights Habilitar la creación de alertas sobre las dimensiones de las métricas personalizadas. Esta casilla envía datos a la
base de datos de métricas de Azure Monitor mediante la API de métricas personalizadas para permitir unas alertas más
complejas. Obtenga más información sobre el modelo de tarifas de Application Insights y las tarifas en su región.
Cómo enviar métricas personalizadas

Al enviar las métricas personalizadas a Azure Monitor, cada punto de datos (o valor) notificado debe incluir la
siguiente información:
Authentication
Para enviar métricas personalizadas a Azure Monitor, la entidad que envía la métrica debe tener un token de
Azure Active Directory (Azure AD) válido en el encabezado de por tador de la solicitud. Existen algunas formas
admitidas para adquirir un token de portador válido:
1. Identidades administradas para recursos de Azure. Proporciona una identidad a un recurso de Azure mismo,
por ejemplo, una máquina virtual. Managed Service Identity (MSI) está diseñado para proporcionar
permisos a los recursos para llevar a cabo determinadas operaciones. Un ejemplo es permitir que un
recurso emita métricas sobre sí mismo. Se puede conceder a un recurso, o a su MSI, permisos de
Publicador de métricas de super visión en otro recurso. Con este permiso, el MSI puede emitir métricas
también para otros recursos.
2. Entidad de servicio de Azure AD. En este escenario, en una aplicación de Azure AD, o servicio, pueden
asignarse permisos para emitir métricas sobre un recurso de Azure. Para autenticar la solicitud, Azure
Monitor valida el token de aplicación mediante las claves públicas de Azure AD. El rol Super visión del
publicador de métricas existente ya tiene este permiso. Está disponible en Azure Portal. La entidad de
servicio, en función de para qué recursos vaya a emitir las métricas personalizadas, puede recibir el rol
Super visión del publicador de métricas en el ámbito necesario. Algunos ejemplos son una suscripción,
un grupo de recursos o un recurso específico.
TIP
Cuando solicite un token de Azure AD para emitir métricas personalizadas, asegúrese de que la audiencia o el recurso
para el que se solicita el token sea https://monitoring.azure.com/ . Asegúrese de incluir la barra diagonal "/" final.
Asunto
Esta propiedad captura para cuál identificador de recurso de Azure se notifica la métrica personalizada. Esta
información se codificarán en la dirección URL de la llamada API que se realiza. Cada API solo puede enviar los
valores de métrica para un único recurso de Azure.
NOTE
No se pueden emitir métricas personalizadas con el identificador de recurso de un grupo de recursos o una suscripción.
Region
Esta propiedad captura en qué región de Azure se implementa el recurso para el que se van a emitir las
métricas. Las métricas se deben emitir al mismo punto de conexión regional de Azure Monitor que la región
donde se implementa el recurso. Por ejemplo, las métricas personalizadas para una máquina virtual que se
implementa en el Oeste de EE. UU. deben enviarse al punto de conexión de Azure Monitor regional WestUS. La
información de región también está codificada en la dirección URL de la llamada API.
NOTE
Durante la versión preliminar pública, las métricas personalizadas solo están disponibles en un subconjunto de las
regiones de Azure. En una sección posterior de este artículo se incluye una lista de regiones admitidas.
Timestamp
Cada punto de datos que se envía a Azure Monitor debe marcarse con una marca de tiempo. Esta marca de
tiempo captura la fecha y hora en que se midió o recopiló el valor de la métrica. Azure Monitor acepta datos de
métrica con marcas de tiempo de hasta 20 minutos en el pasado y hasta 5 minutos en el futuro. La marca de
tiempo debe estar en formato ISO 8601.
Espacio de nombres
Los espacios de nombres son una manera de clasificar o agrupar las métricas similares. Mediante el uso de
espacios de nombres se puede conseguir el aislamiento entre los grupos de métricas que puedan estar
recopilando diferentes conclusiones o indicadores de rendimiento. Por ejemplo, podría tener un espacio de
nombres denominado contosomemor ymetrics que realice el seguimiento de las métricas de uso de
memoria que perfile una aplicación. Otro espacio de nombres denominado contosoapptransaction podría
realizar un seguimiento de todas las métricas sobre las transacciones de usuario en la aplicación.
Nombre
Nombre es el nombre de la métrica que se está notificando. Normalmente, el nombre es lo suficientemente
descriptivo como para ayudar a identificar lo que se está midiendo. Un ejemplo es una métrica que mide el
número de bytes de memoria utilizados en una máquina virtual determinada. Podría tener un nombre de
métrica como Bytes de memoria en uso .
Claves de dimensión
Una dimensión es un par de valor o clave que ayuda a describir características adicionales sobre la métrica que
se recopila. Mediante el uso de características adicionales, puede recopilar más información acerca de la
métrica, lo que permite obtener conclusiones más detalladas. Por ejemplo, la métrica Bytes de memoria en
uso podría tener una clave de dimensión denominada Proceso que capture el número de bytes de memoria
que consume cada proceso en una máquina virtual. Con esta clave, puede filtrar la métrica para ver cuánta
memoria usan los procesos específicos o para identificar los cinco procesos principales por uso de memoria.
Las dimensiones son opcionales, no todas las métricas pueden tener dimensiones. Una métrica personalizada
puede tener hasta 10 dimensiones.
Valores de dimensión
Al informar de un punto de datos de métrica, para cada clave de dimensión en la métrica notificada, hay un
valor de dimensión correspondiente. Por ejemplo, si quisiera informar de la memoria utilizada por ContosoApp
en la máquina virtual:
El nombre de la métrica sería Bytes de memoria en uso .
La clave de dimensión sería Proceso .
El valor de la dimensión sería ContosoApp.exe .
Al publicar un valor de métrica, solo puede especificar un único valor de dimensión por clave de dimensión. Si
recopila el mismo uso de memoria para varios procesos en la máquina virtual, puede informar sobre varios
valores de métricas para esa marca de tiempo. Cada valor de métrica especificaría un valor de dimensión
diferente para la clave de dimensión Proceso . Las dimensiones son opcionales, no todas las métricas pueden
tener dimensiones. Si en una publicación de métrica se definen las claves de dimensión, los valores de
dimensión correspondientes serán obligatorios.
Valores de métrica
Azure Monitor almacena todas las métricas a intervalos de granularidad de un minuto. Somos conscientes de
que, durante un minuto determinado, es posible que una métrica tenga que ser muestreada varias veces. Un
ejemplo es el uso de CPU. O podría ser necesario medirlo para muchos eventos discretos. Un ejemplo son las
latencias de transacción de inicio de sesión. Para limitar el número de valores sin procesar que tenga que emitir
y pagar en Azure Monitor, puede agregar previamente de manera local y emitir los valores:
Mínimo : el valor mínimo observado de todas las muestras y medidas durante el minuto.
Máximo : el valor máximo observado de todas las muestras y medidas durante el minuto.
Suma : el sumatorio de todos los valores observados de todas las muestras y medidas durante el minuto.
Recuento : el número de muestras y medidas tomadas durante el minuto.
Por ejemplo, si hubo cuatro transacciones de inicio de sesión a la aplicación durante un minuto determinado,
las latencias medidas resultantes para cada una podrían ser las siguientes:
T RA N SA C C IÓ N 1 T RA N SA C C IÓ N 2 T RA N SA C C IÓ N 3 T RA N SA C C IÓ N 4
7 ms 4 ms 13 ms 16 ms
La publicación de métricas resultante en Azure Monitor sería la siguiente:

Mín.: 4
Máx.: 16
Suma: 40
Recuento: 4
Si la aplicación no puede agregar previamente de manea local y debe emitir cada muestra o evento discretos
inmediatamente después de la recopilación, puede emitir los valores de medida sin procesar. Por ejemplo, cada
vez que se produzca una transacción de inicio de sesión en la aplicación, publica una métrica en Azure Monitor
con solo una única medida. Por lo tanto, para una transacción de inicio de sesión que llevó 12 ms, la
publicación de la métrica sería la siguiente:
Mín.: 12
Máx.: 12
Suma: 12
Recuento: 1
Con este proceso, puede emitir varios valores para la misma combinación de métrica más dimensión durante
un minuto dado. Azure Monitor luego toma todos los valores sin procesar emitidos para un minuto dado y los
suma.
Publicación de métricas personalizadas de ejemplo
En el ejemplo siguiente, creará una métrica personalizada llamada Memoria de bytes en uso en el espacio
de nombres de métrica Perfil de memoria para una máquina virtual. La métrica tiene una única dimensión
denominada Proceso . Para la marca de tiempo dada, se emiten valores de métricas para dos procesos
diferentes:
{
"time": "2018-08-20T11:25:20-7:00",
"data": {
"baseData": {
"metric": "Memory Bytes in Use",

"namespace": "Memory Profile",
"dimNames": [
"Process" ],
"series": [
{
"dimValues": [
"ContosoApp.exe"
],
"min": 10,
"max": 89,
"sum": 190,
"count": 4
},
{
"dimValues": [
"SalesApp.exe"
],
"min": 10,
"max": 23,
"sum": 86,
"count": 4
}
]
}
}
}
NOTE
Application Insights, la extensión de diagnóstico, y el agente InfluxData Telegraf ya están configurados para emitir los
valores de métrica frente al punto de conexión regional correcto y transportar todas las propiedades anteriores en cada
emisión.
Definiciones de métricas personalizadas

No es necesario definir previamente una métrica personalizada en Azure Monitor antes de emitirla. Cada punto
de datos de métrica publicado contiene el espacio de nombres, el nombre y la información de la dimensión. Por
tanto, la primera vez que se emite una métrica personalizada para Azure Monitor, se crea automáticamente una
definición de métrica. Esta definición de métrica luego puede detectarse en cualquier recurso con respecto al
que se emitió la métrica a través de las definiciones de métricas.
NOTE
Azure Monitor todavía no permite definir Unidades para una métrica personalizada.
Uso de métricas personalizadas

Una vez que las métricas personalizadas se envían a Azure Monitor, puede examinarlas con Azure Portal y
consultarlas mediante las API REST de Azure Monitor. También puede crear alertas con ellas para avisarle
cuando se cumplen ciertas condiciones.
NOTE
Debe ser un rol de lector o colaborador para ver las métricas personalizadas.
Exploración de las métricas personalizadas a través de Azure Portal

1. Vaya a Azure Portal.
2. Seleccione el panel Monitor .
3. Seleccione Métricas .
4. Seleccione un recurso con el que haya emitido métricas personalizadas.
5. Seleccione el espacio de nombres de métrica para la métrica personalizada.
6. Seleccione la métrica personalizada.
Regiones admitidas
Durante la versión preliminar pública, la capacidad de publicar métricas personalizadas solo está disponible en
un subconjunto de las regiones de Azure. Esta restricción implica que las métricas solo pueden publicarse para
recursos de una de las regiones admitidas. En la tabla siguiente se enumera el conjunto de regiones de Azure
admitidas para las métricas personalizadas. También se muestran los puntos de conexión correspondientes
para cuyos recursos en esas regiones se deben publicar métricas:
REGIÓ N DE A Z URE P REF IJO DEL P UN TO DE C O N EXIÓ N REGIO N A L
EE. UU. y Canadá
Centro-Oeste de EE. UU. https://westcentralus.monitoring.azure.com
Oeste de EE. UU. 2 https://westus2.monitoring.azure.com
Centro-Norte de EE. UU https://northcentralus.monitoring.azure.com
Centro-sur de EE. UU. https://southcentralus.monitoring.azure.com
Centro de EE. UU. https://centralus.monitoring.azure.com
Centro de Canadá https://canadacentral.monitoring.azure.com
Este de EE. UU. https://eastus.monitoring.azure.com
Este de EE. UU. 2 https://eastus2.monitoring.azure.com
Europa
Norte de Europa https://northeurope.monitoring.azure.com
Oeste de Europa https://westeurope.monitoring.azure.com
Sur de Reino Unido https://uksouth.monitoring.azure.com
Centro de Francia https://francecentral.monitoring.azure.com
África
REGIÓ N DE A Z URE P REF IJO DEL P UN TO DE C O N EXIÓ N REGIO N A L
Norte de Sudáfrica https://southafricanorth.monitoring.azure.com
Asia
Centro de la India https://centralindia.monitoring.azure.com
Este de Australia https://australiaeast.monitoring.azure.com
Japón Oriental https://japaneast.monitoring.azure.com
Sudeste de Asia https://southeastasia.monitoring.azure.com
Este de Asia https://eastasia.monitoring.azure.com
Centro de Corea del Sur https://koreacentral.monitoring.azure.com
Latencia y retención del almacenamiento

La adición de una nueva métrica o de una nueva dimensión a una métrica pueden tardar de 2 a 3 minutos en
aparecer. Una vez en el sistema, los datos deben aparecer en menos de 30 segundos el 99 % del tiempo.
Si elimina una métrica o quita una dimensión, el cambio puede tardar de una semana a un mes en eliminarse
del sistema.
Cuotas y límites
Azure Monitor impone los siguientes límites de uso a las métricas personalizadas:
C AT EGO RY L ÍM IT E
Serie temporal activa/suscripciones/región 50.000
Claves de dimensión por métrica 10
Longitud de cadena de espacios de nombres de métricas, 256 caracteres

nombres de métricas, claves de dimensión y valores de
dimensión
Una serie temporal activa se define como cualquier combinación única de métrica, clave de dimensión o valor
de dimensión para los que se hayan publicado valores de métrica en las últimas 12 horas.
Pasos siguientes
Use métricas personalizadas desde distintos servicios:
Máquinas virtuales
Conjunto de escalado de máquinas virtuales
Azure Virtual Machines (clásico)
Máquina virtual Linux que usa el agente Telegraf
REST API
Cloud Services clásico
Envío de métricas personalizadas de un recurso de
Azure al almacén de métricas de Azure Monitor
mediante la API REST
En este artículo muestra cómo enviar métricas personalizadas de los recursos de Azure al almacén de métricas
Azure Monitor a través de una API de REST. Una vez que las métricas estén en Azure Monitor, puede hacer con
ellas lo mismo que con las métricas estándar. Por ejemplo, puede crear gráficos o alertas, y enrutarlos a otras
herramientas externas.
NOTE
La API de REST solo permite el envío de métricas personalizadas de los recursos de Azure. Para enviar métricas de recursos
en distintos entornos o de forma local, puede usar Application Insights.
Creación y autorización de una entidad de servicio para la emisión de

métricas
Cree una entidad de servicio en el inquilino de Azure Active Directory según las instrucciones que encontrará en
Creación de una entidad de servicio.
Tenga en cuenta lo siguiente al realizar este proceso:
Puede escribir cualquier dirección URL para la dirección URL de inicio de sesión.
Cree un nuevo secreto de cliente para esta aplicación.
Guarde la clave y el identificador de cliente para usarlos en pasos posteriores.
Asigne a la aplicación que creó como parte del paso 1, Supervisión del publicador de métricas, permisos para el
recurso frente al cual desea emitir métricas. Si va a usar la aplicación para emitir métricas personalizadas frente a
muchos recursos, puede conceder estos permisos en el nivel de suscripción o de grupo de recursos.
Obtención de un token de autorización

Abra un símbolo del sistema y ejecute el comando siguiente:
curl -X POST https://login.microsoftonline.com/<yourtenantid>/oauth2/token -F

"grant_type=client_credentials" -F "client_id=<insert clientId from earlier step>" -F "client_secret=<insert
client secret from earlier step>" -F "resource=https://monitoring.azure.com/"
Guarde el token de acceso de la respuesta.

Emisión de la métrica a través de la API de REST
1. Pegue el siguiente código JSON en un archivo y guárdelo como custommetric.json en el equipo local.
Actualice el parámetro de tiempo en el archivo JSON:
{
"time": "2018-09-13T16:34:20",
"data": {
"baseData": {
"metric": "QueueDepth",
"namespace": "QueueProcessing",
"dimNames": [
"QueueName",
"MessageType"
],
"series": [
{
"dimValues": [
"ImagesToProcess",
"JPEG"
],
"min": 3,
"max": 20,
"sum": 28,
"count": 3
}
]
}
}
}
2. En la ventana del símbolo del sistema, publique los datos de la métrica:

azureRegion . Debe coincidir con la región de implementación del recurso para el que se van a
emitir las métricas.
resourceID . El identificador de recurso del recurso de Azure con respecto al que realiza el
seguimiento de la métrica.
AccessToken . Pegue el token que haya adquirido anteriormente.
curl -X POST https://<azureRegion>.monitoring.azure.com/<resourceId>/metrics -H "Content-Type:

application/json" -H "Authorization: Bearer <AccessToken>" -d @custommetric.json
3. Cambie la marca de tiempo y los valores del archivo JSON.

4. Repita los dos pasos anteriores varias veces para tener datos durante varios minutos.
Si recibe un mensaje de error en alguna parte del proceso, tenga en cuenta la siguiente información de solución
de problemas:
1. No se pueden emitir métricas con respecto a una suscripción o grupo de recursos como el recurso de Azure.
2. No se puede colocar en el almacén una métrica si pasan más de 20 minutos desde su creación. El almacén de
métricas está optimizado para las alertas y los gráficos en tiempo real.
3. El número de nombres de dimensión debe coincidir con los valores y viceversa. Compruebe los valores.
4. Se pueden emitir métricas con respecto a una región que no es compatible con las métricas personalizadas.
Consulte las regiones admitidas.
Visualización de las métricas

2. En el menú de la izquierda, seleccione Monitor .
3. En la página Monitor , seleccione Métricas .
4. Cambie el período de agregación a Últimos 30 minutos .

5. En el menú desplegable Recursos , seleccione el recurso con respecto al que emitió la métrica.
6. En el menú desplegable Espacios de nombres , seleccione QueueProcessing .
7. En el menú desplegable Métricas , seleccione QueueDepth .
Pasos siguientes
Más información acerca de las métricas personalizadas.
Envío de datos de registro a Azure Monitor con
HTTP Data Collector API (versión preliminar
pública)
En este artículo se muestra cómo utilizar HTTP Data Collector API para enviar datos de registro a Azure
Monitor desde un cliente de API REST. Describe cómo dar formato a los datos recopilados por el script o
la aplicación, incluirlos en una solicitud y hacer que esa solicitud la autorice Azure Monitor. Se
proporcionan ejemplos de PowerShell, C# y Python.
NOTE
Este artículo se ha actualizado recientemente para usar el término registros de Azure Monitor en lugar de Log
Analytics. Los datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen
recopilándose y analizándose por el mismo servicio de Log Analytics. Estamos actualizando la terminología para
reflejar mejor el rol de los registros de Azure Monitor. Consulte Azure Monitor terminology changes (Cambios en
la terminología de Azure Monitor) para obtener más información.
NOTE
HTTP Data Collector API de Azure Monitor se encuentra en versión preliminar pública.
Conceptos
Puede usar HTTP Data Collector API para enviar datos a un área de trabajo de Log Analytics en Azure
Monitor desde cualquier cliente que pueda llamar a una API REST. Podría tratarse de un runbook en
Azure Automation que recopila datos de administración de Azure u otra nube, o podría ser un sistema
de administración alternativo que usa Azure Monitor para consolidar y analizar los datos de registro.
Todos los datos del área de trabajo de Log Analytics se almacenan como un registro con un tipo de
registro concreto. Se da formato a los datos para enviarlos a la API del recopilador de datos HTTP como
varios registros en JSON. Al enviar los datos, se crea un registro individual en el repositorio para cada
registro en la carga de solicitud.
Creación de una solicitud

Para usar la API de recopilador de datos de HTTP, cree una solicitud POST que incluya los datos que se
van a enviar en notación de objetos JavaScript (JSON). Las siguientes tres tablas enumeran los atributos
que son necesarios para cada solicitud. Se describirá cada atributo con más detalle más adelante en el
artículo.
URI de solicitud
AT RIB UTO P RO P IEDA D
Método POST
URI https://<CustomerId>.ods.opinsights.azure.com/api/logs
?api-version=2016-04-01
Tipo de contenido application/json
Parámetros de URI de solicitud

PA RÁ M ET RO DESC RIP C IÓ N
CustomerID El identificador único del área de trabajo de Log

Analytics.
Recurso Nombre de recurso de la API: /api/logs.
Versión de API Versión de la API que se usará con esta solicitud.

Actualmente, es 2016-04-01.
Encabezados de solicitud
EN C A B EZ A DO DESC RIP C IÓ N
Authorization Firma de la autorización. Más adelante en este artículo,

encontrará información acerca de cómo crear un
encabezado HMAC-SHA256.
Log-Type Especifica el tipo de registro de los datos que se envían.

Solo puede contener letras, números y guiones bajos () y
no puede superar los 100 caracteres.
x-ms-date Fecha en que se procesó la solicitud, en formato RFC

1123.
x-ms-AzureResourceId Identificador de recurso del recurso de Azure con el que

se deben asociar los datos. Esto rellena la propiedad
_ResourceId y permite que los datos se incluyan en las
consultas de contexto del recurso. Si no se especifica
este campo, los datos no se incluirán en las consultas de
contexto del recurso.
time-generated-field Nombre de un campo en los datos que contiene la

marca de tiempo del elemento de datos. Si especifica un
campo, su contenido se usa para TimeGenerated . Si
no se especifica este campo, el valor predeterminado de
TimeGenerated es el tiempo que el mensaje se ingiere.
El contenido del campo de mensaje debe seguir el
formato ISO 8601 AAAA-MM-DDThh:mm:ssZ.
Authorization
Cualquier solicitud a HTTP Data Collector API de Azure Monitor debe incluir un encabezado de
autorización. Para autenticar una solicitud, debe firmar la solicitud con la clave principal o secundaria del
área de trabajo que realiza la solicitud. Después, pase esa firma como parte de la solicitud.
Este es el formato del encabezado de autorización:
Authorization: SharedKey <WorkspaceID>:<Signature>
WorkspaceID es el identificador único del área de trabajo de Log Analytics. Signature es un código de
autenticación de mensajes basado en hash (HMAC) que se construye a partir de la solicitud y después se
procesa mediante el algoritmo SHA256. Luego se codifica con la codificación Base64.
Use este formato para codificar la cadena de firma SharedKey :
StringToSign = VERB + "\n" +

Content-Length + "\n" +
Content-Type + "\n" +
x-ms-date + "\n" +
"/api/logs";
Este es un ejemplo de una cadena de firma:
POST\n1024\napplication/json\nx-ms-date:Mon, 04 Apr 2016 08:00:00 GMT\n/api/logs
Cuando tenga la cadena de firma, codifíquela usando un algoritmo HMAC-SHA256 en la cadena

codificada mediante UTF-8 y, después, codifique el resultado como Base64. Use este formato:
Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
Los ejemplos de las secciones siguientes tienen código de ejemplo que le ayudarán a crear un
encabezado de autorización.
Cuerpo de la solicitud
El cuerpo del mensaje debe estar en formato JSON. Debe incluir uno o varios registros con los pares de
nombre y valor de propiedad en el siguiente formato. El nombre de la propiedad solo puede contener
letras, números y guiones bajos ().
[
{
"property 1": "value1",
"property 4": "value4"
}
]
Puede procesar por lotes varios registros en una sola solicitud con el formato siguiente. Todos los
registros deben ser del mismo tipo de registro.
[
{
},
{
}
]
Propiedades y tipo de registro

Cuando se envían datos a través de HTTP Data Collector API de Azure Monitor, se define un tipo de
registro personalizado. Actualmente, no se pueden escribir datos en tipos de registros existentes creados
por otros tipos de datos y soluciones. Azure Monitor lee los datos entrantes y después crea las
propiedades que coinciden con los tipos de datos de los valores que especifique.
Cada solicitud a Data Collector API debe incluir un encabezado Log-Type con el nombre del tipo de
registro. El sufijo _CL se anexa automáticamente al nombre que especifique para distinguirlo de otros
tipos de registros como un registro personalizado. Por ejemplo, si escribe el nombre
MyNewRecordType , Azure Monitor crea un registro con el tipo de MyNewRecordType_CL . Esto
ayuda a garantizar que no haya conflictos entre los nombres de tipo creados por el usuario y los
incluidos en las soluciones de Microsoft actuales o futuras.
Para identificar el tipo de datos de una propiedad, Azure Monitor agrega un sufijo al nombre de la
propiedad. Si una propiedad contiene un valor null, la propiedad no se incluye en ese registro. Esta tabla
enumera el tipo de datos de la propiedad y el sufijo correspondiente:
T IP O DE DATO S DE L A P RO P IEDA D SUF IJO
String _s
Boolean _b
Double _d
Fecha/hora _t
GUID (almacenado como una cadena) _g
NOTE
A los valores de cadena que parecen ser GUID se les asigna el sufijo _g y se les aplica formato de GUID, incluso si
el valor entrante no incluye guiones. Por ejemplo, "8145d822-13a7-44ad-859c-36f31a84f6dd" y
"8145d82213a744ad859c36f31a84f6dd" se almacenarán como "8145d822-13a7-44ad-859c-36f31a84f6dd".
Las únicas diferencias entre esta y otra cadena es la _g en el nombre y la inserción de guiones si no se
proporcionan en la entrada.
El tipo de datos que utiliza Azure Monitor para cada propiedad depende de si ya existe el tipo de registro
para el nuevo registro.
Si el tipo de registro no existe, Azure Monitor crea uno nuevo mediante la inferencia de tipos JSON
para determinar el tipo de datos para cada propiedad del nuevo registro.
Si el tipo de registro existe, Azure Monitor intenta crear un nuevo registro en función de las
propiedades existentes. Si el tipo de datos de una propiedad en el nuevo registro no coincide y no se
puede convertir al tipo existente, o si el registro incluye una propiedad que no existe, Azure Monitor
crea una nueva propiedad que tiene el sufijo pertinente.
Por ejemplo, esta entrada de envío crearía un registro con tres propiedades number_d , boolean_b y
string_s :
Si después se envía la entrada siguiente, con todos los valores con formato de cadena, las propiedades
no cambiarían. Estos valores se pueden convertir a los tipos de datos existentes:
Pero, si después se realiza el siguiente envío, Azure Monitor crearía las nuevas propiedades boolean_d
y string_d . Estos valores no se pueden convertir:
Si después se envía la entrada siguiente, antes de que se cree el tipo de registro, Azure Monitor crearía
un registro con tres propiedades number_s , boolean_s y string_s . En esta entrada, se da un formato
de cadena a cada uno de los valores iniciales:
Propiedades reservadas
Las propiedades siguientes están reservadas y no deben usarse en un registro de tipo personalizado.
Recibirá un error si la carga útil incluye alguno de estos nombres de propiedad.
tenant
Límites de datos
Existen algunas restricciones en cuando a los datos enviados a Data Collector API de Azure Monitor.
Máximo de 30 MB por publicación en Data Collector API de Azure Monitor. Se trata de un límite de
tamaño para una sola publicación. Si los datos de una única publicación superan los 30 MB, debe
dividir los datos en fragmentos más pequeños y enviarlos al mismo tiempo.
Límite de 32 kB para los valores de campo. Si el valor del campo es mayor que 32 kB, se truncarán
los datos.
El número máximo recomendado de campos para un tipo determinado es 50. Se trata de un límite
práctico desde una perspectiva de la experiencia de búsqueda y la facilidad de uso.
Una tabla en un área de trabajo de Log Analytics solo admite hasta 500 columnas (denominada
campo en este artículo).
El número máximo de caracteres para el nombre de columna es 500.
Códigos de retorno
El código de estado HTTP 200 significa que se ha recibido la solicitud para su procesamiento. Esto indica
que el trabajo se ha completado correctamente.
Esta tabla muestra el conjunto completo de códigos de estado que el servicio puede devolver:
C Ó DIGO ESTA DO C Ó DIGO DE ERRO R DESC RIP C IÓ N
200 Aceptar La solicitud se aceptó

correctamente.
400 Solicitud incorrecta InactiveCustomer El área de trabajo se

cerró.
400 Solicitud incorrecta InvalidApiVersion El servicio no reconoció la

versión de API
especificada.
400 Solicitud incorrecta InvalidCustomerId El identificador de área de

trabajo especificado no es
válido.
400 Solicitud incorrecta InvalidDataFormat No envió un formato

JSON no válido. El cuerpo
de la respuesta puede
contener más información
acerca de cómo resolver
el error.
400 Solicitud incorrecta InvalidLogType El tipo de registro

especificado contenía
caracteres especiales o
valores numéricos.
400 Solicitud incorrecta MissingApiVersion No se especificó la versión

de API.
400 Solicitud incorrecta MissingContentType No se especificó el tipo de

contenido.
400 Solicitud incorrecta MissingLogType No se especificó el tipo de

registro de valor
requerido.
C Ó DIGO ESTA DO C Ó DIGO DE ERRO R DESC RIP C IÓ N
400 Solicitud incorrecta UnsupportedContentTyp No se estableció el tipo

e de contenido en
application/json .
403 Prohibido InvalidAuthorization El servicio no pudo

autenticar la solicitud.
Compruebe que el
identificador del área de
trabajo y la clave de
conexión sean válidas.
404 No encontrado La dirección URL

proporcionada no es
correcta, bien o la
solicitud es demasiado
grande.
429 Demasiadas solicitudes El servicio está

experimentando un gran
volumen de datos de su
cuenta. Vuelva a intentar
realizar la solicitud más
tarde.
500 Internal Server Error UnspecifiedError El servicio detectó un

error interno. Vuelva a
intentar realizar la
solicitud.
503 Servicio no disponible ServiceUnavailable El servicio actualmente no

está disponible para
recibir solicitudes. Vuelva
a intentar realizar la
solicitud.
Consultar datos
Para consultar los datos enviados por HTTP Data Collector API de Azure Monitor, busque los registros
cuyo Type sea igual al valor de LogType que especificó, con el sufijo _CL . Por ejemplo, si utilizó
MyCustomLog , se devolverán todos los registros con MyCustomLog_CL .
Solicitudes de ejemplo
En las secciones siguientes, encontrará ejemplos de cómo enviar datos a HTTP Data Collector API de
Azure Monitor mediante el uso de diferentes lenguajes de programación.
Para cada ejemplo, siga estos pasos para establecer las variables para el encabezado de autorización:
1. En Azure Portal, seleccione el área de trabajo de Log Analytics.
2. Seleccione Administración de agentes .
3. A la derecha de Id. de área de trabajo , seleccione el icono de copia y pegue el identificador como
valor de la variable Id. de cliente .
4. A la derecha de Clave principal , seleccione el icono de copia y pegue el identificador como valor de
la variable Clave compar tida .
También puede cambiar las variables del tipo de registro y de los datos JSON.
Ejemplo de PowerShell
# Replace with your Workspace ID

$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
# Replace with your Primary Key

$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# Specify the name of the record type that you'll be creating

$LogType = "MyRecordType"
# You can use an optional field to specify the timestamp from the data. If the time field is not
specified, Azure Monitor assumes the time is the message ingestion time
$TimeStampField = ""
# Create two records with the same set of properties to create

$json = @"
[{ "StringValue": "MyString1",
"NumberValue": 42,
"BooleanValue": true,
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{ "StringValue": "MyString2",
"NumberValue": 43,
"BooleanValue": false,
"DateValue": "2019-09-12T20:00:00.625Z",
"GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@
# Create the function to create the authorization signature

Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType,
$resource)
{
$xHeaders = "x-ms-date:" + $date
$stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n"
+ $resource
$bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
$keyBytes = [Convert]::FromBase64String($sharedKey)
$sha256 = New-Object System.Security.Cryptography.HMACSHA256

$sha256.Key = $keyBytes
$calculatedHash = $sha256.ComputeHash($bytesToHash)
$encodedHash = [Convert]::ToBase64String($calculatedHash)
$authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
return $authorization
}
# Create the function to create and post the request

Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
$method = "POST"
$contentType = "application/json"
$resource = "/api/logs"
$rfc1123date = [DateTime]::UtcNow.ToString("r")
$contentLength = $body.Length
$signature = Build-Signature `
-customerId $customerId `
-sharedKey $sharedKey `
-date $rfc1123date `
-contentLength $contentLength `
-method $method `
-contentType $contentType `
-resource $resource
$uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-
04-01"
$headers = @{
"Authorization" = $signature;
"Log-Type" = $logType;
"x-ms-date" = $rfc1123date;
"time-generated-field" = $TimeStampField;
}
$response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers

$headers -Body $body -UseBasicParsing
return $response.StatusCode
# Submit the data to the API endpoint

Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body
([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType
Ejemplo de C#
using System;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Security.Cryptography;
using System.Text;
using System.Threading.Tasks;
namespace OIAPIExample
{
class ApiExample
{
// An example JSON object, with key/value pairs
static string json = @"[{""DemoField1"":""DemoValue1"",""DemoField2"":""DemoValue2""},
{""DemoField3"":""DemoValue3"",""DemoField4"":""DemoValue4""}]";
// Update customerId to your Log Analytics workspace ID

static string customerId = "xxxxxxxx-xxx-xxx-xxx-xxxxxxxxxxxx";
// For sharedKey, use either the primary or the secondary Connected Sources client
authentication key
static string sharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
// LogName is name of the event type that is being submitted to Azure Monitor
static string LogName = "DemoExample";
// You can use an optional field to specify the timestamp from the data. If the time field
is not specified, Azure Monitor assumes the time is the message ingestion time
static string TimeStampField = "";
static void Main()

{
// Create a hash for the API signature
var datestring = DateTime.UtcNow.ToString("r");
var jsonBytes = Encoding.UTF8.GetBytes(json);
string stringToHash = "POST\n" + jsonBytes.Length + "\napplication/json\n" + "x-ms-
date:" + datestring + "\n/api/logs";
string hashedString = BuildSignature(stringToHash, sharedKey);
string signature = "SharedKey " + customerId + ":" + hashedString;
PostData(signature, datestring, json);

}
// Build the API signature

// Build the API signature
public static string BuildSignature(string message, string secret)
{
var encoding = new System.Text.ASCIIEncoding();
byte[] keyByte = Convert.FromBase64String(secret);
byte[] messageBytes = encoding.GetBytes(message);
using (var hmacsha256 = new HMACSHA256(keyByte))
{
byte[] hash = hmacsha256.ComputeHash(messageBytes);
return Convert.ToBase64String(hash);
}
}
// Send a request to the POST API endpoint

public static void PostData(string signature, string date, string json)
{
try
{
string url = "https://" + customerId + ".ods.opinsights.azure.com/api/logs?api-
version=2016-04-01";
System.Net.Http.HttpClient client = new System.Net.Http.HttpClient();

client.DefaultRequestHeaders.Add("Accept", "application/json");
client.DefaultRequestHeaders.Add("Log-Type", LogName);
client.DefaultRequestHeaders.Add("Authorization", signature);
client.DefaultRequestHeaders.Add("x-ms-date", date);
client.DefaultRequestHeaders.Add("time-generated-field", TimeStampField);
System.Net.Http.HttpContent httpContent = new StringContent(json, Encoding.UTF8);

httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
Task<System.Net.Http.HttpResponseMessage> response = client.PostAsync(new Uri(url),
httpContent);
System.Net.Http.HttpContent responseContent = response.Result.Content;

string result = responseContent.ReadAsStringAsync().Result;
Console.WriteLine("Return Result: " + result);
}
catch (Exception excep)
{
Console.WriteLine("API Post Exception: " + excep.Message);
}
}
}
}
Ejemplo de Python 2
import json
import requests
import datetime
import hashlib
import hmac
import base64
# Update the customer ID to your Log Analytics workspace ID

customer_id = 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# For the shared key, use either the primary or the secondary Connected Sources client
authentication key
shared_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# The log type is the name of the event that is being submitted
log_type = 'WebMonitorTest'
# An example JSON web monitor object

json_data = [{
json_data = [{
"slot_ID": 12345,
"ID": "5cdad72f-c848-4df0-8aaa-ffe033e75d57",
"availability_Value": 100,
"performance_Value": 6.954,
"measurement_Name": "last_one_hour",
"duration": 3600,
"warning_Threshold": 0,
"critical_Threshold": 0,
"IsActive": "true"
},
{
"slot_ID": 67890,
"ID": "b6bee458-fb65-492e-996d-61c4d7fbb942",
"duration": 3600,
"IsActive": "false"
}]
body = json.dumps(json_data)
#####################
######Functions######
#####################
# Build the API signature

def build_signature(customer_id, shared_key, date, content_length, method, content_type, resource):
x_headers = 'x-ms-date:' + date
string_to_hash = method + "\n" + str(content_length) + "\n" + content_type + "\n" + x_headers +
"\n" + resource
bytes_to_hash = bytes(string_to_hash).encode('utf-8')
decoded_key = base64.b64decode(shared_key)
encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash,
digestmod=hashlib.sha256).digest())
authorization = "SharedKey {}:{}".format(customer_id,encoded_hash)
return authorization
# Build and send a request to the POST API

def post_data(customer_id, shared_key, body, log_type):
method = 'POST'
content_type = 'application/json'
resource = '/api/logs'
rfc1123date = datetime.datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
content_length = len(body)
signature = build_signature(customer_id, shared_key, rfc1123date, content_length, method,
content_type, resource)
uri = 'https://' + customer_id + '.ods.opinsights.azure.com' + resource + '?api-version=2016-04-
01'
headers = {
'content-type': content_type,
'Authorization': signature,
'Log-Type': log_type,
'x-ms-date': rfc1123date
}
response = requests.post(uri,data=body, headers=headers)

if (response.status_code >= 200 and response.status_code <= 299):
print 'Accepted'
else:
print "Response code: {}".format(response.status_code)
post_data(customer_id, shared_key, body, log_type)
Ejemplo de Python 3
import json
import requests
import datetime
import hashlib
import hmac
import base64
# Update the customer ID to your Log Analytics workspace ID

customer_id = 'xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# For the shared key, use either the primary or the secondary Connected Sources client
authentication key
shared_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# The log type is the name of the event that is being submitted
log_type = 'WebMonitorTest'
# An example JSON web monitor object

json_data = [{
"slot_ID": 12345,
"ID": "5cdad72f-c848-4df0-8aaa-ffe033e75d57",
"duration": 3600,
"IsActive": "true"
},
{
"slot_ID": 67890,
"ID": "b6bee458-fb65-492e-996d-61c4d7fbb942",
"duration": 3600,
"IsActive": "false"
}]
body = json.dumps(json_data)
#####################
######Functions######
#####################
# Build the API signature

def build_signature(customer_id, shared_key, date, content_length, method, content_type, resource):
x_headers = 'x-ms-date:' + date
string_to_hash = method + "\n" + str(content_length) + "\n" + content_type + "\n" + x_headers +
"\n" + resource
bytes_to_hash = bytes(string_to_hash, encoding="utf-8")
decoded_key = base64.b64decode(shared_key)
encoded_hash = base64.b64encode(hmac.new(decoded_key, bytes_to_hash,
digestmod=hashlib.sha256).digest()).decode()
authorization = "SharedKey {}:{}".format(customer_id,encoded_hash)
return authorization
# Build and send a request to the POST API

def post_data(customer_id, shared_key, body, log_type):
method = 'POST'
content_type = 'application/json'
resource = '/api/logs'
rfc1123date = datetime.datetime.utcnow().strftime('%a, %d %b %Y %H:%M:%S GMT')
content_length = len(body)
signature = build_signature(customer_id, shared_key, rfc1123date, content_length, method,
content_type, resource)
01'
headers = {
'content-type': content_type,
'Authorization': signature,
'Log-Type': log_type,
'x-ms-date': rfc1123date
}
response = requests.post(uri,data=body, headers=headers)

if (response.status_code >= 200 and response.status_code <= 299):
print('Accepted')
else:
print("Response code: {}".format(response.status_code))
post_data(customer_id, shared_key, body, log_type)
Alternativas y consideraciones
Aunque la API del recopilador de datos debe cubrir la mayor parte de sus necesidades para recopilar
datos de formato libre en los registros de Azure, hay casos en los que podría ser necesaria una
alternativa para solucionar algunas de las limitaciones de la API. Las siguientes son todas las opciones,
junto con las consideraciones principales:
A LT ERN AT IVA DESC RIP C IÓ N IDÓ N EA PA RA
Eventos personalizados: Ingesta Application Insights, instrumentado Los datos se generan dentro
basada en SDK nativa de normalmente a través de un SDK de la aplicación, pero el SDK
Application Insights dentro de la aplicación, ofrece la no los recibe a través de uno
capacidad de enviar datos de los tipos de datos
personalizados a través de los predeterminados
eventos personalizados. (solicitudes, dependencias,
excepciones, etc.).
Datos que está
correlacionados con mayor
frecuencia con otros datos
de aplicación en Application
Insights
API del recopilador de datos en La API del recopilador de datos en Datos que no
registros de Azure Monitor registros de Azure Monitor es una necesariamente se
forma completamente libre para la generaron dentro de una
ingesta de datos. Pueden enviársele aplicación instrumentada en
todos los datos cuyo formato sea Application Insights.
un objeto JSON. Una vez enviados, Algunos ejemplos son tablas
se procesarán y estarán disponibles de hechos y de búsqueda,
en los registros, para que se datos de referencia,
correlacionen con otros datos en los estadísticas agregadas
registros u otros datos de previamente, etc.
Application Insights. Diseñado para datos a los
que se harán referencia
Es bastante fácil cargar los datos cruzadas con otros datos de
como archivos en un blob de Azure Azure Monitor (Application
Blob, desde donde se procesarán y Insights, otros tipos de
cargarán estos archivos en Log datos de registros, Security
Analytics. Consulte este artículo Center, Azure Monitor para
para ver un ejemplo de contenedores y máquinas
implementación de una canalización virtuales, etc.).
de este tipo.
A LT ERN AT IVA DESC RIP C IÓ N IDÓ N EA PA RA
Azure Data Explorer Azure Data Explorer (ADX) es la Datos que no se

plataforma de datos que se utiliza correlacionan con ningún
en Application Insights Analytics y otro dato en Application
los registros de Azure Monitor. Insights o los registros.
Ahora con disponibilidad general Datos que requieren ingesta
("GA"), cuando usa la plataforma de o procesamiento avanzados
datos sin procesar obtiene completa que no están disponibles
flexibilidad (que requiere la actualmente en los registros
sobrecarga de administración) en el de Azure Monitor.
clúster (RBAC, tasa de retención,
esquema, etc). Azure Data Explorer
proporciona muchas opciones de
ingestión, incluidos los archivos
JSON, CSV y TSV.
Pasos siguientes
Use Log Search API para recuperar datos desde el área de trabajo de Log Analytics.
Más información sobre cómo crear una canalización de datos con Data Collector API mediante el
flujo de trabajo Logic Apps a Azure Monitor.
Creación de una canalización de datos con Data
Collector API
Data Collector API de Azure Monitor permite importar los datos de registros personalizados en un área de trabajo
de Log Analytics en Azure Monitor. Los únicos requisitos son que los datos tengan formato JSON y estén divididos
en segmentos de 30 MB o menos. Se trata de un mecanismo completamente flexible que se puede utilizar de
muchas maneras: desde datos enviados directamente por la aplicación hasta cargas ad hoc de un solo uso. Este
artículo describe algunos puntos de partida para un escenario común: la necesidad de cargar los datos
almacenados en archivos de forma regular y automatizada. Aunque la canalización que se presenta aquí no será la
de mayor rendimiento ni optimización, está pensada para servir como punto de partida para la creación de una
canalización de producción propia.
NOTE
Este artículo se ha actualizado recientemente para usar el término registros de Azure Monitor en lugar de Log Analytics. Los
datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen recopilándose y analizándose por
el mismo servicio de Log Analytics. Estamos actualizando la terminología para reflejar mejor el rol de los registros de Azure
Monitor. Consulte Azure Monitor terminology changes (Cambios en la terminología de Azure Monitor) para obtener más
información.
Problema de ejemplo
El resto de este artículo, examinaremos los datos de la vista de página de Application Insights. En nuestro
escenario hipotético, queremos correlacionar información geográfica recopilada de manera predeterminada por
el SDK de Application Insights con datos personalizados que contienen la población de todos los países o regiones
del mundo, con el fin de identificar dónde debemos dedicar el máximo importe en dólares en marketing.
Se usa un origen de datos público como UN World Population Prospects (Perspectivas de población mundial de la
ONU) para este propósito. Los datos tendrán el siguiente esquema simple:
En nuestro ejemplo, se supone que se cargará un archivo nuevo con los datos del último año tan pronto como
esté disponible.
Diseño general
Se usa una lógica de tipo ETL clásica para diseñar nuestra canalización. La arquitectura tendrá el aspecto siguiente:
En este artículo no se explica cómo crear datos ni cómo cargarlos en una cuenta de Azure Blob Storage. En su
lugar, se recoge el flujo en cuanto se carga un archivo nuevo en el blob. Desde aquí:
1. Un proceso detectará que se han cargado nuevos datos. En nuestro ejemplo se utiliza una aplicación lógica
de Azure que dispone de un desencadenador para detectar la carga de nuevos datos en un blob.
2. Un procesador lee estos nuevos datos y los convierte en JSON, el formato requerido por Azure Monitor. En
este ejemplo, usamos una función de Azure como una manera ligera, eficaz y rentable de ejecutar el código
de procesamiento. La misma aplicación lógica que se utiliza para detectar nuevos datos inicia la función.
3. Por último, una vez que el objeto JSON está disponible, se envía a Azure Monitor. La misma aplicación
lógica envía los datos a Azure Monitor mediante la actividad integrada de Log Analytics Data Collector.
Aunque la configuración detallada del almacenamiento de blobs, la aplicación lógica o la función de Azure no se
describen en este artículo, hay disponibles instrucciones detalladas en las páginas de los productos específicos.
Para supervisar esta canalización, se usan Application Insights para supervisar la función de Azure (más
información aquí) y Azure Monitor para supervisar la aplicación lógica (más información aquí).
Configuración de la canalización
Para establecer la canalización, primero debe asegurarse de que tiene el contenedor de blobs creado y
configurado. Del mismo modo, asegúrese de que se ha creado el área de trabajo de Log Analytics donde le
gustaría enviar los datos.
Ingesta de datos JSON

La ingesta de datos JSON es trivial con Logic Apps y, puesto que no se necesita llevar a cabo ninguna
transformación, podemos encapsular toda la canalización en una única aplicación lógica. Una vez que se han
configurado el contenedor de blobs y el área de trabajo de Log Analytics, cree una nueva aplicación lógica y
configúrela como sigue:
Guarde la aplicación lógica y pruébela.
Ingesta de XML, CSV u otros formatos de datos

Hoy en día, Logic Apps no tiene funcionalidades integradas para transformar fácilmente XML, CSV u otros tipos al
formato JSON. Por lo tanto, es necesario usar otros medios para realizar esta transformación. En este artículo,
usamos las funcionalidades de proceso sin servidor de Azure Functions como una manera muy ligera y rentable
de hacerlo.
En este ejemplo se analiza un archivo CSV, pero se puede procesar cualquier otro tipo de archivo de forma similar.
Basta con modificar el apartado de deserialización de la función de Azure para reflejar la lógica adecuada para el
tipo de datos específico.
1. Cree una nueva función de Azure, con el runtime v1 de la función y la opción basado en consumo cuando
se le solicite. Seleccione la plantilla Desencadenador HTTP para C# como punto de partida, que configura
los enlaces tal y como se necesita.
2. En la pestaña Ver archivos del panel derecho, cree un nuevo archivo llamado project.json y pegue el
siguiente código de los paquetes de NuGet que estamos usando:
{
"frameworks": {
"net46":{
"dependencies": {
"CsvHelper": "7.1.1",
"Newtonsoft.Json": "11.0.2"
}
}
}
}
3. Cambie a run.csx en el panel derecho y reemplace el código predeterminado por el siguiente.
NOTE
Para el proyecto, debe reemplazar el modelo de registro (la clase "PopulationRecord") por su propio esquema de
datos.
using System.Net;
using Newtonsoft.Json;
using CsvHelper;
class PopulationRecord
{
public String Location { get; set; }
public int Time { get; set; }
public long Population { get; set; }
}
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)

{
string filePath = await req.Content.ReadAsStringAsync(); //get the CSV URI being passed from Logic
App
string response = "";
//get a stream from blob

WebClient wc = new WebClient();
Stream s = wc.OpenRead(filePath);
//read the stream

using (var sr = new StreamReader(s))
{
var csvReader = new CsvReader(sr);
var records = csvReader.GetRecords<PopulationRecord>(); //deserialize the CSV stream as an

IEnumerable
response = JsonConvert.SerializeObject(records); //serialize the IEnumerable back into JSON

}
return response == null

? req.CreateResponse(HttpStatusCode.BadRequest, "There was an issue getting data")
: req.CreateResponse(HttpStatusCode.OK, response);
}
4. Guarde la función.
5. Pruebe la función para asegurarse de que el código funciona correctamente. Cambie a la pestaña Probar
en el panel derecho y configure la prueba como sigue. Especifique un vínculo a un blob con datos de
ejemplo en cuadro de texto Cuerpo de la solicitud . Después de hacer clic en Ejecutar , debería ver la
salida JSON en el cuadro Salida :
Ahora debemos volver atrás y modificar la aplicación lógica que comenzamos a crear anteriormente para incluir
los datos ingeridos y convertidos a formato JSON. Mediante el Diseñador de vistas, realice la configuración como
se indica a continuación y guarde la aplicación lógica:
Prueba de la canalización
Ahora puede cargar un archivo nuevo en el blob que configuró anteriormente y será supervisado por la aplicación
lógica. En unos instantes, verá el inicio de una nueva instancia de la aplicación lógica, la llamada a la función de
Azure y, después, el envío correcto de los datos a Azure Monitor.
NOTE
Puede tardar hasta 30 minutos para que los datos aparezcan en Azure Monitor la primera vez que envía un nuevo tipo de
datos.
Correlación con otros datos de Log Analytics y Application Insights

Para completar nuestro objetivo de poner en correlación los datos de la vista de página de Application Insights
con los datos de población que se han ingerido del origen de datos personalizado, ejecute la siguiente consulta
desde la ventana de Application Insights Analytics o en el área de trabajo de Log Analytics:
app("fabrikamprod").pageViews
| summarize numUsers = count() by client_CountryOrRegion
workspace("customdatademo").Population_CL
) on $left.client_CountryOrRegion == $right.Location_s
| project client_CountryOrRegion, numUsers, Population_d
La salida ahora debe mostrar los dos orígenes de datos unidos.
Mejoras sugeridas para una canalización de producción

En este artículo se presenta un prototipo funcional, cuya lógica subyacente se puede aplicar a una verdadera
solución con calidad de producción. Para esta solución con calidad de producción, se recomiendan las siguientes
mejoras:
Agregue control de errores y lógica de reintento en la aplicación lógica y en la función.
Agregue lógica para asegurarse de que no se supera el límite de 30 MB en una sola llamada a Log Analytics
Ingestion API. Divida los datos en segmentos más pequeños si es necesario.
Configure una directiva de limpieza en el almacenamiento de blobs. Una vez que se han enviado
correctamente al área de trabajo de Log Analytics, a menos que quiera mantener los datos sin procesar
disponibles para fines de archivo, no hay ninguna razón para seguir almacenándolos.
Compruebe que la supervisión está habilitada en la canalización completa y agregue puntos de seguimiento y
alertas según corresponda.
Aproveche las ventajas del control de código fuente para administrar el código de la función y la aplicación
lógica.
Asegúrese de seguir una directiva de administración de cambios adecuada, de manera que si cambia el
esquema, la función y la aplicación lógica se modifican en consecuencia.
Si va a cargar varios tipos de datos diferentes, divídalos en carpetas individuales dentro del contenedor de
blobs y cree la lógica en función del tipo de datos.
Pasos siguientes
Obtenga más información sobre Data Collector API para escribir datos en el área de trabajo de Log Analytics
desde cualquier cliente de API REST.
Conector de Azure Monitor Logs para Logic Apps y
Power Automate
Azure Logic Apps y Power Automate le permite crear flujos de trabajo automatizados, con cientos de acciones
para diversos servicios. El conector de Azure Monitor Logs le permite crear flujos de trabajo destinados a
recuperar datos de un área de trabajo de Log Analytics o de una aplicación Application Insights en Azure Monitor.
En este artículo se describen las acciones que se incluyen con el conector y se proporciona un tutorial para crear
un flujo de trabajo con estos datos.
Por ejemplo, puede crear una aplicación lógica para usar los datos de registro de Azure Monitor incluidos en una
notificación de correo electrónico de Office 365, crear un error en Azure DevOps o publicar un mensaje de Slack.
Puede desencadenar un flujo de trabajo mediante una programación simple o a partir de alguna acción de un
servicio conectado, como cuando se recibe un correo electrónico o un tweet.
Límites de conector
El conector de registros de Azure Monitor tiene estos límites:
Tamaño máximo de datos: 16 MB
Tamaño máximo de respuesta de consultas de 100 MB
Número máximo de registros: 500.000
Tiempo de espera máximo de consulta de 110 segundos.
En función del tamaño de los datos y de la consulta que use, el conector puede alcanzar sus límites y producir un
error. Puede solucionar estos casos al ajustar la periodicidad del desencadenador para que se ejecute con más
frecuencia y consulte menos datos. Puede usar consultas que agreguen los datos para devolver menos registros
y columnas.
Acciones
En la tabla siguiente se describen las acciones incluidas con el conector de Azure Monitor Logs. Ambos le
permiten ejecutar una consulta de registro en un área de trabajo de Log Analytics o una aplicación de Application
Insights. La diferencia radica en la forma en que se devuelven los datos.
NOTE
El conector de Azure Monitor Logs reemplaza el conector de Azure Log Analytics y el conector de Azure Application
Insights. Este conector proporciona la misma funcionalidad que los demás y es el método preferido para ejecutar una
consulta en un área de trabajo de Log Analytics o una aplicación de Application Insights.
A C C IÓ N DESC RIP C IÓ N
Ejecutar la consulta y mostrar los resultados Devuelve cada fila como su propio objeto. Utilice esta acción
si desea trabajar con cada fila por separado en el resto del
flujo de trabajo. Normalmente, la acción va seguida de una
actividad Foreach.
A C C IÓ N DESC RIP C IÓ N
Ejecutar la consulta y visualizar los resultados Devuelve todas las filas del conjunto de resultados como un
objeto formateado único. Utilice esta acción si desea utilizar el
conjunto de resultados en el resto del flujo de trabajo, por
ejemplo para enviar los resultados en un correo.
Tutoriales
En los siguientes tutoriales se muestra el uso de los conectores de Azure Monitor en Azure Logic Apps. Puede
realizar este mismo ejemplo con Power Automate. La única diferencia es cómo crear el flujo de trabajo inicial y
ejecutarlo cuando haya finalizado. La configuración del flujo de trabajo y las acciones es la misma en ambos
casos. Consulte Creación de un flujo desde una plantilla en Power Automate para empezar.
Crear una aplicación lógica
Vaya a Logic Apps en Azure Portal y haga clic en Agregar . Seleccione las opciones de Suscripción , Grupo de
recursos y Región para almacenar la nueva aplicación lógica y, a continuación, asígnele un nombre único.
Puede activar la opción de configuración de Log Analytics para recopilar información sobre los eventos y datos
en tiempo de ejecución, tal y como se describe en Configuración de registros de Azure Monitor y recopilación de
datos de diagnóstico para Azure Logic Apps. Esta configuración no es necesaria para usar el conector de Azure
Monitor Logs.
Seleccione Revisar y crear y, a continuación, Crear . Cuando la implementación finalice, haga clic en Ir al
recurso para abrir el Diseñador de aplicaciones lógicas .
Creación de un desencadenador para la aplicación lógica
En Empezar con un desencadenador común , seleccione Periodicidad . Esta acción crea una aplicación lógica
que se ejecuta automáticamente a intervalos regulares. En el cuadro Frecuencia de la acción, seleccione Día y,
en el cuadro Inter valo , escriba 1 para ejecutar el flujo de trabajo una vez al día.
Tutorial: Envío de los resultados visualizados por correo

En el siguiente tutorial se muestra cómo crear una aplicación lógica que envía los resultados de una consulta de
registro de Azure Monitor por correo electrónico.
Adición de una acción de Azure Monitor Logs
Haga clic en + Nuevo paso para agregar una acción que se ejecute después de la acción de periodicidad. En
Elegir una acción , escriba azure monitor y, a continuación, seleccione Azure Monitor Logs .
Haga clic en Azure Log Analytics: ejecutar consulta y ver resultados .

Adición de una acción de Azure Monitor Logs
Seleccione las opciones de Suscripción y Grupo de recursos para su área de trabajo de Log Analytics.
Seleccione Área de trabajo de Log Analytics en Tipo de recurso y, a continuación, seleccione el nombre del área
de trabajo en Nombre del recurso .
En la ventana Consulta , agregue la siguiente consulta de registro.
Event
| where TimeGenerated > ago(1day)
| summarize TotalErrors=count() by Computer
| sort by Computer asc
Seleccione Establecer en la consulta en Inter valo de tiempo y Tabla HTML en Tipo de gráfico .
La cuenta asociada a la conexión actual enviará el correo. Puede hacer clic en Cambiar conexión para
especificar otra cuenta.
Adición de una acción de correo electrónico
Haga clic en + Nuevo paso y, a continuación, en + Agregar una acción . En Elegir una acción , escriba
outlook y, a continuación, seleccione Office 365 Outlook .
Seleccione Enviar correo electrónico (V2) .
Haga clic en cualquier lugar del cuadro Cuerpo para abrir una ventana Contenido dinámico con los valores de
las acciones anteriores en la aplicación lógica. Seleccione Ver más y, a continuación, Cuerpo , que es el resultado
de la consulta de la acción de Log Analytics.
Especifique la dirección de correo electrónico de un destinatario en la ventana Para y un asunto para el correo
electrónico en Asunto .
Guardado y prueba de la aplicación lógica

Haga clic en Guardar y, a continuación, en Ejecutar para realizar una serie de pruebas de la aplicación lógica.
Cuando se complete la aplicación lógica, compruebe el correo del destinatario que especificó. Debe haber recibido
un correo electrónico con un cuerpo similar al siguiente:
Pasos siguientes
Más información sobre las consultas de registro en Azure Monitor.
Más información acerca de Logic Apps.
Más información sobre Power Automate.
Automatización de procesos de Application Insights
con Logic Apps
¿Se encuentra a menudo ejecutando las mismas consultas en los datos de telemetría para comprobar si el servicio
está funcionando correctamente? ¿Desea automatizar estas consultas para encontrar tendencias y anomalías, y
crear sus propios flujos de trabajo en función de ellas? El conector Azure Application Insights para Logic Apps es la
herramienta adecuada para este fin.
NOTE
El conector de Azure Application Insights se ha reemplazado por el conector de Azure Monitor que se integra con
Azure Active Directory en lugar de requerir una clave de API y también permite recuperar datos de un área de trabajo de Log
Analytics.
Con esta integración, se pueden automatizar numerosos procesos sin tener que escribir una sola línea de código.
Puede crear una aplicación lógica con Application Insights Connector para automatizar rápidamente cualquier
proceso de Application Insights.
También puede agregar acciones adicionales. La característica Logic Apps de Azure App Service realiza cientos de
acciones disponibles. Por ejemplo, si usa una aplicación lógica, puede enviar automáticamente una notificación por
correo electrónico o crear un error en Azure DevOps. También puede utilizar una de las muchas plantillas
disponibles para ayudar a acelerar el proceso de creación de la aplicación lógica.
Creación de una aplicación lógica para Application Insights

En este tutorial, puede obtener información sobre cómo crear una aplicación lógica que usa el algoritmo de
clústeres automáticos de Analytics para agrupar los atributos en los datos para una aplicación web. El flujo envía
automáticamente los resultados por correo electrónico, y esto es solo un ejemplo de cómo puede usar Application
Insights Analytics y Logic Apps conjuntamente.
Paso 1: Creación de una aplicación lógica
2. Haga clic en Crear un recurso , seleccione Web y móvil y, a continuación, seleccione Logic App .
Paso 2: Creación de un desencadenador para la aplicación lógica
1. En la ventana del Diseñador de aplicación lógica , en Empezar con un desencadenador común ,
seleccione Periodicidad .
2. En el cuadro Inter valo , escriba 1 y, luego, en el cuadro Frecuencia , seleccione Día .
Paso 3: Incorporación de una acción de Application Insights

1. Haga clic en New Step (Nuevo paso).
2. En el cuadro de búsqueda Elegir una acción , escriba Azure Application Insights .
3. En Acciones , haga clic en Azure Application Insights: Visualizar consulta de análisis .
Paso 4: Conexión a un recurso de Application Insights

Para completar este paso, necesita un identificador de aplicación y una clave de API para el recurso. Puede
recuperarlos desde Azure Portal, como se muestra en el diagrama siguiente:
Proporcione un nombre para la conexión, el identificador de aplicación y la clave de API.
Paso 5: Especificación del tipo de gráfico y consulta de análisis

En el siguiente ejemplo, la consulta selecciona las solicitudes con error del último día y las pone en correlación con
las excepciones que se han producido como parte de la operación. Analytics correlaciona las solicitudes erróneas
en función del identificador operation_Id. La consulta, a continuación, segmenta los resultados mediante el
algoritmo de clúster automático.
Al crear sus propias consultas, asegúrese de comprobar que funcionan correctamente en Analytics antes de
agregarlas al flujo.
1. En el cuadro Consulta , agregue la siguiente consulta de análisis:
requests
| where success == "False"
| project name, operation_Id
| join ( exceptions
| project problemId, outerMessage, operation_Id
) on operation_Id
| evaluate autocluster()
2. En el cuadro Tipo de gráfico , seleccione Tabla Html .
Paso 6: Configuración de la aplicación lógica para enviar correo electrónico

1. Haga clic en New Step (Nuevo paso).
2. En el cuadro de búsqueda, escriba Office 365 Outlook .
3. Haga clic en Office 365 Outlook : Enviar un correo electrónico .
4. En la ventana Enviar un correo electrónico , haga lo siguiente:
a. Escriba la dirección de correo electrónico del destinatario.
b. Escriba un asunto para el correo electrónico.
c. Haga clic en cualquier parte del cuadro Cuerpo y, en el menú de contenido dinámico que se abre a la
derecha, seleccione Cuerpo .
d. Haga clic en la lista desplegable Agregar nuevo parámetro y seleccione Datos adjuntos y Es HTML.
5. En el menú de contenido dinámico, haga lo siguiente:
a. Seleccione Nombre de datos adjuntos .
b. Seleccione Contenido de datos adjuntos .
c. En el campo Es HTML , seleccione Sí .
Paso 7: Guardado y prueba de la aplicación lógica
Haga clic en Guardar para guardar los cambios.
Puede esperar a que el desencadenador ejecute la aplicación lógica, o puede ejecutarla inmediatamente si
selecciona Ejecutar .
Cuando se ejecuta la aplicación lógica, los destinatarios que haya especificado en la lista de correo electrónico
recibirán un correo electrónico similar al siguiente:
Pasos siguientes
Más información sobre cómo crear consultas de análisis.
Información general sobre los agentes de Azure
Monitor
Las máquinas virtuales y otros recursos de proceso requieren un agente para recopilar datos de
supervisión necesarios para medir el rendimiento y la disponibilidad de sus cargas de trabajo y sistema
operativo invitado. En este artículo se describen los agentes utilizados por Azure Monitor y se ayuda a
determinar qué se necesita para cumplir con los requisitos del entorno concreto.
NOTE
Actualmente, Azure Monitor tiene varios agentes, debido a la reciente consolidación de Azure Monitor y Log
Analytics. Aunque puede haber superposición en sus características, cada uno tiene funcionalidades únicas. En
función de los requisitos, puede que necesite uno o varios de los agentes en las máquinas virtuales.
Puede tener un conjunto específico de requisitos que no se puede cumplir por completo con un solo
agente para una máquina virtual concreta. Por ejemplo, puede que quiera usar alertas de métricas que
requieran la extensión de Azure Diagnostics, pero que también quieran aprovechar la funcionalidad de
Azure Monitor para VM que requiere el agente de Log Analytics y Dependency Agent. En este tipo de
casos, puede usar varios agentes; se trata de un escenario común en clientes que requieren funcionalidad
de cada uno de ellos.
Resumen de los agentes

En las tablas siguientes se proporciona una comparación rápida de los agentes de Azure Monitor para
Windows y Linux. En la sección siguiente se proporcionan más detalles sobre cada uno de ellos.
NOTE
El agente de Azure Monitor se encuentra actualmente en versión preliminar con funcionalidades limitadas. Esta
tabla se actualizará.
Agentes de Windows
A GEN T E DE A Z URE
M O N ITO R ( VERSIÓ N DIA GN Ó ST IC O LO G A N A LY T IC S DEP EN DEN C IA
P REL IM IN A R) EXT EN SIÓ N ( WA D) A GEN T E A GEN T E
Entornos Azure Azure Azure Azure

compatibles Otra nube Otra nube
Local Local
Requisitos del None None None Requiere el agente

agente de Log Analytics
A GEN T E DE A Z URE
M O N ITO R ( VERSIÓ N DIA GN Ó ST IC O LO G A N A LY T IC S DEP EN DEN C IA
P REL IM IN A R) EXT EN SIÓ N ( WA D) A GEN T E A GEN T E
Datos Registros de Registros de Registros de Dependencias de

recopilados eventos eventos eventos procesos
Rendimiento Eventos de ETW Rendimiento Métricas de
Rendimiento Registros basados conexión de red
Registros basados en archivos
en archivos Registros IIS
Registros IIS Conclusiones y
Registros de soluciones
aplicaciones .NET Otros servicios
Volcados de
memoria
Registros de
diagnósticos del
agente
Destinatario de Registros de Azure Azure Storage Registros de Azure Registros de Azure

los datos Monitor Métricas de Azure Monitor Monitor
Métricas de Azure Monitor (a través del agente
Monitor Centro de eventos de Log Analytics)
Ser vicios y Log Analytics Explorador de Azure Monitor para Azure Monitor para
features Explorador de métricas máquinas virtuales máquinas virtuales
Se admite métricas Log Analytics Mapa de servicio
Azure Automation
Azure Security
Center
Azure Sentinel
Agentes de Linux
A GEN T E DE
A Z URE
M O N ITO R DIA GN Ó ST IC O
( VERSIÓ N EXT EN SIÓ N T EL EGRA F LO G A N A LY T IC S DEP EN DEN C IA
P REL IM IN A R) ( WA D) A GEN T E A GEN T E A GEN T E
Entornos Azure Azure Azure Azure Azure

compatibles Otra nube Otra nube Otra nube
Local Local Local
Requisitos del None None None None Requiere el

agente agente de Log
Analytics
Datos syslog syslog Rendimiento syslog Dependencias

recopilados Rendimiento Rendimiento Rendimiento de procesos
Métricas de
conexión de red
Destinatario Registros de Azure Storage Métricas de Registros de Registros de

de los datos Azure Monitor Centro de Azure Monitor Azure Monitor Azure Monitor
Métricas de eventos (a través del
Azure Monitor agente de Log
Analytics)
A GEN T E DE
A Z URE
M O N ITO R DIA GN Ó ST IC O
( VERSIÓ N EXT EN SIÓ N T EL EGRA F LO G A N A LY T IC S DEP EN DEN C IA
P REL IM IN A R) ( WA D) A GEN T E A GEN T E A GEN T E
Ser vicios y Log Analytics Explorador de Azure Monitor Azure Monitor

features Explorador de métricas para máquinas para máquinas
Se admite métricas virtuales virtuales
Log Analytics Mapa de
Azure servicio
Automation
Azure Security
Center
Azure Sentinel
Agente de Azure Monitor (versión preliminar)

El agente de Azure Monitor se encuentra actualmente en versión preliminar y reemplazará al agente de
Log Analytics y al agente de Telegraf para máquinas virtuales Windows y Linux. Puede enviar datos a los
registros y métricas de Azure Monitor y usar las reglas de recopilación de datos (DCR) que proporcionan
un método más escalable para configurar la recopilación de datos y los destinos de cada agente.
Utilice el agente de Azure Monitor si necesita:
Recopilar los registros y las métricas de los invitados de cualquier máquina virtual en Azure, en otras
nubes o en el entorno local. (Azure solo en versión preliminar).
Enviar datos a registros y métricas de Azure Monitor para su análisis con Azure Monitor.
Enviar datos a Azure Storage para su archivado.
Enviar datos a herramientas de terceros mediante Azure Event Hubs.
Administrar la seguridad de las máquinas virtuales mediante Azure Security Center o Azure Sentinel.
(No disponible en versión preliminar).
Las limitaciones del agente de Azure Monitor incluyen:
Actualmente en versión preliminar pública. Consulte las limitaciones actuales para obtener una lista de
las limitaciones durante la versión preliminar pública.

El agente de Log Analytics recopila datos de supervisión del sistema operativo invitado y de las cargas de
trabajo de las máquinas virtuales de Azure, otros proveedores de nube y el entorno local. Envía datos a un
área de trabajo de Log Analytics. El agente de Log Analytics es el mismo agente que se usa en System
Center Operations Manager y en los equipos de agente de host múltiple para comunicarse con el grupo de
administración y Azure Monitor simultáneamente. Este agente también es necesario en ciertas
conclusiones de Azure Monitor y otros servicios de Azure.
NOTE
El agente de Log Analytics para Windows a menudo se conoce como Microsoft Monitoring Agent (MMA). El agente
de Log Analytics para Linux se conoce a menudo como agente de OMS.
Use el agente de Log Analytics si necesita:

Recopilar registros y datos de rendimiento de máquinas virtuales o físicas dentro o fuera de Azure.
Enviar datos a un área de trabajo de Log Analytics para aprovechar las características compatibles con
los registros de Azure Monitor, como las consultas de registro.
Use Azure Monitor para VM, que le permite supervisar las máquinas virtuales a escala y supervisa sus
procesos y dependencias en otros recursos y procesos externos.
Administrar la seguridad de las máquinas virtuales mediante Azure Security Center o Azure Sentinel.
Usar Update Management de Azure Automation, State Configuration de Azure Automation o Change
Tracking e Inventario de Azure Automation para ofrecer una administración completa de las VM de
Azure.
Usar diferentes soluciones para supervisar un servicio o una aplicación determinados.
Las limitaciones del agente de Log Analytics incluyen:
No se pueden enviar datos a métricas de Azure Monitor, Azure Storage ni Azure Event Hubs.
Dificultad para configurar definiciones de supervisión únicas para agentes individuales.
Dificultad para administrar a escala, ya que cada máquina virtual tiene una configuración única.
Extensión de Diagnósticos de Azure

La extensión Azure Diagnostics recopila datos de supervisión del sistema operativo invitado y de las
cargas de trabajo de las máquinas virtuales de Azure y otros recursos de proceso. Principalmente, recopila
datos en Azure Storage, pero también permite definir receptores de datos para enviar datos a otros
destinos, como métricas de Azure Monitor y Azure Event Hubs.
Use la extensión Azure Diagnostics si necesita:
Enviar datos a Azure Storage para archivarlos o analizarlos con herramientas como Explorador de
Azure Storage.
Enviar datos a métricas de Azure Monitor para analizarlos con el explorador de métricas y para
aprovechar las característica, como las alertas de métricas casi en tiempo real y la escalabilidad
automática (solo Windows).
Enviar datos a herramientas de terceros mediante Azure Event Hubs.
Recopilar diagnósticos de arranque para investigar los problemas de arranque de VM.
Las limitaciones de la extensión Azure Diagnostics incluyen:
Solo se puede utilizar con recursos de Azure.
Tiene capacidad limitada para enviar datos a los registros de Azure Monitor.
Agente Telegraf
El agente de InfluxData Telegraf se usa para recopilar datos de rendimiento de equipos Linux en métricas
de Azure Monitor.
Use el agente Telegraf si necesita:
Enviar datos a métricas de Azure Monitor para analizarlos con el explorador de métricas y para
aprovechar las característica, como las alertas de métricas casi en tiempo real y la escalabilidad
automática (solo Linux).
Dependency Agent
Dependency Agent recopila datos detectados acerca de los procesos que se ejecutan en las dependencias
de las máquinas virtuales y los procesos externos.
Use Dependency Agent si necesita:
Usar la característica de asignación para Azure Monitor para VM o la solución Service Map.
Tenga en cuenta lo siguiente al usar Dependency Agent:
Dependency Agent requiere que el agente de Log Analytics se instale en la misma máquina virtual.
En las máquinas virtuales de Linux, el agente de Log Analytics debe instalarse antes que la extensión
Azure Diagnostics.
Extensiones de máquina virtual

La extensión Log Analytics para Windows y Linux instala el agente de Log Analytics en máquinas virtuales
de Azure. La extensión Dependency de Azure Monitor para Windows y Linux instala Dependency Agent en
máquinas virtuales de Azure. Se trata de los mismos agentes descritos anteriormente, pero permiten
administrarlos a través de extensiones de máquinas virtuales. Debe usar extensiones para instalar y
administrar los agentes siempre que sea posible.
Sistemas operativos admitidos

En las tablas siguientes se enumeran los sistemas operativos compatibles con los agente de Azure Monitor.
Consulte la documentación de cada agente para conocer las consideraciones únicas y el proceso de
instalación. Consulte la documentación de Telegraf para obtener información sobre los sistemas
operativos admitidos. Se supone que todos los sistemas operativos son x64. No se admite x86 para
ningún sistema operativo.
Windows
SIST EM A DE A GEN T E DE A Z URE A GEN T E DE LO G DEP EN DEN C Y EXT EN SIÓ N
O P ERA C IO N ES M O N ITO R A N A LY T IC S A GEN T DIA GN O ST IC S
Windows Server X X X X
2019
2016
Windows X
Server 2016 Core
2012 R2
2012
Windows Server X X X
2008 R2
Windows 10 X X X
Enterprise
(incluida la sesión
múltiple) y Pro
Windows 8 X X
Enterprise y Pro
Windows 7 SP1 X X
Linux
Amazon Linux X
2017.09
CentOS Linux 7 X X X
CentOS Linux 7.8 X X X X
CentOS Linux 7.6 X X X X
CentOS Linux 6 X X
CentOS Linux 6.5+ X X X
Debian 10 X
Debian 9 X X x X
Debian 8 X X X
Debian 7 X
OpenSUSE 13.1+ X
Oracle Linux 7 X X X
Oracle Linux 6 X X
Oracle Linux 6.4+ X X X
Red Hat Enterprise X X

Linux Server 8
Red Hat Enterprise X X X X

Linux Server 7
Red Hat Enterprise X X X

Linux Server 6
Red Hat Enterprise X X X X

Linux Server 6.7+
SUSE Linux X X
Enterprise Server 15
SUSE Linux X X X X
Enterprise Server 12
Ubuntu 18.04 LTS X X X X
Ubuntu 16.04 LTS X X X X

Ubuntu 14.04 LTS X X X
Compatibilidad del kernel de Linux con Dependency Agent

Dado que Dependency Agent funciona en el nivel de kernel, la compatibilidad también depende de la
versión del kernel. En la tabla siguiente se enumeran la versión principal y secundaria de los sistemas
operativos Linux y las versiones de kernel admitidas para Dependency Agent.
DIST RIB UC IÓ N VERSIÓ N DEL SO VERSIÓ N DEL K ERN EL
Red Hat Linux 7 7.6 3.10.0-957
7.5 3.10.0-862
7.4 3.10.0-693
Red Hat Linux 6 6.10 2.6.32-754
6.9 2.6.32-696
CentOSPlus 6.10 2.6.32-754.3.5

2.6.32-696.30.1
6.9 2.6.32-696.30.1
2.6.32-696.18.7
Ubuntu Server 18,04 5.3.0-1020

5.0 (incluye kernel optimizado para
Azure)
4.18
4.15
16.04.3 4.15.*
16.04 4.13.*
4.11.*
4.10.*
4.8.*
4.4.*
SUSE Linux 12 Enterprise Server 12 SP4 4.12.* (incluye kernel optimizado

para Azure)
12 SP3 4.4.*
12 SP2 4.4.*
Debian 9 4,9
Pasos siguientes
Obtenga más información sobre cada uno de los agentes en los siguientes artículos:
Introducción al agente de Log Analytics
Introducción a la extensión Azure Diagnostics
Recopilación de métricas personalizadas para una máquina virtual Linux con el agente de InfluxData
Telegraf
Azure Monitor.
General
para Azure Monitor.
Monitor.
Registros
en Azure Monitor.
información.
sus tipos.
Métricas
de métricas?
Alertas
tipos de alertas:
Agentes
Analytics.
de datos enviada:
WireData
la red.
Log Analytics?
recurso.
Visualizaciones
Aplicación .NET
virtuales de Azure
SharePoint
Otras plataformas
¿Es gratis?
limitar los gastos.
¿Cuánto cuesta?
ai.js
Web.config
packages.config
Resource Manager?
Más información.
Solicitudes HTTP
Log Analytics
Logstash

Podría:
servidor proxy.

automáticamente)
rendimiento
web

de servidor
producido.
Automation
proxy.
...
<TelemetryModules>
<Add
t>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
</TelemetryChannel>
...
...
NOTE

<system.net>
<defaultProxy>
</defaultProxy>
</system.net>

soluciones:

sencilla.
contenedores.
Kubelet
Opción 1
combinaciones.

ContainerLog
ContainerData
Opción 2
NOTE

clústeres.
Helm?
contenedores.
}));
los registros:
21Vianet.

compatibles.
Insights.
agregado?
subredes?
experiencia.
protocolos.
Pasos siguientes
adicionales.
Log Analytics
Información general del agente de Azure Monitor
El agente de Azure Monitor (AMA) recopila datos de supervisión del sistema operativo invitado de máquinas
virtuales y los entrega a Azure Monitor. En este artículo se proporciona información general sobre el agente de
Azure Monitor, incluido cómo instalarlo y cómo configurar la recopilación de datos.
Relación con otros agentes

El agente de Azure Monitor reemplaza a los siguientes agentes utilizados actualmente por Azure Monitor para
recopilar datos de invitado de máquinas virtuales:
Agente de Log Analytics: Envía datos al área de trabajo de Log Analytics y admite Azure Monitor para VM y
soluciones de supervisión.
Extensión de Diagnostics: Envía datos a Azure Storage, a las métricas de Azure Monitor (solo en Windows), a
Event Hubs y a Azure Storage.
Agente de Telegraf: Envía datos a las métricas de Azure Monitor (solo Linux).
Además de consolidar esta funcionalidad en un solo agente, el agente de Azure Monitor proporciona las
siguientes ventajas frente a los agentes existentes:
Ámbito de supervisión. Configure de forma centralizada la recopilación para diferentes conjuntos de datos de
diferentes conjuntos de VM.
Hospedaje múltiple en Linux: Envíe datos de VM Linux a varias áreas de trabajo.
Filtrado de eventos de Windows: Use consultas de XPATCH para filtrar los eventos de Windows que se
recopilan.
Administración mejorada de las extensiones: El agente de Azure Monitor utiliza un nuevo método de control de
la extensibilidad que es más transparente y controlable que los módulos de administración y los
complementos de Linux en los agentes de Log Analytics actuales.
Cambios en la recopilación de datos
Los métodos para definir la recopilación de datos de los agentes existentes son distintos entre sí, y cada uno de
ellos tiene desafíos que se abordan con el agente de Azure Monitor.
El agente de Log Analytics obtiene su configuración de un área de trabajo de Log Analytics. Esto es fácil de
configurar de forma centralizada, pero es difícil establecer definiciones independientes para diferentes
máquinas virtuales. Solo puede enviar datos a un área de trabajo de Log Analytics.
La extensión de Diagnostics tiene una configuración para cada máquina virtual. Resulta fácil establecer
definiciones independientes para diferentes máquinas virtuales, pero difícil de administrar de forma
centralizada. Solo puede enviar datos a métricas de Azure Monitor, Azure Event Hubs o Azure Storage. En el
caso de los agentes de Linux, se necesita el agente de Telegraf de código abierto para enviar datos a las
El agente de Azure Monitor utiliza las reglas de recopilación de datos (DCR) para configurar los datos que se van a
recopilar de cada agente. Las reglas de recopilación de datos permiten la capacidad de administración de la
configuración de la recopilación a escala y, al mismo tiempo, habilitan configuraciones únicas con ámbito para
subconjuntos de máquinas. Son independientes del área de trabajo e independientes de la máquina virtual, lo que
permite definirlas una vez y reutilizarlas en distintas máquinas y entornos. Consulte Configuración de la
recopilación de datos para el agente de Azure Monitor (versión preliminar).
Limitaciones actuales
Durante la versión preliminar pública del agente de Azure Monitor se aplican las siguientes limitaciones:
El agente de Azure Monitor no admite soluciones y conclusiones, como Azure Monitor para VM y Azure
Security Center. El único escenario que se admite actualmente es la recopilación de datos con las reglas de
recopilación de datos que usted configure.
Las reglas de recopilación de datos se deben crear en la misma región que cualquier área de trabajo de Log
Analytics que se use como destino.
Actualmente solo se admiten máquinas virtuales de Azure. No se admiten actualmente máquinas virtuales
locales, conjuntos de escalado de máquinas virtuales, ARC para servidores, Azure Kubernetes Service ni otros
tipos de recursos de proceso.
La máquina virtual debe tener acceso a los siguientes puntos de conexión HTTPS:
*.ods.opinsights.azure.com
*.ingest.monitor.azure.com
*.control.monitor.azure.com
Coexistencia con otros agentes

El agente de Azure Monitor puede coexistir con los agentes existentes para que pueda seguir usando su
funcionalidad existente durante la evaluación o la migración. Esto es especialmente importante debido a las
limitaciones de la versión preliminar pública para admitir las soluciones existentes. Sin embargo, debe tener
cuidado al recopilar datos duplicados, ya que esto podría sesgar los resultados de las consultas y generar cargos
adicionales por la ingesta y retención de datos.
Por ejemplo, Azure Monitor para VM usa el agente de Log Analytics para enviar datos de rendimiento a un área de
trabajo de Log Analytics. También puede haber configurado el área de trabajo para recopilar eventos de Windows
y eventos de Syslog de los agentes. Si instala el agente de Azure Monitor y crea una regla de recopilación de datos
para estos mismos eventos y datos de rendimiento, se generarán datos duplicados.
Costos
El agente de Azure Monitor no cuesta nada, pero puede incurrir en gastos por los datos ingeridos. Consulte
Precios de Azure Monitor para obtener más información sobre la recopilación y retención de datos de Log
Analytics, y para las métricas de los clientes.
Orígenes y destinos de los datos

En la tabla siguiente se enumeran los tipos de datos que se pueden recopilar actualmente con el agente de Azure
Monitor mediante reglas de recopilación de datos y a dónde se pueden enviar los datos. Consulte ¿Qué supervisa
Azure Monitor? para ver una lista con información detallada, soluciones y otros servicios que usan el agente de
Azure Monitor para recopilar otros tipos de datos.
El agente de Azure Monitor envía datos a métricas de Azure Monitor o a un área de trabajo de Log Analytics que
admite registros de Azure Monitor.
O RIGEN DE DATO S DEST IN AT IO N S DESC RIP C IÓ N
Rendimiento Métricas de Azure Monitor Valores numéricos que miden el

Área de trabajo de Log Analytics rendimiento de diferentes aspectos del
sistema operativo y las cargas de
trabajo.
O RIGEN DE DATO S DEST IN AT IO N S DESC RIP C IÓ N
Registros de eventos de Windows Área de trabajo de Log Analytics Información enviada al sistema de
registro de eventos de Windows.
syslog Área de trabajo de Log Analytics Información enviada al sistema de

registro de eventos de Windows.

Los siguientes sistemas operativos son compatibles actualmente con el agente de Azure Monitor.
Windows
Windows Server 2019
Windows Server 2016
Windows Server 2012
Windows Server 2012 R2
Linux
CentOS 61, 7
Debian 9, 10
Oracle Linux 61, 7
RHEL 61, 7, 8
SLES 11, 12, 15
Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS
IMPORTANT
1 Para que estasdistribuciones envíen datos de Syslog, es necesario reiniciar el servicio rsyslog una vez después de haber
instalado el agente.
Seguridad
El agente de Azure Monitor no requiere ninguna clave, pero en su lugar requiere una identidad administrada
asignada por el sistema. Debe tener una identidad administrada asignada por el sistema habilitada en cada
máquina virtual antes de implementar el agente.
Instalación del agente de Azure Monitor

El agente de Azure Monitor se implementa como extensión de VM de Azure con los detalles de la tabla siguiente.
P RO P IEDA D W IN DO W S L IN UX
Publicador Microsoft.Azure.Monitor Microsoft.Azure.Monitor
Tipo AzureMonitorWindowsAgent AzureMonitorLinuxAgent
TypeHandlerVersion 1.0 1.5
Instale el agente de Azure Monitor con cualquiera de los métodos para instalar los agentes de máquina virtual,
incluidos los siguientes con PowerShell o la CLI. Como alternativa, puede instalar el agente y configurar la
recopilación de datos en máquinas virtuales de su suscripción a Azure desde el portal con el procedimiento
descrito en Configuración de la recopilación de datos para el agente de Azure Monitor (versión preliminar).
Windows
CLI
PowerShell
az vm extension set --name AzureMonitorWindowsAgent --publisher Microsoft.Azure.Monitor --ids {resource ID of

the VM}
Linux
CLI
PowerShell
az vm extension set --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor --ids {resource ID of

the VM}
Pasos siguientes
Cree una regla de recopilación de datos para recopilar datos del agente y enviarlos a Azure Monitor.
Configuración de la recopilación de datos para el
agente de Azure Monitor (versión preliminar)
Las reglas de recopilación de datos (DCR) definen los datos que entran en Azure Monitor y especifican dónde se
deben enviar. En este artículo se describe cómo crear una regla de recopilación de datos para recopilar datos de
máquinas virtuales mediante el agente de Azure Monitor.
Para obtener una descripción completa de las reglas de recopilación de datos, consulte Reglas de recopilación de
datos en Azure Monitor (versión preliminar).
NOTE
En este artículo se describe cómo configurar los datos de las máquinas virtuales con el agente de Azure Monitor que se
encuentra actualmente en versión preliminar. Consulte Información general sobre los agentes de Azure Monitor para
obtener una descripción de los agentes que están disponibles con carácter general y cómo usarlos para recopilar datos.
Asociaciones de reglas de recopilación de datos

Para aplicar una reglas de recopilación de datos a una máquina virtual, cree una asociación para la máquina
virtual. Una máquina virtual puede tener una asociación a varias reglas de recopilación de datos y una de estas
reglas puede tener varias máquinas virtuales asociadas. Esto le permite definir un conjunto de reglas de
recopilación de datos, cada una de las cuales coincide con un requisito determinado y aplicarlas solo a las
máquinas virtuales en las que se aplican.
Por ejemplo, imagine un entorno con un conjunto de máquinas virtuales que ejecutan una aplicación de línea de
negocio y otras que se ejecutan SQL Server. Es posible que tenga una regla de recopilación de datos
predeterminada que se aplique a todas las máquinas virtuales y a reglas de recopilación de datos
independientes que recopilen datos específicamente para la aplicación de línea de negocio y SQL Server. Las
asociaciones de las máquinas virtuales con las reglas de recopilación de datos tendrían un aspecto similar al
siguiente diagrama.
Creación mediante Azure Portal
Puede usar Azure Portal para crear una regla de recopilación de datos y asociar las máquinas virtuales de su
suscripción a esa regla. El agente de Azure Monitor se instalará automáticamente y se creará una identidad
administrada para las máquinas virtuales que no lo tengan instalado.
En el menú Azure Monitor de Azure Portal, seleccione las reglas de recopilación de datos en la sección
Configuración . Haga clic en Agregar para agregar una nueva asignación y regla de recopilación de datos.
Haga clic en Agregar para crear una nueva regla y un conjunto de asociaciones. Dé un nombre de regla y
especifique una suscripción y un grupo de recursos . Esto especifica dónde se creará la regla de recopilación
de datos. Las máquinas virtuales y sus asociaciones pueden estar en cualquier suscripción o grupo de recursos
del inquilino.
En la pestaña Máquinas vir tuales , agregue las máquinas virtuales que deben tener aplicada la regla de
recopilación de datos. El agente de Azure Monitor se instalará en las máquinas virtuales que no lo tengan
instalado.
En la pestaña Collect and deliver (Recopilar y entregar), haga clic en Add data source (Agregar origen de
datos) para agregar un origen de datos y un conjunto de destino. Seleccione un tipo de origen de datos y se
mostrarán los detalles correspondientes. Para los contadores de rendimiento, puede seleccionar entre un
conjunto predefinido de objetos y su frecuencia de muestreo. En el caso de los eventos, puede seleccionar entre
un conjunto de registros o instalaciones y el nivel de gravedad.
Para especificar otros registros y contadores de rendimiento, seleccione Custom (Personalizado). Después,
puede especificar un XPath para los valores específicos que se van a recopilar. Consulte la regla de recopilación
de datos de ejemplo para ver ejemplos.
En la pestaña Destination (Destino), agregue uno o varios destinos para el origen de datos. Los orígenes de
datos de eventos de Windows y Syslog solo pueden enviar a registros de Azure Monitor. Los contadores de
rendimiento pueden enviar a métricas de Azure Monitor y registros de Azure Monitor.
Haga clic en Agregar origen de datos (Agregar origen de datos) y, después, en Revisar y crear para revisar
los detalles de la regla de recopilación de datos y la asociación con el conjunto de máquinas virtuales. Haga clic
en Crear para crearlo.
NOTE
Cuando se hayan creado las asociaciones y la regla de recopilación de datos, los datos pueden tardar hasta cinco minutos
en enviarse a los destinos.
Creación mediante la API REST

Siga los pasos que se indican a continuación para crear una DCR y asociaciones mediante la API REST. 1. Cree
manualmente el archivo DCR con el formato JSON que se muestra en DCR de ejemplo. 2. Cree la regla con la
API REST. 3. Cree una asociación para cada máquina virtual a la regla de recopilación de datos mediante la API
REST.
Pasos siguientes
Más información sobre el agente de Azure Monitor.
Más información sobre las reglas de recopilación de datos.
Introducción al agente de Log Analytics
El agente de Azure Log Analytics recopila la telemetría de las máquinas virtuales Windows y Linux en
cualquier nube, en máquinas locales y en aquellas supervisadas por System Center Operations Manager y
envía los datos recopilados al área de trabajo de Log Analytics en Azure Monitor. El agente de Log Analytics
también permite utilizar información detallada y otros servicios de Azure Monitor, como Azure Monitor
para VM, Azure Security Center y Azure Automation. En este artículo se proporciona una descripción
detallada del agente, de los requisitos del sistema y de la red, y de los métodos de implementación.
NOTE
Debe saber que el agente de Log Analytics también se denomina a veces Microsoft Monitoring Agent (MMA) o
agente de OMS para Linux.
Comparación con Azure Diagnostics Extension

El agente Azure Diagnostics Extension de Azure Monitor también puede utilizarse para recopilar datos de
supervisión del sistema operativo invitado de las máquinas virtuales de Azure. Puede optar por usar uno o
ambos, según sus necesidades. Consulte Introducción a los agentes de Azure Monitor para ver una
comparación detallada entre los agentes de Azure Monitor.
Las principales diferencias que debe tener en cuenta son:
Azure Diagnostics Extension solo se puede usar con máquinas virtuales de Azure. El agente de Log
Analytics se puede usar con máquinas virtuales de Azure, de otras nubes y del entorno local.
Azure Diagnostics Extension envía datos a Azure Storage, a las métricas de Azure Monitor (solo en
Windows) y a Event Hubs. El agente de Log Analytics envía los datos a los registros de Azure Monitor.
El agente de Log Analytics es necesario para las soluciones, Azure Monitor para VM y otros servicios,
como Azure Security Center.
Costos
El agente de Log Analytics no cuesta nada, pero puede generar gastos por los datos ingeridos. Consulte
Administrar el uso y los costos con los registros de Azure Monitor para más información sobre los precios
de los datos recopilados en el área de trabajo de Log Analytics.

Consulte los sistemas operativos admitidos para obtener una lista de las versiones del sistema operativo
Windows y Linux compatibles con el agente de Log Analytics.
Datos recopilados
En la tabla siguiente, se muestran los tipos de datos que puede configurar en un área de trabajo de Log
Analytics para recopilar los datos de todos los agentes conectados. Consulte ¿Qué supervisa Azure
Monitor? para ver una lista con información detallada, soluciones y otros servicios que usan el agente de
Log Analytics para recopilar otros tipos de datos.
O RIGEN DE DATO S DESC RIP C IÓ N
Registros de eventos de Windows Información enviada al sistema de registro de eventos de

Windows.
Syslog Información enviada al sistema de registro de eventos de

Windows.
Rendimiento Valores numéricos que miden el rendimiento de diferentes

aspectos del sistema operativo y las cargas de trabajo.
Registros de IIS Información sobre el uso de los sitios web de IIS que se
ejecutan en el sistema operativo invitado.
Registros personalizados Eventos de archivos de texto en equipos Windows y Linux.
Destinos de datos
El agente de Log Analytics envía datos al área de trabajo de Log Analytics de Azure Monitor. El agente de
Windows puede hospedarse en diferentes sitios para enviar datos a varias áreas de trabajo y grupos de
administración de System Center Operations Manager. El agente de Linux puede enviar datos a un solo
destino, ya sea un área de trabajo o un grupo de administración.
Otros servicios
El agente para Linux y Windows no sirve solo para conectarse a Azure Monitor. Otros servicios, como Azure
Security Center y Azure Sentinel, también usan este agente y su conexión con el área de trabajo de Log
Analytics. El agente también admite Azure Automation para hospedar el rol de trabajo Hybrid Runbook
Worker y otros servicios como Change Tracking, Update Management y Azure Security Center. Para
obtener más información acerca de la función Hybrid Runbook Worker, consulte Hybrid Runbook Worker
de Azure Automation.
Limitaciones del área de trabajo y el grupo de administración

Consulte Configurar el agente para que envíe notificaciones a un grupo de administración de Operations
Manager para obtener más información sobre cómo conectar un agente a un grupo de administración de
Operations Manager.
Los agentes de Windows pueden conectarse con hasta cuatro áreas de trabajo, incluso si estas están
conectadas a un grupo de administración de System Center Operations Manager.
El agente de Linux no admite el hospedaje múltiple y solo puede conectarse con un área de trabajo o
grupo de administración.
Limitaciones de seguridad
El agente de Windows admite el estándar FIPS 140, mientras que el agente de Linux no lo admite.
Opción de instalación
Existen diferentes métodos para instalar el agente de Log Analytics y conectar la máquina a Azure Monitor
en función de los requisitos. En las secciones siguientes se enumeran los posibles métodos para distintos
tipos de máquinas virtuales.
Máquina virtual de Azure
Azure Monitor para VM proporciona varios métodos para habilitar agentes a escala. Esto incluye la
instalación del agente de Log Analytics y Dependency Agent.
Azure Security Center puede aprovisionar el agente de Log Analytics en todas las máquinas virtuales de
Azure admitidas y en las nuevas máquinas virtuales que se creen si se habilita para supervisar las
amenazas y vulnerabilidades de la seguridad.
La extensión de Log Analytics para máquinas virtuales Windows o Linux se puede instalar mediante
Azure Portal, la CLI de Azure, Azure PowerShell o una plantilla de Azure Resource Manager.
Puede instalarla para máquinas virtuales individuales de Azure manualmente desde Azure Portal.
Máquina virtual de Windows en el entorno local o en otra nube
Instale manualmente el agente desde la línea de comandos.
Automatice la instalación con DSC de Automatización de Azure.
Use una plantilla de Resource Manager con Azure Stack
Máquina virtual Linux en el entorno local o en otra nube
Instale manualmente el agente mediante una llamada a un script contenedor hospedado en GitHub.
System Center Operations Manager|Integre Operations Manager con Azure Monitor para reenviar datos
recopilados de equipos Windows que informan a un grupo de administración.
Clave e id. del área de trabajo

Independientemente del método de instalación que haya usado, necesitará la clave y el id. de área de
trabajo para área de trabajo de Log Analytics a la que se conectará el agente. Seleccione el área de trabajo
desde el menú Áreas de trabajo de Log Analytics en Azure Portal. A continuación, seleccione
Administración de agentes en la sección Configuración .
Protocolo TLS 1.2

Para garantizar la seguridad de los datos en tránsito hacia los registros de Azure Monitor, se recomienda
encarecidamente configurar el agente para que use al menos Seguridad de la capa de transporte (TLS) 1.2.
Las versiones anteriores de TLS/Capa de sockets seguros (SSL) han demostrado ser vulnerables y, si bien
todavía funcionan para permitir la compatibilidad con versiones anteriores, no se recomiendan . Para
información adicional, revise Sending data securely using TLS 1.2 (Envío de datos de forma segura
mediante TLS 1.2).
Requisitos de red
El agente para Linux y Windows se comunica con el servicio Azure Monitor a través del puerto TCP 443. Si
la máquina se conecta mediante un servidor proxy o firewall para comunicarse a través de Internet,
consulte los requisitos siguientes para comprender qué configuración de red es necesaria. Si las directivas
de seguridad de TI no permiten que los equipos de la red se conecten a Internet, puede configurar una
puerta de enlace de Log Analytics y, luego, configurar el agente para conectarse a Azure Monitor a través
de la puerta de enlace. Después, el agente puede recibir información de configuración y enviar los datos
recopilados.
En la tabla siguiente se muestra la información de configuración de proxy y firewall necesaria para que los
agentes de Windows y Linux se comuniquen con los registros de Azure Monitor.
Requisitos de firewall
O M IT IR IN SP EC C IÓ N DE
REC URSO DEL A GEN T E P UERTO S DIREC C IÓ N HTTPS
*.ods.opinsights.azure.com Puerto 443 Salida Sí
*.oms.opinsights.azure.co Puerto 443 Salida Sí

m
*.blob.core.windows.net Puerto 443 Salida Sí
*.azure-automation.net Puerto 443 Salida Sí
Para obtener información sobre el firewall necesaria para Azure Government, vea Administración de Azure
Government.
Si tiene previsto usar Hybrid Runbook Worker de Azure Automation para conectarse al servicio
Automation y registrarse en él para usar runbooks o soluciones de administración en el entorno, debe
tener acceso al número de puerto y las direcciones URL descritos en Configuración de la red para Hybrid
Runbook Worker.
Configuración de proxy
El agente de Linux y Windows admite la comunicación a través de un servidor proxy o la puerta de enlace
de Log Analytics con Azure Monitor mediante el protocolo HTTPS. Se admite la autenticación anónima y
básica (nombre de usuario/contraseña). Si el agente de Windows está conectado directamente al servicio, la
configuración de proxy se especifica durante la instalación o después de la implementación desde el Panel
de control o con PowerShell.
Con el agente de Linux, el servidor proxy se especifica durante o después de la instalación mediante la
modificación del archivo de configuración proxy.conf. El valor de configuración del proxy del agente de
Linux tiene la siguiente sintaxis:
[protocol://][user:password@]proxyhost[:port]
Protocolo https
usuario Nombre de usuario opcional para la autenticación de

proxy
password Contraseña opcional para la autenticación de proxy
proxyhost Dirección o nombre de dominio completo (FQDN) del

servidor proxy o la puerta de enlace de Log Analytics
port Número de puerto opcional para el servidor proxy o la

puerta de enlace de Log Analytics
NOTE
Si usa caracteres especiales como "@" en la contraseña, recibirá un error de conexión de proxy porque el valor no se
analiza correctamente. Para solucionar este problema, codifique la contraseña en la dirección URL con una
herramienta como URLDecode.
Pasos siguientes
Revise los orígenes de datos para saber qué orígenes de datos hay disponibles para recopilar datos de
su sistema Windows o Linux.
Obtenga información acerca de las consultas de registros para analizar los datos recopilados de
soluciones y orígenes de datos.
Conozca las soluciones de supervisión que agregan funcionalidad a Azure Monitor y que también
recopilan datos en el área de trabajo de Log Analytics.
Instalación del agente de Log Analytics en
equipos Windows
En este artículo se proporcionan detalles sobre cómo instalar el agente de Log Analytics en equipos
Windows mediante los siguientes métodos:
Instalación manual mediante el asistente para la instalación o la línea de comandos.
Desired State Configuration (DSC) de Azure Automation
IMPORTANT
Los métodos de instalación que se describen en este artículo se usan normalmente para máquinas virtuales locales o
en otras nubes. Consulte Opciones de instalación para ver las opciones más eficaces que puede usar para máquinas
virtuales de Azure.
NOTE
Si tiene que configurar el agente para que informe a varias áreas de trabajo, esto no puede realizarse durante la
instalación inicial, solo después actualizando la configuración del Panel de control o PowerShell, tal como se describe
en Adición o eliminación de un área de trabajo.

Consulte Información general de los agentes de Azure Monitor para obtener una lista de las versiones de
Windows admitidas por el agente de Log Analytics.
Requisito de compatibilidad con la firma de código SHA -2 para Windows
El agente de Windows empezará a usar exclusivamente la firma SHA-2 el 17 de agosto de 2020. Este
cambio afectará a los clientes que usan el agente de Log Analytics en un sistema operativo heredado como
parte de cualquier servicio de Azure (Azure Monitor, Azure Automation, Azure Update Management, Azure
Change Tracking, Azure Security Center, Azure Sentinel, ATP de Windows Defender). El cambio no requiere
ninguna acción del cliente a menos que esté ejecutando el agente en una versión de sistema operativo
heredada (Windows 7, Windows Server 2008 R2 y Windows Server 2008). Los clientes que ejecutan una
versión de sistema operativo heredada deben realizar las siguientes acciones en sus máquinas antes del 17
de agosto de 2020 o los agentes dejarán de enviar datos a las áreas de trabajo de Log Analytics:
1. Instale el Service Pack más reciente para su sistema operativo. Las versiones de Service Pack
necesarias son:
Windows 7 SP1
Windows Server 2008 SP2
Windows Server 2008 R2 SP1
2. Instale las actualizaciones de firma SHA-2 de Windows para su sistema operativo, como se describe
en Requisito de compatibilidad con la firma de código SHA-2 para Windows y WSUS de 2019.
3. Actualice el agente de Windows a la versión más reciente (versión 10.20.18029).
4. Se recomienda para configurar el agente para usar TLS 1.2.
Requisitos de red
Consulte Introducción al agente de Log Analytics para conocer los requisitos de red para el agente de
Windows.
Configuración del agente para usar TLS 1.2

El protocolo TLS 1.2 garantiza la seguridad de los datos en tránsito para la comunicación entre el agente de
Windows y el servicio de Log Analytics. Si va a realizar la instalación en un sistema operativo sin TLS 1.2
habilitado de forma predeterminada, debe configurar TLS 1.2 mediante los pasos siguientes.
1. Busque la siguiente subclave del Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNE
L\Protocols
2. Cree una subclave en Protocolos para TLS 1.2
HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2
3. Cree una subclave Cliente debajo de la subclave de la versión del protocolo TLS 1.2 que ha creado
anteriormente. Por ejemplo,
1.2\Client .
4. Cree los siguientes valores DWORD en
1.2\Client :
Enabled [Value = 1]
DisabledByDefault [Value = 0]
Configure .NET Framework 4.6 o posterior para que sea compatible con la criptografía segura, ya que, de
forma predeterminada, está desactivada. La criptografía fuerte utiliza protocolos de red más seguros como
TLS 1.2, y bloquea los protocolos que no son seguros.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 .
2. Cree el valor DWORD SchUseStrongCr ypto bajo esta subclave con un valor de 1 .
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319 .
4. Cree el valor DWORD SchUseStrongCr ypto bajo esta subclave con un valor de 1 .
5. Reinicie el sistema para que la configuración surta efecto.
Instalación del agente mediante el asistente para instalación

Los siguientes pasos permiten la instalación y configuración del agente de Log Analytics en Azure y en la
nube de Azure Government mediante el asistente para la configuración del agente en su equipo. Si desea
aprender a configurar el agente para que también informe a un grupo de administración de System Center
Operations Manager, consulte Para implementar el agente de Operations Manager con el Asistente para
instalación del agente.
1. En el área de trabajo de Log Analytics, en la página Ser vidores Windows a la que navegó
anteriormente, seleccione la versión Descargar el agente de Windows que desee descargar según la
arquitectura del procesador del sistema operativo Windows.
2. Ejecute el programa de instalación para instalar al agente en el equipo.
3. En la página principal , haga clic en Siguiente .
4. En la página Términos de licencia , lea la licencia y haga clic en Acepto .
5. En la página e Carpeta de destino , cambie o mantenga la carpeta de instalación predeterminada y
haga clic en Siguiente .
6. En la página Opciones de instalación del agente , elija la opción para conectar el agente a Azure Log
Analytics y luego haga clic en Siguiente .
7. En la página Azure Log Analytics , realice lo siguiente:
a. Pegue el Id. del área de trabajo y la clave del área de trabajo (clave principal) que copió
anteriormente. Si el equipo tiene que notificar a un área de trabajo de Log Analytics en Azure
Government Cloud, seleccione Azure US Gov desde la lista desplegable Azure Cloud .
b. Si el equipo necesita comunicarse a través de un servidor proxy con el servicio de Log Analytics,
haga clic en Avanzado y proporcione la dirección URL y el número de puerto del servidor proxy.
Si el servidor proxy requiere autenticación, escriba el nombre de usuario y la contraseña para
autenticar con el servidor proxy y, luego, haga clic en Siguiente .
8. Haga clic en Siguiente cuando haya terminado de proporcionar las opciones de configuración
necesarias.
9. En la página Preparado para instalar , revise las opciones seleccionadas y haga clic en Instalar .
10. En la página La configuración finalizó correctamente , haga clic en Finalizar .
Una vez completado el proceso, el Agente de administración de Microsoft aparece en el Panel de
control . Para confirmar que está informando a Log Analytics, revise Comprobar la conectividad del agente
con Log Analytics.
Instalación del agente mediante la línea de comandos

El archivo descargado del agente es un paquete de instalación independiente. El programa de instalación del
agente y los archivos auxiliares se encuentran en el paquete y deben extraerse para realizar la instalación
correctamente mediante la línea de comandos que se muestra en los ejemplos siguientes.
NOTE
Si desea actualizar a un agente, debe utilizar la API de scripting de Log Analytics. Si quiere obtener más información,
consulte Administrar y mantener el agente de Log Analytics para Windows y Linux.
En la tabla siguiente se resaltan los parámetros específicos que admite la configuración del agente, aunque
la implementación se haya realizado mediante DSC de Automatización.
O P C IO N ES ESP EC ÍF IC A S DE M M A N OTA S
NOAPM=1 Parámetro opcional. Instala al agente sin la supervisión de

rendimiento de aplicaciones .NET.
ADD_OPINSIGHTS_WORKSPACE 1 = Configurar el agente para informar a un área de

trabajo
OPINSIGHTS_WORKSPACE_ID Identificador de área de trabajo (guid) para el área de

trabajo que se agregará
OPINSIGHTS_WORKSPACE_KEY Clave del área de trabajo que se usa para autenticar

inicialmente con el área de trabajo
OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE Especificar el entorno en la nube donde se encuentra el

área de trabajo
0 = nube comercial de Azure (valor predeterminado)
1= Azure Government
OPINSIGHTS_PROXY_URL Identificador URI del proxy que se va a usar
OPINSIGHTS_PROXY_USERNAME Nombre de usuario para acceder a un proxy autenticado
OPINSIGHTS_PROXY_PASSWORD Contraseña para acceder a un proxy autenticado
1. Para extraer los archivos de instalación del agente, desde un símbolo del sistema con privilegios
elevados ejecute MMASetup-<platform>.exe /c y se le solicitará la ruta en la que extraer los archivos.
Como alternativa, puede especificar la ruta de acceso pasando los argumentos
MMASetup-<platform>.exe /c /t:<Full Path> .
2. Para instalar el agente de forma silenciosa y configurarlo para que informe a un área de trabajo en la
nube comercial de Azure, vaya a la carpeta en la que extrajo los archivos de instalación y escriba:
setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0

OPINSIGHTS_WORKSPACE_ID="<your workspace ID>" OPINSIGHTS_WORKSPACE_KEY="<your workspace key>"
AcceptEndUserLicenseAgreement=1
o bien, para configurar el agente para que informe a la nube de la administración pública de EE. UU.,
escriba:
setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=1

OPINSIGHTS_WORKSPACE_ID="<your workspace ID>" OPINSIGHTS_WORKSPACE_KEY="<your workspace key>"
AcceptEndUserLicenseAgreement=1
NOTE
Los valores de cadena para los parámetros OPINSIGHTS_WORKSPACE_ID y OPINSIGHTS_WORKSPACE_KEY
se deben encapsular en comillas dobles para indicar a Windows Installer que los interprete como opciones
válidas para el paquete.
Instalación del agente mediante DSC en Azure Automation

Puede usar el siguiente script de ejemplo para instalar el agente mediante DSC de Azure Automation. Si no
tiene una cuenta de Automation, consulte Introducción a Azure Automation para comprobar los requisitos y
los pasos necesarios para crear una cuenta de Automation antes de poder usar DSC de Automatización. Si
no está familiarizado con DSC de Automatización, consulte Introducción a DSC de Automatización.
En el ejemplo siguiente se instala el agente de 64 bits, identificado mediante el valor URI . También puede
utilizar la versión de 32 bits si se reemplaza el valor del identificador URI. Estos son los identificadores URI
para ambas versiones:
Agente de Windows de 64 bits: https://go.microsoft.com/fwlink/?LinkId=828603
Agente de Windows de 32 bits: https://go.microsoft.com/fwlink/?LinkId=828604
NOTE
Este procedimiento y el script de ejemplo no admiten la actualización del agente que ya está implementado en un
equipo Windows.
Las versiones de 32 y 64 bits del paquete de agente tienen códigos de producto diferentes y las nuevas
versiones publicadas también tienen un valor único. El código de producto es un GUID, que es la
identificación principal de una aplicación o un producto, y se representa mediante la propiedad
ProductCode de Windows Installer. El valor ProductId del script MMAgent.ps1 tiene que coincidir con el
código de producto del paquete del instalador del agente de 32 o 64 bits.
Para recuperar el código de producto del paquete para instalar el agente directamente, puede usar Orca.exe
desde la página Windows SDK Components for Windows Installer Developers (Componentes del SDK de
Windows para desarrolladores de Windows Installer), donde encontrará un componente del Kit de
desarrollo de software de Windows, o mediante PowerShell y un script de ejemplo que haya escrito un MVP
(profesional más valioso) de Microsoft. Para cualquier enfoque, primero debe extraer el archivo
MOMagent.msi del paquete de instalación MMASetup. Esto se explicó anteriormente en el primero paso de
la sección Instalación del agente a través de la línea de comandos.
1. Importe el módulo DSC xPSDesiredStateConfiguration de
https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration en Azure Automation.
2. En Azure Automation, cree los recursos de variable OPSINSIGHTS_WS_ID y OPSINSIGHTS_WS_KEY.
Establezca OPSINSIGHTS_WS_ID en el identificador del área de trabajo de Log Analytics y
OPSINSIGHTS_WS_KEY en la clave principal del área de trabajo.
3. Copie el script y guárdelo como MMAgent.ps1.
Configuration MMAgent
{
$OIPackageLocalPath = "C:\Deploy\MMASetup-AMD64.exe"
$OPSINSIGHTS_WS_ID = Get-AutomationVariable -Name "OPSINSIGHTS_WS_ID"
$OPSINSIGHTS_WS_KEY = Get-AutomationVariable -Name "OPSINSIGHTS_WS_KEY"
Import-DscResource -ModuleName xPSDesiredStateConfiguration

Import-DscResource -ModuleName PSDesiredStateConfiguration
Node OMSnode {
Service OIService
{
Name = "HealthService"
State = "Running"
DependsOn = "[Package]OI"
}
xRemoteFile OIPackage {
Uri = "https://go.microsoft.com/fwlink/?LinkId=828603"
DestinationPath = $OIPackageLocalPath
}
Package OI {
Ensure = "Present"
Path = $OIPackageLocalPath
Name = "Microsoft Monitoring Agent"
ProductId = "8A7F2C51-4C7D-4BFD-9014-91D11F24AAE2"
Arguments = '/C:"setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID='
+ $OPSINSIGHTS_WS_ID + ' OPINSIGHTS_WORKSPACE_KEY=' + $OPSINSIGHTS_WS_KEY + '
AcceptEndUserLicenseAgreement=1"'
DependsOn = "[xRemoteFile]OIPackage"
}
}
}
4. Actualice el valor ProductId en el script con el código de producto extraído de la versión más reciente
del paquete de instalación del agente mediante los métodos recomendados anteriormente.
5. Importe el script de configuración MMAgent.ps1 en su cuenta de Automation.
6. Asigne un equipo Windows o un nodo a la configuración. Durante los 15 minutos siguientes, el nodo
comprueba la configuración y el agente se inserta en el nodo.
Comprobación de la conectividad del agente a Azure Monitor

Una vez completada la instalación del agente, compruebe que se ha conectado correctamente y que la
creación de informes puede realizarse desde ambos lados.
En el Panel de control del equipo, busque el elemento Microsoft Monitoring Agent . Selecciónelo y, en la
pestaña Azure Log Analytics , el agente debe mostrar un mensaje que indica: The Microsoft Monitoring
Agent has successfully connected to the Microsoft Operations Management Suite ser vice
(Microsoft Monitoring Agent se ha conectado correctamente al servicio Microsoft Operations Management
Suite).
También puede realizar una consulta de registros sencilla en Azure Portal.
1. En Azure Portal, busque y seleccione Monitor .
2. Seleccione Registros en el menú.
3. En el panel deRegistros , en el campo tipo de consulta:
Heartbeat
| where Category == "Direct Agent"
En los resultados de la búsqueda devueltos, verá los registros de latido del equipo que indican que está
conectado y que está creando informes para el servicio.
Información de caché
Los datos del agente de Log Analytics se almacenan en la memoria caché del equipo local en C:\Program
Files\Microsoft Monitoring Agent\Agent\Health Service State antes de enviarse a Azure Monitor. El agente
intenta realizar la carga cada 20 segundos. En caso de que se produzca un error, esperará una cantidad de
tiempo que aumenta exponencialmente hasta que se ejecute correctamente. Esperará 30 segundos antes del
segundo intento, 60 segundos antes del siguiente, 120 segundos y así sucesivamente hasta un máximo de
8,5 horas entre los reintentos hasta que se vuelva a conectar correctamente. Este tiempo de espera es
ligeramente aleatorio para evitar que todos los agentes intenten conectarse simultáneamente. Los datos
más antiguos se descartan cuando se alcanza el búfer máximo.
El tamaño de caché predeterminado es 50 MB, pero se puede configurar entre un mínimo de 5 MB y un
máximo de 1,5 GB. Se almacena en la clave del Registro
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Persistence Cache
Maximum. El valor representa el número de páginas, con 8 KB por página.
Pasos siguientes
Revise Administrar y mantener el agente de Log Analytics para Windows y Linux para obtener
información sobre cómo volver a configurar, actualizar o quitar el agente de la máquina virtual.
Consulte Solución de problemas del agente de Windows si encuentra incidencias durante la
instalación o la administración del agente.
Instalación del agente de Log Analytics en equipos
Linux
En este artículo, se proporcionan detalles sobre la instalación del agente de Log Analytics en equipos Linux con los
métodos siguientes:
Instale al agente para Linux con un script contenedor hospedado en GitHub. Este es el método recomendado
para instalar y actualizar el agente cuando el equipo tiene conectividad a Internet directamente o a través de un
servidor proxy.
Descargue e instale manualmente el agente. Esto es necesario cuando el equipo Linux no tiene acceso a
Internet y se va a comunicar con Azure Monitor o Azure Automation utilizando la puerta de enlace de Log
Analytics.
IMPORTANT
Los métodos de instalación descritos en este artículo se usan normalmente con máquinas virtuales locales o en otras nubes.
Consulte Opciones de instalación para ver las opciones más eficaces que se pueden utilizar con Azure Virtual Machines.

Consulte Información general de los agentes de Azure Monitor para obtener una lista de las distribuciones de
Linux admitidas por el agente de Log Analytics.
NOTE
OpenSSL 1.1.0 solo se admite en las plataformas x86_x64 (64 bits) y OpenSSL anterior a 1.x no se admite en ninguna
plataforma.
A partir de las versiones publicadas después de agosto de 2018, hemos realizado los siguientes cambios en
nuestro modelo de soporte técnico:
Solo se admiten las versiones de servidor, no de cliente.
La compatibilidad se centra en cualquiera de las distribuciones de Linux aprobadas en Azure. Tenga en cuenta
que puede haber cierto retraso entre la aprobación de una distribución o versión de Linux en Azure y su
compatibilidad con el agente de Linux de Log Analytics.
Se admiten todas las versiones secundarias de cada versión principal de la lista.
No se admiten las versiones que han superado la fecha de finalización de soporte técnico de su fabricante.
No se admiten las nuevas versiones de AMI.
Solo se admiten las versiones que ejecutan SSL 1.x de forma predeterminada.
NOTE
Si utiliza una distribución o versión que no se admite actualmente y no se alinea con nuestro modelo de soporte técnico, se
recomienda bifurcar este repositorio, confirmar que el soporte técnico de Microsoft no prestará asistencia con versiones de
agente con bifurcación.
Requisito de Python 2
El agente de Log Analytics requiere Python 2. Si la máquina virtual usa un distribución que no incluye Python 2 de
forma predeterminada, debe instalarlo. Los siguientes comandos de ejemplo instalarán Python 2 en diferentes
distribuciones.
Red Hat, CentOS, Oracle: yum install -y python2
Ubuntu, Debian: apt-get install -y python2
SUSE: zypper install -y python2
El ejecutable python2 debe tener un alias para python. A continuación se ofrece un método que puede usar para
establecer este alias:
1. Ejecute el siguiente comando para quitar los alias existentes.
sudo update-alternatives --remove-all python
2. Para crear el alias, ejecute el siguiente comando.
sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 1
Protección de Linux admitida

El agente de OMS tiene compatibilidad de personalización limitada para Linux.
Actualmente se admiten los siguientes:
FIPs
Los siguientes están planeados, pero no se admiten actualmente:
CIS
SELINUX
Otros métodos de protección y personalización no se admiten ni están planeados para el agente de OMS.
Requisitos del agente

En la tabla siguiente se indican los paquetes necesarios para las distribuciones de Linux compatibles en las que se
instalará el agente.
PA Q UET E N EC ESA RIO DESC RIP C IÓ N VERSIÓ N M ÍN IM A
Glibc Biblioteca GNU C 2.5-12
Openssl Bibliotecas OpenSSL 1.0.x o 1.1.x
Curl Cliente web de cURL 7.15.5
Python 2.6+ o 3.3+
Python ctypes
PAM Módulos de autenticación conectables

NOTE
Rsyslog o Syslog son necesarios para recopilar mensajes de Syslog. El demonio predeterminado de Syslog en la versión 5 de
Red Hat Enterprise Linux, CentOS y Oracle Linux (Sysklog) no se admite para la recopilación de eventos de Syslog. Para
recopilar datos de Syslog de esta versión de estas distribuciones, es necesario instalar configurar el demonio de Rsyslog para
reemplazar Sysklog.
Requisitos de red
Consulte Introducción al agente de Log Analytics para conocer los requisitos de red para el agente de Linux.
Paquete de instalación del agente

El agente de Log Analytics para Linux se compone de varios paquetes. El archivo de lanzamiento contiene los
siguientes paquetes, que estarán disponibles si el conjunto de paquetes de shell se ejecuta con el parámetro
--extract :
PA C K A GE VERSIÓ N DESC RIP C IÓ N
omsagent 1.12.15 Agente de Log Analytics para Linux
omsconfig 1.1.1 Agente para configurar el agente de

Log Analytics
omi 1.6.3 Infraestructura de administración

abierta (OMI), servidor de CIM ligero
Tenga en cuenta que OMI debe tener
acceso raíz para poder ejecutar los
trabajos de Cron que son necesarios
para que el servicio funcione.
scx 1.6.3 Proveedores de CIM OMI para métricas

de rendimiento del sistema operativo
apache-cimprov 1.0.1 Proveedor de supervisión de

rendimiento de servidor HTTP de
Apache para OMI. Solo se instala si se
detecta un servidor HTTP de Apache.
mysql-cimprov 1.0.1 Proveedor de supervisión de

rendimiento de servidor MySQL Server
para OMI. Solo se instala si se detecta
un servidor MySQL/MariaDB de
Apache.
docker-cimprov 1.0.0 Proveedor de Docker para OMI. Solo se

instala si se detecta Docker.
Detalles de instalación del agente

Una vez instalado el agente de Log Analytics para paquetes Linux, se aplicarán los siguientes cambios de
configuración adicionales en todo el sistema. Estos artefactos se quitan cuando se desinstala el paquete omsagent.
Se crea un usuario sin privilegios llamado: omsagent . El demonio se ejecuta con esta credencial.
Se crea un archivo include de sudoers en /etc/sudoers.d/omsagent . Este archivo permite a omsagent reiniciar
los demonios syslog y omsagent. Si la versión de sudo instalada no es compatible con las directivas include de
sudo, estas entradas se escribirán en /etc/sudoers .
Se modifica la configuración de Syslog para reenviar un subconjunto de eventos al agente. Para más
información, consulte este artículo sobre la configuración de colecciones de datos de Syslog.
En los equipos supervisados con Linux, el agente aparece como omsagent . omsconfig es el agente de
configuración del agente de Log Analytics para Linux que busca la nueva configuración del portal cada cinco
minutos. Esta nueva configuración actualizada se aplica a los archivos de configuración del agente que se
encuentran en /etc/opt/microsoft/omsagent/conf/omsagent.conf .
Instalación del agente con un script contenedor

Los pasos siguientes permiten configurar el agente de Log Analytics en Azure y la nube de Azure Government
utilizando el script contenedor en aquellos equipos Linux que puedan conectarse directamente o a través de un
servidor proxy para descargar el agente hospedado en GitHub e instalar el agente.
Si el equipo Linux necesita un servidor proxy para comunicarse con Log Analytics, esta configuración puede
especificarse en la línea de comandos incluyendo -p [protocol://][user:password@]proxyhost[:port] . La
propiedad protocol acepta http o https , y la propiedad proxyhost acepta el nombre de dominio completo o la
dirección IP del servidor proxy.
Por ejemplo: https://proxy01.contoso.com:30443
Si se requiere autenticación en alguno de los dos casos, deberá especificar el nombre de usuario y la contraseña.
1. Si desea configurar el equipo Linux para que se conecte a un área de trabajo de Log Analytics, ejecute el
comando siguiente con el identificador del área de trabajo y la clave principal. El siguiente comando
descarga el agente, valida su suma de comprobación y lo instala.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s <YOUR
WORKSPACE PRIMARY KEY>

Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]<proxy user>:
<proxy password>@<proxyhost>[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY>
2. Para configurar el equipo Linux de modo que se conecte con un área de trabajo de Log Analytics en la nube
de Azure Government, ejecute el comando siguiente con el identificador del área de trabajo y la clave
principal que ha copiado anteriormente. El siguiente comando descarga el agente, valida su suma de
comprobación y lo instala.
Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -w <YOUR WORKSPACE ID> -s <YOUR
WORKSPACE PRIMARY KEY> -d opinsights.azure.us

Linux/master/installer/scripts/onboard_agent.sh && sh onboard_agent.sh -p [protocol://]<proxy user>:
<proxy password>@<proxyhost>[:port] -w <YOUR WORKSPACE ID> -s <YOUR WORKSPACE PRIMARY KEY> -d
opinsights.azure.us
Instalación manual del agente

El agente de Log Analytics para Linux viene en un conjunto de scripts de shell autoextraíbles e instalables. Este
paquete contiene los paquetes Debian y RPM para cada uno de los componentes del agente y se pueden instalar
directamente o extraerse para recuperar los paquetes individuales. Hay dos paquetes, uno para arquitecturas x64
y otro para arquitecturas x86.
NOTE
En el caso de las máquinas virtuales de Azure, le recomendamos que instale el agente utilizando la extensión de máquina
virtual de Log Analytics para Linux.
1. Descargue y transfiera el conjunto adecuado (x64 o x86) a la máquina virtual o al equipo físico Linux
mediante scp o sftp.
2. Instale el paquete utilizando el argumento --install . Para incluir un área de trabajo de Log Analytics
durante la instalación, proporcione los parámetros -w <WorkspaceID> y -s <workspaceKey> que copió
anteriormente.
NOTE
Si los paquetes dependientes (por ejemplo, omi, scx, omsconfig o sus versiones anteriores) están instalados, como
ocurriría en el caso de que el agente de System Center Operations Manager para Linux estuviera instalado, es
necesario utilizar el argumento --upgrade .
sudo sh ./omsagent-*.universal.x64.sh --install -w <workspace id> -s <shared key>
3. Si desea configurar el agente de Linux para instalar un área de trabajo de Log Analytics y conectarse a ella
utilizando una puerta de enlace de Log Analytics, ejecute el siguiente comando con el proxy, el identificador
del área de trabajo y los parámetros de clave del área de trabajo. Esta configuración se puede especificar en
la línea de comandos incluyendo -p [protocol://][user:password@]proxyhost[:port] . La propiedad
proxyhost acepta un nombre de dominio completo o una dirección IP del servidor de puerta de enlace de
Log Analytics.
sudo sh ./omsagent-*.universal.x64.sh --upgrade -p https://<proxy address>:<proxy port> -w <workspace

id> -s <shared key>
Si se requiere autenticación, deberá especificar el nombre de usuario y la contraseña. Por ejemplo:
sudo sh ./omsagent-*.universal.x64.sh --upgrade -p https://<proxy user>:<proxy password>@<proxy

address>:<proxy port> -w <workspace id> -s <shared key>
4. Si desea configurar el equipo Linux para que se conecte a un área de trabajo de Log Analytics situada en la
nube de Azure Government, ejecute el comando siguiente con el identificador del área de trabajo y la clave
principal que copió anteriormente.
sudo sh ./omsagent-*.universal.x64.sh --upgrade -w <workspace id> -s <shared key> -d

opinsights.azure.us
Si desea instalar los paquetes del agente y configurarlos para que posteriormente envíen información a un área
de trabajo de Log Analytics, ejecute el siguiente comando:
sudo sh ./omsagent-*.universal.x64.sh --upgrade
Para extraer los paquetes de agente del conjunto de paquetes sin instalarlos, ejecute el siguiente comando:
sudo sh ./omsagent-*.universal.x64.sh --extract
Actualización desde una versión anterior

A partir de la versión 1.0.0-47, todos los lanzamientos permiten actualizar desde la versión anterior. Realice la
instalación con el parámetro --upgrade para actualizar todos los componentes del agente a la última versión.
Información de caché
Los datos del agente de Log Analytics para Linux se almacenan en la caché del equipo local en %
STATE_DIR_WS%/out_oms_common. buffer * antes de enviarse a Azure Monitor. Los datos de registro
personalizados se almacenan en búfer en %STATE_DIR_WS%/out_oms_blob.buffer*. La ruta de acceso puede ser
diferente para algunas soluciones y tipos de datos.
El agente intenta realizar la carga cada 20 segundos. Si no lo consigue, el tiempo de espera aumentará de forma
exponencial hasta que la operación se ejecute correctamente. Esperará 30 segundos antes del segundo intento;
60 segundos antes del siguiente; 120 segundos a continuación y así sucesivamente hasta un máximo de
9 minutos entre reintentos hasta que se vuelva a conectar correctamente. El agente solo volverá a intentar la
operación 10 veces para un fragmento determinado de datos antes de descartarlo y pasar al siguiente. Esto
continuará hasta que el agente pueda volver a efectuar la carga correctamente. Por esta razón, los datos se
pueden almacenar en búfer hasta 8,5 horas antes de ser descartados.
El tamaño predeterminado de la caché es 10 MB, pero se puede modificar en el archivo omsagent.conf.
Pasos siguientes
Revise Administrar y mantener el agente de Log Analytics para Windows y Linux para obtener información
sobre cómo volver a configurar, actualizar o quitar el agente de la máquina virtual.
Consulte Troubleshooting the Linux agent (Solución de problemas del agente Linux) si encuentra
problemas durante la instalación del agente o al administrarlo.
Extensión de máquina virtual de Log Analytics para
Windows
Los registros de Azure Monitor proporcionan funcionalidades de supervisión de recursos locales y en la nube.
Microsoft, como editor de la extensión de máquina virtual del agente de Log Analytics para Windows, es quien
presta los servicios de soporte técnico para esta solución. La extensión instala el agente de Log Analytics en
Azure Virtual Machines e inscribe las máquinas virtuales en un área de trabajo de Log Analytics. En este
documento se especifican las plataformas compatibles, configuraciones y opciones de implementación de la
extensión de máquina virtual de Log Analytics para Windows.
Requisitos previos
Sistema operativo
Para obtener más información acerca de los sistemas operativos Windows admitidos, consulte el artículo
Información general sobre los agentes de Azure Monitor.
Versión de extensión de agente y máquina virtual
En la tabla siguiente se proporciona una asignación de la versión de la extensión de VM de Windows Log
Analytics y el paquete del agente de Log Analytics para cada versión.
VERSIÓ N DEL C O N JUN TO VERSIÓ N DE EXT EN SIÓ N DE

DE P RO DUC TO S W IN DO W S VM W IN DO W S DE LO G
PA RA LO G A N A LY T IC S A N A LY T IC S F EC H A DE L A VERSIÓ N N OTA S DE L A VERSIÓ N
10.20.18038 1.0.18040.2 Agosto de 2020 Resuelve un

problema en Azure
Arc
10.20.18038 1.0.18038 Abril de 2020 Permite la

conectividad a través
de Private Link
mediante ámbitos
de Private Link de
Azure Monitor.
Agrega la limitación
de ingesta para
evitar un influjo
repentino y
accidental de ingesta
en un área de
trabajo.
Agrega
compatibilidad con
regiones y nubes de
Azure Government
adicionales.
Resuelve un error en
el que se bloqueaba
HealthService.exe.
10.20.18029 1.0.18029 Marzo de 2020 Agrega

compatibilidad con
la firma de código
SHA-2.
Mejora la instalación
y administración de
extensiones de
máquina virtual.
Resuelve un error en
Azure Arc de
integración de
servidores.
Agrega una
herramienta de
solución de
problemas integrada
de soporte al cliente.
Agrega
compatibilidad con
más regiones de
Azure Government.
10.20.18018 1.0.18018 Octubre de 2019 Correcciones de

errores menores y
mejoras de
estabilización
10.20.18011 1.0.18011 Julio de 2019 Correcciones de

errores menores y
mejoras de
estabilización
Aumento de
MaxExpressionDepth
a 10 000
10.20.18001 1.0.18001 Junio de 2019 Correcciones de

errores menores y
mejoras de
estabilización
Se agregó la
posibilidad de
deshabilitar las
credenciales
predeterminadas al
realizar la conexión
de proxy
(compatibilidad con
WINHTTP_AUTOLOG
ON_SECURITY_LEVE
L_HIGH).
10.19.13515 1.0.13515 Marzo de 2019 Correcciones

menores de
estabilización
10.19.10006 N/D Diciembre de 2018 Correcciones

menores de
estabilización
8.0.11136 N/D Septiembre de 2018 Se agregó

compatibilidad con
la detección de
cambios en los
identificadores de
recursos al migrar
las máquinas
virtuales.
Se agregó
compatibilidad con
la notificación de
identificadores de
recursos cuando se
usa una instalación
sin extensiones.
8.0.11103 N/D Abril de 2018
8.0.11081 1.0.11081 Noviembre de 2017
8.0.11072 1.0.11072 Septiembre de 2017
8.0.11049 1.0.11049 Febrero de 2017

Azure Security Center aprovisiona automáticamente el agente de Log Analytics y lo conecta con el área de
trabajo predeterminada de Log Analytics de la suscripción de Azure. Si utiliza Azure Security Center, no siga los
pasos de este documento. Si lo hace, sobrescribirá el área de trabajo configurada e interrumpirá la conexión con
Conectividad de Internet
La extensión del agente de Log Analytics para Windows requiere que la máquina virtual de destino esté
conectada a Internet.
Esquema de extensión
En el siguiente JSON se muestra el esquema para la extensión del agente de Log Analytics. La extensión requiere
el identificador y la clave del área de trabajo de destino de Log Analytics. Se pueden encontrar en la
configuración del área de trabajo en Azure Portal. Como la clave del área de trabajo debe tratarse como datos
confidenciales, debe almacenarse en una configuración protegida. Los datos de configuración protegida de la
extensión de VM de Azure están cifrados y solo se descifran en la máquina virtual de destino. Tenga en cuenta
que workspaceId y workspaceKey distinguen mayúsculas de minúsculas.
{
"name": "OMSExtension",
"apiVersion": "[variables('apiVersion')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"settings": {
"workspaceId": "myWorkSpaceId"
},
"workspaceKey": "myWorkspaceKey"
}
}
}
Valores de propiedad
N O M B RE VA LO R / E JEM P LO
apiVersion 2015-06-15
publisher Microsoft.EnterpriseCloud.Monitoring
type MicrosoftMonitoringAgent
typeHandlerVersion 1.0
workspaceId (e.g)* 6f680a37-00c6-41c7-a93f-1437e3462574
workspaceKey (p. ej.) z4bU3p1/GrnWpQkky4gdabWXAhbWSTz70hm4m2Xt92XI+r

SRgE8qVvRhsGo9TXffbrTahyrwv35W0pOqQAU7uQ==
* El identificador del área de trabajo se denomina identificador de consumidor en la API de Log Analytics.
NOTE
Para obtener más propiedades, vea Conexión de equipos Windows a Azure Monitor de Azure.
Implementación de plantilla
Las extensiones de VM de Azure pueden implementarse con plantillas de Azure Resource Manager. El esquema
JSON detallado en la sección anterior se puede usar en una plantilla de Azure Resource Manager para ejecutar el
agente de Log Analytics durante la implementación de una plantilla de Azure Resource Manager. En la Galería de
inicio rápido de Azure encontrará una plantilla de ejemplo que incluye la extensión de VM del agente de Log
Analytics.
NOTE
La plantilla no admite la especificación de más de un identificador y clave de área de trabajo cuando quiere configurar el
agente para informar a varias áreas de trabajo. Para configurar el agente para que informe a varias áreas de trabajo,
consulte Adición o eliminación de un área de trabajo.
El JSON de una extensión de máquina virtual puede estar anidada en el recurso de máquina virtual, o colocada
en la raíz o un nivel superior de una plantilla JSON de Resource Manager. La colocación de la plantilla JSON
afecta al valor del nombre y tipo del recurso. Para obtener más información, consulte el artículo sobre cómo
establecer el nombre y el tipo de recursos secundarios.
En el siguiente ejemplo se da por supuesto que la extensión de Log Analytics está anidada dentro de los recursos
de máquina virtual. Cuando se anidan los recursos de extensión, la plantilla JSON se coloca en el objeto
"resources": [] de la máquina virtual.
{
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
Al colocar la plantilla JSON de la extensión en la raíz de la plantilla, el nombre de recurso incluye una referencia a
la máquina virtual principal, y el tipo refleja la configuración anidada.
{
"name": "<parentVmResource>/OMSExtension",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
Implementación de PowerShell
El comando Set-AzVMExtension puede utilizarse para implementar la extensión de máquina virtual del agente de
Log Analytics en una máquina virtual existente. Antes de ejecutar el comando, las configuraciones públicas y
privadas deben estar almacenadas en una tabla hash de PowerShell.
$PublicSettings = @{"workspaceId" = "myWorkspaceId"}

$ProtectedSettings = @{"workspaceKey" = "myWorkspaceKey"}
Set-AzVMExtension -ExtensionName "MicrosoftMonitoringAgent" `

-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Publisher "Microsoft.EnterpriseCloud.Monitoring" `
-ExtensionType "MicrosoftMonitoringAgent" `
-TypeHandlerVersion 1.0 `
-Settings $PublicSettings `
-ProtectedSettings $ProtectedSettings `
-Location WestUS
Solución de problemas y asistencia

Los datos sobre el estado de las implementaciones de extensiones pueden recuperarse desde Azure Portal y
mediante el módulo Azure PowerShell. Para ver el estado de implementación de las extensiones de una VM
determinada, ejecute el comando siguiente con el módulo de Azure PowerShell.
Get-AzVMExtension -ResourceGroupName myResourceGroup -VMName myVM -Name myExtensionName
El resultado de la ejecución de las extensiones se registra en los archivos que se encuentran en el siguiente
directorio:
C:\WindowsAzure\Logs\Plugins\Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent\
Soporte técnico
Si necesita más ayuda con cualquier aspecto de este artículo, puede ponerse en contacto con los expertos de
Azure en los foros de MSDN Azure o Stack Overflow. Como alternativa, puede registrar un incidente de soporte
técnico de Azure. Vaya al sitio de soporte técnico de Azure y seleccione Obtener soporte. Para obtener
información sobre el uso del soporte técnico, lea las Preguntas más frecuentes de soporte técnico de Microsoft
Azure.
Extensión de máquina virtual de Log Analytics para
Linux
Los registros de Azure Monitor proporcionan funcionalidades de supervisión, generación de alertas y corrección
de alertas a los recursos locales y en la nube. Microsoft, como editor de la extensión de máquina virtual de Log
Analytics para Linux, es quien presta los servicios de soporte técnico para esta solución. La extensión instala el
agente de Log Analytics en Azure Virtual Machines e inscribe las máquinas virtuales en un área de trabajo de
Log Analytics. En este documento se especifican las plataformas compatibles, configuraciones y opciones de
implementación de la extensión de máquina virtual de Log Analytics para Linux.
NOTE
referencia al agente de OMS para Windows o Linux como el agente de Log Analytics para Windows y el agente de Log
Analytics para Linux.
NOTE
Los datos de registro siguen almacenándose en un área de trabajo de Log Analytics y siguen recopilándose y
analizándose por el mismo servicio de Log Analytics. Estamos actualizando la terminología para reflejar mejor el rol de los
registros de Azure Monitor. Consulte Azure Monitor terminology changes (Cambios en la terminología de Azure Monitor)
para obtener más información.
Requisitos previos
Sistema operativo
Para más información sobre las distribuciones de Linux admitidas, consulte el artículo Información general
sobre los agentes de Azure Monitor.
Versión de extensión de agente y máquina virtual
En la tabla siguiente se proporciona una asignación de la versión de la extensión de VM de Log Analytics y el
paquete del agente de Log Analytics para cada versión. Se incluye un vínculo a las notas de la versión del
paquete del agente de Log Analytics. Las notas de versión incluyen detalles sobre corrección de errores y nuevas
características que están disponibles para una versión de agente determinada.
VERSIÓ N DE EXT EN SIÓ N DE M Á Q UIN A VIRT UA L L IN UX DE

LO G A N A LY T IC S VERSIÓ N DEL PA Q UET E DEL A GEN T E DE LO G A N A LY T IC S
1.13.13 1.13.7-0
1.12.25 1.12.15-0
1.11.15 1.11.0-9
VERSIÓ N DE EXT EN SIÓ N DE M Á Q UIN A VIRT UA L L IN UX DE
LO G A N A LY T IC S VERSIÓ N DEL PA Q UET E DEL A GEN T E DE LO G A N A LY T IC S
1.10.0 1.10.0-1
1.9.1 1.9.0-0
1.8.11 1.8.1-256
1.8.0 1.8.0-256
1.7.9 1.6.1-3
1.6.42.0 1.6.0-42
1.4.60.2 1.4.4-210
1.4.59.1 1.4.3-174
1.4.58.7 14.2-125
1.4.56.5 1.4.2-124
1.4.55.4 1.4.1-123
1.4.45.3 1.4.1-45
1.4.45.2 1.4.0-45
1.3.127.5 1.3.5-127
1.3.127.7 1.3.5-127
1.3.18.7 1.3.4-15

Azure Security Center aprovisiona automáticamente el agente de Log Analytics y lo conecta con el área de
trabajo de Log Analytics predeterminada creada por ASC en su suscripción a Azure. Si utiliza Azure Security
Center, no siga los pasos de este documento. Si lo hace, sobrescribirá el área de trabajo configurada e
interrumpirá la conexión con Azure Security Center.
Conectividad de Internet
La extensión del agente de Log Analytics para Linux requiere que la máquina virtual de destino esté conectada a
Internet.
Esquema de extensión
El siguiente JSON muestra el esquema para la extensión del agente de Log Analytics. La extensión requiere el
identificador y la clave del área de trabajo de Log Analytics de destino, valores que se pueden encontrar en el
área de trabajo de Log Analytics en Azure Portal. Como la clave del área de trabajo debe tratarse como datos
confidenciales, debe almacenarse en una configuración protegida. Los datos de configuración protegida de la
extensión de VM de Azure están cifrados y solo se descifran en la máquina virtual de destino. Tenga en cuenta
que workspaceId y workspaceKey distinguen mayúsculas de minúsculas.
{
"apiVersion": "2018-06-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vm-name>)]"
],
"properties": {
"settings": {
"workspaceId": "myWorkspaceId"
},
"workspaceKey": "myWorkSpaceKey"
}
}
}
NOTE
En el esquema anterior se da por supuesto que se colocará en el nivel raíz de la plantilla. Si lo coloca en el recurso de
máquina virtual en la plantilla, debe cambiar las propiedades type y name tal como se describe a continuación.
Valores de propiedad
N O M B RE VA LO R / E JEM P LO
apiVersion 2018-06-01
publisher Microsoft.EnterpriseCloud.Monitoring
type OmsAgentForLinux
typeHandlerVersion 1.7
workspaceId (p.ej) 6f680a37-00c6-41c7-a93f-1437e3462574
workspaceKey (p. ej.) z4bU3p1/GrnWpQkky4gdabWXAhbWSTz70hm4m2Xt92XI+

rSRgE8qVvRhsGo9TXffbrTahyrwv35W0pOqQAU7uQ==
Implementación de plantilla
Las extensiones de VM de Azure pueden implementarse con plantillas de Azure Resource Manager. Las plantillas
resultan ideales cuando se implementan una o varias máquinas virtuales que requieren configuración tras la
implementación, como por ejemplo, su incorporación a los registros de Azure Monitor. Puede encontrar una
plantilla de Resource Manager de ejemplo que incluye la extensión de máquina virtual del agente de Log
Analytics en la Galería de inicio rápido de Azure.
La configuración JSON de una extensión de máquina virtual puede estar anidada en el recurso de máquina
virtual o colocada en la raíz o nivel superior de una plantilla JSON de Resource Manager. La colocación de la
configuración JSON afecta al valor del nombre y tipo del recurso. Para obtener más información, consulte el
artículo sobre cómo establecer el nombre y el tipo de recursos secundarios.
En el siguiente ejemplo se da por supuesto que la extensión de VM está anidada dentro de los recursos de
máquina virtual. Cuando se anidan los recursos de extensión, la plantilla JSON se coloca en el objeto
"resources": [] de la máquina virtual.
{
"apiVersion": "2018-06-01",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
Al colocar la plantilla JSON de la extensión en la raíz de la plantilla, el nombre de recurso incluye una referencia
a la máquina virtual principal, y el tipo refleja la configuración anidada.
{
"name": "<parentVmResource>/OMSExtension",
"apiVersion": "2018-06-01",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
Implementación de la CLI de Azure

La CLI de Azure puede utilizarse para implementar la extensión de máquina virtual del agente de Log Analytics
en una máquina virtual. Reemplace el valor myWorkspaceKey siguiente por la clave del área de trabajo y el
valor myWorkspaceId por el identificador del área de trabajo. Estos valores se pueden encontrar en el área de
trabajo de Log Analytics en Azure Portal en Configuración avanzada.
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name OmsAgentForLinux \
--publisher Microsoft.EnterpriseCloud.Monitoring \
--version 1.10.1 --protected-settings '{"workspaceKey":"myWorkspaceKey"}' \
--settings '{"workspaceId":"myWorkspaceId"}'
Solución de problemas y asistencia

Los datos sobre el estado de las implementaciones de extensiones pueden recuperarse desde Azure Portal y
mediante la CLI de Azure. Para ver el estado de implementación de las extensiones de una máquina virtual
determinada, ejecute el comando siguiente con la CLI de Azure.
az vm extension list --resource-group myResourceGroup --vm-name myVM -o table
El resultado de la ejecución de las extensiones se registra en el archivo siguiente:
/opt/microsoft/omsagent/bin/stdout
Códigos de error y su significado

C Ó DIGO DE ERRO R SIGN IF IC A DO A C C IÓ N P O SIB L E
9 Habilitar llamado antes de tiempo Actualice el agente de Linux de Azure a

la versión más reciente disponible.
10 La máquina virtual ya está conectada a Para conectar la máquina virtual al

un área de trabajo de Log Analytics área de trabajo especificada en el
esquema de extensión, establezca
stopOnMultipleConnections en false
en la configuración pública o quite esta
propiedad. Esta máquina virtual se
factura una vez por cada área de
trabajo a la que se conecta.
11 Configuración no válida proporcionada Siga los ejemplos anteriores para

a la extensión configurar todos los valores de
propiedad necesarios para la
implementación.
17 Error al instalar el paquete de Log

Analytics
19 Error al instalar el paquete de OMI
20 Error al instalar el paquete de SCX
51 Esta extensión no se admite en el

sistema operativo de la máquina
virtual
C Ó DIGO DE ERRO R SIGN IF IC A DO A C C IÓ N P O SIB L E
55 No se puede conectar al servicio Azure Compruebe que el sistema tiene

Monitor o faltan los paquetes acceso a Internet o que se ha
necesarios o el administrador de proporcionado un servidor proxy HTTP
paquetes dpkg está bloqueado válido. Además, compruebe la validez
del identificador del área de trabajo y
compruebe que las utilidades curl y tar
está instaladas.
Puede encontrar información adicional para solucionar problemas en la Guía de solución de problemas del
Soporte técnico
Si necesita más ayuda con cualquier aspecto de este artículo, puede ponerse en contacto con los expertos de
Azure en los foros de MSDN Azure o Stack Overflow. Como alternativa, puede registrar un incidente de soporte
técnico de Azure. Vaya al sitio de soporte técnico de Azure y seleccione Obtener soporte. Para obtener
información sobre el uso del soporte técnico, lea las Preguntas más frecuentes de soporte técnico de Microsoft
Azure.
Conexión de equipos sin acceso a Internet mediante
la puerta de enlace de Log Analytics en Azure
Monitor
NOTE
La terminología cambia a medida que se realiza la transición de Microsoft Operations Management Suite (OMS) a
Microsoft Azure Monitor. Este artículo hace referencia a la puerta de enlace de OMS como la puerta de enlace de Azure
Log Analytics.
Este artículo describe cómo configurar la comunicación con Azure Automation y Azure Monitor mediante la
puerta de enlace de Log Analytics cuando los equipos que están directamente conectados o están supervisados
por Operations Manager no tienen acceso a Internet.
La puerta de enlace de Log Analytics es un proxy de reenvío de HTTP que admite la tunelización HTTP mediante
el comando HTTP CONNECT. Esta puerta de enlace envía datos a Azure Automation y a un área de trabajo de
Log Analytics en Azure Monitor en nombre de los equipos que no pueden conectarse a Internet.
La puerta de enlace de Log Analytics admite lo siguiente:
Informes de las mismas áreas de trabajo de Log Analytics configuradas en cada agente que hay detrás y que
están configuradas con Hybrid Runbook Workers de Azure Automation.
Equipos Windows en los que Microsoft Monitoring Agent está directamente conectado a un área de trabajo
de Log Analytics en Azure Monitor.
Equipos Linux en los que el agente de Log Analytics está directamente conectado a un área de trabajo de
Azure Monitor.
System Center Operations Manager 2012 SP1 con UR7, Operations Manager 2012 R2 con UR3 o un grupo
de administración en Operations Manager 2016 o posterior integrado con Log Analytics.
Algunas directivas de seguridad de TI no permiten la conexión a Internet para los equipos de red. Estos equipos
no conectados podrían ser dispositivos de punto de venta (POS) o los servidores que admiten servicios de TI,
por ejemplo. Para conectar estos dispositivos a Azure Automation o un área de trabajo de Log Analytics para
poder administrarlos y supervisarlos, configúrelos para que se comuniquen directamente con la puerta de
enlace de Log Analytics. La puerta de enlace de Log Analytics puede recibir información de configuración y
reenviar los datos en su nombre. Si los equipos están configurados con el agente de Log Analytics para
conectarse directamente a un área de trabajo de Log Analytics, los equipos se comunicarán en su lugar con la
puerta de enlace de Log Analytics.
La puerta de enlace de Log Analytics transfiere datos desde los agentes al servicio directamente. No analiza
ninguno de los datos en tránsito ni almacena datos en la memoria caché cuando pierde la conectividad con el
servicio. Cuando la puerta de enlace no puede comunicarse con el servicio, el agente continúa ejecutándose y
pone en cola los datos recopilados en el disco del equipo supervisado. Cuando se restaura la conexión, el agente
envía los datos en caché recopilados a Azure Monitor.
Cuando un grupo de administración de Operations Manager se integra en Log Analytics, se pueden configurar
los servidores de administración para que se conecten a la puerta de enlace de Log Analytics para recibir
información de configuración y enviar los datos recopilados según la solución que haya habilitado. Los agentes
de Operations Manager envían algunos datos al servidor de administración. Por ejemplo, los agentes pueden
enviar alertas de Operations Manager, datos de evaluación de configuración, datos del espacio de instancia y
datos de capacidad. Otros datos de gran volumen, como registros, datos de rendimiento y eventos de seguridad
de Internet Information Services (IIS), se envían directamente a la puerta de enlace de Log Analytics.
Si ha implementado uno o más servidores de puerta de enlace de Operations Manager para supervisar sistemas
no confiables en una red perimetral o una red aislada, dichos servidores no se podrán comunicar con la puerta
de enlace de Log Analytics. Los servidores de puerta de enlace de Operations Manager solo pueden informar a
un servidor de administración. Cuando se configura un grupo de administración de Operations Manager para
comunicarse con la puerta de enlace de Log Analytics, la información de configuración de proxy se distribuye
automáticamente a todos los equipos administrados por agente y configurados para recopilar datos de registro
para Azure Monitor, incluso si la configuración está vacía.
Para proporcionar alta disponibilidad a grupos directamente conectados o grupos de Operations Management
que se comunican con un área de trabajo de Log Analytics mediante la puerta de enlace, use el equilibrio de
carga de red (NLB) para redirigir y distribuir el tráfico entre varios servidores de puerta de enlace. De esa forma,
si un servidor de puerta de enlace deja de funcionar, el tráfico se redirige a otro nodo disponible.
El equipo que ejecuta la puerta de enlace de Log Analytics requiere el agente de Windows de Log Analytics para
identificar los puntos de conexión de servicio que necesita la puerta de enlace para establecer la conexión. El
agente también necesita dirigir la puerta de enlace para informar a las mismas áreas de trabajo que los agentes
o grupo de administración de Operations Manager detrás de la puerta de enlace con la que se ha configurado.
Esta configuración permite que la puerta de enlace y el agente se comuniquen con su área de trabajo asignada.
Una puerta de enlace puede ser de hosts múltiples en hasta cuatro áreas de trabajo. Este es el número total de
áreas de trabajo que admite un agente de Windows.
Cada agente debe tener conectividad de red a la puerta de enlace para que los agentes puedan transferir
automáticamente datos a la puerta de enlace y recibirlos de esta. Evite instalar la puerta de enlace en un
controlador de dominio. Los equipos Linux que están detrás de un servidor de puerta de enlace no pueden usar
el método de instalación del script contenedor para instalar el agente de Log Analytics para Linux. El agente debe
descargarse manualmente, copiarse en el equipo e instalarse manualmente porque la puerta de enlace solo
admite la comunicación con los servicios de Azure que se han mencionado anteriormente.
El siguiente diagrama muestra el flujo de datos desde los agentes directos, a través de la puerta de enlace, a
Azure Automation y Log Analytics. La configuración de proxy del agente debe coincidir con el puerto con el que
se ha configurado la puerta de enlace de Log Analytics.
El siguiente diagrama muestra el flujo de datos de un grupo de administración de Operations Manager a Log
Analytics.
Configuración del sistema

Los equipos designados para ejecutar la puerta de enlace de Log Analytics deben tener la siguiente
configuración:
Windows 10, Windows 8.1 o Windows 7
Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012,
Windows Server 2008 R2 o Windows Server 2008
Microsoft .NET Framework 4.5
Procesador de 4 núcleos y 8 GB de memoria como mínimo
El agente de Windows para Log Analytics que está configurado para informar a la misma área de trabajo que
los agentes que se comunican a través de la puerta de enlace.
Disponibilidad de idiomas
La puerta de enlace de Log Analytics está disponible en los idiomas siguientes:
Chino (simplificado)
Chino (tradicional)
Checo
Neerlandés
Inglés
Francés
Alemán
Húngaro
Italiano
Japonés
Coreano
Polaco
Portugués (Brasil)
Portugués (Portugal)
Ruso
Español (internacional)
Protocolos de cifrado admitidos
La puerta de enlace de Log Analytics solo admite Seguridad de la capa de transporte (TLS) 1.0, 1.1 y 1.2. No se
admite Capa de sockets seguros (SSL). Para garantizar la seguridad de datos en tránsito en Log Analytics,
configure la puerta de enlace para que use como mínimo TLS 1.2. Las versiones anteriores de TLS o SSL son
vulnerables. Aunque permiten actualmente compatibilidad con versiones anteriores, evite su uso.
Para información adicional, revise Sending data securely using TLS 1.2 (Envío de datos de forma segura
mediante TLS 1.2).
Número admitido de conexiones del agente
En la tabla siguiente se muestra aproximadamente cuántos agentes pueden comunicarse con un servidor de
puerta de enlace. La compatibilidad se basa en los agentes que cargan aproximadamente 200 KB de datos cada 6
segundos. El volumen de datos por agente de prueba es de unos 2,7 GB por día.
P UERTA DE EN L A C E A GEN T ES C O M PAT IB L ES ( A P RO XIM A DO )
CPU: Procesador Intel Xeon E5-2660 v3 @, 2,6 GHz, doble 600

núcleo
Memoria: 4 GB
Ancho de banda de la red: 1 Gbps
CPU: Procesador Intel Xeon E5-2660 v3 @, 2,6 GHz, cuatro 1000

núcleos
Memoria: 8 GB
Ancho de banda de la red: 1 Gbps
Descargar la puerta de enlace de Log Analytics

Obtenga la versión más reciente del archivo de instalación de puerta de enlace de Log Analytics en el Centro de
descarga de Microsoft (vínculo de descarga) o Azure Portal.
Para obtener la puerta de enlace de Log Analytics desde Azure Portal, siga estos pasos:
1. Vaya a la lista de servicios y, luego, seleccione Log Analytics .
2. Seleccione un área de trabajo.
3. En su hoja de área de trabajo, en General , seleccione Inicio rápido .
4. En Elija un origen de datos para conectarse al área de trabajo , seleccione Equipos .
5. En la hoja Agente directo , seleccione Descargar puer ta de enlace de Log Analytics .
or
1. En la hoja de área de trabajo en Configuración , seleccione Configuración avanzada .
2. Vaya a Orígenes conectados > Ser vidores de Windows y seleccione Descargar puer ta de enlace de
Log Analytics .
Instalación de la puerta de enlace de Log Analytics mediante el

asistente para la instalación
Para instalar una puerta de enlace mediante el asistente para la instalación, siga estos pasos.
1. En la carpeta de destino, haga doble clic en Log Analytics gateway.msi .
2. En la página principal , seleccione Siguiente .
3. En la página del Contrato de licencia , seleccione Acepto los términos del contrato de licencia para
aceptar los Términos de licencia del software de Microsoft y, a continuación, seleccione Siguiente .
4. En la página de dirección del proxy y puer to :
a. Escriba el número de puerto TCP que se va a usar para la puerta de enlace. El programa de instalación
utiliza este número de puerto para configurar una regla de entrada en el firewall de Windows. El valor
predeterminado es 8080. El intervalo válido del número de puerto es de 1 a 65535. Si el valor
especificado no se encuentra en este intervalo, aparece un mensaje de error.
b. Si el servidor en que está instalada la puerta de enlace necesita comunicarse a través de un proxy,
escriba la dirección del proxy al que debe conectarse la puerta de enlace. Por ejemplo, escriba
http://myorgname.corp.contoso.com:80 : Si deja este campo en blanco, la puerta de enlace intentará
conectarse directamente a Internet. Si el servidor proxy requiere autenticación, especifique el nombre de
usuario y la contraseña.
c. Seleccione Next (Siguiente).
5. Si Microsoft Update no está habilitado, aparecerá la página de Microsoft Update, donde puede elegir
habilitarlo. Elija la opción que desee y seleccione Siguiente . De lo contrario, continúe con el paso
siguiente.
6. En la página de la carpeta de destino , deje la carpeta predeterminada C:\Archivos de programa\OMS
Gateway o escriba la ubicación en la que desea instalar la puerta de enlace. Luego, seleccione Siguiente .
7. En la página Preparado para instalar , seleccione Instalar . Si un Control de cuentas de usuario solicita
permiso para realizar la instalación, seleccione Sí .
8. Una vez finalizada la instalación, seleccione Finalizar . Para comprobar que el servicio se está ejecutando,
abra el complemento services.msc y compruebe que la puer ta de enlace de OMS aparece en la lista de
servicios y que su estado sea En ejecución .
Instalación de la puerta de enlace de Log Analytics mediante la línea

de comandos
El archivo descargado para la puerta de enlace es un paquete de Windows Installer que admite la instalación
silenciosa desde la línea de comandos u otro método automatizado. Si no está familiarizado con las opciones de
línea de comandos estándar de Windows Installer, consulte Opciones de línea de comandos.
En la tabla siguiente se resaltan los parámetros admitidos por el programa de instalación.
PA RÁ M ET RO S N OTA S
PORTNUMBER Número de puerto TCP para que la puerta de enlace realice

la escucha.
PROXY Dirección IP del servidor proxy.
INSTALLDIR Ruta de acceso completa para especificar el directorio de

instalación de archivos de software de puerta de enlace.
USERNAME Id. de usuario para autenticarse con el servidor proxy
PASSWORD Contraseña del Id. de usuario para autenticarse con el proxy
LicenseAccepted Especifique un valor de 1 para comprobar que acepta el

contrato de licencia.
HASAUTH Especifique un valor de 1 cuando se especifiquen los

parámetros USERNAME/PASSWORD.
HASPROXY Especifique un valor de 1 cuando establezca la dirección IP

para el parámetro PROXY .
Para realizar una instalación silenciosa de la puerta de enlace y configurarla con un número de puerto y una
dirección de proxy específicos, escriba lo siguiente:
Msiexec.exe /I "oms gateway.msi" /qn PORTNUMBER=8080 PROXY="10.80.2.200" HASPROXY=1 LicenseAccepted=1

Con la opción de línea de comandos/qn se oculta el programa de instalación, con /qb se muestra el programa de
instalación durante la instalación silenciosa.
Si tiene que proporcionar credenciales para autenticarse con el proxy, escriba lo siguiente:
Msiexec.exe /I "oms gateway.msi" /qn PORTNUMBER=8080 PROXY="10.80.2.200" HASPROXY=1 HASAUTH=1 USERNAME="

<username>" PASSWORD="<password>" LicenseAccepted=1
Después de la instalación, puede confirmar que se ha aceptado la configuración (excluido el nombre de usuario y
contraseña) mediante los siguientes cmdlets de PowerShell:
Get-OMSGatewayConfig : devuelve el puerto TCP para el que se ha configurado la escucha de la puerta de
enlace.
Get-OMSGatewayRelayProxy : devuelve la dirección IP del servidor proxy configurado con el que
comunicarse.
Configuración de equilibrio de carga de red

Puede configurar la puerta de enlace para lograr alta disponibilidad con equilibrio de carga de red (NLB)
mediante Equilibrio de carga de red de (NLB) de Microsoft, Azure Load Balancer o equilibradores de carga
basados en hardware. El equilibrador de carga administra el tráfico al redirigir las conexiones solicitadas desde
los agentes de Log Analytics o los servidores de administración de Operations Manager mediante sus nodos. Si
un servidor de puerta de enlace deja de funcionar, el tráfico se redirige a otros nodos.
Equilibrio de carga de red de Microsoft
Para más información sobre cómo diseñar e implementar un clúster de equilibrio de carga de red de Windows
Server 2016, consulte Equilibrio de carga de red. Los pasos siguientes describen cómo configurar un clúster de
equilibrio de carga de red de Microsoft.
1. Inicie sesión en el servidor Windows que sea miembro del clúster NLB con una cuenta administrativa.
2. Abra el Administrador de equilibrio de carga de red en el Administrador del servidor, haga clic en
Herramientas y, luego, en Administrador de equilibrio de carga de red .
3. Para conectar un servidor de puerta de enlace de Log Analytics con Microsoft Monitoring Agent instalado,
haga clic con el botón derecho en la dirección IP del clúster y, después, seleccione Agregar host al
clúster .
4. Escriba la dirección IP del servidor de la puerta de enlace al que desea conectarse.
Azure Load Balancer

Para obtener información sobre cómo diseñar e implementar Azure Load Balancer, consulte ¿Qué es Azure Load
Balancer? Para implementar un equilibrador de carga básico, siga los pasos descritos en esta guía de inicio
rápido, excepto los pasos descritos en la sección Creación de ser vidores back-end .
NOTE
La configuración de Azure Load Balancer mediante la SKU básica requiere que las máquinas virtuales de Azure
pertenezcan a un conjunto de disponibilidad. Para obtener más información sobre los conjuntos de disponibilidad, consulte
Administración de la disponibilidad de las máquinas virtuales Windows en Azure. Para agregar máquinas virtuales
existentes a un conjunto de disponibilidad, consulte Configuración del conjunto de disponibilidad de Azure Resource
Manager.
Después de crear el equilibrador de carga, debe crearse un grupo back-end, que distribuye el tráfico a uno o más
servidores de puerta de enlace. Siga los pasos descritos en la sección del artículo de la guía de inicio rápido
Creación de recursos para el equilibrador de carga.
NOTE
Cuando configure el sondeo de estado, debe configurarse para usar el puerto TCP del servidor de puerta de enlace. El
sondeo de estado agrega o quita de forma dinámica los servidores de puerta de enlace de la rotación de Load Balancer en
base a su respuesta a las comprobaciones de estado.
Configuración del agente de Log Analytics y el grupo de

administración de Operations Manager
En esta sección, se indicarán los pasos para configurar los agentes de Log Analytics conectados directamente, un
grupo de administración de Operations Manager o Hybrid Runbook Workers de Azure Automation con la puerta
de enlace de Log Analytics para comunicarse con Azure Automation o Log Analytics.
Configuración del agente de Log Analytics independiente
Cuando configure el agente de Log Analytics, cambie el valor de servidor de proxy por la dirección IP del
servidor de puerta de enlace de Log Analytics y el número de puerto. Si ha implementado varios servidores de
puerta de enlace detrás de un equilibrador de carga, la configuración de proxy del agente de Log Analytics es la
dirección IP virtual del equilibrador de carga.
NOTE
Para instalar el agente de Log Analytics en la puerta de enlace y los equipos Windows que se conectan directamente a Log
Analytics, consulte Conexión de equipos Windows al servicio Log Analytics de Azure. Para los equipos Linux, consulte
Conexión de equipos Linux a Azure Monitor.
Después de instalar al agente en el servidor de puerta de enlace, configúrelo para que informe al área de trabajo
o a los agentes de las áreas de trabajo que se comunican con la puerta de enlace. Si el agente de Windows de
Log Analytics no está instalado en la puerta de enlace, se escribe el evento 300 en el registro de eventos de la
puerta de enlace de OMS con un mensaje que indica que el agente debe instalarse. Si el agente está instalado,
pero no está configurado para informar a la misma área de trabajo que los agentes que se comunican a través
de ella, se escribirá el evento 105 en el mismo registro de eventos indicando que el agente de la puerta de enlace
debe configurarse para llevar a cabo dicha comunicación.
Después de completar la configuración, reinicie el servicio Puer ta de enlace de OMS para aplicar los cambios.
En caso contrario, la puerta de enlace rechazará los intentos de los agentes por comunicarse con Log Analytics e
informará sobre el evento 105 en el registro de eventos de puerta de enlace de OMS. Esto se aplicará también al
agregar o quitar un área de trabajo de la configuración de agente en el servidor de puerta de enlace.
Para obtener información relacionada con Hybrid Runbook Worker de Automation, consulte Automatización de
recursos en los centros de datos o nube con Hybrid Runbook Worker.
Configuración de Operations Manager: todos los agentes usan el mismo servidor proxy
La configuración de proxy de Operations Manager se aplica automáticamente a todos los agentes que informan
a Operations Manager, incluso si la configuración está vacía.
Si desea utilizar la puerta de enlace de OMS para que sea compatible con Operations Manager, debe tener:
Microsoft Monitoring Agent (versión 8.0.10900.0 o posterior) instalado en el servidor de la puerta de enlace
de OMS y configurado con las mismas áreas de trabajo de Log Analytics que configuró para que el grupo de
administración enviara informes.
Conectividad de Internet. De forma alternativa, la puerta de enlace de OMS debe estar conectada a un
servidor proxy conectado a Internet.
NOTE
Si no especifica ningún valor para la puerta de enlace, se insertan valores en blanco para todos los agentes.
Si el grupo de administración de Operations Manager se registra con un área de trabajo de Log Analytics por
primera vez, la opción para especificar la configuración de proxy para el grupo de administración no estará
disponible en la consola del operador. Esta opción solo está disponible si el grupo de administración se ha
registrado con el servicio.
Para configurar la integración, actualice la configuración de proxy del sistema con Netsh en el sistema en el que
se esté ejecutando la consola del operador y en todos los servidores de administración del grupo de
administración. Siga estos pasos:
1. Abra un símbolo del sistema con privilegios elevados:
a. Seleccione Inicio y especifique cmd .
b. Haga clic con el botón derecho en el símbolo del sistema y seleccione Ejecutar como
administrador .
2. Escriba el comando siguiente:
netsh winhttp set proxy <proxy>:<port>
Después de completar la integración con Log Analytics, quite el cambio ejecutando netsh winhttp reset proxy . A
continuación, en la consola de operación, use la opción Configurar el ser vidor proxy para especificar el
servidor de puerta de enlace de Log Analytics.
1. En la consola de Operations Manager, en Operations Management Suite , seleccione Conexión y, a
continuación, Configurar ser vidor proxy .
2. Seleccione Use un ser vidor proxy para obtener acceso al ser vicio Operations Management
Suite y, después, escriba la dirección IP del servidor de puerta de enlace de Log Analytics o la dirección IP
virtual del equilibrador de carga. Tenga cuidado al comenzar con el prefijo http:// .
3. Seleccione Finalizar . El grupo de administración de Operations Manager está ahora configurado para
comunicarse mediante el servidor de puerta de enlace con el servicio Log Analytics.
Configuración de Operations Manager: determinados agentes usan un servidor proxy
En entornos grandes o complejos, puede que solo quiera tener determinados servidores (o grupos) que usen el
servidor de puerta de enlace de Log Analytics. En estos servidores, no se puede actualizar el agente Operations
Manager directamente, ya que el valor global para el grupo de administración sobrescribe este valor. En su lugar,
invalide la regla utilizada para insertar estos valores.
NOTE
Use esta técnica de configuración si desea permitir varios servidores de puerta de enlace de Log Analytics en su entorno.
Por ejemplo, puede exigir que se especifiquen determinados servidores de puerta de enlace de Log Analytics en cada
región.
Para configurar servidores o grupos específicos que utilicen el servidor de puerta de enlace de Log Analytics:
1. Abra la consola de Operations Manager y seleccione el área de trabajo Creación .
2. En el área de trabajo Creación, seleccione Reglas .
3. Seleccione el botón Ámbito en barra de herramientas de Operations Manager. Si este botón no está
disponible, asegúrese de que ha seleccionado un objeto, y no una carpeta, en el panel Super visión . El
cuadro de diálogo Objetos de módulo de administración de ámbito muestra una lista de clases,
grupos u objetos de destino comunes.
4. Escriba Ser vicio de mantenimiento en el campo Buscar y selecciónelo en la lista. Seleccione Aceptar .
5. Busque Regla de configuración de proxy de Advisor .
6. En la barra de herramientas de Operations Manager, seleccione Invalidaciones y luego vaya a Invalidar
la regla\Para un objeto de clase específico: Ser vicio de mantenimiento y seleccione un objeto de
la lista. También puede crear un grupo personalizado que incluya el objeto de servicio de mantenimiento
de los servidores a los que desea aplicar esta invalidación. Después, aplique la invalidación a ese grupo
personalizado.
7. En el cuadro de diálogo Propiedades de invalidación , agregue una marca de verificación en la
columna Invalidar junto al parámetro WebProxyAddress . En el campo Valor de invalidación , escriba
la dirección URL del servidor de puerta de enlace de Log Analytics. Tenga cuidado al comenzar con el
prefijo http:// .
NOTE
No es necesario habilitar la regla. Esta ya se administra automáticamente con una invalidación en el módulo de
administración de reemplazo de referencia segura de Microsoft System Center Advisor dirigido al grupo de
servidores de supervisión de Microsoft System Center Advisor.
8. Seleccione un módulo de administración de la lista Seleccionar módulo de administración de

destino o cree un nuevo módulo de administración no sellado seleccionando Nuevo .
9. Cuando termine, seleccione Aceptar .
Configuración de Hybrid Runbook Workers de Automation
Si tiene Hybrid Runbook Workers de Azure Automation en su entorno, siga estos pasos para configurar la puerta
de enlace de OMS de modo que sea compatible con los trabajos.
Consulte la sección sobre configuración de la red de la documentación de Automation para buscar la dirección
URL de cada región.
Si el equipo se registra automáticamente como Hybrid Runbook Worker, por ejemplo, si la solución de
administración de actualizaciones está habilitada para una o más máquinas virtuales, siga estos pasos:
1. Agregue las direcciones URL del servicio de datos en tiempo de ejecución del trabajo a la lista de hosts
permitidos de puerta de enlace de Log Analytics. Por ejemplo:
Add-OMSGatewayAllowedHost we-jobruntimedata-prod-su1.azure-automation.net
2. Reinicie el servicio de puerta de enlace de Log Analytics mediante el siguiente cmdlet de PowerShell:
Restart-Service OMSGatewayService
Si el equipo está incorporado en Azure Automation mediante el cmdlet de registro de Hybrid Runbook Worker,
siga estos pasos:
1. Agregue la dirección URL de registro del servicio Agente a la lista de hosts permitidos de la puerta de enlace
de Log Analytics. Por ejemplo: Add-OMSGatewayAllowedHost ncus-agentservice-prod-1.azure-automation.net
2. Agregue las direcciones URL del servicio de datos en tiempo de ejecución del trabajo a la lista de hosts
permitidos de puerta de enlace de Log Analytics. Por ejemplo:
Add-OMSGatewayAllowedHost we-jobruntimedata-prod-su1.azure-automation.net
3. Reinicie el servicio de puerta de enlace de Log Analytics. Restart-Service OMSGatewayService
Cmdlets de PowerShell útiles

Puede usar cmdlets para completar las tareas necesarias para actualizar las opciones de configuración de la
puerta de enlace de Log Analytics. Para poder usar cmdlets, asegúrese de lo siguiente:
1. Instale la puerta de enlace de Log Analytics (Microsoft Windows Installer).
2. Abra una ventana de la consola de PowerShell.
3. Para importar el módulo, escriba este comando: Import-Module OMSGateway .
4. Si no se ha producido ningún error en el paso anterior, el módulo se ha importado correctamente y se
pueden usar los cmdlets. Escriba Get-Module OMSGateway .
5. Después de usar los cmdlets para realizar cambios, reinicie el servicio de puerta de enlace de OMS.
Un error en el paso 3 implica que el módulo no se ha importado. Este error podría producirse si PowerShell no
puede encontrar el módulo. Puede encontrar el módulo en la ruta de instalación de puerta de enlace de OMS:
C:\Archivos de programa\Microsoft OMS Gateway\PowerShell\OmsGateway.
C M DL ET PA RÁ M ET RO S DESC RIP C IÓ N E JEM P LO
Get-OMSGatewayConfig Clave Obtiene la configuración del Get-OMSGatewayConfig

servicio
Set-OMSGatewayConfig Clave (se requiere) Cambia la configuración del Set-OMSGatewayConfig -

Value servicio Name ListenPort -Value
8080
Get- Obtiene la dirección del Get-

OMSGatewayRelayProxy proxy de retransmisión OMSGatewayRelayProxy
(ascendente)
Set- Dirección Establece la dirección (y 1. Establezca un proxy de

OMSGatewayRelayProxy Nombre de usuario credencial) del proxy de retransmisión y la
Contraseña (cadena segura) retransmisión (ascendente) credencial:
Set-
OMSGatewayRelayProxy
-Address
http://www.myproxy.com:8080
-Username user1 -
Password 123
2. Establezca un proxy de
retransmisión que no
necesite autenticación:
Set-
-Address
http://www.myproxy.com:8080
3. Desactive la configuración
del proxy de retransmisión:
Set-
-Address ""
Get- Obtiene el host permitido Get-

OMSGatewayAllowedHost actualmente (solo el host OMSGatewayAllowedHost
permitido configurado
localmente, no hosts
permitidos que se
descargan
automáticamente)
Add- Host (obligatorio) Agrega el host a la lista de Add-

OMSGatewayAllowedHost permitidos OMSGatewayAllowedHost -
Host www.test.com
Remove- Host (obligatorio) Quita el host de la lista de Remove-

OMSGatewayAllowedHost permitidos OMSGatewayAllowedHost
-Host www.test.com
C M DL ET PA RÁ M ET RO S DESC RIP C IÓ N E JEM P LO
Add- Asunto (obligatorio) Agrega el asunto del Add-OMSGatewayAllowed

OMSGatewayAllowedClientCertificate certificado de cliente a la ClientCertificate
lista de permitidos -Subject mycert
Remove- Asunto (obligatorio) Quita el asunto del Remove-

OMSGatewayAllowedClientCertificate certificado de cliente de la OMSGatewayAllowed
lista de permitidos ClientCertificate
-Subject mycert
Get- Obtiene los asuntos de Get-

OMSGatewayAllowedClientCertificate certificado de cliente OMSGatewayAllowed
permitidos actualmente ClientCertificate
(solo los asuntos permitidos
configurados localmente, no
los asuntos permitidos que
se descargan
automáticamente)
Para recopilar eventos registrados por la puerta de enlace, debe tener instalado el agente de Log Analytics.
Identificadores de evento y descripciones de la puerta de enlace de Log Analytics

En la tabla siguiente, se muestran los identificadores de evento y las descripciones de los eventos de registro de
la puerta de enlace de Log Analytics.
ID DESC RIP C IÓ N
400 Cualquier error de la aplicación que no tiene un identificador

específico.
401 Configuración errónea. Por ejemplo, listenPort = "text", en

lugar de un entero.
402 Excepción al analizar los mensajes de protocolo de enlace

TLS.
ID DESC RIP C IÓ N
403 Error de red. Por ejemplo, no se puede conectar al servidor

de destino.
100 Información general.
101 El servicio se ha iniciado.
102 El servicio se ha detenido.
103 Se ha recibido un comando HTTP CONNECT del cliente.
104 No es un comando HTTP CONNECT.
105 El servidor de destino no está en la lista de permitidos o el

puerto de destino no es seguro (443).
Asegúrese de que el agente MMA del servidor de puerta de

enlace de OMS y los agentes que se comunican con la
puerta de enlace de OMS están conectados a la misma área
de trabajo de Log Analytics.
105 ERROR TcpConnection – Invalid Client certificate:

CN=Gateway.
Asegúrese de que está usando la versión de puerta de enlace

de OMS 1.0.395.0 o superior. Asegúrese también de que el
agente MMA del servidor de puerta de enlace de OMS y los
agentes que se comunican con la puerta de enlace de OMS
están conectados a la misma área de trabajo de Log
Analytics.
106 Versión del protocolo TLS/SSL no admitida.
La puerta de enlace de Log Analytics admite TLS 1.0, 1.1 y

1.2. No admite SSL.
107 Se ha comprobado la sesión de TLS.
Contadores de rendimiento que se recopilan

En la tabla siguiente, se muestran los contadores de rendimiento disponibles para la puerta de enlace de Log
Analytics. Utilice el Monitor de rendimiento para agregar contadores.
Puerta de enlace de Log Analytics/conexión de cliente activa Número de conexiones de red (TCP) de cliente activas
Puerta de enlace de Log Analytics/número de errores Número de errores
Puerta de enlace de Log Analytics/cliente conectado Número máximo de clientes conectados
Puerta de enlace de Log Analytics/número de rechazos Número de rechazos debido a un error de validación de TLS
Asistencia
Después de iniciar sesión en Azure Portal, puede obtener ayuda con la puerta de enlace de Log Analytics o con
cualquier otro servicio o característica de Azure. Para solicitar asistencia, seleccione el icono de signo de
interrogación en la esquina superior derecha del portal y seleccione Nueva solicitud de sopor te técnico . A
continuación, complete el formulario de solicitud de soporte técnico nuevo.
Pasos siguientes
Agregue orígenes de datos para recopilar datos de los orígenes conectados y almacenar los datos en el área de
Administrar y mantener el agente de Log Analytics
para Windows y Linux
Después de la implementación inicial del agente de Windows o Linux para Log Analytics en Azure Monitor, debe
volver a configurar el agente, actualizarlo o quitarlo del equipo si alcanzó la fase de retirada de su ciclo de vida.
Puede administrar fácilmente estas tareas de mantenimiento rutinarias manualmente o de manera automática, lo
que reduce los errores de funcionamiento y los gastos.
Actualizar el agente
El agente de Log Analytics para Windows y Linux puede actualizarse a la versión más reciente de forma manual o
automáticamente según el escenario de implementación y la VM que se está ejecutando en el entorno. Los
métodos siguientes pueden usarse para actualizar el agente.
EN TO RN O M ÉTO DO DE IN STA L A C IÓ N M ÉTO DO DE A C T UA L IZ A C IÓ N
Azure VM Extensión de VM del agente de Log El agente se actualiza automáticamente

Analytics para Windows o Linux de forma predeterminada a menos que
configure la plantilla de Azure Resource
Manager para no realizar la
actualización; para ello, debe establecer
la propiedad autoUpgradeMinorVersion
a false .
Imágenes personalizadas de VM de Instalación manual del agente de Log La actualización de las VM a la versión
Azure Analytics para Windows o Linux más reciente del agente debe realizarse
desde la línea de comandos que ejecuta
el paquete del instalador de Windows o
el paquete de scripts de shell instalable
y autoextraíble de Linux.
VM ajenas a Azure Instalación manual del agente de Log La actualización de las VM a la versión
Analytics para Windows o Linux más reciente del agente debe realizarse
desde la línea de comandos que ejecuta
Actualización del agente de Windows

Para actualizar el agente de una máquina virtual Windows a la última versión que no se instaló con la extensión
de máquina virtual de Log Analytics, realice el proceso desde el símbolo del sistema, un script u otra solución de
automatización, o mediante el Asistente de instalación MMASetup-<platform>.msi.
Puede descargar la versión más reciente del agente de Windows desde el área de trabajo de Log Analytics,
realizando los pasos siguientes.
2. En Azure Portal, haga clic en Todos los ser vicios . En la lista de recursos, escriba Log Analytics . Cuando
Analytics .
3. En la lista de áreas de trabajo de Log Analytics, seleccione un área de trabajo.
4. En el área de trabajo de Log Analytics, seleccione Configuración avanzada , a continuación, seleccione
Orígenes conectados y, finalmente, Ser vidores Windows .
5. En la página Ser vidores de Windows , seleccione la versión correcta en Descargar el agente de
Windows que quiera descargar según la arquitectura del procesador del sistema operativo Windows.
NOTE
Durante la actualización del agente de Log Analytics para Windows, no se admitirá la configuración o volver a configurar un
área de trabajo para notificaciones. Para configurar el agente, deberá seguir uno de los métodos admitidos que se
enumeran en Agregar o quitar un área de trabajo.
Para actualizar mediante el Asistente de instalación

1. Inicie sesión en el equipo con una cuenta con derechos administrativos.
2. Ejecute MMASetup-<platform>.exe para iniciar el Asistente de instalación.
3. En la primera página del Asistente, haga clic en Siguiente .
4. En el cuadro de diálogo Configuración de Microsoft Monitoring Agent , haga clic en Aceptar para
aceptar el contrato de licencia.
5. En el cuadro de diálogo Configuración de Microsoft Monitoring Agent , haga clic en Actualizar . La
página de estado muestra el progreso de la actualización.
6. Cuando aparezca la página Se completó correctamente la configuración de Microsoft Monitoring
Agent , haga clic en Finalizar .
Actualizar desde la línea de comandos
2. Para extraer los archivos de instalación del agente, desde un símbolo del sistema con privilegios elevados
ejecute MMASetup-<platform>.exe /c y se le solicitará la ruta en la que extraer los archivos. Como
alternativa, puede especificar la ruta de acceso pasando los argumentos
MMASetup-<platform>.exe /c /t:<Full Path> .
3. Ejecute el siguiente comando, donde D:\ es la ubicación del archivo de registro de actualización.
setup.exe /qn /l*v D:\logs\AgentUpgrade.log AcceptEndUserLicenseAgreement=1
Actualización del agente de Linux

Es posible actualizar desde versiones anteriores (> 1.0.0-47). Si realizas la instalación con el comando --upgrade ,
se actualizarán todos los componentes del agente a la versión más reciente.
Para actualizar al agente, ejecute el siguiente comando.
sudo sh ./omsagent-*.universal.x64.sh --upgrade
Adición o eliminación de un área de trabajo

Agente de Windows
Los pasos descritos en esta sección son necesarios cuando no solo quiere reconfigurar el agente de Windows
para informar a un área de trabajo diferente o eliminar un área de trabajo de su configuración, sino también
cuando quiere configurar el agente para que informe a más de un área de trabajo (comúnmente referido como
hospedaje múltiple). La configuración del agente de Windows para informar a múltiples áreas de trabajo solo se
puede realizar después de la configuración inicial del agente y mediante los métodos que se describen a
continuación.
Actualizar la configuración del Panel de control
2. Abra el Panel de control .
3. Seleccione Microsoft Monitoring Agent y haga clic en la pestaña Azure Log Analytics .
4. Si quiere eliminar un área de trabajo, selecciónela y, después, haga clic en Quitar . Repita este paso para
cualquier otra área de trabajo de la que quiera que el agente deje de informar.
5. Si agrega un área de trabajo, haga clic en Agregar y en el cuadro de diálogo Agregar área de trabajo
de Log Analytics , pegue el identificador del área de trabajo y la clave del área de trabajo (clave principal).
Si el equipo tiene que notificar a un área de trabajo de Log Analytics en Azure Government Cloud,
seleccione Azure US Gov de la lista desplegable Azure Cloud.
6. Haga clic en Aceptar para guardar los cambios.
Quitar un área de trabajo con PowerShell
$workspaceId = "<Your workspace Id>"

$mma = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
$mma.RemoveCloudWorkspace($workspaceId)
$mma.ReloadConfiguration()
Agregar un área de trabajo en Azure Commercial con PowerShell

$workspaceKey = "<Your workspace Key>"
$mma.AddCloudWorkspace($workspaceId, $workspaceKey)
Agregar un área de trabajo en Azure for US Government con PowerShell

$workspaceKey = "<Your workspace Key>"
$mma.AddCloudWorkspace($workspaceId, $workspaceKey, 1)
NOTE
Si ha usado la línea de comandos o el script anteriormente para instalar o configurar el agente,
EnableAzureOperationalInsights se ha reemplazado por AddCloudWorkspace y RemoveCloudWorkspace .
Agente Linux
En los pasos siguientes se muestra cómo volver a configurar el agente de Linux si decide registrarlo en un área de
trabajo diferente o si quiere quitar un área de trabajo de la configuración.
1. Para comprobar que está registrado en un área de trabajo, ejecute el siguiente comando:
/opt/microsoft/omsagent/bin/omsadmin.sh -l
Debe devolver un estado similar al del ejemplo siguiente:

Primary Workspace: <workspaceId> Status: Onboarded(OMSAgent Running)
Es importante que el estado también muestre que el agente se está ejecutando, de lo contrario los
siguientes pasos para volver a configurar el agente no se completarán correctamente.
2. Si ya está registrado en un área de trabajo, quite el área de trabajo registrada mediante al ejecución del
siguiente comando. En caso contrario, si no está registrado, continúe con el paso siguiente.
/opt/microsoft/omsagent/bin/omsadmin.sh -X
3. Para registrarse con otra área de trabajo, ejecute el comando siguiente:

/opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <shared key> [-d <top level domain>]
4. Para comprobar que los cambios surten efecto, ejecute el siguiente comando:
/opt/microsoft/omsagent/bin/omsadmin.sh -l
Debe devolver un estado similar al del ejemplo siguiente:

Primary Workspace: <workspaceId> Status: Onboarded(OMSAgent Running)
El servicio del agente no tiene que reiniciarse para que los cambios surtan efecto.
Actualizar la configuración de proxy

Si quiere configurar el agente para comunicarse con el servicio a través de un servidor proxy o la puerta de
enlace de Log Analytics después de la implementación, use uno de los métodos siguientes para completar esta
tarea.
Agente de Windows
Actualizar la configuración con Panel de control
3. Seleccione Microsoft Monitoring Agent y haga clic en la pestaña Configuración de proxy .
4. Haga clic en Usar un ser vidor proxy y proporcione la dirección URL y el número de puerto del servidor
proxy o puerta de enlace. Si el servidor proxy o la puerta de enlace de Log Analytics requiere autenticación,
escriba el nombre de usuario y la contraseña para autenticarse y luego haga clic en Aceptar .
Actualizar la configuración con PowerShell
Copie el código de PowerShell de ejemplo siguiente, actualícelo con información específica de su entorno y
guárdelo con una extensión de nombre de archivo PS1. Ejecute el script en cada uno de los equipos que se
conecta directamente con el área de trabajo de Log Analytics en Azure Monitor.
param($ProxyDomainName="https://proxy.contoso.com:30443", $cred=(Get-Credential))
# First we get the Health Service configuration object. We need to determine if we

#have the right update rollup with the API we need. If not, no need to run the rest of the script.
$healthServiceSettings = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
$proxyMethod = $healthServiceSettings | Get-Member -Name 'SetProxyInfo'
if (!$proxyMethod)
{
Write-Output 'Health Service proxy API not present, will not update settings.'
return
}
Write-Output "Clearing proxy settings."

$healthServiceSettings.SetProxyInfo('', '', '')
$ProxyUserName = $cred.username
Write-Output "Setting proxy to $ProxyDomainName with proxy username $ProxyUserName."

$healthServiceSettings.SetProxyInfo($ProxyDomainName, $ProxyUserName, $cred.GetNetworkCredential().password)
Agente Linux
Siga estos pasos si los equipos Linux necesitan comunicarse a través de un servidor proxy o la puerta de enlace
de Log Analytics. El valor de configuración de proxy tiene la siguiente sintaxis:
[protocol://][user:password@]proxyhost[:port] . La propiedad proxyhost acepta un nombre de dominio completo
o la dirección IP del servidor proxy.
1. Edite el archivo /etc/opt/microsoft/omsagent/proxy.conf . Para ello, ejecute los comandos siguientes y
cambie los valores según su configuración específica.
proxyconf="https://proxyuser:proxypassword@proxyserver01:30443"
sudo echo $proxyconf >>/etc/opt/microsoft/omsagent/proxy.conf
sudo chown omsagent:omiusers /etc/opt/microsoft/omsagent/proxy.conf
Desinstalar agente
Use uno de los procedimientos siguientes para desinstalar al agente de Windows o Linux mediante el asistente
para instalación o la línea de comandos.
Agente de Windows
Desinstalar desde el Panel de control
2. En Panel de control , haga clic en Programas y características .
3. En Programas y características , haga clic en Microsoft Monitoring Agent , haga clic en Desinstalar
y, después, haga clic en Sí .
NOTE
También se puede ejecutar el asistente para instalación del agente haciendo doble clic en MMASetup-<platform>.exe ,
que está disponible para su descarga desde un área de trabajo en Azure Portal.
Desinstalar desde la línea de comandos

El archivo descargado del agente es un paquete de instalación independiente creado con IExpress. El programa de
instalación para el agente y los archivos auxiliares se encuentran en el paquete y deben extraerse para realizar la
desinstalación correctamente con la línea de comandos que se muestra en el ejemplo siguiente.
2. Para extraer los archivos de instalación del agente, desde un símbolo del sistema con privilegios elevados
ejecute extract MMASetup-<platform>.exe y se le solicitará la ruta en la que extraer los archivos. Como
alternativa, puede especificar la ruta de acceso pasando los argumentos
extract MMASetup-<platform>.exe /c:<Path> /t:<Path> . Para más información acerca de los modificadores
de la línea de comandos compatibles con IExpress, consulte Command-line switches for IExpress
(Modificadores de la línea de comandos para IExpress) y, después, actualice el ejemplo para adaptarlo a sus
necesidades.
3. En el símbolo del sistema, escriba: %WinDir%\System32\msiexec.exe /x <Path>:\MOMAgent.msi /qb .
Agente Linux
Para quitar el agente, ejecute el siguiente comando en el equipo Linux. El argumento --purge quita
completamente el agente y su configuración.
wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh
&& sh onboard_agent.sh --purge
Configurar el agente para que envíe notificaciones a un grupo de

administración de Operations Manager
Agente de Windows
Siga estos pasos para configurar al agente de Log Analytics para Windows para informar a un grupo de
administración de System Center Operations Manager.
NOTE

3. Haga clic en Microsoft Monitoring Agent y, después, en la pestaña Operations Manager .
4. Si los servidores de Operations Manager tienen integración con Active Directory, haga clic en Actualizar
automáticamente asignaciones de grupos de administración desde AD DS .
5. Haga clic en Agregar para abrir el cuadro de diálogo Agregar un grupo de administración .
6. En el campo Nombre del grupo de administración , especifique un nombre para el grupo de
administración.
7. En el campo Ser vidor de administración principal , escriba el nombre de equipo del servidor de
administración principal.
8. En el campo Puer to de ser vidor de administración , escriba el número de puerto TCP.
9. En Cuenta de acción del agente , seleccione la cuenta de sistema local o una cuenta de dominio local.
10. Haga clic en Aceptar para cerrar el cuadro de diálogo Agregar un grupo de administración y después
haga clic en Aceptar para cerrar el cuadro de diálogo Propiedades de Microsoft Monitoring Agent .
Agente Linux
Siga estos pasos para configurar al agente de Log Analytics para Linux para informar a un grupo de
administración de System Center Operations Manager.
NOTE
1. Edite el archivo /etc/opt/omi/conf/omiserver.conf
2. Asegúrese de que la línea que comienza con httpsport= define el puerto 1270. Por ejemplo:
httpsport=1270
3. Reinicie el servidor OMI: sudo /opt/omi/bin/service_control restart
Pasos siguientes
Consulte Solución de problemas del agente Linux si encuentra incidencias durante la instalación o la
administración del agente.
Consulte Solución de problemas del agente Windows si encuentra incidencias durante la instalación o la
administración del agente.
Solución Agent Health en Azure Monitor
La solución Agent Health en Azure le ayuda a entender, para todos los agentes que informan directamente al área
de trabajo de Log Analytics en Azure Monitor o a un grupo de administración de System Center Operations
Manager conectado a Azure Monitor, cuáles no responden y cuáles envían datos operativos. También puede
realizar un seguimiento del número de agentes que se implementan, dónde están distribuidos geográficamente y
llevar a cabo otras consultas para mantener el conocimiento de la distribución de los agentes implementados en
Azure, en otros entornos de nube o en un entorno local.
Prerrequisitos
Antes de implementar esta solución, confirme que tiene actualmente agentes de Windows compatibles que
informan al área de trabajo de Log Analytics o a un grupo de administración de Operations Manager integrado
con el área de trabajo.
Componentes de soluciones
Esta solución consta de los siguientes recursos que se agregan a su área de trabajo y a los agentes directamente
conectados o al grupo de administración conectado de Operations Manager.
Módulos de administración
Si el grupo de administración de System Center Operations Manager está conectado al área de trabajo de Log
Analytics, se instalarán los siguientes módulos de administración en Operations Manager. Estos módulos de
administración también se instalan en equipos Windows directamente conectados después de agregar esta
solución. No hay nada para configurar o administrar en estos módulos de administración.
Intelligence Pack HealthAssessment Direct Channel de Microsoft System Center Advisor
(Microsoft.IntelligencePacks.HealthAssessmentDirect)
Intelligence Pack HealthAssessment Server Channel de Microsoft System Center Advisor
(Microsoft.IntelligencePacks.HealthAssessmentViaServer)
Para obtener más información sobre cómo se actualizan los módulos de administración de soluciones, consulte
Conexión de Operations Manager con Log Analytics.
Configuración
Agregue la solución Agent Health al área de trabajo de Log Analytics mediante el proceso descrito en
Incorporación de soluciones. No es necesario realizar ninguna configuración más.
Agentes admitidos
En la tabla siguiente se describen los orígenes conectados que son compatibles con esta solución.
O RIGEN C O N EC TA DO C O M PAT IB L E DESC RIP C IÓ N
Agentes de Windows Sí Se recopilan eventos de latido de

agentes directos de Windows.
Grupo de administración de System Sí Se recopilan eventos de latido de

Center Operations Manager agentes que informan al grupo de
administración cada 60 segundos y
después se reenvían a Azure Monitor.
No se requiere ninguna conexión
directa entre los agentes de Operations
Manager y Azure Monitor. Los datos de
eventos de latido se reenvían del grupo
de administración al área de trabajo de
Log Analytics.
Uso de la solución
Al agregar la solución al área de trabajo de Log Analytics, se agrega el icono Agent Health al panel. Este icono
muestra el número total de agentes y el número de agentes que no responden en las últimas 24 horas.
Haga clic en el icono Agent Health para abrir el panel Agent Health . El panel incluye las columnas de la tabla
siguiente. Cada columna muestra los diez principales eventos por recuento que coinciden con los criterios de esa
columna para el intervalo de tiempo especificado. Puede ejecutar una búsqueda de registros que proporcione toda
la lista si selecciona Ver todo en la parte inferior derecha de la columna o hace clic en el encabezado de columna.
Agent count over time (Número de agentes a lo largo del Una tendencia del número de agentes durante un período de
tiempo) siete días para agentes de Linux y Windows.
Count of unresponsive agents (Número de agentes que no Una lista de agentes que no ha enviado ningún latido en las
responden) últimas 24 horas.
Distribution by OS Type (Distribución por tipo de sistema Una división de cuántos agentes de Windows y Linux tiene en
operativo) su entorno.
Distribution by Agent Version (Distribución por versión del Una división de las diferentes versiones de agente instaladas
agente) en su entorno y el número de cada una de ellas.
Distribution by Agent Category (Distribución por categoría Una división de las diferentes categorías de agentes que
del agente) envían eventos de latido: agentes directos, agentes de
OpsMgr o el servidor de administración de OpsMgr.
Distribution by Management Group (Distribución por grupo División de los diferentes grupos de administración de
de administración) Operations Manager en su entorno.
Geo-location of Agents (Geolocalización de los agentes) División de los diferentes países o regiones donde tiene
agentes y número total de agentes instalados en cada país o
región.
Count of Gateways Installed (Número de puertas de enlace Número de servidores que tienen instalada la puerta de
instaladas) enlace de Log Analytics y una lista de estos servidores.

La solución crea un tipo de registro en el área de trabajo de Log Analytics.
Registros de latidos
Se crea un registro del tipo Hear tbeat . Estos registros tienen las propiedades de la tabla siguiente.
Type Heartbeat
Category El valor es Direct Agent, SCOM Agent o SCOM Management

Server.
Computer Nombre del equipo.
OSType Sistema operativo Windows o Linux.
OSMajorVersion Versión principal del sistema operativo.
OSMinorVersion Versión secundaria del sistema operativo.
Version Versión del agente de Log Analytics o de Operations Manager.
SCAgentChannel El valor es Direct o SCManagementServer.
IsGatewayInstalled Si la puerta de enlace de Log Analytics está instalada, el valor

es true; en caso contrario, es false.
ComputerIP Dirección IP pública del equipo. En máquinas virtuales de

Azure, se mostrará la dirección IP pública si hay alguna
disponible. En el caso de las máquinas virtuales que usan
direcciones IP privadas, se mostrará la dirección SNAT de
Azure (no la dirección IP privada).
RemoteIPCountry Ubicación geográfica donde el equipo está implementado.
ManagementGroupName Nombre del grupo de administración de Operations Manager.
SourceComputerId Identificador único del equipo.
RemoteIPLongitude Longitud de la ubicación geográfica del equipo.
RemoteIPLatitude Latitud de la ubicación geográfica del equipo.
Cada agente que informa a un servidor de administración de Operations Manager enviará dos latidos y el valor de
la propiedad SCAgentChannel incluirá tanto Direct como SCManagementSer ver , en función de qué soluciones
y orígenes de datos haya habilitado en su suscripción. Si recuerda, los datos de soluciones se envían directamente
desde un servidor de administración de Operations Manager a Azure Monitor, o bien, debido al volumen de los
datos recopilados en el agente, se envían directamente del agente a Azure Monitor. Para los eventos de latido que
tienen el valor SCManagementSer ver , el valor de ComputerIP es la dirección IP del servidor de administración,
ya que es el que realmente carga los datos. Para los latidos donde SCAgentChannel esté establecido en Direct , es
la dirección IP pública del agente.
Búsquedas de registros de ejemplo

En la tabla siguiente se proporcionan búsquedas de registros de ejemplo para los registros recopilados por esta
solución.
Heartbeat | distinct Computer Número total de agentes
Heartbeat | summarize LastCall = max(TimeGenerated) by Número de agentes que no responden en las últimas 24
Computer | where LastCall < ago(24h) horas
Heartbeat | summarize LastCall = max(TimeGenerated) by Número de agentes que no responden en los últimos 15
Computer | where LastCall < ago(15m) minutos
Heartbeat | where TimeGenerated > ago(24h) and Computer Equipos en línea (en las últimas 24 horas)
in ((Heartbeat | where TimeGenerated > ago(24h) | distinct
Computer)) | summarize LastCall = max(TimeGenerated) by
Computer
Heartbeat | where TimeGenerated > ago(24h) and Computer Total de agentes sin conexión en los últimos 30 minutos (para
!in ((Heartbeat | where TimeGenerated > ago(30m) | distinct las últimas 24 horas)
Computer)) | summarize LastCall = max(TimeGenerated) by
Computer
Heartbeat | summarize AggregatedValue = dcount(Computer) Obtener una tendencia de número de agentes a lo largo del
by OSType tiempo por tipo de sistema operativo
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by OS Type (Distribución por tipo de sistema
by OSType operativo)
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by Agent Version (Distribución por versión del
by Version agente)
Heartbeat | summarize AggregatedValue = count() by Distribution by Agent Category (Distribución por categoría
Category del agente)
Heartbeat | summarize AggregatedValue = dcount(Computer) Distribution by Management Group (Distribución por grupo
by ManagementGroupName de administración)
Heartbeat | summarize AggregatedValue = dcount(Computer) Geo-location of Agents (Geolocalización de los agentes)

by RemoteIPCountry
Heartbeat | where iff(isnotnull(toint(IsGatewayInstalled)), Número de puertas de enlace de Log Analytics instaladas

IsGatewayInstalled == true, IsGatewayInstalled == "true") ==
true | distinct Computer
Pasos siguientes
Consulte las información general sobre las alertas en Azure Monitor para obtener más detalles sobre la
generación de alertas desde consultas de registro.
Introducción a Azure Diagnostics Extension
Azure Diagnostics Extension es un agente de Azure Monitor que recopila datos de supervisión del
sistema operativo invitado de los recursos de proceso de Azure, máquinas virtuales incluidas. En este
artículo se proporciona información general sobre Azure Diagnostics Extension, incluida la
funcionalidad específica que admite y las opciones de instalación y configuración.
NOTE
Azure Diagnostics Extension es uno de los agentes disponibles para recopilar datos de supervisión del sistema
operativo invitado y de los recursos de proceso de Azure. Consulte Introducción a los agentes de Azure
Monitor para ver una descripción de los distintos agentes e instrucciones sobre cómo seleccionar los que
necesite.
Escenarios principales
Los escenarios principales abordados por la extensión de diagnóstico son:
Recopilación de métricas de invitado en métricas de Azure Monitor.
Envío de registros y métricas de invitado a Azure Storage para su archivado.
Envío de registros y métricas de invitado a Azure Event Hubs para enviarlos fuera de Azure.
Comparación con el agente de Log Analytics

El agente de Log Analytics en Azure Monitor también sirve para recopilar datos de supervisión del
sistema operativo invitado de máquinas virtuales. Puede optar por usar uno o ambos, según sus
necesidades. Consulte Introducción a los agentes de Azure Monitor para ver una comparación
detallada entre los agentes de Azure Monitor.
Las principales diferencias que debe tener en cuenta son:
Azure Diagnostics Extension solo se puede usar con máquinas virtuales de Azure. El agente de Log
Analytics se puede usar con máquinas virtuales de Azure, de otras nubes y del entorno local.
Azure Diagnostics Extension envía datos a Azure Storage, a las métricas de Azure Monitor (solo en
Windows) y a Event Hubs. El agente de Log Analytics recopila los datos en los registros en Azure
Monitor.
El agente de Log Analytics es necesario para las soluciones, Azure Monitor para VM y otros
servicios, como Azure Security Center.
Costos
La extensión de Azure Diagnostics no cuesta nada, pero puede incurrir en cargos por los datos
ingeridos. Compruebe la página Precios de Azure Monitor del destino en el que va a recopilar los
datos.
Datos recopilados
En las tablas siguientes se enumeran los datos que se pueden recopilar con la extensión Diagnostics
de Windows y de Linux.
Extensión Diagnostics de Windows (WAD)
Registros de eventos de Windows Eventos del registro de eventos de Windows.
Contadores de rendimiento Valores numéricos que miden el rendimiento de

diferentes aspectos del sistema operativo y las cargas
de trabajo.
Registros IIS Información sobre el uso de los sitios web de IIS que se
ejecutan en el sistema operativo invitado.
Registros de aplicación Seguimiento de mensajes escritos por la aplicación.
Registros de .NET EventSource Eventos de escritura de código mediante la clase

EventSource de .NET
Registros de ETW basado en manifiesto Seguimiento de eventos para Windows generados por
cualquier proceso.
Volcados de memoria (registros) Información sobre el estado del proceso en caso de

bloqueo de una aplicación.
Registros basados en archivos Archivos creados por su aplicación o servicio.
Registros de diagnóstico del agente Información sobre Azure Diagnostics.
Extensión Diagnostics de Linux (LAD)

syslog Eventos enviados al sistema de registro de eventos de

Linux.
Contadores de rendimiento Valores numéricos que miden el rendimiento de

diferentes aspectos del sistema operativo y las cargas
de trabajo.
Archivos de registro Entradas enviadas a un registro basado en archivos.
Destinos de datos
La extensión Azure Diagnostics para Windows y Linux siempre recopila datos en una cuenta de Azure
Storage. Consulte el artículo acerca de Instalación y configuración de Azure Diagnostics Extension de
Windows (WAD) y Uso de la extensión Diagnostics de Linux para supervisar métricas y registros para
una lista de las tablas y los blobs donde se recopilan estos datos.
Configure uno o varios receptores de datos para enviar datos a otros destinos adicionales. En las
secciones siguientes se enumeran los receptores disponibles para la extensión Diagnostics de
Windows y Linux.
Extensión Diagnostics de Windows (WAD)
Métricas de Azure Monitor Recopila datos de rendimiento en Métricas en Azure

Monitor. Consulte el artículo Envío de métricas de
sistema operativo invitado a la base de datos de
Centros de eventos Usa Azure Event Hubs para enviar datos fuera de
Azure. Consulte Transmisión de datos de Azure
Diagnostics a Event Hubs.
Blobs de Azure Storage Escribe los datos en blobs de Azure Storage además de
en tablas.
Application Insights Recopila datos de las aplicaciones que se ejecutan en la

máquina virtual en Application Insights para
integrarlos con la supervisión de otras aplicaciones.
Consulte el artículo sobre el Envío de datos de
diagnóstico a Application Insights.
También puede recopilar datos de WAD del almacenamiento en un área de trabajo de Log Analytics
para analizarlos con Registros en Azure Monitor, aunque normalmente se usa el agente de Log
Analytics para esta funcionalidad. Puede enviar datos directamente a un área de trabajo de Log
Analytics y admite soluciones e información que proporcionan funcionalidades adicionales. Consulte el
artículo sobre la Recopilación de registros de diagnóstico de Azure desde Azure Storage.
Extensión Diagnostics de Linux (LAD)
LAD escribe los datos en tablas en Azure Storage. Es compatible con los receptores de la tabla
siguiente.
Centros de eventos Usa Azure Event Hubs para enviar datos fuera de
Azure.
Blobs de Azure Storage Escribe los datos en blobs de Azure Storage además de
en tablas.
Métricas de Azure Monitor Instala el agente de Telegraf además de LAD. Consulte

Recopilación de métricas personalizadas para una
máquina virtual Linux con el agente de InfluxData
Telegraf.
Instalación y configuración
La extensión Diagnostics se implementa como una extensión de máquina virtual en Azure, por lo que
admite las mismas opciones de instalación con las plantillas de Resource Manager, PowerShell y la CLI.
Consulte Características y extensiones de máquina virtual de Windows y Características y extensiones
de máquina virtual de Linux para información general sobre la instalación y el mantenimiento de
extensiones de máquina virtual.
También puede instalar y configurar la extensión Diagnostics de Windows y Linux en Azure Portal en
Configuración de diagnóstico en la sección Super visión del menú de la máquina virtual.
Consulte los artículos siguientes para más información sobre la instalación y la configuración de la
extensión Diagnostics de Windows y de Linux.
Instalación y configuración de Azure Diagnostics Extension de Windows (WAD)
Uso de la extensión Diagnostics de Linux para supervisar métricas y registros
Otra documentación
Roles web y de trabajo del servicio en la nube de Azure (clásico )
Introducción a la supervisión de servicios en la nube
Habilitación de Azure Diagnostics en Azure Cloud Services
Application Insights para Azure Cloud Services
Seguimiento del flujo en una aplicación de Cloud Services con Diagnósticos de Azure
Azure Service Fabric
Supervisión y diagnóstico de servicios en una configuración de desarrollo de máquina local
Pasos siguientes
Aprenda a utilizar los contadores de rendimiento en Diagnósticos de Azure.
Si tiene problemas al iniciar los diagnósticos o al buscar datos en las tablas de Azure Storage,
consulte Solución de problemas de Azure Diagnostics.
Instalación y configuración de la extensión de
Azure Diagnostics (WAD) para Windows
Azure Diagnostics Extension es un agente de Azure Monitor que recopila datos de supervisión del sistema
operativo invitado y de las cargas de trabajo de las máquinas virtuales de Azure y de otros recursos de
proceso. En este artículo se proporcionan detalles sobre cómo instalar y configurar la extensión de
diagnósticos para Windows y una descripción de cómo se almacenan los datos en la cuenta de Azure Storage.
La extensión de diagnósticos se implementa como una extensión de máquina virtual en Azure, por lo que
admite las mismas opciones de instalación mediante las plantillas de Resource Manager, PowerShell y la CLI.
Consulte Características y extensiones de las máquinas virtuales para Windows para más información sobre
la instalación y el mantenimiento de extensiones de máquina virtual.
Al configurar la extensión de diagnósticos de Windows Azure, debe especificar una cuenta de
almacenamiento a la que se enviarán todos los datos especificados. Opcionalmente, puede agregar uno o
más receptores de datos con el fin de enviar los datos a ubicaciones diferentes.
Receptor de Azure Monitor: envíe datos de rendimiento de invitados a métricas de Azure Monitor.
Receptor de centros de eventos: envíe datos de registro y de rendimiento de invitados a centros de
eventos de Azure para reenviarlos fuera de Azure. No se puede configurar este receptor en Azure Portal.
Instalación con Azure Portal

Puede instalar y configurar la extensión de diagnósticos en una máquina virtual de Azure Portal que
proporcione una interfaz en lugar de trabajar directamente con la configuración. Al habilitar la extensión de
diagnósticos, se usará automáticamente una configuración predeterminada con los eventos y contadores de
rendimiento más comunes. Esta configuración predeterminada se puede modificar de acuerdo con sus
requisitos específicos.
NOTE
A continuación se describe la configuración más común de la extensión de diagnósticos. Para obtener más información
sobre la configuración, vea Esquema de Windows Diagnostic Extension.
1. Abra el menú de una máquina virtual en Azure Portal.

2. Haga clic en Configuración de diagnóstico en la sección Super visión del menú de la máquina
virtual.
3. Haga clic en Habilitar super visión a nivel de invitado si aún no se ha habilitado la extensión de
diagnósticos.
4. Se crea una cuenta de Azure Storage para la máquina virtual, donde el nombre se basa en el del grupo
de recursos de la máquina virtual, y se seleccionará un conjunto predeterminado de contadores y
registros de rendimiento de invitado.
5. En la pestaña Contadores de rendimiento , seleccione las métricas de invitado que desea recopilar
de esta máquina virtual. Use la opción Personalizado para realizar una selección más avanzada.
6. En la pestaña Registros , seleccione los registros que se van a recopilar de la máquina virtual. Los
registros se pueden enviar a centro de eventos o almacenamiento, pero no a Azure Monitor. Use el
agente de Log Analytics para recopilar los registros de invitados a Azure Monitor.
7. En la pestaña Volcados de memoria , especifique cualquier proceso para recopilar volcados de

memoria después de un bloqueo. Los datos se escribirán en la cuenta de almacenamiento para la
configuración de diagnóstico y, opcionalmente, puede especificar un contenedor de blobs.
8. En la pestaña Receptores , especifique si desea enviar los datos a ubicaciones distintas de

Azure Storage. Si selecciona Azure Monitor , se enviarán los datos de rendimiento de los invitados a
las métricas de Azure Monitor. No se puede configurar el receptor de centros de eventos mediante
Azure Portal.
Si no ha habilitado una identidad asignada por el sistema configurada para la máquina virtual, es
posible que vea la siguiente advertencia al guardar una configuración con el receptor de
Azure Monitor. Haga clic en el banner para habilitar la identidad asignada por el sistema.
9. En Agente , puede cambiar la cuenta de almacenamiento, establecer la cuota de disco y especificar si

desea recopilar registros de infraestructura de diagnóstico.
10. Para guardar la configuración, haga clic en Guardar .
NOTE
Aunque se puede dar formato a la configuración de la extensión de diagnósticos en JSON o XML, cualquier
configuración realizada en Azure Portal se almacenará siempre como JSON. Si usa XML con otro método de
configuración y, luego, cambia la configuración con Azure Portal, esta cambiará a JSON.

Consulte Uso de la supervisión y el diagnóstico con una máquina virtual Windows y plantillas de Azure
Resource Manager para información sobre la implementación de la extensión de diagnósticos con plantillas
de Azure Resource Manager.
Implementación de la CLI de Azure

La CLI de Azure se puede usar para implementar la extensión de Azure Diagnostics en una máquina virtual
existente mediante az vm extension set, como en el ejemplo siguiente.
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name IaaSDiagnostics \
--publisher Microsoft.Azure.Diagnostics \
--protected-settings protected-settings.json \
--settings public-settings.json
La configuración protegida se define en el elemento PrivateConfig del esquema de configuración. A

continuación se indica un ejemplo mínimo de un archivo de configuración protegida que define la cuenta de
almacenamiento. Consulte Configuración de ejemplo para ver detalles completos de la configuración privada.
{
"storageAccountName": "mystorageaccount",
"storageAccountKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"storageAccountEndPoint": "https://mystorageaccount.blob.core.windows.net"
}
La configuración pública se define en el elemento Public del esquema de configuración. A continuación se

ofrece un ejemplo mínimo de un archivo de configuración pública que permite la recopilación de registros de
infraestructura de diagnóstico, un único contador de rendimiento y un único registro de eventos. Consulte
Configuración de ejemplo para información detallada sobre la configuración pública.
{
"StorageAccount": "mystorageaccount",
"WadCfg": {
{
"counterSpecifier": "\\Processor Information(_Total)\\% Processor Time",
"unit": "Percent",
"sampleRate": "PT60S"
}
]
},
"DataSource": [
{
"name": "Application!*[System[(Level=1 or Level=2 or Level=3)]]"
}
]
}
}
}
}
Implementación de PowerShell
PowerShell se puede usar para implementar la extensión de Azure Diagnostics en una máquina virtual
existente mediante Set-AzVMDiagnosticsExtension, como en el ejemplo siguiente.
Set-AzVMDiagnosticsExtension -ResourceGroupName "myvmresourcegroup" `

-VMName "myvm" `
-DiagnosticsConfigurationPath "DiagnosticsConfiguration.json"
La configuración privada se define en el elemento PrivateConfig, mientras que la configuración pública se

define en el elemento Public del esquema de configuración. También puede optar por especificar los detalles
de la cuenta de almacenamiento como parámetros del cmdlet Set-AzVMDiagnosticsExtension en lugar de
incluirlos en la configuración privada.
A continuación se ofrece un ejemplo mínimo de un archivo de configuración que permite la recopilación de
registros de infraestructura de diagnóstico, un único contador de rendimiento y un único registro de eventos.
Consulte Configuración de ejemplo para información detallada sobre la configuración pública y privada.
{
"PublicConfig": {
"WadCfg": {
},
{
"unit": "percent"
}
]
},
"DataSource": [
{
}
]
}
}
},
"StorageType": "TableAndBlob"
},
"PrivateConfig": {
"storageAccountKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"storageAccountEndPoint": "https://mystorageaccount.blob.core.windows.net"
}
}
Consulte también Uso de PowerShell para habilitar Diagnósticos de Azure en una máquina virtual con
Windows.
Almacenamiento de datos
En la tabla siguiente se enumeran los distintos tipos de datos recopilados por la extensión de diagnósticos y
se indica si se almacenan como una tabla o un blob. Los datos almacenados en tablas también se pueden
almacenar en blobs en función del valor de StorageType de la configuración pública.
DATA T IP O DE A L M A C EN A M IEN TO DESC RIP C IÓ N
WADDiagnosticInfrastructureLogsTabl Tabla Monitor de diagnóstico y cambios de

e configuración.
DATA T IP O DE A L M A C EN A M IEN TO DESC RIP C IÓ N
WADDirectoriesTable Tabla Directorios que supervisa el monitor

de diagnóstico. Esto incluye los
registros de IIS, los registros de
solicitudes con error de IIS y los
directorios personalizados. La
ubicación del archivo de registro de
blob se especifica en el campo de
contenedor y el nombre del blob está
en el campo RelativePath. El campo
AbsolutePath indica la ubicación y el
nombre del archivo tal como existía
en la máquina virtual de Azure.
WadLogsTable Tabla Registros escritos en código mediante

la escucha de seguimiento.
WADPerformanceCountersTable Tabla Contadores de rendimiento.
WADWindowsEventLogsTable Tabla Registros de eventos de Windows.
wad-iis-failedreqlogfiles Blob Contiene información de los registros

de solicitudes con error de IIS.
wad-iis-logfiles Blob Contiene información sobre los

registros de IIS.
"custom" Blob Un contenedor personalizado basado

en la configuración de directorios
supervisados por el monitor de
diagnóstico. El nombre de este
contenedor de blob se especificará en
WADDirectoriesTable.
Herramientas para ver los datos de diagnóstico

Existen varias herramientas para ver los datos una vez que se transfieren al almacenamiento. Por ejemplo:
El Explorador de servidores en Visual Studio: si instaló Azure Tools para Microsoft Visual Studio, puede
usar el nodo de Azure Storage en el Explorador de servidores para ver los datos de tabla y blob de solo
lectura de las cuentas de Azure Storage. Puede mostrar datos de la cuenta del emulador de
almacenamiento local y también desde cuentas de almacenamiento que haya creado para Azure. Para
obtener más información, consulte Exploración y administración de recursos de almacenamiento con el
Explorador de servidores.
Explorador de Microsoft Azure Storage es una aplicación independiente que permite trabajar fácilmente
con los datos de Azure Storage en Windows, OSX y Linux.
Azure Management Studio incluye Azure Diagnostics Manager, que permite ver, descargar y administrar
los datos de diagnóstico recopilados por las aplicaciones que se ejecutan en Azure.
Pasos siguientes
Consulte Envío de datos desde la extensión Azure Diagnostics para Windows a Event Hubs para más
información sobre el reenvío de datos de supervisión a Azure Event Hubs.
Uso de PowerShell para habilitar Diagnósticos de
Azure en una máquina virtual con Windows
Diagnósticos de Azure es la funcionalidad de Azure que habilita la recopilación de datos de diagnóstico en una
aplicación implementada. Puede usar la extensión de diagnósticos para recopilar datos de diagnóstico como
registros de aplicaciones o contadores de rendimiento de una máquina virtual (VM) de Azure con Windows.
Habilite la extensión de diagnósticos si usa el modelo de

implementación del Administrador de recursos
Puede habilitar la extensión de diagnósticos al crear una VM de Windows a través del modelo de implementación
del Administrador de recursos de Azure añadiendo la configuración de extensiones a la plantilla del Administrador
de recursos. Vea Creación de una máquina virtual de Windows con supervisión y diagnóstico mediante la plantilla
de Azure Resource Manager.
Para habilitar la extensión de diagnósticos en una VM existente creada mediante el modelo de implementación de
Resource Manager, puede usar el cmdlet de PowerShell Set-AzVMDiagnosticsExtension tal como se muestra a
continuación.
$vm_resourcegroup = "myvmresourcegroup"
$vm_name = "myvm"
$diagnosticsconfig_path = "DiagnosticsPubConfig.xml"
Set-AzVMDiagnosticsExtension -ResourceGroupName $vm_resourcegroup -VMName $vm_name -

DiagnosticsConfigurationPath $diagnosticsconfig_path
$diagnosticsconfig_path es la ruta de acceso del archivo que contiene la configuración de diagnóstico en XML
como se describe en el ejemplo a continuación.
Si especifica el archivo de configuración de diagnósticos de un elemento StorageAccount con un nombre de
cuenta de almacenamiento, el script Set-AzVMDiagnosticsExtension establecerá automáticamente la extensión de
diagnósticos para enviar datos de diagnóstico a esa cuenta de almacenamiento. Para que esto funcione, la cuenta
de almacenamiento necesita estar en la misma suscripción que la VM.
Si no se ha especificado el parámetro StorageAccount en la configuración de diagnóstico, es necesario pasar el
parámetro StorageAccountName al cmdlet. Si no se ha especificado el parámetro StorageAccountName , el cmdlet
siempre usará la cuenta de almacenamiento especificada en el parámetro y no la especificada en el archivo de
configuración de diagnóstico.
Si la cuenta de almacenamiento de diagnóstico está en una suscripción distinta que la VM, es necesario pasar
explícitamente los parámetros StorageAccountName y StorageAccountKey al cmdlet. El parámetro
StorageAccountKey no es necesario cuando la cuenta de almacenamiento de diagnóstico está en la misma
suscripción, ya que el cmdlet puede consultar automáticamente y establecer el valor de clave cuando se habilita la
extensión de diagnóstico. Sin embargo, si la cuenta de almacenamiento de diagnóstico está en una suscripción
diferente, es posible que el cmdlet no pueda obtener la clave automáticamente y que sea necesario especificar
explícitamente la clave mediante el parámetro StorageAccountKey .
Set-AzVMDiagnosticsExtension -ResourceGroupName $vm_resourcegroup -VMName $vm_name -
DiagnosticsConfigurationPath $diagnosticsconfig_path -StorageAccountName $diagnosticsstorage_name -
StorageAccountKey $diagnosticsstorage_key
Una vez habilitada la extensión de diagnósticos en una VM, puede obtener la configuración actual mediante el
cmdlet Get-AzmDiagnosticsExtension Get.
Get-AzVMDiagnosticsExtension -ResourceGroupName $vm_resourcegroup -VMName $vm_name
El cmdlet devuelve PublicSettings, que contiene la configuración de diagnóstico. Hay dos tipos de configuraciones
compatibles: WadCfg y xmlCfg. WadCfg es la configuración JSON y xmlCfg es la configuración XML en formato
con codificación Base64. Para leer el archivo XML, es necesario descodificarlo.
$publicsettings = (Get-AzVMDiagnosticsExtension -ResourceGroupName $vm_resourcegroup -VMName

$vm_name).PublicSettings
$encodedconfig = (ConvertFrom-Json -InputObject $publicsettings).xmlCfg
$xmlconfig = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($encodedconfig))
Write-Host $xmlconfig
El cmdlet Remove-AzVmDiagnosticsExtension puede usarse para quitar la extensión de diagnósticos de la VM.
Habilite la extensión de diagnósticos si usa el modelo de

implementación clásico
IMPORTANT
Las máquinas virtuales clásicas se retirarán el 1 de marzo de 2023.
Si usa recursos de IaaS desde ASM, complete la migración antes del 1 de marzo de 2023. Le recomendamos que realice el
cambio antes, para aprovechar las diversas mejoras de las características de Azure Resource Manager.
Para más información, consulte Migración de los recursos de IaaS a Azure Resource Manager antes de 1 de marzo de 2023.
Puede usar el cmdlet Set-AzureVMDiagnosticsExtension para habilitar la extensión de diagnósticos en una VM

creada mediante el modelo de implementación clásica. En el ejemplo siguiente se muestra cómo crear una nueva
VM mediante el modelo de implementación clásica con la extensión de diagnósticos habilitada.
$VM = New-AzureVMConfig -Name $VM -InstanceSize Small -ImageName $VMImage

$VM = Add-AzureProvisioningConfig -VM $VM -AdminUsername $Username -Password $Password -Windows
$VM = Set-AzureVMDiagnosticsExtension -DiagnosticsConfigurationPath $Config_Path -VM $VM -StorageContext
$Storage_Context
New-AzVM -Location $Location -ServiceName $Service_Name -VM $VM
Para habilitar la extensión de diagnósticos en una VM existente creada mediante el modelo de implementación
clásica, use el cmdlet Get-AzureVM en primer lugar para obtener la configuración de VM. A continuación, actualice
la configuración de VM para incluir la extensión de diagnósticos mediante el cmdlet Set-
AzureVMDiagnosticsExtension . Por último, aplique la configuración actualizada a la VM mediante Update-
AzureVM.
$VM = Get-AzureVM -ServiceName $Service_Name -Name $VM_Name

$VM_Update = Set-AzureVMDiagnosticsExtension -DiagnosticsConfigurationPath $Config_Path -VM $VM -
StorageContext $Storage_Context
Update-AzureVM -ServiceName $Service_Name -Name $VM_Name -VM $VM_Update.VM
Configuración de diagnósticos de ejemplo
Se puede utilizar el siguiente XML para la configuración pública de diagnósticos con los scripts anteriores. Esta
configuración de ejemplo transferirá diversos contadores de rendimiento a la cuenta de almacenamiento de
información de diagnósticos junto con los errores de la aplicación, seguridad y canales del sistema en los registros
de eventos de Windows y los errores de los registros de infraestructura de diagnóstico.
La configuración debe actualizarse para incluir lo siguiente:
El atributo resourceID del elemento Métricas tiene que actualizarse con el identificador de recurso de la
VM.
El identificador de recursos puede crearse mediante el siguiente patrón:
"/subscriptions/{Identificador de suscripción para la suscripción con la
VM}/resourceGroups/{Nombre del grupo de recursos para la
VM}/providers/Microsoft.Compute/virtualMachines/{Nombre de la VM}".
Por ejemplo, si el identificador de suscripción para la suscripción donde se está ejecutando la VM es
11111111-1111-1111-1111-111111111111 , el nombre del grupo de recursos para el grupo
de recursos es MyResourceGroup y el nombre de la VM esMyWindowsVM , el valor de
resourceID sería:
<Metrics resourceId="/subscriptions/11111111-1111-1111-1111-
111111111111/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/virtualMachines/MyWindow
sVM" >
Para obtener más información sobre cómo se generan las métricas según la configuración de las
métricas y los contadores de rendimiento, consulte la tabla de métricas de Diagnósticos de Azure de
almacenamiento.
El elemento StorageAccount tiene que actualizarse con el nombre de la cuenta de almacenamiento de
diagnósticos.
<?xml version="1.0" encoding="utf-8"?>

<PublicConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096">
<DiagnosticInfrastructureLogs scheduledTransferLogLevelFilter="Error"/>
<PerformanceCounters scheduledTransferPeriod="PT1M">
<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time"
sampleRate="PT15S" unit="Percent">
<annotation displayName="CPU utilization" locale="en-us"/>
</PerformanceCounterConfiguration>
<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Privileged Time"
<annotation displayName="CPU privileged time" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% User Time"
<annotation displayName="CPU user time" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Processor Information(_Total)\Processor
Frequency" sampleRate="PT15S" unit="Count">
<annotation displayName="CPU frequency" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\System\Processes" sampleRate="PT15S"
unit="Count">
<annotation displayName="Processes" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Process(_Total)\Thread Count"
sampleRate="PT15S" unit="Count">
<annotation displayName="Threads" locale="en-us"/>
<annotation displayName="Threads" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Process(_Total)\Handle Count"
<annotation displayName="Handles" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\% Committed Bytes In Use"
<annotation displayName="Memory usage" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes" sampleRate="PT15S"
unit="Bytes">
<annotation displayName="Memory available" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Committed Bytes" sampleRate="PT15S"
unit="Bytes">
<annotation displayName="Memory committed" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Commit Limit" sampleRate="PT15S"
unit="Bytes">
<annotation displayName="Memory commit limit" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Pool Paged Bytes" sampleRate="PT15S"
unit="Bytes">
<annotation displayName="Memory paged pool" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Pool Nonpaged Bytes"
sampleRate="PT15S" unit="Bytes">
<annotation displayName="Memory non-paged pool" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\% Disk Time"
<annotation displayName="Disk active time" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\% Disk Read Time"
<annotation displayName="Disk active read time" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\% Disk Write Time"
<annotation displayName="Disk active write time" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Transfers/sec"
sampleRate="PT15S" unit="CountPerSecond">
<annotation displayName="Disk operations" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Reads/sec"
<annotation displayName="Disk read operations" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Writes/sec"
<annotation displayName="Disk write operations" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Bytes/sec"
sampleRate="PT15S" unit="BytesPerSecond">
<annotation displayName="Disk speed" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Read Bytes/sec"
<annotation displayName="Disk read speed" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Disk Write Bytes/sec"
<annotation displayName="Disk write speed" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Avg. Disk Queue Length"
<annotation displayName="Disk average queue length" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Avg. Disk Read Queue
Length" sampleRate="PT15S" unit="Count">
<annotation displayName="Disk average read queue length" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\PhysicalDisk(_Total)\Avg. Disk Write Queue
Length" sampleRate="PT15S" unit="Count">
<annotation displayName="Disk average write queue length" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\LogicalDisk(_Total)\% Free Space"
<annotation displayName="Disk free space (percentage)" locale="en-us"/>
<PerformanceCounterConfiguration counterSpecifier="\LogicalDisk(_Total)\Free Megabytes"
<annotation displayName="Disk free space (MB)" locale="en-us"/>
</PerformanceCounters>
<Metrics resourceId="(Update with resource ID for the VM)" >
<MetricAggregation scheduledTransferPeriod="PT1H"/>
<MetricAggregation scheduledTransferPeriod="PT1M"/>
</Metrics>
<WindowsEventLog scheduledTransferPeriod="PT1M">
<DataSource name="Application!*[System[(Level = 1 or Level = 2)]]"/>
<DataSource name="Security!*[System[(Level = 1 or Level = 2)]"/>
<DataSource name="System!*[System[(Level = 1 or Level = 2)]]"/>
</WindowsEventLog>
</DiagnosticMonitorConfiguration>
</WadCfg>
<StorageAccount>(Update with diagnostics storage account name)</StorageAccount>
</PublicConfig>
Pasos siguientes
Para obtener orientación adicional sobre el uso de la funcionalidad Diagnósticos de Azure y otras técnicas para
solucionar problemas, consulte Habilitación de diagnósticos en Azure Cloud Services y Virtual Machines.
Esquema de configuración de diagnósticos se explican las distintas opciones de configuración XML para la
extensión de diagnósticos.
Uso de la supervisión y el diagnóstico con una máquina
virtual Windows y plantillas de Azure Resource Manager
La extensión Azure Diagnostics proporciona funcionalidades de supervisión y diagnóstico en una máquina virtual de Azure
basada en Windows. Para habilitar estas funcionalidades en la máquina virtual, incluya la extensión como parte de la plantilla de
Azure Resource Manager. Para obtener más información sobre cómo incluir cualquier extensión como parte de una plantilla de
máquina virtual, consulte Creación de plantillas del Administrador de recursos de Azure con extensiones de máquina virtual . En
este artículo se describe cómo agregar la extensión de Diagnósticos de Azure a una plantilla de máquina virtual de Windows.
Incorporación de la extensión de Diagnósticos de Azure a la definición de

recursos de máquina virtual
Para habilitar la extensión Diagnostics en una máquina virtual Windows, debe agregar la extensión como un recurso de máquina
virtual en la plantilla de Resource Manager.
En una máquina virtual sencilla basada en el Administrador de recursos, agregue la configuración de extensión a la matriz
resources de la máquina virtual:
"resources": [
{
"name": "Microsoft.Insights.VMDiagnosticsSettings",
"apiVersion": "2015-06-15",
"dependsOn": [
],
"tags": {
"displayName": "AzureDiagnostics"
},
"properties": {
"settings": {
"xmlCfg": "[base64(concat(variables('wadcfgxstart'), variables('wadmetricsresourceid'), variables('vmName'),
variables('wadcfgxend')))]",
"storageAccount": "[parameters('existingdiagnosticsStorageAccountName')]"
},
"storageAccountName": "[parameters('existingdiagnosticsStorageAccountName')]",
"storageAccountKey": "[listkeys(variables('accountid'), '2015-05-01-preview').key1]",
"storageAccountEndPoint": "https://core.windows.net"
}
}
}
]
Otra costumbre común es agregar la configuración de extensión en el nodo de recursos raíz de la plantilla en lugar de definirla
en el nodo de recursos de la máquina virtual. Con este enfoque tiene que especificar explícitamente una relación jerárquica entre
la extensión y la máquina virtual con los valores name y type. Por ejemplo:
"name": "[concat(variables('vmName'),'Microsoft.Insights.VMDiagnosticsSettings')]",
La extensión siempre se asocia a la máquina virtual y puede definirla directamente en el nodo de recursos de la máquina virtual
o en el nivel base y usar la convención de nomenclatura jerárquica para asociarla a la máquina virtual.
Para conjuntos de escala de máquina virtual, la configuración de extensión se especifica en la propiedad extensionProfile de
VirtualMachineProfile.
La propiedad publisher con el valor de Microsoft.Azure.Diagnostics y la propiedad type con el valor IaaSDiagnostics
identifican de forma única la extensión de Diagnósticos de Azure.
El valor de la propiedad name se puede usar para hacer referencia a la extensión en el grupo de recursos. Al establecerla
específicamente en Microsoft.Insights.VMDiagnosticsSettings es posible identificarla fácilmente mediante Azure Portal, lo
que garantiza que los gráficos de supervisión se muestren correctamente en Azure Portal.
typeHandlerVersion especifica la versión de la extensión que quiere usar. Establecer la versión secundaria de
autoUpgradeMinorVersion en true garantiza la obtención de la versión secundaria más reciente de la extensión que está
disponible. Se recomienda establecer siempre autoUpgradeMinorVersion en true para que siempre obtenga la extensión de
diagnósticos más reciente disponible con todas las nuevas características y soluciones de errores.
El elemento settings contiene propiedades de configuración de la extensión que se pueden establecer y leer de la extensión (lo
que se conoce en ocasiones como configuración pública). La propiedad xmlcfg contiene configuración basada en XML para los
registros de diagnóstico, los contadores de rendimiento, etc., que se recopilan con el agente de diagnóstico. Consulte Esquema
de configuración de diagnósticos para obtener más información sobre el propio esquema XML. Es una práctica común
almacenar la configuración XML real como una variable en la plantilla del Administrador de recursos de Azure y luego
concatenarla y codificarla como base64 para establecer el valor de xmlcfg. Consulte la sección sobre las variables de
configuración de diagnóstico para obtener más información sobre cómo almacenar el XML en variables. La propiedad
storageAccount especifica el nombre de la cuenta de almacenamiento a la que se transfieren los datos de diagnóstico.
Las propiedades de protectedSettings (conocida en ocasiones como configuración privada) se pueden establecer, pero no se
pueden leer después de que se han establecido. El carácter de solo escritura de protectedSettings hace que sea útil para
almacenar secretos, como la clave de la cuenta de almacenamiento donde se escriben los datos de diagnóstico.
Especificación de la cuenta de almacenamiento de diagnóstico como parámetro

El fragmento de código JSON de la extensión Diagnostics anterior presupone dos parámetros
existingdiagnosticsStorageAccountName y existingdiagnosticsStorageResourceGroup para especificar la cuenta de
almacenamiento de diagnóstico donde se almacenan los datos de diagnóstico. La especificación de la cuenta de almacenamiento
de diagnóstico como parámetro hace que sea fácil cambiarla entre distintos entornos; por ejemplo, puede que quiera usar una
cuenta de almacenamiento de diagnóstico diferente para prueba y otra para la implementación en producción.
"existingdiagnosticsStorageAccountName": {
"type": "string",
"metadata": {
"description": "The name of an existing storage account to which diagnostics data is transfered."
}
},
"existingdiagnosticsStorageResourceGroup": {
"type": "string",
"metadata": {
"description": "The resource group for the storage account specified in existingdiagnosticsStorageAccountName"
}
}
Resulta aconsejable especificar una cuenta de almacenamiento de diagnóstico en un grupo de recursos diferente al grupo de
recursos de la máquina virtual. Un grupo de recursos se puede considerar una unidad de implementación con su propio ciclo de
vida; una máquina virtual se puede implementar y volver a implementar a medida que se realizan nuevas actualizaciones de
configuraciones en ella, pero puede que quiera seguir almacenando los datos de diagnóstico en la misma cuenta de
almacenamiento en esas implementaciones de máquina virtual. Tener la cuenta de almacenamiento en un recurso diferente hace
posible que dicha cuenta acepte datos de varias implementaciones de máquina virtual, lo que facilita la solución de problemas
entre las distintas versiones.
NOTE
Si crea una plantilla de máquina virtual Windows desde Visual Studio, la cuenta de almacenamiento predeterminada se podría configurar
para usar la misma cuenta de almacenamiento en la que se carga la VHD de máquina virtual. Esto sirve para simplificar la configuración
inicial de la máquina virtual. Vuelva a factorizar la plantilla para usar una cuenta de almacenamiento diferente que se pueda pasar como un
parámetro.
variables de configuración de diagnóstico
El fragmento json de la extensión de diagnósticos anterior define una variable accountid para simplificar la obtención de la clave
de la cuenta de almacenamiento para el almacenamiento de diagnóstico:
"accountid": "[concat('/subscriptions/', subscription().subscriptionId,

'/resourceGroups/',parameters('existingdiagnosticsStorageResourceGroup'),
'/providers/','Microsoft.Storage/storageAccounts/', parameters('existingdiagnosticsStorageAccountName'))]"
La propiedad xmlcfg de la extensión de diagnósticos se define mediante diversas variables que se concatenan juntas. Los valores
de estas variables están en XML, así que se deben incluir correctamente entre secuencias de escape al definir las variables json.
El siguiente ejemplo describe el XML de configuración de diagnóstico que recopila contadores de rendimiento de nivel de
sistema estándar junto con algunos registros de eventos de Windows y registros de infraestructura de diagnóstico. Se ha
incluido correctamente entre secuencias de escape y se le ha dado el formato adecuado para que la configuración se pueda
pegar directamente en la sección de variables de su plantilla. Para obtener un ejemplo más claro para el usuario del XML de
configuración, consulte el Esquema de configuración de diagnósticos .
"wadlogs": "<WadCfg> <DiagnosticMonitorConfiguration overallQuotaInMB=\"4096\"
xmlns=\"http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration\"> <DiagnosticInfrastructureLogs
scheduledTransferLogLevelFilter=\"Error\"/> <WindowsEventLog scheduledTransferPeriod=\"PT1M\" > <DataSource
name=\"Application!*[System[(Level = 1 or Level = 2)]]\" /> <DataSource name=\"Security!*[System[(Level = 1 or Level =
2)]]\" /> <DataSource name=\"System!*[System[(Level = 1 or Level = 2)]]\" /></WindowsEventLog>",
"wadperfcounters1": "<PerformanceCounters scheduledTransferPeriod=\"PT1M\"><PerformanceCounterConfiguration
counterSpecifier=\"\\Processor(_Total)\\% Processor Time\" sampleRate=\"PT15S\" unit=\"Percent\"><annotation
displayName=\"CPU utilization\" locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\Processor(_Total)\\% Privileged Time\" sampleRate=\"PT15S\" unit=\"Percent\"><annotation
displayName=\"CPU privileged time\" locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\Processor(_Total)\\% User Time\" sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"CPU
user time\" locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\Processor Information(_Total)\\Processor Frequency\" sampleRate=\"PT15S\" unit=\"Count\"><annotation
displayName=\"CPU frequency\" locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\System\\Processes\" sampleRate=\"PT15S\" unit=\"Count\"><annotation displayName=\"Processes\"
locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\Process(_Total)\\Thread Count\" sampleRate=\"PT15S\" unit=\"Count\"><annotation displayName=\"Threads\"
locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration
counterSpecifier=\"\\Process(_Total)\\Handle Count\" sampleRate=\"PT15S\" unit=\"Count\"><annotation displayName=\"Handles\"
locale=\"en-us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\Memory\\%
Committed Bytes In Use\" sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"Memory usage\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\Memory\\Available Bytes\"
sampleRate=\"PT15S\" unit=\"Bytes\"><annotation displayName=\"Memory available\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\Memory\\Committed Bytes\"
sampleRate=\"PT15S\" unit=\"Bytes\"><annotation displayName=\"Memory committed\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\Memory\\Commit Limit\"
sampleRate=\"PT15S\" unit=\"Bytes\"><annotation displayName=\"Memory commit limit\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\% Disk Time\"
sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"Disk active time\" locale=\"en-us\"/>
</PerformanceCounterConfiguration>",
"wadperfcounters2": "<PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\% Disk Read Time\"
sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"Disk active read time\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\% Disk Write
Time\" sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"Disk active write time\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\Disk
Transfers/sec\" sampleRate=\"PT15S\" unit=\"CountPerSecond\"><annotation displayName=\"Disk operations\" locale=\"en-us\"/>
Reads/sec\" sampleRate=\"PT15S\" unit=\"CountPerSecond\"><annotation displayName=\"Disk read operations\" locale=\"en-us\"/>
Writes/sec\" sampleRate=\"PT15S\" unit=\"CountPerSecond\"><annotation displayName=\"Disk write operations\" locale=\"en-
us\"/></PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\Disk
Bytes/sec\" sampleRate=\"PT15S\" unit=\"BytesPerSecond\"><annotation displayName=\"Disk speed\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\Disk Read
Bytes/sec\" sampleRate=\"PT15S\" unit=\"BytesPerSecond\"><annotation displayName=\"Disk read speed\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\PhysicalDisk(_Total)\\Disk Write
Bytes/sec\" sampleRate=\"PT15S\" unit=\"BytesPerSecond\"><annotation displayName=\"Disk write speed\" locale=\"en-us\"/>
</PerformanceCounterConfiguration><PerformanceCounterConfiguration counterSpecifier=\"\\LogicalDisk(_Total)\\% Free Space\"
sampleRate=\"PT15S\" unit=\"Percent\"><annotation displayName=\"Disk free space (percentage)\" locale=\"en-us\"/>
</PerformanceCounterConfiguration></PerformanceCounters>",
"wadcfgxstart": "[concat(variables('wadlogs'), variables('wadperfcounters1'), variables('wadperfcounters2'), '<Metrics
resourceId=\"')]",
"wadmetricsresourceid": "[concat('/subscriptions/', subscription().subscriptionId, '/resourceGroups/', resourceGroup().name
, '/providers/', 'Microsoft.Compute/virtualMachines/')]",
"wadcfgxend": "\"><MetricAggregation scheduledTransferPeriod=\"PT1H\"/><MetricAggregation scheduledTransferPeriod=\"PT1M\"/>
</Metrics></DiagnosticMonitorConfiguration></WadCfg>"
El nodo de XML de definición de métricas de la configuración anterior es un elemento de configuración importante ya que
define cómo se agregarán y almacenarán los contadores de rendimiento definidos anteriormente en el XML en el nodo
PerformanceCounter.
IMPORTANT
Estas métricas dirigen los gráficos de supervisión y alertas en el Portal de Azure. El nodo Métricas con resourceID y MetricAggregation
deben incluirse en la configuración de diagnóstico para la máquina virtual si quiere ver los datos de supervisión de la máquina virtual en
Azure Portal.
A continuación se muestra un ejemplo del XML de las definiciones de métricas:

<Metrics
resourceId="/subscriptions/subscription().subscriptionId/resourceGroups/resourceGroup().name/providers/Microsoft.Compute/vir
tualMachines/vmName">
<MetricAggregation scheduledTransferPeriod="PT1H"/>
<MetricAggregation scheduledTransferPeriod="PT1M"/>
</Metrics>
El atributo resourceID identifica de forma única la máquina virtual de su suscripción. Asegúrese de usar las funciones
subscription() y resourceGroup() para que la plantilla actualice automáticamente esos valores en función de la suscripción y el
grupo de recursos en el que va a realizar la implementación.
Si va a crear varias máquinas virtuales en un bucle, tiene que rellenar el valor resourceID con una función copyIndex() para
diferenciar correctamente cada máquina virtual de forma individual. El valor xmlCfg se puede actualizar para admitir esto de la
manera siguiente:
"xmlCfg": "[base64(concat(variables('wadcfgxstart'), variables('wadmetricsresourceid'), concat(parameters('vmNamePrefix'),

copyindex()), variables('wadcfgxend')))]",
El valor MetricAggregation de PT1M y PT1H indica una agregación durante un minuto y una agregación durante una hora,
respectivamente.
Tablas de WADMetrics en almacenamiento

La configuración de métricas anterior genera tablas en la cuenta de almacenamiento de diagnóstico con las convenciones de
nomenclatura siguientes:
WADMetrics : prefijo estándar para todas las tablas WADMetrics.
PT1H o PT1M : significa que la tabla contiene datos agregados durante una hora o un minuto.
P10D : significa que la tabla contendrá datos de diez días de cuando la tabla comenzó a recopilar datos.
V2S : constante de cadena.
yyyymmdd : la fecha en la que la tabla comenzó a recopilar datos.
Ejemplo: WADMetricsPT1HP10DV2S20151108 contiene datos de métricas agregados durante una hora durante 10 días a partir
del 11 de noviembre de 2015.
Cada tabla WADMetrics contiene las columnas siguientes:
Par titionKey : la clave de partición se construye a partir del valor resourceID para identificar de forma única el recurso de
máquina virtual. Por ejemplo:
002Fsubscriptions:
<subscriptionID>:002FresourceGroups:002F<ResourceGroupName>:002Fproviders:002FMicrosoft:002ECompute:002FvirtualMachines:002F<vmName>
RowKey : sigue el formato <Descending time tick>:<Performance Counter Name> . El cálculo de la graduación de tiempo
descendente es igual a la graduación de tiempo máxima menos el tiempo de comienzo del período de agregación. Por
ejemplo, si el período de ejemplo empezó el 10 de noviembre de 2015 a las 00:00 horas UTC, entonces el cálculo sería:
DateTime.MaxValue.Ticks - (new DateTime(2015,11,10,0,0,0,DateTimeKind.Utc).Ticks) . Para el contador de rendimiento de
bytes de memoria disponible, la clave de fila será similar a: 2519551871999999999__:005CMemory:005CAvailable:0020Bytes
CounterName : nombre del contador de rendimiento. Coincide con el valor de counterSpecifier definido en el archivo de
configuración XML.
Maximum : el valor máximo del contador de rendimiento durante el período de agregación.
Mínimos : el valor mínimo del contador de rendimiento durante el período de agregación.
Total : la suma de todos los valores del contador de rendimiento notificados durante el período de agregación.
Recuento : el número total de valores notificados para el contador de rendimiento.
Average : el valor medio (total/count) del contador de rendimiento durante el período de agregación.
Pasos siguientes
Para obtener una plantilla de ejemplo de una máquina virtual Windows con la extensión Diagnostics, consulte 201-vm-
monitoring-diagnostics-extension.
Implemente la plantilla de Azure Resource Manager mediante Azure PowerShell o la línea de comandos de Azure.
Obtenga más información sobre la creación de plantillas del Administrador de recursos de Azure
Enviar métricas de SO invitado al almacén de
métricas de Azure Monitor con una plantilla de
Azure Resource Manager para una máquina virtual
Windows
Los datos de rendimiento del sistema operativo invitado de las máquinas virtuales de Azure no se recopilan
automáticamente como otras métricas de la plataforma. Instale la extensión de diagnósticos de Azure Monitor
para recopilar métricas del sistema operativo invitado en la base de datos de métricas, de modo que se pueda
usar con todas las características de métricas de Azure Monitor, incluidos alertas, gráficos, enrutamiento y acceso
casi en tiempo real de una API REST. En este artículo se describe el proceso de envío de métricas de rendimiento
del SO invitado para una máquina virtual Windows a la base de datos de métricas mediante una plantilla de
Resource Manager.
NOTE
Para obtener más información sobre la configuración de la extensión de diagnósticos para recopilar métricas del SO
invitado mediante Azure Portal, consulte Instalación y configuración de la extensión de Azure Diagnostics (WAD) para
Windows.
Si no está familiarizado con las plantillas de Resource Manager, obtenga información sobre las implementaciones
de plantilla y su estructura y sintaxis.
Prerrequisitos
La suscripción debe estar registrada en Microsoft.Insights.
Debe tener instalado Azure PowerShell o Azure Cloud Shell.
El recurso de máquina virtual debe estar en una región que admita métricas personalizadas.
Configuración de Azure Monitor como receptor de datos

La extensión Azure Diagnostics usa una característica denominada "receptores de datos" para enrutar las
métricas y los registros a distintas ubicaciones. En los pasos siguientes se muestra cómo usar una plantilla de
Resource Manager y PowerShell para implementar una VM con el nuevo receptor de datos "Azure Monitor".
Creación de una plantilla de Resource Manager

En este ejemplo, puede usar una plantilla de ejemplo disponible públicamente. Las plantillas iniciales se
encuentran en https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-simple-windows.
Azuredeploy.json es una plantilla de Resource Manager configurada previamente para la
implementación de una máquina virtual.
Azuredeploy.Parameters.json es un archivo de parámetros que almacena información como el nombre
de usuario y la contraseña que le gustaría establecer para la VM. Durante la implementación, la plantilla de
Resource Manager usa los parámetros establecidos en este archivo.
Descargue y guarde ambos archivos localmente.
Modificación de azuredeploy.parameters.json
Abra el archivo azuredeploy.parameters.json.
1. Especifique los valores de adminUsername y adminPassword para la VM. Estos parámetros se utilizan
para el acceso remoto a la VM. Para evitar el secuestro de la VM, NO use los valores de esta plantilla. Los
bots buscan por Internet los nombres de usuario y las contraseñas en repositorios públicos de GitHub. Es
probable que sean VM de prueba con estos valores predeterminados.
2. Cree un dnsname único para la VM.
Modificación de azuredeploy.json
Abra el archivo azuredeploy.json.
Agregue un identificador de cuenta de almacenamiento a la sección de variables de la plantilla después de la
entrada para storageAccountName .
// Find these lines.

"variables": {
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'sawinvm')]",
// Add this line directly below.

"accountid": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
Agregue esta extensión de Managed Service Identity (MSI) a la plantilla en la parte superior de la sección
resources . La extensión garantiza que Azure Monitor acepte las métricas que se emiten.
//Find this code.

"resources": [
// Add this code directly below.
{
"name": "[concat(variables('vmName'), '/', 'WADExtensionSetup')]",
"apiVersion": "2017-12-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]" ],
"properties": {
"settings": {
"port": 50342
}
}
},
Agregue la configuración de identity en el recurso de VM para asegurarse de que Azure asigne a la extensión
MSI una identidad del sistema. Este paso garantiza que la VM pueda emitir métricas de invitado sobre sí misma a
Azure Monitor.
// Find this section
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2017-03-30",
"name": "[variables('vmName')]",
// add these 3 lines below
"identity": {
"type": "SystemAssigned"
},
//end of added lines
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
...
Agregue la siguiente configuración para habilitar la extensión de diagnóstico en una máquina virtual Windows.
En una máquina virtual sencilla basada en Resource Manager, se puede agregar la configuración de extensión a la
matriz de recursos de la máquina virtual. La línea "sinks"— "AzMonSink" y la correspondiente "SinksConfig" más
adelante en la sección—permiten que la extensión emita métricas directamente a Azure Monitor. No dude en
agregar o quitar contadores de rendimiento según sea necesario.
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
},
//Start of section to add
"resources": [
{
"name": "[concat(variables('vmName'), '/', 'Microsoft.Insights.VMDiagnosticsSettings')]",
"apiVersion": "2017-12-01",
"dependsOn": [
],
"properties": {
"settings": {
"WadCfg": {
"WadCfg": {
},
"Directories": {
"IISLogs": {
"containerName": "wad-iis-logfiles"
},
"FailedRequestLogs": {
"containerName": "wad-failedrequestlogs"
}
},
"sinks": "AzMonSink",
{
"counterSpecifier": "\\Memory\\Available Bytes",
},
{
"counterSpecifier": "\\Memory\\% Committed Bytes In Use",
},
{
"counterSpecifier": "\\Memory\\Committed Bytes",
}
]
},
"DataSource": [
{
"name": "Application!*"
}
]
},
"Logs": {
}
},
"SinksConfig": {
"Sink": [
{
"name" : "AzMonSink",
"AzureMonitor" : {}
}
]
}
},
"StorageAccount": "[variables('storageAccountName')]"
},
"storageAccountName": "[variables('storageAccountName')]",
"storageAccountKey": "[listKeys(variables('accountid'),'2015-06-15').key1]",
"storageAccountEndPoint": "https://core.windows.net/"
}
}
}
]
//End of section to add
Guarde y cierre ambos archivos.

Implementación de la plantilla de Resource Manager
NOTE
Debe estar ejecutando la versión de la extensión 1.5 o superior de Azure Diagnostics Y tener la propiedad
autoUpgradeMinorVersion : establecida en "true" en la plantilla de Resource Manager. A continuación, Azure carga la
extensión adecuada cuando se inicia la VM. Si no tiene estas opciones en la plantilla, modifíquelas y vuelva a implementar la
plantilla.
Para implementar la plantilla de Resource Manager, se usa Azure PowerShell.

1. Inicie PowerShell.
2. Inicie sesión en Azure con Login-AzAccount .
3. Obtenga una lista de suscripciones con Get-AzSubscription .
4. Establezca la suscripción que se usa para crear o actualizar la máquina virtual en:
Select-AzSubscription -SubscriptionName "<Name of the subscription>"
5. Para crear un nuevo grupo de recursos para la VM que se está implementando, ejecute el comando
siguiente:
New-AzResourceGroup -Name "<Name of Resource Group>" -Location "<Azure Region>"
NOTE
Recuerde usar una región de Azure que esté habilitada para las métricas personalizadas.
6. Ejecute los comandos siguientes para implementar la máquina virtual mediante la plantilla de Resource
Manager.
NOTE
Si quiere actualizar una VM existente, simplemente agregue -Mode Incremental al final del comando siguiente.
New-AzResourceGroupDeployment -Name "<NameThisDeployment>" -ResourceGroupName "<Name of the Resource

Group>" -TemplateFile "<File path of your Resource Manager template>" -TemplateParameterFile "<File
path of your parameters file>"
7. Una vez que la implementación se realice correctamente, la máquina virtual debe estar en Azure Portal,
emitiendo métricas a Azure Monitor.
NOTE
Puede que surjan errores en torno al parámetro vmSkuSize seleccionado. Si ocurre, vuelva al archivo
azuredeploy.json y actualice el valor predeterminado del parámetro vmSkuSize. En este caso, se recomienda probar
"Standard_DS1_v2").
Gráfico de las métricas

1. Inicie sesión en el Portal de Azure.
3. En la página Monitor, seleccione Métricas .

5. En el menú desplegable de recursos, seleccione la VM que ha creado. Si no ha cambiado el nombre de la
plantilla, debe ser SimpleWinVM2.
6. En el menú desplegable de espacios de nombres, seleccione azure.vm.windows.guest .
7. En el menú desplegable de métricas, seleccione Memor y%Committed Bytes in Use (Memoria%Bytes
confirmados en uso).
Pasos siguientes
Enviar métricas de SO invitado al almacén de
métricas de Azure Monitor con una plantilla de
Azure Resource Manager para un conjunto de
escalado de máquinas virtuales de Windows
NOTE
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.
Mediante el uso de la extensión Windows Azure Diagnostics (WAD) de Azure Monitor, puede recopilar métricas y
registros del sistema operativo invitado (SO invitado) que se ejecuta como parte de una máquina virtual, servicio
en la nube, o clúster de Azure Service Fabric. La extensión puede enviar datos de telemetría a muchas ubicaciones
diferentes que aparecen en el artículo vinculado anteriormente.
En este artículo se describe el proceso de envío de métricas de rendimiento del SO invitado para un conjunto de
escalado de máquinas virtuales de Windows al almacén de datos de Azure Monitor. A partir de Windows Azure
Diagnostics versión 1.11, puede escribir las métricas directamente en el almacén de métricas de Azure Monitor,
donde ya se recopilan métricas de la plataforma estándar. Al almacenarlas en esta ubicación, se permite tener
acceso a las mismas acciones disponibles para las métricas de la plataforma. Las acciones incluyen la generación
de alertas casi en tiempo real, la creación de gráficos, el enrutamiento, el acceso desde la API REST y mucho más.
Anteriormente, la extensión Windows Azure Diagnostics se escribía en Azure Storage, pero no en el almacén de
datos de Azure Monitor.
Si no está familiarizado con las plantillas de Resource Manager, obtenga información sobre las implementaciones
de plantilla y su estructura y sintaxis.
Prerrequisitos
Debe tener instalado Azure PowerShell, o puede usar Azure CloudShell.
Configuración de Azure Monitor como receptor de datos

La extensión Azure Diagnostics usa una característica denominada receptores de datos para enrutar las
métricas y los registros a distintas ubicaciones. En los pasos siguientes se muestra cómo usar una plantilla de
Resource Manager y PowerShell para implementar una VM con el nuevo receptor de datos Azure Monitor.
Creación de una plantilla de Resource Manager

En este ejemplo, puede usar una plantilla de ejemplo disponible públicamente.
Azuredeploy.json es una plantilla de Resource Manager configurada previamente para la implementación
de un conjunto de escalado de máquinas virtuales.
Azuredeploy.Parameters.json es un archivo de parámetros que almacena información como el nombre
de usuario y la contraseña que quiere establecer para la VM. Durante la implementación, la plantilla de
Resource Manager usa los parámetros establecidos en este archivo.
Descargue y guarde ambos archivos localmente.
Modificación de azuredeploy.parameters.json
Abra el archivo azuredeploy.parameters.json :
Proporcione el objeto vmSKU que quiere implementar. Se recomienda Standard_D2_v3.
Especifique un valor de windowsOSVersion que le gustaría para el conjunto de escalado de máquinas
virtuales. Se recomienda 2016-Datacenter.
Asigne un nombre al recurso del conjunto de escalado de máquinas virtuales que se va a implementar con la
propiedad vmssName . Por ejemplo, VMSS-WAD-TEST .
Especifique el número de VM que quiere que se ejecuten en el conjunto de escalado de máquinas virtuales con
la propiedad instanceCount .
Especifique los valores de adminUsername y adminPassword para el conjunto de escalado de máquinas
virtuales. Estos parámetros se utilizan para el acceso remoto a las VM del conjunto de escalado. Para evitar el
secuestro de la VM, no use los valores de esta plantilla. Los bots buscan por Internet los nombres de usuario y
las contraseñas en repositorios públicos de GitHub. Es probable que sean VM de prueba con estos valores
predeterminados.
Modificación de azuredeploy.json
Abra el archivo azuredeploy.json .
Agregue una variable para retener la información de la cuenta de almacenamiento en la plantilla de Resource
Manager. Todos los registros p contadores de rendimiento especificados en el archivo de configuración de
diagnóstico se escriben en el almacén de métricas de Azure Monitor y en la cuenta de almacenamiento
especificada aquí:
"variables": {
//add this line
"storageAccountName": "[concat('storage', uniqueString(resourceGroup().id))]",
Busque la definición de·conjunto de escalado de máquinas virtuales en la sección de recursos y agregue la sección
identidad a la configuración. Esto adición garantiza que Azure le asigne una identidad del sistema. Este paso
también garantiza que las VM del conjunto de escalado puedan emitir métricas de invitado sobre sí mismas a
Azure Monitor.
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "[variables('namingInfix')]",
"apiVersion": "2017-03-30",
//add these lines below
"identity": {
},
//end of lines to add
En el recurso del conjunto de escalado de máquinas virtuales, busque la sección vir tualMachineProfile . Agregue
un nuevo perfil llamado extensionsProfile para administrar las extensiones.
En extensionProfile , agregue una nueva extensión a la plantilla, como se muestra en la sección VMSS-WAD-
extension . Esta sección es la extensión de identidades administradas para los recursos de Azure que garantiza que
Azure Monitor acepta las métricas que se emiten. El campo name puede contener cualquier nombre.
El código siguiente de la extensión MSI también agrega la extensión de diagnóstico y la configuración como
recurso de extensión al recurso del conjunto de escalado de máquinas virtuales. No dude en agregar o quitar
contadores de rendimiento según sea necesario:
"extensionProfile": {
"extensions": [
// BEGINNING of added code
// Managed identities for Azure resources
{
"name": "VMSS-WAD-extension",
"properties": {
"settings": {
"port": 50342
},
"protectedSettings": {}
}
},
// add diagnostic extension. (Remove this comment after pasting.)
{
"name": "[concat('VMDiagnosticsVmExt','_vmNodeType0Name')]",
"properties": {
"storageAccountName": "[variables('storageAccountName')]",
"storageAccountKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts',
variables('storageAccountName')),'2015-05-01-preview').key1]",
"storageAccountEndPoint": "https://core.windows.net/"
},
"settings": {
"WadCfg": {
"overallQuotaInMB": "50000",
"sinks": "AzMonSink",
{
"counterSpecifier": "\\Memory\\% Committed Bytes In Use",
},
{
"counterSpecifier": "\\Memory\\Available Bytes",
},
{
"counterSpecifier": "\\Memory\\Committed Bytes",
}
]
},
"EtwProviders": {
"EtwEventSourceProviderConfiguration": [
{
"provider": "Microsoft-ServiceFabric-Actors",
"scheduledTransferKeywordFilter": "1",
"DefaultEvents": {
"eventDestination": "ServiceFabricReliableActorEventTable"
}
},
{
"provider": "Microsoft-ServiceFabric-Services",
"DefaultEvents": {
"eventDestination":
"ServiceFabricReliableServiceEventTable"
}
}
],
"EtwManifestProviderConfiguration": [
{
"provider": "cbd93bc2-71e5-4566-b3a7-595d8eeca6e8",
"scheduledTransferLogLevelFilter": "Information",
"scheduledTransferKeywordFilter": "4611686018427387904",
"DefaultEvents": {
"eventDestination": "ServiceFabricSystemEventTable"
}
}
]
}
},
"SinksConfig": {
"Sink": [
{
"name": "AzMonSink",
"AzureMonitor": {}
}
]
}
},
"StorageAccount": "[variables('storageAccountName')]"
},
"typeHandlerVersion": "1.11"
}
}
]
}
}
}
},
//end of added code plus a few brackets. Be sure that the number and type of brackets match properly when
done.
{
"type": "Microsoft.Insights/autoscaleSettings",
...
Agregue dependsOn para la cuenta de almacenamiento a fin de asegurarse de que se cree en el orden correcto.
"dependsOn": [
"[concat('Microsoft.Network/loadBalancers/', variables('loadBalancerName'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
//add this line below
"[concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]"
Cree una cuenta de almacenamiento si aún no se ha creado ninguna en la plantilla.

"resources": [
// add this code
{
"name": "[variables('storageAccountName')]",
"properties": {
"accountType": "Standard_LRS"
}
},
// end added code
{
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
Guarde y cierre ambos archivos.
Implementación de la plantilla de Resource Manager

NOTE
Debe estar ejecutando la versión de la extensión 1.5 o superior de Azure Diagnostics y , A LA VEZ, tener la propiedad
autoUpgradeMinorVersion: establecida en true en la plantilla de Resource Manager. A continuación, Azure carga la
extensión adecuada cuando se inicia la VM. Si no tiene estas opciones en la plantilla, modifíquelas y vuelva a implementar la
plantilla.
Para implementar la plantilla de Resource Manager, se usa Azure PowerShell:

1. Inicie PowerShell.
2. Inicie sesión en Azure con Login-AzAccount .
3. Obtenga una lista de suscripciones con Get-AzSubscription .
4. Establezca la suscripción que va a crear o actualice la máquina virtual:
Select-AzSubscription -SubscriptionName "<Name of the subscription>"
5. Cree un nuevo grupo de recursos para la VM que se va a implementar. Ejecute el siguiente comando:
New-AzResourceGroup -Name "VMSSWADtestGrp" -Location "<Azure Region>"
NOTE
Recuerde usar una región de Azure que esté habilitada para las métricas personalizadas. Recuerde usar una región de
Azure que esté habilitada para las métricas personalizadas.
6. Ejecute los siguientes comandos para implementar la máquina virtual:
NOTE
Si quiere actualizar un conjunto de escalado existente, agregue -Mode Incremental al final del comando.
New-AzResourceGroupDeployment -Name "VMSSWADTest" -ResourceGroupName "VMSSWADtestGrp" -TemplateFile "
<File path of your azuredeploy.JSON file>" -TemplateParameterFile "<File path of your
azuredeploy.parameters.JSON file>"
7. Una vez realizada la implementación correctamente, debería ver el conjunto de escalado de máquinas
virtuales en Azure Portal. Debería emitir métricas a Azure Monitor.
NOTE
Puede que surjan errores en torno al parámetro vmSkuSize seleccionado. En ese caso, vuelva al archivo
azuredeploy.json y actualice el valor predeterminado del parámetro vmSkuSize . Le recomendamos que pruebe
Standard_DS1_v2 .
Gráfico de las métricas

3. En la página Monitor , seleccione Métricas .

5. En el menú desplegable del recurso, seleccione el conjunto de escalado de máquinas virtuales que creó.
7. En el menú desplegable de métricas, seleccione Memor y%Committed Bytes in Use (Memoria%Bytes
A continuación, también puede elegir usar las dimensiones en esta métrica para graficarla para una VM en
particular o para trazar cada VM del conjunto de escalado.
Pasos siguientes
Envío de métricas de SO invitado a la base de datos
de métricas de Azure Monitor para una máquina
virtual Windows (clásica)
NOTE
La extensión Diagnostics de Azure Monitor (conocida como "WAD" o "Diagnostics") le permite recopilar métricas y
registros del sistema operativo invitado (SO invitado) que se ejecuta como parte de un clúster de Service Fabric,
un servicio en la nube o una máquina virtual. La extensión puede enviar datos de telemetría a muchas ubicaciones
diferentes.
En este artículo se describe el proceso de envío de métricas de rendimiento del SO invitado para una máquina
virtual Windows (clásica) a la base de datos de métricas de Azure Monitor. A partir de Diagnostics versión 1.11,
puede escribir las métricas directamente en el almacén de métricas de Azure Monitor, donde ya se recopilan
métricas de la plataforma estándar.
Almacenarlas en esta ubicación permite acceder a las mismas acciones disponibles para las métricas de la
plataforma. Las acciones incluyen la generación de alertas casi en tiempo real, la creación de gráficos, el
enrutamiento, el acceso desde una API REST y mucho más. Anteriormente, la extensión Diagnostics se escribía en
Azure Storage, pero no en el almacén de datos de Azure Monitor.
El proceso descrito en este artículo solo funciona para máquinas virtuales clásicas que ejecutan el sistema
operativo Windows.
Requisitos previos
Debe ser administrador de servicios o administrador en su suscripción de Azure.
Creación de una máquina virtual clásica y una cuenta de

almacenamiento
1. Cree una máquina virtual clásica mediante Azure Portal.
2. Al crear esta máquina virtual, elija la opción para crear una nueva cuenta de almacenamiento clásica.
Usaremos esta cuenta de almacenamiento en pasos posteriores.
3. En Azure Portal, vaya a la hoja de recursos Cuentas de almacenamiento . Seleccione Claves y anote el
nombre y la clave de la cuenta de almacenamiento. Necesitará esta información en pasos posteriores.
Creación de una entidad de servicio

Cree una entidad de servicio en el inquilino de Azure Active Directory según las instrucciones que encontrará en
Creación de una entidad de servicio. Tenga en cuenta lo siguiente al realizar este proceso:
Asigne a esta aplicación permisos "Supervisión del publicador de métricas" para el recurso para el cual quiere
emitir métricas. Puede usar un grupo de recursos o una suscripción completa.
NOTE
La extensión Diagnostics usa la entidad de servicio para autenticarse en Azure Monitor y emitir métricas para la máquina
virtual clásica.
Creación de la configuración de la extensión Diagnostics

1. Prepare el archivo de configuración de la extensión Diagnostics. Este archivo determina qué registros y
contadores de rendimiento debe recopilar la extensión Diagnostics para la máquina virtual clásica. El
siguiente es un ejemplo:
<DiagnosticsConfiguration
xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="applicationInsights.errors">
<DiagnosticInfrastructureLogs scheduledTransferLogLevelFilter="Error" />
<Directories scheduledTransferPeriod="PT1M">
<IISLogs containerName="wad-iis-logfiles" />
<FailedRequestLogs containerName="wad-failedrequestlogs" />
</Directories>
<PerformanceCounterConfiguration counterSpecifier="\Processor(*)\% Processor Time"
sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available Bytes"
<PerformanceCounterConfiguration counterSpecifier="\Memory\Committed Bytes"
<PerformanceCounterConfiguration counterSpecifier="\Memory\% Committed Bytes"
<PerformanceCounterConfiguration counterSpecifier="\LogicalDisk(*)\Disk Read Bytes/sec"
<DataSource name="Application!*[System[(Level=1 or Level=2 or Level=3)]]" />
<DataSource name="Windows Azure!*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]" />
</WindowsEventLog>
<CrashDumps>
<CrashDumpConfiguration processName="WaIISHost.exe" />
<CrashDumpConfiguration processName="WaWorkerHost.exe" />
<CrashDumpConfiguration processName="w3wp.exe" />
</CrashDumps>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Error" />
<Metrics resourceId="/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.ClassicCompute/virtualMachines/MyClassi
cVM">
<MetricAggregation scheduledTransferPeriod="PT1M" />
<MetricAggregation scheduledTransferPeriod="PT1H" />
</Metrics>
<SinksConfig>
</SinksConfig>
</WadCfg>
<StorageAccount />
</PublicConfig>
<PrivateConfig xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<StorageAccount name="" endpoint="" />
</PrivateConfig>
<IsEnabled>true</IsEnabled>
</DiagnosticsConfiguration>
2. En la sección "SinksConfig" del archivo de diagnóstico, defina un nuevo receptor de Azure Monitor, de la
forma siguiente:
<SinksConfig>
<Sink name="AzMonSink">
<AzureMonitor>
<ResourceId>Provide the resource ID of your classic VM </ResourceId>
<Region>The region your VM is deployed in</Region>
</AzureMonitor>
</Sink>
</SinksConfig>
3. En la sección del archivo de configuración donde se enumera la lista de contadores de rendimiento que se
van a recopilar, enrute los contadores de rendimiento al receptor de Azure Monitor "AzMonSink".
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="AzMonSink">

...
4. En la configuración privada, defina la cuenta de Azure Monitor. A continuación, agregue la información de la

entidad de servicio que se usará para emitir métricas.
<AzureMonitorAccount>
<ServicePrincipalMeta>
<PrincipalId>clientId for your service principal</PrincipalId>
<Secret>client secret of your service principal</Secret>
</ServicePrincipalMeta>
</AzureMonitorAccount>
</PrivateConfig>
5. Guarde este archivo localmente.
Implementación de la extensión Diagnostics en el servicio en la nube

1. Inicie PowerShell e inicie sesión.
Login-AzAccount
2. Empiece por establecer el contexto en la máquina virtual clásica.
$VM = Get-AzureVM -ServiceName <VM’s Service_Name> -Name <VM Name>
3. Establezca el contexto de la cuenta de almacenamiento clásica que se creó con la VM.
$StorageContext = New-AzStorageContext -StorageAccountName <name of your storage account from earlier

steps> -storageaccountkey "<storage account key from earlier steps>"
4. Establezca la ruta de acceso del archivo de Diagnostics en una variable mediante el comando siguiente:
$diagconfig = “<path of the diagnostics configuration file with the Azure Monitor sink configured>”
5. Prepare la actualización de la máquina virtual clásica con el archivo de diagnóstico que tenga configurado
el receptor de Azure Monitor.
$VM_Update = Set-AzureVMDiagnosticsExtension -DiagnosticsConfigurationPath $diagconfig -VM $VM -

StorageContext $Storage_Context
6. Implemente la actualización en la máquina virtual; para ello, ejecute el comando siguiente:
Update-AzureVM -ServiceName "ClassicVMWAD7216" -Name "ClassicVMWAD" -VM $VM_Update.VM

NOTE
Sigue siendo obligatorio proporcionar una cuenta de almacenamiento como parte de la instalación de la extensión
Diagnostics. Todos los registros o contadores de rendimiento especificados en el archivo de configuración de Diagnostics se
escribirán en la cuenta de almacenamiento especificada.
Trazado de métricas en Azure Portal

3. En la hoja Monitor , seleccione Métricas .
4. En la lista desplegable de recursos, seleccione la máquina virtual clásica.

6. En el menú desplegable de métricas, seleccione Memor y\Committed Bytes in Use (Memoria\bytes
Pasos siguientes
Envío de métricas de SO invitado al almacén de
métricas de Azure Monitor en Cloud Services clásico
NOTE
Con la extensión Diagnostics de Azure Monitor, puede recopilar métricas y registros del sistema operativo invitado
(SO invitado) que se ejecuta como parte de un clúster de Service Fabric, un servicio en la nube o una máquina
virtual. La extensión puede enviar datos de telemetría a muchas ubicaciones diferentes.
En este artículo se describe el proceso de envío de métricas de rendimiento del SO invitado para Cloud Services
clásico de Azure al almacén de métricas de Azure Monitor. A partir de Diagnostics versión 1.11, puede escribir las
métricas directamente en el almacén de métricas de Azure Monitor, donde ya se recopilan métricas de la
plataforma estándar.
Almacenarlas en esta ubicación permite tener acceso a las mismas acciones disponibles para las métricas de la
plataforma. Las acciones incluyen la generación de alertas casi en tiempo real, la creación de gráficos, el
enrutamiento, el acceso desde una API REST y mucho más. Anteriormente, la extensión Diagnostics se escribía en
Azure Storage, pero no en el almacén de datos de Azure Monitor.
El proceso descrito en este artículo solo funciona para los contadores de rendimiento en Azure Cloud Services. No
funciona para otras métricas personalizadas.
Requisitos previos
Debe ser administrador de servicios o administrador en su suscripción de Azure.
Su servicio en la nube debe estar en una región que admita métricas personalizadas.
Aprovisionamiento de un servicio en la nube y una cuenta de

almacenamiento
1. Cree e implemente un servicio en la nube clásico. Una aplicación de ejemplo de Cloud Services clásico y su
implementación pueden encontrarse en Introducción a Azure Cloud Services y ASP.NET.
2. Puede usar una cuenta de almacenamiento existente o implementar una nueva. Es mejor si la cuenta de
almacenamiento se encuentra en la misma región que el servicio en la nube clásico que ha creado. En Azure
Portal, vaya a la hoja de recursos Cuentas de almacenamiento y, después, seleccione Claves . Anote el
nombre y la clave de la cuenta de almacenamiento. Necesitará esta información en pasos posteriores.
Creación de una entidad de servicio
Cree una entidad de servicio en su inquilino de Azure Active Directory siguiendo las instrucciones de Uso del
portal para crear una aplicación de Azure Active Directory y una entidad de servicio con acceso a los recursos.
Tenga en cuenta lo siguiente al realizar este proceso:
Puede colocar cualquier dirección URL como dirección URL de inicio de sesión.
Asigne los permisos Supervisión del publicador de métricas a la aplicación que creó en el paso anterior para el
recurso frente al cual quiere emitir métricas. Si va a usar la aplicación para emitir métricas personalizadas frente a
muchos recursos, puede conceder estos permisos en el nivel de suscripción o de grupo de recursos.
NOTE
La extensión Diagnostics usa la entidad de servicio para autenticarse en Azure Monitor y emitir métricas para su servicio en
la nube.
Creación de la configuración de la extensión Diagnostics

Prepare el archivo de configuración de la extensión Diagnostics. Este archivo determina qué registros y contadores
de rendimiento debe recopilar la extensión Diagnostics para el servicio en la nube. A continuación encontrará un
ejemplo de archivo de configuración de Diagnostics:
<DiagnosticsConfiguration
xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration">
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096">
<DiagnosticInfrastructureLogs scheduledTransferLogLevelFilter="Error" />
<Directories scheduledTransferPeriod="PT1M">
<IISLogs containerName="wad-iis-logfiles" />
<FailedRequestLogs containerName="wad-failedrequestlogs" />
</Directories>
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Committed Bytes" sampleRate="PT15S" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Page Faults/sec" sampleRate="PT15S" />
<DataSource name="Application!*[System[(Level=1 or Level=2 or Level=3)]]" />
<DataSource name="Windows Azure!*[System[(Level=1 or Level=2 or Level=3 or Level=4)]]" />
</WindowsEventLog>
<CrashDumps>
<CrashDumpConfiguration processName="WaIISHost.exe" />
<CrashDumpConfiguration processName="WaWorkerHost.exe" />
<CrashDumpConfiguration processName="w3wp.exe" />
</CrashDumps>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Error" />
<SinksConfig>
</SinksConfig>
</WadCfg>
<StorageAccount />
</PublicConfig>
</PrivateConfig>
</DiagnosticsConfiguration>
En la sección "SinksConfig" del archivo de diagnóstico, defina un nuevo receptor de Azure Monitor:
<SinksConfig>
<Sink name="AzMonSink">
<AzureMonitor>
<ResourceId>-Provide ClassicCloudService’s Resource ID-</ResourceId>
<Region>-Azure Region your Cloud Service is deployed in-</Region>
</AzureMonitor>
</Sink>
</SinksConfig>
En la sección del archivo de configuración donde se enumeran los contadores de rendimiento que se van a
recopilar, agregue el receptor de Azure Monitor. Esta entrada garantiza que todos los contadores de rendimiento
especificados se enruten a Azure Monitor como métricas. Puede agregar o quitar contadores de rendimiento
según sus necesidades.
<PerformanceCounters scheduledTransferPeriod="PT1M" sinks="AzMonSink">

...
Por último, en la configuración privada, agregue la sección Azure Monitor Account (Cuenta de Azure Monitor).
Escriba el identificador de cliente y el secreto de la entidad de servicio que creó antes.
<AzureMonitorAccount>
<ServicePrincipalMeta>
<PrincipalId>clientId from step 3</PrincipalId>
<Secret>client secret from step 3</Secret>
</ServicePrincipalMeta>
</AzureMonitorAccount>
</PrivateConfig>
Guarde este archivo de diagnóstico localmente.
Implementación de la extensión Diagnostics en el servicio en la nube

Inicie PowerShell e inicie sesión en Azure.
Login-AzAccount
Use los siguientes comandos para almacenar los detalles de la cuenta de almacenamiento que creó anteriormente.
$storage_account = <name of your storage account from step 3>

$storage_keys = <storage account key from step 3>
De igual modo, establezca la ruta de acceso del archivo de diagnóstico en una variable mediante el comando
siguiente:
$diagconfig = “<path of the Diagnostics configuration file with the Azure Monitor sink configured>”
Implemente la extensión Diagnostics en el servicio en la nube con el archivo de diagnóstico y el receptor de Azure
Monitor configurado mediante el siguiente comando:
Set-AzureServiceDiagnosticsExtension -ServiceName <classicCloudServiceName> -StorageAccountName

$storage_account -StorageAccountKey $storage_keys -DiagnosticsConfigurationPath $diagconfig
NOTE
Sigue siendo obligatorio proporcionar una cuenta de almacenamiento como parte de la instalación de la extensión
Diagnostics. Todos los registros o contadores de rendimiento especificados en el archivo de configuración de diagnóstico se
escribirán en la cuenta de almacenamiento especificada.
Trazado de métricas en Azure Portal

3. En la hoja Monitor , seleccione la pestaña Métricas (versión preliminar) .
4. En la lista desplegable de recursos, seleccione el servicio en la nube clásico.
6. En el menú desplegable de métricas, seleccione Memor y\Committed Bytes in Use (Memoria\bytes
Puede usar las funcionalidades de división y de filtrado de dimensiones para ver la memoria total utilizada por un
rol específico y cada instancia de rol.
Pasos siguientes
Envío de datos de Windows Azure Diagnostics
Extension a Azure Event Hubs
operativo invitado y de las cargas de trabajo de las máquinas virtuales de Azure y de otros recursos de proceso.
En este artículo, se explica cómo puede enviar datos desde Windows Azure Diagnostic Extension (WAD) a Azure
Event Hubs para reenviarlos después fuera de Azure.
Datos admitidos
Los datos recopilados del sistema operativo invitado que pueden enviarse a Event Hubs son los siguientes.
Otros orígenes de datos recopilados por WAD, como los volcados de memoria y los registros de IIS, no se
pueden enviar a Event Hubs.
Eventos de Seguimiento de eventos para Windows (ETW)
Registros de eventos de Windows, incluidos los registros de aplicaciones en el registro de eventos de
Windows
Registros de infraestructura de diagnóstico de Azure
Requisitos previos
Windows Diagnostics Extension 1.6 o versiones posteriores. Consulte el historial de versiones en Historial y
versiones de esquemas de configuración de Azure Diagnostics Extension y los recursos admitidos en la
introducción a Azure Diagnostics Extension.
Siempre debe aprovisionarse un espacio de nombres de Event Hubs. Consulte la introducción a Event Hubs
para más información.
Esquema de configuración
Consulte las diferentes opciones para habilitar y configurar Diagnostics Extension en Instalación y configuración
de Windows Azure Diagnostics Extension (WAD) y una referencia del esquema de configuración en Esquema de
configuración de Azure Diagnostics. De aquí hasta el final del artículo, se describe cómo se utiliza esta
configuración para enviar datos a un centro de eventos.
Azure Diagnostics siempre envía registros y métricas a una cuenta de Azure Storage. Puede configurar uno o
varios receptores de datos para enviar datos a otros destinos. Cada receptor de datos se define en el elemento
SinksConfig de la configuración pública con información confidencial en la configuración privada. Esta
configuración de los centros de eventos utiliza los valores de la tabla siguiente.
Nombre Nombre descriptivo del receptor. Se utiliza en la

configuración para especificar qué orígenes de datos van a
enviar información al receptor.
Url Dirección URL del centro de eventos con el formato <event-

hubs-namespace>.servicebus.windows.net/<event-hub-
name>.
SharedAccessKeyName Nombre de la directiva de acceso compartido del centro de

eventos que tiene, como mínimo, el permiso Enviar .
SharedAccessKey Clave principal o secundaria de la directiva de acceso

compartido del centro de eventos.
A continuación, se incluyen ejemplos de la configuración pública y privada. Se trata de una configuración

mínima con un solo contador de rendimiento y un solo registro de eventos que ilustra cómo se configura y
utiliza el receptor de datos del centro de eventos. Puede ver un ejemplo más complejo en Esquema de
configuración de Azure Diagnostics.
Configuración pública
{
"WadCfg": {
"sinks": "myEventHub",
{
"sampleRate": "PT3M"
}
]
},
"sinks": "myEventHub",
"DataSource": [
{
}
]
}
},
"SinksConfig": {
"Sink": [
{
"name": "myEventHub",
"EventHub": {
"Url": "https://diags-mycompany-ns.servicebus.windows.net/diageventhub",
"SharedAccessKeyName": "SendRule"
}
}
]
}
},
}
Configuración privada
{
"storageAccountKey": "{base64 encoded key}",
"storageAccountEndPoint": "https://core.windows.net",
"EventHub": {
"Url": "https://diags-mycompany-ns.servicebus.windows.net/diageventhub",
"SharedAccessKeyName": "SendRule",
"SharedAccessKey": "{base64 encoded key}"
}
}
Para enviar datos a un receptor de datos, debe especificar el atributo sinks en el nodo del origen de datos. El
lugar en el que incluya el atributo sinks determinará el ámbito de la asignación. En el ejemplo siguiente, el
atributo sinks está definido en el nodo PerformanceCounters , lo que hará que todos los contadores de
rendimiento secundarios se envíen al centro de eventos.
"sinks": "MyEventHub",
{
},
{
"counterSpecifier": "\\Memory\\Available MBytes",
},
{
"counterSpecifier": "\\Web Service(_Total)\\ISAPI Extension Requests/sec",
}
]
}
En el ejemplo siguiente, el atributo sinks se aplica directamente a tres contadores, por lo que solo se enviarán
estos contadores de rendimiento al centro de eventos.
{
"sinks": "MyEventHub"
},
{
},
{
"counterSpecifier": "\\Web Service(_Total)\\ISAPI Extension Requests/sec",
},
{
"counterSpecifier": "\\ASP.NET\\Requests Rejected",
},
{
"counterSpecifier": "\\ASP.NET\\Requests Queued",
}
]
}
Validación de la configuración
Puede utilizar diferentes métodos para comprobar que los datos se están enviando al centro de eventos. El
método más sencillo es utilizar una captura de Event Hubs, tal y como se describe en Captura de eventos a
través de Azure Event Hubs en Azure Blob Storage o Azure Data Lake Storage.
Solución de problemas con los receptores de Event Hubs

Consulte la tabla WADDiagnosticInfrastructureLogsTable de Azure Storage, que contiene registros y
errores de Azure Diagnostics. Una opción es usar una herramienta como el Explorador de Azure Storage
para conectarse a esta cuenta de almacenamiento, ver esta tabla y agregar una consulta para TimeStamp
en las últimas 24 horas. Puede usar la herramienta para exportar un archivo .csv y abrirlo en una
aplicación como Microsoft Excel. Excel facilita la búsqueda de cadenas de tarjeta de llamadas, como
EventHubs , para ver qué error se notifica.
Compruebe que el centro de eventos esté correctamente aprovisionado. Toda la información de conexión
de la sección PrivateConfig de la configuración debe coincidir con los valores del recurso que se
muestran en el portal. No olvide que debe tener una directiva SAS definida (en este ejemplo es
SendRule) en el portal y que debe haberse concedido el permiso Enviar.
Pasos siguientes
Información general de Event Hubs
Creación de un centro de eventos
Preguntas más frecuentes sobre Event Hubs
Recopilación de datos de Azure Diagnostics
Extension en los registros de Azure Monitor
operativo invitado de los recursos de proceso de Azure, incluidas las máquinas virtuales. En este artículo, se
explica cómo se recopilan los datos obtenidos por la extensión de diagnóstico de Azure Storage en los registros
de Azure Monitor.
NOTE
Por lo general, el agente de Log Analytics de Azure Monitor es el mecanismo preferido para recopilar datos del sistema
operativo invitado en registros de Azure Monitor. Consulte Introducción a los agentes de Azure Monitor para ver una
comparativa detallada de los agentes.
Tipos de datos admitidos

Azure Diagnostics Extension almacena los datos en una cuenta de Azure Storage. Para que los registros de Azure
Monitor recopilen estos datos, deben estar en las siguientes ubicaciones:
T IP O DE REGIST RO T IP O DE REC URSO LO C AT IO N
Registros IIS Virtual Machines wad-iis-logfiles (Blob Storage)

Roles web
Roles de trabajo
syslog Virtual Machines LinuxsyslogVer2v0 (Table Storage)
Eventos operativos de Service Fabric Nodos de Service Fabric WADServiceFabricSystemEventTable
Service Fabric Reliable Actor Events Nodos de Service Fabric WADServiceFabricReliableActorEventTa

ble
Service Fabric Reliable Service Events Nodos de Service Fabric WADServiceFabricReliableServiceEventT

able
Registros de eventos de Windows Nodos de Service Fabric WADWindowsEventLogsTable (Table

Virtual Machines Storage)
Roles web
Roles de trabajo
Registros de ETW de Windows Nodos de Service Fabric WADETWEventTable (Table Storage)

Virtual Machines
Roles web
Roles de trabajo
Tipos de datos no admitidos

Datos de rendimiento del sistema operativo invitado
Registros de IIS procedentes de sitios web de Azure
Habilitación de Azure Diagnostics Extension
Consulte el artículo Instalación y configuración de Windows Azure Diagnostics Extension (WAD) y Uso de la
extensión Diagnostics de Linux para supervisar métricas y registros si necesita más información sobre la
instalación y configuración de Diagnostics Extension. De este modo, podrá especificar la cuenta de
almacenamiento y configurar la colección de datos que desea reenviar a los registros de Azure Monitor.
Recopilación de registros de Azure Storage

Utilice el procedimiento siguiente para habilitar la recopilación de datos de Diagnostics Extension desde una
cuenta de Azure Storage:
1. En Azure Portal, vaya a las Áreas de trabajo de Log Analytics y seleccione su área de trabajo.
2. Haga clic en Registros de las cuentas de almacenamiento en la sección Orígenes de datos del área
de trabajo del menú.
3. Haga clic en Agregar .
4. En Cuenta de almacenamiento , seleccione la cuenta de almacenamiento que contenga los datos que desea
recopilar.
5. En Tipos de datos , seleccione el tipo de datos que desea recopilar.
6. El valor de Origen se rellenará automáticamente en función del tipo de datos elegido.
7. Haga clic en Aceptar para guardar la configuración.
8. Repita la operación con los demás tipos de datos.
En aproximadamente 30 minutos podrá ver los datos de la cuenta de almacenamiento en el área de trabajo de
Log Analytics. Solo verá los datos que se escriban en el almacenamiento de una vez aplicada la configuración. El
área de trabajo no lee los datos preexistentes de la cuenta de almacenamiento.
NOTE
El portal no valida si el origen existe en la cuenta de almacenamiento ni si se escriben nuevos datos.
Pasos siguientes
Recopilación de registros y métricas de los servicios de Azure para los servicios compatibles de Azure.
Incorporación de soluciones de Log Analytics desde la galería de soluciones para más información sobre los
datos.
Búsquedas de registros en Log Analytics para analizar los datos.
Envío de datos de diagnóstico de Cloud Services,
Virtual Machines o Service Fabric a Application
Insights
Cloud Services, Virtual Machines, los conjuntos de escalado de máquinas virtuales y Service Fabric usan la
extensión Azure Diagnostics para recopilar datos. Esta extensión envía los datos a las tablas de Azure Storage.
Sin embargo, también puede canalizar todos los datos o un subconjunto de ellos a otras ubicaciones mediante
la versión 1.5 o una posterior de la extensión Azure Diagnostics.
En este artículo se describe cómo enviar datos de la extensión Azure Diagnostics a Application Insights.
Explicación de la configuración de Diagnostics

La versión 1.5 de la extensión Azure Diagnostics introdujo los receptores, que son más ubicaciones donde
puede enviar datos de diagnóstico.
Ejemplo de configuración de un receptor para Application Insights:
<SinksConfig>
<Sink name="ApplicationInsights">
<ApplicationInsights>{Insert InstrumentationKey}</ApplicationInsights>
<Channels>
<Channel logLevel="Error" name="MyTopDiagData" />
<Channel logLevel="Verbose" name="MyLogData" />
</Channels>
</Sink>
</SinksConfig>
"SinksConfig": {
"Sink": [
{
"name": "ApplicationInsights",
"ApplicationInsights": "{Insert InstrumentationKey}",
"Channels": {
"Channel": [
{
"logLevel": "Error",
"name": "MyTopDiagData"
},
{
"name": "MyLogData"
}
]
}
}
]
}
El atributo name del receptor es un valor de cadena que identifica de forma única el receptor.
El elemento ApplicationInsights especifica la clave de instrumentación del recurso de Application
Insights donde se enviarán los datos de Azure Diagnostics.
Si no tiene un recurso existente de Application Insights, consulte Creación de recursos en Application
Insights para más información sobre cómo crear un recurso y obtener la clave de instrumentación.
Si está desarrollando un servicio en la nube con Azure SDK 2.8 y versiones posteriores, se rellena
automáticamente esta clave de instrumentación. El valor se basa en la configuración de servicio
APPINSIGHTS_INSTRUMENTATIONKEY al empaquetar el proyecto de Cloud Services. Consulte
Usar Application Insights con Cloud Services.
El elemento Channels contiene uno o varios elementos Channel .
El atributo name identifica de forma única el atributo a ese canal.
Con el atributo loglevel se puede especificar el nivel de registro que permitirá el canal. Estos son los
niveles de registro disponibles, en orden de más a menos información:
Verbose
Information
Advertencia
Error
Crítico
El canal actúa como filtro y permite seleccionar los niveles de registro específicos que enviar al receptor. Por
ejemplo, podría recopilar registros detallados y enviarlos al almacenamiento, pero solo se envían los errores al
receptor.
En el gráfico siguiente se muestra esta relación.
El gráfico siguiente resume los valores de configuración y cómo funcionan. Puede incluir varios receptores en
la configuración en distintos niveles de la jerarquía. El receptor del nivel superior de la jerarquía actúa como
una configuración global y el especificado en los elementos individuales como una invalidación de esa
configuración global.
Ejemplo completo de configuración de receptor
Este es un ejemplo completo del archivo de configuración público que
1. envía todos los errores a Application Insights (se especifica en el nodo
DiagnosticMonitorConfiguration ).
2. Además, envía los registros de aplicación detallados (se especifica en el nodo Logs ).
<WadCfg>
<DiagnosticMonitorConfiguration overallQuotaInMB="4096"
sinks="ApplicationInsights.MyTopDiagData"> 
<DiagnosticInfrastructureLogs />
<PerformanceCounters>
sampleRate="PT3M" />
<PerformanceCounterConfiguration counterSpecifier="\Memory\Available MBytes" sampleRate="PT3M" />
<DataSource name="Application!*" />
</WindowsEventLog>
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose"
sinks="ApplicationInsights.MyLogData"/> 
<SinksConfig>
<Sink name="ApplicationInsights">
<ApplicationInsights>{Insert InstrumentationKey}</ApplicationInsights>
<Channels>
<Channel logLevel="Error" name="MyTopDiagData" />
<Channel logLevel="Verbose" name="MyLogData" />
</Channels>
</Sink>
</SinksConfig>
</WadCfg>
"WadCfg": {
"sinks": "ApplicationInsights.MyTopDiagData", "_comment": "All info below sent to this channel",
},
{
},
{
}
]
},
"DataSource": [
{
"name": "Application!*"
}
]
},
"Logs": {
"scheduledTransferLogLevelFilter": "Verbose",
"sinks": "ApplicationInsights.MyLogData", "_comment": "This specific info sent to this channel"
}
},
"SinksConfig": {
"Sink": [
{
"name": "ApplicationInsights",
"ApplicationInsights": "{Insert InstrumentationKey}",
"Channels": {
"Channel": [
{
"name": "MyTopDiagData"
},
{
"logLevel": "Verbose",
"name": "MyLogData"
}
]
}
}
]
}
}
En la configuración anterior, las líneas siguientes tienen estos significados:

Envía todos los datos que recopila Azure Diagnostics.
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="ApplicationInsights">

"sinks": "ApplicationInsights",
}
Envía solo los registros de errores al receptor de Application Insights.
<DiagnosticMonitorConfiguration overallQuotaInMB="4096" sinks="ApplicationInsights.MyTopDiagdata">
"sinks": "ApplicationInsights.MyTopDiagData",
}
Envía los registros de aplicación detallados a Application Insights.
<Logs scheduledTransferPeriod="PT1M" scheduledTransferLogLevelFilter="Verbose"

sinks="ApplicationInsights.MyLogData"/>
"sinks": "ApplicationInsights.MyLogData",
}
Limitaciones
Channels solo registra el tipo de registro y no los contadores de rendimiento. Si especifica un
canal con un elemento de contador de rendimiento, se pasará por alto.
El nivel de registro de un canal no puede superar el nivel de registro de lo que va a recopilar
con Azure Diagnostics. Por ejemplo, no puede recopilar errores de registro de aplicación del elemento
Logs y tratar de enviar registros detallados al receptor de Application Insights. El atributo
scheduledTransferLogLevelFilter debe recopilar siempre un número de registros igual o superior a los
registros que intenta enviar a un receptor.
No puede enviar datos de blob recopilados mediante la extensión Azure Diagnostics a
Application Insights. Por ejemplo, nada de lo especificado en el nodo Directories. En el caso de volcados
de memoria, el volcado real se sigue enviando al almacenamiento de blobs y solo se transmitirá a
Application Insights una notificación de que el volcado de memoria se ha generado.
Pasos siguientes
Obtenga información sobre cómo ver información de Azure Diagnostics en Application Insights.
Use PowerShell para habilitar la extensión de diagnósticos de Azure en su aplicación.
Use Visual Studio para habilitar la extensión de Diagnósticos de Azure en su aplicación
Historial y versiones del esquema de configuración
de Windows Azure Diagnostics (WAD) Extension
En este artículo, puede consultar el historial de versiones del esquema de Azure Diagnostics Extension para
Windows (WAD) que se incluye en el SDK de Microsoft Azure.
Gráfico de envío de las versiones de Azure Diagnostics y de Azure SDK

VERSIÓ N DE L A EXT EN SIÓ N
VERSIÓ N DEL SDK DE A Z URE DIA GN O ST IC S M O DELO
1.x 1.0 complemento
2.0 - 2.4 1.0 complemento
2.5 1.2 extensión
2.6 1.3 "
2.7 1.4 "
2.8 1.5 "
2.9 1.6 "
2.96 1.7 "
2.96 1.8 "
2.96 1.8.1 "
2.96 1.9 "
2.96 1.11 "
La versión 1.0 de Azure Diagnostics se incluyó por primera vez en un modelo de complemento, lo que significa
que, al instalar Azure SDK, obtuvo la versión de Azure Diagnostics que se incluía con el producto.
A partir de SDK 2.5 (versión 1.2 de Diagnósticos), Diagnósticos de Azure pasó a un modelo de extensión. Las
herramientas para usar las características nuevas solo estaban disponibles en las versiones más recientes de Azure
SDK, pero cualquier servicio que use Azure Diagnostics seleccionaría la versión de envío más reciente
directamente desde Azure. Por ejemplo, cualquier usuario que siga usando SDK 2.5 estaría cargando la versión
más reciente que se muestra en la tabla anterior, sin importar si usan las características más recientes.
Índice de esquemas
Las distintas versiones de Azure Diagnostics utilizan esquemas de configuración diferentes. Los esquemas 1.0 y
1.2 están en desuso. Para más información sobre la versión 1.3 y versiones posteriores, consulte Esquema de
configuración de Diagnostics 1.3 y versiones posteriores.
Historial de versiones
Extensión Diagnostics 1.11
Incorporación de compatibilidad con el receptor de Azure Monitor. Este receptor solo se puede aplicar a los
contadores de rendimiento. Permite el envío a Azure Monitor de los contadores de rendimiento recopilados en la
máquina virtual, VMSS o en el servicio en la nube como métricas personalizadas. El receptor de Azure Monitor
admite:
La recuperación de todos los contadores de rendimiento que se envían a Azure Monitor a través de las API de
Las alertas de todos los contadores de rendimiento que se envían a Azure Monitor a través de la nueva
experiencia unificada de alertas de Azure Monitor.
El tratamiento del operador comodín de los contadores de rendimiento como la dimensión "Instancia" de la
métrica. Por ejemplo, si recopiló el contador de "LogicalDisk(*)/DiskWrites/sec", debería poder filtrar y dividir
en la dimensión "Instancia" para el trazado o una alerta en las escrituras en disco/s para cada disco lógico (C:,
D:, etc.).
Definición de Azure Monitor como un receptor nuevo de la configuración de la extensión Diagnostics
"SinksConfig": {
"Sink": [
{
"name": "AzureMonitorSink",
"AzureMonitor": {}
},
]
}
<SinksConfig>
<Sink name="AzureMonitorSink">
<AzureMonitor/>
</Sink>
</SinksConfig>
NOTE
La configuración del receptor de Azure Monitor para las máquinas virtuales clásicas y el servicio en la nube clásica requiere
que se definan más parámetros en la configuración privada de la extensión Diagnostics.
Para obtener más información, consulte la documentación detallada del esquema de extensión Diagnostics.
A continuación, puede configurar los contadores de rendimiento para enrutarlos para el receptor de Azure
Monitor.
"sinks": "AzureMonitorSink",
{
"unit": "percent"
}
]
},
<PerformanceCounters scheduledTransferPeriod="PT1M", sinks="AzureMonitorSink">

<PerformanceCounterConfiguration counterSpecifier="\Processor(_Total)\% Processor Time" sampleRate="PT1M"
unit="percent" />

Se agregó compatibilidad con Docker.
Extensión Diagnostics 1.8.1
Puede especificar un token de SAS en lugar de una clave de cuenta de almacenamiento en la configuración
privada. Si se proporciona un token de SAS, se omite la clave de cuenta de almacenamiento.
{
"storageAccountName": "diagstorageaccount",
"storageAccountEndPoint": "https://core.windows.net",
"storageAccountSasToken": "{sas token}",
"SecondaryStorageAccounts": {
"StorageAccount": [
{
"name": "secondarydiagstorageaccount",
"endpoint": "https://core.windows.net",
"sasToken": "{sas token}"
}
]
}
}
<PrivateConfig>
<StorageAccount name="diagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas token}" />
<SecondaryStorageAccounts>
<StorageAccount name="secondarydiagstorageaccount" endpoint="https://core.windows.net" sasToken="{sas
token}" />
</SecondaryStorageAccounts>
</PrivateConfig>

Se agregó StorageType a PublicConfig. Puede ser Table, Blob y TableAndBlob. Table es el valor predeterminado.
{
"WadCfg": {
},
"StorageAccount": "diagstorageaccount",
"StorageType": "TableAndBlob"
}
<PublicConfig>
<WadCfg />
<StorageAccount>diagstorageaccount</StorageAccount>
<StorageType>TableAndBlob</StorageType>
</PublicConfig>

Se agregó la capacidad de enrutar a EventHub.
Se agregaron el elemento Sinks y la capacidad de enviar datos de diagnóstico a Application Insights, lo que
permitió diagnosticar de forma más sencilla los problemas tanto en la aplicación como en la infraestructura y el
sistema.
Azure SDK 2.6 y extensión Diagnostics 1.3
Para los proyectos de Cloud Service en Visual Studio, se realizaron los siguientes cambios. (Estos cambios también
se aplican a las versiones posteriores del SDK de Azure.)
El emulador local ahora es compatible con diagnósticos. Este cambio significa que puede recopilar datos de
diagnóstico y asegurarse de que su aplicación crea los seguimientos correctos mientras desarrolla y realiza
pruebas en Visual Studio. La cadena de conexión UseDevelopmentStorage=true habilita la colección de datos de
diagnóstico mientras ejecuta el proyecto de servicio en la nube en Visual Studio mediante el emulador de
almacenamiento de Azure. Todos los datos de diagnóstico se recopilan en la cuenta de almacenamiento
(Almacenamiento de desarrollo).
La cadena de conexión de la cuenta de almacenamiento de diagnóstico
(Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString) se almacena una vez más en el archivo de
configuración de servicio (.cscfg). En Azure SDK 2.5 se especificó la cuenta de almacenamiento de diagnóstico
en el archivo diagnostics.wadcfgx.
Existen algunas diferencias importantes entre el funcionamiento de la cadena de conexión en Azure SDK 2.4 y
Azure SDK 2.6 y versiones posteriores.
En Azure SDK 2.4 y versiones anteriores, la cadena de conexión se usaba como entorno de tiempo de ejecución
mediante el complemento de diagnóstico para obtener la información de la cuenta de almacenamiento para la
transferencia de registros de diagnóstico.
En Azure SDK 2.6 y versiones posteriores, Visual Studio usa la cadena de conexión de diagnóstico para
configurar la extensión de diagnóstico con la información de la cuenta de almacenamiento adecuada durante la
publicación. La cadena de conexión le permite definir las cuentas de almacenamiento diferentes para diferentes
configuraciones de servicio que Visual Studio usará al publicar. Sin embargo, porque ya no está disponible el
complemento de diagnóstico (después de Azure SDK 2.5), el archivo .cscfg por sí solo no puede habilitar la
extensión de diagnóstico. Debe habilitar la extensión por separado a través de herramientas como Visual
Studio o PowerShell.
Para simplificar el proceso de configuración de la extensión de diagnósticos con PowerShell, la salida del
paquete de Visual Studio también contiene el XML de configuración pública para la extensión de diagnósticos
para cada rol. Visual Studio usa la cadena de conexión de diagnósticos para rellenar la información de la cuenta
de almacenamiento presente en la configuración pública. Los archivos de configuración públicos se crean en la
carpeta Extensiones y siguen el patrón PaaSDiagnostics.<RoleName>.PubConfig.xml . Cualquier implementación
basada en PowerShell puede usar este patrón para asignar cada configuración a un rol.
El portal de Azure también usa la cadena de conexión del archivo .cscfg para obtener acceso a los datos de
diagnóstico, por lo que puede aparecer en la pestaña Super visión . La cadena de conexión es necesaria para
configurar el servicio para que muestre los datos de supervisión detallada en el portal.
Migración de proyectos a Azure SDK 2.6 y versiones posteriores
Al migrar de Azure SDK 2.5 a Azure SDK 2.6 o versiones posteriores, si tenía una cuenta de almacenamiento de
diagnósticos especificada en el archivo .wadcfgx, permanecerá allí. Para aprovechar la flexibilidad de utilizar
cuentas de almacenamiento diferentes para distintas configuraciones de almacenamiento, tendrá que agregar
manualmente la cadena de conexión al proyecto. Si está migrando un proyecto de Azure SDK 2.4 o una versión
anterior a Azure SDK 2.6, se conservarán las cadenas de conexión de diagnóstico. Sin embargo, tenga en cuenta
los cambios en cómo se tratan las cadenas de conexión en Azure SDK 2.6 tal como se especifica en la sección
anterior.
Cómo determina Visual Studio la cuenta de almacenamiento de diagnósticos
Si se especifica una cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio lo usa para configurar
la extensión de diagnóstico al publicar y al generar los archivos xml de configuración pública durante el
empaquetado.
Si no se especifica ninguna cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio recurre a usar
la cuenta de almacenamiento especificada en el archivo .wadcfgx para configurar la extensión de diagnóstico al
publicar, y a generar los archivos xml de configuración pública durante el empaquetado.
La cadena de conexión de diagnóstico del archivo .cscfg tiene prioridad sobre la cuenta de almacenamiento del
archivo .wadcfgx. Si se especifica una cadena de conexión de diagnóstico en el archivo .cscfg, Visual Studio la
usa y omite la cuenta de almacenamiento en .wadcfgx.
¿ Qué hace la casilla "Actualizar las cadenas de conexión de almacenamiento de..."?
La casilla Actualizar las cadenas de conexión de almacenamiento de desarrollo para el diagnóstico y
el almacenamiento en caché con las credenciales de la cuenta de almacenamiento de Microsoft
Azure al publicar en Microsoft Azure le ofrece una manera cómoda de actualizar cualquier cadena de
conexión de cuenta de almacenamiento de desarrollo con la cuenta de almacenamiento de Azure especificada
durante la publicación.
Por ejemplo, supongamos que activa esta casilla y la cadena de conexión de diagnóstico especifica
UseDevelopmentStorage=true . Al publicar el proyecto en Azure, Visual Studio actualizará automáticamente la cadena
de conexión de diagnóstico con la cuenta de almacenamiento que especificó en el Asistente para publicación. Sin
embargo, si se especificó una cuenta de almacenamiento real como la cadena de conexión de diagnóstico, se usará
dicha cuenta en su lugar.
Diferencias de funcionalidad de diagnóstico entre Azure SDK 2.4 y versiones anteriores y Azure SDK 2.5 y
versiones posteriores
Si está actualizando su proyecto de Azure SDK 2.4 a Azure SDK 2.5 o versiones posteriores, debe tener en cuenta
las siguientes diferencias de funcionalidad de diagnóstico.
Las API de configuración están desusadas : la configuración mediante programación del diagnóstico está
disponible en Azure SDK 2.4 o versiones anteriores, pero está en desuso en Azure SDK 2.5 y versiones
posteriores. Si la configuración de diagnóstico está definida actualmente en el código, deberá volver a definir
esa configuración desde el principio en el proyecto migrado para que el diagnóstico siga funcionando. El
archivo de configuración de diagnóstico de Azure SDK 2.4 es diagnostics.wadcfg y diagnostics.wadcfgx, para
Azure SDK 2.5 y versiones posteriores.
El diagnóstico para aplicaciones de ser vicio en la nube solo se puede configurar en el nivel de
rol, no en el nivel de instancia.
Cada vez que implementa la aplicación, se actualiza la configuración de diagnóstico : esto puede
provocar problemas de paridad si cambia la configuración de diagnóstico del Explorador de servidores y luego
vuelve a implementar la aplicación.
En Azure SDK 2.5 y versiones posteriores, los volcados de memoria se configuran en el archivo
de configuración de diagnóstico, no en el código : si tiene volcados de memoria configurados en el
código, tendrá que transferir manualmente la configuración del código al archivo de configuración, porque los
volcados de memoria no se transfieren durante la migración a Azure SDK 2.6.
Solución de problemas de Azure Diagnostics
En este artículo se proporciona información para la solución de problemas relacionados con el uso de Azure
Diagnostics. Para obtener información sobre Azure Diagnostics, consulte la introducción a Azure Diagnostics.
Componentes lógicos
Diagnostics Plugin Launcher (DiagnosticsPluginLauncher.exe) : inicia la extensión Azure Diagnostics.
Funciona como el proceso de punto de entrada.
Diagnostics Plugin (DiagnosticsPlugin.exe) : configura, inicia y administra la duración del agente de
supervisión. Es el proceso principal que ejecuta el iniciador.
Agente de super visión (procesos de MonAgent*.exe) : supervisa, recopila y transfiere los datos de
diagnóstico.
Rutas de acceso de registro y de artefacto

Estas son las rutas de acceso a algunos de los registros y artefactos más importantes. Se tendrá en cuenta esta
información a lo largo del documento.
A RT EFA C TO PAT H
Archivo de configuración de Azure Diagnostics %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics

.PaaSDiagnostics<version>\Config.txt
Archivos de registro C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<

version>\
Almacén local para los datos de diagnóstico C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Tables
Archivo de configuración del agente de super visión C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Configuration\MaCo
nfig.xml
Paquete de extensión de Azure Diagnostics %SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics

.PaaSDiagnostics<version>
Ruta de acceso a la utilidad de recopilación de %SystemDrive%\Packages\GuestAgent\

registros
Archivo de registro de MonAgentHost C:\Resources\Directory<CloudServiceDeploymentID>.

<RoleName>.DiagnosticStore\WAD0107\Configuration\MonA
gentHost.<seq_num>.log
Máquinas virtuales
A RT EFA C TO PAT H
Archivo de configuración de Azure Diagnostics C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<version>\RuntimeSettings
Archivos de registro C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\
Almacén local para los datos de diagnóstico C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
Archivo de configuración del agente de super visión C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\
MaConfig.xml
Archivo de estado C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<version>\Status
Paquete de extensión de Azure Diagnostics C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnosti

cs<DiagnosticsVersion>
Ruta de acceso a la utilidad de recopilación de C:\WindowsAzure\Logs\WaAppAgent.log

registros
Archivo de registro de MonAgentHost C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.Ia

aSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\
MonAgentHost.<seq_num>.log
Los datos métricos no aparecen en Azure Portal

Azure Diagnostics proporciona una serie de datos métricos, que se pueden mostrar en Azure Portal. Si tiene
problemas para ver los datos en el portal, consulte la tabla WADMetrics* de la cuenta de almacenamiento de Azure
Diagnostics para ver si los registros de las métricas correspondientes están presentes y para asegurarse que el
proveedor de recursos Microsoft.Insights esté registrado.
En este caso, el elemento Par titionKey de la tabla se compone del id. de recursos, la máquina virtual o el conjunto
de escalado de máquinas virtuales. RowKey es el nombre de la métrica (también conocido como el nombre del
contador de rendimiento).
Si el identificador del recurso es incorrecto, compruebe la opción Diagnóstico Configuración > Métricas >
ResourceId para ver si el identificador del recurso está bien definido.
Si no hay ningún dato para la métrica específica, compruebe la opción Configuración de diagnóstico >
Contador de rendimiento para ver si se incluye la métrica (el contador de rendimiento). Los siguientes
contadores se habilitan de forma predeterminada:
Procesador(_Total)% Hora del procesador
\Memoria\Bytes disponibles
\ASP.NET Applications(Total )\Requests/Sec [\Aplicaciones ASP.NET(Total)\Solicitudes/s]
\ASP.NET Applications(Total )\Errors Total/Sec [\Aplicaciones ASP.NET(Total)\Total de errores/s]
\ASP.NET\Requests Queued (\ASP.NET\Solicitudes en cola)
\ASP.NET\Requests Rejected (\ASP.NET\Solicitudes rechazadas)
\Processor(w3wp)% Processor Time [\Procesador(w3wp) Tiempo de procesador]
\Process(w3wp)\Private Bytes [\Proceso(w3wp)\Bytes privados]
\Process(WaIISHost)% Processor Time [\Proceso(WaIISHost) Tiempo de procesador]
\Process(WaIISHost)\Private Bytes [\Proceso(WallSHost)\Bytes privados]
\Process(WaWorkerHost)% Processor Time [\Proceso(WaWorkerHost) Tiempo de procesador]
\Process(WaWorkerHost)\Private Bytes (\Proceso(WaWorkerHost)\Bytes privados)
\Memory\Page Faults/sec (\Memoria\Errores de página/s)
.NET CLR Memory(Global)% Time in GC [Memoria CLR NET(Global) Tiempo en GC]
\LogicalDisk(C:)\Disk Write Bytes/sec [\DiscoLógico(C:)\Bytes de escritura en disco/segundo]
\LogicalDisk(C:)\Disk Read Bytes/sec [\DiscoLógico(C:)\Bytes de lectura en disco/s]
\LogicalDisk(D:)\Disk Write Bytes/sec [\DiscoLógico(D:)\Bytes de escritura en disco/s]
\LogicalDisk(D:)\Disk Read Bytes/sec [\DiscoLógico(D:)\Bytes de lectura en disco/s]
Si la configuración se ha establecido correctamente, pero todavía no puede ver los datos métricos, siga las
instrucciones siguientes para solucionar cualquier problema que tenga.
Azure Diagnostics no se inicia

Examine los archivos DiagnosticsPluginLauncher.log y DiagnosticsPlugin.log en la ubicación de los archivos
de registro proporcionada anteriormente, para obtener información sobre por qué Azure Diagnostics no se pudo
iniciar.
Si estos registros indican Monitoring Agent not reporting success after launch , significa que hubo un error al
iniciar MonAgentHost.exe. Examine los registros en la ubicación que se indicó para MonAgentHost log file en la
sección anterior.
La última línea de los archivos de registro contiene el código de salida.
DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0
Si encuentra un código de salida negativo , consulte la tabla de códigos de salida en la sección Referencias.
Los datos de diagnóstico no se registran en Azure Storage

Compruebe si no aparece ningún dato o si solo aparece parte de ellos.
Registros de infraestructura de diagnóstico
Diagnostics registra todos los errores de los registros de infraestructura de diagnóstico. Asegúrese de que ha
habilitado la opción de captura de registros de infraestructura de diagnóstico en la configuración. A continuación,
puede buscar rápidamente los errores más relevantes que aparezcan en la DiagnosticInfrastructureLogsTable
tabla de la cuenta de almacenamiento configurada.
No aparece ningún dato
La razón más común para que los datos de evento no aparezcan en absoluto, es que la información de la cuenta de
almacenamiento se ha definido incorrectamente.
Solución: corrija la configuración de Diagnostics y vuelva a instalar esta extensión.
Si la cuenta de almacenamiento está configurada correctamente, conéctese a la máquina mediante acceso remoto
y asegúrese de que DiagnosticsPlugin.exe y MonAgentCore.exe se están ejecutando. Si no se están ejecutando, siga
las instrucciones de la sección Azure Diagnostics no se inicia.
Si los procesos están en ejecución, vaya a ¿Se capturan los datos localmente? y siga las instrucciones que se
detallan allí.
Si el problema no se soluciona, pruebe a llevar a cabo las acciones siguientes:
1. Desinstalación del agente
2. Eliminación del directorio C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics
3. Instalación del agente de nuevo
No están todos los datos
Si puede ver algunos de los datos pero no todos, esto quiere decir que la colección de datos o la canalización de
transferencia están configuradas correctamente. Siga las subsecciones que se muestran aquí para acotar el
problema.
¿ Está configurada la colección?
La configuración de diagnóstico contiene instrucciones que indican que se debe recopilar un tipo determinado de
datos. Revise la configuración para comprobar que solo está buscando los datos que configuró en la colección.
¿ Genera datos el host?
Contadores de rendimiento : abra el monitor de rendimiento y compruebe el contador.
Registros de seguimiento : conéctese a la máquina virtual mediante Escritorio remoto y agregue
TextWriterTraceListener al archivo de configuración de la aplicación. Consulte
https://msdn.microsoft.com/library/sk36c28t.aspx para configurar el agente de escucha de texto. Asegúrese
de que el elemento <trace> tenga <trace autoflush="true"> .
Si no ve que se generen registros de seguimiento, consulte Más información sobre los registros de
seguimiento que faltan.
Seguimientos de ETW : conéctese a la máquina virtual mediante Escritorio remoto e instale PerfView. En
PerfView, ejecute Archivo > Comando de usuario > Escuchar etwprovder1 > etwprovider2 etc.
Tenga en cuenta que el comando de escucha distingue mayúsculas de minúsculas y que no puede haber
espacios entre la lista de proveedores de ETW separados por comas. Si no se puede ejecutar el comando,
puede hacer clic en el botón Registrar en la esquina inferior derecha de la herramienta Perfview para ver lo
que se intentó ejecutar y cuál fue el resultado. Suponiendo que la entrada es correcta, aparece una nueva
ventana. En unos segundos, empezará a ver los seguimientos de ETW.
Registros de eventos : conéctese a la máquina virtual mediante Escritorio remoto. Abra Event Viewer y
asegúrese de que los eventos estén ahí.
¿ Se capturan los datos localmente?
A continuación, asegúrese de que los datos se capturen localmente. Los datos se almacenan localmente en
archivos *.tsf en el almacén local de datos de diagnóstico. Diferentes tipos de registros se recopilan en
diferentes archivos .tsf . Los nombres son similares a los nombres de tablas de Azure Storage.
Por ejemplo, los Performance Counters se obtienen en PerformanceCountersTable.tsf . Los registros de eventos se
obtienen en WindowsEventLogsTable.tsf . Siga las instrucciones de la sección Extracción de registros locales para
abrir los archivos de recopilación locales y asegúrese de que se recopilan en el disco.
Si no ve que los registros se recopilen localmente y ya ha comprobado que el host genera datos, es probable que
tenga un problema de configuración. Revise las opciones de configuración.
Igualmente, revise la configuración que se generó para MonitoringAgent MaConfig.xml. Compruebe que haya una
sección que describa el origen de los registros correspondientes. A continuación, que no se pierdan en la
conversión entre la configuración de Diagnostics y la del agente de supervisión.
¿ Se transfieren los datos?
Si ha comprobado que los datos se capturan localmente, pero sigue sin verlos en su cuenta de almacenamiento,
siga estos pasos:
Asegúrese de que haya proporcionado una cuenta de almacenamiento correcta y que no haya sustituido las
claves de la cuenta de almacenamiento propuesta. Al usar Azure Cloud Services, hay que tener en cuenta
que en ocasiones los usuarios no actualizan useDevelopmentStorage=true .
Compruebe que la cuenta de almacenamiento proporcionada es correcta. Asegúrese de que no tenga
restricciones de red que no permitan que los componentes alcancen los puntos de conexión de
almacenamiento público. Una forma de hacerlo consiste en conectarse a la máquina mediante Escritorio
remoto e intentar escribir algo en la misma cuenta de almacenamiento.
Por último, intente ver qué errores notifica el agente de supervisión. El agente de supervisión escribe sus
registros en maeventtable.tsf , que se encuentra en el almacén local de datos de diagnóstico. Siga las
instrucciones de la sección Extracción de registros locales para abrir este archivo. A continuación, intente
determinar si hay errors que indiquen la imposibilidad de leer archivos locales o de escribir en el
almacenamiento.
Captura y archivo de registros
Si va a ponerse en contacto con el servicio técnico, lo primero que podrían pedirle es que recopilara registros de su
máquina. Para ahorrar tiempo, hágalo usted mismo. Ejecute la utilidad CollectGuestLogs.exe en Ruta de acceso a
la utilidad de recopilación de registros. Se creará un archivo .zip que contiene todos los registros relevantes de
Azure en la misma carpeta.
Tablas de datos de diagnóstico no encontradas

Las tablas de Azure Storage que contienen eventos de ETW se nombran mediante el código siguiente:
if (String.IsNullOrEmpty(eventDestination)) {
if (e == "DefaultEvents")
tableName = "WADDefault" + MD5(provider);
else
tableName = "WADEvent" + MD5(provider) + eventId;
}
else
tableName = "WAD" + eventDestination;
Este es un ejemplo:
<EtwEventSourceProviderConfiguration provider="prov1">
<Event id="1" />
<Event id="2" eventDestination="dest1" />
<DefaultEvents />
</EtwEventSourceProviderConfiguration>
<EtwEventSourceProviderConfiguration provider="prov2">
<DefaultEvents eventDestination="dest2" />
</EtwEventSourceProviderConfiguration>
"EtwEventSourceProviderConfiguration": [
{
"provider": "prov1",
"Event": [
{
"id": 1
},
{
"id": 2,
"eventDestination": "dest1"
}
],
"DefaultEvents": {
"eventDestination": "DefaultEventDestination",
"sinks": ""
}
},
{
"provider": "prov2",
"DefaultEvents": {
"eventDestination": "dest2"
}
}
]
Este código genera cuatro tablas:
EVEN TO N O M B RE DE L A TA B L A
proveedor="prov1" <Id. de evento="1" /> WADEvent+MD5("prov1")+"1"
proveedor ="prov1" <ID. de evento="2" WADdest1

eventDestination="dest1" />
proveedor="prov1" <DefaultEvents /> WADDefault+MD5("prov1")
proveedor="prov2" <DefaultEvents eventDestination="dest2" WADdest2

/>
Referencias
Cómo comprobar la configuración de la extensión de Diagnostics
La manera más sencilla de comprobar la configuración de su extensión es ir a Azure Resource Explorer y
desplazarse a la máquina virtual o al servicio en la nube en los que se encuentra la extensión de Azure Diagnostics
(IaaSDiagnostics/PaaDiagnostics) en cuestión.
Como alternativa, puede conectarse a la máquina mediante Escritorio remoto y examinar el archivo de
configuración de Azure Diagnostics que se describe en la sección Rutas de acceso de registro y artefacto.
En cualquier caso, busque Microsoft.Azure.Diagnostics y, a continuación, el campo xmlCfg o WadCfg .
Si está buscando en alguna máquina virtual y está presente el campo WadCfg , significa que la configuración está
en formato JSON. Si el campo xmlCfg está presente, significa que la configuración se ha realizado en XML y está
codificada en Base 64. Debe descodificarlo para ver el XML que cargó Diagnostics.
En cuanto al rol de servicio en la nube, si elige la configuración del disco, los datos se codifican en Base64, por lo
que deberá descodificarlos para ver el XML que se cargó mediante Diagnostics.
Códigos de salida del complemento Azure Diagnostics
El complemento devuelve los siguientes códigos de salida:
C Ó DIGO DE SA L IDA DESC RIP C IÓ N
0 Correcto.
-1 Error genérico.
-2 No se puede cargar el archivo rcf.

Este error interno solo debería ocurrir si el iniciador del
complemento del agente invitado se invoca manualmente
de forma incorrecta en la máquina virtual.
-3 No se puede cargar el archivo de configuración de

Diagnósticos.
Solución: Esto se debe a que un archivo de configuración
no supera la validación del esquema. La solución es
proporcionar un archivo de configuración que cumpla el
esquema.
-4 Ya hay otra instancia de Diagnósticos del agente de

supervisión que usa el directorio de recursos local.
Solución: especifique un valor distinto para
LocalResourceDirector y .
-6 El iniciador del complemento del agente invitado intentó

iniciar Diagnósticos con una línea de comandos no válida.
-10 El complemento Diagnósticos se cerró con una excepción no

controlada.
-11 El agente invitado no pudo crear el proceso encargado de

iniciar y supervisar al agente de supervisión.
Solución: compruebe que hay disponibles recursos del
sistema suficientes para iniciar nuevos procesos.
-101 Argumentos no válidos al llamar al complemento

Diagnósticos.
-102 El proceso del complemento no se puede iniciar por sí mismo.

-103 El proceso del complemento no se puede iniciar por sí mismo.

Concretamente, no puede crear el objeto del registrador.
-104 No se puede cargar el archivo rcf proporcionado por el agente

invitado.
-105 El complemento Diagnósticos no puede abrir el archivo de

configuración de Diagnósticos.
Este error interno solo debería ocurrir si el complemento
de Diagnostics se invoca manualmente de forma
incorrecta en la máquina virtual.
-106 No se puede leer el archivo de configuración de Diagnósticos.

Esto se debe a que un archivo de configuración no supera
la validación del esquema.
Solución: proporcione un archivo de configuración que

cumpla el esquema. Para obtener más información,
consulte Cómo comprobar la configuración de la
extensión de Diagnostics.
-107 El directorio de recursos pasado al agente de supervisión no

es válido.
Este error interno solo debería ocurrir si el agente de
supervisión se invoca manualmente y de forma incorrecta
en la máquina virtual.
-108 No se puede convertir el archivo de configuración de

Diagnósticos al archivo de configuración del agente de
supervisión.
Diagnósticos se invoca manualmente con un archivo de
configuración no válido.
-110 Error de configuración general de Diagnósticos.

Diagnósticos se invoca manualmente con un archivo de
configuración no válido.
-111 No se puede iniciar el agente de supervisión.

Solución: compruebe que hay suficientes recursos del
sistema disponibles.
-112 Error general
Extracción de registros locales

El agente de supervisión recopila registros y artefactos como archivos .tsf . El archivo .tsf no se puede leer
pero puede convertirlo a .csv de la manera siguiente:
<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf
Un archivo nuevo llamado <relevantLogFile>.csv se crea en la misma ruta de acceso que el archivo .tsf
correspondiente.
NOTE
Solo debe ejecutar esta utilidad con el archivo .tsf principal (por ejemplo, PerformanceCountersTable.tsf). Los archivos
complementarios (por ejemplo, PerformanceCountersTables_**001.tsf, PerformanceCountersTables_**002.tsf etc.) se
procesarán automáticamente.
Más información sobre los registros de seguimiento que faltan
NOTE
La información que se ofrece a continuación, se aplica principalmente a Azure Cloud Services, a no ser que haya configurado
la utilidad DiagnosticsMonitorTraceListener en una aplicación que se ejecute en la máquina virtual de IaaS.
Asegúrese de que DiagnosticMonitorTraceListener esté configurado en el archivo web.config o

app.config. Esto se configura de forma predeterminada en los proyectos de servicios de nube. Sin embargo,
algunos clientes lo convierten en comentario, lo que hace que los diagnósticos no recopilen las
instrucciones de seguimiento.
Si no se escriben registros con el método OnStar t o Run , asegúrese de que
DiagnosticMonitorTraceListener se encuentre en app.config. De forma predeterminada está en
web.config, pero eso solo se aplica al código que se ejecuta en w3wp.exe. Debido a ello, debe estar en
app.config para que se capturen los seguimientos que se ejecutan en WaIISHost.exe.
Asegúrese de que usa Diagnostics.Trace.TraceXXX en lugar de Diagnostics.Debug.WriteXXX. Las
instrucciones de depuración se quitarán de una compilación de versión.
Asegúrese de que el código compilado tenga realmente líneas de Diagnostics.Trace (use Reflector,
ildasm o ILSpy para comprobarlo). Los comandos Diagnostics.Trace se quitan del binario compilado a
menos que se use el símbolo de compilación condicional TRACE. Si usa msbuild para compilar el proyecto,
este es un problema habitual con el que se encontrará.
Problemas conocidos y mitigaciones

Esta es una lista de problemas conocidos con mitigaciones conocidas:
1. Dependencia de .NET 4.5
La extensión de Windows Azure Diagnostics tiene una dependencia de tiempo de ejecución en la plataforma .NET
4.5 o superior. En el momento de escribir este artículo, todas las máquinas aprovisionadas de Azure Cloud Services
y todas las imágenes de base oficiales de máquinas virtuales de Azure tienen instalado .NET 4.5 o una versión
superior.
Aún así, es posible encontrarse en una situación en la que intente ejecutar Windows Azure Diagnostics en una
máquina que no tenga .NET 4.5 o superior. Esto sucede cuando crea su máquina a partir de una imagen o
instantánea anterior, o cuando trae su propio disco personalizado.
Generalmente se manifiesta como un código de salida 255 al ejecutar DiagnosticsPluginLauncher.exe. El error
se produce debido a la siguiente excepción no controlada:
System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0,

Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
Mitigación: instale .NET 4.5 o una versión superior en la máquina.

2. Los datos de los contadores de rendimiento están disponibles en el almacenamiento, pero no se
muestran en el por tal
La experiencia del portal de las máquinas virtuales muestra de forma predeterminada determinados contadores
de rendimiento. Si no ve estos contadores de rendimiento y sabe que los datos se están generando porque están
disponibles en el almacenamiento, consulte lo siguiente:
Si los datos del almacenamiento tienen nombres de contadores en inglés. Si los nombres de los contadores
no están en inglés, el gráfico de métricas del portal no podrá reconocerlos. Mitigación : cambie el idioma
de la máquina a inglés en las cuentas del sistema. Para ello, seleccione Panel de control > Región >
Administración > Copiar configuración . A continuación, anule la selección de la opción Cuentas de
sistema y de pantalla de bienvenida para que el lenguaje personalizado no se aplique a la cuenta del
sistema.
Si usa caracteres comodín (*) en los nombres de los contadores de rendimiento, el portal no podrá
correlacionar el contador de rendimiento configurado y el recopilado cuando estos se envíen al receptor de
Azure Storage. Mitigación : para asegurarse de que puede usar caracteres comodín y que tiene el portal
expandido (*), enrute los contadores de rendimiento hacia el receptor de Azure Monitor.
Uso de la extensión Diagnostics de Linux para
supervisar métricas y registros
En este documento se describen las versiones 3.0 y posteriores de la extensión Diagnostics de Linux.
IMPORTANT
Para obtener información sobre las versiones 2.3 y anteriores, consulte este documento.
Introducción
La extensión Diagnostics de Linux ayuda a los usuarios a supervisar el mantenimiento de máquinas virtuales
Linux que se ejecuten en Microsoft Azure. Ofrece la siguiente funcionalidad:
Recopila métricas de rendimiento del sistema de la máquina virtual y las almacena en una tabla específica de
una cuenta de almacenamiento designada.
Recupera eventos de registro de syslog y los almacena en una tabla específica de la cuenta de
almacenamiento designada.
Permite a los usuarios personalizar las métricas de datos que se recopilan y se cargan.
Permite a los usuarios personalizar las utilidades de syslog y los niveles de gravedad de los eventos que se
recopilan y se cargan.
Permite a los usuarios cargar los archivos de registro especificados en la tabla de almacenamiento designada.
Admite el envío de métricas y eventos de registro a puntos de conexión arbitrarios de EventHub y blobs con
formato JSON en la cuenta de almacenamiento designada.
Esta extensión funciona con los dos modelos de implementación de Azure.
Instalación de la extensión en la máquina virtual

Puede habilitar esta extensión mediante cmdlets de Azure PowerShell, scripts de la CLI de Azure, plantillas de
ARM o Azure Portal. Para obtener más información, consulte Funciones de la extensión.
Mediante estas instrucciones de instalación y una configuración de ejemplo descargable se configura LAD 3.0
para:
capturar las mismas métricas que las proporcionadas por LAD 2.3 y almacenarlas,
capturar un conjunto útil de métricas del sistema de archivos (función nueva de LAD 3.0),
capturar la recopilación predeterminada de syslog habilitada por LAD 2.3, y
habilitar la experiencia de Azure Portal para la creación de gráficos y desencadenamiento de alertas en
métricas de máquinas virtuales.
La configuración que se puede descargar es solo un ejemplo; modifíquela como corresponda para adaptarla a
sus necesidades.
Distribuciones de Linux compatibles
La extensión Diagnostics de Linux admite las siguientes distribuciones y versiones. La lista de distribuciones y
versiones es válida únicamente con las imágenes de proveedor de Linux aprobadas por Azure. Por lo general, las
imágenes BYOL y BYOS de terceros (como los dispositivos) no suelen admitirse en la extensión Diagnostics de
Linux.
En todas las versiones secundarias también se admite una distribución que enumera solo versiones principales,
como Debian 7. Si se especifica una versión secundaria específica, solo se admitirá esa versión en concreto; si
"+" aparece anexado, se admitirán las versiones secundarias iguales o superiores que la versión especificada.
Distribuciones y versiones admitidas:
Ubuntu 18.04, 16.04, 14.04
CentOS 7, 6.5+
Oracle Linux 7, 6.4+
OpenSUSE 13.1+
SUSE Linux Enterprise Server 12
Debian 9, 8, 7
RHEL 7, 6.7+
Requisitos previos
Versión 2.2.0 o posterior del agente Linux de Azure . La mayoría de las imágenes de la galería de
máquina virtual Linux de Azure incluyen la versión 2.2.7 o posterior. Ejecute /usr/sbin/waagent -version para
confirmar la versión instalada en la máquina virtual. Si la máquina virtual está ejecutando una versión
anterior del agente invitado, siga estas instrucciones para actualizarla.
Azure CLI . Instale el entorno de la CLI de Azure en la máquina.
El comando wget, si aún no lo tiene: Ejecute sudo apt-get install wget .
Una suscripción a Azure existente y una cuenta de almacenamiento de uso general existente para almacenar
los datos. Las cuentas de almacenamiento de uso general admiten el almacenamiento en tablas, que es
necesario. Una cuenta de Blob Storage no funcionará.
Instalación de ejemplo
NOTE
Para cualquiera de los ejemplos, rellene valores correctos de las variables de la primera sección antes de ejecutar lo
siguiente.
La configuración de ejemplo descargada en estos ejemplos recopila un conjunto de datos estándar y los envía a
un almacenamiento de tabla. La dirección URL de la configuración de muestreo y su contenido están sujetos a
cambios. En la mayoría de los casos, conviene descargar una copia del archivo JSON de configuración del portal
y personalizarlo según sus necesidades y, tras ello, hacer que las plantillas o automatizaciones que se creen usen
su propia versión del archivo de configuración, en lugar de tener que descargar esa dirección URL una y otra
vez.
Ejemplo de la CLI de Azure
# Set your Azure VM diagnostic variables correctly below
my_resource_group=<your_azure_resource_group_name_containing_your_azure_linux_vm>
my_linux_vm=<your_azure_linux_vm_name>
my_diagnostic_storage_account=<your_azure_storage_account_for_storing_vm_diagnostic_data>
# Should login to Azure first before anything else

az login
# Select the subscription containing the storage account

az account set --subscription <your_azure_subscription_id>
# Download the sample Public settings. (You could also use curl or any web browser)
wget https://raw.githubusercontent.com/Azure/azure-linux-
extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json -O
portal_public_settings.json
# Build the VM resource ID. Replace storage account name and resource ID in the public settings.
my_vm_resource_id=$(az vm show -g $my_resource_group -n $my_linux_vm --query "id" -o tsv)
sed -i "s#__DIAGNOSTIC_STORAGE_ACCOUNT__#$my_diagnostic_storage_account#g" portal_public_settings.json
sed -i "s#__VM_RESOURCE_ID__#$my_vm_resource_id#g" portal_public_settings.json
# Build the protected settings (storage account SAS token)

my_diagnostic_storage_account_sastoken=$(az storage account generate-sas --account-name
$my_diagnostic_storage_account --expiry 2037-12-31T23:59:00Z --permissions wlacu --resource-types co --
services bt -o tsv)
my_lad_protected_settings="{'storageAccountName': '$my_diagnostic_storage_account',
'storageAccountSasToken': '$my_diagnostic_storage_account_sastoken'}"
# Finallly tell Azure to install and enable the extension

az vm extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic --version 3.0 --resource-
group $my_resource_group --vm-name $my_linux_vm --protected-settings "${my_lad_protected_settings}" --
settings portal_public_settings.json
Ejemplo de PowerShell
$storageAccountName = "yourStorageAccountName"
$storageAccountResourceGroup = "yourStorageAccountResourceGroupName"
$vmName = "yourVMName"
$VMresourceGroup = "yourVMResourceGroupName"
# Get the VM object

$vm = Get-AzVM -Name $vmName -ResourceGroupName $VMresourceGroup
# Get the public settings template from GitHub and update the templated values for storage account and
resource ID
$publicSettings = (Invoke-WebRequest -Uri https://raw.githubusercontent.com/Azure/azure-linux-
extensions/master/Diagnostic/tests/lad_2_3_compatible_portal_pub_settings.json).Content
$publicSettings = $publicSettings.Replace('__DIAGNOSTIC_STORAGE_ACCOUNT__', $storageAccountName)
$publicSettings = $publicSettings.Replace('__VM_RESOURCE_ID__', $vm.Id)
# If you have your own customized public settings, you can inline those rather than using the template
above: $publicSettings = '{"ladCfg": { ... },}'
# Generate a SAS token for the agent to use to authenticate with the storage account
$sasToken = New-AzStorageAccountSASToken -Service Blob,Table -ResourceType Service,Container,Object -
Permission "racwdlup" -Context (Get-AzStorageAccount -ResourceGroupName $storageAccountResourceGroup -
AccountName $storageAccountName).Context -ExpiryTime $([System.DateTime]::Now.AddYears(10))
# Build the protected settings (storage account SAS token)

$protectedSettings="{'storageAccountName': '$storageAccountName', 'storageAccountSasToken': '$sasToken'}"
# Finally install the extension with the settings built above

Set-AzVMExtension -ResourceGroupName $VMresourceGroup -VMName $vmName -Location $vm.Location -ExtensionType
LinuxDiagnostic -Publisher Microsoft.Azure.Diagnostics -Name LinuxDiagnostic -SettingString $publicSettings
-ProtectedSettingString $protectedSettings -TypeHandlerVersion 3.0
Actualización de la configuración de la extensión
Después de cambiar la Configuración pública o protegida, ejecute el mismo comando para implementarla en la
VM. Si se ha realizado cualquier modificación en la configuración, la configuración actualizada se envía a la
extensión. LAD recarga la configuración y se reinicia automáticamente.
Migración desde versiones anteriores de la extensión
La versión más reciente de la extensión es la 3.0 . Todas las versiones anteriores (2.x) están en desuso y
pueden retirarse a par tir del 31 de julio de 2018 .
IMPORTANT
En esta extensión se introducen importantes cambios de configuración. La finalidad de uno de estos cambios era
aumentar la seguridad de la extensión; por tanto, no se pudo conservar la compatibilidad con las versiones 2.x anteriores.
Además, el publicador de esta extensión es diferente del de las versiones 2.x.
Para migrar a esta nueva versión de la extensión desde versiones 2.x, debe desinstalar la antigua (con el nombre de
publicador anterior) y, a continuación, instalar la versión 3.
Recomendaciones:
Instale la extensión con la actualización de versión secundaria automática habilitada.
En máquinas virtuales con el modelo de implementación clásica, especifique "3.*" como versión si va a
instalar la extensión mediante la CLI xPLAT de Azure o PowerShell.
En las máquinas virtuales del modelo de implementación de Azure Resource Manager, incluya
""autoUpgradeMinorVersion": true" en la plantilla de implementación de máquina virtual.
Use una cuenta de almacenamiento nueva o diferente para LAD 3.0. Hay varias pequeñas incompatibilidades
entre LAD 2.3 y LAD 3.0 que hacen que compartir una cuenta sea problemático:
LAD 3.0 almacena los eventos de syslog en una tabla con un nombre diferente.
Las cadenas de counterSpecifier para las métricas de builtin son diferentes en LAD 3.0.
Configuración protegida
Este conjunto de información de configuración contiene información confidencial que debería protegerse de la
vista pública, por ejemplo, las credenciales de almacenamiento. Esta configuración se transmite la extensión y es
almacenada por esta de forma cifrada.
{
"storageAccountName" : "the storage account to receive data",
"storageAccountEndPoint": "the hostname suffix for the cloud for this account",
"storageAccountSasToken": "SAS access token",
"mdsdHttpProxy": "HTTP proxy settings",
"sinksConfig": { ... }
}
N O M B RE VA L UE
storageAccountName Es el nombre de la cuenta de almacenamiento en la que la

extensión escribe los datos.
N O M B RE VA L UE
storageAccountEndPoint (Opcional) es el punto de conexión que identifica la nube en

la que existe la cuenta de almacenamiento. Si no hubiera
configuración, LAD selecciona la nube pública de Azure (
https://core.windows.net ) de forma predeterminada.
Para usar una cuenta de almacenamiento en Azure Alemania,
Azure Government o Azure China, establezca este valor
como corresponda.
storageAccountSasToken Es un token de SAS de cuenta para Blob services y Table

services ( ss='bt' ) aplicable a contenedores y objetos (
srt='co' ), que otorga permisos, los crea, los enumera, los
actualiza y los escribe ( sp='acluw' ). No incluya el signo de
interrogación principal (?).
mdsdHttpProxy (Opcional) es información del proxy HTTP necesaria para

habilitar la extensión para conectarse a la cuenta de
almacenamiento y el punto de conexión especificados.
sinksConfig (Opcional) es información sobre destinos alternativos a los

que pueden enviarse métricas y eventos. La información
específica de cada receptor de datos admitido por la
extensión se trata en las siguientes secciones.
Para obtener un token de SAS en una plantilla de Resource Manager, utilice la función listAccountSas . Para ver
una plantilla de ejemplo, consulte un ejemplo de función de lista.
Es posible construir el token de SAS necesario de forma muy sencilla mediante Azure Portal.
1. Seleccione la cuenta de almacenamiento de uso general en la que quiere que escriba la extensión.
2. Seleccione "Firma de acceso compartido" de la sección Configuración del menú izquierdo.
3. Cree las secciones pertinentes, conforme a lo descrito anteriormente.
4. Haga clic en el botón "Generar SAS".
Copie la SAS generada en el campo storageAccountSasToken. Elimine el signo de interrogación principal ("?").
sinksConfig
"sinksConfig": {
"sink": [
{
"name": "sinkname",
"type": "sinktype",
...
},
...
]
},
En esta sección opcional se definen destinos adicionales a los que la extensión envía la información que recopila.
La matriz "sink" contiene un objeto para cada receptor de datos adicional. El atributo "type" determina los demás
atributos del objeto.
EL EM EN TO VA L UE
name Una cadena usada para hacer referencia a este receptor en

cualquier otra parte de la configuración de la extensión.
EL EM EN TO VA L UE
type Es el tipo de receptor que se va a definir. Determina los

demás valores (si los hubiera) en instancias de este tipo.
La versión 3.0 de la extensión Diagnostics de Linux admite dos tipos de receptores: de EventHub y Json BLOB.
El receptor de EventHub
"sink": [
{
"name": "sinkname",
"type": "EventHub",
"sasURL": "https SAS URL"
},
...
]
La entrada "sasURL" contiene la URL completa, incluido el token SAS, para la instancia de EventHub en la que
deberían publicarse los datos. LAD necesita una directiva de denominación de SAS que habilite la notificación
Send. Por ejemplo:
Cree un espacio de nombres de Event Hubs llamado contosohub .
Cree un Event Hub en el espacio de nombres llamado syslogmsgs .
Cree una directiva de acceso compartido en el Event Hub llamada writer que habilite la notificación Send.
Si creó una SAS válida hasta la medianoche en horario UTC del 1 de enero de 2018, el valor de sasURL podría
ser:
https://contosohub.servicebus.windows.net/syslogmsgs?
sr=contosohub.servicebus.windows.net%2fsyslogmsgs&sig=xxxxxxxxxxxxxxxxxxxxxxxxx&se=1514764800&skn=writer
Para obtener más información sobre la generación y recuperación de información sobre tokens de SAS para
Event Hubs, consulte esta página web.
El receptor de Json BLOB
"sink": [
{
"name": "sinkname",
"type": "JsonBlob"
},
...
]
Los datos dirigidos a un receptor de Json BLOB se almacenan en blobs en Azure Storage. Cada instancia de LAD
crea un blob cada hora para cada nombre de receptor. Todos los blobs siempre contienen una matriz de objeto
JSON válida sintácticamente. Se agregan nuevas entradas a la matriz automáticamente. Los blobs se almacenan
en un contenedor con el mismo nombre que el receptor. Las reglas de Azure Storage para los nombres de
contenedores de blobs se aplican a los nombres de los receptores de Json BLOB: entre 3 y 63 caracteres
alfanuméricos ASCII o guiones.
Esta estructura contiene varios bloques de valores de configuración que controlan la información recopilada por
la extensión. Cada valor de configuración es opcional. Si especifica ladCfg , también debe especificar
StorageAccount .
{
"ladCfg": { ... },
"perfCfg": { ... },
"fileLogs": { ... },
"StorageAccount": "the storage account to receive data",
"mdsdHttpProxy" : ""
}
EL EM EN TO VA L UE
StorageAccount Es el nombre de la cuenta de almacenamiento en la que la

extensión escribe los datos. Debe ser el mismo nombre que
se especifique en la Configuración protegida.
mdsdHttpProxy (Opcional) es el mismo que en la Configuración protegida. El

valor público reemplaza al privado, en caso de estar
establecido. Coloque elementos de configuración de proxy
que contengan un secreto, como una contraseña, en la
Configuración protegida.
El resto de los elementos se describen con más detalle en las secciones siguientes.
ladCfg
"ladCfg": {
"diagnosticMonitorConfiguration": {
"eventVolume": "Medium",
"metrics": { ... },
"performanceCounters": { ... },
"syslogEvents": { ... }
},
"sampleRateInSeconds": 15
}
Esta estructura opcional controla la recopilación de métricas y registros para enviarlos al servicio de Métricas de
Azure y otros receptores de datos. Debe especificar performanceCounters , syslogEvents o ambos. Debe
especificar la estructura de metrics .
EL EM EN TO VA L UE
eventVolume (Opcional) controla el número de particiones creadas en la

tabla de almacenamiento. Debe ser uno de los siguientes
valores: "Large" , "Medium" o "Small" . Si no se
especifica, el valor predeterminado es "Medium" .
sampleRateInSeconds (Opcional) es el intervalo predeterminado entre la

recopilación de métricas sin procesar (sin agregar). La
frecuencia de muestreo más pequeña admitida es de 15
segundos. Si no se especifica, el valor predeterminado es
15 .
Métricas
"metrics": {
"resourceId": "/subscriptions/...",
"metricAggregation" : [
{ "scheduledTransferPeriod" : "PT1H" },
{ "scheduledTransferPeriod" : "PT5M" }
]
}
EL EM EN TO VA L UE
resourceId El identificador de recurso de Azure Resource Manager de la

VM o del conjunto de escalado de máquinas virtuales al que
pertenezca la VM. Esta configuración también debe
especificarse en caso de usar cualquier receptor de Json
BLOB en la configuración.
scheduledTransferPeriod La frecuencia con la que se computarán métricas agregadas

y se transferirán a Métricas de Azure, expresadas en forma
de intervalo de tiempo ISO 8601. El período de transferencia
mínimo es de 60 segundos, es decir, PT1M. Debe especificar
al menos un elemento scheduledTransferPeriod.
Se recopilan muestras de las métricas especificadas en la sección performanceCounters cada 15 segundos o a la

frecuencia de muestreo definida para el contador de forma explícita. Si aparecen varias frecuencias de
scheduledTransferPeriod (como en el ejemplo), cada agregación se computa de forma independiente.
performanceCounters
"performanceCounters": {
"sinks": "",
{
"type": "builtin",
"class": "Processor",
"counter": "PercentIdleTime",
"counterSpecifier": "/builtin/Processor/PercentIdleTime",
"sampleRate": "PT15S",
"unit": "Percent",
"annotation": [
{
"displayName" : "Aggregate CPU %idle time",
"locale" : "en-us"
}
]
}
]
}
Esta sección opcional controla la recopilación de métricas. Se agregan muestras sin procesar para cada elemento
scheduledTransferPeriod a fin de generar estos valores:
mean
minimum
maximum
last-collected value
Número de muestras sin procesar usadas para computar el agregado
EL EM EN TO VA L UE
sinks (Opcional) es una lista separada por comas de nombres de

receptores a los que LAD envía los resultados de las métricas
agregadas. Todas las métricas agregadas se publican en cada
receptor indicado. Consulte sinksConfig. Ejemplo:
"EHsink1, myjsonsink" .
type Identifica el proveedor real de la métrica.
class Junto con "counter", identifica la métrica específica en el

espacio de nombres del proveedor.
counter Junto con "class", identifica la métrica específica en el espacio

de nombres del proveedor.
counterSpecifier Identifica la métrica específica en el espacio de nombres de

Métricas de Azure.
condición (Opcional) selecciona una instancia específica del objeto al

que se aplica la métrica o selecciona la agregación en todas
las instancias de este objeto. Para más información, consulte
las definiciones de las métricas builtin .
sampleRate Intervalo de ISO 8601 que establece la frecuencia de

recopilación de muestras sin procesar de esta métrica. Si no
se establece, el intervalo de recopilación se establece a partir
del valor de sampleRateInSeconds. La frecuencia de
muestreo más corta admitida es de 15 segundos (PT15S).
unit Debería ser una de estas cadenas: "Count", "Bytes",

"Seconds", "Percent", "CountPerSecond", "BytesPerSecond" o
"Millisecond". Define la unidad para la métrica. Los
consumidores de los datos recopilados esperan que los
valores de los datos recopilados coincidan con esta unidad.
LAD omite este campo.
DisplayName La etiqueta (en el idioma especificado por la configuración

regional correspondiente) que va a adjuntarse a estos datos
en el servicio de Métricas de Azure. LAD omite este campo.
El elemento counterSpecifier es un identificador arbitrario. Los consumidores de métricas, como la característica

de creación de grafos y desencadenamiento alertas de Azure Portal, usan counterSpecifier como "clave" para
identificar una métrica o instancia de una métrica. Para las métricas de builtin , se recomienda usar valores
counterSpecifier que empiecen por /builtin/ . Si va a recopilar una instancia específica de una métrica, se
recomienda adjuntar el identificador de la instancia al valor de counterSpecifier. He aquí algunos ejemplos:
/builtin/Processor/PercentIdleTime : tiempo de inactividad promediado en todas las vCPU
/builtin/Disk/FreeSpace(/mnt) : espacio libre para el elemento /mnt filesystem
/builtin/Disk/FreeSpace : espacio libre promediado entre todos los elementos filesystem montados
Ni LAD ni Azure Portal esperan que el valor de counterSpecifier concuerde con ningún patrón. Sea coherente en
el modo de construcción de valores counterSpecifier.
Si especifica performanceCounters , LAD siempre escribe datos en una tabla en Azure Storage. Puede hacer que se
escriban los mismos datos a blobs JSON o Event Hubs, pero no puede deshabilitar el almacenamiento de datos
en una tabla. Todas las instancias de la extensión de diagnóstico configuradas para usar el mismo nombre de
cuenta de almacenamiento y el mismo punto de conexión agregan sus métricas y registros a la misma tabla. Si
hay demasiadas máquinas virtuales escribiendo en la misma partición de tabla, Azure puede limitar las
escrituras a dicha partición. El valor eventVolume hace que las entradas se repartan entre 1 (Small), 10
(Medium) o 100 (Large) particiones diferentes. Por lo general, un valor "Medium" es suficiente para asegurarse
de que el tráfico no se vea limitado. La característica de las métricas de Azure de Azure Portal usa los datos de
esta tabla para crear gráficos o desencadenar alertas. El nombre de tabla es la concatenación de las siguientes
cadenas:
WADMetrics
El elemento "scheduledTransferPeriod" para los valores agregados almacenados en la tabla
P10DV2S
Una fecha en formato "AAAAMMDD", que cambia cada 10 días
Algunos ejemplos son WADMetricsPT1HP10DV2S20170410 y WADMetricsPT1MP10DV2S20170609 .
syslogEvents
"syslogEvents": {
"sinks": "",
"facilityName1": "minSeverity",
"facilityName2": "minSeverity",
...
}
}
Esta sección opcional controla la recopilación de eventos de registro de syslog. Si se omite la sección, no se
captura ningún evento de syslog.
La recopilación de syslogEventConfiguration tiene una entrada para cada recurso de syslog de interés. Si el valor
de minSeverity es "NONE" para un recurso en particular, o si el recurso no aparece en el elemento, no se captura
ningún evento de dicho recurso.
EL EM EN TO VA L UE
sinks Es una lista separada por comas de nombres de receptores

en los que se publican los eventos de registros individuales.
Todos los eventos de registro que coincidan con las
restricciones de syslogEventConfiguration se publican en
cada receptor indicado. Ejemplo: "EHforsyslog"
facilityName Es un nombre de recurso de syslog (como "LOG_USER" o

"LOG_LOCAL0"). Consulte la sección "facility" de la página
man de syslog para obtener la lista completa.
minSeverity Es un nivel de gravedad de syslog (como "LOG_ERR" o

"LOG_INFO"). Consulte la sección "level" de la página man de
syslog para obtener la lista completa. La extensión captura
eventos enviados al recurso al nivel especificado o uno
superior.
Si especifica syslogEvents , LAD siempre escribe datos en una tabla en Azure Storage. Puede hacer que se
escriban los mismos datos a blobs JSON o Event Hubs, pero no puede deshabilitar el almacenamiento de datos
en una tabla. El compartimiento de la creación de particiones para esta tabla es el mismo descrito para
performanceCounters . El nombre de tabla es la concatenación de las siguientes cadenas:
LinuxSyslog
Una fecha en formato "AAAAMMDD", que cambia cada 10 días
Algunos ejemplos son LinuxSyslog20170410 y LinuxSyslog20170609 .
perfCfg
Esta sección opcional controla la exclusión de consultas OMI arbitrarias.
"perfCfg": [
{
"namespace": "root/scx",
"query": "SELECT PercentAvailableMemory, PercentUsedSwap FROM SCX_MemoryStatisticalInformation",
"table": "LinuxOldMemory",
"frequency": 300,
"sinks": ""
}
]
EL EM EN TO VA L UE
espacio de nombres (Opcional) es el espacio de nombres OMI en el que la

consulta debería ejecutarse. Si no se especifica, el valor
predeterminado es "root/scx", implementado por los
proveedores multiplataforma de System Center.
Query Es la consulta de OMI que va a ejecutarse.
table (Opcional) es la tabla de almacenamiento de Azure, en la

cuenta de almacenamiento designada (consulte
Configuración protegida).
frequency (Opcional) es el número de segundos entre la ejecución de la

consulta. El valor predeterminado es de 300 (5 minutos) y el
mínimo es de 15 segundos.
sinks (Opcional) es una lista separada por comas de nombres de

receptores adicionales en los que deberían publicarse los
resultados de las métricas de muestra sin procesar. Ni la
extensión ni Métricas de Azure computan ninguna
agregación de estos ejemplos sin procesar.
Deben especificarse "table", "sinks" o ambos.

fileLogs
Controla la captura de los archivos de registro. LAD captura nuevas líneas de texto a medida que se escriben en
el archivo y las escribe en filas de tabla o en cualquier receptor especificado (de JsonBlob o EventHub).
NOTE
Un subcomponente de LAD denominado omsagent captura fileLogs. Para recopilar fileLogs, debe asegurarse de que el
usuario omsagent tenga permisos de lectura en los archivos especificados, así como permisos de ejecución en todos los
directorios de la ruta de acceso a ese archivo. Puede comprobarlo si ejecuta
sudo su omsagent -c 'cat /path/to/file' después de instalar LAD.
"fileLogs": [
{
"file": "/var/log/mydaemonlog",
"table": "MyDaemonEvents",
"sinks": ""
}
]
EL EM EN TO VA L UE
archivo Es la ruta de acceso completa del archivo de registro que va

a inspeccionarse y capturarse. La ruta de acceso debe
denominar un único archivo. No puede denominar un
directorio ni contener caracteres comodín. La cuenta de
usuario "omsagent" debe tener acceso de lectura a la ruta de
acceso del archivo.
table (Opcional) es la tabla de Azure Storage en la cuenta de

almacenamiento designada (especificada en la configuración
protegida) en la que se escriben nuevas líneas de la "cola" del
archivo.
sinks (Opcional) es una lista separada por combas de nombres de

receptores adicionales a la que se envían líneas de registro.
Deben especificarse "table", "sinks" o ambos.
Métricas admitidas por el proveedor de builtin

El proveedor de métricas builtin es una fuente de métricas del máximo interés para una gran cantidad de
usuarios. Estas métricas se dividen en cinco clases amplias:
Procesador
Memoria
Red
Sistema de archivos
Disco
Métricas builtin para la clase Processor
La clase de métricas Processor proporciona información sobre el uso del procesador en la máquina virtual. Al
agregar porcentajes, el resultado es el promedio de todas las CPU. En una máquina virtual de dos vCPU, si una
de ellas estaba activa al 100 % y la otra, inactiva al 100 %, el valor de PercentIdleTime sería de 50. Si la actividad
de cada vCPU era del 50 % durante el mismo período, el resultado indicado también sería de 50. En una
máquina virtual de cuatro vCPU, si una de ellas estaba activa al 100 % y todas las demás, inactivas, el valor de
PercentIdleTime sería de 75.
C O UN T ER SIGN IF IC A DO
PercentIdleTime Porcentaje de tiempo del período de agregación durante el

que los procesadores ejecutaban el bucle de inactividad del
kernel
PercentProcessorTime Porcentaje de tiempo de ejecución de un subproceso no

inactivo
PercentIOWaitTime Porcentaje de tiempo de espera para la finalización de

operaciones de E/S
PercentInterruptTime Porcentaje de tiempo de ejecución de interrupciones de

hardware o software y DPC (llamadas a procedimiento
aplazadas)
PercentUserTime Del tiempo no inactivo durante el período de agregación, el

porcentaje empleado en modo de usuario en prioridad
normal
PercentNiceTime Del tiempo no inactivo, el porcentaje empleado en prioridad

disminuida (nice)
PercentPrivilegedTime Del tiempo no inactivo, el porcentaje empleado en modo

privilegiado (kernel)
Los cuatro primeros contadores deberían sumar un 100 %. Los tres últimos contadores también suman 100 %.
Subdividen la suma de PercentProcessorTime, PercentIOWaitTime y PercentInterruptTime.
Para obtener un único agregado de métricas de todos los procesadores, establezca
"condition": "IsAggregate=TRUE" . Para obtener una métrica para un procesador específico, como el segundo
procesador lógico de una máquina virtual de cuatro vCPU, establezca "condition": "Name=\\"1\\"" . Los
números de procesador lógico se encuentran en el rango [0..n-1] .
Métricas builtin para la clase Memory
La clase de métricas Memory proporciona información sobre utilización, paginación e intercambio de memoria.
AvailableMemory Memoria física disponible en MiB
PercentAvailableMemory Memoria física disponible en forma de porcentaje del total de

memoria
UsedMemory Memoria física en uso (MiB)
PercentUsedMemory Memoria física en uso en forma de porcentaje del total de

memoria
PagesPerSec Paginación total (lectura y escritura)
PagesReadPerSec Páginas leídas desde la memoria auxiliar (archivo de

intercambio, archivo de programa, archivo asignado, etc.)
PagesWrittenPerSec Páginas escritas en la memoria auxiliar (archivo de

intercambio, archivo asignado, etc.)
AvailableSwap Espacio de intercambio sin usar (MiB)
PercentAvailableSwap Espacio de intercambio sin usar en forma de porcentaje del

total de intercambio
UsedSwap Espacio de intercambio (MiB) en uso
PercentUsedSwap Espacio de intercambio en uso en forma de porcentaje del

total de intercambio
Esta clase de métricas tiene una sola instancia. El atributo "condition" no tiene valores de configuración útiles y
debería omitirse.
Métricas builtin para la clase Network
La clase de métricas Network proporciona información sobre la actividad de red de una interfaz de red concreta
desde el arranque. LAD no expone las métricas de ancho de banda, las cuales pueden recuperarse a partir de
métricas de host.
BytesTransmitted Total de bytes enviados desde el arranque
BytesReceived Total de bytes recibidos desde el arranque
BytesTotal Total de bytes enviados o recibidos desde el arranque
PacketsTransmitted Total de paquetes enviados desde el arranque
PacketsReceived Total de paquetes recibidos desde el arranque
TotalRxErrors Número de errores de recepción desde el arranque
TotalTxErrors Número de errores de transmisión desde el arranque
TotalCollisions Número de colisiones notificadas por los puertos de red

desde el arranque
Aunque esta clase está instanciada, LAD no admite la captura de agregados de métricas Network de todos los
dispositivos de red. Para obtener las métricas de una interfaz instanciada, como eth0, establezca
"condition": "InstanceID=\\"eth0\\"" .
Métricas builtin para la clase Filesystem

La clase de métricas Filesystem proporciona información sobre el uso del sistema de archivos. Los valores
absolutos y porcentuales se notifican como se hubieran mostrado a un usuario normal (no raíz).
FreeSpace Espacio disponible en disco en bytes
UsedSpace Espacio usado en disco en bytes
PercentFreeSpace Porcentaje de espacio libre
PercentUsedSpace Porcentaje de espacio usado
PercentFreeInodes Porcentaje de inodes sin usar

PercentUsedInodes Porcentaje de inodes asignados (en uso) sumado de todos

los sistemas de archivos
BytesReadPerSecond Bytes leídos por segundo
BytesWrittenPerSecond Bytes escritos por segundo
BytesPerSecond Bytes leídos o escritos por segundo
ReadsPerSecond Operaciones de lectura por segundo
WritesPerSecond Operaciones de escritura por segundo
TransfersPerSecond Operaciones de lectura o escritura por segundo
Los valores agregados de todos los archivos del sistema pueden obtenerse estableciendo
"condition": "IsAggregate=True" . Los valores para un sistema de archivos montado específico, como "/mnt",
pueden obtenerse estableciendo "condition": 'Name="/mnt"' .
NOTA : Si usa Azure Portal en lugar de JSON, el formato correcto para el campo de condición es Name="/mnt".
Métricas builtin para la clase Disk
La clase de métricas Disk proporciona información sobre el uso de dispositivos de disco. Estas estadísticas se
aplican a toda la unidad. Si hay varios sistemas de archivos en un dispositivo, los contadores para dicho
dispositivo están, de hecho, agregados en todos ellos.
ReadsPerSecond Operaciones de lectura por segundo
WritesPerSecond Operaciones de escritura por segundo
TransfersPerSecond Total de operaciones por segundo
AverageReadTime Promedio de segundos por operación de lectura
AverageWriteTime Promedio de segundos por operación de escritura
AverageTransferTime Promedio de segundos por operación
AverageDiskQueueLength Promedio de operaciones de disco en cola
ReadBytesPerSecond Número de bytes leídos por segundo
WriteBytesPerSecond Número de bytes escritos por segundo
BytesPerSecond Número de bytes leídos o escritos por segundo
Los valores agregados de todos los discos pueden obtenerse estableciendo "condition": "IsAggregate=True" .
Para obtener información para un dispositivo en concreto (por ejemplo, /dev/sdf1), establezca
"condition": "Name=\\"/dev/sdf1\\"" .
Instalación y configuración de LAD 3.0
Azure CLI
Si suponemos que la configuración protegida se encuentra en el archivo ProtectedSettings.json y que la
información de configuración pública está en PublicSettings.json, ejecute este comando:
az vm extension set --publisher Microsoft.Azure.Diagnostics --name LinuxDiagnostic --version 3.0 --resource-

group <resource_group_name> --vm-name <vm_name> --protected-settings ProtectedSettings.json --settings
PublicSettings.json
El comando supone que se está usando el modo de Administración de recursos de Azure de la CLI de Azure. Para
configura LAD para máquinas virtuales con el modelo de implementación clásica (ASM), cambie al modo "asm"
( azure config mode asm ) y omita el nombre del grupo de recursos en el comando. Para obtener más
información, consulte la documentación de la CLI multiplataforma.
PowerShell
Si suponemos que la configuración protegida se encuentra en la variable $protectedSettings y que la
información de configuración pública está en la variable $publicSettings , ejecute este comando:
Set-AzVMExtension -ResourceGroupName <resource_group_name> -VMName <vm_name> -Location <vm_location> -

ExtensionType LinuxDiagnostic -Publisher Microsoft.Azure.Diagnostics -Name LinuxDiagnostic -SettingString
$publicSettings -ProtectedSettingString $protectedSettings -TypeHandlerVersion 3.0
Una configuración de LAD 3.0 de ejemplo

Conforme a las anteriores definiciones, a continuación hay un ejemplo de configuración de extensión de LAD 3.0
con una explicación. Para aplicar este ejemplo a su caso, debería usar su propio nombre de cuenta de
almacenamiento, token de SAS de cuenta y tokens de SAS de Event Hubs.
NOTE
Dependiendo de si usa la CLI de Azure o PowerShell para instalar LAD, el método para proporcionar la configuración
pública y protegida será diferente. Si usa la CLI de Azure, guarde la siguiente configuración en ProtectedSettings.json y
PublicSettings.json para usarla con el comando de ejemplo anterior. Si usa PowerShell, guarde la configuración en
$protectedSettings y $publicSettings mediante la ejecución de $protectedSettings = '{ ... }' .
Configuración protegida
Esta configuración protegida define:
Una cuenta de almacenamiento
Un token de SAS de cuenta que coincida
Varios receptores (Json BLOB o Event Hubs con tokens SAS)
{
"storageAccountSasToken": "sv=xxxx-xx-xx&ss=bt&srt=co&sp=wlacu&st=yyyy-yy-yyT21%3A22%3A00Z&se=zzzz-zz-
zzT21%3A22%3A00Z&sig=fake_signature",
"sinksConfig": {
"sink": [
{
"name": "SyslogJsonBlob",
"type": "JsonBlob"
},
{
"name": "FilelogJsonBlob",
"type": "JsonBlob"
},
{
"name": "LinuxCpuJsonBlob",
"type": "JsonBlob"
},
{
"name": "MyJsonMetricsBlob",
"type": "JsonBlob"
},
{
"name": "LinuxCpuEventHub",
"type": "EventHub",
"sasURL": "https://youreventhubnamespace.servicebus.windows.net/youreventhubpublisher?
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=fake_signature&
se=1808096361&skn=yourehpolicy"
},
{
"name": "MyMetricEventHub",
"type": "EventHub",
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&sk
n=yourehpolicy"
},
{
"name": "LoggingEventHub",
"type": "EventHub",
sr=https%3a%2f%2fyoureventhubnamespace.servicebus.windows.net%2fyoureventhubpublisher%2f&sig=yourehpolicy&se
=1808096361&skn=yourehpolicy"
}
]
}
}
Estos valores públicos hacen que LAD:
Cargue métricas de porcentaje de tiempo de procesador y espacio usado en disco en la tabla WADMetrics* .
Cargue mensajes del recurso de syslog "user" y la gravedad "info" en la tabla LinuxSyslog* .
Cargue resultados sin formato de consultas OMI (PercentProcessorTime y PercentIdleTime) en la tabla
llamada LinuxCPU .
Cargue líneas anexadas en el archivo /var/log/myladtestlog en la tabla MyLadTestLog .
En cualquier caso, también se cargan datos en:
Azure Blob Storage (el nombre del contenedor es el definido en el receptor de JSON Blob)
El punto de conexión de Event Hubs (especificado en el receptor de Event Hubs)
{
"StorageAccount": "yourdiagstgacct",
"StorageAccount": "yourdiagstgacct",
"ladCfg": {
"sampleRateInSeconds": 15,
"diagnosticMonitorConfiguration": {
"performanceCounters": {
"sinks": "MyMetricEventHub,MyJsonMetricsBlob",
{
"unit": "Percent",
"type": "builtin",
"counter": "PercentProcessorTime",
"counterSpecifier": "/builtin/Processor/PercentProcessorTime",
"annotation": [
{
"locale": "en-us",
"displayName": "Aggregate CPU %utilization"
}
],
"class": "Processor"
},
{
"unit": "Bytes",
"type": "builtin",
"counter": "UsedSpace",
"counterSpecifier": "/builtin/FileSystem/UsedSpace",
"annotation": [
{
"locale": "en-us",
"displayName": "Used disk space on /"
}
],
"condition": "Name=\"/\"",
"class": "Filesystem"
}
]
},
"metrics": {
"metricAggregation": [
{
"scheduledTransferPeriod": "PT1H"
},
{
"scheduledTransferPeriod": "PT1M"
}
],
"resourceId":
"/subscriptions/your_azure_subscription_id/resourceGroups/your_resource_group_name/providers/Microsoft.Compu
te/virtualMachines/your_vm_name"
},
"eventVolume": "Large",
"syslogEvents": {
"sinks": "SyslogJsonBlob,LoggingEventHub",
"LOG_USER": "LOG_INFO"
}
}
}
},
"perfCfg": [
{
"query": "SELECT PercentProcessorTime, PercentIdleTime FROM SCX_ProcessorStatisticalInformation WHERE
Name='_TOTAL'",
"table": "LinuxCpu",
"frequency": 60,
"sinks": "LinuxCpuJsonBlob,LinuxCpuEventHub"
}
],
"fileLogs": [
{
{
"file": "/var/log/myladtestlog",
"table": "MyLadTestLog",
"sinks": "FilelogJsonBlob,LoggingEventHub"
}
]
}
El elemento resourceId de la configuración debe coincidir con el de la VM o el del conjunto de escalado de

La característica de creación de gráficos y desencadenamiento de alertas de métricas de la plataforma de
Azure conoce el elemento resourceId de la máquina virtual en la que se esté trabajando. Espera encontrar los
datos de la máquina virtual mediante el elemento resourceId de la clave de búsqueda.
Si usa el escalado automático de Azure, el elemento resourceId de la configuración del escalado automático
debe coincidir con el usado por LAD.
El elemento resourceId se compila en los nombres de instancias de JSON Blob escritas por LAD.
Consulta de los datos

Use Azure Portal para consultar datos de rendimiento o establecer alertas:
Los datos de performanceCounters se almacenan en una tabla de Azure Storage. Las API de Azure Storage están
disponibles para múltiples lenguajes y plataformas.
Los datos enviados a receptores de Json BLOB se almacenan en blobs de la cuenta de almacenamiento a los que
se dio nombre en la Configuración protegida. Puede consumir los datos de blob con cualquier API de Azure Blob
Storage.
Además, puede usar las siguientes herramientas de la interfaz de usuario para acceder a los datos de Azure
Storage:
Explorador de servidores de Visual Studio.
Explorador de Microsoft Azure Storage.
Esta instantánea de una sesión del Explorador de Microsoft Azure Storage muestra las tablas y los contenedores
de Azure Storage generados a partir de una extensión de LAD 3.0 configurada correctamente en una máquina
virtual de prueba. La imagen no coincide exactamente con la configuración de ejemplo de LAD 3.0.
Consulte los documentos de EventHubs pertinentes para obtener información sobre cómo consumir mensajes
publicados en un punto de conexión de EventHubs.
Pasos siguientes
Cree alertas de métricas de Azure Monitor para las métricas que recopile.
Cree gráficos de supervisión para las métricas.
Obtenga información sobre cómo crear un conjunto de escalado de máquinas virtuales con sus propias
métricas para controlar el escalado automático.
Recopilación de métricas personalizadas para
una máquina virtual Linux con el agente de
InfluxData Telegraf
Mediante Azure Monitor, puede recopilar métricas personalizadas a través de los datos de telemetría de la
aplicación, un agente que se ejecuta en los recursos de Azure o, incluso, fuera del sistema de supervisión. A
continuación, puede enviarlas directamente a Azure Monitor. En este artículo, se proporcionan
instrucciones sobre cómo implementar al agente de InfluxData Telegraf en una máquina virtual Linux en
Azure y configurar el agente para que publique las métricas en Azure Monitor.
Agente de InfluxData Telegraf

Telegraf es un agente controlado por complemento que habilita la recopilación de métricas más de 150
orígenes diferentes. Según las cargas de trabajo que se ejecuten en la máquina virtual, puede configurar al
agente para aprovechar los complementos de entrada especializados para recopilar métricas. Algunos
ejemplos son MySQL, NGINX y Apache. Mediante el uso de complementos de salida, el agente, a
continuación, puede escribir en los destinos que elija. El agente de Telegraf se integra directamente con la
API REST de métricas personalizadas de Azure Monitor. Admite un complemento de salida de Azure
Monitor. Mediante este complemento, el agente puede recopilar métricas específicas de la carga de trabajo
de la máquina virtual Linux y enviarlas como métricas personalizadas a Azure Monitor.
NOTE
Las métricas personalizadas no se admiten en todas las regiones. Las regiones admitidas se enumeran aquí.
Envío de métricas personalizadas

En este tutorial, implementamos una máquina virtual Linux que ejecuta el sistema operativo Ubuntu 16.04
LTS. El agente de Telegraf es compatible con la mayoría de los sistemas operativos Linux. En el portal de
descarga de InfluxData están disponibles los paquetes Debian y RPM, además de los archivos binarios de
Linux sin empaquetar. Consulte esta guía de instalación de Telegraf para conocer instrucciones y opciones
de instalación adicionales.
NOTE
Si quiere migrar reglas de alertas clásicas y usar una máquina virtual de Linux existente, asegúrese de que la
máquina virtual tenga establecida una identidad asignada por el sistema en Activado .
Cree una nueva máquina virtual Linux:

1. Seleccione la opción Crear un recurso en el panel de navegación izquierdo.
2. Busque Máquina vir tual .
3. Seleccione Ubuntu 16.04 LTS y seleccione Crear .
4. Especifique un nombre de máquina virtual como MyTelegrafVM .
5. Deje el tipo de disco como SSD . A continuación, proporcione un Nombre de usuario , por ejemplo,
usuarioAzure .
6. En Tipo de autenticación , seleccione Contraseña . A continuación, escriba una contraseña que
utilizará más adelante para conectarse mediante SSH a la máquina virtual.
7. Elija Crear nuevo grupo de recursos . A continuación, indique un nombre, como
miGrupoDeRecursos . Elija su Ubicación . Después, seleccione Aceptar .
8. Seleccione un tamaño para la máquina virtual. Puede filtrar por Tipo de proceso o Tipo de disco ,
por ejemplo.
9. En la página Configuración , en Red > Grupo de seguridad de red > Seleccionar puer tos de
entrada públicos , seleccione HTTP y SSH (22) . Deje el resto de valores predeterminados y
10. En la página de resumen, seleccione Crear para iniciar la implementación de la máquina virtual.
11. La máquina virtual se ancla al panel de Azure Portal. Una vez completada la implementación, se
abrirá automáticamente el resumen de la máquina virtual.
12. En el panel de la máquina virtual, vaya a la pestaña Identidad . Asegúrese de que la máquina virtual
tiene una identidad asignada por el sistema establecida en Activada .
Conexión a la máquina virtual

Cree una conexión SSH con la máquina virtual. Seleccione el botón Conectar en la página de información
general de la máquina virtual.
En la página Connect to vir tual machine (Conexión a una máquina virtual), mantenga las opciones
predeterminadas para conectarse por nombre DNS a través del puerto 22. En Iniciar sesión con la
cuenta local de VM se muestra un comando de conexión. Seleccione el botón para copiar el comando. En
el ejemplo siguiente se muestra el aspecto que tiene el comando de conexión SSH:
ssh azureuser@XXXX.XX.XXX
Pegue el comando de conexión SSH en un shell, como Azure Cloud Shell o Bash en Ubuntu o Windows, o
bien use un cliente de SSH de su elección para crear la conexión.
Instalación y configuración de Telegraf

Para instalar el paquete de Telegraf para Debian en la máquina virtual, ejecute los siguientes comandos
desde la sesión SSH:
# download the package to the VM

wget https://dl.influxdata.com/telegraf/releases/telegraf_1.8.0~rc1-1_amd64.deb
# install the package
sudo dpkg -i telegraf_1.8.0~rc1-1_amd64.deb
El archivo de configuración de Telegraf define las operaciones de Telegraf. De forma predeterminado, se

instala un archivo de configuración de ejemplo en la ruta de acceso /etc/telegraf/telegraf.conf . El
archivo de configuración de ejemplo enumera todos los posibles complementos de entrada y salida. Sin
embargo, vamos a crear un archivo de configuración personalizado y haremos que el agente lo use; para
ello, hay que ejecutar los siguientes comandos:
# generate the new Telegraf config file in the current directory

telegraf --input-filter cpu:mem --output-filter azure_monitor config > azm-telegraf.conf
# replace the example config with the new generated config

sudo cp azm-telegraf.conf /etc/telegraf/telegraf.conf
NOTE
El código anterior solo permite dos complementos de entrada: cpu y mem . Puede agregar más complementos de
entrada, en función de la carga de trabajo que se ejecute en la máquina. Algunos ejemplos son Docker, MySQL y
NGINX. Para obtener una lista completa de complementos de entrada, consulte la sección Configuración
adicional.
Por último, para que el agente se inicie con la nueva configuración, hacemos que el agente se detenga y se
inicie mediante los siguientes comandos:
# stop the telegraf agent on the VM

sudo systemctl stop telegraf
# start the telegraf agent on the VM to ensure it picks up the latest configuration
sudo systemctl start telegraf
Ahora, el agente recopilará las métricas de cada uno de los complementos de entrada especificados y los
emitirá a Azure Monitor.
Trazado de las métricas de Telegraf en Azure Portal

1. Abra Azure Portal.
2. Vaya a la pestaña Super visar . Seleccione Métricas .
3. Seleccione la máquina virtual en el selector de recursos.

4. Seleccione el espacio de nombres Telegraf/CPU y la métrica usage_system . Puede elegir filtrar
por las dimensiones de esta métrica, o dividir según dichas dimensiones.
Configuración adicional
En el tutorial anterior, se proporciona información sobre cómo configurar el agente de Telegraf para
recopilar métricas de algunos complementos básicos de entrada. El agente de Telegraf es compatible con
más de 150 complementos de entrada, con algunas opciones de configuración adicionales de
compatibilidad. InfluxData ha publicado una lista de complementos compatibles e instrucciones en inglés
sobre cómo configurarlas.
Además, en este tutorial usó el agente de Telegraf para emitir métricas acerca de la máquina virtual en la
que se implementó el agente. El agente de Telegraf también se puede usar como un recopilador y centro de
reenvío de las métricas para otros recursos. Para obtener más información sobre cómo configurar el
agente para que emita métricas para otros recursos de Azure, consulte Azure Monitor Custom Metric
Output for Telegraf (Salida de métricas personalizadas de Azure Monitor para Telegraf).
Cuando ya no los necesite, puede eliminar el grupo de recursos, la máquina virtual y todos los recursos
relacionados. Para ello, seleccione el grupo de recursos de la máquina virtual y seleccione Eliminar .
Después, confirme el nombre del grupo de recursos que hay que eliminar.
Pasos siguientes
Solución de problemas de la extensión de máquina
virtual de Log Analytics en Azure Monitor
En este artículo se proporciona ayuda y posibles soluciones para resolver los errores que puedan surgir con la
extensión de máquinas virtuales de Log Analytics para aquellas máquinas virtuales que se ejecutan en Microsoft
Azure para Windows y Linux.
Para comprobar el estado de la extensión, realice los pasos siguientes en Azure Portal.
1. Inicie sesión en el Portal de Azure.
2. En Azure Portal, haga clic en Todos los ser vicios . En la lista de recursos, escriba Máquinas vir tuales .
Cuando comience a escribir, la lista se filtrará en función de la entrada. Seleccione Máquinas vir tuales .
3. En la lista de máquinas virtuales, busque y seleccione la que le interesa.
4. En la máquina virtual, haga clic en Extensiones .
5. En la lista, compruebe si la extensión de Log Analytics está habilitada. Para Linux, el agente aparece como
OMSAgentforLinux y para Windows, el agente aparece como MicrosoftMonitoringAgent .
6. Haga clic en la extensión para ver los detalles.

Solución de problemas con la extensión de máquinas virtuales de
Azure en Windows.
Si la extensión de la máquina virtual Microsoft Monitoring Agent no se instala o no envía informes, puede realizar
los pasos siguientes para solucionar el problema.
1. Siga los pasos de KB 2965986 para comprobar que el agente de máquina virtual de Azure está instalado y
funciona correctamente.
También puede revisar el archivo de registro del agente de máquina virtual
C:\WindowsAzure\logs\WaAppAgent.log
Si el registro no existe, el agente de máquina virtual no estará instalado.
Instale el agente de máquina virtual de Azure.
2. Revise los archivos de registro de la extensión de máquina virtual de Microsoft Monitoring Agent en
C:\Packages\Plugins\Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent .
3. Asegúrese de que la máquina virtual puede ejecutar scripts de PowerShell.
4. Asegúrese de que no se hayan modificado los permisos en C:\Windows\temp.
5. Consulte el estado de Microsoft Monitoring Agent, para lo que debe escribir lo siguiente en una ventana de
PowerShell con privilegios elevados en la máquina virtual
(New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg').GetCloudWorkspaces() | Format-List .
6. Revise los archivos de registro de instalación de Microsoft Monitoring Agent en
C:\Windows\System32\config\systemprofile\AppData\Local\SCOM\Logs .
Para más información, consulte Solución de problemas de la extensión de máquina virtual de Microsoft Azure.
Solución de problemas con la extensión de máquinas virtuales en Linux

NOTE
Si la extensión de la máquina virtual del agente de Log Analytics para Linux no se instala o no envía informes,
puede realizar los pasos siguientes para solucionar el problema.
1. Si el estado de la extensión es desconocido, compruebe si el agente de máquina virtual de Azure está instalado
y funciona correctamente revisando el archivo de registro del agente de máquina virtual /var/log/waagent.log .
Si el registro no existe, el agente de máquina virtual no estará instalado.
Instale el agente de máquina virtual de Azure en máquinas virtuales Linux.
2. Para otros estados incorrectos, revise los archivos de registro de extensión de máquina virtual del agente de
Log Analytics para Linux en
/var/log/azure/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux/*/extension.log y
/var/log/azure/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux/*/CommandExecution.log .
3. Si el estado de la extensión es correcto, pero no se están cargando datos, revise los archivos de registro del
agente de Log Analytics para Linux en /var/opt/microsoft/omsagent/log/omsagent.log .
Para más información, consulte Solución de problemas de la extensión de máquina virtual de Linux Azure.
Pasos siguientes
Para obtener instrucciones adicionales para solucionar problemas relacionados con el agente de Log Analytics para
Linux que se hospeda en equipos externos a Azure, vea Troubleshoot Azure Log Analytics Linux Agent (Solución de
problemas del agente de Linux para Azure Log Analytics).
Procedimientos para solucionar problemas
relacionados con el agente de Log Analytics para
Windows
En este artículo se proporciona información sobre los errores que es posible que experimente con el agente de
Log Analytics para Windows en Azure Monitor y se sugieren posibles soluciones para resolverlos.
Si ninguno de estos pasos funciona, también están disponibles los siguientes canales de soporte técnico:
Los clientes con ventajas de soporte técnico Premier pueden abrir una solicitud de soporte técnico en Premier.
Los clientes con contratos de soporte técnico de Azure pueden abrir una solicitud de soporte técnico en Azure
Portal.
Visite la página de comentarios de Log Analytics para revisar los errores e ideas enviadas
https://aka.ms/opinsightsfeedback o registre uno nuevo.
Orígenes de solución de problemas importantes

Para ayudar a solucionar los problemas relacionados con el agente de Log Analytics para Windows, el agente
registra los eventos en el registro de eventos de Windows, concretamente en Aplicaciones y servicios\Operations
Manager.
Problemas de conectividad
Si el agente se comunica a través de un servidor proxy o un firewall, es posible que haya restricciones vigentes
que impidan la comunicación desde el equipo de origen y el servicio Azure Monitor. En caso de que se bloquee la
comunicación, debido a un error de configuración, se puede producir un error en el registro con un área de
trabajo al intentar instalar el agente o configurarlo después de la instalación para que notifique a un área de
trabajo adicional. Se puede producir un error de comunicación del agente después de un registro correcto. En esta
sección se describen los métodos para solucionar este tipo de problema con el agente de Windows.
Compruebe que el firewall o proxy está configurado para permitir los puertos y las direcciones URL descritas en
la tabla siguiente. Confirme también que la inspección de HTTP no está habilitada para el tráfico web, ya que
puede evitar un canal TLS seguro entre el agente y Azure Monitor.
O M IT IR IN SP EC C IÓ N DE
REC URSO DEL A GEN T E P UERTO S DIREC C IÓ N HTTPS
*.ods.opinsights.azure.com Puerto 443 Salida Sí
*.oms.opinsights.azure.com Puerto 443 Salida Sí
*.blob.core.windows.net Puerto 443 Salida Sí
*.agentsvc.azure- Puerto 443 Salida Sí

automation.net
Para obtener información sobre el firewall necesaria para Azure Government, vea Administración de Azure
Government. Si tiene previsto usar Hybrid Runbook Worker de Azure Automation para conectarse al servicio
Automation y registrarse en él para usar runbooks o soluciones de administración en el entorno, debe tener
acceso al número de puerto y las direcciones URL descritos en Configuración de la red para Hybrid Runbook
Worker.
Hay varias formas de comprobar si el agente se comunica de forma correcta con Azure Monitor.
Habilite la Evaluación de estado del agente de Azure Log Analytics en el área de trabajo. En el panel de
Agent Health, examine la columna Count of unresponsive agents (Número de agentes que no
responden) para ver rápidamente si aparece el agente.
Ejecute la consulta siguiente para confirmar que el agente envía un latido al área de trabajo que se ha
configurado para que le envíe notificaciones. Reemplace <ComputerName> con el nombre real del equipo.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
Si el equipo se comunica correctamente con el servicio, la consulta debe devolver un resultado. Si la

consulta no ha devuelto un resultado, compruebe primero que el agente está configurado para notificar al
área de trabajo correcta. Si está configurado correctamente, vaya al paso 3 y busque en el registro de
eventos de Windows para identificar si el agente registra el problema que podría estar impidiendo la
comunicación con Azure Monitor.
Otro método para identificar un problema de conectividad consiste en ejecutar la herramienta
TestCloudConnectivity . La herramienta se instala de forma predeterminada con el agente en la carpeta
%SystemRoot%\Archivos de programa\Microsoft Monitoring Agent\Agent. Desde un símbolo del sistema
con privilegios elevados, vaya a la carpeta y ejecute la herramienta. La herramienta devuelve los resultados
y resalta dónde se ha producido el error en la prueba (por ejemplo, si estaba relacionado con un puerto o
una dirección URL determinada que se ha bloqueado).
Filtre el registro de eventos de Operations Manager por Orígenes de eventos - Módulos de servicio de
mantenimiento, HealthService y Conector de servicio, y fíltrelo por Nivel de evento Advertencia y Error
para confirmar si ha escrito eventos de la tabla siguiente. Si se han escrito, revise los pasos de resolución
incluidos para cada evento posible.
ID. DE EVEN TO SO URC E DESC RIP C IÓ N RESO L UC IÓ N
2133 y 2129 Servicio de mantenimiento Error de conexión con el Este error se puede
servicio desde el agente producir cuando el agente
no se puede comunicar
directamente o a través de
un servidor proxy o
firewall con el servicio
Azure Monitor.
Compruebe la
configuración de proxy de
agente o que el firewall o
proxy de red permite el
tráfico TCP desde el
equipo al servicio.
2138 Módulos de servicio de Se requiere autenticación Configure las opciones del

mantenimiento del proxy proxy de agente y
especifique el nombre de
usuario y la contraseña
necesarios para
autenticarse con el
servidor proxy.
2129 Módulos de servicio de Error de conexión o error Compruebe la

mantenimiento de negociación TLS configuración TCP/IP del
adaptador de red y del
proxy de agente.
2127 Módulos de servicio de Error al enviar datos de Si solo se produce de

mantenimiento código de error recibido forma periódica durante el
día, podría ser
simplemente una
anomalía aleatoria que se
puede ignorar. Supervise
para comprender la
frecuencia con que sucede.
Si se produce con
frecuencia a lo largo del
día, compruebe la
configuración de red y de
proxy. Si en la descripción
se incluye el código de
error HTTP 404 y es la
primera vez que el agente
intenta enviar datos al
servicio, incluirá un error
500 con un código de
error 404 interno. 404
significa que no se ha
encontrado, lo que indica
que el área de
almacenamiento para la
nueva área de trabajo
todavía se está
aprovisionando. En el
siguiente reintento, los
datos se escribirán
correctamente en el área
de trabajo según lo
previsto. Un error HTTP
403 podría indicar un
problema de credenciales
o permisos. El error 403
incluye más información
para ayudar a solucionar
el problema.
4000 Conector de servicio Error de resolución de El equipo no pudo

nombre DNS resolver la dirección de
Internet que se ha usado
al enviar datos al servicio.
Esto podría deberse a la
configuración de
resolución DNS en el
equipo, la configuración
incorrecta del proxy o un
problema de DNS
temporal con el proveedor.
Si se produce de forma
periódica, se podría deber
a un problema transitorio
relacionado con la red.
4001 Conector de servicio Error de conexión al Este error se puede

servicio. producir cuando el agente
no se puede comunicar
directamente o a través de
un servidor proxy o
firewall con el servicio
Azure Monitor.
Compruebe la
configuración de proxy de
agente o que el firewall o
proxy de red permite el
tráfico TCP desde el
equipo al servicio.
4002 Conector de servicio El servicio ha devuelto el Este error se escribe

código de estado HTTP durante la fase de registro
403 en respuesta a una inicial del agente y verá
consulta. Póngase en una dirección URL similar
contacto con el a la siguiente:
administrador de servicios https://<workspaceID>.o
para el estado del servicio. ms.opinsights.azure.com/A
La consulta se reintentará gentService.svc/AgentTop
más tarde. ologyRequest. Un código
de error 403 significa
prohibido y se puede
deber a que la clave o el
identificador del área de
trabajo se hayan escrito
incorrectamente, o bien a
que la fecha y hora en el
equipo sean incorrectas. Si
la hora es +/-15 minutos
de la hora actual, la
incorporación produce un
error. Para corregir este
problema, actualice la
fecha o la zona horaria del
equipo Windows.
Problemas recopilación de datos

Después de instalar el agente y de que notifique a sus áreas de trabajo configuradas, es posible que deje de
recibir configuración o de recopilar o reenviar rendimiento, registros u otros datos para el servicio en función de
lo que se haya habilitado y destinado al equipo. Es necesario determinar si:
En el área de trabajo no está disponible un tipo de datos determinado o se trata de todos los datos.
El tipo de datos lo especifica una solución o se especifica como parte de la configuración de recopilación de
datos del área de trabajo.
Cuántos equipos se ven afectados. Cuántos equipos notifican al área de trabajo: uno o varios.
Funcionaba y se ha detenido a una hora concreta del día o nunca se ha recopilado.
La consulta de búsqueda de registros que se usa es sintácticamente correcta.
El agente ha recibido alguna vez su configuración de Azure Monitor.
El primer paso para solucionar problemas consiste en determinar si el equipo envía un evento de latido.
Heartbeat
| where Computer like "<ComputerName>"
| summarize arg_max(TimeGenerated, * ) by Computer
Si la consulta devuelve resultados, tendrá que determinar si no se ha recopilado un tipo de datos determinado y
se ha reenviado al servicio. La causa podría ser que el agente no reciba la configuración actualizada desde el
servicio, o bien algún otro síntoma que impida el funcionamiento normal del agente. Para solucionar problemas
adicionales, realice los pasos siguientes.
1. Abra un símbolo del sistema con privilegios elevados en el equipo y escriba
net stop healthservice && net start healthservice para reiniciar el servicio del agente.
2. Abra el registro de eventos de Operations Manager y busque los identificadores de evento 7023, 7024,
7025, 7028 y 1210 en Origen del evento HealthService. Estos eventos indican que el agente recibe
correctamente la configuración de Azure Monitor y que supervisan el equipo de forma activa. La
descripción del evento con el identificador 1210 también especificará en la última línea todas las
soluciones y la información que se incluyen en el ámbito de supervisión del agente.
3. Si después de unos minutos no ve los datos esperados en la visualización o los resultados de la consulta,
en función de si los ve desde una solución o desde Insight, desde el registro de eventos de Operations
Manager, busque Orígenes de eventos HealthService y Módulos de servicio de mantenimiento, y filtre
por Nivel de evento Advertencia y Error para confirmar si ha escrito eventos de la tabla siguiente.
8000 HealthService Este evento especificará si El id. de evento 2136 de la

un flujo de trabajo instancia de HealthService
relacionado con el de origen se escribe junto
rendimiento, los eventos u con este evento y puede
otro tipo de datos indicar que el agente no
recopilado no puede se puede comunicar con el
reenviar al servicio para la servicio, posiblemente
ingesta en el área de debido a una
trabajo. configuración incorrecta
de las opciones de proxy y
autenticación, a la
interrupción de la red, o
bien a que el firewall de
red o el proxy no permite
el tráfico TCP desde el
equipo al servicio.
10102 y 10103 Módulos de servicio de El flujo de trabajo no ha Esto puede ocurrir si el

mantenimiento podido resolver el origen contador de rendimiento
de datos. especificado o la instancia
no existen en el equipo o
se han definido
incorrectamente en la
configuración de datos del
área de trabajo. Si se trata
de un contador de
rendimiento especificado
por el usuario, compruebe
que la información
especificada sigue el
formato correcto y que
existe en los equipos de
destino.
26002 Módulos de servicio de El flujo de trabajo no ha Esto puede ocurrir si el

mantenimiento podido resolver el origen registro de eventos de
de datos. Windows especificado no
existe en el equipo. Este
error se puede omitir sin
problemas si el equipo no
espera que se registre este
registro de eventos; en
caso contrario, si se trata
de un registro de eventos
especificado por el
usuario, compruebe que la
información especificada
sea correcta.
Cómo solucionar problemas relacionados con el
agente de Log Analytics para Linux
En este artículo se proporciona información sobre los errores que es posible que experimente con el agente de
Log Analytics para Linux en Azure Monitor y se sugieren posibles soluciones para resolverlos.
Si ninguno de estos pasos funciona, también están disponibles los siguientes canales de soporte técnico:
Los clientes con ventajas de soporte técnico Premier pueden abrir una solicitud de soporte técnico en
Premier.
Los clientes con contratos de soporte técnico de Azure pueden abrir una solicitud de soporte técnico en Azure
Portal.
Diagnostique los problemas de OMI con la Guía de solución de problemas de OMI.
Registre un problema de GitHub.
Visite la página de comentarios de Log Analytics para revisar los errores e ideas enviadas
https://aka.ms/opinsightsfeedback o registre uno nuevo.
Ubicaciones de registro importantes y herramienta de recopilador de

registros
A RC H IVO PAT H
Archivo de registro del agente de Log Analytics para Linux /var/opt/microsoft/omsagent/<workspace

id>/log/omsagent.log
Archivo de registro de configuración del agente de Log /var/opt/microsoft/omsconfig/omsconfig.log

Analytics
Se recomienda usar nuestra herramienta de recopilador de registros para recuperar registros importantes para
solucionar problemas o antes de enviar un problema de GitHub. Puede leer más acerca de la herramienta y cómo
ejecutarla aquí.
Archivos de configuración importantes

C AT EGO RY UB IC A C IÓ N DEL A RC H IVO
syslog /etc/syslog-ng/syslog-ng.conf , /etc/rsyslog.conf o

/etc/rsyslog.d/95-omsagent.conf
Rendimiento, Nagios, Zabbix, salida de Log Analytics y agente /etc/opt/microsoft/omsagent/<workspace

general id>/conf/omsagent.conf
Configuraciones adicionales /etc/opt/microsoft/omsagent/<workspace

id>/conf/omsagent.d/*.conf
NOTE
Edición de archivos de configuración para los contadores de rendimiento, y Syslog se sobrescribe si la colección se
configura desde el menú de datos Configuración avanzada de Log Analytics en Azure Portal para el área de trabajo. Para
deshabilitar la configuración para todos los agentes, deshabilite la colección de Configuración avanzada de Log
Analytics o, para un único agente, ejecute lo siguiente:
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable'
Códigos de error de instalación

C Ó DIGO DE ERRO R SIGN IF IC A DO
NOT_DEFINED Dado que las dependencias necesarias No se pudo instalar auoms, instale el
no están instaladas, no se instalará el paquete auditd.
complemento de auoms auditd
2 Opción no válida proporcionada a la

agrupación de shell. Ejecute
sudo sh ./omsagent-
*.universal*.sh --help
para el uso
3 Ninguna opción proporcionada a la

agrupación de shell. Ejecute
sudo sh ./omsagent-
*.universal*.sh --help
para el uso.
4 Tipo de paquete no válido o

configuración de proxy no válida; los
paquetes omsagent-rpm.sh solo
pueden instalarse en sistemas basados
en RPM, y los paquetes
omsagent-deb.sh solo pueden
instalarse en sistemas basados en
Debian. Se recomienda usar el
instalador universal de la versión más
reciente. Además, revise para
comprobar la configuración de proxy.
5 La agrupación de shell se debe ejecutar

como raíz, o bien se devolvió el error
403 durante la incorporación. Ejecute el
comando con sudo .
6 Arquitectura de paquete no válida, o

bien se devolvió el error 200 durante la
incorporación; los paquetes
omsagent-x64.sh solo pueden
instalarse en sistemas de 64 bits, y los
paquetes omsagent- x86.sh solo
pueden instalarse en sistemas de 32
bits. Descargue el paquete correcto
para su arquitectura de la versión más
reciente.
17 No se pudo instalar el paquete de

OMS. Examine el resultado del
comando para conocer el error raíz.
19 No se pudo instalar el paquete de OMI.

Examine el resultado del comando para
conocer el error raíz.
20 No se pudo instalar el paquete de SCX.

Examine el resultado del comando para
conocer el error raíz.
21 No se pudieron instalar los kits del

proveedor. Examine el resultado del
comando para conocer el error raíz.
22 No se pudo instalar el paquete

integrado. Examine el resultado del
comando para conocer el error raíz
23 El paquete de SCX u OMI ya está

instalado. Use --upgrade en lugar de
--install para instalar la agrupación
de shell.
30 Error de agrupación interno. Registre

un problema de GitHub con los
detalles del resultado.
55 Versión de openssl no compatible, o

bien no se puede conectar con Azure
Monitor, o dpkg está bloqueado, o
falta el programa curl.
61 Falta la biblioteca ctypes de Python.

Instale la biblioteca ctypes de Python o
el paquete (python-ctypes).
62 Falta el programa tar, instale tar.
63 Falta el programa sed, instale sed.
64 Falta el programa curl, instale curl.
65 Falta el programa gpg, instale gpg.
Códigos de error de incorporación

2 Opción no válida proporcionada al script omsadmin. Ejecute

sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h
para el uso.
3 Configuración no válida proporcionada al script omsadmin.

Ejecute
sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h
para el uso.
4 Proxy no válido proporcionado al script omsadmin.

Compruebe el proxy y consulte nuestra documentación para
usar un proxy HTTP.
5 Error HTTP 403 recibido de Azure Monitor. Vea el resultado

completo del script omsadmin para obtener más información.
6 Error HTTP distinto de 200 recibido de Azure Monitor. Vea el

resultado completo del script omsadmin para obtener más
información.
7 No se puede conectar a Azure Monitor. Vea el resultado

completo del script omsadmin para obtener más información.
8 Error en la incorporación al área de trabajo de Log Analytics.

Vea el resultado completo del script omsadmin para obtener
más información.
30 Error interno de script. Registre un problema de GitHub con

los detalles del resultado.
31 Error al generar identificador de agente. Registre un problema

de GitHub con los detalles del resultado.
32 Error al generar los certificados. Vea el resultado completo del

script omsadmin para obtener más información.
33 Error al generar la metaconfiguración para omsconfig.

Registre un problema de GitHub con los detalles del
resultado.
34 El script de generación de la metaconfiguración no está

presente. Vuelva a intentar la incorporación con
sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w
<Workspace ID> -s <Workspace Key>
.
Habilitación del registro de depuración

Depuración del complemento de salida de OMS
FluentD permite niveles de registro específicos del complemento, lo que le permite especificar distintos niveles
de registro para entradas y salidas. Para especificar un nivel de registro distinto para la salida de OMS, edite la
configuración del agente general en /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf .
En el complemento de salida de OMS, antes del final del archivo de configuración, cambie la propiedad
log_level de info a debug :
<match oms.** docker.**>
type out_oms
log_level debug
num_threads 5
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
El registro de depuración permite ver cargas por lotes a Azure Monitor separadas por tipo, número de elementos
de datos y tiempo de envío:
Ejemplo de registro con depuración habilitada:
Success sending oms.nagios x 1 in 0.14s

Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s
Salida detallada
En lugar de usar el complemento de salida de OMS, también puede generar la salida de elementos de datos
directamente a stdout , que es visible en el archivo de registro del agente de Log Analytics para Linux.
En el archivo de configuración del agente general de Log Analytics en
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf , convierta en comentario el complemento de
salida de OMS agregando # al principio de cada línea:
#<match oms.** docker.**>

# type out_oms
# log_level info
# num_threads 5
# buffer_chunk_limit 5m
# buffer_type file
# buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
# buffer_queue_limit 10
# flush_interval 20s
# retry_limit 10
# retry_wait 30s
#</match>
Debajo del complemento de salida, quite la marca de comentario de la siguiente sección quitando el # delante
de cada línea:
<match **>
type stdout
</match>
Problema: No es posible establecer la conexión a través del proxy a

Azure Monitor.
Causas probables
El proxy especificado durante la incorporación era incorrecto.
Los puntos de conexión de servicio de Azure Monitor y Azure Automation no están en la lista de permitidos
en el centro de datos.
Solución
1. Vuelva a incorporase a Azure Monitor con el agente de Log Analytics para Linux mediante el siguiente
comando con la opción -v habilitada. Así se permite la salida detallada del agente que se conecta a través
del proxy a Azure Monitor.
/opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v
2. Revise la sección Actualizar la configuración de proxy para comprobar que el agente se haya configurado
correctamente para comunicarse a través de un servidor proxy.
3. Asegúrese de que los puntos de conexión descritos en la lista de requisitos de firewall de red de Azure
Monitor se agregan correctamente a una lista de permitidos. Si usa Azure Automation, en el vínculo
también se incluyen los pasos de configuración de red necesarios.
Problema: Recibe un error 403 al intentar incorporarse

Causas probables
La fecha y la hora son incorrectas en el servidor Linux
El identificador y la clave de área de trabajo usados son incorrectos
Solución
1. Compruebe la hora en el servidor Linux con el comando date. Si la hora es +/-15 minutos de la hora actual, la
incorporación produce un error. Para corregir este problema, actualice la fecha o la zona horaria del servidor
Linux.
2. Compruebe que ha instalado la versión más reciente del agente de Log Analytics para Linux. La versión más
reciente notifica ahora si el desfase temporal está causando el error de incorporación.
3. Vuelva a realizar la incorporación con el identificador de área de trabajo y la clave de área de trabajo correctos
según las instrucciones de instalación de este artículo.
Problema: Ve los errores 404 y 500 en el archivo de registro justo

después de la incorporación
Se trata de un problema conocido que se produce con la primera carga de datos de Linux en un área de trabajo
de Log Analytics. Esto no afecta a los datos que se envían ni a la experiencia del servicio.
Problema: Se indica el proceso omiagent usa el 100 % de la CPU

Causas probables
Una regresión en el paquete nss-pem v1.0.3 5.el7 causó un problema de rendimiento grave, que hemos
observado con frecuencia en las distribuciones Redhat/Centos 7.x. Para más información sobre este problema,
consulte la siguiente documentación: Bug 1667121 Performance regression in libcurl (Error 1667121 Regresión
del rendimiento en libcurl).
Los errores relacionados con el rendimiento no se producen constantemente y son muy difíciles de reproducir. Si
experimenta este problema con omiagent, debe usar el script omiHighCPUDiagnostics.sh, que recopilará el
seguimiento de pila de omiagent cuando se supere un umbral determinado.
1. Descarga del script
wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-
Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh
2. Ejecute el diagnóstico durante 24 horas con un umbral de la CPU del 30 %

bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30
3. La pila de llamadas se volcará en el archivo omiagent_trace. Si observa muchas llamadas a las funciones
Curl y NSS, realice los pasos de resolución siguientes.
Resolución (paso a paso )
1. Actualice el paquete nss-pem a v1.0.3 5.el7_6.1.
sudo yum upgrade nss-pem
2. Si el paquete nss-pem no está disponible para la actualización (sucede principalmente en Centos), degrade
curl a la versión 7.29.0-46. Si por error ejecuta la "actualización de yum", curl se actualizará a la versión
7.29.0-51 y volverá a producirse el problema.
sudo yum downgrade curl libcurl
3. Reinicie OMI:
sudo scxadmin -restart
Problema: No aparece ningún dato en Azure Portal

Causas probables
Error de incorporación a Azure Monitor
La conexión a Azure Monitor está bloqueada
Se está haciendo la copia de seguridad de los datos del agente de Log Analytics para Linux
Solución
1. Para comprobar si la incorporación en Azure Monitor se realizó correctamente, asegúrese de que existe el
archivo siguiente: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf .
2. Repita la incorporación con las instrucciones de la línea de comandos omsadmin.sh
3. Si utiliza un proxy, consulte los pasos de resolución de proxy que proporcionó anteriormente.
4. En algunos casos, cuando el agente de Log Analytics para Linux no puede comunicarse con el servicio, los
datos del agente ocupan el tamaño de búfer total de 50 MB. Se debe reiniciar el agente ejecutando el
siguiente comando /opt/microsoft/omsagent/bin/service_control restart [<workspace id>] .
NOTE
Este problema se ha corregido en la versión 1.1.0-28 y posteriores del agente.
Problema: No ve los mensajes de Syslog reenviados

Causas probables
La configuración aplicada al servidor Linux no permite la recopilación de las utilidades enviadas ni de los
niveles de registro.
Syslog no se reenvía correctamente al servidor Linux.
El número de mensajes que se reenvía por segundo es demasiado grande para la configuración básica del
agente de Log Analytics para Linux
Solución
Compruebe que la configuración de Syslog en el área de trabajo de Log Analytics tenga todas las utilidades y
los niveles de registro correctos. Revise Configuración de Syslog en Azure Portal.
Compruebe que los demonios de mensajería de Syslog nativos ( rsyslog , syslog-ng ) puedan recibir los
mensajes reenviados.
Compruebe la configuración de firewall en el servidor de Syslog para asegurarse de que no se estén
bloqueando los mensajes.
Simule un mensaje de Syslog en Log Analytics con el comando logger .
logger -p local0.err "This is my test message"
Problema: Recibe el error de que la dirección Errno ya está en uso en

el archivo de registro de omsagent
Si ve
[error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use -
bind(2) for "127.0.0.1" port 25224>
en omsagent.log.
Causas probables
Este error indica que la extensión Diagnostics de Linux (LAD) está instalada en paralelo con la extensión de VM
Linux de Log Analytics, y usa el mismo puerto para la colección de datos de syslog que omsagent.
Solución
1. Como raíz, ejecute los comandos siguientes (tenga en cuenta que 25224 es un ejemplo y es posible que
en su entorno vea que LAD usa otro número de puerto):
/opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229
sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
A continuación, tiene que editar el archivo de configuración correcto, rsyslogd o syslog_ng , y cambiar la
configuración relacionada con LAD para escribir en el puerto 25229.
2. Si la VM ejecuta rsyslogd , el archivo que debe modificar es: /etc/rsyslog.d/95-omsagent.conf (si existe,
de lo contrario, /etc/rsyslog ). Si la VM ejecuta syslog_ng , el archivo que debe modificar es:
/etc/syslog-ng/syslog-ng.conf .
3. Reinicie omsagent sudo /opt/microsoft/omsagent/bin/service_control restart .

4. Reinicie el servicio syslog.
Problema: No puede desinstalar omsagent con la opción purge

Causas probables
La extensión Diagnostics de Linux está instalada
La extensión Diagnostics de Linux se instaló y desinstaló, pero todavía aparece un error que indica que mdsd
usa omsagent, por lo que no se puede quitar.
Solución
1. Desinstale la extensión Diagnostics de Linux (LAD).
2. Quite los archivos de la extensión Diagnostics de Linux de la máquina si están presentes en la siguiente
ubicación: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ y
/var/opt/microsoft/omsagent/LAD/ .
Problema: No ve ningún dato de Nagios

Causas probables
El usuario omsagent no tiene permisos para leer el archivo de registro de Nagios
No se quitó la marca de comentario de origen y filtro y de Nagios del archivo omsagent.conf
Solución
1. Para agregar el usuario omsagent para leer del archivo de Nagios, siga estas instrucciones.
2. En el archivo de configuración general del agente de Log Analytics para Linux en
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf , asegúrese de que se haya quitado la
marca de comentarios tanto del origen como del filtro de Nagios.
<source>
type tail
path /var/log/nagios/nagios.log
format none
tag oms.nagios
</source>
<filter oms.nagios>
type filter_nagios_log
</filter>
Problema: No ve ningún dato de Linux

Causas probables
Error de incorporación a Azure Monitor
La conexión a Azure Monitor está bloqueada
La máquina virtual se reinició
El paquete de OMI se actualizó manualmente a una versión más reciente en comparación con la que instaló el
paquete del agente de Log Analytics para Linux
Error class not found de los registros de recursos de DSC en el archivo de registro omsconfig.log
Se está haciendo la copia de seguridad de los datos del agente de Log Analytics
DSC registra Current configuration does not exist. Execute Start-DscConfiguration command with -Path
parameter to specify a configuration file and create a current configuration first. en el archivo de registro
omsconfig.log , pero no existe ningún mensaje de registro sobre las operaciones de
PerformRequiredConfigurationChecks .
Solución
1. Instale todas las dependencias como el paquete auditd.
2. Para comprobar si la incorporación a Azure Monitor se realizó correctamente, asegúrese de que existe el
archivo siguiente: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf . Si no existe, repita la
incorporación con las instrucciones de la línea de comandos de omsadmin.sh.
3. Si usa un proxy, compruebe los pasos anteriores para solucionar problemas con un proxy.
4. En algunos sistemas de distribución de Azure, el demonio de servidor OMI omid no se inicia después de
reiniciar la máquina virtual. Esto provocará que no se muestren los datos relacionados con la solución de
Audit, ChangeTracking ni UpdateManagement. La solución alternativa consiste en iniciar manualmente el
servidor omi ejecutando sudo /opt/omi/bin/service_control restart .
5. Después de que el paquete OMI se actualice manualmente a una versión más reciente, debe reiniciarse
manualmente para que el agente de Log Analytics siga funcionando. Este paso es necesario para algunas
distribuciones donde el servidor OMI no se inicia automáticamente tras su actualización. Ejecute
sudo /opt/omi/bin/service_control restart para reiniciar OMI.
6. Si ve el error class not found en el recurso DSC en omsconfig.log, ejecute

sudo /opt/omi/bin/service_control restart .
7. En algunos casos, cuando el agente de Log Analytics para Linux no puede comunicarse con Azure Monitor,
se crea una copia de seguridad de los datos del agente del tamaño de búfer total: 50 MB. Se debe reiniciar
el agente ejecutando el siguiente comando /opt/microsoft/omsagent/bin/service_control restart .
NOTE
Este problema se ha corregido en la versión 1.1.0-28 y posteriores del agente.
Si el archivo de registro omsconfig.log no indica que las operaciones PerformRequiredConfigurationChecks

se ejecutan periódicamente en el sistema, podría haber un problema con el servicio o con el trabajos cron.
Asegúrese de que exista el trabajo cron en /etc/cron.d/OMSConsistencyInvoker . De ser necesario, ejecute
los siguientes comandos para crear el trabajo cron:
mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee
/etc/cron.d/OMSConsistencyInvoker
Además, asegúrese de que el servicio cron se esté ejecutando. Puede usar service cron status con
Debian, Ubuntu, SUSE, o service crond status con RHEL, CentOS, Oracle Linux para comprobar el estado
de este servicio. Si el servicio no existe, puede instalar los archivos binarios e iniciar el servicio mediante lo
siguiente:
Ubuntu/Debian
# To Install the service binaries

sudo apt-get install -y cron
# To start the service
sudo service cron start
SUSE

sudo zypper in cron -y
sudo systemctl enable cron
sudo systemctl start cron
RHEL/CeonOS

sudo yum install -y crond
sudo service crond start
Oracle Linux

sudo yum install -y cronie
sudo service crond start
Problema: Al configurar la colección desde el portal para los

contadores de rendimiento de Syslog o Linux, la configuración no se
aplica
Causas probables
El agente de Log Analytics para Linux no ha seleccionado la configuración más reciente
No se aplicó la configuración cambiada en el portal
Solución
Información previa: omsconfig es el agente de configuración del agente de Log Analytics para Linux que cada
cinco minutos busca una nueva configuración del portal. Esta configuración se aplica luego en los archivos de
configuración del agente de Log Analytics para Linux ubicados en
/etc/opt/microsoft/omsagent/conf/omsagent.conf.
En algunos casos, es posible que el agente de configuración del agente de Log Analytics para Linux no pueda
comunicarse con el servicio de configuración del portal y, por tanto, no se aplique la configuración más
reciente.
1. Para comprobar que el agente omsconfig está instalado, ejecute dpkg --list omsconfig o
rpm -qi omsconfig . Si no está instalado, vuelva a instalar la versión más reciente del agente de Log
Analytics para Linux.
2. Para comprobar que el agente omsconfig puede comunicarse con Azure Monitor, ejecute el
siguiente comando
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' . Este
comando devuelve la configuración que el agente recupera del servicio, incluida la configuración de
Syslog, los contadores de rendimiento de Linux y los registros personalizados. Si se produce un
error en este comando, ejecute el siguiente comando
sudo su omsagent -c 'python
/opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'
. Este comando fuerza al agente omsconfig a comunicarse con Azure Monitor y a recuperar la
configuración más reciente.
Problema: No ve ningún dato de registro personalizado

Causas probables
Error de incorporación a Azure Monitor.
No se ha seleccionado la opción Aplicar la configuración que aparece a continuación a mis máquinas
con Linux .
omsconfig no ha recuperado la configuración del registro personalizado más reciente del servicio.
El usuario omsagent del agente de Log Analytics para Linux no puede acceder al registro personalizado
debido a permisos o a que no se encuentra. Puede que vea los errores siguientes:
[DATETIME] [warn]: file not found. Continuing without tailing it.
[DATETIME] [error]: file not accessible by omsagent.
Un problema conocido con la condición de carrera se ha corregido en el agente de Log Analytics para Linux
versión 1.1.0-217
Solución
1. Para comprobar si la incorporación a Azure Monitor se realizó correctamente, asegúrese de que existe el
archivo siguiente: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf . Si no existe:
2. Repita la incorporación con las instrucciones de la línea de comandos de omsadmin.sh.
3. En Configuración avanzada en Azure Portal, asegúrese de que la opción Aplicar la configuración
que aparece a continuación a mis máquinas con Linux esté habilitada.
4. Para comprobar que el agente omsconfig puede comunicarse con Azure Monitor, ejecute el siguiente
comando sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' . Este
comando devuelve la configuración que el agente recupera del servicio, incluida la configuración de
Syslog, los contadores de rendimiento de Linux y los registros personalizados. Si se produce un error en
este comando, ejecute el siguiente comando
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py' .
Este comando fuerza al agente omsconfig a comunicarse con Azure Monitor y a recuperar la configuración
más reciente.
Información previa: En lugar de que el agente de Log Analytics para Linux se ejecute como usuario con
privilegios, root , el agente se ejecuta como el usuario omsagent . En la mayoría de los casos, se deben conceder
permisos explícitos al usuario para que lea determinados archivos. Para conceder permiso al usuario omsagent ,
ejecute los siguientes comandos:
1. Agregue el usuario omsagent a un grupo específico sudo usermod -a -G <GROUPNAME> <USERNAME> .
2. Concédale acceso de lectura universal al archivo necesario sudo chmod -R ugo+rx <FILE DIRECTORY> .
Existe un problema conocido con la condición de carrera en el agente de Log Analytics para Linux antes de la
versión 1.1.0-217. Después de actualizar al agente más reciente, ejecute el siguiente comando para obtener la
versión más reciente del complemento de salida:
sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace
id>/conf/omsagent.conf
.
Problema: Intenta repetir la incorporación en una nueva área de

trabajo
Cuando intenta repetir la incorporación de un agente en una nueva área de trabajo, la configuración del agente
de Log Analytics debe limpiarse antes de repetir la incorporación. Para limpiar la configuración anterior del
agente, ejecute la agrupación de shell con --purge
sudo sh ./omsagent-*.universal.x64.sh --purge
Or
sudo sh ./onboard_agent.sh --purge
Puede continuar con la repetición de la incorporación después de usar la opción --purge
La extensión del agente de Log Analytics en Azure Portal está

marcada con un estado de error: error de aprovisionamiento.
Causas probables
Se quitó el agente de Log Analytics del sistema operativo
El servicio de agente de Log Analytics está inactivo, deshabilitado o no está configurado
Solución
Siga los pasos a continuación para corregir el problema.
1. Quite la extensión de Azure Portal.
2. Instale el agente siguiendo las instrucciones.
3. Reinicie el agente con el comando siguiente: sudo /opt/microsoft/omsagent/bin/service_control restart .
Espere unos minutos y el estado de aprovisionamiento cambia a Aprovisionamiento realizado
correctamente .
Problema: Actualización a petición del agente de Log Analytics

Causas probables
Los paquetes de agente de Log Analytics en el host no están desactualizados.
Solución
Siga los pasos a continuación para corregir el problema.
1. Busque la versión más reciente en esta página.
2. Descargue script de instalación (1.4.2-124 como versión de ejemplo):
wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-
124/omsagent-1.4.2-124.universal.x64.sh
3. Para actualizar los paquetes, ejecute sudo sh ./omsagent-*.universal.x64.sh --upgrade .

Información general sobre el escalado automático
en Microsoft Azure
En este artículo se explican el concepto del escalado automático de Microsoft Azure y las ventajas que aporta, y
se realiza una introducción para empezar a usarlo.
La escalabilidad automática de Azure Monitor solo se aplica a Virtual Machine Scale Sets, Cloud Services, App
Service - Web Apps, Servicios API Management y clústeres de Azure Data Explorer.
NOTE
Azure tiene dos métodos de escalado automático. Una versión anterior del escalado automático se aplica a Virtual
Machines (conjuntos de disponibilidad). Esta característica tiene una compatibilidad limitada, por lo que, para poder usar el
escalado automático de manera más rápida y fiable, recomendamos la migración a los conjuntos de escalado de máquinas
virtuales. En este artículo, se incluye un vínculo sobre cómo utilizar la tecnología antigua.
¿Qué es el escalado automático?

Gracias al escalado automático, puede ejecutar la cantidad correcta de recursos para administrar la carga de la
aplicación. Permite agregar recursos para controlar el aumento de la carga y ahorrar dinero mediante la
eliminación de recursos inactivos. Especifique un número mínimo y máximo de instancias para ejecutar y
agregue o quite máquinas virtuales automáticamente en función de un conjunto de reglas. Tener un mínimo
garantiza la ejecución de la aplicación aunque no exista carga. Tener un máximo limita el posible costo total por
hora. Se escala automáticamente entre estos dos extremos en función de las reglas que se creen.
Cuando se cumplen las condiciones de las reglas, se desencadenan una o varias acciones de escalado
automático. Puede agregar y quitar máquinas virtuales o realizar otras acciones. En el siguiente diagrama
conceptual se muestra este proceso.
La explicación siguiente se aplica a las partes del diagrama anterior.
Métricas de los recursos

Los recursos generan métricas, que procesan posteriormente las reglas. Las métricas proceden de métodos
diferentes. Los conjuntos de escalado de máquinas virtuales usan datos de telemetría de los agentes de
Diagnósticos de Azure, mientras que la telemetría de Web Apps y Cloud Services proviene directamente de la
infraestructura de Azure. Algunas de las estadísticas que se utilizan frecuentemente son el uso de CPU, el uso de
memoria, el número de subprocesos, la longitud de la cola y el uso del disco. Para ver una lista de los datos de
telemetría que se pueden utilizar, consulte Métricas comunes de escalado automático de Azure Insights.
También puede usar métricas personalizadas que las aplicaciones pueden generar. Si ha configurado las
aplicaciones para que envíen métricas a Application Insights, puede usarlas para tomar decisiones sobre si
necesita escalar o no.
Time
Las reglas basadas en programaciones emplean el huso horario UTC. Debe establecer la zona horaria
correctamente al configurar las reglas.
Reglas
El diagrama solo muestra una única regla de escalado automático, pero puede tener muchas. Puede crear reglas
complejas de superposición según su situación. Estos son algunos de los tipos de reglas:
Basadas en métricas : por ejemplo, realizar esta acción cuando el uso de CPU sea superior al 50 %.
Basadas en tiempo : por ejemplo, desencadenar un webhook todos los sábados a las 8:00 en una zona
horaria determinada.
Las reglas basadas en métricas miden la carga de la aplicación y agregan o quitan máquinas virtuales en función
de ella. Las reglas de programación permiten escalar al ver los modelos de tiempo de la carga, si quiere escalar
antes de un posible aumento de carga o si esta disminuye.
Acciones y escalado automático

Las reglas pueden desencadenar uno o varios tipos de acciones.
Escalar : escalar o reducir horizontalmente máquinas virtuales
Enviar correo electrónico : enviar correo electrónico a los administradores y coadministradores de la
suscripción, así como a otras direcciones de correo electrónico que especifique
Automate via webhooks (Automatizar mediante webhooks): llamar a webhooks, que pueden
desencadenar varias acciones dentro o fuera de Azure. Dentro de Azure, puede iniciar runbooks de Azure
Automation, Azure Function o Azure Logic Apps. La dirección URL de terceros de ejemplo fuera de Azure
incluye servicios como Slack y Twilio.
Configuración de escalado automático

El escalado automático utiliza la siguiente terminología y estructura.
El motor de escalado automático lee la configuración de escalado automático para determinar si se
debe escalar hacia arriba o hacia abajo. Contiene uno o más perfiles, información sobre el recurso de
destino y la configuración de las notificaciones.
Un perfil de escalado automático es una combinación de:
Una configuración de capacidad , que indica los valores mínimos, máximos y
predeterminados para el número de instancias.
Un conjunto de reglas , cada una de las cuales incluye un desencadenador (tiempo o
métrica) y una acción de escalado (escalado o reducción vertical).
Una periodicidad , que indica cuándo el escalado automático debe hacer entrar en vigor el
perfil.
Puede tener varios perfiles, lo cual le permitirá ocuparse de diferentes requisitos
coincidentes. Puede tener perfiles de escalado automático diferentes, por ejemplo, para
distintos momentos del día o días de la semana.
La configuración de las notificaciones define qué notificaciones deben aparecer cuando se
produce un evento de escalado automático en función de los criterios de los perfiles de
configuración de escalado automático que cumpla. Con el escalado automático se pueden notificar
a una o más direcciones de correo electrónico o realizar llamadas a uno o más webhooks.
La lista íntegra de campos y descripciones configurables se encuentra en la API de REST de escalado automático.
Para ver ejemplos de código, consulte los siguientes artículos:
Configuración avanzada de escalado automático con plantillas de Resource Manager para VM Scale Sets
API de REST de escalado automático
Escalado horizontal frente a escalado vertical

El escalado automático solo escala horizontalmente, que es un aumento o una reducción del número de
instancias de máquina virtual. El escalado horizontal resulta más flexible en un entorno en la nube, ya que puede
llegar a ejecutar miles de máquinas virtuales para administrar la carga.
En contraste, el escalado vertical es diferente. Mantiene el mismo número de máquinas virtuales, pero hace que
sean más o menos potentes. La potencia se mide en memoria, velocidad de CPU, espacio en disco, etc. El
escalado vertical tiene más limitaciones, ya que depende de la disponibilidad de hardware de mayor tamaño,
que supera el límite rápidamente y puede variar según la región. El escalado vertical también suele requerir que
se detenga y reinicie una máquina virtual.
Métodos de acceso
Puede configurar el escalado automático en los siguientes lugares:
Azure Portal
PowerShell
Interfaz de línea de comandos (CLI) multiplataforma
API de REST de Azure Monitor
Servicios compatibles con el escalado automático

SERVIC IO ESQ UEM A Y DO C UM EN TO S
Web Apps Escalado en Web Apps
Cloud Services Escalado automático de un servicio en la nube
Virtual Machines: Clásico Escalado de conjuntos de disponibilidad clásicos de máquina

virtual
Virtual Machines: Conjuntos de escalado de Windows Escalado de conjuntos de escalado de máquinas virtuales en
Windows
Virtual Machines: Conjuntos de escalado de Linux Escalado de conjuntos de escalado de máquinas virtuales en
Linux
Virtual Machines: Ejemplo de Windows Configuración avanzada de escalado automático con

plantillas de Resource Manager para VM Scale Sets
Servicio API Management Escalado automático de una instancia de Azure API

Management
Clústeres de Azure Data Explorer Administración del escalado de clústeres de Azure Data
Explorer para ajustarse a los cambios en la demanda
Azure App Service Escalado de una aplicación en Azure App Service
Logic Apps Incorporación de capacidad del Entorno del servicio de

integración (ISE)
Pasos siguientes
Para más información sobre el escalado automático, consulte los tutoriales de escalado automático anteriores o
los siguientes recursos:
Métricas comunes de escalado automático de Azure Monitor
Procedimientos recomendados de escalado automático en Azure Monitor
Uso de acciones de escalado automático para enviar notificaciones de alerta por correo electrónico y
Webhook en Azure Insights
Solución de problemas de escalado automático de conjuntos de escalado de máquinas virtuales
Introducción al escalado automático en Azure
Este artículo describe cómo configurar el escalado automático de recursos en Microsoft Azure Portal.
Service - Web Apps y los servicios de API Management.
Detección de la configuración de escalado automático en la suscripción

Puede detectar todos los recursos a los que se aplica el escalado automático en Azure Monitor. Siga los pasos
siguientes para obtener un tutorial paso a paso:
1. Abra Azure Portal.
2. Haga clic en el icono de Azure Monitor en el panel izquierdo.
3. Haga clic en Escalado automático para ver todos los recursos para los que se puede aplicar el escalado
automático, junto con su estado de escalado automático actual.
Puede utilizar el panel de filtro de la parte superior para limitar la lista a los recursos seleccionados de un grupo de
recursos específico, tipos de recursos concretos o un recurso determinado.
Para cada recurso, encontrará el recuento de instancias actual y el estado de escalado automático. El estado de
escalado automático puede ser:
No configurado : aún no se ha habilitado el escalado automático para este recurso.
Habilitado : se ha habilitado el escalado automático para este recurso.
Disabled : se ha deshabilitado el escalado automático para este recurso.
Creación de la primera configuración de escalado automático

Se va a ofrecer ahora un tutorial paso a paso sencillo sobre cómo crear la primera configuración de escalado
automático.
1. Abra la hoja Escalado automático en Azure Monitor y seleccione un recurso que desee escalar (en los
pasos siguientes se usa un plan de App Service asociado con una aplicación web. Puede crear su primera
aplicación web de ASP.NET en Azure en cinco minutos).
2. Tenga en cuenta que el número actual de instancias es 1. Haga clic en Enable autoscale (Habilitar escalado
automático).
3. Proporcione un nombre para la configuración de escalado y haga clic en Agregar una regla . Tenga en
cuenta que las opciones de la regla de escalado se abren como un panel Contexto en el lado derecho. De
forma predeterminada, establece la opción para escalar el recuento de instancias en 1 si el porcentaje de
CPU del recurso supera el 70 %. Deje los valores predeterminados y haga clic en Agregar .
4. Ahora ha creado su primera regla de escalado. Tenga en cuenta que UX ofrece procedimientos
recomendados e indica que "se recomienda tener al menos una regla de reducción horizontal". Para ello:
a. Haga clic en Agregar una regla .
b. Establezca Operador en Menos que .
c. Establezca Umbral en 20 .
d. Establezca Operación en Reducir recuento en .
Ahora debería tener una configuración de escalado que escale o reduzca horizontalmente en función del
uso de CPU.

Felicidades. Ya ha establecido correctamente la primera configuración del escalado para escalar automáticamente
la aplicación web en función del uso de CPU.
NOTE
Los mismos pasos son aplicables para empezar a trabajar con un rol de servicio en la nube o un conjunto de escalado de
Otras consideraciones
Escalación según una programación
Además de escalar en función de la CPU, puede establecer la escala de forma diferente para días específicos de la
semana.
1. Haga clic en Add a scale condition (Agregar una condición de escalado).
2. Establezca el modo y las reglas de escalado de la misma forma que la condición predeterminada.
3. Seleccione Repeat specific days (Repetir días específicos) para la programación.
4. Seleccione los días y la hora de inicio y fin en que debe aplicarse la condición de escalado.
Escalado distinto en fechas concretas

Además de escalar en función de la CPU, puede establecer la escala de forma diferente para fechas específicas.
1. Haga clic en Add a scale condition (Agregar una condición de escalado).
2. Establezca el modo y las reglas de escalado de la misma forma que la condición predeterminada.
3. Seleccione Specify star t/end dates (Especificar fechas de inicio y fin) para la programación.
4. Seleccione las fechas y la hora de inicio y fin en que debe aplicarse la condición de escalado.
Consulta del historial de escalado de un recurso
Cada vez que un recurso se escala o reduce verticalmente, se registra un evento en el registro de actividad. Puede
consultar el historial de escalado del recurso de las últimas 24 horas si cambia a la pestaña Historial de
ejecución .
Si desea consultar el historial de escalado completo (de hasta 90 días), seleccione Haga clic aquí para ver más
detalles . Se abre el registro de actividad, con el escalado automático previamente seleccionado para el recurso y
la categoría.
Consulta de la definición de escalado del recurso
El escalado automático es un recurso de Azure Resource Manager. Puede ver la definición de escala en JSON al
cambiar a la pestaña JSON .
Puede realizar cambios en JSON directamente, si es necesario. Estos cambios se reflejarán después de guardarlos.
Deshabilitar el escalado automático y escalar manualmente las instancias
Pueden darse ocasiones en que desee deshabilitar la configuración actual de escalado y escalar los recursos
manualmente.
Haga clic en el botón Deshabilitar escalado automático en la parte superior.
NOTE
Esta opción deshabilita su configuración. Sin embargo, puede volver a ella después de habilitar de nuevo el escalado
automático.
Ahora puede establecer el número de instancias a las que desea escalar manualmente.
Siempre se puede volver al escalado automático; para ello, haga clic en Enable autoscale (Habilitar escalado
automático) y luego haga clic en Save (Guardar).
Enrutamiento del tráfico a instancias en buen estado (App Service)

Al escalar horizontalmente a varias instancias, App Service puede realizar comprobaciones de estado en ellas para
enrutar el tráfico únicamente a las que estén en buen estado. Para ello, abra el portal de App Service y, luego,
seleccione Comprobación de estado en Super visión . Seleccione Habilitar y proporcione una ruta de acceso
válida a una dirección URL en la aplicación, por ejemplo, /health o /api/health . Haga clic en Save (Guardar).
Ruta de acceso de comprobación de estado
La ruta de acceso debe responder en dos minutos con un código de estado entre 200 y 299 (incluido). Si no lo
hace, o devuelve un código de estado que no está dentro del rango, la instancia se considera "incorrecta". La
comprobación de estado se integra con las características de autenticación y autorización de App Service; el
sistema alcanza el punto de conexión aunque estén habilitadas estas características de seguridad. Si usa un
sistema de autenticación propio, la ruta de comprobación de estado debe permitir el acceso anónimo. Si el sitio
tiene habilitado HTTPS , la comprobación de estado respeta HTTPS y envía la solicitud mediante ese protocolo.
La ruta de acceso de comprobación de estado debe comprobar los componentes críticos de la aplicación. Por
ejemplo, si la aplicación depende de una base de datos y de un sistema de mensajería, el punto de conexión de
comprobación de estado debe conectarse a esos componentes. Si la aplicación no se puede conectar a un
componente esencial, la ruta de acceso debe devolver un código de respuesta de nivel 500 para indicar que la
aplicación tiene un estado incorrecto.
Comportamiento
Cuando se proporciona la ruta de acceso de comprobación de estado, App Service hace ping a la ruta de acceso en
todas las instancias. Si después de cinco pings no se recibe un código de respuesta correcto, esa instancia se
considera "incorrecta". Las instancias incorrectas se excluyen de la rotación del equilibrador de carga. Además, al
escalar vertical u horizontalmente, App Service hace ping a la ruta de acceso de comprobación de estado para
asegurarse de que las nuevas instancias están listas para las solicitudes.
El resto de instancias en buen estado pueden experimentar un aumento de la carga. Para evitar saturarlas, se
excluyen no más de la mitad de las instancias. Por ejemplo, si un plan de App Service se escala horizontalmente a
cuatro instancias y tres de ellas están en mal estado, hasta dos se pueden excluir de la rotación del equilibrador de
carga. Las otras dos instancias (una en buen estado y otra en mal estado) siguen recibiendo solicitudes. En el peor
de los casos, si todas las instancias están en mal estado, no se excluye ninguna.
Si una instancia permanece en mal estado durante una hora, se reemplaza por una nueva. A lo sumo, se reemplaza
una instancia por hora, con un máximo de tres instancias al día por plan de App Service.
Supervisión
Después de proporcionar la ruta de acceso de comprobación de estado de la aplicación, puede supervisar el
estado del sitio mediante Azure Monitor. En la hoja Comprobación de estado del portal, haga clic en Métricas
en la barra de herramientas superior. Se abre una nueva hoja donde puede ver el estado de mantenimiento
histórico del sitio y crear una regla de alerta. Para obtener más información sobre la supervisión de sitios, vea la
guía sobre Azure Monitor.
Pasos siguientes
Creación de una alerta de registro de actividades para supervisar todas las operaciones del motor de escalado
automático en su suscripción
Creación de una alerta de registro de actividades para supervisar todas las operaciones erróneas de escalado
automático y reducción horizontal en su suscripción
Información acerca de la configuración de escalado
automático
La configuración de escalado automático le ayuda a asegurarse de que tiene la cantidad adecuada de recursos en
ejecución para administrar las fluctuaciones de carga de la aplicación. Puede configurar los valores de escalado
automático para que se desencadene en función de métricas que indican carga o rendimiento, o para que se
desencadene en una fecha y hora programadas. En este artículo se proporciona una visión detallada de la
estructura de una configuración de escalado automático. El artículo comienza con el esquema y las propiedades de
una configuración y luego le guía por los diferentes tipos de perfil que se pueden configurar. Por último, en el
artículo se describe cómo la característica de escalado automático de Azure evalúa qué perfil ejecutar en un
momento dado.
Esquema de la configuración de escalado automático

Para ilustrar este esquema, se utiliza la siguiente configuración de escalado automático. Es importante tener en
cuenta que esta configuración de escalado automático tiene:
Un perfil.
Dos reglas de métricas en este perfil, una para el escalado horizontal y otra para la reducción horizontal.
La regla de escalado horizontal se desencadena cuando la métrica de porcentaje de CPU promedio del
conjunto de escalado de máquinas virtuales es superior al 85 % durante los últimos 10 minutos.
La regla de reducción horizontal se desencadena cuando el promedio del conjunto de escalado de
máquinas virtuales es inferior al 60 % durante el último minuto.
NOTE
Una configuración puede tener varios perfiles. Para más información, consulte la sección de perfiles. Un perfil también puede
tener definidas varias reglas de escalado y reducción horizontal. Para ver cómo se evalúan, consulte la sección de evaluación.
{
"id": "/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/autoscalesettings/setting1",
"name": "setting1",
"type": "Microsoft.Insights/autoscaleSettings",
"location": "East US",
"properties": {
"enabled": true,
"targetResourceUri":
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/vmss1",
"profiles": [
{
"name": "mainProfile",
"capacity": {
"minimum": "1",
"maximum": "4",
"default": "1"
},
"rules": [
{
"metricTrigger": {
"metricName": "Percentage CPU",
"metricResourceUri":
"timeGrain": "PT1M",
"statistic": "Average",
"timeWindow": "PT10M",
"timeAggregation": "Average",
"threshold": 85
},
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"operator": "LessThan",
"threshold": 60
},
"scaleAction": {
"direction": "Decrease",
"value": "1",
"cooldown": "PT5M"
}
}
]
}
]
}
}
SEC C IÓ N N O M B RE DEL EL EM EN TO DESC RIP C IÓ N

Configuración id Identificador de recurso de la

configuración de escalado automático.
La configuración de escalado
automático es un recurso de Azure
Resource Manager.
Configuración name Nombre de la configuración de escalado

automático.
Configuración ubicación Ubicación de la configuración de

escalado automático. Esta ubicación
puede ser diferente de la ubicación de
los recursos que se van a escalar.
properties targetResourceUri Identificador de recurso del recurso que

se va a escalar. Solo puede tener una
configuración de escalado automático
por recurso.
properties profiles Una configuración de escalado

automático se compone de uno o varios
perfiles. Cada vez que se ejecuta el
motor de escalado automático, ejecuta
un perfil.
perfile name Nombre del perfil. Puede elegir

cualquier nombre que le ayude a
identificar el perfil.
perfile capacity.maximum La capacidad máxima permitida.

Garantiza que, al ejecutar este perfil, el
escalado automático no escalará el
recurso por encima de este número.
perfile Capacity.minimum La capacidad mínima permitida.

Garantiza que, al ejecutar este perfil, el
escalado automático no escalará el
recurso por debajo de este número.
perfile Capacity.default Si hay algún problema al leer la métrica

del recurso (en este caso, la CPU de
"vmss1") y la capacidad actual es inferior
a la predeterminada, el escalado
automático escalará horizontalmente al
valor predeterminado. De esta forma, se
garantiza la disponibilidad del recurso. Si
la capacidad actual ya es mayor que la
predeterminada, el escalado automático
no reduce horizontalmente.
perfile reglas El escalado automático permite escalar

automáticamente entre las capacidades
máxima y mínima mediante las reglas
del perfil. Puede tener varias reglas en
un perfil. Normalmente hay dos reglas:
una para determinar cuándo escalar
horizontalmente y la otra para
determinar cuándo reducir
horizontalmente.
rule metricTrigger Define la condición de métrica de la

regla.
metricTrigger metricName El nombre de la métrica.
metricTrigger metricResourceUri El identificador de recurso del recurso

que emite esta métrica. En la mayoría
de los casos, es el mismo que el recurso
que se va a escalar. En algunos casos,
puede ser diferente. Por ejemplo, puede
escalar un conjunto de escalado de
máquinas virtuales en función del
número de mensajes en una cola de
almacenamiento.
metricTrigger timeGrain La duración del muestreo de métricas.

Por ejemplo, TimeGrain = "PT1M"
significa que las métricas se deberían
agregar cada minuto mediante el
método de agregación especificado en
"statistic".
metricTrigger statistic El método de agregación del período

timeGrain. Por ejemplo, statistic =
"Average" y timeGrain = "PT1M"
significa que las métricas se deberían
agregar cada minuto tomando la media.
Esta propiedad determina cómo se
muestrea la métrica.
metricTrigger timeWindow La cantidad de tiempo necesario para

recuperar las métricas. Por ejemplo,
timeWindow = "PT10M" significa
que, cada vez que se ejecuta el escalado
automático, se consultan las métricas de
los últimos 10 minutos. La ventana de
tiempo permite que las métricas se
normalicen y evita que reaccionen a
picos transitorios.
metricTrigger timeAggregation Método de agregación que se usa para

agregar métricas muestreadas. Por
ejemplo, TimeAggregation =
"Average" agregará las métricas
muestreadas teniendo en cuenta la
media. En el caso anterior, toma las diez
muestras de 1 minuto y hace la media.
rule scaleAction La acción que se realizará cuando se

desencadene la propiedad metricTrigger
de la regla.
scaleAction direction "Aumentar" para escalar

horizontalmente o "Reducir" para
reducir horizontalmente.
scaleAction value El grado de aumento o reducción de la

capacidad del recurso.
scaleAction cooldown La cantidad de tiempo que debe

transcurrir después de realizar una
operación de escalado antes de poder
iniciar otra. Por ejemplo, si cooldown =
"PT10M" , el escalado automático no
intenta escalar de nuevo durante otros
10 minutos. Cooldown permite que las
métricas se estabilicen después de la
adición o eliminación de instancias.
Perfiles de escalado automático

Hay tres tipos de perfiles de escalado automático:
Perfil normal: el perfil más común. Si no es necesario escalar el recurso en función del día de la semana, o
de un día determinado, puede usar un perfil normal. Luego, este perfil se puede configurar con reglas de
métricas que determinen cuándo realizar un escalado horizontal y cuándo una reducción horizontal. Solo
debe definir un perfil normal.
El perfil de ejemplo que se usó anteriormente en este artículo es un ejemplo de perfil normal. También es
posible establecer un perfil para escalar a un número de instancias estáticas para el recurso.
Perfil de fecha fija: este perfil es para casos especiales. Por ejemplo, supongamos que tiene previsto un
evento importante el 26 de diciembre de 2018 (PST). Quiere que las capacidades mínima y máxima del
recurso sean diferentes ese día, pero seguir escalando sobre las mismas métricas. En este caso, debe agregar
un perfil de fecha fija a la lista de perfiles de la configuración. El perfil se configura solo para que se ejecute
en el día del evento. Para cualquier otro día, el escalado automático usa el perfil normal.
"profiles": [{
"name": " regularProfile",
"capacity": {
...
},
"rules": [{
...
},
{
...
}]
},
{
"name": "eventProfile",
"capacity": {
...
},
"rules": [{
...
}, {
...
}],
"fixedDate": {
"timeZone": "Pacific Standard Time",
"start": "2017-12-26T00:00:00",
"end": "2017-12-26T23:59:00"
}}
]
Perfil de periodicidad: este tipo de perfil le permite garantizar que este perfil se usará siempre un día
concreto de la semana. Los perfiles de periodicidad solo tienen una hora de inicio. Se ejecutan hasta que el
siguiente perfil de periodicidad o perfil de fecha fija está configurado para iniciarse. Una configuración de
escalado automático que solo incluya un perfil de periodicidad ejecuta ese perfil incluso aunque haya un
perfil normal definido en la misma configuración. En los dos ejemplos siguientes se muestra cómo se usa
este perfil:
Ejemplo 1: Días laborables frente a fines de semana
Supongamos que quiere que los fines de semana su capacidad máxima sea 4. Como en los días laborables la
carga esperada es mayor, quiere que su capacidad máxima sea 10. En este caso, la configuración contendría
dos perfiles de periodicidad, uno para ejecutarse durante los fines de semana y el otro los días laborables. La
configuración es parecida a esta:
"profiles": [
{
"name": "weekdayProfile",
"capacity": {
...
},
"rules": [{
...
}],
"recurrence": {
"frequency": "Week",
"schedule": {
"days": [
"Monday"
],
"hours": [
0
],
"minutes": [
0
]
}
}}
},
{
"name": "weekendProfile",
"capacity": {
...
},
"rules": [{
...
}]
"recurrence": {
"schedule": {
"days": [
"Saturday"
],
"hours": [
0
],
"minutes": [
0
]
}
}
}]
La configuración anterior muestra que cada perfil de periodicidad tiene una programación. Esta
programación determina cuándo comienza a ejecutarse el perfil. El perfil se detiene cuando llega la hora de
ejecutar otro perfil.
Por ejemplo, en la configuración anterior, "weekdayProfile" está configurado para iniciarse los lunes a las
12:00 a.m. Eso significa que este perfil comienza a ejecutarse los lunes a las 12:00 a.m. Y continúa hasta el
sábado a las 12:00 a.m., cuando está programado que comience a ejecutarse "weekendProfile".
Ejemplo 2: Horas laborables
Supongamos que tiene un umbral de métrica durante las horas laborables (de 9:00 a.m. a 5:00 p.m.) y otro
para todas las demás horas. La configuración sería parecida a esta:
"profiles": [
{
"name": "businessHoursProfile",
"capacity": {
...
},
"rules": [{
...
}],
"recurrence": {
"schedule": {
"days": [
"Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
],
"hours": [
9
],
"minutes": [
0
]
}
}
},
{
"name": "nonBusinessHoursProfile",
"capacity": {
...
},
"rules": [{
...
}]
"recurrence": {
"schedule": {
"days": [
"Monday", “Tuesday”, “Wednesday”, “Thursday”, “Friday”
],
"hours": [
17
],
"minutes": [
0
]
}
}
}]
La configuración anterior muestra que "businessHoursProfile" comienza a ejecutarse el lunes a las 9:00 a.m.
y continúa hasta las 5:00 p.m. En este momento, comienza a ejecutarse "nonBusinessHoursProfile".
"nonBusinessHoursProfile" se ejecuta hasta las 9:00 a.m. del martes y después "businessHoursProfile" toma
de nuevo el control. Este perfil se repite hasta el viernes a las 5:00 p.m. En ese momento,
"nonBusinessHoursProfile" se ejecuta todo el tiempo hasta el lunes a las 9:00 a.m.
NOTE
La interfaz de usuario de escalado automático de Azure Portal exige horas de finalización para los perfiles de periodicidad y
empieza a ejecutar el perfil predeterminado de la configuración de escalado automático entre los perfiles de periodicidad.
Evaluación del escalado automático

Dado que la configuración de escalado automático puede incluir varios perfiles, y que cada perfil puede incluir
varias reglas de métrica, es importante comprender cómo se evalúa una configuración de escalado automático.
Cada vez que se ejecuta el trabajo de escalado automático, se empieza por elegir el perfil que se aplica. A
continuación, el escalado automático evalúa los valores mínimo y máximo y las reglas de métrica del perfil, y
decide si es necesario realizar una acción de escalado.
¿Qué perfil seleccionará el escalado automático?
El escalado automático usa la siguiente secuencia para elegir el perfil:
1. En primer lugar, busca cualquier perfil de fecha fija que esté configurado para ejecutarse ahora. Si existe, el
escalado automático lo ejecuta. Si hay varios perfiles de fecha fija que se supone que se pueden ejecutar, el
escalado automático selecciona el primero de ellos.
2. Si no hay ningún perfil de fecha fija, el escalado automático busca perfiles de periodicidad. Si los encuentra, los
ejecuta.
3. Si no hay perfiles de fecha fija ni de periodicidad, el escalado automático ejecuta el perfil normal.
¿Cómo evalúa el escalado automático varias reglas?
Después de que el escalado automático determina qué perfil ejecutar, evalúa todas las reglas de escalado horizontal
del perfil (son reglas con la dirección = "Aumentar" ).
Si se desencadenan una o varias reglas de escalado horizontal, el escalado automático calcula la nueva capacidad
según la propiedad scaleAction de cada una de esas reglas. A continuación, realiza el escalado horizontal hasta
alcanzar el máximo de esas capacidades para garantizar la disponibilidad del servicio.
Por ejemplo, supongamos que hay un conjunto de escalado de máquinas virtuales con una capacidad actual de 10.
Hay dos reglas de escalado horizontal: una que aumenta la capacidad en un 10 por ciento y otra que la aumenta en
3 recuentos. La primera regla daría como resultado una nueva capacidad de 11 y la segunda regla generaría una
capacidad de 13. Para garantizar la disponibilidad del servicio, el escalado automático elige la acción que tenga
como resultado la capacidad máxima, por lo que, en este caso, se elige la segunda regla.
Si no se desencadena ninguna regla de escalado horizontal, el escalado automático evalúa todas las reglas de
reducción horizontal (reglas con la dirección = "Reducir" ). El escalado automático solo realizará una acción de
reducción horizontal si se desencadenan todas las reglas de reducción horizontal.
El escalado automático calcula la nueva capacidad en función de la propiedad scaleAction de cada una de esas
reglas. A continuación, elige la acción de escalado que da como resultado el valor máximo de esas capacidades para
garantizar la disponibilidad del servicio.
Por ejemplo, supongamos que hay un conjunto de escalado de máquinas virtuales con una capacidad actual de 10.
Hay dos reglas de reducción horizontal: una que reduce la capacidad en un 50 por ciento y otra que la reduce en 3
recuentos. La primera regla daría como resultado una nueva capacidad de 5 y la segunda regla generaría una
capacidad de 7. Para garantizar la disponibilidad del servicio, el escalado automático elige la acción que tenga como
resultado la capacidad máxima, por lo que, en este caso, se elige la segunda regla.
Pasos siguientes
Para más información sobre el escalado automático, consulte los siguientes recursos:
Introducción a los registros de escalado automático
Métricas comunes de escalado automático de Azure Monitor
Procedimientos recomendados de escalado automático en Azure Monitor
Uso de acciones de escalado automático para enviar notificaciones de alerta por correo electrónico y Webhook
en Azure Insights
Procedimientos recomendados de escalado
automático
Conceptos de escalado automático

Un recurso solo puede tener una configuración de escalado automático.
Una configuración de escalado automático puede tener uno o varios perfiles y cada perfil, a su vez, puede
tener una o varias reglas de escalado automático.
Una configuración de escalado automático escala instancias horizontalmente aumentando las instancias y las
reduce horizontalmente disminuyendo el número de instancias. Una configuración de escalado automático
presenta unos valores máximo, mínimo y predeterminado de instancias.
Un trabajo de escalado automático siempre lee la métrica asociada por la que realizar la escala y comprueba si
se rebasó el umbral establecido para el escalado horizontal o la reducción horizontal. En Métricas comunes de
escalado automático de Azure Monitor encontrará una lista de métricas por las que el escalado automático
puede escalar.
Todos los umbrales se calculan en el nivel de instancia. Por ejemplo, "escalar horizontalmente por una instancia
cuando el uso medio de la CPU es superior al 80 % cuando el número de instancias es 2" significa escalar
horizontalmente cuando el uso medio de la CPU en todas las instancias sea superior al 80 %.
Todos los errores de escalado automático se registran en el registro de actividad. Después, puede configurar
una alerta de registro de actividad de forma que pueda recibir una notificación por correo electrónico, SMS o
webhook siempre que haya un error de escalabilidad automática.
De forma similar, todas las acciones de escalado correctas se publican en el registro de actividad. Después,
puede configurar una alerta de registro de actividad de forma que pueda recibir una notificación por correo
electrónico, SMS o webhook siempre que haya una acción de escalabilidad automática correcta. Puede
configurar notificaciones de correo electrónico o webhook para recibir una notificación cada vez que se lleve a
cabo una acción de escalado correcta a través de la pestaña de notificaciones de la configuración de escalado
automático.
Procedimientos recomendados de escalado automático

Use los procedimientos recomendados al usar el escalado automático.
Asegúrese de que los valores máximo y mínimo son diferentes y de que hay margen suficiente entre ellos
Si tiene una configuración en la que el valor mínimo es 2, el valor máximo es 2 y el número de instancias es 2, no
se puede ejecutar ninguna acción de escalado. Mantenga un margen suficiente entre los números de instancias
máximo y mínimo, que son inclusivos. El escalado automático siempre escala entre estos límites.
El escalado manual se restablece al valor máximo y mínimo de escalado automático.
Si actualiza manualmente el recuento de instancias a un valor superior o inferior al máximo, el motor de escalado
automático se ajusta automáticamente al valor mínimo (si está por debajo) o al máximo (si está por encima). Por
ejemplo, establezca el intervalo entre 3 y 6. Si tiene una instancia en ejecución, el motor de escalabilidad
automática escala a tres instancias cuando vuelve a ejecutarse. Del mismo modo, si establece manualmente la
escalabilidad en ocho instancias, en la siguiente ejecución de escalabilidad automática se escalará de vuelta a seis
instancias. La escalabilidad manual es temporal a menos que restablezca también las reglas de escalabilidad
automática.
Use siempre una combinación de reglas de escalado horizontal y reducción horizontal que realice un aumento y
una disminución.
Si usa un único elemento de la combinación, la escalabilidad automática solo ocurrirá en una dirección
(escalabilidad o reducción horizontal) hasta que alcance el conteo máximo o mínimo de instancias que se ha
definido en el perfil. Esta no es la mejor opción; idealmente, querrá que el recurso escale verticalmente en los
momentos de uso elevado para garantizar la disponibilidad. De forma similar, en los momentos de poco uso
querrá que el recurso se reduzca verticalmente para ahorrar costos.
Elija la estadística adecuada para la métrica de diagnósticos
Para las métricas de diagnóstico, puede elegir entre Promedio, Mínimo, Máximo y Total como métrica a partir de
la que escalar. La estadística más común es Promedio.
Elija los umbrales cuidadosamente para todos los tipos de métrica
Es recomendable tener cuidado a la hora de elegir los diferentes umbrales de escalado y reducción horizontal en
función de las situaciones prácticas.
No se recomiendan opciones de escalado automático como las de los siguientes ejemplos, con valores de umbral
iguales o similares en condiciones de escalado o reducción horizontal:
Aumentar las instancias en 1 cuando el número de subprocesos >= 600
Disminuir las instancias en 1 cuando el número de subprocesos <= 600
Veamos un ejemplo de lo que puede llevar a producir un comportamiento confuso. Considere la siguiente
secuencia.
1. Imaginemos que hay dos instancias inicialmente y después aumenta el número promedio de subprocesos por
instancia a 625.
2. La escalabilidad automática escala horizontalmente para agregar una tercera instancia.
3. Imaginemos ahora que el número promedio de subprocesos en la instancia se reduce a 575.
4. Antes de reducir verticalmente, el escalado automático intenta evaluar cuál será el estado final si reduce
horizontalmente. Por ejemplo, 575 x 3 (número de instancias actual) = 1725/2 (número final de instancias al
reducir verticalmente) = 862,5 subprocesos. Esto significa que el escalado automático tiene que volver a
escalar horizontalmente de inmediato (incluso después de haber reducido horizontalmente) si el número
promedio de subprocesos sigue siendo el mismo o incluso si se reduce solo una pequeña cantidad. Sin
embargo, si se volviera a escalar verticalmente, todo el proceso se repetiría, dando lugar a un bucle infinito.
5. Para evitar esta situación (conocida como "inestable"), el escalado automático nunca reduce verticalmente. En
su lugar, pasa esto por alto y vuelve a evaluar la situación la siguiente vez que el trabajo del servicio se ejecuta.
El estado oscilante puede ser confuso para muchos usuarios, ya que puede dar la impresión de que la
escalabilidad automática no funciona cuando el número promedio de subprocesos es 575.
La estimación durante una reducción horizontal está diseñada para evitar situaciones "oscilantes", donde las
acciones de reducción horizontal y escalado horizontal avanzan y retroceden continuamente. Recuerde este
comportamiento cuando elija los mismos umbrales de escalado horizontal y reducción horizontal.
Nuestra recomendación es establecer un margen suficiente entre el escalado horizontal y en los umbrales. Por
ejemplo, echemos un vistazo a esta siguiente combinación de reglas, que es mejor.
Aumentar las instancias en 1 cuando el porcentaje de CPU > = 80
Disminuir las instancias en 1 cuando el porcentaje de CPU > = 60
En este caso
1. Imaginemos que hay 2 instancias para empezar.
2. Si el promedio de porcentaje de CPU entre instancias llega a 80, el escalado automático escala
horizontalmente agregando una tercera instancia.
3. Imaginemos ahora que, con el tiempo, el porcentaje de CPU cae a 60.
4. La regla de reducción horizontal del escalado automático calcula el estado final como si fuese a reducirse
horizontalmente. Por ejemplo, 60 x 3 (número de instancias actual) = 180/2 (número final de instancias al
reducir verticalmente) = 90. Por tanto, el escalado automático no reduce horizontalmente porque tendría que
volver a escalar horizontalmente de inmediato. En su lugar, omite la reducción vertical.
5. La próxima vez que comprueba el escalado automático, la CPU ha seguido cayendo a 50. Vuelve a calcular: 50
x 3 instancias = 150/2 instancias = 75, lo que está por debajo del umbral de escalado horizontal de 80. Por
tanto, reduce horizontalmente a 2 instancias.
Consideraciones para establecer valores de umbral de escalado en métricas especiales
En el caso de las métricas especiales, como la métrica longitud de cola de Service Bus o de Storage, el umbral es el
promedio de mensajes disponibles por número actual de instancias. Elija cuidadosamente el valor de umbral para
esta métrica.
Veamos esto con un ejemplo para procurar que entienda el comportamiento de mejor forma.
Aumentar las instancias en 1 cuando el número de mensajes de la cola de almacenamiento > = 50
Disminuir las instancias en 1 cuando el número de mensajes de la cola de almacenamiento < = 10
Considere la siguiente secuencia:
1. Hay dos instancias de la cola de almacenamiento.
2. Siguen llegando mensajes y, al revisar la cola de almacenamiento, el recuento total es 50. Se supone que el
escalado automático tendría que iniciar una acción de escalado horizontal. Sin embargo, vemos que sigue
siendo de 50/2 = 25 mensajes por instancia. Por lo tanto, el escalado horizontal no se ha producido. Para que
el primer escalado horizontal se produzca, el número total de mensajes en la cola de almacenamiento debe ser
100.
3. Tras esto, imaginemos que el número total de mensajes llega a 100.
4. Se agrega una tercera instancia de la cola de almacenamiento debido a una acción de escalado horizontal. La
siguiente acción de escalado horizontal no tendrá lugar hasta que el número total de mensajes en la cola
llegue a 150 porque 150/3 = 50.
5. Ahora, disminuye el número de mensajes en la cola. Con tres instancias, la primera acción de reducción
horizontal ocurre cuando el número total de mensajes en la cola llega a 30, porque 30/3 equivale a 10
mensajes por instancia, que es el umbral de reducción horizontal.
Consideraciones de escalado cuando hay varios perfiles configurados en una configuración de escalado
automático
En una configuración de escalado automático, puede elegir un perfil predeterminado, que se aplica siempre
(independientemente de programaciones o períodos de tiempo), o bien optar por perfil periódico o por un perfil
para un período fijo con una fecha y un intervalo de tiempo.
Cuando el servicio de escalado automático procesa estos perfiles, siempre los comprueba en el siguiente orden:
1. Perfil de fecha fija
2. Perfil periódico
3. Perfil predeterminado ("Siempre")
Si se cumple una condición de perfil, el escalado automático no comprobará la siguiente condición de perfil por
debajo de este. El escalado automático solo procesa un perfil cada vez. Esto significa que, si queremos incluir una
condición de procesamiento de un perfil de nivel inferior, tendremos que incluir también las reglas del perfil
actual.
Vamos a analizarlo con un ejemplo:
La siguiente imagen muestra una configuración de escalado automático con un perfil predeterminado con un
número de instancias mínimo = 2 y un número de instancias máximo = 10. En este ejemplo, las reglas están
configuradas para escalar horizontalmente cuando el número de mensajes en la cola sea mayor que 10 y,
asimismo, reducir horizontalmente cuando el número de mensajes en la cola sea inferior a tres. Ahora el recurso
puede escalar entre dos y diez instancias.
Además, hay un perfil periódico establecido para el lunes. Está configurado para un número de instancias mínimo
de tres y un número de instancias máximo de diez. Esto significa que, la primera vez que la escalabilidad
automática compruebe esta condición el lunes, si el recuento de instancias es dos, lo escala al nuevo mínimo de
tres. Mientras el escalado automático siga encontrando una coincidencia con esta condición de perfil (lunes), solo
procesa las reglas de escalado/reducción horizontal basadas en CPU configuradas en este perfil. En este
momento, no comprueba la longitud de la cola. Sin embargo, si queremos que compruebe la condición de
longitud de cola, tendremos que incluir esas reglas del perfil predeterminado también en el perfil del lunes.
De forma similar, cuando el escalado automático regresa al perfil predeterminado, primero comprueba si se
cumplen las condiciones mínima y máxima. Si el número de instancias en ese momento es 12, reducirá
horizontalmente a 10, que es el máximo permitido en el perfil predeterminado.
Consideraciones de escalado cuando hay varias reglas configuradas en un perfil
Hay casos en los que puede que sea necesario establecer varias reglas en un perfil. El motor de escalabilidad
automática usa el siguiente conjunto de reglas de escalado automático cuando se establecen varias reglas.
Al escalar horizontalmente, el escalado automático se ejecuta si se cumple cualquier regla. Al reducir
horizontalmente, el escalado automático necesita que todas las reglas se cumplan.
Para ilustrar esto, imaginemos que tiene las siguientes cuatro reglas de escalabilidad automática:
Con una CPU < 30 %, se reduce horizontalmente en 1
Con una memoria < 50 %, se reduce horizontalmente en 1
Con una CPU> 75 %, se escala horizontalmente en 1
Con una memoria > 75 %, se escala horizontalmente en 1
Por tanto, sucederá lo siguiente:
Con una CPU del 76 % y una memoria del 50 %, se escala horizontalmente.
Con una CPU del 50 % y una memoria del 76 %, se escala horizontalmente.
Por otro lado, con una CPU del 25 % y una memoria del 51 %, el escalado automático no reduce horizontalmente.
Para ello, la CPU debe ser 29 % y la memoria, 49 %.
Seleccione siempre un número predeterminado de instancias seguro
El número predeterminado de instancias es importante, porque el escalado automático escala el servicio a dicho
número cuando no hay métricas disponibles. Por tanto, seleccione un número predeterminado de instancias que
sea seguro para sus cargas de trabajo.
Configure notificaciones de escalado automático
El escalado automático se publicará en el registro de actividad si se produce alguna de las condiciones siguientes:
El escalado automático genera una operación de escala.
El servicio de escalado automático completa correctamente una acción de escalado.
El servicio de escalado automático no puede realizar una acción de escalado.
No hay métricas disponibles para que el servicio de escalado automático tome una decisión de escalado.
Vuelve a haber métricas disponibles (recuperación) para poder tomar una decisión de escalado.
También puede usar una alerta de registro de actividades para supervisar el mantenimiento del motor de
escalado automático. Aquí puede ver ejemplos para crear una alerta de registro de actividades para supervisar
todas las operaciones del motor de escalado automático en su suscripción o para crear una alerta de registro de
actividades para supervisar todas las operaciones con errores de escalado automático y reducción horizontal en
su suscripción.
Además de utilizar alertas de registro de actividad, puede configurar notificaciones de correo electrónico o
webhook para recibir una notificación cada vez que se lleve a cabo una acción de escalado correcta a través de la
pestaña de notificaciones de la configuración de escalado automático.
Pasos siguientes
Cree una alerta de registro de actividades para supervisar todas las operaciones del motor de escalado
automático en su suscripción.
Cree una alerta de registro de actividades para supervisar todas las operaciones con errores de escalado
automático y reducción horizontal en su suscripción.
Métricas comunes de escalado automático de Azure
Monitor
NOTE
El escalado automático de Azure Monitor le permite escalar verticalmente y reducir horizontalmente el número
de instancias en ejecución, basándose en los datos de telemetría (métricas). Este documento describe las métricas
comunes que estaría interesado en usar. En Azure Portal, puede elegir la métrica de recurso por la que se va a
escalar. Sin embargo, también puede elegir cualquier métrica de un recurso diferente por la que escalar.
Service - Web Apps y los servicios de API Management. Otros servicios de Azure usan distintos métodos de
escalado.
Cálculo de métricas de máquinas virtuales basadas en Resource

Manager
De forma predeterminada, las máquinas virtuales basadas en Resource Manager y los conjuntos de escalado de
máquinas virtuales emiten métricas básicas (de nivel de host). Además, al configurar la recopilación de datos de
diagnóstico para máquinas virtuales y conjuntos de escalado de máquinas virtuales de Azure, la extensión de
diagnóstico de Azure también emite contadores de rendimiento de SO invitado (lo que normalmente se conoce
como "métricas de SO invitado"). Todas estas métricas se usan en reglas de escalado automático.
Puede usar la CLI, API o PoSH Get MetricDefinitions para ver las métricas disponibles para el recurso VMSS.
Si está utilizando conjuntos de escalado de máquinas virtuales y no ve una métrica concreta enumerada,
entonces es probable que esté deshabilitada en la extensión Diagnostics.
Si una métrica concreta no se muestrea o se transfiere a la frecuencia que desea, puede actualizar la
configuración de diagnóstico.
Si se cumple cualquiera de los casos anteriores, revise Uso de PowerShell para habilitar Diagnósticos de Azure en
una máquina virtual con Windows sobre PowerShell para configurar y actualizar la extensión Diagnostics de
máquina virtual de Azure a fin de habilitar la métrica. Ese artículo también incluye un archivo de configuración de
diagnósticos de ejemplo.
Métricas de host para máquinas virtuales Windows y Linux basadas en Resource Manager
Las siguientes métricas de nivel de host se emiten de forma predeterminada para máquinas virtuales y conjuntos
de escalado de máquinas virtuales de Azure en instancias de Windows y Linux. Estas métricas describen la
máquina virtual de Azure, pero se recopilan desde el host de dicha máquina en lugar de hacerlo a través de
agente instalado en la máquina virtual invitada. Puede usar estas métricas en reglas de escalado automático.
Métricas de host para máquinas virtuales Windows y Linux basadas en Resource Manager
Métricas de host para conjuntos de escalado de máquinas virtuales Windows y Linux basadas en Resource
Manager
Métricas de SO invitado para máquinas virtuales Windows basadas en Resource Manager
Cuando crea una nueva máquina virtual en Azure, los diagnósticos se habilitan mediante la extensión
Diagnósticos. La extensión de diagnósticos emite un conjunto de métricas realizadas desde dentro de la máquina
virtual. Esto significa que puede escalar automáticamente fuera de las métricas que no se emiten de forma
predeterminada.
Puede generar una lista de las métricas mediante el siguiente comando en PowerShell.
Puede crear una alerta para las siguientes métricas:
N O M B RE DE L A M ÉT RIC A UN IDA D
Procesador(_Total)% Hora del procesador Percent
\Procesador(_Total)% de tiempo con privilegios Percent
\Procesador(_Total)% de tiempo de usuario Percent
\Información del procesador(_Total)\Frecuencia del Count

procesador
\Sistema\Procesos Count
\Proceso(_Total)\Número de subprocesos Count
\Proceso(_Total)\Número de identificadores Count
\Memoria% de bytes confirmados en uso Percent
\Memoria\Bytes disponibles Bytes
\Memoria\Bytes confirmados Bytes
\Memoria\Límite de confirmación Bytes
\Memoria\Bytes de bloque paginado Bytes
\Memoria\Bytes de bloque no paginado Bytes
\Disco físico(_Total)% de tiempo de disco Percent
\Disco físico(_Total)%Tiempo de lectura de disco Percent
\Disco físico(_Total)% de tiempo de escritura de disco Percent
\Disco físico(_Total)\Transferencias de disco/s CountPerSecond
\Disco físico(_Total)\Lecturas de disco/s CountPerSecond

\Disco físico(_Total)\Escrituras de disco/s CountPerSecond
\Disco físico(_Total)\Bytes de disco/s BytesPerSecond
\Disco físico(_Total)\Bytes de lectura de disco/s BytesPerSecond
\Disco físico(_Total)\Bytes de escritura de disco/s BytesPerSecond
\Disco físico(_Total)\Promedio Longitud de la cola de disco Count
\Disco físico(_Total)\Promedio Longitud de la cola de lectura Count

de disco
\Disco físico(_Total)\Promedio Longitud de la cola de escritura Count

de disco
\Disco lógico(_Total)% de espacio disponible Percent
\Disco lógico(_Total)\Megabytes disponibles Count
Métricas de SO invitado para máquinas virtuales Linux

Cuando crea una máquina virtual en Azure, los diagnósticos se habilitan de forma predeterminada mediante la
extensión Diagnósticos.
Puede generar una lista de las métricas mediante el siguiente comando en PowerShell.
Puede crear una alerta para las siguientes métricas:
\Memory\AvailableMemory Bytes
\Memory\PercentAvailableMemory Percent
\Memory\UsedMemory Bytes
\Memory\PercentUsedMemory Percent
\Memory\PercentUsedByCache Percent
\Memory\PagesPerSec CountPerSecond
\Memory\PagesReadPerSec CountPerSecond
\Memory\PagesWrittenPerSec CountPerSecond
\Memory\AvailableSwap Bytes
\Memory\PercentAvailableSwap Percent
\Memory\UsedSwap Bytes
\Memory\PercentUsedSwap Percent
\Processor\PercentIdleTime Percent
\Processor\PercentUserTime Percent
\Processor\PercentNiceTime Percent
\Processor\PercentPrivilegedTime Percent
\Processor\PercentInterruptTime Percent
\Processor\PercentDPCTime Percent
\Processor\PercentProcessorTime Percent
\Processor\PercentIOWaitTime Percent
\PhysicalDisk\BytesPerSecond BytesPerSecond
\PhysicalDisk\ReadBytesPerSecond BytesPerSecond
\PhysicalDisk\WriteBytesPerSecond BytesPerSecond
\PhysicalDisk\TransfersPerSecond CountPerSecond
\PhysicalDisk\ReadsPerSecond CountPerSecond
\PhysicalDisk\WritesPerSecond CountPerSecond
\PhysicalDisk\AverageReadTime Segundos
\PhysicalDisk\AverageWriteTime Segundos
\PhysicalDisk\AverageTransferTime Segundos
\PhysicalDisk\AverageDiskQueueLength Count
\NetworkInterface\BytesTransmitted Bytes
\NetworkInterface\BytesReceived Bytes
\NetworkInterface\PacketsTransmitted Count
\NetworkInterface\PacketsReceived Count
\NetworkInterface\BytesTotal Bytes
\NetworkInterface\TotalRxErrors Count
\NetworkInterface\TotalTxErrors Count
\NetworkInterface\TotalCollisions Count
Métricas de App Service comúnmente usadas (granja de servidores)

También puede realizar el escalado automático basándose en métricas de servidor web comunes, como la
longitud de cola Http. El nombre de la métrica es HttpQueueLength . En la siguiente sección se muestran las
métricas de granja de servidores disponibles (App Service).
Métricas de Web Apps
Puede generar una lista de las métricas de Web Apps mediante el siguiente comando en PowerShell.
Puede alertar sobre estas métricas o escalar por las mismas.
CpuPercentage Percent
MemoryPercentage Percent
DiskQueueLength Count
HttpQueueLength Count
BytesReceived Bytes
BytesSent Bytes
Métricas de almacenamiento utilizadas comúnmente

Puede escalar por la longitud de la cola de almacenamiento, que es el número de mensajes de dicha cola. La
longitud de cola de almacenamiento es una métrica especial y el umbral es el número de mensajes por instancia.
Por ejemplo, si hay dos instancias y el umbral está establecido en 100, el escalado se produce cuando el número
total de mensajes de la cola es 200. Esto puede ser 100 mensajes por instancia, 120 y 80, o cualquier
combinación que sume hasta 200 o más.
Esta configuración la puede realizar en Azure Portal, en la hoja Configuración . Para los conjuntos de escalado de
máquinas virtuales, puede actualizar la configuración de escalado automático en la plantilla de Resource
Manager para usar metricName como ApproximateMessageCount y pasar el identificador de la cola de
almacenamiento como metricResourceUri.
Por ejemplo, con una cuenta de almacenamiento clásico el parámetro de escalado automático metricTrigger
incluiría lo siguiente:
"metricName": "ApproximateMessageCount",
"metricNamespace": "",
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.ClassicStorage/storageAccou
nts/STORAGE_ACCOUNT_NAME/services/queue/queues/QUEUE_NAME"
En el caso de una cuenta de almacenamiento (no clásica) el metricTrigger incluiría lo siguiente:
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.Storage/storageAccounts/STO
RAGE_ACCOUNT_NAME/services/queue/queues/QUEUE_NAME"
Métricas más usadas de Service Bus

Puede escalar por la longitud de la cola de Service Bus, que es el número de mensajes de dicha cola. La longitud
de cola de Service Bus es una métrica especial y el umbral es el número de mensajes por instancia. Por ejemplo,
si hay dos instancias y el umbral está establecido en 100, el escalado se produce cuando el número total de
mensajes de la cola es 200. Esto puede ser 100 mensajes por instancia, 120 y 80, o cualquier combinación que
sume hasta 200 o más.
Para los conjuntos de escalado de máquinas virtuales, puede actualizar la configuración de escalado automático
en la plantilla de Resource Manager para usar metricName como ApproximateMessageCount y pasar el
identificador de la cola de almacenamiento como metricResourceUri.
"/subscriptions/SUBSCRIPTION_ID/resourceGroups/RES_GROUP_NAME/providers/Microsoft.ServiceBus/namespaces/SB_NA
MESPACE/queues/QUEUE_NAME"
NOTE
Para Service Bus, el concepto de grupo de recursos no existe pero Azure Resource Manager crea un grupo de recursos
predeterminado por región. El grupo de recursos suele tener el formato 'Default-ServiceBus-[región]'. Por ejemplo, 'Default-
ServiceBus-EastUS', 'Default-ServiceBus-WestUS', 'Default-ServiceBus-AustraliaEast', etc.
Información general sobre los patrones comunes de
escalado automático
En este artículo se describen algunos de los patrones comunes para escalar recursos en Azure.
Introducción
En este artículo se asume que está familiarizado con el escalado automático. Puede comenzar aquí a escalar los
recursos. A continuación, se indican algunos de los patrones comunes de escalado.
Escala en función de la CPU

Tiene una aplicación web (rol de VMSS o de servicio en la nube) y:
Desea escalar o reducir horizontalmente en función de la CPU.
Además, desea asegurarse de que hay un número mínimo de instancias.
También quiere asegurarse de que establece un límite máximo del número de instancias al que puede escalar.
Escalado distinto entre los días de la semana y los fines de semana

Desea 3 instancias de forma predeterminada (en días de la semana).
No espera que haya tráfico durante los fines de semana y, por tanto, desea reducir verticalmente a 1 instancia
para los fines de semana.
Escalado distinto durante festividades
Desea escalar o reducir verticalmente en función del uso de CPU de forma predeterminada.
Sin embargo, durante Navidad u otros días específicos importantes para su negocio, desea reemplazar los
valores predeterminados y disponer de más capacidad.
Escalado en función de métricas personalizadas

Tiene un front-end web y un nivel de API que se comunica con el back-end.
Quiere escalar el nivel de API en función de los eventos personalizados en el front-end (ejemplo: Quiere escalar
el proceso de finalización de la compra en función del número de artículos en el carro de la compra).
Introducción al escalado automático mediante
métricas personalizadas en Azure
En este artículo se describe cómo escalar el recurso mediante una métrica personalizada en Azure Portal.
Service - Web Apps, clústeres de Azure Data Explorer,
Entorno del servicio de integración y los servicios de API Management.
Introducción
En este artículo se presupone que tiene una aplicación web con Application Insights configurado. Si aún no la tiene,
puede configurar Application Insights para el sitio web ASP.NET.
Abra Azure Portal
Haga clic en el icono de Azure Monitor en el panel de navegación izquierdo.
Haga clic en la opción Escalado automático para ver todos los recursos a los que se aplica el escalado
automático, junto con su estado de escalado automático actual
Abra la hoja "Escalado automático" en Azure Monitor y seleccione un recurso que desee escalar.
Nota: En los pasos siguientes se usa un plan de App Service asociado con una aplicación web con
Application Insights configurado.
En la hoja de configuración de escalado del recurso, tenga en cuenta que el recuento de la instancia actual es 1.
Haga clic en "Enable autoscale" (Habilitar escalado automático).
Proporcione un nombre para la configuración de escalado y haga clic en "Agregar una regla". Tenga en cuenta
que las opciones de la regla de escalado se abren como un panel Contexto en el lado derecho. De forma
predeterminada, establece la opción para escalar el recuento de instancias en 1 si el porcentaje de CPU del
recurso supera el 70 %. Cambie el origen de métricas en la parte superior a "Application Insights", seleccione el
recurso de Application Insights en el menú desplegable "Recurso" y luego seleccione la métrica personalizada en
la que quiere basar el escalado.
De forma similar al paso anterior, agregue una regla de escalado que reduzca horizontalmente y disminuya el
recuento de escala en 1 si la métrica personalizada está por debajo del umbral.
Establezca los límites de la instancia. Por ejemplo, si desea escalar entre 2-5 instancias en función de las
fluctuaciones de la métrica personalizada, establezca el "mínimo" en "2", el "máximo" en "5" y el "valor
predeterminado" en "2".
Nota: En caso de que haya algún problema al leer las métricas de recursos y la capacidad actual sea
inferior a la predeterminada, el escalado automático escalará horizontalmente al valor predeterminado a
fin de garantizar la disponibilidad del recurso. Si la capacidad actual ya es mayor que la predeterminada,
el escalado automático no reducirá horizontalmente.
Haga clic en "Guardar".

¡Enhorabuena! Ya ha establecido correctamente la configuración del escalado para escalar automáticamente la
aplicación web en función de una métrica personalizada.
Nota: Los mismos pasos son aplicables para empezar a trabajar con un rol de servicio en la nube o VMSS.
Tutorial: Creación de reglas de escalado automático
de conjuntos de escalado de máquinas virtuales con
Azure PowerShell
IMPORTANT
El uso de esta característica de Azure desde PowerShell requiere que tenga el módulo AzureRM instalado. Se trata de un
módulo anterior que solo está disponible para Windows PowerShell 5.1 que ya no obtiene nuevas características. Los
módulos Az y AzureRM no son compatibles cuando se instalan para las mismas versiones de PowerShell. Si necesita ambas
versiones:
1. Desinstale el módulo Az desde una sesión de PowerShell 5.1.
2. Instale el módulo AzureRM desde una sesión de PowerShell 5.1.
3. Descargue e instale PowerShell Core 6.x o posterior.
4. Instale el módulo Az en una sesión de PowerShell Core.
Al crear un conjunto de escalado, puede definir el número de instancias de máquina virtual que quiere ejecutar. A
medida que cambia la demanda de las aplicaciones, puede aumentar o reducir automáticamente el número de
estas instancias. La posibilidad de realizar el escalado automático le permite satisfacer la demanda del cliente o
responder a los cambios de rendimiento de la aplicación a lo largo del ciclo de vida de esta. En este tutorial,
aprenderá a:
Usar el escalado automático con un conjunto de escalado
Crear y usar reglas de escalado automático
Realizar pruebas de esfuerzo de instancias de máquina virtual y desencadenar reglas de escalado automático
Reducir el escalado automáticamente cuando se reduzca la demanda
Existe un problema conocido que afecta a la versión 6.8.1 o posterior del módulo de Azure PowerShell, incluida la
versión actual de Azure Cloud Shell. Este tutorial solo se puede realizar con la versión 6.0.0 a 6.8.0 del módulo de
Azure PowerShell. Ejecute Get-Module -ListAvailable AzureRM para encontrar la versión. Si PowerShell se ejecuta
localmente, también debe ejecutar Connect-AzureRmAccount para crear una conexión con Azure.
Creación de un conjunto de escalado

Para facilitar la creación de las reglas de escalado automático, defina algunas de las variables para el conjunto de
escalado. En el siguiente ejemplo se definen variables para el conjunto de escalado denominado myScaleSet del
grupo de recursos myResourceGroup en la región Este de EE. UU. El identificador de la suscripción se obtiene con
Get-AzureRmSubscription. Si tiene varias suscripciones asociadas a su cuenta, solo se devolverá la primera de
ellas. Ajuste los nombres y los identificadores de la suscripción como se indica a continuación:
$mySubscriptionId = (Get-AzureRmSubscription)[0].Id
$myResourceGroup = "myResourceGroup"
$myScaleSet = "myScaleSet"
$myLocation = "East US"
Ahora, cree un conjunto de escalado de máquinas virtuales con New-AzureRmVmss. Para distribuir el tráfico a las
instancias individuales de VM, también se crea un equilibrador de carga. El equilibrador de carga incluye reglas
para distribuir el tráfico en el puerto TCP 80, y permitir el tráfico de Escritorio remoto en el puerto TCP 3389 y la
conexión remota de PowerShell en el puerto TCP 5985. Cuando se le solicite, proporcione sus propias credenciales
administrativas para las instancias de máquina virtual en el conjunto de escalado:
New-AzureRmVmss `
-ResourceGroupName $myResourceGroup `
-VMScaleSetName $myScaleSet `
-Location $myLocation `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer"
Se tardan unos minutos en crear y configurar todos los recursos de conjunto de escalado y máquinas virtuales.
Creación de una regla de escalado automático horizontal

Si aumenta la demanda de la aplicación, la carga de las instancias de máquina virtual del conjunto de escalado
aumenta. Si este aumento de la carga es continuado, en lugar de ser algo puntual, puede configurar reglas de
escalado automático para aumentar el número de instancias de máquina virtual en el conjunto de escalado.
Cuando se crean estas instancias de máquina virtual y se implementan las aplicaciones, el conjunto de escalado
empieza a distribuir el tráfico entre ellas mediante el equilibrador de carga. Puede controlar qué métricas se deben
supervisar como, por ejemplo, la CPU o el disco, cuánto tiempo debe cumplir la carga de la aplicación un límite
determinado y cuántas instancias de máquina virtual se deben agregar al conjunto de escalado.
Vamos a crear una regla con New-AzureRmAutoscaleRule que aumenta el número de instancias de máquina
virtual de un conjunto de escalado cuando la carga promedio de la CPU es superior al 70 % durante un período de
más de 5 minutos. Cuando se desencadena la regla, aumenta el número de instancias de máquina virtual en tres.
Los siguientes parámetros se utilizan para esta regla:
PA RÁ M ET RO EXP L IC A C IÓ N VA L UE
-MetricName La métrica de rendimiento del conjunto Porcentaje de CPU

de escalado sobre el que realizar las
acciones de supervisión y aplicación.
-TimeGrain Frecuencia de recopilación de las 1 minuto.

métricas para el análisis.
-MetricStatistic Define cómo se deben agregar las Average

métricas recopiladas para el análisis.
-TimeWindow El periodo durante el que se realiza la 5 minutos

supervisión antes de que se comparen
los valores de métricas y umbrales.
-Operator El operador que se utiliza para Mayor que

comparar los datos de las métricas con
los umbrales.
-Threshold El valor que hace que la regla de 70%

escalado automático desencadene una
acción.
PA RÁ M ET RO EXP L IC A C IÓ N VA L UE
-ScaleActionDirection Define si el conjunto de escalado debe Aumento

escalarse o reducirse verticalmente.
-ScaleActionScaleType Indica que el número de instancias de Nº de cambios

máquina virtual debe cambiarse por un
valor especificado.
-ScaleActionValue El porcentaje de instancias de máquina 3

virtual se debe cambiar al
desencadenarse la regla.
-ScaleActionCooldown El periodo que hay que esperar hasta 5 minutos

que la regla se vuelva a aplicar, para que
las acciones de escalado automático
tengan tiempo de surtir efecto.
En el ejemplo siguiente se crea un objeto denominado myRuleScaleOut que contiene esta regla de escalado
vertical. - MetricResourceId usa las variables definidas anteriormente para el identificador de la suscripción, el
nombre del grupo de recursos y el nombre del conjunto de escalado:
$myRuleScaleOut = New-AzureRmAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId
/subscriptions/$mySubscriptionId/resourceGroups/$myResourceGroup/providers/Microsoft.Compute/virtualMachineSca
leSets/$myScaleSet `
-TimeGrain 00:01:00 `
-MetricStatistic "Average" `
-TimeWindow 00:05:00 `
-Operator "GreaterThan" `
-Threshold 70 `
-ScaleActionDirection "Increase" `
-ScaleActionScaleType "ChangeCount" `
-ScaleActionValue 3 `
-ScaleActionCooldown 00:05:00
Creación de una regla de escalado automático horizontal de reducción

La demanda de la aplicación puede reducirse por las tardes o durante los fines de semana. Si esta reducción es
constante a lo largo de un período, puede configurar reglas de escalado automático para reducir el número de
instancias de máquina virtual del conjunto de escalado. Esta acción de reducción horizontal permite rebajar el
costo de ejecutar el conjunto de escalado ya que solo se ejecuta el número de instancias necesario para satisfacer
la demanda actual.
Cree otra regla con New-AzureRmAutoscaleRule que reduzca el número de instancias de máquina virtual de un
conjunto de escalado cuando la carga promedio de la CPU sea inferior al 30 % durante un período de más de 5
minutos. Cuando se desencadena la regla, el número de instancias de máquina virtual se reduce en una. En el
ejemplo siguiente se crea un objeto denominado myRuleScaleOut que contiene esta regla de reducción vertical. -
MetricResourceId usa las variables definidas anteriormente para el identificador de la suscripción, el nombre del
grupo de recursos y el nombre del conjunto de escalado:
$myRuleScaleIn = New-AzureRmAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId
-Operator "LessThan" `
-MetricStatistic "Average" `
-Threshold 30 `
-TimeGrain 00:01:00 `
-TimeWindow 00:05:00 `
-ScaleActionCooldown 00:05:00 `
-ScaleActionDirection "Decrease" `
-ScaleActionScaleType "ChangeCount" `
-ScaleActionValue 1
Definición de un perfil de escalado automático

Cree un perfil para asociar las reglas de escalado automático a un conjunto de escalado. El perfil de escalado
automático define la capacidad predeterminada, mínima y máxima del conjunto de escalado y asocia las reglas de
escalado automático. Cree un perfil de escalado automático con New-AzureRmAutoscaleProfile. En el ejemplo
siguiente se establece la capacidad predeterminada y la mínima para 2 instancias de máquina virtual y un máximo
de 10. Las reglas de escalado y reducción horizontal creadas en los pasos anteriores se asocian ahora:
$myScaleProfile = New-AzureRmAutoscaleProfile `
-DefaultCapacity 2 `
-MaximumCapacity 10 `
-MinimumCapacity 2 `
-Rule $myRuleScaleOut,$myRuleScaleIn `
-Name "autoprofile"
Aplicación del perfil de escalabilidad automática a un conjunto de

escalado
El último paso consiste en aplicar el perfil de escalado automático al conjunto de escalado. Posteriormente, el
conjunto de escalado se podrá escalar o reducir horizontalmente en función de la demanda de la aplicación.
Aplique el perfil de escalado automático con Add-AzureRmAutoscaleSetting como se indica a continuación:
Add-AzureRmAutoscaleSetting `
-Location $myLocation `
-Name "autosetting" `
-ResourceGroup $myResourceGroup `
-TargetResourceId
-AutoscaleProfile $myScaleProfile
Generación de carga de CPU en el conjunto de escalado

Para probar las reglas de escalado automático, genere cargas de CPU en las instancias de máquina virtual del
conjunto de escalado. Esta carga de CPU simulada hace que las reglas de escalado automático escalen
horizontalmente y aumenten el número de instancias de máquina virtual. Como la carga simulada de la CPU se
reduce, las reglas de escalado automático reducen horizontalmente el número de instancias de máquina virtual.
Para obtener una lista de los puertos NAT para conectarse a instancias de máquina virtual en un conjunto de
escalado, primero obtenga el objeto de equilibrador de carga con el comando Get-AzureRmLoadBalancer.
Después, consulte las reglas NAT entrantes con Get-AzureRmLoadBalancerInboundNatRuleConfig:
# Get the load balancer object

$lb = Get-AzureRmLoadBalancer -ResourceGroupName "myResourceGroup" -Name "myLoadBalancer"
# View the list of inbound NAT rules

Get-AzureRmLoadBalancerInboundNatRuleConfig -LoadBalancer $lb | Select-Object
Name,Protocol,FrontEndPort,BackEndPort
La salida del ejemplo siguiente muestra el nombre de instancia, la dirección IP pública del equilibrador de carga y
el número de puerto al que las reglas NAT reenvían el tráfico:
Name Protocol FrontendPort BackendPort

---- -------- ------------ -----------
myRDPRule.0 Tcp 50001 3389
myRDPRule.1 Tcp 50002 3389
El nombre de la regla se alinea con el nombre de la instancia de máquina virtual como se muestra en un comando
Get-AzureRmVmssVM anterior. Por ejemplo, para conectarse a la instancia de máquina virtual 0, use myRDPRule.0
y conéctese al puerto 50001. Para conectarse a la instancia de máquina virtual 1, utilice el valor de myRDPRule.1 y
conéctese al puerto 50002.
Consulte la dirección IP pública del equilibrador de carga con Get-AzureRmPublicIPAddress:
Get-AzureRmPublicIpAddress -ResourceGroupName "myResourceGroup" -Name myPublicIP | Select IpAddress
Salida de ejemplo:
IpAddress
---------
52.168.121.216
Cree una conexión remota a la primera instancia de máquina virtual. Especifique su dirección IP pública y el
número de puerto de la instancia de máquina virtual necesaria, tal como se muestra en los comandos anteriores.
Cuando se le solicite, escriba las credenciales que ha utilizado al crear el conjunto de escalado (de forma
predeterminada en los comandos de ejemplo, azureuser y P@ssw0rd! ). Si se utiliza Azure Cloud Shell, realice este
paso desde un símbolo del sistema local de PowerShell o un cliente de Escritorio remoto. En el ejemplo siguiente
se realiza una conexión a la instancia de máquina virtual 0:
mstsc /v 52.168.121.216:50001
Con la sesión iniciada, abra Internet Explorer desde la barra de tareas.

Seleccione Aceptar para aceptar Usar la configuración recomendada de compatibilidad, privacidad y seguridad
en el símbolo del sistema.
Escriba http://download.sysinternals.com/files/CPUSTRES.zip en la barra de direcciones.
Como la configuración de seguridad mejorada de Internet Explorer está habilitada, elija Agregar el dominio
http://download.sysinternals.com a la lista de sitios de confianza.
Cuando se le solicite la descarga del archivo, seleccione Abrir , y seleccione y haga clic en Ejecutar para
ejecutar la herramienta CPUSTRES.EXE.
Para generar carga de la CPU, marque dos casillas de subprocesos activos . Desde el menú desplegable Actividad
de ambos subprocesos, seleccione Máximo. Puede abrir el Administrador de tareas para confirmar que la carga de
CPU en la máquina virtual está al 100 %.
Deje abierta la sesión de conexión a Escritorio remoto y abra otra. Conéctese a la segunda instancia de máquina
virtual con el número de puerto del cmdlet Get-AzureRmLoadBalancerInboundNatRuleConfig anterior:
mstsc /v 52.168.121.216:50002
Una vez iniciada la sesión en la segunda instancia de máquina virtual, repita los pasos anteriores para descargar y
ejecutar CPUSTRES.EXE. De nuevo, inicie dos subprocesos activos y establezca la actividad en Máximo.
Para permitir que la herramienta CPU Stress continúe ejecutándose, deje abierta ambas sesiones de conexión a
Escritorio remoto.
Supervisión de las reglas de escalado automático activas

Para supervisar el número de instancias de máquina virtual del conjunto de escalado, use while . Las reglas de
escalado automático tardan 5 minutos en empezar el proceso de escalado horizontal en respuesta a la carga de
CPU generada por CPUStress en cada instancia de máquina virtual:
while (1) {Get-AzureRmVmssVM `

-ResourceGroupName $myResourceGroup `
-VMScaleSetName $myScaleSet; sleep 10}
Cuando se alcanza el umbral de la CPU, las reglas de escalado automático aumentan el número de instancias de
máquina virtual en el conjunto de escalado. La siguiente salida muestra tres máquinas virtuales que se crean
durante el escalado horizontal automático:
ResourceGroupName Name Location Sku Capacity InstanceID ProvisioningState
----------------- ---- -------- --- -------- ---------- -----------------
MYRESOURCEGROUP myScaleSet_2 eastus Standard_DS2 2 Succeeded
MYRESOURCEGROUP myScaleSet_3 eastus Standard_DS2 3 Succeeded
MYRESOURCEGROUP myScaleSet_4 eastus Standard_DS2 4 Creating
Cierre la herramienta CPU Stress en todas las sesiones de conexión a Escritorio remoto de las instancias de
máquina virtual. La carga de CPU media del conjunto de escalado vuelve al estado normal. Después de otros 5
minutos, las reglas de escalado automático reducen horizontalmente el número de instancias de máquina virtual.
Con las acciones de reducción horizontal se eliminan instancias de máquina virtual en orden, empezando por los
identificadores mayores. Cuando un conjunto de escalado usa conjuntos de disponibilidad o zonas de
disponibilidad, las acciones de reducción horizontal se distribuyen por igual entre esas instancias de máquina
virtual. En la salida de ejemplo siguiente se muestra la eliminación de una instancia de máquina virtual con la
reducción horizontal del conjunto de escalado:
MYRESOURCEGROUP myScaleSet_6 eastus Standard_DS2 6 Deleting
Salga de while con Ctrl-c . El conjunto de escalado continúa la reducción horizontal cada 5 minutos y quita una
instancia de máquina virtual hasta que se alcanza el mínimo de dos instancias.
Para quitar el conjunto de escalado y los recursos adicionales, elimine el grupo de recursos y todos sus recursos
con Remove-AzureRmResourceGroup. El parámetro -Force confirma que desea eliminar los recursos sin pedir
confirmación adicional. El parámetro -AsJob devuelve el control a la petición de confirmación sin esperar a que
finalice la operación.
Remove-AzureRmResourceGroup -Name "myResourceGroup" -Force -AsJob
Pasos siguientes
En este tutorial aprendió cómo escalar y reducir horizontalmente de forma automática con Azure PowerShell:
Usar el escalado automático con un conjunto de escalado
Crear y usar reglas de escalado automático
Realizar pruebas de esfuerzo de instancias de máquina virtual y desencadenar reglas de escalado automático
Reducir el escalado automáticamente cuando se reduzca la demanda
Configuración avanzada de escalado automático con
plantillas de Resource Manager para conjuntos de
escalado de máquinas virtuales
Puede reducir y escalar horizontalmente los conjuntos de escalado de máquinas virtuales según umbrales de
métricas de rendimiento, siguiendo una programación periódica o por una fecha determinada. También puede
configurar notificaciones de correo electrónico y webhook para las acciones de escalado. Este tutorial muestra un
ejemplo de configuración de todos estos objetos utilizando una plantilla de Resource Manager en un conjunto de
escalado de máquinas virtuales.
NOTE
Aunque en este tutorial se explican los pasos para VM Scale Sets, la misma información se aplica al escalado automático de
Cloud Services, App Service Web Apps y servicios de API Management. Para conocer una configuración simple de escalado y
reducción horizontal en una instancia de VM Scale Set en una métrica de rendimiento simple, como CPU, consulte los
documentos para Linux y Windows.
Tutorial
En este tutorial, usaremos el Explorador de recursos de Azure para configurar y actualizar el valor de escalado
automático para un conjunto de escalado. El Explorador de recursos de Azure es una manera fácil de administrar
los recursos de Azure mediante las plantillas de Resource Manager. Si no está familiarizado con la herramienta
Explorador de recursos de Azure, lea esta introducción.
1. Implemente un nuevo conjunto de escala con un valor de escalado automático básico. Este artículo utiliza
uno de la Galería de inicio rápido de Azure, que tiene un conjunto de escala de Windows con una plantilla
básica de escalado automático. Los conjuntos de escala de Linux funcionan del mismo modo.
2. Una vez creado el conjunto de escala, navegue al recurso del mismo desde el Explorador de recursos de
Azure. En el nodo de Microsoft.Insights aparece lo siguiente.
La ejecución de la plantilla crea un valor de escalado automático predeterminado con el nombre
'autoscalewad' . En el lado derecho puede ver la definición completa de este valor de escalado automático.
En este caso, el valor de escalado automático predeterminado viene con una regla de escalado horizontal y
otra de reducción horizontal, ambas basadas en el % de CPU.
3. Ahora puede agregar más perfiles y reglas basadas en la programación o requisitos específicos. Creamos
una configuración de escalado automático con tres perfiles. Para comprender los perfiles y las reglas de
escalado automático, revise el artículo Procedimientos recomendados de escalado automático.
P ERF IL ES Y REGL A S DESC RIP C IÓ N
Perfil Basado en rendimiento/métrica
Regla Recuento de mensajes de cola de Service Bus > x
Regla Recuento de mensajes de cola de Service Bus > y
Regla CPU% > n
Regla % de CPU < p
Perfil Horas de la mañana días de semana, (no hay

reglas)
Perfil Día de lanzamiento de producto (no hay reglas)
4. Este es un escenario hipotético de escalado que se utiliza para este tutorial.

Basado en la carga : quisiera escalar horizontal o verticalmente según la carga en la aplicación
hospedada en mi conjunto de escalado.*
Tamaño de cola de mensajes : uso una cola de Service Bus para los mensajes entrantes a la
aplicación. Uso el % de CPU y el recuento de la cola de mensajes y configuro un perfil
predeterminado para desencadenar una acción de escalado si el número de mensajes o la CPU
alcanzan el umbral.*
Horario de la semana y el día : quiero un perfil periódico semanal basado en la "hora del día"
llamado "Horas de la mañana en semana". Según los datos históricos, ya sé que es mejor tener cierto
número de instancias de máquina virtual para administrar la carga de la aplicación durante este
tiempo.*
Fechas especiales : agrego un perfil de "Día de lanzamiento de producto". Planeo con antelación
para fechas específicas, de forma que mi aplicación esté preparada para controlar la carga que se
produce con los anuncios de marketing y cuando se coloca un nuevo producto en la aplicación.*
Los dos últimos perfiles también pueden contener otras reglas basadas en métricas de rendimiento.
En este caso, decidí no tener ninguno y confiar en las reglas basadas en las métricas de rendimiento
predeterminadas. Las reglas son opcionales para los perfiles periódico y basado en la fecha.
La asignación de prioridades de los perfiles y las reglas que realiza el motor de escalado automático
también se explica en el artículo sobre procedimientos recomendados de escalado automático. Para
ver una lista de las métricas más comunes para el escalado automático, consulte Métricas comunes
de escalado automático.
5. Asegúrese de que se encuentra en el modo de lectura y escritura en el Explorador de recursos.
6. Haga clic en Editar. Reemplace el elemento "perfiles" en la configuración de escalado automático por la
siguiente configuración:
{
"name": "Perf_Based_Scale",
"capacity": {
"minimum": "2",
"maximum": "12",
"default": "2"
},
"rules": [
{
"metricTrigger": {
"metricName": "MessageCount",
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue",
"threshold": 10
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"metricName": "MessageCount",
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue",
"threshold": 3
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/<this_vmss_na
me>",
"threshold": 85
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
},
{
"metricTrigger": {
"/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachineScaleSets/<this_vmss_na
me>",
"threshold": 60
},
"scaleAction": {
"value": "1",
"cooldown": "PT5M"
}
}
]
},
{
"name": "Weekday_Morning_Hours_Scale",
"capacity": {
"minimum": "4",
"maximum": "12",
"default": "4"
},
"rules": [],
"recurrence": {
"schedule": {
"days": [
"Monday",
"Tuesday",
"Wednesday",
"Thursday",
"Friday"
],
"hours": [
6
],
"minutes": [
0
]
}
}
},
{
"name": "Product_Launch_Day",
"capacity": {
"minimum": "6",
"maximum": "20",
"default": "6"
},
"rules": [],
"fixedDate": {
"start": "2016-06-20T00:06:00Z",
"end": "2016-06-21T23:59:00Z"
}
}
Para los campos compatibles y sus valores, consulte la documentación de la API de REST de escalado
automático. La configuración de escalado automático contiene ahora los tres perfiles explicados
anteriormente.
7. Por último, echemos un vistazo a la sección de notificación del escalado automático. Las notificaciones de
escalado automático le permiten hacer tres cosas cuando se desencadena correctamente un escalado o una
reducción horizontal.
Notificar a los administradores y coadministradores de su suscripción
Enviar un correo electrónico a un conjunto de usuarios
Desencadenar una llamada de webhook. Cuando se desencadena, este webhook envía metadatos sobre
la condición de escalado automático y el recurso de conjunto de escala. Para más información acerca de
la carga del webhook de escalado automático, consulte Uso de acciones de escalado automático para
enviar notificaciones de alerta por correo electrónico y Webhook en Azure Insights.
Agregue lo siguiente al valor de escalado automático para reemplazar el elemento notification cuyo valor
es null.
"notifications": [
{
"operation": "Scale",
"email": {
"sendToSubscriptionAdministrator": true,
"sendToSubscriptionCoAdministrators": false,
"customEmails": [
"user1@mycompany.com",
"user2@mycompany.com"
]
},
"webhooks": [
{
"serviceUri": "https://foo.webhook.example.com?token=abcd1234",
"properties": {
"optional_key1": "optional_value1",
"optional_key2": "optional_value2"
}
}
]
}
]
Presione el botón Put en el Explorador de recursos para actualizar el valor de escalado automático.
Ha actualizado un valor de escalado automático en un conjunto de escala de máquina virtual para incluir varios
perfiles y notificaciones de escalado.
Pasos siguientes
Siga estos vínculos para más información sobre el escalado automático:
Solución de problemas de escalado automático de conjuntos de escalado de máquinas virtuales
Métricas comunes de escalado automático
Procedimientos recomendados de escalado automático
Administración del escalado automático con PowerShell
Administración del escalado automático con CLI
Configuración de webhooks y notificaciones por correo electrónico en el escalado automático
Referencia de la plantilla de Microsoft.Insights/autoscalesettings
Uso de acciones de escalado automático para enviar
notificaciones de alerta por correo electrónico y
Webhook en Azure Monitor
En este artículo se muestra cómo configurar desencadenadores para que pueda llamar a direcciones URL web
específicas o enviar mensajes de correo electrónico en función de las acciones de escalado automático en Azure.
webhooks
Los Webhook permiten enrutar las notificaciones de alerta de Azure a otros sistemas para procesarlas
posteriormente o notificaciones personalizadas. Un ejemplo de esto puede ser el enrutamiento de la alerta a los
servicios que pueden controlar una solicitud web entrante para enviar SMS, registrar errores o notificar a un
equipo mediante servicios de chat y mensajería. El identificador URI de webhook debe ser un punto de conexión
HTTP o HTTPS válido.
Email
Se pueden enviar mensajes de correo electrónico a cualquier dirección de correo electrónico válida. También se
enviará una notificación a los administradores y los coadministradores de la suscripción en la que se ejecuta la
regla.
Cloud Services y App Services

Puede participar desde Azure Portal en Cloud Services y granjas de servidores (App Services).
Elija la Escalar por .
Conjuntos de escalado de máquina virtual

Para las máquinas virtuales más recientes creadas con Resource Manager (conjuntos de escala de máquina
virtual), puede configurar esto con la API de REST, las plantillas de Resource Manager, PowerShell y CLI. Aún no se
encuentra disponible una interfaz de portal. Al utilizar la API REST o la plantilla de Resource Manager, incluya el
elemento de notificaciones en el objeto autoscalesettings con las siguientes opciones.
"notifications": [
{
"operation": "Scale",
"email": {
"sendToSubscriptionAdministrator": false,
"sendToSubscriptionCoAdministrators": false,
"customEmails": [
"user1@mycompany.com",
"user2@mycompany.com"
]
},
"webhooks": [
{
"serviceUri": "https://foo.webhook.example.com?token=abcd1234",
"properties": {
"optional_key1": "optional_value1",
"optional_key2": "optional_value2"
}
}
]
}
]
CAMPO ¿O B L IGATO RIO ? DESC RIP C IÓ N
operation sí el valor debe ser "Scale"
sendToSubscriptionAdministrator sí el valor debe ser "true" o "false"
sendToSubscriptionCoAdministrators sí el valor debe ser "true" o "false"
customEmails sí el valor puede ser null [] o una cadena

de matriz de mensajes de correo
electrónico
webhooks sí el valor puede ser null o un

identificador URI válido
serviceUri sí un identificador URI de https válido
properties sí el valor debe ser {} vacío o puede

contener pares clave-valor
Autenticación en Webhook
El webhook puede realizar la autenticación con un método basado en token, en el que el URI del webhook se
guarda con un identificador de token como un parámetro de consulta. Por ejemplo,
https://mysamplealert/webcallback?tokenid=sometokenid&someparameter=somevalue
Esquema de carga de Webhook de notificación de escalado

automático
Cuando se genera la notificación de escalado automático, los metadatos siguientes se incluyen en la carga de
Webhook:
{
"version": "1.0",
"status": "Activated",
"operation": "Scale In",
"context": {
"timestamp": "2016-03-11T07:31:04.5834118Z",
"id":
"/subscriptions/s1/resourceGroups/rg1/providers/microsoft.insights/autoscalesettings/myautoscaleSetting",
"name": "myautoscaleSetting",
"details": "Autoscale successfully started scale operation for resource 'MyCSRole' from
capacity '3' to capacity '2'",
"subscriptionId": "s1",
"resourceGroupName": "rg1",
"resourceName": "MyCSRole",
"resourceType": "microsoft.classiccompute/domainnames/slots/roles",
"resourceId":
"/subscriptions/s1/resourceGroups/rg1/providers/microsoft.classicCompute/domainNames/myCloudService/slots/Pro
duction/roles/MyCSRole",
"portalLink":
"https://portal.azure.com/#resource/subscriptions/s1/resourceGroups/rg1/providers/microsoft.classicCompute/do
mainNames/myCloudService",
"oldCapacity": "3",
"newCapacity": "2"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
status sí Estado que indica que se ha generado

una acción de escalado automático.
operation sí Para un aumento de instancias, será

"Escalar horizontalmente"; para una
disminución de instancias, "Reducir
horizontalmente".
context sí Contexto de la acción de escalado

automático.
timestamp sí Marca de tiempo cuando se

desencadena la acción de escalado
automático.
id Sí Id. de Resource Manager de la

configuración de escalado automático
name Sí Nombre de la configuración de

escalado automático.
detalles Sí Explicación de la acción que realizó el

servicio de escalado automático y el
cambio en el recuento de instancias.
subscriptionId Sí Id. de suscripción del recurso de

destino que se está escalando.
resourceGroupName Sí Nombre del grupo de recursos del

recurso de destino que se está
escalando.
resourceName Sí Nombre del recurso de destino que se

está escalando.
resourceType Sí Los tres valores admitidos:

"microsoft.classiccompute/domainname
s/slots/roles" - Roles del servicio en la
nube,
"microsoft.compute/virtualmachinescale
sets" - Conjuntos de escalado de
máquina virtual
"Microsoft.Web/serverfarms" - Web
App
resourceId Sí Id. de Resource Manager del recurso de

destino que se está escalando
portalLink Sí Vínculo del portal de Azure a la página

de resumen del recurso de destino.
oldCapacity Sí Recuento de instancias (antiguo) actual

cuando el escalado automático ha
realizado una acción de escalado.
newCapacity Sí Nuevo recuento de instancias al que el

escalado automático escaló el recurso.
properties No Opcional. Conjunto de pares <Clave,

Valor> (por ejemplo, Diccionario
<Cadena, Cadena>). El campo de
propiedades es opcional. En una
interfaz de usuario personalizada o un
flujo de trabajo basado en una
aplicación lógica, puede escribir las
claves y los valores que se pueden
transmitir utilizando la carga. La forma
alternativa para transmitir propiedades
personalizadas a la llamada de
Webhook de salida es mediante el
propio URI de Webhook (como
parámetros de consulta).
Solución de problemas de escalabilidad automática
de Azure
Gracias a la escalabilidad automática de Azure Monitor, puede ejecutar la cantidad correcta de recursos para
administrar la carga de la aplicación. Permite agregar recursos para administrar el aumento de la carga y ahorrar
dinero mediante la eliminación de recursos inactivos. Puede escalar en función de una programación, una fecha y
hora fijas o la métrica de recursos que elija. Para más información, consulte Introducción a la escalabilidad
automática.
El servicio de escalabilidad automática proporciona métricas y registros para comprender las acciones de escalado
que se han producido y la evaluación de las condiciones que han dado lugar a esas acciones. Puede encontrar
respuesta a preguntas como las siguientes:
¿Por qué mi servicio se ha escalado o reducido horizontalmente?
¿Por qué no se ha escalado mi servicio?
¿Por qué se ha producido un error en una acción de escalabilidad automática?
¿Por qué una acción de escalabilidad automática tarda tiempo en escalar?
Métricas de escalabilidad automática

La escalabilidad automática le proporciona cuatro métricas para comprender su funcionamiento.
Valor de métrica obser vado : el valor de la métrica en la que ha elegido llevar a cabo la acción de escalado,
tal como lo ha detectado o calculado el motor de escalabilidad automática. Dado que una única configuración
de escalabilidad automática puede tener varias reglas y, por lo tanto, varios orígenes de métricas, puede filtrar
mediante "origen de métrica" como dimensión.
Umbral de métrica : el umbral establecido para realizar la acción de escalado. Como una única configuración
de escalabilidad automática puede tener varias reglas y, por lo tanto, varios orígenes de métricas, puede filtrar
mediante "regla de métrica" como dimensión.
Capacidad obser vada : el número activo de instancias del recurso de destino tal como lo ha detectado el
motor de escalabilidad automática.
Acciones de escalado iniciadas : el número de acciones de escalabilidad horizontal y reducción horizontal
iniciadas por el motor de escalabilidad automática. Puede filtrar por acciones de escalabilidad horizontal y de
reducción horizontal.
Puede utilizar el Explorador de métricas para representar todas las métricas anteriores en un único lugar. El gráfico
debería mostrar:
la métrica real
la métrica tal como la ha detectado o calculado el motor de escalabilidad automática
el umbral de una acción de escalado
el cambio en capacidad
Ejemplo 1: análisis de una regla de escalabilidad automática simple

Tenemos una configuración de escalabilidad automática simple para un conjunto de escalado de máquinas
virtuales que:
se escala horizontalmente cuando el promedio de porcentaje de CPU de un conjunto es superior al 70 %
durante 10 minutos
se reduce horizontalmente cuando el porcentaje de CPU del conjunto es inferior al 5 % durante más de
10 minutos.
Vamos a revisar las métricas del servicio de escalabilidad automática.
Figura 1a: porcentaje de métricas de CPU para el conjunto de escalado de máquinas vir tuales y la
métrica Valor de métrica obser vado para la configuración de escalabilidad automática
Figura 1b: Umbral de métrica y Capacidad obser vada

En la ilustración 1b, el Umbral de métrica (línea azul claro) de la regla de escalabilidad horizontal es 70. La
Capacidad obser vada (línea azul oscura) muestra el número de instancias activas, que actualmente es de 3.
NOTE
Tendrá que filtrar el Umbral de métrica por la regla de escalabilidad horizontal de la dimensión de la regla del
desencadenador de métricas (aumento) para ver el umbral de escalabilidad horizontal y la escala en la regla (reducción).
Ejemplo 2: escalabilidad automática avanzada para un conjunto de

Disponemos de una configuración de escalabilidad automática que permite escalar horizontalmente un recurso del
conjunto de escalado de máquinas virtuales en función de su propia métrica Flujos salientes . Observe que la
opción de dividir la métrica por el recuento de instancias para el umbral de métrica está activada.
La regla de la acción de escalado es:
Si el valor de Outbound Flow per instance (Flujo saliente por instancia) es mayor que 10, el servicio de
escalabilidad automática se debe escalar horizontalmente en 1 instancia.
En este caso, el valor de métrica observado del motor de escalabilidad automática se calcula como el valor de
métrica real dividido por el número de instancias. Si el valor de métrica observado es inferior al umbral, no se
inicia ninguna acción de escalabilidad horizontal.
Figura 2: ejemplo de gráficos de métricas de escalabilidad automática del conjunto de escalado de

máquinas vir tuales
En la ilustración 2, puede ver dos gráficos de métricas.
En el gráfico de la parte superior se muestra el valor real de la métrica Flujos salientes . El valor real es 6.
En el gráfico de la parte inferior se muestran algunos valores.
El Valor de métrica obser vado (azul claro) es 3 porque hay 2 instancias activas y 6 dividido entre 2 es 3.
La Capacidad obser vada (púrpura) muestra el recuento de instancias que detecta el motor de escalabilidad
automática.
El Umbral de métrica (verde claro) se establece en 10.
Si hay varias reglas de acción de escalado, puede usar la división o la opción Agregar filtro en el gráfico del
Explorador de métricas para ver la métrica de una regla o un origen específico. Para más información sobre cómo
dividir un gráfico de métricas, consulte Características avanzadas de gráficos de métricas: división
Ejemplo 3: descripción de los eventos de escalabilidad automática

En la pantalla de configuración de escalabilidad automática, vaya a la pestaña Hist. de eje. para ver las acciones de
escalado más recientes. En la pestaña también se muestra el cambio en la Capacidad obser vada a lo largo del
tiempo. Para ver más detalles sobre todas las acciones de escalabilidad automática, incluidas las operaciones como
actualizar o eliminar la configuración de escalabilidad automática, consulte el registro de actividad y filtre por las
operaciones de escalabilidad automática.
Escalabilidad automática de registros de recursos

Igual que cualquier otro recurso de Azure, el servicio de escalabilidad automática proporciona registros de
recursos. Existen dos categorías de registros.
Evaluaciones de escalabilidad automática : el motor de escalabilidad automática registra las entradas
de registro para cada evaluación de condición única cada vez que realiza una comprobación. La entrada
incluye detalles sobre los valores observados de las métricas, las reglas evaluadas y si la evaluación ha dado
como resultado una acción de escalado o no.
Acciones de escalabilidad automática : el motor registra los eventos de acción de escalado iniciados por
el servicio de escalabilidad automática y los resultados de estas acciones de escalado (correcto, error y
cantidad de escalado que ha detectado el servicio de escalabilidad automática).
Al igual que con cualquier servicio compatible con Azure Monitor, puede usar Configuración de diagnóstico para
enrutar estos registros:
al área de trabajo de Log Analytics para análisis detallados
a Event Hubs y, a continuación, a herramientas que no son de Azure
a la cuenta de Azure Storage para archivo
En la imagen anterior se muestra la configuración de diagnóstico de escalabilidad automática de Azure Portal. Allí
puede seleccionar la pestaña Registros de diagnóstico/recursos y habilitar la recopilación y el enrutamiento de
registros. También puede realizar la misma acción mediante la API REST, CLI, PowerShell y plantillas del
Administrador de recursos para la configuración de diagnóstico eligiendo el tipo de recurso como
Microsoft.Insights/AutoscaleSettings.
Solución de problemas mediante registros de escalabilidad automática

Para una mejor experiencia de solución de problemas, se recomienda enrutar los registros a Registros de Azure
Monitor (Log Analytics) a través de un área de trabajo cuando crea la configuración de escalabilidad automática.
Este proceso se muestra en la imagen de la sección anterior. Puede asegurarse de las acciones de evaluación y
escalado mejor con Log Analytics.
Una vez que haya configurado los registros de escalabilidad automática para enviarlos al área de trabajo de Log
Analytics, puede ejecutar las siguientes consultas para comprobar los registros.
Para empezar, pruebe esta consulta para ver los registros de evaluación de escalabilidad automática más recientes:
AutoscaleEvaluationsLog
| limit 50
O bien, intente la siguiente consulta para ver los registros de acciones de escalado más recientes:
AutoscaleScaleActionsLog
| limit 50
Use las secciones siguientes para estas cuestiones.
Se ha producido una acción de escalado que no esperaba

En primer lugar, ejecute la consulta para que la acción de escalado encuentre la acción de escalado que le interesa.
Si es la acción de escalado más reciente, utilice la siguiente consulta:
| take 1
Seleccione el campo CorrelationId en el registro de acciones de escalado. Utilice el campo CorrelationId para
buscar el registro de evaluación correcto. Al ejecutar la consulta siguiente, se mostrarán todas las reglas y
condiciones evaluadas que llevan a esta acción de escalado.
| where CorrelationId = "<correliationId>"
¿Qué perfil ha provocado una acción de escalado?

Se ha producido una acción de escalado, pero tiene reglas y perfiles superpuestos, y debe realizar un seguimiento
de cuáles son los que han producido la acción.
Busque el campo correlationId de la acción de escalado (como se explica en el ejemplo 1) y, después, ejecute la
consulta en los registros de evaluación para ver más información sobre el perfil.
| where CorrelationId = "<correliationId_Guid>"
| where ProfileSelected == true
| project ProfileEvaluationTime, Profile, ProfileSelected, EvaluationResult
La evaluación de todo el perfil también se puede entender mejor con la siguiente consulta
| where OperationName contains == "profileEvaluation"
| project OperationName, Profile, ProfileEvaluationTime, ProfileSelected, EvaluationResult
No se ha producido una acción de escalado

Esperaba una acción de escalado y no se ha producido. Puede que no haya ningún registro o evento de acción de
escalado.
Revise las métricas de escalabilidad automática si usa una regla de escalado basada en métricas. Es posible que el
Valor de métrica obser vado o la Capacidad obser vada no sean lo que esperaba y, por lo tanto, no se haya
activado la regla de escalado. Aún seguirá viendo evaluaciones, pero no una regla de escalabilidad horizontal.
También es posible que el tiempo de recuperación impida que se produzca una acción de escalado.
Revise los registros de evaluación de escalabilidad automática durante el período de tiempo en el que esperaba
que se produjera la acción de escalado. Revise todas las evaluaciones que ha realizado y por qué decidió no
desencadenar una acción de escalado.
| where OperationName == "MetricEvaluation" or OperationName == "ScaleRuleEvaluation"
| project OperationName, MetricData, ObservedValue, Threshold, EstimateScaleResult
Error durante la acción de escalado

Puede haber casos en los que el servicio de escalabilidad automática haya realizado la acción de escalado, pero el
sistema ha decidido no escalar o no ha podido completar la acción de escalado. Use esta consulta para buscar las
acciones de escalado con errores.
| where ResultType == "Failed"
| project ResultDescription
Cree reglas de alertas para recibir notificaciones de errores o acciones de escalabilidad automática. También puede
crear reglas de alertas para recibir notificaciones sobre los eventos de escalabilidad automática.
Esquema de registros de recursos de escalabilidad automática

Para más información, consulte los registros de recursos de escalabilidad automática
Pasos siguientes
Lea información sobre Procedimientos recomendados de escalabilidad automática.
Esquema de registro de recursos de acciones de
escalabilidad automática de Azure Monitor
A continuación se muestran los formatos generales para los registros de recursos de escalabilidad automática que
incluyen datos de ejemplo. No todos los ejemplos siguientes son JSON formados correctamente porque pueden
incluir varios valores que podrían ser válidos para un campo determinado.
Use los eventos de este tipo para solucionar los problemas de escalabilidad automática que pueda tener. Para más
información, consulte Solución de problemas de escalabilidad automática.
Evaluación del perfil

Se registra cuando la escalabilidad automática busca primero un perfil de escalabilidad automática
{
"time": "2018-09-10 18:12:00.6132593",
"resourceId": "/SUBSCRIPTIONS/BA13C41D-C957-4774-8A37-
092D62ACFC85/RESOURCEGROUPS/AUTOSCALETRACKING12042017/PROVIDERS/MICROSOFT.INSIGHTS/AUTOSCALESETTINGS/DEFAULTSE
TTING",
"operationName": ["FixedDateProfileEvaluation", "RecurrentProfileEvaluation", "DefaultProfileEvaluation"],
"category": "AutoscaleEvaluations",
"correlationId": "e8f67045-f381-445d-bc2d-eeff81ec0d77",
"property": {
"targetResourceId": "/subscriptions/d45c994a-809b-4cb3-a952-
e75f8c488d23/resourceGroups/RingAhoy/providers/Microsoft.Web/serverfarms/ringahoy",
"profile": "defaultProfile",
"profileSelected": [true, false]
}
}
Evaluación de la recuperación de perfiles

Se registra cuando la escalabilidad automática evalúa si no debe realizar una escala debido a un período de
recuperación.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "ScaleRuleCooldownEvaluation",
"property": {
"selectedProfile": "defaultProfile",
"scaleDirection": ["Increase", "Decrease"]
"lastScaleActionTime": "2018-09-10 18:08:00.6132593",
"cooldown": "00:30:00",
"evaluationTime": "2018-09-10 18:11:00.6132593",
"skipRuleEvaluationForCooldown": true
}
}
Evaluación de la regla de acceso

Se registra cuando la escalabilidad automática comienza primero a evaluar una regla de escala determinada.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "ScaleRuleEvaluation",
"property": {
"timeGrain": "00:01:00",
"timeGrainStatistic": "Average",
"timeWindow": "00:10:00",
"timeAggregationType": "Average",
"threshold": 70,
"observedValue": 25,
"estimateScaleResult": ["Triggered", "NotTriggered", "Unknown"]
}
}
Evaluación de la métrica
Se registra cuando la escalabilidad automática evalúa la métrica que se usa para desencadenar una acción de
escalado.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "MetricEvaluation",
"property": {
"timeGrain": "00:01:00",
"timeGrainStatistic": "Average",
"startTime": "2018-09-10 18:00:00.43833793",
"endTime": "2018-09-10 18:10:00.43833793",
"data": [0.33333333333333331,0.16666666666666666,1.0,0.33333333333333331,2.0,0.16666666666666666,9.5]
}
}
Evaluación del recuento de instancias

Se registra cuando la escalabilidad automática evalúa el número de instancias que ya se están ejecutando en
preparación para decidir si debe iniciar otras, cerrar algunas o no hacer nada.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "InstanceCountEvaluation",
"property": {
"currentInstanceCount": 20,
"minimumInstanceCount": 15,
"maximumInstanceCount": 30,
"defaultInstanceCount": 20
}
}
Evaluación de la acción de escalado

Se registra cuando la escalabilidad automática comienza a evaluar si se debe realizar una acción de escalado.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "ScaleActionOperationEvaluation",
"property": {
"lastScaleActionOperationId": "378ejr-7yye-892d-17dd-92ndijfe1738",
"lastScaleActionOperationStatus": ["InProgress", "Timeout"]
"skipCurrentAutoscaleEvaluation": [true, false]
}
}
Evaluación de la actualización de instancias

Se registra cuando la escalabilidad automática actualiza el número de instancias de proceso en ejecución, ya sea
hacia arriba o hacia abajo.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "InstanceUpdateEvaluation",
"property": {
"newInstanceCount": 21,
"shouldUpdateInstance": [true, false],
"reason": ["Scale down action triggered", "Scale up to default instance count", ...]
}
}
Acción de escalado
Se registra cuando la escalabilidad automática inicia una acción de escalado, ya sea vertical u horizontal.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "InstanceScaleAction",
"category": "AutoscaleScaleActions",
"resultType": ["Succeeded", "InProgress", "Failed"],
"resultDescription": ["Create async operation job failed", ...]
"property": {
"newInstanceCount": 21,
"scaleDirection": ["Increase", "Decrease"],
["createdAsyncScaleActionJob": [true, false],]
["createdAsyncScaleActionJobId": "378ejr-7yye-892d-17dd-92ndijfe1738",]
}
}
Seguimiento de la acción de escalado

Se registra a intervalos diferentes de una acción de escalado de instancia.
{
"time": "2018-09-10 18:12:00.6132593",
TTING",
"operationName": "InstanceScaleAction",
"category": "AutoscaleScaleActions",
"property": {
"scaleActionOperationId": "378ejr-7yye-892d-17dd-92ndijfe1738",
"scaleActionOperationStatus": ["InProgress", "Timeout", "Canceled", ...],
"scaleActionMessage": ["Scale action is inprogress", ...]
}
}
Pasos siguientes
Más información sobre escalabilidad automática
Creación, visualización y administración de
alertas de métricas mediante Azure Monitor
Las alertas de métricas en Azure Monitor proporcionan una forma de recibir notificaciones cuando una
de sus métricas cruza un umbral. Las alertas de métricas funcionan en una amplia variedad de métricas
de plataforma multidimensionales, métricas personalizadas y métricas personalizadas y estándar de
Application Insights. En este artículo describiremos cómo crear, ver y administrar las reglas de alertas de
métricas a través de Azure Portal y la CLI de Azure. También puede crear reglas de alertas de métricas
mediante plantillas de Azure Resource Manager, que se describen en otro artículo.
Puede obtener más información acerca del funcionamiento de las alertas de métricas en el artículo
sobre información general de las alertas de métricas.
Creación con Azure Portal

En el siguiente procedimiento se describe cómo crear una regla de alertas de métricas en Azure Portal:
1. En Azure Portal, haga clic en Monitor . La hoja {1}Monitor{2} consolida todas las opciones de
configuración y todos los datos de supervisión en una vista.
2. Haga clic en Aler tas y, a continuación, en + Nueva regla de aler tas .
TIP
La mayoría de las hojas de recursos también tienen la opción Aler tas en el menú de recursos de la
sección Super visión , de modo que también podría crear alertas desde allí.
3. Haga clic en Seleccionar destino , en el panel de contexto que se carga, y seleccione un recurso
de destino sobre el que quiera alertar. Use los menús desplegables Suscripción y Tipo de
recurso para buscar el recurso que quiere supervisar. También puede utilizar la barra de
búsqueda para buscar su recurso.
4. Si el recurso seleccionado tiene métricas para las que puede crear alertas, la sección Available
signals (Señales disponibles) de la parte inferior derecha incluirá métricas. Puede ver la lista
completa de tipos de recursos compatibles con las alertas de métricas en este artículo.
5. Una vez haya seleccionado un recurso de destino, haga clic en Agregar condición .
6. Verá una lista de señales que se admiten para el recurso. Seleccione la métrica para la que quiera
crear una alerta.
7. Verá un gráfico para la métrica de las últimas seis horas. Use la lista desplegable Período del
gráfico para ver un historial más largo de la métrica.
8. Si la métrica tiene dimensiones, podrá ver una tabla de dimensiones. Seleccione uno o varios
valores por dimensión.
Los valores de dimensión mostrados se basan en los datos de métrica de los últimos tres días.
Si no se muestra el valor de dimensión que está buscando, haga clic en "+" para agregar un
valor personalizado.
También puede seleccionar * para cualquiera de las dimensiones. Si selecciona * , se
escalará dinámicamente la selección de todos los valores actuales y futuros de una dimensión.
La regla de alertas de métricas evaluará la condición para todas las combinaciones de valores
seleccionados. Obtenga más información sobre cómo funciona la creación de alertas en las
métricas multidimensionales.
9. Seleccione el tipo de Umbral , Operador y Tipo de agregación . Esto determinará la lógica que
evaluará la regla de alertas de métricas.
Si usa un umbral Estático , siga para definir un Valor de umbral . El gráfico de métricas
puede ayudar a determinar cuál podría ser un umbral razonable.
Si usa un umbral Dinámico , siga para definir la Sensibilidad del umbral . El gráfico de
métricas mostrará los umbrales calculados según los datos recientes. Más información sobre
las opciones de tipo y sensibilidad de la condición de umbrales dinámicos.
10. Opcionalmente, refine la condición ajustando las opciones Granularidad de agregación y
Frecuencia de evaluación .
11. Haga clic en Done (Listo).
12. Opcionalmente, puede agregar otro criterio si quiere supervisar una regla de alertas compleja.
Actualmente los usuarios pueden tener reglas de alertas con criterios de umbrales dinámicos
como único criterio.
13. Rellene los Detalles de aler tas como Nombre de la regla de aler tas , Descripción y
Gravedad .
14. Agregue un grupo de acciones a la alerta, ya sea seleccionando un grupo de acciones existente o
creando uno nuevo.
15. Haga clic en Listo para guardar la regla de alertas de métrica.
NOTE
Las reglas de alertas de métricas creadas mediante el portal se crean en el mismo grupo de recursos que el
recurso de destino.
Visualización y administración con Azure Portal

Puede ver y administrar las reglas de alertas de métricas mediante la hoja Administrar reglas de Alertas.
En el siguiente procedimiento se muestra cómo puede ver las reglas de alertas de métricas y editar una
de ellas.
1. En Azure Portal, vaya a Monitor .
2. Haga clic en Aler tas y Administrar reglas
3. En la hoja Administrar reglas , puede ver todas las reglas de alertas de las suscripciones. Puede
filtrar aún más las reglas mediante las opciones Grupo de recursos , Tipo de recurso y
Recurso . Si solo quiere ver las alertas de métricas, seleccione Métricas en Tipo de señal .
TIP
En la hoja Administrar reglas , puede seleccionar varias reglas de alertas y habilitarlas o deshabilitarlas.
Esto puede resultarle útil cuando es necesario realizar un mantenimiento de determinados recursos de
destino.
4. Haga clic en el nombre de la regla de alertas de métricas que quiera editar.
5. En la regla Editar, haga clic en los criterios de aler ta que quiera editar. Puede cambiar la
métrica, la condición de umbral y otros campos según sea necesario
NOTE
No puede editar el recurso de destino y el nombre de la regla de aler tas después de crear la
alerta de métrica.
6. Haga clic en Listo para guardar los cambios.
Con la CLI de Azure

En las secciones anteriores se describía cómo crear, ver y administrar las reglas de alertas de métricas
mediante Azure Portal. En esta sección se describe cómo hacer lo mismo con la multiplataforma CLI de
Azure. La forma más rápida de comenzar a utilizar la CLI de Azure es a través de Azure Cloud Shell. En
este artículo, usamos Cloud Shell.
1. Vaya a Azure Portal y haga clic en Cloud Shell .
2. En el símbolo del sistema, puede usar los comandos con la opción --help para obtener más
información sobre el comando y cómo usarlo. Por ejemplo, el comando siguiente muestra la lista
de comandos disponibles para crear, ver y administrar alertas de métricas.
az monitor metrics alert --help
3. Puede crear una regla de alertas de métricas sencilla que supervise si el porcentaje medio de la
CPU en una máquina virtual es mayor que 90.
az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes

{VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description
{descriptionofthealert}
4. Puede ver todas las alertas de métricas en un grupo de recursos con el siguiente comando.
az monitor metrics alert list -g {ResourceGroup}
5. Puede ver los detalles de una regla de alertas métricas determinada mediante el nombre o el
identificador del recurso de la regla.
az monitor metrics alert show -g {ResourceGroup} -n {AlertRuleName}
az monitor metrics alert show --ids {RuleResourceId}
6. Puede deshabilitar una regla de alertas de métricas con el comando siguiente.
az monitor metrics alert update -g {ResourceGroup} -n {AlertRuleName} --enabled false
7. Puede eliminar una regla de alertas de métricas con el comando siguiente.

az monitor metrics alert delete -g {ResourceGroup} -n {AlertRuleName}
Con PowerShell
Las reglas de alertas de métricas disponen de cmdlets dedicados de PowerShell:
Add-AzMetricAlertRuleV2: cree una nueva regla de alerta de métrica o actualice una existente.
Get-AzMetricAlertRuleV2: obtenga una o varias reglas de alerta de métricas.
Remove-AzMetricAlertRuleV2: elimine una regla de alerta de métrica.
Con API REST

Crear o actualizar: cree una nueva regla de alerta de métrica o actualice una existente.
Obtener: obtenga una regla de alerta de métrica específica.
Enumerar por grupo de recursos: obtenga una lista de reglas de alertas de métricas en un grupo de
recursos específico.
Lista por suscripción: obtenga una lista de reglas de alertas de métricas en una suscripción
específica.
Actualizar: actualice una regla de alerta de métrica.
Eliminar: elimine una regla de alerta de métrica.
Pasos siguientes
Creación de alertas de métricas con plantillas de Azure Resource Manager.
Comprender cómo funcionan las alertas de métricas.
Cómo funcionan las alertas de métricas con la condición de umbrales dinámicos.
Comprender el esquema de webhook para las alertas de métricas
Supervisión de la disponibilidad de un sitio web
Después de haber implementado la aplicación o sitio web, puede configurar pruebas periódicas para supervisar la
disponibilidad y capacidad de respuesta. Azure Application Insights envía solicitudes web a su aplicación a
intervalos regulares desde puntos de todo el mundo. Puede enviar una alerta si la aplicación no responde o si
responde de manera demasiada lenta.
Puede configurar pruebas de disponibilidad para cualquier punto de conexión HTTP o HTTPS que sea accesible
desde la red pública de Internet. No hace falta realizar cambios en el sitio web que está probando. De hecho, incluso
no hace falta que sea un sitio de su propiedad. Puede probar la disponibilidad de una API de REST de la que
depende su servicio.
Tipos de pruebas de disponibilidad:
Hay tres tipos de pruebas de disponibilidad:
Prueba de ping de la dirección URL: una prueba sencilla que se puede crear en el portal de Azure.
Prueba web de varios pasos: una grabación de una secuencia de solicitudes web que se pueden reproducir para
probar los escenarios más complejos. Las pruebas web de varios pasos se crean en Visual Studio Enterprise y se
carga en el portal para su ejecución.
Pruebas de disponibilidad de seguimiento personalizado: Si decide crear una aplicación personalizada para
ejecutar pruebas de disponibilidad, puede usar el método TrackAvailability() para enviar los resultados a
Puede crear hasta 100 pruebas de disponibilidad por recurso de Application Insights.

Para crear una prueba de disponibilidad, primero deberá crear un recurso de Application Insights. Si ya creó un
recurso, siga con la siguiente sección para crear una prueba de ping de dirección URL.
En Azure Portal, seleccione Crear un recurso > Herramientas para desarrolladores > Application Insights
y cree un recurso de Application Insights.
Creación de una prueba de ping de la dirección URL

El nombre "prueba de ping de dirección URL" es un poco inapropiado. Para que quede claro, esta prueba no usa
ICMP (Protocolo de mensajes de control de Internet) para comprobar la disponibilidad del sitio. En cambio, usa la
funcionalidad más avanzada de solicitud HTTP para validar si un punto de conexión responde. También mide el
rendimiento asociado con esa respuesta y agrega la capacidad de establecer criterios de éxito personalizados junto
con características más avanzadas, como analizar solicitudes dependientes y permitir reintentos.
Para crear la primera solicitud de disponibilidad, abra el panel Disponibilidad y seleccione Crear prueba .
Creación de una prueba
C O N F IGURA C IÓ N EXP L IC A C IÓ N
URL La dirección URL puede ser cualquier página web que desee
probar, pero debe ser visible desde la red pública de Internet.
La dirección URL puede incluir una cadena de consulta. Así, por
ejemplo, se puede ejercitar un poco la base de datos. Si la
dirección URL se resuelve en una redirección, la seguimos,
hasta 10 redirecciones.
Analizar solicitudes dependientes La prueba solicitará imágenes, scripts, archivos de estilo y

otros archivos que forman parte de la página web en pruebas.
El tiempo de respuesta registrado incluye el tiempo dedicado a
obtener estos archivos. La prueba da error si cualquiera de
estos recursos no se puede descargar correctamente dentro
del tiempo de espera de la prueba entera. Si la opción no está
activada, la prueba solo solicita el archivo en la dirección URL
que especificó. Si se habilita esta opción, se realiza una
comprobación más estricta. Podría producirse un error en la
prueba para los casos que puede que no sean evidentes al
examinar el sitio de forma manual.
Habilitar reintentos cuando la prueba da error, se reintenta tras un corto intervalo.

Se notifica un error únicamente si los tres intentos sucesivos
producen un error. Las sucesivas pruebas se realizan según la
frecuencia habitual de la prueba. El reintento se suspende
temporalmente hasta que uno se complete correctamente.
Esta regla se aplica independientemente en cada ubicación de
la prueba. Se recomienda esta opción . Como media, cerca
del 80 % de los errores desaparecen al reintentar.
Frecuencia de prueba establece la frecuencia con que se ejecuta la prueba desde

cada ubicación de prueba. Con una frecuencia predeterminada
de cinco minutos y cinco ubicaciones de prueba, el sitio se
prueba, de media, cada minuto.
Ubicaciones de prueba Son los lugares desde donde nuestros servidores envían
solicitudes web a la dirección URL. El número mínimo de
ubicaciones de prueba recomendadas es cinco con el fin
de asegurarse de que puede distinguir los problemas del sitio
web de los problemas de la red. Puede seleccionar hasta 16
ubicaciones.
Si la dirección URL no es visible desde la red Internet pública, tiene la opción de abrir selectivamente
el firewall para permitir solo las transacciones de prueba . Para más información sobre las excepciones de
firewall para nuestros agentes de prueba de disponibilidad, consulte la guía de direcciones IP.
NOTE
Se recomienda probar desde varias ubicaciones con un mínimo de cinco ubicaciones . Esto es para evitar falsas alarmas
que pueden deberse a problemas transitorios con una ubicación específica. Además, hemos descubierto que la configuración
óptima es que el número de ubicaciones de prueba sea igual que el umbral de ubicación de la aler ta + 2 .
Criterios de éxito
Tiempo de espera de prueba reduzca este valor para recibir una alerta sobre las respuestas
lentas. La prueba se considera un error si no se han recibido
respuestas de su sitio dentro de este período. Si seleccionó
Analizar solicitudes dependientes , todas las imágenes,
archivos de estilo, scripts y otros recursos dependientes se
deben haber recibido durante este período.
Respuesta HTTP el código de estado devuelto que se considera correcto. 200 es

el código que indica que se ha devuelto una página web
normal.
Coincidencia de contenido Una cadena, como "Bienvenido". Probamos que se produce

una coincidencia exacta entre mayúsculas y minúsculas en
todas las respuestas. Debe ser una cadena sin formato, sin
caracteres comodín. No se olvide de que si el contenido
cambia, es posible que tenga que actualizarla. En la
coincidencia de contenido solo se admiten caracteres
en inglés
Alertas
Casi en tiempo real (versión preliminar) Se recomienda usar alertas casi en tiempo real. La
configuración de este tipo de alertas se realiza después de
crear la prueba de disponibilidad.
Clásico Ya no se recomienda usar alertas clásicas para nuevas pruebas

de disponibilidad.
Umbral de la ubicación de la aler ta se recomienda un mínimo de 3/5 ubicaciones. La relación

óptima entre el umbral de ubicación de la alerta y el número
de ubicaciones de prueba es umbral de ubicación de la
aler ta = número de ubicaciones de prueba - 2, con un
mínimo de cinco ubicaciones de prueba.
Visualización de los resultados de las pruebas de disponibilidad

Los resultados de la prueba de disponibilidad se pueden visualizar con vistas de línea o vistas de trazado de
dispersión.
Después de unos minutos, haga clic en Actualizar para ver los resultados.
En la vista de dispersión se muestran ejemplos de los resultados de las pruebas, que incluyen detalles sobre los
pasos de las pruebas de diagnóstico. El motor de pruebas almacena los detalles de diagnóstico de las pruebas con
errores. En el caso de las pruebas correctas, los detalles de diagnóstico se almacenan para un subconjunto de las
ejecuciones. Mantenga el mouse sobre cualquiera de los puntos rojos o verdes para ver la prueba, el nombre de
esta y su ubicación.
Seleccione una prueba o una ubicación determinadas, o bien reduzca el período de tiempo para ver más resultados
del período de tiempo que le interese. Use el Explorador de búsqueda para ver los resultados de todas las
ejecuciones, o use consultas de Analytics para ejecutar informes personalizados en estos datos.
Inspección y edición de pruebas

Para editar, eliminar o deshabilitar temporalmente una prueba, haga clic en el botón de puntos suspensivos junto al
nombre de la prueba. Pueden tardar hasta 20 minutos para que los cambios se propaguen a todos los agentes de
prueba después de realizar un cambio.
Tal vez le interese deshabilitar las pruebas de disponibilidad o las reglas de alerta asociadas a ellas mientras esté
realizando el mantenimiento del servicio.
Si ve errores
Haga clic en un punto rojo.
Puede ver los detalles de transacción en todos los componentes desde el resultado de la prueba de disponibilidad.
Aquí puede:
Inspeccionar la respuesta recibida desde el servidor.
Diagnosticar errores con la telemetría de lado servidor correlacionada que se recopiló durante el procesamiento
de la prueba de disponibilidad con error.
Registrar un problema o elemento de trabajo en GIT o Azure Boards para realizar un seguimiento del problema.
El error contiene un vínculo a este evento.
Abra el resultado de la prueba web en Visual Studio.
Obtenga más información acerca de la experiencia de diagnósticos de transacción extremo a extremo aquí.
Haga clic en la fila de excepciones para ver los detalles de la excepción del lado servidor que ha provocado un error
en la prueba de disponibilidad sintética. También puede obtener la instantánea de depuración para realizar
diagnósticos de nivel de código más completos.
Además de los resultados sin formato, también puede ver dos métricas de disponibilidad clave en el Explorador de
métricas:
1. Disponibilidad: Porcentaje de las pruebas que obtuvieron resultados satisfactorios en todas las ejecuciones de
prueba.
2. Duración de la prueba: Duración media de las pruebas en todas las ejecuciones de prueba.
Automation
Use scripts de PowerShell para configurar una prueba de disponibilidad automáticamente.
Configure un webhook que se llama cuando se genera una alerta.
Artículo de solución de problemas dedicado.
Pasos siguientes
Pruebas web de varios pasos
Alertas de métricas con umbrales dinámicos en
Azure Monitor
La alerta de métricas con detección de umbrales dinámicos aprovecha el aprendizaje automático avanzado para
obtener información acerca del comportamiento histórico de las métricas e identificar patrones y anomalías
que indican problemas posibles para los servicios. Proporciona soporte técnico tanto de una interfaz de usuario
simple como de operaciones a escala, ya que permite a los usuarios configurar reglas de alerta a través de la
API de Azure Resource Manager de forma totalmente automática.
Una vez que se cree una regla de alerta, solo se activará solo cuando la métrica supervisada no se comporte
según lo previsto, en función de sus umbrales personalizados.
Agradecemos sus comentarios, así que puede enviarlos a azurealertsfeedback@microsoft.com.
¿Por qué y cuándo se recomienda el uso de un tipo de condición

dinámica?
1. Aler tas escalables : las reglas de alertas de umbral dinámico pueden crear umbrales a medida para
cientos de series de métricas a la vez con la misma facilidad de definición que si se tratara de una regla
de alertas para una sola métrica. Le proporcionan menos alertas para crear y administrar. Puede usar
Azure Portal o la API de Azure Resource Manager para crearlas. El enfoque escalable es especialmente
útil cuando se trabaja con dimensiones de métricas o cuando se aplican a varios recursos como, por
ejemplo, a todos los recursos de la suscripción. Obtenga más información acerca de cómo configurar
alertas de métricas con umbrales dinámicos mediante plantillas.
2. Reconocimiento de patrones de métricas inteligentes : mediante la tecnología Machine Learning
podemos detectar automáticamente patrones de métricas y adaptarlos a los cambios que se producen en
las métricas con el tiempo, lo que a menudo puede incluir estacionalidad (cada hora, cada día o cada
semana). La adaptación al comportamiento de las métricas con el paso del tiempo y la generación de
alertas en función de las desviaciones de su patrón permite que no sea imprescindible conocer el umbral
"correcto" de cada métrica. El algoritmo de Machine Learning que se usa en umbrales dinámicos está
diseñado para evitar umbrales con ruido (poca precisión) o amplios (poco recuerdo) que no tengan un
patrón esperado.
3. Configuración intuitiva : los umbrales dinámicos permiten configurar alertas de métricas mediante
conceptos de alto nivel, lo que mitiga la necesidad de poseer un amplio conocimiento acerca de la
métrica.
¿Cómo se configuran reglas de alertas con umbrales dinámicos?

Las alertas con umbrales dinámicos pueden configurarse a través de alertas de métricas en Azure Monitor. Más
información acerca de cómo configurar alertas de métricas.
¿Cómo se calculan los umbrales?

Los umbrales dinámicos aprenden continuamente los datos de las series de métricas e intentan modelarlos
mediante un conjunto de algoritmos y métodos. Detecta en los datos patrones como la estacionalidad (cada
hora, cada día o cada semana) y puede controlar métricas con ruido (como la memoria o la CPU del equipo), así
como las métricas con poca dispersión (como la disponibilidad y la tasa de error).
Los umbrales se seleccionan de forma que una desviación de estos umbrales indica una anomalía en el
comportamiento de la métrica.
NOTE
La detección de patrones estacionales se establece en un intervalo de hora, día o semana. Esto significa que otros
patrones, como el patrón cada dos horas o dos veces por semana, podrían no detectarse.
¿Qué significa el valor "Sensibilidad" en los umbrales dinámicos?

La sensibilidad del umbral de alerta es un concepto de alto nivel que controla la cantidad de desviación del
comportamiento de la métrica necesaria para desencadenar una alerta. Esta opción no requiere conocimiento
acerca del umbral estático similar a una métrica. Las opciones disponibles son:
Alto: los umbrales serán estrictos y estarán próximos al patrón de la serie de métricas. Una regla de alertas
se desencadenará ante la mínima desviación, lo que generará más alertas.
Mediano: umbrales menos estrechos y más equilibrados, menos alertas que con la sensibilidad alta (valor
predeterminado).
Bajo: los umbrales serán laxos y habrá más distancia desde el patrón de la serie de métricas. Una regla de
alertas se desencadenará solo ante desviaciones más grandes, lo que generará menos alertas.
¿Cuáles son las opciones de configuración de "Operador" en los

umbrales dinámicos?
La regla de alertas de los umbrales dinámicos puede crear umbrales personalizados en función del
comportamiento de las métricas en los límites superior e inferior de uso de la misma regla de alerta. Puede
elegir que la alerta que se va a desencadenar en una de las tres condiciones siguientes:
Mayor que el umbral superior o menor que el umbral inferior (valor predeterminado)
Mayor que el umbral superior
Menor que el umbral inferior
¿Qué significa la configuración avanzada de los umbrales dinámicos?

Períodos de error : los umbrales dinámicos también permiten configurar el número de infracciones necesarias
para que se desencadene la alerta, que es el número mínimo de desviaciones requeridas en un período
concreto para que el sistema genere una alerta (el valor predeterminado es cuatro desviaciones en 20 minutos).
El usuario puede configurar los períodos de error y elegir los motivos por los que va a recibir alertas. Para ello
solo debe cambiar los períodos de error y el período de tiempo. Esta capacidad reduce el ruido de las alertas
que generan los picos transitorios. Por ejemplo:
Para desencadenar una alerta cuando el problema es continuo durante 20 minutos, 4 veces consecutivas en un
período dado de 5 minutos, utilice la siguiente configuración:
Para desencadenar una alerta cuando se ha producido una infracción de un umbral dinámico en 20 minutos de
los últimos 30 con un período de 5 minutos, utilice la siguiente configuración:
Omitir los datos anteriores a : los usuarios también tienen la opción de definir la fecha a partir de la que el
sistema debe comenzar a calcular los umbrales. Un caso de uso típico puede producirse cuando un recurso se
ejecutaba en modo de prueba y ahora se ha promocionado a servir una carga de trabajo de producción y, por lo
tanto, no debe tenerse en cuenta el comportamiento de las métrica durante la fase de pruebas.
¿Cómo averiguar por qué se ha desencadenado una alerta de

umbrales dinámicos?
Puede explorar las instancias de alerta desencadenadas en la vista de alertas, haciendo clic en el vínculo en el
correo electrónico o mensaje de texto, o en el explorador para mostrar la vista de alertas en Azure Portal. Más
información sobre la vista de alertas.
La vista de alertas muestra:
Todos los detalles de la métrica en el momento en que se desencadena la alerta de umbrales dinámicos.
Un gráfico del período en el que se desencadenó la alerta, que incluye los umbrales dinámicos usados en ese
momento dado.
La capacidad de proporcionar comentarios sobre la experiencia de alertas de umbrales dinámicos y la vista
de alertas, lo que podría mejorar futuras detecciones.
¿Se desencadenará una alerta con el lento cambio de

comportamiento de una métrica?
Probablemente no. Los umbrales dinámicos son buenos para detectar desviaciones importantes, en lugar de
problemas de evolución lenta.
¿Cuántos datos se usan para obtener una vista previa y, después,

calcular los umbrales?
La primera vez que se crea una alerta, los umbrales que aparecen en el gráfico se calculan utilizando datos
históricos, que deben ser suficientes para poder calcular patrones estacionales por hora o día (10 días). Una vez
creada una regla de alertas, los umbrales dinámicos usarán todos los datos históricos necesarios que estén
disponibles y aprenderán y se adaptarán continuamente según los datos nuevos para que los umbrales sean
cada vez más precisos. Esto significa que, después de este cálculo, el gráfico también mostrará los patrones
semanales.
¿Cuántos datos se necesitan para desencadenar una alerta?

Si tiene un nuevo recurso o faltan datos de las métricas, los umbrales dinámicos no desencadenarán alertas
antes de que haya disponibles tres días o al menos 30 ejemplos de datos de métrica, para así poder garantizar
que los umbrales son precisos. En el caso de los recursos existentes con datos de métrica suficientes, los
umbrales dinámicos pueden desencadenar alertas inmediatamente.
Procedimientos recomendados para umbrales dinámicos

Los umbrales dinámicos se puede aplicar a cualquier plataforma o métrica personalizada de Azure Monitor y
también se ha optimizado para las métricas comunes de aplicaciones y de infraestructura. Los elementos
siguientes son procedimientos recomendados sobre cómo configurar alertas en algunas de estas métricas con
umbrales dinámicos.
Umbrales dinámicos en las métricas de porcentaje de CPU de máquina virtual
1. En Azure Portal, haga clic en Monitor . La vista Monitor consolida todas las opciones de configuración y
todos los datos de supervisión en una vista.
TIP
La mayoría de las hojas de recursos también tienen la opción Aler tas en el menú de recursos de la sección
Super visión , de modo que también podría crear alertas desde allí.
3. Haga clic en Seleccionar destino , en el panel de contexto que se carga, y seleccione un recurso de
destino sobre el que quiera alertar. Use los menús desplegables Suscripción y Tipo de recurso
"Máquinas vir tuales" para buscar el recurso que quiere supervisar. También puede utilizar la barra de
5. Seleccione "Porcentaje de CPU" .
6. De manera opcional, puede restringir la métrica ajustando Período y Agregación . No se recomienda
usar el tipo de agregación "máxima" para este tipo de métrica ya que es menos representativo del
comportamiento. Para el tipo de agregación "máxima", el umbral estático puede ser más adecuado.
7. Verá un gráfico para la métrica de las últimas 6 horas. Defina los parámetros de la alerta:
a. Tipo de condición : elija la opción "Dinámico".
b. Sensibilidad : elija una sensibilidad media o baja para reducir el ruido de las alertas.
c. Operador : elija "mayor que" excepto si el comportamiento representa el uso de la aplicación.
d. Frecuencia : considere la posibilidad de reducirla según el impacto empresarial de la alerta.
e. Períodos de error (Opción avanzada) la ventana temporal debe ser al menos de 15 minutos. Por
ejemplo, si se establece el período en cinco minutos, los períodos de error deben ser tres como
mínimo.
8. El gráfico de métricas mostrará los umbrales calculados según los datos recientes.
10. Rellene los Detalles de aler tas como Nombre de la regla de aler tas , Descripción y Gravedad .
11. Agregue un grupo de acciones a la alerta, ya sea seleccionando un grupo de acciones existente o creando
uno nuevo.
NOTE
Las reglas de alertas de métricas creadas mediante el portal se crean en el mismo grupo de recursos que el recurso de
destino.
Umbrales dinámicos en el tiempo de ejecución de solicitudes HTTP de Application Insights

1. En Azure Portal, haga clic en Monitor . La vista Monitor consolida todas las opciones de configuración y
todos los datos de supervisión en una vista.
TIP
La mayoría de las hojas de recursos también tienen la opción Aler tas en el menú de recursos de la sección
Super visión , de modo que también podría crear alertas desde allí.
3. Haga clic en Seleccionar destino , en el panel de contexto que se carga, y seleccione un recurso de
destino sobre el que quiera alertar. Use los menús desplegables Suscripción y Tipo de recurso
"Application Insights" para buscar el recurso que quiere supervisar. También puede utilizar la barra de
5. Seleccione la opción "Tiempo de ejecución de solicitud HTTP" .
6. De manera opcional, puede restringir la métrica ajustando Período y Agregación . No se recomienda
usar el tipo de agregación "máxima" para este tipo de métrica ya que es menos representativo del
comportamiento. Para el tipo de agregación "máxima", el umbral estático puede ser más adecuado.
7. Verá un gráfico para la métrica de las últimas 6 horas. Defina los parámetros de la alerta:
a. Tipo de condición : elija la opción "Dinámico".
b. Operador : elija "mayor que" para reducir el número de alertas que se desencadenan con una mejora
de la duración.
c. Frecuencia : considere la posibilidad de reducirla según el impacto empresarial de la alerta.
8. El gráfico de métricas mostrará los umbrales calculados según los datos recientes.
10. Rellene los Detalles de aler tas como Nombre de la regla de aler tas , Descripción y Gravedad .
11. Agregue un grupo de acciones a la alerta, ya sea seleccionando un grupo de acciones existente o creando
uno nuevo.
NOTE
Las reglas de alertas de métricas creadas mediante el portal se crean en el mismo grupo de recursos que el recurso de
destino.
Interpretación de gráficos de umbrales dinámicos

A continuación aparece un gráfico que muestra una métrica, sus límites de umbrales dinámicos y algunas
alertas que se desencadenan cuando el valor se sitúa fuera de los umbrales permitidos.
Utilice la siguiente información para interpretar el gráfico anterior.
Línea azul : la métrica medida real a lo largo del tiempo.
Área azul sombreada : muestra el intervalo permitido para la métrica. Siempre que los valores de la
métrica permanezcan dentro de este intervalo, no se producirá ninguna alerta.
Puntos azules : si hace clic en cualquier parte del gráfico y, a continuación, mantiene el mouse sobre la línea
azul, verá un punto azul debajo del cursor que muestra un valor de métrica agregado individual.
Elemento emergente con un punto azul : muestra el valor de la métrica medida (el punto azul) y los
valores superior e inferior del intervalo permitido.
Punto rojo con un círculo negro : muestra el primer valor de la métrica fuera del intervalo permitido. Este
es el valor que activa una alerta de métrica y la pone en estado activo.
Puntos rojos : indican valores medidos adicionales fuera del intervalo permitido. No activarán alertas de
métricas adicionales, pero la alerta permanecerá activa.
Área roja : muestra la hora en que el valor de la métrica estaba fuera del intervalo permitido. La alerta
permanecerá en estado activo siempre que los valores medidos posteriores estén fuera del intervalo
permitido, pero no se activarán nuevas alertas.
Final del área roja : cuando la línea azul vuelve dentro de los valores permitidos, el área roja se detiene y la
línea del valor medido se vuelve azul. El estado de la alerta de la métrica desencadenada en el momento que
indica el punto rojo con el contorno negro se establece en resuelto.
Supervisión de varias series temporales en una sola
regla de alerta de métrica
Es posible utilizar una sola regla de alerta de métrica para supervisar una o varias series temporales de métricas, de
modo que la supervisión de los recursos a escala resulte más sencilla.
Serie temporal de métricas

Una serie temporal de métricas es una serie de medidas (o "valores de métricas") capturadas durante un período
de tiempo.
Por ejemplo:
El uso de CPU de una máquina virtual.
Los bytes entrantes (entrada) a una cuenta de almacenamiento.
El número de solicitudes con error de una aplicación web
Regla de alerta en una sola serie temporal

Una regla de alerta supervisa una sola serie temporal cuando cumple todas las condiciones siguientes:
La regla supervisa un único recurso de destino.
Contiene una única condición.
Evalúa una métrica sin elegir las dimensiones (suponiendo que la métrica admita dimensiones).
Un ejemplo de este tipo de regla de alerta (mostrando solo las propiedades pertinentes):
Recurso de destino: myVM1
Métrica: Porcentaje de la CPU
Operador: Mayor que
Umbral: 70
En esta regla de alerta, se supervisa una sola serie temporal de métricas:
Porcentaje de CPU donde Recurso="myVM1" > 70 %
Regla de alerta en varias series temporales
Una regla de alerta supervisa varias series temporales si usa al menos una de las siguientes características:
Varios recursos
Varias condiciones
Varias dimensiones
Varios recursos
Una sola regla de alerta de métrica puede supervisar varios recursos, siempre que los recursos sean del mismo
tipo y existan en la misma región de Azure. El uso de este tipo de regla reduce la complejidad y el número total de
reglas de alerta que se deben mantener.
Un ejemplo de este tipo de regla de alerta:
Recurso de destino: myVM1, myVM2
Operador: Mayor que
Umbral: 70
En esta regla de alerta, dos series temporales de métricas se supervisan por separado:
En una regla de alerta de varios recursos, la condición se evalúa por separado para cada uno de los recursos (o,
con más precisión, para cada una de las series temporales de métricas que corresponden a cada recurso). Esto
significa que las alertas también se activan para cada recurso por separado.
Por ejemplo, supongamos que hemos establecido la regla de alerta anterior para supervisar la CPU por encima del
70 %. En el período de tiempo evaluado (es decir, los últimos 5 minutos):
El porcentaje de CPU de myVM1 es superior al 70 %.
El porcentaje de CPU de myVM2 es del 50 %.
La regla de alerta se desencadena en myVM1, pero no en myVM2. Estas alertas desencadenadas son
independientes. También pueden resolverse en momentos diferentes según el comportamiento individual de cada
una de las máquinas virtuales.
Para obtener más información sobre las reglas de alertas de varios recursos y los tipos de recursos compatibles
con esta funcionalidad, consulte Supervisión a escala mediante alertas de métricas en Azure Monitor.
NOTE
Varias condiciones
Una sola regla de alertas de métrica también puede supervisar hasta cinco condiciones por regla de alerta.
Por ejemplo:
Recurso de destino: myVM1
Condition1
Operador: Mayor que
Umbral: 70
Condición2
Métrica: Red entrante total
Operador: Mayor que
Umbral: 20 MB
Para esta regla de alerta, se están supervisando dos series temporales de métricas:
Red entrante total donde Recurso="myVM1" > 20 MB
Se usa un operador "AND" entre las condiciones. La regla de alerta activa una alerta cuando se cumplen todas las
condiciones. La alerta desencadenada se resuelve si ya no se cumple al menos una de las condiciones.
NOTE
Existen restricciones al usar dimensiones en una regla de alerta con varias condiciones. Para obtener más información,
consulte Restricciones al usar dimensiones en una regla de alertas de métricas con varias condiciones.
Varias dimensiones
Una sola regla de alerta de métrica también puede supervisar varios valores de dimensión de una métrica. Las
dimensiones de una métrica son pares nombre-valor que transportan datos adicionales para describir el valor de la
métrica. Por ejemplo, la métrica Transacciones de una cuenta de almacenamiento tiene una dimensión
denominada Nombre de API que describe el nombre de la API a la que llama cada transacción (por ejemplo,
GetBlob, DeleteBlob, PutPage). El uso de dimensiones es opcional, pero permite filtrar la métrica y supervisar solo
series temporales específicas, en lugar de supervisar la métrica como un agregado de todos los valores de
dimensión colocados juntos.
Por ejemplo, puede elegir que se desencadene una alerta cuando el número de transacciones sea elevado en todos
los nombres de API (que son los datos agregados) o bien dividirla para que se produzca una alerta solo cuando el
número de transacciones sea elevado para los nombres de API específicos.
Ejemplo de una regla de alerta que supervisa varias dimensiones:
Recurso de destino: myStorage1
Métrica: Transactions
Dimensions
Nombre de API = GetBlob, DeleteBlob, PutPage
Operador: Mayor que
Umbral: 70
Para esta regla de alerta, se están supervisando tres series temporales de métricas:
Transacciones donde Recurso="myStorage1" y Nombre de la API="GetBlob" > 70
Transacciones donde Recurso="myStorage1" y Nombre de la API="DeleteBlob" > 70
Transacciones donde Recurso="myStorage1" y Nombre de la API="PutPage" > 70
Una regla de alertas de métricas de varias dimensiones también puede supervisar varios valores de dimensión de
diferentes dimensiones de una métrica. En este caso, la regla de alerta supervisa de forma independiente todas
las combinaciones de valores de dimensión de la selección.
Ejemplo de este tipo de alerta:
Recurso de destino: myStorage1
Métrica: Transactions
Dimensions
Nombre de API = GetBlob, DeleteBlob, PutPage
Autenticación = SAS, AccountKey
Operador: Mayor que
Umbral: 70
En esta regla de alerta, seis series temporales de métricas se supervisan por separado:
Transacciones donde Recurso="myStorage1", Nombre de la API="GetBlob"y Autenticación="SAS" > 70
Transacciones donde Recurso="myStorage1", Nombre de la API="GetBlob" y Autenticación="AccountKey" > 70
Transacciones donde Recurso="myStorage1", Nombre de la API="DeleteBlob"y Autenticación="SAS" > 70
Transacciones donde Recurso="myStorage1", Nombre de la API="DeleteBlob" y Autenticación="AccountKey" >
70
Transacciones donde Recurso="myStorage1", Nombre de la API="PutPage" y Autenticación="SAS" > 70
Transacciones donde Recurso="myStorage1", Nombre de la API="PutPage" y Autenticación="AccountKey" > 70
Características avanzadas de varias dimensiones

1. Seleccionar todas las dimensiones actuales y futuras : puede optar por supervisar todos los valores
posibles de una dimensión, incluidos los valores futuros. Este tipo de regla de alerta se escalará
automáticamente para supervisar todos los valores de la dimensión sin necesidad de modificar la regla de
alerta cada vez que se agregue o se quite un valor de dimensión.
2. Excluir dimensiones : la selección del operador "" (excluir) para un valor de dimensión equivale a seleccionar
todos los demás valores de esa dimensión, incluidos los valores futuros.
3. Dimensiones nuevas y personalizadas : los valores de dimensión que se muestran en Azure Portal se basan
en los datos de métrica recopilados en los últimos tres días. Si aún no se ha emitido el valor de dimensión que
está buscando, puede agregar un valor de dimensión personalizada.
Precios de alertas de métricas
Los precios de las reglas de alertas de métricas están disponibles en la página de precios de Azure Monitor.
Al crear una regla de alertas de métrica, la estimación de precios proporcionada se basa en las características
seleccionadas y el número de series temporales supervisadas, que se determina a partir de la configuración de
reglas y los valores de métricas actuales. Sin embargo, el cargo mensual se basa en las evaluaciones reales de la
serie temporal y, por tanto, puede diferir de la estimación original si alguna serie temporal no tiene datos para
evaluar, o si la regla de alerta utiliza características que pueden hacer que se escale dinámicamente.
Por ejemplo, una regla de alerta puede mostrar una estimación de precios elevada si aprovecha la característica de
varias dimensiones y hay un gran número de combinaciones de valores de dimensión seleccionados, lo que da
lugar a la supervisión de muchas series temporales. Sin embargo, el cargo real de esa regla de alerta puede ser
menor si no todas las series temporales resultantes de las combinaciones de valores de dimensión tienen
realmente datos para evaluar.
Pasos siguientes
Obtenga más información sobre la supervisión a escala mediante alertas de métricas y umbrales dinámicos.
Creación de alertas de métricas para registros en
Azure Monitor
NOTE
Azure Monitor admite el tipo de alertas de métricas, que tiene ventajas sobre las alertas clásicas. Las métricas
están disponibles para una amplia lista de servicios de Azure. En este artículo se explica el uso de un subconjunto
(es decir) para el recurso Microsoft.OperationalInsights/workspaces .
También puede utilizar las alertas de métricas en los registros populares de Log Analytics extraídos como
métricas como parte de las métricas de los registros, incluidos recursos en Azure o en la instancia local. A
continuación se enumeran las soluciones de Log Analytics admitidas:
Contadores de rendimiento para equipos con Windows y Linux
Registros de latidos para Agent Health
Registros de administración de actualizaciones
Datos de registros de eventos
Hay muchas ventajas al usar aler tas de métricas para registros a través de alertas de registro basadas en
consultas en Azure; a continuación se enumeran algunas de ellas:
Las alertas de métricas ofrecen la funcionalidad de supervisión casi en tiempo real, y las alertas de métricas
para registros bifurcan los datos a partir del origen de registro para garantizar lo mismo.
Las alertas de métricas tienen estado, solo se notifican una vez cuando se desencadena la alerta y una vez
cuando se resuelva la alerta; a diferencia de las alertas de registro, que no tienen estado y siguen
notificándose en cada intervalo si se cumple la condición de alerta.
Las alertas de métricas para registros proporcionan varias dimensiones, lo que permite filtrar valores
específicos, como equipos, tipo de sistema operativo, etc., de manera más sencilla, sin la necesidad de
componer una consulta en el análisis.
NOTE
La métrica o dimensión específicas solo se mostrarán si los datos de ellas existen durante el período elegido. Estas métricas
están disponibles para los clientes con áreas de trabajo de Azure Log Analytics.
Métricas y dimensiones compatibles para registros

Las alertas de métricas admiten alertas de métricas que utilizan dimensiones. Puede usar dimensiones para
filtrar las métricas al nivel adecuado. Se incluye la lista completa de métricas admitidas para los registros de
áreas de trabajo de Log Analytics; a través de las soluciones compatibles.
NOTE
Para ver una métrica admitida extraída de un área de trabajo de Log Analytics a través de Azure Monitor: Métricas, debe
crearse una alerta de métrica para el registro en la métrica específica. Las dimensiones elegidas en la alerta de métrica para
registros solo aparecerán para la exploración a través de Azure Monitor: Métricas.
Creación de alertas de métricas para Log Analytics

Los datos de métricas de registros populares se canalizan antes de procesarse en Log Analytics, en Azure
Monitor: Métrica. Esto permite a los usuarios aprovechar las funcionalidades de la plataforma de métricas, así
como la alerta de métrica: incluso tener alertas con una frecuencia de apenas 1 minuto. A continuación aparecen
los medios para crear una alerta de métrica para registros.
Requisitos previos para alertas de métricas para registros

Antes de que funcione la métrica para registros recopilada en los datos de Log Analytics, debe configurarse lo
siguiente y estar disponible:
1. Área de trabajo de Log Analytics activa : debe haber un área de trabajo de Log Analytics activa y válida.
Para obtener más información, consulte Creación de un área de trabajo de Log Analytics en Azure Portal.
2. Agente configurado para el área de trabajo de Log Analytics : el agente debe configurarse para que
las máquinas virtuales de Azure o las máquinas virtuales locales envíen datos al área de trabajo de Log
Analytics usada en el paso anterior. Para obtener más información, consulte Log Analytics - Agent Overview
(Log Analytics: Introducción al agente).
3. Soluciones de Log Analytics admitidas instaladas : la solución de Log Analytics debe estar configurada y
enviar datos al área de trabajo de Log Analytics; las soluciones admitidas son Contadores de rendimiento
para Windows y Linux, Registros de latidos para Agent Health, Administración de actualizaciones y Datos de
eventos.
4. Soluciones de Log Analytics configuradas para enviar registros : la solución de Log Analytics debe
tener los datos o registros que corresponden a las métricas admitidas para las áreas de trabajo de Log
Analytics habilitadas. Por ejemplo, para el contador % de memoria disponible, debe configurarse primero en
la solución Contadores de rendimiento.
Configuración de alertas de métricas para registros

Las alertas de métricas se pueden crear y administrar mediante Azure Portal, plantillas de Resource Manager, la
API REST, PowerShell y la CLI de Azure. Dado que las alertas de métricas para registros es una variante de alertas
de métricas: una vez que se cumplan los requisitos previos, se puede crear una alerta de métrica para registros
para el área de trabajo de Log Analytics especificada. Todas las características y funcionalidades de alertas de
métricas se aplicarán a las alertas de métricas para registros, incluido el esquema de carga, los límites de cuota
aplicables y el precio facturado.
Para obtener instrucciones paso a paso y ejemplos, consulte creación y administración de alertas de métricas. En
concreto, para las alertas de métricas de registros, siga las instrucciones para administrar las alertas de métricas
y asegúrese de lo siguiente:
El destino para la alerta de métrica es un área de trabajo de Log Analytics válida.
La señal elegida para la alerta de métrica para el área de trabajo de Log Analytics seleccionada es del tipo
Métrica .
Filtrar por condiciones o recurso específicos mediante filtros de dimensión; las métricas para registros son
multidimensionales.
Al configurar la lógica de señal, se puede crear una sola alerta para abarcar varios valores de dimensión (por
ejemplo, equipo).
Si no usa Azure Portal para crear la alerta de métrica para el área de trabajo de Log Analytics seleccionada, el
usuario debe crear primero manualmente una regla explícita para convertir los datos de registro en una
métrica mediante Azure Monitor: Scheduled Query Rules (Azure Monitor: Reglas de consulta programadas).
NOTE
Al crear la alerta de métrica para el área de trabajo de Log Analytics mediante Azure Portal, la regla correspondiente para
convertir datos de registro en la métrica a través de Azure Monitor: Scheduled Query Rules se crea automáticamente en
segundo plano, sin necesidad de ninguna intervención o acción del usuario. Para la creación de alertas de métricas para
registros a través de medios distintos de Azure Portal, consulte la sección Plantilla de recursos para las alertas de métricas
de registros por medios de ejemplo para crear una regla de conversión de registro a métrica basada en
ScheduledQueryRule antes de la creación de la alerta de métrica o, de lo contrario, no habrá datos para la alerta de
métrica en los registros creados.
Plantilla de recursos para las alertas de métricas de registros

Como se indicó anteriormente, el proceso de creación de alertas de métricas para registros tiene dos puntas:
1. Crear una regla para extraer las métricas de los registros admitidos mediante la API scheduledQueryRule
2. Crear una alerta de métrica para la métrica extraída del registro (en el paso 1) y el área de trabajo de Log
Analytics como recurso de destino
Alertas de métricas para los registros de umbral estático
Para lograr el mismo, se puede utilizar el ejemplo de la plantilla de Azure Resource Manager a continuación,
cuando la creación de la alerta de métrica de umbral estático dependa de la creación correcta de la regla para
extraer las métricas de los registros a través de scheduledQueryRule.
{
"parameters": {
"convertRuleName": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the rule to convert log to metric"
}
},
"convertRuleDescription": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Description for log converted to metric"
}
},
"convertRuleRegion": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the region used by workspace"
}
},
"convertRuleStatus": {
"type": "string",
"defaultValue": "true",
"metadata": {
"description": "Specifies whether the log conversion rule is enabled"
}
},
"convertRuleMetric": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric once extraction done from logs."
}
},
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Full Resource ID of the resource emitting the metric that will be used for
the comparison. For example: /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"metadata": {
"description": "Period of time used to monitor alert activity based on the threshold. Must
be between five minutes and one day. ISO 8601 duration format."
}
},
"type": "string",
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"convertRuleTag": "hidden-link:/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName",
"convertRuleSourceWorkspace": {
"SourceId": "/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"resources": [
{
"name": "[parameters('convertRuleName')]",
"type": "Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[parameters('convertRuleRegion')]",
"tags": {
"[variables('convertRuleTag')]": "Resource"
},
"properties": {
"description": "[parameters('convertRuleDescription')]",
"enabled": "[parameters('convertRuleStatus')]",
"source": {
"dataSourceId": "[variables('convertRuleSourceWorkspace').SourceId]"
},
"action": {
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resour
ces.ScheduledQueryRules.LogToMetricAction",
"criteria": [{
"metricName": "[parameters('convertRuleMetric')]",
"dimensions": []
}
]
}
}
},
{
"apiVersion": "2018-03-01",
"tags": {},
"dependsOn":["
[resourceId('Microsoft.Insights/scheduledQueryRules',parameters('convertRuleName'))]"],
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
Supongamos que el código JSON anterior se guarda como metricfromLogsAlertStatic.json, a continuación,

puede ir acompañado de un archivo JSON de parámetros para la creación basada en la plantilla de recursos. A
continuación se incluye un ejemplo de archivo de JSON de parámetros:
{
"parameters": {
"value": "TestLogtoMetricRule"
},
"value": "Test rule to extract metrics from logs via template"
},
"value": "West Central US"
},
"value": "true"
},
"value": "Average_% Idle Time"
},
"alertName": {
"value": "TestMetricAlertonLog"
},
"value": "New multi-dimensional metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/1234-56789-1234-
567a/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
},
"metricName":{
},
"operator": {
},
"threshold":{
"value": "1"
},
"timeAggregation":{
"value": "Average"
},
"actionGroupId": {
567a/resourceGroups/myRG/providers/microsoft.insights/actionGroups/actionGroupName"
}
}
}
Suponiendo que el archivo de parámetros anterior se guarda como metricfromLogsAlertStatic.parameters.json,

se puede crear la alerta de métrica para registros con la plantilla de recursos para la creación en Azure Portal.
Como alternativa, también se puede usar el siguiente comando de Azure Powershell:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile metricfromLogsAlertStatic.json

TemplateParameterFile metricfromLogsAlertStatic.parameters.json
O bien, implemente la plantilla de recursos con la CLI de Azure:

az group deployment create --resource-group myRG --template-file metricfromLogsAlertStatic.json --parameters
@metricfromLogsAlertStatic.parameters.json
Alertas de métricas para registros con umbrales dinámicos

Para lograr el mismo, se puede utilizar el ejemplo de la plantilla de Azure Resource Manager a continuación,
cuando la creación de la alerta de métrica de umbral dinámico dependa de la creación correcta de la regla para
extraer las métricas de los registros a través de scheduledQueryRule.
{
"parameters": {
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the rule to convert log to metric"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Description for log converted to metric"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the region used by workspace"
}
},
"type": "string",
"defaultValue": "true",
"metadata": {
"description": "Specifies whether the log conversion rule is enabled"
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Name of the metric once extraction done from logs."
}
},
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
the comparison. For example: /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
"description": "Tunes how 'noisy' the Dynamic Thresholds alerts will be: 'High' will result
in more alerts while 'Low' will result in fewer alerts."
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"metadata": {
be between five minutes and one day. ISO 8601 duration format."
}
},
"type": "string",
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"convertRuleTag": "hidden-link:/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName",
"convertRuleSourceWorkspace": {
"SourceId": "/subscriptions/1234-56789-1234-
567a/resourceGroups/resourceGroupName/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
}
},
"resources": [
{
"name": "[parameters('convertRuleName')]",
"type": "Microsoft.Insights/scheduledQueryRules",
"apiVersion": "2018-04-16",
"location": "[parameters('convertRuleRegion')]",
"tags": {
"[variables('convertRuleTag')]": "Resource"
},
"properties": {
"enabled": "[parameters('convertRuleStatus')]",
"source": {
"dataSourceId": "[variables('convertRuleSourceWorkspace').SourceId]"
},
"action": {
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataContracts.Resour
"criteria": [{
"metricName": "[parameters('convertRuleMetric')]",
"dimensions": []
}
]
}
}
},
{
"apiVersion": "2018-03-01",
"tags": {},
"dependsOn":["
[resourceId('Microsoft.Insights/scheduledQueryRules',parameters('convertRuleName'))]"],
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
Supongamos que el código JSON anterior se guarda como metricfromLogsAlertDynamic.json, a continuación,

puede ir acompañado de un archivo JSON de parámetros para la creación basada en la plantilla de recursos. A
continuación se incluye un ejemplo de archivo de JSON de parámetros:
{
"parameters": {
"value": "TestLogtoMetricRule"
},
"value": "Test rule to extract metrics from logs via template"
},
"value": "West Central US"
},
"value": "true"
},
},
"alertName": {
"value": "TestMetricAlertonLog"
},
"value": "New multi-dimensional metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
567a/resourceGroups/myRG/providers/Microsoft.OperationalInsights/workspaces/workspaceName"
},
"metricName":{
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"timeAggregation":{
"value": "Average"
},
"actionGroupId": {
567a/resourceGroups/myRG/providers/microsoft.insights/actionGroups/actionGroupName"
}
}
}
Suponiendo que el archivo de parámetros anterior se guarda como

metricfromLogsAlertDynamic.parameters.json, se puede crear la alerta de métrica para registros con la plantilla
de recursos para la creación en Azure Portal.
Como alternativa, también se puede usar el siguiente comando de Azure Powershell:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile metricfromLogsAlertDynamic.json
TemplateParameterFile metricfromLogsAlertDynamic.parameters.json
O bien, implemente la plantilla de recursos con la CLI de Azure:
az group deployment create --resource-group myRG --template-file metricfromLogsAlertDynamic.json --

parameters @metricfromLogsAlertDynamic.parameters.json
Pasos siguientes
Obtenga más información sobre las alertas de métricas.
Más información sobre las alertas de registro en Azure.
Más información sobre las alertas en Azure.
Creación de una alerta de métrica con una plantilla
de Resource Manager
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.
En este artículo se explica cómo usar una plantilla de Azure Resource Manager para configurar nuevas alertas
de métrica en Azure Monitor. Las plantillas de Resource Manager permiten configurar alertas mediante
programación de una forma coherente y reproducible en todos los entornos. Las alertas de métrica más
recientes están disponibles en este conjunto de tipos de recursos.
IMPORTANT
Plantilla de recursos para la creación de alertas de métricas para el tipo de recurso: El área de trabajo de Azure Log
Analytics (es decir, Microsoft.OperationalInsights/workspaces ) requiere pasos adicionales. Para obtener más
información, consulte el artículo sobre Plantilla de recursos para las alertas de métricas de registros.
Los pasos básicos son los siguientes:

1. Use una de las plantillas siguientes como archivo JSON que describa cómo crear la alerta.
2. Editar y usar el archivo de parámetros correspondiente como archivo JSON para personalizar la alerta.
3. Para el parámetro metricName , consulte las métricas disponibles en Métricas compatibles de Azure Monitor.
4. Implemente la plantilla mediante cualquier método de implementación.
Plantilla para una alerta de métricas de umbral estático simple

Para crear una alerta mediante una plantilla de Resource Manager, cree un recurso de tipo
Microsoft.Insights/metricAlerts y rellene todas las propiedades relacionadas. A continuación se muestra una
plantilla de ejemplo que crea una regla de alertas de métrica.
Para este tutorial, guarde el archivo JSON siguiente como simplestaticmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
the comparison. For example /subscriptions/00000000-0000-0000-0000-0000-
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
be between one minute and one day. ISO 8601 duration format."
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
La explicación del esquemas y las propiedades de una regla de alertas está disponible aquí.
Puede establecer los valores de los parámetros en la línea de comandos o mediante un archivo de parámetros.
A continuación se proporciona un archivo de parámetros de ejemplo.
Guarde el archivo JSON siguiente como simplestaticmetricalert.parameters.json y modifíquelo según sea
necesario.
{
"parameters": {
"alertName": {
"value": "New Metric Alert"
},
"value": "New metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-
resourceGroup-name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "80"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Puede crear la alerta de métrica con la plantilla y el archivo de parámetros mediante PowerShell o la CLI de
Azure.
Uso de Azure PowerShell
Connect-AzAccount
Select-AzSubscription -SubscriptionName <yourSubscriptionName>
New-AzResourceGroupDeployment -Name AlertDeployment -ResourceGroupName ResourceGroupofTargetResource `

-TemplateFile simplestaticmetricalert.json -TemplateParameterFile simplestaticmetricalert.parameters.json
Uso de la CLI de Azure
az login
az group deployment create \

--name AlertDeployment \
--template-file simplestaticmetricalert.json \
--parameters @simplestaticmetricalert.parameters.json
NOTE
Aunque la alerta de métrica se puede crear en un grupo de recursos distinto al recurso de destino, se recomienda usar el
mismo grupo de recursos que el recurso de destino.
Plantilla para una alerta de métricas de umbrales dinámicos simple

Microsoft.Insights/metricAlerts y rellene todas las propiedades relacionadas. A continuación se muestra una
plantilla de ejemplo que crea una regla de alertas de métrica.
Para este tutorial, guarde el archivo JSON siguiente como simpledynamicmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Use this option to set the date from which to start learning the metric
historical data and calculate the dynamic thresholds (in ISO8601 format, e.g. '2019-12-31T22:00:00Z')."
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
be between five minutes and one hour. ISO 8601 duration format."
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
"ignoreDataBefore": "[parameters('ignoreDataBefore')]",
}
]
},
"actions": [
"actions": [
{
}
]
}
}
]
}
Guarde el archivo JSON siguiente como simpledynamicmetricalert.parameters.json y modifíquelo según sea
necesario.
{
"parameters": {
"alertName": {
"value": "New Metric Alert with Dynamic Thresholds"
},
"value": "New metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
resourceGroup-name/providers/Microsoft.Compute/virtualMachines/replace-with-resource-name"
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": ""
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Azure.
Connect-AzAccount

-TemplateFile simpledynamicmetricalert.json -TemplateParameterFile
simpledynamicmetricalert.parameters.json
az login

--template-file simpledynamicmetricalert.json \
--parameters @simpledynamicmetricalert.parameters.json
NOTE
Aunque la alerta de métrica se puede crear en un grupo de recursos distinto al recurso de destino, se recomienda usar el
mismo grupo de recursos que el recurso de destino.
Plantilla para una alerta de métrica de umbral estática que supervisa

varios criterios
Las alertas de métrica más recientes admiten las alertas relacionadas con métricas de varias dimensiones
además de admitir la definición de varios criterios (hasta 5 por regla de alerta). Puede usar la siguiente plantilla
para crear una regla de alerta de métrica más avanzada relacionada con métricas dimensionales y especificar
varios criterios.
Tenga en cuenta las restricciones siguientes cuando use dimensiones en una regla de alerta que contenga
varios criterios:
Cuando las métricas configuradas en distintos criterios admiten la misma dimensión, se debe establecer de
forma explícita un valor de dimensión configurado de la misma manera para todas esas métricas (en los
criterios pertinentes).
En el ejemplo siguiente, como las métricas Transactions y SuccessE2ELatency tienen una
dimensión ApiName , y criterion1 especifica el valor "GetBlob" para la dimensión ApiName ,
criterion2 también debe establecer un valor "GetBlob" para la dimensión ApiName .
Para este tutorial, guarde el archivo JSON siguiente como advancedstaticmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion1":{
"type": "object",
"metadata": {
"description": "Criterion includes metric name, dimension values, threshold and an
operator. The alert rule fires when ALL criteria are met"
}
},
"criterion2": {
"type": "object",
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
"criteria": "[concat(variables('criterion1'),variables('criterion2'))]"
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
},
"actions": [
{
}
]
}
}
]
}
Puede usar la plantilla anterior junto con el archivo de parámetros proporcionado a continuación.
Para este tutorial, guarde y modifique el archivo JSON siguiente como advancedstaticmetricalert.json.
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert (Replace with your alert name)"
},
"value": "New multi-dimensional metric alert created via template (Replace with your alert
description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
resourcegroup-name/providers/Microsoft.Storage/storageAccounts/replace-with-storage-account"
},
"criterion1": {
"value": {
"dimensions": [
{
"values": ["Success"]
},
{
"name":"ApiName",
}
],
"threshold": "5",
}
},
"criterion2": {
"value":{
"name": "2nd criterion",
"metricName": "SuccessE2ELatency",
"dimensions": [
{
"name":"ApiName",
}
],
"threshold": "250",
"timeAggregation": "Average"
}
},
"actionGroupId": {
"value": "/subscriptions/replace-with-subscription-id/resourceGroups/replace-with-resource-
group-name/providers/Microsoft.Insights/actionGroups/replace-with-actiongroup-name"
}
}
}
Azure desde el directorio de trabajo actual.
Connect-AzAccount

-TemplateFile advancedstaticmetricalert.json -TemplateParameterFile
advancedstaticmetricalert.parameters.json
az login

--template-file advancedstaticmetricalert.json \
--parameters @advancedstaticmetricalert.parameters.json
Plantilla para alerta de métrica estática que supervisa varias

dimensiones
Puede usar la siguiente plantilla para crear una regla de alerta de métrica estática relacionada con las métricas
dimensionales.
Una sola regla de alerta puede supervisar varias series temporales de métricas a la vez, por lo que habrá
menos reglas de alerta para administrar.
1. ResponseType : el carácter comodín "*" significa que para cada valor de la dimensión ResponseType ,
incluidos los valores futuros, se supervisa individualmente una serie temporal diferente.
Para este tutorial, guarde el archivo JSON siguiente como multidimensionalstaticmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion":{
"type": "object",
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
},
"actions": [
{
}
]
}
}
]
}
Para este tutorial, guarde y modifique el archivo JSON siguiente como
multidimensionalstaticmetricalert.parameters.json.
{
"parameters": {
"alertName": {
"value": "New multi-dimensional metric alert rule (replace with your alert name)"
},
"value": "New multi-dimensional metric alert rule created via template (replace with your alert
description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
},
"criterion": {
"value": {
"name": "Criterion",
"dimensions": [
{
"values": ["*"]
},
{
"name":"ApiName",
}
],
"threshold": "5",
}
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile multidimensionalstaticmetricalert.json -TemplateParameterFile
multidimensionalstaticmetricalert.parameters.json

az login

--template-file multidimensionalstaticmetricalert.json \
--parameters @multidimensionalstaticmetricalert.parameters.json
Plantilla para una alerta de métrica de umbrales dinámicos que

supervisa varias dimensiones
Puede usar la siguiente plantilla para crear una regla de alerta de métrica de umbrales dinámicos más
avanzada relacionada con las métricas dimensionales.
Una sola regla de alertas de umbrales dinámicos puede crear umbrales personalizados para cientos de series
temporales de métricas (incluso de distintos tipos) a la vez, por lo que habrá menos reglas de alerta para
administrar.
1. ResponseType : para cada valor de la dimensión ResponseType , incluidos los valores futuros, se supervisa
individualmente una serie temporal diferente.
Para este tutorial, guarde el archivo JSON siguiente como advanceddynamicmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"criterion":{
"type": "object",
"metadata": {
operator."
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": {
},
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
},
"actions": [
{
}
]
}
}
]
}
Para este tutorial, guarde y modifique el archivo JSON siguiente como advanceddynamicmetricalert.json.
{
"parameters": {
"alertName": {
"value": "New Multi-dimensional Metric Alert with Dynamic Thresholds (Replace with your alert
name)"
},
"value": "New multi-dimensional metric alert with Dynamic Thresholds created via template
(Replace with your alert description)"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
},
"criterion": {
"value": {
"dimensions": [
{
"values": ["*"]
},
{
"name":"ApiName",
}
],
"operator": "GreaterOrLessThan",
"alertSensitivity": "Medium",
"failingPeriods": {
"numberOfEvaluationPeriods": "4",
"minFailingPeriodsToAlert": "3"
},
}
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile advanceddynamicmetricalert.json -TemplateParameterFile
advanceddynamicmetricalert.parameters.json
az login

--template-file advanceddynamicmetricalert.json \
--parameters @advanceddynamicmetricalert.parameters.json
NOTE
Actualmente no se admiten varios criterios para las reglas de alertas de métricas que usan umbrales dinámicos.
Plantilla para una alerta de métrica de umbral estático que supervisa

una métrica personalizada
Puede usar la siguiente plantilla para crear una regla de alertas de métrica de umbral estático más avanzada
sobre una métrica personalizada.
Para más información sobre las métricas personalizadas en Azure Monitor, consulte Métricas personalizadas en
Azure Monitor.
Al crear una regla de alertas sobre una métrica personalizada, debe especificar tanto el nombre de la métrica
como el espacio de nombres de la métrica. También debe asegurarse de que ya se está notificando la métrica
personalizada, ya que no se puede crear una regla de alertas en una métrica personalizada que todavía no
existe.
Para este tutorial, guarde el archivo JSON siguiente como customstaticmetricalert.json.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"resourceId": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
"description": "Namespace of the metric used in the comparison to activate the alert."
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
"description": "How often the metric alert is evaluated represented in ISO 8601 duration
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
{
"metricNamespace": "[parameters('metricNamespace')]",
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
Para este tutorial, guarde y modifique el archivo JSON siguiente como customstaticmetricalert.parameters.json.
{
"parameters": {
"alertName": {
"value": "New alert rule on a custom metric"
},
"value": "New alert rule on a custom metric created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"resourceId": {
resourceGroup-name/providers/microsoft.insights/components/replace-with-application-insights-resource-name"
},
"metricName": {
"value": "The custom metric name"
},
"value": "Azure.ApplicationInsights"
},
"operator": {
},
"threshold": {
"value": "80"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount
New-AzResourceGroupDeployment -Name AlertDeployment -ResourceGroupName ResourceGroupOfTargetResource `

-TemplateFile customstaticmetricalert.json -TemplateParameterFile customstaticmetricalert.parameters.json
az login

--resource-group ResourceGroupOfTargetResource \
--template-file customstaticmetricalert.json \
--parameters @customstaticmetricalert.parameters.json
NOTE
Para buscar el espacio de nombres de la métrica de una métrica personalizada específica, vaya a las métricas
personalizadas en Azure Portal.
Plantilla para alerta de métrica que supervisa varios recursos

En las secciones anteriores se han descrito las plantillas de Azure Resource Manager de ejemplo para crear
alertas de métricas que supervisan un recurso individual. Azure Monitor admite ahora la supervisión de varios
recursos (del mismo tipo) con una sola regla de alertas de métricas para los recursos de la misma región de
Azure. En este momento, esta característica solo se admite en la nube pública de Azure y para máquinas
virtuales, bases de datos de SQL Server, grupos elásticos de SQL Server y dispositivos Data Box Edge.
Asimismo, solo puede emplearse con métricas de plataforma, y no con métricas personalizadas.
La regla de alertas de los umbrales dinámicos también puede ayudar a crear umbrales personalizados para
cientos de métricas (incluso a distintos tipos) a la vez, lo que reduce el número de reglas de alertas que hay que
administrar.
En esta sección se describen las plantillas de Azure Resource Manager de tres escenarios para supervisar varios
recursos con una sola regla.
Supervisión de todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de recursos.
Supervisión de todas las máquinas virtuales (de una región de Azure) en una suscripción.
Supervisión de una lista de máquinas virtuales (de una región de Azure) en una suscripción.
NOTE
En una regla de alerta de métrica que supervisa varios recursos, se aplican las limitaciones siguientes:
El ámbito de la regla de alerta debe contener al menos un recurso del tipo de recurso seleccionado.
La regla de alerta solo puede contener una condición.
Alerta de umbral estático en todas las máquinas virtuales de uno o varios grupos de recursos
Esta plantilla creará una regla de alerta de métrica de umbral estático que supervise el valor de Porcentaje de
CPU de todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de recursos.
Guarde el archivo JSON siguiente como all-vms-in-resource-group-static.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored
are in. For example - /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
Puede usar la plantilla anterior con el archivo de parámetros siguiente. Guarde y modifique el archivo JSON
siguiente como all-vms-in-resource-group-static.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1",
name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
group-name/providers/Microsoft.Insights/actionGroups/replace-with-action-group-name"
}
}
}
Puede crear la alerta de métrica estática con la plantilla y el archivo de parámetros mediante PowerShell o la
CLI de Azure desde el directorio de trabajo actual.
Connect-AzAccount
New-AzResourceGroupDeployment -Name MultiResourceAlertDeployment -ResourceGroupName

ResourceGroupWhereRuleShouldbeSaved `
-TemplateFile all-vms-in-resource-group-static.json -TemplateParameterFile all-vms-in-resource-group-
static.parameters.json

az login

--name MultiResourceAlertDeployment \
--resource-group ResourceGroupWhereRuleShouldbeSaved \
--template-file all-vms-in-resource-group-static.json \
--parameters @all-vms-in-resource-group-static.parameters.json
Alerta de umbrales dinámicos en todas las máquinas virtuales de uno o varios grupos de recursos
Esta plantilla creará una regla de alertas de la métrica de umbrales dinámicos que supervise el valor de
Porcentaje de CPU de todas las máquinas virtuales (de una región de Azure) en uno o varios grupos de
recursos.
Guarde el archivo JSON siguiente como all-vms-in-resource-group-dynamic.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "Full path of the resource group(s) where target resources to be monitored
are in. For example - /subscriptions/00000000-0000-0000-0000-0000-
00000000/resourceGroups/ResourceGroupName"
}
},
"type": "string",
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
siguiente como all-vms-in-resource-group-dynamic.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds via Azure Resource Manager
template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
name1",
name2"
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile all-vms-in-resource-group-dynamic.json -TemplateParameterFile all-vms-in-resource-group-
dynamic.parameters.json
az login

--template-file all-vms-in-resource-group-dynamic.json \
--parameters @all-vms-in-resource-group-dynamic.parameters.json
Alerta de umbral estático en todas las máquinas virtuales de una suscripción

Esta plantilla creará una regla de alertas de métrica de umbral estático que supervisa el valor de Porcentaje de
CPU de todas las máquinas virtuales (de una región de Azure) en una suscripción.
Guarde el archivo JSON siguiente como all-vms-in-subscription-static.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
},
"type": "string",
"minLength": 1,
"metadata": {
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
siguiente como all-vms-in-subscription-static.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert via Azure Resource Manager template"
},
"value": "New Multi-resource sub level metric alert created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile all-vms-in-subscription-static.json -TemplateParameterFile all-vms-in-subscription-
static.parameters.json

az login

--template-file all-vms-in-subscription-static.json \
--parameters @all-vms-in-subscription.parameters-static.json
Alerta de umbrales dinámicos en todas las máquinas virtuales de una suscripción

Esta plantilla creará una regla de alertas de métrica de umbrales dinámicos que supervisa el valor de
Porcentaje de CPU de todas las máquinas virtuales (de una región de Azure) en una suscripción.
Guarde el archivo JSON siguiente como all-vms-in-subscription-dynamic.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
/subscriptions/00000000-0000-0000-0000-0000-00000000"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
siguiente como all-vms-in-subscription-dynamic.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource sub level metric alert with Dynamic Thresholds via Azure Resource
Manager template"
},
"value": "New Multi-resource sub level metric alert with Dynamic Thresholds created via
template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile all-vms-in-subscription-dynamic.json -TemplateParameterFile all-vms-in-subscription-
dynamic.parameters.json
az login

--template-file all-vms-in-subscription-dynamic.json \
--parameters @all-vms-in-subscription-dynamic.parameter-dynamics.json
Alerta de umbral estático en una lista de máquinas virtuales

Esta plantilla creará una regla de alertas de métrica de umbral estático que supervisa el valor de Porcentaje de
CPU de una lista de máquinas virtuales (de una región de Azure) de una suscripción.
Guarde el archivo JSON siguiente como list-of-vms-static.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-
0000-0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"Equals",
"NotEquals",
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H",
"PT6H",
"PT12H",
"PT24H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"PT1M",
"PT1M",
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
}
]
},
"actions": [
{
}
]
}
}
]
}
siguiente como list-of-vms-static.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert by list via Azure Resource Manager template"
},
"value": "New Multi-resource metric alert by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
]
},
},
},
"metricName": {
},
"operator": {
},
"threshold": {
"value": "0"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile list-of-vms-static.json -TemplateParameterFile list-of-vms-static.parameters.json

az login

--template-file list-of-vms-static.json \
--parameters @list-of-vms-static.parameters.json
Alerta de umbrales dinámicos en una lista de máquinas virtuales

Esta plantilla creará una regla de alertas de métrica de umbrales dinámicos que supervisa el valor de
Porcentaje de CPU de una lista de máquinas virtuales (de una región de Azure) de una suscripción.
Guarde el archivo JSON siguiente como list-of-vms-dynamic.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"alertSeverity": {
"type": "int",
"defaultValue": 3,
"allowedValues": [
0,
1,
2,
3,
4
],
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
}
},
"type": "array",
"minLength": 1,
"metadata": {
"description": "array of Azure resource Ids. For example - /subscriptions/00000000-0000-
0000-0000-0000-00000000/resourceGroup/resource-group-name/Microsoft.compute/virtualMachines/vm-name"
}
},
"type": "string",
"allowedValues": [
"EastUS",
"EastUS2",
"CentralUS",
"NorthCentralUS",
"SouthCentralUS",
"WestCentralUS",
"WestUS",
"WestUS2",
"CanadaEast",
"CanadaCentral",
"BrazilSouth",
"NorthEurope",
"WestEurope",
"FranceCentral",
"FranceSouth",
"UKWest",
"UKSouth",
"GermanyCentral",
"GermanyNortheast",
"GermanyNorth",
"SwitzerlandNorth",
"SwitzerlandWest",
"NorwayEast",
"NorwayWest",
"SoutheastAsia",
"EastAsia",
"AustraliaEast",
"AustraliaCentral",
"ChinaEast",
"ChinaNorth",
"ChinaEast2",
"ChinaNorth2",
"CentralIndia",
"WestIndia",
"SouthIndia",
"JapanEast",
"JapanWest",
"KoreaCentral",
"KoreaSouth",
"SouthAfricaWest",
"SouthAfricaNorth",
"UAECentral",
"UAENorth"
],
"metadata": {
}
},
"type": "string",
"minLength": 1,
"metadata": {
}
},
"metricName": {
"type": "string",
"minLength": 1,
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"GreaterOrLessThan"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"High",
"Medium",
"Low"
],
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"metadata": {
}
},
"type": "string",
"allowedValues": [
"Average",
"Minimum",
"Maximum",
"Total",
"Count"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
}
},
"type": "string",
"allowedValues": [
"allowedValues": [
"PT5M",
"PT15M",
"PT30M",
"PT1H"
],
"metadata": {
format"
}
},
"actionGroupId": {
"type": "string",
"defaultValue": "",
"metadata": {
deactivated"
}
}
},
"variables": { },
"resources": [
{
"apiVersion": "2018-03-01",
"tags": {},
"properties": {
"criteria": {
"allOf": [
{
"dimensions":[],
"failingPeriods": {
},
}
]
},
"actions": [
{
}
]
}
}
]
}
siguiente como ist-of-vms-dynamic.parameters.json para usarlo en este tutorial.
{
"parameters": {
"alertName": {
"value": "Multi-resource metric alert with Dynamic Thresholds by list via Azure Resource
Manager template"
},
"value": "New Multi-resource metric alert with Dynamic Thresholds by list created via template"
},
"alertSeverity": {
"value":3
},
"isEnabled": {
"value": true
},
"value": [
]
},
},
},
"metricName": {
},
"operator": {
},
"value": "Medium"
},
"value": "4"
},
"value": "3"
},
"value": "Average"
},
"actionGroupId": {
}
}
}
Connect-AzAccount

-TemplateFile list-of-vms-dynamic.json -TemplateParameterFile list-of-vms-dynamic.parameters.json
az login

--template-file list-of-vms-dynamic.json \
--parameters @list-of-vms-dynamic.parameters.json
Plantilla para una prueba de disponibilidad junto con una alerta de

métricas
Las pruebas de disponibilidad de Application Insights le ayudan a supervisar la disponibilidad del sitio web o la
aplicación desde varias ubicaciones de todo el mundo. Las alertas de la prueba de disponibilidad le avisan
cuando se producen errores en las pruebas desde un determinado número de ubicaciones. Estas alertas
corresponden al mismo tipo de recurso que las alertas de métricas (Microsoft.Insights/metricAlerts). La
siguiente plantilla de Azure Resource Manager de ejemplo se puede usar para configurar una sencilla prueba
de disponibilidad y una alerta asociada.
Para este tutorial, guarde el archivo json siguiente como availabilityalert.json.
{
"parameters": {
"appName": {
"type": "string"
},
"pingURL": {
"type": "string"
},
"pingText": {
"type": "string",
"defaultValue": ""
},
"actionGroupId": {
"type": "string"
},
"location": {
"type": "string"
}
},
"variables": {
"pingTestName": "[concat('PingTest-', toLower(parameters('appName')))]",
"pingAlertRuleName": "[concat('PingAlert-', toLower(parameters('appName')), '-',
subscription().subscriptionId)]"
},
"resources": [
{
"name": "[variables('pingTestName')]",
"type": "Microsoft.Insights/webtests",
"apiVersion": "2014-04-01",
"apiVersion": "2014-04-01",
"tags": {
"Resource"
},
"properties": {
"Name": "[variables('pingTestName')]",
"Description": "Basic ping test",
"Enabled": true,
"Frequency": 300,
"Timeout": 120,
"Kind": "ping",
"RetryEnabled": true,
"Locations": [
{
"Id": "us-va-ash-azr"
},
{
"Id": "emea-nl-ams-azr"
},
{
"Id": "apac-jp-kaw-edge"
}
],
"Configuration": {
"WebTest": "[concat('<WebTest Name=\"', variables('pingTestName'), '\" Enabled=\"True\"
xmlns=\"http://microsoft.com/schemas/VisualStudio/TeamTest/2010\" Description=\"\"
CredentialUserName=\"\" CredentialPassword=\"\" PreAuthenticate=\"True\" Proxy=\"default\"
StopOnError=\"False\" RecordedResultFile=\"\" ResultsLocale=\"\"> <Items> <Request
Method=\"GET\" Version=\"1.1\" Url=\"', parameters('pingURL'), '\" ThinkTime=\"0\" Timeout=\"300\"
ParseDependentRequests=\"True\" FollowRedirects=\"True\" RecordResult=\"True\" Cache=\"False\"
ResponseTimeGoal=\"0\" Encoding=\"utf-8\" ExpectedHttpStatusCode=\"200\" ExpectedResponseUrl=\"\"
ReportingName=\"\" IgnoreHttpStatusCode=\"False\" /> </Items> <ValidationRules> <ValidationRule
Classname=\"Microsoft.VisualStudio.TestTools.WebTesting.Rules.ValidationRuleFindText,
Microsoft.VisualStudio.QualityTools.WebTestFramework, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a\" DisplayName=\"Find Text\" Description=\"Verifies the existence of
the specified text in the response.\" Level=\"High\" ExecutionOrder=\"BeforeDependents\">
<RuleParameters> <RuleParameter Name=\"FindText\" Value=\"', parameters('pingText'), '\" />
<RuleParameter Name=\"IgnoreCase\" Value=\"False\" /> <RuleParameter Name=\"UseRegularExpression\"
Value=\"False\" /> <RuleParameter Name=\"PassIfTextFound\" Value=\"True\" /> </RuleParameters>
</ValidationRule> </ValidationRules> </WebTest>')]"
},
"SyntheticMonitorId": "[variables('pingTestName')]"
}
},
{
"name": "[variables('pingAlertRuleName')]",
"apiVersion": "2018-03-01",
"dependsOn": [
"[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]"
],
"tags": {
"Resource",
"[concat('hidden-link:', resourceId('Microsoft.Insights/webtests', variables('pingTestName')))]":
"Resource"
},
"properties": {
"description": "Alert for web test",
"severity": 1,
"enabled": true,
"scopes": [
"[resourceId('Microsoft.Insights/webtests',variables('pingTestName'))]",
"[resourceId('Microsoft.Insights/components',parameters('appName'))]"
],
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.WebtestLocationAvailabilityCriteria",
"webTestId": "[resourceId('Microsoft.Insights/webtests', variables('pingTestName'))]",
"componentId": "[resourceId('Microsoft.Insights/components', parameters('appName'))]",
"failedLocationCount": 2
},
"actions": [
{
}
]
}
}
]
}
NOTE
&amp ; es la referencia de entidad HTML para &. Los parámetros de dirección URL se siguen separando con un solo
símbolo &, pero si se menciona la dirección URL en HTML, es necesario codificarla. Por lo tanto, si tiene un símbolo "&"
en el valor del parámetro pingURL, tiene que agregarle un escape con " &amp ;".
Guarde el archivo json siguiente como availabilityalert.parameters.json y modifíquelo según sea necesario.
{
"parameters": {
"appName": {
"value": "Replace with your Application Insights resource name"
},
"pingURL": {
"value": "https://www.yoursite.com"
},
"actionGroupId": {
resourceGroup-name/providers/microsoft.insights/actiongroups/replace-with-action-group-name"
},
"location": {
"value": "Replace with the location of your Application Insights resource"
}
}
}
Puede crear la prueba de disponibilidad y la alerta asociada con la plantilla y el archivo de parámetros
mediante PowerShell o la CLI de Azure.
Connect-AzAccount
New-AzResourceGroupDeployment -Name AvailabilityAlertDeployment -ResourceGroupName

ResourceGroupofApplicationInsightsComponent `
-TemplateFile availabilityalert.json -TemplateParameterFile availabilityalert.parameters.json
az login

--name AvailabilityAlertDeployment \
--resource-group ResourceGroupofApplicationInsightsComponent \
--template-file availabilityalert.json \
--parameters @availabilityalert.parameters.json
Pasos siguientes
Obtenga más información sobre alertas en Azure
Obtenga más información para crear un grupo de acciones con plantillas de Resource Manager
Para conocer las propiedades y la sintaxis de JSON, consulte la referencia de la plantilla
Microsoft.Insights/metricAlerts.
Solución de problemas en las alertas de métricas de
Azure Monitor
En este artículo se describen los problemas comunes de las alertas de métricas de Azure Monitor y cómo
solucionarlos.
Las alertas de Azure Monitor le informan de forma proactiva cuando se detectan condiciones importantes en los
datos que se supervisan. Le permiten identificar y solucionar los problemas antes de que los usuarios del sistema
puedan verlos. Para más información sobre las alertas, consulte Información general sobre las alertas en
Microsoft Azure.
La alerta de métrica debería haberse desencadenado, pero no lo hizo

Si cree que una alerta de métrica debe haberse desencadenado, pero no lo hizo y no se encuentra en Azure
Portal, intente seguir los pasos siguientes:
1. Configuración : revise la configuración de la regla de alerta de métricas para asegurarse de que se haya
establecido correctamente:
Compruebe que los valores Tipo de agregación , Granularidad de agregación (período) y
Valor de umbral o Confidencialidad estén configurados según lo esperado.
Para una regla de alerta que usa umbrales dinámicos, compruebe si se ha establecido la
configuración avanzada, ya que la opción Número de infracciones puede filtrar las alertas y la
opción Omitir los datos antes del puede afectar a cómo se calculan los umbrales.
NOTE
Los umbrales dinámicos tardan al menos 3 días en estar activos y requieren 30 muestras de métricas como
mínimo.
2. Se desencadena pero no genera ninguna notificación : revise la lista de alertas desencadenadas

para ver si puede localizar la alerta desencadenada. Si puede ver la alerta en la lista, pero tiene un
problema con algunas de sus acciones o notificaciones, consulte más información aquí.
3. Ya está activa : compruebe si ya hay una alerta desencadenada en la serie temporal de métricas para la
que espera recibir una alerta. Las alertas de métricas tienen estado, lo que significa que, una vez que se
desencadene una alerta en una serie temporal específica de métricas, no se activarán alertas adicionales
en esa serie temporal hasta que ya no se observe el problema. Esta opción de diseño reduce el ruido. La
alerta se resolverá automáticamente cuando no se cumpla la condición de alerta durante tres
evaluaciones consecutivas.
4. Dimensiones usadas : si ha seleccionado varios valores de dimensión para una métrica, la regla de alerta
supervisará si las series temporales de métricas individuales (definidas por una combinación de valores de
dimensión) superan un umbral. Si también quiere supervisar la serie temporal de métricas de agregado
(sin ninguna dimensión seleccionada), configure una regla de alerta adicional en la métrica sin seleccionar
las dimensiones.
5. Agregación y granularidad de tiempo : si visualiza la métrica mediante gráficos de métricas, asegúrese
de lo siguiente:
El valor Agregación seleccionado en el gráfico de métricas es igual que el de Tipo de agregación en
la regla de alerta.
El valor Granularidad de tiempo es el mismo que el de Granularidad de agregación (período)
en la regla de alerta (y no está establecido en "Automático").
Una alerta de métrica se desencadenó cuando no debería

Si cree que no se debería haber desencadenado una alerta de métricas y lo hizo, los siguientes pasos pueden
ayudarle a resolver el problema.
1. Revise la lista de alertas desencadenadas para buscar la alerta desencadenada y haga clic para ver sus
detalles. Revise la información proporcionada en Why did this aler t fire? (¿Por qué se desencadenó esta
alerta?) para ver el gráfico de métricas, el valor de métrica y el valor del umbral del momento en que
se desencadenó la alerta.
NOTE
Si usa el tipo de condición Umbrales dinámicos y piensa que los umbrales usados no eran correctos, envíe sus
comentarios mediante el icono de desaprobación. Estos comentarios afectarán a la investigación algorítmica del
aprendizaje automático y mejorarán las detecciones futuras.
2. Si seleccionó varios valores de dimensión para una métrica, la alerta se desencadenará cuando
cualquiera de las series temporales de métricas (definidas por la combinación de valores de dimensión)
supere el umbral. Para más información sobre el uso de las dimensiones en las alertas de métricas,
consulte este artículo.
3. Revise la configuración de la regla de alerta para asegurarse de que se haya establecido correctamente:
Compruebe que los valores Tipo de agregación , Granularidad de agregación (período) y Valor
de umbral o Confidencialidad estén configurados según lo esperado.
Para una regla de alerta que usa umbrales dinámicos, compruebe si se ha establecido la configuración
avanzada, ya que la opción Número de infracciones puede filtrar las alertas y la opción Omitir los
datos antes del puede afectar a cómo se calculan los umbrales.
NOTE
Los umbrales dinámicos tardan al menos 3 días en estar activos y requieren 30 muestras de métricas como
mínimo.
4. Si está visualizando la métrica con el gráfico de métricas, asegúrese de lo siguiente:

El valor Agregación seleccionado en el gráfico de métricas es igual que el de Tipo de agregación en
la regla de alerta.
El valor Granularidad de tiempo es el mismo que el de Granularidad de agregación (período)
en la regla de alerta (y no está establecido en "Automático").
5. Si la regla se desencadena mientras ya hay alertas desencadenadas que supervisan los mismos criterios
(que no se han resuelto), compruebe si la regla de alerta se ha configurado con la propiedad autoMitigate
establecida en false (esta propiedad solo se puede configurar mediante REST, PowerShell o la CLI, por lo
que compruebe el script usado para implementar la regla de alerta). En tal caso, la regla de alerta no
resolverá automáticamente las alertas desencadenadas y no será necesario resolver una alerta
desencadenada antes de volver a desencadenarla.
No se puede encontrar la métrica de la que se deben generar alertas

(métricas de máquinas virtuales invitadas)
Para generar alertar sobre las métricas del sistema operativo invitado de las máquinas virtuales (por ejemplo: la
memoria o el espacio en disco), asegúrese de que haya instalado el agente necesario para recopilar estos datos
en las métricas de Azure Monitor:
Para las máquinas virtuales Windows
Para las máquinas virtuales Linux
Para obtener más información acerca de la recopilación de datos del sistema operativo invitado de una máquina
virtual, consulte este vínculo.
NOTE
Si ha configurado las métricas de invitado que se van a enviar a un área de trabajo de Log Analytics, estas aparecerán en el
recurso del área de trabajo de Log Analytics y comenzarán a mostrar datos solo después de crear una regla de alerta que
las supervise. Para ello, siga los pasos para configurar una alerta de métrica para los registros.
No se puede encontrar la métrica de la que se deben generar alertas

Si quiere generar alertas sobre una métrica específica, pero no puede ver ninguna métrica del recurso,
compruebe si el tipo de recurso es compatible con las alertas de métricas. Si puede ver algunas métricas del
recurso, pero no puede encontrar ninguna métrica específica, compruebe si esa métrica está disponible y, si es
así, consulte su descripción para ver si solo está disponible en versiones o ediciones específicas del recurso.
No se puede encontrar la dimensión de la métrica de la que se deben

generar alertas
Si quiere generar una alerta sobre valores de dimensión específicos de una métrica, pero no puede encontrar
estos valores, tenga en cuenta lo siguiente:
1. Los valores de dimensión pueden tardar unos minutos en aparecer en la lista de valores de dimensión .
2. Los valores de dimensión mostrados se basan en los datos de métrica recopilados en los últimos tres días.
3. Si aún no se ha emitido el valor de dimensión, haga clic en el signo "+" para agregar un valor personalizado.
4. Si quiere generar alertas sobre todos los valores posibles de una dimensión (incluidos los valores futuros),
active la casilla "Seleccionar*".
Reglas de alertas de métricas aún definidas en un recurso eliminado

Al eliminar un recurso de Azure, las reglas de alertas de métricas asociadas no se eliminan automáticamente.
Para eliminar reglas de alerta asociadas a un recurso que se ha eliminado:
1. Abra el grupo de recursos en el que se ha definido el recurso eliminado.
2. En la lista que muestra los recursos, active la casilla Mostrar tipos ocultos
3. Filtre la lista por tipo = = microsoft.insights/metricaler ts
4. Seleccione las reglas de alertas pertinentes y seleccione Eliminar .
Generación de alertas de métricas cada vez que se cumple mi

condición
Las alertas de métricas tienen estado de forma predeterminada y, por lo tanto, no se desencadenan alertas
adicionales si ya hay una alerta desencadenada en una serie temporal determinada. Si quiere quitar el estado de
una regla de alerta de métrica específica y recibir una alerta para cada evaluación en la que se cumpla la
condición de alerta, cree la regla de alerta mediante programación (por ejemplo, mediante Resource Manager,
PowerShell, REST y la CLI) y establezca la propiedad autoMitigate en "False".
NOTE
La creación de una regla de alerta de métricas sin estado evita que se resuelvan las alertas desencadenadas, por lo que,
aunque después no se cumpla más la condición, las alertas desencadenadas permanecerán en un estado desencadenado
hasta el período de retención de 30 días.
Definición de una regla de alerta en una métrica personalizada que

todavía no se ha emitido
Al crear una regla de alerta de métrica, el nombre de la métrica se valida con la API de definiciones de métricas
para asegurarse de que existe. En algunos casos, le gustaría crear una regla de alerta en una métrica
personalizada incluso antes de que se emita. Por ejemplo, al crear (mediante una plantilla de Resource Manager)
un recurso de Application Insights que emitirá una métrica personalizada, junto con una regla de alerta que
supervise esa métrica.
Para evitar que se produzca un error en la implementación al intentar validar las definiciones de la métrica
personalizada, puede usar el parámetro skipMetricValidation en la sección de criterios de la regla de alerta, lo que
hará que se omita la validación de la métrica. Vea el ejemplo siguiente para obtener información sobre cómo
usar este parámetro en una plantilla de Resource Manager. Para más información, consulte los ejemplos de
plantilla de Resource Manager completos para crear reglas de alertas de métricas.
"criteria": {
"allOf": [
{
"name" : "condition1",
"metricName": "myCustomMetric",
"metricNamespace": "myCustomMetricNamespace",
"dimensions":[],
"threshold" : 10,
"skipMetricValidation": true
}
]
}
Exportación de la plantilla de Azure Resource Manager de una regla

de alertas de métricas mediante Azure Portal
La exportación de la plantilla de Resource Manager de una regla de alertas de métricas le ayuda a conocer su
sintaxis y sus propiedades JSON, y se puede usar para automatizar implementaciones futuras.
1. Vaya a la sección Grupos de recursos en el portal y seleccione el grupo de recursos que contenga la regla.
2. En la sección de información general, active la casilla Mostrar tipos ocultos .
3. En el filtro Tipo , seleccione microsoft.insights/metricalerts.
4. Seleccione la regla de regla apropiada para ver sus detalles.
5. En Configuración , seleccione Expor tar plantilla .
La cuota de las reglas de alertas de métricas es demasiado baja

El número permitido de reglas de alertas de métricas por suscripción está sujeto a los límites de cuota.
Si ha alcanzado el límite de cuota, los siguientes pasos pueden ayudar a resolver el problema:
1. Intente eliminar o deshabilitar las reglas de alertas de métricas que ya no se usan.
2. Cambie al uso de reglas de alertas de métricas que supervisen varios recursos. Con esta funcionalidad,
una única regla de alerta puede supervisar varios recursos con solo una regla de alerta en la cuota. Para
más información sobre esta funcionalidad y los tipos de recursos admitidos, consulte este artículo.
3. Si necesita aumentar el límite de cuota, abra una solicitud de soporte técnico y proporcione la siguiente
información:
Los identificadores de suscripción para los que tiene que aumentar los límites de cuota.
Tipo de recurso para el que se va a aumentar la cuota: Aler tas de métricas o aler tas de métricas
(clásicas)
Límite de cuota solicitado
Comprobación del número total de reglas de alertas de métricas

Para comprobar el uso actual de las reglas de alertas de métricas, siga los pasos siguientes.
Desde Azure Portal
1. Abra la pantalla Aler tas y haga clic en Administrar reglas de aler tas.
2. Filtre la suscripción correspondiente mediante el control desplegable Suscripción .
3. Asegúrese de NO filtrar por un grupo de recursos, tipo de recurso o recurso específico.
4. En el control desplegable Tipo de señal , seleccione Métricas .
5. Verifique que el control desplegable Estado esté establecido en Habilitado .
6. El número total de reglas de alertas de métricas se mostrará encima de la lista de reglas de alerta.
Desde la API
PowerShell: Get-AzMetricAlertRuleV2
API REST: Lista por suscripción
CLI de Azure: az monitor metrics alert list
Administración de las reglas de alertas mediante las plantillas de

Resource Manager, la API REST, PowerShell o la CLI de Azure
Si tiene problemas para crear, actualizar, recuperar o eliminar las alertas de métricas mediante plantillas de
Resource Manager, API REST, PowerShell o la interfaz de la línea de comandos (CLI) de Azure, puede que los
pasos siguientes le ayuden a solucionarlos.
Consulte la lista errores comunes de implementación de Azure y solucione el problema.
Consulte los ejemplos de plantillas de Azure Resource Manager de alertas de métricas para asegurarse de que
está pasando correctamente todos los parámetros.
API DE REST
Repase la guía de la API REST para asegurarse de que todos los parámetros se pasan correctamente.
PowerShell
Asegúrese de usar los cmdlets de PowerShell adecuados para las alertas de métricas:
Los cmdlets de PowerShell para las alertas de métricas están disponibles en el módulo Az.monitor.
Asegúrese de usar los cmdlets que terminan en "V2" para nuevas alertas de métricas (no clásicas) (por
ejemplo, Add-AzMetricAlertRuleV2).
Azure CLI
Asegúrese de usar los comandos de la CLI adecuados para las alertas de métricas:
Los comandos de la CLI para las alertas de métricas comienzan por az monitor metrics alert . Consulte la
referencia de la CLI de Azure para obtener información sobre la sintaxis.
Puede ver un ejemplo que muestra cómo usar la CLI de alertas de métricas.
Para generar una alerta en una métrica personalizada, asegúrese de anteponer el nombre de la métrica con el
espacio de nombres de métrica pertinente: NAMESPACE.METRIC
General
Si recibe un error Metric not found :
Para una métrica de plataforma: asegúrese de usar el nombre de la métrica de la página de
métricas admitidas de Azure Monitor y no el nombre para mostrar de la métrica .
Para una métrica personalizada: asegúrese de que la métrica ya se esté generando (no puede crear
una regla de alerta en una métrica personalizada que todavía no existe) y de que proporcione el
espacio de nombres de la métrica personalizada (consulte aquí un ejemplo de plantilla de Resource
Manager).
Si va a crear alertas de métricas en registros, asegúrese de incluir las dependencias correspondientes.
Consulte la plantilla de ejemplo.
Si crea una regla de alerta que contiene varios criterios, tenga en cuenta las siguientes restricciones:
Cuando las métricas configuradas en distintos criterios admiten la misma dimensión, se debe
establecer de forma explícita un valor de dimensión configurado de la misma manera para todas esas
métricas (consulte en este artículo un ejemplo de una plantilla de Resource Manager).
Sin permisos para crear reglas de alertas de métricas

Para crear una regla de alerta de métricas, debe tener los permisos siguientes:
Permiso de lectura en el recurso de destino de la regla de alerta
Permiso de escritura en el grupo de recursos en el que se crea la regla de alerta (si va a crear la regla de alerta
desde Azure Portal, esta se crea en el mismo grupo de recursos en el que reside el recurso de destino).
Permiso de lectura en cualquier grupo de acciones asociado a la regla de alerta (si es aplicable)
Restricciones de nomenclatura para las reglas de alertas de métricas

Tenga en cuenta las siguientes restricciones para los nombres de las reglas de alertas de métricas:
Los nombres de las reglas de alertas de métricas no se pueden cambiar (cambiar su nombre) una vez creadas
Los nombres de las reglas de alertas de métricas deben ser únicos dentro de un grupo de recursos
Los nombres de las reglas de alertas de métricas no pueden contener los siguientes caracteres: * # & +: < > ?
@%{}\/
Los nombres de las reglas de alertas de métricas no pueden acabar con el siguiente carácter: .
Restricciones al usar dimensiones en una regla de alertas de métricas

con varias condiciones
Las alertas de métricas admiten las alertas relacionadas con métricas de varias dimensiones además de admitir
la definición de varias condiciones (hasta 5 por regla de alertas).
Tenga en cuenta las restricciones siguientes cuando use dimensiones en una regla de alertas que contenga varias
condiciones:
Solo puede seleccionar un valor por dimensión dentro de cada condición.
No puede usar la opción "Seleccionar todos los valores actuales y futuros" (Select *).
Cuando métricas que están configuradas en distintas condiciones admiten la misma dimensión, se debe
establecer de forma explícita un valor de dimensión configurado de la misma manera para todas esas
métricas (en las condiciones pertinentes). Por ejemplo:
Considere una regla de alertas de métricas que se define en una cuenta de almacenamiento y
supervisa dos condiciones:
Suma total del valor de Transactions > 5
Media del valor de SuccessE2ELatency > 250 ms
Nos gustaría actualizar la primera condición y supervisar solo las transacciones en las que la
dimensión ApiName sea igual a "GetBlob" .
Dado que las métricas Transactions y SuccessE2ELatency admiten la dimensión ApiName ,
necesitaremos actualizar ambas condiciones y hacer que ambas especifiquen la dimensión ApiName
con el valor "GetBlob" .
Pasos siguientes
Para obtener información general sobre la solución de problemas de alertas y notificaciones, consulte
Solución de problemas en las alertas de Azure Monitor.
Creación, visualización y administración de
alertas de registro mediante Azure Monitor
En este artículo se muestra cómo crear y administrar alertas de registro con la interfaz de alertas
en Azure Portal. Las reglas de alertas se definen mediante tres componentes:
Destino: Un recurso de Azure específico para supervisar.
Criterios: Una condición o lógica que se va a evaluar para determinar si es verdadera. Si es
verdadera, la alerta se activa.
Acción: llamada específica enviada a un receptor de una notificación (correo electrónico, SMS,
webhook, etc.).
El término aler ta de registro describe las alertas en las que se evalúa una consulta de registro en
el área de trabajo de Log Analytics o en Application Insights, y se desencadena una alerta si el
resultado es verdadero. Obtenga más información acerca de la funcionalidad, la terminología y los
tipos de Alertas de registro: información general.
NOTE
Los datos de registro de un área de trabajo de Log Analytics también se pueden enrutar a la base de datos
de métricas Azure Monitor. Las alertas de métricas tienen diferentes comportamientos, lo que puede ser
más conveniente en función de los datos con los que esté trabajando. Para saber más sobre cómo se
pueden enrutar los registros a las métricas, vea Alerta de métricas para los registros.
Creación de una regla de alertas de registro en Azure Portal

1. En el portal, seleccione Monitor . En esa sección, elija Aler tas .
2. Haga clic en Nueva regla de aler tas .
3. Aparece el panel Crear aler ta . Tiene cuatro partes:

el recurso al que se aplica la alerta;
la condición que se va a comprobar;
acción que se realizará si la condición es verdadera,
los detalles para asignar un nombre y una descripción de la alerta.
4. Para definir la condición de la alerta, use primero el vínculo Seleccionar recurso y

especifique el destino mediante la selección de un recurso. Para filtrar, elija la Suscripción, el
Tipo de recurso y el Recurso necesario.
5. Asegúrese de que Tipo de recurso es un origen de análisis como Log Analytics o
Application Insights y el tipo de señal es Registro. Haga clic en Done (Listo). Después, use el
botón Agregar criterios para ver la lista de opciones de señal disponibles para el recurso.
Busque y elija la opción Custom log search (Búsqueda de registros personalizada) para
Log Analytics o Application Insights, en función de dónde residan los datos de las alertas de
registro.
NOTE
Las listas de las alertas pueden importar una consulta de análisis como tipo de señal (Log (Saved
Quer y) (Registro [consulta guardada])), tal como se muestra en la ilustración anterior. De este
modo, los usuarios pueden perfeccionar la consulta en Analytics y guardarla para su uso futuro en
las alertas. Para más información sobre el uso de consultas guardadas, vea uso de consultas de
registros en Azure Monitor y consultas compartidas en Application Insights Analytics.
6. Una vez seleccionada, cree la consulta de alertas en el campo Consulta de búsqueda . Si la

sintaxis de la consulta es incorrecta, el campo muestra un error en rojo.
7. Si la sintaxis de la consulta es correcta, los datos históricos de la consulta aparecen como un
gráfico con la opción de cambiar el período de tiempo de las últimas seis horas a la última
semana.
La visualización de los datos históricos solo se muestra si los resultados de la consulta

tienen detalles temporales. Si la consulta genera datos resumidos o valores de columna
específicos, estos se representan en un gráfico singular.
Para las medidas métricas mediante Application Insights o la API de Log Analytics, puede
especificar por qué variable concreta se agruparán los datos mediante la opción Agregado
en , tal y como muestra aquí:
8. Después, elija la condición, la agregación y el umbral de Lógica de aler ta .
9. Elija el período de tiempo durante el que se va a evaluar la condición especificada, mediante
la opción Período .
10. Elija la frecuencia con la que se ejecuta la alerta en Frecuencia .
Las aler tas de registro se pueden basar en lo siguiente:
Número de registros: se crea una alerta si el número de registros devueltos por la
consulta es mayor o menor que el valor que proporcione.
Unidades métricas: se crea una alerta si cada valor agregado en los resultados excede el
valor de umbral proporcionado y se agrupa por el valor elegido. El número de
infracciones de una alerta es el número de veces que se supera el umbral en el período
de tiempo seleccionado. Puede especificar Infracciones totales para cualquier
combinación de infracciones en el conjunto de resultados o Infracciones consecutivas
para que las infracciones deban tener lugar en muestras consecutivas.
12. Asigne un nombre a la alerta en el campo Nombre de la regla de aler tas junto con una
Descripción , en la que debe proporcionar información específica sobre la alerta, y debe
indicar también un valor de Gravedad entre las opciones proporcionadas. Estos detalles se
reutilizan en todos los correos electrónicos, las notificaciones o las notificaciones push de
alerta enviados por Azure Monitor. Además, puede elegir activar inmediatamente la regla de
alertas al crearla si hace clic en Habilitar regla tras la creación .
13. Elija si quiere Suprimir aler tas durante un período de tiempo. Al activar la supresión de la
regla de alerta, las acciones de la regla se deshabilitan durante un período de tiempo
definido después de crear una nueva alerta. La regla se sigue ejecutando y crea registros de
alertas si se cumplen los criterios. Esta opción ofrece tiempo para corregir el problema sin
ejecutar acciones duplicadas.
TIP
Especifique un valor de desactivar las alertas mayor que la frecuencia de alertas para garantizar que
las notificaciones se detengan sin superposición
14. Como tercer y último paso, especifique si la regla de alerta debe desencadenar un Grupo
de acciones o varios cuando se cumpla la condición de alerta. Puede elegir cualquier grupo
de acciones existente o crear uno nuevo. Con los grupos de acciones, puede enviar una serie
de acciones, como por ejemplo, enviar correos electrónicos, enviar SMS, llamar a webhook,
corregir mediante Azure Runbooks, realizar una inserción en la herramienta ITSM y mucho
más. Obtenga más información sobre los grupos de acciones.
NOTE
Para conocer los límites de las acciones que se pueden realizar, vea Límites de servicio de
suscripción de Azure.
Hay disponibles otras funciones para reemplazar las acciones predeterminadas:

Notificación por correo electrónico : Invalida asunto de correo electrónico en el
correo electrónico enviado a través del grupo de acciones. No se puede modificar el
cuerpo del mensaje de correo y este campo no es para la dirección de correo
electrónico.
Incluir carga de JSON personalizada : Invalida el JSON de webhook que usan los
grupos de acciones suponiendo que el grupo de acciones contenga un tipo de
webhook. Para más información sobre los formatos de webhook, vea Acciones de
webhook para alertas de registro. La opción de vista de webhook se proporciona para
comprobar el formato con datos JSON de ejemplo.
15. Si todos los campos son válidos y tienen una marca verde, se puede hacer clic en el botón
Crear regla de aler tas y se crea la alerta en Azure Monitor: Alertas. Todas las alertas
pueden verse en el panel de las alertas.
En cuestión de minutos, se activa la alerta y se desencadena tal como se describió

anteriormente.
Los usuarios también pueden finalizar la consulta de análisis en Log Analytics e insertarla para
crear una alerta mediante el botón "Establecer alerta" y, a continuación, seguir las instrucciones del
paso 6 en adelante del tutorial anterior.
Visualización y administración de las alertas de registro en Azure Portal

1. En Azure Portal, seleccione Super visar y, en la sección SUPERVISAR, elija Aler tas .
2. Se muestra el panel de aler tas , de forma que aparecen todas las alertas de Azure
(incluidas las alertas de registro) en un único panel, incluidas todas las instancias de cuando
se ha activado la regla de la alerta de registro. Para obtener más información, consulte Alert
Management.
NOTE
Las reglas de la alerta de registro se componen de una lógica personalizada basada en la consulta
proporcionada por los usuarios y, por lo tanto, sin un estado resuelto. Debido a esto, cada vez que
se cumplen las condiciones especificadas en la regla de la alerta de registro, se activa.
3. Seleccione el botón Administrar reglas situado en la barra superior para navegar hasta la
sección de administración de reglas, donde se enumeran todas las reglas de alerta creadas,
incluidas las alertas que se han deshabilitado.
Administración de alertas de registro mediante la plantilla de

recursos de Azure
Las alertas del registro de Azure Monitor están asociadas con el tipo de recurso
Microsoft.Insights/scheduledQueryRules/ . Para más información sobre este tipo de recurso, vea
Azure Monitor: referencia de la API de reglas de consulta programada. Las alertas de registro de
Application Insights o Log Analytics se pueden crear mediante la API de Reglas de consulta
programadas.
NOTE
Las alertas de registro de Log Analytics también se puede administrar mediante Alert API de Log Analytics
y las plantillas heredadas de búsquedas y alertas guardadas de Log Analytics también. Para más
información acerca del uso de la nueva API de Reglas de consulta programadas detallada aquí de forma
predeterminada, consulte Switch to new API for Log Analytics Alerts (Cambio a una API nueva de alertas
de Log Analytics).
Creación de una alerta de registro de ejemplo mediante la plantilla de recursos de Azure

Esta es la estructura de la plantilla de recursos basada en la creación de reglas de consulta
programada mediante una consulta de búsqueda de registros estándar de una alerta de registro
del tipo número de resultados, con datos de ejemplo establecidos como variables.
{
"parameters": {
},
"variables": {
"alertLocation": "southcentralus",
"alertName": "samplelogalert",
"alertDescription": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"requests",
"SourceId": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/components/sampleAIapplication",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4"
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/myRG/providers/microsoft.insights/actiongroups/sampleAG",
"Subject": "Customized Email Header",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescription')]",
"enabled": "[variables('alertStatus')]",
"source": {
"query": "[variables('alertSource').Query]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataCon
tracts.Resources.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"aznsAction":{
"actionGroup":"[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]"
}
}
}
} ]
}
El JSON del ejemplo anterior puede guardarse como (digamos) sampleScheduledQueryRule.json a
efectos de este tutorial y puede implementarse mediante Azure Resource Manager en Azure Portal.
Alerta de registro con consulta entre registros mediante la plantilla de recursos de Azure
Esta es la estructura de la plantilla de recursos basada en la creación de reglas de consulta
programada mediante una consulta de búsqueda de registros entre recursos de una alerta de
registro del tipo unidad métrica, con datos de ejemplo establecidos como variables.
{
"parameters": {
},
"variables": {
"alertLocation": "Region Name for your Application Insights App or Log Analytics
Workspace",
"alertName": "sample log alert",
"alertDescr": "Sample log search alert",
"alertStatus": "true",
"alertSource":{
"Query":"union workspace(\"servicews\").Update, app('serviceapp').requests |
summarize AggregatedValue = count() by bin(TimeGenerated,1h), Classification",
"Resource1": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.OperationalInsights/workspaces/servic
ews",
"Resource2": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/components/serviceapp",
"SourceId": "/subscriptions/a123d7efg-123c-1234-5678-
ews",
"Type":"ResultCount"
},
"alertSchedule":{
"Frequency": 15,
"Time": 60
},
"alertActions":{
"SeverityLevel": "4",
"SuppressTimeinMin": 20
},
"alertTrigger":{
"Operator":"GreaterThan",
"Threshold":"1"
},
"metricMeasurement": {
"thresholdOperator": "Equal",
"threshold": "1",
"metricTriggerType": "Consecutive",
"metricColumn": "Classification"
},
"actionGrp":{
"ActionGroup": "/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG",
"Subject": "Customized Email Header",
"Webhook": "{ \"alertname\":\"#alertrulename\", \"IncludeSearchResults\":true }"
}
},
"resources":[ {
"name":"[variables('alertName')]",
"apiVersion": "2018-04-16",
"location": "[variables('alertLocation')]",
"properties":{
"description": "[variables('alertDescr')]",
"source": {
"query": "[variables('alertSource').Query]",
"authorizedResources": "[concat(array(variables('alertSource').Resource1),
array(variables('alertSource').Resource2))]",
"dataSourceId": "[variables('alertSource').SourceId]",
"queryType":"[variables('alertSource').Type]"
},
"schedule":{
"frequencyInMinutes": "[variables('alertSchedule').Frequency]",
"timeWindowInMinutes": "[variables('alertSchedule').Time]"
},
"action":{
"odata.type":
"Microsoft.WindowsAzure.Management.Monitoring.Alerts.Models.Microsoft.AppInsights.Nexus.DataCon
tracts.Resources.ScheduledQueryRules.AlertingAction",
"severity":"[variables('alertActions').SeverityLevel]",
"throttlingInMin": "[variables('alertActions').SuppressTimeinMin]",
"aznsAction":{
"actionGroup": "[array(variables('actionGrp').ActionGroup)]",
"emailSubject":"[variables('actionGrp').Subject]",
"customWebhookPayload":"[variables('actionGrp').Webhook]"
},
"trigger":{
"thresholdOperator":"[variables('alertTrigger').Operator]",
"threshold":"[variables('alertTrigger').Threshold]",
"metricTrigger":{
"thresholdOperator": "
[variables('metricMeasurement').thresholdOperator]",
"threshold": "[variables('metricMeasurement').threshold]",
"metricColumn": "[variables('metricMeasurement').metricColumn]",
"metricTriggerType": "
[variables('metricMeasurement').metricTriggerType]"
}
}
}
}
} ]
}
IMPORTANT
Si usa una consulta entre recursos en la alerta de registros, el uso de authorizedResources es obligatorio y
el usuario debe acceder a la lista de los recursos indicados.
El JSON del ejemplo anterior puede guardarse como (digamos) sampleScheduledQueryRule.json a

efectos de este tutorial y puede implementarse mediante Azure Resource Manager en Azure Portal.
Administración de alertas de registro con PowerShell

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el
módulo de AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como
mínimo. Para más información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte
Introducing the new Azure PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell).
Para obtener instrucciones sobre la instalación del módulo Az, consulte Instalación de Azure PowerShell.
Azure Monitor: API de Reglas de consulta programadas es una API REST totalmente compatible con
la API REST de Azure Resource Manager. Y los cmdlets de PowerShell que se enumeran a
continuación están disponibles para aprovechar la API de Reglas de consulta programadas.
New-AzScheduledQueryRule: cmdlet de PowerShell para crear una nueva regla de alerta de
registro.
Set-AzScheduledQueryRule: cmdlet de PowerShell para actualizar una regla de alerta de
registro.
New-AzScheduledQueryRuleSource: cmdlet de PowerShell para crear o actualizar el objeto que
especifica los parámetros de origen para una alerta de registro. Se usa como entrada en los
cmdlets New-AzScheduledQueryRule y Set-AzScheduledQueryRule.
New-AzScheduledQueryRuleSchedule: cmdlet de PowerShell para crear o actualizar el objeto
que especifica los parámetros de programación para una alerta de registro. Se usa como
entrada en los cmdlets New-AzScheduledQueryRule y Set-AzScheduledQueryRule.
New-AzScheduledQueryRuleAlertingAction: cmdlet de PowerShell para crear o actualizar el
objeto que especifica los parámetros de acción para una alerta de registro. Se usa como entrada
en los cmdlets New-AzScheduledQueryRule y Set-AzScheduledQueryRule.
New-AzScheduledQueryRuleAznsActionGroup: cmdlet de PowerShell para crear o actualizar el
objeto que especifica los parámetros de grupos para una alerta de registro. Se usa como
entrada en el cmdlet New-AzScheduledQueryRuleAlertingAction.
New-AzScheduledQueryRuleTriggerCondition: cmdlet de PowerShell para crear o actualizar el
objeto que especifica los parámetros de condición de desencadenador para una alerta de
registro. Se usa como entrada en el cmdlet New-AzScheduledQueryRuleAlertingAction.
New-AzScheduledQueryRuleLogMetricTrigger: cmdlet de PowerShell para crear o actualizar el
objeto que especifica los parámetros de condición de desencadenador para una alerta de
registro de tipo de medida de métrica. Se usa como entrada en el cmdlet New-
AzScheduledQueryRuleTriggerCondition.
Get-AzScheduledQueryRule: cmdlet de PowerShell para enumerar las reglas de alerta de
registro o una regla de alerta de registro específica
Update-AzScheduledQueryRule: cmdlet de PowerShell para habilitar o deshabilitar la regla de
alerta de registro
Remove-AzScheduledQueryRule: cmdlet de PowerShell para eliminar una regla de alerta de
registro
NOTE
Los cmdlets de PowerShell ScheduledQueryRules solo pueden administrar las reglas creadas por el propio
cmdlet o mediante Azure Monitor: API de Reglas de consulta programadas. Las reglas de alerta de registro
creadas con la API de alertas de Log Analytics antiguas y las plantillas antiguas de alertas y búsquedas
guardadas de Log Analytics pueden administrarse mediante los cmdlets de PowerShell
ScheduledQueryRules solo después de que el usuario cambie la preferencia de API a las alertas de Log
Analytics.
A continuación, se muestran los pasos para crear una regla de alertas de registro de ejemplo con
los cmdlets scheduledQueryRules de PowerShell.
$source = New-AzScheduledQueryRuleSource -Query 'Heartbeat | summarize AggregatedValue =
count() by bin(TimeGenerated, 5m), _ResourceId' -DataSourceId "/subscriptions/a123d7efg-123c-
1234-5678-
ews"
$schedule = New-AzScheduledQueryRuleSchedule -FrequencyInMinutes 15 -TimeWindowInMinutes 30
$metricTrigger = New-AzScheduledQueryRuleLogMetricTrigger -ThresholdOperator "GreaterThan" -

Threshold 2 -MetricTriggerType "Consecutive" -MetricColumn "_ResourceId"
$triggerCondition = New-AzScheduledQueryRuleTriggerCondition -ThresholdOperator "LessThan" -

Threshold 5 -MetricTrigger $metricTrigger
$aznsActionGroup = New-AzScheduledQueryRuleAznsActionGroup -ActionGroup

"/subscriptions/a123d7efg-123c-1234-5678-
a12bc3defgh4/resourceGroups/contosoRG/providers/microsoft.insights/actiongroups/sampleAG" -
EmailSubject "Custom email subject" -CustomWebhookPayload "{ `"alert`":`"#alertrulename`",
`"IncludeSearchResults`":true }"
$alertingAction = New-AzScheduledQueryRuleAlertingAction -AznsAction $aznsActionGroup -Severity

"3" -Trigger $triggerCondition
New-AzScheduledQueryRule -ResourceGroupName "contosoRG" -Location "Region Name for your

Application Insights App or Log Analytics Workspace" -Action $alertingAction -Enabled $true -
Description "Alert description" -Schedule $schedule -Source $source -Name "Alert Name"
Administración de alertas de registro con la CLI o la API

Azure Monitor: API de Reglas de consulta programadas es una API REST totalmente compatible con
la API REST de Azure Resource Manager. Por lo tanto, se puede utilizar a través de Powershell con
los comandos de Resource Manager para la CLI de Azure.
NOTE
Las alertas de registro de Log Analytics también se puede administrar mediante Alert API de Log Analytics
y las plantillas heredadas de búsquedas y alertas guardadas de Log Analytics también. Para más
información acerca del uso de la nueva API de Reglas de consulta programadas detallada aquí de forma
predeterminada, consulte Switch to new API for Log Analytics Alerts (Cambio a una API nueva de alertas
de Log Analytics).
Actualmente, las alertas de registro no tienen comandos de la CLI dedicados; pero, como se
muestra a continuación, se pueden usar mediante el cmdlet de la CLI de Azure Resource Manager
para la plantilla de recursos de muestra que se mostró anteriormente
(sampleScheduledQueryRule.json) en la sección Plantilla de recursos:
az group deployment create --resource-group contosoRG --template-file

sampleScheduledQueryRule.json
Si la operación se realiza correctamente, se devolverá 201 para indicar que se ha creado la regla de
alertas o 200 si se ha modificado una regla de alerta existente.
Pasos siguientes
Más información sobre las alertas de registro en las alertas de Azure.
Conocer las acciones de webhook para alertas de registro
Más información sobre Application Insights
Obtenga más información sobre las consultas de registro.
Consultas de alertas de registro en Azure Monitor
Las reglas de alertas basadas en registros de Azure Monitor se ejecutan a intervalos regulares, por lo que debe
asegurarse de que están escritas de manera eficiente para minimizar la sobrecarga y la latencia. Este artículo
proporciona recomendaciones sobre cómo escribir consultas eficaces para las alertas de registro y un proceso
para convertir las consultas existentes.
Tipos de consultas de registro

Las consultas de registro de Azure Monitor comienzan con una tabla o un operador de búsqueda o de unión.
Por ejemplo, la siguiente consulta se limita a la tabla SecurityEvent y busca el identificador de evento específico.
Esta es la única tabla que debe procesar la consulta.
SecurityEvent | where EventID == 4624
Las consultas que empiezan por search o union le permiten buscar en varias columnas de una tabla o incluso
en varias tablas. Los ejemplos siguientes muestran varios métodos para buscar el término Memory:
search "Memory"
search * | where == "Memory"
search ObjectName: "Memory"
search ObjectName == "Memory"
union * | where ObjectName == "Memory"
Aunque search y union son útiles durante la exploración de datos, ya que buscan términos en todo el modelo
de datos, son menos eficientes que el uso de una tabla puesto que aquellos deben examinar varias tablas. Dado
que las consultas de las reglas de alertas se ejecutan a intervalos regulares, esto puede dar lugar a una
sobrecarga excesiva que agrega latencia a la alerta. Debido a esta sobrecarga, las consultas para las reglas de
alertas de registro en Azure siempre deben empezar con una tabla que defina un ámbito claro que mejore el
rendimiento de las consultas y la pertinencia de los resultados.
Consultas no admitidas
A partir del 11 de enero de 2019, la creación o modificación de reglas de alertas de registro que usen los
operadores search o union no se admitirán en Azure Portal. El uso de estos operadores en una regla de alertas
devolverá un mensaje de error. Este cambio no afecta a las reglas de alertas existentes ni a aquellas creadas y
editadas con la API de Log Analytics. No obstante, debería considerar la posibilidad de cambiar las reglas de
alertas que usen estos tipos de consultas para mejorar su eficacia.
A las reglas de alertas del registro que usan consultas entre recursos no les afecta este cambio ya que estas usan
union , que permite limitar el ámbito de la consulta a recursos específicos. Este no es igual a union * que no se
puede usar. El ejemplo siguiente sería válido en una regla de alertas de registro:
union
workspace('Contoso-workspace1').Perf
NOTE
La consulta entre recursos en las alertas de registro se admite en la nueva API scheduledQueryRules. De forma
predeterminada, Azure Monitor usa la API de alerta heredada de Log Analytics para crear nuevas reglas de alerta de
registro desde Azure Portal, a menos que cambie de API de alerta de registro heredada. Después del cambio, la nueva API
se convierte en la predeterminada para las nuevas reglas de alerta en Azure Portal y le permite crear reglas de alertas de
registro de consulta entre recursos. Puede crear reglas de alertas de registro de consulta entre recursos sin realizar el
cambio mediante la plantilla de ARM de la API scheduledQueryRules; sin embargo, esta regla de alertas se puede
administrar mediante la API scheduledQueryRules y no desde Azure Portal.
Ejemplos
Los siguientes ejemplos incluyen las consultas de registro que usan search y union y proporcionan los pasos
que puede usar para modificar estas consultas para su uso con las reglas de alertas.
Ejemplo 1
Desea crear una regla de alertas de registro mediante la siguiente consulta que recupera información de
rendimiento mediante search :
search * | where Type == 'Perf' and CounterName == '% Free Space'

| where CounterValue < 30
| summarize count()
Para modificar esta consulta, empiece por usar la consulta siguiente para identificar la tabla a la que pertenecen
las propiedades:
search * | where CounterName == '% Free Space'

| summarize by $table
El resultado de esta consulta muestra que la propiedad CounterName procede de la tabla Perf.
Puede usar este resultado para crear la siguiente consulta que podría usar para la regla de alertas:
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
| summarize count()
Ejemplo 2
Desea crear una regla de alertas de registro mediante la siguiente consulta que recupera información de
rendimiento mediante search :
search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"

| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)
| count
las propiedades:
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"

El resultado de esta consulta muestra que la propiedad ObjectName y CounterName procede de la tabla Perf.
Puede usar este resultado para crear la siguiente consulta que podría usar para la regla de alertas:
Perf
| where ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage=avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)
| count
Ejemplo 3
Desea crear una regla de alertas de registro mediante la siguiente consulta que usa search y union para
recuperar información de rendimiento:
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| where Computer !in ((union * | where CounterName == "% Processor Utility" | summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer| count
las propiedades de la primera parte de la consulta:
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
El resultado de esta consulta muestra que todas estas propiedades proceden de la tabla Perf.
Ahora use union con el comando withsource para identificar qué tabla de origen ha contribuido a cada fila.
union withsource=table * | where CounterName == "% Processor Utility"

| summarize by table
El resultado de esta consulta muestra que estas propiedades también proceden de la tabla Perf.
Puede usar estos resultados para crear la siguiente consulta que podría usar para la regla de alertas:
Perf
| where ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total"
| where Computer !in (
(Perf
| where CounterName == "% Processor Utility"
| summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer
| count
Ejemplo 4
Desea crear una regla de alertas de registro mediante la siguiente consulta que combina los resultados de dos
consultas search :
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
search in (Heartbeat) OSType == 'Windows'
| summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
| project Hour , Computer
)
on Hour
| count
Para modificar la consulta, empiece por usar la consulta siguiente para identificar la tabla que contiene las
propiedades del lado izquierdo de la combinación:
search Type == 'SecurityEvent' and EventID == '4625'

El resultado indica que las propiedades del lado izquierdo de la combinación pertenecen a la tabla SecurityEvent.
Ahora, use la consulta siguiente para identificar la tabla que contiene las propiedades del lado derecho de la
combinación:
search in (Heartbeat) OSType == 'Windows'

El resultado indica que las propiedades del lado derecho de la combinación pertenecen a la tabla Heartbeat.
Puede usar estos resultados para crear la siguiente consulta que podría usar para la regla de alertas:
SecurityEvent
| where EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
Heartbeat
| where OSType == 'Windows'
| summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
| project Hour , Computer
)
on Hour
| count
Pasos siguientes
Más información sobre las alertas de registro de Azure Monitor.
Más información acerca de las consultas de registro.
Acciones de webhook para reglas de alertas de
registro
Cuando se crea una alerta de registro en Azure, se puede configurar mediante grupos de acciones, para así
poder realizar una o varias acciones. En este artículo se describen las diferentes acciones de webhook que están
disponibles y se muestra cómo configurar un webhook personalizado basado en JSON.
NOTE
También se puede usar el esquema de alertas comunes para las integraciones de webhook. El esquema de alerta común
ofrece la ventaja de tener una carga útil de alerta única y extensible en todos los servicios de alerta de Azure Monitor.
Tenga en cuenta que el esquema de alerta común no respeta la opción de JSON personalizada para las alertas de registro.
Se aplaza a la carga del esquema de alerta común si se selecciona con independencia de la personalización que haya
realizado en el nivel de la regla de alerta. Obtenga más información sobre las definiciones de esquemas de alertas
comunes.
Acciones de webhook
Las acciones de webhook permiten invocar un proceso externo a través de una sola solicitud HTTP POST. El
servicio al que se llama debe admitir webhooks y determinar cómo utilizará las cargas que reciba.
Las acciones de webhook requieren las propiedades de la siguiente tabla.
Dirección URL de Webhook La dirección URL del webhook.
Carga de JSON personalizada La carga personalizada que se envía con el webhook, cuando
se elige esta opción durante la creación de la alerta. Para
más información, consulte Administración de alertas de
registro.
NOTE
El botón Ver webhook y la opción Incluir la carga personalizada de JSON para webhook de la alerta del registro
muestran una carga de webhook de ejemplo con la personalización proporcionada. No contiene datos reales, pero es
representativo del esquema JSON que se usa para las alertas de registro.
Los webhooks incluyen una dirección URL y una carga con formato JSON que corresponde a los datos enviados
al servicio externo. De forma predeterminada, la carga incluye los valores en la tabla siguiente. Puede optar por
reemplazar esta carga con una personalizada de su propiedad. En ese caso, puede utilizar las variables de la
tabla para cada uno de los parámetros e incluir así sus valores en la carga personalizada.
PA RÁ M ET RO VA RIA B L E DESC RIP C IÓ N
AlertRuleName #alertrulename Nombre de la regla de alerta.

Gravedad #severity Gravedad establecida en la alerta de

registros activada.
AlertThresholdOperator ThresholdOperator Operador de umbral para la regla de

alertas, que usa mayor que o menor
que.
AlertThresholdValue #thresholdvalue Valor de umbral para la regla de alerta.
LinkToSearchResults #linktosearchresults Vínculo al portal de Analytics que

devuelve los registros de la consulta
que creó la alerta.
LinkToSearchResultsAPI #linktosearchresultsapi Vínculo a la API de Analytics que

que creó la alerta.
LinkToFilteredSearchResultsUI #linktofilteredsearchresultsui Vínculo al portal de Analytics que

filtrada por las combinaciones de
valores de dimensiones que crearon la
alerta.
LinkToFilteredSearchResultsAPI #linktofilteredsearchresultsapi Vínculo a la API de Analytics que

filtrada por las combinaciones de
valores de dimensiones que crearon la
alerta.
ResultCount #searchresultcount Número de registros en los resultados

de la búsqueda.
SearchIntervalEndtimeUtc #searchintervalendtimeutc Hora de finalización de la consulta en

hora UTC, con formato mm/dd/aaaa
HH:mm:ss AM/PM.
SearchIntervalInSeconds #searchinterval Período de tiempo para la regla de

alertas, con formato HH:mm:ss.
SearchIntervalStartTimeUtc #searchintervalstarttimeutc Hora de inicio de la consulta en hora

UTC, con formato mm/dd/aaaa
HH:mm:ss AM/PM.
SearchQuery #searchquery Consulta de búsqueda de registros

utilizada por la regla de alerta.
SearchResults "IncludeSearchResults": true Los registros devueltos por la consulta

en forma de una tabla JSON, limitados
a los primeros 1000 registros. Se
agrega "IncludeSearchResults": true en
una definición personalizada de
webhook de JSON como una
propiedad de nivel superior.
Dimensiones "IncludeDimensions": true Combinaciones de valores de

dimensiones que desencadenaron esa
alerta como una sección JSON. Se
agrega "IncludeDimensions": true en
una definición personalizada de
webhook de JSON como una
propiedad de nivel superior.
AlertType #alerttype El tipo de regla de alertas de registro

configurada, bien como Unidades
métricas o como Número de
resultados.
WorkspaceID #workspaceid Identificador del área de trabajo de

Log Analytics.
Identificador de la aplicación #applicationid Identificador de la aplicación

Subscription ID #subscriptionid Identificador de la suscripción a Azure

usada.
NOTE
Los vínculos proporcionados pasan parámetros como SearchQuery, Search Interval StartTime y Search Interval End time
de la dirección URL a Azure Portal o a la API.
Por ejemplo, podría especificar la siguiente carga personalizada que incluye un único parámetro denominado
text. El servicio al que llama este webhook espera este parámetro.
{
"text":"#alertrulename fired with #searchresultcount over threshold of #thresholdvalue."
}
Esta carga de ejemplo se resuelve en algo similar a lo siguiente al enviarse al webhook:
{
"text":"My Alert Rule fired with 18 records over threshold of 10 ."
}
Como todas las variables de un webhook personalizado deben especificarse dentro de un contenedor JSON,
como "#searchinterval", el webhook resultante también tendrá datos de variable dentro de contenedores, como
"00:05:00".
Para incluir resultados de búsqueda en una carga personalizada, asegúrese de que el parámetro
IncludeSearchResults se establece como una propiedad de nivel superior en la carga de JSON.
Cargas de ejemplo
En esta sección se muestran cargas de ejemplo para los webhooks de alertas de registro. Estas cargas incluyen
ejemplos en los que la carga es estándar y otros en los que es personalizada.
Webhook estándar para alertas de registro
En ambos ejemplos se incluye una carga ficticia con solo dos columnas y dos filas.
Alerta de registro para Log Analytics
La carga de ejemplo siguiente corresponde a una acción de webhook estándar sin una opción JSON
personalizada, que se usa para las alertas basadas en Log Analytics:
{
"SubscriptionId": "12345a-1234b-123c-123d-12345678e",
"AlertRuleName": "AcmeRule",
"SearchQuery": "Perf | where ObjectName == \"Processor\" and CounterName == \"% Processor Time\" |
summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer",
"SearchIntervalStartTimeUtc": "2018-03-26T08:10:40Z",
"SearchIntervalEndtimeUtc": "2018-03-26T09:10:40Z",
"AlertThresholdOperator": "Greater Than",
"AlertThresholdValue": 0,
"ResultCount": 2,
"SearchIntervalInSeconds": 3600,
"LinkToSearchResults": "https://portal.azure.com/#Analyticsblade/search/index?
_timeInterval.intervalEnd=2018-03-26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",
"LinkToFilteredSearchResultsUI": "https://portal.azure.com/#Analyticsblade/search/index?
"LinkToSearchResultsAPI": "https://api.loganalytics.io/v1/workspaces/workspaceID/query?
query=Heartbeat&timespan=2020-05-07T18%3a11%3a51.0000000Z%2f2020-05-07T18%3a16%3a51.0000000Z",
"LinkToFilteredSearchResultsAPI": "https://api.loganalytics.io/v1/workspaces/workspaceID/query?
"Description": "log alert rule",
"Severity": "Warning",
"AffectedConfigurationItems": [
"INC-Gen2Alert"
],
"Dimensions": [
{
"name": "Computer",
"value": "INC-Gen2Alert"
}
],
"SearchResult": {
"tables": [
{
"name": "PrimaryResult",
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "TimeGenerated",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
]
},
"WorkspaceId": "12345a-1234b-123c-123d-12345678e",
"AlertType": "Metric measurement"
}
NOTE
El valor del campo "Severity" puede cambiar si ha cambiado la preferencia de API para las alertas de registro en Log
Analytics.
Alerta de registro para Application Insights

La carga de ejemplo siguiente corresponde a un webhook estándar sin una opción JSON personalizada, que se
usa para alertas de registro basadas en Application Insights:
{
"schemaId": "Microsoft.Insights/LogAlert",
"data": {
"SubscriptionId": "12345a-1234b-123c-123d-12345678e",
"AlertRuleName": "AcmeRule",
"SearchQuery": "requests | where resultCode == \"500\" | summarize AggregatedValue = Count by
bin(Timestamp, 5m), IP",
"SearchIntervalStartTimeUtc": "2018-03-26T08:10:40Z",
"SearchIntervalEndtimeUtc": "2018-03-26T09:10:40Z",
"AlertThresholdOperator": "Greater Than",
"AlertThresholdValue": 0,
"ResultCount": 2,
"SearchIntervalInSeconds": 3600,
"LinkToSearchResults": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-123c-
123d-12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-
26T09%3a10%3a40.0000000Z&_timeInterval.intervalDuration=3600&q=Usage",
"LinkToFilteredSearchResultsUI": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-
1234b-123c-123d-12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-
"LinkToSearchResultsAPI":
"https://api.applicationinsights.io/v1/apps/0MyAppId0/metrics/requests/count",
"LinkToFilteredSearchResultsAPI":
"Description": null,
"Severity": "3",
"Dimensions": [
{
"name": "IP",
"value": "1.1.1.1"
}
],
"SearchResult": {
"tables": [
{
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Id",
"type": "string"
},
{
"name": "Timestamp",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
]
},
"ApplicationId": "123123f0-01d3-12ab-123f-abc1ab01c0a1",
}
}
Alerta de registro con carga de JSON personalizada

Por ejemplo, para crear una carga personalizada que solo incluya el nombre de la alerta y los resultados de la
búsqueda, puede usar lo siguiente:
{
"alertname":"#alertrulename",
"IncludeSearchResults":true
}
A continuación se muestra una carga de ejemplo que corresponde a una acción de webhook personalizada para
cualquier alerta de registro:
{
"alertname":"AcmeRule","IncludeSearchResults":true,
"SearchResults":
{
"tables":[
{"name":"PrimaryResult","columns":
[
{"name":"$table","type":"string"},
{"name":"Id","type":"string"},
{"name":"TimeGenerated","type":"datetime"}
],
"rows":
[
["Fabrikam","33446677a","2018-02-02T15:03:12.18Z"],
["Contoso","33445566b","2018-02-02T15:16:53.932Z"]
]
}
]
}
}
Pasos siguientes
Más información sobre las alertas de registro en las alertas de Azure.
Aprenda a administrar alertas de registro en Azure.
Cree y administre grupos de acciones en Azure.
Solución de problemas de alertas de registro en
Azure Monitor
En este artículo se muestra cómo solucionar problemas habituales con las alertas de registro en Azure Monitor.
Además, se proporcionan soluciones a los problemas comunes sobre la funcionalidad y la configuración de las
alertas de registro.
El término alertas de registro describe las reglas que se desencadenan en función de una consulta de registros en
un área de trabajo de Azure Log Analytics o en Azure Application Insights. Obtenga más información acerca de la
funcionalidad, la terminología y los tipos en Alertas de registro en Azure Monitor.
NOTE
En este artículo no se tienen en cuenta los casos en que Azure Portal muestra una regla de alertas desencadenada y no se
realiza una notificación a través de un grupo de acciones asociado. Para estos casos, consulte los detalles de Crear y
administrar grupos de acciones en Azure Portal.
No se activó la alerta de registro

Estas son algunas causas habituales por las que el estado de una regla de alerta de registro en Azure Monitor
configurada no se muestra como desencadenada cuando se espera.
Tiempo de ingesta de datos para registros
La alerta de registro ejecuta periódicamente la consulta basada en Log Analytics o Application Insights. Dado que
Azure Monitor procesa muchos terabytes de datos de miles de clientes desde diferentes orígenes en todo el
mundo, el servicio es susceptible de sufrir retrasos variables. Para obtener más información, consulte Tiempo de la
ingesta de datos de registro en Azure Monitor.
Para mitigar los retrasos, el sistema espera y vuelve a intentar la consulta de alerta varias veces si detecta que aún
no se han ingerido los datos necesarios. El sistema tiene un tiempo de espera establecido que aumenta
exponencialmente. La alerta de registro solo se desencadena una vez que los datos están disponibles, por lo que el
retraso puede deberse a una ingesta de datos de registro lenta.
Período de tiempo configurado incorrectamente
Como se describe en el artículo sobre la terminología para alertas de registro, el período de tiempo que se indica
en la configuración especifica el intervalo de tiempo para la consulta. La consulta devuelve solo los registros que
se crearon dentro de este intervalo.
El período restringe los datos capturados para una consulta de registros, con el fin de evitar abusos, y evita todos
los comandos de tiempo (como ago ) utilizados en la consulta de registros. Por ejemplo, si el período se establece
en 60 minutos, y la consulta se ejecuta a la 1:15 p. m., los registros creados entre las 12:15 p. m. y la 1:15 p. m. son
los únicos que se usan para la consulta de registros. Si la consulta de registros usa un comando de tiempo como
ago (1d) , seguirá utilizando solo los datos entre las 12:15 p. m. y la 1:15 p. m., ya que el período está establecido
en ese intervalo.
Compruebe que el período de tiempo en la configuración coincida con la consulta. En el ejemplo anterior, si la
consulta de registros utiliza ago (1d) con el marcador verde, el período de tiempo debe establecerse en 24 horas
o 1440 minutos (como se indica en rojo). Esta configuración garantiza que la consulta se ejecute según lo previsto.
Se ha establecido la opción Suprimir alertas
Como se describe en el paso 8 del artículo sobre cómo crear una regla de alerta de registro en Azure Portal, las
alertas de registro proporcionan una opción Suprimir aler tas destinada a suprimir las acciones de
desencadenamiento y notificación durante un período de tiempo configurado. Como resultado, puede parecerle
que una alerta no se desencadena. De hecho, se ha desencadenado, pero se ha suprimido.
Regla de alertas de unidades métricas
Las alertas de registro de unidades métricas constituyen un subtipo de alertas de registro que tienen
funcionalidades especiales y una sintaxis de consulta de alerta restringida. Una regla para una alerta de registro de
unidades métricas requiere que el resultado de la consulta sea una serie temporal métrica. Es decir, el resultado es
una tabla con períodos de tiempo distintos, de igual tamaño, junto con los valores agregados correspondientes.
Puede optar por tener variables adicionales en la tabla junto con AggregatedValue . Estas variables se pueden
usar para ordenar la tabla.
Por ejemplo, suponga que se ha configurado una regla para una alerta de registro de unidades métricas como:
Consulta de search *| summarize AggregatedValue = count() by $table, bin(timestamp, 1h)
Período de tiempo de 6 horas
Umbral de 50
Lógica de alerta de tres infracciones consecutivas
Aggregate Upon establecido en $table
Dado que el comando incluye summarize ... by (resumir … por) y se han proporcionado dos variables
(timestamp y $table ), el sistema elegirá $table para Aggregate Upon . El sistema ordena la tabla de resultados
por el campo $table , como se muestra en la captura de pantalla siguiente. A continuación, examina las distintas
instancias de AggregatedValue para cada tipo de tabla (como availabilityResults ) para ver si se han producido
tres o más infracciones consecutivas.
Dado que Aggregate Upon está definido en $table , los datos se ordenan en una columna $table (se indica en
rojo). A continuación, se agrupan y buscan los tipos de campo Aggregate Upon .
Por ejemplo, para $table , los valores de availabilityResults se considerarán un trazado o una entidad (se indica
en naranja). En el trazado o la entidad de este valor, el servicio de alerta busca tres infracciones consecutivas (se
indican en verde). Las infracciones desencadenan una alerta para el valor de la tabla availabilityResults .
De forma similar, si se producen tres infracciones consecutivas para cualquier otro valor de $table , se
desencadena otra notificación de alerta para el mismo fin. El servicio de alertas ordena automáticamente los
valores en un trazado o una entidad (se indica en naranja) por tiempo.
Ahora supongamos que la regla de la alerta de registro de unidades métricas se modificó y que la consulta era
search *| summarize AggregatedValue = count() by bin(timestamp, 1h) . El resto de la configuración sigue siendo la
misma que antes, incluida la lógica de alerta de las tres infracciones consecutivas. En este caso, la opción de
Aggregate Upon será timestamp de forma predeterminada. Solo se proporciona un valor en la consulta de
summarize... by (es decir, timestamp ). Al igual que en el ejemplo anterior, el resultado al final de la ejecución
será el que se muestra en la siguiente ilustración.
Dado que Aggregate Upon está definido en timestamp , los datos se ordenan en una columna timestamp (se
indica en rojo). A continuación, se realiza la agrupación por timestamp . Por ejemplo, los valores de
2018-10-17T06:00:00Z se considerarán un trazado o una entidad (se indica en naranja). En el trazado o la entidad
de este valor, el servicio de alerta no encontrará ninguna infracción consecutiva (ya que cada valor de timestamp
tiene una sola entrada). Por tanto, la alerta nunca se desencadenará. En este caso, el usuario tiene que:
Agregar una variable ficticia o una variable existente (como $table ) para ordenar correctamente con el campo
Aggregate Upon configurado.
Volver a configurar una regla de alerta para usar, en su lugar, la lógica de alerta basada en infracción total .
Alerta de registro activada innecesariamente

Una regla de alertas de registro en Azure Monitor configurada podría desencadenarse inesperadamente al verla
en Alertas de Azure. En las secciones siguientes se describen algunos motivos comunes.
Alerta desencadenada por datos parciales
Log Analytics y Application Insights están sujetos al procesamiento y a retrasos de ingesta. Al ejecutar una
consulta de alerta de registro, es posible que encuentre que no hay datos disponibles o que solo algunos datos
estén disponibles. Para obtener más información, consulte Tiempo de la ingesta de datos de registro en Azure
Monitor.
En función de cómo configure la regla de alertas, puede producirse una activación incorrecta si no hay ningún
dato en los registros, o los datos que hay son parciales, en el momento de la ejecución de la alerta. En tales casos,
se recomienda cambiar la configuración o la consulta de alerta.
Por ejemplo, si la regla de alertas de registro se configura para desencadenarse cuando el número de resultados
de una consulta de Analytics sea menor que 5, la alerta se desencadenará cuando no haya datos (cero registros) o
los resultados sean parciales (un registro). Sin embargo, después del retraso de la ingesta de datos, la misma
consulta con todos los datos podría proporcionar un resultado de 10 registros.
Salida de la consulta de alerta no comprendida
La lógica de las alertas de registros se proporcionan en una consulta de Analytics. La consulta de Analytics puede
usar varias funciones matemáticas y macrodatos. El servicio de alertas ejecuta la consulta a los intervalos
especificados con datos de un período especificado. Este servicio realiza pequeños cambios en la consulta en
función del tipo de alerta. Este cambio puede verse en la sección Consulta que se va a ejecutar en la pantalla
Configurar lógica de señal :
El contenido del cuadro Consulta que se va a ejecutar es lo que ejecuta el servicio de alertas de registro. Si
quiere saber cuál será el resultado de la consulta de alerta antes de crear la alerta,puede ejecutar la consulta
indicada y el intervalo de tiempo a través del portal de Analytics o Analytics API.
La alerta de registro se deshabilitó

En las siguientes secciones se enumeran algunos de los motivos por los que Azure Monitor podría deshabilitar la
regla de alertas de registro.
El recurso donde se creó la alerta ya no existe
Las reglas de alertas de registro creadas en Azure Monitor están destinadas a un recurso específico, como un área
de trabajo de Azure Log Analytics, una aplicación de Azure Application Insights y un recurso de Azure. A
continuación, el servicio de alertas de registro ejecutará una consulta de Analytics proporcionada en la regla para
el destino especificado. No obstante, tras la creación de la regla, los usuarios tienden a eliminarla de Azure, o a
moverla en Azure (el destino de la regla de alertas de registro). Dado que el destino de la regla de alertas ya no es
válido, se produce un error en la ejecución de la regla.
En estos casos, Azure Monitor se deshabilita la alerta de registro y se asegura que no se le facture
innecesariamente si la regla no se puede ejecutar continuamente durante un período cuantificable (por ejemplo,
una semana). Puede averiguar la hora exacta en que Azure Monitor deshabilitó la alerta de registro a través del
registro de actividad de Azure. En el registro de actividad de Azure, se agrega un evento cuando Azure Monitor
deshabilita la regla de alertas de registro.
El siguiente evento de ejemplo del registro de actividad de Azure es para una regla de alertas que se ha
deshabilitado debido a un error continuo.
{
"caller": "Microsoft.Insights/ScheduledQueryRules",
"channels": "Operation",
"claims": {
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
},
"correlationId": "abcdefg-4d12-1234-4256-21233554aff",
"description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing
consistently with the same exception for the past week",
"eventDataId": "f123e07-bf45-1234-4565-123a123455b",
"eventName": {
"value": "",
"localizedValue": ""
},
"category": {
"value": "Administrative",
"localizedValue": "Administrative"
},
"eventTimestamp": "2019-03-22T04:18:22.8569543Z",
"id":
"/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRUL
ES/TEST-BAD-ALERTS",
"level": "Informational",
"operationId": "",
"operationName": {
"value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
},
"resourceGroupName": "<Resource Group>",
"resourceProviderName": {
"value": "MICROSOFT.INSIGHTS",
"localizedValue": "Microsoft Insights"
},
"resourceType": {
"value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
"localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
},
"resourceId":
"status": {
"value": "Succeeded",
"localizedValue": "Succeeded"
},
"subStatus": {
"value": "",
"localizedValue": ""
},
"submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
"subscriptionId": "<SubscriptionId>",
"properties": {
"resourceId":
"subscriptionId": "<SubscriptionId>",
"resourceGroup": "<ResourceGroup>",
"eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
"eventTimeStamp": "03/22/2019 04:18:22",
"issueStartTime": "03/22/2019 04:18:22",
"operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
"status": "Succeeded",
"reason": "Alert has been failing consistently with the same exception for the past week"
},
"relatedEvents": []
}
La consulta que se usa en una alerta de registro no es válida
Cada regla de alertas de registro creada en Azure Monitor como parte de su configuración debe especificar una
consulta de Analytics que el servicio de alerta ejecutará periódicamente. Es posible que la consulta de Analytics
tuviera la sintaxis correcta en el momento de crear o actualizar la regla. Pero a veces, durante un período de
tiempo, la consulta proporcionada en la regla de alertas de registro puede desarrollar problemas de sintaxis y
provocar un error en la ejecución de la regla. Algunas razones comunes por las que una consulta de Analytics
proporcionada en una regla de alertas de registro puede desarrollar errores son:
La consulta está escrita para ejecutarse en varios recursos. Uno o varios de los recursos especificados ya no
existen.
La alerta de registro del tipo de unidades métricas configurada tiene una consulta de alerta que no cumple con
las normas de sintaxis.
No ha habido ningún flujo de datos para la plataforma de Analytics. El ejecución de la consulta produce un
error porque no hay ningún dato para la consulta proporcionada.
Los cambios en el lenguaje de consulta incluyen un formato revisado para comandos y funciones. Por lo tanto,
la consulta proporcionada anteriormente en una regla de alertas ya no es válida.
Azure Advisor le advierte acerca de este comportamiento. Se agregó una recomendación para la regla de alertas
de registro específica en Azure Advisor, bajo la categoría de alta disponibilidad con un impacto medio y una
descripción similar a "Reparar la regla de alertas de registro para garantizar la supervisión".
NOTE
Si una consulta de alerta de la regla de alertas de registro no se rectifica después de que Azure Advisor proporcione una
recomendación durante siete días, Azure Monitor deshabilitará la alerta de registro y se asegurará de que no le facturen
innecesariamente cuando la regla no pueda ejecutarse continuamente durante un período cuantificable (siete días). Para
averiguar la hora exacta en que Azure Monitor deshabilitó la regla de alertas de registro, puede buscar un evento en el
registro de actividad de Azure.
Se alcanzó la cuota de la regla de alerta

El número de reglas de alertas de búsqueda de registros por suscripción y recurso está sujeto a los límites de
cuota descritos en este artículo.
Pasos recomendados
Si ha alcanzado el límite de cuota, los siguientes pasos pueden ayudar a resolver el problema.
1. Intente eliminar o deshabilitar las reglas de alertas de búsqueda de registros que ya no se usan.
2. Si necesita aumentar el límite de cuota, abra una solicitud de soporte técnico y proporcione la siguiente
información:
Los identificadores de suscripción para los que tiene que aumentar los límites de cuota.
Motivo de aumento de cuota
Tipo de recurso para el que se va a aumentar la cuota: Log Analytics , Application Insights , etc.
Límite de cuota solicitado
Para comprobar el uso actual de las nuevas reglas de alertas de registro
Desde Azure Portal
1. Abra la pantalla Alertas y haga clic en Administrar reglas de alertas.
2. Filtre la suscripción correspondiente mediante el control desplegable Suscripción.
3. Asegúrese de NO filtrar por un grupo de recursos, tipo de recurso o recurso específico.
4. En el control desplegable Tipo de señal, seleccione "Búsqueda de registros".
5. Compruebe que el control desplegable Estado está establecido en "Habilitado".
6. El número total de reglas de alertas de búsqueda de registros se mostrará encima de la lista de reglas.
Desde la API
PowerShell: Get-AzScheduledQueryRule
API REST: Lista por suscripción
Pasos siguientes
Más información sobre las alertas de registro en Azure.
Crear, ver y administrar las alertas del registro de
actividad mediante Azure Monitor
Las alertas del registro de actividad son alertas que se activan cuando un nuevo evento del registro de
actividad cumple las condiciones especificadas en la alerta.
Estas alertas son recursos de Azure, por lo que pueden crearse con una plantilla de Azure Resource Manager.
También se pueden crear, actualizar o eliminar en Azure Portal. Normalmente es necesario crear alertas del
registro de actividad para recibir una notificación si se producen cambios específicos en los recursos de la
suscripción de Azure. Las alertas a menudo se limitan a grupos de recursos o recursos determinados. Por
ejemplo, es posible que quiera recibir una notificación cuando se elimine cualquier máquina virtual del grupo
de recursos de ejemplo myProductionResourceGroup . O bien, podría querer recibir una notificación si se
asigna algún rol nuevo a un usuario de la suscripción.
IMPORTANT
No se pueden crear alertas en la notificación de Service Health a través de la interfaz para la creación de alertas del
registro de actividad. Para obtener más información acerca de cómo crear y usar las notificaciones de Service Health,
consulte Receive activity log alerts on service health notifications (Recibir alertas del registro de actividad con las
notificaciones de Service Health).
Cuando cree reglas de alertas, asegúrese de lo siguiente:

La suscripción del ámbito no es diferente de la suscripción donde se creó la alerta.
La alerta se configurará según los siguientes tipos de criterios: nivel, estado, autor de la llamada, grupo de
recursos, id. del recurso o categoría de eventos del tipo de recurso.
No hay condición "anyOf" o condiciones anidadas en la configuración de alertas JSON. Básicamente, solo
se permite una condición "allOf" sin más condiciones "allOf" o "anyOf".
Cuando la categoría es "administrativo", debe especificar al menos uno de los criterios anteriores en la
alerta. No puede crear una alerta que se active cada vez que se crea un evento en los registros de
actividad.
Azure portal
Puede usar Azure Portal para crear y modificar las reglas de alertas del registro de actividad. Asimismo, se
integra la experiencia con el registro de actividad de Azure para garantizar la creación de alertas sin
problemas para eventos específicos de interés.
Crear con Azure Portal
Use el siguiente procedimiento.
1. En Azure Portal, seleccione Super visar > Aler tas .
2. Seleccione Nueva regla de aler tas en la esquina superior izquierda de la ventana Aler tas .
Aparece la ventana Crear regla .
3. En Definir condición de aler tas , proporcione la siguiente información y haga clic en Hecho :
Destino de la aler ta: Para ver y seleccionar el destino de la nueva alerta, use Filtrar por
suscripción / Filtrar por tipo de recurso . Seleccione el recurso o grupo de recursos de la
lista que se muestra.
NOTE
Puede seleccionar solo el recurso de seguimiento de Azure Resource Manager, el grupo de recursos o
una suscripción completa de una señal del registro de actividad.
Vista de ejemplo de la aler ta de destino

En Criterios de destino , seleccione Agregar criterios . Se muestran todas las señales
disponibles del destino, que incluyen las de varias categorías del registro de actividad . El
nombre de la categoría se agrega al nombre del ser vicio de super visión .
Seleccione la señal de la lista que se muestra y que corresponde a varias operaciones posibles
para el tipo Registro de actividad .
Puede seleccionar la escala de tiempo del historial de registro y la lógica de la alerta
correspondiente a esta señal de destino:
Pantalla para agregar criterios
NOTE
Para que las reglas sean de alta calidad y efectivas, pedimos que se añada al menos una condición más
a las reglas con la señal "todo administrativo". Como parte de la definición de la alerta, debe rellenar
una de las listas desplegables: "Nivel de evento", "Estado" o "Iniciado por" y así la regla será más
específica.
Hora del historial : los eventos disponibles para la operación seleccionada se pueden
trazar en las últimas 6, 12 o 24 horas o durante la última semana.
Lógica de aler ta :
Nivel de evento : Nivel de gravedad del evento: Detallado, Informativo, Advertencia,
Error o Crítico.
Estado : Estado del evento: Iniciado o Erróneo o Correcto.
Evento iniciado por : También se denomina "autor de la llamada". La dirección de
correo electrónico o el identificador de Azure Active Directory del usuario que realizó
la operación.
Este gráfico de señal de ejemplo tiene la lógica de alerta aplicada:
4. En la opción que permite definir los detalles de las aler tas , proporcione los datos siguientes:
Nombre de la regla de aler tas : El nombre de la nueva regla de alertas.
Descripción : La descripción de la nueva regla de alertas.
Guardar la aler ta en el grupo de recursos : Seleccione el grupo de recursos donde quiere
guardar esta nueva regla.
5. En el grupo de acciones , en el menú desplegable, especifique el grupo de acciones que quiere
asignar a esta nueva regla de alertas. O bien, cree un nuevo grupo de acción y asígneselo a la nueva
regla. Para crear un nuevo grupo, seleccione + Nuevo grupo .
6. Para habilitar las reglas después de crearlas, seleccione Sí en la opción Habilitar regla tras la
creación .
7. Seleccione Crear regla de aler tas .
Se crea la nueva regla de alertas del registro de actividad y aparece un mensaje de confirmación en la
esquina superior derecha de la ventana.
Puede habilitar, deshabilitar, editar o eliminar una regla. Obtenga más información sobre cómo
administrar las reglas del registro de actividad.
Una simple analogía para comprender las condiciones en las que se pueden crear reglas de alertas en el
registro de actividad es explorar o filtrar eventos a través del Registro de actividad en Azure Portal. En la
pantalla de Azure Monitor : registro de actividad se puede filtrar o buscar un evento necesario y crear
una alerta mediante el botón Agregar aler ta del registro de actividad . A continuación, siga los pasos 4 a
7 tal como se mostró anteriormente.
Visualización y administración en Azure Portal

1. En Azure Portal, seleccione Super visar > Aler tas . Seleccione Administrar reglas de aler tas en la
esquina superior izquierda de la ventana.
Aparece la lista de reglas disponibles.

2. Busque la regla del registro de actividad que quiera modificar.
Puede usar los filtros disponibles: Suscripción, Grupo de recursos, Recursos, Tipo de señal o Estado
para buscar la regla de actividad que quiera editar.
NOTE
Recuerde que solo puede editar las secciones Descripción , Criterios de destino y Grupos de acción .
3. Seleccione la regla y haga doble clic para editar las opciones de la misma. Realice los cambios
necesarios y seleccione Guardar .
4. Puede habilitar, deshabilitar, editar o eliminar una regla. Seleccione la opción adecuada en la parte
superior de la ventana, después de seleccionar la regla tal como se detalla en el paso 2.

Para crear una regla de alerta del registro de actividad mediante una plantilla de Azure Resource Manager,
cree un recurso del tipo microsoft.insights/activityLogAlerts . A continuación, rellene todas las propiedades
relacionadas. A continuación, se muestra una plantilla que crea una regla de alerta del registro de actividad:
{
"parameters": {
"activityLogAlertName": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Activity log alert."
}
},
"activityLogAlertEnabled": {
"type": "bool",
"metadata": {
"description": "Indicates whether or not the alert is enabled."
}
},
"actionGroupResourceId": {
"type": "string",
"metadata": {
"description": "Resource Id for the Action group."
}
}
},
"resources": [
{
"type": "Microsoft.Insights/activityLogAlerts",
"apiVersion": "2017-04-01",
"name": "[parameters('activityLogAlertName')]",
"properties": {
"enabled": "[parameters('activityLogAlertEnabled')]",
"scopes": [
"[subscription().id]"
],
"condition": {
"allOf": [
{
"field": "category",
"equals": "Administrative"
},
{
"field": "operationName",
"equals": "Microsoft.Resources/deployments/write"
},
{
"field": "resourceType",
"equals": "Microsoft.Resources/deployments"
}
]
},
"actions": {
"actionGroups":
[
{
"actionGroupId": "[parameters('actionGroupResourceId')]"
}
]
}
}
}
]
}
El ejemplo JSON anterior se puede guardar, por ejemplo, como sampleActivityLogAlert.json a los efectos de
este tutorial, y puede implementarse con Azure Resource Manager en Azure Portal.
NOTE
Tenga en cuenta que las alertas del registro de actividad de nivel más alto se pueden definir como suscripción. Lo que
significa que no hay opción para definir la alerta en un par de suscripciones, por lo tanto, la definición debe ser una
alerta por suscripción.
Los campos siguientes son las opciones que puede usar en la plantilla de Azure Resource Manager para los
campos de condiciones: Observe que "Resource Health", "Advisor" y "Service Health" tienen campos de
propiedades adicionales para sus campos especiales.
1. resourceId: el identificador del recurso afectado en el evento del registro de actividad en el que se debe
generar la alerta.
2. category: categoría del evento del registro de actividad. Por ejemplo: Administrative, ServiceHealth,
ResourceHealth, Autoscale, Security, Recommendation, Policy.
3. caller: dirección de correo electrónico o el identificador de Azure Active Directory del usuario que realizó la
operación del evento del registro de actividad.
4. level: nivel de la actividad del evento del registro de actividad en el que se debe generar la alerta. Por
ejemplo: Critical, Error, Warning, Informational, Verbose.
5. operationName: nombre de la operación en el evento del registro de actividad. Por ejemplo:
Microsoft.Resources/deployments/write
6. resourceGroup: nombre del grupo de recursos del recurso afectado en el evento del registro de actividad.
7. resourceProvider: explicación de tipos y proveedor de recursos de Azure. Para obtener una lista que asigna
proveedores de recursos con servicios de Azure, consulte Proveedores de recursos para servicios de
Azure.
8. status: cadena que describe el estado de la operación en el evento de actividad. Por ejemplo: Started, In
Progress, Succeeded, Failed, Active, Resolved
9. subStatus: Normalmente el código de estado HTTP de la llamada REST correspondiente, pero también
puede incluir otras cadenas que describen un subestado. Por ejemplo: Correcto (código de estado HTTP:
200), Creado (código de estado HTTP: 201), Aceptado (código de estado HTTP: 202), Sin contenido (código
de estado HTTP: 204), Solicitud incorrecta (código de estado HTTP: 400), No encontrado (código de estado
HTTP): 404), Conflicto (código de estado HTTP: 409), Error interno del servidor (código de estado HTTP:
500), Servicio no disponible (código de estado HTTP: Tiempo de espera agotado para la puerta de enlace
(código de estado HTTP: 503) 504).
10. resourceType: tipo de recurso que se vio afectado por el evento. Por ejemplo:
Microsoft.Resources/deployments
Por ejemplo:
"condition": {
"allOf": [
{
"field": "category",
"equals": "Administrative"
},
{
"field": "resourceType",
"equals": "Microsoft.Resources/deployments"
}
]
}
Puede encontrar más información sobre los campos del registro de actividad aquí.
NOTE
Una regla de alertas nueva del registro de actividad puede tardar hasta 5 minutos en activarse.
API DE REST
La API de alertas del registro de actividad de Azure Monitor es una API de REST. Es totalmente compatible con
la API de REST de Azure Resource Manager. Asimismo, se puede usar con PowerShell mediante el cmdlet de
Resource Manager o la CLI de Azure.
PowerShell
NOTE
Implementación de la plantilla de Resource Manager con PowerShell

Para usar PowerShell para implementar la plantilla de ejemplo de Resource Manager que se muestra en la
sección anterior Plantilla de Azure Resource Manager, use el siguiente comando:
New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile sampleActivityLogAlert.json -

TemplateParameterFile sampleActivityLogAlert.parameters.json
Tenga en cuenta que sampleActivityLogAlert.parameters.json tiene los valores proporcionados para los
parámetros que se necesitan para crear las reglas de alertas.
Usar los cmdlets de PowerShell del registro de actividad
Las alertas del registro de actividad tienen cmdlets dedicados de PowerShell disponibles:
Set-AzActivityLogAlert: crea una nueva alerta de registro de actividad o actualiza una alerta de registro de
actividad existente.
Get-AzActivityLogAlert: obtiene uno o más recursos de alerta del registro de actividad.
Enable-AzActivityLogAlert: habilita una alerta de registro de actividad existente y establece sus etiquetas.
Disable-AzActivityLogAlert: deshabilita una alerta de registro de actividad existente y establece sus
etiquetas.
Remove-AzActivityLogAlert: quita una alerta de registro de actividad.
Azure CLI
Los comandos dedicados de la CLI de Azure en el conjunto de comandos az monitor activity-log alert están
disponibles para administrar las reglas de alertas del registro de actividad.
Para crear una nueva regla de alertas del registro de actividad, use los siguientes comandos en este orden:
1. az monitor activity-log alert create: para crear un nuevo recurso de regla de alertas del registro de
actividad.
2. az monitor activity-log alert scope: para agregar el ámbito de la regla de alertas creada del registro de
actividad.
3. az monitor activity-log alert action-group: para agregar un grupo de acciones a la regla de alertas del
registro de actividad.
Para recuperar un recurso de regla de alertas del registro de actividad, puede usar el comando az monitor
activity-log alert show de la CLI de Azure. Asimismo, para ver todos los recursos de regla de alertas del
registro de actividad en un grupo de recursos, use az monitor activity-log alert list. Para quitar los recursos de
regla de alertas del registro de actividad, use el comando az monitor activity-log alert delete de la CLI de
Azure.
Pasos siguientes
Obtenga información acerca del esquema de webhook para los registros de actividad.
Lea la información general sobre los registros de actividad.
Más información sobre los grupos de acciones.
Alertas de registro de actividad
Las alertas del registro de actividad son alertas que se activan cuando un nuevo evento del registro de actividad
cumple las condiciones especificadas en la alerta. Según el orden y el volumen de los eventos registrados en el
registro de actividad de Azure, se activará la regla de alerta. Las regla de alertas del registro de actividad son
recursos de Azure, por lo que pueden crearse con una plantilla de Azure Resource Manager. También se pueden
crear, actualizar o eliminar en Azure Portal. Este artículo presenta los conceptos relativos a las alertas del registro
de actividad. Para más información sobre cómo crear o usar reglas de alertas de registro de actividad, consulte
Creación y administración de alertas del registro de actividad.
NOTE
Por lo general, se crean alertas del registro de actividad para recibir notificaciones cuando:
Se produzcan operaciones específicas en los recursos de la suscripción de Azure, que abarcan normalmente
grupos de recursos o recursos en particular. Por ejemplo, si quiere que le notifiquen cuando se elimine
alguna máquina virtual de myProductionResourceGroup. O, podría querer recibir una notificación si se
asigna algún rol nuevo a un usuario de la suscripción.
Se produce un evento de mantenimiento del servicio. Los eventos de mantenimiento del servicio incluyen la
notificación de incidentes y eventos de mantenimiento que se aplican a recursos de la suscripción.
Una simple analogía para comprender las condiciones en las que se pueden crear reglas de alertas en el registro
de actividad es explorar o filtrar eventos a través del Registro de actividad en Azure Portal. En "Azure Monitor:
registro de actividad" se puede filtrar o buscar un evento necesario y crear una alerta mediante el botón
Agregar aler ta de registro de actividad .
En cualquier caso, una alerta del registro de actividad solo supervisa eventos de la suscripción en la que se ha
creado la alerta.
Puede configurar una alerta del registro de actividad según las propiedades de nivel superior del objeto JSON
de un evento del registro de actividad. Para obtener más información, consulte Categorías del Registro de
actividad. Para más información acerca de los eventos de mantenimiento del servicio, consulte Recibir alertas del
registro de actividad con las notificaciones del servicio.
Las alertas del registro de actividad tienen algunas opciones en común:
Categoría : Administración, Mantenimiento del servicio, Escalado automático, Seguridad, Directiva y
Recomendación.
Ámbito : el recurso individual o conjunto de recursos para el que se define la alerta de registro de actividad.
El ámbito de una alerta de registro de actividad se puede definir en distintos niveles:
Nivel de recurso: por ejemplo, para una máquina virtual concreta
Nivel de grupo de recursos: por ejemplo, todas las máquinas virtuales de un grupo de recursos
específico
Nivel de suscripción: por ejemplo, todas las máquinas virtuales de una suscripción (o) todos los
recursos de una suscripción
Grupo de recursos : de forma predeterminada, la regla de alertas se guarda en el grupo de recursos que
tiene el destino definido en el ámbito. El usuario también puede definir el grupo de recursos donde se debe
almacenar la regla de alertas.
Tipo de recurso : Resource Manager ha definido el espacio de nombres para el destino de la alerta.
Nombre de la operación : Nombre de la operación de Azure Resource Manager utilizado por el control de
acceso basado en rol. No se pueden usar operaciones no registradas con Azure Resource Manager en una
regla de alerta de registro de actividad.
Nivel : el nivel de gravedad del evento (informativo, advertencia, error o crítico).
Estado : el estado del evento, normalmente Iniciado, Error o Correcto.
Evento iniciado por : También se denomina "llamador". La dirección de correo electrónico o el identificador
de Azure Active Directory del usuario que realizó la operación.
NOTE
En una suscripción se pueden crear hasta 100 reglas de alertas para una actividad del ámbito en el nivel: de un único
recurso, de todos los recursos de un grupo de recursos (o) de suscripción completa.
Cuando se activa una alerta del registro de actividad, usa un grupo de acciones para generar acciones o
notificaciones. Un grupo de acciones es un conjunto reutilizable de destinatarios de notificación, como
direcciones de correo electrónico, direcciones URL del webhook o números de teléfono para SMS. Se puede
hacer referencia a los receptores desde varias alertas para centralizar y agrupar los canales de notificación. Al
definir la alerta del registro de actividad, tiene dos opciones. Puede:
Usar un grupo de acciones existente en la alerta del registro de actividad.
Crear un nuevo grupo de acciones.
Para más información sobre los grupos de acciones, consulte Creación y administración de grupos de acciones
en Azure Portal.
Pasos siguientes
Obtener una Introducción a las alertas.
Obtenga información sobre la creación y modificación de las alertas del registro de actividad.
Webhooks para alertas del registro de actividad de
Azure
Como parte de la definición de un grupo de acciones, se pueden configurar puntos de conexión de webhook
para recibir notificaciones de alertas del registro de actividad. Los webhooks permiten enrutar estas
notificaciones a otros sistemas para su procesamiento posterior o acciones personalizadas. Este artículo
muestra el aspecto de la carga útil para HTTP POST a un webhook.
Para más información sobre las alertas del registro de actividad, consulte cómo crear alertas del registro de
actividad de Azure.
Para obtener información sobre los grupos de acciones, consulte cómo crear grupos de acciones.
NOTE
También puede usar el esquema de alerta común, que le ofrece la ventaja de tener una carga útil de alerta única y
extensible en todos los servicios de alerta Azure Monitor, para las integraciones de su webhook. Obtenga más
información sobre las definiciones de esquemas de alertas comunes.
Autenticación del webhook

El webhook puede usar opcionalmente autorización basada en token para la autenticación. El identificador URI
del webhook se guarda con un identificador de token, por ejemplo,
https://mysamplealert/webcallback?tokenid=sometokenid&someparameter=somevalue .
Esquema de carga
La carga útil JSON incluida en la operación POST difiere según el campo data.context.activityLog.eventSource de
la carga útil.
Comunes
{
"schemaId": "Microsoft.Insights/activityLogs",
"data": {
"context": {
"activityLog": {
"correlationId": "6ac88262-43be-4adf-a11c-bd2179852898",
"eventSource": "Administrative",
"eventTimestamp": "2017-03-29T15:43:08.0019532+00:00",
"eventDataId": "8195a56a-85de-4663-943e-1a2bf401ad94",
"operationName": "Microsoft.Insights/actionGroups/write",
"operationId": "6ac88262-43be-4adf-a11c-bd2179852898",
"status": "Started",
"subStatus": "",
"subscriptionId": "52c65f65-0518-4d37-9719-7dbbfc68c57a",
"submissionTimestamp": "2017-03-29T15:43:20.3863637+00:00",
...
}
},
"properties": {}
}
}
Administrativo
{
"data": {
"context": {
"activityLog": {
"authorization": {
"action": "Microsoft.Insights/actionGroups/write",
"scope": "/subscriptions/52c65f65-0518-4d37-9719-7dbbfc68c57b/resourceGroups/CONTOSO-
TEST/providers/Microsoft.Insights/actionGroups/IncidentActions"
},
"claims": "{...}",
"caller": "me@contoso.com",
"description": "",
"httpRequest": "{...}",
"resourceId": "/subscriptions/52c65f65-0518-4d37-9719-7dbbfc68c57b/resourceGroups/CONTOSO-
TEST/providers/Microsoft.Insights/actionGroups/IncidentActions",
"resourceGroupName": "CONTOSO-TEST",
"resourceProviderName": "Microsoft.Insights",
"resourceType": "Microsoft.Insights/actionGroups"
}
},
"properties": {}
}
}
Seguridad
{
"schemaId":"Microsoft.Insights/activityLogs",
"data":{"status":"Activated",
"context":{
"activityLog":{
"channels":"Operation",
"correlationId":"2518408115673929999",
"description":"Failed SSH brute force attack. Failed brute force attacks were detected from
the following attackers: [\"IP Address: 01.02.03.04\"]. Attackers were trying to access the host with the
following user names: [\"root\"].",
"eventSource":"Security",
"eventTimestamp":"2017-06-25T19:00:32.607+00:00",
"eventDataId":"Sec-07f2-4d74-aaf0-03d2f53d5a33",
"level":"Informational",
"operationName":"Microsoft.Security/locations/alerts/activate/action",
"operationId":"Sec-07f2-4d74-aaf0-03d2f53d5a33",
"properties":{
"attackers":"[\"IP Address: 01.02.03.04\"]",
"numberOfFailedAuthenticationAttemptsToHost":"456",
"accountsUsedOnFailedSignInToHostAttempts":"[\"root\"]",
"wasSSHSessionInitiated":"No","endTimeUTC":"06/25/2017 19:59:39",
"actionTaken":"Detected",
"resourceType":"Virtual Machine",
"severity":"Medium",
"compromisedEntity":"LinuxVM1",
"remediationSteps":"[In case this is an Azure virtual machine, add the source IP to NSG
block list for 24 hours (see https://azure.microsoft.com/documentation/articles/virtual-networks-nsg/)]",
"attackedResourceType":"Virtual Machine"
},
"resourceId":"/subscriptions/12345-5645-123a-9867-
123b45a6789/resourceGroups/contoso/providers/Microsoft.Security/locations/centralus/alerts/Sec-07f2-4d74-
aaf0-03d2f53d5a33",
"resourceGroupName":"contoso",
"resourceProviderName":"Microsoft.Security",
"status":"Active",
"subscriptionId":"12345-5645-123a-9867-123b45a6789",
"submissionTimestamp":"2017-06-25T20:23:04.9743772+00:00",
"resourceType":"MICROSOFT.SECURITY/LOCATIONS/ALERTS"
}
},
"properties":{}
}
}
Recomendación
{
"schemaId":"Microsoft.Insights/activityLogs",
"data":{
"status":"Activated",
"context":{
"activityLog":{
"channels":"Operation",
"claims":"
{\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress\":\"Microsoft.Advisor\"}",
"caller":"Microsoft.Advisor",
"correlationId":"123b4c54-11bb-3d65-89f1-0678da7891bd",
"description":"A new recommendation is available.",
"eventSource":"Recommendation",
"eventTimestamp":"2017-06-29T13:52:33.2742943+00:00",
"httpRequest":"{\"clientIpAddress\":\"0.0.0.0\"}",
"eventDataId":"1bf234ef-e45f-4567-8bba-fb9b0ee1dbcb",
"level":"Informational",
"operationName":"Microsoft.Advisor/recommendations/available/action",
"properties":{
"recommendationSchemaVersion":"1.0",
"recommendationCategory":"HighAvailability",
"recommendationImpact":"Medium",
"recommendationName":"Enable Soft Delete to protect your blob data",
"recommendationResourceLink":"https://portal.azure.com/#blade/Microsoft_Azure_Expert/RecommendationListBlad
e/recommendationTypeId/12dbf883-5e4b-4f56-7da8-123b45c4b6e6",
"recommendationType":"12dbf883-5e4b-4f56-7da8-123b45c4b6e6"
},
"resourceId":"/subscriptions/12345-5645-123a-9867-
123b45a6789/resourceGroups/contoso/providers/microsoft.storage/storageaccounts/contosoStore",
"resourceGroupName":"CONTOSO",
"resourceProviderName":"MICROSOFT.STORAGE",
"status":"Active",
"subStatus":"",
"subscriptionId":"12345-5645-123a-9867-123b45a6789",
"submissionTimestamp":"2017-06-29T13:52:33.2742943+00:00",
"resourceType":"MICROSOFT.STORAGE/STORAGEACCOUNTS"
}
},
"properties":{}
}
}
ServiceHealth
{
"data": {
"context": {
"activityLog": {
"channels": "Admin",
"correlationId": "bbac944f-ddc0-4b4c-aa85-cc7dc5d5c1a6",
"description": "Active: Virtual Machines - Australia East",
"eventSource": "ServiceHealth",
"eventDataId": "6fa98c0f-334a-b066-1934-1a4b3d929856",
"operationName": "Microsoft.ServiceHealth/incident/action",
"operationId": "bbac944f-ddc0-4b4c-aa85-cc7dc5d5c1a6",
"properties": {
"title": "Virtual Machines - Australia East",
"service": "Virtual Machines",
"region": "Australia East",
"communication": "Starting at 02:48 UTC on 18 Oct 2017 you have been identified as a
customer using Virtual Machines in Australia East who may receive errors starting Dv2 Promo and DSv2 Promo
Virtual Machines which are in a stopped "deallocated" or suspended state. Customers can still
provision Dv1 and Dv2 series Virtual Machines or try deploying Virtual Machines in other regions, as a
possible workaround. Engineers have identified a possible fix for the underlying cause, and are exploring
implementation options. The next update will be provided as events warrant.",
"incidentType": "Incident",
"trackingId": "0NIH-U2O",
"impactStartTime": "2017-10-18T02:48:00.0000000Z",
"impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"Australia
East\"}],\"ServiceName\":\"Virtual Machines\"}]",
"defaultLanguageTitle": "Virtual Machines - Australia East",
"defaultLanguageContent": "Starting at 02:48 UTC on 18 Oct 2017 you have been identified as
a customer using Virtual Machines in Australia East who may receive errors starting Dv2 Promo and DSv2
Promo Virtual Machines which are in a stopped "deallocated" or suspended state. Customers can
still provision Dv1 and Dv2 series Virtual Machines or try deploying Virtual Machines in other regions, as
a possible workaround. Engineers have identified a possible fix for the underlying cause, and are exploring
implementation options. The next update will be provided as events warrant.",
"stage": "Active",
"communicationId": "636439673646212912",
"version": "0.1.1"
},
"status": "Active",
"subscriptionId": "45529734-0ed9-4895-a0df-44b59a5a07f9",
"submissionTimestamp": "2017-10-18T23:49:28.7864349+00:00"
}
},
"properties": {}
}
}
Para obtener detalles del esquema específico sobre alertas del registro de actividad de notificaciones de
mantenimiento del servicio, consulte Notificaciones de mantenimiento del servicio. Además, puede obtener
información acerca de cómo configurar notificaciones webhook del estado del servicio con las soluciones de
administración de problemas existentes.
ResourceHealth
{
"data": {
"context": {
"activityLog": {
"channels": "Admin, Operation",
"correlationId": "a1be61fd-37ur-ba05-b827-cb874708babf",
"eventSource": "ResourceHealth",
"eventDataId": "2b37e2d0-7bda-4de7-ur8c6-1447d02265b2",
"operationName": "Microsoft.Resourcehealth/healthevent/Activated/action",
"operationId": "2b37e2d0-7bda-489f-81c6-1447d02265b2",
"properties": {
"title": "Virtual Machine health status changed to unavailable",
"details": "Virtual machine has experienced an unexpected event",
"currentHealthStatus": "Unavailable",
"previousHealthStatus": "Available",
"type": "Downtime",
"cause": "PlatformInitiated"
},
"resourceId": "/subscriptions/<subscription Id>/resourceGroups/<resource
group>/providers/Microsoft.Compute/virtualMachines/<resource name>",
"resourceGroupName": "<resource group>",
"resourceProviderName": "Microsoft.Resourcehealth/healthevent/action",
"status": "Active",
"subscriptionId": "<subscription Id>",
"resourceType": "Microsoft.Compute/virtualMachines"
}
}
}
}
N O M B RE DEL EL EM EN TO DESC RIP C IÓ N
status Usado para alertas de métrica. Siempre se establece en

"activated" para las alertas del registro de actividad.
context Contexto del evento
resourceProviderName Proveedor de recursos del recurso afectado
conditionType Siempre "Event"
name Nombre de la regla de alerta.
id Identificador de recurso de la alerta
description Descripción de la alerta establecida al crear la alerta.
subscriptionId Identificador de suscripción de Azure
timestamp Cuándo generó el evento el servicio de Azure que procesó la

solicitud
resourceId Identificador de recurso del recurso afectado.

resourceGroupName Nombre del grupo de recursos del recurso afectado.
properties Conjunto de pares <Key, Value> (es decir,

Dictionary<String, String> ) que incluye detalles sobre
el evento.
event Elemento que contiene metadatos sobre el evento.
authorization Las propiedades del Control de acceso basado en rol del

evento. Estas propiedades normalmente incluyen la acción,
el rol y el ámbito.
category Categoría del evento. Los valores admitidos incluyen:

Administrative, Alert, Security, ServiceHealth y
Recommendation.
caller Dirección de correo electrónico del usuario que realizó la

operación, la notificación de UPN o la notificación de SPN
basada en la disponibilidad. Puede ser null para ciertas
llamadas del sistema.
correlationId Normalmente, un GUID en formato de cadena. Los eventos

con correlationId pertenecen a la misma acción de mayor
tamaño y suelen compartir un campo correlationId.
eventDescription Descripción de texto estático del evento
eventDataId Identificador único para el evento
eventSource Nombre de la infraestructura o el servicio de Azure que

generó el evento
httpRequest La solicitud normalmente incluye clientRequestId,

clientIpAddress y el método HTTP (por ejemplo, PUT).
level Uno de los valores siguientes: crítico, error, advertencia e

informativo.
operationId Por lo general, un GUID compartido entre los eventos

correspondientes a una sola operación
operationName Nombre de la operación.
properties Propiedades del evento.
status String. Estado de la operación. Entre los valores habituales,

se incluyen Started, In Progress, Succeeded, Failed, Active y
Resolved.
subStatus Normalmente, incluye el código de estado HTTP de la

llamada de REST correspondiente. También podría incluir
otras cadenas que describen un subestado. Los valores de
subestado comunes son Aceptar (código de estado HTTP:
200), Creado (código de estado HTTP: 201), Aceptado
(código de estado HTTP: 202), Sin contenido (código de
estado HTTP: 204), Solicitud incorrecta (código de estado
HTTP: 400), No encontrado (código de estado HTTP): 404),
Conflicto (código de estado HTTP: 409), Error interno del
servidor (código de estado HTTP: 500), Servicio no
disponible (código de estado HTTP: 503), Tiempo de espera
agotado para la puerta de enlace (código de estado HTTP:
504).
Para obtener información del esquema específico en todas las otras alertas del registro de actividad, consulte
Información general sobre el registro de actividad de Azure.
Pasos siguientes
Más información sobre el registro de actividad.
Ejecución de scripts de Azure Automation (runbooks) en alertas de Azure.
Uso de una aplicación lógica para enviar un SMS a través de Twilio desde una alerta de Azure. Este ejemplo
es para alertas de métrica, pero podría modificarse para funcionar con una alerta del registro de actividad.
Uso de una aplicación lógica para enviar un mensaje de Slack desde una alerta de Azure. Este ejemplo es
para alertas de métrica, pero podría modificarse para funcionar con una alerta del registro de actividad.
Uso de una aplicación lógica para enviar un mensaje a una cola de Azure desde una alerta de Azure. Este
ejemplo es para alertas de métrica, pero podría modificarse para funcionar con una alerta del registro de
actividad.
Visualización de las notificaciones de mantenimiento
del servicio mediante Azure Portal
Las notificaciones de mantenimiento del servicio se publican mediante la infraestructura de Azure en el registro
de actividad de Azure. Las notificaciones contienen información acerca de los recursos en la suscripción. Debido
al volumen posiblemente grande de la información almacenada en el registro de actividad, hay una interfaz de
usuario independiente que facilita la visualización y la configuración de alertas en las notificaciones de
mantenimiento del servicio.
En función de la clase, las notificaciones de mantenimiento del servicio pueden ser meramente informativas o
pueden requerir acciones.
Para obtener más información sobre las distintas clases de notificaciones de mantenimiento del servicio, vea
Propiedades de las notificaciones de Service Health.
Visualización de las notificaciones de mantenimiento del servicio en

Azure Portal
1. En Azure Portal, seleccione Super visión .
Azure Monitor se abre junto con toda la configuración de supervisión y los datos en una sola vista
consolidada. Primero se abre la sección Registro de actividades .
2. Seleccione Aler tas .
3. Seleccione +Agregar aler ta del registro de actividad y configure una alerta para asegurarse de que
recibe las futuras notificaciones del servicio. Para más información, consulte Creación de alertas del
registro de actividad en notificaciones del servicio.
Pasos siguientes
Más información sobre las alertas del registro de actividad.
Creación de alertas del registro de actividad en
notificaciones del servicio mediante Azure Portal
En este artículo se explica cómo usar Azure Portal para configurar las alertas del registro de actividad para las
notificaciones de mantenimiento de un servicio mediante Azure Portal.
Las notificaciones de mantenimiento del servicio se almacenan en el registro de actividad de Azure. Debido al
gran volumen de información almacenada en el registro de actividad, existe una interfaz de usuario
independiente que facilita la visualización y la configuración de alertas en las notificaciones de mantenimiento
del servicio.
Puede recibir una alerta cuando Azure envía notificaciones de estado del servicio a la suscripción de Azure.
Puede configurar la alerta en función de:
La clase de notificación de estado del servicio (problemas de servicio, mantenimiento planificado, avisos de
estado y avisos de seguridad).
La suscripción afectada.
Los servicios afectados.
Las regiones afectadas.
NOTE
Las notificaciones de estado del servicio no envían alertas para los eventos de estado de los recursos.
También puede configurar a quién se debe enviar la alerta:

Seleccione un grupo de acciones existente.
Cree un nuevo grupo de acciones (que puede usarse para futuras alertas).
Para más información sobre los grupos de acciones, consulte Creación y administración de grupos de acciones.
Para obtener información sobre cómo configurar las alertas de notificación de mantenimiento del servicio
mediante plantillas de Azure Resource Manager, consulte Plantillas de Resource Manager.
Ver un vídeo sobre cómo configurar su primera alerta de Azure Service Health
Creación de alertas de Service Health mediante Azure Portal

1. En el portal, seleccione Estado del ser vicio .
2. En la sección Aler tas , seleccione Aler tas de estado .
3. Seleccione Agregar aler ta de Ser vice Health y rellene los campos.
4. Seleccione la suscripción , los ser vicios y las regiones para los cuales quiere recibir alertas.
NOTE
Esta suscripción se usa para guardar la alerta del registro de actividad. El recurso de la alerta se implementa en esta
suscripción y supervisa los eventos en el registro de actividad para dicho recurso.
5. Elija los Tipos de evento para los que quiere recibir alertas: Problemas de servicio, Mantenimiento
planeado, Avisos de estado y Avisos de seguridad.
6. Haga clic en Seleccionar grupo de acciones para elegir un grupo de acciones existente o para crear
un nuevo grupo de acciones. Para obtener más información sobre los grupos de acciones, consulte
Creación y administración de grupos de acciones en Azure Portal.
7. Para definir los detalles de la alerta, escriba un nombre de regla de aler tas y una descripción .
8. Seleccione el grupo de recursos donde quiere guardar la alerta.
En unos minutos, la alerta está activa y comienza a desencadenarse en función de las condiciones especificadas
durante la creación.
Obtenga información acerca de cómo configurar notificaciones de webhook para los sistemas de
administración de problemas existentes. Para obtener información sobre el esquema de webhook para las
alertas del registro de actividad, consulte Webhooks para alertas del registro de actividad de Azure.
Pasos siguientes
Obtenga información sobre los procedimientos recomendados para la configuración de alertas de Azure
Service Health.
Obtenga información sobre cómo configurar notificaciones de inserción móviles de Azure Service Health.
Obtenga información acerca de cómo configurar notificaciones de webhook para los sistemas de
administración de problemas existentes.
Más información sobre la Limitación del número de notificaciones.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo puede recibir alertas.
Reglas de acción (versión preliminar)
Las reglas de acción le ayudan a definir o suprimir acciones en cualquier ámbito de Azure Resource Manager
(suscripción, grupo de recursos o recurso de destino de Azure). Disponen de varios filtros que le ayudan a
reducir el subconjunto específico de instancias de alerta sobre las que quiere actuar.
¿Por qué y cuándo deben usar reglas de acción?

Supresión de alertas
Hay muchos escenarios en los que resulta útil suprimir las notificaciones que generan las alertas. Estos
escenarios van desde la supresión durante una ventana de mantenimiento planeado hasta la supresión
durante las horas no laborables. Por ejemplo, el equipo responsable de ContosoVM desea suprimir las
notificaciones de alerta durante el fin de semana próximo, puesto que ContosoVM está llevando a cabo un
mantenimiento planeado.
Aunque el equipo puede deshabilitar manualmente todas las reglas de alerta configuradas en ContosoVM (y
habilitarlas de nuevo después del mantenimiento), no es un proceso sencillo. Las reglas de acción le permiten
definir la supresión de alertas a escala con la posibilidad de configurar el período de supresión de forma
flexible. En el ejemplo anterior, el equipo puede definir una regla de acción en ContosoVM que suprime todas
las notificaciones de alerta durante el fin de semana.
Acciones a escala
Aunque las reglas de alertas le ayudan a definir el grupo de acciones que se desencadena cuando se genera la
alerta, los clientes a menudo tienden a disponer de un grupo de acciones comunes en su ámbito de
operaciones. Por ejemplo, un equipo responsable del grupo de recursos ContosoRG probablemente definirá
el mismo grupo de acciones para todas las reglas de alerta definidas dentro de ContosoRG .
Las reglas de acción le ayudan a simplificar este proceso. Al definir acciones a escala, se puede desencadenar
un grupo de acciones para cualquier alerta que se genere en el ámbito configurado. En el ejemplo anterior, el
equipo ahora puede definir una regla de acción sobre ContosoRG que desencadenará el mismo grupo de
acciones para todas las alertas generadas dentro de él.
NOTE
Actualmente, las reglas de acción no se aplican a las alertas de Azure Service Health.
Configuración de una regla de acciones

Portal
CLI de Azure
Para acceder a la característica, puede seleccionar Administrar acciones desde la página de inicio de
Aler tas en Azure Monitor. Después, seleccione Reglas de acción (versión preliminar) . Para acceder a las
reglas, seleccione Reglas de acción (versión preliminar) desde el panel de la página de aterrizaje de
alertas.
Seleccione + Nueva regla de acción .
Como alternativa, también puede crear una regla de acción al configurar una regla de alerta.
Ahora verá la página de flujo para crear reglas de acción. Configure los elementos siguientes:
Ámbito
En primer lugar, elija el ámbito (suscripción, grupo de recursos o recurso de destino de Azure). También puede
realizar varias selecciones de una combinación de ámbitos dentro de una sola suscripción.
Criterios de filtro
Además, puede definir filtros para restringirlos a un subconjunto específico de las alertas.
Los filtros disponibles son:
Gravedad : la opción para seleccionar uno o varios niveles de gravedad de alerta. Gravedad = Sev1
significa que la regla de acción es aplicable a todas las alertas con un nivel de gravedad Sev1.
Super visar ser vicio : filtro basado en el servicio de supervisión de origen. Este filtro también tiene varias
selecciones. Por ejemplo, Super visar ser vicio = "Application Insights" significa que la regla de acción
se aplica a todas las alertas basadas en Application Insights.
Tipo de recurso : filtro según un tipo de recurso específico. Este filtro también tiene varias selecciones. Por
ejemplo, Tipo de recurso = "Vir tual Machines" significa que la regla de acción es aplicable a todas las
Id. de regla de aler ta : opción para filtrar por reglas de alertas específicas mediante el identificador de
Resource Manager de la regla de alerta.
Condición del monitor : filtro para las instancias de alerta con la condición de supervisión
Desencadenada o Resuelta .
Descripción : coincidencia regex (expresión regular) que define una coincidencia de cadena con la
descripción, definida como parte de la regla de alerta. Por ejemplo, La descripción contiene "prod "
buscará la coincidencia con todas las alertas que contengan la cadena "prod" en sus descripciones.
Contexto de aler ta (carga) : coincidencia regex que define una coincidencia de cadena con los campos
de contexto de alerta de la carga de una alerta. Por ejemplo, Contexto de aler ta (carga) contiene
"Equipo 01" buscará la coincidencia con todas las alertas cuyas cargas contengan la cadena "Equipo-01".
Estos filtros se aplican junto con otro. Por ejemplo, si define Tipo de recurso = "Virtual Machines" y
"Gravedad" = Sev0 , se filtran todas las alertas con Sev0 en solo sus máquinas virtuales.
Configuración del grupo de acciones o supresiones

A continuación, configure la regla de acción para la supresión de alertas o la compatibilidad con grupos de
acciones. No puede elegir ambos. La configuración actúa en todas las instancias de alerta que coincidan con el
ámbito y los filtros definidos previamente.
Supresión
Si selecciona supresión , configure la duración de la supresión de notificaciones y acciones. Elija una de las
siguientes opciones:
Desde ahora (siempre) : suprime todas las notificaciones de forma indefinida.
A la hora programada : suprime las notificaciones dentro de una duración limitada.
Con periodicidad : suprime las notificaciones de una programación periódica diaria, semanal o mensual.
Grupo de acciones
Si selecciona Grupo de acciones en el botón de alternancia, agregue un grupo de acciones existente o cree
uno nuevo.
NOTE
Puede asociar un solo grupo de acciones a una regla de acción.
Detalles de la regla de acción
Por último, configure los siguientes detalles de la regla de acción:
Nombre
Grupo de recursos en el que se guarda.
Descripción
Escenarios de ejemplo
Escenario 1: Supresión de alertas en función de la gravedad
Contoso quiere suprimir las notificaciones de todas las alertas de Sev4 en todas las máquinas virtuales dentro
de la suscripción ContosoSub cada fin de semana.
Solución: Cree una regla de acción con:
Ámbito = ContosoSub
Filtros
Gravedad = Sev4
Tipo de recurso = Vir tual Machines
Supresión con la periodicidad establecida en semanal y las opciones Sábado y Domingo activadas
Escenario 2: Supresión de alertas basada en el contexto de alerta (carga)
Contoso quiere suprimir las notificaciones en todos los registros de alertas generadas para Equipo 01 en
ContosoSub indefinidamente ya que va a someterse a mantenimiento.
Ámbito = ContosoSub
Filtros
Supervisar servicio = Log Analytics
Contexto de alerta (carga) contiene Equipo 01
Supresión establecida en Desde ahora (siempre)
Escenario 3: Grupo de acciones definido en un grupo de recursos
Contoso ha definido una alerta de métricas en el nivel de suscripción. Pero quiere definir las acciones que se
desencadenan específicamente para las alertas generadas desde el grupo de recursos ContosoRG .
Ámbito = ContosoRG
Sin filtros
Grupo de acciones establecido en ContosoActionGroup
NOTE
Los grupos de acciones definidos dentro de las reglas de acción y las reglas de alertas funcionan de forma
independiente, sin desduplicación. En el escenario descrito anteriormente, si un grupo de acciones se define para la
regla de alerta, se desencadena junto con el grupo de acciones definido en la regla de acción.
Administración de las reglas de acción

Portal
CLI de Azure
Puede ver y administrar las reglas de acción desde la vista de lista:
Desde aquí, puede habilitar, deshabilitar o eliminar reglas de acción a escala si activa la casilla que hay junto a
ellas. Al seleccionar una regla de acción, se abre su página de configuración. La página le ayuda a actualizar la
definición de la regla de acción y a habilitarla o deshabilitarla.
Las alertas de registro creadas con la opción número de resultados generan una sola instancia de alerta con el
resultado de búsqueda completo (que, por ejemplo, podría extenderse a varios equipos). En este escenario, si
una regla de acción usa el filtro Contexto de aler ta (carga) , actuará sobre la instancia de alerta siempre
que haya una coincidencia. En el escenario 2, descrito anteriormente, si los resultados de la búsqueda de la
alerta de registro generada contienen Equipo 01 y Equipo 02 , se suprime toda la notificación. No se ha
generado ninguna notificación para Equipo 02 .
Para usar mejor las alertas de registro con las reglas de acción, cree alertas de registro con la opción unidades
métricas. Con esta opción, se generan instancias de alerta independientes según el campo de grupo definido.
A continuación, en el escenario 2, se generan instancias de alerta independientes para Equipo 01 y Equipo
02 . Debido a la regla de acción descrita en el escenario, solo se suprime la notificación de Equipo 01 . La
notificación de Equipo 02 se sigue activando de forma normal.
Al configurar una regla de acción, me gustaría ver todas las reglas de acción que se pueden superponer de
modo que se eviten notificaciones duplicadas. ¿Se puede hacer esto?
Después de definir un ámbito al configurar una regla de acción, puede ver una lista de reglas de acción que se
superponen en el mismo ámbito (si la hay). Esta superposición puede ser una de las siguientes opciones:
Una coincidencia exacta: Por ejemplo, la regla de acción que va a definir y la regla de acción que se
superpone están en la misma suscripción.
Un subconjunto: Por ejemplo, la regla de acción que va a definir se encuentra en una suscripción y la regla
de acción que se superpone se encuentra en un grupo de recursos dentro de la suscripción.
Un superconjunto: Por ejemplo, la regla de acción que va a definir se encuentra en un grupo de recursos y
la regla de acción que se superpone se encuentra en la suscripción que contiene el grupo de recursos.
Una intersección: Por ejemplo, la regla de acción que va a definir se encuentra en VM1 y VM2 , y la regla
de acción que se superpone, en VM2 y VM3 .
Al configurar una regla de alerta, ¿es posible saber si ya hay definidas reglas de acción que podrían actuar
sobre la regla de alerta que voy a definir?
Después de definir el recurso de destino para la regla de alerta, puede ver la lista de reglas de acción que
actúan en el mismo ámbito (si existe); para ello, seleccione Ver acciones configuradas en la sección
Acciones . Esta lista se rellena en función de los siguientes escenarios para el ámbito:
Una coincidencia exacta: por ejemplo, la regla de alerta que va a definir y la regla de acción están en la
misma suscripción.
Un subconjunto: por ejemplo, la regla de alerta que va a definir se encuentra en una suscripción y la regla
de acción se encuentra en un grupo de recursos dentro de la suscripción.
Un superconjunto: por ejemplo, la regla de alerta que va a definir se encuentra en un grupo de recursos y
la regla de acción se encuentra en la suscripción que contiene el grupo de recursos.
Una intersección: Por ejemplo, la regla de alerta que va a definir se encuentra en VM1 y VM2 , y la regla de
acción, en VM2 y VM3 .
¿Puedo ver las alertas que han sido suprimidas por una regla de acción?
En la página de lista de alertas, puede elegir una columna adicional denominada Estado de supresión . Si se
suprimiera la notificación para una instancia de alerta, mostraría ese estado en la lista.
Si hay una regla de acción con un grupo de acciones y otra con la supresión activa en el mismo ámbito, ¿qué
ocurre?
La supresión siempre tiene prioridad en el mismo ámbito.
¿Qué ocurre si tengo un recurso supervisado en dos reglas de acción independientes? ¿Puedo obtener una
o dos notificaciones? Por ejemplo, VM2 en el escenario siguiente:
action rule AR1 defined for VM1 and VM2 with action group AG1
Para cada alerta en VM1 y VM3, el grupo de acciones AG1 se desencadenaría una vez. Para cada alerta en
VM2 , el grupo de acciones AG1 se desencadenaría dos veces, ya que las reglas de acción no desduplican las
acciones.
¿Qué ocurre si tengo un recurso supervisado en dos reglas de acción independientes y una llama a la acción
mientras la otra lo hace a la supresión? Por ejemplo, VM2 en el escenario siguiente:
action rule AR2 defined for VM2 and VM3 with suppression
Para cada alerta en VM1, el grupo de acciones AG1 se desencadenaría una vez. Se suprimirán las acciones y
las notificaciones para todas las alertas en VM2 y VM3.
¿Qué ocurre si tengo una regla de alerta y una regla de acción definidas para el mismo recurso que llama a
grupos de acciones diferentes? Por ejemplo, VM1 en el escenario siguiente:
alert rule rule1 on VM1 with action group AG2
action rule AR1 defined for VM1 with action group AG1
Para cada alerta en VM1, el grupo de acciones AG1 se desencadenaría una vez. Cada vez que se desencadene
la regla de alerta "rule1", también se desencadenará además AG2. Los grupos de acciones definidos dentro de
las reglas de acción y las reglas de alertas funcionan de forma independiente, sin desduplicación.
Pasos siguientes
Obtenga más información sobre alertas en Azure
Creación y administración de grupos de
acciones en Azure Portal
Un grupo de acciones es una colección de las preferencias de notificación que el

propietario de una suscripción de Azure define. Las alertas de Azure Monitor y Service
Health usan grupos de acciones para notificar a los usuarios que se ha desencadenado
una alerta. Varias alertas pueden usar el mismo grupo de acciones o distintos grupos de
acciones en función de los requisitos del usuario. Puede configurar un máximo de 2000
grupos de acciones en una suscripción.
En este artículo se muestra cómo crear y administrar grupos de acciones en el portal de
Azure.
Cada acción se compone de las siguientes propiedades:
Tipo : La notificación o acción realizada. El envío de llamadas de voz, mensajes de
texto o correo electrónico o el desencadenamiento de varios tipos de acciones
automatizadas son algunos ejemplos. Consulte los tipos más adelante en este
artículo.
Name : un identificador único dentro del grupo de acciones.
Detalles : detalles correspondientes que varían según el tipo.
Para más información sobre el uso de plantillas de Azure Resource Manager para
configurar grupos de acciones, consulte Plantillas de Resource Manager para grupos de
acciones.
Creación de un grupo de acciones con Azure Portal

1. En Azure Portal, busque y seleccione Monitor . El panel Monitor consolida todas
las opciones de configuración y todos los datos de supervisión en una vista.
2. Seleccione Aler tas y Administrar acciones .
3. Seleccione Agregar grupo de acciones y rellene los campos correspondientes

en la experiencia del asistente.
Configuración básica del grupo de acciones
En Detalles del proyecto :
Seleccione la Suscripción y el Grupo de recursos donde está guardado el grupo de
acciones.
En Detalles de instancia :
1. Escriba el Nombre del grupo de acciones .
2. Escriba un Nombre para mostrar . El nombre para mostrar se utiliza en lugar del
nombre completo del grupo de acciones cuando se envían notificaciones
mediante este grupo.
Configuración de notificaciones
1. Haga clic en el botón Siguiente: Notificaciones > para ir a la pestaña
Notificaciones , o bien seleccione la pestaña Notificaciones en la parte superior
de la pantalla.
2. Defina una lista de notificaciones que se enviarán cuando se desencadene una
alerta. Proporcione lo siguiente para cada notificación:
a. Tipo de notificación : seleccione el tipo de notificación que desea enviar. Las
opciones disponibles son:
Rol de Azure Resource Manager de correo electrónico: envíe un correo
electrónico a los usuarios asignados a determinados roles de ARM en el nivel
de suscripción.
Correo electrónico/SMS/Inserción/Voz: envíe estos tipos de notificación a
destinatarios específicos.
b. Name : especifique un nombre único para la notificación.
c. Detalles : en función del tipo de notificación seleccionado, escriba una dirección
de correo electrónico, un número de teléfono, etc.
d. Esquema de aler ta común : puede optar por habilitar el esquema de alerta
común, que proporciona la ventaja de tener una sola carga de alertas, extensible y
unificada, para todos los servicios de alerta de Azure Monitor.
Configuración de acciones
1. Haga clic en el botón Siguiente: Acciones > para ir a la pestaña Acciones , o
bien seleccione la pestaña Acciones en la parte superior de la pantalla.
2. Defina una lista de acciones que se ejecutarán cuando se desencadene una alerta.
Proporcione lo siguiente para cada acción:
a. Tipo de acción : seleccione Runbook de Automation, Función de Azure, ITSM,
Aplicación lógica, Webhook seguro y webhook.
b. Name : escriba un nombre único para la acción.
c. Detalles : según el tipo de acción, proporcione un identificador URI de
webhook, una aplicación de Azure, una conexión de ITSM o un runbook de
Automation. Para la acción de ITSM, especifique además Elemento de trabajo y
otros campos que requiera la herramienta ITSM.
d. Esquema de aler ta común : puede optar por habilitar el esquema de alerta
común, que proporciona la ventaja de tener una sola carga de alertas, extensible y
unificada, para todos los servicios de alerta de Azure Monitor.
Creación del grupo de acciones
1. Puede explorar la configuración de Etiquetas si lo desea. Esto le permite asociar
pares clave-valor al grupo de acciones para su categorización, y es una
característica disponible para cualquier recurso de Azure.
2. Haga clic en Revisar y crear para revisar la configuración. Se realizará una

validación rápida de las entradas para asegurarse de que se seleccionan todos los
campos obligatorios. Si hay algún problema, se le indicará aquí. Una vez revisada
la configuración, haga clic en Crear para aprovisionar el grupo de acciones.
NOTE
Al configurar una acción para notificar a una persona por correo electrónico o SMS, la persona
recibe una confirmación que le indica que se le ha agregado al grupo de acciones.
Administración de los grupos de acciones

Después de crear un grupo de acciones, puede ver los grupos de acciones
seleccionando Administrar acciones en la página de aterrizaje Aler tas del panel
Super visión . Seleccione el grupo de acciones que desea administrar para:
Agregar, editar o quitar acciones.
Eliminar el grupo de acciones.
Información específica de la acción

NOTE
Consulte los límites de servicio de suscripción para la supervisión para los límites numéricos de
cada uno de los siguientes elementos.
Runbook de automatización
Consulte los límites de servicio de suscripción de Azure para los límites relacionados con
las cargas de runbook.
En un grupo de acciones puede tener un número limitado de acciones de runbook.
Notificaciones push de aplicaciones de Azure
En un grupo de acciones puede tener un número limitado de acciones de aplicación de
Azure.
Email
Se enviarán mensajes de correo electrónico desde las direcciones de correo electrónico
siguientes. Asegúrese de que el filtrado de correo electrónico esté configurado
correctamente.
azure-noreply@microsoft.com
azureemail-noreply@microsoft.com
alerts-noreply@mail.windowsazure.com
En un grupo de acciones puede tener un número limitado de acciones de correo
electrónico. Consulte el artículo de información sobre las limitaciones.
Rol de Azure Resource Manager de correo electrónico
Envíe un correo electrónico a los miembros del rol de la suscripción. El correo electrónico
solo se enviará a los miembros usuarios de Azure AD del rol. No se enviará correo
electrónico a grupos de Azure AD ni entidades de servicio.
En un grupo de acciones puede tener un número limitado de acciones de correo
electrónico. Consulte el artículo de información sobre las limitaciones.
Función
Llama a un punto de conexión del desencadenador HTTP existente en Azure Functions.
En un grupo de acciones puede tener un número limitado de acciones de función.
ITSM
La acción de ITSM requiere una conexión de ITSM. Aprenda cómo crear una conexión de
ITSM.
En un grupo de acciones puede tener un número limitado de acciones de ITSM.
Aplicación lógica
En un grupo de acciones puede tener un número limitado de acciones de aplicación
lógica.
Webhook seguro
La acción de webhook de Grupos de acciones le permite aprovechar Azure Active
Directory para proteger la conexión entre el grupo de acciones y la API web protegida
(punto de conexión de webhook). A continuación se describe el flujo de trabajo general
para aprovechar esta funcionalidad. Para una introducción a las entidades de servicio y
aplicaciones de Azure AD, consulte Introducción a la Plataforma de identidad de
Microsoft (versión 2.0).
1. Cree una aplicación Azure AD para la API web. Consulte API web protegida:
registro de aplicación.
Configure la API protegida para que la llame una aplicación de demonio.
2. Habilite Grupos de acciones para usar la aplicación de Azure AD.
NOTE
Debe ser miembro del rol Administrador de aplicaciones de Azure AD para ejecutar este
script.
Modifique la llamada Connect-AzureAD del script de PowerShell para usar el

identificador de inquilino de Azure AD.
Modifique la variable del script de PowerShell
$myAzureADApplicationObjectId para usar el identificador de objeto de la
aplicación de Azure AD.
Ejecute el script modificado.
3. Configure la acción de webhook seguro del grupo de acciones.
Copie el valor $myApp.ObjectId del script e introdúzcalo en el campo Id. de
objeto de aplicación en la definición de acción de webhook.
Script de PowerShell de webhook seguro
Connect-AzureAD -TenantId "<provide your Azure AD tenant ID here>"
# This is your Azure AD Application's ObjectId.

$myAzureADApplicationObjectId = "<the Object Id of your Azure AD Application>"
# This is the Action Groups Azure AD AppId

$actionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a"
# This is the name of the new role we will add to your Azure AD Application
$actionGroupRoleName = "ActionGroupsSecureWebhook"
# Create an application role of given name and description

Function CreateAppRole([string] $Name, [string] $Description)
{
$appRole = New-Object Microsoft.Open.AzureAD.Model.AppRole
$appRole.AllowedMemberTypes = New-Object System.Collections.Generic.List[string]
$appRole.AllowedMemberTypes.Add("Application");
$appRole.DisplayName = $Name
$appRole.Id = New-Guid
$appRole.Id = New-Guid
$appRole.IsEnabled = $true
$appRole.Description = $Description
$appRole.Value = $Name;
return $appRole
}
# Get my Azure AD Application, it's roles and service principal

$myApp = Get-AzureADApplication -ObjectId $myAzureADApplicationObjectId
$myAppRoles = $myApp.AppRoles
$actionGroupsSP = Get-AzureADServicePrincipal -Filter ("appId eq '" +
$actionGroupsAppId + "'")
Write-Host "App Roles before addition of new role.."

Write-Host $myAppRoles
# Create the role if it doesn't exist

if ($myAppRoles -match "ActionGroupsSecureWebhook")
{
Write-Host "The Action Groups role is already defined.`n"
}
else
{
$myServicePrincipal = Get-AzureADServicePrincipal -Filter ("appId eq '" +
$myApp.AppId + "'")
# Add our new role to the Azure AD Application

$newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role
for Action Groups to join"
$myAppRoles.Add($newRole)
Set-AzureADApplication -ObjectId $myApp.ObjectId -AppRoles $myAppRoles
}
# Create the service principal if it doesn't exist

if ($actionGroupsSP -match "AzNS AAD Webhook")
{
Write-Host "The Service principal is already defined.`n"
}
else
{
# Create a service principal for the Action Groups Azure AD Application and add
it to the role
$actionGroupsSP = New-AzureADServicePrincipal -AppId $actionGroupsAppId
}
New-AzureADServiceAppRoleAssignment -Id $myApp.AppRoles[0].Id -ResourceId

$myServicePrincipal.ObjectId -ObjectId $actionGroupsSP.ObjectId -PrincipalId
$actionGroupsSP.ObjectId
Write-Host "My Azure AD Application ($myApp.ObjectId): " + $myApp.ObjectId

Write-Host "My Azure AD Application's Roles"
Write-Host $myApp.AppRoles
sms
Consulte también la información sobre las limitaciones y el comportamiento de las
alertas por SMS para información adicional.
En un grupo de acciones puede tener un número limitado de acciones de SMS.
NOTE
Si la interfaz de usuario del grupo de acciones de Azure Portal no permite seleccionar el código
de país o región, no se admite SMS para el país o región. Si el código de país o región no está
disponible, puede votar en UserVoice para que el país o región se agregue. Mientras tanto,
como solución alternativa, haga que el grupo de acciones llame a un webhook de un proveedor
de SMS de terceros con soporte en el país o región.
Los precios de los países o regiones admitidos se muestran en la página de precios de

Azure Monitor.
Voz
Consulte el artículo Información sobre las limitaciones para comportamientos
importantes adicionales.
En un grupo de acciones puede tener un número limitado de acciones de voz.
NOTE
Si la interfaz de usuario del grupo de acciones de Azure Portal no permite seleccionar el código
de país o región, no se admiten llamadas de voz en el país o región. Si el código de país o
región no está disponible, puede votar en UserVoice para que el país o región se agregue.
Mientras tanto, como solución alternativa, haga que el grupo de acciones llame a un webhook
de un proveedor de llamadas de voz de terceros con soporte en el país o región.
Los precios de los países o regiones admitidos se muestran en la página de precios de

Azure Monitor.
webhook
Los webhooks se procesan utilizando las siguientes reglas:
Una llamada de webhook se intenta un máximo de 3 veces.
Se volverá a intentar la llamada si no se recibe una respuesta dentro del período de
tiempo de espera o se devuelve uno de los siguientes códigos de estado HTTP: 408,
429, 503 o 504.
La primera llamada esperará diez segundos para obtener una respuesta.
El segundo y el tercer intento esperarán treinta segundos para obtener una respuesta.
Después de que los tres intentos de llamada al webhook no se hayan realizado,
ningún grupo de acciones llamará al punto de conexión durante quince minutos.
Rangos de direcciones IP de origen
13.72.19.232
13.106.57.181
13.106.54.3
13.106.54.19
13.106.38.142
13.106.38.148
13.106.57.196
13.106.57.197
52.244.68.117
52.244.65.137
52.183.31.0
52.184.145.166
51.4.138.199
51.5.148.86
51.5.149.19
Para recibir actualizaciones sobre los cambios a estas direcciones IP, se recomienda
configurar una alerta de Service Health, que supervisa las notificaciones informativas
sobre el servicio de grupos de acciones.
En un grupo de acciones puede tener un número limitado de acciones de webhook.
Pasos siguientes
Más información sobre el comportamiento de las alertas por SMS.
Comprender el esquema de webhook de alertas del registro de actividad.
Obtenga más información sobre el conector de ITSM.
Más información sobre la limitación de velocidad en las alertas.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo puede
recibir alertas.
Aprenda a configurar alertas siempre que se publique una notificación de
mantenimiento de un servicio.
Esquema de alertas comunes
Este artículo describe qué es el esquema de alertas comunes, las ventajas de usarlo y cómo habilitarlo.
¿Qué es el esquema de alertas comunes?

Actualmente, el esquema de alerta común normaliza la experiencia de consumo de notificaciones de alerta en
Azure. Históricamente, los tres tipos de alerta de Azure (métrica, registro y registro de actividad) han tenido sus
propias plantillas de correo electrónico, esquemas de webhook, etc. Con el esquema de alerta comunes, ahora
puede recibir notificaciones de alertas con un esquema coherente.
Cualquier instancia de alerta describe el recurso que resultó afectado y la causa de la aler ta , y estas
instancias se describen en el esquema común en las secciones siguientes:
Información esencial : Un conjunto de campos estandarizados común a todos los tipos de alertas, que
describen en qué recurso se encuentra la alerta junto con otros metadatos de alerta comunes (por ejemplo,
gravedad o descripción).
Contexto de aler ta : Un conjunto de campos que describen la causa de la aler ta , con campos que varían
según el tipo de aler ta . Por ejemplo, una alerta de métrica tendría campos como el nombre de la métrica y el
valor de la métrica en el contexto de la alerta, mientras que una alerta de registro de actividad tendría
información sobre el evento que generó la alerta.
Entre los escenarios de integración típicos que nos cuentan nuestros clientes está el enrutamiento de la instancia
de alerta al equipo correspondiente según alguna variable dinámica (por ejemplo, grupo de recursos), después de
que el equipo responsable empiece a trabajar en ella. Con el esquema de alertas comunes, puede tener una lógica
de enrutamiento estandarizada con tipos de alerta al utilizar los campos esenciales, dejando los campos de
contexto tal cual para que los equipos afectados los investiguen en profundidad.
Esto significa que puede tener potencialmente menos integraciones, con lo que el proceso de administrarlas y
mantenerlas será una tarea mucho más sencilla. Además, los enriquecimientos de carga de alertas futuras (por
ejemplo, personalización, enriquecimiento de diagnóstico, etc.) solo se detectarán en el esquema común.
¿Qué mejoras aporta el esquema de alertas comunes?

El esquema de alertas comunes se manifestará principalmente en las notificaciones de alertas. Las mejoras que
verá son las siguientes:
A C C IÓ N M E JO RA S
sms Una plantilla SMS coherente para todos los tipos de alerta.
Email Una plantilla de correo electrónico detallada y coherente, que

le permite diagnosticar fácilmente los problemas de un
vistazo. Vínculos profundos insertados en la instancia de
alerta en el portal y los recursos afectados garantizan que
pueda pasar rápidamente al proceso de corrección.
Webhook/Logic App/Azure Functions/Runbook de Una estructura JSON coherente para todos los tipos de alerta,
Automation que le permite crear fácilmente integraciones entre los
diferentes tipos de alerta.
El nuevo esquema también permitirá una experiencia de consumo de alertas más rica tanto en Azure Portal como
en Azure Mobile App en el futuro inmediato.
Más información sobre las definiciones de esquema para webhooks/Logic Apps/Azure Functions/runbook de
Automation.
NOTE
Las siguientes acciones no admiten el esquema de alertas comunes: Conector ITSM.
¿Cómo habilito el esquema de alertas comunes?

Puede participar o dejar de participar en el esquema de alertas comunes a través de grupos de acciones, en el
portal y la API REST. El botón de alternancia para cambiar al nuevo esquema existe en el nivel de acción. Por
ejemplo, debe expresar por separado la intención de recibir una acción de correo electrónico y una acción de
webhook.
NOTE
1. Los siguientes tipos de alerta admiten el esquema común de forma predeterminada (no es necesario expresar la
participación):
Alertas de detección inteligente
2. Los siguientes tipos de alerta no admiten actualmente el esquema común:
Las alertas generadas por Azure Monitor para VM
Las alertas generadas por Azure Cost Management
Mediante Azure Portal
1. Abra una acción existente o una nueva en un grupo de acciones.

2. Seleccione "Sí" para que el botón de alternancia habilite el esquema de alerta comunes, como se muestra.
Mediante la API REST de grupos de acciones
También puede usar la API de grupos de acciones para participar en el esquema de alertas comunes. Al realizar la
llamada de creación o actualización de la API REST, puede establecer la marca "useCommonAlertSchema" en "true"
(para participar) o "false" (para dejar de participar) para cualquiera de las siguientes acciones: correo
electrónico/webhook/Logic Apps/función de Azure Functions/runbook de Automation.
Por ejemplo, el siguiente cuerpo de la solicitud realizado en la API REST de creación o actualización hará lo
siguiente:
Habilitar el esquema de alertas comunes para la acción de correo electrónico "John Doe's email"
Deshabilitar el esquema de alertas comunes para la acción de correo electrónico "Jane Smith's email"
Habilitar el esquema de alertas comunes para la acción de webhook "Sample webhook"
{
"properties": {
"groupShortName": "sample",
"enabled": true,
"emailReceivers": [
{
"name": "John Doe's email",
"emailAddress": "johndoe@email.com",
"useCommonAlertSchema": true
},
{
"name": "Jane Smith's email",
"emailAddress": "janesmith@email.com",
"useCommonAlertSchema": false
}
],
"smsReceivers": [
{
"name": "John Doe's mobile",
"countryCode": "1",
},
{
"name": "Jane Smith's mobile",
"countryCode": "1",
}
],
{
"name": "Sample webhook",
"serviceUri": "http://www.example.com/webhook",
"useCommonAlertSchema": true
}
]
},
"tags": {}
}
Pasos siguientes
Definiciones del esquema de alertas comunes para webhooks/Logic Apps/Azure Functions/runbook de
Automation.
Obtenga información sobre cómo crear una aplicación lógica que aproveche el esquema común de alertas para
controlar todas las alertas.
Definiciones de esquemas de alertas comunes
En este artículo se describen las definiciones del esquema de alertas comunes de Azure Monitor, incluyendo
aquellas para webhooks, Azure Logic Apps, Azure Functions y los runbooks de Azure Automation.
Cualquier instancia de alerta describe el recurso afectado y la causa de la alerta. Estas instancias se describen en el
esquema común de las secciones siguientes:
Información esencial : un conjunto de campos estandarizados común a todos los tipos de alertas, que
describen en qué recurso se encuentra la alerta junto con otros metadatos de alerta comunes (por ejemplo,
gravedad o descripción).
Contexto de aler ta : un conjunto de campos que describen la causa de la alerta, con campos que varían según
el tipo de alerta. Por ejemplo, una alerta de métrica incluye campos como el nombre y el valor de la métrica en
el contexto de la alerta, mientras que una alerta de registro de actividad tiene información sobre el evento que
generó la alerta.
Carga de aler ta de ejemplo
{
"schemaId": "azureMonitorCommonAlertSchema",
"data": {
"essentials": {
"alertId": "/subscriptions/<subscription ID>/providers/Microsoft.AlertsManagement/alerts/b9569717-bc32-
442f-add5-83a997729330",
"alertRule": "WCUS-R2-Gen2",
"severity": "Sev3",
"signalType": "Metric",
"monitorCondition": "Resolved",
"monitoringService": "Platform",
"alertTargetIDs": [
"/subscriptions/<subscription
ID>/resourcegroups/pipelinealertrg/providers/microsoft.compute/virtualmachines/wcus-r2-gen2"
],
"originAlertId": "3f2d4487-b0fc-4125-8bd5-
7ad17384221e_PipeLineAlertRG_microsoft.insights_metricAlerts_WCUS-R2-Gen2_-117781227",
"firedDateTime": "2019-03-22T13:58:24.3713213Z",
"resolvedDateTime": "2019-03-22T14:03:16.2246313Z",
"description": "",
"essentialsVersion": "1.0",
"alertContextVersion": "1.0"
},
"alertContext": {
"properties": null,
"conditionType": "SingleResourceMultipleMetricCriteria",
"condition": {
"allOf": [
{
"metricNamespace": "Microsoft.Compute/virtualMachines",
"threshold": "25",
"dimensions": [
{
"name": "ResourceId",
"value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"
}
],
"metricValue": 7.727
}
]
}
}
}
}
Essentials
alertId GUID que identifica de forma única la instancia de alerta.
alertRule Nombre de la regla de alertas que generó la instancia de la

alerta.
severity Gravedad de la alerta. Valores posibles: Sev0, Sev1, Sev2, Sev3

o Sev4.
signalType Identifica la señal en que se definió la regla de alertas. Valores

posibles: Métrica, Registro o Registro de actividad.
monitorCondition Cuando se desencadena una alerta, la condición de

supervisión de la alerta se establece en Desencadenada .
Cuando desaparece la condición subyacente que provocó que
se desencadenara la alerta, la condición de supervisión se
establece en Resuelta .
monitoringService El servicio o solución de supervisión que generó la alerta. El

servicio de supervisión dicta los campos para el contexto de
alerta.
alertTargetIds Lista de los identificadores de Azure Resource Manager que

son los destinos afectados de una alerta. Para una alerta de
registro definida en un área de trabajo de Log Analytics o una
instancia de Application Insights, es el área de trabajo o la
aplicación correspondiente.
originAlertId Id. de la instancia de alerta que generó el servicio de

supervisión encargado.
firedDateTime Fecha y hora de activación de la instancia de alerta en la hora

universal coordinada (UTC).
resolvedDateTime Fecha y hora del momento en que la condición de supervisión

de la instancia de alerta se estableció como Resuelta en UTC.
Actualmente solo es aplicable a las alertas de métricas.
description Descripción tal como se define en la regla de alertas.
essentialsVersion Número de versión de la sección de información básica.
alertContextVersion Número de versión de la sección alertContext .
Valores de ejemplo
{
"essentials": {
"alertId": "/subscriptions/<subscription ID>/providers/Microsoft.AlertsManagement/alerts/b9569717-bc32-
442f-add5-83a997729330",
"alertRule": "Contoso IT Metric Alert",
"severity": "Sev3",
"signalType": "Metric",
"monitorCondition": "Fired",
"monitoringService": "Platform",
"alertTargetIDs": [
"/subscriptions/<subscription ID>/resourceGroups/aimon-rg/providers/Microsoft.Insights/components/ai-
orion-int-fe"
],
"originAlertId": "74ff8faa0c79db6084969cf7c72b0710e51aec70b4f332c719ab5307227a984f",
"firedDateTime": "2019-03-26T05:25:50.4994863Z",
"description": "Test Metric alert",
"essentialsVersion": "1.0",
"alertContextVersion": "1.0"
}
}
Contexto de alerta
Alertas de métricas
monitoringService = Platform
Valores de ejemplo
{
"alertContext": {
"properties": null,
"condition": {
"allOf": [
{
"metricNamespace": "Microsoft.Compute/virtualMachines",
"threshold": "25",
"dimensions": [
{
"value": "3efad9dc-3d50-4eac-9c87-8b3fd6f97e4e"
}
],
"metricValue": 31.1105
}
],
"windowStartTime": "2019-03-22T13:40:03.064Z",
"windowEndTime": "2019-03-22T13:45:03.064Z"
}
}
}
Alertas de registro
NOTE
En el caso de las alertas de registro que tienen definida una carga de JSON o un asunto de correo electrónico personalizados,
habilitar el esquema común revierte el esquema de la carga o el asunto de correo electrónico a los que se describen a
continuación. Las alertas con el esquema común habilitado tienen un límite de tamaño superior de 256 KB por alerta. Los
resultados de la búsqueda no se insertan en la carga de las alertas de registro si hicieron que el tamaño de la alerta superara
este umbral. Para determinar esto, compruebe la marca IncludeSearchResults . Cuando no se incluyen los resultados de la
búsqueda, se recomienda usar la consulta de búsqueda en conjunto con la API de Log Analytics.
monitoringService = Log Analytics
Valores de ejemplo
{
"alertContext": {
"SearchQuery": "Perf | where ObjectName == \"Processor\" and CounterName == \"% Processor Time\" |
summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer",
"SearchIntervalStartTimeUtc": "3/22/2019 1:36:31 PM",
"SearchIntervalEndtimeUtc": "3/22/2019 1:51:31 PM",
"ResultCount": 2,
"LinkToSearchResults": "https://portal.azure.com/#Analyticsblade/search/index?
"LinkToFilteredSearchResultsUI": "https://portal.azure.com/#Analyticsblade/search/index?
"LinkToSearchResultsAPI": "https://api.loganalytics.io/v1/workspaces/workspaceID/query?
"SeverityDescription": "Warning",
"WorkspaceId": "12345a-1234b-123c-123d-12345678e",
"SearchIntervalDurationMin": "15",
"AffectedConfigurationItems": [
"INC-Gen2Alert"
],
"SearchIntervalInMinutes": "15",
"Threshold": 10000,
"Operator": "Less Than",
"Dimensions": [
{
"name": "Computer",
"value": "INC-Gen2Alert"
}
],
"SearchResults": {
"tables": [
{
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "TimeGenerated",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
]
},
"dataSources": [
{
"resourceId": "/subscriptions/a5ea55e2-7482-49ba-90b3-
60e7496dd873/resourcegroups/test/providers/microsoft.operationalinsights/workspaces/test",
"tables": [
"Heartbeat"
]
}
],
"IncludeSearchResults": "True",
}
}
monitoringService = Application Insights
Valores de ejemplo
{
"alertContext": {
"SearchQuery": "requests | where resultCode == \"500\" | summarize AggregatedValue = Count by
bin(Timestamp, 5m), IP",
"SearchIntervalStartTimeUtc": "3/22/2019 1:36:33 PM",
"SearchIntervalEndtimeUtc": "3/22/2019 1:51:33 PM",
"ResultCount": 2,
"LinkToSearchResults": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-123c-123d-
12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-
"LinkToFilteredSearchResultsUI": "https://portal.azure.com/AnalyticsBlade/subscriptions/12345a-1234b-
123c-123d-12345678e/?query=search+*+&timeInterval.intervalEnd=2018-03-
"LinkToSearchResultsAPI":
"LinkToFilteredSearchResultsAPI":
"SearchIntervalDurationMin": "15",
"SearchIntervalInMinutes": "15",
"Threshold": 10000,
"Operator": "Less Than",
"ApplicationId": "8e20151d-75b2-4d66-b965-153fb69d65a6",
"Dimensions": [
{
"name": "IP",
"value": "1.1.1.1"
}
],
"SearchResults": {
"tables": [
{
"columns": [
{
"name": "$table",
"type": "string"
},
{
"name": "Id",
"type": "string"
},
{
"name": "Timestamp",
"type": "datetime"
}
],
"rows": [
[
"Fabrikam",
"33446677a",
"2018-02-02T15:03:12.18Z"
],
[
"Contoso",
"33445566b",
"2018-02-02T15:16:53.932Z"
]
]
}
],
"dataSources": [
{
"resourceId": "/subscriptions/a5ea27e2-7482-49ba-90b3-
52e7496dd873/resourcegroups/test/providers/microsoft.operationalinsights/workspaces/test",
"tables": [
"Heartbeat"
]
}
]
]
},
"IncludeSearchResults": "True",
}
}
Alertas de registros de actividad

monitoringService = Activity Log - Administrative
Valores de ejemplo
{
"alertContext": {
"authorization": {
"action": "Microsoft.Compute/virtualMachines/restart/action",
"scope": "/subscriptions/<subscription
ID>/resourceGroups/PipeLineAlertRG/providers/Microsoft.Compute/virtualMachines/WCUS-R2-ActLog"
},
"claims": "{\"aud\":\"https://management.core.windows.net/\",\"iss\":\"https://sts.windows.net/72f988bf-
86f1-41af-91ab-
2d7cd011db47/\",\"iat\":\"1553260826\",\"nbf\":\"1553260826\",\"exp\":\"1553264726\",\"aio\":\"42JgYNjdt+rr+3j
/dx68v018XhuFAwA=\",\"appid\":\"e9a02282-074f-45cf-93b0-
50568e0e7e50\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://
sts.windows.net/72f988bf-86f1-41af-91ab-
2d7cd011db47/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"9778283b-b94c-4ac6-8a41-
d5b493d03aa3\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"9778283b-b94c-4ac6-
8a41-d5b493d03aa3\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"72f988bf-86f1-41af-91ab-
2d7cd011db47\",\"uti\":\"v5wYC9t9ekuA2rkZSVZbAA\",\"ver\":\"1.0\"}",
"caller": "9778283b-b94c-4ac6-8a41-d5b493d03aa3",
"correlationId": "8ee9c32a-92a1-4a8f-989c-b0ba09292a91",
"eventDataId": "161fda7e-1cb4-4bc5-9c90-857c55a8f57b",
"operationName": "Microsoft.Compute/virtualMachines/restart/action",
"operationId": "310db69b-690f-436b-b740-6103ab6b0cba",
"subStatus": "",
}
}
monitoringService = Activity Log - Policy
Valores de ejemplo
{
"alertContext": {
"authorization": {
"action": "Microsoft.Resources/checkPolicyCompliance/read",
"scope": "/subscriptions/<GUID>"
},
"claims": "
{\"aud\":\"https://management.azure.com/\",\"iss\":\"https://sts.windows.net/<GUID>/\",\"iat\":\"1566711059\",
\"nbf\":\"1566711059\",\"exp\":\"1566740159\",\"aio\":\"42FgYOhynHNw0scy3T/bL71+xLyqEwA=\",\"appid\":\"
<GUID>\",\"appidacr\":\"2\",\"http://schemas.microsoft.com/identity/claims/identityprovider\":\"https://sts.wi
ndows.net/<GUID>/\",\"http://schemas.microsoft.com/identity/claims/objectidentifier\":\"
<GUID>\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"
<GUID>\",\"http://schemas.microsoft.com/identity/claims/tenantid\":\"
<GUID>\",\"uti\":\"Miy1GzoAG0Scu_l3m1aIAA\",\"ver\":\"1.0\"}",
"caller": "<GUID>",
"correlationId": "<GUID>",
"eventSource": "Policy",
"eventDataId": "<GUID>",
"level": "Warning",
"operationName": "Microsoft.Authorization/policies/audit/action",
"operationId": "<GUID>",
"properties": {
"isComplianceCheck": "True",
"resourceLocation": "eastus2",
"ancestors": "<GUID>",
"policies": "
[{\"policyDefinitionId\":\"/providers/Microsoft.Authorization/policyDefinitions/<GUID>/\",\"policySetDefinitio
nId\":\"/providers/Microsoft.Authorization/policySetDefinitions/<GUID>/\",\"policyDefinitionReferenceId\":\"vu
lnerabilityAssessmentMonitoring\",\"policySetDefinitionName\":\"<GUID>\",\"policyDefinitionName\":\"
<GUID>\",\"policyDefinitionEffect\":\"AuditIfNotExists\",\"policyAssignmentId\":\"/subscriptions/<GUID>/provid
ers/Microsoft.Authorization/policyAssignments/SecurityCenterBuiltIn/\",\"policyAssignmentName\":\"SecurityCent
erBuiltIn\",\"policyAssignmentScope\":\"/subscriptions/<GUID>\",\"policyAssignmentSku\":
{\"name\":\"A1\",\"tier\":\"Standard\"},\"policyAssignmentParameters\":{}}]"
},
"subStatus": "",
}
}
monitoringService = Activity Log - Autoscale
Valores de ejemplo
{
"alertContext": {
"claims": "
{\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn\":\"Microsoft.Insights/autoscaleSettings\"}",
"caller": "Microsoft.Insights/autoscaleSettings",
"eventSource": "Autoscale",
"operationName": "Microsoft.Insights/AutoscaleSettings/Scaleup/Action",
"properties": {
"description": "The autoscale engine attempting to scale resource
'/subscriptions/d<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS'
from 9 instances count to 10 instances count.",
"resourceName":
"/subscriptions/<GUID>/resourceGroups/voiceassistancedemo/providers/Microsoft.Compute/virtualMachineScaleSets/
alexademo",
"oldInstancesCount": "9",
"newInstancesCount": "10",
"activeAutoscaleProfile": "{\r\n \"Name\": \"Auto created scale condition\",\r\n \"Capacity\": {\r\n
\"Minimum\": \"1\",\r\n \"Maximum\": \"10\",\r\n \"Default\": \"1\"\r\n },\r\n \"Rules\": [\r\n
{\r\n \"MetricTrigger\": {\r\n \"Name\": \"Percentage CPU\",\r\n \"Namespace\":
\"microsoft.compute/virtualmachinescalesets\",\r\n \"Resource\":
\"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\
r\n \"ResourceLocation\": \"eastus\",\r\n \"TimeGrain\": \"PT1M\",\r\n \"Statistic\":
\"Average\",\r\n \"TimeWindow\": \"PT5M\",\r\n \"TimeAggregation\": \"Average\",\r\n
\"Operator\": \"GreaterThan\",\r\n \"Threshold\": 0.0,\r\n \"Source\":
\"/subscriptions/<GUID>/resourceGroups/testRG/providers/Microsoft.Compute/virtualMachineScaleSets/testVMSS\",\
r\n \"MetricType\": \"MDM\",\r\n \"Dimensions\": [],\r\n \"DividePerInstance\": false\r\n
},\r\n \"ScaleAction\": {\r\n \"Direction\": \"Increase\",\r\n \"Type\":
\"ChangeCount\",\r\n \"Value\": \"1\",\r\n \"Cooldown\": \"PT1M\"\r\n }\r\n }\r\n
]\r\n}",
"lastScaleActionTime": "Wed, 21 Aug 2019 16:17:47 GMT"
},
}
}
monitoringService = Activity Log - Security
Valores de ejemplo
{
"alertContext": {
"eventSource": "Security",
"eventTimestamp": "2019-08-26T08:34:14+00:00",
"operationName": "Microsoft.Security/locations/alerts/activate/action",
"properties": {
"threatStatus": "Quarantined",
"category": "Virus",
"threatID": "2147519003",
"filePath": "C:\\AlertGeneration\\test.eicar",
"protectionType": "Windows Defender",
"actionTaken": "Blocked",
"resourceType": "Virtual Machine",
"severity": "Low",
"compromisedEntity": "testVM",
"remediationSteps": "[\"No user action is necessary\"]",
"attackedResourceType": "Virtual Machine"
},
"status": "Active",
}
}
monitoringService = ServiceHealth
Valores de ejemplo
{
"alertContext": {
"authorization": null,
"channels": 1,
"claims": null,
"caller": null,
"correlationId": "f3cf2430-1ee3-4158-8e35-7a1d615acfc7",
"eventSource": 2,
"httpRequest": null,
"level": 3,
"operationName": "Microsoft.ServiceHealth/maintenance/action",
"properties": {
"title": "Azure Synapse Analytics Scheduled Maintenance Pending",
"service": "Azure Synapse Analytics",
"region": "East US",
"communication": "<MESSAGE>",
"incidentType": "Maintenance",
"trackingId": "<GUID>",
"impactStartTime": "2019-06-26T04:00:00Z",
"impactMitigationTime": "2019-06-26T12:00:00Z",
"impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"East US\"}],\"ServiceName\":\"Azure
Synapse Analytics\"}]",
"impactedServicesTableRows": "<tr>\r\n<td align='center' style='padding: 5px 10px; border-right:1px
solid black; border-bottom:1px solid black'>Azure Synapse Analytics</td>\r\n<td align='center' style='padding:
5px 10px; border-bottom:1px solid black'>East US<br></td>\r\n</tr>\r\n",
"defaultLanguageTitle": "Azure Synapse Analytics Scheduled Maintenance Pending",
"defaultLanguageContent": "<MESSAGE>",
"stage": "Planned",
"communicationId": "<GUID>",
"maintenanceId": "<GUID>",
"isHIR": "false",
"version": "0.1.1"
},
"status": "Active",
"subStatus": null,
"ResourceType": null
}
}
monitoringService = Resource Health
Valores de ejemplo
{
"alertContext": {
"eventSource": "ResourceHealth",
"operationName": "Microsoft.Resourcehealth/healthevent/Activated/action",
"properties": {
"title": "This virtual machine is stopping and deallocating as requested by an authorized user or
process",
"details": null,
"currentHealthStatus": "Unavailable",
"previousHealthStatus": "Available",
"type": "Downtime",
"cause": "UserInitiated"
},
"status": "Active",
}
}
Pasos siguientes
Obtenga más información sobre el esquema de alertas comunes.
Obtenga información sobre cómo crear una aplicación lógica que aproveche el esquema común de alertas para
Integración del esquema común de alertas con Logic
Apps
En este artículo se muestra cómo crear una aplicación lógica que aprovecha el esquema común de alertas para
El esquema común de alerta proporciona un esquema JSON estandarizado y extensible a través de todos los
diferentes tipos de alerta. El esquema común de alerta es especialmente útil cuando se aprovecha mediante
programación: con webhooks, runbooks y aplicaciones lógicas. En este artículo, se muestra cómo se puede crear
una única aplicación lógica para controlar todas las alertas. Los mismos principios se pueden aplicar a otros
métodos de programación. La aplicación lógica descrita en este artículo crea variables bien definidas para los
campos "esenciales"y también se describe cómo puede controlar la lógica específica del tipos de alerta.
Prerequisites
En este artículo se supone que el lector está familiarizado con los conceptos siguientes:
Configuración de reglas de alerta (métrica, registro, registro de actividad)
Configuración de grupos de acciones
Habilitación del esquema común de alerta desde dentro de grupos de acciones
Creación de una aplicación lógica, aprovechando el esquema común de

alerta
1. Siga los pasos para crear la aplicación lógica.
2. Seleccione el desencadenador Cuando se recibe una solicitud HTTP .
3. Seleccione Editar para cambiar el desencadenador de solicitud HTTP.
4. Copie y pegue el siguiente esquema:

{
"type": "object",
"properties": {
"schemaId": {
"type": "string"
},
"data": {
"type": "object",
"properties": {
"essentials": {
"type": "object",
"properties": {
"alertId": {
"type": "string"
},
"alertRule": {
"type": "string"
},
"severity": {
"type": "string"
},
"signalType": {
"type": "string"
},
"monitorCondition": {
"type": "string"
},
"monitoringService": {
"type": "string"
},
"alertTargetIDs": {
"type": "array",
"items": {
"type": "string"
}
},
"originAlertId": {
"type": "string"
},
"firedDateTime": {
"type": "string"
},
"resolvedDateTime": {
"type": "string"
},
"description": {
"type": "string"
},
"essentialsVersion": {
"type": "string"
},
"alertContextVersion": {
"type": "string"
}
}
},
"alertContext": {
"type": "object",
"properties": {}
}
}
}
}
}
5. Seleccione + Nuevo paso y luego elija Agregar una acción .

6. En esta fase, puede agregar diversos conectores (Microsoft Teams, Slack, Salesforce, etc.) en función de sus
requisitos empresariales específicos. Puede usar los "campos esenciales" proporcionados.
Como alternativa, puede crear una lógica condicional propia según el tipo de alerta mediante la opción
"Expression".
El campo "monitoringService" permite identificar de forma única el tipo de alerta en función del cual puede
crear la lógica condicional.
Por ejemplo, el siguiente fragmento de código comprueba si la alerta es una alerta de registro basada en
Application Insights y, en caso afirmativo, se imprimen los resultados de búsqueda. En caso contrario,
imprime "NA" (No disponible).
if(equals(triggerBody()?['data']?['essentials']?['monitoringService'],'Application
Insights'),triggerBody()?['data']?['alertContext']?['SearchResults'],'NA')
Obtenga más información sobre cómo escribir expresiones de la lógica de aplicación.
Pasos siguientes
Más información sobre el esquema de alertas comunes.
Comportamiento de las alertas por SMS en los
grupos de acciones
Los grupos de acciones le permiten configurar una lista de acciones. Estos grupos se utilizan al definir alertas, lo
que garantiza que cuando se activa una alerta, un grupo de acciones concreto recibe la notificación. Una de las
acciones que se admiten es SMS; las notificaciones SMS admiten la comunicación bidireccional. Un usuario puede
responder a un SMS para:
Cancelar la suscripción a aler tas: un usuario puede cancelar la suscripción a todas las alertas por SMS
para todos los grupos de acciones o para un único grupo de acciones.
Volver a suscribirse a aler tas: un usuario puede volver a suscribirse a todas las alertas por SMS para todos
los grupos de acciones o para un solo grupo de acciones.
Solicitar ayuda: un usuario puede pedir más información acerca del SMS. Se le redirigirá a este artículo.
En este artículo se trata el comportamiento de las alertas por SMS y las acciones de respuesta que el usuario
puede realizar en función de su configuración regional:
Recepción de una alerta por SMS

Un receptor de SMS, que se configura como parte de un grupo de acciones, recibirá un SMS cuando se
desencadene una alerta. El SMS contiene la siguiente información:
El nombre corto del grupo de acciones al que se envió esta alerta
El título de la alerta
RESP UESTA DESC RIP C IÓ N
DISABLE <Action Group Short name> Deshabilita SMS adicionales del grupo de acciones
ENABLE <Action Group Short name> Vuelve a habilitar los SMS en el grupo de acciones
STOP Deshabilita SMS adicionales de todos los grupos de acciones
START Vuelve a habilitar SMS en TODOS los grupos de acciones
HELP Se enviará una respuesta al usuario con un vínculo a este

artículo.
NOTE
Si un usuario ha cancelado la suscripción a las alertas por SMS, pero luego se agrega a un nuevo grupo de acciones; SE
recibirán alertas por SMS para el grupo de acciones nuevo, pero permanecerán sin suscripción de todos los grupos de
acciones anteriores.
Pasos siguientes
Obtener una introducción a las alertas del registro de actividad y aprender cómo puede recibir alertas
Más información sobre la limitación de la tasa de SMS
Limitación del número de SMS, llamadas de voz,
correos electrónicos, notificaciones push de App de
Azure y publicaciones de webhooks
La limitación de número supone una suspensión de las notificaciones que se produce cuando se envían
demasiadas a un número de teléfono, dirección de correo electrónico o dispositivo determinados. La limitación
del índice asegura que las alertas son fáciles de administrar y procesar.
Los umbrales del límite de número son:
SMS : no más de 1 SMS cada 5 minutos.
Voz : no más de 1 llamada de voz cada 5 minutos.
Correo electrónico : no más de 100 mensajes de correo electrónico en una hora.
Otras acciones no tienen velocidad limitada.
Reglas de limitación de número

Un número de teléfono o correo electrónico particular se limitan cuando reciben más mensajes de los que
permite el umbral.
Un número de teléfono o correo electrónico puede formar parte de grupos de acciones de muchas
suscripciones. La limitación de número se aplica en todas las suscripciones. En cuanto se alcanza el umbral,
se aplica incluso si se envían los mensajes desde varias suscripciones.
Cuando una dirección de correo electrónico está limitada, se envía una notificación adicional del mismo
tipo para comunicar la limitación. El correo electrónico indica cuándo expira la limitación de número.
Pasos siguientes
Más información sobre el comportamiento de las alertas por SMS.
Consulte la introducción a las alertas del registro de actividad y aprenda cómo puede recibir alertas.
Aprenda a configurar alertas siempre que se publique una notificación de mantenimiento de un servicio.
Creación de un grupo de acciones con una plantilla
de Resource Manager
En este artículo se muestra cómo utilizar una plantilla de Azure Resource Manager para configurar grupos de
acciones. Mediante el uso de plantillas, puede configurar automáticamente grupos de acciones que se pueden
reutilizar en determinados tipos de alertas. Estos grupos de acciones garantizan que se notifique a todas las
entidades correctas cuando se desencadene una alerta.
Los pasos básicos son:
1. Crear una plantilla en forma de archivo JSON que describa cómo crear la alerta del grupo de acciones.
En primer lugar, se describe cómo crear una plantilla de Resource Manager para un grupo de acciones donde las
definiciones de acción están codificadas en la plantilla. En segundo lugar, se describe cómo crear una plantilla que
toma la información de configuración de webhook como parámetros de entrada cuando se implementa la
plantilla.
Plantillas de Resource Manager para un grupo de acciones

Para crear un grupo de acciones mediante una plantilla de Resource Manager, cree un recurso del tipo
Microsoft.Insights/actionGroups . A continuación, rellene todas las propiedades relacionadas. Aquí hay dos
plantillas de ejemplo que crean un grupo de acciones.
{
"parameters": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
}
},
"resources": [
{
"apiVersion": "2018-03-01",
"properties": {
"enabled": true,
"smsReceivers": [
{
"name": "contosoSMS",
"countryCode": "1",
},
{
"name": "contosoSMS2",
"countryCode": "1",
}
],
"emailReceivers": [
{
"name": "contosoEmail",
"emailAddress": "devops@contoso.com"
},
{
"name": "contosoEmail2",
"emailAddress": "devops2@contoso.com"
}
],
{
"name": "contosoHook",
},
{
"name": "contosoHook2",
}
]
}
}
],
"outputs":{
"actionGroupId":{
"type":"string",
}
}
}
{
"parameters": {
"type": "string",
"metadata": {
"description": "Unique name (within the Resource Group) for the Action group."
}
},
"type": "string",
"metadata": {
"description": "Short name (maximum 12 characters) for the Action group."
}
},
"webhookReceiverName": {
"type": "string",
"metadata": {
"description": "Webhook receiver service Name."
}
},
"webhookServiceUri": {
"type": "string",
"metadata": {
"description": "Webhook receiver service URI."
}
}
},
"resources": [
{
"apiVersion": "2018-03-01",
"properties": {
"enabled": true,
"smsReceivers": [
],
"emailReceivers": [
],
{
"name": "[parameters('webhookReceiverName')]",
"serviceUri": "[parameters('webhookServiceUri')]"
}
]
}
}
],
"outputs":{
"actionGroupResourceId":{
"type":"string",
}
}
}
Pasos siguientes
Obtenga más información sobre alertas.
Aprenda a agregar alertas mediante una plantilla de Resource Manager.
Procedimientos para desencadenar acciones
complejas con alertas de Azure Monitor
En este artículo se muestra cómo configurar y desencadenar una aplicación lógica para crear una conversación en
Microsoft Teams cuando se activa una alerta.
Cuando se desencadena una alerta de Azure Monitor, llama a un grupo de acciones. Los grupos de acciones
permiten desencadenar una o varias acciones para notificar sobre la alerta a otros usuarios y también a resolverla.
El proceso general es:
Crear la aplicación lógica para el tipo de alerta respectivo.
Importar una carga de ejemplo para el tipo de alerta respectivo en la aplicación lógica.
Definir el comportamiento de la aplicación lógica.
Copiar el punto de conexión HTTP de la aplicación lógica en un grupo de acciones de Azure.
El proceso es similar si quiere que la aplicación lógica lleve a cabo otra acción.
Creación de una alerta del Registro de actividad: Administrativo

1. En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda.
2. Busque y seleccione Aplicación lógica y luego seleccione Crear .
3. Asigne un Nombre a la aplicación lógica, elija un Grupo de recursos , etc.
4. Seleccione Crear para crear la aplicación lógica. Un mensaje emergente indica que se ha creado la
aplicación lógica. Seleccione Launch Resource (Iniciar recurso) para abrir el diseñador de Logic Apps .
5. Seleccione el desencadenador: Cuando se recibe una solicitud HTTP .
6. Seleccione Editar para cambiar el desencadenador de solicitud HTTP.

7. Seleccione Usar una carga de ejemplo para generar el esquema .
8. Copie y pegue la carga de ejemplo siguiente en el cuadro de diálogo:

{
"data": {
"context": {
"activityLog": {
"authorization": {
"action": "microsoft.insights/activityLogAlerts/write",
"scope": "/subscriptions/…"
},
"claims": "…",
"caller": "logicappdemo@contoso.com",
"correlationId": "91ad2bac-1afa-4932-a2ce-2f8efd6765a3",
"description": "",
"eventDataId": "ec74c4a2-d7ae-48c3-a4d0-2684a1611ca0",
"operationName": "microsoft.insights/activityLogAlerts/write",
"operationId": "61f59fc8-1442-4c74-9f5f-937392a9723c",
"resourceId": "/subscriptions/…",
"resourceGroupName": "LOGICAPP-DEMO",
"resourceProviderName": "microsoft.insights",
"subStatus": "",
"subscriptionId": "…",
"resourceType": "microsoft.insights/activityLogAlerts"
}
},
"properties": {}
}
}
9. El diseñador de Logic App mostrará una ventana emergente para recordarle que la solicitud enviada a la
aplicación lógica debe establecer el encabezado Content-Type en application/json . Cierre la ventana
emergente. La alerta de Azure Monitor establece el encabezado.
10. Seleccione + Nuevo paso y luego elija Agregar una acción .
11. Busque y seleccione el conector de Microsoft Teams. Elija la acción Microsoft Teams – Post message
(Microsoft Teams: publicar mensaje).
12. Configure la acción de Microsoft Teams. El diseñador de Logic Apps le pide que se autentique en su
cuenta de Office 365. Elija el Id. de equipo y el Id. de canal para enviar el mensaje.
13. Configure el mensaje con una combinación de texto estático y referencias a los <fields> del contexto
dinámico. Corte y pegue el texto siguiente en el campo Mensaje :
Activity Log Alert: <eventSource>

operationName: <operationName>
status: <status>
resourceId: <resourceId>
Luego busque y reemplace los <fields> por etiquetas de contenido dinámico con el mismo nombre.
NOTE
Hay dos campos dinámicos denominados status . Agregue ambos campos al mensaje. Use el campo del contenedor
de propiedades activityLog y elimine el otro. Si pasa el puntero sobre el campo status , verá la referencia de campo
completa como se muestra en la captura de pantalla siguiente:
14. En la parte superior del diseñador de Logic Apps , seleccione Guardar para guardar la aplicación lógica.
15. Abra el grupo de acciones existente y agregue una acción para hacer referencia a la aplicación lógica. Si no
existe un grupo de acciones, consulte Creación y administración de grupos de acciones en Azure Portal para
crear uno. No olvide guardar los cambios.
La próxima vez que una alerta llame al grupo de acciones, se llamará a la aplicación lógica.
Creación de una alerta de Service Health

Las entradas de Azure Service Health forman parte del registro de actividad. El proceso de creación de la alerta es
similar a la creación de una alerta de registro de actividad, pero con unos cuantos cambios:
Los pasos del 1 al 7 son iguales.
Para el paso 8, use la carga de ejemplo siguiente para el desencadenador de solicitud HTTP:
{
"data": {
"context": {
"activityLog": {
"channels": "Admin",
"correlationId": "e416ed3c-8874-4ec8-bc6b-54e3c92a24d4",
"description": "…",
"eventSource": "ServiceHealth",
"eventDataId": "9ce152f5-d435-ee31-2dce-104228486a6d",
"operationName": "Microsoft.ServiceHealth/incident/action",
"operationId": "e416ed3c-8874-4ec8-bc6b-54e3c92a24d4",
"properties": {
"title": "...",
"service": "...",
"region": "Global",
"communication": "...",
"incidentType": "Incident",
"trackingId": "...",
"impactStartTime": "2018-03-22T21:40:00.0000000Z",
"impactMitigationTime": "2018-03-22T21:41:00.0000000Z",
"impactedServices": "[{"ImpactedRegions"}]",
"defaultLanguageTitle": "...",
"defaultLanguageContent": "...",
"stage": "Active",
"communicationId": "11000001466525",
"version": "0.1.1"
},
"status": "Active",
"subscriptionId": "...",
}
},
"properties": {}
}
}
Los pasos 9 y 10 son iguales.

Para los pasos 11 a 14, siga este procedimiento:
1. Seleccione + Nuevo paso y luego elija Agregar una condición . Establezca las condiciones
siguientes para que la aplicación lógica solo se ejecute cuando los datos de entrada coincidan con los
siguientes. Cuando especifique el valor de la versión en el cuadro de texto, inclúyalo entre comillas
("0.1.1") para asegurarse de que se evalúa como cadena y no como tipo numérico. El sistema no
muestra las comillas si vuelve a la página, pero el código subyacente conserva el tipo de cadena.
schemaId == Microsoft.Insights/activityLogs
eventSource == ServiceHealth
version == "0.1.1"
2. En la condición if true , siga las instrucciones que aparecen en los pasos 11 a 13 de Creación de una
alerta del registro de actividad para agregar la acción de Teams de Microsoft.
3. Defina el mensaje con una combinación de HTML y contenido dinámico. Corte y pegue el texto
siguiente en el campo Mensaje . Reemplace los campos [incidentType] , [trackingID] , [title] y
[communication] por etiquetas de contenido dinámico con el mismo nombre:
<p>
<b>Alert Type:</b> <strong>[incidentType]</strong>
<strong>Tracking ID:</strong> [trackingId]
<strong>Title:</strong> [title]</p>
<p>
<a
href="https://ms.portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade/serviceIs
sues">For details, log in to the Azure Service Health dashboard.</a>
</p>
<p>[communication]</p>
4. Para la condición If false , proporcione un mensaje útil:
<p><strong>Service Health Alert</strong></p>

<p><b>Unrecognized alert schema</b></p>
<p><a
href="https://ms.portal.azure.com/#blade/Microsoft_Azure_Health/AzureHealthBrowseBlade/serviceIs
sues">For details, log in to the Azure Service Health dashboard.\</a></p>
El paso 15 es igual. Siga las instrucciones para guardar la aplicación lógica y actualizar el grupo de acciones.
Creación de una alerta de métrica

El proceso de creación de una alerta de métrica es similar a la creación de una alerta de registro de actividad, pero
con unos cuantos cambios:
Los pasos del 1 al 7 son iguales.
Para el paso 8, use la carga de ejemplo siguiente para el desencadenador de solicitud HTTP:
{
"schemaId": "AzureMonitorMetricAlert",
"data": {
"version": "2.0",
"context": {
"timestamp": "2018-04-09T19:00:07.7461615Z",
"id": "...",
"name": "TEST-VM CPU Utilization",
"description": "",
"condition": {
"allOf": [
{
"dimensions": [
{
"value": "d92fc5cb-06cf-4309-8c9a-538eea6a17a6"
}
],
"threshold": "5",
"timeAggregation": "PT15M",
"metricValue": 1.0
}
]
},
"subscriptionId": "...",
"resourceGroupName": "TEST",
"resourceName": "test-vm",
"resourceType": "Microsoft.Compute/virtualMachines",
"resourceId": "...",
"portalLink": "..."
},
"properties": {}
}
}
Los pasos 9 y 10 son iguales.

Para los pasos 11 a 14, siga este procedimiento:
1. Seleccione + Nuevo paso y luego elija Agregar una condición . Establezca las condiciones
siguientes para que la aplicación lógica solo se ejecute cuando los datos de entrada coincidan con los
siguientes. Cuando especifique el valor de la versión en el cuadro de texto, inclúyalo entre comillas
("2.0") para asegurarse de que se evalúa como cadena y no como tipo numérico. El sistema no
muestra las comillas si vuelve a la página, pero el código subyacente conserva el tipo de cadena.
schemaId == AzureMonitorMetricAlert
version == "2.0"
2. En la condición if true , agregue un bucle For each y la acción de Microsoft Teams. Defina el
mensaje con una combinación de HTML y contenido dinámico.
3. En la condición If false , defina una acción de Microsoft Teams que comunique que la alerta de
métrica no coincide con las expectativas de la aplicación lógica. Incluya la carga de JSON. Observe
cómo hacer referencia al contenido dinámico de triggerBody en la expresión json() .
El paso 15 es igual. Siga las instrucciones para guardar la aplicación lógica y actualizar el grupo de acciones.
Llamada a otras aplicaciones además de Microsoft Teams

Logic Apps tiene una serie de distintos conectores que permiten desencadenar acciones en una amplia gama de
aplicaciones y bases de datos. Slack, SQL Server, Oracle, Salesforce, son solo algunos ejemplos. Para más
información sobre los conectores, consulte Conectores de Logic App.
Pasos siguientes
Consulte la introducción a las alertas del registro de actividad de Azure y aprenda cómo puede recibir alertas.
Aprenda a configurar alertas siempre que se publique una notificación de Azure Service Health.
Grupos inteligentes
Un desafío común al gestionar las alertas consiste en cribar el ruido para averiguar lo que realmente importa: los
grupos inteligentes están diseñados para ser la solución a ese problema.
Los grupos inteligentes se crean de manera automática a través de algoritmos de aprendizaje automático para
combinar las alertas relacionadas que representan un solo problema. Cuando se crea una alerta, el algoritmo la
agrega a un grupo inteligente nuevo o a un grupo inteligente existente según información como los patrones
históricos, las propiedades similares y la estructura similar. Por ejemplo, si el porcentaje de CPU en varias
máquinas virtuales de una suscripción alcanza su máximo simultáneamente dando lugar a muchas alertas
individuales y, si estas alertas se han producido juntas en cualquier momento pasado, es probable que se agrupen
en un único grupo inteligente, lo que sugiere una posible causa principal común. Esto significa que para los
usuarios que solucionan los problemas de las alertas, los grupos inteligentes no solo les permiten reducir el ruido
mediante la administración de las alertas relacionadas como una única unidad agregada, sino que también les
orientan hacia las posibles causas raíz comunes de sus alertas.
Actualmente, el algoritmo solo considera las alertas provenientes del mismo servicio de supervisión dentro de una
suscripción. Los grupos inteligentes pueden reducir hasta un 99 por ciento de ruido de alertas a través de esta
consolidación. Puede ver la razón por la que las alertas se incluyeron en un grupo en la página de detalles del
grupo inteligente.
Puede ver los detalles de los grupos inteligentes y establecer el estado de manera similar a las alertas. Cada alerta
forma parte de un solo grupo inteligente.
Estado de grupo inteligente

El estado de grupo inteligente es un concepto similar al estado de alerta, que le permite administrar el proceso de
resolución en el nivel de un grupo inteligente. Al igual que el estado de alerta, cuando se crea un grupo inteligente,
tiene el estado Nuevo , que se puede cambiar a Confirmado o Cerrado .
Se admiten los siguientes estados de grupo inteligente.
STAT E DESC RIP C IÓ N
Nuevo Se acaba de detectar el problema y todavía no se ha revisado.
Confirmado Un administrador revisó el grupo inteligente y empezó a

trabajar en él.
Closed Se resolvió el problema. Después de cerrar un grupo

inteligente, puede volver a abrirlo mediante el cambio a otro
estado.
Obtenga información sobre cómo cambiar el estado del grupo inteligente.
NOTE
El cambio de estado de un grupo inteligente no modifica el estado de las alertas individuales que lo componen.
Página de detalles del grupo inteligente
La página de detalles del grupo inteligente se muestra al seleccionar un grupo inteligente. Proporciona detalles
acerca del grupo inteligente, incluido el razonamiento que se usó para crear el grupo, y le permite cambiar su
estado.
La página de detalles del grupo inteligente incluye las secciones siguientes.
Alertas Muestra las alertas individuales que se incluyen en el grupo

inteligente. Seleccione una alerta para abrir su página de
detalles de la alerta.
Historial Muestra cada acción que realiza el grupo inteligente y los

cambios hechos en él. Se limita actualmente a los cambios de
estado y a los cambios de pertenencia de una alerta.
Taxonomía del grupo inteligente

El nombre de un grupo inteligente es el nombre de su primera alerta. No se puede crear ni cambiar el nombre de
un grupo inteligente.
Pasos siguientes
Cambio de estado de alerta y de grupo inteligente
Administrar instancias de alerta con alertas unificadas
Gracias a la experiencia de alertas unificadas en Azure Monitor, puede ver todos los tipos de alertas en Azure. Aquí
se abarcan varias suscripciones en un solo panel. En este artículo se explica cómo puede ver sus instancias de
alerta y cómo buscar instancias de alerta específicas para la solución de problemas.
NOTE
Solo puede acceder a las alertas generadas en los últimos 30 días.
Ir a la página de alertas
Puede ir a la página de alertas de cualquiera de las siguientes maneras:
En Azure Portal, seleccione Monitor > Aler tas .
Use el contexto de un recurso específico. Abra un recurso, vaya a la sección de super visión y seleccione
Aler tas . La página de aterrizaje se filtrará previamente para mostrar las alertas de ese recurso específico.
Use el contexto de un grupo de recursos específico. Abra un grupo de recursos, vaya a la sección de
super visión y seleccione Aler tas . La página de aterrizaje se filtrará previamente para mostrar las alertas
de ese grupo de recursos específico.
Buscar instancias de alertas
La página Resumen de aler tas le proporciona información general de todas sus instancias de alerta en Azure.
Puede modificar la vista de resumen seleccionando varias suscripciones (hasta un máximo de 5) o filtrando por
grupos de recursos , ya sean recursos o inter valos de tiempo específicos. Haga clic en Aler tas totales o en
cualquiera de las bandas de gravedad para ir a la vista de lista de sus alertas.
En la página Todas las aler tas se muestran todas las instancias de alerta en Azure. Si accede al portal desde una
notificación de alerta, puede usar los filtros disponibles para limitar esa instancia de alerta específica.
NOTE
Si llegó a la página haciendo clic en cualquiera de las bandas de gravedad, la lista se filtrará previamente en función de esa
gravedad.
Además de los filtros disponibles en la página anterior, también puede realizar procesos de filtrado en función del
servicio de supervisión (por ejemplo, Plataforma para métricas), la condición de la supervisión (activada o
resuelta), la gravedad, el estado de las alertas (nueva, confirmada y cerrada), o el id. de grupo inteligente.
NOTE
Si llegó a la página haciendo clic en cualquiera de las bandas de gravedad, la lista se filtrará previamente en función de esa
gravedad.
Al seleccionar cualquier instancia de alerta, se abre la página Detalles de aler ta , lo que le permite obtener más
detalles sobre esa instancia de alerta específica.
Los grupos inteligentes usan algoritmos de aprendizaje automático para agrupar las alertas en función de su
concurrencia o similitud, a fin de que el usuario ahora pueda administrar grupos inteligentes en lugar de tener que
administrar individualmente cada alerta. En este artículo le guiaremos por el proceso de obtener acceso a grupos
inteligentes y de usarlos en Azure Monitor.
1. Para ver los grupos inteligentes creados para sus instancias de alerta puede hacer una de las siguientes
opciones:
a. Hacer clic en Grupos inteligentes en la página Resumen de aler tas .
b. Hacer clic en Alertas por grupos inteligentes (Alerts by Smart Groups) en la página de todas las
alertas.
2. Esto le llevará a la vista con la lista de todos los grupos inteligentes creados mediante las instancias de
alerta. En lugar de examinar varias alertas, ahora puede usar los grupos inteligentes.
3. Al hacer clic en cualquier grupo inteligente, se abre la página de detalles, donde puede ver el motivo de la
agrupación, junto con las alertas que lo componen. Esta agregación le permite lidiar con un único grupo
inteligente, en lugar de examinar varias alertas.
Administración de estados de alertas y de grupos
inteligentes
Las alertas en Azure Monitor ahora tienen un estado de alerta y una condición de supervisión y, de forma similar,
los grupos inteligentes tienen un estado de grupo inteligente. Los cambios en el estado ahora se registran en el
historial que está asociado a la alerta o al grupo inteligente. Este artículo le guiará a través del proceso de cambiar
el estado de las alertas y los grupos inteligentes.
Cambio en el estado de una alerta

1. Puede cambiar el estado de una alerta de las siguientes formas:
En la página Todas las alertas, haga clic en la casilla de verificación situada junto a las alertas cuyo
estado desea cambiar y, después, en Cambiar estado.
Puede hacer clic en Cambiar estado desde la página Detalles de la alerta de una instancia de alerta
específica
En la página Detalles de la alerta de una instancia de alerta específica, dentro del panel Grupo
inteligente, puede hacer clic en la casilla de verificación junto a las alertas que quiera
En la página Detalles del grupo inteligente, puede marcar la casilla al lado de las alertas que
aparecen en la lista de miembros si desea cambiar su estado y, a continuación, puede hacer clic en
Cambiar estado.
2. Al hacer clic en Cambiar estado, se abre un menú emergente que permite seleccionar el estado (Nuevo,
Confirmado o Cerrado) y escribir un comentario si es necesario.
3. Una vez hecho esto, el cambio de estado se registra en el historial de la alerta correspondiente. Puede
comprobar que se haya registrado si abre la página de detalles correspondiente y observa la sección de
historial.
Cambios en el estado del grupo inteligente
1. Puede cambiar el estado de un grupo inteligente de las siguientes formas:
a. En la página con la lista de grupos inteligentes, puede hacer clic en la casilla de verificación situada
junto a los grupos inteligentes cuyo estado desea cambiar y, después, en Cambiar estado
b. En la página de detalles del grupo inteligente, puede hacer clic en Cambiar estado
2. Al hacer clic en Cambiar estado, se abre un menú emergente que permite seleccionar el estado (Nuevo,
Confirmado o Cerrado) y escribir un comentario si es necesario.
NOTE
El cambio de estado de un grupo inteligente no modifica el estado de las alertas individuales que lo componen.
3. Una vez hecho esto, el cambio de estado se registra en el historial del grupo inteligente correspondiente.
Puede comprobar que se haya registrado si abre la página de detalles correspondiente y observa la
sección de historial.
Administración de alertas de System Center
Operations Manager, Zabbix y Nagios en Azure
Monitor
Ahora puede ver las alertas de Nagios, Zabbix y System Center Operations Manager en Azure Monitor. Estas
alertas proceden de integraciones con servidores Nagios o Zabbix o con System Center Operations Manager en
Log Analytics.
Prerrequisitos
Los registros del repositorio de Log Analytics con un tipo de alerta se importarán a Azure Monitor, por lo que debe
realizar las configuraciones que sean necesarias para recopilar estos registros.
1. Para las alertas de Nagios y Zabbix , configure esos servidores para que envíen alertas a Log Analytics.
2. Para las alertas de System Center Operations Manager ,conecte el grupo de administración de Operations
Manager al área de trabajo de Log Analytics. A continuación, implemente la solución Alert Management desde
Azure Marketplace. Una vez hecho esto, las alertas creadas en System Center Operations Manager se importan
en Log Analytics.
Visualización de las instancias de alertas

Una vez que haya configurado la importación en Log Analytics, puede empezar a ver instancias de alertas de estos
servicios de supervisión en Azure Monitor. Una vez que están presentes en Azure Monitor, podrá administrar las
instancias de alertas, administrar los grupos inteligentes creados en estas alertas y cambiar el estado de las alertas
y de los grupos inteligentes.
NOTE
1. Esta solución solo le permite ver instancias de alertas desencadenadas por System Center Operations Manager, Zabbix y
Nagios en Azure Monitor. La configuración de la regla de alertas solo se puede ver y editar en las correspondientes
herramientas de supervisión.
2. Todas las instancias de alertas desencadenadas estarán disponibles en Azure Monitor y en Azure Log Analytics. En la
actualidad, no hay manera de elegir entre los dos o de ingerir solo alertas desencadenadas específicas.
3. Todas las alertas de System Center Operations Manager, Zabbix y Nagios tienen el tipo de señal "Desconocido", ya que el
tipo de datos de telemetría subyacente no está disponible.
4. Las alertas de Nagios no tienen estado; por ejemplo, la condición de supervisión de una alerta no pasará de "Activada" a
"Resuelta". En su lugar, "Activada" y "Resuelta" se muestran como instancias independientes de la alerta.
Creación y administración de reglas de alerta de
Log Analytics con la API de REST
La API REST de alertas de Log Analytics le permite crear y administrar alertas en Log Analytics. En este
artículo encontrará información detallada sobre la API y varios ejemplos para realizar distintas
operaciones.
IMPORTANT
Como se anunció anteriormente, las áreas de trabajo de Log Analytics creadas después del 1 de junio de 2019
podrán administrar reglas de alerta únicamente mediante la API REST scheduledQueryRules de Azure, la plantilla
de Azure Resource Manager y el cmdlet de PowerShell. Los clientes pueden cambiar fácilmente su forma preferida
de administración de reglas de alertas para que las áreas de trabajo anteriores aprovechen scheduledQueryRules
de Azure Monitor como valor predeterminado y consigan muchas de las nuevas ventajas, como la posibilidad de
usar cmdlets nativos de PowerShell, el aumento del período de retrospectiva en las reglas, la creación de reglas en
un grupo de recursos o una suscripción independientes y mucho más.
La API de REST de búsqueda de Log Analytics es de tipo RESTful y se puede obtener acceso a ella a través
de la API de REST de Azure Resource Manager. En este documento encontrará ejemplos donde se tiene
acceso a la API desde una línea de comandos de PowerShell a través de ARMClient, una herramienta de
línea de comandos de código abierto que simplifica la tarea de invocar a la API de Azure Resource
Manager. El uso de ARMClient y PowerShell es una de las muchas opciones para tener acceso a la API de
búsqueda de Log Analytics. Con estas herramientas, puede usar la API de RESTful de Azure Resource
Manager para realizar llamadas a las áreas de trabajo de Log Analytics y ejecutar comandos de búsqueda
dentro de ellas. La API generará resultados de búsqueda, en formato JSON, lo que le permite usar los
resultados de búsqueda de muchas formas distintas mediante programación.
Prerrequisitos
Actualmente, solo se pueden crear alertas con una búsqueda guardada en Log Analytics. Para obtener
más información, consulte API de búsqueda de registros de Log Analytics .
Programaciones
Una búsqueda guardada puede tener una o varias programaciones. La programación define la frecuencia
con que se realiza la búsqueda y el intervalo de tiempo en el que se identifican los criterios. Las
programaciones tienen las propiedades de la siguiente tabla.
Intervalo Frecuencia con que se realiza la búsqueda. Se mide en

minutos.
QueryTimeSpan Intervalo de tiempo en el que se evalúan los criterios.

Debe ser igual o mayor que Intervalo. Se mide en
minutos.
Versión Versión de API en uso. Actualmente, siempre debe estar

establecida en 1.
Por ejemplo, en una consulta de evento con un valor de Intervalo de 15 minutos y un valor de Timespan
de 30 minutos, la consulta se ejecutaría cada 15 minutos y se desencadenaría una alerta si los criterios
siguieran evaluándose como True durante un intervalo de 30 minutos.
Recuperar programaciones
Use el método Get para recuperar todas las programaciones de una búsqueda guardada.
armclient get /subscriptions/{Subscription

ID}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{Workspace
Name}/savedSearches/{Search ID}/schedules?api-version=2015-03-20
Use el método Get con un identificador de programación para recuperar una programación concreta de
una búsqueda guardada.

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}?api-version=2015-03-20
La siguiente es una respuesta de ejemplo de una programación.
{
"value": [{
"id": "subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/sampleRG/providers/Microsoft.OperationalInsights/workspaces/MyWorkspace/s
avedSearches/0f0f4853-17f8-4ed1-9a03-8e888b0d16ec/schedules/a17b53ef-bd70-4ca4-9ead-83b00f2024a8",
"etag": "W/\"datetime'2016-02-25T20%3A54%3A49.8074679Z'\"",
"properties": {
"Interval": 15,
"QueryTimeSpan": 15,
"Enabled": true,
}
}]
}
Creación de una programación

Use el método Put con un identificador de programación único para crear una programación nueva. Dos
programaciones no pueden tener el mismo identificador, aunque estén asociadas a diferentes búsquedas
guardadas. Al crear una programación en la consola de Log Analytics, se crea un GUID para el
identificador de programación.
NOTE
El nombre de todas las búsquedas guardadas, programaciones y acciones creadas con Log Analytics API debe
estar en minúsculas.
$scheduleJson = "{'properties': { 'Interval': 15, 'QueryTimeSpan':15, 'Enabled':'true' } }"

armclient put /subscriptions/{Subscription
Name}/savedSearches/{Search ID}/schedules/mynewschedule?api-version=2015-03-20 $scheduleJson
Edición de una programación
Utilice el método Put con un identificador de programación existente para modificar la programación de
la misma búsqueda guardada. En el ejemplo siguiente, la programación está deshabilitada. El cuerpo de la
solicitud debe incluir el valor etag de la programación.
$scheduleJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A49.8074679Z'\""','properties': {

'Interval': 15, 'QueryTimeSpan':15, 'Enabled':'false' } }"
Name}/savedSearches/{Search ID}/schedules/mynewschedule?api-version=2015-03-20 $scheduleJson
Eliminar programaciones
Para eliminar una programación, use el método Delete con un identificador de programación.
armclient delete /subscriptions/{Subscription

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}?api-version=2015-03-20
Acciones
Una programación puede tener varias acciones. Una acción puede definir uno o varios procesos que se
van a realizar (como enviar un correo o iniciar un Runbook), o bien puede definir un umbral que
determina si los resultados de una búsqueda coinciden con algunos criterios. Algunas acciones definen
ambos aspectos, de forma que los procesos se realizan cuando se alcance el umbral.
Todas las acciones tienen las propiedades de la siguiente tabla. Los distintos tipos de alertas tienen
diferentes propiedades adicionales, descritas aquí.
Type Tipo de la acción. Actualmente, los valores posibles son

Alert y Webhook.
Name Nombre para mostrar de la alerta.
Version Versión de API en uso. Actualmente, siempre debe estar

establecida en 1.
Recuperar acciones
Use el método Get para recuperar todas las acciones de una programación.

Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions?api-version=2015-03-20
Use el método Get con el identificador de una acción para recuperar esa acción concreta para una
programación.

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}/actions/{Action ID}?api-version=2015-
03-20
Crear o editar acciones
Para crear una acción, use el método Put con un identificador de acción único de la programación. Al crear
una acción en la consola de Log Analytics, se crea un GUID para el identificador de acción.
NOTE
El nombre de todas las búsquedas guardadas, programaciones y acciones creadas con Log Analytics API debe
estar en minúsculas.
Utilice el método Put con un identificador de acción existente para modificar la programación de la
misma búsqueda guardada. El cuerpo de la solicitud debe incluir el valor etag de la programación.
El formato de solicitud para crear una acción varía según el tipo de acción. En las secciones siguientes se
proporcionan ejemplos.
Eliminar acciones
Use el método Delete con el identificador de acción para eliminar esa acción.
armclient delete /subscriptions/{Subscription

Name}/savedSearches/{Subscription ID}/schedules/{Schedule ID}/Actions/{Action ID}?api-version=2015-
03-20
Acciones de alerta
Una programación debe tener una acción de alerta única y exclusivamente. Las acciones de alerta tienen
una o varias de las secciones de la siguiente tabla. Cada una de ellas se describe con más detalle abajo.
SEC C IÓ N DESC RIP C IÓ N USO
Umbral Criterios para establecer cuándo se Se requiere para cada alerta, ya sea
va a ejecutar la acción. antes o después de extenderlas a
Azure.
severity Etiqueta que se usa para clasificar la Se requiere para cada alerta, ya sea
alerta cuando se desencadena. antes o después de extenderlas a
Azure.
Suprimir Opción para dejar de recibir Opcional para cada alerta, ya sea
notificaciones de la alerta. antes o después de extenderlas a
Azure.
Grupos de acciones Identificadores para Azure Se requiere una vez que las alertas
ActionGroup donde se especifican se extienden a Azure
las acciones requeridas, como
correos electrónicos, mensajes SMS,
llamadas de voz, webhooks,
runbooks de Automation,
conectores ITSM, etc.
Personalizar las acciones Modifica la salida estándar para Opcional para cada alerta, se puede
seleccionar acciones en ActionGroup usar después de que las alertas se
extienden a Azure.
Umbrales
Una acción de alerta debe tener un umbral única y exclusivamente. Cuando los resultados de una
búsqueda guardada coinciden con el umbral de una acción asociada a esa búsqueda, se ejecutan los
demás procesos de esa acción. Una acción también puede contener solo un umbral para que pueda
usarse con acciones de otros tipos que no contienen umbrales.
Los umbrales tienen las propiedades de la siguiente tabla.
Operator Operador de la comparación de umbral.

gt = Mayor que
lt = Menor que
Value Valor del umbral.
Por ejemplo, en una consulta de evento con un valor de Intervalo de 15 minutos, un valor de Timespan de
30 minutos y un valor de Threshold mayor que 10, la consulta se ejecutaría cada 15 minutos y se
desencadenaría una alerta si devolviera 10 eventos creados durante un intervalo de 30 minutos.
La siguiente es una respuesta de ejemplo de una acción con un solo umbral.
"properties": {
"Type": "Alert",
"Name": "My threshold action",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Version": 1
}
Use el método Put con un identificador de acción único para crear una acción de umbral para una
programación.
$thresholdJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1', 'Type':'Alert',

'Threshold': { 'Operator': 'gt', 'Value': 10 } } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/mythreshold?api-version=2015-03-20
$thresholdJson
Use el método Put con un identificador de acción existente para modificar una acción de umbral para una
programación. El cuerpo de la solicitud debe incluir el valor etag de la acción.
$thresholdJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': { 'Name':

'My Threshold', 'Version':'1', 'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 10 } } }"
$thresholdJson
severity
Log Analytics permite clasificar las alertas en categorías, para permitir una administración y una
evaluación de prioridades más sencillas. La gravedad de la alerta que se define es: informativa,
advertencia y crítica. Estos valores se asignan a la escala de gravedad normalizada de Alertas de Azure
como:
N IVEL DE GRAVEDA D DE LO G A N A LY T IC S N IVEL DE GRAVEDA D DE A L ERTA S DE A Z URE
critical Gravedad 0
warning Gravedad 1
informational Gravedad 2
La siguiente es una respuesta de ejemplo de una acción con un solo umbral y gravedad.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Severity": "critical",
"Version": 1
}
Use el método Put con un identificador de acción único para crear una acción para una programación con
gravedad.
$thresholdWithSevJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1','Severity':

'critical', 'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 10 } } }"
$thresholdWithSevJson
Use el método Put con un identificador de acción existente para modificar una acción de gravedad para
una programación. El cuerpo de la solicitud debe incluir el valor etag de la acción.
$thresholdWithSevJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': {

'Name': 'My Threshold', 'Version':'1','Severity': 'critical', 'Type':'Alert', 'Threshold': {
'Operator': 'gt', 'Value': 10 } } }"
$thresholdWithSevJson
Suprimir
Las alertas de consulta basadas en Log Analytics se activarán cada vez que se alcance o supere el umbral.
Según la lógica implicada en la consulta, esto puede producir que la alerta se active en una serie de
intervalos y, por tanto, también se envíen notificaciones constantemente. Para evitar estos escenarios, un
usuario puede establecer la opción de suprimir para indicar a Log Analytics que debe esperar durante un
período de tiempo estipulado antes de que la notificación se desencadene por segunda vez para la regla
de alertas. Por lo tanto, si la supresión se establece en 30 minutos, la alerta se activará la primera vez y
enviará las notificaciones configuradas. Pero, a continuación, espera 30 minutos antes de volver a utilizar
la notificación para la regla de alertas. En el período transitorio, la regla de alertas se seguirá ejecutando:
Log Analytics solo suprime la notificación durante el tiempo especificado, independientemente de
cuántas veces se desencadena la regla de alertas durante este período.
La propiedad de supresión de la regla de alertas de Log Analytics se especifica con el valor Throttling y el
período de supresión mediante el valor DurationInMinutes.
La siguiente es una respuesta de ejemplo de una acción con un solo umbral, la gravedad y la propiedad
de supresión.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 10
},
"Throttling": {
"DurationInMinutes": 30
},
"Version": 1
}
Use el método Put con un identificador de acción único para crear una acción para una programación con
gravedad.
$AlertSuppressJson = "{'properties': { 'Name': 'My Threshold', 'Version':'1','Severity': 'critical',

'Type':'Alert', 'Throttling': { 'DurationInMinutes': 30 },'Threshold': { 'Operator': 'gt', 'Value':
10 } } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/myalert?api-version=2015-03-20
$AlertSuppressJson
Use el método Put con un identificador de acción existente para modificar una acción de gravedad para
una programación. El cuerpo de la solicitud debe incluir el valor etag de la acción.
$AlertSuppressJson = "{'etag': 'W/\"datetime'2016-02-25T20%3A54%3A20.1302566Z'\"','properties': {

'Name': 'My Threshold', 'Version':'1','Severity': 'critical', 'Type':'Alert', 'Throttling': {
'DurationInMinutes': 30 },'Threshold': { 'Operator': 'gt', 'Value': 10 } } }"
Name}/savedSearches/{Search ID}/schedules/{Schedule ID}/actions/myalert?api-version=2015-03-20
$AlertSuppressJson
Grupos de acciones
Todas las alertas de Azure usan el grupo de acciones como el mecanismo predeterminado para controlar
las acciones. Con el grupo de acciones, puede especificar las acciones una vez y, luego, asociar el grupo de
acciones a varias alertas en todo Azure, sin la necesidad de declarar repetidamente una y otra vez las
mismas acciones. Los grupos de acciones admiten varias acciones, incluido el correo electrónico, SMS,
llamadas de voz, conexión ITSM, runbook de Automation, URI de webhook, etc.
Para los usuarios que han extendido sus alertas a Azure, ahora una programación tendrá los detalles del
grupo de acciones junto con el umbral, para así poder crear una alerta. Antes de crear una alerta, es
necesario definir los detalles de correo electrónico, las direcciones URL de webhooks, los detalles de
automatización de runbooks y otras acciones dentro de un grupo de acciones. Es posible crear un grupo
de acciones desde Azure Monitor en el portal o usar la API Action Group.
Para agregar la asociación de un grupo de acciones a una alerta, especifique el identificador de Azure
Resource Manager único del grupo de acciones en la definición de la alerta. A continuación, aparece una
ilustración de ejemplo:
"properties": {
"Type": "Alert",
"Name": "test-alert",
"Description": "I need to put a description here",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"AzNsNotification": {
"GroupIds": [
"/subscriptions/1234a45-123d-4321-12aa-123b12a5678/resourcegroups/my-resource-
group/providers/microsoft.insights/actiongroups/test-actiongroup"
]
},
"Version": 1
}
Use el método Put con un identificación de acción único para asociar el grupo de acciones ya existente
para una programación. Esta es una ilustración de ejemplo del uso.
$AzNsJson = "{'properties': { 'Name': 'test-alert', 'Version':'1', 'Type':'Alert', 'Threshold': {

'Operator': 'gt', 'Value': 12 },'Severity': 'critical', 'AzNsNotification': {'GroupIds':
['subscriptions/1234a45-123d-4321-12aa-123b12a5678/resourcegroups/my-resource-
group/providers/microsoft.insights/actiongroups/test-actiongroup']} } }"
armclient put /subscriptions/{Subscription ID}/resourceGroups/{Resource Group
Name}/Microsoft.OperationalInsights/workspaces/{Workspace Name}/savedSearches/{Search
ID}/schedules/{Schedule ID}/actions/myAzNsaction?api-version=2015-03-20 $AzNsJson
Use el método Put con un identificador de acción existente para modificar un grupo de acciones asociado
para una programación. El cuerpo de la solicitud debe incluir el valor etag de la acción.
$AzNsJson = "{'etag': 'datetime'2017-12-13T10%3A52%3A21.1697364Z'\"', 'properties': { 'Name': 'test-

alert', 'Version':'1', 'Type':'Alert', 'Threshold': { 'Operator': 'gt', 'Value': 12 },'Severity':
'critical', 'AzNsNotification': { 'GroupIds': ['subscriptions/1234a45-123d-4321-12aa-
123b12a5678/resourcegroups/my-resource-group/providers/microsoft.insights/actiongroups/test-
actiongroup'] } } }"
Personalizar las acciones

En el caso de las acciones predeterminadas, siga la plantilla y el formato estándar para las notificaciones.
Pero los usuarios pueden personalizar algunas acciones, incluso si los controlan los grupos de acciones.
Actualmente, es posible personalizar el asunto del correo electrónico y la carga del webhook.
P e r so n a l i z a c i ó n d e l a su n t o d e l c o r r e o e l e c t r ó n i c o p a r a e l g r u p o d e a c c i o n e s
De manera predeterminada, el asunto del correo electrónico para las alertas es: Notificación de alerta
<AlertName> para <WorkspaceName> . Pero se puede personalizar, de modo que pueda especificar palabras
o etiquetas, para permitirle emplear fácilmente reglas de filtro en la Bandeja de entrada. Los detalles del
encabezado del correo electrónico personalizado se deben enviar junto con los detalles de ActionGroup,
como se muestra en el ejemplo siguiente.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"GroupIds": [
],
"CustomEmailSubject": "Azure Alert fired"
},
"Version": 1
}
con una personalización para una programación. Esta es una ilustración de ejemplo del uso.

group/providers/microsoft.insights/actiongroups/test-actiongroup'], 'CustomEmailSubject': 'Azure
Alert fired'} } }"

'critical', 'AzNsNotification': {'GroupIds': ['subscriptions/1234a45-123d-4321-12aa-
actiongroup']}, 'CustomEmailSubject': 'Azure Alert fired' } }"
P e r so n a l i z a c i ó n d e l a c a r g a d e W e b h o o k p a r a u n g r u p o d e a c c i o n e s
De manera predeterminada, el webhook enviado a través del grupo de acciones para Log Analytics tiene
una estructura fija. Sin embargo, un usuario puede personalizar la carga de JSON si usa variables
específicas admitidas para cumplir con los requisitos del punto de conexión del webhook. Para más
información, consulte Acciones de webhook para reglas de alertas de registro.
Los detalles del webhook personalizado se deben enviar junto con los detalles de ActionGroup y se
aplicarán a todo los URI del webhook especificados dentro del grupo de acciones, como se indica en el
ejemplo a continuación.
"properties": {
"Type": "Alert",
"Threshold": {
"Operator": "gt",
"Value": 12
},
"GroupIds": [
],
"CustomWebhookPayload": "{\"field1\":\"value1\",\"field2\":\"value2\"}",
"CustomEmailSubject": "Azure Alert fired"
},
"Version": 1
},
con una personalización para una programación. Esta es una ilustración de ejemplo del uso.

group/providers/microsoft.insights/actiongroups/test-actiongroup'], 'CustomEmailSubject': 'Azure
Alert fired','CustomWebhookPayload': '{\"field1\":\"value1\",\"field2\":\"value2\"}'} } }"

'critical', 'AzNsNotification': {'GroupIds': ['subscriptions/1234a45-123d-4321-12aa-
actiongroup']}, 'CustomEmailSubject': 'Azure Alert fired','CustomWebhookPayload':
'{\"field1\":\"value1\",\"field2\":\"value2\"}' } }"
Pasos siguientes
Use la API de búsqueda de registros de Log Analytics en Log Analytics.
Más información sobre las alertas de registro en Azure Monitor
Creación, edición o administración de reglas de alertas de registro en Azure Monitor
Solución de problemas en las alertas de Azure
Monitor
En este artículo se describen los problemas comunes en las alertas y notificaciones de Azure Monitor.
Las alertas de Azure Monitor le informan de forma proactiva cuando se detectan condiciones importantes en los
datos que se supervisan. Le permiten identificar y solucionar los problemas antes de que los usuarios del sistema
puedan verlos. Para más información sobre las alertas, consulte Información general sobre las alertas en
Microsoft Azure.
Si tiene un problema en el que a veces una alerta no se desencadena según lo esperado, consulte los artículos
siguientes. Puede ver las alertas "desencadenadas" en Azure Portal.
Solución de problemas con las alertas de métricas de Azure Monitor en Microsoft Azure
Solución de problemas con las alertas de registro de Azure Monitor en Microsoft Azure
Si la alerta se desencadena según lo previsto en Azure Portal, pero no se generan las notificaciones adecuadas,
use la información que se encuentra a lo largo de este artículo para solucionar ese problema.
La acción o notificación de mi alerta no funcionó como se esperaba

Si puede ver una alerta desencadenada en Azure Portal, pero tiene un problema con algunas de sus acciones o
notificaciones, consulte las secciones siguientes.
No se recibió el correo electrónico esperado

Si puede ver una alerta desencadenada en Azure Portal, pero no recibió el correo electrónico que ha configurado
para ello, siga estos pasos:
1. ¿Se suprimió el correo electrónico mediante una regla de acción ?
Compruébelo haciendo clic en la alerta desencadenada en el portal y examine la pestaña Historial en busca
de los grupos de acciones suprimidos:
2. ¿Está el tipo de acción "Rol de Azure Resource Manager de correo electrónico"?

Esta acción solo examina las asignaciones de roles de Azure Resource Manager que se encuentran en el
ámbito de la suscripción y de tipo Usuario. Asegúrese de que ha asignado el rol en el nivel de suscripción y
no en el nivel de recurso o de grupo de recursos.
3. ¿El ser vidor de correo electrónico y el buzón aceptan correos electrónicos externos?
Compruebe que no se bloqueen los mensajes de correo electrónico de estas tres direcciones:
azure-noreply@microsoft.com
azureemail-noreply@microsoft.com
alerts-noreply@mail.windowsazure.com
Es habitual que las listas de distribución de correo o las listas postales internas bloqueen correos
electrónicos de direcciones de correo electrónico externas. Debe permitir el correo de las direcciones de
correo electrónico anteriores.
Para probarlo, agregue una dirección de correo electrónico del trabajo convencional (no una lista de
distribución de correo) al grupo de acciones y compruebe si las alertas llegan a ese correo electrónico.
4. ¿El correo electrónico lo procesaron reglas de la bandeja de entrada o un filtro de correo no
deseado?
Compruebe que no hay ninguna regla de bandeja de entrada que elimine esos mensajes de correo
electrónico o los mueva a otra carpeta. Por ejemplo, las reglas de bandeja de entrada podrían detectar
remitentes específicos o palabras concretas en el asunto.
Compruebe también:
la configuración del correo no deseado de su cliente de correo electrónico (como Outlook o Gmail)
los límites del remitente, la configuración del correo no deseado y la configuración de la
cuarentena del servidor de correo electrónico (como Exchange, Office 365 o G-Suite)
la configuración de la aplicación de seguridad de correo electrónico, si existe (como Barracuda o
Cisco).
5. ¿Ha cancelado la suscripción al grupo de acciones accidentalmente?
Los correos electrónicos de alerta proporcionan un vínculo para cancelar la suscripción al grupo de
acciones. Para comprobar si ha cancelado la suscripción a este grupo de acciones accidentalmente, puede
realizar una de estas acciones:
a. Abrir el grupo de acciones en el portal y comprobar la columna Estado:
b. Buscar en el correo electrónico la confirmación de cancelación de suscripción:
Para suscribirse de nuevo, use el vínculo del correo electrónico de confirmación de cancelación de
suscripción que ha recibido, o bien quite la dirección de correo electrónico del grupo de acciones y luego
vuelva a agregarla.
6. ¿Se le ha limitado la tasa debido a que muchos correos electrónicos van a una sola dirección
de correo electrónico?
El correo electrónico tiene una tasa limitada de no más de cien mensajes de correo electrónico cada hora
para cada dirección. Si supera este umbral, se quitan las notificaciones de correo electrónico adicionales.
Compruebe si ha recibido un mensaje que indica que la dirección de correo electrónico tiene limitado el
número de correos temporalmente:
Si desea recibir un gran volumen de notificaciones sin limitación de tasa, considere la posibilidad de usar
una acción diferente, como el método webhook, la aplicación lógica, la función de Azure o los runbooks de
automatización, ninguna de las cuales tiene una tasa limitada.
No se recibió el SMS, la llamada de voz o la notificación de inserción

esperada
Si puede ver una alerta desencadenada en el portal pero no recibió el SMS, la llamada de voz o la notificación de
inserción que ha configurado para ello, siga estos pasos:
1. ¿Se suprimió la acción mediante una regla de acción ?
Si no se realizó de manera intencionada, puede modificar, deshabilitar o eliminar la regla de acción.

2. SMS/voz: ¿es correcto su número de teléfono?
Compruebe la acción de SMS por si hubiera errores tipográficos en el código de país o en el número de
teléfono.
3. SMS/voz: ¿se le ha limitado la tasa?
Los SMS y las llamadas de voz tienen una tasa limitada de no más de una notificación cada cinco minutos
por número de teléfono. Si supera este umbral, las notificaciones se quitarán.
Llamada de voz: compruebe el historial de llamadas y vea si tiene una llamada diferente de Azure en los
cinco minutos anteriores.
SMS: compruebe en el historial de SMS si tiene un mensaje que indica que el número de teléfono tiene
limitada la tasa.
Si desea recibir un gran volumen de notificaciones sin limitación de tasa, considere la posibilidad de usar
una acción diferente, como el método webhook, la aplicación lógica, la función de Azure o los runbooks de
automatización, ninguna de las cuales tiene una tasa limitada.
4. SMS: ¿ha cancelado la suscripción al grupo de acciones accidentalmente?
Abra el historial de SMS y compruebe si ha optado por no recibir la entrega de SMS de este grupo de
acciones específico (mediante la respuesta DISABLE nombre_corto_de_grupo_de_acciones) o de todos los
grupos de acciones (mediante la respuesta STOP). Para suscribirse de nuevo, envíe el comando SMS
pertinente (ENABLE nombre_corto_de_grupo_de_acciones o START) o bien quite la acción de SMS del
grupo de acciones y luego vuelva a agregarla. Para obtener más información, consulte Comportamiento de
las alertas por SMS en los grupos de acciones.
5. ¿Ha bloqueado accidentalmente las notificaciones en el teléfono?
La mayoría de los teléfonos móviles le permiten bloquear llamadas o SMS de números de teléfono o
códigos cortos específicos, o bloquear las notificaciones de inserción de aplicaciones concretas (como
Azure Mobile App). Para comprobar si ha bloqueado accidentalmente las notificaciones en el teléfono,
busque en la documentación correspondiente al sistema operativo y modelo del teléfono, o bien pruebe
con un teléfono y número de teléfono diferentes.
Se esperaba otro tipo de acción para desencadenar, pero no tuvo lugar

Si puede ver una alerta desencadenada en el portal, pero su acción configurada no se desencadenó, siga estos
pasos:
1. ¿Se suprimió la acción mediante una regla de acción?
Si no se realizó de manera intencionada, puede modificar, deshabilitar o eliminar la regla de acción.

2. ¿No se ha desencadenado un webhook?
a. ¿Se han bloqueado las direcciones IP de origen?
Agregue las direcciones IP desde las que se llama al webhook a su lista de permitidos.
b. ¿Funciona correctamente el punto de conexión de webhook?
Compruebe que la configuración del punto de conexión del webhook es correcta y que el punto de
conexión funciona correctamente. Compruebe los registros de webhook o instrumente su código
para que pueda investigar (por ejemplo, registre la carga útil de entrada).
c. ¿Está llamando a Slack o a Microsoft Teams?
Cada uno de estos puntos de conexión espera un formato JSON específico. Siga estas instrucciones
para configurar una acción de aplicación lógica en su lugar.
d. ¿El webhook dejó de responder o devolvió errores?
Nuestro tiempo de espera para una respuesta de webhook es de diez segundos. Se volverá a
intentar la llamada de webhook hasta dos veces más cuando se devuelvan los siguientes códigos de
estado HTTP: 408, 429, 503, 504 o cuando el punto de conexión HTTP no responda. El primer
reintento se produce transcurridos 10 segundos. El segundo reintento, y final, se produce una vez
transcurridos cien segundos. Si el segundo reintento produce un error, el punto de conexión no se
llamará de nuevo durante 30 minutos para ninguno de los grupos de acciones.
La acción o notificación se produjo más de una vez

Si ha recibido una notificación de una alerta (por ejemplo, un mensaje de correo electrónico o un SMS) más de
una vez, o si la acción de la alerta (por ejemplo, un webhook o una función de Azure) se desencadenó varias veces,
siga estos pasos:
1. ¿Es realmente la misma aler ta?
En algunos casos, se desencadenan varias alertas similares en torno a la misma hora. Por lo tanto, es
posible que parezca que la misma alerta desencadenó sus acciones varias veces. Por ejemplo, una regla de
alerta del registro de actividad puede configurarse para desencadenarse cuando se inicia y finaliza un
evento (operación correcta o errónea); para ello, no se aplicarían filtros en el campo de estado del evento.
Para comprobar si estas acciones o notificaciones provienen de diferentes alertas, examine los detalles de
la alerta, como su marca de tiempo y el identificador de la alerta o su identificador de correlación. También
puede consultar la lista de alertas desencadenadas en el portal. En ese caso, necesitaría adaptar la lógica de
la regla de alerta o configurar el origen de la alerta.
2. ¿La acción se repite en varios grupos de acciones?
Cuando una alerta se desencadena, cada uno de sus grupos de acciones se procesa de forma
independiente. Por lo tanto, si una acción (por ejemplo, una dirección de correo electrónico) aparece en
varios grupos de acciones desencadenados, se le llamará una vez por cada grupo de acciones.
Para comprobar los grupos de acciones que se han desencadenado, consulte la pestaña del historial de
alertas. Allí vería tanto los grupos de acciones definidos en la regla de alerta como los grupos de acciones
agregados a la alerta mediante reglas de acción:
La acción o notificación tiene un contenido inesperado

Si ha recibido la alerta pero cree que faltan algunos de sus campos o son incorrectos, siga estos pasos:
1. ¿Ha elegido el formato correcto para la acción?
Cada tipo de acción (correo electrónico, webhook, etc.) tiene dos formatos: el predeterminado (el formato
heredado) y el formato de esquema común más reciente. Cuando se crea un grupo de acciones, se
especifica el formato que se desea por acción; las distintas acciones de los grupos de acciones pueden tener
diferentes formatos.
Por ejemplo, para la acción de webhook:
Compruebe si el formato especificado en el nivel de acción es el esperado. Por ejemplo, puede que haya
desarrollado un código que responda a las alertas (webhook, función, aplicación lógica, etc.), que espera un
formato, pero más adelante en la acción usted u otra persona especificó un formato diferente.
Además, compruebe el formato de carga útil (JSON) para alertas de registro de actividad, para alertas de
búsqueda de registros (Application Insights y análisis de registros), para alertas de métricas, para el
esquema de alerta común y para las alertas de métricas clásicas en desuso.
2. Aler tas de registros de actividad: ¿La información está disponible en el registro de actividad?
Las alertas del registro de actividad son alertas basadas en eventos escritos en el registro de actividad de
Azure, tales como eventos sobre la creación, actualización o eliminación de recursos de Azure, eventos
sobre el estado de los servicios y recursos o hallazgos de Azure Advisor y Azure Policy. Si ha recibido una
alerta basada en el registro de actividad pero algunos campos que necesita faltan o son incorrectos,
compruebe primero los eventos en el propio registro de actividad. Si el recurso de Azure no escribió los
campos que está buscando en su evento de registro de actividad, esos campos no se incluirán en la alerta
correspondiente.
La regla de acción no funciona como se esperaba

Si puede ver una alerta desencadenada en el portal, pero una regla de acción relacionada no funcionó según lo
esperado, siga estos pasos:
1. ¿Está habilitada la regla de acción?
Compruebe la columna Estado de la regla de acción para ver si el rol de acción correspondiente está
habilitado.
Si no está habilitada, puede habilitar la regla de acción seleccionándola y haciendo clic en Habilitar.
2. ¿Se trata de una aler ta de estado del ser vicio?
Las alertas de estado del servicio (servicio de monitor = "Service Health") no se ven afectadas por las
reglas de acción.
3. ¿La regla de acción actuó en la aler ta?
Compruebe si la regla de acción ha procesado la alerta haciendo clic en la alerta desencadenada en el
portal y examine la pestaña Historial.
Este es un ejemplo de regla de acción que suprime todos los grupos de acciones:
Este es un ejemplo de una regla de acción que agrega otro grupo de acciones:
4. ¿El filtro y el ámbito de la regla de acción coinciden con la aler ta desencadenada?

Si cree que la regla de acción se debe haber desencadenado pero no lo hizo, o que no se debería haber
desencadenado pero lo hizo, examine cuidadosamente el ámbito de la regla de acción y las condiciones del
filtro comparándolos con las propiedades de la alerta desencadenada.
Cómo buscar el identificador de alerta de una alerta desencadenada

Al abrir un caso sobre una alerta desencadenada concreta (por ejemplo, si no recibió su notificación por correo
electrónico), deberá proporcionar el identificador de la alerta.
Para localizarlo, siga estos pasos:
1. En Azure Portal, vaya a la lista de alertas desencadenadas y busque esa alerta específica. Puede usar los
filtros para ayudarle a encontrarlo.
2. Haga clic en la alerta para abrir los detalles de la misma.
3. Desplácese hacia abajo por los campos de alerta de la primera pestaña (la pestaña de resumen) hasta que
lo localice y cópielo. Ese campo también incluye un botón auxiliar "Copiar al Portapapeles" que puede usar.
Problema al crear, actualizar o eliminar reglas de acción en Azure Portal

Si ha recibido un error al intentar crear, actualizar o eliminar una regla de acción, siga estos pasos:
1. ¿Ha recibido un error de permiso?
Debe tener el rol integrado Colaborador de supervisión o bien los permisos específicos relacionados con
las reglas de acción y las alertas.
2. ¿Ha comprobado los parámetros de la regla de acción?
Compruebe la documentación de la regla de acción o el comando Set-AzActionRule de PowerShell de la
regla de acción.
Pasos siguientes
Si usa una alerta de registro, consulte también Solución de problemas de alertas de registro en Azure Monitor.
Vuelva a Azure Portal para comprobar si ha resuelto el problema con las instrucciones anteriores.
Actualización de reglas de alertas o reglas de acción
cuando su recurso de destino se mueve a otra región
de Azure
En este artículo se describe por qué las reglas de alerta y reglas de acción existentes pueden verse afectadas
cuando se mueven otros recursos de Azure entre regiones, y cómo identificar y resolver esos problemas. Consulte
la documentación principal de movimiento de recursos para obtener información adicional sobre cuándo es útil el
movimiento de recursos entre regiones y una lista de comprobación del diseño de un proceso de movimiento.
Por qué existe el problema

Las reglas de alertas y las reglas de acción hacen referencia a otros recursos de Azure. Entre algunos ejemplos se
incluyen VM de Azure, Azure SQL y Azure Storage. Al mover los recursos a los que hacen referencia esas reglas, es
probable que estas dejen de funcionar correctamente porque no pueden encontrar los recursos a los que hacen
referencia.
Hay dos motivos principales por los que las reglas pueden dejar de funcionar después de mover los recursos de
destino:
El ámbito de la regla hace referencia explícita al recurso anterior.
La regla de alerta se basa en métricas.
El ámbito de la regla hace referencia explícita al recurso anterior

Cuando se mueve un recurso, su identificador de recurso cambia en la mayoría de los casos. En segundo plano, el
sistema replica el recurso en la nueva región antes de eliminarlo de la antigua región. Este proceso requiere que
existen simultáneamente dos recursos y, por tanto, dos identificadores de recurso diferentes durante un breve
período de tiempo. Dado que los identificadores de recurso deben ser únicos, se debe crear un nuevo identificador
durante el proceso.
¿Cómo afecta el movimiento de recursos a las reglas existentes?
Las reglas de alerta y las reglas de acción tienen un ámbito de recursos a los que se aplican. El ámbito puede ser
toda una suscripción, un grupo de recursos, o uno o varios recursos específicos. Por ejemplo, esta es una regla con
un ámbito con dos recursos (dos máquinas virtuales):
Si el ámbito de la regla menciona explícitamente un recurso, y ese recurso se ha movido y se ha cambiado su

identificador de recurso, esa regla buscará un recurso incorrecto o inexistente y, por tanto, se producirá un error.
Procedimiento para corregir el problema
Actualice o vuelva a crear la regla afectada para que apunte al nuevo recurso. El proceso para actualizar el ámbito
se encuentra más adelante en este artículo.
El problema se aplica a estos tipos de reglas:
Reglas de acción
Alertas clásicas
Alertas de métricas; para obtener más información, consulte la sección siguiente Reglas de alertas basadas en
métricas.
NOTE
Las reglas de alertas de búsqueda de registros y las reglas de alertas del detector inteligente no se ven afectadas, ya que su
ámbito es un área de trabajo o Application Insights. Ninguno de estos ámbitos admite actualmente el movimiento entre
regiones.
Reglas de alertas basadas en métricas

Las métricas que emiten los recursos de Azure son regionales. Cada vez que un recurso se mueve a una nueva
región, comienza a emitir las métricas en esa nueva región. Como consecuencia, es necesario actualizar o volver a
crear las reglas de alertas basadas en métricas para que apunten al flujo de métricas actual en la región correcta.
Esta explicación se aplica tanto a las reglas de alertas de métricas como a las reglas de alertas de pruebas de
disponibilidad.
Si se han movido todos los recursos del ámbito, no es necesario volver a crear la regla. Simplemente puede
actualizar cualquier campo de la regla de alertas, como la descripción de la regla de alertas, y guardarla. Si se han
movido solo algunos de los recursos del ámbito, debe quitar de la regla existente los recursos que se han
movido, y crear una nueva regla que cubra solo los recursos movidos.
Procedimientos para solucionar problemas

Detección de reglas asociadas a un recurso que se ha movido desde Azure Portal
En el caso de las reglas de aler tas , navegue a Alertas > Administrar reglas de alertas > filtre por la
suscripción que la contiene y el recurso movido.
NOTE
Las reglas de alerta del registro de actividad no admiten este proceso. No es posible actualizar el ámbito de una regla de
alertas del registro de actividad y hacer que apunte a un recurso de otra suscripción. En su lugar, puede crear una nueva
regla que reemplace a la anterior.
En el caso de las reglas de acción , navegue a Alertas > Administrar acciones (versión preliminar) > filtre
por la suscripción que la contiene y el recurso movido.
Cambio de ámbito de una regla desde Azure Portal
1. Abra la regla que identificó en el paso anterior; para ello, haga clic en ella.
2. En Recursos , haga clic en Editar y ajuste el ámbito según sea necesario.
3. Ajuste las otras propiedades de la regla según sea necesario.
Cambio del ámbito de una regla mediante plantillas de Azure Resource Manager
1. Obtenga la plantilla de Azure Resource Manager de la regla. Para exportar la plantilla de una regla desde Azure
Portal:
a. Vaya a la sección Grupos de recursos en el portal y abra el grupo de recursos que contiene la regla.
b. En la sección Información general, active la casilla Mostrar tipo oculto y filtre por el tipo relevante de
la regla.
c. Seleccione la regla correspondiente para ver sus detalles.
d. En Configuración , seleccione Expor tar plantilla .
2. Modifique la plantilla. Si es necesario, divida en dos reglas (lo que es pertinente en algunos casos de alertas de
métricas, como se ha indicado anteriormente).
3. Vuelva a implementar la plantilla.
Cambio del ámbito de una regla mediante la API de REST
1. Obtenga la regla existente (alertas de métricas, alertas del registro de actividad).
2. Modifique el ámbito (alertas del registro de actividad).
3. Volver a implementar la regla (alertas de métricas, alertas del registro de actividad).
Cambio del ámbito de una regla mediante PowerShell
1. Obtenga la regla existente (alertas de métricas, alertas del registro de actividad, reglas de acción).
2. Modifique el ámbito. Si es necesario, divida en dos reglas (lo que es pertinente en algunos casos de alertas de
métricas, como se ha indicado anteriormente).
3. Vuelva a implementar la regla (alertas de métricas, alertas del registro de actividad, reglas de acción).
Cambio del ámbito de una regla mediante la CLI de Azure
1. Obtenga la regla existente (alertas de métricas, alertas del registro de actividad).
2. Actualice el ámbito de la regla directamente (alertas de métricas, alertas del registro de actividad).
3. Si es necesario, divida en dos reglas (lo que es pertinente en algunos casos de alertas de métricas, como se ha
indicado anteriormente).
Pasos siguientes
Obtenga información sobre cómo corregir otros problemas de las notificaciones de alerta, alertas de métricas y
alertas del registro.
Conectar Azure a las herramientas de ITSM
mediante el Conector de Administración de
servicios de TI
El Conector de Administración de servicios de TI (ITSMC) le permite conectar Azure y un producto o servicio de

Administración de servicios de TI (ITSM) compatibles.
Servicios de Azure como Log Analytics y Azure Monitor proporcionan herramientas para detectar, analizar y
solucionar problemas relacionados con los recursos de Azure y de otros proveedores. Sin embargo, los
elementos de trabajo relacionados con un problema suelen residir en un producto o servicio de ITSM. El
conector de ITSM proporciona una conexión bidireccional entre las herramientas de Azure e ITSM para ayudarle
a resolver problemas con mayor rapidez.
ITSMC admite conexiones con las siguientes herramientas ITSM:
ServiceNow
System Center Service Manager
Provance
Cherwell
Con ITSMC, puede:
Crear elementos de trabajo en la herramienta de ITSM, en función de las alertas de Azure (alertas de métricas,
de Activity Log y de Log Analytics).
Sincronizar de forma opcional los datos de incidentes y solicitudes de cambio de la herramienta ITSM con un
área de trabajo de Azure Log Analytics.
Más información sobre los términos legales y la directiva de privacidad.
Puede empezar a usar el conector de ITSM siguiendo estos pasos:
1. Agregue la solución del conector de ITSM.
2. Cree una conexión de ITSM
3. Use la conexión.
Agregar la solución IT Service Management Connector

Para poder crear una conexión, debe agregar la solución del conector de ITSM.
1. En Azure Portal, haga clic en el icono + Nuevo .
2. Busque el Conector de Administración de ser vicios de TI en Marketplace y haga clic en Crear .
3. En la sección Área de trabajo de OMS , seleccione el área de trabajo de Azure Log Analytics donde
quiera instalar la solución.
NOTE
Como parte de la transición continuada de Microsoft Operations Management Suite (OMS) a Azure Monitor,
las áreas de trabajo de OMS ahora se conocen como áreas de trabajo de Log Analytics.
Solo se puede instalar el conector ITSM en áreas de trabajo de Log Analytics en las siguientes regiones: Este de
EE. UU., Oeste de EE. UU.2, Centro Sur de EE. UU., Centro-oeste de EE. UU., Fairfax, Centro de Canadá, Oeste de
Europa, Sur de Reino Unido, Sudeste de Asia, Este de Japón, Centro de la India y Sudeste de Australia.
4. En la sección Configuración del área de trabajo de OMS , seleccione el grupo de recursos donde
quiera crear el recurso de la solución.
NOTE
Como parte de la transición continuada de Microsoft Operations Management Suite (OMS) a Azure Monitor, las
áreas de trabajo de OMS ahora se conocen como áreas de trabajo de Log Analytics.

Cuando se implemente el recurso de la solución, aparecerá una notificación en la parte superior derecha de la
ventana.
Crear una conexión de ITSM

Después de instalar la solución, puede crear una conexión.
Para crear una conexión, debe preparar la herramienta de ITSM para permitir la conexión a la solución del
conector de ITSM.
Según el producto de ITSM al que se conecte, siga estos pasos:
System Center Service Manager (SCSM)
ServiceNow
Provance
Cherwell
Una vez que haya preparado sus herramientas ITSM, siga estos pasos para crear una conexión:
1. Vaya a Todos los recursos y busque Ser viceDesk(YourWorkspaceName) .
2. En la opción ORÍGENES DE DATOS DEL ÁREA DE TRABAJO del panel izquierdo, haga clic en
Conexiones de ITSM .
En esta página se muestra la lista de conexiones.

3. Haga clic en Agregar conexión .
4. Especifique la configuración de conexión tal como se describe en el artículo Configuring the ITSMC
connection with your ITSM products/services (Configurar la conexión ITSMC con los productos o servicios
de ITSM).
NOTE
De forma predeterminada, ITSMC actualiza los datos de configuración de la conexión una vez cada 24 horas. Para
actualizar los datos de la conexión al instante para cualquier modificación o actualizaciones de plantilla que se
realicen, haga clic en el botón Actualizar que se muestra en la hoja de la conexión.
Uso de la solución
Al usar la solución del Conector ITSM, puede crear elementos de trabajo de alertas de Azure, alertas de Log
Analytics y entradas de registros de Log Analytics.
Creación de elementos de trabajo de ITSM a partir de alertas de Azure

Una vez que haya creado la conexión a ITSM, puede crear elementos de trabajo en la herramienta de ITSM según
las alertas de Azure, mediante la acción de ITSM en Grupos de acciones .
Los grupos de acciones proporcionan una manera modular y reutilizable de desencadenar acciones para las
alertas de Azure. Puede usar los grupos de acciones con alertas de métricas, de Activity Log y de Azure Log
Analytics en Azure Portal.
Utilice el siguiente procedimiento:
1. En Azure Portal, haga clic en Monitor
2. En el panel izquierdo, haga clic en Grupos de acciones . Aparece la ventana Agregar grupo de
acciones .
3. Complete los campos Name (Nombre) y Shor tName (Nombre corto) para el grupo de acciones.
Seleccione el grupo de recursos y la suscripción donde quiere crear el grupo de acciones.
4. En la lista de acciones, seleccione ITSM en la lista desplegable Tipo de acción . Proporcione un nombre
para la acción y haga clic en Editar detalles .
5. En Subscription (Suscripción), indique dónde se encuentra el área de trabajo de Log Analytics.
Seleccione el nombre de la conexión (el nombre del conector ITSM) seguido del nombre del área de
trabajo. Por ejemplo, "MiITSMMConnector(MiAreaDeTrabajo)".
6. Seleccione el tipo Elemento de trabajo en el menú desplegable. Elija usar una plantilla existente o
rellene los campos requeridos para el producto ITSM.
7. Haga clic en OK .
Al crear o editar una regla de alerta de Azure, use un grupo de acciones, que tiene una acción de ITSM. Cuando
se desencadena la alerta, se crea o actualiza un elemento de trabajo en la herramienta ITSM.
NOTE
Para obtener información sobre los precios de las acciones de ITSM, consulte la página de precios de los grupos de
acciones.
Visualizar y analizar los datos de incidentes y solicitudes de cambios

Si se tienen en cuenta las opciones de configuración de una conexión, el Conector ITSM puede sincronizar hasta
120 días de datos referentes a incidentes y a solicitudes cambios. El esquema de registros de estos datos se
proporciona en la próxima sección.
Gracias al panel del Conector ITSM en la solución, se pueden visualizar los datos de incidentes y solicitudes de
cambios.
Asimismo, el panel también proporciona información acerca del estado del conector que se puede usar como
punto de partida para analizar cualquier problema con las conexiones.
También puede visualizar los incidentes que se sincronizan con los equipos afectados dentro de la solución
Service Map.
Mapa de servicio detecta automáticamente los componentes de la aplicación en sistemas Windows y Linux y
asigna la comunicación entre servicios. Permite ver los servidores a medida que piensa en ellos, como los
sistemas interconectados que ofrecen servicios críticos. Mapa de servicio muestra las conexiones entre
servidores, procesos y puertos en cualquier arquitectura conectada TCP sin una configuración necesaria que sea
distinta a la instalación de un agente. Más información.
Si usa la solución Service Map, puede ver los elementos de la consola de servicio creados en la solución ITSM tal
como se muestra en el ejemplo siguiente:
Más información: Mapa de servicio
Información adicional
Datos que se sincronizan del producto ITSM
Los incidentes y las solicitudes de cambio se sincronizan desde el producto ITSM con el área de trabajo de Log
Analytics según la configuración de la conexión.
En la siguiente información se muestran ejemplos de datos recopilados por ITSMC:
NOTE
En función del tipo de elemento de trabajo que se importa a Log Analytics, Ser viceDesk_CL contiene los campos
siguientes:
Elemento de trabajo: Incidentes

ServiceDeskWorkItemType_s="Incidente"
Fields
ServiceDeskConnectionName
Service Desk ID
State
Urgencia
Impacto
Priority
Escalado
Creado por
Resuelto por
Cerrado por
Source
Asignado a
Category
Título
Descripción
Fecha de creación
Fecha de cierre
Fecha de resolución
Fecha de última modificación
Computer
Elemento de trabajo: Solicitudes de cambio
ServiceDeskWorkItemType_s="ChangeRequest"
Fields
ServiceDeskConnectionName
Service Desk ID
Creado por
Cerrado por
Source
Asignado a
Título
Tipo
Category
State
Escalado
Estado del conflicto
Urgencia
Priority
Riesgo
Impacto
Asignado a
Fecha de creación
Fecha de cierre
Fecha de última modificación
Fecha de solicitud
Fecha de inicio planeada
Fecha de finalización planeada
Fecha de inicio del trabajo
Fecha de finalización del trabajo
Descripción
Computer
Datos de salida para un incidente de ServiceNow

C A M P O DE LO G A N A LY T IC S C A M P O DE SERVIC EN O W
ServiceDeskId_s Number
IncidentState_s State
C A M P O DE LO G A N A LY T IC S C A M P O DE SERVIC EN O W
Urgency_s Urgencia
Impact_s Impacto
Priority_s Priority
CreatedBy_s Abierto por
ResolvedBy_s Resuelto por
ClosedBy_s Cerrado por
Source_s Tipo de contacto
AssignedTo_s Asignado a
Category_s Category
Title_s Descripción breve
Description_s Notas
CreatedDate_t Abierto
ClosedDate_t closed
ResolvedDate_t Resuelto
Computer Elemento de configuración
Datos de salida para una solicitud de cambio de ServiceNow

LO G A N A LY T IC S C A M P O DE SERVIC EN O W
ServiceDeskId_s Number
CreatedBy_s Solicitado por
ClosedBy_s Cerrado por
AssignedTo_s Asignado a
Title_s Descripción breve
Type_s Tipo
Category_s Category
CRState_s State
LO G A N A LY T IC S C A M P O DE SERVIC EN O W
Urgency_s Urgencia
Priority_s Priority
Risk_s Riesgo
Impact_s Impacto
RequestedDate_t Solicitado por fecha
ClosedDate_t Fecha de cierre
PlannedStartDate_t Fecha de inicio planeada
PlannedEndDate_t Fecha de finalización planeada
WorkStartDate_t Fecha de inicio real
WorkEndDate_t Fecha de finalización real
Description_s Descripción
Computer Elemento de configuración
Solución de problemas de conexión de ITSM

1. Si se produce un error en la conexión de la UI del origen conectado y recibe el mensaje Error al guardar
la conexión , siga estos pasos:
En el caso de conexiones de ServiceNow, Cherwell y Provance,
asegúrese de que ha introducido correctamente el nombre de usuario, la contraseña, el Id. de cliente y
el secreto de cliente de cada una de las conexiones.
compruebe si dispone de privilegios suficientes en el producto ITSM correspondiente para realizar la
conexión.
En el caso de conexiones de Service Manager,
asegúrese de que la aplicación web se implementa correctamente y se crea la conexión híbrida. Para
comprobar que la conexión se ha establecido correctamente con la máquina de Service Manager local,
visite la dirección URL de la aplicación web como se detalla en la documentación para realizar la
conexión híbrida.
2. Si los datos de ServiceNow no se sincronizan con Log Analytics, asegúrese de que la instancia de
ServiceNow no esté suspendida. En algunas ocasiones, las instancias de desarrollo de ServiceNow se
suspenden si están inactivas durante mucho tiempo. En caso contrario, notifique el problema.
3. Si se generan alertas de Log Analytics, pero no se crean elementos de trabajo en el producto de ITSM, no
se crean elementos de configuración o no se vinculan a elementos de trabajo, o bien necesita información
general, vea:
ITSMC: La solución muestra un resumen de conexiones, elementos de trabajo, equipos, etc. Haga clic
en el icono que muestra Estado del conector , que le lleva a Búsqueda de registros con la consulta
correspondiente. Para obtener más información, consulte las entradas del registro con LogType_S
como ERROR para obtener más información.
Página Búsqueda de registros : vea directamente los errores y la información relacionada con la
consulta * ServiceDeskLog_CL * .
Solucionar problemas de implementación de aplicaciones web de

Service Manager
1. En caso de que se produzcan problemas con la implementación de la aplicación web, asegúrese de tener los
permisos suficientes en la suscripción mencionada para crear o implementar recursos.
2. Si aparece el mensaje de error Referencia a objeto no establecida como instancia de un objeto" al
ejecutar el script, asegúrese de que especificó valores válidos en la sección Configuración de usuario .
3. Si no puede crear el espacio de nombres de retransmisión de Service Bus, asegúrese de que el proveedor de
recursos necesario está registrado en la suscripción. Si no está registrado, cree el espacio de nombres de Bus
Relay manualmente desde Azure Portal. También puede crearlo mientras crea la conexión híbrida desde Azure
Portal.
Ponerse en contacto con nosotros

Si tiene consultas o comentarios sobre IT Service Management, póngase en contacto con nosotros en
omsitsmfeedback@microsoft.com.
Pasos siguientes
Incorporación de productos o servicios de ITSM a IT Service Management Connector.
Conectar productos o servicios de ITSM con el
Conector de Administración de servicios de TI
En este artículo se proporciona información sobre cómo configurar la conexión entre los productos y servicios de
ITSM y el Conector de Administración de servicios de TI (ITSMC) en Log Analytics para administrar de forma
centralizada los elementos de trabajo. Para obtener más información sobre ITSMC, vea Información general.
Se admiten los siguientes productos y servicios de ITSM. Seleccione un producto para ver información detallada
sobre cómo conectarlo a ITSMC.
System Center Service Manager
ServiceNow
Provance
Cherwell
NOTE
El conector de ITSM solo se puede conectar a instancias de ServiceNow basadas en la nube. Actualmente no se admiten
instancias locales de ServiceNow.
Conectar System Center Service Manager con el Conector de

Administración de servicios de TI en Azure
En las secciones siguientes se proporcionan detalles sobre cómo conectar su producto de System Center Service
Manager con ITSMC en Azure.
Prerrequisitos
Asegúrese de que se cumplen los siguientes requisitos previos:
ITSMC instalado Más información: Agregar la solución IT Service Management Connector.
Se implementa y se configura la aplicación web de Service Manager (aplicación web). Aquí se puede obtener
información sobre la aplicación web.
Conexión híbrida creada y configurada Más información: Configuración de la conexión híbrida.
Versiones admitidas de Service Manager: 2012 R2 o 2016.
Rol de usuario: operador avanzado.
Procedimiento de conexión
Use el siguiente procedimiento para conectar la instancia de System Center Service Manager con ITSMC:
1. En Azure Portal, vaya a Todos los recursos y busque Ser viceDesk(YourWorkspaceName) .
2. En ORÍGENES DE DATOS DEL ÁREA DE TRABAJO , haga clic en Conexiones de ITSM .
3. En la parte superior del panel derecho, haga clic en Agregar .
4. Proporcione la información tal como se describe en la tabla siguiente y haga clic en Aceptar para crear la
conexión.
NOTE
Todos estos parámetros son obligatorios.
Nombre de la conexión Escriba un nombre para la instancia de System Center Service

Manager que quiere conectar con ITSMC. Usará este nombre
más adelante cuando configure los elementos de trabajo en
el análisis de registros detallados de la instancia o vista.
Tipo de asociado Seleccione System Center Ser vice Manager .
Dirección URL del ser vidor Escriba la dirección URL de la aplicación web de Service
Manager. Aquí podrá obtener más información sobre la
aplicación web de Service Manager.
Id. de cliente Escriba el identificador de cliente que ha generado (mediante

el script automático) para autenticar la aplicación web. Aquí
podrá obtener más información sobre el script automatizado.
Secreto de cliente Escriba el secreto de cliente generado para este identificador.
Sincronización de datos Seleccione los elementos de trabajo de Service Manager que

quiere sincronizar mediante ITSMC. Estos elementos de
trabajo se importan en Log Analytics. Opciones: incidentes,
solicitudes de cambio.
Ámbito de sincronización de datos Escriba el número de días pasados de los que desea los
datos. Límite máximo : 120 días.
Creación de un elemento de configuración de Seleccione esta opción si desea crear los elementos de
solución ITSM configuración en el producto ITSM. Al seleccionarla, Log
Analytics crea los elementos de configuración afectados como
elementos de configuración (si no existen) en el sistema ITSM
compatible. Valor predeterminado : deshabilitado.
Cuando se ha conectado y sincronizado correctamente :

Los elementos de trabajo seleccionados de Service Manager se importan en Azure Log Analytics . Puede
ver el resumen de estos elementos de trabajo en el icono de IT Service Management Connector.
Puede crear incidentes a partir de alertas de Log Analytics, de entradas de registros o de alertas de Azure
en esta instancia de Service Manager.
Más información: Creación de elementos de trabajo de ITSM a partir de alertas de Azure.
Creación e implementación del servicio de aplicaciones web de Service Manager
Para conectar la instancia de Service Manager local con ITSMC en Azure, Microsoft ha creado una aplicación web
de Service Manager en GitHub.
Para configurar la aplicación web de ITSM para Service Manager, haga lo siguiente:
Implemente la aplicación web : implemente la aplicación web, establezca las propiedades y autentíquese
con Azure AD. Puede implementar la aplicación web mediante el script automatizado que Microsoft ha
proporcionado.
Configure la conexión híbrida - Configure esta conexión, manualmente.
Implementación de la aplicación web
Use el script automatizado para implementar la aplicación web, establecer las propiedades y autenticarse con
Azure AD.
Ejecute el script proporcionando los siguientes detalles necesarios:
Detalles de la suscripción de Azure
Definición de un nombre de grupo de recursos
Location
Detalles del servidor de Service Manager (nombre del servidor, dominio, nombre de usuario y contraseña)
Prefijo de nombre de sitio de la aplicación web
Espacio de nombres de ServiceBus.
El script crea la aplicación web con el nombre que especificó ( junto con algunas cadenas adicionales para hacerlo
único). Genera la dirección URL de la aplicación web , el id. de cliente y el secreto de cliente .
Guarde los valores, ya que se usan al crear una conexión con ITSMC.
Comprobación de la instalación de la aplicación web
1. Vaya a Azure Por tal > Recursos .
2. Seleccione la aplicación web y haga clic en Configuración > Configuración de la aplicación .
3. Confirme la información sobre la instancia de Service Manager que ha proporcionado en el momento de la
implementación de la aplicación a través del script.
Configuración de la conexión híbrida
Use el procedimiento siguiente para configurar la conexión híbrida que conecta la instancia de Service Manager
con ITSMC en Azure.
1. Busque la aplicación web de Service Manager, Recursos de Azure .
2. Haga clic en Configuración > Redes .
3. En Conexiones híbridas , haga clic en Configure los puntos de conexión de la conexión híbrida .
4. En la hoja Conexiones híbridas , haga clic en Agregar conexión híbrida .
5. En la hoja Agregar conexiones híbridas , haga clic en Crear conexión híbrida nueva .
6. Escriba los valores siguientes:
Nombre del punto de conexión : especifique un nombre para la conexión híbrida nueva.
Host del punto de conexión : nombre de dominio completo del servidor de administración de
Service Manager.
Puer to del punto de conexión : tipo 5724
Espacio de nombres de Ser vice Bus : use un espacio de nombres de Service Bus existente o
cree uno.
Ubicación : seleccione la ubicación.
Name : especifique un nombre para la instancia de Service Bus si lo está creando.
7. Haga clic en Aceptar para cerrar la hoja Crear conexión híbrida y empiece a crearla.
Una vez creada, se muestra debajo de la hoja.
8. Cuando se crea la conexión híbrida, seleccione la conexión y haga clic en Agregar conexión híbrida
seleccionada .
Configuración del programa de instalación del agente de escucha
Utilice el procedimiento siguiente para configurar el programa de instalación del agente de escucha para la
conexión híbrida.
1. En la hoja Conexiones híbridas , haga clic en Descargar administrador de conexión e instálelo en el
equipo donde se ejecuta la instancia de System Center Service Manager.
Una vez finalizada la instalación, la opción Hybrid Connection Manager UI (IU de administración de
conexión híbrida) está disponible en el menú Iniciar .
2. Haga clic en Hybrid Connection Manager UI (IU de administración de conexión híbrida), se le pedirán
las credenciales de Azure.
3. Inicie sesión con sus credenciales de Azure y seleccione la suscripción en la que se creó la conexión
híbrida.
La conexión híbrida se ha conectado correctamente.
NOTE
Después de crear la conexión híbrida, compruebe y pruebe la conexión visitando la aplicación web de la instancia de Service
Manager implementado. Asegúrese de que la conexión es correcta antes de intentar conectarse con ITSMC en Azure.
En la siguiente imagen de ejemplo se muestran los detalles de una conexión correcta:

Conectar ServiceNow al Conector de Administración de servicios de TI
en Azure
En las secciones siguientes se proporcionan detalles sobre cómo conectar su producto de ServiceNow a ITSMC
en Azure.
Prerrequisitos
Versiones compatibles con ServiceNow: Orlando, Nueva York, Madrid, Londres, Kingston, Yakarta, Estambul,
Helsinki, Ginebra.
NOTE
ITSMC admite solo la oferta de SaaS oficial de ServiceNow. No se admiten implementaciones privadas de ServiceNow.
Los administradores de Ser viceNow deben realizar lo siguiente en la instancia de Ser viceNow: :
Generar el identificador y el secreto del cliente para el producto de ServiceNow. Para más información
sobre cómo generar el identificador y el secreto de cliente, consulte la siguiente información según sea
necesario:
Configuración de OAuth para Orlando
Configuración de OAuth para Nueva York
Configuración de OAuth para Madrid
Configuración de OAuth para Londres
Configuración de OAuth para Kingston
Configuración de OAuth para Yakarta
Configuración de OAuth para Estambul
Configuración de OAuth para Helsinki
Configuración de OAuth para Ginebra
NOTE
Como parte de la definición de "Configuración de OAuth", se recomienda:
1. Actualizar la duración del token de actualización a 90 días (7 776 000 segundos). Como parte de la
Configuración de OAuth en la fase 2: Crear un punto de conexión para que los clientes accedan a la instancia Después
de la definición del punto de conexión, en la hoja ServiceNow, busque OAuth del sistema y, a continuación, seleccione
Registro de aplicaciones. Seleccione el nombre de OAuth que se definió y actualice el campo de duración del token de
actualización a 7 776 000 (90 días expresados en segundos). Finalmente, haga clic en Actualizar.
2. Se recomienda establecer un procedimiento interno para asegurarse de que la conexión permanezca
activa según la duración del token de actualización para actualizar el token. Asegúrese de realizar las siguientes
operaciones antes de la fecha de expiración esperada del token de actualización (se recomienda un par de días antes de
que expire la duración del token de actualización):
1. Completar un proceso de sincronización manual para la configuración del conector de ITSM
2. Revocar el token de actualización anterior, ya que no se recomienda mantener las claves antiguas por motivos de
seguridad. En la hoja ServiceNow, busque System OAuth (OAuth del sistema) y seleccione Manage Tokens (Administrar
tokens). Elija el token antiguo de la lista según el nombre de OAuth y la fecha de expiración.
3. Haga clic en Revoke Access (Revocar acceso) y, a continuación, en Revoke (Revocar).
Instalar la aplicación de usuario para la integración de Microsoft Log Analytics (aplicación de ServiceNow).
Más información.
Crear el rol de usuario de integración para la aplicación de usuario instalada. Aquí puede encontrar más
información sobre cómo crear el rol de usuario de integración.
Use el procedimiento siguiente para crear una nueva conexión a ServiceNow.
conexión.
NOTE
Nombre de la conexión Escriba un nombre para la instancia de ServiceNow que

quiere conectar con ITSMC. Usará este nombre más adelante
en Log Analytics cuando configure los elementos de trabajo
en el análisis de registros detallados de ITSM o vista.
Tipo de asociado Seleccione Ser viceNow .
Nombre de usuario Escriba el nombre de usuario de integración que ha creado

en la aplicación de ServiceNow para que admita la conexión
con ITSMC. Más información: Creación de un rol de usuario
de aplicación de ServiceNow.
Contraseña Escriba la contraseña asociada con este nombre de usuario.

Nota : El nombre de usuario y la contraseña se utilizan para
generar únicamente tokens de autenticación y no se
almacenan en ningún lugar dentro del servicio ITSMC.
Dirección URL del ser vidor Escriba la dirección URL de la instancia de ServiceNow que
quiere conectar con ITSMC. La dirección URL debe apuntar a
una versión de SaaS compatible con el sufijo
".servicenow.com".
Id. de cliente Escriba el identificador de cliente que desea utilizar para la

autenticación de OAuth2 y que ha generado anteriormente.
Para más información acerca de cómo generar el identificador
y el secreto del cliente: Configuración de OAuth.
Secreto de cliente Escriba el secreto de cliente generado para este identificador.
Ámbito de sincronización de datos Seleccione los elementos de trabajo de ServiceNow que

quiere sincronizar con Azure Log Analytics mediante ITSMC.
Los valores seleccionados se importan en Log Analytics.
Opciones: incidentes y solicitudes de cambio.
Sincronización de datos Escriba el número de días pasados de los que desea los
solución ITSM configuración en el producto ITSM. Cuando se selecciona,
ITMSC crea los elementos de configuración afectados como
elementos de configuración (en el caso de que no existan) en
el sistema ITSM compatible. Valor predeterminado :
deshabilitado.
Los elementos de trabajo seleccionados en la instancia de ServiceNow se importan en Azure Log
Analytics . Puede ver el resumen de estos elementos de trabajo en el icono de IT Service Management
Connector.
en esta instancia de ServiceNow.
NOTE
ServiceNow tiene un límite de frecuencia para las solicitudes por hora. Para configurar dicho límite, defina el valor de
"Limitación de velocidad de la API REST de entrada" en la instancia de ServiceNow.
Creación de un rol de usuario de integración de aplicación de ServiceNow

Utilice el siguiente procedimiento:
1. Visite la tienda de ServiceNow e instale la aplicación de usuario para la integración de OMS de
Microsoft y Ser viceNow en la instancia de ServiceNow.
NOTE
Como parte de la transición continuada de Microsoft Operations Management Suite (OMS) a Azure Monitor, OMS
ahora se conoce como Log Analytics.
2. Después de la instalación, visite la barra de navegación izquierda de la instancia de ServiceNow, y busque

y seleccione el integrador de OMS de Microsoft.
3. Haga clic en Installation Checklist (Lista de comprobación de instalación).
El estado se muestra como Not complete (Sin completar) si aún no se creó el rol de usuario.
4. En los cuadros de texto, junto a Create integration user (Crear usuario de integración), escriba el
nombre de usuario para el usuario que puede conectarse a ITSMC en Azure.
5. Escriba la contraseña para este usuario y haga clic en Aceptar .
NOTE
Utilice estas credenciales para realizar la conexión de ServiceNow en Azure.
El usuario recién creado se muestra con los roles predeterminados asignados.

Roles predeterminados :
personalize_choices
import_transformer
x_mioms_microsoft.User
itil
template_editor
view_changer
Cuando el usuario se crea correctamente, el estado de Check Installation Checklist (Comprobar lista de
comprobación de instalación) pasa a Completed (Completado) y se muestran los detalles del rol de usuario
creado para la aplicación.
NOTE
El Conector ITSM puede enviar incidentes a ServiceNow sin otros módulos instalados en la instancia de ServiceNow. Si usa
el módulo EventManagement en su instancia de ServiceNow y quiere crear eventos o alertas en ServiceNow mediante el
conector, agregue los siguientes roles para el usuario de integración:
evt_mgmt_integration
evt_mgmt_operator
Conectar Provance al Conector de Administración de servicios de TI en

Azure
En las secciones siguientes se proporcionan detalles sobre cómo conectar su producto de Provance a ITSMC en
Azure.
Prerrequisitos
La aplicación Provance debe registrarse con Azure AD y estará disponible el identificador de cliente. Para
una información detallada, consulte el tema sobre cómo configurar la autenticación de Active Directory.
Rol de usuario: Administrador.
Use el procedimiento siguiente para crear una conexión a Provance:

conexión.
NOTE
Nombre de la conexión Escriba un nombre para la instancia de Provance que quiere

conectar con ITSMC. Usará este nombre más adelante cuando
configure los elementos de trabajo en el análisis de registros
detallados de ITSM o vista.
Tipo de asociado Seleccione Provance .
Nombre de usuario Escriba el nombre de usuario que puede conectarse a ITSMC.


Nota: El nombre de usuario y la contraseña se utilizan para
Dirección URL del ser vidor Escriba la dirección URL de la instancia de Provance que
quiere conectar con ITSMC.
Id. de cliente Escriba el identificador de cliente para autenticar esta

conexión, que genera en la instancia de Provance. Para más
información sobre el identificador de cliente, consulte el tema
sobre cómo configurar la autenticación de Active Directory.
Ámbito de sincronización de datos Seleccione los elementos de trabajo de Provance que quiera
sincronizar con Azure Log Analytics mediante ITSMC. Estos
elementos de trabajo se importan en Log Analytics.
Opciones: incidentes, solicitudes de cambio.
deshabilitado.
Los elementos de trabajo seleccionados en la instancia de Provance se importan en Azure Log Analytics .
Puede ver el resumen de estos elementos de trabajo en el icono de IT Service Management Connector.
en esta instancia de Provance.
Conectar Cherwell con el Conector de Administración de servicios de

TI en Azure
En las secciones siguientes se proporcionan detalles sobre cómo conectar su producto de Cherwell a ITSMC en
Azure.
Prerrequisitos
Identificador de cliente generado. Más información: Generación del identificador de cliente para Cherwell.
Rol de usuario: Administrador.
Use el procedimiento siguiente para crear una conexión a Provance:

conexión.
NOTE
Nombre de la conexión Escriba un nombre para la instancia de Cherwell que quiere

conectar con ITSMC. Usará este nombre más adelante cuando
configure los elementos de trabajo en el análisis de registros
detallados de ITSM o vista.
Tipo de asociado Seleccione Cher well.
Nombre de usuario Escriba el nombre de usuario de Cherwell que puede

conectarse a ITSMC.

Nota: El nombre de usuario y la contraseña se utilizan para
Dirección URL del ser vidor Escriba la dirección URL de la instancia de Cherwell que
quiere conectar con ITSMC.
Id. de cliente Escriba el identificador de cliente para autenticar esta

conexión, que genera en la instancia de Cherwell.
Ámbito de sincronización de datos Seleccione los elementos de trabajo de Cherwell que quiere
sincronizar mediante ITSMC. Estos elementos de trabajo se
importan en Log Analytics. Opciones: incidentes, solicitudes
de cambio.
deshabilitado.
Los elementos de trabajo seleccionados en la instancia de Cherwell se importan en Azure Log Analytics .
Puede ver el resumen de estos elementos de trabajo en el icono de IT Service Management Connector.
en esta instancia de Cherwell.
Generación del identificador de cliente para Cherwell
Para generar el identificador o clave de cliente para Cherwell, utilice el procedimiento siguiente:
1. Inicie sesión en la instancia de Cherwell como administrador.
2. Haga clic en Security > Edit REST API client settings (Seguridad > Editar configuración de cliente de
API de REST).
3. Seleccione Create new client > client secret (Crear nuevo cliente > Secreto de cliente).
Pasos siguientes
Creación de elementos de trabajo de ITSM a partir de alertas de Azure
Creación de una aplicación web de Service Manager
mediante el script automatizado
Use el siguiente script para crear la aplicación web para la instancia de Service Manager. Aquí puede obtener más
información sobre la conexión de Service Manager. Aplicación web de Service Manager
Ejecute el script proporcionando los siguientes detalles necesarios:
Detalles de la suscripción de Azure
Definición de un nombre de grupo de recursos
Location
Detalles del servidor de Service Manager (nombre del servidor, dominio, nombre de usuario y contraseña)
Prefijo de nombre de sitio de la aplicación web
Espacio de nombres de ServiceBus.
El script creará la aplicación web con el nombre que especificó ( junto con algunas cadenas adicionales para
hacerlo único). Genera la dirección URL de la aplicación web , el id. de cliente y el secreto de cliente .
Guarde estos valores, ya que los necesitará cuando cree una conexión con el Conector de Administración de
servicios de TI.
NOTE
Requisitos previos
Windows Management Framework 5.0 o posterior. Windows 10 tiene la versión 5.1 de forma predeterminada.
Puede descargar el marco desde aquí:
Use el siguiente script:
####################################
# User Configuration Section Begins
####################################
# Subscription name in Azure account. Check in Azure Portal.

$azureSubscriptionName = ""
# Resource group name for resource deployment. Could be an existing resource group or a new one to be
created.
$resourceGroupName = ""
# Location for existing resource group or new resource group deployment

################################### List of available regions
#################################################
# centralus,eastasia,southeastasia,eastus,eastus2,westus,westus2,northcentralus,southcentralus,westcentralus,
#
northeurope,westeurope,japaneast,japanwest,brazilsouth,australiasoutheast,australiaeast,westindia,southindia,
# centralindia,canadacentral,canadaeast,uksouth,ukwest.
#############################################################################################################
##
$location = ""
# Service Manager Authentication Settings

$serverName = ""
$domain = ""
$username = ""
$password = ""
# Azure site Name Prefix. Default is "smoc". It can be configured to any desired value.
$siteNamePrefix = ""
# Service Bus namespace. Please provide an already existing service bus namespace.
# If it doesn't exist, a new one will be created with name $siteName + "sbn" which can also be later reused
for any other hybrid connections.
$serviceName = ""
##################################
# User Configuration Section Ends
##################################
################
# Installations
################
# Allowing the execution of the script for current user.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser -Force
Write-Host "Checking for required modules..."

if(!(Get-PackageProvider -Name NuGet))
{
Write-Host "Installing NuGet Package Provider..."
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Scope CurrentUser -Force -WarningAction
SilentlyContinue
}
$module = Get-Module -ListAvailable -Name Az
if(!$module -or ($module[0].Version.Major -lt 1))

{
Write-Host "Installing Az Module..."
try
{
# In case of Win 10 Anniversary update
Install-Module Az -MinimumVersion 1.0 -Scope CurrentUser -Force -WarningAction SilentlyContinue -
AllowClobber
}
catch
{
Install-Module Az -MinimumVersion 1.0 -Scope CurrentUser -Force -WarningAction SilentlyContinue
}
Write-Host "Requirement check complete!!"
#############
# Parameters
#############
$errorActionPreference = "Stop"
$templateUri = "https://raw.githubusercontent.com/Azure/SMOMSConnector/master/azuredeploy.json"
if(!$siteNamePrefix)
{
$siteNamePrefix = "smoc"
}
Connect-AzAccount
$context = Set-AzContext -SubscriptionName $azureSubscriptionName -WarningAction SilentlyContinue
$resourceProvider = Get-AzResourceProvider -ProviderNamespace Microsoft.Web
if(!$resourceProvider -or $resourceProvider[0].RegistrationState -ne "Registered")

{
try
{
Write-Host "Registering Microsoft.Web Resource Provider"
Register-AzResourceProvider -ProviderNamespace Microsoft.Web
}
catch
{
Write-Host "Failed to Register Microsoft.Web Resource Provider. Please register it in Azure Portal."
exit
}
}
do
{
$rand = Get-Random -Maximum 32000
$siteName = $siteNamePrefix + $rand
$resource = Get-AzResource -Name $siteName -ResourceType Microsoft.Web/sites
}while($resource)
$azureSite = "https://"+$siteName+".azurewebsites.net"
##############
# MAIN Begins
##############
# Web App Deployment

####################
$tenant = $context.Tenant.Id
if(!$tenant)
{
#For backward compatibility with older versions
$tenant = $context.Tenant.TenantId
}
try
{
Get-AzResourceGroup -Name $resourceGroupName
}
catch
{
New-AzResourceGroup -Location $location -Name $resourceGroupName
}
Write-Output "Web App Deployment in progress...."
New-AzResourceGroupDeployment -TemplateUri $templateUri -siteName $siteName -ResourceGroupName

$resourceGroupName
Write-Output "Web App Deployed successfully!!"
# AAD Authentication
####################
Add-Type -AssemblyName System.Web
$secret = [System.Web.Security.Membership]::GeneratePassword(30,2).ToString()
$secret = [System.Web.Security.Membership]::GeneratePassword(30,2).ToString()
$clientSecret = $secret | ConvertTo-SecureString -AsPlainText -Force
try
{
Write-Host "Creating AzureAD application..."
$adApp = New-AzADApplication -DisplayName $siteName -HomePage $azureSite -IdentifierUris $azureSite -

Password $clientSecret
Write-Host "AzureAD application created successfully!!"

}
catch
{
# Delete the deployed web app if Azure AD application fails
Remove-AzResource -ResourceGroupName $resourceGroupName -ResourceName $siteName -ResourceType
Microsoft.Web/sites -Force
Write-Host "Failure occurred in Azure AD application....Try again!!"
exit
$clientId = $adApp.ApplicationId
$servicePrincipal = New-AzADServicePrincipal -ApplicationId $clientId
# Web App Configuration

#######################
try
{
Write-Host "Configuring deployed Web-App..."

$webApp = Get-AzWebAppSlot -ResourceGroupName $resourceGroupName -Name $siteName -Slot production -
WarningAction SilentlyContinue
$appSettingList = $webApp.SiteConfig.AppSettings
$appSettings = @{}
ForEach ($item in $appSettingList) {
$appSettings[$item.Name] = $item.Value
}
$appSettings['ida:Tenant'] = $tenant
$appSettings['ida:Audience'] = $azureSite
$appSettings['ida:ServerName'] = $serverName
$appSettings['ida:Domain'] = $domain
$appSettings['ida:Username'] = $userName
$appSettings['ida:WhitelistedClientId'] = $clientId
$connStrings = @{}
$kvp = @{"Type"="Custom"; "Value"=$password}
$connStrings['ida:Password'] = $kvp
Set-AzWebAppSlot -ResourceGroupName $resourceGroupName -Name $siteName -AppSettings $appSettings -

ConnectionStrings $connStrings -Slot production -WarningAction SilentlyContinue
}
catch
{
Write-Host "Web App configuration failed. Please ensure all values are provided in Service Manager
Authentication Settings in User Configuration Section"
# Delete the AzureRm AD Application if configuration fails

Remove-AzADApplication -ObjectId $adApp.ObjectId -Force
# Delete the deployed web app if configuration fails

# Delete the deployed web app if configuration fails
Remove-AzResource -ResourceGroupName $resourceGroupName -ResourceName $siteName -ResourceType
Microsoft.Web/sites -Force
exit
}
# Relay Namespace
###################
if(!$serviceName)
{
$serviceName = $siteName + "sbn"
}
$resourceProvider = Get-AzResourceProvider -ProviderNamespace Microsoft.Relay
if(!$resourceProvider -or $resourceProvider[0].RegistrationState -ne "Registered")

{
try
{
Write-Host "Registering Microsoft.Relay Resource Provider"
Register-AzResourceProvider -ProviderNamespace Microsoft.Relay
}
catch
{
Write-Host "Failed to Register Microsoft.Relay Resource Provider. Please register it in Azure
Portal."
}
}
$resource = Get-AzResource -Name $serviceName -ResourceType Microsoft.Relay/namespaces
if(!$resource)
{
$serviceName = $siteName + "sbn"
$properties = @{
"sku" = @{
"name"= "Standard"
"tier"= "Standard"
"capacity"= 1
}
}
try
{
Write-Host "Creating Service Bus namespace..."
New-AzResource -ResourceName $serviceName -Location $location -PropertyObject $properties -
ResourceGroupName $resourceGroupName -ResourceType Microsoft.Relay/namespaces -ApiVersion 2016-07-01 -Force
}
catch
{
$err = $TRUE
Write-Host "Creation of Service Bus Namespace failed...Please create it manually from Azure
Portal.`n"
}
Write-Host "Note: Please Configure Hybrid connection in the Networking section of the web application in
Azure Portal to link to the on-premises system.`n"
Write-Host "App Details"
Write-Host "============"
Write-Host "App Name:" $siteName
Write-Host "Client Id:" $clientId
Write-Host "Client Secret:" $secret
Write-Host "URI:" $azureSite
if(!$err)
{
Write-Host "ServiceBus Namespace:" $serviceName
Write-Host "ServiceBus Namespace:" $serviceName
}
Pasos siguientes
Configuración de la conexión híbrida.
Cómo corregir manualmente los problemas de
sincronización de ServiceNow
Azure Monitor puede conectarse a otros proveedores de Administración de servicios de TI (ITSM) de terceros.
ServiceNow es uno de estos proveedores.
Por motivos de seguridad, puede que tenga que actualizar el token de autenticación que se usa para la conexión
con ServiceNow. Use el proceso de sincronización siguiente para volver a activar la conexión y actualizar el token:
1. Busque la solución en el banner de búsqueda superior y, luego, seleccione las soluciones apropiadas.
2. En la pantalla de la solución, elija "Seleccionar todo" en el filtro de suscripción y, a continuación, filtre por
"ServiceDesk".
3. Seleccione la solución de la conexión de ITSM.

4. Seleccione la conexión de ITSM en el banner izquierdo.
5. Seleccione cada conector en la lista.

a. Haga clic en el nombre del conector para configurarlo.
b. Elimine los conectores que ya no se estén usando.
c. Actualice los campos de acuerdo con estas definiciones según el tipo de asociado.
d. Haga clic en Sincronizar
e. Haga clic en Guardar
f. Revise las notificaciones para comprobar si el proceso finalizó correctamente
Pasos siguientes
Más información sobre las Conexiones IT Service Management
Solución Alert Management en Azure Log Analytics
NOTE
Azure Monitor ahora es compatible con funcionalidades mejoradas para la administración de alertas a escala, incluidas las
generadas por las herramientas de supervisión como System Center Operations Manager, Zabbix o Nagios.
La solución Administración de alertas le ayuda a analizar todas las alertas del repositorio de Log Analytics. Estas
alertas pueden proceder de diversos orígenes, incluidos los creados por Log Analytics o los importados de Nagios
o Zabbix. La solución también importa alertas desde cualquier grupo de administración conectado de System
Center Operations Manager.
Prerrequisitos
La solución funciona con todos los registros del repositorio de Log Analytics con un tipo de Aler ta , por lo que
debe realizar las configuraciones que sean necesarias para recopilar estos registros.
Para las alertas de Log Analytics, cree reglas de alerta para crear registros de alerta directamente en el
repositorio.
Para las alertas de Nagios y Zabbix, configure esos servidores para que envíen alertas a Log Analytics.
Para las alertas de System Center Operations Manager,conecte el grupo de administración de Operations
Manager al área de trabajo de Log Analytics. Las alertas creadas en System Center Operations Manager se
importan en Log Analytics.
Configuración
Agregue la solución Alert Management al área de trabajo de Log Analytics mediante el proceso descrito en
Adición de soluciones. No es necesario realizar ninguna configuración más.
Si el grupo de administración de System Center Operations Manager está conectado al área de trabajo de Log
Analytics, se instalarán los siguientes módulos de administración en System Center Operations Manager al
agregar esta solución. No es necesario realizar tareas de configuración o mantenimiento de estos módulos de
administración.
Administración de alertas de Microsoft System Center Advisor (Microsoft.IntelligencePacks.AlertManagement)
Para obtener más información sobre cómo se actualizan los módulos de administración de soluciones, consulte
Conexión de Operations Manager con Log Analytics.
Agentes
En la tabla siguiente se describen los orígenes conectados que son compatibles con esta solución.
O RIGEN C O N EC TA DO SO P O RT E T ÉC N IC O DESC RIP C IÓ N
Agentes de Windows No Los agentes directos de Windows no

generan alertas. Se pueden crear alertas
de Log Analytics de eventos y datos de
rendimiento recopilados desde agentes
de Windows.
Agentes de Linux No Los agentes directos de Linux no

generan alertas. Se pueden crear alertas
de Log Analytics de eventos y datos de
rendimiento recopilados desde agentes
de Linux. Las alertas de Nagios y Zabbix
se recopilan desde los servidores que
requieren el agente de Linux.
Grupo de administración de System Sí Las alertas que se generan en agentes

Center Operations de Operations Manager se entregan al
grupo de administración y luego se
reenvían a Log Analytics.
No se requiere ninguna conexión

directa entre los agentes de Operations
Manager y Log Analytics. Los datos de
alerta se reenvían desde el grupo de
administración al repositorio de Log
Analytics.
Frecuencia de recopilación
Todos los registros de alerta están disponibles para la solución en cuanto se almacenan en el repositorio.
Los datos de alerta se envían desde el grupo de administración de Operations Manager a Log Analytics cada
tres minutos.
Uso de la solución
Al agregar la solución Alert Management al área de trabajo de Log Analytics, se agrega el icono Aler t
Management al panel. Este icono muestra un recuento y una representación gráfica del número de alertas
actualmente activas que se generaron en las últimas 24 horas. Este intervalo de tiempo no se puede cambiar.
Haga clic en el icono Administración de aler tas para abrir el panel Administración de aler tas . El panel
incluye las columnas de la tabla siguiente. Cada columna muestra las diez principales alertas por recuento que
coinciden con los criterios de esa columna para el ámbito e intervalo de tiempo especificados. Puede ejecutar una
búsqueda de registros que proporcione toda la lista haciendo clic en Ver todo en la parte inferior de la columna o
haciendo clic en el encabezado de columna.
Alertas críticas Todas las alertas con una gravedad crítica agrupadas por
nombre de alerta. Haga clic en un nombre de la alerta para
ejecutar una búsqueda de registros que devuelva todos los
registros de esa alerta.
Alertas de advertencia Todas las alertas con una gravedad de advertencia agrupadas
por nombre de alerta. Haga clic en un nombre de la alerta
para ejecutar una búsqueda de registros que devuelva todos
los registros de esa alerta.
Alertas activas de System Center Operations Manager Todas las alertas recopiladas desde Operations Manager con
cualquier estado distinto de Cerrado agrupadas por el origen
que generó la alerta.
Todas las alertas activas Todas las alertas con cualquier gravedad agrupadas por
nombre de alerta. Solo incluye las alertas de Operations
Manager con cualquier estado distinto de Cerrado.
Si se desplaza a la derecha, el panel mostrará varias consultas comunes en las que puede hacer clic para realizar
una búsqueda de registros para datos de alertas.
Registros de Log Analytics

La solución Administración de alertas analiza todos los registros con un tipo de Aler ta . La solución no recopila
directamente las alertas creadas por Log Analytics o recopiladas desde Nagios o Zabbix.
La solución importa alertas desde System Center Operations Manager y crea un registro correspondiente para
cada una con un tipo de Aler ta y un SourceSystem de OpsManager . Estos registros tienen las propiedades de la
tabla siguiente:
Type Alerta
SourceSystem OpsManager
AlertContext Detalles del elemento de datos que provocó la alerta

generados en formato XML.
AlertDescription Descripción detallada de la alerta.
AlertId GUID de la alerta.
AlertName Nombre de la alerta
AlertPriority Nivel de prioridad de la alerta.
AlertSeverity Nivel de gravedad de la alerta.
AlertState Estado de resolución más reciente de la alerta.
LastModifiedBy Nombre del usuario que modificó por última vez la alerta.
ManagementGroupName Nombre del grupo de administración donde se generó la

alerta.
RepeatCount Número de veces que se generó la misma alerta para el

mismo objeto supervisado desde que se resolvió.
ResolvedBy Nombre del usuario que resolvió la alerta. Vacío si la alerta

todavía no se ha resuelto.
SourceDisplayName Nombre para mostrar del objeto de supervisión que generó la

alerta.
SourceFullName Nombre completo del objeto de supervisión que generó la

alerta.
TicketId Id. de vale para la alerta si el entorno de System Center

Operations Manager está integrado con un proceso para
asignar vales para las alertas. Vacío si no se asigna ningún vale.
TimeGenerated Fecha y hora en que se creó la alerta.
TimeLastModified Fecha y hora en que se cambió la alerta.
TimeRaised Fecha y hora en que se generó la alerta.
TimeResolved Fecha y hora en que se resolvió la alerta. Vacío si la alerta

todavía no se ha resuelto.
Búsquedas de registros de ejemplo

La tabla siguiente proporciona búsquedas de registros de ejemplo para los registros de alerta recopilados por esta
solución:
Alert | where SourceSystem == "OpsManager" and Alertas críticas generadas durante las últimas 24 horas
AlertSeverity == "error" and TimeRaised > ago(24h)
Alert | where AlertSeverity == "warning" and TimeRaised > Alertas de advertencia generadas durante las últimas 24
ago(24h) horas
Alert | where SourceSystem == "OpsManager" and AlertState Orígenes con alertas activas generadas durante las últimas 24
!= "Closed" and TimeRaised > ago(24h) | summarize Count = horas
count() by SourceDisplayName
Alert | where SourceSystem == "OpsManager" and Alertas críticas generadas durante las últimas 24 horas que
AlertSeverity == "error" and TimeRaised > ago(24h) and todavía están activas
AlertState != "Closed"
Alert | where SourceSystem == "OpsManager" and Alertas generadas durante las últimas 24 horas que ahora
TimeRaised > ago(24h) and AlertState == "Closed" están cerradas
Alert | where SourceSystem == "OpsManager" and Alertas generadas durante el último día agrupadas por su
TimeRaised > ago(1d) | summarize Count = count() by gravedad
AlertSeverity
Alert | where SourceSystem == "OpsManager" and Alertas generadas durante el último día ordenadas por su
TimeRaised > ago(1d) | sort by RepeatCount desc valor de número de repeticiones
Pasos siguientes
Obtenga información sobre alertas en Log Analytics para más detalles sobre la generación de alertas desde
Log Analytics.
¿Qué son las alertas clásicas en Microsoft Azure?
NOTE
En este artículo se describe cómo crear alertas de métrica clásicas más antiguas. Azure Monitor ahora es compatible con
una nueva experiencia de alertas y las más recientes alertas de métrica casi en tiempo real. Las alertas clásicas se retiran,
aunque siguen con un uso limitado para los recursos que aún no admiten las nuevas alertas.
Las alertas le permiten configurar las condiciones en los datos y recibir notificaciones cuando las condiciones
coinciden con los datos de supervisión más actualizados.
Funcionalidades de alertas antiguas y nuevas

Anteriormente, Azure Monitor, Application Insights, Log Analytics y Service Health tenían funcionalidades
independientes de generación de alertas. Con el tiempo, Azure ha mejorado y combinado la interfaz de usuario y
los distintos métodos de alerta. La consolidación aún está en proceso.
Puede ver las alertas clásicas solo en la pantalla de usuario de alertas clásicas en Azure Portal. Para acceder a esta
pantalla, debe seleccionar el botón Ver aler tas clásicas en la pantalla de alertas.
La nueva experiencia de usuario para alertas presenta las siguientes ventajas en comparación con la experiencia
de alertas clásicas:
Mejor sistema de notificaciones : todas las nuevas alertas usan grupos de acciones, que se denominan
grupos de notificaciones y acciones que pueden reutilizarse en varias alertas. Las alertas de métricas clásicas y
las alertas de Log Analytics más antiguas no usan grupos de acciones.
Una experiencia de creación unificada : la creación de todas las alertas para las métricas, los registros y el
registro de actividad en Azure Monitor, Log Analytics y Application Insights está disponible desde un solo
lugar.
Visualización de las aler tas desencadenadas de Log Analytics en Azure Por tal : ahora también
puede ver las alertas desencadenadas de Log Analytics en su suscripción. Anteriormente, estas se
encontraban en un portal independiente.
Separación de las aler tas desencadenadas y las reglas de aler tas : las reglas de alertas (la definición
de la condición que desencadena una alerta) y las alertas desencadenadas (una instancia de la activación de
regla de alertas) están diferenciadas, es decir, que las vistas operativas y de configuración son independientes.
Mejor flujo de trabajo : la nueva experiencia de creación de Alertas guía al usuario en el proceso de
configuración de una regla de alertas, lo que facilita la detección de las condiciones correctas para que se
active una alerta.
Consolidación de aler tas inteligentes y configuración del estado de aler ta : las alertas más recientes
incluyen la funcionalidad de agrupación automática, que muestra las alertas similares juntas para reducir la
sobrecarga de la interfaz de usuario.
Las alertas de métricas más recientes presentan estas ventajas en comparación con las alertas de métricas
clásicas:
Latencia mejorada : las nuevas alertas de métricas se pueden ejecutar con una frecuencia de cada minuto.
Las alertas de métricas anteriores siempre se ejecutan con una frecuencia de 5 minutos. Las alertas más
recientes tienen un retraso cada vez menor desde que tiene lugar el problema hasta la notificación o acción
(de 3 a 5 minutos). Las alertas anteriores tardan entre 5 y 15 minutos, según el tipo. Las alertas de registro
suelen tener un retraso de 10 a 15 minutos debido al tiempo que se tarda en ingerir los registros, pero los
métodos de procesamiento más recientes reducen ese tiempo.
Compatibilidad con métricas multidimensionales : puede enviar alertas sobre las métricas
dimensionales que le permiten supervisar un segmento interesante de la métrica.
Más control sobre las condiciones de la métrica : Puede definir reglas de alertas más sofisticadas. Las
nuevas alertas admiten la supervisión de los valores máximos, mínimos, promedio y totales de las métricas.
Super visión combinada de varias métricas : se pueden supervisar varias métricas (actualmente hasta dos
métricas) con una sola regla. Si ambas métricas incumplen sus respectivos umbrales durante el período
especificado, se desencadena una alerta.
Mejor sistema de notificaciones : todas las nuevas alertas usan grupos de acciones, que se denominan
grupos de notificaciones y acciones que pueden reutilizarse en varias alertas. Las alertas de métricas clásicas y
las alertas de Log Analytics más antiguas no usan grupos de acciones.
Métricas de registros (versión preliminar pública): los datos de registro que van a Log Analytics ahora se
pueden extraer y convertir en métricas de Azure Monitor y luego en alertas como cualquier otra métrica.
Consulte el artículo sobre para conocer la terminología específica de las alertas clásicas.
alertas ( clásicas)
Alertas clásicas sobre datos de Azure Monitor

Hay dos tipos de alertas clásicas disponibles: alertas de métricas y alertas de registro de actividad.
Aler tas de métricas clásicas : la alerta se desencadena cuando el valor de una métrica específica cruza
un umbral que se le haya asignado. La alerta en cuestión genera una notificación cuando se sobrepasa el
umbral y se cumple la condición de alerta. En ese momento, la alerta se considera "Activada". Genera otra
notificación cuando se "resuelve" (esto es, cuando se sobrepasa el umbral de nuevo y ya no se cumple la
condición).
Aler tas clásicas de registro de actividad : una alerta de registro de streaming que se desencadena en
un evento de registro de actividad que coincide con los criterios de filtro. Estas alertas tienen solo un
estado "Activado". El motor de alertas simplemente aplica los criterios del filtro a cualquier evento nuevo.
No busca las entradas más antiguas. Se pueden utilizar estas alertas para recibir notificaciones cuando se
produzca un incidente de Service Health o cuando un usuario o una aplicación realice una operación en su
suscripción, por ejemplo, "Eliminar máquina virtual".
Para los datos del registro de recursos disponibles mediante Azure Monitor, enrute los datos a Log Analytics y
use una alerta de consulta de registros. Log Analytics utiliza ahora el nuevo método de alertas
El diagrama siguiente resume los orígenes de datos en Azure Monitor y, de forma conceptual, la manera en la
que se puede se puede alertar sobre esos datos.
Taxonomía de alertas (clásicas)
Azure utiliza los siguientes términos para describir las alertas clásicas y sus funciones:
Aler ta : una definición de criterios (una o más reglas o condiciones) que se activa cuando se cumplen.
Activo : estado en el que se cumplen los criterios definidos por una alerta clásica.
Resuelto : estado en el que ya no se cumplen los criterios definidos por una alerta clásica, después de que se
cumplieran con anterioridad.
Notificación : acción que se realiza a partir de la activación de una alerta clásica.
Acción : una llamada específica que se envían al receptor de una notificación (por ejemplo, envío de un correo
electrónico a una dirección o una publicación en una dirección URL de webhook). Las notificaciones
normalmente pueden desencadenar varias acciones.
¿Cómo se puede recibir una notificación de una alerta clásica de Azure

Monitor?
Históricamente, las alertas de Azure de distintos servicios usan sus propios métodos de notificación integrados.
Azure Monitor creó una agrupación de notificaciones reutilizables denominada grupos de acciones. Los grupos
de acciones especifican un conjunto de receptores para una notificación. Cada vez que se activa una alerta que
hace referencia al grupo de acción, todos los receptores reciben esa notificación. Los grupos de acciones
permiten reutilizar una agrupación de receptores (por ejemplo, la lista de ingenieros de guardia) a través de
muchos objetos de alerta. Los grupos de acciones admiten la notificación mediante la publicación en una URL de
webhook, además de direcciones de correo electrónico, números de SMS y otras acciones. Para más información,
consulte Grupos de acciones.
Las alertas clásicas anteriores del registro de actividad usan grupos de acciones.
Pero las anteriores alertas de métricas aún no los utilizan. En cambio, se pueden configurar las siguientes
acciones:
Enviar notificaciones de correo electrónico al administrador de servicios o a los coadministradores, o a las
direcciones de correo electrónico adicionales que especifique.
Llamar a un webhook, que permite iniciar acciones de automatización adicionales.
Los webhooks permiten la automatización y corrección, por ejemplo, mediante:
Runbook de Azure Automation
Función de Azure
Aplicación lógica de Azure
un servicio de terceros
Pasos siguientes
Obtenga información sobre las reglas de alertas y su configuración mediante:
Más información sobre las métricas
Configuración de alertas de métricas clásicas a través de Azure Portal
Configuración de alertas de métricas clásicas a través de PowerShell
Configuración de alertas de métricas clásicas con la interfaz de línea de comandos (CLI)
Configuración de alertas de métricas clásicas con la API de REST de Azure Monitor
Más información sobre el registro de actividad
Configuración de alertas del registro de actividad a través de Azure Portal
Configuración de alertas del registro de actividad a través de Resource Manager
Revisión del esquema de webhook de alertas del registro de actividad
Obtenga más información sobre los grupos de acciones
Configuración de alertas más recientes
Preparar las aplicaciones lógicas y los runbooks para
la migración de las reglas de alertas clásicas
NOTE
Como se anunció anteriormente, se retiran las alertas clásicas en Azure Monitor, aunque se siguen usando de forma limitada
para los recursos que aún no admiten las nuevas alertas. La fecha de retirada de esas alertas se ha prolongado. Pronto se
anunciará una nueva fecha.
Si opta por migrar voluntariamente las reglas de alertas clásicas a las nuevas reglas de alertas, tenga en cuenta
que existen algunas diferencias entre los dos sistemas. En este artículo se explican esas diferencias y cómo puede
prepararse para el cambio.
Cambios de API
Las API que crean y administran las reglas de alertas clásicas ( microsoft.insights/alertrules ) son diferentes de
las API que crean y administran las nuevas alertas de métricas ( microsoft.insights/metricalerts ). Si crea y
administra mediante programación reglas de alertas clásicas hoy, actualice los scripts de implementación para
trabajar con las nuevas API.
La tabla siguiente es una referencia a las interfaces de programación para las alertas clásicas y nuevas:
T IP O DE SC RIP T DE IM P L EM EN TA C IÓ N A L ERTA S C L Á SIC A S N UEVA S A L ERTA S DE M ÉT RIC A S
API DE REST microsoft.insights/alertrules microsoft.insights/metricalerts
Azure CLI az monitor alert az monitor metrics alert
PowerShell Referencia Referencia
Plantilla del Administrador de recursos Para alertas clásicas Para nuevas alertas de métricas
de Azure
Cambios de carga de notificación

El formato de carga de notificación es ligeramente diferente entre las reglas de alertas clásicas y las nuevas alertas
de métricas. Si tiene alguna acción de webhook, aplicación lógica o runbook que se desencadene mediante reglas
de alertas clásicas, debe actualizar esos puntos de conexión de notificación para que acepten el formato de carga
de las nuevas alertas de métricas.
Utilice la tabla siguiente para asignar los campos de carga de webhook del formato clásico al nuevo formato:
T IP O DE P UN TO DE C O N EXIÓ N DE
N OT IF IC A C IO N ES A L ERTA S C L Á SIC A S N UEVA S A L ERTA S DE M ÉT RIC A S
¿Se activó o resolvió la alerta? status data.status

T IP O DE P UN TO DE C O N EXIÓ N DE
N OT IF IC A C IO N ES A L ERTA S C L Á SIC A S N UEVA S A L ERTA S DE M ÉT RIC A S
Información contextual sobre la alerta contextoo data.context
Marca de tiempo en que se activó o context.timestamp data.context.timestamp

resolvió la alerta
Id. de regla de alerta context.id data.context.id
Nombre de regla de alerta context.name data.context.name
Descripción de la regla de alerta context.description data.context.description
Condición de regla de alerta context.condition data.context.condition
Nombre de métrica context.condition.metricName data.context.condition.allOf[0].met

ricName
Agregación de tiempo (cómo se agrega context.condition.timeAggregatio context.condition.timeAggregation

la métrica en la ventana de evaluación) n
Período de evaluación context.condition.windowSize data.context.condition.windowSize
Operador (cómo se compara el valor de context.condition.operator data.context.condition.operator

métrica agregado con el umbral)
Umbral context.condition.threshold data.context.condition.allOf[0].thr

eshold
Valor de métrica context.condition.metricValue data.context.condition.allOf[0].met

ricValue
Id. de suscripción context.subscriptionId data.context.subscriptionId
Grupo de recursos del recurso afectado context.resourceGroup data.context.resourceGroup
Nombre del recurso afectado context.resourceName data.context.resourceName
Tipo del recurso afectado context.resourceType data.context.resourceType
Id. del recurso afectado context.resourceId data.context.resourceId
Vínculo directo a la página de resumen context.por talLink data.context.por talLink

de recursos del portal
Campos de carga personalizada que se proper ties data.proper ties

deben pasar a la aplicación lógica o
webhook
Las cargas son similares, como puede ver. En la siguiente sección se ofrece:
Detalles acerca de cómo modificar las aplicaciones lógicas para trabajar con el nuevo formato.
Un ejemplo de runbook que analiza la carga de notificación para las alertas nuevas.
Modificar una aplicación lógica para recibir una notificación de alerta
de métrica
Si usa aplicaciones lógicas con alertas clásicas, debe modificar el código de aplicación de lógica para analizar la
nueva carga de alertas de métricas. Siga estos pasos:
1. Cree una nueva aplicación lógica.
2. Use la plantilla "Azure Monitor - Metrics Alert Handler" (Azure Monitor: controlador de alertas de métricas).
Esta plantilla tiene un desencadenador de solicitud HTTP con el esquema apropiado definido.
3. Agregue una acción para hospedar la lógica de procesamiento.
Usar un runbook de automatización que reciba una notificación de

alerta de métrica
En el ejemplo siguiente se proporciona código de PowerShell para usar en el runbook. Este código puede analizar
las cargas para reglas de alertas de métricas clásicas y nuevas reglas de alertas de métricas.
## Example PowerShell code to use in a runbook to handle parsing of both classic and new metric alerts.
[OutputType("PSAzureOperationResponse")]
param
(
[Parameter (Mandatory=$false)]
[object] $WebhookData
)
$ErrorActionPreference = "stop"
if ($WebhookData)
{
# Get the data object from WebhookData.
$WebhookBody = (ConvertFrom-Json -InputObject $WebhookData.RequestBody)
# Determine whether the alert triggering the runbook is a classic metric alert or a new metric alert
(depends on the payload schema).
$schemaId = $WebhookBody.schemaId
Write-Verbose "schemaId: $schemaId" -Verbose
if ($schemaId -eq "AzureMonitorMetricAlert") {
# This is the new metric alert schema.

$AlertContext = [object] ($WebhookBody.data).context
$status = ($WebhookBody.data).status
# Parse fields related to alert rule condition.

$metricName = $AlertContext.condition.allOf[0].metricName
$metricValue = $AlertContext.condition.allOf[0].metricValue
$threshold = $AlertContext.condition.allOf[0].threshold
$timeAggregation = $AlertContext.condition.allOf[0].timeAggregation
}
elseif ($schemaId -eq $null) {
# This is the classic metric alert schema.
$AlertContext = [object] $WebhookBody.context
$status = $WebhookBody.status
# Parse fields related to alert rule condition.

$metricName = $AlertContext.condition.metricName
$metricValue = $AlertContext.condition.metricValue
$threshold = $AlertContext.condition.threshold
$timeAggregation = $AlertContext.condition.timeAggregation
}
else {
# The schema is neither a classic metric alert nor a new metric alert.
Write-Error "The alert data schema - $schemaId - is not supported."
}
# Parse fields related to resource affected.

$ResourceName = $AlertContext.resourceName
$ResourceType = $AlertContext.resourceType
$ResourceGroupName = $AlertContext.resourceGroupName
$ResourceId = $AlertContext.resourceId
$SubId = $AlertContext.subscriptionId
## Your logic to handle the alert here.

}
else {
# Error
Write-Error "This runbook is meant to be started from an Azure alert webhook only."
}
Para obtener un ejemplo completo de un runbook que detenga una máquina virtual cuando se desencadene una
alerta, consulte la documentación de Azure Automation.
Integración de asociados a través de webhooks
La mayoría de nuestros asociados que se integran con las alertas clásicas ya son compatibles con las nuevas
alertas de métricas a través de sus integraciones. Las integraciones conocidas que ya funcionan con las nuevas
alertas de métricas son:
PagerDuty
OpsGenie
Signl4
Si usa una integración de asociados que no aparece aquí, confirme con el proveedor de integración que funciona
la integración con las nuevas alertas de métricas.
Pasos siguientes
Descripción del funcionamiento de la herramienta de migración
Descripción de las opciones de migración para las
alertas más recientes
Las alertas clásicas se retiran, aunque siguen con un uso limitado para los recursos que aún no admiten las nuevas
alertas. Pronto se va a anunciar una nueva fecha para la migración de las alertas restante, la nube de Azure
Government y Azure China 21Vianet.
En este artículo se explica cómo funcionan las herramientas de migración manual y de migración voluntaria, que
se usarán para migrar las reglas de alertas restantes. También se describen soluciones para algunos problemas
comunes.
IMPORTANT
La migración no afecta a las alertas de registro de actividad (incluidas alertas de estado de servicio) ni las alertas de registros.
La migración solo se aplica a las reglas de alertas clásicas que se describen aquí.
NOTE
Si las reglas de alertas clásicas no son válidas, es decir, se encuentran en métricas en desuso o recursos eliminados, no se
migrarán ni estarán disponibles tras retirarse el servicio.
Migración manual de alertas clásicas a alertas más recientes

Los clientes que estén interesados en migrar manualmente las alertas restantes ya pueden hacerlo con las
secciones siguientes. Estas secciones también definen las métricas que el proveedor de recursos retira y
actualmente no se pueden migrar de manera directa.
Métricas de invitado en máquinas virtuales
Para poder crear nuevas alertas de métricas en las métricas de invitado, estas últimas se deben enviar al almacén
de métricas personalizadas de Azure Monitor. Siga estas instrucciones para habilitar el receptor de Azure Monitor
en la configuración de diagnóstico:
Habilitar métricas de invitado para VM de Windows
Habilitar métricas de invitado para VM de Linux
Una vez realizados estos pasos, puede crear nuevas alertas de métricas en las métricas de invitado. Además,
después de crear nuevas alertas de métricas, puede eliminar las alertas clásicas.
Métricas de la cuenta de almacenamiento
Todas las alertas clásicas en las cuentas de almacenamiento se pueden migrar, excepto las alertas de estas
métricas:
PercentAuthorizationError
PercentClientOtherError
PercentNetworkError
PercentServerOtherError
PercentSuccess
PercentThrottlingError
PercentTimeoutError
AnonymousThrottlingError
SASThrottlingError
ThrottlingError
La reglas de alertas clásicas en las métricas de porcentaje se deben migrar en función de la asignación entre las
métricas de almacenamiento antiguas y nuevas. Los umbrales deberán modificarse según corresponda porque la
nueva métrica disponible es absoluta.
Las reglas de alertas clásicas en AnonymousThrottlingError, SASThrottlingError y ThrottlingError deben dividirse
en dos nuevas alertas porque no hay ninguna métrica combinada que proporciona la misma funcionalidad. Los
umbrales deberán adaptarse según corresponda.
Métricas de Cosmos DB
Todas las alertas clásicas de las métricas de Cosmos DB se pueden migrar, excepto las alertas de estas métricas:
Solicitudes medias por segundo
Nivel de coherencia
Http 2xx
Http 3xx
Http 400
Http 401
Internal Server Error
Número máximo de RUPM consumidas por minuto
Número máximo de RU por segundo
Solicitudes con error de recuento de Mongo
Solicitudes con error de eliminación de Mongo
Solicitudes con error de inserción de Mongo
Otras solicitudes con error de Mongo
Cargo de otras solicitudes de Mongo
Velocidad de otras solicitudes de Mongo
Solicitudes con error de consultas de Mongo
Solicitudes con error de actualización de Mongo
Latencia de lectura observada
Latencia de escritura observada
Disponibilidad del servicio
Capacidad de almacenamiento
Solicitudes limitadas
Total de solicitudes
Actualmente no están disponibles en el nuevo sistema las solicitudes medias por segundo, el nivel de coherencia,
el número máximo de RUPM consumidas por minuto, el número máximo de RU por segundo, la latencia de lectura
observada, la latencia de escritura observada y la capacidad de almacenamiento.
Las alertas de métricas de solicitud como Http 2xx, Http 3xx, Http 400, Http 401, error interno del servidor,
disponibilidad del servicio, solicitudes limitadas y solicitudes totales no se migran porque la manera de contar las
solicitudes en las métricas clásicas y las métricas nuevas es diferente. Las alertas de este tipo deberán volver a
crearse manualmente con umbrales ajustados.
Las alertas de las métricas de solicitudes con error de Mongo deben dividirse en varias alertas, dado que no hay
ninguna métrica combinada que proporcione la misma funcionalidad. Los umbrales deberán adaptarse según
corresponda.
Métricas de proceso clásico
Las alertas de métricas de proceso clásico no se migrarán con la herramienta de migración, ya que los recursos de
proceso clásico todavía no se admiten con las nuevas alertas. La compatibilidad con nuevas alertas en estos tipos
de recursos se encuentra actualmente en versión preliminar pública y los clientes pueden volver a crear nuevas
reglas de alerta equivalentes en función de las reglas de alertas clásicas.
Reglas de alertas clásicas en métricas en desuso
Estas son las reglas de alertas clásicas en las métricas que se admitían anteriormente, pero finalmente han
quedado en desuso. Un pequeño porcentaje de clientes podría tener reglas de alertas clásicas no válidas en esas
métricas. Puesto que estas reglas de alertas no son válidas, no se migrarán.
T IP O DE REC URSO M ÉT RIC A S EN DESUSO
Microsoft.DBforMySQL/servers compute_consumption_percent, compute_limit
Microsoft.DBforPostgreSQL/servers compute_consumption_percent, compute_limit
Microsoft.Network/publicIPAddresses defaultddostriggerrate
Microsoft.SQL/servers/databases service_level_objective, storage_limit, storage_used, throttling,

dtu_consumption_percent, storage_used
Microsoft.Web/hostingEnvironments/multirolepools averagememoryworkingset
Microsoft.Web/hostingEnvironments/workerpools bytesreceived, httpqueuelength
Cómo se crean nuevas reglas de alertas equivalente y grupos de

acciones
La herramienta de migración convierte las reglas de alertas clásicas en nuevas reglas de alertas equivalentes y
grupos de acciones. Para la mayoría las reglas de alertas clásicas, las nuevas reglas de alertas equivalentes están
en la misma métrica con las mismas propiedades, como windowSize y aggregationType . Sin embargo, hay algunas
reglas de alertas clásicas que se encuentran en las métricas que tienen una métrica equivalente diferente en el
nuevo sistema. Los siguientes principios se aplican a la migración de las alertas clásicas, a menos que especifique
en la sección siguiente:
Frecuencia : define la frecuencia con la que se comprueba la condición de una regla de alertas clásicas o nueva.
El elemento frequency en las reglas de alertas clásicas era configurable por el usuario y era siempre 5 minutos
para todos los tipos de recursos, excepto los componentes de Application Insights, para el que era 1 minuto. Por
lo tanto, la frecuencia de las reglas equivalentes también se establece en 5 minutos y 1 minuto,
respectivamente.
Tipo de agregación : define cómo se agrega la métrica a través de la ventana de interés. El elemento
aggregationType también es el mismo entre las alertas clásicas y las alertas nuevas para la mayoría de las
métricas. En algunos casos, dado que la métrica es diferente entre las alertas clásicas y las alertas nuevas, se
usa el elemento aggregationType equivalente o el elemento primary Aggregation Type definido para la métrica.
Unidades : propiedad de la métrica en la que se crea la alerta. Algunas métricas equivalentes tienen unidades
diferentes. El umbral se ajusta según corresponda y en función de la necesidad. Por ejemplo, si la métrica
original tiene segundos como unidades pero la nueva métrica equivalente tiene milisegundos como unidades,
el umbral original se multiplica por 1000 para garantizar el mismo comportamiento.
Tamaño de la ventana : define la ventana durante la que los datos de la métrica se agregan para compararlos
con el umbral. Para valores windowSize estándares, como 5 minutos, 15 minutos, 30 minutos, 1 hora, 3 horas,
6 horas, 12 horas o 1 día, no hay ningún cambio realizado para la nueva regla de alertas equivalente. Para otros
valores, se usará el elemento windowSize más cercano. Para la mayoría de los clientes, este cambio no tiene
ningún impacto. Para un pequeño porcentaje de clientes, es posible que sea necesario ajustar el umbral para
obtener exactamente el mismo comportamiento.
En las secciones siguientes, detallamos las métricas que tienen una métrica diferente equivalente en el nuevo
sistema. Las métricas que permanecen iguales para las mismas reglas de alertas clásicas y nuevas no se indican.
Encontrará una lista de las métricas que se admiten en el nuevo sistema aquí.
Microsoft.StorageAccounts/services
Para servicios de cuenta de almacenamiento, como blob, tabla, archivo y cola, se asignan las siguientes métricas a
las métricas equivalentes, tal como se muestra a continuación:
M ÉT RIC A EQ UIVA L EN T E EN L A S
M ÉT RIC A EN L A S A L ERTA S C L Á SIC A S A L ERTA S N UEVA S C O M EN TA RIO S
AnonymousAuthorizationError Métrica Transacciones con las

dimensiones
"ResponseType"="AuthorizationError" y
"Authentication" = "Anonymous"
AnonymousClientOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientOtherError" y
AnonymousClientTimeOutError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientTimeOutError" y
AnonymousNetworkError Métrica Transacciones con las

dimensiones
"ResponseType"="NetworkError" y
AnonymousServerOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ServerOtherError" y
AnonymousServerTimeOutError Métrica Transacciones con las

dimensiones
"ResponseType"="ServerTimeOutError"
y "Authentication" = "Anonymous"
AnonymousSuccess Métrica Transacciones con las

dimensiones "ResponseType"="Success"
y "Authentication" = "Anonymous"
AuthorizationError Métrica Transacciones con las

dimensiones
"ResponseType"="AuthorizationError"
AverageE2ELatency SuccessE2ELatency
AverageServerLatency SuccessServerLatency
Capacity BlobCapacity Use aggregationType "average" en

lugar de "last". La métrica solo se aplica
a Blob Service
ClientOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientOtherError"
ClientTimeoutError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientTimeOutError"
ContainerCount ContainerCount Use aggregationType "average" en

a Blob Service
NetworkError Métrica Transacciones con las

dimensiones
"ResponseType"="NetworkError"
ObjectCount BlobCount Use aggregationType "average" en

a Blob Service
SASAuthorizationError Métrica Transacciones con las

dimensiones
"ResponseType"="AuthorizationError" y
"Authentication" = "SAS"
SASClientOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientOtherError" y
SASClientTimeOutError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientTimeOutError" y
SASNetworkError Métrica Transacciones con las

dimensiones
SASServerOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ServerOtherError" y
SASServerTimeOutError Métrica Transacciones con las

dimensiones
and "Authentication" = "SAS"
SASSuccess Métrica Transacciones con las

dimensiones
ServerOtherError Métrica Transacciones con las

dimensiones
"ResponseType"="ClientOtherError"
ServerTimeOutError Métrica Transacciones con las

dimensiones
Correcto Métrica Transacciones con las

dimensiones "ResponseType"="Success"
TotalBillableRequests Transacciones
TotalEgress Salida
TotalIngress Entrada
TotalRequests Transacciones
Microsoft.insights/components
Para Application Insights, las métricas equivalentes se muestran a continuación:
availability.availabilityMetric.value availabilityResults/availabilityPercentage
availability.durationMetric.value availabilityResults/duration Multiplique umbral original por 1000,

porque las unidades para la métrica
clásica se expresan en segundos y para
la nueva métrica se expresan en
milisegundos.
basicExceptionBrowser.count exceptions/browser Use aggregationType "count" en

lugar de "sum".
basicExceptionServer.count exceptions/server Use aggregationType "count" en

lugar de "sum".
clientPerformance.clientProcess.value browserTimings/processingDuration Multiplique umbral original por 1000,

milisegundos.
clientPerformance.networkConnection.v browserTimings/networkDuration Multiplique umbral original por 1000,

alue porque las unidades para la métrica
milisegundos.
clientPerformance.receiveRequest.value browserTimings/receiveDuration Multiplique umbral original por 1000,

milisegundos.
clientPerformance.sendRequest.value browserTimings/sendDuration Multiplique umbral original por 1000,

milisegundos.
clientPerformance.total.value browserTimings/totalDuration Multiplique umbral original por 1000,

milisegundos.
performanceCounter.available_bytes.val performanceCounters/memoryAvailable
ue Bytes
performanceCounter.io_data_bytes_per_ performanceCounters/processIOBytesP
sec.value erSecond
performanceCounter.number_of_exceps performanceCounters/exceptionsPerSec
_thrown_per_sec.value ond
performanceCounter.percentage_proces performanceCounters/processCpuPerce
sor_time_normalized.value ntage
performanceCounter.percentage_proces performanceCounters/processCpuPerce El umbral se tendrá que modificar

sor_time.value ntage según corresponda, ya que la métrica
original se aplicaba a todos los núcleos
mientras que la métrica nueva se
normaliza en un núcleo. La herramienta
de migración no cambia los umbrales.
performanceCounter.percentage_proces performanceCounters/processorCpuPer
sor_total.value centage
performanceCounter.process_private_by performanceCounters/processPrivateBy
tes.value tes
performanceCounter.request_execution_ performanceCounters/requestExecution
time.value Time
performanceCounter.requests_in_applic performanceCounters/requestsInQueue
ation_queue.value
performanceCounter.requests_per_sec.v performanceCounters/requestsPerSecon
alue d
request.duration requests/duration Multiplique umbral original por 1000,

milisegundos.
request.rate requests/rate
requestFailed.count requests/failed Use aggregationType "count" en

lugar de "sum".
view.count pageViews/count Use aggregationType "count" en

lugar de "sum".
Microsoft.DocumentDB/databaseAccounts
Para Cosmos DB, las métricas equivalentes se muestran a continuación:
AvailableStorage AvailableStorage
Tamaño de datos DataUsage
Recuento de documentos DocumentCount
Tamaño de índice IndexUsage
Cargo de la solicitud de recuento de MongoRequestCharge con dimensión

Mongo "CommandName" = "count"
Velocidad de la solicitud de recuento de MongoRequestsCount con dimensión

Mongo "CommandName" = "count"
Carga de la solicitud de eliminación de MongoRequestCharge con dimensión

Mongo "CommandName" = "delete"
Velocidad de la solicitud de eliminación MongoRequestsCount con dimensión

de Mongo "CommandName" = "delete"
Cargo de la solicitud de inserción de MongoRequestCharge con dimensión

Mongo "CommandName" = "insert"
Velocidad de la solicitud de inserción de MongoRequestsCount con dimensión

Mongo "CommandName" = "insert"
Cargo de la solicitud de consulta de MongoRequestCharge con dimensión

Mongo "CommandName" = "find"
Velocidad de la solicitud de consulta de MongoRequestsCount con dimensión

Mongo "CommandName" = "find"
Carga de la solicitud de actualización de MongoRequestCharge con dimensión

Mongo "CommandName" = "update"
Servicio no disponible ServiceAvailability
TotalRequestUnits TotalRequestUnits
Creación de grupos de acción equivalentes

Las reglas de alertas clásicas tenían vinculadas acciones de correo electrónico, webhook, runbook y aplicación
lógica. Las nuevas reglas de alertas usan grupos de acciones que se pueden volver a usar en varias reglas de
alertas. La herramienta de migración crea el grupo de acciones único para las mismas acciones,
independientemente de cuántas reglas de alertas usan la acción. Los grupos de acciones que crea la herramienta
de migración usan el formato de nombres "Migrated_AG*".
NOTE
Las alertas clásicas envían correos electrónicos localizados en función de la configuración regional del administrador clásico
cuando se usan para notificar roles de administrador clásico. Los nuevos mensajes de alerta se envían a través de grupos de
acciones y solo están en inglés.
Fases de lanzamiento
La herramienta de migración se está lanzando en fases para los clientes que usan reglas de alertas clásicas. Los
propietarios de suscripciones recibirán un correo electrónico cuando la suscripción esté lista para la migración
mediante el uso de la herramienta.
NOTE
Dado que la herramienta se está lanzando en fases, es posible que vea que algunas de sus suscripciones no están preparadas
para la migración durante las fases iniciales.
Actualmente, la mayoría de las suscripciones están marcadas como listas para la migración. Solo las suscripciones
que tienen alertas clásicas en los siguientes tipos de recursos todavía no están listas para la migración.
Microsoft.classicCompute/domainNames/slots/roles
Microsoft.insights/components
¿Quién puede desencadenar la migración?

Cualquier usuario que tenga el rol integrado de colaborador de supervisión en el nivel de la suscripción puede
desencadenar la migración. Los usuarios que tienen un rol personalizado con los siguientes permisos también
pueden desencadenar la migración:
*/read
Microsoft.Insights/actiongroups/*
Microsoft.Insights/AlertRules/*
Microsoft.Insights/metricAlerts/*
Microsoft.AlertsManagement/smartDetectorAlertRules/*
NOTE
Además de tener los permisos mencionados anteriormente, su suscripción debería haberse registrado en el proveedor de
recursos Microsoft.AlertsManagement. Esto es necesario para migrar correctamente las alertas de anomalías de error de
Problemas comunes y soluciones

Después de desencadenar la migración, recibirá un correo electrónico en las direcciones que proporcionó para
avisarle de que la migración se ha completado o si se requiere alguna acción de su parte. En esta sección se
describen algunos problemas comunes y cómo resolverlos.
Error de validación
Debido a algunos cambios recientes en las reglas de alertas clásicas de la suscripción, no se puede migrar la
suscripción. Este problema es temporal. Puede reiniciar la migración una vez que el estado de migración vuelva a
Ready for migration (Listo para la migración) en unos días.
Ámbito que nos impide migrar las reglas
Como parte de la migración, se crearán nuevas alertas de métricas y nuevos grupos de acciones, y luego se
eliminarán las reglas de alerta clásicas. Sin embargo, un bloqueo de ámbito puede impedir la creación o
eliminación de recursos. Según el bloqueo de ámbito, no se pudieron migrar algunas reglas o ninguna de ellas.
Puede resolver este problema si quita el bloqueo de ámbito de la suscripción, el grupo de recursos o el recurso
que aparece en la herramienta de migración y vuelve a desencadenar la migración. No se puede deshabilitar el
bloqueo del ámbito y se debe quitar mientras dure el proceso de migración. Más información sobre cómo
administrar los bloqueos de ámbito.
Directiva con efecto de denegación que nos impide migrar las reglas
Como parte de la migración, se crearán nuevas alertas de métricas y nuevos grupos de acciones, y luego se
eliminarán las reglas de alerta clásicas. Sin embargo, una directiva puede evitar la creación de recursos. Según la
directiva, no se pudieron migrar algunas reglas o ninguna de ellas. Las directivas que bloquean el proceso se
enumeran en la herramienta de migración. Para resolver este problema:
Excluya las suscripciones o los grupos de recursos mientras dure el proceso de migración de la asignación de
directiva. Más información sobre la administración del ámbito de exclusión de las directivas.
Quite o cambie el efecto a auditoría o anexión (lo que, por ejemplo, puede solucionar problemas relativos a la
ausencia de etiquetas). Obtenga más información sobre la administración del efecto de las directivas.
Pasos siguientes
Uso de la herramienta de migración voluntaria para
migrar las reglas de alertas clásicas
Como se anunció anteriormente, se retiran las alertas clásicas en Azure Monitor, aunque se siguen usando de
forma limitada para los recursos que aún no admiten las nuevas alertas. Había disponible una herramienta de
migración en Azure Portal para los clientes que usaban reglas de alertas clásicas y que deseaban desencadenar la
migración ellos mismos. En este artículo se explica cómo usar la herramienta de migración, que también se usará
para las alertas restantes pendientes de más anuncios.
Ventajas de las nuevas alertas

Las alertas clásicas están siendo remplazadas por un sistema de alertas nuevo y unificado en Azure Monitor. La
nueva plataforma de alertas consta de las siguientes ventajas:
Puede crear alertas sobre una variedad de métricas multidimensionales para muchos más servicios de Azure.
Las nuevas alertas de métricas admiten reglas de alertas de múltiples recursos que reducen en gran medida la
sobrecarga de administrar muchas reglas.
El mecanismo de notificación unificado, que admite:
Grupos de acciones, un mecanismo de notificación modular que funciona con todos los nuevos tipos de
alertas (métricas, registro y registro de actividad).
Nuevos mecanismos de notificación como SMS, voz y el Conector ITSM.
La experiencia de alertas unificada incorpora todas las alertas sobre la diferentes señales (métricas, registro y
registro de actividad) en un solo lugar.
Antes de la migración
El proceso de migración convierte las reglas de alertas clásicas a las reglas de alertas nuevas equivalentes y crea
grupos de acciones. En la preparación, tenga en cuenta los siguientes aspectos:
El formato de carga de notificación y las API para crear y administrar nuevas reglas de alertas son
diferentes de las reglas de alerta clásicas porque admiten más características. Obtenga información sobre
cómo preparar la migración.
No se pueden migrar algunas reglas de alertas clásicas mediante la herramienta. Obtenga información
sobre las reglas que no se pueden migrar y qué hacer con ellas.
NOTE
El proceso de migración no afecta a la evaluación de las reglas de alertas clásicas. Seguirán ejecutándose y enviando
alertas hasta que se hayan migrado y las nuevas reglas de alertas surtan efecto.
Cómo usar la herramienta de migración

Para desencadenar la migración de las reglas de alertas clásicas en Azure Portal, siga estos pasos:
1. En Azure Portal, seleccione Monitor .
2. Seleccione Aler tas y, a continuación, seleccione Administrar reglas de aler tas o Ver aler tas clásicas .
3. Seleccione Migrar a las nuevas reglas para ir a la página de inicio de la migración. Esta página muestra
una lista de todas las suscripciones y su estado de migración:
Todas las suscripciones que se pueden migrar mediante la herramienta están marcadas como Listo para
migrar .
NOTE
La herramienta de migración se está implementando por fases en todas las suscripciones que usan reglas de alertas
clásicas. En las primeras fases del lanzamiento, es posible que vea algunas suscripciones marcadas como no listas
para la migración.
4. Seleccione una o varias suscripciones y, a continuación, seleccione Obtener una vista previa de la
migración .
La página resultante muestra los detalles de las reglas de alertas clásicas que se migrarán para una
suscripción cada vez. También puede seleccionar Descargar los detalles de la migración de esta
suscripción para obtener los detalles en un formato CSV.
5. Especifique una o varias direcciones de correo electrónico para recibir una notificación del estado de la
migración. Recibirá un correo electrónico una vez completada la migración o si es necesaria alguna acción
por parte del usuario.
6. Seleccione Iniciar migración . Lea la información que se muestra en el cuadro de diálogo de confirmación
y confirme que está listo para iniciar el proceso de migración.
IMPORTANT
Después de iniciar la migración de una suscripción, no podrá editar o crear reglas de alertas clásicas para esa
suscripción. Esta restricción garantiza que no se pierde ningún cambio en las reglas de alertas clásicas durante la
migración a las nuevas reglas. Aunque no podrá cambiar las reglas de alertas clásicas, estas aún seguirán en
ejecución y proporcionarán alertas hasta que se hayan migrado. Una vez completada la migración de su suscripción,
ya no podrá usar más las reglas de alertas clásicas.
7. Recibirá un correo electrónico en las direcciones que proporcionó anteriormente cuando se complete la
migración o si es necesaria alguna acción por su parte. También puede comprobar periódicamente el
estado en la página de inicio de la migración en el portal.

¿Por qué mi suscripción aparece como no lista para la migración?
La herramienta de migración se está implementando en los clientes por fases. En las primeras fases, la mayoría o
todas las suscripciones pueden estar marcadas como No está lista para la migración .
Cuando una suscripción pasa a estar lista para la migración, el propietario de la suscripción recibirá un mensaje
de correo electrónico que indica que la herramienta está disponible. Esté atento de este mensaje.
¿Quién puede desencadenar la migración?
Pueden desencadenar la migración los usuarios que tengan el rol de colaborador de supervisión asignado en el
nivel de suscripción. Más información sobre el Control de acceso basado en rol para el proceso de migración.
¿Cuánto tiempo tardará la migración?
La migración se completa en menos de una hora para la mayoría de las suscripciones. Puede realizar un
seguimiento del estado de la migración en la página de inicio de la migración. Durante la migración, se garantiza
que las alertas todavía se ejecutan en el sistema de alertas clásicas o en el nuevo.
¿Qué puedo hacer si surge algún problema durante la migración?
Consulte la guía de solución de problemas para obtener ayuda con los problemas que se pueden producir
durante la migración. Si es necesaria alguna acción por parte del usuario para completar la migración, se le
notificará en las direcciones de correo electrónico que proporcionó al configurar la herramienta.
Pasos siguientes
Descripción del proceso de migración automática de
reglas de alertas clásicas
Como se anunció anteriormente, se retiran las alertas clásicas en Azure Monitor, aunque se siguen usando de
forma limitada para los recursos que aún no admiten las nuevas alertas. Como parte del proceso de retirada, hay
disponible una herramienta de migración en Azure Portal para que los clientes puedan desencadenar la migración
ellos mismos. Este artículo le guiará a través del proceso de migración automática y le ayudará a resolver los
problemas que pueda tener.
NOTE
Este artículo solo es válido en la nube pública de Azure. El proceso de retirada de alertas clásicas de Azure Monitor en la nube
de Azure Government y Azure China 21Vianet se anunciará próximamente.
¿Qué ocurrirá durante el proceso de migración automática?

A partir del 1 de septiembre de 2019 , los clientes no podrán crear reglas de alertas clásicas, excepto en
algunas métricas.
En el caso de las excepciones, los clientes pueden seguir creando reglas de alertas clásicas y usar sus alertas
clásicas hasta nuevo aviso.
A partir del 1 de septiembre de 2019 , la migración de alertas clásicas de todos los clientes que tengan
alertas clásicas se desencadenará por lotes.
Al igual que sucede con la herramienta de migración voluntaria, algunas reglas de alertas clásicas que no se
pueden migrar se dejarán tal cual están. Estas reglas de alertas clásicas se seguirán admitiendo hasta nuevo
aviso. Sin embargo, las reglas de alertas clásicas no válidas se eliminarán, porque dejarán de ser funcionales.
Las reglas de alertas clásicas que supervisen recursos de destino eliminados o que remitan a métricas que
ya no se admiten se considerarán no válidas.
Una vez iniciada la migración de la suscripción, esta deberá completarse en un plazo de una hora (a menos
que surjan problemas). Los clientes pueden supervisar el estado de la migración en la hoja de migración en
Azure Monitor.
Los propietarios de la suscripción recibirán un correo electrónico cuando la migración se complete
correctamente.
Si hay algún problema durante la migración, los propietarios de la suscripción también recibirán un correo
electrónico donde se les informará convenientemente. Los clientes pueden usar la hoja de migración para
ver todos los detalles del problema.
En caso de que se requiera una acción por parte de los clientes, como deshabilitar temporalmente un
bloqueo de recursos o cambiar una asignación de directiva, los clientes tendrán que resolver estos
problemas. Si no se resuelven, no se puede garantizar la migración correcta de las alertas clásicas.
NOTE
Si no desea esperar a que se inicie el proceso de migración automática, puede desencadenarla voluntariamente con la
herramienta de migración.
Aspectos importantes que tener en cuenta

El proceso de migración convierte las reglas de alertas clásicas a las reglas de alertas nuevas equivalentes y crea
grupos de acciones. En la preparación, tenga en cuenta los siguientes aspectos:
Los formatos de carga de notificación de las nuevas reglas de alertas son diferentes de las reglas de alertas
clásicas porque admiten más características. Si tiene aplicaciones lógicas, runbooks o webhooks que se
desencadenan mediante una regla de alerta clásica, podrían dejar de funcionar según lo previsto una vez
que se complete la migración, dadas las diferencias en las cargas de notificación. Obtenga información sobre
cómo preparar la migración.
Algunas reglas de alertas clásicas no se pueden migrar mediante la herramienta. Obtenga información sobre
las reglas que no se pueden migrar y qué hacer con ellas.
NOTE
El proceso de migración no afecta a la evaluación de las reglas de alertas clásicas. Seguirán ejecutándose y enviando
alertas hasta que se hayan migrado y las nuevas reglas de alertas surtan efecto.
¿Qué ocurre si se produce un error en la migración automática?

Cuando se produce un error en el proceso de migración automática, los propietarios de la suscripción recibirán un
correo electrónico donde se les informará del problema. Se puede usar la hoja de migración en Azure Monitor para
ver todos los detalles del problema.
Consulte la guía de solución de problemas para obtener ayuda con los problemas que se pueden producir durante
la migración.
NOTE
En caso de que se requiera una acción por parte de los clientes, como deshabilitar temporalmente un bloqueo de recursos o
cambiar una asignación de directiva, los clientes tendrán que resolver estos problemas. Si no se resuelven, no se puede
garantizar la migración correcta de las alertas clásicas.
Pasos siguientes
Creación, visualización y administración de alertas
de métricas clásicas mediante Azure Monitor
WARNING
En este artículo se describe cómo crear alertas de métrica clásicas más antiguas. Azure Monitor ahora es compatible con
Las alertas de métricas clásicas en Azure Monitor proporcionan una forma de recibir notificaciones cuando una
de sus métricas cruza un umbral. Las alertas de métricas clásicas son una funcionalidad más antigua que
permiten enviar alertas solo en métricas no dimensionales. Existe una funcionalidad más reciente existente
llamada Alertas de métricas que ha mejorado la funcionalidad de las alertas de métricas clásicas. Puede obtener
más información acerca de la nueva funcionalidad de alertas de indicadores en la información general de las
alertas de métricas. En este artículo describiremos cómo crear, ver y administrar las reglas de alerta de métricas
clásicas a través de Azure Portal, Azure CLI y Powershell.
Con Azure Portal

1. En el portal, busque el recurso que desea supervisar y, a continuación, selecciónelo.
2. En la sección SUPERVISIÓN , seleccione Aler tas (clásico) . El texto y el icono pueden variar ligeramente
en los distintos recursos. Si no encuentra Aler tas (clásico) aquí, puede que lo encuentre en Aler tas o en
Reglas de aler tas .
3. Seleccione el comando Agregar una aler ta de métrica (clásica) y rellene los campos.
4. Asigne un nombre a la regla de alerta. Después, elija una descripción , que también aparecerá en los
correos electrónicos de notificación.
5. Seleccione la métrica que desea supervisar. Posteriormente, elija una condición y el valor de umbral de
la métrica. También debe elegir el período de la regla de métrica que se debe cumplir antes de que se
desencadene la alerta. Por ejemplo, si usa el período "En los últimos 5 minutos" y la alerta busca una CPU
por encima del 80 %, la alerta se desencadena cuando la CPU ha estado por encima del 80 % durante 5
minutos de manera uniforme. Una vez que se desencadena por primera vez, se vuelve a desencadenar
cuando la CPU se mantiene por debajo del 80 % durante 5 minutos. La medición de la métrica de CPU se
produce cada minuto.
6. Seleccione Enviar correo electrónico a propietarios... si desea que se envíe una notificación por
correo electrónico a los administradores y coadministradores cuando se active la alerta.
7. Si quiere enviar notificaciones a otras direcciones de correo electrónico cuando se active la alerta,
agréguelas en el campo Correos electrónicos adicionales del administrador . Separe las direcciones
de correo electrónico con punto y coma y procure que tengan el siguiente formato:
email@contoso.com;email2@contoso.com
8. Escriba un identificador URI válido en el campo Webhook si desea llamarlo cuando se active la alerta.
9. Si usa Azure Automation, puede seleccionar un runbook para que se ejecute cuando se active la alerta.
10. Seleccione Aceptar para crear la alerta.
En cuestión de minutos, se activa la alerta y se desencadena tal como se describió anteriormente.
Una vez que haya creado una alerta, puede seleccionarla y realizar alguna de las acciones siguientes:
Ver un gráfico que muestre el umbral de las métricas y los valores reales del día anterior.
Editar la alerta o eliminarla.
Deshabilitar la alerta, si desea dejar de recibir notificaciones de esa alerta de manera temporal, o
habilitarla si desea reanudar sus notificaciones.
Con la CLI de Azure

En las secciones anteriores se describía cómo crear, ver y administrar las reglas de alertas de métricas mediante
Azure Portal. En esta sección se describe cómo hacer lo mismo con la multiplataforma CLI de Azure. La forma
más rápida de comenzar a utilizar la CLI de Azure es a través de Azure Cloud Shell.
Obtener todas las reglas de alerta de métricas clásicas en un grupo de recursos
az monitor alert list --resource-group <group name>
Ver los detalles de una regla de alerta de métricas clásica específica
az monitor alert show --resource-group <group name> --name <alert name>
Crear una regla de alerta de métricas clásica
az monitor alert create --name <alert name> --resource-group <group name> \

--action email <email1 email2 ...> \
--action webhook <URI> \
--target <target object ID> \
--condition "<METRIC> {>,>=,<,<=} <THRESHOLD> {avg,min,max,total,last} ##h##m##s"
Eliminar una regla de alerta de métricas clásica
az monitor alert delete --name <alert name> --resource-group <group name>
Con PowerShell
NOTE
En esta sección se muestra cómo usar los comandos de PowerShell para crear, ver y administrar las alertas de
métricas clásicas. Los ejemplos de este artículo muestran cómo puede usar los cmdlets de Azure Monitor en las
alertas de métricas clásicas.
1. Si no lo ha hecho ya, configure PowerShell para que se ejecute en el equipo. Para más información,
consulte el artículo de instalación y configuración de PowerShell. También puede consultar toda la lista de
cmdlets de PowerShell de Azure Monitor en Azure Monitor Cmdlets (Cmdlets de Azure Monitor).
2. Primero, inicie sesión en la suscripción de Azure.
Connect-AzAccount
3. Verá una pantalla de inicio de sesión. Una vez que inicie sesión, se muestran el identificador
predeterminado de la suscripción, el identificador de inquilino y la cuenta. Todos los cmdlets de Azure
funcionan en el contexto de la suscripción predeterminada. Para ver la lista de suscripciones a las que
tiene acceso, use el siguiente comando:
Get-AzSubscription
4. Para cambiar el contexto de trabajo a una suscripción diferente, utilice el siguiente comando:
Set-AzContext -SubscriptionId <subscriptionid>
5. Puede obtener todas las reglas de alerta de métricas clásicas en un grupo de recursos:
Get-AzAlertRule -ResourceGroup montest
6. Puede ver los detalles de una regla de alerta de métricas clásica.
Get-AzAlertRule -Name simpletestCPU -ResourceGroup montest -DetailedOutput
7. Puede recuperar todas las reglas de alerta de un recurso de destino. Por ejemplo, todas las reglas de
alerta se establecen en una máquina virtual.
Get-AzAlertRule -ResourceGroup montest -TargetResourceId

/subscriptions/s1/resourceGroups/montest/providers/Microsoft.Compute/virtualMachines/testconfig
8. Ya no se pueden crear reglas de alertas mediante PowerShell. Para crear una regla de alerta tiene que usar
el nuevo comando Add-AzMetricAlertRule.
Pasos siguientes
Crear una alerta de métricas clásica con una plantilla de Resource Manager.
Cómo hacer que una alerta de métrica clásica notifique a un sistema que no es de Azure mediante un
webhook.
Creación de una alerta de métrica clásica con una
plantilla de Resource Manager
WARNING
En este artículo se describe cómo crear alertas de métrica clásicas más antiguas. Azure Monitor ahora es compatible con una
nueva experiencia de alertas y las más recientes alertas de métrica casi en tiempo real. Las alertas clásicas se retiran, aunque
siguen con un uso limitado para los recursos que aún no admiten las nuevas alertas.
En este artículo se describe cómo se puede utilizar una plantilla de Azure Resource Manager para configurar
alertas de métricas clásicas de Azure. Esto permite configurar automáticamente las alertas en los recursos cuando
se crean para asegurarse de que todos los recursos se supervisan correctamente.
Los pasos básicos son los siguientes:
1. Cree una plantilla como archivo JSON que describa cómo crear la alerta.
A continuación se describe cómo crear una plantilla de Resource Manager primero para una alerta solamente y,
después, para una alerta durante la creación de otro recurso.
Plantilla de Resource Manager para una alerta de métricas clásica

Microsoft.Insights/alertRules y rellene todas las propiedades relacionadas. A continuación se muestra una
plantilla que crea una regla de alertas.
{
"parameters": {
"alertName": {
"type": "string",
"metadata": {
"description": "Name of alert"
}
},
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"isEnabled": {
"type": "bool",
"metadata": {
"description": "Specifies whether alerts are enabled"
}
},
"resourceId": {
"type": "string",
"defaultValue": "",
"metadata": {
comparison."
}
},
"metricName": {
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"operator": {
"type": "string",
"allowedValues": [
"GreaterThan",
"LessThan",
"LessThanOrEqual"
],
"metadata": {
}
},
"threshold": {
"type": "string",
"defaultValue": "",
"metadata": {
}
},
"aggregation": {
"type": "string",
"allowedValues": [
"Average",
"Last",
"Maximum",
"Minimum",
"Total"
],
"metadata": {
}
},
"windowSize": {
"type": "string",
"metadata": {
between five minutes and one day. ISO 8601 duration format."
}
},
"sendToServiceOwners": {
"type": "bool",
"metadata": {
"description": "Specifies whether alerts are sent to service owners"
}
},
"customEmailAddresses": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "Comma-delimited email addresses where the alerts are also sent"
}
},
"webhookUrl": {
"webhookUrl": {
"type": "string",
"defaultValue": "",
"metadata": {
"description": "URL of a webhook that will receive an HTTP POST when the alert activates."
}
}
},
"variables": {
"customEmails": "[split(parameters('customEmailAddresses'), ',')]"
},
"resources": [
{
"type": "Microsoft.Insights/alertRules",
"apiVersion": "2016-03-01",
"properties": {
"isEnabled": "[parameters('isEnabled')]",
"condition": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
"dataSource": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
"resourceUri": "[parameters('resourceId')]",
"metricName": "[parameters('metricName')]"
},
"threshold": "[parameters('threshold')]",
"timeAggregation": "[parameters('aggregation')]"
},
"actions": [
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
"sendToServiceOwners": "[parameters('sendToServiceOwners')]",
"customEmails": "[variables('customEmails')]"
},
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleWebhookAction",
"serviceUri": "[parameters('webhookUrl')]",
"properties": {}
}
]
}
}
]
}
Plantilla de Resource Manager para un recurso con una alerta de

métricas clásica
Una alerta en una plantilla de Resource Manager suele ser más útil al crear una alerta mientras se crea un recurso.
Por ejemplo, desea asegurarse de que se configura una regla "CPU % > 80" cada vez que implementa una
máquina virtual. Para ello, agregue la regla de alerta como un recurso en la matriz de recursos para la plantilla de
máquina virtual y agregue también una dependencia utilizando la propiedad dependsOn para el identificador de
recurso de máquina virtual. A continuación se presenta un ejemplo completo que crea una máquina virtual
Windows y agrega una alerta que notifica a los administradores de la suscripción cuando el uso de CPU supera el
80 %.
{
"parameters": {
"newStorageAccountName": {
"type": "string",
"metadata": {
"Description": "The name of the storage account where the VM disk is stored."
}
},
"adminUsername": {
"type": "string",
"metadata": {
"Description": "The name of the administrator account on the VM."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"Description": "The administrator account password on the VM."
}
},
"dnsNameForPublicIP": {
"type": "string",
"metadata": {
"Description": "The name of the public IP address used to access the VM."
}
}
},
"variables": {
"location": "Central US",
"imagePublisher": "MicrosoftWindowsServer",
"imageOffer": "WindowsServer",
"windowsOSVersion": "2012-R2-Datacenter",
"OSDiskName": "osdisk1",
"nicName": "nc1",
"addressPrefix": "10.0.0.0/16",
"subnetName": "sn1",
"subnetPrefix": "10.0.0.0/24",
"storageAccountType": "Standard_LRS",
"publicIPAddressName": "ip1",
"publicIPAddressType": "Dynamic",
"vmStorageAccountContainerName": "vhds",
"vmName": "vm1",
"vmSize": "Standard_A0",
"virtualNetworkName": "vn1",
"vnetID": "[resourceId('Microsoft.Network/virtualNetworks',variables('virtualNetworkName'))]",
"subnetRef": "[concat(variables('vnetID'),'/subnets/',variables('subnetName'))]",
"vmID":"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]",
"alertName": "highCPUOnVM",
"alertDescription":"CPU is over 80%",
"alertIsEnabled": true,
"resourceId": "",
"threshold": "80",
"aggregation": "Average",
"customEmails": "",
"sendToServiceOwners": true,
"webhookUrl": "http://testwebhook.test"
},
"resources": [
{
"name": "[parameters('newStorageAccountName')]",
"apiVersion": "2015-06-15",
"location": "[variables('location')]",
"properties": {
"accountType": "[variables('storageAccountType')]"
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('publicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "[variables('publicIPAddressType')]",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsNameForPublicIP')]"
}
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]"
}
}
]
}
},
{
"apiVersion": "2016-03-30",
"type": "Microsoft.Network/networkInterfaces",
"name": "[variables('nicName')]",
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "
[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"apiVersion": "2016-03-30",
"name": "[variables('vmName')]",
"dependsOn": [
"[concat('Microsoft.Storage/storageAccounts/', parameters('newStorageAccountName'))]",
"[concat('Microsoft.Storage/storageAccounts/', parameters('newStorageAccountName'))]",
"[concat('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[variables('vmSize')]"
},
"osProfile": {
"computername": "[variables('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"publisher": "[variables('imagePublisher')]",
"offer": "[variables('imageOffer')]",
"sku": "[variables('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "
[concat('http://',parameters('newStorageAccountName'),'.blob.core.windows.net/',variables('vmStorageAccountCon
tainerName'),'/',variables('OSDiskName'),'.vhd')]"
},
"caching": "ReadWrite",
"createOption": "FromImage"
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]"
}
]
}
}
},
{
"type": "Microsoft.Insights/alertRules",
"name": "[variables('alertName')]",
"dependsOn": [
"[variables('vmID')]"
],
"apiVersion": "2016-03-01",
"properties": {
"name": "[variables('alertName')]",
"description": "variables('alertDescription')",
"isEnabled": "[variables('alertIsEnabled')]",
"condition": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition",
"dataSource": {
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleMetricDataSource",
"resourceUri": "[variables('vmID')]",
"metricName": "[variables('metricName')]"
},
"operator": "[variables('operator')]",
"threshold": "[variables('threshold')]",
"windowSize": "[variables('windowSize')]",
"timeAggregation": "[variables('aggregation')]"
},
"actions": [
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleEmailAction",
"sendToServiceOwners": "[variables('sendToServiceOwners')]",
"customEmails": "[variables('customEmails')]"
},
{
{
"odata.type": "Microsoft.Azure.Management.Insights.Models.RuleWebhookAction",
"serviceUri": "[variables('webhookUrl')]",
"properties": {}
}
]
}
}
]
}
Pasos siguientes
Más información sobre alertas
Agregue la Configuración de diagnóstico a la plantilla de Resource Manager
Para conocer las propiedades y la sintaxis de JSON, consulte la referencia de la plantilla
Microsoft.Insights/alertrules.
Llamada a un webhook con una alerta de métrica
clásica en Azure Monitor
WARNING
En este artículo se describe cómo usar las alertas de métrica clásicas más antiguas. Azure Monitor ahora es compatible con
Puede usar los webhooks para redirigir una notificación de alerta de Azure a otros sistemas para su
procesamiento posterior o acciones personalizadas. Puede usar un webhook en una alerta para redirigirla a
servicios que envían mensajes SMS, para registrar errores, para notificar a un equipo mediante servicios de chat
y mensajería o llevar a cabo otras acciones.
En este artículo se describe cómo establecer un webhook en una alerta de métrica de Azure. También muestra el
aspecto de la carga útil para HTTP POST a un webhook. Para obtener información sobre la configuración y el
esquema de una alerta de registro de actividad de Azure (alerta de eventos), consulte Llamada a un webhook
cuando se activan alertas del registro de actividades de Azure.
Las alertas de Azure usan HTTP POST para enviar el contenido de la alerta en formato JSON a un URI de
webhook que se proporciona al crear la alerta. El esquema se define más adelante en este artículo. Este URI debe
ser un punto de conexión HTTP o HTTPS válido. Azure envía una entrada por cada solicitud cuando se activa una
alerta.
Configuración de webhooks mediante Azure Portal

Puede agregar o actualizar el URI de webhook, en Azure Portal, vaya a Create/Update Aler ts (Crear/Actualizar
alertas).
También puede configurar una alerta para enviarla a un URI de webhook mediante los cmdlets de Azure
PowerShell, la CLI multiplataforma o la API de REST de Azure Monitor.
Autenticación del webhook

El webhook puede autenticarse mediante una autorización basada en token. El URI del webhook se guarda con
un identificador de token. Por ejemplo:
https://mysamplealert/webcallback?tokenid=sometokenid&someparameter=somevalue
Esquema de carga
La operación POST contiene el siguiente esquema y carga útil de JSON para todas las alertas basadas en
métricas:
{
"context": {
"timestamp": "2015-08-14T22:26:41.9975398Z",
"id": "/subscriptions/s1/resourceGroups/useast/providers/microsoft.insights/alertrules/ruleName1",
"name": "ruleName1",
"description": "some description",
"conditionType": "Metric",
"condition": {
"metricName": "Requests",
"metricUnit": "Count",
"metricValue": "10",
"threshold": "10",
"windowSize": "15",
"operator": "GreaterThanOrEqual"
},
"subscriptionId": "s1",
"resourceGroupName": "useast",
"resourceName": "mysite1",
"resourceType": "microsoft.foo/sites",
"resourceId": "/subscriptions/s1/resourceGroups/useast/providers/microsoft.foo/sites/mysite1",
"resourceRegion": "centralus",
"portalLink":
"https://portal.azure.com/#resource/subscriptions/s1/resourceGroups/useast/providers/microsoft.foo/sites/mys
ite1"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
C O N JUN TO F IJO DE
CAMPO M A N DATO RY VA LO RES N OTA S
status Y Activado, Resuelto Estado de la alerta en

función de las condiciones
que haya establecido.
context Y Contexto de la alerta
timestamp Y La hora en la que se

desencadenó la alerta.
id Y Cada regla de alerta tiene

un identificador único.
name Y Nombre de la alerta
description Y Descripción de la alerta.

conditionType Y Métrica, Evento Se admiten dos tipos de

alertas: métrica y evento.
Las alertas de métrica se
basan en una condición de
métrica. Las alertas de
evento se basan en un
evento del registro de
actividad. Use este valor
para comprobar si la alerta
está basada en una métrica
o en un evento.
condición Y Los campos específicos que

buscar en función del
campo conditionType .
metricName Para alertas de métricas El nombre de la métrica que

define qué supervisa la
regla.
metricUnit Para alertas de métricas Bytes, BytesPerSecond, La unidad permitida en la

Count, CountPerSecond, métrica. Consulte Valores
Percent, Seconds permitidos.
metricValue Para alertas de métricas Valor real de la métrica que

causó la alerta
threshold Para alertas de métricas Valor de umbral en el que se

activa la alerta
windowSize Para alertas de métricas El período de tiempo que se

usa para supervisar la
actividad de la alerta según
el umbral. El valor debe
estar comprendido entre 5
minutos y 1 día. El valor
debe tener el formato de
duración ISO 8601.
timeAggregation Para alertas de métricas Average, Last, Maximum, La manera en que se

Minimum, None, Total recopilan los datos se
debería combinar con el
tiempo. El valor
predeterminado es Average.
Consulte Valores permitidos.
operator Para alertas de métricas Operador usado para

comparar los datos de
métrica actuales con el
umbral establecido.
subscriptionId Y El identificador de la
suscripción de Azure.
resourceGroupName Y Nombre del grupo de

recursos del recurso
afectado.
resourceName Y Nombre del recurso

afectado.
resourceType Y Tipo del recurso afectado.
resourceId Y Identificador de recurso del

recurso afectado.
resourceRegion Y Región o ubicación del

recurso afectado.
portalLink Y Vínculo directo a la página

de resumen de recursos del
portal.
properties N Opcional Conjunto de pares

clave/valor que incluye
detalles sobre el evento. Por
ejemplo,
Dictionary<String,
String>
. El campo de propiedades
es opcional. En un flujo de
trabajo basado en una
aplicación lógica o una
interfaz de usuario
personalizada, los usuarios
pueden especificar pares
clave/valores que se pueden
pasar con la carga útil. Una
forma alternativa para pasar
propiedades personalizadas
a la webhook es mediante el
propio URI de webhook
(como parámetros de
consulta).
NOTE
Solo se puede establecer el campo de propiedades mediante la API de REST de Azure Monitor.
Pasos siguientes
Aprenda más sobre los webhooks y las alertas de Azure en el vídeo Integración de las alertas de Azure con
PagerDuty.
Obtenga información sobre cómo ejecutar scripts de Azure Automation (Runbooks) en alertas de Azure.
Aprenda a usar una aplicación lógica para enviar un mensaje SMS a través de Twilio desde una alerta de
Azure.
Sepa cómo usar una aplicación lógica para enviar un mensaje de Slack desde una alerta de Azure.
Obtenga información sobre cómo usar una aplicación lógica para enviar un mensaje a una cola de Azure
desde una alerta de Azure.
Application Insights es una característica de Azure Monitor que es un servicio de

Application Performance Management (APM) extensible para desarrolladores y
profesionales de DevOps. Úselo para supervisar las aplicaciones en directo. Detectará
automáticamente anomalías en el rendimiento e incluye eficaces herramientas de
análisis que le ayudan a diagnosticar problemas y a saber lo que hacen realmente los
usuarios con la aplicación. Está diseñado para ayudarle a mejorar continuamente el
rendimiento y la facilidad de uso. Funciona con diversas aplicaciones y en una amplia
variedad de plataformas, como .NET, Node.js, Java y Python, hospedadas en el entorno
local, de forma híbrida o en cualquier nube pública. Se integra con el proceso de
DevOps y tiene puntos de conexión a numerosas herramientas de desarrollo. Puede
supervisar y analizar la telemetría de aplicaciones móviles mediante la integración con
Visual Studio App Center.
¿Cómo funciona Application Insights?

Instale un paquete de instrumentación pequeño (SDK) en la aplicación o habilite
Application Insights mediante el agente de Application Insights cuando se admita. La
instrumentación supervisa la aplicación y dirige los datos de telemetría a un recurso de
Azure Application Insights mediante un GUID único al que se hace referencia como una
clave de instrumentación.
No solo puede instrumentar la aplicación de servicio web, sino también todos los
componentes en segundo plano y JavaScript en las propias páginas web. La aplicación y
sus componentes se pueden ejecutar en cualquier lugar; no tienen que estar
hospedados en Azure.
Además, puede obtener la telemetría de los entornos del host, como pueden ser
contadores de rendimiento, diagnósticos de Azure o registros de Docker. También puede
configurar pruebas web que envíen periódicamente solicitudes sintéticas al servicio
web.
Todos estos flujos de telemetría están integrados en Azure Monitor. En Azure Portal,
puede aplicar versátiles herramientas de análisis y búsqueda a los datos sin procesar.
¿Cuál es la sobrecarga?
El impacto sobre el rendimiento de la aplicación es pequeño. Las llamadas de
seguimiento no suponen ningún tipo de bloqueo y se agrupan por lotes y se envían en
un subproceso aparte.
¿Qué supervisa Application Insights?

Application Insights está dirigido al equipo de desarrollo y sirve ayudarle a conocer el
rendimiento de una aplicación y cómo se utiliza. Supervisa:
Tasas de solicitud, tiempos de respuesta y tasas de error - Averigüe qué
páginas que son las más conocidas, en qué momento del día y dónde están los
usuarios. Vea qué páginas presentan mejor rendimiento. Si los tiempos de respuesta
y las tasas de error aumentan cuando hay más solicitudes, quizás tiene un problema
de recursos.
Tasas de dependencia, tiempos de respuesta y tasa de error - Averigüe si los
servicios externos le ralentizan.
Excepciones : - Analice las estadísticas agregadas o seleccione instancias concretas y
profundice en el seguimiento de la pila y las solicitudes relacionadas. Se notifican
tanto las excepciones de servidor como las de explorador.
Vistas de página y rendimiento de carga - Notificados por los exploradores de
los usuarios.
Llamadas AJAX desde páginas web - Tasas, tiempos de respuesta y tasas de error.
Número de usuarios y sesiones .
Contadores de rendimiento de las máquinas de servidor de Windows o Linux,
como CPU, memoria y uso de la red.
Diagnóstico de host de Docker o Azure.
Registros de seguimiento de diagnóstico de la aplicación - De esta forma puede
correlacionar eventos de seguimiento con las solicitudes.
Métricas y eventos personalizados que usted mismo escribe en el código de
cliente o servidor para realizar un seguimiento de eventos empresariales, como
artículos vendidos o partidas ganadas.
¿Dónde veo la telemetría?

Hay muchas formas de explorar los datos. Consulte estos artículos:
Detección inteligente y aler tas manuales

Las alertas automáticas configuradas se
adaptan a los patrones normales de telemetría
de la aplicación y se desencadenan cuando
algo no responde al patrón habitual. También
puede establecer alertas sobre niveles
concretos de métricas estándares o
personalizadas.
Mapa de aplicación
Explore los componentes de la aplicación, con
alertas y métricas clave.
Inspeccione los perfiles de ejecución de
solicitudes muestreadas.
Análisis de uso
Analice la segmentación y la retención de
usuarios.
Búsqueda de diagnóstico para datos de

instancia
Busque y filtre eventos como solicitudes,
excepciones, llamadas de dependencia,
seguimientos de registro y vistas de páginas.
Explorador de métricas para datos

agregados
Explore, filtre y segmente datos agregados,
como los índices de solicitudes, errores y
excepciones; los tiempos de respuesta y los
tiempos de carga de página.
Paneles
Combine datos de varios recursos y
compártalos con otros. Ideal para aplicaciones
de varios componentes y para la presentación
continua en la sala de reuniones.
Secuencia de métricas en directo

Al implementar una nueva compilación, fíjese
en estos indicadores de rendimiento casi en
tiempo real para asegurarse de que todo
funciona según lo esperado.
Análisis
Responda preguntas complejas acerca del uso
y el rendimiento de su aplicación mediante este
eficaz lenguaje de consulta.
Visual Studio
Vea los datos de rendimiento en el código.
Vaya al código desde los seguimientos de la
pila.
Depure instantáneas muestreadas desde
operaciones en directo, con valores de
parámetro.
Power BI
Integre métricas de uso con otra inteligencia
empresarial.
API DE REST
Escriba código para ejecutar consultas sobre las
métricas y los datos sin procesar.
Expor tación continua

Exportación masiva de datos sin procesar al
almacenamiento tan pronto como llegan.
¿Cómo uso Application Insights?

Supervisión
Instale Application Insights en la aplicación web, configure las pruebas web de
disponibilidad y:
Revise el panel de aplicación predeterminado para que su equipo no pierda de vista
la carga, la capacidad de respuesta y el rendimiento de las dependencias, las cargas
de páginas y las llamadas AJAX.
Detecte cuáles son las solicitudes más lentas y con mayor número de errores.
Vea Live Stream cuando implemente una versión nueva, con el fin de conocer
inmediatamente la existencia de cualquier degradación.
Detección y diagnóstico
Cuando reciba una alerta o detecte un problema:
Evalúe cuántos usuarios se ven afectados.
Correlacione los errores con las excepciones, las llamadas de dependencia y los
seguimientos.
Examine el generador de perfiles, las instantáneas, los volcados de pila y los registros
de seguimiento.
Compilación, medición y aprendizaje
Mida la eficacia de cada característica nueva que implemente.
Planee la medición de la forma en que los clientes utilizan las nuevas características
empresariales y de experiencia de usuario.
Escriba datos de telemetría personalizados en el código.
Base el siguiente ciclo de desarrollo en pruebas contundentes de la telemetría.
Introducción
Application Insights es uno de los muchos servicios hospedados en Microsoft Azure y
los datos de telemetría se envían ahí para analizarlos y mostrarlos. Por tanto, antes de
nada, se necesita una suscripción a Microsoft Azure. El registro es gratuito y, si elige el
plan de precios básico de Application Insights, no habrá cargo alguno hasta que la
aplicación tenga un uso considerable. Si la organización ya tiene una suscripción, puede
agregarle su cuenta de Microsoft.
Hay varias formas de empezar. Comience con la que más se ajuste a sus necesidades.
Puede agregar los demás posteriormente.
En tiempo de ejecución: instrumente su aplicación web en el ser vidor. Ideal
para las aplicaciones ya implementadas. Evita toda actualización del código.
Aplicaciones ASP.NET o ASP.NET Core hospedadas en Azure Web
Apps
Aplicaciones ASP.NET hospedadas en IIS en una máquina vir tual de
Azure o un conjunto de escalado de máquinas vir tuales de Azure
Aplicaciones ASP.NET hospedadas en una máquina vir tual en el
entorno local de IIS
En tiempo de desarrollo: agregue Application Insights al código. Le permite
personalizar la recopilación de telemetría personalizada y enviar telemetría adicional.
Aplicación ASP.NET Core
Aplicaciones de consola .NET
Java
Node.js
Python
Otras plataformas
Instrumente sus páginas web para la vista de la página, AJAX y otros datos de
telemetría del lado cliente.
Analice el uso de aplicaciones móviles mediante la integración con Visual
Studio App Center.
Pruebas de disponibilidad : haga ping a su sitio web de manera regular desde
nuestros servidores.
Pasos siguientes
Comience en el tiempo de ejecución con:
Aplicaciones hospedadas en IIS en máquina virtual de Azure y conjunto de escalado
de máquinas virtuales de Azure
Servidor IIS
Azure Web Apps
Comience en el tiempo de desarrollo con:
ASP.NET
ASP.NET Core
Java
Node.js
Python
Soporte y comentarios
Preguntas y problemas:
Página de preguntas y respuestas de Microsoft
Stackoverflow
Sus sugerencias:
UserVoice
Blog:
Blog de Application Insights
Azure Monitor.
General
para Azure Monitor.
Monitor.
Registros
en Azure Monitor.
información.
sus tipos.
Métricas
de métricas?
Alertas
tipos de alertas:
Agentes
Analytics.
de datos enviada:
WireData
la red.
Log Analytics?
recurso.
Visualizaciones
Aplicación .NET
virtuales de Azure
SharePoint
Otras plataformas
¿Es gratis?
limitar los gastos.
¿Cuánto cuesta?
ai.js
Web.config
packages.config
Resource Manager?
Más información.
Solicitudes HTTP
Log Analytics
Logstash

Podría:
servidor proxy.

automáticamente)
rendimiento
web

de servidor
producido.
Automation
proxy.
...
<TelemetryModules>
<Add
t>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
</TelemetryChannel>
...
...
NOTE

<system.net>
<defaultProxy>
</defaultProxy>
</system.net>

soluciones:

sencilla.
contenedores.
Kubelet
Opción 1
combinaciones.

ContainerLog
ContainerData
Opción 2
NOTE

clústeres.
Helm?
contenedores.
}));
los registros:
21Vianet.

compatibles.
Insights.
agregado?
subredes?
experiencia.
protocolos.
Pasos siguientes
adicionales.
Log Analytics
Application Insights para aplicaciones de ASP.NET
Core
En este artículo se describe cómo habilitar Application Insights para una aplicación de ASP.NET Core. Al
completar las instrucciones de este artículo, Application Insights recopilará solicitudes, dependencias,
excepciones, contadores de rendimiento, latidos y registros de la aplicación de ASP.NET Core.
El ejemplo que vamos a usar aquí es una aplicación de MVC que tiene como destino netcoreapp3.0 . Estas
instrucciones se pueden aplicar a todas las aplicaciones de ASP.NET Core. Si usa el Servicio de trabajo, siga
las instrucciones que encontrará aquí.
Escenarios admitidos
El SDK de Application Insights para ASP.NET Core puede supervisar sus aplicaciones, independientemente
de dónde y cómo se ejecuten. Si la aplicación se está ejecutando y tiene conectividad de red a Azure, se
pueden recopilar datos de telemetría. La supervisión de Application Insights se admite siempre y cuando
.NET Core sea compatible. Información de compatibilidad:
Sistema operativo : Windows, Linux o Mac.
Método de hospedaje : en el proceso o fuera del proceso.
Método de implementación : Marco dependiente o independiente.
Ser vidor web : IIS (Internet Information Server) o Kestrel.
Plataforma de hospedaje : característica Web Apps de Azure App Service, VM de Azure, Docker, Azure
Kubernetes Service (AKS), etc.
Versión del entorno de ejecución de .NET Core : 1.XX, 2.XX o 3.XX
IDE : Visual Studio, VS Code o línea de comandos.
NOTE
ASP.NET Core 3.X requiere Application Insights 2.8.0 o posterior.
Requisitos previos
Una aplicación de ASP.NET Core en funcionamiento. Si necesita crear una aplicación de ASP .NET Core,
siga este tutorial de ASP.NET Core.
Una clave de instrumentación de Application Insights válida. Esta clave es necesaria para enviar los
datos de telemetría a Application Insights. Si necesita crear un nuevo recurso de Application Insights
para obtener un clave de instrumentación, consulte Creación de recursos en Application Insights.
Habilitación de la telemetría de Application Insights del lado

servidor (Visual Studio)
En en caso de Visual Studio para Mac, use las instrucciones manuales. Solo la versión de Windows de Visual
Studio admite este procedimiento.
1. Abra el proyecto en Visual Studio.
TIP
Si quiere, puede configurar el control de código fuente para el proyecto para hacer un seguimiento de los
cambios que realiza Application Insights. Para habilitar el control de código fuente, seleccione Archivo >
Add to Source Control (Agregar al control de código fuente).
2. Seleccione Proyecto > Agregar Telemetría de Application Insights .

3. Seleccione Comenzar . En función de la versión de Visual Studio, el texto puede variar. Algunas
versiones anteriores usan un botón Comenzar gratis .
4. Seleccione su suscripción. A continuación, seleccione Recurso > Registrar .
5. Después de agregar Application Insights al proyecto, confirme que está usando la versión estable
más reciente del SDK. Vaya a Proyecto > Administrar paquetes NuGet >
Microsoft.ApplicationInsights.AspNetCore . Si lo necesita, elija Actualizar .
6. Si ha seguido la sugerencia opcional y agregó el proyecto al control de código fuente, vaya a View
(Ver) > Team Explorer > Cambios . A continuación, seleccione cada archivo para ver una vista de
las diferencias de los cambios realizados por la telemetría de Application Insights.
Habilitación de la telemetría de Application Insights del lado

servidor (sin Visual Studio)
1. Instale el SDK de Application Insights desde el paquete de NuGet para ASP.NET Core. Se recomienda
que use siempre la versión estable más reciente. Consulte las notas de la versión completa para el
SDK en el repositorio de GitHub de código abierto.
En el siguiente ejemplo de código se muestran los cambios que se agregarán al archivo .csproj del
proyecto.
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.13.1" />
</ItemGroup>
2. Agregue services.AddApplicationInsightsTelemetry(); al método ConfigureServices() en su clase

Startup , como en este ejemplo:
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// The following line enables Application Insights telemetry collection.
services.AddApplicationInsightsTelemetry();
// This code adds other services for your application.

services.AddMvc();
}
3. Comprobar la clave de instrumentación.

Aunque puede proporcionar la clave de instrumentación como un argumento a
AddApplicationInsightsTelemetry , se recomienda que especifique la clave de instrumentación en la
configuración. En el siguiente ejemplo de código se muestra cómo especificar una clave de
instrumentación en appsettings.json . Asegúrese de que appsettings.json se copia en la carpeta
raíz de la aplicación durante la publicación.
{
"ApplicationInsights": {
"InstrumentationKey": "putinstrumentationkeyhere"
},
"Logging": {
"LogLevel": {
"Default": "Warning"
}
}
}
Como alternativa, puede especificar la clave de instrumentación en cualquiera de las siguientes

variables de entorno:
APPINSIGHTS_INSTRUMENTATIONKEY
ApplicationInsights:InstrumentationKey
Por ejemplo:
SET ApplicationInsights:InstrumentationKey=putinstrumentationkeyhere
SET APPINSIGHTS_INSTRUMENTATIONKEY=putinstrumentationkeyhere
APPINSIGHTS_INSTRUMENTATIONKEY se utiliza normalmente en Azure Web Apps, pero también se

puede usar en todos los lugares donde se admita este SDK. (Si va a realizar la supervisión de
aplicaciones web sin código, este formato es necesario si no está usando cadenas de
conexión).
En lugar de establecer las claves de instrumentación, ahora también puede utilizar Cadenas de
conexión.
NOTE
Una clave de instrumentación especificada en el código prevalece frente a la variable del entorno
APPINSIGHTS_INSTRUMENTATIONKEY , que prevalece sobre otras opciones.
Secretos de usuario y otros proveedores de configuración

Si desea almacenar la clave de instrumentación en los secretos de usuario de ASP.NET Core o recuperarla
de otro proveedor de configuración, puede usar la sobrecarga con un parámetro
Microsoft.Extensions.Configuration.IConfiguration . Por ejemplo,
services.AddApplicationInsightsTelemetry(Configuration); .
Ejecución de la aplicación
Ejecute la aplicación y realícele solicitudes. Ahora, la telemetría debería fluir hacia Application Insights. El
SDK de Application Insights recopila automáticamente las solicitudes web entrantes en la aplicación, junto
con la telemetría siguiente.
Live Metrics
Live Metrics se puede usar para comprobar rápidamente si la supervisión de Application Insights está
configurada correctamente. Aunque la telemetría puede tardar unos minutos en aparecer en el portal y en
el análisis, Live Metrics mostraría el uso de la CPU del proceso en ejecución casi en tiempo real. También
puede mostrar otros tipos de telemetría, como las solicitudes, las dependencias, los seguimientos, etc.
Registros de ILogger
Los registros emitidos a través de ILogger de gravedad Warning o mayor se capturan automáticamente.
Siga la documentación de ILogger para personalizar los niveles de registro que captura Application
Insights.
Dependencias
La recopilación de dependencias está habilitada de manera predeterminada. En este artículo se explican las
dependencias que se recopilan automáticamente; también contiene pasos para realizar el seguimiento
manual.
La compatibilidad con los contadores de rendimiento en ASP.Net Core es limitada:
Las versiones 2.4.1 y posteriores del SDK recopilan contadores de rendimiento si la aplicación se ejecuta
en Azure Web Apps (Windows).
en Windows y tiene como destino NETSTANDARD2.0 o una versión posterior.
Para las aplicaciones que tienen como destino .NET Framework, todas las versiones del SDK admiten
contadores de rendimiento.
Las versiones 2.8.0 y posteriores del SDK admiten el contador de CPU/memoria de Linux. No se admite
ningún otro contador en Linux. La manera recomendada de obtener contadores del sistema en Linux (y
otros entornos que no son Windows) es mediante EventCounters.
EventCounter
EventCounterCollectionModule está habilitado de forma predeterminada y recopilará un conjunto
predeterminado de contadores de las aplicaciones de .NET Core 3.X. En el tutorial de EventCounter se
muestra el conjunto de contadores recopilado de manera predeterminada. También incluye instrucciones
sobre la personalización de la lista.
Habilitación de la telemetría del lado cliente para aplicaciones web

Los pasos anteriores son suficientes para ayudarle a empezar a recopilar datos de telemetría del lado
servidor. Si la aplicación tiene componentes del lado cliente, siga estos pasos para comenzar a recopilar
telemetría de uso.
1. En _ViewImports.cshtml , agregue la inserción:
@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet

2. En _Layout.cshtml , inserte HtmlHelper al final de la sección <head> pero antes de cualquier otro
script. Si quiere informar de cualquier telemetría de JavaScript desde la página, insértela después de
este fragmento de código:
@Html.Raw(JavaScriptSnippet.FullScript)
</head>
Como alternativa al uso de FullScript , ScriptBody está disponible a partir del SDK de la versión 2.14.
Úselo si necesita controlar la etiqueta <script> para establecer una directiva de seguridad de contenido:
<script> // apply custom changes to this script tag.

@Html.Raw(JavaScriptSnippet.ScriptBody)
</script>
Los nombres del archivo .cshtml mencionados anteriormente son de una plantilla de la aplicación de
MVC predeterminada. En última instancia, si desea habilitar correctamente la supervisión del lado cliente
para la aplicación, el fragmento de código de JavaScript debe aparecer en la sección <head> de cada
página de la aplicación que quiere supervisar. Puede lograr este objetivo para esta plantilla de la aplicación
al agregar el fragmento de código de JavaScript a _Layout.cshtml .
Si el proyecto no incluye _Layout.cshtml , aún puede agregar la supervisión del lado cliente. Puede hacerlo
agregando el fragmento de código de JavaScript a un archivo equivalente que controle el objeto <head> de
todas las páginas de la aplicación. O bien, puede agregar el fragmento de código en varias páginas, pero
esta solución es difícil de mantener y no se recomienda.

Puede personalizar el SDK de Application Insights para ASP.NET Core para cambiar la configuración
predeterminada. Es posible que los usuarios de los SDK de Application Insights ASP.NET estén
familiarizados con el cambio de configuración mediante el uso de ApplicationInsights.config o
modificando TelemetryConfiguration.Active . La configuración de ASP.NET Core se cambia de forma
diferente. Agregue el SDK de ASP.NET Core a la aplicación y configúrelo mediante el uso de la inserción de
dependencias integradas de ASP.NET Core. Realice casi todos los cambios de configuración en el método
ConfigureServices() de su clase Startup.cs , a menos que se indique lo contrario. Para más información,
consulte las siguientes secciones.
NOTE
En las aplicaciones de ASP.NET Core, no se admite cambiar la configuración modificando
TelemetryConfiguration.Active .
Uso de ApplicationInsightsServiceOptions
Puede modificar algunos ajustes de configuración comunes pasando de ApplicationInsightsServiceOptions
a AddApplicationInsightsTelemetry , como se muestra en este ejemplo:
{
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions aiOptions
= new
Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();
// Disables adaptive sampling.
aiOptions.EnableAdaptiveSampling = false;
// Disables QuickPulse (Live Metrics stream).

aiOptions.EnableQuickPulseMetricStream = false;
services.AddApplicationInsightsTelemetry(aiOptions);
}
Lista completa de valores de ApplicationInsightsServiceOptions
C O N F IGURA C IÓ N DESC RIP C IÓ N VA LO R P REDET ERM IN A DO
EnablePerformanceCounterCollection Habilitar o deshabilitar true

Module PerformanceCounterCollectionModule
EnableRequestTrackingTelemetryMod Habilitar o deshabilitar true

ule RequestTrackingTelemetryModule
EnableEventCounterCollectionModul Habilitar o deshabilitar true

e EventCounterCollectionModule
EnableDependencyTrackingTelemetry Habilitar o deshabilitar true

Module DependencyTrackingTelemetryModule
EnableAppServicesHeartbeatTelemetr Habilitar o deshabilitar true

yModule AppServicesHeartbeatTelemetryModule
EnableAzureInstanceMetadataTeleme Habilitar o deshabilitar true

tryModule AzureInstanceMetadataTelemetryModule
EnableQuickPulseMetricStream Habilitar o deshabilitar la true

característica LiveMetrics
EnableAdaptiveSampling Habilitar o deshabilitar el muestreo true

adaptable
EnableHeartbeat Habilitar o deshabilitar la true

característica de latidos, que envía
periódicamente (cada 15 minutos de
forma predeterminada) una métrica
personalizada denominada
"HeartBeatState" con información
sobre el entorno de ejecución; por
ejemplo, la versión de .NET,
información del entorno de Azure, si
procede, etc.
AddAutoCollectedMetricExtractor Habilitar o deshabilitar el extractor de true

AutoCollectedMetrics, que es un
elemento TelemetryProcessor que
envía métricas previamente
agregadas sobre las solicitudes o
dependencias antes de que tenga
lugar el muestreo.
RequestCollectionOptions.TrackExcep Habilitar o deshabilitar los informes false en NETSTANDARD2.0 (porque

tions de seguimiento de excepciones no se realiza un seguimiento de las
controladas por el módulo de excepciones con
recopilación de solicitudes. ApplicationInsightsLoggerProvider);
en caso contrario, true.
Consulte los valores configurables en ApplicationInsightsServiceOptions para obtener la lista más

actualizada.
muestreo
El SDK de Application Insights SDK para ASP.NET Core admite el muestreo adaptable y el de tipo fijo. El
muestreo adaptable está habilitado de forma predeterminada.
Para obtener más información, consulte Configuración del muestreo adaptable para aplicaciones ASP.NET
Core.
Adición de TelemetryInitializers
Use inicializadores de telemetría cuando quiera enriquecer la telemetría con información adicional.
Agregue cualquier nuevo objeto TelemetryInitializer al contenedor DependencyInjection tal como se
muestra en el código siguiente. El SDK recoge automáticamente cualquier objeto TelemetryInitializer que
se agregue al contenedor DependencyInjection .

{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
}
Eliminación de Telemetryinitializer
Los inicializadores de telemetría están presentes de forma predeterminada. Para quitar todos los
inicializadores de telemetría o solo algunos específicos, use el siguiente código de ejemplo después de
llamar a AddApplicationInsightsTelemetry() .
{
// Remove a specific built-in telemetry initializer

var tiToRemove = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType ==
typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
services.Remove(tiToRemove);
}
// Remove all initializers

// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
services.RemoveAll(typeof(ITelemetryInitializer));
}
Adición de procesadores de telemetría

Puede agregar procesadores de telemetría personalizados a TelemetryConfiguration mediante el método
de extensión AddApplicationInsightsTelemetryProcessor en IServiceCollection . Los procesadores de
telemetría se usan en escenarios de filtrado avanzado. Use el ejemplo siguiente.

{
// ...
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
// If you have more processors:

services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Configuración o eliminación de objetos TelemetryModules predeterminados

Application Insights usa módulos de telemetría para recopilar automáticamente información de telemetría
útil sobre cargas de trabajo específicas sin necesidad de ninguna configuración adicional.
Los siguientes módulos de recopilación automática están habilitados de forma predeterminada. Estos
módulos son responsables de recopilar automáticamente datos de telemetría. Puede deshabilitarlos o
configurarlos para modificar su comportamiento predeterminado.
RequestTrackingTelemetryModule : recopila información de RequestTelemetry de las solicitudes web
entrantes.
DependencyTrackingTelemetryModule : recopila información de DependencyTelemetry de llamadas HTTP
salientes y llamadas SQL.
PerformanceCollectorModule : recopila información de PerformanceCounters de Windows.
QuickPulseTelemetryModule : recopila telemetría para mostrar en el portal de Live Metrics.
AppServicesHeartbeatTelemetryModule : recopila latidos (que se envían como métricas personalizadas)
sobre el entorno de Azure App Service donde se hospeda la aplicación.
AzureInstanceMetadataTelemetryModule : recopila latidos (que se envían como métricas personalizadas)
sobre el entorno de las máquinas virtuales de Azure donde se hospeda la aplicación.
EventCounterCollectionModule : recopila información de EventCounter. Este módulo es una característica
nueva y está disponible en la versión 2.8.0 y versiones posteriores del SDK.
Para configurar cualquier objeto TelemetryModule predeterminado, use el método de la extensión
ConfigureTelemetryModule<T> en IServiceCollection , como se muestra en el ejemplo siguiente.
using Microsoft.ApplicationInsights.DependencyCollector;
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector;

{
// The following configures DependencyTrackingTelemetryModule.

// Similarly, any other default modules can be configured.
services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) =>
{
module.EnableW3CHeadersInjection = true;
});
// The following removes all default counters from EventCounterCollectionModule, and adds a single
one.
services.ConfigureTelemetryModule<EventCounterCollectionModule>(
(module, o) =>
{
module.Counters.Clear();
module.Counters.Add(new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
}
);
// The following removes PerformanceCollectorModule to disable perf-counter collection.

// Similarly, any other default modules can be removed.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>(t =>
t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
A partir de la versión 2.12.2, ApplicationInsightsServiceOptions contiene una opción sencilla para

deshabilitar cualquiera de los módulos predeterminados.
Configuración de un canal de telemetría
El Canal de telemetría predeterminado es ServerTelemetryChannel . Puede invalidarlo tal como se muestra
en el ejemplo siguiente.
using Microsoft.ApplicationInsights.Channel;

{
// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel()
{MaxTelemetryBufferCapacity = 19898 });
}
Deshabilitar la telemetría dinámicamente

Si desea deshabilitar la telemetría condicional y dinámicamente, puede resolver la instancia
TelemetryConfiguration con el contenedor de inyección de dependencias de ASP.NET Core en cualquier
parte del código y establecer DisableTelemetry como marca.
{
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration

configuration)
{
configuration.DisableTelemetry = true;
...
}
Lo anterior no impide que los módulos de recopilación automática recopilen la telemetría. El envío de
telemetría a Application Insights solo se deshabilita con el enfoque anterior. Si no quiere un módulo de
recopilación automática determinado, lo mejor es quitar el módulo de telemetría.

¿Admite Application Insights ASP.NET Core 3.X?
Sí. Actualice a la versión 2.8.0 o una posterior del SDK de Application Insights para ASP.NET Core. Las
versiones anteriores del SDK no admiten ASP.NET Core 3.X.
Además, si usa estas instrucciones basadas en Visual Studio, actualice a la versión más reciente de
Visual Studio 2019 (16.3.0) para la incorporación. Las versiones anteriores de Visual Studio no admiten la
incorporación automática de aplicaciones ASP.NET Core 3.X.
¿Cómo puedo realizar un seguimiento de la telemetría que se recopila automáticamente?
Obtenga una instancia de TelemetryClient mediante el uso de la inserción del constructor y llame al
método TrackXXX() necesario que incluye. No se recomienda crear nuevas instancias TelemetryClient en
una aplicación de ASP.NET Core. Una instancia singleton de TelemetryClient ya está registrada en el
contenedor DependencyInjection , que comparte TelemetryConfiguration con el resto de los datos de
telemetría. Se recomienda crear una nueva instancia TelemetryClient solo si se necesita una configuración
independiente del resto de los datos de telemetría.
En el ejemplo siguiente se muestra cómo realizar el seguimiento de los datos de telemetría adicionales
desde un controlador.
using Microsoft.ApplicationInsights;
public class HomeController : Controller

{
private TelemetryClient telemetry;
// Use constructor injection to get a TelemetryClient instance.

public HomeController(TelemetryClient telemetry)
{
this.telemetry = telemetry;
}
public IActionResult Index()

{
// Call the required TrackXXX method.
this.telemetry.TrackEvent("HomePageRequested");
return View();
}
Para obtener más información acerca de los datos personalizados que reporta Application Insights,
consulte API de Application Insights para eventos y métricas personalizados. Se puede usar un enfoque
similar para el envío de métricas personalizadas a Application Insights mediante la API de GetMetric.
Algunas plantillas de Visual Studio usan el método de extensión UseApplicationInsights() en
IWebHostBuilder para habilitar Application Insights. ¿Es este uso aún válido?
Aunque todavía se admite el método de extensión UseApplicationInsights() , está marcado como obsoleto
desde la versión 2.8.0 del SDK de Application Insights en adelante. Se quitará en el siguiente cambio de
versión principal del SDK. La manera recomendada de habilitar la telemetría de Application Insights es usar
AddApplicationInsightsTelemetry() , porque proporciona sobrecargas para controlar configuración.
Además, en las aplicaciones ASP.NET Core 3.X, services.AddApplicationInsightsTelemetry() es la única
manera de habilitar Application Insights.
Estoy implementando mi aplicación de ASP.NET Core en Web Apps. ¿Debo habilitar la extensión de
Application Insights desde Web Apps?
Si está instalado el SDK en tiempo de compilación, como se muestra en este artículo, no es necesario
habilitar la extensión de Application Insights desde el portal de App Service. Incluso si la extensión está
instalada, se retirará cuando detecte que el SDK ya está agregado en la aplicación. Si habilita Application
Insights desde la extensión, no tiene que instalar ni actualizar el SDK. Pero si habilita Application Insights
siguiendo las instrucciones de este artículo, tendrá más flexibilidad porque:
La telemetría de Application Insights seguirá funcionando en:
Todos los sistemas operativos, incluidos Windows, Linux y Mac.
Todos los modos de publicación, incluidos los independientes o dependientes del marco.
Todas las plataformas de destino, incluida la versión completa de .NET Framework.
Todas las opciones de hospedaje, incluidos contenedores, Web Apps, VM, Linux, Azure Kubernetes
Service y hospedaje independiente de Azure.
Todas las versiones de .NET Core, incluidas las versiones preliminares.
Puede ver datos de telemetría localmente cuando depure desde Visual Studio.
Puede realizar un seguimiento de telemetría personalizada adicional mediante la API TrackXXX() .
Tiene control total sobre la configuración.
¿Puedo habilitar la supervisión de Application Insights con herramientas como Monitor de estado?
No. Monitor de estado y Monitor de estado v2 actualmente solo son compatibles con ASP.NET 4.x.
¿Se habilita automáticamente Application Insights para mi aplicación de ASP.NET Core 2.0?
El metapaquete Microsoft.AspNetCore.All 2.0 incluye el SDK de Application Insights (versión 2.1.0). Si
ejecuta la aplicación en el depurador de Visual Studio, Visual Studio habilita Application Insights y muestra
los datos de telemetría localmente en el propio IDE. No se envían datos de telemetría al servicio Application
Insights, a menos que se haya especificado una clave de instrumentación. Se recomienda seguir las
instrucciones de este artículo para habilitar Application Insights, incluso para aplicaciones 2.0.
Si ejecuto mi aplicación en Linux, ¿se admiten todas las características?
Sí. La compatibilidad de características para el SDK es la misma en todas las plataformas, con las siguientes
excepciones:
El SDK recopila contadores de eventos en Linux, ya que los contadores de rendimiento solo se admiten
en Windows. La mayoría de las métricas son las mismas.
Aunque el objeto ServerTelemetryChannel está habilitado de forma predeterminada, si la aplicación se
ejecuta en Linux o MacOS, el canal no crea automáticamente una carpeta de almacenamiento local para
mantener los datos de telemetría temporalmente si hay problemas de red. Debido a esta limitación, la
telemetría se pierde cuando hay problemas temporales de red o del servidor. Para solucionar este
problema, configure una carpeta local para el canal:
using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;

{
// The following will configure the channel to use the given folder to temporarily
// store telemetry items during network or Application Insights server issues.
// User should ensure that the given folder already exists
// and that the application has read/write permissions.
services.AddSingleton(typeof(ITelemetryChannel),
new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
}
¿Es este SDK compatible con las nuevas aplicaciones de plantilla de servicio de trabajo de .NET
Core 3.X?
Este SDK requiere HttpContext y, por lo tanto, no funciona en ninguna aplicación sin HTTP, incluidas las
aplicaciones de servicio de trabajo de .NET Core 3.X. Consulte este documento para habilitar Application
Insights en tales aplicaciones mediante el SDK de Microsoft.ApplicationInsights.WorkerService que se acaba
de publicar.
SDK de código abierto

Lectura y contribución al código.
Para obtener las actualizaciones y correcciones de errores más recientes, consulte las notas de la versión.
Pasos siguientes
Explore los flujos de usuarios para saber cómo navegan por la aplicación.
Configure una colección de instantáneas para ver el estado del código fuente y las variables en el
momento en que se produzca una excepción.
Use la API para enviar sus propios eventos y métricas para obtener una vista detallada del rendimiento y
del uso de la aplicación.
Las pruebas de disponibilidad comprueban la aplicación constantemente desde cualquier parte del
mundo.
Inserción de dependencias en ASP.NET Core
ApplicationInsightsLoggerProvider para los registros
de ILogger de .NET Core
ASP.NET Core es compatible con una API de registro que funciona con diferentes tipos de proveedores de registro
integrados y de terceros. El registro se realiza mediante una llamada a Log() o una variante de este en instancias
de ILogger. En este artículo se muestra cómo usar ApplicationInsightsLoggerProvider para capturar los registros
de ILogger en aplicaciones de consola y de ASP.NET Core. También se describe cómo
ApplicationInsightsLoggerProvider se integra con otros datos de telemetría de Application Insights. Para más
información, consulte Registro en ASP.NET Core.
Aplicaciones de ASP.NET Core

ApplicationInsightsLoggerProvider se habilita de forma predeterminada en el SDK
Microsoft.ApplicationInsights.AspNet versión 2.7.1 (y posteriores) al activar una supervisión normal de Application
Insights mediante uno de los siguientes métodos:
Mediante una llamada al método de extensión UseApplicationInsights en IWebHostBuilder (ahora obsoleto)
Mediante una llamada al método de extensión AddApplicationInsightsTelemetr y en IServiceCollection
Los registros de ILogger que captura ApplicationInsightsLoggerProvider están sujetos a la misma configuración
que los otros datos de telemetría recopilados. Tienen el mismo conjunto de objetos TelemetryInitializer y
TelemetryProcessor, usan el mismo objeto TelemetryChannel, y se ponen en correlación y muestrean de la misma
manera que otros datos de telemetría. Si usa la versión 2.7.1 o posteriores, no necesita realizar ninguna acción
para capturar registros de ILogger.
De forma predeterminada, solo se envían a Application Insights los registros de Advertencia o superiores de
ILogger (de todas las categorías). Sin embargo, puede aplicar filtros para modificar este comportamiento. Se
necesitan pasos adicionales para capturar registros de ILogger desde Program.cs o Star tup.cs (consulte Captura
de registros de ILogger de Startup.cs y Program.cs en aplicaciones de ASP.NET Core).
Si usa una versión anterior del SDK de Microsoft.ApplicationInsights.AspNet o desea usar solo
ApplicationInsightsLoggerProvider sin ninguna otra supervisión de Application Insights, use el procedimiento
siguiente:
1. Instale el paquete de NuGet:
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging.ApplicationInsights" Version="2.9.1" />
</ItemGroup>
2. Modifique Program.cs tal como se muestra aquí:

using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Logging;
public class Program

{
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>

WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureLogging(
builder =>
{
// Providing an instrumentation key here is required if you're using
// standalone package Microsoft.Extensions.Logging.ApplicationInsights
// or if you want to capture logs from early in the application startup
// pipeline from Startup.cs or Program.cs itself.
builder.AddApplicationInsights("ikey");
// Optional: Apply filters to control what logs are sent to Application Insights.
// The following configures LogLevel Information or above to be sent to
// Application Insights for all categories.
builder.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("", LogLevel.Information);
}
);
}
El código del paso 2 configura ApplicationInsightsLoggerProvider . El código siguiente muestra un ejemplo de la

clase Controller, que usa ILogger para enviar registros. Application Insights captura los registros.
public class ValuesController : ControllerBase

{
private readonly ILogger _logger;
public ValuesController(ILogger<ValuesController> logger)

{
_logger = logger;
}
// GET api/values
[HttpGet]
public ActionResult<IEnumerable<string>> Get()
{
// All the following logs will be picked up by Application Insights.
// and all of them will have ("MyKey", "MyValue") in Properties.
using (_logger.BeginScope(new Dictionary<string, object> { { "MyKey", "MyValue" } }))
{
_logger.LogWarning("An example of a Warning trace..");
_logger.LogError("An example of an Error level message");
}
return new string[] { "value1", "value2" };
}
}
Captura de registros de ILogger de Startup.cs y Program.cs en aplicaciones de ASP.NET Core

NOTE
En ASP.NET Core 3.0 y versiones posteriores, ya no es posible insertar ILogger en Startup.cs y Program.cs. Para obtener
más información, consulte https://github.com/aspnet/Announcements/issues/353.
El nuevo proveedor ApplicationInsightsLoggerProvider puede capturar registros antes en la canalización de inicio

de una aplicación. Aunque ApplicationInsightsLoggerProvider está habilitado automáticamente en Application
Insights (a partir de la versión 2.7.1), no tiene una clave de instrumentación configurada hasta más adelante en la
canalización. Por lo tanto, solo se capturarán registros de Controller y otras clases. Para capturar todos los
registros, ya desde Program.cs y Star tup.cs , debe habilitar explícitamente una clave de instrumentación para
ApplicationInsightsLoggerProvider. Además, la configuración de TelemetryConfiguration no está completa cuando
se registra desde los propios Program.cs o Star tup.cs . Por lo tanto, esos registros tendrán una configuración
mínima que utiliza InMemoryChannel, sin muestreo y sin inicializadores ni procesadores de telemetría estándar.
En los siguientes ejemplos se muestra esta funcionalidad con Program.cs y Star tup.cs .
Ejemplo de Program.cs
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;

{
{
var host = CreateWebHostBuilder(args).Build();
var logger = host.Services.GetRequiredService<ILogger<Program>>();
// This will be picked up by AI
logger.LogInformation("From Program. Running the host now..");
host.Run();
}

.ConfigureLogging(
builder =>
{
// Providing an instrumentation key here is required if you're using
// standalone package Microsoft.Extensions.Logging.ApplicationInsights
// or if you want to capture logs from early in the application startup
// pipeline from Startup.cs or Program.cs itself.
builder.AddApplicationInsights("ikey");
// Adding the filter below to ensure logs of all severity from Program.cs
// is sent to ApplicationInsights.
(typeof(Program).FullName, LogLevel.Trace);
// Adding the filter below to ensure logs of all severity from Startup.cs
// is sent to ApplicationInsights.
(typeof(Startup).FullName, LogLevel.Trace);
}
);
}
Ejemplo de Startup.cs
public class Startup
{
public Startup(IConfiguration configuration, ILogger<Startup> logger)

{
Configuration = configuration;
_logger = logger;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
{
// The following will be picked up by Application Insights.

_logger.LogInformation("Logging from ConfigureServices.");
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
_logger.LogInformation("Configuring for Development environment");
app.UseDeveloperExceptionPage();
}
else
{
_logger.LogInformation("Configuring for Production environment");
}
app.UseMvc();
}
}
Migración desde el antiguo ApplicationInsightsLoggerProvider

Las versiones del SDK de Microsoft.ApplicationInsights.AspNet anteriores a 2.7.1 eran compatibles con un
proveedor de registro que ahora está obsoleto. Este proveedor se habilitaba a través del método de extensión
AddApplicationInsights() de ILoggerFactory. Le recomendamos que migre al nuevo proveedor, lo que implica
dos pasos:
1. Quitar la llamada a ILoggerFactory.AddApplicationInsights() del método Star tup.Configure() para evitar un
registro doble.
2. Volver a aplicar las reglas de filtrado en el código, porque el nuevo proveedor no las respetará. Las sobrecargas
de ILoggerFactory.AddApplicationInsights() incluían un mínimo de funciones de LogLevel o filtro. Con el nuevo
proveedor, el filtrado forma parte de la propia plataforma de registro. Ya no lo realiza el proveedor de
Application Insights. Por lo tanto, deben quitarse los filtros que se proporcionan a través de las sobrecargas de
ILoggerFactory.AddApplicationInsights() . Las reglas de filtrado deben proporcionarse siguiendo las
instrucciones de Control del nivel de registro. Si usa appsettings.json para filtrar el registro, seguirá
funcionando con el nuevo proveedor, ya que ambos usan el mismo alias de proveedor, ApplicationInsights.
Todavía puede usar el proveedor anterior (solo se quitará en un cambio de versión principal a 3.xx). Sin embargo, le
recomendamos que migre al nuevo proveedor, por los siguientes motivos:
El proveedor anterior no es compatible con ámbitos de registro. En el nuevo proveedor, las propiedades del
ámbito se agregan automáticamente como propiedades personalizadas a los datos de telemetría recopilados.
Ahora se pueden capturar registros mucho antes en la canalización de inicio de la aplicación. Ya se pueden
capturar registros de las clases Program y Star tup .
Con el nuevo proveedor, el filtrado se realiza en el propio nivel de la plataforma. Puede filtrar los registros del
proveedor de Application Insights de la misma manera que en otros proveedores, incluidos los proveedores
integrados, como la consola, depuración, etcétera. También puede aplicar los mismos filtros a varios
proveedores.
En ASP.NET Core (versión 2.0 y posteriores), el método recomendado para habilitar proveedores de registro
consiste en usar métodos de extensión en ILoggingBuilder en el propio archivo Program.cs .
NOTE
El nuevo proveedor está disponible para aplicaciones dirigidas a NETSTANDARD2.0 o posterior. Desde SDK
Microsoft.ApplicationInsights.AspNet versión 2.14.0, también hay un nuevo proveedor disponible para las aplicaciones que
tienen como destino .NET Framework NET461 o posterior. Si la aplicación se dirige a versiones anteriores de .NET Core, como
.NET Core 1.1, o a .NET Framework anteriores a NET46, siga usando el proveedor anterior.
Aplicación de consola
NOTE
Hay un nuevo SDK de Application Insights llamado Microsoft.ApplicationInsights.WorkerService que se puede usar para
habilitar Application Insights (ILogger y otra información de telemetría de Application Insights) en cualquier aplicación de
consola. Se recomienda usar este paquete y las instrucciones asociadas que se indican aquí.
En el siguiente código se muestra una aplicación de ejemplo de la consola configurada para enviar seguimientos
de ILogger a Application Insights.
Paquetes instalados:
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.1.0" />
<PackageReference Include="Microsoft.Extensions.Logging.ApplicationInsights" Version="2.9.1" />
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.1.0" />
</ItemGroup>
class Program
{
static void Main(string[] args)
{
// Create the DI container.
IServiceCollection services = new ServiceCollection();
// Channel is explicitly configured to do flush on it later.

var channel = new InMemoryChannel();
services.Configure<TelemetryConfiguration>(
(config) =>
{
config.TelemetryChannel = channel;
}
);
// Add the logging pipelines to use. We are using Application Insights only here.
services.AddLogging(builder =>
{
// Optional: Apply filters to configure LogLevel Trace or above is sent to
// Application Insights for all categories.
("", LogLevel.Trace);
builder.AddApplicationInsights("--YourAIKeyHere--");
});
// Build ServiceProvider.
IServiceProvider serviceProvider = services.BuildServiceProvider();
ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();
// Begin a new scope. This is optional.

using (logger.BeginScope(new Dictionary<string, object> { { "Method", nameof(Main) } }))
{
logger.LogInformation("Logger is working"); // this will be captured by Application Insights.
}
// Explicitly call Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if application terminates, telemetry is sent to the back-end.
channel.Flush();
Thread.Sleep(1000);
}
}
Este ejemplo usa el paquete independiente Microsoft.Extensions.Logging.ApplicationInsights . De forma

predeterminada, esta configuración utiliza la opción "mínima" de TelemetryConfiguration para enviar datos a
Application Insights. Mínima significa que el canal que se utiliza es InMemoryChannel. No hay ningún muestreo ni
TelemetryInitializers estándar. Este comportamiento se puede invalidar para una aplicación de consola, tal como se
muestra en el siguiente ejemplo.
Instale este paquete adicional:
<PackageReference Include="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" Version="2.9.1" />
En la sección siguiente se muestra cómo invalidar el valor predeterminado de TelemetryConfiguration con el

método ser vices.Configure<Telemetr yConfiguration>() . En este ejemplo se configura
ServerTelemetryChannel y el muestreo. Se agrega un elemento ITelemetryInitializer personalizado a
TelemetryConfiguration.
var serverChannel = new ServerTelemetryChannel();
services.Configure<TelemetryConfiguration>(
(config) =>
{
config.TelemetryChannel = serverChannel;
config.TelemetryInitializers.Add(new MyTelemetryInitalizer());
config.DefaultTelemetrySink.TelemetryProcessorChainBuilder.UseSampling(5);
serverChannel.Initialize(config);
}
);
// Add the logging pipelines to use. We are adding Application Insights only.
services.AddLogging(loggingBuilder =>
{
loggingBuilder.AddApplicationInsights();
});
........
........
// Explicitly calling Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if the application terminates, telemetry is sent to the back end.
serverChannel.Flush();
Thread.Sleep(1000);
Control del nivel de registro

La infraestructura ILogger de ASP.NET Core incluye un mecanismo integrado para aplicar el filtrado del registro.
Esto permite controlar los registros que se envían a cada proveedor registrado, incluido el proveedor de
Application Insights. El filtrado se puede realizar en la configuración (normalmente mediante un archivo
appsettings.json) o en el código. Esta función se proporciona en la propia plataforma. No es específica del
proveedor de Application Insights.
En los ejemplos siguientes se aplican reglas de filtro a ApplicationInsightsLoggerProvider.
Creación de reglas de filtro en la configuración con appsettings.json
Para ApplicationInsightsLoggerProvider, el alias de proveedor es ApplicationInsights . En la siguiente sección de
appsettings.json se indica a los proveedores de registro que generalmente se registren en el nivel Advertencia y
superiores. A continuación, invalida el ApplicationInsightsLoggerProvider para registrar las categorías que
comienzan por "Microsoft" en el nivel Error y superiores.
{
"Logging": {
"LogLevel": {
},
"LogLevel": {
"Microsoft": "Error"
}
}
}
}
Creación de reglas de filtro en el código

En el siguiente fragmento de código se configuran los registros para que el nivel de Warning (Advertencia) y
superiores de todas las categorías, y el nivel de Error y superiores de las categorías que comienzan con
"Microsoft"se envíen a ApplicationInsightsLoggerProvider . Esta configuración es la misma que en la sección
anterior en appsettings.json.
.ConfigureLogging(logging =>
logging.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("", LogLevel.Warning)
.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider>
("Microsoft", LogLevel.Error);

¿Cuáles son las versiones antigua y nueva de ApplicationInsightsLoggerProvider?
El SDK de Microsoft.ApplicationInsights.AspNet incluía un elemento ApplicationInsightsLoggerProvider integrado
(Microsoft.ApplicationInsights.AspNetCore.Logging.ApplicationInsightsLoggerProvider), que se habilitaba a través
de métodos de extensión de ILoggerFactor y . Este proveedor está marcado como obsoleto desde la versión 2.7.1.
Se quitará por completo en el siguiente cambio de versión principal. El paquete
Microsoft.ApplicationInsights.AspNetCore 2.6.1 en sí no está obsoleto. Se necesita para habilitar la supervisión de
las solicitudes, las dependencias, etcétera.
La alternativa propuesta es el nuevo paquete independiente Microsoft.Extensions.Logging.ApplicationInsights, que
contiene un proveedor ApplicationInsightsLoggerProvider
(Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider) y métodos de extensión en
ILoggerBuilder para habilitarlo.
El SDK de Microsoft.ApplicationInsights.AspNet versión 2.7.1 depende del nuevo paquete y habilita la captura de
ILogger automáticamente.
¿Por qué algunos registros de ILogger se muestran dos veces en Application Insights?
La duplicación puede ocurrir si tiene la versión anterior (ya obsoleta) de ApplicationInsightsLoggerProvider
habilitada mediante una llamada a AddApplicationInsights en ILoggerFactory . Compruebe si el método
Configure incluye la siguiente información y quítela:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

{
loggerFactory.AddApplicationInsights(app.ApplicationServices, LogLevel.Warning);
// ..other code.
}
Si se produce un registro doble cuando se depura desde Visual Studio, establezca EnableDebugLogger en false en el
código que habilita Application Insights, como se indica a continuación. Esta duplicación y la corrección solo son
pertinentes cuando se depura la aplicación.

{
ApplicationInsightsServiceOptions options = new ApplicationInsightsServiceOptions();
options.EnableDebugLogger = false;
services.AddApplicationInsightsTelemetry(options);
// ..other code.
}
Actualicé al SDK de Microsoft.ApplicationInsights.AspNet versión 2.7.1 y los registros de ILogger se capturan

automáticamente. ¿Cómo desactivo por completo esta característica?
Consulte en la sección Control del nivel de registro cómo filtrar los registros en general. Para desactivar
ApplicationInsightsLoggerProvider, utilice LogLevel.None :
En el código:
("", LogLevel.None);
En la configuración:
{
"Logging": {
"LogLevel": {
"Default": "None"
}
}
¿Por qué algunos registros de ILogger no tiene las mismas propiedades que otros?
Application Insights captura y envía los registros de ILogger con el mismo valor de TelemetryConfiguration que se
usa para los demás datos de telemetría. Sin embargo, hay una excepción. De forma predeterminada, la
configuración de TelemetryConfiguration no está completa cuando se registra desde Program.cs o Star tup.cs .
Los registros con estas procedencias no tendrán la configuración predeterminada, por lo que no se ejecutarán
todos los objetos TelemetryInitializer y TelemetryProcessor.
Estoy usando el paquete independiente Microsoft.Extensions.Logging.ApplicationInsights y quiero registrar
manualmente algunos datos de telemetría personalizados adicionales. ¿Cómo debo hacerlo?
Cuando se usa el paquete independiente, TelemetryClient no se inserta en el contenedor de DI, por lo que
necesita crear una nueva instancia de TelemetryClient y utilizar la misma configuración que utilice el proveedor
de registro, como se muestra en el código siguiente. Esto garantiza que se usa la misma configuración para todos
los datos de telemetría personalizados y los datos de telemetría de ILogger.
public class MyController : ApiController

{
// This telemetryclient can be used to track additional telemetry using TrackXXX() api.
private readonly TelemetryClient _telemetryClient;
public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)

{
_telemetryClient = new TelemetryClient(options.Value);
_logger = logger;
}
}
NOTE
Si utiliza el paquete Microsoft.ApplicationInsights.AspNetCore para habilitar Application Insights, modifique este código para
obtener TelemetryClient directamente en el constructor. Para ver un ejemplo, consulte esta pregunta frecuente.
¿Qué tipo de datos de telemetría de Application Insights se generan a partir de los registros de ILogger? O
bien, ¿dónde puedo ver los registros de ILogger en Application Insights?
ApplicationInsightsLoggerProvider captura los registros de ILogger y crea un elemento TraceTelemetry a partir de
ellos. Si se pasa un objeto Exception al método Log() de ILogger, se crea un elemento ExceptionTelemetry en lugar
de TraceTelemetry. Estos elementos de telemetría pueden encontrarse en los mismos lugares que otros elementos
TraceTelemetry o ExceptionTelemetry para Application Insights, incluido el portal, análisis o el depurador local de
Visual Studio.
Si prefiere enviar siempre un elemento TraceTelemetry, use este fragmento de código:
builder.AddApplicationInsights((opt) => opt.TrackExceptionsAsExceptionTelemetry = false);
No tengo instalado el SDK y uso la extensión Web Apps de Azure para habilitar Application Insights para mis
aplicaciones de ASP.NET Core. ¿Cómo uso el nuevo proveedor?
La extensión de Application Insights en Azure Web Apps usa el nuevo proveedor. Puede modificar las reglas de
filtrado en el archivo appsettings.json para la aplicación.
Estoy usando el paquete independiente Microsoft.Extensions.Logging.ApplicationInsights y habilito el
proveedor de Application Insights mediante una llamada a builder.AddApplicationInsights("ikey") . ¿Existe
alguna opción para obtener una clave de instrumentación a partir de la configuración?
Modifique Program.cs y appsettings.json como se indica a continuación:

{
{
CreateWebHostBuilder(args).Build().Run();
}

.ConfigureLogging((hostingContext, logging) =>
{
// hostingContext.HostingEnvironment can be used to determine environments as well.
var appInsightKey = hostingContext.Configuration["myikeyfromconfig"];
logging.AddApplicationInsights(appInsightKey);
});
}
Sección relevante de appsettings.json :
{
"myikeyfromconfig": "putrealikeyhere"
}
Este código solo es necesario cuando se usa un proveedor de registro independiente. En la supervisión normal de
Application Insights, la clave de instrumentación se carga automáticamente desde la ruta de acceso de
configuración ApplicationInsights: Instrumentationkey. Appsettings.json debe tener este aspecto:
{
"ApplicationInsights":
{
"Instrumentationkey":"putrealikeyhere"
}
}
Pasos siguientes
Más información sobre:
Registro en ASP.NET Core
Registros de seguimiento de .NET en Application Insights
Configuración de Application Insights para
un sitio web de ASP.NET
Este procedimiento configura una aplicación web de ASP.NET para que envíe datos de
telemetría al servicio Azure Application Insights. Funciona en las aplicaciones ASP.NET que se
hospedan en su propio servidor IIS local o en la nube. Obtenga gráficos y un eficaz lenguaje de
consulta que le ayudarán a conocer el rendimiento de la aplicación y cómo la usan las
personas, más alertas automáticas cuando aparezcan errores o haya problemas de
rendimiento. Muchos desarrolladores consideran que estas características son excelentes tal y
como están, pero si necesita ampliar y personalizar la telemetría, puede hacerlo.
Su instalación se realiza desde Visual Studio con unos pocos clics. Tiene la opción para evitar
cargos. Para ello, solo debe limitar el volumen de la telemetría. Esta funcionalidad le permite
probar y depurar un sitio con no muchos usuarios, o incluso supervisarlo. Si decide que desea
supervisar su sitio de producción, no le costará trabajo aumentar el límite más adelante.
Prerrequisitos
Para agregar Application Insights al sitio web de ASP.NET, necesita:
Instale Visual Studio 2019 para Windows con las cargas de trabajo siguientes:
Desarrollo de ASP.NET y web (no desactive los componentes opcionales)
Desarrollo de Azure
Paso 1: Agregue el SDK de Application Insights

IMPORTANT
Las capturas de pantalla de este ejemplo están basadas en Visual Studio 2017, versión 15.9.9 y
posteriores. La experiencia de adición de Application Insights varía en las versiones de Visual Studio, así
como el tipo de plantilla de ASP.NET. Las versiones anteriores pueden tener texto alternativo, como
"Configurar Application Insights".
Haga clic con el botón derecho en el nombre de la aplicación web en el Explorador de

soluciones y seleccione Agregar > Telemetría de Application Insights .
(En función de la versión del SDK de Application Insights que tenga, puede que se le solicite
que actualice a la versión más reciente. Si se le solicita, seleccione Actualizar SDK .)
Pantalla Configuración de Application Insights:

Seleccione Comenzar .
Si desea establecer el grupo de recursos o la ubicación en que se almacenan los datos, haga
clic en Parámetros de configuración . Los grupos de recursos se utilizan para controlar el
acceso a los datos. Por ejemplo, si tiene varias aplicaciones que forman parte del mismo
sistema, puede poner sus datos de Application Insights en el mismo grupo de recursos.
Seleccione Registrar .
Seleccione Proyecto > Administrar paquetes NuGet > Origen de paquete: nuget.org >
Confirme que tiene la versión estable más reciente del SDK de Application Insights.
La telemetría se enviará a Azure Portal, durante la depuración y después de que se haya
publicado la aplicación.
NOTE
Si no desea enviar datos de telemetría al portal mientras se lleva a cabo una depuración, agregue el
SDK de Application Insights a la aplicación, pero no configure ningún recurso en el portal. Durante la
depuración puede ver la telemetría en Visual Studio. Posteriormente, puede volver a esta página de
configuración, o bien puede esperar hasta que haya implementado la aplicación y activar la telemetría
en tiempo de ejecución.
Paso 2: Ejecutar la aplicación

Ejecute la aplicación con F5. Abra distintas páginas para generar telemetría.
En Visual Studio, verá un recuento de los eventos que se han registrado.
Paso 3: Visualización de los datos de telemetría
La telemetría se puede ver en Visual Studio o en el portal web de Application Insights. Busque
telemetría en Visual Studio, ya que le ayudará a depurar la aplicación. Supervise el rendimiento
y uso en el portal web cuando el sistema esté activo.
Visualización de datos de telemetría en Visual Studio
En Visual Studio, para ver los datos de Application Insights. Seleccione Explorador de
soluciones > Ser vicios conectados > haga clic con el botón derecho en Application
Insights y, a continuación, haga clic en Buscar telemetría activa .
En la ventana de búsqueda de Application Insights de Visual Studio, puede ver los datos de la
aplicación para la telemetría generada en el lado servidor de la aplicación. Experimente con los
filtros y haga clic en cualquier evento para ver más información al respecto.
TIP
Si no ve datos, asegúrese de que el intervalo de tiempo es correcto y haga clic en el icono de
búsqueda.
Más información acerca de las herramientas de Application Insights en Visual Studio.

Visualización de datos de telemetría en el portal web
La telemetría también se puede ver en el portal web de Application Insights (salvo que se elija
instalar solo el SDK). El portal tiene más gráficos, herramientas de análisis y vistas de
componentes que Visual Studio. El portal también ofrece alertas.
Abra el recurso de Application Insights. Inicie sesión en Azure Portal y búsquelo allí o
seleccione Explorador de soluciones > Ser vicios conectados > haga clic con el botón
derecho en Application Insights > Abrir por tal de Application Insights y deje que le
lleve allí.
El portal se abrirá en una vista de los datos de telemetría de su aplicación.
En el portal, haga clic en cualquier icono para ver su contenido con mayor detalle.
Paso 4: Publicación de la aplicación

Publique su aplicación en el servidor IIS o en Azure. Consulte Secuencia de métricas en directo
para asegurarse de que todo está ejecutándose sin problemas.
La telemetría se crea en el portal de Application Insights, donde puede supervisar las métricas
y buscar la telemetría. También puede usar el eficaz lenguaje de consulta de Kusto para analizar
el uso y rendimiento o para buscar eventos concretos.
También puede seguir analizando la telemetría en Visual Studio con herramientas como
búsqueda de diagnóstico y las tendencias.
NOTE
Si la aplicación envía suficiente telemetría que se acerque a las limitaciones de peticiones, se activará el
muestreo automático. El muestreo reduce la cantidad de datos de telemetría enviados desde su
aplicación, a la vez que conserva los datos correlacionados para fines de diagnóstico.
Ya está listo
Felicidades. Ha instalado el paquete de Application Insights en la aplicación y lo ha configurado
para que envíe telemetría al servicio Application Insights en Azure.
El recurso de Azure que recibe la telemetría de la aplicación se identifica mediante una clave de
instrumentación, que se encuentra en el archivo ApplicationInsights.config.
Actualización a futuras versiones del SDK

Notas de la versión
Para actualizar a una nueva versión del SDK, abra el Administrador de paquetes NuGet y
filtre por los paquetes instalados. Seleccione Microsoft.ApplicationInsights.Web y elija
Actualizar .
Si ha hecho alguna personalización en ApplicationInsights.config, guarde una copia del mismo
antes de realizar la actualización. Luego, combine los cambios en la nueva versión.
Pasos siguientes
Si está interesado, puede examinar otros temas:
Instrumentación de aplicaciones web en tiempo de ejecución con Application Insights
Más telemetría
Datos de carga de página y explorador : inserte un fragmento de código en las
páginas web.
Obtenga una super visión más detallada de las dependencias y excepciones :
instale el Monitor de estado en el servidor.
Codifique eventos personalizados para contar, cronometrar y medir las acciones de los
usuarios.
Obtenga datos del registro : ponga en correlación los datos del registro con la
telemetría.
Análisis
Trabajo con Application Insights en Visual Studio
Incluye información acerca de la depuración con telemetría, la búsqueda de diagnóstico y la
profundización en el código.
Analytics : eficaz lenguaje de consulta.
Alertas
Pruebas de disponibilidad: cree pruebas para asegurarse de que el sitio sea visible en la
Web.
Diagnósticos inteligentes: estas pruebas se realizan automáticamente, por lo que no es
preciso hacer nada para configurarlas. Le indican si la aplicación tiene una tasa de
solicitudes con error inusual.
Alertas de métricas: Establezca alertas que le adviertan si una métrica supera un umbral.
Puede establecerlas en las métricas personalizadas que codifique en la aplicación.
Automation
Creación de recursos de Application Insights mediante PowerShell
Application Insights para las aplicaciones de
servicio de trabajo (aplicaciones sin HTTP)
Application Insights va a lanzar un nuevo SDK, denominado Microsoft.ApplicationInsights.WorkerService , más

adecuado para cargas de trabajo sin HTTP, como mensajería, tareas en segundo plano, aplicaciones de consola,
etc. Estos tipos de aplicaciones no tienen la noción de una solicitud HTTP entrante como las aplicaciones web
ASP.NET/ASP.NET Core tradicionales y, por tanto, no se admiten los paquetes de Application Insights para las
aplicaciones ASP.NET o ASP.NET Core.
El nuevo SDK no recopila telemetría por sí mismo. En su lugar, ofrece en otros recopiladores automáticos de
Application Insights conocidos, como DependencyCollector, PerfCounterCollector o
ApplicationInsightsLoggingProvider. Este SDK expone métodos de extensión en IServiceCollection para
habilitar y configurar la recopilación de telemetría.
Escenarios admitidos
El SDK de Application Insights para el servicio de trabajo es más adecuado para aplicaciones sin HTTP,
independientemente de dónde y cómo se ejecuten. Si la aplicación se está ejecutando y tiene conectividad de
red a Azure, se pueden recopilar datos de telemetría. La supervisión de Application Insights se admite siempre
y cuando .NET Core sea compatible. Este paquete se puede usar en el servicio de trabajo de .NET Core 3.0
presentado recientemente, en tareas en segundo plano en Asp.Net Core 2.1/2.2, en aplicaciones de consola
(.NET Core/.NET Framework), etc.
Prerrequisitos
Una clave de instrumentación de Application Insights válida. Esta clave es necesaria para enviar los datos de
telemetría a Application Insights. Si necesita crear un nuevo recurso de Application Insights para obtener un
clave de instrumentación, consulte Creación de recursos en Application Insights.
Uso del SDK de Application Insights para servicios de trabajo

1. Instale el paquete Microsoft.ApplicationInsights.WorkerService en la aplicación. En el siguiente fragmento
de código se muestran los cambios que se agregarán al archivo .csproj del proyecto.
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.13.1" />
</ItemGroup>
1. Llame al método de extensión AddApplicationInsightsTelemetryWorkerService(string instrumentationKey)

en IServiceCollection y proporcione la clave de instrumentación. Se debe llamar a este método al
inicio de la aplicación. La ubicación exacta depende del tipo de aplicación.
2. Recupere una instancia de ILogger o de TelemetryClient del contenedor de inserción de dependencias
(DI) mediante una llamada a serviceProvider.GetRequiredService<TelemetryClient>(); o la inserción de
constructores. Este paso desencadenará la configuración de los módulos de TelemetryConfiguration y
de recopilación automática.
Las instrucciones concretas para cada tipo de aplicación se indican en las secciones siguientes.
Aplicación de servicio de trabajo .NET Core 3.0
El ejemplo completo se comparte aquí
1. Descargue e instale .NET Core 3.0.
2. Cree un proyecto de servicio de trabajo mediante la nueva plantilla de proyecto de Visual Studio o la
línea de comandos dotnet new worker .
3. Instale el paquete Microsoft.ApplicationInsights.WorkerService en la aplicación.
4. Agregue services.AddApplicationInsightsTelemetryWorkerService(); al método CreateHostBuilder() en
su clase Program.cs , como en este ejemplo:
public static IHostBuilder CreateHostBuilder(string[] args) =>

Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
services.AddApplicationInsightsTelemetryWorkerService();
});
5. Modifique Worker.cs como se muestra en el ejemplo siguiente.
using Microsoft.ApplicationInsights.DataContracts;
public class Worker : BackgroundService

{
private readonly ILogger<Worker> _logger;
private TelemetryClient _telemetryClient;
private static HttpClient _httpClient = new HttpClient();
public Worker(ILogger<Worker> logger, TelemetryClient tc)

{
_logger = logger;
_telemetryClient = tc;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)

{
while (!stoppingToken.IsCancellationRequested)
{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or
higher is captured by Application Insights");
_logger.LogInformation("Calling bing.com");
var res = await _httpClient.GetAsync("https://bing.com");
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
_telemetryClient.TrackEvent("Bing call event completed");
}
await Task.Delay(1000, stoppingToken);

}
}
}
6. Comprobar la clave de instrumentación.

Aunque puede proporcionar la clave de instrumentación como un argumento a
AddApplicationInsightsTelemetryWorkerService , se recomienda que especifique la clave de
instrumentación en la configuración. En el siguiente ejemplo de código se muestra cómo especificar una
clave de instrumentación en appsettings.json . Asegúrese de que appsettings.json se copia en la
carpeta raíz de la aplicación durante la publicación.
{
"ApplicationInsights":
{
"InstrumentationKey": "putinstrumentationkeyhere"
},
"Logging":
{
"LogLevel":
{
}
}
}
Como alternativa, puede especificar la clave de instrumentación en cualquiera de las siguientes variables de
entorno. APPINSIGHTS_INSTRUMENTATIONKEY o ApplicationInsights:InstrumentationKey
Por ejemplo: SET ApplicationInsights:InstrumentationKey=putinstrumentationkeyhere o
SET APPINSIGHTS_INSTRUMENTATIONKEY=putinstrumentationkeyhere
Por lo general, APPINSIGHTS_INSTRUMENTATIONKEY especifica la clave de instrumentación para las aplicaciones

implementadas en Web Apps como trabajos web.
NOTE
Una clave de instrumentación especificada en el código prevalece frente a la variable del entorno
APPINSIGHTS_INSTRUMENTATIONKEY , que prevalece sobre otras opciones.
Tareas en segundo plano de ASP.NET Core con servicios hospedados

En este documento se describe cómo crear tareas en segundo plano en la aplicación ASP.NET Core 2.1/2.2.
1. Instale el paquete Microsoft.ApplicationInsights.WorkerService
(https://www.nuget.org/packages/Microsoft.ApplicationInsights.WorkerService) ) en la aplicación.
2. Agregue services.AddApplicationInsightsTelemetryWorkerService(); al método ConfigureServices() , como
en este ejemplo:
public static async Task Main(string[] args)
{
var host = new HostBuilder()
.ConfigureAppConfiguration((hostContext, config) =>
{
config.AddJsonFile("appsettings.json", optional: true);
})
.ConfigureServices((hostContext, services) =>
{
services.AddLogging();
services.AddHostedService<TimedHostedService>();
// instrumentation key is read automatically from appsettings.json

})
.UseConsoleLifetime()
.Build();
using (host)
{
// Start the host
await host.StartAsync();
// Wait for the host to shutdown

await host.WaitForShutdownAsync();
}
}
A continuación se encuentra el código para TimedHostedService donde reside la lógica de la tarea en segundo
plano.
public class TimedHostedService : IHostedService, IDisposable

{
private Timer _timer;
private static HttpClient httpClient = new HttpClient();
public TimedHostedService(ILogger<TimedHostedService> logger, TelemetryClient tc)

{
_logger = logger;
this._telemetryClient = tc;
}
public Task StartAsync(CancellationToken cancellationToken)

{
_logger.LogInformation("Timed Background Service is starting.");
_timer = new Timer(DoWork, null, TimeSpan.Zero,

TimeSpan.FromSeconds(1));
return Task.CompletedTask;
}
private void DoWork(object state)

{
using (_telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
_logger.LogWarning("A sample warning message. By default, logs with severity Warning or
higher is captured by Application Insights");
_logger.LogInformation("Calling bing.com");
var res = httpClient.GetAsync("https://bing.com").GetAwaiter().GetResult();
_logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
_telemetryClient.TrackEvent("Bing call event completed");
}
}
}
3. Comprobar la clave de instrumentación. Use el mismo appsettings.json del ejemplo anterior del servicio
de trabajo de .NET Core 3.0.
Aplicación de consola .NET Core/.NET Framework

Como se mencionó al principio de este artículo, el nuevo paquete se puede usar para habilitar la telemetría de
Application Insights, incluso desde una aplicación de consola normal. Este paquete tiene como destino
NetStandard2.0 y, por lo tanto, se puede usar para aplicaciones de consola con .NET Core 2.0 o una versión
posterior, y .NET Framework 4.7.2 o una versión posterior.
1. Instale el paquete Microsoft.ApplicationInsights.WorkerService
(https://www.nuget.org/packages/Microsoft.ApplicationInsights.WorkerService) ) en la aplicación.
2. Modifique Program.cs tal como se muestra en el ejemplo siguiente.
using Microsoft.Extensions.DependencyInjection;
using System;
namespace WorkerSDKOnConsole
{
class Program
{
static async Task Main(string[] args)
{
// Being a regular console app, there is no appsettings.json or configuration providers

enabled by default.
// Hence instrumentation key and any changes to default logging level must be specified
here.
services.AddLogging(loggingBuilder =>
loggingBuilder.AddFilter<Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider
>("Category", LogLevel.Information));
services.AddApplicationInsightsTelemetryWorkerService("instrumentationkeyhere");
// Build ServiceProvider.
IServiceProvider serviceProvider = services.BuildServiceProvider();
// Obtain logger instance from DI.

ILogger<Program> logger = serviceProvider.GetRequiredService<ILogger<Program>>();
// Obtain TelemetryClient instance from DI, for additional manual tracking or to flush.
var telemetryClient = serviceProvider.GetRequiredService<TelemetryClient>();
var httpClient = new HttpClient();
while (true) // This app runs indefinitely. replace with actual application termination
logic.
{
logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
// Replace with a name which makes sense for this operation.

using (telemetryClient.StartOperation<RequestTelemetry>("operation"))
{
logger.LogWarning("A sample warning message. By default, logs with severity Warning
or higher is captured by Application Insights");
logger.LogInformation("Calling bing.com");
var res = await httpClient.GetAsync("https://bing.com");
logger.LogInformation("Calling bing completed with status:" + res.StatusCode);
telemetryClient.TrackEvent("Bing call event completed");
}
await Task.Delay(1000);
}
// Explicitly call Flush() followed by sleep is required in Console Apps.

// This is to ensure that even if application terminates, telemetry is sent to the back-
end.
telemetryClient.Flush();
Task.Delay(5000).Wait();
}
}
}
Esta aplicación de consola también usa el mismo TelemetryConfiguration predeterminado y se puede

personalizar de la misma manera que los ejemplos de la sección anterior.
Ejecute la aplicación. Todos los trabajos de ejemplo anteriores realizan una llamada HTTP por segundo a
bing.com y emiten pocos registros mediante ILogger. Estas líneas se incluyen dentro de la llamada
StartOperation de TelemetryClient , que se usa para crear una operación (en este ejemplo, RequestTelemetry ,
denominada "operation"). Application Insights recopilará estos registros de ILogger (de nivel advertencia o
superior, de forma predeterminada) y las dependencias, y se correlacionarán con RequestTelemetry con
relación de elementos primarios y secundarios. La correlación también funciona a través de límites
proceso/red. Por ejemplo, si la llamada se realizó a otro componente supervisado, se correlacionará también
con este elemento primario.
Esta operación personalizada de RequestTelemetry puede considerarse como el equivalente de una solicitud
web de entrada en una aplicación web típica. Aunque no es necesario usar una operación, se adapta mejor al
modelo de datos de correlación de Application Insights, donde RequestTelemetry actúa como operación
primaria y la telemetría generada en la iteración del trabajo se trata como que lógicamente pertenece a la
misma operación. Este enfoque también garantiza que toda la telemetría generada (automática y manual)
tendrá el mismo operation_id . Dado que el muestreo se basa en operation_id , el algoritmo de muestreo
mantiene o quita toda la telemetría de una sola iteración.
A continuación se enumera toda la telemetría que Application Insights recopila automáticamente.
Live Metrics
Live Metrics se puede usar para comprobar rápidamente si la supervisión de Application Insights está
configurada correctamente. Aunque la telemetría puede tardar unos minutos en aparecer en el portal y en el
análisis, Live Metrics mostraría el uso de la CPU del proceso en ejecución casi en tiempo real. También puede
mostrar otros tipos de telemetría, como las solicitudes, las dependencias, los seguimientos, etc.
Registros de ILogger
Los registros emitidos a través de ILogger de gravedad Warning o mayor se capturan automáticamente. Siga
la documentación de ILogger para personalizar los niveles de registro que captura Application Insights.
Dependencias
La recopilación de dependencias está habilitada de manera predeterminada. En este artículo se explican las
dependencias que se recopilan automáticamente; también contiene pasos para realizar el seguimiento manual.
EventCounter
EventCounterCollectionModule está habilitado de forma predeterminada y recopilará un conjunto
predeterminado de contadores de las aplicaciones de .NET Core 3.0. En el tutorial de EventCounter se muestra
el conjunto de contadores recopilado de manera predeterminada. También incluye instrucciones sobre la
personalización de la lista.
Seguimiento manual de la telemetría adicional
Aunque el SDK recopila automáticamente la telemetría como se explicó anteriormente, en la mayoría de los
casos el usuario deberá enviar telemetría adicional al servicio Application Insights. El mecanismo recomendado
para hacer un seguimiento de esta telemetría adicional consiste en obtener una instancia de TelemetryClient a
partir de la inserción de dependencias y llamar después a uno de los métodos TrackXXX() de la API admitidos.
Otro caso de uso típico es el seguimiento personalizado de las operaciones. Este enfoque se muestra en los
ejemplos de trabajo anteriores.

El TelemetryConfiguration predeterminado que usa el SDK del servicio de trabajo es similar a la configuración
automática que se usa en una aplicación ASP.NET o ASP.NET Core, menos los enriquecedores de telemetría que
sirven para enriquecer la telemetría de HttpContext .
Puede personalizar el SDK de Application Insights para el servicio de trabajo para cambiar la configuración
predeterminada. Es posible que los usuarios de los SDK de Application Insights para ASP.NET estén
familiarizados con el cambio de configuración mediante el uso de la inserción de dependencias incorporada de
ASP.NET Core. El SDK de del servicio de trabajo también se basa en principios similares. Realice casi todos los
cambios de configuración en la sección ConfigureServices() mediante una llamada a los métodos adecuados
en IServiceCollection , tal como se detalla a continuación.
NOTE
Al usar este SDK, no se admite el cambio de la configuración mediante la modificación de
TelemetryConfiguration.Active y los cambios no se reflejan.
Uso de ApplicationInsightsServiceOptions
Puede modificar algunos ajustes de configuración comunes pasando de ApplicationInsightsServiceOptions a
AddApplicationInsightsTelemetryWorkerService , como se muestra en este ejemplo:
using Microsoft.ApplicationInsights.WorkerService;

{
Microsoft.ApplicationInsights.WorkerService.ApplicationInsightsServiceOptions aiOptions
= new Microsoft.ApplicationInsights.WorkerService.ApplicationInsightsServiceOptions();
// Disables adaptive sampling.
// Disables QuickPulse (Live Metrics stream).

aiOptions.EnableQuickPulseMetricStream = false;
services.AddApplicationInsightsTelemetryWorkerService(aiOptions);
}
Tenga en cuenta que en este SDK está en el espacio de nombres

ApplicationInsightsServiceOptions
Microsoft.ApplicationInsights.WorkerService en lugar de en
Microsoft.ApplicationInsights.AspNetCore.Extensions en el SDK de ASP.NET Core.
Configuraciones que se suelen usar en ApplicationInsightsServiceOptions
EnableQuickPulseMetricStream Habilitar o deshabilitar la característica true

LiveMetrics
EnableAdaptiveSampling Habilitar o deshabilitar el muestreo true

adaptable
EnableHeartbeat Habilitar o deshabilitar la característica true

de latidos, que periódicamente (cada
15 minutos de forma predeterminada)
envía una métrica personalizada
denominada "HeartBeatState" con
información sobre el entorno de
ejecución, por ejemplo, la versión de
.NET, información del entorno de
Azure, si procede, etc.
AddAutoCollectedMetricExtractor Habilitar o deshabilitar el extractor de true

AutoCollectedMetrics, que es un
elemento TelemetryProcessor que
envía métricas previamente agregadas
sobre las solicitudes o dependencias
antes de que tenga lugar el muestreo.
Consulte los valores configurables en ApplicationInsightsServiceOptions para obtener la lista más actualizada.
muestreo
El SDK de Application Insights para el servicio de trabajo admite el muestreo adaptable y el de tipo fijo. El
muestreo adaptable está habilitado de forma predeterminada. La configuración del muestreo para el servicio
de trabajo se realiza de la misma manera que para las aplicaciones ASP.NET Core.
Adición de TelemetryInitializers
Use inicializadores de telemetría cuando quiera definir propiedades para que se envíen con toda la telemetría.
Agregue cualquier TelemetryInitializer nuevo al contenedor DependencyInjection y el SDK lo agregará
automáticamente a TelemetryConfiguration .
using Microsoft.ApplicationInsights.Extensibility;

{
services.AddSingleton<ITelemetryInitializer, MyCustomTelemetryInitializer>();
}
Eliminación de Telemetryinitializer
Los inicializadores de telemetría están presentes de forma predeterminada. Para quitar todos los inicializadores
de telemetría o solo algunos específicos, use el siguiente código de ejemplo después de llamar a
AddApplicationInsightsTelemetryWorkerService() .

{
// Remove a specific built-in telemetry initializer
var tiToRemove = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType ==
typeof(AspNetCoreEnvironmentTelemetryInitializer));
if (tiToRemove != null)
{
services.Remove(tiToRemove);
}
// Remove all initializers

// This requires importing namespace by using Microsoft.Extensions.DependencyInjection.Extensions;
services.RemoveAll(typeof(ITelemetryInitializer));
}
Adición de procesadores de telemetría

Puede agregar procesadores de telemetría personalizados a TelemetryConfiguration mediante el método de
extensión AddApplicationInsightsTelemetryProcessor en IServiceCollection . Puede usar los procesadores de
telemetría en escenarios de filtrado avanzado para permitir un control más directo sobre lo que se incluirá o
excluirá de la telemetría que envía al servicio Application Insights. Use el ejemplo siguiente.
{
services.AddApplicationInsightsTelemetryProcessor<MyFirstCustomTelemetryProcessor>();
services.AddApplicationInsightsTelemetryProcessor<MySecondCustomTelemetryProcessor>();
}
Configuración o eliminación de objetos TelemetryModules predeterminados

Application Insights usa módulos de telemetría para recopilar automáticamente información de telemetría
sobre cargas de trabajo específicas sin necesidad de seguimiento manual.
Los siguientes módulos de recopilación automática están habilitados de forma predeterminada. Estos módulos
son responsables de recopilar automáticamente datos de telemetría. Puede deshabilitarlos o configurarlos para
modificar su comportamiento predeterminado.
DependencyTrackingTelemetryModule
PerformanceCollectorModule
QuickPulseTelemetryModule
AppServicesHeartbeatTelemetryModule - (Actualmente hay un problema relacionado con este módulo de
telemetría. Para obtener una solución temporal, consulte el problema de GitHub 1689).
AzureInstanceMetadataTelemetryModule
Para configurar cualquier objeto TelemetryModule predeterminado, use el método de la extensión

ConfigureTelemetryModule<T> en IServiceCollection , como se muestra en el ejemplo siguiente.
using Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse;

{
// The following configures QuickPulseTelemetryModule.

// Similarly, any other default modules can be configured.
services.ConfigureTelemetryModule<QuickPulseTelemetryModule>((module, o) =>
{
module.AuthenticationApiKey = "keyhere";
});
// The following removes PerformanceCollectorModule to disable perf-counter collection.

// Similarly, any other default modules can be removed.
var performanceCounterService = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(PerformanceCollectorModule));
if (performanceCounterService != null)
{
services.Remove(performanceCounterService);
}
}
Configuración del canal de telemetría

El canal predeterminado es ServerTelemetryChannel . Puede invalidarlo tal como se muestra en el ejemplo
siguiente.

{
// Use the following to replace the default channel with InMemoryChannel.
// This can also be applied to ServerTelemetryChannel.
services.AddSingleton(typeof(ITelemetryChannel), new InMemoryChannel() {MaxTelemetryBufferCapacity
= 19898 });
}
Deshabilitar la telemetría dinámicamente

Si desea deshabilitar la telemetría condicional y dinámicamente, puede resolver la instancia
TelemetryConfiguration con el contenedor de inyección de dependencias de ASP.NET Core en cualquier parte
del código y establecer DisableTelemetry como marca.

{
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration

configuration)
{
configuration.DisableTelemetry = true;
...
}

¿Cómo puedo realizar un seguimiento de la telemetría que se recopila automáticamente?
Obtenga una instancia de TelemetryClient mediante el uso de la inserción del constructor y llame al método
TrackXXX() necesario que incluye. No se recomienda crear instancias de TelemetryClient . Una instancia
singleton de TelemetryClient ya está registrada en el contenedor DependencyInjection , que comparte
TelemetryConfiguration con el resto de los datos de telemetría. Se recomienda crear una nueva instancia
TelemetryClient solo si se necesita una configuración independiente del resto de los datos de telemetría.
¿Puedo usar el IDE de Visual Studio para incorporar Application Insights a un proyecto de servicio de
trabajo?
La incorporación del IDE de Visual Studio se admite actualmente solo para aplicaciones ASP.NET/ASP.NET Core.
Este documento se actualizará cuando Visual Studio ofrezca compatibilidad con las aplicaciones de servicio de
trabajo de incorporación.
¿Puedo habilitar la supervisión de Application Insights con herramientas como Monitor de estado?
No. Monitor de estado y Monitor de estado v2 actualmente solo son compatibles con ASP.NET 4.x.
Si ejecuto mi aplicación en Linux, ¿se admiten todas las características?
Sí. La compatibilidad de características para el SDK es la misma en todas las plataformas, con las siguientes
excepciones:
Los contadores de rendimiento solo se admiten en Windows, con la excepción de CPU o memoria de
procesos que se muestran en Live Metrics.
Aunque el objeto ServerTelemetryChannel está habilitado de forma predeterminada, si la aplicación se
ejecuta en Linux o MacOS, el canal no crea automáticamente una carpeta de almacenamiento local para
mantener los datos de telemetría temporalmente si hay problemas de red. Debido a esta limitación, la
telemetría se pierde cuando hay problemas temporales de red o del servidor. Para solucionar este problema,
configure una carpeta local para el canal:

{
// The following will configure the channel to use the given folder to temporarily
// store telemetry items during network or Application Insights server issues.
// User should ensure that the given folder already exists
// and that the application has read/write permissions.
services.AddSingleton(typeof(ITelemetryChannel),
new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
}
Aplicaciones de ejemplo
Aplicación de consola .NET Core: use este ejemplo si usa una aplicación de consola escrita en .NET Core
(versión 2.0 o posterior) o .NET Framework (versión 4.7.2 o posterior).
Tareas en segundo plano de ASP.NET Core con HostedServices: use este ejemplo si está en ASP.NET Core
2.1/2.2 y cree tareas en segundo plano según la orientación oficial que se muestra aquí.
Servicio de trabajo .NET Core 3.0: use este ejemplo si tiene una aplicación de servicio de trabajo .NET Core 3.0
según las instrucciones oficiales que se muestran aquí.

Lectura y contribución al código.
Pasos siguientes
Use la API para enviar sus propios eventos y métricas para obtener una vista detallada del rendimiento y del
uso de la aplicación.
Realice el seguimiento de las dependencias adicionales cuyo seguimiento no se realiza automáticamente.
Enriquezca o filtre la telemetría recopilada automáticamente.
Inserción de dependencias en ASP.NET Core.
Application Insights para aplicaciones de consola
.NET
Application Insights permite supervisar la disponibilidad, el rendimiento y el uso de una aplicación web.
Necesita una suscripción a Microsoft Azure. Inicie sesión con una cuenta Microsoft, que podría tener para
Windows, Xbox Live u otros servicios en la nube de Microsoft. Si su equipo tiene una suscripción organizativa a
Azure, el propietario puede agregarle a esta con la cuenta de Microsoft.
NOTE
Es muy recomendable utilizar el paquete de Microsoft.ApplicationInsights.WorkerService y las instrucciones asociadas que se
especifican aquí para cualquier aplicación de consola. Este paquete va dirigido a NetStandard2.0 y, por lo tanto, se puede
usar en .NET Core 2.1 o una versión posterior, y .NET Framework 4.7.2 o una versión posterior.
Introducción
En Azure Portal, cree un recurso de Application Insights. Para el tipo de aplicación, elija General .
Realice una copia de la clave de instrumentación. Busque la clave en la lista desplegable Essentials del recurso
que creó.
Instale el paquete Microsoft.ApplicationInsights más reciente.
Establezca la clave de instrumentación en el código antes de hacer el seguimiento de cualquier telemetría (o
establezca la variable de entorno APPINSIGHTS_INSTRUMENTATIONKEY). Después de eso, debe ser capaz de
hacer un seguimiento manual de la telemetría y verla en Azure Portal
// you may use different options to create configuration as shown later in this article
TelemetryConfiguration configuration = TelemetryConfiguration.CreateDefault();
configuration.InstrumentationKey = " *your key* ";
var telemetryClient = new TelemetryClient(configuration);
telemetryClient.TrackTrace("Hello World!");
NOTE
Los datos de telemetría no se envían al instante. Los elementos de telemetría se procesan por lotes y se envían mediante el
SDK de ApplicationInsights. En las aplicaciones de consola, que se cierran justo después de llamar a los métodos Track() ,
es posible que no se envíen los datos de telemetría a menos que Flush() y Sleep / Delay se completen antes de que se
cierre la aplicación, tal como se muestra en el ejemplo completo más adelante en este artículo. Sleep no es necesario si usa
InMemoryChannel . Hay un problema activo relacionado con la necesidad de Sleep cuyo seguimiento se realiza aquí:
ApplicationInsights-dotnet/issues/407
Instale la versión más reciente de Microsoft.ApplicationInsights.DependencyCollector, que hace

automáticamente un seguimiento de HTTP, SQL o algunas llamadas de dependencias externas.
Puede inicializar y configurar Application Insights desde el código o con el archivo ApplicationInsights.config .
Asegúrese de que la inicialización se realice tan pronto como sea posible.
NOTE
Las instrucciones referentes a ApplicationInsights.config solo son aplicables a las aplicaciones que tienen como destino
.NET Framework, y no se aplican a las aplicaciones de .NET Core.
Uso del archivo de configuración

De manera predeterminada, el SDK de Application Insights busca el archivo ApplicationInsights.config en el
directorio de trabajo cuando se crea TelemetryConfiguration
TelemetryConfiguration config = TelemetryConfiguration.Active; // Reads ApplicationInsights.config file if

present
También puede especificar la ruta de acceso al archivo de configuración.
using System.IO;
TelemetryConfiguration configuration =
TelemetryConfiguration.CreateFromConfiguration(File.ReadAllText("C:\\ApplicationInsights.config"));
Para más información, consulte la referencia del archivo de configuración.

Puede obtener un ejemplo completo del archivo de configuración mediante la instalación de la versión más
reciente del paquete Microsoft.ApplicationInsights.WindowsServer. Esta es la configuración mínima para la
colección de dependencias que es equivalente al ejemplo de código.

<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<InstrumentationKey>Your Key</InstrumentationKey>
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.HttpDependenciesParsingTelemetryInitializer,
Microsoft.AI.DependencyCollector"/>
</TelemetryInitializers>
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule,
Microsoft.AI.DependencyCollector">
<ExcludeComponentCorrelationHttpHeadersOnDomains>
<Add>core.windows.net</Add>
<Add>core.chinacloudapi.cn</Add>
<Add>core.cloudapi.de</Add>
<Add>core.usgovcloudapi.net</Add>
<Add>localhost</Add>
<Add>127.0.0.1</Add>
</ExcludeComponentCorrelationHttpHeadersOnDomains>
<IncludeDiagnosticSourceActivities>
<Add>Microsoft.Azure.ServiceBus</Add>
<Add>Microsoft.Azure.EventHubs</Add>
</IncludeDiagnosticSourceActivities>
</Add>
</TelemetryModules>
<TelemetryChannel Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
Microsoft.AI.ServerTelemetryChannel"/>
Configuración de la colección de telemetría a partir del código

NOTE
La lectura del archivo de configuración no se admite en .NET Core. Puede plantearse la posibilidad de usar el SDK de
Application Insights para ASP.NET Core
Durante el inicio de la aplicación, cree y configure la instancia DependencyTrackingTelemetryModule , que debe ser
singleton y se debe conservar por toda la duración de la aplicación.
var module = new DependencyTrackingTelemetryModule();
// prevent Correlation Id to be sent to certain endpoints. You may add other domains as needed.
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.windows.net");
//...
// enable known dependency tracking, note that in future versions, we will extend this list.
// please check default settings in https://github.com/Microsoft/ApplicationInsights-dotnet-
server/blob/develop/Src/DependencyCollector/DependencyCollector/ApplicationInsights.config.install.xdt
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.ServiceBus");
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.EventHubs");
//....
// initialize the module

module.Initialize(configuration);
Agregue inicializadores de telemetría comunes
// ensures proper DependencyTelemetry.Type is set for Azure RESTful API calls

configuration.TelemetryInitializers.Add(new HttpDependenciesParsingTelemetryInitializer());
Si ha creado la configuración con un constructor TelemetryConfiguration() sin formato, es preciso que también
habilite la compatibilidad con la correlación. No es necesario si lee configuración de un archivo, se usan
TelemetryConfiguration.CreateDefault() o TelemetryConfiguration.Active .
configuration.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());
También puede instalar e inicializar el módulo de recopilador Contador de rendimiento, como se describeaquí
Ejemplo completo
using Microsoft.ApplicationInsights.DependencyCollector;
namespace ConsoleApp
{
class Program
{
{
configuration.InstrumentationKey = "removed";
configuration.TelemetryInitializers.Add(new HttpDependenciesParsingTelemetryInitializer());

using (InitializeDependencyTracking(configuration))
{
{
// run app...
telemetryClient.TrackTrace("Hello World!");
using (var httpClient = new HttpClient())

{
// Http dependency is automatically tracked!
httpClient.GetAsync("https://microsoft.com").Wait();
}
// before exit, flush the remaining data

// flush is not blocking when not using InMemoryChannel so wait a bit. There is an active issue
regarding the need for `Sleep`/`Delay`
// which is tracked here: https://github.com/microsoft/ApplicationInsights-dotnet/issues/407
static DependencyTrackingTelemetryModule InitializeDependencyTracking(TelemetryConfiguration

configuration)
{
var module = new DependencyTrackingTelemetryModule();
// prevent Correlation Id to be sent to certain endpoints. You may add other domains as needed.
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.windows.net");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.chinacloudapi.cn");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.cloudapi.de");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("core.usgovcloudapi.net");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("localhost");
module.ExcludeComponentCorrelationHttpHeadersOnDomains.Add("127.0.0.1");
// enable known dependency tracking, note that in future versions, we will extend this list.
// please check default settings in https://github.com/microsoft/ApplicationInsights-dotnet-
server/blob/develop/WEB/Src/DependencyCollector/DependencyCollector/ApplicationInsights.config.install.xdt
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.ServiceBus");
module.IncludeDiagnosticSourceActivities.Add("Microsoft.Azure.EventHubs");
// initialize the module

module.Initialize(configuration);
return module;
}
}
}
Pasos siguientes
Supervise dependencias para ver si REST, SQL u otros recursos externos se están ralentizando.
Use la API para enviar sus propios eventos y métricas para obtener una vista más detallada del rendimiento y el
uso de la aplicación.
Inicio rápido: Introducción a Application Insights
en un proyecto web de Java
En este inicio rápido, se usa Application Insights para instrumentar automáticamente solicitudes, realizar
un seguimiento de dependencias y recopilar contadores de rendimiento, diagnosticar problemas de
rendimiento y excepciones y escribir código para realizar un seguimiento de lo que hacen los usuarios
con la aplicación.
Application Insights es un servicio de análisis extensible para desarrolladores web que ayuda a
comprender el rendimiento y el uso de la aplicación activa. Application Insights es compatible con
aplicaciones Java que se ejecutan en Linux, Unix o Windows.
Prerrequisitos
Una aplicación Java en funcionamiento.
Obtención de una clave de instrumentación de Application

Insights
2. En Azure Portal, cree un nuevo recurso de Application Insights. Establezca el tipo de aplicación a
una aplicación web de Java.
3. Busque la clave de instrumentación del nuevo recurso. Pronto tendrá que pegarla en el proyecto
de código.
Incorporación del SDK de Application Insights para Java al

proyecto
Elija el tipo de proyecto.
Maven
Gradle
Otros tipos
Si su proyecto ya se ha configurado para usar Maven para la compilación, combine el siguiente código
en el archivo pom.xml.
A continuación, actualice las dependencias del proyecto, para obtener los archivos binarios descargados.
<dependencies>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-web-auto</artifactId>


<version>2.5.0</version>
</dependency>
</dependencies>
Preguntas
¿Cuál es la relación entre los componentes -web-auto , -web y -core ?
applicationinsights-web-auto proporciona métricas que realizan el seguimiento de los
recuentos de solicitudes de servlet HTTP y los tiempos de respuesta, mediante el registro
automático del filtro de servlet de Application Insights en tiempo de ejecución.
applicationinsights-web también proporciona métricas que realizan el seguimiento de los
recuentos de solicitudes de servlet HTTP y los tiempos de respuesta, pero requiere el registro
manual del filtro de servlet de Application Insights en la aplicación.
applicationinsights-core solo proporciona la API básica, por ejemplo, si la aplicación no se
basa en servlet.
¿Cómo se debe actualizar el SDK a la versión más reciente?
Si usa Gradle o Maven...
Actualice el archivo de compilación para especificar la última versión.
Si va a administrar las dependencias manualmente...
Descargue el SDK más reciente de Application Insights para Java y sustituya los
antiguos. Los cambios se describen en las notas de la versión de SDK.
Adición de un archivo ApplicationInsights.xml

Agregue ApplicationInsights.xml a la carpeta de recursos del proyecto o asegúrese de que se agrega a la
ruta de acceso de la clase de implementación del proyecto. Copie en ella el siguiente XML.
Reemplace la clave de instrumentación por la que recibió de Azure Portal.
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings"
schemaVersion="2014-05-30">


<InstrumentationKey>** Your instrumentation key **</InstrumentationKey>

<TelemetryModules>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"
/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"
/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
</TelemetryModules>



<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitia
lizer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInit
ializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitialize
r"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/
>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitiali
zer"/>
Si lo desea, el archivo de configuración puede estar en cualquier ubicación a la que su aplicación tenga
acceso. La propiedad del sistema -Dapplicationinsights.configurationDirectory especifica el directorio
que contiene ApplicationInsights.xml. Por ejemplo, un archivo de configuración ubicado en
E:\myconfigs\appinsights\ApplicationInsights.xml se configuraría con la propiedad
-Dapplicationinsights.configurationDirectory="E:\myconfigs\appinsights" .
La clave de instrumentación se envía junto con todos los elementos de telemetría e indica a
Application Insights que se muestre en el recurso.
El componente de la solicitud HTTP es opcional. Envía automáticamente telemetría sobre las
solicitudes y tiempos de respuesta en el portal.
La correlación de eventos es una incorporación al componente de la solicitud HTTP. Asigna un
identificador a cada solicitud recibida por el servidor. A continuación, agrega este identificador como
una propiedad a todos los elementos de telemetría como la propiedad "Operation.Id". Le permite
correlacionar la telemetría asociada a cada solicitud estableciendo un filtro en la búsqueda de
diagnóstico.
Alternativas para establecer la clave de instrumentación
SDK de Application Insights busca la clave en este orden:
1. Propiedad del sistema: -DAPPINSIGHTS_INSTRUMENTATIONKEY=your_ikey
2. Variable de entorno: APPINSIGHTS_INSTRUMENTATIONKEY
3. Archivo de configuración: ApplicationInsights.xml
También se puede configurar en el código:
String instrumentationKey = "00000000-0000-0000-0000-000000000000";
if (instrumentationKey != null)
{
TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
}
Adición del agente

Instale el agente de Java para capturar llamadas HTTP salientes, consultas de JDBC y registros de
aplicaciones y mejorar la nomenclatura de las operaciones.
Ejecútela en modo de depuración en el equipo de desarrollo o bien publíquela en el servidor.
Visualización de la telemetría en Application Insights

Vuelva al recurso de Application Insights en el Portal de Microsoft Azure.
Los datos de las solicitudes HTTP aparecen en la hoja de información general. (Si todavía no está ahí,
espere unos segundos y, a continuación, haga clic en Actualizar).
Más información acerca de las métricas.

Haga clic en cualquier gráfico para ver métricas agregadas más detalladas.
Datos de instancia
Haga clic en un tipo de solicitud específico para ver las instancias individuales.
Análisis: Lenguaje de consulta eficaz

A medida que acumula más datos, puede ejecutar consultas tanto para agregar datos como para buscar
instancias individuales. Analytics es una eficaz herramienta tanto para conocer el rendimiento y el uso,
como para el diagnóstico.
Instalación de la aplicación en el servidor

Ahora puede publicar la aplicación en el servidor, dejar que la utilicen los usuarios y ver la telemetría en
el portal.
Asegúrese de que el firewall permite que la aplicación envíe datos de telemetría a estos puertos:
dc.services.visualstudio.com:443
f5.services.visualstudio.com:443
Si el tráfico saliente debe enrutarse a través de un firewall, defina las propiedades de sistema
http.proxyHost y http.proxyPort .
En los servidores de Windows, instale:

Microsoft Visual C++ Redistributable
(Este componente habilita los contadores de rendimiento.)
Configuración de Azure App Service (Spring Boot)

Las aplicaciones de Spring Boot que se ejecutan en Windows requieren configuración adicional para
ejecutarse en Azure App Services. Modifique web.config y agregue la siguiente configuración:
<?xml version="1.0" encoding="UTF-8"?>

<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler"
resourceType="Unspecified"/>
</handlers>
<httpPlatform processPath="%JAVA_HOME%\bin\java.exe" arguments="-
Djava.net.preferIPv4Stack=true -Dserver.port=%HTTP_PLATFORM_PORT% -jar
"%HOME%\site\wwwroot\AzureWebAppExample-0.0.1-SNAPSHOT.jar"">
</httpPlatform>
</system.webServer>
</configuration>
Excepciones y errores de solicitud

El filtro web de Application Insights recopila automáticamente las excepciones no controladas y las
solicitudes con error.
Para recopilar datos de otras excepciones, puede insertar llamadas a trackException() en el código.
Supervisión de llamadas a métodos y dependencias externas

Instale el agente de Java para registrar los métodos internos especificados y las llamadas realizadas a
través de JDBC, con datos de tiempo.
También sirve para la nomenclatura automática de las operaciones.
Seguimiento distribuido de W3C

El SDK de Java de Application Insights ahora admite el seguimiento distribuido de W3C.
La configuración del SDK de entrada se explica más en detalle en nuestro artículo sobre correlación.
La configuración del SDK de salida se define en el archivo AI-Agent.xml.
Abra Investigar y Métricas para ver un intervalo de contadores de rendimiento.
Personalizar la recopilación de contadores de rendimiento
Para deshabilitar la recopilación del conjunto estándar de contadores de rendimiento, agregue el
siguiente código bajo el nodo raíz del archivo ApplicationInsights.xml:
<UseBuiltIn>False</UseBuiltIn>
Recopilar contadores de rendimiento adicionales

Puede especificar contadores de rendimiento adicionales que se van a recopilar.
Contadores JMX (expuestos por la máquina virtual de Java)
<Jmx>
<Add objectName="java.lang:type=ClassLoading" attribute="TotalLoadedClassCount"
displayName="Loaded Class Count"/>
<Add objectName="java.lang:type=Memory" attribute="HeapMemoryUsage.used" displayName="Heap
Memory Usage-used" type="composite"/>
</Jmx>
displayName : el nombre mostrado en el portal de Application Insights.

objectName : el nombre del objeto JMX.
attribute : el atributo del nombre del objeto JMX que se va a capturar
type (opcional): el tipo del atributo del objeto JMX:
Valor predeterminado: un tipo simple como int o long.
composite : los datos del contador de rendimiento tienen el formato 'Attribute.Data'
tabular : los datos del contador de rendimiento tienen el formato de una fila de tabla
Contadores de rendimiento de Windows

Cada contador de rendimiento de Windows es un miembro de una categoría (de la misma manera que
un campo es un miembro de una clase). Las categorías puede ser globales, o pueden tener instancias
con nombre o numeradas.
<Windows>
<Add displayName="Process User Time" categoryName="Process" counterName="%User Time"
instanceName="__SELF__" />
<Add displayName="Bytes Printed per Second" categoryName="Print Queue" counterName="Bytes
Printed/sec" instanceName="Fax" />
</Windows>
displayName: el nombre mostrado en el portal de Application Insights.

categoryName: la categoría de contador de rendimiento (objeto de rendimiento) con la que está
asociada este contador de rendimiento.
counterName: el nombre del contador de rendimiento.
instanceName: el nombre de la instancia de categoría del contador de rendimiento o una cadena
vacía (""), si la categoría contiene una sola instancia. Si categoryName es Proceso, y el contador de
rendimiento que desea recopilar está en el proceso de JVM actual en que se ejecuta la aplicación,
especifique "__SELF__" .
Contadores de rendimiento de Unix
Instale collectd con el complemento de Application Insights para obtener una amplia variedad de
datos de red y del sistema.
Obtención de datos de usuario y sesión

Bien, va a enviar telemetría desde el servidor web. Ahora, para obtener la visión completa de 360 grados
de la aplicación, puede agregar mayor supervisión:
Agregue telemetría a las páginas web para supervisar las vistas de páginas y las métricas de usuario.
Configure las pruebas web para comprobar que la aplicación efectivamente está activa y responde
adecuadamente.
Envío de su propia telemetría

Ahora que ha instalado el SDK, puede utilizar la API para enviar su propia telemetría.
Realice el seguimiento de eventos y métricas personalizados para saber qué hacen los usuarios con
su aplicación.
Busque eventos y registros para ayudar a diagnosticar problemas.
Pruebas web de disponibilidad

Application Insights puede probar su sitio web a intervalos regulares para comprobar que está activo y
que responde correctamente.
Obtenga más información sobre cómo configurar las pruebas web de disponibilidad.
¿Tiene preguntas? ¿Tiene problemas?

Solución de problemas de Java
Pasos siguientes
Supervisión de llamadas a dependencias
Supervisión de contadores de rendimiento de Unix
Incorporación de la supervisión a las páginas web para controlar los tiempos de carga, las llamadas
de AJAX y la excepciones del explorador.
Escritura de una telemetría personalizada para hacer un seguimiento del uso en el explorador o el
servidor.
Uso de Analytics para realizar consultas eficaces sobre los datos de telemetría de la aplicación
Para más información, visite Azure para desarrolladores de Java.
Supervisar aplicaciones de Docker en Application
Insights (en desuso)
NOTE
Esta solución está en desuso. Para más información sobre nuestras inversiones actuales en la supervisión de contenedores, se
recomienda comprobar Azure Monitor para contenedores.
Los eventos de ciclo de vida y los contadores de rendimiento de los contenedores Docker pueden mostrarse en
gráficos en Application Insights. Instale la imagen de Application Insights en un contenedor del host y se mostrarán
los contadores de rendimiento del host, así como de las demás imágenes.
Con Docker, distribuye sus aplicaciones en contenedores ligeros junto con todas las dependencias. Estos
contenedores se ejecutan en cualquier equipo host que ejecute un motor Docker.
Al ejecutar la imagen de Application Insights en el host Docker, obtendrá estas ventajas:
Telemetría del ciclo de vida sobre todos los contenedores que se ejecutan en el host: start, stop, etc.
Contadores de rendimiento de todos los contenedores. CPU, memoria, uso de red y mucho más.
Si instaló el SDK de Application Insights en las aplicaciones que se ejecutan en los contenedores, toda la
telemetría de dichas aplicaciones tendrán propiedades adicionales que identifiquen el contenedor y el equipo
host. De esta forma, si tiene, por ejemplo, instancias de una aplicación que se ejecuta en más de un host, podrá
filtrar fácilmente los datos de telemetría de la aplicación en función del host.
Configurar el recurso de Application Insights

1. Inicie sesión en Microsoft Azure Portal y abra el recurso de Application Insights de la aplicación; o cree uno
nuevo.
¿Qué recurso debería usar? Si las aplicaciones que se ejecutan en el host las desarrolló otra persona, deberá
crear un nuevo recurso de Application Insights. Es el sitio donde verá y analizará los datos de telemetría.
Seleccione General para el tipo de aplicación.
Pero si usted es el desarrollador de las aplicaciones, esperamos que haya agregado el SDK de Application
Insights a cada una de ellas. Si todos son realmente componentes de una aplicación empresarial única,
puede configurarlas todas para que envíen telemetría a un recurso y usará ese mismo recurso para mostrar
los datos de rendimiento y de ciclo de vida de Docker.
Un tercer escenario es que haya desarrollado la mayoría de las aplicaciones, pero use recursos
independientes para mostrar sus datos de telemetría. En ese caso, probablemente también querrá crear un
recurso independiente para los datos de Docker.
2. Haga clic en la lista desplegable Essentials y copie la clave de instrumentación. Se usará para indicar al SDK
dónde puede enviar sus datos de telemetría.
Tenga a mano la ventana del explorador, volverá a ella pronto para examinar los datos de telemetría.
Ejecutar la supervisión de Application Insights en el host

Ahora que tiene un lugar donde mostrar los datos de telemetría, puede configurar la aplicación del contenedor que
los recopilará y enviará.
1. Conéctese al host Docker.
2. Edite la clave de instrumentación de este comando y después ejecútelo:
docker run -v /var/run/docker.sock:/docker.sock -d microsoft/applicationinsights ikey=000000-1111-2222-

3333-444444444
Solo es necesaria una imagen de Application Insights por cada host de Docker. Si la aplicación se implementa en
varios hosts de Docker, repita el comando en todos los hosts.
Actualización de la aplicación
Si la aplicación se instrumenta con el SDK de Application Insights para Java <TelemetryInitializers> , agregue la
siguiente línea en el archivo ApplicationInsights.xml del proyecto, en el elemento :
<Add type="com.microsoft.applicationinsights.extensibility.initializer.docker.DockerContextInitializer"/>
Esto agrega información de Docker como el contenedor y el identificador de host a cada uno de los elementos de
telemetría que se envían desde la aplicación.
Visualización de la telemetría
Vuelva al recurso de Application Insights en el Portal de Azure.
Haga clic en el icono de Docker.
Pronto verá que llegan datos desde la aplicación de Docker, especialmente si tiene otros contenedores que se
ejecutan en el motor de Docker.
Eventos de contenedor Docker
Para investigar eventos individuales, haga clic en Buscar. Busque y filtre para encontrar los eventos deseados. Haga
clic en cualquier evento para más detalles.
Excepciones por el nombre del contenedor
Contexto de Docker agregado a los datos de telemetría de la aplicación
Los datos de telemetría de solicitud enviados desde la aplicación instrumentada con el SDK de AI están
enriquecidos con la información de contexto de Docker.
Preguntas y respuestas
¿Qué me da Application Insights que no me dé Docker?
Desglose detallado de los contadores de rendimiento por contenedor e imagen.
Integración de datos de contenedores y aplicaciones en un panel.
Exportación de la telemetría , para su análisis posterior en una base de datos, Power BI u otro panel.
¿Cómo se obtienen datos de telemetría de la propia aplicación?
Instale el SDK de Application Insights en la aplicación. Más información sobre: aplicaciones web de Java y
aplicaciones web de Windows.
Vídeo
Pasos siguientes
Application Insights para Java
Application Insights para Node.js
Application Insights para ASP.NET
Exploración de los registros de seguimiento de Java
en Application Insights
Si está usando Logback o Log4J (v1.2 o v2.0) para el seguimiento, los registros de seguimiento se pueden enviar
automáticamente a Application Insights, donde puede explorarlos y buscar en ellos.
TIP
Solo tiene que establecer la clave de instrumentación de Application Insights una vez para la aplicación. Si usa una
plataforma como Java Spring, es posible que ya haya registrado la clave en otra parte de la configuración de la aplicación.
Uso del agente de Java de Application Insights

De forma predeterminada, el agente de Java de Application Insights captura automáticamente el registro
realizado en el nivel WARN y superiores.
Puede cambiar el umbral de registro capturado mediante el archivo AI-Agent.xml :

<ApplicationInsightsAgent>
<Instrumentation>
<BuiltIn>
<Logging threshold="info"/>
</BuiltIn>
</Instrumentation>
</ApplicationInsightsAgent>
Puede deshabilitar la captura de registro del agente de Java mediante el archivo AI-Agent.xml :

<Instrumentation>
<BuiltIn>
<Logging enabled="false"/>
</BuiltIn>
</Instrumentation>
También puede seguir las instrucciones que se indican a continuación

(en lugar de usar el agente de Java)
Instalación del SDK de Java
Siga las instrucciones para instalar el SDK de Application Insights para Java, si aún no lo ha hecho.
Incorporación de bibliotecas de registro al proyecto
Elija la forma adecuada para su proyecto.
Si está usando Maven...
Si su proyecto ya se ha configurado para usar Maven para la compilación, combine uno de los siguientes
fragmentos de código en el archivo pom.xml.
Logback
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-logback</artifactId>
<version>[2.0,)</version>
</dependency>
</dependencies>
Log4J v2.0
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-log4j2</artifactId>
</dependency>
</dependencies>
Log4J v1.2
<dependencies>
<dependency>
<artifactId>applicationinsights-logging-log4j1_2</artifactId>
</dependency>
</dependencies>
Si está usando Gradle...

Si el proyecto ya se ha configurado para usar Gradle para la compilación, agregue una de las líneas siguientes al
grupo dependencies en el archivo build.gradle.
Logback
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-logback', version: '2.0.+'
Log4J v2.0
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j2', version: '2.0.+'
Log4J v1.2
compile group: 'com.microsoft.azure', name: 'applicationinsights-logging-log4j1_2', version: '2.0.+'
De lo contrario...
Siga las instrucciones para instalar manualmente el SDK de Java de Application Insights, descargar el archivo JAR
(tras llegar a la página central de Maven, haga clic en el vínculo "jar" en la sección de descarga) para el appender
adecuado y agregar al proyecto el archivo JAR del appender descargado.
REGIST RA DO R DESC A RGA R B IB L IOT EC A
Logback JAR del appender de Logback applicationinsights-logging-logback
Log4J v2.0 JAR del appender de Log4J v2 applicationinsights-logging-log4j2
Log4J v1.2 JAR del appender de Log4J v1.2 applicationinsights-logging-log4j1_2
Incorporación del appender el marco de registro

Para empezar a recibir los seguimientos, combine el fragmento de código relevante al archivo de configuración
Log4J o Logback:
Logback
<appender name="aiAppender"
class="com.microsoft.applicationinsights.logback.ApplicationInsightsAppender">
<instrumentationKey>[APPLICATION_INSIGHTS_KEY]</instrumentationKey>
</appender>
<root level="trace">
<appender-ref ref="aiAppender" />
</root>
Log4J v2.0
<Configuration packages="com.microsoft.applicationinsights.log4j.v2">
<Appenders>
<ApplicationInsightsAppender name="aiAppender" instrumentationKey="[APPLICATION_INSIGHTS_KEY]" />
</Appenders>
<Loggers>
<Root level="trace">
<AppenderRef ref="aiAppender"/>
</Root>
</Loggers>
</Configuration>
Log4J v1.2
<appender name="aiAppender"
class="com.microsoft.applicationinsights.log4j.v1_2.ApplicationInsightsAppender">
<param name="instrumentationKey" value="[APPLICATION_INSIGHTS_KEY]" />
</appender>
<root>
<priority value ="trace" />
<appender-ref ref="aiAppender" />
</root>
Los appenders de Application Insights pueden hacer referencia a cualquier registrador configurado y no
necesariamente por el registrador de raíz (como se muestra en los ejemplos de código anteriores).
En el portal de Application Insights, explore los seguimientos.

Ahora que ha configurado el proyecto para enviar el seguimiento a Application Insights, puede ver y buscar estos
seguimientos en el portal de Application Insights, en la hoja Búsqueda.
Las excepciones enviadas a través de registradores se mostrarán en el portal como telemetría de excepciones.
Pasos siguientes
Búsqueda de diagnóstico
collectd: métricas de rendimiento de Linux en
Para explorar las métricas de rendimiento del sistema de Linux en Application Insights, instale collectd junto con
su complemento Application Insights. Esta solución de código abierto recopila diversas estadísticas de red y del
sistema.
Normalmente, usará collectd si ya ha instrumentado el servicio web de Java con Application Insights. Así
obtendrá más datos para ayudarlo a mejorar el rendimiento de la aplicación o a diagnosticar los problemas.
Obtención de la clave de instrumentación

En Microsoft Azure Portal, abra el recurso Application Insights donde desea que aparezcan los datos. (o bien,
cree un nuevo recurso).
Realice una copia de la clave de instrumentación, que identifica al recurso.
Instalación de collectd y del complemento

En los equipos de servidor Linux:
1. Instale la versión de collectd 5.4.0 o posterior.
2. Descargue el complemento del escritor collectd de Application Insights. Anote el número de versión.
3. Copie el archivo JAR del complemento en /usr/share/collectd/java .
4. Edite /etc/collectd/collectd.conf :
Asegúrese de que el complemento de Java está habilitado.
Actualice el elemento JVMArg para que java.class.path incluya el archivo JAR siguiente. Actualice el
número de versión para que coincida con el que descargó:
/usr/share/collectd/java/applicationinsights-collectd-1.0.5.jar
Agregue este fragmento de código con la clave de instrumentación del recurso:
LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
<Plugin ApplicationInsightsWriter>
InstrumentationKey "Your key"
</Plugin>
A continuación se muestra un archivo de configuración de ejemplo:

...
# collectd plugins
LoadPlugin cpu
LoadPlugin disk
LoadPlugin load
...
# Enable Java Plugin

LoadPlugin "java"
# Configure Java Plugin

<Plugin "java">
JVMArg "-verbose:jni"
JVMArg "-Djava.class.path=/usr/share/collectd/java/applicationinsights-collectd-
1.0.5.jar:/usr/share/collectd/java/collectd-api.jar"
# Enabling Application Insights plugin

LoadPlugin "com.microsoft.applicationinsights.collectd.ApplicationInsightsWriter"
# Configuring Application Insights plugin

<Plugin ApplicationInsightsWriter>
InstrumentationKey "12345678-1234-1234-1234-123456781234"
</Plugin>
# Other plugin configurations ...

...
</Plugin>
...
Configure otros complementos de collectdque pueden recopilar diversos datos de orígenes diferentes.
Reinicie collectd según su manual.
Visualización de los datos en Application Insights

En el recurso de Application Insights, abra Métricas y agregue gráficos. Para ello, seleccione las métricas que
quiere ver en la categoría Personalizado.
De forma predeterminada, las métricas se agregan en todos los equipos host desde los que se recopilaron
estas. Para ver las métricas por host, en la hoja Detalles del gráfico, active Agrupación y elija Agrupar por
CollectD-Host.
Para excluir la carga de estadísticas específicas

De forma predeterminada, el complemento de Application Insights envía todos los datos recopilados por todos
los complementos de lectura de collectd habilitados.
Para excluir los datos de orígenes de datos o complementos específicos:
Edite el archivo de configuración.
En <Plugin ApplicationInsightsWriter> , agregue líneas de directiva de esta manera:
DIREC T IVA EF EC TO
Exclude disk Excluir todos los datos recopilados por el complemento

disk
Exclude disk:read,write Excluir los orígenes denominados read y write del

complemento disk .
Separar directivas con una nueva línea.
¿Tiene problemas?
No veo datos en el portal
Abra Buscar para ver si han llegado los eventos sin procesar. A veces tardan más en aparecer en el
Es posible que deba establecer excepciones del firewall para los datos salientes
Habilite el seguimiento en el complemento Application Insights. Agregue esta línea en
<Plugin ApplicationInsightsWriter> :
SDKLogger true
Abra un terminal e inicie collectd en modo detallado para ver cualquier problema que esté notificando:
sudo collectd -f
Problema conocido
El complemento de escritura de Application Insights es incompatible con determinados complementos de
lectura. Algunos complementos envían a veces "NaN" donde el complemento de Application Insights espera un
número de punto flotante.
Síntoma: el registro recopilado muestra errores que incluyen "AI:... SyntaxError: token inesperado N".
Solución alternativa: excluir los datos recopilados por los complementos de escritura con problemas.
Supervisión de dependencias, excepciones
detectadas y tiempos de ejecución del método en
aplicaciones web de Java
Si ha instrumentado la aplicación web de Java con Application Insights, puede usar el agente de Java para
obtener información más clara, sin tener que realizar cambios de código:
Dependencias: datos sobre las llamadas realizadas por la aplicación a otros componentes, por
ejemplo:
Se capturan las llamadas HTTP salientes realizadas a través de Apache HttpClient, OkHttp y
java.net.HttpURLConnection .
Se capturan las llamadas Redis realizadas a través del cliente de Jedis.
Consultas JDBC : en el caso de MySQL y PostgreSQL, si la llamada tarda más de 10 segundos, el
agente notifica el plan de consulta.
Registro de aplicaciones : puede capturar y poner en correlación los registros de aplicaciones con
solicitudes HTTP y otra telemetría.
Log4j 1.2
Log4j2
Logback
Nomenclatura mejorada para las opciones : (se usa para la agregación de solicitudes en el portal).
Spring : se basa en @RequestMapping .
JAX-RS : se basa en @Path .
Para usar el agente de Java, debe instalarlo en el servidor. Las aplicaciones web deben instrumentarse con el
SDK de Application Insights para Java.
Instalación del agente de Application Insights para Java

1. Descargue el agenteen la máquina que ejecuta el servidor de Java. Asegúrese de descargar la misma
versión del agente de Java que los paquetes web y principales del SDK de Application Insights para
Java.
2. Edite el script de inicio del servidor de aplicaciones y agregue el siguiente argumento de JVM:
-javaagent:<full path to the agent JAR file>
Por ejemplo, en Tomcat en un equipo Linux:

export JAVA_OPTS="$JAVA_OPTS -javaagent:<full path to agent JAR file>"
3. Reinicie el servidor de aplicaciones.
Configuración del agente

Cree un archivo denominado AI-Agent.xml y colóquelo en la misma carpeta que el archivo JAR del agente.
Establezca el contenido del archivo XML. Edite el ejemplo siguiente para incluir u omitir las características que
desee.

<Instrumentation>
<BuiltIn enabled="true">

<Logging enabled="true" />

<HTTP enabled="true" />


<JDBC enabled="true" />


<Jedis enabled="true" />

<MaxStatementQueryLimitInMS>1000</MaxStatementQueryLimitInMS>
</BuiltIn>
</Instrumentation>
Configuración adicional (Spring Boot)

java -javaagent:/path/to/agent.jar -jar path/to/TestApp.jar
Para Azure App Service, haga lo siguiente:

Seleccione Configuración > Configuración de la aplicación.
En Configuración de la aplicación, agregue un nuevo par clave-valor:
Clave: JAVA_OPTS Valor: -javaagent:D:/home/site/wwwroot/applicationinsights-agent-2.5.0.jar
Para conocer la última versión del agente de Java, consulte aquí las versiones.
El agente debe estar empaquetado como un recurso en el proyecto de forma que termine en el directorio
D:/home/site/wwwroot/. Para confirmar que el agente está en el directorio correcto de App Service, vaya a
Herramientas de desarrollo > Herramientas avanzadas > Consola de depuración y examine el
contenido del directorio del sitio.
Guarde la configuración y reinicie la aplicación. (Estos pasos solo se aplican a las instancias de App
Services que se ejecutan en Windows).
NOTE
AI-Agent.xml y el archivo jar del agente deben estar en la misma carpeta. A menudo se colocan juntos en la carpeta
/resources del proyecto.
Habilitación del seguimiento distribuido de W3C

Agregue lo siguiente al archivo AI-Agent.xml:
<Instrumentation>
<HTTP enabled="true" W3C="true" enableW3CBackCompat="true"/>
</BuiltIn>
</Instrumentation>
NOTE
El modo de compatibilidad con versiones anteriores está habilitado de forma predeterminada, y el parámetro
enableW3CBackCompat es opcional y debe usarse solo cuando quiera desactivarlo.
Lo ideal sería cuando todos los servicios se han actualizado a la versión más reciente de los SDK compatibles
con el protocolo W3C. Se recomienda encarecidamente pasar a la versión más reciente de los SDK con
compatibilidad con W3C lo antes posible.
Asegúrese de que las configuraciones (del agente) tanto entrantes como salientes sean exactamente
iguales.
Visualización de los datos

En el recurso de Application Insights, aparecen tiempos de ejecución agregados de métodos y dependencias
remotos en el icono Rendimiento.
Para buscar instancias individuales de informes de dependencia, excepción y método, abra Buscar.
Más información sobre diagnósticos de problemas de dependencia.
¿Tiene preguntas? ¿Tiene problemas?

¿No hay datos? Establecer excepciones del firewall
Solución de problemas de Java
Filtrado de telemetría en la aplicación web de Java
Los filtros proporcionan una manera de seleccionar la telemetría que su aplicación web de Java envía a
Application Insights. Hay algunos filtros de serie que puede utilizar y también puede escribir sus propios filtros
personalizados.
Los filtros de serie incluyen:
El nivel de gravedad del seguimiento
Direcciones URL específicas, palabras clave o códigos de respuesta
Respuestas rápidas, es decir, las solicitudes a las que la aplicación responde rápidamente
Nombres de eventos específicos
NOTE
Los filtros sesgan las métricas de la aplicación. Por ejemplo, puede decidir que, para diagnosticar respuestas lentas, hay que
establecer un filtro para descartar los tiempos de respuesta rápidos. Pero debe tener en cuenta que los tiempos de
respuesta promedio notificados por Application Insights serán más lentos que la velocidad real y que el recuento de las
solicitudes será menor que el recuento real. Si puede resultar un problema, use el muestreo en su lugar.
Establecimiento de filtros
En ApplicationInsights.xml, agregue una sección TelemetryProcessors como la de este ejemplo:
<TelemetryProcessors>
<BuiltInProcessors>
<Processor type="TraceTelemetryFilter">
<Add name="FromSeverityLevel" value="ERROR"/>
</Processor>
<Processor type="RequestTelemetryFilter">
<Add name="MinimumDurationInMS" value="100"/>
<Add name="NotNeededResponseCodes" value="200-400"/>
</Processor>
<Processor type="PageViewTelemetryFilter">
<Add name="DurationThresholdInMS" value="100"/>
<Add name="NotNeededNames" value="home,index"/>
<Add name="NotNeededUrls" value=".jpg,.css"/>
</Processor>
<Processor type="TelemetryEventFilter">

<Add name="NotNeededNames" value="Start,Stop,Pause"/>
</Processor>


<Processor type="SyntheticSourceFilter">

<Add name="NotNeededSources" value="Application Insights Availability
Monitoring,BingPreview"
</Processor>
</BuiltInProcessors>
<CustomProcessors>
<Processor type="com.fabrikam.MyFilter">
<Add name="Successful" value="false"/>
</Processor>
</CustomProcessors>
</TelemetryProcessors>
Inspeccione el conjunto completo de procesadores integrados.
Filtros integrados
Filtro de telemetría de métricas
<Processor type="MetricTelemetryFilter">
<Add name="NotNeeded" value="metric1,metric2"/>
</Processor>
NotNeeded : lista de nombres de métricas personalizados separada por comas.

Filtro de telemetría de vista de página
<Processor type="PageViewTelemetryFilter">
<Add name="DurationThresholdInMS" value="500"/>
<Add name="NotNeededNames" value="page1,page2"/>
<Add name="NotNeededUrls" value="url1,url2"/>
</Processor>
DurationThresholdInMS : la duración se refiere al tiempo dedicado a cargar la página. Si está establecido el

tiempo, no se notifican las páginas que se cargan más rápido que en este momento.
NotNeededNames : lista de nombres de página separados por comas.
NotNeededUrls : lista de fragmentos de URL separados por comas. Por ejemplo, "home" filtra todas las
páginas que tienen "inicio" en la dirección URL.
Filtro de telemetría de solicitudes
<Processor type="RequestTelemetryFilter">
<Add name="MinimumDurationInMS" value="500"/>
<Add name="NotNeededResponseCodes" value="page1,page2"/>
<Add name="NotNeededUrls" value="url1,url2"/>
</Processor>
Filtro de origen sintético

Filtra toda la telemetría con valores en la propiedad SyntheticSource. Incluye solicitudes de bots, spiders y
Filtre la telemetría para todas las solicitudes sintéticas:
<Processor type="SyntheticSourceFilter" />
Filtre la telemetría para orígenes sintéticos específicos:
<Processor type="SyntheticSourceFilter" >

<Add name="NotNeeded" value="source1,source2"/>
</Processor>
NotNeeded : Lista de nombres de origen sintético separados por comas.

Filtro de eventos de telemetría
Filtra los eventos personalizados (registrados mediante TrackEvent()).
<Processor type="TelemetryEventFilter" >

<Add name="NotNeededNames" value="event1, event2"/>
</Processor>
NotNeededNames : lista de nombres de eventos separados por comas.

Filtro de telemetría de seguimiento
Filtra los seguimientos de registros (registrados mediante TrackTrace() o un recopilador de plataforma de
registro).
<Processor type="TraceTelemetryFilter">
<Add name="FromSeverityLevel" value="ERROR"/>
</Processor>
Los valores válidos de FromSeverityLevel son:

OFF - Filtra TODOS los seguimientos
TRACE - Sin filtrado. es igual al nivel de seguimiento
INFO - Filtra el nivel TRACE
WARN - Filtra el nivel TRACE e INFO
ERROR - Filtra WARN, INFO, TRACE
CRITICAL - Filtra todo menos CRITICAL
Filtros personalizados
1. Codificación del filtro
En el código, cree una clase que implemente TelemetryProcessor :
package com.fabrikam.MyFilter;
import com.microsoft.applicationinsights.extensibility.TelemetryProcessor;
import com.microsoft.applicationinsights.telemetry.Telemetry;
public class SuccessFilter implements TelemetryProcessor {
/* Any parameters that are required to support the filter.*/

private final String successful;
/* Initializers for the parameters, named "setParameterName" */

public void setNotNeeded(String successful)
{
this.successful = successful;
}
/* This method is called for each item of telemetry to be sent.

Return false to discard it.
Return true to allow other processors to inspect it. */
@Override
public boolean process(Telemetry telemetry) {
if (telemetry == null) { return true; }
if (telemetry instanceof RequestTelemetry)
{
RequestTelemetry requestTelemetry = (RequestTelemetry)telemetry;
return request.getSuccess() == successful;
}
return true;
}
}
2. Invocación del filtro en el archivo de configuración

En ApplicationInsights.xml:
<CustomProcessors>
<Processor type="com.fabrikam.SuccessFilter">
<Add name="Successful" value="false"/>
</Processor>
</CustomProcessors>
3. Invocación del filtro (Java Spring)

En el caso de las aplicaciones basadas en el marco Spring, los procesadores de telemetría personalizados deben
registrarse en la clase principal de la aplicación como un bean. A continuación, cuando se inicie la aplicación, se
conectarán automáticamente.
@Bean
public TelemetryProcessor successFilter() {
return new SuccessFilter();
}
Deberá crear sus propios parámetros de filtro en application.properties y aprovechar el marco de

configuración externalizado de Spring Boot para pasar los parámetros al filtro personalizado.
El filtro no funciona.
Compruebe que ha proporcionado valores de parámetro válidos. Por ejemplo, las duraciones deben ser
números enteros. Unos valores no válidos hará que el filtro que ignore. Si el filtro personalizado produce una
excepción desde un constructor o el método set, se omitirá.
Pasos siguientes
Muestreo: considere la posibilidad del muestreo como una alternativa que no sesga las métricas.
Cómo usar Micrometer con el SDK de Azure
Application Insights para Java
La aplicación Micrometer supervisa las métricas de medidas para código de aplicación basado en JVM y le permite
exportar los datos a los sistemas de supervisión que prefiera. Este artículo le mostrará cómo usar Micrometer con
Application Insights tanto para las aplicaciones Spring Boot como para las que no sean Spring Boot.
Uso de Spring Boot 1.5x

Agregue las siguientes dependencias al archivo pom.xml o al archivo build.gradle:
Application Insights spring-boot-starter 2.5.0 o posterior
Micrometer Azure Registry 1.1.0 o posterior
Micrometer Spring Legacy 1.1.0 o posterior (modifica el código de configuración automática en la plataforma
de Spring).
Recurso ApplicationInsights
Pasos
1. Actualice el archivo pom.xml de la aplicación Spring Boot y agréguele las siguientes dependencias:
<dependency>
<artifactId>applicationinsights-spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-spring-legacy</artifactId>
</dependency>
<dependency>
<artifactId>micrometer-registry-azure-monitor</artifactId>
</dependency>
2. Actualice el archivo application.properties o yml con la clave de Application Insights Instrumentation

mediante la siguiente propiedad:
azure.application-insights.instrumentation-key=<your-instrumentation-key-here>
3. Compile la aplicación y ejecútela.

4. Las opciones anteriores deberían conseguir que empezara a ejecutar las métricas agregadas previamente y
recopiladas de forma automática para Azure Monitor. Para más información sobre cómo ajustar el iniciador
de Spring Boot de Application Insights, consulte el archivo Léame en GitHub.
Uso de Spring 2.x

Application Insights Spring-boot-starter 2.1.2 o posterior
Azure-spring-boot-metrics-starters 2.0.7 o posterior
Recurso de Application Insights
Pasos:
1. Actualice el archivo pom.xml de la aplicación de Spring Boot y agréguele la siguiente dependencia:
<dependency>
<artifactId>azure-spring-boot-metrics-starter</artifactId>
</dependency>
2. Actualice el archivo application.properties o yml con la clave de Application Insights Instrumentation

mediante la siguiente propiedad:
azure.application-insights.instrumentation-key=<your-instrumentation-key-here>
3. Compile la aplicación y ejecútela.

4. Las opciones anteriores deberían conseguir que empezara a ejecutar las métricas agregadas previamente y
recopiladas de forma automática para Azure Monitor. Para más información sobre cómo ajustar el iniciador
de Spring Boot de Application Insights, consulte el archivo Léame en GitHub.
Métricas predeterminadas:
Las métricas se configuran automáticamente para Tomcat, JVM, métricas de Logback, métricas de Log4J,
métricas de tiempo de actividad, métricas de procesador y FileDescriptorMetrics.
Por ejemplo, si Netflix Hystrix está presente en la ruta de acceso de la clase, también obtenemos esas métricas.
Las siguientes métricas pueden estar disponibles al agregar los beans (o componentes software) respectivos.
CacheMetrics (CaffeineCache, EhCache2, GuavaCache, HazelcastCache y JCache)
DataBaseTableMetrics
HibernateMetrics
JettyMetrics
Métricas de OkHttp3
Métricas de Kafka
Cómo desactivar la recopilación automática de las métricas:
Métricas de JVM:
Management.Metrics.binders.jvm.Enabled=False
Métricas de Logback:
management.metrics.binders.logback.enabled=false
Métricas de tiempo de actividad:
management.metrics.binders.uptime.enabled=false
Métricas de procesador:
management.metrics.binders.processor.enabled=false
FileDescriptorMetrics:
management.metrics.binders.files.enabled=false
Métricas de Hystrix si la biblioteca está en la ruta de clase:
management.metrics.binders.hystrix.enabled=false
Métricas de AspectJ si la biblioteca está en la ruta de clase:
spring.aop.enabled=false
NOTE
Especifique las propiedades anteriores en el archivo application.properties o application.yml de la aplicación Spring Boot
Uso de Micrometer con aplicaciones web que no son Spring Boot

Application Insights Web Auto 2.5.0 o posterior
Micrometer Azure Registry 1.1.0 o posterior
Recurso de Application Insights
Pasos:
1. Agregue las siguientes dependencias en el archivo pom.xml o build.gradle:
<dependency>
<artifactId>micrometer-registry-azure-monitor</artifactId>
</dependency>
<dependency>
<artifactId>applicationinsights-web-auto</artifactId>
</dependency>
2. Coloque el archivo ApplicationInsights.xml en la carpeta de recursos:




<TelemetryModules>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebSessionTrackingTelemetryModule"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebUserTrackingTelemetryModule"/>
</TelemetryModules>



<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationIdTelemetryInitialize
r"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebOperationNameTelemetryInitiali
zer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebSessionTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserTelemetryInitializer"/>
<Add
type="com.microsoft.applicationinsights.web.extensibility.initializers.WebUserAgentTelemetryInitializer"
/>
3. Clase de Servlet de ejemplo (emite una métrica de temporizador):

@WebServlet("/hello")
public class TimedDemo extends HttpServlet {
private static final long serialVersionUID = -4751096228274971485L;
@Override
@Timed(value = "hello.world")
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.getWriter().println("Hello World!");
MeterRegistry registry = (MeterRegistry)
getServletContext().getAttribute("AzureMonitorMeterRegistry");
//create new Timer metric

Timer sampleTimer = registry.timer("timer");
Stream<Integer> infiniteStream = Stream.iterate(0, i -> i+1);
infiniteStream.limit(10).forEach(integer -> {
try {
Thread.sleep(1000);
sampleTimer.record(integer, TimeUnit.MILLISECONDS);
} catch (Exception e) {}
});
}
@Override
public void init() throws ServletException {
System.out.println("Servlet " + this.getServletName() + " has started");
}
@Override
public void destroy() {
System.out.println("Servlet " + this.getServletName() + " has stopped");
}
4. Clase de configuración de ejemplo:

@WebListener
public class MeterRegistryConfiguration implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent servletContextEvent) {
// Create AzureMonitorMeterRegistry
private final AzureMonitorConfig config = new AzureMonitorConfig() {
@Override
public String get(String key) {
return null;
}
@Override
public Duration step() {
return Duration.ofSeconds(60);}
@Override
public boolean enabled() {
return false;
}
};
MeterRegistry azureMeterRegistry = AzureMonitorMeterRegistry.builder(config);
//set the config to be used elsewhere

servletContextEvent.getServletContext().setAttribute("AzureMonitorMeterRegistry",
azureMeterRegistry);
@Override
public void contextDestroyed(ServletContextEvent servletContextEvent) {
}
}
Para más información acerca de las métricas, consulte la documentación de Micrometer.

Otro ejemplo de código sobre cómo crear distintos tipos de métricas puede encontrarse en el repositorio de
GitHub de Micrometer oficial.
Cómo enlazar la recopilación de métricas adicionales

SpringBoot/Spring
Cree un bean de la categoría de métrica respectiva. Por ejemplo, supongamos que necesitamos las métricas de
caché de Guava:
@Bean
GuavaCacheMetrics guavaCacheMetrics() {
Return new GuavaCacheMetrics();
}
Hay varias que no están habilitadas de forma predeterminada, pero se pueden enlazar del modo anterior. Para
obtener una lista completa, consulte el repositorio de GitHub de Micrometer oficial.
Aplicaciones que no sean Spring
Agregue el siguiente código de enlace al archivo de configuración:
New GuavaCacheMetrics().bind(registry);
Pasos siguientes
Para obtener más información sobre Micrometer, vea la documentación de Micrometer oficial.
Para obtener información sobre Spring en Azure, vea la documentación de Spring en Azure oficial.
Solución de problemas y preguntas y respuestas
sobre Application Insights para Java
Preguntas o problemas relacionados con Azure Application Insights en Java. a continuación se incluyen algunas
sugerencias.
Errores de compilación
En Eclipse o Intellij IDEA, al agregar el SDK de Application Insights a través de Maven o Gradle,
obtengo errores de compilación o de validación de la suma de comprobación.
Si el elemento <version>de dependencia usa un patrón con caracteres comodín (por ejemplo, (Maven)
<version>[2.0,)</version> o (Gradle) version:'2.0.+' ), pruebe a especificar una versión específica en su
lugar, como 2.0.1 . Consulte la notas de la versión para la versión más reciente.
Sin datos
He agregado Application Insights correctamente y he ejecutado mi aplicación, pero no aparecen
datos en el por tal.
Espere un minuto y haga clic en Actualizar, Los gráficos se actualizan automáticamente de forma periódica,
pero puede actualizarlos manualmente. El intervalo de actualización depende del intervalo de tiempo del
gráfico.
Compruebe que tiene una clave de instrumentación definida en el archivo ApplicationInsights.xml (en la
carpeta de recursos del proyecto) o configurada como variable de entorno.
Compruebe que no haya ningún nodo <DisableTelemetry>true</DisableTelemetry> en el archivo xml.
En el firewall, es posible que tenga que abrir los puertos TCP 80 y 443 para el tráfico saliente en
dc.services.visualstudio.com. Consulte la lista completa de excepciones del firewall
En el panel de inicio de Microsoft Azure, observe el mapa de estado del servicio. Si hay algunas indicaciones
de alerta, espere hasta que hayan vuelto a su estado correcto y después cierre y vuelva a abrir el cuadro de la
aplicación de Application Insights.
Active el inicio de sesión. Para ello, agregue un elemento <SDKLogger /> bajo el nodo raíz en el archivo
ApplicationInsights.xml (en la carpeta de recursos del proyecto) y compruebe si hay entradas precedidas por
la indicación AI: INFO/WARN/ERROR para cualquier registro sospechoso.
Asegúrese de que se ha cargado correctamente el archivo ApplicationInsights.xml apropiado por parte del
SDK de Java, examinando para ello los mensajes de salida de la consola para ver si hay una instrucción que
haga referencia a que "el archivo de configuración se ha encontrado correctamente".
Si no se encuentra el archivo de configuración, compruebe los mensajes de salida para ver dónde se busca el
archivo de configuración, y asegúrese de que ApplicationInsights.xml se encuentra en una de las ubicaciones
de búsqueda. Como regla general, puede colocar el archivo de configuración cerca de los JAR de SDK de
Application Insights. Por ejemplo: en Tomcat, esto significaría la carpeta WEB-INF/classes. Durante el
desarrollo, puede colocar el archivo ApplicationInsights.xml en la carpeta de recursos del proyecto web.
Consulte también la página de problemas de GitHub para ver los problemas conocidos relacionados con el
SDK.
Asegúrese de usar la misma versión de los appender de inicio de sesión, agente, web y núcleo de Application
Insights para evitar tener problemas de conflictos de versiones.
Solía ver datos, pero ya no sucede esto.
¿Ha alcanzado su cuota mensual de puntos de datos? Abra Configuración/Cuotas y Precios para averiguarlo.
Si es así, puede actualizar el plan o pagar para obtener capacidad adicional. Consulte el esquema de precios.
¿Ha actualizado el SDK recientemente? Asegúrese de que en el directorio del proyecto solo haya archivos JAR
de SDK únicos. No debería haber dos versiones diferentes de SDK.
¿Busca en el recurso correcto de AI? El valor de iKey de la aplicación debe coincidir con el recurso en el que
espera la telemetría. Deben ser iguales.
No veo todos los datos que esperaba
Abra la página Uso y costos estimados y compruebe si el muestreo está en funcionamiento. (La transmisión al
100 % significa que el muestreo no está en funcionamiento). El servicio Application Insights se puede
configurar para que acepte únicamente una fracción de la telemetría procedente de la aplicación. Esto le
ayuda a mantenerse en su cuota mensual de telemetría.
¿Tiene activado el muestreo del SDK? En caso afirmativo, los datos se muestrearían a la velocidad especificada
para todos los tipos aplicables.
¿Ejecuta una versión anterior del SDK de Java? A partir de la versión 2.0.1, hemos introducido un mecanismo
de tolerancia a errores para controlar los errores intermitentes de la red y el back-end, así como la
persistencia de los datos en las unidades locales.
¿Tiene limitaciones debido al exceso de telemetría? Si activa el registro INFO, verá el mensaje de registro "App
is throttled" (La aplicación está limitada). El límite actual es de 32 000 elementos de telemetría/segundo.
El agente de Java no puede capturar datos de dependencia
¿Ha configurado el agente de Java siguiendo el agente de configuración de Java?
Asegúrese de que el archivo JAR del agente de Java y el archivo AI-Agent.xml se coloquen en la misma
carpeta.
Asegúrese de que la dependencia que intenta recopilar automáticamente admita la recopilación automática.
Actualmente solo se admiten colecciones de dependencias de MySQL, MsSQL, Oracle DB y Azure Cache for
Redis.
No aparecen datos de uso

Veo datos sobre solicitudes y tiempos de respuesta, pero no de vista de página, del explorador o
de datos de usuarios.
La aplicación se ha configurado correctamente para enviar datos de telemetría desde el servidor. El paso
siguiente consiste en configurar las páginas web para enviar datos de telemetría desde el explorador web.
Como alternativa, si el cliente es una aplicación de teléfono o de cualquier otro dispositivo, puede enviar datos de
telemetría desde este.
Use la misma clave de instrumentación para configurar la telemetría tanto de cliente como de servidor. Los datos
aparecerán en el mismo recurso de Application Insights y podrá correlacionar eventos de cliente y servidor.
Deshabilitación de la telemetría
¿Cómo puedo deshabilitar la recopilación de telemetría?
En el código:
TelemetryConfiguration config = TelemetryConfiguration.getActive();

config.setTrackingIsDisabled(true);
O
Actualice ApplicationInsights.xml (en la carpeta de recursos del proyecto). Agregue lo siguiente bajo el nodo raíz:
<DisableTelemetry>true</DisableTelemetry>
Si usa el método XML, debe reiniciar la aplicación al cambiar el valor.
Cambio de destino
Obtenga la clave de instrumentación del nuevo recurso.
Si ha agregado Application Insights al proyecto mediante el kit de herramientas de Azure para Eclipse, haga
clic con el botón derecho en el proyecto web, seleccione Azure , Configurar Application Insights y cambie
la clave.
Si ha configurado la clave de instrumentación como variable de entorno, actualice el valor de dicha variable
con el nuevo valor de iKey.
De lo contrario, actualice la clave en ApplicationInsights.xml en la carpeta de recursos del proyecto.
Depuración de datos del SDK

¿Cómo puedo averiguar lo que está haciendo el SDK?
Para más información sobre lo que sucede en la API, agregue <SDKLogger/> bajo el nodo raíz del archivo de
configuración ApplicationInsights.xml.
ApplicationInsights.xml
También puede indicar al registrador que lo envíe a un archivo:
<SDKLogger type="FILE">

<Level>TRACE</Level>
<UniquePrefix>AI</UniquePrefix>
<BaseFolderPath>C:/agent/AISDK</BaseFolderPath>
</SDKLogger>
Spring Boot Starter

Para habilitar los registros del SDK con aplicaciones de Spring Boot mediante Spring Boot Starter de Application
Insights, agregue lo siguiente al archivo application.properties :
azure.application-insights.logger.type=file
azure.application-insights.logger.base-folder-path=C:/agent/AISDK
azure.application-insights.logger.level=trace
o para imprimir si se produce un error estándar:
azure.application-insights.logger.type=console
azure.application-insights.logger.level=trace
Agente de Java
Para habilitar la actualización del registro del agente de JVM, actualice el archivo AI-Agent.xml:
<AgentLogger type="FILE">
<Level>TRACE</Level>
<UniquePrefix>AI</UniquePrefix>
<BaseFolderPath>C:/agent/AIAGENT</BaseFolderPath>
</AgentLogger>
Propiedades de la línea de comandos de Java

A partir de la versión 2.4.0
Para habilitar el registro con opciones de la línea de comandos, sin cambiar los archivos de configuración:
java -Dapplicationinsights.logger.file.level=trace -Dapplicationinsights.logger.file.uniquePrefix=AI -

Dapplicationinsights.logger.baseFolderPath="C:/my/log/dir" -jar MyApp.jar
o para imprimir si se produce un error estándar:
java -Dapplicationinsights.logger.console.level=trace -jar MyApp.jar
Pantalla de inicio de Azure

Estoy mirando el por tal de Azure . ¿El mapa indica algo sobre mi aplicación?
No, este muestra el estado de los servidores de Azure en todo el mundo.
¿Cómo puedo encontrar datos sobre mi aplicación desde el panel de inicio de Azure (pantalla principal)?
Suponiendo configuró la aplicación para Application Insights, haga clic en Examinar, seleccione Application
Insights y, después, elija el recurso de aplicación que haya creado para su aplicación. Para mayor brevedad en un
futuro, puede anclar la aplicación al panel de inicio.
Servidores de intranet
¿Puedo super visar un ser vidor de mi intranet?
Sí, siempre que dicho servidor pueda enviar datos de telemetría al portal de Application Insights a través de una
conexión pública a Internet.
En el firewall, tendrá que abrir los puertos TCP 80 y 443 para el tráfico saliente en dc.services.visualstudio.com y
f5.services.visualstudio.com.
Retención de datos
¿Cuánto tiempo se retienen los datos en el por tal? ¿Es seguro?
Consulte Privacidad y retención de los datos.
Registro de depuración
Application Insights usa org.apache.http . Se reubica en los archivos JAR principales de Application Insights en el
espacio de nombres com.microsoft.applicationinsights.core.dependencies.http . Esto permite a Application
Insights administrar los escenarios donde existen diferentes versiones del mismo módulo org.apache.http en un
código base.
NOTE
Si habilita los registros a nivel de DEPURACIÓN para todos los espacios de nombres en la aplicación, se respetarán en
todos los módulos de ejecución, incluido org.apache.http , cuyo nombre ha cambiado a
com.microsoft.applicationinsights.core.dependencies.http . Application Insights no podrá aplicar el filtrado a estas
llamadas, porque la llamada de registro la realiza la biblioteca de Apache. Los registros a nivel de DEPURACIÓN producen
un volumen considerable de datos de registro y no se recomiendan para las instancias de producción en vivo.
Pasos siguientes
He configurado Application Insights para mi aplicación de ser vidor Java. ¿Qué más puedo hacer?
Supervisar la disponibilidad de sus páginas web
Supervisar el uso de las páginas web
Realizar el seguimiento del uso y diagnosticar los problemas en las aplicaciones de su dispositivo
Escribir código para realizar un seguimiento del uso de la aplicación
Capturar los registros de diagnóstico
Obtener ayuda
Stack Overflow
Notificación de un problema en GitHub
Supervisión de servicios y aplicaciones de Node.js
con Application Insights
Application Insights supervisa los componentes y los servicios back-end después de implementarlos para
ayudarle a detectar y diagnosticar rápidamente problemas de rendimiento, entre otros. Puede usar
Application Insights para los servicios de Node.js que se hospedan en el centro de datos, en máquinas
virtuales de Azure y en aplicaciones web, e incluso en otras nubes públicas.
Para recibir, almacenar y explorar los datos de supervisión, incluya el SDK en su código y luego configure el
recurso correspondiente de Application Insights en Azure. El SDK envía datos a ese recurso para realizar el
análisis y la exploración posteriormente.
El SDK de Node.js puede supervisar automáticamente las solicitudes HTTP entrantes y salientes, excepciones
y varias métricas del sistema. A partir de la versión 0.20, el SDK también puede supervisar algunos paquetes
de terceros comunes, como MongoDB, MySQL y Redis. Todos los eventos relacionados con una solicitud HTTP
entrante se correlacionan para una solución de problemas más rápida.
Puede usar TelemetryClient API para instrumentar y supervisar manualmente aspectos adicionales de la
aplicación y el sistema. TelemetryClient API se describe con más detalle más adelante en este artículo.
Introducción
Realice las tareas siguientes para configurar la supervisión para una aplicación o servicio.
Requisitos previos
Antes de empezar, asegúrese de que tiene una suscripción de Azure o bien obtenga una nueva de forma
gratuita. Si su organización ya tiene una suscripción de Azure, un administrador puede seguir estas
instrucciones y agregarle a ella.
Configuración de un recurso de Application Insights
2. Creación de recursos en Application Insights
Configuración del SDK de Node.js
Incluya el SDK en la aplicación para que pueda recopilar datos.
1. Copie la clave de instrumentación del recurso (también conocida como ikey) desde su recurso recién
creado. Application Insights usa el valor de ikey para asignar datos a los recursos de Azure. Para que el
SDK pueda usar el valor de ikey, se debe especificar en una variable de entorno o en el código.
2. Agregue la biblioteca del SDK de Node.js a las dependencias de la aplicación a través de package.json.
En la carpeta raíz de la aplicación, ejecute:
npm install applicationinsights --save
NOTE
Si usa TypeScript, no instale paquetes "typings" independientes. El paquete NPM contiene un archivo typings
integrado.
3. Cargue explícitamente la biblioteca en el código. Dado que el SDK inserta la instrumentación en

muchas otras bibliotecas, cargue la biblioteca tan pronto como sea posible, incluso antes que otras
instrucciones require .
let appInsights = require('applicationinsights');
4. También puede proporcionar una clave ikey mediante la variable de entorno

APPINSIGHTS_INSTRUMENTATIONKEY en lugar de pasarla manualmente a setup() o
new appInsights.TelemetryClient() . Esta práctica permite conservar los valores de ikey fuera del
código fuente confirmado y también para especificar distintos valores de ikey para los diferentes
entornos. Para realizar la configuración manualmente, llame a appInsights.setup('[your ikey]'); .
Para conocer opciones de configuración adicionales, consulte las secciones siguientes.
Puede probar el SDK sin enviar telemetría estableciendo
appInsights.defaultClient.config.disableAppInsights = true .
5. Comience a recopilar y enviar datos automáticamente mediante una llamada a appInsights.start(); .
Supervisión de la aplicación
El SDK recopila automáticamente datos de telemetría sobre el entorno de ejecución de Node.js y algunos
módulos de terceros comunes. Utilice la aplicación para generar algunos datos.
A continuación, en Azure Portal vaya al recurso de Application Insights que creó antes. En la Escala de
tiempo con información general , busque los primeros puntos de datos. Para ver datos más detallados,
seleccione diferentes componentes en los gráficos.
Para ver la topología detectada para la aplicación, puede usar el mapa de aplicación.
Sin datos
Dado que el SDK crea lotes de datos para enviar, puede haber un retraso hasta que se muestran los
elementos en el portal. Si no ve los datos en el recurso, pruebe algunas de las soluciones siguientes:
Seguir usando la aplicación. Realizar más acciones para generar más datos de telemetría.
Haga clic en Actualizar en la vista de recursos del portal. Los gráficos se actualizan periódicamente por sí
mismos, pero si se actualizan de forma manual, se actualizan de inmediato.
Compruebe que los puertos de salida necesarios estén abiertos.
Use Buscar para buscar eventos específicos.
Consulte las preguntas más frecuentes.
Uso básico
Para la recopilación integrada de solicitudes HTTP, eventos populares de bibliotecas de terceros, excepciones
no controladas y métricas del sistema, use:
let appInsights = require("applicationinsights");
appInsights.setup("[your ikey]").start();
NOTE
Si la clave de instrumentación se establece en la variable de entorno APPINSIGHTS_INSTRUMENTATIONKEY , se puede
llamar a .setup() sin argumentos. Esto facilita el uso de diferentes claves ikey para diferentes entornos.
Cargue la biblioteca de Application Insights, require("applicationinsights") , tan pronto como sea posible en
los scripts antes de cargar otros paquetes. Esto es necesario para que la biblioteca de Application Insights
pueda preparar los paquetes posteriores con fines de seguimiento. Si encuentra conflictos con otras
bibliotecas que realizan una preparación similar, intente cargar la biblioteca de Application Insights después
de esas otras.
Debido a la forma en la que JavaScript controla las devoluciones de llamada, se requiere trabajo adicional
para realizar el seguimiento de una solicitud entre las dependencias externas y las devoluciones de llamada
posteriores. De forma predeterminada, este seguimiento adicional está habilitado; para deshabilitarlo, llame a
setAutoDependencyCorrelation(false) tal y como se describe en la sección de configuración que aparece más
abajo.
Migración desde versiones anteriores a la 0.22

Hay cambios importantes entre las versiones anteriores y posteriores a la 0.22. Estos cambios están
diseñados para ofrecer coherencia con otros SDK de Application Insights y permitir la extensibilidad futura.
En general, puede realizar la migración de las siguientes formas:
Reemplace las referencias a appInsights.client por appInsights.defaultClient .
Reemplace las referencias a appInsights.getClient() por new appInsights.TelemetryClient() .
Reemplace todos los argumentos por métodos client.track* con un único objeto que contenga
propiedades con nombre como argumentos. Vea las sugerencias de tipos integrados del IDE o
TelemetryTypes para el objeto de excepción para cada tipo de telemetría.
Si accede a las funciones de configuración del SDK sin encadenarlas a appInsights.setup() , ahora puede
encontrar estas funciones en appInsights.Configurations (por ejemplo,
appInsights.Configuration.setAutoCollectDependencies(true) ). Revise los cambios realizados en la
configuración predeterminada en la siguiente sección.
Configuración del SDK

El objeto appInsights proporciona varios métodos de configuración. Estos métodos se enumeran en el
siguiente fragmento de código con sus valores predeterminados.
appInsights.setup("<instrumentation_key>")
.setAutoDependencyCorrelation(true)
.setAutoCollectRequests(true)
.setAutoCollectPerformance(true, true)
.setAutoCollectExceptions(true)
.setAutoCollectDependencies(true)
.setAutoCollectConsole(true)
.setUseDiskRetryCaching(true)
.setSendLiveMetrics(false)
.setDistributedTracingMode(appInsights.DistributedTracingModes.AI)
.start();
Para correlacionar totalmente los eventos en un servicio, asegúrese de establecer

.setAutoDependencyCorrelation(true) . Con esta opción establecida, el SDK puede realizar el seguimiento del
contexto a través de las devoluciones de llamada asincrónicas en Node.js.
Revise las descripciones en las sugerencias de tipos integrados del IDE, o bien consulte applicationinsights.ts
para obtener información detallada sobre qué controlan y sobre los argumentos secundarios opcionales.
NOTE
De forma predeterminada, setAutoCollectConsole está configurado para excluir las llamadas a console.log (y a
otros métodos de consola). Solo se recopilarán las llamadas a registradores de terceros admitidos (por ejemplo,
Winston y Bunyan). Puede cambiar este comportamiento para incluir las llamadas a métodos console mediante
setAutoCollectConsole(true, true) .
muestreo
De forma predeterminada, el SDK enviará todos los datos recopilados al servicio de Application Insights. Si
recopila una gran cantidad de datos, es posible que quiera habilitar el muestreo para reducir la cantidad de
datos enviados. Para ello, especifique el campo samplingPercentage en el objeto config de un cliente. Si
establece samplingPercentage en 100 (el valor predeterminado), se enviarán todos los datos, y si lo establece
en 0, no se enviará nada.
Si usa la correlación automática, todos los datos asociados a una única solicitud se incluirán o excluirán como
una unidad.
Agregue el siguiente fragmento de código para habilitar el muestreo:
const appInsights = require("applicationinsights");

appInsights.setup("<instrumentation_key>");
appInsights.defaultClient.config.samplingPercentage = 33; // 33% of all telemetry will be sent to
appInsights.start();
Varios roles para aplicaciones de varios componentes

Si la aplicación consta de varios componentes que quiere instrumentar con la misma clave de
instrumentación, pero quiere seguir viendo estos componentes como unidades independientes en el portal,
como si usaran claves de instrumentación independientes (por ejemplo, como nodos independientes en el
mapa de aplicación), puede que necesite configurar manualmente el campo RoleName para distinguir la
telemetría de un componente de otros componentes que envían datos a su recurso de Application Insights.
Use el siguiente código para configurar el campo RoleName:
appInsights.setup("<instrumentation_key>");
appInsights.defaultClient.context.tags[appInsights.defaultClient.context.keys.cloudRole] = "MyRoleName";
appInsights.start();
Instrumentación de terceros automática

Para realizar un seguimiento del contexto a través de llamadas asincrónicas, es necesario hacer algunos
cambios en las bibliotecas de terceros, como MongoDB y Redis. De forma predeterminada, Application
Insights usará diagnostic-channel-publishers para modificar de forma dinámica algunas de estas bibliotecas.
Se puede deshabilitar si se establece la variable de entorno APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL .
NOTE
Al establecer esa variable de entorno, es posible que los eventos dejen de estar asociados correctamente a la operación
adecuada.
Las modificaciones dinámicas individuales se pueden deshabilitar si se establece la variable de entorno

APPLICATION_INSIGHTS_NO_PATCH_MODULES en una lista de paquetes separados por comas, por ejemplo,
APPLICATION_INSIGHTS_NO_PATCH_MODULES=console,redis para evitar la modificación de los paquetes console y
redis .
Actualmente hay nueve paquetes instrumentados: bunyan , console , mongodb , mongodb-core , mysql , redis ,
winston , pg y pg-pool . Consulte el archivo Léame de diagnostic-channel-publishers para obtener
información sobre la versión revisada de estos paquetes.
Las revisiones de bunyan , winston y console generarán eventos de seguimiento de Application Insights en
función de si setAutoCollectConsole está habilitado. El resto generará eventos de dependencia de Application
Insights en función de si setAutoCollectDependencies está habilitado.
Live Metrics
Para habilitar el envío de métricas en tiempo real desde la aplicación a Azure, use setSendLiveMetrics(true) .
Actualmente no se admite el filtrado de métricas en tiempo real en el portal.
Métricas extendidas
NOTE
La capacidad de enviar métricas nativas extendidas se agregó en la versión 1.4.0.
Para habilitar el envío de métricas nativas extendidas desde su aplicación a Azure, instale el paquete de
métricas nativas independiente. El SDK se cargará automáticamente cuando se instale y empezará a recopilar
métricas nativas de Node.js.
npm install applicationinsights-native-metrics
Actualmente, el paquete de métricas nativas recopila automáticamente tiempo de CPU de recolección de

elementos no utilizados, tics de bucle de eventos e información de uso de montones:
Recolección de elementos no utilizados : cantidad de tiempo de CPU que se dedica a cada tipo de
recolección de elementos no utilizados y número de repeticiones de cada tipo.
Bucle de eventos : número de tics que se han producido y tiempo de CPU que se ha dedicado en total.
Montón frente a no montón : cantidad de uso de memoria de la aplicación se dedica o no al montón.
Modos de seguimiento distribuido
De forma predeterminada, el SDK enviará los encabezados que entienden otras aplicaciones o servicios
instrumentados con un SDK de Application Insights. Opcionalmente, puede habilitar el envío y la recepción de
encabezados de contexto de seguimiento de W3C, además de los encabezados de IA existentes, por lo que no
se interrumpirá la correlación con ninguno de los servicios heredados existentes. La habilitación de
encabezados de W3C permitirá que la aplicación se correlacione con otros servicios no instrumentados con
Application Insights, pero que adopte este estándar de W3C.

appInsights
.setup("<your ikey>")
.setDistributedTracingMode(appInsights.DistributedTracingModes.AI_AND_W3C)
.start()
TelemetryClient API
Para obtener una descripción completa de TelemetryClient API, consulte API de Application Insights para
eventos y métricas personalizados.
Puede realizar el seguimiento de cualquier solicitud, evento, métrica o excepción mediante el SDK de Node.js
de Application Insights. El ejemplo de código siguiente muestra algunas de las API que puede usar:

appInsights.setup().start(); // assuming ikey in env var. start() can be omitted to disable any non-
custom data
let client = appInsights.defaultClient;
client.trackEvent({name: "my custom event", properties: {customProperty: "custom property value"}});
client.trackException({exception: new Error("handled exceptions can be logged with this method")});
client.trackMetric({name: "custom metric", value: 3});
client.trackTrace({message: "trace message"});
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM
Customers", duration:231, resultCode:0, success: true, dependencyTypeName: "ZSQL"});
client.trackRequest({name:"GET /customers", url:"http://myserver/customers", duration:309,
resultCode:200, success:true});
let http = require("http");

http.createServer( (req, res) => {
client.trackNodeHttpRequest({request: req, response: res}); // Place at the beginning of your request
handler
});
Seguimiento de las dependencias

Utilice el código siguiente para realizar el seguimiento de las dependencias:

let client = new appInsights.TelemetryClient();
var success = false;

let startTime = Date.now();
// execute dependency call here....
let duration = Date.now() - startTime;
success = true;
client.trackDependency({target:"http://dbname", name:"select customers proc", data:"SELECT * FROM

Customers", duration:duration, resultCode:0, success: true, dependencyTypeName: "ZSQL"});;
A continuación se muestra una utilidad de ejemplo que usa trackMetric para medir el tiempo que tarda la
programación del bucle de eventos:
function startMeasuringEventLoop() {
var startTime = process.hrtime();
var sampleSum = 0;
var sampleCount = 0;
// Measure event loop scheduling delay

setInterval(() => {
var elapsed = process.hrtime(startTime);
startTime = process.hrtime();
sampleSum += elapsed[0] * 1e9 + elapsed[1];
sampleCount++;
}, 0);
// Report custom metric every second

setInterval(() => {
var samples = sampleSum;
var count = sampleCount;
sampleSum = 0;
sampleCount = 0;
if (count > 0) {
var avgNs = samples / count;
var avgMs = Math.round(avgNs / 1e6);
client.trackMetric({name: "Event Loop Delay", value: avgMs});
}
}, 1000);
}
Incorporación de una propiedad personalizada a todos los eventos

Utilice el código siguiente para agregar una propiedad personalizada a todos los eventos:
appInsights.defaultClient.commonProperties = {
environment: process.env.SOME_ENV_VARIABLE
};
Seguimiento de solicitudes HTTP GET

Use el código siguiente para realizar un seguimiento manual de las solicitudes HTTP GET:
NOTE
Se hace un seguimiento de todas las solicitudes de forma predeterminada. Para deshabilitar la recopilación automática,
llame a .setAutoCollectRequests(false) antes de llamar a start().
appInsights.defaultClient.trackRequest({name:"GET /customers", url:"http://myserver/customers",

duration:309, resultCode:200, success:true});
También puede realizar un seguimiento de las solicitudes mediante el método trackNodeHttpRequest :
var server = http.createServer((req, res) => {

if ( req.method === "GET" ) {
appInsights.defaultClient.trackNodeHttpRequest({request:req, response:res});
}
// other work here....
res.end();
});
Seguimiento de la hora de inicio del servidor

Utilice el código siguiente para realizar un seguimiento de la hora de inicio del servidor:
let start = Date.now();

server.on("listening", () => {
let duration = Date.now() - start;
appInsights.defaultClient.trackMetric({name: "server startup time", value: duration});
});
Preprocesamiento de datos con procesadores de telemetría

Puede procesar y filtrar los datos recopilados antes de enviarlos para su retención mediante el uso de
procesadores de telemetría. Los procesadores de telemetría se llaman de uno en uno en el orden en el que se
han agregado antes de que el elemento de telemetría se envíe a la nube.
public addTelemetryProcessor(telemetryProcessor: (envelope: Contracts.Envelope, context: {

http.RequestOptions, http.ClientRequest, http.ClientResponse, correlationContext }) => boolean)
Si un procesador de telemetría devuelve false, no se enviará el elemento de telemetría.

Todos los procesadores de telemetría reciben los datos de telemetría y su sobre para inspeccionarlos y
modificarlos. También reciben un objeto de contexto. En el caso de la telemetría de seguimiento manual, el
contenido de este objeto lo define el parámetro contextObjects cuando se llama a un método de
seguimiento. Para la telemetría recopilada automáticamente, este objeto se llena con la información de
solicitud disponible y el contenido de la solicitud persistente, tal como lo proporciona
appInsights.getCorrelationContext() (si está habilitada la correlación automática de dependencias).
El tipo de TypeScript de un procesador de telemetría es:
telemetryProcessor: (envelope: ContractsModule.Contracts.Envelope, context: { http.RequestOptions,

http.ClientRequest, http.ClientResponse, correlationContext }) => boolean;
Por ejemplo, un procesador que quita los datos de seguimiento de pilas de las excepciones podría escribirse y
agregarse como se indica a continuación:
function removeStackTraces ( envelope, context ) {

if (envelope.data.baseType === "Microsoft.ApplicationInsights.ExceptionData") {
var data = envelope.data.baseData;
if (data.exceptions && data.exceptions.length > 0) {
for (var i = 0; i < data.exceptions.length; i++) {
var exception = data.exceptions[i];
exception.parsedStack = null;
exception.hasFullStack = false;
}
}
}
return true;
}
appInsights.defaultClient.addTelemetryProcessor(removeStackTraces);
Uso de múltiples claves de instrumentación

Puede crear varios recursos de Application Insights y enviar distintos datos a cada uno de ellos con sus
respectivas claves de instrumentación ("ikey").
Por ejemplo:
// configure auto-collection under one ikey

appInsights.setup("_ikey-A_").start();
// track some events manually under another ikey

let otherClient = new appInsights.TelemetryClient("_ikey-B_");
otherClient.trackEvent({name: "my custom event"});
Opciones de configuración avanzada

El objeto de cliente contiene una propiedad config con muchos valores de configuración opcionales para
escenarios avanzados. Estos valores pueden establecerse de la siguiente manera:
client.config.PROPERTYNAME = VALUE;
Las siguientes propiedades son específicas del cliente, por lo que puede configurar
appInsights.defaultClient de forma independiente con respecto a los clientes creados con
new appInsights.TelemetryClient() .
instrumentationKey Identificador para el recurso de Application Insights.
endpointUrl Punto de conexión de ingesta al que se van a enviar las

cargas de telemetría.
quickPulseHost Host de Live Metrics Stream al que se va a enviar la

telemetría de métricas en tiempo real.
proxyHttpUrl Servidor proxy para el tráfico HTTP del SDK (opcional, el

valor predeterminado se extrae de la variable de entorno
http_proxy ).
proxyHttpsUrl Servidor proxy para el tráfico HTTPS del SDK (opcional, el

valor predeterminado se extrae de la variable de entorno
https_proxy ).
httpAgent Agente http.Agent que se usará para el tráfico HTTP del

SDK (opcional, valor predeterminado sin definir).
httpsAgent Agente https.Agent que se usará para el tráfico HTTPS del

SDK (opcional, valor predeterminado sin definir).
maxBatchSize Número máximo de elementos de telemetría que se

incluirán en una carga en el punto de conexión de ingesta
(el valor predeterminado es 250 ).
maxBatchIntervalMs Cantidad máxima de tiempo que hay que esperar para que
una carga alcance el tamaño máximo de lote, maxBatchSize
(el valor predeterminado es 15000 ).
disableAppInsights Marca que indica si la transmisión de telemetría está

deshabilitada (el valor predeterminado es false ).
samplingPercentage Porcentaje de elementos de telemetría de los que se realiza

un seguimiento y que se deben transmitir (el valor
predeterminado es 100 ).
correlationIdRetryIntervalMs Tiempo de espera antes de volver a intentar recuperar el

identificador para la correlación entre componentes (el
valor predeterminado es 30000 ).
correlationHeaderExcludedDomains Lista de dominios que se excluirán de la inyección de

encabezados de correlación entre componentes (para ver el
valor predeterminado, consulte Config.ts).
Pasos siguientes
Navegación y paneles en el portal de Application Insights
Escritura de consultas de Analytics sobre los datos de telemetría
Configuración de Azure Monitor para la aplicación
de Python
Azure Monitor admite seguimiento distribuido, recopilación de métricas y registro de aplicaciones de Python
gracias a la integración con OpenCensus. En este artículo, encontrará instrucciones para configurar
OpenCensus para Python y enviar los datos de supervisión a Azure Monitor.
Requisitos previos
Suscripción a Azure. Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Instalación de Python. En este artículo se usa Python 3.7.0, aunque es probable que las versiones
anteriores funcionen con cambios menores. El SDK solo admite Python v2.7 y v3.4-v3.7.
Cree un recurso de Application Insights. Se le asignará su propia clave de instrumentación (iKey) para el
recurso.
Instrumentación con el SDK de Python para OpenCensus en Azure

Monitor
Instale los exportadores de Azure Monitor de OpenCensus:
python -m pip install opencensus-ext-azure
Para una lista completa de los paquetes y las integraciones, consulte Paquetes de OpenCensus.
NOTE
El comando python -m pip install opencensus-ext-azure supone que tiene una variable de entorno PATH
establecida para la instalación de Python. Si no ha configurado esta variable, deberá proporcionar la ruta de acceso
completa del directorio a la ubicación del archivo ejecutable de Python. El resultado es un comando como el siguiente:
C:\Users\Administrator\AppData\Local\Programs\Python\Python37-32\python.exe -m pip install opencensus-
ext-azure
.
El SDK emplea tres exportadores de Azure Monitor para enviar distintos tipos de telemetría a Azure Monitor.
Son seguimiento, métricas y registros. Para obtener más información sobre estos tipos de telemetría, consulte
la información general sobre la plataforma de datos. Utilice las instrucciones siguientes para enviar estos tipos
de telemetría a través de los tres exportadores.
Asignaciones de tipos de telemetría

Estos son los exportadores que proporciona OpenCensus asignados a los tipos de telemetría que se ven en
Azure Monitor.
T IP O DE T EL EM ET RÍA EN A Z URE
P IL A R DE O B SERVA B IL IDA D M O N ITO R. EXP L IC A C IÓ N
T IP O DE T EL EM ET RÍA EN A Z URE
P IL A R DE O B SERVA B IL IDA D M O N ITO R. EXP L IC A C IÓ N
Registros Seguimientos, excepciones, Telemetría de registro, telemetría de

customEvents excepciones, telemetría de eventos
Métricas customMetrics, performanceCounters Contadores de rendimiento de

métricas personalizadas
Seguimiento Dependencias de solicitudes Solicitudes entrantes, solicitudes

salientes
Registros
1. Primero, se van a generar algunos datos de registro locales.
import logging
logger = logging.getLogger(__name__)
def valuePrompt():
line = input("Enter a value: ")
logger.warning(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
2. El código pedirá continuamente que se escriba un valor. Se emite una entrada de registro para cada
valor especificado.
Enter a value: 24
24
Enter a value: 55
55
Enter a value: 123
123
Enter a value: 90
90
3. Aunque introducir valores es útil con fines de demostración, la finalidad básica es emitir los datos del
registro a Azure Monitor. Pase la cadena de conexión directamente al exportador. O bien, puede
especificarlo en una variable de entorno APPLICATIONINSIGHTS_CONNECTION_STRING . Modifique el código
del paso anterior en función del ejemplo de código siguiente:
import logging
from opencensus.ext.azure.log_exporter import AzureLogHandler
# TODO: replace the all-zero GUID with your instrumentation key.

logger.addHandler(AzureLogHandler(
connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000')
)
def valuePrompt():
logger.warning(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
4. El exportador envía los datos de registro a Azure Monitor. Puede encontrar los datos en traces .
NOTE
En este contexto, traces no es lo mismo que tracing . Aquí, traces hace referencia al tipo de telemetría
que verá en Azure Monitor al usar AzureLogHandler . Pero tracing hace referencia a un concepto de
OpenCensus y se relaciona con el seguimiento distribuido.
NOTE
El registrador raíz se configura con el nivel de advertencia. Esto significa que los registros que se envían con
menos de una gravedad se omiten y, a su vez, no se enviarán a Azure Monitor. Para obtener más información,
vea la documentación.
5. También puede agregar propiedades personalizadas a los mensajes de registro del argumento de
palabra clave extra mediante el campo custom_dimensions. Estas propiedades aparecen como pares de
valor clave en el customDimensions de Azure Monitor.
NOTE
Para que esta característica funcione, debe pasar un diccionario al campo custom_dimensions. Si se pasan
argumentos de cualquier otro tipo, el registrador los omitirá.
import logging
)
properties = {'custom_dimensions': {'key_1': 'value_1', 'key_2': 'value_2'}}
# Use properties in logging statements

logger.warning('action', extra=properties)
Configuración del registro para aplicaciones de Django.

Puede configurar el registro de forma explícita en su código de aplicación, como en el caso de las aplicaciones
de Django, o puede especificarlo en la configuración de registro de Django. Este código puede entrar en
cualquier archivo que use para la configuración de los valores de Django. Para ver cómo configurar los
valores de Django, consulte valores de Django. Para más información sobre la configuración del registro para
Log4j, consulte registro de Django.
LOGGING = {
"handlers": {
"azure": {
"level": "DEBUG",
"class": "opencensus.ext.azure.log_exporter.AzureLogHandler",
"instrumentation_key": "<your-ikey-here>",
},
"console": {
"level": "DEBUG",
"class": "logging.StreamHandler",
"stream": sys.stdout,
},
},
"loggers": {
"logger_name": {"handlers": ["azure", "console"]},
},
}
Asegúrese de usar el registrador con el mismo nombre que el especificado en su configuración.
import logging
logger = logging.getLogger("logger_name")
logger.warning("this will be tracked")
Enviar excepciones
OpenCensus Python no realiza de forma automática el seguimiento y el envío de la telemetría de exception .
Se envían mediante AzureLogHandler por medio de excepciones a través de la biblioteca de registro de
Python. Puede agregar propiedades personalizadas de la misma manera que con el registro normal.
import logging
)
properties = {'custom_dimensions': {'key_1': 'value_1', 'key_2': 'value_2'}}
# Use properties in exception logs

try:
result = 1 / 0 # generate a ZeroDivisionError
except Exception:
logger.exception('Captured an exception.', extra=properties)
Es decisión del usuario cómo quiere registrar las excepciones no controladas, ya que debe registrar las
excepciones de manera explícita. OpenCensus no impone restricciones en el modo en que un usuario quiera
hacerlo, siempre y cuando registre explícitamente una telemetría de excepciones.
Envío de eventos
Puede enviar la telemetría de customEvent exactamente del mismo modo que envía la telemetría de trace ,
excepto mediante el uso de AzureEventHandler en su lugar.
import logging
from opencensus.ext.azure.log_exporter import AzureEventHandler
logger.addHandler(AzureEventHandler(connection_string='InstrumentationKey=<your-instrumentation_key-
here>'))
logger.setLevel(logging.INFO)
logger.info('Hello, World!')
muestreo
Para información sobre el muestreo en OpenCensus, eche un vistazo al muestreo en OpenCensus.
Correlación de registros
Para más información sobre cómo enriquecer los registros con los datos de contexto de seguimiento, vea la
integración de registros de Python para OpenCensus.
Modificación de la telemetría
Para obtener detalles sobre cómo modificar la telemetría sometida a seguimiento antes de enviarla a Azure
Monitor, vea los procesadores de telemetría de Python para OpenCensus.
Métricas
1. Primero, se van a generar algunos datos de métrica locales. Se creará una métrica sencilla para realizar
el seguimiento del número de veces que el usuario selecciona la tecla Entrar .
from datetime import datetime
from opencensus.stats import aggregation as aggregation_module
from opencensus.stats import measure as measure_module
from opencensus.stats import stats as stats_module
from opencensus.stats import view as view_module
from opencensus.tags import tag_map as tag_map_module
stats = stats_module.stats
view_manager = stats.view_manager
stats_recorder = stats.stats_recorder
prompt_measure = measure_module.MeasureInt("prompts",
"number of prompts",
"prompts")
prompt_view = view_module.View("prompt view",
[],
prompt_measure,
aggregation_module.CountAggregation())
view_manager.register_view(prompt_view)
mmap = stats_recorder.new_measurement_map()
tmap = tag_map_module.TagMap()
def prompt():
input("Press enter.")
mmap.measure_int_put(prompt_measure, 1)
mmap.record(tmap)
metrics = list(mmap.measure_to_view_map.get_metrics(datetime.utcnow()))
print(metrics[0].time_series[0].points[0])
def main():
while True:
prompt()
if __name__ == "__main__":
main()
2. Al ejecutar el código varias veces, se le pedirá que seleccione Entrar . Se crea una métrica para realizar
el seguimiento del número de veces que se presiona la tecla Entrar . Con cada entrada, el valor se
incrementará y la información de la métrica se mostrará en la consola. La información incluye el valor
actual y la marca de tiempo actual en el momento en que se actualizó la métrica.
Press enter.
Point(value=ValueLong(5), timestamp=2019-10-09 20:58:04.930426)
Press enter.
Press enter.
3. Aunque introducir valores es útil con fines de demostración, la finalidad básica es emitir los datos de la
métrica a Azure Monitor. Pase la cadena de conexión directamente al exportador. O bien, puede
especificarlo en una variable de entorno APPLICATIONINSIGHTS_CONNECTION_STRING . Modifique el código
del paso anterior en función del ejemplo de código siguiente:
from datetime import datetime
from opencensus.ext.azure import metrics_exporter
prompt_measure = measure_module.MeasureInt("prompts",
"prompts")
prompt_view = view_module.View("prompt view",
[],
prompt_measure,
view_manager.register_view(prompt_view)

exporter = metrics_exporter.new_metrics_exporter(
view_manager.register_exporter(exporter)
def prompt():
input("Press enter.")
mmap.measure_int_put(prompt_measure, 1)
mmap.record(tmap)
metrics = list(mmap.measure_to_view_map.get_metrics(datetime.utcnow()))
print(metrics[0].time_series[0].points[0])
def main():
while True:
prompt()
if __name__ == "__main__":
main()
4. El exportador envía los datos de métricas a Azure Monitor según un intervalo fijo. El valor
predeterminado es cada 15 segundos. Se está realizando el seguimiento de una sola métrica. Por lo
tanto, los datos de esta métrica se envían en cada intervalo con el valor y la marca de tiempo que
contengan. Puede encontrar los datos en customMetrics .
De forma predeterminada, el exportador de métricas envía un conjunto de contadores de rendimiento a Azure
Monitor. Puede deshabilitar este comportamiento si establece la marca enable_standard_metrics en False en
el constructor del exportador de métricas.
...
exporter = metrics_exporter.new_metrics_exporter(
enable_standard_metrics=False,
connection_string='InstrumentationKey=<your-instrumentation-key-here>')
...
Estos contadores de rendimiento se envían actualmente:

Memoria disponible (bytes)
Tiempo de procesador de CPU (porcentaje)
Tasa de solicitudes entrantes (por segundo)
Tiempo de ejecución promedio de solicitudes entrantes (milisegundos)
Uso de CPU de proceso (porcentaje)
Bytes privados del proceso (bytes)
Debería poder ver estas métricas en performanceCounters . Para más información, consulte Contadores de
rendimiento.
Para obtener detalles sobre cómo modificar la telemetría sometida a seguimiento antes de enviarla a Azure
Monitor, vea los procesadores de telemetría de Python para OpenCensus.
Seguimiento
NOTE
En OpenCensus, tracing hace referencia al seguimiento distribuido. AzureExporter envía datos de telemetría de
requests y dependency a Azure Monitor.
1. En primer lugar, vamos a generar algunos datos de seguimiento localmente. En Python IDLE, o en el
editor que prefiera, escriba el código siguiente:
from opencensus.trace.samplers import ProbabilitySampler

from opencensus.trace.tracer import Tracer
tracer = Tracer(sampler=ProbabilitySampler(1.0))
def valuePrompt():
with tracer.span(name="test") as span:
print(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
2. Al ejecutar el código varias veces, se le pedirá que introduzca un valor. Con cada entrada, el valor se
imprime en el shell. El módulo de Python para OpenCensus genera una parte correspondiente de
SpanData . El proyecto OpenCensus define un seguimiento como un árbol de intervalos.
Enter a value: 4
4
[SpanData(name='test', context=SpanContext(trace_id=8aa41bc469f1a705aed1bdb20c342603, span_id=None,
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='15ac5123ac1f6847',
parent_span_id=None, attributes=BoundedDict({}, maxlen=32), start_time='2019-06-
27T18:21:22.805429Z', end_time='2019-06-27T18:21:44.933405Z', child_span_count=0, stack_trace=None,
annotations=BoundedList([], maxlen=32), message_events=BoundedList([], maxlen=128),
links=BoundedList([], maxlen=32), status=None, same_process_as_parent_span=None, span_kind=0)]
Enter a value: 25
25
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='2e512f846ba342de',
Enter a value: 100
100
trace_options=TraceOptions(enabled=True), tracestate=None), span_id='f3f9f9ee6db4740a',
3. Aunque introducir valores es útil con fines de demostración, la finalidad básica es emitir SpanData a
Azure Monitor. Pase la cadena de conexión directamente al exportador. O bien, puede especificarlo en
una variable de entorno APPLICATIONINSIGHTS_CONNECTION_STRING . Modifique el código del paso anterior
en función del ejemplo de código siguiente:
from opencensus.ext.azure.trace_exporter import AzureExporter


tracer = Tracer(
exporter=AzureExporter(
connection_string='InstrumentationKey=00000000-0000-0000-0000-000000000000'),
sampler=ProbabilitySampler(1.0),
)
def valuePrompt():
with tracer.span(name="test") as span:
print(line)
def main():
while True:
valuePrompt()
if __name__ == "__main__":
main()
4. Ahora, al ejecutar el script de Python, todavía se le seguirá pidiendo que especifique los valores, pero
en el shell solo se imprime el valor. El valor de SpanData creado se envía a Azure Monitor. Puede
encontrar los datos del intervalo emitidos en dependencies . Para obtener más información sobre las
solicitudes de salida, vea las dependencias de Python para OpenCensus. Para obtener más información
sobre las solicitudes de entrada, vea las solicitudes de Python para OpenCensus.
muestreo
Para información sobre el muestreo en OpenCensus, eche un vistazo al muestreo en OpenCensus.
Correlación de seguimiento
Para obtener más información sobre la correlación de telemetría de los datos de seguimiento, eche un vistazo
a la correlación de telemetría de Python para OpenCensus.
Para obtener más información sobre cómo modificar la telemetría sometida a seguimiento antes de enviarla a
Azure Monitor, vea los procesadores de telemetría de Python para OpenCensus.
Configuración de los exportadores de Azure Monitor

Como se muestra, hay tres exportadores de Azure Monitor diferentes que admiten OpenCensus. Cada uno
envía distintos tipos de telemetría a Azure Monitor. Para ver qué tipos de telemetría envía cada exportador,
consulte la lista siguiente.
Cada exportador acepta los mismos argumentos para la configuración, que se pasan a través de los
constructores. Aquí puede ver los detalles de cada uno de ellos:
connection_string : La cadena de conexión usada para conectarse a su recurso de Azure Monitor. Tiene
prioridad sobre instrumentation_key .
enable_standard_metrics : Usado para AzureMetricsExporter . Indica al exportador que envíe las métricas de
los contadores de rendimiento de forma automática a Azure Monitor. Su valor predeterminado es True .
export_interval : Se utiliza para especificar la frecuencia en segundos de exportación.
instrumentation_key : La clave de instrumentación utilizada para conectarse al recurso de Azure Monitor.
logging_sampling_rate : Usado para AzureLogHandler . Proporciona una frecuencia de muestreo [0, 1.0]
para exportar registros. Su valor predeterminado es 1.0.
max_batch_size : Especifica el tamaño máximo de la telemetría que se exporta a la vez.
proxies : Especifica una secuencia de servidores proxy que se va a usar para enviar datos a Azure Monitor.
Para obtener más información, consulte las proxies.
storage_path : Una ruta de acceso a la ubicación de la carpeta de almacenamiento local (telemetría sin
enviar). A partir del v1.0.3 de opencensus-ext-azure , la ruta de acceso predeterminada es el directorio
temporal del sistema operativo + opencensus-python + your-ikey . Antes de v1.0.3, la ruta de acceso
predeterminada es $USER + .opencensus + .azure + python-file-name .
Visualización de los datos con consultas

Puede ver los datos de telemetría que se enviaron desde la aplicación mediante la pestaña Registros
(Analytics) .
En la lista de Activo :
En el caso de la telemetría enviada con el exportador de seguimiento de Azure Monitor, las solicitudes
entrantes se muestran en requests . Las solicitudes salientes o en proceso se muestran en dependencies .
En el caso de la telemetría enviada con el exportador de métricas de Azure Monitor, las métricas enviadas
se muestran en customMetrics .
En el caso de la telemetría enviada con el exportador de registros de Azure Monitor, los registros se
muestran en traces . Las excepciones aparecen en exceptions .
Para obtener información más detallada sobre cómo usar las consultas y los registros, consulte Registros en
Azure Monitor.
Más información sobre OpenCensus para Python

Python de OpenCensus en GitHub
Personalización
Exportadores de Azure Monitor en GitHub
Integraciones de OpenCensus
Aplicaciones de ejemplo de Azure Monitor
Pasos siguientes
Seguimiento de las solicitudes entrantes
Seguimiento de las solicitudes salientes
Mapa de aplicación
Supervisión del rendimiento de un extremo a otro
Alertas
Pruebas de disponibilidad: cree pruebas para asegurarse de que el sitio sea visible en la Web.
Diagnósticos inteligentes: estas pruebas se realizan automáticamente, por lo que no es preciso hacer nada
para configurarlas. Le indican si la aplicación tiene una tasa de solicitudes con error inusual.
Alertas de métricas: Establezca alertas que le adviertan si una métrica supera un umbral. Puede
establecerlas en las métricas personalizadas que codifique en la aplicación.
Seguimiento de dependencias con OpenCensus
Python
Una dependencia es un componente externo al que la aplicación llama. Los datos de dependencia se recopilan con
OpenCensus Python y sus diversas integraciones. Los datos se envían después a Application Insights en Azure
Monitor como telemetría dependencies .
En primer lugar, instrumente la aplicación con el SDK de OpenCensus para Python más reciente.
Dependencias en proceso
El SDK de OpenCensus para Python para Azure Monitor le permite enviar datos de telemetría de dependencias "en
proceso" (información y lógica que se produce dentro de la aplicación). Las dependencias en proceso tendrán el
campo type como INPROC en Analytics.

tracer = Tracer(exporter=AzureExporter(connection_string="InstrumentationKey=<your-ikey-here>"),
sampler=ProbabilitySampler(1.0))
with tracer.span(name='foo'): # <-- A dependency telemetry item will be sent for this span "foo"
print('Hello, World!')
Dependencias con la integración de "solicitudes"

Realice un seguimiento de las solicitudes salientes con la integración de requests de OpenCensus.
Descargue e instale opencensus-ext-requests desde PyPI y agréguelo a las integraciones de seguimiento. Se
realizará un seguimiento de las solicitudes enviadas que usan la biblioteca de solicitudes de Python.
import requests
from opencensus.trace import config_integration
config_integration.trace_integrations(['requests']) # <-- this line enables the requests integration
tracer = Tracer(exporter=AzureExporter(connection_string="InstrumentationKey=<your-ikey-here>"),
sampler=ProbabilitySampler(1.0))
with tracer.span(name='parent'):
response = requests.get(url='https://www.wikipedia.org/wiki/Rabbit') # <-- this request will be tracked
Dependencias con la integración de "httplib"

Realice un seguimiento de las solicitudes salientes con la integración de httplib de OpenCensus.
Descargue e instale opencensus-ext-httplib desde PyPI y agréguelo a las integraciones de seguimiento. Se
realizará un seguimiento de las solicitudes enviadas mediante http.client para Python3 o httplib para Python2.
import http.client as httplib

config_integration.trace_integrations(['httplib'])
conn = httplib.HTTPConnection("www.python.org")
tracer = Tracer(
exporter=AzureExporter(),
sampler=ProbabilitySampler(1.0)
)
conn.request("GET", "http://www.python.org", "", {})

response = conn.getresponse()
conn.close()
Dependencias con la integración de "django"

Realice un seguimiento de las solicitudes salientes de Django con la integración de django de OpenCensus.
NOTE
Las únicas solicitudes de Django de salida de las que se realiza un seguimiento son las llamadas a una base de datos. Para las
solicitudes realizadas a la aplicación de Django, consulte solicitudes entrantes.
Descargue e instale opencensus-ext-django desde PyPI y agregue la siguiente línea a la sección MIDDLEWARE del
archivo settings.py de Django.
MIDDLEWARE = [
...
'opencensus.ext.django.middleware.OpencensusMiddleware',
]
Se puede proporcionar una configuración adicional; consulte las personalizaciones para obtener una referencia
completa.
OPENCENSUS = {
'TRACE': {
'SAMPLER': 'opencensus.trace.samplers.ProbabilitySampler(rate=1)',
'EXPORTER': '''opencensus.ext.azure.trace_exporter.AzureExporter(
connection_string="InstrumentationKey=<your-ikey-here>"
)''',
}
}
Dependencias con la integración de "mysql"

Realice un seguimiento de las solicitudes salientes de MySQL con la integración de mysql de OpenCensus. Esta
integración es compatible con la biblioteca de MySQL-Connector.
Descargue e instale opencensus-ext-mysql desde PyPI y agregue las líneas siguientes al código.
config_integration.trace_integrations(['mysql'])
Dependencias con la integración de "pymysql"

Realice un seguimiento de las dependencias de PyMySQL con la integración de pymysql de OpenCensus.
Descargue e instale opencensus-ext-pymysql desde PyPI y agregue las líneas siguientes al código.
config_integration.trace_integrations(['pymysql'])
Dependencias con la integración de "postgreSQL"

Realice un seguimiento de las dependencias de PostgreSQL con la integración de postgresql de OpenCensus.
Esta integración es compatible con la biblioteca psycopg2.
Descargue e instale opencensus-ext-postgresql desde PyPI y agregue las líneas siguientes al código.
config_integration.trace_integrations(['postgresql'])
Dependencias con la integración de "pymongo"

Realice un seguimiento de las dependencias de MongoDB con la integración de pymongo de OpenCensus. Esta
integración es compatible con la biblioteca pymongo.
Descargue e instale opencensus-ext-pymongo desde PyPI y agregue las líneas siguientes al código.
config_integration.trace_integrations(['pymongo'])
Dependencias con la integración de "sqlalchemy"

Realice un seguimiento de las dependencias mediante SQLAlchemy con la integración de sqlalchemy de
OpenCensus. Esta integración realiza un seguimiento del uso del paquete sqlalchemy, independientemente de la
base de datos subyacente.
config_integration.trace_integrations(['sqlalchemy'])
Pasos siguientes
Mapa de aplicación
Disponibilidad
Búsqueda
Consulta de Log (Analytics)
Diagnósticos de transacción
Seguimiento de las solicitudes entrantes con
OpenCensus para Python
Los datos de solicitudes entrantes se recopilan con OpenCensus para Python y sus diversas integraciones. Realice
el seguimiento de los datos de solicitudes entrantes enviados a las aplicaciones web creadas sobre los marcos
web más populares django , flask y pyramid . Los datos se envían después a Application Insights en Azure
Monitor como telemetría requests .
En primer lugar, instrumente la aplicación con el SDK de OpenCensus para Python más reciente.
Seguimiento de aplicaciones de Django

1. Descargue e instale opencensus-ext-django de PyPI e instrumente la aplicación con el middleware de
django . Se realizará el seguimiento de las solicitudes entrantes enviadas a la aplicación django .
2. Incluya opencensus.ext.django.middleware.OpencensusMiddleware en el archivo settings.py en MIDDLEWARE .
MIDDLEWARE = (
...
'opencensus.ext.django.middleware.OpencensusMiddleware',
...
)
3. Asegúrese de que AzureExporter está configurado correctamente en settings.py en OPENCENSUS . Para las
solicitudes de direcciones URL de las que no quiera realizar el seguimiento, agréguelas a BLACKLIST_PATHS .
OPENCENSUS = {
'TRACE': {
'SAMPLER': 'opencensus.trace.samplers.ProbabilitySampler(rate=1)',
connection_string="InstrumentationKey=<your-ikey-here>"
)''',
'BLACKLIST_PATHS': ['https://example.com'], <--- These sites will not be traced if a request
is sent to it.
}
}
Seguimiento de aplicaciones de Flask

1. Descargue e instale opencensus-ext-flask de PyPI e instrumente la aplicación con el middleware de flask .
Se realizará el seguimiento de las solicitudes entrantes enviadas a la aplicación flask .
from flask import Flask
from opencensus.ext.flask.flask_middleware import FlaskMiddleware
app = Flask(__name__)
middleware = FlaskMiddleware(
app,
exporter=AzureExporter(connection_string="InstrumentationKey=<your-ikey-here>"),
sampler=ProbabilitySampler(rate=1.0),
)
@app.route('/')
def hello():
return 'Hello World!'
if __name__ == '__main__':
app.run(host='localhost', port=8080, threaded=True)
2. También puede configurar la aplicación de flask mediante app.config . Para las solicitudes de direcciones
URL de las que no quiera realizar el seguimiento, agréguelas a BLACKLIST_PATHS .
app.config['OPENCENSUS'] = {
'TRACE': {
'SAMPLER': 'opencensus.trace.samplers.ProbabilitySampler(rate=1.0)',
connection_string="InstrumentationKey=<your-ikey-here>",
)''',
'BLACKLIST_PATHS': ['https://example.com'], <--- These sites will not be traced if a request
is sent to it.
}
}
Seguimiento de aplicaciones de Pyramid

1. Descargue e instale opencensus-ext-django de PyPI e instrumente la aplicación con la interpolación de
pyramid . Se realizará el seguimiento de las solicitudes entrantes enviadas a la aplicación pyramid .
def main(global_config, **settings):

config = Configurator(settings=settings)
config.add_tween('opencensus.ext.pyramid'
'.pyramid_middleware.OpenCensusTweenFactory')
2. Puede configurar la interpolación de pyramid directamente en el código. Para las solicitudes de direcciones
URL de las que no quiera realizar el seguimiento, agréguelas a BLACKLIST_PATHS .
settings = {
'OPENCENSUS': {
'TRACE': {
'SAMPLER': 'opencensus.trace.samplers.ProbabilitySampler(rate=1.0)',
connection_string="InstrumentationKey=<your-ikey-here>",
)''',
'BLACKLIST_PATHS': ['https://example.com'], <--- These sites will not be traced if a
request is sent to it.
}
}
}
config = Configurator(settings=settings)
Pasos siguientes
Mapa de aplicación
Disponibilidad
Búsqueda
Consulta de Log (Analytics)
Application Insights para páginas web
Obtenga información sobre el rendimiento y la utilización de su página web o aplicación. Si

agrega Application Insights al script de la página, obtendrá los intervalos de carga de la
página y de las llamadas AJAX, recuentos y detalles sobre las excepciones del explorador y los
errores de AJAX, así como usuarios y recuentos de sesiones. Todos estos datos se pueden
segmentar por página, sistema operativo del cliente y versión del explorador, geolocalización
y otras dimensiones. Puede establecer alertas sobre recuentos de errores o sobre cargas de
página lentas. Y mediante la inserción de llamadas de seguimiento en el código de JavaScript,
puede controlar cómo se utilizan las distintas características de la aplicación de la página web.
Puede utilizar Application Insights con cualquier página web, solo tiene que agregar un
pequeño fragmento de JavaScript. Si el servicio web es Java o ASP.NET, puede usar los SDK
del lado servidor junto con el SDK de JavaScript del lado cliente para obtener una descripción
completa del rendimiento de la aplicación.
Adición del SDK de JavaScript

1. En primer lugar, necesita un recurso de Application Insights. Si aún no tiene un recurso y
una clave de instrumentación, siga las instrucciones para crear un nuevo recurso.
2. Copie la clave de instrumentación (también conocida como "iKey") del recurso al que
desea que se envíe la telemetría de JavaScript (del paso 1). Lo agregará al valor
instrumentationKey del SDK de JavaScript de Application Insights.
3. Agregue el SDK de JavaScript de Application Insights a su página web o aplicación
mediante una de las dos opciones siguientes:
Configuración de npm
Fragmento de código Javascript
IMPORTANT
Use solo un método para agregar el SDK de JavaScript a la aplicación. Si usa el programa de
instalación de NPM, no use el fragmento de código y viceversa.
NOTE
El programa de instalación de NPM instala el SDK de JavaScript como una dependencia del proyecto,
habilitando IntelliSense, mientras que el fragmento de código captura el SDK en tiempo de ejecución.
Ambos admiten las mismas características. Sin embargo, los desarrolladores que desean más eventos
y configuración personalizados normalmente optan por el programa de instalación de NPM, mientras
que los usuarios que buscan una habilitación rápida del análisis web integrado optan por el
fragmento de código.
Configuración basada en npm

Instale a través de NPM.
npm i --save @microsoft/applicationinsights-web

NOTE
Con este paquete se incluyen typings , por lo que no necesita instalar un paquete de typings
independiente.
import { ApplicationInsights } from '@microsoft/applicationinsights-web'
const appInsights = new ApplicationInsights({ config: {

instrumentationKey: 'YOUR_INSTRUMENTATION_KEY_GOES_HERE'
} });
appInsights.loadAppInsights();
appInsights.trackPageView(); // Manually call trackPageView to establish the current
user/session/pageview
Configuración basada en fragmento de código

Si su aplicación no usa npm, puede instrumentar directamente las páginas web con
Application Insights pegando este fragmento de código en la parte superior de cada una de
las páginas. Preferiblemente, debe ser el primer script de la sección <head> para que pueda
supervisar cualquier posible problema con todas las dependencias y, opcionalmente,
cualquier error de JavaScript. Si usa una aplicación de servidor de Blazor, agregue el
fragmento de código en la parte superior del archivo _Host.cshtml en la sección <head> .
Para ayudar a realizar un seguimiento de la versión del fragmento de código que la aplicación
usa, a partir de la versión 2.5.5, el evento de vista de página incluirá una nueva etiqueta
"ai.internal.snippet" que contendrá la versión de fragmento de código identificada.
El fragmento de código actual (que se muestra a continuación) se identificará como la versión
"3".
!function(T,l,y){var
S=T.location,u="script",k="instrumentationKey",D="ingestionendpoint",C="disableExceptionTr
acking",E="ai.device.",I="toLowerCase",b="crossOrigin",w="POST",e="appInsightsSDK",t=y.nam
e||"appInsights";(y.name||T[e])&&(T[e]=t);var n=T[t]||function(d){var g=!1,f=!1,m=
{initialize:!0,queue:[],sv:"4",version:2,config:d};function v(e,t){var n=
{},a="Browser";return n[E+"id"]=a[I]
(),n[E+"type"]=a,n["ai.operation.name"]=S&&S.pathname||"_unknown_",n["ai.internal.sdkVersi
on"]="javascript:snippet_"+(m.sv||m.version),{time:function(){var e=new Date;function t(e)
{var t=""+e;return 1===t.length&&(t="0"+t),t}return e.getUTCFullYear()+"-
"+t(1+e.getUTCMonth())+"-
"+t(e.getUTCDate())+"T"+t(e.getUTCHours())+":"+t(e.getUTCMinutes())+":"+t(e.getUTCSeconds(
))+"."+((e.getUTCMilliseconds()/1e3).toFixed(3)+"").slice(2,5)+"Z"}
(),iKey:e,name:"Microsoft.ApplicationInsights."+e.replace(/-
/g,"")+"."+t,sampleRate:100,tags:n,data:{baseData:{ver:2}}}}var h=d.url||y.src;if(h)
{function a(e){var t,n,a,i,r,o,s,c,p,l,u;g=!0,m.queue=[],f||(f=!0,t=h,s=function(){var e=
{},t=d.connectionString;if(t)for(var n=t.split(";"),a=0;a<n.length;a++){var
i=n[a].split("=");2===i.length&&(e[i[0][I]()]=i[1])}if(!e[D]){var r=e.endpointsuffix,o=r?
e.location:null;e[D]="https://"+(o?o+".":"")+"dc."+(r||"services.visualstudio.com")}return
e}(),c=s[k]||d[k]||"",p=s[D],l=p?p+"/v2/track":config.endpointUrl,(u=[]).push((n="SDK LOAD
Failure: Failed to load Application Insights SDK script (See stack for details)",a=t,i=l,
(o=(r=v(c,"Exception")).data).baseType="ExceptionData",o.baseData.exceptions=
[{typeName:"SDKLoadFailed",message:n.replace(/\./g,"-"),hasFullStack:!1,stack:n+"\nSnippet
failed to load ["+a+"] -- Telemetry is disabled\nHelp Link:
https://go.microsoft.com/fwlink/?linkid=2128109\nHost: "+
(S&&S.pathname||"_unknown_")+"\nEndpoint: "+i,parsedStack:
[]}],r)),u.push(function(e,t,n,a){var
i=v(c,"Message"),r=i.data;r.baseType="MessageData";var o=r.baseData;return o.message='AI
(Internal): 99 message:"'+("SDK LOAD Failure: Failed to load Application Insights SDK
script (See stack for details) ("+n+")").replace(/\"/g,"")+'"',o.properties=
{endpoint:a},i}(0,0,t,l)),function(e,t){if(JSON){var n=T.fetch;if(n&&!y.useXhr)n(t,
{method:w,body:JSON.stringify(e),mode:"cors"});else if(XMLHttpRequest){var a=new
XMLHttpRequest;a.open(w,t),a.setRequestHeader("Content-
type","application/json"),a.send(JSON.stringify(e))}}}(u,l))}function i(e,t)
{f||setTimeout(function(){!t&&m.core||a()},500)}var e=function(){var
n=l.createElement(u);n.src=h;var e=y[b];return!e&&""!==e||"undefined"==n[b]||
(n[b]=e),n.onload=i,n.onerror=a,n.onreadystatechange=function(e,t)
{"loaded"!==n.readyState&&"complete"!==n.readyState||i(0,t)},n}();y.ld<0?
l.getElementsByTagName("head")[0].appendChild(e):setTimeout(function()
{l.getElementsByTagName(u)
[0].parentNode.appendChild(e)},y.ld||0)}try{m.cookie=l.cookie}catch(p){}function t(e)
{for(;e.length;)!function(t){m[t]=function(){var e=arguments;g||m.queue.push(function()
{m[t].apply(m,e)})}}(e.pop())}var
n="track",r="TrackPage",o="TrackEvent";t([n+"Event",n+"PageView",n+"Exception",n+"Trace",n
+"DependencyData",n+"Metric",n+"PageViewPerformance","start"+r,"stop"+r,"start"+o,"stop"+o
,"addTelemetryInitializer","setAuthenticatedUserContext","clearAuthenticatedUserContext","
flush"]),m.SeverityLevel={Verbose:0,Information:1,Warning:2,Error:3,Critical:4};var s=
(d.extensionConfig||{}).ApplicationInsightsAnalytics||{};if(!0!==d[C]&&!0!==s[C])
{method="onerror",t(["_"+method]);var c=T[method];T[method]=function(e,t,n,a,i){var
r=c&&c(e,t,n,a,i);return!0!==r&&m["_"+method]
({message:e,url:t,lineNumber:n,columnNumber:a,error:i}),r},d.autoExceptionInstrumented=!0}
return m}(y.cfg);(T[t]=n).queue&&0===n.queue.length&&n.trackPageView({})}(window,document,
{
src: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js", // The SDK URL Source
//name: "appInsights", // Global SDK Instance name defaults to "appInsights" when not
supplied
//ld: 0, // Defines the load delay (in ms) before attempting to load the sdk. -1 = block
page load and add to head. (default) = 0ms load after timeout,
//useXhr: 1, // Use XHR instead of fetch to report failures (if available),
//crossOrigin: "anonymous", // When supplied this will add the provided value as the cross
origin attribute on the script tag
}});
</script>
NOTE
Para mejorar la legibilidad y reducir errores potenciales de JavaScript, todas las opciones de
configuración posibles se muestran en una nueva línea en el código del fragmento de código anterior.
Si no desea cambiar el valor de una línea comentada, se puede quitar.
Informes de errores de carga de script

Esta versión del fragmento detecta errores e informa de ellos al cargar el SDK desde la red
CDN como una excepción en el portal de Azure Monitor (en errores > excepciones >
explorador). Esta excepción proporciona visibilidad en los errores de este tipo para que tenga
en cuenta que la aplicación no informa de la telemetría (u otras excepciones) según lo
esperado. Esta señal es una medida importante para comprender que ha perdido la telemetría
porque el SDK no se cargó o se inicializó, lo que puede dar lugar a:
Informes incompletos del uso que los usuarios están haciendo (o intentan hacer ) del sitio;
Falta de telemetría sobre el modo en que los usuarios finales usan su sitio;
Ausencia de errores de JavaScript que podrían estar impidiendo que los usuarios finales
usaran el sitio correctamente.
Para obtener detalles sobre esta excepción, vea la página de solución de problemas Error de
carga del SDK.
Los informes de este error como una excepción en el portal no usan la opción de
configuración disableExceptionTracking de la configuración de Application Insights y, por
tanto, si se produce este error, el fragmento de código siempre lo notificará, aunque la
compatibilidad con window.onerror esté deshabilitada.
Los informes de errores de carga del SDK NO se admiten específicamente en IE 8 (o versiones
inferiores). Esto ayuda a disminuir el tamaño reducido del fragmento de código suponiendo
que la mayoría de los entornos no usan exclusivamente IE 8 o una versión inferior. Si tiene
este requisito y desea recibir estas excepciones, deberá incluir un polyfill de fetch o crear su
propia versión de fragmento de código que use XDomainRequest en lugar de XMLHttpRequest .
Se recomienda usar el código fuente del fragmento de código proporcionado como punto de
partida.
NOTE
Si usa una versión anterior del fragmento de código, se recomienda encarecidamente que actualice a
la versión más reciente para que reciba estos problemas no notificados previamente.
Opciones de configuración del fragmento de código

Ahora, todas las opciones de configuración se han trasladado al final del script para evitar la
introducción accidental de errores de JavaScript que no solo harían que el SDK no pudiera
cargarse, sino que también deshabilitaría la notificación del error.
Cada opción de configuración se muestra arriba en una nueva línea. Si no desea invalidar el
valor predeterminado de un elemento mostrado como [opcional], puede quitar esa línea para
minimizar el tamaño resultante de la página devuelta.
Las opciones de configuración disponibles son las siguientes:
N O M B RE T IP O DESC RIP C IÓ N
src string [obligatorio] Dirección URL completa desde

la que se va a cargar el SDK.
Este valor se usa para el
atributo "src" de una etiqueta
<script /> agregada
dinámicamente. Puede usar la
ubicación de la red CDN pública
o la suya propia hospedada de
forma privada.
name cadena [opcional] El nombre global del SDK

inicializado. El valor
predeterminado es
appInsights . Por lo tanto,
window.appInsights será una
referencia a la instancia
inicializada. Nota: Si proporciona
un valor de nombre o una
instancia anterior parece estar
asignada (mediante el nombre
global appInsightsSDK), este
valor de nombre también se
definirá en el espacio de
nombres global como
window.appInsightsSDK=
<name value>
. El código de inicialización del
SDK requiere todo esto para
asegurarse de que está
inicializando y actualizando los
métodos de proxy y esqueleto
del fragmento de código
correctos.
ld número en ms [opcional] Define el retraso de carga que

se debe esperar antes de
intentar cargar el SDK. El valor
predeterminado es 0 ms y
cualquier valor negativo
agregará una etiqueta de script
inmediatamente a la región
<head> de la página, que luego
bloqueará el evento de carga de
la página hasta que se cargue el
script (o se produzca un error).
useXhr booleano [opcional] Este valor solo se usa para

notificar errores de carga del
SDK. Los informes intentarán
primero usar fetch() si está
disponible y luego recurrirán a
XHR. Si establece este valor en
true, simplemente se omitirá la
comprobación de fetch. El uso
de este valor solo es necesario
si la aplicación se usa en un
entorno en el que fetch no
enviaría los eventos de error.
crossOrigin cadena [opcional] Al incluir este valor, la etiqueta

de script agregada para
descargar el SDK incluirá el
atributo crossOrigin con este
valor de cadena. Cuando no se
define (que es la opción
predeterminada), no se agrega
ningún atributo crossOrigin. Los
valores recomendados no se
definen (que es la opción
predeterminada); ""; o
"anonymous" (para todos los
valores válidos, consulte la
documentación Atributo HTML:
crossorigin )
cfg objeto [obligatorio] Se trata de la configuración

pasada al SDK de Application
Insights durante la inicialización.
Envío de telemetría a Azure Portal

De forma predeterminada, el SDK de JavaScript de Application Insights recopila
automáticamente un número de elementos de telemetría que son útiles para determinar el
estado de la aplicación y la experiencia del usuario subyacente. Entre ellas se incluyen las
siguientes:
Excepciones no detectadas en la aplicación, incluida información sobre lo siguiente:
Seguimiento de la pila
Detalles de la excepción y mensaje que acompaña al error
Número de línea y columna del error
Dirección URL en la que se produjo el error
Solicitudes de dependencia de red realizadas por las solicitudes XHR and Fetch (la
recopilación de capturas está deshabilitada de forma predeterminada) de la aplicación,
incluida información sobre lo siguiente:
Dirección URL del origen de dependencia
Comando y método usado para solicitar la dependencia
Duración de la solicitud
Código de resultado y estado correcto de la solicitud
Identificador (si existe) del usuario que realiza la solicitud
Contexto de correlación (si existe) en el que se realiza la solicitud
Información del usuario (por ejemplo, ubicación, red, IP)
Información del dispositivo (por ejemplo, explorador, sistema operativo, versión,
idioma, modelo)
Información de la sesión
Inicializadores de telemetría
Los inicializadores de telemetría se usan para modificar el contenido de la telemetría
recopilada antes de enviarla desde el explorador del usuario. También se pueden usar para
impedir que se envíen determinados datos de telemetría, devolviendo false . Se pueden
agregar varios inicializadores de telemetría a la instancia de Application Insights, que se
ejecutarán en el orden en el que se han agregado.
El argumento de entrada en addTelemetryInitializer es una devolución de llamada que toma
ITelemetryItem como argumento y devuelve boolean o void . Si devuelve false , no se
envía el elemento de telemetría, sino que pasa al siguiente inicializador de telemetría, si existe,
o se envía al punto de conexión de recopilación de telemetría.
Ejemplo de uso de inicializadores de telemetría:
var telemetryInitializer = (envelope) => {

envelope.data.someField = 'This item passed through my telemetry initializer';
};
appInsights.addTelemetryInitializer(telemetryInitializer);
appInsights.trackTrace({message: 'This message will use a telemetry initializer'});
appInsights.addTelemetryInitializer(() => false); // Nothing is sent after this is

executed
appInsights.trackTrace({message: 'this message will not be sent'}); // Not sent
Configuración
La mayoría de los campos de configuración tienen un nombre que permite establecer false
como valor predeterminado. Todos los campos son opcionales, excepto instrumentationKey .
N O M B RE VA LO R P REDET ERM IN A DO DESC RIP C IÓ N
instrumentationKey null Obligatorio

La clave de instrumentación que
ha obtenido en Azure Portal.
accountId null Un identificador de cuenta

opcional, si su aplicación agrupa
a los usuarios en cuentas. Sin
espacios, comas, puntos y
comas, signos igual o barras
verticales.
sessionRenewalMs 1800000 Se registra una sesión si el

usuario está inactivo durante
este período de tiempo en
milisegundos. El valor
predeterminado es 30 minutos.
sessionExpirationMs 86400000 Se registra una sesión si ha

continuado durante este
período de tiempo en
milisegundos. El valor
predeterminado es 24 horas.
maxBatchSizeInBytes 10 000 Tamaño máximo del lote de

telemetría. Si un lote supera
este límite, se envía
inmediatamente y se inicia un
nuevo lote.
maxBatchInterval 15000 Cuánto tiempo deben recopilar

datos de telemetría en lote
antes de enviarlos
(milisegundos).
disableExceptionTracking false Si es true, las excepciones no se

recopilan automáticamente. El
valor predeterminado es False.
disableTelemetry false Si es true, no se recopila ni se

envía la telemetría. El valor
predeterminado es False.
enableDebug false Si es true, los datos de

depuración internos se
devuelven como una excepción
en lugar de registrarse,
independientemente de la
configuración de registro del
SDK. El valor predeterminado es
False.
Nota: Si se habilita este valor,
se descartará la telemetría
siempre que se produzca un
error interno. Esto puede ser
útil para identificar rápidamente
problemas con la configuración
o el uso del SDK. Si no desea
perder telemetría durante la
depuración, considere la
posibilidad de usar
consoleLoggingLevel o
telemetryLoggingLevel en
lugar de enableDebug .
loggingLevelConsole 0 Registra errores internos de

Application Insights en la
consola.
0: desactivado
1: solo errores críticos
2: todo (errores y advertencias)
loggingLevelTelemetry 1 Envía errores internos de

Application Insights como
telemetría.
0: desactivado
1: solo errores críticos
2: todo (errores y advertencias)
diagnosticLogInterval 10 000 (interno) Intervalo de sondeo

(en milisegundos) para la cola
de registro interno
samplingPercentage 100 Porcentaje de eventos que se

enviarán. El valor
predeterminado es 100, lo que
significa que se envían todos los
eventos. Establézcalo si desea
conservar el límite de datos
para aplicaciones a gran escala.
autoTrackPageVisitTime false Si es true, en una vista de

página, se realiza un
seguimiento del tiempo de
visualización de la página
instrumentada anterior, que se
envía como telemetría, y se
inicia un nuevo temporizador
para la vista de página actual. El
valor predeterminado es False.
disableAjaxTracking false Si es true, las llamadas Ajax no

se recopilan automáticamente.
El valor predeterminado es
False.
disableFetchTracking true Si es true, las solicitudes Fetch

no se recopilan
automáticamente. El valor
predeterminado es true.
overridePageViewDuration false Si es true, el comportamiento

predeterminado de
trackPageView se cambia para
registrar el final del intervalo de
duración de la vista de página
cuando se llama a
trackPageView. Si es false y no
se proporciona ninguna
duración personalizada a
trackPageView, el rendimiento
de la vista de página se calcula
mediante la API de tiempos de
navegación. El valor
maxAjaxCallsPerView 500 El valor predeterminado es 500:

controla cuántas llamadas AJAX
se supervisarán por vista de
página. Establézcalo en -1 para
supervisar todas las llamadas
AJAX (ilimitadas) en la página.
disableDataLossAnalysis true Si es false, se comprobará al

inicio en los búferes del
remitente de telemetría interna
si hay elementos que todavía
no se hayan enviado.
disableCorrelationHeaders false Si es false, el SDK agregará dos

encabezados ("Request-Id" y
"Request-Context") a todas las
solicitudes de dependencia para
correlacionarlas con las
solicitudes correspondientes en
el lado servidor. El valor
correlationHeaderExcludedDom Deshabilite encabezados de

ains correlación para dominios
específicos.
correlationHeaderDomains Habilite encabezados de

correlación para dominios
específicos.
disableFlushOnBeforeUnload false El valor predeterminado es false.

Si es true, no se llamará al
método Flush cuando se
desencadene un evento
onBeforeUnload.
enableSessionStorageBuffer true El valor predeterminado es true.

Si es true, el búfer con toda la
telemetría no enviada se guarda
en el almacenamiento de la
sesión. El búfer se restaura al
cargar la página.
isCookieUseDisabled false El valor predeterminado es false.

Si es true, el SDK no almacenará
ni leerá ningún dato de las
cookies.
cookieDomain null Dominio de cookies

personalizado. Resulta útil si
desea compartir cookies de
Application Insights entre
subdominios.
isRetryDisabled false El valor predeterminado es false.

Si es false, se produce un
reintento con los errores 206
(parcialmente correcto), 408
(tiempo de espera), 429
(demasiadas solicitudes), 500
(error interno del servidor), 503
(servicio no disponible) y 0 (sin
conexión, solo si se detecta).
isStorageUseDisabled false Si es true, el SDK no almacenará

ni leerá ningún dato del
almacenamiento local o de la
sesión. El valor predeterminado
es False.
isBeaconApiDisabled true Si es false, el SDK enviará toda

la telemetría mediante Beacon
API.
onunloadDisableBeacon false El valor predeterminado es false.

Si la pestaña está cerrada, el
SDK enviará la telemetría
restante mediante la API
Beacon .
sdkExtension null Establece el nombre de la

extensión del SDK. Solo puede
contener caracteres alfabéticos.
El nombre de la extensión se
agrega como prefijo a la
etiqueta "ai.internal.sdkVersion"
(por ejemplo,
"ext_javascript:2.0.0"). El valor
predeterminado es null.
isBrowserLinkTrackingEnabled false El valor predeterminado es

False. Si es true, el SDK realizará
un seguimiento de todas las
solicitudes de Vínculo con
exploradores.
appId null AppId se utiliza para la

correlación entre las
dependencias AJAX que se
producen en el lado cliente con
las solicitudes del lado servidor.
Cuando Beacon API está
habilitada, no se puede usar
automáticamente, pero se
puede establecer manualmente
en la configuración. El valor
predeterminado es null.
enableCorsCorrelation false Si es true, el SDK agregará dos

encabezados ("Request-Id" y
"Request-Context") a todas las
solicitudes CORS para
correlacionar dependencias
AJAX salientes con las
solicitudes correspondientes en
el lado servidor. El valor
predeterminado es false.
namePrefix no definido Un valor opcional que se usará

como sufijo de nombre para el
nombre de cookies y
localStorage.
enableAutoRouteTracking false Realice un seguimiento

automático de los cambios de
ruta en aplicaciones de página
única (SPA). Si es true, cada
cambio de ruta enviará una
nueva vista de página a
Application Insights. Los
cambios de ruta hash (
example.com/foo#bar )
también se registran como
nuevas vistas de página.
enableRequestHeaderTracking false Si es true, se realiza un

seguimiento de los encabezados
de solicitud AJAX y Fetch. El
valor predeterminado es false.
enableResponseHeaderTracking false Si es true, se realiza un

seguimiento de los encabezados
de respuesta de solicitud AJAX
y Fetch. El valor predeterminado
es false.
distributedTracingMode DistributedTracingModes.AI Establece del modo de

seguimiento distribuido. Si se
establece el modo
AI_AND_W3C o el modo W3C,
se generarán los encabezados
de contexto de seguimiento
W3C (traceparent/tracestate) y
se incluirán en todas las
solicitudes salientes.
AI_AND_W3C se proporciona
para la compatibilidad con
versiones anteriores de
cualquier servicio
instrumentado de Application
Insights heredado. Consulte el
ejemplo aquí.
enableAjaxErrorStatusText false El valor predeterminado es false.

Si es true, incluye el texto de
datos de error de respuesta en
el evento de dependencia en
solicitudes AJAX erróneas.
enableAjaxPerfTracking false El valor predeterminado es false.

Marca para habilitar la
búsqueda y la inclusión de
intervalos de
window.performance de
explorador adicionales en las
métricas notificadas de ajax
(XHR y Fetch).
maxAjaxPerfLookupAttempts 3 El valor predeterminado es 3.

Número máximo de veces que
se deben buscar los intervalos
de window.performance (si
están disponibles). Esto es
necesario, ya que no todos los
exploradores rellenan
window.performance antes de
notificar el final de la solicitud
de XHR y para las solicitudes de
fetch se agregan después de su
terminación.
ajaxPerfLookupDelay 25 Su valor predeterminado es

25 ms. Cantidad de tiempo que
hay que esperar antes de volver
a intentar encontrar los
intervalos de
windows.performance para una
solicitud ajax . El tiempo se da
en milisegundos y se pasa
directamente a setTimeout().
enableUnhandledPromiseRejecti false Si es true, los rechazos de

onTracking promise no controlados se
recopilarán automáticamente y
se notificarán como un error de
JavaScript. Cuando
disableExceptionTracking es true
(no realizar seguimiento de
excepciones), el valor de
configuración se omite y los
rechazos de promise no
controlados no se notifican.
Aplicaciones de página única

De forma predeterminada, este SDK no controlará el cambio de ruta basado en el estado que
se produce en las aplicaciones de página única. Para habilitar el seguimiento automático de
cambios de ruta para una aplicación de página única, puede agregar
enableAutoRouteTracking: true a la configuración de instalación.
Actualmente, ofrecemos un complemento React independiente que puede inicializarse con

este SDK. También llevará a cabo el seguimiento de cambios de ruta, así como la recopilación
de otros datos de telemetría específicos de React.
NOTE
Use enableAutoRouteTracking: true solo si no está usando el complemento React. Ambos
pueden enviar nuevos valores PageView cuando cambia la ruta. Si ambos están habilitados, es posible
que se envíen valores de PageView duplicados.
Configuración: autoTrackPageVisitTime
Al establecer autoTrackPageVisitTime: true , se realiza un seguimiento del tiempo que un
usuario permanece en cada página. En cada instancia nueva de PageView, el tiempo que pasó
el usuario en la página anterior (previous) se envía como una métrica personalizada
denominada PageVisitTime . Esta métrica personalizada es visible en el Explorador de
métricas como "Métricas basadas en registros".
Extensiones de React
EXT EN SIO N ES
React
EXT EN SIO N ES
React Native
Correlación
La correlación entre el cliente y el servidor es compatible con:
Solicitudes XHR/AJAX
Solicitudes Fetch
La correlación entre el cliente y el servidor no es compatible con solicitudes GET ni POST .
Habilitación de la correlación entre componentes entre las solicitudes de servidor y AJAX
de cliente
Para habilitar la correlación CORS , el cliente debe enviar dos encabezados de solicitud
adicionales Request-Id y Request-Context , y el lado servidor debe poder aceptar conexiones
con los encabezados presentes. El envío de estos encabezados se habilita estableciendo
enableCorsCorrelation: true dentro de la configuración del SDK de JavaScript.
En función de la configuración de Access-Control-Allow-Headers en el lado servidor, a menudo

es necesario extender la lista del lado servidor mediante la adición manual de Request-Id y
Request-Context .
Access-Control-Allow-Headers: Request-Id , Request-Context , <your header>
Si alguno de los servidores de terceros con los que se comunica el cliente no puede aceptar
los encabezados Request-Id y Request-Context , y no es posible actualizar su configuración,
deberá colocarlos en una lista de exclusión a través de la propiedad de configuración
correlationHeaderExcludeDomains . Esta propiedad admite caracteres comodín.
// excerpt of the config section of the JavaScript SDK snippet with correlation
// between client-side AJAX and server requests enabled.
enableCorsCorrelation: true,
correlationHeaderExcludedDomains: ['myapp.azurewebsites.net',
'*.queue.core.windows.net']
}});
</script>
Exploración de datos del explorador o del lado cliente

Para ver datos del explorador o del lado cliente, vaya a Métricas y agregue métricas
individuales que le interesen:
También puede ver los datos desde el SDK de JavaScript mediante la experiencia de
explorador en el portal.
Seleccione Explorador y, a continuación, elija Errores o Rendimiento .
Rendimiento
Dependencias
Análisis
Para consultar la telemetría recopilada por el SDK de JavaScript, seleccione el botón Ver en
registros (Analytics) . Al agregar una instrucción where de client_Type == "Browser" , solo
verá los datos del SDK de JavaScript y se excluirán todos los datos de telemetría del lado
servidor recopilados por otros SDK.
// average pageView duration by name
let timeGrain=5m;
let dataset=pageViews
// additional filters can be applied here
| where client_Type == "Browser" ;
// calculate average pageView duration for all pageViews
dataset
| summarize avg(duration) by bin(timestamp, timeGrain)
| extend pageView='Overall'
// render result in a chart
| render timechart
Compatibilidad con mapa de origen

La pila de llamadas compactada de los datos de telemetría de las excepciones se puede
descompactar en Azure Portal. Todas las integraciones existentes en el panel Detalles de la
excepción funcionarán con la pila de llamadas recién descompactada.
Vínculo a la cuenta de Blob Storage
Puede vincular su recurso de Application Insights a su propio contenedor de Azure Blob
Storage para desminificar las pilas de llamadas automáticamente. Para empezar, consulte el
artículo sobre la compatibilidad con mapa de origen automático.
Arrastrar y colocar
1. Seleccione un elemento de telemetría de excepciones en Azure Portal para ver sus detalles
de transacción completa.
2. Identifique qué mapas de origen corresponden a esta pila de llamadas. El mapa de origen
debe coincidir con el archivo de origen de un marco de pila, pero con el sufijo .map .
3. Arrastre y coloque los mapas de origen en la pila de llamadas en Azure Portal
Versión web básica de Application Insights

Para una experiencia ligera, puede instalar la versión básica de Application Insights.
npm i --save @microsoft/applicationinsights-web-basic
Esta versión incluye las características y funcionalidades mínimas, que puede ir ampliando
como desee. Por ejemplo, no realiza ninguna recopilación automática (excepciones no
detectadas, AJAX, etc.). En esta versión no se incluyen las API para enviar determinados tipos
de telemetría, como trackTrace , trackException , etc., por lo que tendrá que proporcionar su
propio contenedor. La única API disponible es track . Aquí tiene un ejemplo.
Ejemplos
Para ver ejemplos ejecutables, consulte Ejemplos del SDK de Application Insights para
JavaScript.
Actualizar desde la versión anterior de Application Insights

Cambios importantes en la versión del SDK V2:
Para permitir mejores firmas de API, se han actualizado algunas de las llamadas API, como
trackPageView o trackException. No se admite la ejecución en Internet Explorer 8 o en
versiones anteriores del explorador.
El sobre de telemetría presenta cambios en el nombre y la estructura del campo debido a
actualizaciones del esquema de datos.
context.operation se ha trasladado a context.telemetryTrace . También se han cambiado
algunos campos ( operation.id --> telemetryTrace.traceID ).
Para actualizar manualmente el identificador de la vista de página actual (por
ejemplo, en las aplicaciones SPA), puede hacerlo con
appInsights.properties.context.telemetryTrace.traceID = Util.generateW3CId() .
NOTE
Para mantener el identificador de seguimiento único, donde usó anteriormente
Util.newId() , ahora use Util.generateW3CId() . En última instancia, terminan
siendo el identificador de la operación.
Si usa el SDK de producción de Application Insights actual (1.0.20) y desea ver si el nuevo SDK
funciona en tiempo de ejecución, actualice la dirección URL en función de su escenario de
carga de SDK actual.
Descarga mediante el escenario de CDN: actualice el fragmento de código que usa
actualmente para que apunte a la dirección URL siguiente:
"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js"
Escenario de npm: llame a downloadAndSetup para descargar el script

ApplicationInsights completo de la red CDN e inicialícelo con la clave de
instrumentación:
appInsights.downloadAndSetup({
instrumentationKey: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx",
url: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js"
});
Pruebe en el entorno interno para comprobar que la telemetría de supervisión funciona

según lo esperado. Si todo funciona, actualice las firmas de API correctamente a la versión del
SDK V2 y realice la implementación en los entornos de producción.
Rendimiento y sobrecarga del SDK

Gracias a su tamaño comprimido con gzip de 36 KB y a los aproximadamente 15 ms que
tarda en inicializarse, Application Insights agrega una cantidad insignificante de tiempo de
carga a su sitio web. Con el fragmento de código, los componentes mínimos de la biblioteca
se cargan rápidamente. Mientras tanto, el script completo se descarga en segundo plano.
Mientras el script se descarga de la red CDN, todo el seguimiento de la página se pone en
cola. Una vez que se completa la inicialización asincrónica del script descargado, se realiza un
seguimiento de todos los eventos que se pusieron en cola. Como resultado, no perderá
telemetría durante todo el ciclo de vida de la página. Este proceso de instalación proporciona
a la página un sistema de análisis sin interrupciones, invisible para los usuarios.
Resumen:
npm package 2.5.8
Tiempo de inicialización total de 15 ms

Cero datos de telemetría perdidos durante el ciclo de vida de la página
Compatibilidad con exploradores
Chrome (última Firefox (última Internet Opera (última Safari (última

versión) ✔ versión) ✔ Explorer 9 (y versión) ✔ versión) ✔
posteriores) y
Edge ✔
Compatible con
IE 8
Compatibilidad con ES3/IE8

Como un SDK, hay numerosos usuarios que no pueden controlar los exploradores que sus
clientes usan. Por lo tanto, es necesario asegurarse de que este SDK continúa "funcionando" y
no interrumpe la ejecución de JS cuando lo carga un explorador más antiguo. Aunque
resultaría idóneo no admitir IE8 ni los exploradores de generaciones anteriores (ES3), hay
numerosos usuarios y clientes de gran tamaño que siguen requiriendo que las páginas
"funcionen" y, como se comentó, pueden o no controlar el explorador que sus usuarios finales
deciden usar.
Esto NO significa que solamente se admita el conjunto común más bajo de características;
simplemente indica que necesitamos mantener la compatibilidad con el código de ES3 y, al
agregar nuevas características, deberá hacerse de manera que no interrumpan el análisis de
JavaScript para ES3 y se agregarán como una característica opcional.
Consulte GitHub para obtener todos los detalles sobre la compatibilidad con IE8

El SDK de JavaScript de Application Insights es de código abierto. Para ver el código fuente o
para contribuir al proyecto, visite el repositorio de GitHub oficial.
Para obtener las actualizaciones y correcciones de errores más recientes, consulte las notas de
la versión.
Pasos siguientes
Seguir el uso
Eventos y métricas personalizados
Compilación - Métrica - Aprendizaje
Solución de problemas de errores de carga del SDK
Compatibilidad con mapas de origen para
aplicaciones JavaScript
Application Insights admite la carga de mapas de origen en su propio contenedor de blobs de la cuenta de
almacenamiento. Los mapas de origen se pueden usar para desminificar las pilas de llamadas que se encuentran
en la página de detalles de la transacción completa. Cualquier excepción enviada por el SDK de JavaScript o el SDK
de Node.js se puede desminificar con mapas de origen.
Creación de una cuenta de almacenamiento y un contenedor de blobs

Si ya tiene una cuenta de almacenamiento o un contenedor de blobs, puede omitir este paso.
1. Creación de una cuenta de almacenamiento nueva
2. Cree un contenedor de blobs en la cuenta de almacenamiento. Asegúrese de establecer "Nivel de acceso
público" en Private para asegurarse de que los mapas de origen no sean accesibles públicamente.
Inserción de mapas de origen en el contenedor de blobs
Para integrar la canalización de implementación continua con la cuenta de almacenamiento, debe configurarla
para cargar automáticamente los mapas de origen en el contenedor de blobs configurado.
Los mapas de origen se pueden cargar al contenedor de Blob Storage con la misma estructura de carpetas en la
que se compilaron e implementaron. Un caso de uso común es prefijar una carpeta de implementación con su
versión, por ejemplo, 1.2.3/static/js/main.js . Cuando se desminifique a través de un contenedor de blobs de
Azure llamado sourcemaps , intentará capturar un mapa de origen ubicado en
sourcemaps/1.2.3/static/js/main.js.map .
Carga de mapas de origen mediante Azure Pipelines (recomendado )

Si usa Azure Pipelines para compilar e implementar de forma continua la aplicación, agregue una tarea Copia de
archivos de Azure a la canalización para cargar automáticamente los mapas de origen.
Configuración del recurso de Application Insights con una cuenta de

almacenamiento del mapa de origen
Página de detalles de la transacción completa
En la pestaña de detalles de la transacción completa, puede hacer clic en Desminificar y se mostrará un aviso de
configuración si el recurso no está configurado.
1. En el portal, consulte los detalles de una excepción que está minificada.
2. Haga clic en Desminificar
3. Si el recurso no se ha configurado, aparecerá un mensaje que le solicitará que lo configure.
En la página de propiedades
Si desea configurar o cambiar la cuenta de almacenamiento o el contenedor de blobs que está vinculado a su
recurso de Application Insights, puede hacerlo en la pestaña Propiedades del recurso de Application Insights.
1. Vaya a la pestaña Propiedades del recurso de Application Insights.
2. Haga clic en Cambiar el contenedor de blobs del mapa de origen.
3. Seleccione otro contenedor de blobs como contenedor de mapas de origen.
4. Haga clic en Apply .
Configuración del control de acceso basado en rol (RBAC ) requerida en el contenedor de blobs
Cualquier usuario del portal que use esta característica debe estar como mínimo asignado como Lector de datos
de Storage Blob a su contenedor de blobs. Debe asignar este rol a cualquier otro usuario que vaya a usar los
mapas de origen mediante esta característica.
NOTE
En función de cómo se haya creado el contenedor, es posible que no haya sido asignado automáticamente a usted o a su
equipo.
Mapa de origen no encontrado

1. Compruebe que el mapa de origen correspondiente se haya cargado en el contenedor de blobs correcto.
2. Compruebe que el archivo de mapa de origen lleve el nombre del archivo de JavaScript coincidente, con el
sufijo .map .
Por ejemplo, /static/js/main.4e2ca5fa.chunk.js buscará el blob llamado main.4e2ca5fa.chunk.js.map
3. Compruebe la consola del explorador para ver si se registra algún error. Inclúyalo en una incidencia de soporte
técnico.
Pasos siguientes
Tarea Copia de archivos de Azure
Complemento React para el SDK de JavaScript de
El complemento React para el SDK de JavaScript de Application Insights habilita lo siguiente:

Seguimiento de cambios de ruta
Estadísticas de uso de componentes de React
Introducción
Instalación del paquete de npm:
npm install @microsoft/applicationinsights-react-js
Uso básico
import React from 'react';
import { ApplicationInsights } from '@microsoft/applicationinsights-web';
import { ReactPlugin, withAITracking } from '@microsoft/applicationinsights-react-js';
import { createBrowserHistory } from "history";
const browserHistory = createBrowserHistory({ basename: '' });

var reactPlugin = new ReactPlugin();
var appInsights = new ApplicationInsights({
config: {
instrumentationKey: 'YOUR_INSTRUMENTATION_KEY_GOES_HERE',
extensions: [reactPlugin],
extensionConfig: {
[reactPlugin.identifier]: { history: browserHistory }
}
}
});
// To instrument various React components usage tracking, apply the `withAITracking` higher-order
// component function.
class MyComponent extends React.Component {

...
}
export default withAITracking(reactPlugin,appInsights, MyComponent);
Configuración
history null Historial de react-router. Para obtener

más información, consulte la
documentación del paquete de react-
router. Para obtener información sobre
cómo tener acceso al objeto de historial
fuera de los componentes, consulte las
preguntas frecuentes de react-router.
Seguimiento de uso de componentes de React

Para instrumentar el seguimiento del uso de varios componentes de React, aplique la función de componente de
orden superior withAITracking .
Medirá el tiempo desde el evento de ComponentDidMount a través del evento ComponentWillUnmount . Sin embargo,
para que esto sea más preciso, restará el tiempo en el que el usuario estuvo inactivo
React Component Engaged Time = ComponentWillUnmount timestamp - ComponentDidMount timestamp - idle time .
Para ver esta métrica en Azure Portal, tiene que ir al recurso de Application Insights, seleccionar la pestaña
"Métricas" y configurar los gráficos vacíos para mostrar el nombre de la métrica personalizada "React Component
Engaged Time (seconds)" (Tiempo de interactividad del componente de React [segundos]), seleccionar la
agregación (suma, promedio, etc.) de la métrica y aplicar la división "Component Name" (Nombre del
componente).
También puede ejecutar consultas personalizadas para dividir los datos de Application Insights con el fin de
generar informes y visualizaciones según sus requisitos. En Azure Portal navegue hasta el recurso de Application
Insights, seleccione "Análisis" en el menú superior de la pestaña de información general y ejecute la consulta.
NOTE
Las nuevas métricas personalizadas pueden tardar hasta 10 minutos en aparecer en Azure Portal.
Aplicación de ejemplo
Consulte la demostración de React en Application Insights.
Pasos siguientes
Para obtener más información sobre el SDK de JavaScript, consulte la documentación del SDK de JavaScript de
Para obtener información sobre el lenguaje de consulta de Kusto y la consulta de datos en Log Analytics,
consulte la información general sobre la consulta de registro.
Complemento Native React para el SDK de
JavaScript de Application Insights
El complemento Native React para el SDK de JavaScript de Application Insights recopila información del
dispositivo; de forma predeterminada, este complemento recopila automáticamente:
Identificador de dispositivo único (también conocido como identificador de instalación).
Nombre del modelo de dispositivo (como iPhone X, Samsung Galaxy Fold, Huawei P30 Pro, etc.)
Tipo de dispositivo (por ejemplo, auricular, tableta, etc.)
Requisitos
Debe usar una versión mayor o igual que 2.0.0 de @microsoft/applicationinsights-web . Este complemento solo
funcionará en aplicaciones react-native. No funcionará con aplicaciones que usan el marco Expo, por lo que no
funcionará con Create React Native App.
Introducción
Instale y vincule el paquete react-native-device-info. Mantenga el paquete react-native-device-info actualizado
para recopilar los nombres de dispositivo más recientes con la aplicación.
npm install --save @microsoft/applicationinsights-react-native @microsoft/applicationinsights-web

npm install --save react-native-device-info
react-native link react-native-device-info
Inicialización del complemento

Para usar este complemento, debe construir el complemento y agregarlo como extension a la instancia de
Application Insights existente.
import { ApplicationInsights } from '@microsoft/applicationinsights-web';

import { ReactNativePlugin } from '@microsoft/applicationinsights-react-native';
var RNPlugin = new ReactNativePlugin();

var appInsights = new ApplicationInsights({
config: {
extensions: [RNPlugin]
}
});
Pasos siguientes
Para obtener más información sobre el SDK de JavaScript, consulte la documentación del SDK de JavaScript de
Para obtener información sobre el lenguaje de consulta de Kusto y la consulta de datos en Log Analytics,
consulte la información general sobre la consulta de registro.
Solución de problemas de errores de carga del SDK
para aplicaciones web de JavaScript
El fragmento de código de JavaScript (v3 o posterior) crea y notifica la excepción del error de carga del SDK
cuando detecta que el script del SDK no se pudo descargar o inicializar. Simplificando, el cliente (explorador) de los
usuarios finales no pudo descargar el SDK de Application Insights o inicializar desde la página de hospedaje
identificada y, por tanto, no se informará ningún evento ni datos de telemetría.
NOTE
Esta excepción se admite en todos los principales exploradores que admiten la API fetch() o XMLHttpRequest. Esto excluye
IE 8 y versiones anteriores, por lo que no obtendrá este tipo de excepción desde dichos exploradores (a menos que su
entorno incluya el polyfill fetch).
Los detalles de la pila incluyen la información básica con las direcciones URL que usa el usuario final.
<CDN Endpoint> Dirección URL que se utilizó (y produjo un error) para

descargar el SDK.
<Help Link> Dirección URL que enlaza a la documentación de solución de

problemas (esta página).
<Host URL> Dirección URL completa de la página que utilizaba el usuario

final.
<Endpoint URL> Dirección URL que se utilizó para informar de la excepción.

Este valor puede ser útil para identificar si se accedió a la
página de hospedaje desde la red pública de Internet o desde
una nube privada.
Los motivos más comunes para que se produzca esta excepción son:
Errores intermitentes de conectividad de red.
Interrupción en la red CDN de Application Insights.
No se pudo inicializar el SDK después de cargar el script.
Se ha bloqueado la red CDN de Application Insights para JavaScript.
Los errores intermitentes de conectividad de red son el motivo más común de esta excepción, especialmente en
escenarios móviles en itinerancia en los que los usuarios pierden la conectividad de red de forma intermitente.
En las secciones siguientes se describe cómo solucionar cada posible causa principal de este error.
NOTE
Algunos de los pasos de solución de problemas suponen que la aplicación tiene control directo de la etiqueta <script /> del
fragmento de código y su configuración, que se devuelven como parte de la página HTML de hospedaje. Si no es así, los
pasos identificados no se aplicarán a su escenario.
Errores intermitentes de conectividad de red

Si el usuario experimenta errores intermitentes de conectividad de red, hay menos soluciones
posibles y, por lo general, se resolverán por sí mismos transcurrido un breve período de tiempo. Por
ejemplo, si el usuario vuelve a cargar el sitio (actualiza la página), los archivos (con el tiempo) se descargarán y se
almacenarán en caché localmente hasta que se publique una versión actualizada.
NOTE
Si esta excepción es persistente y le ocurre a muchos de los usuarios (diagnosticado mediante un nivel rápido y sostenido de
notificaciones de esta excepción) junto con una reducción en los datos de telemetría habituales del cliente, los problemas
intermitentes de conectividad de red no serán probablemente la verdadera causa del problema y debe seguir con el
diagnóstico de otros problemas conocidos.
Cuando se da esta situación, es poco probable que el hospedaje del SDK en su propia red CDN reduzca las
repeticiones de esta excepción, ya que su propia red CDN se verá afectada por el mismo problema.
Lo mismo se aplica también cuando se usa el SDK mediante la solución de paquetes npm. Sin embargo, desde la
perspectiva de los usuarios finales, cuando esto ocurre, es toda la aplicación lo que no se puede cargar o inicializar
(en lugar de simplemente el SDK de telemetría, algo que no ven de forma visual), por lo que lo más probable es
que actualicen el sitio hasta que se cargue completamente.
También puede intentar usar paquetes npm para insertar el SDK de Application Insights.
Para minimizar los errores intermitentes de conectividad de red, hemos implementado encabezados de control de
la memoria caché en todos los archivos de la red CDN, de modo que, una vez que el explorador del usuario final
haya descargado la versión actual del SDK, no tendrá que volver a descargarlo y el explorador volverá a usar la
copia obtenida anteriormente (consulte cómo funciona el almacenamiento en caché). Si se produce un error en la
comprobación del almacenamiento en caché o si se ha publicado una nueva versión, el explorador del usuario
final tendrá que descargar la versión actualizada. Por lo tanto, es posible que observe un nivel de "ruido" de fondo
en el escenario de comprobación de errores o un pico temporal cuando se publica una nueva versión y está
disponible con carácter general (se implementa en la red CDN).
Interrupción en la red CDN de Application Insights

Puede confirmar si hay una interrupción en la red CDN de Application Insights; para ello, intente acceder al punto
de conexión de la red CDN directamente desde el explorador (por ejemplo,
https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js) ) desde una ubicación diferente a la de los usuarios finales,
probablemente desde su propia máquina de desarrollo (suponiendo que la organización no haya bloqueado este
dominio).
Si confirma que hay una interrupción, puede crear una nueva incidencia de soporte técnico o intentar cambiar la
dirección URL que se usa para descargar el SDK.
Cambio del punto de conexión de la red CDN
Como la aplicación devuelve el fragmento de código y su configuración como parte de cada página generada,
puede cambiar la configuración src del fragmento de código para que utilice una dirección URL diferente para el
SDK. Con este enfoque, puede evitar el problema de la red CDN bloqueada, ya que la nueva dirección URL no
debería estar bloqueada.
Puntos de conexión actuales de la red CDN del SDK para JavaScript de Application Insights
https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js
https://js.monitor.azure.com/scripts/b/ai.2.min.js
NOTE
El punto de conexión https://js.monitor.azure.com/ es un alias que nos permite cambiar entre proveedores de la red
CDN en unos 5 minutos, sin necesidad de que el usuario cambie la configuración. Esto nos permite corregir los problemas
detectados relacionados con la red CDN más rápidamente si un proveedor de CDN tiene problemas regionales o globales
sin necesidad de que todos los usuarios ajusten su configuración.
No se pudo inicializar el SDK después de cargar el script

Cuando no se puede inicializar el SDK, el elemento <script /> se descargó correctamente desde la red CDN, pero
se produce un error durante la inicialización. Esto se puede deber a que faltan dependencias o que no son válidas
o bien a algún tipo de excepción de JavaScript.
Lo primero que hay que comprobar es si el SDK se descargó correctamente. Si el script no se descargó, este
escenario no es la causa de la excepción del error de carga del SDK.
Comprobación rápida: con un explorador que admita herramientas de desarrollo (F12), valide en la pestaña Red
que el script definido en la configuración src del fragmento de código se descargó con un código de respuesta
200 (correcto) o 304 (no modificado). También puede usar una herramienta como Fiddler para revisar el tráfico de
red.
En las secciones siguientes se incluyen diferentes opciones de informes y se recomienda crear una incidencia de
soporte técnico o generar un problema en GitHub.
Reglas básicas para las notificaciones:
Si el problema solo afecta a un número pequeño de usuarios y a un determinado subconjunto de versiones del
explorador (consulte los detalles de la excepción que se ha comunicado), es probable que se trate de un
problema con el entorno o el usuario final, lo que probablemente requerirá que la aplicación proporcione
implementaciones de polyfill adicionales. En estos casos, notifique un problema en GitHub.
Si este problema afecta a toda la aplicación y todos los usuarios se ven afectados, es probable que se trate de
un problema relacionado con la versión y, por lo tanto, debe crear una nueva incidencia de soporte técnico.
Excepciones de JavaScript
En primer lugar, compruebe si hay excepciones de JavaScript. Cargue la página con un explorador que admita las
herramientas de desarrollo (F12) y revise si se produjeron excepciones.
Si se notifican excepciones en el script del SDK (por ejemplo, ai.2.min.js), esto puede indicar que la configuración
que se ha pasado al SDK contiene una configuración inesperada o que falta o que se ha implementado una
versión defectuosa en la red CDN.
Para comprobar si hay una configuración defectuosa, cambie la configuración que se pasa al fragmento de código
(si no lo ha hecho ya), de modo que solo incluya la clave de instrumentación como un valor de cadena.
src: "https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js ",

cfg:{
instrumentationKey: "CLAVE_DE_INSTRUMENTACIÓN"
}});
Si al usar esta configuración mínima todavía aparece una excepción de JavaScript en el script del SDK, cree una
nueva incidencia de soporte técnico, ya que esto requerirá que se revierta la compilación defectuosa, ya que
probablemente sea un problema con una versión implementada recientemente.
Si la excepción desaparece, es probable que el problema se deba a un error de coincidencia de tipos o a un valor
inesperado. Empiece a agregar de nuevo las opciones de configuración de una en una y pruebe hasta que se
produzca la excepción. A continuación, consulte la documentación del elemento que causa el problema. Si la
documentación no es clara o necesita ayuda, notifique un problema en GitHub.
Si la configuración se ha implementado previamente y funcionaba, pero ha comenzado a notificar esta excepción,
puede tratarse de un problema con una versión recién implementada. Compruebe si solo afecta a un pequeño
conjunto de usuarios o exploradores y notifique un problema en GitHub o cree una nueva incidencia de soporte
técnico.
Habilitación de la depuración en la consola
Si no se produce ninguna excepción, el paso siguiente consiste en habilitar la depuración en la consola; para ello,
agregue la opción loggingLevelConsole a la configuración y se enviarán todos los errores y advertencias de
inicialización a la consola de los exploradores (disponible normalmente mediante las herramientas de desarrollo
(F12)). Los errores detectados deberían ser autodescriptivos y puede notificar un problema en GitHub si necesita
ayuda adicional.
cfg:{
instrumentationKey: "CLAVE_DE_INSTRUMENTACIÓN",
loggingLevelConsole: 2
}});
NOTE
Durante la inicialización, el SDK realiza algunas comprobaciones básicas de las principales dependencias conocidas. Si el
runtime actual no las proporciona, informará de los errores como mensajes de advertencia en la consola, pero solo si el
valor de loggingLevelConsole es mayor que cero.
Si todavía no se puede inicializar, intente habilitar la opción de configuración enableDebug . Esto hará que se
generen todos los errores internos como una excepción (lo que hará que se pierdan los datos de telemetría). Dado
que se trata de una configuración solo del desarrollador, es probable que se produzca ruido con las excepciones
que se inician como parte de algunas comprobaciones internas, por lo que deberá revisar cada excepción para
determinar qué problema está causando el error en el SDK. Use la versión no reducida del script (observe que la
extensión del fragmento siguiente es ".js" y no ".min.js"); de lo contrario, las excepciones no serán legibles.
WARNING
Se trata de una configuración solo para desarrolladores y nunca se debe habilitar en un entorno de producción completo, ya
que se perderán los datos de telemetría.
src: "https://az416426.vo.msecnd.net/scripts/b/ai.2.js ",

cfg:{
instrumentationKey: "CLAVE_DE_INSTRUMENTACIÓN",
enableDebug: true
}});
Si esto tampoco proporciona información, debe notificar un problema en GitHub con los detalles y un sitio de
ejemplo, si dispone de uno. Incluya la versión del explorador, el sistema operativo y los detalles del marco de JS
para ayudar a identificar el problema.
Se ha bloqueado la red CDN de Application Insights para JavaScript

Es posible que se bloquee la red CDN cuando se ha notificado o identificado un punto de conexión de la red CDN
del SDK de Application Insights para JavaScript como no seguro. Cuando esto sucede, el punto de conexión se
incluye en una lista pública de bloqueos y los consumidores de estas listas comenzarán a bloquear todo el acceso.
Para resolverlo, es necesario que el propietario del punto de conexión de la red CDN colabore con la entidad de la
lista de bloqueos que marcó el punto de conexión como no seguro para que este se elimine de la lista
correspondiente.
Compruebe si el punto de conexión de la red CDN se ha identificado como no seguro.
Informe de transparencia de Google
VirusTotal
Sucuri SiteCheck
En función de la frecuencia con la que la aplicación, el firewall o el entorno actualicen sus copias locales de estas
listas, puede tardar una cantidad considerable de tiempo y requerir la intervención manual de los usuarios finales
o los departamentos de TI corporativos para forzar una actualización o permitir explícitamente que los puntos de
conexión de la red CDN resuelvan el problema.
Si el punto de conexión de la red CDN se identifica como no seguro, cree una incidencia de soporte técnico para
asegurarse de que el problema se resuelve lo antes posible.
Para evitar potencialmente este problema con más rapidez, puede cambiar el punto de conexión de la red CDN del
SDK.
La red CDN de Application Insights para JavaScript está bloqueada (por el usuario final: bloqueado por el
explorador, por un bloqueador instalado o por el firewall personal)
Compruebe si los usuarios finales han:
Instalado un complemento del explorador (normalmente algún tipo de bloqueador de anuncios, malware o
elementos emergentes).
Bloqueado (o no permitido) los puntos de conexión de la red CDN de Application Insights en el explorador o
servidor proxy.
Configurado una regla de firewall que provoca el bloqueo del dominio de la red CDN del SDK (o que no se
resuelva entrada de DNS).
Si han configurado alguna de estas opciones, tendrá que colaborar con ellos (o proporcionar documentación)
para permitir el acceso a los puntos de conexión de la red CDN.
Es posible que el complemento que han instalado utilice listas públicas de bloqueos. Si no es así, lo más probable
es que exista alguna otra solución configurada manualmente o que se usen listas de bloqueo de dominio privado.
Adición de excepciones para los puntos de conexión de la red CDN
Colabore con los usuarios finales o proporcione documentación que les informe de que deben permitir que los
scripts de los puntos de conexión de la red CDN de Application Insights se descarguen mediante su inclusión en el
complemento del explorador o en la lista de excepciones de las reglas de firewall (esto variará en función del
entorno del usuario final).
Este es un ejemplo de cómo configurar Chrome para permitir o bloquear el acceso a sitios web.
La red CDN de Application Insights está bloqueada (por el firewall corporativo )
Si los usuarios finales se encuentran en una red corporativa, es más probable que se trate de su solución de
firewall y que su departamento de TI haya implementado algún tipo de sistema de filtrado de Internet. En este
caso, tendrá que colaborar con ellos para permitir las reglas necesarias para los usuarios finales.
Adición de excepciones para los puntos de conexión de la red CDN para entidades corporativas
Es similar a la adición de excepciones para los usuarios finales, pero debe colaborar con el departamento de TI de
la empresa para que configuren los puntos de conexión de la red CDN de Application Insights desde los que se va
a descargar mediante la inclusión (o eliminación) de los mismos en todos los servicios de lista de bloqueos o de
lista de permitidos del dominio.
WARNING
Si el usuario corporativo usa una nube privada y no puede habilitar ninguna forma de excepción que proporcione a sus
usuarios internos acceso público a los puntos de conexión de la red CDN, tendrá que usar los paquetes npm de Application
Insights u hospedar el SDK de Application Insights en su propia red CDN.
Solución de problemas adicional para casos de red CDN bloqueada
NOTE
Si los usuarios usan una nube privada y no tienen acceso a la red pública de Internet, deberá hospedar el SDK en su propia
red CDN o usar paquetes NPM.
Hospedaje del SDK en su propia red CDN

En lugar de que los usuarios finales descarguen el SDK de Application Insights desde la red CDN pública, puede
hospedar el SDK de Application Insights en su propio punto de conexión de la red CDN. Se recomienda que use
una versión específica (ai.2.#.#.min.js) para que sea más fácil identificar la versión que se usa. También puede
actualizarlo de forma periódica a la versión actual (ai.2.min.js) para que pueda aprovechar las correcciones de
errores y las nuevas características que estén disponibles.
Uso de paquetes npm para insertar el SDK de Application Insights
En lugar de usar el fragmento de código y los puntos de conexión de la red CDN pública, podría usar paquetes
npm para incluir el SDK como parte de sus propios archivos JavaScript. El SDK se convertirá en otro paquete
dentro de sus propios scripts.
NOTE
Al usar los paquetes NPM, se recomienda que también use algún tipo de agrupador de JavaScript para ayudar con la
división y la minificación del código.
Al igual que con el fragmento de código, también es posible que sus propios scripts (con o sin usar los paquetes
NPM del SDK) se vean afectados por los mismos problemas de bloqueo que se enumeran aquí, por lo que, en
función de la aplicación, los usuarios y el marco de trabajo, puede que desee considerar la posibilidad de
implementar algo similar a la lógica del fragmento de código para detectar estos problemas.
Pasos siguientes
Obtención de ayuda adicional mediante la notificación de un problema en GitHub
Supervisar el uso de las páginas web
API de Application Insights para eventos
y métricas personalizados
Inserte unas cuantas líneas de código en la aplicación para averiguar qué uso hacen de ella
los usuarios o para ayudarle a diagnosticar problemas. Puede enviar datos de telemetría
desde aplicaciones de escritorio y de dispositivo y desde clientes y servidores web. Use la
API de telemetría principal de Azure Application Insights para enviar métricas y eventos
personalizados, así como sus propias versiones de telemetría estándar. Esta API es la
misma que usan los recopiladores de datos estándar de Application Insights.
API summary
La API central es uniforme en todas las plataformas, excepto por algunas pequeñas
variaciones como GetMetric (solo .NET).
M ÉTO DO SE USA PA RA
TrackPageView Páginas, pantallas, hojas o formularios.
TrackEvent Acciones de usuario y otros eventos. Se usa para

realizar el seguimiento del comportamiento de
los usuarios o para supervisar el rendimiento.
GetMetric Cero y métricas multidimensionales, agregación

configurada de forma centralizada, solo en C#.
TrackMetric Las medidas de rendimiento, como las

longitudes de cola, no están relacionadas con
eventos específicos.
TrackException Excepciones de registro para diagnóstico.

Permite realizar el seguimiento del lugar donde
se producen en relación con otros eventos y
examinar los seguimientos de pila.
TrackRequest Registro de la frecuencia y duración de las

solicitudes de servidor para el análisis de
rendimiento.
TrackTrace Mensajes del registro de diagnóstico de

recursos. También puede capturar registros de
terceros.
TrackDependency Registro de la duración y frecuencia de las

llamadas a componentes externos de los que
depende la aplicación.
Puede adjuntar propiedades y métricas a la mayoría de estas llamadas de telemetría.
Antes de comenzar
Si aún no tiene una referencia en el SDK de Application Insights:
Agregue el SDK de Application Insights a su proyecto:
Proyecto de ASP.NET
Proyecto de ASP.NET Core
Proyecto de Java
Proyecto de Node.js
JavaScript en cada página web
En el código de servidor web o de dispositivo, incluya:
C#: using Microsoft.ApplicationInsights;
Visual Basic: Imports Microsoft.ApplicationInsights
Java: import com.microsoft.applicationinsights.TelemetryClient;
Node.js: var applicationInsights = require("applicationinsights");
Obtención de una instancia de TelemetryClient

Obtenga una instancia de TelemetryClient (excepto en JavaScript en páginas web):
En el caso de las aplicaciones ASP.NET Core y aplicaciones que no son HTTP o de trabajo
para .NET/.NET Core, se recomienda obtener una instancia de TelemetryClient del
contenedor de inserción de dependencias, tal como se explica en la documentación
correspondiente.
Si usa AzureFunctions v2 o superior o Azure WebJobs v3 o superior, siga este documento:
https://docs.microsoft.com/azure/azure-functions/functions-monitoring#version-2x-and-
higher
C#
private TelemetryClient telemetry = new TelemetryClient();
Los usuarios que reciban mensajes que indiquen que el método está obsoleto pueden
visitar microsoft/ApplicationInsights-dotnet#1152 para obtener más detalles.
Visual Basic
Private Dim telemetry As New TelemetryClient
Java
private TelemetryClient telemetry = new TelemetryClient();
Node.js
var telemetry = applicationInsights.defaultClient;
TelemetryClient es seguro para subprocesos.

Para proyectos ASP.NET y Java, las solicitudes HTTP entrantes se capturan
automáticamente. Puede que quiera crear instancias adicionales de TelemetryClient para
otro módulo de la aplicación. Por ejemplo, puede tener una instancia de TelemetryClient en
la clase de middleware para notificar eventos de la lógica de negocios. Puede establecer
propiedades como UserId y DeviceId para identificar la máquina. Esta información se
adjunta a todos los eventos enviados por la instancia.
C#
TelemetryClient.Context.User.Id = "...";
TelemetryClient.Context.Device.Id = "...";
Java
telemetry.getContext().getUser().setId("...");
telemetry.getContext().getDevice().setId("...");
En proyectos de Node.js, puede usar

new applicationInsights.TelemetryClient(instrumentationKey?) para crear una nueva
instancia, pero esto solo se recomienda para escenarios que requieren configuración
aislada del singleton defaultClient .
TrackEvent
En Application Insights, un evento personalizado es un punto de datos que se puede
mostrar en el Explorador de métricas como recuento agregado, y como repeticiones
individuales en Búsqueda de diagnóstico. (No está relacionado con MVC ni con "eventos"
de otro marco).
Inserte llamadas a TrackEvent en el código para contabilizar diversos eventos: la
frecuencia con la que los usuarios eligen una determinada característica, con la que logran
unos determinados objetivos o con la que cometen determinados tipos de errores.
Por ejemplo, en una aplicación de juego, envíe un evento cada vez que un usuario gane el
juego:
JavaScript
appInsights.trackEvent({name:"WinGame"});
C#
telemetry.TrackEvent("WinGame");
Visual Basic
telemetry.TrackEvent("WinGame")
Java
telemetry.trackEvent("WinGame");
Node.js
telemetry.trackEvent({name: "WinGame"});
Eventos personalizados en Analytics

La telemetría está disponible en la tabla customEvents de Analytics de Application Insights.
Cada fila representa una llamada a trackEvent(..) en la aplicación.
Si el muestreo está en uso, en la propiedad itemCount se muestra un valor mayor que 1.
Por ejemplo, itemCount==10 significa que de cada 10 llamadas a trackEvent(), el proceso
de muestreo solo transmite una. Para obtener un recuento correcto de eventos
personalizados, debería usar código como customEvents | summarize sum(itemCount) .
GetMetric
Para obtener información sobre cómo usar eficazmente la llamada a GetMetric() para
capturar métricas previamente agregadas de forma local para aplicaciones .NET y
.NET Core, visite la documentación de GetMetric.
TrackMetric
NOTE
Microsoft.ApplicationInsights.TelemetryClient.TrackMetric no es el método preferido para el envío
de métricas. Las métricas deben agregarse previamente siempre durante un tiempo antes de
enviarse. Use una de las sobrecargas GetMetric(..) para obtener un objeto de métrica para acceder
a funcionalidades de agregación previa del SDK. Si va a implementar su propia lógica de
agregación previa, puede usar el método TrackMetric() para enviar los agregados resultantes. Si su
aplicación requiere el envío de un elemento de telemetría independiente en cada ocasión sin
agregación a lo largo del tiempo, es probable que en su caso haya que usar la telemetría de
eventos; consulte TelemetryClient.TrackEvent
(Microsoft.ApplicationInsights.DataContracts.EventTelemetry).
Application Insights puede crear gráficos de métricas que no estén conectadas a eventos
concretos. Por ejemplo, puede supervisar una longitud de cola a intervalos regulares. En el
caso de las métricas, las mediciones individuales tienen menos interés que las variaciones
y tendencias; por tanto, los gráficos estadísticos resultan útiles.
Para enviar las métricas a Application Insights, puede usar la API TrackMetric(..) . Hay dos
formas de enviar una métrica:
Valor único. Cada vez que realiza una medición en la aplicación, envía el valor
correspondiente a Application Insights. Por ejemplo, suponga que cuenta con una
métrica que describe el número de elementos de un contenedor. Durante un
período determinado, primero coloca tres elementos en el contenedor y
seguidamente retira dos. En consecuencia, llamaría a TrackMetric dos veces: la
primera, para pasar el valor 3 y a continuación el valor -2 . Application Insights
almacena ambos valores en su nombre.
Agregación. Al trabajar con métricas, las mediciones individuales pocas veces
resultan de interés. En su lugar, lo importante son los resúmenes de
acontecimientos durante un período determinado. Los resúmenes de este tipo se
denominan agregaciones. En el ejemplo anterior, la suma de las métricas agregadas
del período correspondiente es de 1 y el recuento de los valores de las métricas es
de 2 . Al usar el método de agregación, solo invocará TrackMetric una vez por
período y enviará los valores agregados. Este es el método que se recomienda usar,
ya que puede reducir significativamente los costos y la sobrecarga de rendimiento
gracias a que envía menos puntos de datos a Application Insights, a pesar de seguir
recopilado toda la información pertinente.
Ejemplos
Valores únicos
Para enviar un único valor de métrica:
JavaScript
appInsights.trackMetric("queueLength", 42.0);
C#
var sample = new MetricTelemetry();

sample.Name = "metric name";
sample.Value = 42.3;
telemetryClient.TrackMetric(sample);
Java
telemetry.trackMetric("queueLength", 42.0);
Node.js
telemetry.trackMetric({name: "queueLength", value: 42.0});
Métricas personalizadas en Analytics

La telemetría está disponible en la tabla customMetrics de Analytics de Application
Insights. Cada fila representa una llamada a trackMetric(..) en la aplicación.
valueSum : es la suma de las medidas. Para obtener el valor medio, divídalo por
valueCount .
valueCount : el número de medidas que se agregaron en esta llamada a
trackMetric(..) .
Vistas de página
En una aplicación de dispositivo o de página web, se envían datos de telemetría de la vista
de página de forma predeterminada cuando se carga cada pantalla o página. Sin embargo,
puede cambiar esta frecuencia para que se realice el seguimiento de las vistas de página en
momentos diferentes o adicionales. Por ejemplo, en una aplicación que muestra pestañas u
hojas, quizás quiera realizar el seguimiento de una página siempre que el usuario abra una
nueva hoja.
Los datos de usuario y de sesión se envían como propiedades junto con las vistas de
página, por lo que los gráficos de usuario y de sesión se activan cuando hay datos de
telemetría de vistas de página.
Vistas de página personalizadas
JavaScript
appInsights.trackPageView("tab1");
C#
telemetry.TrackPageView("GameReviewPage");
Visual Basic
telemetry.TrackPageView("GameReviewPage")
Java
telemetry.trackPageView("GameReviewPage");
Si tiene varias fichas dentro de páginas HTML diferentes, puede especificar también la
dirección URL:
appInsights.trackPageView("tab1", "http://fabrikam.com/page1.htm");
Cronometrar las vistas de página

De forma predeterminada, los tiempos notificados como Tiempo de carga de la vista
de página se miden desde que el explorador envía la solicitud hasta que se llama al
evento de carga de página del explorador.
En su lugar, puede:
Establecer una duración explícita en la llamada trackPageView:
appInsights.trackPageView("tab1", null, null, null, durationInMilliseconds); .
Usar las llamadas para cronometrar la vista de página startTrackPage y stopTrackPage .
JavaScript
// To start timing a page:

appInsights.startTrackPage("Page1");
...
// To stop timing and log the page:

appInsights.stopTrackPage("Page1", url, properties, measurements);
El nombre que use como primer parámetro asocia las llamadas inicial y final. El valor
predeterminado es el nombre de la página actual.
Las duraciones de carga de página resultantes que se muestran en el Explorador de
métricas se derivan del intervalo que media entre las llamadas inicial y final. Depende del
usuario qué intervalo se cronometra realmente.
Telemetría de páginas en Analytics
En Analytics hay dos tablas en las que se muestran datos de operaciones de explorador:
La tabla pageViews contiene datos sobre la URL y el título de la página.
La tabla browserTimings contiene datos sobre el rendimiento del cliente, como el
tiempo que se tarda en procesar los datos entrantes.
Para averiguar cuánto tarda el explorador en procesar diferentes páginas:
browserTimings
| summarize avg(networkDuration), avg(processingDuration), avg(totalDuration) by name
Para descubrir la popularidad de distintos exploradores:
pageViews
| summarize count() by client_Browser
Para asociar las vistas de página a las llamadas AJAX, realice una combinación con
dependencias:
pageViews
| join (dependencies) on operation_Id
TrackRequest
El SDK del servidor usa TrackRequest para registrar las solicitudes de HTTP.
También puede llamarlo usted mismo si quiere simular solicitudes en un contexto en el que
no se está ejecutando el módulo de servicio web.
Sin embargo, lo que se recomienda para enviar telemetría de solicitudes es que la solicitud
actúe como contexto de operación.
Contexto de operación
Puede correlacionar los elementos de telemetría juntos mediante su asociación con el
contexto de la operación. El módulo de seguimiento de solicitud estándar realiza esta
operación para excepciones y otros eventos enviados al procesar una solicitud HTTP. En
Búsqueda y Análisis, puede encontrar fácilmente cualquier evento asociado a la solicitud
mediante su identificador de operación.
Para más información sobre la correlación, vea Correlación de telemetría en Application
Insights.
Al realizar el seguimiento de la telemetría manualmente, la forma más fácil de garantizar la
correlación de telemetría es mediante el uso de este patrón:
C#
// Establish an operation context and associated telemetry item:
using (var operation = telemetryClient.StartOperation<RequestTelemetry>
("operationName"))
{
// Telemetry sent in here will use the same operation ID.
...
telemetryClient.TrackTrace(...); // or other Track* calls
...
// Set properties of containing telemetry item--for example:

operation.Telemetry.ResponseCode = "200";
// Optional: explicitly send telemetry item:

telemetryClient.StopOperation(operation);
} // When operation is disposed, telemetry item is sent.
Junto con la configuración de un contexto de la operación, StartOperation crea un

elemento de telemetría del tipo que especifique. Envía el elemento de telemetría al eliminar
la operación, o si llama explícitamente a StopOperation . Si usa RequestTelemetry como
tipo de telemetría, su duración se establece en el intervalo cronometrado entre el inicio y la
detención.
Los elementos de telemetría notificados dentro de un ámbito de operación se convierten
en "elementos secundarios" de dicha operación. Los contextos de operación pueden estar
anidados.
En la Búsqueda, el contexto de la operación se utiliza para crear la lista de Elementos
relacionados :
Consulte Seguimiento de las operaciones personalizadas con el SDK de .NET para

Application Insights para más información sobre el seguimiento de las operaciones
personalizadas.
Solicitudes en Analytics
En Analytics de Application Insights, las solicitudes aparecen en la tabla requests .
Si el muestreo está en uso, en la propiedad de itemCount se mostrará un valor superior a
1. Por ejemplo, itemCount==10 significa que de cada 10 llamadas a trackRequest(), el
proceso de muestreo solo transmite una. Para obtener un recuento correcto de solicitudes
y la duración media segmentada por nombres de solicitudes, use código como el siguiente:
requests
| summarize count = sum(itemCount), avgduration = avg(duration) by name
TrackException
Enviar excepciones a Application Insights:
Para contarlas, como indicación de la frecuencia de un problema.
Para examinar los casos individuales.
Los informes incluyen los seguimientos de la pila.
C#
try
{
...
}
catch (Exception ex)
{
telemetry.TrackException(ex);
}
Java
try {
...
} catch (Exception ex) {
telemetry.trackException(ex);
}
JavaScript
try
{
...
}
catch (ex)
{
appInsights.trackException(ex);
}
Node.js
try
{
...
}
catch (ex)
{
telemetry.trackException({exception: ex});
}
Los SDK capturan muchas excepciones automáticamente, por lo que no siempre es

necesario llamar explícitamente a TrackException.
ASP.NET: escritura de código para detectar excepciones.
Java EE: las excepciones se detectan automáticamente.
JavaScript: las excepciones se detectan automáticamente. Si desea deshabilitar la
colección automática, agregue una línea al fragmento de código que se inserta en las
páginas web:
({
instrumentationKey: "your key",
disableExceptionTracking: true
})
Excepciones en Analytics
En Analytics de Application Insights, las excepciones aparecen en la tabla exceptions .
Por ejemplo, itemCount==10 significa que de cada 10 llamadas a trackException(), el
proceso de muestreo solo transmite una. Para obtener un recuento correcto de
excepciones segmentadas por tipo de excepción, use código como el siguiente:
exceptions
| summarize sum(itemCount) by type
La mayor parte de la información importante sobre pilas ya se extrajo en variables

independientes, pero puede desmontar la estructura details para obtener más. Puesto
que se trata de una estructura dinámica, debería convertir el resultado al tipo que espere.
Por ejemplo:
exceptions
| extend method2 = tostring(details[0].parsedStack[1].method)
Para asociar las excepciones a sus respectivas solicitudes, use una combinación:
exceptions
| join (requests) on operation_Id
TrackTrace
Use TrackTrace para ayudar a diagnosticar problemas mediante el envío de una ''ruta de
exploración'' a Application Insights. Puede enviar fragmentos de datos de diagnóstico e
inspeccionarlos en Búsqueda de diagnóstico.
Los adaptadores de registro de .NET usan esta API para enviar registros de terceros al
portal.
En Java, para registradores estándar como Log4J o Logback, utilice los appenders de Log4j
o Logback de Application Insights para enviar registros de terceros al portal.
C#
telemetry.TrackTrace(message, SeverityLevel.Warning, properties);
Java
telemetry.trackTrace(message, SeverityLevel.Warning, properties);
Node.js
telemetry.trackTrace({
message: message,
severity: applicationInsights.Contracts.SeverityLevel.Warning,
properties: properties
});
JavaScript del lado cliente/explorador
trackTrace(message: string, properties?: {[string]:string}, severityLevel?:

SeverityLevel)
Registre un evento de diagnóstico, como la entrada o la salida de un método.
message Datos de diagnóstico. Puede ser mucho más

largo que un nombre.
properties Asignación de cadena a cadena: Datos

adicionales que se usan para filtrar excepciones
en el portal. El valor predeterminado es vacío.
severityLevel Valores admitidos: SeverityLevel.ts
Puede buscar en el contenido del mensaje, pero (a diferencia de los valores de propiedad)
no puede filtrar por él.
El límite de tamaño en message es mucho mayor que el límite en propiedades. Una ventaja
de TrackTrace es que puede colocar datos relativamente largos en el mensaje. Por ejemplo,
aquí puede codificar datos POST.
Además, puede agregar un nivel de gravedad al mensaje. Y, al igual que con otra
telemetría, puede agregar valores de propiedad para ayudar a filtrar o buscar distintos
conjuntos de seguimientos. Por ejemplo:
C#
var telemetry = new Microsoft.ApplicationInsights.TelemetryClient();

telemetry.TrackTrace("Slow database response",
SeverityLevel.Warning,
new Dictionary<string,string> { {"database", db.ID} });
Java
Map<String, Integer> properties = new HashMap<>();

properties.put("Database", db.ID);
telemetry.trackTrace("Slow Database response", SeverityLevel.Warning, properties);
En Búsqueda, puede filtrar fácilmente todos los mensajes de un determinado nivel de

gravedad relativos a una determinada base de datos.
Seguimientos en Analytics
En Analytics de Application Insights, las llamadas a TrackTrace aparecen en la tabla traces .
Por ejemplo, itemCount==10 significa que de cada 10 llamadas a trackTrace() , el proceso
de muestreo solo transmite una. Para obtener un recuento correcto de llamadas de
seguimiento, debería codificar por tanto como traces | summarize sum(itemCount) .
TrackDependency
Utilice la llamada de TrackDependency para realizar un seguimiento de los tiempos de
respuesta y las tasas de éxito de las llamadas a un fragmento de código externo. Los
resultados se muestran en los gráficos de dependencia del portal. Es necesario agregar el
fragmento de código siguiente siempre que se realice una llamada de dependencia.
C#

var startTime = DateTime.UtcNow;
var timer = System.Diagnostics.Stopwatch.StartNew();
try
{
success = dependency.Call();
}
catch(Exception ex)
{
success = false;
telemetry.TrackException(ex);
throw new Exception("Operation went wrong", ex);
}
finally
{
timer.Stop();
telemetry.TrackDependency("DependencyType", "myDependency", "myCall", startTime,
timer.Elapsed, success);
}
Java
boolean success = false;

Instant startTime = Instant.now();
try {
success = dependency.call();
}
finally {
Instant endTime = Instant.now();
Duration delta = Duration.between(startTime, endTime);
RemoteDependencyTelemetry dependencyTelemetry = new RemoteDependencyTelemetry("My
Dependency", "myCall", delta, success);
RemoteDependencyTelemetry.setTimeStamp(startTime);
RemoteDependencyTelemetry.trackDependency(dependencyTelemetry);
}
Node.js
var startTime = new Date().getTime();
try
{
}
finally
{
var elapsed = new Date() - startTime;
telemetry.trackDependency({
dependencyTypeName: "myDependency",
name: "myCall",
duration: elapsed,
success: success
});
}
Recuerde que los SDK del servidor incluyen un módulo de dependencia que detecta y
realiza automáticamente el seguimiento de ciertas llamadas de dependencia; por ejemplo,
a bases de datos y API de REST. Debe instalar un agente en el servidor para que el módulo
funcione.
En Java, es posible realizar el seguimiento de ciertas llamadas de dependencia
automáticamente mediante el agente de Java.
Utilizará esta llamada si desea hacer un seguimiento de las llamadas no captadas por el
seguimiento automatizado, o bien si no desea instalar el agente.
Para desactivar el módulo de seguimiento de dependencias estándar en C#, edite
ApplicationInsights.config y elimine la referencia a
DependencyCollector.DependencyTrackingTelemetryModule . En Java, no instale al agente de
Java si no quiere recopilar dependencias estándar automáticamente.
Dependencias en Analytics
En Analytics de Application Insights, las llamadas de trackDependency aparecen en la tabla
dependencies .

Por ejemplo, itemCount==10 significa que de cada 10 llamadas a trackDependency(), el
proceso de muestreo solo transmite una. Para obtener un recuento correcto de
dependencias segmentadas por componente de destino, use código como el siguiente:
dependencies
| summarize sum(itemCount) by target
Para asociar las dependencias a sus respectivas solicitudes, use una combinación:
dependencies
| join (requests) on operation_Id
Datos de vaciado
Normalmente, el SDK envía datos a intervalos fijos (normalmente 30 segundos) o cuando
el búfer está lleno (normalmente 500 elementos). Sin embargo, en algunos casos puede
que desee vaciar el búfer: por ejemplo, si usa el SDK en una aplicación que se apaga.
C#
telemetry.Flush();
// Allow some time for flushing before shutdown.
System.Threading.Thread.Sleep(5000);
Java
telemetry.flush();
//Allow some time for flushing before shutting down
Thread.sleep(5000);
Node.js
telemetry.flush();
La función es asincrónica para el canal de telemetría del servidor.

Lo ideal es que se utilice el método flush() en la actividad de cierre de la aplicación.
Usuarios autenticados
En una aplicación web, los usuarios se identifican por cookies (de manera predeterminada).
Se puede contar al usuario más de una vez si accede a la aplicación desde un equipo o
explorador diferente, o si elimina las cookies.
Si los usuarios inician sesión en su aplicación, puede obtener un recuento más preciso
estableciendo el identificador del usuario autenticado en el código del explorador:
JavaScript
// Called when my app has identified the user.

function Authenticated(signInId) {
var validatedId = signInId.replace(/[,;=| ]+/g, "_");
appInsights.setAuthenticatedUserContext(validatedId);
...
}
En una aplicación MVC web de ASP.NET, por ejemplo:

Razor
@if (Request.IsAuthenticated)
{
<script>
appInsights.setAuthenticatedUserContext("@User.Identity.Name
.Replace("\\", "\\\\")"
.replace(/[,;=| ]+/g, "_"));
</script>
}
No es necesario usar el nombre de inicio de sesión real del usuario. Solo tiene que ser un
identificador único para ese usuario. No debe incluir espacios ni ninguno de los caracteres
,;=| .
El identificador de usuario también se establece en una cookie de sesión y se envía al

servidor. Si está instalado el SDK del servidor, el identificador de usuario autenticado se
envía como parte de las propiedades de contexto tanto de la telemetría del cliente como
del servidor. A continuación, puede filtrar y buscar en ella.
Si su aplicación agrupa a los usuarios en cuentas, también puede pasar un identificador de
la cuenta (con las mismas restricciones de caracteres).
appInsights.setAuthenticatedUserContext(validatedId, accountId);
En el Explorador de métricas, puede crear un gráfico que cuente los Usuarios

autenticados y las Cuentas de usuario .
También puede Buscar puntos de datos de cliente con cuentas y nombres de usuario
específicos.
Filtrado, búsqueda y segmentación de los datos

mediante el uso de propiedades
Puede asociar propiedades y medidas a los eventos (y también a las métricas, vistas de
página, excepciones y otros datos de telemetría).
propiedades son valores de cadena que se pueden usar para filtrar los datos de telemetría
en los informes de uso. Por ejemplo, si su aplicación proporciona varios juegos, puede
adjuntar el nombre del juego a cada evento para así poder ver cuáles son los juegos más
populares.
Hay un límite de aproximadamente 8192 en la longitud de cadena. (Si quiere enviar
fragmentos grandes de datos, use el parámetro de mensaje de TrackTrace).
métricas son valores numéricos que se pueden presentar de forma gráfica. Por ejemplo,
puede que quiera ver si hay un aumento gradual en las puntuaciones que alcanzan sus
jugadores. Los gráficos se pueden segmentar por las propiedades enviadas con el evento,
así que puede separar o apilar los gráficos para diferentes juegos.
Para que valores de métricas se muestren correctamente, deben ser mayores o iguales que
0.
Hay algunos límites en el número de propiedades, valores de propiedad y métricas que
puede usar.
JavaScript
appInsights.trackEvent
("WinGame",
// String properties:
{Game: currentGame.name, Difficulty: currentGame.difficulty},
// Numeric metrics:
{Score: currentGame.score, Opponents: currentGame.opponentCount}
);
appInsights.trackPageView
("page name", "http://fabrikam.com/pageurl.html",
// String properties:
{Game: currentGame.name, Difficulty: currentGame.difficulty},
// Numeric metrics:
{Score: currentGame.score, Opponents: currentGame.opponentCount}
);
C#
// Set up some properties and metrics:

var properties = new Dictionary <string, string>
{{"game", currentGame.Name}, {"difficulty", currentGame.Difficulty}};
var metrics = new Dictionary <string, double>
{{"Score", currentGame.Score}, {"Opponents", currentGame.OpponentCount}};
// Send the event:

telemetry.TrackEvent("WinGame", properties, metrics);
Node.js
// Set up some properties and metrics:

var properties = {"game": currentGame.Name, "difficulty": currentGame.Difficulty};
var metrics = {"Score": currentGame.Score, "Opponents": currentGame.OpponentCount};
// Send the event:

telemetry.trackEvent({name: "WinGame", properties: properties, measurements: metrics});
Visual Basic
' Set up some properties:

Dim properties = New Dictionary (Of String, String)
properties.Add("game", currentGame.Name)
properties.Add("difficulty", currentGame.Difficulty)
Dim metrics = New Dictionary (Of String, Double)

metrics.Add("Score", currentGame.Score)
metrics.Add("Opponents", currentGame.OpponentCount)
' Send the event:

telemetry.TrackEvent("WinGame", properties, metrics)
Java
Map<String, String> properties = new HashMap<String, String>();

properties.put("game", currentGame.getName());
properties.put("difficulty", currentGame.getDifficulty());
Map<String, Double> metrics = new HashMap<String, Double>();

metrics.put("Score", currentGame.getScore());
metrics.put("Opponents", currentGame.getOpponentCount());
telemetry.trackEvent("WinGame", properties, metrics);
NOTE
Tenga cuidado de no registrar información de identificación personal en las propiedades.
Método alternativo para establecer propiedades y métricas

Si le resulta más cómodo, puede recopilar los parámetros de un evento en un objeto
independiente:
var event = new EventTelemetry();
event.Name = "WinGame";
event.Metrics["processingTime"] = stopwatch.Elapsed.TotalMilliseconds;
event.Properties["game"] = currentGame.Name;
event.Properties["difficulty"] = currentGame.Difficulty;
event.Metrics["Score"] = currentGame.Score;
event.Metrics["Opponents"] = currentGame.Opponents.Length;
telemetry.TrackEvent(event);
WARNING
No vuelva a usar la misma instancia de elemento de telemetría ( event en este ejemplo) para
llamar a Track*() varias veces. Esto puede hacer que se envíe la telemetría con una configuración
incorrecta.
Mediciones y propiedades personalizadas en Analytics

En Analytics, las métricas y propiedades personalizadas aparecen en los atributos
customMeasurements y customDimensions de cada registro de telemetría.
Por ejemplo, si agregó una propiedad llamada "game" a la telemetría de solicitudes, esta
consulta cuenta el número de apariciones de diferentes valores de "game" y muestra la
media de la métrica personalizada "score":
requests
| summarize sum(itemCount), avg(todouble(customMeasurements.score)) by
tostring(customDimensions.game)
Tenga en lo siguiente:
Al extraer un valor de los elementos de JSON customDimensions o
customMeasurements, es de tipo dinámico, por lo que debe convertirlo a tostring o
todouble .
Para tener en cuenta la posibilidad de muestreo, debería usar sum(itemCount) , no
count() .
Eventos de temporización
Seguro que en ocasiones le gustaría representar el tiempo que se tarda en realizar alguna
acción. Por ejemplo, puede que quiera saber cuánto tiempo tardan los usuarios en
considerar las opciones de un juego. Puede usar el parámetro de medida para ello.
C#
var stopwatch = System.Diagnostics.Stopwatch.StartNew();
// ... perform the timed action ...
stopwatch.Stop();
var metrics = new Dictionary <string, double>

{{"processingTime", stopwatch.Elapsed.TotalMilliseconds}};
// Set up some properties:

{{"signalSource", currentSignalSource.Name}};
// Send the event:

telemetry.TrackEvent("SignalProcessed", properties, metrics);
Java
long startTime = System.currentTimeMillis();
// Perform timed action
long endTime = System.currentTimeMillis();

Map<String, Double> metrics = new HashMap<>();
metrics.put("ProcessingTime", (double)endTime-startTime);
// Setup some properties

Map<String, String> properties = new HashMap<>();
properties.put("signalSource", currentSignalSource.getName());
// Send the event

telemetry.trackEvent("SignalProcessed", properties, metrics);
Propiedades predeterminadas para la telemetría

personalizada
Si quiere establecer valores de propiedad predeterminados para algunos de los eventos
personalizados que escriba, puede hacerlo en una instancia de TelemetryClient. Se
adjuntarán a cada elemento de telemetría enviado desde ese cliente.
C#
var gameTelemetry = new TelemetryClient();

gameTelemetry.Context.GlobalProperties["Game"] = currentGame.Name;
// Now all telemetry will automatically be sent with the context property:
gameTelemetry.TrackEvent("WinGame");
Visual Basic
Dim gameTelemetry = New TelemetryClient()

gameTelemetry.Context.GlobalProperties("Game") = currentGame.Name
' Now all telemetry will automatically be sent with the context property:
gameTelemetry.TrackEvent("WinGame")
Java
import com.microsoft.applicationinsights.TelemetryClient;
import com.microsoft.applicationinsights.TelemetryContext;
...
TelemetryClient gameTelemetry = new TelemetryClient();

TelemetryContext context = gameTelemetry.getContext();
context.getProperties().put("Game", currentGame.Name);
gameTelemetry.TrackEvent("WinGame");
Node.js
var gameTelemetry = new applicationInsights.TelemetryClient();

gameTelemetry.commonProperties["Game"] = currentGame.Name;
gameTelemetry.TrackEvent({name: "WinGame"});
Las llamadas de telemetría individuales pueden invalidar los valores predeterminados en

los diccionarios de propiedad.
Para los clientes web de JavaScript, use los inicializadores de telemetría de JavaScript.
Para agregar propiedades a toda la telemetría, incluidos los datos de los módulos de
recopilación estándar, implemente ITelemetryInitializer .
Muestreo, filtrado y procesamiento de telemetría

Puede escribir código para procesar la telemetría antes de que se envíe desde el SDK. El
procesamiento incluye los datos enviados desde los módulos de telemetría estándar, como
la recopilación de solicitudes HTTP y de dependencias.
Agregue propiedades a la telemetría mediante la implementación de
ITelemetryInitializer . Por ejemplo, puede agregar números de versión o valores
calculados a partir de otras propiedades.
El filtrado puede modificar o descartar la telemetría antes de que se envíe desde el SDK,
mediante la implementación de ITelemetryProcessor . Puede controlar qué se envía y qué
se descarta, pero debe tener en cuenta el efecto en las métricas. Según la forma en que se
descarten los elementos, podría perder la capacidad de navegar entre elementos
relacionados.
El muestreo es una solución empaquetada para reducir el volumen de datos enviado desde
la aplicación al portal. Lo hace sin que las métricas mostradas resulten afectadas. Y sin
repercutir tampoco sobre capacidad para diagnosticar problemas navegando entre
elementos relacionados, como excepciones, solicitudes y vistas de página.
Más información.
Deshabilitación de la telemetría
Para iniciar y detener dinámicamente la recopilación y la transmisión de telemetría:
C#
TelemetryConfiguration.Active.DisableTelemetry = true;
Java
telemetry.getConfiguration().setTrackingDisabled(true);
Para deshabilitar los recopiladores estándar seleccionados (por ejemplo, contadores de

rendimiento, solicitudes HTTP o dependencias), elimine o convierta en comentarios las
líneas correspondientes en ApplicationInsights.config. Puede hacer esto, por ejemplo, si
quiere enviar sus propios datos de TrackRequest.
Node.js
telemetry.config.disableAppInsights = true;
Para deshabilitar los recopiladores estándar seleccionados (por ejemplo, los contadores de
rendimiento, las solicitudes HTTP o las dependencias) en el tiempo de inicialización,
encadene métodos de configuración a su código de inicialización de SDK:
applicationInsights.setup()
.setAutoCollectRequests(false)
.setAutoCollectPerformance(false)
.setAutoCollectExceptions(false)
.setAutoCollectDependencies(false)
.setAutoCollectConsole(false)
.start();
Para deshabilitar estos recopiladores después de la inicialización, utilice el objeto de

configuración: applicationInsights.Configuration.setAutoCollectRequests(false)
Modo de programador
Durante la depuración, resulta útil enviar los datos de telemetría por la canalización para
así poder ver los resultados inmediatamente. También puede recibir mensajes adicionales
que le ayuden a realizar el seguimiento de los posibles problemas con la telemetría.
Desactívelo en producción, ya que puede ralentizar la aplicación.
C#
TelemetryConfiguration.Active.TelemetryChannel.DeveloperMode = true;
Visual Basic
TelemetryConfiguration.Active.TelemetryChannel.DeveloperMode = True
Node.js
Para Node.js, puede habilitar el modo de desarrollador habilitando el registro interno a
través de setInternalLogging y estableciendo maxBatchSize en 0, lo que hace que la
telemetría se envíe tan pronto como se recopile.
applicationInsights.setup("ikey")
.setInternalLogging(true, true)
.start()
applicationInsights.defaultClient.config.maxBatchSize = 0;
Establecimiento de la clave de instrumentación para

datos de telemetría personalizados seleccionados
C#
var telemetry = new TelemetryClient();

telemetry.InstrumentationKey = "---my key---";
// ...
Copia de la clave de instrumentación

Para evitar la mezcla de telemetría de entornos de desarrollo, pruebas y producción, puede
crear recursos separados de Application Insights y cambiar sus claves en función del
entorno.
En lugar de obtener la clave de instrumentación del archivo de configuración, puede
establecerla en el código. Establezca la clave en un método de inicialización, como
global.aspx.cs en un servicio de ASP.NET:
C#
protected void Application_Start()

{
Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey =
// - for example -
WebConfigurationManager.Settings["ikey"];
...
}
JavaScript
appInsights.config.instrumentationKey = myKey;
En una página web, podría configurarla a partir del estado del servidor web, en lugar de
codificarla literalmente en el script. Por ejemplo, en una página web generada en una
aplicación ASP.NET:
JavaScript en Razor
// Standard Application Insights webpage script:
var appInsights = window.appInsights || function(config){ ...
// Modify this part:
}({instrumentationKey:
// Generate from server property:
@Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey;
}) // ...
String instrumentationKey = "00000000-0000-0000-0000-000000000000";
if (instrumentationKey != null)
{
TelemetryConfiguration.getActive().setInstrumentationKey(instrumentationKey);
}
TelemetryContext
TelemetryClient tiene una propiedad de Context, que contiene valores que se envían junto
con todos los datos de telemetría. Normalmente, se establecen mediante los módulos de
telemetría estándar, pero también los puede establecer usted mismo. Por ejemplo:
telemetry.Context.Operation.Name = "MyOperationName";
Si establece cualquiera de estos valores manualmente, considere la posibilidad de quitar la

línea pertinente de ApplicationInsights.config, de modo que no se confundan sus valores
con los valores estándar.
Component : la aplicación y su versión.
Device : datos sobre el dispositivo donde se ejecuta la aplicación. (En aplicaciones web,
se trata del servidor o el dispositivo de cliente desde el que se envía la telemetría).
InstrumentationKey : el recurso de Application Insights en Azure donde aparece la
telemetría. Normalmente, se selecciona de ApplicationInsights.config.
Ubicación : la ubicación geográfica del dispositivo.
Operation : en las aplicaciones web, es la solicitud HTTP actual. En otros tipos de
aplicaciones, puede establecer este valor para agrupar los eventos juntos.
Identificador : valor generado que correlaciona distintos eventos, de modo que
cuando usted inspeccione cualquier evento en Búsqueda de diagnóstico, puede
encontrar elementos relacionados.
Name : un identificador, generalmente la dirección URL de la solicitud HTTP.
SyntheticSource : si no es un valor nulo ni está vacío, esta cadena indica que el
origen de la solicitud se ha identificado como un robot o una prueba web. De
forma predeterminada, se excluye de cálculos en el Explorador de métricas.
Propiedades : propiedades que se envían con todos los datos de telemetría. Se pueden
invalidar en llamadas de seguimiento* individuales.
Sesión : sesión del usuario. El identificador se establece en un valor generado, que
cambia cuando el usuario lleva un tiempo sin estar activo.
Usuario : información del usuario.
límites
Hay algunos límites en el número de métricas y eventos por aplicación; es decir, por clave
de instrumentación. Los límites dependen del plan de precios que elija.

Total de datos por día 100 GB Se pueden reducir los datos si

se establece un límite. Si
necesita más datos, puede
aumentar el límite en el portal,
hasta 1000 GB. Para
capacidades mayores de
1000 GB, envíe un correo
electrónico a
AIDataCap@microsoft.com.
Limitaciones 32 000 eventos por segundo El límite se mide por minuto.
Retención de datos Entre 30 y 730 días Este recurso es para Search,

Analytics y el Explorador de
métricas.
Retención de resultados 90 días Este recurso proporciona

detallados para la prueba de resultados detallados de cada
disponibilidad de varios pasos paso.
Tamaño máximo de elementos 64 KB

de telemetría
Número máximo de elementos 64 K

de telemetría por lote
Longitud de nombres de 150 Consulte esquemas de tipos.

propiedades y métricas
Longitud de cadena del valor 8192 Consulte esquemas de tipos.

de propiedad
Longitud del mensaje de 32 768 Consulte esquemas de tipos.

seguimiento y excepción
Número de pruebas de 100

disponibilidad por aplicación
Retención de datos del 5 días

generador de perfiles
Datos enviados por día del 10 GB

generador de perfiles
Para más información, consulte Administración de precios y cuotas para Application

Insights.
Para evitar llegar al límite de velocidad de datos, utilice el muestreo.
Para determinar cuánto tiempo se conservan los datos, consulte el artículo sobre retención
de datos y privacidad.
Documentos de referencia
Referencia de ASP.NET
Referencia de Java
Referencia de JavaScript
Código del SDK

SDK básico de ASP.NET
ASP.NET
Paquetes de Windows Server
SDK de Java
SDK de Node.js
SDK de JavaScript
Preguntas
¿Qué excepciones pueden iniciar las llamadas de seguimiento_()?
Ninguno. No es necesario agruparlas en cláusulas try-catch. Si el SDK encuentra
problemas, registrará los mensajes en la salida de la consola de depuración, y, si los
mensajes pasan, en la Búsqueda de diagnóstico.
¿Hay una API de REST para obtener datos desde el portal?
Sí, la API de acceso a datos. Otras maneras de extraer datos son exportar desde
Analytics a Power BI y la exportación continua.
Pasos siguientes
Búsqueda de eventos y registros
Solución de problemas cuando no hay datos:
Application Insights para .NET/.NET Core
Falta parte de mi telemetría

En Application Insights, solo veo una fracción de los eventos generados por mi aplicación.
Si observa la misma fracción constantemente, es probable que se deba al muestreoadaptable. Para
confirmarlo, abra Búsqueda (desde la hoja de información general) y examine una instancia de una solicitud u
otro evento. En la parte inferior de la sección Propiedades, haga clic en "..." para obtener todos los detalles de
la propiedad. Si Recuento de solicitudes > 1, hay un muestreo en curso.
De lo contrario, es posible que se esté aproximando a un límite de velocidad de datos para su plan de precios.
Estos límites se aplican por minuto.
Experimento una pérdida de datos aleatoria.
Compruebe si está experimentando pérdida de datos en el canal de telemetría.
Busque problemas conocidos en el repositorio de GitHub del canal de telemetría.
Experimento pérdida de datos en la aplicación de consola o en la aplicación web cuando la aplicación está a punto
de detenerse.
El canal del SDK mantiene los datos de telemetría en el búfer y los envía en lotes. Si se está cerrando la
aplicación, es posible que deba llamar explícitamente a Flush(). El comportamiento de Flush() depende del
canal real utilizado.
No hay datos de mi servidor

He instalado mi aplicación en el servidor web y ahora no veo ninguna telemetría procedente de ella. Funcionaba
correctamente en mi equipo de desarrollo.
Probablemente sea un problema de firewall. Configure excepciones de firewall para que Application Insights
envíe datos.
Es posible que falten algunos requisitos previos en el servidor IIS: Extensibilidad de .NET 4.5 y ASP.NET 4.5.
He instalado el monitor de estado en el servidor web para supervisar las aplicaciones existentes. No se ve ningún
resultado.
Consulte Solución de problemas del Monitor de estado.
No hay ninguna opción "Agregar Application Insights" en Visual Studio

Cuando hago clic con el botón derecho en un proyecto existente en el Explorador de soluciones, no veo ninguna
opción de Application Insights.
No todos los tipos de proyectos .NET son compatibles con las herramientas. Se admiten los proyectos WCF y
Web. Para otros tipos de proyecto como aplicaciones de escritorio o de servicio, puede agregar manualmente
un SDK de Application Insights al proyecto.
Asegúrese de que tiene Visual Studio 2013 Update 3 o posterior. Viene con Developer Analytics Tools
preinstalado, que ofrece el SDK de Application Insights.
Seleccione Herramientas , Extensiones y actualizaciones y compruebe que Developer Analytics Tools
está instalado y habilitado. Si es así, haga clic en Actualizaciones para ver si hay alguna disponible.
Abra el cuadro de diálogo Nuevo proyecto y elija Aplicación web ASP.NET. Si ve la opción Application Insights
aquí, es que las herramientas están instaladas. Si no es así, intente desinstalar y volver a instalar Developer
Analytics Tools.
Error al agregar Application Insights

Cuando intento agregar Application Insights a un proyecto existente, veo un mensaje de error.
Causas probables:
se produce un error de comunicación con el portal de Application Insights,
hay algún problema con su cuenta de Azure,
Solo tiene acceso de lectura a la suscripción o el grupo en que ha tratado de crear el recurso nuevo.
Solución:
Compruebe que ha proporcionado las credenciales de inicio de sesión para la cuenta de Azure correcta.
En el explorador, compruebe que tiene acceso al portal de Azure. Abra Configuración y compruebe si hay
alguna restricción.
Agregar Application Insights a un proyecto existente: en el Explorador de soluciones, haga clic con el botón
derecho en el proyecto y elija “Agregar Application Insights”.
Aparece el mensaje de error "La clave de instrumentación no puede

estar vacía".
Parece que algo salió mal durante la instalación de Application Insights o puede ser un adaptador del registro.
En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y elija Application Insights >
Configurar Application Insights . Aparecerá un cuadro de diálogo que le invita a iniciar sesión en Azure y a
crear un recurso de Application Insights, o a volver a utilizar uno existente.
"Faltan paquetes NuGet" en el servidor de compilación

Todo se compila correctamente al depurar en el equipo de desarrollo pero aparece un error de NuGet en el
servidor de compilación.
Consulte Restauración de paquetes NuGet y Restauración automática de paquetes.
Falta el comando de menú para abrir Application Insights desde Visual

Studio
Al hacer clic con el botón derecho en el Explorador de soluciones del proyecto, no se ve ningún comando de
Application Insights o no se ve un comando Abrir Application Insights.
Causas probables:
Si se ha creado el recurso de Application Insights manualmente o si el proyecto es de un tipo que no es
compatible con las herramientas de Application Insights.
Developer Analytics Tools está deshabilitado en Visual Studio.
Visual Studio es anterior a la actualización 3 de 2013.
Solución:
Compruebe que la versión de Visual Studio sea la actualización 3 de 2013 o posterior.
Seleccione Herramientas , Extensiones y actualizaciones y compruebe que Developer Analytics Tools
está instalado y habilitado. Si es así, haga clic en Actualizaciones para ver si hay alguna disponible.
En el Explorador de soluciones, haga clic con el botón derecho en el proyecto. Si ve el comando Application
Insights > Configurar Application Insights , úselo para conectar el proyecto al recurso en el servicio de
De lo contrario, el tipo de proyecto no es directamente compatible con Developer Analytics Tools. Para ver la
telemetría, inicie sesión en el Portal de Azure, elija Application Insights en la barra de navegación de la izquierda y
seleccione la aplicación.
'Acceso denegado' al abrir Application Insights desde Visual Studio

El comando de menú 'Abrir Application Insights' lleva al Portal de Azure pero aparece un error de "acceso
denegado".
El inicio de sesión de Microsoft que utilizó por última vez en el explorador predeterminado no tiene acceso al
recurso que se creó cuando se agregó Application Insights a esta aplicación. Hay dos causas probables:
Tiene más de una cuenta de Microsoft: ¿quizás tenga una cuenta profesional y una cuenta personal de
Microsoft? El inicio de sesión que se utilizó por última vez en el explorador predeterminado era para una
cuenta distinta de la que tiene acceso para agregar Application Insights al proyecto.
Solución: haga clic en su nombre en la parte superior derecha de la ventana del explorador y cierre la
sesión. A continuación, inicie sesión con la cuenta que tiene acceso. En la barra de navegación izquierda,
haga clic en Application Insights y seleccione la aplicación.
Otro usuario ha agregado Application Insights al proyecto y se ha olvidado de proporcionarle acceso al grupo
de recursos en el que se creó.
Solución: si este usuario utiliza una cuenta de organización, puede agregarle al equipo, o bien, puede
concederle acceso individual al grupo de recursos.
'No se encuentra ningún activo' al abrir Application Insights desde

Visual Studio
El comando de menú 'Abrir Application Insights' lleva al Portal de Azure pero aparece un error de "no se
encuentra ningún activo".
Causas probables:
Se ha eliminado el recurso de Application Insights para su aplicación o
la clave de instrumentación se ha establecido o modificado en ApplicationInsights.config editándola
directamente, sin actualizar el archivo de proyecto.
La clave de instrumentación en ApplicationInsights.config controla dónde se envía la telemetría. Una línea en el
archivo de proyecto controla qué recurso se abre al utilizar el comando de Visual Studio.
Solución:
En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y elija Application Insights,
Configurar Application Insights. En el cuadro de diálogo, puede elegir enviar la telemetría a un recurso
existente o crear uno nuevo. O:
Abra el recurso directamente. Inicie sesión en el Portal de Azure, elija Application Insights en la barra de
navegación de la izquierda y seleccione la aplicación.
¿Dónde se encuentra la telemetría?

He iniciado sesión en Microsoft Azure Portal y estoy mirando el panel de inicio de Azure. ¿Dónde se encuentran
los datos de Application Insights?
En la barra de navegación izquierda, haga clic en Application Insights y luego en el nombre de la aplicación. Si
no tiene ahí ningún proyecto, es necesario agregar o configurar Application Insights en el proyecto web.
Ahí verá algunos gráficos de resumen. Puede hacer clic en ellos para ver su contenido con más detalle.
En Visual Studio, al depurar la aplicación, haga clic en el botón de Application Insights.
No hay datos de servidor (o ningún tipo de datos)

Se ejecuta la aplicación y se abre el servicio de Application Insights en Microsoft Azure pero todos los gráficos
muestran 'Obtenga información sobre cómo recopilar...' o 'No está configurado.' O bien, solo vista de página y
datos de usuario, pero no hay datos de servidor.
Ejecute la aplicación en modo de depuración en Visual Studio (F5). Utilice la aplicación para generar telemetría.
Compruebe que puede ver los eventos registrados en la ventana de resultados de Visual Studio.
En el portal de Application Insights, abra Diagnostic Search(Búsqueda de diagnóstico). Los datos suelen
aparecer aquí en primer lugar.
Haga clic en el botón Actualizar. La hoja se actualiza periódicamente, pero también puede hacerlo
manualmente. El intervalo de actualización es mayor para intervalos de tiempo mayores.
Compruebe las claves de instrumentación coincidan. En la hoja principal de la aplicación en el portal de
Application Insights, en la lista desplegable de Essentials , vea la Clave de instrumentación . A continuación,
en el proyecto de Visual Studio, abra ApplicationInsights.config y busque <instrumentationkey> . Compruebe
que las dos claves sean iguales. Si no es así:
En el portal, haga clic en Application Insights y busque el recurso de aplicación con la clave correcta, o
En el Explorador de soluciones de Visual Studio, haga clic con el botón derecho en el proyecto y elija
Application Insights, Configurar. Restablezca la aplicación para enviar la telemetría al recurso adecuado.
Si no puede encontrar las claves coincidentes, compruebe que utiliza las mismas credenciales de inicio
de sesión en Visual Studio que en el portal.
En el panel de inicio de Microsoft Azure, observe el mapa de Estado del servicio. Si hay algunas indicaciones
de alerta, espere hasta que hayan vuelto a su estado correcto y después cierre y vuelva a abrir el cuadro de la
aplicación de Application Insights.
Compruebe también nuestro blog de estado.
¿Ha escrito algún código para el SDK del lado servidor que pueda haber cambiado la clave de instrumentación
en instancias TelemetryClient o en TelemetryContext ? ¿O ha escrito una configuración de filtro o muestreo
que pueda estar filtrando demasiado?
Si editó ApplicationInsights.config, compruebe minuciosamente la configuración de TelemetryInitializers y
TelemetryProcessors. Un parámetro o tipo con un nombre incorrecto puede provocar que el SDK no envíe
datos.
No hay datos en Vistas de página, Explorador o Uso

Se ven datos en los gráficos de Tiempo de respuesta del servidor y Solicitudes de servidor pero no hay datos en
Tiempo de carga de la vista de página, o en las hojas Explorador o Uso.
Los datos proceden de los scripts de las páginas web.
Si agrega Application Insights a un proyecto web existente, tendrá que agregar los scripts manualmente.
Asegúrese de que Internet Explorer no muestra el sitio en modo de compatibilidad.
Use la característica de depuración del explorador (F12 en algunos exploradores y, después, elija Red) para
comprobar que los datos se envían a dc.services.visualstudio.com .
No hay datos de excepción o dependencia

Consulte telemetría de dependencias y telemetría de excepciones.
Sin datos de rendimiento

Los datos de rendimiento (CPU, velocidad de E/S, etc.) están disponibles para servicios web de Java, aplicaciones
de escritorio de Windows, servicios y aplicaciones web IIS si instala el Monitor de estado y Azure Cloud Services.
Los encontrará en la sección Configuración > Servidores.
No hay datos (de servidor) desde que se publicó la aplicación en el

servidor
Compruebe que realmente copió todas las DLL de Microsoft.ApplicationInsights en el servidor, junto con
Microsoft.Diagnostics.Instrumentation.Extensions.Intercept.dll.
En el firewall, es posible que tenga que abrir algunos puertos TCP.
Si tiene que usar un servidor proxy para enviar fuera de la red corporativa, establezca el valor defaultProxy en
el archivo Web.config.
Windows Server 2008: asegúrese de que ha instalado las siguientes actualizaciones: KB2468871, KB2533523
y KB2600217.
Solía ver datos, pero ya no sucede esto.

¿Ha alcanzado su cuota mensual de puntos de datos? Abra Configuración/Cuotas y Precios para averiguarlo.
Si es así, puede actualizar el plan o pagar para obtener capacidad adicional. Consulte el esquema de precios.
No veo todos los datos que esperaba

Si la aplicación envía una gran cantidad de datos y usa el SDK de Application Insights para ASP.NET versión 2.0.0-
beta3 o posterior, la característica de muestreo adaptativo puede operar y enviar solamente un porcentaje de los
Se puede deshabilitar, pero no se recomienda. El muestreo está diseñado para que la telemetría relacionada se
transmita correctamente, con fines de diagnóstico.
La dirección IP del cliente es 0.0.0.0

El 5 de febrero de 2018, anunciamos que habíamos eliminado el registro de la dirección IP del cliente. Esto no
afecta a la ubicación geográfica.
NOTE
Si necesita los primeros tres octetos de la dirección IP, puede usar un inicializador de telemetría para agregar un atributo
personalizado. Esto no afecta a los datos recopilados antes del 5 de febrero de 2018.
Datos geográficos incorrectos en la telemetría de usuario

La ciudad, región y dimensiones del país proceden de las direcciones IP y no siempre son precisas. Estas
direcciones IP se procesan en primer lugar para la ubicación y, a continuación, se cambian a 0.0.0.0 para
almacenarse.
Excepción "Método no encontrado" en la ejecución en Azure Cloud

Services
¿Ha realizado la compilación para .NET 4.6? 4.6 no se admite automáticamente en los roles de Azure Cloud
Service. Instale 4.6 en cada rol antes de ejecutar la aplicación.
Registros de la solución de problemas

Siga estas instrucciones para capturar registros de solución de problemas para su marco.
.NET Framework
1. Instale el paquete Microsoft.AspNet.ApplicationInsights.HostingStartup de NuGet. La versión que instale
debe coincidir con la versión de Microsoft.ApplicationInsighs instalada actualmente.
2. Modifique el archivo applicationinsights.config para incluir lo siguiente:
<TelemetryModules>
<Add
Type="Microsoft.ApplicationInsights.Extensibility.HostingStartup.FileDiagnosticsTelemetryModule,
Microsoft.AspNet.ApplicationInsights.HostingStartup">
<Severity>Verbose</Severity>
<LogFileName>mylog.txt</LogFileName>
<LogFilePath>C:\\SDKLOGS</LogFilePath>
</Add>
</TelemetryModules>
La aplicación debe tener permisos de escritura en la ubicación configurada.

3. Reinicie el proceso para que el SDK adopte esta nueva configuración.
4. Revierta estos cambios cuando haya terminado.
.NET Core
1. Instale el paquete NuGet del SDK de Application Insights para ASP.NET Core desde NuGet. La versión que
instale debe coincidir con la versión de Microsoft.ApplicationInsights instalada actualmente.
La versión más reciente de Microsoft.ApplicationInsights.AspNetCore es 2.14.0 y hace referencia a
Microsoft.ApplicationInsights versión 2.14.0. Por lo tanto, se debería instalar la versión de
Microsoft.ApplicationInsights.AspNetCore 2.14.0.
2. Modifique el método ConfigureServices en su clase Startup.cs :
services.AddSingleton<ITelemetryModule, FileDiagnosticsTelemetryModule>();
services.ConfigureTelemetryModule<FileDiagnosticsTelemetryModule>( (module, options) => {
module.LogFilePath = "C:\\SDKLOGS";
module.LogFileName = "mylog.txt";
module.Severity = "Verbose";
} );
La aplicación debe tener permisos de escritura en la ubicación configurada.

3. Reinicie el proceso para que el SDK adopte esta nueva configuración.
4. Revierta estos cambios cuando haya terminado.
Recopilación de registros con PerfView

PerfView es una herramienta gratuita de análisis de rendimiento y diagnóstico que ayuda a aislar la CPU, la
memoria y otros problemas mediante la recopilación y la visualización de información de diagnóstico de varios
orígenes.
El SDK de Application Insights mantiene registros de solución de problemas automática de EventSource que se
pueden capturar con PerfView.
Para recopilar registros, descargue PerfView y ejecute este comando:
PerfView.exe collect -MaxCollectSec:300 -NoGui /onlyProviders=*Microsoft-ApplicationInsights-Core,*Microsoft-

ApplicationInsights-Data,*Microsoft-ApplicationInsights-WindowsServer-TelemetryChannel,*Microsoft-
ApplicationInsights-Extensibility-AppMapCorrelation-Dependency,*Microsoft-ApplicationInsights-Extensibility-
AppMapCorrelation-Web,*Microsoft-ApplicationInsights-Extensibility-DependencyCollector,*Microsoft-
ApplicationInsights-Extensibility-HostingStartup,*Microsoft-ApplicationInsights-Extensibility-
PerformanceCollector,*Microsoft-ApplicationInsights-Extensibility-EventCounterCollector,*Microsoft-
ApplicationInsights-Extensibility-PerformanceCollector-QuickPulse,*Microsoft-ApplicationInsights-
Extensibility-Web,*Microsoft-ApplicationInsights-Extensibility-WindowsServer,*Microsoft-ApplicationInsights-
WindowsServer-Core,*Microsoft-ApplicationInsights-LoggerProvider,*Microsoft-ApplicationInsights-
Extensibility-EventSourceListener,*Microsoft-ApplicationInsights-AspNetCore
Puede modificar estos parámetros según sea necesario:

MaxCollectSec . Establezca este parámetro para evitar que PerfView se ejecute indefinidamente y afecte al
rendimiento del servidor.
OnlyProviders . Establezca este parámetro para recopilar únicamente los registros del SDK. Puede
personalizar esta lista en función de sus investigaciones específicas.
NoGui . Establezca este parámetro para recopilar los registros sin la GUI.
Para obtener más información,
Registro de seguimientos de rendimiento con PerfView.
Orígenes de eventos de Application Insights
Recopilación de registros con dotnet-trace

Un método alternativo de recopilación de registros para la solución de problemas que puede resultar
especialmente útil en entornos basados en Linux es dotnet-trace
dotnet-trace collect --process-id <PID> --providers Microsoft-ApplicationInsights-Core,Microsoft-

ApplicationInsights-Data,Microsoft-ApplicationInsights-WindowsServer-TelemetryChannel,Microsoft-
ApplicationInsights-Extensibility-AppMapCorrelation-Dependency,Microsoft-ApplicationInsights-Extensibility-
AppMapCorrelation-Web,Microsoft-ApplicationInsights-Extensibility-DependencyCollector,Microsoft-
ApplicationInsights-Extensibility-HostingStartup,Microsoft-ApplicationInsights-Extensibility-
PerformanceCollector,Microsoft-ApplicationInsights-Extensibility-EventCounterCollector,Microsoft-
ApplicationInsights-Extensibility-PerformanceCollector-QuickPulse,Microsoft-ApplicationInsights-
Extensibility-Web,Microsoft-ApplicationInsights-Extensibility-WindowsServer,Microsoft-ApplicationInsights-
WindowsServer-Core,Microsoft-ApplicationInsights-LoggerProvider,Microsoft-ApplicationInsights-Extensibility-
EventSourceListener,Microsoft-ApplicationInsights-AspNetCore
Eliminación de Application Insights

Aprenda a quitar Application Insights en Visual Studio siguiendo los pasos que se indican en el artículo sobre la
eliminación.
Sigue sin funcionar...

Página de preguntas y respuestas de Microsoft sobre Application Insights
Procedimiento para quitar Application Insights en
Visual Studio
En este artículo se mostrará cómo quitar el SDK de Application Insights de ASP.NET y ASP.NET Core en Visual
Studio.
Para quitar Application Insights, deberá quitar los paquetes NuGet y las referencias de la API de la aplicación.
Puede desinstalar los paquetes NuGet mediante la consola de Administración de paquetes o la solución para
administrar NuGet en Visual Studio. En las secciones siguientes se muestran dos maneras de quitar los paquetes
NuGet y todo lo que se agregó automáticamente en el proyecto. Asegúrese de confirmar los archivos agregados y
las áreas de su propio código en los que se han quitado las llamadas realizadas a la API.
Desinstalación mediante la consola de Administración de paquetes

.NET
.NET Core
1. Para abrir la consola de Administración de paquetes, en el menú superior, seleccione
Herramientas > Administrador de paquetes NuGet > Consola del Administrador de paquetes.
NOTE
Si la recopilación de seguimiento está habilitada, primero debe desinstalar Microsoft.ApplicationInsights.TraceListener.
Escriba Uninstall-package Microsoft.ApplicationInsights.TraceListener y siga el paso siguiente para quitar
Microsoft.ApplicationInsights.Web.
2. Escriba el comando siguiente: Uninstall-Package Microsoft.ApplicationInsights.Web -RemoveDependencies
Después de escribir el comando, el paquete de Application Insights y todas sus dependencias se

desinstalarán del proyecto.
Desinstalación mediante la interfaz de usuario NuGet de Visual Studio

.NET
.NET Core
1. En el Explorador de soluciones de la derecha, haga clic con el botón derecho en Solución y
seleccione Administrar paquetes NuGet para la solución .
Verá una pantalla que le permite editar todos los paquetes NuGet que forman parte del proyecto.
NOTE
Si está habilitada la recopilación de seguimiento, primero debe desinstalar Microsoft.ApplicationInsights.TraceListener
sin seleccionar la opción para quitar las dependencias y, a continuación, seguir los pasos que se indican a
continuación para desinstalar Microsoft.ApplicationInsights.Web con la opción para quitar las dependencias
seleccionada.
2. Haga clic en el paquete "Microsoft.ApplicationInsights.Web". A la derecha, marque la casilla situada junto a

Proyecto para seleccionar todos los proyectos.
3. Para quitar todas las dependencias en la desinstalación, seleccione el botón desplegable Opciones que se
encuentra debajo de la sección donde seleccionó Proyecto.
En Desinstalar opciones, seleccione la casilla situada junto a Quitar dependencias.
4. Seleccione Desinstalar .
Se mostrará un cuadro de diálogo que muestra todas las dependencias que se van a quitar de la
aplicación. Seleccione Aceptar para desinstalar.
5. Después de desinstalar todo, es posible que siga apareciendo "ApplicationInsights.config" y

"AiHandleErrorAttribute.cs" en el Explorador de soluciones. Puede eliminar manualmente los dos archivos.
Lo que se crea al agregar Application Insights

Cuando agrega Application Insights al proyecto, crea archivos y agrega código a algunos de sus archivos. La
desinstalación exclusiva de los paquetes NuGet no siempre descartará los archivos y el código. Para quitar
completamente Application Insights, debe comprobar y eliminar manualmente el código o los archivos agregados
junto con cualquier llamada API que haya agregado en el proyecto.
.NET
.NET Core
Al agregar Telemetría de Application Insights a un proyecto ASP.NET de Visual Studio, se agregan los siguientes
archivos:
AiHandleErrorAttribute.cs
Se agregan los siguientes fragmentos de código:
[Nombre del proyecto].csproj
<ApplicationInsightsResourceId>/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/Default-ApplicationInsights-
EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
Packages.config
<packages>
...
<package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />

<package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472"
/>
<package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0"
targetFramework="net472" />
<package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0"
<package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
<package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472"
/>
<package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0"
<package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
<package id="System.Buffers" version="4.4.0" targetFramework="net472" />

<package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
<package id="System.Memory" version="4.5.3" targetFramework="net472" />
<package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
<package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
...
</packages>
Layout.cshtml
Si el proyecto tiene un archivo Layout.cshtml, se agrega el código siguiente.
<head>
...
<script type = 'text/javascript' >
var appInsights=window.appInsights||function(config)
{
function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){
t[config].apply(t, i)})} }
var t = {
config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az41642
6.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)
[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=
['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return
r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||
(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o);
return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
}({
instrumentationKey:'00000000-0000-0000-0000-000000000000'
});
</script>
...
</head>
ConnectedService.json
{
"ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
"Version": "16.0.0.0",
"GettingStartedDocument": {
"Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
}
}
FilterConfig.cs
public static void RegisterGlobalFilters(GlobalFilterCollection filters)

{
filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
}
Pasos siguientes
Azure Monitor
¿Qué es la instrumentación automática o la conexión
sin código de Azure Monitor Application Insights?
La instrumentación automática, o conexión sin código, permite habilitar la supervisión de las aplicaciones con
Application Insights sin modificar el código.
Application Insights se integra con varios proveedores de recursos y funciona en distintos entornos. En resumen,
solo debe habilitar y, en algunos casos, configurar el agente, que estará listo para recopilar la telemetría. En unos
instantes, podrá ver las métricas, los datos y las dependencias en el recurso de Application Insights, lo que le
permitirá detectar el origen de los posibles problemas antes de que se produzcan y analizar la causa raíz a través
de la vista de transacciones integral.
Entornos, lenguajes y proveedores de recursos admitidos

A medida que agregamos más integraciones, la matriz de funcionalidades de instrumentación automática se
vuelve compleja. En la tabla siguiente se muestra el estado actual de la situación en lo que se refiere a la
compatibilidad con varios proveedores de recursos, lenguajes y entornos.
EN TO RN O / P RO VEEDO
R DE REC URSO S . N ET . N ET C O RE JAVA N O DE. JS
Azure App Service en Disponibilidad Disponibilidad Vista previa privada Vista previa privada
Windows general, OnBD* general, opcional
Azure App Service en N/D No compatible Vista previa pública Vista previa pública
Linux
Azure App Service en N/D En diseño En diseño En diseño

AKS
Azure Functions: Disponibilidad Disponibilidad Disponibilidad Disponibilidad

básico general, OnBD* general, OnBD* general, OnBD* general, OnBD*
Azure Functions: No compatible No compatible Vista previa pública No compatible

dependencias
Azure Kubernetes N/D En diseño Mediante el agente En diseño

Service
VM de Azure con Vista previa pública No compatible No compatible No compatible

Windows
VM locales con Disponibilidad No compatible Mediante el agente No compatible

Windows general, opcional
Agente No compatible No compatible Vista previa pública No compatible

independiente:
cualquier ent.
*OnBD significa "Activado de forma predeterminada"; Application Insights se habilitará automáticamente una vez
que implemente la aplicación en los entornos compatibles.
Azure App Service

Windows
La supervisión de aplicaciones en Azure App Service está disponible para la aplicación .NET y está habilitada de
forma predeterminada, .NET Core se puede habilitar con un solo clic, y Java y Node.js están en versión preliminar
privada.
Linux
La supervisión de las aplicaciones Java y Node.js en App Service se encuentra en versión preliminar pública y se
puede habilitar en Azure Portal, disponible en todas las regiones.
Azure Functions
La supervisión básica de Azure Functions está habilitada de forma predeterminada para recopilar el registro, el
rendimiento, los datos de error y las solicitudes HTTP. En el caso de las aplicaciones Java, puede habilitar una
supervisión más completa con seguimiento distribuido y obtener los detalles de la transacción de un extremo a
otro. Esta funcionalidad de Java está en versión preliminar pública y puede habilitarla en Azure Portal.
Azure Kubernetes Service

La instrumentación sin código de Azure Kubernetes Service está disponible actualmente para aplicaciones Java a
través del agente independiente.
Conjunto de escalado de máquinas virtuales y máquinas virtuales de

Azure con Windows
La instrumentación automática para máquinas virtuales de Azure y el conjunto de escalado de máquinas virtuales
está disponible para las aplicaciones .NET
Servidores locales
Puede habilitar fácilmente la supervisión de sus servidores de Windows locales para las aplicaciones .NET y para
las aplicaciones Java.
Otros entornos
El versátil agente independiente de Java funciona en cualquier entorno, por lo que no es necesario instrumentar el
código. Siga esta guía para habilitar Application Insights y obtener información sobre las increíbles funcionalidades
del agente de Java. El agente se encuentra en versión preliminar pública y está disponible en todas las regiones.
Pasos siguientes
Información general de Application Insights
Mapa de aplicación
Implementación de Azure Application Insights
Agent en máquinas virtuales de Azure y
conjuntos de escalado de máquinas virtuales de
Azure
La habilitación de la supervisión en las aplicaciones web basadas en .NET que se ejecutan en máquinas
virtuales de Azure y conjuntos de escalado de máquinas virtuales ahora es más fácil que nunca. Obtenga
todas las ventajas de usar Application Insights sin modificar el código.
En este artículo se le guía a través de la habilitación de la supervisión de Application Insights mediante
Application Insights Agent y se proporcionan instrucciones preliminares para automatizar el proceso para
implementaciones a gran escala.
IMPORTANT
Azure Application Insights Agent para .NET está actualmente en la versión preliminar pública. Esta versión preliminar
se ofrece sin un Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible
que algunas características no sean compatibles o que tengan sus funcionalidades limitadas. Para más información,
consulte Términos de uso complementarios de las Versiones Preliminares de Microsoft Azure.

Hay dos maneras de habilitar la supervisión de aplicaciones para las aplicaciones hospedadas en máquinas
virtuales y conjuntos de escalado de máquinas virtuales de Azure:
Sin código a través de Application Insights Agent
Este método es el más fácil de habilitar y no requiere ninguna configuración avanzada. A
menudo se conoce como supervisión de "entorno en tiempo de ejecución".
En el caso de las máquinas virtuales de Azure y los conjuntos de escalado de máquinas
virtuales de Azure, se recomienda habilitar, como mínimo, este nivel de supervisión. Después,
en función del escenario, puede evaluar si la instrumentación manual es necesaria.
Application Insights Agent recopila automáticamente las mismas señales de dependencia que
el SDK de NET. Consulte Recopilación automática de dependencias para más información.
NOTE
En la actualidad, solo se admiten las aplicaciones .NET hospedadas en IIS. Use un SDK para
instrumentar aplicaciones ASP.NET Core, Java y Node.js hospedadas en máquinas virtuales de Azure y
conjuntos de escalado de máquinas virtuales.
Basado en código mediante SDK

Este enfoque es mucho más personalizable, pero requiere la incorporación de una
dependencia en los paquetes NuGet del SDK de Application Insights. Este método también
implica que el usuario tiene que administrar las actualizaciones a la versión más reciente de
los paquetes.
Si necesita realizar llamadas de API personalizadas para supervisar eventos o dependencias
no capturados de manera predeterminada con la supervisión basada en agentes, deberá usar
este método. Consulte el artículo API de Application Insights para eventos y métricas
personalizados para obtener más información.
NOTE
Si se detecta tanto la supervisión basada en agentes como la instrumentación manual basada en SDK, solo se
respetará la configuración de la instrumentación manual. Esto es para evitar que se envíen datos duplicados. Para
más información sobre este tema, consulte la sección Solución de problemas a continuación.
Administración de Application Insights Agent para aplicaciones

.NET en máquinas virtuales de Azure mediante PowerShell
NOTE
Para instalar Application Insights Agent, necesitará una cadena de conexión. Cree un nuevo recurso de Application
Insights o copie la cadena de conexión de un recurso de Application Insights existente.
NOTE
¿Es nuevo en PowerShell? Eche un vistazo a la Guía de introducción.
Instalación o actualización de Application Insights Agent como una extensión para las máquinas virtuales de
Azure
$publicCfgJsonString = '
{
"redfieldConfiguration": {
"instrumentationKeyMap": {
"filters": [
{
"appFilter": ".*",
"machineFilter": ".*",
"virtualPathFilter": ".*",
"instrumentationSettings" : {
"connectionString": "InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
}
]
}
}
}
';
$privateCfgJsonString = '{}';
Set-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Location "

<myVmLocation>" -Name "ApplicationMonitoring" -Publisher "Microsoft.Azure.Diagnostics" -Type
"ApplicationMonitoringWindows" -Version "2.8" -SettingString $publicCfgJsonString -
ProtectedSettingString $privateCfgJsonString
NOTE
Puede instalar o actualizar Application Insights Agent como una extensión en varias máquinas virtuales a escala
mediante un bucle de PowerShell.
Desinstalación de la extensión de Agent de Application Insights desde una máquina virtual de Azure
Remove-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Name

"ApplicationMonitoring"
Consulta del estado de la extensión Application Insights Agent para una máquina virtual de Azure
Get-AzVMExtension -ResourceGroupName "<myVmResourceGroup>" -VMName "<myVmName>" -Name

ApplicationMonitoring -Status
Obtención de la lista de extensiones instaladas para la máquina virtual de Azure
Get-AzResource -ResourceId
"/subscriptions/<mySubscriptionId>/resourceGroups/<myVmResourceGroup>/providers/Microsoft.Compute/virtu
alMachines/<myVmName>/extensions"
# Name : ApplicationMonitoring
# ResourceGroupName : <myVmResourceGroup>
# ResourceType : Microsoft.Compute/virtualMachines/extensions
# Location : southcentralus
# ResourceId :
/subscriptions/<mySubscriptionId>/resourceGroups/<myVmResourceGroup>/providers/Microsoft.Compute/virtua
lMachines/<myVmName>/extensions/ApplicationMonitoring
También puede ver las extensiones instaladas en la hoja de la máquina virtual de Azure en el portal.
NOTE
Para comprobar la instalación, haga clic en Live Metrics Stream en el recurso de Application Insights asociado a la
cadena de conexión que usó para implementar la extensión de Application Insights Agent. Si va a enviar datos desde
varias máquinas virtuales, seleccione las máquinas virtuales de Azure de destino en nombre del servidor. Los datos
pueden tardar hasta un minuto en empezar a fluir.
Administración de Application Insights Agent para aplicaciones

.NET en conjuntos de escalado de máquinas virtuales de Azure
mediante PowerShell
Instalación o actualización de Application Insights Agent como una extensión para el conjunto de escalado
de máquinas virtuales de Azure
$publicCfgHashtable =
@{
"redfieldConfiguration"= @{
"instrumentationKeyMap"= @{
"filters"= @(
@{
"appFilter"= ".*";
"machineFilter"= ".*";
"virtualPathFilter": ".*",
"instrumentationSettings" : {
"connectionString": "InstrumentationKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # Application
Insights connection string, create new Application Insights resource if you don't have one.
https://ms.portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/microsoft.insights%2F
components
}
}
)
}
}
};
$privateCfgHashtable = @{};
$vmss = Get-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "<myVmssName>"
Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "ApplicationMonitoring" -Publisher

"Microsoft.Azure.Diagnostics" -Type "ApplicationMonitoringWindows" -TypeHandlerVersion "2.8" -Setting
$publicCfgHashtable -ProtectedSetting $privateCfgHashtable
Update-AzVmss -ResourceGroupName $vmss.ResourceGroupName -Name $vmss.Name -VirtualMachineScaleSet $vmss
# Note: depending on your update policy, you might need to run Update-AzVmssInstance for each instance
Desinstalación de la extensión de supervisión de aplicaciones desde conjuntos de escalado de máquinas

virtuales de Azure
$vmss = Get-AzVmss -ResourceGroupName "<myResourceGroup>" -VMScaleSetName "<myVmssName>"
Remove-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "ApplicationMonitoring"
Update-AzVmss -ResourceGroupName $vmss.ResourceGroupName -Name $vmss.Name -VirtualMachineScaleSet $vmss
# Note: depending on your update policy, you might need to run Update-AzVmssInstance for each instance
Estado de la extensión de supervisión de aplicaciones de consulta para conjuntos de escalado de máquinas

virtuales de Azure
# Not supported by extensions framework
Obtención de la lista de extensiones instaladas para conjuntos de escalado de máquinas virtuales de Azure
Get-AzResource -ResourceId
/subscriptions/<mySubscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualM
achineScaleSets/<myVmssName>/extensions
# Name : ApplicationMonitoringWindows
# ResourceGroupName : <myResourceGroup>
# ResourceType : Microsoft.Compute/virtualMachineScaleSets/extensions
# Location :
# ResourceId :
/subscriptions/<mySubscriptionId>/resourceGroups/<myResourceGroup>/providers/Microsoft.Compute/virtualM
achineScaleSets/<myVmssName>/extensions/ApplicationMonitoringWindows
Busque sugerencias para la solución de problemas de la extensión de Agent de Application Insights para las
aplicaciones .NET que se ejecutan en máquinas virtuales de Azure y en conjuntos de escalado de máquinas
virtuales.
NOTE
Las aplicaciones .NET Core, Java y Node.js solo se admiten en máquinas virtuales y conjuntos de escalado de
máquinas virtuales de Azure a través de la instrumentación manual basada en SDK y, por tanto, los pasos siguientes
no se aplican a estos escenarios.
El resultado de la ejecución de las extensiones se registra en los archivos que se encuentran en los
siguientes directorios:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.ApplicationMonitoringWindows\<version>\
Pasos siguientes
Obtenga información sobre cómo implementar una aplicación en un conjunto de escalado de máquinas
virtuales de Azure.
Configure pruebas web de disponibilidad para recibir una alerta si el punto de conexión deja de estar
activo.
Supervisar el rendimiento de Azure App Service
Ahora, habilitar la supervisión en las aplicaciones web basadas en ASP.NET y ASP.NET Core que se
ejecutan en Azure App Services es más fácil que nunca. Mientras que antes era necesario instalar
manualmente una extensión de sitio, ahora el agente o la extensión más reciente están integrados en la
imagen de App Service de manera predeterminada. En este artículo le guiaremos a través de la
habilitación de la supervisión de Application Insights y proporcionaremos instrucciones preliminares
para automatizar el proceso para implementaciones a gran escala.
NOTE
Agregar manualmente una extensión de sitio de Application Insights a través de Herramientas de desarrollo
> Extensiones está en desuso. Este método de instalación de extensiones dependía de actualizaciones manuales
para cada nueva versión. La versión estable más reciente de la extensión ahora viene preinstalada como parte de
la imagen de App Service. Los archivos se encuentran en
d:\Program Files (x86)\SiteExtensions\ApplicationInsightsAgent y se actualizan automáticamente con
cada versión estable. Si sigue las instrucciones basadas en agentes para habilitar la supervisión a continuación, se
quitará automáticamente la extensión en desuso.

Hay dos maneras de habilitar la supervisión de aplicaciones para las aplicaciones hospedadas de Azure
App Service:
Super visión de aplicaciones basadas en agentes (ApplicationInsightsAgent).
Este método es el más fácil de habilitar y no requiere ninguna configuración avanzada. A
menudo se conoce como supervisión de "entorno en tiempo de ejecución". Para Azure App
Services se recomienda la habilitación de este nivel de supervisión como mínimo y, a
continuación, en función del escenario específico, puede evaluar si es necesaria una
supervisión más avanzada a través de instrumentación manual.
Instrumentación manual de la aplicación mediante código mediante la instalación del SDK
Este enfoque es mucho más personalizable, pero requiere la incorporación de una
dependencia en los paquetes NuGet del SDK de Application Insights. Este método también
implica que el usuario tiene que administrar las actualizaciones a la versión más reciente de
los paquetes.
Si necesita realizar llamadas de API personalizadas para supervisar eventos o dependencias
no capturados de manera predeterminada con la supervisión basada en agentes, deberá
usar este método. Consulte el artículo API de Application Insights para eventos y métricas
personalizados para obtener más información. Actualmente, esta es la única opción
admitida para las cargas de trabajo basadas en Linux.
NOTE
Si se detectan tanto la supervisión basada en agentes como la instrumentación manual basada en SDK, solo se
respetará la configuración de la instrumentación manual. Esto es para evitar que se envíen datos duplicados. Para
más información sobre este tema, consulte la sección de solución de problemas que encontrará a continuación.
Habilitación de la supervisión basada en agente

.NET
.NET Core
Node.js
Java
Python
NOTE
No se admite la combinación de APPINSIGHTS_JAVASCRIPT_ENABLED y urlCompression. Para más información,
consulte la explicación de la sección Solución de problemas.
1. Seleccione Application Insights en el panel de control de Azure para el servicio de

aplicaciones.
Elija crear un nuevo recurso a menos que ya haya configurado un recurso de Application
Insights para esta aplicación.
NOTE
Al hacer clic en Aceptar para crear el nuevo recurso, se le pedirá Aplicar la configuración de
super visión . Con la selección de Continuar se vinculará el nuevo recurso de Application Insights
a su servicio de aplicaciones. Al hacerlo, también se desencadenará un reinicio del ser vicio
de aplicaciones .
2. Después de especificar qué recurso se debe usar, puede elegir cómo quiere que Application
Insights recopile los datos de cada plataforma para la aplicación. La supervisión de aplicaciones
ASP.NET está activada de manera predeterminada con dos niveles diferentes de la colección.
A continuación se muestra un resumen de los datos recopilados para cada ruta:

REC O P IL A C IÓ N REC O M EN DA DA DE
DATA REC O P IL A C IÓ N B Á SIC A DE . N ET . N ET
Agrega las tendencias de uso de Sí Sí

CPU, memoria y E/S.
Recopila las tendencias de uso y Sí Sí

habilita la correlación entre los
resultados de disponibilidad y las
transacciones.
Recopila las excepciones no Sí Sí

controladas por el proceso de host.
Mejora la precisión de las métricas Sí Sí

de APM con carga, cuando se usa el
muestreo.
Correlaciona los microservicios No (solo funcionalidades de APM de Sí

entre los límites de solicitud y instancia única)
dependencia.
3. Para configurar valores como el muestreo, que anteriormente se podía controlar mediante el
archivo applicationinsights.config, ahora puede interactuar con esos mismos valores a través de la
configuración de la aplicación con un prefijo correspondiente.
Por ejemplo, para cambiar el porcentaje de muestreo inicial, puede crear una configuración
de la aplicación de
MicrosoftAppInsights_AdaptiveSamplingTelemetryProcessor_InitialSamplingPercentage y un
valor de 100 .
Para obtener la lista de valores de configuración de procesador de telemetría de muestreo
adaptable compatibles, puede consultar el código y la documentación asociada.
Habilitación de la supervisión del lado cliente

.NET
.NET Core
Node.js
Java
Python
La supervisión de cliente está habilitada en ASP.NET. Para habilitar la supervisión de cliente:
Parámetros > Configuración
En Configuración de la aplicación, cree una nueva configuración de la aplicación :
Nombre: APPINSIGHTS_JAVASCRIPT_ENABLED
Valor: true
Guarde la configuración y reinicie la aplicación.

Para deshabilitar la supervisión de cliente, quite el par clave-valor asociado de la configuración de la
aplicación o establezca el valor en false.
Automatización de la supervisión
Con el fin de habilitar la recopilación de datos de telemetría con Application Insights, la configuración de
la aplicación deberá configurarse:
Definiciones de los valores de configuración de la aplicación

N O M B RE DEL VA LO R DE
C O N F IGURA C IÓ N DE L A
A P L IC A C IÓ N DEF IN IC IÓ N VA L UE
ApplicationInsightsAgent_EXTENSIO Extensión principal; controla la ~2

N_VERSION supervisión en el entorno en tiempo
de ejecución.
XDT_MicrosoftApplicationInsights_ Solo en el modo predeterminado; se default o recommended .

Mode habilitan las características
esenciales para garantizar un
rendimiento óptimo.
InstrumentationEngine_EXTENSION Controla si se activa el motor ~1

_VERSION InstrumentationEngine de
reescritura binaria. Esta
configuración tiene implicaciones de
rendimiento y afecta a la hora de
inicio o al arranque en frío.
XDT_MicrosoftApplicationInsights_B Controla si el texto de la tabla SQL y ~1

aseExtensions Azure se captura junto con las
llamadas de dependencia.
Advertencia de rendimiento: el
tiempo de inicio en frío de la
aplicación se verá afectado. Esta
configuración requiere el elemento
InstrumentationEngine .
Configuración de la aplicación de App Service con Azure Resource Manager

La configuración de la aplicación de App Service se puede administrar y configurar con plantillas de
Azure Resource Manager. Este método puede usarse al implementar nuevos recursos de App Service con
la automatización de Azure Resource Manager o para modificar la configuración de los recursos
existentes.
La estructura básica de JSON de la configuración de la aplicación para App Service se muestra a
continuación:
"resources": [
{
"name": "appsettings",
"type": "config",
"apiVersion": "2015-08-01",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', variables('webSiteName'))]"
],
"tags": {
"displayName": "Application Insights Settings"
},
"properties": {
"key1": "value1",
"key2": "value2"
}
}
]
Para obtener un ejemplo de una plantilla de Azure Resource Manager con la configuración de la
aplicación establecida para Application Insights, esta plantilla puede resultar útil, sobre todo en la sección
que empieza a partir de la línea 238.
Automatización de la creación de un recurso de Application Insights y vínculo a la instancia de App
Service recién creada
Para crear una plantilla de Azure Resource Manager con toda la configuración predeterminada de
Application Insights establecida, comience el proceso como si fuese a crear una nueva aplicación web
con Application Insights habilitado.
Seleccione Opciones de automatización .
Esta opción genera la plantilla de Azure Resource Manager más reciente con toda la configuración
necesaria establecida.
A continuación, se muestra un ejemplo; reemplace todas las instancias de AppMonitoredSite por el
nombre del sitio:
{
"resources": [
{
"properties": {
"siteConfig": {
"appSettings": [
{
"value": "[reference('microsoft.insights/components/AppMonitoredSite',
'2015-05-01').InstrumentationKey]"
},
{
"value": "[reference('microsoft.insights/components/AppMonitoredSite',
'2015-05-01').ConnectionString]"
},
{
"value": "~2"
}
]
},
"serverFarmId": "[concat('/subscriptions/',
parameters('subscriptionId'),'/resourcegroups/', parameters('serverFarmResourceGroup'),
'/providers/Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]",
"hostingEnvironment": "[parameters('hostingEnvironment')]"
},
"dependsOn": [
"[concat('Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]",
"microsoft.insights/components/AppMonitoredSite"
],
"apiVersion": "2016-03-01",
"location": "[parameters('location')]"
},
{
"apiVersion": "2016-09-01",
"name": "[parameters('hostingPlanName')]",
"type": "Microsoft.Web/serverfarms",
"properties": {
"name": "[parameters('hostingPlanName')]",
"workerSizeId": "[parameters('workerSize')]",
"workerSizeId": "[parameters('workerSize')]",
"numberOfWorkers": "1",
"hostingEnvironment": "[parameters('hostingEnvironment')]"
},
"sku": {
"Tier": "[parameters('sku')]",
"Name": "[parameters('skuCode')]"
}
},
{
"apiVersion": "2015-05-01",
"name": "AppMonitoredSite",
"location": "West US 2",
"properties": {
}
}
],
"parameters": {
"name": {
"type": "string"
},
"type": "string"
},
"hostingEnvironment": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"skuCode": {
"type": "string"
},
"workerSize": {
"type": "string"
},
"type": "string"
},
"subscriptionId": {
"type": "string"
}
},
"$schema": "https://schema.management.azure.com/schemas/2014-04-01-
preview/deploymentTemplate.json#",
"contentVersion": "1.0.0.0"
}
Habilitación a través de PowerShell

Para habilitar la supervisión de la aplicación a través de PowerShell, solo se debe cambiar la
configuración de la aplicación subyacente. A continuación, se muestra un ejemplo que habilita la
supervisión de la aplicación para un sitio web denominado "AppMonitoredSite" en el grupo de recursos
"AppMonitoredRG" y configura los datos para que se envíen a la clave de instrumentación "012345678-
abcd-ef01-2345-6789abcd".
NOTE
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre
la instalación del módulo Az, consulte Instalación de Azure PowerShell.
$app = Get-AzWebApp -ResourceGroupName "AppMonitoredRG" -Name "AppMonitoredSite" -ErrorAction Stop

$newAppSettings = @{} # case-insensitive hash map
$app.SiteConfig.AppSettings | %{$newAppSettings[$_.Name] = $_.Value} # preserve non Application
Insights application settings.
$newAppSettings["APPINSIGHTS_INSTRUMENTATIONKEY"] = "012345678-abcd-ef01-2345-6789abcd"; # set the
Application Insights instrumentation key
$newAppSettings["APPLICATIONINSIGHTS_CONNECTION_STRING"] = "InstrumentationKey=012345678-abcd-ef01-
2345-6789abcd"; # set the Application Insights connection string
$newAppSettings["ApplicationInsightsAgent_EXTENSION_VERSION"] = "~2"; # enable the
ApplicationInsightsAgent
$app = Set-AzWebApp -AppSettings $newAppSettings -ResourceGroupName $app.ResourceGroup -Name
$app.Name -ErrorAction Stop
Actualización del agente o extensión de supervisión

Actualización de las versiones 2.8.9 y posteriores
La actualización de la versión 2.8.9 se realiza automáticamente, sin acciones adicionales. Los nuevos bits
de supervisión se proporcionan en segundo plano para el servicio de aplicación de destino y se recogen
en el reinicio de la aplicación.
Para comprobar qué versión de la extensión se ejecuta, visite
http://yoursitename.scm.azurewebsites.net/ApplicationInsights
Actualización de las versiones 1.0.0 a 2.6.5

A partir de la versión 2.8.9 se usa la extensión de sitio preinstalada. Si tiene una versión anterior, puede
actualizarla de dos maneras:
Actualización mediante la habilitación a través del portal. (Incluso si tiene la extensión Application
Insights para Azure App Service instalada, la interfaz de usuario solo muestra el botón Habilitar .
En segundo plano, la anterior extensión de sitio privada se quitará).
Actualización a través de PowerShell:
1. Establezca la configuración de la aplicación para habilitar la extensión de sitio preinstalada
ApplicationInsightsAgent. Consulte Habilitación a través de PowerShell.
2. Quite manualmente la extensión de sitio privada denominada extensión de Application Insights
para Azure App Service.
Si se realiza la actualización desde una versión anterior a la 2.5.1, compruebe que los archivos DLL de
ApplicationInsigths se quitan de la carpeta de la ubicación de la aplicación. Vea los pasos para la solución
de problemas.
A continuación, se muestra nuestra guía paso a paso de solución de problemas para la supervisión
basada en extensiones o agentes para aplicaciones basadas en .NET y .NET Core que se ejecutan en Azure
App Services.
NOTE
Las aplicaciones Java solo se admiten en Azure App Services mediante la instrumentación manual basada en SDK
y, por tanto, los pasos siguientes no se aplican a estos escenarios.
1. Compruebe que la aplicación se supervisa a través de ApplicationInsightsAgent .

Compruebe que la configuración de la aplicación ApplicationInsightsAgent_EXTENSION_VERSION
se establece en un valor de "~2".
2. Asegúrese de que la aplicación cumple los requisitos que se deben supervisar.
Vaya a https://yoursitename.scm.azurewebsites.net/ApplicationInsights .
Confirme que el Application Insights Extension Status es

Pre-Installed Site Extension, version 2.8.12.1527, is running. .
Si no se está ejecutando, siga las instrucciones para habilitar la supervisión de
Confirme que el origen de estado existe y tiene el siguiente aspecto:
Status source
D:\home\LogFiles\ApplicationInsights\status\status_RD0003FF0317B6_4248_1.json
.
Si no está presente un valor similar, significa que la aplicación no se admite o no se está
ejecutando actualmente. Para asegurarse de que la aplicación se está ejecutando, intente
visitar manualmente los puntos de conexión de la aplicación o la dirección URL de la
aplicación, lo que permitirá que la información del entorno en tiempo de ejecución esté
disponible.
Confirme que IKeyExists es true .
Si es false , agregue APPINSIGHTS_INSTRUMENTATIONKEY y
APPLICATIONINSIGHTS_CONNECTION_STRING con el GUID de ikey a la configuración de la
aplicación.
Confirme que no hay ninguna entrada para AppAlreadyInstrumented ,
AppContainsDiagnosticSourceAssembly y AppContainsAspNetTelemetryCorrelationAssembly .
Si existe alguna de estas entradas, quite los siguientes paquetes de la aplicación:

Microsoft.ApplicationInsights , System.Diagnostics.DiagnosticSource y
Microsoft.AspNet.TelemetryCorrelation .
La tabla siguiente proporciona una explicación más detallada de lo que significan estos valores, sus
causas subyacente y las correcciones recomendadas:
VA LO R DEL P RO B L EM A EXP L IC A C IÓ N F IX
AppAlreadyInstrumented:true Este valor indica que la extensión haQuite las referencias. Algunas de
detectado que algún aspecto del estas referencias se agregan de
SDK ya está presente en la manera predeterminada en
aplicación y se interrumpirá. Puede determinadas plantillas de Visual
deberse a una referencia a Studio y las versiones anteriores de
System.Diagnostics.DiagnosticSourceVisual Studio pueden agregar
, referencias a
Microsoft.AspNet.TelemetryCorrelation .
o
Microsoft.ApplicationInsights .
AppAlreadyInstrumented:true Si la aplicación tiene como destino Se recomienda que los clientes con
.NET Core 2.1 o 2.2 y hace .NET Core 2.1 o 2.2 usen el
referencia al metapaquete metapaquete
Microsoft.AspNetCore.All, se Microsoft.AspNetCore.App en su
incorporará a Application Insights y lugar.
la extensión se interrumpirá.
AppAlreadyInstrumented:true Este valor también puede deberse a Limpie la carpeta de la aplicación

la presencia de los archivos DLL para asegurarse de que se han
anteriores en la carpeta de la quitado estos archivos DLL.
aplicación de una implementación Compruebe el directorio "bin" de la
anterior. aplicación local y el directorio
"wwwroot" de App Service. (Para
comprobar el directorio "wwwroot"
de la aplicación web de App Service:
herramientas avanzadas (Kudu) >
Consola de depuración > CMD >
home\site\wwwroot).
Este valor indica que la extensión

AppContainsAspNetTelemetryCorrelationAssembly: Quite la referencia.
true detectó referencias a
Microsoft.AspNet.TelemetryCorrelation
en la aplicación y se interrumpirá.
Este valor indica que la extensión

AppContainsDiagnosticSourceAssembly**:true Quite la referencia.
detectó referencias a
System.Diagnostics.DiagnosticSource
en la aplicación y se interrumpirá.
VA LO R DEL P RO B L EM A EXP L IC A C IÓ N F IX
IKeyExists:false Este valor indica que la clave de Asegúrese de que la configuración

instrumentación no está presente está presente en la configuración de
en la AppSetting, la aplicación de App Service.
APPINSIGHTS_INSTRUMENTATIONKEY
. Causas posibles: Es posible que los
valores se hayan eliminado por
accidente, que haya olvidado
establecer los valores en el script de
automatización, etc.
No se admite APPINSIGHTS_JAVASCRIPT_ENABLED ni urlCompression

Si usa APPINSIGHTS_JAVASCRIPT_ENABLED=true en casos donde el contenido está codificado, podría
obtener errores como los siguientes:
Error de reescritura de dirección URL 500
Error de módulo de reescritura de dirección URL 500.53 con el mensaje Las reglas de reescritura
saliente no se pueden aplicar cuando el contenido de la respuesta HTTP está codificado ("gzip").
Esto se debe a que la configuración de la aplicación APPINSIGHTS_JAVASCRIPT_ENABLED está
establecida en true y la codificación de contenido está presente al mismo tiempo. Este escenario aún no
se admite. La solución consiste en quitar APPINSIGHTS_JAVASCRIPT_ENABLED de la configuración de la
aplicación. Esto significa que si la instrumentación de JavaScript del lado cliente o explorador sigue
siendo necesaria, se necesitan referencias del SDK manuales para las páginas web. Siga las instrucciones
para la instrumentación manual con el SDK de JavaScript.
Para obtener la información más reciente sobre la extensión o el agente de Application Insights, consulte
las notas de la versión.
El sitio web predeterminado implementado con las aplicaciones web no admite la supervisión
automática de cliente.
Cuando se crea una aplicación web con los entornos de ejecución ASP.NET o .NET Core en instancias de
Azure App Service, implementa una única página HTML estática como sitio web de inicio. La página web
estática también carga un elemento web administrado de .NET en IIS. Esto permite probar la supervisión
sin código del lado servidor, pero no admite la supervisión automática de cliente.
Si desea probar el servidor sin código y la supervisión de cliente para ASP.NET o ASP.NET Core en una
aplicación web de Azure App Services, se recomienda seguir las guías oficiales para crear una aplicación
web ASP.NET Core y crear una aplicación web de ASP.NET Framework y después usar las instrucciones
del artículo actual para habilitar la supervisión.
PHP y WordPress no se admiten
Los sitios de PHP y WordPress no se admiten. Actualmente, no hay ningún SDK/agente compatible
oficialmente para la supervisión del lado servidor de estas cargas de trabajo. Sin embargo, la
instrumentación manual de transacciones del lado cliente en un sitio de PHP o WordPress agregando el
JavaScript del lado cliente a las páginas web puede realizarse mediante el SDK de JavaScript.
Cadena de conexión y clave de instrumentación
Al utilizar la supervisión sin código, solo se requiere la cadena de conexión. Sin embargo, todavía se
recomienda establecer la clave de instrumentación para mantener la compatibilidad con versiones
anteriores de SDK cuando se realiza la instrumentación manual.
Pasos siguientes
Ejecute el generador de perfiles en la aplicación activa.
Azure Functions: supervisar Azure Functions con Application Insights
Microsoft Azure Diagnostics para enviar este tipo de información a Application Insights.
Supervise las métricas del estado del servicio para asegurarse de que el servicio está disponible y
responde adecuadamente.
Reciba notificaciones de alerta cada vez que se produzcan eventos de operaciones o las métricas
traspasen un umbral.
Use aplicaciones y páginas web de Application Insights para JavaScript para obtener la telemetría del
cliente de los exploradores que visitan una página web.
Configure pruebas web de disponibilidad para recibir una alerta si el sitio deja de estar activo.
Application Insights para Azure Cloud Services
Application Insights puede supervisar las aplicaciones de Azure Cloud Service para comprobar la
disponibilidad, el rendimiento, los errores y el uso al combinar datos de los SDK de Application Insights con
datos de Azure Diagnostics de los servicios en la nube. Con los comentarios que obtendrá sobre el
rendimiento y la eficacia de la aplicación en su entorno natural, pueda tomar decisiones meditadas sobre la
dirección del diseño en cada ciclo de vida de desarrollo.
Requisitos previos
Antes de comenzar, necesitará lo siguiente:
Una suscripción a Azure. Inicie sesión con una cuenta Microsoft para Windows, Xbox Live u otros
servicios en la nube de Microsoft.
Herramientas de Microsoft Azure 2.9 o posterior.
Developer Analytics Tools 7.10 o posterior.
Introducción rápida
La manera más rápida y sencilla de supervisar su servicio en la nube con Application Insights es elegir esa
opción al publicar su servicio en Azure.
Esta opción instrumenta una aplicación en el entorno de ejecución, lo que le proporciona la telemetría que
necesita para supervisar las solicitudes, excepciones y dependencias en el rol web. También supervisa los
contadores de rendimiento de los roles de trabajo. Los seguimientos de diagnóstico que la aplicación genera
también se envían a Application Insights.
Si esta opción es todo lo que necesita, ha terminado.
Los siguientes pasos son ver las métricas de la aplicación y consultar los datos con Analytics.
Para supervisar el rendimiento en el explorador, puede que quiera configurar pruebas de disponibilidad y
agregar código a las páginas web.
Las secciones siguientes tratan las siguientes opciones adicionales:
Enviar datos de diferentes componentes y crear configuraciones para separar recursos.
Agregar telemetría personalizada desde su aplicación.
Aplicación de ejemplo instrumentada con Application Insights

En esta aplicación de ejemplo, Application Insights se agrega a un servicio en la nube con dos roles de
trabajo hospedados en Azure.
En la sección a continuación, se explica cómo adaptar su propio proyecto de servicio en la nube de la misma
manera.
Planeamiento de recursos y grupos de recursos

La telemetría de la aplicación se almacena, analiza y muestra en un recurso de Azure de tipo Application
Insights.
Cada recurso pertenece a un grupo de recursos. Los grupos de recursos se usan para administrar los costos,
para conceder acceso a los miembros del equipo y para implementar las actualizaciones en una transacción
coordinada única. Por ejemplo, podría escribir un script para implementar un servicio en la nube de Azure y
sus recursos de supervisión de Application Insights en una operación todo en uno.
Recursos para componentes
Le recomendamos que cree un recurso independiente para cada componente de la aplicación. Es decir, crear
un recurso para cada rol web y rol de trabajo. Puede analizar cada componente por separado, pero crear un
panel que reúna los gráficos de clave de todos los componentes, de modo que pueda compararlos y
supervisarlos conjuntamente de un solo vistazo.
Un enfoque alternativo consiste en enviar la telemetría de más de un rol al mismo recurso, pero agregar una
propiedad de dimensión para cada elemento de telemetría que identifique su rol de origen. En este enfoque,
los gráficos de métricas, como las excepciones, normalmente muestran una agregación de las cuentas de
diferentes roles, pero puede segmentar el gráfico por el identificador de rol cuando sea necesario. También
se pueden filtrar las búsquedas por la misma dimensión. Esta alternativa hace un poco más fácil el poder ver
todo al mismo tiempo, pero también puede causar confusión entre los roles.
La telemetría del explorador suele incluirse en el mismo recurso que su rol web de lado servidor.
Coloque los recursos de Application Insights para los diferentes componentes en un grupo de recursos. Este
enfoque facilita administrarlos juntos.
Separación de desarrollo, prueba y producción
Si va a desarrollar eventos personalizados para la característica siguiente mientras la versión anterior está
activa, querrá enviar la telemetría de desarrollo a un recurso de Application Insights independiente. De lo
contrario, puede resultar difícil encontrar su telemetría de prueba entre todo el tráfico desde el sitio activo.
Para evitar esta situación, cree recursos independientes para cada configuración de compilación o "sello"
(desarrollo, prueba, producción, etc.) del sistema. Coloque los recursos para cada configuración de
compilación en un grupo de recursos independiente.
Para enviar la telemetría a los recursos adecuados, puede configurar el SDK de Application Insights para que
seleccione una clave de instrumentación diferente dependiendo de la configuración de compilación.
Creación de un recurso de Application Insights para cada rol

Si ha decidido crear un recurso independiente para cada rol, y quizás otro conjunto distinto para cada
configuración de compilación, es más fácil crearlos en el portal de Application Insights. Si crea muchos
recursos, puede automatizar el proceso.
1. En Azure Portal, seleccione Nuevo > Ser vicios de desarrollo > Application Insights .
2. En la lista desplegable Tipo de aplicación , seleccione Aplicación web ASP.NET .

Cada recurso se identifica con una clave de instrumentación. Podría necesitar esta clave más adelante si
quisiera configurar o comprobar manualmente la configuración del SDK.
Configuración de Diagnósticos de Azure para cada rol

Establezca esta opción para supervisar la aplicación con Application Insights. Para los roles web, esta opción
permite la supervisión del rendimiento, alertas y diagnósticos, así como el análisis del uso. Para otros roles,
puede buscar y supervisar Azure Diagnostics, como el reinicio, los contadores de rendimiento y las llamadas
a System.Diagnostics.Trace.
1. En el Explorador de soluciones de Visual Studio, en <YourCloudSer vice> > Roles , abra las
propiedades de cada rol.
2. En Configuración , seleccione la casilla Enviar datos de diagnóstico a Application Insights y
seleccione el recurso de Application Insights adecuado que creó anteriormente.
Si ha decidido usar un recurso de Application Insights distinto para cada configuración de compilación,
seleccione primero la configuración.
Esto tiene el efecto de insertar las claves de instrumentación de Application Insights en los archivos
denominados ServiceConfiguration.*.cscfg. Este es el ejemplo de código.
Si quiere modificar el nivel de la información de diagnóstico enviada a Application Insights, puede hacerlo
editando los archivos .cscfg directamente.
Instalación del SDK en cada proyecto

Con esta opción, puede agregar telemetría de negocio personalizada a cualquier rol. La opción proporciona
un análisis más detallado de cómo la aplicación se usa y se comporta.
En Visual Studio, configure el SDK de Application Insights para cada proyecto de aplicación en la nube.
1. Para configurar los roles web , haga clic con el botón derecho en el proyecto y seleccione
Configurar Application Insights o Agregar > Telemetría de Application Insights .
2. Para configurar roles de trabajo :
a. Haga clic con el botón derecho en el proyecto y seleccione Administrar paquetes NuGet .
b. Agregue Application Insights para servidores de Windows.
3. Para configurar el SDK para enviar datos al recurso de Application Insights.

a. En una función de inicio adecuada, establezca la clave de instrumentación a partir de la opción de
configuración del archivo .cscfg:
RoleEnvironment.GetConfigurationSettingValue("APPINSIGHTS_INSTRUMENTATIONKEY");
b. Repita el "paso a" para cada rol de la aplicación. Consulte los ejemplos:
Rol web
Rol de trabajo
Para las páginas web
4. Establezca el archivo ApplicationInsights.config para que se copie siempre en el directorio de salida.
Aparece un mensaje en el archivo .config en el que se le pide que coloque allí la clave de
instrumentación. Sin embargo, para las aplicaciones de nube es mejor establecerla desde el archivo
.cscfg. Este enfoque garantiza que el rol se identifica correctamente en el portal.
Configuración del monitor de estado para recopilar consultas

completas de SQL (opcional)
Este paso solo es necesario si quiere capturar consultas completas de SQL en .NET Framework.
1. En el archivo \*.csdef , agregue una tarea de inicio para todos los roles similares a
<Startup>
<Task commandLine="AppInsightsAgent\InstallAgent.bat" executionContext="elevated"
taskType="simple">
<Environment>
<Variable name="ApplicationInsightsAgent.DownloadLink"
value="http://go.microsoft.com/fwlink/?LinkID=522371" />
<Variable name="RoleEnvironment.IsEmulated">
<RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
</Variable>
</Environment>
</Task>
</Startup>
2. Descargue InstallAgent.bat e InstallAgent.ps1 y colóquelos en la carpeta AppInsightsAgent de cada

proyecto de rol. Asegúrese de copiarlos en el directorio de salida a través de las propiedades de
archivo de Visual Studio o mediante scripts de compilación.
3. En todos los roles de trabajo, agregue las siguientes variables de entorno:
<Environment>
<Variable name="COR_ENABLE_PROFILING" value="1" />
<Variable name="COR_PROFILER" value="{324F817A-7420-4E6D-B3C1-143FBED6D855}" />
<Variable name="MicrosoftInstrumentationEngine_Host" value="{CA487940-57D2-10BF-11B2-
A3AD5A13CBC0}" />
</Environment>
Ejecución y publicación de la aplicación

1. Ejecute la aplicación e inicie sesión en Azure.
2. Abra los recursos de Application Insights que creó.
Los puntos de datos individuales se muestran en Buscar y los datos agregados se muestran en el
3. Agregue más telemetría (consulte las secciones siguientes) y luego publique la aplicación para
obtener diagnósticos en vivo y comentarios sobre el uso.
Si no hay ningún dato, haga lo siguiente:
1. Para ver los eventos individuales, abra el icono Búsqueda.
2. En la aplicación, abra distintas páginas para que genere telemetría.
3. Espere unos segundos y haga clic en Actualizar .
Para más información, consulte Solución de problemas.
Visualización de eventos de Microsoft Azure Diagnostics

En las siguientes ubicaciones, puede encontrar la información de Azure Diagnostics en Application Insights:
Los contadores de rendimiento se muestran como métricas personalizadas.
Los registros de eventos de Windows se muestran como seguimientos y eventos personalizados.
Los registros de aplicación, los registros ETW y los registros de infraestructura de diagnóstico aparecen
como seguimientos.
Para ver los recuentos de eventos y los contadores de rendimiento, abra Explorador de métricas y agregue
un nuevo gráfico:
Para buscar en los distintos registros de seguimiento enviados por Azure Diagnostics, use Búsqueda o una
consulta de Analytics. Por ejemplo, suponga que tiene una excepción no controlada que provocó el bloqueo
y reciclaje de un rol. Esa información aparecería en el canal Aplicación del registro de eventos de Windows.
Puede utilizar Buscar para ver el error del registro de eventos de Windows y obtener el seguimiento de la
pila completo para la excepción. Así podrá encontrar la causa principal del problema.
Más telemetría
En las secciones siguientes se describe cómo obtener telemetría adicional de diversos aspectos de la
aplicación.
Seguimiento de las solicitudes de roles de trabajo

En los roles web, el módulo de solicitudes recopila automáticamente datos acerca de las solicitudes HTTP.
Puede obtener ejemplos de cómo invalidar el comportamiento de la colección predeterminada si consulta el
MVCWebRole de ejemplo.
Puede capturar el rendimiento de las llamadas a los roles de trabajo realizando su seguimiento de la misma
manera que con las solicitudes HTTP. En Application Insights, el tipo de telemetría Solicitud mide una unidad
de trabajo del lado servidor con nombre que se puede programar y puede realizarse correctamente o
producir un error de forma independiente. Si bien el SDK captura automáticamente las solicitudes HTTP,
puede insertar su propio código para realizar el seguimiento de las solicitudes a los roles de trabajo.
Consulte los dos roles de trabajo de ejemplo instrumentados en las solicitudes de informes:
WorkerRoleA
WorkerRoleB
Excepciones
Para obtener información acerca de cómo puede recopilar excepciones no controladas de tipos de
aplicaciones web diferentes, consulte Supervisión de excepciones en Application Insights.
El rol de web ejemplo tiene los controladores MVC5 y Web API 2. Las excepciones no controladas de los dos
se capturan con los siguientes controladores:
La configuración de AiHandleErrorAttribute para los controladores MVC5 se muestran en este ejemplo
La configuración de AiWebApiExceptionLogger para los controladores Web API 2 se muestran en este
ejemplo
Para los roles de trabajo, el seguimiento de las excepciones se puede realizar de dos maneras:
Use TrackException(ex).
Si ha agregado el paquete NuGet del agente de escucha de seguimiento de Application Insights, puede
usar System.Diagnostics.Trace para registrar las excepciones como se muestra en este ejemplo.
Los siguientes contadores se recopilan de forma predeterminada:
\Process(??APP_WIN32_PROC??)% Tiempo de procesador
\Memoria\Bytes disponibles
.NET CLR Exceptions(??APP_CLR_PROC??)# of Exceps Thrown / sec
\Process(??APP_WIN32_PROC??)\Private Bytes
\Process(??APP_WIN32_PROC??)\IO Data Bytes/sec
Procesador(_Total)% Hora del procesador
Además, también se recopilan los siguientes contadores para los roles web:
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests/Sec
\ASP.NET Applications(??APP_W3SVC_PROC??)\Request Execution Time
\ASP.NET Applications(??APP_W3SVC_PROC??)\Requests In Application Queue
Puede especificar otros contadores de rendimiento de Windows o personalizados si modifica
ApplicationInsights.config como se muestra en este ejemplo.
Telemetría correlacionada para roles de trabajo
Para obtener una sofisticada experiencia de diagnóstico, puede ver qué provocó una solicitud de latencia alta
o con errores. Con los roles web, el SDK establece automáticamente una correlación entre la telemetría
relacionada.
Si desea lograr esta vista para los roles de trabajo, puede utilizar un inicializador de telemetría personalizado
para establecer un atributo de contexto Operation.Id común para toda la telemetría. Ello le permite
comprobar de un vistazo si el problema de latencia o de los errores se produjo debido a una dependencia o
al código.
A continuación, se indica cómo puede hacerlo.
Establezca el identificador de la correlación en una CallContext como se muestra en este ejemplo. En este
caso, usamos el identificador de solicitud como identificador de correlación.
Agregue una implementación personalizada de TelemetryInitializer para establecer el Operation.Id en el
correlationId que se estableció antes. Para obtener un ejemplo, consulte
ItemCorrelationTelemetryInitializer.
Agregue el inicializador de telemetría personalizado. Puede hacerlo en el archivo
ApplicationInsights.config o en el código según se muestra en este ejemplo.
Telemetría de cliente
Para obtener telemetría basada en el navegador (como recuentos de vista de página, tiempos de carga de
página y excepciones de script) y escribir telemetría personalizada en los scripts de página, consulte Adición
del SDK de JavaScript a las páginas web.
Pruebas de disponibilidad
Para comprobar que la aplicación efectivamente está activa y responde adecuadamente, configure las
pruebas web.
Mostrar todos los elementos juntos
Para obtener una imagen general del sistema, puede mostrar los gráficos de supervisión clave en un panel.
Por ejemplo, puede anclar la solicitud y el número de errores de cada rol.
Si el sistema usa otros servicios de Azure, como Stream Analytics, incluya también sus gráficos de
supervisión.
Si tiene una aplicación móvil cliente, utilice App Center. Cree consultas en Analytics para mostrar los
recuentos de eventos y anclarlos al panel.
Ejemplo
El ejemplo supervisa un servicio que tiene un rol web y dos roles de trabajo.
Excepción "Método no encontrado" en la ejecución en Azure Cloud

Services
¿Ha realizado la compilación para .NET 4.6? .NET 4.6 no se admite automáticamente en los roles de Azure
Cloud Service. Instale .NET 4.6 en cada rol antes de ejecutar la aplicación.
Vídeo
Pasos siguientes
Configuración del envío de diagnósticos de Azure a Application Insights
Creación automática de recursos de Application Insights
Automatización de Azure Diagnostics
Funciones de Azure
Supervisión de Azure Functions con Application
Insights de Azure Monitor
Azure Functions ofrece integración incorporada en Azure Application Insights para supervisar las funciones.
Application Insights recopila datos de registros, de rendimiento y de errores, y detecta automáticamente las
anomalías en el rendimiento. Application Insights incluye herramientas de análisis eficaces que ayudan a
diagnosticar problemas y comprender cómo se usan las funciones. Cuando tenga la visibilidad de los datos de su
aplicación, puede mejorar continuamente el rendimiento y la facilidad de uso. Incluso puede usar Application
Insights durante el desarrollo local de proyectos de aplicación de función.
La instrumentación de Application Insights necesaria está integrada en Azure Functions. Lo único que necesita es
una clave de instrumentación válida para conectar la aplicación de funciones a un recurso de Application Insights.
La clave de instrumentación debe agregarse a la configuración de la aplicación cuando se cree el recurso de la
aplicación de funciones en Azure. Si la aplicación de funciones aún no tiene esta clave, puede establecerla de
forma manual. Para obtener más información, lea sobre la supervisión de Azure Functions.
Seguimiento distribuido para aplicaciones Java en Windows (versión

preliminar pública)
IMPORTANT
Esta característica se encuentra actualmente en versión preliminar pública para Java Azure Functions en Windows; no se
admite el seguimiento distribuido para Java Azure Functions en Linux. En el plan de consumo, tiene un arranque en frío de 8
a 9 segundos.
Si las aplicaciones están escritas en Java, puede ver los datos enriquecidos de las aplicaciones de funciones,
incluidas las solicitudes, las dependencias, los registros y las métricas. Los datos adicionales también le permiten
ver y diagnosticar transacciones de un extremo a otro y ver el mapa de aplicación, que agrega muchas
transacciones para mostrar una vista topológica de cómo interactúan los sistemas y cuáles son las tasas promedio
de rendimiento y de errores.
Los diagnósticos de un extremo a otro y el mapa de aplicación proporcionan visibilidad en una única
transacción/solicitud. Juntas, estas dos características son muy útiles para encontrar la causa principal de los
problemas de confiabilidad y los cuellos de botella de rendimiento por solicitud.
¿Cómo se habilita el seguimiento distribuido para las aplicaciones de funciones de Java?
Vaya a la hoja de información general de la aplicación de funciones, vaya a Configuraciones. En Configuración de
aplicación, haga clic en "+ Nueva configuración de la aplicación". Agregue las siguientes dos configuraciones de la
aplicación con los valores siguientes y haga clic en Guardar en la parte superior izquierda. ¡Listo!
XDT_MicrosoftApplicationInsights_Java -> 1
ApplicationInsightsAgent_EXTENSION_VERSION -> ~2
Pasos siguientes
Lea más instrucciones e información sobre la supervisión de Azure Functions.
Obtenga información general sobre el seguimiento distribuido.
Vea qué mapa de aplicación puede servir a su empresa.
Lea sobre las solicitudes y dependencias para aplicaciones de Java.
Obtenga más información sobre Azure Monitor y Application Insights.
Supervisión de aplicaciones sin instrumentación para
Kubernetes: Application Insights de Azure Monitor
IMPORTANT
Actualmente, puede habilitar la supervisión de las aplicaciones Java que se ejecutan en Kubernetes sin instrumentar el
código: use el agente independiente de Java. Aunque la solución para habilitar sin problemas la supervisión de aplicaciones
está en desarrollo para otros lenguajes, puede usar los SDK para supervisar las aplicaciones que se ejecutan en AKS: ASP.NET
Core, ASP.NET, Node.js, JavaScript y Python.
Supervisión de aplicaciones sin instrumentar el código

Actualmente, solo Java permite habilitar la supervisión de aplicaciones sin instrumentar el código. Para supervisar
aplicaciones en otros lenguajes, use los SDK.
Java
Una vez habilitado, el agente de Java recopilará automáticamente una gran cantidad de solicitudes, dependencias,
registros y métricas de las bibliotecas y los marcos de trabajo más usados.
Siga las instrucciones detalladas para supervisar las aplicaciones Java que se ejecutan en aplicaciones de
Kubernetes, así como otros entornos.
Otros idiomas
En el caso de aplicaciones en otros lenguajes, actualmente se recomienda usar los SDK:
ASP.NET Core
ASP.NET
Node.js
JavaScript
Python
Pasos siguientes
Más información sobre Azure Monitor y Application Insights.
Consulte una introducción al seguimiento distribuido y descubra lo que el Mapa de aplicación puede hacer por
su empresa.
Supervisión de aplicaciones sin código de Java
con Azure Monitor Application Insights: versión
preliminar pública
La supervisión de aplicaciones Java sin código destaca por su simplicidad. No hace falta que realice ningún
cambio en el código, ya que el agente de Java se puede habilitar mediante un par de cambios de
configuración.
El agente de Java funciona en cualquier entorno y le permite supervisar todas sus aplicaciones Java. En otras
palabras, tanto si ejecuta las aplicaciones Java en máquinas virtuales, en el entorno local, en AKS, en
Windows o en Linux (usted decide), el agente de Java 3.0 las supervisará.
Ya no es necesario que agregue el SDK de Java de Application Insights a la aplicación, ya que el agente 3.0
recopila solicitudes, dependencias y registros por su cuenta automáticamente.
Así mismo, puede enviar telemetría personalizada desde la aplicación. El agente 3.0 realizará un seguimiento
de esta y la correlacionará con la telemetría recopilada automáticamente.
Guía de inicio rápido

1. Descargue el agente.
Descargue applicationinsights-agent-3.0.0-PREVIEW.5.jar.
2. Apunte JVM al agente.
Agregue -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.5.jar a los argumentos de JVM de la
aplicación.
Los argumentos típicos de JVM son -Xmx512m y -XX:+UseG1GC . Por lo tanto, si sabe dónde debe agregarlos,
lo mismo se aplica para este.
Para obtener ayuda adicional con la configuración de los argumentos de JVM de la aplicación, consulte
Versión preliminar 3.0: sugerencias para actualizar los argumentos de JVM.
3. Apunte el agente al recurso de Application Insights.
Si aún no tiene ningún recurso de Application Insights, puede crear uno nuevo siguiendo los pasos descritos
en la guía de creación de recursos.
Apunte el agente hacia el recurso de Application Insights, ya sea estableciendo una variable de entorno:
APPLICATIONINSIGHTS_CONNECTION_STRING=InstrumentationKey=00000000-0000-0000-0000-000000000000
O creando un archivo de configuración denominado ApplicationInsights.json y colocándolo en el mismo

directorio que applicationinsights-agent-3.0.0-PREVIEW.5.jar , con el siguiente contenido:
{
"instrumentationSettings": {
"connectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
}
}
Puede encontrar la cadena de conexión en el recurso de Application Insights:
4. ¡Ya está!
Ahora, inicie la aplicación y vaya a su recurso de Application Insights en Azure Portal para ver los datos de
supervisión.
NOTE
Los datos de supervisión pueden tardar un par de minutos en aparecer en el portal.
En el archivo ApplicationInsights.json , también puede configurar lo siguiente:
Nombre del rol en la nube
Instancia de rol en la nube
Captura del registro de aplicaciones
Métricas JMX
Micrómetro
Latido
muestreo
Proxy HTTP
Diagnóstico automático
Consulte los detalles en Versión preliminar pública 3.0: opciones de configuración.
Solicitudes, dependencias, registros y métricas recopilados

automáticamente
Requests
Consumidores de JMS
Consumidores de Kafka
Netty/WebFlux
Servlets
Programación de Spring
Dependencias con propagación de seguimiento distribuido
Apache HttpClient y HttpAsyncClient
gRPC
java.net.HttpURLConnection
JMS
Kafka
Cliente Netty
OkHttp
Otras dependencias
Cassandra
JDBC
MongoDB (asincrónico y sincrónico)
Redis (Lettuce y Jedis)
Registros
java.util.logging
Log4j
SLF4J/Logback
Métricas
Micrometer (incluidas las métricas del actuador de Spring Boot)
Métricas JMX
Envío de telemetría personalizada desde su aplicación

Nuestro objetivo con la versión 3.0 y las posteriores es permitirle enviar telemetría personalizada mediante
API estándar.
Se admiten Micrometer, OpenTelemetry API y los marcos de registro conocidos. Application Insights Java 3.0
capturará automáticamente la telemetría y la correlacionará con la telemetría recopilada automáticamente.
Telemetría personalizada admitida
En la tabla siguiente se representan los tipos de telemetría personalizados admitidos actualmente que se
pueden habilitar para complementar el agente Java 3.0. En resumen, las métricas personalizadas se admiten
a través de Micrometer, las excepciones personalizadas y los seguimientos se pueden habilitar a través de las
plataformas de registro, y se admite cualquier tipo de telemetría personalizada a través del SDK de
Application Insights Java 2.x.
M IC RÓ M ET RO LO G4J, LO GB A C K , JUL SDK 2. X
Eventos personalizados Sí
Métricas Sí Sí
personalizadas
Dependencias Sí
Excepciones Sí Sí
M IC RÓ M ET RO LO G4J, LO GB A C K , JUL SDK 2. X
Vistas de página Sí
Solicitudes Sí
Traces Sí Sí
No tenemos previsto publicar ningún SDK con Application Insights 3.0 en este momento.
Application Insights Java 3.0 ya escucha la telemetría que se envía al SDK de Java de Application Insights 2.x.
Esta funcionalidad es una parte importante de la historia de actualización de los usuarios existentes de 2.x y
llena una brecha importante en la compatibilidad con la telemetría personalizada hasta que OpenTelemetry
API ofrezca disponibilidad general.
Envío de telemetría personalizada con el SDK de Java de Application

Insights 2.x
Agregue applicationinsights-core-2.6.0.jar a la aplicación (todas las versiones 2.x son compatibles con
Application Insights Java 3.0, pero merece la pena usar la más reciente si es posible):
<dependency>
<artifactId>applicationinsights-core</artifactId>
</dependency>
Cree un elemento TelemetryClient:
private static final TelemetryClient telemetryClient = new TelemetryClient();
Úselo para enviar telemetría personalizada.

Eventos
telemetryClient.trackEvent("WinGame");
Métricas
Puede enviar telemetría de métricas a través de Micrometer:
Counter counter = Metrics.counter("test_counter");

counter.increment();
También puede usar el SDK de Java de Application Insights 2.x:
telemetryClient.trackMetric("queueLength", 42.0);
Dependencias
boolean success = false;
long startTime = System.currentTimeMillis();
try {
success = dependency.call();
} finally {
long endTime = System.currentTimeMillis();
RemoteDependencyTelemetry telemetry = new RemoteDependencyTelemetry();
telemetry.setTimestamp(new Date(startTime));
telemetry.setDuration(new Duration(endTime - startTime));
telemetryClient.trackDependency(telemetry);
}
Registros
Puede enviar telemetría de registro personalizada a través de su marco de registro favorito.
telemetryClient.trackTrace(message, SeverityLevel.Warning, properties);
Excepciones
Puede enviar telemetría de excepción personalizada a través de su marco de registro favorito.
try {
...
} catch (Exception e) {
telemetryClient.trackException(e);
}
Actualización del SDK de Java de Application Insights 2.x

Si ya usa el SDK de Java de Application Insights 2.x en la aplicación, no es necesario que lo quite. El agente de
Java 3.0 lo detectará, y capturará y correlacionará cualquier telemetría personalizada que envíe a través del
SDK de Java 2.x, al mismo tiempo que suprimirá cualquier recopilación automática que realice el SDK de
Java 2.x para evitar la captura duplicada.
NOTE
Nota: Los elementos Telemetryinitializer y TelemetryProcessors del SDK de Java 2.x no se ejecutarán cuando se use el
agente 3.0.
Opciones de configuración: agente independiente de
Java para Application Insights de Azure Monitor
Cadena de conexión y nombre de rol

{
"connectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000",
"preview": {
"roleName": "my cloud role name"
}
}
}
La cadena de conexión es obligatoria y el nombre del rol es importante cada vez que se envían datos de diferentes
aplicaciones al mismo recurso de Application Insights.
Encontrará más detalles y opciones de configuración adicionales a continuación.
Ruta del archivo de configuración

De forma predeterminada, Application Insights Java 3.0 Preview espera que el archivo de configuración se
denomine ApplicationInsights.json y que se encuentre en el mismo directorio que el archivo
applicationinsights-agent-3.0.0-PREVIEW.5.jar .
Puede especificar la ruta de acceso a su propio archivo de configuración mediante

la variable de entorno APPLICATIONINSIGHTS_CONFIGURATION_FILE , o
la propiedad del sistema Java applicationinsights.configurationFile .
Si especifica una ruta de acceso relativa, se resolverá de forma relativa al directorio en el que se encuentra
applicationinsights-agent-3.0.0-PREVIEW.5.jar .
Cadena de conexión
Este es un paso necesario. Puede encontrar la cadena de conexión en el recurso de Application Insights:
También puede establecer la cadena de conexión mediante la variable de entorno

APPLICATIONINSIGHTS_CONNECTION_STRING .
Nombre del rol en la nube

Este se usa para etiquetar el componente en el mapa de aplicación.
Si quiere establecer el nombre del rol de nube, haga lo siguiente:
{
"preview": {
}
}
}
Si no se establece el nombre del rol en la nube, se usará el nombre del recurso de Application Insights para
etiquetar el componente en el mapa de aplicación.
También puede establecer el nombre de rol en la nube mediante la variable de entorno
APPLICATIONINSIGHTS_ROLE_NAME .
Instancia de rol en la nube

La instancia de rol de la nube tiene como valor predeterminado el nombre del equipo.
Si quiere establecer la instancia de rol de nube en un valor diferente en lugar del nombre del equipo, use lo
siguiente:
{
"preview": {
"roleInstance": "my cloud role instance"
}
}
}
También puede establecer la instancia de rol en la nube mediante la variable de entorno

APPLICATIONINSIGHTS_ROLE_INSTANCE .
Captura del registro de aplicaciones

Application Insights Java 3.0 Preview captura automáticamente el registro de aplicaciones mediante Log4j,
Logback y java.util.logging.
De forma predeterminada, capturará todos los registros realizados en el nivel WARN o superior.
Si quiere cambiar este umbral, use lo siguiente:
{
"preview": {
"instrumentation": {
"logging": {
"threshold": "ERROR"
}
}
}
}
}
Los siguientes son los valores threshold válidos que puede especificar en el archivo ApplicationInsights.json y
cómo se corresponden con los niveles de registro en diferentes marcos de registro:
THRESHOLD LO G4J LO GB A C K JUL
Apagado Apagado Apagado Apagado
FATAL FATAL ERROR SEVERE
ERROR/SEVERE ERROR ERROR SEVERE
WARN/WARNING WARN WARN WARNING
INFO INFO INFO INFO
CONFIG DEBUG DEBUG CONFIG
DEBUG/FINE DEBUG DEBUG FINE
FINER DEBUG DEBUG FINER
TRACE/FINEST TRACE TRACE FINEST
ALL ALL ALL ALL
Métricas JMX
Si tiene alguna métrica de JMX que le interese capturar, use lo siguiente:
{
"preview": {
"jmxMetrics": [
{
"objectName": "java.lang:type=ClassLoading",
"attribute": "LoadedClassCount",
"display": "Loaded Class Count"
},
{
"objectName": "java.lang:type=MemoryPool,name=Code Cache",
"attribute": "Usage.used",
"display": "Code Cache Used"
}
]
}
}
}
Micrometer (incluidas las métricas del actuador de Spring Boot)

Si la aplicación usa Micrometer, Application Insights 3.0 (a partir de Preview.2) captura ahora las métricas enviadas
al registro global de Micrometer.
Si la aplicación usa el actuador de Spring Boot, Application Insights 3.0 (a partir de Preview.4) captura ahora las
métricas configuradas por este (que usa Micrometer, pero no usa el registro global de Micrometer).
Si quiere deshabilitar estas características, haga lo siguiente:
{
"preview": {
"instrumentation": {
"micrometer": {
"enabled": false
}
}
}
}
}
Latido
De forma predeterminada, Application Insights Java 3.0 Preview envía una métrica de latido cada 15 minutos. Si
está usando la métrica de latido para desencadenar las alertas, puede aumentar la frecuencia de este latido:
{
"preview": {
"heartbeat": {
"intervalSeconds": 60
}
}
}
}
NOTE
No puede reducir la frecuencia del latido, ya que los datos del mismo también se usan para supervisar el uso de Application
Insights.
muestreo
El muestreo resulta útil si necesita reducir costos. Este se realiza como una función en el id. de operación (también
conocido como id. de seguimiento), por lo que el mismo id. de operación siempre dará como resultado la misma
decisión de muestreo. Esto garantiza que no se realizará el muestreo de algunas partes de una transacción
distribuida mientras se muestrean otras.
Por ejemplo, si establece el muestreo en 10 %, solo verá el 10 % de sus transacciones, pero cada una de ese 10 %
tendrá los detalles completos de las transacciones de un extremo a otro.
El siguiente es un ejemplo de cómo establecer el muestreo en 10 % de todas las transacciones . Asegúrese de
establecer la velocidad de muestreo correcta para su caso de uso:
{
"preview": {
"sampling": {
"fixedRate": {
"percentage": 10
}
}
}
}
}
Proxy HTTP
Si su aplicación está protegida por un firewall y no puede conectarse directamente a Application Insights (consulte
Direcciones IP que emplea Application Insights), puede configurar Application Insights Java 3.0 Preview para que
use un proxy HTTP:
{
"preview": {
"httpProxy": {
"host": "myproxy",
"port": 8080
}
}
}
}
Diagnóstico automático
"Diagnóstico automático" hace referencia al registro interno de Application Insights Java 3.0 Preview.
Puede ser útil para detectar y diagnosticar problemas con Application Insights.
De forma predeterminada, se registra en la consola con el nivel warn , que corresponde a la siguiente
configuración:
{
"preview": {
"selfDiagnostics": {
"destination": "console",
"level": "WARN"
}
}
}
}
Los niveles válidos son OFF , ERROR , WARN , INFO , DEBUG y TRACE .
Si quiere realizar el registro en un archivo en lugar de en la consola:
{
"preview": {
"selfDiagnostics": {
"destination": "file",
"directory": "/var/log/applicationinsights",
"level": "WARN",
"maxSizeMB": 10
}
}
}
}
Cuando se usa el registro de archivos, una vez que el archivo alcanza el límite maxSizeMB , se realiza una
sustitución, de modo que se conserva solo el archivo de registro completado más recientemente, además del
archivo de registro actual.
Configuración de los argumentos de JVM del agente
independiente de Java para Application Insights de
Azure Monitor
Entornos de Azure
Configure App Services.
Spring Boot
Agregue el argumento de JVM -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar en alguna parte
antes de -jar , por ejemplo:
java -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar -jar <myapp.jar>
Spring Boot mediante el punto de entrada de Docker

Si usa el formato exec, agregue el parámetro "-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar" a
la lista de parámetros en algún lugar antes del parámetro "-jar" , por ejemplo:
ENTRYPOINT ["java", "-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar", "-jar", "<myapp.jar>"]
Si usa el formato shell, agregue el argumento -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar de

JVM en algún lugar antes de -jar , por ejemplo:
ENTRYPOINT java -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar -jar <myapp.jar>
Tomcat 8 (Linux)
Tomcat instalado mediante apt-get o yum
Si instaló Tomcat mediante apt-get o yum , debe tener un archivo /etc/tomcat8/tomcat8.conf . Agregue esta línea
al final del archivo:
JAVA_OPTS="$JAVA_OPTS -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar"
Tomcat instalado mediante descarga y descompresión

Si instaló Tomcat mediante la descarga y descompresión de https://tomcat.apache.org, debe tener un archivo
denominado <tomcat>/bin/catalina.sh . Cree un nuevo archivo en el mismo directorio denominado
<tomcat>/bin/setenv.sh con el siguiente contenido:
CATALINA_OPTS="$CATALINA_OPTS -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar"
Si el archivo ya existe, modifíquelo y agregue
<tomcat>/bin/setenv.sh
-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar a CATALINA_OPTS .
Tomcat 8 (Windows)
Ejecución de Tomcat desde la línea de comandos
Busque el archivo <tomcat>/bin/catalina.bat . Cree un nuevo archivo en el mismo directorio denominado
<tomcat>/bin/setenv.bat con el siguiente contenido:
set CATALINA_OPTS=%CATALINA_OPTS% -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar
Las comillas no son necesarias, pero si quiere incluirlas, la ubicación adecuada es la siguiente:
set "CATALINA_OPTS=%CATALINA_OPTS% -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar"
Si el archivo ya existe, simplemente modifíquelo y agregue

<tomcat>/bin/setenv.bat
-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar a CATALINA_OPTS .
Ejecución de Tomcat como servicio de Windows

Busque el archivo <tomcat>/bin/tomcat8w.exe . Ejecute el archivo ejecutable y agregue
-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar a la sección Java Options de la pestaña Java .
JBoss EAP 7
Servidor independiente
Agregue -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar a la variable de entorno JAVA_OPTS
existente en el archivo JBOSS_HOME/bin/standalone.conf (Linux) o JBOSS_HOME/bin/standalone.conf.bat (Windows):
JAVA_OPTS="<b>-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar</b> -Xms1303m -Xmx1303m ..."

...
Servidor del dominio

Agregue -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar al elemento jvm-options existente en el
archivo JBOSS_HOME/domain/configuration/host.xml :
...
<jvms>
<jvm name="default">
<heap size="64m" max-size="256m"/>
<jvm-options>
<option value="-server"/>

<option value="-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar"/>
<option value="-XX:MetaspaceSize=96m"/>
<option value="-XX:MaxMetaspaceSize=256m"/>
</jvm-options>
</jvm>
</jvms>
...
Si ejecuta varios servidores administrados en un solo host, deberá agregar applicationinsights.agent.id al

elemento system-properties de cada server :
...
<servers>
<server name="server-one" group="main-server-group">

<system-properties>
<property name="applicationinsights.agent.id" value="..."/>
</system-properties>
</server>
<server name="server-two" group="main-server-group">
<socket-bindings port-offset="150"/>

<system-properties>
<property name="applicationinsights.agent.id" value="..."/>
</system-properties>
</server>
</servers>
...
El valor de applicationinsights.agent.id especificado debe ser único. Se usa para crear un subdirectorio en el
directorio applicationinsights, ya que cada proceso de JVM necesita su propia configuración de applicationinsights
y su propio archivo de registro applicationinsights local. Además, si se informa al recopilador central, el archivo
applicationinsights.properties se comparte entre varios servidores administrados, por lo que el valor
applicationinsights.agent.id especificado es necesario para invalidar la configuración agent.id en dicho archivo
compartido. applicationinsights.agent.rollup.id se puede especificar de manera similar en el elemento
system-properties del servidor si necesita invalidar la configuración agent.rollup.id de cada servidor
administrado.
Jetty 9
Agregue estas líneas al archivo start.ini .
--exec
-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar
Payara 5
Agregue -javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar al elemento jvm-options existente en el
archivo glassfish/domains/domain1/config/domain.xml :
...
<java-config ...>

<jvm-options>
-javaagent:path/to/applicationinsights-agent-3.0.0-PREVIEW.jar>
</jvm-options>
...
</java-config>
...
WebSphere 8
Abra la consola de administración, vaya a Ser vidores > Ser vidores de aplicaciones WebSphere >
Ser vidores de aplicaciones , elija los servidores de aplicaciones adecuados y haga clic en:
Java and Process Management > Process definition > Java Virtual Machine
En "Argumentos de la JVM genéricos", agregue lo siguiente:
Después, guarde y reinicie el servidor de aplicaciones.
OpenLiberty 18
Cree un nuevo archivo jvm.optionsen el directorio del servidor (por ejemplo,
<openliberty>/usr/servers/defaultServer ) y agregue la siguiente línea:
Implementación de Azure Application Insights
Agent para servidores locales
IMPORTANT
Esta guía se recomienda para implementaciones de Application Insights Agent en la nube locales y en el entorno local que
no sean de Azure. Este es el enfoque recomendado para las implementaciones de máquinas virtuales y de conjuntos de
escalado de máquinas virtuales de Azure.
Application Insights Agent (anteriormente conocido como Monitor de estado V2) es un módulo de PowerShell
publicado en la Galería de PowerShell. Reemplaza al Monitor de estado. Se envía telemetría a Azure Portal,
donde puede supervisar la aplicación.
NOTE
El módulo solo admite actualmente la instrumentación sin código de aplicaciones web .NET hospedadas con IIS. Use un
SDK para instrumentar las aplicaciones ASP.NET Core, Java y Node.js.
Galería de PowerShell
Application Insights Agent se encuentra aquí:
https://www.powershellgallery.com/packages/Az.ApplicationMonitor.
C U R R E NT V E R S I O N V1.1.0
Instructions
Consulte las instrucciones de introducción para empezar con ejemplos concisos de código.
Consulte las instrucciones detalladas para profundizar.
Referencia de la API de PowerShell

Disable-ApplicationInsightsMonitoring
Disable-InstrumentationEngine
Enable-ApplicationInsightsMonitoring
Enable-InstrumentationEngine
Get-ApplicationInsightsMonitoringConfig
Get-ApplicationInsightsMonitoringStatus
Set-ApplicationInsightsMonitoringConfig
Start-ApplicationInsightsMonitoringTrace
Problemas conocidos
¿Application Insights Agent admite instalaciones de proxy?
Sí. Hay varias maneras de descargar Application Insights Agent. Si el equipo tiene acceso a internet, puede
incorporarlo en la Galería de PowerShell mediante los parámetros -Proxy . Puede descargar
manualmente el módulo e instalarlo en el equipo o usarlo directamente. Cada una de estas opciones se
describe en las instrucciones detalladas.
¿Admite el Monitor de estado v2 aplicaciones ASP.NET Core?
No. Para instrucciones sobre cómo habilitar la supervisión de aplicaciones ASP.NET Core, consulte
Application Insights para aplicaciones ASP.NET Core. No es necesario instalar el Monitor de estado para
una aplicación ASP.NET Core. Esto es así incluso si la aplicación ASP.NET Core se hospeda en IIS.
¿Cómo se puede comprobar que la habilitación se realizó correctamente?
Se puede usar el cmdlet Get-ApplicationInsightsMonitoringStatus para comprobar que la
habilitación se ha realizado correctamente.
Se recomienda usar Live Metrics para determinar rápidamente si la aplicación envía telemetría.
También puede usar Log Analytics para enumerar todos los roles en la nube que están enviando
actualmente telemetría:
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
Pasos siguientes
Vea la telemetría:
Explore las métricas para supervisar el rendimiento y el uso.
Busque en los eventos y los registros para diagnosticar problemas.
Use Analytics para consultas más avanzadas.
Cree paneles.
Agregue más telemetría:
Cree pruebas web para asegurarse de que el sitio permanece activo.
Agregue telemetría de cliente web para ver las excepciones de código de la página web y para habilitar las
llamadas de seguimiento.
Agregue el SDK de Application Insights al código para que pueda insertar llamadas de seguimiento y registro.
Introducción a Azure Application Insights Agent para
servidores locales
Este artículo contiene los comandos de inicio rápido que se espera que funcionen para la mayoría de los entornos.
Las instrucciones dependen de la Galería de PowerShell para distribuir las actualizaciones. Estos comandos
admiten el parámetro de PowerShell -Proxy .
Para obtener una explicación de estos comandos, las instrucciones de personalización e información sobre cómo
solucionar problemas, consulte las instrucciones detalladas.
Descarga e instalación a través de la Galería de PowerShell

Requisitos previos de instalación
Ejecute PowerShell como administrador.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process -Force

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
Install-Module -Name PowerShellGet -Force
Cierre PowerShell.
Instalación de Application Insights Agent
Ejecute PowerShell como administrador.

Install-Module -Name Az.ApplicationMonitor -AllowPrerelease -AcceptLicense

Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Descarga e instalación manual (opción sin conexión)

Descara del módulo
Descargue manualmente la versión más reciente del módulo desde la Galería de PowerShell.
Descompresión e instalación de Application Insights Agent
$pathToNupkg = "C:\Users\t\Desktop\Az.ApplicationMonitor.0.3.0-alpha.nupkg"
$pathToZip = ([io.path]::ChangeExtension($pathToNupkg, "zip"))
$pathToNupkg | rename-item -newname $pathToZip
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\Az.ApplicationMonitor"
Expand-Archive -LiteralPath $pathToZip -DestinationPath $pathInstalledModule
Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Pasos siguientes
Vea la telemetría:
Cree paneles.
Haga mucho más con Application Insights Agent:
Revise las instrucciones detalladas para obtener una explicación de los comandos que se encuentran aquí.
Use nuestra guía para solucionar problemas de Application Insights Agent.
Application Insights Agent (antes Monitor de
estado v2): Instrucciones detalladas
En este artículo se describe cómo incorporarse a la Galería de PowerShell y descargar el módulo

ApplicationMonitor. Se incluyen los parámetros más comunes que necesitará para empezar. También
proporcionamos instrucciones de descarga manual en caso de que no tenga acceso a Internet.
Obtención de una clave de instrumentación

Para empezar, necesita una clave de instrumentación. Para obtener más información, vea Creación de recursos en
Ejecución de PowerShell como administrador con una directiva de

ejecución con privilegios elevados
Ejecutar como administrador
PowerShell necesita permisos de nivel de administrador para hacer cambios en el equipo.
Directiva de ejecución
Descripción: De forma predeterminada, la ejecución de scripts de PowerShell está deshabilitada. Le
recomendamos que permita los scripts de RemoteSigned solo para el ámbito actual.
Referencia: Información sobre las directivas de ejecución y Set-ExecutionPolicy.
Comando: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process .
Parámetro opcional:
-Force . Se omite el mensaje de confirmación.
Ejemplos de errores
Install-Module : The 'Install-Module' command was found in the module 'PowerShellGet', but the module could
not be
loaded. For more information, run 'Import-Module PowerShellGet'.
Import-Module : File C:\Program

Files\WindowsPowerShell\Modules\PackageManagement\1.3.1\PackageManagement.psm1 cannot
be loaded because running scripts is disabled on this system. For more information, see
about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
Requisitos previos para PowerShell

Ejecute el comando $PSVersionTable para auditar la instancia de PowerShell. Este comando genera el siguiente
resultado:
Name Value
---- -----
PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Estas instrucciones se han escrito y probado en un equipo que ejecuta Windows 10 y las versiones mencionadas
anteriormente.
Requisitos previos de la Galería de PowerShell

Con estos pasos, se preparará el servidor para descargar los módulos de la Galería de PowerShell.
NOTE
La Galería de PowerShell es compatible con Windows 10, Windows Server 2016 y PowerShell 6. Para obtener información
sobre las versiones anteriores, consulte Instalación de PowerShellGet.
1. Ejecute PowerShell como administrador con una directiva de ejecución con privilegios elevados.
2. Instale el proveedor de paquetes NuGet.
Descripción: Necesita este proveedor para interactuar con repositorios basados en NuGet, como la
Galería de PowerShell.
Referencia: Install-PackageProvider.
Comando: Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 .
Parámetros opcionales:
-Proxy . Especifica un servidor proxy para la solicitud.
-Force . Se omite el mensaje de confirmación.
Recibirá este mensaje si NuGet no se ha configurado:
NuGet provider is required to continue

PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based
repositories.
The NuGet provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\t\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet
provider by running
'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to
install and import
the NuGet provider now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):
3. Configure la Galería de PowerShell como un repositorio de confianza.

Descripción: De forma predeterminada, la Galería de PowerShell no es un repositorio de confianza.
Referencia: Set-PSRepository.
Comando: Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted .
Parámetro opcional:
Recibirá este mensaje si la Galería de PowerShell no es de confianza:
Untrusted repository
You are installing the modules from an untrusted repository.
If you trust this repository, change its InstallationPolicy value
by running the Set-PSRepository cmdlet. Are you sure you want to
install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):
Puede confirmar este cambio y auditar todos los PSRepositories si ejecuta el comando Get-PSRepository .
4. Instale la versión más reciente de PowerShellGet.
Descripción: Este módulo contiene las herramientas que se usan para obtener otros módulos de la
Galería de PowerShell. La versión 1.0.0.1 se distribuye con Windows 10 y Windows Server. Se requiere
la versión 1.6.0 o posterior. Para determinar qué versión está instalada, ejecute el comando
Get-Command -Module PowerShellGet .
Referencia: Instalación de PowerShellGet.
Comando: Install-Module -Name PowerShellGet .
-Force . Omite la advertencia de que ya está instalado e instala la versión más reciente.
Recibirá este error si no usa la versión más reciente de PowerShellGet:
Install-Module : A parameter cannot be found that matches parameter name 'AllowPrerelease'.

At line:1 char:20
Install-Module abc -AllowPrerelease
~~~~~~~~~~~~~~~~
CategoryInfo : InvalidArgument: (:) [Install-Module], ParameterBindingException
FullyQualifiedErrorId : NamedParameterNotFound,Install-Module
5. Reinicie PowerShell. No puede cargar la nueva versión en la sesión actual. Las nuevas sesiones de
PowerShell cargarán la versión más reciente de PowerShellGet.
Descarga e instalación del módulo a través de la Galería de PowerShell

Con estos pasos, descargará el módulo Az.ApplicationMonitor desde la Galería de PowerShell.
1. Asegúrese de que se cumplen todos los requisitos previos de la Galería de PowerShell.
3. Instale el módulo Az.ApplicationMonitor.
Referencia: Install-Module.
Comando: Install-Module -Name Az.ApplicationMonitor .
-AllowPrerelease . Permite la instalación de las versiones alfa y beta.
-AcceptLicense . Omite el mensaje para aceptar la licencia.
-Force . Omite la advertencia de repositorio de confianza.
Descarga e instalación manual del módulo (opción sin conexión)

Si por algún motivo no puede conectarse al módulo de PowerShell, puede descargar e instalar el módulo
Az.ApplicationMonitor de forma manual.
Descarga manual del archivo nupkg más reciente
1. Ir a https://www.powershellgallery.com/packages/Az.ApplicationMonitor.
2. Seleccione la versión más reciente del archivo en la tabla Historial de versiones .
3. En Opciones de instalación , seleccione Descarga manual .
Opción 1: Instalación en un directorio de módulos de PowerShell
Instale el módulo de PowerShell que ha descargado manualmente en un directorio de PowerShell para que las
sesiones de PowerShell lo puedan detectar. Para obtener más información, consulte Instalación de un módulo de
PowerShell.
Descompresión de nupkg como un archivo ZIP mediante Expand-Archive (v1.0.1.0)
Descripción: La versión base de Microsoft.PowerShell.Archive (v1.0.1.0) no puede descomprimir los
archivos nupkg. Cambie el nombre del archivo con la extensión .zip.
Referencia: Expand-Archive.
Comando:
$pathToNupkg = "C:\az.applicationmonitor.0.3.0-alpha.nupkg"
$pathToZip = ([io.path]::ChangeExtension($pathToNupkg, "zip"))
$pathToNupkg | rename-item -newname $pathToZip
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\az.applicationmonitor"
Expand-Archive -LiteralPath $pathToZip -DestinationPath $pathInstalledModule
Descompresión de nupkg mediante Expand-Archive (v1.1.0.0)

Descripción: Use una versión actual de Expand-Archive para descomprimir los archivos nupkg sin cambiar
la extensión.
Referencia: Expand-Archive y Microsoft.PowerShell.Archive.
Comando:
$pathToNupkg = "C:\az.applicationmonitor.0.2.1-alpha.nupkg"
$pathInstalledModule = "$Env:ProgramFiles\WindowsPowerShell\Modules\az.applicationmonitor"
Expand-Archive -LiteralPath $pathToNupkg -DestinationPath $pathInstalledModule
Opción 2: Descompresión e importación manual de nupkg

Instale el módulo de PowerShell que ha descargado manualmente en un directorio de PowerShell para que las
sesiones de PowerShell lo puedan detectar. Para obtener más información, consulte Instalación de un módulo de
PowerShell.
Si va a instalar el módulo en cualquier otro directorio, importe manualmente el módulo mediante Import-
Module.
IMPORTANT
Los archivos DLL se instalarán mediante las rutas de acceso relativas. Almacene el contenido del paquete en el directorio
del entorno de ejecución previsto y confirme que los permisos de acceso permiten la lectura pero no la escritura.
1. Cambie la extensión por ".zip" y extraiga el contenido del paquete en el directorio de instalación que quiera.
2. Busque la ruta de acceso del archivo Az.ApplicationMonitor.psd1.
4. Cargue el módulo con el comando Import-Module Az.ApplicationMonitor.psd1 .
Enrutamiento del tráfico a través de un proxy

Al supervisar un equipo en su intranet privada, deberá enrutar el tráfico HTTP a través de un proxy.
Los comandos de PowerShell para descargar e instalar Az.ApplicationMonitor desde la Galería de PowerShell
admiten un parámetro -Proxy . Consulte las instrucciones anteriores cuando escriba los scripts de instalación.
El SDK de Application Insights tendrá que enviar la telemetría de la aplicación a Microsoft. Le recomendamos que
configure las opciones de configuración de proxy de la aplicación en el archivo web.config. Para obtener más
información, consulte Preguntas más frecuentes sobre Application Insights: Paso a través de proxy.
Use el comando Enable-ApplicationInsightsMonitoring para habilitar la supervisión.
Consulte la referencia de la API para obtener una descripción detallada de cómo usar este cmdlet.
Pasos siguientes
Vea la telemetría:
Cree paneles.
Solución de problemas de Application Insights Agent
(antes Monitor de estado v2)
Cuando se habilita la supervisión, podría experimentar problemas que impidan la recopilación de datos. En este
artículo se enumeran todos los problemas conocidos y se proporcionan ejemplos de solución de problemas. Si
encuentra un problema que no aparece aquí, puede ponerse en contacto con nosotros en GitHub.
Problemas conocidos
Archivos DLL en conflicto en el directorio bin de una aplicación
Si cualquiera de estas DLL están presente en el directorio bin, la supervisión podría dar error:
Microsoft.ApplicationInsights.dll
Microsoft.AspNet.TelemetryCorrelation.dll
System.Diagnostics.DiagnosticSource.dll
Algunos de estos archivos DLL se incluyen en las plantillas de aplicación predeterminadas de Visual Studio,
incluso si la aplicación no las usa. Puede usar las herramientas de solución de problemas para ver el
comportamiento de los síntomas:
PerfView:
ThreadID="7,500"
ProcessorNumber="0"
msg="Found 'System.Diagnostics.DiagnosticSource, Version=4.0.2.1, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' assembly, skipping attaching redfield binaries"
ExtVer="2.8.13.5972"
SubscriptionId=""
AppName=""
FormattedMessage="Found 'System.Diagnostics.DiagnosticSource, Version=4.0.2.1, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51' assembly, skipping attaching redfield binaries"
IISReset y carga de aplicación (sin telemetría). Investigue con Sysinternals (Handle.exe y ListDLLs.exe):
.\handle64.exe -p w3wp | findstr /I "InstrumentationEngine AI. ApplicationInsights"

E54: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Re
dfieldIISModule.dll
.\Listdlls64.exe w3wp | findstr /I "InstrumentationEngine AI ApplicationInsights"

0x0000000009be0000 0x127000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\MicrosoftInstrumentati
onEngine_x64.dll
0x0000000009b90000 0x4f000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.ApplicationI
nsights.ExtensionsHost_x64.dll
0x0000000004d20000 0xb2000 C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.ApplicationI
nsights.Extensions.Base_x64.dll
Conflicto con la configuración compartida de IIS

Si tiene un clúster de servidores web, puede que esté usando una configuración compartida. HttpModule no
pueden insertarse en esta configuración compartida. Ejecute el comando Enable en cada servidor web para
instalar el archivo DLL en la GAC de cada servidor.
Después de ejecutar el comando Enable, siga estos pasos:
1. Vaya al directorio de configuración compartida y busque el archivo applicationHost.config.
2. Agregue esta línea a la sección de módulos de la configuración:
<modules>

<add name="ManagedHttpModuleHelper"
type="Microsoft.AppInsights.IIS.ManagedHttpModuleHelper.ManagedHttpModuleHelper,
Microsoft.AppInsights.IIS.ManagedHttpModuleHelper, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler,runtimeVersionv4.0" />
</modules>
Aplicaciones anidadas en IIS

En la versión 1.0 so se instrumentan aplicaciones anidadas en IIS. Aquí puede ver el seguimiento de este
problema.
La configuración avanzada del SDK no está disponible.
La configuración del SDK no se muestra al usuario final en la versión 1.0. Aquí puede ver el seguimiento de este
problema.
Solución de problemas de PowerShell
Determine qué módulos están disponibles
Puede usar el comando Get-Module -ListAvailable para determinar qué módulos se instalan.
Importe un módulo en la sesión actual
Si un módulo no se ha cargado en una sesión de PowerShell, puede cargarlo manualmente mediante el comando
Import-Module <path to psd1> .
Solución de problemas del módulo Application Insights Agent

Enumeración de los comandos disponibles en el módulo Application Insights Agent
Ejecute el comando Get-Command -Module Az.ApplicationMonitor para obtener los comandos disponibles:
CommandType Name Version Source

----------- ---- ------- ------
Cmdlet Disable-ApplicationInsightsMonitoring 0.4.0 Az.ApplicationMonitor
Cmdlet Disable-InstrumentationEngine 0.4.0 Az.ApplicationMonitor
Cmdlet Enable-ApplicationInsightsMonitoring 0.4.0 Az.ApplicationMonitor
Cmdlet Enable-InstrumentationEngine 0.4.0 Az.ApplicationMonitor
Cmdlet Get-ApplicationInsightsMonitoringConfig 0.4.0 Az.ApplicationMonitor
Cmdlet Get-ApplicationInsightsMonitoringStatus 0.4.0 Az.ApplicationMonitor
Cmdlet Set-ApplicationInsightsMonitoringConfig 0.4.0 Az.ApplicationMonitor
Cmdlet Start-ApplicationInsightsMonitoringTrace 0.4.0 Az.ApplicationMonitor
Determinación de la versión actual del módulo Application Insights Agent

Ejecute el comando Get-ApplicationInsightsMonitoringStatus -PowerShellModule para mostrar la siguiente
información sobre el módulo:
Versión del módulo de PowerShell
Versión del SDK de Application Insights
Rutas de acceso de los archivos del módulo de PowerShell
Revise la referencia de la API para obtener una descripción detallada de cómo usar este cmdlet.
Solución de problemas de los procesos en ejecución
Puede inspeccionar los procesos en el equipo instrumentado para determinar si todos los archivos DLL se cargan.
Si funciona la supervisión, deben cargarse al menos 12 DLL.
Use el comando Get-ApplicationInsightsMonitoringStatus -InspectProcess para comprobar las DLL.
Revise la referencia de la API para obtener una descripción detallada de cómo usar este cmdlet.
Recopilación de los registros ETW con PerfView
Configurar
1. Descargue PerfView.exe y PerfView64.exe desde GitHub.
2. Inicie PerfView64.exe.
3. Expanda Opciones avanzadas .
4. Desactive estas casillas de verificación:
Zip
Combinar
.NET Symbol Collection (Colección de símbolos de .NET)
5. Establezca estos proveedores adicionales :
61f6ca3b-4b5f-5602-fa60-759a2a2d1fbd,323adc25-e39b-5c87-8658-2c1af1a92dc5,925fa42b-9ef6-5fa7-10b8-
56449d7a2040,f7d60e07-e910-5aca-bdd2-9de45b46c560,7c739bb9-7861-412e-ba50-bf30d95eae36,61f6ca3b-4b5f-5602-
fa60-759a2a2d1fbd,323adc25-e39b-5c87-8658-2c1af1a92dc5,252e28f4-43f9-5771-197a-e8c7e750a984
Recopilación de registros
1. En una consola de comandos con privilegios de administrador, ejecute el comando iisreset /stop para
desactivar IIS y todas las aplicaciones web.
2. En PerfView, seleccione Iniciar colección .
3. En una consola de comandos con privilegios de administrador, ejecute el comando iisreset /start para
iniciar IIS.
4. Intente ir a la aplicación.
5. Cuando la aplicación se cargue, vuelva a PerfView y seleccione Detener colección .
Pasos siguientes
Revise la referencia de API para obtener información acerca de los parámetros que podría haber pasado por
alto.
Si encuentra un problema que no aparece aquí, puede ponerse en contacto con nosotros en GitHub.
Referencia de la API del agente de Application
Insights de Azure Monitor
Este artículo describe un cmdlet que forma parte del módulo Az.ApplicationMonitor de PowerShell.
NOTE
Para empezar, necesita una clave de instrumentación. Para más información, consulte Crear un recurso.
Este cmdlet requiere que revise y acepte la licencia, y la declaración de privacidad.
IMPORTANT
Este cmdlet requiere una sesión de PowerShell con permisos de administrador y una directiva de ejecución elevada. Para
más información, consulte Ejecute PowerShell como administrador con una directiva de ejecución con privilegios elevados.
Este cmdlet requiere que revise y acepte la licencia, y la declaración de privacidad.
El motor de instrumentación produce más sobrecarga y está desactivado de forma predeterminada.
Enable-InstrumentationEngine
Habilita el motor de instrumentación mediante la definición de algunas claves del Registro. Reinicie IIS para
aplicar los cambios.
El motor de instrumentación puede complementar los datos recopilados por los SDK de .NET. Recopila los
eventos y mensajes que describen la ejecución de un proceso administrado. Estos eventos y mensajes incluyen
códigos de resultado de la dependencia, verbos HTTP y texto de comando SQL.
Habilite el motor de instrumentación si:
Ya ha habilitado la supervisión con el cmdlet Enable pero no ha habilitado el motor de instrumentación.
Ha instrumentado la aplicación manualmente con los SDK de .NET y desea recopilar datos de telemetría
adicionales.
Ejemplos
PS C:\> Enable-InstrumentationEngine
Parámetros
-AcceptLicense
Opcional. Use este modificador para aceptar la licencia y la declaración de privacidad en las instalaciones sin
periféricos.
-Verbose
Parámetro común. Use este modificador para generar registros detallados.
Output
Sa l i d a d e e j e m p l o a l h a b i l i t a r c o r r e c t a m e n t e e l m o t o r d e i n st r u m e n t a c i ó n
Configuring IIS Environment for instrumentation engine...
Configuring registry for instrumentation engine...
Enable-ApplicationInsightsMonitoring.
Permite adjuntar sin código la supervisión de aplicaciones IIS en un equipo de destino.
Este cmdlet modificará el archivo IIS applicationHost.config y establecerá algunas claves del Registro. También
creará un archivo applicationinsights.ikey.config, que define la clave de instrumentación usada por cada
aplicación. IIS cargará RedfieldModule durante el inicio, lo que insertará los SDK de Application Insights en
aplicaciones como las de inicio. Reinicie IIS para que los cambios surtan efecto.
Después de habilitar la supervisión, se recomienda que use Live Metrics para comprobar rápidamente si la
aplicación enviaba telemetría.
Ejemplos
Ejemplo con una única clave de instrumentación
En este ejemplo, a todas las aplicaciones en el equipo actual se les asigna una única clave de instrumentación.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Ejemplo con un mapa de claves de instrumentación

En este ejemplo:
MachineFilter busca la correspondencia con el equipo actual usando el comodín '.*' .
AppFilter='WebAppExclude' proporciona una clave de instrumentación null . No se puede instrumentar la
aplicación especificada.
AppFilter='WebAppOne' asigna una clave de instrumentación única a la aplicación especificada.
AppFilter='WebAppTwo' asigna una clave de instrumentación única a la aplicación especificada.
Por último, AppFilter también usa el comodín '.*' para buscar la correspondencia de todas las aplicaciones
web que no coincidan según las reglas anteriores y les asigna una clave de instrumentación predeterminada.
Se agregan espacios para mejorar la legibilidad.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKeyMap

@(@{MachineFilter='.*';AppFilter='WebAppExclude'},
@{MachineFilter='.*';AppFilter='WebAppOne';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxxxxxxx1'}},
@{MachineFilter='.*';AppFilter='WebAppTwo';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxxxxxxx2'}},
@{MachineFilter='.*';AppFilter='.*';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-xxxx-
xxxx-xxxxxdefault'}})
Parámetros
-InstrumentationKey
Requerido. Use este parámetro para proporcionar una única clave de instrumentación para que la usen todas las
aplicaciones en el equipo de destino.
-InstrumentationKeyMap
Requerido. Use este parámetro para proporcionar varias claves de instrumentación y una asignación de las
claves de instrumentación utilizadas por cada aplicación. Puede crear un solo script de instalación para varios
equipos si establece MachineFilter .
IMPORTANT
Las aplicaciones se harán coincidir con las reglas en el orden en que estas se proporcionan. Por tanto, debe especificar las
reglas más específicas en primer lugar y las más genéricas las últimas.
Sc h e m a
@(@{MachineFilter='.*';AppFilter='.*';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx'}})
MachineFilter es una expresión regular de C# requerida del nombre de la máquina virtual o del equipo.
".*" coincidirá con todos
"ComputerName" coincidirá solo son aquellos equipos que tengan el nombre exacto especificado.
AppFilter es una expresión regular de C# requerida del nombre del sitio de IIS. Para obtener una lista de
sitios en el servidor, ejecute el comando get-iissite.
"SiteName" coincidirá solo son el sitio de IIS que tenga el nombre exacto especificado.
InstrumentationKey se requiere para habilitar la supervisión de las aplicaciones que coincidan con los dos
filtros anteriores.
Deje este valor como null si desea definir reglas para excluir la supervisión.
-EnableInstrumentationEngine
Opcional. Utilice este modificador para habilitar el motor de instrumentación y recopilar eventos y mensajes
sobre lo que sucede durante la ejecución de un proceso administrado. Estos eventos y mensajes incluyen códigos
de resultado de la dependencia, verbos HTTP y texto de comando SQL.
El motor de instrumentación se sobrecarga y está desactivado de forma predeterminada.
-AcceptLicense
Opcional. Use este modificador para aceptar la licencia y la declaración de privacidad en las instalaciones sin
periféricos.
-IgnoreSharedConfig
Si tiene un clúster de servidores web, puede que esté usando una configuración compartida. HttpModule no
pueden insertarse en esta configuración compartida. Este script generará un error con un mensaje que indica que
se necesitan pasos de instalación adicionales. Use este modificador para ignorar esta comprobación y seguir
instalando requisitos previos. Para obtener más información, consulte Conflicto con la configuración compartida
de IIS.
-Verbose
Parámetro común. Utilice este modificador para mostrar registros detallados.
-WhatIf
Parámetro común. Utilice este modificador para probar y validar los parámetros de entrada sin habilitar
realmente la supervisión.
Output
Ejemplo de salida de una activación correcta
Initiating Disable Process
Applying transformation to 'C:\Windows\System32\inetsrv\config\applicationHost.config'
'C:\Windows\System32\inetsrv\config\applicationHost.config' backed up to
'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-52z'
in :1,237
No element in the source document matches
'/configuration/location[@path='']/system.webServer/modules/add[@name='ManagedHttpModuleHelper']'
Not executing RemoveAll (transform line 1, 546)
Transformation to 'C:\Windows\System32\inetsrv\config\applicationHost.config' was successfully applied.
Operation: 'disable'
GAC Module will not be removed, since this operation might cause IIS instabilities
Configuring IIS Environment for codeless attach...
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN[Environment]
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC[Environment]
Registry: skipping non-existent 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS[Environment]
Successfully disabled Application Insights Status Monitor
Installing GAC module 'C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\0.2.0\content\Runtime\Microsoft.AppInsights.IIS.Managed
HttpModuleHelper.dll'
Found GAC module Microsoft.AppInsights.IIS.ManagedHttpModuleHelper.ManagedHttpModuleHelper,
Microsoft.AppInsights.IIS.ManagedHttpModuleHelper, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-52z_1'
Operation: 'enable'
Updating app pool permissions...
Successfully enabled Application Insights Status Monitor
Disable-InstrumentationEngine
Deshabilita el motor de instrumentación mediante la eliminación de algunas claves del Registro. Reinicie IIS para
aplicar los cambios.
Ejemplos
PS C:\> Disable-InstrumentationEngine
Parámetros
-Verbose
Output
Sa l i d a d e e j e m p l o a l d e sh a b i l i t a r c o r r e c t a m e n t e e l m o t o r d e i n st r u m e n t a c i ó n

Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN[Environment]'
Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC[Environment]'
Registry: removing 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WAS[Environment]'
Disable-ApplicationInsightsMonitoring
Deshabilita la supervisión en el equipo de destino. Este cmdlet quitará los cambios realizados en el archivo
applicationHost.config de IIS y eliminará las claves del Registro.
Ejemplos
PS C:\> Disable-ApplicationInsightsMonitoring
Parámetros
-Verbose
Output
Sa l i d a d e e j e m p l o a l d e sh a b i l i t a r c o r r e c t a m e n t e l a su p e r v i si ó n
Initiating Disable Process

'C:\Windows\System32\inetsrv\config\applicationHost.config.backup-2019-03-26_08-59-00z'
in :1,237
No element in the source document matches
'/configuration/location[@path='']/system.webServer/modules/add[@name='ManagedHttpModuleHelper']'
Not executing RemoveAll (transform line 1, 546)
Operation: 'disable'
GAC Module will not be removed, since this operation might cause IIS instabilities
Successfully disabled Application Insights Status Monitor
Get-ApplicationInsightsMonitoringConfig
Obtiene el archivo de configuración e imprime los valores en la consola.
Ejemplos
PS C:\> Get-ApplicationInsightsMonitoringConfig
Parámetros
No se requiere ningún parámetro.
Output
Sa l i d a d e e j e m p l o a l l e e r e l a r c h i v o d e c o n fi g u r a c i ó n
RedfieldConfiguration:
Filters:
0)InstrumentationKey: AppFilter: WebAppExclude MachineFilter: .*
1)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx2 AppFilter: WebAppTwo MachineFilter: .*
2)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxdefault AppFilter: .* MachineFilter: .*
Get-ApplicationInsightsMonitoringStatus
Este cmdlet proporciona información de solución de problemas sobre el Monitor de estado. Use este cmdlet para
investigar el estado de supervisión, la versión del módulo de PowerShell y para inspeccionar el proceso en
ejecución. Este cmdlet notificará la información sobre la versión e información sobre los archivos de clave
necesarios para la supervisión.
Ejemplos
Ejemplo: Estado de la aplicación
Ejecute el comando Get-ApplicationInsightsMonitoringStatus para que aparezca el estado de supervisión de los
sitios web.
PS C:\Windows\system32> Get-ApplicationInsightsMonitoringStatus
IIS Websites:
SiteName : Default Web Site

ApplicationPoolName : DefaultAppPool
SiteId : 1
SiteState : Stopped
SiteName : DemoWebApp111
ApplicationPoolName : DemoWebApp111
SiteId : 2
SiteState : Started
ProcessId : not found
SiteId : 3
SiteState : Started
ProcessId : 2024
Instrumented : true
InstrumentationKey : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx123
SiteId : 4
SiteState : Started
ProcessId : 5184
AppAlreadyInstrumented : true
En este ejemplo,
Machine Identifier (Identificador de la máquina) es un identificador anónimo utilizado para identificar
de forma exclusiva el servidor. Si crea una solicitud de soporte técnico, necesitaremos este identificador para
buscar los registros del servidor.
Default Web Site (Sitio web predeterminado) está detenido en IIS
DemoWebApp111 se ha iniciado en IIS, pero no ha recibido ninguna solicitud. Este informe muestra que no
hay ningún proceso en ejecución (ProcessId: not found).
DemoWebApp222 se está ejecutando y se está supervisando (Instrumented: true). Según la configuración
del usuario, la clave de instrumentación xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx123 coincidió para este sitio.
DemoWebApp333 se ha instrumentado manualmente mediante el SDK de Application Insights. El agente
Monitor de estado ha detectado el SDK y no supervisará este sitio.
Ejemplo: Información sobre el módulo de PowerShell
Ejecute el comando Get-ApplicationInsightsMonitoringStatus -PowerShellModule para mostrar información sobre
el módulo actual:
PS C:\> Get-ApplicationInsightsMonitoringStatus -PowerShellModule
PowerShell Module version:

0.4.0-alpha
Application Insights SDK version:

2.9.0.3872
Executing PowerShell Module Assembly:

Microsoft.ApplicationInsights.Redfield.Configurator.PowerShell, Version=2.8.14.11432, Culture=neutral,
PublicKeyToken=31bf3856ad364e35
PowerShell Module Directory:

C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\0.2.2\content\PowerShell
Runtime Paths:
ParentDirectory (Exists: True)
C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content
ConfigurationPath (Exists: True)

C:\Program Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\applicationInsights.ikey.config
ManagedHttpModuleHelperPath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AppInsights.IIS.ManagedHttpMo
duleHelper.dll
RedfieldIISModulePath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.RedfieldI
ISModule.dll
InstrumentationEngine86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\MicrosoftInstrumentationEngin
e_x86.dll
InstrumentationEngine64Path (Exists: True)

C:\Program
e_x64.dll
InstrumentationEngineExtensionHost86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\Microsoft.ApplicationInsights
.ExtensionsHost_x86.dll
InstrumentationEngineExtensionHost64Path (Exists: True)

C:\Program
InstrumentationEngineExtensionConfig86Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation32\Microsoft.InstrumentationEngi
ne.Extensions.config
InstrumentationEngineExtensionConfig64Path (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Instrumentation64\Microsoft.InstrumentationEngi
ne.Extensions.config
ApplicationInsightsSdkPath (Exists: True)

C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.dll
Ejemplo: Estado en tiempo de ejecución
Puede inspeccionar el proceso en el equipo instrumentado para determinar si todos los archivos DLL se cargan.
Si funciona la supervisión, deben cargarse al menos 12 DLL.
Ejecute el comando Get-ApplicationInsightsMonitoringStatus -InspectProcess :
PS C:\> Get-ApplicationInsightsMonitoringStatus -InspectProcess
iisreset.exe /status
Status for IIS Admin Service ( IISADMIN ) : Running
Status for Windows Process Activation Service ( WAS ) : Running
Status for Net.Msmq Listener Adapter ( NetMsmqActivator ) : Running
Status for Net.Pipe Listener Adapter ( NetPipeActivator ) : Running
Status for Net.Tcp Listener Adapter ( NetTcpActivator ) : Running
Status for World Wide Web Publishing Service ( W3SVC ) : Running
handle64.exe -accepteula -p w3wp

BF0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.ServerTelemetryChannel.dll
C58: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.AzureAppServices.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.DependencyCollector.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.WindowsServer.dll
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.Web.dll
CBC: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.PerfCounterCollector.dll
DB0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.AI.Agent.Intercept.dll
B98: File (R-D) C:\Program
ISModule.dll
BB4: File (R-D) C:\Program
ISModule.Contracts.dll
BCC: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Redfield.
Lightup.dll
BE0: File (R-D) C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.dll
listdlls64.exe -accepteula w3wp

0x0000000019ac0000 0x127000 C:\Program
e_x64.dll
0x00000000198b0000 0x4f000 C:\Program
0x000000000c460000 0xb2000 C:\Program
.Extensions.Base_x64.dll
0x000000000ad60000 0x108000
C:\Windows\TEMP\2.4.0.0.Microsoft.ApplicationInsights.Extensions.Intercept_x64.dll
Parámetros
(Sin parámetros )
De forma predeterminada, este cmdlet notificará el estado de supervisión de las aplicaciones web. Use esta
opción para revisar si la aplicación se ha instrumentado correctamente. También puede revisar qué clave de
instrumentación coincidió con su sitio.
-PowerShellModule
Opcional . Utilice este modificador para informar de los números de versión y rutas de acceso de los archivos
DLL necesarios para la supervisión. Use esta opción si tiene que identificar la versión de cualquier archivo DLL,
incluido el SDK de Application Insights.
-InspectProcess
Opcional . Utilice este modificador para informar de si se está ejecutando IIS. También descargará herramientas
externas para determinar si los archivos DLL necesarios se han cargado en el entorno de ejecución de IIS.
Si se produce un error en este proceso por cualquier motivo, puede ejecutar estos comandos manualmente:
iisreset.exe /status
handle64.exe -p w3wp | findstr /I "InstrumentationEngine AI. ApplicationInsights"
listdlls64.exe w3wp | findstr /I "InstrumentationEngine AI ApplicationInsights"
-Force
Opcional . Se utiliza solo con InspectProcess. Use este modificador para omitir el mensaje de usuario que aparece
antes de que se descarguen las herramientas adicionales.
Set-ApplicationInsightsMonitoringConfig
Establece el archivo de configuración sin tener que realizar una reinstalación completa. Reinicie IIS para que los
cambios surtan efecto.
IMPORTANT
Este cmdlet requiere una sesión de PowerShell con permisos de administrador.
Ejemplos
Ejemplo con una única clave de instrumentación
En este ejemplo, a todas las aplicaciones en el equipo actual se les asignará una única clave de instrumentación.
PS C:\> Enable-ApplicationInsightsMonitoring -InstrumentationKey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Ejemplo con un mapa de claves de instrumentación

En este ejemplo:
MachineFilter busca la correspondencia con el equipo actual usando el comodín '.*' .
AppFilter='WebAppExclude' proporciona una clave de instrumentación null . No se puede instrumentar la
aplicación especificada.
AppFilter='WebAppOne' asigna una clave de instrumentación única a la aplicación especificada.
AppFilter='WebAppTwo' asigna una clave de instrumentación única a la aplicación especificada.
Por último, AppFilter también usa el comodín '.*' para buscar la correspondencia de todas las aplicaciones
web que no coincidan según las reglas anteriores y les asigna una clave de instrumentación predeterminada.
Se agregan espacios para mejorar la legibilidad.
Enable-ApplicationInsightsMonitoring -InstrumentationKeyMap `
@(@{MachineFilter='.*';AppFilter='WebAppExclude'},
@{MachineFilter='.*';AppFilter='WebAppOne';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-
xxxx-xxxx-xxxx-xxxxxxxxxxx1'}},
@{MachineFilter='.*';AppFilter='WebAppTwo';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-
xxxx-xxxx-xxxx-xxxxxxxxxxx2'}},
@{MachineFilter='.*';AppFilter='.*';InstrumentationSettings=@{InstrumentationKey='xxxxxxxx-xxxx-
xxxx-xxxx-xxxxxdefault'}})
Parámetros
-InstrumentationKey
Requerido. Use este parámetro para proporcionar una única clave de instrumentación para que la usen todas las
aplicaciones en el equipo de destino.
-InstrumentationKeyMap
Requerido. Use este parámetro para proporcionar varias claves de instrumentación y una asignación de las
claves de instrumentación utilizadas por cada aplicación. Puede crear un solo script de instalación para varios
equipos si establece MachineFilter .
IMPORTANT
Las aplicaciones se harán coincidir con las reglas en el orden en que estas se proporcionan. Por tanto, debe especificar las
reglas más específicas en primer lugar y las más genéricas las últimas.
Sc h e m a
@(@{MachineFilter='.*';AppFilter='.*';InstrumentationKey='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'})
MachineFilter es una expresión regular de C# requerida del nombre de la máquina virtual o del equipo.
"ComputerName" coincidirá solo son aquellos equipos que tengan el nombre especificado.
AppFilter es una expresión regular de C# requerida del nombre de la máquina virtual o del equipo.
"ApplicationName" coincidirá solo son aquellas aplicaciones IIS que tengan el nombre especificado.
InstrumentationKey se requiere para habilitar la supervisión de las aplicaciones que coincidan con los dos
filtros anteriores.
Deje este valor como null si desea definir reglas para excluir la supervisión.
-Verbose
Output
De forma predeterminada, no se produce ninguna salida.
Ej e m p l o d e sa l i d a d e t a l l a d a d e l a c o n fi g u r a c i ó n e n e l a r c h i v o d e c o n fi g u r a c i ó n a t r a v é s d e - I n st r u m e n t a t i o n K e y
VERBOSE: Operation: InstallWithIkey

VERBOSE: InstrumentationKeyMap parsed:
Filters:
0)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx AppFilter: .* MachineFilter: .*
VERBOSE: set config file
VERBOSE: Config File Path:
Ej e m p l o d e sa l i d a d e t a l l a d a d e l a c o n fi g u r a c i ó n e n e l a r c h i v o d e c o n fi g u r a c i ó n a t r a v é s d e - I n st r u m e n t a t i o n K e y M a p
VERBOSE: Operation: InstallWithIkeyMap

VERBOSE: InstrumentationKeyMap parsed:
Filters:
0)InstrumentationKey: AppFilter: WebAppExclude MachineFilter: .*
1)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx2 AppFilter: WebAppTwo MachineFilter: .*
2)InstrumentationKey: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxdefault AppFilter: .* MachineFilter: .*
VERBOSE: set config file
VERBOSE: Config File Path:
Start-ApplicationInsightsMonitoringTrace
Recopila eventos de ETW desde el runtime para adjuntar sin código. Este cmdlet es una alternativa a la ejecución
de PerfView.
Los eventos recopilados se imprimirán en la consola en tiempo real y se guardarán en un archivo ETL. PerfView
puede abrir el archivo ETL de salida para llevar a cabo una investigación más extensa.
Este cmdlet se ejecutará hasta alcanzar que se agote el tiempo de espera (con un valor predeterminado de 5
minutos) o hasta que se lo detiene manualmente ( Ctrl + C ).
Ejemplos
Recopilación de eventos
Por lo general, le pediríamos que recopile eventos para investigar por qué no se está instrumentando la
aplicación.
El runtime para adjuntar sin código emitirá eventos de ETW cuando se inician IIA y la aplicación.
Para recopilar estos eventos:
1. En una consola cmd con privilegio de administración, ejecute iisreset /stop para desactivar IIS y todas las
aplicaciones web.
2. Ejecute este cmdlet.
3. En una consola cmd con privilegio de administración ejecute iisreset /start para iniciar IIS.
4. Intente ir a la aplicación.
5. Cuando la aplicación termina de cargarse, puede detenerla de manera manual ( Ctrl + C ) o esperar a que se
agote el tiempo de espera.
Qué eventos se recopilan
Existen tres opciones al recopilar los eventos:
1. Use el modificador -CollectSdkEvents para recopilar los eventos emitidos desde el SDK de Application
Insights.
2. Use el modificador -CollectRedfieldEvents para recopilar los eventos que emite el Monitor de estado y el
runtime de Redfield. Estos registros son útiles al diagnosticar el inicio de IIS y de las aplicaciones.
3. Use ambos modificadores para recopilar ambos tipos de evento.
4. De manera predeterminada, si no se especifica ningún modificador, se recopilarán ambos tipos de evento.
Parámetros
-MaxDurationInMinutes
Opcional. Use este parámetro para establecer durante cuánto tiempo este script debe recopilar eventos. El valor
predeterminado es 5 minutos.
-LogDirectory
Opcional. Use este conmutador para establecer el directorio de salida del archivo ETL. De manera
predeterminada, este archivo se creará en el directorio de módulos de PowerShell. Se mostrará la ruta de acceso
completa durante la ejecución de un script.
-CollectSdkEvents
Opcional. Use este modificador para recopilar eventos del SDK de Application Insights.
-CollectRedfieldEvents
Opcional. Use este modificador para recopilar eventos desde el Monitor de estado y el runtime de Redfield.
-Verbose
Output
Ejemplo de registros de inicio de aplicación
PS C:\Windows\system32> Start-ApplicationInsightsMonitoringTrace -ColectRedfieldEvents
Starting...
Log File: C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\logs\20190627_144217_ApplicationInsights_ETW_Tr
ace.etl
Tracing enabled, waiting for events.
Tracing will timeout in 5 minutes. Press CTRL+C to cancel.
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Resolved variables to:

MicrosoftAppInsights_ManagedHttpModulePath='C:\Program
ISModule.dll',
MicrosoftAppInsights_ManagedHttpModuleType='Microsoft.ApplicationInsights.RedfieldIISModule.RedfieldIISModule
'
MicrosoftDiagnosticServices_ManagedHttpModulePath2='', MicrosoftDiagnosticServices_ManagedHttpModuleType2=''
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Environment variable
'MicrosoftDiagnosticServices_ManagedHttpModulePath2' or 'MicrosoftDiagnosticServices_ManagedHttpModuleType2'
is null, skipping managed dll loading
2:42:31 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace
MulticastHttpModule.constructor, success, 70 ms
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Current assembly
'Microsoft.ApplicationInsights.RedfieldIISModule, Version=2.8.18.27202, Culture=neutral,
PublicKeyToken=f23a46de0be5d6f3' location 'C:\Program
ISModule.dll'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Matched filter
'.*'~'STATUSMONITORTE', '.*'~'DemoWithSql'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace Lightup assembly calculated path:
'C:\Program
Files\WindowsPowerShell\Modules\Az.ApplicationMonitor\content\Runtime\Microsoft.ApplicationInsights.Redfield.
Lightup.dll'
2:42:31 PM EVENT: Microsoft-ApplicationInsights-FrameworkLightup Trace Loaded applicationInsights.config from
assembly's resource Microsoft.ApplicationInsights.Redfield.Lightup, Version=2.8.18.27202, Culture=neutral,
PublicKeyToken=f23a46de0be5d6f3/Microsoft.ApplicationInsights.Redfield.Lightup.ApplicationInsights-
recommended.config
2:42:34 PM EVENT: Microsoft-ApplicationInsights-FrameworkLightup Trace Successfully attached
ApplicationInsights SDK
2:42:34 PM EVENT: Microsoft-ApplicationInsights-RedfieldIISModule Trace
RedfieldIISModule.LoadLightupAssemblyAndGetLightupHttpModuleClass, success, 2687 ms
RedfieldIISModule.CreateAndInitializeApplicationInsightsHttpModules(lightupHttpModuleClass), success
2:42:34 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace ManagedHttpModuleHelper,
multicastHttpModule.Init() success, 3288 ms
MicrosoftAppInsights_ManagedHttpModulePath='C:\Program
ISModule.dll',
MicrosoftAppInsights_ManagedHttpModuleType='Microsoft.ApplicationInsights.RedfieldIISModule.RedfieldIISModule
'
MicrosoftDiagnosticServices_ManagedHttpModulePath2='', MicrosoftDiagnosticServices_ManagedHttpModuleType2=''
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace Environment variable
'MicrosoftDiagnosticServices_ManagedHttpModulePath2' or 'MicrosoftDiagnosticServices_ManagedHttpModuleType2'
is null, skipping managed dll loading
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace
MulticastHttpModule.constructor, success, 0 ms
RedfieldIISModule.CreateAndInitializeApplicationInsightsHttpModules(lightupHttpModuleClass), success
2:42:35 PM EVENT: Microsoft-ApplicationInsights-IIS-ManagedHttpModuleHelper Trace ManagedHttpModuleHelper,
multicastHttpModule.Init() success, 0 ms
Timeout Reached. Stopping...
Pasos siguientes
Vea la telemetría:
Use análisis para consultas más avanzadas.
Cree paneles.
Instrumentación de aplicaciones web en
tiempo de ejecución con Adjuntar sin código
de Application Insights
IMPORTANT
Ya no se recomienda el uso del Monitor de estado y, a par tir del 1 de junio de 2021 , no se admitirá
esta versión del Monitor de estado. Se ha reemplazado por Azure Application Insights Agent
(anteriormente denominado Monitor de estado V2). Consulte nuestra documentación sobre las
implementaciones de servidores locales o las implementaciones de máquinas virtuales y conjuntos de
Puede instrumentar una aplicación web activa con Azure Application Insights sin tener que
modificar ni volver a implementar el código. Necesita una suscripción a Microsoft Azure .
Monitor de estado se usa para instrumentar una aplicación .NET hospedada en IIS, ya sea en el
entorno local o en una máquina virtual.
Si la aplicación se implementa en una máquina virtual de Azure o en un conjunto de escalado de
máquinas virtuales de Azure, siga estas instrucciones.
Si la aplicación se implementa en Azure App Services, siga estas instrucciones.
Si la aplicación se implementa en una máquina virtual de Azure, puede activar la supervisión de
Application Insights en el panel de control de Azure.
(También hay artículos independientes sobre cómo instrumentar Azure Cloud Services).
Puede optar entre dos vías de aplicar Application Insights a sus aplicaciones web .NET:
Tiempo de compilación: Agregue el SDK de Application Insights al código de la aplicación
web.
Tiempo de ejecución: instrumenta la aplicación web en el servidor, como se describe a
continuación, sin volver a generar e implementar el código.
NOTE
Si usa la instrumentación en tiempo de compilación, la instrumentación en tiempo de ejecución no
funcionará ni aunque esté activada.
A continuación hay un resumen de lo que se obtiene por cada vía:

T IEM P O DE C O M P IL A C IÓ N T IEM P O DE E JEC UC IÓ N
Solicitudes y excepciones Sí Sí
Excepciones más detalladas Sí
Diagnósticos de dependencia En .NET 4.6 +, pero con menos Sí, detalles completos: códigos de
detalle resultado, texto de comandos
SQL, verbo HTTP
Contadores de rendimiento Sí Sí
del sistema
API para la telemetría Sí No

personalizada
Integración del registro de Sí No

seguimiento
Vista de página y datos de Sí No

usuario
Es necesario volver a Sí No
compilar el código
Supervisión de una aplicación web de IIS activa

Si la aplicación se hospeda en un servidor IIS, habilite Application Insights con el Monitor de estado.
1. En el servidor web IIS, inicie sesión con las credenciales de administrador.
2. Si el Monitor de estado de Application Insights todavía no está instalado, descargue y ejecute
el instalador.
3. En el Monitor de estado, seleccione la aplicación web instalada o el sitio web que desea
supervisar. Inicie sesión con sus credenciales de Azure.
Configure el recurso donde desee ver los resultados en el portal de Application Insights.
(Normalmente, es mejor crear un nuevo recurso. Seleccione un recurso existente si ya tiene
pruebas web o la supervisión de cliente para esta aplicación).
4. Reinicie IIS.
El servicio web se interrumpe durante un breve período.
Personalización de las opciones de supervisión

Si se habilita Application Insights, se agregan archivos DLL y ApplicationInsights.config a la
aplicación web. También puede editar el archivo .config para cambiar algunas de las opciones.
Al volver a publicar la aplicación, vuelva a habilitar Application

Insights
Antes de volver a publicar la aplicación, considere la posibilidad de agregar Application Insights al
código de Visual Studio. Obtendrá una telemetría más detallada y la capacidad para escribir
telemetría personalizada.
Si desea volver a publicar sin agregar Application Insights al código, tenga en cuenta que el proceso
de implementación puede eliminar los archivos DLL y ApplicationInsights.config desde el sitio web
publicado. Por lo tanto:
1. Si edita el archivo ApplicationInsights.config, realice una copia del mismo antes de volver a
publicar la aplicación.
2. Vuelva a publicar la aplicación.
3. Vuelva a habilitar la supervisión de Application Insights. (Use el método adecuado: ya sea el
panel de control de la aplicación web de Azure o el Monitor de estado en un host IIS).
4. Restablezca las modificaciones realizadas en el archivo .config.
Confirmación de una instalación válida
Estos son algunos de los pasos que puede seguir para confirmar que la instalación se completó
correctamente.
Confirme que el archivo applicationInsights.config esté en el directorio de la aplicación de
destino y que incluya la clave de instrumentación.
Si sospecha que faltan datos, puede ejecutar una consulta en Analytics para mostrar todos
los roles de la nube que actualmente envían datos de telemetría.
union * | summarize count() by cloud_RoleName, cloud_RoleInstance
Si tiene que confirmar que Application Insights se ha adjuntado correctamente, puede

ejecutar Sysinternals Handle en una ventana de comando para confirmar que IIS cargó
applicationinsights.dll.
handle.exe /p w3wp.exe
¿No se puede conectar? ¿No hay telemetría?

Abra los puertos de salida necesarios en el firewall del servidor para que el Monitor de estado
funcione.
Error de inicio de sesión
Si el Monitor de estado no puede iniciar sesión, haga una instalación de línea de comandos. El
Monitor de estado intenta iniciar sesión para recopilar la clave de instrumentación, pero la puede
proporcionar manualmente con el comando:
Import-Module 'C:\Program Files\Microsoft Application Insights\Status

Monitor\PowerShell\Microsoft.Diagnostics.Agent.StatusMonitor.PowerShell.dll'
Start-ApplicationInsightsMonitoring -Name appName -InstrumentationKey 00000000-000-000-000-
0000000
No se pudo cargar el archivo ni el ensamblado "System.Diagnostics.DiagnosticSource"

Puede recibir este error después de habilitar Application Insights. Esto se debe a que el instalador
reemplaza este archivo dll en el directorio bin. Para corregir y actualizar web.config:
<dependentAssembly>
<assemblyIdentity name="System.Diagnostics.DiagnosticSource"
publicKeyToken="cc7b13ffcd2ddd51"/>
<bindingRedirect oldVersion="0.0.0.0-4.*.*.*" newVersion="4.0.2.1"/>
</dependentAssembly>
Hacemos un seguimiento de este problema aquí.

Mensajes de diagnósticos de la aplicación
Abrir el Monitor de estado y seleccione la aplicación en el panel izquierdo. Compruebe si hay
algún mensaje de diagnóstico para esta aplicación en la sección "Notificaciones de
configuración":
Registros detallados
De manera predeterminada, el Monitor de estado generará los registros de diagnóstico en:
C:\Program Files\Microsoft Application Insights\Status Monitor\diagnostics.log
Para generar registros detallados, modifique el archivo de configuración:

C:\Program Files\Microsoft Application Insights\Status
Monitor\Microsoft.Diagnostics.Agent.StatusMonitor.exe.config
y agregue <add key="TraceLevel" value="All" /> en appsettings . Luego, reinicie el monitor
de estado.
Puesto que Monitor de estado es una aplicación .NET, también es posible habilitar
seguimiento de .net mediante la adición de los diagnósticos adecuados al archivo de
configuración. Por ejemplo, en algunos escenarios puede resultar útil ver lo que sucede en el
nivel de red mediante la configuración del seguimiento de red.
Permisos insuficientes
En el servidor, si ve en un mensaje acerca de "permisos insuficientes", intente lo siguiente:
En el Administrador de IIS, seleccione el grupo de aplicaciones, abra Configuración
avanzada y en Modelo de proceso , anote la identidad.
En el panel de control de administración del equipo, agregue esta identidad al grupo
Usuarios del monitor de sistema.
Conflictos con Systems Center Operations Manager
Si tiene instalado MMA/SCOM (Systems Center Operation Manager) en el servidor, algunas
versiones pueden entrar en conflicto. Desinstale SCOM y el Monitor de estado y vuelva a
instalar las versiones más recientes.
Instalación errónea o incompleta
Si se produce un error del Monitor de estado durante una instalación, se podría generar una
instalación incompleta de la que el Monitor de estado no se pueda recuperar. Para esto se
necesitará un restablecimiento manual.
Elimine cualquiera de estos archivos encontrados en el directorio de la aplicación:
Cualquier archivo DLL en el directorio bin que comience con "Microsoft.AI." o
"Microsoft.ApplicationInsights.".
Este archivo DLL en el directorio bin: "Microsoft.Web.Infrastructure.dll"
Este archivo DLL en el directorio bin: "System.Diagnostics.DiagnosticSource.dll"
En el directorio de la aplicación, quite "App_Data\packages"
En el directorio de la aplicación, quite "applicationinsights.config"
Más soluciones de problemas
Consulte Más soluciones de problemas.
Requisitos del sistema

Compatibilidad de sistema operativo para el Monitor de estado de Application Insights en servidor:
Windows Server 2008
Windows Server 2012
Windows Server 2016
con .NET Framework 4.5 y la versión más reciente de SP (Monitor de estado se compila en esta
versión de framework).
En el lado cliente: Windows 7, 8, 8.1 y 10, nuevamente con .NET Framework 4.5
La compatibilidad con IIS es: IIS 7, 7.5, 8, 8.5 (se requiere IIS)
Automatización con PowerShell

Puede iniciar y detener la supervisión mediante PowerShell en el servidor IIS.
En primer lugar, importe el módulo de Application Insights:
Import-Module 'C:\Program Files\Microsoft Application Insights\Status
Monitor\PowerShell\Microsoft.Diagnostics.Agent.StatusMonitor.PowerShell.dll'
Encuentre las aplicaciones en supervisión:

Get-ApplicationInsightsMonitoringStatus [-Name appName]
-Name (Opcional) Nombre de una aplicación web.

Muestra el estado de supervisión de Application Insights para cada aplicación web (u otra
aplicación con nombre) en este servidor IIS.
Devuelve ApplicationInsightsApplication para cada aplicación:
SdkState==EnabledAfterDeployment : la aplicación se está supervisando y se ha
instrumentado en tiempo de ejecución, ya sea con la herramienta Monitor de estado o
con Start-ApplicationInsightsMonitoring .
SdkState==Disabled : la aplicación no se ha instrumentado para Application Insights.
Nunca se ha instrumentado, o bien se deshabilitó la supervisión en tiempo de ejecución
con la herramienta Monitor de estado o con Stop-ApplicationInsightsMonitoring .
SdkState==EnabledByCodeInstrumentation : se ha instrumentado la aplicación agregando el
SDK al código fuente. El SDK no se puede actualizar ni detener.
SdkVersion muestra la versión en uso para la supervisión de esta aplicación.
LatestAvailableSdkVersion muestra la versión disponible en la galería de NuGet. Para
actualizar la aplicación a esta versión, use Update-ApplicationInsightsMonitoring .
Start-ApplicationInsightsMonitoring -Name appName -InstrumentationKey 00000000-000-000-000-
0000000
-Name El nombre de la aplicación en IIS

-InstrumentationKey El valor ikey del recurso de Application Insights donde quiere que se
muestren los resultados.
Este cmdlet solo afecta a las aplicaciones que no se han instrumentado, es decir, aquellas
cuyo SdkState == NotInstrumented.
El cmdlet no afecta a una aplicación que ya se ha instrumentado. No importa que se
instrumentara en tiempo de compilación mediante la adición del SDK al código, o en tiempo
de ejecución mediante un uso anterior de este cmdlet.
La versión del SDK utilizada para instrumentar la aplicación es la versión que se ha
descargado más recientemente en este servidor.
Para descargar la versión más reciente, use Update-ApplicationInsightsVersion.
Si se descarga correctamente, devuelve ApplicationInsightsApplication . Si se produce un
error, inicia un seguimiento a stderr.
Name : Default Web Site/WebApp1

InstrumentationKey : 00000000-0000-0000-0000-000000000000
ProfilerState : ApplicationInsights
SdkState : EnabledAfterDeployment
SdkVersion : 1.2.1
LatestAvailableSdkVersion : 1.2.3
Stop-ApplicationInsightsMonitoring [-Name appName | -All]

-Name El nombre de una aplicación en IIS
-All Detiene la supervisión de todas las aplicaciones en este servidor IIS con
SdkState==EnabledAfterDeployment
Detiene la supervisión de las aplicaciones especificadas y quita la instrumentación. Solo
funciona para las aplicaciones que se han instrumentado en tiempo de ejecución con la
herramienta Monitor de estado o Start-ApplicationInsightsApplication. (
SdkState==EnabledAfterDeployment )
Devuelve ApplicationInsightsApplication.
Update-ApplicationInsightsMonitoring -Name appName [-InstrumentationKey "0000000-0000-000-000-
0000"
]
-Name : el nombre de la aplicación web en IIS.
-InstrumentationKey (Opcional). Utilice esto para cambiar el recurso al que se envía la
telemetría de la aplicación.
Este cmdlet:
Permite actualizar la aplicación con nombre a la versión del SDK descargada más
recientemente en este equipo. (Solo funciona si SdkState==EnabledAfterDeployment )
Si proporciona una clave de instrumentación, se vuelve a configurar la aplicación con
nombre para enviar los datos de telemetría al recurso con esa clave. (Funciona si
SdkState != Disabled )
Update-ApplicationInsightsVersion
Permite descargar el SDK más reciente de Application Insights en el servidor.
Preguntas acerca del Monitor de estado

Una aplicación de escritorio que se instala en el servidor web de IIS. Le ayuda a instrumentar y
configurar aplicaciones web.
¿Cuándo puedo usar el Monitor de estado?
Para instrumentar cualquier aplicación web que se ejecute en el servidor IIS, incluso si ya se está
en ejecución.
Para habilitar la telemetría adicional para las aplicaciones web que se han compilado con el SDK
de Application Insights en el momento de la compilación.
¿Puedo cerrarlo después de ejecutarlo?
Sí. Una vez que se hayan instrumentado los sitios web seleccionados, puede cerrarlo.
No recopila telemetría por sí mismo. Simplemente configura las aplicaciones web y establece
algunos permisos.
¿Qué hace el Monitor de estado?
Cuando selecciona una aplicación web para instrumentarla con el Monitor de estado:
Descarga y coloca los ensamblados de Application Insights y el archivo
ApplicationInsights.config en la carpeta de archivos binarios de la aplicación web.
Habilita la generación de perfiles de CLR para recopilar llamadas de dependencia.
¿Qué versión del SDK de Application Insights realiza la instalación de Monitor de estado?
A partir de ahora, Monitor de estado solo puede instalar las versiones 2.3 o 2.4 del SDK de
La versión 2.4 del SDK de Application Insights es la última compatible con .NET 4.0, cuyo final de
vida útil fue en enero de 2016. Por lo tanto, a partir de ahora se puede usar Monitor de estado para
instrumentar una aplicación .NET 4.0.
¿Tengo que actualizar el Monitor de estado siempre que actualice la aplicación?
No si reimplementa de forma incremental.
Si selecciona la opción "eliminar archivos existentes" en el proceso de publicación, necesitará volver
a ejecutar el Monitor de estado para configurar Application Insights.
¿Qué telemetría se recopila?
En el caso de las aplicaciones que instrumenta solo en tiempo de ejecución mediante el Monitor de
estado:
Solicitudes HTTP
Llamadas a dependencias
Excepciones
En el caso de las aplicaciones ya instrumentadas en el momento de la compilación:
Contadores de proceso.
Llamadas de dependencia (.NET 4.5); valores devueltos en las llamadas de dependencia (.NET
4.6).
Valores de seguimiento de la pila de excepción.
Más información
Vídeo
Descarga del Monitor de estado

Use el nuevo Módulo de PowerShell
Descargue y ejecute el instalador del Monitor de estado
O ejecute el Instalador de plataforma web y busque ahí el Monitor de estado de Application
Insights.
Pasos siguientes
Vea la telemetría:
Explore las métricas para supervisar el rendimiento y uso.
Análisis para más consultas avanzadas
Agregue telemetría de cliente web para ver las excepciones de código de la página web y para
que le permitan insertar llamadas de seguimiento.
Agregue el SDK de Application Insights al código para que pueda insertar llamadas de
seguimiento y registro.
Supervisión sin código de aplicaciones de Java en el
entorno local con Application Insights de Azure
Monitor: versión preliminar pública
La supervisión de aplicaciones Java sin código destaca por su simplicidad. No hace falta que realice ningún cambio
en el código, ya que el agente de Java se puede habilitar mediante un par de cambios de configuración.
Una vez habilitado, el agente de Java recopilará automáticamente una gran cantidad de solicitudes, dependencias,
registros y métricas de las bibliotecas y los marcos de trabajo más usados.
Siga las instrucciones detalladas para todos los entornos, incluido el local.
Pasos siguientes
Obtención de las instrucciones para descargar el agente de Java
Configuración de los argumentos de JVM
Personalización de la configuración
Azure Monitor.
General
para Azure Monitor.
Monitor.
Registros
en Azure Monitor.
información.
sus tipos.
Métricas
de métricas?
Alertas
tipos de alertas:
Agentes
Analytics.
de datos enviada:
WireData
la red.
Log Analytics?
recurso.
Visualizaciones
Aplicación .NET
virtuales de Azure
SharePoint
Otras plataformas
¿Es gratis?
limitar los gastos.
¿Cuánto cuesta?
ai.js
Web.config
packages.config
Resource Manager?
Más información.
Solicitudes HTTP
Log Analytics
Logstash

Podría:
servidor proxy.

automáticamente)
rendimiento
web

de servidor
producido.
Automation
proxy.
...
<TelemetryModules>
<Add
t>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
</TelemetryChannel>
...
...
NOTE

<system.net>
<defaultProxy>
</defaultProxy>
</system.net>

soluciones:

sencilla.
contenedores.
Kubelet
Opción 1
combinaciones.

ContainerLog
ContainerData
Opción 2
NOTE

clústeres.
Helm?
contenedores.
}));
los registros:
21Vianet.

compatibles.
Insights.
agregado?
subredes?
experiencia.
protocolos.
Pasos siguientes
adicionales.
Log Analytics
Creación de recursos en Application
Insights
Azure Application Insights muestra los datos de la aplicación en un recursode Microsoft Azure.
Por tanto, la creación de un nuevo recurso forma parte de la configuración de Application
Insights para supervisar una aplicación nueva. Después de haber creado el recurso nuevo,
puede obtener su clave de instrumentación y usarla para configurar el SDK de Application
Insights. La clave de instrumentación vincula la telemetría al recurso.
Iniciar sesión en Microsoft Azure


Inicie sesión en Azure Portal y cree un recurso de Application Insights:
Nombre Unique value Nombre que identifica la

aplicación que está
supervisando.
Grupo de recursos myResourceGroup Nombre para el grupo de

recursos nuevo o existente que
hospedará los datos de
Región East US Elija una ubicación cerca de

usted o de donde se hospeda la
aplicación.
Modo de recursos Classic o Workspace-based Los recursos basados en el área

de trabajo se encuentran
actualmente en versión
preliminar pública y permiten
enviar la telemetría de
Application Insights a un área de
trabajo común de Log Analytics.
Para obtener más información,
consulte el artículo sobre los
recursos basados en áreas de
trabajo.
NOTE
Aunque puede usar el mismo nombre de recurso en distintos grupos de recursos, puede ser
beneficioso usar un nombre único global. Esto puede ser útil si tiene previsto realizar consultas entre
recursos ya que simplifica la sintaxis necesaria.
Escriba los valores apropiados en los campos obligatorios y, a continuación, seleccione Revisar
y crear .
Cuando se haya creado la aplicación, se abrirá un panel nuevo. En este panel podrá ver los datos
de uso y rendimiento de la aplicación supervisada.

La clave de instrumentación identifica el recurso con el que quiere asociar los datos de
telemetría. Necesitará copiar la clave de instrumentación y agregarla al código de la aplicación.
Instalación del SDK en la aplicación

Instale el SDK de Application Insights en su aplicación. Este paso depende en gran medida del
tipo de aplicación.
Use la clave de instrumentación para configurar el SDK que instala en la aplicación.
El SDK incluye módulos estándar que envían telemetría sin tener que escribir código adicional.
Para realizar un seguimiento de las acciones del usuario o diagnosticar los problemas con más
detalle, use la API para enviar su propia telemetría.
Creación de un recurso de forma automática

PowerShell
Creación de un recurso de Application Insights
New-AzApplicationInsights [-ResourceGroupName] <String> [-Name] <String> [-Location]
<String> [-Kind <String>]
[-Tag <Hashtable>] [-DefaultProfile <IAzureContextContainer>] [-WhatIf] [-Confirm]
[<CommonParameters>]
Ejemplo
New-AzApplicationInsights -Kind java -ResourceGroupName testgroup -Name test1027 -location

eastus
Results
Id :
/subscriptions/{subid}/resourceGroups/testgroup/providers/microsoft.insights/components/test
1027
ResourceGroupName : testgroup
Name : test1027
Kind : web
Location : eastus
Type : microsoft.insights/components
AppId : 8323fb13-32aa-46af-b467-8355cf4f8f98
ApplicationType : web
Tags : {}
CreationDate : 10/27/2017 4:56:40 PM
FlowType :
HockeyAppId :
HockeyAppToken :
InstrumentationKey : 00000000-aaaa-bbbb-cccc-dddddddddddd
ProvisioningState : Succeeded
RequestSource : AzurePowerShell
SamplingPercentage :
TenantId : {subid}
Para obtener la documentación completa de PowerShell para este cmdlet y obtener información
sobre cómo recuperar la clave de instrumentación, consulte la documentación de Azure
PowerShell.
CLI de Azure (versión preliminar)
Para obtener acceso a los comandos de la CLI de Azure de Application Insights en versión
preliminar, primero debe ejecutar:
az extension add -n application-insights
Si no ejecuta el comando az extension add , verá un mensaje de error que indica:

az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az
monitor --help'.
Ahora puede ejecutar lo siguiente para crear el recurso de Application Insights:
az monitor app-insights component create --app

--location
--resource-group
[--application-type]
[--kind]
[--tags]
Ejemplo
az monitor app-insights component create --app demoApp --location westus2 --kind web -g
demoRg --application-type web
Results
az monitor app-insights component create --app demoApp --location eastus --kind web -g
demoApp --application-type web
{
"appId": "87ba512c-e8c9-48d7-b6eb-118d4aee2697",
"applicationId": "demoApp",
"applicationType": "web",
"creationDate": "2019-08-16T18:15:59.740014+00:00",
"etag": "\"0300edb9-0000-0100-0000-5d56f2e00000\"",
"flowType": "Bluefield",
"hockeyAppId": null,
"hockeyAppToken": null,
"id":
"/subscriptions/{subid}/resourceGroups/demoApp/providers/microsoft.insights/components/demoA
pp",
"instrumentationKey": "00000000-aaaa-bbbb-cccc-dddddddddddd",
"kind": "web",
"location": "eastus",
"name": "demoApp",
"requestSource": "rest",
"resourceGroup": "demoApp",
"samplingPercentage": null,
"tags": {},
"tenantId": {tenantID},
"type": "microsoft.insights/components"
}
Para obtener la documentación completa de la CLI de Azure para este comando y obtener
información sobre cómo recuperar la clave de instrumentación, consulte la documentación de la
CLI de Azure.
Pasos siguientes
Exploración de métricas
Escribir consultas de Analytics
Recursos de Application Insights basados en áreas
de trabajo
Los recursos basados en área de trabajo permiten la integración completa entre Application Insights y Log
Analytics. Ahora puede optar por enviar la telemetría de Application Insights a un área de trabajo común de
Log Analytics, lo que permite el acceso completo a todas las características de Log Analytics a la vez que se
mantienen los registros de aplicación, infraestructura y plataforma en una única ubicación consolidada.
Esto también permite el control de acceso basado en rol (RBAC) común en los recursos y elimina la necesidad
de consultas entre aplicaciones y áreas de trabajo.
NOTE
La ingesta de datos y la retención de recursos de Application Insights basados en área de trabajo se facturan por
medio del área de trabajo de Log Analytics en la que se encuentran los datos. Más información sobre la facturación de
recursos de Application Insights basados en área de trabajo.
Funcionalidades nuevas
Application Insights basado en áreas de trabajo permite aprovechar las capacidades más recientes de
Azure Monitor y Log Analytics, lo que incluye:
Las claves administradas por el cliente (CMK) proporcionan cifrado en reposo de los datos mediante claves
de cifrado a las que solo tiene acceso el usuario.
Azure Private Link le permite vincular de forma segura los servicios PaaS de Azure a la red virtual
mediante puntos de conexión privados.
Traiga su propio almacenamiento (BYOS) para Profiler y Snapshot Debugger le proporciona control total
sobre la directiva de cifrado en reposo, la directiva de administración de la duración y el acceso a la red
para todos los datos asociados a Application Insights Profiler y Snapshot Debugger.
Los niveles de reserva de capacidad permiten ahorrar hasta un 25 % en comparación con el precio de
Pago por uso.
Ingesta de datos más rápida gracias a la ingesta de streaming de Log Analytics.
Creación de un recurso basado en áreas de trabajo

Inicie sesión en Azure Portal y cree un recurso de Application Insights:
Si aún no tiene un área de trabajo de Log Analytics, vea la documentación de creación de áreas de trabajo de
Log Analytics.
Los recursos basados en el área de trabajo están disponibles actualmente en todas las regiones
comerciales y en Azure Government .
Una vez creado el recurso, se ve la información del área de trabajo correspondiente en el panel de
información general :
Al hacer clic en el texto del vínculo azul, se le lleva al área de trabajo de Log Analytics asociada, donde puede
aprovechar el nuevo entorno de consultas unificado del área de trabajo.
NOTE
Todavía se proporciona compatibilidad total con versiones anteriores con las consultas de recursos clásicas, los libros y
las alertas basadas en registro de Application Insights dentro de la experiencia de Application Insights. Para consultar o
ver en la nueva estructura o esquema de tabla basados en área de trabajo, primero debe ir al área de trabajo de Log
Analytics. Al seleccionar Registros ( Analytics) en los paneles de Application Insights se obtiene acceso a la
experiencia de consulta clásica de Application Insights.
Copiar la cadena de conexión

La cadena de conexión identifica el recurso con el que se quieren asociar los datos de telemetría. También
permite modificar los puntos de conexión que va a usar el recurso como destino de la telemetría. Tiene que
copiar la cadena de conexión y agregarla al código de la aplicación o a una variable de entorno.
Configuración de supervisión
Una vez creado un recurso de Application Insights basado en área de trabajo, la configuración de la
supervisión es relativamente sencilla.
Supervisión de aplicaciones basada en código
En la supervisión de aplicaciones basada en código, solo se debe instalar el SDK adecuado de Application
Insights y apuntarlo a la clave de instrumentación o la cadena de conexión del recurso recién creado.
Para obtener documentación detallada sobre la configuración de un SDK de Application Insights para la
supervisión basada en código, vea la documentación específica del lenguaje o el marco:
ASP.NET
ASP.NET Core
Tareas en segundo plano y aplicaciones de consola modernas (.NET/.NET Core)
Aplicaciones de consola clásicas (.NET)
Java
JavaScript
Node.js
Python
Supervisión sin código y creación de recursos de Visual Studio
En la supervisión sin código de servicios como Azure Functions y Azure App Services, también tiene que crear
primero el recurso de Application Insights basado en área de trabajo y luego apuntar a ese recurso durante la
fase de configuración de la supervisión.
Aunque estos servicios ofrecen la opción de crear un nuevo recurso de Application Insights dentro de su
propio proceso de creación de recursos, los recursos creados mediante estas opciones de la interfaz de
usuario están restringidos actualmente a la experiencia clásica de Application Insights.
Lo mismo se aplica a la experiencia de creación de recursos de Application Insights en Visual Studio para
ASP.NET y ASP.NET Core. Debe seleccionar un recurso existente basado en área de trabajo desde la interfaz de
usuario de habilitación de la supervisión de Visual Studio. Si opta por crear el nuevo recurso desde
Visual Studio, se le limita a crear un recurso de Application Insights clásico.
Creación de un recurso de forma automática

Azure CLI
Para acceder a los comandos de la CLI de Azure de Application Insights en versión preliminar, primero debe
ejecutar:
Si no ejecuta el comando az extension add , aparece un mensaje de error que indica:

az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az monitor --help'.
Ahora puede ejecutar lo siguiente para crear el recurso de Application Insights:
az monitor app-insights component create --app

--location
--resource-group
[--application-type]
[--ingestion-access {Disabled, Enabled}]
[--kind]
[--only-show-errors]
[--query-access {Disabled, Enabled}]
[--tags]
[--workspace]
Ejemplo
az monitor app-insights component create --app demoApp --location eastus --kind web -g my_resource_group
--workspace "/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/test1234/providers/microsoft.operationalinsights/workspaces/test1234555"
Para obtener la documentación completa de la CLI de Azure para este comando, vea la documentación de la
CLI de Azure.
Azure PowerShell
El comando New-AzApplicationInsights de PowerShell no admite actualmente la creación de un recurso de
Application Insights basado en área de trabajo. Para crear un recurso basado en área de trabajo con
PowerShell, puede usar las plantillas de Azure Resource Manager siguientes e implementar con PowerShell.
Plantillas del Administrador de recursos de Azure
{
"parameters": {
"name": {
"type": "string"
},
"type": {
"type": "string"
},
"regionId": {
"type": "string"
},
"tagsArray": {
"type": "object"
},
"requestSource": {
"type": "string"
},
"type": "string"
}
},
"resources": [
{
"properties": {
"Request_Source": "[parameters('requestSource')]",
"WorkspaceResourceId": "[parameters('workspaceResourceId')]"
}
}
]
}
{
"parameters": {
"type": {
"value": "web"
},
"name": {
"value": "customresourcename"
},
"regionId": {
"value": "eastus"
},
"tagsArray": {
"value": {}
},
"requestSource": {
"value": "Custom"
},
"value": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/my_resource_group/providers/microsoft.operationalinsights/workspaces/myworksp
acename"
}
}
}
Modificación del área de trabajo asociada

Una vez creado un recurso de Application Insights basado en área de trabajo, puede modificar el área de
trabajo de Log Analytics asociada.
En el panel del recurso de Application Insights, seleccione Propiedades > Cambiar el área de trabajo >
Áreas de trabajo de Log Analytics .
Exportación de telemetría
La funcionalidad de exportación continua heredada no es compatible con los recursos basados en área de
trabajo. En su lugar, seleccione Configuración de diagnóstico > Agregar configuración de
diagnóstico en el recurso de Application Insights. Puede seleccionar todas las tablas, o un subconjunto de
tablas, para archivar en una cuenta de almacenamiento o para transmitir a un centro de eventos de Azure.
Pasos siguientes
Panel de información general de Application
Insights
Application Insights siempre ha proporcionado un panel de información general de resumen para permitir
una valoración rápida a simple vista del mantenimiento y el rendimiento de una aplicación. El nuevo panel de
información general proporciona una experiencia más rápida y flexible.
¿Cómo se prueba la nueva experiencia?

Ahora, el nuevo panel de información general se inicia de forma predeterminada:
Mejor rendimiento
Se ha simplificado la selección de intervalo de tiempo a favor de una interfaz más sencilla con un solo clic.
El rendimiento en general ha aumentado enormemente. Se tiene acceso con un solo clic a funciones
populares como Buscar y Análisis . Cada mosaico de KPI de actualización dinámica predeterminado
proporciona información de las funciones correspondientes de Application Insights. Para obtener más
información acerca de las solicitudes erróneas, seleccione Errores en el encabezado Investigar :
Panel de la aplicación
El panel de la aplicación aprovecha la tecnología de paneles existente en Azure para proporcionar una única
vista en el panel, totalmente personalizable, del mantenimiento y el rendimiento de la aplicación.
Para acceder al panel predeterminado, seleccione Panel de la aplicación en la esquina superior izquierda.
Si esta es la primera vez que accede al panel, se iniciará una vista predeterminada:
Puede conservar la vista predeterminada si así lo desea. Aunque también puede agregar o eliminar
elementos del panel para adaptarlo mejor a las necesidades de su equipo.
NOTE
Todos los usuarios con acceso al recurso de Application Insights comparten el mismo panel de la aplicación. Los
cambios que realice cualquiera de ellos modificarán la vista de todos.
Para volver a la experiencia de información general, simplemente seleccione:
Si selecciona Configurar las opciones del icono y establece un intervalo de tiempo personalizado que
supere los 31 días, el panel no mostrará más de 31 días de datos, incluso con la retención de datos
predeterminada de 90 días. Actualmente no hay ninguna solución alternativa para este comportamiento.
Pasos siguientes
Embudos
Retención
Flujos de usuario
Mapa de aplicación: Evaluación de prioridades de
las aplicaciones distribuidas
El mapa de aplicación le ayuda a detectar los cuellos de botella en el rendimiento o las zonas activas con
error en todos los componentes de la aplicación distribuida. Cada nodo del mapa representa un
componente de aplicación o sus dependencias, e incluye el KPI de mantenimiento y el estado de alerta.
Puede hacer clic a través de cualquier componente para ver un diagnóstico más detallado, como los eventos
de Application Insights. Si su aplicación usa los servicios de Azure, también puede hacer clic por los
diagnósticos de Azure, como las recomendaciones SQL Database Advisor.
¿Qué es un componente?
Los componentes son partes que se pueden implementar independientemente de su aplicación de
microservicios o distribuida. Los equipos de operaciones y los desarrolladores pueden ver el código o
acceder a la telemetría que generan estos componentes de la aplicación.
Los componentes son diferentes de las dependencias externas "observadas", como SQL, EventHub, etc. a
las que su equipo u organización no pueden acceder (código o telemetría).
Los componentes se ejecutan en cualquier número de instancias de rol, servidor o contenedor.
Los componentes pueden ser claves de instrumentación de Application Insights independientes (incluso
aunque las suscripciones sean diferentes) o diferentes roles que informan a una única clave de
instrumentación de Application Insights. La experiencia de mapa de versión preliminar muestra los
componentes con independencia de cómo están configurados.
Mapa de aplicación compuesta

Puede ver la topología de aplicación completa a lo largo de varios niveles de componentes de aplicación
relacionados. Los componentes podrían ser diferentes recursos de Application Insights o distintos roles de
un único recurso. Para encontrar componentes, el mapa de aplicación sigue las llamadas de dependencia
HTTP entre los servidores con el SDK de Application Insights instalado.
Esta experiencia comienza con la detección progresiva de los componentes. La primera vez que carga el
mapa de aplicación, se desencadena un conjunto de consultas para detectar los componentes relacionados
con este componente. Un botón en la esquina superior izquierda se actualiza con el número de
componentes de la aplicación a medida que se detectan.
Al hacer clic en "Update map components" (Actualizar componentes del mapa), el mapa se actualiza con
todos los componentes detectados hasta ese momento. Según la complejidad de la aplicación, esta
operación puede tardar un minuto en cargarse.
Si todos los componentes son roles dentro de un único recurso de Application Insights, este paso de
detección no es necesario. La carga inicial para este tipo de aplicación tendrá todos sus componentes.
Uno de los objetivos principales de la experiencia es poder visualizar topologías complejas con cientos de
componentes.
Haga clic en cada componente para ver información detallada relacionada e ir a la experiencia de evaluación
de prioridades de rendimiento y errores de ese componente.
Investigar los errores

Seleccione Investigar los errores para iniciar el panel de errores.
Investigar el rendimiento
Para solucionar problemas de rendimiento haga clic en Investigar el rendimiento .
Ir a los detalles
Haga clic en Ir a los detalles para explorar una experiencia de transacción completa, que puede ofrecer las
vistas hasta el nivel de la pila de llamadas.
Visualización de Registros (Analytics)
Para consultar e investigar aún más los datos de aplicaciones, haga clic en Ver en Registros (Analytics) .
Alertas
Para ver las alertas activas y las reglas subyacentes que provocan el desencadenamiento de estas, haga clic
en Aler tas .
Establecimiento o reemplazo del nombre del rol en la nube
El mapa de aplicación usa la propiedad nombre de rol en la nube para identificar los componentes en el
mapa. Para establecer o reemplazar manualmente el nombre de rol en la nube y cambiar lo que se muestra
en el mapa de aplicación:
NOTE
El Agente o SDK de Application Insights agregan de forma automática la propiedad de nombre de rol en la nube a la
telemetría emitida por los componentes en un entorno de Azure App Service.
.NET/.NetCore
Java
Node.js
JavaScript
Escriba un elemento Telemetr yInitializer personalizado como el siguiente.
namespace CustomInitializer.Telemetry
{
public class MyTelemetryInitializer : ITelemetryInitializer
{
public void Initialize(ITelemetry telemetry)
{
if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
{
//set custom role name here
telemetry.Context.Cloud.RoleName = "Custom RoleName";
telemetry.Context.Cloud.RoleInstance = "Custom RoleInstance";
}
}
}
}
Aplicaciones ASP.NET: cargue el inicializador en el elemento Telemetr yConfiguration activo.

En ApplicationInsights.config:

<Add Type="CustomInitializer.Telemetry.MyTelemetryInitializer, CustomInitializer"/>
...
Un método alternativo para las aplicaciones web de ASP.NET consiste en crear una instancia del inicializador
en el código, por ejemplo, en Global.aspx.cs:
using CustomInitializer.Telemetry;

{
// ...
TelemetryConfiguration.Active.TelemetryInitializers.Add(new MyTelemetryInitializer());
}
NOTE
La adición del inicializador mediante ApplicationInsights.config o TelemetryConfiguration.Active no es
válida para las aplicaciones de ASP.NET Core.
Aplicaciones de ASP.NET Core: cargue el inicializador en el elemento Telemetr yConfiguration.

Para aplicaciones de ASP.NET Core, la adición de un nuevo elemento TelemetryInitializer se realiza
agregándolo al contenedor de inserción de dependencias, como se muestra a continuación. Esto se hace en
el método ConfigureServices de la clase Startup.cs .
{
services.AddSingleton<ITelemetryInitializer, MyTelemetryInitializer>();
}
Comprensión del nombre de rol en la nube dentro del contexto del mapa de aplicación
Para comprender el nombre de rol en la nube , puede ser útil consultar un mapa de aplicación que tenga
presentes varios nombres de rol en la nube:
En el mapa de aplicación de arriba, cada uno de los nombres de los cuadros verdes son valores de nombre
de rol en la nube para distintos aspectos de esta aplicación distribuida. Por lo que, para esta aplicación, sus
roles constan de: Authentication , acmefrontend , Inventory Management y Payment Processing Worker Role .
En el caso de esta aplicación, cada uno de esos nombres de rol en la nube también representa un único
recurso de Application Insights diferente con sus propias claves de instrumentación. Puesto que el
propietario de esta aplicación tiene acceso a cada uno de estos cuatro recursos de Application Insights, el
mapa de aplicación es capaz de unir un mapa de las relaciones subyacentes.
Para las definiciones oficiales:
[Description("Name of the role the application is a part of. Maps directly to the role name in
azure.")]
[MaxStringLength("256")]
705: string CloudRole = "ai.cloud.role";
[Description("Name of the instance where the application is running. Computer name for on-premises,
instance name for Azure.")]
[MaxStringLength("256")]
715: string CloudRoleInstance = "ai.cloud.roleInstance";
Como alternativa, la instancia de rol en la nube puede ser muy útil para escenarios donde el nombre
de rol en la nube indica que el problema se encuentra en algún lugar en el front-end web, pero puede
que ejecute el front-end web en varios servidores de carga equilibrada, por lo que poder profundizar a un
nivel más profundo a través de las consultas de Kusto y saber si el problema afecta a todos los servidores o
instancias de front-end web o solo a uno puede ser muy importante.
Un escenario en el que podría querer reemplazar el valor de la instancia de rol en la nube podría ser si la
aplicación se ejecutara en un entorno en contenedor donde simplemente conocer el servidor individual no
sería suficiente información para localizar un problema determinado.
Para obtener más información sobre cómo reemplazar la propiedad de nombre de rol en la nube con
inicializadores de telemetría, vea Agregar propiedades: ITelemetryInitializer.
Si tiene dificultades para conseguir que el mapa de aplicación funcione según lo esperado, siga estos pasos:
General
1. Asegúrese de que usa un SDK oficialmente compatible. Es posible que los SDK no compatibles o de
la comunidad no admitan la correlación.
Consulte este artículo para obtener una lista de los SDK compatibles.
2. Actualice todos los componentes a la versión más reciente del SDK.
3. Si usa Azure Functions con C#, actualice a Functions V2.
4. Confirme que el nombre de rol en la nube está configurado correctamente.
5. Si falta una dependencia, asegúrese de que se encuentra en la lista de dependencias recopiladas
automáticamente. De lo contrario, todavía puede realizar su seguimiento de forma manual con una
llamada de seguimiento de dependencia.
Hay demasiados nodos en el mapa
El mapa de aplicación construye un nodo de aplicación para cada nombre de rol en la nube único presente
en la telemetría de solicitud y un nodo de dependencia para cada combinación única de tipo, destino y
nombre de rol en la nube en la telemetría de dependencia. Si hay más de 10 000 nodos en la telemetría, el
mapa de aplicación no podrá capturar todos los nodos y vínculos, por lo que la asignación será incompleta.
Si ocurre esto, aparecerá un mensaje de advertencia al visualizar el mapa.
Además, el mapa de aplicación solo admite hasta 1000 nodos sin agrupar independientes representados a
la vez. El mapa de aplicación reduce la complejidad visual agrupando las dependencias que tengan el
mismo tipo y llamadores, pero si la telemetría tiene demasiados nombres de rol en la nube únicos o
demasiados tipos de dependencia, esa agrupación será insuficiente y el mapa no se podrá representar.
Para solucionar este problema, deberá cambiar la instrumentación para establecer correctamente el nombre
de rol en la nube, el tipo de dependencia y los campos de destino de dependencia.
El destino de dependencia debe representar el nombre lógico de una dependencia. En muchos casos,
es equivalente al nombre del servidor o del recurso de la dependencia. Por ejemplo, en el caso de las
dependencias HTTP se establece en el nombre de host. No debe contener id. exclusivos o parámetros
que cambian de una solicitud a otra.
El tipo de dependencia debe representar el tipo lógico de una dependencia. Por ejemplo, HTTP, SQL o
Azure Blob son tipos de dependencia típicos. No debe contener id. exclusivos.
El propósito de nombre de rol en la nube se describe en la sección anterior.
Comentarios del portal

Para proporcionar comentarios, use la opción de comentarios.
Pasos siguientes
Para más información sobre cómo funciona la correlación en Application Insights, consulte el artículo
sobre la correlación de telemetría.
La experiencia de diagnóstico de transacción de un extremo a otro correlaciona la telemetría del lado
servidor con todos los componentes supervisados de Application Insights en una única vista.
En el caso de escenarios avanzados de correlación en ASP.NET Core y ASP.NET, consulte el artículo sobre
seguimiento de operaciones personalizadas.
Diagnósticos de transacción entre componentes
unificados
La experiencia de diagnóstico unificada correlaciona automáticamente la telemetría del lado servidor con
todos los componentes supervisados de Application Insights en una única visualización. No importa si tiene
varios recursos con claves de instrumentación independientes. Application Insights detecta la relación
subyacente y le permite diagnosticar fácilmente el componente, la dependencia o la excepción de la aplicación
que provocaron una ralentización o un error en la transacción.
¿Qué es un componente?
Los componentes son partes que se pueden implementar independientemente de su aplicación de
microservicios o distribuida. Los equipos de operaciones y los desarrolladores pueden ver el código o acceder
a la telemetría que generan estos componentes de la aplicación.
Los componentes son diferentes de las dependencias externas "observadas", como SQL, EventHub, etc. a las
que su equipo u organización no pueden acceder (código o telemetría).
Los componentes se ejecutan en cualquier número de instancias de rol, servidor o contenedor.
Los componentes pueden ser claves de instrumentación de Application Insights independientes (incluso
aunque las suscripciones sean diferentes) o diferentes roles que informan a una única clave de
instrumentación de Application Insights. La nueva experiencia muestra los detalles en todos los
componentes, independientemente de cómo se hayan configurado.
NOTE
¿Faltan los vínculos a elementos relacionados? Todos los datos de telemetría relacionados se encuentran en
las secciones superior e inferior del lado izquierdo.
Experiencia de diagnósticos de la transacción

Esta vista tiene cuatro partes principales: una lista de resultados, un gráfico de transacción entre componentes,
una lista de secuencia de tiempo de todos los datos de telemetría relacionados con esta operación y el panel
de detalles de cualquier elemento de telemetría seleccionado a la izquierda.
Gráfico de transacciones entre componentes
Este gráfico proporciona una escala de tiempo con barras horizontales que muestra la duración de las
solicitudes y las dependencias entre los componentes. Las excepciones que se recopilan también se marcan en
la escala de tiempo.
La fila superior de este gráfico representa el punto de entrada, la solicitud entrante al primer componente
que se llamó en esta transacción. La duración es el tiempo total necesario para que se complete la
transacción.
Las llamadas a las dependencias externas son filas sencillas que no se pueden contraer, con iconos que
representan el tipo de dependencia.
Las llamadas a otros componentes son filas que se pueden contraer. Cada fila corresponde a una operación
específica que se invoca en el componente.
De forma predeterminada, la solicitud, la dependencia o la excepción seleccionadas se muestran en el lado
derecho.
Seleccione cualquier fila para ver sus detalles a la derecha.
NOTE
Las llamadas a otros componentes tienen dos filas: una fila representa la llamada saliente (dependencia) desde el
componente del llamador, y la otra fila corresponde a la solicitud entrante al componente del que recibe la llamada. El
icono inicial y los distintos estilos de las barras de duración le ayudan a diferenciarlos.
Todos los datos de telemetría con este identificador de operación

En esta sección se muestra la vista de lista plana en una secuencia de tiempo de todos los datos de telemetría
relacionados con esta transacción. También se muestran los eventos personalizados y los seguimientos que no
se muestran en el gráfico de transacciones. Puede filtrar esta lista por los datos de telemetría generados por
una llamada o componente específicos. Puede seleccionar cualquier elemento de telemetría en esta lista para
ver sus detalles a la derecha.
Detalles de la telemetría seleccionada
En este panel contraíble se muestran los detalles de cualquier elemento seleccionado del gráfico de
transacciones o de la lista. "Mostrar todo" enumera todos los atributos estándares recopilados. Los atributos
personalizados se muestran por separado después del conjunto estándar. Haga clic en "..." debajo de la ventana
de seguimiento de la pila para obtener una opción para copiar el seguimiento. Las opciones "Open profiler
traces" (Abrir seguimientos de Profiler) o "Abrir instantánea de depuración" muestran los diagnósticos de nivel
de código en los paneles de detalles correspondientes.
Search Results
En este panel contraíble se muestran los otros resultados que cumplen los criterios de filtro. Haga clic en
cualquier resultado para actualizar los detalles correspondientes en las tres secciones enumeradas
anteriormente. Intentamos buscar ejemplos con más probabilidades de tener detalles disponibles de todos los
componentes, aunque el muestreo esté activo en cualquiera de ellos. Se muestran como ejemplos "sugeridos".
Profiler y Snapshot Debugger
Application Insights Profiler y Snapshot Debugger le ayudan a realizar diagnósticos al nivel de código para
conocer los problemas de rendimiento y errores. Con esta experiencia, podrá ver seguimientos de Profiler o
instantáneas de cualquier componente con tan solo un clic.
Si no pudo conseguir que Profiler funcionara, póngase en contacto con
ser viceprofilerhelp@microsoft.com .
Si no pudo conseguir que Snapshot Debugger funcionara, póngase en contacto con
snapshothelp@microsoft.com .

Solo veo un componente en el gráfico y el resto solo se muestran como dependencias externas sin detalles
acerca de lo que sucedió dentro de esos componentes.
Posibles razones:
¿Existen otros componentes instrumentados con Application Insights?
¿Usa la versión más reciente y estable de SDK de Application Insights?
Si estos componentes son recursos independientes de Application Insights, ¿tiene el acceso requerido para
su telemetría?
Si tiene acceso y los componentes se instrumentan con el SDK más reciente de Application Insights, háganoslo
saber a través del canal de comentarios en la parte superior derecha.
Veo filas duplicadas para las dependencias. ¿Es normal?
Por ahora, presentamos la llamada de dependencia de salida de forma independiente de la solicitud entrante.
Por lo general, las dos llamadas son idénticas y solo difiere el valor de duración debido al recorrido de ida y
vuelta. El icono inicial y los distintos estilos de las barras de duración le ayudan a diferenciarlos. ¿Le resulta
confusa esta presentación de los datos? Envíenos sus comentarios.
¿Qué hay de los desfases temporales entre las instancias de los diferentes componentes?
Las escalas de tiempo se ajustan para los desfases temporales en el gráfico de transacciones. Puede ver las
marcas de tiempo exactas en el panel de detalles o con Analytics.
¿Por qué faltan en la nueva experiencia la mayoría de las consultas de elementos relacionadas?
es así por diseño. Todos los elementos relacionados, en todos los componentes, están disponibles en el lado
izquierdo (secciones superior e inferior). La nueva experiencia tiene dos elementos relacionados que no se
tratan en el lado izquierdo: todos los datos de telemetría de los cinco minutos anteriores y posteriores a este
evento y la escala de tiempo del usuario.
Supervisión de la disponibilidad de un
sitio web
Después de haber implementado la aplicación o sitio web, puede configurar pruebas

periódicas para supervisar la disponibilidad y capacidad de respuesta. Azure
Application Insights envía solicitudes web a su aplicación a intervalos regulares
desde puntos de todo el mundo. Puede enviar una alerta si la aplicación no responde
o si responde de manera demasiada lenta.
Puede configurar pruebas de disponibilidad para cualquier punto de conexión HTTP o
HTTPS que sea accesible desde la red pública de Internet. No hace falta realizar
cambios en el sitio web que está probando. De hecho, incluso no hace falta que sea
un sitio de su propiedad. Puede probar la disponibilidad de una API de REST de la
que depende su servicio.
Tipos de pruebas de disponibilidad:
Hay tres tipos de pruebas de disponibilidad:
Prueba de ping de la dirección URL: una prueba sencilla que se puede crear en el
portal de Azure.
Prueba web de varios pasos: una grabación de una secuencia de solicitudes web
que se pueden reproducir para probar los escenarios más complejos. Las pruebas
web de varios pasos se crean en Visual Studio Enterprise y se carga en el portal
para su ejecución.
Pruebas de disponibilidad de seguimiento personalizado: Si decide crear una
aplicación personalizada para ejecutar pruebas de disponibilidad, puede usar el
método TrackAvailability() para enviar los resultados a Application Insights.
Puede crear hasta 100 pruebas de disponibilidad por recurso de

Para crear una prueba de disponibilidad, primero deberá crear un recurso de
Application Insights. Si ya creó un recurso, siga con la siguiente sección para crear
una prueba de ping de dirección URL.
En Azure Portal, seleccione Crear un recurso > Herramientas para
desarrolladores > Application Insights y cree un recurso de Application Insights.
Creación de una prueba de ping de la dirección URL

El nombre "prueba de ping de dirección URL" es un poco inapropiado. Para que
quede claro, esta prueba no usa ICMP (Protocolo de mensajes de control de Internet)
para comprobar la disponibilidad del sitio. En cambio, usa la funcionalidad más
avanzada de solicitud HTTP para validar si un punto de conexión responde. También
mide el rendimiento asociado con esa respuesta y agrega la capacidad de establecer
criterios de éxito personalizados junto con características más avanzadas, como
analizar solicitudes dependientes y permitir reintentos.
Para crear la primera solicitud de disponibilidad, abra el panel Disponibilidad y
seleccione Crear prueba .
Creación de una prueba

URL La dirección URL puede ser cualquier página

web que desee probar, pero debe ser visible
desde la red pública de Internet. La dirección
URL puede incluir una cadena de consulta.
Así, por ejemplo, se puede ejercitar un poco la
base de datos. Si la dirección URL se resuelve
en una redirección, la seguimos, hasta 10
redirecciones.
Analizar solicitudes dependientes La prueba solicitará imágenes, scripts,

archivos de estilo y otros archivos que
forman parte de la página web en pruebas. El
tiempo de respuesta registrado incluye el
tiempo dedicado a obtener estos archivos. La
prueba da error si cualquiera de estos
recursos no se puede descargar
correctamente dentro del tiempo de espera
de la prueba entera. Si la opción no está
activada, la prueba solo solicita el archivo en
la dirección URL que especificó. Si se habilita
esta opción, se realiza una comprobación más
estricta. Podría producirse un error en la
prueba para los casos que puede que no sean
evidentes al examinar el sitio de forma
manual.
Habilitar reintentos cuando la prueba da error, se reintenta tras

un corto intervalo. Se notifica un error
únicamente si los tres intentos sucesivos
producen un error. Las sucesivas pruebas se
realizan según la frecuencia habitual de la
prueba. El reintento se suspende
temporalmente hasta que uno se complete
correctamente. Esta regla se aplica
independientemente en cada ubicación de la
prueba. Se recomienda esta opción .
Como media, cerca del 80 % de los errores
desaparecen al reintentar.
Frecuencia de prueba establece la frecuencia con que se ejecuta la

prueba desde cada ubicación de prueba. Con
una frecuencia predeterminada de cinco
minutos y cinco ubicaciones de prueba, el
sitio se prueba, de media, cada minuto.
Ubicaciones de prueba Son los lugares desde donde nuestros

servidores envían solicitudes web a la
dirección URL. El número mínimo de
ubicaciones de prueba recomendadas
es cinco con el fin de asegurarse de que
puede distinguir los problemas del sitio web
de los problemas de la red. Puede seleccionar
hasta 16 ubicaciones.
Si la dirección URL no es visible desde la red Internet pública, tiene la

opción de abrir selectivamente el firewall para permitir solo las
transacciones de prueba . Para más información sobre las excepciones de firewall
para nuestros agentes de prueba de disponibilidad, consulte la guía de direcciones IP.
NOTE
Se recomienda probar desde varias ubicaciones con un mínimo de cinco ubicaciones .
Esto es para evitar falsas alarmas que pueden deberse a problemas transitorios con una
ubicación específica. Además, hemos descubierto que la configuración óptima es que el
número de ubicaciones de prueba sea igual que el umbral de ubicación de la
aler ta + 2 .
Criterios de éxito
Tiempo de espera de prueba reduzca este valor para recibir una alerta
sobre las respuestas lentas. La prueba se
considera un error si no se han recibido
respuestas de su sitio dentro de este período.
Si seleccionó Analizar solicitudes
dependientes , todas las imágenes, archivos
de estilo, scripts y otros recursos
dependientes se deben haber recibido
durante este período.
Respuesta HTTP el código de estado devuelto que se

considera correcto. 200 es el código que
indica que se ha devuelto una página web
normal.
Coincidencia de contenido Una cadena, como "Bienvenido". Probamos

que se produce una coincidencia exacta entre
mayúsculas y minúsculas en todas las
respuestas. Debe ser una cadena sin formato,
sin caracteres comodín. No se olvide de que si
el contenido cambia, es posible que tenga
que actualizarla. En la coincidencia de
contenido solo se admiten caracteres
en inglés
Alertas
Casi en tiempo real (versión preliminar) Se recomienda usar alertas casi en tiempo
real. La configuración de este tipo de alertas
se realiza después de crear la prueba de
disponibilidad.
Clásico Ya no se recomienda usar alertas clásicas para

nuevas pruebas de disponibilidad.
Umbral de la ubicación de la aler ta se recomienda un mínimo de 3/5 ubicaciones.

La relación óptima entre el umbral de
ubicación de la alerta y el número de
ubicaciones de prueba es umbral de
ubicación de la aler ta = número de
ubicaciones de prueba - 2, con un
mínimo de cinco ubicaciones de
prueba.
Visualización de los resultados de las pruebas de

disponibilidad
Los resultados de la prueba de disponibilidad se pueden visualizar con vistas de línea
o vistas de trazado de dispersión.
Después de unos minutos, haga clic en Actualizar para ver los resultados.
En la vista de dispersión se muestran ejemplos de los resultados de las pruebas, que

incluyen detalles sobre los pasos de las pruebas de diagnóstico. El motor de pruebas
almacena los detalles de diagnóstico de las pruebas con errores. En el caso de las
pruebas correctas, los detalles de diagnóstico se almacenan para un subconjunto de
las ejecuciones. Mantenga el mouse sobre cualquiera de los puntos rojos o verdes
para ver la prueba, el nombre de esta y su ubicación.
Seleccione una prueba o una ubicación determinadas, o bien reduzca el período de
tiempo para ver más resultados del período de tiempo que le interese. Use el
Explorador de búsqueda para ver los resultados de todas las ejecuciones, o use
consultas de Analytics para ejecutar informes personalizados en estos datos.
Inspección y edición de pruebas

Para editar, eliminar o deshabilitar temporalmente una prueba, haga clic en el botón
de puntos suspensivos junto al nombre de la prueba. Pueden tardar hasta 20
minutos para que los cambios se propaguen a todos los agentes de prueba después
de realizar un cambio.
Tal vez le interese deshabilitar las pruebas de disponibilidad o las reglas de alerta
asociadas a ellas mientras esté realizando el mantenimiento del servicio.
Si ve errores
Haga clic en un punto rojo.
Puede ver los detalles de transacción en todos los componentes desde el resultado
de la prueba de disponibilidad. Aquí puede:
Inspeccionar la respuesta recibida desde el servidor.
Diagnosticar errores con la telemetría de lado servidor correlacionada que se
recopiló durante el procesamiento de la prueba de disponibilidad con error.
Registrar un problema o elemento de trabajo en GIT o Azure Boards para realizar
un seguimiento del problema. El error contiene un vínculo a este evento.
Abra el resultado de la prueba web en Visual Studio.
Obtenga más información acerca de la experiencia de diagnósticos de transacción
extremo a extremo aquí.
Haga clic en la fila de excepciones para ver los detalles de la excepción del lado
servidor que ha provocado un error en la prueba de disponibilidad sintética. También
puede obtener la instantánea de depuración para realizar diagnósticos de nivel de
código más completos.
Además de los resultados sin formato, también puede ver dos métricas de
disponibilidad clave en el Explorador de métricas:
1. Disponibilidad: Porcentaje de las pruebas que obtuvieron resultados satisfactorios
en todas las ejecuciones de prueba.
2. Duración de la prueba: Duración media de las pruebas en todas las ejecuciones de
prueba.
Automation
Use scripts de PowerShell para configurar una prueba de disponibilidad
automáticamente.
Configure un webhook que se llama cuando se genera una alerta.
Pasos siguientes
Puede supervisar una secuencia registrada de direcciones URL e interacciones con un sitio web a través de
pruebas web de varios pasos. En este artículo se proporciona una guía paso a paso del proceso de creación de
una prueba web de varios pasos con Visual Studio Enterprise.
NOTE
Las pruebas web de varios pasos dependen de los archivos de pruebas web de Visual Studio. Se anunció que
Visual Studio 2019 será la última versión con la funcionalidad de prueba web. Es importante comprender que, aunque
no se agregarán nuevas características, la funcionalidad de pruebas web de Visual Studio 2019 todavía se admite y se
seguirá admitiendo durante el ciclo de vida de soporte técnico del producto. El equipo de productos de Azure Monitor
ha abordado las preguntas sobre el futuro de las pruebas de disponibilidad de varios pasos aquí.
No se admiten las pruebas web de varios pasos en la nube de Azure Government.
Requisitos previos
Visual Studio 2017 Enterprise posterior.
Herramientas de rendimiento web y pruebas de carga de Visual Studio.
Para encontrar el requisito de las herramientas de prueba. Inicie el Instalador de Visual Studio >
Componentes individuales > Depuración y pruebas > Herramientas de rendimiento web y
pruebas de carga .
NOTE
Las pruebas web de varios pasos tienen costes adicionales asociados. Para más información, consulte la guía oficial de
precios.
Registro de una prueba web de varios pasos

WARNING
Ya no se recomienda usar la grabadora de varios pasos. La grabadora se desarrolló para páginas HTML estáticas con
interacciones básicas y no proporciona una experiencia funcional para páginas web modernas.
Para obtener instrucciones sobre cómo crear pruebas web de Visual Studio, consulte la documentación oficial
de Visual Studio 2019.
Carga de la prueba web

1. En el portal de Application Insights, en el panel Disponibilidad, seleccione Crear prueba > Tipo de
prueba > Prueba web de varios pasos .
2. Establezca las ubicaciones de prueba, la frecuencia y los parámetros de alerta.
Frecuencia y ubicación
Frecuencia de prueba establece la frecuencia con que se ejecuta la prueba desde

cada ubicación de prueba. Con una frecuencia
predeterminada de cinco minutos y cinco ubicaciones de
prueba, el sitio se prueba, de media, cada minuto.
Ubicaciones de prueba Son los lugares desde donde nuestros servidores envían
solicitudes web a la dirección URL. El número mínimo de
ubicaciones de prueba recomendadas es cinco con el
fin de asegurarse de que puede distinguir los problemas del
sitio web de los problemas de la red. Puede seleccionar
hasta 16 ubicaciones.
Criterios de éxito
Tiempo de espera de prueba reduzca este valor para recibir una alerta sobre las
respuestas lentas. La prueba se considera un error si no se
han recibido respuestas de su sitio dentro de este período.
Si seleccionó Analizar solicitudes dependientes , todas
las imágenes, archivos de estilo, scripts y otros recursos
dependientes se deben haber recibido durante este
período.
Respuesta HTTP el código de estado devuelto que se considera correcto.

200 es el código que indica que se ha devuelto una página
web normal.
Coincidencia de contenido Una cadena, como "Bienvenido". Probamos que se produce

una coincidencia exacta entre mayúsculas y minúsculas en
todas las respuestas. Debe ser una cadena sin formato, sin
caracteres comodín. No se olvide de que si el contenido
cambia, es posible que tenga que actualizarla. En la
coincidencia de contenido solo se admiten
caracteres en inglés
Alertas
Casi en tiempo real (versión preliminar) Se recomienda usar alertas casi en tiempo real. La
configuración de este tipo de alertas se realiza después de
crear la prueba de disponibilidad.
Clásico Ya no se recomienda usar alertas clásicas para nuevas

Umbral de la ubicación de la aler ta se recomienda un mínimo de 3/5 ubicaciones. La relación

óptima entre el umbral de ubicación de la alerta y el
número de ubicaciones de prueba es umbral de
ubicación de la aler ta = número de ubicaciones de
prueba - 2, con un mínimo de cinco ubicaciones de
prueba.
Configuración
Inserción de números de tiempo y aleatorios en la prueba
Suponga que está probando una herramienta que obtiene datos que dependen del tiempo, como acciones de
una fuente externa. Cuando se graba la prueba web, debe utilizar horas específicas, pero las establece como
parámetros de la prueba, StartTime y EndTime.
Al ejecutar la prueba, le gustaría que EndTime fuera siempre la hora actual y que StartTime fuera 15 minutos
menos.
El complemento de hora y fecha de prueba web proporciona la manera de controlar los tiempos de
parametrización.
1. Agregue un complemento de prueba de web a cada valor variable que desee. En la barra de
herramientas de pruebas web, elija Agregar complemento de prueba web .
En este ejemplo, usamos dos instancias del complemento Date Time Plug-in. Una instancia es para
"hace 15 minutos" y otra para "ahora".
2. Abra las propiedades de cada complemento. Asígnele un nombre y configúrelo para utilizar la hora
actual. En cada uno de ellos, establezca Añadir minutos = -15.
3. En los parámetros de prueba en la web, utilice {{plug-in name}} para hacer referencia al nombre de un
complemento.
Ahora puede cargar la prueba en el portal. Utilizará los valores dinámicos en cada ejecución de la prueba.
Tratamiento del inicio de sesión
Si los usuarios inician sesión en la aplicación, tiene varias opciones para simular el inicio de sesión a fin de
poder probar páginas detrás del inicio de sesión. El enfoque que utilice dependerá del tipo de seguridad
proporcionada por la aplicación.
En todos los casos, debe crear una cuenta en su aplicación para realizar pruebas. Si es posible, restrinja los
permisos de esta cuenta de prueba para que sea totalmente imposible que las pruebas web afecten a usuarios
reales.
Nombre de usuario y la contraseña simples : grabar una prueba web de la manera habitual. Elimine las
cookies en primer lugar.
Autenticación SAML
N O M B RE DE P RO P IEDA D DESC RIP C IÓ N
URI de audiencia El URI de audiencia para el token SAML. Se trata del URI
para Access Control Service (ACS), incluido el nombre de
host y el espacio de nombres de ACS.
Contraseña de certificado La contraseña del certificado de cliente que concederá

acceso a la clave privada insertada.
Certificado de cliente El valor del certificado de cliente con una clave privada en
formato codificado en Base64.
Identificador de nombre El identificador de nombre del token.
No después de El intervalo de tiempo durante el cual será válido el token. El

valor predeterminado es 5 minutos.
No antes de El intervalo de tiempo durante el cual será válido un token

creado en el pasado (para abordar el desfase horario). El
valor predeterminado es (negativo) 5 minutos.
Nombre de parámetro de contexto de destino El parámetro de contexto que recibirá la aserción generada.
Secreto del cliente : si la aplicación tiene una ruta de inicio de sesión que implica un secreto de cliente, úsela.
Azure Active Directory (AAD) es un ejemplo de un servicio que proporciona inicio de sesión del secreto de
cliente. En AAD, el secreto de cliente es la clave de la aplicación.
Esta es una prueba web de ejemplo de una aplicación web de Azure que usa una clave de aplicación:
Obtener el token de AAD mediante el secreto de cliente (AppKey). Extraer el token de portador de la respuesta.
Llamar a la API mediante el token de portador del encabezado de la autorización. Asegúrese de que la prueba
web sea un cliente real (es decir, tiene su propia aplicación en AAD) y use su clientId + appkey. El servicio que
se prueba también tiene su propia aplicación en AAD: el identificador URI de esta aplicación, appID, se refleja
en la prueba web en el campo "resource".
Autenticación abierta
Un ejemplo de autenticación abierta es el iniciar sesión con una cuenta de Microsoft o Google. Muchas
aplicaciones que utilizan OAuth proporcionan la alternativa del secreto de cliente, por lo que la primera táctica
sería investigar dicha posibilidad.
Si la prueba debe iniciar sesión con OAuth, el enfoque general es el siguiente:
Utilice una herramienta como Fiddler para examinar el tráfico entre el explorador web, el sitio de autenticación
y la aplicación. Realice dos o más inicios de sesión mediante distintas máquinas o exploradores o en intervalos
largos de tiempo (para permitir que los tokens expiren). Mediante la comparación de diferentes sesiones,
identifique el token pasado desde el sitio de autenticación que, a continuación, se pasa al servidor de
aplicaciones después de iniciar sesión. Grabe una prueba web con Visual Studio. Parametrice los tokens,
estableciendo el parámetro cuando se devuelve el token desde el autenticador y utilizándolo en la consulta al
sitio. (Visual Studio intenta parametrizar la prueba pero no parametriza correctamente los tokens).
Pasos siguientes
Pruebas web de ping de URL
Creación y ejecución de pruebas de disponibilidad
personalizadas mediante Azure Functions
En este artículo se explica cómo crear una función de Azure con TrackAvailability() que se ejecutará periódicamente
según la configuración especificada en la función TimerTrigger con lógica de negocios propia. Los resultados de
esta prueba se enviarán al recurso de Application Insights, donde podrá consultar los datos de los resultados de
disponibilidad y generar alertas sobre ellos. Esto le permite crear pruebas personalizadas de forma parecida a lo
que puede hacer mediante Supervisión de la disponibilidad en el portal. Las pruebas personalizadas le permitirán
escribir pruebas de disponibilidad más complejas de las que puede crear con la interfaz de usuario del portal,
supervisar una aplicación dentro de la red virtual de Azure, cambiar la dirección del punto de conexión o crear una
prueba de disponibilidad incluso si esta característica no está disponible en su región.
NOTE
Este ejemplo se ha diseñado únicamente para mostrar la mecánica de cómo actúa la llamada a la API de TrackAvailability() en
una función de Azure. No muestra cómo se escribe el código de prueba HTTP o la lógica de negocios subyacentes que se
necesitarían para convertir esta llamada en una prueba de disponibilidad totalmente funcional. De forma predeterminada, si
recorre este ejemplo, creará una prueba de disponibilidad que siempre generará un error.
Creación de una función desencadenada por el temporizador

Si tiene un recurso de Application Insights:
De forma predeterminada Azure Functions crea un recurso de Application Insights, pero si desea usar
uno de los recursos que ya ha creado, deberá especificarlo durante la creación.
Siga las instrucciones sobre cómo crear un recurso de Azure Functions y una función desencadenada por
el temporizador (detener antes de la limpieza) con las siguientes opciones.
Seleccione la pestaña Super visión situada cerca de la parte superior.
Seleccione el cuadro desplegable Application Insights y escriba o seleccione el nombre del
recurso.
Seleccionar Revisar y crear .
Si aún no tiene un recurso de Application Insights creado para la función desencadenada por el temporizador:
De forma predeterminada, si crea una aplicación de Azure Functions, se creará un recurso de Application
Insights.
Siga las instrucciones sobre cómo crear un recurso de Azure Functions y una función desencadenada por
el temporizador (detener antes de la limpieza).
Código de ejemplo
Copie el código siguiente en el archivo run.csx (esto reemplazará el código ya existente). Para ello, vaya a la
aplicación Azure Functions y seleccione la función de desencadenador de temporizador a la izquierda.
NOTE
Para la dirección del punto de conexión debería usar:
EndpointAddress= https://dc.services.visualstudio.com/v2/track . A menos que el recurso se encuentre en una
región como Azure Government o Azure China, en cuyo caso consulte este artículo sobre sustitución de los puntos de
conexión predeterminados, seleccione el punto de conexión adecuado del canal de telemetría de su región.
#load "runAvailabilityTest.csx"
using System;
using System.Diagnostics;
// The Application Insights Instrumentation Key can be changed by going to the overview page of your Function
App, selecting configuration, and changing the value of the APPINSIGHTS_INSTRUMENTATIONKEY Application setting.
// DO NOT replace the code below with your instrumentation key, the key's value is pulled from the environment
variable/application setting key/value pair.
private static readonly string instrumentationKey =
Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY");
//[CONFIGURATION_REQUIRED]
// If your resource is in a region like Azure Government or Azure China, change the endpoint address
accordingly.
// Visit https://docs.microsoft.com/azure/azure-monitor/app/custom-endpoints#regions-that-require-endpoint-
modification for more details.
private const string EndpointAddress = "https://dc.services.visualstudio.com/v2/track";
private static readonly TelemetryConfiguration telemetryConfiguration = new

TelemetryConfiguration(instrumentationKey, new InMemoryChannel { EndpointAddress = EndpointAddress });
private static readonly TelemetryClient telemetryClient = new TelemetryClient(telemetryConfiguration);
public async static Task Run(TimerInfo myTimer, ILogger log)

{
log.LogInformation($"Entering Run at: {DateTime.Now}");
if (myTimer.IsPastDue)
{
log.LogWarning($"[Warning]: Timer is running late! Last ran at: {myTimer.ScheduleStatus.Last}");
}
// [CONFIGURATION_REQUIRED] provide {testName} accordingly for your test function

string testName = "AvailabilityTestFunction";
// REGION_NAME is a default environment variable that comes with App Service

string location = Environment.GetEnvironmentVariable("REGION_NAME");
log.LogInformation($"Executing availability test run for {testName} at: {DateTime.Now}");

string operationId = Guid.NewGuid().ToString("N");
var availability = new AvailabilityTelemetry

{
Id = operationId,
Name = testName,
RunLocation = location,
Success = false
};
var stopwatch = new Stopwatch();

stopwatch.Start();
try
{
await RunAvailbiltyTestAsync(log);
availability.Success = true;
}
{
availability.Message = ex.Message;
var exceptionTelemetry = new ExceptionTelemetry(ex);

exceptionTelemetry.Context.Operation.Id = operationId;
exceptionTelemetry.Properties.Add("TestName", testName);
exceptionTelemetry.Properties.Add("TestLocation", location);
telemetryClient.TrackException(exceptionTelemetry);
}
finally
{
stopwatch.Stop();
availability.Duration = stopwatch.Elapsed;
availability.Timestamp = DateTimeOffset.UtcNow;
telemetryClient.TrackAvailability(availability);
// call flush to ensure telemetry is sent
}
}
En la derecha, debajo de Ver archivos, seleccione Agregar . Llame al nuevo archivo function.proj con la
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.8.2" /> 
</ItemGroup>
</Project>
En la derecha, debajo de Ver archivos, seleccione Agregar . Llame al nuevo archivo runAvailabilityTest.csx con la
public async static Task RunAvailbiltyTestAsync(ILogger log)

{
// Add your business logic here.
throw new NotImplementedException();
}
Comprobación de la disponibilidad
Para asegurarse de que todo funciona, puede examinar el gráfico de la pestaña Disponibilidad del recurso de
NOTE
Si ha implementado su propia lógica de negocios en runAvailabilityTest.csx, verá resultados correctos como en las capturas de
pantallas siguientes; si no lo hizo, verá resultados con errores. Las pruebas creadas con TrackAvailability() aparecerán
con CUSTOM junto al nombre de la prueba.
Para ver los detalles de la transacción completa, seleccione Correcto o Erróneo en Aumentar detalle y, a
continuación, seleccione un ejemplo. También puede obtener los detalles de la transacción de un extremo a otro
seleccionando un punto de datos en el gráfico.
Si ejecutó todo tal cual (sin agregar lógica de negocios), verá que se produjo un error en la prueba.
Consulta en Registros (Analytics)
Puede usar registros (Analytics) para ver los resultados de disponibilidad, dependencias, etc. Para más información
acerca de los registros, visite Introducción a las consultas de registros.
Pasos siguientes
Mapa de aplicación
Azure Application Insights envía solicitudes web a su aplicación a intervalos regulares desde puntos de todo el
mundo. Puede enviar una alerta si la aplicación no responde o si responde de manera demasiada lenta.
Habilitación de alertas
Las alertas ahora se habilitan automáticamente de forma predeterminada, pero para configurar por completo la
alerta, primero debe crear inicialmente la prueba de disponibilidad.
NOTE
Con las nuevas alertas unificadas, la gravedad de la regla de alertas y las preferencias de notificación con grupos de
accionesse tienen que configurar en la experiencia de alertas. Sin los pasos siguientes, solo recibirá las notificaciones del
portal.
1. Después de guardar la prueba de disponibilidad, en la pestaña de detalles, haga clic en el signo de puntos
suspensivos junto a la prueba que acaba de realizar. Haga clic en “Editar alerta”.
2. Establezca el nivel de gravedad deseado, la descripción de la regla y lo más importante: el grupo de
acciones con las preferencias de notificación que le gustaría usar para esta regla de alertas.
NOTE
Las alertas de disponibilidad creadas a través de esta experiencia están basadas en el estado. Esto significa que, cuando se
cumplan los criterios de alerta, se generará una única alerta cuando el sitio se detecte como no disponible. Si el sitio sigue
fuera de servicio la próxima vez que se evalúen los criterios de alerta, no se generará una nueva alerta. Por lo tanto, si el sitio
estuvo fuera de servicio durante una hora y había configurado una alerta de correo electrónico, solo recibiría un correo
electrónico cuando el sitio estuviera fuera de servicio y un correo electrónico posterior cuando se realizara una copia de
seguridad del sitio. No recibiría alertas continuas recordándole que el sitio seguía sin estar disponible.
Alertas para X de las Y ubicaciones que notifican errores

La regla de alertas X de las Y ubicaciones se habilita de forma predeterminada en la nueva experiencia de alertas
unificadas cuando se crea una prueba de disponibilidad. Puede cancelar esta acción si selecciona la opción
"clásica" o si deshabilita la regla de alertas.
NOTE
Siga los pasos anteriores para configurar los grupos de acción para recibir notificaciones cuando se desencadene la alerta. Sin
este paso, solo recibirá las notificaciones en el portal cuando se desencadene la regla.
Alertas sobre las métricas de disponibilidad

Mediante las nuevas alertas unificadas, también puede generar alertas sobre la disponibilidad total segmentada y
las métricas de duración de la prueba:
1. Seleccione un recurso de Application Insights en la experiencia de métricas y seleccione una métrica de
disponibilidad:
2. Al configurar la opción de alertas desde el menú se abrirá la nueva experiencia, donde podrá seleccionar
pruebas o ubicaciones específicas para establecer la regla de alertas. También puede configurar los grupos
de acciones para esta regla de alertas.
Alertas sobre las consultas de análisis personalizadas
Mediante las nuevas alertas unificadas, puede generar alertas sobre las consultas de registro personalizadas. Con
las consultas personalizadas, puede enviar alertas sobre cualquier condición arbitraria que le ayude a obtener los
indicadores de problemas de disponibilidad más fiables. Esta opción también la puede usar si envía resultados
personalizados de disponibilidad mediante el SDK de TrackAvailability.
TIP
Las métricas sobre datos de disponibilidad incluyen los resultados personalizados de disponibilidad que puede enviar
mediante una llamada a nuestro SDK de TrackAvailability. Puede usar la compatibilidad con las alertas sobre métricas para
generar alertas sobre resultados personalizados de disponibilidad.
Automatización de alertas
Para automatizar este proceso con plantillas de Azure Resource Manager, consulte la documentación relativa a la
creación de una alerta de métrica con una plantilla de Resource Manager.
Pasos siguientes
Pruebas web de ping de URL
Pruebas de rendimiento
NOTE
El servicio de prueba de carga basado en la nube ha quedado en desuso. Puede encontrar más información sobre el desuso,
la disponibilidad del servicio y servicios alternativos aquí.
Application Insights le permite generar pruebas de carga para sus sitios web. Al igual que las pruebas de
disponibilidad, puede enviar solicitudes básicas o solicitudes de varios pasos desde agentes de prueba de Azure de
todo el mundo. Las pruebas de rendimiento le permiten simular hasta 20 000 usuarios simultáneos durante 60
minutos.

Para crear una prueba de rendimiento, primero deberá crear un recurso de Application Insights. Si ya ha creado un
recurso, continúe con la siguiente sección.
En Azure Portal, seleccione Crear un recurso > Herramientas para desarrolladores > Application Insights
y cree un recurso de Application Insights.
Configuración de pruebas de rendimiento

Si es la primera vez que crea una prueba de rendimiento, seleccione Establecer la organización y elija una
organización de Azure DevOps como el origen para las pruebas de rendimiento.
En Configurar , vaya a Pruebas de rendimiento y haga clic en Nuevo para crear una prueba.
Para crear una prueba de rendimiento básica, seleccione un tipo de prueba de Prueba manual y rellene las
opciones que desee para la prueba.
C O N F IGURA C IÓ N VA LO R M Á XIM O
Carga de usuarios 20.000
Duración (minutos) 60
Después de crea la prueba, haga clic en Ejecutar prueba .

Una vez completada la prueba, verá los resultados con un aspecto similares al siguiente:
Configuración de la prueba web de Visual Studio
Las capacidades de pruebas de rendimiento avanzadas de Application Insights se basan en los proyectos de prueba
de rendimiento y carga de Visual Studio.
Pasos siguientes
Pruebas de ping de dirección URL
En este artículo se proporciona ayuda para solucionar problemas comunes que pueden producirse al usar la
supervisión de disponibilidad.
Errores SSL o TLS

SÍN TO M A / M EN SA JE DE ERRO R C A USA S P O SIB L ES
No se pudo crear el canal SSL o TLS seguro Versión de SSL. Solo se admiten TLS 1.0, 1.1 y 1.2. SSLv3 no
se admite.
Capa de registro de TLSv1.2: Alerta (Nivel: irrecuperable, Consulte la conversación sobre StackExchange para más
Descripción: registro MAC incorrecto) información.
La dirección URL en la que se produce un error se encuentra Esto puede deberse a una configuración incorrecta en la red
en una red CDN (Content Delivery Network) CDN
Posible solución alternativa

Si las direcciones URL que presentan el problema son siempre a recursos dependientes, se recomienda
deshabilitar la opción Analizar solicitudes dependientes para la prueba web.
La prueba muestra un error solo desde determinadas ubicaciones

SÍN TO M A / M EN SA JE DE ERRO R C A USA S P O SIB L ES
Se produjo un error en el intento de conexión porque la Un firewall está bloqueando los agentes de prueba en
parte conectada no respondió correctamente después de un determinadas ubicaciones.
período de tiempo
Se están redirigiendo determinadas direcciones IP a través de

equilibradores de carga, administradores de tráfico geográfico
o Azure Express Route.
Si usa Azure ExpressRoute, hay escenarios en los que los

paquetes se podrían descartar cuando se produce un
enrutamiento asimétrico.
Error de prueba con un error de infracción de protocolo.

SÍN TO M A / M EN SA JE DE ERRO R C A USA S P O SIB L ES P O SIB L ES RESO L UC IO N ES
SÍN TO M A / M EN SA JE DE ERRO R C A USA S P O SIB L ES P O SIB L ES RESO L UC IO N ES
El servidor confirmó una infracción del Esto sucede cuando se detectan a. Póngase en contacto con el
protocolo. Section=ResponseHeader encabezados mal formados. En proveedor del host del sitio web o el
Detail=CR debe ir seguido de LF. concreto, algunos encabezados podrían proveedor de CDN para corregir los
no estar usando CRLF para indicar el servidores con errores.
final de línea, lo que provoca una b. En caso de que las solicitudes con
infracción de la especificación HTTP. error sean recursos (p. ej., archivos de
Application Insights aplica esta estilo, imágenes o scripts), puede
especificación HTTP y devuelve errores considerar la posibilidad de deshabilitar
para las respuestas que tienen el análisis de las solicitudes
encabezados con un formato dependientes. Tenga en cuenta que, si
incorrecto. lo hace, perderá la capacidad de
supervisar la disponibilidad de esos
archivos.
NOTE
La dirección URL podría no dar error en los exploradores que tienen una validación poco minuciosa de encabezados HTTP.
Consulte esta entrada del blog para obtener una explicación detallada del problema: http://mehdi.me/a-tale-of-debugging-
the-linkedin-api-net-and-http-protocol-violations/
Preguntas habituales sobre la solución de problemas

Este sitio parece correcto, pero se ven errores de pruebas. ¿Por qué recibo alertas de Application Insights?
¿La prueba tiene habilitada la opción Analizar solicitudes dependientes ? Esta opción da como
resultado una comprobación estricta de los recursos, como las secuencias de comandos y las imágenes,
entre otros. Estos tipos de errores pueden no ser visibles en un explorador. Compruebe todas las
imágenes, los scripts, las hojas de estilo y cualquier otro archivo cargado que haya cargado la página. Si se
produce un error en cualquiera de ellos, se notifica que la prueba ha concluido con errores, incluso si la
página HTML principal se carga correctamente. Para reducir la sensibilidad de la prueba para tales errores
de recursos, simplemente desactive la opción "Analizar las solicitudes dependientes" de la configuración
de pruebas.
Para reducir las probabilidades de ruido de señales de red transitorias etc., asegúrese de que se
compruebe la configuración "Habilitar reintentos para errores de pruebas". También puede realizar
pruebas desde más ubicaciones y administrar el umbral de la regla de alertas en consecuencia para evitar
problemas específicos de ubicación que causan las alertas innecesarias.
Haga clic en cualquiera de los puntos rojos de la experiencia de disponibilidad o en cualquier error de
disponibilidad desde el Explorador de búsqueda para ver los detalles de por qué se notificó el error. El
resultado de la prueba, junto con la telemetría del lado servidor correlacionada (si la opción está
habilitada) ayudará a comprender el motivo del error de la prueba. Los problemas de conexión o red son
las causas más comunes de los problemas transitorios.
¿Se agotó el tiempo de espera de la prueba? Las pruebas se anulan después de 2 minutos. Si la prueba de
ping o de varios pasos tarda más de 2 minutos, se notificará como un error. Considere la posibilidad de
dividir la prueba en varias partes más pequeñas que puedan completarse en lapsos más cortos.
¿Todas las ubicaciones ha informado de un error, o solo algunas de ellas? Si solo algunas informan de
errores, puede ser debido a problemas de red o CDN. De nuevo, hacer clic en los puntos rojos debe ayudar
a entender por qué la ubicación notifica errores.
No recibí ningún correo electrónico cuando la alerta se desencadenó, se resolvió, o ambos.
Compruebe la configuración de alertas clásicas para confirmar que su correo electrónico aparezca directamente
en la lista, o que la lista de distribución en la que se encuentra esté configurada para recibir notificaciones. De ser
así, compruebe la configuración de la lista de distribución para confirmar que puede recibir mensajes de correo
electrónico externos. Compruebe también si el administrador de correo tiene configurada alguna directiva que
pueda estar causando este problema.
No recibí la notificación de webhook.
Compruebe que la aplicación que recibe la notificación de webhook esté disponible y procese correctamente las
solicitudes de webhook. Para obtener más información, consulte este artículo.
Obtengo errores 403 Prohibido, ¿qué significa esto?
Este error indica que es necesario agregar excepciones de firewall para permitir que los agentes de disponibilidad
prueben la dirección URL de destino. Para obtener una lista completa de las direcciones IP del agente admitidas,
consulte el artículo sobre excepciones de IP.
Error de prueba intermitente con un error de infracción de protocolo.
El error ("infracción del protocolo... CR debe ir seguido de LF") indica un problema con el servidor (o las
dependencias). Aparece cuando se establecen los encabezados con formato incorrecto en la respuesta. Puede
deberse a equilibradores de carga o CDN. En concreto, algunos encabezados podrían no estar usando CRLF para
indicar el final de línea, lo que provoca una infracción de la especificación del HTTP y, por tanto, no superan la
validación en el nivel de WebRequest de .NET. Inspeccione la respuesta para detectar encabezados que podrían
estar cometiendo una infracción.
NOTE
La dirección URL podría no dar error en los exploradores que tienen una validación poco minuciosa de encabezados HTTP.
Consulte esta entrada del blog para obtener una explicación detallada del problema: http://mehdi.me/a-tale-of-debugging-
the-linkedin-api-net-and-http-protocol-violations/
No veo telemetría de servidor relacionada para diagnosticar errores de pruebas.

Si tiene Application Insights configurado para la aplicación de servidor, esto puede deberse a que se está llevando
a cabo un muestreo. Seleccione un resultado de disponibilidad diferente.
¿Puedo llamar a código desde mi prueba web?
No. Los pasos de la prueba deben encontrarse en el archivo .webtest. Y no se puede llamar a otras pruebas web
ni utilizar bucles. Pero hay varios complementos que pueden resultarle útiles.
¿Existe alguna diferencia entre las "pruebas web" y las "pruebas de disponibilidad"?
Los dos términos se pueden usar indistintamente. El término "pruebas de disponibilidad" es más genérico, e
incluye las pruebas de ping de dirección URL única y las pruebas web de varios pasos.
Me gustaría usar pruebas de disponibilidad en nuestro servidor interno que se ejecuta detrás de un firewall.
Hay dos soluciones posibles:
Configure el firewall para que permita las solicitudes entrantes de las direcciones IP de los agentes de prueba
web.
Escriba su propio código para comprobar periódicamente el servidor interno. Ejecute el código como un
proceso en segundo plano en un servidor de prueba detrás del firewall. El proceso de prueba puede enviar
sus resultados a Application Insights mediante la API TrackAvailability() en el paquete de SDK principal. Para
ello, es necesario que el servidor de prueba tenga acceso saliente al punto de conexión de ingesta de
Application Insights, pero plantea un riesgo de seguridad mucho menor que la alternativa de permitir las
solicitudes entrantes. Los resultados aparecerán en las hojas de pruebas web de disponibilidad, aunque la
experiencia se verá ligeramente simplificada con respecto a lo que está disponible para las pruebas creadas
mediante el portal. Las pruebas de disponibilidad personalizadas también aparecerán como resultados de
disponibilidad en los análisis, las búsquedas y las métricas.
Al cargar una prueba web de varios pasos, se produce un error
Algunas razones por las que puede ocurrir:
Hay un límite de tamaño de 300 000.
No se admiten los bucles.
No se admiten referencias a otras pruebas web.
No se admiten orígenes de datos.
No se completa la prueba de varios pasos
Hay un límite de 100 solicitudes por prueba. Además, la prueba se detiene si se ejecuta durante más de dos
minutos.
¿Cómo se puede ejecutar una prueba con certificados de cliente?
Actualmente no se admite.
¿Quién recibe las notificaciones de alerta (clásicas)?

Esta sección solo se aplica a las alertas clásicas y le ayudará a optimizar las notificaciones de alerta para
asegurarse de que solo reciban las notificaciones los destinatarios que elija. Para más información sobre la
diferencia entre alertas clásicas y la nueva experiencia de alertas, consulte el artículo de información general de
alertas. Para controlar las notificaciones de alertas en la nueva experiencia de alertas, use grupos de acciones.
Se recomienda el uso de destinatarios específicos para las notificaciones de alerta clásicas.
Si está habilitada la opción de casilla de verificación masiva o grupo , las alertas sobre errores enviadas
desde X de Y ubicaciones se envían a los usuarios con roles de administrador o coadministrador.
Básicamente todos los administradores de la suscripción recibirán notificaciones.
Si está habilitada la opción de casilla masiva o grupo , las alertas sobre las métricas de disponibilidad se
envían a los usuarios con roles de propietario, colaborador o lector de la suscripción. De hecho, todos los
usuarios con acceso a la suscripción del recurso de Application Insights están dentro del ámbito y
recibirán notificaciones.
NOTE
Si actualmente usa la opción de casilla de verificación masiva o grupo y la deshabilita, no podrá revertir el cambio.
Use la nueva experiencia de alertas o las alertas prácticamente en tiempo real si tiene que enviar notificaciones a
los usuarios según sus roles. Con los grupos de acciones, puede configurar el envío de notificaciones por correo
electrónico a usuarios con cualquiera de los roles de propietario, colaborador o lector (no combinados
conjuntamente como única opción).
Pasos siguientes
Pruebas de ping de dirección URL
¿Qué es el seguimiento distribuido?
La llegada de las modernas arquitecturas de microservicios y en la nube ha dado lugar a servicios simples que
se pueden implementar de forma independiente y que pueden ayudar a reducir los costos al tiempo que
aumentan la disponibilidad y el rendimiento. Pero aunque estos movimientos han hecho más fáciles de
entender los servicios individuales como un todo, se han creado sistemas que en general son más difíciles de
analizar y depurar.
En las arquitecturas monolíticas, nos hemos acostumbrado a depurar con pilas de llamadas. Las pilas de
llamadas son excelentes herramientas para mostrar el flujo de ejecución (el método A llama al método B y este
al método C), junto con detalles y parámetros sobre cada una de esas llamadas. Esto es fantástico para
estructuras monolíticas o servicios que se ejecutan en un único proceso, pero ¿cómo se depura cuando la
llamada se produce fuera de los límites de un proceso y no es simplemente una referencia en la pila local?
Aquí entra en juego el seguimiento distribuido.
El seguimiento distribuido es el equivalente de las pilas de llamadas para arquitecturas de microservicios y en
la nube modernas, junto con un generador de perfiles de rendimiento simple. En Azure Monitor, se
proporcionan dos experiencias para consumir datos de seguimiento distribuido. La primera es la vista de
diagnósticos de transacción, que es como una pila de llamadas con una dimensión de tiempo adicional. La vista
de diagnósticos de transacción proporciona visibilidad sobre una sola transacción o solicitud y resulta útil para
encontrar la causa raíz de problemas de confiabilidad y cuellos de botella de rendimiento por cada solicitud.
Azure Monitor ofrece también una vista de mapa de aplicación que agrega muchas transacciones para mostrar
una vista topológica de cómo interactúan los sistemas y cuáles son las tasas promedio de rendimiento y de
errores.
Cómo habilitar el seguimiento distribuido

Habilitar el seguimiento distribuido de los servicios de una aplicación es tan simple como agregar el agente, el
SDK o la biblioteca adecuados a cada servicio, en función del lenguaje en el que se implementó el servicio.
Habilitación mediante Application Insights a través de la

instrumentación automática o SDK
Los SDK o agentes de Application Insights para .NET, .NET Core, Java, Node.js y JavaScript admiten el
seguimiento distribuido de forma nativa. Las instrucciones para instalar y configurar cada SDK de Application
Insights están disponibles a continuación:
.NET
.NET Core
Java
Node.js
JavaScript
Python
Con el SDK de Application Insights adecuado instalado y configurado, la información de seguimiento se
recopila automáticamente para los marcos de trabajo, bibliotecas y tecnologías más populares mediante los
auto-recopiladores de dependencias del SDK. La lista completa de las tecnologías compatibles está disponible
en la documentación de la recopilación automática de dependencias.
Además, se puede realizar el seguimiento manual de cualquier tecnología con una llamada a TrackDependency
en TelemetryClient.
Habilitación mediante OpenCensus

Además de los SDK de Application Insights, Application Insights también admite el seguimiento distribuido
mediante OpenCensus. OpenCensus es una distribución de bibliotecas de código abierto e independiente del
proveedor que proporciona recopilación de métricas y seguimiento distribuido para los servicios. También
permite a la comunidad de código abierto habilitar el seguimiento distribuido con tecnologías conocidas como
Redis, Memcached o MongoDB. Microsoft colabora en OpenCensus junto con varios otros asociados de
supervisión y en la nube.
Python
El sitio web de OpenCensus mantiene la documentación de referencia de la API para Python y Go, así como
diversas guías para el uso de OpenCensus.
Pasos siguientes
Guía de uso de Python de OpenCensus
Mapa de aplicación
Correlación de Telemetría en Application Insights
En el mundo de los microservicios, todas las operaciones lógicas requieren que el trabajo se realice en diversos
componentes del servicio. Puede supervisar cada uno de estos componentes por separado mediante Application
Insights. Application Insights admite la correlación de telemetría distribuida, que se usa para detectar el
componente que es responsable de los errores o de una degradación del rendimiento.
Este artículo explica el modelo de datos utilizado por Application Insights para poner en correlación la telemetría
enviada por varios componentes. También se explican los protocolos y las técnicas de propagación contextual, así
como la implementación de tácticas de correlación en distintos lenguajes y plataformas.
Modelo de datos de correlación de telemetría

Application Insights define el modelo de datos para la correlación de telemetría distribuida. Para asociar la
telemetría con una operación lógica, todos los elementos de telemetría tienen el campo de contexto denominado
operation_Id . Todos los elementos de telemetría comparten este identificador en el seguimiento distribuido. De
este modo, aun si pierde telemetría desde una sola capa, se pueden seguir asociando los datos telemétricos
notificados por otros componentes.
Habitualmente, una operación lógica distribuida consta de un conjunto de operaciones más pequeñas, que son
solicitudes que se procesan en uno de los componentes. Estas operaciones se definen mediante telemetría de
solicitudes. Cada elemento de telemetría de solicitudes cuenta con su propio id , que lo identifica de manera global
e inequívoca. Además, todos los elementos de telemetría (como los seguimientos y las excepciones) que están
asociados a la solicitud deben establecer operation_parentId en el valor de la solicitud id .
La telemetría de dependencias representa a todas las operaciones salientes, como una llamada HTTP a otro
componente. La telemetría de dependencia también define su propio id , que es globalmente único. La telemetría
de solicitudes, que se inicia mediante esta llamada de dependencia, utiliza este id como su operation_parentId .
Puede crear una vista de la operación lógica distribuida usando operation_Id , operation_parentId y request.id
con dependency.id . Estos campos también definen el orden de causalidad de las llamadas de telemetría.
En el entorno de los microservicios, los seguimientos de componentes pueden ir a distintos elementos de
almacenamiento. Cada componente puede tener su propia clave de instrumentación en Application Insights. Para
obtener la telemetría de la operación lógica, Application Insights consulta los datos de cada elemento de
almacenamiento. Si el número de elementos de almacenamiento es grande, necesitará una pista para saber dónde
debe mirar a continuación. El modelo de datos de Application Insights define dos campos, request.source y
dependency.target , para solucionar este problema. El primer campo identifica el componente que inició la solicitud
de dependencia. El segundo campo identifica qué componente devolvió la respuesta de la llamada de dependencia.
Ejemplo
Veamos un ejemplo. Una aplicación llamada Stock Prices muestra el precio de mercado actual de una acción
mediante una API externa denominada Stock. La aplicación Stock Prices tiene una página llamada Stock page que el
explorador web del cliente abre mediante GET /Home/Stock . La aplicación consulta la API Stick mediante el uso de
una llamada HTTP GET /api/stock/value .
Puede analizar la telemetría resultante ejecutando una consulta:
(requests | union dependencies | union pageViews)
| where operation_Id == "STYz"
| project timestamp, itemType, name, id, operation_ParentId, operation_Id
En los resultados, observe que todos los elementos de telemetría comparten la raíz operation_Id . Cuando se
realiza una llamada Ajax desde la página, se asigna un nuevo identificador único ( qJSXU ) a la telemetría de
dependencia y el identificador de pageView se usa como operation_ParentId . La solicitud al servidor utiliza
después el identificador de Ajax como operation_ParentId .
O P ERAT IO N _PA REN T I

IT EM T Y P E NAME ID D O P ERAT IO N _ID
pageView Stock page STYz STYz
dependency GET /Home/Stock qJSXU STYz STYz
request GET Home/Stock KqKwlrSt9PA= qJSXU STYz
dependency GET /api/stock/value bBrf2L7mm2g= KqKwlrSt9PA= STYz
Cuando se realiza la llamada GET /api/stock/value a un servicio externo, necesita conocer la identidad de ese
servidor para poder establecer el campo dependency.target correctamente. Si el servicio externo no admite la
supervisión, target se establece en el nombre de host del servicio (por ejemplo, stock-prices-api.com ). Pero si
ese servicio se identifica devolviendo un encabezado HTTP predefinido, target contiene la identidad de servicio
que permite a Application Insights crear un seguimiento distribuido consultando la telemetría de ese servicio.
Encabezados de correlación
Application Insights está realizando la transición a W3C Trace-Context, que define:
traceparent : lleva el identificador único global de la operación y un identificador único de la llamada.
tracestate : lleva el contexto de seguimiento específico del sistema.
La versión más reciente del SDK de Application Insights es compatible con el protocolo de Trace-Context, pero es
posible que tenga que usarlo. (Se mantendrá la compatibilidad con el antiguo protocolo de correlación compatible
con el SDK de Application Insights).
El protocolo HTTP de correlación , también denominado Request-Id, está entrando en desuso. Este protocolo define
dos encabezados:
Request-Id : lleva el identificador único global de la llamada.
Correlation-Context : lleva la colección de pares nombre-valor de las propiedades del seguimiento distribuido.
Application Insights también define la extensión del protocolo HTTP de correlación. Usa pares nombre-valor
Request-Context para propagar la colección de propiedades utilizadas por el autor o el destinatario de la llamada. El
SDK de Application Insights usa este encabezado para establecer los campos dependency.target y request.source .
Habilitación de la compatibilidad con el seguimiento distribuido de W3C en aplicaciones clásicas de ASP.NET
NOTE
A partir de Microsoft.ApplicationInsights.Web y Microsoft.ApplicationInsights.DependencyCollector , no se
necesita configuración.
La compatibilidad con Trace-Context de W3C se realiza de manera compatible con versiones anteriores. Se espera
que la correlación funcione con aplicaciones que están instrumentadas con versiones anteriores de SDK (que no es
compatible con W3C).
Si quiere seguir usando el protocolo Request-Id heredado, puede deshabilitar Trace-Context con esta
configuración:
Activity.DefaultIdFormat = ActivityIdFormat.Hierarchical;
Activity.ForceDefaultIdFormat = true;
Si ejecuta una versión anterior del SDK, le recomendamos actualizarlo o aplicar la configuración siguiente para
habilitar Trace-Context. Esta característica está disponible en los paquetes Microsoft.ApplicationInsights.Web y
Microsoft.ApplicationInsights.DependencyCollector a partir de la versión 2.8.0-beta1. De forma predeterminada,
está deshabilitada. Para habilitarla, haga estos cambios en ApplicationInsights.config :
En RequestTrackingTelemetryModule , agregue el elemento EnableW3CHeadersExtraction y establezca su valor en
true .
En DependencyTrackingTelemetryModule , agregue el elemento EnableW3CHeadersInjection y establezca su valor en
true.
Agregue W3COperationCorrelationTelemetryInitializer en TelemetryInitializers . Será similar al siguiente
ejemplo:
<Add Type="Microsoft.ApplicationInsights.Extensibility.W3C.W3COperationCorrelationTelemetryInitializer,
Microsoft.ApplicationInsights"/>
...
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones de ASP.NET Core
NOTE
A partir de la versión 2.8.0 de Microsoft.ApplicationInsights.AspNetCore , no se necesita configuración.
configuración:
habilitar Trace-Context.
Esta característica está en la versión 2.5.0-beta1 de Microsoft.ApplicationInsights.AspNetCore y en la versión 2.8.0-
beta1 de Microsoft.ApplicationInsights.DependencyCollector . De forma predeterminada, está deshabilitada. Para
habilitarla, cambie ApplicationInsightsServiceOptions.RequestCollectionOptions.EnableW3CDistributedTracing a
true :
{
services.AddApplicationInsightsTelemetry(o =>
o.RequestCollectionOptions.EnableW3CDistributedTracing = true );
// ....
}
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones de Java

Agente de Java 3.0
El agente de Java 3.0 es compatible con W3C listo para usar y no se necesita ninguna configuración adicional.
SDK de Java
Configuración de entrada
En el caso de las aplicaciones de Java EE, agregue lo siguiente a la etiqueta <TelemetryModules> en el
archivo ApplicationInsights.xml:
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModul
e>
<Param name = "W3CEnabled" value ="true"/>
<Param name ="enableW3CBackCompat" value = "true" />
</Add>
En el caso de las aplicaciones de Spring Boot, agregue estas propiedades:

azure.application-insights.web.enable-W3C=true
azure.application-insights.web.enable-W3C-backcompat-mode=true
Configuración de salida
<Instrumentation>
</BuiltIn>
</Instrumentation>
NOTE
El modo de compatibilidad con versiones anteriores está habilitado de forma predeterminada, por lo que el
enableW3CBackCompat parámetro es opcional. Solo debe utilizarlo cuando desee desactivar la compatibilidad con
versiones anteriores.
Lo ideal sería desactivar la compatibilidad cuando todos los servicios se hayan actualizado a la versión más reciente de
los SDK compatibles con el protocolo W3C. Se recomienda encarecidamente que cambie a estos SDK más recientes lo
antes posible.
IMPORTANT
Asegúrese de que las configuraciones de entrada y salida sean exactamente iguales.
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones web

Esta característica está en Microsoft.ApplicationInsights.JavaScript . De forma predeterminada, está deshabilitada.
Para habilitarla, use la configuración distributedTracingMode . AI_AND_W3C se proporciona para la compatibilidad
con versiones anteriores de cualquier servicio heredado instrumentado por Application Insights.
Configuración de npm (omitir si se usa Configuración de fragmentos de código)
import { ApplicationInsights, DistributedTracingModes } from '@microsoft/applicationinsights-web';

distributedTracingMode: DistributedTracingModes.W3C
/* ...other configuration options... */
} });
Configuración de fragmentos de código (omitir si se usa Configuración de npm)
var sdkInstance="appInsightsSDK";window[sdkInstance]="appInsights";var
aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){i[e]=function(){var
n=arguments;i.queue.push(function(){i[e].apply(i,n)})}}var i={config:e};i.initialize=!0;var
a=document,t=window;setTimeout(function(){var
n=a.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",a.getEle
mentsByTagName("script")[0].parentNode.appendChild(n)});try{i.cookie=a.cookie}catch(e){}i.queue=
[],i.version=2;for(var r=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("tr
ack"+r.pop());n("startTrackPage"),n("stopTrackPage");var o="Track"+r[0];if(n("start"+o),n("stop"+o),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0=
==e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var
s=t[r];t[r]=function(e,n,a,t,o){var c=s&&s(e,n,a,t,o);return!0!==c&&i["_"+r]
({message:e,url:n,lineNumber:a,columnNumber:t,error:o}),c},e.autoExceptionInstrumented=!0}return i}
(
{
instrumentationKey:"INSTRUMENTATION_KEY",
distributedTracingMode: 2 // DistributedTracingModes.W3C
}
);
window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
OpenTracing y Application Insights

La especificación del modelo de datos de OpenTracing y los modelos de datos de Application Insights se asignan de
A P P L IC AT IO N IN SIGH T S O P EN T RA C IN G
Request , PageView Span con span.kind = server
Dependency Span con span.kind = client
Id de Request y Dependency SpanId
Operation_Id TraceId
Operation_ParentId Reference de tipo ChildOf (el intervalo primario)
Para más información, consulte Modelo de datos de telemetría de Application Insights.

Para ver definiciones de los conceptos de OpenTracing, consulte specification y semantic conventions de
OpenTracing.
Correlación de los datos de telemetría en OpenCensus Python

OpenCensus Python sigue las especificaciones del modelo de datos OpenTracing descritas anteriormente. También
admite Trace-Context de W3C sin requerir ninguna configuración.
Correlación de las solicitudes entrantes
OpenCensus Python correlaciona los encabezados de Trace-Context de W3C de las solicitudes entrantes a los
intervalos que se generan a partir de las solicitudes. OpenCensus lo hará automáticamente con integraciones para
marcos de aplicaciones web populares: Flask, Django y Pyramid. Solo tiene que rellenar los encabezados de Trace-
Context de W3C con el formato correcto y enviarlos con la solicitud. Esta es una aplicación de Flask de ejemplo que
muestra esto:

app,
)
@app.route('/')
def hello():
if __name__ == '__main__':
Este código ejecuta una aplicación de Flask de ejemplo en la máquina local, escuchando el puerto 8080 . Para
correlacionar el contexto de seguimiento, se envía una solicitud al punto de conexión. En este ejemplo, se puede
usar un comando curl :
curl --header "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" localhost:8080
Al examinar el formato de encabezado de Trace-Context, se deriva la información siguiente:

version : 00
trace-id : 4bf92f3577b34da6a3ce929d0e0e4736
parent-id/span-id : 00f067aa0ba902b7
trace-flags : 01
Si se echa un vistazo a la entrada de solicitud que se envió a Azure Monitor, se pueden ver los campos rellenados
con la información de encabezado de seguimiento. Puede encontrar estos datos en Registros (Analytics) en el
recurso Application Insights de Azure Monitor.
El campo id está en el formato <trace-id>.<span-id> , donde el trace-id se toma del encabezado de seguimiento
que se pasó en la solicitud y el span-id es una matriz de 8 bytes generada para este intervalo.
El campo operation_ParentId tiene el formato <trace-id>.<parent-id> , donde tanto trace-id como parent-id se
toman del encabezado de seguimiento que se pasó en la solicitud.
Python de OpenCensus permite correlacionar registros al agregar un identificador de seguimiento, un identificador
de intervalo y una marca de muestreo para escribir registros. Estos atributos se agregan al instalar la integración de
registro de OpenCensus. Los atributos siguientes se agregarán a los objetos LogRecord de Python: traceId ,
spanId y traceSampled . Tenga en cuenta que esto solo se aplica a los registradores que se crean después de la
integración.
Esta es una aplicación de ejemplo que muestra esto:
import logging

from opencensus.trace.samplers import AlwaysOnSampler
config_integration.trace_integrations(['logging'])
logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
tracer = Tracer(sampler=AlwaysOnSampler())
logger.warning('Before the span')
with tracer.span(name='hello'):
logger.warning('In the span')
logger.warning('After the span')
Cuando se ejecuta este código, se imprime lo siguiente en la consola:
2019-10-17 11:25:59,382 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 Before the span

2019-10-17 11:25:59,384 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=70da28f5a4831014 In the span
2019-10-17 11:25:59,385 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 After the span
Observe que hay un spanId presente para el mensaje de registro que se encuentra dentro del intervalo. Es el
mismo spanId que pertenece al intervalo denominado hello .
Puede exportar los datos de registro mediante AzureLogHandler . Para obtener más información, consulte este
artículo.
Correlación de telemetría en .NET

Con el tiempo, .NET ha establecido diversas formas para establecer correspondencias entre la telemetría y los
registros de diagnósticos:
System.Diagnostics.CorrelationManager permite hacer el seguimiento de LogicalOperationStack y ActivityId.
System.Diagnostics.Tracing.EventSource y Seguimiento de eventos para Windows (ETW) definen el método
SetCurrentThreadActivityId.
ILogger usa ámbitos de registro.
Windows Communication Foundation (WCF) y HTTP conectan la propagación del contexto "actual".
Pero esos métodos no proporcionaban compatibilidad con el seguimiento distribuido automático.
DiagnosticSource admite la correlación automática entre máquinas. Las bibliotecas de .NET admiten
DiagnosticSource y permiten la propagación automática entre máquinas del contexto de correlación mediante el
transporte correspondiente; por ejemplo, HTTP.
En la guía de actividades para el usuario en DiagnosticSource se explican los conceptos básicos de las actividades
de seguimiento.
ASP.NET Core 2.0 admite la extracción de encabezados HTTP e inicia nuevas actividades.
A partir de la versión 4.1.0, System.Net.Http.HttpClient permite insertar automáticamente los encabezados HTTP
de correlación y realizar un seguimiento de las llamadas HTTP como actividades.
Hay un nuevo módulo HTTP, Microsoft.AspNet.TelemetryCorrelation para ASP.NET clásico. Este módulo implementa
la correlación de telemetría mediante DiagnosticSource . Las actividades se inician en función de los encabezados
de solicitud entrantes. También establece correlación entre los datos de telemetría de las distintas fases del
procesamiento de solicitudes, incluso cuando cada fase de procesamiento de Internet Information Services (IIS) se
ejecuta en un subproceso administrado diferente.
A partir de la versión 2.4.0-beta1, el SDK de Application Insights utiliza DiagnosticSource y Activity para recopilar
datos telemétricos y asociarlos con la actividad actual.
Correlación de telemetría en Java

El agente de Java y el SDK de Java versión 2.0.0 o posteriores permiten la correlación automática de la telemetría.
Rellena automáticamente el valor de operation_id en todos los elementos de telemetría (como seguimientos,
excepciones y eventos personalizados) que se emiten en el ámbito de una solicitud. También propaga los
encabezados de correlación (descritos anteriormente) de las llamadas de un servicio de a otro mediante HTTP si el
agente del SDK de Java está configurado.
NOTE
El agente de Java de Application Insights recopila automáticamente las solicitudes y dependencias de JMS, Kafka,
Netty/Webflux, etc. En el caso del SDK de Java, la característica de correlación solamente admite las llamadas realizadas
mediante Apache HttpClient. No se admite la propagación automática de contextos entre tecnologías de mensajería (como
Kafka, RabbitMQ y Azure Service Bus) en el SDK.
NOTE
Para recopilar la telemetría personalizada, debe instrumentar la aplicación con el SDK de Java 2.6.
Nombres de roles
Es posible que quiera personalizar el modo en que los nombres de los componentes aparecen en el mapa de
aplicación. Para ello, puede establecer manualmente el valor de cloud_RoleName a través de una de las acciones
siguientes:
Para el agente de Java 3.0 de Application Insights, establezca el nombre del rol de nube de la siguiente
manera:
{
"preview": {
}
}
}

Con el SDK 2.5.0 de Java de Application Insights y versiones posteriores, puede especificar el cloud_RoleName
si agrega <RoleName> al archivo ApplicationInsights.xml:

<RoleName>** Your role name **</RoleName>
...
Si usa Spring Boot con el código de inicio de Spring Boot de Application Insights, solo debe establecer el
nombre personalizado para la aplicación en el archivo application.properties:
spring.application.name=<name-of-app>
El código de inicio de Spring Boot asigna automáticamente cloudRoleName al valor que se especifica para la
propiedad spring.application.name .
Pasos siguientes
Escriba una telemetría personalizada.
En el caso de escenarios avanzados de correlación en ASP.NET Core y ASP.NET, consulte el artículo sobre el
Obtenga más información sobre la opción cloud_RoleName en otros SDK.
Incorpore todos los componentes de un microservicio en Application Insights. Consulte las plataformas
compatibles.
Consulte en el modelo de datos los tipos de Application Insights.
Obtenga información sobre cómo ampliar y filtrar la telemetría.
Consulte la referencia de configuración de Application Insights.
Live Metrics Stream: supervisión y diagnóstico con
una latencia de 1 segundo
Supervise la aplicación web, ya activa y en producción, con Live Metrics Stream (también conocido como
QuickPulse) desde Application Insights. Seleccione métricas y contadores de rendimiento y fíltrelos para
inspeccionarlos en tiempo real sin que el servicio se vea afectado. Inspeccione seguimientos de la pila
procedentes de ejemplos de errores de solicitudes y excepciones. Junto con Profiler y el depurador de
instantáneas, Live Metrics Stream proporciona una herramienta de diagnóstico eficaz y no invasiva para
sitios web activos.
Con Live Metrics Stream, puede:
Inspeccionar el rendimiento y los recuentos de errores mientras se publica una solución para validarla.
Inspeccionar el efecto de las cargas de prueba y diagnosticar problemas en tiempo real.
Centrarse en ciertas sesiones de prueba o filtrar problemas conocidos seleccionando las métricas que
quiera inspeccionar y filtrándolas.
Obtener seguimientos de las excepciones cuando se produzcan.
Experimentar con filtros para localizar los indicadores clave de rendimiento más pertinentes.
Supervisar cualquier contador de rendimiento de Windows en tiempo real.
Identifique fácilmente un servidor con problemas y filtre todos los KPI o fuente directa solo en dicho
servidor.
Actualmente, Live Metrics se admite en aplicaciones de ASP.NET, ASP.NET Core, Azure Functions, Java y
Node.js.
Introducción
1. Siga las instrucciones específicas del lenguaje para habilitar Live Metrics.
ASP.NET: Live Metrics está habilitada de forma predeterminada.
ASP.NET Core: Live Metrics está habilitada de forma predeterminada.
.NET, Consola de .NET Core o Worker: Live Metrics está habilitada de forma predeterminada.
Aplicaciones .NET: se habilita mediante código.
Node.js
2. En Azure Portal, abra el recurso de Application Insights de la aplicación y, a continuación, abra Live
Stream.
3. Proteja el canal de control si puede que vaya a usar información confidencial como nombres de
clientes en los filtros.
Habilitación de LiveMetrics mediante código para cualquier aplicación .NET
Aunque LiveMetrics se habilita de forma predeterminada cuando se incorpora siguiendo las instrucciones
recomendadas para las aplicaciones .NET, a continuación se muestra cómo configurar Live Metrics de forma
manual.
1. Instale el paquete NuGet Microsoft.ApplicationInsights.PerfCounterCollector.
2. El siguiente código de aplicación de consola de ejemplo muestra la configuración de Live Metrics.
using System;
namespace LiveMetricsDemo
{
class Program
{
{
// Create a TelemetryConfiguration instance.
TelemetryConfiguration config = TelemetryConfiguration.CreateDefault();
config.InstrumentationKey = "INSTRUMENTATION-KEY-HERE";
QuickPulseTelemetryProcessor quickPulseProcessor = null;
config.DefaultTelemetrySink.TelemetryProcessorChainBuilder
.Use((next) =>
{
quickPulseProcessor = new QuickPulseTelemetryProcessor(next);
return quickPulseProcessor;
})
.Build();
var quickPulseModule = new QuickPulseTelemetryModule();
// Secure the control channel.

// This is optional, but recommended.
quickPulseModule.AuthenticationApiKey = "YOUR-API-KEY-HERE";
quickPulseModule.Initialize(config);
quickPulseModule.RegisterTelemetryProcessor(quickPulseProcessor);
// Create a TelemetryClient instance. It is important

// to use the same TelemetryConfiguration here as the one
// used to setup Live Metrics.
TelemetryClient client = new TelemetryClient(config);
// This sample runs indefinitely. Replace with actual application logic.

while (true)
{
// Send dependency and request telemetry.
// These will be shown in Live Metrics stream.
// CPU/Memory Performance counter is also shown
// automatically without any additional steps.
client.TrackDependency("My dependency", "target", "http://sample",
DateTimeOffset.Now, TimeSpan.FromMilliseconds(300), true);
client.TrackRequest("My Request", DateTimeOffset.Now,
TimeSpan.FromMilliseconds(230), "200", true);
}
}
}
}
Aunque el ejemplo anterior es para una aplicación de consola, se puede usar el mismo código en cualquier
aplicación .NET. Si se habilita cualquier otro módulo TelemetryModules que recopile automáticamente la
telemetría, es importante asegurarse de que la misma configuración que se use para la inicialización de los
módulos también se emplee para el módulo de Live Metrics.
¿En qué se diferencia Live Metrics Stream de Explorador de métricas

y Analytics?
EXP LO RA DO R DE M ÉT RIC A S Y
L IVE ST REA M A N A LY T IC S
Latency Los datos se muestran en un La agregación se realiza en minutos.

segundo.
Sin retención Los datos se conservan solo mientras Los datos se conservan durante 90
se encuentren en el gráfico y luego se días.
descartan.
A petición Los datos solo se transmiten mientras Se envían datos siempre que el SDK
el panel de Live Metrics está abierto. esté instalado y habilitado.
Gratis No se efectúa ningún cargo por los Están sujetos a aplicación de precios.
datos de Live Stream.
Muestreo Se transmiten todas las métricas y los Se pueden muestrear eventos.

contadores seleccionados. Se
muestrean los errores y seguimientos
de la pila.
Canal de control Las señales de control de filtro se La comunicación es unidireccional,

envían al SDK. Se recomienda hacia el portal
proteger este canal.
Selección y filtrado de métricas

[Disponible con ASP.NET, ASP.NET Core y Azure Functions (versión 2).]
Puede supervisar KPI personalizados en vivo aplicando filtros arbitrarios en cualquier telemetría de
Application Insights desde el portal. Haga clic en el control de filtro que se muestra cuando coloca el mouse
sobre cualquiera de los gráficos. En el siguiente gráfico se traza un KPI de recuento de solicitudes
personalizado con filtros en atributos de URL y duración. Valide los filtros con la sección de versión
preliminar de secuencias que muestra una fuente activa de telemetría que coincide con los criterios
especificados en cualquier momento.
Puede supervisar un valor que no sea el de recuento. Las opciones dependen del tipo de secuencia, que
podría ser cualquier telemetría de Application Insights: solicitudes, dependencias, excepciones, seguimientos,
eventos o métricas. Puede ser su propia medida personalizada:
Además de telemetría de Application Insights, también puede supervisar cualquier contador de rendimiento
de Windows eligiendo entre las opciones de secuencias y proporcionando el nombre del contador de
rendimiento.
Las métricas activas se agregan en dos puntos: localmente en cada servidor y, a continuación, en todos los
servidores. Puede cambiar el valor predeterminado en cualquiera de ellos seleccionando otras opciones en
las correspondientes listas desplegables.
Telemetría de ejemplo: eventos personalizados de diagnóstico en

vivo
De forma predeterminada, la fuente directa de eventos muestra ejemplos de solicitudes con error y llamadas
de dependencia, excepciones, eventos y seguimientos. Haga clic en el icono de filtro para ver los criterios
aplicados en cualquier momento.
Como con las métricas, puede especificar cualquier criterio arbitrario en cualquiera de los tipos de telemetría
de Application Insights. En este ejemplo, seleccionaremos los eventos y errores de solicitud específicos.
NOTE
Actualmente, para los criterios basados en mensajes de excepción, use el mensaje de excepción más externo. En el
ejemplo anterior, para filtrar la excepción benigna con el mensaje de excepción interna (lo que sigue al delimitador "<--
"): "El cliente está desconectado". Use un mensaje que no contenga criterios de error al leer el contenido de la solicitud.
Consulte los detalles de un elemento en la fuente directa haciendo clic en él. Puede pausar la fuente haciendo
clic en Pausar o simplemente desplazándose hacia abajo o haciendo clic en un elemento. La fuente directa se
reanudará una vez que se desplace hacia la parte superior, o bien al hacer clic en el contador de elementos
recopilados mientras estaba en pausa.
Filtrado por instancia de servidor

Si quiere supervisar una instancia de rol de servidor en particular, puede filtrar por servidor. Para filtrar,
seleccione el nombre del servidor en Servidores.
Protección del canal de control
NOTE
Actualmente, solo se puede configurar un canal autenticado mediante la supervisión basada en código y no se pueden
autenticar los servidores con la conexión sin código.
Los criterios de filtros personalizados que especifique en el portal de Live Metrics se envían hacia el
componente de Live Metrics del SDK de Application Insights. Los filtros podrían contener información
confidencial, como identificadores de clientes. Puede hacer que el canal seguro con una clave secreta de API,
además de la clave de instrumentación.
Creación de una clave de API
Incorporación de la clave de API a la configuración
ASP.NET
En el archivo applicationinsights.config, agregue AuthenticationApiKey a QuickPulseTelemetryModule:
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.QuickPulse.QuickPulseTelemetryModu
le, Microsoft.AI.PerfCounterCollector">
<AuthenticationApiKey>YOUR-API-KEY-HERE</AuthenticationApiKey>
</Add>
ASP.NET Core
Para las aplicaciones de ASP.NET Core, siga las instrucciones descritas aquí.
Modifique ConfigureServices del archivo Startup.cs como sigue:
Agregue el siguiente espacio de nombres.
A continuación, modifique el método ConfigureServices como se indica a continuación.

{
// existing code which include services.AddApplicationInsightsTelemetry() to enable Application
Insights.
services.ConfigureTelemetryModule<QuickPulseTelemetryModule> ((module, o) =>
module.AuthenticationApiKey = "YOUR-API-KEY-HERE");
}
Puede encontrar más información sobre la configuración de las aplicaciones de ASP.NET Core en nuestras
instrucciones para configurar los módulos de telemetría en ASP.NET Core.
WorkerService
Para las aplicaciones de WorkerService, siga las instrucciones que se indican a continuación.
Agregue el siguiente espacio de nombres.
A continuación, agregue la siguiente línea antes de la llamada a

services.AddApplicationInsightsTelemetryWorkerService .
services.ConfigureTelemetryModule<QuickPulseTelemetryModule> ((module, o) =>

module.AuthenticationApiKey = "YOUR-API-KEY-HERE");
Puede encontrar más información sobre la configuración de aplicaciones de WorkerService en nuestras

instrucciones sobre la configuración de los módulos de telemetría en WorkerServices.
Azure Function Apps
En el caso de Azure Function Apps (versión 2), la protección del canal con una clave de API puede realizarse
con una variable de entorno.
Cree una clave de API desde su recurso de Application Insights y vaya a Opciones > Configuración en la
aplicación de función. Seleccione Nueva configuración de la aplicación y escriba un nombre de
APPINSIGHTS_QUICKPULSEAUTHAPIKEY y un valor que corresponda a la clave de API.
Sin embargo, si reconoce y confía en todos los servidores conectados, puede probar los filtros
personalizados sin el canal autenticado. Esta opción está disponible durante seis meses. Esta invalidación se
requiere una vez cada nueva sesión, o cuando se pone en línea un nuevo servidor.
NOTE
Se recomienda que configure el canal autenticado antes de escribir información potencialmente confidencial, como
identificadores de clientes en los criterios de filtro.
Tabla de características compatibles

F ILT RA DO DIVISIÓ N DE
M ÉT RIC A S M ÉT RIC A S DE P ERSO N A L IZ A D T EL EM ET RÍA DE C PU POR
IDIO M A B Á SIC A S REN DIM IEN TO O E JEM P LO P RO C ESO
.NET Framework Se admite Se admite Se admite Se admite Se admite

(V2.7.2+) (V2.7.2+) (V2.7.2+) (V2.7.2+) (V2.7.2+)
.NET Core Se admite Se admite Se admite Se admite Se admite

(destino=.NET (V2.4.1+) (V2.4.1+) (V2.4.1+) (V2.4.1+) (V2.4.1+)
Framework)
.NET Core Se admite Admitido* Se admite Se admite No admitido

(destino=.NET (V2.4.1+) (V2.4.1+) (V2.4.1+)
Core)
Azure Functions Compatible Compatible Compatible Compatible No admitido

v2
Java Se admite Se admite No admitido No admitido No admitido

(V2.0.0+) (V2.0.0+)
Node.js Se admite Se admite No admitido Se admite No admitido

(V1.3.0+) (V1.3.0+) (V1.3.0+)
Las métricas básicas incluyen la tasa de solicitudes, dependencias y excepciones. Las métricas de rendimiento
(contadores de rendimiento) incluyen la memoria y la CPU. La telemetría de ejemplo muestra un flujo de
información detallada para las solicitudes y dependencias con errores, excepciones, eventos y seguimientos.
* La compatibilidad con PerfCounters varía ligeramente en las diversas versiones de .NET Core que no tienen
.NET Framework como destino:
Se admiten las métricas de PerfCounters cuando se ejecutan en Azure App Service para Windows.
(AspNetCore SDK Version 2.4.1 o superior)
Se admiten PerfCounters cuando la aplicación se ejecuta en CUALQUIER máquina de Windows, ya sea una
máquina virtual, un servicio en la nube, local, etc. (AspNetCore SDK versión 2.7.1 o superior), pero para
las aplicaciones que tienen como destino .NET Core 2.0 o superior.
Los PerfCounters se admiten cuando la aplicación se ejecuta en cualquier lugar (Linux, Windows, App
Service para Linux, contenedores, etc.) en las versiones más recientes (es decir, AspNetCore SDK versión
2.8.0 o posterior), pero solo para las aplicaciones que tengan como destino .NET Core 2.0 o posterior.
Live Metrics Stream usa direcciones IP diferentes a las de otros datos de telemetría de Application Insights.
Asegúrese de que esas direcciones IP están abiertos en el firewall. Compruebe también que los puertos de
salida de Live Metrics Stream estén abiertos en el firewall de los servidores.
Pasos siguientes
Supervisión del uso con Application Insights
Uso de la Búsqueda de diagnóstico
Métricas agregadas previamente y basadas en
registros en Application Insights
En este artículo se explica la diferencia entre las métricas de Application Insights "tradicionales" que se basan en
los registros y las métricas previamente agregadas que están actualmente en versión preliminar pública. Ambos
tipos de métricas están disponibles para los usuarios de Application Insights, y cada uno aporta un valor único
para las funciones de supervisión del estado de mantenimiento de la aplicación, diagnóstico y análisis. Los
desarrolladores que van a instrumentar aplicaciones pueden decidir qué tipo de métrica es la más adecuada para
un escenario determinado, según el tamaño de la aplicación, el volumen esperado de los datos de telemetría y los
requisitos empresariales de alertas y precisión de las métricas.
Métricas basadas en registros

Hasta hace poco, el modelo de datos de telemetría de supervisión de aplicaciones de Application Insights se
basaba únicamente en unos pocos tipos predefinidos de eventos, tales como solicitudes, excepciones, llamadas
de dependencia, vistas de página, etc. Los desarrolladores pueden usar el SDK para emitir estos eventos
manualmente (escribiendo código que invoca explícitamente el SDK) o pueden usar la recopilación automática de
eventos de la instrumentación automática. En cualquier caso, el servidor back-end de Application Insights
almacena todos los eventos recopilados como registros y las hojas de Application Insights en Azure Portal actúan
como herramienta de análisis y diagnóstico para visualizar los datos basados en eventos de los registros.
El uso de registros para conservar un conjunto completo de eventos puede aportar gran valor al análisis y el
diagnóstico. Por ejemplo, puede obtener el número exacto de solicitudes enviadas a una dirección URL
determinada con el número de usuarios distintos que realizaron estas llamadas. O puede obtener seguimientos
de diagnóstico detallados, incluidas las excepciones y llamadas de dependencia para cualquier sesión de usuario.
Con este tipo de información puede mejorar considerablemente la visibilidad sobre el estado y el uso de la
aplicación, lo que permite reducir el tiempo necesario diagnosticar los problemas de una aplicación.
Al mismo tiempo, recopilar un conjunto completo de eventos puede resultar poco práctico (o incluso imposible)
en el caso de aplicaciones que generan un gran volumen de telemetría. En aquellos casos en los que el volumen
de eventos es demasiado alto, Application Insights implementa varias técnicas de reducción del volumen de datos
de telemetría, tales como muestreo y filtrado, que reducen el número de eventos recopilados y almacenados.
Lamentablemente, reducir el número de eventos almacenados reduce también la precisión de las métricas que,
en segundo plano, deben realizar agregaciones en tiempo de consulta de los eventos almacenados en los
registros.
NOTE
En Application Insights, las métricas que se basan en la agregación en tiempo de consulta de los eventos y las medidas que
se almacenan en los registros se denominan métricas basadas en registros. Estas métricas suelen tienen muchas
dimensiones de las propiedades de los eventos, lo que hace que sean superiores para el análisis, pero la precisión de estas
métricas se ve afectada negativamente por el muestreo y el filtrado.
Métricas agregadas previamente

Además de las métricas basadas en registros, a finales de 2018 el equipo de Application Insights lanzó una
versión preliminar pública de métricas que se almacenan en un repositorio especializado que está optimizado
para series temporales. Las nuevas métricas ya no se conservan como eventos individuales con una gran
cantidad de propiedades. En su lugar, se almacenan como series temporales previamente agregadas y solo con
las dimensiones clave. Esto hace que las nuevas métricas sean superiores en tiempo de consulta: la recuperación
de datos es mucho más rápida y requiere menos capacidad de proceso. Esto permite nuevos escenarios como las
alertas casi en tiempo real sobre las dimensiones de las métricas y paneles con más capacidad de respuesta y
muchos más.
IMPORTANT
Las métricas basadas en registros y las métricas agregadas previamente coexisten en Application Insights. Para diferenciar
las dos, en la experiencia de usuario de Application Insights, las métricas agregadas previamente ahora se llaman "métricas
estándar (versión preliminar)", mientras que el nombre de las métricas tradicionales de eventos ha cambiado a "métricas
basadas en registros".
Los SDK más recientes (SDK de Application Insights 2.7 o versiones posteriores para. NET) agregan previamente
las métricas durante la recopilación antes de que se apliquen las técnicas de reducción del volumen de datos de
telemetría. Esto significa que la precisión de las nuevas métricas no se ve afectada por el muestreo y el filtrado
cuando se usan las versiones más recientes del SDK de Application Insights.
En el caso de los SDK que no implementan la agregación previa (es decir, las versiones anteriores del SDK de
Application Insights o la instrumentación del explorador) el servidor back-end de Application Insights sigue
agregando los eventos recibidos por la el punto de conexión de recopilación de eventos de Application Insights
para rellenar las nuevas métricas. Esto significa que aunque no se beneficie del menor volumen de datos que se
transmite a través del cable, podrá seguir usando las métricas agregadas previamente para experimentar un
mejor rendimiento y aprovechar la compatibilidad con las alertas dimensionales casi en tiempo real con los SDK
que no agregan previamente las métricas durante la recopilación.
Merece la pena mencionar que el punto de conexión de la colección agrega previamente los eventos antes de
muestreo de ingesta, lo que significa que el muestreo de ingesta no afectará nunca a la precisión de las métricas
agregadas previamente, independientemente de la versión SDK que use con su aplicación.
Uso de agregación previa con métricas personalizadas de Application

Insights
Puede usar la agregación previa con las métricas personalizadas. Las dos ventajas principales son la capacidad de
configurar y generar alertas sobre una dimensión de una métrica personalizada, y la reducción del volumen de
datos que se envía desde el SDK al punto de conexión de recopilación de Application Insights.
Hay varias maneras de enviar métricas personalizadas desde el SDK de Application Insights. Si su versión del SDK
ofrece los métodos GetMetric y TrackValue, esta es la manera preferida para enviar métricas personalizadas, ya
que la agregación previa ocurre dentro del SDK, lo que no solo reduce el volumen de datos almacenados en
Azure, sino también el volumen de datos que se transmite desde el SDK de Application Insights. En caso contrario,
use el método trackMetric, que realizará la agregación previa de los eventos de métrica durante la ingesta de
datos.
Dimensiones de métricas personalizadas y agregación previa

Todas las métricas que envíe con las llamadas API trackMetric o GetMetric y TrackValue se almacenan
automáticamente en los almacenes de registros y métricas. Sin embargo, mientras que la versión basada en
registros de la métrica personalizada siempre conserva todas las dimensiones, la versión de la métrica
previamente agregada se almacena de forma predeterminada sin dimensiones. Puede activar la recopilación de
dimensiones de las métricas personalizadas en la pestaña Uso y costos estimados, activando "Habilitar la creación
de alertas sobre las dimensiones de las métricas personalizadas".
¿Por qué la recopilación de dimensiones de métricas personalizadas
está desactivada de forma predeterminada?
La recopilación de dimensiones de métricas personalizadas se ha desactivado de forma predeterminada porque,
en el futuro, el almacenamiento de métricas personalizadas con dimensiones se facturará por separado de
Application Insights, mientras que el almacenamiento de métricas personalizadas no dimensionales seguirá
siendo gratuita (hasta una cuota). Para más información sobre los próximos cambios en los modelos de precios,
consulte la página de precios oficial.
Creación de gráficos y exploración de métricas estándar basadas en

registros y agregadas previamente
Use el Explorador de métricas de Azure Monitor para trazar los gráficos de las métricas agregadas previamente y
basadas en registros, y para crear paneles con gráficos. Después de seleccionar el recurso de Application Insights
deseado, utilice el selector de espacios de nombres para cambiar de métricas estándar (versión preliminar) a
métricas basadas en registros, o seleccione un espacio de nombres de métricas personalizadas:
Modelos de precios para métricas de Application Insights

La ingesta de métricas en Application Insights, tanto si se basa en el registro como si se agrega previamente,
generará costos en función del tamaño de los datos ingeridos, tal y como se describe aquí. Las métricas
personalizadas, incluidas todas sus dimensiones, siempre se almacenan en el almacén de registros de Application
Insights. Además, se reenvía de forma predeterminada una versión previamente agregada de las métricas
personalizadas (sin dimensiones) al almacén de métricas.
Al seleccionar la opción Habilitar la creación de alertas sobre las dimensiones de las métricas personalizadas para
almacenar todas las dimensiones de las métricas previamente agregadas en el almacén de métricas, se pueden
generar costos adicionales basados en los precios de las métricas personalizadas.
Pasos siguientes
Alertas casi en tiempo real
GetMetric y TrackValue
Métricas basadas en registros de Application Insights
Las métricas basadas en registros de Application Insights le permiten analizar el estado de las aplicaciones
supervisadas, crear paneles eficaces y configurar alertas. Existen dos tipos de métricas:
Las métricas basadas en registros subyacentes se traducen en consultas de Kusto de eventos almacenados.
Las métricas estándar se almacenan como series temporales previamente agregadas.
Puesto que las métricas estándar se agregan previamente durante la recopilación, tienen un mejor rendimiento en
el momento de la consulta. Esto las convierte en una opción mejor para los paneles y las alertas en tiempo real. Las
métricas basadas en registros tienen más dimensiones, lo que las convierte en la mejor opción para el análisis de
datos y los diagnósticos ad hoc. Use el selector del espacio de nombres para cambiar entre las métricas basadas en
registros y las métricas estándar en el explorador de métricas.
Interpretación y uso de consultas de este artículo

En este artículo se enumeran las métricas con las agregaciones y dimensiones compatibles. Los detalles sobre las
métricas basadas en registros incluyen las instrucciones de consulta de Kusto subyacentes. Para mayor comodidad,
cada consulta usa valores predeterminados para la granularidad del tiempo, el tipo de gráfico y, a veces, para
dividir la dimensión, lo que simplifica el uso de la consulta en Log Analytics sin necesidad de modificarla.
Cuando se traza la misma métrica en el explorador de métricas, no hay valores predeterminados: la consulta se
ajusta dinámicamente en función de la configuración del gráfico:
El Inter valo de tiempo seleccionado se traduce en un una cláusula where timestamp... adicional para
seleccionar solo los eventos del intervalo de tiempo seleccionado. Por ejemplo, en un gráfico que muestra
los datos de las últimas 24 horas, la consulta incluye | where timestamp > ago(24 h) .
La Granularidad de tiempo seleccionada se pone en la cláusula final.summarize ... by bin(timestamp, [time
grain]) .
Todas las dimensiones de Filtro seleccionadas se traducen en cláusulas where adicionales.
La dimensión Split char t (Dividir gráfico) se traduce en una propiedad de resumen adicional. Por ejemplo,
si divide el gráfico por ubicación y realiza un trazado usando una granularidad de tiempo de cinco minutos,
la cláusula summarize se resume como ... by bin(timestamp, 5 m), location.
NOTE
Si no está familiarizado con el lenguaje de consulta de Kusto, comience por copiar y pegar las instrucciones de Kusto en el
panel de consulta de Log Analytics sin realizar ninguna modificación. Haga clic en Ejecutar para ver el gráfico básico. Cuando
empiece a comprender la sintaxis del lenguaje de consulta, podrá comenzar a realizar pequeñas modificaciones y ver el
impacto del cambio. La exploración de sus propios datos es una excelente manera de comenzar a obtener toda la eficacia de
Log Analytics y Azure Monitor.
Métricas de disponibilidad
Las métricas de la categoría Disponibilidad le permiten ver el estado de la aplicación web, tal y como se observa en
los puntos de todo el mundo. Configure las pruebas de disponibilidad para empezar a usar las métricas de esta
categoría.
Disponibilidad (availabilityResults/availabilityPercentage )
La métrica Disponibilidad muestra el porcentaje de las series de pruebas web que no detectaron ningún problema.
El valor mínimo posible es 0, que indica que se han producido errores en todas las series de pruebas web. El valor
de 100 significa que todas las series de pruebas web superaron los criterios de validación.
UN IDA D DE M EDIDA A GREGA C IO N ES C O M PAT IB L ES DIM EN SIO N ES C O M PAT IB L ES
Porcentaje Average Ubicación de ejecución, nombre de

prueba
availabilityResults
| summarize sum(todouble(success == 1) * 100) / count() by bin(timestamp, 5m), location
| render timechart
Duración de la prueba de disponibilidad (availabilityResults/duration)

La métrica Duración de la prueba de disponibilidad muestra cuánto tiempo tardó en ejecutarse la prueba web. En el
caso de las pruebas web de varios pasos, la métrica refleja el tiempo total de ejecución de todos los pasos.
Milisegundos Promedio, mín., máx. Ubicación de ejecución, nombre de

prueba, resultado de prueba
availabilityResults
| where notempty(duration)
| extend availabilityResult_duration = iif(itemType == 'availabilityResult', duration, todouble(''))
| summarize sum(availabilityResult_duration)/sum(itemCount) by bin(timestamp, 5m), location
| render timechart
Pruebas de disponibilidad (availabilityResults/count)

La métrica de las Pruebas de disponibilidad refleja el recuento de las series de pruebas web de Azure Monitor.
Count Count Ubicación de ejecución, nombre de

prueba, resultado de prueba
availabilityResults
| summarize sum(itemCount) by bin(timestamp, 5m)
| render timechart
Métricas del explorador

El SDK de JavaScript de Application Insights recopila las métricas de explorador de los exploradores de los usuarios
finales reales. Proporcionan una gran información sobre la experiencia de los usuarios con la aplicación web.
Normalmente, no se muestrean las métricas del explorador, lo que significa que proporcionan una mayor precisión
de los números de uso en comparación con las métricas del lado servidor, que podrían sesgarse con el muestreo.
NOTE
Para recopilar las métricas del explorador, la aplicación debe estar instrumentada con el SDK de JavaScript para Application
Insights.
Tiempo de carga de página del explorador (browserTimings/totalDuration)

DIM EN SIO N ES P REVIA M EN T E
UN IDA D DE M EDIDA A GREGA C IO N ES C O M PAT IB L ES A GREGA DA S
Milisegundos Promedio, mín., máx. None
browserTimings
| where notempty(totalDuration)
| extend _sum = totalDuration
| extend _count = itemCount
| extend _sum = _sum * _count
| summarize sum(_sum) / sum(_count) by bin(timestamp, 5m)
| render timechart
Tiempo de procesamiento del cliente (browserTiming/processingDuration)

browserTimings
| where notempty(processingDuration)
| extend _sum = processingDuration
| summarize sum(_sum)/sum(_count) by bin(timestamp, 5m)
| render timechart
Tiempo de conexión de red de carga de página (browserTimings/networkDuration)

browserTimings
| where notempty(networkDuration)
| extend _sum = networkDuration
| render timechart
Tiempo de respuesta de recepción (browserTimings/receiveDuration)


browserTimings
| where notempty(receiveDuration)
| extend _sum = receiveDuration
| render timechart
Hora de envío de la solicitud (browserTimings/sendDuration)

browserTimings
| where notempty(sendDuration)
| extend _sum = sendDuration
| render timechart
Métricas de errores
Las métricas de Errores muestran problemas con el procesamiento de solicitudes, las llamadas de dependencia y
las excepciones producidas.
Excepciones de explorador (exceptions/browser)
Esta métrica refleja el número de excepciones producidas a partir del código de aplicación que se ejecuta en el
explorador. Solo se incluyen en la métrica las excepciones de las que se realiza un seguimiento con una llamada API
de Application Insights trackException() .
A GREGA C IO N ES DIM EN SIO N ES

UN IDA D DE M EDIDA C O M PAT IB L ES P REVIA M EN T E A GREGA DA S N OTA S
Count Count None La versión basada en

registros usa la agregación
Sum .
exceptions
| where notempty(client_Browser)
| render barchart
Errores de llamada de dependencia (dependencies/failed)

Cantidad de llamadas de dependencia con errores.

Count Count None La versión basada en

registros usa la agregación
Sum .
dependencies
| render barchart
Excepciones (exceptions/count)
Cada vez que registra una excepción en Application Insights, se produce una llamada al método trackException() del
SDK. La métrica de excepciones muestra la cantidad de excepciones registradas.

Count Count Nombre del rol en la nube, La versión basada en

instancia de rol en la nube, registros usa la agregación
tipo de dispositivo Sum .
exceptions
| render barchart
Solicitudes con error (requests/failed)

Recuento de solicitudes de servidor de las que se ha realizado un seguimiento y que se marcaron como errores. De
forma predeterminada, el SDK de Application Insights marca automáticamente cada solicitud de servidor que
devolvió el código de respuesta HTTP 5xx o 4xx como una solicitud con error. Para personalizar esta lógica, puede
modificar la propiedad success del elemento de telemetría de la solicitud en un inicializador de telemetría
personalizado.

Count Count Instancia de rol en la nube, La versión basada en

nombre de rol en la nube, registros usa la agregación
tráfico real o sintético, Sum .
rendimiento de la solicitud,
código de respuesta
requests
| render barchart
Excepciones del servidor (exceptions/server)

Esta métrica muestra el número de excepciones de servidor.

Count Count Nombre del rol en la nube, La versión basada en

instancia de rol en la nube registros usa la agregación
Sum .
exceptions
| where isempty(client_Browser)
| render barchart
Use las métricas de la categoría de Contadores de rendimiento para acceder a los contadores de rendimiento
del sistema que recopila Application Insights.
Memoria disponible (performanceCounters/availableMemory)
performanceCounters
| where ((category == "Memory" and counter == "Available Bytes") or name == "availableMemory")
| extend performanceCounter_value = iif(itemType == "performanceCounter", value, todouble(''))
| summarize sum(performanceCounter_value) / count() by bin(timestamp, 1m)
| render timechart
Tasa de excepciones (performanceCounters/exceptionRate )
performanceCounters
| where ((category == ".NET CLR Exceptions" and counter == "# of Exceps Thrown / sec") or name ==
"exceptionRate")
| extend performanceCounter_value = iif(itemType == 'performanceCounter',value,todouble(''))
| render timechart
Tiempo de ejecución de la solicitud HTTP (performanceCounters/requestExecutionTime )
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Request Execution Time") or name ==
"requestExecutionTime")
| render timechart
Frecuencia de solicitudes HTTP (performanceCounters/requestsPerSecond)
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Requests/Sec") or name == "requestsPerSecond")
| render timechart
Solicitudes HTTP en la cola de la aplicación (performanceCounters/requestsInQueue )
performanceCounters
| where ((category == "ASP.NET Applications" and counter == "Requests In Application Queue") or name ==
"requestsInQueue")
| render timechart
CPU de proceso (performanceCounters/processCpuPercentage )

La métrica muestra la cantidad de la capacidad total del procesador que usa el proceso que hospeda la aplicación
supervisada.
Porcentaje Promedio, mín., máx. Instancia de rol en la nube
performanceCounters
| where ((category == "Process" and counter == "% Processor Time Normalized") or name ==
"processCpuPercentage")
| render timechart
Tasa de E/S del proceso (performanceCounters/processIOBytesPerSecond)

Bytes por segundo Promedio, mín., máx. Instancia de rol en la nube
performanceCounters
| where ((category == "Process" and counter == "IO Data Bytes/sec") or name == "processIOBytesPerSecond")
| render timechart
Bytes privados del proceso (performanceCounters/processPrivateBytes)

Cantidad de memoria no compartida que el proceso supervisado asignó para sus datos.
Bytes Promedio, mín., máx. Instancia de rol en la nube
performanceCounters
| where ((category == "Process" and counter == "Private Bytes") or name == "processPrivateBytes")
| render timechart
Tiempo de procesador (performanceCounters/processorCpuPercentage )

Consumo de CPU de todos los procesos que se ejecutan en la instancia del servidor supervisado.
Porcentaje Promedio, mín., máx. Instancia de rol en la nube
NOTE
La métrica de tiempo del procesador no está disponible para las aplicaciones hospedadas en Azure App Services. Use la
métrica de la CPU de procesos para realizar un seguimiento del uso de la CPU de las aplicaciones web hospedadas en App
Services.
performanceCounters
| where ((category == "Processor" and counter == "% Processor Time") or name == "processorCpuPercentage")
| render timechart
Métricas del servidor

Llamadas de dependencia (dependencies/count)
Esta métrica está relacionada con el número de llamadas de dependencia.
dependencies
| render barchart
Duración de la dependencia (dependencies/duration)

Esta métrica hace referencia a la duración de las llamadas de dependencia.
dependencies
| extend dependency_duration = iif(itemType == 'dependency',duration,todouble(''))
| extend _sum = dependency_duration
| extend _sum = _sum*_count
| summarize sum(_sum)/sum(_count) by bin(timestamp, 1m)
| render timechart
Solicitudes de servidor (requests/count)

Esta métrica refleja el número de solicitudes de servidor entrantes que recibió la aplicación web.
requests
| render barchart
Tiempo de respuesta del servidor (requests/duration)

Esta métrica refleja el tiempo que tardaron los servidores en procesar las solicitudes entrantes.
requests
| extend request_duration = iif(itemType == 'request', duration, todouble(''))
| extend _sum = request_duration
| extend _sum = _sum*_count
| render timechart
Métricas de uso
Tiempo de carga de la vista de página (pageViews/duration)
Esta métrica hace referencia a la cantidad de tiempo que tardaron en cargarse los eventos de PageView.
pageViews
| extend pageView_duration = iif(itemType == 'pageView', duration, todouble(''))
| extend _sum = pageView_duration
| render barchart
Vistas de página (pageViews/count)

Recuento de eventos de PageView registrados con la API de Application Insights TrackPageView().
pageViews
| summarize sum(itemCount) by bin(timestamp, 1h)
| render barchart
Sesiones (sessions/count)
Esta métrica hace referencia al recuento de distintos identificadores de sesión.
union traces, requests, pageViews, dependencies, customEvents, availabilityResults, exceptions, customMetrics,

browserTimings
| where notempty(session_Id)
| summarize dcount(session_Id) by bin(timestamp, 1h)
| render barchart
Seguimientos (traces/count)
Recuento de instrucciones de seguimiento registradas con la llamada API de Application Insights TrackTrace().
traces
| summarize sum(itemCount) by bin(timestamp, 1h)
| render barchart
Usuarios (users/count)
Número de usuarios distintos que han tenido acceso a la aplicación. La precisión de esta métrica puede verse
afectada significativamente mediante el uso del filtrado y el muestreo de telemetría.

browserTimings
| where notempty(user_Id)
| summarize dcount(user_Id) by bin(timestamp, 1h)
| render barchart
Usuarios, autenticados (users/authenticated)

Número de usuarios distintos que se han autenticado en la aplicación.

browserTimings
| where notempty(user_AuthenticatedId)
| summarize dcount(user_AuthenticatedId) by bin(timestamp, 1h)
| render barchart
Uso de Búsqueda en Application Insights
Búsqueda es una característica de Application Insights que se usa para buscar y explorar
elementos de telemetría individuales, como vistas de páginas, excepciones o solicitudes web. Y
puede ver los seguimientos de registros y eventos que haya codificado.
(Para consultas más complejas sobre los datos, use Analytics).
¿Dónde verá Search?

En el Portal de Azure
Puede abrir la búsqueda de diagnóstico en la pestaña Información general de Application
Insights de la aplicación (que se encuentra en la barra superior) o en Investigar a la izquierda.
Vaya al menú desplegable Tipos de evento para ver una lista de elementos de telemetría:
solicitudes de servidor, vistas de página, eventos personalizados que haya codificado, etc. En la
parte superior de la lista de resultados hay un gráfico de resumen que muestra los recuentos
de eventos con el paso del tiempo.
Haga clic en el menú desplegable o en Actualizar para obtener los nuevos eventos.
En Visual Studio
En Visual Studio, también hay una ventana de Búsqueda de Application Insights. Esta ventana
resulta muy útil para mostrar eventos de telemetría generados por la aplicación que está
depurando. Pero también puede mostrar los eventos recopilados desde la aplicación publicada
en Azure Portal.
Abra la ventana de búsqueda en Visual Studio:
La ventana de búsqueda tiene características similares al portal web:
La pestaña Track Operation (Seguimiento de operaciones) está disponible cuando se abre una
solicitud o una vista de página. Una "operación" es una secuencia de eventos que está asociada
a una sola solicitud o vista de página. Por ejemplo, llamadas de dependencia, excepciones,
registros de seguimiento y eventos personalizados pueden ser parte de una única operación.
La pestaña Track Operation (Seguimiento de operaciones) muestra gráficamente el tiempo y la
duración de estos eventos con respecto a la solicitud o vista de página.
Inspección de elementos individuales

Seleccione cualquier elemento de telemetría para ver los campos clave y los elementos
relacionados.
Esto iniciará la vista de detalles de una transacción completa.
Filtro de los tipos de evento

Abra el menú desplegable Tipos de evento y elija los tipos de evento que quiere ver. (Si,
posteriormente, quiere restaurar los filtros, haga clic en Restablecer).
Los tipos de evento son:
Seguimiento - registros de diagnóstico, como llamadas a TrackTrace, log4Net, NLog y
System.Diagnostic.Trace.
Solicitud - solicitudes HTTP recibidas por la aplicación de servidor, como páginas, scripts,
imágenes, archivos de estilo y datos. Estos eventos se utilizan para crear los gráficos de
información general de solicitudes y respuestas.
Vista de página - es la telemetría enviada por el cliente web , que se usa para crear
informes de vistas de página.
Evento personalizado - si ha insertado llamadas a TrackEvent() para supervisar el uso ,
puede buscarlas aquí.
Excepción - excepciones no detectadas en el servidor y las que se registran mediante
TrackException().
Dependencia: - llamadas desde su aplicación de servidor a otros servicios, como API de
REST o bases de datos, y llamadas de AJAX desde su código de cliente.
Disponibilidad : resultados de pruebas de disponibilidad.
Filtro de los valores de propiedad

Puede filtrar eventos por los valores de sus propiedades. Las propiedades disponibles
dependen de los tipos de evento que haya seleccionado. Haga clic en el icono de filtro
para comenzar.
El hecho de no elegir ningún valor de una propiedad en particular tiene el mismo efecto que
elegir todos los valores. Se desactiva el filtrado en esa propiedad.
Observe que los recuentos a la derecha de los valores de filtro muestran cuántas repeticiones
hay en el conjunto filtrado actual.
Búsqueda de eventos con la misma propiedad

Para buscar todos los elementos con el mismo valor de propiedad, escríbalo en la barra de
búsqueda o haga clic en la casilla al examinar las propiedades en la pestaña de filtro.
Búsqueda de los datos
NOTE
Para escribir consultas más complejas, abra Registros (Analytics) desde la parte superior de la hoja
Buscar.
Puede buscar términos en cualquiera de los valores de propiedad. Esto es útil si ha escrito
eventos personalizados con valores de propiedad.
Quizás desee establecer un intervalo de tiempo, dado que las búsquedas en un intervalo más
corto son más rápidas.
Busque palabras completas, no subcadenas. Use comillas con los caracteres especiales.
ST RIN G N O EN C O N T RA DO EN C O N T RA DO
ST RIN G N O EN C O N T RA DO EN C O N T RA DO
HomeController.About home homecontroller

controller about
out "homecontroller.about"
Estados Unidos Uni united

ted states
united AND states
"united states"
A continuación se muestran las expresiones de búsqueda que puede utilizar:
C O N SULTA DE E JEM P LO EF EC TO
apple Busca todos los eventos del intervalo de tiempo

cuyos campos incluyen la palabra "apple".
apple AND banana Busca eventos que contienen ambos términos.

apple banana Utilizar "AND" en mayúsculas, no "and".
Forma abreviada.
apple OR banana Buscar eventos que contengan cualquiera de los

dos términos. Usar "OR" no "or".
apple NOT banana Buscar eventos que contengan un término pero no

el otro.
muestreo
Si la aplicación genera una gran cantidad de datos de telemetría (y está usando la versión
2.0.0-beta3 o posterior del SDK de ASP.NET), el módulo de muestreo adaptable reduce
automáticamente el volumen que se envía al portal mediante el envío de solamente una
fracción representativa de los eventos. Sin embargo, los eventos relacionados con la misma
solicitud se seleccionan o deseleccionan como grupo, por lo que puede navegar entre ellos.
Más información sobre el muestreo.
Creación de elemento de trabajo

Puede crear un error en GitHub o en Azure DevOps, con información de cualquier elemento de
telemetría.
Para ir a la vista de detalles de la transacción de un extremo a otro, haga clic en cualquier
elemento de telemetría y seleccione Crear elemento de trabajo .
La primera vez que lo haga, se le pedirá que configure un vínculo a la organización y el
proyecto de Azure DevOps.
(También puede configurar el vínculo en la pestaña Elementos de trabajo).
Envío de más telemetría a Application Insights

Además de la telemetría inmediata enviada por el SDK de Application Insights, puede:
Capturar seguimientos de registros de su plataforma de registro de favoritos en .NET o
Java. Esto significa que puede buscar en los seguimientos de registros y correlacionarlos
con vistas de página, excepciones y otros eventos.
Escribir código para enviar eventos personalizados, vistas de página y excepciones.
Aprender a enviar registros y telemetría personalizada a Application Insights.
¿Qué cantidad de datos se conserva?
Consulte Resumen de límites.
¿Cómo puedo ver datos POST en mis solicitudes de servidor?
Aunque no registramos los datos POST automáticamente, puede usar TrackTrace o llamadas de
registro. Coloque los datos POST en el parámetro de mensaje. No puede filtrar por el mensaje
de la misma forma que con las propiedades, pero el límite de tamaño es mayor.
Pasos siguientes
Escribir consultas complejas en Analytics
Envío de registros y telemetría personalizada a Application Insights.
Configuración de pruebas de disponibilidad y de capacidad de respuesta
Generación de perfiles de aplicaciones de
producción en Azure con Application Insights
Habilitación de Application Insights Profiler para la aplicación

Azure Application Insights Profiler proporciona un seguimiento del rendimiento de las aplicaciones que se
ejecutan en producción en Azure. Profiler captura los datos automáticamente a escala sin que afecte de forma
negativa a los usuarios. Profiler le ayuda a identificar la ruta de acceso "activa" al código que tarda más tiempo
cuando se atiende una solicitud web determinada.
Profiler funciona con aplicaciones .NET implementadas en los siguientes servicios de Azure. En los vínculos
siguientes se pueden encontrar instrucciones específicas para habilitar Profiler para cada tipo de servicio.
Azure App Service
Azure Virtual Machines y Virtual Machine Scale Sets
VERSIÓN PRELIMINAR Aplicaciones web con Linux en Azure para ASP.NET Core
Si ha habilitado Profiler, pero no ve los seguimientos, consulte nuestra Guía de solución de problemas.
Visualización de datos de Profiler

Para que Profiler cargue los seguimientos, la aplicación debe administrar las solicitudes de forma activa. Si está
realizando un experimento, puede generar solicitudes dirigidas a la aplicación web mediante Pruebas de
rendimiento de Application Insights. Si acaba de habilitar Profiler, puede ejecutar una breve prueba de carga.
Mientras se ejecuta la prueba de carga, presione el botón Generar perfiles ahora en el panel Profiler
Settings (Configuración de Profiler). Una vez que Profiler está en ejecución, genera perfiles aleatoriamente una
vez cada hora aproximadamente y durante dos minutos. Si la aplicación está controlando un flujo constante de
solicitudes, Profiler carga los seguimientos cada hora.
Después de que la aplicación reciba tráfico y Profiler haya tenido tiempo de cargar los seguimientos, podrá
verlos. Este proceso puede tardar entre 5 y 10 minutos. Para ver los seguimientos, vaya al panel Performance
(Rendimiento), seleccione Take Actions (Realizar acciones) y, luego, seleccione el botón Seguimientos de
Profiler .
Seleccione una muestra para mostrar un desglose de nivel de código del tiempo dedicado a ejecutar la solicitud.
El explorador de seguimiento muestra la siguiente información:

Mostrar ruta de acceso activa : abre el nodo hoja más grande o al menos algo que se aproxime. En la
mayoría de los casos, este nodo está cerca de un cuello de botella de rendimiento.
Etiqueta : nombre de la función o el evento. El árbol muestra una combinación de código y eventos que se
han producido (como, por ejemplo eventos HTTP y SQL). El evento superior representa la duración total de la
solicitud.
Transcurrido : el intervalo de tiempo entre el inicio y el final de la operación.
Cuándo : el momento en que se ejecutó la función o el evento con relación a otras funciones.
Cómo leer datos de rendimiento

Profiler de servicio de Microsoft usa una combinación de método de muestreo e instrumentación para analizar el
rendimiento de la aplicación. Cuando la colección detallada está en curso, el generador de perfiles del servicio
muestrea cada milisegundo el puntero de instrucción de las CPU de todas las máquinas. Cada una de las
muestras captura toda la pila de llamadas del subproceso que se está ejecutando actualmente. Esto proporciona
información detallada sobre lo que dicho subproceso estaba haciendo, con un grado de abstracción tanto de
nivel alto como bajo. Profiler de servicio también recopila otros eventos para realizar el seguimiento de la
causalidad y la correlación de actividades, como eventos de cambio de contexto, eventos de biblioteca TPL y
eventos de grupo de subprocesos.
La pila de llamadas que se muestra en la vista de escala de tiempo es el resultado del muestreo y la
instrumentación. Como cada muestra captura la pila de llamadas completa del subproceso, incluye código de
Microsoft .NET Framework y de otros marcos a los que se haga referencia.
Asignación de objetos (clr!JIT_New o clr!JIT_Newarr1)
clr!JIT_New y clr!JIT_Newarr1 son funciones auxiliares de .NET Framework que asignan memoria desde un
montón administrado. clr!JIT_New se invoca cuando se asigna un objeto. clr!JIT_Newarr1 se invoca cuando
se asigna una matriz de objetos. Estas dos funciones suelen ser rápidas y tardan relativamente poco tiempo. Si
clr!JIT_New o clr!JIT_Newarr1 tardan mucho tiempo en la escala de tiempo, significa que el código podría
estar asignando muchos objetos y consumiendo una importante cantidad de memoria.
Código de carga (clr!ThePreStub)
clr!ThePreStub es una función auxiliar de .NET Framework que prepara el código para ejecutarse por primera
vez. Esta ejecución suele incluir, pero sin limitarse a ello, la compilación JIT (Just-In-Time). Para cada método de
C#, se debe invocar clr!ThePreStub una vez como máximo durante un proceso.
Si clr!ThePreStub tarda mucho tiempo con una solicitud, significa que la solicitud es la primera que ejecuta ese
método. El entorno en tiempo de ejecución de .NET Framework tarda un tiempo considerable en cargar el primer
método. Podría plantearse la posibilidad de usar un proceso de preparación que ejecute esa parte del código
antes de que los usuarios accedan a él, o bien ejecutar el Generador de imágenes nativo (ngen.exe) en sus
ensamblados.
Contención de bloqueo (clr!JITutil_MonContention o clr!JITutil_MonEnterWorker)
clr!JITutil_MonContention o clr!JITutil_MonEnterWorker indican que el subproceso actual está a la espera
de que se libere un bloqueo. Este texto se muestra normalmente al ejecutar una instrucción LOCK de C#, al
invocar el método Monitor.Enter o al invocar un método con el atributo MethodImplOptions.Synchronized .
La contención de bloqueo se produce normalmente cuando un subproceso A adquiere un bloqueo y un
subproceso B intenta adquirir el mismo bloqueo antes de que el subproceso A lo libere.
Código de carga ([COLD])
Si el nombre del método contiene [COLD] , por ejemplo, mscorlib.ni!
[COLD]System.Reflection.CustomAttribute.IsDefined , significa que el entorno en tiempo de ejecución de
.NET Framework es la primera vez que ejecuta código que no está optimizado mediante la optimización guiada
por perfiles. Para cada método, debe presentarse como máximo una vez durante el proceso.
Si el código de carga tarda una cantidad de tiempo considerable con una solicitud, significa que la solicitud es la
primera en ejecutar la parte no optimizada del método. Considere la posibilidad de usar un proceso de
preparación que ejecute esa parte del código antes de que los usuarios accedan e él.
Envío de una solicitud HTTP
Métodos como HttpClient.Send indican que el código está esperando a que finalice una solicitud HTTP.
Operación de base de datos
Métodos como SqlCommand.Execute indican que el código está a la espera de que finalice una operación de
base de datos.
Espera (AWAIT_TIME)
AWAIT_TIME indica que el código está a la espera de que finalice otra tarea. Este retraso sucede normalmente
con la instrucción AWAIT de C#. Cuando el código efectúa una instrucción AWAIT de C#, el subproceso se
desenreda y devuelve el control al grupo de subprocesos, y no hay ningún subproceso bloqueado a la espera de
que finalice AWAIT . Pero, lógicamente, el subproceso que realizó AWAIT está "bloqueado" a la espera de que
finalice la operación. La instrucción AWAIT_TIME indica el tiempo de bloqueo a la espera de que finalice la tarea.
Tiempo de bloqueo
BLOCKED_TIME indica que el código está a la espera de que otro recurso esté disponible. Por ejemplo, podría
estar esperando un objeto de sincronización, a que un subproceso esté disponible o a que termine una solicitud.
Async no administrada
.NET Framework emite eventos ETW y pasa identificadores de actividad entre subprocesos para que se pueda
realizar un seguimiento de las llamadas asincrónicas entre subprocesos. Tanto al código no administrado (código
nativo) como a algunos estilos anteriores les faltan estos eventos e identificadores de actividad, de modo que el
generador de perfiles no puede informar sobre qué subproceso y qué funciones se ejecutan en el subproceso.
Esto se etiqueta como "Async no administrada" en la pila de llamadas. Si descarga el archivo ETW, es posible que
pueda usar PerfView para obtener más información sobre lo que sucede.
Tiempo de CPU
La CPU está ocupada ejecutando las instrucciones.
Tiempo de disco
La aplicación está ejecutando operaciones de disco.
Tiempo de red
La aplicación está ejecutando operaciones de red.
Columna Cuándo
La columna Cuándo es una visualización de cómo varían con el tiempo las muestras INCLUSIVAS recopiladas
para un nodo. El intervalo total de la solicitud se divide en 32 depósitos de tiempo. Las muestras inclusivas para
ese nodo se acumulan en esos 32 depósitos. Cada depósito se representa con una barra. El alto de la barra
representa un valor escalado. En el caso de nodos marcados CPU_TIME o BLOCKED_TIME , o cuando existe una
relación obvia de consumo de un recurso (por ejemplo, CPU, disco o subproceso), la barra representa el
consumo de uno de esos recursos durante el depósito. Para estas métricas, puede obtener un valor superior al
100 % si consume varios recursos. Por ejemplo, si por término medio usa dos CPU a lo largo de un intervalo,
consigue el 200 %.
Limitaciones
El período de retención de datos predeterminado es de cinco días. El número máximo de datos ingerido al día es
de 10 GB.
No hay ningún cargo por el uso del servicio Profiler. Para poder usarlo, la aplicación web debe estar hospedada
al menos en el nivel básico de la característica Web Apps de Azure App Service.
Sobrecarga y algoritmo de muestreo

Profiler se ejecuta de manera aleatoria dos minutos cada hora en cada máquina virtual que hospede la aplicación
que tiene habilitado Profiler para capturar seguimientos. Al ejecutarse Profiler, agrega una sobrecarga de la CPU
del 5 al 15 % al servidor.
Pasos siguientes
Habilite Application Insights Profiler para la aplicación de Azure. Consulte también:
App Services
Generación de perfiles de aplicaciones activas de
Azure App Service con Application Insights
Puede ejecutar Profiler en aplicaciones ASP.NET y ASP.NET Core que se ejecutan en Azure App Service con el nivel
de servicio Básico o superior. Actualmente, la habilitación de Profiler en Linux solo es posible a través de este
método.
Habilitación de Profiler en la aplicación

Para habilitar Profiler en una aplicación, siga las instrucciones que se indican a continuación. Si está ejecutando
otro tipo de servicio de Azure, aquí encontrará instrucciones para habilitar Profiler en otras plataformas
compatibles:
Cloud Services
Aplicaciones de Service Fabric
Máquinas virtuales
Application Insights Profiler viene preinstalado en el entorno de ejecución de App Services. Los pasos siguientes le
mostrarán cómo habilitarlo para App Service. Siga estos pasos incluso si ha incluido el SDK de App Insights en la
aplicación en el momento de la compilación.
1. Vaya al panel de control de Azure y busque la instancia de App Service.
2. Habilite a la opción "Siempre disponible" para el servicio de aplicación. Puede encontrar esta opción en
Opciones , página Configuración (consulte la captura de pantalla en el paso siguiente) y haga clic en la
pestaña Configuración general .
3. Vaya a la página Configuración > Application Insights .
4. Siga las instrucciones que aparecen en el panel para crear un nuevo recurso o seleccione un recurso de App
Insights existente para supervisar la aplicación. También, asegúrese de que Profiler esté activado . Si el
recurso de Application Insights está en otra suscripción de App Service, no puede usar esta página para
configurar Application Insights. Sin embargo, puede hacerlo manualmente creando la configuración de la
aplicación necesaria por usted mismo. La siguiente sección contiene instrucciones para habilitar Profiler de
forma manual.
5. Profiler está habilitado con una configuración de aplicación de App Services.
Habilitación de Profiler manualmente o con Azure Resource Manager

Application Insights Profiler puede habilitarse mediante la creación de la configuración de la aplicación para
Azure App Service. La página con las opciones mostradas anteriormente crea esta configuración de aplicación de
forma automática. Sin embargo, es posible automatizar la creación de estas opciones mediante una plantilla u
otros medios. Esta configuración también funciona si el recurso de Application Insights está en otra suscripción de
Azure App Service. Estos son los valores necesarios para habilitar el generador de perfiles:
C O N F IGURA C IÓ N DE A P L IC A C IÓ N VA L UE
APPINSIGHTS_INSTRUMENTATIONKEY iKey para el recurso de Application Insights
APPINSIGHTS_PROFILERFEATURE_VERSION 1.0.0
DiagnosticServices_EXTENSION_VERSION ~3
Puede establecer estos valores mediante las plantillas de Azure Resource Manager, Azure PowerShell o la CLI de
Azure.
Habilitación de Profiler para otras nubes manualmente
Si quiere habilitar Profiler para otras nubes, puede usar la siguiente configuración de aplicación.
C O N F IGURA C IÓ N DE A P L IC A C IÓ N VA LO RES DE US GO VERN M EN T N UB E DE C H IN A
ApplicationInsightsProfilerEndpoint https://agent.serviceprofiler.azure.us https://profiler.applicationinsights.azure.cn
ApplicationInsightsEndpoint https://dc.applicationinsights.us https://dc.applicationinsights.azure.cn
Deshabilitación de Profiler
Para detener o reiniciar Profiler en una instancia de la aplicación, vaya a WebJobs y detenga el trabajo web
llamado ApplicationInsightsProfiler3. Incluso si el generador de perfiles se deshabilita mediante el modificador de
la página de Application Insights como se describió anteriormente, el proceso del generador de perfiles se seguirá
ejecutando. El generador de perfiles comprobará si está habilitado. Si está deshabilitado, entrará en suspensión
durante un tiempo antes de volver a realizar la comprobación. Si está deshabilitado, no realizará la generación de
perfiles. Si deshabilita este trabajo web, el proceso del generador de perfiles no se ejecutará, ni siquiera para
comprobar si está habilitado.
Se recomienda tener habilitado el generador de perfiles en todas las aplicaciones para detectar cualquier problema
de rendimiento lo antes posible.
Los archivos de Profiler pueden eliminarse cuando se usa WebDeploy para implementar los cambios en la
aplicación web. Puede evitar la eliminación si se excluye la carpeta App_Data de la eliminación durante la
implementación.
Pasos siguientes
Generación de perfiles de Azure Cloud Services con
También puede implementar Application Insights Profiler en estos servicios:

Azure App Service
Aplicaciones de Azure Service Fabric
Azure Virtual Machines
Application Insights Profiler se instala con la extensión de Azure Diagnostics. Solo tiene que configurar Azure
Diagnostics para instalar Profiler y enviar perfiles al recurso de Application Insights.
Habilitación de Profiler para Azure Cloud Services

1. Asegúrese de que está utilizando .NET Framework 4.6.1 o una versión posterior. Si usa la familia 4 del
sistema operativo, deberá instalar .NET Framework 4.6.1 o una versión más reciente con una tarea de inicio.
La familia 5 del sistema operativo incluye una versión compatible de .NET Framework de forma
predeterminada.
2. Agregue el SDK de Application Insights a Azure Cloud Services.
Se ha corregido el error en el generador de perfiles que se incluye con WAD para
Cloud Ser vices. La versión más reciente de WAD (1.12.2.0) para Cloud Services funciona con todas las
versiones recientes del SDK de App Insights. Los hosts de Cloud Services actualizarán WAD
automáticamente, pero no es algo inmediato. Para forzar una actualización, puede volver a implementar su
servicio o reiniciar el nodo.
3. Realice un seguimiento de las solicitudes con Application Insights:
Para los roles web de ASP.NET, Application Insights puede realizar un seguimiento de las solicitudes
automáticamente.
Para los roles de trabajo, agregue código para realizar el seguimiento de solicitudes.
4. Configure la extensión de Azure Diagnostics para habilitar Profiler:
a. Busque el archivo diagnostics.wadcfgx de Azure Diagnostics correspondiente a su rol de aplicación, como
se muestra aquí:
Si no encuentra el archivo, consulte Set up diagnostics for Azure Cloud Services and Virtual Machines
(Configuración de diagnósticos para Azure Cloud Services y Virtual Machines).
b. Agregue la siguiente sección SinksConfig como elemento secundario de WadCfg :
<WadCfg>
<DiagnosticMonitorConfiguration>...</DiagnosticMonitorConfiguration>
<SinksConfig>
<Sink name="MyApplicationInsightsProfiler">

<ApplicationInsightsProfiler>00000000-0000-0000-0000-000000000000</ApplicationInsightsProfiler>
</Sink>
</SinksConfig>
</WadCfg>
NOTE
Si el archivo diagnostics.wadcfgx también contiene otro receptor de tipo ApplicationInsights, las tres claves de
instrumentación siguientes tienen que coincidir:
La clave que usa la aplicación.
La clave que usa el receptor ApplicationInsights.
La clave que usa el receptor ApplicationInsightsProfiler.
Puede encontrar el valor real de la clave de instrumentación que usa el receptor ApplicationInsights en los
archivos ServiceConfiguration.*.cscfg. Después de la versión de Azure SDK para Visual Studio 15.5, solo es preciso
que coincidan las claves de instrumentación que usan la aplicación y el receptor ApplicationInsightsProfiler.
5. Implemente el servicio con la nueva configuración de Diagnostics, y Application Insights Profiler se

configurará para ejecutarse en el servicio.
Pasos siguientes
Genere tráfico para su aplicación (por ejemplo, inicie una prueba de disponibilidad). A continuación, espere de
10 a 15 minutos para que se empiecen a enviar seguimientos a la instancia de Application Insights.
Consulte Seguimientos de Profiler en Azure Portal.
Para solucionar los problemas de Profiler, consulte Solución de problemas de Profiler.
Generación de perfiles de aplicaciones de Azure
Service Fabric en vivo con Application Insights
También puede implementar Application Insights Profiler en estos servicios:

Azure App Service
Configuración de la definición de implementación del entorno

Application Insights Profiler se incluye con Azure Diagnostics. Puede instalar la extensión de Azure Diagnostics
mediante una plantilla de Azure Resource Manager para el clúster de Service Fabric. Obtenga una plantilla que
instale Azure Diagnostics en un clúster de Service Fabric.
Para configurar su entorno, realice las siguientes acciones:
1. Profiler admite .NET Framework y .NET Core. Si usa .NET Framework, asegúrese de que usa .NET
Framework 4.6.1 o una versión posterior. Basta con confirmar que el sistema operativo implementado es
Windows Server 2012 R2 o posterior. Profiler admite .NET Core 2.1 y aplicaciones más recientes.
2. Busque la extensión de Azure Diagnostics en el archivo de plantilla de implementación.

3. Agregue la siguiente sección SinksConfig como elemento secundario de WadCfg . Reemplace el valor de la
propiedad ApplicationInsightsProfiler por su propia clave de instrumentación de Application Insights:
"SinksConfig": {
"Sink": [
{
"name": "MyApplicationInsightsProfilerSink",
"ApplicationInsightsProfiler": "00000000-0000-0000-0000-000000000000"
}
]
}
Para obtener información acerca de cómo agregar la extensión de Diagnostics a una plantilla de
implementación, consulte Uso de la supervisión y el diagnóstico con una máquina virtual Windows y
plantillas de Azure Resource Manager.
4. Implemente el clúster de Service Fabric mediante la plantilla de Azure Resource Manager.
Si la configuración es correcta, Application Insights Profiler se instala y se habilita cuando está instalada la
extensión de Azure Diagnostics.
5. Agregue Application Insights a la aplicación de Service Fabric.
Para que Profiler pueda recopilar los perfiles de las solicitudes, la aplicación debe supervisar las
operaciones con Application Insights. Para las API sin estado, puede consultar las instrucciones para el
seguimiento de las solicitudes para la generación de perfiles. Para obtener más información sobre la
supervisión de operaciones personalizadas en otros tipos de aplicaciones, consulte Seguimiento de las
operaciones personalizadas con el SDK de .NET para Application Insights.
6. Vuelva a implementar la aplicación.
Pasos siguientes
Para obtener ayuda para solucionar problemas de Profiler, consulte la sección Solución de problemas de
Profiler.
Generación de perfiles de aplicaciones web en
ejecución en una máquina virtual o un conjunto de
escalado de máquinas virtuales de Azure mediante
Application Insights Profiler
NOTE
También puede implementar Azure Application Insights Profiler en estos servicios:

Azure App Service
Implementación de Profiler en una máquina virtual o un conjunto de

En este artículo se muestran los pasos necesarios para que Application Insights Profiler se ejecute en una máquina
virtual (VM) de Azure o un conjunto de escalado de máquinas virtuales de Azure. Profiler se instala con la
extensión de Azure Diagnostics para VM. Configure la extensión para ejecutar Profiler y compile el SDK de
Application Insights en la aplicación.
1. Agregue el SDK de Application Insights a la aplicación de ASP.NET.
Para ver los perfiles para las solicitudes, debe enviar telemetría de solicitudes a Application Insights.
2. Instale la extensión de Azure Diagnostics en la VM. Para consultar ejemplos de plantillas de Azure Resource
Manager completas:
Máquina virtual
Conjunto de escalado de máquinas virtuales
El elemento clave es ApplicationInsightsProfilerSink en WadCfg. Para indicar a Azure Diagnostics que
habilite Profiler para enviar datos a la clave iKey, agregue otro receptor a esta sección.
"SinksConfig": {
"Sink": [
{
"name": "ApplicationInsightsSink",
"ApplicationInsights": "85f73556-b1ba-46de-9534-606e08c6120f"
},
{
"name": "MyApplicationInsightsProfilerSink",
"ApplicationInsightsProfiler": "85f73556-b1ba-46de-9534-606e08c6120f"
}
]
},
3. Implemente la definición de implementación de entorno modificada.

Al aplicar las modificaciones, generalmente se realiza una implementación de plantilla completa o una
publicación basada en el servicio en la nube mediante cmdlets de PowerShell o Visual Studio.
Los siguientes comandos de PowerShell se pueden usar como un enfoque alternativo para las máquinas
virtuales existentes que solo afecta a la extensión de Azure Diagnostics. Agregue el valor ProfilerSink que
se mencionó anteriormente a la configuración que devuelve el comando Get-AzVMDiagnosticsExtension.
Luego, pase la configuración actualizada al comando Set-AzVMDiagnosticsExtension.
$ConfigFilePath = [IO.Path]::GetTempFileName()
# After you export the currently deployed Diagnostics config to a file, edit it to include the
ApplicationInsightsProfiler sink.
(Get-AzVMDiagnosticsExtension -ResourceGroupName "MyRG" -VMName "MyVM").PublicSettings | Out-File -
Verbose $ConfigFilePath
# Set-AzVMDiagnosticsExtension might require the -StorageAccountName argument
# If your original diagnostics configuration had the storageAccountName property in the
protectedSettings section (which is not downloadable), be sure to pass the same original value you had
in this cmdlet call.
Set-AzVMDiagnosticsExtension -ResourceGroupName "MyRG" -VMName "MyVM" -DiagnosticsConfigurationPath
$ConfigFilePath
4. Si la aplicación deseada se ejecuta mediante IIS, habilite la característica IIS Http Tracing de Windows.
a. Establezca el acceso remoto al entorno y, a continuación, use la ventana Agregar características de
Windows. También puede ejecutar el siguiente comando en PowerShell (como administrador):
Enable-WindowsOptionalFeature -FeatureName IIS-HttpTracing -Online -All
b. Si el establecimiento del acceso remoto supone un problema, puede usar la CLI de Azure para ejecutar el
siguiente comando:
az vm run-command invoke -g MyResourceGroupName -n MyVirtualMachineName --command-id

RunPowerShellScript --scripts "Enable-WindowsOptionalFeature -FeatureName IIS-HttpTracing -Online -All"
5. Implementación de aplicación.
Establecimiento del receptor de Profiler con Azure Resource Explorer

Todavía no tenemos forma de establecer el receptor de Application Insights Profiler desde el portal. En lugar de
usar PowerShell como se describió anteriormente, puede usar Azure Resource Explorer para establecer el receptor.
Pero tenga en cuenta que, si vuelve a implementar la máquina virtual, el receptor se perderá. Deberá actualizar la
configuración que usa al implementar la VM para conservar este ajuste.
1. Compruebe que la extensión Windows Azure Diagnostics esté instalada. Para ello, revise las extensiones
instaladas para la máquina virtual.
2. Busque la extensión de diagnóstico de VM para su máquina virtual. Vaya a https://resources.azure.com.

Expanda el grupo de recursos, Microsoft.Compute virtualMachines, el nombre de la máquina virtual y las
extensiones.
3. Agregue el receptor de Application Insights Profiler al nodo SinksConfig en WadCfg. Si todavía no tiene una
sección SinksConfig, es posible que tenga que agregar una. Asegúrese de especificar la iKey de Application
Insights correspondiente en la configuración. Deberá cambiar el modo de los exploradores a
Lectura/escritura en la esquina superior derecha y presionar el botón "Editar" azul.
4. Cuando haya terminado de editar la configuración, presione "Put". Si la operación Put se realiza
correctamente, aparecerá una marca verde en medio de la pantalla.
¿Puede ejecutarse Profiler en servidores locales?

No tenemos planes para que Application Insights Profiler sea compatible con servidores locales.
Pasos siguientes
Para obtener ayuda para solucionar problemas de Profiler, consulte la sección Solución de problemas de
Profiler.
Generación de perfiles de aplicaciones web de Azure
en Linux de ASP.NET Core con Application Insights
Profiler
Esta funcionalidad actualmente está en su versión preliminar.

Averigüe cuánto tiempo se invierte en cada método de la aplicación web activa con Application Insights.
Application Insights Profiler ahora está disponible para las aplicaciones web de ASP.NET Core hospedadas en Linux
en Azure App Service. Esta guía proporciona instrucciones paso a paso sobre cómo se pueden recopilar los
seguimientos de Profiler para las aplicaciones web de ASP.NET Core en Linux.
Después de completar este tutorial, la aplicación puede recopilar los seguimientos de Profiler igual que los que se
muestran en la imagen. En este ejemplo, el seguimiento de Profiler indica que una solicitud web en particular es
lenta porque la mayor parte del tiempo se dedica a esperar. La ruta de acceso activa en el código que está
ralentizando la aplicación se marca con un icono de llama. El método About de la sección HomeController está
ralentizando la aplicación web porque llama a la función Thread.Sleep .
Prerrequisitos
Las instrucciones siguientes se aplican a todos los entornos de desarrollo Windows, Linux y Mac:
Instale SDK 2.1.2 de .NET Core o posterior.
Instale Git siguiendo las instrucciones que encontrará en Getting Started - Installing Git (Introducción:
instalación de Git).
Configuración del proyecto de forma local

1. Abra una ventana del símbolo del sistema en la máquina. Las instrucciones siguientes se aplican a todos los
entornos de desarrollo Windows, Linux y Mac.
2. Cree una aplicación web MVC de ASP.NET Core:
dotnet new mvc -n LinuxProfilerTest
3. Cambie el directorio de trabajo a la carpeta raíz para el proyecto.

4. Agregue el paquete NuGet para recopilar los seguimientos de Profiler:
dotnet add package Microsoft.ApplicationInsights.Profiler.AspNetCore
5. Habilitación de Application Insights en Program.cs:

.UseApplicationInsights() // Add this line of code to Enable Application Insights
.UseStartup<Startup>();
6. Habilitación de Profiler en Startup.cs:

{
services.AddServiceProfiler(); // Add this line of code to Enable Profiler
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
7. Agregue una línea de código a la sección HomeController.cs para retardar de manera aleatoria unos
segundos:
using System.Threading;
...
public IActionResult About()

{
Random r = new Random();
int delay = r.Next(5000, 10000);
Thread.Sleep(delay);
return View();
}
8. Guarde y confirme los cambios en el repositorio local:
git init
git add .
git commit -m "first commit"
Creación de la aplicación web en Linux para hospedar el proyecto

1. Cree el entorno de aplicación web mediante App Service en Linux:
2. Cree las credenciales de implementación:
NOTE
Anote la contraseña que se utilizará más adelante al implementar la aplicación web.
3. Elija las opciones de implementación. Para configurar un repositorio de Git local en la aplicación web, siga
las instrucciones de Azure Portal. Automáticamente se crea un repositorio de Git.
Para más opciones de implementación, consulte la documentación de App Service.
Implementación del proyecto

1. En la ventana del símbolo del sistema, vaya a la carpeta raíz para el proyecto. Agregue el repositorio de Git
remoto para que apunte a una de las instancias de App Service:
git remote add azure https://<username>@<app_name>.scm.azurewebsites.net:443/<app_name>.git
Use el nombre de usuario que empleó para crear las credenciales de implementación.
Use el nombre de aplicación que usó para crear la aplicación web mediante App Service en Linux.
2. Implemente el proyecto insertando los cambios en Azure:
git push azure master
Debería ver una salida similar al ejemplo siguiente:
Counting objects: 9, done.

Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (9/9), 1.78 KiB | 911.00 KiB/s, done.
Total 9 (delta 3), reused 0 (delta 0)
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id 'd7369a99d7'.
remote: Generating deployment script.
remote: Running deployment command...
remote: Handling ASP.NET Core Web Application deployment.
remote: ......
remote: Restoring packages for /home/site/repository/EventPipeExampleLinux.csproj...
remote: .
remote: Installing Newtonsoft.Json 10.0.3.
remote: Installing Microsoft.ApplicationInsights.Profiler.Core 1.1.0-LKG
...
Adición de Application Insights para supervisar las aplicaciones web

1. Cree un recurso de Application Insights.
2. Copie el valor de iKey del recurso de Application Insights y configure las opciones siguientes en sus
aplicaciones web:
APPINSIGHTS_INSTRUMENTATIONKEY: [YOUR_APPINSIGHTS_KEY]
Cuando se cambia la configuración de la aplicación, el sitio se reinicia automáticamente. Tras aplicar la
nueva configuración, Profiler se ejecuta inmediatamente durante dos minutos. Profiler se ejecuta entonces
dos minutos cada hora.
3. Genere cierto tráfico a su sitio web. Puede generar tráfico actualizando la página About (Acerca de) varias
veces.
4. Espere de dos a cinco minutos para que los eventos se agreguen a Application Insights.
5. Vaya al panel Performance (Rendimiento) de Application Insights en Azure Portal. Puede ver los
seguimientos de Profiler en la parte inferior derecha del panel.
Pasos siguientes
Si usa contenedores personalizados hospedados por Azure App Service, siga las instrucciones que se describen en
Enable Service Profiler for a containerized ASP.NET Core application (Habilitación de Profiler de servicio para una
aplicación ASP.NET Core en contenedor) para habilitar Application Insights Profiler.
Si tiene algún problema o sugerencias, notifíquelos en el repositorio de GitHub de Application Insights:
ApplicationInsights-Profiler-AspNetCore: problemas.
Configuración de Application Insights Profiler
Agente de Profiler actualizado

Las características del desencadenador solo funcionan con la versión 2.6 o posterior del agente de Profiler. Si está
ejecutando una instancia de Azure App Service, el agente se actualizará automáticamente. Puede ver qué versión
del agente está ejecutando si va a la dirección URL de KUDU para el sitio web y agrega \DiagnosticServices al final,
de la siguiente manera: https://yourwebsite.scm.azurewebsites.net/diagnosticservices . El trabajo web de
Application Insights Profiler debe tener la versión 2.6 o posterior. Puede forzar una actualización reiniciando la
aplicación web.
Si está ejecutando Profiler en una VM o un servicio en la nube, debe tener instalada la extensión de
Windows Azure Diagnostics (WAD) 16.0.4 o una versión posterior. Puede comprobar la versión de WAD iniciando
sesión en su VM y mirando este directorio:
C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics\1.16.0.4. El nombre del directorio es la versión
de WAD que está instalada. El agente de Azure VM actualizará WAD automáticamente cuando haya nuevas
versiones disponibles.
Página de configuración de Profiler

Para abrir el panel de configuración de Azure Application Insights Profiler, vaya al panel de rendimiento de
Application Insights y seleccione el botón Configurar Profiler .
Esta opción abre una página que tiene este aspecto:

La página Configurar Application Insights Profiler tiene estas características:
C A RA C T ERÍST IC A DESC RIP C IÓ N
Generar perfiles ahora inicia sesiones de generación en todas las aplicaciones

vinculadas a esta instancia de Application Insights.
Desencadenadores Esto le permite configurar desencadenadores que hacen que

se ejecute la instancia de Profiler.
Sesiones de generación de perfiles recientes muestra información acerca de las anteriores sesiones de
generación de perfiles.
Generar perfiles ahora

Esta opción le permite iniciar una sesión de creación de perfiles bajo petición. Cuando haga clic en este vínculo,
todos los agentes de Profiler que envían datos a esta instancia de Application Insights comenzarán a capturar un
perfil. Después de 5 a 10 minutos, la sesión de creación del perfil se mostrará en la lista que tiene a continuación.
Para que un usuario desencadene manualmente una sesión de Profiler, requiere como mínimo tener "acceso de
escritura" en su rol para el componente de Application Insights. En la mayoría de los casos, este acceso se obtiene
automáticamente y no es necesario realizar ninguna tarea adicional. Si tiene problemas, el rol del ámbito de
suscripción que debe agregar es el rol de "Colaborador de componentes de Application Insights". Obtenga más
información sobre el control de acceso de rol con Azure Monitoring.
Configuración del desencadenador

Al hacer clic en el botón Desencadenadores en la barra de menú, se abre el cuadro de configuración del
desencadenador. Puede configurar el desencadenador para comenzar a generar perfiles cuando el porcentaje de
uso de la CPU o la memoria alcanza el nivel establecido.
Botón de activado o desactivado Activado: el desencadenador puede iniciar Profiler.

Desactivado: el desencadenador no iniciará Profiler.
Umbral de memoria Cuando este porcentaje de memoria está en uso, se iniciará

Profiler.
Duration Se establece el período de tiempo durante el que se ejecutará

Profiler cuando se active.
Recuperación Se establece el período de tiempo durante el cual Profiler

esperará antes de comprobar nuevamente el uso de la
memoria o la CPU después de que se desencadene.
Sesiones de generación de perfiles recientes

En esta sección de la página se muestra información sobre las sesiones recientes de creación de perfiles. Una
sesión de creación de perfiles representa el período de tiempo durante el que el agente de Profiler toma un perfil
de una de las máquinas que hospedan su aplicación. Puede abrir los perfiles de una sesión haciendo clic en una de
las filas. Para cada sesión, mostramos lo siguiente:
Desencadenado en función de Cómo se inició la sesión, ya sea mediante un desencadenador,

la opción Crear perfil o un muestreo predeterminado.
Nombre de la aplicación Nombre de la aplicación de la que se creó el perfil.

Instancia de máquina Nombre de la máquina en la que se ejecutó el agente de

Profiler.
Timestamp Hora en la que se capturó el perfil.
Seguimiento Número de seguimientos que se adjuntaron a solicitudes

individuales.
% de CPU Porcentaje de la CPU que se estaba usando mientras se

ejecutaba Profiler.
% de memoria Porcentaje de memoria que se estaba usando mientras se

ejecutaba Profiler.
Usar pruebas de rendimiento web para generar tráfico en la aplicación

Profiler se puede desencadenar manualmente con un solo clic. Imagine que está ejecutando una prueba de
rendimiento web. Necesitará realizar seguimientos que le ayuden a saber si la aplicación web funciona
correctamente en condiciones de carga. Poder control el momento en que se capturan los seguimientos es
fundamental, ya que sabe cuándo se va a ejecutar la prueba de carga. Sin embargo, con el intervalo de muestreo
aleatorio es posible que se lo pierda.
En las secciones siguientes se ilustra cómo funciona este escenario:
Paso 1: Generación de tráfico a la aplicación web mediante el inicio de una prueba de rendimiento web
Si la aplicación web tiene ya tráfico entrante o si simplemente desea generar tráfico manualmente, omita esta
sección y continúe con el paso 2.
1. En el portal de Application Insights, seleccione Configure > Performance Testing (Configurar > Prueba
de rendimiento).
2. Para iniciar una nueva prueba de rendimiento, seleccione el botón New (Nuevo).
3. En el panel New performance test (Nueva prueba de rendimiento), configure la dirección URL de destino
de la prueba. Acepte la configuración predeterminada y seleccione Run test (Ejecutar prueba) para
empezar a ejecutar la prueba de carga.
En primer lugar, la nueva prueba se pone en cola y,después, pasa al estado en curso.
Paso 2: Inicio de una sesión a petición de Profiler

1. Cuando la prueba de carga esté en ejecución, inicie Profiler para capturar los seguimientos de la aplicación
web mientras se recibe la carga.
2. Vaya al panel de configuración de Profiler .
Paso 3: Visualización de seguimientos
Cuando Profiler deje de ejecutarse, siga las instrucciones de la notificación para ir al panel de rendimiento y ver los
seguimientos.
Pasos siguientes
Habilitar Profiler y ver seguimientos
Escritura de código para realizar el seguimiento de
solicitudes con Application Insights
Para ver los perfiles de la aplicación en la página Rendimiento, Azure Application Insights tiene que realizar un
seguimiento de las solicitudes para la aplicación. Application Insights puede realizar automáticamente un
seguimiento de solicitudes para las aplicaciones que se basan en marcos de trabajo ya instrumentados. Dos
ejemplos son ASP.NET y ASP.NET Core.
Pero para otras aplicaciones, como los roles de trabajo de Azure Cloud Services y las API sin estado de Service
Fabric, es necesario escribir código para indicar a Application Insights dónde empiezan y terminan las solicitudes.
Una vez escrito este código, la telemetría de solicitudes se envía a Application Insights. Puede ver la telemetría en
la página Rendimiento y los perfiles se recopilan para dichas solicitudes.
Para realizar un seguimiento de las solicitudes manualmente, haga lo siguiente:
1. Agregue el código siguiente al principio de la duración de la aplicación:
...
// Replace with your own Application Insights instrumentation key.
TelemetryConfiguration.Active.InstrumentationKey = "00000000-0000-0000-0000-000000000000";
Para más información acerca de la configuración de esta clave de instrumentación global, consulte Using
Service Fabric with Application Insights (Uso de Service Fabric con Application Insights).
2. Con respecto a cualquier parte del código que quiera instrumentar, agregue una instrucción
StartOperation<RequestTelemetry> using alrededor, como se muestra en el ejemplo siguiente:
...
var client = new TelemetryClient();
...
using (var operation = client.StartOperation<RequestTelemetry>("Insert_Your_Custom_Event_Unique_Name"))
{
// ... Code I want to profile.
}
No se permite llamar a StartOperation<RequestTelemetry> dentro de otro ámbito de

StartOperation<RequestTelemetry> . En su lugar, puede usar StartOperation<DependencyTelemetry> en el
ámbito anidado. Por ejemplo:
using (var getDetailsOperation = client.StartOperation<RequestTelemetry>("GetProductDetails"))
{
try
{
ProductDetail details = new ProductDetail() { Id = productId };
getDetailsOperation.Telemetry.Properties["ProductId"] = productId.ToString();
// By using DependencyTelemetry, 'GetProductPrice' is correctly linked as part of the

'GetProductDetails' request.
using (var getPriceOperation = client.StartOperation<DependencyTelemetry>("GetProductPrice"))
{
double price = await _priceDataBase.GetAsync(productId);
if (IsTooCheap(price))
{
throw new PriceTooLowException(productId);
}
details.Price = price;
}
// Similarly, note how 'GetProductReviews' doesn't establish another RequestTelemetry.

using (var getReviewsOperation = client.StartOperation<DependencyTelemetry>("GetProductReviews"))
{
details.Reviews = await _reviewDataBase.GetAsync(productId);
}
getDetailsOperation.Telemetry.Success = true;
return details;
}
catch(Exception ex)
{
getDetailsOperation.Telemetry.Success = false;
// This exception gets linked to the 'GetProductDetails' request telemetry.

client.TrackException(ex);
throw;
}
}
Configuración de Traiga su propio almacenamiento
(BYOS) para Application Insights Profiler y Snapshot
Debugger
¿Qué es Traiga su propio almacenamiento (BYOS) y por qué podría

resultarme últil?
Cuando se usa Application Insights Profiler o Snapshot Debugger, los artefactos generados por la aplicación se
cargan en cuentas de Azure Storage a través de la red pública de Internet. Microsoft paga y controla esas cuentas
para su procesamiento y análisis. Microsoft controla las directivas de administración de la vigencia y el cifrado en
reposo para esos artefactos.
Con Traiga su propio almacenamiento, estos artefactos se cargan en una cuenta de almacenamiento que usted
controla. Esto significa que controla la directiva de cifrado en reposo, la directiva de administración de la vigencia y
el acceso a la red. Sin embargo, será responsable de los costos asociados a esa cuenta de almacenamiento.
NOTE
Si está habilitando Private Link, Traiga su propio almacenamiento es obligatorio. Para obtener más información acerca de
Private Link para Application Insights, consulte la documentación.
Si está habilitando las claves administradas de cliente, Traiga su propio almacenamiento es obligatorio. Para obtener más
información acerca de las claves administradas de cliente, consulte la documentación.
¿Cómo se tiene acceso a la cuenta de almacenamiento?

1. Los agentes que se ejecutan en Virtual Machines o App Service cargarán artefactos (perfiles, instantáneas y
símbolos) en los contenedores de blobs de su cuenta. Este proceso implica ponerse en contacto con el servicio
Application Insights Profiler o Snapshot Debugger para obtener un token de SAS (firma de acceso compartido)
para un nuevo blob en la cuenta de almacenamiento.
2. El servicio Application Insights Profiler o Snapshot Debugger analizará el blob entrante y volverá a escribir los
resultados del análisis y los archivos de registro en el almacenamiento de blobs. Dependiendo de la capacidad
de proceso disponible, este proceso puede producirse en cualquier momento después de la carga.
3. Al ver los seguimientos de Profiler o el análisis de Snapshot Debugger, el servicio capturará los resultados del
análisis del almacenamiento de blobs.
Requisitos previos
Asegúrese de crear la cuenta de almacenamiento en la misma ubicación que el recurso de Application Insights.
Por ejemplo, Si el recurso de Application Insights está en Oeste de EE. UU. 2, la cuenta de almacenamiento debe
estar también en Oeste de EE. UU. 2.
Conceda el rol "Colaborador de datos de blobs de almacenamiento" al "Acceso a almacenamiento de confianza
de servicios de diagnóstico" de la aplicación de AAD en la cuenta de almacenamiento a través de la interfaz de
usuario de Access Control (IAM).
Si está habilitado Private Link, configure la opción adicional para permitir la conexión a nuestro servicio de
confianza de Microsoft desde Virtual Network.
Habilitación de BYOS
Crear cuenta de almacenamiento
Cree una nueva cuenta de almacenamiento (si no la tiene) en la misma ubicación que el recurso de Application
Insights. Si el recurso de Application Insights está en West US 2 , la cuenta de almacenamiento debe estar en
West US 2 .
Concesión de acceso a los servicios de diagnóstico a su cuenta de almacenamiento

Una cuenta de almacenamiento de BYOS se vinculará a un recurso de Application Insights. Puede haber solo una
cuenta de almacenamiento por recurso de Application Insights y ambos deben estar en la misma ubicación. Puede
usar la misma cuenta de almacenamiento con más de un recurso de Application Insights.
En primer lugar, se debe conceder acceso a la cuenta de almacenamiento al servicio Application Insights Profiler y
Snapshot Debugger. Para conceder acceso, agregue el rol Storage Blob Data Contributor a la aplicación de AAD
llamada Diagnostic Services Trusted Storage Access a través de la página de Access Control (IAM) de la cuenta de
almacenamiento, tal como se muestra en la figura 1.0.
Pasos:
1. Haga clic en el botón "Agregar" de la sección "Agregar una asignación de roles".
2. Seleccione rol "Colaborador de datos de blobs de almacenamiento"
3. En la opción "Asignar acceso a", seleccione "Usuario, grupo o entidad de servicio de Azure AD".
4. Búsqueda y selección de la aplicación "Acceso a almacenamiento de confianza de servicios de diagnóstico"
5. Guardar cambios
Figura 1.0
Después de agregar el rol, aparecerá en la sección "Asignaciones de roles", como la figura 1.1.
Figura 1.1
Si está usando también Private Link, se necesita una configuración adicional para permitir la conexión a nuestro
servicio de confianza de Microsoft desde Virtual Network. Consulte la documentación de Seguridad de red de
almacenamiento.
Vinculación de la cuenta de almacenamiento con el recurso de Application Insights
Para configurar BYOS para el diagnóstico en el nivel de código (Profiler/Debugger), hay tres opciones:
Uso de cmdlets de Azure PowerShell
Uso de la interfaz de la línea de comandos de Azure (CLI)
Uso de la plantilla de Azure Resource Manager
Configuración mediante cmdlets de Azure PowerShell
1. Asegúrese de que ha instalado Az PowerShell 4.2.0 o posterior.
Para instalar Azure PowerShell, consulte la documentación oficial de Azure PowerShell.
2. Instale la extensión de PowerShell para Application Insights.
Install-Module -Name Az.ApplicationInsights -Force
3. Inicie sesión con su cuenta de Azure.
Connect-AzAccount -Subscription "{subscription_id}"
Para obtener más información sobre cómo iniciar sesión, consulte la documentación de Connect-AzAccount.
4. Quite la cuenta de almacenamiento anterior vinculada al recurso de Application Insights.
Patrón:
$appInsights = Get-AzApplicationInsights -ResourceGroupName "{resource_group_name}" -Name "

{storage_account_name}"
Remove-AzApplicationInsightsLinkedStorageAccount -ResourceId $appInsights.Id
Ejemplo:
$appInsights = Get-AzApplicationInsights -ResourceGroupName "byos-test" -Name "byos-test-westus2-ai"

5. Conecte la cuenta de almacenamiento con el recurso de Application Insights.

Patrón:
$storageAccount = Get-AzStorageAccount -ResourceGroupName "{resource_group_name}" -Name "

{application_insights_name}"
New-AzApplicationInsightsLinkedStorageAccount -ResourceId $appInsights.Id -
LinkedStorageAccountResourceId $storageAccount.Id
Ejemplo:
$storageAccount = Get-AzStorageAccount -ResourceGroupName "byos-test" -Name "byosteststoragewestus2"

Configuración mediante la CLI de Azure

1. Asegúrese de que ha instalado la CLI de Azure.
Para instalar la CLI de Azure, consulte la documentación oficial de la CLI de Azure.
2. Instale la extensión de la CLI de Application Insights.

Patrón:
az monitor app-insights component linked-storage link --resource-group "{resource_group_name}" --app "

{application_insights_name}" --storage-account "{storage_account_name}"
Ejemplo:
az monitor app-insights component linked-storage link --resource-group "byos-test" --app "byos-test-

westus2-ai" --storage-account "byosteststoragewestus2"
Resultado esperado:
{
"id": "/subscriptions/{subscription}/resourcegroups/byos-
test/providers/microsoft.insights/components/byos-test-westus2-
ai/linkedstorageaccounts/serviceprofiler",
"linkedStorageAccount": "/subscriptions/{subscription}/resourceGroups/byos-
test/providers/Microsoft.Storage/storageAccounts/byosteststoragewestus2",
"name": "serviceprofiler",
"resourceGroup": "byos-test",
"type": "microsoft.insights/components/linkedstorageaccounts"
}
NOTE
Para realizar actualizaciones en las cuentas de almacenamiento vinculadas al recurso de Application Insights, consulte
la documentación de la CLI de Application Insights.
Configuración de la plantilla de Azure Resource Manager

1. Cree un archivo de plantilla de Azure Resource Manager con el siguiente contenido (byos.template.json).
{
"parameters": {
"applicationinsights_name": {
"type": "String"
},
"storageaccount_name": {
"type": "String"
}
},
"variables": {},
"resources": [
{
"name": "[concat(parameters('applicationinsights_name'), '/serviceprofiler')]",
"type": "Microsoft.Insights/components/linkedStorageAccounts",
"properties": {
"linkedStorageAccount": "[resourceId('Microsoft.Storage/storageAccounts',
parameters('storageaccount_name'))]"
}
}
],
"outputs": {}
}
2. Ejecute el siguiente comando de PowerShell para implementar la plantilla anterior (cree una cuenta de
almacenamiento vinculada).
Patrón:
New-AzResourceGroupDeployment -ResourceGroupName "{your_resource_name}" -TemplateFile "

{local_path_to_arm_template}"
Ejemplo:
New-AzResourceGroupDeployment -ResourceGroupName "byos-test" -TemplateFile "D:\Docs\byos.template.json"
3. Proporcione los siguientes parámetros cuando se le solicite en la consola de PowerShell:

application_insights_name Nombre del recurso de Application Insights para habilitar

BYOS.
storage_account_name Nombre del recurso de la cuenta de almacenamiento que

usará como BYOS.
Resultado esperado:
Supply values for the following parameters:

(Type !? for Help.)
application_insights_name: byos-test-westus2-ai
storage_account_name: byosteststoragewestus2
DeploymentName : byos.template
ResourceGroupName : byos-test
Timestamp : 4/16/2020 1:24:57 AM
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
============================== ========================= ==========
application_insights_name String byos-test-westus2-
ai
storage_account_name String
byosteststoragewestus2
Outputs :
DeploymentDebugLogLevel :
4. Habilite el diagnóstico en el nivel de código (Profiler/Debugger) en la carga de trabajo correspondiente a

través de Azure Portal. (App Service > Application Insights)
Figura 2.0
No se admite el esquema de plantilla "{schema_uri}".
Asegúrese de que la propiedad $schema de la plantilla es válida. Debe seguir el patrón siguiente:
https://schema.management.azure.com/schemas/{schema_version}/deploymentTemplate.json#
Asegúrese de que schema_version en la plantilla esté dentro de los valores válidos:
2014-04-01-preview, 2015-01-01, 2018-05-01, 2019-04-01, 2019-08-01 . Mensaje de error:
New-AzResourceGroupDeployment : 11:53:49 AM - Error: Code=InvalidTemplate; Message=Deployment template

validation failed: 'Template schema
'https://schema.management.azure.com/schemas/2020-01-01/deploymentTemplate.json#' is not supported.
Supported versions are
'2014-04-01-preview,2015-01-01,2018-05-01,2019-04-01,2019-08-01'. Please see https://aka.ms/arm-template
for usage details.'.
No se encontró ningún proveedor de recursos registrado para la ubicación "{location}".

Asegúrese de que apiVersion del recurso microsoft.insights/components es 2015-05-01 .
Asegúrese de que apiVersion del recurso linkedStorageAccount es 2020-03-01-preview . Mensaje de error:
New-AzResourceGroupDeployment : 6:18:03 PM - Resource microsoft.insights/components 'byos-test-westus2-

ai' failed with message '{
"error": {
"code": "NoRegisteredProviderFound",
"message": "No registered resource provider found for location 'westus2' and API version '2020-03-
01-preview' for type 'components'. The supported api-versions are '2014-04-01,
2014-08-01, 2014-12-01-preview, 2015-05-01, 2018-05-01-preview'. The supported locations are ', eastus,
southcentralus, northeurope, westeurope, southeastasia, westus2, uksouth,
canadacentral, centralindia, japaneast, australiaeast, koreacentral, francecentral, centralus, eastus2,
eastasia, westus, southafricanorth, northcentralus, brazilsouth, switzerlandnorth,
australiasoutheast'."
}
}'
La ubicación de la cuenta de almacenamiento debe coincidir con la ubicación del componente AI.
Asegúrese de que la ubicación del recurso de Application Insights sea la misma que la de la cuenta de
almacenamiento. Mensaje de error:
New-AzResourceGroupDeployment : 1:01:12 PM - Resource

microsoft.insights/components/linkedStorageAccounts 'byos-test-centralus-ai/serviceprofiler' failed with
message '{
"error": {
"code": "BadRequest",
"message": "Storage account location should match AI component location",
"innererror": {
"trace": [
"System.ArgumentException"
]
}
}
}'
Para solucionar problemas generales de Profiler, consulte la documentación de solución de problemas de Profiler.
Para la solución de problemas generales de Snapshot Debugger, consulte la documentación de solución de
problemas de Snapshot Debugger.

Si tengo habilitado Profiler o Snapshot y he habilitado BYOS, ¿se migrarán mis datos a mi cuenta de
almacenamiento? No, no lo harán.
¿Funcionará BYOS con el cifrado en reposo y la clave administrada de cliente? Sí, para ser precisos, BYOS es
un requisito para tener Profiler/Debugger habilitado con las claves administradas por el cliente.
¿Funcionará BYOS en un entorno aislado de Internet? Sí. De hecho, BYOS es un requisito para escenarios de
redes aisladas.
¿Funcionará BYOS cuando se hayan habilitado tanto las claves administradas de cliente como Private Link?
Sí, esa opción existe.
Si he habilitado BYOS, ¿puedo volver a usar las cuentas de almacenamiento de servicios de diagnóstico para
almacenar los datos recopilados? Sí, pero ya no se admite la migración de datos desde BYOS.
Después de habilitar BYOS, ¿me haré cargo de todos los costos relacionados, que son los derivados del
almacenamiento y las redes? Sí
Solución de problemas de activación o visualización
de Application Insights Profiler
Cau t i on
Hay un error al ejecutar el generador de perfiles con aplicaciones de ASP.NET Core en Azure App Service.
Tenemos una solución, pero tardará unas semanas en implementarse en todo el mundo. Puede solucionar el
error agregando el SDK de Application Insights a la aplicación con las instrucciones que se indican aquí.
Solución general de problemas

Los perfiles solo se cargan si hay solicitudes en la aplicación mientras se ejecuta Profiler
Azure Application Insights Profiler recopila los datos de generación de perfiles durante dos minutos cada hora.
También recopila datos cuando se selecciona el botón Generar perfiles ahora en el panel Configurar
Application Insights Profiler . Pero los datos de generación de perfiles solo se cargan cuando se pueden
adjuntar a una solicitud que se ja realizado mientras se ejecuta Profiler.
Profiler escribe mensajes de seguimiento y eventos personalizados en el recurso de Application Insights. Estos
eventos se pueden usar para ver cómo se ejecuta Profiler. Si cree que Profiler debe ejecutar y capturar
seguimientos, pero estos no se muestran en el panel Rendimiento , puede comprobar el funcionamiento de
Profiler:
1. Busque mensajes de seguimiento y eventos personalizados que Profiler ha enviado a su recurso de
Application Insights. Puede usar esta cadena de búsqueda para encontrar los datos pertinentes:
stopprofiler OR startprofiler OR upload OR ServiceProfilerSample
La siguiente imagen muestra dos ejemplos de búsquedas de dos recursos de inteligencia artificial:
A la izquierda, la aplicación no recibe solicitudes mientras se ejecuta Profiler. El mensaje explica
que la carga se ha cancelado debido a la falta de actividad.
A la derecha, Profiler se ha iniciado y ha enviado eventos personalizados cuando ha detectado las
solicitudes que se han producido mientras se estaba ejecutando Profiler. Si se muestra el evento
personalizado ServiceProfilerSample, significa que Profiler ha adjuntado un seguimiento a una
solicitud y que el seguimiento se puede ver en el panel Rendimiento de Application Insights .
Si no se muestran datos de telemetría, Profiler no está en ejecución. Para solucionar problemas,
consulte las secciones de solución de problemas del tipo de aplicación concreto más adelante en
este artículo.
2. Si hubiera solicitudes durante la ejecución de Profiler, asegúrese de que la parte de la aplicación que
tiene habilitado Profiler es la que controla las solicitudes. Aunque las aplicaciones a veces constan de
varios componentes, Profiler está habilitado solo para algunos de los componentes. El panel
Configurar Application Insights Profiler muestra los componentes que han cargado seguimientos.
Otros aspectos que hay que comprobar
Asegúrese de que la aplicación se ejecuta en .NET Framework 4.6.
Si la aplicación web es una aplicación de ASP.NET Core, debe ejecutar al menos ASP.NET Core 2.0.
Si la antigüedad de los datos que intenta ver supera el par de semanas, pruebe a limitar el filtro de tiempo y
inténtelo de nuevo. Los seguimientos se eliminan pasados siete días.
Asegúrese de que no haya servidores proxy ni un firewall que bloqueen el acceso a
https://gateway.azureserviceprofiler.net.
No se admite Profiler en planes de App Service gratuitos o compartidos. Si usa uno de estos planes, intente
escalar verticalmente a uno de los planes básicos y Profiler debería empezar a funcionar.
Doble recuento de subprocesos paralelos
En algunos casos, la métrica de tiempo total del visor de la pila es mayor que la duración de la solicitud.
Esta situación puede darse cuando hay dos o más subprocesos asociados a una solicitud y funcionan en
paralelo. En ese caso, el tiempo de subproceso total es superior al tiempo transcurrido. Es posible que uno de
los subprocesos esté a la espera de que el otro finalice. El visor intenta detectar esta situación y omite la espera
sin interés. Al hacerlo, prefiere mostrar demasiada información antes que omitir lo que podría ser información
crítica.
Cuando vea subprocesos en paralelo en sus seguimientos, determine cuáles de ellos están en espera, con el fin
de que pueda determinar cuál es la ruta crítica de la solicitud. Normalmente, el subproceso que pasa
rápidamente a un estado de espera tan solo espera a los restantes subprocesos. Concéntrese en los demás
subprocesos e ignore el tiempo de los subprocesos en espera.
Informe de errores del visor de generación de perfiles
Envíe una incidencia de soporte técnico desde el portal. Asegúrese de incluir el identificador de correlación del
mensaje de error.
Solución de los problemas de Profiler en Azure App Service

Para que Profiler funcione correctamente:
El plan de servicio de aplicación web tiene que ser de nivel Básico o superior.
La aplicación web debe tener Application Insights habilitado.
La aplicación web debe tener las siguientes opciones:
El WebJob ApplicationInsightsProfiler3 debe estar en ejecución. Para comprobarlo:

1. Vaya a Kudu.
2. En el menú Tools (Herramientas), seleccione WebJobs Dashboard (Panel de WebJobs).
Se abre el panel WebJobs .
3. Para ver los detalles del webjob, incluido el registro, seleccione el vínculo
ApplicationInsightsProfiler3 .
Se abre el panel Continuous WebJob Details (Detalles de WebJobs continuos).
Si no puede averiguar el motivo por el que Profiler no funciona, puede descargar el registro y enviarlo a
nuestro equipo para que este pueda ayudarle, serviceprofilerhelp@microsoft.com.
Instalación manual
Cuando se configura Profiler, se realizan las siguientes actualizaciones en la configuración de la aplicación web.
Si su entorno lo requiere, las actualizaciones se pueden aplicar manualmente. Un ejemplo podría ser la
ejecución de su aplicación en un entorno de Web Apps para PowerApps. Para aplicar las actualizaciones
manualmente:
1. En el panel de control de la aplicación web , abra Configuración .
2. Establezca la versión de .NET Framework en v4.6 .
3. Establezca Siempre activado en Activado .
4. Cree esta configuración de aplicación:
Hay demasiadas sesiones de generación de perfiles activas

Actualmente, puede habilitar Profiler en hasta cuatro aplicaciones web de Azure y ranuras de implementación
que se ejecuten en el mismo plan de servicio. Si tiene más aplicaciones en ejecución en un plan de servicio de
una aplicación, Profiler podría iniciar la excepción
Microsoft.ServiceProfiler.Exceptions.TooManyETWSessionException. Profiler se ejecuta por separado en cada
aplicación web e intenta iniciar una sesión de ETW (Seguimiento de eventos para Windows ) en cada una de
ellas. Sin embargo, hay un número máximo de sesiones de ETW que pueden estar activas al mismo tiempo. Si
el WebJob de Profiler notifica que hay demasiadas sesiones de generación de perfiles activas, mueva algunas
aplicaciones web a otro plan de servicio.
Error de implementación: El directorio no está vacío "D:\home\site\wwwroot\App_Data\jobs"
Si va a volver a implementar la aplicación web en un recurso de Web Apps con Profiler habilitado, puede que
aparezca un mensaje similar al siguiente:
El directorio no está vacío "D:\home\site\wwwroot\App_Data\jobs"
Este error se produce si Web Deploy se ejecuta desde scripts o desde la canalización de implementación de
Azure DevOps. La solución consiste en agregar los siguientes parámetros de implementación adicionales a la
tarea de Web Deploy:
-skip:Directory='.*\\App_Data\\jobs\\continuous\\ApplicationInsightsProfiler.*' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data\\jobs\\continuous$' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data\\jobs$' -
skip:skipAction=Delete,objectname='dirPath',absolutepath='.*\\App_Data$'
Estos parámetros eliminan la carpeta que usa Application Insights Profiler y desbloquea el proceso de
reeimplementación. No afectan a la instancia de Profiler actualmente en ejecución.
¿Cómo se puede determinar si Application Insights Profiler se está ejecutando?
Profiler se ejecuta como un WebJob continuo en la aplicación web. Puede abrir el recurso de aplicación web en
Azure Portal. En el panel WebJobs , compruebe el estado de ApplicationInsightsProfiler . Si no se está
ejecutando, abra Registros para obtener más información.
Solución de problemas de servicios en la nube y máquinas virtuales

Se ha corregido el error en el generador de perfiles que se incluye con WAD para
Cloud Ser vices. La versión más reciente de WAD (1.12.2.0) para Cloud Services funciona con todas las
versiones recientes del SDK de App Insights. Los hosts de Cloud Services actualizarán WAD
automáticamente, pero no es algo inmediato. Para forzar una actualización, puede volver a implementar su
servicio o reiniciar el nodo.
Para ver si Azure Diagnostics ha configurado Profiler correctamente, realice las tres acciones siguientes:
1. En primer lugar, tiene que comprobar si el contenido de la configuración de Azure Diagnostics que se ha
implementado es el que esperaba.
2. En segundo lugar, asegúrese de que Azure Diagnostics pasa el valor de iKey adecuado en la línea de
comandos de Profiler.
3. En tercer lugar, puede compruebe en el archivo de registro de Profiler si este se ha ejecutado, pero ha
devuelto error.
Para comprobar la configuración que se usó para configurar Azure Diagnostics:
1. Inicie sesión en la máquina virtual (VM) y abra el archivo de registro que se encuentra en esta ubicación.
La versión del complemento puede ser más reciente en la máquina.
Para máquinas virtuales:
c:\WindowsAzure\logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.11.3.12\DiagnosticsPlugin
.log
Para Cloud Services:
c:\logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.11.3.12\DiagnosticsPlugin.log
2. En dicho archivo puede buscar la cadena WadCfg para saber qué valores se han pasado a la máquina
virtual para configurar Azure Diagnostics. Puede comprobar si el valor de iKey que ha usado el receptor
de Profiler es correcto.
3. Compruebe la línea de comandos que se usa para iniciar Profiler. Los argumentos que se utilizan para
iniciar Profiler están en el siguiente archivo. (La unidad podría ser la c: o la d: y el directorio puede estar
oculto).
Para máquinas virtuales:
C:\ProgramData\ApplicationInsightsProfiler\config.json
D:\ProgramData\ApplicationInsightsProfiler\config.json
4. Asegúrese de que el valor de iKey en la línea de comandos de Profiler es correcto.

5. Use la ruta de acceso que se encuentra en el archivo config.json anterior para consultar el archivo de
registro de Profiler, denominado BootstrapN.log . Muestra la información de depuración que indica la
configuración que usa Profiler. También muestra el estado y los mensajes de error de Profiler.
Para máquinas virtuales, el archivo suele estar aquí:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics\1.17.0.6\ApplicationInsight
sProfiler
C:\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics\1.17.0.6\ApplicationInsightsProfiler
Si Profiler se está ejecutando mientras la aplicación recibe solicitudes, se mostrará el siguiente mensaje:
Activity detected from iKey (Se ha detectado actividad en la clave de instrumentación).
Cuando se cargue el seguimiento, se muestra el mensaje siguiente: Start to upload trace (Inicio de carga
del seguimiento).
Edición de reglas de firewall o proxy de red

Si la aplicación se conecta a Internet a través de un proxy o un firewall, es posible que tenga que editar las
reglas para permitir que la aplicación se comunique con el servicio Application Insights Profiler. Las direcciones
IP que se usan en Application Insights Profiler se incluyen en la etiqueta de servicio de Azure Monitor.
Depurar instantáneas cuando se producen
excepciones en aplicaciones de .NET
Cuando se produce una excepción, puede recopilar automáticamente una instantánea de depuración desde
la aplicación web activa. La instantánea muestra el estado del código fuente y las variables en el momento
en que se produjo la excepción. En Application Insights, Snapshot Debugger supervisa los datos de
telemetría de las excepciones de su aplicación web. Recopila instantáneas de las excepciones más
importantes con el fin de que tenga la información necesaria para diagnosticar problemas en producción.
Incluya el paquete NuGet del recopilador de instantáneas en la aplicación y, opcionalmente, configure los
parámetros de recopilación en ApplicationInsights.config. Las instantáneas aparecen en excepciones en el
portal de Application Insights.
Puede ver las instantáneas de depuración en el portal para examinar la pila de llamadas e inspeccionar las
variables en cada marco de pila de llamadas. Para obtener una experiencia de depuración más eficaz con el
código fuente, abra las instantáneas con Visual Studio 2019 Enterprise. En Visual Studio también puede
establecer puntos de acoplamiento para tomar instantáneas de forma interactiva sin tener que esperar una
excepción.
Las instantáneas de depuración se guardan durante 15 días. Esta directiva de retención se establece para
cada aplicación. Si necesita aumentar este valor, puede solicitar un aumento abriendo una incidencia de
soporte técnico en Azure Portal.
Habilitación de Snapshot Debugger de Application Insights para la

aplicación
La recopilación de instantáneas está disponible para:
Aplicaciones de .NET Framework y ASP.NET que ejecuten .NET Framework 4.5 o posterior.
Aplicaciones de .NET Core 2.0 y ASP.NET Core 2.0 que se ejecuten en Windows.
Se admiten los siguientes entornos:
Azure App Service
Azure Cloud Services con la familia del SO 4 o posterior
Servicios de Azure Service Fabric con Windows Server 2012 R2 o posterior
Azure Virtual Machines y conjuntos de escalado de máquinas virtuales con Windows Server 2012 R2 o
posterior
Máquinas virtuales o físicas locales que ejecutan Windows Server 2012 R2 o posterior, o Windows 8.1 o
posterior.
NOTE
No se admiten las aplicaciones cliente (por ejemplo, WPF, Windows Forms o UWP).
Si ha habilitado Snapshot Debugger, pero no ve las instantáneas, consulte nuestra Guía de solución de
problemas.
Concesión de permisos
El acceso a las instantáneas está protegido por el control de acceso basado en rol (RBAC). Para poder
inspeccionar una instantánea, el propietario de la suscripción debe agregarle primero al rol necesario.
NOTE
Los propietarios y los colaboradores no tienen automáticamente este rol. Si desean ver las instantáneas, se deben
agregar a sí mismos al rol.
Los propietarios de la suscripción deben asignar el rol Application Insights Snapshot Debugger a los
usuarios que van a inspeccionar las instantáneas. Los propietarios de suscripción pueden asignar este rol a
usuarios individuales o grupos en el recurso de Application Insights de destino o en su grupo de recursos o
suscripción.
1. Vaya al recurso de Application Insights en Azure Portal.
2. Haga clic en Control de acceso (IAM).
3. Haga clic en el botón +Add role assignment (+ Agregar asignación de roles) botón.
4. Seleccione Application Insights Snapshot Debugger en la lista desplegable Roles .
5. Busque el usuario que quiere agregar y escriba un nombre.
6. Haga clic en el botón Guardar para agregar el usuario al rol.
IMPORTANT
Las instantáneas pueden contener información personal y otra información confidencial en valores de variables y
parámetros.
Visualización de instantáneas en el portal

Una vez que se haya producido una excepción en la aplicación y se haya creado una instantánea, debería
tener instantáneas para visualizar. Pueden transcurrir entre cinco y diez minutos desde que se produce una
excepción hasta que una instantánea está lista y puede visualizarse desde el portal. Para visualizar las
instantáneas, en el panel Error , seleccione el botón Operaciones al ver la pestaña Operaciones , o bien
seleccione el botón Excepciones al ver la pestaña Excepciones :
Seleccione una operación o una excepción en el panel derecho para abrir el panel Detalles de la
transacción completa y, luego, seleccione el evento de excepción. Si una instantánea está disponible para
una excepción determinada, se mostrará el botón Abrir instantánea de depuración en el panel derecho
con detalles de la excepción.
En la vista de depuración instantánea, verá una pila de llamadas y un panel de variables. Al seleccionar
marcos de la pila de llamadas en el panel de la pila de llamadas, podrá ver las variables locales y los
parámetros para esa llamada de función en el panel de variables.
Las instantáneas pueden incluir información confidencial y, de manera predeterminada, no están visibles.
Para ver las instantáneas, debe tener asignado el rol Application Insights Snapshot Debugger .
Visualización de instantáneas en Visual Studio 2017 Enterprise o

versiones posteriores
1. Haga clic en el botón Descargar la instantánea para descargar un archivo .diagsession , que
puede abrirse en Visual Studio Enterprise.
2. Para abrir el archivo .diagsession , debe tener instalado el componente Snapshot Debugger de
Visual Studio. El componente Snapshot Debugger es un componente obligatorio de la carga de
trabajo de ASP.NET en Visual Studio y se puede seleccionar de la lista de componentes individuales en
el instalador de Visual Studio. Si usa una versión de Visual Studio anterior a Visual Studio 2017,
versión 15.5, deberá instalar la extensión desde Visual Studio Marketplace.
3. Después de abrir el archivo de instantánea, aparece la página de depuración de minivolcado de Visual
Studio. Haga clic en Depurar código administrado para empezar a depurar la instantánea. La
instantánea se abre en la línea de código donde se produjo la excepción para que pueda depurar el
estado actual del proceso.
La instantánea descargada incluye los archivos de símbolos que se encontraron en el servidor de
aplicaciones web. Estos archivos de símbolos son necesarios para asociar los datos de instantáneas con el
código fuente. Para las aplicaciones de App Service, asegúrese de habilitar la implementación de símbolos
cuando publique las aplicaciones web.
Funcionamiento de las instantáneas

Snapshot Collector se implementa como un procesador de telemetría de Application Insights. Al ejecutar la
aplicación, el procesador de telemetría de Snapshot Collector se agrega a la canalización de telemetría de la
aplicación. Cada vez que la aplicación llama a TrackException, Snapshot Collector calcula un identificador del
problema del tipo de excepción producida y el método de lanzamiento. Cada vez que la aplicación llama a
TrackException, se incrementa un contador para el identificador del problema adecuado. Cuando el contador
alcanza el valor ThresholdForSnapshotting , el identificador del problema se agrega a un plan de recolección.
Snapshot Collector también supervisa las excepciones a medida que se producen si se suscribe al evento
AppDomain.CurrentDomain.FirstChanceException. Cuando ese evento se desencadena, el identificador del
problema de la excepción se calcula y se compara con los identificadores del problema del plan de
recolección. Si se encuentra una coincidencia, se crea una instantánea del proceso en ejecución. Se asigna un
identificador único a la instantánea y la excepción se marca con ese identificador. Tras la devolución del
controlador de FirstChanceException, la excepción producida se procesa con normalidad. Finalmente, la
excepción alcanza el método TrackException de nuevo que, junto con el identificador de instantáneas, se
notifica a Application Insights.
El proceso principal sigue ejecutándose y ofrece tráfico a los usuarios con poca interrupción. Mientras tanto,
la instantánea se entrega al proceso del cargador de instantáneas. El cargador de instantáneas crea un
minivolcado y lo carga en Application Insights junto con los archivos de símbolos (.pdb) pertinentes.
TIP
Una instantánea de proceso es un clon suspendido del proceso en ejecución.
La creación de la instantánea tarda aproximadamente de 10 a 20 milisegundos.
El valor predeterminado de ThresholdForSnapshotting es 1. También es el valor mínimo. Por lo tanto, la
aplicación debe desencadenar la misma excepción dos veces antes de crear una instantánea.
Establezca IsEnabledInDeveloperMode en true si quiere generar instantáneas durante la depuración en Visual
Studio.
La velocidad de creación de instantáneas está limitada por la configuración de SnapshotsPerTenMinutesLimit .
De manera predeterminada, el límite es una instantánea cada diez minutos.
No se pueden cargar más de 50 instantáneas al día.
Limitaciones
El período de retención de datos predeterminado es de 15 días. Para cada instancia de Application Insights,
se permite un número máximo de 50 instantáneas por día.
Publicación de símbolos
El Depurador de instantáneas requiere que los archivos de símbolos estén presentes en el servidor de
producción para descodificar variables y proporcionar una experiencia de depuración en Visual Studio. La
versión 15.2 (o superior) de Visual Studio 2017 publica símbolos de compilaciones de versión de forma
predeterminada al publicar en App Service. En las versiones anteriores, tiene que agregar la siguiente línea
al archivo .pubxml de su perfil de publicación para que los símbolos se publiquen en modo de versión:
<ExcludeGeneratedDebugSymbol>False</ExcludeGeneratedDebugSymbol>
Para Azure Compute y otros tipos, asegúrese de que los archivos de símbolos están en la misma carpeta del
archivo .dll principal de la aplicación (normalmente, wwwroot/bin ), o que están disponibles en la ruta de
acceso actual.
NOTE
Para más información acerca de las diferentes opciones de símbolos disponibles, consulte la , documentación de
Visual Studio. Para obtener los mejores resultados posible, se recomienda usar "Full", "Portable" o "Embedded".
Compilaciones optimizadas
En algunos casos, las variables locales no se pueden ver en las compilaciones de versión debido a las
optimizaciones que aplica el compilador JIT. Sin embargo, en Azure App Services, Snapshot Collector puede
invalidar la optimización de los métodos de lanzamiento que forman parte del plan de recolección.
TIP
Instale la extensión de sitio de Application Insights en su App Service para obtener soporte técnico para la
invalidación de optimizaciones.
Pasos siguientes
Habilitación de Snapshot Debugger de Application Insights para la aplicación:
Azure App Service
Servicios de Azure Service Fabric
Máquinas virtuales o físicas locales
Más allá de Snapshot Debugger de Application Insights:
Establezca puntos de ajuste en el código para obtener instantáneas sin tener que esperar una excepción.
En el artículo sobre cómo diagnosticar excepciones en aplicaciones web se explica cómo hacer más
visibles las excepciones en Application Insights.
Detección inteligente detecta automáticamente las anomalías de rendimiento.
Habilitación de Snapshot Debugger para
aplicaciones de .NET en Azure App Service
Actualmente, Snapshot Debugger puede usarse con aplicaciones ASP.NET y ASP.NET Core que se ejecutan en
Azure App Service en planes de servicio de Windows.
Habilitación de Snapshot Debugger

Para habilitar Snapshot Debugger en una aplicación, siga las instrucciones que se indican a continuación. Si está
ejecutando otro tipo de servicio de Azure, aquí encontrará instrucciones para habilitar Snapshot Debugger en
otras plataformas compatibles:
Servicios de Azure Service Fabric
Máquinas virtuales o físicas locales
Si usa una versión preliminar de .NET Core, siga las instrucciones para Habilite Snapshot Debugger para
aplicaciones .NET en Azure Service Fabric, servicio en la nube y máquinas virtuales en primer lugar para incluir el
paquete NuGet Microsoft.ApplicationInsights.SnapshotCollector con la aplicación y, luego, complete el resto de
las instrucciones siguientes.
Snapshot Debugger de Application Insights se preinstaló con el entorno de ejecución de App Services, pero es
necesario activarlo si quiere obtener instantáneas para la aplicación de App Service. Después de implementar
una aplicación web, aunque haya incluido el SDK de Application Insights en el código fuente, siga los pasos que
se indican a continuación para habilitar el depurador de instantáneas.
1. Vaya al panel de control de Azure y busque la instancia de App Service.
2. Vaya a la página Configuración > Application Insights .
3. Siga las instrucciones que aparecen en la página para crear un nuevo recurso o seleccione un recurso de
App Insights existente para supervisar la aplicación. También asegúrese de que los dos modificadores de
Snapshot Debugger están activados .
4. Snapshot Debugger está habilitado con una configuración de aplicación de App Services.
Deshabilitación de Snapshot Debugger
Siga los mismos pasos que para Habilitación de Snapshot Debugger , pero cambie los dos modificadores de
Snapshot Debugger al modo desactivado . Recomendamos que tenga habilitado Snapshot Debugger en todas
las aplicaciones para facilitar el diagnóstico de las excepciones de la aplicación.

En el caso de una instancia de Azure App Service, puede establecer la configuración de la aplicación en una
plantilla de Azure Resource Manager para habilitar Snapshot Debugger y Profiler. Se agrega un recurso de
configuración que contiene la configuración de la aplicación como un recurso secundario del sitio web:
{
"apiVersion": "2015-08-01",
"name": "[parameters('webSiteName')]",
"dependsOn": [
"[variables('hostingPlanName')]"
],
"tags": {
"[concat('hidden-related:', resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName')))]":
"empty",
"displayName": "Website"
},
"properties": {
"name": "[parameters('webSiteName')]",
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
},
"resources": [
{
"apiVersion": "2015-08-01",
"name": "appsettings",
"type": "config",
"dependsOn": [
"[parameters('webSiteName')]",
"[concat('AppInsights', parameters('webSiteName'))]"
],
"properties": {
"APPINSIGHTS_INSTRUMENTATIONKEY": "[reference(resourceId('Microsoft.Insights/components',
concat('AppInsights', parameters('webSiteName'))), '2014-04-01').InstrumentationKey]",
"APPINSIGHTS_PROFILERFEATURE_VERSION": "1.0.0",
"APPINSIGHTS_SNAPSHOTFEATURE_VERSION": "1.0.0",
"DiagnosticServices_EXTENSION_VERSION": "~3",
"ApplicationInsightsAgent_EXTENSION_VERSION": "~2"
}
}
]
},
Pasos siguientes
Genere tráfico para la aplicación que pueda desencadenar una excepción. A continuación, espere de 10 a
15 minutos para que se empiecen a enviar instantáneas a la instancia de Application Insights.
Vea las instantáneas en Azure Portal.
Por ayuda para solucionar problemas de Snapshot Debugger, consulte la sección Solución de problemas de
Snapshot Debugger.
Habilite Snapshot Debugger para aplicaciones
.NET en Azure Service Fabric, servicio en la nube y
máquinas virtuales
Si la aplicación ASP.NET o ASP.NET Core se ejecuta en Azure App Service, se recomienda encarecidamente
habilitar Snapshot Debugger en la página del portal de Application Insights. Sin embargo, si la aplicación
requiere una configuración personalizada de Snapshot Debugger o una versión preliminar de .NET Core, debe
seguir esta instrucción además de las instrucciones de habilitación mediante la página del portal de
Si la aplicación se ejecuta en Azure Service Fabric, el servicio en la nube, máquinas virtuales o máquinas
locales, se deben aplicar las instrucciones siguientes.
Configurar la recopilación de instantáneas para aplicaciones ASP.NET

1. Habilite Application Insights en su aplicación web, si aún no lo ha hecho.
2. Incluya el paquete NuGet Microsoft.ApplicationInsights.SnapshotCollector en la aplicación.
3. Si es necesario, personalice la configuración de Snapshot Debugger agregada a
ApplicationInsights.config. La configuración predeterminada de Snapshot Debugger está
principalmente vacía y todas las configuraciones son opcionales. Este es un ejemplo que muestra una
configuración equivalente a la configuración predeterminada:
<Add Type="Microsoft.ApplicationInsights.SnapshotCollector.SnapshotCollectorTelemetryProcessor,
Microsoft.ApplicationInsights.SnapshotCollector">



<IsEnabledInDeveloperMode>false</IsEnabledInDeveloperMode>

<ThresholdForSnapshotting>1</ThresholdForSnapshotting>

<MaximumSnapshotsRequired>3</MaximumSnapshotsRequired>

<MaximumCollectionPlanSize>50</MaximumCollectionPlanSize>

<ReconnectInterval>00:15:00</ReconnectInterval>

<ProblemCounterResetInterval>1.00:00:00</ProblemCounterResetInterval>

<SnapshotsPerTenMinutesLimit>3</SnapshotsPerTenMinutesLimit>

<SnapshotsPerDayLimit>30</SnapshotsPerDayLimit>

<ProvideAnonymousTelemetry>true</ProvideAnonymousTelemetry>

<FailedRequestLimit>3</FailedRequestLimit>
</Add>
4. Las instantáneas solo se recopilan en las excepciones de las que se informa a Application Insights. En
algunos casos (por ejemplo, en versiones anteriores de la plataforma. NET), es posible que tenga que
configurar la recopilación de excepciones para ver las excepciones con las instantáneas en el portal.
Configuración de la recopilación de instantáneas para aplicaciones

que usen ASP.NET Core 2.0 y versiones posteriores
1. Habilite Application Insights en su aplicación web ASP.NET Core, si aún no lo ha hecho.
NOTE
Procure que la aplicación haga referencia a la versión 2.1.1 (o una más reciente) del paquete
Microsoft.ApplicationInsights.AspNetCore.
2. Incluya el paquete NuGet Microsoft.ApplicationInsights.SnapshotCollector en la aplicación.

3. Modifique la clase Startup de la aplicación para agregar y configurar el procesador de telemetría del
recopilador de instantáneas.
a. Si usa la versión 1.3.5 o posterior del paquete NuGet
Microsoft.ApplicationInsights.SnapshotCollector, agregue las siguientes instrucciones mediante
declaraciones en Startup.cs .
using Microsoft.ApplicationInsights.SnapshotCollector;
Agregue lo siguiente al final del método ConfigureServices en la clase Startup de Startup.cs .
services.AddSnapshotCollector((configuration) =>
Configuration.Bind(nameof(SnapshotCollectorConfiguration), configuration));
b. Si usa la versión 1.3.4 o anterior del paquete Nuget

Microsoft.ApplicationInsights.SnapshotCollector, agregue lo siguiente mediante declaraciones en
Startup.cs .
using Microsoft.ApplicationInsights.SnapshotCollector;
using Microsoft.Extensions.Options;
using Microsoft.ApplicationInsights.AspNetCore;
Agregue la siguiente clase SnapshotCollectorTelemetryProcessorFactory a la clase Startup .
class Startup
{
private class SnapshotCollectorTelemetryProcessorFactory : ITelemetryProcessorFactory
{
private readonly IServiceProvider _serviceProvider;
public SnapshotCollectorTelemetryProcessorFactory(IServiceProvider serviceProvider)

=>
_serviceProvider = serviceProvider;
public ITelemetryProcessor Create(ITelemetryProcessor next)

{
var snapshotConfigurationOptions =
_serviceProvider.GetService<IOptions<SnapshotCollectorConfiguration>>();
return new SnapshotCollectorTelemetryProcessor(next, configuration:
snapshotConfigurationOptions.Value);
}
}
...
Agregue los servicios SnapshotCollectorConfiguration y

SnapshotCollectorTelemetryProcessorFactory a la canalización de inicio:
// This method gets called by the runtime. Use this method to add services to the
container.
{
// Configure SnapshotCollector from application settings
services.Configure<SnapshotCollectorConfiguration>
(Configuration.GetSection(nameof(SnapshotCollectorConfiguration)));
// Add SnapshotCollector telemetry processor.

services.AddSingleton<ITelemetryProcessorFactory>(sp => new
SnapshotCollectorTelemetryProcessorFactory(sp));
// TODO: Add other services your application needs here.

}
}
4. Si es necesario, personalice la configuración de Snapshot Debugger; para ello, agregue una sección
SnapshotCollectorConfiguration a appsettings.json. Todos los ajustes de la configuración de Snapshot
Debugger son opcionales. Este es un ejemplo que muestra una configuración equivalente a la
configuración predeterminada:
{
"SnapshotCollectorConfiguration": {
"IsEnabledInDeveloperMode": false,
"ThresholdForSnapshotting": 1,
"MaximumSnapshotsRequired": 3,
"MaximumCollectionPlanSize": 50,
"ReconnectInterval": "00:15:00",
"ProblemCounterResetInterval":"1.00:00:00",
"SnapshotsPerTenMinutesLimit": 1,
"SnapshotsPerDayLimit": 30,
"SnapshotInLowPriorityThread": true,
"ProvideAnonymousTelemetry": true,
"FailedRequestLimit": 3
}
}
Configurar la recopilación de instantáneas para otras aplicaciones

.NET
1. Si la aplicación aún no tiene Application Insights, debe empezar por habilitar Application Insights y
establecer la clave de instrumentación.
2. Agregue el paquete NuGet Microsoft.ApplicationInsights.SnapshotCollector en la aplicación.
3. Las instantáneas solo se recopilan en las excepciones de las que se informa a Application Insights. Es
posible que tenga que modificar el código para informar de las excepciones. El código de control de
excepciones depende de la estructura de la aplicación, pero a continuación se muestra un ejemplo:
TelemetryClient _telemetryClient = new TelemetryClient();
void ExampleRequest()
{
try
{
// TODO: Handle the request.
}
{
// Report the exception to Application Insights.
_telemetryClient.TrackException(ex);
// TODO: Rethrow the exception if desired.

}
}
Pasos siguientes
Genere tráfico para la aplicación que pueda desencadenar una excepción. A continuación, espere de 10 a
15 minutos para que se empiecen a enviar instantáneas a la instancia de Application Insights.
Vea las instantáneas en Azure Portal.
Por ayuda para solucionar problemas de Snapshot Debugger, consulte la sección Solución de problemas de
Snapshot Debugger.
Actualización de Snapshot Debugger
Para proporcionar la máxima seguridad posible para los datos, Microsoft está dejando de utilizar TLS 1.0 y TLS 1.1,
que han demostrado ser vulnerables ante determinados atacantes. Si utiliza una versión anterior de la extensión de
sitio, deberá actualizarla para que siga funcionando. En este documento se describen los pasos necesarios para
actualizar Snapshot Debugger a la versión más reciente. Hay dos rutas de actualización principales en función de si
ha habilitado Snapshot Debugger con una extensión de sitio o si usa un SDK/Nuget que se ha agregado a la
aplicación. Ambas rutas de actualización se describen a continuación.
Actualización de la extensión de sitio

IMPORTANT
Las versiones anteriores de Application Insights usaban una extensión de sitio privada, la extensión de Application Insights
para Azure App Service. La experiencia actual de Application Insights se habilita estableciendo la configuración de la aplicación
para que ponga en marcha una extensión de sitio preinstalada. Para evitar conflictos que podrían provocar que el sitio dejase
de funcionar, es importante eliminar primero la extensión de sitio privada. Consulte el paso 4 a continuación.
Si ha habilitado Snapshot Debugger mediante la extensión de sitio, puede realizar fácilmente la actualización
mediante el siguiente procedimiento:
2. Vaya al recurso que tiene habilitado Snapshot Debugger y Application Insights. Por ejemplo, para una
aplicación web, navegue hasta el recurso de App Service:
3. Una vez que haya navegado hasta el recurso, haga clic en la hoja Extensiones y espere a que se rellene la
lista de extensiones:
4. Si está instalada alguna versión de la extensión de Application Insights para Azure App Service, selecciónela
y haga clic en Eliminar. Confirme con Sí para eliminar la extensión y espere a que se complete la eliminación
antes de pasar al paso siguiente.
5. Vaya a la hoja Información general del recurso y haga clic en Application Insights:
6. Si esta es la primera vez que ve la hoja Application Insights de esta instancia de App Service, se le pedirá que
active Application Insights. Seleccione Activar Application Insights .
7. Se muestra la configuración de Application Insights actual. A menos que desee aprovechar la oportunidad
para cambiar la configuración, puede dejarla tal cual. El botón Aplicar de la parte inferior de la hoja no está
habilitado de forma predeterminada; tendrá activar o desactivar uno de los valores para habilitarlo. En
realidad no es necesario cambiar la configuración, basta con cambiar el parámetro y, a continuación, revertir
el cambio de inmediato. Recomendamos alternar el parámetro de Profiler y luego seleccionar Aplicar .
8. Al hacer clic en Aplicar , se le pedirá que confirme los cambios.
NOTE
El sitio se reiniciará como parte del proceso de actualización.
9. Haga clic en Sí para aplicar los cambios y espere a que se complete el proceso.
El sitio ya se ha actualizado y está listo para usarse.
Actualización de Snapshot Debugger mediante SDK/Nuget

Si la aplicación está usando una versión de Microsoft.ApplicationInsights.SnapshotCollector por debajo de la
versión 1.3.1, se deberá actualizar a una versión más reciente para seguir funcionando.
Configuración de Traiga su propio almacenamiento
(BYOS) para Application Insights Profiler y Snapshot
Debugger
¿Qué es Traiga su propio almacenamiento (BYOS) y por qué podría

resultarme últil?
Cuando se usa Application Insights Profiler o Snapshot Debugger, los artefactos generados por la aplicación se
cargan en cuentas de Azure Storage a través de la red pública de Internet. Microsoft paga y controla esas cuentas
para su procesamiento y análisis. Microsoft controla las directivas de administración de la vigencia y el cifrado en
reposo para esos artefactos.
Con Traiga su propio almacenamiento, estos artefactos se cargan en una cuenta de almacenamiento que usted
controla. Esto significa que controla la directiva de cifrado en reposo, la directiva de administración de la vigencia
y el acceso a la red. Sin embargo, será responsable de los costos asociados a esa cuenta de almacenamiento.
NOTE
Si está habilitando Private Link, Traiga su propio almacenamiento es obligatorio. Para obtener más información acerca de
Private Link para Application Insights, consulte la documentación.
Si está habilitando las claves administradas de cliente, Traiga su propio almacenamiento es obligatorio. Para obtener más
información acerca de las claves administradas de cliente, consulte la documentación.
¿Cómo se tiene acceso a la cuenta de almacenamiento?

1. Los agentes que se ejecutan en Virtual Machines o App Service cargarán artefactos (perfiles, instantáneas y
símbolos) en los contenedores de blobs de su cuenta. Este proceso implica ponerse en contacto con el servicio
Application Insights Profiler o Snapshot Debugger para obtener un token de SAS (firma de acceso
compartido) para un nuevo blob en la cuenta de almacenamiento.
2. El servicio Application Insights Profiler o Snapshot Debugger analizará el blob entrante y volverá a escribir los
resultados del análisis y los archivos de registro en el almacenamiento de blobs. Dependiendo de la capacidad
de proceso disponible, este proceso puede producirse en cualquier momento después de la carga.
3. Al ver los seguimientos de Profiler o el análisis de Snapshot Debugger, el servicio capturará los resultados del
análisis del almacenamiento de blobs.
Requisitos previos
Asegúrese de crear la cuenta de almacenamiento en la misma ubicación que el recurso de Application Insights.
Por ejemplo, Si el recurso de Application Insights está en Oeste de EE. UU. 2, la cuenta de almacenamiento
debe estar también en Oeste de EE. UU. 2.
Conceda el rol "Colaborador de datos de blobs de almacenamiento" al "Acceso a almacenamiento de
confianza de servicios de diagnóstico" de la aplicación de AAD en la cuenta de almacenamiento a través de la
interfaz de usuario de Access Control (IAM).
Si está habilitado Private Link, configure la opción adicional para permitir la conexión a nuestro servicio de
confianza de Microsoft desde Virtual Network.
Habilitación de BYOS
Crear cuenta de almacenamiento
Cree una nueva cuenta de almacenamiento (si no la tiene) en la misma ubicación que el recurso de Application
Insights. Si el recurso de Application Insights está en West US 2 , la cuenta de almacenamiento debe estar en
West US 2 .
Concesión de acceso a los servicios de diagnóstico a su cuenta de almacenamiento

Una cuenta de almacenamiento de BYOS se vinculará a un recurso de Application Insights. Puede haber solo una
cuenta de almacenamiento por recurso de Application Insights y ambos deben estar en la misma ubicación.
Puede usar la misma cuenta de almacenamiento con más de un recurso de Application Insights.
En primer lugar, se debe conceder acceso a la cuenta de almacenamiento al servicio Application Insights Profiler y
Snapshot Debugger. Para conceder acceso, agregue el rol Storage Blob Data Contributor a la aplicación de AAD
llamada Diagnostic Services Trusted Storage Access a través de la página de Access Control (IAM) de la cuenta
de almacenamiento, tal como se muestra en la figura 1.0.
Pasos:
1. Haga clic en el botón "Agregar" de la sección "Agregar una asignación de roles".
2. Seleccione rol "Colaborador de datos de blobs de almacenamiento"
3. En la opción "Asignar acceso a", seleccione "Usuario, grupo o entidad de servicio de Azure AD".
4. Búsqueda y selección de la aplicación "Acceso a almacenamiento de confianza de servicios de diagnóstico"
5. Guardar cambios
Figura 1.0
Después de agregar el rol, aparecerá en la sección "Asignaciones de roles", como la figura 1.1.
Figura 1.1
Si está usando también Private Link, se necesita una configuración adicional para permitir la conexión a nuestro
servicio de confianza de Microsoft desde Virtual Network. Consulte la documentación de Seguridad de red de
almacenamiento.
Vinculación de la cuenta de almacenamiento con el recurso de Application Insights
Para configurar BYOS para el diagnóstico en el nivel de código (Profiler/Debugger), hay tres opciones:
Uso de cmdlets de Azure PowerShell
Uso de la interfaz de la línea de comandos de Azure (CLI)
Uso de la plantilla de Azure Resource Manager
Configuración mediante cmdlets de Azure PowerShell
1. Asegúrese de que ha instalado Az PowerShell 4.2.0 o posterior.
Para instalar Azure PowerShell, consulte la documentación oficial de Azure PowerShell.
2. Instale la extensión de PowerShell para Application Insights.
Install-Module -Name Az.ApplicationInsights -Force
3. Inicie sesión con su cuenta de Azure.
Connect-AzAccount -Subscription "{subscription_id}"
Para obtener más información sobre cómo iniciar sesión, consulte la documentación de Connect-
AzAccount.
4. Quite la cuenta de almacenamiento anterior vinculada al recurso de Application Insights.
Patrón:
Ejemplo:


Patrón:
$storageAccount = Get-AzStorageAccount -ResourceGroupName "{resource_group_name}" -Name "

{application_insights_name}"
Ejemplo:
$storageAccount = Get-AzStorageAccount -ResourceGroupName "byos-test" -Name "byosteststoragewestus2"

Configuración mediante la CLI de Azure

1. Asegúrese de que ha instalado la CLI de Azure.
Para instalar la CLI de Azure, consulte la documentación oficial de la CLI de Azure.
2. Instale la extensión de la CLI de Application Insights.

Patrón:
az monitor app-insights component linked-storage link --resource-group "{resource_group_name}" --app "

{application_insights_name}" --storage-account "{storage_account_name}"
Ejemplo:
az monitor app-insights component linked-storage link --resource-group "byos-test" --app "byos-test-

westus2-ai" --storage-account "byosteststoragewestus2"
Resultado esperado:
{
"id": "/subscriptions/{subscription}/resourcegroups/byos-
test/providers/microsoft.insights/components/byos-test-westus2-
ai/linkedstorageaccounts/serviceprofiler",
"linkedStorageAccount": "/subscriptions/{subscription}/resourceGroups/byos-
test/providers/Microsoft.Storage/storageAccounts/byosteststoragewestus2",
"name": "serviceprofiler",
"resourceGroup": "byos-test",
"type": "microsoft.insights/components/linkedstorageaccounts"
}
NOTE
Para realizar actualizaciones en las cuentas de almacenamiento vinculadas al recurso de Application Insights,
consulte la documentación de la CLI de Application Insights.
Configuración de la plantilla de Azure Resource Manager

1. Cree un archivo de plantilla de Azure Resource Manager con el siguiente contenido (byos.template.json).
{
"parameters": {
"applicationinsights_name": {
"type": "String"
},
"storageaccount_name": {
"type": "String"
}
},
"variables": {},
"resources": [
{
"name": "[concat(parameters('applicationinsights_name'), '/serviceprofiler')]",
"type": "Microsoft.Insights/components/linkedStorageAccounts",
"properties": {
"linkedStorageAccount": "[resourceId('Microsoft.Storage/storageAccounts',
parameters('storageaccount_name'))]"
}
}
],
"outputs": {}
}
2. Ejecute el siguiente comando de PowerShell para implementar la plantilla anterior (cree una cuenta de
almacenamiento vinculada).
Patrón:
New-AzResourceGroupDeployment -ResourceGroupName "{your_resource_name}" -TemplateFile "

{local_path_to_arm_template}"
Ejemplo:
New-AzResourceGroupDeployment -ResourceGroupName "byos-test" -TemplateFile

"D:\Docs\byos.template.json"
3. Proporcione los siguientes parámetros cuando se le solicite en la consola de PowerShell:
application_insights_name Nombre del recurso de Application Insights para habilitar

BYOS.
storage_account_name Nombre del recurso de la cuenta de almacenamiento que

usará como BYOS.
Resultado esperado:
Supply values for the following parameters:

(Type !? for Help.)
application_insights_name: byos-test-westus2-ai
storage_account_name: byosteststoragewestus2
DeploymentName : byos.template
ResourceGroupName : byos-test
Timestamp : 4/16/2020 1:24:57 AM
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
============================== ========================= ==========
application_insights_name String byos-test-
westus2-ai
storage_account_name String
byosteststoragewestus2
Outputs :
DeploymentDebugLogLevel :
4. Habilite el diagnóstico en el nivel de código (Profiler/Debugger) en la carga de trabajo correspondiente a

través de Azure Portal. (App Service > Application Insights)
Figura 2.0
No se admite el esquema de plantilla "{schema_uri}".
Asegúrese de que la propiedad $schema de la plantilla es válida. Debe seguir el patrón siguiente:
https://schema.management.azure.com/schemas/{schema_version}/deploymentTemplate.json#
Asegúrese de que schema_version en la plantilla esté dentro de los valores válidos:
2014-04-01-preview, 2015-01-01, 2018-05-01, 2019-04-01, 2019-08-01 . Mensaje de error:
New-AzResourceGroupDeployment : 11:53:49 AM - Error: Code=InvalidTemplate; Message=Deployment template

validation failed: 'Template schema
'https://schema.management.azure.com/schemas/2020-01-01/deploymentTemplate.json#' is not supported.
Supported versions are
'2014-04-01-preview,2015-01-01,2018-05-01,2019-04-01,2019-08-01'. Please see https://aka.ms/arm-
template for usage details.'.
No se encontró ningún proveedor de recursos registrado para la ubicación "{location}".

Asegúrese de que apiVersion del recurso microsoft.insights/components es 2015-05-01 .
Asegúrese de que apiVersion del recurso linkedStorageAccount es 2020-03-01-preview . Mensaje de error:
New-AzResourceGroupDeployment : 6:18:03 PM - Resource microsoft.insights/components 'byos-test-

westus2-ai' failed with message '{
"error": {
"code": "NoRegisteredProviderFound",
"message": "No registered resource provider found for location 'westus2' and API version '2020-03-
01-preview' for type 'components'. The supported api-versions are '2014-04-01,
2014-08-01, 2014-12-01-preview, 2015-05-01, 2018-05-01-preview'. The supported locations are ',
eastus, southcentralus, northeurope, westeurope, southeastasia, westus2, uksouth,
canadacentral, centralindia, japaneast, australiaeast, koreacentral, francecentral, centralus,
eastus2, eastasia, westus, southafricanorth, northcentralus, brazilsouth, switzerlandnorth,
australiasoutheast'."
}
}'
La ubicación de la cuenta de almacenamiento debe coincidir con la ubicación del componente AI.
Asegúrese de que la ubicación del recurso de Application Insights sea la misma que la de la cuenta de
almacenamiento. Mensaje de error:
New-AzResourceGroupDeployment : 1:01:12 PM - Resource

microsoft.insights/components/linkedStorageAccounts 'byos-test-centralus-ai/serviceprofiler' failed
with message '{
"error": {
"code": "BadRequest",
"message": "Storage account location should match AI component location",
"innererror": {
"trace": [
"System.ArgumentException"
]
}
}
}'
Para solucionar problemas generales de Profiler, consulte la documentación de solución de problemas de Profiler.
Para la solución de problemas generales de Snapshot Debugger, consulte la documentación de solución de
problemas de Snapshot Debugger.

Si tengo habilitado Profiler o Snapshot y he habilitado BYOS, ¿se migrarán mis datos a mi cuenta de
almacenamiento? No, no lo harán.
¿Funcionará BYOS con el cifrado en reposo y la clave administrada de cliente? Sí, para ser precisos, BYOS
es un requisito para tener Profiler/Debugger habilitado con las claves administradas por el cliente.
¿Funcionará BYOS en un entorno aislado de Internet? Sí. De hecho, BYOS es un requisito para escenarios
de redes aisladas.
¿Funcionará BYOS cuando se hayan habilitado tanto las claves administradas de cliente como Private Link?
Sí, esa opción existe.
Si he habilitado BYOS, ¿puedo volver a usar las cuentas de almacenamiento de servicios de diagnóstico
para almacenar los datos recopilados? Sí, pero ya no se admite la migración de datos desde BYOS.
Después de habilitar BYOS, ¿me haré cargo de todos los costos relacionados, que son los derivados del
almacenamiento y las redes? Sí
Solucionar problemas de habilitación de Application
Insights Snapshot Debugger o ver instantáneas
Si habilitó Application Insights Snapshot Debugger para la aplicación, pero no puede ver las instantáneas para
las excepciones, puede usar estas instrucciones para solucionar problemas. Puede haber muchas razones
diferentes de por qué no se generan las instantáneas. Puede ejecutar la comprobación de estado de instantáneas
para identificar algunas de las posibles causas comunes.
Uso de la comprobación de estado de instantáneas

Algunos problemas comunes provocan que no se muestre la opción Abrir instantánea de depuración. Por
ejemplo, el uso de una instancia de Snapshot Collector no actualizada, el hecho de alcanzar el límite diario de
carga o, quizás, la tardanza de la instantánea en cargarse. Use la comprobación de estado de instantáneas para
solucionar problemas comunes.
Hay un vínculo en el panel de excepción de la vista de seguimiento de un extremo a otro que le lleva a la
comprobación de estado de instantáneas.
La interfaz interactiva, similar a un chat, busca problemas comunes y le guía para corregirlos.
Si no se soluciona el problema, consulte los siguientes pasos de solución de problemas de forma manual.
Comprobar la clave de instrumentación

Asegúrese de que está usando la clave de instrumentación correcta en la aplicación publicada. Por lo general, la
clave de instrumentación se lee desde el archivo ApplicationInsights.config. Compruebe que el valor es igual que
la clave de instrumentación para el recurso de Application Insights que ve en el portal.
Versiones preliminares de .NET Core

Si la aplicación usa una versión preliminar de .NET Core y Snapshot Debugger se ha habilitado mediante el panel
de Application Insights del portal, puede que Snapshot Debugger no se inicie. Siga primero las instrucciones del
artículo sobre la Habilitación de Snapshot Debugger para otros entornos para incluir el paquete NuGet
Microsoft.ApplicationInsights.SnapshotCollector con la aplicación además de habilitarlo mediante el panel de
Actualización a la versión más reciente del paquete NuGet

Si se habilitó Snapshot Debugger con el panel Application Insights en el portal, la aplicación ya debería estar
ejecutando el paquete NuGet más reciente. Si se habilitó Snapshot Debugger mediante la inclusión del paquete
NuGet Microsoft.ApplicationInsights.SnapshotCollector, use el administrador de paquetes NuGet de Visual
Studio para asegurarse de que usa la versión más reciente de Microsoft.ApplicationInsights.SnapshotCollector.
Puede encontrar notas de la versión en https://github.com/Microsoft/ApplicationInsights-Home/issues/167
Comprobar los registros de usuario de carga

Después de crear una instantánea, se crea un archivo de minivolcado (.dmp) en el disco. Un proceso de usuario
de carga independiente crea ese archivo de minivolcado y lo carga, junto con los archivos PDB asociados, en el
almacenamiento de Snapshot Debugger de Application Insights. Después de cargar correctamente el
minivolcado, se elimina del disco. Los archivos de registro del proceso de usuario de carga se conservan en el
disco. En un entorno de App Service, puede encontrar estos registros en D:\Home\LogFiles . Use el sitio de
administración de Kudu para App Service para buscar estos archivos de registro.
1. Abra la aplicación App Service en Azure Portal.
2. Haga clic en Herramientas avanzadas o busque Kudu .
3. Haga clic en Ir .
4. En el cuadro de lista desplegable Consola de depuración , seleccione CMD .
5. Haga clic en LogFiles .
Debería ver al menos un archivo con un nombre que comienza con Uploader_ o SnapshotUploader_ y una
extensión .log . Haga clic en el icono adecuado para descargar los archivos de registro o abrirlos en un
explorador. El nombre de archivo incluye un sufijo único que identifica la instancia de App Service. Si la instancia
de App Service se hospeda en más de un equipo, hay archivos de registro independientes para cada equipo.
Cuando el usuario de carga detecta un nuevo archivo de minivolcado, se registra en el archivo de registro. Este
es un ejemplo de una instantánea y una carga correctas:
SnapshotUploader.exe Information: 0 : Received Fork request ID 139e411a23934dc0b9ea08a626db16c5 from process
6368 (Low pri)
DateTime=2018-03-09T01:42:41.8571711Z
SnapshotUploader.exe Information: 0 : Creating minidump from Fork request ID
139e411a23934dc0b9ea08a626db16c5 from process 6368 (Low pri)
DateTime=2018-03-09T01:42:41.8571711Z
SnapshotUploader.exe Information: 0 : Dump placeholder file created: 139e411a23934dc0b9ea08a626db16c5.dm_
DateTime=2018-03-09T01:42:41.8728496Z
SnapshotUploader.exe Information: 0 : Dump available 139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:45.7525022Z
SnapshotUploader.exe Information: 0 : Successfully wrote minidump to
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:45.7681360Z
SnapshotUploader.exe Information: 0 : Uploading
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp, 214.42 MB
(uncompressed)
DateTime=2018-03-09T01:42:45.7681360Z
SnapshotUploader.exe Information: 0 : Upload successful. Compressed size 86.56 MB
DateTime=2018-03-09T01:42:59.6184651Z
SnapshotUploader.exe Information: 0 : Extracting PDB info from
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp.
DateTime=2018-03-09T01:42:59.6184651Z
SnapshotUploader.exe Information: 0 : Matched 2 PDB(s) with local files.
DateTime=2018-03-09T01:42:59.6809606Z
SnapshotUploader.exe Information: 0 : Stamp does not want any of our matched PDBs.
DateTime=2018-03-09T01:42:59.8059929Z
SnapshotUploader.exe Information: 0 : Deleted
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\139e411a23934dc0b9ea08a626db16c5.dmp
DateTime=2018-03-09T01:42:59.8530649Z
NOTE
El ejemplo anterior es de la versión 1.2.0 del paquete NuGet Microsoft.ApplicationInsights.SnapshotCollector. En versiones
anteriores, el proceso de usuario de carga se llama MinidumpUploader.exe y el registro está menos detallado.
En el ejemplo anterior, la clave de instrumentación es c12a605e73c44346a984e00000000000 . Este valor debe

coincidir con la clave de instrumentación de la aplicación. El minivolcado está asociado a una instantánea con el
identificador 139e411a23934dc0b9ea08a626db16c5 . Puede usar este identificador más adelante para buscar la
telemetría de excepciones asociada en Application Insights Analytics.
El usuario de carga busca nuevos archivos PDB una vez cada 15 minutos. Este es un ejemplo:
SnapshotUploader.exe Information: 0 : PDB rescan requested.

DateTime=2018-03-09T01:47:19.4457768Z
SnapshotUploader.exe Information: 0 : Scanning D:\home\site\wwwroot for local PDBs.
DateTime=2018-03-09T01:47:19.4457768Z
SnapshotUploader.exe Information: 0 : Local PDB scan complete. Found 2 PDB(s).
DateTime=2018-03-09T01:47:19.4614027Z
SnapshotUploader.exe Information: 0 : Deleted PDB scan marker :
D:\local\Temp\Dumps\c12a605e73c44346a984e00000000000\6368.pdbscan
DateTime=2018-03-09T01:47:19.4614027Z
Para las aplicaciones que no están hospedadas en App Service, los registros de usuario de carga están en la
misma carpeta que los minivolcados: %TEMP%\Dumps\<ikey> (donde <ikey> es la clave de instrumentación).
Solución de problemas de Cloud Services

Para los roles de Cloud Services, la carpeta temporal predeterminada puede ser demasiado pequeña para
contener los archivos de minivolcado, dando lugar a pérdida de instantáneas. El espacio necesario depende del
espacio de trabajo total de la aplicación y el número de instantáneas simultáneas. El espacio de trabajo de un rol
web ASP.NET de 32 bits está normalmente entre 200 y 500 MB. Debe disponer del espacio necesario para al
menos dos instantáneas simultáneas. Por ejemplo, si la aplicación usa 1 GB de espacio de trabajo total, debe
asegurarse de que hay al menos 2 GB de espacio en disco para almacenar las instantáneas. Siga estos pasos para
configurar el rol del servicio en la nube con un recurso local dedicado para las instantáneas.
1. Agregue un nuevo recurso local a su servicio en la nube editando el archivo de definición (.csdef) del
servicio en la nube. En el ejemplo siguiente se define un recurso llamado SnapshotStore con un tamaño
de 5 GB.
<LocalResources>
<LocalStorage name="SnapshotStore" cleanOnRoleRecycle="false" sizeInMB="5120" />
</LocalResources>
2. Modifique el código de inicio del rol para agregar una variable de entorno que apunte al recurso local
SnapshotStore . En roles de trabajo, el código se debe agregar al método OnStart del rol:
public override bool OnStart()

{
Environment.SetEnvironmentVariable("SNAPSHOTSTORE",
RoleEnvironment.GetLocalResource("SnapshotStore").RootPath);
return base.OnStart();
}
En roles web (ASP.NET), el código se debe agregar al método Application_Start de la aplicación web:
using Microsoft.WindowsAzure.ServiceRuntime;
using System;
namespace MyWebRoleApp
{
public class MyMvcApplication : System.Web.HttpApplication
{
{
Environment.SetEnvironmentVariable("SNAPSHOTSTORE",
RoleEnvironment.GetLocalResource("SnapshotStore").RootPath);
// TODO: The rest of your application startup code
}
}
}
3. Actualice el archivo ApplicationInsights.config del rol para reemplazar la ubicación de la carpeta temporal
utilizada por SnapshotCollector

<TempFolder>%SNAPSHOTSTORE%</TempFolder>

</Add>
Invalidación de la carpeta Instantáneas

Cuando se inicia Snapshot Collector, intenta encontrar una carpeta del disco que sea adecuada para ejecutar el
proceso del cargador de instantáneas. La carpeta elegida se conoce como carpeta de instantáneas.
Snapshot Collector comprueba unas cuantas ubicaciones conocidas, asegurándose de que tiene permisos para
copiar los archivos binarios del cargador de instantáneas. Se usaron las siguientes variables de entorno:
Fabric_Folder_App_Temp
LOCALAPPDATA
APPDATA
TEMP
Si no se puede encontrar una carpeta adecuada, Snapshot Collector envía un error que dice "Could not find a
suitable shadow copy folder." (No se pudo encontrar una carpeta de instantáneas adecuada).
Si se produce un error en la copia, Snapshot Collector envía un error ShadowCopyFailed .
Si no se puede iniciar el cargador, Snapshot Collector enviará un error UploaderCannotStartFromShadowCopy . El
cuerpo del mensaje normalmente incluye System.UnauthorizedAccessException . Este error se suele producir
porque la aplicación se ejecuta en una cuenta con permisos reducidos. La cuenta tiene permiso para escribir en
la carpeta de instantáneas, pero no tiene permiso para ejecutar código.
Puesto que estos errores suelen ocurrir durante el inicio, normalmente van seguidos de un error
ExceptionDuringConnect que dice "Uploader failed to start" ("Error al iniciar el cargador").
Para resolver estos errores, puede especificar la carpeta de copia de instantáneas manualmente a través de la
opción de configuración ShadowCopyFolder . Por ejemplo, use ApplicationInsights.config:

<ShadowCopyFolder>D:\SnapshotUploader</ShadowCopyFolder>

</Add>
O bien, si usa appsettings.json con una aplicación .NET Core:
{
"InstrumentationKey": "<your instrumentation key>"
},
"SnapshotCollectorConfiguration": {
"ShadowCopyFolder": "D:\\SnapshotUploader"
}
}
Usar la búsqueda de Application Insights para buscar excepciones con

instantáneas
Cuando se crea una instantánea, la excepción iniciada se etiqueta con un identificador de instantánea. Ese
identificador de instantánea se incluye como una propiedad personalizada cuando se notifica la telemetría de
excepciones a Application Insights. Mediante la búsqueda de Application Insights, puede buscar toda la
telemetría con la propiedad personalizada ai.snapshot.id .
1. Vaya al recurso de Application Insights en Azure Portal.
2. Haga clic en Buscar .
3. En el cuadro de texto Buscar, escriba ai.snapshot.id y presione Entrar.
Si esta búsqueda no devuelve ningún resultado, no se ha informado de ninguna instantánea a Application

Insights para la aplicación en el intervalo de tiempo seleccionado.
Para buscar un identificador de instantánea específico en los registros de usuario de carga, escriba ese
identificador en el cuadro Buscar. Si no se encuentra la telemetría para una instantánea que sabe que se cargó,
siga estos pasos:
1. Compruebe que está viendo el recurso de Application Insights correcto comprobando la clave de
instrumentación.
2. Mediante la marca de tiempo del registro del usuario de carga, ajuste el filtro de intervalo de tiempo de la
búsqueda para cubrir ese intervalo de tiempo.
Si sigue sin ver una excepción con ese identificador de instantánea, significa que la excepción de telemetría no se
ha notificado a Application Insights. Esta situación puede ocurrir si se bloqueó la aplicación después de que tomó
la instantánea, pero antes de notificar la telemetría de excepción. En este caso, compruebe los registros de App
Service en Diagnose and solve problems para ver si hay reinicios inesperados o excepciones no controladas.
Edición de reglas de firewall o proxy de red

Si la aplicación se conecta a Internet a través de un proxy o un firewall, es posible que tenga que editar las reglas
para permitir que la aplicación se comunique con el servicio de Snapshot Debugger. Las direcciones IP que se
usan en Snapshot Debugger se incluyen en la etiqueta de servicio de Azure Monitor.
Detección inteligente en Application Insights
La detección inteligente avisa automáticamente de posibles problemas de rendimiento y anomalías en los

errores en su aplicación web. Realiza un análisis proactivo de la telemetría que su aplicación envía a Application
Insights. Si hay un aumento repentino de las tasas de error o patrones de rendimiento anormales en el cliente o
el servidor, recibirá una alerta. Esta característica no necesita ninguna configuración. Funciona si la aplicación
envía suficiente telemetría.
Puede acceder a las detecciones emitidas por la detección inteligente tanto desde los correos electrónicos que
recibe, como desde la hoja de detección inteligente.
Revisión de las detecciones inteligentes

Puede detectar las detecciones de dos maneras:
Recibirá un correo electrónico de Application Insights. Este es un ejemplo típico:
Haga clic en el botón grande para abrir más detalles en el portal.

La hoja Detección inteligente en Application Insights. Seleccione Detección inteligente en el menú
Investigar para ver una lista de las detecciones recientes.
Seleccione una detección para ver sus detalles.
¿Qué problemas se detectan?

La Detección inteligente detecta y notifica una variedad de problemas, como:
Detección inteligente: anomalías de errores. Usamos el aprendizaje automático para establecer la tasa
esperada de solicitudes con error para su aplicación, correlacionando la carga y otros factores. Si la tasa de
error queda fuera del rango esperado, se enviará una alerta.
Detección inteligente: anomalías de rendimiento. Recibe notificaciones si la duración del tiempo de respuesta
de operación o dependencia se ralentiza en comparación con la línea de base histórica, o si se identifica un
patrón anómalo en el tiempo de respuesta o en el tiempo de carga de página.
Problemas y degradaciones generales, como Degradación de seguimiento, Fuga de memoria, Aumento
anómalo del volumen de excepciones y Antipatrones de seguridad.
(Los vínculos a la Ayuda de cada notificación llevan a los artículos pertinentes).
Notificaciones por correo electrónico de detección inteligente

Todas las reglas de detección inteligente, excepto las reglas marcadas como versión preliminar, se configuran de
forma predeterminada para enviar notificaciones por correo electrónico cuando se encuentran las detecciones.
La configuración de las notificaciones por correo electrónico para una regla de detección inteligente específica
puede hacerse abriendo hoja Configuración de detección inteligente y seleccionando la regla, lo que abrirá la
hoja Editar regla .
Como alternativa, puede cambiar la configuración mediante plantillas de Azure Resource Manager. Para más
información, consulte Administración de reglas de detección inteligente de Application Insights con plantillas de
Azure Resource Manager.
Vídeo
Pasos siguientes
Estas herramientas de diagnóstico lo ayudarán a inspeccionar los datos de telemetría de su aplicación:
Explorador de búsqueda
Analytics: Lenguaje de consulta eficaz
La detección inteligente es completamente automática. Pero ¿quizás le gustaría configurar algunas alertas más?
Alertas de métricas configuradas manualmente
Detección inteligente: anomalías de error
Application Insights le avisa automáticamente casi en tiempo real si la aplicación web sufre un aumento anómalo
en la frecuencia de solicitudes erróneas. Asimismo, detecta un aumento inusual de la tasa de solicitudes HTTP o
llamadas de dependencia notificadas como errores. En el caso de las solicitudes, las solicitudes con error suelen
tener códigos de respuesta de 400 o superiores. Para ayudarle a evaluar las prioridades y a diagnosticar el
problema, en los detalles de la alerta se proporciona un análisis de las características de los errores, así como
datos de la aplicación relacionados. También hay vínculos en el portal de Application Insights para obtener un
diagnóstico más amplio. La característica no necesita ninguna instalación o configuración, ya que usa algoritmos
de aprendizaje automático para predecir la tasa normal de errores.
Esta característica funciona para cualquier aplicación web, hospedada en la nube o en sus propios servidores, que
genere datos de dependencia o de solicitud de la aplicación. Por ejemplo, si tiene un rol de trabajo que llama a
TrackRequest() o TrackDependency().
Después de configurar Application Insights para su proyecto, si la aplicación genera una cantidad mínima
determinada de datos, la detección inteligente de anomalías de error tarda 24 horas en aprender el
comportamiento normal de la aplicación antes de activarse y poder enviar alertas.
Esta es una alerta de ejemplo:
Los detalles de la alerta le indicarán lo siguiente:
La tasa de errores en comparación con el comportamiento normal de la aplicación.
Cuántos usuarios se ven afectados (para darle una idea de la gravedad).
Un patrón característico relacionado con los errores. En este ejemplo encontrará un código de respuesta, un
nombre de solicitud (operación) y una versión de aplicación concretos. Esto le indica inmediatamente por
dónde empezar a buscar en el código. Otras posibilidades pueden ser un sistema operativo cliente o
explorador específicos.
Las excepciones, seguimientos de registros y errores de dependencias (bases de datos u otros componentes
externos) que parecen estar asociados con los errores caracterizados.
Vínculo directos a búsquedas significativas en los datos de Application Insights.
Ventajas de la detección inteligente

Las alertas de métricas normales le comunican que puede haber un problema. Sin embargo, la detección
inteligente inicia el trabajo de diagnóstico y realiza gran parte del análisis que, de otra forma, tendría que hacer
usted mismo. Los resultados se le presentan claramente organizados, lo que le ayuda a llegar rápidamente a la
raíz del problema.
Funcionamiento
La detección inteligente supervisa los datos recibidos de su aplicación y, en particular, las tasas de errores. Esta
regla cuenta el número de solicitudes para el que la propiedad Successful request es falsa y el número de
llamadas de dependencia para el que la propiedad Successful call es falsa. De manera predeterminada, para las
solicitudes, Successful request == (resultCode < 400) (a no ser que haya escrito código personalizado para filtrar
o generar sus propias llamadas de TrackRequest).
El rendimiento de una aplicación tiene un patrón típico de comportamiento. Algunas solicitudes o llamadas de
dependencia son más propensas a errores que otras; y la tasa de error general puede aumentar a medida que
aumenta la carga. La detección inteligente usa aprendizaje automático para encontrar estas anomalías.
A medida que Application Insights recibe datos de su aplicación web, la detección inteligente compara el
comportamiento actual con los patrones vistos a lo largo de los últimos días. Si se observa un incremento
anómalo de la tasa de errores en comparación con el rendimiento previo, se desencadena un análisis.
Cuando se desencadena un análisis, el servicio realiza un análisis del clúster en la solicitud errónea, para tratar de
identificar un patrón de valores que caracterice los errores.
En el ejemplo anterior, el análisis ha detectado que la mayoría de los errores giran en torno a un código de
resultado, nombre de solicitud, host de URL de servidor e instancia de rol específicos.
Si se instrumenta el servicio con estas llamadas de datos, el analizador busca una excepción y un error de
dependencia que estén asociados a solicitudes del clúster que ha identificado, junto con un ejemplo de cualquier
registro de seguimiento asociado a estas solicitudes.
El análisis resultante se le envía como una alerta, a no ser que configurara lo contrario.
Al igual que con las alertas que establece de forma manual, puede inspeccionar el estado de la alerta
desencadenada y se puede resolver si el problema se ha corregido. Configure las reglas de alertas en la página
Alertas de su recurso de Application Insights. Pero, a diferencia de otras alertas, no es necesario instalar ni
configurar la detección inteligente. Si lo desea, puede deshabilitarla o cambiar sus direcciones de correo
electrónico de destino.
Detalles de la lógica de alerta
Las alertas se desencadenan por nuestro algoritmo de aprendizaje automático propietario, por lo que no se
pueden compartir los detalles exactos de la implementación. Dicho esto, entendemos que a veces se necesita
saber más acerca de cómo funciona la lógica subyacente. Los principales factores que se evalúan para determinar
si se debe desencadenar una alerta son:
Análisis del porcentaje de errores de las solicitudes o dependencias en una ventana de tiempo adaptable de 20
minutos.
Una comparación del porcentaje de errores de los últimos 20 minutos con la tasa de los últimos 40 minutos y
los últimos siete días, y la búsqueda de desviaciones significativas que superen X veces esa desviación
estándar.
Al utilizar un límite adaptativo para el porcentaje mínimo de errores, que varía en función del volumen de
solicitudes o dependencias de la aplicación.
Hay lógica que puede resolver automáticamente la condición supervisada de la alerta desencadenada si el
problema deja de detectarse durante 8-24 horas.
Configurar alertas
Puede deshabilitar la regla de alertas de la detección inteligente desde el portal o a través de Azure Resource
Manager (consulte el ejemplo de plantilla).
Esta regla de alertas está creada con un grupo de acciones asociado denominado "Detección inteligente de
Application Insights" que contiene acciones de correo electrónico y webhook y se puede extender para
desencadenar acciones adicionales cuando se activa la alerta.
NOTE
Las notificaciones por correo electrónico que se envían desde esta regla de alertas ahora se envían de manera
predeterminada a los usuarios asociados con los roles Lector de supervisión y Colaborador de supervisión de la suscripción.
Encontrará más información sobre esto aquí. Las notificaciones enviadas desde esta regla de alertas siguen el esquema de
alertas comunes.
Abra la página Alertas. Las reglas de alertas de anomalías de error se incluyen junto con las alertas que se han
establecido manualmente, y puede ver si están actualmente en el estado de alerta.
Haga clic en la alerta para configurarla.

Tenga en cuenta que puede deshabilitar o eliminar una regla de alertas de anomalías de error, pero no puede
crear otra en el mismo recurso de Application Insights.
Ejemplo de la carga de webhook de una alerta de anomalías de error

{
"properties": {
"essentials": {
"severity": "Sev3",
"signalType": "Log",
"alertState": "New",
"monitorCondition": "Resolved",
"monitorService": "Smart Detector",
"targetResource": "/subscriptions/4f9b81be-fa32-4f96-aeb3-fc5c3f678df9/resourcegroups/test-
group/providers/microsoft.insights/components/test-rule",
"targetResourceName": "test-rule",
"targetResourceGroup": "test-group",
"targetResourceGroup": "test-group",
"targetResourceType": "microsoft.insights/components",
"sourceCreatedId": "1a0a5b6436a9b2a13377f5c89a3477855276f8208982e0f167697a2b45fcbb3e",
"alertRule": "/subscriptions/4f9b81be-fa32-4f96-aeb3-fc5c3f678df9/resourcegroups/test-
group/providers/microsoft.alertsmanagement/smartdetectoralertrules/failure anomalies - test-rule",
"startDateTime": "2019-10-30T17:52:32.5802978Z",
"lastModifiedDateTime": "2019-10-30T18:25:23.1072443Z",
"monitorConditionResolvedDateTime": "2019-10-30T18:25:26.4440603Z",
"lastModifiedUserName": "System",
"actionStatus": {
"isSuppressed": false
},
"description": "Failure Anomalies notifies you of an unusual rise in the rate of failed HTTP
requests or dependency calls."
},
"context": {
"DetectionSummary": "An abnormal rise in failed request rate",
"FormattedOccurenceTime": "2019-10-30T17:50:00Z",
"DetectedFailureRate": "50.0% (200/400 requests)",
"NormalFailureRate": "0.0% (over the last 30 minutes)",
"FailureRateChart": [["2019-10-30T05:20:00Z",
0],
["2019-10-30T05:40:00Z",
100],
["2019-10-30T06:00:00Z",
0],
["2019-10-30T06:20:00Z",
0],
["2019-10-30T06:40:00Z",
100],
["2019-10-30T07:00:00Z",
0],
["2019-10-30T07:20:00Z",
0],
["2019-10-30T07:40:00Z",
100],
["2019-10-30T08:00:00Z",
0],
["2019-10-30T08:20:00Z",
0],
["2019-10-30T08:40:00Z",
100],
["2019-10-30T17:00:00Z",
0],
["2019-10-30T17:20:00Z",
0],
["2019-10-30T09:00:00Z",
0],
["2019-10-30T09:20:00Z",
0],
["2019-10-30T09:40:00Z",
100],
["2019-10-30T10:00:00Z",
0],
["2019-10-30T10:20:00Z",
0],
["2019-10-30T10:40:00Z",
100],
["2019-10-30T11:00:00Z",
0],
["2019-10-30T11:20:00Z",
0],
["2019-10-30T11:40:00Z",
100],
["2019-10-30T12:00:00Z",
0],
["2019-10-30T12:20:00Z",
0],
["2019-10-30T12:40:00Z",
100],
100],
["2019-10-30T13:00:00Z",
0],
["2019-10-30T13:20:00Z",
0],
["2019-10-30T13:40:00Z",
100],
["2019-10-30T14:00:00Z",
0],
["2019-10-30T14:20:00Z",
0],
["2019-10-30T14:40:00Z",
100],
["2019-10-30T15:00:00Z",
0],
["2019-10-30T15:20:00Z",
0],
["2019-10-30T15:40:00Z",
100],
["2019-10-30T16:00:00Z",
0],
["2019-10-30T16:20:00Z",
0],
["2019-10-30T16:40:00Z",
100],
["2019-10-30T17:30:00Z",
50]],
"ArmSystemEventsRequest": "/subscriptions/4f9b81be-fa32-4f96-aeb3-
fc5c3f678df9/resourceGroups/test-group/providers/microsoft.insights/components/test-rule/query?
query=%0d%0a++++++++++++++++systemEvents%0d%0a++++++++++++++++%7c+where+timestamp+%3e%3d+datetime(%272019-10-
30T17%3a20%3a00.0000000Z%27)+%0d%0a++++++++++++++++%7c+where+itemType+%3d%3d+%27systemEvent%27+and+name+%3d%3
d+%27ProactiveDetectionInsight%27+%0d%0a++++++++++++++++%7c+where+dimensions.InsightType+in+
(%275%27%2c+%277%27)+%0d%0a++++++++++++++++%7c+where+dimensions.InsightDocumentId+%3d%3d+%27718fb0c3-425b-
4185-be33-
4311dfb4deeb%27+%0d%0a++++++++++++++++%7c+project+dimensions.InsightOneClassTable%2c+%0d%0a++++++++++++++++++
++++++++dimensions.InsightExceptionCorrelationTable%2c+%0d%0a++++++++++++++++++++++++++dimensions.InsightDepe
ndencyCorrelationTable%2c+%0d%0a++++++++++++++++++++++++++dimensions.InsightRequestCorrelationTable%2c+%0d%0a
++++++++++++++++++++++++++dimensions.InsightTraceCorrelationTable%0d%0a++++++++++++&api-version=2018-04-20",
"LinksTable": [{
"Link": "<a
href=\"https://portal.azure.com/#blade/AppInsightsExtension/ProactiveDetectionFeedBlade/ComponentId/{\"Subscr
iptionId\":\"4f9b81be-fa32-4f96-aeb3-fc5c3f678df9\",\"ResourceGroup\":\"test-group\",\"Name\":\"test-
rule\"}/SelectedItemGroup/718fb0c3-425b-4185-be33-4311dfb4deeb/SelectedItemTime/2019-10-
30T17:50:00Z/InsightType/5\" target=\"_blank\">View full details in Application Insights</a>"
}],
"SmartDetectorId": "FailureAnomaliesDetector",
"SmartDetectorName": "Failure Anomalies",
"AnalysisTimestamp": "2019-10-30T17:52:32.5802978Z"
},
"egressConfig": {
"displayConfig": [{
"rootJsonNode": null,
"sectionName": null,
"displayControls": [{
"property": "DetectionSummary",
"displayName": "What was detected?",
"type": "Text",
"isOptional": false,
"isPropertySerialized": false
},
{
"property": "FormattedOccurenceTime",
"displayName": "When did this occur?",
"type": "Text",
},
{
"property": "DetectedFailureRate",
"displayName": "Detected failure rate",
"displayName": "Detected failure rate",
"type": "Text",
},
{
"property": "NormalFailureRate",
"displayName": "Normal failure rate",
"type": "Text",
},
{
"chartType": "Line",
"xAxisType": "Date",
"yAxisType": "Percentage",
"xAxisName": "",
"yAxisName": "",
"property": "FailureRateChart",
"displayName": "Failure rate over last 12 hours",
"type": "Chart",
},
{
"defaultLoad": true,
"displayConfig": [{
"rootJsonNode": null,
"sectionName": null,
"displayControls": [{
"showHeader": false,
"columns": [{
"property": "Name",
"displayName": "Name"
},
{
"property": "Value",
"displayName": "Value"
}],
"property": "tables[0].rows[0][0]",
"displayName": "All of the failed requests had these characteristics:",
"type": "Table",
"isPropertySerialized": true
}]
}],
"property": "ArmSystemEventsRequest",
"displayName": "",
"type": "ARMRequest",
},
{
"showHeader": false,
"columns": [{
"property": "Link",
"displayName": "Link"
}],
"property": "LinksTable",
"displayName": "Links",
"type": "Table",
}]
}]
}
},
"id": "/subscriptions/4f9b81be-fa32-4f96-aeb3-fc5c3f678df9/resourcegroups/test-
group/providers/microsoft.insights/components/test-rule/providers/Microsoft.AlertsManagement/alerts/7daf8739-
ca8a-4562-b69a-ff28db4ba0a5",
ca8a-4562-b69a-ff28db4ba0a5",
"type": "Microsoft.AlertsManagement/alerts",
"name": "Failure Anomalies - test-rule"
}
Evaluación de prioridades y diagnóstico de una alerta

Una alerta indica que se detectó un aumento anómalo de la tasa de solicitudes con errores. Es probable que haya
algún problema con la aplicación o con su entorno.
Si necesita investigar más, haga clic en los vínculos "Ver todos los detalles en Application Insights" de esta página
que le llevarán directamente a una página de búsqueda filtrada por las solicitudes, la excepción, la dependencia o
el seguimiento correspondientes.
También puede abrir Azure Portal, navegar hasta el recurso de Application Insights de su aplicación y abrir la
página Errores.
Al hacer clic en "Diagnosticar errores", obtendrá más detalles y podrá resolver el problema.
Puede determinar la urgencia del problema a partir del porcentaje de solicitudes y del número de usuarios
afectados. En el ejemplo anterior, la tasa de error del 78,5 % se compara con una tasa normal del 2,2 %, lo que
indica que hay algo que no va bien. Por otro lado, solo 46 usuarios se vieron afectados. Si se tratara de su
aplicación, podría evaluar la gravedad del problema.
En muchos casos, podrá diagnosticar el problema rápidamente a partir del nombre de la solicitud, las excepciones,
los errores de dependencias y otros datos de seguimiento proporcionados.
En este ejemplo, se produjo una excepción de SQL Database debido a que se alcanzó el límite de solicitudes.
Revisar las alertas recientes
Haga clic en Aler tas en la página de recursos de Application Insights para ver las alertas desencadenadas más
recientes:
¿Cuál es la diferencia ...

La detección inteligente de anomalías de errores complementa otras características similares pero distintas de
Las alertas de métricas las configura el usuario y pueden supervisar una amplia variedad de métricas,
como el uso de la CPU, las tasas de solicitudes y los tiempos de carga de las páginas, entre otras. Puede
usarlas para avisarle, por ejemplo, de si necesita agregar más recursos. Por el contrario, la detección
inteligente de anomalías de error abarca un pequeño conjunto de métricas críticas (actualmente solo la
tasa de solicitudes con errores), diseñadas para notificarle casi en tiempo real el momento en el que la tasa
de solicitudes con errores de la aplicación web aumenta en comparación con el comportamiento normal de
esta. A diferencia de las alertas de métricas, la detección inteligente establece y actualiza automáticamente
los umbrales en respuesta a los cambios en el comportamiento. La detección inteligente también inicia el
trabajo de diagnóstico, lo que le ahorra tiempo en la resolución de problemas.
La detección inteligente de anomalías de rendimiento también usa la inteligencia automática para detectar
patrones inusuales en las métricas y no requiere ninguna configuración por parte del usuario. Pero a
diferencia de la detección inteligente de anomalías de errores, el objetivo de la detección inteligente de
anomalías de rendimiento es encontrar segmentos del colector de uso que pudieran haberse servidor
incorrectamente, por ejemplo, por páginas específicas de un tipo específico de explorador. El análisis se
realiza diariamente y, si se encuentra algún resultado, probablemente sea mucho menos urgente que una
alerta. Por el contrario, el análisis de anomalías de error se realiza continuamente sobre los datos de
aplicación entrantes, y se le notificará en unos minutos si las tasas de errores del servidor son mayores de
lo esperado.
Si recibe una alerta de detección inteligente

¿Por qué he recibido esta alerta?
Hemos detectado un aumento anómalo en la tasa de solicitudes con errores en comparación con la línea de
base normal del período anterior. Después de analizar los errores y los datos de aplicación asociados, creemos
que hay un problema que debe examinar.
¿La notificación significa que tengo definitivamente un problema?
Intentamos alertarle sobre las interrupciones o la degradación de la aplicación, aunque solo usted puede
entender totalmente la semántica y el impacto en la aplicación o los usuarios.
¿Está viendo los datos de mi aplicación?
No. El servicio es completamente automático. Solo obtendrá las notificaciones. Sus datos son privados.
¿Es necesario suscribirse a esta alerta?
No. Cada aplicación que envía datos de solicitud tiene la regla de alerta de detección inteligente.
¿Puedo cancelar la suscripción u hacer que mis colegas reciban las notificaciones?
Sí, en Reglas de alerta, haga clic en la regla de detección inteligente para configurarla. Puede deshabilitar la
alerta o cambiar a los destinatarios de la misma.
Perdí el mensaje de correo electrónico. ¿Dónde puedo encontrar las notificaciones en el portal?
En los registros de actividad. En Azure, abra el recurso de Application Insights correspondiente a su aplicación y
luego seleccione los registros de actividad.
Algunas de las alertas se refieren a problemas conocidos y no deseo recibirlas.
Puede usar la característica de supresión de las reglas de acción de alerta.
Pasos siguientes
Estas herramientas de diagnóstico lo ayudarán a inspeccionar los datos de su aplicación:
Explorador de búsqueda
Analytics: Lenguaje de consulta eficaz
Las detecciones inteligentes son automáticas. Pero ¿quizás le gustaría configurar algunas alertas más?
Detección inteligente: anomalías de rendimiento
Application Insights analiza automáticamente el rendimiento de su aplicación web y puede advertirle de los
posibles problemas. Podría estar leyendo este artículo porque ha recibido una de nuestras notificaciones de
detección inteligente.
Esta característica no requiere ninguna configuración especial, tan solo ajustar los parámetros de la aplicación
para Application Insights para el idioma admitido. Se activará cuando la aplicación genera suficientes datos de
telemetría.
¿Cuándo recibiría una notificación de detección inteligente?

Application Insights ha detectado que el rendimiento de la aplicación se ha degradado en una de estas maneras:
Degradación del tiempo de respuesta : la aplicación ha comenzado a responder a las solicitudes de una
forma más lenta de lo habitual. El cambio podría haber sido rápido, por ejemplo, porque hubo una regresión
en la implementación más reciente. También podría haber sido gradual, probablemente debido a una fuga de
memoria.
Degradación de la duración de la dependencia : la aplicación realiza llamadas a una API de REST, una
base de datos u otra dependencia. La dependencia responde de una forma más lenta de lo habitual.
Patrón de rendimiento lento : la aplicación parece tener un problema de rendimiento que está afectando
solo a algunas solicitudes. Por ejemplo, las páginas se cargan mucho más lentamente en un tipo de explorador
que en otros, o las solicitudes se atienden de una forma más lenta desde un servidor concreto. En la
actualidad, nuestros algoritmos examinan tiempos de carga de página, tiempos de respuesta de solicitud y
tiempos de respuesta de dependencia.
Detección inteligente requiere, al menos, 8 días de datos de telemetría en un volumen de trabajo con el fin de
establecer una línea de base de rendimiento normal. Por lo tanto, después de que la aplicación se haya estado
ejecutando durante ese periodo, se generará una notificación cuando se produzca un problema significativo.
Entonces, ¿mi aplicación tiene un problema?

No, una notificación no significa que la aplicación tenga un problema. Simplemente es una sugerencia sobre algo
que puede que desee examinar con más detenimiento.
¿Cómo puedo corregirlo?

Las notificaciones incluyen información de diagnóstico. Este es un ejemplo:
1. Evaluación de errores . La notificación muestra el número de usuarios u operaciones afectado. Esto
puede ayudarlo a asignar una prioridad al problema.
2. Ámbito . ¿Está el problema afectando a todo el tráfico o solo a algunas páginas? ¿Está limitado a
ubicaciones o exploradores determinados? Esta información puede obtenerse de la notificación.
3. Diagnóstico . A menudo, la información de diagnóstico de la notificación sugiere cuál es la naturaleza del
problema. Por ejemplo, si el tiempo de respuesta se ralentiza cuando la velocidad de solicitudes es alta, el
problema podría estar en que su servidor o dependencias están sobrecargadas.
Si no sugiere la causa, abra la hoja Rendimiento de Application Insights. Allí encontrará los datos de
Profiler. Si se producen excepciones, también puede probar el Depurador de instantáneas.
Configuración de notificaciones de correo electrónico

Las notificaciones de Detección inteligente se habilitan de forma predeterminada y se envían a aquellos que
tienen el acceso Lector de supervisión y Colaborador de supervisión a la suscripción en la que reside el recurso
de Application Insights. Para cambiar esta configuración, haga clic en la opción Configurar de la notificación por
correo electrónico, o bien abra la configuración de Detección inteligente en Application Insights.
Para dejar de recibir notificaciones por correo electrónico, puede usar el vínculo de cancelación de
suscripción del correo electrónico de Detección inteligente .
Los mensajes de correo electrónico de las anomalías de rendimiento de Detección inteligente tienen una
limitación de un correo electrónico al día por recurso de Application Insights. El mensaje de correo electrónico
solo se enviará si se ha detectado, como mínimo, un problema nuevo ese día. No obtendrá repeticiones de ningún
mensaje.

¿El personal de Microsoft mira mis datos?
No. El servicio es completamente automático. Solo obtendrá las notificaciones. Sus datos son privados.
¿Analiza todos los datos recopilados por Application Insights?
No en este momento. Actualmente, analizamos el tiempo de respuesta de la solicitud, el tiempo de
respuesta de dependencia y el tiempo de carga de la página. En un futuro analizaremos más métricas.
¿En qué tipos de aplicación funciona?
Estas degradaciones se detectan en cualquier aplicación que generan los datos de telemetría. Si instaló
Application Insights en su aplicación web, el seguimiento de las solicitudes y las dependencias se realiza
automáticamente. Sin embargo, en los servicios back-end u otras aplicaciones, si insertó llamadas a
TrackRequest() o TrackDependency, la Detección inteligente funcionará de la misma manera.
¿Puedo crear mis propias reglas de detección de anomalías o personalizar las existentes?
Aún no, pero puede realizar lo siguiente:
Configurar alertas que le indiquen cuándo una métrica cruza un umbral.
Exportar telemetría a una base de datos o a PowerBI para poder realizar un análisis usted mismo.
¿Con qué frecuencia se lleva a cabo el análisis?
Ejecutamos el análisis diariamente en la telemetría del día anterior (día completo en la zona horaria
UTC).
¿Sustituye esto a las alertas de métricas?
No. No nos comprometemos a detectar cada comportamiento que el usuario podría anómalo.
Si no tomo ninguna medida como respuesta a una notificación, ¿recibiré un aviso?
No, obtendrá un mensaje sobre cada problema solo una vez. Si el problema persiste, se actualizará en la
hoja de fuente de Detección inteligente.
Perdí el mensaje de correo electrónico. ¿Dónde puedo encontrar las notificaciones en el portal?
En la información general de Application Insights de su aplicación, haga clic en el icono Detección
inteligente . Allí encontrará todas las notificaciones de los 90 últimos días.
¿Cómo puedo mejorar el rendimiento?

Las respuestas lentas y los errores se encuentran entre los principales motivos de frustración entre los usuarios
de los sitios web, como bien sabrá por su propia experiencia. Por lo tanto, es importante que trate los problemas.
Evaluación de errores
En primer lugar, ¿es realmente importante? Si una página siempre tarda en cargarse, pero solo un 1 % de los
usuarios del sitio accede a ella, es posible que tenga cosas más importantes de las que ocuparse. Por otro lado, si
solo un 1 % de los usuarios la abren, pero aún así produce excepciones cada vez, puede que merezca la pena
investigar el problema.
Use la instrucción de impacto (usuarios afectados o porcentaje de tráfico) como guía general, pero tenga en
cuenta que esta no le va a explicar todo lo que pasa. Recopile otras pruebas para confirmar.
Tenga en cuenta los parámetros del problema. Si es dependiente de la ubicación, configure pruebas de
disponibilidad que incluyan la región: simplemente puede que haya problemas de red en esa área.
Diagnostico de cargas de página lentas
¿Dónde está el problema? ¿Es el servidor lento para responder, es la página muy larga o requiere mucho trabajo
del explorador para mostrarla?
Abra la hoja de métricas del navegador. La visualización segmentada del tiempo de carga de página del
explorador muestra en qué se va el tiempo.
Si el tiempo de solicitud de envío es alto, o bien el servidor responde con lentitud o la solicitud es un envío
con una gran cantidad de datos. Mire las métricas de rendimiento para investigar los tiempos de respuesta.
Configure el seguimiento de dependencias para ver si la lentitud se debe a los servicios externos o a su base
de datos.
Si predomina la recepción de respuesta , la página y sus elementos dependientes (JavaScript, CSS,
imágenes y demás, excluyendo los datos cargados de forma asincrónica) son largos. Configure una prueba de
disponibilidad, y asegúrese de establecer la opción de cargar los elementos dependientes. Cuando obtenga
algunos resultados, abra el detalle de un resultado y expándalo para ver los tiempos de carga de los distintos
archivos.
Un Tiempo de procesamiento del cliente alto sugiere que los scripts se ejecutan con lentitud. Si el motivo
no es obvio, considere la posibilidad de agregar algún código de control de tiempo y enviar las horas en
llamadas de trackMetric.
Mejora de páginas lentas
Hay un sitio web completo de consejos sobre cómo mejorar las respuestas del servidor y los tiempos de carga de
página, por lo que no intentaremos repetirlo aquí todo otra vez. Estas son algunas sugerencias que
probablemente ya conozca, pero que pueden ayudarle a pensar en soluciones:
Ralentización de la carga debido a archivos grandes: cargue los scripts y otras partes de forma asincrónica.
Use la agrupación de scripts. Divida la página principal en widgets que cargan sus datos por separado. No
envíe simples HTML antiguos para tablas de gran tamaño: use un script para solicitar los datos como JSON u
otro formato compacto y luego rellene la tabla en su lugar. Existen excelentes marcos para ayudarle con todo
esto. (Lo que también implican grandes scripts, por supuesto.)
Ralentización de las dependencias de servidor: tenga en cuenta las ubicaciones geográficas de los
componentes. Por ejemplo, si usa Azure, asegúrese de que el servidor web y la base de datos se encuentran en
la misma región. ¿Es posible que consultas las consultas recuperen más información de la que necesitan?
¿Podría ayudar el almacenamiento en caché o el procesamiento por lotes?
Problemas de capacidad: eche una ojeada a las métricas de servidor de tiempos de respuesta y recuentos de
solicitudes. Si los tiempos de respuesta presentan picos desproporcionados en recuentos de solicitud, es
probable que se está tirando en exceso de los servidores.
Degradación del tiempo de respuesta del servidor

La notificación de degradación del tiempo de respuesta indica lo siguiente:
El tiempo de respuesta en comparación con el tiempo de respuesta normal de esta operación.
El número de usuarios afectados.
El tiempo promedio de respuesta y el tiempo de respuesta del percentil 90 de esta operación en el día de la
detección y 7 días antes.
El número de solicitudes de esta operación en el día de la detección y 7 días antes.
La correlación entre la degradación en esta operación y las degradaciones en las dependencias relacionadas.
Los vínculos para ayudarlo a diagnosticar el problema:
Los seguimientos del generador de perfiles para ayudarlo a ver en qué se ha invertido el tiempo de
operación (el vínculo está disponible si se han recopilado ejemplos de seguimientos del generador de
perfiles para esta operación durante el periodo de detección).
Los informes de rendimiento del Explorador de métrica, donde puede segmentar y desglosar los filtros
o intervalos de tiempo de esta operación.
Busque esta llamada ver las propiedades de llamadas específicas.
Informes de error: si el número es mayor que 1, significa que hubo errores en esta operación que
pueden haber contribuido a la degradación del rendimiento.
Degradación de la duración de la dependencia

Las aplicaciones modernas adoptan cada vez más enfoques de diseño de microservicios, lo que en muchos casos
conduce a que el nivel de confiabilidad en los servicios externos sea muy elevado. Por ejemplo, si la aplicación se
basa en alguna plataforma de datos o incluso si genera su propio servicio de bots, probablemente confiará en
algún proveedor de servicios cognitivos para habilitar sus bots con el fin de que interactúen de una forma más
humana, así como en algún servicio de almacenamiento de datos que utilicen dichos bots para responder.
Notificación de degradación de dependencia de ejemplo:
Observe que le indica:
La duración en comparación con el tiempo de respuesta normal de esta operación
El número de usuarios afectados.
Duración promedio y duración del percentil 90 de esta dependencia en el día de la detección y 7 días antes.
Número de llamadas de dependencia en el día de la detección y 7 días antes.
Los vínculos para ayudarlo a diagnosticar el problema:
Informes de rendimiento del Explorador de métrica de esta dependencia.
Busque estas llamadas de dependencia para ver las propiedades de llamadas.
Informes de error: si el número es mayor que 1, significa que hubo errores de llamadas de dependencia
durante el período de detección que podrían haber contribuido a la degradación de la duración.
Abra Análisis con las consultas que calculan el número y la duración de esta dependencia.
Detección inteligente de los patrones de rendimiento lento

Application Insights busca los problemas de rendimiento que podrían afectar solo a algunos de sus usuarios, o
bien exclusivamente a sus usuarios en algunos casos. Por ejemplo, una notificación de si las páginas de su
aplicación se cargan más lentamente en un tipo de explorador que en otros, o de si las solicitudes se atienden de
una forma más lenta desde un servidor determinado. También puede detectar problemas asociados con
combinaciones de propiedades, como los clientes que usan un determinado sistema operativo y experimentan
cargas lentas de página.
Anomalías como estas son muy difíciles de detectar con tan solo inspeccionar los datos, pero son más comunes
de lo que puede creer. A menudo, solo se muestran cuando se quejan los clientes. Para entonces, ya es demasiado
tarde: los usuarios afectados ya se han pasado a sus competidores.
En la actualidad, nuestros algoritmos examinan tiempos de carga de página, tiempos de respuesta de solicitud en
el servidor y tiempos de respuesta de dependencia.
No tiene que establecer ningún umbral o regla de configuración. El aprendizaje automático y los algoritmos de
minería de datos se usan para detectar patrones anormales.
Cuándo muestra la hora en que se detectó el problema.

Qué describe:
el problema detectado;
las características del conjunto de eventos que encontramos mostraron el comportamiento del
problema.
La tabla compara el conjunto de bajo rendimiento con el comportamiento medio de todos los demás
eventos.
Haga clic en los vínculos para abrir el Explorador de métricas y Búsqueda en los informes relevantes, filtrados en
la hora y las propiedades del conjunto de rendimiento lento.
Modifique los filtros y el intervalo de tiempo para explorar la telemetría.
Pasos siguientes
Estas herramientas de diagnóstico lo ayudarán a inspeccionar los datos de telemetría de su aplicación:
depurador de instantáneas
Analytics
Diagnóstico de análisis inteligente
Las detecciones inteligentes son completamente automáticas. Pero ¿quizás le gustaría configurar algunas alertas
más?
Degradación en la relación de gravedad de
seguimiento (versión preliminar)
Los seguimientos se usan ampliamente en aplicaciones, ya que ayudan a describir lo que sucede en segundo
plano. Cuando algo va mal, los seguimientos proporcionan visibilidad fundamental en la secuencia de eventos que
conducen al estado no deseado. Aunque los seguimientos no están estructurados generalmente, hay algo que
puede aprender de ellos en concreto: su nivel de gravedad. En el estado estable de una aplicación, se podría
esperar que la relación entre los seguimientos "correctos" (Información y Detallado) y los seguimientos
"incorrectos" (Advertencia, Error y Crítico) permanecieran estables. La suposición es que los seguimientos
"incorrectos" pueden reflejarse de forma periódica hasta cierto punto debido a una serie de motivos (por ejemplo,
problemas de red transitorios). Pero cuando un problema real comienza a crecer, normalmente se manifiesta como
un aumento en la proporción relativa de los seguimientos "incorrectos" y "correctos". La detección inteligente de
Application Insights analiza automáticamente los seguimientos registrados por la aplicación y puede avisarle sobre
los patrones poco habituales en la gravedad de la telemetría de seguimiento.
Esta característica no requiere ninguna configuración especial, que no sea la configuración del registro de
seguimiento de la aplicación (consulte cómo configurar un agente de escucha de registro de seguimiento para
.NET o Java). Se activará cuando la aplicación genere suficiente telemetría de excepciones.
¿Cuándo recibiré este tipo de notificación de detección inteligente?

Es posible que obtenga este tipo de notificación si la relación entre los seguimientos “correctos” (seguimientos
iniciados con el nivel Información o Detallado) y los seguimientos “incorrectos” (seguimientos iniciados con el
nivel Advertencia, Error o Irrecuperable) se degrada en un día determinado, en comparación con una base de
referencia calculada durante los últimos siete días.

No, una notificación no significa que la aplicación tenga un problema. Aunque una degradación en la relación entre
los seguimientos "correctos" e "incorrectos" podría indicar un problema de aplicación, este cambio en la relación
también puede ser benigno. Por ejemplo, el aumento podría ser debido a un nuevo flujo en la aplicación que emita
más seguimientos "incorrectos" que los flujos de existentes.

Las notificaciones incluyen información de diagnóstico para facilitar el proceso de diagnóstico:
1. Evaluación de prioridades . La notificación muestra el número de operaciones afectadas. Esto puede
ayudarlo a asignar una prioridad al problema.
2. Ámbito. ¿El problema afecta a todo el tráfico o solo a alguna operación? Esta información puede obtenerse de
la notificación.
3. Diagnóstico. Puede usar los elementos relacionados y los vínculos de informes para obtener información que
puede ayudarle a efectuar un diagnóstico más exhaustivo del problema.
Aumento anormal del volumen de excepciones
Application Insights analiza automáticamente las excepciones generadas en la aplicación y puede avisarle sobre los
patrones inusuales en la telemetría de excepciones.
Esta característica no requiere ninguna configuración especial, excepto la configuración de los informes de
excepciones de la aplicación. Se activará cuando la aplicación genere suficiente telemetría de excepciones.

Es posible que obtenga este tipo de notificación si la aplicación presenta un aumento anormal en el número de
excepciones de un tipo específico durante un día, en comparación con una base de referencia calculada durante los
últimos siete días. Se usan algoritmos de aprendizaje automático para detectar el aumento en el número de
excepciones, teniendo en cuenta un crecimiento natural en el uso de la aplicación.

No, una notificación no significa que la aplicación tenga un problema. Aunque un número excesivo de excepciones
suele indicar un problema de la aplicación, es posible que estas sean benignas y que la aplicación las controle
correctamente.

Las notificaciones incluyen información de diagnóstico para facilitar el proceso de diagnóstico:
1. Evaluación de prioridades . La notificación muestra el número de usuarios o solicitudes afectados. Esto
puede ayudarlo a asignar una prioridad al problema.
2. Ámbito. ¿El problema afecta a todo el tráfico o solo a alguna operación? Esta información puede obtenerse de
la notificación.
3. Diagnóstico. La detección contiene información sobre el método desde el que se generó la excepción, así
como del tipo de excepción. También puede usar los elementos relacionados y los vínculos de informes para
obtener información que puede ayudarle a efectuar un diagnóstico más exhaustivo del problema.
Detección de fugas de memoria (versión preliminar)
Application Insights analiza automáticamente el consumo de memoria de cada uno de los procesos de la
aplicación y le avisará sobre posibles fugas de memoria o de un aumento en el consumo de memoria.
Esta característica no requiere ninguna configuración especial, excepto la configuración de los contadores de
rendimiento de la aplicación. Se activa cuando la aplicación genera suficiente telemetría en los contadores de
rendimiento de memoria (por ejemplo, bytes privados).

Una notificación típica suele generarse por un aumento uniforme del consumo de memoria durante un largo
período de tiempo, en uno o más procesos y/o en uno o varios equipos, que forman parte de la aplicación. Los
algoritmos de aprendizaje automático se utilizan para detectar un consumo de memoria aumentado que coincida
con un patrón de fuga de memoria.
Entonces, ¿mi aplicación tiene realmente un problema?

No, una notificación no significa que la aplicación tenga un problema. Aunque los patrones de fuga de memoria
generalmente indican un problema de aplicación, estos patrones pueden ser típicos de su proceso específico, o
pueden tener una justificación comercial natural, y pueden ignorarse.

Las notificaciones incluyen información de diagnóstico para facilitar el proceso de análisis de diagnóstico:
1. Evaluación de prioridades . La notificación muestra cuánto aumentó la memoria (en GB) y el intervalo de
tiempo en el que se produjo ese aumento. Esto puede ayudarlo a asignar una prioridad al problema.
2. Ámbito. ¿Cuántas máquinas mostraron el patrón de fuga de memoria? ¿Cuántas excepciones se
desencadenaron durante la posible fuga de memoria? Esta información puede obtenerse de la notificación.
3. Diagnóstico. La detección contiene el patrón de fuga de memoria, y muestra el consumo de memoria del
proceso a lo largo del tiempo. También puede usar los elementos relacionados y los vínculos de informes para
obtener información que puede ayudarle a efectuar un diagnóstico más exhaustivo del problema.
Application Security Detection Pack (versión
preliminar)
Application Insights analiza automáticamente la telemetría generada por la aplicación y detecta posibles
problemas de seguridad. Esta funcionalidad permite identificar los posibles problemas de seguridad y controlarlos
corrigiendo la aplicación o tomando las medidas de seguridad necesarias.
Esta característica no requiere ninguna configuración especial, excepto configurar la aplicación para que envíe la
telemetría.

Se detectan tres tipos de problemas de seguridad:
1. Acceso a direcciones URL no seguro: se está accediendo a una dirección URL en la aplicación a través de HTTP y
HTTPS. Normalmente, una dirección URL que acepta solicitudes HTTPS no debe aceptar solicitudes HTTP. Esto
puede indicar un problema de seguridad o errores en la aplicación.
2. Formulario no seguro: un formulario (u otra solicitud "POST") en la aplicación usa HTTP en lugar de HTTPS. El
uso de HTTP puede poner en peligro los datos del usuario que envía el formulario.
3. Actividad del usuario sospechosa: el mismo usuario está accediendo a la aplicación desde varios países o
regiones aproximadamente al mismo tiempo. Por ejemplo, el mismo usuario accedió a la aplicación desde
España y desde Estados Unidos durante la misma hora. Esta detección indica un intento de acceso a la
aplicación potencialmente malintencionado.
¿Significa esto que la aplicación tiene un problema de seguridad?

No, una notificación no significa que la aplicación tenga un problema de seguridad. En muchos casos, una
detección de cualquiera de los escenarios anteriores puede indicar un problema de seguridad. Sin embargo, la
detección puede tener una justificación comercial natural y se puede omitir.
¿Cómo se soluciona una detección de "Acceso a direcciones URL no

seguro"?
1. Evaluación de prioridades . La notificación proporciona el número de usuarios que accedieron a direcciones
URL no seguras y la dirección URL más afecta por acceso no seguro. Esto puede ayudarlo a asignar una
prioridad al problema.
2. Ámbito. ¿Qué porcentaje de usuarios obtienen acceso a direcciones URL no seguras? ¿Cuántas direcciones
URL se vieron afectadas? Esta información puede obtenerse de la notificación.
3. Diagnóstico. La detección proporciona la lista de solicitudes no seguras y la lista de direcciones URL y
usuarios que se vieron afectados, para ayudar a efectuar un diagnóstico exhaustivo del problema.
¿Cómo se soluciona la detección "Formulario no seguro"?

1. Evaluación de prioridades . La notificación informa del número de formularios no seguros y del número de
usuarios cuyos datos estuvieron potencialmente en peligro. Esto puede ayudarlo a asignar una prioridad al
problema.
2. Ámbito. ¿Qué formulario estuvo implicado en el mayor número de transmisiones no seguras y cuál es la
distribución de las transmisiones no seguras a lo largo del tiempo? Esta información puede obtenerse de la
notificación.
3. Diagnóstico. La detección proporciona la lista de formularios no seguros y desglosa el número de
transmisiones no seguras de cada formulario, para ayudar a efectuar un diagnóstico exhaustivo del problema.
¿Cómo se soluciona la detección "Actividad del usuario sospechosa"?

1. Evaluación de prioridades . La notificación proporciona el número de los diferentes usuarios que exhibieron
este comportamiento sospechoso. Esto puede ayudarlo a asignar una prioridad al problema.
2. Ámbito. ¿Desde qué países o regiones se originó la solicitud sospechosa? ¿Qué usuario era más sospechoso?
Esta información puede obtenerse de la notificación.
3. Diagnóstico. La detección proporciona la lista de usuarios sospechosos y la lista de países o regiones para
cada usuario, para ayudarle a efectuar un diagnóstico exhaustivo del problema.
Alerta sobre problemas en Azure Cloud Services
mediante la integración de Azure Diagnostics con
Azure Application Insights
En este artículo se describirá cómo configurar reglas de alerta para supervisan problemas como errores de inicio,
bloqueos y bucles de reciclaje de roles en Azure Cloud Services (roles web y de trabajo).
El método descrito en este artículo se basa en la integración Azure Diagnostics con Application Insights y la
funcionalidad de alertas de registro para Application Insights lanzada recientemente.
Definición de una consulta base

Para empezar, definiremos una consulta base que recupera los eventos del registro de eventos de Windows desde
el canal de Microsoft Azure, que se capturan en Application Insights como registros de seguimiento. Estos registros
se pueden utilizar para detectar diversos problemas en Azure Cloud Services, como errores de inicio, errores en
tiempo de ejecución y bucles de reciclaje.
NOTE
La siguiente consulta base comprueba si hay problemas en un período de tiempo de treinta minutos y supone una latencia
de diez minutos en la ingesta de los registros de telemetría. Estos valores predeterminados se pueden configurar como
considere oportuno.
let window = 30m;

let endTime = ago(10m);
let EventLogs = traces
| where timestamp > endTime - window and timestamp < endTime
| extend channel = tostring(customDimensions.Channel), eventId = tostring(customDimensions.EventId)
| where channel == 'Windows Azure' and isnotempty(eventId)
| where tostring(customDimensions.DeploymentName) !contains 'deployment' // discard records captured from local
machines
| project timestamp, channel, eventId, message, cloud_RoleInstance, cloud_RoleName, itemCount;
Comprobación de identificadores de eventos específicos

Después de recuperar los eventos del registro de eventos de Windows, se pueden detectar problemas específicos
mediante la comprobación de sus propiedades de mensaje y de identificador de evento correspondientes (vea los
ejemplos siguientes). Simplemente combine la consulta base anterior con una de las consultas siguientes y use esa
consulta combinada cuando defina la regla de alerta de registro.
NOTE
En los ejemplos siguientes, se detectará un problema si se encuentran más de tres eventos durante el período de tiempo
analizado. Este comportamiento predeterminado puede configurarse para cambiar la sensibilidad de la regla de alerta.
// Detect failures in the OnStart method
EventLogs
| where eventId == '2001'
| where message contains '.OnStart()'
| summarize Failures = sum(itemCount) by cloud_RoleInstance, cloud_RoleName
| where Failures > 3
// Detect failures during runtime

EventLogs
| where message contains '.Run()'
// Detect failures when running a startup task

EventLogs
// Detect recycle loops

EventLogs
Crear una alerta

En el menú de navegación del recurso de Application Insights, vaya a Aler tas y luego seleccione Nueva regla de
aler tas .
En la ventana Crear regla , en la sección Definir condición de la aler ta , haga clic en Agregar criterios y luego
seleccione Búsqueda de registros personalizada .
En el cuadro Consulta de búsqueda , pegue la consulta combinada que preparó en el paso anterior.
Luego, siga con el cuadro Umbral y establezca su valor en 0. Si lo desea, puede ajustar los campos Período y
Frecuencia . Haga clic en Done (Listo).
En la sección Definir detalles de la aler ta , proporcione un nombre y descripción a la regla de alerta y

establezca su gravedad . Además, asegúrese de que el botón Habilitar regla tras la creación se establece en Sí .
En la sección Definir grupo de acciones , puede seleccionar un grupo de acciones existente o crear uno nuevo.
Puede elegir que el grupo de acciones contenga varias acciones de distintos tipos.
Una vez que haya definido el grupo de acciones, confirme los cambios y haga clic en Crear regla de aler tas .
Pasos siguientes
Más información sobre la detección automática:
Anomalías de error Fugas de memoria Anomalías de rendimiento
Administración de reglas de detección inteligente de
Application Insights con plantillas de Azure Resource
Manager
Las reglas de detección inteligente de Application Insights se pueden administrar y configurar con plantillas de
Azure Resource Manager. Este método puede usarse al implementar nuevos recursos de Application Insights con
la automatización de Azure Resource Manager o para modificar la configuración de los recursos existentes.
Configuración de una regla de detección inteligente

Puede configurar los siguientes valores en una regla de detección inteligente:
Si la regla se habilita (el valor predeterminado es true ).
Si no se deben enviar correos electrónicos a los usuarios asociados con los roles Lector de supervisión y
Colaborador de supervisión cuando se encuentra una detección (el valor predeterminado es true ).
Los destinatarios de correo electrónico adicionales que deben recibir una notificación cuando se encuentra una
detección.
La configuración de correo electrónico no está disponible para las reglas de detección inteligente
marcadas como versión preliminar.
Para permitir la configuración de los valores de regla a través de Azure Resource Manager, la configuración de
reglas de detección inteligente ahora está disponible como recurso interno en el recurso de Application Insights
denominado ProactiveDetectionConfigs . Para obtener la máxima flexibilidad, cada regla de detección
inteligente puede configurarse con valores de notificación únicos.
Ejemplos
A continuación se muestran algunos ejemplos que muestran cómo configurar los valores de reglas de detección
inteligente mediante plantillas de Azure Resource Manager. Todos los ejemplos hacen referencia a un recurso de
Application Insights denominado "myApplication" y a la "regla de detección inteligente de duración de la
dependencia prolongada" que internamente se denomina "longdependencyduration" . Asegúrese de reemplazar el
nombre de recurso de Application Insights y de especificar el nombre interno de la regla de detección inteligente
pertinente. En la tabla siguiente, busque una lista de los nombres internos de Azure Resource Manager
correspondientes a cada regla de detección inteligente.
Deshabilitación de una regla de detección inteligente
{
"name": "myApplication",
"type": "Microsoft.Insights/components",
"properties": {
"ApplicationId": "myApplication"
},
"resources": [
{
"name": "longdependencyduration",
"type": "ProactiveDetectionConfigs",
"dependsOn": [
"[resourceId('Microsoft.Insights/components', 'myApplication')]"
],
"properties": {
"sendEmailsToSubscriptionOwners": true,
"customEmails": [],
"enabled": false
}
}
]
}
Deshabilitación del envío de notificaciones por correo electrónico para una regla de detección inteligente
{
"properties": {
},
"resources": [
{
"dependsOn": [
],
"properties": {
"sendEmailsToSubscriptionOwners": false,
"customEmails": [],
"enabled": true
}
}
]
}
Adición de otros destinatarios de correo electrónico para una regla de detección inteligente
{
"properties": {
},
"resources": [
{
"dependsOn": [
],
"properties": {
"sendEmailsToSubscriptionOwners": true,
"customEmails": ['alice@contoso.com', 'bob@contoso.com'],
"enabled": true
}
}
]
}
Nombres de regla de detección inteligente

Seguidamente se muestra una tabla de nombres de reglas de detección inteligente tal y como aparecen en el
portal, así como sus nombres internos, que deben utilizarse en la plantilla de Azure Resource Manager.
NOTE
Las reglas de detección inteligente marcadas como de versión preliminar no admiten notificaciones por correo electrónico.
Por lo tanto, solo se puede establecer la propiedad habilitada para estas reglas.
N O M B RE DE REGL A DE A Z URE P O RTA L N O M B RE IN T ERN O
Carga lenta de página slowpageloadtime
Lentitud en el tiempo de respuesta del servidor slowserverresponsetime
Duración de la dependencia prolongada longdependencyduration
Degradación del tiempo de respuesta del servidor degradationinserverresponsetime
Reducción de la duración de la dependencia degradationindependencyduration
Degradación en la relación de gravedad de seguimiento extension_traceseveritydetector

Aumento anormal del volumen de excepciones (versión extension_exceptionchangeextension

preliminar)
N O M B RE DE REGL A DE A Z URE P O RTA L N O M B RE IN T ERN O
Detección de una posible fuga de memoria (versión extension_memoryleakextension

preliminar)
Detección de un posible problema de seguridad (versión extension_securityextensionspackage

preliminar)
Aumento anómalo del volumen de datos diario (versión extension_billingdatavolumedailyspikeextension

preliminar)
Regla de alertas Anomalías de errores

Esta plantilla de Azure Resource Manager muestra la configuración de una regla de alertas de Anomalías en los
errores con una gravedad de 2. Esta versión nueva de la regla de alertas de Anomalías en los errores es parte de la
nueva plataforma de alertas de Azure y reemplaza la versión clásica que se retira como parte del proceso de
retirada de alertas clásicas.
NOTE
Las anomalías de errores son un servicio global, por lo que la ubicación de la regla se crea en la ubicación global.
{
"resources": [
{
"type": "microsoft.alertsmanagement/smartdetectoralertrules",
"apiVersion": "2019-03-01",
"name": "Failure Anomalies - my-app",
"properties": {
"description": "Failure Anomalies notifies you of an unusual rise in the rate of failed HTTP
requests or dependency calls.",
"state": "Enabled",
"severity": "2",
"frequency": "PT1M",
"detector": {
"id": "FailureAnomaliesDetector"
},
"scope": ["/subscriptions/00000000-1111-2222-3333-
444444444444/resourceGroups/MyResourceGroup/providers/microsoft.insights/components/my-app"],
"actionGroups": {
"groupIds": ["/subscriptions/00000000-1111-2222-3333-
444444444444/resourcegroups/MyResourceGroup/providers/microsoft.insights/actiongroups/MyActionGroup"]
}
}
}
]
}
NOTE
Esta plantilla de Azure Resource Manager es única para la regla de alertas de Anomalías en los errores y es distinta de las
otras reglas clásicas de detección inteligente que se describen en este artículo. Si desea administrar Anomalías en los errores
manualmente, esto se hace en Alertas de Azure Monitor, mientras que todas las demás reglas de detección inteligente se
administran en el panel Detección inteligente de la interfaz de usuario.
Pasos siguientes
Más información sobre la detección automática:
Anomalías de error
Fugas de memoria
Cambio de las notificaciones por correo electrónico
de detección inteligente
Según los comentarios de los clientes, el 1 de abril de 2019 vamos a cambiar los roles predeterminados de
quienes reciben notificaciones por correo electrónico de detección inteligente.
¿Qué está cambiando?

Actualmente, las notificaciones por correo electrónico de detección inteligente se envían de forma predeterminada
a los roles de propietario de la suscripción, colaborador de la suscripción y lector de la suscripción. Estos roles
suelen incluir usuarios que no participan activamente en la supervisión, lo que hace que muchos de estos usuarios
reciban notificaciones innecesariamente. Para mejorar esta experiencia, estamos haciendo un cambio para que las
notificaciones por correo electrónico solo vayan, de manera predeterminada, a los roles de lector de supervisión y
colaborador de supervisión.
Ámbito de este cambio

Este cambio afectará a todas las reglas de detección inteligente, excepto los siguientes:
Las reglas de detección inteligente marcadas como versión preliminar. Estas reglas de detección inteligente
no admiten notificaciones por correo electrónico en este momento.
Reglas de anomalías de error. Esta regla comenzará a dirigir a los nuevos roles predeterminados una vez
que se migre de una alerta clásica a la plataforma de alertas unificada (hay más información disponible
aquí).
¿Cómo prepararse para este cambio?

Para garantizar que las notificaciones por correo electrónico de detección inteligente se envíen a los usuarios
pertinentes, estos usuarios deben tener asignados los roles de lector de supervisión y colaborador de supervisión
de la suscripción.
Para asignar usuarios a los roles de lector de supervisión o de colaborador de supervisión mediante Azure Portal,
siga los pasos descritos en el artículo Adición de una asignación de roles. Asegúrese de seleccionar lector de
supervisión o colaborador de supervisión como el rol al que se asignan los usuarios.
NOTE
Los destinatarios específicos de las notificaciones de detección inteligente, configurados mediante la opción Destinatarios de
correo electrónico adicionales en la configuración de la regla, no se verán afectados por este cambio. Estos destinatarios
seguirá recibiendo las notificaciones por correo electrónico.
Si tiene alguna pregunta o duda acerca de este cambio, no dude en ponerse en contacto con nosotros.
Pasos siguientes
Más información sobre la detección inteligente:
Anomalías de error
Fugas de memoria
Análisis de uso con Application Insights
¿Qué características de la aplicación web o móvil son más populares? ¿Los usuarios logran sus objetivos con
la aplicación? ¿Salen de ella en momentos concretos y vuelven más tarde? Azure Application Insights le
ayudará a obtener información eficaz sobre el uso de la aplicación por parte de los usuarios. Cada vez que
actualice la aplicación, puede evaluar también si funciona bien para los usuarios. Con este conocimiento,
puede tomar decisiones basadas en datos sobre los ciclos de desarrollo siguientes.
Envío de telemetría desde la aplicación

La mejor experiencia se obtiene mediante la instalación de Application Insights en el código de servidor de
aplicaciones y en las páginas web. Los componentes de cliente y servidor de la aplicación devuelven
telemetría a Azure Portal para su análisis.
1. Código de ser vidor : instale el módulo adecuado para ASP.NET, Azure, Java, Node.js u otra
aplicación.
¿No desea instalar código del servidor? Simplemente cree un recurso de Azure Application
Insights.
2. Código de página web : Agregue el siguiente script en la página web antes de </head> de cierre.
Reemplace la clave de instrumentación por el valor apropiado para el recurso de Application Insights:
aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){t[e]=function(){var
n=arguments;t.queue.push(function(){t[e].apply(t,n)})}}var t={config:e};t.initialize=!0;var
i=document,a=window;setTimeout(function(){var
n=i.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",i.
getElementsByTagName("script")[0].parentNode.appendChild(n)});try{t.cookie=i.cookie}catch(e)
{}t.queue=[],t.version=2;for(var r=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;
)n("track"+r.pop());n("startTrackPage"),n("stopTrackPage");var
s="Track"+r[0];if(n("start"+s),n("stop"+s),n("setAuthenticatedUserContext"),n("clearAuthenticatedU
serContext"),n("flush"),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytic
s&&!0===e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+
(r="onerror"));var o=a[r];a[r]=function(e,n,i,a,s){var c=o&&o(e,n,i,a,s);return!0!==c&&t["_"+r]
({message:e,url:n,lineNumber:i,columnNumber:a,error:s}),c},e.autoExceptionInstrumented=!0}return
t}(
{
instrumentationKey:"INSTRUMENTATION_KEY"
}
);window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
Para conocer configuraciones más avanzadas para supervisar sitios web, consulte el artículo de
referencia del SDK de JavaScript.
3. Código de aplicación móvil : utilice el SDK de App Center para recopilar eventos de la aplicación y
después enviar copias de estos eventos a Application Insights para el análisis; para ello, siga esta guía.
4. Obtener telemetría : ejecute su proyecto en modo de depuración durante unos minutos y luego
busque resultados en la hoja de información general en Application Insights.
Publique su aplicación para supervisar el rendimiento de su aplicación y descubra lo que hacen sus
usuarios con ella.
Inclusión del identificador de usuario y de sesión en la telemetría

Para realizar un seguimiento de los usuarios a lo largo del tiempo, Application Insights necesita una manera
de identificarlos. La herramienta de eventos es la única herramienta de uso que no requiere un identificador
de usuario o de sesión.
Comience enviando identificadores de usuario y de sesión con este proceso.
Exploración de estadísticas y datos demográficos de uso

Descubra cuándo los usuarios utilizan la aplicación, en qué páginas que están más interesados, en qué
ubicación se encuentran dichos usuarios, y los sistemas operativos y exploradores que emplean.
Los informes Usuarios y sesiones filtran los datos por páginas o eventos personalizados, y los segmentan
por propiedades tales como la ubicación, el entorno y la página. También puede agregar sus propios filtros.
La información de la derecha señala patrones de interés en el conjunto de datos.

El informe Usuarios indica el número de usuarios únicos que tienen acceso a las páginas dentro de los
periodos seleccionados. Para las aplicaciones web, los usuarios se cuentan con cookies. Si alguien accede
a su sitio con distintos exploradores o máquinas cliente, o borra las cookies, se contabilizarán más de una
vez.
El informe Sesiones indica el número de sesiones de usuario que acceden al sitio. Una sesión es un
periodo de actividad por parte de un usuario, que finaliza con un periodo de inactividad de más de media
hora.
Más información sobre las herramientas Usuarios, Sesiones y Eventos
Retención : ¿cuántos usuarios regresan?

Retención lo ayudará a comprender la frecuencia con la que los usuarios vuelven a usar su aplicación, en
función de las cohortes de usuarios que realizan alguna acción empresarial durante un intervalo de tiempo
determinado.
Qué características específicas provocan que los usuarios vuelvan más veces que otras
Formular hipótesis basadas en datos de usuarios reales
Determinar si la retención es un problema del producto
Los controles de retención de la parte superior permiten definir eventos específicos y el intervalo de tiempo
para calcular la retención. El gráfico situado en la parte central proporciona una representación visual del
porcentaje total de retención por el intervalo de tiempo especificado. El gráfico de la parte inferior
representa la retención individual en un periodo determinado. Este nivel de detalle permite entender lo que
hacen los usuarios y qué podría afectar al regreso de los usuarios con una granularidad más detallada.
Más información de la herramienta Retención
Eventos de negocio personalizados

Para obtener una idea clara de lo que los usuarios hacen con la aplicación, es útil insertar líneas de código
para registrar los eventos personalizados. Estos eventos pueden realizar un seguimiento desde acciones del
usuario detalladas como hacer clic en botones específicos hasta eventos de negocio más importantes como
realizar una compra o ganar una partida.
Aunque, en algunos casos, las vistas de página pueden representar eventos útiles, en general, no es así. Un
usuario puede abrir una página de un producto sin necesidad de adquirirlo.
Con los eventos específicos del negocio, puede realizar un gráfico del progreso de los usuarios en su sitio.
Puede averiguar sus preferencias para diferentes opciones y en qué partes salen o tienen dificultades. Con
este conocimiento, puedan tomar decisiones fundamentadas en lo que respecta a las prioridades del trabajo
pendiente en materia de desarrollo.
Los eventos se pueden registrar del lado del cliente de la aplicación:
appInsights.trackEvent("ExpandDetailTab", {DetailTab: tabName});
O del lado del servidor:

var tc = new Microsoft.ApplicationInsights.TelemetryClient();
tc.TrackEvent("CreatedAccount", new Dictionary<string,string> {"AccountType":account.Type}, null);
...
tc.TrackEvent("AddedItemToCart", new Dictionary<string,string> {"Item":item.Name}, null);
...
tc.TrackEvent("CompletedPurchase");
Puede adjuntar los valores de propiedad a estos eventos, para que pueda filtrar o dividir los eventos al
examinarlos en el portal. Además, se adjunta un conjunto estándar de propiedades a cada evento, como el
identificador de usuario anónimo, lo que permite realizar un seguimiento de la secuencia de actividades de
un usuario individual.
Obtenga más información sobre los eventos personalizados y las propiedades.
Eventos de segmentación y desglose
En las herramientas Usuarios, Sesiones y Eventos, puede segmentar y desglosar los eventos personalizados
por usuario, nombre del evento y propiedades.
Diseño de la telemetría con la aplicación

Al diseñar cada característica de la aplicación, tenga en cuenta cómo va a medir su éxito con los usuarios.
Decida qué eventos empresariales necesita registrar y codifique las llamadas de seguimiento de esos
eventos en la aplicación desde el principio.
Prueba A | B
Si no conoce qué variante de una característica tendrá más éxito, publique ambas para que estén accesibles a
los diferentes usuarios. Mida el éxito de cada una y, a continuación, cambie a una versión unificada.
Para realizar esta técnica, adjunte valores de propiedad distintas a toda la telemetría que se envía con cada
versión de la aplicación. Puede hacerlo al definir las propiedades en el TelemetryContext activo. Estas
propiedades predeterminadas se agregan a cada mensaje de telemetría que envía la aplicación: no solo los
mensajes personalizados, sino también la telemetría estándar.
En el portal de Application Insights, podrá filtrar y dividir los datos en los valores de propiedad, con el fin de
comparar las distintas versiones.
Para ello, configure un inicializador de telemetría:
// Telemetry initializer class
{
public void Initialize(ITelemetry item)
{
var itemProperties = item as ISupportProperties;
if (itemProperties != null && !itemProperties.Properties.ContainsKey("AppVersion"))
{
itemProperties.Properties["AppVersion"] = "v2.1";
}
}
}
En el inicializador de la aplicación web, como Global.asax.cs:

{
// ...
TelemetryConfiguration.Active.TelemetryInitializers
.Add(new MyTelemetryInitializer());
}
Aplicaciones de ASP.NET Core
NOTE
La adición del inicializador mediante ApplicationInsights.config o TelemetryConfiguration.Active no es
válida para las aplicaciones de ASP.NET Core.
Para aplicaciones de ASP.NET Core, la adición de un nuevo elemento TelemetryInitializer se realiza

agregándolo al contenedor de inserción de dependencias, como se muestra a continuación. Esto se hace en
el método ConfigureServices de la clase Startup.cs .
{
}
Todos los nuevos clientes de telemetría agregan automáticamente el valor de propiedad especificado. La
telemetría individual puede invalidar los valores predeterminados.
Pasos siguientes
Embudos
Retención
Flujos de usuario
Libros
Adición de contexto de usuario
Enviar identificadores contextuales de usuario para
habilitar las experiencias de uso en Azure
Seguimiento de usuarios
Application Insights le permite supervisar y realizar un seguimiento de los usuarios a través de un conjunto de
herramientas de uso del producto:
Embudos
Cohortes de retención
Libros
Para realizar un seguimiento de lo que hace un usuario a lo largo del tiempo, Application Insights necesita un
identificador para cada usuario o sesión. Incluya los siguientes identificadores en cada evento personalizado o
vista de página.
Usuarios, embudos, retención y cohortes: incluya el identificador de usuario.
Sesiones: incluya el identificador de sesión.
NOTE
Este es un artículo avanzado que describe los pasos manuales para el seguimiento de la actividad del usuario con
Application Insights. Con muchas aplicaciones web es posible que estos pasos no sean necesarios , ya que los SDK
del servidor predeterminados junto con el SDK de JavaScript del lado cliente o explorador suelen ser suficientes para
realizar un seguimiento automático de la actividad del usuario. Si no ha configurado la supervisión de cliente además del
SDK del lado servidor, hágalo primero y pruébelo para ver si las herramientas de análisis de comportamiento de usuario se
ejecutan según lo esperado.
Elección de los identificadores de usuario

Los identificadores de usuario se deben conservar entre las sesiones de usuario para realizar un seguimiento de
cómo se comportan los usuarios con el tiempo. Hay varios enfoques para conservar el identificador.
Una definición de un usuario que ya tiene en su servicio.
Si el servicio tiene acceso a un explorador, puede pasar a este una cookie con un identificador en ella. El
identificador se conservará siempre que la cookie permanezca en el explorador del usuario.
Si es necesario, puede usar un nuevo identificador en cada sesión, pero los resultados sobre los usuarios
serán limitados. Por ejemplo, no podrá ver cómo cambia el comportamiento de un usuario con el tiempo.
El identificador debe ser un GUID u otra cadena lo suficientemente compleja como para identificar de forma
única a cada usuario. Por ejemplo, podría ser un número aleatorio largo.
Si el identificador contiene información de identificación personal sobre el usuario, no es un valor adecuado para
enviarlo a Application Insights como identificador de usuario. Puede enviar un identificador de ese tipo como
identificador de usuario autenticado, pero no cumplirá el requisito de identificador de usuario para los escenarios
de uso.
Aplicaciones ASP.NET: Establecimiento del contexto de usuario en un
inicializador de telemetría
Cree un inicializador de telemetría, tal como se describe aquí en detalle. Pase el id. de sesión a través de la
telemetría de solicitudes y establezca Context.User.Id y Context.Session.Id.
Este ejemplo establece el identificador de usuario en un identificador que expira después de la sesión. Si es
posible, use un identificador de usuario que se conserve entre sesiones.
Inicializador de telemetría
using System;
using System.Web;
namespace MvcWebRole.Telemetry
{
/*
* Custom TelemetryInitializer that sets the user ID.
*
*/
{
{
var ctx = HttpContext.Current;
// If telemetry initializer is called as part of request execution and not from some async thread
if (ctx != null)
{
var requestTelemetry = ctx.GetRequestTelemetry();
// Set the user and session ids from requestTelemetry.Context.User.Id, which is populated in
Application_PostAcquireRequestState in Global.asax.cs.
if (requestTelemetry != null && !string.IsNullOrEmpty(requestTelemetry.Context.User.Id) &&
(string.IsNullOrEmpty(telemetry.Context.User.Id) ||
string.IsNullOrEmpty(telemetry.Context.Session.Id)))
{
// Set the user id on the Application Insights telemetry item.
telemetry.Context.User.Id = requestTelemetry.Context.User.Id;
// Set the session id on the Application Insights telemetry item.

telemetry.Context.Session.Id = requestTelemetry.Context.User.Id;
}
}
}
}
}
Global.asax.cs
using System.Web;
using System.Web.Http;
using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
{
public class MvcApplication : HttpApplication
{
{
AreaRegistration.RegisterAllAreas();
GlobalConfiguration.Configure(WebApiConfig.Register);
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
}
protected void Application_PostAcquireRequestState()

{
var requestTelemetry = Context.GetRequestTelemetry();
if (HttpContext.Current.Session != null && requestTelemetry != null &&

string.IsNullOrEmpty(requestTelemetry.Context.User.Id))
{
requestTelemetry.Context.User.Id = Session.SessionID;
}
}
}
}
Pasos siguientes
Para habilitar las experiencias de uso, empiece por enviar eventos personalizados o vistas de páginas.
Si ya ha enviado eventos personalizados o vistas de página, explore las herramientas de uso para obtener
información sobre cómo los usuarios utilizan el servicio.
Información general del uso
Usuarios, sesiones y eventos
Embudos
Retención
Libros
Análisis de usuarios, sesiones y eventos en
Descubra cuándo utilizan los usuarios la aplicación web, en qué páginas están más interesados, en qué ubicación
se encuentran dichos usuarios, y los sistemas operativos y exploradores que emplean. Analice la telemetría de
uso y de negocio con Azure Application Insights.
Introducción
Si aún no ve los datos en las hojas de usuarios, sesiones o eventos de Application Insights, obtenga información
sobre cómo empezar a trabajar con las herramientas de uso.
La herramienta de segmentación de usuarios, sesiones y eventos

Tres de las hojas de uso usan la misma herramienta para segmentar y desglosar telemetría de su aplicación web
desde tres perspectivas. Mediante el filtrado y la división de los datos, puede descubrir información detallada
sobre el uso relativo de distintas páginas y características.
Herramienta Usuarios : averigüe cuántas personas usan la aplicación y sus características. Los usuarios
se cuentan mediante el uso de identificadores anónimos almacenados en las cookies del explorador. Una
sola persona que usa distintos exploradores o máquinas se contarán como más de un usuario.
Herramienta Sesiones : la cantidad de sesiones de actividad de usuario que han incluido determinadas
páginas y características de la aplicación. Una sesión se cuenta después de media hora de inactividad del
usuario o después de 24 horas de uso continuo.
Herramienta Eventos : la frecuencia con la que se usan ciertas páginas y características de la aplicación.
Una vista de página se cuenta cuando un explorador carga una página de la aplicación, siempre que se
haya instrumentado.
Un evento personalizado representa una repetición de algo que sucede en la aplicación, a menudo, una
interacción del usuario como un clic en el botón o la realización de alguna tarea. Inserte código en su
aplicación para generar eventos personalizados.
Consulta de determinados usuarios

Explore distintos grupos de usuarios mediante ajustando las opciones de consulta en la parte superior de la
herramienta Usuarios:
Mostrar: elija una cohorte de usuarios que se va a analizar.
Que usaron: elija eventos personalizados y vistas de página.
Durante: elija un intervalo de tiempo.
Por: elija cómo se desglosarán los datos, por un periodo u otra propiedad como un explorador o una ciudad.
Dividir por: elija una propiedad por la que dividir o segmentar los datos.
Agregar filtros: limite la consulta a determinados usuarios, sesiones o eventos en función de sus propiedades,
como un explorador o una ciudad.
Guardado e intercambio de informes

Puede guardar los informes de Usuarios, de forma privada (solo para usted) en la sección Mis informes, o bien
con todos aquellos que tengan acceso a este recurso de Application Insights en la sección Informes compartidos.
Para compartir un vínculo con un informe de usuarios, sesiones o eventos, haga clic en Recurso compar tido
en la barra de herramientas y, después, copie el vínculo.
Para compartir una copia de los datos de un informe de usuarios, sesiones o eventos, haga clic en Recurso
compar tido en la barra de herramientas y, después, en el icono Word para crear un documento de Word con
los datos. O bien, haga clic en el icono Word encima del gráfico principal.
Conozca a sus usuarios

La sección Meet your users (Conozca a sus usuarios) muestra información acerca de los cinco usuarios de
ejemplo coincidentes con la consulta actual. Al tener en cuenta y explorar los comportamientos de los usuarios,
además de los agregados, se puede proporcionar información sobre cómo se utiliza realmente la aplicación.
Pasos siguientes
Embudos
Retención
Flujos de usuario
Libros
Descubra cómo los clientes usan la aplicación con
los embudos de Application Insights.
Conocer la experiencia de los clientes es de suma importancia para su negocio. Si la aplicación implica varias
fases, debe saber si la mayoría de los clientes avanzan a través de todo el proceso, o si finalizan el proceso en
algún momento. La progresión a través de una serie de pasos en una aplicación web se conoce como embudo.
Puede usar los embudos de Azure Application Insights para obtener información sobre los usuarios y supervisar
las tasas de conversión detalladas.
Creación de un embudo
Antes de crear el embudo, decida la pregunta a la que quiere obtener respuesta. Por ejemplo, es posible que
desee saber cuántos usuarios están visualizando la página principal, viendo un perfil de cliente y creando un vale.
En este ejemplo, los propietarios de la compañía Fabrikam Fiber desean conocer el porcentaje de clientes que han
creado correctamente un vale de cliente.
Estos son los pasos que deben seguir para crear un embudo.
1. En la herramienta Embudos de Application Insights, seleccione Nuevo .
2. En el menú desplegable Inter valo de tiempo , seleccione Últimos 90 días . Seleccione Mis embudos o
Embudos compar tidos .
3. En la lista desplegable Paso 1 , seleccione Índice .
4. En la lista Paso 2 , seleccione Cliente .
5. En la lista Paso 3 , seleccione Crear .
6. Agregue un nombre para el embudo y seleccione Guardar .
En la siguiente captura de pantalla se muestra un ejemplo de tipo de datos que la herramienta Embudos genera.
Los propietarios de Fabrikam pueden ver que, durante los últimos 90 días, el 54,3 % de sus clientes que visitó la
página principal crearon un vale de cliente. También pueden ver que 2700 clientes consultaron el índice desde la
página principal. Esto podría indicar un problema de actualización.
Características de Embudos
La captura de pantalla anterior incluye cinco áreas resaltadas. Se trata de características de Embudos. En la lista
siguiente se ofrecen más detalles sobre cada área correspondiente de la captura de pantalla:
1. Si la aplicación está muestreada, se mostrará un banner de muestreo. Al seleccionar el banner, se abre un
panel contextual, en el que se explica cómo desactivar el muestreo.
2. Puede exportar el embudo a Power BI.
3. Seleccione un paso para ver más detalles a la derecha.
4. En el gráfico del historial de conversiones se muestran tasas de conversión de los últimos 90 días.
5. Acceda a la herramienta de los usuarios para comprenderlos mejor. Puede usar filtros en cada paso.
Pasos siguientes
Retención
Libros
Exportación a Power BI
Cohortes de Application Insights
Una cohorte es un conjuntos de usuarios, sesiones, eventos u operaciones que tienen algo en común. En Azure
Application Insights las cohortes se definen mediante una consulta de análisis. En los casos en que tiene que
analizar un conjunto específico de usuarios o eventos de forma repetida, las cohortes pueden proporcionarle una
mayor flexibilidad para expresar exactamente el conjunto que le interesa.
Cohortes frente a filtros básicos

Las cohortes se usan de manera similar a los filtros. Pero las definiciones de las cohortes se crean a partir de
consultas de análisis personalizadas, por lo que son mucho más adaptables y complejas. A diferencia de los filtros,
puede guardar las cohortes para que otros miembros del equipo puedan volver a usarlas.
Puede definir una cohorte de usuarios en la que todos hayan probado una nueva característica de una aplicación.
Puede guardar esta cohorte en un recurso de Application Insights. En el futuro, resultará sencillo analizar este
grupo de usuarios específicos guardado.
NOTE
Una vez creadas, las cohortes están disponibles en las herramientas Usuarios, Sesiones, Eventos y Flujos de usuario.
Ejemplo: Usuarios dedicados

El equipo define como usuario dedicado a cualquier persona que use la aplicación cinco o más veces en un mes
determinado. En esta sección, definirá una cohorte de estos usuarios dedicados.
1. Abra la herramienta de Cohortes.
2. Seleccione la pestaña Galería de plantillas . Verá una colección de plantillas para varias cohortes.
3. Seleccione Engaged Users – by Days Used (Usuarios dedicados: por días de uso).
Hay tres parámetros para esta cohorte:
Actividades , donde elige qué eventos y vistas de página contar como "uso".
Período , la definición de un mes.
UsedAtleastCustom , el número de veces que los usuarios necesitan usar algo de un período para
contar como usuario dedicado.
4. Cambie UsedAtleastCustom a 5+ días y deje Período con el valor predeterminado de 28 días.
Esta cohorte representa todos los identificadores de usuarios que se enviaron con cualquier vista de página
o evento personalizado en 5 días distintos en los últimos 28 días.
5. Seleccione Guardar .
TIP
Asigne un nombre a la cohorte, como "Usuarios dedicados (5 + días)". Guárdela en "Mis informes" o "Informes
compartidos" en función de si desea que otras personas con acceso a este recurso de Application Insights vean esta
cohorte.
6. Seleccione Back to Galler y (Volver a la galería).

¿Qué puede hacer con esta cohorte?
Abra la herramienta Users (Usuarios). En la lista desplegable Show (Mostrar), elija la cohorte que creó en Users
who belong to (Usuarios que pertenecen a).
La herramienta de usuarios se filtra ahora con esta cohorte de usuarios:
Hay varios aspectos importantes que se deben tener en cuenta:
No puede crear este conjunto a través de los filtros normales. La lógica de fecha es más avanzada.
Puede filtrar aún más esta cohorte con los filtros normales de la herramienta de usuarios. De ese modo, si bien
la cohorte se define en ventanas de 28 días, aún se puede ajustar el intervalo de tiempo en la herramienta de
usuario para que sea 30, 60 o 90 días.
Estos filtros admiten preguntas más sofisticadas que son imposibles de expresas mediante el generador de
consultas. Por ejemplo, las personas que estaban dedicadas en los últimos 28 días. ¿Cómo se han comportado esas
mismas personas durante los últimos 60 días?
Ejemplo: Cohorte de eventos

También puede hacer cohortes de eventos. En esta sección, definirá una cohorte de los eventos y las vistas de
página. Luego verá cómo usarlos desde las otras herramientas. Esta cohorte puede definir un conjunto de eventos
que su equipo considere de uso activo o un conjunto relacionado con una nueva característica específica.
1. Abra la herramienta de Cohortes.
2. Seleccione la pestaña Galería de plantillas . Verá una colección de plantillas para varias cohortes.
3. Seleccione Events Picker (Selector de eventos).
4. En la lista desplegable Actividades , seleccione los eventos que quiere incluir en la cohorte.
5. Guarde la cohorte y asígnele un nombre.
Ejemplo: usuarios activos en donde se modifica una consulta

Las dos cohortes anteriores se han definido mediante listas desplegables. Pero también se pueden definir las
cohortes con consultas de análisis para una flexibilidad total. Para ver cómo hacerlo, cree una cohorte de usuarios
del Reino Unido.
1. Abra la herramienta Cohortes, seleccione la pestaña Galería de plantillas y seleccione Cohor tes de
usuarios en blanco .
Hay tres opciones:
Una sección de texto Markdown donde se describe la cohorte en más detalle para otros usuarios del
equipo.
Una sección de parámetros, donde crea sus propios parámetros, como Actividades y otras listas
desplegables de los dos ejemplos anteriores.
Una sección de consulta que se usa para definir la cohorte con una consulta de análisis.
En la sección de la consulta, escriba una consulta de análisis. La consulta selecciona el conjunto
específico de filas que describen la cohorte que desee definir. La herramienta Cohortes agrega
implícitamente una cláusula "| Resumir por identificador de usuario" a la consulta. Se muestra una
vista previa de estos datos debajo de la consulta en una tabla para que se asegure de que la consulta
devuelve resultados.
NOTE
Si no ve la consulta, pruebe a cambiar el tamaño de la sección para hacerla más alta y mostrar la consulta. En
el .gif animado al principio de esta sección se muestra el comportamiento de cambio de tamaño.
2. Copie y pegue el texto siguiente en el editor de consultas:
union customEvents, pageViews

| where client_CountryOrRegion == "United Kingdom"
3. Seleccione Ejecutar consulta . Si no ve identificadores de usuarios en la tabla, cambie a un país o región

donde haya usuarios de la aplicación.
4. Guarde y dele un nombre a la cohorte.

He definido una cohorte de usuarios de un determinado país o región. Cuando comparo esta cohorte en la
herramienta Usuarios con simplemente establecer un filtro en ese país o región, veo resultados diferentes. ¿Por
qué?
Las cohortes y los filtros son diferentes. Suponga que tiene una cohorte de usuarios del Reino Unido (definida
como el ejemplo anterior) y compara sus resultados con configurar el filtro "Country or region = United Kingdom"
(País o región = Reino Unido).
La versión de cohorte muestra todos los eventos de los usuarios que enviaron uno o varios eventos desde el
Reino Unido en el intervalo de tiempo actual. Si se divide según el país o región, probablemente vea muchos
países y regiones.
La versión de filtros solo muestra los eventos del Reino Unido. Pero si se divide según el país o región, solo verá
el Reino Unido.
Más información
Lenguaje de consulta de Analytics
Flujos de usuario
Análisis de impacto con Application Insights
La herramienta Impacto analiza cómo influyen los tiempos de carga y otras propiedades en las tasas de conversión
para las distintas partes de su aplicación. Para ser más exactos, detecta cómo cualquier dimensión de una vista
de página , evento personalizado o solicitud afecta el uso de una diferente vista de página o evento
personalizado .
¿Sigue sin tener claro la función de la herramienta Impacto?

La herramienta Impacto puede considerarse la herramienta por excelencia para establecer argumentos con alguien
de su equipo acerca de cómo la lentitud de algún aspecto de su sitio está afectando a que los usuarios no se
queden. Aunque los usuarios pueden tolerar una cierta lentitud, la herramienta Impacto proporciona una visión
general de la mejor manera de equilibrar la optimización y el rendimiento para maximizar la conversión de
usuario.
Pero analizar el rendimiento es solo un subconjunto de las capacidades de Impacto. Dado que la herramienta
Impacto es compatible con dimensiones y eventos personalizados, la respuesta a preguntas acerca de cómo afecta
la elección de explorador del usuario con las distintas tasas de conversión está a tan solo unos clics.
NOTE
El recurso de Application Insights debe contener vistas de páginas o eventos personalizados para poder utilizar la
herramienta Impacto. Aprenda a configurar la aplicación para que recopile vistas de página automáticamente con el SDK de
JavaScript de Application Insights. También es importante tener en cuenta que, puesto que va a analizar correlaciones, el
tamaño del ejemplo importa.
¿El tiempo de carga de página está afectando a cuánta gente se

convierte en mi página?
Para empezar a responder a preguntas con la herramienta Impacto, elija una vista de página inicial, un evento
personalizado o una solicitud.
1. Seleccione una vista de página en la lista desplegable For the page view (Para la vista de página).
2. Deje la lista desplegable analyze how its (Analizar su) en la selección predeterminada de Duración (en este
contexto Duración es un alias para Tiempo de carga de la página .)
3. Para la lista desplegable afecta al uso de , seleccione un evento personalizado. Este evento debe corresponder
a un elemento de la interfaz de usuario en la vista de página que seleccionó en el paso 1.
En esta instancia, a medida que aumenta el tiempo de carga de Página del producto disminuye las veces que se
hizo clic en Adquirir producto . Según la distribución anterior, puede conseguirse que una duración de carga de
página óptima de 3,5 segundos alcance una tasa de conversión de un 55 %. Otras mejoras de rendimiento para
reducir el tiempo de carga por debajo de 3,5 segundos no se correlacionan actualmente con ventajas de
conversión adicionales.
¿Qué ocurre si sigo las vistas de página y los tiempos de carga de
manera personalizada?
Impacto admite propiedades y medidas personalizadas y estándar, así que puede usar lo que prefiera. En lugar de
duración, use filtros en los eventos principales y secundarios para obtener datos más específicos.
¿Las tasas de conversión de los usuarios varían en función de los países

o regiones?
1. Seleccione una vista de página en la lista desplegable For the page view (Para la vista de página).
2. Elija "País o región" en la lista desplegable analyze how its (Analizar su).
3. En la lista desplegable afecta el uso de , seleccione un evento personalizado que corresponda a un elemento
de la interfaz de usuario en la vista de página que eligió en el paso 1.
En este caso, los resultados ya no se ajustan en un modelo de eje x continuo como lo hacían en el primer ejemplo.
En su lugar, se presenta una visualización similar a un embudo segmentado. Ordenar por Uso para ver la variación
de conversión para el evento personalizado basándose en el país o región.
¿Cómo calcula la herramienta Impacto la tasa de conversión?

En segundo plano, la herramienta Impacto se basa en el coeficiente de correlación de Pearson. Los resultados se
calculan entre -1 y 1, donde -1 representa una correlación lineal negativa y 1 representa una correlación lineal
positiva.
El análisis básico de cómo funciona Análisis de impacto es el siguiente:
A = la vista de página/evento personalizado/solicitud principal que seleccionó en la primera lista desplegable.
(Para la vista de página ).
B = la vista de página/evento personalizado secundario que seleccionó (afecta al uso de ).
Impacto examina una muestra de todas las sesiones de los usuarios en el intervalo de tiempo seleccionado. Para
cada sesión, busca cada aparición de A.
A continuación las sesiones se dividen en dos tipos diferentes de subsesiones basándose en una de estas dos
condiciones:
Una subsesión convertida se compone de una sesión que termina con un evento B y abarca todos los eventos A
que se producen antes B.
Se produce un subsesión no convertida cuando todos los eventos A ocurren sin un terminal B.
La manera en la que se calcula el impacto varía en función de si estamos realizando el análisis por métricas o
dimensiones. En el caso de las métricas, se calcula un promedio de todos los eventos _A_en una subsesión se
promedian. Mientras que para las dimensiones, el valor de cada A contribuye 1/N al valor asignado a B donde N es
el número de eventos _A_en la subsesión.
Pasos siguientes
Embudos
Retención
Flujos de usuario
Libros
Análisis de retención de usuarios para aplicaciones
web con Application Insights
La característica Retención de Azure Application Insights le ayuda a analizar cuántos usuarios regresan a la
aplicación, y con qué frecuencia realizan determinadas tareas o logran objetivos. Por ejemplo, si ejecuta un sitio
de juegos, puede comparar el número de usuarios que regresan al sitio después de perder una partida con la
cantidad que vuelven tras ganar. Esta información puede ayudarlo a mejorar la experiencia de los usuarios y la
estrategia empresarial.
Introducción
Si aún no ve los datos en la herramienta Retención del portal de Application Insights, obtenga información sobre
cómo empezar a trabajar con las herramientas de uso.
La herramienta Retención
1. La barra de herramientas permite a los usuarios crear nuevos informes de retención, abrir los informes ya
existentes, guardar el informe de retención actual (o guardarlo mediante la opción Guardar como), revertir
los cambios efectuados en los informes guardados, actualizar los datos del informe, compartir un informe
por correo electrónico o vínculo directo y acceder a la página de documentación.
2. De forma predeterminada, la herramienta de retención muestra todos los usuarios que hicieron algo y que ,
posteriormente, regresaron e hicieron algo más a lo largo de un período. Puede seleccionar una combinación
diferente de eventos para centrar el enfoque en las actividades específicas del usuario.
3. Agregue uno o varios filtros en las propiedades. Por ejemplo, puede centrarse en los usuarios de un país o
una región determinados. Haga clic en Actualizar después de establecer los filtros.
4. El gráfico de retención general muestra un resumen de la retención del usuario durante un período de
tiempo seleccionado.
5. La cuadrícula muestra el número de usuarios retenidos según el generador de consultas en 2. Cada fila
representa una cohorte de usuarios que llevó a cabo cualquier evento en el periodo mostrado. Cada celda de
la fila muestra cuántos de esa cohorte regresaron al menos una vez en un periodo posterior. Algunos
usuarios pueden regresar en más de un periodo.
6. Las tarjetas de información muestran los cinco eventos de inicio más importantes y los cinco eventos
devueltos principales para proporcionar a los usuarios una mejor comprensión de su informe de retención.
Los usuarios pueden mantener el puntero sobre las celdas de la herramienta Retención para acceder al botón de
análisis y a la información que explica lo que significa cada celda. El botón Análisis conduce al usuario a la
herramienta Análisis con una consulta rellenada previamente para generar usuarios desde la celda.
Uso de eventos empresariales para realizar un seguimiento de la

retención
Para obtener el análisis de retención más útil, mida los eventos que representan actividades empresariales
importantes.
Por ejemplo, muchos usuarios podrían abrir una página de la aplicación sin jugar al juego que se muestra. Al
realizar solo el seguimiento de las vistas de página, se proporcionaría una estimación inexacta de cuántas
personas vuelven a reproducir el juego después de haberlo jugado anteriormente. Para obtener una visión clara
de los jugadores que regresan, la aplicación debe enviar un evento personalizado cuando un usuario juega
realmente.
Se recomienda codificar los eventos personalizados que representan las acciones clave del negocio y usarlos
para realizar el análisis de retención. Para obtener el resultado del juego, tiene que escribir una línea de código
con el fin enviar un evento personalizado a Application Insights. Si se escribe en el código de la página web o en
Node.JS, se vería similar a esto:
appinsights.trackEvent("won game");
O en el código del servidor ASP.NET:
telemetry.TrackEvent("won game");
Obtenga más información sobre la creación de eventos personalizados.
Pasos siguientes
Embudos
Flujos de usuario
Libros
Análisis de patrones de navegación del usuario
mediante Flujos de usuarios de Application Insights
La herramienta Flujos de usuarios permite visualizar cómo navegan los usuarios por las páginas y características
del sitio. Resulta idónea para responder a preguntas del tipo:
¿Cómo salen los usuarios de una página del sitio?
¿En qué hacen clic los usuarios en una página del sitio?
¿Dónde están los lugares que los usuarios abandonan con más frecuencia en su sitio?
¿Hay lugares donde los usuarios repitan la misma acción una y otra vez?
La herramienta Flujos de usuario se inicia a partir de una vista de página inicial, un evento personalizado o una
excepción que especifique. En función de este evento inicial, Flujos de usuario muestra los eventos que se
produjeron antes y después durante las sesiones de usuario. Aparecen líneas de varios grosores que muestran
cuántas veces han seguido cada ruta los usuarios. Los nodos especiales de Inicio de la sesión muestran dónde
iniciaron una sesión los nodos posteriores. Los nodos de Fin de la sesión muestran cuántos usuarios no
enviaron vistas de páginas ni eventos personalizados después del nodo anterior, destacando los momentos en
los que los usuarios abandonaron probablemente su sitio.
NOTE
El recurso de Application Insights debe contener vistas de página o eventos personalizados para poder utilizar la
herramienta Flujos de usuarios. Aprenda a configurar la aplicación para que recopile vistas de página automáticamente
con el SDK de JavaScript de Application Insights.
Elección de un evento inicial

Para empezar a responder a las preguntas con la herramienta Flujos de usuario, elija una vista de página inicial,
un evento personalizado o una excepción que sirva como punto de partida de la visualización:
1. Haga clic en el vínculo del título ¿Qué hacen los usuarios después de...? o haga clic en el botón Editar .
2. Seleccione una vista de página, un evento personalizado o una excepción en la lista desplegable Evento
inicial .
3. Haga clic en Crear gráfico .
La columna "Paso 1" de la visualización muestra lo que los usuarios hicieron con más frecuencia justo después
del evento inicial, ordenado de arriba a abajo de más a menos frecuente. El "Paso 2" y las columnas siguientes
muestran lo que los usuarios hicieron a partir de ahí, creando una imagen con todas las maneras en que los
usuarios navegaron por el sitio.
De forma predeterminada, la herramienta Flujos de usuarios muestrea de forma aleatoria solo las últimas 24
horas de vistas de página y eventos personalizados del sitio. Puede aumentar el intervalo de tiempo y cambiar el
equilibrio de rendimiento y precisión para el muestreo aleatorio en el menú Edición.
Si algunas de las vistas de página, eventos personalizados y excepciones no son pertinentes, haga clic en la X en
los nodos que desea ocultar. Una vez que haya seleccionado los nodos que desea ocultar, haga clic en el botón
Crear gráfico situado debajo de la visualización. Para ver todos los nodos que ha ocultado, haga clic en el
botón Editar y mire la sección Eventos excluidos .
Si faltan vistas de página o eventos personalizados que esperaba ver en la visualización:
Compruebe la sección Eventos excluidos en el menú Editar .
Utilice los botones de signo más en Otros nodos para incluir eventos menos frecuentes en la visualización.
Si los usuarios envían con poca frecuencia la vista de página o evento personalizado que espera, pruebe a
aumentar el intervalo de tiempo de la visualización en el menú Editar .
Asegúrese de que la vista de página, evento personalizado o excepción están configurados correctamente
para su recopilación mediante el SDK de Application Insights en el código fuente del sitio. Obtenga más
información sobre la recopilación de eventos personalizados.
Si desea ver más pasos en la visualización, use las listas desplegables Pasos anteriores y Pasos siguientes
encima de la visualización.
Después de visitar una página o una característica, ¿a dónde van los

usuarios y dónde hacen clic?
Si el evento inicial es una vista de página, la primera columna ("Paso 1") de la visualización es una forma rápida
de ver lo que hicieron los usuarios inmediatamente después de visitar la página. Intente abrir el sitio en una
ventana que esté junto a la visualización de Flujos de usuarios. Compare sus expectativas de cómo los usuarios
interactúan con la página, con la lista de eventos de la columna "Paso 1". A menudo, hay veces en las que un
elemento de la interfaz de usuario de la página, que le parece insignificante a su equipo, puede estar entre los
elementos más usados de la página. Puede ser un buen punto inicial para realizar mejoras en el diseño del sitio.
Si el evento inicial es un evento personalizado, la primera columna muestra lo que los usuarios hicieron justo
después de realizar esa acción. Al igual que con las vistas de página, vea si el comportamiento que se ha
observado en los usuarios se corresponde con las expectativas y objetivos del equipo. Por ejemplo, si el evento
inicial seleccionado es "Elemento agregado al carro de la compra", mire a ver si aparecen poco después "Ir a
Finalizar la compra" y "Compra terminada" en la visualización. Si el comportamiento del usuario es diferente de
lo esperado, use la visualización para entender si los usuarios se sienten "atraídos" por el diseño actual de su
sitio.
¿Dónde están los lugares que los usuarios abandonan con más
frecuencia en su sitio?
Observe los nodos de Fin de la sesión que aparecen en la parte de arriba de una columna de la visualización,
especialmente al principio de un flujo. Esto significa que muchos usuarios probablemente abandonaron su sitio
después de seguir la ruta de acceso anterior de páginas e interacciones de la interfaz de usuario. En algunas
ocasiones, aunque el abandono es previsible, como, por ejemplo, después de completar una compra en un sitio
de comercio electrónico, este suele ser indicativo de problemas de diseño, bajo rendimiento u otras cuestiones
mejorables.
Tenga en cuenta que los nodos Fin de la sesión se basan únicamente en la telemetría recopilada por este
recurso de Application Insights. Aunque Application Insights no reciba datos de telemetría de ciertas
interacciones de usuario, los usuarios pueden haber seguido interactuando con el sitio de esas maneras después
de que la herramienta Flujos de usuarios indicase que la sesión había finalizado.
¿Hay lugares donde los usuarios repitan la misma acción una y otra
vez?
Busque una vista de página o un evento personalizado que repitan muchos usuarios en los pasos subsiguientes
de la visualización. Normalmente, esto significa que los usuarios están realizando acciones repetitivas en su sitio.
Si observa mucha repetición, para reducirla, considere la posibilidad de cambiar el diseño de su sitio o agregar
nuevas funcionalidades. Por ejemplo, agregue la funcionalidad de edición en masa si observa que los usuarios
realizan acciones repetitivas en cada fila de un elemento de tabla.
Preguntas frecuentes
¿Representa el evento inicial la primera vez que aparece el evento en una sesión, o las veces posteriores?
El evento inicial de la visualización solo representa la primera vez que un usuario envía esa vista de página o
evento personalizado durante una sesión. Si los usuarios pueden enviar el evento inicial varias veces en una
sesión, la columna "Paso 1" solo muestra el comportamiento de los usuarios después de la primera instancia del
evento inicial, no de todas las instancias.
Algunos de los nodos en mi visualización son demasiado genéricos. Por ejemplo, un nodo que solo indica
"Clic en Button". ¿Cómo se puede dividir en nodos más detallados?
Use las opciones de Dividir por en el menú Editar :
1. Elija el evento que desea dividir en el menú Eventos .
2. Elija una dimensión en el menú Dimensión . Por ejemplo, si tiene un evento denominado "Clic en Button",
pruebe una propiedad personalizada denominada "Button Name".
Pasos siguientes
Retención
Incorporación de eventos personalizados a la aplicación
Solución de problemas de las herramientas de análisis
de comportamiento de usuario en Application
Insights
¿Tiene alguna pregunta sobre las herramientas de análisis de comportamiento de usuario en Application Insights:
usuarios, sesiones, eventos, embudos, flujos de usuario, retención o cohortes? Estas son algunas respuestas.
Recuento de usuarios
Las herramientas de análisis de compor tamiento de usuario muestran que mi aplicación tiene una
sesión y un usuario, pero sé que tiene varios usuarios y sesiones. ¿Cómo se solucionan estos
recuentos incorrectos?
Todos los eventos de telemetría de Application Insights tienen un identificador de usuario anónimo y un
identificador de sesión como parte de las propiedades estándares. De forma predeterminada, todas las
herramientas de análisis de uso de recuento de usuarios y sesiones se basan en estos identificadores. Si estas
propiedades estándares no se rellenan con identificadores únicos para cada usuario y sesión de la aplicación, verá
un recuento incorrecto de usuarios y sesiones en las herramientas de análisis de uso.
Si supervisa una aplicación web, la solución más sencilla consiste en agregar el SDK de JavaScript de Application
Insights a la aplicación y asegurarse de que el fragmento de código de script se carga en todas las páginas que
desee supervisar. El SDK de JavaScript genera identificadores de usuario y sesión automáticamente y rellena los
eventos de telemetría con ellos según se van enviando desde la aplicación.
Si supervisa un servicio web (sin interfaz de usuario), cree un inicializador de telemetría que rellene las
propiedades de los identificadores de usuario anónimo y sesión según las nociones de su servicio sobre los
usuarios únicos y las sesiones.
Si la aplicación envía identificadores de usuarios autenticados, con la herramienta Usuarios puede realizar el
recuento en función de estos. En la lista desplegable "Mostrar", seleccione "Usuarios autenticados".
Actualmente, las herramientas de análisis de comportamiento de usuario no admiten el recuento de usuarios o
sesiones en función de propiedades distintas del identificador de usuario anónimo, el identificador de usuario
autenticado o el identificador de sesión.
Nomenclatura de los eventos

Mi aplicación tiene miles de vistas de página y nombres de eventos personalizados distintos. Resulta
difícil distinguirlos y las herramientas de análisis de compor tamiento de usuario dejan de responder
con frecuencia. ¿Cómo se solucionan estos problemas de nomenclatura?
Las herramientas de análisis de comportamiento de usuario utilizan las vistas de página y los nombres de los
eventos personalizados. La correcta nomenclatura de los eventos es fundamental para sacarles partido a estas
herramientas. El objetivo es un equilibrio entre un número reducido de nombres demasiado genéricos ("Se hizo clic
en el botón") y un número excesivo de nombres demasiado específicos ("Se hizo clic en el botón Editar de
http://www.contoso.com/index").
Para realizar cambios en las vistas de página y los nombres de evento personalizados que envía la aplicación, debe
cambiar el código fuente de la aplicación y volver a realizar la implementación. Todos los datos de telemetría
de Application Insights se almacenan durante 90 días y no se pueden eliminar , por lo que los cambios
realizados en los nombres de evento tardarán 90 días en manifestarse totalmente. Durante los 90 días después de
los cambios en el nombre, en la telemetría aparecen tanto los nuevos nombres como los antiguos, por lo que es
necesario ajustar las consultas y comunicarse con los equipos en consecuencia.
Si la aplicación envía demasiados nombres de vista de página, compruebe si estos se especifican manualmente en
el código o si los envía automáticamente el SDK de JavaScript de Application Insights:
Si se especifican manualmente en el código mediante trackPageView API, cambie el nombre a uno menos
específico. Evite los errores comunes, como colocar la dirección URL en el nombre de la vista de página. En
su lugar, use el parámetro de dirección URL de trackPageView API. Mueva los demás detalles del nombre de
la vista de página a propiedades personalizadas.
Si el SDK de JavaScript de Application Insights envía los nombres de vista de página automáticamente,
puede cambiar los títulos de las páginas o enviar los nombres de vista de página manualmente. De forma
predeterminada, el SDK envía el título de cada página como nombre de la vista de página. Puede cambiar los
títulos a otros más generales, pero tenga en cuenta la optimización del motor de búsqueda y otros efectos
que este cambio podría tener. Especificar manualmente los nombres de vista de página con trackPageView
API invalida los nombres recopilados automáticamente, por lo que podría enviar nombres más generales a
la telemetría sin cambiar los títulos de página.
Si la aplicación envía demasiados nombres de evento personalizados, cambie los nombres en el código a otros
menos específicos. Una vez más, evite colocar direcciones URL y otros datos de página o dinámicos directamente
en los nombres de evento personalizados. En su lugar, mueva estos detalles a las propiedades personalizadas del
evento personalizado con trackEvent API. Por ejemplo, en lugar de
appInsights.trackEvent("Edit button clicked on http://www.contoso.com/index") , sugerimos algo parecido a
appInsights.trackEvent("Edit button clicked", { "Source URL": "http://www.contoso.com/index" }) .
Pasos siguientes
Introducción a las herramientas de análisis de comportamiento de usuario
Obtener ayuda
Stack Overflow
Anotaciones sobre gráficos de métricas en
Las anotaciones muestran dónde ha implementado una nueva compilación u otros eventos importantes. Las
anotaciones permiten ver fácilmente si los cambios tuvieron algún efecto en el rendimiento de la aplicación. Se
pueden crear automáticamente con el sistema de compilación de Azure Pipelines. También puede crear
anotaciones para marcar los eventos que prefiera si los crea desde PowerShell.
Anotaciones de la versión con una compilación de Azure Pipelines

Las anotaciones de la versión son una característica del servicio Azure Pipelines basado en la nube de Azure
DevOps.
Instalación de la extensión Anotaciones (una vez)
Para poder crear anotaciones de la versión, debe instalar una de las muchas extensiones de Azure DevOps
disponibles en Visual Studio Marketplace.
1. Inicie sesión en su proyecto de Azure DevOps.
2. En la página de extensión de anotaciones de la versión de Visual Studio Marketplace, seleccione su
organización de Azure DevOps y, a continuación, seleccione Instalar para agregar la extensión a la
organización de Azure DevOps.
Solo deberá instalar la extensión una vez para su organización de Azure DevOps. Las anotaciones de la versión se
pueden configurar ahora para cualquier proyecto de su organización.
Configurar anotaciones de versión
Cree una clave de API independiente para cada una de las plantillas de versión de Azure Pipelines.
1. Inicie sesión en Azure Portal y abra el recurso de Application Insights que supervisa su aplicación. Si no tiene
uno, cree un nuevo recurso de Application Insights.
2. Abra la pestaña Acceso de API y copie el Id. de Application Insights .
3. En una ventana del explorador independiente, abra o cree la plantilla de versión que administra sus
implementaciones de Azure Pipelines.
4. Seleccione Agregar tarea y, a continuación, seleccione la tarea Anotación de versión de Application
Insights en el menú.
NOTE
Actualmente, la tarea Anotación de versión solo admite agentes basados en Windows; no se ejecuta en Linux, macOS
ni otros tipos de agentes.
5. En Id. de aplicación , pegue el identificador de Application Insights que copió de la pestaña Acceso de
API .
6. De vuelta en la ventana Acceso de API de Application Insights, seleccione Crear clave de API .
7. En la ventana Crear clave de API , escriba una descripción, seleccione Escribir anotaciones y, a
continuación, seleccione Generar clave . Copie la clave nueva.
8. En la ventana de la plantilla de versión, en la pestaña Variables , seleccione Agregar para crear una
definición de variable para la nueva clave de API.
9. En Nombre , escriba ApiKey y, en Valor , pegue la clave de API que copió en la pestaña Acceso de API .
10. Seleccione Guardar en la ventana de la plantilla de versión principal para guardar la plantilla.
NOTE
Los límites de las claves de API se describen en la documentación de los límites de frecuencia de la API de REST.
Ver anotaciones
NOTE
Las anotaciones de versión no están disponibles actualmente en el panel de métricas de Application Insights
Ahora, cuando utilice la plantilla de versión para implementar una nueva versión, se enviará una anotación a
Application Insights. Las anotaciones se pueden ver en las siguientes ubicaciones:
El panel de uso, donde también puede crear anotaciones de versión manualmente:
En cualquier consulta de libro basada en registros en la que la visualización muestre el tiempo a lo largo del eje x.
Para habilitar anotaciones en el libro, vaya a Configuración avanzada y seleccione Mostrar anotaciones .
Seleccione un marcador de anotación para abrir los detalles de la versión, incluidos el solicitante, la rama de
control de código fuente, la canalización de la versión y el entorno.
Crear anotaciones personalizadas desde PowerShell

Puede usar el script de PowerShell CreateReleaseAnnotation de GitHub para crear anotaciones desde cualquier
proceso que desee, sin usar Azure DevOps.
1. Realice una copia local de CreateReleaseAnnotation.ps1.
2. Use los pasos del procedimiento anterior para obtener el identificador de Application Insights y crear una
clave de API desde la pestaña Acceso de API de Application Insights.
3. Llame al script de PowerShell con el código siguiente, reemplazando los marcadores de posición entre
corchetes angulares por sus valores. Los valores de -releaseProperties son opcionales.
.\CreateReleaseAnnotation.ps1 `
-applicationId "<applicationId>" `
-apiKey "<apiKey>" `
-releaseName "<releaseName>" `
-releaseProperties @{
"ReleaseDescription"="<a description>";
"TriggerBy"="<Your name>" }
El script se puede modificar (por ejemplo, para crear anotaciones para el pasado).
Pasos siguientes
Crear elementos de trabajo
Automation con PowerShell
Incorporación de supervisión continua a la
canalización de versión
Azure Pipelines se integra con Azure Application Insights para permitir la supervisión continua de la canalización
de versión de DevOps a lo largo del ciclo de vida de desarrollo del software.
Con la supervisión continua, las canalizaciones de versión pueden incorporar datos de supervisión de Application
Insights y otros recursos de Azure. Cuando la canalización de versión detecta una alerta de Application Insights,
puede canalizar o revertir la implementación hasta que se resuelva la alerta. Si todas las comprobaciones son
correctas, las implementaciones pueden continuar automáticamente de prueba a producción sin necesidad de
intervención manual.
Configuración de la supervisión continua

1. En Azure DevOps seleccione una organización y un proyecto.
2. En el menú de la izquierda de la página del proyecto,seleccione Canalizaciones > Versiones .
3. Baje la flecha situada junto a Nuevo y seleccione Nueva canalización de versión . O bien, si aún no tiene
una canalización, seleccione Nueva canalización en la página que aparece.
4. En el panel Seleccionar una plantilla , busque y seleccione Implementación de Azure App Ser vice
con super visión continua y Aplicar .
5. En el cuadro Fase 1 , seleccione el hipervínculo a Ver tareas de la fase .

6. En el panel de configuración de la Fase 1 , rellene estos campos:
Nombre de la fase Proporcione un nombre de fase o déjelo como Fase 1 .
Suscripción de Azure Desplácese hacia abajo y seleccione la suscripción de

Azure vinculada que desea usar.
Tipo de aplicación Desplácese hacia abajo y seleccione el tipo de aplicación.
Nombre de App Ser vice Escriba el nombre de la instancia de Azure App Service.
Nombre de grupo de recursos para Application Seleccione el grupo de recursos que quiera usar de la lista
Insights desplegable.
Nombre de recurso de Application Insights Seleccione de la lista desplegable el recurso de Application

Insights para el grupo de recursos que seleccionó.
7. Para guardar la canalización con la configuración de la regla de alertas predeterminada, seleccione

Guardar en la esquina superior derecha de la ventana de Azure DevOps. Escriba un comentario descriptivo
y seleccione Aceptar .
Modificación de las reglas de alertas

La plantilla Implementación de Azure App Ser vice con super visión continua tiene cuatro reglas de alerta
listas para usar: Disponibilidad , Solicitudes con errores , Tiempo de respuesta del ser vidor y
Excepciones de ser vidor . Puede agregar más reglas o cambiar la configuración de estas para satisfacer sus
necesidades de nivel de servicio.
Para modificar la configuración de las reglas de alertas:
En el panel izquierdo de la página canalización de versión, seleccione Configure Application Insights Aler ts
(Configurar alertas de Application Insights).
Las cuatro reglas de alerta predeterminadas se crean mediante un script en línea:
$subscription = az account show --query

"id";$subscription.Trim("`"");$resource="/subscriptions/$subscription/resourcegroups/"+"$(Parameters.AppInsigh
tsResourceGroupName)"+"/providers/microsoft.insights/components/" +
"$(Parameters.ApplicationInsightsResourceName)";
az monitor metrics alert create -n 'Availability_$(Release.DefinitionName)' -g
$(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'avg
availabilityResults/availabilityPercentage < 99' --description "created from Azure DevOps";
az monitor metrics alert create -n 'FailedRequests_$(Release.DefinitionName)' -g
$(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'count requests/failed > 5' --
description "created from Azure DevOps";
az monitor metrics alert create -n 'ServerResponseTime_$(Release.DefinitionName)' -g
$(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'avg requests/duration > 5' --
az monitor metrics alert create -n 'ServerExceptions_$(Release.DefinitionName)' -g
$(Parameters.AppInsightsResourceGroupName) --scopes $resource --condition 'count exceptions/server > 5' --
Puede modificar el script y agregar reglas de alerta adicionales, modificar las condiciones de alerta o quitar reglas
de alerta que no tengan sentido para los fines de su implementación.
Incorporación de condiciones de implementación
Al agregar puertas de implementación a la canalización de versión, una alerta que supera los umbrales
establecidos evita la promoción de versiones no deseadas. Una vez resuelta la alerta, la implementación puede
continuar automáticamente.
Para agregar puertas de implementación:
1. En la página principal de la canalización, en Fases , seleccione el icono Condiciones anteriores a la
implementación o Condiciones posteriores a la implementación en función de la fase donde se
necesite una puerta de supervisión continua.
2. En el panel de configuración Condiciones anteriores a la implementación , establezca Puer tas en

Habilitadas .
3. Junto a Validaciones de la implementación , seleccione Agregar .
4. Seleccione Consultar las aler tas de Azure Monitor en el menú desplegable. Esta opción permite
acceder a las alertas de Azure Monitor y de Application Insights.
5. En Opciones de evaluación , escriba los valores que desee configurar, como El tiempo entre la
reevaluación de las validaciones y El tiempo de espera tras el cual se produce un error de las
validaciones .
Visualización de los registros de versión

En los registros de versión se puede ver el comportamiento de la puerta de implementación y otros pasos de la
versión. Para abrir los registros:
1. Seleccione Versiones en el menú de la izquierda de la página Canalización.
2. Seleccione cualquier versión.
3. En fases , seleccione cualquier fase para ver un resumen de la versión.
4. Para ver los registros, seleccione Ver registros en el resumen de la versión y el hipervínculo Correcto o
Erróneo en cualquier fase, o mantenga el mouse sobre una fase y seleccione Registros .
Pasos siguientes
Para más información sobre Azure pipelines, consulte la documentación de Azure Pipelines.
Recursos, roles y control de acceso en Application
Insights
Puede controlar quién tiene acceso de lectura y actualización a los datos en Azure Application Insightsmediante el
uso del control de acceso basado en roles (RBAC de Azure) de Azure.
IMPORTANT
Asigne acceso a los usuarios para el grupo de recursos o la suscripción a los que pertenece el recurso de aplicación,
no para el propio recurso. Asigne el rol de colaborador de componentes de Application Insights . De esta forma, se
garantiza el control de acceso uniforme a las alertas y las pruebas web junto con su recurso de aplicación. Más información.
NOTE
Recursos, grupos y suscripciones

En primer lugar, vamos a ver algunas definiciones:
Recurso : una instancia de un servicio de Microsoft Azure. El recurso de Application Insights recopila,
analiza y muestra los datos de telemetría enviados desde su aplicación. Otros tipos de recursos de Azure
son aplicaciones web, bases de datos y máquinas virtuales.
Para ver todos los recursos, abra Azure Portal, inicie sesión y haga clic en Todos los recursos. Para buscar
un recurso, escriba parte del nombre en el campo de filtro.
Grupo de recursos : cada recurso pertenece a un solo grupo. Un grupo es una forma cómoda de
administrar los recursos relacionados, especialmente de cara al control de acceso. Por ejemplo, en un
grupo de recursos podría colocar una aplicación web, un recurso de Application Insights para supervisar la
aplicación y un recurso de almacenamiento para mantener los datos exportados.
Suscripción : para usar Application Insights u otros recursos de Azure, inicie sesión en una suscripción de
Azure. Cada grupo de recursos pertenece a una suscripción de Azure, donde elije su paquete de precios y,
si se trata de una suscripción de la organización, selecciona los miembros y sus permisos de acceso.
Cuenta de Microsoft : el nombre de usuario y la contraseña que usa para iniciar sesión en suscripciones
de Microsoft Azure, XBox Live, Outlook.com y otros servicios de Microsoft.
Control de acceso para el grupo de recursos

Es importante comprender que, además del recurso que ha creado para su aplicación, también hay recursos
ocultos independientes para las alertas y las pruebas web. Estos están conectados al mismo grupo de recursos
que el recurso de Application Insights. También podría haber colocado ahí otros servicios de Azure, como sitios
web o almacenamiento.
Para proporcionar acceso a otro usuario, siga estos pasos:

Debe tener derechos de propietario a la suscripción o al grupo de recursos.
El usuario debe tener una cuenta de Microsoft o acceder a su cuenta Microsoft de la organización. Puede
proporcionar acceso individual y también a grupos de usuarios definidos en Active Directory de Azure.
Vaya al grupo de recursos o directamente al recurso mismo.
Elija Control de acceso (IAM) en el menú de la izquierda.
Seleccione Agregar asignación de roles .
La vista Agregar permisos a continuación es principalmente específica a los recursos de Application Insights, si
estuviera viendo los permisos de control de acceso de un nivel superior, como grupos de recursos, vería que roles
adicionales no centrados en Application Insights.
Para ver la información sobre todos los roles integrados de control de acceso basado en rol de Azure, use el
contenido de referencia oficial.
Seleccione un rol.
Cuando corresponda, tendrá un vínculo a la documentación de referencia oficial asociada.
RO L E EN EL GRUP O DE REC URSO S:
Propietario Puede cambiar cualquier cosa, incluido el acceso de usuario.
Colaborador Puede editar cualquier cosa, incluidos todos los recursos.
Colaborador de componentes de Application Insights Puede editar recursos de Application Insights.
Lector Puede ver, pero no puede cambiar nada.

RO L E EN EL GRUP O DE REC URSO S:
Depurador de instantáneas de Application Insights Concede permiso al usuario para usar las características de
Application Insights Snapshot Debugger. Tenga en cuenta que
este rol no se incluye en los roles de propietario ni
colaborador.
Colaborador para la administración de versiones de Rol de colaborador para servicios que se implementan a
implementación de servicios de Azure través de implementación de servicios de Azure.
Purgador de datos Rol especial para purgar datos personales. Para más
información, consulte nuestros guía para datos personales.
Administrador de ExpressRoute Puede crear, eliminar y administrar rutas rápidas.
Colaborador de Log Analytics Un colaborador de Log Analytics puede leer todos los datos
de supervisión y editar la configuración de supervisión. La
edición de la configuración de supervisión incluye la
posibilidad de añadir la extensión de máquina virtual a las
máquinas virtuales, leer las claves de las cuentas de
almacenamiento para poder configurar la recopilación de
registros de Azure Storage, crear y configurar cuentas de
Automation, añadir soluciones y configurar Azure Diagnostics
en todos los recursos de Azure.
Lector de Log Analytics Un lector de Log Analytics puede ver y buscar todos los
datos de supervisión, así como consultar la configuración de
supervisión, incluida la de Azure Diagnostics en todos los
recursos de Azure.
masterreader Permite a un usuario ver todo el contenido, pero no realizar

cambios.
Colaborador de supervisión Puede leer todos los datos de supervisión y actualizar la

configuración de esta.
Supervisión del publicador de métricas Permite publicar las métricas de los recursos de Azure.
Lector de supervisión Puede leer todos los datos de supervisión.
Colaborador de la directiva de recursos (versión preliminar) Los usuarios repuestos de EA, con derechos para crear o
modificar la directiva de recursos, crean incidencias de
soporte técnico y leen los recursos o la jerarquía.
Administrador de acceso de usuario Permite a un usuario administrar el acceso de otros usuarios

a los recursos de Azure.
Colaborador de sitio web Permite administrar los sitios web (no planes web), pero no
acceder a ellos.
La "edición" incluye la creación, la eliminación y la actualización:

Recursos
Pruebas web
Alertas
Seleccione el usuario.
Si el usuario de su elección no está en el directorio, puede invitar a cualquier persona con una cuenta Microsoft.
(Si se usan servicios como Outlook.com, OneDrive, Windows Phone o XBox Live, se tiene una cuenta Microsoft).
Contenido relacionado
Control de acceso basado en roles de Azure (Azure RBAC)
Consulta de PowerShell para determinar la pertenencia a roles

Como algunos roles pueden vincularse a notificaciones y alertas de correo electrónico, puede resultar útil poder
generar una lista de los usuarios que pertenecen a un determinado rol. Para ayudar con la generación de estos
tipos de listas, le ofrecemos las siguientes consultas de ejemplo, que puede adaptar a sus necesidades específicas:
Suscripción completa a consultas para roles de administradores y roles de colaborador
(Get-AzRoleAssignment -IncludeClassicAdministrators | Where-Object {$_.RoleDefinitionName -in

@('ServiceAdministrator', 'CoAdministrator', 'Owner', 'Contributor') } | Select -ExpandProperty SignInName |
Sort-Object -Unique) -Join ", "
Consulta en el contexto de un recurso específico de Application Insights para propietarios y colaboradores
$resourceGroup = "RGNAME"
$resourceName = "AppInsightsName"
$resourceType = "microsoft.insights/components"
(Get-AzRoleAssignment -ResourceGroup $resourceGroup -ResourceType $resourceType -ResourceName $resourceName |
Where-Object {$_.RoleDefinitionName -in @('Owner', 'Contributor') } | Select -ExpandProperty SignInName |
Sort-Object -Unique) -Join ", "
Consulta en el contexto de un grupo de recursos específico para propietarios y colaboradores
$resourceGroup = "RGNAME"
(Get-AzRoleAssignment -ResourceGroup $resourceGroup | Where-Object {$_.RoleDefinitionName -in @('Owner',
'Contributor') } | Select -ExpandProperty SignInName | Sort-Object -Unique) -Join ", "
Administración de la ubicación geográfica y la
dirección IP
En este artículo se explica cómo realizar la búsqueda de geolocalización y la administración de direcciones IP en

Application Insights, además de cómo modificar el comportamiento predeterminado.
Comportamiento predeterminado
De forma predeterminada, las direcciones IP se recopilan temporalmente, pero no se almacenan en Application
Insights. El proceso básico es el siguiente:
Las direcciones IP se envían a Application Insights como parte de los datos de telemetría. Al llegar al punto de
conexión de ingesta en Azure, la dirección IP se usa para realizar una búsqueda de geolocalización mediante
GeoLite2 de MaxMind. Los resultados de esta búsqueda se usan para completar los campos client_City ,
client_StateOrProvince , client_CountryOrRegion . En este punto, la dirección IP se descarta y 0.0.0.0 se escribe
en el campo client_IP .
Telemetría del explorador: recopilamos temporalmente la dirección IP del remitente. La dirección IP se calcula
mediante el punto de conexión de ingesta.
Telemetría del servidor: el módulo de Application Insights recopila temporalmente la dirección IP del cliente.
No se recopila si X-Forwarded-For está establecido.
Este comportamiento es así de forma predeterminada, ya que le ayudará a evitar la recopilación innecesaria de
datos personales. Siempre que sea posible, se recomienda evitar la recopilación de datos personales.
Invalidar el comportamiento predeterminado

Aunque el comportamiento predeterminado debe minimizar la recopilación de datos personales, todavía
ofrecemos la opción para recopilar y almacenar datos de direcciones IP. Antes de decidir si quiere almacenar
datos personales como direcciones IP, le recomendamos que compruebe que esta acción no infrinja los
requisitos de cumplimiento o la normativa local a los que pueda estar sujeto. Para obtener más información
sobre la administración de datos personales en Application Insights, consulte la guía de datos personales.
Almacenamiento de datos de direcciones IP

Para habilitar la recopilación y el almacenamiento de direcciones IP, la propiedad DisableIpMasking del
componente de Application Insights debe establecerse en true . Esta propiedad se puede establecer a través de
las plantillas de Azure Resource Manager o llamando a la API de REST.
Plantilla de Azure Resource Manager
{
"id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-
name>/providers/microsoft.insights/components/<resource-name>",
"name": "<resource-name>",
"location": "westcentralus",
"tags": {
},
"kind": "web",
"properties": {
"Application_Type": "web",
"Request_Source": "IbizaAIExtension",
// ...
"DisableIpMasking": true
}
}
Portal
Si solo necesita modificar el comportamiento de un solo recurso de Application Insights, la forma más fácil de
lograrlo es a través de Azure Portal.
1. Vaya al recurso de Application Insights > Configuración > Expor tar plantilla .
2. Seleccione Implementar .
3. Seleccione Editar plantilla . (Si su plantilla tiene propiedades o recursos adicionales que no aparecen en
esta plantilla de ejemplo, proceda con precaución para asegurarse de que todos los recursos acepten la
implementación de la plantilla como un cambio o actualización incremental).
4. Realice los siguientes cambios en el archivo JSON del recurso y haga clic en Guardar :
WARNING
Si experimenta un error que dice: El grupo de recursos está en una ubicación que no es compatible con
uno o varios recursos de la plantilla. Elija otro grupo de recursos. Seleccione temporalmente otro grupo
de recursos en la lista desplegable y, a continuación, vuelva a seleccionar el grupo de recursos original para
resolver el error.
5. Seleccione Acepto > Comprar .
En este caso no se compra nada nuevo, simplemente estamos actualizando la configuración del recurso
de Application Insights existente.
6. Una vez completada la implementación, se registrarán los nuevos datos de telemetría.
Si tuviera que seleccionar y editar la plantilla nuevamente, solo vería la plantilla predeterminada y no la
propiedad recién agregada y su valor asociado. Si no ve los datos de la dirección IP y quiere confirmar
que "DisableIpMasking": true está configurado. Ejecute el siguiente código de PowerShell: (Reemplace
Fabrikam-dev con el recurso apropiado y el nombre del grupo de recursos).
# If you aren't using the cloud shell you will need to connect to your Azure account
# Connect-AzAccount
$AppInsights = Get-AzResource -Name 'Fabrikam-dev' -ResourceType 'microsoft.insights/components' -
ResourceGroupName 'Fabrikam-dev'
$AppInsights.Properties
Como resultado, se devolverá una lista de propiedades. Una de las propiedades debe ser
DisableIpMasking: true . Si ejecuta PowerShell antes de implementar la nueva propiedad con Azure
Resource Manager, la propiedad no existirá.
API de REST
La carga útil de la API de Rest para realizar las mismas modificaciones es la siguiente:
PATCH https://management.azure.com/subscriptions/<sub-id>/resourceGroups/<rg-
name>/providers/microsoft.insights/components/<resource-name>?api-version=2018-05-01-preview HTTP/1.1
Host: management.azure.com
Authorization: AUTH_TOKEN
Content-Type: application/json
Content-Length: 54
{
"location": "<resource location>",
"kind": "web",
"properties": {
"Application_Type": "web",
"DisableIpMasking": true
}
}
Inicializador de telemetría
Si necesita una alternativa más flexible que DisableIpMasking para registrar todo o parte de las direcciones IP,
puede usar un inicializador de telemetría para copiar todo o parte de la dirección IP en un campo personalizado.
ASP.NET/ASP.NET Core
namespace MyWebApp
{
public class CloneIPAddress : ITelemetryInitializer
{
{
ISupportProperties propTelemetry = telemetry as ISupportProperties;
if (propTelemetry !=null && !propTelemetry.Properties.ContainsKey("client-ip"))

{
string clientIPValue = telemetry.Context.Location.Ip;
propTelemetry.Properties.Add("client-ip", clientIPValue);
}
}
}
}
NOTE
Si no puede acceder a ISupportProperties , asegúrese de que ejecuta la versión estable más reciente del SDK de
Application Insights. ISupportProperties están pensadas para valores de cardinalidad alta, mientras que
GlobalProperties son más adecuadas para valores de cardinalidad baja, como el nombre de la región, el nombre del
entorno, etc.
Habilitar el inicializador de telemetría para .ASP.NET

namespace MyWebApp
{
public class MvcApplication : System.Web.HttpApplication
{
{
//Enable your telemetry initializer:
TelemetryConfiguration.Active.TelemetryInitializers.Add(new CloneIPAddress());
}
}
}
Habilitar el inicializador de telemetría para ASP.NET Core

Puede crear su inicializador de telemetría de la misma manera en ASP.NET Core y en ASP.NET, pero para habilitar
el inicializador, use el siguiente ejemplo como referencia:
{
services.AddSingleton<ITelemetryInitializer, CloneIPAddress>();
}
Node.js
appInsights.defaultClient.addTelemetryProcessor((envelope) => {
const baseData = envelope.data.baseData;
if (appInsights.Contracts.domainSupportsProperties(baseData)) {
const ipAddress = envelope.tags[appInsights.defaultClient.context.keys.locationIp];
if (ipAddress) {
baseData.properties["client-ip"] = ipAddress;
}
}
});
JavaScript del lado cliente

A diferencia de los SDK del lado del servidor, el SDK de Javascript del lado cliente no calcula la dirección IP. De
forma predeterminada, el cálculo de la dirección IP para la telemetría del lado cliente se realiza en el punto de
conexión de ingesta de Azure al llegar la telemetría. Esto significa que si envía datos del lado cliente a un proxy y
luego los reenvía al punto de conexión de ingesta, el cálculo de la dirección IP puede mostrar la dirección IP del
proxy y no del cliente. Si no se usa un proxy, esto no debería ser un problema.
Si quiere calcular la dirección IP directamente en el lado cliente, necesitará agregar su propia lógica
personalizada para realizar este cálculo y usar el resultado para establecer la etiqueta ai.location.ip . Cuando
se establece ai.location.ip , el punto de conexión de ingesta no realiza el cálculo de la dirección IP, y la
dirección IP proporcionada se respeta y se usa para realizar la búsqueda geográfica. En este caso, la dirección IP
seguirá estableciéndose en cero de forma predeterminada.
Para retener la dirección IP completa calculada a partir de su lógica personalizada, puede usar un inicializador de
telemetría que copie los datos de la dirección IP que proporcionó en ai.location.ip en un campo
personalizado separado. Pero, de nuevo, a diferencia de los SDK del lado servidor, sin depender de bibliotecas de
terceros o de su propia lógica de recopilación de IP del lado cliente, el SDK del lado cliente no calculará la IP.
appInsights.addTelemetryInitializer((item) => {
const ipAddress = item.tags && item.tags["ai.location.ip"];
if (ipAddress) {
item.baseData.properties = {
...item.baseData.properties,
"client-ip": ipAddress
};
}
});
Ver los resultados del inicializador de telemetría

Si a continuación desencadena un nuevo proceso de tráfico en su sitio y espera aproximadamente de 2 a 5
minutos para asegurarse de que haya tiempo para la ingesta, puede ejecutar una consulta de Kusto para ver si la
recopilación de direcciones IP funciona:
requests
| project appName, operation_Name, url, resultCode, client_IP, customDimensions.["client-ip"]
Las direcciones IP recién recopiladas deben aparecer en la columna customDimensions_client-ip . La columna

predeterminada client-ip todavía tendrá los 4 octetos establecidos en cero o solo mostrará los primeros tres
octetos, dependiendo de cómo haya configurado la recopilación de direcciones IP en el nivel de componente. Si
está realizando pruebas de forma local después de implementar el inicializador de telemetría y el valor que ve
para customDimensions_client-ip es ::1 , este es el comportamiento esperado. ::1 representa la dirección de
bucle invertido en IPv6. Es equivalente a 127.0.01 en IPv4 y es el resultado que verá cuando realice pruebas
desde localhost.
Pasos siguientes
Obtenga más información sobre la recopilación de datos personales en Application Insights.
Obtenga más información sobre cómo funciona la recopilación de direcciones IP en Application Insights.
(Esta es una publicación de blog externa anterior que escribió uno de nuestros ingenieros. Es anterior al
comportamiento predeterminado actual donde la dirección IP se registra como 0.0.0.0 , pero se
profundiza en la mecánica del elemento ClientIpHeaderTelemetryInitializer integrado).
Muestreo en Application Insights.
El muestreo es una característica de Azure Application Insights. Se trata de la manera

recomendada de reducir el tráfico de telemetría, los costos de datos y los costos de
almacenamiento conservando, al mismo tiempo, un análisis estadísticamente correcto de los
datos de las aplicaciones. El muestreo también le ayuda a evitar que Application Insights
limite los datos de telemetría. El filtro de muestreo selecciona los elementos relacionados
para que pueda desplazarse entre los elementos cuando realiza investigaciones de
diagnóstico.
Cuando los recuentos de métrica se presentan en el portal, se vuelven a normalizar para
tener en cuenta el muestreo. De este modo, se minimizan los efectos en las estadísticas.
Resumen breve
Hay tres tipos diferentes de muestreo: muestreo adaptable, muestreo de frecuencia fija y
muestreo de ingesta.
El muestreo adaptable está habilitado de manera predeterminada en todas las versiones
más recientes de los kits de desarrollo de software (SDK) de Application Insights para
ASP.NET y ASP.NET Core. También lo usa Azure Functions.
El muestreo de frecuencia fija está disponible en las versiones recientes de los SDK de
Application Insights para ASP.NET, ASP.NET Core, Java (tanto el agente como el SDK) y
Python.
El muestreo de ingesta funciona en el punto de conexión de servicio de Application
Insights. Solo se aplica cuando no hay ningún otro muestreo en vigor. Si el SDK muestrea
los datos de telemetría, el muestreo de ingesta está deshabilitado.
Para aplicaciones web, si registra eventos personalizados y necesita asegurarse de que un
conjunto de eventos se conserva o descarta en conjunto, los eventos deben tener el
mismo valor de OperationId .
Si escribe consultas de Analytics, debería tener en cuenta el muestreo. En concreto, en
lugar de simplemente contar registros, debería usar summarize sum(itemCount) .
Algunos tipos de telemetría, incluidas las métricas de rendimiento y las métricas
personalizadas, siempre se conservan independientemente de si el muestreo está
habilitado o no.
En la tabla siguiente se resumen los tipos de muestreo disponibles para cada SDK y tipo de
aplicación:
SE A DM IT E EL SE A DM IT E EL SE A DM IT E EL
SDK DE A P P L IC AT IO N M UEST REO M UEST REO DE M UEST REO DE
IN SIGH T S A DA P TA B L E F REC UEN C IA F IJA IN GESTA
ASP.NET Sí (activado de forma Sí Solo si no hay otro

predeterminada) muestreo en vigor
ASP.NET Core Sí (activado de forma Sí Solo si no hay otro

SE A DM IT E EL SE A DM IT E EL SE A DM IT E EL
SDK DE A P P L IC AT IO N M UEST REO M UEST REO DE M UEST REO DE
IN SIGH T S A DA P TA B L E F REC UEN C IA F IJA IN GESTA
Azure Functions Sí (activado de forma No Solo si no hay otro

Java No Sí Solo si no hay otro

muestreo en vigor
Node.JS No Sí Solo si no hay otro

muestreo en vigor
Python No Sí Solo si no hay otro

muestreo en vigor
Todos los demás No No Sí
NOTE
La información de la mayor parte de esta página se aplica a las versiones actuales de los SDK de
Application Insights. Para obtener información sobre las versiones anteriores de los SDK, consulte la
sección siguiente.
Tipos de muestreo
Hay tres métodos de muestreo diferentes:
El muestreo adaptable ajusta automáticamente el volumen de telemetría que se
envía desde el SDK en la aplicación de ASP.NET/ASP.NET Core y desde Azure
Functions. Este es el muestreo predeterminado cuando se usa el SDK de ASP.NET o
ASP.NET Core. Actualmente, el muestreo adaptable solo está disponible para la
telemetría del lado servidor de ASP.NET y para Azure Functions.
El muestreo de frecuencia fija reduce el volumen de telemetría que se envía desde
el servidor ASP.NET, ASP.NET Core o Java y desde los exploradores de los usuarios. El
usuario establece la frecuencia. El cliente y el servidor sincronizarán su muestreo por
lo que, en Búsqueda, puede desplazarse entre las solicitudes y las vistas de página
relacionadas.
El muestreo de ingesta se produce en el punto de conexión de servicio de
Application Insights. Lo que hace es descartar algunos de los datos de telemetría que
llegan desde su aplicación según la frecuencia de muestreo establecida. Aunque no
reduce el tráfico de telemetría enviado desde su aplicación, le ayuda a mantenerse
dentro de su cuota mensual. La principal ventaja del muestreo de ingesta es que
puede establecer la frecuencia de muestreo sin volver a implementar la aplicación. El
muestreo de ingesta funciona uniformemente para todos los servidores y clientes,
pero no se aplica cuando están en funcionamiento otros tipos de muestreo.
IMPORTANT
Si los métodos de muestreo adaptable o de frecuencia fija están en funcionamiento, el muestreo de
ingesta se deshabilita.
muestreo adaptable
Influye en el volumen de telemetría enviado desde su aplicación de servidor web hasta el
punto de conexión del servicio de Application Insights.
TIP
El muestreo adaptable está habilitado de forma predeterminada cuando se usa el SDK de ASP.NET o
el SDK de ASP.NET Core y también está habilitado de forma predeterminada para Azure Functions.
El volumen se ajusta automáticamente para mantenerse dentro de una frecuencia máxima

especificada de tráfico y se controla mediante el valor MaxTelemetryItemsPerSecond . Si la
aplicación genera una cantidad baja de telemetría, como al depurar o debido a un uso bajo,
el procesador de muestreo no podrá descargar los elementos mientras el volumen se
encuentre por debajo de MaxTelemetryItemsPerSecond . A medida que aumenta el volumen de
telemetría, la frecuencia de muestreo se ajusta para lograr el volumen objetivo. El ajuste se
actualiza a intervalos regulares y se basa en una media móvil de la velocidad de transmisión
de salida.
Para lograr el volumen objetivo, se descartan algunos de los datos de telemetría generados.
Pero, al igual que otros tipos de muestreo, el algoritmo conserva los elementos de
telemetría relacionados. Por ejemplo, cuando se inspeccione la telemetría en Búsqueda,
podrá buscar la solicitud relacionada con una excepción determinada.
Los recuentos de métrica, como la tasa de solicitudes y la tasa de excepciones, se ajustan
para compensar la frecuencia de muestreo, de modo que exhiban valores aproximadamente
correctos en el Explorador de métricas.
Configuración del muestreo adaptable para aplicaciones de ASP.NET
NOTE
Esta sección se aplica a las aplicaciones de ASP.NET, no a las aplicaciones de ASP.NET Core. Obtenga
información sobre cómo configurar el muestreo adaptable para aplicaciones de ASP.NET Core más
adelante en este documento.
En ApplicationInsights.config, puede ajustar varios parámetros en el nodo

AdaptiveSamplingTelemetryProcessor . Las cifras que se muestran son los valores
predeterminados:
<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
La velocidad de destino de las operaciones lógicas que el algoritmo adaptativo

pretende recopilar en cada host de ser vidor . Si la aplicación web se ejecuta en
varios hosts, reduzca este valor para que se mantenga dentro de la velocidad objetivo
de tráfico en el portal de Application Insights.
<EvaluationInterval>00:00:15</EvaluationInterval>
Intervalo en el que se vuelve a evaluar la velocidad actual de telemetría. La evaluación

se realiza como una media móvil. Se recomienda acortar este intervalo si la
telemetría experimenta ráfagas repentinas.
<SamplingPercentageDecreaseTimeout>00:02:00</SamplingPercentageDecreaseTimeout>
Cuando se cambia el valor del porcentaje de muestreo, ¿qué tiempo mínimo se tarda
en permitir de nuevo que se reduzca el porcentaje de muestreo para capturar menos
datos?
<SamplingPercentageIncreaseTimeout>00:15:00</SamplingPercentageIncreaseTimeout>
Cuando se cambia el valor del porcentaje de muestreo, ¿qué tiempo mínimo se tarda
en permitir de nuevo que se aumente el porcentaje de muestreo para capturar más
datos?
<MinSamplingPercentage>0.1</MinSamplingPercentage>
A medida que el porcentaje de muestreo varía, ¿cuál es el valor mínimo que se

permite establecer?
<MaxSamplingPercentage>100.0</MaxSamplingPercentage>
A medida que el porcentaje de muestreo varía, ¿cuál es el valor máximo que se

permite establecer?
<MovingAverageRatio>0.25</MovingAverageRatio>
En el cálculo de la media móvil, especifica el peso que se debería asignar al valor más
reciente. Use un valor igual o menor que 1. Los valores menores hacen que el
algoritmo reaccione con menor agilidad a los cambios repentinos.
<InitialSamplingPercentage>100</InitialSamplingPercentage>
Cantidad de datos de telemetría que se muestra cuando se acaba de iniciar la

aplicación. No reduzca este valor durante la depuración.
<ExcludedTypes>Trace;Exception</ExcludedTypes>
Una lista delimitada por puntos y coma de tipos que no desea que estén sujetos a
muestreo. Los tipos reconocidos son: Dependency , Event , Exception , PageView ,
Request y Trace . Se transmiten todos los datos de telemetría de los tipos
especificados; los tipos no especificados se muestrean.
<IncludedTypes>Request;Dependency</IncludedTypes>
Una lista delimitada por puntos y coma de tipos que desea que estén sujetos a
muestreo. Los tipos reconocidos son: Dependency , Event , Exception , PageView ,
Request y Trace . Los tipos especificados se muestrean, todos los datos de
telemetría del resto de tipos siempre se transmitirán.
Para desactivar el muestreo adaptable, elimine los nodos
AdaptiveSamplingTelemetryProcessor de ApplicationInsights.config .
Alternativa: Configuración del muestreo adaptable en el código

En lugar de establecer el parámetro de muestreo en el archivo .config , puede establecer
estos valores mediante programación.
1. Elimine todos los nodos AdaptiveSamplingTelemetryProcessor del archivo .config .
2. Use el siguiente fragmento de código para configurar el muestreo adaptable:
using Microsoft.ApplicationInsights.WindowsServer.Channel.Implementation;
// ...
var builder =
TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder
;
// For older versions of the Application Insights SDK, use the following line
instead:
// var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;
// Enable AdaptiveSampling so as to keep overall telemetry volume to 5 items per

second.
builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5);
// If you have other telemetry processors:

builder.Use((next) => new AnotherProcessor(next));
builder.Build();
(Más información sobre los procesadores de telemetría).

También puede ajustar la frecuencia de muestreo para cada tipo de telemetría
individualmente o incluso puede excluir determinados tipos del muestreo:
// The following configures adaptive sampling with 5 items per second, and also excludes
Dependency telemetry from being subjected to sampling.
builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5, excludedTypes: "Dependency");
Configuración del muestreo adaptable para aplicaciones de ASP.NET Core

No hay ningún objeto ApplicationInsights.config para aplicaciones de ASP.NET Core, por lo
que todas las configuraciones se realizan mediante código. El muestreo adaptable está
habilitado de forma predeterminada para todas las aplicaciones de ASP.NET Core. Puede
deshabilitar o personalizar el comportamiento de muestreo.
Desactivación del muestreo adaptable
La característica de muestreo predeterminada se puede deshabilitar al agregar el servicio de
Application Insights, en el método ConfigureServices , con
ApplicationInsightsServiceOptions dentro del archivo Startup.cs :

{
// ...
var aiOptions = new

Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOptions();
//...
}
El código anterior deshabilitará el muestreo adaptable. Siga los pasos a continuación para
agregar el muestreo con más opciones de personalización.
Configuración de las opciones de muestreo
Use los métodos de extensión de TelemetryProcessorChainBuilder como se muestra a
continuación para personalizar el comportamiento de muestreo.
IMPORTANT
Si usa este método para configurar el muestreo, asegúrese de establecer la propiedad
aiOptions.EnableAdaptiveSampling en false al llamar a
AddApplicationInsightsTelemetry() .
using Microsoft.ApplicationInsights.Extensibility
public void Configure(IApplicationBuilder app, IHostingEnvironment env,

TelemetryConfiguration configuration)
{
var builder = configuration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
instead:
// var builder = configuration.TelemetryProcessorChainBuilder;
// Using adaptive sampling

builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5);
// Alternately, the following configures adaptive sampling with 5 items per second,
and also excludes DependencyTelemetry from being subject to sampling.
// builder.UseAdaptiveSampling(maxTelemetryItemsPerSecond:5, excludedTypes:
"Dependency");

builder.Build();
// ...
}
Configuración del muestreo adaptable para Azure Functions

Siga las instrucciones de esta página para configurar el muestreo adaptable para las
aplicaciones que se ejecutan en Azure Functions.
Muestreo de frecuencia fija

El muestreo de frecuencia fija reduce el tráfico enviado desde el servidor web y los
exploradores web. A diferencia del muestreo adaptable, reduce la telemetría a una tasa fija
que usted decide. El muestreo de frecuencia fija está disponible para las aplicaciones de
ASP.NET, ASP.NET Core, Java y Python.
Al igual que otras técnicas de muestreo, esto también conserva elementos relacionados.
También sincroniza el muestreo del cliente y del servidor para que los elementos
relacionados se conserven; por ejemplo, cuando mira una vista de página en Búsqueda,
puede encontrar sus solicitudes de servidor relacionadas.
En el Explorador de métricas, las tasas, como los recuentos de solicitudes y de excepciones,
se multiplican por un factor para compensar la frecuencia de muestreo, de forma que sean
aproximadamente correctas.
Configuración del muestreo de frecuencia fija para aplicaciones de ASP.NET
1. Deshabilite el muestreo adaptable : En ApplicationInsights.config , elimine o
marque como comentario el nodo AdaptiveSamplingTelemetryProcessor .

2. Habilite el módulo de muestreo de frecuencia fija. Agregue este fragmento de

código a ApplicationInsights.config :
<Add
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTeleme
tryProcessor, Microsoft.AI.ServerTelemetryChannel">


<SamplingPercentage>10</SamplingPercentage>
</Add>
Como alternativa, en lugar de establecer el parámetro de muestreo en el archivo

ApplicationInsights.config , puede establecer estos valores mediante programación:
// ...
var builder =
TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder
;
instead:
// var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;
builder.UseSampling(10.0); // percentage

builder.Build();
(Más información sobre los procesadores de telemetría).

Configuración del muestreo de frecuencia fija para aplicaciones de ASP.NET Core
1. Deshabilite el muestreo adaptable : Se pueden realizar cambios en el método
ConfigureServices mediante ApplicationInsightsServiceOptions :
{
// ...
var aiOptions = new

Microsoft.ApplicationInsights.AspNetCore.Extensions.ApplicationInsightsServiceOpt
ions();
//...
}
2. Habilite el módulo de muestreo de frecuencia fija. Se pueden realizar cambios

en el método Configure , tal como se muestra en el siguiente fragmento de código:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)

{
var configuration =
app.ApplicationServices.GetService<TelemetryConfiguration>();
var builder =
configuration.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
instead:
// var builder =
TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;
// Using fixed rate sampling

double fixedSamplingPercentage = 10;
builder.UseSampling(fixedSamplingPercentage);
builder.Build();
// ...
}
Configuración del muestreo de frecuencia fija para aplicaciones de Java

De manera predeterminada, no hay ningún muestreo habilitado en el agente ni en el SDK de
Java. Actualmente, solo admite el muestreo de frecuencia fija. No se admite el muestreo
adaptable en Java.
Configuración del agente de Java
1. Descargue applicationinsights-agent-3.0.0-PREVIEW.5.jar.
2. Para habilitar el muestreo, agregue lo siguiente al archivo ApplicationInsights.json :
{
"preview": {
"sampling": {
"fixedRate": {
"percentage": 10 //this is just an example that shows you how to enable only
only 10% of transaction
}
}
}
}
}
Configuración del SDK de Java

1. Descargue y configure la aplicación web con la versión más reciente del SDK de
Application Insights para Java.
2. Habilite el módulo de muestreo de frecuencia fija ; para ello, agregue el
siguiente fragmento de código al archivo ApplicationInsights.xml :
<BuiltInProcessors>
<Processor type="FixedRateSamplingTelemetryProcessor">

<Add name="SamplingPercentage" value="50" />
</Processor>
</BuiltInProcessors>
3. Puede incluir o excluir determinados tipos de telemetría del muestreo con las
siguientes etiquetas dentro del elemento FixedRateSamplingTelemetryProcessor de la
etiqueta Processor :
<ExcludedTypes>
<ExcludedType>Request</ExcludedType>
</ExcludedTypes>
<IncludedTypes>
<IncludedType>Exception</IncludedType>
</IncludedTypes>
Los tipos de telemetría que se pueden incluir o excluir del muestreo son: Dependency , Event
, Exception , PageView , Request y Trace .
NOTE
Para el porcentaje de muestreo, elija un porcentaje que esté cerca de 100/N, donde N es un número
entero. Actualmente el muestreo no es compatible con otros valores.
Configuración del muestreo de frecuencia fija para aplicaciones de Python de OpenCensus

Instrumente la aplicación con los exportadores de Azure Monitor de OpenCensus más
recientes.
NOTE
El muestreo de frecuencia fija no está disponible para el exportador de métricas. Esto significa que
las métricas personalizadas son los únicos tipos de telemetría en los que NO se puede configurar el
muestreo. El exportador de métricas enviará toda la telemetría de la que realice el seguimiento.
Muestreo de frecuencia fija para seguimiento

Puede especificar un elemento sampler como parte de la configuración de Tracer . Si no se
proporciona ningún elemento sampler explícito, se usará de forma predeterminada
ProbabilitySampler . ProbabilitySampler usaría una frecuencia de 1/10 000 de forma
predeterminada, lo que significa que se enviará a Application Insights una de cada 10 000
solicitudes. Si desea especificar una frecuencia de muestreo, consulte a continuación.
Para especificar la frecuencia de muestreo, asegúrese de que Tracer especifica un elemento
sampler con una frecuencia de muestreo entre 0,0 y 1,0, ambos inclusive. Una velocidad de
muestreo de 1,0 representa el 100 %, lo que significa que todas las solicitudes se enviarán
como datos de telemetría a Application Insights.
tracer = Tracer(
exporter=AzureExporter(
instrumentation_key='00000000-0000-0000-0000-000000000000',
),
sampler=ProbabilitySampler(1.0),
)
Muestreo de frecuencia fija para registros

Puede configurar el muestreo de frecuencia fija para AzureLogHandler mediante la
modificación del argumento opcional logging_sampling_rate . Si no se proporciona ningún
argumento, se usará una frecuencia de muestreo de 1.0. Una velocidad de muestreo de 1,0
representa el 100 %, lo que significa que todas las solicitudes se enviarán como datos de
telemetría a Application Insights.
handler = AzureLogHandler(
instrumentation_key='00000000-0000-0000-0000-000000000000',
logging_sampling_rate=0.5,
)
Configuración del muestreo de frecuencia fija para páginas web con JavaScript
Las páginas web basadas en JavaScript se pueden configurar para usar Application Insights.
Los datos de telemetría se envían desde la aplicación cliente que se ejecuta en el explorador
del usuario y las páginas se pueden hospedar en cualquier servidor.
Cuando configure las páginas web basadas en JavaScript para Application Insights,
modifique el fragmento de código de JavaScript que obtiene del portal de Application
Insights.
TIP
En aplicaciones de ASP.NET con JavaScript incluido, el fragmento de código suele ir en
_Layout.cshtml .
Inserte una línea como samplingPercentage: 10, antes de la clave de instrumentación:
<script>
var appInsights = // ...
({
// Value must be 100/N where N is an integer.
// Valid examples: 50, 25, 20, 10, 5, 1, 0.1, ...
samplingPercentage: 10,
instrumentationKey: ...
});
window.appInsights = appInsights;
</script>
Para el porcentaje de muestreo, elija un porcentaje que esté cerca de 100/N, donde N es un
número entero. Actualmente el muestreo no es compatible con otros valores.
Coordinación del muestreo en el lado servidor y en el cliente
El SDK de JavaScript del cliente participa en el muestreo de frecuencia fija junto con el SDK
del lado servidor. Las páginas instrumentadas solo enviarán telemetría del cliente desde el
mismo usuario para el que el SDK del servidor decidió incluir en el muestreo. Esta lógica
está diseñada para mantener la integridad de la sesión de usuario entre las aplicaciones en
el lado cliente y el lado servidor. Como resultado, a partir de cualquier elemento específico
de telemetría en Application Insights, puede encontrar todos los demás elementos de
telemetría para ese usuario o esa sesión y, en Buscar, puede desplazarse entre las vistas de
página y las solicitudes relacionadas.
Si la telemetría del lado cliente y la del lado servidor no muestran muestras coordinadas:
Compruebe que habilitó el muestreo tanto en el cliente como en el servidor.
Compruebe que establece el mismo porcentaje de muestreo en el cliente y el servidor.
Asegúrese de que la versión del SDK es 2.0 o superior.
muestreo de ingesta
El muestreo de ingesta funciona en el punto en el que la telemetría del servidor web, los
exploradores y los dispositivos alcanzan el punto de conexión de servicio de Application
Insights. Aunque no reduce el tráfico de telemetría enviado desde su aplicación, sí reduce la
cantidad procesada y retenida (y cobrada) por Application Insights.
Utilice este tipo de muestreo si con frecuencia su aplicación sobrepasa su cuota mensual y
no tiene la opción de usar ninguno de los tipos de muestreo basados en el SDK.
Establecer la frecuencia de muestreo en la página Uso y costos estimados:
Al igual que otros tipos de muestreo, el algoritmo conserva elementos de telemetría

relacionados. Por ejemplo, cuando se inspeccione la telemetría en Búsqueda, podrá buscar la
solicitud relacionada con una excepción determinada. Los recuentos de métrica, como la tasa
de solicitudes y la tasa de excepciones se mantienen correctamente.
Los puntos de datos que se descartan por muestreo no están disponibles en ninguna
característica de Application Insights como exportación continua.
El muestreo de ingesta no funciona mientras el muestreo adaptable o el de frecuencia fija
están en funcionamiento. El muestreo adaptable está habilitado de forma predeterminada
cuando se usa el SDK de ASP.NET o el SDK de ASP.NET Core o cuando Application Insights
está habilitado en Azure App Service o mediante el Monitor de estado. Cuando el punto de
conexión de servicio de Application Insights recibe la telemetría, examina la telemetría y, si
se indica que la frecuencia de muestreo es inferior al 100% (lo que indica que se muestreará
la telemetría), se omite la frecuencia del muestreo de ingesta que establezca.
WARNING
El valor que se muestra en el icono del portal indica el valor que ha establecido para el muestreo de
ingesta. Si un muestreo del SDK está en funcionamiento (muestreo adaptable o de frecuencia fija),
no representa la frecuencia real de muestreo.
¿Cuándo usar el muestreo?

En general, para la mayoría de las aplicaciones pequeñas y medianas no es necesario
realizar muestreos. La información de diagnóstico más útil y las estadísticas más precisas se
obtienen mediante la recopilación de datos en todas las actividades del usuario.
Las principales ventajas del muestreo son:
El servicio de Application Insights descarta ("limita") puntos de datos cuando la
aplicación envía un número muy elevado de datos de telemetría en un intervalo de
tiempo corto. El muestreo reduce la probabilidad de que se produzca una limitación en la
aplicación.
Para mantenerse dentro de la cuota de puntos de datos de su plan de tarifa.
Para reducir el tráfico de red de la recopilación de telemetría.
¿Qué tipo de muestreo debo utilizar?
Use el muestreo de ingesta si:
Sobrepasa con frecuencia su cuota mensual de telemetría.
Recibe muchos datos de telemetría de los exploradores web de los usuarios.
Usa una versión del SDK que no admite el muestreo; por ejemplo, las versiones de
ASP.NET anteriores a la 2.
Use el muestreo de frecuencia fija si:
Quiere un muestreo sincronizado entre cliente y servidor para que, cuando investigue
eventos en Buscar, pueda desplazarse entre los eventos relacionados en el cliente y el
servidor, como vistas de página y solicitudes HTTP.
Está seguro del porcentaje de muestreo adecuado para la aplicación. Debe ser lo bastante
alto como para obtener métricas precisas, pero inferior a la frecuencia que supera la
cuota de precios y los valores de limitación.
Use el muestreo adaptable si:
Si no se cumplen las condiciones para usar las otras formas de muestreo, le recomendamos
el muestreo adaptable. Esta opción está habilitada de manera predeterminada en el SDK de
ASP.NET y ASP.NET Core. No reducirá el tráfico hasta que se alcance un determinado índice
mínimo; por lo tanto, los sitios con poco uso probablemente no se muestrearán.
¿Cómo se puede saber si el muestreo está en

funcionamiento?
Para conocer la frecuencia de muestreo real independientemente de dónde se ha aplicado,
use una consulta de Analytics como esta:
union requests,dependencies,pageViews,browserTimings,exceptions,traces
| summarize RetainedPercentage = 100/avg(itemCount) by bin(timestamp, 1h), itemType
Si ve que RetainedPercentage para cualquier tipo es inferior a 100, se muestrea ese tipo de
telemetría.
IMPORTANT
Application Insights no realiza el muestreo de los contadores de sesión, métricas (incluidas las
métricas personalizadas) ni rendimiento de los tipos de telemetría en ninguna de las técnicas de
muestreo. Estos tipos siempre se excluyen del muestreo, ya que la reducción en la precisión puede
ser altamente indeseable para estos tipos de telemetría.
Cómo funciona el muestreo

El algoritmo de muestreo decide qué elementos de telemetría se van a eliminar y cuáles
conservar. Esto es cierto si el muestreo lo realiza el SDK o el servicio de Application Insights.
La decisión del muestreo se basa en varias reglas que tienen como objetivo conservar
intactos todos los puntos de datos interrelacionados, manteniendo una experiencia de
diagnóstico en Application Insights que sea práctica y confiable, incluso con un conjunto
reducido de datos. Por ejemplo, si la aplicación tiene una solicitud con error incluida en una
muestra, se conservarán los elementos de telemetría adicionales (como la excepción y los
seguimientos registrados para esta solicitud). El muestreo los mantiene o los elimina en
conjunto. Como resultado, al examinar los detalles de solicitud en Application Insights,
siempre puede ver la solicitud junto con sus elementos de telemetría asociados.
La decisión de muestreo se basa en el identificador de operación de la solicitud, lo que
significa que todos los elementos de telemetría que pertenecen a una operación
determinada se conservan o se descartan. Para los elementos de telemetría que no tienen
establecido un identificador de operación (por ejemplo, los elementos de telemetría
notificados desde subprocesos asincrónicos sin contexto HTTP), el muestreo simplemente
captura un porcentaje de elementos de telemetría de cada tipo.
Al presentarle la telemetría, el servicio de Application Insights ajusta las métricas con el
mismo porcentaje de muestreo que se usó en el momento de la recopilación, para
compensar por los puntos de datos que faltan. Por lo tanto, al examinar la telemetría en
Application Insights, los usuarios ven aproximaciones estadísticamente correctas que están
muy próximas a los números reales.
La precisión de la aproximación depende en gran medida del porcentaje de muestreo
configurado. También, la precisión aumenta en las aplicaciones que administran un gran
volumen de solicitudes básicamente similares de muchos usuarios. Por otro lado, para las
aplicaciones que no funcionan con una carga significativa, el muestreo no es necesario ya
que estas aplicaciones normalmente pueden enviar toda su telemetría manteniéndose
dentro de la cuota, sin causar pérdida de datos por causa de la limitación.

¿Cuál es el comportamiento de muestreo predeterminado en los SDK de ASP.NET y ASP.NET
Core?
Si usa una de las versiones más recientes del SDK anterior, el muestreo adaptable está
habilitado de manera predeterminada con cinco elementos de telemetría por
segundo. Hay dos nodos AdaptiveSamplingTelemetryProcessor agregados de forma
predeterminada y uno incluye el tipo Event en el muestreo, mientras que el otro
excluye el tipo Event del muestreo. Esta configuración significa que el SDK intentará
limitar los elementos de telemetría a cinco elementos de telemetría de tipo Event y
cinco elementos de telemetría de todos los demás tipos combinados, lo que garantiza
que el muestreo de Events se realiza por separado de otros tipos de telemetría. Los
eventos se suelen usar para la telemetría empresarial y es más probable que no
deban verse afectados por los volúmenes de telemetría de diagnóstico.
A continuación se muestra el archivo ApplicationInsights.config predeterminado
generado. En ASP.NET Core, el mismo comportamiento predeterminado se habilita en
el código. Use los ejemplos de la sección anterior de esta página para cambiar este
comportamiento predeterminado.
<Add
<ExcludedTypes>Event</ExcludedTypes>
</Add>
<Add
<IncludedTypes>Event</IncludedTypes>
</Add>
¿La telemetría se puede muestrear más de una vez?

No. Los elementos SamplingTelemetryProcessors omiten elementos de las
consideraciones de muestreo si el elemento ya se ha muestreado. Lo mismo sucede para
el muestreo de ingesta, que no aplicará el muestreo a los elementos ya muestreados en
el propio SDK.
¿Por qué realizar un muestreo no consiste simplemente en "recopilar X por ciento de cada
tipo de telemetría"?
Aunque este método de muestreo proporcionaría un nivel de precisión alto en las
aproximaciones de métricas, destruiría la capacidad de poner en correlación datos de
diagnóstico por usuario, sesión y solicitud, lo cual es crítico para el diagnóstico. Por lo
tanto, el muestreo funciona mejor con directivas como "recopilar todos los elementos de
telemetría para el X por ciento de los usuarios de la aplicación" o "recopilar toda la
telemetría para el X por ciento de las solicitudes de la aplicación". Para los elementos de
telemetría no asociados con las solicitudes (por ejemplo, el procesamiento asincrónico en
segundo plano), la acción de reserva es "recopilar X por ciento de todos los elementos
para cada tipo de telemetría".
¿Se puede cambiar el porcentaje de muestreo con el tiempo?
Sí, el muestreo adaptable cambia gradualmente el porcentaje de muestreo, en función
del volumen de datos de telemetría observado en ese momento.
Si uso el muestreo de frecuencia fija, ¿cómo sé cuál es el porcentaje de muestreo que
funcionará mejor para mi aplicación?
Una manera de comenzar es con muestreo adaptable, averigüe qué velocidad elige
(consulte la pregunta anterior) y luego cambie a muestreo de tasa fija con esa
velocidad.
Si no, lo tendrá que adivinar. Analice su uso actual de telemetría en Application
Insights, observe las limitaciones que se produzcan y estime el volumen de telemetría
recopilado. Estas tres entradas, junto con el plan de tarifa seleccionado, le sugerirán
cuánto debería reducir el volumen de telemetría recopilado. Sin embargo, un
aumento del número de usuarios o algún otro incremento en el volumen de datos de
telemetría podrían provocar que la estimación no fuese válida.
¿Qué sucede si configuro un porcentaje de muestreo demasiado bajo?
Un porcentaje de muestreo excesivamente bajo provoca un muestreo excesivo y reduce
la precisión de las aproximaciones cuando Application Insights intenta compensar la
visualización de los datos por la reducción del volumen de datos. Además, la experiencia
de diagnóstico puede verse afectada negativamente, ya que algunas de las solicitudes
con poca frecuencia errores o lentas pueden quedar fuera del muestreo.
¿Qué sucede si configuro un porcentaje de muestreo demasiado alto?
Configurar un porcentaje de muestreo demasiado alto (no suficientemente drástico) da
como resultado una reducción insuficiente del volumen de telemetría recopilada. Se
pueden seguir produciendo pérdidas de datos de telemetría relacionadas con la
limitación, y el costo de usar Application Insights puede ser mayor de lo planeado, debido
a los cargos debidos al uso por encima del límite.
¿En qué plataformas puedo usar muestreo?
El muestreo de ingesta puede producirse automáticamente cuando cualquier dato de
telemetría se sitúa por encima de un determinado volumen, si el SDK no realiza
muestreo. Esta configuración funcionaría, por ejemplo, si usa una versión antigua del
SDK de ASP.NET o del SDK de Java.
Si usa los SDK de ASP.NET o ASP.NET Core actuales (hospedado en Azure o en su propio
servidor), obtendrá de forma predeterminada el muestreo adaptable, pero puede
cambiar al de frecuencia fija como se ha descrito anteriormente. Con el muestreo de
frecuencia fija, el SDK del explorador se sincroniza automáticamente con los eventos
relacionados con el muestreo.
Si usa el agente de Java actual, puede configurar ApplicationInsights.json (para el SDK
de Java, configure ApplicationInsights.xml ) para activar el muestreo de frecuencia fija.
De manera predeterminada, el muestreo está desactivado. Con el muestreo de frecuencia
fija, el SDK del explorador y el servidor se sincronizan automáticamente para muestrear
los eventos relacionados.
Hay ciertos eventos excepcionales que siempre quiero ver. ¿Cómo se consigue que el
módulo de muestreo los reconozca?
La mejor forma de lograrlo es escribir un objeto TelemetryInitializer personalizado,
que establece SamplingPercentage en 100 en el elemento de telemetría que desee
retener, tal como se muestra a continuación. Cuando se garantiza que los
inicializadores se ejecutan antes que los procesadores de telemetría (incluido el
muestreo), se tiene la seguridad de que todas las técnicas de muestreo omitirán este
elemento de cualquier consideración de muestreo. Se dispone de inicializadores de
telemetría personalizados en el SDK de ASP.NET, el SDK de ASP.NET Core, el SDK de
JavaScript y el SDK de Java. Por ejemplo, puede configurar un inicializador de
telemetría mediante el SDK de ASP.NET:

{
{
if(somecondition)
{
((ISupportSampling)telemetry).SamplingPercentage = 100;
}
}
}
Versiones anteriores de SDK

El muestreo adaptable está disponible para el SDK de Application Insights para ASP.NET
v2.0.0-beta3 y versiones posteriores y el SDK de Microsoft.ApplicationInsights.AspNetCore
v2.2.0-beta1 y versiones posteriores y está habilitado de manera predeterminada.
El muestreo de frecuencia fija es una característica del SDK de ASP.NET de la versión 2.0.0 y
posteriores y del SDK de Java de la versión 2.0.1 y posteriores.
Antes de la versión v2.5.0-beta2 del SDK de ASP.NET y de la versión v2.2.0-beta3 del SDK de
ASP.NET Core, la decisión de muestreo se basaba en el hash del identificador de usuario de
las aplicaciones que definen al "usuario" (es decir, las aplicaciones web más habituales). Para
los tipos de aplicaciones que no definen a los usuarios (como los servicios web), la decisión
de muestreo se basaba en el identificador de operación de la solicitud. Las versiones
recientes de los SDK de ASP.NET y ASP.NET Core usan el identificador de operación para la
decisión de muestreo.
Pasos siguientes
filtro puede proporcionar un control más estricto de los SDK que envía.
Lea el artículo de Developer Network Optimize Telemetry with Application Insights
(Optimización de la telemetría con Application Insights).
Canales de telemetría en Application Insights
Los canales de telemetría son una parte integral de los SDK de Azure Application Insights. Administran el
almacenamiento en búfer y la transmisión de telemetría al servicio Application Insights. Las versiones de los SDK
de .NET y .NET Core tienen dos canales de telemetría integrados: InMemoryChannel y ServerTelemetryChannel . En
este artículo se describe cada canal en detalle, incluido el procedimiento para personalizar el comportamiento del
canal.
¿Cuáles son los canales de telemetría?

Los canales de telemetría son responsables de almacenar en búfer los elementos de telemetría y enviarlos al
servicio Application Insights, donde se almacenan con finalidades de consultas y análisis. Un canal de telemetría
es cualquier clase que implementa la interfaz Microsoft.ApplicationInsights.ITelemetryChannel .
El método Send(ITelemetry item) de un canal de telemetría se invoca después de llamar a todos los
inicializadores y procesadores de telemetría. Por lo tanto, todos los elementos que proporciona un procesador de
telemetría no alcanzarán el canal. Normalmente, el método Send() no envía los elementos al back-end de
manera instantánea. Por lo general, los almacena en búfer y los envía en lotes a fin de que la transmisión sea
eficaz.
Live Metrics Stream también tiene un canal personalizado que sustenta el streaming en vivo de la telemetría. Este
canal es independiente del canal de telemetría normal, por lo que no se cubre en este documento.
Canales de telemetría integrados

Los SDK de .NET Core y .NET de Application Insights se envían con dos canales integrados:
InMemoryChannel : un canal ligero que almacena en búfer los elementos en la memoria hasta que se envían.
Los elementos se almacenan en búfer en la memoria y se vacían una vez cada 30 segundos, o cada vez que
se almacenan en búfer 500 elementos. Este canal ofrece garantías de confiabilidad mínimas porque no
reintenta el envío de telemetría tras un error. Asimismo, no conserva los elementos en el disco, por lo que
todos los elementos no enviados se pierden permanentemente cuando se cierra la aplicación
(independiente de si se trata de un cierre estable o no). Este canal implementa un método Flush() que
puede usarse para vaciar por la fuerza todos los elementos de telemetría que hay en la memoria de
manera sincrónica. Resulta adecuado para las aplicaciones de ejecución breve en las que es ideal realizar un
vaciado sincrónico.
El canal forma parte del mayor paquete Microsoft.ApplicationInsights de NuGet y es el que usa el SDK de
manera predeterminada cuando no hay nada más configurado.
ServerTelemetryChannel : se trata de un canal más avanzado con directivas de reintento y la capacidad de
almacenar datos en un disco local. Este canal reintenta el envío de telemetría si se producen errores
transitorios. Asimismo, usa el almacenamiento en disco local para mantener los elementos en el disco
durante las interrupciones de red o grandes volúmenes de telemetría. Debido a estos mecanismos de
reintento y el almacenamiento en disco local, este canal se considera más confiable y se recomienda para
todos los escenarios de producción. Es la opción predeterminada para las aplicaciones ASP.NET y ASP.NET
Core que están configuradas según la documentación oficial. Este canal está optimizado para escenarios de
servidor con procesos de larga ejecución. El método Flush() que implementa este canal no es sincrónico.
Este canal se incluye con el paquete Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel NuGet
y se adquiere automáticamente cuando se utiliza el paquete de NuGet
Microsoft.ApplicationInsights.AspNetCore o Microsoft.ApplicationInsights.Web.
Configuración de un canal de telemetría

Para configurar un canal de telemetría, debe establecerlo en la configuración de telemetría activa. En el caso de las
aplicaciones de ASP.NET, la configuración implica establecer la instancia del canal de telemetría en
TelemetryConfiguration.Active o bien modificar ApplicationInsights.config . Para las aplicaciones de ASP.NET
Core, la configuración implica agregar el canal al contenedor de inserción de dependencias.
En las secciones siguientes, se muestran ejemplos de configuración del valor StorageFolder para el canal en
distintos tipos de aplicaciones. StorageFolder es solo uno de los valores configurables. Para obtener la lista
completa de valores de configuración, consulte la sección configuración más adelante en este artículo.
Configuración mediante ApplicationInsights.config para aplicaciones de ASP.NET
En la sección siguiente de ApplicationInsights.config se muestra el canal configurado ServerTelemetryChannel con
StorageFolder establecido en una ubicación personalizada:
<TelemetrySinks>
<Add Name="default">

<TelemetryChannel
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel,
<StorageFolder>d:\temp\applicationinsights</StorageFolder>
</TelemetryChannel>
</Add>
</TelemetrySinks>
Configuración del código para las aplicaciones de ASP.NET

El código siguiente configura una instancia de "ServerTelemetryChannel" con StorageFolder establecido en una
ubicación personalizada. Agregue este código al principio de la aplicación, normalmente en el método
Application_Start() de Global.aspx.cs.
{
var serverTelemetryChannel = new ServerTelemetryChannel();
serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
}
Configuración del código para las aplicaciones de ASP.NET Core

Modifique el método ConfigureServices de la clase Startup.cs de la siguiente manera:

{
// This sets up ServerTelemetryChannel with StorageFolder set to a custom location.
services.AddSingleton(typeof(ITelemetryChannel), new ServerTelemetryChannel() {StorageFolder =
@"d:\temp\applicationinsights" });
}
IMPORTANT
No se recomienda configurar el canal mediante TelemetryConfiguration.Active para las aplicaciones de ASP.NET Core.
Configuración del código para las aplicaciones de consola de ASP.NET Core o .NET
En el caso de las aplicaciones de consola, el código es el mismo para .NET y .NET Core:
var serverTelemetryChannel = new ServerTelemetryChannel();

serverTelemetryChannel.StorageFolder = @"d:\temp\applicationinsights";
serverTelemetryChannel.Initialize(TelemetryConfiguration.Active);
TelemetryConfiguration.Active.TelemetryChannel = serverTelemetryChannel;
Detalles de funcionamiento de ServerTelemetryChannel

ServerTelemetryChannel almacena los elementos que llegan de un búfer en memoria. Los elementos se serializan,
comprimen y almacenan en una instancia de Transmission una vez cada 30 segundos, o cuando se han
almacenado en búfer 500 elementos. Una sola instancia de Transmission contiene hasta 500 elementos y
representa un lote de datos de telemetría que se envía a través de una sola llamada HTTPS al servicio de
De forma predeterminada, se puede enviar un máximo de 10 instancias de Transmission en paralelo. Si llegan
datos de telemetría a velocidades más rápidas, o si el back-end de application Insights o la red funcionan con
lentitud, las instancias de Transmission se almacenan en memoria. La capacidad predeterminada de este búfer
Transmission en memoria es de 5 MB. Cuando se ha superado la capacidad en memoria, las instancias de
Transmission se almacenan en el disco local hasta un límite de 50 MB. Las instancias de Transmission también se
almacenan en el disco local cuando hay problemas de red. Solo los elementos que se almacenan en un disco local
sobreviven a un bloqueo de la aplicación. Se envían siempre que la aplicación se inicia de nuevo.
Valores configurables en los canales

Para obtener la lista completa de valores configurables de cada canal, consulte:
Inmemorychannel
ServerTelemetryChannel
A continuación, le mostramos la configuración que se usa con más frecuencia para ServerTelemetryChannel :
1. MaxTransmissionBufferCapacity : cantidad máxima de memoria, en bytes, que usa el canal para las
transmisiones de búfer en memoria. Cuando se alcanza esta capacidad, los nuevos elementos se
almacenan directamente en el disco local. El valor predeterminado es de 5 MB. Si se establece un valor
superior, el uso del disco se reduce, sin embargo, recuerde que los elementos en memoria se perderán si se
bloquea la aplicación.
2. MaxTransmissionSenderCapacity : número máximo de instancias de Transmission que se enviarán a
Application Insights al mismo tiempo. El valor predeterminado es 10. Este valor puede configurarse en un
número mayor, cosa que se recomienda cuando se genera un gran volumen de telemetría. El gran volumen
normalmente tiene lugar durante las pruebas de carga o cuando se desactiva el muestreo.
3. StorageFolder : Carpeta que usa el canal para almacenar elementos en el disco según sea necesario. En
Windows, se usa %LOCALAPPDATA% o %TEMP% si no se especifica ninguna otra ruta de acceso de forma
explícita. En entornos que no son de Windows, debe especificar una ubicación válida o, de lo contrario, la
telemetría no se almacenará en el disco local.
¿Qué canal debería usar?

Se recomienda el canal ServerTelemetryChannel para los escenarios de mayor producción que implican
aplicaciones de ejecución prolongada. El método Flush() que implementa ServerTelemetryChannel no es
sincrónico, y tampoco garantiza que se envíen todos los elementos pendientes de la memoria o disco. Si utiliza
este canal en escenarios en que la aplicación está a punto de cerrarse, le recomendamos que introduzca algún
retraso después de llamar a Flush() . La cantidad exacta de retraso que puede necesitar no es predecible.
Depende de factores como el número de elementos o de instancias de Transmission que hay en la memoria, de
cuántos están en el disco y cuántos se están transmitiendo al back-end y de si el canal está en medio de
escenarios de retroceso exponenciales.
Si necesita realizar un vaciado sincrónico, le recomendamos que use InMemoryChannel .

¿El canal de Application Insights garantiza la entrega de los datos de telemetría? Si no es así, ¿cuáles son los
escenarios en los que se pueden perder los datos de telemetría?
La respuesta corta es que ninguno de los canales integrados ofrece una garantía de tipo de transacción de entrega
de telemetría al back-end. El canal ServerTelemetryChannel es más avanzado comparado con InMemoryChannel en
lo que respecta a la entrega confiable, pero solo hace un intento de mejor esfuerzo para enviar la telemetría. Aún
así, igualmente se pueden perder datos de telemetría en diversas situaciones, incluidos los escenarios comunes
siguientes:
1. Los elementos en la memoria se pierden cuando se bloquea la aplicación.
2. Los datos de telemetría se pierden durante largos períodos de problemas de red. Los datos de telemetría se
almacenan en el disco local durante las interrupciones de red o cuando se producen problemas con el
back-end de Application Insights. Sin embargo, se descartan los elementos anteriores a 48 horas.
3. Las ubicaciones predeterminadas del disco en las que se almacenan datos de telemetría en Windows son
%LOCALAPPDATA% o %TEMP%. Normalmente, estas ubicaciones se encuentran en el entorno local de la
máquina. Si la aplicación se migra físicamente desde una ubicación a otra, se pierde cualquier telemetría
almacenada en la ubicación original.
4. En Web Apps en Windows, la ubicación de almacenamiento en disco predeterminada es
D:\local\LocalAppData. Esta ubicación no se conserva. Se borra cuando se realizan reinicios de la aplicación,
escalados horizontales y otras operaciones similares, lo que da lugar a la pérdida de cualquier telemetría
almacenada. Puede reemplazar el valor predeterminado y especificar el almacenamiento en una ubicación
persistente como D:\home. Sin embargo, dado que estas ubicaciones persistentes las proporciona el
almacenamiento remoto, pueden ser lentas.
¿ServerTelemetryChannel funciona en sistemas distintos de Windows?
Aunque el nombre de su paquete y el espacio de nombres incluye "WindowsServer", este canal se admite en
sistemas distintos de Windows, con la siguiente excepción. En los sistemas distintos de Windows, el canal no crea
una carpeta de almacenamiento local de forma predeterminada. Debe crear una carpeta de almacenamiento local
y configurar el canal para que la use. Una vez configurado el almacenamiento local, el canal funciona del mismo
modo en todos los sistemas.
¿El SDK crea almacenamiento local temporal? ¿Se cifran los datos en el almacenamiento?
El SDK almacena elementos de telemetría en el almacenamiento local cuando se producen problemas de red o
hay una limitación. Estos datos no se cifran localmente.
En el caso de los sistemas Windows, el SDK crea automáticamente una carpeta temporal local en el directorio
%LOCALAPPDATA% o e %TEMP% y restringe el acceso solo a los administradores y al usuario actual.
Para los sistemas que distintos de Windows, no se crea ningún almacenamiento local automáticamente mediante
el SDK, por lo que no se almacena ningún dato localmente de forma predeterminada. Puede crear un directorio de
almacenamiento usted mismo y configurar el canal para que lo utilice. En este caso, es su responsabilidad
asegurarse de que se protege el directorio. Obtenga más información sobre la protección y la privacidad de los
datos.

Al igual que todos los SDK de Application Insights, los canales son código abierto. Puede leer el código y
contribuir en este, o bien notificar problemas en el repositorio oficial de GitHub.
Pasos siguientes
Muestreo
Solución de problemas del SDK
Filtro y preprocesamiento de la telemetría en el
SDK de Application Insights
Puede escribir y configurar complementos para el SDK de Application Insights con el fin de personalizar
cómo se enriquece y se procesa la telemetría antes de enviarla al servicio de Application Insights.
muestreo reduce el volumen de la telemetría sin que ello influya en las estadísticas. Mantiene juntos
los puntos de datos relacionados para que pueda navegar entre ellos a la hora de diagnosticar un
problema. En el portal, se multiplican los recuentos totales para compensar el muestreo.
El filtro con procesadores de telemetría permite filtrar la telemetría en el SDK antes de enviarla al
servidor. Por ejemplo, para reducir el volumen de la telemetría puede excluir las solicitudes de robots.
El filtro constituye un enfoque más básico que el muestreo para reducir el tráfico. Le permite tener un
mayor control sobre lo que se transmite, aunque afecta a las estadísticas. Por ejemplo, puede filtrar
todas las solicitudes correctas.
Los inicializadores de telemetría agregan o modifican propiedades a cualquier telemetría enviada
desde la aplicación, lo que incluye la telemetría de los módulos estándar. Por ejemplo, puede agregar
valores calculados o números de versión para filtrar los datos en el portal.
API del SDK se usa para enviar métricas y eventos personalizados.
Antes de comenzar:
Instale el SDK adecuado para su aplicación: ASP.NET, ASP.NET Core, No HTTP/Trabajo para .NET/.NET
Core o JavaScript.
Filtros
Esta técnica le ofrece un control directo sobre lo que se incluirá en la transmisión de telemetría o lo que
se excluirá de ella. El filtrado se puede usar para impedir el envío de elementos de telemetría a
Application Insights. Puede utilizar el filtrado junto con el muestreo o por separado.
Para filtrar la telemetría, escriba un procesador de telemetría y regístrelo con TelemetryConfiguration .
Toda la telemetría pasa por el procesador. Puede optar por no incluirla en la transmisión o por
proporcionársela al procesador siguiente en la cadena. Esto incluye la telemetría de los módulos
estándar, como el recopilador de solicitudes HTTP y el recopilador de dependencia, así como la telemetría
de la que haya realizado un seguimiento. Por ejemplo, puede filtrar para dejar fuera la telemetría acerca
de las solicitudes de robots o las llamadas de dependencia correctas.
WARNING
El filtrado de la telemetría enviada desde el SDK usando procesadores puede sesgar las estadísticas que se ven en
el portal y dificultar el seguimiento de elementos relacionados.
En su lugar, puede efectuar un muestreo.
Creación de un procesador de telemetría (C#)

1. Para crear un filtro, implemente ITelemetryProcessor .
Los procesadores de telemetría forman una cadena de procesamiento. Al crear instancias de un
procesador de telemetría, se le proporciona una referencia al procesador siguiente en la cadena.
Cuando un punto de datos de telemetría se pasa al método de proceso, realiza su trabajo y, a
continuación, llama (o no) al procesador de telemetría siguiente en la cadena.
public class SuccessfulDependencyFilter : ITelemetryProcessor

{
private ITelemetryProcessor Next { get; set; }
// next will point to the next TelemetryProcessor in the chain.

public SuccessfulDependencyFilter(ITelemetryProcessor next)
{
this.Next = next;
}
public void Process(ITelemetry item)

{
// To filter out an item, return without calling the next processor.
if (!OKtoSend(item)) { return; }
this.Next.Process(item);
}
// Example: replace with your own criteria.

private bool OKtoSend (ITelemetry item)
{
var dependency = item as DependencyTelemetry;
if (dependency == null) return true;
return dependency.Success != true;

}
}
2. Agregue el procesador.
Inserte este fragmento en ApplicationInsights.config:
<Add Type="WebApplication9.SuccessfulDependencyFilter, WebApplication9">

<MyParamFromConfigFile>2-beta</MyParamFromConfigFile>
</Add>
Puede pasar valores de cadena desde el archivo .config proporcionando propiedades con nombre
públicas en la clase.
WARNING
Tenga cuidado para que el nombre de tipo y los nombres de propiedad del archivo .config coincidan con los
nombres de clase y propiedad del código. Si el archivo .config hace referencia a un tipo o propiedad que no existe,
el SDK puede producir un error de forma silenciosa al enviar cualquier telemetría.
Alternativamente, se puede inicializar el filtro en el código. En una clase de inicialización adecuada (por
ejemplo, AppStart de Global.asax.cs ), inserte el procesador en la cadena:
var builder = TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
builder.Use((next) => new SuccessfulDependencyFilter(next));

builder.Build();
Los clientes de telemetría creados a partir de este punto usarán sus procesadores.
Aplicaciones Core/ Ser vicio de trabajo de ASP.NET
NOTE
La adición de un procesador mediante ApplicationInsights.config o TelemetryConfiguration.Active no
es válida para las aplicaciones de ASP.NET Core o si usa el SDK de Microsoft.ApplicationInsights.WorkerService.
Para las aplicaciones escritas mediante ASP.NET Core o WorkerService, la adición de un nuevo
procesador de telemetría se realiza mediante el método de extensión
AddApplicationInsightsTelemetryProcessor en IServiceCollection , como se muestra. Se llama a este
método en el método ConfigureServices de su clase Startup.cs .

{
// ...
services.AddApplicationInsightsTelemetryProcessor<SuccessfulDependencyFilter>();

services.AddApplicationInsightsTelemetryProcessor<AnotherProcessor>();
}
Filtros de ejemplo
Solicitudes sintéticas
Filtrar las pruebas web y robots. Aunque el Explorador de métricas proporciona la opción para filtrar y
dejar fuera los orígenes sintéticos, esta opción reduce el tráfico y el tamaño de ingesta filtrándolos en el
SDK.

{
if (!string.IsNullOrEmpty(item.Context.Operation.SyntheticSource)) {return;}
// Send everything else:

}
Error de autenticación
Filtrar solicitudes con una respuesta "401".
{
var request = item as RequestTelemetry;
if (request != null &&

request.ResponseCode.Equals("401", StringComparison.OrdinalIgnoreCase))
{
// To filter out an item, return without calling the next processor.
return;
}
// Send everything else

}
Filtrar las llamadas de dependencia rápida y remota

Si quiere diagnosticar solo las llamadas que son lentas, descarte las rápidas.
NOTE
Este filtrado sesgará las estadísticas que se ven en el portal.

{
var request = item as DependencyTelemetry;
if (request != null && request.Duration.TotalMilliseconds < 100)

{
return;
}
}
Diagnóstico de problemas de dependencia

este blog se describe un proyecto para diagnosticar problemas de dependencia enviando
automáticamente pings regulares a las dependencias.
Aplicaciones web de JavaScript
Filtro con ITelemetr yInitializer
1. Cree una función de devolución de llamada del inicializador de telemetría. La función de
devolución de llamada toma ITelemetryItem como parámetro, que es el evento que se está
procesando. La devolución de false desde esta devolución de llamada da lugar a que se filtre el
elemento de telemetría.
var filteringFunction = (envelope) => {

if (envelope.data.someField === 'tobefilteredout') {
return false;
}
return true;
};
2. Agregue la devolución de llamada del inicializador de telemetría:
appInsights.addTelemetryInitializer(filteringFunction);
Agregar o modificar propiedades: ITelemetryInitializer
Use los inicializadores de telemetría para enriquecer la telemetría con información adicional o para
invalidar las propiedades de telemetría establecidas por los módulos de telemetría estándar.
Por ejemplo, Application Insights para un paquete web recopila telemetría acerca de las solicitudes HTTP.
De forma predeterminada, marca como errónea cualquier solicitud con un código de respuesta >=400.
Pero si quiere tratar 400 como correcto, puede proporcionar un inicializador de telemetría que establezca
la propiedad de éxito.
Si se proporciona un inicializador de telemetría, se llama cada vez que se llama a cualquiera de los
métodos Track*(). Esto incluye los métodos Track() llamados por los módulos de telemetría estándar.
Por convención, estos módulos no establecen ninguna propiedad que ya haya sido establecida por un
inicializador. Se llama a los inicializadores de telemetría antes de llamar a los procesadores de telemetría.
Por tanto, cualquier enriquecimiento realizado por los inicializadores es visible para los procesadores.
Defina su inicializador
C#
using System;
{
/*
* Custom TelemetryInitializer that overrides the default SDK
* behavior of treating response codes >= 400 as failed requests
*
*/
{
{
var requestTelemetry = telemetry as RequestTelemetry;
// Is this a TrackRequest() ?
if (requestTelemetry == null) return;
int code;
bool parsed = Int32.TryParse(requestTelemetry.ResponseCode, out code);
if (!parsed) return;
if (code >= 400 && code < 500)
{
// If we set the Success property, the SDK won't change it:
requestTelemetry.Success = true;
// Allow us to filter these requests in the portal:

requestTelemetry.Properties["Overridden400s"] = "true";
}
// else leave the SDK to set the Success property
}
}
}
Aplicaciones ASP.NET: Carga del inicializador

En ApplicationInsights.config:

<Add Type="MvcWebRole.Telemetry.MyTelemetryInitializer, MvcWebRole"/>
...
Alternativamente, se pueden crear instancias del inicializador en el código, por ejemplo en Global.aspx.cs:

{
// ...
}
Obtenga más información de este ejemplo.

Aplicaciones Core/ Ser vicio de trabajo de ASP.NET: Carga del inicializador
NOTE
La adición de un inicializador mediante ApplicationInsights.config o TelemetryConfiguration.Active no
es válida para las aplicaciones de ASP.NET Core o si usa el SDK de Microsoft.ApplicationInsights.WorkerService.
Para las aplicaciones escritas mediante ASP.NET Core o WorkerService, la adición de un nuevo
inicializador de telemetría se realiza agregándolo al contenedor de inserción de dependencias, como se
muestra. Esto se hace en el método Startup.ConfigureServices .
{
}
Inicializadores de telemetría de JavaScript

JavaScript
Inserte un inicializador de telemetría inmediatamente después del código de inicialización que obtuvo
del portal:
// ... initialization code
...({
instrumentationKey: "your instrumentation key"
});
window.appInsights = appInsights;
// Adding telemetry initializer.

// This is called whenever a new telemetry item
// is created.
appInsights.queue.push(function () {
appInsights.context.addTelemetryInitializer(function (envelope) {
var telemetryItem = envelope.data.baseData;
// To check the telemetry items type - for example PageView:

if (envelope.name == Microsoft.ApplicationInsights.Telemetry.PageView.envelopeType) {
// this statement removes url from all page view documents
telemetryItem.url = "URL CENSORED";
}
// To set custom properties:

telemetryItem.properties = telemetryItem.properties || {};
telemetryItem.properties["globalProperty"] = "boo";
// To set custom metrics:

telemetryItem.measurements = telemetryItem.measurements || {};
telemetryItem.measurements["globalMetric"] = 100;
});
});
// End of inserted code.
</script>
Para obtener un resumen de las propiedades no personalizadas disponibles en el elemento de telemetría,

consulte Modelo de exportación de datos de Application Insights.
Puede agregar tantos inicializadores como desee. Se llaman en el orden en que se agregan.
Procesadores de telemetría de Python para OpenCensus
Los procesadores de telemetría de Python para OpenCensus son simplemente funciones de devolución
de llamada utilizadas para procesar la telemetría antes de que se exporten. La función de devolución de
llamada debe aceptar un tipo de datos de sobre como parámetro. Para filtrar la telemetría para que no se
exporte, asegúrese de que la función de devolución de llamada devuelva False . Puede ver el esquema
de los tipos de datos de Azure Monitor en los sobres en GitHub.
NOTE
cloud_RoleName se puede modificar cambiando el atributo ai.cloud.role del campo tags .
def callback_function(envelope):
envelope.tags['ai.cloud.role'] = 'new_role_name'
# Example for log exporter
import logging
# Callback function to append '_hello' to each log message telemetry

envelope.data.baseData.message += '_hello'
return True
handler = AzureLogHandler(connection_string='InstrumentationKey=<your-instrumentation_key-here>')
handler.add_telemetry_processor(callback_function)
logger.addHandler(handler)
logger.warning('Hello, World!')
# Example for trace exporter

import requests

config_integration.trace_integrations(['requests'])
# Callback function to add os_type: linux to span properties

envelope.data.baseData.properties['os_type'] = 'linux'
return True
exporter = AzureExporter(
connection_string='InstrumentationKey=<your-instrumentation-key-here>'
)
exporter.add_telemetry_processor(callback_function)
tracer = Tracer(exporter=exporter, sampler=ProbabilitySampler(1.0))
with tracer.span(name='parent'):
response = requests.get(url='https://www.wikipedia.org/wiki/Rabbit')
# Example for metrics exporter
import time
from opencensus.ext.azure import metrics_exporter

CARROTS_MEASURE = measure_module.MeasureInt("carrots",
"number of carrots",
"carrots")
CARROTS_VIEW = view_module.View("carrots_view",
"number of carrots",
[],
CARROTS_MEASURE,
# Callback function to only export the metric if value is greater than 0

return envelope.data.baseData.metrics[0].value > 0
def main():
# Enable metrics
# Set the interval in seconds in which you want to send metrics
exporter = metrics_exporter.new_metrics_exporter(connection_string='InstrumentationKey=<your-
instrumentation-key-here>')
exporter.add_telemetry_processor(callback_function)
view_manager.register_exporter(exporter)
view_manager.register_view(CARROTS_VIEW)
mmap.measure_int_put(CARROTS_MEASURE, 1000)
mmap.record(tmap)
# Default export interval is every 15.0s
# Your application should run for at least this amount
# of time so the exporter will meet this interval
# Sleep can fulfill this
time.sleep(60)
print("Done recording metrics")
if __name__ == "__main__":
main()
Puede agregar tantos procesadores como quiera. Se llaman en el orden en que se agregan. En el caso de
que un procesador produzca una excepción, esta no afectará a los procesadores siguientes.
TelemetryInitializers de ejemplo
Adición de una propiedad personalizada
El siguiente inicializador de ejemplo agrega una propiedad personalizada a cada una de las telemetrías
de las que se ha realizado un seguimiento.
public void Initialize(ITelemetry item)
{
var itemProperties = item as ISupportProperties;
if(itemProperties != null && !itemProperties.Properties.ContainsKey("customProp"))
{
itemProperties.Properties["customProp"] = "customValue";
}
}
Adición de un nombre de rol en la nube

El siguiente inicializador de ejemplo establece el nombre de rol en la nube a cada una de las telemetrías
de las que se ha realizado un seguimiento.

{
if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
{
telemetry.Context.Cloud.RoleName = "MyCloudRoleName";
}
}
Adición de información desde HttpContext

El inicializador de ejemplo siguiente lee los datos de HttpContext y lo anexa a una instancia de
RequestTelemetry . IHttpContextAccessor se proporciona automáticamente a través de la inserción de
dependencias del constructor.
public class HttpContextRequestTelemetryInitializer : ITelemetryInitializer

{
private readonly IHttpContextAccessor httpContextAccessor;
public HttpContextRequestTelemetryInitializer(IHttpContextAccessor httpContextAccessor)

{
this.httpContextAccessor =
httpContextAccessor ??
throw new ArgumentNullException(nameof(httpContextAccessor));
}

{
var requestTelemetry = telemetry as RequestTelemetry;
if (requestTelemetry == null) return;
var claims = this.httpContextAccessor.HttpContext.User.Claims;

Claim oidClaim = claims.FirstOrDefault(claim => claim.Type == "oid");
requestTelemetry.Properties.Add("UserOid", oidClaim?.Value);
}
}
ITelemetryProcessor e ITelemetryInitializer
¿Cuál es la diferencia entre los procesadores de telemetría y los inicializadores de telemetría?
Hay algunas superposiciones en lo que puede hacer con ellos. Ambos se pueden usar para agregar o
modificar las propiedades de la telemetría, aunque se recomienda usar inicializadores con esa
finalidad.
Los inicializadores de telemetría siempre se ejecutan antes que los procesadores de telemetría.
Se puede llamar a los inicializadores de telemetría más de una vez. Por convención, no establecen
ninguna propiedad que ya se haya establecido.
Los procesadores de telemetría permiten reemplazar o descartar por completo un elemento de
telemetría.
Se garantiza que se llamará a todos los inicializadores de telemetría registrados para cada elemento
de telemetría. En el caso de los procesadores de telemetría, el SDK garantiza la llamada al primer
procesador de telemetría. Los procesadores de telemetría anteriores deciden si se llama o no al resto
de los procesadores.
Use los inicializadores de la telemetría para enriquecerla con propiedades adicionales o invalidar una
existente. Use un procesador de telemetría para filtrar la telemetría.
Solución de problemas de ApplicationInsights.config

Compruebe que el nombre del tipo completo y el nombre del ensamblado sean correctos.
Compruebe que el archivo applicationinsights.config esté en el directorio de salida y que contenga
todos los cambios recientes.
Documentos de referencia
Información general acerca de la API
Referencia de ASP.NET
Código del SDK

SDK básico de ASP.NET
SDK de ASP.NET
SDK de JavaScript
Pasos siguientes
Búsqueda de eventos y registros
Muestreo
Correlación de Telemetría en Application Insights
En el mundo de los microservicios, todas las operaciones lógicas requieren que el trabajo se realice en diversos
componentes del servicio. Puede supervisar cada uno de estos componentes por separado mediante Application
Insights. Application Insights admite la correlación de telemetría distribuida, que se usa para detectar el
componente que es responsable de los errores o de una degradación del rendimiento.
Este artículo explica el modelo de datos utilizado por Application Insights para poner en correlación la telemetría
enviada por varios componentes. También se explican los protocolos y las técnicas de propagación contextual, así
como la implementación de tácticas de correlación en distintos lenguajes y plataformas.
Modelo de datos de correlación de telemetría

Application Insights define el modelo de datos para la correlación de telemetría distribuida. Para asociar la
telemetría con una operación lógica, todos los elementos de telemetría tienen el campo de contexto denominado
operation_Id . Todos los elementos de telemetría comparten este identificador en el seguimiento distribuido. De
este modo, aun si pierde telemetría desde una sola capa, se pueden seguir asociando los datos telemétricos
notificados por otros componentes.
Habitualmente, una operación lógica distribuida consta de un conjunto de operaciones más pequeñas, que son
solicitudes que se procesan en uno de los componentes. Estas operaciones se definen mediante telemetría de
solicitudes. Cada elemento de telemetría de solicitudes cuenta con su propio id , que lo identifica de manera global
e inequívoca. Además, todos los elementos de telemetría (como los seguimientos y las excepciones) que están
asociados a la solicitud deben establecer operation_parentId en el valor de la solicitud id .
La telemetría de dependencias representa a todas las operaciones salientes, como una llamada HTTP a otro
componente. La telemetría de dependencia también define su propio id , que es globalmente único. La telemetría
de solicitudes, que se inicia mediante esta llamada de dependencia, utiliza este id como su operation_parentId .
Puede crear una vista de la operación lógica distribuida usando operation_Id , operation_parentId y request.id
con dependency.id . Estos campos también definen el orden de causalidad de las llamadas de telemetría.
En el entorno de los microservicios, los seguimientos de componentes pueden ir a distintos elementos de
almacenamiento. Cada componente puede tener su propia clave de instrumentación en Application Insights. Para
obtener la telemetría de la operación lógica, Application Insights consulta los datos de cada elemento de
almacenamiento. Si el número de elementos de almacenamiento es grande, necesitará una pista para saber dónde
debe mirar a continuación. El modelo de datos de Application Insights define dos campos, request.source y
dependency.target , para solucionar este problema. El primer campo identifica el componente que inició la solicitud
de dependencia. El segundo campo identifica qué componente devolvió la respuesta de la llamada de dependencia.
Ejemplo
Veamos un ejemplo. Una aplicación llamada Stock Prices muestra el precio de mercado actual de una acción
mediante una API externa denominada Stock. La aplicación Stock Prices tiene una página llamada Stock page que el
explorador web del cliente abre mediante GET /Home/Stock . La aplicación consulta la API Stick mediante el uso de
una llamada HTTP GET /api/stock/value .
Puede analizar la telemetría resultante ejecutando una consulta:
(requests | union dependencies | union pageViews)
| where operation_Id == "STYz"
| project timestamp, itemType, name, id, operation_ParentId, operation_Id
En los resultados, observe que todos los elementos de telemetría comparten la raíz operation_Id . Cuando se
realiza una llamada Ajax desde la página, se asigna un nuevo identificador único ( qJSXU ) a la telemetría de
dependencia y el identificador de pageView se usa como operation_ParentId . La solicitud al servidor utiliza
después el identificador de Ajax como operation_ParentId .
O P ERAT IO N _PA REN T I

IT EM T Y P E NAME ID D O P ERAT IO N _ID
pageView Stock page STYz STYz
dependency GET /Home/Stock qJSXU STYz STYz
request GET Home/Stock KqKwlrSt9PA= qJSXU STYz
dependency GET /api/stock/value bBrf2L7mm2g= KqKwlrSt9PA= STYz
Cuando se realiza la llamada GET /api/stock/value a un servicio externo, necesita conocer la identidad de ese
servidor para poder establecer el campo dependency.target correctamente. Si el servicio externo no admite la
supervisión, target se establece en el nombre de host del servicio (por ejemplo, stock-prices-api.com ). Pero si
ese servicio se identifica devolviendo un encabezado HTTP predefinido, target contiene la identidad de servicio
que permite a Application Insights crear un seguimiento distribuido consultando la telemetría de ese servicio.
Encabezados de correlación
Application Insights está realizando la transición a W3C Trace-Context, que define:
traceparent : lleva el identificador único global de la operación y un identificador único de la llamada.
tracestate : lleva el contexto de seguimiento específico del sistema.
La versión más reciente del SDK de Application Insights es compatible con el protocolo de Trace-Context, pero es
posible que tenga que usarlo. (Se mantendrá la compatibilidad con el antiguo protocolo de correlación compatible
con el SDK de Application Insights).
El protocolo HTTP de correlación , también denominado Request-Id, está entrando en desuso. Este protocolo define
dos encabezados:
Request-Id : lleva el identificador único global de la llamada.
Correlation-Context : lleva la colección de pares nombre-valor de las propiedades del seguimiento distribuido.
Application Insights también define la extensión del protocolo HTTP de correlación. Usa pares nombre-valor
Request-Context para propagar la colección de propiedades utilizadas por el autor o el destinatario de la llamada. El
SDK de Application Insights usa este encabezado para establecer los campos dependency.target y request.source .
Habilitación de la compatibilidad con el seguimiento distribuido de W3C en aplicaciones clásicas de ASP.NET
NOTE
A partir de Microsoft.ApplicationInsights.Web y Microsoft.ApplicationInsights.DependencyCollector , no se
necesita configuración.
configuración:
habilitar Trace-Context. Esta característica está disponible en los paquetes Microsoft.ApplicationInsights.Web y
Microsoft.ApplicationInsights.DependencyCollector a partir de la versión 2.8.0-beta1. De forma predeterminada,
está deshabilitada. Para habilitarla, haga estos cambios en ApplicationInsights.config :
En RequestTrackingTelemetryModule , agregue el elemento EnableW3CHeadersExtraction y establezca su valor en
true .
En DependencyTrackingTelemetryModule , agregue el elemento EnableW3CHeadersInjection y establezca su valor en
true.
Agregue W3COperationCorrelationTelemetryInitializer en TelemetryInitializers . Será similar al siguiente
ejemplo:
<Add Type="Microsoft.ApplicationInsights.Extensibility.W3C.W3COperationCorrelationTelemetryInitializer,
Microsoft.ApplicationInsights"/>
...
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones de ASP.NET Core
NOTE
A partir de la versión 2.8.0 de Microsoft.ApplicationInsights.AspNetCore , no se necesita configuración.
configuración:
habilitar Trace-Context.
Esta característica está en la versión 2.5.0-beta1 de Microsoft.ApplicationInsights.AspNetCore y en la versión 2.8.0-
beta1 de Microsoft.ApplicationInsights.DependencyCollector . De forma predeterminada, está deshabilitada. Para
habilitarla, cambie ApplicationInsightsServiceOptions.RequestCollectionOptions.EnableW3CDistributedTracing a
true :
{
services.AddApplicationInsightsTelemetry(o =>
o.RequestCollectionOptions.EnableW3CDistributedTracing = true );
// ....
}
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones de Java

Agente de Java 3.0
El agente de Java 3.0 es compatible con W3C listo para usar y no se necesita ninguna configuración adicional.
SDK de Java
Configuración de entrada
En el caso de las aplicaciones de Java EE, agregue lo siguiente a la etiqueta <TelemetryModules> en el
archivo ApplicationInsights.xml:
<Add
type="com.microsoft.applicationinsights.web.extensibility.modules.WebRequestTrackingTelemetryModul
e>
<Param name = "W3CEnabled" value ="true"/>
<Param name ="enableW3CBackCompat" value = "true" />
</Add>
En el caso de las aplicaciones de Spring Boot, agregue estas propiedades:

azure.application-insights.web.enable-W3C=true
azure.application-insights.web.enable-W3C-backcompat-mode=true
Configuración de salida
<Instrumentation>
</BuiltIn>
</Instrumentation>
NOTE
El modo de compatibilidad con versiones anteriores está habilitado de forma predeterminada, por lo que el
enableW3CBackCompat parámetro es opcional. Solo debe utilizarlo cuando desee desactivar la compatibilidad con
versiones anteriores.
Lo ideal sería desactivar la compatibilidad cuando todos los servicios se hayan actualizado a la versión más reciente de
los SDK compatibles con el protocolo W3C. Se recomienda encarecidamente que cambie a estos SDK más recientes lo
antes posible.
IMPORTANT
Asegúrese de que las configuraciones de entrada y salida sean exactamente iguales.
Habilitar la compatibilidad con el seguimiento distribuido de W3C para aplicaciones web

Esta característica está en Microsoft.ApplicationInsights.JavaScript . De forma predeterminada, está deshabilitada.
Para habilitarla, use la configuración distributedTracingMode . AI_AND_W3C se proporciona para la compatibilidad
con versiones anteriores de cualquier servicio heredado instrumentado por Application Insights.
Configuración de npm (omitir si se usa Configuración de fragmentos de código)
import { ApplicationInsights, DistributedTracingModes } from '@microsoft/applicationinsights-web';

distributedTracingMode: DistributedTracingModes.W3C
} });
Configuración de fragmentos de código (omitir si se usa Configuración de npm)
aiName=window[sdkInstance],aisdk=window[aiName]||function(e){function n(e){i[e]=function(){var
n=arguments;i.queue.push(function(){i[e].apply(i,n)})}}var i={config:e};i.initialize=!0;var
a=document,t=window;setTimeout(function(){var
n=a.createElement("script");n.src=e.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",a.getEle
mentsByTagName("script")[0].parentNode.appendChild(n)});try{i.cookie=a.cookie}catch(e){}i.queue=
[],i.version=2;for(var r=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];r.length;)n("tr
ack"+r.pop());n("startTrackPage"),n("stopTrackPage");var o="Track"+r[0];if(n("start"+o),n("stop"+o),!
(!0===e.disableExceptionTracking||e.extensionConfig&&e.extensionConfig.ApplicationInsightsAnalytics&&!0=
==e.extensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){n("_"+(r="onerror"));var
s=t[r];t[r]=function(e,n,a,t,o){var c=s&&s(e,n,a,t,o);return!0!==c&&i["_"+r]
({message:e,url:n,lineNumber:a,columnNumber:t,error:o}),c},e.autoExceptionInstrumented=!0}return i}
(
{
instrumentationKey:"INSTRUMENTATION_KEY",
distributedTracingMode: 2 // DistributedTracingModes.W3C
}
);
window[aiName]=aisdk,aisdk.queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
OpenTracing y Application Insights

La especificación del modelo de datos de OpenTracing y los modelos de datos de Application Insights se asignan de
A P P L IC AT IO N IN SIGH T S O P EN T RA C IN G
Request , PageView Span con span.kind = server
Dependency Span con span.kind = client
Id de Request y Dependency SpanId
Operation_Id TraceId
Operation_ParentId Reference de tipo ChildOf (el intervalo primario)
Para más información, consulte Modelo de datos de telemetría de Application Insights.

Para ver definiciones de los conceptos de OpenTracing, consulte specification y semantic conventions de
OpenTracing.
Correlación de los datos de telemetría en OpenCensus Python

OpenCensus Python sigue las especificaciones del modelo de datos OpenTracing descritas anteriormente. También
admite Trace-Context de W3C sin requerir ninguna configuración.
Correlación de las solicitudes entrantes
OpenCensus Python correlaciona los encabezados de Trace-Context de W3C de las solicitudes entrantes a los
intervalos que se generan a partir de las solicitudes. OpenCensus lo hará automáticamente con integraciones para
marcos de aplicaciones web populares: Flask, Django y Pyramid. Solo tiene que rellenar los encabezados de Trace-
Context de W3C con el formato correcto y enviarlos con la solicitud. Esta es una aplicación de Flask de ejemplo que
muestra esto:

app,
)
@app.route('/')
def hello():
if __name__ == '__main__':
Este código ejecuta una aplicación de Flask de ejemplo en la máquina local, escuchando el puerto 8080 . Para
correlacionar el contexto de seguimiento, se envía una solicitud al punto de conexión. En este ejemplo, se puede
usar un comando curl :
curl --header "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" localhost:8080
Al examinar el formato de encabezado de Trace-Context, se deriva la información siguiente:

version : 00
trace-id : 4bf92f3577b34da6a3ce929d0e0e4736
parent-id/span-id : 00f067aa0ba902b7
trace-flags : 01
Si se echa un vistazo a la entrada de solicitud que se envió a Azure Monitor, se pueden ver los campos rellenados
con la información de encabezado de seguimiento. Puede encontrar estos datos en Registros (Analytics) en el
recurso Application Insights de Azure Monitor.
El campo id está en el formato <trace-id>.<span-id> , donde el trace-id se toma del encabezado de seguimiento
que se pasó en la solicitud y el span-id es una matriz de 8 bytes generada para este intervalo.
El campo operation_ParentId tiene el formato <trace-id>.<parent-id> , donde tanto trace-id como parent-id se
toman del encabezado de seguimiento que se pasó en la solicitud.
Python de OpenCensus permite correlacionar registros al agregar un identificador de seguimiento, un identificador
de intervalo y una marca de muestreo para escribir registros. Estos atributos se agregan al instalar la integración de
registro de OpenCensus. Los atributos siguientes se agregarán a los objetos LogRecord de Python: traceId ,
spanId y traceSampled . Tenga en cuenta que esto solo se aplica a los registradores que se crean después de la
integración.
Esta es una aplicación de ejemplo que muestra esto:
import logging

from opencensus.trace.samplers import AlwaysOnSampler
config_integration.trace_integrations(['logging'])
logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
tracer = Tracer(sampler=AlwaysOnSampler())
logger.warning('Before the span')
with tracer.span(name='hello'):
logger.warning('In the span')
logger.warning('After the span')
Cuando se ejecuta este código, se imprime lo siguiente en la consola:
2019-10-17 11:25:59,382 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 Before the span

2019-10-17 11:25:59,384 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=70da28f5a4831014 In the span
2019-10-17 11:25:59,385 traceId=c54cb1d4bbbec5864bf0917c64aeacdc spanId=0000000000000000 After the span
Observe que hay un spanId presente para el mensaje de registro que se encuentra dentro del intervalo. Es el
mismo spanId que pertenece al intervalo denominado hello .
Puede exportar los datos de registro mediante AzureLogHandler . Para obtener más información, consulte este
artículo.
Correlación de telemetría en .NET

Con el tiempo, .NET ha establecido diversas formas para establecer correspondencias entre la telemetría y los
registros de diagnósticos:
System.Diagnostics.CorrelationManager permite hacer el seguimiento de LogicalOperationStack y ActivityId.
System.Diagnostics.Tracing.EventSource y Seguimiento de eventos para Windows (ETW) definen el método
SetCurrentThreadActivityId.
ILogger usa ámbitos de registro.
Windows Communication Foundation (WCF) y HTTP conectan la propagación del contexto "actual".
Pero esos métodos no proporcionaban compatibilidad con el seguimiento distribuido automático.
DiagnosticSource admite la correlación automática entre máquinas. Las bibliotecas de .NET admiten
DiagnosticSource y permiten la propagación automática entre máquinas del contexto de correlación mediante el
transporte correspondiente; por ejemplo, HTTP.
En la guía de actividades para el usuario en DiagnosticSource se explican los conceptos básicos de las actividades
de seguimiento.
ASP.NET Core 2.0 admite la extracción de encabezados HTTP e inicia nuevas actividades.
A partir de la versión 4.1.0, System.Net.Http.HttpClient permite insertar automáticamente los encabezados HTTP
de correlación y realizar un seguimiento de las llamadas HTTP como actividades.
Hay un nuevo módulo HTTP, Microsoft.AspNet.TelemetryCorrelation para ASP.NET clásico. Este módulo implementa
la correlación de telemetría mediante DiagnosticSource . Las actividades se inician en función de los encabezados
de solicitud entrantes. También establece correlación entre los datos de telemetría de las distintas fases del
procesamiento de solicitudes, incluso cuando cada fase de procesamiento de Internet Information Services (IIS) se
ejecuta en un subproceso administrado diferente.
A partir de la versión 2.4.0-beta1, el SDK de Application Insights utiliza DiagnosticSource y Activity para recopilar
datos telemétricos y asociarlos con la actividad actual.
Correlación de telemetría en Java

El agente de Java y el SDK de Java versión 2.0.0 o posteriores permiten la correlación automática de la telemetría.
Rellena automáticamente el valor de operation_id en todos los elementos de telemetría (como seguimientos,
excepciones y eventos personalizados) que se emiten en el ámbito de una solicitud. También propaga los
encabezados de correlación (descritos anteriormente) de las llamadas de un servicio de a otro mediante HTTP si el
agente del SDK de Java está configurado.
NOTE
El agente de Java de Application Insights recopila automáticamente las solicitudes y dependencias de JMS, Kafka,
Netty/Webflux, etc. En el caso del SDK de Java, la característica de correlación solamente admite las llamadas realizadas
mediante Apache HttpClient. No se admite la propagación automática de contextos entre tecnologías de mensajería (como
Kafka, RabbitMQ y Azure Service Bus) en el SDK.
NOTE
Para recopilar la telemetría personalizada, debe instrumentar la aplicación con el SDK de Java 2.6.
Nombres de roles
Es posible que quiera personalizar el modo en que los nombres de los componentes aparecen en el mapa de
aplicación. Para ello, puede establecer manualmente el valor de cloud_RoleName a través de una de las acciones
siguientes:
Para el agente de Java 3.0 de Application Insights, establezca el nombre del rol de nube de la siguiente
manera:
{
"preview": {
}
}
}

Con el SDK 2.5.0 de Java de Application Insights y versiones posteriores, puede especificar el cloud_RoleName
si agrega <RoleName> al archivo ApplicationInsights.xml:

<RoleName>** Your role name **</RoleName>
...
Si usa Spring Boot con el código de inicio de Spring Boot de Application Insights, solo debe establecer el
nombre personalizado para la aplicación en el archivo application.properties:
spring.application.name=<name-of-app>
El código de inicio de Spring Boot asigna automáticamente cloudRoleName al valor que se especifica para la
propiedad spring.application.name .
Pasos siguientes
Escriba una telemetría personalizada.
En el caso de escenarios avanzados de correlación en ASP.NET Core y ASP.NET, consulte el artículo sobre el
Obtenga más información sobre la opción cloud_RoleName en otros SDK.
Incorpore todos los componentes de un microservicio en Application Insights. Consulte las plataformas
compatibles.
Consulte en el modelo de datos los tipos de Application Insights.
Obtenga información sobre cómo ampliar y filtrar la telemetría.
Consulte la referencia de configuración de Application Insights.
Seguimiento de las operaciones personalizadas con
el SDK de .NET para Application Insights
Los SDK de Azure Application Insights realizan el seguimiento automático de las solicitudes HTTP de entrada y
las llamadas a los servicios dependientes, como solicitudes HTTP y consultas SQL. El seguimiento y la
correlación de las solicitudes y dependencias le ofrece visibilidad en la capacidad de respuesta de toda la
aplicación y la confiabilidad en todos los microservicios que combinan esta aplicación.
Hay una clase de patrones de aplicación que no se admiten de forma genérica. La supervisión correcta de estos
patrones requiere la instrumentación manual de código. En este artículo se abordan algunos patrones que
pueden requerir la instrumentación manual, como el procesamiento de colas personalizadas y la ejecución de
tareas de larga duración en segundo plano.
En este documento se proporcionan instrucciones sobre cómo realizar el seguimiento de operaciones
personalizadas con el SDK de Application Insights. Esta documentación es relevante para:
Application Insights para .NET (también conocido como Base SDK) versión 2.4+.
Application Insights para aplicaciones web (con ASP.NET) versión 2.4+.
Application Insights para ASP.NET Core versión 2.1+.
Una operación es una parte de trabajo lógica ejecutada por una aplicación. Tiene un nombre, una hora de inicio,
una duración, un resultado y un contexto de ejecución como el nombre de usuario, las propiedades y el
resultado. Si la operación B inició la operación A, la operación B se establece como un elemento primario de A.
Una operación solo puede tener un elemento primario, pero puede tener muchas operaciones secundarias. Para
más información sobre las operaciones y la correlación de telemetría, vea Correlación de telemetría en Azure
En el SDK de .NET para Application Insights se describe la operación mediante la clase abstracta
OperationTelemetry y sus descendientes RequestTelemetry y DependencyTelemetry.
Seguimiento de operaciones de entrada

El SDK web de Application Insights recopila automáticamente las solicitudes HTTP para las aplicaciones ASP.NET
que se ejecutan en una canalización IIS y todas las aplicaciones ASP.NET Core. Hay soluciones admitidas por la
comunidad para otras plataformas y marcos de trabajo. Pero si la aplicación no es compatible con ninguna
solución admitida por los estándares o la comunidad, puede instrumentarla de forma manual.
Otro ejemplo que requiere seguimiento personalizado es el proceso de trabajo que recibe los elementos de la
cola. Para algunas colas, se realiza un seguimiento como dependencia de la llamada para agregar un mensaje a
esta cola. Pero la operación general que describe el procesamiento de mensajes no se recopila
automáticamente.
Ahora vamos a ver cómo se puede realizar un seguimiento de tales operaciones.
Generalmente, la tarea consiste en crear RequestTelemetry y establecer propiedades conocidas. Una vez
finalizada la operación, se realiza el seguimiento de la telemetría. En el siguiente ejemplo se muestra esta tarea.
Solicitud HTTP en una aplicación autohospedada de Owin
En este ejemplo, el contexto de seguimiento se propaga según el protocolo HTTP para la correlación. Debe
esperar recibir los encabezados que se describen ahí.
public class ApplicationInsightsMiddleware : OwinMiddleware

{
// you may create a new TelemetryConfiguration instance, reuse one you already have
// or fetch the instance created by Application Insights SDK.
private readonly TelemetryConfiguration telemetryConfiguration =
TelemetryConfiguration.CreateDefault();
private readonly TelemetryClient telemetryClient = new TelemetryClient(telemetryConfiguration);
public ApplicationInsightsMiddleware(OwinMiddleware next) : base(next) {}
public override async Task Invoke(IOwinContext context)

{
// Let's create and start RequestTelemetry.
var requestTelemetry = new RequestTelemetry
{
Name = $"{context.Request.Method} {context.Request.Uri.GetLeftPart(UriPartial.Path)}"
};
// If there is a Request-Id received from the upstream service, set the telemetry context
accordingly.
if (context.Request.Headers.ContainsKey("Request-Id"))
{
var requestId = context.Request.Headers.Get("Request-Id");
// Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
requestTelemetry.Context.Operation.Id = GetOperationId(requestId);
requestTelemetry.Context.Operation.ParentId = requestId;
}
// StartOperation is a helper method that allows correlation of

// current operations with nested operations/telemetry
// and initializes start time and duration on telemetry items.
var operation = telemetryClient.StartOperation(requestTelemetry);
// Process the request.

try
{
await Next.Invoke(context);
}
catch (Exception e)
{
requestTelemetry.Success = false;
telemetryClient.TrackException(e);
throw;
}
finally
{
// Update status code and success as appropriate.
if (context.Response != null)
{
requestTelemetry.ResponseCode = context.Response.StatusCode.ToString();
requestTelemetry.Success = context.Response.StatusCode >= 200 &&
context.Response.StatusCode <= 299;
}
else
{
requestTelemetry.Success = false;
}
// Now it's time to stop the operation (and track telemetry).

}
}
public static string GetOperationId(string id)

{
{
// Returns the root ID from the '|' to the first '.' if any.
int rootEnd = id.IndexOf('.');
if (rootEnd < 0)
rootEnd = id.Length;
int rootStart = id[0] == '|' ? 1 : 0;

return id.Substring(rootStart, rootEnd - rootStart);
}
}
El Protocolo HTTP para la correlación también declara el encabezado Correlation-Context . Pero aquí se omite
para simplificar.
Instrumentación de colas
Aunque existen el contexto de seguimiento de W3C y el protocolo HTTP para la correlación para pasar los
detalles de la correlación con la solicitud HTTP, todos los protocolos de cola tienen que definir cómo se
transmiten los mismos detalles junto con el mensaje de cola. Algunos protocolos de cola (por ejemplo, AMQP)
permiten pasar metadatos adicionales, y otros (como una cola de Azure Storage) requieren que el contexto se
codifique en la carga del mensaje.
NOTE
Todavía no se admite el seguimiento entre componentes para las colas con HTTP, si el productor y el
consumidor envían telemetría a distintos recursos de Application Insights, la experiencia de diagnósticos de
transacción y el mapa de aplicación muestran transacciones y asignaciones de un extremo a otro. En el caso de las
colas, todavía no se admite.
Cola de Service Bus

Application Insights realiza un seguimiento de las llamadas de mensajería de Service Bus con la nueva versión
3.0.0 del cliente Microsoft Azure ServiceBus para .NET y con versiones posteriores. Si usa un patrón de
controlador de mensajes para procesar mensajes, ya ha terminado: se realizará el seguimiento automático de
todas las llamadas de Service Bus que se hayan hecho mediante el servicio y se correlacionarán con otros
elementos de telemetría. Consulte el artículo sobre el seguimiento del cliente Service Bus con Microsoft
Application Insights si desea procesar los mensajes manualmente.
Si usa el paquete WindowsAzure.ServiceBus, siga leyendo; en los ejemplos siguientes se muestra cómo realizar
un seguimiento de las llamadas y correlacionarlas en Service Bus, ya que la cola de Service Bus usa el protocolo
AMQP y Application Insights no realiza un seguimiento automático de las operaciones de cola. Los
identificadores de correlación se transmiten en las propiedades del mensaje.
Poner en cola
public async Task Enqueue(string payload)
{
// StartOperation is a helper method that initializes the telemetry item
// and allows correlation of this operation with its parent and children.
var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queueName);
operation.Telemetry.Type = "Azure Service Bus";

operation.Telemetry.Data = "Enqueue " + queueName;
var message = new BrokeredMessage(payload);

// Service Bus queue allows the property bag to pass along with the message.
// We will use them to pass our correlation identifiers (and other context)
// to the consumer.
message.Properties.Add("ParentId", operation.Telemetry.Id);
message.Properties.Add("RootId", operation.Telemetry.Context.Operation.Id);
try
{
await queue.SendAsync(message);
// Set operation.Telemetry Success and ResponseCode here.

operation.Telemetry.Success = true;
}
catch (Exception e)
{
// Set operation.Telemetry Success and ResponseCode here.
operation.Telemetry.Success = false;
throw;
}
finally
{
}
}
Proceso
public async Task Process(BrokeredMessage message)
{
// After the message is taken from the queue, create RequestTelemetry to track its processing.
// It might also make sense to get the name from the message.
RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
var rootId = message.Properties["RootId"].ToString();

var parentId = message.Properties["ParentId"].ToString();
// Get the operation ID from the Request-Id (if you follow the HTTP Protocol for Correlation).
requestTelemetry.Context.Operation.Id = rootId;
requestTelemetry.Context.Operation.ParentId = parentId;
try
{
await ProcessMessage();
}
catch (Exception e)
{
throw;
}
finally
{
}
}
Cola de Azure Storage

En el ejemplo siguiente se muestra cómo realizar el seguimiento de operaciones de cola de Azure Storage y
poner en correlación la telemetría entre el productor, el consumidor y Azure Storage.
La cola de Storage tiene una API HTTP. El recolector de dependencias de Application Insights realiza el
seguimiento de todas las llamadas a la cola para las solicitudes HTTP. Se configura de forma predeterminada en
las aplicaciones ASP.NET y ASP.NET Core, con otros tipos de aplicación, puede consultar la documentación de las
aplicaciones de consola.
Es posible que también quiera poner en correlación el identificador de operación de Application Insights con el
identificador de solicitud de Storage. Para obtener información sobre cómo establecer y obtener un cliente de
solicitud de Storage y un identificador de solicitud de servidor, vea Supervisión, diagnóstico y solución de
problemas de Azure Storage.
Poner en cola
Como las colas de Storage admiten la API de HTTP, Application Insights realiza el seguimiento automático de
todas las operaciones en la cola. En muchos casos, esta instrumentación debería ser suficiente. Pero para poner
en correlación seguimientos en el lado del consumidor con seguimientos del productor, tiene que pasar un
contexto de correlación de forma similar a como se hace en el Protocolo HTTP para la correlación.
En este ejemplo se muestra cómo realizar un seguimiento de la operación Enqueue . Puede:
Poner en correlación los reintentos (si existen) : todos tienen un elemento primario común que es la
operación Enqueue . En caso contrario, se realiza su seguimiento como elementos secundarios de la solicitud
de entrada. Si hay varias solicitudes lógicas a la cola, podría ser difícil buscar qué llamada generó los
reintentos.
Poner en correlación los registros de almacenamiento (si es necesario y cuando sea necesario) :
se correlacionan con la telemetría de Application Insights.
La operación Enqueue es el elemento secundario de una operación principal (por ejemplo, una solicitud HTTP
de entrada). La llamada de dependencia HTTP es el elemento secundario de la operación Enqueue y el
descendiente de la solicitud de entrada:
public async Task Enqueue(CloudQueue queue, string message)

{
var operation = telemetryClient.StartOperation<DependencyTelemetry>("enqueue " + queue.Name);
operation.Telemetry.Type = "Azure queue";
operation.Telemetry.Data = "Enqueue " + queue.Name;
// MessagePayload represents your custom message and also serializes correlation identifiers into
payload.
// For example, if you choose to pass payload serialized to JSON, it might look like
// {'RootId' : 'some-id', 'ParentId' : '|some-id.1.2.3.', 'message' : 'your message to process'}
var jsonPayload = JsonConvert.SerializeObject(new MessagePayload
{
RootId = operation.Telemetry.Context.Operation.Id,
ParentId = operation.Telemetry.Id,
Payload = message
});
CloudQueueMessage queueMessage = new CloudQueueMessage(jsonPayload);
// Add operation.Telemetry.Id to the OperationContext to correlate Storage logs and Application

Insights telemetry.
OperationContext context = new OperationContext { ClientRequestID = operation.Telemetry.Id};
try
{
await queue.AddMessageAsync(queueMessage, null, null, new QueueRequestOptions(), context);
}
catch (StorageException e)
{
operation.Telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
operation.Telemetry.Success = false;
operation.Telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
}
finally
{
}
}
Para reducir la cantidad de telemetría que notifica la aplicación o si no quiere realizar el seguimiento de la
operación Enqueue por otras razones, use directamente la API Activity :
Cree (e inicie) una nueva Activity en lugar de iniciar la operación de Application Insights. No es necesario
asignar ninguna propiedad en este elemento, excepto el nombre de la operación.
Serialice yourActivity.Id en la carga del mensaje en lugar de operation.Telemetry.Id . También se puede
usar Activity.Current.Id .
Quitar de la cola
Al igual que Enqueue , Application Insights realiza el seguimiento automático de la solicitud HTTP a la cola de
Storage. Pero supuestamente la operación Enqueue se produce en el contexto principal, por ejemplo en un
contexto de solicitud de entrada. Los SDK de Application Insights correlacionan automáticamente esta operación
(y su elemento HTTP) con la solicitud primaria y otra telemetría notificada en el mismo ámbito.
La operación Dequeue es complicada. El SDK de Application Insights realiza automáticamente el seguimiento de
las solicitudes HTTP. Pero desconoce el contexto de correlación hasta que se analiza el mensaje. No es posible
poner en correlación la solicitud HTTP para obtener el mensaje con el resto de la telemetría, en especial cuando
se recibe más de un mensaje.
public async Task<MessagePayload> Dequeue(CloudQueue queue)
{
var operation = telemetryClient.StartOperation<DependencyTelemetry>("dequeue " + queue.Name);
operation.Telemetry.Type = "Azure queue";
operation.Telemetry.Data = "Dequeue " + queue.Name;
try
{
var message = await queue.GetMessageAsync();
}
catch (StorageException e)
{
operation.telemetry.Properties.Add("AzureServiceRequestID", e.RequestInformation.ServiceRequestID);
operation.telemetry.Success = false;
operation.telemetry.ResultCode = e.RequestInformation.HttpStatusCode.ToString();
}
finally
{
}
return null;
}
Proceso
En el ejemplo siguiente, se realiza el seguimiento de un mensaje de entrada de forma similar a cómo se realiza
en una solicitud HTTP de entrada:
public async Task Process(MessagePayload message)

{
// After the message is dequeued from the queue, create RequestTelemetry to track its processing.
RequestTelemetry requestTelemetry = new RequestTelemetry { Name = "process " + queueName };
// It might also make sense to get the name from the message.
requestTelemetry.Context.Operation.Id = message.RootId;
requestTelemetry.Context.Operation.ParentId = message.ParentId;
try
{
await ProcessMessage();
}
catch (Exception e)
{
throw;
}
finally
{
}
}
Del mismo modo, se pueden instrumentar otras operaciones de cola. Una operación de lectura se debe
instrumentalizar de una manera similar a la de una operación de quitar de la cola. La instrumentación de las
operaciones de administración de cola no es necesaria. Application Insights realiza el seguimiento de las
operaciones como HTTP y en la mayoría de los casos es suficiente.
Al instrumentar la eliminación de mensajes, asegúrese de establecer los identificadores de la operación
(correlación). Como alternativa, puede usar la API de Activity . No es necesario establecer identificadores de
operaciones en los elementos de telemetría, porque el SDK de Application Insights lo hace automáticamente:
Cree una nueva Activity después de que tenga un elemento de la cola.
Use Activity.SetParentId(message.ParentId) para poner en correlación los registros de consumidor y
productor.
Inicie la Activity .
Realice el seguimiento de las operaciones de quitar de la cola, proceso y eliminación mediante los asistentes
Start/StopOperation . Hágalo desde el mismo flujo de control asincrónico (contexto de ejecución). De esta
forma, se correlacionan correctamente.
Pare la Activity .
Use Start/StopOperation o llame a la telemetría de Track manualmente.
Tipos de dependencia
Application Insights usa el tipo de dependencia para personalizar las experiencias de la interfaz de usuario. En el
caso de las colas, reconoce los siguientes tipos de DependencyTelemetry que mejoran la experiencia de
diagnósticos de transacción:
Azure queue para colas de Azure Storage
Azure Event Hubs para Azure Event Hubs
Azure Service Bus para Azure Service Bus
Procesamiento por lotes

En algunas colas, se pueden quitar de la cola varios mensajes con una solicitud. El procesamiento de este tipo de
mensajes es supuestamente independiente y pertenece a las distintas operaciones lógicas. No es posible poner
en correlación la operación Dequeue con el mensaje determinado que va a procesarse.
Cada mensaje debe procesarse en su propio flujo de control asincrónico. Para más información, vea la sección
Seguimiento de dependencias de salida.
Tareas en segundo plano de ejecución prolongada

Algunas aplicaciones inician operaciones de larga ejecución que es posible que se deban a solicitudes del
usuario. Desde la perspectiva del seguimiento o la instrumentación, no es diferente de la instrumentación de
solicitudes o dependencias:
async Task BackgroundTask()
{
var operation = telemetryClient.StartOperation<DependencyTelemetry>(taskName);
operation.Telemetry.Type = "Background";
try
{
int progress = 0;
while (progress < 100)
{
// Process the task.
telemetryClient.TrackTrace($"done {progress++}%");
}
}
catch (Exception e)
{
throw;
}
finally
{
}
}
En este ejemplo, telemetryClient.StartOperation crea DependencyTelemetry y rellena el contexto de correlación.

Supongamos que tiene una operación principal creada por las solicitudes de entrada que programaron la
operación. Siempre que BackgroundTask se inicie en el mismo flujo de control asincrónico que una solicitud de
entrada, se correlaciona con esa operación principal. BackgroundTask y todos los elementos de telemetría
anidados se correlacionan automáticamente con la solicitud que la causó incluso después de que finalice la
solicitud.
Cuando la tarea se inicia desde el subproceso en segundo plano que no tiene ninguna operación ( Activity )
asociada a él, BackgroundTask no tiene ningún elemento primario. Pero puede tener operaciones anidadas.
Todos los elementos de telemetría notificados desde la tarea se ponen en correlación con la
DependencyTelemetry creada en BackgroundTask .
Seguimiento de dependencias de salida

Puede realizar el seguimiento de su propio tipo de dependencia o de una operación que no es compatible con
El método Enqueue de la cola de Service Bus o la cola de Storage puede servir como ejemplo de este
seguimiento personalizado.
El enfoque general para el seguimiento de dependencias personalizadas es este:
Llame al método TelemetryClient.StartOperation (extensión) que rellena las propiedades de
DependencyTelemetry que se necesitan para la correlación y algunas otras (inicio de la marca de tiempo,
duración).
Establezca otras propiedades personalizadas en DependencyTelemetry , como el nombre y cualquier otro
contexto que se necesite.
Realice una llamada de dependencia y espere.
Detenga la operación con StopOperation cuando finalice.
Controle las excepciones.
public async Task RunMyTaskAsync()
{
using (var operation = telemetryClient.StartOperation<DependencyTelemetry>("task 1"))
{
try
{
var myTask = await StartMyTaskAsync();
}
catch(...)
{
}
}
}
Desechar la operación provoca que la operación se detenga, por lo que puede hacerlo en lugar de llamar a
StopOperation .
Advertencia: en algunos casos, una excepción no controlada puede impedir la llamada a finally , por lo que
puede que no se realice un seguimiento de las operaciones.
Seguimiento y procesamiento de operaciones paralelas
StopOperation solo detiene la operación que se inició. Si la operación de ejecución actual no coincide con la que
quiere detener, StopOperation no hace nada. Es posible que suceda esta situación si se inician varias
operaciones en paralelo en el mismo contexto de ejecución:
var firstOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 1");

var firstTask = RunMyTaskAsync();
var secondOperation = telemetryClient.StartOperation<DependencyTelemetry>("task 2");

var secondTask = RunMyTaskAsync();
await firstTask;
// FAILURE!!! This will do nothing and will not report telemetry for the first operation
// as currently secondOperation is active.
telemetryClient.StopOperation(firstOperation);
await secondTask;
Asegúrese de llamar siempre a StartOperation y de procesar la operación en el mismo método async para
aislar las operaciones que se ejecutan en paralelo. Si la operación es sincrónica o no asincrónica, encapsule el
proceso y realice un seguimiento con Task.Run :
public void RunMyTask(string name)
{
using (var operation = telemetryClient.StartOperation<DependencyTelemetry>(name))
{
Process();
}
}
public async Task RunAllTasks()

{
var task1 = Task.Run(() => RunMyTask("task 1"));
var task2 = Task.Run(() => RunMyTask("task 2"));
await Task.WhenAll(task1, task2);

}
Operaciones de ApplicationInsights frente a

System.Diagnostics.Activity
System.Diagnostics.Activity representa el contexto de seguimiento distribuido y lo utilizan las plataformas y
las bibliotecas para crear y propagar el contexto dentro y fuera del proceso, así como correlacionar los
elementos de telemetría. La actividad funciona junto System.Diagnostics.DiagnosticSource , que es el mecanismo
de notificación entre la plataforma o la biblioteca para notificar de eventos interesantes (solicitudes entrantes o
salientes, excepciones, etc.).
Las actividades son los ciudadanos de primera clase en Application Insights y la recopilación automática de
dependencias y solicitudes se basa en gran medida en ellas junto con los eventos DiagnosticSource . Si crea una
actividad en la aplicación, no se producirá la creación de telemetría de Application Insights. Application Insights
debe recibir los eventos de DiagnosticSource y conocer los nombres y las cargas de los eventos para convertir
la actividad en telemetría.
Cada operación de Application Insights (solicitud o dependencia) implica Activity ; cuando se llama a
StartOperation , se crea la actividad subyacente. StartOperation es el método recomendado para realizar el
seguimiento de las telemetrías de solicitudes o de dependencias manualmente y asegurarse de que todo está
correlacionado.
Pasos siguientes
Obtenga los conceptos básicos de la correlación de telemetría en Application Insights.
Consulte cómo los datos correlacionados alimentan la experiencia de diagnósticos de transacción y el mapa
de aplicación.
Vea el modelo de datos para los tipos y el modelo de datos de Application Insights.
Notifique eventos y métricas personalizados a Application Insights.
Compruebe la configuración de la recopilación de propiedades de contexto.
Consulte el manual del usuario de System.Diagnostics.Activity para ver cómo se correlaciona la telemetría.
Automatizar informes personalizados con datos de
Azure Application Insights
Los informes periódicos ayudan a mantener informado al equipo sobre cómo van sus servicios críticos para la
empresa. Los desarrolladores, los equipos de DevOps o SRE y sus administradores pueden ser productivos con
informes automatizados que proporcionan información de forma fiable sin necesidad de que todos los usuarios
inicien sesión en el portal. Estos informes también pueden ayudar a identificar aumentos graduales de las latencias
y las velocidades de carga o error que es posible que no desencadenen ninguna regla de alertas.
Cada empresa tiene sus necesidades de informes únicas, como:
Agregaciones concretas de percentil de métricas o métricas personalizadas en un informe.
Tener diferentes informes para los resúmenes diarios, semanales y mensuales de datos para los distintos
destinatarios.
Segmentación por atributos personalizados como la región o el entorno.
Agrupar algunos recursos de IA en un único informe, incluso si pueden estar en distintas suscripciones o grupos
de recursos, etc.
Informes independientes que contienen métricas confidenciales que se envían a un público selectivo.
Informes para las partes interesadas que es posible que no tengan acceso a los recursos del portal.
NOTE
El correo electrónico de resumen semanal de Application Insights no permitía ninguna personalización y se suspenderá en
favor de las opciones personalizadas que se muestran a continuación. El último correo electrónico de resumen semanal se
enviará el 11 de junio de 2018. Configure una de las opciones siguientes para obtener informes personalizados similares (use
la consulta que se sugiere a continuación).
Para automatizar los correos electrónicos de informe personalizados

Puede consultar mediante programación datos de Application Insights para generar informes personalizados en
una programación. Las opciones siguientes pueden ayudarle a empezar rápidamente:
Automatizar informes con Microsoft Flow
Automatizar informes con Logic Apps
Use la plantilla "Resumen programado de Application Insights" de Azure Functions en el escenario
Supervisión. Esta función usa SendGrid para enviar el correo electrónico.
Consulta de ejemplo para un correo electrónico de resumen semanal
La consulta siguiente muestra la unión de varios conjuntos de datos para un correo electrónico de resumen
semanal, por ejemplo, un informe. Personalícela según sea necesario y úsela con cualquiera de las opciones
enumeradas anteriormente para automatizar un informe semanal.
let period=7d;
requests
| where timestamp > ago(period)
| summarize Row = 1, TotalRequests = sum(itemCount), FailedRequests = sum(toint(success == 'False')),
RequestsDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
| join (
dependencies
| summarize Row = 1, TotalDependencies = sum(itemCount), FailedDependencies = sum(success == 'False'),
DependenciesDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
) on Row | join (
pageViews
| summarize Row = 1, TotalViews = sum(itemCount)
) on Row | join (
exceptions
| summarize Row = 1, TotalExceptions = sum(itemCount)
) on Row | join (
availabilityResults
| summarize Row = 1, OverallAvailability = iff(isnan(avg(toint(success))), '------',
tostring(toint(avg(toint(success)) * 10000) / 100.0)),
AvailabilityDuration = iff(isnan(avg(duration)), '------', tostring(toint(avg(duration) * 100) / 100.0))
) on Row
| project TotalRequests, FailedRequests, RequestsDuration, TotalDependencies, FailedDependencies,
DependenciesDuration, TotalViews, TotalExceptions, OverallAvailability, AvailabilityDuration
Informe de resumen programado de Application Insights

1. Cree una aplicación de funciones de Azure. (La activación de Application Insights solo es necesaria si quiere
supervisar la nueva aplicación de funciones con Application Insights)
Consulte la documentación de Azure Functions para más información sobre cómo crear una aplicación de
funciones.
2. Una vez que la nueva aplicación Function App haya completado la implementación, seleccione Ir al
recurso .
3. Seleccione Nueva función .
4. Seleccione la plantilla de resumen programada de Application Insights .
NOTE
De forma predeterminada, las aplicaciones de funciones se crean con la versión 3.x del entorno en tiempo de
ejecución. Debe dirigirse a la versión del entorno de ejecución de Azure Functions 1.x para usar la plantilla de
resumen de programación de Application Insights. Vaya a Configuración > Configuración del tiempo de ejecución de
la función para cambiar la versión del entorno de ejecución.
5. Escriba una dirección de correo electrónico del destinatario correcta para el informe y seleccione Crear .
6. Seleccione la Aplicación de funciones > Características de la plataforma > Configuración .

7. Cree tres nuevas configuraciones de la aplicación con los valores correspondientes adecuados AI_APP_ID ,
AI_APP_KEY y SendGridAPI . Seleccione Guardar .
(Los valores AI_ pueden encontrarse en el acceso de API para el recurso de Application Insights sobre el cual
quiere informar. Si no tiene ninguna clave de API de Application Insights, existe la opción Crear clave de
API ).
AI_APP_ID = Id. de aplicación
AI_APP_KEY = Clave de API
SendGridAPI = Clave de API de SendGrid
NOTE
Si no tiene ninguna cuenta en SendGrid, puede crear una. Puede encontrar la documentación de SendGrid
para Azure Functions aquí. Si solo quiere una explicación básica sobre cómo configurar SendGrid y generar
una clave de API, se proporciona una al final de este artículo.
8. Seleccione Integrar y, en Salidas, haga clic en SendGrid ($return) .

9. En SendGridAPI Key App Setting (Configuración de la aplicación de clave de SendGridAPI), seleccione la
configuración de la aplicación recién creada para SendGridAPI .
10. Ejecute y pruebe la aplicación de Function App.
11. Compruebe su correo electrónico para confirmar que el mensaje se ha enviado o recibido correctamente.
SendGrid con Azure

Estos pasos se aplican solo si aún no ha configurado ninguna cuenta de SendGrid.
1. En Azure Portal, seleccione Crear un recurso , busque Ser vicio de correo electrónico SendGrid > haga
clic en Crear > y rellene las instrucciones de creación específicas de SendGrid.
2. Una vez creada, en Cuentas de SendGrid, seleccione Administrar .
3. Esto iniciará el sitio de SendGrid. Seleccione Configuración > Claves de API .
4. Crear una clave de API > Elija Create & View (Crear y ver). (Consulte la documentación de SendGrid sobre
el acceso restringido para determinar qué nivel de permisos es adecuado para la clave de API. A
continuación, se selecciona el acceso total solo como ejemplo).
5. Copie la clave completa. Este es el valor que necesita como valor de SendGridAPI en la configuración de
Function App.
Pasos siguientes
Más información sobre cómo crear consultas de análisis.
Obtenga más información sobre consultar mediante programación los datos de Application Insights.
Más información sobre Microsoft Flow.
Diagnóstico de excepciones en aplicaciones
Las excepciones en la aplicación web en directo se notifican mediante Application Insights. Puede
correlacionar las solicitudes con error con excepciones y otros eventos en el cliente y en el servidor, de
modo que pueda diagnosticar rápidamente las causas.
Configuración de informes de excepciones

Para que se notifiquen excepciones desde su aplicación de servidor:
Aplicaciones web de Azure: Agregue la extensión de Application Insights.
Aplicaciones hospedadas en IIS en máquina virtual de Azure y conjunto de escalado de
máquinas virtuales de Azure: Incorporación de la extensión de supervisión de aplicaciones
Instale el SDK de Application Insights en su código de aplicación.
Servidores web IIS: Ejecute el agente de Application Insights; o
Aplicaciones web de Java: Habilite el agente Java
Instale el fragmento de código de JavaScript en las páginas web para capturar las excepciones
del explorador.
En algunos marcos de aplicaciones o con algunas opciones de configuración, debe realizar
algunos pasos adicionales para capturar más excepciones:
Formularios web
MVC
API web 1.*
API web 2.*
WCF
Este artículo se centra específicamente en aplicaciones de .NET Framework desde la perspectiva
de un ejemplo de código. Algunos de los métodos que funcionan en .NET Framework son
obsoletos en el SDK de .NET Core. Vea la documentación del SDK de .NET Core si tiene una
aplicación .NET Core.
Diagnóstico de excepciones mediante Visual Studio

Abra la solución de aplicación en Visual Studio para ayudar con la depuración.
Ejecute la aplicación, bien en el servidor o en el equipo de desarrollo mediante F5.
Abra la ventana Búsqueda de Application Insights en Visual Studio y configúrela para mostrar los
eventos de la aplicación. Durante la depuración, puede hacer esto haciendo clic simplemente en el
botón de Application Insights.
Observe que puede filtrar el informe para mostrar solo excepciones.
¿No se muestra ninguna excepción? Consulte Captura de excepciones.
Haga clic en un informe de excepciones para mostrar su seguimiento de la pila. Haga clic en una
referencia de línea en el seguimiento de la pila para abrir el archivo de código pertinente.
En el código, tenga en cuenta que CodeLens muestra datos de las excepciones:
Diagnóstico de errores mediante el Portal de Azure

Application Insights incluye una experiencia APM seleccionada para ayudar a diagnosticar errores en
las aplicaciones supervisadas. Para empezar, haga clic en la opción Errores del menú de recursos de
Application Insights situado en la sección de investigación. Debería ver una vista de pantalla completa
que muestra las tendencias de índice de errores de sus solicitudes: cuántas de ellas generan errores y
cuántos usuarios se ven afectados. A la derecha, verá algunas de las distribuciones más útiles
específicas de la operación con error seleccionada, incluidos los tres códigos de respuesta principales,
los tres tipos principales de excepción y los tres tipos principales de dependencia con error.
A continuación, con un solo clic, puede revisar ejemplos representativos de cada uno de estos
subconjuntos de operaciones. En concreto, para diagnosticar excepciones, puede hacer clic en el
recuento de una excepción determinada para que se muestre con la hoja de detalles Transacción
completa, como esta:
Como alternativa , en lugar de observar las excepciones de una operación específica con errores,
puede empezar desde la vista general de excepciones y cambiar a la pestaña Excepciones en la parte
superior. Aquí puede ver todas las excepciones que se recopilan para la aplicación supervisada.
¿No se muestra ninguna excepción? Consulte Captura de excepciones.
Personalización del seguimiento y del registro de datos

Para obtener datos de diagnóstico específicos de su aplicación, puede insertar código para enviar sus
propios datos de telemetría. Esto aparece en la búsqueda de diagnóstico junto con la solicitud, vista de
página y otros datos que se recopilan automáticamente.
Tiene varias opciones:
TrackEvent() normalmente se usa para supervisar patrones de uso, pero los datos que envía
también aparecen en Eventos personalizados en la búsqueda de diagnósticos. Los eventos tienen
nombre y pueden llevar propiedades de cadena y métricas numéricas en las que puede filtrar las
búsquedas de diagnósticos.
TrackTrace() le permite enviar datos más grandes, como la información de POST.
TrackException() envía seguimientos de la pila. Más información sobre excepciones.
Si ya usa un marco de registro como Log4Net o NLog, puede capturar aquellos registros y verlos
en la búsqueda de diagnósticos junto con datos de solicitud y excepción.
Para ver estos eventos, abra Buscar en el menú de la izquierda, seleccione el menú desplegable Tipos
de evento y elija Evento personalizado, Seguimiento o Excepción.
NOTE
Si la aplicación genera mucha telemetría, el módulo de muestreo adaptable reducirá automáticamente el
volumen que se envía al portal mediante el envío de únicamente una fracción representativa de eventos. Los
eventos que forman parte de la misma operación se seleccionarán o se anulará su selección como grupo, por lo
que puede navegar entre los eventos relacionados. Más información sobre el muestreo.
Visualización de los datos de solicitud POST

Los detalles de la solicitud no incluyen los datos enviados a la aplicación en una llamada a POST. Para
que se notifiquen estos datos:
Instale el SDK en su proyecto de aplicación.
Inserte código en la aplicación para llamar a Microsoft.ApplicationInsights.TrackTrace(). Envíe los
datos de POST en el parámetro de mensaje. Hay un límite en cuanto al tamaño permitido, así que
debe intentar enviar únicamente los datos fundamentales.
Cuando investigue una solicitud con error, busque los seguimientos asociados.
Captura de excepciones y datos de diagnóstico relacionados
En primer lugar, no verá en el portal todas las excepciones que provocan errores en su aplicación. Verá
las excepciones del explorador (si usa el SDK de JavaScript en sus páginas web). Pero la mayoría de las
excepciones de servidor las detecta IIS y debe escribir algo de código para verlas.
Puede:
Registrar excepciones explícitamente insertando código en los controladores de excepciones
para notificar las excepciones.
Capturar excepciones automáticamente configurando su marco de ASP.NET. Las adiciones
necesarias son diferentes para los distintos tipos de marco.
Notificación de excepciones explícitamente

La manera más sencilla consiste en insertar una llamada a TrackException() en un controlador de
excepciones.
try
{ ...
}
catch (ex)
{
appInsights.trackException(ex, "handler loc",
{Game: currentGame.Name,
State: currentGame.State.ToString()});
}
var telemetry = new TelemetryClient();

...
try
{ ...
}
{
// Set up some properties:
{{"Game", currentGame.Name}};
var measurements = new Dictionary <string, double>

{{"Users", currentGame.Users.Count}};
// Send the exception telemetry:

telemetry.TrackException(ex, properties, measurements);
}
Dim telemetry = New TelemetryClient
...
Try
...
Catch ex as Exception
' Set up some properties:
Dim properties = New Dictionary (Of String, String)
properties.Add("Game", currentGame.Name)
Dim measurements = New Dictionary (Of String, Double)

measurements.Add("Users", currentGame.Users.Count)
' Send the exception telemetry:

telemetry.TrackException(ex, properties, measurements)
End Try
Los parámetros de las propiedades y las medidas son opcionales, pero son útiles para filtrar y agregar
información adicional. Por ejemplo, si tiene una aplicación que se puede ejecutar varios juegos, podría
buscar todos los informes de excepción relacionados con un juego en particular. Puede agregar tantos
elementos como desee para cada diccionario.
Excepciones de explorador
Se notifican la mayoría de las excepciones de explorador.
Si la página web incluye archivos de script de redes de entrega de contenido o de otros dominios,
asegúrese de que la etiqueta de script tenga el atributo crossorigin="anonymous" , y que el servidor
envíe encabezados CORS. Esto le permitirá obtener un seguimiento de pila y los detalles de las
excepciones no controladas de JavaScript de estos recursos.
Reutilización del cliente de telemetría

NOTE
Se recomienda crear una instancia de TelemetryClient una vez y reutilizarla durante todo el ciclo de vida de una
aplicación.
A continuación se muestra un ejemplo de uso correcto de TelemetryClient.
public class GoodController : ApiController

{
// OK
private static readonly TelemetryClient telemetryClient;
static GoodController()
{
telemetryClient = new TelemetryClient();
}
}
Formularios web
Para los formularios web, el módulo HTTP podrá recopilar las excepciones cuando no haya ningún
redireccionamiento configurado con CustomErrors.
Pero si tiene redireccionamientos activos, agregue las siguientes líneas a la función Application_Error
en Global.asax.cs. (Agregue un archivo Global.asax si aún no tiene uno.)
void Application_Error(object sender, EventArgs e)
{
if (HttpContext.Current.IsCustomErrorEnabled && Server.GetLastError () != null)
{
var ai = new TelemetryClient(); // or re-use an existing instance
ai.TrackException(Server.GetLastError());
}
}
MVC
A partir del SDK web de Application Insights versión 2.6 (beta3 y posterior), Application Insights
recopila excepciones no controladas producidas automáticamente en los métodos de controladores
MVC 5+. Si anteriormente ha agregado un controlador personalizado para realizar el seguimiento de
tales excepciones (como se describe en los ejemplos siguientes), puede quitarlo para impedir el
seguimiento de excepciones por duplicado.
Hay un número de casos que los filtros de excepciones no pueden procesar. Por ejemplo:
Excepciones iniciadas por constructores del controlador.
Excepciones iniciadas por controladores de mensajes.
Excepciones iniciadas durante el enrutamiento.
Excepciones iniciadas durante la serialización del contenido de respuesta.
Excepción que se produce durante el inicio de la aplicación.
Excepción que se produce en tareas en segundo plano.
Es necesario seguir realizando el seguimiento de todas las excepciones controladas por la aplicación
manualmente. Las excepciones no controladas que se originan en los controladores dan lugar
normalmente a respuestas 500 "Error interno del servidor". Si dicha respuesta se creó manualmente
como resultado de una excepción controlada (o sin ninguna excepción en absoluto), se realiza su
seguimiento en la telemetría de la solicitud correspondiente ResultCode 500; sin embargo, el SDK de
Application Insights no puede realizar el seguimiento de la excepción correspondiente.
Compatibilidad con versiones anteriores
Si usa MVC 4 (y anterior) del SDK web de Application Insights 2.5 (y anterior), consulte los siguientes
ejemplos para realizar el seguimiento de las excepciones.
Si la configuración de CustomErrors es Off , entonces habrá excepciones disponibles para que las
recopile el módulo HTTP. Sin embargo, si es RemoteOnly (valor predeterminado), o On , la excepción se
desactivará y no estará disponible para que Application Insights la recopile automáticamente. Para
corregir este problema, invalide la clase System.Web.Mvc.HandleErrorAttribute y aplique la clase
invalidada como se muestra a continuación para las diferentes versiones de MVC (origen de GitHub):
using System;
using System.Web.Mvc;
namespace MVC2App.Controllers
{
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true,
AllowMultiple = true)]
public class AiHandleErrorAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext filterContext)
{
if (filterContext != null && filterContext.HttpContext != null &&
filterContext.Exception != null)
{
//If customError is Off, then AI HTTPModule will report the exception
if (filterContext.HttpContext.IsCustomErrorEnabled)
{ //or reuse instance (recommended!). see note above
var ai = new TelemetryClient();
ai.TrackException(filterContext.Exception);
}
}
base.OnException(filterContext);
}
}
}
MVC 2
Sustituya el atributo HandleError por el nuevo atributo en los controladores.
namespace MVC2App.Controllers
{
[AiHandleError]
public class HomeController : Controller
{
...
Ejemplo
MVC 3
Registrar AiHandleErrorAttribute como filtro global de Global.asax.cs:
public class MyMvcApplication : System.Web.HttpApplication

{
{
filters.Add(new AiHandleErrorAttribute());
}
...
Ejemplo
MVC 4, MVC5
Registrar AiHandleErrorAttribute como filtro global en FilterConfig.cs:
public class FilterConfig
{
{
// Default replaced with the override to track unhandled exceptions
filters.Add(new AiHandleErrorAttribute());
}
}
Ejemplo
API Web
A partir del SDK web de Application Insights versión 2.6 (beta3 y posterior), Application Insights
recopila excepciones no controladas producidas automáticamente en los métodos de controladores
para WebAPI 2+. Si anteriormente ha agregado un controlador personalizado para realizar el
seguimiento de tales excepciones (como se describe en los ejemplos siguientes), puede quitarlo para
impedir el seguimiento de excepciones por duplicado.
Hay un número de casos que los filtros de excepciones no pueden procesar. Por ejemplo:
Excepciones iniciadas por constructores del controlador.
Excepciones iniciadas por controladores de mensajes.
Excepciones iniciadas durante el enrutamiento.
Excepciones iniciadas durante la serialización del contenido de respuesta.
Excepción que se produce durante el inicio de la aplicación.
Excepción que se produce en tareas en segundo plano.
Es necesario seguir realizando el seguimiento de todas las excepciones controladas por la aplicación
manualmente. Las excepciones no controladas que se originan en los controladores dan lugar
normalmente a respuestas 500 "Error interno del servidor". Si dicha respuesta se creó manualmente
como resultado de una excepción controlada (o sin ninguna excepción en absoluto), se realiza su
seguimiento en la telemetría de la solicitud correspondiente ResultCode 500; sin embargo, el SDK de
Application Insights no puede realizar el seguimiento de la excepción correspondiente.
Compatibilidad con versiones anteriores
Si usa WebAPI 1 (y anterior) del SDK web de Application Insights 2.5 (y anterior), consulte los
siguientes ejemplos para realizar el seguimiento de las excepciones.
Web API 1.x
Invalidar System.Web.Http.Filters.ExceptionFilterAttribute:
using System.Web.Http.Filters;
namespace WebAPI.App_Start
{
public class AiExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext actionExecutedContext)
{
if (actionExecutedContext != null && actionExecutedContext.Exception != null)
{ //or reuse instance (recommended!). see note above
ai.TrackException(actionExecutedContext.Exception);
}
base.OnException(actionExecutedContext);
}
}
}
Podría agregar este atributo invalidado a controladores específicos o agregarlo a la configuración de

filtros globales en la clase WebApiConfig:
using WebApi1.x.App_Start;
namespace WebApi1.x
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(name: "DefaultApi", routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional });
...
config.EnableSystemDiagnosticsTracing();
// Capture exceptions for Application Insights:

config.Filters.Add(new AiExceptionFilterAttribute());
}
}
}
Ejemplo
Web API 2.x
Agregue una implementación de IExceptionLogger:
using System.Web.Http.ExceptionHandling;
namespace ProductsAppPureWebAPI.App_Start
{
public class AiExceptionLogger : ExceptionLogger
{
public override void Log(ExceptionLoggerContext context)
{
if (context !=null && context.Exception != null)
{//or reuse instance (recommended!). see note above
ai.TrackException(context.Exception);
}
base.Log(context);
}
}
}
Agregue lo siguiente a los servicios en WebApiConfig:
using System.Web.Http.ExceptionHandling;
using ProductsAppPureWebAPI.App_Start;
namespace WebApi2WithMVC
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// Web API configuration and services
// Web API routes

config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.Services.Add(typeof(IExceptionLogger), new AiExceptionLogger());
}
}
}
Ejemplo
Como alternativa, puede:
1. Sustituir el único ExceptionHandler por una implementación personalizada de IExceptionHandler.
Solo se llama a este controlador de excepciones cuando el marco es aún capaz de seleccionar el
mensaje de respuesta que se enviará (no cuando se anula la conexión, por ejemplo)
2. Los filtros de excepciones (como se describe en la sección sobre controladores de Web API 1.x
anteriores) no se llaman en todos los casos.
WCF
Agregue una clase que extienda el atributo y que implemente IErrorHandler y IServiceBehavior.
using System;
using System.Collections.Generic;
using System.Linq;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Web;
namespace WcfService4.ErrorHandling
{
public class AiLogExceptionAttribute : Attribute, IErrorHandler, IServiceBehavior
{
public void AddBindingParameters(ServiceDescription serviceDescription,
System.ServiceModel.ServiceHostBase serviceHostBase,
System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints,
System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
{
}
public void ApplyDispatchBehavior(ServiceDescription serviceDescription,

System.ServiceModel.ServiceHostBase serviceHostBase)
{
foreach (ChannelDispatcher disp in serviceHostBase.ChannelDispatchers)
{
disp.ErrorHandlers.Add(this);
}
}
public void Validate(ServiceDescription serviceDescription,

System.ServiceModel.ServiceHostBase serviceHostBase)
{
}
bool IErrorHandler.HandleError(Exception error)

{//or reuse instance (recommended!). see note above
ai.TrackException(error);
return false;
}
void IErrorHandler.ProvideFault(Exception error,

System.ServiceModel.Channels.MessageVersion version,
ref System.ServiceModel.Channels.Message fault)
{
}
}
}
Add the attribute to the service implementations:
namespace WcfService4
{
[AiLogException]
public class Service1 : IService1
{
...
Ejemplo
Contadores de rendimiento de excepciones

Si tiene instalado el agente de Application Insights en el servidor, puede obtener un gráfico de la tasa
de excepciones, medida por .NET. Esto incluye las excepciones de .NET, tanto controladas como no
controladas.
Abra una pestaña del Explorador de métricas, agregue un nuevo gráfico y seleccione Tasa de
excepciones , que aparece debajo de Contadores de rendimiento.
.NET framework calcula la tasa contando el número de excepciones producidas en un intervalo y
dividiéndolo por la duración del intervalo de tiempo.
Esto es diferente del recuento de "Excepciones" calculado por el portal de Application Insights
contando los informes de TrackException. Los intervalos de muestreo son diferentes y el SDK no envía
informes de TrackException para todas las excepciones, controladas y no controladas.
Pasos siguientes
Supervisar REST, SQL y otras llamadas a las dependencias
Supervisar los tiempos de carga de página, las excepciones del explorador y las llamadas AJAX
Supervisar los contadores de rendimiento
Exploración de los registros de seguimiento de
.NET, .NET Core y Python en Application
Insights
Envíe registros de seguimiento de diagnóstico para la aplicación ASP.NET/ASP.NET Core desde ILogger,
NLog, log4Net o System.Diagnostics.Trace a Azure Application Insights. En el caso de las aplicaciones de
Python, envíe registros de seguimiento de diagnóstico mediante AzureLogHandler en OpenCensus para
Python para Azure Monitor. Después, puede explorarlos y buscar en ellos. Estos registros se combinan
con los otros archivos de registro procedentes de su aplicación, de modo que pueda identificar los
seguimientos asociados con cada solicitud de usuario y correlacionarlos con otros eventos e informes
de excepciones.
NOTE
¿Necesita el módulo de captura de registros? Es un adaptador útil para registradores de terceros, pero si aún no
usa NLog, log4Net o System.Diagnostics.Trace, considere la posibilidad de llamar directamente a Application
Insights TrackTrace() .
Instalación del registro en la aplicación

Instale el marco de registro elegido en el proyecto, lo que debería producir una entrada en app.config o
web.config.
<configuration>
<system.diagnostics>
<trace>
<listeners>
<add name="myAppInsightsListener"
type="Microsoft.ApplicationInsights.TraceListener.ApplicationInsightsTraceListener,
Microsoft.ApplicationInsights.TraceListener" />
</listeners>
</trace>
</system.diagnostics>
</configuration>
Configuración de Application Insights para recopilar registros

Si todavía no lo ha hecho, agregue Application Insights a su proyecto. Verá una opción para incluir el
compilador de registros.
También puede hacer clic con el botón derecho en el proyecto en el Explorador de soluciones para
configurar Application Insights . Seleccione la opción Configure trace collection (Configurar
recolección de seguimientos).
NOTE
¿No aparece ningún menú de Application Insights ni ninguna opción de recopilador de registros? Pruebe la
Instalación manual
Utilice este método si el tipo de proyecto no es compatible con el programa de instalación de
Application Insights (por ejemplo, un proyecto de escritorio de Windows).
1. Si planea usar log4Net o NLog, instálelo en su proyecto.
2. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y seleccione
Administrar paquetes NuGet .
3. Busque "Application Insights".
4. Seleccione uno de los siguientes paquetes:
Para ILogger: Microsoft.Extensions.Logging.ApplicationInsights nuget v2.15.0
Para NLog: Microsoft.ApplicationInsights.NLogTarget nuget v2.15.0
Para Log4Net: Microsoft.ApplicationInsights.Log4NetAppender nuget v2.15.0
Para System.Diagnostics: Microsoft.ApplicationInsights.TraceListener nuget v2.15.0
Microsoft.ApplicationInsights.DiagnosticSourceListener nuget v2.15.0
Microsoft.ApplicationInsights.EtwCollector nuget v2.15.0
Microsoft.ApplicationInsights.EventSourceListener nuget v2.15.0
El paquete NuGet instala los ensamblados necesarios y, si es aplicable, modifica el archivo web.config o
app.config.
ILogger
Para ver algunos ejemplos de uso de la implementación de ILogger para Application Insights con
aplicaciones de consola y de ASP.NET Core, vea ApplicationInsightsLoggerProvider para registros
ILogger de .NET Core.
Insertar llamadas de registro de diagnóstico

Si usa System.Diagnostics.Trace, una llamada típica sería:
System.Diagnostics.Trace.TraceWarning("Slow response - database01");
Si prefiere log4net o NLog, use lo siguiente:
logger.Warn("Slow response - database01");
Uso de eventos EventSource

Puede configurar eventos System.Diagnostics.Tracing.EventSource para enviarse a Application Insights
como seguimientos. Primero, instale el paquete de NuGet
Microsoft.ApplicationInsights.EventSourceListener . Seguidamente, edite la sección TelemetryModules
del archivo ApplicationInsights.config.
<Add Type="Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule,
Microsoft.ApplicationInsights.EventSourceListener">
<Sources>
<Add Name="MyCompany" Level="Verbose" />
</Sources>
</Add>
En cada origen, puede establecer los siguientes parámetros:

Name especifica el nombre del evento EventSource que se recopilará.
Level especifica el nivel de registro que se recopilará: Critical, Error, Informational, LogAlways,
Verbose o Warning.
Keywords (opcional) especifica el valor del entero de combinaciones de palabras clave que se usará.
Uso de eventos DiagnosticSource

Puede configurar eventos System.Diagnostics.DiagnosticSource para enviarlos a Application Insights
como seguimientos. Primero, instale el paquete de NuGet
Microsoft.ApplicationInsights.DiagnosticSourceListener . Después, edite la sección "TelemetryModules"
del archivo ApplicationInsights.config.
<Add
Type="Microsoft.ApplicationInsights.DiagnosticSourceListener.DiagnosticSourceTelemetryModule,
Microsoft.ApplicationInsights.DiagnosticSourceListener">
<Sources>
<Add Name="MyDiagnosticSourceName" />
</Sources>
</Add>
Para cada instancia de DiagnosticSource que quiera seguir, agregue una entrada con el atributo Name
establecido con el nombre de la instancia DiagnosticSource.
Uso de eventos ETW

Puede configurar eventos de Seguimiento de eventos para Windows (ETW) para enviarse a Application
Insights como seguimientos. Primero, instale el paquete de NuGet
Microsoft.ApplicationInsights.EtwCollector . Después, edite la sección "TelemetryModules" del archivo
ApplicationInsights.config.
NOTE
Solo se pueden recopilar eventos ETW si el proceso que hospeda el SDK se ejecuta bajo una identidad que sea
miembro de Usuarios del registro de rendimiento o Administradores.
<Add Type="Microsoft.ApplicationInsights.EtwCollector.EtwCollectorTelemetryModule,
Microsoft.ApplicationInsights.EtwCollector">
<Sources>
<Add ProviderName="MyCompanyEventSourceName" Level="Verbose" />
</Sources>
</Add>
En cada origen, puede establecer los siguientes parámetros:

ProviderName es el nombre del proveedor ETW que se recopilará.
ProviderGuid especifica el GUID del proveedor ETW que se recopilará. Se puede usar en lugar de
ProviderName .
Level establece el nivel de registro que se recopilará. Puede ser Critical, Error, Informational,
LogAlways, Verbose o Warning.
Keywords (opcional) establece el valor del entero de combinaciones de palabras clave que se usará.
Uso de la API de seguimiento directamente

Puede llamar directamente a la API de seguimiento de Application Insights. Los adaptadores de registro
usan esta API.
Por ejemplo:

telemetry.TrackTrace("Slow response - database01");
Una ventaja de TrackTrace es que puede colocar datos relativamente largos en el mensaje. Por ejemplo,
aquí puede codificar datos POST.
También puede agregar un nivel de gravedad al mensaje. Además, al igual que con otra telemetría,
puede agregar valores de propiedad para ayudar a filtrar o buscar distintos conjuntos de seguimientos.
Por ejemplo:

telemetry.TrackTrace("Slow database response",
SeverityLevel.Warning,
new Dictionary<string,string> { {"database", db.ID} });
Esto permitiría filtrar fácilmente en Búsqueda todos los mensajes de un determinado nivel de gravedad
relativos a una determinada base de datos.
AzureLogHandler para OpenCensus para Python

El controlador de registro de Azure Monitor permite exportar registros de Python a Azure Monitor.
Instrumente la aplicación con el SDK de OpenCensus para Python para Azure Monitor.
En este ejemplo se muestra cómo enviar un registro de nivel de advertencia a Azure Monitor.
import logging
logger.addHandler(AzureLogHandler(connection_string='InstrumentationKey=<your-instrumentation_key-
here>'))
logger.warning('Hello, World!')
Explorar los registros

Ejecute la aplicación en modo de depuración o impleméntela para que esté activa.
En el panel de información general de su aplicación, en el portal de Application Insights, seleccione
Buscar.
Por ejemplo, puede:
Filtrar por seguimientos de registro o por elementos con determinadas propiedades.
Inspeccionar un elemento específico en detalle
Buscar otros datos de registro del sistema que se relacionen con la misma solicitud de usuario (tiene
el mismo OperationId).
Guardar la configuración de una página como favorita.
NOTE
Si usa el SDK de Application Insights para ASP.NET versión 2.0.0-beta3 o posterior y la aplicación envía una gran
cantidad de datos, la característica de muestreo adaptativo puede operar y enviar solamente una parte de los
datos de telemetría. Aprenda más sobre el muestreo.
¿Cómo se puede hacer para Java?
En la instrumentación sin código de Java (recomendado) donde los registros se recopilan de forma
predefinida, use el agente Java 3.0.
Si usa el SDK de Java, utilice los adaptadores de registro de Java.
No aparece la opción de Application Insights en el menú contextual del proyecto
Asegúrese de que Developer Analytics Tools está instalado en el equipo de desarrollo. En Visual
Studio, en Herramientas > Extensiones y actualizaciones , busque Developer Analytics Tools .
Si no se encuentra en la pestaña Instalado , abra la pestaña En línea e instálelo.
Podría tratarse de un tipo de proyecto que no es compatible con Developer Analytics Tools. Use la
instalación manual.
No aparece la opción de adaptador de registro en la herramienta de configuración
Instale primero la plataforma de registro.
Si usa System.Diagnostics.Trace, asegúrese de que lo ha configurado en web.config.
Asegúrese de que tiene la última versión de Application Insights. En Visual Studio, vaya a
Herramientas > Extensiones y actualizaciones y abra la pestaña Actualizaciones . Si
Developer Analytics Tools está instalado, selecciónelo para actualizarlo.
Aparece el mensaje de error "La clave de instrumentación no puede estar vacía"
Probablemente haya instalado el paquete NuGet del adaptador de registro sin instalar Application
Insights. En el Explorador de soluciones, haga clic con el botón derecho en ApplicationInsights.config y
seleccione Actualizar Application Insights . Se le pedirá que inicie sesión en Azure y que cree un
recurso de Application Insights o que vuelva a usar uno existente. Esto debería corregir el problema.
Puedo ver seguimientos en la búsqueda de diagnóstico, pero no otros eventos
El paso de todos los eventos y solicitudes por la canalización puede llevar un rato.
¿Qué cantidad de datos se conserva?
Hay varios factores que afectan a la cantidad de datos que se conservan. Para obtener más información,
vea la sección Límites de la página de métricas de eventos de cliente.
No veo algunas entradas del registro que esperaba
Si usa el SDK de Application Insights para ASP.NET versión 2.0.0-beta3 o posterior y la aplicación envía
grandes cantidades de datos, la característica de muestreo adaptativo puede operar y enviar solamente
una parte de los datos de telemetría. Aprenda más sobre el muestreo.
Pasos siguientes
Diagnóstico de errores y excepciones en ASP.NET
Más información sobre la búsqueda
Configuración de pruebas de disponibilidad y de capacidad de respuesta
Contadores de rendimiento de sistema en
Windows proporciona una amplia variedad de contadores de rendimiento, como la ocupación de la CPU,
memoria, disco y uso de la red. También puede definir sus propios contadores de rendimiento. La colección
de contadores de rendimiento es compatible siempre que se aplicación se ejecute en IIS en un host local o en
una máquina virtual para la que tenga acceso administrativo. Aunque las aplicaciones que se ejecutan como
Azure Web Apps no tienen acceso directo a los contadores de rendimiento, Application Insights recopila un
subconjunto de contadores disponibles.
Visualización de contadores
El panel Métricas muestra el conjunto predeterminado de contadores de rendimiento.
Los contadores predeterminados actuales que se configuran para la recopilación para aplicaciones web de
ASP.NET/ASP.NET Core son los siguientes:
% de Proceso\Tiempo de procesador
% de Proceso\Tiempo de procesador normalizado
Memoria\Bytes disponibles
Solicitudes de ASP.NET/segundo
Excepciones de .NET CLR iniciadas/segundo
Tiempo de ejecución de solicitudes de aplicaciones ASP.NET
Proceso\Bytes privados
Proceso\Bytes de datos de E/S por segundo
Aplicaciones ASP.NET\Solicitudes en la cola de aplicaciones
Procesador(_Total)\% de tiempo del procesador
Adición de contadores
Si el contador de rendimiento que quiere no está incluido en la lista de métricas, puede agregarlo.
1. Averigüe qué contadores están disponibles en el servidor mediante este comando de PowerShell en el
servidor local:
Get-Counter -ListSet *
(Consulte Get-Counter ).
2. Abra ApplicationInsights.config.
Si agrega Application Insights a la aplicación durante el desarrollo, edite ApplicationInsights.config
en el proyecto y vuelva a implementarlo en los servidores.
3. Edite la directiva del recopilador de rendimiento:
<Add
Type="Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule,
<Counters>
<Add PerformanceCounter="\Objects\Processes"/>
<Add PerformanceCounter="\Sales(photo)\# Items Sold" ReportAs="Photo sales"/>
</Counters>
</Add>
NOTE
Las aplicaciones de ASP.NET Core no tienen ApplicationInsights.config y, por lo tanto, el método anterior no es
válido para las aplicaciones de ASP.NET Core.
Puede capturar tanto los contadores estándar como los que ha implementado usted mismo.
\Objects\Processes es un ejemplo de contador estándar que está disponible en todos los sistemas Windows.
\Sales(photo)\# Items Sold es un ejemplo de contador personalizado que podría implementarse en un
servicio web.
El formato es \Category(instance)\Counter" o, para las categorías que no tienen instancias, simplemente
\Category\Counter .
ReportAs es necesario para los nombres de contadores que no coinciden [a-zA-Z()/-_ \.]+ : es decir, que
contienen caracteres que no están en los siguientes conjuntos: letras, paréntesis, barra diagonal, guión,
subrayado, espacio, punto.
Si especifica una instancia, se recopilará como una dimensión "CounterInstanceName" de la métrica
notificada.
Recopilación de contadores de rendimiento en el código para aplicaciones web de ASP.NET o aplicaciones
de consola de .NET/.NET Core
Para recopilar contadores de rendimiento del sistema y enviarlos a Application Insights, puede adaptar el
siguiente fragmento:
var perfCollectorModule = new PerformanceCollectorModule();

perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Process([replace-with-application-process-name])\Page Faults/sec", "PageFaultsPerfSec"));
perfCollectorModule.Initialize(TelemetryConfiguration.Active);
También puede hacer lo mismo con las métricas personalizadas que haya creado:
var perfCollectorModule = new PerformanceCollectorModule();
perfCollectorModule.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Sales(photo)\# Items Sold", "Photo sales"));
perfCollectorModule.Initialize(TelemetryConfiguration.Active);
Recopilación de contadores de rendimiento en el código para aplicaciones web de ASP.NET Core

Modifique el método ConfigureServices en su clase Startup.cs como aparece a continuación.

{
// The following configures PerformanceCollectorModule.

services.ConfigureTelemetryModule<PerformanceCollectorModule>((module, o) =>
{
// the application process name could be "dotnet" for ASP.NET Core self-hosted
applications.
module.Counters.Add(new PerformanceCounterCollectionRequest(
@"\Process([replace-with-application-process-name])\Page Faults/sec", "DotnetPageFaultsPerfSec"));
});
}
Contadores de rendimiento en Analytics

Puede buscar y mostrar informes de contador de rendimiento en Analytics.
El esquema performanceCounters expone category , el nombre de counter y el nombre de instance de
cada contador de rendimiento. En la telemetría de cada aplicación, solo se ven los contadores de dicha
aplicación. Por ejemplo, para ver qué contadores están disponibles:
(Aquí "Instance" hace referencia a la instancia de contador de rendimiento, no al rol ni a la instancia de

máquina de servidor. El nombre de la instancia del contador de rendimiento normalmente segmenta
contadores, como el tiempo de procesador por el nombre del proceso o la aplicación).
Para obtener un gráfico de la memoria disponible en un período reciente:
Al igual que otros datos de telemetría, performanceCounters también tiene una columna
cloud_RoleInstance que indica la identidad de la instancia del servidor host en el que se ejecuta la aplicación.
Por ejemplo, para comparar el rendimiento de una aplicación en distintas máquinas:
Recuentos de ASP.NET y Application Insights

¿En qué se diferencian la tasa de excepciones y las métricas de excepciones?
tasa de excepciones es un contador de rendimiento del sistema. El CLR cuenta todas las excepciones
controladas y no controladas que se producen, y divide el total de un intervalo de muestreo entre la
duración del intervalo. El SDK de Application Insights recopila este resultado y lo envía al portal.
Excepciones es un recuento de los informes de TrackException recibidos a través del portal en el
intervalo de muestreo del gráfico. Solo incluye las excepciones controladas para las que ha escrito
llamadas a TrackException en el código y no incluye todas las excepciones no controladas.
Contadores de rendimiento para aplicaciones que se ejecutan en

Azure Web Apps
Las aplicaciones de ASP.NET y ASP.NET Core implementadas en Azure Web Apps se ejecutan en un entorno
de espacio aislado especial. Este entorno no permite el acceso directo a los contadores de rendimiento del
sistema. Sin embargo, se expone un subconjunto limitado de contadores como variables de entorno como se
describe aquí. El SDK de Application Insights para ASP.NET y ASP.NET Core recopila contadores de
rendimiento desde Azure Web Apps desde estas variables de entorno especiales. Solo un subconjunto de
contadores está disponibles en este entorno, y puede encontrar la lista completa aquí.
Contadores de rendimiento en aplicaciones de ASP.NET Core

La compatibilidad con los contadores de rendimiento en ASP.Net Core es limitada:
en Azure Web Apps (Windows).
en Windows y tiene como destino NETSTANDARD2.0 o una versión posterior.
Para las aplicaciones que tienen como destino .NET Framework, todas las versiones del SDK admiten
Las versiones 2.8.0 y posteriores del SDK admiten el contador de CPU/memoria de Linux. No se admite
ningún otro contador en Linux. La manera recomendada de obtener contadores del sistema en Linux (y
otros entornos que no son Windows) es mediante EventCounters.
Alertas
Al igual que otras métricas, puede establecer una alerta para advertirle si un contador de rendimiento queda
fuera de un límite especificado. Abra el panel de alertas y haga clic en Agregar alerta.
Pasos siguientes
Seguimiento de dependencias
Seguimiento de excepciones
Introducción a los contadores de eventos
EventCounter es el mecanismo de .NET/.NET Core para publicar y consumir contadores o estadísticas. En este
documento se proporciona información general sobre EventCounters y ejemplos sobre cómo publicarlos y
consumirlos. Los contadores de eventos se admiten en todas las plataformas de sistema operativo (Windows,
Linux y macOS). Puede considerarse un equivalente multiplataforma de los contadores de rendimiento que solo
se admiten en los sistemas Windows.
Aunque los usuarios pueden publicar cualquier EventCounters personalizado que necesiten, el entorno de
ejecución de .NET Core 3.0 publica un conjunto de estos contadores de forma predeterminada. En el documento
se recorren los pasos necesarios para recopilar y ver EventCounters (definidos por el sistema o por el usuario)
en Azure Application Insights.
Uso de Application Insights para recopilar contadores de eventos

Application Insights admite la recopilación de EventCounters con su EventCounterCollectionModule , que forma
parte del paquete NuGet Microsoft.ApplicationInsights.EventCounterCollector lanzado recientemente.
EventCounterCollectionModule se habilita automáticamente al usar AspNetCore o WorkerService.
EventCounterCollectionModule recopila contadores con una frecuencia de recopilación no configurable de 60
segundos. No se requieren permisos especiales para recopilar contadores de eventos.
Contadores predeterminados recopilados

Para las aplicaciones que se ejecutan en .NET Core 3.0, los siguientes contadores los recopila automáticamente
el SDK. El nombre de los contadores tendrá el formato "Categoría|Contador".
C AT EGO RY C O N TA DO R
System.Runtime cpu-usage
System.Runtime working-set
System.Runtime gc-heap-size
System.Runtime gen-0-gc-count
System.Runtime time-in-gc
System.Runtime gen-0-size
C AT EGO RY C O N TA DO R
System.Runtime loh-size
System.Runtime alloc-rate
System.Runtime assembly-count
System.Runtime exception-count
System.Runtime threadpool-thread-count
System.Runtime monitor-lock-contention-count
System.Runtime threadpool-queue-length
System.Runtime threadpool-completed-items-count
System.Runtime active-timer-count
NOTE
Los contadores de la categoría Microsoft.AspNetCore.Hosting solo se agregan en aplicaciones ASP.NET Core.
Personalización de los contadores que se van a recopilar

El ejemplo siguiente muestra cómo agregar/quitar contadores. Esta personalización se llevaría a cabo en el
método ConfigureServices de la aplicación después de que se haya habilitado la recopilación de telemetría de
Application Insights mediante AddApplicationInsightsTelemetry() o AddApplicationInsightsWorkerService() . A
continuación se muestra un ejemplo de código de una aplicación ASP.NET Core. Para otros tipos de aplicaciones,
consulte este documento.
using Microsoft.ApplicationInsights.Extensibility.EventCounterCollector;

{
//... other code...
// The following code shows several customizations done to EventCounterCollectionModule.

services.ConfigureTelemetryModule<EventCounterCollectionModule>(
(module, o) =>
{
// This removes all default counters.
module.Counters.Clear();
// This adds a user defined counter "MyCounter" from EventSource named "MyEventSource"
module.Counters.Add(new EventCounterCollectionRequest("MyEventSource", "MyCounter"));
// This adds the system counter "gen-0-size" from "System.Runtime"

module.Counters.Add(new EventCounterCollectionRequest("System.Runtime", "gen-0-size"));
}
);
// The following code removes EventCounterCollectionModule to disable the module completely.

var eventCounterModule = services.FirstOrDefault<ServiceDescriptor>
(t => t.ImplementationType == typeof(EventCounterCollectionModule));
if (eventCounterModule != null)
{
services.Remove(eventCounterModule);
}
}
Los contadores de eventos en el explorador de métricas

Para ver las métricas de EventCounter en el explorador de métricas, seleccione el recurso de Application Insights
y elija las métricas basadas en registros como espacio de nombres de métrica. Después, las métricas de
EventCounter se mostrarán en la categoría Custom.
Contadores de eventos en Analytics

También puede buscar y mostrar informes de los contadores de eventos en Analytics, en la tabla
customMetrics .
Por ejemplo, ejecute la siguiente consulta para ver qué contadores se recopilan y están disponibles para
consulta:
customMetrics | summarize avg(value) by name

Para un gráfico de un contador específico (por ejemplo, ThreadPool Completed Work Item Count ) en el período
más reciente, ejecute la consulta siguiente.
customMetrics
| where name contains "System.Runtime|ThreadPool Completed Work Item Count"
| summarize avg(value) by cloud_RoleInstance, bin(timestamp, 1m)
| render timechart
Al igual que otros datos de telemetría, customMetrics también tiene una columna cloud_RoleInstance que
indica la identidad de la instancia del servidor host en el que se ejecuta la aplicación. La consulta anterior
muestra el valor del contador por instancia y se puede usar para comparar el rendimiento de las distintas
instancias del servidor.
Alertas
Al igual que otras métricas, puede establecer una alerta para advertirle si un contador de eventos supera un
límite especificado. Abra el panel de alertas y haga clic en Agregar alerta.

¿Puedo ver los contadores de eventos en Live Metrics?
A día de hoy, Live Metrics no muestra los contadores de eventos. Para ver la telemetría, use el explorador de
métricas o el análisis.
¿De qué plataformas puedo ver la lista predeterminada de contadores de .NET Core 3.0?
EventCounter no requiere ningún permiso especial y se admite en todas las plataformas donde se admita .NET
Core 3.0. Esto incluye:
Sistema operativo : Windows, Linux o macOS.
Método de hospedaje : en el proceso o fuera del proceso.
Método de implementación : Marco dependiente o independiente.
Ser vidor web : IIS (Internet Information Server) o Kestrel.
Plataforma de hospedaje : característica Web Apps de Azure App Service, VM de Azure, Docker, Azure
Kubernetes Service (AKS), etc.
He habilitado Application Insights en el portal de aplicaciones web de Azure, pero no veo contadores de
eventos.
La extensión de Application Insights para ASP.NET Core aún no admite esta característica. Este documento se
actualizará cuando se admita la característica.
Pasos siguientes
Seguimiento de dependencias
Seguimiento de dependencias en Azure
Una dependencia es un componente al que la aplicación llama. Suele ser un servicio al que se llama
mediante HTTP, una base de datos o un sistema de archivos. Application Insights mide la duración de
las llamadas de dependencia, independientemente de si devuelven un error o no, junto con
información adicional como el nombre de la dependencia y más. Puede investigar llamadas de
dependencia específicas y relacionarlas a solicitudes y excepciones.
Dependencias con seguimiento automático

Los SDK de Application Insights para .NET y .NET Core se suministran con
DependencyTrackingTelemetryModule , un módulo de telemetría que recopila dependencias
automáticamente. Esta recolección de dependencias se habilita automáticamente para las aplicaciones
de ASP.NET y ASP.NET Core cuando se configuran según la documentación oficial vinculada.
DependencyTrackingTelemetryModule se distribuye como este paquete NuGet y se incluye
automáticamente cuando usa cualquiera de los paquetes NuGet Microsoft.ApplicationInsights.Web o
Microsoft.ApplicationInsights.AspNetCore .
DependencyTrackingTelemetryModule actualmente realiza un seguimiento automático de las siguientes

dependencias:
DEP EN DEN C IA S DETA L L ES
HTTP/HTTPS Llamadas HTTP/HTTPS locales o remotas
Llamadas WCF Solo realiza un seguimiento automáticamente si se usan

enlaces basados en HTTP.
SQL Llamadas realizadas con SqlClient . Consulte esta

sección para capturar consultas SQL.
Azure Storage (blobs, tablas, colas) Llamadas realizadas con el cliente de Azure Storage.
SDK de cliente de EventHub Versión 1.1.0 y posteriores.
SDK de cliente de Service Bus Versión 3.0.0 y posteriores.
Azure Cosmos DB Se realiza un seguimiento automático solo si se usa

HTTP/HTTPS. Application Insights no capturará el modo
TCP.
Si falta una dependencia o está usando un SDK diferente, asegúrese de que se encuentra en la lista de
dependencias recopiladas automáticamente. Si la dependencia no se recopila automáticamente, todavía
puede realizar un seguimiento manual con una llamada a TrackDependency .
Configuración de seguimiento automático de dependencias en

aplicaciones de consola
Para hacer un seguimiento automático de las dependencias de aplicaciones de consola de .NET, instale
el paquete de NuGet Microsoft.ApplicationInsights.DependencyCollector e inicialice
DependencyTrackingTelemetryModule como se indica a continuación:
DependencyTrackingTelemetryModule depModule = new DependencyTrackingTelemetryModule();

depModule.Initialize(TelemetryConfiguration.Active);
En el caso de las aplicaciones de consola de .NET Core TelemetryConfiguration.Active está obsoleto.

Consulte las instrucciones de la documentación del servicio de trabajo y la documentación de
supervisión de ASP.NET Core
Funcionamiento de la supervisión automática de dependencias
Las dependencias se recopilan automáticamente mediante una de las siguientes técnicas:
Se usa instrumentación del código de byte alrededor de determinados métodos.
(InstrumentationEngine de StatusMonitor o de la extensión de aplicación web de Azure)
Devoluciones de llamada de EventSource
Devoluciones de llamada de DiagnosticSource (en los últimos SDK de .NET/.NET Core)
Seguimiento manual las dependencias

Los siguientes son algunos ejemplos de las dependencias que no se recopilan automáticamente y, por
lo tanto, requieren seguimiento manual.
Azure Cosmos DB se rastrea automáticamente solo si se usa HTTP/HTTPS. Application Insights no
capturará el modo TCP.
Redis
Para las dependencias que el SDK no recopila automáticamente, puede realizar un seguimiento manual
mediante la API de TrackDependency que utilizan los módulos de recolección automática estándar.
Por ejemplo, si compila el código con un ensamblado que no escribió usted mismo, podría cronometrar
todas las llamadas al ensamblado para averiguar cómo contribuye a los tiempos de respuesta. Para que
estos datos se muestren en los gráficos de dependencia en Application Insights, envíelos mediante
TrackDependency .
var startTime = DateTime.UtcNow;

var timer = System.Diagnostics.Stopwatch.StartNew();
try
{
// making dependency call
}
finally
{
timer.Stop();
telemetryClient.TrackDependency("myDependencyType", "myDependencyCall", "myDependencyData",
startTime, timer.Elapsed, success);
}
Como alternativa, TelemetryClient proporciona los métodos de extensión StartOperation y

StopOperation que pueden usarse para realizar un seguimiento manual de las dependencias, tal como
se muestra aquí.
Si desea desactivar el módulo de seguimiento de dependencia estándar, quite la referencia a
DependencyTrackingTelemetryModule en ApplicationInsights.config para las aplicaciones de ASP.NET.
Para las aplicaciones de ASP.NET Core, siga las instrucciones descritas aquí.
Seguimiento de llamadas AJAX desde páginas web

Para las páginas web, el SDK de JavaScript de Application Insights recopila automáticamente las
llamadas AJAX como dependencias.
Seguimiento de SQL avanzado para obtener la consulta SQL

completa
Para las llamadas SQL, el nombre del servidor y la base de datos siempre se recopilan y almacenan
como el nombre de la DependencyTelemetry recopilada. Hay un campo adicional denominado "data",
que puede contener el texto completo de la consulta SQL.
En el caso de aplicaciones ASP.NET Core, ahora es necesario participar en la recopilación de texto SQL
mediante:
services.ConfigureTelemetryModule<DependencyTrackingTelemetryModule>((module, o) => { module.

EnableSqlCommandTextInstrumentation = true; });
En el caso de las aplicaciones de ASP.NET, se recopila texto de la consulta SQL completa con la ayuda de
la instrumentación de código de bytes, que requiere el uso del motor de instrumentación o puede
realizarse mediante el paquete NuGet Microsoft.Data.SqlClient, en lugar de la biblioteca
System.Data.SqlClient. A continuación, se describen los pasos específicos de la plataforma para habilitar
la recopilación completa de consultas SQL:
PA SO S N EC ESA RIO S PA RA O BT EN ER L A C O N SULTA SQ L

P L ATA F O RM A C O M P L ETA
Aplicación web de Azure En el panel de control de la aplicación web abra la hoja

de Application Insights y habilite los comandos SQL de
.NET
Servidor IIS (máquina virtual de Azure, del entorno Use el paquete de NuGet Microsoft.Data.SqlClient o use
local, entre otras). el módulo Monitor de estado de PowerShell para
instalar el motor de instrumentación y reiniciar IIS.
Servicio en la nube de Azure Agregue una tarea de inicio para instalar StatusMonitor.
La aplicación se debe incorporar al SDK de
ApplicationInsights en tiempo de compilación mediante
la instalación de paquetes de NuGet para las
aplicaciones de ASP.NET o ASP.NET Core.
IIS Express Use el paquete NuGet Microsoft.Data.SqlClient.
Además de los pasos específicos de la plataforma anteriores, también debe optar explícitamente
por habilitar la colección de comandos SQL al modificar el archivo applicationInsights.config con
lo siguiente:
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule,
Microsoft.AI.DependencyCollector">
<EnableSqlCommandTextInstrumentation>true</EnableSqlCommandTextInstrumentation>
</Add>
En los casos anteriores, la forma correcta de validar que el motor de instrumentación está instalado
correctamente es comprobar que la versión de SDK de la DependencyTelemetry recopilada sea "rddp".
Un valor "rdddsd" o "rddf" indica que las dependencias se recopilan a través de las devoluciones de
llamada de DiagnosticSource o EventSource y, por lo tanto, no se puede capturar la consulta SQL
completa.
Dónde encontrar los datos de dependencia

Asignación de aplicación visualiza las dependencias entre la aplicación y los componentes
colindantes.
Diagnósticos de transacción muestra los datos de servidor unificados correlacionados.
La pestaña Exploradores muestra las llamadas AJAX de los exploradores de los usuarios.
Haga clic en las solicitudes lentas o con errores para comprobar sus llamadas de dependencia.
Análisis puede utilizarse para consultar los datos de dependencia.
Diagnóstico de solicitudes lentas

Cada evento de solicitud está asociado a las llamadas de dependencia, las excepciones y otros eventos
de los que se realiza un seguimiento mientras la aplicación procesa la solicitud. Por lo tanto, si algunas
solicitudes no tienen un buen rendimiento, puede averiguar si se debe a respuestas lentas de una
dependencia.
Seguimiento de solicitudes en dependencias
Abra la pestaña Rendimiento y vaya a la pestaña Dependencias en la parte superior junto a las
operaciones.
Haga clic en un nombre de dependencia de la sección general. Después de seleccionar una
dependencia, a la derecha se mostrará un gráfico con la distribución de duraciones de esa dependencia.
Haga clic en el botón azul Ejemplos en la parte inferior derecha y, a continuación, en un ejemplo para
ver los detalles de transacción completos.
Generación de un perfil del sitio activo

¿Quiere saber en qué se invierte el tiempo? El generador de perfiles de Application Insights realiza un
seguimiento de las llamadas HTTP a los sitios activos y muestra qué funciones del código tardan más
tiempo en ejecutarse.
Error en las solicitudes

Las solicitudes con error también podrían estar asociadas a llamadas a dependencias con errores.
Podemos ir a la pestaña Errores a la izquierda y, a continuación, hacer clic en la pestaña
Dependencias en la parte superior.
Aquí podrá ver el recuento de dependencias con errores. Para obtener más detalles sobre una
repetición con error, pruebe a hacer clic en el nombre de una dependencia en la tabla inferior. Puede
hacer clic en el botón azul Dependencias situado en la parte inferior derecha para obtener los detalles
de transacción completos.
Registros (Analytics)
Puede realizar un seguimiento de las dependencias en el lenguaje de consulta de Kusto. Estos son
algunos ejemplos.
Búsqueda de llamadas de dependencia con errores:
dependencies | where success != "True" | take 10
Búsqueda de llamadas AJAX:
dependencies | where client_Type == "Browser" | take 10
Búsqueda de llamadas de dependencia asociadas a solicitudes:
dependencies
| where timestamp > ago(1d) and client_Type != "Browser"
| join (requests | where timestamp > ago(1d))
on operation_Id
Búsqueda de llamadas AJAX asociadas a vistas de página:

dependencies
| where timestamp > ago(1d) and client_Type == "Browser"
| join (browserTimings | where timestamp > ago(1d))
on operation_Id

¿Qué método usa el recopilador de dependencias para informar sobre las llamadas con error a las
dependencias?
Las llamadas de dependencia con error tendrán el campo "success" establecido en False.
DependencyTrackingTelemetryModule no notifica sobre ExceptionTelemetry . El modelo de datos
completo para las dependencias se describe aquí.
¿Cómo calculo la latencia de ingesta para mi telemetría de dependencia?
dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp
| extend TimeIngested = ingestion_time()
Cómo determino la hora en la que se inició la llamada de dependencia?

En la vista de consulta de Log Analytics timestamp representa el momento en que se inició la llamada a
TrackDependency(), que se produjo inmediatamente después de recibir la respuesta de la llamada de
dependencia. Para calcular la hora de inicio de la llamada de dependencia, debería tomar timestamp y
restarle el valor de duration registrado para la llamada de dependencia.

Como todos los SDK de Application Insights, el módulo de recolección de dependencias también es de
código abierto. Puede leer y contribuir al código o notificar sobre problemas en el repositorio oficial de
GitHub.
Pasos siguientes
Excepciones
Datos de página y usuario
Disponibilidad
con ApplicationInsights.config o .xml
El SDK de Application Insights para .NET consta de varios paquetes de NuGet. El paquete principal
proporciona la API para enviar telemetría a Application Insights. Los paquetes adicionales proporcionan
módulos e inicializadores de telemetría para hacer un seguimiento automático de la aplicación y su
contexto. Si ajusta el archivo de configuración, puede habilitar o deshabilitar los módulos e
inicializadores de telemetría, y establecer los parámetros para algunos de ellos.
El archivo de configuración se denomina ApplicationInsights.config o ApplicationInsights.xml ,
dependiendo del tipo de la aplicación. Se agrega automáticamente al proyecto cuando se instalan la
mayoría de las versiones del SDK. De forma predeterminada, cuando se usa la experiencia
automatizada de los proyectos de plantilla de Visual Studio que admiten Agregar > Telemetría de
Application Insights , se crea el archivo ApplicationInsights.config en la carpeta raíz del proyecto y,
cuando es compatible, se copia en la carpeta bin. El Monitor de estado en un servidor IIS también lo
agrega a una aplicación web. El archivo de configuración se omite si se usa la extensión para el sitio
web de Azure o la extensión para VM de Azure y conjuntos de escalado de máquinas virtuales.
No hay un archivo equivalente para controlar el SDK en una página web.
En este documento se describen las secciones que verá en el archivo de configuración, cómo controlan
los componentes del SDK y qué paquetes NuGet cargan esos componentes.
NOTE
Las instrucciones de ApplicationInsights.config y .xml no se aplican al SDK de .NET Core. Para configurar
aplicaciones de .NET Core, siga esta guía.
Módulos de telemetría (ASP.NET)

Cada módulo de telemetría recopila un tipo específico de datos y usa la API principal para enviar dichos
datos. Los módulos los instalan diferentes paquetes NuGet, que también agregan las líneas necesarias
al archivo .config.
Hay un nodo en el archivo de configuración para cada módulo. Para deshabilitar un módulo, elimine el
nodo o conviértalo en comentario.
Seguimiento de dependencia
Dependency tracking recopila la telemetría sobre las llamadas que realiza la aplicación a bases de datos
y a servicios y bases de datos externos. Para permitir que este módulo funcione en un servidor IIS,
deberá instalar el Monitor de estado.
También puede escribir su propio código de seguimiento de dependencias con la API de
TrackDependency.
Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule
Microsoft.ApplicationInsights.DependencyCollector .
Las dependencias se pueden recopilar automáticamente sin modificar el código mediante la asociación
basada en agente (sin código). Para utilizarlo en aplicaciones web de Azure, habilite la extensión
Application Insights. Para usarlo en una VM de Azure o en un conjunto de escalado de máquinas
virtuales de Azure, habilite la extensión de supervisión de aplicaciones para VM y conjuntos de
Recopilador de rendimiento
Recopila contadores de rendimiento del sistema como CPU, memoria y carga de la red desde
instalaciones de IIS. Puede especificar qué contadores recopilar, incluidos los contadores de
rendimiento que ha configurado usted mismo.
Microsoft.ApplicationInsights.Extensibility.PerfCounterCollector.PerformanceCollectorModule
Microsoft.ApplicationInsights.PerfCounterCollector .
Telemetría de diagnósticos de Application Insights
DiagnosticsTelemetryModule informa de errores en el propio código de instrumentación de Application
Insights. Por ejemplo, si el código no puede tener acceso a los contadores de rendimiento o si un
ITelemetryInitializer inicia una excepción. La telemetría de seguimiento que sigue este módulo
aparece en la Búsqueda de diagnóstico.
* `Microsoft.ApplicationInsights.Extensibility.Implementation.Tracing.DiagnosticsTelemetryModule`
* [Microsoft.ApplicationInsights](https://www.nuget.org/packages/Microsoft.ApplicationInsights)
NuGet package. If you only install this package, the ApplicationInsights.config file is not
automatically created.
Modo de programador
DeveloperModeWithDebuggerAttachedTelemetryModule fuerza al TelemetryChannel de Application Insights a
enviar los datos inmediatamente, elemento de telemetría a elemento, cuando se adjunta un depurador
al proceso de aplicación. Esto reduce la cantidad de tiempo entre el momento en que la aplicación
realiza un seguimiento de telemetría y el momento en que esta aparece en el portal de Application
Insights. Esto provoca una sobrecarga considerable en la CPU y el ancho de banda.
Microsoft.ApplicationInsights.WindowsServer.DeveloperModeWithDebuggerAttachedTelemetryModule
Application Insights Windows Server
Seguimiento de solicitud web
Informa del tiempo de respuesta y del código del resultado de solicitudes HTTP.
Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule
Microsoft.ApplicationInsights.Web
Seguimiento de excepciones
ExceptionTrackingTelemetryModule realiza excepciones no controladas en la aplicación web. Consulte
Errores y excepciones.
Microsoft.ApplicationInsights.Web.ExceptionTrackingTelemetryModule
Microsoft.ApplicationInsights.Web
Microsoft.ApplicationInsights.WindowsServer.UnobservedExceptionTelemetryModule - Realiza un
seguimiento de excepciones de tareas inadvertidas.
Microsoft.ApplicationInsights.WindowsServer.UnhandledExceptionTelemetryModule - Realiza un
seguimiento de excepciones no controladas para roles de trabajo, servicios de Windows y
aplicaciones de consola.
Application Insights Windows Server .
Seguimiento de EventSource
EventSourceTelemetryModule permite configurar eventos EventSource para enviarse a Application
Insights como seguimientos. Para obtener información sobre el seguimiento de eventos EventSource,
vea Uso de eventos EventSource.
Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule
Microsoft.ApplicationInsights.EventSourceListener
Seguimiento de eventos ETW
EtwCollectorTelemetryModule permite configurar eventos de proveedores ETW para enviarse a
Application Insights como seguimientos. Para obtener información sobre el seguimiento de eventos
ETW de seguimiento, vea Uso de eventos ETW.
Microsoft.ApplicationInsights.EtwCollector.EtwCollectorTelemetryModule
Microsoft.ApplicationInsights.EtwCollector
El paquete Microsoft.ApplicationInsights proporciona la API principal del SDK. Los otros módulos de
telemetría usan esto y también puede usarlo usted mismo para definir su propia telemetría.
No hay entrada en ApplicationInsights.config.
Microsoft.ApplicationInsights . Si solamente instala este NuGet, no se genera ningún archivo .config.
Canal de telemetría
El canal de telemetría administra el almacenamiento en búfer y la transmisión de telemetría al servicio
Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.ServerTelemetryChannel es el canal
predeterminado para aplicaciones web. Almacena en búfer los datos en memoria y emplea
mecanismos de reintento y almacenamiento de disco local para proporcionar una entrega de
telemetría de más confianza.
Microsoft.ApplicationInsights.InMemoryChannel es un canal de telemetría ligero que se utiliza si no
se ha configurado ningún otro canal.
Inicializadores de telemetría (ASP.NET)

Los inicializadores de telemetría establecen propiedades de contexto que se envían junto con todos los
elementos de telemetría.
También puede escribir sus propios inicializadores para establecer propiedades de contexto.
Los inicializadores estándar están todos establecidos por los paquetes NuGet web o WindowsServer:
AccountIdTelemetryInitializer establece la propiedad AccountId.
AuthenticatedUserIdTelemetryInitializer establece la propiedad AuthenticatedUserId
establecida por el SDK de JavaScript.
AzureRoleEnvironmentTelemetryInitializeractualiza las propiedades RoleName y RoleInstance
del contexto Device para todos los elementos de telemetría con información extraída del
entorno de tiempo de ejecución de Azure.
actualiza la propiedad Version del
BuildInfoConfigComponentVersionTelemetryInitializer
contexto Component para todos los elementos de telemetría con el valor extraído del archivo
BuildInfo.config que produce MS Build.
ClientIpHeaderTelemetryInitializer actualiza la propiedad Ip del contexto Location de todos

los elementos de telemetría según el encabezado HTTP X-Forwarded-For de la solicitud.
DeviceTelemetryInitializer actualiza las propiedades siguientes del contexto Device para
todos los elementos de telemetría.
Type se establece en "PC".
Id se establece en el nombre de dominio del equipo donde se ejecuta la aplicación web.
OemName se establece en el valor extraído del campo Win32_ComputerSystem.Manufacturer con
WMI.
Model se establece en el valor extraído del campo Win32_ComputerSystem.Model con WMI.
NetworkType se establece en el valor extraído de NetworkInterface .
Language se establece en el nombre de CurrentCulture .
DomainNameRoleInstanceTelemetryInitializer actualiza la propiedad RoleInstance del contexto

Device para todos los elementos de telemetría con el nombre de dominio del equipo donde se
ejecuta la aplicación web.
OperationNameTelemetryInitializer actualiza la propiedad Name de la propiedad
RequestTelemetry y Name propiedad del contexto Operation de todos los elementos de
telemetría según el método HTTP, así como los nombres del controlador MVC de ASP.NET y la
acción que se invoca para procesar la solicitud.
OperationIdTelemetryInitializer o actualizan la
OperationCorrelationTelemetryInitializer
propiedad de contexto Operation.Id de todos los elementos de telemetría de los que se realiza
un seguimiento mientras se controla una solicitud con el RequestTelemetry.Id que se genera.
SessionTelemetryInitializer actualiza la propiedad Id del contexto Session para todos los
elementos de telemetría con valor extraído de la cookie ai_session que genera el código de
instrumentación JavaScript de Application Insights que se ejecuta en el explorador del usuario.
SyntheticTelemetryInitializer o SyntheticUserAgentTelemetryInitializer actualiza las
propiedades de los contextos User , Session y Operation de todos los elementos de telemetría
de los que se realiza el seguimiento al controlar una solicitud de un origen sintético, como una
prueba de disponibilidad o un bot de motor de búsqueda. De forma predeterminada, Explorador
de métricas no muestra telemetría sintética.
Conjunto de <Filters> que identifica las propiedades de las solicitudes.
UserTelemetryInitializer actualiza las propiedades Id y AcquisitionDate del contexto User
para todos los elementos de telemetría con valores extraídos de la cookie ai_user que genera
el código de instrumentación JavaScript de Application Insights que se ejecuta en el explorador
del usuario.
WebTestTelemetryInitializer establece el identificador de usuario, el identificador de sesión y las
propiedades de origen sintético de las solicitudes HTTP que proceden de pruebas de
disponibilidad. Conjunto de <Filters> que identifica las propiedades de las solicitudes.
Para aplicaciones de .NET que se ejecutan en Service Fabric, puede incluir el paquete de NuGet
Microsoft.ApplicationInsights.ServiceFabric . Este paquete incluye FabricTelemetryInitializer , que
agrega propiedades de Service Fabric a elementos de telemetría. Para obtener más información,
consulte la página de GitHub sobre las propiedades que agrega este paquete de NuGet.
Procesadores de telemetría (ASP.NET)

Los procesadores de telemetría pueden filtrar y modificar cada elemento de telemetría justo antes de
que se envíe desde el SDK al portal.
También puede escribir sus propios procesadores de telemetría.
Procesador de telemetría de muestreo adaptable (desde 2.0.0-beta3)
Esta opción está habilitada de manera predeterminada. Si la aplicación envía una gran cantidad de
datos de telemetría, este procesador quita algunos de ellos.
<Add
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcess
or, Microsoft.AI.ServerTelemetryChannel">
</Add>
El parámetro proporciona el destino que el algoritmo intenta alcanzar. Cada instancia del SDK funciona
de forma independiente, por lo que si el servidor es un clúster de varios equipos, se multiplicará el
volumen real de telemetría en consonancia.
Obtenga más información sobre el muestreo.
Procesador de telemetría de muestreo de tasa fija (desde 2.0.0-beta1)
También hay un procesador de telemetría de muestreo estándar (desde 2.0.1):
<Add
Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.SamplingTelemetryProcessor,


<SamplingPercentage>10</SamplingPercentage>
</Add>
InstrumentationKey
Esto determina el recurso de Application Insights en el que aparecen los datos. Normalmente se crea
un recurso independiente, con una clave independiente, para cada una de las aplicaciones.
Si desea establecer la clave de forma dinámica (por ejemplo, si desea enviar los resultados de su
aplicación a distintos recursos) puede omitir la clave del archivo de configuración y establecerla en el
código.
Para establecer la clave de todas las instancias de TelemetryClient, incluidos los módulos de telemetría
estándar. Hágalo en un método de inicialización, como global.aspx.cs, en un servicio de ASP.NET:

{
configuration.InstrumentationKey = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx";
Si solo desea enviar un conjunto específico de eventos a un recurso diferente, puede establecer la clave
para un TelemetryClient específico:
var tc = new TelemetryClient();

tc.Context.InstrumentationKey = "----- my key ----";
tc.TrackEvent("myEvent");
// ...
Para obtener una nueva clave, cree un nuevo recurso en el portal de Application Insights.
Proveedor ApplicationId
Disponible a partir de la versión 2.6.0
El propósito de este proveedor es buscar un identificador de aplicación en función de una clave de
instrumentación. El identificador de aplicación se incluye en RequestTelemetry y DependencyTelemetry,
y se usa para determinar la correlación en el portal.
Está disponible al establecer TelemetryConfiguration.ApplicationIdProvider en el código o en la
configuración.
Interfaz: IApplicationIdProvider
public interface IApplicationIdProvider

{
bool TryGetApplicationId(string instrumentationKey, out string applicationId);
}
Se proporcionan dos implementaciones en el SDK Microsoft.ApplicationInsights:

ApplicationInsightsApplicationIdProvider y DictionaryApplicationIdProvider .
ApplicationInsightsApplicationIdProvider
Es un contenedor alrededor de nuestra API de Profile. Limita las solicitudes y los resultados en la
memoria caché.
Este proveedor se agrega al archivo de configuración cuando se instala
Microsoft.ApplicationInsights.DependencyCollector o Microsoft.ApplicationInsights.Web
Esta clase tiene una propiedad ProfileQueryEndpoint opcional. De manera predeterminada, se
establece en https://dc.services.visualstudio.com/api/profiles/{0}/appId . Si tiene que configurar un
proxy para esta configuración, se recomienda un proxy en la dirección base y la inclusión de
"/api/profiles/{0}/appId". Tenga en cuenta que "{0}" se sustituye en tiempo de ejecución por cada
solicitud con la clave de instrumentación.
Ejemplo de configuración con ApplicationInsights.config:
...
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsA
pplicationIdProvider, Microsoft.ApplicationInsights">
<ProfileQueryEndpoint>https://dc.services.visualstudio.com/api/profiles/{0}/appId</ProfileQueryEndp
oint>
...
Ejemplo de configuración mediante código:
TelemetryConfiguration.Active.ApplicationIdProvider = new
ApplicationInsightsApplicationIdProvider();
DictionaryApplicationIdProvider
Se trata de un proveedor estático, que se basará en los pares de clave de instrumentación/identificador
de la aplicación configurados.
Esta clase tiene una propiedad Defined , que es un Diccionario<string,string> de los pares de clave de
instrumentación e identificador de aplicación.
Esta clase tiene una propiedad Next opcional que puede utilizarse para configurar otro proveedor que
se use al solicitar una clave de instrumentación que no exista en la configuración.
Ejemplo de configuración con ApplicationInsights.config:
...
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.DictionaryApplicatio
nIdProvider, Microsoft.ApplicationInsights">
<Defined>
<Type key="InstrumentationKey_1" value="ApplicationId_1"/>
<Type key="InstrumentationKey_2" value="ApplicationId_2"/>
</Defined>
<Next
Type="Microsoft.ApplicationInsights.Extensibility.Implementation.ApplicationId.ApplicationInsightsA
pplicationIdProvider, Microsoft.ApplicationInsights" />
...
Ejemplo de configuración mediante código:
TelemetryConfiguration.Active.ApplicationIdProvider = new DictionaryApplicationIdProvider{

Defined = new Dictionary<string, string>
{
{"InstrumentationKey_1", "ApplicationId_1"},
{"InstrumentationKey_2", "ApplicationId_2"}
}
};
Pasos siguientes
Más información acerca de la API.
Correlación de los datos de Application Insights con
orígenes de datos personalizados
Application Insights recopila diferentes tipos de datos: excepciones, seguimientos, vistas de página y otros. Si bien
esto suele ser suficiente para investigar el rendimiento, la confiabilidad y el uso de la aplicación, hay casos en los
que resulta útil correlacionar los datos almacenados en Application Insights con otros conjuntos de datos
completamente personalizados.
Algunas situaciones en las que es posible que desee usar datos personalizados incluyen:
Enriquecimiento de datos o tablas de búsqueda: complementar, por ejemplo, un nombre de servidor con el
propietario del servidor y la ubicación del laboratorio en el que se puede encontrar.
Correlación con orígenes de datos que no son de Application Insights: por ejemplo, correlacionar datos sobre
una compra en una tienda web con la información del servicio de entrega de compras para determinar el grado
de precisión de las estimaciones de la hora de envío.
Datos completamente personalizados: a muchos de nuestros clientes les encantan el lenguaje de consulta y el
rendimiento de la plataforma de registro de Azure Monitor que hay detrás de Application Insights, y quieren
aprovecharlos para consultar datos que no están relacionados con Application Insights. Por ejemplo, para
supervisar el rendimiento de un panel solar como parte de una instalación doméstica inteligente como se
describe aquí.
Correlación de datos personalizados con datos de Application Insights

Puesto que Application Insights está respaldado por la eficaz plataforma de registro de Azure Monitor, se puede
usar toda la potencia de Azure Monitor para la ingesta de datos. De este modo, se escriben consultas con el
operador "join" que establecen una correlación de estos datos personalizados con los datos disponibles en los
Ingesta de datos
En esta sección, revisamos cómo ingerir los datos en registros de Azure Monitor.
Si aún no tiene una, aprovisione una nueva área de trabajo de Log Analytics según estas instrucciones, incluido el
paso "Creación de un área de trabajo".
Para empezar a enviar datos de registro a Azure Monitor. Existen varias opciones:
Para un mecanismo sincrónico, puede llamar directamente a Data Collector API o usar el conector de Logic
Apps; simplemente busque "Azure Log Analytics" y elija la opción "Enviar datos":
Para una opción asincrónica, use Data Collector API para crear una canalización de procesamiento. Consulte
este artículo para más información.
Correlación de datos
Application Insights se basa en la plataforma de registro de Azure Monitor. Por lo tanto, podemos usar
combinaciones entre recursos para correlacionar cualquier dato que se ingiera en Azure Monitor con los datos de
Por ejemplo, podemos ingerir el inventario y las ubicaciones del laboratorio en una tabla llamada
"LabLocations_CL" en un área de trabajo de Log Analytics llamada "myLA". A continuación, si quisiéramos revisar
las solicitudes de la aplicación de Application Insights llamada "myAI" y correlacionar los nombres de equipo que
atienden las solicitudes con las ubicaciones de estos equipos almacenados en la tabla personalizada mencionada
anteriormente, podemos ejecutar la siguiente consulta en el contexto de Application Insights o de Azure Monitor:
app('myAI').requests
workspace('myLA').LabLocations_CL
| project Computer_S, Owner_S, Lab_S
) on $left.cloud_RoleInstance == $right.Computer
Pasos siguientes
Consulte la referencia de Data Collector API.
Más información sobre combinaciones entre recursos.
Cadenas de conexión
Las cadenas de conexión proporcionan a los usuarios de Application Insights una única opción de configuración, lo que elimina la necesidad de varias
configuraciones de proxy. Resultan de gran utilidad para los servidores web de la intranet y los entornos de nube híbrida o soberana que buscan enviar datos al
servicio de supervisión.
Los pares clave-valor proporcionan a los usuarios una manera fácil de definir una combinación de sufijo y prefijo para cada servicio o producto de Application
Insights (AI).
IMPORTANT
No se recomienda establecer la cadena de conexión y la clave de instrumentación. En caso de que un usuario establezca ambas, tendrá prioridad la que se haya establecido en último
lugar.
Información general de escenario

Escenarios de cliente en los que se visualiza dónde tiene esto el mayor efecto:
Excepciones de firewall o redirecciones de proxy
En los casos en los que es necesario supervisar el servidor web de la intranet, nuestra solución anterior solicitaba a los clientes que agregaran puntos de
conexión de servicio individuales a la configuración. Para más información, consulte esta página. Las cadenas de conexión ofrecen una mejor alternativa, ya
que reducen esta labor a una única configuración. Una corrección de sufijos y prefijos simple permite el rellenado y la redirección automáticos de todos los
puntos de conexión a los servicios adecuados.
Entornos de nube soberana o híbrida
Los usuarios pueden enviar datos a una región de Azure Government definida. Las cadenas de conexión permiten definir la configuración de punto de
conexión de los servidores de la intranet o la configuración de la nube híbrida.
Introducción
¿Dónde está la cadena de conexión?
La cadena de conexión se muestra en la hoja de información general del recurso de Application Insights.
Schema
Longitud máxima
La conexión tiene una longitud máxima admitida de 4096 caracteres.
Pares de clave-valor
La cadena de conexión consta de una lista de valores de configuración representados como pares de clave-valor separados por punto y coma:
key1=value1;key2=value2;key3=value3
Sintaxis
InstrumentationKey(por ejemplo: 00000000-0000-0000-0000-000000000000) La cadena de conexión es un campo obligatorio .
Authorization(por ejemplo: ikey) (Este valor es opcional porque actualmente no se admite la autorización mediante ikey.)
EndpointSuffix (por ejemplo: applicationinsights.azure.cn) Al establecer el sufijo del punto de conexión, se indicará al SDK a qué nube de Azure se conectará. El
SDK ensamblará el resto del punto de conexión para los servicios individuales.
Puntos de conexión explícitos. Cualquier servicio se puede invalidar explícitamente en la cadena de conexión.
IngestionEndpoint (por ejemplo: https://dc.applicationinsights.azure.com )
LiveEndpoint (por ejemplo: https://live.applicationinsights.azure.com )
ProfilerEndpoint (por ejemplo: https://profiler.applicationinsights.azure.com )
SnapshotEndpoint (por ejemplo: https://snapshot.applicationinsights.azure.com )
Esquema del punto de conexión

<prefix>.<suffix>
Prefijo: define un servicio.

Sufijo: define el nombre de dominio común.
Su fi j o s v á l i d o s
Esta es una lista de sufijos válidos.

applicationinsights.azure.cn
applicationinsights.us
Consulte también: https://docs.microsoft.com/azure/azure-monitor/app/custom-endpoints#regions-that-require-endpoint-modification
P r e fi j o s v á l i d o s
Ingesta de telemetría: dc
Live Metrics: live
Profiler: profiler
Instantánea: snapshot
Ejemplos de cadena de conexión

Cadena de conexión válida mínima
InstrumentationKey=00000000-0000-0000-0000-000000000000;
En este ejemplo, solo se ha establecido la clave de instrumentación.

El esquema de autorización tiene como valor predeterminado "ikey".
Clave de instrumentación: 00000000-0000-0000-0000-000000000000
Los identificadores URI de servicio regional se basan en los valores predeterminados del SDK y se conectarán a Azure público global:
Ingesta: https://dc.services.visualstudio.com/
Live Metrics: https://rt.services.visualstudio.com/
Profiler: https://agent.azureserviceprofiler.net/
Depurador: https://agent.azureserviceprofiler.net/
Cadena de conexión con sufijo de punto de conexión
InstrumentationKey=00000000-0000-0000-0000-000000000000;EndpointSuffix=ai.contoso.com;
En este ejemplo, esta cadena de conexión especifica el sufijo de punto de conexión, y el SDK construirá los puntos de conexión de servicio.
Los identificadores URI de servicio regional se basan en el sufijo de punto de conexión proporcionado:
Ingesta: https://dc.ai.contoso.com
Live Metrics: https://live.ai.contoso.com
Profiler: https://profiler.ai.contoso.com
Depurador: https://snapshot.ai.contoso.com
Cadena de conexión con invalidaciones explícitas del punto de conexión
InstrumentationKey=00000000-0000-0000-0000-
000000000000;IngestionEndpoint=https://custom.com:111/;LiveEndpoint=https://custom.com:222/;ProfilerEndpoint=https://custom.com:333/;SnapshotEndpoint=https://custom.com:444/;
En este ejemplo, esta cadena de conexión especifica invalidaciones explícitas para cada servicio. El SDK usará los puntos de conexión exactos proporcionados sin
modificaciones.
Los identificadores URI de servicio regional se basan en los valores de invalidación explícitos:
Ingesta: https://custom.com:111/
Live Metrics: https://custom.com:222/
Profiler: https://custom.com:333/
Depurador: https://custom.com:444/
Cómo establecer una cadena de conexión

Se admiten cadenas de conexión en las siguientes versiones del SDK:
.NET y .NET Core v2.12.0
Java v2.5.1 y Java 3.0
JavaScript v2.3.0
NodeJS v1.5.0
Python v1.0.0
Una cadena de conexión se puede establecer por el código, la variable de entorno o el archivo de configuración.
Variable de entorno
Cadena de conexión: APPLICATIONINSIGHTS_CONNECTION_STRING
.NET/.NetCore
Java
JavaScript
Node.js
Python
TelemetryConfiguration.ConnectionString: https://github.com/microsoft/ApplicationInsights-
dotnet/blob/add45ceed35a817dc7202ec07d3df1672d1f610d/BASE/src/Microsoft.ApplicationInsights/Extensibility/TelemetryConfiguration.cs#L271-L274
.NET establecido explícitamente:
var configuration = new TelemetryConfiguration

{
ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000;"
};
Archivo de configuración .NET:

<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<ConnectionString>InstrumentationKey=00000000-0000-0000-0000-000000000000</ConnectionString>
NetCore establecido explícitamente:

{
var options = new ApplicationInsightsServiceOptions { ConnectionString = "InstrumentationKey=00000000-0000-0000-0000-000000000000;" };
services.AddApplicationInsightsTelemetry(options: options);
}
NetCore config.json:
{
"ConnectionString" : "InstrumentationKey=00000000-0000-0000-0000-000000000000;"
}
}
Recopilación de métricas personalizadas en .NET y
.NET Core
Los SDK de Application Insights de Azure Monitor para .NET y .NET Core tienen dos métodos diferentes para
recopilar métricas personalizadas, TrackMetric() y GetMetric() . La diferencia principal entre estos dos métodos
es la agregación local. TrackMetric() no dispone de agregación previa, en tanto que GetMetric() tiene
agregación previa. El enfoque recomendado es usar agregación, por lo que TrackMetric() ya no es el método
preferido para recopilar métricas personalizadas. En este artículo se le guiará por el uso del método GetMetric () y
parte de la lógica en la que se basa en su funcionamiento.
TrackMetric frente a GetMetric

TrackMetric() envía datos de telemetría sin procesar que denotan una métrica. No es eficaz para enviar un
elemento de telemetría único para cada valor. TrackMetric() también es ineficaz en términos de rendimiento, ya
que cada elemento TrackMetric(item) pasa a través de la canalización completa del SDK de inicializadores y
procesadores de telemetría. A diferencia de TrackMetric() , GetMetric() controla la agregación previa local
automáticamente y, a continuación, solo envía una métrica de resumen agregada cada intervalo fijo de un minuto.
Por lo tanto, si necesita supervisar de cerca algunas métricas personalizadas en el nivel de segundos o incluso en
el de milisegundos, puede hacerlo y además solo se incurre en el costo de almacenamiento y tráfico de red de la
supervisión en cada minuto. Esto también reduce en gran medida el riesgo de que se produzca una limitación, ya
que se reduce considerablemente el número total de elementos de telemetría que se deben enviar para una
métrica agregada.
En Application Insights, las métricas personalizadas recopiladas mediante TrackMetric() y GetMetric() no están
sujetas a muestreo. El muestreo de métricas importantes puede dar lugar a escenarios en los que las alertas que
se puedan haber creado en torno a esas métricas resulten poco confiables. Si nunca se realiza el muestreo de las
métricas personalizadas, normalmente puede estar seguro de que se activará una alerta cuando se infrinjan los
umbrales de alerta. Sin embargo, dado que no se muestrean las métricas personalizadas, existen algunas posibles
preocupaciones.
Si necesita realizar un seguimiento de las tendencias de una métrica cada segundo o en un intervalo aún más
granular, esto puede dar lugar a:
Aumento de los costos de almacenamiento de datos. Hay un costo asociado con la cantidad de datos que se
envían a Azure Monitor. (Cuantos más datos envíe, mayor será el costo total de la supervisión).
Aumento del tráfico de red y sobrecarga del rendimiento. (En algunos escenarios esto podría tener un costo
monetario y de rendimiento de la aplicación).
Riesgo de limitación de la ingesta de datos. (El servicio Azure Monitor descarta ("limita") puntos de datos
cuando la aplicación envía un número muy elevado de datos de telemetría en un intervalo de tiempo corto).
La limitación tiene una preocupación especial en la que, al igual que en el muestreo, la limitación puede conducir a
alertas perdidas, ya que la condición para desencadenar una alerta podría producirse localmente y, a continuación,
ser eliminada en el punto de conexión de ingesta debido a que se están enviando demasiados datos. Por este
motivo, para .NET y .NET Core, no se recomienda usar TrackMetric() a menos que haya implementado su propia
lógica de agregación local. Si intenta realizar un seguimiento de cada instancia en la que se produce un evento
durante un período de tiempo determinado, es posible que sea mejor opción TrackEvent() . Sin embargo, tenga
en cuenta que, a diferencia de las métricas personalizadas, los eventos personalizados están sujetos a muestreo.
Por supuesto, puede utilizar TrackMetric() incluso sin escribir su propia agregación previa local, pero si lo hace,
tenga en cuenta los posibles problemas.
En resumen, GetMetric() es el enfoque recomendado, ya que realiza la agregación previa, acumula los valores de
todas las llamadas a Track() y envía un resumen o agregado cada minuto. Esto puede reducir significativamente
los costos y la sobrecarga de rendimiento, ya que envía menos puntos de datos, pero recopila toda la información
pertinente.
NOTE
Solo los SDK de .NET y .NET Core tienen el método GetMetric(). Si usa Java, puede usar las métricas de Micrometer o
TrackMetric() . En el caso de Python, puede usar OpenCensus.stats para enviar métricas personalizadas. Para JavaScript y
Node.js puede utilizar TrackMetric() , pero tenga en cuenta las advertencias que se han descrito en la sección anterior.
Introducción a GetMetric
En los ejemplos, vamos a usar una aplicación básica de servicio de trabajo de .NET Core 3.1. Si desea replicar
exactamente el entorno de prueba utilizado con estos ejemplos, siga los pasos 1 a 6 del artículo sobre supervisión
del servicio de trabajo para agregar Application Insights a una plantilla de proyecto básica de servicio de trabajo.
Estos conceptos se aplican a cualquier aplicación general en la que se pueda usar el SDK, incluidas las aplicaciones
web y las aplicaciones de consola.
Envío de métricas
Reemplace el contenido del archivo worker.cs por lo siguiente:
using System;
using System.Threading;
using Microsoft.Extensions.Hosting;
namespace WorkerService3
{
public class Worker : BackgroundService
{
private readonly ILogger<Worker> _logger;
public Worker(ILogger<Worker> logger, TelemetryClient tc)

{
_logger = logger;
_telemetryClient = tc;
}

{ // The following line demonstrates usages of GetMetric API.
// Here "computersSold", a custom metric name, is being tracked with a value of 42 every second.
{
_telemetryClient.GetMetric("computersSold").TrackValue(42);

}
}
}
}
Si ejecuta el código anterior y observa la telemetría que se envía mediante la ventana de salida de Visual Studio o
una herramienta como Fiddler de Telerik, verá que el bucle while se ejecuta repetidamente sin que se envíen datos
de telemetría y, a continuación, se envía un único elemento de telemetría en torno a la marca de 60 segundos, que
en el caso de nuestra prueba tiene el siguiente aspecto:
Application Insights Telemetry: {"name":"Microsoft.ApplicationInsights.Dev.00000000-0000-0000-0000-

000000000000.Metric", "time":"2019-12-28T00:54:19.0000000Z",
"ikey":"00000000-0000-0000-0000-000000000000",
"tags":{"ai.application.ver":"1.0.0.0",
"ai.cloud.roleInstance":"Test-Computer-Name",
"ai.internal.sdkVersion":"m-agg2c:2.12.0-21496",
"ai.internal.nodeName":"Test-Computer-Name"},
"data":{"baseType":"MetricData",
"baseData":{"ver":2,"metrics":[{"name":"computersSold",
"kind":"Aggregation",
"value":1722,
"count":41,
"min":42,
"max":42,
"stdDev":0}],
"properties":{"_MS.AggregationIntervalMs":"42000",
"DeveloperMode":"true"}}}}
Este único elemento de telemetría representa un agregado de 41 medidas de métricas distintas. Dado que se envía
el mismo valor una y otra vez, tenemos una desviación estándar (stDev) de 0, con idénticos valores máximo (max)
y mínimo (min) . La propiedad value representa la suma de todos los valores individuales que se agregaron.
Si examinamos el recurso de Application Insights en la experiencia de Log Analytics, este elemento de telemetría
individual tendría el siguiente aspecto:
NOTE
Aunque el elemento de telemetría sin procesar no contenía una propiedad ni campo de suma explícitos, se crea uno
automáticamente después de la ingesta. En este caso, las propiedades value y valueSum representan lo mismo.
También puede acceder a los datos de telemetría de la métrica personalizada en la sección Métricas del portal.
Tanto para una métrica basada en registros como para una métrica personalizada. (La captura de pantalla
siguiente es un ejemplo de métrica basada en registros).
Almacenamiento en caché de referencias de métricas para uso de alto rendimiento
En algunos casos, los valores de las métricas se observan con mucha frecuencia. Por ejemplo, un servicio de alto
rendimiento que procesa 500 solicitudes por segundo puede querer emitir 20 métricas de datos de telemetría por
cada solicitud. Esto significa un seguimiento de 10 000 valores por segundo. En dichos escenarios de alto
rendimiento, es posible que los usuarios necesiten ayudar al SDK evitando algunas búsquedas.
Por ejemplo, en este caso, en el ejemplo anterior se realizó una búsqueda de un identificador de la métrica
"ComputersSold" y, a continuación, se realizó un seguimiento de un valor observado de 42. En su lugar, el
identificador se puede almacenar en caché para las invocaciones de varios seguimientos:
//...

{
// This is where the cache is stored to handle faster lookup
Metric computersSold = _telemetryClient.GetMetric("ComputersSold");
{
computersSold.TrackValue(42);
computersSold.TrackValue(142);

}
}
Además de almacenar en caché el identificador de la métrica, en el ejemplo anterior también se redujo

Task.Delay a 50 milisegundos para que el bucle se ejecute con más frecuencia, lo que generaba 772 invocaciones
a TrackValue() .
Métricas multidimensionales
Los ejemplos de la sección anterior muestran métricas de dimensión cero. Las métricas también pueden ser
multidimensionales. Actualmente se admiten hasta 10 dimensiones.
Este es un ejemplo de cómo crear una métrica de una dimensión:
//...

{
// This is an example of a metric with a single dimension.
// FormFactor is the name of the dimension.
Metric computersSold= _telemetryClient.GetMetric("ComputersSold", "FormFactor");
{
// The number of arguments (dimension values)
// must match the number of dimensions specified while GetMetric.
// Laptop, Tablet, etc are values for the dimension "FormFactor"
computersSold.TrackValue(42, "Laptop");
computersSold.TrackValue(20, "Tablet");
computersSold.TrackValue(126, "Desktop");

}
}
La ejecución de este código durante al menos 60 segundos dará como resultado que se envíen tres elementos de
telemetría distintos a Azure, cada uno de los cuales representa la agregación de uno de los tres factores de forma.
Como antes, puede examinarlos en la vista de Log Analytics:
Así como en la experiencia del Explorador de métricas:
Sin embargo, observará que no se puede dividir la métrica por la nueva dimensión personalizada ni ver la
dimensión personalizada con la vista de métricas:
De forma predeterminada, las métricas multidimensionales dentro de la experiencia del Explorador de métricas no
están activadas en recursos de Application Insights.
Habilitación de las métricas multidimensionales
Para habilitar las métricas multidimensionales para un recurso de Application Insights, seleccione Uso y costos
estimados > Métricas personalizadas > Habilitar la creación de aler tas sobre las dimensiones de las
métricas personalizadas > Aceptar . Aquí puede encontrar más detalles al respecto.
Una vez que haya realizado ese cambio y haya enviado nuevos datos de telemetría multidimensionales, dispondrá
de la opción Aplicar división .
NOTE
Solo se almacenarán las dimensiones de las métricas enviadas después de activar la característica en el portal.
Y para ver las agregaciones de métricas para cada dimensión FormFactor:
Uso de MetricIdentifier cuando hay más de tres dimensiones

En la actualidad se admiten 10 dimensiones, pero si hay más de tres dimensiones se requiere el uso de
MetricIdentifier :
// Add "using Microsoft.ApplicationInsights.Metrics;" to use MetricIdentifier
// MetricIdentifier id = new MetricIdentifier("[metricNamespace]","[metricId],"[dim1]","[dim2]","[dim3]","
[dim4]","[dim5]");
MetricIdentifier id = new MetricIdentifier("CustomMetricNamespace","ComputerSold", "FormFactor",
"GraphicsCard", "MemorySpeed", "BatteryCapacity", "StorageCapacity");
Metric computersSold = _telemetryClient.GetMetric(id);
computersSold.TrackValue(110,"Laptop", "Nvidia", "DDR4", "39Wh", "1TB");
Configuración de métricas personalizadas

Si desea modificar la configuración de la métrica, debe hacerlo donde se inicializa la métrica.
Nombres de dimensión especiales
Las métricas no usan el contexto de telemetría del elemento TelemetryClient que se usa para acceder a ellas, los
nombres de dimensión especiales disponibles como constantes en la clase MetricDimensionNames son la mejor
solución alternativa para esta limitación.
Los agregados de métricas enviados por la siguiente métrica "Tamaño de solicitud de operación especial" no
tienen establecido Context.Operation.Name en "Operación especial". En su lugar, TrackMetric() o cualquier otro
TrackXXX () tendrán establecido correctamente OperationName en "Operación especial".
//...
TelemetryClient specialClient;
private static int GetCurrentRequestSize()
{
// Do stuff
return 1100;
}
int requestSize = GetCurrentRequestSize()

{
{
//...
specialClient.Context.Operation.Name = "Special Operation";
specialClient.GetMetric("Special Operation Request Size").TrackValue(requestSize);
//...
}
En este caso, use los nombres de dimensión especiales que aparecen en la clase MetricDimensionNames para
especificar los valores de TelemetryContext .
Por ejemplo, cuando el agregado de métricas resultante de la siguiente instrucción se envía al punto de conexión
en la nube de Application Insights, el campo de datos Context.Operation.Name estará establecido en "Operación
especial":
_telemetryClient.GetMetric("Request Size",
MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation");
Los valores de esta dimensión especial se copiarán en TelemetryContext y no se utilizarán como una dimensión
"normal". Si también desea mantener una dimensión de operación para la exploración normal de métricas, debe
crear una dimensión independiente para ese propósito:
_telemetryClient.GetMetric("Request Size", "Operation Name",
MetricDimensionNames.TelemetryContext.Operation.Name).TrackValue(requestSize, "Special Operation", "Special
Operation");
Límites de las dimensiones y las series temporales

Para evitar que el subsistema de telemetría agote accidentalmente los recursos, puede controlar el número
máximo de series de datos por métrica. Los límites predeterminados son no más de 1 000 series de datos totales
por métrica y no más de 100 valores diferentes por dimensión.
En el contexto de los límites de dimensiones y series temporales, utilice Metric.TrackValue(..) para asegurarse de
que se observan los límites. Si se han alcanzado los límites, Metric.TrackValue(..) devolverá "False" y no se
realizará seguimiento del valor. De lo contrario, devolverá "True". Esto resulta útil si los datos de una métrica se
originan a partir de los datos proporcionados por el usuario.
El constructor MetricConfiguration toma algunas opciones para administrar series diferentes dentro de la métrica
respectiva y un objeto de una clase que implementa IMetricSeriesConfiguration , que especifica el
comportamiento de agregación para cada serie individual de la métrica:
var metConfig = new MetricConfiguration(seriesCountLimit: 100, valuesPerDimensionLimit:2,

new MetricSeriesConfigurationForMeasurement(restrictToUInt32Values: false));
Metric computersSold = _telemetryClient.GetMetric("ComputersSold", "Dimension1", "Dimension2", metConfig);
// Start tracking.
computersSold.TrackValue(100, "Dim1Value1", "Dim2Value1");
// The following call gives 3rd unique value for dimension2, which is above the limit of 2.
// The above call does not track the metric, and returns false.
seriesCountLimit es el número máximo de series temporales de datos que puede contener una métrica. Una
vez alcanzado este límite, se llama a TrackValue() .
valuesPerDimensionLimit limita el número de valores distintos por dimensión de forma similar.
restrictToUInt32Values determina si solo se debe realizar el seguimiento de los valores enteros no negativos.
Este es un ejemplo de cómo enviar un mensaje para saber si se han superado los límites:
if (! computersSold.TrackValue(100, "Dim1Value1", "Dim2Value3"))

{
// Add "using Microsoft.ApplicationInsights.DataContract;" to use SeverityLevel.Error
_telemetryClient.TrackTrace("Metric value not tracked as value of one of the dimension exceeded the cap.
Revisit the dimensions to ensure they are within the limits",
SeverityLevel.Error);
}
Pasos siguientes
Más información sobre la supervisión de aplicaciones de servicio de trabajo.
Más información sobre las métricas basadas en registros y agregadas previamente.
Cómo habilitar Application Insights para aplicaciones ASP.NET Core
Cómo habilitar Application Insights para aplicaciones ASP.NET
Diagnósticos detallados para servicios y aplicaciones
¿Por qué necesito Application Insights?

Application Insights supervisa la ejecución de la aplicación web. Indica los errores y problemas de rendimiento y le
ayuda a analizar el modo en que los clientes usan las aplicaciones. Sirve para aplicaciones que se ejecutan en
muchas plataformas (ASP.NET, Java EE, Node.js, etc.) y se hospeda en la nube o en el entorno local.
Resulta fundamental para supervisar una aplicación moderna mientras se ejecuta. Y lo más importante, puede
detectar los errores antes que la mayoría de sus clientes. También puede detectar y resolver problemas de
rendimiento que, si bien no son catastróficos, quizás ralenticen la velocidad del sistema u ocasionen algún
inconveniente a los usuarios. Y si el sistema rinde como espera, querrá saber lo que hacen con él los usuarios:
¿usan las características más recientes? ¿Les funcionan bien?
Las aplicaciones web modernas se desarrollan en un ciclo de entrega continua: lanzan una nueva característica o
mejora, observan cómo funciona para los usuarios y, en función de esa información, planean el siguiente
incremento de desarrollo. Una parte fundamental de este ciclo es la fase de observación. Application Insights
proporciona las herramientas para supervisar el rendimiento y uso de una aplicación web.
El aspecto más importante de este proceso es el diagnóstico. Si una aplicación no funciona correctamente, el
negocio se pierde. Por lo tanto, el papel fundamental de un marco de supervisión es detectar los errores de manera
confiable, notificarlos inmediatamente y presentar la información necesaria para diagnosticar el problema. Esto es
exactamente lo que hace Application Insights.
¿De dónde proceden los errores?
Los errores de los sistemas web proceden normalmente de problemas de configuración o de interacciones
incorrectas entre sus muchos componentes. La primera tarea al abordar un incidente en un sitio activo es, por lo
tanto, identificar la raíz del problema: ¿qué componente o relación es la causa?
Algunos de nosotros, los más veteranos, podemos recordar una época más sencilla en la que un programa
informático se ejecutaba en un equipo. Los desarrolladores lo probaban a fondo antes de enviarlo; y, una vez
enviado, era muy raro volver verlo o acordarse de él. Los usuarios tenían que soportar los errores residuales
durante muchos años.
Ahora, las cosas son muy diferentes. La aplicación se ejecuta en una enorme cantidad de dispositivos diferentes y
puede ser difícil garantizar el mismo comportamiento exacto en cada uno. El hospedaje de aplicaciones en el nube
significa que los errores se puede resolver más rápido, pero también una continua rivalidad y la expectativa de
nuevas características a intervalos frecuentes.
En estas condiciones, la única manera de mantener un control estricto sobre el número de errores es la prueba
unitaria automatizada. Sería imposible volver a probarlo todo manualmente en cada entrega. La prueba unitaria es
ahora una parte común del proceso de compilación. Herramientas como la ayuda de Xamarin Test Cloud ayudan al
proporcionar pruebas automatizadas de la interfaz de usuario en varias versiones de explorador. Estos regímenes
de pruebas nos permiten tener la esperanza de que la tasa de errores encontrados en una aplicación se pueda
mantener al mínimo.
Las aplicaciones web típicas tienen muchos componentes activos. Además del cliente (en una aplicación de
explorador o dispositivo) y el servidor web, es probable que haya bastante procesamiento back-end. Quizás el
back-end es una canalización de componentes o una colección de piezas de colaboración más flexible. Y muchos de
ellos no estarán bajo su control, y son servicios externos de los que depende.
En este tipo de configuraciones, puede ser difícil y costoso probar, o predecir, cada posible modo de error, que no
sea el propio sistema activo.
Preguntas...
Algunas preguntas que hacemos cuando desarrollamos un sistema web:
¿Se bloqueará mi aplicación?
¿Qué ha sucedido exactamente? Si una solicitud ha dado error, quiero saber cómo hemos llegado hasta aquí.
Necesitamos un seguimiento de eventos...
¿Es mi aplicación lo suficientemente rápida? ¿Cuánto tarda en responder a solicitudes normales?
¿Puede administrar el servidor la carga? Cuando aumenta la tasa de solicitudes, ¿se mantiene estable el tiempo
de respuesta?
¿Cuál es la capacidad de respuesta de mis dependencias? (las API de REST, las bases de datos y otros
componentes a los que llama mi aplicación). En concreto, si el sistema es lento, ¿se debe a alguno de mis
componentes o a otra cosa?
¿Está mi aplicación activa o inactiva? ¿se puede ver desde cualquier parte del mundo? Quiero saber si se
detiene....
¿Cuál es la causa? ¿Se debe el error a un componente o una dependencia? ¿Es un problema de comunicación?
¿Cuántos usuarios están afectados? Si tiene varios problemas a los que hacer frente, ¿cuál es el más
importante?

1. Application Insights instrumenta la aplicación y envía datos de telemetría sobre ella mientras esta se ejecuta.
Puede general el SDK de Application Insights en la aplicación o aplicar la instrumentación en tiempo de
ejecución. El primer método es más flexible, ya que puede agregar sus propios datos de telemetría a los
módulos normales.
2. Estos datos se envían al portal de Application Insights, donde se almacenan y procesan. (Aunque Application
Insights se hospeda en Microsoft Azure, puede supervisar cualquier aplicación web, no solo las de Azure).
3. La información de telemetría se presenta en forma de gráficos y tablas de eventos.
Hay dos tipos principales de telemetría: instancias agregadas y sin formato.
Por ejemplo, los datos de instancia incluyen un informe de una solicitud que ha recibido la aplicación web. Se
pueden buscar e inspeccionar los detalles de una solicitud mediante la herramienta de búsqueda del portal de
Application Insights. La instancia incluiría datos, como el tiempo que la aplicación ha tardado en responder a la
solicitud, la dirección URL solicitada, la ubicación aproximada del cliente y otros datos.
Los datos agregados incluyen recuentos de eventos por unidad de tiempo, de modo que puede comparar la
tasa de solicitudes con los tiempos de respuesta. También incluyen los promedios de las métricas, como los
tiempos de respuesta de solicitud.
Las principales categorías de datos son:
Solicitudes a la aplicación (normalmente solicitudes HTTP), con datos sobre dirección URL, tiempo de respuesta
y éxito o error.
Dependencias: llamadas de REST y SQL realizadas por la aplicación, también con identificador URI, tiempos de
respuesta y éxito.
Excepciones, que incluyen seguimientos de pila.
Datos de vista de página, que proceden de los exploradores de los usuarios.
Métricas, como contadores de rendimiento, y métricas escritas por usted mismo.
Eventos personalizados que puede utilizar para realizar el seguimiento de eventos empresariales.
Seguimientos de registros usados para la depuración.
Caso práctico: Real Madrid F.C.

El servicio web del Club de fútbol del Real Madrid presta servicio a aproximadamente 450 millones de aficionados
de todo el mundo. Los aficionados acceden a él tanto mediante exploradores web como las aplicaciones móviles
del Club. No solo reservan entradas, sino que también acceden a información y a clips de vídeo sobre resultados,
jugadores y próximos partidos. Pueden realizar búsquedas con filtros, como el número de goles marcados.
También hay vínculos a redes sociales. La experiencia del usuario está enormemente personalizada y está diseñada
como una comunicación bidireccional para favorecer la participación de los aficionados.
La solución es un sistema de servicios y aplicaciones en Microsoft Azure. La escalabilidad es un requisito clave: el
tráfico es variable y puede alcanzar volúmenes elevados antes y durante los partidos.
Para el Real Madrid, es fundamental supervisar el rendimiento del sistema. Azure Application Insights ofrece una
vista completa del sistema, lo que garantiza un nivel de servicio alto y confiable.
El Club también obtiene un profundo conocimiento de sus aficionados: dónde están (solo el 3 % está en España),
qué interés tienen en los jugadores, los resultados históricos y los próximos partidos y cómo responden a los
resultados de los partidos.
La mayoría de estos datos de telemetría se recopilan automáticamente sin ningún código adicional, lo que
simplifica la solución y reduce la complejidad operacional. Para el Real Madrid, Application Insights trata con 3800
millones de puntos de datos de telemetría al mes.
El Real Madrid utiliza el módulo Power BI para ver estos datos.
Detección inteligente
Proactive diagnostics es una característica reciente. Sin ninguna configuración especial por parte del usuario,
Application Insights detecta y le avisa automáticamente de cualquier aumento en la tasa de errores en la aplicación.
Es lo suficientemente inteligente como para omitir un trasfondo de errores ocasionales y también de aumentos
que son simplemente proporcionales a un aumento en las solicitudes. Por ejemplo, si se produce un error en uno
de los servicios de los que depende, o si la nueva compilación que acaba de implementar no funciona tan bien, lo
sabrá en cuanto mire su correo electrónico. (Y hay webhooks para que pueda desencadenar otras aplicaciones).
Otro aspecto de esta característica es que realiza un análisis exhaustivo a diario de los datos de telemetría,
buscando patrones de rendimiento poco habituales difíciles de detectar. Por ejemplo, puede encontrar un
rendimiento lento asociado a una zona geográfica determinada, o a una versión de explorador determinada.
En ambos casos, la alerta no solo indica los síntomas detectados, sino que también ofrece datos que necesita para
diagnosticar el problema, como los informes de excepciones pertinentes.
El cliente Samtec afirmó: "Durante una migración reciente de características, nos encontramos con una base de
datos no escalada lo suficiente que estaba llegando al límite de sus recursos y ocasionando tiempos de espera. Las
alertas de detección proactiva nos salvaron literalmente mientras clasificábamos el problema, casi en tiempo real
como anunciábamos. Estas alertas junto con las alertas de la plataforma Azure nos ayudaron a solucionar el
problema de forma casi instantánea. Tiempo de inactividad total < 10 minutos".
Secuencia de métricas en directo

La implementación de la compilación más reciente puede ser una experiencia Implementar la compilación más
reciente puede ser una experiencia inquietante. Si hay problemas, querrá saberlo enseguida para poder dar marcha
atrás en caso necesario. La secuencia de métricas activas le proporciona métricas claves con una latencia de
aproximadamente un segundo.
Y le permite inspeccionar inmediatamente una muestra de los errores o excepciones.
Mapa de aplicación
El mapa de aplicación detecta automáticamente la topología de la aplicación y sitúa la información del rendimiento
en primer lugar, para que pueda identificar fácilmente los cuellos de botella y los flujos problemáticos en su
entorno distribuido. Además, permite detectar dependencias de aplicaciones en servicios de Azure. Al comprender
si el problema está relacionado con el código o con las dependencias puede clasificarlo y, en un solo lugar,
profundizar en la experiencia relacionada con el diagnóstico. Por ejemplo, puede que los errores de la aplicación se
deban a la degradación del rendimiento en el nivel de SQL. Con el mapa de aplicación, puede verlo
inmediatamente y profundizar en la experiencia de SQL Index Advisor o de Query Insights.
Application Insights Analytics

Con Analytics, puede escribir consultas arbitrarias en un lenguaje avanzado, tipo SQL. El diagnóstico en la pila
entera de aplicaciones se convierte en una tarea sencilla gracias a la conexión de diversas perspectivas, y puede
formular las preguntas adecuadas para correlacionar el rendimiento del servicio con las métricas empresariales y
la experiencia del cliente.
Puede consultar todas instancias de telemetría y los datos sin procesar de métricas en el portal. El lenguaje incluye
el filtro, unión, agregación y otras operaciones. Puede calcular campos y realizar análisis estadísticos. Dispone de
visualizaciones tanto gráficas como tabulares.
Por ejemplo, es fácil:
Segmentar los datos de rendimiento de solicitud de la aplicación por niveles de clientes para comprender su
experiencia.
Buscar códigos de error específicos o nombres de eventos personalizado durante las investigaciones del sitio
activo.
Profundizar en el uso de aplicaciones de clientes específicos para entender cómo se adquieren y adoptar las
características.
Realizar un seguimiento de las sesiones y los tiempos de respuesta para usuarios específicos para que los
equipos de operaciones y soporte técnico puedan proporcionar soporte al cliente al instante.
Determinar las características de aplicaciones utilizadas con frecuencia para responder a preguntas de
priorización de características.
El cliente DNN afirmó: "Application Insights nos ha proporcionado la parte que faltaba de la ecuación para poder
combinar, ordenar, consultar y filtrar los datos de acuerdo con nuestras necesidades. Al permitir que nuestro
equipo use su propio ingenio y experiencia para buscar datos con un lenguaje de consulta avanzado, hemos
podido descubrir cosas y resolver problemas que ni siquiera sabíamos que teníamos. Un gran número de
respuestas interesantes proceden de las preguntas que comienzan con 'Me pregunto si...' ".
Integración de herramientas de desarrollo

Visual Studio y Eclipse tienen herramientas para configurar los paquetes SDK correctos para el proyecto que está
desarrollando. Hay un comando de menú para agregar Application Insights.
Si usa una plataforma de registro de seguimiento, como Log4N, NLog o System.Diagnostics.Trace, tiene la opción
de enviar los registros a Application Insights junto con los demás datos de telemetría, de modo que pueda
correlacionar fácilmente los seguimientos con solicitudes, llamadas de dependencia y excepciones.
Telemetría de búsqueda en Visual Studio
Al desarrollar y depurar una característica, puede ver y buscar la telemetría directamente en Visual Studio, con las
mismas utilidades de búsqueda que en el portal web.
Y cuando Application Insights registra una excepción, puede ver el punto de datos en Visual Studio y saltar
directamente al código pertinente.
Durante la depuración, tiene la opción de conservar los datos de telemetría en el equipo de desarrollo y verlos en
Visual Studio sin enviarlos al portal. Esta opción local evita mezclar la depuración con la telemetría de producción.
Elementos de trabajo
Cuando se genera una alerta, Application Insights puede crear automáticamente un elemento de trabajo en su
sistema de seguimiento de trabajos.
Pero, ¿y qué sucede con...?

Privacidad y almacenamiento : la telemetría se mantiene en servidores seguros de Azure.
Rendimiento: el impacto es muy bajo. la telemetría se procesa por lotes.
Precios : puede comenzar de forma gratuita y continuar así mientras el volumen sea bajo.
Vídeo
Pasos siguientes
Empezar a usar Application Insights es fácil. Tiene opciones principalmente para:
Servidores IIS y también para Azure App Service.
Instrumentar el proyecto durante el desarrollo. Puede hacerlo para aplicaciones de ASP.NET o Java, así como
para Node.js y otros tipos.
Instrumentar cualquier página web agregando un fragmento de código corto.
Supervisar el rendimiento de aplicaciones web
Asegúrese de que la aplicación tendrá un rendimiento correcto y descubra rápidamente los posibles errores.
Application Insights le indicará las excepciones y los problemas de rendimiento, y lo ayudará a buscar y
diagnosticar las causas principales.
Application Insights puede supervisar aplicaciones y servicios web Java y ASP.NET y servicios WCF. Pueden estar
hospedados localmente, en máquinas virtuales o como sitios web de Microsoft Azure.
En el lado del cliente, Application Insights puede obtener datos de telemetría de páginas web y una amplia
variedad de dispositivos, entre los que se incluyen iOS, Android y aplicaciones de la Tienda Windows.
Configuración de la supervisión de rendimiento

Si todavía no ha agregado Application Insights a un proyecto (es decir, si no dispone de ApplicationInsights.config),
puede comenzar con uno de estos procedimientos:
Aplicaciones web ASP.NET
Agregar supervisión de excepciones
Agregar supervisión de dependencias
Aplicaciones web de Java EE
Exploración de las métricas de rendimiento

En el Portal de Azure, busque el recurso de Application Insights que configuró para la aplicación. La hoja de
información general muestra los datos de rendimiento básicos:
Haga clic en cualquier gráfico para ver su contenido con mayor detalle y los resultados durante más tiempo. Por
ejemplo, haga clic en el mosaico Solicitudes y seleccione un intervalo de tiempo:
Haga clic en un gráfico para elegir las métricas mostradas o para agregar un nuevo gráfico y seleccionar sus
métricas:
NOTE
Desactive todas las métricas para ver todas las métricas disponibles. Las métricas se organizan en grupos. Cuando se
selecciona un miembro de un grupo, solo aparecen los demás miembros de dicho grupo.
¿Qué significa todo esto? Informes y mosaicos de rendimiento
Puede obtener una gran variedad de métricas de rendimiento. Comencemos por las que aparecen de forma
predeterminada en la hoja de la aplicación.
Requests
El número de solicitudes HTTP que se reciben en un período específico. Compare este dato con los resultados de
otros informes para ver cómo se comporta la aplicación cuando la carga varía.
Las solicitudes HTTP incluyen todas las solicitudes GET o POST de páginas, datos e imágenes.
Haga clic en el mosaico para obtener las cuentas de URL específicas.
Tiempo medio de respuesta
Mide el tiempo entre la entrada de una solicitud web y la devolución de la respuesta correspondiente.
Los puntos muestran una media móvil. Si hay muchas solicitudes, es posible que algunas de ellas se desvíen de la
media sin que en el gráfico se muestre ningún pico o descenso evidente.
Busque picos poco habituales. Por lo general, el tiempo de respuesta aumenta cuando aumentan las solicitudes. Si
este aumento es desproporcionado, la aplicación puede alcanzar el límite de recursos (por ejemplo, de CPU o de
un servicio que esté usando).
Haga clic en el icono para obtener los tiempos de direcciones URL concretas.
Solicitudes más lentas
Muestra las solicitudes que pueden precisar un ajuste de rendimiento.

Error en las solicitudes
Un recuento de las solicitudes que inician excepciones no detectadas.
Haga clic en el mosaico para ver los detalles de errores específicos y seleccione una solicitud individual para
revisarla de forma más exhaustiva.
Solo se conserva una muestra representativa de los errores para su inspección individual.
Otras métricas
Si desea ver las demás métricas que puede mostrar, haga clic en un gráfico y desactive todas las métricas para ver
el conjunto completo de opciones disponibles. Haga clic en (i) para ver la definición de cada métrica.
Si selecciona una métrica, se deshabilitan las demás, por lo que no pueden aparecer en el mismo gráfico.
Establecer alertas
Para recibir notificaciones por correo electrónico de los valores no habituales de cualquier métrica, agregue una
alerta. Puede decidir si se debe enviar un mensaje de correo electrónico a los administradores de cuentas o a
direcciones de correo electrónico específicas.
Establezca el recurso antes de las demás propiedades. No elija los recursos de la prueba web si desea establecer
alertas en las métricas de rendimiento o de uso.
Asegúrese de tener en cuenta las unidades en las que se le pide que escriba el valor de umbral.
No puedo ver el botón Agregar alerta : ¿es una cuenta de grupo a la que tiene acceso de solo lectura? Consulte con
el administrador de cuenta.
Diagnóstico de problemas
Para buscar y diagnosticar problemas de rendimiento, lea estas sugerencias:
Configure las pruebas web para recibir una alerta si el sitio web deja de funcionar o si no responde
correctamente, o lo hace más lentamente de lo habitual.
Compare el recuento de Solicitudes con otras métricas para ver si la lentitud de respuesta o los errores se
encuentran relacionados con la carga.
Inserte y busque instrucciones de seguimiento en el código para facilitar la identificación de los problemas.
Supervise el funcionamiento de la aplicación web con Live Metrics Stream.
Capture el estado de una aplicación .NET con Snapshot Debugger.
Búsqueda y corrección de cuellos de botella en el rendimiento con la

experiencia de investigación interactiva del rendimiento
Puede usar la experiencia de investigación del rendimiento para revisar las operaciones de ejecución lenta en su
aplicación web. Puede seleccionar una operación específica lenta rápidamente y usar Profiler para encontrar la
causa del funcionamiento lento en el código. Use la distribución de la nueva duración que se muestra para la
operación seleccionada para evaluar rápidamente cómo perciben la experiencia los clientes. Puede ver cuántas de
sus interacciones de usuario se vieron afectadas por cada operación lenta. En el siguiente ejemplo, hemos decidido
echar un vistazo más de cerca a la experiencia de la operación GET Customers/Details. En la distribución de
duración podemos ver que hay tres picos. El pico del extremo izquierdo es de, aproximadamente, 400 ms y
representa una experiencia con una gran capacidad de respuesta. El pico intermedio es de, aproximadamente, 1,2 s
y representa una experiencia mediocre. Finalmente, en 3,6 s tenemos un pequeño aumento que representa la
experiencia de percentil 99, lo que podría hacer que nuestros clientes se fueran insatisfechos. Esta experiencia es
diez veces más lenta que la experiencia excelente de la misma operación.
Para obtener una mejor idea de las experiencias de usuario para esta operación, podemos seleccionar un intervalo
de tiempo mayor. A continuación, podemos reducir el tiempo a un intervalo concreto en que la operación fue lenta.
En el siguiente ejemplo hemos cambiado el valor predeterminado de 24 horas por el de 7 días y hemos ampliado
el periodo entre 9:47 y 12:47 del martes 12 y el miércoles 13. La distribución de la duración y el número de
seguimientos de Profiler y de ejemplo se han actualizado a la derecha.
Para limitar las experiencias lentas, a continuación, ampliamos las duraciones situadas en el percentil entre 95 y 99.
Estas representan el 4 % de las interacciones del usuario que eran lentas.
Ahora podemos observar los ejemplos representativos haciendo clic en el botón Ejemplos o los seguimientos de
Profiler haciendo clic en el botón Seguimientos de Profiler. En este ejemplo hay cuatro seguimientos que se han
recopilado para obtener clientes y detalles en el periodo de tiempo y el intervalo de duración de interés.
A veces, el problema no estará en el código, sino en una dependencia que invoca el código. Puede cambiar a la
pestaña Dependencias de la vista de evaluación de prioridades para investigar tales dependencias lentas. De forma
predeterminada, la vista de rendimiento muestra medias de tendencia, pero el dato relevante es el del percentil 95
(o 99, en caso de que esté supervisando un servicio consolidado). En el siguiente ejemplo, nos hemos centrado en
la dependencia de blob de Azure lenta, donde se invocó PUT fabrikamaccount. Las buenas experiencias se agrupan
alrededor de los 40 ms, mientras que las llamadas lentas a la misma dependencia son tres veces más lentas,
aproximadamente 120 ms. No se necesitan muchas llamadas para que la operación respectiva se ralentice
considerablemente. Puede profundizar en los ejemplos representativos y seguimientos de Profiler, exactamente
igual que con la pestaña operaciones.
La experiencia de investigación de rendimiento muestra conclusiones significativas a la largo del conjunto de

muestra en el que ha decido centrarse. La mejor manera de buscar en todas las informaciones disponibles es
cambiar a un intervalo de tiempo de 30 días y, a continuación, seleccionar Información general para ver
información de todas las operaciones del mes pasado.
Pasos siguientes
Pruebas web: reciba solicitudes web en su aplicación de forma periódica desde distintos lugares del mundo.
Capture y busque seguimientos de diagnóstico: inserte llamadas de seguimiento y cribe los resultados para
identificar los problemas.
Seguimiento del uso: averigüe cuántas personas usan la aplicación.
Solución de problemas: con preguntas y respuestas
¿Cuántos recursos de Application Insights se
deben implementar?
Cuando esté desarrollando la próxima versión de una aplicación web, no querrá mezclar la telemetría de
Application Insights de la nueva versión con la que ya se ha publicado. Para evitar confusiones, envíe la
telemetría de las distintas fases de desarrollo para separar los recursos de Application Insights con claves de
instrumentación independientes (iKey). Para que sea más fácil cambiar la clave de instrumentación cuando
pase una versión de una fase a otro, puede ser útil establecer la clave iKey en el código en lugar de en el
archivo de configuración.
(Si el sistema es un servicio en la nube de Azure, hay otra forma de configurar claves separadas).
Acerca de los recursos y las claves de instrumentación

Al configurar la supervisión de Application Insights para su aplicación web, se crea un recurso de Application
Insights en Microsoft Azure. Abra este recurso en Azure Portal con el fin de ver y analizar la telemetría
recopilada de la aplicación. Cada recurso se identifica con una clave de instrumentación (iKey). Cuando se
instala el paquete de Application Insights para supervisar la aplicación, configúrelo con la clave de
instrumentación para que sepa dónde enviar la telemetría.
Cada recurso de Application Insights incluye métricas disponibles de serie. En caso de que componentes
totalmente independientes notifican al mismo recurso de Application Insights, puede que estas métricas no
tengan sentido para el panel o la alerta.
Cuándo usar un único recurso de Application Insights
En componentes de aplicaciones que se han implementado juntos. Normalmente han sido desarrollados
por un solo equipo, administrados por el mismo conjunto de usuarios de DevOps/ITOps.
Si tiene sentido agregar indicadores clave de rendimiento (KPI), como las duraciones de las respuestas, las
tasas de error en el panel, etc., en todos ellos de forma predeterminada (puede optar por segmentar por
nombre de rol en la experiencia del Explorador de métricas).
Si no hay necesidad de administrar el control de acceso basado en rol (RBAC) de manera diferente entre
los componentes de aplicaciones.
Si no necesita criterios de alerta de métricas diferentes entre los componentes.
Si no necesita administrar exportaciones continuas de forma distinta entre los componentes.
Si no necesita administrar facturaciones o cuotas de forma distinta entre los componentes.
Si es correcto tener una clave de API con el mismo acceso a los datos de todos los componentes. Diez
claves de API son suficientes para las necesidades en todos ellos.
Si es correcto tener la misma detección inteligente y la misma configuración de integración de elementos
de trabajo en todos los roles.
Otros aspectos que se deben tener en cuenta
Es posible que tenga que agregar código personalizado para asegurarse de que se establezcan valores
significativos en el atributo Cloud_RoleName. Sin valores significativos establecidos para este atributo,
NINGUNA de las experiencias del portal va a funcionar.
En el caso de las aplicaciones de Service Fabric y los servicios en la nube clásicos, el SDK lee
automáticamente del entorno de roles de Azure y los establece. En todos los demás tipos de aplicaciones,
es probable que tenga que establecer esto de forma explícita.
La experiencia de Live Metrics no admite la división por nombre de rol.

Para que sea más fácil cambiar el valor de iKey cuando el código pasa por las fases de producción, referencie
la clave de forma dinámica en el código, en lugar de utilizar un valor estático o que se haya codificado de
forma rígida.
Establezca la clave en un método de inicialización, como global.aspx.cs en un servicio de ASP.NET:

{
Microsoft.ApplicationInsights.Extensibility.
// - for example -
WebConfigurationManager.AppSettings["ikey"];
...
En este ejemplo, las ikeys para los distintos recursos se colocan en diferentes versiones del archivo de
configuración web. Si cambia el archivo de configuración web (algo que se puede hacer como parte del script
de lanzamiento), se intercambiará el recurso de destino.
Páginas web
La clave de instrumentación también se usa en las páginas web de la aplicación, en el script obtenido del
panel de inicio rápido. En vez de codificarla literalmente en el script, genérela desde el estado del servidor.
Por ejemplo, en una aplicación ASP.NET:
// Standard Application Insights web page script:
var appInsights = window.appInsights || function(config){ ...
// Modify this part:
}({instrumentationKey:
// Generate from server property:
"@Microsoft.ApplicationInsights.Extensibility.
TelemetryConfiguration.Active.InstrumentationKey"
}
)
//...
Creación de recurso de Application Insights adicionales

Para crear un recurso de Application Insights, siga la guía de creación de recursos.
La clave de instrumentación identifica al recurso que ha creado.
Necesita las claves de instrumentación de todos los recursos a los que la aplicación enviará datos.
Filtrado por número de compilación

Cuando se publica una nueva versión de la aplicación, querrá poder separar la telemetría en las diferentes
versiones.
Puede establecer la propiedad de versión de la aplicación para filtrar los resultados de la búsqueda y del
explorador de métricas.
Hay diferentes métodos de establecer la propiedad de versión de la aplicación.
Establezca directamente:
telemetryClient.Context.Component.Version = typeof(MyProject.MyClass).Assembly.GetName().Version;
Ajuste esa línea en un inicializador de telemetría para asegurarse de que todas las instancias de
TelemetryClient se establecen de forma coherente.
[ASP.NET] Establezca la versión en BuildInfo.config . El módulo web recogerá la versión del nodo
BuildLabel. Incluya este archivo en el proyecto y recuerde que establecer la propiedad Copiar siempre
en el Explorador de soluciones.

<DeploymentEvent xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.microsoft.com/VisualStudio/DeploymentEvent/2013/06">
<ProjectName>AppVersionExpt</ProjectName>
<Build type="MSBuild">
<MSBuild>
<BuildLabel kind="label">1.0.0.2</BuildLabel>
</MSBuild>
</Build>
</DeploymentEvent>
[ASP.NET] Genere BuildInfo.config automáticamente en MSBuild. Para ello, agregue unas líneas a su
archivo .csproj :
<PropertyGroup>
<GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
<IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>
Esto genera un archivo denominado suNombreProyecto.BuildInfo.config. El proceso de publicación

cambia su nombre a BuildInfo.config.
La etiqueta de compilación contiene un marcador de posición (AutoGen_...) al compilar con Visual
Studio. Pero cuando se crea con MSBuild, se rellena con el número de versión correcto.
Para permitir que MSBuild genere números de versión, establezca la versión como 1.0.* en
AssemblyReference.cs.
Versión y seguimiento de versiones

Para realizar el seguimiento de la versión de la aplicación, asegúrese de que buildinfo.config lo genera el
proceso de Microsoft Build Engine. En el archivo .csproj , agregue lo siguiente:
<PropertyGroup>
<GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
<IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>
Cuando tenga la información de la compilación, el módulo web de Application Insights agregará

automáticamente la versión de la aplicación como una propiedad a cada elemento de telemetría. Esto le
permite filtrar por versión al realizar búsquedas de diagnósticos o al explorar métricas.
Tenga en cuenta, sin embargo, que el número de versión de la compilación solo lo genera Microsoft Build
Engine, no la compilación de desarrollador de Visual Studio.
Anotaciones de la versión
Si usa Azure DevOps, puede obtener un marcador de anotación agregado a los gráficos, siempre que
publique una nueva versión.
Pasos siguientes
Recursos compartidos para varios roles
Creación de un inicializador de telemetría para distinguir variantes A/B
¿Cómo ... en Application Insights?
Recibir un correo electrónico cuando...

Enviar un correo electrónico si mi sitio deja de funcionar
Establecer una prueba web de disponibilidad.
Enviar un correo electrónico si mi sitio está sobrecargado
Establecer una alerta en Tiempo de respuesta del ser vidor . Un umbral entre 1 y 2 segundos debería funcionar.
La aplicación también podría mostrar señales de esfuerzo al devolver códigos de error. Establezca una alerta en
Solicitudes con error .
Si quiere establecer una alerta en Excepciones de ser vidor , puede que tenga que realizar alguna configuración
adicional para poder ver los datos.
Envío de excepciones por correo electrónico
1. Configurar supervisión de excepciones
2. Establecer una alerta en la métrica de recuento de excepciones
Enviar un correo electrónico sobre un evento en mi aplicación
Supongamos que quiere recibir un correo electrónico cuando se produce un evento específico. Application Insights
no ofrece esta función directamente, pero puede enviar una alerta cuando una métrica sobrepasa un umbral.
Las alertas se pueden establecer en métricas personalizadas, aunque no así los eventos no personalizados. Escribir
código para aumentar una métrica cuando se produce el evento:
telemetry.TrackMetric("Alarm", 10);
o:
var measurements = new Dictionary<string,double>();

measurements ["Alarm"] = 10;
telemetry.TrackEvent("status", null, measurements);
Dado que las alertas tienen dos estados, debe enviar un valor bajo cuando considere que la alerta ha finalizado:
telemetry.TrackMetric("Alarm", 0.5);
Cree un gráfico en el Explorador de métricas para ver la alarma:
Ahora establezca que se desencadene una alerta cuando la métrica esté por encima de un valor medio durante un
período breve de tiempo:
Establecer el período promedio en el mínimo.

Recibirá mensajes de correo electrónico cuando la métrica esté por encima y por debajo del umbral.
Algunos puntos que se deben tener en cuenta:
Una alerta tiene dos estados ("alerta" y "correcto"). El estado se evalúa solo cuando se recibe una métrica.
Un mensaje de correo electrónico solo se envía cuando cambia el estado. Este es el motivo por el que tiene que
enviar métricas tanto de valores altos como bajos.
Para evaluar la alerta, la media se toma de los valores recibidos durante el período anterior. Esto se produce
cada vez que se recibe una métrica, por lo que los mensajes de correo electrónico se pueden enviar con mayor
frecuencia que el período definido.
Puesto que los correos electrónicos se envían tanto en los estados "alerta" como "correcto", es posible que
considere volver a pensar en su evento monoestable como en una condición de dos estados. Por ejemplo, en
lugar de un evento de "trabajo completado", tiene una condición de "trabajo en curso", donde recibe correos
electrónicos al principio y al final de un trabajo.
Configuración de alertas automáticamente
Uso de PowerShell para crear nuevas alertas
Uso de PowerShell para administrar Application Insights

Creación de nuevos recursos
Creación de nuevas alertas
Telemetría independiente de diferentes versiones

Varias roles en una aplicación: usar un único recurso de Application Insights y filtrar por cloud_NombreDelRol.
Separación de desarrollo, prueba y versiones de lanzamiento: Use diferentes recursos de Application Insights.
Tome las claves de instrumentación de web.config. Más información
Generación de informes de versiones de compilación: agregar una propiedad usando un inicializador de
telemetría. Más información
Supervisar servidores back-end y aplicaciones de escritorio

Use el módulo de SDK de Windows Server.
Panel con métricas de varias aplicaciones
En el explorador de métricas, personalice el gráfico y guárdelo como favorito. Ánclelo al panel de Azure.
Panel con datos de otros orígenes y Application Insights
Exporte la telemetría a Power BI.
Or
Use SharePoint como panel, mostrando los datos en elementos web de SharePoint. Use la exportación continua
y Stream Analytics para exportar a SQL. Use PowerView para examinar la base de datos y crear un elemento web
de SharePoint para PowerView.
Filtrado de usuarios anónimos o autenticados
Si los usuarios inician sesión, puede establecer el identificador de usuario autenticado. (No ocurre
automáticamente).
Seguidamente, puede:
Buscar identificadores de usuario específicos
Filtrar métricas a los usuarios anónimos o autenticados
Modificación de valores o nombres de propiedad

Cree un filtro. Esto le permite modificar o filtrar telemetría antes de que se envíe desde su aplicación a Application
Insights.
Enumeración de usuarios específicos y su uso

Si solo desea buscar usuarios específicos, puede establecer el identificador de usuario autenticado.
Si desea obtener una lista de usuarios con datos como las páginas que ven o la frecuencia con la que inician sesión,
tiene dos opciones:
Establezca el identificador de usuario autenticado, exporte a una base de datos y use las herramientas
adecuadas para analizar los datos de usuario.
Si solo dispone de un número reducido de usuarios, envíe eventos o métricas personalizados, mediante el uso
de los datos de interés como el valor de métrica o el nombre de evento y el establecimiento del identificador de
usuario como una propiedad. Para analizar las vistas de página, reemplace la llamada trackPageView de
JavaScript estándar. Para analizar la telemetría en el servidor, use un inicializador de telemetría para agregar el
identificador de usuario para toda la telemetría de servidor. Después puede filtrar y segmentar las métricas y las
búsquedas en el identificador de usuario.
Reducción del tráfico de la aplicación a Application Insights

En ApplicationInsights.config, deshabilite los módulos que no necesite, como el recopilador de contadores de
rendimiento.
Use Muestreo y filtrado en el SDK.
En las páginas web, limite el número de llamadas AJAX que se notifican para cada vista de página. En el
fragmento de script después de instrumentationKey:... , inserte: ,maxAjaxCallsPerView:3 (o un número
adecuado).
Si está usando TrackMetric, calcule el agregado de los lotes de los valores de métricas antes de enviar el
resultado. Hay una sobrecarga de TrackMetric() que se proporciona para eso.
Obtenga más información sobre precios y cuotas.
Deshabilitar la telemetría
Para iniciar y detener dinámicamente la recopilación y la transmisión de telemetría desde el servidor:
Aplicaciones clásicas de ASP.NET
TelemetryConfiguration.Active.DisableTelemetry = true;
Otras aplicaciones
No se recomienda usar TelemetryConfiguration.Active singleton en la consola o en aplicaciones de ASP.NET Core.
Si ha creado la instancia de TelemetryConfiguration usted mismo, establezca DisableTelemetry en true .
En el caso de las aplicaciones de ASP.NET Core puede acceder a la instancia de TelemetryConfiguration mediante la
inserción de dependencias en ASP.NET Core. Encontrará más información en el artículo Application Insights para
aplicaciones de ASP.NET Core.
Deshabilitación de recopiladores estándar seleccionados

Los recopiladores estándar (por ejemplo, los contadores de rendimiento, las solicitudes HTTP o las dependencias)
se pueden deshabilitar
Aplicaciones ASP.NET : elimine o convierta en comentario las líneas correspondientes en
Aplicaciones ASP.NET Core : siga las opciones de configuración de los módulos de telemetría de Application
Insights para aplicaciones de ASP.NET Core
Visualización de contadores de rendimiento del sistema

Entre las métricas que se pueden mostrar en el Explorador de métricas se encuentra un conjunto de contadores de
rendimiento del sistema. Hay una hoja predefinida denominada Ser vidores que muestra varios de ellos.
Si no ve ningún dato de contadores de rendimiento

ser vidor IIS en su propia máquina o en una VM. Instale el Monitor de estado.
Sitio web de Azure : todavía no se admiten los contadores de rendimiento. Hay varias métricas que se puede
obtener como parte estándar del sitio web de Azure en el panel de control.
Ser vidor Unix - instale collectd
Para mostrar más contadores de rendimiento
En primer lugar, agregue un nuevo gráfico y compruebe si el contador está en el conjunto básico que se ofrece.
Si no es así, agregue el contador al conjunto recopilado por el módulo del contador de rendimiento.
Administración de recursos de Application Insights
mediante PowerShell
NOTE
Este artículo muestra cómo automatizar la creación y actualización de los recursos de Application Insights
automáticamente mediante Azure Resource Management. Puede hacerlo, por ejemplo, como parte de un
proceso de compilación. Junto con el recurso básico de Application Insights, puede crear pruebas web de
disponibilidad, configurar alertas, establecer el esquema de precios y crear otros recursos de Azure.
La clave para crear estos recursos es las plantillas JSON para el Administrador de recursos de Azure. El
procedimiento básico es: descargar las definiciones JSON de los recursos existentes; parametrizar
determinados valores como los nombres; y luego ejecutar la plantilla siempre que se quiera crear un nuevo
recurso. Puede empaquetar varios recursos juntos para crearlos todos en un solo paso, por ejemplo, un
monitor de aplicaciones con pruebas de disponibilidad, alertas y almacenamiento para la exportación
continua. Existen algunos matices a algunas de las parametrizaciones automáticas, que se explican aquí.
Instalación única
Si no ha usado PowerShell con su suscripción de Azure antes:
Instale el módulo de Azure PowerShell en el equipo donde desea ejecutar los scripts:
1. Instale el Instalador de plataforma web de Microsoft (v5 o superior).
2. Úselo para instalar Microsoft Azure PowerShell.
Además de usar plantillas de Resource Manager, existe un completo conjunto de cmdlets de PowerShell en
Application Insights que facilitan la configuración de recursos de Application Insights mediante programación.
Entre las funcionalidades que habilitan los cmdlets se incluyen las siguientes:
Crear y eliminar recursos de Application Insights
Obtener listas de recursos de Application Insights y sus propiedades
Crear y administrar la exportación continua
Crear y administrar claves de aplicación
Establecer el plan de precios
Creación de recursos de Application Insights mediante un cmdlet de

PowerShell
Aquí se muestra cómo crear un nuevo recurso de Application Insights en el centro de datos Este de EE. UU. de
Azure con el cmdlet New-AzApplicationInsights:
New-AzApplicationInsights -ResourceGroupName <resource group> -Name <resource name> -location eastus
Creación de recursos de Application Insights mediante una plantilla

de Resource Manager
Aquí se muestra cómo crear un nuevo recurso de Application Insights mediante una plantilla de Resource
Manager.
Creación de la plantilla de Azure Resource Manager
Cree un nuevo archivo .json. Vamos a llamarlo template1.json en este ejemplo. Copie este contenido en él:
{
"parameters": {
"appName": {
"type": "string",
"metadata": {
"description": "Enter the name of your Application Insights resource."
}
},
"appType": {
"type": "string",
"defaultValue": "web",
"allowedValues": [
"web",
"java",
"other"
],
"metadata": {
"description": "Enter the type of the monitored application."
}
},
"appLocation": {
"type": "string",
"defaultValue": "eastus",
"metadata": {
"description": "Enter the location of your Application Insights resource."
}
},
"type": "int",
"defaultValue": 90,
"allowedValues": [
30,
60,
90,
120,
180,
270,
365,
550,
730
],
"metadata": {
"description": "Data retention in days"
}
},
"ImmediatePurgeDataOn30Days": {
"type": "bool",
"defaultValue": false,
"metadata": {
"description": "If set to true when changing retention to 30 days, older data will be
immediately deleted. Use this with extreme caution. This only applies when retention is being set to 30
immediately deleted. Use this with extreme caution. This only applies when retention is being set to 30
days."
}
},
"priceCode": {
"type": "int",
"defaultValue": 1,
"allowedValues": [
1,
2
],
"metadata": {
"description": "Pricing plan: 1 = Per GB (or legacy Basic plan), 2 = Per Node (legacy
Enterprise plan)"
}
},
"dailyQuota": {
"type": "int",
"minValue": 1,
"metadata": {
"description": "Enter daily quota in GB."
}
},
"dailyQuotaResetTime": {
"type": "int",
"defaultValue": 0,
"metadata": {
"description": "Enter daily quota reset hour in UTC (0 to 23). Values outside the
range will get a random reset hour."
}
},
"warningThreshold": {
"type": "int",
"defaultValue": 90,
"minValue": 1,
"maxValue": 100,
"metadata": {
"description": "Enter the % value of daily quota after which warning mail to be sent.
"
}
}
},
"variables": {
"priceArray": [
"Basic",
"Application Insights Enterprise"
],
"pricePlan": "[take(variables('priceArray'),parameters('priceCode'))]",
"billingplan": "[concat(parameters('appName'),'/', variables('pricePlan')[0])]"
},
"resources": [
{
"kind": "[parameters('appType')]",
"name": "[parameters('appName')]",
"apiVersion": "2014-04-01",
"location": "[parameters('appLocation')]",
"tags": {},
"properties": {
"ApplicationId": "[parameters('appName')]",
"retentionInDays": "[parameters('retentionInDays')]"
},
"dependsOn": []
},
{
"name": "[variables('billingplan')]",
"type": "microsoft.insights/components/CurrentBillingFeatures",
"location": "[parameters('appLocation')]",
"apiVersion": "2015-05-01",
"dependsOn": [
"[resourceId('microsoft.insights/components', parameters('appName'))]"
],
"properties": {
"CurrentBillingFeatures": "[variables('pricePlan')]",
"DataVolumeCap": {
"Cap": "[parameters('dailyQuota')]",
"WarningThreshold": "[parameters('warningThreshold')]",
"ResetTime": "[parameters('dailyQuotaResetTime')]"
}
}
}
]
}
Uso de la plantilla de Resource Manager para crear un nuevo recurso de Application Insights
1. En PowerShell, inicie sesión en Azure mediante $Connect-AzAccount .
2. Establezca el contexto en una suscripción con Set-AzContext "<subscription ID>" .
3. Ejecute una nueva implementación para crear un nuevo recurso de Application Insights:
New-AzResourceGroupDeployment -ResourceGroupName Fabrikam `

-TemplateFile .\template1.json `
-appName myNewApp
-ResourceGroupNamees el grupo donde desea crear los nuevos recursos.

-TemplateFile debe aparecer antes que los parámetros personalizados.
-appName es el nombre del recurso que se va a crear.
Puede agregar otros parámetros, cuyas descripciones se encuentran en la sección de parámetros de la

plantilla.

Después de crear un recurso de aplicación, querrá la clave de instrumentación:
1. $Connect-AzAccount
2. Set-AzContext "<subscription ID>"
3. $resource = Get-AzResource -Name "<resource name>" -ResourceType "Microsoft.Insights/components"
4. $details = Get-AzResource -ResourceId $resource.ResourceId
5. $details.Properties.InstrumentationKey
Para ver una lista de muchas otras propiedades del recurso de Application Insights, use el siguiente comando:
Get-AzApplicationInsights -ResourceGroupName Fabrikam -Name FabrikamProd | Format-List
Dispone de propiedades adicionales a través de los siguientes cmdlets:

Set-AzApplicationInsightsDailyCap
Set-AzApplicationInsightsPricingPlan
Get-AzApplicationInsightsApiKey
Get-AzApplicationInsightsContinuousExport
Consulte la documentación detallada para información sobre los parámetros de estos cmdlets.
Establecimiento de la retención de datos

A continuación se muestran tres métodos para establecer la retención de datos mediante programación en un
recurso de Application Insights.
Establecimiento de la retención de datos mediante comandos de PowerShell
A continuación se muestra un conjunto sencillo de comandos de PowerShell para establecer la retención de
datos para el recurso de Application Insights:
$Resource = Get-AzResource -ResourceType Microsoft.Insights/components -ResourceGroupName

MyResourceGroupName -ResourceName MyResourceName
$Resource.Properties.RetentionInDays = 365
$Resource | Set-AzResource -Force
Establecimiento de la retención de datos mediante REST

Para obtener la retención actual de datos del recurso de Application Insights, puede usar la herramienta OSS
ARMClient (puede obtener más información sobre ARMClient en los artículos de David Ebbo y Daniel
Bowbyes). Este es un ejemplo del uso de ARMClient para obtener la retención actual:
armclient GET /subscriptions/00000000-0000-0000-0000-

00000000000/resourceGroups/MyResourceGroupName/providers/microsoft.insights/components/MyResourceName?
api-version=2018-05-01-preview
Para establecer la retención, se usa un comando PUT similar:

00000000000/resourceGroups/MyResourceGroupName/providers/microsoft.insights/components/MyResourceName?
api-version=2018-05-01-preview "{location: 'eastus', properties: {'retentionInDays': 365}}"
Para establecer la retención de datos en 365 días mediante la plantilla anterior, ejecute:
New-AzResourceGroupDeployment -ResourceGroupName "<resource group>" `

-retentionInDays 365 `
-appName myApp
Establecimiento de la retención de datos mediante un script de PowerShell

El siguiente script también se puede usar para cambiar la retención. Copie este script para guardarlo como
Set-ApplicationInsightsRetention.ps1 .
Param(
[Parameter(Mandatory = $True)]
[string]$SubscriptionId,
[string]$ResourceGroupName,
[string]$Name,
[string]$RetentionInDays
)
$ErrorActionPreference = 'Stop'
if (-not (Get-Module Az.Accounts)) {
Import-Module Az.Accounts
}
$azProfile =
[Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile
if (-not $azProfile.Accounts.Count) {
Write-Error "Ensure you have logged in before calling this function."
}
$currentAzureContext = Get-AzContext
$profileClient = New-Object Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient($azProfile)
$token = $profileClient.AcquireAccessToken($currentAzureContext.Tenant.TenantId)
$UserToken = $token.AccessToken
$RequestUri =
"https://management.azure.com/subscriptions/$($SubscriptionId)/resourceGroups/$($ResourceGroupName)/provi
ders/Microsoft.Insights/components/$($Name)?api-version=2015-05-01"
$Headers = @{
"Authorization" = "Bearer $UserToken"
"x-ms-client-tenant-id" = $currentAzureContext.Tenant.TenantId
}
## Get Component object via ARM
$GetResponse = Invoke-RestMethod -Method "GET" -Uri $RequestUri -Headers $Headers
## Update RetentionInDays property

if($($GetResponse.properties | Get-Member "RetentionInDays"))
{
$GetResponse.properties.RetentionInDays = $RetentionInDays
}
else
{
$GetResponse.properties | Add-Member -Type NoteProperty -Name "RetentionInDays" -Value
$RetentionInDays
}
## Upsert Component object via ARM
$PutResponse = Invoke-RestMethod -Method "PUT" -Uri "$($RequestUri)" -Headers $Headers -Body
$($GetResponse | ConvertTo-Json) -ContentType "application/json"
$PutResponse
Después, este script se puede utilizar para:
Set-ApplicationInsightsRetention `
[-SubscriptionId] <String> `
[-ResourceGroupName] <String> `
[-Name] <String> `
[-RetentionInDays <Int>]
Establecimiento del límite diario

Para obtener las propiedades de límite diario, use el cmdlet Set-AzApplicationInsightsPricingPlan:
Set-AzApplicationInsightsDailyCap -ResourceGroupName <resource group> -Name <resource name> | Format-List
Para establecer las propiedades de límite diario, use el mismo cmdlet. Por ejemplo, para establecer el límite en
300 GB/día:
Set-AzApplicationInsightsDailyCap -ResourceGroupName <resource group> -Name <resource name> -DailyCapGB

300
También puede usar ARMClient para obtener y establecer parámetros de límite diarios. Para obtener los
valores actuales, use:

00000000000/resourceGroups/MyResourceGroupName/providers/microsoft.insights/components/MyResourceName/Cur
rentBillingFeatures?api-version=2018-05-01-preview
Establecimiento del tiempo de restablecimiento del límite diario

Para establecer el tiempo de restablecimiento del límite diario, puede usar ARMClient. Este es un ejemplo de
uso de ARMClient , para establecer el tiempo de restablecimiento en una hora nueva (en este ejemplo 12:00
UTC):

rentBillingFeatures?api-version=2018-05-01-preview "{'CurrentBillingFeatures':['Basic'],'DataVolumeCap':
{'ResetTime':12}}"
Establecimiento del plan de precios

Para obtener el plan de precios actual, use el cmdlet Set-AzApplicationInsightsPricingPlan:
Set-AzApplicationInsightsPricingPlan -ResourceGroupName <resource group> -Name <resource name> | Format-

List
Para establecer el plan de precios, use el mismo cmdlet con la especificación de -PricingPlan :
Set-AzApplicationInsightsPricingPlan -ResourceGroupName <resource group> -Name <resource name> -

PricingPlan Basic
También puede establecer el plan de precios de un recurso de Application Insights existente mediante la
plantilla de Resource Manager anterior, omitiendo el recurso "microsoft.insights/components" y el nodo
dependsOn del recurso de facturación. Por ejemplo, para establecerlo en el plan Por GB (antes plan Básico),
ejecute:
New-AzResourceGroupDeployment -ResourceGroupName "<resource group>" `

-priceCode 1 `
-appName myApp
priceCode se define como:

P RIC EC O DE PLAN
1 Por GB (anteriormente denominado plan Básico)
2 Por nodo (anteriormente denominado plan Enterprise)
Por último, puede usar ARMClient para obtener y establecer planes de precios y parámetros de límite diarios.
Para obtener los valores actuales, use:

Y puede establecer todos estos parámetros mediante:

"{'CurrentBillingFeatures':['Basic'],'DataVolumeCap':
{'Cap':200,'ResetTime':12,'StopSendNotificationWhenHitCap':true,'WarningThreshold':90,'StopSendNotificati
onWhenHitThreshold':true}}"
De este modo, establecerá el límite diario en 200 GB/día, configurará el tiempo de restablecimiento del límite
diario en 12:00 UTC, enviará mensajes de correo electrónico cuando se alcance el límite y se cumpla el nivel
de advertencia, y establecerá el umbral de advertencia en el 90 % del límite.

Para automatizar la creación de las alertas de métricas, consulte el artículo sobre la plantilla de alertas de
métricas.
Agregar una prueba de disponibilidad

Para automatizar las pruebas de disponibilidad, consulte el artículo sobre la plantilla de alertas de métricas.
Agregar más recursos

Para automatizar la creación de otros recursos de cualquier variante, cree un ejemplo manualmente y luego
copie y parametrice su código en Azure Resource Manager.
1. Abra el Administrador de recursos de Azure. Desplácese hacia abajo por
subscriptions/resourceGroups/<your resource group>/providers/Microsoft.Insights/components hasta el
recurso de la aplicación.
Componentes son los recursos básicos de Application Insights para mostrar aplicaciones. Existen
recursos distintos para las reglas de alerta asociadas y las pruebas web de disponibilidad.
2. Copie el código JSON del componente en el lugar adecuado en template1.json .
3. Elimine estas propiedades:
id
InstrumentationKey
CreationDate
TenantId
4. Abra las secciones webtests y alertrules y copie el código JSON de los elementos individuales en la
plantilla. No copie de los nodos webtests o alertrules : vaya a los elementos que hay debajo de ellos.
Cada prueba web tiene una regla de alerta asociada, por lo que tiene que copiar las dos.
También puede incluir alertas en las métricas. Nombres de métricas.
5. Inserte esta línea en cada recurso:
"apiVersion": "2015-05-01",
Parametrización de la plantilla
Ahora, debe reemplazar los nombres específicos por parámetros. Para parametrizar una plantilla, escriba
expresiones mediante un conjunto de funciones auxiliares.
No se puede parametrizar solo una parte de una cadena, así que use concat() para compilar las cadenas.
Éstos son ejemplos de sustituciones que querrá realizar. Hay varias repeticiones de cada sustitución. Y puede
que tenga otras en la plantilla. En estos ejemplos se usan los parámetros y las variables que se han definido
en la parte superior de la plantilla.
F IN D REEM P L A Z A R P O R
"hidden- "[concat('hidden-link:',
link:/subscriptions/.../../components/MyAppName" resourceId('microsoft.insights/components',
parameters('appName')))]"
"/subscriptions/.../../alertrules/myAlertName- "[resourceId('Microsoft.Insights/alertrules',
myAppName-subsId", variables('alertRuleName'))]",
"/subscriptions/.../../webtests/myTestName- "[resourceId('Microsoft.Insights/webtests',
myAppName", parameters('webTestName'))]",
"myWebTest-myAppName" "[variables(testName)]"'
"myTestName-myAppName-subsId" "[variables('alertRuleName')]"
"myAppName" "[parameters('appName')]"
"myappname" (minúscula) "[toLower(parameters('appName'))]"
"<WebTest Name=\"myWebTest\" ... [concat('<WebTest Name=\"',

Url=\"http://fabrikam.com/home\" ...>" parameters('webTestName'),
'\" ... Url=\"', parameters('Url'),
'\"...>')]"
Establecimiento de dependencias entre los recursos

Azure debe instalar los recursos en un orden estricto. Para tener la seguridad de que una instalación finaliza
antes de que comience la siguiente, agregue líneas de dependencia:
En el recurso de la prueba de disponibilidad:
"dependsOn": ["[resourceId('Microsoft.Insights/components', parameters('appName'))]"],
En el recurso de la alerta para una prueba de disponibilidad:

"dependsOn": ["[resourceId('Microsoft.Insights/webtests', variables('testName'))]"],
Pasos siguientes
Otros artículos de automatización:
Script de PowerShell para crear un recurso de Application Insights : método rápido sin necesidad de
plantilla.
Uso de PowerShell para configurar alertas en Application Insights
Creación de pruebas web
Envío de Azure Diagnostics a Application Insights
Creación de anotaciones de versión
Uso de PowerShell para configurar Application
Insights para Azure Cloud Services
Microsoft Azure puede configurarse para que envíe diagnósticos de Azure a Azure Application Insights. Los
diagnósticos están relacionados con Azure Cloud Services y Azure Virtual Machines. Complementan la telemetría
que se envía desde la aplicación mediante el SDK de Application Insights. Como parte de la automatización del
proceso de creación de nuevos recursos en Azure, puede configurar diagnósticos mediante PowerShell.
Plantilla de Azure
Si la aplicación web está en Azure y crea los recursos mediante una plantilla de Azure Resource Manager, puede
configurar Application Insights agregando lo siguiente al nodo de recursos:
{
resources: [
/* Create Application Insights resource */
{
"apiVersion": "2015-05-01",
"name": "nameOfAIAppResource",
"kind": "web",
"properties": { "ApplicationId": "nameOfAIAppResource" },
"dependsOn": [
"[concat('Microsoft.Web/sites/', myWebAppName)]"
]
}
]
}
nameOfAIAppResource : nombre para el recurso de Application Insights

myWebAppName : identificador de la aplicación web
Habilitar la extensión de diagnósticos como parte de la implementación

de un servicio en la nube
El cmdlet New-AzureDeployment tiene un parámetro ExtensionConfiguration , que toma una matriz de
configuraciones de diagnósticos. Estas pueden crearse mediante el cmdlet
New-AzureServiceDiagnosticsExtensionConfig . Por ejemplo:
$service_package = "CloudService.cspkg"
$service_config = "ServiceConfiguration.Cloud.cscfg"
$diagnostics_storagename = "myservicediagnostics"
$webrole_diagconfigpath = "MyService.WebRole.PubConfig.xml"
$workerrole_diagconfigpath = "MyService.WorkerRole.PubConfig.xml"
$primary_storagekey = (Get-AzStorageKey `
-StorageAccountName "$diagnostics_storagename").Primary
$storage_context = New-AzStorageContext `
-StorageAccountName $diagnostics_storagename `
-StorageAccountKey $primary_storagekey
$webrole_diagconfig = `
New-AzureServiceDiagnosticsExtensionConfig `
-Role "WebRole" -Storage_context $storageContext `
-DiagnosticsConfigurationPath $webrole_diagconfigpath
$workerrole_diagconfig = `
New-AzureServiceDiagnosticsExtensionConfig `
-Role "WorkerRole" `
-StorageContext $storage_context `
-DiagnosticsConfigurationPath $workerrole_diagconfigpath
New-AzureDeployment `
-ServiceName $service_name `
-Slot Production `
-Package $service_package `
-Configuration $service_config `
-ExtensionConfiguration @($webrole_diagconfig,$workerrole_diagconfig)
Habilitar la extensión de diagnóstico en un servicio en la nube

existente
En un servicio existente, use Set-AzureServiceDiagnosticsExtension .
$service_name = "MyService"
$diagnostics_storagename = "myservicediagnostics"
$webrole_diagconfigpath = "MyService.WebRole.PubConfig.xml"
$workerrole_diagconfigpath = "MyService.WorkerRole.PubConfig.xml"
$primary_storagekey = (Get-AzStorageKey `
-StorageAccountName "$diagnostics_storagename").Primary
$storage_context = New-AzStorageContext `
-StorageAccountName $diagnostics_storagename `
-StorageAccountKey $primary_storagekey
Set-AzureServiceDiagnosticsExtension `
-DiagnosticsConfigurationPath $webrole_diagconfigpath `
-Slot Production `
-Role "WebRole"
Set-AzureServiceDiagnosticsExtension `
-DiagnosticsConfigurationPath $workerrole_diagconfigpath `
-Slot Production `
-Role "WorkerRole"
Obtener la configuración actual de la extensión de diagnósticos

Get-AzureServiceDiagnosticsExtension -ServiceName "MyService"
Eliminar la extensión de diagnósticos
Remove-AzureServiceDiagnosticsExtension -ServiceName "MyService"
Si ha habilitado la extensión de diagnósticos mediante Set-AzureServiceDiagnosticsExtension o

New-AzureServiceDiagnosticsExtensionConfig sin el parámetro Role, puede quitar la extensión mediante
Remove-AzureServiceDiagnosticsExtension sin el parámetro Role. Si ha usado el parámetro Role al habilitar la
extensión, debe utilizarlo también al quitar la extensión.
Para quitar la extensión de diagnóstico de cada rol individual:
Remove-AzureServiceDiagnosticsExtension -ServiceName "MyService" -Role "WebRole"
Consulte también
Supervisión de aplicaciones de Azure Cloud Service con Application Insights
Envío de Azure Diagnostics a Application Insights
Automatización de la configuración de alertas
Exportación de telemetría desde Application
Insights
¿Desea mantener la telemetría durante más tiempo que el período de retención estándar? ¿O quiere
procesarla de algún modo especializado? La exportación continua es lo más conveniente para ello. Los
eventos que se ven en el portal de Application Insights pueden exportarse a almacenamiento en Microsoft
Azure en formato JSON. Desde allí puede descargar los datos y escribir el código necesario para procesarlos.
NOTE
La exportación continua solo se admite para los recursos clásicos de Application Insights. Los recursos de Application
Insights basados en áreas de trabajo deben usar la configuración de diagnóstico.
Antes de configurar la exportación continua, hay algunas alternativas que conviene tener en cuenta:
El botón Exportar de la parte superior de una pestaña de búsqueda o métricas permite transferir tablas
y gráficos a una hoja de cálculo de Excel.
Analytics proporciona un lenguaje de consulta eficaz para telemetría. También puede exportar los
resultados.
Si lo que le interesa es explorar los datos en Power BI, puede hacerlo sin usar la exportación continua.
La API de REST de acceso a datos le permite acceder a datos de telemetría con programación.
También puede acceder a la configuración de la exportación continua a través de PowerShell.
Cuando la exportación continua copie sus datos en el almacenamiento (donde pueden permanecer tanto
tiempo como quiera), seguirán estando disponibles en Application Insights durante el período de retención
habitual.
Configuración avanzada del almacenamiento de exportación

continua
La exportación continua no admite las siguientes características o configuraciones del almacenamiento de
Azure:
El uso de los firewalls de VNET o Azure Storage junto con Azure Blob Storage.
Azure Data Lake Storage Gen2.
Creación de una exportación continua.

1. En el recurso de Application Insights de su aplicación en Configuración, a la izquierda, abra
Exportación continua y elija Agregar :
2. Elija los tipos de datos de telemetría que quiere exportar.
3. Cree o seleccione una cuenta de almacenamiento de Azure donde quiera almacenar los datos. Para
más información sobre las opciones de precios de almacenamiento, visite la página oficial de precios.
Haga clic en Agregar, Destino de exportación, Cuenta de almacenamiento y cree un nuevo almacén o
elija uno.
WARNING
De forma predeterminada, la ubicación de almacenamiento se establecerá en la misma región geográfica que el
recurso de Application Insights. Si los almacena en una región diferente, puede conllevar gastos de
transferencia.
4. Cree o seleccione un contenedor en el almacenamiento.
NOTE
Una vez que haya creado la exportación, los datos recién ingeridos comenzarán a fluir a Azure Blob Storage. Una
exportación continua solo transmitirá telemetría nueva que se crea o se ingiere después de habilitar la exportación
continua. Los datos que existían antes de habilitar la exportación continua no se exportarán y no hay manera de
exportar de forma retroactiva los datos creados anteriormente, con la exportación continua.
Puede haber un retraso de aproximadamente una hora antes de que aparezcan los datos en el
almacenamiento.
Una vez completada la primera exportación, encontrará una estructura similar a la siguiente en el contenedor
de Azure Blob Storage: (Variará en función de los datos que recopile).
Disponibilidad Notifica sobre pruebas web de disponibilidad.
Evento Eventos personalizados generados por TrackEvent().
Excepciones Notifica sobre excepciones en el servidor y en el explorador.
Mensajes Enviados por TrackTrace y por los adaptadores de registro.
Métricas Generado por llamadas de la API de métricas.
PerformanceCounters Contadores de rendimiento recopilados por Application

Insights.
Solicitudes Enviado por TrackRequest. Los módulos estándar usan esto

para informar sobre el tiempo de respuesta del servidor,
medido en el propio servidor.
Para editar la exportación continua

Haga clic en Exportación continua y seleccione la cuenta de almacenamiento que desee editar.
Para detener la exportación continua
Para detener la exportación, haga clic en Deshabilitar. Al hacer clic en Habilitar de nuevo, la exportación se
reinicia con nuevos datos. No obtendrá los datos que llegaron al portal mientras estaba deshabilitada la
exportación.
Para detener la exportación de forma permanente, elimínela. Al realizar esta acción no se eliminan los datos
del almacenamiento.
¿No puede agregar o cambiar una exportación?
Para agregar o cambiar las exportaciones, necesita derechos de acceso de propietario, colaborador o
colaborador de Application Insights. Más información sobre los roles.
¿Qué eventos obtiene?

Los datos exportados son la telemetría sin procesar que recibimos de la aplicación, aunque también
agregamos los datos de ubicación que calculamos a partir de la dirección IP del cliente.
Los datos que se han descartado por muestreo no se incluyen en los datos exportados.
No se incluyen otras métricas calculadas. Por ejemplo, no exportamos el uso medio de la CPU, pero sí la
telemetría sin procesar a partir de la que se calcula la media.
Los datos también incluyen los resultados de cualquier prueba web de disponibilidad que haya configurado.
NOTE
Muestreo. Si la aplicación envía muchos datos, la característica de muestreo puede operar y enviar solamente una
fracción de la telemetría generada. Aprenda más sobre el muestreo.
Inspección de los datos

Puede inspeccionar el almacenamiento directamente en el portal. Haga clic en Inicio en el menú de la
izquierda, en la parte superior donde se indica "Servicios de Azure", seleccione Cuentas de
almacenamiento , seleccione el nombre de la cuenta de almacenamiento, en la página de información
general, seleccione Blobs bajo Servicios y, por último, seleccione el nombre del contenedor.
Para inspeccionar Azure Storage en Visual Studio, abra Ver , Cloud Explorer . Si no tienes ese comando de
menú, deberá instalar Azure SDK: abra el cuadro de diálogo Nuevo proyecto , expanda Visual C#/Nube/ y
seleccione Obtener Microsoft Azure SDK para. NET .
Al abrir el almacén de blobs, verá un contenedor con un conjunto de archivos blob. El URI de cada archivo
que se deriva del nombre del recurso de Application Insights, su clave de instrumentación, y el tipo, fecha y
hora de telemetría. (El nombre del recurso está todo en minúsculas y la clave de instrumentación omite
guiones).
La fecha y hora son UTC e indican cuándo se depositó la telemetría en el almacén, no la hora en que se
generó. De modo que si escribe código para descargar los datos, se puede mover linealmente a través de los
datos.
Este es el formato de la ruta de acceso:
$"{applicationName}_{instrumentationKey}/{type}/{blobDeliveryTimeUtc:yyyy-MM-dd}/{
blobDeliveryTimeUtc:HH}/{blobId}_{blobCreationTimeUtc:yyyyMMdd_HHmmss}.blob"
Where
blobCreationTimeUtc es la hora de creación del blob en el almacenamiento provisional interno.
blobDeliveryTimeUtc es la hora de copia del blob en el almacenamiento de destino de exportación.
Formato de datos
Cada blob es un archivo de texto que contiene varias filas separadas por' \n'. Contiene la telemetría
procesada durante un período de aproximadamente la mitad de un minuto.
Cada fila representa un punto de datos de telemetría, como una vista de página o una solicitud.
Cada fila es un documento JSON sin formato. Si desea ver las filas, abra el blob en Visual Studio y elija
Editar > Avanzado > Archivo de formato :
Las duraciones de tiempo son tics, donde 10 000 tics = 1 ms. Por ejemplo, estos valores muestran un tiempo
de 1 ms para enviar una solicitud desde el explorador, 3 ms para recibirla y 1,8 s para procesar la página en el
explorador:
"sendRequest": {"value": 10000.0},

"receiveRequest": {"value": 30000.0},
"clientProcess": {"value": 17970000.0}
Referencia detallada del modelo de datos para los tipos y valores de propiedad.
Procesamiento de los datos

En una pequeña escala, puede escribir código para separar sus datos, leerlos en una hoja de cálculo, etc. Por
ejemplo:
private IEnumerable<T> DeserializeMany<T>(string folderName)
{
var files = Directory.EnumerateFiles(folderName, "*.blob", SearchOption.AllDirectories);
foreach (var file in files)
{
using (var fileReader = File.OpenText(file))
{
string fileContent = fileReader.ReadToEnd();
IEnumerable<string> entities = fileContent.Split('\n').Where(s =>
!string.IsNullOrWhiteSpace(s));
foreach (var entity in entities)
{
yield return JsonConvert.DeserializeObject<T>(entity);
}
}
}
}
Para obtener un ejemplo de código mayor, consulte cómo usar un rol de trabajo.
Eliminación de los datos antiguos

Es responsable de administrar la capacidad de almacenamiento y de eliminar los datos antiguos, si fuera
necesario.
Si vuelve a generar la clave de almacenamiento...

Si cambia la clave para el almacenamiento, la exportación continua dejará de funcionar. Verá una notificación
en su cuenta de Azure.
Abra la pestaña Exportación continua y edite la exportación. Modifique el destino de exportación, pero deje el
mismo almacenamiento seleccionado. Haga clic en Aceptar para confirmar.
La exportación continua se reiniciará.
Ejemplos de exportación
Exportación a SQL con el Stream Analytics
Ejemplo 2 de Stream Analytics
En escalas más grandes, considere la posibilidad de clústeres de Hadoop en HDInsight en la nube. HDInsight
ofrece una amplia variedad de tecnologías para administrar y analizar macrodatos, y puede usarlo para
procesar datos que se han exportado desde Application Insights.
Lo único que quiero es una descarga única de un gráfico.
Sí, puede hacerlo. En la parte superior de la pestaña, haga clic en Expor tar datos .
Configuro una exportación, pero no hay ningún dato en el almacén.
¿Recibió Application Insights alguna telemetría de su aplicación desde que configuró la exportación?
Solo recibirá datos nuevos.
Intenté configurar una exportación, pero se deniega el acceso.
Si la cuenta pertenece a su organización, debe ser miembro de los grupos de propietarios o
colaboradores.
¿Puedo exportar directamente a mi propio almacén local?
Lamentablemente, no. Nuestro motor de exportación actualmente solo funciona con el
almacenamiento de Azure.
¿Hay ningún límite para la cantidad de datos que puedo colocar en mi almacén?
No. Seguiremos insertando datos hasta que elimine la exportación. Pararemos si alcanzamos los
límites externos del almacenamiento de blobs, pero hasta llegar ahí falta mucho. Depende de usted
controlar la cantidad de almacenamiento que usa.
¿Cuántos blobs debería ver en el almacenamiento?
Para cada tipo de datos que seleccionó para exportar, se crea un blob nuevo cada minuto (si los
datos están disponibles).
Además, para las aplicaciones con mucho tráfico, se asignan unidades de partición adicionales. En
este caso, cada unidad crea un blob cada minuto.
Volví a generar la clave de mi almacenamiento o cambié el nombre del contenedor, y ahora no
funciona la exportación.
Edite la exportación y abra la pestaña de destino de la exportación. Deje el mismo almacenamiento
seleccionado que antes y haga clic en Aceptar para confirmar. La exportación se reiniciará. Si el cambio
estaba dentro de los últimos días, no perderá datos.
¿Puedo detener la exportación?
Sí. Haga clic en Deshabilitar.
Ejemplos de código
Ejemplo de Stream Analytics
Exportación a SQL con el Stream Analytics
Uso de Stream Analytics para procesar datos
exportados de Application Insights
Azure Stream Analytics es la herramienta ideal para procesar los datos exportados desde Application Insights.
Stream Analytics puede extraer datos de una variedad de orígenes. Puede transformar y filtrar los datos y, después,
enrutarlos a una variedad de receptores.
En este ejemplo, vamos a crear un adaptador que toma datos de Application Insights, cambia su nombre y procesa
algunos de los campos, y después los canaliza a Power BI.
WARNING
Hay formas recomendadas mucho mejores y sencillas de mostrar datos de Application Insights en Power BI. La ruta de
acceso que se muestra aquí es solo un ejemplo para mostrar cómo se procesan los datos exportados.
Creación de almacenamiento en Azure

La exportación continua siempre envía los datos a una cuenta de Azure Storage, por lo que necesitará crear
primero el almacenamiento.
1. Cree una cuenta de almacenamiento "clásica" en su suscripción en el Portal de Azure.
2. Crear un contenedor
3. Copie la clave de acceso de almacenamiento.

La necesitará en seguida para configurar la entrada para el servicio de análisis de transmisiones.
Inicio de la exportación continua al almacenamiento de Azure
exportación continua transfiere los datos de Application Insights al almacenamiento de Azure.
1. En el portal de Azure, busque el recurso de Application Insights que ha creado para la aplicación.
2. Cree una exportación continua.
Seleccione la cuenta de almacenamiento que creó anteriormente:
Configure los tipos de eventos que desea ver:

3. Permita que se acumulen algunos datos. Póngase cómo y deje que los usuarios usen su aplicación durante
un tiempo. Así, aparecerá la telemetría y verá gráficos estadísticos en el explorador de métricas y eventos
individuales en la búsqueda de diagnóstico.
Y, además, exportará los datos en el almacenamiento.
4. Inspeccione los datos exportados. En Visual Studio, elija Ver/Cloud Explorer y abra
Azure/Almacenamiento. (Si no tiene esta opción de menú, deberá instalar Azure SDK: abra el cuadro de
diálogo Nuevo proyecto y Visual C#/Nube/Obtener Microsoft Azure SDK para. NET).
Tome nota de la parte común del nombre de la ruta de acceso, que se deriva del nombre de la aplicación y
de la clave de instrumentación.
Los eventos se escriben en archivos de blob en formato JSON. Cada archivo puede contener uno o varios eventos.
Así, es probable que queramos leer los datos de eventos y filtrar por los campos que deseemos. Se pueden realizar
multitud de acciones con los datos, pero nuestro plan de hoy consiste en usar Stream Analytics para canalizar los
datos a Power BI.
Creación de una instancia de Azure Stream Analytics

Desde Azure Portal, seleccione el servicio Azure Stream Analytics y cree un nuevo trabajo de Stream Analytics:
Cuando se cree el nuevo trabajo, seleccione Ir al recurso .
Incorporación de una nueva entrada

Configúrelo de manera que tome los datos del blob de Exportación continua:
Ahora, necesitará la clave de acceso principal de la cuenta de almacenamiento, que anotó anteriormente.
Establézcala como la clave de cuenta de almacenamiento.
Establecimiento del patrón del prefijo de la ruta de acceso
Asegúrese de establecer el formato de fecha como AAAA-MM-DD (con guiones).
El patrón del prefijo de la ruta de acceso especifica dónde busca el Stream Analytics los archivos de entrada en el
almacenamiento. Deberá establecerlo para que coincida con el modo en que la Exportación continua almacena los
datos. Configúrelo como este caso que se muestra a continuación:
webapplication27_12345678123412341234123456789abcdef0/PageViews/{date}/{time}
En este ejemplo:
webapplication27 es el nombre del recurso de Application Insights, todo en minúsculas .
1234... es la clave de instrumentación que copió del recurso de Application Insights, omitiendo guiones .
PageViews es el tipo de datos que quiere analizar. Los tipos disponibles dependen del filtro definido en la
Exportación continua. Examine los datos exportados para ver los demás tipos disponibles y vea el modelo de
exportación de datos.
/{date}/{time} es un patrón escrito literalmente.
NOTE
Inspeccione el almacenamiento para asegurarse de que obtiene la ruta de acceso correcta.
Incorporación de una nueva salida

Ahora seleccione el trabajo > Salidas > Agregar .
Ofrezca su cuenta profesional o educativa para autorizar el Stream Analytics a tener acceso al recurso de
Power BI. Luego invente un nombre para la salida y para la tabla y el conjunto de datos de Power BI de destino.
Definición de la consulta
La consulta controla la traducción de la entrada en la salida.
Use la función de prueba para comprobar que obtiene la salida correcta. Proporciónele los datos de ejemplo que
tomó de la página de entradas.
Consulta para mostrar recuentos de eventos
Pegue esta consulta:
SELECT
flat.ArrayValue.name,
count(*)
INTO
[pbi-output]
FROM
[export-input] A
OUTER APPLY GetElements(A.[event]) as flat
GROUP BY TumblingWindow(minute, 1), flat.ArrayValue.name
export-input es el alias que damos a la entrada de transmisiones

pbi-output es el alias que hemos definido para la salida
Usamos OUTER APPLY GetElements porque el nombre del evento se encuentra en una matriz JSON anidada. A
continuación, la opción Select selecciona el nombre de evento, junto con el recuento del número de instancias
con dicho nombre en el período de tiempo. La cláusula Group By agrupa los elementos en períodos de tiempo
de un minuto.
Consulta para mostrar valores de métrica
SELECT
A.context.data.eventtime,
avg(CASE WHEN flat.arrayvalue.myMetric.value IS NULL THEN 0 ELSE flat.arrayvalue.myMetric.value END) as
myValue
INTO
[pbi-output]
FROM
[export-input] A
OUTER APPLY GetElements(A.context.custom.metrics) as flat
GROUP BY TumblingWindow(minute, 1), A.context.data.eventtime
Esta consulta explora la telemetría de métricas para obtener la hora del evento y el valor de métrica. Los valores
de métrica están dentro de una matriz, por eso usamos el patrón OUTER APPLY GetElements para extraer las
filas. "myMetric" es el nombre de la métrica en este caso.
Consulta para incluir los valores de propiedades de dimensión
WITH flat AS (
SELECT
MySource.context.data.eventTime as eventTime,
InstanceId = MyDimension.ArrayValue.InstanceId.value,
BusinessUnitId = MyDimension.ArrayValue.BusinessUnitId.value
FROM MySource
OUTER APPLY GetArrayElements(MySource.context.custom.dimensions) MyDimension
)
SELECT
eventTime,
InstanceId,
BusinessUnitId
INTO AIOutput
FROM flat
Esta consulta incluye valores de las propiedades de dimensión sin depender de la fijación de una dimensión
determinada en un índice fijo en la matriz de dimensión.
Ejecutar el trabajo
Puede seleccionar una fecha en el pasado desde la que iniciar el trabajo.
Espere hasta que el trabajo esté en ejecución.
Visualización de resultados en Power BI

WARNING
Hay formas recomendadas mucho mejores y sencillas de mostrar datos de Application Insights en Power BI. La ruta de
acceso que se muestra aquí es solo un ejemplo para mostrar cómo se procesan los datos exportados.
Abra Power BI con su cuenta profesional o educativa y seleccione el conjunto de datos y la tabla que ha definido
como la salida del trabajo del Stream Analytics.
Ahora puede usar este conjunto de datos en informes y paneles de Power BI.
¿No hay datos?

Compruebe que establece el formato de fecha correctamente en AAAA-MM-DD (con guiones).
Vídeo
Noam Ben Zeev muestra cómo procesar los datos exportados mediante Stream Analytics.
Pasos siguientes
Tutorial: exportación a SQL desde Application
Insights mediante Stream Analytics
En este artículo se muestra cómo trasladar los datos de telemetría desde Azure Application Insights a Azure SQL
Database mediante la Exportación continua y Azure Stream Analytics.
La Exportación continua traslada los datos de telemetría a Azure Storage en formato JSON. Analizaremos los
objetos JSON mediante Azure Stream Analytics y crearemos filas en una tabla de base de datos.
(De manera más general, la Exportación continua es la forma de realizar su propio análisis de la telemetría que
las aplicaciones envían a Application Insights. Se puede adaptar este ejemplo de código para realizar otras
operaciones con la telemetría exportada, como la adición de datos).
Comenzaremos con la suposición de que ya dispone de la aplicación que desea supervisar.
En este ejemplo, vamos a usar los datos de la vista de página, pero se puede ampliar fácilmente el mismo patrón
a otros tipos de datos, como eventos y excepciones personalizados.
Agregar Application Insights a una aplicación

Primeros pasos:
1. Configure Application Insights para sus páginas web.
(En este ejemplo, nos centraremos en el procesamiento de datos de vistas de página de los exploradores
cliente, pero también puede configurar Application Insights para el lado servidor de una aplicación Java o
ASP.NET y procesar peticiones, dependencias y otra telemetría de servidor).
2. Publique la aplicación y vea los datos de telemetría que aparecen en el recurso de Application Insights.
Creación de almacenamiento en Azure

La exportación continua siempre envía los datos a una cuenta de Azure Storage, por lo que necesitará crear
primero el almacenamiento.
1. Cree una cuenta de almacenamiento en su suscripción en el portal de Azure.
2. Crear un contenedor
3. Copie la clave de acceso de almacenamiento.

La necesitará en seguida para configurar la entrada para el servicio de análisis de transmisiones.
Inicio de la exportación continua al almacenamiento de Azure
1. En el portal de Azure, busque el recurso de Application Insights que ha creado para la aplicación.
2. Cree una exportación continua.
Seleccione la cuenta de almacenamiento que creó anteriormente:

Configure los tipos de eventos que desea ver:
3. Permita que se acumulen algunos datos. Póngase cómo y deje que los usuarios usen su aplicación
durante un tiempo. Así, aparecerá la telemetría y verá gráficos estadísticos en el explorador de métricas y
eventos individuales en la búsqueda de diagnóstico.
Y, además, exportará los datos en el almacenamiento.
4. Inspeccione los datos exportados, ya sea en el portal (seleccione Examinar , seleccione la cuenta de
almacenamiento y, después, Contenedores ) o bien en Visual Studio. En Visual Studio, elija Ver/Cloud
Explorer y abra Azure/Almacenamiento. (Si no tiene esta opción de menú, deberá instalar Azure SDK:
abra el cuadro de diálogo Nuevo proyecto y Visual C#/Nube/Obtener Microsoft Azure SDK para. NET).
Tome nota de la parte común del nombre de la ruta de acceso, que se deriva del nombre de la aplicación
y de la clave de instrumentación.
Los eventos se escriben en archivos de blob en formato JSON. Cada archivo puede contener uno o varios
eventos. Así, es probable que queramos leer los datos de eventos y filtrar por los campos que deseemos. Se
pueden realizar multitud de acciones con los datos, pero nuestro plan de hoy consiste en usar Stream Analytics
para trasladar los datos a SQL Database. De este modo, será más sencillo ejecutar muchas consultas
interesantes.
Creación de una base de datos de Azure SQL

De nuevo, empiece desde su suscripción en Azure Portal, cree la base de datos (y un servidor, a menos que ya
tenga uno) donde escribirá los datos.
Asegúrese de que el servidor permite el acceso a los servicios de Azure:
Creación de una tabla en Azure SQL Database

Conéctese a la base de datos creada en la sección anterior con su herramienta preferida de administración. En
este tutorial, usaremos Herramientas de administración de SQL Server (SSMS).
Cree una nueva consulta y ejecute la siguiente instrucción T-SQL:
CREATE TABLE [dbo].[PageViewsTable](

[pageName] [nvarchar](max) NOT NULL,
[viewCount] [int] NOT NULL,
[url] [nvarchar](max) NULL,
[urlDataPort] [int] NULL,
[urlDataprotocol] [nvarchar](50) NULL,
[urlDataHost] [nvarchar](50) NULL,
[urlDataBase] [nvarchar](50) NULL,
[urlDataHashTag] [nvarchar](max) NULL,
[eventTime] [datetime] NOT NULL,
[isSynthetic] [nvarchar](50) NULL,
[deviceId] [nvarchar](50) NULL,
[deviceType] [nvarchar](50) NULL,
[os] [nvarchar](50) NULL,
[osVersion] [nvarchar](50) NULL,
[locale] [nvarchar](50) NULL,
[userAgent] [nvarchar](max) NULL,
[browser] [nvarchar](50) NULL,
[browserVersion] [nvarchar](50) NULL,
[screenResolution] [nvarchar](50) NULL,
[sessionId] [nvarchar](max) NULL,
[sessionIsFirst] [nvarchar](50) NULL,
[clientIp] [nvarchar](50) NULL,
[continent] [nvarchar](50) NULL,
[country] [nvarchar](50) NULL,
[province] [nvarchar](50) NULL,
[city] [nvarchar](50) NULL
)
CREATE CLUSTERED INDEX [pvTblIdx] ON [dbo].[PageViewsTable]

(
[eventTime] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE =
OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
En este ejemplo, usamos datos de vistas de página. Para ver los demás datos disponibles, observe el resultado
de JSON y consulte el modelo de exportación de datos.
Creación de una instancia de Azure Stream Analytics

Desde Azure Portal, seleccione el servicio Azure Stream Analytics y cree un nuevo trabajo de Stream Analytics:
Cuando se cree el nuevo trabajo, seleccione Ir al recurso .
Incorporación de una nueva entrada

Configúrelo de manera que tome los datos del blob de Exportación continua:
Ahora, necesitará la clave de acceso principal de la cuenta de almacenamiento, que anotó anteriormente.
Establézcala como la clave de cuenta de almacenamiento.
Establecimiento del patrón del prefijo de la ruta de acceso
Asegúrese de establecer el formato de fecha como AAAA-MM-DD (con guiones).
El patrón del prefijo de la ruta de acceso especifica cómo busca el Stream Analytics los archivos de entrada en el
almacenamiento. Deberá establecerlo para que coincida con el modo en que la Exportación continua almacena
los datos. Configúrelo como este caso que se muestra a continuación:
webapplication27_12345678123412341234123456789abcdef0/PageViews/{date}/{time}
En este ejemplo:
webapplication27 es el nombre del recurso de Application Insights, todo en minúsculas .
1234... es la clave de instrumentación del recurso de Application Insights con los guiones quitados .
PageViews es el tipo de datos que se van a analizar. Los tipos disponibles dependen del filtro definido en la
Exportación continua. Examine los datos exportados para ver los demás tipos disponibles y vea el modelo de
exportación de datos.
/{date}/{time} es un patrón escrito literalmente.
Para obtener el nombre y el valor iKey del recurso de Application Insights, abra Essentials en su página de
información general o bien abra la Configuración.
TIP
Use la función Sample para comprobar que estableció correctamente la ruta de acceso de entrada. Si se produce un error:
compruebe que hay datos en el almacenamiento para el intervalo de tiempo de muestreo que eligió. Modifique la
definición de entrada y compruebe que establece correctamente la cuenta de almacenamiento, el prefijo de ruta de acceso
y el formato de fecha.
Establecimiento de la consulta
Abra la sección de consulta:
Reemplace la consulta predeterminada por lo siguiente:
SELECT flat.ArrayValue.name as pageName

, flat.ArrayValue.count as viewCount
, flat.ArrayValue.url as url
, flat.ArrayValue.urlData.port as urlDataPort
, flat.ArrayValue.urlData.protocol as urlDataprotocol
, flat.ArrayValue.urlData.host as urlDataHost
, flat.ArrayValue.urlData.base as urlDataBase
, flat.ArrayValue.urlData.hashTag as urlDataHashTag
,A.context.data.eventTime as eventTime
,A.context.data.isSynthetic as isSynthetic
,A.context.device.id as deviceId
,A.context.device.type as deviceType
,A.context.device.os as os
,A.context.device.osVersion as osVersion
,A.context.device.locale as locale
,A.context.device.userAgent as userAgent
,A.context.device.browser as browser
,A.context.device.browserVersion as browserVersion
,A.context.device.screenResolution.value as screenResolution
,A.context.session.id as sessionId
,A.context.session.isFirst as sessionIsFirst
,A.context.location.clientip as clientIp
,A.context.location.continent as continent
,A.context.location.country as country
,A.context.location.province as province
,A.context.location.city as city
INTO
AIOutput
FROM AIinput A
CROSS APPLY GetElements(A.[view]) as flat
Observe que las primeras propiedades son específicas de los datos de la vista de página. Las exportaciones de
otros tipos de telemetría tendrán diferentes propiedades. Vea la referencia detallada del modelo de datos para
los tipos y valores de propiedad
Configuración de la salida a la base de datos

Seleccione SQL como salida.
Especifique la base de datos.
Cierre el asistente y espere una notificación que indica que se ha configurado la salida.
Inicio del procesamiento

Inicie el trabajo desde la barra de acción:
Puede elegir si desea iniciar el procesamiento de los datos a partir de ahora o bien empezar con datos
anteriores. Lo segundo resulta útil si la Exportación continua ya se ha estado ejecutando durante un tiempo.
Después de unos minutos, vuelva a las herramientas de administración de SQL Server y consulte los datos que
están entrando. Por ejemplo, utilice una consulta como esta:
SELECT TOP 100 *

FROM [dbo].[PageViewsTable]
Artículos relacionados
Exportación a PowerBI mediante Stream Analytics
Referencia detallada del modelo de datos para los tipos y valores de propiedad
Exportación continua en Application Insights
Modelo de exportación de datos de Application
Insights
En esta tabla se enumeran las propiedades de telemetría enviadas desde los SDK de Application Insights al
portal. Verá estas propiedades en el resultado de datos de Exportación continua. También aparecen en los
filtros de propiedad de Explorador de métricas y Búsqueda de diagnóstico.
Puntos a tener en cuenta:
[0] en estas tablas denota un punto en la ruta de acceso donde se debe insertar un índice; pero no
siempre es 0.
Los períodos de tiempo se indican en décimas de microsegundo, así que 10000000 = 1 segundo.
Las fechas y horas son UTC y se proporcionan en el formato ISO yyyy-MM-DDThh:mm:ss.sssZ
Ejemplo
// A server report about an HTTP request
{
"request": [
{
"urlData": { // derived from 'url'
"host": "contoso.org",
"base": "/",
"hashTag": ""
},
"responseCode": 200, // Sent to client
"success": true, // Default == responseCode<400
// Request id becomes the operation id of child events
"id": "fCOhCdCnZ9I=",
"name": "GET Home/Index",
"count": 1, // 100% / sampling rate
"durationMetric": {
"value": 1046804.0, // 10000000 == 1 second
// Currently the following fields are redundant:
"count": 1.0,
"min": 1046804.0,
"max": 1046804.0,
"stdDev": 0.0,
"sampledValue": 1046804.0
},
"url": "/"
}
],
"internal": {
"data": {
"id": "7f156650-ef4c-11e5-8453-3f984b167d05",
"documentVersion": "1.61"
}
},
"context": {
"device": { // client browser
"type": "PC",
"screenResolution": { },
"roleInstance": "WFWEB14B.fabrikam.net"
},
"application": { },
"location": { // derived from client ip
"location": { // derived from client ip
"continent": "North America",
"country": "United States",
// last octagon is anonymized to 0 at portal:
"clientip": "168.62.177.0",
"province": "",
"city": ""
},
"data": {
"isSynthetic": true, // we identified source as a bot
// percentage of generated data sent to portal:
"samplingRate": 100.0,
"eventTime": "2016-03-21T10:05:45.7334717Z" // UTC
},
"user": {
"isAuthenticated": false,
"anonId": "us-tx-sn1-azr", // bot agent id
"anonAcquisitionDate": "0001-01-01T00:00:00Z",
"authAcquisitionDate": "0001-01-01T00:00:00Z",
"accountAcquisitionDate": "0001-01-01T00:00:00Z"
},
"operation": {
"id": "fCOhCdCnZ9I=",
"parentId": "fCOhCdCnZ9I=",
"name": "GET Home/Index"
},
"cloud": { },
"serverDevice": { },
"custom": { // set by custom fields of track calls
"dimensions": [ ],
"metrics": [ ]
},
"session": {
"id": "65504c10-44a6-489e-b9dc-94184eb00d86",
"isFirst": true
}
}
}
Context
Una sección de contexto acompaña a todos los tipos de telemetría. No todos estos campos se transmiten con
cada punto de datos.
PAT H T IP O N OTA S
context.custom.dimensions [0] objeto [ ] Pares de cadenas de clave-valor

establecidos por el parámetro de
propiedades personalizadas. Longitud
máxima de clave: 100, longitud
máxima de valores: 1024. Más de 100
valores únicos, se pueden realizar
búsquedas en la propiedad, pero no se
puede usar para la segmentación.
Máximo de 200 claves por ikey.
context.custom.metrics [0] objeto [ ] Los pares de clave-valor se establecen

mediante el parámetro de medidas
personalizado y mediante
TrackMetrics. Longitud máxima de
clave: 100, los valores pueden ser
numéricos.
context.data.eventTime string UTC
context.data.isSynthetic boolean La solicitud parece proceder de un bot

o una prueba web.
context.data.samplingRate number Porcentaje de telemetría generado por

el SDK que se envía al portal. Intervalo
0,0 a 100,0.
context.device object Dispositivo de cliente
context.device.browser string IE, Chrome,…
context.device.browserVersion string Chrome 48.0,…
context.device.deviceModel string
context.device.deviceName string
context.device.id string
context.device.locale string en-GB, de-DE,…
context.device.network string
context.device.oemName string
context.device.os string
context.device.osVersion string Sistema operativo del host
context.device.roleInstance string Identificador del host del servidor
context.device.roleName string
context.device.screenResolution string
context.device.type string PC, explorador,…
context.location object Derivado de clientip .
context.location.city string Derivado de clientip , si se conoce.
context.location.clientip string El último octágono se hace anónimo

en 0.
context.location.continent string
context.location.country string
context.location.province string Estado o provincia

context.operation.id string Los elementos que tienen el mismo

operation id se muestran como
elementos relacionados en el portal.
Normalmente, request id .
context.operation.name string Nombre de solicitud o dirección URL
context.operation.parentId string Permite elementos relacionados

anidados.
context.session.id string Id de un grupo de operaciones del

mismo origen. Un período de 30
minutos sin una operación señala el
final de una sesión.
context.session.isFirst boolean
context.user.accountAcquisitionDate string
context.user.accountId string
context.user.anonAcquisitionDate string
context.user.anonId string
context.user.authAcquisitionDate string Usuario autenticado
context.user.authId string
context.user.isAuthenticated boolean
context.user.storeRegion string
internal.data.documentVersion string
internal.data.id string Unique id que se asigna cuando un

elemento se ingiere en Application
Insights
Eventos
Eventos personalizados generados por TrackEvent().
event [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo, 4 => 25 %.
event [0] name string Nombre del evento. Longitud máxima:

250.
event [0] url string

event [0] urlData.base string
event [0] urlData.host string
Excepciones
Notifica sobre excepciones en el servidor y en el explorador.
basicException [0] assembly string
basicException [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo, 4 => 25 %.
basicException [0] exceptionGroup string
basicException [0] exceptionType string
basicException [0] string

failedUserCodeMethod

failedUserCodeAssembly
basicException [0] handledAt string
basicException [0] hasFullStack boolean
basicException [0] id string
basicException [0] method string
basicException [0] message string Mensaje de excepción. Longitud

máxima: 10 000.

outerExceptionMessage

outerExceptionThrownAtAssembly

outerExceptionThrownAtMethod
basicException [0] outerExceptionType string
basicException [0] outerId string
basicException [0] parsedStack [0] string

assembly

fileName
basicException [0] parsedStack [0] level integer
basicException [0] parsedStack [0] line integer

method
basicException [0] stack string Longitud máxima: 10 000.
basicException [0] typeName string
Mensajes de seguimiento
Enviados por TrackTrace y por los adaptadores de registro.
message [0] loggerName string
message [0] parameters string
message [0] raw string El mensaje de registro, longitud

máxima: 10 000.
message [0] severityLevel string
Dependencia remota
Enviado por TrackDependency. Se usa para notificar el rendimiento y el uso de las llamadas a dependencias en
el servidor y de las llamadas AJAX en el explorador.
remoteDependency [0] async boolean
remoteDependency [0] baseName string
remoteDependency [0] string Por ejemplo, "home/index".

commandName
remoteDependency [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo, 4 => 25 %.
remoteDependency [0] string HTTP, SQL...

dependencyTypeName
remoteDependency [0] number Tiempo desde la llamada hasta la

durationMetric.value finalización de respuesta de la
dependencia
remoteDependency [0] id string
remoteDependency [0] name string URL Longitud máxima: 250.
remoteDependency [0] resultCode string de la dependencia de HTTP
remoteDependency [0] success boolean
remoteDependency [0] type string Http, Sql,...
remoteDependency [0] url string Longitud máxima: 2000
remoteDependency [0] urlData.base string Longitud máxima: 2000
remoteDependency [0] string

urlData.hashTag
remoteDependency [0] urlData.host string Longitud máxima: 200
Requests
Enviado por TrackRequest. Los módulos estándar usan esto para informar sobre el tiempo de respuesta del
servidor, medido en el propio servidor.
request [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo: 4 => 25 %.
request [0] durationMetric.value number Tiempo desde que llega la solicitud

hasta la respuesta. 1e7 = 1 s
request [0] id string Operation id
request [0] name string GET y POST + dirección url base.

Longitud máxima: 250
request [0] responseCode integer Respuesta HTTP enviada al cliente
request [0] success boolean Predeterminado == (responseCode <

400)
request [0] url string No incluye el host
request [0] urlData.base string
request [0] urlData.hashTag string

request [0] urlData.host string
Rendimiento de la vista de página

Enviado por el explorador. Mide el tiempo que se tarda en procesar una página desde que el usuario inicia la
solicitud hasta que aparece por completo (excluidas las llamadas AJAX asincrónicas).
Los valores de contexto muestran el sistema operativo del cliente y la versión del explorador.
clientPerformance [0] integer Tiempo transcurrido desde el fin de la

clientProcess.value recepción del código HTML hasta que
se muestra la página.
clientPerformance [0] name string
clientPerformance [0] integer Tiempo necesario para establecer una

networkConnection.value conexión de red.
clientPerformance [0] integer Tiempo transcurrido desde la

receiveRequest.value finalización del envío de la solicitud
hasta la recepción del código HTML en
la respuesta.
clientPerformance [0] integer Tiempo empleado en enviar la solicitud

sendRequest.value HTTP.
clientPerformance [0] total.value integer Tiempo transcurrido desde que se

empieza a enviar la solicitud hasta que
se muestra la página.
clientPerformance [0] url string Dirección URL de esta solicitud
clientPerformance [0] urlData.base string
clientPerformance [0] urlData.hashTag string
clientPerformance [0] urlData.host string
clientPerformance [0] urlData.protocol string
Vistas de página
Enviado por trackPageView() o stopTrackPage
view [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo, 4 => 25 %.
view [0] durationMetric.value integer Valor establecido opcionalmente en

trackPageView() o mediante
startTrackPage() - stopTrackPage(). No
es igual que los valores de
clientPerformance.
view [0] name string Título de la página. Longitud máxima:

250
view [0] url string
view [0] urlData.base string
view [0] urlData.hashTag string
view [0] urlData.host string
Disponibilidad
Notifica sobre pruebas web de disponibilidad.
availability [0] availabilityMetric.name string availability
availability [0] availabilityMetric.value number 1,0 o 0,0
availability [0] count integer 100/(frecuencia demuestreo ). Por

ejemplo, 4 => 25 %.
availability [0] dataSizeMetric.name string
availability [0] dataSizeMetric.value integer
availability [0] durationMetric.name string
availability [0] durationMetric.value number Duración de la prueba. 1e7 = 1 s
availability [0] message string Diagnóstico de errores
availability [0] result string Sin errores/Error
availability [0] runLocation string Origen geográfica de la solicitud http
availability [0] testName string
availability [0] testRunId string
availability [0] testTimestamp string
Métricas
Generado por TrackMetric().
El valor de la métrica se encuentra en context.custom.metrics[0].
Por ejemplo:
{
"metric": [ ],
"context": {
...
"custom": {
"dimensions": [
{ "ProcessId": "4068" }
],
"metrics": [
{
"dispatchRate": {
"value": 0.001295,
"count": 1.0,
"min": 0.001295,
"max": 0.001295,
"stdDev": 0.0,
"sampledValue": 0.001295,
"sum": 0.001295
}
}
]
}
}
}
Acerca de los valores de métrica

Los valores de métrica, tanto en los informes de métrica como en otros lugares, se notifican con una estructura
de objeto estándar. Por ejemplo:
"durationMetric": {
"name": "contoso.org",
"type": "Aggregation",
"value": 468.71603053650279,
"count": 1.0,
"min": 468.71603053650279,
"max": 468.71603053650279,
"stdDev": 0.0,
"sampledValue": 468.71603053650279
}
Aunque esto puede cambiar en el futuro, en la actualidad, en todos los valores notificados desde los módulos
SDK estándar, count==1 y solo los campos name y value son útiles. El único caso donde podrían ser
diferentes es si escribe sus propias llamadas de TrackMetric, en cuyo caso establecerá los demás parámetros.
El propósito de los demás campos es permitir que las métricas se agreguen en el SDK, para reducir el tráfico
hacia el portal. Por ejemplo, podría hacer el promedio de varias lecturas sucesivas antes de enviar cada informe
métrica. A continuación, podría calcular el mínimo, el máximo, la desviación estándar y un valor agregado
(suma o promedio) y establecer el recuento en el número de lecturas representado por el informe.
En las tablas anteriores, hemos omitido los campos usados con poca frecuencia como count, min, max, stdDev
y sampledValue.
En lugar de la agregación previa de las métricas, puede usar el muestreo si necesita reducir el volumen de
Duraciones
Excepto donde se indique lo contrario, las duraciones se representan en décimas de microsegundo, por lo que
10000000,0 equivalen a 1 segundo.
Consulte también
Ejemplos de código
Depure sus aplicaciones con Azure Application
Insights en Visual Studio
En Visual Studio (2015 y versiones posteriores), se pueden diagnosticar y analizar los problemas de rendimiento
de las aplicaciones web, tanto en tiempo de depuración como en producción, mediante los datos de telemetría
de Azure Application Insights.
Si ha creado la aplicación web de ASP.NET mediante Visual Studio 2017 o versiones posteriores, ya tiene el SDK
de Application Insights. Si todavía no lo ha hecho, agregue Application Insights a su aplicación.
Para supervisar la aplicación cuando se encuentra activa en producción, normalmente verá la telemetría de
Application Insights en Azure Portal, donde puede establecer alertas y aplicar eficaces herramientas de
supervisión. Pero para la depuración, también puede buscar y analizar la telemetría en Visual Studio. Puede usar
Visual Studio para analizar la telemetría desde su sitio de producción y desde los procesos de depuración que se
ejecutan en el equipo de desarrollo. En este caso, puede analizar los procesos de depuración aunque todavía no
haya configurado el SDK para enviar telemetría a Azure Portal.
Depure el proyecto
Ejecute la aplicación web en modo de depuración local mediante F5. Abra distintas páginas para generar
telemetría.
En Visual Studio, puede ver un recuento de los eventos que el módulo Application Insights ha registrado en el
proyecto.
Haga clic en este botón para buscar la telemetría.
Búsqueda de Application Insights

La ventana de búsqueda de Application Insights muestra los eventos que se han registrado. (Si inició sesión en
Azure al configurar Application Insights, puede buscar los mismos eventos en Azure Portal).
NOTE
Después de seleccionar o anular la selección de filtros, haga clic en el botón de búsqueda al final del campo de búsqueda
de texto.
La búsqueda de texto sin formato funciona en todos los campos de los eventos. Por ejemplo, buscar parte de la
dirección URL de una página; o el valor de una propiedad, como la ciudad del cliente; o palabras específicas en
un registro de seguimiento.
Haga clic en cualquier evento para ver sus propiedades con todo detalle.
Para las solicitudes a la aplicación web, puede hacer clic en el código.
También puede abrir los elementos relacionados para ayudar a diagnosticar las solicitudes con errores o
excepciones.
Ver solicitudes con error y excepciones
Informes de excepciones en la ventana de búsqueda. (En algunos tipos anteriores de aplicaciones de ASP.NET,
tendrá que configurar la supervisión de excepciones para ver las excepciones que el entorno administra).
Haga clic en una excepción para obtener un seguimiento de la pila. Si el código de la aplicación es abierto en
Visual Studio, puede hacer clic para recorrer el seguimiento de la pila hasta dar con la línea correspondiente del
código.
Ver resúmenes de solicitudes y excepciones en el código

En la línea de Code Lens, encima de cada método de controlador, puede ver un recuento de las solicitudes y
excepciones registradas por Application Insights en las últimas 24 horas.
NOTE
Code Lens muestra los datos de Application Insights solo si tiene configurada la aplicación para enviar telemetría al portal
Más información acerca de Application Insights en Code Lens
Tendencias
Tendencias es una herramienta para visualizar cómo se comporta la aplicación con el paso del tiempo.
Elija Explorar tendencias de telemetría con el botón de la barra de herramientas de Application Insights o en
la ventana Búsqueda de Application Insights. Seleccione una de las cinco consultas comunes para empezar.
Puede analizar diferentes conjuntos de datos en función de los tipos de telemetría, los intervalos de tiempo y
otras propiedades.
Para detectar anomalías en los datos, elija una de las opciones de anomalía en la lista desplegable "Tipo de vista".
Con las opciones de filtrado de la parte inferior de la ventana, resulta más sencillo centrarse en subconjuntos
específicos de la telemetría.
Más sobre Tendencias.

Supervisión local
(Desde Visual Studio 2015 Update 2) Si no ha configurado el SDK para enviar datos de telemetría al portal de
Application Insights (para que no haya ninguna clave de instrumentación en ApplicationInsights.config), la
ventana diagnóstico muestra los datos de telemetría de la sesión de depuración más reciente.
Esto es conveniente si ya ha publicado una versión anterior de la aplicación. No quiere que los datos de
telemetría de las sesiones de depuración se mezclen con los datos de telemetría en el portal de Application
Insights de la aplicación publicada.
También es útil si tiene datos de telemetría personalizados que desea depurar antes de enviarlos al portal.
En primer lugar, configuré totalmente Application Insights para enviar los datos de telemetría al portal.
Pero ahora me gustaría ver los datos de telemetría solo en Visual Studio.
En la configuración de la ventana de búsqueda, hay una opción para buscar diagnósticos locales,
incluso si la aplicación envía datos de telemetría al portal.
Para detener el envío de datos de telemetría al portal, convierta en comentario la línea
<instrumentationkey>... de ApplicationInsights.config. Cuando esté listo para enviar de nuevo datos
de telemetría al portal, quite los comentarios.
Pasos siguientes
Incorporación de datos adicionales

Supervise el uso, la disponibilidad, las dependencias y las
excepciones. Integrar seguimientos de marcos de registro.
Escribir telemetría personalizada.
Trabajo con el por tal de Application Insights

Consulte paneles, eficaces herramientas de diagnóstico y
análisis, alertas, un mapa activo de dependencias de la
aplicación y datos de telemetría exportados.
Análisis de tendencias en Visual Studio
La herramienta Tendencias de Application Insights muestra cómo los eventos de telemetría importantes de la
aplicación web cambian a lo largo del tiempo, lo que ayuda a identificar rápidamente los problemas y las
anomalías. Al vincularle a información de diagnóstico más detallada, Tendencias puede ayudarle a mejorar el
rendimiento de la aplicación, realizar un seguimiento de las causas de las excepciones y revelar información de los
eventos personalizados.
Configuración de la aplicación web para Application Insights

Si aún no lo ha hecho, configure la aplicación web para Application Insights. Esto le permite enviar datos de
telemetría al portal de Application Insights. La herramienta Tendencias lee ahí la telemetría.
Tendencias de Application Insights está disponible en Visual Studio 2015 Update 3 y versiones posteriores.
Tendencias de Application Insights

Para abrir la ventana de Tendencias de Application Insights:
En el botón de la barra de herramientas de Application Insights, elija Explorar tendencias de telemetría , o
bien
En el menú contextual del proyecto, elija Application Insights > Explorar tendencias de telemetría , o
bien
En la barra de menús de Visual Studio, elija Vista > Otras ventanas > Tendencias de Application
Insights .
Verá un aviso para seleccionar un recurso. Haga clic en Seleccionar un recurso , inicie sesión con una
suscripción de Azure y elija el recurso de Application Insights de la lista para el que desea analizar las tendencias
de telemetría.
Elección de un análisis de tendencias

Para empezar, elija entre uno de los cinco análisis de tendencias comunes, cada de los cuales analiza los datos de
las últimas 24 horas:
Investigue los problemas de rendimiento con las solicitudes del ser vidor : solicitudes realizadas al
servicio, agrupadas por tiempos de respuesta.
Analice los errores en las solicitudes del ser vidor : solicitudes realizadas al servicio, agrupadas por
código de respuesta HTTP.
Examine las excepciones de la aplicación -excepciones del servicio, agrupadas por tipo de excepción.
Compruebe el rendimiento de las dependencias de la aplicación : servicios llamados por su servicio,
agrupados por tiempos de respuesta.
Inspeccione sus eventos personalizados : eventos personalizados que se ha configurado para el servicio,
agrupados por tipo de evento.
Estos análisis pregenerados están disponibles más adelante, en el botón Ver tipos comunes de análisis de
telemetría , situado en la esquina superior izquierda de la ventana Tendencias.
Visualización de tendencias en la aplicación

Tendencias de Application Insights crea una visualización de la serie temporal o de la telemetría de su aplicación.
Cada visualización de la serie temporal muestra un tipo de telemetría, agrupados por una propiedad de esa
telemetría, a lo largo de algún intervalo de tiempo. Por ejemplo, puede que quiera ver las solicitudes del servidor,
agrupadas por el país o región en el que se han originado, a lo largo de las últimas 24 horas. En este ejemplo, cada
burbuja de la visualización representaría un recuento de las solicitudes del servidor para algún país o región
durante una hora.
Utilice los controles de la parte superior de la ventana para ajustar los tipos de telemetría que ve. En primer lugar,
elija los tipos de telemetría en los que está interesado:
Tipo de telemetría : solicitudes del servidor, excepciones, dependencias o eventos personalizados.
Inter valo de tiempo : en cualquier momento entre los últimos 30 minutos y los últimos tres días.
Agrupar por : tipo excepción, identificador del problema, país o región, etc.
A continuación, haga clic en Analizar telemetría para ejecutar la consulta.
Para desplazarse entre las burbujas de la visualización:
Haga clic para seleccionar una burbuja; esto actualiza los filtros situados en la parte inferior de la ventana y
resume solo los eventos que se produjeron durante un período específico.
Haga doble clic en una burbuja para ir a la herramienta de búsqueda y ver todos los eventos de telemetría
individuales que se produjeron durante ese período.
Haga Ctrl-clic en una burbuja para anular su selección en la visualización.
TIP
Las herramientas Tendencias y Buscar funcionan conjuntamente para ayudar a identificar las causas de los problemas en el
servicio entre miles de eventos de telemetría. Por ejemplo, si una tarde sus clientes notan que la aplicación tiene menos
capacidad de respuesta, empiece con Tendencias. Analice las solicitudes al servicio realizadas durante las últimas horas,
agrupadas por tiempo de respuesta. Vea si hay un clúster de solicitudes lentas inusualmente grande. A continuación, haga
doble clic en esa burbuja para ir a la herramienta Buscar, con el filtro esos eventos de solicitud filtrados. En Buscar puede
explorar el contenido de esas solicitudes e ir al código correspondiente para resolver el problema.
Filter
Detecte tendencias más específicas con los controles de filtro en la parte inferior de la ventana. Para aplicar un
filtro, haga clic en su nombre. Puede cambiar rápidamente entre distintos filtros para detectar tendencias que
pueden estar ocultas en una determinada dimensión de la telemetría. Si aplica un filtro en una dimensión, como
Tipo de excepción, sigue siendo posible hacer clic en los filtros de otras dimensione, aunque aparecen atenuados.
Para dejar de aplicar un filtro, vuelva a hacer clic en él. Haga ctrl-clic para seleccionar varios filtros de la misma
dimensión.
¿Qué ocurre si desea aplicar varios filtros?

1. Aplique el primer filtro.
2. Haga clic en el botón Apply selected filters and quer y again (Aplicar filtros seleccionados y volver a
consultar) para usar el nombre de la dimensión de su primer filtro. Esto volverá a consultar la telemetría solo
para los eventos que coinciden con el primer filtro.
3. Aplique un segundo filtro.
4. Repita el proceso para buscar tendencias en subconjuntos específicos de la telemetría. Por ejemplo, las
solicitudes de servidor denominadas "GET Home/Index" y que procedían de Alemania y que recibieron un
código de respuesta 500.
Para dejar de aplicar uno de estos filtros, haga clic en el botón Remove selected filters and quer y again
(Quitar filtros seleccionados y volver a consultar) de la dimensión.
Búsqueda de anomalías
La herramienta Tendencias puede resaltar las burbujas de eventos anómalos en comparación con otras burbujas
de la misma serie temporal. En la lista desplegable Tipo de vista, elija Recuentos en el ciclo (resaltar
anomalías) o Porcentajes en el ciclo (resaltar anomalías) . Las burbujas rojas son anómalas. Las anomalías
se definen como burbujas con recuentos o porcentajes que superan 2,1 veces la desviación estándar de los
recuentos o porcentajes que se produjeron en los últimos dos períodos (48 horas si está viendo las últimas 24
horas, etc.).
TIP
Resaltar las anomalías es especialmente útil para buscar valores atípicos en series temporales de pequeñas burbujas que, de
lo contrario, pueden parecer de tamaño similar.
Pasos siguientes

Busque la telemetría, consulte los datos de CodeLens y
configure Application Insights. Todos desde Visual Studio.

Paneles, eficaces herramientas de diagnóstico y análisis,
alertas, un mapa activo de dependencias de la aplicación y
exportación de la telemetría.
Telemetría de Application Insights en CodeLens de
Visual Studio
Los métodos del código de la aplicación web se pueden anotar con telemetría acerca de las excepciones en tiempo
de ejecución y los tiempos de respuesta de las solicitudes. Si instala Azure Application Insights en la aplicación, la
telemetría aparece en CodeLens de Visual Studio (las notas de la parte superior de cada función en las que suele
ver información útil, como el número de lugares en que se hace referencia a la función o la última persona que la
editó).
NOTE
Application Insights en CodeLens está disponible en Visual Studio 2015 actualización 3, y posteriores, o bien con la última
versión de la extensión de Developer Analytics Tools. CodeLens está disponible en las ediciones Enterprise y Professional de
Visual Studio.
Dónde encontrar datos de Application Insights

Busque los datos de telemetría de Application Insights en los indicadores de CodeLens de los métodos de solicitud
públicos de la aplicación web. Los indicadores de CodeLens se muestran encima del método y de otras
declaraciones en el código de C# y Visual Basic. Si hay datos de Application Insights disponibles para un método,
verá indicadores de solicitudes y excepciones como "100 solicitudes, 1 % con error" o "10 excepciones". Para más
detalles, haga clic en un indicador de CodeLens.
TIP
Los indicadores de solicitudes y excepciones de Application Insights pueden tardar unos segundos más en cargarse después
de que aparezcan otros indicadores de CodeLens.
Excepciones en CodeLens
El indicador de excepción de CodeLens muestra el número de excepciones que se han producido en las últimas 24
horas de las 15 excepciones que se producen con más frecuencia en la aplicación durante dicho período, al
procesar la solicitud atendida por el método.
Para más detalles, haga clic en el indicador de excepciones de CodeLens:
El cambio de porcentaje en el número de excepciones en las últimas 24 horas, con respecto a las 24 horas
anteriores
Elija Ir al código para navegar el código fuente de la función que genera la excepción.
Elija Buscar para consultar todas las instancias de esta excepción que se han producido en las últimas 24 horas.
Elija Tendencia para ver la tendencia de las repeticiones de esta excepción en las últimas 24 horas.
Elija Ver todas las excepciones en esta aplicación para consultar todas las excepciones que se han
producido en las últimas 24 horas.
Elija Explorar tendencias de excepción para ver la tendencia de todas las excepciones que se han producido
en las últimas 24 horas.
TIP
Si ve "0 excepciones" en CodeLens, pero sabe que debería haber excepciones, asegúrese de que está seleccionado el recurso
de Application Insights correcto en CodeLens. Para seleccionar otro recurso, haga clic con el botón derecho en el proyecto en
el Explorador de soluciones y elija Application Insights > Elegir origen de telemetría . CodeLens solo se muestra para
las 15 excepciones que se producen con mayor frecuencia en la aplicación en las últimas 24 horas, por lo que si una
excepción está en el lugar 16º, o más allá, "0 excepciones". Las excepciones de las vistas de ASP.NET puede que no aparezcan
en los métodos de controlador que generaron dichas vistas.
TIP
Si ve "? excepciones"en CodeLens, se deberá a que es preciso que asocie su cuenta de Azure con Visual Studio o puede que
haya caducado la credencial de su cuenta de Azure. En ambos casos, haga clic en "? excepciones" y elija Agregar una
cuenta... para escribir sus credenciales.
Solicitudes en CodeLens
El indicador de solicitud de CodeLens muestra el número de solicitudes HTTP que sido atendidas por un método en
las últimas 24 horas, además del porcentaje de dichas solicitudes en las que han producido errores.
Para más detalles, haga clic en el indicador de solicitudes de CodeLens:
Los cambios, tanto a nivel absoluta como porcentual, en el número de solicitudes, solicitudes con error y
tiempos de respuesta medios durante las últimas 24 horas, en comparación con las 24 horas anteriores.
La confiabilidad del método, calculada como el porcentaje de solicitudes en que no se produjeron errores en las
últimas 24 horas.
Elija Buscar para las solicitudes o las solicitudes con error para consultar todas las solicitudes (con error) que se
produjeron en las últimas 24 horas.
Elija Tendencia para ver la tendencia para las solicitudes, las solicitudes con errores o los tiempos de respuesta
medios en las últimas 24 horas.
Elija el nombre del recurso de Application Insights en la esquina superior izquierda de la vista de detalles de
CodeLens para cambiar el recurso que es el origen de los datos de CodeLens.
Pasos siguientes

Busque la telemetría, consulte los datos de CodeLens y
configure Application Insights. Todos desde Visual Studio.


Paneles, eficaces herramientas de diagnóstico y análisis,
alertas, un mapa activo de dependencias de la aplicación y
exportación de la telemetría.
Supervisión de un sitio de SharePoint con
Azure Application Insights le permite supervisar la disponibilidad, el rendimiento y el uso de sus aplicaciones.
Aquí aprenderá a configurarlo para un sitio de SharePoint.
NOTE
Debido a algunos problemas de seguridad, no puede agregar directamente el script que se describe en este artículo a sus
páginas web de la experiencia de usuario moderna de SharePoint. También puede usar el marco de SharePoint (SPFx) para
crear una extensión personalizada que puede usar para instalar Application Insights en los sitios de SharePoint. Para más
información, consulte Creación de una solución de extensión de SPFx con AppInsights instalado desde cero o consulte el
ejemplo.

En el portal de Azure, cree un nuevo recurso de Application Insights. Elija ASP.NET como el tipo de aplicación.
En la ventana que se abre podrá ver los datos de uso y rendimiento acerca de la aplicación. Para volver a ella la
próxima vez que inicie sesión en Azure, encontrará un icono correspondiente en la pantalla de inicio. También
puede hacer clic en Examinar para buscarla.
Incorporación del script a sus páginas web


aiName=window[sdkInstance],aisdk=window[aiName]||function(n){var o=
{config:n,initialize:!0},t=document,e=window,i="script";setTimeout(function(){var
e=t.createElement(i);e.src=n.url||"https://az416426.vo.msecnd.net/scripts/b/ai.2.min.js",t.getElementsByTagNa
me(i)[0].parentNode.appendChild(e)});try{o.cookie=t.cookie}catch(e){}function a(n){o[n]=function(){var
e=arguments;o.queue.push(function(){o[n].apply(o,e)})}}o.queue=[],o.version=2;for(var s=
["Event","PageView","Exception","Trace","DependencyData","Metric","PageViewPerformance"];s.length;)a("track"+
s.pop());var r="Track",c=r+"Page";a("start"+c),a("stop"+c);var
u=r+"Event";if(a("start"+u),a("stop"+u),a("addTelemetryInitializer"),a("setAuthenticatedUserContext"),a("clea
rAuthenticatedUserContext"),a("flush"),o.SeverityLevel=
{Verbose:0,Information:1,Warning:2,Error:3,Critical:4},!
(!0===n.disableExceptionTracking||n.extensionConfig&&n.extensionConfig.ApplicationInsightsAnalytics&&!0===n.e
xtensionConfig.ApplicationInsightsAnalytics.disableExceptionTracking)){a("_"+(s="onerror"));var
p=e[s];e[s]=function(e,n,t,i,a){var r=p&&p(e,n,t,i,a);return!0!==r&&o["_"+s]
({message:e,url:n,lineNumber:t,columnNumber:i,error:a}),r},n.autoExceptionInstrumented=!0}return o}(
{
instrumentationKey:"INSTRUMENTATION_KEY"
}
);(window[aiName]=aisdk).queue&&0===aisdk.queue.length&&aisdk.trackPageView({});
</script>
Inserte el script justo antes de la etiqueta </head> de cada página que desea seguir. Si su sitio web tiene una
página maestra, puede colocar el script allí. Por ejemplo, en un proyecto de ASP.NET MVC, lo colocaría en
View\Shared\_Layout.cshtml.
El script contiene la clave de instrumentación que dirige los datos de telemetría al recurso de Application Insights.
Agregar el código a las páginas del sitio
En la página maestra
Si se puede editar la página maestra del sitio, dispondrá de supervisión para cada página del sitio.
Desproteja y edite la página maestra mediante SharePoint Designer o cualquier otro editor.
Agregue el código justo antes de la etiqueta .
O, en páginas individuales
Para supervisar un conjunto limitado de páginas, agregue el script por separado a cada página.
Inserte un elemento web e incruste el fragmento de código en él.
Visualización de los datos de la aplicación

Vuelva a implementar la aplicación.
Vuelva a la hoja de la aplicación en el Portal de Azure.
Los primeros eventos aparecerán en la búsqueda.
Si espera más datos, haga clic en Actualizar después de unos segundos.
Captura del identificador de usuario

El fragmento de código de una página web estándar no captura el identificador de usuario de SharePoint, pero
una pequeña modificación le permitirá hacerlo.
1. Copie la clave de instrumentación de la aplicación de la lista desplegable Essentials en Application Insights .
2. En el siguiente fragmento, sustituya la clave de instrumentación por "XXXX".

3. Inserte el script en la aplicación de SharePoint en lugar del fragmento de código que obtenga desde el
portal.
<SharePoint:ScriptLink ID="ScriptLink1" name="SP.js" runat="server" localizable="false" loadafterui="true" />
<SharePoint:ScriptLink ID="ScriptLink2" name="SP.UserProfiles.js" runat="server" localizable="false"
loadafterui="true" />
var personProperties;
// Ensure that the SP.UserProfiles.js file is loaded before the custom code runs.
SP.SOD.executeOrDelayUntilScriptLoaded(getUserProperties, 'SP.UserProfiles.js');
function getUserProperties() {
// Get the current client context and PeopleManager instance.
var clientContext = new SP.ClientContext.get_current();
var peopleManager = new SP.UserProfiles.PeopleManager(clientContext);
// Get user properties for the target user.

// To get the PersonProperties object for the current user, use the
// getMyProperties method.
personProperties = peopleManager.getMyProperties();
// Load the PersonProperties object and send the request.

clientContext.load(personProperties);
clientContext.executeQueryAsync(onRequestSuccess, onRequestFail);
}
// This function runs if the executeQueryAsync call succeeds.

function onRequestSuccess() {
var appInsights=window.appInsights||function(config){
function s(config){t[config]=function(){var i=arguments;t.queue.push(function(){t[config].apply(t,i)})}}var
t=
{config:config},r=document,f=window,e="script",o=r.createElement(e),i,u;for(o.src=config.url||"//az416426.vo.
msecnd.net/scripts/a/ai.0.js",r.getElementsByTagName(e)
[0].parentNode.appendChild(o),t.cookie=r.cookie,t.queue=[],i=
["Event","Exception","Metric","PageView","Trace"];i.length;)s("track"+i.pop());return
config.disableExceptionTracking||(i="onerror",s("_"+i),u=f[i],f[i]=function(config,r,f,e,o){var
s=u&&u(config,r,f,e,o);return s!==!0&&t["_"+i](config,r,f,e,o),s}),t
}({
instrumentationKey:"XXXX"
});
appInsights.trackPageView(document.title,window.location.href, {User:
personProperties.get_displayName()});
}
// This function runs if the executeQueryAsync call fails.

function onRequestFail(sender, args) {
}
</script>
Pasos siguientes
Pruebas web para supervisar la disponibilidad de su sitio.
Application Insights para otros tipos de aplicación.
Supervisión del uso y el rendimiento en las
aplicaciones de escritorio de Windows clásicas
Las aplicaciones hospedadas en el entorno local, en Azure y en otras nubes pueden aprovechar las ventajas de
Application Insights. La única limitación es la necesidad de permitir la comunicación al servicio de Application
Insights. Para supervisar las aplicaciones de la Plataforma universal de Windows (UWP), se recomienda Visual
Studio App Center.
Para enviar datos de telemetría a Application Insights desde una

aplicación Windows clásica
1. En Azure Portal, cree un recurso de Application Insights.
2. Realice una copia de la clave de instrumentación.
3. En Visual Studio, edite los paquetes NuGet de su proyecto de aplicación y agregue
Microsoft.ApplicationInsights.WindowsServer. (O elija Microsoft.ApplicationInsights si únicamente le
interesa la API de base, sin los módulos de recopilación de datos de telemetría estándar).
4. Establezca la clave de instrumentación en el código:
TelemetryConfiguration.Active.InstrumentationKey = " su clave ";
o en ApplicationInsights.config (si tiene instalado uno de los paquetes de telemetría estándar):

<InstrumentationKey> su clave </InstrumentationKey>
Si usa ApplicationInsights.config, asegúrese de que sus propiedades en el Explorador de soluciones se
establecen en Acción de compilación = Contenido, Copiar en el directorio de salida = Copiar .
5. Use la API para enviar telemetría.
6. Ejecute la aplicación y vea la telemetría en el recurso que creó en Azure Portal.
Ejemplo de código
public partial class Form1 : Form

{
private TelemetryClient tc = new TelemetryClient();
...
private void Form1_Load(object sender, EventArgs e)
{
// Alternative to setting ikey in config file:
tc.InstrumentationKey = "key copied from portal";
// Set session data:

tc.Context.Session.Id = Guid.NewGuid().ToString();
tc.Context.Device.OperatingSystem = Environment.OSVersion.ToString();
// Log a page view:

tc.TrackPageView("Form1");
...
}
protected override void OnClosing(System.ComponentModel.CancelEventArgs e)

{
e.Cancel = true;
if (tc != null)
{
tc.Flush(); // only for desktop apps
// Allow time for flushing:

System.Threading.Thread.Sleep(1000);
}
base.OnClosing(e);
}
Invalidación del almacenamiento del nombre de equipo

De forma predeterminada, este SDK recopilará y almacenará el nombre de equipo del sistema que emite la
telemetría.
El plan de tarifa Enterprise (por nodo) heredado de Application Insights usa el nombre de equipo para la
facturación interna. De forma predeterminada, si usa un inicializador de telemetría para invalidar
telemetry.Context.Cloud.RoleInstance , se enviará una propiedad ai.internal.nodeName independiente con el
valor del nombre de equipo. Este valor no se almacenará con los datos de telemetría de Application Insights,
sino que se usa internamente en la ingesta para permitir la compatibilidad con versiones anteriores con el
modelo de facturación basado en nodos heredado.
Si está en el plan de tarifa Enterprise (por nodo) heredado y simplemente necesita invalidar el almacenamiento
del nombre de equipo, use un inicializador de telemetría:
Escriba un elemento Telemetr yInitializer personalizado como el siguiente.
namespace CustomInitializer.Telemetry
{
{
{
if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleInstance))
{
// Set custom role name here. Providing an empty string will result
// in the computer name still be sent via this property.
telemetry.Context.Cloud.RoleInstance = "Custom RoleInstance";
}
}
}
}
Cree una instancia del inicializador en el método Main() de Program.cs que aparece a continuación al
establecer la clave de instrumentación:
static void Main()

{
TelemetryConfiguration.Active.InstrumentationKey = "{Instrumentation-key-here}";
//...
}
Invalidación de la transmisión del nombre de equipo

Si no está en el plan de tarifa Enterprise (por nodo) heredado y desea evitar completamente que los datos de
telemetría contengan el nombre de equipo, debe usar un procesador de telemetría.
Procesador de telemetría
namespace WindowsFormsApp2
{
public class CustomTelemetryProcessor : ITelemetryProcessor
{
private readonly ITelemetryProcessor _next;
public CustomTelemetryProcessor(ITelemetryProcessor next)

{
_next = next;
}

{
if (item != null)
{
item.Context.Cloud.RoleInstance = string.Empty;
}
_next.Process(item);
}
}
}
Cree una instancia del procesador de telemetría en el método Main() de Program.cs que aparece después de
establecer la clave de instrumentación:
namespace WindowsFormsApp2
{
static class Program
{
static void Main()
{
TelemetryConfiguration.Active.InstrumentationKey = "{Instrumentation-key-here}";
var builder =
TelemetryConfiguration.Active.DefaultTelemetrySink.TelemetryProcessorChainBuilder;
builder.Use((next) => new CustomTelemetryProcessor(next));
builder.Build();
//...
}
}
}
NOTE
Aunque técnicamente puede usar un procesador de telemetría tal y como se describió anteriormente aunque se
encuentre en el plan de tarifa empresa heredada (por nodo), esto dará lugar a una posible facturación excesiva debido a
la incapacidad de distinguir correctamente los nodos en el caso de los precios por nodo.
Pasos siguientes
Creación de un panel
Uso de Application Change Analysis (versión
preliminar) en Azure Monitor
Cuando se produce una interrupción o un problema en un sitio activo, determinar rápidamente la causa raíz es
fundamental. Las soluciones de supervisión estándares pueden alertarlo sobre un problema. Incluso pueden
indicarle qué componente está presentando el error. Sin embargo, esta alerta no siempre explica inmediatamente
la causa del error. Sabrá que su sitio funcionaba hace cinco minutos y que ahora no funciona. ¿Qué cambió en los
últimos cinco minutos? Esta es la pregunta que Application Change Analysis está diseñado para responder en
Azure Monitor.
A partir de la eficacia de Azure Resource Graph, Change Analysis proporciona conclusiones sobre los cambios de la
aplicación de Azure para aumentar la observación y reducir el tiempo medio para reparación.
IMPORTANT
Change Analysis se encuentra actualmente en versión preliminar. Esta versión preliminar se proporciona sin un contrato de
nivel de servicio. Esta versión no se recomienda para usarse en cargas de trabajo. Es posible que algunas características no
sean compatibles o que sus funcionalidades estén limitadas. Para obtener más información, consulte Términos de uso
complementarios de las Versiones preliminares de Microsoft Azure.
Change Analysis detecta varios tipos de cambios, desde el nivel de infraestructura hasta la implementación de la
aplicación. Es un proveedor de recursos de Azure de nivel de suscripción que comprueba los cambios de recursos
en la suscripción. Change Analysis proporciona datos para que varias herramientas de diagnóstico ayuden a los
usuarios a comprender qué cambios pueden haber causado los problemas.
El siguiente diagrama muestra la arquitectura de Change Analysis:
Orígenes de datos
Consultas de Application Change Analysis para propiedades controladas de Azure Resource Manager,
configuraciones con proxy y cambios en el invitado de la aplicación web. Además, el servicio hace un seguimiento
de los cambios en las dependencias de los recursos para diagnosticar y supervisar una aplicación completa.
Cambios en la propiedades controladas de Azure Resource Manager
Mediante Azure Resource Graph, Change Analysis proporciona un registro histórico de la forma en que los
recursos de Azure que hospedan a la aplicación han cambiado con el tiempo. Es posible detectar la configuración
controlada, como las identidades administradas, la actualización del sistema operativo de la plataforma y los
nombres de host.
Cambios en la configuración con Proxy de Azure Resource Manager
Las opciones de configuración, como la regla de configuración de IP, configuración de TLS y versiones de extensión,
todavía no están disponibles en Azure Resource Graph. Por lo tanto, las consultas de Change Analysis se calculan
de forma segura para proporcionar más detalles sobre lo que ha cambiado en la aplicación.
Cambios en la implementación y la configuración de aplicaciones web (cambios en invitado )
Change Analysis captura el estado de implementación y configuración de una aplicación cada 4 horas. Puede
detectar, por ejemplo, los cambios en las variables de entorno de aplicación. La herramienta calcula las diferencias
y presenta qué ha cambiado. A diferencia de los cambios de Resource Manager, es posible que la información
sobre cambios en la implementación de código no esté disponible en la herramienta inmediatamente. Para ver los
cambios más recientes en Change Analysis, seleccione Actualizar .
Cambios de dependencia
Los cambios realizados en las dependencias de recursos también pueden causar problemas en una aplicación web.
Por ejemplo, si llama una aplicación web a una caché de Redis Cache, la SKU la dicha caché podría afectar al
rendimiento de la aplicación de web. Para detectar los cambios en las dependencias, Change Analysis comprueba
el registro DNS de la aplicación web. De este modo, identifica los cambios en todos los componentes de aplicación
que podrían ocasionar problemas. Actualmente se admiten las siguientes dependencias:
Web Apps
Azure Storage
Azure SQL
Servicio Application Change Analysis

El servicio Application Change Analysis calcula y agrega los datos modificados de los orígenes de datos
mencionados anteriormente. Proporciona un conjunto de análisis para que los usuarios naveguen fácilmente por
todos los cambios de los recursos y para identificar qué cambio es pertinente en el contexto de solución de
problemas o de supervisión. Es necesario registrar el proveedor de recursos "Microsoft. ChangeAnalysis" con una
suscripción para que esté disponible la configuración de propiedades controladas y datos de cambio de
configuración con Proxy de Azure Resource Manager. Al entrar en la herramienta Diagnosticar y solucionar
problemas de Web Apps o abrir la hoja independiente de Change Analysis, este proveedor de recursos se registra
automáticamente. No tiene ningún costo de implementación ni rendimiento para la suscripción. Al habilitar
Change Analysis para aplicaciones web (o habilitar la herramienta Diagnosticar y resolver problemas), tendrá un
impacto insignificante en el rendimiento de la aplicación web y ningún costo de facturación. En el caso de cambios
en el invitado de la aplicación web, se requiere una habilitación independiente para examinar los archivos de
código dentro de una aplicación web. Para más información, consulte la sección Change Analysis en la herramienta
Diagnosticar y solucionar problemas que aparece más adelante en este artículo para obtener más detalles.
Visualizaciones para Application Change Analysis

UI independiente
En Azure Monitor, hay un panel independiente para que Change Analysis vea todos los cambios con información
sobre los recursos de información y dependencias de aplicaciones.
Busque Change Analysis en la barra de búsqueda de Azure Portal para iniciar la experiencia.
Todos los recursos de una suscripción seleccionada se muestran con los cambios de las últimas 24 horas. Para
optimizar el rendimiento de carga de páginas, el servicio muestra 10 recursos a la vez. Haga clic en las páginas
siguientes para ver más recursos. Estamos trabajando actualmente para poder quitar esta limitación.
Haga clic en un recurso para ver todos sus cambios. Si es necesario, explore en profundidad un cambio para ver la
información y los detalles sobre el cambio en formato JSON.
Si tiene algún comentario, use el botón Enviar comentarios de la hoja o el correo electrónico
changeanalysisteam@microsoft.com.
Diagnóstico y solución de problemas de una aplicación web

En Azure Monitor, Change Analysis también está integrado en la experiencia de autoservicio Diagnosticar y
solucionar problemas . Obtenga acceso a esta experiencia desde la pagina Información general de la
aplicación de App Service.
Application Change Analysis en la herramienta Diagnosticar y solucionar problemas
Application Change Analysis es un detector independiente en las herramientas de diagnóstico y solución de
problemas de una aplicación web. También se agrega en Application Crashes (Bloqueos de la aplicación) y Web
App Down detectors (Detectores de aplicación web fuera de servicio). Cuando entra en la herramienta
Diagnosticar y solucionar problemas, el proveedor de recursos Microsoft.ChangeAnalysis se registrará
automáticamente. Siga estas instrucciones para habilitar el seguimiento de cambios en el invitado de la aplicación
web.
1. Seleccione Availability and Performance (Disponibilidad y rendimiento).
2. Seleccione Application Changes (Cambios de la aplicación). Esta característica también está disponible en
Application Crashes (Bloqueos de la aplicación).
3. Para habilitar Change Analysis, seleccione Habilitar ahora .
4. Active Change Analysis y seleccione Guardar . La herramienta muestra todas las aplicaciones web en un
plan de App Service. Puede usar el modificador nivel de plan para activar Application Change Analysis para
todas las aplicaciones web de un plan.
5. Para obtener acceso a Change Analysis, seleccione Diagnosticar y solucionar problemas > Availability
and Performance (disponibilidad y rendimiento) > Application Crashes (bloqueos de
aplicación) . Verá un gráfico con un resumen del tipo de cambios a lo largo del tiempo, junto con detalles
sobre estos cambios: De forma predeterminada, se muestran los cambios en las últimas 24 horas para
ayudar a solucionar problemas inmediatos.
Habilitación de Change Analysis a gran escala

Si la suscripción incluye varias aplicaciones web, podría resultar ineficaz habilitar el servicio en el nivel de
aplicación web. Ejecute el siguiente script para habilitar todas las aplicaciones web de su suscripción.
Requisitos previos:
Módulo Az de PowerShell. Siga las instrucciones de Instalación del módulo de Azure PowerShell.
Ejecute el siguiente script:
# Log in to your Azure subscription

Connect-AzAccount
# Get subscription Id
$SubscriptionId = Read-Host -Prompt 'Input your subscription Id'
# Make Feature Flag visible to the subscription

Set-AzContext -SubscriptionId $SubscriptionId
# Register resource provider

Register-AzResourceProvider -ProviderNamespace "Microsoft.ChangeAnalysis"
# Enable each web app

$webapp_list = Get-AzWebApp | Where-Object {$_.kind -eq 'app'}
foreach ($webapp in $webapp_list)
{
$tags = $webapp.Tags
$tags[“hidden-related:diagnostics/changeAnalysisScanEnabled”]=$true
Set-AzResource -ResourceId $webapp.Id -Tag $tags -Force
}
Diagnóstico y solución de problemas de una máquina virtual

Vaya a la herramienta Diagnosticar y solucionar problemas para una máquina virtual. Vaya a Herramientas para
la solución de problemas , navegue hacia abajo de la página y seleccione Analizar cambios recientes para
ver los cambios en la máquina virtual.
Pasos siguientes
Habilitar Application Insights para aplicaciones de Azure App Services.
Habilitar Application Insights para aplicaciones hospedadas en IIS en máquina virtual de Azure y conjunto de
Obtenga más información sobre Azure Resource Graph, que ayuda a la eficacia de Change Analysis.
¿Qué es Azure Monitor para máquinas
virtuales?
Azure Monitor para VM supervisa el rendimiento y el mantenimiento de las máquinas virtuales y los
conjuntos de escalado de máquinas virtuales, incluidos los procesos en ejecución y las dependencias
de otros recursos. Puede ayudar a ofrecer de forma eficaz un rendimiento predecible y disponibilidad
de las aplicaciones vitales mediante la identificación de cuellos de botella de rendimiento y problemas
de red, así como ayudar a comprender si un problema está relacionado con otras dependencias.
Azure Monitor para VM admite sistemas operativos Windows y Linux en:
Conjuntos de escalado de máquinas virtuales de Azure
Máquinas virtuales híbridas conectadas con Azure Arc
Máquinas virtuales locales
Máquinas virtuales hospedadas en otro entorno de nube
Azure Monitor para VM almacena sus datos en registros de Azure Monitor, lo que le permite ofrecer
una agregación y un filtrado eficaces, y el análisis de las tendencias de los datos a lo largo del tiempo.
Puede ver estos datos directamente en una sola VM desde la máquina virtual, o puede usar a Azure
Monitor para ofrecer una vista agregada de varias VM.
Precios
No hay ningún costo directo por Azure Monitor para VM, pero se le cobrará por la actividad en el área
de trabajo de Log Analytics. Según los precios que se publican en la página de precios de Azure
Monitor, Azure Monitor para VM se factura según:
Datos ingeridos de agentes y almacenados en el área de trabajo.
Las reglas de alertas basadas en el registro y los datos de estado.
Las notificaciones enviadas desde reglas de alertas.
El tamaño del registro varía en función de las longitudes de cadena de los contadores de rendimiento
y puede aumentar con el número de discos lógicos y adaptadores de red asignados a la máquina
virtual. Si ya usa Service Map, el único cambio que verá son los datos de rendimiento adicionales que
se envían al tipo de datos InsightsMetrics de Azure Monitor.
Configuración de Azure Monitor para VM

Los pasos para configurar Azure Monitor para VM son los siguientes. Siga cada vínculo para obtener
instrucciones detalladas sobre cada paso:
Creación de un área de trabajo de Log Analytics.
Incorporación de la solución VMInsights al área de trabajo.
Instalación de agentes en la máquina virtual y el conjunto de escalado de máquinas virtuales que
se van a supervisar.
Pasos siguientes
Consulte Implementación de Azure Monitor para VM para conocer los requisitos y los métodos
para habilitar la supervisión de máquinas virtuales.
Preguntas frecuentes sobre Azure Monitor para VM
disponible de forma general (GA): preguntas más
frecuentes
En estas Preguntas más frecuentes acerca de la disponibilidad general se describen los cambios realizados en el
cuarto trimestre de 2019 y el primer trimestre de 2020, a medida que los preparábamos para disponibilidad
general.
Actualizaciones de Azure Monitor para VM

Hemos publicado una versión nueva de Azure Monitor para VM en enero de 2020 antes de nuestro anuncio
sobre la disponibilidad general. Los clientes que habiliten Azure Monitor para VM recibirán la nueva versión de
disponibilidad general, mientras que a los clientes existentes que usan Azure Monitor para VM desde el cuarto
trimestre de 2019 y versiones anteriores se les solicitará que realicen la actualización. En estas preguntas
frecuentes se ofrece una guía para realizar una actualización a gran escala si tiene implementaciones de gran
tamaño en varias áreas de trabajo.
Con esta actualización, los datos de rendimiento de Azure Monitor para VM se almacenan en la misma tabla
InsightsMetrics que Azure Monitor para contenedores, lo que facilita la consulta de los dos conjuntos de datos.
Además, puede almacenar conjuntos de datos más diversos que no podíamos almacenar en la tabla utilizada
anteriormente.
Ahora nuestras vistas de rendimiento usan los datos que almacenamos en la tabla InsightsMetrics. Si aún no ha
llevado a cabo la actualización para usar la solución de VMInsights más reciente en el área de trabajo, los
gráficos ya no mostrarán información. Puede actualizar desde nuestra página Get Star ted como se describe a
continuación.
¿Qué está cambiando?

Se ha lanzado una nueva solución, llamada VMInsights, que incluye funcionalidades adicionales para la
recopilación de datos, junto con una nueva ubicación para almacenar estos datos en el área de trabajo de Log
Analytics.
En el pasado, se habilitó la solución ServiceMap en el área de trabajo y se configuraron contadores de
rendimiento en el área de trabajo de Log Analytics para enviar los datos a la tabla Perf. Esta nueva solución
envía los datos a una tabla llamada InsightsMetrics, que también se usa en Azure Monitor para contenedores. El
esquema de esta tabla nos permite almacenar métricas adicionales y conjuntos de datos de servicio que no son
compatibles con el formato de la tabla Perf.
Se han actualizado los gráficos de rendimiento para usar los datos que almacenamos en la tabla
InsightsMetrics. Puede actualizar para usar la tabla InsightsMetrics desde nuestra página Comenzar como se
describe a continuación.
¿Cómo realizar una actualización?

Cuando un área de trabajo de Log Analytics se actualiza a la versión más reciente de Azure Monitor a las
máquinas virtuales, actualizará el agente de dependencias en cada una de las máquinas virtuales asociadas al
área de trabajo. Cada máquina virtual que necesite actualización se identificará en la pestaña Introducción de
Azure Monitor para VM en Azure Portal. Cuando elige actualizar una máquina virtual, se actualiza el área de
trabajo de esa máquina virtual junto con cualquier otra máquina virtual conectada al área de trabajo. Puede
seleccionar una o varias máquinas virtuales, grupos de recursos o suscripciones.
Use el siguiente comando para actualizar un área de trabajo mediante PowerShell:
Set-AzOperationalInsightsIntelligencePack -ResourceGroupName <resource-group-name> -WorkspaceName

<workspace-name> -IntelligencePackName "VMInsights" -Enabled $True
¿Qué debo hacer con los contadores de rendimiento de mi área de

trabajo si instalo la solución VMInsights?
El método anterior de habilitación de Azure Monitor para VM usaba contadores de rendimiento en el área de
trabajo. La versión actual almacena estos datos en una tabla denominada InsightsMetrics . Puede elegir
deshabilitar estos contadores de rendimiento en el área de trabajo si ya no necesita usarlos.
NOTE
Si tiene reglas de alertas que hagan referencia a estos contadores en la tabla Perf , deberá actualizarlas para que hagan
referencia a los nuevos datos almacenados en la tabla InsightsMetrics . Consulte nuestra documentación para
obtener ejemplos de consultas de registro que puede usar y que hacen referencia a esta tabla.
Si decide mantener los contadores de rendimiento habilitados, se le facturarán los datos ingeridos y
conservados en la tabla Perf según los [precios de Log
Analytics[(https://azure.microsoft.com/pricing/details/monitor/).
¿Cómo afectará este cambio a las reglas de alerta?

Si ha creado alertas del registro que consultan los contadores de rendimiento dirigidos a la tabla Perf que se
han habilitado en el área de trabajo, debe actualizar estas reglas para que hagan referencia a la tabla
InsightsMetrics en su lugar. Esta guía también se aplica a las reglas de búsqueda de registros mediante
ServiceMapComputer_CL y ServiceMapProcess_CL , ya que esos conjuntos de datos se mueven a las tablas
VMComputer y VMProcess .
Actualizaremos tanto este documento con preguntas frecuentes como nuestra documentación para incluir
reglas de alertas de búsqueda de registros de ejemplo para los conjuntos de datos que recopilamos.
¿Cómo afectará esto a la factura?

La facturación todavía se basa en los datos ingeridos y retenidos en el área de trabajo de Log Analytics.
Los datos de rendimiento de nivel de máquina que se recopilan son los mismos, tienen un tamaño similar a los
datos almacenados en la tabla Perf y costarán aproximadamente lo mismo.
¿Qué pasa si solo deseo usar Service Map?

No hay problema. Verá en Azure Portal mensajes acerca de la próxima actualización cuando vea Azure Monitor
para VM. Una vez que se lance, recibirá un mensaje en el que se le solicitará que actualice a la nueva versión. Si
prefiere usar solo la característica Maps, puede optar por no realizar la actualización y seguir usando la
característica Maps en Azure Monitor para VM y la solución Service Map a la que se accede desde el área de
trabajo o desde el icono del panel.
Si elige habilitar manualmente los contadores de rendimiento en el área de trabajo, es posible que pueda ver
los datos en algunos de los gráficos de rendimiento que se ven en Azure Monitor. Una vez que se lance la
nueva solución, actualizaremos los gráficos de rendimiento para consultar los datos almacenados en la tabla
InsightsMetrics . Si desea ver los datos de esa tabla en estos gráficos, tendrá que realizar la actualización a la
nueva versión de Azure Monitor para VM.
Los cambios para mover datos desde ServiceMapComputer_CL y ServiceMapProcess_CL afectarán tanto a Service
Map como a Azure Monitor para VM, por lo que debe planear esta actualización.
Aunque decida no realizar la actualización a la solución VMInsights , seguiremos proporcionando versiones
heredadas de los libros de rendimiento que hacen referencia a los datos de la tabla Perf .
¿Se almacenarán también en InsightsMetrics los conjuntos de datos

de Service Map?
Los conjuntos de datos no se duplicarán si usa ambas soluciones. Ambas ofertas comparten los conjuntos de
datos que se almacenarán en las tablas VMComputer (anteriormente ServiceMapComputer_CL), VMProcess
(anteriormente ServiceMapProcess_CL), VMConnection y VMBoundPort para almacenar los conjuntos de datos
del mapa que recopilemos.
La tabla InsightsMetrics almacenará los conjuntos de datos de máquinas virtuales, procesos y servicios que
recopilemos y solo se rellenará si se usa Azure Monitor para VM y la solución VM Insights. La solución Service
Map no recopilará ni almacenará datos en la tabla InsightsMetrics .
¿Se me cobrará el doble si tengo las soluciones Service Map y

VMInsights en mi área de trabajo?
No, las dos soluciones comparten los conjuntos de datos del mapa que almacenamos en VMComputer
(anteriormente ServiceMapComputer_CL), VMProcess (anteriormente ServiceMapProcess_CL), VMConnection y
VMBoundPort . Si tiene ambas soluciones en el área de trabajo, no se le cobrará el doble por estos datos.
Si elimino cualquiera de las dos soluciones, Service Map o

VMInsights, ¿se eliminarán mis datos?
No, las dos soluciones comparten los conjuntos de datos del mapa que almacenamos en VMComputer
(anteriormente ServiceMapComputer_CL), VMProcess (anteriormente ServiceMapProcess_CL), VMConnection y
VMBoundPort . Si elimina una de las soluciones, estos conjuntos de datos observan que aún hay una solución
que utiliza los datos y que permanece en el área de trabajo de Log Analytics. Para que los datos se eliminen del
área de trabajo, es preciso eliminar las dos soluciones del área de trabajo.
La característica Health está en versión preliminar pública limitada.

Hemos recibido muchos comentarios de los clientes sobre nuestro conjunto de características Health de la
máquina virtual. Existe gran interés en torno a esta característica y entusiasmo por su potencial para admitir la
supervisión de flujos de trabajo. Estamos planeando realizar varios cambios para agregar funcionalidad y dar
respuesta a los comentarios que hemos recibido.
Para minimizar el impacto de estos cambios en los clientes nuevos, hemos trasladado esta característica a una
versión preliminar pública limitada . Esta actualización se produjo en octubre de 2019.
Tenemos previsto volver a lanzar la característica Health en 2020, después de que Azure Monitor para VM se
encuentre en disponibilidad general.
¿Cómo acceden los clientes existentes a la característica Health?

Los clientes existentes que usen la característica Health seguirán teniendo acceso a ella, pero no se ofrecerán a
los nuevos clientes.
Para acceder a la característica, puede agregar la siguiente marca de la característica feature.vmhealth=true a la
dirección URL de Azure Portal, https://portal.azure.com. Ejemplo:
https://portal.azure.com/?feature.vmhealth=true .
También puede usar esta dirección URL corta, que establece la marca de la característica automáticamente:
https://aka.ms/vmhealthpreview.
Como cliente existente, puede seguir usando la característica Health en las máquinas virtuales conectadas a
una configuración de área de trabajo existente con la funcionalidad de estado.
Ahora utilizo la característica Health de la máquina virtual con un

entorno y desearía implementarla en uno nuevo.
Los clientes existentes que usan la característica Health y desean usarla para una nueva puesta en servicio,
póngase en contacto con nosotros en vminsights@microsoft.com para solicitar instrucciones.
Pasos siguientes
Para conocer los requisitos y los métodos para habilitar la supervisión de máquinas virtuales, consulte
Implementación de Azure Monitor para VM.
Azure Monitor.
General
para Azure Monitor.
Monitor.
Registros
en Azure Monitor.
información.
sus tipos.
Métricas
de métricas?
Alertas
tipos de alertas:
Agentes
Analytics.
de datos enviada:
WireData
la red.
Log Analytics?
recurso.
Visualizaciones
Aplicación .NET
virtuales de Azure
SharePoint
Otras plataformas
¿Es gratis?
limitar los gastos.
¿Cuánto cuesta?
ai.js
Web.config
packages.config
Resource Manager?
Más información.
Solicitudes HTTP
Log Analytics
Logstash

Podría:
servidor proxy.

automáticamente)
rendimiento
web

de servidor
producido.
Automation
proxy.
...
<TelemetryModules>
<Add
t>
</Add>
</TelemetryModules>
...
<TelemetryChannel>
</TelemetryChannel>
...
...
NOTE

<system.net>
<defaultProxy>
</defaultProxy>
</system.net>

soluciones:

sencilla.
contenedores.
Kubelet
Opción 1
combinaciones.

ContainerLog
ContainerData
Opción 2
NOTE

clústeres.
Helm?
contenedores.
}));
los registros:
21Vianet.

compatibles.
Insights.
agregado?
subredes?
experiencia.
protocolos.
Pasos siguientes
adicionales.
Log Analytics
Configuración del área de trabajo de Log Analytics
para Azure Monitor para VM
Azure Monitor para VM recopila sus datos de una o varias áreas de trabajo de Log Analytics en Azure Monitor.
Antes de incorporar agentes, debe crear y configurar un área de trabajo. En este artículo se describen los
requisitos del área de trabajo y cómo configurarla para Azure Monitor para VM.
Una suscripción única puede usar cualquier número de áreas de trabajo en función de sus requisitos. El único
requisito del área de trabajo es que se encuentre en una ubicación admitida y esté configurada con la solución
VMInsights.
Una vez configurada el área de trabajo, puede usar cualquiera de las opciones disponibles para instalar los
agentes necesarios en la VM y VMMS, y especificar un área de trabajo para que envíen sus datos. Azure Monitor
para VM recopilará datos de cualquier área de trabajo configurada en su suscripción.
NOTE
Al habilitar Azure Monitor para VM en una única VM o en VMMS con Azure Portal, se le ofrece la opción de seleccionar un
área de trabajo existente o crear una nueva. La solución VMInsights se instalará en este área de trabajo si aún no lo está.
Después, puede usar este área de trabajo para otros agentes.

NOTE
La información que se describe en esta sección también se aplica a la solución Service Map.
Acceda a las áreas de trabajo de Log Analytics en Azure Portal desde el menú Áreas de trabajo de Log
Analytics .
Puede crear una nueva área de trabajo de Log Analytics mediante cualquiera de los métodos siguientes. Consulte
Diseño de la implementación de registros de Azure Monitor para obtener instrucciones sobre cómo determinar
el número de áreas de trabajo que debe usar en su entorno y cómo diseñar su estrategia de acceso.
Azure Portal
CLI de Azure
PowerShell
Azure Resource Manager
Regiones admitidas
Azure Monitor para VM admite áreas de trabajo de Log Analytics en las siguientes regiones, aunque puede
supervisar las máquinas virtuales en cualquier región. Las máquinas virtuales en sí no se limitan a las regiones
admitidas por el área de trabajo de Log Analytics.
Centro-Oeste de EE. UU.
Oeste de EE. UU.
Oeste de EE. UU. 2
Centro-sur de EE. UU.
Este de EE. UU.
Este de EE. UU. 2
Centro de EE. UU.
Centro-Norte de EE. UU
US Gov Az
US Gov Va
Centro de Canadá
Sur de Reino Unido
Norte de Europa
Oeste de Europa
Este de Asia
Sudeste de Asia
Centro de la India
Japón Oriental
Este de Australia
Sudeste de Australia
Control de acceso basado en rol

Para habilitar y obtener acceso a las características de Azure Monitor para VM, debe tener el rol de colaborador
de Log Analytics en el área de trabajo. Para ver los datos de rendimiento, mantenimiento y el mapa, debe tener el
rol de lector de supervisión en la máquina virtual de Azure. Para más información acerca de cómo controlar el
acceso a un área de trabajo de Log Analytics, consulte Administración de áreas de trabajo.
Incorporación de la solución VMInsights al área de trabajo

Antes de que se pueda utilizar un área de trabajo de Log Analytics con Azure Monitor para VM, debe tener
instalada la solución VMInsights. Los métodos para configurar el área de trabajo se describen en las secciones
siguientes.
NOTE
Al agregar la solución VMInsights al área de trabajo, todas las máquinas virtuales existentes conectadas al área de trabajo
comenzarán a enviar datos a InsightsMetrics. Los datos del resto de tipos de datos no se recopilarán hasta que agregue
Dependency Agent a las máquinas virtuales existentes conectadas al área de trabajo.
Azure portal
Existen tres opciones para configurar un área de trabajo existente desde Azure Portal.
Para configurar una única área de trabajo, seleccione Otras opciones de incorporación y, a continuación,
Configurar un área de trabajo . Seleccione una suscripción y un área de trabajo y, a continuación, haga clic en
Configurar .
Para configurar varias áreas de trabajo, seleccione la pestaña Configuración del área de trabajo en el menú
Máquinas vir tuales del menú Super visión de Azure Portal. Establezca los valores de filtro para mostrar una
lista de áreas de trabajo existentes. Marque la casilla situada junto a cada área de trabajo que quiera habilitar y, a
continuación, haga clic en Configurar selección .
Al habilitar Azure Monitor para VM en una única VM o en VMMS con Azure Portal, se le ofrece la opción de
seleccionar un área de trabajo existente o crear una nueva. La solución VMInsights se instalará en este área de
trabajo si aún no lo está. Después, puede usar este área de trabajo para otros agentes.
Las plantillas de Azure Resource Manager para Azure Monitor para VM se suministran en un archivo de
almacenamiento (.zip) que puede descargar desde nuestro repositorio de GitHub. Incluye una plantilla llamada
ConfigureWorkspace que configura un área de trabajo de Log Analytics para Azure Monitor para VM. Esta
plantilla se implementa mediante cualquiera de los métodos estándar, incluidos los comandos de PowerShell y de
la CLI de ejemplo siguientes:
CLI
PowerShell
az deployment group create --name ConfigureWorkspace --resource-group my-resource-group --template-file

CreateWorkspace.json --parameters workspaceResourceId='/subscriptions/00000000-0000-0000-0000-
000000000000/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-
workspace' workspaceLocation='eastus'
Pasos siguientes
Consulte Incorporación de agentes a Azure Monitor para VM para conectar agentes a Azure Monitor para VM.
Consulte Soluciones de supervisión como destino en Azure Monitor (versión preliminar) para limitar la
cantidad de datos que se envían desde una solución al área de trabajo.
Información general sobre la habilitación de Azure
Monitor para VM
En este artículo se proporciona información general sobre las opciones disponibles para habilitar Azure
Monitor para VM con el fin de supervisar el estado y el rendimiento de lo siguiente:
Conjuntos de escalado de máquinas virtuales de Azure
Máquinas virtuales híbridas conectadas con Azure Arc
Máquinas virtuales locales
Máquinas virtuales hospedadas en otro entorno de nube
Para configurar Azure Monitor para VM:
Habilite una única VM de Azure, VMSS de Azure o máquina de Azure Arc; para ello, seleccione Insights
directamente del menú de Azure Portal.
Habilite varias VM de Azure, VMSS de Azure o máquinas de Azure Arc mediante Azure Policy. Este método
asegura que se instalan y configuran correctamente las dependencias necesarias en las máquinas
virtuales y conjuntos de escalado nuevos y existentes. Se informa de las máquinas virtuales y conjuntos
de escalado no compatibles para que pueda decidir si habilitarlas y cómo corregir las incompatibilidades.
Habilite varias VM de Azure, VM de Azure Arc, VMSS de Azure o máquinas de Azure Arc a través de una
suscripción o un grupo de recursos especificado mediante PowerShell.
Habilite Azure Monitor para VM para supervisar las máquinas virtuales o equipos físicos hospedados en
la red corporativa o en otro entorno de nube.
Requisitos previos
Antes de empezar, asegúrese de conocer la información de los apartados siguientes.
NOTE
La siguiente información que se describe en esta sección también se aplica a la solución Service Map.
Log Analytics
Azure Monitor para VM admite un área de trabajo de Log Analytics en las siguientes regiones:
Centro-Oeste de EE. UU.
Oeste de EE. UU.
Oeste de EE. UU. 2
Centro-sur de EE. UU.
Este de EE. UU.
Este de EE. UU. 2
Centro de EE. UU.
Centro-Norte de EE. UU
US Gov Az
US Gov Va
Centro de Canadá
Sur de Reino Unido
Norte de Europa
Oeste de Europa
Este de Asia
Sudeste de Asia
Centro de la India
Japón Oriental
Este de Australia
Sudeste de Australia
NOTE
Puede supervisar máquinas virtuales de Azure en cualquier región. Las máquinas virtuales no se limitan a las regiones
admitidas por el área de trabajo de Log Analytics.
Si no tiene un área de trabajo de Log Analytics, puede crear una usando alguno de estos recursos:
CLI de Azure
PowerShell
Azure Portal
Azure Resource Manager
Conjunto de escalado de máquinas virtuales de Azure
Máquina virtual híbrida conectada con Azure Arc

Azure Monitor para VM admite cualquier sistema operativo que sea compatible con el agente de Log
Analytics y el agente de dependencia. Consulte Información general sobre los agentes de Azure Monitor.
Consulte la siguiente lista de consideraciones sobre la compatibilidad de Linux del agente de dependencia
que admite Azure Monitor para VM:
Se admiten solo versiones de kernel SMP Linux y predeterminados.
Las versiones de kernel no estándar, como Physical Address Extension (PAE) y Xen, no son compatibles con
ninguna distribución de Linux. Por ejemplo, un sistema con la cadena de versión 2.6.16.21-0.8-xen no es
compatible.
No se admiten los kernel personalizados, incluidas las recompilaciones de kernels estándar.
Para distribuciones de Debian que no sean la versión 9.4, no se admite la característica de asignación y la
característica de rendimiento solo está disponible en el menú de Azure Monitor. No está disponible
directamente desde el panel izquierdo de la máquina virtual de Azure.
Se admite el kernel de CentOSPlus.
El kernel de Linux debe revisarse para la vulnerabilidad de Spectre. Consulte al proveedor de distribución
de Linux para más información.
Máquinas de Azure Arc admitidas

Azure Monitor para VM está disponible para los servidores habilitados para Azure Arc en las regiones donde
el servicio de extensión de Arc está disponible. Debe ejecutar la versión 0 9 o superior del agente de Arc.
Agentes de Windows Sí Junto con el agente de Log Analytics

para Windows, los agentes de
Windows requieren Dependency
Agent. Para más información,
consulte el artículo sobre los sistemas
operativos compatibles.
Agentes de Linux Sí Junto con el agente de Log Analytics

para Linux, los agentes de Linux
requieren Dependency Agent. Para
más información, consulte el artículo
sobre los sistemas operativos
compatibles.
Grupo de administración de System No

Center Operations Manager
Agentes
Azure Monitor para VM requiere la instalación de los dos agentes siguientes en cada máquina virtual o
conjunto de escalado de máquinas virtuales que se supervisarán. La instalación de estos agentes y su
conexión al área de trabajo es el único requisito para incorporar el recurso.
Agente de Log Analytics. Recopila eventos y datos de rendimiento de la máquina virtual o del conjunto de
escalado de máquinas virtuales y los entrega al área de trabajo de Log Analytics. Los métodos de
implementación para el agente de Log Analytics en los recursos de Azure usan la extensión de VM para
Windows y Linux.
Dependency Agent. Recopila datos detectados acerca de los procesos que se ejecutan en las dependencias
de las máquinas virtuales y los procesos externos, que usa la característica de asignación de Azure
Monitor para VM. Dependency Agent depende del agente de Log Analytics para entregar los datos a
Azure Monitor. Los métodos de implementación de Dependency Agent en los recursos de Azure usan la
extensión VM para Windows y Linux.
NOTE
El agente de Log Analytics es el mismo agente que se usa para System Center Operations Manager. Azure Monitor
para VM puede supervisar agentes que también están supervisados por Operations Manager si están conectados
directamente, e instala Dependency Agent en ellos. Azure Monitor para VM no puede supervisar los agentes
conectados a Azure Monitor a través de una conexión de grupo de administración.
A continuación se muestran varios métodos para implementar estos agentes.
Azure Portal Instale ambos agentes en una sola máquina virtual, en un

conjunto de escalado de máquinas virtuales o en máquinas
virtuales híbridas conectadas a Azure Arc.
Plantillas de Resource Manager Instale ambos agentes con cualquiera de los métodos
admitidos para implementar una plantilla de Resource
Manager, como la CLI y PowerShell.
Azure Policy Asigne la iniciativa de Azure Policy para instalar

automáticamente los agentes cuando se crea una máquina
virtual o un conjunto de escalado de máquinas virtuales.
Instalación manual Instale los agentes en el sistema operativo invitado en

equipos hospedados fuera de Azure, incluidos los de su
centro de datos u otros entornos en la nube.
Cuando un área de trabajo de Log Analytics está configurada para Azure Monitor para VM, se reenvían dos
módulo de administración a todos los equipos Windows conectados a esa área de trabajo. Los módulos de
administración se denominan Microsoft.IntelligencePacks.ApplicationDependencyMonitor y
Microsoft.IntelligencePacks.VMInsights y se escriben en *%Programfiles%\Microsoft Monitoring
Agent\Agent\Health Service State\Management Packs*.
El origen de datos que utiliza el módulo de administración ApplicationDependencyMonitor es * %Program
files%\Microsoft Monitoring Agent\Agent\Health Service
State\Resources<AutoGeneratedID>\Microsoft.EnterpriseManagement.Advisor.ApplicationDependencyMonit
orDataSource.dll. El origen de datos que utiliza el módulo de administración VMInsights es %Program
files%\Microsoft Monitoring Agent\Agent\Health Service State\Resources<AutoGeneratedID>\
Microsoft.VirtualMachineMonitoringModule.dll.
Datos de diagnóstico y uso

Microsoft recopila automáticamente datos de uso y rendimiento a través del servicio Azure Monitor.
Microsoft usa estos datos para mejorar la calidad, la seguridad y la integridad del servicio.
Para proporcionar funcionalidades de solución de problemas precisas y eficientes, la característica de
asignación incluye datos sobre la configuración del software. Los datos proporcionan información como el
sistema operativo y versión, la dirección IP, el nombre DNS y el nombre de la estación de trabajo. Microsoft
no recopila nombres, direcciones ni otra información de contacto.
Para más información sobre el uso y la recopilación de datos, vea la Declaración de privacidad de Microsoft
Online Services.
NOTE
Para más información sobre cómo ver o eliminar datos personales, consulte Solicitudes de interesados de datos de
Azure para el RGPD. Para más información sobre el Reglamento general de protección de datos, consulte la sección
sobre RGPD del Portal de confianza de servicios.
Pasos siguientes
Para aprender a usar la característica de supervisión Rendimiento, consulte Visualización del rendimiento de
Azure Monitor para VM. Para ver las dependencias de las aplicaciones detectadas, consulte Uso de la
asignación de Azure Monitor para VM (versión preliminar) para conocer los componentes de una aplicación.
Habilitar Azure Monitor para VM para una sola
máquina virtual o un conjunto de escalado de
máquinas virtuales mediante Azure Portal
En este artículo se describe cómo habilitar Azure Monitor para VM para una máquina virtual o un conjunto de
escalado de máquinas virtuales mediante Azure Portal. Este procedimiento se puede usar para:
Requisitos previos
Cree y configure un área de trabajo de Log Analytics. Como alternativa, puede crear un área de trabajo durante
este proceso.
Vea Sistemas operativos admitidos para asegurarse de que el sistema operativo de la máquina virtual o el
conjunto de escalado de máquinas virtuales que va a habilitar son compatibles.

En el Azure Portal, seleccione Máquinas vir tuales , Conjuntos de escalado de máquinas vir tuales o
Máquinas: Azure Arc y seleccione un recurso de la lista. En la sección Super visión del menú, seleccione
Insights y, a continuación, Habilitar . En el ejemplo siguiente, se muestra una máquina virtual de Azure, pero el
menú es similar para el conjunto de escalado de máquinas virtuales o Azure Arc.
Si la máquina virtual aún no está conectada a un área de trabajo de Log Analytics, se le pedirá que seleccione una.
Si anteriormente no ha creado un área de trabajo, puede seleccionar una predeterminada para la ubicación en la
que se implementa la máquina virtual o el conjunto de escalado de máquinas virtuales en la suscripción. Se creará
y configurará el área de trabajo si aún no existe. Si selecciona un área de trabajo existente, se configurará en Azure
Monitor para VM si aún no está configurada.
NOTE
Si selecciona un área de trabajo que no se configuró anteriormente en Azure Monitor para VM, se agregará el módulo de
administración VMInsights a esta área de trabajo. Esto se aplicará a cualquier agente que ya esté conectado al área de
trabajo, independientemente de si está habilitado o no en Azure Monitor para VM. Los datos de rendimiento se recopilarán
de estas máquinas virtuales y se almacenarán en la tabla InsightsMetrics.
Recibirá mensajes de estado a medida que se lleve a cabo la configuración.
NOTE
Si usa un modelo de actualización manual para el conjunto de escalado de máquinas virtuales, actualice las instancias para
completar la configuración. Puede iniciar las actualizaciones desde la página Instancias , en la sección Configuración .
Pasos siguientes
Vea Uso de la característica de asignación de Azure Monitor para VM para ver las dependencias de las
aplicaciones detectadas.
Consulte Ver el rendimiento de las máquinas virtuales de Azure para identificar cuellos de botella, el uso
general y el rendimiento de la máquina virtual.
Habilitar Azure Monitor para VM mediante
PowerShell
En este artículo se describe cómo habilitar Azure Monitor para VM en máquinas virtuales de Azure mediante
PowerShell. Este procedimiento se puede usar para:
Requisitos previos
Cree y configure un área de trabajo de Log Analytics.
Script de PowerShell
Para habilitar Azure Monitor para VM en varias máquinas virtuales o conjuntos de escalado de máquinas
virtuales, use el script de PowerShell Install-VMInsights.ps1, que está disponible en la Galería de Azure
PowerShell. Este script procesa una iteración en:
Cada máquina virtual y conjunto de escalado de máquinas virtuales de su suscripción.
El grupo de recursos con ámbito especificado por ResourceGroup.
Una única VM o conjunto de escalado de máquinas virtuales que se especifica mediante Name.
Para cada máquina virtual o conjunto de escalado de máquinas virtuales, el script comprueba si ya están
instaladas las extensiones de máquina virtual para el agente de Log Analytics y Dependency Agent. Si lo
están, el script vuelve a intentar realizar la instalación. Si no están instaladas, el script las instala.
Compruebe que usa la versión Az 1.0.0 o posterior del módulo de Azure PowerShell con los alias de
compatibilidad Enable-AzureRM habilitados. Ejecute Get-Module -ListAvailable Az para encontrar la versión.
Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta
localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.
Para obtener una lista de los detalles de los argumentos del script y un ejemplo de uso, ejecute Get-Help .
Get-Help .\Install-VMInsights.ps1 -Detailed
SYNOPSIS
This script installs VM extensions for Log Analytics and the Dependency agent as needed for VM
Insights.
SYNTAX
.\Install-VMInsights.ps1 [-WorkspaceId] <String> [-WorkspaceKey] <String> [-SubscriptionId] <String>
[[-ResourceGroup]
<String>] [[-Name] <String>] [[-PolicyAssignmentName] <String>] [-ReInstall] [-
TriggerVmssManualVMUpdate] [-Approve] [-WorkspaceRegion] <String>
[-WhatIf] [-Confirm] [<CommonParameters>]
DESCRIPTION
This script installs or reconfigures the following on VMs and virtual machine scale sets:
This script installs or reconfigures the following on VMs and virtual machine scale sets:
- Log Analytics VM extension configured to supplied Log Analytics workspace
- Dependency agent VM extension
Can be applied to:

- Subscription
- Resource group in a subscription
- Specific VM or virtual machine scale set
- Compliance results of a policy for a VM or VM extension
Script will show you a list of VMs or virtual machine scale sets that will apply to and let you
confirm to continue.
Use -Approve switch to run without prompting, if all required parameters are provided.
If the extensions are already installed, they will not install again.
Use -ReInstall switch if you need to, for example, update the workspace.
Use -WhatIf if you want to see what would happen in terms of installs, what workspace configured to,
and status of the extension.
PARAMETERS
-WorkspaceId <String>
Log Analytics WorkspaceID (GUID) for the data to be sent to
-WorkspaceKey <String>
Log Analytics Workspace primary or secondary key
-SubscriptionId <String>
SubscriptionId for the VMs/VM Scale Sets
If using PolicyAssignmentName parameter, subscription that VMs are in
-ResourceGroup <String>
<Optional> Resource Group to which the VMs or VM Scale Sets belong
-Name <String>
<Optional> To install to a single VM/VM Scale Set
-PolicyAssignmentName <String>
<Optional> Take the input VMs to operate on as the Compliance results from this Assignment
If specified will only take from this source.
-ReInstall [<SwitchParameter>]
<Optional> If VM/VM Scale Set is already configured for a different workspace, set this to
change to the new workspace
-TriggerVmssManualVMUpdate [<SwitchParameter>]
<Optional> Set this flag to trigger update of VM instances in a scale set whose upgrade policy
is set to Manual
-Approve [<SwitchParameter>]
<Optional> Gives the approval for the installation to start with no confirmation prompt for the
listed VMs/VM Scale Sets
-WorkspaceRegion <String>
Region the Log Analytics Workspace is in
Supported values: "East US","eastus","Southeast Asia","southeastasia","West Central
US","westcentralus","West Europe","westeurope"
For Health supported is: "East US","eastus","West Central US","westcentralus"
-WhatIf [<SwitchParameter>]
<Optional> See what would happen in terms of installs.
If extension is already installed will show what workspace is currently configured, and status
of the VM extension
-Confirm [<SwitchParameter>]
<Optional> Confirm every action
<CommonParameters>
This cmdlet supports the common parameters: Verbose, Debug,
This cmdlet supports the common parameters: Verbose, Debug,
ErrorAction, ErrorVariable, WarningAction, WarningVariable,
OutBuffer, PipelineVariable, and OutVariable. For more information, see
about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).
-------------------------- EXAMPLE 1 --------------------------

.\Install-VMInsights.ps1 -WorkspaceRegion eastus -WorkspaceId <WorkspaceId>-WorkspaceKey
<WorkspaceKey> -SubscriptionId <SubscriptionId>
-ResourceGroup <ResourceGroup>
Install for all VMs in a resource group in a subscription
-------------------------- EXAMPLE 2 --------------------------

-ResourceGroup <ResourceGroup> -ReInstall
Specify to reinstall extensions even if already installed, for example, to update to a different
workspace
-------------------------- EXAMPLE 3 --------------------------

-PolicyAssignmentName a4f79f8ce891455198c08736 -ReInstall
Specify to use a PolicyAssignmentName for source and to reinstall (move to a new workspace)
En el ejemplo siguiente se muestra cómo utilizar los comandos de PowerShell en la carpeta para habilitar
Azure Monitor para VM y comprender el resultado esperado:
$WorkspaceId = "<GUID>"
$WorkspaceKey = "<Key>"
$SubscriptionId = "<GUID>"
.\Install-VMInsights.ps1 -WorkspaceId $WorkspaceId -WorkspaceKey $WorkspaceKey -SubscriptionId
$SubscriptionId -WorkspaceRegion eastus
Getting list of VMs or virtual machine scale sets matching criteria specified
VMs or virtual machine scale sets matching criteria:
db-ws-1 VM running
db-ws2012 VM running
This operation will install the Log Analytics and Dependency agent extensions on the previous two VMs or
virtual machine scale sets.
VMs in a non-running state will be skipped.
Extension will not be reinstalled if already installed. Use -ReInstall if desired, for example, to
update workspace.
Confirm
Continue?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
db-ws-1 : Deploying DependencyAgentWindows with name DAExtension

db-ws-1 : Successfully deployed DependencyAgentWindows
db-ws-1 : Deploying MicrosoftMonitoringAgent with name MMAExtension
db-ws-1 : Successfully deployed MicrosoftMonitoringAgent
db-ws2012 : Deploying DependencyAgentWindows with name DAExtension
db-ws2012 : Successfully deployed DependencyAgentWindows
db-ws2012 : Deploying MicrosoftMonitoringAgent with name MMAExtension
db-ws2012 : Successfully deployed MicrosoftMonitoringAgent
Summary:
Already onboarded: (0)
Succeeded: (4)
db-ws-1 : Successfully deployed DependencyAgentWindows
db-ws-1 : Successfully deployed MicrosoftMonitoringAgent
db-ws2012 : Successfully deployed DependencyAgentWindows
db-ws2012 : Successfully deployed MicrosoftMonitoringAgent
Connected to different workspace: (0)
Not running - start VM to configure: (0)
Failed: (0)
Pasos siguientes
Vea Uso de la característica de asignación de Azure Monitor para VM para ver las dependencias de las
aplicaciones detectadas.
Consulte Ver el rendimiento de las máquinas virtuales de Azure para identificar cuellos de botella, el uso
general y el rendimiento de la máquina virtual.
Habilitación de Azure Monitor para VM mediante
plantillas de Resource Manager
En este artículo se describe cómo habilitar Azure Monitor para VM para una máquina virtual o un conjunto de
escalado de máquinas virtuales mediante plantillas de Resource Manager. Este procedimiento se puede usar para:
Requisitos previos

Hemos creado plantillas de Azure Resource Manager de ejemplo para incorporar sus máquinas virtuales y
conjuntos de escalado de máquinas virtuales. Estas plantillas incluyen escenarios que puede usar para habilitar la
supervisión de un recurso existente y para crear un nuevo recurso que tenga la supervisión habilitada.
NOTE
La plantilla debe implementarse en el mismo grupo de recursos que la máquina virtual o el conjunto de escalado de
máquinas virtuales que se van a habilitar.
Las plantillas de Azure Resource Manager se suministran en un archivo de almacenamiento (.zip) que puede
descargar desde nuestro repositorio de GitHub. El contenido del archivo incluye carpetas que representan cada
escenario de implementación con un archivo de plantilla y un archivo de parámetros. Antes de ejecutarlos,
modifique el archivo de parámetros y especifique los valores necesarios.
El archivo de descarga contiene las siguientes plantillas para distintos escenarios:
La plantilla ExistingVmOnboarding habilita Azure Monitor para VM si la máquina virtual ya existe.
La plantilla NewVmOnboarding crea una máquina virtual y habilita Azure Monitor para VM para que la
supervise.
La plantilla ExistingVmssOnboarding habilita Azure Monitor para VM si el conjunto de escalado de máquinas
virtuales ya existe.
La plantilla NewVmssOnboarding crea conjuntos de escalado de máquinas virtuales y habilita Azure Monitor
para VM para que lo supervise.
La plantilla ConfigureWorkspace configura el área de trabajo de Log Analytics para que admita Azure
Monitor para VM habilitando las soluciones y la colección de contadores de rendimiento de los sistemas
operativos Linux y Windows.
NOTE
Si ya había conjuntos de escalado de máquinas virtuales y la directiva de actualización está establecida en Manual, Azure
Monitor para VM no se habilitará para las instancias de manera predeterminada tras ejecutar la plantilla de Azure Resource
Manager ExistingVmssOnboarding . Tendrá que actualizar manualmente las instancias.
Implementación de plantillas
Las plantillas se pueden implementar mediante cualquier método de implementación de plantillas de Resource
Manager, incluidos los ejemplos siguientes con PowerShell y la CLI.
New-AzResourceGroupDeployment -Name OnboardCluster -ResourceGroupName <ResourceGroupName> -TemplateFile

<Template.json> -TemplateParameterFile <Parameters.json>
az group deployment create --resource-group <ResourceGroupName> --template-file <Template.json> --parameters

<Parameters.json>
Pasos siguientes
Ahora que la supervisión está habilitada para las máquinas virtuales, esta información está disponible para
analizarse con Azure Monitor para VM.
Para ver las dependencias de las aplicaciones detectadas, consulte Uso de la asignación de Azure Monitor
para VM (versión preliminar) para conocer los componentes de una aplicación.
Para identificar los cuellos de botella y el uso general con el rendimiento de la máquina virtual, vea Cómo
representar el rendimiento en gráficos con Azure Monitor para VM (versión preliminar).
Habilitación de Azure Monitor para VM mediante
Azure Policy
En este artículo se explica cómo habilitar Azure Monitor para VM para máquinas virtuales de Azure o máquinas
virtuales híbridas conectadas con Azure Arc (versión preliminar) mediante Azure Policy. Azure Policy permite
asignar definiciones de directivas que instalan los agentes necesarios para Azure Monitor para VM en el entorno
de Azure y habilitan automáticamente la supervisión de las máquinas virtuales cuando se crea cada máquina
virtual. Azure Monitor para VM ofrece una característica que permite detectar y corregir VM no compatibles en el
entorno. Use esta característica en lugar de trabajar directamente con Azure Policy.
Si no está familiarizado con Azure Policy, obtenga una breve introducción en Implementación de Azure Monitor a
escala mediante Azure Policy.
NOTE
Para usar Azure Policy con conjuntos de escalado de máquinas virtuales de Azure o para trabajar con Azure Policy
directamente para habilitar las máquinas virtuales de Azure, vea Implementación de Azure Monitor a escala mediante Azure
Policy.
Requisitos previos
Iniciativa de Azure Monitor para VM

Azure Monitor para VM proporciona definiciones de directivas integradas para instalar el agente de Log Analytics
y Dependency Agent en máquinas virtuales de Azure. La iniciativa Habilitar Azure Monitor para VM incluye
cada una de estas definiciones de directiva. Asigne esta iniciativa a un grupo de administración, una suscripción o
un grupo de recursos para instalar automáticamente los agentes en cualquier máquina virtual Windows o Linux
de Azure en ese ámbito.
Acceso a la característica Cobertura de directiva

Para acceder a Cober tura de directiva de Azure Monitor para VM , vaya a Máquinas vir tuales en el menú
Azure Monitor de Azure Portal. Seleccione Otras opciones de incorporación y Habilitar en Habilitar
mediante directiva .
Creación de una asignación
Si aún no tiene una asignación, haga clic en Asignar directiva para crear una.
Se trata de la misma página utilizada para asignar una iniciativa en Azure Policy, con la excepción de que está
codificada con el ámbito seleccionado y la definición de la iniciativa Habilitar Azure Monitor para VM .
Opcionalmente, puede cambiar el Nombre de asignación y agregar una Descripción . Seleccione Exclusiones
si desea proporcionar una exclusión en el ámbito. Por ejemplo, el ámbito puede ser un grupo de administración, y
se puede especificar una suscripción en ese grupo de administración para que se excluya de la asignación.
En la página Parámetros , seleccione un Área de trabajo de Log Analytics que usarán todas las máquinas
virtuales de la asignación. Si desea especificar diferentes áreas de trabajo para distintas máquinas virtuales, debe
crear varias asignaciones, cada una con su propio ámbito.
NOTE
Si el área de trabajo está fuera del ámbito de la asignación, conceda los permisos de colaborador de Log Analytics al
identificador de la entidad de seguridad. de la asignación de la directiva. Si no lo hace, es posible que vea un error de
implementación, como
The client '343de0fe-e724-46b8-b1fb-97090f7054ed' with object id '343de0fe-e724-46b8-b1fb-97090f7054ed'
does not have authorization to perform action 'microsoft.operationalinsights/workspaces/read' over scope
...
.
Haga clic en Revisar y crear para revisar los detalles de la asignación antes de hacer clic en Crear para crearla.
No cree una tarea de corrección en este momento, ya que lo más probable es que necesite varias tareas de
corrección para habilitar las máquinas virtuales existentes. Vea Corrección de los resultados de cumplimiento a
continuación.
Revisión del cumplimiento

Una vez creada una asignación, puede revisar y administrar la cobertura de la iniciativa Habilitar Azure Monitor
para VM en los grupos de administración y las suscripciones. Esto mostrará cuántas máquinas virtuales existen
en cada suscripción o grupo de administración y su estado de cumplimiento.
En la tabla siguiente se proporciona una descripción de la información de esta vista.
F UN C IÓ N DESC RIP C IÓ N
Ámbito Grupo de administración y suscripciones a las que tenga o

haya heredado el acceso con capacidad de explorar en
profundidad la jerarquía de grupos de administración.
Rol Su rol en el ámbito, que debe ser lector, propietario o

colaborador. Estará en blanco si tiene acceso a la suscripción,
pero no al grupo de administración al que esta pertenece. El
rol determina qué datos puede ver y qué acciones puede
realizar en cuanto a la asignación de directivas e iniciativas
(propietario), editarlas o ver el cumplimiento.
TOTAL DE VM Número total de máquinas virtuales en ese ámbito,

independientemente de su estado. Para un grupo de
administración, es una suma total de las VM anidadas bajo las
suscripciones o los grupos de administración secundarios.
Cober tura de la asignación Porcentaje de VM que están cubiertas por la iniciativa.
Estado de la asignación Correcto : todas las VM del ámbito tienen los agentes de Log
Analytics y Dependency Agent implementados en ellas.
Adver tencia : la suscripción no está en un grupo de
administración.
No iniciado : se ha agregado una nueva asignación.
Bloqueo : no tiene suficientes privilegios para el grupo de
administración.
En blanco : no existe ninguna VM o no se ha asignado una
directiva.
Máquinas vir tuales compatibles Número de máquinas virtuales compatibles, que es el número
de máquinas virtuales que tienen el agente de Log Analytics y
Dependency Agent instalados. Estará en blanco si no hay
ninguna asignación, ninguna máquina virtual en el ámbito o
no tiene los permisos adecuados.
Cumplimiento normativo La cifra de cumplimiento general es la suma de los distintos

recursos que son Conforme dividida por la suma de todos los
recursos distintos.
F UN C IÓ N DESC RIP C IÓ N
Estado de cumplimiento Compatible : todas las máquinas virtuales del ámbito tienen
el agente de Log Analytics y Dependency Agent
implementados en ellas, o aún no se ha evaluado ninguna
máquina virtual nueva del ámbito sujeta a la asignación.
No compatible : hay máquinas virtuales que se han evaluado
pero que no están habilitadas y que pueden requerir
corrección.
No iniciado : se ha agregado una nueva asignación.
Bloqueo : no tiene suficientes privilegios para el grupo de
administración.
En blanco : no se ha asignado ninguna directiva.
Al asignar la iniciativa, el ámbito seleccionado en la asignación podría ser el ámbito que se muestra o un
subconjunto del mismo. Por ejemplo, es posible que haya creado una asignación para una suscripción (ámbito de
la directiva) y no un grupo de administración (ámbito de la cobertura). En este caso, el valor de cober tura de la
asignación indica el número de VM del ámbito de la iniciativa dividido entre las VM del ámbito de la cobertura.
En otro caso, es posible que haya excluido algunas VM, grupos de recursos o una suscripción del ámbito de la
directiva. Si el valor está en blanco, indica que la directiva o la iniciativa no existe o no tiene permiso. Se
proporciona información en Estado de asignación .
Corrección de los resultados de cumplimiento

La iniciativa se aplicará a las máquinas virtuales a medida que se creen o modifiquen, pero no se aplicarán a las
máquinas virtuales existentes. Si la asignación no muestra el cumplimiento total, cree tareas de corrección para
evaluar y habilitar las máquinas virtuales existentes y seleccione Ver compatibilidad seleccionando los puntos
suspensivos (...).
En la página Cumplimiento se enumeran las asignaciones que coinciden con el filtro especificado y se indica si
son compatibles. Haga clic en una asignación para ver sus detalles.
En la página Compatibilidad de iniciativas , se enumeran las definiciones de directiva de la iniciativa y si cada
una de ellas es compatible.
Haga clic en una definición de directiva para ver sus detalles. Entre los escenarios en los que se mostrarán las
definiciones de directiva como no compatibles se incluyen los siguientes:
No están implementados los agentes de Log Analytics o Dependency Agent. Cree una tarea de corrección para
la mitigación.
La imagen de la máquina virtual (SO) no está identificada en la definición de la directiva. Los criterios de la
directiva de implementación solo incluyen las máquinas virtuales que se implementan a partir de imágenes de
máquina virtual de Azure conocidas. Consulte en la documentación si el sistema operativo de VM es
compatible.
Las máquinas virtuales no inician sesión en el área de trabajo de Log Analytics especificada. Algunas máquinas
virtuales en el ámbito de la iniciativa están conectadas a un área de trabajo de Log Analytics distinta de la que
se especifica en la asignación de directiva.
Para crear una tarea de corrección para mitigar los problemas de cumplimiento, haga clic en Crear tarea de
corrección .
Haga clic en Corregir para crear la tarea de corrección y, a continuación, en Corregir para iniciarla. Lo más
probable es que necesite crear varias tareas de corrección, una para cada definición de directiva. No se puede
crear una tarea de corrección para una iniciativa.
Una vez completadas las tareas de corrección, las máquinas virtuales deben ser compatibles con los agentes
instalados y habilitados para Azure Monitor para VM.
Pasos siguientes
Para ver las dependencias de las aplicaciones detectadas, consulte Uso de la asignación de Azure Monitor para
VM (versión preliminar) para conocer los componentes de una aplicación.
Habilitar Azure Monitor para VM para una máquina
virtual híbrida
En este artículo se describe cómo habilitar Azure Monitor para VM para una máquina virtual fuera de Azure,
incluidos los entornos locales y otros entornos en la nube.
IMPORTANT
El método recomendado para habilitar máquinas virtuales híbridas primero consiste en habilitar Azure Arc para servidores, a
fin de que las máquinas virtuales se puedan habilitar para Azure Monitor para VM con procesos similares a los de las
máquinas virtuales de Azure. En este artículo se describe cómo incorporar máquinas virtuales híbridas si decide no usar
Azure Arc.
Requisitos previos
Las máquinas virtuales fuera de Azure requieren el mismo agente de Log Analytics y el mismo Dependency Agent
que los que se usan para las máquinas virtuales de Azure. Dado que no se pueden usar las extensiones de
máquina virtual para instalar los agentes, debe instalarlos manualmente en el sistema operativo invitado o
mediante algún otro método.
Vea Conexión de equipos Windows a Azure Monitor o Conexión de equipos Linux a Azure Monitor para más
información sobre la implementación del agente de Log Analytics. En este artículo se proporcionan detalles sobre
Dependency Agent.
Requisitos de firewall
Los requisitos de firewall para el agente de Log Analytics se proporcionan en Introducción al agente de Log
Analytics. La extensión Dependency Agent para Service Map de Azure Monitor para VM no transmite ningún dato
y no requiere ningún cambio en firewalls o puertos. Los datos de Mapa siempre son transmitidos por el agente de
Log Analytics al servicio de Azure Monitor, ya sea directamente o mediante la Puerta de enlace de Operations
Management Suite, si las directivas de seguridad de TI no permiten que los equipos de la red se conecten a
Internet.
Dependency Agent
NOTE
La siguiente información que se describe en esta sección también se aplica a la solución Service Map.
Puede descargar Dependency Agent desde estas ubicaciones:

A RC H IVO SO VERSIÓ N SH A - 256
InstallDependencyAgent- Windows 9.10.5.10940 C27A56D0BE9CF162DF732

Windows.exe 92DFBB2083F5FF749F2B80
FCAD2545BC8B14B64A8D7
InstallDependencyAgent- Linux 9.10.5.10940 71B4E1DA5116E61E03317C

Linux64.bin 49C6702B5069F01A0C9A7
CB860F6ACFAF5C198740E
Instalar Dependency Agent en Windows

Para instalar Dependency Agent manualmente en equipos Windows, puede ejecutar
InstallDependencyAgent-Windows.exe . Si ejecuta este archivo ejecutable sin opciones, se inicia un asistente para
instalación que puede seguir para realizar la instalación del agente de forma interactiva. Necesita privilegios de
administrador en el sistema operativo invitado para instalar o desinstalar el agente.
En la tabla siguiente se destacan los parámetros que admite el programa de instalación para el agente desde la
línea de comandos.
/? Devuelve una lista de las opciones de la línea de comandos.
/S Realiza una instalación silenciosa sin interacción del usuario.
Por ejemplo, para ejecutar el programa de instalación con el parámetro /? , escriba InstallDependencyAgent-
Windows.exe /? .
Los archivos de Dependency Agent para Windows se instalan en C:\Archivos de programa\Microsoft Dependency
Agent de manera predeterminada. Si Dependency Agent no se inicia una vez completada la instalación, compruebe
los registros para obtener información detallada del error. El directorio de registro es %Programfiles%\Microsoft
Dependency Agent\logs.
Script de PowerShell
Use el siguiente script de PowerShell de ejemplo para descargar e instalar el agente:
Invoke-WebRequest "https://aka.ms/dependencyagentwindows" -OutFile InstallDependencyAgent-Windows.exe
.\InstallDependencyAgent-Windows.exe /S
Instalación de Dependency Agent en Linux

Dependency Agent se instala en los servidores Linux desde InstallDependencyAgent-Linux64.bin, un script de shell
con un archivo binario autoextraíble. Puede ejecutar el archivo mediante sh o agregar permisos de ejecución al
propio archivo.
NOTE
Es necesario el acceso raíz para instalar o configurar el agente.
-help Obtenga una lista de las opciones de la línea de comandos.
-S Realice una instalación silenciosa sin preguntas.
--check Compruebe los permisos y el sistema operativo, pero no

instale el agente.
Por ejemplo, para ejecutar el programa de instalación con el parámetro -help , escriba
InstallDependencyAgent-Linux64.bin -help . Para instalar Dependency en Linux como raíz, ejecute el comando
sh InstallDependencyAgent-Linux64.bin .
Si Dependency Agent no se inicia, compruebe los registros para obtener información detallada del error. En los
agentes de Linux, el directorio de registro es /var/opt/microsoft/dependency-agent/log.
Los archivos de Dependency Agent se colocan en los directorios siguientes:
A RC H IVO S LO C AT IO N
Archivos principales /opt/microsoft/dependency-agent
Archivos de registro /var/opt/microsoft/dependency-agent/log
Archivos de configuración /etc/opt/microsoft/dependency-agent/config
Archivos ejecutables de servicio /opt/microsoft/dependency-agent/bin/microsoft-dependency-

agent
/opt/microsoft/dependency-agent/bin/microsoft-dependency-
agent-manager
Archivos binarios de almacenamiento /var/opt/microsoft/dependency-agent/storage
Script de shell
Use el siguiente script de shell de ejemplo para descargar e instalar el agente:
wget --content-disposition https://aka.ms/dependencyagentlinux -O InstallDependencyAgent-Linux64.bin

sudo sh InstallDependencyAgent-Linux64.bin -s
Configuración de estado deseado

Para implementar Dependency Agent mediante Desired State Configuration (DSC), puede usar el módulo
xPSDesiredStateConfiguration con el siguiente código de ejemplo:
configuration VMInsights {
Import-DscResource -ModuleName xPSDesiredStateConfiguration
$DAPackageLocalPath = "C:\InstallDependencyAgent-Windows.exe"
Node localhost
{
# Download and install the Dependency agent
xRemoteFile DAPackage
{
Uri = "https://aka.ms/dependencyagentwindows"
DestinationPath = $DAPackageLocalPath
}
xPackage DA
{
Ensure="Present"
Name = "Dependency Agent"
Path = $DAPackageLocalPath
Arguments = '/S'
ProductId = ""
InstalledCheckRegKey =
"HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\DependencyAgent"
InstalledCheckRegValueName = "DisplayName"
InstalledCheckRegValueData = "Dependency Agent"
DependsOn = "[xRemoteFile]DAPackage"
}
}
}
La VM no aparece en la asignación
Si la instalación del agente de dependencia se completó correctamente, pero no ve el equipo en el mapa, siga estos
pasos para diagnosticar el problema.
1. ¿Se ha instalado Dependency Agent correctamente? Para validarlo, compruebe si el servicio está instalado y
se ejecuta.
Windows : Busque el servicio llamado "Microsoft Dependency Agent".
Linux : Busque el proceso en ejecución "microsoft-dependency-agent".
2. ¿Está en el plan de tarifa gratuito de Log Analytics ? El plan gratuito permite hasta cinco equipos únicos.
Ningún equipo posterior aparecerá en la asignación, incluso si los cinco anteriores ya no envían datos.
3. ¿El equipo envía datos de registro y de rendimiento a los registros de Azure Monitor? Realice la consulta
siguiente para el equipo:
Usage | where Computer == "computer-name" | summarize sum(Quantity), any(QuantityUnit) by DataType
¿Devolvió uno o más resultados? ¿Son los datos recientes? Si es así, el agente de Log Analytics funciona
correctamente y se comunica con el servicio. Si no es así, compruebe el agente en el servidor: Log Analytics
agent for Windows troubleshooting (Cómo solucionar problemas relacionados con el agente de Windows
de Log Analytics) o Cómo solucionar problemas relacionados con el agente de Linux de Log Analytics.
El equipo aparece en la asignación, pero no tiene ningún proceso
Si ve el servidor en el mapa, pero no tienen datos de procesos ni de conexión, eso indica que Dependency Agent
está instalado y se está ejecutando, pero el controlador del kernel no se cargó.
Revise el archivo C:\Program Files\Microsoft Dependency Agent\logs\wrapper.log (Windows) o el archivo
/var/opt/microsoft/dependency-agent/log/service.log (Linux). Las últimas líneas del archivo deben indicar por qué
no se cargó el kernel. Por ejemplo, es posible que el kernel no sea compatible con Linux si actualizó el kernel.
Pasos siguientes
Para ver las dependencias de las aplicaciones detectadas, consulte Uso de la asignación de Azure Monitor
para VM (versión preliminar) para conocer los componentes de una aplicación.
Actualización del agente Dependency Agent en
Azure Monitor para VM
Después de la implementación inicial del agente Dependency Agent en Azure Monitor para VM, se publican
actualizaciones que incluyen correcciones de errores o compatibilidad con nuevas características o funcionalidad.
Este artículo le ayuda a comprender los métodos disponibles y a realizar la actualización manualmente o a través
de la automatización.
Opciones de actualización
El agente Dependency Agent para Windows y Linux puede actualizarse a la versión más reciente de forma manual
o automática según el escenario de implementación y el entorno en que se está ejecutando la máquina. Los
métodos siguientes pueden usarse para actualizar el agente.
EN TO RN O M ÉTO DO DE IN STA L A C IÓ N M ÉTO DO DE A C T UA L IZ A C IÓ N
Azure VM Extensión de VM del agente de El agente se actualiza automáticamente

Dependency Agent para Windows y de forma predeterminada a menos que
Linux. configure la plantilla de Azure Resource
Manager para no realizar la
actualización; para ello, debe establecer
la propiedad autoUpgradeMinorVersion
a false . La actualización de una versión
secundaria en la que la actualización
automática está deshabilitada y la
actualización de una versión principal
siguen el mismo método: desinstalar y
volver a instalar la extensión.
Imágenes personalizadas de VM de Instalación manual del agente La actualización de las VM a la versión

Azure Dependency Agent para Windows o más reciente del agente debe realizarse
Linux desde la línea de comandos que ejecuta
VM ajenas a Azure Instalación manual del agente La actualización de las VM a la versión

Dependency Agent para Windows o más reciente del agente debe realizarse
Linux desde la línea de comandos que ejecuta
Actualización del agente de Windows

Para actualizar el agente en una VM de Windows a la última versión que no se instaló con la extensión de VM de
Dependency Agent, puede realizar el proceso desde el símbolo del sistema, el script u otra solución de
automatización, o mediante el Asistente para la instalación InstallDependencyAgent-Windows.exe.
Puede descargar la versión más reciente del agente de Windows aquí.
Uso del Asistente para la instalación
2. Ejecute InstallDependencyAgent-Windows.exe para iniciar el Asistente para la instalación.
3. Siga las instrucciones del Asistente para la instalación de Dependency Agent para desinstalar la
versión anterior de Dependency Agent y, a continuación, instale la versión más reciente.
Desde la línea de comandos
2. Ejecute el siguiente comando:
InstallDependencyAgent-Windows.exe /S /RebootMode=manual
El parámetro /RebootMode=manual impide que la actualización reinicie automáticamente el equipo si algunos

procesos usan archivos de la versión anterior y tienen un bloqueo.
3. Para confirmar que la actualización se realizó correctamente, consulte install.log para obtener
información detallada sobre la instalación. El directorio de registro es %Programfiles%\Microsoft
Dependency Agent\logs.
Actualización del agente de Linux

La actualización desde versiones anteriores del agente Dependency Agent en Linux se admite y se realiza siguiendo
el mismo comando que una nueva instalación.
Puede descargar la versión más reciente del agente de Linux aquí.
2. Ejecute el siguiente comando como raíz sh InstallDependencyAgent-Linux64.bin -s .
Si Dependency Agent no se inicia, compruebe los registros para obtener información detallada del error. En los
agentes de Linux, el directorio de registro es /var/opt/microsoft/dependency-agent/log.
Pasos siguientes
Si desea detener la supervisión de las máquinas virtuales durante un período de tiempo o quitar Azure Monitor
para VM por completo, consulte Deshabilitación de la supervisión de las máquinas virtuales en Azure Monitor para
VM.
Uso de la característica de asignación de Azure
Monitor para VM para conocer los componentes
de una aplicación
En Azure Monitor para VM, puede ver los componentes de la aplicación detectados en las máquinas virtuales
(VM) de Windows y Linux que se ejecutan en Azure o en su entorno. Puede observar las VM de dos maneras.
Ver una asignación directamente desde una VM o ver un asignación desde Azure Monitor para ver los
componentes de los grupos de VM. En este artículo le ayudamos a comprender estos dos métodos de
visualización y a usar la característica de asignación.
Para obtener más información sobre cómo configurar Azure Monitor para máquinas virtuales, consulte el
artículo Enable Azure Monitor for VMs (Habilitar Azure Monitor para máquinas virtuales).

Introducción a la experiencia de asignación

Antes de profundizar en la experiencia de asignación, debe entender cómo se presenta y se visualiza la
información. Sin importar si selecciona la característica de asignación directamente desde una máquina
virtual o desde Azure Monitor, se presentará una experiencia coherente. La única diferencia es que, desde
Azure Monitor, una sola asignación muestra todos los miembros de un clúster o aplicación de varios niveles.
La característica de asignación visualiza las dependencias de VM al detectar los procesos en ejecución que
tienen:
Conexiones de red activas entre servidores.
Latencia de conexión entrante y saliente.
Puertos en cualquier arquitectura con conexión TCP a través de un intervalo de tiempo especificado.
Al expandir una VM se muestran los detalles del proceso y se muestran solo los procesos que se comunican
con la máquina virtual. El grupo de clientes muestra el número de clientes front-end que se conectan a la VM.
Los grupos del puerto de servidor muestran el número de servidores back-end a los que se conecta la VM.
Expanda un grupo de puertos de servidor para ver una lista detallada de los servidores que se conectan a
través de ese puerto.
Cuando se selecciona la VM, el panel Propiedades de la derecha muestra las propiedades de la VM. Las
propiedades incluyen información del sistema que proporciona el sistema operativo, propiedades de la VM de
Azure y un gráfico de anillos que resume las conexiones detectadas.
En el lado derecho del panel, seleccione Eventos registro para mostrar una lista de los datos que la VM ha
enviado a Azure Monitor. Estos datos están disponibles para su consulta. Seleccione cualquier tipo de registro
para abrir la página Registros , donde verá los resultados para ese tipo de registro. También verá una consulta
preconfigurada que se filtra en la VM.
Cierre la página Registros y vuelva al panel Propiedades . Una vez allí, seleccione Aler tas para ver las
alertas de los criterios de estado de la VM. La característica de asignación se integra con Alertas de Azure para
mostrar las alertas del servidor seleccionado en el intervalo de tiempo seleccionado. El servidor muestra un
icono para las alertas actuales y el panel Aler tas del equipo enumera las alertas.
Para hacer que la característica de asignación muestre las alertas pertinentes, cree una regla de alerta que se
aplique a un equipo determinado:
Incluya una cláusula para agrupar alertas por equipo (por ejemplo, by Computer inter val 1 minute ).
Basar la alerta en una métrica.
Para obtener más información sobre Alertas de Azure y crear reglas de alertas, consulte el artículo Alertas
unificadas en Azure Monitor.
En la esquina superior derecha, la opción Leyenda describe los símbolos y roles en la asignación. Para
obtener una visión más detallada en el mapa y moverlo, use los controles de zoom de la esquina inferior
derecha. Puede establecer el nivel de zoom y ajustar el mapa al tamaño de la página.
Métricas de conexión
En el panel Conexiones se muestra la métrica estándar para la conexión que haya seleccionado de la
máquina virtual a través del puerto TCP. Las métricas incluyen el tiempo de respuesta, las solicitudes por
minuto, el rendimiento del tráfico y los vínculos.
Conexiones con errores
El mapa muestra las conexiones erróneas para procesos y equipos. Una línea discontinua roja indica que un
sistema cliente no puede conectarse con un proceso o puerto. Para sistemas que usan Dependency Agent, el
agente informa de los intentos de conexión erróneos. La característica de asignación supervisa un proceso
mediante la observación de los sockets TCP que no pueden establecer una conexión. Este error puede deberse
a un firewall, a una configuración incorrecta en el cliente o servidor o a un servicio remoto que no está
disponible.
La comprensión de las conexiones con errores puede ayudar a solucionar problemas, validar la migración,
analizar la seguridad y comprender la arquitectura general del servicio. Las conexiones con errores a veces
son inofensivas, pero a menudo indican un problema. Las conexiones pueden producir un error, por ejemplo,
cuando un entorno de conmutación por error de repente se convierte en inalcanzable o dos capas de
aplicaciones no pueden comunicarse entre sí después de una migración en la nube.
Grupos de clientes
En la asignación, los grupos de clientes representan a los equipos clientes que tienen conexiones con el
equipo asignado. Un único grupo de clientes representa a los clientes de un proceso o equipo individual.
Para ver las direcciones IP y los clientes supervisados de los sistemas en un grupo de clientes, seleccione el
grupo. El contenido del grupo se muestra a continuación.
Si el grupo incluye a los clientes supervisados y sin supervisión, puede seleccionar la sección correspondiente
del gráfico de anillos del grupo para filtrar a los clientes.
Grupos del puerto de servidor
Los grupos del puerto de servidor representan los puertos en servidores que tienen conexiones entrantes
desde el equipo asignado. El grupo contiene el puerto del servidor y un recuento del número de servidores
con conexiones a ese puerto. Seleccione el grupo para ver los servidores y las conexiones individuales.
Si el grupo incluye a los servidores supervisados y sin supervisión, puede seleccionar la sección
correspondiente del gráfico de anillos del grupo para filtrar a los servidores.
Ver un mapa de una VM

Para acceder a Azure Monitor para VM directamente desde una VM:
1. En Azure Portal, seleccione Vir tual Machines .
2. En la lista, elija una VM. En la sección Super visión , seleccione Insights .
3. Seleccione la pestaña Asignación .
La asignación muestra las dependencias de la VM mediante la detección de procesos y grupos de procesos
que se están ejecutando en conexiones de red activas durante un determinado intervalo de tiempo.
De forma predeterminada, la asignación muestra los últimos 30 minutos. Si quiere ver el aspecto de las
dependencias en el pasado, puede consultar los intervalos de tiempo históricos de hasta hace una hora. Para
ejecutar la consulta, use el selector TimeRange en la esquina superior izquierda. Puede ejecutar una consulta,
por ejemplo, durante un incidente o para ver el estado antes de un cambio.
Visualización de una asignación desde un conjunto de escalado de
máquinas virtuales
Para obtener acceso a Azure Monitor para VM directamente desde un conjunto de escalado de máquinas
virtuales:
1. En Azure Portal, seleccione Conjuntos de escalado de máquinas vir tuales .
2. En la lista, elija una VM. Luego, en la sección Super visión , seleccione Insights .
La asignación muestra todas las instancias del conjunto de escalado como un nodo de grupo junto con las
dependencias del grupo. El nodo expandido enumera las instancias del conjunto de escalado. Puede
desplazarse a través de estas instancias (10 a la vez).
Para cargar un asignación para una determinada instancia, seleccione primero esa instancia en la asignación.
A continuación, seleccione el botón puntos suspensivos (…) a la derecha y elija Cargar mapa del
ser vidor . En la asignación que aparece, puede ver los procesos y grupos de procesos con conexiones de red
activas durante un intervalo de tiempo especificado.
ejecutar la consulta, use el selector TimeRange . Puede ejecutar una consulta, por ejemplo, durante un
incidente o para ver el estado antes de un cambio.
NOTE
También puede acceder a una asignación de una instancia específica desde la vista Instancias de su conjunto de
escalado de máquinas virtuales. En la sección Configuración , vaya a Instancias > Insights .
Visualización de una asignación desde Azure Monitor

Desde Azure Monitor, la característica de asignación proporciona una visión global de las VM y sus
dependencias. Para obtener acceso a la característica de asignación en Azure Monitor:
2. En la sección Insights , elija Máquinas vir tuales .
Elija un área de trabajo con el selector Área de trabajo en la parte superior de la página. Si tiene más de un
área de trabajo de Log Analytics, elija el área de trabajo que está habilitado con la solución y que tiene VM que
dependen de él.
El selector de grupos devuelve las suscripciones, los grupos de recursos, los grupos de equipos y los
conjuntos de escalado de máquinas virtuales de los equipos relacionados con el área de trabajo seleccionada.
La selección solo se aplica a la característica de asignación y no se aplica a las secciones de rendimiento o
estado.
ejecutar la consulta, use el selector TimeRange . Puede ejecutar una consulta, por ejemplo, durante un
incidente o para ver el estado antes de un cambio.
Pasos siguientes
Para identificar los cuellos de botella, comprobar el rendimiento y comprender el uso general de las VM,
consulte View performance status for Azure Monitor for VMs (Ver el estado del rendimiento de Azure Monitor
para VM).
Cómo representar el rendimiento en gráficos con
Azure Monitor para VM
Azure Monitor para VM incluye un conjunto de gráficos de rendimiento que tienen como destino varios
indicadores clave de rendimiento (KPI) para ayudarle a determinar el rendimiento de una máquina virtual. Los
gráficos muestran el uso de los recursos durante un período de tiempo para que pueda identificar cuellos de
botella, anomalías, o cambiar a una perspectiva en la que se muestre cada máquina a fin de ver el uso de los
recursos en función de la métrica seleccionada. Aunque hay varios elementos a tener en cuenta cuando se
trata del rendimiento, Azure Monitor para VM supervisa los indicadores de rendimiento clave del sistema
operativo relacionados con la utilización del procesador, la memoria, el adaptador de red y los discos. El
rendimiento complementa la característica de supervisión de mantenimiento y ayuda a exponer los problemas
que indican un posible error en el componente del sistema. Además, es compatible con la optimización y los
ajustes para lograr la eficiencia, así como con el planeamiento de capacidad.
Limitaciones
A continuación, se indican las limitaciones en la recopilación del rendimiento con Azure Monitor para VM.
No hay memoria disponible para las máquinas virtuales que ejecutan Red Hat Linux (RHEL) 6. Esta
métrica se calcula a partir de MemAvailable , que se introdujo en la versión del kernel 3.14.
Las métricas solo están disponibles para discos de datos de máquinas virtuales Linux que usan la familia
del sistema de archivos EXT (EXT2, EXT3, EXT4).
Perspectiva de varias VM de Azure Monitor

En Azure Monitor, la característica de rendimiento proporciona una vista de todas las máquinas virtuales
supervisadas implementadas en grupos de trabajo de sus suscripciones o su entorno. Para obtener acceso
desde Azure Monitor, siga estos pasos.
2. Elija Máquinas vir tuales en la sección Soluciones .
3. Seleccione la pestaña Rendimiento .
En la pestaña Top N Char ts (Gráficos de N principales), si tiene más de un área de trabajo de Log Analytics,
elija la que esté habilitada con la solución en el selector Área de trabajo de la parte superior de la página. El
selector de grupos devolverá las suscripciones, los grupos de recursos, los grupos de equipos y los conjuntos
de escalado de máquinas virtuales de los equipos relacionados con el área de trabajo seleccionada que puede
usar para filtrar aún más los resultados que aparecen en las tablas de esta y otras páginas. Su selección solo se
aplica a la característica de rendimiento y no se aplica a las secciones de salud o mapa.
De forma predeterminada, los gráficos muestran las últimas 24 horas. Mediante el selector Inter valo de
tiempo , puede consultar los intervalos de tiempo históricos de hasta 30 días para mostrar cómo como era el
rendimiento en el pasado.
Los cinco gráficos de uso de la capacidad que se muestran en la página son:
CPU Utilization % (Porcentaje de uso de la CPU): muestra las primeras cinco máquinas con el mayor uso
medio del procesador.
Memoria disponible: muestra las primeras cinco máquinas con la menor cantidad media de memoria
disponible.
Logical Disk Space Used % (Porcentaje de espacio usado del disco lógico): muestra las cinco primeras
máquinas con el mayor porcentaje medio de espacio en disco que se usa en todos los volúmenes del disco.
Bytes Sent Rate (Tasa de bytes enviados): muestra las cinco primeras máquinas con el mayor número
medio de bytes enviados.
Bytes Receive Rate (Tasa de bytes recibidos): muestra las cinco primeras máquinas con el mayor número
medio de bytes recibidos.
Al hacer clic en el icono de anclaje en la esquina superior derecha de uno de los cinco gráficos, se anclará el
gráfico seleccionado en el último panel de Azure que haya visto. En el panel, puede cambiar el tamaño y la
posición del gráfico. Al seleccionar el gráfico desde el panel, se le redirigirá a Azure Monitor para VM y se
cargará el ámbito y la vista correctos.
Al hacer clic en el icono situado a la izquierda del icono de anclaje en cualquiera de los cinco gráficos, se abre
la vista Lista de N principales . Aquí puede ver el uso de los recursos para esa métrica de rendimiento por
cada VM en una vista de lista y la máquina con mayor tendencia.
Al hacer clic en la máquina virtual, el panel Propiedades se expande hacia la derecha para mostrar las
propiedades del elemento seleccionado, como la información del sistema notificada por el sistema operativo,
las propiedades de la VM de Azure, etc. Al hacer clic en una de las opciones de la sección Vínculos rápidos ,
se le redirigirá a esa característica directamente desde la VM seleccionada.
Cambie a la pestaña Aggregated Char ts (Gráficos agregados) para ver las métricas de rendimiento filtradas
por las medidas de los percentiles y las medias.
Se proporcionan los siguientes gráficos de uso de la capacidad:

CPU Utilization % (Porcentaje de uso de la CPU): el valor predeterminado muestra la media y el percentil 95
superior.
Memoria disponible: el valor predeterminado muestra la media y los percentiles 5 y 10 superiores.
Logical Disk Space Used % (Porcentaje de espacio usado del disco lógico): el valor predeterminado muestra
la media y el percentil 95.
Bytes Sent Rate (Tasa de bytes enviados): el valor predeterminado muestra la media de bytes enviados.
Bytes Sent Rate (Tasa de bytes recibidos): el valor predeterminado muestra la media de bytes recibidos.
También puede cambiar la granularidad de los gráficos en el intervalo de tiempo. Para ello, seleccione Avg
(Promedio), Min (Mínimo), Max (Máximo), 50th (50), 90th (90) y 95th (95) en el selector de percentiles.
Para ver el uso de recursos por máquina virtual individual en una vista de lista y ver qué máquina tiene
tendencia a una mayor utilización, seleccione la pestaña Top N List (Lista de N principales). En la página Top
N lista (Lista de N principales), se muestran las 20 máquinas principales ordenadas por el mayor uso según el
percentil 95 para la métrica CPU Utilization % (Porcentaje de uso de la CPU). Para ver más máquinas, seleccione
Cargar más . De este modo, los resultados se ampliarán y se mostrarán las 500 máquinas principales.
NOTE
La lista no puede mostrar más de 500 máquinas a la vez.
Para filtrar los resultados en una máquina virtual específica de la lista, escriba el nombre de su equipo en el
cuadro de texto Buscar por nombre .
Si prefiere ver el uso desde otra métrica de rendimiento, en la lista desplegable Métrica , seleccione Memoria
disponible , Logical Disk Space Used % (Logical Disk Space Used %), Network Received Byte/s (Bytes
recibidos por la red) o Network Sent Byte/s (Bytes enviados por la red) y la lista se actualizará para mostrar
el uso con el ámbito de esa métrica.
Al seleccionar una máquina virtual de la lista, se abre el panel Propiedades del lado derecho de la página y,
desde aquí, puede seleccionar Performance detail (Detalles de rendimiento). Se abrirá la página Vir tual
Machine Detail (Detalles de la máquina virtual) con el ámbito en esa máquina virtual, similar a la experiencia
de acceso al rendimiento de las conclusiones de la VM directamente desde la VM de Azure.
Ver el rendimiento directamente desde una VM de Azure

Para obtener acceso directamente desde una máquina virtual, realice los siguientes pasos.
2. En la lista, elija una máquina virtual y, en la sección Super visión , elija Conclusiones .
3. Seleccione la pestaña Rendimiento .
Esta página no solo incluye los gráficos de uso de rendimiento, sino también una tabla para cada disco lógico
detectado, su capacidad, la utilización y la media total de cada medida.
Se proporcionan los siguientes gráficos de uso de la capacidad:
CPU Utilization % (Porcentaje de uso de la CPU): el valor predeterminado muestra la media y el percentil 95
superior.
Memoria disponible: el valor predeterminado muestra la media y los percentiles 5 y 10 superiores.
Logical Disk Space Used % (Porcentaje de espacio usado del disco lógico): el valor predeterminado muestra
la media y el percentil 95.
Logical Disk IOPS (IOPS del disco lógico): el valor predeterminado muestra la media y el percentil 95.
Logical Disk MB/s (MB/s del disco lógico): el valor predeterminado muestra la media y el percentil 95.
Max Logical Disk Used % (Porcentaje de uso máximo del disco lógico): el valor predeterminado muestra la
media y el percentil 95.
Bytes Sent Rate (Tasa de bytes enviados): el valor predeterminado muestra la media de bytes enviados.
Bytes Sent Rate (Tasa de bytes recibidos): el valor predeterminado muestra la media de bytes recibidos.
posición del gráfico. Al seleccionar el gráfico desde el panel, se le redirige a Azure Monitor para VM y se carga
la vista de detalle de rendimiento de la máquina virtual.
Visualización del rendimiento directamente desde un conjunto de

escalado de máquinas virtuales de Azure
Para acceder directamente desde un conjunto de escalado de máquinas virtuales de Azure, realice los
siguientes pasos.
1. En Azure Portal, seleccione Conjuntos de escalado de máquinas vir tuales .
2. En la lista, elija una máquina virtual y, en la sección Super visión , elija Conclusiones para ver la pestaña
Rendimiento .
Esta página carga la vista de rendimiento de Azure Monitor, limitándose al conjunto de escalado seleccionado.
Esto le permite ver las N instancias principales del conjunto de escalado en todo el conjunto de métricas
supervisadas, ver el rendimiento agregado en el conjunto de escalado y ver las tendencias de las métricas
seleccionadas de las instancias individuales del conjunto de escalado. Al seleccionar una instancia de la vista de
lista, puede cargar su asignación o ir a una vista de rendimiento detallada para esa instancia.
posición del gráfico. Al seleccionar el gráfico desde el panel, se le redirige a Azure Monitor para VM y se carga
la vista de detalle de rendimiento de la máquina virtual.
NOTE
También puede acceder a una vista de rendimiento detallada de una instancia específica desde la vista Instancias de su
conjunto de escalado. Vaya a Instancias en la sección Configuración y, a continuación, elija Conclusiones .
Pasos siguientes
Aprenda a usar los libros que se incluyen con Azure Monitor para VM para analizar más a fondo las
métricas de rendimiento y de red.
Para más información sobre las dependencias de las aplicaciones detectadas, consulte Uso de la
asignación de Azure Monitor para VM.
Cómo consultar registros de Azure Monitor para VM
Azure Monitor para VM recopila métricas de rendimiento y conexión, datos de inventario de proceso y equipo, e
información sobre el estado, y reenvía estos datos al área de trabajo de Log Analytics en Azure Monitor. Estos
datos están disponibles para consulta en Azure Monitor. Estos datos se pueden aplicar a escenarios que incluyen
la planeación de la migración, el análisis de la capacidad, la detección y la solución de problemas de rendimiento a
petición.
Registros de asignación
Se genera un registro por hora para cada equipo y proceso únicos, además de los registros generados cuando un
proceso o equipo se inicia o se integra en la característica de asignación de Azure Monitor para VM. Estos
registros tienen las propiedades de las tablas siguientes. Los campos y valores de los eventos
ServiceMapComputer_CL se asignan a los campos del recurso Equipo en la API ServiceMap de Azure Resource
Manager. Los campos y valores de los eventos ServiceMapProcess_CL se asignan a los campos del recurso
Proceso en la API ServiceMap de Azure Resource Manager. El campo ResourceName_s coincide con el campo de
nombre del recurso correspondiente de Resource Manager.
Hay propiedades generadas internamente que puede usar para identificar los equipos y procesos únicos:
Equipo: Use ResourceId o ResourceName_s para identificar de forma exclusiva un equipo dentro de un área de
Proceso: Use ResourceId para identificar de forma exclusiva un proceso dentro de un área de trabajo de Log
Analytics. ResourceName_s es único dentro del contexto de la máquina en la que se está ejecutando el proceso
(MachineResourceName_s)
Puesto que pueden existir varios registros para un proceso y equipo especificados en un intervalo de tiempo
concreto, las consultas pueden devolver más de un registro para el mismo proceso o equipo. Para incluir solo el
registro más reciente, agregue | summarize arg_max(TimeGenerated, *) by ResourceId a la consulta.
Conexiones y puertos
La característica de métricas de conexión presenta dos nuevas tablas en los registros de Azure Monitor:
VMConnection y VMBoundPort. Estas tablas proporcionan información acerca de las conexiones para una
máquina (entrantes y salientes), así como los puertos del servidor que están abiertos o activos en estas. Las
métricas de conexión también se exponen a través de API que proporcionan los medios para obtener una métrica
específica durante un período de tiempo. Las conexiones TCP resultantes de aceptar en un socket de escucha son
de entrada, mientras que las creadas al conectarse a un puerto y una IP concretos son de salida. La dirección de
una conexión se representa mediante la propiedad Direction, que se puede definir como inbound u outbound .
Los registros de estas tablas se generan a partir de los datos que notifica Dependency Agent. Cada registro
representa una observación en un intervalo de tiempo de un minuto. La propiedad TimeGenerated indica el inicio
del intervalo de tiempo. Cada registro contiene información para identificar la entidad correspondiente; es decir,
conexión o puerto, así como las métricas asociadas con esa entidad. Actualmente, solo se notifica la actividad de
red que tiene lugar mediante TCP a través de IPv4.
Campos y convenciones comunes
Los campos y las convenciones siguientes se aplican a VMConnection y VMBoundPort:
Equipo: nombre de dominio completo de la máquina que genera el informe.
AgentId: identificador único de una máquina con el agente de Log Analytics.
Máquina: nombre del recurso de Azure Resource Manager para la máquina expuesta por ServiceMap. Tiene el
formato m-{GUID} , donde GUID coincide con el GUID de AgentId.
Proceso: nombre del recurso de Azure Resource Manager para el proceso expuesto por ServiceMap. Tiene el
formato p-{cadena hexadecimal} . El proceso es único dentro de un ámbito de la máquina y, para generar un
identificador de proceso único entre máquinas, combina los valores de los campos Máquina y Proceso.
ProcessName: nombre del archivo ejecutable del proceso de informes.
Todas las direcciones IP son cadenas en formato canónico IPv4, como 13.107.3.160.
Para administrar el costo y la complejidad, los registros de conexión no representan conexiones de red físicas
individuales. Varias conexiones de red físicas se agrupan en una conexión lógica, que, a continuación, se refleja en
la tabla correspondiente. Lo que significa que los registros de la tabla VMConnection representan una agrupación
lógica, y no las conexiones físicas individuales que se observan. Las conexiones de red físicas que comparten el
mismo valor para los siguientes atributos durante un intervalo determinado de un minuto se agregan en un
registro lógico único en VMConnection.
Dirección Dirección de la conexión; el valor es inbound u outbound
Máquina FQDN del equipo
Proceso Identidad de proceso o grupos de procesos; iniciar/aceptar la

conexión
SourceIp Dirección IP de origen
DestinationIp Dirección IP de destino.
DestinationPort Número de puerto de destino
Protocolo Protocolo utilizado para la conexión. Los valores son tcp.
Para tener en cuenta el impacto de la agrupación, se proporciona información sobre el número de conexiones
físicas agrupadas en las siguientes propiedades del registro:
LinksEstablished Número de conexiones de red físicas que se han establecido

durante el período de tiempo de generación de informes
LinksTerminated Número de conexiones de red físicas que han finalizado

durante el período de tiempo de generación de informes
LinksFailed Número de conexiones de red físicas que han generado

errores durante el período de tiempo de generación de
informes Actualmente, esta información está disponible solo
para las conexiones salientes.
LinksLive Número de conexiones de red físicas que estaban abiertas al

final del período de tiempo de generación de informes
Métricas
Además de las métricas de recuento de conexión, también se incluye información sobre el volumen de datos
enviado y recibido en una conexión lógica o puerto de red concreto en las siguientes propiedades del registro:
BytesSent Número total de bytes enviados durante el período de

tiempo de generación de informes
BytesReceived Número total de bytes recibidos durante el período de

tiempo de generación de informes
Respuestas Número de respuestas observado durante el período de

tiempo de generación de informes.
ResponseTimeMax Mayor tiempo de respuesta (milisegundos) observado

durante el período de tiempo de generación de informes. Si
no hay ningún valor, la propiedad está en blanco.
ResponseTimeMin Menor tiempo de respuesta (milisegundos) observado

durante el período de tiempo de generación de informes. Si
no hay ningún valor, la propiedad está en blanco.
ResponseTimeMin Suma de todos los tiempos de respuesta (milisegundos)

observados durante el período de tiempo de generación de
informes. Si no hay ningún valor, la propiedad está en blanco.
El tercer tipo de datos que se va a notificar es el tiempo de respuesta: ¿cuánto tiempo pasa el autor de la llamada
esperando que una solicitud enviada a través de una conexión se procese y reciba respuesta del punto de
conexión remoto? El tiempo de respuesta notificado es una estimación del tiempo de respuesta real del protocolo
de aplicación subyacente. Se calcula utilizando la heurística basada en la observación del flujo de datos entre el
origen y destino de una conexión de red física. Conceptualmente, es la diferencia entre el momento en que el
último byte de una solicitud sale del remitente y el momento en que llega el último byte de la respuesta. Estas dos
marcas de tiempo se utilizan para delinear los eventos de solicitud y respuesta de una conexión física concreta. La
diferencia entre ellas representa el tiempo de respuesta de una única solicitud.
En esta primera versión de esta característica, el algoritmo es una aproximación que puede funcionar con cierto
grado de éxito según el protocolo de aplicación real usado para una conexión de red concreta. Por ejemplo, el
enfoque actual funciona bien para los protocolos basados en solicitud-respuesta, como HTTP(S), pero no funciona
con protocolos unidireccionales ni basados en la cola de mensajes.
A continuación se incluyen puntos importantes que debe tener en cuenta:
1. Si un proceso acepta conexiones en la misma dirección IP, pero a través de varias interfaces de red, se
notificará un registro independiente para cada interfaz.
2. Los registros con IP comodín no contendrán ninguna actividad. Se incluyen para representar el hecho de que
un puerto del equipo está abierto al tráfico de entrada.
3. Para reducir el nivel de detalle y el volumen de datos, los registros con dirección IP de carácter comodín se
omitirán cuando haya un registro coincidente (para el mismo proceso, puerto y protocolo) con una dirección
IP específica. Cuando un registro de dirección IP comodín se omite, la propiedad del registro IsWildcardBind
con la dirección IP específica se definirá como "True" para indicar que el puerto se expone a través de cada
interfaz de la máquina de generación de informes.
4. Los puertos que están enlazados solo en una interfaz específica tienen IsWildcardBind definido como False.
Nomenclatura y clasificación
Para mayor comodidad, la dirección IP del extremo remoto de una conexión se incluye en la propiedad RemoteIp.
Para las conexiones entrantes, RemoteIp coincide con SourceIp, mientras que, para las conexiones salientes,
coincide con DestinationIp. La propiedad RemoteDnsCanonicalNames representa los nombres canónicos DNS
que notifica la máquina para RemoteIp. Las propiedades RemoteDnsQuestions y RemoteClassification están
reservadas para uso futuro.
Geolocalización
VMConnection también incluye información de ubicación geográfica para el extremo remoto de cada registro de
conexión en las siguientes propiedades del registro:
RemoteCountry Nombre del país o región que hospeda la dirección IP de

RemoteIp. Por ejemplo: Estados Unidos
RemoteLatitude Latitud de geolocalización. Por ejemplo, 47.68
RemoteLongitude Longitud de geolocalización. Por ejemplo, -122.12
Direcciones IP malintencionadas
Todas las propiedades de RemoteIp de la tabla VMConnection se comparan con un conjunto de direcciones IP con
actividad malintencionada conocida. Si el valor de RemoteIp se identifica como malintencionado, las propiedades
siguientes se completarán (si la IP no se considera malintencionada, están vacías) en las siguientes propiedades
del registro:
MaliciousIP Dirección RemoteIp
IndicatorThreadType El indicador de amenazas detectado es uno de los siguientes

valores: Botnet, C2, CryptoMining, Darknet, DDos ,
MaliciousUrl, Malware, Phishing, Proxy, PUA, Watchlist.
Descripción Descripción de la amenaza observada.
TLPLevel Nivel de protocolo de semáforo (TLP) es uno de los valores

definidos: blanco, verde, ámbar, rojo.
Confianza Los valores válidos se encuentran entre 0 y 100.
severity Los valores se encuentran entre 0 y 5, donde 5 es el más

grave y 0 no es grave en absoluto. El valor predeterminado es
3.
FirstReportedDateTime La primera vez que el proveedor informó sobre el indicador.
LastReportedDateTime La última vez que Interflow ha visto el indicador.
IsActive Indica que los indicadores se desactivan con el valor True o

False.
ReportReferenceLink Vincula a informes relacionados con un objeto observable

especificado.
AdditionalInformation Proporciona información adicional, si procede, sobre la

amenaza observada.
Puertos
En una máquina, los puertos que aceptan activamente el tráfico entrante o que pueden aceptar tráfico
potencialmente, pero que están inactivas durante el período de tiempo de informes, se escriben en la tabla
VMBoundPort.
Todos los registros de VMBoundPort se identifican mediante los campos siguientes:
Proceso Identidad del proceso (o grupos de procesos) a la que está

asociado el puerto.
Ip Dirección IP del puerto (puede ser la dirección IP comodín,

0.0.0.0).
Port Número del puerto.
Protocolo Protocolo. Ejemplo, tcp o udp (solo se admite tcp

actualmente).
Identidad de la que se deriva un puerto de los cinco campos anteriores. Se almacena en la propiedad PortId. Esta
propiedad se puede usar para buscar rápidamente los registros de un puerto específico a través del tiempo.
Métricas
Los registros de puerto incluyen métricas que representen las conexiones asociadas. Actualmente, se notifican las
métricas siguientes (los detalles de cada métrica se describen en la sección anterior):
BytesSent y BytesReceived
LinksEstablished, LinksTerminated y LinksLive
ResposeTime, ResponseTimeMin, ResponseTimeMax y ResponseTimeSum
A continuación se incluyen puntos importantes que debe tener en cuenta:
Si un proceso acepta conexiones en la misma dirección IP, pero a través de varias interfaces de red, se
notificará un registro independiente para cada interfaz.
Los registros con IP comodín no contendrán ninguna actividad. Se incluyen para representar el hecho de que
un puerto del equipo está abierto al tráfico de entrada.
Para reducir el nivel de detalle y el volumen de datos, los registros con dirección IP de carácter comodín se
omitirán cuando haya un registro coincidente (para el mismo proceso, puerto y protocolo) con una dirección
IP específica. Si un registro de dirección IP comodín se omite, la propiedad IsWildcardBind del registro con la
dirección IP específica se establecerá en True. Esto indica que el puerto se expone a través de todas las
interfaces de la máquina del informe.
Los puertos que están enlazados solo en una interfaz específica tienen IsWildcardBind definido como False.
Registros de VMComputer
Los registros con un tipo de VMComputer tienen datos de inventario para servidores con Dependency Agent.
Estos registros tienen las propiedades de la tabla siguiente:
TenantId Identificador único del área de trabajo
SourceSystem Insights
TimeGenerated Marca de tiempo del registro (UTC)
Computer FQDN del equipo

AgentId Identificador único del agente de Log Analytics
Máquina nombre del recurso de Azure Resource Manager para la

máquina expuesta por ServiceMap. Tiene el formato m-
{GUID} , donde GUID coincide con el GUID de AgentId.
DisplayName Nombre para mostrar
FullDisplayName Nombre para mostrar del plan
HostName Nombre de la máquina sin el nombre de dominio
BootTime Hora de arranque de la máquina (UTC)
TimeZone La zona horaria normalizada
VirtualizationState virtual, hypervisor, physical
Ipv4Addresses Matriz de direcciones IPv4
Ipv4SubnetMasks Matriz de máscaras de subred IPv4 (en el mismo orden que

Ipv4Addresses)
Ipv4DefaultGateways Matriz de puertas de enlace IPv4
Ipv6Addresses Matriz de direcciones IPv6
MacAddresses Matriz de direcciones MAC
DnsNames Matriz de nombres DNS asociados a la máquina
DependencyAgentVersion Versión del agente de Dependency Agent que se ejecuta en la

máquina
OperatingSystemFamily Linux, Windows
OperatingSystemFullName Nombre completo del sistema operativo
PhysicalMemoryMB Memoria física en MB
Cpus Número de procesadores
CpuSpeed Velocidad de la CPU en MHz
VirtualMachineType hyperv, vmware, xen
VirtualMachineNativeId Identificador de máquina virtual asignado por su hipervisor
VirtualMachineNativeName Nombre de la máquina virtual

VirtualMachineHypervisorId Identificador único del hipervisor que hospeda la máquina

virtual
HypervisorType hyperv
HypervisorId Identificador único del hipervisor
HostingProvider azure
_ResourceId Identificador único de un recurso de Azure
AzureSubscriptionId Identificador único global que identifica la suscripción
AzureResourceGroup Nombre del grupo de recursos de Azure del que es miembro

la máquina
AzureResourceName Nombre del recurso de Azure
AzureLocation Ubicación del grupo de recursos de Azure
AzureUpdateDomain Nombre del dominio de actualización de Azure
AzureFaultDomain Nombre del dominio de error de Azure
AzureVmId Identificador único de la máquina virtual de Azure
AzureSize Tamaño de la máquina virtual de Azure
AzureImagePublisher Nombre del publicador de máquinas virtuales de Azure
AzureImageOffering Nombre del tipo de oferta de máquina virtual de Azure
AzureImageSku SKU de la imagen de máquina virtual de Azure
AzureImageVersion Versión de la imagen de máquina virtual de Azure
AzureCloudServiceName Nombre del servicio en la nube de Azure
AzureCloudServiceDeployment Identificador de implementación del servicio en la nube
AzureCloudServiceRoleName Nombre del rol del servicio en la nube
AzureCloudServiceRoleType Tipo de rol del servicio en la nube: worker o web
AzureCloudServiceInstanceId Identificador de instancia del rol del servicio en la nube
AzureVmScaleSetName Nombre de conjunto de escalado de máquinas virtuales
AzureVmScaleSetDeployment Identificador de la implementación del conjunto de escalado

de máquinas virtuales
AzureVmScaleSetResourceId Identificador único del recurso del conjunto de escalado de

máquinas virtuales
AzureVmScaleSetInstanceId Identificador único del conjunto de escalado de máquinas

virtuales
AzureServiceFabricClusterId Identificador único del clúster de Azure Service Fabric
AzureServiceFabricClusterName Nombre del clúster de Azure Service Fabric
Registro de VMProcess
Los registros con un tipo VMProcess tienen datos de inventario para procesos conectados mediante TCP en
servidores con Dependency Agent. Estos registros tienen las propiedades de la tabla siguiente:
TimeGenerated Marca de tiempo del registro (UTC)
AgentId Identificador único del agente de Log Analytics
Máquina nombre del recurso de Azure Resource Manager para la

máquina expuesta por ServiceMap. Tiene el formato m-
{GUID} , donde GUID coincide con el GUID de AgentId.
Proceso Identificador único del proceso de Service Map. Tiene el

formato p-{GUID} .
ExecutableName Nombre del archivo ejecutable del proceso
DisplayName Nombre para mostrar del proceso
Role Rol de proceso: webserver, appServer, databaseServer,

ldapServer, smbServer
Grupo Nombre del grupo de procesos Los procesos del mismo

grupo están relacionados de manera lógica; por ejemplo,
parte del mismo producto o componente del sistema.
StartTime Hora de inicio del grupo de procesos
FirstPid Primer PID del grupo de procesos
Descripción Descripción del proceso
CompanyName Nombre de la compañía

InternalName Nombre interno
ProductName Nombre del producto
ProductVersion Versión del producto
FileVersion Versión del archivo
ExecutablePath _s Ruta de acceso del archivo ejecutable
CommandLine Línea de comandos
WorkingDirectory Directorio de trabajo
Servicios Matriz de servicios en la que se ejecuta el proceso
UserName Cuenta en la que se está ejecutando el proceso
UserDomain Dominio en el que se está ejecutando el proceso
_ResourceId Identificador único de un proceso en el área de trabajo
Consultas de mapa de ejemplo

Enumerar todas las máquinas conocidas
VMComputer | summarize arg_max(TimeGenerated, *) by _ResourceId
Cuando se reinicie la VM por última vez
let Today = now(); VMComputer | extend DaysSinceBoot = Today - BootTime | summarize by Computer,
DaysSinceBoot, BootTime | sort by BootTime asc
Resumen de las VM de Azure por imagen, ubicación y SKU
VMComputer | where AzureLocation != "" | summarize by Computer, AzureImageOffering, AzureLocation,

AzureImageSku
Enumeración de la capacidad de memoria física de todos los equipos administrados
VMComputer | summarize arg_max(TimeGenerated, *) by _ResourceId | project PhysicalMemoryMB, Computer
Enumeración del nombre de equipo, DNS, IP y SO
VMComputer | summarize arg_max(TimeGenerated, *) by _ResourceId | project Computer, OperatingSystemFullName,

DnsNames, Ipv4Addresses
Buscar todos los procesos con "sql" en la línea de comandos

VMProcess | where CommandLine contains_cs "sql" | summarize arg_max(TimeGenerated, *) by _ResourceId
Buscar una máquina (registro más reciente ) por el nombre de recurso
search in (VMComputer) "m-4b9c93f9-bc37-46df-b43c-899ba829e07b" | summarize arg_max(TimeGenerated, *) by

_ResourceId
Buscar un equipo (registro más reciente ) por dirección IP
search in (VMComputer) "10.229.243.232" | summarize arg_max(TimeGenerated, *) by _ResourceId
Enumerar todos los procesos conocidos en un equipo determinado
VMProcess | where Machine == "m-559dbcd8-3130-454d-8d1d-f624e57961bc" | summarize arg_max(TimeGenerated, *)

by _ResourceId
Enumerar todos los equipos que ejecutan SQL Server
VMComputer | where AzureResourceName in ((search in (VMProcess) "*sql*" | distinct Machine)) | distinct

Computer
Enumerar todas las versiones de producto únicas de curl en mi centro de datos
VMProcess | where ExecutableName == "curl" | distinct ProductVersion
Crear un grupo de equipos de todos los equipos con CentOS
VMComputer | where OperatingSystemFullName contains_cs "CentOS" | distinct Computer
Tendencias de bytes enviados y recibidos
VMConnection | summarize sum(BytesSent), sum(BytesReceived) by bin(TimeGenerated,1hr), Computer | order by

Computer desc | render timechart
VM de Azure que transmiten más bytes
VMConnection | join kind=fullouter(VMComputer) on $left.Computer == $right.Computer | summarize

count(BytesSent) by Computer, AzureVMSize | sort by count_BytesSent desc
Tendencias del estado del vínculo
VMConnection | where TimeGenerated >= ago(24hr) | where Computer == "acme-demo" | summarize

dcount(LinksEstablished), dcount(LinksLive), dcount(LinksFailed), dcount(LinksTerminated) by
bin(TimeGenerated, 1h) | render timechart
Tendencia de errores de conexión
VMConnection | where Computer == "acme-demo" | extend bythehour = datetime_part("hour", TimeGenerated) |

project bythehour, LinksFailed | summarize failCount = count() by bythehour | sort by bythehour asc | render
timechart
Puertos enlazados
VMBoundPort
| where TimeGenerated >= ago(24hr)
| where Computer == 'admdemo-appsvr'
| distinct Port, ProcessName
Número de puertos abiertos en las máquinas
VMBoundPort
| where Ip != "127.0.0.1"
| summarize by Computer, Machine, Port, Protocol
| summarize OpenPorts=count() by Computer, Machine
| order by OpenPorts desc
Puntuación de procesos en el área de trabajo por el número de puertos que tienen abiertos
VMBoundPort
| where Ip != "127.0.0.1"
| summarize by ProcessName, Port, Protocol
| summarize OpenPorts=count() by ProcessName
| order by OpenPorts desc
Comportamiento agregado de cada puerto

A continuación, esta consulta se puede usar para puntuar los puertos por actividad (por ejemplo, puertos con más
tráfico entrante y saliente o puertos con más conexiones).
//
VMBoundPort
| where Ip != "127.0.0.1"
| summarize BytesSent=sum(BytesSent), BytesReceived=sum(BytesReceived),
LinksEstablished=sum(LinksEstablished), LinksTerminated=sum(LinksTerminated), arg_max(TimeGenerated,
LinksLive) by Machine, Computer, ProcessName, Ip, Port, IsWildcardBind
| project-away TimeGenerated
| order by Machine, Computer, Port, Ip, ProcessName
Resumir las conexiones salientes desde un grupo de máquinas

// the machines of interest
let machines = datatable(m: string) ["m-82412a7a-6a32-45a9-a8d6-538354224a25"];
// map of ip to monitored machine in the environment
let ips=materialize(VMComputer
| summarize ips=makeset(todynamic(Ipv4Addresses)) by MonitoredMachine=AzureResourceName
| mvexpand ips to typeof(string));
// all connections to/from the machines of interest
let out=materialize(VMConnection
| where Machine in (machines)
| summarize arg_max(TimeGenerated, *) by ConnectionId);
// connections to localhost augmented with RemoteMachine
let local=out
| where RemoteIp startswith "127."
| project ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp, DestinationPort,
Protocol, RemoteIp, RemoteMachine=Machine;
// connections not to localhost augmented with RemoteMachine
let remote=materialize(out
| where RemoteIp !startswith "127."
| join kind=leftouter (ips) on $left.RemoteIp == $right.ips
| summarize by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp,
DestinationPort, Protocol, RemoteIp, RemoteMachine=MonitoredMachine);
// the remote machines to/from which we have connections
let remoteMachines = remote | summarize by RemoteMachine;
// all augmented connections
(local)
| union (remote)
//Take all outbound records but only inbound records that come from either //unmonitored machines or
monitored machines not in the set for which we are computing dependencies.
| where Direction == 'outbound' or (Direction == 'inbound' and RemoteMachine !in (machines))
| summarize by ConnectionId, Direction, Machine, Process, ProcessName, SourceIp, DestinationIp,
DestinationPort, Protocol, RemoteIp, RemoteMachine
// identify the remote port
| extend RemotePort=iff(Direction == 'outbound', DestinationPort, 0)
// construct the join key we'll use to find a matching port
| extend JoinKey=strcat_delim(':', RemoteMachine, RemoteIp, RemotePort, Protocol)
// find a matching port
| join kind=leftouter (VMBoundPort
| where Machine in (remoteMachines)
| summarize arg_max(TimeGenerated, *) by PortId
| extend JoinKey=strcat_delim(':', Machine, Ip, Port, Protocol)) on JoinKey
// aggregate the remote information
| summarize Remote=makeset(iff(isempty(RemoteMachine), todynamic('{}'), pack('Machine', RemoteMachine,
'Process', Process1, 'ProcessName', ProcessName1))) by ConnectionId, Direction, Machine, Process,
ProcessName, SourceIp, DestinationIp, DestinationPort, Protocol
Registros de rendimiento
Los registros con un tipo de InsightsMetrics tienen datos de rendimiento del sistema operativo invitado de la
máquina virtual. Estos registros tienen las propiedades de la tabla siguiente:
TimeGenerated Hora en que se recopiló el valor (UTC)
Origen vm.azm.ms
Espacio de nombres Categoría del contador de rendimiento
Nombre Nombre del contador de rendimiento.
Val Valor recopilado
Etiquetas Detalles relacionados sobre el registro. Vea la tabla siguiente

para consultar las etiquetas utilizadas con diferentes tipos de
registros.
AgentId Identificador único de cada agente del equipo
Tipo InsightsMetrics
ResourceId Identificador de recurso de la máquina virtual
Los contadores de rendimiento recopilados actualmente en la tabla InsightsMetrics se enumeran en la tabla

siguiente:
ESPA C IO DE
N O M B RES N O M B RE DESC RIP C IÓ N UN IDA D ET IQ UETA S
Computer Latido Latido de equipo
Memoria AvailableMB Bytes disponibles en Megabytes memorySizeMB:

la memoria tamaño total de la
memoria
Red WriteBytesPerSecond Bytes de escritura de BytesPerSecond NetworkDeviceId:

red por segundo identificador del
dispositivo
bytes: total de bytes
enviados
Red ReadBytesPerSecond Bytes de lectura de BytesPerSecond networkDeviceId:

red por segundo identificador del
dispositivo
bytes: total de bytes
recibidos
Procesador UtilizationPercentage Porcentaje de uso del Percent totalCpus: CPU

procesador totales
LogicalDisk WritesPerSecond Escrituras en el disco CountPerSecond mountId: identificador

lógico por segundo de montaje del
dispositivo
LogicalDisk WriteLatencyMs Latencia de escritura MilliSeconds mountId: identificador

en el disco lógico en de montaje del
milisegundos dispositivo
LogicalDisk WriteBytesPerSecond Bytes de escritura en BytesPerSecond mountId: identificador

el disco lógico por de montaje del
segundo dispositivo
ESPA C IO DE
N O M B RES N O M B RE DESC RIP C IÓ N UN IDA D ET IQ UETA S
LogicalDisk TransfersPerSecond Transferencias del CountPerSecond mountId: identificador

disco lógico por de montaje del
segundo dispositivo
LogicalDisk TransferLatencyMs Latencia de MilliSeconds mountId: identificador

transferencia del de montaje del
disco lógico en dispositivo
milisegundos
LogicalDisk ReadsPerSecond Lecturas del disco CountPerSecond mountId: identificador

lógico por segundo de montaje del
dispositivo
LogicalDisk ReadLatencyMs Latencia de lectura MilliSeconds mountId: identificador

del disco lógico en de montaje del
milisegundos dispositivo
LogicalDisk ReadBytesPerSecond Bytes de lectura de BytesPerSecond mountId: identificador

disco lógico por de montaje del
segundo dispositivo
LogicalDisk FreeSpacePercentage Porcentaje de espacio Percent mountId: identificador

disponible en disco de montaje del
lógico dispositivo
LogicalDisk FreeSpaceMB Bytes de espacio Megabytes mountId: identificador

disponible en el disco de montaje del
lógico dispositivo
diskSizeMB: tamaño
total del disco
LogicalDisk BytesPerSecond Bytes del disco lógico BytesPerSecond mountId: identificador

por segundo de montaje del
dispositivo
Pasos siguientes
Si eres nuevo a la hora de escribir consultas en Azure Monitor, revisa el tema sobre el uso de Log Analytics
en Azure Portal para escribir consultas de registro.
Información acerca de la escritura de consultas de búsqueda.
Creación de informes interactivos Azure Monitor
para VM con libros
Los libros combinan texto,consultas de registros, métricas y parámetros en informes interactivos avanzados. Otros
miembros del equipo con acceso a los mismos recursos de Azure pueden editar los libros.
Los libros son útiles en escenarios como los siguientes:
Explorar la utilización de la máquina virtual cuando no se conocen de antemano las métricas de interés:
utilización de CPU, espacio en disco, memoria, dependencias de red, etc. A diferencia de otras herramientas de
análisis de uso, los libros le permiten combinar varios tipos de visualizaciones y análisis, lo que los hace
idóneos para este tipo de exploración de forma libre.
Explicar a su equipo cómo funciona una máquina virtual aprovisionada recientemente, mostrando las métricas
para contadores clave y otros eventos de registro.
Compartir los resultados de un experimento de cambio de tamaño de la máquina virtual con otros miembros
del equipo. Puede explicar los objetivos del experimento con texto y luego mostrar cada métrica de utilización y
las consultas de análisis que se usan para evaluar el experimento, junto con indicadores claros sobre si cada
métrica está por encima o por debajo del objetivo.
Notificar el impacto de una interrupción del servicio en la utilización de la máquina virtual, con la combinación
de datos, explicación del texto y análisis de los pasos siguientes para evitar más interrupciones en el futuro.
En la tabla siguiente se resumen los libros que incluye Azure Monitor para VM para ayudarle a empezar.
L IB RO DESC RIP C IÓ N Á M B ITO
Rendimiento Proporciona una versión personalizable A escala

de la vista de la Lista y Gráficos de N
principales en un único libro que
aprovecha todos los contadores de
rendimiento de Log Analytics que se
han habilitado.
Contadores de rendimiento Una vista de Gráfico de N principales A escala

entre un amplio conjunto de
Conexiones Las conexiones ofrecen una visión A escala

detallada de las conexiones entrantes y
salientes de las máquinas virtuales
supervisadas.
Puertos activos Proporciona una lista de los procesos A escala

que se han enlazado a los puertos en
las máquinas virtuales supervisadas y
su actividad en el periodo de tiempo
seleccionado.
Open Ports (Abrir puertos) Proporciona el número de puertos A escala

abiertos en las máquinas virtuales
supervisadas, así como los detalles de
estos puertos.
L IB RO DESC RIP C IÓ N Á M B ITO
Conexiones con errores Muestra el número de conexiones con A escala

errores en las máquinas virtuales
supervisadas, la tendencia de errores y
si el porcentaje de errores aumenta con
el tiempo.
Seguridad y auditoría Un análisis del tráfico TCP/IP que A escala

informa sobre las conexiones generales,
las conexiones malintencionadas, en las
que se encuentran los puntos de
conexión IP de forma global. Para
habilitar todas las características, deberá
habilitar la Detección de seguridad.
Tráfico TCP Un informe de clasificación de las A escala

máquinas virtuales supervisadas y del
tráfico enviado, recibido y el total, en
una cuadrícula que se muestra como
una línea de tendencia.
Comparación de tráfico Este libro le permite comparar las A escala

tendencias en el tráfico de red para solo
una máquina o para un grupo.
Rendimiento Proporciona una versión personalizable Máquina virtual única

de la Vista de rendimiento que
aprovecha todos los contadores de
rendimiento de Log Analytics que se
han habilitado.
Conexiones Las conexiones ofrecen una visión Máquina virtual única

detallada de las conexiones entrantes y
salientes de las máquinas virtuales.
Creación de un libro
Un libro se compone de secciones que constan de tablas, texto, controles de entrada y gráficos que se pueden
editar de forma independientemente. Para entender mejor los libros, empecemos por abrir una plantilla para
recorrer la creación de un libro personalizado.
2. Seleccione Máquinas vir tuales .
3. En la lista, seleccione una máquina virtual.
4. En la página de la máquina virtual, en la sección Super visión , seleccione Insights .
5. En la página de conclusiones de la máquina virtual, seleccione la pestaña de Rendimiento o de Mapas y
luego seleccione Ver libros en el vínculo en la página. En la lista desplegable, seleccione Ir a la galería .
Se inicia la galería de libros con varios libros pregenerados que le ayudarán a empezar a trabajar.
6. Para crear un libro, seleccione Nuevo .
Edición de las secciones del libro

Los libros tienen dos modos: modo de edición y modo de lectura . Cuando se inicia por primera vez un libro, se
abre en modo de edición . Se muestra todo el contenido del libro, incluidos los pasos y los parámetros que se
encuentran ocultos. El modo de lectura presenta una vista simplificada de estilo del informe. El modo de lectura
permite reducir la complejidad que conlleva la creación de un informe, a la vez que se puede acceder a la mecánica
subyacente con tan solo unos clics cuando la necesita para realizar modificaciones.
1. Cuando haya terminado de editar una sección, haga clic en Edición finalizada en la esquina inferior
izquierda de la sección.
2. Para crear un duplicado de una sección, haga clic en el icono Clone this section (Clonar este sección). La
creación de secciones duplicadas es una forma ideal de iterar una consulta sin perder las iteraciones
anteriores.
3. Para mover hacia arriba una sección de un libro, haga clic en el icono Subir o Bajar .
4. Para eliminar una sección de forma permanente, haga clic en el icono Quitar .
Adición de texto y secciones de Markdown

La adición de títulos, explicaciones y comentarios a los libros le ayuda a convertir un conjunto de tablas y gráficos
en una descripción. Las secciones de texto de los libros son compatibles con la sintaxis de Markdown para dar
formato a los textos como títulos, negrita, cursiva y listas con viñetas.
Para agregar una sección de texto al libro, use el botón Agregar texto situado en la parte inferior del libro o en la
parte inferior de cualquier sección.
Incorporación de secciones de consulta
Para agregar una sección de consulta al libro, use el botón Agregar consulta situado en la parte inferior del libro
o en la parte inferior de cualquier sección.
Las secciones de consulta son muy flexibles y pueden usarse para responder preguntas como las siguientes:
¿Cómo ha sido la utilización de la CPU durante el mismo período de tiempo en el que se ha producido un
aumento de tráfico?
¿Cuál ha sido la tendencia en el espacio disponible en disco en el último mes?
¿Cuántos errores de conexión de red ha experimentado mi máquina virtual en las últimas dos semanas?
Además, no está limitado únicamente a realizar consultas del contexto de la máquina virtual con la que inició el
libro. Puede hacer consultas en varias máquinas virtuales, así como en las áreas de trabajo de Log Analytics,
siempre que tenga permiso para acceder a esos recursos.
Para incluir los datos de otras áreas de trabajo de Log Analytics o de una aplicación de Application Insights
específica, use el identificador de área de trabajo . Para obtener más información acerca de las consultas entre
recursos, consulte la guía oficial.
Configuración avanzada de consultas analíticas
Cada sección tiene su propia configuración avanzada, a la que se puede acceder mediante el icono de
configuración situado a la derecha del botón Agregar parámetros .
Ancho personalizado Define un tamaño arbitrario para un elemento, de modo que

se puedan ajustar varios elementos en una sola línea. Esto le
permitirá organizar mejor los gráficos y las tablas en informes
interactivos enriquecidos.
Conditionally visible (Visible condicionalmente) Especificar para ocultar los pasos en función de un parámetro
en el modo de lectura.
Expor t a parameter (Exportar un parámetro) Permite que una fila seleccionada en la cuadrícula o en el
gráfico genere más pasos para cambiar los valores o para
hacerlos visibles.
Mostrar la consulta cuando no se está editando Muestra la consulta por encima del gráfico o la tabla incluso
en modo de lectura.
Mostrar el botón Abrir en Analytics cuando no se Agrega el icono azul de Analytics a la esquina derecha del
esté editando gráfico para permitir el acceso con un solo clic.
La mayoría de estas opciones de configuración son bastante intuitivas, pero para comprender la opción Expor tar
un parámetro le recomendamos que examine un libro que use esta funcionalidad.
Uno de los libros compilados previamente, Tráfico de TCP , proporciona información sobre las métricas de
conexión de una máquina virtual.
La primera sección del libro se basa en datos de consulta de registro. La segunda sección también se basa en datos
de consulta de registro pero, si se selecciona una fila en la primera tabla, se actualizará el contenido de los gráficos
de forma interactiva:
El comportamiento es posible mediante la utilización de la configuración avanzada Cuando se seleccione un

elemento, expor te un parámetro , que está habilitada en la consulta de registro de la tabla.
Después, la segunda consulta de registro utiliza los valores exportados cuando se selecciona una fila para crear un
conjunto de valores que luego utilizan el encabezado y los gráficos de la sección. Si no se selecciona ninguna fila,
oculta el encabezado y los gráficos de la sección.
Por ejemplo, el parámetro oculto en la segunda sección utiliza la siguiente referencia de la fila seleccionada en la
cuadrícula:
VMConnection
| where TimeGenerated {TimeRange}
| where Computer in ("{ComputerName}") or '*' in ("{ComputerName}")
| summarize Sent = sum(BytesSent), Received = sum(BytesReceived) by bin(TimeGenerated, {TimeRange:grain})
Incorporación de secciones de métricas
Las secciones de las métricas le proporcionan acceso total para incorporar datos de métricas de Azure Monitor en
sus informes interactivos. En Azure Monitor para VM, los libros compilados previamente normalmente contendrán
datos de consulta de análisis en lugar de datos de métrica. Se puede elegir la creación de libros con datos de
métrica, lo que permite aprovechar al máximo lo mejor de ambas características en un mismo lugar. También tiene
la capacidad de extraer datos de métricas de recursos en cualquiera de las suscripciones a las que tiene acceso.
Este es un ejemplo de datos de la máquina virtual que se extraen en un libro para proporcionar una visualización
de cuadrícula del rendimiento de la CPU:
Incorporación de secciones de parámetros

Los parámetros de libros le permiten cambiar valores en el libro sin tener que editar manualmente las secciones
de texto o consulta. Esto elimina la necesidad de tener que comprender el lenguaje de consulta de análisis
subyacente y amplía significativamente la audiencia potencial de creación de informes basados en el libro.
Para reemplazar los valores de parámetros en consultas, texto o en otras secciones de parámetros, se coloca el
nombre del parámetro entre llaves, como {parameterName} . Los nombres de parámetros se limitan a reglas
similares como identificadores de JavaScript, básicamente caracteres alfabéticos o de subrayado, seguidos de
caracteres alfanuméricos o de subrayado. Por ejemplo, a1 está permitido, pero 1a no lo está.
Los parámetros son lineales, desde la parte superior de un libro y hasta los pasos posteriores. Los parámetros que
se declaran más adelante en un libro pueden reemplazar a aquellos que se han declarado anteriormente. Esto
también permite a los parámetros que usan consultas tener acceso a los valores de parámetros definidos
anteriormente. En el propio paso de un parámetro, los parámetros también son lineales, de izquierda a derecha,
donde los parámetros de la derecha pueden depender de un parámetro declarado anteriormente en ese mismo
paso.
Hay cuatro tipos diferentes de parámetros que se admiten actualmente:
Texto Permite al usuario editar un cuadro de texto y, si se quiere, se
puede proporcionar una consulta para rellenar el valor
predeterminado.
Lista desplegable Permite al usuario elegir entre un conjunto de valores.
Selector de inter valo de tiempo Permite al usuario elegir entre un conjunto predefinido de
valores de intervalo de tiempo o seleccionar entre un
intervalo de tiempo personalizado.
Selector de recursos Permite al usuario elegir entre los recursos seleccionados para
el libro.
Uso de un parámetro de texto

El valor que un usuario escribe en el cuadro de texto se sustituye directamente en la consulta, sin caracteres de
escape ni comillas. Si el valor necesario es una cadena, la consulta debe tener comillas alrededor del parámetro
(como "{parameter}" ).
El parámetro de texto permite que el valor de un cuadro de texto se use en cualquier lugar. Puede ser el nombre de
la tabla, el nombre de la columna, el nombre de la función, el operador, etc. El tipo de parámetro de texto tiene la
configuración Obtener el valor predeterminado de consulta de análisis , lo que permite que el autor del
libro use una consulta para rellenar el valor predeterminado de ese cuadro de texto.
Cuando se usa el valor predeterminado de una consulta de registro, solo el primer valor de la primera fila (fila 0,
columna 0) se utiliza como el valor predeterminado. Por lo tanto, se recomienda limitar la consulta para devolver
solo una sola fila y una columna. Se omite cualquier otro dato devuelto por la consulta.
Independientemente del valor que devuelva la consulta, se reemplazará directamente sin ningún carácter de
escape ni comillas. Si la consulta no devuelve ninguna fila, el resultado del parámetro es una cadena vacía (si el
parámetro no es necesario) o indefinido (si el parámetro es necesario).
Uso de una lista desplegable
El tipo de parámetro de la lista desplegable le permite crear un control de lista desplegable, lo que permite a su
vez seleccionar uno o varios valores.
La lista desplegable se rellena mediante una consulta de registro o JSON. Si la consulta devuelve una columna, los
valores de esa columna son el valor y la etiqueta en el control de la lista desplegable. Si la consulta devuelve dos
columnas, la primera es el valor y la segunda es la etiqueta que se muestra en la lista desplegable. Si la consulta
devuelve tres columnas, la tercera se utiliza para indicar la selección predeterminada en esa lista desplegable. Esta
columna puede ser de cualquier tipo, pero lo más sencillo es usar tipos booleanos o numéricos, donde 0 es falso y
1 es verdadero.
Si la columna es un tipo de cadena, la cadena nula o vacía se considera falsa y cualquier otro valor se considera
verdadero. Para las listas desplegables de selección única, el primer valor con un valor verdadero se utiliza como la
selección predeterminada. Para las listas desplegables de selección múltiple, todos los valores con un valor
verdadero se utilizan como el conjunto de selección predeterminada. Los elementos en la lista desplegable se
muestran en el orden en el que la consulta devuelve las filas.
Echemos un vistazo a los parámetros del informe Información general de conexiones. Haga clic en el símbolo de
edición junto a Dirección .
Esto iniciará el elemento de menú Editar parámetro .
JSON permite generar una tabla arbitraria que se rellena con contenido. Por ejemplo, el siguiente JSON genera
dos valores en la lista desplegable:
[
{ "value": "inbound", "label": "Inbound"},
{ "value": "outbound", "label": "Outbound"}
]
Un ejemplo más aplicable es usar una lista desplegable para elegir entre un conjunto de contadores de
rendimiento por el nombre:
Perf
| summarize by CounterName, ObjectName
| order by ObjectName asc, CounterName asc
| project Counter = pack('counter', CounterName, 'object', ObjectName), CounterName, group = ObjectName
La consulta mostrará los resultados de la siguiente forma:
Las listas desplegables son herramientas increíblemente eficaces para personalizar y crear informes interactivos.
Parámetros de intervalo de tiempo
Aunque puede elaborar su propio parámetro de intervalo de tiempo personalizado mediante el tipo de parámetro
de la lista desplegable, también puede usar el tipo de parámetro de intervalo de tiempo ya definido si no necesita
el mismo grado de flexibilidad.
Los tipos de parámetro de intervalo de tiempo tienen 15 intervalos predeterminados que van desde cinco minutos
hasta los últimos 90 días. También hay una opción para permitir la selección del intervalo de tiempo
personalizado, que permite que el operador del informe elija los valores explícitos de inicio y fin del intervalo de
tiempo.
Selector de recursos
El tipo de parámetro del selector de recursos le permite definir el ámbito del informe para ciertos tipos de
recursos. Un ejemplo de libro compilado previamente que aprovecha el tipo de selector de recursos es el libro
Rendimiento .
Almacenamiento y uso compartido de libros con el equipo
Los libros se guardan en un área de trabajo de Log Analytics o en un recurso de máquina virtual, en función de
cómo se accede a la galería de libros. El libro se puede guardar en la sección privada de Mis informes o en la
sección Informes compar tidos a la que pueden acceder todos los usuarios con acceso al recurso. Para ver todos
los libros del recurso, haga clic en el botón Abrir de la barra de acciones.
Para compartir un libro que está actualmente en Mis informes :
1. Haga clic en Abrir en la barra de acciones
2. Haga clic en el botón "..." situado junto al libro que desea compartir
3. Haga clic en Move to Shared Repor ts (Mover a informes compartidos).
Para compartir un libro con un vínculo o por correo electrónico, haga clic en Compar tir en la barra de acciones.
Tenga en cuenta que los destinatarios del vínculo necesitarán acceder a este recurso en Azure Portal para ver el
libro. Para realizar ediciones, los destinatarios necesitan al menos permisos de colaborador para el recurso.
Para anclar un vínculo a un libro en un panel de Azure:
1. Haga clic en Abrir en la barra de acciones
2. Haga clic en el botón "..." situado junto al libro que desea anclar
3. Haga clic en Anclar al panel .
Pasos siguientes
Para identificar las limitaciones y el rendimiento general de la máquina virtual, consulte Visualización del
rendimiento de la máquina virtual de Azure.
Para más información sobre las dependencias de las aplicaciones detectadas, consulte Uso de la asignación
de Azure Monitor para VM.
Creación de alertas a partir de Azure Monitor para
VM
Las alertas de Azure Monitor notifican al usuario proactivamente sobre datos y patrones interesantes en los datos
de supervisión. Azure Monitor para VM no incluye las reglas de alerta preconfiguradas, pero puede crear las suyas
propias en función de los datos que recopila. En este artículo se proporcionan instrucciones sobre cómo crear
reglas de alerta, incluido un conjunto de consultas de ejemplo.
Tipos de reglas de alerta

Azure Monitor tiene distintos tipos de reglas de alerta en función de los datos que se usan para crear la alerta.
Todos los datos recopilados por Azure Monitor para VM se almacenan en registros de Azure Monitor que admiten
alertas de registro. Actualmente no puede usar alertas de métricas con los datos de rendimiento recopilados de
Azure Monitor para VM porque los datos no se recopilan en métricas de Azure Monitor. Para recopilar datos para
alertas de métricas, instale la extensión de diagnósticos para máquinas virtuales Windows o el agente Telegraf
para máquinas virtuales Linux para recopilar datos de rendimiento en métricas.
Hay dos tipos de alertas de registro en Azure Monitor:
Alertas de número de resultados, que crean una única alerta cuando una consulta devuelve al menos un
número especificado de registros. Son ideales para datos no numéricos, como los eventos de Windows y
Syslog recopilados por el agente de Log Analytics o para analizar las tendencias de rendimiento en varios
equipos.
Alertas de medición de métricas, que crean una alerta independiente para cada registro de una consulta que
tenga un valor que supere un umbral definido en la regla de alerta. Estas reglas de alerta son ideales para los
datos de rendimiento recopilados por Azure Monitor para VM, ya que pueden crear alertas individuales para
cada equipo.
Tutorial de reglas de alerta

Esta sección le guía a través de la creación de una regla de alerta de medición de métricas mediante datos de
rendimiento de Azure Monitor para VM. Puede usar este proceso básico con diversas consultas de registro para
alertar sobre diferentes contadores de rendimiento.
Empiece por crear una nueva regla de alerta siguiendo el procedimiento descrito en Creación, visualización y
administración de alertas de registro mediante Azure Monitor. En el recurso seleccione el área de trabajo de Log
Analytics que Azure Monitor para VM usa en la suscripción. Puesto que el recurso de destino para las reglas de
alerta de registro es siempre un área de trabajo de Log Analytics, la consulta de registro debe incluir cualquier
filtro para máquinas virtuales concretas o conjuntos de escalado de máquinas virtuales.
Para la condición de la regla de alerta, use una de las consultas de la sección que aparece a continuación como la
consulta de búsqueda . La consulta debe devolver una propiedad numérica denominada AggregatedValue. Debe
resumir los datos por equipo para que pueda crear una alerta independiente para cada máquina virtual que
supere el umbral.
En Lógica de aler ta , seleccione Unidades métricas y proporcione un valor en Valor del umbral . En
Desencadenar aler ta según , especifique el número de veces que se debe superar el umbral antes de que se
cree una alerta. Por ejemplo, es probable que no le interese el escenario en el que el procesador supera un umbral
una vez y luego vuelve a la normalidad, pero sí si sigue superando el umbral en varias medidas consecutivas.
La sección Se evaluó basándose en define la frecuencia con la que se ejecuta la consulta y el período de tiempo
de esta. En el ejemplo que se muestra a continuación, la consulta se ejecutará cada quince minutos y evaluará los
valores de rendimiento recopilados durante los quince minutos anteriores.
Consultas de alerta de ejemplo

Las siguientes consultas se pueden usar con una regla de alerta de medición de métricas con los datos de
rendimiento recopilados por Azure Monitor para VM. Cada una resume los datos por equipo para que se cree una
alerta para cada equipo con un valor que supere el umbral.
Uso de CPU
InsightsMetrics
| where Origin == "vm.azm.ms"
| where Namespace == "Processor" and Name == "UtilizationPercentage"
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId
Memoria disponible en MB
InsightsMetrics
| where Namespace == "Memory" and Name == "AvailableMB"
Memoria disponible en porcentaje
InsightsMetrics
| where Namespace == "Memory" and Name == "AvailableMB"
| extend TotalMemory = toreal(todynamic(Tags)["vm.azm.ms/memorySizeMB"])
| extend AvailableMemoryPercentage = (toreal(Val) / TotalMemory) * 100.0
| summarize AggregatedValue = avg(AvailableMemoryPercentage) by bin(TimeGenerated, 15m), Computer, _ResourceId
Disco lógico usado: todos los discos de cada equipo
InsightsMetrics
| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"
Disco lógico usado: discos individuales
InsightsMetrics
| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"
| extend Disk=tostring(todynamic(Tags)["vm.azm.ms/mountId"])
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, Disk
IOPS de disco lógico
InsightsMetrics
| where Namespace == "LogicalDisk" and Name == "TransfersPerSecond"
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m) ), Computer, _ResourceId, Disk
Velocidad de datos de disco lógico
InsightsMetrics
| where Namespace == "LogicalDisk" and Name == "BytesPerSecond"
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m) , Computer, _ResourceId, Disk
Bytes de interfaces de red recibidos: todas las interfaces
InsightsMetrics
| where Namespace == "Network" and Name == "ReadBytesPerSecond"
Bytes de interfaces de red recibidos: interfaces individuales
InsightsMetrics
| where Namespace == "Network" and Name == "ReadBytesPerSecond"
| extend NetworkInterface=tostring(todynamic(Tags)["vm.azm.ms/networkDeviceId"])
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, NetworkInterface
Bytes de interfaces de red enviados: todas las interfaces
InsightsMetrics
| where Namespace == "Network" and Name == "WriteBytesPerSecond"
Bytes de interfaces de red enviados: interfaces individuales
InsightsMetrics
| where Namespace == "Network" and Name == "WriteBytesPerSecond"
| extend NetworkInterface=tostring(todynamic(Tags)["vm.azm.ms/networkDeviceId"])
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), Computer, _ResourceId, NetworkInterface
Conjunto de escalado de máquina virtual

Realice la modificación por el identificador de suscripción, el grupo de recursos y el nombre del conjunto de
InsightsMetrics
| where _ResourceId startswith "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-
resource-group/providers/Microsoft.Compute/virtualMachineScaleSets/my-vm-scaleset"
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m), _ResourceId
Máquina virtual específica

Realice la modificación por el identificador de suscripción, el grupo de recursos y el nombre de la máquina virtual.
InsightsMetrics
| where _ResourceId =~ "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-
group/providers/Microsoft.Compute/virtualMachines/my-vm"
| summarize AggregatedValue = avg(Val) by bin(TimeGenerated, 15m)
Utilización de la CPU para todos los recursos de proceso en una suscripción

Realice la modificación por el identificador de suscripción.
InsightsMetrics
| where _ResourceId startswith "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" and (_ResourceId contains
"/providers/Microsoft.Compute/virtualMachines/" or _ResourceId contains
"/providers/Microsoft.Compute/virtualMachineScaleSets/")
Utilización de la CPU para todos los recursos de proceso en un grupo de recursos

Realice la modificación por el identificador de suscripción y el grupo de recursos.
InsightsMetrics
| where _ResourceId startswith "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-
resource-group/providers/Microsoft.Compute/virtualMachines/"
or _ResourceId startswith "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-
group/providers/Microsoft.Compute/virtualMachineScaleSets/"
Pasos siguientes
Obtenga más información sobre alertas en Azure Monitor.
Obtenga más información sobre consultas de registro con datos de Azure Monitor para VM.
Deshabilitación de la supervisión de las máquinas
virtuales en Azure Monitor para VM
Después de habilitar la supervisión de las máquinas virtuales (VM), más adelante puede elegir deshabilitar la
supervisión en Azure Monitor para VM. En este artículo se muestra cómo deshabilitar la supervisión de una o más
VM.
Actualmente, Azure Monitor para VM no permite deshabilitar de forma selectiva la supervisión de VM. Puede que
el área de trabajo de Log Analytics admita Azure Monitor para VM y otras soluciones. También puede recopilar
otros datos de supervisión. Si el área de trabajo de Log Analytics proporciona estos servicios, debe entender el
efecto y métodos de la deshabilitación de la supervisión antes de empezar.
Azure Monitor para VM se basa en los siguientes componentes para ofrecer su experiencia:
Un área de trabajo de Log Analytics, que almacena los datos de supervisión de las máquinas virtuales y otros
orígenes.
Una colección de contadores de rendimiento configurados en el área de trabajo. La colección actualiza la
configuración de supervisión en todas las VM conectadas al área de trabajo.
VMInsights , que es una solución de supervisión configurada en el área de trabajo. Esta solución actualiza la
configuración de supervisión en todas las máquinas virtuales conectadas al área de trabajo.
MicrosoftMonitoringAgent y DependencyAgent , que son extensiones de Azure VM. Estas extensiones recopilan y
envían datos al área de trabajo.
Cuando se prepare para deshabilitar la supervisión de las VM, tenga en cuenta estas consideraciones:
Si realizó la evaluación con una sola VM y usó el área de trabajo de Log Analytics predeterminada
preseleccionada, puede deshabilitar la supervisión mediante la desinstalación del agente de dependencia de la
máquina virtual y la desconexión del agente de Log Analytics de esta área de trabajo. Este enfoque es adecuado
si tiene la intención de utilizar la máquina virtual para otros fines y decide posteriormente volver a conectarla a
un área de trabajo diferente.
Si seleccionó un área de trabajo de Log Analytics existente que admite otras soluciones de supervisión y
recopilación de datos de otros orígenes, puede quitar los componentes de la solución del área de trabajo sin
que el área de trabajo se vea afectada.
NOTE
Después de quitar los componentes de la solución del área de trabajo, puede seguir viendo los datos de rendimiento y de
mapa para las máquinas virtuales de Azure. Los datos, finalmente, dejarán de aparecer en las vistas Rendimiento y Mapa .
La opción Habilitar estará disponible en la máquina virtual de Azure seleccionada para que pueda volver a habilitar la
supervisión en el futuro.
Quitar completamente Azure Monitor para VM

Si aún necesita el área de trabajo de Log Analytics, siga estos pasos para quitar por completo Azure Monitor para
VM. Va a quitar la solución VMInsights del área de trabajo.
comience a escribir, la lista filtrará las sugerencias en función de la entrada. Seleccione Log Analytics .
3. En la lista de áreas de trabajo de Log Analytics, seleccione el área de trabajo que eligió al incorporarse a Azure
Monitor para VM.
4. A la izquierda, seleccione Soluciones .
5. En la lista de soluciones, seleccione VMInsights(nombre de área de trabajo) . En la página Introducción
de la solución, seleccione Eliminar . Cuando se le solicite confirmación, haga clic en Sí .
Deshabilitar la supervisión y conservar el área de trabajo

Si el área de trabajo de Log Analytics aún debe admitir la supervisión de otros orígenes, siga estos pasos para
deshabilitar la supervisión en la VM que usó para evaluar Azure Monitor para VM. Para las VM de Azure, quitará la
extensión de VM del agente de dependencias y la extensión de VM del agente de Log Analytics para Windows o
Linux directamente de la VM.
NOTE
No quite el agente de Log Analytics si:
Azure Automation administra la VM para orquestar los procesos o para administrar la configuración o las actualizaciones.
Azure Security Center administra la VM para la seguridad y la detección de amenazas.
Si quita el agente de Log Analytics, impedirá que esos servicios y soluciones administren de forma proactiva la VM.

3. En la lista, seleccione una máquina virtual.
4. En el panel izquierdo, seleccione Extensiones . En la página Extensiones , seleccione DependencyAgent .
5. En la página de propiedades de la extensión, seleccione Desinstalar .
6. En la página Extensiones , seleccione MicrosoftMonitoringAgent . En la página de propiedades de la
extensión, seleccione Desinstalar .
Introducción a Azure Monitor para contenedores
Azure Monitor para contenedores es una característica diseñada para supervisar el rendimiento de las
cargas de trabajo de contenedor implementadas en:
Clústeres de Kubernetes administrados que se hospedan en Azure Kubernetes Service (AKS)
Clústeres de Kubernetes autoadministrados que se hospedan en Azure con AKS Engine
Azure Container Instances
Clústeres de Kubernetes autoadministrados que se hospedan en Azure Stack o en el entorno local
Red Hat OpenShift en Azure
Kubernetes habilitado para Azure Arc (versión preliminar)
Azure Monitor para contenedores es compatible con los clústeres que ejecutan el sistema operativo Linux y
Windows Server 2019.
La supervisión de los contenedores es fundamental, sobre todo cuando se ejecuta un clúster de producción,
a escala, con varias aplicaciones.
Azure Monitor para contenedores le brinda la posibilidad de visibilizar el rendimiento mediante la
recopilación de métricas del procesador y de la memoria de los controladores, nodos y contenedores
disponibles en Kubernetes mediante la API de métricas. También se recopilan registros del contenedor. Una
vez habilitada la supervisión de clústeres de Kubernetes, se recopilan métricas y registros automáticamente
mediante una versión en contenedor del agente de Log Analytics para Linux. Las métricas se escriben en el
almacén de métricas y los datos de registro se incluyen en el almacén de registros asociado a su área de
¿Cómo se proporciona Azure Monitor para contenedores?

Azure Monitor para contenedores ofrece una experiencia de supervisión completa con diferentes
características de Azure Monitor. Estas características le permiten comprender el rendimiento y el estado
del clúster de Kubernetes que ejecuta el sistema operativo Linux y Windows Server 2019, así como las
cargas de trabajo del contenedor. Con Azure Monitor para contenedores, puede hacer lo siguiente:
Identificar los contenedores de AKS que se ejecutan en el nodo y su utilización media tanto del
procesador como de la memoria. Este conocimiento puede ayudarle a identificar cuellos de botella
en los recursos.
Identificar el uso de procesador y memoria de grupos de contenedores y sus contenedores
hospedados en Azure Container Instances.
Identificar dónde se encuentra el contenedor en un controlador o un pod. Este conocimiento puede
ayudarle a ver el rendimiento general del controlador o del pod.
Revisar el uso de recursos de las cargas de trabajo que se ejecutan en el host que no estén
relacionadas con los procesos estándar que admite el pod.
Conocer el comportamiento del clúster tanto con cargas medias como con las más pesadas. Este
conocimiento puede ayudarle a identificar los requisitos de capacidad y determinar la carga máxima
que el clúster puede admitir.
Configure alertas para que le notifiquen de manera proactiva o registren el hecho de que el uso de
la CPU y la memoria en nodos o contenedores supera los umbrales, o cuando se produzca un
cambio del estado de mantenimiento en el clúster en la infraestructura o la acumulación de estado
de los nodos.
Integrarse con Prometheus para ver las métricas de la aplicación y de la carga de trabajo que
recopila de los nodos y Kubernetes mediante consultas para crear alertas personalizadas y paneles y
realizar un análisis detallado.
Supervise las cargas de trabajo de contenedor implementadas en AKS Engine de manera local y AKS
Engine en Azure Stack.
Supervise las cargas de trabajo de contenedor implementadas en Red Hat OpenShift en Azure.
NOTE
La compatibilidad con Red Hat OpenShift en Azure es una característica que se encuentra en versión
preliminar pública en este momento.
Supervise las cargas de trabajo de contenedor implementadas en Kubernetes habilitado para Azure
Arc (versión preliminar).
Estas son las principales diferencias al supervisar un clúster de Windows Server en comparación con un
clúster de Linux:
Windows no tiene una métrica RSS de memoria y, como resultado, no está disponible para los
contenedores y el nodo de Windows. La métrica de espacio de trabajo está disponible.
La información sobre la capacidad de almacenamiento del disco no está disponible para los nodos de
Windows.
Solo se supervisan los entornos de pods, no los entornos de Docker.
Con la versión preliminar, se admite un máximo de 30 contenedores de Windows Server. Esta limitación
no se aplica a los contenedores de Linux.
Consulte el siguiente vídeo, que proporciona un análisis detallado de nivel intermedio para ayudarle a
obtener información sobre cómo supervisar el clúster de AKS con Azure Monitor para contenedores.
¿Cómo se obtiene acceso a esta característica?

Puede acceder a Azure Monitor para contenedores de dos maneras: desde Azure Monitor o directamente
desde el clúster de AKS seleccionado. Desde Azure Monitor tiene una perspectiva global de todos los
contenedores implementados, cuáles se supervisan y cuáles no. Esto le permite buscar y filtrar a través de
las suscripciones y los grupos de recursos y, después, explorar en profundidad Azure Monitor para
contenedores desde el contenedor seleccionado. En caso contrario, puede acceder a la característica
directamente desde un contenedor de AKS seleccionado desde la página de AKS.
Si le interesan la supervisión y la administración de hosts de contenedor de Docker y Windows que se

ejecutan fuera de AKS y quiere más información sobre la configuración, la auditoría y la utilización de
recursos, consulte la solución de supervisión de contenedores.
Pasos siguientes
Para comenzar a supervisar el clúster de Kubernetes, revise Cómo habilitar Azure Monitor para
contenedores, a fin de conocer los requisitos y los métodos disponibles para habilitar la supervisión.
En este artículo de preguntas frecuentes de Microsoft, se presenta una lista con las preguntas frecuentes
sobre Azure Monitor.
General
aplicaciones y servicios en Azure, en otros entornos en la nube o en el entorno local. Azure Monitor recopila
datos de varios orígenes en una plataforma de datos común en la que se pueden analizar las tendencias y las
anomalías. Las características enriquecidas de Azure Monitor ayudan a identificar y responder rápidamente
ante situaciones críticas que pueden afectar a la aplicación.
En septiembre de 2018, Microsoft combinó Azure Monitor, Log Analytics y Application Insights en un único
servicio para proporcionar una eficaz supervisión de un extremo a otro de las aplicaciones y los componentes
en los que se basan. Las características de Log Analytics y Application Insights no han cambiado, aunque
algunas características han cambiado su marca por Azure Monitor para reflejar mejor su nuevo ámbito. El
motor de datos de registro y el lenguaje de consulta de Log Analytics se denominan ahora Registros de Azure
Monitor. Consulte Actualizaciones de terminología de Azure Monitor.
Las características de Azure Monitor que están habilitadas automáticamente, como la recopilación de
métricas y los registros de actividad, se proporcionan sin costo alguno. Hay un costo asociado a otras
características, como las consultas de registro y las alertas. Para obtener información detallada sobre los
precios, consulte la página de precios de Azure Monitor.
diagnóstico para recopilar información más detallada sobre el funcionamiento de los recursos de Azure y
agregar soluciones de supervisión e información detallada para proporcionar un análisis adicional de los
datos recopilados de servicios específicos.
Puede acceder a todas las características y los datos de Azure Monitor desde el menú Monitor de Azure
Portal. La sección Super visión del menú de los distintos servicios de Azure proporciona acceso a las mismas
herramientas con datos filtrados para un recurso determinado. Tambi

Azure Monitor

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Azure Monitor

Cargado por

Copyright:

Formatos disponibles

Contents

Documentación sobre Azure Monitor

¿Qué datos recopila Azure Monitor?

Azure Monitor para contenedores

Respuesta a situaciones críticas

Visualización de los datos de supervisión

Integración y exportación de datos

También puede usar Power BI para mostrar la telemetría de solicitudes en un mapa.

Q UÉ DEB ERÍA VER C Ó M O C O N SEGUIRLO RA Z O N ES PA RA Q UERERLO

Gráficos de disponibilidad Pruebas web Saber que la aplicación web funciona

Rendimiento de la aplicación de Agregue Application Insights a su Detectar problemas de rendimiento

Métricas personalizadas de servidor Seguimiento de llamadas en el código Business intelligence

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Paso a través de proxy

¿Puedo ejecutar pruebas web de disponibilidad en un servidor de intranet?

Azure Monitor para contenedores

//lets say we are querying an hour worth of logs

¿Puedo ver las métricas recopiladas en Grafana?

Azure Monitor para máquinas virtuales

Inicio de sesión en Azure Portal

Página de información general

Visualización del registro de actividad

Inicio de sesión en Azure Portal

Creación de un área de trabajo de Log Analytics

Creación de la configuración de diagnóstico

Recuperación de datos con una consulta de registro

Creación de un área de trabajo de Log Analytics

Esta plantilla define un recurso:

az monitor log-analytics workspace show --resource-group my-workspace-01 --workspace-name my-resource-group

Creación de la configuración de diagnóstico

Esta plantilla define un recurso:

az deployment sub create --name CreateDiagnosticSetting --location eastus --template-file

az monitor diagnostic-settings show --resource '/subscriptions/00000000-0000-0000-0000-000000000000' --name

Generación de datos del registro

Recuperación de datos con una consulta de registro

Expanda uno de los registros para ver sus propiedades detalladas.

az group delete --name my-resource-group

Completar el inicio rápido de la supervisión de recursos de Azure

Habilitar Azure Monitor para VM

Configuración del área de trabajo

Ver datos recopilados

10. Vuelva a seleccionar la máquina virtual y, luego, seleccione Registrar eventos .

Inicio de sesión en Azure Portal

Crear un área de trabajo

2. Seleccione Crear y, después, seleccione opciones para los elementos siguientes:

3. Después de proporcionar la información necesaria en el panel Área de trabajo de Log Analytics ,

Obtención de la clave y el identificador de área de trabajo

Instalación del agente para Linux

El siguiente comando incluye el parámetro de proxy -p y la sintaxis de ejemplo necesaria cuando el

El siguiente comando incluye el parámetro de proxy -p y la sintaxis de ejemplo necesaria cuando el

3. Ejecute el comando siguiente para reiniciar el agente:

sudo /opt/microsoft/omsagent/bin/service_control restart [<workspace id>]

Recopilación de datos de eventos y rendimiento

Ver datos recopilados

Inicio de sesión en Azure Portal

Crear un área de trabajo

2. Seleccione Crear y, después, seleccione opciones para los elementos siguientes:

3. Después de proporcionar la información necesaria en el panel Área de trabajo de Log Analytics ,

Obtención de la clave y el identificador del área de trabajo

Instalación del agente para Windows

Visualización de los datos recopilados

Habilitación de Application Insights

Confirmación de la configuración de la aplicación