자체 배포 컬렉션 시작하기

이 문서에서는 자체 배포 컬렉션에 Google Cloud Managed Service for Prometheus를 설정하는 방법을 설명합니다. 여기에서는 예시 애플리케이션을 Kubernetes 클러스터에 배포하고 Monarch에서 수집된 측정항목을 저장하는 Prometheus 서버로 이를 모니터링합니다.

이 문서에서는 다음을 수행하는 방법을 보여줍니다.

  • 환경 및 명령줄 도구를 설정합니다.
  • GKE 지원 클러스터의 워크로드 아이덴티티 제휴에 대한 서비스 계정을 구성합니다.
  • Kubernetes에서 드롭인 Prometheus 바이너리를 실행합니다.
  • Managed Service for Prometheus에 수집되는 측정항목을 제어합니다.
  • Managed Service for Prometheus를 prometheus-operator 설정과 통합합니다.
  • Prometheus 바이너리를 수동으로 컴파일하고 실행합니다.

자체 배포 데이터 컬렉션을 사용하여 항상 하던대로 Prometheus 설치를 관리합니다. 유일한 차이점은 업스트림 Prometheus 바이너리 대신 Prometheus 삽입형 대체 기능 바이너리 gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0을 사용한다는 것입니다.

드롭인 바이너리는 --export.* 플래그와 함께 추가적인 구성 옵션을 제공합니다. 자세한 내용은 --help 옵션의 출력을 참조하세요. 이 문서에서는 가장 중요한 옵션들만 설명합니다.

Managed Service for Prometheus는 페더레이션 서버 또는 원격 쓰기 수신자로 사용되는 서버에서 측정항목 내보내기를 지원하지 않습니다. 필터 및 로컬 집계를 사용하여 Monarch로 전송하기 전 데이터를 집계하여 수집 볼륨을 줄이는 등 모든 페더레이션 서버 기능을 복제할 수 있습니다.

Managed Service for Prometheus로 데이터를 스트리밍하려면 추가 리소스가 사용됩니다. 자체 배포 수집기의 경우 CPU 및 메모리 한도를 5배로 늘리고 실제 사용량에 맞게 조정하는 것이 좋습니다.

관리 및 자체 배포 데이터 컬렉션에 대한 자세한 내용은 Managed Service for Prometheus에서 데이터 수집을 참조하세요.

시작하기 전에

이 섹션에서는 이 문서에 설명된 태스크에 필요한 구성에 대해 설명합니다.

프로젝트 및 도구 설정

Google Cloud Managed Service for Prometheus를 사용하려면 다음 리소스가 필요합니다.

  • Cloud Monitoring API가 사용 설정된 Google Cloud 프로젝트가 필요합니다.

    • Google Cloud 프로젝트가 없으면 다음을 수행합니다.

      1. Google Cloud 콘솔에서 새 프로젝트로 이동합니다.

        새 프로젝트 만들기

      2. 프로젝트 이름 필드에서 프로젝트 이름을 입력한 후 만들기를 클릭합니다.

      3. 결제로 이동:

        결제로 이동

      4. 페이지 상단에서 아직 선택하지 않았으면 바로 전에 만든 프로젝트를 선택합니다.

      5. 기존 결제 프로필을 선택하거나 새 결제 프로필을 만들라는 메시지가 표시됩니다.

      Monitoring API는 새 프로젝트에 대해 기본적으로 사용 설정됩니다.

    • Google Cloud 프로젝트가 이미 있으면 Monitoring API가 사용 설정되었는지 확인합니다.

      1. API 및 서비스로 이동합니다.

        API 및 서비스로 이동

      2. 프로젝트를 선택합니다.

      3. API 및 서비스 사용 설정을 클릭합니다.

      4. 'Monitoring'을 검색합니다.

      5. 검색 결과에서 'Cloud Monitoring API'를 클릭합니다.

      6. 'API 사용 설정'이 표시되지 않으면 사용 설정 버튼을 클릭합니다.

  • Kubernetes 클러스터가 필요합니다. Kubernetes 클러스터가 없으면 GKE 빠른 시작 안내를 따르세요.

또한 다음 명령줄 도구가 필요합니다.

  • gcloud
  • kubectl

gcloud 및 kubectl 도구는 Google Cloud CLI의 일부입니다. 설치에 대한 자세한 내용은 Google Cloud CLI 구성요소 관리를 참조하세요. 설치한 gcloud CLI 구성요소를 보려면 다음 명령어를 실행하세요.

