Compartir a través de

Supervisión de la ingesta en cola con métricas

  • Artículo

En el proceso de ingesta en cola, Azure Data Explorer optimiza la ingesta de datos para un alto rendimiento mediante el procesamiento por lotes de pequeños fragmentos entrantes de datos en lotes en función de una directiva de procesamiento por lotes de ingesta configurable. La directiva de procesamiento por lotes permite establecer las condiciones del desencadenador para sellar un lote (tamaño de datos, número de blobs o tiempo transcurrido). Luego, estos lotes se ingieren de forma óptima para obtener resultados de consultas rápidos.

En este artículo, aprenderá a usar métricas para supervisar la ingesta en cola en Azure Data Explorer en Azure Portal.

Fases de procesamiento por lotes

Las fases descritas en esta sección se aplican a todas las ingestas de procesamiento por lotes. Para Las ingestas de Azure Event Grid, Azure Event Hubs, Azure IoT Hub y Cosmos DB, antes de que los datos se en cola para la ingesta de una conexión de datos obtengan los datos de orígenes externos y realicen un reorganizamiento inicial de datos.

La ingesta en cola se produce en fases:

  1. Batching Manager escucha la cola para los mensajes de ingesta y las solicitudes de procesos.
  2. Batching Manager optimiza el rendimiento de ingesta tomando los pequeños fragmentos de datos de entrada que recibe y procesa por lotes las direcciones URL en función de la directiva de procesamiento por lotes de ingesta.
  3. Ingestion Manager envía los comandos de ingesta a Azure Data Explorer Storage Engine.
  4. Azure Data Explorer Storage Engine almacena los datos ingeridos, lo que hace que esté disponible para la consulta.

Azure Data Explorer proporciona un conjunto de métricas de ingesta de Azure Monitor para que pueda supervisar la ingesta de datos en todas las fases y componentes del proceso de ingesta en cola.

La métrica de ingesta de Azure Data Explorer proporcionan información detallada sobre:

  • Resultado de la ingesta en cola.
  • La cantidad de datos ingeridos.
  • Latencia de la ingesta en cola y donde se produce.
  • El propio proceso de procesamiento por lotes.
  • Para las ingestas de Event Hubs, Event Grid e IoT Hub: el número de eventos recibidos.

En este artículo, aprenderá a usar las métricas de ingesta en Azure Portal para supervisar la ingesta en cola en Azure Data Explorer.

Requisitos previos

Creación de gráficos de métricas con el explorador de métricas de Azure Monitor

A continuación se muestra una explicación general de cómo usar las métricas de Azure Monitor que se implementarán en las secciones posteriores. Siga estos pasos para crear gráficos de métricas con el explorador de métricas de Azure Monitor en Azure Portal:

  1. Inicie sesión en Azure Portal y vaya a la página de información general del clúster de Azure Data Explorer.

  2. Seleccione Métricas en la barra de navegación izquierda para abrir el panel de métricas.

  3. Abra el panel del selector de hora en la parte superior derecha del panel de métricas y cambie el intervalo de tiempo la hora que desea analizar. En este artículo, vamos a analizar la ingesta de datos en Azure Data Explorer en las últimas 48 horas.

  4. Seleccione un ámbito y un espacio de nombres de métricas:

    • El ámbito es el nombre del clúster de Azure Data Explorer. En el ejemplo siguiente, usaremos un clúster denominado demo11.
    • En Espacio de nombres de métricas, seleccione Métricas estándar del clúster de Kusto. Este es el espacio de nombres que contiene las métricas de Azure Data Explorer.

    Captura de pantalla que muestra cómo seleccionar la configuración de una métrica en Azure Portal.

  5. Seleccione el nombre de la métrica y el valor de agregación correspondiente.

Para ver algunos ejemplos de este artículo, seleccionaremos Agregar filtro y Aplicar división para las métricas que tienen dimensiones. También usaremos Agregar métrica para trazar otras métricas en el mismo gráfico y + Nuevo gráfico para ver varios gráficos en una vista.

Cada vez que agregue una nueva métrica, repetirá los pasos cuatro y cinco.

Nota:

Para más información sobre cómo usar métricas para supervisar Azure Data Explorer en general y cómo trabajar con el panel de métricas, consulte Supervisión del rendimiento, el mantenimiento y el uso de Azure Data Explorer con métricas.

