Supervisión del procesamiento de eventos sin servidor

En este artículo, se proporcionan instrucciones sobre la supervisión de arquitecturas sin servidor controladas por eventos.

La supervisión proporciona información sobre el comportamiento y el estado de los sistemas. Le ayuda a crear una vista holística del entorno, recuperar tendencias históricas, correlacionar diversos factores y medir los cambios en el rendimiento, el consumo o la tasa de errores. Puede usar la supervisión para definir alertas cuando se produzcan condiciones que puedan afectar a la calidad del servicio o cuando surjan condiciones de especial interés para su entorno específico.

En este artículo, se muestra el uso de Azure Monitor para supervisar una aplicación sin servidor creada con Event Hubs y Azure Functions. Describe métricas útiles para la supervisión y cómo realizar la integración con Application Insights y capturar métricas personalizadas, y proporciona ejemplos de código.

Supuestos

En este artículo, se supone que tiene una arquitectura como la descrita en la arquitectura de referencia para el procesamiento de eventos sin servidor. Básicamente:

• Los eventos llegan a Azure Event Hubs.
• Se desencadena una aplicación de funciones para controlar el evento.
• Azure Monitor está disponible para su uso con la arquitectura.

Métricas de Azure Monitor

En primer lugar, es necesario decidir qué métricas se necesitarán antes de empezar a formular información útil sobre la arquitectura. Cada recurso realiza tareas diferentes y, a su vez, genera métricas diferentes.

Estas métricas de Event Hub serán de interés para capturar información útil:

• Solicitudes entrantes
• Solicitudes salientes
• solicitudes limitadas
• Solicitudes correctas
• Mensajes entrantes
• Mensajes salientes
• Mensajes capturados
• Bytes de entrada
• Bytes de salida
• Bytes capturados
• Errores de usuario

De forma similar, estas métricas de Azure Functions serán de interés para capturar información útil:

• Recuento de ejecución de funciones
• Conexiones
• Datos de
• Salida de datos
• Errores de servidor HTTP
• Requests
• Solicitudes en la cola de la aplicación
• Tiempo de respuesta

Uso del registro de diagnóstico para capturar información

Cuando se analizan conjuntamente, las métricas anteriores se pueden usar para formular y capturar la siguiente información:

• Tasa de solicitudes procesadas por Event Hubs
• Tasa de solicitudes procesadas por Azure Functions
• Rendimiento total del centro de eventos
• Errores de usuario
• Duración de Azure Functions
• Latencia de un extremo a otro
• Latencia en cada fase
• Número de mensajes perdidos
• Número de mensajes procesados más de una vez

Para asegurarse de que Event Hubs captura las métricas necesarias, primero debemos habilitar los registros de diagnóstico (que están deshabilitados de manera predeterminada). A continuación, debemos seleccionar qué registros se desean y configurar el área de trabajo correcta de Log Analytics como destino para ellos.

Las categorías de registros y métricas que nos interesan son:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (para cargas de trabajo de Apache Kafka)
• KafkaUserErrorLogs (para cargas de trabajo de Apache Kafka)
• EventHubVNetConnectionEvent
• AllMetrics

En la documentación de Azure, se proporcionan instrucciones sobre cómo configurar los registros de diagnóstico para un centro de eventos de Azure. En la captura de pantalla siguiente se muestra un panel de configuración de diagnóstico de ejemplo con las categorías de métricas y de registro correctas seleccionadas, y un área de trabajo de Log Analytics establecida como destino. (Si se usa un sistema externo para analizar los registros, se puede usar la opción Transmitir a un centro de eventos en su lugar).

Nota

Para usar los diagnósticos de registro para capturar información, debe crear centros de eventos en distintos espacios de nombres. Esto se debe a una restricción en Azure.

El centro de eventos establecido en un espacio de nombres de Event Hubs determinado se representa en las métricas de Azure Monitor en una dimensión llamada EntityName. En Azure Portal, los datos de un centro de eventos específico normalmente se pueden ver en esa instancia de Azure Monitor. Pero cuando los datos de métricas se enrutan a los diagnósticos de registro, actualmente no hay ninguna manera de ver los datos por centro de eventos mediante el filtrado de la dimensión EntityName.

Como solución alternativa, la creación de centros de eventos en distintos espacios de nombres ayuda a que sea posible localizar las métricas de un centro específico.

Uso de Application Insights

Puede habilitar Application Insights para capturar métricas y datos de telemetría personalizados desde Azure Functions. Esto le permite definir análisis que se adapten a sus propios propósitos, proporcionando otra manera de obtener información importante para el escenario de procesamiento de eventos sin servidor.

En esta captura de pantalla, se muestra una lista de ejemplo de métricas personalizadas y datos de telemetría dentro de Application Insights:

Métricas personalizadas predeterminadas

En Application Insights, las métricas personalizadas de Azure Functions se almacenan en la tabla customMetrics. Incluye los siguientes valores, que se extienden en una escala de tiempo para diferentes instancias de funciones:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Estas métricas se pueden usar para calcular eficazmente los promedios agregados en las distintas instancias de funciones que se invocan en una ejecución.

En esta captura de pantalla, se muestra el aspecto de estas métricas personalizadas predeterminadas cuando se ven en Application Insights:

Mensajes personalizados

