Surveiller Azure Functions et Event Hubs

La surveillance fournit des informations sur le comportement et l’intégrité de vos systèmes, et vous aide à créer une vue holistique de l’environnement, des tendances historiques, à mettre en corrélation différents facteurs et à mesurer les variations de performances, de consommation ou de taux d’erreur.

Azure Functions est intégré à Azure Application Insights. Depuis Application Insights, vous pouvez obtenir des informations telles que le nombre d’instances d’application de fonction ou de télémétrie de demande et de dépendance d’une fonction. Lorsque vous travaillez avec Functions et Event Hubs, Application Insights peut également suivre les télémétries de dépendance sortante vers Event Hub, en calculant le temps passé dans la file d’attente et en présentant le flux de bout en bout du système connecté via Event Hubs.

Cette section présente des fonctionnalités utiles et des informations que vous pouvez obtenir d’Application Insights pour votre solution Event Hubs ainsi que de Functions.

Mise en correspondance d'applications

La mise en correspondance d'applications montre comment les composants d’un système interagissent les uns avec les autres. En raison de la télémétrie des dépendances fournie par Application Insights, il cartographie le déroulement des événements entre Azure Functions et Event Hubs, notamment la moyenne de chaque exécution de fonction et la durée moyenne d’un événement dans Event Hubs, ainsi que l’indication des transactions qui contiennent des erreurs marquées en rouge.

Une fois que vous avez envoyé la charge attendue à votre système, vous pouvez accéder à Application Insights dans le portail Azureet dans la barre latérale, choisissez Mise en correspondance d'applications. Voici un mappage montrant trois fonctions, trois Event Hubs et des échecs évidents lors de l’écriture dans une base de données en aval :

Détails de la transaction de bout en bout

Les détails de la transaction de bout en bout montrent comment vos composants système interagissent les uns avec les autres, dans l’ordre chronologique. Cette vue indique également combien de temps un événement a passé dans la file d’attente. Vous pouvez également examiner la télémétrie de chaque composant à partir de cette vue, ce qui facilite le dépannage des composants au sein de la même requête lorsqu’un problème se produit.

Métriques de plateforme et données de télémétrie

Les métriques générées par la plateforme dans Azure Monitor pour Event Hubs et Azure Functions peuvent être utilisées pour la surveillance globale du comportement et de l’intégrité de la solution :

• Les métriques de Event hubs Azure dans Azure Monitor sont particulièrement intéressantes pour capturer des informations utiles pour Event Hubs (telles que les agrégats de demandes entrantes, les demandes sortantes, les demandes limitées, les demandes réussies, les messages entrants, les messages sortants, les messages capturés, les octets entrants, les octets sortants, les octets capturés, les erreurs utilisateur).

• Les métriques de Azure Functions partagent un grand nombre des mesures de Azure App Service, avec l’ajout du nombre d’exécutions de fonctions et des unités d’exécution de fonction qui peuvent être utilisées pour comprendre l'utilisation et le coût du plan de consommation. Les autres métriques intéressantes sont les connexions, les données entrantes, les données sortantes, la plage de travail moyenne de la mémoire, le nombre de threads, les requêtes et le temps de réponse.

Azure Functions s’intègre à Application Insights pour fournir des informations et des données de télémétrie avancées et détaillées sur l’hôte Function et les exécutions de fonction. Pour en savoir plus, consultez Analyser la télémétrie d’Azure Functions dans Application Insights. Lorsque vous utilisez Application Insights pour surveiller une topologie, plusieurs configurations sont disponibles. Pour plus d’informations, consultez Comment configurer la surveillance de Azure Functions.

Voici un exemple de télémétrie supplémentaire pour les fonctions déclenchées par Event Hubs générées dans la table des traces :

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

Ces informations requièrent l’utilisation de Event Hubs extension 4.2.0 ou d’une version ultérieure. Ces données sont très utiles car elles contiennent des informations sur le message qui a déclenché l’exécution de la fonction et peuvent être utilisées pour l’interrogation et l’analyse. Elles contiennent les données suivantes pour chaque déclenchement de la fonction :

• L’ID de partition (6)
• La plage de décalage de partition (3985758552064-3985758624640)
• L’intervalle de temps pour la mise en file d’attente en UTC (2022-10-31T12:51:58.1750000+00:00-2022-10-31T12:52:03.8160000+00:00)
• La plage de numéros de séquence 3712266-3712275
• Et le nombre de messages (10)

Reportez-vous à la section Exemple de requêtes Application Insights pour obtenir des exemples d’utilisation de cette télémétrie.

