En este documento, se describe cómo solucionar problemas comunes con Storage Intelligence, los informes de inventario de Storage Insights, los conjuntos de datos de Storage Insights, y las operaciones de almacenamiento por lotes.
Errores de configuración de Storage Intelligence
En las siguientes secciones, se describen los errores que puedes encontrar cuando configuras o administras Storage Intelligence para un recurso.
400: Nombre de bucket no válido
Problema: La solicitud muestra 400 Bad Request con el mensaje The specified
bucket is not valid.
Solución: La solicitud no es válida. Asegúrate de que la solicitud cumpla con los siguientes requisitos:
- Usa
locations/global. Storage Intelligence no admite otras ubicaciones. - Asegúrate de que los nombres de bucket o las expresiones regulares en
bucket_id_regexessean válidos.
A continuación, se muestra un ejemplo de una solicitud 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./v2/projects/PROJECT_ID/locations/global/intelligenceConfig?updateMask=edition_config,filter"400: Argumento no válido: máscara de actualización vacía
Problema: Cuando envías una solicitud de configuración o actualización, la solicitud muestra
400 Bad Request con el mensaje Empty UPDATE_MASK in the request.
Solución: Proporciona un UPDATE_MASK no vacío en tu solicitud. UPDATE_MASK
especifica una lista separada por comas de
FieldMask
campos en el recurso
IntelligenceConfig para
actualizar (como updateMask=edition_config o
updateMask=edition_config,filter).
400: Ruta de máscara de actualización no válida
Problema: Cuando se actualiza una configuración, la solicitud muestra 400 Bad Request
con el mensaje Invalid UPDATE_MASK paths.
Solución: Verifica que cada nombre de campo en UPDATE_MASK coincida con un campo válido
en el recurso IntelligenceConfig.
400: El campo no se puede editar
Problema: Cuando se actualiza una configuración, la solicitud muestra 400 Bad Request
con el mensaje Invalid UPDATE_MASK: UPDATE_TIME field is not editable.
Solución: Quita los campos del sistema no editables (como UPDATE_TIME) de
UPDATE_MASK. Solo especifica los campos mutables definidos en
IntelligenceConfig.
400: Valor no válido
Problema: La solicitud muestra 400 Bad Request con el mensaje Invalid value
at storage_intelligence.edition_config.
Solución: Establece edition_config en un valor admitido: INHERIT,
STANDARD, o DISABLED.
400: Filtro no vacío
Problema: La solicitud muestra 400 Bad Request con el mensaje Non-empty
filter cannot be specified for INHERIT or DISABLED edition configuration.
Solución: Quita los filtros de bucket de la solicitud. Los filtros de bucket
no se admiten cuando edition_config se establece en INHERIT o DISABLED.
400: Valores de ubicación o bucket vacíos en el filtro
Problema: La solicitud muestra 400 Bad Request con el mensaje Empty
location or bucket values in filter.
Solución: Asegúrate de que ni location ni bucket sean cadenas vacías en
tu filtro de bucket.
Problemas comunes de Storage Insights
En esta sección, se describe cómo resolver problemas comunes con los informes de inventario y los conjuntos de datos.
Se generan varios informes de inventario a diario
Problema: Una configuración de informes de inventario genera varios archivos de informes cada día.
Solución: Cloud Storage fragmenta los informes de inventario para buckets con más de 1,000,000 de objetos, lo que genera un fragmento por cada 1,000,000 de objetos. Por ejemplo, un bucket con 3,500,000 objetos genera cuatro fragmentos de informes y un archivo de manifiesto que enumera cada fragmento.
Los informes de inventario no aparecen en el bucket de destino
Problema: Los informes de inventario no aparecen en el bucket de destino.
Solución: Si los informes no se entregan al bucket de destino, verifica lo siguiente:
Asegúrate de que haya pasado la fecha de inicio configurada. Para obtener más información, consulta Crea una configuración de informes de inventario.
Consulta el historial de informes de inventario para verificar las fallas y sus causas raíz. Para ver su historial de informes de inventario, siga estos pasos:
- En la Google Cloud consola, ve a la página Buckets de Cloud Storage.
En la lista de buckets, haz clic en el nombre del bucket de origen que contiene la configuración del informe de inventario.
En la página Detalles del bucket, haz clic en la pestaña Inventory reports.
En la lista de opciones de configuración de informes de inventario, haz clic en el UUID de la configuración de informes de inventario que generó los informes que deseas verificar.
Verifica si hay fallas en la sección Historial de informes de inventario. Puedes mantener el puntero sobre Ayuda () para obtener detalles sobre el motivo por el que se produjo un error.
- En la Google Cloud consola, ve a la página Buckets de Cloud Storage.
Asegúrate de que se otorguen al agente de servicio a nivel de proyecto los roles de IAM necesarias para leer y escribir informes de inventario. Para obtener más información, consulta Otorga roles necesarios al agente de servicio.
Demoras en los informes de inventario
Problema: Se retrasa la generación de informes de inventario.
Solución: Los tiempos de generación de informes varían. Las demoras de hasta 24 horas son normales.
Los conjuntos de datos no se propagan
Problema: Las tablas de conjuntos de datos de Storage Insights permanecen vacías.
Solución: En tu conjunto de datos de BigQuery vinculado, consulta
error_attributes_view para obtener códigos de error. Para obtener más información, consulta
Soluciona errores de conjuntos de datos.
Valores nulos en la columna "ref" cuando se consultan conjuntos de datos
Problema: Cuando se consultan conjuntos de datos de Storage Insights en BigQuery, la
ref columna muestra null.
Solución: Para los objetos que terminan en /, la columna ref de los conjuntos de datos es nula.
Si la columna ref muestra valores nulos cuando consultas conjuntos de datos de Storage Insights
en BigQuery, verifica que hayas otorgado los permisos y roles de conexión necesarios, incluido el acceso a los recursos de Cloud Storage, como se describe en Analiza datos y metadatos de objetos con
BigQuery.
Errores de validación de trabajos de operaciones de almacenamiento por lotes
En esta sección, se describen los errores de validación que se producen cuando se envía una solicitud de trabajo de operaciones por lotes a storagebatchoperations.googleapis.com.
400: ID de trabajo o nombre de recurso no válidos
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request (INVALID_ARGUMENT)
con el motivo JOB_ID_INVALID o RESOURCE_NAME_TOO_LONG.
Solución: Verifica que el ID de trabajo conste de 1 a 63 caracteres alfanuméricos en minúscula
o guiones ([a-z0-9]([-a-z0-9]*[a-z0-9])?) y que la ruta de acceso completa del
recurso no supere los 1,024 bytes. Para obtener más información, consulta
Nombre del trabajo.
400: Parámetros de transformación en conflicto o faltantes
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request (INVALID_ARGUMENT)
con el motivo TRANSFORMATION_NOT_SPECIFIED,
REWRITE_OBJECT_MISSING_PARAMETERS, PUT_OBJECT_HOLD_MISSING_PARAMETERS, o
PUT_METADATA_MISSING_PARAMETERS.
Solución: Especifica exactamente un tipo de transformación con todos los parámetros necesarios. Si configuras la retención de objetos, verifica que Object Lock esté habilitado en el bucket y que las marcas de tiempo usen el formato RFC 3339 UTC. Para obtener más información sobre los requisitos de parámetros por transformación, consulta Tipo de trabajo.
400: Prefijos de objetos superpuestos o duplicados
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request (INVALID_ARGUMENT)
con el motivo OBJECT_PREFIX_OVERLAP o DUPLICATE_OBJECT_PREFIX.
Solución: Quita los prefijos duplicados y asegúrate de que ningún prefijo en
included_object_prefixes sea un prefijo de otra entrada en la lista. Para obtener más
información, consulta Prefijos de objetos.
400: Problemas de formato y acceso a archivos de manifiesto
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request (INVALID_ARGUMENT)
con el motivo MANIFEST_LOCATION_REQUIRED o MANIFEST_LOCATION_INVALID,
o el trabajo no puede leer el manifiesto.
Solución: Verifica que el URI del manifiesto sea una ruta de acceso CSV válida
(gs://<bucket_name>/<path>/<object_name>.csv) y que el
agente de servicio de operaciones de almacenamiento por lotes tenga el rol roles/storage.objectViewer
en el bucket de manifiesto. Para obtener más información sobre los requisitos de formato y
esquema de CSV, consulta Manifiesto.
400: Errores de descubrimiento de conjuntos de datos de Storage Insights
Problema: El uso de un conjunto de datos de Storage Insights para el descubrimiento de objetos muestra una respuesta
400 Bad Request (INVALID_ARGUMENT o FAILED_PRECONDITION) con el
motivo BUCKET_DISCOVERY_SNAPSHOT_TOO_OLD,
TARGET_LOCATIONS_REQUIRED_FOR_SNAPSHOT_TIME o
BUCKET_DISCOVERY_TOO_MANY_BUCKETS.
Solución: Verifica que snapshot_time esté dentro de las últimas 48 horas, especifica
target_locations para los buckets y asegúrate de que la consulta de descubrimiento no
coincida con más de 1,000 buckets. Para obtener más información, consulta Crea un manifiesto con
conjuntos de datos de Storage Insights.
400: Falla la transformación de la clase de almacenamiento en buckets habilitados para Autoclass
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request
(FAILED_PRECONDITION) con el motivo
AUTOCLASS_STORAGE_CLASS_TRANSFORMATION_UNSUPPORTED.
Solución: No puedes ejecutar transformaciones de clase de almacenamiento en buckets con Autoclass habilitada. Dirige a un bucket sin Autoclass o quita la transformación de la clase de almacenamiento. Para obtener más información, consulta Restricciones de Autoclass.
400: Fallan las actualizaciones de la LCA de objetos en buckets de acceso uniforme a nivel de bucket
Problema: La solicitud de creación de trabajo muestra una respuesta 400 Bad Request
(FAILED_PRECONDITION) con el motivo
UBLA_OBJECT_ACL_UPDATE_UNSUPPORTED.
Solución: No puedes actualizar las LCA de objetos en buckets con el acceso uniforme a nivel de bucket habilitado. En su lugar, administra el acceso con roles de IAM a nivel de bucket o proyecto. Para obtener más información, consulta Acceso uniforme a nivel de bucket.
Problemas de tiempo de ejecución y ejecución de operaciones de almacenamiento por lotes
En esta sección, se describen los problemas que se producen durante la ejecución asíncrona de un trabajo de operaciones por lotes.
403: Errores de permisos durante la ejecución
Problema: Un trabajo por lotes falla durante la ejecución con 403 Forbidden
(PERMISSION_DENIED).
Solución: Otorga al agente de servicio de operaciones de almacenamiento por lotes
(service-PROJECT_NUMBER@gcp-sa-storagebatchoperations.)
los roles de IAM necesarios para tu tipo de transformación. Para obtener más
información, consulta Otorga permisos al agente de servicio.
Errores de encriptación de CMEK durante la reescritura de objetos
Problema: Las reescrituras de objetos fallan con 400 Bad Request o 403 Forbidden debido al
estado de la clave de Cloud KMS o a errores de permisos.
Solución: Verifica que la clave de Cloud KMS esté Enabled y resida en
la misma región que el bucket de destino, y que el agente de servicio tenga el
roles/cloudkms.cryptoKeyEncrypterDecrypter rol. Para obtener más información, consulta
Tipo de trabajo: Reescritura de objetos.
Alto recuento de fallas en error_summaries
Problema: Un trabajo por lotes se completa con un counters.failed_object_count
y códigos de error en error_summaries (como 404 NOT_FOUND, 412
FAILED_PRECONDITION o 403 PERMISSION_DENIED).
Solución: Ejecuta gcloud storage batch-operations jobs describe con la
--location marca (por ejemplo,
gcloud storage batch-operations jobs describe JOB_ID --location=LOCATION) para
ver el desglose de errores agregados y consulta Cloud Logging para obtener registros de errores por objeto. Para obtener más información, consulta Obtén detalles del trabajo.
El trabajo de operaciones de almacenamiento por lotes falla debido a una instantánea de más de dos días
Problema: Cuando creas un trabajo de operaciones de almacenamiento por lotes basado en filtros de CEL, falla la creación del trabajo. El mensaje de error indica que la hora de la instantánea es anterior a dos días.
Solución: Para evitar acciones en estados de objetos desactualizados, las operaciones de almacenamiento por lotes fallan automáticamente en la creación de trabajos. Esta falla se produce si la instantánea seleccionada tiene más de dos días. Selecciona uno de los siguientes métodos para resolver este problema:
- Usa un archivo de manifiesto: Consulta tu conjunto de datos de forma manual en BigQuery. Exporta los resultados a un archivo de manifiesto CSV y sube el archivo a un bucket de Cloud Storage. Luego, puedes crear el trabajo de operaciones por lotes con el método de manifiesto para evitar el límite de dos días.
- Verifica las configuraciones del conjunto de datos: Verifica que las configuraciones del conjunto de datos estén activas y no en pausa. Confirma que las instantáneas del conjunto de datos se ejecuten correctamente. Para obtener información sobre cómo verificar tus configuraciones, consulta Visualiza la configuración de un conjunto de datos.
- Usa anulaciones de ubicación de destino y hora de instantánea: Especifica la marca
--target-snapshot-timepara omitir la falla de obsolescencia de dos días. Para ello, selecciona de forma explícita una instantánea en formato RFC 3339. Especifica la marca--target-locationspara limitar la operación a las ubicaciones en las que existe la instantánea. Puedes usar estas anulaciones para resolver las demoras de sincronización que impiden que se actualice la instantánea global automatizada. En consecuencia, puedes orientar de forma manual una instantánea regional más reciente. Para obtener la sintaxis del comando, consulta Crea un trabajo con filtros avanzados.
Falla el trabajo de operaciones de almacenamiento por lotes basado en filtros de CEL en proyectos recién suscritos
Problema: La ejecución de un trabajo de operaciones de almacenamiento por lotes basado en filtros de CEL en un proyecto recién suscrito falla porque el sistema no puede encontrar una instantánea válida.
Solución: Después de habilitar la suscripción a Storage Intelligence, debes esperar 24 horas antes de ejecutar trabajos de operaciones de almacenamiento por lotes basados en filtros de CEL. Esta demora permite que el sistema realice la instantánea de metadatos inicial y establezca la hora de la instantánea inicial.
Falla el trabajo de operaciones de almacenamiento por lotes basado en filtros de CEL con errores de permisos o arroja errores de tiempo de ejecución
Problema: Un trabajo de operaciones de almacenamiento por lotes basado en filtros de CEL falla durante la ejecución o muestra errores de permisos de tiempo de ejecución.
Solución: Las operaciones de almacenamiento por lotes usan tus credenciales de usuario para procesar objetos. El trabajo falla si no tienes los permisos de lector o escritor de IAM necesarios en los buckets y objetos de destino. Este problema se produce cuando los filtros de CEL seleccionan recursos a los que no tienes acceso. Confirma que tu cuenta tenga los roles de administrador de almacenamiento (roles/storage.admin), administrador de objetos de almacenamiento (roles/storage.objectAdmin) o roles equivalentes para todos los buckets y objetos en el alcance del trabajo. Si deseas obtener instrucciones para otorgar roles, consulta Usa permisos de IAM.
Supervisión y análisis de registros
Para obtener más información sobre cómo inspeccionar las fallas de ejecución por objeto y las cargas útiles de errores en Cloud Logging, consulta Visualiza registros de operaciones de almacenamiento por lotos.