Partekatu honen bidez:


Métricas personalizadas en Azure Monitor (versión preliminar)

Azure pone algunas métricas a su disposición de manera estándar. Estas métricas se denominan estándar o de plataforma. Las métricas personalizadas son indicadores de rendimiento o métricas específicas de la empresa que se pueden recopilar a través de la telemetría de la aplicación, el agente de Azure Monitor, una extensión de diagnóstico que se ejecuta en los recursos de Azure o un sistema de supervisión externo. Cuando las métricas se publican en Azure Monitor, puede examinarlas, consultarlas y generar alertas en paralelo con las métricas estándar de 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:

Modelo de precios y retención

En general, aunque la ingesta de métricas estándar (métricas de plataforma) hacia el almacén de métricas de Azure Monitor no supone ningún costo, las métricas personalizadas sí que tiene un costo una vez que alcancen la disponibilidad general. Las consultas a la API de métricas conllevan costos. Para obtener más información sobre cuándo se habilita la facturación para las consultas de métricas y las métricas personalizadas, consulte la página de precios de Azure Monitor.

Las métricas personalizadas se conservan durante el mismo tiempo que las métricas de plataforma.

Nota:

Para proporcionar una mejor experiencia, las métricas personalizadas enviadas a Azure Monitor desde la API clásica (SDK) de Application Insights siempre se almacenan en Log Analytics y en el Almacén de métricas. El costo de almacenar estas métricas solo se basa en el volumen ingerido por Log Analytics. No hay ningún costo adicional para los datos almacenados en el Almacén de métricas.

Definiciones de métricas personalizadas

Cada punto de datos de métrica publicado contiene el espacio de nombres, el nombre y la información de la dimensión. La primera vez que se emite una métrica personalizada para Azure Monitor se crea automáticamente una definición de métrica. Esta nueva definición de métrica puede detectarse después en cualquier recurso con respecto al que se emitió la métrica a través de las definiciones de métricas. No es necesario definir previamente una métrica personalizada en Azure Monitor antes de emitirla.

Nota:

La característica Application Insights, la extensión de diagnóstico y el agente Telegraf de InfluxData ya están configurados para emitir los valores de métrica hacia el punto de conexión regional correcto e incluir todas las propiedades anteriores en cada emisión.

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 de REST de Azure Monitor. También puede crear alertas con ellas para avisarle cuando se cumplen ciertas condiciones.

Nota

Debe ser un rol de lector o colaborador para ver las métricas personalizadas. Consulte Lector de supervisión.

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.

Para más información sobre la visualización de métricas en Azure Portal, consulte Análisis de métricas con el Explorador de métricas de Azure.

Latencia y retención del almacenamiento

Una métrica recién agregada o una dimensión recién agregada a una métrica puede tardar hasta 3 minutos en aparecer. Una vez que los datos están en el sistema, 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:

Category Límite
Total de series temporales activas en una suscripción por región 50.000
Claves de dimensión por métrica 10
Longitud de cadena de espacios de nombres de métricas, nombres de métricas, claves de dimensión y valores de dimensión 256 caracteres
Longitud combinada de todos los nombres de métricas personalizados, con codificación utf-8 64 KB

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.

Para comprender el límite de 50 000 series temporales, tenga en cuenta la siguiente métrica:

Tiempo de respuesta del servidor con dimensiones: Región, Departamento, Id. de cliente.

Con esta métrica, si tiene 10 regiones, 20 departamentos y 100 clientes, se le proporcionarán 10 x 20 x 100 = 20 000 series temporales.

Si tiene 100 regiones, 200 departamentos y 2000 clientes, tendrá 100 x 200 x 2000 = 40 millones de series temporales, lo que supera el límite solo para esta métrica.

De nuevo, este límite no se aplica a una métrica individual. Corresponde a la suma de todas estas métricas en una suscripción y región.

Realice los pasos siguientes para ver las métricas de series temporales activas actuales y obtener más información para ayudarle a solucionar problemas.

  1. Vaya a la sección Supervisión de Azure Portal.
  2. Seleccione Métricas en el lado izquierdo.
  3. En Seleccionar un ámbito, compruebe la suscripción y los grupos de recursos aplicables.
  4. En Refinar ámbito, elija Uso de métricas personalizados y la ubicación deseada.
  5. Seleccione el botón Aplicar.
  6. Elija Serie temporal activa, Límite de serie temporal activa o Serie temporal limitada.

