Monitorizar Funções do Azure e Hubs de Eventos

A monitorização fornece informações sobre o comportamento e o estado de funcionamento dos seus sistemas e ajuda a criar uma visão holística do ambiente, tendências históricas, correlacionar diversos fatores e medir alterações no desempenho, no consumo ou na taxa de erros.

Funções do Azure oferece integração incorporada com o Application Insights. No Application Insights, pode obter informações como o número de instâncias da aplicação de funções ou a telemetria de pedidos e dependências de uma função. Ao trabalhar com Funções e Hubs de Eventos, o Application Insights também pode controlar as telemetrias de dependência de saída para o hub de eventos, calculando o tempo gasto na fila e mostrando o fluxo ponto a ponto do sistema ligado através dos Hubs de Eventos.

Esta secção apresenta funcionalidades e informações úteis que pode obter do Application Insights para a sua solução hubs de eventos e Funções.

Mapeamento de Aplicações

O Mapa da Aplicação mostra como os componentes num sistema estão a interagir entre si. Devido à telemetria de dependência que o Application Insights fornece, mapeia o fluxo de eventos entre Funções do Azure e Hubs de Eventos, incluindo a média de cada execução de funções e a duração média de um evento nos Hubs de Eventos, bem como mostra transações que contêm falhas marcadas a vermelho.

Depois de enviar a carga esperada para o seu sistema, pode aceder ao Application Insights no portal do Azure e, na barra lateral, selecione No Mapa da Aplicação. Eis um mapa que mostra três funções, três hubs de eventos e falhas aparentes ao escrever numa base de dados a jusante:

Detalhes da transação ponto a ponto

Os detalhes da transação ponto a ponto mostram como os componentes do sistema interagem entre si, por ordem cronológica. Esta vista também mostra quanto tempo um evento passou na fila. Também pode explorar a telemetria de cada componente a partir desta vista, o que facilita a resolução de problemas entre componentes no mesmo pedido quando ocorreu um problema.

Métricas e telemetria da plataforma

As métricas geradas pela plataforma no Azure Monitor para Hubs de Eventos e Funções do Azure podem ser utilizadas para monitorização geral do comportamento e do estado de funcionamento da solução:

• Hubs de Eventos do Azure métricas no Azure Monitor são do interesse de capturar informações úteis para os Hubs de Eventos (como agregações de Pedidos Recebidos, Pedidos Enviados, Pedidos Limitados, Pedidos Bem-sucedidos, Mensagens Recebidas, Mensagens Enviadas, Mensagens Capturadas, Bytes Recebidos, Bytes Enviados, Bytes Capturados, Erros do Utilizador).

• Funções do Azure métricas partilham muitas das métricas do Serviço de Aplicações do Azure, com a adição de Contagem de Execução de Funções e Unidades de Execução de Funções que podem ser utilizadas para compreender a utilização e o custo do plano de Consumo. Outras métricas de interesse são Ligações, Entrada de Dados, Saída de Dados, Conjunto de Trabalho de Memória Média, Contagem de Threads, Pedidos e Tempo de Resposta.

Funções do Azure integra-se com o Application Insights para fornecer telemetria e informações avançadas e detalhadas sobre o anfitrião de Funções e execuções de funções. Para saber mais, veja Analisar Funções do Azure telemetria no Application Insights. Ao utilizar o Application Insights para monitorizar uma topologia, existem várias configurações disponíveis. Para saber mais, veja Como configurar a monitorização para Funções do Azure.

Segue-se um exemplo de telemetria adicional para funções acionadas pelos Hubs de Eventos geradas na tabela de rastreios :

Trigger Details: PartionId: 6, Offset: 3985758552064-3985758624640, EnqueueTimeUtc: 2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00, SequenceNumber: 3712266-3712275, Count: 10

Estas informações requerem que utilize a extensão 4.2.0 ou posterior dos Hubs de Eventos. Estes dados são muito úteis, uma vez que contêm informações sobre a mensagem que acionou a execução da função e podem ser utilizados para consultas e informações. Inclui os seguintes dados para cada vez que a função é acionada:

• O ID da partição (6)
• O intervalo de deslocamento da partição (3985758552064-3985758624640)
• Intervalo de Tempo de Fila em UTC (2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00)
• O intervalo de números de sequência 3712266-3712275
• E a contagem de mensagens (10)

Veja a secção Exemplo de consultas do Application Insights para obter exemplos sobre como utilizar esta telemetria.

A telemetria personalizada também é possível para diferentes linguagens (biblioteca de classeS C#, C# Isolado, Script C#, JavaScript, Java, PowerShell e Python). Este registo é apresentado na tabela de rastreios no Application Insights. Pode criar as suas próprias entradas no Application Insights e adicionar dimensões personalizadas que podem ser utilizadas para consultar dados e criar dashboards personalizados.

Por fim, quando a aplicação de funções se liga a um hub de eventos através de um enlace de saída, as entradas também são escritas na tabela Dependências do Application Insights.

Para os Hubs de Eventos, a correlação é injetada no payload do evento e verá uma propriedade Diagnostic-Id em eventos:

Segue-se o formato de Contexto de Rastreio W3C que também é utilizado como ID da Operação e Ligações de Operação na telemetria criada pelas Funções, que permite ao Application Insights construir a correlação entre eventos do hub de eventos e execuções de funções, mesmo quando são distribuídos.

Exemplo de consultas do Application Insights

Segue-se uma lista de consultas úteis do Application Insights ao monitorizar os Hubs de Eventos com Funções do Azure. Esta consulta apresenta informações detalhadas sobre a função acionada pelo hub de eventos com a telemetria emitida pela extensão 4.2.0 e superior dos Hubs de Eventos.

Quando a amostragem é ativada no Application Insights, podem existir lacunas nos dados.

Informações detalhadas sobre o processamento de eventos

Os dados só são emitidos no formato correto quando é utilizada a distribuição em lote. A distribuição em lote significa que a função aceita vários eventos para cada execução, o que é recomendado para o desempenho. Não se esqueça das seguintes considerações:

• O dispatchTimeMilliseconds valor aproxima o período de tempo entre quando o evento foi escrito no hub de eventos e quando foi recolhido pela aplicação de funções para processamento.
• dispatchTimeMilliseconds pode ser negativo ou impreciso devido ao desfasamento do relógio entre o servidor do hub de eventos e a aplicação de funções.
• As partições dos Hubs de Eventos são processadas sequencialmente. Uma mensagem não será enviada para o código de função para processamento até que todas as mensagens anteriores tenham sido processadas. Monitorize o tempo de execução das suas funções, uma vez que tempos de execução mais longos causarão atrasos na distribuição.
• O cálculo utiliza enqueueTime da primeira mensagem no lote. Os tempos de envio podem ser mais baixos para outras mensagens no lote.
• dispatchTimeMilliseconds baseia-se no ponto anterior no tempo.
• Os números de sequência são por partição e o processamento duplicado pode ocorrer porque os Hubs de Eventos não garantem a entrega de mensagens exatamente uma vez.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| project timestamp, cloud_RoleInstance, operation_Name, processId =
customDimensions.ProcessId, partitionId, messageCount, sequenceNumberStart,
sequenceNumberEnd, enqueueTimeStart, enqueueTimeEnd, dispatchTimeMilliseconds

Visualização da latência da distribuição

Esta consulta visualiza a latência de distribuição de eventos de percentil 50 e 90 para uma determinada função acionada pelo hub de eventos. Veja a consulta acima para obter mais detalhes e notas.

traces
| where operation_Name == "<ENTER THE NAME OF YOUR FUNCTION HERE>"
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize percentiles(dispatchTimeMilliseconds, 50, 90) by bin(timestamp, 5m)
| render timechart

Resumo da latência da distribuição

Esta consulta é semelhante à acima, mas mostra uma vista de resumo.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| extend dispatchTimeMilliseconds = (timestamp - enqueueTimeStart) / 1ms
| summarize messageCount = sum(messageCount),
percentiles(dispatchTimeMilliseconds, 50, 90, 99, 99.9, 99.99) by operation_Name

Distribuição de mensagens entre partições

Esta consulta mostra como visualizar a distribuição de mensagens entre partições.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Distribuição de mensagens entre instâncias

Esta consulta mostra como visualizar a distribuição de mensagens entre instâncias.

traces
| where message startswith "Trigger Details: Parti"
| parse message with * "tionId: " partitionId:string ", Offset: "
offsetStart:string "-" offsetEnd:string", EnqueueTimeUtc: "
enqueueTimeStart:datetime "+00:00-" enqueueTimeEnd:datetime "+00:00, SequenceNumber: "
sequenceNumberStart:string "-" sequenceNumberEnd:string ", Count: "
messageCount:int
| summarize messageCount = sum(messageCount) by cloud_RoleInstance,
bin(timestamp, 5m)
| render areachart kind=stacked

Executar Instâncias e Instâncias Alocadas

Esta consulta mostra como visualizar o número de Funções do Azure instâncias que estão a processar eventos a partir dos Hubs de Eventos e o número total de instâncias (processamento e espera pela concessão). Na maioria das vezes, devem ser os mesmos.

traces
| where message startswith "Trigger Details: Parti"
| summarize type = "Executing Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
| union (
    traces
    | summarize type = "Allocated Instances", Count = dcount(cloud_RoleInstance) by
bin(timestamp, 60s)
)
| project timestamp, type, Count
| render timechart

Toda a Telemetria para uma Execução de Função específica

O campo operation_Id pode ser utilizado nas diferentes tabelas no Application Insights. Para os Hubs de Eventos acionados Funções do Azure a seguinte consulta, por exemplo, resultará nas informações do acionador, na telemetria dos registos no código da Função e nas dependências e exceções:

union isfuzzy=true requests, exceptions, traces, dependencies
| where * has "<ENTER THE OPERATION_ID OF YOUR FUNCTION EXECUTION HERE>"
| order by timestamp asc

Latência Ponto a Ponto para um Evento

Como a propriedade enqueueTimeUtc no rastreio de detalhes do acionador mostra a hora de colocação apenas do primeiro evento de cada lote processado pela função, pode ser utilizada uma consulta mais avançada para calcular a latência ponto a ponto dos eventos entre duas funções com Hubs de Eventos no meio. Esta consulta irá expandir as ligações de operação (se existirem) no pedido da segunda função e mapear a hora de fim para o mesmo ID de operação correspondente da hora de início da primeira função.

let start = view(){
requests
| where operation_Name == "FirstFunction"
| project start_t = timestamp, first_operation_Id = operation_Id
};
let link = view(){
requests
| where operation_Name == "SecondFunction"
| mv-expand ex = parse_json(tostring(customDimensions["_MS.links"]))
| extend parent = case(isnotempty(ex.operation_Id), ex.operation_Id, operation_Id )
| project first_operation_Id = parent, second_operation_Id = operation_Id
};
let finish = view(){
traces
| where customDimensions["EventName"] == "FunctionCompleted" and operation_Name
== "SecondFunction"
| project end_t = timestamp, second_operation_Id = operation_Id
};
start
| join kind=inner (
link
| join kind=inner finish on second_operation_Id
) on first_operation_Id
| project start_t, end_t, first_operation_Id, second_operation_Id
| summarize avg(datetime_diff('second', end_t, start_t))

Contribuidores

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

Autor principal:

• David Barkol | Especialista em Soluções Principais GBB

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

Passos seguintes

Para saber mais, considere rever estes artigos relacionados:

• Monitorizar o processamento de eventos sem servidor
• Analisar Funções do Azure telemetria no Application Insights
• Configurar a monitorização para Funções do Azure
• Analisar Funções do Azure telemetria no Application Insights
• Métricas no Azure Monitor – Hubs de Eventos do Azure
• Kusto Query Language

Recursos relacionados

• A monitorização do processamento de eventos sem servidor fornece orientações sobre a monitorização de arquiteturas condicionadas por eventos sem servidor.
• 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.