Une télémétrie personnalisée est également possible pour différents langages (bibliothèque de classes C#, C# isolé, script C#, JavaScript, Java, PowerShell et Python). Cette journalisation s’affiche dans la table des traces de Application Insights. Vous pouvez créer vos propres entrées dans Application Insights et ajouter des dimensions personnalisées qui peuvent être utilisées pour interroger des données et créer des tableaux de bord personnalisés.

Enfin, lorsque votre application de fonction se connecte à Event Hub à l’aide d’une liaison de sortie, les entrées sont également écrites dans la table de dépendances Application Insights.

Pour Event Hubs, la corrélation est injectée dans la charge utile d’événement et vous voyez une propriété Diagnostic-Id dans les événements :

Cela suit le format du contexte de suivi W3C qui sont également utilisés comme Id d’opération et liens d’opération dans les données de télémétrie créées par Functions, ce qui permet à Application Insights de construire la corrélation entre des événements Event Hub et des exécutions de fonctions, même lorsqu’ils sont distribués.

Exemple de requêtes Application Insights

Vous trouverez ci-dessous une liste de requêtes Application Insights utiles lors de la surveillance de Event Hubs avec Azure Functions. Cette requête affiche des informations détaillées pour la fonction déclenchée par Event Hub à l’aide des données de télémétrie émises par l’extension Event Hubs 4.2.0 et les versions ultérieures.

Lorsque l'échantillonnage est activé dans Application Insights, il peut y avoir des écarts dans les données.

Informations détaillées sur le traitement des événements

Les données sont émises dans le format approprié uniquement lorsque le dispatch par lot est utilisé. Le dispatch par lot signifie que la fonction accepte plusieurs événements pour chaque exécution, ce qui est recommandé pour les performances. Gardez à l’esprit les considérations suivantes :

• La valeur dispatchTimeMilliseconds est proche de la durée écoulée entre le moment où l’événement a été écrit dans Event Hub et le moment où il a été récupéré par l’application de fonction pour son traitement.
• dispatchTimeMilliseconds peut être négatif ou imprécis en raison de la dérive de l’horloge entre le serveur Event Hub et l’application de fonction.
• Les partitions Event Hubs sont traitées de manière séquentielle. Un message ne sera pas distribué au code de fonction pour traitement tant que tous les messages précédents n’ont pas été traités. Surveillez la durée d’exécution de vos fonctions, car des durées d’exécution plus longues entraînent des retards de dispatch.
• Le calcul utilise le enqueueTime du premier message du lot. Les durées de dispatch peuvent être inférieures pour d’autres messages du lot.
• dispatchTimeMilliseconds est basé sur le point dans le temps.
• Les numéros de séquence sont par partition et le traitement en double peut être effectué, car Event Hubs ne garantit pas la remise des messages en une seule fois.

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

Visualisation de la latence de dispatch

Cette requête visualise les 50e et 90e percentiles de latence de dispatch de l’événement pour une fonction déclenchée par Event Hub. Pour plus d’informations et des remarques, consultez la requête ci-dessus.

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

Résumé de la latence de dispatch

Cette requête est similaire à celle ci-dessus, mais elle présente une vue de résumé.

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

Distribution des messages sur les partitions

Cette requête montre comment visualiser la distribution des messages sur plusieurs partitions.

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

Distribution des messages sur les partitions

Cette requête montre comment visualiser la distribution des messages sur plusieurs instances.

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

Exécution des instances et des instances allouées

Cette requête montre comment visualiser le nombre d’instances Azure Functions qui traitent des événements à partir d’Event Hubs, ainsi que le nombre total d’instances (traitement et en attente de bail). La plupart du temps, elles doivent être identiques.

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

Toutes les données de télémétrie pour une exécution de fonction spécifique

Le champ operation_Id peut être utilisé dans les différentes tables d’Application Insights. Par exemple, pour Azure Functions déclenché par Event Hubs, la requête suivante génère les informations du déclencheur, les données de télémétrie à partir des journaux dans le code Function, ainsi que les dépendances et les exceptions :

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

Latence de bout en bout pour un événement

Étant donné que la propriété enqueueTimeUtc dans le suivi des détails du déclencheur affiche l’heure de mise en file d’attente uniquement pour le premier événement de chaque lot traité par la fonction, une requête plus avancée peut être utilisée pour calculer la latence de bout en bout des événements entre deux fonctions avec des Event Hubs intermédiaires. Cette requête développera les liens d’opération (le cas échéant) dans la requête de la deuxième fonction et mappera son heure de fin sur le même ID d’opération correspondant de l’heure de début de la première fonction.

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

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• David Barkol | PSS (Principal Solution Specialist) (GBB)

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Avant de continuer, consultez les articles suivants :

• Supervision du traitement d’événements serverless
• Analyser la télémétrie d’Azure Functions dans Application Insights
• Configurer l’analyse pour Azure Functions
• Analyser la télémétrie d’Azure Functions dans Application Insights
• Métriques dans Azure Monitor - Azure Event Hubs
• Langage de requête Kusto

Ressources associées

• Supervision du traitement d’événements serverless fournit des conseils sur la supervision des architectures serverless basées sur les événements.
• Traitement d’événements sans serveur est une architecture de référence détaillant une architecture typique de ce type, avec des exemples de code et des informations importantes à prendre en compte.