Skip to main content
Data Infrastructure Insights
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Dépannez le collecteur de données ONTAP SVM

Contributeurs netapp-alavoie
PDF

Utilisez ce guide pour déterminer si un problème de collecteur est causé par la connectivité de gestion, la connectivité de rappel FPolicy, la configuration ONTAP, la capacité de l'agent, la résolution d'identité ou une condition préalable à une fonctionnalité.

Ce document comporte deux parties. Commencez par les vérifications basées sur les symptômes. N'utilisez les diagnostics avancés à la fin que si ces vérifications ne résolvent pas le problème, ou si NetApp Support demande des preuves supplémentaires.

Remarque : Pour connaître les étapes de configuration, les autorisations et les prérequis des fonctionnalités, consultez "Configuration du collecteur de données ONTAP SVM".

Commencez ici

  1. Dans la section Sécurité des charges de travail, sélectionnez Collecteurs. Dans la colonne État, ouvrez Plus de détails et notez la chaîne de caractères complète indiquant la raison.

  2. Sur la page d'ajout ou de modification d'un collecteur, sélectionnez Test Connection. Résolvez chaque vérification échouée avant d'enregistrer.

  3. Choisissez le symptôme correspondant ci-dessous et suivez les vérifications dans l'ordre.

Ouvrez Plus de détails pour voir l'erreur complète du collecteur.

Lien vers plus de détails pour un collecteur en état d'erreur, largeur=624, hauteur=126

Remarque : Pour une validation complète, connectez-vous à l’aide de l’adresse IP de gestion du cluster et du nom de la SVM. Le mode SVM ne peut pas exécuter les vérifications des fonctionnalités et du RBAC. Le test de connexion sollicite des ports FPolicy représentatifs, et non chaque port réservé.

Comprendre les résultats du test de connexion

Résultat Ce que cela valide Où continuer en cas d'échec

HTTPS

L'agent peut accéder à la gestion ONTAP via le port TCP 443.

Impossible d'ajouter le collecteur ou le test de connexion échoue

Version ONTAP

Les informations d'identification fonctionnent ; la version d'ONTAP et l'éligibilité aux fonctionnalités peuvent être lues.

Impossible d'ajouter le collecteur ou le test de connexion échoue

LIF de données

Une LIF de données opérationnelle éligible existe ; ONTAP 9.8+ inclut data-fpolicy-client.

Vérifiez la LIF de données et la politique de service

IP de l'agent

L'agent possède une adresse locale qui peut acheminer vers les LIF de données SVM.

Connectivité de rappel FPolicy

Serveur FPolicy

ONTAP peut se connecter à l’agent sur les ports FPolicy actifs.

Connectivité de rappel FPolicy

Caractéristiques

Le compte et la version ONTAP prennent en charge certaines fonctionnalités optionnelles. Mode cluster uniquement.

Impossible d'ajouter le collecteur ou le test de connexion échoue

Remarque : Le test de connexion ne valide pas l’intégralité de la réservation du port de rappel, le flux réel des événements de fichiers, le comportement MetroCluster ou SVM-DR, la disponibilité de l’agrégat du magasin persistant, les règles MAV, la syntaxe du filtre de partage et de volume, ni les collecteurs d’annuaire utilisateur.

Choisissez votre symptôme

  • Je ne peux pas ajouter le collecteur ou le test de connexion échoue

  • Le statut du collecteur est Erreur

  • L'état du collecteur est dégradé

  • Le collecteur est en cours d'exécution, mais aucune activité n'apparaît

  • L'activité affiche un SID au lieu d'un nom d'utilisateur

  • Les performances d'ONTAP ont changé après l'activation de Workload Security

  • L'utilisation de la capacité ou de l'abonnement semble incorrecte

  • Les actions de snapshot ou de blocage d'utilisateurs échouent

  • L'état du collecteur ou l'événement manquant peut être un comportement attendu

Je ne peux pas ajouter le collecteur, ou le test de connexion échoue