gcloud components list

환경 구성

프로젝트 ID 또는 클러스터 이름을 반복해서 입력하지 않으려면 다음 구성을 수행합니다.

  • 다음과 같이 명령줄 도구를 구성합니다.

    • Google Cloud 프로젝트의 ID를 참조하도록 gcloud CLI를 구성합니다.

      gcloud config set project PROJECT_ID

    • 클러스터를 사용하도록 kubectl CLI를 구성합니다.

      kubectl config set-cluster CLUSTER_NAME

    이러한 도구에 대한 자세한 내용은 다음을 참조하세요.

네임스페이스 설정

예시 애플리케이션의 일부로 만드는 리소스에 대해 NAMESPACE_NAME Kubernetes 네임스페이스를 만듭니다.

kubectl create ns NAMESPACE_NAME

서비스 계정 사용자 인증 정보 확인

Kubernetes 클러스터에 GKE용 워크로드 아이덴티티 제휴가 사용 설정되어 있으면 이 섹션을 건너뛸 수 있습니다.

GKE에서 실행될 때 Managed Service for Prometheus는 Compute Engine 기본 서비스 계정을 기반으로 환경에서 사용자 인증 정보를 자동으로 검색합니다. 기본적으로 기본 서비스 계정에는 필요한 권한 monitoring.metricWriter 및 monitoring.viewer가 있습니다. GKE용 워크로드 아이덴티티 제휴를 사용하지 않고 이전에 기본 노드 서비스 계정에서 이러한 역할 중 하나를 삭제한 경우 계속하기 전에 누락된 권한을 다시 추가해야 합니다.

GKE에서 실행하지 않는 경우 명시적으로 사용자 인증 정보 제공을 참조하세요.

GKE용 워크로드 아이덴티티 제휴에 대한 서비스 계정 구성

Kubernetes 클러스터에 GKE용 워크로드 아이덴티티 제휴가 사용 설정되지 않은 경우 이 섹션을 건너뛸 수 있습니다.

Managed Service for Prometheus는 Cloud Monitoring API를 사용하여 측정항목 데이터를 캡처합니다. 클러스터에서 GKE용 워크로드 아이덴티티 제휴를 사용하는 경우 Kubernetes 서비스 계정에 Monitoring API에 대한 권한을 부여해야 합니다. 이 섹션에서는 다음을 설명합니다.

서비스 계정 만들기 및 바인딩

이 단계는 Managed Service for Prometheus 문서의 여러 위치에 표시됩니다. 이미 이전 태스크를 수행하는 동안 이 단계를 수행했으면 이를 반복할 필요가 없습니다. 서비스 계정 승인으로 건너뛰세요.

다음 명령어 시퀀스는 gmp-test-sa 서비스 계정을 만들고 NAMESPACE_NAME 네임스페이스의 기본 Kubernetes 서비스 계정에 바인딩합니다.

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

다른 GKE 네임스페이스 또는 서비스 계정을 사용하는 경우 적절하게 명령어를 조정합니다.

서비스 계정 승인

관련 권한 그룹이 역할에 수집되고 주 구성원(이 예시에서는 Google Cloud 서비스 계정)에 역할을 부여합니다. 모니터링 역할에 대한 자세한 내용은 액세스 제어를 참조하세요.

다음 명령어는 Google Cloud 서비스 계정 gmp-test-sa에 측정항목 데이터 쓰기에 필요한 Monitoring API 역할을 부여합니다.

이미 이전 태스크를 수행하는 동안 Google Cloud 서비스 계정에 특정 역할을 부여한 경우 이를 다시 수행할 필요가 없습니다.

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

GKE용 워크로드 아이덴티티 제휴 구성 디버그

GKE용 워크로드 아이덴티티 제휴가 작동하지 않는 경우 GKE용 워크로드 아이덴티티 제휴 설정 확인 문서와 GKE용 워크로드 아이덴티티 제휴 문제 해결 가이드를 참조하세요.

GKE용 워크로드 아이덴티티 제휴를 구성할 때 오타 및 부분 복사-붙여넣기가 가장 일반적인 오류 소스이므로 이 안내의 코드 샘플에 삽입된 수정 가능한 변수 및 클릭 가능한 복사-붙여넣기 아이콘을 사용하는 것이 좋습니다.

프로덕션 환경의 GKE용 워크로드 아이덴티티 제휴