En este artículo, aprenderá qué métricas se pueden usar para realizar un seguimiento de la ingesta en cola y cómo usar estas métricas.

Visualización del resultado de la ingesta

La métrica Resultado de ingesta proporciona información sobre el número total de orígenes que se han ingerido correctamente y los que no se pudieron ingerir.

En este ejemplo, usaremos esta métrica para ver el resultado de nuestros intentos de ingesta y usaremos la información de estado para ayudar a solucionar los intentos con errores.

  1. En el panel Metrics (Métricas) de Azure Monitor, seleccione Add Metric (Agregar métrica).
  2. Seleccione Ingestion result (Resultado de ingesta) como valor de Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación). Esta selección muestra los resultados de la ingesta a lo largo del tiempo en una línea del gráfico.
  3. Seleccione el botón Apply splitting (Aplicar separación), que se encuentra encima del gráfico, y elija Status (Estado) para segmentar el gráfico por el estado de los resultados de la ingesta. Después de seleccionar los valores de separación, haga clic fuera del selector de divisiones para cerrarlo.

Ahora la información de métrica se divide por estado y podemos ver la información sobre el estado de los resultados de la ingesta dividida en tres líneas:

  1. Azul para las operaciones de ingesta correctas.
  2. Naranja para las operaciones de ingesta que no se pudieron realizar debido al error Entidad no encontrada.
  3. Morada para las operaciones de ingesta que no se pudieron realizar debido al error Solicitud incorrecta.

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de resultados de ingesta agregados por suma y divididos por estado.

Tenga en cuenta lo siguiente al examinar el gráfico de resultados de la ingesta:

  • Si se usa la ingesta de Event Hubs o IoT Hub, hay una agregación previa de eventos en el componente Data Connection. Durante esta fase de ingesta, los eventos se tratan como un único origen que se va a ingerir. Por consiguiente, unos pocos eventos aparecen como un único resultado de ingesta después de la agregación previa.
  • Los errores transitorios se reintentan internamente un número limitado de veces. Cada error transitorio se notifica como un resultado de ingesta transitorio. Este es el motivo por el que una única ingesta puede dar lugar a más de un resultado de ingesta.
  • En el gráfico, los errores de ingesta se muestran por la categoría del código de error. Para ver la lista completa de códigos de error de ingesta por categorías e intentar conocer mejor el posible motivo del error, consulte Códigos de error de ingesta en Azure Data Explorer.
  • Para más detalles sobre cualquier error de ingesta, puede establecer registros de diagnóstico de ingesta con errores. Sin embargo, es importante tener en cuenta que la generación de registros da como resultado la creación de recursos adicionales y, por tanto, un aumento en el COGS (costo de bienes vendidos).

Visualización de la cantidad de datos ingeridos

Las métricas Blobs processed, Blobs Received y Blobs Dropped proporcionan información sobre el número de blobs procesados, recibidos y eliminados por los componentes de ingesta durante las fases de ingesta en cola.

En este ejemplo, usaremos estas métricas para ver cuántos datos han atravesado la canalización de ingesta, cuántos recibieron los componentes de ingesta y cuántos se han descartado.

Blobs procesados

  1. En el panel Metrics (Métricas) de Azure Monitor, seleccione Add Metric (Agregar métrica).
  2. Seleccione Blobs Processed (Blobs procesados) como valor de Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación).
  3. Seleccione el botón Apply splitting y elija Component Type (Tipo de componente) para segmentar el gráfico en función de los distintos componentes de ingesta.
  4. Para centrarse en una base de datos específica del clúster, seleccione el botón Add filter (Agregar filtro), que se encuentra encima del gráfico, y, después, elija los valores de base de datos que desea incluir al trazar el gráfico. En este ejemplo, se filtran los blobs enviados a la base de datos de GitHub, para lo que se selecciona Database (Base de datos) en Property (Propiedad), = en Operator (Operador) y GitHub en la lista desplegable Values (Valores). Después de seleccionar los valores de filtro, haga clic fuera del selector de filtro para cerrarlo.

