Santé

La page Santé est un tableau de bord en direct de votre déploiement Scrydon. Ouvrez-la depuis Paramètres → Plateforme → Santé. Elle exécute une batterie de vérifications en lecture seule, affiche l'état de l'infrastructure et propose des tests explicites des capacités d'extensions configurées.

Ce que vous voyez

• Bandeau d'infrastructure — un verdict pour l'infrastructure : Vérifications d'infrastructure réussies, 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 pour les workloads non concernés : un cluster sans pool Kata peut exposer le niveau durci plus faible à un workload hors Agent qualifié séparément. Lorsque l’isolation de l’Agent standard est requise, l’Agent y est indisponible et ne rétrograde jamais automatiquement vers le niveau durci ou une exécution sur l’hôte. Un administrateur d’organisation peut explicitement sélectionner l’exécution auditée dans le processus sous Paramètres → Plateforme → Calcul ; ce choix n’est pas un niveau d’isolation et n’est pas couvert par l’attestation. Un plan activé mais injoignable dégrade le verdict global, car l’exécution Agent avec isolation requise échoue de manière fermée 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 l'infrastructure à 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.

Vérifier les extensions configurées

Ouvrez Extensions pour vérifier ce que votre organisation a configuré. L'onglet se lit comme l'onglet Infrastructure : un bandeau récapitulatif, puis une ligne par vérification avec son Type, son Statut et son Contexte. Relancer les vérifications dans l'en-tête de la page relance l'onglet que vous consultez.

Les vérifications gratuites s'exécutent d'elles-mêmes

L'ouverture de l'onglet n'exécute que des vérifications gratuites, affichées avec le type Configuration :

• Connexions, Configuration des capacités et Politiques par défaut inspectent la configuration stockée et le catalogue installé : format de configuration, syntaxe des URL de points de terminaison, politiques par défaut explicites, références de connexion, portée d'environnement et listes de modèles autorisés.
• Une ligne par point de terminaison HTTPS configuré effectue une nouvelle poignée de main TLS et vérifie le nom d'hôte, la confiance et la validité du certificat. Les points de terminaison publics utilisent l'épinglage DNS ; les destinations privées, le HTTP simple, les URL contenant des identifiants et les points de terminaison manquants sont signalés comme non vérifiés. La poignée de main dispose d'un délai de cinq secondes.

Ces vérifications n'envoient aucune requête au fournisseur, ne découvrent aucun modèle et ne lisent aucun identifiant. Une vérification gratuite Réussie ne vérifie ni les identifiants, ni la sélection automatique de modèle, ni les déploiements, ni le routage de l'envoi ; c'est le rôle d'un test en direct.

Tous les environnements d'espace de travail accessibles sont vérifiés par défaut ; utilisez le sélecteur Environnement pour restreindre ce périmètre. Une même vérification dans plusieurs environnements forme une seule ligne. Son statut est le pire de ses environnements, de sorte qu'une réussite ne masque jamais un environnement frère en échec ou non testé. Dépliez la ligne pour voir chaque constat distinct une seule fois, du plus grave au moins grave, avec les environnements concernés. La recherche porte sur les libellés, les modèles, les environnements et les erreurs du fournisseur ; Filtrer restreint par type ou par statut.

Les tests en direct coûtent de l'argent, vous les exécutez donc un par un

Un test en direct envoie une petite requête synthétique au fournisseur. Rien n'est envoyé tant que vous n'avez pas cliqué sur ce test, et il n'existe pas d'exécution groupée.

1. Estimer le coût · gratuit résout la cible, vérifie son point de terminaison TLS et chiffre la charge de travail. Cette étape peut lire des identifiants et découvrir des modèles, mais ne génère rien. Une valeur par défaut dont le modèle qualifié se résout vers une cible différente échoue ici, avant toute requête payante.
2. Le bouton affiche ensuite le prix, par exemple Exécuter le test · ≈ $0.00077, ou Exécuter le test · coût inconnu lorsque le catalogue ne contient aucun tarif correspondant. Cliquer dessus vaut consentement pour cette seule requête. Une estimation n'est pas un plafond de facturation : les minimums du fournisseur et les contrôles de gouvernance peuvent ajouter des coûts.

La couverture Essentielle, par défaut, liste un test par valeur par défaut configurée : l'opération la moins chère qui prouve que la valeur par défaut fonctionne. Tous les tests ajoute chaque connexion et chaque modèle stocké, les variantes en streaming ainsi que la génération d'images et de vidéos.

Les charges de travail sont fixes et réduites : au plus 128 jetons de sortie LLM, un court embedding, un extrait de moins de deux secondes, une phrase, une page OCR, une image de 1024 × 1024 ou quatre secondes de vidéo 720p. Les nouvelles tentatives du fournisseur sont désactivées. Les tests des valeurs par défaut suivent la sélection normale ; les tests de connexion sont épinglés à cette connexion et à ce modèle précis. Après une exécution, la ligne affiche la latence et, lorsque le fournisseur indique l'utilisation, les jetons et leur coût estimé.

Un Réussi en direct signifie que la requête s'est terminée et que sa sortie a passé la validation. Les échecs portent des motifs sûrs du fournisseur tels que endpoint_untrusted et model_not_found. Les outils, webhooks, sélecteurs, déclencheurs et médias en temps réel nécessitent des données de test propres à la ressource et ne sont pas testés en direct.

Les estimations et les tickets de test expirent au bout de 15 minutes, et une cible modifiée nécessite une nouvelle estimation. Une réussite est mémorisée pendant 15 minutes pour le même appelant, le même environnement et une configuration inchangée ; Retester l'exécute de nouveau. Les résultats sont une preuve à un instant donné, pas un historique de surveillance. Annuler arrête le chargement ou signale la requête active ; le travail déjà accepté par le fournisseur peut malgré tout se terminer et être facturé. Le paquet de débogage continue de ne contenir que les diagnostics d'infrastructure.

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é à Télécharger le paquet de débogage dans l'en-tête de cette page, cela donne un point de départ précis pour le diagnostic.