L'action apporte une visibilité logicielle totale sur ces volumes rattachés à la volée, éliminant ainsi le besoin pour les ingénieurs d'ouvrir des accès terminaux complexes sur le système d'exploitation sous-jacent. Ils interrogent directement le moteur d'exécution en utilisant des requêtes standardisées. Les volumes de retours peuvent ensuite être ingérés et transformés en un flux continu de données de télémétrie formaté en temps réel, alimentant directement les tableaux de bord stratégiques de la direction des systèmes d'information.
Exemple de Code Additionnel
<pre>/* CASL Script : SUPERVISION DE L'UTILISATION DU CAS_DISK_CACHE PAR NOEUD */
/* (c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
/* Modifié pour utiliser l'action native getCacheInfo et gérer l'élévation de privilèges */
proc cas;
/* 0. Élévation des privilèges (indispensable dans Viya 4 pour lire ces métriques système) */
accessControl.assumeRole / adminRole="superuser";
/* 1. Appel de l'action native pour interroger l'état du cache */
builtins.getCacheInfo result=ns status=rc;
/* 2. Contrôle de bonne exécution et vérification de la table attendue */
if rc.statusCode == 0 and exists(ns, "diskCacheInfo") then do;
print "-------------------------------------------------------------------";
print " État matériel des pods CAS - Focus Volumes CAS_DISK_CACHE";
print "-------------------------------------------------------------------";
/* 3. Extraction et affichage des métriques de stockage */
/* L'action retourne les colonnes : node, path, FS_size, FS_free, FS_usage */
cacheMetrics = ns.diskCacheInfo[, {"node", "path", "FS_size", "FS_free", "FS_usage"}];
print cacheMetrics;
/* Optionnel : Alerte basique dans les logs SAS si l'utilisation dépasse un seuil critique */
do row over ns.diskCacheInfo;
if (row.FS_size > 0) then do;
/* Calcul du taux d'utilisation à partir de l'espace total et de l'espace libre */
taux_utilisation = ((row.FS_size - row.FS_free) / row.FS_size) * 100;
if taux_utilisation > 80 then
print "ATTENTION : Le noeud " || row.node || " a une charge de cache critique (" || (String)taux_utilisation || "%).";
end;
end;
end;
else do;
print "ERREUR : Impossible de récupérer la télémétrie. Vérifiez que votre session dispose bien des droits d'administrateur (superuser).";
end;
quit;</pre>
1
<pre>/* CASL Script : SUPERVISION DE L'UTILISATION DU CAS_DISK_CACHE PAR NOEUD */
2
/* (c) Nicolas Housset 2026 - Code SAS pour VIYA 4 - testé et validé en version 2024.09 */
3
/* Modifié pour utiliser l'action native getCacheInfo et gérer l'élévation de privilèges */
4
PROC CAS;
5
/* 0. Élévation des privilèges (indispensable dans Viya 4 pour lire ces métriques système) */
6
ACCESSCONTROL.assumeRole / adminRole="superuser";
7
/* 1. Appel de l'action native pour interroger l'état du cache */
8
BUILTINS.getCacheInfo RESULT=ns STATUS=rc;
9
/* 2. Contrôle de bonne exécution et vérification de la table attendue */
10
IF rc.statusCode == 0 and exists(ns, "diskCacheInfo") THENDO;
Découvrez cet exemple pour l'action CAS getCacheInfo : il interroge les métadonnées de stockage pour auditer l'empreinte disque et l'allocation des fichiers temporaires sur vos nœuds de calcul.
Cet exemple pour l'action CAS getCacheInfo désactive le formatage pour extraire des métriques brutes en octets. Crucial pour automatiser l'alerting de saturation sans erreur d'arrondi machine.
Conseil de l'Expert
En tant qu'architecte sur SAS Viya 4, mon conseil fondamental est d'adosser systématiquement votre CAS_DISK_CACHE à du stockage éphémère local à ultra-haute performance (NVMe) fourni par les nœuds de travail Kubernetes (comme les instances Lsv3 sur Azure ou i4i sur AWS), et de fuir le stockage réseau (NAS/NFS) pour ce besoin précis.
Puisque les pods CAS sont par nature volatils dans un cluster K8s, s'appuyer sur des commandes terminales (kubectl exec ou SSH) pour auditer l'espace disque est une anti-pattern. L'approche Cloud-native consiste à interroger directement l'API CAS via CASL. Cela permet non seulement d'obtenir l'état de saturation des volumes à la volée, mais aussi de l'automatiser pour l'exposer à vos outils de monitoring de l'entreprise (via l'API REST vers Prometheus/Grafana) avant que l'éviction d'un pod par Kubernetes (pour cause de Disk Pressure) ne compromette vos traitements analytiques.
Cette réponse vous a-t-elle aidé ?
Vos votes aident à améliorer notre base de connaissances.