Monitorar o processamento de eventos sem servidor

Este artigo fornece orientação sobre o monitoramento de arquiteturas controladas por eventos sem servidor.

O monitoramento fornece informações sobre o comportamento e a integridade de seus sistemas. Ele ajuda você a construir uma visão holística do ambiente, recuperar tendências históricas, correlacionar diversos fatores e medir mudanças no desempenho, consumo ou taxa de erro. Você pode usar o monitoramento para definir alertas quando ocorrem condições que podem afetar a qualidade do seu serviço ou quando surgem condições de interesse particular para o seu ambiente específico.

Este artigo demonstra o uso do Azure Monitor para monitorar um aplicativo sem servidor criado usando Hubs de Eventos e Azure Functions. Ele discute métricas úteis para monitorar, descreve como integrar com o Application Insights e capturar métricas personalizadas e fornece exemplos de código.

Suposições

Este artigo pressupõe que você tenha uma arquitetura como a descrita na arquitetura de referência de processamento de eventos sem servidor. Basicamente:

• Os eventos chegam aos Hubs de Eventos do Azure.
• Um aplicativo de função é acionado para manipular o evento.
• O Azure Monitor está disponível para uso com sua arquitetura.

Métricas do Azure Monitor

Primeiro, precisamos decidir quais métricas serão necessárias antes de começarmos a formular insights úteis sobre a arquitetura. Cada recurso executa tarefas diferentes e, por sua vez, gera métricas diferentes.

Essas métricas do Hub de Eventos serão de interesse para capturar informações úteis:

• Pedidos recebidos
• Pedidos de saída
• Solicitações limitadas
• Pedidos com êxito
• Mensagens recebidas
• Mensagens enviadas
• Mensagens capturadas
• Bytes de entrada
• Bytes de saída
• Bytes capturados
• Erros do utilizador

Da mesma forma, essas métricas do Azure Functions serão de interesse para capturar informações úteis:

• Contagem de execução de funções
• Ligações
• Dados em
• Saída de dados
• Erros do servidor HTTP
• Pedidos do
• Solicitações na fila de aplicativos
• Tempo de resposta

Usando o log de diagnóstico para capturar informações

Quando analisadas em conjunto, as métricas acima podem ser usadas para formular e capturar os seguintes insights:

• Taxa de solicitações processadas por Hubs de Eventos
• Taxa de solicitações processadas pelo Azure Functions
• Taxa de transferência total do Hub de Eventos
• Erros do utilizador
• Duração do Azure Functions
• Latência de ponta a ponta
• Latência em cada estágio
• Número de mensagens perdidas
• Número de mensagens processadas mais de uma vez

Para garantir que os Hubs de Eventos capturem as métricas necessárias, devemos primeiro habilitar os logs de diagnóstico (que são desabilitados por padrão). Em seguida, devemos selecionar quais logs são desejados e configurar o espaço de trabalho correto do Log Analytics como o destino para eles.

As categorias de log e métricas que nos interessam são:

• Logs Operacionais
• AutoScaleLogs
• KafkaCoordinatorLogs (para cargas de trabalho do Apache Kafka)
• KafkaUserErrorLogs (para cargas de trabalho do Apache Kafka)
• EventHubVNetConnectionEvent
• Todas as Métricas

A documentação do Azure fornece instruções sobre como configurar logs de diagnóstico para um hub de eventos do Azure. A captura de tela a seguir mostra um exemplo de painel de configuração de configuração de diagnóstico com as categorias de log e métricas corretas selecionadas e um espaço de trabalho do Log Analytics definido como destino. (Se um sistema externo estiver sendo usado para analisar os logs, a opção de Em vez disso, o fluxo para um hub de eventos pode ser usado.)

Nota

Para utilizar o diagnóstico de log para capturar insights, você deve criar hubs de eventos em namespaces diferentes. Isso ocorre devido a uma restrição no Azure.

Os Hubs de Eventos definidos em um determinado namespace de Hubs de Eventos são representados nas métricas do Azure Monitor sob uma dimensão chamada EntityName. No portal do Azure, os dados de um hub de eventos específico normalmente podem ser exibidos nessa instância do Azure Monitor. Mas quando os dados de métricas são roteados para o diagnóstico de log, atualmente não há como exibir dados por hub de eventos filtrando a EntityName dimensão.

Como solução alternativa, a criação de hubs de eventos em namespaces diferentes ajuda a possibilitar a localização de métricas para um hub específico.

A utilizar o Application Insights

Você pode habilitar o Application Insights para capturar métricas e telemetria personalizada do Azure Functions. Isso permite que você defina análises que atendam aos seus próprios propósitos, fornecendo outra maneira de obter informações importantes para o cenário de processamento de eventos sem servidor.

Esta captura de tela mostra um exemplo de listagem de métricas personalizadas e telemetria no Application Insights:

Métricas personalizadas padrão

No Application Insights, as customMetrics métricas personalizadas do Azure Functions são armazenadas na tabela. Ele inclui os seguintes valores, distribuídos por uma linha do tempo para diferentes instâncias de função:

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

Essas métricas podem ser usadas para calcular com eficiência as médias agregadas nas várias instâncias de função que são invocadas em uma execução.