Los mensajes personalizados registrados en el código de la función de Azure (mediante ILogger) se obtienen de la tabla traces de Application Insights.

La tabla traces tiene las siguientes propiedades importantes (entre otras):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Este es un ejemplo del aspecto que podría tener un mensaje personalizado en la interfaz de Application Insights:

Si el mensaje entrante del centro de eventos o EventData[] se registra como parte de este mensaje de ILogger personalizado, también estará disponible en Application Insights. Esto puede resultar muy útil.

En nuestro escenario de procesamiento de eventos sin servidor, registramos el cuerpo del mensaje serializado en formato JSON que se recibe del centro de eventos. Esto nos permite capturar la matriz de bytes sin procesar, junto con elementos de SystemProperties como x-opt-sequence-number, x-opt-offset y x-opt-enqueued-time. Para determinar cuándo se ha recibido cada mensaje en el centro de eventos, se usa la propiedad x-opt-enqueued-time.

Consulta de ejemplo:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

La consulta de ejemplo devolvería un mensaje similar al siguiente resultado de ejemplo, que se registra de forma predeterminada en Application Insights. Las propiedades del elemento Trigger Details se pueden usar para buscar y capturar información adicional sobre los mensajes recibidos por cada PartitionId, Offset y SequenceNumber.

Resultado de ejemplo de la consulta de ejemplo:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Advertencia

La biblioteca para funciones de Java de Azure tiene actualmente un problema que impide el acceso a los elementos PartitionID y PartitionContext al usar EventHubTrigger. Más información en este informe de problemas de GitHub.

Seguimiento del flujo de mensajes mediante un identificador de transacción con Application Insights

En Application Insights, podemos ver todos los datos de telemetría relacionados con una transacción determinada mediante una consulta de búsqueda de transacciones con el valor de Operation Id de la transacción. Esto puede ser especialmente útil para capturar los valores de percentil de los tiempos medios de los mensajes a medida que la transacción se mueve en la canalización del flujo de eventos.

En la captura de pantalla siguiente, se muestra un ejemplo de búsqueda de transacciones en la interfaz de Application Insights. El valor deseado de Operation ID se introduce en el campo de consulta, identificado con un icono de lupa (y aquí se muestra resaltado en un recuadro rojo). En la parte inferior del panel principal, la pestaña Results (Resultados) muestra los eventos correspondientes en orden secuencial. En cada entrada de evento, el valor de Operation ID se resalta en color azul oscuro para facilitar la comprobación.

Una consulta generada para un identificador de operación específico tendrá un aspecto parecido al siguiente. Observe que el GUID Operation ID se especifica en la cláusula where * has de la tercera línea. En este ejemplo, se acota aún más la consulta entre dos elementos datetimes diferentes.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Esta es una captura de pantalla del aspecto que podrían tener la consulta y sus resultados correspondientes en la interfaz de Application Insights:

Captura de métricas personalizadas desde Azure Functions

Funciones de .NET

El registro estructurado se usa en las funciones de .NET de Azure para capturar dimensiones personalizadas en la tabla traces de Application Insights. Estas dimensiones personalizadas se pueden usar para consultar datos.

Por ejemplo, esta es la instrucción de registro de TransformingFunction de .NET:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

Los registros resultantes creados en Application Insights contienen los parámetros anteriores como dimensiones personalizadas, como se muestra en esta captura de pantalla:

Estos registros se pueden consultar de la siguiente manera:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Nota

Para asegurarnos de que no afectamos al rendimiento con estas pruebas, hemos activado la configuración de muestreo de los registros de la función de Azure para Application Insights mediante el archivo host.json, como se muestra a continuación. Esto significa que todas las estadísticas capturadas del registro se consideran valores medios y no recuentos reales.

Ejemplo de archivo host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Funciones de Java

Actualmente, no se admite el registro estructurado en las funciones de Java de Azure para capturar dimensiones personalizadas en la tabla traces de Application Insights.

Por ejemplo, esta es la instrucción de registro de TransformingFunction de Java:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

Los registros resultantes creados en Application Insights contienen los parámetros anteriores en el mensaje, como se muestra a continuación:

Estos registros se pueden consultar de la siguiente manera:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Nota

Para asegurarnos de que no afectamos al rendimiento con estas pruebas, hemos activado la configuración de muestreo de los registros de la función de Azure para Application Insights mediante el archivo host.json, como se muestra a continuación. Esto significa que todas las estadísticas capturadas del registro se consideran valores medios y no recuentos reales.

Ejemplo de archivo host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Rajasa Savant | Ingeniera sénior de software

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Recursos relacionados

• Procesamiento de eventos sin servidor es una arquitectura de referencia que detalla una arquitectura típica de este tipo, con ejemplos de código y análisis de las consideraciones importantes.
• Eliminación de la agrupación por lotes y filtrado en el procesamiento de eventos sin servidor con Event Hubs describe con más detalle cómo funcionan estas partes de la arquitectura.
• Procesamiento de flujos de eventos sin servidor en una red virtual con puntos de conexión privados es una idea de solución para implementar una arquitectura similar en una red virtual con puntos de conexión privados con el fin de mejorar la seguridad.
• Azure Kubernetes en el procesamiento de flujos de eventos describe una variante de una arquitectura sin servidor controlada por eventos que se ejecuta en Azure Kubernetes con el escalador KEDA.