Monitorizar o processamento de eventos sem servidor

Este artigo fornece orientações sobre a monitorização de arquiteturas baseadas em eventos sem servidor .

A monitorização fornece informações sobre o comportamento e o estado de funcionamento dos seus sistemas. Ajuda-o a criar uma vista holística do ambiente, a obter tendências históricas, a correlacionar diversos fatores e a medir as alterações no desempenho, no consumo ou na taxa de erros. Pode utilizar a monitorização para definir alertas quando ocorrem condições que possam afetar a qualidade do seu serviço ou quando surgem condições de interesse específico para o seu ambiente específico.

Este artigo demonstra a utilização do Azure Monitor para monitorizar uma aplicação sem servidor criada com os Hubs de Eventos e Funções do Azure. Aborda métricas úteis para monitorizar, descreve como integrar com o Application Insights e capturar métricas personalizadas e fornece exemplos de código.

Pressupostos

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

• Os eventos chegam às Hubs de Eventos do Azure.
• É acionada uma Aplicação de Funções para processar o evento.
• O Azure Monitor está disponível para utilização com a sua arquitetura.

Métricas do Azure Monitor

Primeiro, temos de decidir que métricas serão necessárias antes de podermos começar a formular informações úteis sobre a arquitetura. Cada recurso executa tarefas diferentes e, por sua vez, gera métricas diferentes.

Estas métricas do Hub de Eventos terão interesse em capturar informações úteis:

• Pedidos recebidos
• Pedidos de envio
• Pedidos limitados
• Pedidos com êxito
• Mensagens recebidas
• Mensagens a enviar
• Mensagens capturadas
• Bytes de entrada
• Bytes de envio
• Bytes capturados
• Erros de utilizador

Da mesma forma, estas métricas de Funções do Azure terão interesse em capturar informações úteis:

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

Utilizar o registo de diagnósticos para capturar informações

Quando analisadas em conjunto, as métricas acima podem ser utilizadas para formular e capturar as seguintes informações:

• Taxa de pedidos processados pelos Hubs de Eventos
• Taxa de pedidos processados por Funções do Azure
• Débito total do Hub de Eventos
• Erros de utilizador
• Duração do Funções do Azure
• Latência ponto a ponto
• Latência em cada fase
• Número de mensagens perdidas
• Número de mensagens processadas mais do que uma vez

Para garantir que os Hubs de Eventos capturam as métricas necessárias, primeiro temos de ativar os registos de diagnóstico (que estão desativados por predefinição). Em seguida, temos de selecionar os registos pretendidos e configurar a área de trabalho do Log Analytics correta como o destino para os mesmos.

As categorias de registos e métricas em que estamos interessados são:

• OperationalLogs
• Caixas de Dimensionamento Automático
• KafkaCoordinatorLogs (para cargas de trabalho do Apache Kafka)
• KafkaUserErrorLogs (para cargas de trabalho do Apache Kafka)
• EventHubVNetConnectionEvent
• AllMetrics

A documentação do Azure fornece instruções sobre como Configurar registos de diagnóstico para um hub de eventos do Azure. A captura de ecrã seguinte mostra um painel de configuração de definições de diagnóstico de exemplo com as categorias de registo e métricas corretas selecionadas e uma área de trabalho do Log Analytics definida como o destino. (Se um sistema externo estiver a ser utilizado para analisar os registos, pode ser utilizada a opção Transmitir para um hub de eventos .)

Nota

Para utilizar o diagnóstico de registo para capturar informações, deve criar hubs de eventos em espaços de nomes diferentes. Isto deve-se a uma restrição no Azure.

Os Hubs de Eventos definidos num determinado espaço de nomes dos Hubs de Eventos são representados nas métricas do Azure Monitor numa dimensão chamada EntityName. No portal do Azure, normalmente, os dados de um hub de eventos específico podem ser visualizados nessa instância do Azure Monitor. Contudo, quando os dados de métricas são encaminhados para o diagnóstico de registo, não existe atualmente uma forma de ver dados por hub de eventos ao filtrar a EntityName dimensão.

Como solução, a criação de hubs de eventos em diferentes espaços de nomes ajuda a tornar possível localizar métricas para um hub específico.

Utilizar o Application Insights

Pode ativar o Application Insights para capturar métricas e telemetria personalizada de Funções do Azure. Isto permite-lhe definir análises que se adequam às suas próprias finalidades, fornecendo outra forma de obter informações importantes para o cenário de processamento de eventos sem servidor.

Esta captura de ecrã mostra uma lista de exemplos de métricas e telemetria personalizadas no Application Insights:

Métricas personalizadas predefinidas

No Application Insights, as métricas personalizadas para Funções do Azure são armazenadas na customMetrics tabela. Inclui os seguintes valores, distribuídos por uma linha cronológica para diferentes instâncias de função:

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