Esta captura de tela mostra a aparência dessas métricas personalizadas padrão quando visualizadas no Application Insights:

Mensagens personalizadas

As mensagens personalizadas registradas no código da Função do Azure (usando o ILogger) são obtidas na tabela do Application Insights traces .

A traces tabela tem as seguintes propriedades importantes (entre outras):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Aqui está um exemplo de como uma mensagem personalizada pode parecer na interface do Application Insights:

Se a mensagem de entrada do Hub de Eventos ou EventData[] for registrada como parte dessa mensagem personalizada ILogger , isso também será disponibilizado no Application Insights. Isso pode ser muito útil.

Para nosso cenário de processamento de eventos sem servidor, registramos o corpo da mensagem serializada JSON recebida do hub de eventos. Isso nos permite capturar a matriz de bytes brutos, juntamente com SystemProperties like x-opt-sequence-number, x-opt-offset, e x-opt-enqueued-time. Para determinar quando cada mensagem foi recebida pelo Hub de Eventos, a x-opt-enqueued-time propriedade é usada.

Consulta de exemplo:

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"])

A consulta de exemplo retornaria uma mensagem semelhante ao resultado do exemplo a seguir, que é registrada por padrão no Application Insights. As propriedades do Trigger Details podem ser usadas para localizar e capturar informações adicionais sobre mensagens recebidas por PartitionId, Offsete SequenceNumber.

Exemplo de resultado da consulta de exemplo:

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

Aviso

A biblioteca do Azure Java Functions atualmente tem um problema que impede o acesso ao e ao usar EventHubTriggero PartitionIDPartitionContext . Saiba mais neste relatório de problemas do GitHub.

Rastreando o fluxo de mensagens usando um ID de transação com o Application Insights

No Application Insights, podemos visualizar toda a telemetria relacionada a uma transação específica fazendo uma consulta de pesquisa de transação sobre o valor da Operation Id transação. Isso pode ser especialmente útil para capturar os valores de percentil de tempos médios para mensagens à medida que a transação se move pelo pipeline de fluxo de eventos.

A captura de tela a seguir mostra um exemplo de pesquisa de transação na interface do Application Insights. O desejado Operation ID é inserido no campo de consulta, identificado com um ícone de lupa (e mostrado aqui delineado em uma caixa vermelha). Na parte inferior do painel principal, a guia mostra os Results eventos correspondentes em ordem sequencial. Em cada entrada de evento, o valor é realçado em azul escuro para facilitar a Operation ID verificação.

Uma consulta gerada para um ID de operação específico terá a seguinte aparência. Observe que o Operation ID GUID é especificado na cláusula da where * has terceira linha. Este exemplo restringe ainda mais a consulta entre dois arquivos .datetimes

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

Aqui está uma captura de tela de como a consulta e seus resultados correspondentes podem parecer na interface do Application Insights:

Capturar métricas personalizadas do Azure Functions

Funções .NET

O log estruturado é usado nas funções do .NET Azure para capturar dimensões personalizadas na tabela de rastreamentos do Application Insights. Essas dimensões personalizadas podem ser usadas para consultar dados.

Como exemplo, aqui está a instrução de log no .NET TransformingFunction:

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);

Os logs resultantes criados no Application Insights contêm os parâmetros acima como dimensões personalizadas, conforme mostrado nesta captura de tela:

Esses logs podem ser consultados da seguinte maneira:

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 garantir que não afetamos o desempenho nesses testes, ativamos as configurações de amostragem dos logs de Função do Azure para o Application Insights usando o host.json arquivo, conforme mostrado abaixo. Isso significa que todas as estatísticas capturadas do registro são consideradas valores médios e não contagens reais.

host.json exemplo:

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

Funções Java

Atualmente, o log estruturado não é suportado nas funções do Java Azure para capturar dimensões personalizadas na tabela de rastreamentos do Application Insights.

Como exemplo, aqui está a instrução log no Java TransformingFunction:

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

Os logs resultantes criados no Application Insights contêm os parâmetros acima na mensagem, conforme mostrado abaixo:

Esses logs podem ser consultados da seguinte maneira:

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 garantir que não afetamos o desempenho nesses testes, ativamos as configurações de amostragem dos logs de Função do Azure para o Application Insights usando o host.json arquivo, conforme mostrado abaixo. Isso significa que todas as estatísticas capturadas do registro são consideradas valores médios e não contagens reais.

host.json exemplo:

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

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Rajasa Savant - Brasil | Engenheiro de Software Sênior

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Recursos relacionados

• O processamento de eventos sem servidor é uma arquitetura de referência que detalha uma arquitetura típica desse tipo, com exemplos de código e discussão de considerações importantes.
• O cenário de link privado no processamento de fluxo de eventos é uma ideia de solução para implementar uma arquitetura semelhante em uma rede virtual (VNet) com pontos de extremidade privados, a fim de aumentar a segurança.
• O Kubernetes do Azure no processamento de fluxo de eventos descreve uma variação de uma arquitetura orientada a eventos sem servidor em execução no Kubernetes do Azure com escalador KEDA.