Détection des anomalies du journal

Vous pouvez créer un détecteur d'anomalies de journal pour chaque groupe de journaux. Le détecteur d'anomalies analyse les événements du journal ingérés dans le groupe de journaux et détecte les anomalies dans les données du journal. La détection des anomalies utilise l'apprentissage automatique et la reconnaissance de formes pour établir des bases de référence pour le contenu typique des journaux.

Une fois que vous avez créé un détecteur d'anomalies pour un groupe de journaux, celui-ci s'entraîne en utilisant les événements des deux dernières semaines dans le groupe de journaux à des fins d'entraînement. La période d'entraînement peut durer jusqu'à 15 minutes. Une fois la formation terminée, elle commence à analyser les journaux entrants pour identifier les anomalies, qui sont affichées dans la console CloudWatch Logs pour que vous puissiez les examiner.

CloudWatch La reconnaissance des modèles de journaux extrait les modèles de journaux en identifiant le contenu statique et dynamique de vos journaux. 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.

Par exemple, consultez 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 appelés jetons dynamiques. Les jetons dynamiques sont représentés par le <*> moment où CloudWatch Logs affiche le modèle. Chaque valeur différente trouvée pour un jeton dynamique est appelée valeur de jeton.

Les exemples courants de jetons dynamiques incluent les codes d'erreur, les horodatages et les identifiants de demande.

La détection des anomalies dans les journaux utilise ces modèles pour détecter les anomalies. Après la période de formation du modèle de détecteur d'anomalies, les journaux sont évalués par rapport aux tendances connues. Le détecteur d'anomalies signale les fluctuations importantes comme des anomalies.

La création de détecteurs d'anomalies du journal n'entraîne aucun frais.

Gravité et priorité des anomalies et des modèles

Une priorité est attribuée à chaque anomalie détectée par un détecteur d'anomalies logarithmiques. Une gravité est attribuée à chaque modèle détecté.

• La priorité est automatiquement calculée et est basée à la fois sur le niveau de gravité du modèle et sur le degré d'écart par rapport aux valeurs attendues. Par exemple, si la valeur d'un jeton augmente soudainement de 500 %, cette anomalie peut être désignée comme HIGH prioritaire, même si sa gravité l'est. NONE

• La sévérité est basée uniquement sur les mots clés trouvés dans les modèles tels que FATALERROR, etWARN. Si aucun de ces mots clés n'est trouvé, la gravité d'un modèle est marquée commeNONE.

Durée de visibilité des anomalies

Lorsque vous créez un détecteur d'anomalies, vous spécifiez la période maximale de visibilité des anomalies pour celui-ci. Il s'agit du nombre de jours pendant lesquels l'anomalie s'affiche dans la console et est renvoyée par l'opération ListAnomaliesd'API. Une fois ce délai écoulé pour une anomalie, si elle persiste, elle est automatiquement acceptée comme un comportement normal et le modèle de détecteur d'anomalie cesse de la signaler comme une anomalie.

Si vous ne réglez pas le temps de visibilité lorsque vous créez un détecteur d'anomalie, 21 jours sont utilisés par défaut.

Suppression d'une anomalie

Une fois qu'une anomalie a été détectée, vous pouvez choisir de la supprimer temporairement ou définitivement. La suppression d'une anomalie empêche le détecteur d'anomalie de signaler cette occurrence comme une anomalie pendant la durée que vous spécifiez. Lorsque vous supprimez une anomalie, vous pouvez choisir de supprimer uniquement cette anomalie spécifique ou de supprimer toutes les anomalies liées au schéma dans lequel l'anomalie a été détectée.

Vous pouvez toujours consulter les anomalies supprimées dans la console. Vous pouvez également choisir de ne plus les supprimer.

Questions fréquentes (FAQ)

Est-ce que mes données sont AWS utilisées pour entraîner des algorithmes d'apprentissage automatique destinés à être AWS utilisés ou destinés à d'autres clients ?

Non Le modèle de détection des anomalies créé par la formation est basé sur les événements du journal d'un groupe de journaux et n'est utilisé qu'au sein de ce groupe de journaux et de ce AWS compte.

Quels types d'événements de journal fonctionnent bien avec la détection des anomalies ?

La détection des anomalies dans les journaux convient parfaitement aux journaux d'applications et aux autres types de journaux dans lesquels la plupart des entrées de journal correspondent à des modèles classiques. Les groupes de journaux contenant des événements contenant un niveau de journalisation ou des mots clés de gravité tels que INFO, ERROR et DEBUG sont particulièrement adaptés à la détection des anomalies des journaux.

La détection des anomalies du journal n'est pas adaptée pour : enregistrez les événements avec des structures JSON extrêmement longues, tels que CloudTrail les journaux. L'analyse des modèles analyse uniquement les 1 500 premiers caractères d'une ligne de journal, de sorte que tous les caractères dépassant cette limite sont ignorés.

Les journaux d'audit ou d'accès, tels que les journaux de flux VPC, seront également moins efficaces en matière de détection des anomalies. La détection des anomalies est destinée à détecter les problèmes d'application. Elle peut donc ne pas être adaptée aux anomalies du réseau ou de l'accès.

Pour vous aider à déterminer si un détecteur d'anomalies convient à un certain groupe de journaux, utilisez l'analyse des modèles de CloudWatch journaux pour déterminer le nombre de modèles dans les événements de journal du groupe. Si le nombre de modèles n'est pas supérieur à environ 300, la détection des anomalies peut fonctionner correctement. Pour plus d'informations sur l'analyse des modèles, consultezAnalyse de modèles.

Qu'est-ce qui est considéré comme une anomalie ?

Les événements suivants peuvent entraîner le marquage d'un événement du journal comme une anomalie :

• Un événement de journal dont le schéma n'a jamais été observé auparavant dans le groupe de journaux.

• Variation significative par rapport à un schéma connu.

• Nouvelle valeur pour un jeton dynamique comportant un ensemble discret de valeurs habituelles.

• Modification importante du nombre d'occurrences d'une valeur pour un jeton dynamique.

Bien que tous les éléments précédents puissent être marqués comme des anomalies, ils ne signifient pas tous que l'application fonctionne mal. Par exemple, un higher-than-usual certain nombre de valeurs de 200 réussite peuvent être signalées comme des anomalies. Dans de tels cas, vous pouvez envisager de supprimer ces anomalies qui n'indiquent pas de problèmes.

Que se passe-t-il avec les données sensibles masquées ?

Les parties des événements du journal qui sont masquées comme des données sensibles ne sont pas analysées pour détecter toute anomalie. Pour plus d'informations sur le masquage des données sensibles, voir Aider à protéger les données de journal sensibles par le masquage.