이 문서에 설명된 예시에서는 Google Cloud 서비스 계정을 기본 Kubernetes 서비스 계정에 바인딩하고 Google Cloud 서비스 계정에 Monitoring API를 사용하기 위해 필요한 모든 권한을 부여합니다.

프로덕션 환경에서는 각 구성요소에 대해 서비스 계정이 있고, 각각 최소 권한이 포함된 세분화된 방법을 사용해야 할 수 있습니다. 워크로드 아이덴티티 관리를 위한 서비스 계정 구성에 대한 자세한 내용은 GKE용 워크로드 아이덴티티 제휴 사용을 참조하세요.

자체 배포 컬렉션 설정

이 섹션에서는 자체 배포 컬렉션을 사용하는 예시 애플리케이션을 설정하고 실행하는 방법을 설명합니다.

예시 애플리케이션 배포

예시 애플리케이션은 metrics 포트에서 example_requests_total 카운터 측정항목 및 example_random_numbers 히스토그램 측정항목을 내보냅니다. 애플리케이션의 매니페스트에는 세 개의 복제본이 정의되어 있습니다.

예시 애플리케이션을 배포하려면 다음 명령어를 실행합니다.

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml

대체 Prometheus 바이너리 실행

예시 애플리케이션에서 내보낸 측정항목 데이터를 수집하려면 워크로드의 측정항목과 자체 측정항목 엔드포인트를 스크래핑하도록 구성된 Google의 Prometheus 서버의 포크된 버전을 배포합니다.

  1. 포크된 서버를 배포하려면 다음 명령어를 실행합니다.

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/prometheus.yaml

    배포된 이 Prometheus 서버는 업스트림 Prometheus 바이너리의 씬 포크입니다. 표준 Prometheus 서버와 같이 작동하지만 또한 Managed Service for Prometheus로 데이터를 수집합니다.

    위 매니페스트에서는 데이터를 전역 데이터 스토어인 Monarch로 전송하는 기본 작업 예시를 제공합니다. 데이터의 로컬 복사본을 영구 저장하지 않습니다. 이 사전 정의된 구성의 작동 방법과 이를 확장하는 방법은 오픈소스 Prometheus 구성 문서를 참조하세요.

    사전 빌드된 이미지는 Linux 노드에서만 작동합니다. Windows 노드에서 실행되는 대상을 스크래핑하려면 Linux 노드에 서버를 배포하고, Windows 노드에서 엔드포인트를 스크래핑하도록 구성하거나 자체적으로 Windows용 바이너리를 빌드합니다.

  2. Prometheus 서버 및 예시 애플리케이션에 대해 포드가 성공적으로 배포되었는지 확인합니다.

    kubectl -n NAMESPACE_NAME get pod

    배포가 성공했으면 출력이 다음과 비슷하게 표시됩니다.

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

GKE에서 실행하는 경우 다음을 수행할 수 있습니다.

GKE 외부에서 실행하는 경우 다음 섹션의 설명에 따라 서비스 계정을 만들고 측정항목 데이터를 기록하도록 승인해야 합니다.

명시적으로 사용자 인증 정보 제공