Vérifiez ces éléments dans l'ordre

  1. Confirmez le mode de connexion. Le mode cluster requiert l'adresse IP de gestion du cluster et le nom exact, respectant la casse, de la SVM. Le mode SVM requiert l'adresse IP de gestion de la SVM.

  2. Depuis l'agent, vérifiez la connectivité HTTPS à l'adresse IP de gestion configurée sur le port TCP 443. Un délai d'attente indique un problème de routage ou de pare-feu.

  3. Vérifiez les informations d'identification et les applications attribuées à la connexion ONTAP. Attribuez directement les rôles personnalisés à un utilisateur AD ; les rôles au niveau du groupe peuvent ne pas être visibles lors de la vérification des autorisations.

  4. Vérifiez qu'une interface logique de données SVM éligible est opérationnelle. À partir d'ONTAP 9.8, sa stratégie de service doit inclure data-fpolicy-client avec data-nfs et/ou data-cifs.

  5. Si l'adresse IP SVM et vsadmin sont utilisés, utilisez une LIF dédiée à la gestion uniquement. Une LIF avec des rôles combinés Données et Gestion peut répondre au ping même si l'accès à la gestion échoue.

  6. Pour les fonctionnalités optionnelles, accordez les privilèges indiqués par le test des fonctionnalités, puis exécutez à nouveau Test Connection.

Erreurs exactes couvertes

  • Impossible de déterminer le type d’ONTAP pour [host]. Motif : erreur de connexion au système de stockage : l’hôte est inaccessible

  • [IP] est identifié comme un cluster/nœud et ne peut pas être ajouté dans ce mode

  • Aucune interface de données valide trouvée sur le SVM

  • Autorisation manquante : vserver fpolicy

  • Rôles attribués au niveau du groupe plutôt qu'au niveau de l'utilisateur pour cet utilisateur Active Directory

Résolu lorsque

  • Tous les tests de connexion requis sont réussis et le collecteur peut être enregistré. Les vérifications de fonctionnalités peuvent rester indisponibles uniquement pour les fonctionnalités que vous n'utilisez pas.

Statut du collecteur : Erreur

Utilisez la raison indiquée dans Plus de détails. La plupart des états d'erreur appartiennent à l'un des groupes suivants.

Connectivité du rappel FPolicy

Cela signifie que ONTAP ne peut pas maintenir la connexion qui envoie l'activité des fichiers et des utilisateurs à l'Agent.

  1. Exécutez le test de connexion et inspectez le serveur FPolicy, l’adresse IP de l’agent et les LIF de données.

  2. Autorisez les ports TCP réservés dans la plage 35000–55000 de chaque interface logique de données SVM vers l’Agent, y compris le pare-feu hôte de l’Agent. Chaque SVM utilise jusqu’à quatre ports : deux par protocole activé.

  3. Vérifiez que l'agent est accessible en routage depuis chaque nœud de service de données et chaque LIF de données SVM.

  4. Vérifiez qu'un seul collecteur dans un environnement Workload Security surveille la SVM. Un deuxième collecteur remplace la première destination FPolicy.

  5. Sur ONTAP 9.8 et versions ultérieures, vérifiez que data-fpolicy-client est affecté à une LIF de données SVM opérationnelle.

Erreurs exactes couvertes

  • Serveur fpolicy externe arrêté

  • Le nœud n'a pas pu établir de connexion avec le serveur FPolicy…​ Délai d'attente dépassé

  • Aucune adresse IP locale trouvée sur le connecteur pouvant atteindre les interfaces de données du SVM

Résolu lorsque

  • Le test de connexion indique que le serveur FPolicy a réussi et que le collecteur reste en cours d'exécution après la génération de l'activité du client.

Configuration FPolicy

  1. Pour les erreurs de shares-to-include, saisissez les noms complets des partages sans guillemets. Pour les listes longues, filtrez plutôt par volume.

  2. Si l'utilisateur n'est pas autorisé, ajoutez les privilèges personnalisés spécifiques à la fonctionnalité pour l'utilisateur et redémarrez le collecteur.

  3. En l'absence d'interface de données valide, mettez en service une LIF de données éligible et corrigez sa politique de service.

  4. Si les informations agrégées de Persistent Store ne sont pas disponibles, veuillez patienter quelques minutes et redémarrer le collecteur. Persistent Store requiert ONTAP 9.14.1 ou une version ultérieure.

  5. En l'absence de numéro de séquence valide, demandez à un administrateur ONTAP de supprimer les objets FPolicy inutilisés confirmés, puis redémarrez le collecteur.

