Skip to main content
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

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.
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 :
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.