Puedes volver a aprovisionar un bucket de observabilidad para satisfacer los requisitos reglamentarios de residencia y
encriptación de datos. Después de volver a aprovisionar, la ubicación de almacenamiento
y la configuración de encriptación del bucket _Trace coinciden con la configuración predeterminada de los buckets de observabilidad.
Para volver a aprovisionar un bucket, establece la configuración predeterminada y, luego, llama al método de reaprovisionamiento. La operación de reaprovisionamiento puede realizar cualquiera de las siguientes acciones:
- Aplica de forma retroactiva una clave de Cloud Key Management Service a un bucket de observabilidad sin cambiar su ubicación de almacenamiento.
- Cambiar la ubicación de almacenamiento de un bucket de observabilidad y usar la encriptación predeterminada de Google
- Cambiar la ubicación de almacenamiento de un bucket de observabilidad y usar una clave de Cloud KMS para encriptar los datos almacenados
No vuelvas a aprovisionar un bucket de observabilidad cuando quieras cambiar su nombre visible, descripción o clave de Cloud KMS. En esos casos, actualiza el bucket de observabilidad.
Cómo funciona el reaprovisionamiento
Cuando inicias una operación de reaprovisionamiento, el sistema realiza los siguientes pasos:
El sistema determina si el bucket de observabilidad es apto para el reaprovisionamiento. Un bucket de observabilidad es apto cuando se aprueban todas las siguientes verificaciones:
- El bucket de observabilidad se llama
_Trace. - No se volvió a aprovisionar el bucket.
- Se encuentra la configuración predeterminada para los buckets de observabilidad.
- Para que coincida con la configuración predeterminada, la ubicación del bucket de observabilidad debe cambiar o la encriptación debe cambiar de la encriptación predeterminada de Google a CMEK.
- El bucket de observabilidad se llama
El sistema actualiza la configuración del bucket. Este proceso tarda entre cuatro y cinco horas.
Limitaciones
Se aplica la siguiente limitación:
El sistema permite, como máximo, una operación de reaprovisionamiento por bucket de observabilidad. Las solicitudes posteriores fallan con un error
FAILED_PRECONDITION.Solo puedes volver a aprovisionar los buckets llamados
_Trace.No puedes acceder a ningún dato que se haya almacenado antes de que se iniciara el reaprovisionamiento. Se borraron estos datos y no se pueden recuperar.
Si cambia la ubicación del bucket, se borrarán los vínculos y los conjuntos de datos de BigQuery vinculados. Debes volver a crear los vínculos.
Si cambia la ubicación del bucket, debes actualizar de forma manual las vistas de análisis existentes.
No puedes cancelar ni deshacer una operación de reaprovisionamiento. Se ignoran los intentos de cancelar la operación.
El comportamiento de las consultas durante una operación de reaprovisionamiento no está definido.
Auditoría
Para determinar el historial de reaprovisionamiento de un bucket de observabilidad, puedes usar tus registros de auditoría. Los registros de actividad del administrador registran quién realizó una solicitud de reaprovisionamiento, el bucket de observabilidad afectado y la respuesta inicial.
Para encontrar estos registros, aplica los siguientes filtros en el Explorador de registros:
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity" AND
resource.type="audited_resource" AND
resource.labels.service="observability.googleapis.com" AND
resource.labels.method="google.cloud.observability.v1.Observability.ReprovisionBucket"
En el siguiente ejemplo parcial, se muestra un registro de auditoría de actividad del administrador:
{
"logName": "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity",
"resource": {
"type": "audited_resource",
"labels": {
"project_id": "PROJECT_ID",
"service": "observability.googleapis.com",
"method": "google.cloud.observability.v1.Observability.ReprovisionBucket"
}
},
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"status": {
"code": 0,
"message": "OK"
},
...
"serviceName": "observability.googleapis.com",
"methodName": "google.cloud.observability.v1.Observability.ReprovisionBucket",
"authorizationInfo": [...]
"resourceName": "projects/PROJECT_ID/locations/us/buckets/_Trace",
"request": {
"@type": "type.googleapis.com/google.cloud.observability.v1.ReprovisionBucketRequest",
"name": "projects/PROJECT_ID/locations/us/buckets/_Trace"
},
"response": {
"@type": "type.googleapis.com/google.longrunning.Operation",
"name": "projects/PROJECT_ID/locations/us/operations/reprovision-123456789-0",
"done": false,
"metadata": {
"@type": "type.googleapis.com/google.cloud.observability.v1.OperationMetadata",
"target": "projects/PROJECT_ID/locations/us/buckets/_Trace",
"verb": "reprovision",
"apiVersion": "v1"
}
}
},
"severity": "NOTICE",
"timestamp": "2026-06-30T16:54:02.123456Z"
}
Antes de comenzar
- Revisa las limitaciones.
-
Para obtener los permisos que necesitas para volver a aprovisionar un bucket de observabilidad, pídele a tu administrador que te otorgue el rol de IAM de editor de observabilidad (
roles/observability.editor) en el proyecto que aloja tu bucket de observabilidad. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.El rol de editor de observabilidad proporciona permisos para crear y borrar buckets de observabilidad, conjuntos de datos de observabilidad y vínculos en conjuntos de datos. Necesitas estos permisos porque la operación de reaprovisionamiento emite comandos de creación y eliminación.
También puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.
Vuelve a aprovisionar un bucket de observabilidad
Para volver a aprovisionar un bucket de observabilidad, sigue estos pasos:
- Establece la configuración predeterminada para los buckets de observabilidad
- Vuelve a aprovisionar el bucket
- Supervisa el progreso
- Crea vínculos y actualiza vistas de análisis de forma manual
Establece la configuración predeterminada para los buckets de observabilidad
Establece una ubicación de almacenamiento predeterminada y, de manera opcional, una clave de Cloud KMS predeterminada. Puedes establecerlas a nivel de organización, proyecto o carpeta. Por ejemplo, si estableces la configuración predeterminada para una carpeta, los descendientes de esa carpeta usarán esa configuración, a menos que un descendiente también tenga una configuración predeterminada establecida.
Para obtener más información sobre cómo ver y establecer la configuración predeterminada, consulta Establece la configuración predeterminada para los buckets de observabilidad.
Vuelve a aprovisionar el bucket
Usa secuencias de comandos que emitan la solicitud de reaprovisionamiento de forma asíncrona y sondea para
determinar cuándo se completa la operación de reaprovisionamiento. Para volver a aprovisionar un
bucket de observabilidad, usa el
método
projects.locations.buckets.reprovision.
Debes especificar el nombre del bucket de observabilidad, que tiene el siguiente formato:
projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
Los campos de la expresión anterior tienen los siguientes significados:
- PROJECT_ID: Es el identificador del proyecto.
- LOCATION: Es la ubicación del bucket de observabilidad.
- BUCKET_ID: Es el ID del bucket de observabilidad. Este ID debe ser
_Trace.
La respuesta es un objeto Operation. El campo Operation.done proporciona información sobre el progreso:
doneesfalse: La operación está en curso. Para obtener información sobre cómo sondear la operación, consulta Supervisa el progreso.doneestrue: La operación se completó y se estableció el campoerrororesponse:Se establece
response: Indica que la operación asíncrona se completó correctamente. El valor refleja el estado más reciente del bucket de observabilidad que era el destino de reaprovisionamiento.Se establece
error: Indica que falló la operación asíncrona. El valor de este campo es un objetoStatusque contiene un código de error de gRPC y un mensaje de error. Para obtener información sobre los mensajes de error comunes, consulta Mensajes de error.
Por lo general, el reaprovisionamiento tarda entre cuatro y cinco horas en completarse.
Supervisa el progreso
El objeto Operation contiene información sobre el progreso.
Sondea la operación hasta que el valor del campo Operation.done sea true.
Luego, puedes usar los campos Operation.response y Operation.error
para determinar si el reaprovisionamiento se realizó correctamente o falló.
Para sondear el Operation, usa el
método folders.locations.operations.get.
Establece el parámetro de ruta en el nombre de la operación:
operations/UNIQUE_ID
El campo UNIQUE_ID es el identificador único de la operación.
La respuesta es un objeto Operation actualizado.
Si tu aplicación recibe una respuesta HTTP 503 / UNAVAILABLE
cuando realiza un sondeo, implementa una retirada exponencial y vuelve a intentar
la solicitud. Este error indica que la solicitud falló en la capa de transporte o
de red.
Crea vínculos y actualiza vistas de análisis de forma manual
Una vez que se complete la operación de reaprovisionamiento, vuelve a crear los vínculos y actualiza tus vistas de análisis.
Por ejemplo, puedes hacer lo siguiente:
Enumera los vínculos en el conjunto de datos de observabilidad. En algunas situaciones, la operación de reaprovisionamiento conserva los vínculos. Para obtener información sobre este paso, consulta Enumera los vínculos de un conjunto de datos.
Vuelve a crear el conjunto de datos de BigQuery vinculado. Para obtener información sobre este paso, consulta Crea un vínculo en un conjunto de datos.
Revisa tus vistas de análisis y actualiza la ruta de acceso al bucket de observabilidad según sea necesario.
Mensajes de error
En esta sección, se enumeran los códigos de error comunes y, cuando corresponde, las acciones de recuperación.
FAILED_PRECONDITION
El mensaje de error FAILED_PRECONDITION indica que el bucket de observabilidad no es apto para el reaprovisionamiento.
Ejemplo de mensaje de error:
{
"error":{
"code": 400,
"message": "Only _Trace buckets can be reprovisioned.",
"status": "FAILED_PRECONDITION",
"details": [ ... ]
}
}
No hay ninguna acción que puedas realizar para que el bucket de observabilidad sea apto para el reaprovisionamiento.
INVALID_ARGUMENT
El mensaje de error INVALID_ARGUMENT indica que la ubicación del bucket de observabilidad y la configuración de CMEK son coherentes con la configuración predeterminada de los buckets de observabilidad.
Para resolver este error, actualiza la configuración predeterminada de los buckets de observabilidad del proyecto, la carpeta o la organización y, luego, vuelve a aprovisionar el bucket de observabilidad.
PERMISSION_DENIED
El mensaje de error PERMISSION_DENIED indica que no tienes
los roles de IAM necesarios para volver a aprovisionar un bucket de observabilidad.
Para resolver este error, pídele a un administrador que te otorgue los roles de IAM que se indican en la sección Antes de comenzar de este documento.
Soluciona problemas
En esta sección, se describe cómo resolver problemas habituales y responder preguntas que pueden surgir después de volver a aprovisionar un bucket de observabilidad.
¿Cómo sé si se volvió a aprovisionar un bucket?
Consulta tus registros de auditoría y filtra las entradas de registro por el nombre del registro, el servicio y el método. Para obtener más información, consulta la sección de este documento titulada Auditoría.
¿Por qué mi proyecto incluye dos buckets para los datos de seguimiento?
Durante un reaprovisionamiento del bucket de observabilidad _Trace, es posible que el sistema deba
crear un bucket nuevo. Cuando esto sea verdadero, tu proyecto contendrá dos
buckets de observabilidad llamados _Trace durante la operación de reaprovisionamiento.
Si enumeras los buckets de observabilidad en tu proyecto, ambos buckets se informan en los resultados.
Si usas Estadísticas de observabilidad para consultar tus datos de seguimiento, hay una vista de
_AllSpansdisponible para ambos buckets.
No es necesario que realices ninguna acción.
Si el sistema creó un bucket de observabilidad como parte de una operación de reaprovisionamiento, una vez que se complete correctamente esa operación, se borrará el bucket de destino de la operación. Si la operación de reaprovisionamiento falla, se borra el bucket nuevo.
¿Por qué mis datos consultados son diferentes después de volver a aprovisionar?
Una operación de reaprovisionamiento borra todos los datos que se almacenaron antes de que se iniciara la operación. Estos datos no se pueden recuperar.
¿Por qué el Explorador de seguimiento no muestra ningún dato después de volver a aprovisionar?
El Explorador de seguimiento usa la caché para mejorar el rendimiento. La caché está vinculada al bucket de observabilidad que se consulta y, lo que es más importante, si ese bucket no está disponible en el momento de una consulta, esta falla.
Durante una operación de reaprovisionamiento, es posible que tu proyecto de Google Cloud contenga
dos buckets de observabilidad llamados _Trace. Además, cuando se completa esa operación, se borra uno de esos buckets. En esta situación, es posible
que la caché que usa el Explorador de Trace esté vinculada a un bucket que
ya no existe.
Esta falla se corrige automáticamente después de que se agota el tiempo de espera de la caché, lo que requiere alrededor de 10 minutos.
¿Por qué no se puede volver a aprovisionar mi bucket de observabilidad?
Si una operación de reaprovisionamiento falla con un estado FAILED_PRECONDITION, el
bucket de observabilidad de destino no es apto para el reaprovisionamiento. A continuación,
se enumeran algunos motivos por los que un bucket no es apto para el reaprovisionamiento:
- El bucket de observabilidad no se llama
_Trace. - La cantidad de veces que se volvió a aprovisionar el bucket de observabilidad supera una. Puedes consultar tus registros de auditoría para determinar si se volvió a aprovisionar el bucket.
- No se encuentra la configuración predeterminada para los buckets de observabilidad. Para resolver este error, establece la configuración predeterminada de los buckets de observabilidad y, luego, vuelve a ejecutar el comando.
- La configuración del bucket de observabilidad coincide con la configuración predeterminada. Es decir, la operación de reaprovisionamiento no cambiará la configuración del bucket de observabilidad.
- Para que coincida con la configuración predeterminada, el sistema tendría que reemplazar la CMEK por la encriptación administrada por Google. No se admite esta acción.