Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Resolver problemas do Storage Intelligence

Neste documento, descrevemos como resolver problemas comuns com o Storage Intelligence, os relatórios de inventário do Storage Insights, os conjuntos de dados do Storage Insights, os enriquecimentos de objetos (pré-lançamento) e as operações em lote do Storage.

Erros de configuração do Storage Intelligence

As seções a seguir descrevem os erros que podem ocorrer ao configurar ou gerenciar o Storage Intelligence para um recurso.

400: nome de bucket inválido

Problema: a solicitação retorna 400 Bad Request com a mensagem The specified bucket is not valid.

Solução: a solicitação é inválida. Verifique se a solicitação atende aos seguintes requisitos:

Use locations/global. O Storage Intelligence não é compatível com outros locais.
Verifique se os nomes de bucket ou as expressões regulares em bucket_id_regexes são válidos.

Confira um exemplo de solicitação válida:

curl -X PATCH \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    -d '{
      "edition_config": "STANDARD",
      "filter": {
        "included_cloud_storage_buckets": {
          "bucket_id_regexes": [
            "my-bucket-name",
            "prod-data-.*"
          ]
        }
      }
    }' \
    "https://storage.s3nsapis.fr/v2/projects/PROJECT_ID/locations/global/intelligenceConfig?updateMask=edition_config,filter"

400: argumento inválido - máscara de atualização vazia

Problema: quando você envia uma solicitação de configuração ou atualização, ela retorna 400 Bad Request com a mensagem Empty UPDATE_MASK in the request.

Solução: forneça um UPDATE_MASK não vazio na sua solicitação. UPDATE_MASK especifica uma lista separada por vírgulas de campos FieldMask no recurso IntelligenceConfig a serem atualizados (como updateMask=edition_config ou updateMask=edition_config,filter).

400: caminho inválido da máscara de atualização

Problema: ao atualizar uma configuração, a solicitação retorna 400 Bad Request com a mensagem Invalid UPDATE_MASK paths..

Solução: verifique se cada nome de campo em UPDATE_MASK corresponde a um campo válido no recurso IntelligenceConfig.

400: o campo não é editável

Problema: ao atualizar uma configuração, a solicitação retorna 400 Bad Request com a mensagem Invalid UPDATE_MASK: UPDATE_TIME field is not editable.

Solução: remova os campos do sistema não editáveis (como UPDATE_TIME) de UPDATE_MASK. Especifique apenas campos mutáveis definidos em IntelligenceConfig.

400: valor inválido

Problema: a solicitação retorna 400 Bad Request com a mensagem Invalid value at storage_intelligence.edition_config.

Solução: defina edition_config como um valor compatível: INHERIT, STANDARD ou DISABLED.

400: filtro não vazio

Problema: a solicitação retorna 400 Bad Request com a mensagem Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration.

Solução: remova os filtros de bucket da solicitação. Os filtros de bucket não são compatíveis quando edition_config é definido como INHERIT ou DISABLED.

400: valores de local ou grupo vazios no filtro

Problema: a solicitação retorna 400 Bad Request com a mensagem Empty location or bucket values in filter..

Solução: verifique se location e bucket não são strings vazias no seu filtro de bucket.

Problemas comuns do Storage Insights

Nesta seção, descrevemos como resolver problemas comuns com relatórios de inventário e conjuntos de dados.

Vários relatórios de inventário gerados diariamente

Problema: uma configuração de relatório de inventário gera vários arquivos de relatório todos os dias.

Solução: o Cloud Storage fragmenta os relatórios de inventário de buckets com mais de 1.000.000 de objetos, gerando um fragmento para cada 1.000.000 de objetos. Por exemplo, um bucket com 3.500.000 objetos gera quatro fragmentos de relatório e um arquivo de manifesto que lista cada fragmento.

Os relatórios de inventário não aparecem no bucket de destino

Problema: os relatórios de inventário não aparecem no bucket de destino.

Solução: se os relatórios não forem entregues ao bucket de destino, verifique o seguinte:

Verifique se a data de início configurada já passou. Para mais informações, consulte Criar uma configuração de relatório de inventário.
Veja o histórico de relatórios de inventário para verificar se há falhas e as causas raízes. Para ver o histórico de relatórios de inventário, siga estas etapas:
1. No console do Cloud de Confiance , acesse a página Buckets do Cloud Storage.
  
  Acessar buckets
