Optimiser les requêtes d’alerte de recherche dans les journaux

Article
10/15/2024

Cet article explique comment écrire et convertir des alertes de recherche dans les journaux pour obtenir un niveau de performance optimal. Les requêtes optimisées réduisent la latence et la charge des alertes qui s’exécutent fréquemment.

Commencer à écrire une requête de journal d’alerte

Les requêtes d’alerte commencent en interrogeant les données du journal dans Log Analytics qui indiquent le problème. Pour comprendre ce que vous pouvez découvrir, consultez Utilisation de requêtes dans Azure Monitor Log Analytics. Vous pouvez également commencer à écrire votre propre requête.

Requêtes qui indiquent le problème et non l’alerte

Le flux d’alertes a été créé pour transformer les résultats qui indiquent le problème à une alerte. Par exemple, dans le cas d’une requête telle que :

SecurityEvent
| where EventID == 4624

Si l’intention de l’utilisateur est d’alerter, quand ce type d’événement se produit, la logique d’alerte ajoute count à la requête. La requête qui s’exécute sera :

SecurityEvent
| where EventID == 4624
| count

Il n’est pas nécessaire d’ajouter une logique d’alerte à la requête, et cela pourrait même poser des problèmes. Dans l’exemple précédent, si vous incluez count dans votre requête, vous obtiendrez toujours la valeur 1, car le service d’alerte effectue une opération count de count.

Éviter les opérateurs de limite et de prise

L’utilisation de limit et take dans les requêtes peut augmenter la latence et la charge des alertes, car les résultats ne sont pas cohérents sur la durée. Utilisez-les uniquement si nécessaire.

Journaliser les contraintes de requête

Les requêtes de journal dans Azure Monitor commencent par un opérateur de table, search ou union.

Les requêtes de règles d’alerte de recherche dans les journaux doivent toujours commencer par une table pour définir une étendue claire, ce qui améliore le niveau de performance des requêtes et la pertinence des résultats. Les requêtes dans les règles d’alerte s’exécutent fréquemment. L’utilisation de search et de union peut entraîner une surcharge excessive qui ajoute de la latence à l’alerte, car elle nécessite l’analyse de plusieurs tables. Ces opérateurs réduisent également la capacité du service d’alerte à optimiser la requête.

Nous ne prenons pas en charge la création ou la modification des règles d’alerte de recherche dans les journaux qui utilisent les opérateurs search ou union, sauf pour les requêtes inter-ressources.

Par exemple la requête d’alerte suivante a pour étendue la table SecurityEvent et recherche un ID d’événement spécifique. Il s’agit de la seule table que la requête doit traiter.

SecurityEvent
| where EventID == 4624

Les règles d’alerte de recherche dans les journaux utilisant des requêtes inter-ressources ne sont pas affectées par ce changement, car les requêtes inter-ressources utilisent un type de union qui limite l’étendue de la requête à des ressources spécifiques. L’exemple suivant serait une requête d’alerte de recherche dans les journaux valide :

union
app('00000000-0000-0000-0000-000000000001').requests,
app('00000000-0000-0000-0000-000000000002').requests,
workspace('00000000-0000-0000-0000-000000000003').Perf

Remarque

Les requêtes inter-ressources sont prises en charge dans la nouvelle API scheduledQueryRules. Si vous utilisez toujours l’API d’alerte Log Analytics héritée pour créer des alertes de recherche, consultez Mettre à niveau la gestion des règles héritées vers l’API de règles de requêtes planifiées Azure Monitor actuelle pour savoir comment effectuer ce changement.

Exemples

Les exemples suivants incluent des requêtes de journal qui utilisent search et union. Ils montrent les étapes que vous pouvez utiliser pour modifier les requêtes à utiliser dans les règles d'alerte.

Exemple 1

Vous voulez créer une règle d’alerte de recherche dans les journaux avec la requête suivante, qui récupère les informations de niveau de performance en utilisant search :

