Résoudre les problèmes courants
Ce document fournit un ensemble de conseils et de procédures pour vous aider à diagnostiquer et à résoudre les problèmes courants rencontrés lors du déploiement et de l'utilisation de l'agent distant Google Security Operations.
Problème de clé non concordante
Ce problème se produit lorsque les clés privées de Google Security Operations et de l'agent distant ne correspondent pas. Pour résoudre ce problème, assurez-vous que la clé des ressources de l'agent correspond à celle de la base de données agent_db de Siemplify.
Échec du connecteur distant
Si un connecteur distant échoue, procédez comme suit :
- Vérifiez qu'une instance d'intégrations est correctement installée sur l'agent.
- Consultez les journaux de l'agent au niveau d'erreur pour détecter les échecs dans le processus de connexion.
- Testez la même configuration de connecteur en local et vérifiez s'il y a des erreurs.
Échec de l'installation : OS hôte non compatible ou incompatibilités fin de vie
Si les nouvelles installations ou les mises à niveau automatiques échouent en raison d'erreurs de suivi glibc et de blocs d'appels système, procédez comme suit :
- Vérifiez que l'environnement hôte n'exécute pas un système d'exploitation hérité, qui peut manquer de hooks d'appels système modernes.
- Réhébergez l'environnement de l'agent sur une distribution Linux d'entreprise avec la dernière version officielle.
-
Assurez-vous que l'hôte est une plate-forme compatible : Debian 12 (base officielle), RHEL 8.7 :
Vérifiez
/etc/os-release: exécutez la commande suivante et recherchezNAME=etVERSION_ID=:cat /etc/os-release- Pour Debian 12 : recherchez
NAME="Debian GNU/Linux"etVERSION_ID="12". - Pour RHEL 8.7 : recherchez
NAME="Red Hat Enterprise Linux"etVERSION_ID="8.7".
- Pour Debian 12 : recherchez
La configuration du conteneur extrait la couche opérationnelle précédente au lieu de la dernière version
Si l'exécution de commandes de configuration de conteneur extrait par inadvertance une couche opérationnelle précédente au lieu de la version logicielle nouvellement publiée, exécutez les commandes suivantes pour extraire explicitement la dernière image :
Pour Docker :
docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latestPour Podman :
podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest
Échec du déploiement de l'agent Docker
Si le déploiement Docker échoue, procédez comme suit :
- Supprimez le conteneur Docker :
Exécutez la commande suivante pour répertorier les conteneurs en cours d'exécution :
docker psExécutez la commande suivante pour supprimer les conteneurs ayant échoué :
docker rm -f container_id_or_name
- Supprimez les images :
Exécutez la commande suivante pour répertorier les images :
docker imagesExécutez la commande suivante pour supprimer l'image :
docker rmi image_id_or_name
- Supprimez les volumes :
Exécutez la commande suivante pour répertorier les volumes :
docker volume lsExécutez la commande suivante pour supprimer les volumes :
docker volume rm volume_name
- Redéployez l'agent. Pour en savoir plus, consultez Créer un agent à l'aide de Docker.
Agent bloqué à l'état "En attente de l'agent"
Si l'agent a été déployé correctement, mais que l'état reste "En attente de l'agent", procédez comme suit pour résoudre le problème :
- Vérifiez la connectivité de l'hôte : testez la connectivité Internet de la machine hôte de l'agent (par exemple,
curl www.google.comouping 8.8.8.8). Si cela échoue, le problème provient de la connexion Internet de l'hôte. Vérifiez la connectivité du conteneur : si le test de l'hôte réussit, saisissez le shell du conteneur à l'aide de
docker exec -it container_ID bashet vérifiez à nouveau la connectivité. Si le conteneur n'est pas connecté, redémarrez le service Docker sur la machine hôte (service docker restart).Exécutez la commande suivante :
docker exec -itbash - Vérifiez à nouveau la connectivité comme précédemment.
- Si la connectivité est toujours absente, exécutez la commande suivante pour redémarrer le service Docker à partir de la machine hôte (et non du conteneur) :
service docker restart Exécutez la commande suivante pour redémarrer le conteneur :
docker start
Consultez les journaux du conteneur pour détecter les erreurs.
Si l'étape précédente n'a pas permis de résoudre le problème et que l'état de l'agent est toujours "En attente de l'agent" après avoir actualisé la page Agent distant dans Google SecOps, reconnectez-vous au conteneur et extrayez les journaux.
- Recherchez les journaux dans le répertoire
/var/log/SiemplifyAgent/. - Recherchez les erreurs dans les fichiers journaux pour identifier la cause première.
- Recherchez les journaux dans le répertoire
Échec du chargement de l'image Docker (le transfert IP4 est désactivé)
Si une erreur s'affiche dans l'CLI lorsque vous essayez de charger une image Docker (système) ou un agent Google SecOps, il est possible que le transfert IP4 soit désactivé. Procédez comme suit pour l'activer et redémarrer votre agent :
Ajoutez la ligne suivante au fichier
/etc/sysctl.conf:net.ipv4.ip_forward=1Notez que vous devrez utiliser un éditeur de fichiers (par exemple, nano :yum install nano -yExécutez la commande suivante pour redémarrer le service réseau :
systemctl restart networkExécutez la commande suivante pour redémarrer le service Docker :
sudo systemctl restart dockerExécutez la commande suivante pour vérifier si le conteneur est en cours d'exécution :
docker psSi le conteneur n'est pas en cours d'exécution, exécutez la commande suivante pour répertorier tous les conteneurs (y compris ceux qui sont arrêtés) :
docker ps -aSi le conteneur est répertorié, mais arrêté, exécutez la commande suivante pour le démarrer :
docker start container_id_or_name- Si l'agent ou le système ne fonctionne toujours pas après le redémarrage de Docker et du conteneur :
Exécutez la commande suivante pour arrêter le conteneur :
docker stop container_id_or_nameExécutez la commande suivante pour supprimer le conteneur :
docker rm container_id_or_nameExécutez la commande suivante pour supprimer l'image :
docker rmi image_name- Chargez à nouveau l'image.
Erreur après l'arrêt ou le redémarrage de l'agent
Exécutez la commande suivante pour forcer le démarrage de l'agent du programme d'installation :
systemctl start supervisord
Exécutez la commande suivante pour forcer le démarrage de l'agent Docker :
docker start
Vous avez encore besoin d'aide ? Obtenez des réponses auprès des membres de la communauté et des professionnels de Google SecOps.