2. Na lista de buckets, clique no nome do bucket de origem que contém a configuração do relatório de inventário.
3. Na página Detalhes do bucket, clique na guia Relatórios de inventário.
4. Na lista de configurações do relatório de inventário, clique no UUID da configuração do relatório de inventário que gerou os relatórios que você quer verificar.
5. Verifique se há falhas na seção Histórico de relatórios de inventário. É possível manter o ponteiro sobre Ajuda () para ver detalhes sobre o motivo da falha.
Verifique se o agente de serviço para envolvidos no projeto tem os papéis do IAM necessários para ler e gravar relatórios de inventário. Para mais informações, consulte Conceder os papéis necessários ao agente de serviço.

Atrasos no relatório de inventário

Problema: a geração do relatório de inventário está atrasada.

Solução: os tempos de geração de relatórios variam. Atrasos de até 24 horas são normais.

Os conjuntos de dados não estão sendo preenchidos

Problema: as tabelas do conjunto de dados do Storage Insights permanecem vazias.

Solução: no conjunto de dados vinculado do BigQuery, verifique se há códigos de erro em error_attributes_view. Para mais informações, consulte Resolver problemas de erros de conjunto de dados.

Valores nulos na coluna "ref" ao consultar conjuntos de dados

Problema: ao consultar conjuntos de dados do Storage Insights no BigQuery, a coluna ref retorna null.

Solução: para objetos que terminam em /, a coluna ref nos conjuntos de dados é nula.

Se a coluna ref retornar valores nulos ao consultar conjuntos de dados do Storage Insights no BigQuery, verifique se você concedeu as permissões e os papéis de conexão necessários, incluindo o acesso aos recursos do Cloud Storage, conforme descrito em Analisar dados e metadados de objetos usando o BigQuery.

Erros de enriquecimento de objetos

Esta seção descreve como resolver problemas comuns ao configurar, gerar ou consultar enriquecimentos de objetos.

Enriquecimentos ausentes para objetos

Problema: os enriquecimentos de objetos não aparecem nos objetos depois que você os configura.

Solução: verifique o seguinte:

Permissões do agente de serviço: conceda ao agente de serviço de enriquecimento de objetos o papel roles/storage.annotationGeneratorService no bucket (ou projeto) de destino e o papel roles/storage.bucketViewer no projeto. Para instruções, consulte Conceder permissões ao agente de serviço.
Configuração de filtro e escopo: verifique se o recurso FeatureConfig inclui explicitamente o nome do bucket de destino. O Cloud Storage não inclui automaticamente os buckets criados após a criação do recurso FeatureConfig. Além disso, se você excluir e recriar ou realocar um bucket, será necessário atualizar o recurso FeatureConfig para incluí-lo novamente.
Pré-requisitos do modelo e metadados do Content-Type: verifique se os objetos atendem aos limites de tipo de conteúdo e tamanho dos modelos ativados. O Cloud Storage usa o campo de metadados Content-Type do objeto para determinar a qualificação (BMP, GIF, ICO, JPEG, PNG, TIFF ou WEBP para imagens; application/pdf para classificação de PDF). Se os metadados Content-Type estiverem ausentes ou incorretos, o Cloud Storage não processará o objeto até que você atualize os metadados. Além disso, o serviço de enriquecimento de objetos ignora objetos maiores que 20 MiB. Para mais informações, consulte Modelos e esquemas compatíveis.
Latência de processamento: aguarde tempo suficiente para o processamento assíncrono. O serviço de enriquecimento de objetos processa objetos de forma assíncrona. As melhorias para objetos recém-enviados geralmente aparecem em algumas horas. Por outro lado, o preenchimento de objetos existentes em buckets grandes pode levar horas ou dias.

Os enriquecimentos de objetos não ficam visíveis no BigQuery

Problema: os enriquecimentos de objeto aparecem na API, mas não no BigQuery.

Solução: verifique o seguinte:

Configuração de conjuntos de dados do Storage Insights: verifique se você configurou conjuntos de dados do Storage Insights para o bucket.
Programação de relatórios diários: aguarde a atualização diária do conjunto de dados. Os conjuntos de dados do Storage Insights são atualizados a cada 24 horas. Portanto, as melhorias recém-geradas podem levar até 24 horas para aparecer na visualização object_contexts_catalog_view no BigQuery.
Permissões do IAM: verifique se você tem permissões para executar jobs e ler dados no BigQuery (como roles/bigquery.jobUser e roles/bigquery.dataViewer). Para orientações sobre consultas, consulte Analisar enriquecimentos de objetos no BigQuery.

Permissão negada ao recuperar dados de enriquecimento de objetos estendidos

Problema: ocorre um erro de permissão ao recuperar dados estendidos de enriquecimento de objetos.

Solução: é preciso ter a permissão storage.objects.viewFullContext no objeto ou bucket para recuperar dados estendidos, como coordenadas de caixa delimitadora ou pontuações de confiança de categoria. Papéis como Usuário de objetos do Storage (roles/storage.objectUser) e Administrador do Storage (roles/storage.admin) incluem essa permissão. Para mais informações, consulte Gerenciar enriquecimentos de objetos.

Permissão negada ao gerenciar configurações de recursos

Problema: um erro de permissão ocorre ao criar, atualizar ou excluir um FeatureConfig.

Solução: verifique se a conta tem o papel de Administrador do Storage (roles/storage.admin) ou um papel personalizado com as permissões necessárias no projeto de destino. Essas permissões necessárias incluem storage.featureConfigs.create, storage.featureConfigs.update ou storage.featureConfigs.delete. Para permissões específicas do método, consulte Configurar enriquecimentos de objetos e o recurso da API featureConfigs.

Erros de validação de jobs de operações em lote do Storage

Nesta seção, descrevemos os erros de validação que ocorrem ao enviar uma solicitação de job de operações em lote para storagebatchoperations.googleapis.com.

400: ID da tarefa ou nome do recurso inválido

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com o motivo JOB_ID_INVALID ou RESOURCE_NAME_TOO_LONG.

Solução: verifique se o ID da tarefa consiste em 1 a 63 caracteres alfanuméricos minúsculos ou hifens ([a-z0-9]([-a-z0-9]*[a-z0-9])?) e se o caminho completo do recurso da tarefa (projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID) não excede 200 bytes. Se o caminho exceder 200 bytes, reduza o ID da tarefa. Para mais informações, consulte Nome do job.

400: a descrição da vaga excede o limite

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com o motivo DESCRIPTION_TOO_LONG.

Solução: verifique se a descrição do job tem 1.024 bytes ou menos. Se ele exceder esse limite, encurte o texto. Para mais informações, consulte Descrição do job.

400: configurações de origem do job ausentes ou inválidas

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) por um dos seguintes motivos:

SOURCE_NOT_SPECIFIED
BUCKET_LIST_EMPTY
TOO_MANY_BUCKETS
MULTI_BUCKET_NOT_SUPPORTED
BUCKET_NAME_REQUIRED
OBJECT_CONFIGURATION_REQUIRED

Solução: verifique se o job especifica uma configuração de origem válida (bucket_list ou project_source) e se cada bucket define um método de seleção de objetos. Para mais informações, consulte Criar e gerenciar jobs de operações em lote.

400: nome de bucket ou objeto inválido

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com o motivo BUCKET_NAME_INVALID ou OBJECT_NAME_INVALID.

Solução: verifique se todos os nomes de buckets e objetos estão em conformidade com os requisitos de nomenclatura do Cloud Storage. Para mais informações, consulte as diretrizes de nomenclatura de bucket e as diretrizes de nomenclatura de objeto.

400: erros de configuração da origem do projeto

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com qualquer um dos seguintes motivos:

PROJECT_SOURCE_PROJECT_INVALID
PROJECT_SOURCE_DRY_RUN_FIELDS_EXCLUSIVE
PROJECT_SOURCE_DRY_RUN_ID_INVALID

Solução: verifique se a configuração da origem do projeto atende aos requisitos de formatação e exclusividade de campo. Se você especificar um ID da tarefa de simulação, omita todos os outros parâmetros project_source. Para mais informações, consulte Criar um job usando filtros avançados.

400: parâmetros de transformação conflitantes ou ausentes

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) por um dos seguintes motivos:

TRANSFORMATION_NOT_SPECIFIED
REWRITE_OBJECT_MISSING_PARAMETERS
PUT_OBJECT_HOLD_MISSING_PARAMETERS
PUT_METADATA_MISSING_PARAMETERS

Solução: especifique exatamente um tipo de transformação com todos os parâmetros obrigatórios. Se você estiver configurando a retenção de objetos, verifique se o bloqueio de objetos está ativado no bucket e se os carimbos de data/hora usam o formato UTC RFC 3339. Para mais informações sobre os requisitos de parâmetros por transformação, consulte Tipo de serviço.

400: prefixos de objeto sobrepostos ou duplicados

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com o motivo OBJECT_PREFIX_OVERLAP ou DUPLICATE_OBJECT_PREFIX.

Solução: remova os prefixos duplicados e verifique se nenhum prefixo em included_object_prefixes é um prefixo de outra entrada na lista. Para mais informações, consulte Prefixos de objetos.

400: problemas de formatação do arquivo de manifesto e acesso

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com o motivo MANIFEST_LOCATION_REQUIRED ou MANIFEST_LOCATION_INVALID, ou o job não consegue ler o manifesto.

Solução: verifique se o URI do manifesto é um caminho CSV válido (gs://<bucket_name>/<path>/<object_name>.csv) e se o agente de serviço de operações em lote do Storage tem o papel roles/storage.objectViewer no bucket do manifesto. Para mais informações sobre a formatação de CSV e os requisitos de esquema, consulte Manifesto.

400: erros de descoberta do conjunto de dados do Storage Insights

Problema: usar um conjunto de dados do Storage Insights para descoberta de objetos retorna uma resposta 400 Bad Request (INVALID_ARGUMENT ou FAILED_PRECONDITION) por qualquer um dos seguintes motivos:

BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD
TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME
BUCKET_DISCOVERY_TOO_MANY_BUCKETS

Solução: verifique se snapshot_time está nas últimas 48 horas, especifique target_locations para os buckets e garanta que a consulta de descoberta não corresponda a mais de 1.000 buckets. Para mais informações, consulte Criar um manifesto usando conjuntos de dados do Storage Insights.

400: falha na transformação da classe de armazenamento em buckets com a classe automática ativada

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (FAILED_PRECONDITION) com o motivo AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED.

Solução: não é possível executar transformações de classe de armazenamento em buckets com a classe automática ativada. Segmente um bucket sem a classe automática ou remova a transformação da classe de armazenamento. Para mais informações, consulte Restrições da classe automática.

400: falha nas atualizações de ACL de objeto em buckets de acesso uniforme no nível do bucket

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (FAILED_PRECONDITION) com o motivo UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED.

Solução: não é possível atualizar as ACLs de objetos em buckets com o acesso uniforme no nível do bucket ativado. Em vez disso, gerencie o acesso usando papéis do IAM no nível do bucket ou do projeto. Para mais informações, consulte acesso uniforme no nível do bucket.

Problemas de ambiente de execução e execução de operações em lote do Storage

Esta seção descreve problemas que ocorrem durante a execução assíncrona de um job de operações em lote.

403: erros de permissão durante a execução

Problema: um job em lote falha durante a execução com 403 Forbidden (PERMISSION_DENIED).

Solução: conceda ao agente de serviço de operações em lote do Storage (service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.s3ns-system.iam.gserviceaccount.com) os papéis do IAM necessários para seu tipo de transformação. Para mais informações, consulte Conceder permissões ao agente de serviço.

Erros de criptografia CMEK durante a reescrita de objetos

Problema: as regravações de objetos falham com 400 Bad Request ou 403 Forbidden devido a erros de status ou permissão da chave do Cloud KMS.

Solução: verifique se a chave do Cloud KMS é Enabled e está na mesma região do bucket de destino e se o agente de serviço tem o papel roles/cloudkms.cryptoKeyEncrypterDecrypter. Para mais informações, consulte Tipo de serviço: reescrever objeto.

Alta contagem de falhas em error_summaries

Problema: um job em lote é concluído com um counters.failed_object_count diferente de zero e códigos do erro em error_summaries (como 404 NOT_FOUND, 412 FAILED_PRECONDITION ou 403 PERMISSION_DENIED).

Solução: execute gcloud storage batch-operations jobs describe com a flag --location (por exemplo, gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION) para ver o detalhamento agregado de erros e verifique o Cloud Logging para registros de erros por objeto. Para mais informações, consulte Ver detalhes do job.

O job de operação em lote do Storage falha devido a um snapshot com mais de dois dias

Problema: ao criar um job de operação em lote do Storage baseado em filtro CEL, a criação do job falha. A mensagem de erro informa que o horário do snapshot é de mais de dois dias atrás.

Solução: para evitar ações em estados de objeto desatualizados, as operações em lote do Storage falham automaticamente na criação de jobs. Essa falha ocorre se o snapshot selecionado tiver mais de dois dias. Selecione um dos métodos a seguir para resolver o problema:

Usar um arquivo de manifesto: consulte seu conjunto de dados manualmente no BigQuery. Exporte os resultados para um arquivo de manifesto CSV e faça upload dele para um bucket do Cloud Storage. Em seguida, crie o job de operações em lote usando o método de manifesto para evitar o limite de dois dias.
Verifique as configurações do conjunto de dados: confira se as configurações do conjunto de dados estão ativas e não pausadas. Confirme se os snapshots do conjunto de dados são executados. Para saber como verificar suas configurações, consulte Ver uma configuração de conjunto de dados.
Usar a região de segmentação e as substituições de horário do snapshot: especifique a flag --target-snapshot-time para ignorar a falha de desatualização de dois dias selecionando explicitamente um snapshot no formato RFC 3339. Especifique a flag --target-locations para limitar a operação aos locais em que o snapshot existe. É possível usar essas substituições para resolver atrasos na sincronização que impedem a atualização do snapshot global automatizado. Consequentemente, é possível segmentar manualmente um snapshot regional mais recente. Para a sintaxe do comando, consulte Criar um job usando filtros avançados.

O job de operação em lote do Storage com base em filtro CEL falha em projetos recém-inscritos

Problema: a execução de um job de operação em lote do Storage com base em um filtro CEL em um projeto recém-inscrito falha porque o sistema não consegue encontrar um snapshot válido.

Solução: depois de ativar a assinatura do Storage Intelligence, aguarde 24 horas antes de executar jobs de operações em lote do Storage baseados em filtro CEL. Esse atraso permite que o sistema faça o snapshot de metadados inicial e estabeleça o horário de início do snapshot.

O job de operação em lote do Storage baseado em filtro CEL falha com erros de permissão ou gera erros de tempo de execução

Problema: um job de operação em lote do Storage com base em filtros CEL falha durante a execução ou retorna erros de permissões de execução.

Solução: a operação em lote do Storage usa suas credenciais de usuário para processar objetos. O job vai falhar se você não tiver as permissões necessárias de leitura ou gravação do IAM nos buckets e objetos de destino. Esse problema ocorre quando os filtros CEL selecionam recursos aos quais você não tem acesso. Confirme se sua conta tem os papéis de administrador do Storage (roles/storage.admin), administrador de objetos do Storage (roles/storage.objectAdmin) ou equivalentes para todos os buckets e objetos no escopo do job. Para instruções sobre como conceder papéis, consulte Usar permissões do IAM.

Monitoramento e análise de registros

Para mais informações sobre como inspecionar falhas de execução por objeto e payloads de erro no Cloud Logging, consulte Ver registros de operações em lote do Storage.

Problemas com o consultor do Storage Intelligence

Esta seção fornece orientações sobre como resolver problemas comuns encontrados ao usar o Storage Intelligence advisor.

Erros de permissão negada do consultor do Storage Intelligence

Problema: você recebe um erro Permission denied ao acessar o consultor do Storage Intelligence, e os gráficos e as métricas estão vazios ou mostram erros de permissão.

Solução: esse problema ocorre se você não tiver um papel do IAM com as permissões necessárias para acessar o consultor do Storage Intelligence. Peça ao administrador para conceder a você o papel de Administrador do Storage (roles/storage.admin) no projeto, na pasta ou na organização que você quer visualizar. Para ver uma lista das permissões necessárias, consulte Papéis necessários.

Permissões insuficientes para acessar um projeto afetado

Problema: ao visualizar as descobertas no nível da organização ou da pasta, o painel Projetos com descobertas detectadas mostra um indicador de aviso com a mensagem You've insufficient permission to access this project ao lado de um projeto.

Solução: esse problema ocorre se você tem permissões para visualizar o consultor do Storage Intelligence no nível da organização ou da pasta, mas não tem as permissões necessárias do IAM nesse projeto específico. Peça ao administrador do projeto para conceder a você o papel de Administrador do Storage (roles/storage.admin) no projeto afetado.

O consultor do Storage Intelligence está vazio ou faltam dados

Problema: o carregamento de página do consultor do Storage Intelligence, e os gráficos, as métricas na seção Resumo (com o rótulo Resumo do projeto, Resumo da pasta ou Resumo da organização, dependendo do recurso selecionado) ou a seção Principais descobertas estão vazios ou os dados estão desatualizados.

Solução: esse problema pode ocorrer pelos seguintes motivos:

Latência de processamento de dados: as métricas e as descobertas do Storage Intelligence dependem de snapshots diários e da análise do uso do armazenamento. Os dados podem levar de 24 a 48 horas para aparecer no consultor do Storage Intelligence. Esses atrasos geralmente ocorrem depois que você cria novos buckets ou quando acessa o consultor do Storage Intelligence pela primeira vez. Se você espera ver dados de atividade recente, aguarde 48 horas e verifique novamente.
Nenhum recurso de armazenamento: se o projeto, a pasta ou a organização selecionada não tiver buckets ou objetos para o período escolhido, o consultor do Storage Intelligence vai ficar vazio. Escolha outro projeto, pasta ou organização que contenha recursos de armazenamento.
Filtro de tempo incorreto: o filtro de tempo está definido para um intervalo em que não houve atividade de armazenamento. Ajuste o filtro de período para um intervalo que inclua a atividade de armazenamento.

As descobertas não aparecem no consultor do Storage Intelligence

Problema: você espera ver descobertas na seção Principais descobertas com base na atividade de armazenamento recente, mas a seção está vazia.

Solução: esse problema ocorre quando o consultor da Storage Intelligence não gera descobertas para o período selecionado. A falta de descobertas pode ocorrer pelos seguintes motivos:

Nenhum padrão correspondente: o ciclo de análise mais recente não detectou nenhum comportamento de armazenamento que corresponda a um padrão de descoberta.
Atrasos no tratamento de dados: as descobertas dependem de métricas de armazenamento, que levam de 24 a 48 horas para serem processadas. As descobertas de eventos que ocorreram nas últimas 24 horas aparecem após a conclusão do próximo ciclo de processamento.

Problemas ao usar o VPC Service Controls

Problema: você recebe erros de acesso negado ou de permissão ao tentar acessar o consultor do Storage Intelligence em um projeto dentro de um perímetro de serviço do VPC Service Controls.

Solução: esse problema ocorre se o VPC Service Controls não estiver configurado corretamente para permitir a comunicação entre seu projeto, o console do Cloud de Confiance e os recursos do Storage Intelligence. Para resolver esse problema, analise os seguintes requisitos:

Serviços restritos: verifique se o perímetro de serviço restringe a API Cloud Storage (storage.googleapis.com) e a API Storage Insights (storageinsights.googleapis.com). Para mais detalhes, consulte Listar e descrever parâmetros de serviço.
Configuração do perímetro: verifique se o projeto que você está usando para acessar o consultor do Storage Intelligence está no mesmo perímetro de serviço dos projetos que você monitora. Se eles estiverem em perímetros diferentes, será necessário configurar regras de entrada e saída ou usar pontes de perímetro.
Acesso de fora do perímetro: se você acessar o console do Cloud de Confiance em uma rede fora do perímetro, crie uma regra de entrada ou um nível de acesso que inclua sua conta de usuário e o intervalo de endereços IP públicos que você está usando.
VPC compartilhada: se você usa a VPC compartilhada, verifique se o projeto está no mesmo perímetro de serviço que os projetos de serviço. Para mais detalhes, consulte VPC compartilhada.
Registros de auditoria: use o analisador de violações para verificar se há violações do VPC Service Controls nos registros de auditoria. O analisador de violações ajuda a diagnosticar a violação e identificar as causas, como um erro RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.