Ao criar, testar e executar uma carga de trabalho, pode ser útil monitorar o
progresso dela para depurar problemas. As seguintes ferramentas estão disponíveis para monitoramento e depuração:
A imagem de depuração do Confidential Space: a
imagem de depuração do Confidential Space
mantém a VM confidencial que executa a carga de trabalho operacional após a conclusão dela e executa um servidor SSH. Isso permite fazer login remotamente na VM para
diagnosticar problemas. É útil usar a imagem de depuração até ter certeza de que o código está funcionando corretamente. Quando for a hora de trabalhar com
dados de produção sensíveis, mude para a imagem de produção do Confidential Space.
Shell interativo: depois de usar o SSH para se conectar à VM confidencial da carga de trabalho, use o comando
sudo ctr task exec -t --exec-id shell tee-container bash para inserir
um shell interativo dentro do contêiner e diagnosticar problemas da carga de trabalho.
Logging
Como qualquer programa de linha de comando, as cargas de trabalho STDOUT e STDERR podem ser
exibidas no console. Ele também pode ser redirecionado para o Cloud Logging pelo
operador de carga de trabalho que define a
chave de metadados tee-container-log-redirect
como true ou cloud_logging na VM do Confidential Space e
garante que a conta de serviço que executa a carga de trabalho tenha a
função logging.logWriter.
Para reduzir seu perfil de risco, registre a quantidade mínima de informações e não
registre informações sensíveis.
Ver registros do Confidential Space
Se a conta de serviço anexada à sua VM do Confidential Space recebeu o
papel logging.logWriter e você redirecionou os registros para o Cloud Logging, é possível
solucionar os erros visualizando os registros da VM:
Acesse Logging no projeto do operador da carga de trabalho no
Google Cloud console.
Ao lado da guia Consulta, clique no período para definir o período de registro que você quer visualizar.
Filtre os registros pelos seguintes campos, se estiverem disponíveis:
Tipo de recurso: instância de VM
ID da instância:o ID da instância da VM confidencial
Nome do registro: confidencial-space-launcherer
Leia a mensagem de falha para saber qual é o problema. Um recurso pode
não ter sido configurado corretamente, as condições dos atributos nos provedores
de WIP dos colaboradores de dados podem não corresponder às declarações feitas pela
carga de trabalho do Confidential Space ou a própria carga de trabalho pode ter apresentado um erro.
Códigos de retorno
Os códigos de retorno são exibidos no console ao executar o
acesso rápido
e a carga de trabalho e podem ser redirecionados para o Cloud Logging.
Os códigos de retorno estão descritos na seguinte tabela:
Código
Definição
Comportamento de parada da VM
0
A carga de trabalho foi concluída com êxito
ao usar a imagem de produção.
A VM é interrompida após a conclusão da
carga de trabalho.
1
A carga de trabalho ou o acesso rápido retornou
um erro ao usar a imagem de
produção.
A VM é interrompida depois de
retornar um erro.
3
O acesso rápido foi reiniciado após uma
falha devido ao
tee-restart-policy.
A VM é reiniciada.
4
A execução da carga de trabalho ou do acesso rápido
foi concluída ao usar a
imagem de depuração e a VM está
ociosa.
A VM não para depois que a
carga de trabalho é concluída ou retorna
um erro. Isso permite depurar
a carga de trabalho por SSH.
Se uma carga de trabalho falhar, um operador de carga de trabalho receberá apenas a mensagem
workload finished with a non-zero return code, sem contexto adicional. Para uma
imagem de produção, o acesso rápido pode ser definido para reiniciar em caso de falha com
tee-restart-policy=OnFailure.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eCloud Logging can be used to troubleshoot Confidential Space workloads by redirecting \u003ccode\u003eSTDOUT\u003c/code\u003e and \u003ccode\u003eSTDERR\u003c/code\u003e and checking for workload return codes to identify failure points.\u003c/p\u003e\n"],["\u003cp\u003eThe debug Confidential Space image allows for remote SSH access to the VM after workload completion, enabling in-depth diagnosis of issues before switching to the production image.\u003c/p\u003e\n"],["\u003cp\u003eMemory usage monitoring can be enabled for workloads, providing visibility through Cloud Logging or Metrics Explorer, but it requires enablement by both the workload author and operator.\u003c/p\u003e\n"],["\u003cp\u003eWorkload operators can use an interactive shell within the container of a Confidential VM to diagnose issues after connecting via SSH.\u003c/p\u003e\n"],["\u003cp\u003eReturn codes from the workload or launcher, which are displayed in the console and can be redirected to cloud logging, provide crucial information about the success or failure of the workload.\u003c/p\u003e\n"]]],[],null,["# Monitor and debug workloads\n\n[Workload author](/confidential-computing/confidential-space/docs/confidential-space-overview#roles) [Workload operator](/confidential-computing/confidential-space/docs/confidential-space-overview#roles)\n\n*** ** * ** ***\n\nWhen building, testing, and running a workload, it can be useful to monitor its\nprogress to debug issues. The following tools are available to use for\nmonitoring and debugging:\n\n- **Cloud Logging** : As the first step in troubleshooting a Confidential Space\n workload, you can\n [redirect `STDOUT` and `STDERR` to Cloud Logging](/confidential-computing/confidential-space/docs/deploy-workloads#tee-container-log-redirect),\n and then\n [check it for workload return codes](#logging) to see where a failure\n occurred.\n\n- **The debug Confidential Space image** : The\n [debug Confidential Space image](/confidential-computing/confidential-space/docs/confidential-space-images#types_of_images)\n keeps the Confidential VM running the workload operational after the workload has\n completed, and runs an SSH server. This lets you remotely log into the VM to\n diagnose issues. It's useful to use the debug image until you're confident\n that your code is behaving as it should. When it's time to start working on\n sensitive production data, switch to the production Confidential Space\n image.\n\n- **Memory usage monitoring** : You can view the memory usage of the workload in\n [Cloud Logging](/logging) or\n [Metrics Explorer](/monitoring/charts/metrics-explorer).\n The\n [workload author needs to allow it](/confidential-computing/confidential-space/docs/reference/launch-policies#monitoring-memory-allow),\n and the\n [workload operator needs to enable it](/confidential-computing/confidential-space/docs/reference/metadata-variables#tee-memory-monitoring-enable)\n before memory usage is tracked.\n\n- **Interactive shell** : After using SSH to connect to your workload\n Confidential VM, you can use the\n `sudo ctr task exec -t --exec-id shell tee-container bash` command to enter\n an interactive shell inside the container to diagnose workload issues.\n\nLogging\n-------\n\nLike any command line program, the workload `STDOUT` and `STDERR` can be\ndisplayed in the console. It can also be redirected to Cloud Logging by the\nworkload operator setting the\n[`tee-container-log-redirect`](/confidential-computing/confidential-space/docs/deploy-workloads#tee-container-log-redirect)\nmetadata key to `true` or `cloud_logging` on the Confidential Space VM, and\nensuring that the service account running the workload has the\n`logging.logWriter` role.\n\nRedirection can be prevented by the workload author with the\n[`log_redirect` launch policy](/confidential-computing/confidential-space/docs/create-customize-workloads#log-redirect).\n\nTo reduce your risk profile, log the minimum amount of information, and don't\nlog sensitive information.\n\n### View Confidential Space logs\n\nIf the service account attached to your Confidential Space VM has been granted the\n`logging.logWriter` role and you've redirected logs to Cloud Logging, you can\ntroubleshoot errors by viewing the VM's logs:\n\n1. Go to **Logging** in the workload operator's project in the\n Google Cloud console.\n\n [Go to Logging](https://console.cloud.google.com/logs)\n2. Next to the **Query** tab, click the time range to set the logging period\n you want to view.\n\n3. Filter the logs by the following log fields if they're available:\n\n - **Resource type:** VM Instance\n\n - **Instance ID:** The instance ID of the Confidential VM\n\n - **Log name:** confidential-space-launcher\n\n4. Read the failure message to find out what the problem is. A resource might\n not have been set up properly, the attribute conditions in your data\n collaborators' WIP providers might not match the claims made by the\n Confidential Space workload, or the workload itself might have had an error.\n\nReturn codes\n------------\n\nReturn codes are displayed in the console when running the\n[launcher](/docs/security/confidential-space#attestation-process)\nand workload, and can be redirected to Cloud Logging.\n\nThe return codes are described in the following table:\n\nIf a workload fails, a workload operator only receives the message\n`workload finished with a non-zero return code`, without further context. For a\nproduction image, the launcher can be set to restart on failure with\n[`tee-restart-policy=OnFailure`](/confidential-computing/confidential-space/docs/deploy-workloads#tee-restart-policy)."]]