Durée d’ingestion de données de journal dans Azure Monitor

Article
10/15/2024

Azure Monitor est un service de données à grande échelle servant des milliers de clients qui envoient des téraoctets de données chaque mois à un rythme croissant. Les utilisateurs se demandent souvent quel est le délai nécessaire pour que les données de journal soient disponibles une fois qu’elles ont été collectées. Cet article explique les différents facteurs qui affectent cette latence.

Latence moyenne

La latence fait référence au délai qui s’écoule entre l’heure à laquelle les données sont créées sur le système analysé et l’heure à laquelle elles deviennent disponibles pour analyse dans Azure Monitor. Le temps de latence habituel pour ingérer des données de journal est compris entre 20 secondes et 3 minutes. La latence spécifique pour des données particulières varie en fonction de plusieurs facteurs qui sont expliqués dans cet article.

Facteurs qui affectent la latence

Le temps total d’ingestion pour un jeu de données particulier peut être divisé en plusieurs durées (voir ci-dessous) :

Délai de l’agent: délai nécessaire pour découvrir un événement, le collecter et l’envoyer au point de terminaison de collecte de données sous forme d’enregistrement de journal. Dans la plupart des cas, ce processus est géré par un agent. Davantage de latence peut être introduite par le réseau.
Délai du pipeline : délai nécessaire pour que le pipeline d’ingestion traite l’enregistrement de journal. Cette période inclut l’analyse des propriétés de l’événement et l’ajout éventuel des informations calculées.
Délai d’indexation : temps nécessaire à l’ingestion d’un enregistrement de journal dans un magasin Big Data Azure Monitor.

Des informations détaillées sur les différentes latences introduites dans ce processus sont décrites dans les sections suivantes.

Latence de collecte de l’agent

L’heure varie

Les solutions de gestion et les agents utilisent différentes stratégies pour collecter des données d’une machine virtuelle, ce qui peut affecter la latence. Quelques exemples spécifiques sont listés dans le tableau ci-dessous.

Type de données	Fréquence de collecte	Notes
Événements Windows, événements Syslog et métriques de performances	Collecte immédiate
Compteurs de performances Linux	Interrogation à intervalles de 30 secondes
Journaux IIS et journaux texte	Collecte après modification de leur timestamp	Pour les journaux IIS, cette planification varie selon le calendrier de substitution configuré sur IIS.
Solution Active Directory Replication	Évaluation tous les cinq jours	L’agent collecte les journaux uniquement lorsque l’évaluation est effectuée.
Solution d’Évaluation d’Active Directory	Évaluation hebdomadaire de votre infrastructure Active Directory	L’agent collecte les journaux uniquement lorsque l’évaluation est effectuée.

Fréquence de chargement de l’agent

Moins de 1 minute

Pour vous assurer que l’agent Log Analytics est léger, l’agent met en mémoire tampon les journaux d’activité et les charge régulièrement dans Azure Monitor. La fréquence de chargement varie entre 30 secondes et 2 minutes en fonction du type de données. La plupart des données sont chargées en moins d’une minute.

Réseau

Varie

Les conditions réseau peuvent affecter négativement la latence de ces données pour atteindre un point de terminaison de collecte de données.

Métriques Azure, journaux de ressources, journal d’activité

30 secondes à 15 minutes

Les données Azure prennent plus de temps avant d’être disponibles sur un point de terminaison de collecte de données pour leur traitement :

Les métriques de la plateforme Azure sont disponibles en moins d’une minute dans la base de données de métriques, mais il leur faut trois minutes de plus pour être exportées vers le point de terminaison de collecte de données.
Les journaux de ressources demandent généralement 30 à 90 secondes en plus selon le service Azure. Certains services Azure (plus précisément Azure SQL Database et le Réseau virtuel Azure) envoient actuellement leurs journaux toutes les cinq minutes. Nous travaillons actuellement à la diminution de ce délai. Pour examiner cette latence dans votre environnement, consultez la requête qui suit.
Les journaux d’activité sont disponibles pour analyse en 3 à 20 minutes.

Collecte des solutions de gestion

Varie

Certaines solutions ne collectent pas leurs données à partir d’un agent et peuvent utiliser une méthode de collecte qui introduit davantage de latence. Certaines solutions collectent des données à intervalles réguliers sans tenter d’effectuer une collecte en quasi-temps réel. Voici quelques exemples spécifiques :

La solution Microsoft 365 interroge les journaux d’activité à l’aide de l’API Management Activity, qui ne fournit actuellement aucune garantie concernant la latence en quasi-temps réel.
Les données des solutions Windows Analytics (Update Compliance, par exemple) sont collectées quotidiennement par la solution.

Pour déterminer la fréquence de collecte d’une solution, consultez la documentation de chaque solution.

Délai du processus de pipeline

30 à 60 secondes

Une fois que les données sont disponibles au point de terminaison de collecte de données, un délai de 30 à 60 secondes est nécessaire pour qu’elles puissent être interrogées.

Après que les enregistrements de journal sont ingérés dans le pipeline Azure Monitor (identifié dans la propriété _TimeReceived), ils sont écrits dans un stockage temporaire pour garantir l’isolation des locataires et empêcher la perte des données. Ce processus prend généralement entre 5 et 15 secondes en plus.

Certaines solutions implémentent des algorithmes plus lourds pour agréger les données et dériver des insights à mesure que les données affluent. Par exemple, Application Insights calcule les données de cartographie d’application, Azure Network Performance Monitor agrège les données entrantes toutes les 3 minutes, ce qui ajoute au final 3 minutes de latence.

Si la collecte de données inclut une transformation au moment de l’ingestion, cela ajoute une certaine latence au pipeline. Utilisez la métrique Logs Transformation Duration per Min (Durée de transformation des journaux par minute) pour monitorer l’efficacité de la requête de transformation.

