Comment dépanner CloudWatch Logs pour qu'il diffuse vers mon domaine Amazon OpenSearch Service ?

Dernière mise à jour : 13/12/2022

Je ne parviens pas à diffuser mes journaux Amazon CloudWatch Logs vers mon domaine Amazon OpenSearch Service. Comment puis-je résoudre ce problème ?

Résolution

Je ne parviens pas à diffuser plusieurs groupes de journaux CloudWatch vers le même domaine OpenSearch Service

Par défaut, Amazon CloudWatch ne crée qu'une seule fonction AWS Lambda pour chaque domaine OpenSearch Service. Si vous configurez plusieurs groupes de journaux pour indexer des données dans votre domaine, tous ces groupes de journaux appellent la même fonction Lambda. Lorsque le premier groupe de journaux appelle une fonction Lambda, l'appel crée un index et un champ de type dans votre domaine.

Les indices créés dans Amazon OpenSearch Service 6.0.0 ou version ultérieure ne peuvent contenir qu'un seul type de mappage. Les indices créés dans les versions 5.x avec plusieurs types de mappage continuent de fonctionner comme auparavant dans OpenSearch Service 6.x. Pour plus d'informations sur l'obsolescence des types de mappage OpenSearch Service, consultez Retrait des types de mappage (langue française non garantie) sur le site web d'Elastic.

Lorsque d'autres groupes de journaux essaient d'appeler la même fonction Lambda, l'appel échoue avec le message d'erreur suivant :

"reason": "Rejecting mapping update to [ ] as the final mapping would have more than 1 type: [log-group-1, log-group-2]” (« raison » : « Rejet de la mise à jour du mappage vers [ ], car le mappage final contiendrait plusieurs types : [log-group-1, log-group-2] »)

Pour résoudre ce problème, mettez d'abord à jour votre fonction Lambda avec la syntaxe suivante :

var indexName = [
     'cwl-' + payload.logGroup.toLowerCase().split('/').join('-') + '-' + timestamp.getUTCFullYear(),
     ('0' + (timestamp.getUTCMonth() + 1)).slice(-2),
     ('0' + timestamp.getUTCDate()).slice(-2) 
     ].join('.');

Cette syntaxe crée plusieurs indices pour les différents groupes de journaux diffusés dans votre domaine OpenSearch Service.

Ensuite, enregistrez la fonction Lambda mise à jour pour créer des indices distincts pour les différents groupes de journaux diffusés en continu dans votre domaine.

Je ne parviens pas à diffuser vers un domaine OpenSearch Service basé sur VPC dans le même compte AWS

Important : avant de diffuser les groupes de journaux CloudWatch vers votre domaine OpenSearch Service basé sur VPC, veillez à mettre à jour votre politique de rôle AWS Identity and Access Management (IAM). La politique AWSLambdaVPCAccessExecutionRole doit être attachée au rôle IAM attaché à la fonction Lambda correspondante.

Voici une politique AWSLambdaVPCAccessExecutionRole au format JSON :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DeleteNetworkInterface"
      ],
      "Resource": "*"
    }
  ]
}

Remarque : cette politique gérée permet à la fonction Lambda d'écrire le groupe de journaux CloudWatch sur votre cluster dans le VPC.

Une fois que vous avez attaché la politique à votre fonction Lambda, vous pouvez commencer à diffuser les journaux vers votre domaine OpenSearch Service dans le VPC.

Je ne parviens pas à diffuser mon groupe de journaux CloudWatch vers un domaine OpenSearch Service lorsque le contrôle d'accès précis est activé

Si vous diffusez vos CloudWatch Logs vers un domaine OpenSearch Service doté d'un contrôle d'accès précis, vous risquez de rencontrer l'erreur d'autorisation suivante :

"{\"statusCode\":403,\"responseBody\":{\"error\":{\"root_cause\":[{\"type\":\"security_exception\",\"reason\":\"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::123456789101:role/lambda_opensearch_execution, roles=[arn:aws:iam::123456789101:role/lambda_opensearch_execution], requestedTenant=null]\"}],\"type\":\"security_exception\",\"reason\":\"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::123456789101:role/lambda_opensearch_execution, roles=[arn:aws:iam::123456789101:role/lambda_opensearch_execution], requestedTenant=null]\"},\"status\":403}}"

Si vous recevez ce message d'erreur des journaux de la fonction Lambda, c'est que le mappage de rôle est incomplet.

Remarque : par défaut, OpenSearch Service crée une fonction AWS Lambda pour vous.

Domaines OpenSearch Service exécutant les versions 7.9 et ultérieures (y compris OpenSearch version 1.x)

Pour résoudre le message d'erreur, suivez les étapes suivantes:

1.    Ouvrez OpenSearch Dashboards. Vous trouverez un lien vers OpenSearch Dashboards dans le résumé de domaine de votre console OpenSearch Service.

2.    Dans le volet de navigation, choisissez Sécurité.

3.    Choisissez Rôles.

4.    Choisissez le rôle all_access.

5.    Choisissez l'onglet Utilisateurs mappés.

6.    Dans la boîte de dialogue Utilisateurs mappés, choisissez Gérer le mappage.

7.    Sous Rôles backend, entrez le NRA du rôle d'exécution de la fonction Lambda.

8.    Choisissez Mapper. Vos journaux doivent désormais être diffusés vers votre domaine OpenSearch Service.

Pour plus d'informations sur le mappage des rôles, consultez Mappage des rôles aux utilisateurs.

Domaines OpenSearch Service exécutant les versions 7.8 et antérieures

Pour résoudre le message d'erreur, suivez les étapes suivantes:

1.    Ouvrez OpenSearch Dashboards. Vous trouverez un lien vers OpenSearch Dashboards dans le résumé de domaine de votre console OpenSearch Service.

2.    Dans le volet de navigation de gauche, cliquez sur l'icône de verrouillage.

3.    Sélectionnez Mappages de rôle.

4.    Choisissez all_access et security_manager comme rôles.

Remarque : le rôle all_access permet d'accéder uniquement à votre cluster. En fonction de votre cas d'utilisation, vous pouvez également ajouter un contrôle d'accès précis à votre cluster.

5.    Modifiez le mappage pour all_access.

6.    Pour Rôle de backend, ajoutez le rôle d'exécution de la fonction Lambda et choisissez Envoyer. Vos journaux doivent désormais être diffusés vers votre domaine OpenSearch Service.

Mes CloudWatch Logs ne sont pas livrés à mon domaine OpenSearch Service

Si vous diffusez des CloudWatch Logs (à l'aide de la fonction AWS Lambda par défaut) vers votre domaine OpenSearch Service, vous risquez de rencontrer l'erreur d'indexation suivante :

"errorMessage": "{\"statusCode\":200,\"responseBody\":{\"took\":42,\"errors\":true}}",

Remarque : par défaut, les erreurs AWS Lambda sont renvoyées sous forme de réponses 200 OK.

Pour résoudre ce message d'erreur, effectuez les opérations suivantes :

1.    Ouvrez la fonction AWS Lambda par défaut.

2.    Trouvez la ligne de code suivante :

"var logFailedResponses = false;"

3.    Mettez à jour la valeur var logFailedResponses en la définissant sur « true ». Cette mise à jour fournit des informations supplémentaires pour toute nouvelle demande d'indexation utilisant la fonction AWS Lambda. Vous pouvez utiliser les informations supplémentaires pour identifier la cause de votre problème d'indexation.

Je reçois une erreur cluster_block_exception

Les exceptions de bloc de cluster sont causées par les éléments suivants :

  • Manque d'espace de stockage libre
  • Pression de mémoire JVM excessive

Pour plus d'informations sur le dépannage des exceptions de bloc de cluster, consultez ClusterBlockException.

Mon filtre d'abonnement CloudWatch n'envoie pas de données à mon cluster via une fonction Lambda par défaut (OpenSearch Service 2.0 et versions ultérieures)

Il est possible que vous receviez un message d'erreur si vous utilisez un filtre d'abonnement CloudWatch pour envoyer des journaux à Amazon OpenSearch Service 2.x à l'aide de la fonction Lambda par défaut. Si le filtre d'abonnement ne parvient pas à intégrer les journaux et que l'erreur suivante s'affiche, cette dernière est due à un paramètre désactivé :

"{\"statusCode\":400,\"responseBody\":{\"error\":{\"root_cause\":[{\"type\":\"illegal_argument_exception\",\"reason\":\"Action/metadata line [1] contains an unknown parameter [_type]\"}],\"type\":\"illegal_argument_exception\",\"reason\":\"Action/metadata line [1] contains an unknown parameter [_type]\"},\"status\":400}}"

Dans les versions 2.0 et ultérieures d'OpenSearch Service, le paramètre _type est supprimé des points de terminaison de l'API. Pour résoudre cette erreur, vous devez également supprimer le paramètre du code de votre fonction Lambda.

1.    Ouvrez la console AWS Lambda.

2.    Sélectionnez la fonction Lambda par défaut pour votre filtre d'abonnement.

3.    Consultez le code de votre fonction sous Source du code.

4.    Recherchez la fonction transform définie dans le code. Au sein de cette fonction, les données sont converties au format d'indexation JSON pour OpenSearch Service. Les premières lignes de ce code ressemblent à ce qui suit :

function transform(payload) {
    if (payload.messageType === 'CONTROL_MESSAGE') {
        return null;
    }

    var bulkRequestBody = '';

    payload.logEvents.forEach(function(logEvent) {
                var timestamp = new Date(1 * logEvent.timestamp);

5.    Sous la fonction transform, recherchez le paramètre _type. Dans la plupart des cas, il se trouvera à la ligne 79. Supprimez ou mettez en commentaire la ligne de code qui ajoute le paramètre _type. Après la suppression, votre code ressemble à ce qui suit :

var action = {
    "index": {}
};
action.index._index = indexName;
//action.index._type = payload.logGroup;
action.index._id = logEvent.id;

bulkRequestBody += [

Vous pouvez désormais envoyer des demandes d'indexation avec succès.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?