Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une règle de résumé vous permet d’agréger les données de journal à une cadence régulière et d’envoyer les résultats agrégés à une table de journaux personnalisée dans votre espace de travail Log Analytics. Utilisez des règles récapitulatives pour optimiser vos données pour :
Analyse et rapports, en particulier sur les jeux de données volumineux et les intervalles de temps, tels que l’analyse de la sécurité et des incidents ou les rapports d’activité mensuels et annuels. Les requêtes complexes sur un jeu de données volumineux expirent souvent. Il est plus facile et plus efficace d’analyser et de faire des rapports sur les données nettoyées et agrégées résumées.
Réduction des coûts liés aux journaux détaillés, que vous pouvez conserver aussi longtemps que nécessaire dans une table de journal de base moins coûteuse, tout en envoyant uniquement des données résumées vers une table Analytics pour l’analyse et les rapports.
Sécurité et confidentialité des données en supprimant ou en obfusquant les détails de confidentialité dans les données partageables résumées et en limitant l’accès aux tables avec des données brutes.
Cet article explique comment fonctionnent les règles de synthèse et comment définir et afficher des règles de synthèse, et fournit des exemples d’utilisation et d’avantages des règles de synthèse.
Voici une vidéo qui fournit une vue d’ensemble de quelques-uns des avantages des règles de résumé :
Fonctionnement des règles de synthèse
Les règles de synthèse effectuent directement le traitement par lots dans votre espace de travail Log Analytics. La règle de synthèse agrège les blocs de données, définis par taille de bac, en fonction d’une requête KQL et ingère à nouveau les résultats résumés dans une table personnalisée avec un plan de journal Analytics dans votre espace de travail Log Analytics.
Un diagramme 
Les règles récapitulatives agrègent les données de n’importe quelle table, que la table dispose d’un plan de données Analytique ou De base. Azure Monitor crée le schéma de table de destination en fonction de la requête que vous définissez. Si la table de destination existe déjà, Azure Monitor ajoute toutes les colonnes requises pour prendre en charge les résultats de la requête. Toutes les tables de destination incluent également un ensemble de champs standard avec des informations de règle récapitulatives, notamment :
-
_RuleName: règle récapitulative qui a généré l’entrée de journal agrégée. -
_RuleLastModifiedTime: lors de la dernière modification de la règle. -
_BinSize: intervalle d’agrégation. -
_BinStartTime: l’heure de début de l’agrégation.
Configurez jusqu’à 100 règles actives pour agréger des données de plusieurs tables et envoyer les données agrégées à des tables de destination distinctes ou à la même table.
Pour exporter des données résumées d’une table de journaux personnalisée vers un compte de stockage ou Event Hubs pour des intégrations supplémentaires, définissez une règle d’exportation de données.
Exemple : Synthétiser les données ContainerLogV2
Si vous surveillez des conteneurs, vous ingérer un grand volume de journaux détaillés dans la table ContainerLogV2.
Vous pouvez utiliser cette requête dans votre règle récapitulative pour agréger des enregistrements uniques dans les 60 minutes, en favorisant uniquement les données utiles pour l’analyse dans la table de destination :
ContainerLogV2
| summarize Count = count()
by
Computer,
ContainerName,
PodName,
PodNamespace,
LogSource,
LogLevel,
Message = tostring(LogMessage.Message)
Voici les données brutes de la table ContainerLogV2 :
Voici les données agrégées que la règle récapitulative envoie à la table de destination :
Au lieu de journaliser des centaines d’entrées similaires dans un délai d’une heure, la table de destination affiche le nombre de chaque entrée unique, comme défini dans la requête KQL. Définissez le plan de données de base sur la ContainerLogV2 table pour la rétention à faible coût des données brutes et utilisez les données résumées dans la table de destination pour vos besoins d’analyse.
Autorisations requises
| Action | Autorisations requises |
|---|---|
| Créer ou mettre à jour une règle récapitulative | DesMicrosoft.Operationalinsights/workspaces/summaryLogs/write autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Contributeur Log Analytics, par exemple |
| Créer ou mettre à jour une table de destination | DesMicrosoft.OperationalInsights/workspaces/tables/write autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Contributeur Log Analytics, par exemple |
| Activer l’opération de requête dans l’espace de travail | DesMicrosoft.OperationalInsights/workspaces/query/read autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Lecteur Log Analytics, par exemple |
| Interroger tous les tables d’activité dans l’espace de travail | DesMicrosoft.OperationalInsights/workspaces/query/*/read autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Lecteur Log Analytics, par exemple |
| Interroger les journaux d’activité dans une table | DesMicrosoft.OperationalInsights/workspaces/query/<table>/read autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Lecteur Log Analytics, par exemple |
| Journaux d’activité de requête dans une table (action de table) | DesMicrosoft.OperationalInsights/workspaces/tables/query/read autorisations sur l’espace de travail Log Analytics, telles que fournies par le rôle intégré Lecteur Log Analytics, par exemple |
| Utiliser des requêtes chiffrées dans un compte de stockage géré par le client |
Microsoft.Storage/storageAccounts/* autorisations pour le compte de stockage, comme indiqué par le rôle intégré contributeur de compte de stockage, par exemple |
Considérations relatives à l’implémentation
- Le nombre maximal de règles actives dans un espace de travail est de 100.
- Les règles récapitulatives sont actuellement disponibles uniquement dans le cloud public.
- La règle récapitulative traite les données entrantes et ne permet pas un intervalle de temps historique. Les données ne peuvent être traitées qu’à partir du passé récent jusqu’à 24 heures. Cela correspond à un maximum
binSizede 1440 minutes lorsqu’ilbinStartTimeest défini sur la fenêtre complète de 24 heures. - La création d’une règle récapitulative avec une requête portant sur un autre locataire dans Lighthouse n’est pas prise en charge.
- L’ajout d’une transformation d’espace de travail à la table de destination d’une règle de synthèse n’est pas pris en charge.
- L’utilisation de
union *etisfuzzy=truedans les requêtes de règles récapitulatives n’est pas prise en charge.
Modèle de tarification des règles de synthèse
Les règles récapitulatives n’entraînent aucun coût supplémentaire. Vous payez uniquement pour la requête et l’ingestion des résultats dans la table de destination, en fonction du plan de table de la table source dans laquelle vous exécutez la requête :
| Plan de table source | Coût de la requête | Résumé des résultats des coûts d’ingestion |
|---|---|---|
| Analyse de données | Aucun coût | Ingestion des journaux Analytics |
| Essentiel et Auxiliaire | Analyse de données | Ingestion des journaux Analytics |
Par exemple, le calcul du coût pour une règle horaire qui retourne 100 enregistrements par bac est :
| Plan de table source | Calcul mensuel des prix |
|---|---|
| Analyse de données | Prix d’ingestion x taille d’enregistrement x nombre d’enregistrements x 24 heures x 30 jours. |
| Essentiel et Auxiliaire | Prix de l’analyse de données x volume analysé + prix d’ingestion x taille d’enregistrement x nombre d’enregistrements x 24 heures x 30 jours. Pour une règle exécutée en continu, toutes les données entrantes vers la table source sont analysées. |
Pour plus d’informations, consultez Azure Monitor tarification.
Créer ou mettre à jour une règle récapitulative
Les opérateurs disponibles dans votre requête de règle de synthèse dépendent du plan de la table source dans la requête.
- Analytique : prend en charge tous les opérateurs et fonctions KQL, à l’exception des éléments suivants :
-
Requêtes inter-ressources, qui utilisent les expressions
workspaces(),app()etresource(), et les requêtes inter-services, qui utilisent les expressionsADX()etARG(). - Plugins qui remodèlent le schéma de données, y compris bag unpack, narrow et pivot.
-
Requêtes inter-ressources, qui utilisent les expressions
- Essentiel : prend en charge tous les opérateurs KQL sur une seule table. Joignez jusqu’à cinq tables Analytics à l’aide de l’opérateur de recherche .
- Fonctions : les fonctions définies par l’utilisateur ne sont pas prises en charge. Les fonctions système fournies par Microsoft sont prises en charge.
Les règles récapitulatives offrent les avantages les plus élevés en matière de coût et de requête lorsque la requête de règle inclut l’opérateur summarize et que le nombre de résultats ou le volume est réduit de manière significative. Par exemple, visez un volume de résultats de 0,01% ou moins de la source. Avant de créer une règle, testez la requête dans Log Analytics et vérifiez les éléments suivants :
- La requête produit les résultats et le schéma prévus.
- La requête n’atteint pas ou se rapproche des limites de l’API de requête. Si la requête est proche de ses limites, envisagez d’utiliser une valeur de
binSizeplus petite pour traiter moins de données par intervalle. En guise d’alternative, modifiez la requête pour retourner moins d’enregistrements ou moins de champs à volume élevé. - La taille de l’enregistrement dans les résultats est inférieure à 1 Mo.
Note
N’utilisez pas de filtre de temps dans une requête de règle de synthèse, car la requête fonctionne déjà sur l’intervalle de temps défini par la taille de la corbeille. Si vous ajoutez un filtre de temps, il est combiné à la taille du compartiment, ce qui aura pour effet que seule la période de temps qui se chevauche sera utilisée.
Lorsque vous mettez à jour une requête et que les résultats récapitulatives contiennent moins de champs, Azure Monitor ne supprime pas automatiquement les colonnes de la table de destination. Supprimez manuellement les colonnes de votre table si nécessaire.
Une fois que vous avez créé, mis à jour, démarré ou arrêté une règle, récupérez sa configuration et attendez jusqu’à ce qu’elle properties.provisioningState soit Succeeded avant d’apporter une autre modification. Une requête peut aboutir avec succès alors que la règle est toujours Updating.
Pour créer ou mettre à jour une règle récapitulative :
À partir du portail Azure, accédez à votre espace de travail Log Analytics.
Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
Sélectionnez l’onglet Règles de résumé .
Sélectionnez + Créer pour créer une règle récapitulative.
Renseignez le nom de la règle, la description et la table de destination, puis sélectionnez Suivant : Définir la logique de règle.
L’étape logique de règle démarre dans l’expérience de requête de Log Analytics. Créez et testez votre requête ici, puis sélectionnez Appliquer une fois qu’elle produit les résultats attendus.
Sélectionnez la valeur Run summary every qui correspond à
binSize, puis ajustez les autres options de planification selon vos besoins. Sélectionnez Suivant : Vérifier + créer.Passez en revue les paramètres de règle récapitulative, puis sélectionnez Créer.
Propriétés de la règle de résumé
Ce tableau décrit les paramètres disponibles pour la création et la gestion des règles de synthèse.
| Paramètre | Valeurs valides | Descriptif |
|---|---|---|
ruleType |
User ou System |
Spécifie le type de règle. - User: règles que vous définissez. - System : règles prédéfinies gérées par les services Azure. |
description |
Chaîne | Décrit la règle et sa fonction. Ce paramètre est utile lorsque vous avez plusieurs règles et que vous pouvez vous aider à gérer les règles. |
binSize |
20, 30, 60, 120, 180, 360, 720 ou 1440 (minutes) |
Définit l’intervalle d’agrégation et la plage de temps de rétrospection. Par exemple, si vous définissez "binSize": 120, vous pouvez obtenir des entrées pour 02:00 to 04:00 et 04:00 to 06:00. |
query |
Requête KQL (Kusto Query Language) | Définit la requête à exécuter dans la règle. Vous n’avez pas besoin de spécifier une plage de temps, car le binSize paramètre détermine l’intervalle d’agrégation, par exemple, 02:00 to 03:00 si "binSize": 60. Si vous ajoutez un filtre de temps dans la requête, l’intervalle de temps utilisé dans la requête est l’intersection entre le filtre et la taille de la corbeille. |
destinationTable |
tablename_CL | Spécifie le nom de la table de journaux personnalisée de destination. La valeur du nom doit avoir le suffixe _CL. Azure Monitor crée la table dans l'espace de travail, si elle n'existe pas déjà, en fonction de la requête que vous définissez dans la règle. Si la table existe déjà dans l’espace de travail, Azure Monitor ajoute les nouvelles colonnes introduites dans la requête. Si les résultats de résumé incluent un nom de colonne réservé , tel que TimeGenerated, _IsBillable, _ResourceId, TenantId ou Type - Azure Monitor ajoute le préfixe _Original aux champs d’origine pour conserver leurs valeurs d’origine. |
binDelay (facultatif) |
Nombres entiers (en minutes) | Définit un délai d’attente avant l’exécution du bin, généralement utile lorsqu'il est exécuté sur des données arrivant tardivement, également connu sous le nom de latence d’ingestion, et permet à la plupart des données d’arriver. Le délai par défaut est compris entre trois minutes et demi et 10 % de la valeur binSize. Si vous savez que les données que vous interrogez sont généralement ingérées avec un délai, définissez le paramètre binDelay avec la valeur de délai connue ou une valeur supérieure, jusqu’à 1440 minutes. Pour plus d’informations, consultez Configurer le minutage d’agrégation.Dans certains cas, Azure Monitor peut commencer l’exécution de la corbeille légèrement après le délai défini pour garantir la fiabilité du service et la réussite des requêtes. |
retryBinStartTime |
DateHeure dans Format %Y-%n-%eT%H:%M %Z |
Relancez un bin en utilisant retryBinStartTime. Les autres définitions de la règle restent inchangées depuis la dernière mise à jour. La valeur choisie retryBinStartTime doit être après RuleLastModifiedTime et être comprise dans les divisions de binSize. Par exemple, si la règle binSize est de 20 minutes, vous pouvez définir retryBinStartTime la valeur « 2026-02-16T10:00:00Z », « 2026-02-16T10:20:00Z » ou « 2026-02-16T10:40:00Z ». |
binStartTime (facultatif) |
DateHeure dans Format %Y-%n-%eT%H:%M %Z |
Spécifie la date et l’heure de l’exécution initiale de la corbeille. La valeur peut commencer à la date de création de règle moins la valeur binSize, ou ultérieure et en heures entières. Par exemple, si datetime est 2023-12-03T12:13Z et binSize est de 1 440, la valeur de binStartTime valide la plus ancienne est 2023-12-02T13:00Z, et l’agrégation inclut les données journalisées entre 02T13:00 et 03T13:00. Dans ce scénario, les règles commencent à agréger une valeur 03T13:00 plus le délai par défaut ou spécifié. Le paramètre binStartTime est utile dans les scénarios de synthèse quotidiens. Supposons que vous êtes situé dans le fuseau horaire UTC-8 et que vous créez une règle quotidienne à 2023-12-03T12:13Z. Vous souhaitez que la règle se termine avant de commencer votre journée à 8:00 (00:00 UTC). Définissez le paramètre binStartTime sur 2023-12-02T22:00Z. La première agrégation inclut toutes les données journalisées entre 02T :06:00 et 03T :06:00 heure locale, et la règle s’exécute en même temps quotidiennement. Pour plus d’informations, consultez Configurer le minutage d’agrégation.Lorsque vous mettez à jour des règles, choisissez l’une des options suivantes : - Utilisez la valeur binStartTime existante ou supprimez le paramètre binStartTime, auquel cas l’exécution continue en fonction de la définition initiale.- Mettez à jour la règle avec une nouvelle valeur binStartTime pour définir une nouvelle valeur datetime. |
name |
Chaîne | Spécifie le nom de la règle. Le nom doit être unique dans l’espace de travail et peut contenir des lettres, des chiffres, des traits de soulignement, des traits d’union et des points (aucun espace). La valeur du nom est utilisée dans le _RuleName champ de la table de destination. |
displayName (facultatif) |
Chaîne | Spécifie le nom d'affichage de la règle dans les expériences du portail Azure. |
timeSelector (facultatif) |
TimeGenerated |
Définit le champ timestamp que Azure Monitor utilise pour agréger des données. Par exemple, si vous définissez "binSize": 120, vous pouvez obtenir des entrées avec une valeur de TimeGenerated entre 02:00 et 04:00. |
Configurer le minutage d’agrégation
Par défaut, la règle récapitulative crée la première agrégation peu après l’heure entière suivante.
Le court délai ajouté par Azure Monitor tient compte de la latence d’ingestion, c’est-à-dire du délai entre le moment où les données sont créées dans le système surveillé et celui où elles deviennent disponibles pour l’analyse dans Azure Monitor. Par défaut, ce délai est compris entre trois minutes et demi et 10% de la valeur de taille du bac avant d’agréger chaque bac. Dans la plupart des cas, ce délai garantit qu’Azure Monitor agrège toutes les données enregistrées dans chaque période de corbeille.
Par exemple :
- Vous créez une règle de résumé avec une taille de bac de 30 minutes à 14:44. La première agrégation est générée à 15:04, soit l’heure entière suivante, plus 4 minutes de retard.
- Vous créez une règle de résumé avec une taille de compartiment de 720 minutes à 14:44. La première agrégation est générée à 16:12, soit l’heure entière suivante plus 72 minutes (10 % du délai de 720 compartiments).
Utilisez les paramètres binStartTime et binDelay pour modifier le minutage de la première agrégation et le délai ajouté par Azure Monitor avant chaque agrégation.
Les sections suivantes fournissent des exemples de minutage d’agrégation par défaut et les options de minutage d’agrégation plus avancées.
Utiliser le minutage d’agrégation par défaut
Dans cet exemple, la règle de résumé est créée le 2023-06-07 à 14:44 et Azure Monitor ajoute un délai par défaut de quatre minutes.
| binSize (minutes) | Exécution de la règle initiale | Première agrégation | Deuxième agrégation |
|---|---|---|---|
| 1440 | 2023-06-07 15:04 | 2023-06-06 15:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-08 15:00 |
| 720 | 2023-06-07 15:04 | 2023-06-07 03:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-08 03:00 |
| 360 | 2023-06-07 15:04 | 2023-06-07 09:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 21:00 |
| 180 | 2023-06-07 15:04 | 2023-06-07 12:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 18:00 |
| 120 | 2023-06-07 15:04 | 2023-06-07 13:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 17:00 |
| soixante | 2023-06-07 15:04 | 2023-06-07 14:00 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 16:00 |
| 30 | 2023-06-07 15:04 | 2023-06-07 14:30 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 15:30 |
| 20 | 2023-06-07 15:04 | 2023-06-07 14:40 - 2023-06-07 15:00 | 2023-06-07 15:00 - 2023-06-07 15:20 |
Définir des paramètres de minutage d’agrégation facultatifs
Dans cet exemple, la règle de résumé est créée le 2023-06-07 à 14:44, et la règle inclut ces paramètres de configuration avancés :
-
binStartTime: 2023-06-08 07:00 -
binDelay: 8 minutes
| binSize (minutes) | Exécution de la règle initiale | Première agrégation | Deuxième agrégation |
|---|---|---|---|
| 1440 | 2023-06-09 07:08 | 2023-06-08 07:00 - 2023-06-09 07:00 | 2023-06-09 07:00 - 2023-06-10 07:00 |
| 720 | 2023-06-08 19:08 | 2023-06-08 07:00 - 2023-06-08 19:00 | 2023-06-08 19:00 - 2023-06-09 07:00 |
| 360 | 2023-06-08 13:08 | 2023-06-08 07:00 - 2023-06-08 13:00 | 2023-06-08 13:00 - 2023-06-08 19:00 |
| 180 | 2023-06-08 10:08 | 2023-06-08 07:00 - 2023-06-08 10:00 | 2023-06-08 10:00 - 2023-06-08 13:00 |
| 120 | 2023-06-08 09:08 | 2023-06-08 07:00 - 2023-06-08 09:00 | 2023-06-08 09:00 - 2023-06-08 11:00 |
| soixante | 2023-06-08 08:08 | 2023-06-08 07:00 - 2023-06-08 08:00 | le 8 juin 2023 de 8h00 à 9h00 |
| 30 | 2023-06-08 07:38 | 2023-06-08 07:00 – 2023-06-08 07:30 | 2023-06-08 07:30 - 2023-06-08 08:00 |
| 20 | 2023-06-08 07:28 | 2023-06-08 07:00 - 2023-06-08 07:20 | 2023-06-08 07:20 - 2023-06-08 07:40 |
Afficher toutes les règles récapitulatives
Affichez ou répertoriez toutes les règles de synthèse dans votre espace de travail.
La displayName propriété de la règle récapitulative visible dans le portail Azure est différente de la name propriété utilisée dans les appels d’API, en particulier si vous avez créé la règle via le portail. La name propriété est l’identificateur unique de la règle et est utilisée dans les appels d’API pour gérer la règle. Il displayName s’agit d’un nom convivial affiché dans le portail Azure pour faciliter l’identification.
- À partir du portail Azure, accédez à votre espace de travail Log Analytics.
- Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
- Sélectionnez l’onglet Règles de résumé .
Afficher une règle récapitulative
Affichez ou mettez à jour la configuration d’une règle récapitulative spécifique.
À partir du portail Azure, accédez à votre espace de travail Log Analytics.
Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
Sélectionnez l’onglet Règles de résumé .
Sélectionnez les points de suspension (...) en regard de la règle récapitulative que vous souhaitez afficher dans la liste.
Sélectionnez Modifier pour afficher la configuration de la règle récapitulative.
Sélectionnez Suivant : définissez la logique de règle pour afficher la requête utilisée dans la règle récapitulative.
Arrêter une règle récapitulative
Arrêtez une règle pendant une période de temps. L’un des exemples de cas d’usage consiste à vérifier que les données sont ingérées dans une table sans affecter la table résumée et les rapports.
Pour arrêter une règle :
- À partir du portail Azure, accédez à votre espace de travail Log Analytics.
- Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
- Sélectionnez l’onglet Règles de résumé .
- Sélectionnez le bouton bascule d’ActifÉtat et confirmez que l’état passe à Inactif.
Démarrer une règle récapitulative
Lorsque vous redémarrez la règle, Azure Monitor commence à traiter les données à partir de l’heure entière suivante ou en fonction du paramètre défini binStartTime (facultatif).
Pour lancer une règle :
- À partir du portail Azure, accédez à votre espace de travail Log Analytics.
- Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
- Sélectionnez l’onglet Règles de résumé .
- Sélectionnez le bouton bascule InactifÉtat et confirmez que l’état passe à Actif.
Supprimer une règle récapitulative
Un espace de travail Log Analytics prend en charge jusqu’à 100 règles de synthèse actives. Si vous avez déjà 100 règles actives et que vous souhaitez en créer une, vous devez d’abord arrêter ou supprimer une règle récapitulative active.
Pour supprimer une règle :
- À partir du portail Azure, accédez à votre espace de travail Log Analytics.
- Dans le menu de gauche, sous Paramètres, sélectionnez Règles.
- Sélectionnez l’onglet Règles de résumé .
- Sélectionnez les points de suspension (...) en regard de la règle récapitulative que vous souhaitez afficher dans la liste.
- Sélectionnez Supprimer.
Surveiller les règles récapitulatives
Pour surveiller les règles de synthèse, activez la catégorie Summary Logs dans les paramètres diagnostic de votre espace de travail Log Analytics. Azure Monitor envoie des informations récapitulatives sur l’exécution des règles, y compris les états d’exécution Started, Succeeded et Failed, dans la table LASummaryLogs de votre espace de travail.
Configurez des règles d’alerte de journal pour recevoir des notifications en cas d’échec du traitement d’un lot ou lorsque l’exécution d’un lot approche du délai d’expiration, comme illustré dans les exemples suivants. Selon la raison de l’échec, réduisez la taille du bac pour traiter moins de données sur chaque exécution, ou modifiez la requête pour retourner moins d’enregistrements ou moins de champs à volume élevé.
Cette requête retourne des exécutions ayant échoué :
LASummaryLogs | where Status == "Failed"
Cette requête retourne des exécutions bin où la QueryDurationMs valeur est supérieure à 90% de la durée maximale d’exécution de la requête :
LASummaryLogs | where QueryDurationMs > 0.9 * 600000
Vérifier l’exhaustivité des données
Les règles récapitulatives sont conçues pour la mise à l’échelle et incluent un mécanisme de nouvelle tentative pour surmonter les échecs temporaires de service ou de requête liés aux limites de requête. Le mécanisme de nouvelle tentative effectue 10 tentatives d’agrégation d’un bac défaillant dans les huit heures et ignore la corbeille si toutes les tentatives sont épuisées. La règle est définie sur isActive: false et mise en attente après huit nouvelles tentatives consécutives de bac.
Si vous activez le paramètre de diagnostic pour surveiller les règles récapitulatives, Azure Monitor journalise les événements dans la LASummaryLogs table de votre espace de travail, ce qui vous permet d’afficher les exécutions et de réessayer les échecs. Affichez les exécutions avec la requête suivante ou via le portail.
let startTime = datetime("2024-02-16");
let endTime = datetime("2024-03-03");
let ruleName = "myRuleName";
let stepSize = 20m; // The stepSize value is equal to the bin size defined in the rule
LASummaryLogs
| where RuleName == ruleName
| where Status == 'Succeeded'
| make-series dcount(BinStartTime) default=0 on BinStartTime from startTime to endTime step stepSize
| render timechart
Cette requête affiche les résultats sous forme de chronogramme :
Consultez la section Surveiller les règles récapitulatives pour connaître les options de correction des règles et les alertes proactives.
Réexécuter un lot d’une règle récapitulative
Les règles récapitulatives sont conçues pour la mise à l’échelle et incluent un mécanisme de nouvelle tentative pour surmonter les problèmes de service temporaires ou les échecs de limite de requête. Lorsque toutes les tentatives de nouvelle exécution du service ont été épuisées, relancez manuellement l’exécution ayant échoué (ou bin).
La nouvelle tentative est une action sur une règle existante, et non un déploiement de ressources. Recherchez la BinStartTime de la corbeille défaillante et utilisez-la comme retryBinStartTime. Par exemple, pour un intervalle de 60 minutes couvrant 2026-02-16T10:00:00Z à 2026-02-16T11:00:00Z, utilisez 2026-02-16T10:00:00Z.
- Sélectionnez les points de suspension (...) à l’extrême droite de la règle de résumé que vous souhaitez réexécuter.
- Sélectionnez Afficher les exécutions dans le menu.
- Modifiez le filtre pour afficher les exécutions ayant échoué .
- Recherchez l’heure d’exécution que vous souhaitez relancer et sélectionnez les points de suspension (...) à la fin de la ligne correspondante.
- Sélectionnez Relancer cette corbeille dans le menu.
Chiffrer les requêtes de règles récapitulatives à l’aide de clés gérées par le client
Une requête KQL peut contenir des informations sensibles dans les commentaires ou dans la syntaxe de la requête. Pour chiffrer les requêtes de règle de synthèse, liez un compte de stockage à votre espace de travail Log Analytics et utilisez des clés gérées par le client.
Considérations relatives à l’utilisation de requêtes chiffrées :
- La liaison d’un compte de stockage pour chiffrer vos requêtes n’interrompt pas les règles existantes.
- ** Par défaut, Azure Monitor stocke les requêtes des règles de synthèse dans le stockage Log Analytics. Si vous disposez de règles récapitulatives existantes avant de lier un compte de stockage à votre espace de travail Log Analytics, mettez à jour ces règles afin que les requêtes soient enregistrées dans le compte de stockage.
- Les requêtes que vous enregistrez dans un compte de stockage se trouvent dans la table
CustomerConfigurationStoreTable. Ces requêtes sont considérées comme des artefacts de service et leur format peut changer. - Le même compte de stockage prend en charge les requêtes de règles récapitulatives, les requêtes enregistrées dans Log Analytics et les alertes de journal.
Résoudre les problèmes liés aux règles récapitulative
Cette section fournit des conseils pour résoudre les problèmes liés aux règles récapitulatives.
Table de destination de règle récapitulative accidentellement supprimée
Si vous supprimez la table de destination pendant que la règle récapitulative est active, la règle est suspendue et Azure Monitor envoie un événement à la table LASummaryLogs avec un message indiquant que la règle a été suspendue.
Si vous n’avez pas besoin des résultats récapitulatives dans la table de destination, supprimez la règle et la table. Si vous avez besoin des résultats de résumé, suivez les étapes de la section Créer ou mettre à jour des règles récapitulatives pour recréer la table de destination et restaurer toutes les données, y compris les données ingérées avant la suppression, en fonction de la stratégie de rétention dans la table.
La requête utilise des opérateurs qui créent des colonnes dans la table de destination
Le schéma de table de destination est défini lorsque vous créez ou mettez à jour une règle récapitulative. Si la requête inclut des opérateurs qui autorisent l'expansion du schéma de sortie en fonction des données entrantes (par exemple, la arg_max(expression, *) fonction), Azure Monitor n'ajoute pas de nouvelles colonnes à la table de destination après avoir créé ou mis à jour la règle, et les données de sortie qui nécessitent ces colonnes sont supprimées. Pour ajouter les nouveaux champs à la table de destination, mettre à jour la règle de synthèse ou ajouter une colonne à votre table manuellement.
Les données dans les colonnes supprimées restent dans l’espace de travail en fonction des paramètres de rétention de la table
Lorsque vous supprimez un champ de la requête, les colonnes et les données restent dans la table de destination en fonction de la période de rétention définie sur la table ou l’espace de travail. Si vous n’avez pas besoin des colonnes supprimées dans la table de destination, supprimez les colonnes du schéma de table. Si vous ajoutez ensuite des colonnes portant le même nom, toutes les données qui ne sont pas antérieures à la période de rétention apparaissent à nouveau.