Ahora el gráfico muestra cuántos blobs enviados a la base de datos de GitHub se procesaron en cada uno de los componentes de ingesta a lo largo del tiempo.

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de blobs procesados desde la base de datos de GitHub, agregados por suma y divididos por tipo de componente.

  • Observe que el 13 de febrero hay una disminución en el número de blobs que se ingirieron en la base de datos de GitHub a lo largo del tiempo. Fíjese también que el número de blobs que se procesaron en cada uno de los componentes es similar, lo que significa que aproximadamente todos los datos procesados en el componente Data Connection también que los han procesado correctamente los componentes Batching Manager, Ingestion Manager y Azure Data Explorer Storage Engine. Estos datos están listos para la consulta.

Blobs recibidos

Para conocer mejor la relación entre el número de blobs recibidos en cada componente y el número de blobs que se procesaron correctamente en cada componente, agregaremos un nuevo gráfico:

  1. Seleccione + Nuevo gráfico.
  2. Elija los mismos valores que anteriormente en Scope (Ámbito), Metric Namespace (Nombre de espacio de métrica) y Aggregation (Agregación), y seleccione la métrica Blobs Received (Blobs recibidos).
  3. Seleccione el botón Apply splitting (Aplicar separación) y elija Component Type (Tipo de componente) para dividir la métrica Blobs Received (Blobs recibidos) por tipo de componente.
  4. Seleccione el botón Add filter (Agregar filtro) y establezca los mismos valores que antes para filtrar solo los blobs enviados a la base de datos de GitHub.

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra gráficos de blobs procesados y blobs recibidos desde la base de datos de GitHub, agregados por suma y divididos por tipo de componente.

  • Al comparar los gráficos, se observa que el número de blobs recibidos por cada componente coincide mucho con el número de blobs procesados por cada componente. Esta comparación indica que no se ha eliminado ningún blob durante la ingesta.

Blobs eliminados

Para determinar si hay blobs que se han eliminado durante la ingesta, es preciso analizar la métrica Blobs eliminados. Esta métrica muestra cuántos blobs se eliminaron durante la ingesta y ayuda a detectar si hay algún problema en el procesamiento en un componente de ingesta concreto. Para cada blob eliminado, también se obtiene una métrica Resultado de la ingesta con más información sobre el motivo del error.

Visualización de la latencia de la ingesta

Las métricas Stage Latency (Latencia de fase) y Discovery Latency (Latencia de detección) supervisan la latencia en el proceso de ingesta y preguntan si se producen latencias largas en Azure Data Explorer o antes de que los datos lleguen a Azure Data Explorer para su ingesta.

  • Stage Latency (Latencia de fase) indica el intervalo de tiempo que ha transcurrido desde que Azure Data Explorer detecta un mensaje hasta que un componente de la ingesta recibe su contenido para su procesamiento.
  • La latencia de detección se usa para canalizaciones de ingesta con conexiones de datos (como event Hub, IoT Hub y Event Grid). Esta métrica proporciona información sobre el intervalo de tiempo desde que los datos se ponen en cola hasta que las conexiones de datos de Azure Data Explorer los detecta. Este intervalo de tiempo es ascendente en Azure Data Explorer, por lo que no se incluye en la métrica Stage Latency (Latencia de fase), que solo mide la latencia en Azure Data Explorer.

Nota:

Según la directiva de procesamiento por lotes predeterminada, el tiempo de procesamiento por lotes predeterminado es de cinco minutos. Por consiguiente, si otros desencadenadores no han sellado el lote, se sellará a los cinco minutos.

Si detecta una latencia prolongada hasta que los datos están listos para la consulta, el análisis de la latencia de las métricas Stage Latency (Latencia de fase) y Discovery Latency (Latencia de detección) puede ayudarle a saber si la prolongada latencia se debe a una latencia larga en Azure Data Explorer o está en un nivel superior a Azure Data Explorer. Si la latencia se produce en el propio Azure Data Explorer, también puede detectar el componente específico responsable de la misma.

Latencia de fase (versión preliminar)

