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. Confira se ela atende aos seguintes requisitos:
- Use
locations/global. O Storage Intelligence não oferece suporte a outros locais. - Confira se os nomes de buckets ou expressões regulares em
bucket_id_regexessã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 configuração ou solicitação de atualização, a solicitação 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: confira 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:
Confira 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:
- No Cloud de Confiance console do, acesse a página Buckets do Cloud Storage.
Na lista de buckets, clique no nome do bucket de origem que contém a configuração do relatório de inventário.
Na página Detalhes do bucket, clique na guia Relatórios de inventário.
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.
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.
- No Cloud de Confiance console do, acesse a página Buckets do Cloud Storage.
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 de relatórios 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 são 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 não excede 1.024 bytes. Para mais informações, consulte
Nome do job.
400: parâmetros de transformação conflitantes ou ausentes
Problema: a solicitação de criação de job retorna uma 400 Bad Request (INVALID_ARGUMENT)
resposta com o motivo TRANSFORMATION_NOT_SPECIFIED,
REWRITE_OBJECT_MISSING_PARAMETERS, PUT_OBJECT_HOLD_MISSING_PARAMETERS, ou
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 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 objetos sobrepostos ou duplicados
Problema: a solicitação de criação de job retorna uma 400 Bad Request (INVALID_ARGUMENT)
resposta com o motivo OBJECT_PREFIX_OVERLAP ou DUPLICATE_OBJECT_PREFIX.
Solução: remova os prefixos duplicados e confira 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 400 Bad Request (INVALID_ARGUMENT)
resposta 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 o
motivo BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD,
TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME ou
BUCKET_DISCOVERY_TOO_MANY_BUCKETS.
Solução: verifique se snapshot_time está nas últimas 48 horas, especifique
target_locations para os buckets e confira 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: falha na transformação da classe de armazenamento 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: falha nas atualizações de ACL de objetos 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.s3ns-system.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.
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 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 de erros agregados e verifique o Cloud Logging para registros de erros por objeto. Para mais informações, consulte Conferir 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 filtros CEL, a criação do job falha. A mensagem de erro indica 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 métodos a seguir 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: 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 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 de snapshot: especifique a flag
--target-snapshot-timepara ignorar a falha de obsolescência de dois dias selecionando explicitamente um snapshot no formato RFC 3339. Especifique a flag--target-locationspara 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 filtros CEL falha em projetos recém-inscritos
Problema: a execução de um job de operações em lote do Storage baseado em filtros 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 filtros CEL. Esse atraso permite que o sistema execute o snapshot de metadados inicial e estabeleça o horário de snapshot inicial.
O job de operações em lote do Storage baseado em filtros 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 filtros 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.