Erreurs exactes couvertes

  • Échec de la configuration de fpolicy sur SVM…​ Valeur invalide spécifiée pour shares-to-include

  • Échec de la configuration de fpolicy sur la SVM…​ L’utilisateur n’est pas autorisé

  • Aucun numéro de séquence valide n'est disponible pour activer la politique fpolicy

  • Échec de la configuration du stockage persistant…​ Les informations de performance pour l'agrégat ne sont actuellement pas disponibles

Résolu lorsque

  • La stratégie cloudsecure_ FPolicy est activée et le collecteur reste en cours d'exécution.

Capacité de l’agent ou état de santé du collecteur

  1. Saisissez à nouveau le mot de passe du collecteur : ouvrez Édition, saisissez le mot de passe et enregistrez.

  2. Vérifiez la marge de manœuvre du processeur et de la mémoire de l'agent ainsi que le nombre de collecteurs hébergés.

  3. Utilisez l'outil de vérification du taux d'événements pour comparer le taux d'événements de pointe avec la taille de l'Agent. Ajustez la taille de l'Agent ou migrez les collecteurs si nécessaire.

  4. Si l'action échoue toujours, redémarrez le service Agent et réessayez après la reconnexion de l'Agent.

Erreurs exactes couvertes

  • Serveur fpolicy externe surchargé

  • L'agent n'a pas pu se connecter au collecteur

  • AGENT004 — Collecteur arrêté immédiatement après le démarrage

  • AGENT008 — n'a pas pu déterminer l'état de santé du collecteur

  • AGENT005 / AGENT006 / AGENT007 / AGENT009 / AGENT010

Résolu lorsque

  • L'agent est connecté, le collecteur atteint l'état de fonctionnement, et il reste en bonne santé pendant les pics d'activité.

Statut du collecteur : dégradé

Un collecteur dégradé est toujours en cours d'exécution, mais une ou plusieurs connexions de nœud FPolicy sont déconnectées. L'activité assurée par les nœuds concernés pourrait être manquée.

  1. Ouvrez Plus de détails et identifiez le nœud déconnecté.

  2. Vérifiez si ce nœud possède une LIF de données opérationnelle pour la SVM surveillée.

  3. Si le nœud ne dispose d'aucune LIF de données locale pour la SVM, aucune correction n'est requise.

  4. Si une LIF de données existe, vérifiez qu'elle est opérationnelle, qu'elle transporte data-fpolicy-client sur ONTAP 9.8+ et qu'elle peut atteindre les ports de callback de l'Agent.

  5. Autorisez le collecteur à revenir à l'état d'exécution après la reconnexion du nœud.

Erreurs exactes couvertes

  • Serveur FPolicy déconnecté sur le(s) nœud(s) : …​

  • Aucune interface réseau locale n'est présente pour se connecter au serveur FPolicy

Résolu lorsque

  • Tous les nœuds de diffusion de données disposent de canaux FPolicy connectés. Un nœud sans LIF de données locale n'a pas besoin de connexion.

Le collecteur est en cours d'exécution, mais aucune activité n'apparaît

  1. Générez une activité réelle du client SMB ou NFS sur un partage ou un volume surveillé. Aucune E/S client ne produit d'événements.

  2. Vérifiez que le collecteur n'est pas en pause. Reprenez-le avant de tester.

  3. Vérifiez que le protocole client est activé et, pour SMB, que la SVM dispose d'un serveur CIFS.

  4. Examinez les partages et les volumes inclus et exclus. Utilisez des noms complets sans guillemets.

  5. Activez la surveillance des accès aux dossiers lorsque des événements généraux d'accès aux dossiers sont requis. La création, le renommage et la suppression de dossiers sont collectés sans cette option.

  6. Si seules les activités .ini et .DS_Store sont manquantes, aucune action n'est requise ; ces extensions sont exclues de la collecte d'événements FPolicy.

  7. Si aucune activité n'est toujours constatée, utilisez les diagnostics avancés pour vérifier la politique cloudsecure_ et le journal des événements FPolicy d'ONTAP.

Résolu lorsque

  • Les nouvelles opérations client apparaissent dans Activity Forensics avec le protocole, le partage, le chemin et les informations utilisateur attendus.

L'activité affiche un SID au lieu d'un nom d'utilisateur

