> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Santé et dépannage du stockage > Diagnostiquer les échecs de readiness, scanner, CA, autorisations, canary et lettres mortes Utilisez les réponses de santé pour le routage et le triage assaini. Utilisez les journaux protégés, les métriques, les enregistrements d'audit fournisseur et l'état de la base de données pour le diagnostic. ## Points de terminaison de santé web | Point de terminaison | Signification | Succès | Échec | | -------------------- | ---------------------------------------------------------------------- | ---------------------- | ------------------------------------------------- | | `/api/health/live` | Le processus web s'exécute ; aucune vérification externe | `200 {"status":"ok"}` | Échec processus/réseau | | `/api/health/ready` | Les profils de stockage sont joignables et le canary profond est frais | `200`, `status: ready` | `503`, `status: not_ready` et `category` assainie | Les catégories de readiness sont uniquement `configuration`, `authentication`, `tls`, `storage`, `capability` et `canary_stale`. La réponse omet intentionnellement les fournisseurs, les points de terminaison, les noms de buckets, les clés d'objets, les identifiants et les erreurs brutes. ```bash theme={null} curl --fail --silent --show-error \ 'https:///api/health/live' curl --fail --silent --show-error \ 'https:///api/health/ready' ``` N'utilisez pas la liveness pour décider que les écritures sont sûres. Ne placez pas d'identifiant dans une URL de sonde. ## Canary profond Le canary profond planifié écrit des octets aléatoires vers `ephemeral`, enregistre les métadonnées SHA-256, lit et hache les octets exacts, les copie et les vérifie, puis supprime les deux objets. La readiness signale `canary_stale` lorsqu'aucun canary réussi n'existe dans la fenêtre de fraîcheur. Pour un canary périmé : 1. confirmez que l'instrumentation web a démarré le planificateur de canary ; 2. inspectez `storage.readiness`, `storage.operation.*` et la latence fournisseur ; 3. confirmez que `ephemeral` autorise la création conditionnelle, la lecture, la copie et la suppression ; 4. vérifiez l'horloge worker/web et la saturation de la boucle d'événements ; 5. vérifiez que la politique de cycle de vie ne supprime pas les objets canary pendant la transaction ; et 6. exécutez le contrat fournisseur depuis le même réseau et le même contexte d'identité. N'allongez pas de façon permanente le seuil d'âge pour masquer les échecs. ## Triage par catégorie ### `configuration` Validez la lisibilité/le mode de `STORAGE_CONFIG_FILE` et le JSON strict ; les trois profils doivent exister. Utilisez les identifiants de fournisseur canoniques `s3`, `gcs`, `azure` ou `local`. La production ne peut pas utiliser `local`. ### `authentication` Vérifiez la liaison d'identité de charge de travail, la portée du rôle, l'audience du jeton, le chevauchement de rotation des identifiants et les refus d'audit fournisseur. Le web et le worker ont besoin d'un accès correspondant. N'affichez pas de jetons, n'exécutez pas `env` et ne copiez pas de données Secret dans un ticket. ### `tls` Vérifiez le DNS/SAN du point de terminaison, le montage de CA privée, la chaîne d'émission complète, l'expiration, la confiance du proxy et le redémarrage du pod après rotation de CA. Conservez la vérification activée ; n'utilisez jamais HTTP, `--insecure` ou `rejectUnauthorized: false`. ### `storage` Confirmez le bucket/conteneur existant, la route, le DNS, l'egress, le quota, la limitation, la capacité et les opérations objet requises. Les vérifications de santé ne créent pas de stockage manquant. ### `capability` Lorsque le WORM est requis, vérifiez le profil `requireWorm`, le versioning, la rétention/immuabilité des objets et la conservation légale. Relancez la qualification en direct après les changements de politique. ## Panne du scanner Les symptômes comprennent l'augmentation de `storage.quarantine.depth`, `storage.quarantine.oldest_age_seconds`, `storage.scanner.failure`, les tentatives d'outbox et les lettres mortes éventuelles. Vérifiez le socket/hôte `clamd`, la CA TLS, le nom de serveur, la limite de taille, le délai d'expiration, la politique réseau, la santé du moteur et l'état de mise à jour des signatures. Restaurez le scanner, puis autorisez les tentatives idempotentes normales ou utilisez la procédure de rejeu approuvée. Les objets doivent rester en quarantaine jusqu'à un verdict propre terminal ; ne les marquez jamais propres manuellement et ne contournez pas l'analyse. ## Lettres mortes de mutation Surveillez `storage.outbox.deadletter`, `storage.outbox.pending` et `storage.outbox.deadlettered`. Inspectez les enregistrements protégés `StorageMutationOutbox` par ID/statut/opération sans exporter inutilement les charges utiles ou les clés d'objets. 1. classifiez l'échec scanner, permission, rétention, TLS, objet manquant ou fournisseur ; 2. réparez la cause ; 3. confirmez que l'objet correspond toujours à son SHA-256 stocké et à sa version exacte ; 4. rejouez via l'opération de file idempotente approuvée ; et 5. confirmez l'achèvement et les preuves d'audit. Ne supprimez jamais une ligne de lettre morte pour rendre un tableau de bord vert. Les suppressions bloquées par la rétention sont des échecs de politique à résoudre, pas des objets à forcer en suppression. ## Migration et réconciliation Surveillez `storage.migration.result`, `storage.reconciliation.missing`, `storage.reconciliation.orphan_observed`, `storage.reconciliation.orphan_confirmed` et les métriques de réparation d'outbox de réconciliation. * Les objets attendus manquants sont renvoyés vers un état quarantaine/intégrité en échec. * Les orphelins sont d'abord observés et confirmés uniquement après la période de grâce. * Les tentatives de migration peuvent atteindre `DEAD_LETTER` ; conservez la source et examinez avant le rejeu. Ne supprimez pas automatiquement les orphelins confirmés. Corrélez-les avec les sessions de téléversement, les registres de migration, les versions fournisseur, la rétention et les conservations légales. ## Validation sûre Utilisez un préfixe dédié et une identité équivalente à la charge de travail : ```bash theme={null} STORAGE_TEST_PROVIDER=s3 \ STORAGE_TEST_BUCKET='' \ AWS_REGION='' \ ./scripts/storage/validate-storage.sh ``` Pour ODF/Ceph, utilisez `./scripts/storage/validate-ceph-rgw.sh` avec la version exacte et la CA privée. Assainissez les sorties avant de les joindre à un incident.