Resolver problemas do Storage Intelligence

Este documento descreve como solucionar problemas comuns com o Storage Intelligence, os relatórios de inventário do Storage Insights, os conjuntos de dados do Storage Insights, e as operações em lote do Storage.

Erros de configuração do Storage Intelligence

As seções a seguir descrevem 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 ela atende aos seguintes requisitos:

  • Use locations/global. O Storage Intelligence não oferece suporte a outros locais.
  • Verifique se os nomes de buckets ou expressões regulares em bucket_id_regexes são válidos.

Confira a seguir 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.googleapis.com/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 configuração ou solicitação de atualização, ela retorna 400 Bad Request com a mensagem Empty UPDATE_MASK in the request.

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

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

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 campos de 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 está definido como INHERIT ou DISABLED.

400: valores de local ou bucket 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 em seu filtro de bucket.

Problemas comuns do Storage Insights

Esta seção descreve 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 por dia.

Solução: o Cloud Storage fragmenta relatórios de inventário para buckets com mais de 1 milhão de objetos, gerando um fragmento por milhão 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.

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 Google Cloud console do, 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.

Conjuntos de dados não estão sendo preenchidos

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

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

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

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

Solução: para objetos que terminam em /, a coluna ref em 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 validação de jobs de operações em lote do Storage

Esta seção descreve 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 do job 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 do job 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 do job (projects/PROJECT_ID/locations/LOCATION/jobs/JOB_ID) não excede 200 bytes. Se o caminho exceder 200 bytes, encurte o ID do job. Para mais informações, consulte Nome do job.

400: a descrição do job 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 exceder esse limite, encurte o texto. Para mais informações, consulte Descrição do job.

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

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com 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 operações em lote jobs.

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 Diretrizes de nomenclatura de bucket e Diretrizes de nomenclatura de objeto.

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

Problema: a solicitação de criação de job retorna uma resposta 400 Bad Request (INVALID_ARGUMENT) com 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 de origem do projeto atende aos requisitos de formatação e exclusividade de campo. Se você especificar um ID de job 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) com 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 necessários. Se você estiver configurando a retenção de objetos, verifique se o Object Lock 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 objetos 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 e acesso a arquivos de manifesto

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 roles/storage.objectViewer papel no bucket de manifesto. Para mais informações sobre os requisitos de formatação e esquema de CSV, consulte Manifesto.

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

Problema: o uso de um conjunto de dados do Storage Insights para descoberta de objetos retorna uma 400 Bad Request (INVALID_ARGUMENT ou FAILED_PRECONDITION) resposta com 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 verifique se a consulta de descoberta corresponde a no máximo 1.000 buckets. Para mais informações, consulte Criar um manifesto usando conjuntos de dados do Storage Insights.

400: a transformação da classe de armazenamento falha em buckets ativados pela classe automática

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. Escolha 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: as atualizações de ACL de objetos falham 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. 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 execução e de tempo de 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.iam.gserviceaccount.com) os papéis do IAM necessários para o tipo de transformação. Para mais informações, consulte Conceder permissões ao agente de serviço.

Erros de criptografia CMEK durante a regravação de objetos

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

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

Contagem alta de falhas em error_summaries

Problema: um job em lote é concluído com um counters.failed_object_count diferente de zero e códigos de 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 --location flag (por exemplo, gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION) para conferir o detalhamento agregado de erros e verifique o Cloud Logging para registros de erros por objeto. Para mais informações, consulte Receber detalhes do job.

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

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

Solução: para evitar ações em estados de objetos 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 seguintes métodos para resolver esse problema:

  • Usar um arquivo de manifesto: consulte o conjunto de dados manualmente no BigQuery. Exporte os resultados para um arquivo de manifesto CSV e faça o upload do arquivo 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.
  • Verificar as configurações do conjunto de dados: verifique 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 corretamente. Para informações sobre como verificar as configurações, consulte Conferir uma configuração de conjunto de dados.
  • Usar substituições de local de destino e horário do snapshot: especifique a flag --target-snapshot-time para ignorar a falha de obsolescência 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 de 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ções em lote do Storage baseado em filtro CEL falha em projetos recém-inscritos

Problema: a execução de um job de operações em lote do Storage baseado em 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 execute o snapshot de metadados inicial e estabeleça o horário de início do snapshot.

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

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

Solução: as operações em lote do Storage usam suas credenciais de usuário para processar objetos. O job falha se você não tiver as permissões necessárias de leitor ou gravador do IAM nos buckets e objetos segmentados. Esse problema ocorre quando os filtros CEL selecionam recursos aos quais você não tem acesso. Confirme se sua conta tem o papel de Administrador do Storage (roles/storage.admin), Administrador de objetos do Storage (roles/storage.objectAdmin) ou papéis 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 Conferir registros de operações em lote do Storage.

Problemas do consultor do Storage Intelligence

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

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 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 uma lista das permissões necessárias, consulte Papéis necessários.

Permissões insuficientes para visualizar um projeto afetado

Problema: ao visualizar 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ê tiver permissões para visualizar o consultor do Storage Intelligence no nível da organização ou da pasta, mas não tiver as permissões do IAM necessárias 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 os dados estão ausentes

Problema: a página do consultor do Storage Intelligence é carregada, e os gráficos, as métricas na seção Em resumo (rotulada como Projeto em resumo, Pasta em resumo ou Organização em resumo, dependendo do recurso selecionado) ou a seção Principais descobertas estão vazias ou os dados estão desatualizados.

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

  • Latência de tratamento de dados: as métricas e 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 normalmente ocorrem depois que você cria novos buckets ou quando visualiza o consultor do Storage Intelligence pela primeira vez. Se você espera ver dados de atividades recentes, aguarde 48 horas e verifique novamente.
  • Nenhum recurso de armazenamento: se o projeto, a pasta ou a organização selecionada não contiver buckets ou objetos para o período selecionado, o consultor do Storage Intelligence estará vazio. Escolha um projeto, uma pasta ou uma organização diferente que contenha recursos de armazenamento.
  • Filtro de tempo incorreto: o filtro de tempo está definido para um período em que nenhuma atividade de armazenamento ocorreu. Ajuste o filtro de tempo para um período que inclua a atividade de armazenamento.

As descobertas não estão aparecendo 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 se o consultor do Storage Intelligence não gerar 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 tratadas. As descobertas de eventos que ocorreram nas últimas 24 horas aparecem após a conclusão do próximo ciclo de tratamento.

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 de 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 o projeto, o Google Cloud console do Google Cloud e os recursos do Storage Intelligence. Para resolver esse problema, revise 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 visualizar 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, você deve configurar regras de entrada e saída ou usar pontes de perímetro.
  • Acesso de fora do perímetro: se você acessar o Google Cloud console de 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ê usar a VPC compartilhada, verifique se o projeto está no mesmo perímetro de serviço dos 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 causas, como um erro RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

A seguir