Trois vues, une même période
La nouvelle page Audit et état est offerte dans le portail client. La vue d’ensemble réunit l’état actuel des composants, un résumé des exécutions et les changements récents de l’espace de travail. Les garanties d’exécution présentent les enregistrements derrière les nombres de tâches et de microVM. Le journal d’audit porte sur l’activité de l’espace de travail : qui a agi, ce qui s’est passé, la ressource concernée et le moment de l’action.
Choisissez les dernières 24 heures, 7, 30 ou 60 jours, ou une période personnalisée. La même période s’applique aux trois vues. L’onglet et la période restent dans l’URL pour retrouver la même vue. Les dates personnalisées sont limitées par la conservation de l’activité pendant 180 jours. Les dates indisponibles indiquent la raison. Les heures affichées suivent votre préférence de fuseau horaire.
Voir les exceptions plutôt qu’une affirmation générale
Un résumé favorable ne devrait pas masquer un arrêt forcé ou une destruction non confirmée. Les garanties d’exécution distinguent maintenant les destructions normales, les arrêts forcés, les enregistrements en attente de destruction et les baux encore détenus par un agent hôte. Chaque exception a son propre nombre. Les arrêts forcés affichent les codes de motif enregistrés. Le résumé ne présente que les affirmations appuyées par les nombres de la période choisie.
Le diagramme en anneau fonctionne avec un pointeur ou un clavier. Choisissez un résultat pour filtrer le tableau des preuves. Retirez le filtre pour retrouver la liste complète. Les nombres décrivent toujours toute la période, et non seulement la page de preuves affichée. Développez une ligne pour examiner la génération du bail, ses heures d’émission et de fin, son état, le motif de fin enregistré et les preuves d’exécution GitHub disponibles.
Un exemple de vérification
Supposons qu’une tâche ne se soit pas terminée comme prévu. Ouvrez les garanties d’exécution, choisissez la période autour de l’exécution et sélectionnez les arrêts forcés. Développez la ligne correspondante et comparez le motif enregistré avec l’exécution du flux de travail dans GitHub. Ouvrez ensuite le journal d’audit avec la même période pour examiner les changements pertinents de l’espace de travail. Les preuves opérationnelles et l’activité administrative restent distinctes, tout en étant consultables dans le même contexte.
Développez une entrée d’audit pour examiner l’acteur, l’action, la cible, l’heure et les renseignements d’origine disponibles. Le texte ressemblant à des identifiants est masqué dans les descriptions, les cibles et les agents utilisateurs, avant l’affichage, ainsi que dans les lectures d’activité et l’export CSV. Le masquage est une précaution. Il ne faut toujours pas inscrire de secrets dans les noms, les journaux ou les demandes de soutien.
Savoir quand les données ont été actualisées
L’actualisation automatique dépend de la période. 30 et 60 jours : toutes les 60 secondes. 7 jours : toutes les 15 secondes. 24 heures : toutes les 3 secondes lorsque le nombre de tâches en cours dépasse zéro, sinon toutes les 15 secondes. Lorsque l’actualisation automatique est activée, le retour dans l’onglet actualise aussi la page. L’indicateur affiche l’âge des données. Pause arrête l’actualisation automatique. Reprendre actualise la vue puis réactive les mises à jour. Les onglets masqués ne continuent pas à envoyer des demandes d’actualisation. Une période personnalisée représente une fenêtre historique fixe : les mises à jour automatiques sont désactivées et l’actualisation manuelle reste offerte.
Il s’agit d’une actualisation périodique, et non d’un flux d’événements des tâches. Un nombre d’exécutions en cours ou un bail actif ne confirme pas la réussite d’une tâche. Tenez compte de la période, de la dernière actualisation et des preuves sous-jacentes pour interpréter une exception.
Ce que ces enregistrements ne prouvent pas
La page indique les limites des données disponibles. La prise en charge par l’hôte est enregistrée, mais pas l’heure de démarrage de la microVM. Certains baux révoqués par Runzivo n’ont aucun motif enregistré. Les entrées d’audit ne présentent pas les valeurs avant et après. L’état actuel des composants est affiché sans pourcentage de disponibilité ni historique d’incidents inventés, car l’historique des composants n’est pas enregistré ici.
Cette refonte rend les preuves existantes plus faciles à consulter. Elle ne constitue ni une nouvelle entente de niveau de service, ni une garantie que toutes les destructions ont été normales, ni une certification indépendante.