L'audit ONTAP fonctionne ; la résolution d'identité est un problème distinct.

  1. Vérifiez qu'un collecteur d'annuaire utilisateur en cours d'exécution existe pour chaque domaine dont les utilisateurs accèdent à la SVM surveillée, y compris les domaines de confiance.

  2. Vérifiez que le collecteur d'annuaire couvre la forêt ou la base de recherche correcte et utilise des informations d'identification de liaison valides.

  3. Vérifiez les attributs mappés : Active Directory utilise name, objectsid et sAMAccountName ; LDAP utilise name, uidnumber et uid.

  4. Redémarrez le collecteur d'annuaire utilisateur pour demander une synchronisation immédiate après l'ajout d'utilisateurs ou la correction de la configuration.

  5. Consultez la page de dépannage du collecteur AD ou LDAP pour les erreurs de connexion et d'association. Le test de connexion n'est pas disponible pour les collecteurs d'annuaire utilisateur.

Résolu lorsque

  • La nouvelle activité affiche le nom d'utilisateur attendu au lieu du SID ou de l'UID brut.

Les performances d'ONTAP ont changé après l'activation de Workload Security

  1. Utilisez ONTAP 9.13.1 ou une version ultérieure pour corriger les problèmes de latence connus de FPolicy.

  2. Vérifiez l'activité maximale et le dimensionnement de l'Agent à l'aide de l'Event Rate Checker. Déplacez les collecteurs ou augmentez la taille de l'Agent s'il ne peut pas supporter le taux d'événements.

  3. Vérifiez si la surveillance de l'accès aux dossiers a sensiblement augmenté le volume d'événements.

  4. Pour les versions ONTAP prises en charge, envisagez d'utiliser Persistent Store pour mettre en mémoire tampon les événements lors d'interruptions temporaires de connectivité.

  5. En cas de panne de nœud ou de latence de stockage persistante, collectez les preuves ONTAP et contactez le support NetApp.

Résolu lorsque

  • La latence et les IOPS d'ONTAP restent dans la plage attendue pendant que la collecte FPolicy est active.

La capacité ou l’utilisation de l’abonnement semble incorrecte

  1. Comparez la capacité brute rapportée par les collecteurs de cluster Observability ONTAP et les collecteurs SVM de Workload Security.

  2. Pour chaque collecteur SVM, vérifiez si son cluster parent est déjà surveillé par un collecteur Observability. Le même stockage ne doit pas être compté deux fois.

  3. Vérifiez si une migration SVM a été effectuée récemment. Vérifiez que le collecteur est en cours d'exécution et redémarrez-le afin que les informations actuelles sur le cluster et la capacité soient collectées.

  4. Si le total inclut toujours la capacité du cluster et celle du SVM, collectez les données d'utilisation avant et après ainsi que la capacité déclarée pour chaque collecteur.

Résolu lorsque

  • L'utilisation de l'abonnement inclut la capacité de stockage une seule fois et reflète le cluster parent actuel de la SVM.

Les actions de snapshot ou de blocage d'utilisateur échouent

  1. Vérifiez que le collecteur est en cours d'exécution et non en pause.

  2. Pour bloquer les utilisateurs, utilisez les identifiants au niveau du cluster. Un utilisateur personnalisé a également besoin d'un accès SSH sur TCP 22 et des privilèges de blocage documentés.

  3. Vérifiez que l'utilisateur personnalisé dispose des privilèges de snapshot requis.

  4. Si ONTAP Multi-Admin Verify est activé, ajoutez les exclusions documentées pour les snapshots cloudsecure_ et l'opération set utilisée par le blocage des utilisateurs.

  5. Exécutez Test Connection en mode cluster et examinez les résultats des fonctionnalités Snapshot et User Blocking.

Résolu lorsque

  • Workload Security peut créer et supprimer ses instantanés et peut bloquer et rétablir l'accès des utilisateurs.

Comportement attendu — aucune action requise

Ce que vous voyez Pourquoi cela se produit Quand enquêter

MetroCluster le collecteur de secours est arrêté

Utilisez un collecteur en mode cluster pour la source et un autre pour la destination. Seul le collecteur SVM actif s'exécute. Prévoyez jusqu'à deux minutes après le basculement.

Le collecteur côté actif ne passe pas à l’état « En cours d’exécution ».

