Surveillez les problèmes opérationnels dans votre espace de travail Azure Monitor Log Analytics
Pour maintenir les performances et la disponibilité de votre espace de travail Log Analytics dans Azure Monitor, vous devez être en mesure de détecter de façon proactive les problèmes qui surviennent. Cet article décrit comment superviser l’intégrité de votre espace de travail Log Analytics à l’aide des données du tableau Opération. Ce tableau est inclus dans chaque espace de travail Log Analytics. Il contient des messages d’erreur et des avertissements qui se produisent dans votre espace de travail. Nous vous recommandons de créer des alertes pour les problèmes dont le niveau est Avertissement et Erreur.
Autorisations requises
Vous devez disposer d’autorisations Microsoft.OperationalInsights/workspaces/query/*/read dans les espaces de travail Log Analytics que vous interrogez, comme fourni par le rôle intégré de Lecteur Log Analytics, par exemple.
Fonction _LogOperation
Les journaux Azure Monitor envoient des informations sur les éventuels problèmes au tableau Opération de l’espace de travail concerné. La fonction système _LogOperation est basée sur le tableau Opération et fournit un jeu d’informations simplifié pour l’analyse et la création d’alertes.
Colonnes
La fonction _LogOperation renvoie les colonnes du tableau suivant.
| Colonne | Description |
|---|---|
| TimeGenerated | Heure (UTC) à laquelle l’incident est survenu. |
| Category | Groupe de catégorie de l’opération. Peut être utilisé pour filtrer sur les types d’opérations et créer des audits et des alertes système plus précis. Consultez la section suivante pour obtenir la liste des catégories. |
| Opération | Description du type d’opération. L’opération peut indiquer qu’une des limites de Log Analytics a été atteinte, un problème lié au processus back-end ou tout autre message de service. |
| Level | Niveau de gravité du problème : - Info : Aucune attention particulière n’est requise. - Avertissement : Le processus ne s’est pas terminé comme prévu, votre attention est nécessaire. - Erreur : Le processus a échoué et une attention est nécessaire. |
| Détail | Description détaillée de l’opération, inclut le message d’erreur spécifique. |
| _ResourceId | ID de ressource de la ressource Azure liée à l’opération. |
| Computer | Nom de l’ordinateur si l’opération est liée à un agent Azure Monitor. |
| CorrelationId | Utilisé pour regrouper les opérations liées consécutives. |
Catégories
Le tableau suivant décrit les catégories de la fonction _LogOperation.
| Category | Description |
|---|---|
| Ingestion | Opérations faisant partie du processus d’ingestion de données. |
| Agent | Indique un problème lié à l’installation de l’agent. |
| Collecte de données | Opérations liées aux processus de collecte des données. |
| Ciblage de la solution | L’opération de type ConfigurationScope a été traitée. |
| Solution d’évaluation | Un processus d’évaluation a été exécuté. |
Ingestion
Les opérations d’ingestion sont les problèmes qui sont survenus pendant l’ingestion des données. Elles comprennent les notifications sur les limites atteintes de l’espace de travail Log Analytics. Les conditions d’erreur de cette catégorie peuvent indiquer une perte de données, il est donc intéressant de les superviser. Pour connaître les limites de service des espaces de travail Log Analytics, consultez Limites du service Azure Monitor.
Important
Si vous résolvez des problèmes de collecte de données pour un scénario qui utile une règle de collecte de données (DCR), comme l’agent Azure Monitor ou l’API Ingestion de journaux, consultez Superviser et résoudre les problèmes de collecte de données DCR dans Azure Monitor pour obtenir des informations de dépannage supplémentaires.
Opération : Collecte de données arrêtée
« Collecte de données arrêtée car la limite quotidienne de données gratuites a été atteinte. État de l’ingestion = Dépassement de quota »
Au cours des sept derniers jours, la collecte des journaux a atteint la limite quotidienne définie. La limite est définie car l’espace de travail est défini sur niveau gratuit ou la limite de collecte quotidienne a été configurée pour cet espace de travail. Une fois que votre collecte de données a atteint la limite définie, elle s’arrête automatiquement pour la journée et reprend uniquement pendant le jour de collecte suivant.
Actions recommandées :
- Dans la table
_LogOperation, recherchez les événements d’arrêt et de reprise de collecte :_LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Detail has "Data collection" - Créez une alerte sur l’événement Opération « Collecte de données arrêtée ». Cette alerte vous avertit quand la limite de collecte est atteinte.
- Les données collectées une fois que la limite de collecte quotidienne est atteinte sont perdues. Utilisez le volet Insights d’espace de travail pour passer en revue les taux d’utilisation de chaque source. Ou, vous pouvez décider de gérer votre volume de données quotidien maximal ou de changer de niveau tarifaire pour en choisir un adapté à votre modèle de taux de collecte.
- Le taux de collecte de données est calculé par jour et se réinitialise au début du jour suivant. Vous pouvez aussi superviser un événement de reprise de collecte en créant une alerte sur l’événement Opération « Reprise de la collecte des données ».
Opération : Taux d’ingestion
« Le débit du volume d’ingestion de données a dépassé le seuil dans votre espace de travail : {0:0,00} Mo par minute et les données ont été supprimées. »
Actions recommandées :
- Vérifiez si la table
_LogOperationcontient un événement de taux d’ingestion :_LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Operation has "Ingestion rate"
Un événement est envoyé à la table Opération dans l’espace de travail toutes les six heures, pendant que le seuil continue d’être dépassé. - Créez une alerte sur l’événement Opération « Collecte de données arrêtée ». Cette alerte vous avertit quand la limite est atteinte.
- Les données collectées alors que le taux d’ingestion a atteint 100 pourcent sont abandonnées et perdues. Utilisez le panneau Insights d’espace de travail pour passer en revue vos modèles d’utilisation et essayer de les réduire.
Pour plus d’informations, consultez :
Opération : Nombre maximal de colonnes de table
« Les données de type <nom de la table> ont été supprimées, car le nombre de champs du nouveau nombre de champs <nouveau nombre de champs> est supérieur à la limite de <limite actuelle du nombre de champs> champs personnalisés par type de données. »
Action recommandée : Pour les tables personnalisées, vous pouvez passer à l’analyse des données dans les requêtes.
Opération : Validation du contenu du champ
« Les valeurs <nom du champ> de type <nom de la table> des champs suivants ont été réduites à la taille maximale autorisée, soit <limite de taille des champs> octets. Ajustez votre entrée en conséquence. »
Un champ supérieur à la taille limite a été traité par les journaux Azure. Le champ a été réduit à la limite autorisée. Nous vous déconseillons d’envoyer des champs dépassant la limite autorisée, car cela entraîne une perte de données.
Actions recommandées :
Vérifiez la source du type de données concerné :
- Si les données sont envoyées par le biais de l’API du collecteur de données HTTP, vous avez besoin de modifier votre code\script pour fractionner les données avant qu’elles ne soient ingérées.
- Pour les journaux personnalisés, collectés par un agent Log Analytics, modifiez les paramètres de journalisation de l’application ou de l’outil.
- Pour tout autre type de données, déclenchez un cas de support. Pour plus d’informations, consultez Limites du service Azure Monitor.
Collecte de données
La section suivante fournit des informations sur la collecte de données.
Opération : Collecte des journaux d’activité Azure
« L’accès à l’abonnement a été perdu. Assurez-vous que l’abonnement <ID d’abonnement> est dans le locataire Microsoft Entra <ID de locataire>. Si l’abonnement est transféré vers un autre locataire, il n’y aura aucun impact sur les services, mais les informations du locataire peuvent prendre jusqu’à une heure pour se propager."
Dans certains cas, comme le déplacement d’un abonnement vers un autre locataire, les journaux d’activité Azure peuvent cesser de circuler dans l’espace de travail. Dans ces cas, vous avez besoin de reconnecter l’abonnement en suivant le processus décrit dans cet article.
Actions recommandées :
- Si l’abonnement mentionné dans le message d’avertissement n’existe plus, accédez au volet Connecteur du journal d’activité hérité sous Classique. Sélectionnez l’abonnement approprié, puis le bouton Déconnexion.
- Si vous n’avez plus accès à l’abonnement mentionné dans le message d’avertissement :
- Suivez l’étape précédente pour déconnecter l’abonnement.
- Pour continuer à collecter des journaux à partir de cet abonnement, contactez le propriétaire de l’abonnement pour corriger les autorisations et réactiver la collecte des journaux d’activité.
- Créez un paramètre de diagnostic pour envoyer le journal d’activité à un espace de travail Log Analytics.
Agent
La section suivante fournit des informations sur les agents.
Opération : Agent Linux
« Deux applications de configuration successives des paramètres OMS ont échoué. »
Les paramètres de configuration sur le portail ont changé.
Action recommandée : Ce problème est généré en cas de problème de récupération des nouveaux paramètres de configuration par l’agent. Pour atténuer ce problème, réinstallez l’agent.
Recherchez l’événement de l’agent dans la table _LogOperation :
_LogOperation | where TimeGenerated >= ago(6h) | where Category == "Agent" | where Operation == "Linux Agent" | distinct _ResourceId
La liste répertorie les ID de ressource pour lesquels l’agent dispose d’une mauvaise configuration. Pour atténuer le problème, réinstallez les agents listés.
Règles d'alerte
Utilisez les alertes de recherche dans les journaux dans Azure Monitor pour recevoir des notifications de manière proactive lorsqu’un problème est détecté dans votre espace de travail Log Analytics. Utilisez une stratégie qui vous permette de répondre en temps opportun aux problèmes tout en réduisant vos coûts. Votre abonnement sera facturé pour chaque règle d’alerte, comme indiqué dans Tarification Azure Monitor.
La stratégie recommandée consiste à commencer par deux règles d’alerte en fonction du niveau du problème. Utilisez une fréquence courte, par exemple toutes les 5 minutes, pour les erreurs et une fréquence plus longue, par exemple 24 heures, pour les avertissements. Dans la mesure où les erreurs indiquent une potentielle perte de données, vous pouvez les traiter rapidement pour réduire les pertes. Les avertissements indiquent généralement un problème qui ne nécessite pas une attention immédiate. Vous pouvez donc les examiner de façon quotidienne.
Pour créer les règles d’alerte de recherche dans les journaux, utilisez le processus décrit dans Créer, afficher et gérer les alertes de recherche dans les journaux à l’aide d’Azure Monitor. Les sections suivantes décrivent les détails pour chaque règle.
| Requête | Valeur du seuil | Période | Fréquence |
|---|---|---|---|
_LogOperation | where Level == "Error" |
0 | 5 | 5 |
_LogOperation | where Level == "Warning" |
0 | 1 440 | 1 440 |
Ces règles d’alerte répondent de la même manière à toutes les opérations indiquant une Erreur ou un Avertissement. Une fois familiarisé avec les opérations qui génèrent des alertes, vous pouvez avoir envie de répondre différemment à certaines opérations. Par exemple, vous pouvez envoyer des notifications à différentes personnes pour des opérations spécifiques.
Pour créer une règle d’alerte pour une opération spécifique, utilisez une requête comportant les colonnes Catégorie et Opération.
L’exemple suivant crée une alerte Avertissement lorsque le taux de volume d’ingestion atteint 80 pourcent de la limite :
- Cible : Sélectionnez votre espace de travail Log Analytics.
- Critères :
- Nom du signal : Recherche personnalisée dans les journaux
- Requête de recherche :
_LogOperation | where Category == "Ingestion" | where Operation == "Ingestion rate" | where Level == "Warning" - Basé sur : Nombre de résultats
- Condition : Supérieur à
- Seuil : 0
- Période : 5 (minutes)
- Fréquence : 5 (minutes)
- Nom de la règle d'alerte : limite de données quotidienne atteinte
- Gravité : avertissement (Sev 1)
L’exemple suivant crée une alerte Avertissement lorsque la collecte de données atteint la limite quotidienne :
- Cible : Sélectionnez votre espace de travail Log Analytics.
- Critères :
- Nom du signal : Recherche personnalisée dans les journaux
- Requête de recherche :
_LogOperation | where Category == "Ingestion" | where Operation == "Data collection Status" | where Level == "Warning" - Basé sur : Nombre de résultats
- Condition : Supérieur à
- Seuil : 0
- Période : 5 (minutes)
- Fréquence : 5 (minutes)
- Nom de la règle d'alerte : limite de données quotidienne atteinte
- Gravité : avertissement (Sev 1)
Étapes suivantes
- En savoir plus sur les alertes de recherche dans les journaux.
- Collectez des données d’audit de requête pour votre espace de travail.