Concepts de centralisation des données Configuration de la centralisation des journaux Règles de centralisation de la surveillance et de la résolution des problèmes

Cross-account Centralisation des journaux entre régions

La centralisation des données Amazon CloudWatch Logs permet de AWS Organizations collecter les données de journal de plusieurs comptes membres dans un référentiel de données unique en utilisant des règles de centralisation entre comptes et entre régions. Vous définissez les règles qui répliquent automatiquement les données de journal de plusieurs comptes et Régions AWS dans un compte centralisé au sein de votre organisation. Cette fonctionnalité rationalise la consolidation des journaux pour une surveillance, une analyse et une conformité centralisées améliorées sur l'ensemble de votre AWS infrastructure.

CloudWatch La centralisation des données des journaux offre une flexibilité de configuration pour répondre aux exigences opérationnelles et de sécurité, telles que la possibilité de configurer une région de sauvegarde lors de la configuration des règles dans le compte de destination afin de garantir une résilience accrue. En outre, vous avez un contrôle total sur le comportement de chiffrement des groupes de journaux copiés à partir des comptes sources afin de gérer les données chiffrées à l'origine avec des clés KMS gérées par le client.

Note

La fonction de centralisation des CloudWatch journaux traite uniquement les nouvelles données de journal qui arrivent dans les comptes sources une fois que vous avez créé la règle de centralisation. Les données historiques des journaux (journaux qui existaient avant la création des règles) ne sont pas centralisées.

Concepts de centralisation des données

Avant de commencer à utiliser la centralisation des données des CloudWatch journaux, familiarisez-vous avec les concepts suivants :

Règle de centralisation

Configuration qui définit la manière dont les données de journal des comptes et des régions sources sont répliquées vers un compte et une région de destination. Les règles spécifient les critères de source et les paramètres de destination.

Compte source

Le AWS compte d'où proviennent les données du journal. Les événements du journal provenant des comptes sources sont répliqués vers le compte de destination en fonction des règles de centralisation que vous définissez.

Compte de destination

AWS Compte de destination où les données de journal répliquées sont stockées. Ce compte sert d'emplacement centralisé pour l'analyse et la surveillance des journaux.

Région de sauvegarde

Une région secondaire facultative au sein du compte de destination où les données du journal peuvent être répliquées à des fins de résilience et de reprise après sinistre accrues.

Propagation de balises

Fonctionnalité optionnelle qui propage les balises de ressources des groupes de journaux source vers les groupes de journaux de destination correspondants. La propagation des balises utilise un rôle IAM géré par le client dans le compte de destination pour ajouter, mettre à jour et supprimer des balises dans les groupes de journaux de destination. Vous configurez la propagation des balises en ajoutant un TagPropagationConfiguration bloc à la configuration de destination de votre règle de centralisation.

Chiffrement dans CloudWatch les journaux

Les données des groupes de journaux sont toujours cryptées dans CloudWatch les journaux. Par défaut, CloudWatch Logs utilise le chiffrement côté serveur avec le mode Advanced Encryption Standard Galois/Counter Mode 256 bits (AES-GCM) pour chiffrer les données de journal au repos. Vous pouvez également utiliser le service de gestion des AWS clés pour ce chiffrement. Pour plus d'informations, consultez la documentation sur le chiffrement CloudWatch des journaux.

Fonctionnement du chiffrement lors de la centralisation : la centralisation CloudWatch des journaux copie activement les données du journal au moment de l'ingestion depuis les comptes source vers les comptes de destination. Au cours de ce processus, vos données restent cryptées en transit à l'aide d'une clé de service AWS détenue. Les données stockées dans les groupes de journaux source et de destination sont cryptées à l'aide de la méthode de cryptage que vous avez choisie (clés KMS gérées par le client ou AWS détenues par le client). Si vous utilisez une clé KMS gérée par le client dans vos groupes de journaux de destination, ajoutez la balise LogsManaged = true à la clé KMS pour que le service de centralisation y accède.
Lorsque des autorisations KMS sont requises :
- Si vous utilisez des clés KMS gérées par le client dans vos comptes sources, CloudWatch Logs nécessite des autorisations KMS dans les exemples de scénarios suivants :
  - Gestion du débit : lorsque les limites de débit de centralisation sont atteintes, les données du journal sont temporairement stockées cryptées avec la clé KMS gérée par le client jusqu'à ce que la bande passante soit disponible.
  - Protection des données et rédaction : lorsque les politiques de protection des données sont activées pour les groupes de CloudWatch journaux sources, Logs nécessite des autorisations de déchiffrement pour accéder aux données brutes des journaux afin de les centraliser.

Important

Les règles de centralisation sont gérées par le compte de gestion de l' AWS organisation ou par l'administrateur délégué. Pour exclure les groupes de KMS-encrypted journaux gérés par le client de la centralisation, configurez les paramètres de règle sur « Ne pas centraliser les groupes de journaux chiffrés avec la clé AWS KMS ».

Configuration de la centralisation des journaux

Pour configurer la centralisation CloudWatch des journaux, vous devez configurer des règles de centralisation qui définissent la façon dont les données des journaux circulent des groupes de journaux des comptes sources vers les groupes de journaux de votre compte de destination.

Une fois que la règle de centralisation est activée et que les événements du journal sont répliqués sur le compte de destination, vous pouvez créer des filtres de mesure, d'abonnement et de compte sur des groupes de journaux centralisés dotés de fonctionnalités de filtrage améliorées. Ces filtres peuvent cibler les événements de journal provenant de comptes sources et de régions spécifiques, et peuvent émettre des informations sur le compte source et la région sous forme de dimensions métriques. Pour de plus amples informations, veuillez consulter Création de métriques à partir d'événements du journal à l'aide de filtres.

Conditions préalables

AWS Organizations doit être configuré et les comptes source et de destination doivent tous deux appartenir à l'organisation.
L'accès sécurisé doit être activé pour CloudWatch le compte de gestion et le compte de destination afin de permettre l'accès aux données du journal.

Note
Il est recommandé d'activer l'accès sécurisé via la console, qui crée automatiquement le rôle lié aux services (SLR) requis. Si l'accès sécurisé est activé par d'autres méthodes, le rôle lié au service devra être créé séparément.

Prérequis pour la propagation des balises

Pour activer la propagation des balises, vous devez effectuer la configuration supplémentaire suivante :

Création d'un rôle IAM géré par le client

Vous devez créer un rôle IAM géré par le client dans le compte de destination avec la configuration suivante :

Politique d’approbation

La politique de confiance du rôle doit permettre au rôle lié aux services de centralisation de l'assumer. L'exemple de politique de confiance suivant accorde au rôle AWSServiceRoleForObservabilityAdmin_LogsCentralization lié au service l'autorisation d'assumer le rôle de destination. <destination-account-id>Remplacez-le par l'identifiant de votre compte de destination et <organization-id> par votre AWS Organizations identifiant.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<destination-account-id>:role/aws-service-role/logs-centralization.observabilityadmin.amazonaws.com/AWSServiceRoleForObservabilityAdmin_LogsCentralization"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "<organization-id>"
      }
    }
  }]
}

Politique d’autorisations

La politique d'autorisations du rôle doit autoriser les opérations de balises sur les groupes de journaux de destination. L'exemple suivant accorde les autorisations minimales requises. Remplacez <destination-account-id> par votre valeur. Vous pouvez Resource étendre la portée à des modèles d'ARN de groupes de journaux spécifiques.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "logs:ListTagsForResource",
      "logs:TagResource",
      "logs:UntagResource"
    ],
    "Resource": "arn:aws:logs:*:<destination-account-id>:log-group:*"
  }]
}

Objectif de la subvention : PassRole autorisation

Vous devez disposer d'une iam:PassRole autorisation sur le rôle de destination, limité au service de centralisation via la clé de iam:PassedToService condition. L'exemple suivant accorde l'autorisation de transmettre le rôle. Remplacez <destination-account-id> et <your-tag-role-name> par vos valeurs.

Note

Cette déclaration concerne votre politique d'identité (l'appelant principal CreateCentralizationRuleForOrganization ouUpdateCentralizationRuleForOrganization), et non le rôle de destination lui-même.


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::<destination-account-id>:role/<your-tag-role-name>",
    "Condition": {
      "StringEquals": {
        "iam:PassedToService": "logs-centralization.observabilityadmin.amazonaws.com"
      }
    }
  }]
}

Personnalisation des noms des groupes de journaux de destination

Lorsque vous créez une règle de centralisation, vous pouvez personnaliser la façon dont les noms des groupes de journaux de destination sont structurés à l'aide d'attributs. Ces attributs sont automatiquement remplacés par des valeurs réelles lors de la création de groupes de journaux, ce qui vous permet d'organiser les journaux de manière hiérarchique dans votre compte de destination. Par défaut, seul l'${source.logGroup}attribut est utilisé, qui fusionne tous les groupes de journaux portant le même nom dans le compte de destination. Si une variable ne peut pas être résolue, elle hérite de la valeur de sa variable parente dans la hiérarchie.

Attributs disponibles

Vous pouvez utiliser les attributs suivants dans le modèle de nom de votre groupe de journaux de destination :

Attributs du nom du groupe de journaux de destination
Attribut	Description
`${source.accountId}`	L'identifiant du AWS compte dont provient le journal.
`${source.region}`	L' Région AWS origine du journal.
`${source.logGroup}`	Le nom du groupe de journaux d'origine provenant du compte source.
`${source.org.id}`	AWS Organizations L'identifiant du compte source.
`${source.org.ouId}`	L'identifiant de l'unité organisationnelle du compte source
`${source.org.rootId}`	L'ID racine de l'organisation
`${source.org.path}`	Le parcours organisationnel complet du compte à la racine

Exemples

Préserver la structure d'origine du groupe de journaux

Modèle : /centralized/${source.accountId}${source.logGroup}

Résultat: /centralized/123456789012/aws/lambda/my-function

Organiser par compte et par région

Modèle : /centralized/${source.accountId}/${source.region}

Résultat: /centralized/123456789012/us-east-1

Organiser par structure organisationnelle

Modèle : /logs/${source.org.id}/${source.org.ouId}/${source.accountId}

Résultat: /logs/o-abc123/ou-xyz-12345678/123456789012

Structure plate simple

Modèle : /centralized-logs

Résultat: /centralized-logs

Bonnes pratiques

Incluez l'identifiant du compte source pour identifier facilement les journaux de compte d'où proviennent les journaux de compte.
Incluez la région source si vous centralisez à partir de plusieurs régions.
Structurez les noms des groupes de journaux de destination de manière à ce qu'ils comportent moins de 512 caractères. CloudWatch Logs impose une longueur de nom de groupe de journaux maximale de 512 caractères.
Si vous activez la propagation des balises, le modèle doit contenir les trois attributs : ${source.logGroup}${source.accountId}, et${source.region}. Cela garantit que chaque groupe de journaux source correspond à un groupe de journaux de destination unique.

Création d'une règle de centralisation

Suivez la procédure suivante pour créer une règle de centralisation qui réplique les données de journal des comptes sources vers votre compte de destination.

Pour créer une règle de centralisation

Accédez à la CloudWatch console dans le compte de gestion ou d'administrateur délégué de l'organisation.
Cliquez sur Paramètres.
Accédez à l'onglet Organisation.
Choisissez Configurer la règle.
Spécifiez les détails de la source en définissant les champs suivants, puis choisissez Suivant :
1. Nom de la règle de centralisation : entrez un nom unique pour la règle de centralisation.
2. Comptes sources : définissez des critères de sélection des sources pour sélectionner les comptes à partir desquels les données de télémétrie seront centralisées. Les critères de sélection peuvent inclure :
  - Liste des comptes des membres de l'organisation
  - Liste des unités organisationnelles de l'organisation
  - L'ensemble de l'organisation
  Vous pouvez fournir les critères de sélection selon deux modes :
  - Builder : une expérience basée sur les clics pour générer les critères de sélection des sources
  - Éditeur : zone de texte libre fournissant les critères de sélection de la source
  Syntaxe prise en charge pour les critères de sélection des sources :
  - Clés prises en charge : OrganizationId OrganizationUnitId | AccountId | | *
  - Opérateurs pris en charge : = | IN | OR
3. Régions sources : sélectionnez une liste de régions pour rechercher les données de télémétrie à centraliser.
Spécifiez les détails de la destination en définissant les champs suivants, puis choisissez Suivant :
1. Compte de destination : sélectionnez un compte dans l'organisation qui fait office de destination centrale pour les données de télémétrie.
2. Région de destination : sélectionnez une région principale qui stocke une copie des données de télémétrie centralisées.
3. Région de sauvegarde : sélectionnez éventuellement une région qui stocke une deuxième copie des données de télémétrie centralisées.
Spécifiez les données de télémétrie en définissant les champs suivants, puis choisissez Suivant :
1. Groupes de journaux : choisissez l'une des options suivantes :
  - Tous les groupes de journaux : centralisez les journaux de tous les groupes de journaux dans les comptes sources.
  - Filtrer le groupe de journaux : centralisez les journaux d'un sous-ensemble de groupes de journaux dans les comptes sources, en fonction des critères de sélection. Vous pouvez fournir les critères de sélection selon deux modes :
    Builder : une expérience basée sur les choix pour générer les critères de sélection
    
    Editeur : zone de texte libre fournissant les critères de sélection
    Vous pouvez utiliser deux critères de sélection pour filtrer les journaux :
    Critères de sélection des groupes de journaux : critères de sélection qui spécifient les groupes de journaux sources à centraliser.
    
    Clés prises en charge : LogGroupName | *
    
    Opérateurs pris en charge : = | ! = | DANS | PAS DEDANS | ET | OU | J'AIME | PAS COMME
    
    Critères de sélection des sources de données : critères de sélection qui spécifient les sources de données à centraliser.
    
    Clés prises en charge : DataSourceName | DataSourceType
    
    Opérateurs pris en charge : = | ! = | DANS | PAS DEDANS | ET | OU | J'AIME | PAS COMME
    Lorsque les critères de sélection du groupe de journaux et les critères de sélection de la source de données sont spécifiés, un événement de journal doit répondre à ces deux critères pour être centralisé.
2. Groupe de journaux chiffrés KMS
  
  Important
  CloudWatch les règles de centralisation ne fourniront pas les journaux du compte source aux groupes de journaux de destination si la clé KMS fournie dans la règle de centralisation n'autorise pas CloudWatch les journaux à l'utiliser. Si vous utilisez une clé KMS gérée par le client dans vos groupes de journaux de destination, ajoutez la balise LogsManaged = true à la clé KMS. Pour de plus amples informations, veuillez consulter Étape 2 : Définition des autorisations sur la clé KMS.
  
  Choisissez l’une des options suivantes :
  - Centralisez les groupes de journaux sources chiffrés avec des clés KMS gérées par le client à l'aide d'une clé KMS gérée par le client spécifique à la destination : centralisez les événements de journal provenant des groupes de journaux source chiffrés avec des clés KMS gérées par le client dans des groupes de journaux de destination chiffrés avec une clé KMS gérée par le client dans le compte de destination.
    
    Lorsque ce paramètre est sélectionné, vous devez également définir les paramètres suivants :
    ARN de la clé de chiffrement de destination : ARN de la clé KMS gérée par le client dans le compte de destination et la région de destination principale, à associer aux groupes de journaux de destination récemment créés.
    
    ARN de la clé de chiffrement de destination de sauvegarde (si la région de sauvegarde est sélectionnée) : ARN de la clé KMS gérée par le client dans le compte de destination et la région de destination de sauvegarde, à associer aux groupes de journaux de destination nouvellement créés.
    
    Ignorez la centralisation vers les groupes de journaux de destination non chiffrés (facultatif) : s'il existe déjà un groupe de journaux sans clé KMS gérée par le client, CloudWatch impossible de mettre à jour son chiffrement. Choisissez cette option pour ignorer la centralisation des événements de journal depuis les groupes de journaux sources chiffrés avec des clés KMS gérées par le client vers les groupes de journaux de destination qui ne sont pas associés à une clé KMS gérée par le client.
  - Centralisez les groupes de journaux chiffrés avec des clés KMS gérées par le client dans le compte de destination avec une clé KMS AWS propriétaire : centralisez les événements de journal provenant de groupes de journaux sources chiffrés avec des clés KMS gérées par le client dans des groupes de journaux de destination nouvellement créés chiffrés à l'aide d'une clé KMS AWS propriétaire.
  - Ne centralisez pas les groupes de journaux chiffrés avec des clés KMS gérées par le client : ignorez la centralisation des événements de journal provenant des groupes de journaux sources chiffrés avec des clés KMS gérées par le client.
Passez en revue la règle de centralisation, apportez éventuellement des modifications de dernière minute et choisissez Créer une politique de centralisation.

Modifier une règle de centralisation

Suivez la procédure suivante pour modifier une règle de centralisation existante.

Pour modifier une règle de centralisation

Accédez à la CloudWatch console dans le compte de gestion ou d'administrateur délégué de l'organisation.
Cliquez sur Paramètres.
Accédez à l'onglet Organisation.
Choisissez Gérer les règles.
Sélectionnez la règle à mettre à jour et choisissez Modifier.
Mettez à jour la configuration des règles si nécessaire, en choisissant Suivant pour passer à chaque étape.
À l'étape 4, Réviser et configurer, choisissez Mettre à jour la politique de centralisation.

Afficher une règle de centralisation

Suivez la procédure suivante pour afficher les détails d'une règle de centralisation existante.

Pour afficher une règle de centralisation

Accédez à la CloudWatch console dans le compte de gestion ou d'administrateur délégué de l'organisation.
Cliquez sur Paramètres.
Accédez à l'onglet Organisation.
Choisissez Gérer les règles.
Consultez la liste de toutes les règles de centralisation existantes et choisissez un nom de règle spécifique pour en afficher les détails.

Supprimer une règle de centralisation

Suivez la procédure suivante pour supprimer une règle de centralisation existante.

Pour supprimer une règle de centralisation

Accédez à la CloudWatch console dans le compte de gestion ou d'administrateur délégué de l'organisation.
Cliquez sur Paramètres.
Accédez à l'onglet Organisation.
Choisissez Gérer les règles.
Sélectionnez la règle à supprimer, puis choisissez Supprimer.
Pour confirmer la suppression, choisissez Supprimer.

Règles de centralisation de la surveillance et de la résolution des problèmes

Vous pouvez surveiller l'état et les performances de vos règles de centralisation à l'aide de CloudWatch métriques, de la console CloudWatch Logs et AWS CloudTrail des journaux. Cela vous permet de vous assurer que les données du journal sont correctement répliquées et d'identifier tout problème lié à votre configuration de centralisation.

CloudWatch Logs fournit :

État de santé des règles par règle de centralisation
1. Cliquez sur Paramètres.
2. Accédez à l'onglet Organisation.
3. Choisissez Gérer les règles.
Enregistre les appels d'API avec AWS CloudTrail
CloudWatch publie également des mesures à des fins de centralisation, notamment les événements de journalisation répliqués, les erreurs et la limitation. Pour plus d'informations sur ces mesures et leurs dimensions, consultezMesures et dimensions de centralisation.

État de santé des règles de centralisation

Chaque règle de centralisation possède un état de santé qui indique si elle fonctionne correctement. Vous pouvez vérifier l'état des règles via la console ou par programmation à l'aide de l'API.

Les états de santé des règles incluent :

HEALTHY: La règle fonctionne normalement et réplique les données du journal telles qu'elles sont configurées
UNHEALTHY: la règle a rencontré des problèmes et ne réplique peut-être pas correctement les données
PROVISIONING: La centralisation de l'organisation est en cours de mise en place.

Lorsqu'une règle est marquée comme étant MALSAINE, le FailureReason champ fournit des détails sur le problème spécifique qui doit être résolu.

État de santé de la propagation des balises

La propagation des étiquettes possède son propre état de santé (TagPropagationStatus) qui est indépendant de l'état général RuleHealth de livraison des journaux. Si vous ne configurez pas correctement le rôle de destination, l'état général de vos règles n'est pas affecté : seule la propagation des balises est signalée comme étant défectueuse.

Healthy: La dernière tentative de propagation de balises a réussi.
Unhealthy: La dernière tentative de propagation de balises a échoué. Consultez le TagPropagationFailureReason champ pour plus de détails. Consultez la section de dépannage ci-dessous pour connaître les étapes de correction.

Surveillance des appels d'API de centralisation avec AWS CloudTrail

AWS CloudTrail enregistre les appels d'API effectués vers le service de centralisation, ce qui vous permet de suivre les modifications de configuration et de résoudre les problèmes liés aux comptes membres de votre. AWS Organizations

Les principaux CloudTrail événements liés à la centralisation sont les suivants :

CreateCentralizationRuleForOrganization: lorsqu'une nouvelle règle de centralisation est créée
UpdateCentralizationRuleForOrganization: lorsqu'une règle existante est modifiée
DeleteCentralizationRuleForOrganization: Lorsqu'une règle est supprimée
GetCentralizationRuleForOrganization: Lorsque les détails des règles sont récupérés
ListCentralizationRulesForOrganization: Quand les règles sont répertoriées

Vous pouvez utiliser CloudTrail les journaux pour auditer les modifications de configuration de la centralisation et les mettre en corrélation avec des problèmes de performances ou des échecs de réplication.

Recommandations de surveillance

Pour garantir le bon fonctionnement de la centralisation, nous vous recommandons de configurer des CloudWatch alarmes sur les principales mesures de centralisation que nous vendons à CloudWatch Metrics. Cette surveillance proactive vous aide à détecter les problèmes à un stade précoce et à maintenir une centralisation fiable des journaux dans l'ensemble de votre organisation.

Les principaux indicateurs à surveiller sont les suivants :

IncomingCopiedBytes: surveillez le volume de données de journal répliquées avec succès sur votre compte de destination. Une baisse soudaine ou l'absence de cette métrique peut indiquer des problèmes de centralisation.
CentralizationError: configurez des alarmes pour détecter toute erreur dans le processus de centralisation afin d'identifier et de résoudre rapidement les problèmes.
CentralizationThrottled: surveillez les événements de limitation susceptibles d'avoir un impact sur les performances de réplication des journaux.

Pour obtenir la liste complète des mesures de centralisation disponibles et de leurs dimensions, consultezMesures et dimensions de centralisation.

Si les journaux ne sont pas centralisés comme prévu, examinez les scénarios courants suivants qui peuvent empêcher la centralisation des journaux.

Données du journal historique

Autorisations relatives aux clés KMS

Les règles de centralisation ne fourniront pas les journaux du compte source aux groupes de journaux de destination si la clé KMS fournie dans la règle de centralisation n'autorise pas CloudWatch Logs à l'utiliser. Assurez-vous que la politique de clé KMS accorde les autorisations nécessaires aux CloudWatch journaux. Pour de plus amples informations, veuillez consulter Étape 2 : Définition des autorisations sur la clé KMS.

Configuration des clés KMS gérées par le client

Si vous avez sélectionné Ne pas centraliser les groupes de journaux chiffrés avec la clé KMS gérée par le client lors de la création de la règle, les événements de journal provenant des groupes de journaux sources chiffrés avec la clé KMS gérée par le client seront ignorés et ne seront pas centralisés.

Incompatibilité de chiffrement de destination

Si le groupe de journaux de destination existe déjà avec une configuration de chiffrement KMS différente de celle spécifiée par la règle de centralisation et que la résolution des conflits est définie sur SKIP, les enregistrements seront supprimés et une DestinationEncryptionMismatch erreur sera émise. Par exemple, cela se produit lorsque la destination dispose d'un chiffrement par défaut mais que la règle spécifie une clé KMS gérée par le client.

Accès sécurisé non activé

L'accès sécurisé doit être activé pour CloudWatch que le compte de gestion et le compte de destination puissent accéder aux données du journal. AWS Organizations

Critères de sélection des sources

Vérifiez que les critères de sélection des sources de votre règle de centralisation sont correctement configurés :

Comptes et régions : assurez-vous que les comptes sources et les régions d'où proviennent les journaux sont inclus dans la règle. Les groupes de journaux provenant de comptes ou de régions non spécifiés dans la règle ne seront pas centralisés.
Filtres de groupes de journaux : si vous avez configuré des filtres de groupes de journaux, seuls les groupes de journaux correspondant aux critères spécifiés seront centralisés. Vérifiez que vos critères de sélection des groupes de journaux incluent les groupes de journaux que vous souhaitez centraliser.
Appartenance à une organisation : les comptes source et de destination doivent appartenir à la même AWS Organizations organisation. Les comptes extérieurs à l'organisation ne peuvent pas participer à la centralisation.

Limite de quota de groupe de journaux atteinte

Si le compte de destination a atteint sa limite de quota de groupes de journaux, il n'est pas possible de créer de nouveaux groupes de journaux à des fins de centralisation. Vérifiez que le quota du compte de destination est suffisant pour accueillir des groupes de journaux centralisés provenant de tous les comptes sources. Vous pouvez demander une augmentation de quota si nécessaire.

La limite de longueur du nom du flux de journaux est dépassée

Les noms des flux de journaux sont soumis à des restrictions de longueur maximale. Lorsque la centralisation réplique les flux de journaux vers le compte de destination, un suffixe est ajouté au nom du flux de journaux. Si le nom du flux de log qui en résulte dépasse la longueur maximale autorisée, les enregistrements seront supprimés et une InvalidLogStream erreur sera émise sur le compte client.

Règle : état de santé

Vérifiez l'état de santé de la règle de centralisation dans la console ou à l'aide de l'GetCentralizationRuleForOrganizationAPI. Si la règle est marquée comme étant MALSAINE, consultez le FailureReason champ pour obtenir des informations spécifiques sur le problème.

État de santé de la propagation des balises

Si cela s'TagPropagationStatusafficheUnhealthy, cochez le TagPropagationFailureReason champ :

RoleNotAssumable: Le service ne peut pas assumer le rôle de destination. Vérifiez que la politique de confiance du rôle permet au rôle lié au service de centralisation de l'assumer et qu'elle sts:ExternalId correspond à l'identifiant de votre organisation.
RoleLacksPermissions: le rôle a été assumé mais l'appel de l'API du tag a été refusé. Assurez-vous que la politique d'autorisations du rôle accorde logs:ListTagsForResourcelogs:TagResource, et logs:UntagResource sur les groupes de journaux de destination.

Pour diagnostiquer les problèmes de centralisation, examinez l'état de santé des règles de centralisation dans la console, vérifiez les CloudWatch métriques pour détecter les erreurs et les restrictions, et examinez les AWS CloudTrail journaux pour détecter les échecs d'appels d'API. Pour plus d'informations sur les mesures de centralisation, consultezMesures et dimensions de centralisation.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Résoudre les problèmes avec CloudWatch Logs Live Tail

Utilisation des groupes de journaux et des flux de journaux