Dégradé répertorie un nœud sans LIF de données locales

ONTAP ne peut pas établir de canal FPolicy à partir d'un nœud qui ne dessert pas localement la SVM.

Le nœud listé possède une interface de données SVM opérationnelle.

Aucun événement pour .ini ou .DS_Store

Ces extensions sont exclues du périmètre de FPolicy.

D'autres activités de fichiers attendues sont également manquantes.

Bref état d'initialisation, d'arrêt ou de dégradation

Le redémarrage, la mise à niveau, la migration, le basculement et la reprise nécessitent une reconnexion.

L'état persiste au-delà de l'opération ou se répète.

Diagnostics avancés et collecte de données de support

N'utilisez cette section que si les vérifications ci-dessus ne résolvent pas le problème, ou si le support NetApp demande des preuves supplémentaires. Ces procédures nécessitent un accès administrateur à l'hôte de l'agent et à ONTAP._

Recueillez des preuves avant de modifier l'environnement

  1. Consignez la raison complète de l'état du collecteur et l'heure de la panne.

  2. Enregistrez le résultat du test de connexion.

  3. Enregistrez les versions de l'agent et du collecteur, la version d'ONTAP, le nom du SVM, le mode de connexion et les modifications récentes.

  4. Générez le bundle de symptômes de l'agent une seule fois afin que les journaux antérieurs à vos modifications soient préservés.

sudo /opt/netapp/cloudsecure/agent/bin/cloudsecure-agent-symptom-collector.sh -o /tmp

La commande crée le fichier cloudsecure-agent-symptoms.zip. Installez zip si le script indique que la commande zip est introuvable.

Emplacements des journaux

Preuve Emplacement ou commande

Journal de collecte

/opt/netapp/cloudsecure/data-collectors//logs/dsc.log

Contient toutes les activités du collecteur, y compris les erreurs. Utilisez ce journal pour analyser les problèmes du collecteur.

Journal de l'agent

/opt/netapp/cloudsecure/agent/logs/agent.log

Installation et mise à niveau de l'agent

/opt/netapp/cloudsecure/agent/logs/cloudsecure_agent_install.log

/opt/netapp/cloudsecure/agent/logs/cloudsecure_agent_upgrade.log

Test de connexion

/opt/netapp/cloudsecure/test-connection/logs/

Service d'agent

systemctl status cloudsecure-agent.service

journalctl -u cloudsecure-agent.service

Remarque : Le répertoire des journaux du collecteur peut également contenir un fichier error.log, mais il ne s'agit pas d'un journal d'erreurs général. Il n'est créé que lorsqu'un collecteur ne peut pas démarrer en raison d'une configuration incorrecte, et l'Agent le supprime après avoir signalé cette raison dans l'état du collecteur. Il est généralement absent ou vide, utilisez donc dsc.log.

Valider l'état FPolicy ONTAP

Exécutez ces commandes depuis le contexte d'administration ONTAP approprié :

event log show -source fpolicy
event log show -source fpolicy -fields event,action,description
fpolicy show
fpolicy show-engine

Recherchez une stratégie Workload Security avec le préfixe cloudsecure_. Cette stratégie doit être activée, et chaque nœud de service de données doit afficher un moteur externe connecté. Conservez la raison de l'événement et le nom du nœud lorsqu'un canal est déconnecté.

Valider chaque chemin réseau

Direction Port Objectif

Agent → Adresse IP de gestion du cluster ou de la SVM

TCP 443

Configurez et interrogez ONTAP.

LIF de données SVM → Agent

Ports réservés dans la plage TCP 35000–55000

Fichier FPolicy et activité utilisateur. Jusqu'à quatre ports par SVM : deux par protocole activé.

IP de gestion du cluster → Agent

Ports réservés dans la plage TCP 35000–55000

Événements basés sur EMS, y compris les intégrations ARP.

Agent → Adresse IP de gestion du cluster

TCP 22

Blocage des utilisateurs SMB avec les informations d'identification du cluster.

Remarque : Le test de connexion valide les ports de rappel représentatifs en temps réel. Il ne prouve pas que chaque port de la plage réservée du pare-feu est ouvert.

Connectivité de l’agent à la gestion ONTAP

curl -kv https://<management-ip>:443

