Santé de la plateforme

Santé de la plateforme est un tableau de bord en direct de votre déploiement Scrydon. Ouvrez-le depuis Paramètres → Plateforme → Santé. Il exécute une batterie de vérifications en lecture seule et montre, d'un coup d'œil, si tout fonctionne.

Ce que vous voyez

• Bandeau global — un verdict unique : Tous les systèmes opérationnels, Dégradé ou Panne.
• Tableau des vérifications — une ligne par vérification individuelle, que vous pouvez rechercher (tapez pour filtrer) et trier. Chaque ligne montre ce qui est vérifié, un statut, et une colonne Contexte avec le détail (le texte de l'erreur, l'adresse sondée et le temps de réponse). La colonne Type regroupe les vérifications :
  • Reachability — chaque service Scrydon répond-il ? (OK · Dégradé — a répondu mais quelque chose cloche · Injoignable — aucune réponse · Ignoré — non configuré dans cet environnement).
  • Dependency — le magasin de données de chaque service (par exemple sa base de données) fonctionne-t-il ?
  • M2M — les services internes de Scrydon peuvent-ils s'authentifier entre eux ? (OK est sain ; Refusé signifie qu'une permission interne est mal configurée.)
  • Migration — la base de données de chaque service a-t-elle toutes les mises à jour attendues ? Migrations en attente signifie qu'une étape de mise à niveau n'a pas été exécutée — la ligne liste exactement quelles mises à jour de base de données manquent, pour que votre équipe d'exploitation sache quoi appliquer. Chaque ligne peut aussi être dépliée pour montrer quelles migrations ont déjà été exécutées. (Une cause fréquente de problèmes après une mise à niveau est une étape de migration oubliée ; cette vérification la rend visible.)
  • Isolation — ce que le plan d'exécution (le composant qui exécute les agents et les étapes de workflow non fiables dans des pods isolés à usage unique) a vérifié pouvoir fournir sur ce cluster. La première ligne confirme que le plan répond avec son attestation de capacités ; les lignes suivantes montrent chaque niveau d'isolation (microVM, médié, durci) comme Disponible ou Indisponible, plus les faits bruts derrière la décision — le nœud expose-t-il le périphérique hyperviseur /dev/kvm, et une RuntimeClass Kata existe-t-elle et sélectionne-t-elle un nœud Ready. Indisponible est une déclaration de capacité honnête, pas une erreur : un cluster sans pool de nœuds Kata exécute légitimement le seul niveau durci. Seul un plan d'exécution activé mais injoignable dégrade le verdict global, car l'exécution des agents échoue tant que cela dure. Voir Isolation des étapes non fiables pour la façon dont le niveau est choisi par étape.

Relancer les vérifications

La page vérifie tout à son ouverture. Appuyez sur Relancer les vérifications à tout moment pour sonder de nouveau — utile pendant la mise en route d'un déploiement ou après un changement de configuration.

Quand quelque chose est rouge

Un résultat rouge oriente votre équipe d'exploitation vers le service ou la dépendance défaillant. Partagez ce que vous voyez (quel service, quel statut) avec votre administrateur ou le support Scrydon — combiné à l'option Télécharger le paquet de débogage de la page des paramètres d'organisation, cela donne un point de départ précis pour le diagnostic.