GKE에서 실행할 경우 수집 Prometheus 서버가 노드의 서비스 계정 또는 GKE용 워크로드 아이덴티티 제휴 설정을 기준으로 환경에서 사용자 인증 정보를 자동으로 검색합니다. 비GKE Kubernetes 클러스터에서는 플래그 또는 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 수집 Prometheus 서버에 사용자 인증 정보를 명시적으로 제공해야 합니다.

  1. 컨텍스트를 대상 프로젝트에 설정합니다.

    gcloud config set project PROJECT_ID

  2. 서비스 계정을 만듭니다.

    gcloud iam service-accounts create gmp-test-sa

    이 단계에서는 GKE용 워크로드 아이덴티티 제휴 안내에 따라 이미 생성되었을 수 있는 서비스 계정을 만듭니다.

  3. 서비스 계정에 필요한 권한을 부여합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. 서비스 계정에 대해 키를 만들고 다운로드합니다.

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. 키 파일을 비GKE 클러스터에 보안 비밀로 추가합니다.

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. 수정을 위해 Prometheus StatefulSet 리소스를 엽니다.

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. 굵게 표시된 텍스트를 리소스에 추가합니다.

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    2. 파일을 저장하고 편집기를 닫습니다. 변경사항이 적용되고 포드가 다시 생성된 후 제공된 서비스 계정을 사용하여 측정항목 백엔드에 대해 인증을 시작합니다.

    또는 이 예시에 설정된 플래그를 사용하는 대신 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 키-파일 경로를 설정할 수 있습니다.

    자체 배포 컬렉션의 추가 주제

    이 섹션에서는 다음 작업을 수행하는 방법을 설명합니다.

    • 관리형 서비스로 내보내는 데이터를 필터링합니다.
    • 기존 배포 구성을 변환합니다.
    • 고가용성 모드에서 Prometheus 바이너리를 실행합니다.
    • 대체 Prometheus 바이너리를 빌드하고 실행합니다.
    • Google Cloud 외부에서 Prometheus용 관리형 서비스를 실행합니다.

    내보낸 측정항목 필터링

    많은 데이터를 수집하는 경우 비용 절감을 위해 일부 시계열이 Managed Service for Prometheus에 전송되지 않도록 방지해야 할 수 있습니다.

    Prometheus 스크래핑 구성에서 일반 측정항목 레이블 재지정 구성을 사용할 수 있습니다. 레이블 재지정 구성을 사용하면 수집 시 레이블 일치에 따라 측정항목을 삭제할 수 있습니다.

    일부 경우에는 데이터를 로컬로 수집하더라도 이를 Managed Service for Prometheus로 내보내지 않아야 할 수 있습니다. 내보낸 측정항목을 필터링하려면 --export.match 플래그를 사용하면 됩니다.

    이 플래그는 PromQL 시리즈 선택기를 한 개 이상 지정하며 플래그는 여러 번 사용할 수 있습니다. 시계열이 플래그 중 하나 이상에 있는 모든 선택기를 충족하는 경우 시계열은 Prometheus용 관리형 서비스로 내보내집니다. 즉, 자격요건을 확인할 때 단일 플래그 내의 조건은 ANDed이고 개별 플래그의 조건은 ORed입니다. 다음 예시에서는 플래그의 2개 인스턴스가 사용됩니다.

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    이러한 변경에 따라 작업 수준으로 집계되는(권장사항 이름 지정을 따르는 경우) 규칙을 기록하여 생성되는 측정항목뿐만 아니라 'prometheus' 작업에 대한 측정항목만 내보내집니다. 다른 모든 계열의 샘플은 필터링됩니다. 기본적으로 선택기는 지정되지 않고 모든 시계열이 내보내집니다.

    --export.match 플래그는 Prometheus 페더레이션에 대해 match[] 매개변수와 동일한 시맨틱스를 갖습니다. 따라서 Prometheus 서버의 플래그가 페더레이션 Prometheus 서버에서 스크래핑될 때 페더레이션 서버에서 직접 선택기를 사용하여 Managed Service for Prometheus로 페더레이션 설정을 마이그레이션할 수 있습니다. 페더레이션 서버에서 관리형 서비스로 측정항목 내보내기는 지원되지 않습니다.

    필터에 histogram 유형의 측정항목을 포함하려면 _count, _sum, _bucket 측정항목을 지정해야 합니다. 또한 와일드 카드 일치자로 이를 수행할 수 있습니다. 예를 들어 {__name__=~"histogram_metric_.+"} 선택기가 있습니다.

    prometheus-operator 라이브러리를 사용하는 경우 컨테이너의 EXTRA_ARGS 환경 변수를 사용하여 모든 --export.match 플래그를 설정합니다. 자세한 내용은 prometheus-operator와 함께 사용을 참조하세요.

    필터 플래그를 로컬로 실행되는 레코딩 규칙과 조합해서 Monarch로 전송하기 전 데이터를 '롤업'해서 카디널리티 및 비용을 줄입니다. 자세한 내용은 비용 관리 및 기여 분석을 참조하세요.

    Cloud Monitoring 측정항목 관리 페이지에서는 관측 가능성에 영향을 주지 않고 청구 가능 측정항목에 지출하는 금액을 제어할 수 있는 정보를 제공합니다. 측정항목 관리 페이지에서는 다음 정보를 보고합니다.

    • 측정항목 도메인 및 개별 측정항목의 바이트 기반 및 샘플 기반 청구에 대한 수집량
    • 측정항목의 라벨 및 카디널리티에 대한 데이터
    • 각 측정항목 읽기 수입니다.
    • 알림 정책 및 커스텀 대시보드의 측정항목 사용
    • 측정항목 쓰기 오류의 비율

    또한 측정항목 관리를 사용하면 불필요한 측정항목을 제외하여 수집 비용을 절감할 수 있습니다. 측정항목 관리 페이지에 대한 자세한 내용은 측정항목 사용량 보기 및 관리를 참조하세요.

    prometheus-operator 사용

    Managed Service for Prometheus 바이너리는 prometheus-operator로 관리되는 기존 GKE Prometheus 배포에도 사용될 수 있습니다.

    관리형 서비스의 바이너리를 사용하려면 Prometheus 리소스에서 이미지 사양을 바꿉니다.

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    GKE용 워크로드 아이덴티티 제휴 클러스터를 사용 중이고 리소스의 네임스페이스 또는 서비스 계정이 다른 경우에는 추가 네임스페이스 및 Kubernetes 서비스 계정 쌍에 대해 GKE용 워크로드 아이덴티티 제휴 안내를 반복합니다.

    비GKE Kubernetes 클러스터에서 실행하는 경우 사용자 인증 정보를 수동으로 제공해야 합니다. 사용자 인증 정보를 제공하려면 다음을 수행합니다.

    1. 명시적으로 사용자 인증 정보 제공에 설명된 대로 적절한 서비스-계정 키 파일을 보안 비밀로 추가합니다.

    2. Prometheus 리소스를 수정하여 굵게 표시된 텍스트를 추가합니다.

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    컨테이너의 EXTRA_ARGS 환경 변수를 설정하여 측정항목 필터링 플래그와 같은 추가 플래그를 추가할 수 있습니다. 컨테이너 사양의 args 섹션은 Prometheus Operator에서 관리되므로 환경 변수를 통해 수행됩니다.

    kube-prometheus 사용

    널리 사용되는 kube-prometheus 라이브러리를 사용하여 생성된 배포를 구성하여 Managed Service for Prometheus를 사용할 수 있습니다.

    Kube-prometheus에는 기본 네임스페이스 및 서비스 계정에 대한 내부 종속 항목이 일부 있으므로 Managed Service for Prometheus에 데이터를 전송하는 데 필요한 최소 필드 수만 변경하는 것이 좋습니다.

    manifests/prometheus-prometheus.yaml 내에서 이미지 사양을 바꾸고 replicas를 1로 줄여 고가용성 컬렉션을 사용 중지합니다.

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    GKE에서 실행하고 노드의 기본 서비스 계정을 수정하지 않은 경우 수정된 매니페스트를 적용하면 즉시 Prometheus용 관리형 서비스로 데이터가 전송됩니다. 그렇지 않으면 서비스 계정을 구성하고 적용해야 할 수도 있습니다. GKE에서 실행하고 워크로드 아이덴티티를 사용할 때는 monitoring 네임스페이스 내에서 prometheus-k8s 서비스 계정을 만들고 승인해야 할 수 있습니다. 비GKE Kubernetes 클러스터에서 실행하는 경우 prometheus-operator 섹션의 안내를 따르세요.

    kube-prometheus는 기본적으로 많은 측정항목을 수집합니다. 수집된 항목 대부분은 종종 GKE와 같은 관리형 Kubernetes 환경에 있을 필요가 없습니다. 수집 비용을 절약하려면 관심 있는 측정항목만 스크래핑하도록 kube-prometheus를 맞춤설정하고 내보낸 측정항목을 적극적으로 필터링할 수 있습니다.

    자세한 내용은 비용 관리 및 기여 분석을 참조하세요.

    고가용성 배포

    대체 Prometheus 바이너리는 리더 선택을 사용해서 가용성이 높은 컬렉션에 대한 지원이 기본 제공됩니다. 고가용성 모드에서 복제된 Prometheus 서버는 측정항목 수집과 규칙 평가 모두 일상적으로 수행하지만, 둘 중 하나만 Google Cloud Managed Service for Prometheus로 데이터를 전송합니다.

    동일한 Prometheus 서버 복제본은 동일한 external_labels를 포함하여 항상 구성이 동일해야 합니다. 복제본을 명시적으로 다르게 지정하기 위해 __replica__와 같은 특수한 외부 라벨이 사용되는 다른 시스템에서는 이 요구사항이 다르게 적용됩니다.

    Kubernetes API 서버는 지원되는 리더 선택 백엔드이며 다음 플래그를 설정하여 사용 설정될 수 있습니다.

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    LEASE_NAMESPACE 및 LEASE_NAME 값은 리더 선택이 수행되는 임대 리소스를 식별합니다. 동일한 리소스를 가리키는 모든 Prometheus 서버는 동일한 복제본 집합에 속합니다. Prometheus 배포의 Kubernetes 서비스 계정은 해당 임대 리소스의 읽기 및 쓰기 권한이 필요합니다. Kubernetes 클러스터 외부에서 Prometheus 서버를 실행할 때는 --export.ha.kube.config 플래그를 사용하여 명시적 구성을 제공할 수 있습니다.

    그런 다음 replicas 값을 2 이상으로 늘릴 수 있습니다.

    예약된 라벨

    Managed Service for Prometheus는 6개의 예약된 라벨을 사용하여 Monarch의 리소스를 고유하게 식별합니다.

    • project_id: 측정항목과 연결된 Google Cloud 프로젝트의 식별자입니다. 필수 항목.
    • location: 데이터가 저장되는 물리적 위치(Google Cloud 리전)입니다. 이 값은 일반적으로 GKE 클러스터 리전입니다. 데이터가 AWS 또는 온프레미스 배포에서 수집되는 경우 값이 가장 가까운 Google Cloud 리전일 수 있습니다. 필수 항목.
    • cluster: 측정항목과 연결된 Kubernetes 클러스터의 이름입니다. Kubernetes에서 실행하지 않는 경우 인스턴스 그룹과 같은 임의의 계층 구조 수준으로 사용할 수 있습니다. 선택사항이지만 반드시 사용하는 것이 좋습니다.
    • namespace: 측정항목과 연결된 Kubernetes 네임스페이스의 이름입니다. Kubernetes에서 실행되지 않는 경우 인스턴스 하위 그룹과 같은 임의의 계층 구조 수준으로 사용할 수 있습니다. 선택사항이지만 반드시 사용하는 것이 좋습니다.
    • job: Prometheus 대상의 작업 라벨입니다(알려진 경우). 규칙 평가 결과의 경우 비어 있을 수 있습니다. 필수이며 일반적으로 Prometheus에 의해 자동으로 추가됩니다.
    • instance: Prometheus 대상의 인스턴스 라벨입니다(알려진 경우). 규칙 평가 결과의 경우 비어 있을 수 있습니다. 필수이며 일반적으로 Prometheus에 의해 자동으로 추가됩니다. 수동으로 설정하거나 레이블을 변경하는 경우, localhost와 같은 하드코딩된 값을 사용하면 시계열 충돌이 발생할 수 있으므로 사용하지 마세요.

    Google Cloud에서 실행할 때 project_id, location, cluster 라벨이 모든 측정항목에 자동으로 추가됩니다.

    Google Cloud에서 실행할 때는 권장되지 않지만 Prometheus의 global.external_labels 섹션을 사용하여 project_id, location, cluster, namespace 라벨을 재정의할 수 있습니다. 구성 자세한 내용은 Google Cloud 외부에서 자체 배포 컬렉션 실행을 참조하세요.

    예약된 라벨을 측정항목 라벨로 사용하면 자체 배포 컬렉션에서 측정항목 라벨을 예약된 라벨의 값으로 사용합니다. 이렇게 하면 유연성을 확보할 수 있지만 예를 들어 location 라벨을 사용하여 Google Cloud 리전이 아닌 다른 항목을 참조하는 경우 오류가 발생할 수 있습니다.

    바이너리 배포

    비컨테이너화된 환경에서 실행하길 원하는 경우 대체 Prometheus 바이너리를 직접 빌드할 수 있습니다.

    소스 빌드

    자체적으로 Prometheus 컴파일을 위한 기존 프로세스가 있으면 GitHub 저장소를 자체 프로세스로 투명하게 대체할 수 있습니다. Managed Service for Prometheus에는 업스트림 릴리스로부터 해당 릴리스를 구분하기 위해 자체 버전 태그 확장이 사용됩니다.

    일반 바이너리를 빌드하려면 Go 도구 모음 및 최신 버전의 NPM/Yarn을 머신에 설치해야 합니다. 자세한 내용은 업스트림 빌드 안내를 참조하세요.

    1. 저장소를 클론합니다.

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. 원하는 버전 태그를 확인합니다.

      git checkout v2.45.3-gmp.9

    3. Managed Service for Prometheus tarball을 만들려면 다음 명령어를 실행합니다.

      make build && make tarball

    결과 tarball 및 바이너리는 디렉터리 구조 및 기능 면에서 해당 업스트림 변형과 완전히 호환됩니다.

    측정항목 및 라벨 생성 및 업데이트 한도

    Managed Service for Prometheus는 새 측정항목 만들기 및 기존 측정항목에 새 측정항목 라벨 추가에 대한 분당 비율 제한을 적용합니다. 일반적으로는 자체 배포된 컬렉션을 사용하도록 기존 Prometheus 배포를 마이그레이션할 때와 같이 Managed Service for Prometheus를 처음 통합할 때만 이러한 비율 제한에 도달합니다. 이것은 데이터 포인트 수집에 대한 비율 제한이 아닙니다. 이 비율 제한은 이전에 없던 측정항목을 만들거나 기존 측정항목에 새 라벨을 추가할 때에만 적용됩니다.

    이 할당량은 고정되어 있지만 분당 최대 한도까지 새 측정항목 및 측정항목 라벨이 생성됨에 따라 문제가 자동으로 해결됩니다.

    자세한 내용은 문제 해결을 참조하세요.

    Google Cloud 외부에서 자체 배포된 컬렉션 실행

    Compute Engine 환경, GKE 환경, 충분한 권한이 승인된 계정으로 gcloud login을 실행한 머신에서 추가 구성 없이 자체 배포된 컬렉션을 실행할 수 있습니다. Google Cloud 외부에서 사용자 인증 정보, 측정항목을 포함할 project_id, 측정항목을 저장할 location(Google Cloud 리전)을 명시적으로 제공해야 합니다. 또한 Kubernetes 이외의 환경에서 실행할 경우에도 cluster 및 namespace 라벨을 설정해야 합니다.

    명시적으로 사용자 인증 정보 제공에 설명된 대로 --export.credentials-file 플래그 또는 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 사용하여 서비스-계정 키를 제공할 수 있습니다.

    읽기의 경우 계획된 테넌시 모델을 기준으로 project_id를 선택하는 것이 좋습니다. 측정항목 범위를 통해 나중에 읽기를 구성할 방법에 따라 측정항목을 저장할 프로젝트를 선택합니다. 문제되지 않으면 모든 것을 한 프로젝트에 넣을 수 있습니다.

    location의 경우 배포와 가장 가까운 Google Cloud 리전을 선택하는 것이 좋습니다. 선택한 Google Cloud 리전이 배포에서 멀수록 쓰기 지연 시간이 늘어나고 잠재적으로 네트워킹 문제가 발생할 가능성이 높아집니다. 자세한 내용은 여러 클라우드 간 리전 목록을 참조하세요. 중요하지 않으면 모든 것을 하나의 Google Cloud 리전에 넣을 수 있습니다. global을 위치로 사용할 수 없습니다.

    Kubernetes 환경에서 실행하는 경우 cluster 및 namespace 값을 로컬 클러스터 및 네임스페이스로 설정합니다. Kubernetes 외부에서 실행하는 경우 계층적으로 의미 있는 값으로 설정합니다. 예를 들어 AWS에서 실행되는 VM 기반 환경에서는 cluster 값을 __aws__로 설정하고 namespace 값을 인스턴스 ID로 설정합니다. 로컬 메타데이터 서버를 호출하는 라벨 재지정 규칙을 사용하여 인스턴스 ID를 동적으로 채울 수 있습니다.

    최소한의 작동 예시를 보려면 다음 명령어를 사용하여 로컬 자체 모니터링 Prometheus 바이너리를 실행할 수 있습니다.

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    이 예시에서는 us-central1와 같은 값으로 REGION 변수를 설정했다고 가정합니다.

    하지만 Prometheus 구성의 global.external_labels 섹션에서 관리형 서비스에 대해 export 대상 라벨을 설정하는 것이 좋습니다. 예를 들어 Kubernetes 환경에서는 다음 구성을 사용할 수 있습니다.

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    Google Cloud 외부에서 Managed Service for Prometheus를 실행하면 데이터 전송 요금이 발생합니다. Google Cloud에 데이터를 전송하기 위한 요금이 있고, 다른 클라우드 외부로 데이터를 전송하는 데 요금이 발생할 수 있습니다. --export.compression=gzip 플래그를 사용해 압축을 사용 설정하면 이 비용을 최소화할 수 있습니다.

    다음 단계