Une réponse TLS confirme le chemin TCP. Un délai d'attente indique un blocage de routage ou de pare-feu. Une réponse d'authentification prouve l'accessibilité, mais pas que les informations d'identification ou les rôles sont corrects.

Connectivité ONTAP vers le rappel de l'agent

Depuis ONTAP, testez le routage à partir de chaque LIF de données SVM pertinente :

network ping -vserver <svm> -lif <data-lif> -destination <agent-ip> -show-detail

Sur l'agent, inspectez le pare-feu hôte :

sudo firewall-cmd --zone=public --list-ports
sudo iptables-save

Vérifiez que les ports de rappel réservés sont autorisés en entrée depuis toutes les LIF de données SVM et, pour les fonctionnalités basées sur EMS, depuis l'adresse IP de gestion du cluster.

Vérifiez la LIF de données et la politique de service

À partir d'ONTAP 9.8 et des versions ultérieures, une LIF de données SVM opérationnelle doit inclure data-fpolicy-client avec data-nfs et/ou data-cifs.

 network interface show -vserver <svm> -fields service-policy,status-admin,status-oper
Si aucune politique appropriée n'existe, créez-en une ou modifiez-en une selon la conception réseau de votre ONTAP. Par exemple :
 net int service-policy create -policy only_data_fpolicy -vserver <svm> \
*Remarque :* Sur ONTAP antérieur à 9.8, data-fpolicy-client n’est pas requis. La LIF doit avoir le rôle data, être opérationnelle et prendre en charge NFS et/ou CIFS.

Utilisez une trace de paquets ONTAP

N'utilisez une trace de paquets qu'après avoir effectué le test de connexion et si les vérifications de routage et de pare-feu n'expliquent pas un échec de callback.

  1. Lancez une analyse de paquets sur ONTAP pour la LIF de données concernée et l'adresse IP de l'agent.

  2. Tentez un test de connexion ou redémarrez le collecteur.

  3. Attendez la panne, puis arrêtez la trace.

  4. Récupérez la trace à partir de https://<cluster-management-ip>/spi/<cluster-name>/etc/log/packet_traces/.

  5. Recherchez un SYN envoyé par ONTAP au port de rappel de l’Agent. L’absence de SYN indique un problème de chemin ou de stratégie côté ONTAP. Un SYN sans établissement de liaison complet indique un problème de pare-feu ou de routage entre ONTAP et l’Agent.

Remarque : Les traces de paquets peuvent contenir des informations réseau. Traitez-les conformément à vos exigences en matière de traitement des données.

Diagnostiquer les collecteurs SVM dupliqués

Deux collecteurs ne peuvent pas surveiller la même SVM, même s'ils appartiennent à des environnements Workload Security différents. Le collecteur le plus récent réécrit la destination FPolicy et déconnecte le collecteur précédent.

  1. Recherchez chaque environnement Workload Security pouvant accéder au cluster.

  2. Identifiez les collecteurs qui utilisent le même nom de SVM ou le même point de terminaison de gestion.

  3. Conservez un collecteur et supprimez les doublons.

  4. Redémarrez le collecteur conservé et confirmez que son canal FPolicy reste connecté.

Nettoyez les objets FPolicy inutilisés confirmés

Remarque : Ne supprimez pas les objets cloudsecure_ d’un collecteur actif. Le collecteur est propriétaire de ces objets et les met à jour.

Répertoriez la configuration FPolicy et identifiez les objets confirmés comme inutilisés :

fpolicy show

Pour une politique inutilisée, supprimez ses objets dans l'ordre de dépendance :

fpolicy disable -vserver <svm> -policy-name <policy-name>
fpolicy policy scope delete -vserver <svm> -policy-name <policy-name>
fpolicy policy delete -vserver <svm> -policy-name <policy-name>
fpolicy policy event delete -vserver <svm> -event-name <event-name>
fpolicy policy external-engine delete -vserver <svm> -engine-name <engine-name>

Redémarrez le collecteur Workload Security après que les emplacements de séquence ou les objets en conflit ont été effacés.

Diagnostiquer les erreurs de cycle de vie de l'agent et du collecteur

Erreur Vérifications avancées

AGENT004

Consultez le fichier dsc.log pour détecter un arrêt immédiat du processus, un échec d'autorisation ou une configuration invalide.