Un autre processus qui ajoute une latence est le processus qui gère les journaux d’activité personnalisés. Dans certains cas, ce processus peut introduire quelques minutes de latence pour les journaux qui sont collectés à partir de fichiers par l’agent.

Provisionnement des nouveaux types de données personnalisées

Quand un type de données personnalisées est créé à partir d’un journal personnalisé ou de l’API Collecteur de données, le système crée un conteneur de stockage dédié. Cette surcharge ponctuelle se produit uniquement à la première apparition de ce type de données.

Protection en cas de pics de données

Généralement moins d’une minute, mais peut être plus

La priorité numéro 1 d'Azure Monitor est de s’assurer que les données client ne sont pas perdues. Le système dispose donc d’une protection intégrée pour les pics de données. Cette protection inclut des mémoires tampons pour garantir que le système reste toujours opérationnel, même sous une charge considérable. Sous une charge normale, ces contrôles se font en moins d’une minute. Dans des conditions extrêmes et lors de défaillances, ils peuvent avoir besoin de beaucoup plus de temps pour vérifier la sécurité des données.

Délai d’indexation

5 minutes ou moins

Chaque plateforme Big Data propose un équilibre entre la fourniture d’analytiques et de fonctionnalités de recherche avancées, et la fourniture d’un accès immédiat aux données. Avec Azure Monitor, vous pouvez exécuter de puissantes requêtes sur des milliards d’enregistrements et obtenir les résultats au bout de quelques secondes. Ces performances sont rendues possibles par l’infrastructure, qui transforme les données de façon spectaculaire lors de leur ingestion et les stocke dans des structures compactes uniques. Le système met en mémoire tampon les données jusqu’à ce que suffisamment de données soient disponibles pour créer ces structures. Ce processus doit être effectué avant que l’enregistrement de journal s’affiche dans les résultats de la recherche.

Ce processus prend environ cinq minutes avec un faible volume de données, mais il peut être plus rapide avec un débit de données plus élevé. Ce comportement semble illogique, mais ce processus permet l’optimisation de la latence pour les charges de travail de production impliquant de gros volumes.

Vérifier la durée d’ingestion

La durée d’ingestion peut varier pour différentes ressources dans différentes circonstances. Vous pouvez utiliser des requêtes de journal pour identifier un comportement spécifique de votre environnement. Le tableau suivant spécifie la manière dont vous pouvez déterminer les différentes heures d’un enregistrement lors de sa création et de son envoi à Azure Monitor.

Étape	Propriété ou fonction	Commentaires
Enregistrement créé au niveau de la source de données	TimeGenerated Si la source de données ne définit pas cette valeur, celle-ci est définie à la même heure que _TimeReceived.	Si, au moment du traitement, la valeur Time Generated est antérieure à deux jours, la ligne est supprimée.
Enregistrement reçu par le point de terminaison de collecte de données	_TimeReceived	Ce champ n’est pas optimisé pour le traitement de masse et ne doit pas être utilisé pour filtrer de grands jeux de données.
Enregistrement stocké dans l’espace de travail et disponible pour les requêtes	ingestion_time()	Nous vous recommandons d’utiliser `ingestion_time()` si vous voulez filtrer uniquement les enregistrements qui ont été ingérés durant une certaine fenêtre de temps. Dans ce type de cas, nous vous recommandons également d’ajouter un filtre `TimeGenerated` avec une plage plus grande.

Délais de latence d’ingestion

Vous pouvez mesurer la latence d’un enregistrement spécifique en comparant le résultat de la fonction ingestion_time() à la propriété TimeGenerated. Ces données peuvent être utilisées avec diverses agrégations afin de découvrir le comportement de latence d’ingestion. Examinez certains centiles de la durée d’ingestion pour obtenir des insights sur de gros volumes de données.

Par exemple, la requête suivante montre quels ordinateurs ont eu la durée d’ingestion la plus élevée durant les 8 heures précédentes :

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

Les contrôles de centile précédents conviennent pour rechercher des tendances générales en matière de latence. Pour identifier un pic à court terme en matière de latence, l’utilisation de la valeur maximale (max()) peut s’avérer plus efficace.

Si vous souhaitez explorer au niveau du détail la durée d’ingestion pour un ordinateur spécifique sur une période donnée, utilisez la requête suivante, qui affiche également les données de la journée précédente dans un graphe :

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

Utilisez la requête suivante pour afficher la durée d’ingestion des ordinateurs en fonction du pays ou de la région où ils se trouvent, d’après leur adresse IP :

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

Différents types de données provenant de l’agent peuvent avoir des latences d’ingestion différentes ; ainsi, les requêtes précédentes pourraient être utilisées avec d’autres types. Utilisez la requête suivante pour examiner la durée d’ingestion de divers services Azure :

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Utilisez la même logique de requête pour diagnostiquer les conditions de latence pour les données Application Insights :

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

Les deux requêtes ci-dessus peuvent être appairées à n’importe quelle autre table Application Insights autre que « requests » (demandes).

Ressources qui ne répondent plus

Dans certains cas, une ressource peut cesser d’envoyer des données. Pour savoir si une ressource envoie des données ou non, examinez son enregistrement le plus récent, identifiable par le champ TimeGenerated standard.

Utilisez la table Heartbeat pour vérifier la disponibilité d’une machine virtuelle, car une pulsation par minute est envoyée par l’agent. Utilisez la requête suivante pour lister les ordinateurs actifs qui n’ont pas signalé de pulsation récemment :

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc

Étapes suivantes

Consultez le contrat de niveau de service (SLA) pour Azure Monitor.

Partager via