Cloud Trace 데이터는 모니터링 가능성 버킷에서 관리하는 모니터링 가능성 데이터 세트에 저장됩니다. 스토리지 모델을 이해하면 trace 데이터가 저장되는 위치를 제어하고, 암호화 정책을 적용하고, 모니터링 가능성 분석 및 BigQuery에서 제공하는 분석 서비스에 원격 분석을 연결할 수 있습니다.
BigQuery 를 사용하여 trace 데이터를 분석하는 방법에 대한 자세한 내용은 연결된 BigQuery 데이터 세트 만들기를 참조하세요.
모니터링 가능성 스토리지 모델
Observability API 스토리지 모델은 다음 아키텍처를 기반으로 합니다.
- 모니터링 가능성 버킷
- 모니터링 가능성 버킷은 데이터를 저장하는 데이터 세트의 관리 항목입니다. 모니터링 가능성 버킷은 특정 위치에 있으며 데이터 보관 정책이 있습니다. 서비스에서 Google Cloud
모니터링 가능성 API를 사용하여 데이터를 저장하면 시스템은 서비스 이름, 데이터를 저장할
데이터 세트, 저장된 데이터에 대한 읽기 액세스 권한을 제공하는 뷰를 기반으로
모니터링 가능성 버킷을 만듭니다.
예를 들어 Cloud Trace 서비스의 경우 시스템은
시스템에서 만든 버킷의 이름을
_Trace, 데이터 세트의 이름을Spans, 뷰의 이름을_AllSpans로 지정합니다. 모니터링 가능성 버킷의 구조에 대한 자세한 내용은Bucket을 참조하세요. - 데이터 세트
- 데이터 세트는 데이터를 저장합니다. 시스템은 데이터 세트를 관리하는 모니터링 가능성 버킷을 만들 때 데이터 세트 하나를 자동으로 만듭니다. 예를 들어 시스템이
_Trace버킷을 만들 때 trace 데이터를 저장하는Spans라는 데이터 세트도 만듭니다. 데이터 세트의 구조 에 대한 자세한 내용은Dataset을 참조하세요. - 데이터 세트의 뷰
- 각 데이터 세트는 하나 이상의 뷰를 호스팅합니다. 뷰 는 데이터 세트의 항목 하위 집합에 대한 읽기 액세스 권한을 제공합니다. 시스템은 데이터 세트를 만들 때 뷰 하나를 만듭니다. 이 뷰에는 데이터 세트의 모든 데이터가 포함됩니다.
뷰의 이름은 서비스에 따라 다릅니다. 예를 들어
Cloud Trace 서비스의 경우 시스템은
_AllSpansSpans데이터 세트에 뷰를 만듭니다. 뷰의 구조에 대한 자세한 내용은View를 참조하세요. - 데이터 세트의 링크
각 데이터 세트는 최대 하나의 링크를 포함할 수 있습니다. 데이터 세트의 링크 를 만들면 시스템은 연결된 BigQuery 데이터 세트를 만듭니다. 그런 다음 BigQuery 또는 BigQuery API를 사용하는 다른 서비스를 사용하여 데이터 세트의 데이터를 쿼리할 수 있습니다. 링크의 구조에 대한 자세한 내용은
Link를 참조하세요.시스템은 데이터 세트에 링크를 자동으로 만들지 않습니다.
trace 데이터의 스토리지 구성
trace 데이터는 _Trace라는 모니터링 가능성 버킷에서 관리하는 데이터 세트에 저장됩니다. 데이터 세트를 보관하려면 _Trace 버킷이 있어야 합니다.
_Trace 버킷은 자동으로 또는 수동으로 만들 수 있습니다.
자동 생성: 시스템은 애플리케이션 또는 서비스 Google Cloud 에서 trace 데이터를 수신하는 것에 대한 응답으로 버킷을 자동으로 만듭니다. 시스템은 모니터링 가능성 버킷에 적용 가능한 기본 설정을 사용하여 버킷의 위치와 암호화 키를 결정합니다. 기본 설정을 정의하지 않은 경우 시스템은 지원되는 위치를 선택하고 버킷은 Google 기본 암호화를 사용합니다.
Cloud Run 함수, Cloud Run, App Engine에서 생성된 trace 데이터는 시스템에서 모니터링 가능성 버킷을 만들도록 하지 않습니다. 이러한 서비스의 스팬은 모니터링 가능성 버킷이 있는 경우에만 저장됩니다.
수동 생성: Observability API를 사용하여
_Trace버킷을 만들기 전에 Google Cloud 프로젝트에서 trace 데이터를 수신할 수 있습니다. 버킷의 위치를 제공해야 합니다. Cloud Key Management Service 키를 제공할 수 있습니다.- 키를 제공하면 시스템은 해당 키를 사용하여 저장된 데이터를 암호화합니다.
- Cloud KMS 키를 제공하지 않으면 버킷의 상위 리소스에 적용되는 기본 설정에 따라 암호화 키가 결정됩니다. 기본 설정에서 Cloud KMS 키를 지정하면 해당 키가 저장된 데이터를 암호화합니다. 그렇지 않으면 Google 기본 암호화가 사용됩니다.
_Trace 버킷이 생성되면 시스템은 버킷의
Spans라는 데이터 세트와 데이터 세트의 _AllSpans라는 뷰도 만듭니다. 이 뷰에는 데이터 세트의 모든 데이터가 포함됩니다.
자세한 내용은 다음을 참조하세요.
trace 데이터가 Trace 탐색기 페이지에 표시되면 _Trace라는 모니터링 가능성 버킷이 있는 것입니다. 데이터가 표시되지 않거나 스토리지가 초기화되지 않았다는 배너가 표시되면 다음 중 하나를 시도해 보세요.
모니터링 가능성 버킷의 데이터 레지던시
특정 위치에 데이터를 저장하거나 고객 관리 암호화 키 (CMEK)를 사용해야 하는 규정 준수 또는 규제 요구사항이 있는 경우 조직 정책과 모니터링 가능성 버킷의 기본 설정을 모두 구성하는 것이 좋습니다.
조직, 폴더, 프로젝트의 경우 모니터링 가능성 버킷의 기본 설정을 사용하면 다음을 구성할 수 있습니다.
- 기본 스토리지 위치
- 각 위치의 기본 Cloud Key Management Service 키
시스템에서 기본 설정을 사용하는 방법에는 두 가지가 있습니다.
시스템이 모니터링 가능성 버킷을 자동으로 만들 때 기본 설정을 사용하여 버킷의 위치와 암호화 키를 결정합니다. 기본 설정을 정의하지 않은 경우 시스템은 위치를 선택하고 버킷은 Google 기본 암호화를 사용합니다.
API 요청을 실행하여 모니터링 가능성 버킷 생성을 시작할 때 위치를 제공합니다. 그러나 API 요청의 인수가 키를 지정하지 않는 한 시스템은 기본 설정에 정의된 Cloud KMS 키를 사용하여 데이터를 자동으로 암호화합니다.
모니터링 가능성 버킷의 상위 항목은 항상 프로젝트이므로 버킷을 만들 때 시스템은 먼저 프로젝트 수준 기본 설정을 검색합니다. 이러한 설정이 없으면 시스템은 상위 항목의 상위 항목에서 기본 설정을 검색합니다. 예를 들어 폴더의 기본 설정을 정의하면 기본 설정이 구성된 하위 항목을 제외하고 해당 설정이 폴더의 하위 항목에 적용됩니다.
조직 정책을 사용하여 새 모니터링 가능성 버킷의 위치를 제한하거나, CMEK 사용을 요구하거나, 암호화에 사용할 수 있는 Cloud KMS 키를 제한할 수도 있습니다. CMEK 사용을 요구하는 조직 정책을 구성하는 경우 모니터링 가능성 버킷의 기본 설정을 구성해야 합니다. 그렇지 않으면 시스템에서 만든 모니터링 가능성 버킷의 프로비저닝이 실패합니다.
자세한 내용은 모니터링 가능성 버킷의 기본값 설정을 참조하세요.제한사항
다음은 수행할 수 없습니다.
- 모니터링 가능성 버킷 수정 또는 삭제
- 데이터 세트 생성, 삭제 또는 수정
- 뷰 생성, 삭제 또는 수정
- Google Cloud 콘솔을 사용하여 버킷, 데이터 세트, 뷰 또는 링크 나열