AGENT008

Saisissez à nouveau le mot de passe du collecteur ; vérifiez le processeur et la mémoire de l’agent ainsi que le taux d’événements ; consultez dsc.log pour identifier la défaillance sous-jacente du collecteur.

AGENT005 / 006 / 007 / 010

Réessayez dans quelques minutes. Si l'action échoue toujours, redémarrez cloudsecure-agent.service et notez l'action exacte ainsi que la raison.

AGENT009

Vérifiez que le collecteur existe toujours dans l'Agent et l'environnement sélectionnés et qu'une suppression ou une migration simultanée ne l'a pas supprimé.

Agent NOT_CONNECTED

Vérifiez systemctl et journalctl, la sortie SaaS sur TCP 443, la configuration du proxy, l’inspection SSL et le compte cssys.

Utilisez l'outil de vérification du taux d'événements pour dimensionner l'agent. Ne vous fiez pas uniquement au nombre de collecteurs ; le volume d'événements et les fonctionnalités activées influent sur la charge.

Enquêter sur l'absence d'activité après les vérifications de base

  1. Exécutez la commande event log show -source fpolicy et conservez toute erreur.

  2. Exécutez la commande fpolicy show et vérifiez qu'une politique cloudsecure_ est activée.

  3. Vérifiez que le protocole générant les opérations client est activé dans le collecteur et autorisé sur la SVM.

  4. Confirmez que le partage ou le volume n'est pas exclu.

  5. Vérifiez que le collecteur n'était pas en pause lorsque l'opération a eu lieu.

  6. Corrélez l'horodatage de l'opération client avec dsc.log et les événements FPolicy ONTAP.

Enquêter sur la résolution d'identité

Le test de connexion n'est pas disponible pour les collecteurs d'annuaires utilisateur. Utilisez les outils natifs de l'annuaire et le journal du collecteur.

Annuaire Ports par défaut Attributs attendus

Active Directory

389 LDAP / 636 LDAPS

Nom d'affichage : nom

ID: objectsid

Nom d'utilisateur : sAMAccountName

LDAP

389 LDAP / 636 LDAPS

Nom d'affichage : nom

ID : uidnumber

Nom d'utilisateur : uid

Vérifiez le nom du serveur, le port, le DN de liaison, le mot de passe, la forêt ou la base de recherche, ainsi que les droits d'accès en lecture. Redémarrez le collecteur d'annuaire après une correction pour demander une nouvelle synchronisation.

Contrôles de vérification multi-administrateurs

La vérification multi-administrateur peut bloquer les commandes ONTAP utilisées pour les instantanés et le blocage des utilisateurs. Examinez les règles existantes avant de les modifier. Les exclusions de Workload Security documentées sont :

multi-admin-verify rule modify -operation "volume snapshot create" -query "-snapshot !*cloudsecure_*" + multi-admin-verify rule modify -operation "volume snapshot delete" -query "-snapshot !*cloudsecure\_*" + multi-admin-verify rule delete -operation set

Remarque : La suppression de la règle de configuration modifie la protection Multi-Admin Verify pour cette opération. Examinez la modification avec votre administrateur de sécurité ONTAP.

Contactez l’assistance NetApp

Contactez le support si une erreur persiste après les vérifications ordonnées, ONTAP signale une panne de nœud ou si la capacité reste incorrecte après l’actualisation des données du collecteur.

Inclure

  • Le message complet de Status > More detail, ainsi que l'heure de l'échec.

  • Résultats du test de connexion, y compris les vérifications ignorées.

  • Versions des agents et des collecteurs et leur état actuel.

  • Version ONTAP, nom du cluster et du SVM, mode de connexion et modifications récentes de la topologie.

  • cloudsecure-agent-symptoms.zip et le dsc.log correspondant.

  • Résultat des commandes fpolicy show, fpolicy show-engine et event log show -source fpolicy.

  • Trace de paquets lorsqu'un chemin de rappel reste inexpliqué.

  • Pour les performances : la chronologie de la latence et des IOPS, ainsi que la chronologie du taux d'événements.

  • Pour la capacité : utilisation avant et après l’abonnement et capacité brute signalée par chaque collecteur.

Utilisez Aide > Support dans Data Infrastructure Insights pour ouvrir un dossier.