Monitorare ed eseguire il debug dei carichi di lavoro

Autore del carico di lavoro Operatore del carico di lavoro

Quando crei, testi ed esegui un carico di lavoro, può essere utile monitorarne l'avanzamento per eseguire il debug dei problemi. Sono disponibili i seguenti strumenti per il monitoraggio e il debug:

• Cloud Logging: come primo passo per la risoluzione dei problemi di un carico di lavoro di Confidential Space, puoi reindirizzare STDOUT e STDERR a Cloud Logging, quindi controllarli per verificare i codici di restituzione del carico di lavoro e vedere dove si è verificato un errore.

• L'immagine di debug di Confidential Space: L' immagine di debug di Confidential Space mantiene operativa la VM Confidential che esegue il carico di lavoro dopo il completamento del carico di lavoro ed esegue un server SSH. In questo modo puoi accedere da remoto alla VM per diagnosticare i problemi. È utile utilizzare l'immagine di debug finché non sei sicuro che il codice si comporti come previsto. Quando è il momento di iniziare a lavorare con i dati di produzione sensibili, passa all'immagine di produzione di Confidential Space.

• Monitoraggio dell'utilizzo della memoria: puoi visualizzare l'utilizzo della memoria del carico di lavoro in Cloud Logging o in Esplora metriche. L' autore del carico di lavoro deve consentirlo, e l' operatore del carico di lavoro deve abilitarlo prima che la memoria utilizzata venga monitorata.

• Shell interattiva: dopo aver utilizzato SSH per connetterti alla VM Confidential del carico di lavoro, puoi utilizzare il sudo ctr task exec -t --exec-id shell tee-container bash comando per accedere a una shell interattiva all'interno del container per diagnosticare i problemi del carico di lavoro.

Logging

Come qualsiasi programma della riga di comando, STDOUT e STDERR del carico di lavoro possono essere visualizzati nella console. Possono anche essere reindirizzati a Cloud Logging dall' operatore del carico di lavoro impostando la tee-container-log-redirect chiave di metadati su true o cloud_logging nella VM Confidential Space e assicurandosi che il account di servizio che esegue il carico di lavoro abbia il ruolo logging.logWriter.

L'autore del carico di lavoro può impedire il reindirizzamento con il log_redirect criterio di avvio.

Per ridurre il profilo di rischio, registra la quantità minima di informazioni e non registrare informazioni sensibili.

Visualizzare i log di Confidential Space

Se al account di servizio collegato alla VM Confidential Space è stato concesso il ruolo logging.logWriter e hai reindirizzato i log a Cloud Logging, puoi risolvere i problemi visualizzando i log della VM:

1. Vai a Logging nel progetto dell'operatore del carico di lavoro nella Google Cloud console.

   Vai a Logging

2. Accanto alla scheda Query, fai clic sull'intervallo di tempo per impostare il periodo di logging che vuoi visualizzare.

3. Filtra i log in base ai seguenti campi di log, se disponibili:

   • Tipo di risorsa: istanza VM

   • ID istanza: l'ID istanza della VM Confidential

   • Nome log: confidential-space-launcher

4. Leggi il messaggio di errore per scoprire qual è il problema. Una risorsa potrebbe non essere stata configurata correttamente, le condizioni degli attributi nei provider WIP dei collaboratori dei dati potrebbero non corrispondere alle attestazioni effettuate dal carico di lavoro di Confidential Space oppure il carico di lavoro stesso potrebbe aver generato un errore.

Codici di restituzione

I codici di restituzione vengono visualizzati nella console durante l'esecuzione del launcher e del carico di lavoro e possono essere reindirizzati a Cloud Logging.

I codici di restituzione sono descritti nella tabella seguente:

Codice	Definizione	Comportamento di arresto della VM
0	Il carico di lavoro è stato completato correttamente quando si utilizza l'immagine di produzione.	La VM si arresta al termine del carico di lavoro.
1	Il carico di lavoro o il launcher ha restituito un errore quando si utilizza l'immagine di produzione.	La VM si arresta dopo aver restituito un errore.
3	Il launcher è stato riavviato dopo un errore a causa del relativo tee-restart-policy.	La VM viene riavviata.
4	Il carico di lavoro o il launcher ha terminato l'esecuzione quando si utilizza l'immagine di debug e la VM è ora inattiva.	La VM non si arresta al termine del carico di lavoro o se restituisce un errore. In questo modo puoi eseguire il debug del carico di lavoro tramite SSH.

Se un carico di lavoro non riesce, un operatore del carico di lavoro riceve solo il messaggio workload finished with a non-zero return code, senza ulteriori informazioni. Per un' immagine di produzione, il launcher può essere impostato per il riavvio in caso di errore con tee-restart-policy=OnFailure.