Echemos un vistazo primero a la latencia de fase de la ingesta en cola. En Fases del procesamiento por lotes, encontrará una explicación de cada fase.

  1. En el panel Metrics (Métricas) de Azure Monitor, seleccione Add Metric (Agregar métrica).
  2. Seleccione Stage Latency (Latencia de fase) como valor de Metric (Métrica) y Avg (Promedio) como valor de Aggregation (Agregación).
  3. Seleccione el botón Apply splitting y elija Component Type (Tipo de componente) para segmentar el gráfico en función de los distintos componentes de ingesta.
  4. Seleccione el botón Add filter (Agregar filtro) y filtre por los datos enviados a la base de datos de GitHub. Después de seleccionar los valores de filtro, haga clic fuera del selector de filtro para cerrarlo. Ahora el gráfico muestra la latencia de las operaciones de ingesta que se envían a la base de datos de GitHub en cada uno de los componentes a través de la ingesta a lo largo del tiempo:

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de la latencia de las fases de la ingesta desde la base de datos de GitHub, agregados por promedio y divididos por tipo de componente.

Esta es la información que se puede extraer de este gráfico:

  • La latencia en el componente Conexión de datos de Event Hubs es de aproximadamente 0 segundos. Esto tiene sentido, ya que Stage Latency (Latencia de fase) solo mide la latencia desde el momento en que Azure Data Explorer detecta un mensaje.
  • El tiempo más largo en el proceso de ingesta (aproximadamente 5 minutos) transcurre desde el momento en que el componente Batching Manager ha recibido los datos hasta el momento en que los recibe el componente Ingestion Manager. En este ejemplo, se usa la directiva de procesamiento por lotes predeterminada para la base de datos de GitHub. Como se indicó, el límite de tiempo de latencia de la directiva de procesamiento por lotes predeterminada es de 5 minutos, por lo que esto probablemente indica que casi todos los datos se procesaron por lotes por tiempo, y la mayoría del tiempo de latencia para la ingesta en cola se debe al propio procesamiento por lotes.
  • La latencia del motor de almacenamiento del gráfico representa la latencia hasta que los datos se almacenan en Azure Data Explorer Storage Engine y está listos para su consulta. Puede ver que la latencia total media desde el momento en que Azure Data Explorer detectó los datos hasta que están listas para la consulta es de 5,2 minutos.

Latencia de detección

Si usa la ingesta con conexiones de datos, es posible que desee calcular la latencia ascendente a Azure Data Explorer a lo largo del tiempo, ya que también puede producirse una latencia prolongada antes de que Azure Data Explorer obtenga los datos para la ingesta. Para ello, puede usar la métrica Discovery Latency (Latencia de detección).

  1. Seleccione + Nuevo gráfico.
  2. Seleccione Discovery Latency (Latencia de detección) como valor de Metric (Métrica) y Avg (Promedio) como valor de Aggregation (Agregación).
  3. Seleccione el botón Apply splitting y elija Component Type (Tipo de componente) para segmentar el gráfico en función de los distintos tipos de componentes de la conexión de datos. Después de seleccionar los valores de separación, haga clic fuera del selector de divisiones para cerrarlo.

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de latencia de detección para la ingesta de la base de datos de GitHub agregada por promedio y dividida por tipo de componente.

  • Puede ver que, durante la mayor parte del tiempo, la latencia de detección está próxima a 0 segundos, lo que indica que Azure Data Explorer obtuvo los datos justo después de que se pusieran en cola. El pico más alto, de aproximadamente 300 milisegundos, se produce aproximadamente el 13 de febrero a las 14:00, lo que indica que en ese momento el clúster de Azure Data Explorer recibió los datos aproximadamente 300 milisegundos después de que los datos se pusieran en cola.

Descripción del proceso de procesamiento por lotes

En la segunda fase del flujo de ingesta en cola, el componente batching Manager optimiza el rendimiento de ingesta mediante el procesamiento por lotes de los datos que recibe en función de la directiva de procesamiento por lotes de ingesta.

El siguiente conjunto de métricas le ayuda a saber cómo se van a procesar por lotes los datos durante la ingesta:

  • Lotes procesados: el número de lotes completados para la ingesta.
  • Tamaño del lote: el tamaño estimado de los datos sin comprimir en un lote agregado para la ingesta.
  • Duración del lote: la duración de cada lote individual desde que se abre hasta que se sella.
  • Recuento de blobs por lote: el número de blobs de un lote completado para la ingesta.

Lotes procesados.