search *
| where Type == 'Perf' and CounterName == '% Free Space'
| where CounterValue < 30

Pour modifier cette requête, commencez par exécuter la requête suivante afin d’identifier la table à laquelle appartiennent les propriétés :
```
search *
| where CounterName == '% Free Space'
| summarize by $table
```
Le résultat de cette requête montre que la propriété CounterName provient de la table Perf.
Utilisez ce résultat pour créer la requête suivante, que vous utiliseriez pour la règle d’alerte :
```
Perf
| where CounterName == '% Free Space'
| where CounterValue < 30
```

Exemple 2

Vous voulez créer une règle d’alerte de recherche dans les journaux avec la requête suivante, qui récupère les informations de niveau de performance en utilisant search :

search ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage =avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Pour modifier cette requête, commencez par exécuter la requête suivante afin d’identifier la table à laquelle appartiennent les propriétés :
```
search ObjectName=="Memory" and CounterName=="% Committed Bytes In Use"
| summarize by $table
```
Le résultat de cette requête montre que les propriétés ObjectName et CounterName proviennent de la table Perf.

Utilisez ce résultat pour créer la requête suivante, que vous utiliseriez pour la règle d’alerte :

Perf
| where ObjectName =="Memory" and CounterName=="% Committed Bytes In Use"
| summarize Avg_Memory_Usage=avg(CounterValue) by Computer
| where Avg_Memory_Usage between(90 .. 95)

Exemple 3

Vous voulez créer une règle d’alerte de recherche dans les journaux avec la requête suivante qui utilise search et union pour récupérer les informations de niveau de performance :

search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| where Computer !in (
    union *
    | where CounterName == "% Processor Utility"
    | summarize by Computer)
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Pour modifier cette requête, commencez par exécuter la requête suivante afin d’identifier la table à laquelle appartiennent les propriétés dans la première partie de la requête :
```
search (ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total")
| summarize by $table
```
Le résultat de cette requête montre que toutes ces propriétés proviennent de la table Perf.
Utilisez union avec la commande withsource pour identifier la table source ayant contribué à chaque ligne :
```
union withsource=table *
| where CounterName == "% Processor Utility"
| summarize by table
```
Le résultat de cette requête montre que ces propriétés proviennent aussi de la table Perf.

Utilisez ces résultats pour créer la requête suivante, que vous utiliseriez pour la règle d’alerte :

Perf
| where ObjectName == "Processor" and CounterName == "% Idle Time" and InstanceName == "_Total"
| where Computer !in (
    (Perf
    | where CounterName == "% Processor Utility"
    | summarize by Computer))
| summarize Avg_Idle_Time = avg(CounterValue) by Computer

Exemple 4

Vous voulez créer une règle d’alerte de recherche dans les journaux avec la requête suivante qui joint les résultats de deux requêtes search :

search Type == 'SecurityEvent' and EventID == '4625'
| summarize by Computer, Hour = bin(TimeGenerated, 1h)
| join kind = leftouter (
    search in (Heartbeat) OSType == 'Windows'
    | summarize arg_max(TimeGenerated, Computer) by Computer , Hour = bin(TimeGenerated, 1h)
    | project Hour , Computer
) on Hour

Pour modifier la requête, commencez par exécuter la requête suivante afin d’identifier la table qui contient les propriétés figurant du côté gauche de la jointure :
```
search Type == 'SecurityEvent' and EventID == '4625'
| summarize by $table
```
Le résultat indique que les propriétés figurant du côté gauche de la jointure appartiennent à la table SecurityEvent.
Exécutez la requête suivante afin d’identifier la table qui contient les propriétés figurant du côté droit de la jointure :
```
search in (Heartbeat) OSType == 'Windows'
| summarize by $table
```
Le résultat indique que les propriétés figurant sur le côté droit de la jointure appartiennent à la table Heartbeat.