Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Problèmes de surveillance du temps d'exécution
<a name="troubleshooting-guardduty-runtime-monitoring"></a>

Cette section répertorie les erreurs que vous pouvez rencontrer lors de la configuration ou de l'utilisation de Runtime Monitoring.

## Problèmes de couverture du temps d'exécution
<a name="troubleshooting-runtime-monitoring-coverage-issues"></a>

Lorsque la couverture d'exécution de vos ressources protégées devient **défaillante**, la GuardDuty console indique le type de problème exact. Une fois que vous avez identifié le type de problème, consultez les documents suivants pour consulter les étapes de résolution des problèmes pour chaque type de ressource pris en charge :
+ [Résolution des problèmes de couverture des environnements d'exécution Amazon EC2](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot)
+ [Résolution des problèmes de couverture du temps d'exécution d'Amazon ECS-Fargate](gdu-assess-coverage-ecs.md#ecs-runtime-monitoring-coverage-issues-troubleshoot)
+ [Résolution des problèmes de couverture du temps d'exécution d'Amazon EKS](eks-runtime-monitoring-coverage.md#eks-runtime-monitoring-coverage-issues-troubleshoot)

## Résolution des erreurs liées au manque de mémoire dans Runtime Monitoring (support Amazon EC2 uniquement)
<a name="troubleshoot-ec2-cpu-out-of-memory-error"></a>

Cette section décrit les étapes de dépannage lorsque vous rencontrez une erreur de mémoire insuffisante suite [Limite du processeur et de la mémoire](prereq-runtime-monitoring-ec2-support.md#ec2-cpu-memory-limits-gdu-agent) au déploiement manuel de l'agent GuardDuty de sécurité.

Si l' GuardDuty agent `systemd` est arrêté à cause du `out-of-memory` problème et que vous estimez qu'il est raisonnable de fournir plus de mémoire à l' GuardDuty agent, vous pouvez mettre à jour la limite.

1. Ouvrez avec l'autorisation root`/lib/systemd/system/amazon-guardduty-agent.service`.

1. Recherchez `MemoryLimit` et `MemoryMax` mettez à jour les deux valeurs.

   ```
   MemoryLimit=256M
   MemoryMax=256M
   ```

1. Après avoir mis à jour les valeurs, redémarrez l' GuardDuty agent à l'aide de la commande suivante :

   ```
   sudo systemctl daemon-reload
   sudo systemctl restart amazon-guardduty-agent
   ```

1. Exécutez la commande suivante pour afficher l’état :

   ```
   sudo systemctl status amazon-guardduty-agent
   ```

   La sortie attendue indiquera la nouvelle limite de mémoire :

   ```
   Main PID: 2540 (amazon-guardduty)
   Tasks: 16
   Memory: 21.9M (limit: 256.0M)
   ```

## Mon AWS Step Functions flux de travail échoue de façon inattendue
<a name="runtime-ecs-step-function-failure"></a>

Si le GuardDuty conteneur a contribué à l'échec du flux de travail, consultez[Résolution des problèmes de couverture du temps d'exécution d'Amazon ECS-Fargate](gdu-assess-coverage-ecs.md#ecs-runtime-monitoring-coverage-issues-troubleshoot). Si le problème persiste, pour éviter l'échec du flux de travail dû au GuardDuty conteneur, effectuez **l'une** des étapes suivantes :
+ Ajoutez le `false` tag `GuardDutyManaged` : au cluster Amazon ECS associé.
+ Désactivez la configuration automatique de l'agent pour AWS Fargate (ECS uniquement) au niveau du compte. Ajoutez la balise d'inclusion `GuardDutyManaged` : `true` au cluster Amazon ECS associé que vous souhaitez continuer à surveiller avec l'agent GuardDuty automatisé.