Empecemos con una vista general del proceso de procesamiento por lotes. Para ello, examinaremos la métrica Batches processed (Lotes procesados).

  1. En el panel Metrics (Métricas) de Azure Monitor, seleccione Add Metric (Agregar métrica).
  2. Seleccione Batches Processed (Lotes procesados) como valor de Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación).
  3. Seleccione el botón Apply splitting (Aplicar separación) y elija Batching Type (Tipo de procesamiento por lotes) para segmentar el gráfico en función del motivo por el que se selló el lote. Para obtener una lista completa de los tipos de procesamiento por lotes, consulte Tipos de procesamiento por lotes.
  4. Seleccione el botón Add filter (Agregar filtro ) y filtre por los lotes enviados a la base de datos de GitHub. Después de seleccionar los valores de filtro, haga clic fuera del selector de filtro para cerrarlo.

El gráfico muestra el número de lotes sellados con los datos enviados a la base de datos de GitHub a lo largo del tiempo, divididos por el valor de Batching Type (Tipo de procesamiento por lotes).

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de lotes procesados para la ingesta desde la base de datos de GitHub agregada por suma y división por tipo de procesamiento por lotes.

  • Tenga en cuenta que hay entre 2 y 4 lotes por unidad de tiempo a lo largo del tiempo y que todos los lotes se sellan por tiempo en función de lo que se haya estimado en la sección Stage Latency (Latencia de fase), donde puede ver que se tardan unos 5 minutos en procesar los datos por lotes en función de la directiva de procesamiento por lotes predeterminada.

Duración, tamaño y número de blobs del lote

Ahora vamos a caracterizar un poco más los lotes procesados.

  1. Seleccione el botón + Add Chart ( + Agregar gráfico) en todos los gráficos para crear más gráficos para los valores de Metric (Métrica) Batch Duration (Duración de lote), Batch Size (Tamaño de lote) y Batch Blob Count (Número de blobs de lote).
  2. Use Avg (Promedio) como valor de Aggregation (Agregación).
  3. Como en el ejemplo anterior, seleccione el botón Add filter (Agregar filtro) y filtre por los datos enviados a la base de datos de GitHub.

Captura de pantalla del panel Metrics (Métricas) de Azure Portal que muestra gráficos de los valores de recuento de blobs del lote, duración del lote y métricas del tamaño del lote, para la ingesta desde la base de datos de GitHub agregada por promedio y dividida por tipo de procesamiento por lotes.

En los gráficos de Batch Duration (Duración de lote), Batch Size (Tamaño de lote) y Batch Blob Count (Recuento de blobs por lotes), podemos extraer algunas conclusiones:

  • La duración media del lote es de 5 minutos (según la directiva de procesamiento por lotes predeterminada). Téngalo en cuenta al examinar la latencia total de ingesta.

  • En el gráfico Batch size (Tamaño del lote), se puede ver que el tamaño medio de los lotes oscila entre 200 y 500 MB con el tiempo. El tamaño óptimo de los datos que se van a ingerir es de 1 GB de datos sin comprimir y la directiva de procesamiento por lotes predeterminada también define este tamaño como condición de sellado. Como no hay 1 GB de datos para procesar por lotes con el tiempo, no vemos ningún lote sellado por tamaño.

  • El número medio de blobs en los lotes es de, aproximadamente, 160 blobs a lo largo del tiempo, pero luego disminuye a entre 60 y 120 blobs. Según la directiva de procesamiento por lotes predeterminada, un lote se puede sellar cuando el número de blobs es de 1000. Como no llegamos a este número, no vemos lotes sellados por recuento.

Comparación de los eventos recibidos con los eventos enviados para la ingesta

Al aplicar el centro de eventos, el centro de IoT o la ingesta de Event Grid, puede ser útil comparar el número de eventos recibidos por Azure Data Explorer con el número de eventos enviados desde el origen de eventos a Azure Data Explorer. Las Events Received (Eventos recibidos), Events Processed (Eventos procesados) y Events Dropped (Eventos eliminados) permiten realizar esta comparación.

