Compute Server Status
Le module **Compute Server Status** fournit un tableau de bord d'administration et de surveillance interactif en temps réel pour le sous-système de calcul de SAS Viya 4. Alimenté par une interface AJAX entièrement asynchrone, il communique directement avec OpenShift/Kubernetes via la CLI `oc` pour suivre les cycles de vie des sessions, la consommation de ressources en direct et l'exécution de tâches par lots, remplaçant les scripts en ligne de commande statiques par une console opérationnelle intuitive et unifiée.
Aperçu et architecture
Dans SAS Viya 4, l'architecture de calcul s'appuie sur le SAS Launcher Service pour lancer dynamiquement des pods Kubernetes éphémères pour les sessions utilisateur et les tâches planifiées. Ce module surveille l'ensemble du cycle de vie de ces charges de travail en interrogeant le cluster en temps réel et en les catégorisant dans trois vues opérationnelles dédiées :
1. Service de lancement (Orchestrateur) : Suit l'état de santé et la disponibilité des pods d'orchestration (app=sas-launcher) responsables de la répartition des nouvelles charges de travail de calcul.
2. Sessions de calcul actives : Surveille les sessions utilisateur interactives générées par SAS Studio, SAS Model Studio, les interfaces Jupyter ou les appels d'API REST (launcher.sas.com/job-type=compute-server).
3. Tâches par lots en cours d'exécution : Affiche les tâches en arrière-plan et les exécutions de programmes planifiées gérées par le SAS Workload Orchestrator (launcher.sas.com/job-type=sas-programming-environment).
---
Sous-systèmes surveillés et tables de données
1. Service de lancement (Orchestrateur)
La table du service de lancement suit les contrôleurs d'orchestration qui gèrent le provisionnement des pods :
- Nom du pod et IP du pod : Affiche l'identifiant unique du pod et l'adresse IP interne attribuée au cluster.
- Statut et Phase : Badges à code couleur indiquant l'état opérationnel (
Running,Pending,Failed). - Emplacement du nœud : Identifie le nœud de calcul du cluster spécifique hébergeant chaque instance de lancement.
- Redémarrages de conteneur : Surveille le nombre de redémarrages avec des badges rouges très visibles si des redémarrages se produisent, indiquant une instabilité potentielle de l'infrastructure ou de la configuration.
- Âge : Calcule la durée de disponibilité écoulée depuis l'horodatage de création initial.
2. Sessions de calcul actives
La table des sessions de calcul actives offre une visibilité granulaire sur toutes les sessions utilisateur interactives :
- Nom d'utilisateur authentifié : Extrait intelligemment l'identité de l'utilisateur des étiquettes Kubernetes (
launcher.sas.com/username), mettant en évidence à qui appartient la session. - Consommation en direct de CPU et de RAM : Interroge les principales métriques du cluster (
oc adm top pods) en temps réel, affichant l'utilisation exacte du processeur (millicores) et de la mémoire vive (par exemple, Mi/Gi) par session de calcul. - Emplacement du nœud : Affiche le nœud de calcul qui exécute la charge de travail de la session, facilitant l'équilibrage du cluster et le dépannage de la capacité du nœud.
- Âge de la session : Suit la durée depuis le démarrage de la session (
m,h,d).
3. Tâches par lots en cours d'exécution
La table des tâches par lots en cours d'exécution surveille les exécutions de l'environnement de programmation SAS non interactif :
- Suit les tâches en arrière-plan soumises via la CLI SAS Batch, le SAS Workload Orchestrator (SWO) ou des pipelines automatisés.
- Affiche les noms des pods, l'état d'exécution, les comptes d'utilisateurs associés, les attributions de nœuds cibles, l'historique de redémarrage et la durée d'exécution.
---
Indicateurs de santé et alertes visuelles
- Badges de phase :
- Running / Succeeded : Rendu en Vert (bg-success).
- Pending : Rendu en Jaune (bg-warning) pour mettre en évidence les goulots d'étranglement de planification ou les ressources de calcul de cluster insuffisantes.
- Failed / Error : Rendu en Rouge (bg-danger).
- Mise en évidence des échecs : Tout pod dans un état
FailedouError(comme les plantages causés par des événements de mémoire insuffisanteOOMKilled) est automatiquement mis en évidence avec un fond de ligne rouge bien visible (table-danger) pour alerter immédiatement l'opérateur. - Avertissements de redémarrage : Les compteurs de redémarrage non nuls sont signalés en rouge gras pour repérer rapidement les conteneurs en boucle de plantage (crash-looping).
---
Actions de pod interactives et diagnostics
Chaque pod à travers les trois tables inclut une barre d'outils d'action en ligne offrant des capacités instantanées de diagnostic et de gestion :
- Journaux interactifs (
oc logs) :
- Récupère les 1 000 dernières lignes de journal du conteneur.
- Analyseur de journal JSON structuré : Analyse automatiquement la sortie de journalisation JSON de SAS Viya et la divise en trois onglets intuitifs :
- Infos : Messages opérationnels normaux et exécutions de code utilisateur. - Erreurs : Journaux d'avertissement et d'erreur filtrés avec un badge de nombre d'erreurs (mlogErrorCount). Si des erreurs sont détectées, la modale sélectionne et met automatiquement en évidence l'onglet Erreurs.
- Journaux bruts : Flux de journaux non filtré pour un dépannage avancé.
- Exportation de journaux : Télécharger les journaux complets du pod sous forme de fichier texte (<nom_du_pod>_logs.txt) directement sur votre poste de travail.
- Décrire (
oc describe pod) :
- Affiche les spécifications détaillées des pods, les transitions d'état du conteneur, les montages de volumes, les limites de ressources et les codes de sortie de fin (par exemple, Code de sortie 137 pour OOMKilled).
- Événements du cluster (
oc get events) :
- Récupère les événements de cycle de vie Kubernetes en temps réel spécifiquement ciblés sur le pod sélectionné (involvedObject.name), mettant en évidence les échecs de planification, les retards d'extraction d'image ou les erreurs de montage de volume.
- Terminer la session / Supprimer le pod (
oc delete pod) :
- Permet aux administrateurs de terminer en toute sécurité les sessions de calcul emballées, bloquées ou plantées directement depuis l'interface.
- Protégé par une modale de confirmation pour éviter les fins accidentelles, suivi d'une actualisation automatique de la table.
---
Journal d'exécution et contrôles administratifs
- Onglet Journal d'exécution : Offre une visibilité complète sur les opérations backend en affichant la commande exacte exécutée (
/var/www/cmd/07_statut_compute.sh) avec la sortie brute complète du terminal dans une console à espacement fixe sombre. Comprend un bouton Copier en un clic pour faciliter la création de rapports. - Mode de confidentialité et d'anonymisation : Lorsque le
anonymous_modeest activé dansglobal_config.json, le tableau de bord remplace dynamiquement les vrais noms d'utilisateur (User_1), les noms de pods (Pod_1) et les noms d'hôtes de nœuds (Node_1), le rendant sûr pour les captures d'écran, les audits externes et les présentations de fournisseurs. - Actualisation asynchrone : Un bouton Actualiser dédié déclenche la collecte de données en arrière-plan sans recharger la page, accompagné d'une icône de progression (spinner) et de protections robustes contre les délais d'attente (timeouts).