Skip to main content
Ouvrez Administration → Clés et vérifiez que la clé machine est active et dispose de events:add. Ouvrez ensuite Observer → Événements, élargissez la plage temporelle et effacez les filtres d’environnement et d’agent. Si des événements existent, recherchez l’ID de session puis consultez Observer → Sessions pour le regroupement. Si aucun événement n’existe, diagnostiquez le démon Failproof depuis le CLI.Le flux d'événements en direct avec ses filtres principaux visibles et des événements d'agent récents qui arrivent.
Effacez les filtres dans Observer → Événements et recherchez l’ID de session SDK exact. Si rien n’apparaît, inspectez le spool SDK et le démon Failproof sur la machine source.
Ouvrez Admin → application, sélectionnez la machine et comparez ses versions assignée, signalée et précédente. Vérifiez que le périmètre de déploiement inclut la machine et que sa clé dispose de policies:pull. L’ingestion peut fonctionner même lorsque la livraison des politiques échoue.
Ouvrez Admin → application et inspectez la dernière heure de présence de la machine ainsi que sa version signalée. Si la machine est obsolète, traitez cela comme un problème de démon local. N’affaiblissez pas la politique déployée uniquement pour contourner un démon indisponible.
Pour une politique créée dans Cloud, ouvrez Admin → éditeur de politiques, sélectionnez le brouillon et examinez les erreurs de validation avant de publier. Pour une politique locale, utilisez le CLI pour la valider, puis ouvrez Observer → politique après une action de test pour confirmer que les décisions arrivent.
Ouvrez Analyser → audits, sélectionnez l’exécution et vérifiez si l’analyse par modèle a été effectuée. Comparez ensuite son périmètre et sa fenêtre avec Observer → sessions et ouvrez des traces représentatives de cette population.Un résultat nul n’est significatif que lorsque l’analyse s’est déroulée avec succès. Si l’analyse a été ignorée ou a échoué, l’exécution ne produit aucun résultat et conserve la fenêtre non analysée ouverte pour une prochaine exécution réussie. Si l’analyse par modèle est désactivée, l’audit ne produit également aucun résultat, car la vérification déterministe des credentials et du PII enregistre des statistiques mais ne lève plus de résultats.Le formulaire d'audit où l'environnement, l'agent, la cadence et la fenêtre de balayage définissent la population de sessions.
Ouvrez une session terminée et vérifiez si une évaluation manuelle réussit. Le Cloud hébergé ne dispose actuellement d’aucun contrôle du point de terminaison de l’évaluateur dans le tableau de bord ; l’opérateur du serveur doit le configurer.
Utilisez le sélecteur d’organisation et confirmez le slug et les permissions attendus avant de comparer les résultats avec le CLI.
Ouvrez Observer → politique, conservez la décision et la session liée, et identifiez la condition de faux positif. Ouvrez ensuite Admin → application et faites revenir les machines concernées à la version précédente. Créez une version plus ciblée dans l’Éditeur de politiques, testez-la sur un périmètre restreint et élargissez uniquement après que le travail valide réussit.
Lorsque vous contactez le support, incluez la version du CLI, le harnais, l’environnement, l’ID de session ou de déploiement pertinent, ainsi que le résultat de failproofai config --status avec les secrets supprimés.