Hay un límite de 64 KB en la longitud combinada de todos los nombres de métricas personalizados, suponiendo que utf-8 o 1 byte por carácter. Si se supera el límite de 64 KB, los metadatos de métricas adicionales no estarán disponibles. Los nombres de métricas para métricas personalizadas adicionales no aparecerán en Azure Portal en los campos de selección y la API no la devolverá en solicitudes de definiciones de métricas. Los datos de métricas siguen estando disponibles y se pueden consultar.

Cuando se haya superado el límite, reduzca el número de métricas que envía o acorte la longitud de sus nombres. A continuación, los nombres de las nuevas métricas tardan hasta dos días en aparecer.

Para evitar alcanzar el límite, no incluya aspectos variables ni dimensionales en los nombres de métricas. Por ejemplo, las métricas para el uso de CPU del servidor CPU_server_12345678-319d-4a50-b27e-1234567890ab y CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 deben definirse como métricas CPU y con una dimensión Server.

Limitaciones y consideraciones de diseño

Uso de Application Insights con el fin de realizar auditorías. La canalización de telemetría de Application Insights está optimizada para minimizar el impacto en el rendimiento y limitar la supervisión del tráfico de red por parte de la aplicación. Por lo tanto, aplica limitaciones o realiza muestreos (toma solo un porcentaje de la telemetría e ignora el resto) si el conjunto de datos inicial se vuelve demasiado grande. Debido a este comportamiento, no se puede usar con fines de auditoría, ya que es probable que algunos registros se descarten.

Métricas con una variable en el nombre. No use una variable como parte del nombre de la métrica. Use un valor constante en su lugar. Cada vez que la variable cambie de valor, Azure Monitor generará una nueva métrica. Por este motivo, Azure Monitor alcanzará rápidamente el límite que se aplica sobre el número de métricas. Por lo general, cuando los desarrolladores quieren incluir una variable en el nombre de la métrica, lo hacen porque quieren realizar un seguimiento de varias series temporales que se incluyen en una métrica. Para este fin, sin embargo, deben usarse dimensiones en lugar de nombres de métricas variables.

Dimensiones de métricas de alta cardinalidad. Es mucho más probable que las métricas con demasiados valores válidos en una dimensión (una cardinalidad alta) alcancen el límite de 50 000. En general, nunca debe usar un valor que cambie constantemente en una dimensión. Por ejemplo, la marca de tiempo nunca debe ser una dimensión. Puede usar el servidor, cliente o id. de producto, pero solo si tiene un número menor de cada uno de esos tipos.

Como prueba, pregúntese si alguna vez crearía un gráfico de estos datos. Si tiene 10 o quizá incluso 100 servidores, puede resultar útil verlos todos en un gráfico para compararlos. Pero si tiene 1000, probablemente el gráfico resultante sea difícil o imposible de leer. Por ello, se recomienda mantenerlo en menos de 100 valores válidos. Si hubiera hasta 300 valores, estos podrían ser algo difíciles de leer. Si necesita superar esta cantidad, use los registros personalizados de Azure Monitor en su lugar.

Si utiliza un nombre con una variable o una dimensión de cardinalidad alta, puede que observe los siguientes problemas:

  • Las métricas no son fiables debido a un proceso de limitación.
  • El Explorador de métricas no funcionará.
  • Las alertas y las notificaciones se vuelven impredecibles.
  • Los costos pueden aumentar inesperadamente. Microsoft no cobra por métricas personalizadas con dimensiones mientras la característica esté en versión preliminar pública. Una vez que su uso comience a cobrarse, incurrirá en cargos inesperados. La intención es cobrar por el consumo de métricas en función del número de series temporales supervisadas y el número de llamadas API realizadas.

Si el nombre de la métrica o el valor de la dimensión se rellenan con un identificador o una dimensión de cardinalidad alta por error, puede corregirlo fácilmente si quita la parte variable.

Pero si la cardinalidad alta es esencial para su escenario, es probable que las métricas agregadas no sean la opción correcta. Cambie al uso de registros personalizados (es decir, llamadas a la API trackMetric con el elemento trackEvent). Sin embargo, tenga en cuenta que los registros no agregan los valores. Por tanto, cada entrada se almacenará de forma individual. Como resultado, si se experimenta un gran volumen de registros en un período de tiempo reducido (por ejemplo, 1 millón por segundo), esto podría provocar un proceso de limitación y retrasos en la ingesta.

Pasos siguientes

Use métricas personalizadas desde varios servicios: