Como resolver problemas do Workbench da plataforma de agentes

Nesta página, descrevemos as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar o Gemini Enterprise Agent Platform Workbench.

Consulte também Solução de problemas da plataforma de agentes para receber ajuda ao usar outros componentes da plataforma de agentes do Gemini Enterprise.

Para filtrar o conteúdo desta página, clique em um tópico:

Instâncias do Workbench da plataforma do agente

Nesta seção, descrevemos as etapas de solução de problemas para instâncias do Agent Platform Workbench.

Solução de problemas com ferramentas de IA

Esta seção discute como usar ferramentas de IA para solução de problemas.

Solução de problemas com as investigações do Cloud Assist

Ao conectar a plataforma de agentes a outros produtos Google Cloud , as investigações do Gemini Cloud Assist podem ser úteis para resolver problemas de integração. Isso também pode acelerar a solução de problemas na própria instância. Com o Gemini Cloud Assist, é possível extrair insights de métricas e registros gerados pela instância.

  • Pare a instância e siga o link View in Compute Engine.
  • Instale o Agente de operações (recomendado). Isso vai levar alguns minutos
  • Adicione um campo Metadados personalizados notebook-enable-debug e defina como true.
  • Reinicie a instância e reproduza o problema.
  • Ative e configure a API Cloud Assist Investigations.
  • Crie uma nova investigação e descreva o problema em detalhes usando um comando de linguagem natural.
  • Ao digitar, uma caixa de diálogo aparece sugerindo recursos para adicionar à investigação. Revise essa lista e adicione a instância como um recurso, bem como outros recursos na lista de produtos compatíveis.
  • Inicie a investigação e analise os resultados.

Resolver problemas com arquivos de diagnóstico usando a CLI do Gemini

Você pode usar os resultados da investigação do Cloud Assist para informar outras investigações baseadas em IA no arquivo de diagnóstico da instância.

  • Execute a ferramenta de diagnóstico e especifique um bucket do Cloud Storage para fazer upload dos resultados.
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
  • Faça o download do arquivo de diagnóstico para sua estação de trabalho e instale e configure a CLI do Gemini.
  • Inicie o aplicativo e descreva o problema. Inclua a hipótese da investigação do Cloud Assist no contexto. Peça ao modelo para estender a investigação lendo o conteúdo do arquivo de diagnóstico usando comandos de linguagem natural.

Como se conectar e abrir o JupyterLab

Nesta seção, descrevemos as etapas de solução de problemas para se conectar e abrir o JupyterLab.

Nada acontece após clicar em Abrir JupyterLab

Problema

Quando você clica em Abrir JupyterLab, nada acontece.

Solução

Verifique se o navegador não impede que novas guias sejam abertas automaticamente. O JupyterLab é aberto em uma nova guia do navegador.

Não é possível acessar o terminal em uma instância do Workbench da plataforma do agente

Problema

Se você não conseguir acessar o terminal ou encontrar a janela do terminal na tela de início, isso pode ser porque a instância do Agent Platform Workbench não tem o acesso ao terminal ativado.

Solução

Crie uma nova instância do Agent Platform Workbench com a opção Acesso de terminal ativada. Essa opção não pode ser alterada após a criação da instância.

Erro 502 ao abrir o JupyterLab

Problema

Um erro 502 pode significar que sua instância do Workbench da plataforma do agente ainda não está pronta.

Solução

Aguarde alguns minutos, atualize a guia do navegador do console Google Cloud e tente de novo.

O notebook não responde

Problema

Sua instância do Workbench da plataforma do agente não está executando células ou parece estar congelada.

Solução

Primeiro, tente reiniciar o kernel clicando em Kernel no menu superior e depois em Reiniciar kernel. Se isso não funcionar, tente o seguinte:

  • Atualize a página do navegador JupyterLab. A saída da célula não salva não persiste. Portanto, execute essas células novamente para gerar a saída novamente.
  • Redefina a instância.

Não foi possível se conectar à instância do Agent Platform Workbench usando SSH

Problema

Não é possível se conectar à sua instância usando SSH em uma janela de terminal.

As instâncias do Workbench da plataforma do agente usam o Login do SO para permitir o acesso SSH. Quando você cria uma instância, o Agent Platform Workbench ativa o login do SO por padrão, definindo a chave de metadados enable-oslogin como TRUE. Se não for possível usar o SSH para se conectar à instância, talvez essa chave de metadados precise ser definida como TRUE.

Solução

Não há suporte para conexão com uma instância do Workbench da Agent Platform usando o console Google Cloud . Se você não conseguir se conectar à sua instância usando SSH em uma janela de terminal, consulte:

Para definir a chave de metadados enable-oslogin como TRUE, use o método projects.locations.instances.patch na API Notebooks ou o comando gcloud workbench instances update no SDK da plataforma de agentes.

A cota de GPU foi excedida

Problema

Não é possível criar uma instância do Agent Platform Workbench com GPUs.

Solução

Consulte a página de cotas para saber o número de GPUs disponíveis no seu projeto. Se as GPUs não estiverem listadas nessa página ou se você precisar de mais cotas, solicite um aumento para as GPUs do Compute Engine. Consulte Solicitar um limite de cota maior.

Como criar instâncias do Workbench da plataforma de agentes

Esta seção descreve como solucionar problemas relacionados à criação de instâncias do Agent Platform Workbench.

A instância permanece no estado pendente indefinidamente ou fica presa no status de provisionamento

Problema

Depois de criar uma instância do Workbench da plataforma do agente, ela permanece no estado pendente indefinidamente. Um erro como este pode aparecer nos registros seriais:

Could not resolve host: notebooks.googleapis.com

Se a instância fica presa no status de provisionamento, isso pode ser porque você tem uma configuração de rede particular inválida para ela.

Solução

Siga as etapas na seção Os registros da instância mostram erros de conexão ou de tempo limite.

Não é possível criar uma instância dentro de uma rede VPC compartilhada

Problema

A tentativa de criar uma instância em uma rede VPC compartilhada resulta em uma mensagem de erro como esta:

Required 'compute.subnetworks.use' permission for
'projects/network-administration/regions/us-central1/subnetworks/v'

Solução

O problema é que a conta de serviço de notebooks está tentando criar a instância sem as permissões corretas.

Para garantir que a conta de serviço do Notebooks tenha as permissões necessárias para criar uma instância do Agent Platform Workbench em uma rede VPC compartilhada, peça ao administrador para conceder à conta de serviço do Notebooks o papel de usuário da rede de computação (roles/compute.networkUser) do IAM no projeto host.

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esse papel predefinido contém as permissões necessárias para garantir que a conta de serviço do Notebooks possa criar uma instância do Agent Platform Workbench em uma rede VPC compartilhada. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para garantir que a conta de serviço do Notebooks possa criar uma instância do Agent Platform Workbench em uma rede VPC compartilhada:

  • Para usar sub-redes: compute.subnetworks.use

O administrador também pode conceder essas permissões à conta de serviço de notebooks com papéis personalizados ou outros papéis predefinidos.

Não é possível criar uma instância do Agent Platform Workbench com um contêiner personalizado

Problema

Não há opção para usar um contêiner personalizado ao criar uma instância do Agent Platform Workbench no console do Google Cloud .

Solução

Não é possível adicionar um contêiner personalizado a uma instância do Agent Platform Workbench usando o console Google Cloud .

Adicionar um ambiente conda é recomendado em vez de usar um contêiner personalizado.

É possível adicionar um contêiner personalizado a uma instância do Agent Platform Workbench usando a API Notebooks, mas esse recurso não é compatível.

Não é possível usar a CLI do Gemini

Problema

O bloco da CLI do Gemini está no iniciador do JupyterLab e abre sem problemas, mas o Gemini não responde aos comandos.

Solução

Um administrador pode ter bloqueado o acesso à CLI do Gemini. Consulte Controlar o acesso à CLI do Gemini.

O botão "Ativar armazenamento compartilhado" não aparece

Problema

O botão Montar armazenamento compartilhado não aparece na guia Navegador de arquivos da interface do JupyterLab.

Solução

A permissão storage.buckets.list é necessária para que o botão Montar armazenamento compartilhado apareça na interface do JupyterLab da sua instância do Agent Platform Workbench. Peça ao administrador para conceder à conta de serviço da instância do Agent Platform Workbench a permissão storage.buckets.list no projeto.

Erro 599 ao usar o Serviço Gerenciado para Apache Spark

Problema

A tentativa de criar uma instância ativada para o Serviço Gerenciado para Apache Spark resulta em uma mensagem de erro como esta:

HTTP 599: Unknown (Error from Gateway: [Timeout while connecting]
Exception while attempting to connect to Gateway server url.
Ensure gateway url is valid and the Gateway instance is running.)

Solução

Na configuração do Cloud DNS, adicione uma entrada do Cloud DNS para o domínio *.googleusercontent.com.

Não foi possível instalar a extensão JupyterLab de terceiros

Problema

A tentativa de instalar uma extensão JupyterLab de terceiros resulta em uma mensagem Error: 500.

Solução

As extensões do JupyterLab de terceiros não são compatíveis com instâncias do Agent Platform Workbench.

Não é possível editar a máquina virtual subjacente

Problema

Ao tentar editar a máquina virtual (VM) subjacente de uma instância do Agent Platform Workbench, é possível que você receba uma mensagem de erro semelhante a esta:

Current principal doesn't have permission to mutate this resource.

Solução

Esse erro ocorre porque não é possível editar a VM subjacente de uma instância usando o console Google Cloud ou a API Compute Engine.

Para editar a VM subjacente de uma instância do Agent Platform Workbench, use o método projects.locations.instances.patch na API Notebooks ou o comando gcloud workbench instances update no SDK da plataforma do agente.

pacotes pip não ficam disponíveis após a adição do ambiente conda

Problema

Seus pacotes pip não ficam disponíveis depois que você adiciona um kernel baseado em conda.

Solução

Para resolver o problema, consulte Adicionar um ambiente conda e tente o seguinte:

  • Verifique se você usou a variável DL_ANACONDA_ENV_HOME e se ela contém o nome do ambiente.

  • Verifique se pip está localizado em um caminho semelhante a opt/conda/envs/ENVIRONMENT/bin/pip. Execute o comando which pip para indicar o caminho.

Não é possível acessar ou copiar dados de uma instância com acesso de usuário único

Problema

Os dados em uma instância com acesso de usuário único ficam inacessíveis.

Para instâncias do Agent Platform Workbench configuradas com acesso de um único usuário, apenas o único usuário especificado (o proprietário) pode acessar os dados na instância.

Solução

Para acessar ou copiar os dados quando você não é o proprietário da instância, abra um caso de suporte.

Desligamento inesperado

Problema

Sua instância do Workbench da plataforma do agente é encerrada inesperadamente.

Solução

Se a instância for encerrada inesperadamente, pode ser que o desligamento inativo tenha sido iniciado.

Se você ativou o encerramento inativo, a instância será encerrada quando não houver atividade do kernel para o período especificado. Por exemplo, executar uma célula ou nova impressão de saída em um notebook é a atividade que redefine o timer de tempo limite de inatividade. O uso da CPU não redefine o timer de tempo limite de inatividade.

Os registros da instância mostram erros de conexão ou de tempo limite

Problema

Os registros da instância do Agent Platform Workbench mostram erros de conexão ou de tempo limite.

Solução

Se você notar erros de conexão ou de tempo limite nos registros da instância, verifique se o servidor Jupyter está em execução na porta 8080. Siga as etapas na seção Verificar se a API interna do Jupyter está ativa.

Se você desativou External IP e está usando uma rede VPC particular, siga a documentação de opções de configuração de rede. Considere o seguinte:

Os registros da instância mostram "Não é possível entrar em contato com a API Jupyter: ReadTimeoutError".

Problema

Os registros da instância do Workbench da plataforma do agente mostram um erro, como:

notebooks_collection_agent. Unable to contact Jupyter API:
HTTPConnectionPool(host=\'127.0.0.1\', port=8080):
Max retries exceeded ReadTimeoutError(\"HTTPConnectionPool(host=\'127.0.0.1\', port=8080

Solução

Siga as etapas na seção Os registros da instância mostram erros de conexão ou de tempo limite. Você também pode tentar modificar o script do agente de coleta de notebooks para mudar HTTP_TIMEOUT_SESSION para um valor maior, como 60, o que pode ajudar a verificar se a solicitação falhou devido a uma chamada que demorou muito para responder ou à impossibilidade de acessar o URL solicitado.

O endereço docker0 entra em conflito com o endereçamento da VPC

Problema

Por padrão, a interface docker0 é criada com um endereço IP de 172.17.0.1/16. Isso pode entrar em conflito com o endereçamento IP na sua rede VPC, impedindo que a instância se conecte a outros endpoints com endereços 172.17.0.1/16.

Solução

É possível forçar a criação da interface docker0 com um endereço IP que não entre em conflito com sua rede VPC usando o seguinte script de pós-inicialização e definindo o comportamento do script de pós-inicialização como run_once.

#!/bin/bash
# Wait for Docker to be fully started
while ! systemctl is-active docker; do
sleep 1
done
# Stop the Docker service
systemctl stop docker
# Modify /etc/docker/daemon.json
cat < /etc/docker/daemon.json
{
"bip": "CUSTOM_DOCKER_IP/16"
}
EOF
# Restart the Docker service
systemctl start docker

As reservas especificadas não existem

Problema

A operação para criar a instância resulta em uma mensagem de erro Specified reservations do not exist. A saída da operação pode ser semelhante a esta:

{
  "name": "projects/PROJECT/locations/LOCATION/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.notebooks.v2.OperationMetadata",
    "createTime": "2025-01-01T01:00:01.000000000Z",
    "endTime": "2025-01-01T01:00:01.000000000Z",
    "target": "projects/PROJECT/locations/LOCATION/instances/INSTANCE_NAME",
    "verb": "create",
    "requestedCancellation": false,
    "apiVersion": "v2",
    "endpoint": "CreateInstance"
  },
  "done": true,
  "error": {
    "code": 3,
    "message": "Invalid value for field 'resource.reservationAffinity': '{  \"consumeReservationType\": \"SPECIFIC_ALLOCATION\",  \"key\": \"compute.googleapis.com/reservation-name...'. Specified reservations [projects/PROJECT/zones/ZONE/futureReservations/RESERVATION_NAME] do not exist.",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "REQUEST_ID"
      }
    ]
  }
}

Solução

Alguns tipos de máquina do Compute Engine exigem parâmetros adicionais na criação, como SSDs locais ou uma plataforma de CPU mínima. A especificação da instância precisa incluir estes campos adicionais.

  • As instâncias do Workbench da Agent Platform usam a plataforma mínima de CPU automática por padrão. Se a reserva definir uma plataforma específica, defina o min_cpu_platform de acordo ao criar instâncias do Agent Platform Workbench.
  • As instâncias do Agent Platform Workbench sempre definem o número de SSDs locais como os valores padrão de acordo com o tipo de máquina. Por exemplo, a2-ultragpu-1g sempre tem um SSD local, enquanto a2-highgpu-1g sempre tem zero. Ao criar reservas para usar com instâncias do Agent Platform Workbench, deixe o SSD local com o valor padrão.

Procedimentos úteis

Esta seção descreve procedimentos que podem ser úteis.

Use SSH para se conectar à instância do Agent Platform Workbench

Use o SSH para se conectar à instância digitando o seguinte comando no Cloud Shell ou em qualquer ambiente em que a Google Cloud CLI esteja instalada.

gcloud compute ssh --project PROJECT_ID \
  --zone ZONE \
  INSTANCE_NAME -- -L 8080:localhost:8080

Substitua:

  • PROJECT_ID: o ID do projeto
  • ZONE: a Google Cloud zona em que a instância está localizada
  • INSTANCE_NAME: o nome da instância

Também é possível conectar-se à instância abrindo a página de detalhes do Compute Engine dela e clicando no botão SSH.

Registrar novamente com o servidor Inverting Proxy

Para registrar novamente a instância do Workbench da Plataforma de Agentes com o servidor Inverting Proxy interno, interrompa e inicie a VM na página "Instâncias" ou use SSH para se conectar à instância do Workbench da Plataforma de Agentes e digite:

cd /opt/deeplearning/bin
sudo ./attempt-register-vm-on-proxy.sh

Verificar o status do serviço do Docker

Para verificar o status do serviço do Docker, use ssh para se conectar à sua instância do Agent Platform Workbench e digite:

sudo service docker status

Verifique se o agente do Inverting Proxy está em execução

Para verificar se o agente Inverting Proxy do notebook está em execução, use SSH para se conectar à instância do Agent Platform Workbench e digite:

# Confirm Inverting Proxy agent Docker container is running (proxy-agent)
sudo docker ps

# Verify State.Status is running and State.Running is true.
sudo docker inspect proxy-agent

# Grab logs
sudo docker logs proxy-agent

Verifique o status do serviço Jupyter e colete os registros

Para verificar o status do serviço Jupyter, use ssh para se conectar à instância do Agent Platform Workbench e digite:

sudo service jupyter status

Para coletar os registros do serviço Jupyter:

sudo journalctl -u jupyter.service --no-pager

Verificar se a API interna do Jupyter está ativa

A API Jupyter precisa ser executada sempre na porta 8080. Para verificar se isso está acontecendo, inspecione os syslogs da instância em busca de uma entrada semelhante a esta:

Jupyter Server ... running at:
http://localhost:8080

Para verificar se a API interna do Jupyter está ativa, use SSH para se conectar à instância do Agent Platform Workbench e digite:

curl http://127.0.0.1:8080/api/kernelspecs

Também é possível medir o tempo que a API leva para responder, caso as solicitações estejam demorando muito:

time curl -V http://127.0.0.1:8080/api/status
time curl -V http://127.0.0.1:8080/api/kernels
time curl -V http://127.0.0.1:8080/api/connections

Para executar esses comandos na instância do Agent Platform Workbench, abra o JupyterLab e crie um terminal.

Reinicie o serviço do Docker

Para reiniciar o serviço Docker, interrompa e inicie a VM na página "Instâncias" ou use SSH para se conectar à instância do Agent Platform Workbench e digite:

sudo service docker restart

Reiniciar o agente do Inverting Proxy

Para reiniciar o agente Inverting Proxy, interrompa e inicie a VM na página "Instâncias" ou use SSH para se conectar à instância do Agent Platform Workbench e digite:

sudo docker restart proxy-agent

Reiniciar o serviço Jupyter

Para reiniciar o serviço Jupyter, interrompa e inicie a VM na página "Instâncias" ou use SSH para se conectar à instância do Agent Platform Workbench e digite:

sudo service jupyter restart

Reiniciar o agente de coleta de notebooks

O serviço do agente de coleta de Notebooks executa um processo Python em segundo plano que verifica o status dos serviços principais da instância do Agent Platform Workbench.

Para reiniciar o serviço do agente de coleta de notebooks, interrompa e inicie a VM no console doGoogle Cloud ou use SSH para se conectar à instância do Agent Platform Workbench e digite:

sudo systemctl stop notebooks-collection-agent.service

seguido por:

sudo systemctl start notebooks-collection-agent.service

Para executar esses comandos na instância do Agent Platform Workbench, abra o JupyterLab e crie um terminal.

Modificar o script do agente de coleta de notebooks

Para acessar e editar o script, abra um terminal na instância ou use SSH para se conectar à instância do Agent Platform Workbench e digite:

nano /opt/deeplearning/bin/notebooks_collection_agent.py

Depois de editar o arquivo, salve-o.

Em seguida, reinicie o serviço do agente de coleta de notebooks.

Verificar se a instância pode resolver os domínios DNS necessários

Para verificar se a instância pode resolver os domínios DNS necessários, use SSH para se conectar à instância do Agent Platform Workbench e digite:

host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com

ou

curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?

Se a instância tiver o Serviço Gerenciado para Apache Spark ativado, você poderá verificar se ela resolve *.kernels.googleusercontent.com executando o seguinte:

curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .

Para executar esses comandos na instância do Agent Platform Workbench, abra o JupyterLab e crie um terminal.

Fazer uma cópia dos dados do usuário em uma instância

Para armazenar uma cópia dos dados do usuário da sua instância no Cloud Storage, conclua as etapas a seguir.

Criar um bucket do Cloud Storage (opcional)

No mesmo projeto em que sua instância está localizada, crie um bucket do Cloud Storage para armazenar os dados do usuário. Caso você já tenha um bucket do Cloud Storage, pule esta etapa.

Copiar dados do usuário

  1. Na interface da instância do JupyterLab, selecione File > New > Terminal para abrir uma janela de terminal. Para instâncias do Workbench da Agent Platform, é possível se conectar ao terminal da instância usando SSH.

  2. Use a gcloud CLI para copiar os dados do usuário para um bucket do Cloud Storage. O exemplo de comando a seguir copia todos os arquivos do diretório /home/jupyter/ da instância para um diretório em um bucket do Cloud Storage.

    gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive

    Substitua:

    • BUCKET_NAME: o nome do bucket do Cloud Storage
    • PATH: o caminho para o diretório em que você quer copiar os arquivos, por exemplo: /copy/jupyter/

Investigar uma instância que está com problemas de provisionamento usando o gcpdiag

gcpdiag é uma ferramenta de código aberto. Não é um produto do Google Cloud com suporte oficial. Use a ferramenta gcpdiag para identificar e corrigir problemas no projeto Google Cloud. Para mais informações, consulte o projeto gcpdiag no GitHub.

Este runbook gcpdiag investiga as possíveis causas de uma instância do Workbench da Agent Platform ficar presa no status de provisionamento, incluindo as seguintes áreas:
  • Status: verifica o status atual da instância para confirmar se ela está travada no provisionamento e não interrompida ou ativa.
  • Imagem de disco de inicialização da VM do Compute Engine da instância: verifica se a instância foi criada com um contêiner personalizado, uma imagem workbench-instances oficial, Deep Learning VM Images ou imagens sem suporte que podem causar o travamento dela no status de provisionamento.
  • Scripts personalizados: verifica se a instância está usando scripts personalizados de inicialização ou pós-inicialização que mudam a porta padrão do Jupyter ou quebram dependências que podem fazer com que a instância fique presa no status de provisionamento.
  • Versão do ambiente: verifica se a instância está usando a versão mais recente do ambiente, verificando a capacidade de upgrade dela. Versões anteriores podem fazer com que a instância fique presa no status de provisionamento.
  • Desempenho da VM do Compute Engine da instância: verifica o desempenho atual da VM para garantir que ela não esteja prejudicada pelo uso de CPU alto, por memória insuficiente ou por problemas de espaço em disco que possam interromper as operações normais.
  • Porta serial do Compute Engine ou geração de registros do sistema da instância: verifica se a instância tem registros de porta serial, que são analisados para garantir que o Jupyter esteja em execução na porta 127.0.0.1:8080.
  • Acesso SSH e de terminal do Compute Engine da instância: verifica se a VM do Compute Engine da instância está em execução para que o usuário possa usar SSH e abrir um terminal para verificar se o uso de espaço em home/jupyter é inferior a 85%. Quando não há espaço, a instância pode ficar presa no status de provisionamento.
  • IP externo desativado: verifica se o acesso a IPs externos está desativado. Uma configuração de rede incorreta pode fazer com que a instância fique presa no status de provisionamento.

Docker

Você pode executar gcpdiag usando um wrapper que inicia gcpdiag em um contêiner do Docker. Docker ou Podman precisa ser instalado.

  1. Copie e execute o seguinte comando na estação de trabalho local. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Execute o comando gcpdiag. 
    ./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Veja os parâmetros disponíveis para este runbook.

Substitua:

  • PROJECT_ID: o ID do projeto que contém o recurso.
  • INSTANCE_NAME: o nome da instância de destino do Workbench da plataforma de agentes no projeto.
  • ZONE: a zona em que a instância de destino do Workbench da plataforma do agente está.

Flags úteis

Para conferir uma lista e descrição de todas as flags da ferramenta gcpdiag, consulte Instruções de uso do gcpdiag.

Erros de permissões ao usar papéis de conta de serviço com a plataforma do agente

Problema

Você recebe erros gerais de permissão ao usar papéis de conta de serviço com a plataforma do agente.

Esses erros podem aparecer no Cloud Logging nos registros de auditoria ou do componente do produto. Elas também podem aparecer em qualquer combinação dos projetos afetados.

Esses problemas podem ser causados por um ou ambos os motivos a seguir:

  • Uso da função Service Account Token Creator quando a função Service Account User deveria ter sido usada, ou vice-versa. Esses papéis concedem permissões diferentes em uma conta de serviço e não são intercambiáveis. Para saber mais sobre as diferenças entre os papéis Service Account Token Creator e Service Account User, consulte Papéis da conta de serviço.

  • Você concedeu permissões de uma conta de serviço em vários projetos, o que não é permitido por padrão.

Solução

Para resolver o problema, tente uma ou mais das seguintes opções:

  • Determine se a função Service Account Token Creator ou Service Account User é necessária. Para saber mais, leia a documentação do IAM para os serviços da plataforma de agentes que você está usando, bem como outras integrações de produtos.

  • Se você tiver concedido permissões a uma conta de serviço em vários projetos, ative a vinculação de contas de serviço entre projetos verificando se iam.disableCrossProjectServiceAccountUsage. não é aplicada. Para garantir que iam.disableCrossProjectServiceAccountUsage não seja aplicado, execute o seguinte comando:

    gcloud resource-manager org-policies disable-enforce \
  iam.disableCrossProjectServiceAccountUsage \
  --project=PROJECT_ID