Métricas agregadas previamente y basadas en registros en Application Insights
Nota:
La siguiente documentación se basa en la API clásica de Application Insights. El plan a largo plazo de Application Insights consiste en recopilar datos mediante OpenTelemetry. Para más información, vea Habilitación de OpenTelemetry de Azure Monitor para aplicaciones de .NET, Node.js, Python y Java y nuestro plan de desarrollo de OpenTelemetry. La guía de migración está disponible para .NET, Node.jsy Python.
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 agregadas previamente. Ambos tipos de métricas están disponibles para los usuarios de Application Insights. Cada uno de estos aporta un valor único en la supervisión del estado, los diagnósticos y el análisis de la aplicación. Los desarrolladores que van a instrumentar aplicaciones pueden decidir qué tipo de métrica es más adecuado para un escenario determinado. Las decisiones se basan en 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
Antes, 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 y vistas de página. Los desarrolladores pueden usar el SDK para emitir estos eventos manualmente; para ello, deben escribir código que invoca explícitamente el SDK. O bien, pueden usar la recopilación automática de eventos de la instrumentación automática. En cualquier caso, el back-end de Application Insights almacena todos los eventos recopilados como registros. Los paneles 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. Esto también permite reducir el tiempo necesario para 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 que reducen el número de eventos recopilados y almacenados. Estas técnicas incluyen el muestreo y el filtrado. 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.
Nota
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. Por lo general, estas métricas tienen muchas dimensiones de las propiedades de los eventos, lo que hace que sean superiores para el análisis. El muestreo y el filtrado afectan negativamente la precisión de estas métricas.
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. Este cambio hace que las métricas nuevas sean superiores en el momento de la consulta. La recuperación de datos se ejecuta más rápido y requiere menos capacidad de proceso. Como resultado, se permiten escenarios nuevos como las alertas casi en tiempo real sobre las dimensiones de las métricas y paneles con más capacidad de respuesta.
Importante
Las métricas basadas en registros y las métricas agregadas previamente coexisten en Application Insights. Para diferenciarlas, las métricas agregadas previamente ahora se denominan Métricas estándar en la experiencia del usuario de Application Insights. El nombre de las métricas tradicionales de los eventos cambió 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. Esto se aplica a las métricas estándar enviadas de manera predeterminada, por lo que el muestro y el filtrado no afectan la precisión. También se aplica a las métricas personalizadas enviadas mediante GetMetric, lo que genera una ingesta de datos y un costo menores.
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 el punto de conexión de recopilación de eventos de Application Insights para rellenar las métricas nuevas. 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.
El punto de conexión de recopilación agrega previamente eventos antes del muestreo de ingesta. Por este motivo, el muestreo de ingesta nunca afecta a la precisión de las métricas agregadas previamente, independientemente de la versión del SDK que use con la aplicación.
Tabla de métricas agregadas previamente compatibles con SDK
SDK de producción actuales | Métricas estándar (agregación previa de SDK) | Métricas personalizadas (sin agregación previa de SDK) | Métricas personalizadas (con agregación previa de SDK) |
---|---|---|---|
.NET Core y .NET Framework | Compatible (V2.13.1+) | Compatible mediante TrackMetric | Compatible (V2.7.2+) mediante GetMetric |
Java | No compatible | Compatible mediante TrackMetric | No compatible |
Node.js | Se admite (V2.0.0+) | Compatible mediante TrackMetric | No compatible |
Python | No compatible | Compatible | Se admite de forma parcial mediante OpenCensus.stats |
Nota
La implementación de métricas para Python mediante OpenCensus.stats es diferente de GetMetric. Para más información, consulte la documentación de Python sobre las métricas.
Tabla de métricas previamente agregadas compatibles sin código
SDK de producción actuales | Métricas estándar (agregación previa de SDK) | Métricas personalizadas (sin agregación previa de SDK) | Métricas personalizadas (con agregación previa de SDK) |
---|---|---|---|
ASP.NET | Compatible 1 | No compatible | No compatible |
ASP.NET Core | Compatible 2 | No compatible | No compatible |
Java | No compatible | No compatible | Compatible |
Node.js | No compatible | No compatible | No compatible |
- La instrumentación automática de ASP.NET en máquinas virtuales o conjuntos de escalado de máquinas virtuales y entornos locales emite métricas estándar sin dimensiones. Lo mismo ocurre con Azure App Service, pero el nivel de recopilación debe establecerse en recomendado. El SDK es necesario para todas las dimensiones.
- La instrumentación automática de ASP.NET Core en App Service emite métricas estándar sin dimensiones. El SDK es necesario para todas las dimensiones.
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 las siguientes:
- Configurar y alertar sobre una dimensión de una métrica personalizada
- La reducción del volumen de datos enviados 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 la versión del SDK ofrece GetMetric y TrackValue, estos métodos son la manera preferida de enviar métricas personalizadas. En este caso, la agregación previa se produce dentro del SDK. Este enfoque reduce el volumen de los datos almacenados en Azure y también el volumen de datos transmitidos del SDK a Application Insights. En caso contrario, use el método trackMetric, que realiza 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 OpenTelemetry, trackMetric o llamadas API de GetMetric y TrackValue se almacenan automáticamente en los almacenes de registros y métricas. Estas métricas se pueden encontrar en la tabla customMetrics de Application Insights y en el Explorador de métricas en el espacio de nombres de métricas personalizado denominado "azure.applicationinsights". Si bien la versión basada en registros de la métrica personalizada siempre conserva todas las dimensiones, la versión de la métrica agregada previamente se almacena de manera predeterminada sin dimensiones. Conservar dimensiones de métricas personalizadas es una característica en vista previa que se puede activar desde la pestaña Uso y costes estimado seleccionando Con dimensiones en Enviar métricas personalizadas al almacén de métricas de Azure.
Cuotas
Las métricas agregadas previamente se almacenan como series temporales en Azure Monitor. Se aplican cuotas de Azure Monitor sobre métricas personalizadas.
Nota
Superar la cuota podría tener consecuencias imprevistas. Azure Monitor puede dejar de ser confiable en su suscripción o región. Para obtener información sobre cómo evitar superar la cuota, consulte Limitaciones y consideraciones de diseño).
¿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 desactivó de manera predeterminada porque, en el futuro, el almacenamiento de métricas personalizadas con dimensiones se facturará por separado de Application Insights. El almacenamiento de métricas personalizadas no dimensionales sigue siendo gratuito (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 que desee, use el selector de espacios de nombres para cambiar entre las métricas estándar y las métricas basadas en registros. También puede seleccionar un espacio de nombres de métricas personalizado.
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, genera costos en función del tamaño de los datos ingeridos. Para más información, consulte Detalles de los precios de los registros de Azure Monitor. Las métricas personalizadas, incluidas todas sus dimensiones, siempre se almacenan en el almacén de registros de Application Insights. Además, una versión agregada previamente de las métricas personalizadas sin dimensiones se reenvía al almacén de métricas de manera predeterminada.
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.