Google Cloud 외부에서 실행
클러스터가 Google Cloud 내에서 실행되지 않는 경우 project_id 라벨과 location 라벨의 값을 수동으로 구성해야 합니다. 다음을 수행하는 것이 좋습니다.
이 클러스터가 멀티 테넌트 모니터링 모델에 적합한 방식에 따라
project_id를 설정합니다. 선택한project_id에 대한 올바른 권한으로 서비스 계정을 구성해야 합니다.배포에 가장 가까운 Google Cloud 리전을 기준으로
location을 설정합니다.
라벨 재지정 규칙을 사용하여 이러한 라벨을 다시 작성할 수 없습니다.
조직에 프로젝트가 1,000개 넘게 있음
측정항목 범위에서 지원되는 최대 프로젝트 수는 375개이지만 측정항목 범위에서 지원되지 않는 최대 프로젝트 수는 1,000개입니다.
프로젝트가 1,000개를 넘는 경우 수집기를 실행 중인 프로젝트의 ID 대신 중앙 project_id를 사용하도록 수집기를 구성하는 것이 좋습니다. 그러면 모든 프로젝트의 측정항목이 중앙 프로젝트 ID 아래의 Monarch에 저장되며 중앙 프로젝트를 측정항목 범위에 배치하기만 하면 됩니다.
이 방법을 사용하는 경우 다음과 같은 잠재적 단점이 있습니다.
- 프로젝트 수준별로만 권한을 설정할 수 있으므로 이 작업을 수행하면 멀티테넌시 세분성이 일부 손실됩니다. 프로젝트를 논리적으로 몇 가지 카테고리로 그룹화하고 카테고리마다 서로 다른 중앙 프로젝트를 사용하려고 합니다.
- Google Cloud 시스템 측정항목의
project_id값을 재정의할 수 없습니다. 이 해결 방법을 사용하면 측정항목이 각 원래 프로젝트 내에 유지되므로 중앙 프로젝트에서 무료 Google Kubernetes Engine 측정항목을 확인할 수 없습니다. - 중앙 프로젝트를 사용하면 규칙과 ClusterRules 사용이 복잡해질 수 있습니다. 해당 규칙 범위가 규칙이 설치된 프로젝트로 지정되고 각 프로젝트의 클러스터 이름과 네임스페이스 이름 집합이 같지 않을 수 있기 때문입니다. 대신 GlobalRules를 사용해야 할 수도 있습니다.
단일 Google Cloud 리전에서 수동으로 데이터 배치
기본적으로 Managed Service for Prometheus는 데이터가 시작되는 Google Cloud 리전에 데이터를 저장하고 쿼리가 자연스럽게 전역적입니다. 즉, Google Cloud 리전 여러 개에서 데이터를 쿼리하기 위해 데이터가 지리적으로 같은 위치에 있을 필요는 없습니다.
대부분의 경우 이 기본 동작으로 충분합니다. 그러나 예를 들어 규제가 엄격한 환경에 있는 경우 모든 측정항목 데이터를 단일 Google Cloud 리전에 저장하려는 경우가 있을 수 있습니다.
단일 리전에 모든 측정항목 데이터를 저장하려면 수집기가 실행 중인 클러스터의 자동 감지 위치 대신 단일 location을 사용하도록 구성합니다.
단일 Google Cloud 리전에 데이터를 저장하면 범위는 규칙이 설치된 위치로 지정되고 각 Google Cloud 리전의 클러스터 이름과 네임스페이스 이름 집합이 같지 않으므로 규칙과 ClusterRules 사용이 복잡해질 수 있습니다. 대신 GlobalRules를 사용해야 할 수도 있습니다.