관리형 컬렉션으로 규칙 및 알림 평가

이 문서에서는 관리형 컬렉션을 사용하는 Managed Service for Prometheus 배포의 규칙과 알림 평가의 구성을 설명합니다.

다음 다이어그램에서는 Google Cloud 프로젝트 2개에서 클러스터를 여러 개 사용하고 규칙 및 알림 평가와 선택적 GlobalRules 리소스를 모두 사용하는 배포를 보여줍니다.

다이어그램과 같이 배포를 설정하고 사용하려면 다음 사항에 유의하세요.

• 관리형 규칙 평가자는 관리형 컬렉션이 실행 중인 모든 클러스터에 자동으로 배포됩니다. 이러한 평가자는 다음과 같이 구성됩니다.

  • 규칙 리소스를 사용하여 네임스페이스 내 데이터에 대한 규칙을 실행합니다. 규칙 리소스는 규칙을 실행할 모든 네임스페이스에 적용되어야 합니다.

  • ClusterRules 리소스를 사용하여 클러스터에서 데이터에 대한 규칙을 실행합니다. ClusterRules 리소스는 클러스터당 한 번씩 적용되어야 합니다.

• 모든 규칙 평가는 전역 데이터 스토어인 Monarch에 대해 실행됩니다.

  • 규칙 리소스는 규칙을 설치된 프로젝트, 위치, 클러스터, 네임스페이스로 자동 필터링합니다.
  • ClusterRules 리소스는 규칙을 설치된 프로젝트, 위치, 클러스터로 자동 필터링합니다.
  • 모든 규칙 결과는 평가 후 Monarch에 기록됩니다.

• Prometheus AlertManager 인스턴스는 모든 단일 클러스터에 수동으로 배포됩니다. 관리형 규칙 평가자는 실행된 알림 규칙을 로컬 AlertManager 인스턴스로 전송하도록 OperatorConfig 리소스를 수정함으로써 구성됩니다. 음소거, 확인, 사고 관리 워크플로는 일반적으로 PagerDuty와 같은 타사 도구에서 처리됩니다.

  Kubernetes 엔드포인트 리소스를 사용하여 여러 클러스터의 알림 관리를 단일 AlertManager 한 곳에서 제어할 수 있습니다.

앞선 다이어그램에서는 선택적 GlobalRules 리소스도 보여줍니다. 여러 프로젝트에서 전역 SLO 계산과 같은 태스크나 단일 Google Cloud 프로젝트 내 클러스터에서 규칙을 평가하는 경우 GlobalRules를 매우 제한적으로 사용합니다. 가능하면 규칙과 ClusterRules를 사용하는 것이 좋습니다. 이러한 리소스는 안정성이 우수하고 일반적인 Kubernetes 배포 메커니즘과 테넌시 모델에 더욱 적합합니다.

GlobalRules 리소스를 사용하는 경우 앞선 다이어그램의 다음 사항에 유의하세요.

• Google Cloud 내에서 실행되는 단일 클러스터 하나가 측정항목 범위의 전역 규칙 평가 클러스터로 지정됩니다. 이 관리형 규칙 평가자는 프로젝트 1과 2가 포함된 scoping_project_A를 사용하도록 구성됩니다. scoping_project_A에 대해 실행된 규칙은 자동으로 프로젝트 1과 2로 팬아웃됩니다.

  기본 서비스 계정에는 scoping_project_A에 대한 Monitoring 뷰어 권한이 부여되어야 합니다. 이러한 필드를 설정하는 방법에 대한 자세한 내용은 멀티 프로젝트 및 전역 규칙 평가를 참조하세요.

• 다른 모든 클러스터와 마찬가지로 이 규칙 평가자는 네임스페이스나 클러스터로 범위가 지정된 규칙을 평가하는 규칙 및 ClusterRules 리소스로 설정됩니다. 이러한 규칙은 자동으로 로컬 프로젝트(이 경우 프로젝트 1)로 필터링됩니다. scoping_project_A에는 프로젝트 1이 포함되어 있으므로 규칙과 ClusterRules로 구성된 규칙은 예상대로 로컬 프로젝트의 데이터에 대해서만 실행됩니다.

• 이 클러스터에는 scoping_project_A에 대해 규칙을 실행하는 GlobalRules 리소스도 있습니다. GlobalRules는 자동으로 필터링되지 않으므로 GlobalRules는 scoping_project_A의 모든 프로젝트, 위치, 클러스터, 네임스페이스에서 작성된 대로 정확하게 실행됩니다.

• 실행된 알림 규칙은 예상대로 자체 호스팅 AlertManager로 전송됩니다.

GlobalRules를 사용하면 규칙의 project_id, location, cluster, namespace 라벨을 보존하거나 집계하는지 여부에 따라 예상치 못한 결과가 발생할 수 있습니다.

• GlobalRules 규칙에서 by(project_id) 절을 사용하여 project_id 라벨을 보존하는 경우 규칙 결과는 기본 시계열의 원래 project_id 값을 통해 Monarch에 다시 기록됩니다.

  이 시나리오에서는 기본 서비스 계정에 scoping_project_A의 각 모니터링 프로젝트에 대한 Monitoring 측정항목 작성자 권한이 있는지 확인해야 합니다. 새 모니터링 프로젝트를 scoping_project_A에 추가하는 경우 수동으로 서비스 계정에 새 권한도 추가해야 합니다.

• GlobalRules 규칙에서project_id 라벨을 사용하는 경우 (by(project_id) 절)를 통해 규칙 결과는 전역 규칙 평가자가 실행되는 클러스터의 project_id 값을 통해 Monarch에 다시 기록됩니다.

  이 시나리오에서는 기본 서비스 계정을 추가로 수정할 필요가 없습니다.

• GlobalRules에서 by(location) 절을 사용하여 location 절을 보존하는 경우 규칙 결과는 기본 시계열이 시작하는 각 원본 Google Cloud 리전을 통해 Monarch에 다시 기록됩니다.

  GlobalRules에서 location 라벨을 보존하지 않는 경우 데이터는 전역 규칙 평가자가 실행 중인 클러스터의 위치에 다시 기록됩니다.

규칙 목적이 이러한 라벨을 집계하는 것이 아니라면 규칙 평가 결과에 cluster 라벨과 namespace 라벨을 보존하는 것이 좋습니다. 그렇지 않으면 쿼리 성능이 저하되고 카디널리티 제한이 발생할 수 있습니다. 두 라벨 모두 제거하지 않는 것이 좋습니다.