데이터 레지던시 및 암호화 규제 요구사항을 충족하도록 모니터링 가능성 버킷을 다시 프로비저닝할 수 있습니다. 다시 프로비저닝하면 _Trace 버킷의 스토리지 위치와 암호화 구성이 모니터링 가능성 버킷의 기본 설정과 일치합니다.
버킷을 다시 프로비저닝하려면 기본 설정을 구성한 후 다시 프로비저닝 메서드를 호출합니다. 재프로비저닝 작업은 다음 중 하나를 수행할 수 있습니다.
- 스토리지 위치를 변경하지 않고 Cloud Key Management Service 키를 모니터링 가능성 버킷에 소급 적용합니다.
- 모니터링 가능성 버킷의 스토리지 위치를 변경하고 Google 기본 암호화를 사용합니다.
- 모니터링 가능성 버킷의 스토리지 위치를 변경하고 Cloud KMS 키를 사용하여 저장된 데이터를 암호화합니다.
모니터링 가능성 버킷의 표시 이름, 설명 또는 Cloud KMS 키를 변경하려는 경우 모니터링 가능성 버킷을 다시 프로비저닝하지 마세요. 이러한 경우 모니터링 가능성 버킷을 업데이트합니다.
재프로비저닝 작동 방식
재프로비저닝 작업을 시작하면 시스템에서 다음 단계를 수행합니다.
시스템은 모니터링 가능성 버킷이 다시 프로비저닝할 수 있는지 여부를 결정합니다. 모니터링 가능성 버킷은 다음 검사를 모두 통과하면 사용할 수 있습니다.
- 모니터링 가능성 버킷의 이름은
_Trace입니다. - 버킷이 다시 프로비저닝되지 않았습니다.
- 모니터링 가능성 버킷의 기본 설정이 발견됩니다.
- 기본 설정과 일치하려면 모니터링 가능성 버킷의 위치를 변경하거나 암호화를 Google 기본 암호화에서 CMEK로 변경해야 합니다.
- 모니터링 가능성 버킷의 이름은
시스템이 버킷 구성을 업데이트합니다. 이 프로세스는 4~5시간이 걸립니다.
제한사항
다음과 같은 제한사항이 적용됩니다.
시스템은 모니터링 가능성 버킷당 최대 1회의 재프로비저닝 작업을 허용합니다. 후속 요청은
FAILED_PRECONDITION오류와 함께 실패합니다.이름이
_Trace인 버킷만 다시 프로비저닝할 수 있습니다.재프로비저닝이 시작되기 전에 저장된 데이터에는 액세스할 수 없습니다. 이 데이터는 삭제되었으며 복구할 수 없습니다.
버킷의 위치가 변경되면 링크와 연결된 BigQuery 데이터 세트가 삭제됩니다. 링크를 다시 만들어야 합니다.
버킷의 위치가 변경되면 기존 분석 뷰를 수동으로 업데이트해야 합니다.
재프로비저닝 작업은 취소하거나 실행취소할 수 없습니다. 작업을 취소하려는 시도는 무시됩니다.
재프로비저닝 작업 중 쿼리 동작은 정의되지 않습니다.
감사
모니터링 가능성 버킷의 재프로비저닝 내역을 확인하려면 감사 로그를 사용하면 됩니다. 관리자 활동 로그에는 재프로비저닝 요청을 한 사용자, 영향을 받는 모니터링 가능성 버킷, 초기 응답이 기록됩니다.
이러한 레코드를 찾으려면 로그 탐색기에서 다음 필터를 적용합니다.
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"
다음 부분 예시에서는 관리자 활동 감사 로그를 보여줍니다.
{
"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"
}
시작하기 전에
- 제한사항을 검토합니다.
-
모니터링 가능성 버킷을 다시 프로비저닝하는 데 필요한 권한을 얻으려면 관리자에게 모니터링 가능성 버킷을 호스팅하는 프로젝트에 대한 모니터링 가능성 편집자(
roles/observability.editor) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.모니터링 가능성 편집자 역할은 모니터링 가능성 버킷, 모니터링 가능성 데이터 세트, 데이터 세트의 링크를 만들고 삭제할 수 있는 권한을 제공합니다. 재프로비저닝 작업은 생성 및 삭제 명령어를 모두 실행하므로 이러한 권한이 필요합니다.
모니터링 가능성 버킷 다시 프로비저닝
모니터링 가능성 버킷을 다시 프로비저닝하려면 다음 단계를 수행합니다.
모니터링 가능성 버킷의 기본 설정 구성
기본 스토리지 위치를 설정하고 선택적으로 기본 Cloud KMS 키를 설정합니다. 프로젝트, 폴더 또는 조직 수준에서 설정할 수 있습니다. 예를 들어 폴더의 기본 설정을 구성하면 하위 요소에도 기본 설정이 구성되어 있지 않는 한 해당 폴더의 하위 요소는 해당 설정을 사용합니다.
기본 설정을 보고 구성하는 방법에 대한 자세한 내용은 모니터링 가능성 버킷의 기본값 설정을 참조하세요.
버킷 다시 프로비저닝
재프로비저닝 요청을 비동기식으로 실행하고 폴링하여 재프로비저닝 작업이 완료되는 시점을 확인하는 스크립트를 사용합니다. 모니터링 가능성 버킷을 다시 프로비저닝하려면 projects.locations.buckets.reprovision 메서드를 사용합니다.
모니터링 가능성 버킷의 이름을 지정해야 합니다. 이 이름은 다음 형식입니다.
projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID
이전 표현식의 필드는 다음과 같은 의미를 갖습니다.
- PROJECT_ID: 프로젝트 식별자
- LOCATION: 모니터링 가능성 버킷의 위치입니다.
- BUCKET_ID: 모니터링 가능성 버킷의 ID입니다. 이 ID는
_Trace여야 합니다.
응답은 Operation 객체입니다. Operation.done 필드는 진행 상황 정보를 제공합니다.
done이false인 경우: 작업이 진행 중입니다. 작업 폴링에 대한 자세한 내용은 진행 상황 모니터링을 참조하세요.done이true인 경우: 작업이 완료되고error또는response필드가 설정됩니다.response가 설정됨: 비동기 작업이 성공적으로 완료되었음을 나타냅니다. 이 값은 다시 프로비저닝 대상이었던 모니터링 가능성 버킷의 최신 상태를 반영합니다.error가 설정됨: 비동기 작업이 실패했음을 나타냅니다. 이 필드의 값은 gRPC 오류 코드 및 오류 메시지를 포함하는Status객체입니다. 일반적인 오류 메시지에 대한 자세한 내용은 오류 메시지를 참조하세요.
재프로비저닝을 완료하는 데 일반적으로 4~5시간이 걸립니다.
진행 상황 모니터링 .
Operation 객체에는 진행 상황 정보가 포함됩니다.
Operation.done 필드 값이 true가 될 때까지 작업을 폴링합니다.
그런 다음 Operation.response 및 Operation.error 필드를 사용하여 다시 프로비저닝이 성공했는지 또는 실패했는지 확인할 수 있습니다.
Operation를 폴링하려면 folders.locations.operations.get 메서드를 사용합니다.
경로 매개변수를 작업 이름으로 설정합니다.
operations/UNIQUE_ID
UNIQUE_ID 필드는 작업의 고유 식별자입니다.
응답은 업데이트된 Operation 객체입니다.
폴링 시 애플리케이션이 HTTP 503 / UNAVAILABLE 응답을 수신하면 지수 백오프를 구현하고 요청을 다시 시도합니다. 이 오류는 전송 또는 네트워크 계층에서 요청이 실패했음을 나타냅니다.
수동으로 링크 만들기 및 분석 뷰 업데이트
재프로비저닝 작업이 완료되면 링크를 다시 만들고 분석 뷰를 업데이트합니다.
예를 들어 다음과 같이 수행할 수 있습니다.
모니터링 가능성 데이터 세트의 링크를 나열합니다. 일부 시나리오에서는 다시 프로비저닝 작업이 링크를 유지합니다. 이 단계에 대한 자세한 내용은 데이터 세트의 링크 나열을 참조하세요.
연결된 BigQuery 데이터 세트를 다시 만듭니다. 이 단계에 대한 자세한 내용은 데이터 세트에 링크 만들기를 참조하세요.
분석 뷰를 검토하고 필요에 따라 모니터링 가능성 버킷 경로를 업데이트합니다.
오류 메시지
이 섹션에는 일반적인 오류 코드와 해당하는 경우 복구 작업이 나와 있습니다.
FAILED_PRECONDITION
FAILED_PRECONDITION 오류 메시지는 모니터링 가능성 버킷을 다시 프로비저닝할 수 없음을 나타냅니다.
오류 메시지 예시:
{
"error":{
"code": 400,
"message": "Only _Trace buckets can be reprovisioned.",
"status": "FAILED_PRECONDITION",
"details": [ ... ]
}
}
모니터링 가능성 버킷을 다시 프로비저닝할 수 있도록 하기 위해 수행할 수 있는 작업은 없습니다.
INVALID_ARGUMENT
INVALID_ARGUMENT 오류 메시지는 모니터링 가능성 버킷의 위치와 CMEK 구성이 모니터링 가능성 버킷의 기본 설정과 일치함을 나타냅니다.
이 오류를 해결하려면 프로젝트, 폴더 또는 조직의 모니터링 가능성 버킷에 대한 기본 설정을 업데이트한 후 모니터링 가능성 버킷 다시 프로비저닝을 다시 시도합니다.
PERMISSION_DENIED
PERMISSION_DENIED 오류 메시지는 모니터링 가능성 버킷을 다시 프로비저닝하는 데 필요한 IAM 역할이 없음을 나타냅니다.
이 오류를 해결하려면 관리자에게 이 문서의 시작하기 전에 섹션에 나열된 IAM 역할을 부여해 달라고 요청하세요.
문제 해결
이 섹션에서는 모니터링 가능성 버킷을 다시 프로비저닝한 후 발생할 수 있는 일반적인 문제를 해결하고 질문에 답변하는 방법을 설명합니다.
버킷이 다시 프로비저닝되었는지 어떻게 알 수 있나요?
감사 로그를 쿼리하고 로그 이름, 서비스, 메서드로 로그 항목을 필터링합니다. 자세한 내용은 이 문서의 감사 섹션을 참조하세요.
프로젝트에 trace 데이터의 버킷이 두 개 나열되는 이유는 무엇인가요?
_Trace 모니터링 가능성 버킷을 다시 프로비저닝하는 동안 시스템에서 새 버킷을 만들어야 할 수 있습니다. 이 값이 true이면 재프로비저닝 작업 중에 프로젝트에 _Trace라는 모니터링 가능성 버킷이 두 개 포함됩니다.
프로젝트의 모니터링 가능성 버킷을 나열하면 두 버킷이 모두 결과에 보고됩니다.
모니터링 가능성 분석을 사용하여 trace 데이터를 쿼리하는 경우 두 버킷 모두에
_AllSpans뷰를 사용할 수 있습니다.
별도로 취해야 할 조치는 없습니다.
시스템이 재프로비저닝 작업의 일부로 모니터링 가능성 버킷을 만든 경우 해당 작업이 성공적으로 완료되면 작업의 대상이 되는 버킷이 삭제됩니다. 재프로비저닝 작업이 실패하면 새 버킷이 삭제됩니다.
다시 프로비저닝한 후 쿼리한 데이터가 다른 이유는 무엇인가요?
재프로비저닝 작업은 작업이 시작되기 전에 저장된 모든 데이터를 삭제합니다. 이 데이터는 복구할 수 없습니다.
다시 프로비저닝한 후 Trace 탐색기에 데이터가 표시되지 않는 이유는 무엇인가요?
Trace 탐색기는 캐시를 사용하여 성능을 향상시킵니다. 캐시는 쿼리되는 모니터링 가능성 버킷에 연결되며, 중요한 점은 쿼리 시점에 해당 버킷을 사용할 수 없으면 쿼리가 실패한다는 것입니다.
재프로비저닝 작업 중에 Google Cloud 프로젝트에 _Trace라는 모니터링 가능성 버킷이 두 개 포함될 수 있습니다. 또한 작업이 완료되면 해당 버킷 중 하나가 삭제됩니다. 이 시나리오에서는 Trace 탐색기에서 사용하는 캐시가 더 이상 존재하지 않는 버킷에 연결될 수 있습니다.
이 오류는 캐시가 타임아웃된 후 자체 수정되며 약 10분이 소요됩니다.
모니터링 가능성 버킷을 다시 프로비저닝할 수 없는 이유는 무엇인가요?
재프로비저닝 작업이 FAILED_PRECONDITION 상태로 실패하면 대상 모니터링 가능성 버킷은 재프로비저닝할 수 없습니다. 다음은 버킷이 다시 프로비저닝할 수 없는 몇 가지 이유를 보여줍니다.
- 모니터링 가능성 버킷의 이름이
_Trace가 아닙니다. - 모니터링 가능성 버킷이 다시 프로비저닝된 횟수가 1회를 초과합니다. 감사 로그를 쿼리하여 버킷이 다시 프로비저닝되었는지 확인할 수 있습니다.
- 모니터링 가능성 버킷의 기본 설정을 찾을 수 없습니다. 이 오류를 해결하려면 모니터링 가능성 버킷의 기본 설정을 구성한 후 명령어를 다시 시도합니다.
- 모니터링 가능성 버킷의 구성은 기본 설정과 일치합니다. 즉, 다시 프로비저닝 작업은 모니터링 가능성 버킷의 구성을 변경하지 않습니다.
- 기본 설정과 일치하려면 시스템에서 CMEK를 Google 관리 암호화로 바꿔야 합니다. 지원되지 않는 작업입니다.