Estas métricas podem ser utilizadas para calcular eficazmente as médias agregadas em várias instâncias de função que são invocadas numa execução.

Esta captura de ecrã mostra o aspeto destas métricas personalizadas predefinidas quando visualizadas no Application Insights:

Mensagens personalizadas

As mensagens personalizadas registadas no código da Função do Azure (com o ILogger) são obtidas a partir da tabela do Application Insights traces .

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

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Eis um exemplo do aspeto de uma mensagem personalizada na interface do Application Insights:

Se a mensagem do Hub de Eventos recebida ou EventData[] estiver registada como parte desta mensagem personalizada ILogger , isso também será disponibilizado no Application Insights. Isto pode ser muito útil.

Para o nosso cenário de processamento de eventos sem servidor, registamos o corpo da mensagem serializada JSON que é recebido do hub de eventos. Isto permite-nos capturar a matriz de bytes não processados, juntamente com SystemPropertiesx-opt-sequence-number, x-opt-offsete x-opt-enqueued-time. Para determinar quando cada mensagem foi recebida pelo Hub de Eventos, a x-opt-enqueued-time propriedade é utilizada.

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 devolveria uma mensagem semelhante ao seguinte resultado de exemplo, que é registado por predefinição no Application Insights. As propriedades do Trigger Details podem ser utilizadas para localizar e capturar informações adicionais em torno das mensagens recebidas por PartitionId, Offsete SequenceNumber.

Resultado de exemplo 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 das Funções Java do Azure tem atualmente um problema que impede o PartitionID acesso ao e ao PartitionContext utilizar EventHubTrigger. Saiba mais neste relatório de problemas do GitHub.

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

No Application Insights, podemos ver toda a telemetria relacionada com uma transação específica ao efetuar uma consulta de Pesquisa de transações no valor da Operation Id transação. Isto pode ser especialmente útil para capturar os valores de percentil das horas médias das mensagens à medida que a transação se move através do pipeline de fluxo de eventos.

A captura de ecrã seguinte mostra um exemplo de Pesquisa de transações na interface do Application Insights. O pretendido Operation ID é introduzido no campo de consulta, identificado com um ícone de lupa (e mostrado aqui descrito numa caixa vermelha). Na parte inferior do painel principal, o Results separador mostra eventos correspondentes por ordem sequencial. Em cada entrada de evento, o Operation ID valor é realçado em azul escuro para uma verificação fácil.

Uma consulta gerada para um ID de operação específico terá o seguinte aspeto. Tenha em atenção que o Operation ID GUID está especificado na cláusula da where * has terceira linha. Este exemplo reduz ainda mais a consulta entre duas diferentes 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

Segue-se uma captura de ecrã do aspeto da consulta e dos respetivos resultados correspondentes na interface do Application Insights:

Capturar métricas personalizadas de Funções do Azure

Funções .NET

O registo estruturado é utilizado nas funções .NET do Azure para capturar dimensões personalizadas na tabela de rastreios do Application Insights. Estas dimensões personalizadas podem, em seguida, ser utilizadas para consultar dados.

Por exemplo, eis a instrução de registo 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 registos resultantes criados no Application Insights contêm os parâmetros acima como dimensões personalizadas, conforme mostrado nesta captura de ecrã:

Estes registos podem ser consultados da seguinte forma:

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 nestes testes, ativemos as definições de amostragem dos registos de Funções do Azure para o Application Insights com o host.json ficheiro, conforme mostrado abaixo. Isto significa que todas as estatísticas capturadas a partir do registo são consideradas valores médios e não contagens reais.

exemplo host.json:

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

Funções Java

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

Por exemplo, eis a instrução de registo no Java TransformingFunction:

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

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

Estes registos podem ser consultados da seguinte forma:

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 nestes testes, ativemos as definições de amostragem dos registos de Funções do Azure para o Application Insights com o host.json ficheiro, conforme mostrado abaixo. Isto significa que todas as estatísticas capturadas a partir do registo são consideradas valores médios e não contagens reais.

exemplo host.json:

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

Contribuidores

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

Autor principal:

• Rajasa Savant | Engenheiro de Software Sénior

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

Recursos relacionados

• O processamento de eventos sem servidor é uma arquitetura de referência que detalha uma arquitetura típica deste tipo, com exemplos de código e debate de considerações importantes.
• A eliminação de lotes e a filtragem no processamento de eventos sem servidor com os Hubs de Eventos descreve mais detalhadamente como funcionam estas partes da arquitetura de referência.
• O cenário de ligação privada no processamento de fluxos de eventos é uma ideia de solução para implementar uma arquitetura semelhante numa rede virtual (VNet) com pontos finais privados, de forma a melhorar a segurança.
• O Azure Kubernetes no processamento de fluxos de eventos descreve uma variação de uma arquitetura baseada em eventos sem servidor em execução no Azure Kubernetes com o dimensionador KEDA.