.*?)/ | stats avg(latency2) by @method2,
@user2
```
**Extrait les champs `loggingTime`, `loggingType` et `loggingMessage`, filtre vers le bas pour journaliser les événements qui contiennent les chaînes `ERROR` ou `INFO`, puis affiche uniquement les champs `loggingMessage` et `loggingType` pour les événements qui contiennent une chaîne `ERROR`.**
```
FIELDS @message
| PARSE @message "* [*] *" as loggingTime, loggingType, loggingMessage
| FILTER loggingType IN ["ERROR", "INFO"]
| DISPLAY loggingMessage, loggingType = "ERROR" as isError
```
# sort
Utilisez la commande `sort` pour afficher les événements du journal dans l'ordre croissant (`asc`) ou décroissant (`desc`) en fonction d'un champ spécifié. Vous pouvez l'utiliser avec la commande `limit` pour créer des requêtes de type « N premiers » ou « N derniers ».
L'algorithme de tri est une version actualisée du tri naturel. Si vous triez par ordre croissant, la logique suivante est utilisée.
+ Toutes les valeurs non numériques précèdent toutes les valeurs numériques. Les *valeurs numériques* sont des valeurs qui incluent uniquement des chiffres, et non un mélange de chiffres et d'autres caractères.
+ Pour les valeurs non numériques, l'algorithme regroupe les caractères numériques consécutifs et les caractères alphabétiques consécutifs dans des segments distincts à des fins de comparaison. Il classe les parties non numériques en fonction de leurs valeurs Unicode, et les parties numériques en fonction de leur longueur, puis en fonction de leur valeur numérique.
Pour plus d'informations sur l'ordre Unicode, voir [Liste des caractères Unicode](https://en.wikipedia.org/wiki/List_of_Unicode_characters).
Par exemple, ce qui suit est le résultat d'un tri par ordre croissant.
```
!: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sorted by unicode order
#
*%04
0# >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alphanumeric starting with numbers
5A
111A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Starts with more digits than 5A, so it sorted to be later than 5A
2345_
@ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2345 is compared with @ in the unicode order,
@_
A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Values starting with letters
A9876fghj
a12345hfh
0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Number values
01
1
2
3
```
Si vous triez par ordre décroissant, les résultats du tri sont inverses.
Par exemple, la requête suivante pour les journaux de flux Amazon VPC permet de trouver les 15 premiers transferts de paquets entre les hôtes.
```
stats sum(packets) as packetsTransferred by srcAddr, dstAddr
| sort packetsTransferred desc
| limit 15
```
# stats
Utilisez `stats` pour créer des visualisations les données de vos journaux, telles que des diagrammes à barres, des graphiques linéaires et des diagrammes à aires empilées. Cela vous permet d'identifier plus efficacement les modèles dans vos données de journal. CloudWatch Logs Insights génère des visualisations pour les requêtes qui utilisent la `stats` fonction et une ou plusieurs fonctions d'agrégation.
Par exemple, la requête suivante dans un groupe de journaux Route 53 renvoie des visualisations présentant la distribution des enregistrements Route 53 par heure, par type de requête.
```
stats count(*) by queryType, bin(1h)
```
Toutes ces requêtes peuvent produire des graphiques à barres. En outre, si votre requête utilise la fonction `bin()` pour regrouper les données en fonction d'un seul champ au fil du temps, vous pouvez également voir des graphiques linéaires et des graphiques en aires empilées.
les unités de temps et les abréviations suivantes sont prises en charge par la fonction `bin`. Pour toutes les unités et abréviations qui incluent plus d'un caractère, l'ajout de s au pluriel est pris en charge. Donc, les deux `hr` et `hrs` travaillent pour spécifier les heures.
+ `millisecond` `ms` `msec`
+ `second` `s` `sec`
+ `minute` `m` `min`
+ `hour` `h` `hr`
+ `day` `d`
+ `week` `w`
+ `month` `mo` `mon`
+ `quarter` `q` `qtr`
+ `year` `y` `yr`
**Topics**
+ [Visualisation des données de séries temporelles](#CWL_Insights-Visualizing-TimeSeries)
+ [Visualisation des données de journal regroupées par champs](#CWL_Insights-Visualizing-ByFields)
+ [Utiliser plusieurs commandes stats dans une seule requête](#CWL_QuerySyntax-stats-multi)
+ [Fonctions à utiliser avec stats](#CWL_QuerySyntax-stats-functions)
## Visualisation des données de séries temporelles
Les visualisations chronologiques fonctionnent pour les requêtes présentant les caractéristiques suivantes :
+ La requête contient une ou plusieurs fonctions d'agrégation. Pour plus d'informations, consultez [Aggregation Functions in the Stats Command](#CWL_Insights_Aggregation_Functions).
+ La requête utilise la fonction `bin()` pour regrouper les données en un champ.
Ces requêtes peuvent produire des graphiques linéaires, des graphiques en aires empilées et des graphiques à barres et des graphiques circulaires.
**Exemples**
Pour un didacticiel complet, consultez [Didacticiel : Exécuter une requête qui produit des séries temporelles](CWL_AnalyzeLogData_VisualizationQuery.md).
Voici d'autres exemples de requêtes qui fonctionnent pour la visualisation chronologiques.
La requête suivante génère une visualisation des valeurs moyennes du champ `myfield1`, avec un point de données créé toutes les cinq minutes. Chaque point de données correspond à l'agrégation des moyennes des valeurs `myfield1` des journaux des cinq minutes précédentes.
```
stats avg(myfield1) by bin(5m)
```
La requête suivante génère une visualisation des trois valeurs basées sur différents champs, avec un point de données créé toutes les cinq minutes. La visualisation est générée, car la requête contient des fonctions d'agrégation et utilise `bin()` comme champ de regroupement.
```
stats avg(myfield1), min(myfield2), max(myfield3) by bin(5m)
```
**Restrictions pour les graphiques linéaires et les graphiques en aires empilées**
Les requêtes qui regroupent les informations d'entrée de journal sans utiliser la fonction `bin()` peuvent générer des graphiques à barres. Toutefois, les requêtes ne peuvent pas générer de graphique linéaire ou de graphique en aires empilées. Pour plus d'informations sur ces types de requête, consultez [Visualisation des données de journal regroupées par champs](#CWL_Insights-Visualizing-ByFields).
## Visualisation des données de journal regroupées par champs
Vous pouvez produire des graphiques à barres pour les requêtes qui utilisent la fonction `stats` et une ou plusieurs fonctions d'agrégation. Pour plus d'informations, consultez [Aggregation Functions in the Stats Command](#CWL_Insights_Aggregation_Functions).
Pour afficher la visualisation, exécutez votre requête. Choisissez ensuite l'onglet **Visualization (Visualisation)**, sélectionnez la flèche en regard de **Line (Ligne)**, puis choisissez **Bar (Barre)**. Les visualisations sont limitées à 100 barres dans le graphique à barres.
**Exemples**
Pour un didacticiel complet, consultez [Didacticiel : Exécuter une requête qui génère une visualisation groupée par champs de journal](CWL_AnalyzeLogData_VisualizationFieldQuery.md). Les paragraphes suivants incluent d'autres exemples de requête pour la visualisation par champs.
La requête de journal de flux VPC suivante recherche le nombre moyen d'octets transférés par session pour chaque adresse de destination.
```
stats avg(bytes) by dstAddr
```
Vous pouvez également produire un graphique qui comprend plus d'une barre pour chaque valeur résultante. Par exemple, la requête de journal de flux VPC suivante recherche le nombre moyen et le nombre maximal d'octets transférés par session pour chaque adresse de destination.
```
stats avg(bytes), max(bytes) by dstAddr
```
La requête suivante recherche le nombre de journaux de requêtes Amazon Route 53 pour chaque type de requête.
```
stats count(*) by queryType
```
## Utiliser plusieurs commandes stats dans une seule requête
Vous pouvez utiliser jusqu'à deux commandes `stats` dans une seule requête. Cela vous permet d'effectuer une agrégation supplémentaire sur la sortie de la première agrégation.
**Exemple : requête avec deux commandes `stats`**
Par exemple, la requête suivante trouve d'abord le volume de trafic total par tranches de 5 minutes, puis calcule le volume de trafic le plus élevé, le plus bas et le volume de trafic moyen parmi ces tranches de 5 minutes.
```
FIELDS strlen(@message) AS message_length
| STATS sum(message_length)/1024/1024 as logs_mb BY bin(5m)
| STATS max(logs_mb) AS peak_ingest_mb,
min(logs_mb) AS min_ingest_mb,
avg(logs_mb) AS avg_ingest_mb
```
**Exemple : combiner plusieurs commandes stats avec d'autres fonctions telles que `filter`, `fields`, `bin`**
Vous pouvez combiner deux commandes `stats` avec d'autres commandes, telles que `filter` et `fields` dans une seule requête. Par exemple, la requête suivante trouve le nombre d'adresses IP distinctes dans les sessions et le nombre de sessions par plateforme client, filtre ces adresses IP et enfin trouve la moyenne des demandes de session par plateforme client.
```
STATS count_distinct(client_ip) AS session_ips,
count(*) AS requests BY session_id, client_platform
| FILTER session_ips > 1
| STATS count(*) AS multiple_ip_sessions,
sum(requests) / count(*) AS avg_session_requests BY client_platform
```
Vous pouvez utiliser les fonctions `bin` et `dateceil` dans des requêtes comportant plusieurs commandes `stats`. Par exemple, la requête suivante combine d'abord les messages en blocs de 5 minutes, puis agrège ces blocs de 5 minutes en blocs de 10 minutes et calcule les volumes de trafic les plus élevés, les plus bas et la moyenne dans chaque bloc de 10 minutes.
```
FIELDS strlen(@message) AS message_length
| STATS sum(message_length) / 1024 / 1024 AS logs_mb BY BIN(5m) as @t
| STATS max(logs_mb) AS peak_ingest_mb,
min(logs_mb) AS min_ingest_mb,
avg(logs_mb) AS avg_ingest_mb BY dateceil(@t, 10m)
```
**Remarques et limitations**
Une requête peut avoir un maximum de deux commandes `stats`. Ce quota ne peut pas être modifié.
Si vous utilisez une commande `sort` ou `limit`, elle doit apparaître après la deuxième commande `stats`. Si elle est antérieure à la deuxième commande `stats`, la requête n'est pas valide.
Lorsqu'une requête comporte deux commandes `stats`, les résultats partiels de la requête ne commencent pas à s'afficher tant que la première agrégation `stats` n'est pas terminée.
Dans la deuxième commande `stats` d'une seule requête, vous ne pouvez faire référence qu'aux champs définis dans la première commande `stats`. Par exemple, la requête suivante n'est pas valide, car le champ `@message` ne sera plus disponible après la première agrégation `stats`.
```
FIELDS @message
| STATS SUM(Fault) by Operation
# You can only reference `SUM(Fault)` or Operation at this point
| STATS MAX(strlen(@message)) AS MaxMessageSize # Invalid reference to @message
```
Tous les champs auxquels vous faites référence après la première commande `stats` doivent être définis dans cette première commande `stats`.
```
STATS sum(x) as sum_x by y, z
| STATS max(sum_x) as max_x by z
# You can only reference `max(sum_x)`, max_x or z at this point
```
**Important**
La fonction `bin` utilise toujours implicitement le champ `@timestamp`. Cela signifie que vous ne pouvez pas utiliser `bin` dans la deuxième commande `stats` sans utiliser la première commande `stats` pour propager le champ `timestamp`. Par exemple, la requête suivante n'est pas valide.
```
FIELDS strlen(@message) AS message_length
| STATS sum(message_length) AS ingested_bytes BY @logStream
| STATS avg(ingested_bytes) BY bin(5m) # Invalid reference to @timestamp field
```
Définissez plutôt le champ `@timestamp` dans la première commande `stats`, puis utilisez-le avec `dateceil` dans la deuxième commande `stats`, comme dans l'exemple suivant.
```
FIELDS strlen(@message) AS message_length
| STATS sum(message_length) AS ingested_bytes, max(@timestamp) as @t BY @logStream
| STATS avg(ingested_bytes) BY dateceil(@t, 5m)
```
## Fonctions à utiliser avec stats
CloudWatch Logs Insights prend en charge à la fois les fonctions d'agrégation des statistiques et les fonctions de non-agrégation des statistiques.
Utilisez des fonctions statistiques d'agrégation dans la commande `stats` et en tant qu'arguments pour d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `avg(fieldName: NumericLogField)` | nombre | Moyenne des valeurs dans le champ spécifié. |
| `count()` `count(fieldName: LogField)` | number | Compte les événements du journal. `count()`(ou `count(*)`) compte tous les événements renvoyés par la requête, tandis que `count(fieldName)` compte tous les enregistrements qui incluent le nom du champ spécifié. |
| `count_distinct(fieldName: LogField)` | number | Renvoie le nombre de valeurs uniques pour le champ. Si le champ a une cardinalité très élevée (contient de nombreuses valeurs uniques), la valeur renvoyée par `count_distinct` n'est qu'une approximation. |
| `max(fieldName: LogField)` | LogFieldValue | Valeur maximale des valeurs pour ce journal dans le champ interrogé. |
| `min(fieldName: LogField)` | LogFieldValue | Valeur minimale des valeurs pour ce journal dans le champ interrogé. |
| `pct(fieldName: LogFieldValue, percent: number)` | LogFieldValue | Un centile indique la position relative d'une valeur dans un ensemble de données. Par exemple, `pct(@duration, 95)` renvoie la valeur `@duration` à laquelle 95 % des valeurs de `@duration` sont inférieures à cette valeur et 5 % des valeurs lui sont supérieures. |
| `stddev(fieldName: NumericLogField)` | number | Déviation standard des valeurs dans le champ spécifié. |
| `sum(fieldName: NumericLogField)` | number | Somme des valeurs dans le champ spécifié. |
**Fonctions statiques de non-agrégation**
Utilisez des fonctions de non-agrégation dans la commande `stats` et en tant qu'arguments d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `earliest(fieldName: LogField)` | LogField | Renvoie la valeur de `fieldName` à partir de l'événement de journal qui a l'horodatage le plus récent dans les journaux interrogés. |
| `latest(fieldName: LogField)` | LogField | Renvoie la valeur de `fieldName` à partir de l'événement de journal qui a l'horodatage le plus ancien dans les journaux interrogés. |
| `sortsFirst(fieldName: LogField)` | LogField | Renvoie la valeur de `fieldName` triée la première dans les journaux interrogés. |
| `sortsLast(fieldName: LogField)` | LogField | Renvoie la valeur de `fieldName` triée la dernière dans les journaux interrogés. |
# limite
Utilisez la commande `limit` pour spécifier le nombre d'événements du journal que vous voulez que votre requête retourne. Si vous omettez`limit`, la requête renverra jusqu'à 10 000 événements de journal dans les résultats.
Par exemple, l'exemple suivant renvoie uniquement les 25 derniers événements du journal
```
fields @timestamp, @message | sort @timestamp desc | limit 25
```
# dedup
Utilisez `dedup` pour supprimer les résultats dupliqués en fonction de valeurs spécifiques dans les champs que vous indiquez. Vous pouvez l'utiliser `dedup` avec un ou plusieurs champs. Si vous spécifiez un champ avec `dedup`, un seul événement du journal est renvoyé pour chaque valeur unique de ce champ. Si vous spécifiez plusieurs champs, un événement du journal est renvoyé pour chaque combinaison unique de valeurs pour ces champs.
Les doublons sont supprimés en fonction de l'ordre de tri, seul le premier résultat selon l'ordre de tri étant conservé. Nous vous recommandons de trier vos résultats avant de les soumettre à la commande `dedup`. Si les résultats ne sont pas triés avant d'être soumis à `dedup`, l'ordre de tri décroissant par défaut utilisant `@timestamp` est appliqué.
Les valeurs nulles ne sont pas considérées comme des doublons pour l'évaluation. Les événements du journal dont les valeurs sont nulles pour l'un des champs spécifiés sont conservés. Pour éliminer les champs contenant des valeurs nulles, utilisez **`filter`** en appliquant la fonction `isPresent(field)`.
La seule commande de requête que vous pouvez utiliser dans une requête après la commande `dedup` est `limit`.
Lorsque vous l'utilisez `dedup` dans une requête, la console affiche un message tel que **Afficher X des Y enregistrements**, où X représente le nombre de résultats dédupliqués et Y le nombre total d'enregistrements mis en correspondance avant la déduplication. Cela indique que les doublons ont été supprimés et ne signifie pas que des données sont manquantes.
**Exemple : n'afficher que l'événement du journal le plus récent pour chaque valeur unique du champ nommé `server`**
L'exemple suivant affiche les champs `timestamp`, `server`, `severity`, et `message` correspondant uniquement à l'événement le plus récent pour chaque valeur unique de `server`.
```
fields @timestamp, server, severity, message
| sort @timestamp desc
| dedup server
```
Pour d'autres exemples de requêtes CloudWatch Logs Insights, consultez[Requêtes générales](CWL_QuerySyntax-examples.md#CWL_QuerySyntax-examples-general).
# unmask
Utilisez la commande `unmask` pour afficher tout le contenu d'un événement du journal dont certains contenus ont été masqués en raison d'une politique de protection des données. Pour exécuter cette commande, vous devez disposer de l'autorisation `logs:Unmask`.
Pour plus d'informations sur la protection des données dans les groupes de journaux, consultez [Aider à protéger les données sensibles des journaux grâce au masquage](mask-sensitive-log-data.md) (français non garanti).
# unnest
`unnest`À utiliser pour aplatir une liste prise en entrée afin de produire plusieurs enregistrements avec un seul enregistrement pour chaque élément de la liste. En fonction du nombre d'éléments contenus dans un champ, cette commande supprime l'enregistrement actuel et génère de nouveaux enregistrements. Chaque enregistrement inclut le`unnested_field`, qui représente un élément. Tous les autres champs proviennent de l'enregistrement d'origine.
L'entrée pour `unnest` `LIST` is provient de la `jsonParse` fonction. Pour plus d'informations, consultez [la section Types de structures](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-operations-functions.html#CWL_QuerySyntax-structure-types). Tous les autres types, tels que `MAP``numbers`, `String` et, sont traités comme une liste contenant un élément`unnest`.
**Structure de commande**
L'exemple suivant décrit le format de cette commande.
```
unnest field into unnested_field
```
**Exemple de requête**
L'exemple suivant analyse une chaîne d'objet JSON et développe une liste d'événements de champ.
```
fields jsonParse(@message) as json_message
| unnest json_message.events into event
| display event.name
```
L'événement de journal pour cet exemple de requête peut être une chaîne JSON comme suit :
```
{
"events": [
{
"name": "exception"
},
{
"name": "user action"
}
]
}
```
Dans ce cas, l'exemple de requête produit deux enregistrements dans le résultat de la requête, l'un avec « `event.name` as » `exception` et l'autre avec « `event.name` as **user action** »
**Exemple de requête**
L'exemple suivant aplatit une liste, puis filtre les éléments.
```
fields jsonParse(@message) as js
| unnest js.accounts into account
| filter account.type = "internal"
```
**Exemple de requête**
L'exemple suivant aplatit une liste à des fins d'agrégation.
```
fields jsonParse(trimmedData) as accounts
| unnest accounts into account
| stats sum(account.droppedSpans) as n by account.accountId
| sort n desc
| limit 10
```
# chercher
`lookup`À utiliser pour enrichir les résultats de votre requête avec des données de référence issues d'une table de recherche. Une table de recherche contient des données CSV que vous chargez sur Amazon CloudWatch Logs. Lorsqu'une requête est exécutée, la `lookup` commande fait correspondre un champ de votre journal des événements à un champ de la table de recherche et ajoute les champs de sortie spécifiés aux résultats.
Utilisez les tables de recherche pour les scénarios d'enrichissement des données, tels que le mappage des informations utilisateur IDs à utilisateur, les codes de produit aux informations sur le produit ou les codes d'erreur aux descriptions d'erreurs.
## Création et gestion de tables de recherche
Avant de pouvoir utiliser la `lookup` commande dans une requête, vous devez créer une table de recherche. Vous pouvez créer et gérer des tables de recherche depuis la CloudWatch console ou à l'aide de l'API Amazon CloudWatch Logs.
**Pour créer une table de recherche (console)**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, choisissez **Paramètres**, puis l'onglet **Journaux**.
1. Accédez aux **tables de recherche**, puis sélectionnez **Gérer**.
1. Choisissez **Créer une table de recherche**.
1. Entrez un nom pour la table de recherche. Le nom ne peut contenir que des caractères alphanumériques, des traits d'union et des traits de soulignement.
1. (Facultatif) Entrez une description.
1. Téléchargez un fichier CSV. Le fichier doit inclure une ligne d'en-tête avec les noms de colonnes, utiliser le codage UTF-8 et ne pas dépasser 10 Mo.
1. (Facultatif) Spécifiez une AWS KMS clé pour chiffrer les données de la table.
1. Choisissez **Créer**.
Après avoir créé une table de recherche, vous pouvez l'afficher dans l'éditeur de requêtes CloudWatch Logs Insights. Cliquez sur l'onglet **Tables de recherche** pour parcourir les tables disponibles et leurs champs.
Pour mettre à jour une table de recherche, sélectionnez-la et choisissez **Actions**, **Mettre à jour**. Téléchargez un nouveau fichier CSV pour remplacer tout le contenu existant. Pour supprimer une table de recherche, choisissez **Actions**, **Supprimer**.
**Note**
Vous pouvez créer jusqu'à 100 tables de recherche par compte et par compte Région AWS. Les fichiers CSV peuvent peser jusqu'à 10 Mo. Vous pouvez également gérer les tables de recherche à l'aide de l'API Amazon CloudWatch Logs. Pour plus d'informations, consultez [CreateLookupTable](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLookupTable.html)le manuel *Amazon CloudWatch Logs API Reference*.
**Note**
Si la table de recherche est chiffrée à l'aide d'une clé KMS, l'appelant doit avoir l'`kms:Decrypt`autorisation sur la clé (la clé KMS utilisée pour chiffrer la table de recherche) d'utiliser l'`StartQuery`API avec une requête faisant référence à cette table de recherche. Pour de plus amples informations, veuillez consulter [Chiffrez les tables de recherche dans les CloudWatch journaux à l'aide de AWS Key Management Service](encrypt-lookup-tables-kms.md).
## Syntaxe de requête pour la recherche
**Structure de commande**
Le format de cette commande est illustré ci-dessous.
```
lookup table lookup-field as log-field [,...] output-mode output-field[,...]
```
La commande utilise les arguments suivants :
+ `table`— Nom de la table de recherche à utiliser.
+ `lookup-field`— Le champ de la table de recherche à comparer.
+ `log-field`— Le champ correspondant dans votre journal des événements. La correspondance est exacte et distingue les majuscules et minuscules.
+ `output-mode`— Spécifiez `OUTPUT` d'ajouter les champs de sortie aux résultats. Si un champ portant le même nom existe déjà dans le journal des événements, il est remplacé.
+ `output-field`— Un ou plusieurs champs de la table de recherche à ajouter aux résultats.
**Exemple : enrichir les événements du journal avec les détails de l'utilisateur**
Supposons que vous disposiez d'un groupe de journaux contenant des événements contenant un `id` champ et d'une table de recherche nommée `user_data` par des colonnes `id``name`,`email`, et`department`. La requête suivante enrichit chaque événement du journal avec le nom, l'adresse e-mail et le service de l'utilisateur à partir de la table de recherche.
```
fields action, status, name, email, department
| lookup user_data id OUTPUT name, email, department
```
**Exemple : utilisation de la recherche avec agrégation**
Vous pouvez utiliser des champs de sortie de recherche avec des fonctions d'agrégation. La requête suivante enrichit les événements du journal avec les détails de l'utilisateur, puis compte les événements regroupés par adresse e-mail.
```
fields user_id, action, username, email, department
| lookup user_data user_id OUTPUT username, email, department
| stats count(*) by email
```
**Exemple : utiliser la recherche avec filtre**
Vous pouvez filtrer les résultats en fonction des champs renvoyés par la recherche. La requête suivante enrichit les événements du journal, puis filtre pour n'afficher que les événements d'un département spécifique.
```
fields user_id, action
| lookup user_data user_id OUTPUT username, email, department
| filter department = "Engineering"
```
# Fonctions booléennes, de comparaison, numériques, de date/heure et autres
CloudWatch Logs Insights prend en charge de nombreuses autres opérations et fonctions dans les requêtes, comme expliqué dans les sections suivantes.
**Topics**
+ [Opérateurs arithmétiques](#CWL_QuerySyntax-operations-arithmetic)
+ [Opérateurs booléens](#CWL_QuerySyntax-operations-Boolean)
+ [Opérateurs de comparaison](#CWL_QuerySyntax-operations-comparison)
+ [Opérateurs numériques](#CWL_QuerySyntax-operations-numeric)
+ [Types de structures](#CWL_QuerySyntax-structure-types)
+ [Fonctions Datetime](#CWL_QuerySyntax-datetime)
+ [Fonctions générales](#CWL_QuerySyntax-general-functions)
+ [Fonctions JSON](#CWL_QuerySyntax-json-functions)
+ [Fonctions de chaîne d'adresse IP](#CWL_QuerySyntax-IPaddress-functions)
+ [Fonctions de chaîne](#CWL_QuerySyntax-string-functions)
## Opérateurs arithmétiques
Les opérateurs arithmétiques acceptent les types de données numériques en tant qu'arguments et renvoient des résultats numériques. Utilisez des opérateurs arithmétiques dans les commandes `filter` et `fields` et en tant qu'arguments pour d'autres fonctions.
| Opération | Description |
| --- | --- |
| `a + b` | Addition |
| `a - b` | Soustraction |
| `a * b` | Multiplication |
| `a / b` | Division |
| `a ^ b` | Élévation à la puissance (`2 ^ 3` renvoie `8`) |
| `a % b` | Valeurs restantes ou module (`10 % 3` renvoie `1`) |
## Opérateurs booléens
Utilisez les opérateurs booléens `and`, `or` et `not`.
**Note**
Utilisez les opérateurs booléens uniquement dans les fonctions qui renvoient une valeur de **TRUE** (VRAI) ou **FALSE** (FAUX).
## Opérateurs de comparaison
Les opérateurs de comparaison acceptent tous les types de données en tant qu'arguments et renvoient un résultat booléen. Utilisez des opérations de comparaison dans la commande `filter` et en tant qu'arguments pour d'autres fonctions.
| Opérateur | Description |
| --- | --- |
| `=` | Égal à |
| `!=` | Non égal à |
| `<` | Inférieur à |
| `>` | Supérieur à |
| `<=` | Inférieur ou égal à |
| `>=` | Supérieur ou égal à |
## Opérateurs numériques
Les opérations numériques acceptent les types de données numériques en tant qu'arguments numériques et renvoient des résultats numériques. Utilisez des opérations numériques dans les commandes `filter` et `fields` et en tant qu'arguments pour d'autres fonctions.
| Opération | Type de résultat | Description |
| --- | --- | --- |
| `abs(a: number)` | nombre | Valeur absolue |
| `ceil(a: number)` | number | Arrondir jusqu'au nombre entier supérieur suivant (le plus petit nombre entier supérieur à la valeur de `a`) |
| `floor(a: number)` | number | Arrondir jusqu'au nombre entier inférieur suivant (le plus grand nombre entier inférieur à la valeur de `a`) |
| `greatest(a: number, ...numbers: number[])` | number | Renvoie la valeur la plus grande |
| `least(a: number, ...numbers: number[])` | number | Renvoie la valeur la plus petite |
| `log(a: number)` | number | Journal naturel |
| `sqrt(a: number)` | number | Racine carrée |
## Types de structures
Une carte ou une liste est un type de structure dans CloudWatch Logs Insights qui vous permet d'accéder aux attributs et de les utiliser pour les requêtes.
**Exemple : pour obtenir une carte ou une liste**
`jsonParse`À utiliser pour analyser un champ qui est une chaîne JSON dans une carte ou une liste.
```
fields jsonParse(@message) as json_message
```
**Exemple : pour accéder aux attributs**
Utilisez l'opérateur d'accès par points (map.attribute) pour accéder aux éléments d'une carte. Si un attribut d'une carte contient des caractères spéciaux, utilisez des backticks pour placer le nom de l'attribut (map.attributes). `special.char`).
```
fields jsonParse(@message) as json_message
| stats count() by json_message.status_code
```
Utilisez l'opérateur d'accès entre crochets (list [index]) pour récupérer un élément à une position spécifique dans la liste.
```
fields jsonParse(@message) as json_message
| filter json_message.users[1].action = "PutData"
```
Enveloppez les caractères spéciaux en backticks (``) lorsque des caractères spéciaux sont présents dans le nom de la clé.
```
fields jsonParse(@message) as json_message
| filter json_message.`user.id` = "123"
```
**Exemple : résultats vides**
Les cartes et les listes sont traitées comme nulles pour les fonctions de chaîne, de nombre et de date.
```
fields jsonParse(@message) as json_message
| display toupper(json_message)
```
La comparaison de la carte et de la liste avec tout autre champ donne`false`.
**Note**
L'utilisation de la carte et de la liste dans `dedup``pattern`,`sort`, et `stats` n'est pas prise en charge.
## Fonctions Datetime
**Fonctions Datetime**
Utilisez les fonctions de date et heure dans les commandes `fields` et `filter` et en tant qu'arguments pour d'autres fonctions. Utilisez ces fonctions pour créer des compartiments de temps pour les requêtes avec des fonctions de regroupement. Utilisez des périodes composées d'un nombre et de l'un des éléments suivants :
+ `ms`pendant des millisecondes
+ `s`pendant quelques secondes
+ `m`pendant quelques minutes
+ `h`pendant des heures
Par exemple, `10m` correspond à 10 minutes et `1h` correspond à une heure.
**Note**
Utilisez l'unité de temps la plus appropriée pour votre fonction datetime. CloudWatch Logs plafonne votre demande en fonction de l'unité de temps que vous avez choisie. Par exemple, il plafonne à 60 la valeur maximale pour toute demande utilisant`s`. Ainsi, si vous le spécifiez`bin(300s)`, CloudWatch Logs l'implémente en fait sous la forme de 60 secondes, car 60 est le nombre de secondes dans une minute. CloudWatch Logs n'utilisera donc pas un nombre supérieur à 60 avec`s`. Pour créer un bucket de 5 minutes, utilisez `bin(5m)` plutôt.
Le plafond pour `ms` est de 1000, les capuchons pour `s` et `m` sont de 60, et le plafond pour `h` est de 24.
Le tableau suivant contient une liste des différentes fonctions de date et heure que vous pouvez utiliser dans des commandes de requête. Le tableau répertorie le type de résultat de chaque fonction et contient une description de chaque fonction.
**Astuce**
Lorsque vous créez une commande de requête, vous pouvez utiliser le sélecteur d'intervalle pour sélectionner une période de temps à interroger. Par exemple, vous pouvez définir une période de temps entre des intervalles de 5 à 30 minutes, des intervalles de 1, 3 et 12 heures ou une période personnalisée. Vous pouvez également définir des périodes entre des dates spécifiques.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `bin(period: Period)` | Horodatage | Arrondit la valeur de `@timestamp` à la période donnée, puis la tronque. Par exemple, `bin(5m)` arrondit la valeur de `@timestamp` aux 5 minutes les plus proches. Vous pouvez l'utiliser pour regrouper plusieurs entrées de journal dans une requête. L'exemple suivant indique le nombre d'exceptions par heure : filter @message like /Exception/
| stats count(*) as exceptionCount by bin(1h)
| sort exceptionCount desc
les unités de temps et les abréviations suivantes sont prises en charge par la fonction `bin`. Pour toutes les unités et abréviations qui incluent plus d'un caractère, l'ajout de s au pluriel est pris en charge. Donc, les deux `hr` et `hrs` travaillent pour spécifier les heures. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-operations-functions.html) |
| `datefloor(timestamp: Timestamp, period: Period)` | Horodatage | Tronque l'horodatage pour la période donnée. Par exemple, `datefloor(@timestamp, 1h)` tronque toutes les valeurs de `@timestamp` vers la valeur la plus basse de l'heure. |
| `dateceil(timestamp: Timestamp, period: Period)` | Horodatage | Arrondit l'horodatage pour la période donnée, puis la tronque. Par exemple, `dateceil(@timestamp, 1h)` tronque toutes les valeurs de `@timestamp` vers la valeur la plus élevée de l'heure. |
| `fromMillis(fieldName: number)` | Horodatage | Interprète le champ en entrée comme le nombre de millisecondes depuis l'époque Unix et le convertit en horodatage. |
| `toMillis(fieldName: Timestamp)` | number | Convertit l'horodatage trouvé dans le champ nommé en un nombre représentant les millisecondes depuis l'époque Unix. Par exemple, `toMillis(@timestamp)` convertit l'horodatage `2022-01-14T13:18:031.000-08:00` à `1642195111000`. |
| `now()` | number | Renvoie l'heure à laquelle le traitement de la requête a été lancé, en secondes d'époque. Cette fonction ne prend aucun argument. Vous pouvez l'utiliser pour filtrer les résultats de votre requête en fonction de l'heure actuelle. Par exemple, la requête suivante renvoie toutes les erreurs 4xx des deux dernières heures : parse @message "Status Code: *;" as statusCode\n
| filter statusCode >= 400 and statusCode <= 499 \n
| filter toMillis(@timestamp) >= (now() * 1000 - 7200000)
L'exemple suivant renvoie toutes les entrées du journal des cinq dernières heures contenant le mot `error` ou `failure` fields @timestamp, @message
| filter @message like /(?i)(error|failure)/
| filter toMillis(@timestamp) >= (now() * 1000 - 18000000)
|
**Note**
À l'heure actuelle, CloudWatch Logs Insights ne prend pas en charge le filtrage des journaux avec des horodatages lisibles par l'homme.
## Fonctions générales
**Fonctions générales**
Utilisez des fonctions générales dans les commandes `fields` et `filter` et en tant qu'arguments pour d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `ispresent(fieldName: LogField)` | Booléen | Renvoie `true` si le champ existe |
| `coalesce(fieldName: LogField, ...fieldNames: LogField[])` | LogField | Renvoie la première valeur non nulle de la liste |
## Fonctions JSON
**Fonctions JSON**
Utilisez les fonctions JSON dans les `filter` commandes `fields` et comme arguments pour d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `jsonParse(fieldName: string)` | Carte \$1 Liste \$1 Vide | Renvoie une carte ou une liste lorsque l'entrée est une représentation sous forme de chaîne d'un objet JSON ou d'un tableau JSON. Renvoie une valeur vide si l'entrée ne fait pas partie de la représentation. |
| `jsonStringify(fieldName: Map \| List)` | String | Renvoie une chaîne JSON à partir des données d'une carte ou d'une liste. |
## Fonctions de chaîne d'adresse IP
**Fonctions de chaîne d'adresse IP**
Utilisez les fonctions de chaîne d'adresse IP dans les commandes `filter` et `fields` et en tant qu'arguments pour d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `isValidIp(fieldName: string)` | booléen | Renvoie `true` si le champ est une IPv6 adresse IPv4 ou une adresse valide. |
| `isValidIpV4(fieldName: string)` | boolean | Renvoie `true` si le champ est une IPv4 adresse valide. |
| `isValidIpV6(fieldName: string)` | boolean | Renvoie `true` si le champ est une IPv6 adresse valide. |
| `isIpInSubnet(fieldName: string, subnet: string)` | boolean | Renvoie `true` si le champ est une IPv6 adresse valide IPv4 dans le sous-réseau v4 ou v6 spécifié. Lorsque vous spécifiez le sous-réseau, utilisez la notation CIDR telle que `192.0.2.0/24` ou `2001:db8::/32`, où `192.0.2.0` ou `2001:db8::` est le début du bloc d'adresse CIDR. |
| `isIpv4InSubnet(fieldName: string, subnet: string)` | boolean | Renvoie `true` si le champ est une IPv4 adresse valide dans le sous-réseau v4 spécifié. Lorsque vous spécifiez le sous-réseau, utilisez la notation CIDR telle que `192.0.2.0/24` où `192.0.2.0` est le début du bloc d'adresse CIDR. |
| `isIpv6InSubnet(fieldName: string, subnet: string)` | boolean | Renvoie `true` si le champ est une IPv6 adresse valide dans le sous-réseau v6 spécifié. Lorsque vous spécifiez le sous-réseau, utilisez la notation CIDR telle que `2001:db8::/32` où `2001:db8::` est le début du bloc d'adresse CIDR. |
## Fonctions de chaîne
**Fonctions de chaîne**
Utilisez des fonctions de chaîne dans les commandes `fields` et `filter` et en tant qu'arguments pour d'autres fonctions.
| Fonction | Type de résultat | Description |
| --- | --- | --- |
| `isempty(fieldName: string)` | Number | Renvoie `1` si le champ est manquant ou est une chaîne vide. |
| `isblank(fieldName: string)` | Number | Renvoie `1` si le champ est manquant, est une chaîne vide ou contient uniquement un espace. |
| `concat(str: string, ...strings: string[])` | chaîne | Concatène les chaînes. |
| `ltrim(str: string)` `ltrim(str: string, trimChars: string)` | chaîne | Si la fonction ne possède pas de deuxième argument, elle supprime les espaces blancs à gauche de la chaîne. Si la fonction possède un deuxième argument de chaîne, elle ne supprime pas l'espace blanc. Au lieu de cela, elle supprime les caractères de `trimChars` à gauche de `str`. Par exemple, `ltrim("xyZxyfooxyZ","xyZ")` renvoie `"fooxyZ"`. |
| `rtrim(str: string)` `rtrim(str: string, trimChars: string)` | chaîne | Si la fonction ne possède pas de deuxième argument, elle supprime les espaces blancs à droite de la chaîne. Si la fonction possède un deuxième argument de chaîne, elle ne supprime pas l'espace blanc. Au lieu de cela, elle supprime les caractères de `trimChars` à droite de `str`. Par exemple, `rtrim("xyZfooxyxyZ","xyZ")` renvoie `"xyZfoo"`. |
| `trim(str: string)` `trim(str: string, trimChars: string)` | chaîne | Si la fonction ne possède pas de deuxième argument, elle supprime les espaces blancs aux deux extrémités de la chaîne. Si la fonction possède un deuxième argument de chaîne, elle ne supprime pas l'espace blanc. Au lieu de cela, il supprime les caractères de `trimChars` des deux côtés de `str`. Par exemple, `trim("xyZxyfooxyxyZ","xyZ")` renvoie `"foo"`. |
| `strlen(str: string)` | number | Renvoie la longueur de la chaîne en points de code Unicode. |
| `toupper(str: string)` | chaîne | Convertit la chaîne en majuscules. |
| `tolower(str: string)` | chaîne | Convertit la chaîne en minuscules. |
| `substr(str: string, startIndex: number)` `substr(str: string, startIndex: number, length: number)` | chaîne | Renvoie une sous-chaîne à partir de l'index spécifié par l'argument de nombre à la fin de la chaîne. Si la fonction comporte un second argument de nombre, elle comporte la longueur de la sous-chaîne à récupérer. Par exemple, `substr("xyZfooxyZ",3, 3)` renvoie `"foo"`. |
| `replace(fieldName: string, searchValue: string, replaceValue: string)` | chaîne | Remplace toutes les instances de `searchValue` dans `fieldName: string` par `replaceValue`. Par exemple, la fonction `replace(logGroup,"smoke_test","Smoke")` recherche les événements du journal où le champ `logGroup` contient la valeur de chaîne `smoke_test` et remplace la valeur par la chaîne `Smoke`. |
| `strcontains(str: string, searchValue: string)` | number | Renvoie 1 si `str` contient `searchValue` et 0 dans le cas contraire. |
# Champs contenant des caractères spéciaux
Si un champ contient des caractères non alphanumériques autres que le `@` symbole ou le point (`.`), vous devez l'entourer de caractères anticochés (). ``` Par exemple, le champ de journal `foo-bar` doit être placé entre accents graves (``foo-bar``), car il contient un caractère non alphanumérique, le trait d'union (`-`).
# Utilisation d'alias et de commentaires dans les requêtes
Créez des requêtes contenant des alias. Utilisez des alias pour renommer des champs de journal ou lors de l'extraction de valeurs dans des champs. Utilisez le mot-clé `as` pour attribuer un champ de journal ou obtenir un alias. Vous pouvez utiliser plusieurs alias dans une requête. Vous pouvez utiliser des alias dans les commandes suivantes :
+ `fields`
+ `parse`
+ `sort`
+ ` stats `
Les exemples suivants montrent comment créer des requêtes contenant des alias.
**Exemple**
La requête contient un alias dans la commande `fields`.
```
fields @timestamp, @message, accountId as ID
| sort @timestamp desc
| limit 20
```
La requête renvoie les valeurs des champs `@timestamp`, `@message` et `accountId`. Les résultats sont triés dans l'ordre décroissant et limités à 20. Les valeurs pour `accountId` sont répertoriés sous l'alias `ID`.
**Exemple**
La requête contient des alias dans les commandes `sort` et `stats`.
```
stats count(*) by duration as time
| sort time desc
```
La requête compte le nombre de fois que le champ `duration` apparaît dans le groupe de journaux et trie les résultats dans l'ordre décroissant. Les valeurs pour `duration` sont répertoriés sous l'alias `time`.
## Utilisation de commentaires
CloudWatch Logs Insights prend en charge les commentaires dans les requêtes. Utilisez le caractère dièse (**\$1**) pour afficher les commentaires. Vous pouvez utiliser des commentaires pour ignorer les lignes des requêtes ou des requêtes de documents.
**Exemple : requête**
Lorsque la requête suivante est exécutée, la deuxième ligne est ignorée.
```
fields @timestamp, @message, accountId
# | filter accountId not like "7983124201998"
| sort @timestamp desc
| limit 20
```
# Commencez avec Logs Insights QL : didacticiels sur les requêtes
Les sections suivantes incluent des exemples de didacticiels sur les requêtes pour vous aider à démarrer avec Logs Insights QL.
**Topics**
+ [Didacticiel : Exécution et modification d'un exemple de requête](CWL_AnalyzeLogData_RunSampleQuery.md)
+ [Didacticiel : Exécuter une requête avec une fonction d'agrégation](CWL_AnalyzeLogData_AggregationQuery.md)
+ [Didacticiel : Exécuter une requête qui génère une visualisation groupée par champs de journal](CWL_AnalyzeLogData_VisualizationFieldQuery.md)
+ [Didacticiel : Exécuter une requête qui produit des séries temporelles](CWL_AnalyzeLogData_VisualizationQuery.md)
# Didacticiel : Exécution et modification d'un exemple de requête
Le didacticiel suivant vous aide à démarrer avec CloudWatch Logs Insights. Vous exécutez un exemple de requête dans Logs Insights QL, puis vous découvrez comment le modifier et le réexécuter.
Pour exécuter une requête, les journaux doivent déjà être stockés dans CloudWatch Logs. Si vous utilisez déjà les CloudWatch journaux et que vous avez configuré des groupes de journaux et des flux de journaux, vous êtes prêt à commencer. Il se peut également que vous disposiez déjà de journaux si vous utilisez des services tels qu' AWS CloudTrail Amazon Route 53 ou Amazon VPC et que vous avez configuré les journaux de ces services pour qu'ils soient accessibles dans Logs. CloudWatch Pour plus d'informations sur l'envoi de CloudWatch journaux à Logs, consultez[Commencer à utiliser CloudWatch Logs](CWL_GettingStarted.md).
Les requêtes dans CloudWatch Logs Insights renvoient soit un ensemble de champs provenant des événements du journal, soit le résultat d'une agrégation mathématique ou d'une autre opération effectuée sur les événements du journal. Ce didacticiel illustre une requête qui renvoie une liste d'événements du journal.
## Exécution d'un exemple de requête
**Pour exécuter un exemple de requête CloudWatch Logs Insights**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
Sur la page **Logs Insights**, l'éditeur de requêtes contient une requête par défaut dans Logs Insights QL qui renvoie les 20 événements de journal les plus récents.
1. Dans la liste déroulante **Sélectionner les groupes de journaux**, choisissez un ou plusieurs groupes de journaux à interroger.
S'il s'agit d'un compte de surveillance dans le CloudWatch domaine de l'observabilité entre comptes, vous pouvez sélectionner des groupes de journaux dans les comptes sources ainsi que dans le compte de surveillance. Une seule requête peut interroger les journaux de différents comptes à la fois.
Vous pouvez filtrer les groupes de journaux par nom de groupe de journaux, ID de compte ou étiquette de compte.
Lorsque vous sélectionnez un groupe de journaux dans la classe de CloudWatch journaux standard, Logs Insights détecte automatiquement les champs de données du groupe. Pour consulter les champs découverts, sélectionnez le menu **Champs** en haut à droite de la page.
**Note**
Les champs découverts ne sont pris en charge que pour les groupes de journaux de la classe de journaux standard. Pour plus d'informations sur les classes de log, consultez[Classes de log](CloudWatch_Logs_Log_Classes.md).
1. (Facultatif) Utilisez le sélecteur d'intervalle de temps pour sélectionner une période à interroger.
Vous pouvez choisir entre des intervalles de 5 à 30 minutes, des intervalles de 1, 3 et 12 heures ou une période personnalisée.
1. Choisissez **Run** (Exécuter) pour afficher les résultats.
Pour ce didacticiel, les résultats incluent les 20 événements du journal les plus récents.
CloudWatch Logs affiche un graphique à barres des événements du groupe de journaux au fil du temps. Ce graphique à barres montre non seulement les événements dans le tableau, mais également la distribution des événements dans le groupe de journaux qui correspondent à la requête et à la période.
1. Pour consulter tous les champs d'un événement du journal renvoyé, choisissez l'icône de liste déroulante triangulaire à gauche de l'événement numéroté.
## Modification de l'exemple de requête
Dans ce didacticiel, vous modifiez l'exemple de requête pour afficher les 50 événements du journal les plus récents.
Si vous n'avez pas encore exécuté le didacticiel précédent, faites-le maintenant. Ce didacticiel commence au moment où le didacticiel précédent se termine.
**Note**
Certains exemples de requêtes fournis avec CloudWatch Logs Insights utilisent des `tail` commandes `head` ou à la place de`limit`. Ces commandes sont considérées comme obsolètes et ont été remplacées par `limit`. Utilisez `limit` au lieu de `head` ou `tail` dans toutes les requêtes que vous écrivez.
**Pour modifier l'exemple de requête CloudWatch Logs Insights**
1. Dans l'éditeur de requêtes, remplacez **20** par **50**, puis choisissez **Exécuter**.
Les résultats de la nouvelle requête s'affichent. Si le groupe de journaux dispose de suffisamment de données dans la plage de temps par défaut, 50 journaux d'évènements sont désormais répertoriés.
1. (Facultatif) Vous pouvez enregistrer les requêtes que vous avez créées. Pour enregistrer cette requête, choisissez **Enregistrer**. Pour plus d'informations, consultez [Enregistrez et réexécutez les requêtes CloudWatch Logs Insights](CWL_Insights-Saving-Queries.md).
## Ajout d'une commande de filtre à l'exemple de requête
Ce didacticiel explique comment apporter une modification plus puissante à la requête dans l'éditeur de requête. Dans ce didacticiel, vous filtrez les résultats de la requête précédente basée sur un champ dans les événements du journal récupérés.
Si vous n'avez pas encore exécuté les didacticiels précédents, faites-le maintenant. Ce didacticiel commence au moment où le didacticiel précédent se termine.
**Pour ajouter une commande de filtre à la requête précédente**
1. Choisissez un champ à filtrer. Pour voir les champs les plus courants détectés par CloudWatch Logs dans les événements du journal contenus dans les groupes de journaux sélectionnés au cours des 15 dernières minutes, ainsi que le pourcentage de ces événements de journal dans lesquels chaque champ apparaît, sélectionnez **Champs** sur le côté droit de la page.
Pour afficher les champs contenus dans un événement de journal spécifique, choisissez l'icône située à gauche de cette ligne.
Le champ **awsRegion** peut s'afficher dans votre évènement de journal en fonction de la nature des événements qui se trouvent dans vos journaux. Pour le reste de ce didacticiel, nous utiliserons **awsRegion** en tant que champ de filtre, mais vous pouvez utiliser un autre champ si celui-ci n'est pas disponible.
1. Dans la zone de l'éditeur de requête, placez votre curseur après **50** et appuyez sur Entrée.
1. Sur la nouvelle ligne, commencez par entrer une barre verticale (« \$1 ») et un espace. Les commandes d'une requête CloudWatch Logs Insights doivent être séparées par le caractère pipe.
1. Saisissez **filter awsRegion="us-east-1"**.
1. Cliquez sur **Exécuter**.
La requête s'exécute à nouveau, et affiche désormais les 50 résultats les plus récents qui correspondent au nouveau filtre.
Si vous avez filtré sur un autre champ et obtenu un résultat d'erreur, il se peut que vous ayez besoin d'utiliser le nom du champ. Si le nom du champ inclut des caractères non alphanumériques, vous devez placer des guillemet inversés (`) avant et après le nom du champ (par exemple, **`error-code`="102"**).
Vous devez utiliser des guillemets inversés pour les noms de champs qui contiennent des caractères non alphanumériques, mais pas pour les valeurs. Les valeurs sont toujours entre guillemets (").
Logs Insights QL inclut de puissantes fonctionnalités de requête, notamment plusieurs commandes et la prise en charge des expressions régulières, des opérations mathématiques et statistiques. Pour de plus amples informations, veuillez consulter [CloudWatch Syntaxe des requêtes en langage Logs Insights](CWL_QuerySyntax.md).
# Didacticiel : Exécuter une requête avec une fonction d'agrégation
Vous pouvez utiliser des fonctions d'agrégation avec la commande `stats` et en tant qu'arguments pour d'autres fonctions. Dans ce didacticiel, vous exécutez une commande de requête qui compte le nombre d'événements du journal contenant un champ spécifié. La commande de requête renvoie un décompte total regroupé en fonction de la(des) valeur(s) du champ spécifié. Pour plus d'informations sur les fonctions d'agrégation, consultez la section [Opérations et fonctions prises en charge](https://docs.aws.amazon.com/en_us/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html#CWL_QuerySyntax-operations-functions) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
**Exécution d'une requête avec une fonction d'agrégation**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Vérifiez que l'onglet **Logs Insights QL** est sélectionné.
1. Dans la liste déroulante **Sélectionner les groupes de journaux**, choisissez un ou plusieurs groupes de journaux à interroger.
S'il s'agit d'un compte de surveillance dans le CloudWatch domaine de l'observabilité entre comptes, vous pouvez sélectionner des groupes de journaux dans les comptes sources ainsi que dans le compte de surveillance. Une seule requête peut interroger les journaux de différents comptes à la fois.
Vous pouvez filtrer les groupes de journaux par nom de groupe de journaux, ID de compte ou étiquette de compte.
Lorsque vous sélectionnez un groupe de CloudWatch journaux, Logs Insights détecte automatiquement les champs de données du groupe de journaux s'il s'agit d'un groupe de journaux de classe Standard. Pour consulter les champs découverts, sélectionnez le menu **Champs** en haut à droite de la page.
1. Supprimez la requête par défaut dans l'éditeur de requête et saisissez la commande suivante :
```
stats count(*) by fieldName
```
1. *fieldName*Remplacez-le par un champ découvert dans le menu **Champs**.
Le menu **Champs** se trouve en haut à droite de la page et affiche tous les champs découverts détectés par CloudWatch Logs Insights dans votre groupe de journaux.
1. Choisissez **Run** (Exécuter) pour consulter les résultats de requête.
Les résultats de requête indiquent le nombre de registres dans votre groupe de journaux qui correspondent à la commande de requête et le décompte total regroupé en fonction de la(des) valeur(s) du champ spécifié.
# Didacticiel : Exécuter une requête qui génère une visualisation groupée par champs de journal
Lorsque vous exécutez une requête qui utilise la fonction `stats` pour grouper les résultats renvoyés par les valeurs d'un ou de plusieurs champs dans les entrées du journal, vous pouvez afficher les résultats sous la forme d'un graphique à barres, d'un graphique circulaire, d'un graphique linéaire ou d'un graphique en aires empilées. Cela vous permet de visualiser plus efficacement les tendances dans vos journaux.
**Pour exécuter une requête pour générer une visualisation**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Dans la liste déroulante **Select log group(s)** (Sélectionner groupe(s) de journaux), choisissez un ou plusieurs groupes de journaux à interroger.
S'il s'agit d'un compte de surveillance dans le CloudWatch domaine de l'observabilité entre comptes, vous pouvez sélectionner des groupes de journaux dans les comptes sources ainsi que dans le compte de surveillance. Une seule requête peut interroger les journaux de différents comptes à la fois.
Vous pouvez filtrer les groupes de journaux par nom de groupe de journaux, ID de compte ou étiquette de compte.
1. Dans l'éditeur de requête, supprimez le contenu actuel, saisissez la fonction `stats` suivante, puis choisissez **Exécuter la requête**.
```
stats count(*) by @logStream
| limit 100
```
Les résultats indiquent le nombre d'événements de journal dans le groupe de journaux pour chaque flux de journaux. Les résultats sont limités à seulement 100 lignes.
1. Choisissez l'onglet **Visualisation**.
1. Sélectionnez la flèche en regard de **Ligne**, puis choisissez **Barre**.
Le graphique à barres apparaît, affichant une barre pour chaque flux de journaux du groupe de journaux.
# Didacticiel : Exécuter une requête qui produit des séries temporelles
Lorsque vous exécutez une requête qui utilise la fonction `bin()` pour regrouper les résultats renvoyés selon une période de temps, vous pouvez afficher les résultats sous forme de graphique linéaire, de graphique en aires empilées, de graphique circulaire ou de diagramme à barres. Cela vous aide à visualiser plus efficacement les tendances des événements du journal au fil du temps.
**Pour exécuter une requête pour générer une visualisation**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Vérifiez que l'onglet **Logs Insights QL** est sélectionné.
1. Dans la liste déroulante **Sélectionner les groupes de journaux**, choisissez un ou plusieurs groupes de journaux à interroger.
S'il s'agit d'un compte de surveillance dans le CloudWatch domaine de l'observabilité entre comptes, vous pouvez sélectionner des groupes de journaux dans les comptes sources ainsi que dans le compte de surveillance. Une seule requête peut interroger les journaux de différents comptes à la fois.
Vous pouvez filtrer les groupes de journaux par nom de groupe de journaux, ID de compte ou étiquette de compte.
1. Dans l'éditeur de requête, supprimez le contenu actuel, saisissez la fonction `stats` suivante, puis choisissez **Exécuter la requête**.
```
stats count(*) by bin(30s)
```
Les résultats indiquent le nombre d'événements du groupe de journaux reçus par CloudWatch Logs pour chaque période de 30 secondes.
1. Choisissez l’onglet **Visualisation**.
Les résultats sont affichés sous forme de graphique linéaire. Pour basculer vers un graphique à barres, un graphique circulaire ou un graphique en aires empilées, choisissez la flèche en regard de **Ligne** en haut à gauche du graphique.
# Exemples de requêtes
Cette section contient une liste de commandes de requête générales et utiles que vous pouvez exécuter dans la [CloudWatchconsole](https://console.aws.amazon.com/cloudwatch/). Pour plus d'informations sur l'exécution d'une commande de requête, consultez [Tutoriel : Exécuter et modifier un exemple de requête](https://docs.aws.amazon.com/en_us/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_RunSampleQuery.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
Pour plus d'informations sur la syntaxe des requêtes, consultez[CloudWatch Syntaxe des requêtes en langage Logs Insights](CWL_QuerySyntax.md).
**Topics**
+ [Requêtes générales](#CWL_QuerySyntax-examples-general)
+ [Requêtes pour les journaux Lambda](#CWL_QuerySyntax-examples-Lambda)
+ [Requêtes pour les journaux de flux Amazon VPC](#CWL_QuerySyntax-examples-VPC)
+ [Requêtes pour les journaux Route 53](#CWL_QuerySyntax-examples-Route53)
+ [Requêtes pour les CloudTrail journaux](#CWL_QuerySyntax-examples-CloudTrail)
+ [Requêtes pour Amazon API Gateway](#CWL_QuerySyntax-examples-APIGateway)
+ [Requêtes pour passerelle NAT](#CWL_QuerySyntax-examples-NATGateway)
+ [Requêtes pour les journaux du serveur Apache](#CWL_QuerySyntax-examples-Apache)
+ [Requêtes pour Amazon EventBridge](#CWL_QuerySyntax-examples-EventBridge)
+ [Exemples de la commande d'analyse.](#CWL_QuerySyntax-examples-parse)
## Requêtes générales
**Rechercher les 25 derniers événements ajoutés au journal.**
```
fields @timestamp, @message | sort @timestamp desc | limit 25
```
**Obtenir une liste du nombre d'exceptions par heure.**
```
filter @message like /Exception/
| stats count(*) as exceptionCount by bin(1h)
| sort exceptionCount desc
```
**Obtenir une liste des événements de journal qui ne sont pas des exceptions.**
```
fields @message | filter @message not like /Exception/
```
**Obtenir l'événement du journal le plus récent pour chaque valeur unique du champ `server`.**
```
fields @timestamp, server, severity, message
| sort @timestamp asc
| dedup server
```
**Obtenir l'événement du journal le plus récent pour chaque valeur unique du champ `server` pour chaque type de `severity`.**
```
fields @timestamp, server, severity, message
| sort @timestamp desc
| dedup server, severity
```
## Requêtes pour les journaux Lambda
**Déterminer la quantité de mémoire surallouée.**
```
filter @type = "REPORT"
| stats max(@memorySize / 1000 / 1000) as provisonedMemoryMB,
min(@maxMemoryUsed / 1000 / 1000) as smallestMemoryRequestMB,
avg(@maxMemoryUsed / 1000 / 1000) as avgMemoryUsedMB,
max(@maxMemoryUsed / 1000 / 1000) as maxMemoryUsedMB,
provisonedMemoryMB - maxMemoryUsedMB as overProvisionedMB
```
**Créer un rapport de latence.**
```
filter @type = "REPORT" |
stats avg(@duration), max(@duration), min(@duration) by bin(5m)
```
**Rechercher les invocations de fonctions lentes et éliminer les requêtes dupliquées qui peuvent résulter de nouvelles tentatives ou d'un code côté client. Dans cette requête, la valeur `@duration` est exprimée en millisecondes.**
```
fields @timestamp, @requestId, @message, @logStream
| filter @type = "REPORT" and @duration > 1000
| sort @timestamp desc
| dedup @requestId
| limit 20
```
## Requêtes pour les journaux de flux Amazon VPC
**Rechercher les 15 premiers transferts de paquets entre les hôtes :**
```
stats sum(packets) as packetsTransferred by srcAddr, dstAddr
| sort packetsTransferred desc
| limit 15
```
**Trouver les 15 premiers transferts d'octets pour des hôtes sur un sous-réseau donné.**
```
filter isIpv4InSubnet(srcAddr, "192.0.2.0/24")
| stats sum(bytes) as bytesTransferred by dstAddr
| sort bytesTransferred desc
| limit 15
```
**Rechercher les adresses IP qui utilisent UDP comme protocole de transfert de données.**
```
filter protocol=17 | stats count(*) by srcAddr
```
**Rechercher les adresses IP pour lesquelles des enregistrements de flux ont été ignorés durant la fenêtre de capture.**
```
filter logStatus="SKIPDATA"
| stats count(*) by bin(1h) as t
| sort t
```
**Trouver un enregistrement unique pour chaque connexion, afin de résoudre les problèmes de connectivité réseau.**
```
fields @timestamp, srcAddr, dstAddr, srcPort, dstPort, protocol, bytes
| filter logStream = 'vpc-flow-logs' and interfaceId = 'eni-0123456789abcdef0'
| sort @timestamp desc
| dedup srcAddr, dstAddr, srcPort, dstPort, protocol
| limit 20
```
## Requêtes pour les journaux Route 53
**Rechercher la distribution d'enregistrements par heure par type de requête.**
```
stats count(*) by queryType, bin(1h)
```
**Rechercher les 10 premiers résolveurs DNS avec le plus grand nombre de requêtes.**
```
stats count(*) as numRequests by resolverIp
| sort numRequests desc
| limit 10
```
**Rechercher le nombre d'enregistrements par domaine et sous-domaine où le serveur n'a pas pu résoudre la requête DNS.**
```
filter responseCode="SERVFAIL" | stats count(*) by queryName
```
## Requêtes pour les CloudTrail journaux
**Trouvez le nombre d'entrées de journal pour chaque service, type d'événement et AWS région.**
```
stats count(*) by eventSource, eventName, awsRegion
```
**Trouvez les hôtes Amazon EC2 qui ont été démarrés ou arrêtés dans une région donnée AWS .**
```
filter (eventName="StartInstances" or eventName="StopInstances") and awsRegion="us-east-2"
```
**Trouvez les AWS régions, les noms d'utilisateur et les ARNs utilisateurs IAM nouvellement créés.**
```
filter eventName="CreateUser"
| fields awsRegion, requestParameters.userName, responseElements.user.arn
```
**Rechercher le nombre d'enregistrements où une exception s'est produite lors de l'appel de l'API `UpdateTrail`.**
```
filter eventName="UpdateTrail" and ispresent(errorCode)
| stats count(*) by errorCode, errorMessage
```
**Rechercher les entrées de journal dans lesquelles TLS 1.0 ou 1.1 a été utilisé**
```
filter tlsDetails.tlsVersion in [ "TLSv1", "TLSv1.1" ]
| stats count(*) as numOutdatedTlsCalls by userIdentity.accountId, recipientAccountId, eventSource, eventName, awsRegion, tlsDetails.tlsVersion, tlsDetails.cipherSuite, userAgent
| sort eventSource, eventName, awsRegion, tlsDetails.tlsVersion
```
**Rechercher le nombre d'appels par service qui ont utilisé les versions TLS 1.0 ou 1.1**
```
filter tlsDetails.tlsVersion in [ "TLSv1", "TLSv1.1" ]
| stats count(*) as numOutdatedTlsCalls by eventSource
| sort numOutdatedTlsCalls desc
```
## Requêtes pour Amazon API Gateway
Trouver les 10 dernières erreurs 4XX
```
fields @timestamp, status, ip, path, httpMethod
| filter status>=400 and status<=499
| sort @timestamp desc
| limit 10
```
Identifiez les 10 Amazon API Gateway demandes les plus anciennes de votre groupe de journaux Amazon API Gateway d'accès
```
fields @timestamp, status, ip, path, httpMethod, responseLatency
| sort responseLatency desc
| limit 10
```
Renvoyer la liste des chemins d'API les plus populaires de votre groupe de journaux d'accès Amazon API Gateway
```
stats count(*) as requestCount by path
| sort requestCount desc
| limit 10
```
Créer un rapport de latence d'intégration pour votre groupe de journaux d'accès Amazon API Gateway
```
filter status=200
| stats avg(integrationLatency), max(integrationLatency),
min(integrationLatency) by bin(1m)
```
## Requêtes pour passerelle NAT
Si vous constatez des coûts plus élevés que d'habitude sur votre AWS facture, vous pouvez utiliser CloudWatch Logs Insights pour trouver les meilleurs contributeurs. Pour plus d'informations sur les commandes de requête suivantes, consultez [Comment puis-je trouver les principaux contributeurs au trafic via la passerelle NAT de mon VPC](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-find-traffic-sources-nat-gateway/) ? sur la page d'assistance AWS premium.
**Note**
Dans les commandes de requête suivantes, remplacez « x.x.x.x » par l'adresse IP privée de votre passerelle NAT et remplacez « y.y » par les deux premiers octets de votre plage CIDR VPC.
**Rechercher les instances qui envoient le plus de trafic via votre passerelle NAT.**
```
filter (dstAddr like 'x.x.x.x' and srcAddr like 'y.y.')
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc
| limit 10
```
**Déterminer le trafic qui va vers et en provenance des instances de vos passerelles NAT.**
```
filter (dstAddr like 'x.x.x.x' and srcAddr like 'y.y.') or (srcAddr like 'xxx.xx.xx.xx' and dstAddr like 'y.y.')
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc
| limit 10
```
**Déterminer les destinations Internet avec lesquelles les instances de votre VPC communiquent le plus souvent pour les chargements et les téléchargements.**
*****For uploads***** (Pour chargements)
```
filter (srcAddr like 'x.x.x.x' and dstAddr not like 'y.y.')
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc
| limit 10
```
*****Pour les téléchargements*****
```
filter (dstAddr like 'x.x.x.x' and srcAddr not like 'y.y.')
| stats sum(bytes) as bytesTransferred by srcAddr, dstAddr
| sort bytesTransferred desc
| limit 10
```
## Requêtes pour les journaux du serveur Apache
Vous pouvez utiliser CloudWatch Logs Insights pour interroger les journaux du serveur Apache. Pour plus d'informations sur les requêtes suivantes, consultez [Simplifier les journaux du serveur Apache avec CloudWatch Logs Insights sur](https://aws.amazon.com/blogs/mt/simplifying-apache-server-logs-with-amazon-cloudwatch-logs-insights/) le blog AWS Cloud Operations & Migrations.
**Trouver les champs les plus pertinents, afin de pouvoir consulter vos journaux d'accès et vérifier le trafic dans le chemin */admin* de votre application.**
```
fields @timestamp, remoteIP, request, status, filename| sort @timestamp desc
| filter filename="/var/www/html/admin"
| limit 20
```
**Trouver le nombre de requêtes GET uniques qui ont accédé à votre page principale avec le code d'état « 200 » (succès).**
```
fields @timestamp, remoteIP, method, status
| filter status="200" and referrer= http://34.250.27.141/ and method= "GET"
| stats count_distinct(remoteIP) as UniqueVisits
| limit 10
```
**Rechercher le nombre de fois où votre service Apache a redémarré.**
```
fields @timestamp, function, process, message
| filter message like "resuming normal operations"
| sort @timestamp desc
| limit 20
```
## Requêtes pour Amazon EventBridge
Obtenez le nombre d' EventBridge événements regroupés par type de détail d'événement
```
fields @timestamp, @message
| stats count(*) as numberOfEvents by `detail-type`
| sort numberOfEvents desc
```
## Exemples de la commande d'analyse.
**Utilisez une expression glob pour extraire les champs `@user`, `@method` et `@latency` à partir du champ de journal `@message` et renvoyer la latence moyenne pour chaque combinaison unique de `@method` et `@user`.**
```
parse @message "user=*, method:*, latency := *" as @user,
@method, @latency | stats avg(@latency) by @method,
@user
```
**Utilisez une expression régulière pour extraire les champs `@user2`, `@method2` et `@latency2` à partir du champ du journal `@message` et renvoyer la latence moyenne pour chaque combinaison unique de `@method2` et `@user2`.**
```
parse @message /user=(?.*?), method:(?.*?),
latency := (?.*?)/ | stats avg(latency2) by @method2,
@user2
```
**Extrait les champs `loggingTime`, `loggingType` et `loggingMessage`, filtre vers le bas pour journaliser les événements qui contiennent les chaînes `ERROR` ou `INFO`, puis affiche uniquement les champs `loggingMessage` et `loggingType` pour les événements qui contiennent une chaîne `ERROR`.**
```
FIELDS @message
| PARSE @message "* [*] *" as loggingTime, loggingType, loggingMessage
| FILTER loggingType IN ["ERROR", "INFO"]
| DISPLAY loggingMessage, loggingType = "ERROR" as isError
```
# Comparer (diff) avec les plages temporelles précédentes
Vous pouvez utiliser CloudWatch Logs Insights avec Logs Insights QL pour comparer l'évolution des événements de vos journaux au fil du temps. Vous pouvez comparer les événements du journal ingérés au cours d'une période récente avec les journaux de la période immédiatement précédente. Vous pouvez également effectuer une comparaison avec des périodes antérieures similaires. Cela peut vous aider à déterminer si une erreur dans vos journaux a été introduite récemment ou s'est déjà produite, et peut vous aider à identifier d'autres tendances.
Les requêtes de comparaison renvoient uniquement des modèles dans les résultats, et non des événements de journal bruts. Les modèles renvoyés vous aideront à voir rapidement les tendances et l'évolution des événements du journal au fil du temps. Après avoir exécuté une requête de comparaison et obtenu les résultats des modèles, vous pouvez consulter des exemples d'événements de log bruts correspondant aux modèles qui vous intéressent. Pour plus d'informations sur les modèles de journalisation, consultez[Analyse de modèles](CWL_AnalyzeLogData_Patterns.md).
Lorsque vous exécutez une requête de comparaison, celle-ci est analysée par rapport à deux périodes différentes : la période de requête initiale que vous avez sélectionnée et la période de comparaison. La période de comparaison est toujours d'une durée égale à celle de votre période de requête initiale. Les intervalles de temps par défaut pour les comparaisons sont les suivants.
+ **Période précédente** : compare avec la période immédiatement antérieure à la période de votre requête.
+ **Jour précédent** : compare avec la période du jour précédant la période de votre requête.
+ **Semaine précédente** : comparaison avec la période d'une semaine précédant la période de votre requête.
+ **Mois précédent** : comparaison avec la période d'un mois précédant la période de votre requête.
**Note**
Les requêtes utilisant des comparaisons entraînent des frais similaires à ceux de l'exécution d'une seule requête CloudWatch Logs Insights sur une période combinée. Pour en savoir plus, consultez [Tarification Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
**Pour exécuter une requête de comparaison**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, choisissez **Journaux**, **Informations sur les journaux**.
Une requête par défaut apparaît dans la zone de requête.
1. Vérifiez que l'onglet **Logs Insights QL** est sélectionné.
1. Conservez la requête par défaut ou entrez une autre requête.
1. Dans le menu déroulant **Sélectionner un ou plusieurs groupes de journaux**, choisissez un ou plusieurs groupes de journaux à interroger.
1. (Facultatif) Utilisez le sélecteur d'intervalle de temps pour sélectionner une période à interroger. La requête par défaut porte sur les données du journal de l'heure précédente.
1. Dans le sélecteur de plage horaire, choisissez **Comparer**. Choisissez ensuite la période précédente à laquelle vous souhaitez comparer les journaux d'origine, puis choisissez **Appliquer**.
1. Choisissez **Exécuter la requête**.
Pour que la requête récupère les données de la période de comparaison, la `diff` commande est ajoutée à votre requête.
1. Cliquez sur l'onglet **Motifs** pour voir les résultats.
Le tableau affiche les informations suivantes :
+ Chaque **modèle**, avec des parties variables du modèle remplacées par le symbole de jeton dynamique``. *string*Il s'agit d'une description du type de données que le jeton représente. *number*Indique où ce jeton apparaît dans le modèle, par rapport aux autres jetons dynamiques. Pour de plus amples informations, veuillez consulter [Analyse de modèles](CWL_AnalyzeLogData_Patterns.md).
+ Le **nombre d'événements** est le nombre d'événements du journal présentant ce modèle au cours de la période initiale plus récente.
+ Le **nombre d'événements** différentiels est la différence entre le nombre d'événements de journal correspondants au cours de la période en cours et celui de la période de comparaison. Une différence positive signifie qu'il y a davantage d'événements de ce type au cours de la période actuelle.
+ **La description de la différence** résume brièvement l'évolution de ce schéma entre la période en cours et la période de comparaison.
+ Le **type de gravité** est la gravité probable des événements du journal présentant ce modèle, sur la base de mots trouvés dans les événements du journal`FATAL`, tels que`ERROR`, et`WARN`.
1. Pour examiner plus en détail l'un des modèles de la liste, choisissez l'icône de l'un des modèles dans la colonne **Inspecter**.
Le volet **Pattern inspect** apparaît et affiche les informations suivantes :
+ Le **motif**. Sélectionnez un jeton dans le modèle pour analyser les valeurs de ce jeton.
+ Un histogramme indiquant le nombre d'occurrences du modèle sur la plage de temps demandée. Cela peut vous aider à identifier des tendances intéressantes, telles qu'une augmentation soudaine de l'occurrence d'un modèle.
+ L'onglet **Échantillons de journal** affiche quelques-uns des événements du journal correspondant au modèle sélectionné.
+ L'onglet **Valeurs du jeton** affiche les valeurs du jeton dynamique sélectionné, si vous en avez sélectionné un.
**Note**
Un maximum de 10 valeurs de jeton est capturée pour chaque jeton. Le nombre de jetons peut ne pas être précis. CloudWatch Logs utilise un compteur probabiliste pour générer le nombre de jetons, et non la valeur absolue.
+ L'onglet **Modèles associés** affiche d'autres modèles qui se sont produits fréquemment à peu près au même moment que le modèle que vous inspectez. Par exemple, si le modèle d'un `ERROR` message était généralement accompagné d'un autre événement de journal marqué comme `INFO` contenant des détails supplémentaires, ce modèle est affiché ici.
# Visualisation des données du journal dans des graphiques
Vous pouvez utiliser des visualisations telles que des diagrammes à barres, des graphiques linéaires et des graphiques à aires empilées pour identifier plus efficacement les modèles dans vos données de journal. CloudWatch Logs Insights génère des visualisations pour les requêtes qui utilisent la `stats` fonction et une ou plusieurs fonctions d'agrégation. Pour plus d'informations, veuillez consulter [stats](CWL_QuerySyntax-Stats.md).
# OpenSearch Langage de traitement canalisé (PPL)
Cette section contient une introduction de base à l'interrogation des CloudWatch journaux à l'aide de OpenSearch PPL. Avec PPL, vous pouvez récupérer, interroger et analyser des données à l'aide de commandes groupées, ce qui facilite la compréhension et la composition de requêtes complexes. Sa syntaxe est basée sur les canaux Unix et permet d'enchaîner les commandes pour transformer et traiter les données. Avec PPL, vous pouvez filtrer et agréger des données, et utiliser un ensemble complet de fonctions mathématiques, de chaîne, de date, conditionnelles et autres pour l'analyse.
L'inclusion `SOURCE` dans une requête PPL est un moyen utile de spécifier les groupes de journaux, les index de champs et les sources de données à inclure dans une requête lorsque vous utilisez l'API AWS CLI or pour créer une requête. La `SOURCE` commande est prise en charge uniquement dans l'API AWS CLI and, pas dans la CloudWatch console. Lorsque vous utilisez la CloudWatch console pour démarrer une requête, vous utilisez l'interface de console pour spécifier les groupes de journaux ainsi que le nom et le type de source de données.
`aws:fieldIndex`À utiliser pour renvoyer uniquement des données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. Les groupes de journaux pertinents sont automatiquement sélectionnés en fonction des champs spécifiés dans la `filterIndex` commande. Cela réduit le volume numérisé en ignorant les groupes de journaux qui ne contiennent aucun événement de journal contenant le champ spécifié dans la requête, et en analysant uniquement les groupes de journaux correspondant à la valeur spécifiée dans la requête pour cet index de champ. `aws:fieldIndex`À utiliser pour spécifier le nom du champ, ainsi que le nom et la valeur du champ dans la commande source afin d'interroger uniquement les données indexées contenant le champ et la valeur spécifiés. Pour de plus amples informations, consultez [Créez des index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation](CloudWatchLogs-Field-Indexing.md).
Vous pouvez utiliser OpenSearch PPL pour les requêtes de groupes de journaux dans la classe de journal standard.
**Note**
Pour plus d'informations sur toutes les commandes de requête OpenSearch PPL prises en charge dans les CloudWatch journaux et des informations détaillées sur la syntaxe et les restrictions, consultez la section [Commandes PPL prises en charge](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-ppl.html) dans le Guide du développeur OpenSearch de services.
Pour plus d'informations sur les autres langages de requête, vous pouvez utiliser [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html), [OpenSearch Service SQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_SQL.html) et [CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
| Commande ou fonction | Exemple de requête | Description |
| --- | --- | --- |
| fields | `fields field1, field2` | Affiche un ensemble de champs qui doivent être projetés. |
| joindre | `LEFT JOIN left=l, right=r on l.id = r.id `join_right_lg` \| fields l.field_1, r.field_2` | Joint deux ensembles de données. |
| où | `where field1="success" \| where field2 != "i-023fe0a90929d8822" \| fields field3, field4, field5,field6 \| head 1000` | Filtre les données en fonction des conditions que vous spécifiez. |
| AWS : Index des champs | `source = [`aws:fieldIndex`="region", `region` = "us-west-2"] \| where status = 200 \| head 10` | Renvoie uniquement les données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. |
| stats | `stats count(), count(field1), min(field1), max(field1), avg(field1) by field2 \| head 1000` | Effectue des agrégations et des calculs |
| parse | `parse field1 ".*/(?[^/]+$)" \| where field2 = "requestId" \| fields field1, field2 \| head 1000` | Extrait un modèle d'expression régulière (regex) d'une chaîne et affiche le modèle extrait. Le modèle extrait peut également être utilisé pour créer de nouveaux champs ou filtrer des données. |
| sort | `stats count(), count(field1), min(field1) as field1Alias, max(`field1`), avg(`field1`) by field2 \| sort -field1Alias \| head 1000` | Triez les résultats affichés par nom de champ. Utilisez le tri - FieldName pour trier par ordre décroissant. |
| eval | `eval field2 = field1 * 2 \| fields field1, field2 \| head 20` | Modifie ou traite la valeur d'un champ et la stocke dans un autre champ. Cela est utile pour modifier mathématiquement une colonne, appliquer des fonctions de chaîne à une colonne ou appliquer des fonctions de date à une colonne. |
| renommer | `rename field2 as field1 \| fields field1;` | Renomme un ou plusieurs champs dans les résultats de recherche. |
| head | `fields `@message` \| head 20` | Limite les résultats de requête affichés aux N premières lignes. |
| top | `top 2 field1 by field2` | Recherche les valeurs les plus fréquentes pour un champ. |
| dedup | `dedup field1 \| fields field1, field2, field3` | Supprime les entrées dupliquées en fonction des champs que vous spécifiez. |
| rare | `rare field1 by field2` | Recherche les valeurs les moins fréquentes de tous les champs de la liste de champs. |
| sous-requête | `where field_1 IN [ search source= `subquery_lg` \| fields field_2 ] \| fields id, field_1 ` | Exécute des requêtes complexes et imbriquées dans vos instructions PPL. |
| ligne de tendance | `trendline sma(2, field1) as field1Alias` | Calcule les moyennes mobiles des champs. |
| Statistiques de l'événement | `eventstats sum(field1) by field2` | Enrichissez les données de vos événements grâce à des statistiques récapitulatives calculées. Il analyse les champs spécifiés au sein de vos événements, calcule diverses mesures statistiques, puis ajoute ces résultats à chaque événement d'origine sous forme de nouveaux champs. |
| expand | `eval tags_array_string = json_extract(`@message`, '$.tags')\| eval tags_array = json_array(json_extract(tags_string, '$[0]'), json_extract(tags_string, '$[1]'))\| expand tags_array as color_tags` | Décompose un champ contenant plusieurs valeurs en lignes distinctes, en créant une nouvelle ligne pour chaque valeur du champ spécifié. |
| fillnull | `fields `@timestamp`, error_code, status_code \| fillnull using status_code = "UNKNOWN", error_code = "UNKNOWN"` | Remplit les champs nuls avec la valeur que vous fournissez. Il peut être utilisé dans un ou plusieurs domaines. |
| flatten | `eval metadata_struct = json_object('size', json_extract(metadata_string, '$.size'), 'color', json_extract(metadata_string, '$.color')) \| flatten metadata_struct as (meta_size, meta_color) ` | Aplatit un champ. Le champ doit être de ce type : `struct` ou`array>`. |
| cidrmatch | `where cidrmatch(ip, '2003:db8::/32') \| fields ip ` | Vérifie si l'adresse IP spécifiée se situe dans la plage CIDR donnée. |
| résumé du champ | `where field1 != 200 \| fieldsummary includefields= field1 nulls=true` | Calcule les statistiques de base pour chaque champ (nombre, nombre distinct, min, max, avg, stddev et moyenne). |
| grok | `grok email '.+@%{HOSTNAME:host}' \| fields email, host` | Analyse un champ de texte à l'aide d'un motif grok et ajoute les résultats au résultat de recherche. |
| Fonctions de chaîne | `eval field1Len = LENGTH(field1) \| fields field1Len` | Fonctions intégrées dans PPL qui peuvent manipuler et transformer des chaînes et des données de texte dans les requêtes PPL. Par exemple, convertir des majuscules, combiner des chaînes, extraire des parties et nettoyer du texte. |
| Fonctions date-heure | `eval newDate = ADDDATE(DATE('2020-08-26'), 1) \| fields newDate ` | Fonctions intégrées pour gérer et transformer les données de date et d'horodatage dans les requêtes PPL. Par exemple, date\$1add, date\$1format, datediff, date-sub, timestampadd, timestampdiff, current\$1timezone, utc\$1timestamp et current\$1date. |
| Fonctions de condition | `eval field2 = isnull(field1) \| fields field2, field1, field3` | Fonctions intégrées qui vérifient les conditions de champ spécifiques et évaluent les expressions de manière conditionnelle. Par exemple, si le champ 1 est nul, renvoie le champ 2. |
| Fonctions mathématiques | `eval field2 = ACOS(field1) \| fields field1` | Fonctions intégrées pour effectuer des calculs mathématiques et des transformations dans les requêtes PPL. Par exemple, abs (valeur absolue), round (arrondit les nombres), sqrt (racine carrée), pow (calcul de puissance) et ceil (arrondit au nombre entier le plus proche). |
| CryptoGraphic fonctions | `eval crypto = MD5(field)\| head 1000` | Pour calculer le hachage d'un champ donné |
| Fonctions JSON | `eval valid_json = json('[1,2,3,{"f1":1,"f2":[5,6]},4]') \| fields valid_json` | Fonctions intégrées pour gérer le JSON, notamment les tableaux, l'extraction et la validation. Par exemple, json\$1object, json\$1array, to\$1json\$1string, json\$1array\$1length, json\$1extract, json\$1keys et json\$1valid. |
## Étendue de la requête
L'inclusion de SOURCE dans une requête est un moyen utile de spécifier les groupes de journaux à inclure dans une requête lorsque vous utilisez l'API AWS CLI or pour créer une requête. La commande SOURCE n'est prise en charge que dans l'API AWS CLI and, pas dans la CloudWatch console. Lorsque vous utilisez la CloudWatch console pour démarrer une requête, vous utilisez l'interface de console pour spécifier les groupes de journaux ainsi que le nom et le type de source de données.
La commande source de PPL permet désormais de les spécifier de plusieurs manières :
1. Groupe de journaux
1. Index des champs - Nouveau
1. Source et type de données - Nouveau
### Groupe de journaux
La sélection de la source du groupe de journaux peut être utilisée lorsque les clients savent exactement quel ou quels groupes de journaux doivent être recherchés
```
source = [lg:`/aws/lambda/my-function`] | where status = 200 | head 10
```
### Index des champs
La sélection de sources basée sur l'index des champs réduit la quantité de données demandées en limitant les résultats aux seules données indexées lorsque vos filtres ciblent les champs qui ont été indexés. Les groupes de journaux pertinents sont automatiquement sélectionnés en fonction des champs spécifiés dans la `filterIndex` commande. Pour plus d'informations sur les index de champs et sur la façon de les créer, voir [Création d'index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation](CloudWatchLogs-Field-Indexing.md).
`aws:fieldIndex`À utiliser pour renvoyer uniquement des données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. Pour les groupes de journaux indexés sur ce champ, cela optimise davantage la requête en ignorant les groupes de journaux qui ne contiennent aucun événement de journal contenant le champ spécifié dans la requête pour le champ indexé. Il réduit encore le volume numérisé en essayant de scanner uniquement les événements de journal de ces groupes de journaux qui correspondent à la valeur spécifiée dans la requête pour cet index de champ. Pour plus d'informations sur les index de champs et sur la façon de les créer, voir Création d'index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation.
En PPL, `aws:fieldIndex` est utilisé pour spécifier quelles paires clé-valeur doivent être traitées comme des index. La syntaxe est la suivante
```
source = [`aws:fieldIndex`="region", `region` = "us-west-2"] | where status = 200 | head 10
```
Où :
1. ``aws:fieldIndex`="region"`identifie la région en tant qu'index de champ.
1. Remarque : Au lieu de =, les clients peuvent utiliser IN pour spécifier plusieurs index (exemple ci-dessous)
1. ``region`="us-west-2"`identifie la condition de filtre à appliquer
1. Remarque : Au lieu de =, les clients peuvent utiliser IN pour spécifier plusieurs valeurs (exemple ci-dessous)
Les clients peuvent spécifier plusieurs FieldIndexes comme suit
```
source = [`aws:fieldIndex` IN ("status", "region"), `status` = 200, `region` IN ("us-west-2", "us-east-1")] | head 10
```
### Source et type de données
La sélection basée sur la source de données et le type de source peut être utilisée lorsque les clients savent quelles sources de données exactes doivent être interrogées. Cette requête est exécutée sur un ou plusieurs groupes de journaux contenant la source de données et le type spécifiés.
```
source = [ds:`data_source.type`] | where status = 200 | head 10
```
#### PPL pris en charge pour les requêtes de sources de données
Pour prendre en charge le cas d'utilisation de l'interrogation de sources de données dans PPL, vous pouvez utiliser la clause de sélection de source dynamique. À l'aide de cette syntaxe, vous pouvez interroger des sources de données en les spécifiant dans la commande de recherche. Vous pouvez spécifier jusqu'à 10 sources de données.
**Syntaxe**
```
source=[ds:`DataSource1.Type1`, ds:`DataSource2.Type2`, ...ds:`DataSourcen.Typen`]
```
**Exemple de requête**
```
search source=[ds:`DataSource1.Type1`, ds:`DataSource2.Type2`] | fields field1, field2
```
### Exemple combiné
Les clients peuvent spécifier tous les opérateurs de sélection de source dans n'importe quel ordre et les résultats seront l'intersection de toutes les conditions appliquées.
Par exemple,/aws/lambda/my-function-1 peut contenir plusieurs sources et types de données, y compris une grande variété d'index. Lorsque la requête suivante a été exécutée, les résultats renvoyés ne comporteront que des événements de source et de type DataSource 1.Type1 répondant aux critères « status » = 200.
```
search source=[
ds:`DataSource1.Type1`,
lg:`/aws/lambda/my-function-1`,
`aws:fieldIndex` IN ("status"), `status` = 200
]
```
## Restrictions
Les restrictions suivantes s'appliquent lorsque vous utilisez OpenSearch PPL pour effectuer des requêtes dans CloudWatch Logs Insights.
+ Vous ne pouvez pas utiliser de commandes de jointure ou de sous-requête avec des requêtes de source de données.
# OpenSearch Langage de requête structuré (SQL)
Cette section contient une introduction de base à l'interrogation des CloudWatch journaux à l'aide de OpenSearch SQL. Il s'agit d'une option familière si vous avez l'habitude de travailler avec des bases de données relationnelles. OpenSearch SQL offre un sous-ensemble de fonctionnalités SQL, ce qui en fait un bon choix pour effectuer des requêtes ad hoc et des tâches d'analyse de données. Avec OpenSearch SQL, vous pouvez utiliser des commandes telles que SELECT, FROM, WHERE, GROUP BY, HAVING, ainsi que diverses autres commandes et fonctions SQL. Vous pouvez exécuter des tâches JOINs dans différents groupes de journaux, corréler les données entre les groupes de journaux à l'aide de sous-requêtes et utiliser le riche ensemble de fonctions JSON, mathématiques, de chaîne, conditionnelles et autres fonctions SQL pour effectuer une analyse approfondie des données de journal et de sécurité.
`filterIndex`À utiliser pour renvoyer uniquement des données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. Réduisez le volume numérisé en ignorant les groupes de journaux qui ne contiennent aucun événement de journal contenant le champ spécifié dans la requête, et en analysant uniquement les groupes de journaux correspondant à la valeur spécifiée dans la requête pour cet index de champ. `filterIndex`À utiliser pour spécifier le nom du champ, ainsi que le nom et la valeur du champ pour interroger uniquement les données indexées contenant le champ et la valeur spécifiés.
Vous pouvez utiliser le OpenSearch SQL pour les requêtes de groupes de journaux dans la classe de journal standard. SQL prend également en charge les requêtes à l'aide du nom et du type de source de données.
**Note**
Le tableau suivant répertorie les commandes et fonctions SQL prises en charge dans les CloudWatch journaux. Pour plus d'informations sur toutes les commandes OpenSearch SQL, y compris la syntaxe, consultez la section [Commandes SQL prises en charge](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-directquery-sql.html) dans le Guide du développeur de OpenSearch services.
Pour plus d'informations sur les autres langages de requête que vous pouvez utiliser, consultez [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html), [OpenSearch Service PPL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_PPL.html) et [CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html).
## Commandes SQL prises en charge
**Note**
Dans la colonne d'exemple de requête, remplacez le cas `` échéant en fonction de la source de données que vous interrogez.
| Commande ou fonction | Exemple de requête | Description |
| --- | --- | --- |
| SELECT | `SELECT `@message`, Operation FROM `LogGroupA`` | Affiche les valeurs projetées. |
| FROM | `SELECT `@message`, Operation FROM `LogGroupA`` | Clause intégrée qui spécifie les tables ou les vues sources à partir desquelles récupérer les données, prenant en charge différents types de jointures et de sous-requêtes. |
| WHERE | `SELECT * FROM `LogGroupA` WHERE Operation = 'x'` | Les filtres enregistrent les événements en fonction des critères de champ fournis. |
| Index des filtres | `SELECT * FROM `filterIndex('region' = 'us-east-1')` WHERE status = 200 LIMIT 10;` | Renvoie uniquement les données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. |
| GROUP BY | `SELECT `@logStream`, COUNT(*) as log_count FROM `LogGroupA` GROUP BY `@logStream`` | Les groupes enregistrent les événements par catégorie et trouvent la moyenne en fonction des statistiques. |
| HAVING | `SELECT `@logStream`, COUNT(*) as log_count FROM `LogGroupA` GROUP BY `@logStream` HAVING log_count > 100` | Filtre les résultats en fonction des conditions de regroupement. |
| ORDER BY | `SELECT * FROM `LogGroupA` ORDER BY `@timestamp` DESC` | Trie les résultats en fonction des champs de la clause ORDER BY. Vous pouvez trier par ordre décroissant ou croissant. |
| JOIN | `SELECT A.`@message`, B.`@timestamp`FROM `LogGroupA` as A INNER JOIN `LogGroupB` as B ON A.`requestId` = B.`requestId`` | Joint les résultats de deux tables en fonction de champs communs. La jointure interne ou la jointure externe gauche doivent être spécifiées |
| LIMIT | `Select * from `LogGroupA` limit 10` | Limite les résultats de requête affichés aux N premières lignes. |
| Fonctions de chaîne | `SELECT upper(Operation) , lower(Operation), Operation FROM `LogGroupA`` | Fonctions intégrées dans SQL permettant de manipuler et de transformer des chaînes de caractères et des données textuelles dans des requêtes SQL. Par exemple, convertir des majuscules, combiner des chaînes, extraire des parties et nettoyer du texte. |
| Fonctions de date | `SELECT current_date() as today, date_add(current_date(), 30) as thirty_days_later, last_day(current_date()) as month_end FROM `LogGroupA`` | Fonctions intégrées pour gérer et transformer les données de date et d'horodatage dans les requêtes SQL. Par exemple, date\$1add, date\$1format, datediff et current\$1date. |
| Fonctions conditionnelles | `SELECT Operation, IF(Error > 0, 'High', 'Low') as error_category FROM `LogGroupA`;` | Fonctions intégrées qui exécutent des actions en fonction de conditions spécifiées ou qui évaluent les expressions de manière conditionnelle. Par exemple, CASE et IF. |
| Fonctions d’agrégation | `SELECT AVG(bytes) as bytesWritten FROM `LogGroupA`` | Fonctions intégrées qui effectuent des calculs sur plusieurs lignes pour produire une seule valeur résumée. Par exemple, SUM, COUNT, AVG, MAX et MIN. |
| Fonctions JSON | `SELECT get_json_object(json_column, '$.name') as name FROM `LogGroupA`` | Fonctions intégrées pour analyser, extraire, modifier et interroger des données au format JSON dans des requêtes SQL (par exemple, from\$1json, to\$1json, get\$1json\$1object, json\$1tuple) permettant de manipuler les structures JSON dans les ensembles de données. |
| Fonctions de tableau | `SELECT scores, size(scores) as length, array_contains(scores, 90) as has_90 FROM `LogGroupA`;` | Fonctions intégrées permettant de travailler avec des colonnes de type tableau dans les requêtes SQL, permettant des opérations telles que l'accès, la modification et l'analyse de données de tableau (par exemple, size, explode, array\$1contains). |
| Fonctions de fenêtrage | `SELECT field1, field2, RANK() OVER (ORDER BY field2 DESC) as field2Rank FROM `LogGroupA`;` | Fonctions intégrées qui effectuent des calculs sur un ensemble spécifique de lignes liées à la ligne actuelle (fenêtre), permettant des opérations telles que le classement, les totaux cumulés et les moyennes mobiles. Par exemple, ROW\$1NUMBER, RANK, LAG et LEAD |
| Fonctions de conversion | `SELECT CAST('123' AS INT) as converted_number, CAST(123 AS STRING) as converted_string FROM `LogGroupA`` | Fonctions intégrées pour convertir les données d'un type à un autre dans les requêtes SQL, permettant des transformations de type de données et des conversions de format. Par exemple, CAST, TO\$1DATE, TO\$1TIMESTAMP et BINARY. |
| Fonctions de prédicat | `SELECT scores, size(scores) as length, array_contains(scores, 90) as has_90 FROM `LogGroupA`;` | Fonctions intégrées qui évaluent les conditions et renvoient des valeurs booléennes (vrai/faux) en fonction de critères ou de modèles spécifiés. Par exemple, IN, LIKE, BETWEEN, IS NULL et EXISTS. |
| Sélectionnez plusieurs groupes de journaux | `SELECT lg1.field1, lg1.field2 from `logGroups( logGroupIdentifier: ['LogGroup1', 'LogGroup2'])` as lg1 where lg1.field3= "Success"` | Vous permet de spécifier plusieurs groupes de journaux dans une instruction SELECT |
| Sélectionnez plusieurs sources de données | `SELECT ds1.field1, ds1.field2 from `dataSource(['DataSource1', 'DataSource2'])` as ds1 where ds1.field3= "Success"` | Vous permet de spécifier plusieurs sources de données dans une instruction SELECT |
## SQL pris en charge pour les multi-log-group requêtes
Pour prendre en charge le cas d'utilisation permettant d'interroger plusieurs groupes de journaux dans SQL, vous pouvez utiliser la `logGroups` commande. À l'aide de cette syntaxe, vous pouvez interroger plusieurs groupes de journaux en les spécifiant dans la commande FROM.
Syntaxe :
```
`logGroups(
logGroupIdentifier: ['LogGroup1','LogGroup2', ...'LogGroupn']
)
```
Dans cette syntaxe, vous pouvez spécifier jusqu'à 50 groupes de journaux dans le `logGroupIdentifier` paramètre. Pour référencer des groupes de journaux dans un compte de surveillance, utilisez ARNs plutôt que des `LogGroup` noms.
Exemple de requête :
```
SELECT LG1.Column1, LG1.Column2 from `logGroups(
logGroupIdentifier: ['LogGroup1', 'LogGroup2']
)` as LG1 WHERE LG1.Column1 = 'ABC'
```
La syntaxe suivante impliquant plusieurs groupes de journaux après l'`FROM`instruction n'est PAS prise en charge lors de l'interrogation CloudWatch des journaux.
```
SELECT Column1, Column2 FROM 'LogGroup1', 'LogGroup2', ...'LogGroupn'
WHERE Column1 = 'ABC'
```
## SQL pris en charge pour les requêtes de source de données
Pour faciliter l'utilisation des requêtes de sources de données dans SQL, vous pouvez utiliser la commande DataSource. À l'aide de cette syntaxe, vous pouvez interroger des sources de données en les spécifiant dans la `FROM` commande. Vous pouvez spécifier jusqu'à 10 sources de données.
**Syntaxe**
```
`dataSource(
['DataSource1', 'DataSource2', ...'DataSourcen']
)`
```
**Exemple de requête**
```
SELECT DS1.Column1, DS1.Column2 from `dataSource(
['DataSource1', 'DataSource2']
)` as DS1 WHERE DS1.Column1 = 'ABC'
```
## Étendue de la requête
Dans l'API AWS CLI and, vous pouvez spécifier les journaux à interroger en utilisant le groupe de journaux, la source et le type de données, ainsi que les index des champs.
### Groupe de journaux
La sélection de la source du groupe de journaux peut être utilisée lorsque les clients savent exactement quel ou quels groupes de journaux doivent être recherchés
```
SELECT * FROM `logGroups(logGroupIdentifier: ['/aws/lambda/my-function'])`;
```
### Source et type de données
Les clients peuvent interroger leurs journaux en utilisant le nom et le type de source de données.
La sélection basée sur la source de données et le type de source peut être utilisée lorsque les clients savent quelles sources de données exactes doivent être interrogées. Cette requête est exécutée sur un ou plusieurs groupes de journaux contenant la source de données et le type spécifiés.
Pour faciliter l'utilisation des requêtes de sources de données dans SQL, vous pouvez utiliser la commande DataSource. À l'aide de cette syntaxe, vous pouvez interroger des sources de données en les spécifiant dans la commande FROM. Vous pouvez spécifier jusqu'à 10 sources de données.
Syntaxe :
```
`dataSource(
['DataSource1.Type1', 'DataSource2.Type2', ...'DataSourcen.Typen']
)`
```
Exemple de requête :
```
SELECT DS1.Column1, DS1.Column2 from `dataSource(
['DataSource1.Type1', 'DataSource2.Type2']
)` as DS1 WHERE DS1.Column1 = 'ABC'
```
Pour plus d'informations sur les requêtes par sources de données, consultez[Utilisez des facettes pour regrouper et explorer les journaux](CloudWatchLogs-Facets.md).
### Exemple combiné
Les clients peuvent spécifier tous les opérateurs de sélection de source dans les backticks dans n'importe quel ordre et les résultats seront basés sur l'intersection de toutes les conditions appliquées.
Par exemple,/aws/lambda/my-function-1 peut contenir plusieurs sources et types de données, y compris une grande variété d'index. Lorsque la requête suivante a été exécutée, les résultats renvoyés ne comporteront que des événements de source et de type DataSource 1.Type1 répondant aux critères « status » = 200.
```
SELECT * FROM `
logGroups(logGroupIdentifier: ['/aws/lambda/my-function'])
filterIndex('status' = 200)
dataSource(['DataSource1.Type1'])
`;
```
### Index des champs
La sélection de source basée sur l'index des champs identifie automatiquement les groupes de journaux pertinents lorsque vos filtres ciblent les champs indexés, réduisant ainsi le volume de numérisation et le temps d'exécution des requêtes.
`filterIndex`À utiliser pour renvoyer uniquement des données indexées, en forçant une requête à analyser uniquement les groupes de journaux indexés sur un champ que vous spécifiez dans la requête. Pour les groupes de journaux indexés sur ce champ, cela optimise davantage la requête en ignorant les groupes de journaux qui ne contiennent aucun événement de journal contenant le champ spécifié dans la requête pour le champ indexé. Il réduit encore le volume numérisé en essayant de scanner uniquement les événements de journal de ces groupes de journaux qui correspondent à la valeur spécifiée dans la requête pour cet index de champ. Pour plus d'informations sur les index de champs et sur la façon de les créer, voir [Création d'index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation](CloudWatchLogs-Field-Indexing.md).
En SQL, FilterIndex est utilisé pour spécifier quelles paires clé-valeur doivent être traitées comme des index. La syntaxe est la suivante
```
SELECT * FROM `filterIndex('region' = 'us-east-1')`;
```
Où :
1. FilterIndex (...) indique de traiter les valeurs clés qu'elles contiennent comme des index de champs. Chaque paire clé-valeur est séparée par une virgule (exemple ci-dessous)
1. 'region' = 'us-east-1' indique la condition réelle à appliquer
1. Remarque : Au lieu de =, les clients peuvent utiliser IN pour spécifier plusieurs valeurs (exemple ci-dessous)
L'utilisation de plusieurs FilterIndex combinerait les conditions en utilisant « AND ». Dans l'exemple, les journaux correspondant à status=200 et à la région dans us-east-1 ou us-west-2 seraient interrogés.
```
SELECT * FROM `filterIndex('status' = 200, 'region' IN ['us-east-1', 'us-west-2'])`;
```
## Restrictions
Les restrictions suivantes s'appliquent lorsque vous utilisez OpenSearch SQL pour effectuer des requêtes dans CloudWatch Logs Insights.
+ Vous ne pouvez inclure qu'un seul JOIN dans une instruction SELECT.
+ Vous ne pouvez pas utiliser JOIN ou des sous-requêtes avec des requêtes de source de données.
+ Un seul niveau de sous-requêtes imbriquées est pris en charge.
+ Les requêtes d'instruction multiples séparées par des points-virgules (;) ne sont pas prises en charge.
+ Les requêtes contenant des noms de champs identiques mais ne différant que dans certains cas (tels que field1 et FIELD1) ne sont pas prises en charge.
Par exemple, la requête suivante n'est pas prise en charge :
```
Select AWSAccountId, AwsAccountId from LogGroup
```
Cependant, la requête suivante est prise en charge car le nom du champ (`@logStream`) est identique dans les deux groupes de journaux :
```
Select a.`@logStream`, b.`@logStream` from Table A INNER Join Table B on a.id = b.id
```
+ Les fonctions et expressions doivent agir sur les noms de champs et faire partie d'une instruction SELECT avec un groupe de journaux spécifié dans la clause FROM.
Par exemple, cette requête n'est pas prise en charge :
```
SELECT cos(10) FROM LogGroup
```
Cette requête est prise en charge :
```
SELECT cos(field1) FROM LogGroup
```
+ Lorsque vous utilisez des commandes SQL ou PPL, entourez certains champs de backticks pour les interroger correctement. Les champs contenant des caractères spéciaux (non alphabétiques et non numériques) doivent être cochés. Par exemple, joignez `@message``Operation.Export`, et entre `Test::Field` backticks. Il n'est pas nécessaire de placer les champs avec des noms purement alphabétiques en backticks.
Exemple de requête avec des champs simples :
```
SELECT SessionToken, Operation, StartTime FROM `LogGroup-A`
LIMIT 1000;
```
Requête similaire avec backticks ajoutés :
```
SELECT `@SessionToken`, `@Operation`, `@StartTime` FROM `LogGroup-A` LIMIT 1000;
```
# Utiliser le langage naturel pour générer et mettre à jour CloudWatch les requêtes Logs Insights
CloudWatch Logs prend en charge une fonctionnalité de requête en langage naturel pour vous aider à générer et à mettre à jour des requêtes pour [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html), [OpenSearch Service PPL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_PPL.html), [OpenSearch Service SQL](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_SQL.html) et [CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html).
Grâce à cette fonctionnalité, vous pouvez poser des questions ou décrire les données des CloudWatch journaux que vous recherchez dans un langage clair. La fonctionnalité de langage naturel génère une requête en fonction d'une invite que vous entrez et fournit une line-by-line explication du fonctionnement de la requête. Vous pouvez également mettre à jour votre requête pour examiner plus en détail vos données.
En fonction de votre environnement, vous pouvez saisir des messages tels que « Quelles sont les 100 principales adresses IP sources en octets transférés ? » et « Trouvez les 10 requêtes de fonction Lambda les plus lentes ».
**Note**
La fonction de requête en langage naturel est un service régional. Pour certaines régions, la fonction effectue des appels interrégionaux vers des régions des États-Unis pour traiter les invites de requête. Pour plus d'informations, consultez [Amazon CloudWatch étend la prise en charge des régions pour le résumé des résultats de requêtes en langage naturel et la génération de requêtes](https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-cloudwatch-region-support-query-result-summarization-query-generation/).
Pour générer une requête CloudWatch Logs Insights avec cette fonctionnalité, ouvrez l'éditeur de requêtes CloudWatch Logs Insights, sélectionnez le groupe de journaux que vous souhaitez interroger, puis choisissez **Generate query**.
**Important**
Pour utiliser la fonctionnalité de requête en langage naturel, vous devez être connecté avec les politiques [CloudWatchLogsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsFullAccess.html),, [CloudWatchLogsReadOnlyAccess[AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html)](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLogsReadOnlyAccess.html), ou [ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ReadOnlyAccess.html)IAM, ou vous devez disposer de l'`cloudwatch:GenerateQuery`autorisation.
## Exemples de requêtes
Les exemples de cette section décrivent comment générer et mettre à jour des requêtes à l’aide de la fonctionnalité de langage naturel.
**Note**
Pour plus d'informations sur l'éditeur de requêtes et la syntaxe de CloudWatch Logs Insights, voir [Syntaxe de requête CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html).
### Exemples : générer une requête en langage naturel
Pour générer une requête en langage naturel, saisissez une invite et choisissez **Générer une nouvelle requête**. Cet exemple montre les requêtes qui effectuent une recherche de base.
**Invite**
Voici un exemple d'invite qui indique à la fonctionnalité de rechercher les 10 appels de fonction Lambda les plus lents.
```
Find the 10 slowest requests
```
**Query**
Voici la requête utilisant le langage de requête CloudWatch Logs Insights généré par la fonctionnalité de langage naturel en fonction de l'invite. Remarquez comment l’invite apparaît dans un commentaire avant la requête. Après la requête, vous pouvez lire une explication qui décrit son fonctionnement.
```
# Find the 10 slowest requests
fields @timestamp, @message, @duration
| sort @duration desc
| limit 10
# This query retrieves the timestamp, message and duration fields from the logs and sorts them in descending order by duration to find the 10 slowest requests.
```
**Note**
Pour désactiver l’affichage de votre invite et de l’explication du fonctionnement de la requête, utilisez l’icône en forme de roue dentée dans votre éditeur.
**Invite**
Pour générer une requête OpenSearch SQL, sélectionnez l'onglet OpenSearch SQL, puis ouvrez la boîte de dialogue du générateur de requêtes pour saisir votre invite en langage naturel. Voici un exemple d'invite qui utilise la fonctionnalité du langage naturel pour générer une requête OpenSearch SQL.
```
Give me the number of errors and exceptions per hour
```
**Query**
Voici la requête SQL générée par cette invite que vous pouvez utiliser pour trouver le nombre d'erreurs et d'exceptions agrégées par heure :
```
SELECT DATE_FORMAT(`@timestamp`, 'yyyy-MM-dd HH') AS hour,
COUNT(*) AS error_count
FROM `/aws/lambda/CloudWatchOdysseyQueryGen`
WHERE `@message` LIKE '%error%'
OR `@message` LIKE '%exception%'
GROUP BY DATE_FORMAT(`@timestamp`, 'yyyy-MM-dd HH')
ORDER BY hour
```
**Invite**
Pour générer une requête OpenSearch PPL, sélectionnez l'onglet OpenSearch PPL, puis ouvrez la boîte de dialogue du générateur de requêtes pour saisir votre invite en langage naturel. Voici un exemple d'invite qui utilise la fonctionnalité du langage naturel pour générer une requête OpenSearch PPL.
```
Give me all unique exception messages
```
**Query**
Voici la requête PPL générée par cette invite que vous pouvez utiliser pour rechercher les messages d'exception uniques dans vos journaux :
```
dedup @message
| fields @message
```
### Exemple : mettre à jour une requête en langage naturel
Vous pouvez mettre à jour une requête en modifiant l’invite initiale, puis en choisissant **Mettre à jour la requête**.
**Invite mise à jour**
L’exemple suivant présente une version mise à jour de la requête précédente. Au lieu d'une invite qui recherche les 10 appels de fonction Lambda les plus lents, cette invite indique désormais à la fonctionnalité de rechercher les 20 appels de fonction Lambda les plus lents et d'inclure une autre colonne pour les événements de journal supplémentaires.
```
Show top 20 slowest requests instead and display requestId as a column
```
**Requête mise à jour**
Voici un exemple de requête mise à jour à l'aide du langage de requête CloudWatch Logs Insights. Remarquez comment l’invite mise à jour apparaît dans un commentaire avant la requête mise à jour. Après la requête, vous pouvez lire une explication qui décrit comment la requête d’origine a été mise à jour.
```
# Show top 20 slowest requests instead and display requestId as a column
fields @timestamp, @message, @requestId, @duration
| sort @duration desc
| limit 20
# This query modifies the original query by replacing the @message field with the @requestId field and changing the limit from 10 to 20 to return the top 20 log events by duration instead of the top 10.
```
## Refus d’utiliser vos données pour améliorer le service
Les données d’invite en langage naturel que vous fournissez pour entraîner le modèle d’IA et générer des requêtes pertinentes ne sont utilisées que pour fournir et maintenir votre service. Ces données peuvent être utilisées pour améliorer la qualité de CloudWatch Logs Insights. Votre confiance, la confidentialité et la sécurité de votre contenu constituent nos priorités N° 1. Pour plus d’informations, veuillez consulter les rubriques [Conditions de service AWS](https://aws.amazon.com/service-terms/) et [AWS responsible AI policy](https://aws.amazon.com/machine-learning/responsible-ai/policy/).
Vous pouvez refuser que votre contenu soit utilisé pour développer ou améliorer la qualité des requêtes en langage naturel en créant une politique de désinscription des services d’IA. Pour désactiver la collecte de données pour toutes les fonctionnalités de CloudWatch Logs AI, y compris la fonctionnalité de génération de requêtes, vous devez créer une politique de désinscription pour CloudWatch Logs. Pour plus d’informations, consultez [Politiques de désactivation des services IA](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html) dans le *Guide de l’utilisateur AWS Organizations *.
# Journaux pris en charge et champs découverts
CloudWatch Logs Insights prend en charge différents types de journaux. Pour chaque journal envoyé à un groupe de journaux de classe Standard dans Amazon CloudWatch Logs, CloudWatch Logs Insights génère automatiquement cinq champs système :
+ `@message` contient l'événement de journal non analysé brut. C'est l'équivalent du `message` champ dans [InputLogevent](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_InputLogEvent.html).
+ `@timestamp` contient l'horodatage de l'événement dans le champ `timestamp` de l'événement du journal. C'est l'équivalent du `timestamp` champ dans [InputLogevent](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_InputLogEvent.html).
+ `@ingestionTime`contient l'heure à laquelle CloudWatch Logs a reçu l'événement du journal.
+ `@logStream` contient le nom du flux de journaux auquel l'événement de journal a été ajouté. Les flux de journaux regroupent les journaux à travers le même processus qui les a générés.
+ `@log` est un identificateur de groupe de journaux sous la forme de `account-id:log-group-name`. Lors de la requête de plusieurs groupes de journaux, cela peut être utile d'identifier le groupe de journaux auquel appartient un événement particulier.
+ `@entity`contient du JSON aplati lié aux entités pour la fonctionnalité de [télémétrie associée à Explore](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ExploreRelated.html).
Par exemple, ce JSON peut représenter une entité.
```
{
"Entity": {
"KeyAttributes": {
"Type": "Service",
"Name": "PetClinic"
},
"Attributes": {
"PlatformType": "AWS::EC2",
"EC2.InstanceId": "i-1234567890123"
}
}
}
```
Pour cette entité, les champs système extraits seraient les suivants :
```
@entity.KeyAttributes.Type = Service
@entity.KeyAttributes.Name = PetClinic
@entity.Attributes.PlatformType = AWS::EC2
@entity.Attributes.EC2.InstanceId = i-1234567890123
```
**Note**
La découverte de champs n'est prise en charge que pour les groupes de journaux de la classe de journaux standard. Pour plus d'informations sur les classes de log, consultez[Classes de log](CloudWatch_Logs_Log_Classes.md).
CloudWatch Logs Insights insère le symbole **@** au début des champs qu'il génère.
Pour de nombreux types de CloudWatch journaux, Logs découvre également automatiquement les champs de journal contenus dans les journaux. Ces champs de détection automatique figurent dans le tableau suivant.
Pour les autres types de journaux contenant des champs que CloudWatch Logs Insights ne découvre pas automatiquement, vous pouvez utiliser la `parse` commande pour extraire et créer des champs extraits à utiliser dans cette requête. Pour de plus amples informations, veuillez consulter [CloudWatch Syntaxe des requêtes en langage Logs Insights](CWL_QuerySyntax.md).
Si le nom d'un champ de journal découvert commence par le `@` caractère, CloudWatch Logs Insights l'affiche avec un ajout `@` ajouté au début. Par exemple, si un nom de champ de journal est `@example.com`, ce nom de champ s'affiche sous la forme de `@@example.com`.
**Note**
À l'exception de `@message``@timestamp`, ou`@log`, vous pouvez créer des index de champs pour les champs découverts. Pour plus d'informations sur les index de champs, consultez[Créez des index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation](CloudWatchLogs-Field-Indexing.md).
| Type de journal | Champs de journal détectés |
| --- | --- |
| Journaux de flux Amazon VPC | `@timestamp`, `@logStream`, `@message`, `accountId`, `endTime`, `interfaceId`, `logStatus`, `startTime`, `version`, `action`, `bytes`, `dstAddr`, `dstPort`, `packets`, `protocol`, `srcAddr`, `srcPort` |
| Journaux Route 53 | `@timestamp`, `@logStream`, `@message`, `edgeLocation`, `ednsClientSubnet`, `hostZoneId`, `protocol`, `queryName`, `queryTimestamp`, `queryType`, `resolverIp`, `responseCode`, `version` |
| Journaux Lambda | `@timestamp`, `@logStream`, `@message`, `@requestId`, `@duration, ``@billedDuration`, `@type`, `@maxMemoryUsed`, `@memorySize` Si une ligne de journal Lambda contient un ID de suivi X-Ray, elle inclut également les champs suivants : `@xrayTraceId` et `@xraySegmentId`. CloudWatch Logs Insights découvre automatiquement les champs de journal dans les journaux Lambda, mais uniquement pour le premier fragment JSON intégré à chaque événement de journal. Si un événement de journal Lambda contient plusieurs fragments JSON, vous pouvez analyser et extraire les champs de journal à l'aide de la commande `parse`. Pour de plus amples informations, veuillez consulter [Champs des journaux JSON](#CWL_AnalyzeLogData-discoverable-JSON-logs). |
| CloudTrail journaux Journaux au format JSON | Pour plus d'informations, consultez [Champs des journaux JSON](#CWL_AnalyzeLogData-discoverable-JSON-logs). |
| Autres types de journaux | `@timestamp`, `@ingestionTime`, `@logStream`, `@message`, `@log`. |
## Champs des journaux JSON
Avec CloudWatch Logs Insights, vous utilisez la notation par points pour représenter les champs JSON. Cette section contient un exemple d'événement JSON et un extrait de code qui montre comment vous pouvez accéder aux champs JSON à l'aide de la notation par points.
**Exemple : événement JSON**
```
{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EX_PRINCIPAL_ID",
"arn": "arn: aws: iam: : 123456789012: user/Alice",
"accessKeyId": "EXAMPLE_KEY_ID",
"accountId": "123456789012",
"userName": "Alice"
},
"eventTime": "2014-03-06T21: 22: 54Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "StartInstances",
"awsRegion": "us-east-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "ec2-api-tools1.6.12.2",
"requestParameters": {
"instancesSet": {
"items": [
{
"instanceId": "i-abcde123"
}
]
}
},
"responseElements": {
"instancesSet": {
"items": [
{
"instanceId": "i-abcde123",
"currentState": {
"code": 0,
"name": "pending"
},
"previousState": {
"code": 80,
"name": "stopped"
}
}
]
}
}
}
```
L'exemple d'événement JSON contient un objet nommé `userIdentity`. `userIdentity` contient un champ nommé `type`. Pour représenter la valeur de `type` à l'aide de la notation par points, vous utilisez `userIdentity.type`.
L'exemple d'événement JSON contient des matrices qui s'aplatissent en listes de noms et de valeurs de champs imbriqués. Pour représenter la valeur de `instanceId` pour le premier élément de `requestParameters.instancesSet`, vous utilisez `requestParameters.instancesSet.items.0.instanceId`. Le numéro `0` placé avant le champ `instanceID` fait référence à la position des valeurs pour le champ `items`. L'exemple suivant contient un extrait de code qui montre comment vous pouvez accéder aux champs JSON imbriqués dans un événement du journal JSON.
**Exemple : requête**
```
fields @timestamp, @message
| filter requestParameters.instancesSet.items.0.instanceId="i-abcde123"
| sort @timestamp desc
```
L'extrait de code affiche une requête qui utilise la notation par points avec la commande `filter` pour accéder à la valeur du champ JSON imbriqué `instanceId`. La requête filtre les messages dont la valeur de `instanceId` équivaut à `"i-abcde123"` et renvoie tous les événements du journal contenant la valeur spécifiée.
**Note**
CloudWatch Logs Insights peut extraire un maximum de 200 champs d'événements de journal à partir d'un journal JSON. Pour les champs supplémentaires non extraits, vous pouvez utiliser la commande `parse` pour extraire ces champs à partir de l'événement du journal non analysé brut dans le champ de message. Pour plus d'informations sur la `parse` commande, consultez la section [Syntaxe des requêtes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) dans le guide de CloudWatch l'utilisateur Amazon.
# Créez des index de champs pour améliorer les performances des requêtes et réduire le volume de numérisation
Vous pouvez créer des *index des* champs de votre journal des événements pour des recherches efficaces basées sur l'égalité. Lorsque vous utilisez ensuite un index de champ dans une requête CloudWatch Logs Insights, la requête tente d'ignorer le traitement des événements du journal dont on sait qu'ils n'incluent pas le champ indexé. Cela réduit le volume de numérisation de vos requêtes qui utilisent des index de champs, ce qui permet de renvoyer des résultats plus rapidement. Cela peut vous aider à rechercher rapidement des pétaoctets de journaux au total dans des milliers de groupes de journaux et à affiner les journaux pertinents plus rapidement. Les bons champs à indexer sont ceux que vous devez souvent rechercher. Les champs dont la cardinalité des valeurs est élevée sont également de bons candidats pour les index de champs, car une requête utilisant ces index de champs se terminera plus rapidement car cela limite les événements du journal qui sont mis en correspondance avec la valeur cible.
Supposons, par exemple, que vous ayez créé un index de champ pour`requestId`. Ensuite, toute requête CloudWatch Logs Insights sur ce groupe de journaux qui inclut `requestId = value` ou `requestId IN [value, value, ...]` tentera de traiter uniquement les événements du journal dont on sait qu'ils contiennent ce champ indexé et la valeur demandée, et que CloudWatch Logs a détecté une valeur pour ce champ dans le passé.
Vous pouvez également tirer parti de vos index de champs pour créer des requêtes efficaces portant sur un plus grand nombre de groupes de journaux. Lorsque vous utilisez la `filterIndex` commande dans votre requête au lieu de la `filter` commande elle-même, celle-ci est exécutée sur des groupes de journaux sélectionnés sur des événements de journal comportant des index de champs. Ces requêtes peuvent analyser jusqu'à 10 000 groupes de journaux, que vous choisissez en spécifiant jusqu'à cinq préfixes de nom de groupe de journaux. S'il s'agit d'un compte de surveillance dans CloudWatch le domaine de l'observabilité entre comptes, vous pouvez choisir tous les comptes sources ou spécifier des comptes sources individuels pour sélectionner les « groupes de journaux ».
Les champs indexés distinguent les majuscules et minuscules. Par exemple, un index de champ de `RequestId` ne correspondra pas à un événement de journal contenant`requestId`.
Les index de champs ne sont pris en charge que pour les formats de journaux structurés JSON et les journaux de service.
CloudWatch Logs fournit des index de champs par défaut pour tous les groupes de journaux de la classe de journaux standard. Les index de champs par défaut sont automatiquement disponibles pour les champs suivants :
+ `@logStream`
+ `@aws.region`
+ `@aws.account`
+ `@source.log`
+ `@data_source_name`
+ `@data_source_type`
+ `@data_format`
+ `traceId`
+ `severityText`
+ `attributes.session.id`
CloudWatch Logs fournit également des index de champs par défaut pour certaines combinaisons de noms et de types de sources de données. Les index de champs par défaut sont automatiquement disponibles pour les combinaisons de nom et de type de source de données suivantes :
| Nom et type de source de données | Index de champs par défaut |
| --- | --- |
| `amazon_vpc.flow` | `action` `logStatus` `region` `flowDirection` `type` |
| `amazon_route53.resolver_query` | `query_type` `transport` `rcode` |
| `aws_waf.access` | `action` `httpRequest.country` |
| `aws_cloudtrail.data` ` aws_cloudtrail.management` | `eventSource` `eventName` `awsRegion` `userAgent` `errorCode` `eventType` `managementEvent` `readOnly` `eventCategory` `requestId` |
Les index de champs par défaut s'ajoutent aux index de champs personnalisés que vous définissez dans votre politique. Les index de champs par défaut ne sont pas pris en compte dans votre [quota d'index de champs](CloudWatchLogs-Field-Indexing-Syntax.md).
CloudWatch Consigne uniquement les événements du journal ingérés après la création d'une politique d'index. Il n'indexe pas les événements du journal ingérés avant la création de la politique. Une fois que vous avez créé un index de champ, chaque événement de journal correspondant reste indexé pendant 30 jours à compter de la date d'ingestion de l'événement de journal.
**Note**
Si vous créez une politique d'index de champs dans un compte de surveillance, cette politique n'est pas utilisée pour les groupes de journaux des comptes source liés. Une politique d'indexation des champs s'applique uniquement au compte sur lequel elle a été créée.
Les autres rubriques de cette section expliquent comment créer des index de champs. Pour plus d'informations sur la référence aux index de champs dans vos requêtes, reportez-vous aux sections [Index des filtres](CWL_QuerySyntax-FilterIndex.md) et[filtre](CWL_QuerySyntax-Filter.md).
**Topics**
+ [Syntaxe et quotas d'index de champs](CloudWatchLogs-Field-Indexing-Syntax.md)
+ [Création d'une politique d'indexation des champs au niveau du compte](CloudWatchLogs-Field-Indexing-CreateAccountLevel.md)
+ [Création d'une politique d'index de champs au niveau du groupe de journaux](CloudWatchLogs-Field-Indexing-CreateLogGroupLevel.md)
+ [Options de sélection de groupes de journaux lors de la création d'une requête](Field-Indexing-Selection.md)
+ [Effets de la suppression d'une politique d'index de champs](CloudWatchLogs-Field-Indexing-Deletion.md)
# Syntaxe et quotas d'index de champs
Vous créez des index de champs en créant des *politiques d'index de champs*. Vous pouvez créer des politiques d'index au niveau du compte qui s'appliquent à l'ensemble de votre compte, et vous pouvez également créer des politiques qui ne s'appliquent qu'à un seul groupe de journaux. Pour les politiques d'indexation applicables à l'ensemble du compte, vous pouvez en définir une qui s'applique à tous les groupes de journaux du compte. Vous pouvez également créer des politiques d'index au niveau du compte qui s'appliquent à un sous-ensemble de groupes de journaux du compte, sélectionnés par les préfixes de leurs noms de groupes de journaux. Si vous avez plusieurs politiques au niveau du compte dans le même compte, les préfixes des noms de groupes de journaux associés à ces politiques ne peuvent pas se chevaucher. De même, vous pouvez créer des politiques d'index au niveau du compte qui s'appliquent à une combinaison de nom et de type de source de données spécifique. Une seule politique de compte peut être créée par combinaison de nom et de type de source de données.
Les politiques d'index de champs au niveau du groupe de journaux remplacent les politiques d'index de champs au niveau du compte : elles s'appliquent au groupe de journaux dans son ensemble (par exemple, les politiques au niveau du compte sans critères de sélection ou avec des critères de sélection basés sur le préfixe du nom du groupe de journaux). Les politiques au niveau du compte qui correspondent au niveau des événements du journal (par exemple, pour une combinaison de nom et de type de source de données donnée) s'appliqueront en plus des politiques correspondant au groupe de journaux dans son ensemble. Si vous créez une politique d'index au niveau du groupe de journaux, ce groupe de journaux n'utilise pas de politiques au niveau du compte qui correspondent au niveau du groupe de journaux.
Les correspondances entre les événements du journal et les noms des index de champs distinguent les majuscules et minuscules. Par exemple, un index de champ de `RequestId` ne correspondra pas à un événement de journal contenant`requestId`.
Vous pouvez avoir jusqu'à 40 politiques d'index au niveau du compte, dont 20 peuvent utiliser des critères de sélection du préfixe du nom du groupe de journaux et 20 peuvent utiliser des critères de sélection basés sur les sources de données. Si plusieurs politiques d'index au niveau du compte sont filtrées en fonction des préfixes de nom de groupe de journaux, aucune d'entre elles ne peut utiliser des préfixes de nom de groupe de journaux identiques ou des préfixes de nom de groupe de journaux qui se chevauchent. Par exemple, si vous avez une politique filtrée pour enregistrer les groupes commençant par`my-log`, vous ne pouvez pas filtrer une autre politique d'index de champs sur `my-logpprod` ou`my-logging`. De même, si plusieurs politiques d'index au niveau du compte sont filtrées en fonction des combinaisons de nom et de type de source de données, aucune d'entre elles ne peut utiliser le même nom et le même type de source de données. Par exemple, si vous avez une politique filtrée selon le nom `amazon_vpc` et le type de source de données de la source de données, `flow` vous ne pouvez pas créer une autre politique avec cette combinaison.
Si votre politique d'index au niveau du compte ne comporte aucun préfixe de nom et s'applique à tous les groupes de journaux, aucune autre politique d'index au niveau du compte avec des filtres de préfixes de nom de groupe de journaux ne peut être créée ; vous pouvez créer des politiques d'index au niveau du compte qui utilisent des filtres de nom et de type de source de données.
Chaque politique d'indice comporte les quotas et restrictions suivants :
+ Jusqu'à 20 champs peuvent être inclus dans la politique.
+ Chaque nom de champ peut comporter jusqu'à 100 caractères.
+ Pour créer un index d'un champ personnalisé dans vos groupes de journaux commençant par`@`, vous devez spécifier le champ avec un extra `@` au début du nom du champ. Par exemple, si les événements de votre journal incluent un champ nommé`@userId`, vous `@@userId` devez spécifier de créer un index pour ce champ.
Pour les politiques d'indexation au niveau du compte avec le nom de la source de données et les critères de sélection basés sur le type, une restriction supplémentaire s'applique : tous les champs doivent être des types de données primitifs, les primitives imbriquées ne sont prises en charge que pour les structures.
**Champs générés et champs réservés**
CloudWatch Logs Insights génère automatiquement des champs système pour chaque événement du journal. Ces champs générés sont préfixés par. `@` Pour plus d'informations sur les champs générés, consultez[Journaux pris en charge et champs découverts](CWL_AnalyzeLogData-discoverable-fields.md).
Parmi ces champs générés, les suivants sont pris en charge pour être utilisés comme index de champs :
+ `@logStream`
+ `@ingestionTime`
+ `@requestId`
+ `@type`
+ `@initDuration`
+ `@duration`
+ `@billedDuration`
+ `@memorySize`
+ `@maxMemoryUsed`
+ `@xrayTraceId`
+ `@xraySegmentId`
Pour indexer ces champs générés, il n'est pas nécessaire d'en ajouter un `@` autre lorsque vous les spécifiez, comme vous devez le faire pour les champs personnalisés commençant par`@`. Par exemple, pour créer un index de champ pour`@logStream`, il suffit de le spécifier `@logStream` comme index de champ.
CloudWatch Logs fournit des index de champs par défaut pour tous les groupes de journaux de la classe de journaux standard. Les index de champs par défaut sont automatiquement disponibles pour les champs suivants :
+ `@logStream`
+ `@aws.region`
+ `@aws.account`
+ `@source.log`
+ `@data_source_name`
+ `@data_source_type`
+ `@data_format`
+ `traceId`
+ `severityText`
+ `attributes.session.id`
CloudWatch Logs fournit également des index de champs par défaut pour certaines combinaisons de noms et de types de sources de données. Les index de champs par défaut sont automatiquement disponibles pour les combinaisons de nom et de type de source de données suivantes :
| Nom et type de source de données | Index de champs par défaut |
| --- | --- |
| `amazon_vpc.flow` | `action` `logStatus` `region` `flowDirection` `type` |
| `amazon_route53.resolver_query` | `query_type` `transport` `rcode` |
| `aws_waf.access` | `action` `httpRequest.country` |
| `aws_cloudtrail.data` ` aws_cloudtrail.management` | `eventSource` `eventName` `awsRegion` `userAgent` `errorCode` `eventType` `managementEvent` `readOnly` `eventCategory` `requestId` |
Les index de champs par défaut s'ajoutent aux index de champs personnalisés que vous définissez dans votre politique. Les index de champs par défaut ne sont pas pris en compte dans votre [quota d'index de champs](#CloudWatchLogs-Field-Indexing-Syntax).
**Champs enfants et champs de tableau dans les journaux JSON**
Vous pouvez indexer des champs qui sont des champs enfants ou des champs matriciels imbriqués dans les journaux JSON.
Par exemple, vous pouvez créer un index du champ `accessKeyId` enfant dans le `userIdentity` champ de ce journal :
```
{
"eventVersion": "1.0",
"userIdentity": {
"type": "IAMUser",
"principalId": "EXAMPLE_PRINCIPAL_ID",
"arn": "arn: aws: iam: : 123456789012: user/Alice",
"accessKeyId": "11112222",
"accountId": "123456789012",
"userName": "Alice"
},
"eventTime": "2014-03-06T21: 22: 54Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "StartInstances",
"awsRegion": "us-east-2",
"sourceIPAddress": "192.0.2.255",
"userAgent": "ec2-api-tools1.6.12.2",
"requestParameters": {
"instancesSet": {
"items": [{
"instanceId": "i-abcde123",
"currentState": {
"code": 0,
"name": "pending"
},
"previousState": {
"code": 80,
"name": "stopped"
}
}]
}
}
}
```
Pour créer ce champ, vous devez y faire référence à l'aide de la notation par points (`userIdentity.accessKeyId`) à la fois lors de la création de l'index du champ et lors de sa spécification dans une requête. La requête pourrait ressembler à ceci :
```
fields @timestamp, @message
| filterIndex userIdentity.accessKeyId = "11112222"
```
Dans l'exemple précédent, le `instanceId` champ se trouve dans un tableau dans `requestParameters.instancesSet.items` Pour représenter ce champ à la fois lors de la création de l'index du champ et lors de l'interrogation, appelez-le car `requestParameters.instancesSet.items.0.instanceId` le 0 fait référence à la place de ce champ dans le tableau.
Une requête pour ce champ peut alors être la suivante :
```
fields @timestamp, @message
| filterIndex requestParameters.instancesSet.items.0.instanceId="i-abcde123"
```
# Création d'une politique d'indexation des champs au niveau du compte
Suivez les étapes décrites dans cette section pour créer une politique d'index de champs qui s'applique à tous les groupes de journaux du compte ou à plusieurs groupes de journaux dont les noms de groupes de journaux commencent par la même chaîne.
**Pour créer une politique d'indexation des champs au niveau du compte**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation de gauche, choisissez **Paramètres**, puis l'onglet **Journaux**.
1. Dans la section **Politiques d'indexation au niveau du compte**, choisissez **Gérer**.
1. Choisissez **Créer une politique d'index**.
1. Dans **Nom de la politique**, entrez le nom de votre nouvelle politique.
1. Pour **Sélectionner le champ d'application de la politique**, effectuez l'une des opérations suivantes :
+ Choisissez **Tous les groupes de journaux standard** pour que la politique d'indexation s'applique à tous les groupes de journaux de classe standard du compte.
+ Choisissez **Groupes de journaux par correspondance de préfixes** pour appliquer la politique à un sous-ensemble de groupes de journaux dont les noms commencent tous par la même chaîne. Entrez ensuite le préfixe de ces groupes de journaux dans **Entrez un nom de préfixe**.
Après avoir saisi votre préfixe, vous pouvez choisir **Prévisualiser les groupes de journaux correspondant au préfixe** pour confirmer que votre préfixe correspond aux groupes de journaux que vous attendiez.
Choisissez **Enregistrer les données par source de données** pour appliquer la politique à une combinaison de nom et de type de source de données spécifique. Vous pouvez ensuite sélectionner la **source de données** et le **type de données** dans le menu déroulant.
Après avoir sélectionné le nom et le type de la source de données, vous pouvez sélectionner **Obtenir des champs** pour renseigner la section **Configurer les index de champs et les facettes** avec des informations pertinentes telles que les champs disponibles, les groupes de journaux inclus, ainsi que les index de champs par défaut et personnalisés.
1. Pour la **configuration d'un champ d'index personnalisé**, choisissez **Ajouter un chemin de champ** pour saisir le premier champ à indexer.
Entrez ensuite la chaîne à utiliser comme valeur du nom du champ ou sélectionnez un champ dans le menu déroulant. Cela doit correspondre exactement à ce qui apparaît dans le journal des événements. Par exemple, si les événements de votre journal incluent`requestId`, vous devez entrer `requestId` ici. `RequestId``requestID`, et `request Id` ne correspondrait pas.
Si vous souhaitez indexer un champ de journal personnalisé qui commence par le `@` caractère, vous devez inclure un `@` caractère supplémentaire lorsque vous entrez la chaîne d'index. Par exemple, si vous avez un champ de journal personnalisé`@emailname`, saisissez-le `@@emailname` dans la zone **Ajouter un chemin de champ**.
Vous pouvez également créer des index pour les `@logStream` champs `@ingestionTime` et générés automatiquement par CloudWatch Logs. Si c'est le cas, il n'est pas nécessaire d'en ajouter un supplémentaire `@` lorsque vous les spécifiez.
1. (Facultatif) En plus de spécifier le chemin du champ, vous pouvez sélectionner **Définir en tant que facette** pour créer le champ en tant que facette.
1. Répétez l'étape précédente pour ajouter jusqu'à 20 index de champs.
1. Lorsque vous avez terminé, choisissez **Créer**.
# Création d'une politique d'index de champs au niveau du groupe de journaux
Suivez les étapes décrites dans cette section pour créer une politique d'index de champs qui s'applique à un seul groupe de journaux.
**Pour créer une politique d'indexation des champs au niveau du groupe de journaux**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation de gauche, choisissez **Logs** (Journaux), **Log groups** (Groupes de journaux).
1. Choisissez le nom du groupe de journaux.
1. Choisissez l'onglet **Index des champs**.
1. Choisissez **Gérer les index de champs pour ce groupe de journaux**
1. Pour **Gérer les index de champs au niveau des groupes de journaux**, choisissez **Ajouter un chemin de champ** pour saisir le premier champ à indexer.
Entrez ensuite la chaîne à utiliser comme valeur du nom du champ. Cela doit correspondre exactement à ce qui apparaît dans le journal des événements. Par exemple, si les événements de votre journal incluent`requestId`, vous devez entrer `requestId` ici. `RequestId``requestID`, et ne `request Id` correspondrait pas.
Si vous souhaitez indexer un champ de journal personnalisé qui commence par le `@` caractère, vous devez inclure un `@` caractère supplémentaire lorsque vous entrez la chaîne d'index. Par exemple, si vous avez un champ de journal personnalisé`@emailname`, saisissez-le `@@emailname` dans la zone **Ajouter un chemin de champ**.
Vous pouvez également créer des index pour les `@logStream` champs `@ingestionTime` et générés automatiquement par CloudWatch Logs. Si c'est le cas, il n'est pas nécessaire d'en ajouter un supplémentaire `@` lorsque vous les spécifiez.
1. (Facultatif) En plus de spécifier le chemin du champ, vous pouvez sélectionner **Définir en tant que facette** pour créer le champ en tant que facette.
1. Répétez l'étape précédente pour ajouter jusqu'à 20 index de champs.
1. Lorsque vous avez terminé, choisissez **Save**.
# Options de sélection de groupes de journaux lors de la création d'une requête
Cette section explique les différentes manières de sélectionner les groupes de journaux à inclure dans une requête.
**Pour sélectionner des groupes de journaux pour une requête dans la console**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, choisissez **Journaux**, **Informations sur les journaux**.
1. Sélectionnez la langue de requête que vous souhaitez utiliser pour cette requête. Vous pouvez choisir entre **Logs Insights QL**, **OpenSearchPPL** ou **OpenSearch SQL**.
1. Il existe trois méthodes pour sélectionner des groupes de journaux pour la requête :
+ Utilisez le champ **Nom du groupe de journaux**. Il s'agit de la méthode de sélection par défaut. Vous pouvez saisir jusqu'à 50 noms de groupes de journaux avec cette méthode. S'il s'agit d'un compte de surveillance dans le CloudWatch domaine de l'observabilité entre comptes, vous pouvez sélectionner des groupes de journaux dans les comptes sources ainsi que dans le compte de surveillance. Une seule requête peut interroger les journaux de différents comptes à la fois.
+ Utilisez la section **Critères du groupe de journaux**. Dans cette section, vous pouvez choisir des groupes de journaux en fonction du préfixe des noms de groupes de journaux. Vous pouvez inclure jusqu'à cinq préfixes dans une requête. Les groupes de journaux dont le nom contient ces préfixes seront sélectionnés. Sinon, l'option **Tous les groupes de journaux** sélectionne tous les groupes de journaux du compte.
+ S'il s'agit d'un compte de surveillance dans CloudWatch le cadre de l'observabilité entre comptes, vous pouvez sélectionner **Tous les comptes** dans le menu déroulant des comptes pour sélectionner les groupes de journaux parmi tous les comptes associés. Vous pouvez également sélectionner individuellement les comptes à inclure pour cette requête.
Si vos choix correspondent à plus de 10 000 groupes de journaux, un message d'erreur vous invitant à affiner votre sélection s'affichera.
1. La classe de journal par défaut pour une requête est **Standard**. Vous pouvez utiliser la **classe Log** pour la remplacer **par Accès peu fréquent.**
**En utilisant le AWS CLI**
Pour effectuer ces types de sélections lorsque vous lancez une requête depuis la ligne de commande, vous pouvez utiliser la `source` commande dans votre requête. Pour plus d’informations et d’exemples, consultez [SOURCE](CWL_QuerySyntax-Source.md).
# Effets de la suppression d'une politique d'index de champs
Si vous supprimez une politique d'index de champs en vigueur depuis un certain temps, les événements suivants se produisent :
+ Jusqu'à 30 jours après la suppression de la politique, les requêtes peuvent toujours bénéficier des événements du journal indexé.
+ Si vous supprimez une politique d'index au niveau du groupe de journaux et qu'une politique au niveau du compte est déjà en place qui s'appliquerait à ce groupe de journaux, la politique au niveau du compte finira par s'appliquer à ce groupe de journaux.
# Utilisez des facettes pour regrouper et explorer les journaux
Les facettes sont utiles pour analyser les journaux car elles vous permettent de filtrer et de regrouper vos données de manière interactive sans exécuter de requêtes. Une facette est un champ de vos journaux (tel que `ServiceName` ou`StatusCode`) qui permet le filtrage, l'agrégation et l'analyse entre les groupes de journaux. Vous pouvez consulter la liste des champs à facettes dans la console CloudWatch Logs Insights, ainsi que le nombre d'événements de journal pour chaque valeur de facette en fonction de la plage de temps que vous avez sélectionnée. Lorsque vous sélectionnez différentes facettes et valeurs, les valeurs et les nombres de facettes sont mis à jour en temps réel, ce qui vous permet d'explorer vos journaux de manière interactive.
Chaque facette affiche les valeurs disponibles et les nombres automatiquement extraits des champs de vos journaux en fonction de la plage de temps et de l'étendue de la requête sélectionnés, et conservés pendant 30 jours. Le nombre de facettes indiqué est approximatif. Vous pouvez utiliser les facettes par défaut telles que le nom ou le type de source de données pour explorer vos journaux, ou créer des facettes personnalisées dans n'importe quel champ de vos journaux. Le nom de la source de données est un service ou une application AWS qui génère les journaux (par exemple, Route 53, Amazon VPC ou CloudTrail) et le type de source de données est le type spécifique de journal généré par ce service. Les facettes par défaut sont créées par CloudWatch et incluent `@aws.region``@data_source_name`,`@data_source_type`, et`@data_format`. Pour de plus amples informations, veuillez consulter [Gestion des journaux](LogManagement.md). Les facettes ne sont disponibles que pour les journaux ingérés dans le compte. Si vous avez configuré l'observabilité entre comptes, le compte de surveillance ne peut pas afficher les facettes sur la base des journaux des comptes sources.
Pour créer des facettes supplémentaires, sélectionnez les champs de vos journaux qui sont pertinents pour votre résolution des problèmes et configurez-les à l'aide des politiques d'index. Pour les facettes personnalisées, nous vous recommandons de les créer sur des champs à faible cardinalité (champs contenant moins de 100 valeurs uniques par jour, tels que Status et ApplicationName). Les facettes contenant plus de 100 valeurs uniques par jour sont considérées comme présentant une cardinalité élevée et les valeurs de ces facettes ne sont pas affichées. Sélectionnez une ou plusieurs facettes et cliquez pour exécuter des requêtes dans vos journaux.
Pour commencer à utiliser les facettes dans CloudWatch Logs Insights :
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, choisissez **Journaux**, **Informations sur les journaux**.
1. (Facultatif) Utilisez le sélecteur de plage de temps pour sélectionner la période que vous souhaitez analyser. Pour la plage de temps sélectionnée, les facettes et valeurs disponibles sont affichées dans le panneau.
1. Sélectionnez des facettes pour explorer vos données et consulter les mises à jour en temps réel des distributions de valeur entre les facettes.
Les facettes comportant plus de 100 valeurs uniques ne sont pas affichées. Pour rechercher des valeurs spécifiques, utilisez plutôt des filtres dans votre requête.
## Pour exécuter une requête basée sur les facettes
1. Sélectionnez une ou plusieurs valeurs sur les facettes.
1. Le nombre d'événements sera mis à jour en fonction des facettes et des valeurs sélectionnées.
1. Au fur et à mesure que les valeurs des facettes sont sélectionnées, l'étendue de la requête est mise à jour pour refléter la sélection.
1. Après avoir sélectionné les valeurs des facettes, cliquez sur Exécuter pour exécuter votre requête.
1. Le nombre maximum de valeurs uniques prises en charge par facette est de 100. Par exemple, s'il existe plus de 100 valeurs pour une facette, tous les nombres sont affichés sous la forme « - », ce qui indique que les valeurs sont inconnues.
## Pour enregistrer une requête basée sur des facettes
1. Créez votre requête à l'aide d'une ou de plusieurs valeurs de facette.
1. Les autres étapes sont identiques à celles de l'enregistrement d'une requête Logs Insights. Voir les [requêtes Saving CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Saving-Queries.html).
1. Vos requêtes enregistrées sont disponibles dans la section Requêtes enregistrées. Lorsque vous récupérez une requête enregistrée, elle inclut automatiquement les facettes et les valeurs utilisées pour la requête, ce qui facilite l'analyse de vos journaux.
## Pour créer une facette au niveau du compte
1. Pour créer des facettes, vous devez d'abord créer le champ sous forme d'index et le configurer en tant que facette. Dans le volet de navigation, sélectionnez **Paramètres**, **Journaux**, **Politiques d'index au niveau du compte**. Vous pouvez également sélectionner **Gérer les facettes** dans le panneau des facettes.
1. Choisissez **Créer une nouvelle politique d'index**. Pour plus de détails sur la création de politiques d'index, consultez[Création d'une politique d'indexation des champs au niveau du compte](CloudWatchLogs-Field-Indexing-CreateAccountLevel.md).
1. Pour créer une facette, cochez la case **Définir comme facette** pour le champ sélectionné sur la page de création de la politique d'index.
## Gestion des facettes à l'aide de APIs
La gestion des facettes peut être effectuée à l'aide de la politique d'index des champs. Consultez [https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FieldIndex.html](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FieldIndex.html) APIs pour plus de détails.
**Index des champs APIs**
| Non. | Nom | Description |
| --- | --- | --- |
| 1 | PutIndexPolicy | Crée ou met à jour une politique d'index de champs pour le groupe de journaux spécifique |
| 2 | PutAccountPolicy | Crée une politique de protection des données au niveau du compte, une politique de filtrage des abonnements, une politique d'index de champs, une politique de transformation ou une politique d'extraction métrique qui s'applique à tous les groupes de journaux ou à un sous-ensemble de groupes de journaux du compte |
| 3 | DeleteIndexPolicy | Supprime une politique d'index de champs au niveau du groupe de journaux qui a été appliquée à un seul groupe de journaux |
| 4 | DeleteAccountPolicy | Supprime une politique de compte CloudWatch Logs |
# Analyse de modèles
CloudWatch Logs Insights utilise des algorithmes d'apprentissage automatique pour identifier *des modèles* lorsque vous interrogez vos journaux. Un modèle est une structure de texte partagée récurrente dans vos champs de journal. Lorsque vous consultez les résultats d'une requête, vous pouvez choisir l'onglet **Modèles** pour voir les modèles trouvés par CloudWatch Logs sur la base d'un échantillon de vos résultats. Vous pouvez également ajouter la `pattern` commande à votre requête pour analyser les modèles de l'ensemble des événements du journal correspondants.
Les modèles sont utiles pour analyser de grands ensembles de journaux, car un grand nombre d'événements de journal peuvent souvent être compressés en plusieurs modèles.
Examinez l'exemple suivant de trois événements de journal.
```
2023-01-01 19:00:01 [INFO] Calling DynamoDB to store for resource id 12342342k124-12345
2023-01-01 19:00:02 [INFO] Calling DynamoDB to store for resource id 324892398123-12345
2023-01-01 19:00:03 [INFO] Calling DynamoDB to store for resource id 3ff231242342-12345
```
Dans l'exemple précédent, les trois événements du journal suivent le même schéma :
```
[INFO] Calling DynamoDB to store for resource id
```
Les champs d'un modèle sont appelés *jetons*. Les champs qui varient au sein d'un modèle, tels qu'un ID de demande ou un horodatage, sont des jetons *dynamiques*. Chaque jeton dynamique est représenté par``. *string*Il s'agit d'une description du type de données que le jeton représente. *number*Indique où ce jeton apparaît dans le modèle, par rapport aux autres jetons dynamiques.
Les exemples courants de jetons dynamiques incluent les codes d'erreur, les horodatages et les demandes. IDs Une *valeur de jeton* représente une valeur particulière d'un jeton dynamique. Par exemple, si un jeton dynamique représente un code d'erreur HTTP, une valeur de jeton peut l'être`501`.
La détection de modèles est également utilisée dans le détecteur d'anomalies CloudWatch Logs et les fonctionnalités de comparaison. Pour plus d’informations, consultez [Détection des anomalies du journal](LogsAnomalyDetection.md) et [Comparer (diff) avec les plages temporelles précédentes](CWL_AnalyzeLogData_Compare.md).
## Commencer à utiliser l'analyse de modèles
La détection des modèles est automatiquement effectuée dans toutes CloudWatch les requêtes Logs Insights. Les requêtes qui n'incluent pas la `pattern` commande enregistrent à la fois les événements et les modèles dans les résultats.
Si vous incluez la `pattern` commande dans votre requête, l'analyse des modèles est effectuée sur l'ensemble des événements du journal correspondants. Cela permet d'obtenir des résultats de modèle plus précis, mais les événements du journal bruts ne sont pas renvoyés lorsque vous utilisez la `pattern` commande. Lorsqu'une requête n'inclut pas`pattern`, les résultats du modèle sont basés soit sur les 1 000 premiers événements de journal renvoyés, soit sur la valeur limite que vous avez utilisée dans votre requête. Si vous l'incluez `pattern` dans la requête, les résultats affichés dans l'onglet **Modèles** sont dérivés de tous les événements du journal correspondant à la requête.
**Pour commencer à utiliser l'analyse de modèles dans CloudWatch Logs Insights**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le volet de navigation, choisissez **Journaux**, **Informations sur les journaux**.
Sur la page **Logs Insights**, l'éditeur de requête contient une requête par défaut qui renvoie les 20 événements du journal les plus récents.
1. Supprimez la `| limit 20` ligne dans la zone de requête afin que la requête ressemble à ce qui suit :
```
fields @timestamp, @message, @logStream, @log
| sort @timestamp desc
```
1. Dans le menu déroulant **Sélectionner un ou plusieurs groupes de journaux**, choisissez un ou plusieurs groupes de journaux à interroger.
1. (Facultatif) Utilisez le sélecteur d'intervalle de temps pour sélectionner une période à interroger.
Vous pouvez choisir entre des intervalles de 5 minutes et 30 minutes, des intervalles de 1 heure, 3 heures et 12 heures, ou un intervalle de temps personnalisé.
1. Choisissez **Exécuter la requête** pour démarrer la requête.
Lorsque l'exécution de la requête est terminée, l'onglet **Journaux** affiche un tableau des événements du journal renvoyés par la requête. Au-dessus du tableau se trouve un message indiquant le nombre d'enregistrements correspondant à la requête, similaire à l'**affichage de 10 000 enregistrements sur 71 101** correspondants.
1. Choisissez l'onglet **Motifs**.
1. Le tableau affiche désormais les modèles trouvés dans la requête. Comme la requête n'incluait pas la `pattern` commande, cet onglet affiche uniquement les modèles découverts parmi les 10 000 événements de journal indiqués dans le tableau de l'onglet **Journaux**.
Pour chaque modèle, les informations suivantes sont affichées :
+ Le **modèle**, avec chaque jeton dynamique affiché sous la forme``. *string*Il s'agit d'une description du type de données que le jeton représente. *number*Indique où ce jeton apparaît dans le modèle, par rapport aux autres jetons dynamiques.
+ Le **nombre d'événements**, qui est le nombre de fois que le modèle est apparu dans le journal des événements demandé. Choisissez l'en-tête de la colonne **Nombre d'événements** pour trier les modèles par fréquence.
+ Le **ratio d'événements**, qui est le pourcentage des événements du journal interrogés qui contiennent ce modèle.
+ Le **type de gravité**, qui sera l'un des suivants :
+ **ERREUR** si le modèle contient le mot **Error**.
+ **AVERTIR** si le modèle contient le mot **Warn** mais ne contient pas **Error**.
+ **INFO** si le modèle ne contient ni **avertissement** ni **erreur**.
Choisissez l'en-tête de **la colonne Informations sur** la gravité pour trier les modèles par gravité.
1. Modifiez maintenant la requête. Remplacez la `| sort @timestamp desc` ligne de la requête par`| pattern @message`, de sorte que la requête complète soit la suivante :
```
fields @timestamp, @message, @logStream, @log
| pattern @message
```
1. Choisissez **Exécuter la requête**.
Lorsque la requête est terminée, aucun résultat ne s'affiche dans l'onglet **Logs**. Cependant, l'onglet **Modèles** contient probablement un plus grand nombre de modèles répertoriés, en fonction du nombre total d'événements de journal interrogés.
1. Que vous l'ayez inclus ou non `pattern` dans votre requête, vous pouvez examiner plus en détail les modèles renvoyés par la requête. Pour ce faire, choisissez l'icône de l'un des modèles dans la colonne **Inspecter**.
Le volet **Pattern inspect** apparaît et affiche les informations suivantes :
+ Le **motif**. Sélectionnez un jeton dans le modèle pour analyser les valeurs de ce jeton.
+ Un histogramme indiquant le nombre d'occurrences du modèle sur la plage de temps demandée. Cela peut vous aider à identifier des tendances intéressantes, telles qu'une augmentation soudaine de l'occurrence d'un modèle.
+ L'onglet **Échantillons de journal** affiche quelques-uns des événements du journal correspondant au modèle sélectionné.
+ L'onglet **Valeurs du jeton** affiche les valeurs du jeton dynamique sélectionné, si vous en avez sélectionné un.
**Note**
Un maximum de 10 valeurs de jeton est capturée pour chaque jeton. Le nombre de jetons peut ne pas être précis. CloudWatch Logs utilise un compteur probabiliste pour générer le nombre de jetons, et non la valeur absolue.
+ L'onglet **Modèles associés** affiche d'autres modèles qui se sont produits fréquemment à peu près au même moment que le modèle que vous inspectez. Par exemple, si le modèle d'un `ERROR` message était généralement accompagné d'un autre événement de journal marqué comme `INFO` contenant des détails supplémentaires, ce modèle est affiché ici.
## Détails sur la commande pattern
Cette section contient plus de détails sur la `pattern` commande et ses utilisations.
+ Dans le didacticiel précédent, nous avons supprimé la `sort` commande lors de son ajout `pattern` car une requête n'est pas valide si elle inclut une `pattern` commande après une `sort` commande. Il est valide d'avoir un `pattern` avant un`sort`.
Pour plus de détails sur `pattern` la syntaxe, consultez[pattern](CWL_QuerySyntax-Pattern.md).
+ Lorsque vous l'utilisez `pattern` dans une requête, ce `@message` doit être l'un des champs sélectionnés dans la `pattern` commande.
+ Vous pouvez inclure la `filter` commande avant une `pattern` commande pour que seul l'ensemble filtré d'événements du journal soit utilisé comme entrée pour l'analyse des modèles.
+ Pour voir les résultats de modèles pour un champ particulier, tel qu'un champ dérivé de la `parse` commande, utilisez`pattern @fieldname`.
+ Les requêtes dont la sortie n'est pas un journal, telles que les requêtes avec la `stats` commande, ne renvoient pas de résultats de modèle.
# Enregistrez et réexécutez les requêtes CloudWatch Logs Insights
Après avoir créé une requête, vous pouvez l'enregistrer et la réexécuter ultérieurement. Les requêtes sont enregistrées dans une structure de dossiers afin que vous puissiez les organiser. Vous pouvez enregistrer jusqu'à 1 000 requêtes par région et par compte.
Les requêtes sont enregistrées à un niveau spécifique à la région, et non à un niveau spécifique à l'utilisateur. Si vous créez et enregistrez une requête, les autres utilisateurs ayant accès aux CloudWatch journaux de la même région peuvent voir toutes les requêtes enregistrées et leurs structures de dossiers dans la région.
Pour enregistrer une requête, vous devez être connecté à un rôle disposant de l'autorisation `logs:PutQueryDefinition`. Pour afficher une liste des requêtes enregistrées, vous devez être connecté à un rôle disposant de l'autorisation `logs:DescribeQueryDefinitions`.
**Note**
Vous pouvez créer et enregistrer des requêtes avec des paramètres, c'est-à-dire des modèles réutilisables avec des espaces réservés nommés. Au lieu d'enregistrer plusieurs variantes de la même requête avec des valeurs différentes, créez un modèle et fournissez différentes valeurs de paramètres lorsque vous l'exécutez. Cette fonctionnalité est actuellement prise en charge uniquement pour les requêtes utilisant le langage de requête Logs Insights. Pour plus d'informations, consultez la section [Utilisation de requêtes enregistrées avec des paramètres](#CWL_Insights-Parameterized-Queries).
------
#### [ Console ]
**Pour enregistrer une requête**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Dans l'éditeur de requête, créez une requête.
1. Choisissez **Enregistrer**.
1. Entrez un nom pour la requête.
1. (Facultatif) Choisissez un dossier dans lequel vous souhaitez enregistrer cette requête. Sélectionnez ** (Nouveau)** pour créer un dossier. Si vous créez un dossier, vous pouvez utiliser des barres obliques (/) dans son nom pour définir une structure de dossier. Par exemple, le nom d'un nouveau dossier **folder-level-1/folder-level-2** crée un dossier de niveau supérieur appelé **folder-level-1**, avec un autre dossier appelé **folder-level-2** au sein de ce dossier. La requête est enregistrée dans **folder-level-2**.
1. (Facultatif) Modifiez les groupes de journaux ou le texte de la requête.
1. (Facultatif) Pour utiliser des paramètres dans votre requête, procédez comme suit :
1. **Ajoutez des paramètres à votre requête.** Remplacez les valeurs statiques par des espaces réservés en utilisant la `{{parameter}}` syntaxe (doubles accolades avant et après le nom du paramètre).
Exemple : requête originale avec des valeurs statiques :
```
fields @timestamp, @message
| filter level = "Error"
| filter applicationName = "OrderService"
```
Requête mise à jour avec paramètres :
```
fields @timestamp, @message
| filter level = {{logLevel}}
| filter applicationName = {{applicationName}}
```
1. **Définissez les paramètres utilisés dans votre requête.** Pour chaque paramètre d'espace réservé, spécifiez :
+ **Nom** : doit correspondre exactement au nom de l'espace réservé (par exemple,`logLevel`,`applicationName`).
+ **Valeur par défaut** (facultatif) : valeur à utiliser si aucune valeur de paramètre n'est fournie.
+ **Description** (facultatif) : explique l'objectif du paramètre.
1. Les requêtes avec paramètres peuvent être exécutées en utilisant le nom de la requête avec un `$` préfixe et en transmettant les noms des paramètres sous forme de paires clé-valeur. **Pour plus de détails, reportez-vous à la section Pour exécuter une requête enregistrée**.
1. Choisissez **Enregistrer**.
------
#### [ AWS CLI ]
**Pour enregistrer une requête**, utilisez `put-query-definition` :
```
aws logs put-query-definition \
--name "ErrorsByLevel" \
--query-string "fields @timestamp, @message | filter level = \"ERROR\"" \
--log-group-names "/aws/lambda/my-function" \
--region us-east-1
```
(Facultatif) Pour enregistrer une requête avec des paramètres, ajoutez l'`--parameters`option et utilisez des `{{parameterName}}` espaces réservés dans la chaîne de requête :
```
aws logs put-query-definition \
--name "ErrorsByLevel" \
--query-string "fields @timestamp, @message | filter level = {{logLevel}} | filter applicationName = {{applicationName}}" \
--parameters '[{"name":"logLevel","defaultValue":"ERROR","description":"Log level to filter"},{"name":"applicationName","defaultValue":"OrderService","description":"Application name to filter"}]' \
--log-group-names "/aws/lambda/my-function" \
--region us-east-1
```
Pour enregistrer une requête dans un dossier, préfixez le nom de la requête par le chemin du dossier :
```
aws logs put-query-definition \
--name "my-folder/ErrorsByLevel" \
--query-string "fields @timestamp, @message | filter level = {{logLevel}}" \
--parameters '[{"name":"logLevel","defaultValue":"ERROR","description":"Log level to filter"}]' \
--log-group-names "/aws/lambda/my-function" \
--region us-east-1
```
------
#### [ API ]
**Pour enregistrer une requête**, appelez [PutQueryDefinition](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutQueryDefinition.html):
```
{
"name": "ErrorsByLevel",
"queryString": "fields @timestamp, @message | filter level = \"ERROR\"",
"logGroupNames": ["/aws/lambda/my-function"]
}
```
(Facultatif) Pour enregistrer une requête avec des paramètres, incluez le `parameters` champ et utilisez des `{{parameterName}}` espaces réservés dans la chaîne de requête :
```
{
"name": "ErrorsByLevel",
"queryString": "fields @timestamp, @message | filter level = {{logLevel}} | filter applicationName = {{applicationName}}",
"logGroupNames": ["/aws/lambda/my-function"],
"parameters": [
{
"name": "logLevel",
"defaultValue": "ERROR",
"description": "Log level to filter"
},
{
"name": "applicationName",
"defaultValue": "OrderService",
"description": "Application name to filter"
}
]
}
```
------
**Astuce**
Vous pouvez créer un dossier pour les requêtes enregistrées avec `PutQueryDefinition`. Pour créer un dossier pour vos requêtes enregistrées, utilisez une barre oblique (/) pour préfixer le nom de requête souhaité par le nom de dossier de votre choix : `/`. Pour plus d'informations sur cette action, consultez [PutQueryDefinition](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutQueryDefinition.html).
------
#### [ Console ]
**Pour exécuter une requête enregistrée**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Sur la droite, choisissez **Queries (Requêtes)**.
1. Sélectionnez votre requête dans la liste des **requêtes enregistrées**. Le texte de la requête apparaît dans l'éditeur de requêtes.
1. (Facultatif) Pour utiliser une requête paramétrée :
1. Cliquez sur l'icône **\$1** à côté du nom de la requête dans le panneau latéral **des requêtes enregistrées**.
1. La requête paramétrée apparaît dans l'éditeur de requêtes. Par exemple, si vous choisissez l'icône **\$1** à côté`ErrorsByLevel`, l'éditeur de requêtes est renseigné avec : `$ErrorsByLevel(level=, applicationName=)`
1. Fournissez les valeurs des paramètres (level, ApplicationName) et exécutez la requête. Par exemple : `$ErrorsByLevel(level= "ERROR", applicationName= "OrderService")`
1. Cliquez sur **Exécuter**.
------
#### [ AWS CLI ]
**Pour exécuter une requête enregistrée avec des paramètres**
À utiliser `start-query` avec la `$QueryName()` syntaxe suivante :
```
aws logs start-query \
--log-group-names "/aws/lambda/my-function" \
--start-time 1707566400 --end-time 1707570000 \
--query-string '$ErrorsByLevel(level= "ERROR", applicationName= "OrderService")' \
--region us-east-1
```
------
#### [ API ]
**Pour exécuter une requête enregistrée avec des paramètres**
Appelez [StartQuery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_StartQuery.html)avec la `$QueryName()` syntaxe dans le `queryString` champ :
```
{
"logGroupNames": ["/aws/lambda/my-function"],
"startTime": 1707566400,
"endTime": 1707570000,
"queryString": "$ErrorsByLevel(level=\"ERROR\", applicationName= \"OrderService\")"
}
```
------
**Pour enregistrer une nouvelle version d'une requête enregistrée**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Sur la droite, choisissez **Queries (Requêtes)**.
1. Sélectionnez votre requête dans la liste **Saved queries (Requêtes enregistrées)**. Celle-ci apparaît dans l'éditeur de requêtes.
1. Modifiez la requête. Si vous devez l'exécuter pour vérifier le résultat de vos efforts, choisissez **Run query (Exécuter la requête)**.
1. Lorsque vous êtes prêt à enregistrer la nouvelle version, choisissez **Actions**, puis **Save as (Enregistrer sous)**.
1. Entrez un nom pour la requête.
1. (Facultatif) Choisissez un dossier dans lequel vous souhaitez enregistrer cette requête. Sélectionnez ** (Nouveau)** pour créer un dossier. Si vous créez un dossier, vous pouvez utiliser des barres obliques (/) dans son nom pour définir une structure de dossier. Par exemple, le nom d'un nouveau dossier **folder-level-1/folder-level-2** crée un dossier de niveau supérieur appelé **folder-level-1**, avec un autre dossier appelé **folder-level-2** au sein de ce dossier. La requête est enregistrée dans **folder-level-2**.
1. (Facultatif) Modifiez les groupes de journaux ou le texte de la requête.
1. Choisissez **Enregistrer**.
Pour supprimer une requête, vous devez être connecté à un rôle disposant de l'autorisation `logs:DeleteQueryDefinition`.
**Pour modifier ou supprimer une requête enregistrée**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Sur la droite, choisissez **Queries (Requêtes)**.
1. Sélectionnez votre requête dans la liste **Saved queries (Requêtes enregistrées)**. Celle-ci apparaît dans l'éditeur de requêtes.
1. Choisissez **Actions** et **Edit (Modifier)** ou **Actions** et **Delete (Supprimer)**.
## Utilisation de requêtes enregistrées avec paramètres
Les requêtes enregistrées avec paramètres sont des modèles de requêtes réutilisables avec des espaces réservés nommés. Au lieu de conserver plusieurs copies de requêtes presque identiques, vous pouvez enregistrer un modèle et fournir différentes valeurs de paramètres lors de l'exécution de la requête. Les paramètres ne sont pris en charge que dans le langage de requête CloudWatch Logs Insights.
**Fonctionnement**
Lorsque vous enregistrez une requête, les espaces réservés identifient les valeurs que vous pouvez fournir au moment de l'exécution de la requête. Les espaces réservés utilisent la `{{parameterName}}` syntaxe. Voici un exemple de requête enregistrée nommée `ErrorsByLevel` avec deux paramètres `logLevel` et`applicationName`.
```
fields @timestamp, @message
| filter level = {{logLevel}}
| filter applicationName = {{applicationName}}
```
Pour exécuter une requête enregistrée, vous pouvez l'invoquer en utilisant le nom de la requête préfixé par `$` et en transmettant les valeurs des paramètres. Le moteur de requête CloudWatch Logs Insights remplace chaque espace réservé. Si un paramètre contient des valeurs par défaut, ces valeurs sont utilisées si aucune autre valeur n'est fournie.
```
# Run query by using query name and passing parameter values explicitly
$ErrorsByLevel(logLevel = "WARN", applicationName = "OrderService")
# Run query without specifying parameter values - default values are used in this case.
$ErrorsByLevel()
```
Les noms de requêtes enregistrés contenant des espaces ou des caractères spéciaux doivent être suivis de backticks :
```
$`Errors By Level`(logLevel = "WARN")
```
### Exemples de requêtes enregistrées avec paramètres
**Ajouter une limite de résultats en tant que paramètre**
Nom de la requête : `ErrorsByLevel` avec paramètres `logLevel` (par défaut :`"ERROR"`), `applicationName` (par défaut :`"OrderService"`) et `maxResults` (par défaut :`50`)
```
fields @timestamp, @message, @logStream
| filter level = {{logLevel}}
| filter applicationName = {{applicationName}}
| sort @timestamp desc
| limit {{maxResults}}
```
```
# Run the query using the query name and passing parameter values
$ErrorsByLevel(logLevel = "WARN", applicationName = "OrderService", maxResults = 100)
```
**Utilisation de plusieurs requêtes enregistrées avec paramètres**
L'exemple ci-dessous utilise `ErrorsByLevel` une seconde requête `RecentN` enregistrée définie comme `sort @timestamp desc | limit {{count}}` (avec paramètre`count`, par défaut`20`). Le moteur de requêtes CloudWatch Logs Insights développe chaque requête avant de l'exécuter.
```
# Using multiple queries with parameters in sequence
$ErrorsByLevel(logLevel = "WARN", applicationName = "OrderService")
| $RecentN(count = 10)
# Each of the queries is expanded, resulting in the following query when it is run.
fields @timestamp, @message
| filter level = "WARN"
| filter applicationName = "OrderService"
| sort @timestamp desc
| limit 10
```
### Quotas et gestion des erreurs
**Note**
Chaque requête enregistrée peut comporter un maximum de 20 paramètres.
La chaîne de requête étendue ne peut pas dépasser 10 000 caractères. Les noms des paramètres doivent commencer par une lettre ou un trait de soulignement. Une requête enregistrée ne peut pas faire référence à une autre requête enregistrée (les invocations imbriquées ne sont pas prises en charge).
**Erreurs courantes**
| Erreur | Cause |
| --- | --- |
| Les paramètres ne sont pris en charge que pour le langage de requête CWLI | Les paramètres ne sont pris en charge que dans le langage de requête CloudWatch Logs Insights. |
| Paramètres obligatoires introuvables dans QueryString | Le nom d'un paramètre dans `--parameters` ne correspond pas `{{placeholder}}` à la chaîne de requête. |
| Le nombre de paramètres dépasse le maximum de 20 | Les requêtes enregistrées ne prennent actuellement en charge que 20 paramètres. |
| Nom du paramètre dupliqué | La définition de requête contient des paramètres dupliqués`parameters`. |
**Note**
Pour créer ou mettre à jour une requête enregistrée avec des paramètres, vous devez disposer de cette `logs:PutQueryDefinition` autorisation. Pour en exécuter un, il vous faut `logs:StartQuery` et`logs:DescribeQueryDefinitions`.
# Ajouter une requête au tableau de bord ou exporter les résultats de la requête
Après avoir exécuté une requête, vous pouvez l'ajouter à un CloudWatch tableau de bord ou copier les résultats dans le presse-papiers.
Les requêtes ajoutées aux tableaux de bord s'exécutent automatiquement chaque fois que vous chargez le tableau de bord et chaque fois que le tableau de bord s'actualise. Ces requêtes sont prises en compte dans votre limite de 100 requêtes CloudWatch Logs Insights simultanées.
**Pour ajouter les résultats d'une requête sur un tableau de bord**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Choisissez un ou plusieurs groupes de journaux et exécutez une requête.
1. Choisissez **Add to dashboard (Ajouter au tableau de bord)**.
1. Sélectionnez le tableau de bord, ou choisissez **Create (Nouveau)** pour créer un tableau de bord pour les résultats de la requête.
1. Sélectionnez le type de widget à utiliser pour les résultats de la requête.
1. Entrez un nom pour ce widget.
1. Choisissez **Add to dashboard (Ajouter au tableau de bord)**.
**Pour copier les résultats de la requête dans le Presse-papiers ou les télécharger**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Choisissez un ou plusieurs groupes de journaux et exécutez une requête.
1. Choisissez **Export results (Exporter les résultats)**, puis choisissez l'option souhaitée.
# Afficher les requêtes en cours d'exécution ou l'historique des requêtes
Vous pouvez afficher les requêtes en cours, ainsi que votre historique des requêtes récentes.
Les requêtes en cours d'exécution incluent les requêtes que vous avez ajoutées à un tableau de bord. Vous êtes limité à 100 requêtes CloudWatch Logs Insights simultanées par compte, y compris les requêtes ajoutées aux tableaux de bord. En outre, vous pouvez exécuter 15 requêtes simultanées pour OpenSearch Service PPL ou OpenSearch Service SQL.
**Pour afficher l'historique de vos requêtes récentes**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Logs** (Journaux), puis **Logs Insights**.
1. Choisissez **History**, si vous utilisez le nouveau design de la console CloudWatch Logs. Si vous utilisez l'ancienne interface, choisissez **Actions**, puis **View query history for this account (Afficher l'historique des requêtes pour ce compte)**.
La liste de vos requêtes récentes s'affiche. Pour les exécuter à nouveau, sélectionnez la requête et choisissez **Run (Exécuter)**.
Sous **État**, CloudWatch Logs affiche **En cours** pour toutes les requêtes en cours d'exécution.
# Chiffrez les résultats des requêtes avec AWS Key Management Service
Par défaut, CloudWatch Logs chiffre les résultats enregistrés de vos requêtes CloudWatch Logs Insights en utilisant la méthode de chiffrement côté serveur CloudWatch Logs par défaut. Vous pouvez choisir d'utiliser une AWS KMS clé pour chiffrer ces résultats à la place. Si vous associez une AWS KMS clé à vos résultats de chiffrement, CloudWatch Logs utilise cette clé pour chiffrer les résultats enregistrés de toutes les requêtes du compte.
Si vous dissociez ultérieurement une clé des résultats de votre requête, CloudWatch Logs revient à la méthode de cryptage par défaut pour les requêtes ultérieures. Mais les requêtes exécutées alors que la clé était associée sont toujours chiffrées avec cette clé. CloudWatch Les journaux peuvent toujours renvoyer ces résultats une fois la clé KMS dissociée, car ils CloudWatch peuvent continuer à faire référence à la clé. Toutefois, si la clé est désactivée ultérieurement, CloudWatch Logs ne pourra pas lire les résultats de la requête chiffrés avec cette clé.
**Important**
CloudWatch Logs ne prend en charge que les clés KMS symétriques. N'utilisez pas de clé asymétrique pour chiffrer vos résultats de requête. Pour plus d'informations, consultez [Utilisation des clés symétriques et asymétriques](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html).
## Restrictions
+ Pour effectuer les étapes suivantes, vous devez disposer des autorisations suivantes : `kms:CreateKey`, `kms:GetKeyPolicy` et `kms:PutKeyPolicy`.
+ L'association d'une clé à vos résultats de requête ou sa dissociation peut mettre jusqu'à cinq minutes à prendre effet.
+ Si vous révoquez l'accès de CloudWatch Logs à une clé associée ou si vous supprimez une clé KMS associée, vos données chiffrées dans CloudWatch Logs ne peuvent plus être récupérées.
+ Vous ne pouvez pas utiliser la CloudWatch console pour associer une clé, vous devez utiliser l'API AWS CLI or CloudWatch Logs.
## Étape 1 : Création d'un AWS KMS key
Pour créer une clé KMS, utilisez la commande [create-key](https://docs.aws.amazon.com/cli/latest/reference/kms/create-key.html) suivante :
```
aws kms create-key
```
La sortie contient l'ID de clé et l'Amazon Resource Name (ARN) de la clé. Voici un exemple de sortie :
```
{
"KeyMetadata": {
"Origin": "AWS_KMS",
"KeyId": "1234abcd-12ab-34cd-56ef-1234567890ab",
"Description": "",
"KeyManager": "CUSTOMER",
"Enabled": true,
"CustomerMasterKeySpec": "SYMMETRIC_DEFAULT",
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"CreationDate": 1478910250.94,
"Arn": "arn:aws:kms:us-west-2:123456789012:key/6f815f63-e628-448c-8251-e40cb0d29f59",
"AWSAccountId": "123456789012",
"EncryptionAlgorithms": [
"SYMMETRIC_DEFAULT"
]
}
}
```
## Étape 2 : Définition des autorisations sur la clé KMS
Par défaut, toutes les clés KMS sont privées. Seul le propriétaire de la ressource peut l'utiliser pour chiffrer et déchiffrer des données. Cependant, le propriétaire de la ressource peut accorder à d'autres utilisateurs et ressources des autorisations d'accès à la clé. Avec cette étape, vous autorisez le principal du service CloudWatch Logs à utiliser la clé. Ce principal de service doit se trouver dans la même AWS région que celle où la clé est stockée.
Il est recommandé de limiter l'utilisation de la clé aux seuls AWS comptes que vous spécifiez.
Tout d'abord, enregistrez la politique par défaut pour votre clé KMS à `policy.json` l'aide de la [get-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/get-key-policy.html)commande suivante :
```
aws kms get-key-policy --key-id key-id --policy-name default --output text > ./policy.json
```
Ouvrez le fichier `policy.json` dans un éditeur de texte et ajoutez la section en gras à partir de l'une des instructions suivantes. Séparez l'instruction existante de la nouvelle instruction par une virgule. Ces instructions utilisent `Condition` des sections pour renforcer la sécurité de la AWS KMS clé. Pour de plus amples informations, veuillez consulter [AWS KMS clés et contexte de chiffrement](encrypt-log-data-kms.md#encrypt-log-data-kms-policy).
La `Condition` section de cet exemple limite l'utilisation de la AWS KMS clé pour les résultats de la requête CloudWatch Logs Insights dans le compte spécifié.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "key-default-1",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": [
"kms:Encrypt*",
"kms:Decrypt*",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:Describe*"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:logs:us-east-1:111122223333:query-result:*"
},
"StringEquals": {
"aws:SourceAccount": "111122223333"
}
}
}
]
}
```
------
Enfin, ajoutez la politique mise à jour à l'aide de la [put-key-policy](https://docs.aws.amazon.com/cli/latest/reference/kms/put-key-policy.html)commande suivante :
```
aws kms put-key-policy --key-id key-id --policy-name default --policy file://policy.json
```
## Étape 3 : Associer une clé KMS à vos résultats de requête
**Pour associer la clé KMS aux résultats de la requête dans le compte**
Utilisez la commande [disassociate-kms-key](https://docs.aws.amazon.com/cli/latest/reference/logs/disassociate-kms-key.html) comme suit :
```
aws logs associate-kms-key --resource-identifier "arn:aws:logs:region:account-id:query-result:*" --kms-key-id "key-arn"
```
## Étape 4 : Dissocier une clé des résultats de requête dans le compte
Pour dissocier la clé KMS associée aux résultats de la requête, utilisez la [disassociate-kms-key](https://docs.aws.amazon.com/cli/latest/reference/logs/disassociate-kms-key.html)commande suivante :
```
aws logs disassociate-kms-key --resource-identifier "arn:aws:logs:region:account-id:query-result:*"
```
# Génération d'un résumé en langage naturel à partir des résultats des requêtes de CloudWatch Logs Insights
L'analyse des données des journaux est essentielle pour comprendre le comportement de vos applications, mais l'interprétation de gros volumes d'entrées de journal peut prendre beaucoup de temps. CloudWatch Logs Insights propose désormais une fonctionnalité de synthèse en langage naturel qui transforme les résultats de requêtes complexes en résumés clairs et concis. Cette fonctionnalité vous permet d'identifier rapidement les problèmes et d'obtenir des informations exploitables à partir des données de vos journaux.
## Comment ça marche
CloudWatch Logs Insights peut générer un résumé lisible par l'homme à partir des résultats de vos requêtes à l'aide d'Amazon Bedrock. Cette fonctionnalité prend en charge tous les langages de requête de CloudWatch Logs Insights et fournit des informations claires et exploitables à partir des données de vos journaux.
## Disponibilité régionale et traitement des données
**Important**
Lorsque vous utilisez cette fonctionnalité, les résultats de votre requête peuvent être traités différemment Région AWS. Par exemple, si vous exécutez une requête dans l'est des États-Unis (Virginie du Nord), le résumé peut avoir lieu dans l'ouest des États-Unis (Oregon).
Le tableau suivant répertorie les traitements possibles Région AWS pour les différentes zones géographiques dans lesquelles la fonctionnalité de résultats de requête est disponible :
| Géographie des CloudWatch journaux pris en charge | Région de traitement possible |
| --- | --- |
| États-Unis (US) | US East (N. Virginia) Region US East (Ohio) Region US West (Oregon) Region |
| Europe | Région Europe (Frankfurt) Europe (Ireland) Region Région Europe (Paris) Région Europe (Stockholm) Région Europe (Londres) |
| Asie-Pacifique | US East (N. Virginia) Region US East (Ohio) Region US West (Oregon) Region |
| Amérique du Sud | US East (N. Virginia) Region US East (Ohio) Region US West (Oregon) Region |
## Prise en main
**Pour générer un résumé en langage naturel**
1. Exécutez votre requête CloudWatch Logs Insights.
1. Une fois la requête terminée, sélectionnez **Résumer les résultats**.
## Permissions
Vous devez posséder l'un des éléments suivants :
+ `CloudWatchLogsFullAccess` autorisation
+ `CloudWatchLogsReadOnlyAccess` autorisation
+ Politique IAM personnalisée, y compris les `cloudwatch:GenerateQueryResultsSummary` actions`logs:GetQueryResults`, `logs:DescribeQueries` et `logs:FilterLogEvents`
## Confidentialité des données
Les résultats de vos requêtes sont traités de manière sécurisée et ne sont pas utilisés pour former ou améliorer CloudWatch Logs Insights ou Amazon Bedrock. Si vous choisissez de fournir des commentaires sur le résumé des résultats de la requête à l'aide des boutons de commentaires, vos commentaires indiquent votre niveau de satisfaction à l'égard de la fonctionnalité fournie dans CloudWatch Logs Insights.