Eventos recibidos

  1. En el panel Metrics (Métricas) de Azure Monitor, seleccione Add Metric (Agregar métrica).
  2. Seleccione Events Received (Eventos recibidos) como valor de Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación).
  3. Seleccione el botón Add filter (Agregar filtro), que se encuentra encima del gráfico, y elija el valor Component Name (Nombre de componente) de Property (Propiedad) para filtrar los eventos recibidos por una conexión de datos específica definida en el clúster. En este ejemplo, se filtra por la conexión de datos GitHubStreamingEvents. Después de seleccionar los valores de filtro, haga clic fuera del selector de filtro para cerrarlo.

Ahora, el gráfico muestra el número de eventos recibidos por la conexión de datos seleccionada a lo largo del tiempo:

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico de los eventos recibidos durante la ingesta de la base de datos de GitHub agregada a lo largo del tiempo.

  • En este gráfico, la conexión de datos GitHubStreamingEvents recibe entre 200 y 500 eventos por unidad de tiempo a lo largo del tiempo.

Eventos procesados y eventos eliminados

Para ver si Azure Data Explorer ha eliminado eventos, use las métricas Events Processed (Eventos procesados) y Events Dropped (Eventos eliminados).

  1. En el gráfico que ya ha creado, seleccione Add metric (Agregar métrica).
  2. Seleccione Events Processed (Eventos procesados) como valor de Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación).
  3. Vuelva a seleccionar Add metric (Agregar métrica) y seleccione Events Dropped (Eventos eliminados) como valor de Metric (Métrica) y Sum (Suma) como valor Aggregation (Agregación).

El gráfico muestra ahora el número de eventos que se recibieron, procesaron y eliminaron por la conexión de datos GitHubStreamingEvents a lo largo del tiempo.

Captura de pantalla del panel Métricas de Azure Portal en la que se muestra un gráfico con gráficos de los eventos recibidos, procesados y eliminados durante la ingesta de la base de datos de GitHub agregada a lo largo del tiempo.

  • La conexión de datos procesó correctamente casi todos los eventos recibidos. Hay un evento descartado, que es compatible con el resultado de la ingesta con errores debido a una solicitud mala que vimos al ver la métrica de resultado de ingesta.

Comparación de los eventos recibidos en Azure Data Explorer con los mensajes salientes de Event Hubs

También puede comparar el número de eventos recibidos con el número de eventos enviados desde Event Hubs a Azure Data Explorer, mediante la comparación de las métricas Events Received (Eventos Recibidos) y Outgoing Messages (Mensajes salientes).

  1. En el gráfico que ya ha creado para Events Received (Eventos recibidos) seleccione Add metric (Agregar métrica).

  2. Seleccione Ámbito y, en el cuadro de diálogo Seleccionar un ámbito, busque y seleccione el espacio de nombres de Event Hubs que envía datos a la conexión de datos.

    Captura de pantalla del cuadro de diálogo Seleccionar un ámbito en Azure Portal, en la que se muestra una búsqueda de github4demo en la lista de espacios de nombres de Event Hubs.

  3. Seleccione Aplicar.

  4. Seleccione Outgoing Messages (Mensajes salientes) como valor Metric (Métrica) y Sum (Suma) como valor de Aggregation (Agregación).

Haga clic fuera de la configuración para obtener el gráfico completo que compara el número de eventos procesados por la conexión de datos de Azure Data Explorer con el número de eventos enviados desde Event Hubs.

Captura de pantalla del panel Métricas de Azure Portal que muestra un gráfico con gráficos para todos los eventos recibidos, procesados, eliminados y durante la ingesta de la base de datos de GitHub agregada a lo largo del tiempo.

  • Observe que la conexión de datos de Azure Data Explorer procesó correctamente todos los eventos que se enviaron desde Event Hubs.
  • Si tiene más de un centro de eventos en el espacio de nombres de Event Hubs, debe filtrar la métrica Outgoing Messages (Mensajes salientes) por la dimensión Entity Name (Nombre de entidad) para obtener solo los datos del centro de eventos deseado en el espacio de nombres de Event Hubs.

Nota:

No hay ninguna opción para supervisar el mensaje saliente por grupo de consumidores. La métrica Outgoing Messages (Mensajes salientes) cuenta el número total de mensajes consumidos por todos los grupos de consumidores. Por tanto, si tiene pocos grupos de consumidores en Event Hubs, es posible que tenga un número mayor en Outgoing Messages (Mensajes salientes) que en Events Received (Eventos recibidos).

Contenido relacionado