Cloud Run용 Prometheus 사이드카 사용

Cloud Run용 Managed Service for Prometheus 사이드카는 Cloud Run 서비스에 대해 Prometheus 스타일의 모니터링을 수행하는 Google 권장 방식입니다. Cloud Run 서비스가 OTLP 측정항목을 작성하는 경우 OpenTelemetry 사이드카를 사용할 수 있습니다. 하지만 Prometheus 측정항목을 작성하는 서비스의 경우 이 문서에 설명된 Managed Service for Prometheus 사이드카를 사용하세요.

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

사이드카는 서버 측에서 Google Cloud Managed Service for Prometheus를 사용하고 클라이언트 서버리스 워크로드를 위해 커스텀 방식으로 빌드된 OpenTelemetry Collector 배포판을 사용합니다. 이 커스텀 배포판에는 Cloud Run을 지원하기 위해 몇 가지 변경사항이 포함되어 있습니다. 이 수집기는 10초 후 시작 스크래핑을 수행하고, 인스턴스의 단기 수명이 얼마나 짧은지에 관계없이 종료 스크래핑을 수행합니다. 최대한의 신뢰성을 위해서는 사이드카를 실행하는 Cloud Run 서비스에 상시 할당된 CPU를 사용하는 것이 좋습니다. 자세한 내용은 CPU 할당(서비스)을 참조하세요. 낮은 초당 쿼리 수(QPS)로 인해 CPU 할당이 제한된 경우 일부 스크래핑 시도가 실패할 수 있습니다. 상시 할당된 CPU는 사용 가능한 상태로 유지됩니다.

사이드카는 Cloud Run 멀티 컨테이너(사이드카) 기능을 사용해서 수집기를 워크로드 컨테이너와 함께 사이드카 컨테이너로 실행합니다. Cloud Run의 사이드카에 대한 자세한 내용은 서비스에 다중 컨테이너 배포(사이드카)를 참조하세요.

Cloud Run용 Managed Service for Prometheus 사이드카는 Kubernetes PodMonitoring 커스텀 리소스의 일부인 RunMonitoring이라는 새로운 구성을 사용합니다. 대부분의 사용자가 기본 RunMonitoring 구성을 사용할 수 있지만 커스텀 구성을 만들 수도 있습니다. 기본 및 커스텀 RunMonitoring 구성에 대한 자세한 내용은 Cloud Run 서비스에 사이드카 추가를 참조하세요.

시작하기 전에

이 섹션에서는 이 문서를 사용하는 데 필요한 설정에 대해 설명합니다.

gcloud CLI 설치 및 구성

이 문서에서 설명하는 많은 단계에는 Google Cloud CLI가 사용됩니다. gcloud CLI 설치에 대한 자세한 내용은 Google Cloud CLI 구성요소 관리를 참조하세요.

gcloud 명령어를 호출할 때는 Google Cloud 프로젝트의 식별자를 지정해야 합니다. Google Cloud CLI에 대해 기본 프로젝트를 설정하면 모든 명령어에 이를 입력할 필요가 없습니다. 프로젝트를 기본값으로 설정하려면 다음 명령어를 입력합니다.

gcloud config set project PROJECT_ID

또한 Cloud Run 서비스의 기본 리전을 설정할 수 있습니다. 기본 리전을 설정하려면 다음 명령어를 입력합니다.

gcloud config set run/region REGION

API 사용 설정

Google Cloud 프로젝트에서 다음 API를 사용 설정해야 합니다.

  • Cloud Run Admin API: run.googleapis.com
  • Artifact Registry API: artifactregistry.googleapis.com
  • Cloud Monitoring API: monitoring.googleapis.com
  • Cloud Logging API: logging.googleapis.com
  • (선택사항) 커스텀 RunMonitoring 구성을 만들 경우 Secret Manager API: secretmanager.googleapis.com을 사용 설정해야 합니다.
  • (선택사항) 또한 Cloud Build를 사용해서 샘플 앱을 실행하도록 선택한 경우 다음 API를 사용 설정해야 합니다.
    • Cloud Build API: cloudbuild.googleapis.com.
    • Identity and Access Management API: iam.googleapis.com. 자세한 내용은 샘플 앱 빌드 및 실행을 참조하세요.

프로젝트에서 사용 설정된 API를 보려면 다음 명령어를 실행합니다.

gcloud services list

사용 설정되지 않은 API를 사용 설정하려면 다음 명령어 중 하나를 실행합니다.

gcloud services enable run.googleapis.com
gcloud services enable artifactregistry.googleapis.com
gcloud services enable secretmanager.googleapis.com
gcloud services enable monitoring.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable cloudbuild.googleapis.com
gcloud services enable iam.googleapis.com

Cloud Run용 서비스 계정

기본적으로 Cloud Run 작업 및 서비스는 Compute Engine 기본 서비스 계정인 PROJECT_NUMBER-compute@developer.gserviceaccount.com을 사용합니다. 이 서비스 계정에는 일반적으로 이 문서에서 설명하는 측정항목 및 로그를 작성하는 데 필요한 Identity and Access Management(IAM) 역할이 포함되어 있습니다.

  • roles/monitoring.metricWriter
  • roles/logging.logWriter

커스텀 RunMonitoring 구성을 만드는 경우 서비스 계정에 다음 역할도 포함되어야 합니다.

  • roles/secretmanager.admin
  • roles/secretmanager.secretAccessor

또한 Cloud Run에 대해 사용자 관리 서비스 계정을 구성할 수 있습니다. 사용자 관리 서비스 계정에는 다음 역할도 포함되어야 합니다. Cloud Run의 서비스 계정에 대한 자세한 내용은 서비스 ID 구성을 참조하세요.

사이드카를 구성하여 Cloud Run 서비스에 추가

Cloud Run용 Managed Service for Prometheus 사이드카는 Kubernetes PodMonitoring 커스텀 리소스의 일부인 RunMonitoring이라는 새로운 구성을 사용합니다. RunMonitoring 구성은 기존 PodMonitoring 옵션을 사용해서 Cloud Run을 지원하며, Kubernetes와 관련된 일부 옵션이 없습니다.

기본 RunMonitoring 구성을 사용하거나 커스텀 구성을 만들 수 있습니다. 다음 섹션에서는 두 가지 방식을 모두 설명합니다. 두 방식 중 하나만 수행하면 됩니다. 기본 또는 커스텀 구성 사용에 대해 자세히 알아보려면 해당 탭을 선택합니다.

기본 구성

기본 RunMonitoring 구성 사용

커스텀 RunMonitoring 구성을 만들지 않으면 사이드카 수집기가 다음 기본 구성을 합성하여 측정항목 경로 /metrics의 포트 8080에서 30초 간격으로 측정항목을 스크래핑합니다.

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: run-gmp-sidecar
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 30s

기본 구성을 사용할 때 Cloud Run 서비스에 사이드카 추가 이외의 추가 설정은 필요하지 않습니다.

Cloud Run 서비스에 사이드카 추가

기본 RunMonitoring 구성으로 사이드카를 사용하려면 기존 Cloud Run 구성을 수정해서 사이드카를 추가해야 합니다. 사이드카를 추가하려면 다음을 수행합니다.

  • 컨테이너의 시작 및 종료 순서를 지정하는 컨테이너 종속 항목 주석을 추가합니다. 다음 예시에서 "collector"라는 사이드카 컨테이너는 예시에 있는 "app"이라는 애플리케이션 컨테이너 다음에 시작되고 이 컨테이너 이전에 종료됩니다.
  • 다음 예시에서 "collector"라는 수집기의 컨테이너를 만듭니다.

예를 들어 +(더하기) 문자가 앞에 있는 줄을 Cloud Run 구성에 추가한 후 서비스를 다시 배포합니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
+       name: collector

run-service.yaml 구성 파일로 Cloud Run 서비스를 다시 배포하려면 다음 명령어를 실행합니다.

gcloud run services replace run-service.yaml --region=REGION

커스텀 구성

커스텀 RunMonitoring 구성 만들기

기본 구성으로 충분하지 않으면 Cloud Run 서비스에 대해 RunMonitoring 구성을 만들 수 있습니다. 예를 들어 다음과 같은 구성을 만들 수 있습니다.

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

이 구성은 다음을 수행합니다.

  • 포트 8080에서 측정항목을 스크래핑하고 기본 측정항목 경로 /metrics를 사용합니다.
  • 스크래핑 간격을 10초로 지정합니다.
  • 라벨 재지정을 사용해서 스크래핑된 모든 측정항목에 값이 label_value인 label_key 라벨을 추가합니다.
  • service 및 revision 메타데이터 라벨을 스크래핑된 모든 측정항목에 추가합니다.

사용 가능한 구성 옵션에 대한 자세한 내용은 RunMonitoring 사양: 구성 옵션을 참조하세요.

커스텀 RunMonitoring 구성을 사용할 때는 다음 추가 구성을 수행해야 합니다.

Secret Manager를 사용하여 구성 저장

커스텀 RunMonitoring 구성을 제공하려면 다음을 수행합니다.

  • 커스텀 구성이 포함된 파일을 만듭니다.
  • 커스텀 구성이 포함된 Secret Manager 보안 비밀을 만듭니다.

다음 명령어는 custom-config.yaml 파일에서 mysecret이라는 보안 비밀을 만듭니다.

gcloud secrets create mysecret --data-file=custom-config.yaml

custom-config.yaml 파일을 수정한 후 구성에 변경사항을 적용하려면 보안 비밀을 삭제하고 다시 만든 후 Cloud Run 서비스를 다시 배포해야 합니다.

Secret Manager에서 구성 업데이트

언제든지 커스텀 RunMonitoring 구성을 업데이트하려는 경우 기존 보안 비밀의 새 버전을 Secret Manager에 추가할 수 있습니다.

예를 들어 custom-config-updated.yaml 파일에 저장된 새 구성으로 mysecret를 업데이트하려면 다음을 실행합니다.

gcloud secrets versions add mysecret --data-file=custom-config-updated.yaml

사이드카가 자동으로 새로고침되고 변경사항이 구성에 적용됩니다.

Cloud Run 서비스에 사이드카 추가

RunMonitoring 구성을 위해 Secret Manager 보안 비밀을 만든 후에는 다음을 수행하도록 Cloud Run 구성을 수정해야 합니다.

  • Managed Service for Prometheus 사이드카를 추가합니다.
    • 컨테이너의 시작 및 종료 순서를 지정하는 컨테이너 종속 항목 주석을 추가합니다. 다음 예시에서 "collector"라는 사이드카 컨테이너는 예시에 있는 "app"이라는 애플리케이션 컨테이너 다음에 시작되고 이 컨테이너 이전에 종료됩니다.
    • 다음 예시에서 "collector"라는 수집기의 컨테이너를 만듭니다.
  • /etc/rungmp/config.yaml 위치에서 보안 비밀을 수정하여 보안 비밀을 추가합니다.
    • 커스텀 RunMonitoring 구성이 있는 보안 비밀을 가리키는 보안 비밀 주석을 추가합니다.
    • 다음 예시에서 config.yaml 파일을 가리키는 보안 비밀에 대해 "config"라는 볼륨을 만듭니다.
    • 마운트 경로 /etc/rungmp에서 수집기 이미지의 일부로 볼륨을 마운트합니다.

예를 들어 +(더하기) 문자가 앞에 있는 줄을 Cloud Run 구성에 추가한 후 서비스를 다시 배포합니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
+       run.googleapis.com/secrets: 'mysecret:projects/PROJECT_ID/secrets/mysecret'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
+       name: collector
+       volumeMounts:
+       - mountPath: /etc/rungmp/
+         name: config
+     volumes:
+     - name: config
+       secret:
+         items:
+         - key: latest
+           path: config.yaml
+         secretName: 'mysecret'

run-service.yaml 구성 파일로 Cloud Run 서비스를 다시 배포하려면 다음 명령어를 실행합니다.

gcloud run services replace run-service.yaml --region=REGION

RunMonitoring 사양: 구성 옵션

이 섹션에서는 Managed Service for Prometheus 사이드카의 RunMonitoring 구성 사양을 설명합니다. 다음은 커스텀 구성 예시를 보여줍니다.

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

RunMonitoring

RunMonitoring 구성은 Cloud Run 서비스를 모니터링합니다.

필드 설명 스킴 필수
metadata 모든 지속적인 리소스에 포함되어야 하는 메타데이터입니다. metav1.ObjectMeta false
spec Prometheus에서 대상 검색을 위해 선택된 Cloud Run 배포의 사양입니다. RunMonitoringSpec true
RunMonitoringSpec

이 사양은 RunMonitoring 구성이 Cloud Run 서비스를 모니터링하는 방법을 설명합니다.

필드 설명 스킴 필수
endpoints 선택한 포드에서 스크래핑할 엔드포인트입니다. []ScrapeEndpoint true
targetLabels 검색된 엔드포인트에 대해 Prometheus 대상에 추가할 라벨입니다. instance 라벨은 항상 Cloud Run 인스턴스 ID로 설정됩니다. RunTargetLabels false
limits 스크래핑 시에 적용할 한도입니다. *ScrapeLimits false
RunTargetLabels

RunTargetLabels 구성을 사용하면 검색된 Prometheus 대상의 Cloud Run 라벨을 포함할 수 있습니다.

필드 설명 스킴 필수
metadata 모든 스크래핑된 대상에 설정되는 Cloud Run 메타데이터 라벨입니다.

허용되는 키는 instance, revision, service, configuration입니다.

허용되는 키가 설정되었으면 사이드카가 Cloud Run 인스턴스에서 해당하는 값을 모든 측정항목에 측정항목 라벨로 추가합니다. 예를 들면 instanceID, revision_name, service_name, configuration_name입니다.

기본적으로 설정 중인 모든 허용되는 키로 지정됩니다.		 *[]string false

샘플 앱 빌드 및 실행

이 섹션에서는 샘플 앱으로 Managed Service for Prometheus 사이드카를 실행하는 방법을 설명합니다. 이 섹션은 선택사항입니다. 이미 Cloud Run 서비스가 있고 이를 사용해서 사이드카를 배포하려면 Cloud Run 서비스에 Managed Service for Prometheus 사이드카 추가를 참조하세요.

run-gmp-sidecar 저장소 복제

샘플 앱과 해당 구성 파일을 가져오려면 다음 명령어를 실행하여 run-gmp-sidecar 저장소를 클론합니다.

git clone https://github.com/GoogleCloudPlatform/run-gmp-sidecar/

저장소를 클론한 후 run-gmp-sidecar 디렉터리로 변경합니다.

cd run-gmp-sidecar

샘플 앱 빌드 및 실행

샘플 앱에는 Docker 또는 비슷한 Linux용 컨테이너 빌드 시스템이 필요합니다. 다음 방법 중 하나로 샘플 앱을 빌드하고 실행할 수 있습니다.

  • Cloud Build를 사용해서 로컬 Docker 지원 없이 실행합니다. Cloud Build를 사용하는 경우 Cloud Build API도 사용 설정해야 합니다.
  • 샘플 앱을 수동으로 빌드하고 실행합니다.

다음 섹션에서는 두 가지 방식을 모두 설명합니다. 두 방식 중 하나만 수행하면 됩니다. 자세한 내용을 보려면 두 방식 중 하나의 탭을 선택합니다.

Cloud Build 사용

Cloud Build 사용

run-gmp-sidecar 저장소에는 Cloud Build의 구성 파일이 포함됩니다. 이러한 파일은 샘플 앱을 빌드하고 배포하는 데 필요한 단계를 하나로 묶어줍니다.

또한 Cloud Build에서 처리되는 단계를 수동으로 수행할 수 있습니다. 자세한 내용은 수동으로 빌드 및 실행을 참조하세요.

Cloud Build 설정

이러한 구성 파일에는 Cloud Build 서비스 계정과 Artifact Registry 저장소가 필요합니다. run-gmp-sidecar 저장소에는 또한 다음을 수행하는 create-sa-and-ar.sh 스크립트가 포함됩니다.

  • 서비스 계정 run-gmp-sa@PROJECT_ID.iam.gserviceaccount.com을 만듭니다.
  • 서비스 계정에 다음 역할을 부여합니다.
    • roles/iam.serviceAccountUser
    • roles/storage.objectViewer
    • roles/logging.logWriter
    • roles/artifactregistry.createOnPushWriter
    • roles/secretmanager.admin
    • roles/secretmanager.secretAccessor
    • roles/run.admin
  • 컨테이너 이미지에 대해 Artifact Registry 저장소 run-gmp를 만듭니다.

run-gmp-sa 서비스 계정과 run-gmp 저장소를 만들려면 다음 명령어를 실행합니다.

./create-sa-and-ar.sh

권한이 전파되려면 시간이 걸리기 때문에 다음 단계를 진행하기 전 30초 정도 기다리는 것이 좋습니다. 그렇지 않으면 승인 오류가 표시될 수 있습니다.

Cloud Build 요청 제출

run-gmp-sa 서비스 계정과 run-gmp 저장소를 설정한 후에는 Cloud Build 구성 파일을 제출하여 Cloud Build 작업을 시작할 수 있습니다. 다음 gcloud builds submit 명령어를 사용하면 됩니다.

gcloud builds submit . --config=cloudbuild-simple.yaml --region=REGION

이 명령어를 실행하려면 몇 분 정도 걸리지만, Cloud Build 빌드 세부정보를 찾을 수 있는 위치가 거의 즉시 표시됩니다. 메시지는 다음과 같이 표시됩니다.

Logs are available at [
https://console.cloud.google.com/cloud-build/builds/637860fb-7a14-46f2-861e-09c1dc4cea6b?project=PROJECT_NUMBER].

빌드 프로세스를 보려면 브라우저에서 반환된 URL로 이동합니다. 또한 Cloud Logging에서 사이드카 로그를 확인할 수 있습니다.

서비스 URL 확인

Cloud Build 작업이 종료된 후 다음 명령어를 실행하여 Cloud Run 서비스의 엔드포인트 URL을 확인합니다.

gcloud run services describe my-cloud-run-service --region=REGION --format="value(status.url)"

이 명령어는 다음과 같은 서비스 URL을 반환합니다.

https://my-cloud-run-service-abcdefghij-ue.a.run.app

반환된 URL을 앱이 실행 중인지 확인 섹션에서 SERVICE_URL의 값으로 사용합니다.

수동으로 빌드 및 실행

수동으로 빌드 및 실행

Cloud Build 사용에 설명된 대로 Cloud Build에서 처리되는 단계를 수동으로 수행할 수 있습니다. 다음 섹션에서는 동일한 태스크를 수동으로 수행하는 방법을 설명합니다.

이후 단계에서 사용되는 변수 설정

이후 단계 중 일부에는 공통 값에 대한 환경 변수가 사용됩니다. 다음 명령어를 사용해서 이러한 변수를 설정하세요.

export GCP_PROJECT=PROJECT_ID
export REGION=REGION

컨테이너 이미지 저장소 만들기

다음 명령어를 실행하여 컨테이너 이미지에 대한 Artifact Registry 저장소를 만듭니다.

gcloud artifacts repositories create run-gmp \
    --repository-format=docker \
    --location=${REGION}

샘플 앱 빌드 및 푸시

이 예시에서는 Linux 기반 Docker를 사용해서 샘플 앱을 빌드하고 이를 Artifact Registry 저장소에 푸시합니다. Windows 또는 macOS 환경에서 작업하는 경우 이러한 명령어를 조정해야 할 수 있습니다.

샘플 앱을 빌드하고 이를 Artifact Registry에 푸시하려면 다음을 수행합니다.

  1. Google Cloud CLI를 사용해서 Docker 클라이언트에 인증을 수행합니다.

    gcloud auth configure-docker ${REGION}-docker.pkg.dev

  2. run-gmp-sidecar 저장소의 simple-app 디렉터리로 이동합니다. 

    pushd sample-apps/simple-app

  3. 다음 명령어를 실행하여 simple-app 앱을 빌드합니다.

    docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .

  4. 다음 명령어를 실행하여 빌드된 앱의 이미지를 푸시합니다. 

    docker push ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app

  5. run-gmp-sidecar 디렉터리로 돌아갑니다.

    popd

Cloud Run 서비스 구성

run-gmp-sidecar 저장소의 run-service-simple.yaml 파일은 이전 단계에서 빌드한 샘플 앱 및 수집기 이미지를 사용하는 멀티 컨테이너 Cloud Run 서비스를 정의합니다. run-service-simple.yaml 파일에는 다음 서비스 사양이 포함됩니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
        run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "%SAMPLE_APP_IMAGE%"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
      - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
        name: collector

이 파일에는 이전 단계에서 빌드한 이미지의 자리표시자 값이 포함되므로, Google Cloud 프로젝트의 실제 값으로 자리표시자를 업데이트해야 합니다.

다음 명령어를 실행하여 %SAMPLE_APP_IMAGE% 자리표시자를 바꿉니다.

sed -i s@%SAMPLE_APP_IMAGE%@REGION-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app@g run-service-simple.yaml

Cloud Run 서비스 배포

해당 값으로 run-service-simple.yaml 파일을 업데이트한 후에는 다음 명령어를 실행해서 Cloud Run 서비스를 만들고 배포할 수 있습니다.

gcloud run services replace run-service-simple.yaml --region=REGION

이 명령어는 다음과 같은 서비스 URL을 반환합니다.

https://my-cloud-run-service-abcdefghij-ue.a.run.app

반환된 URL을 앱이 실행 중인지 확인 섹션에서 SERVICE_URL의 값으로 사용합니다.

인증되지 않은 HTTP 액세스 허용

서비스 URL에 요청을 수행하려면 먼저 Cloud Run 서비스 정책을 변경해서 인증되지 않은 HTTP 액세스를 수락해야 합니다. run-gmp-sidecar 저장소의 policy.yaml 파일에는 필요한 변경사항이 포함됩니다.

서비스 정책을 변경하려면 다음 명령어를 실행합니다.

gcloud run services set-iam-policy my-cloud-run-service policy.yaml --region=REGION

앱이 실행되는지 확인

Cloud Run 서비스가 샘플 앱을 올바르게 실행하는지 확인하려면 curl 유틸리티를 사용해서 서비스의 metrics 엔드포인트에 액세스합니다.

  1. SERVICE_URL 환경 변수를 이전 단계의 Cloud Run 서비스 URL로 설정합니다.

    export SERVICE_URL=SERVICE_URL

  2. 다음 명령어를 실행하여 서비스 URL에 요청을 전송합니다.

    curl $SERVICE_URL

앱이 성공적으로 시작되었으면 다음 응답이 표시됩니다.

User request received!

측정항목 탐색기에서 앱 측정항목 보기

샘플 app 컨테이너는 다음 측정항목을 작성합니다.

  • foo_metric: 부동 소수점 값으로 표현되는 현재 시간입니다(게이지).
  • bar_metric: 부동 소수점 값으로 표현되는 현재 시간입니다(카운터).

측정항목 탐색기에서 이러한 측정항목을 보려면 다음을 수행하세요.

  1. Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.

    측정항목 탐색기로 이동

  2. 쿼리 빌더 창의 툴바에서 이름이  MQL 또는  PromQL인 버튼을 선택합니다.

  3. 언어 전환 버튼에 PromQL이 선택되어 있는지 확인합니다. 언어 전환 버튼은 쿼리 형식을 지정할 수 있는 동일한 툴바에 있습니다.

  4. 편집기 창에 다음 쿼리를 입력합니다.

    foo_metric

  5. 쿼리 추가를 클릭합니다.

  6. 쿼리 빌더 창의 툴바에서 이름이  MQL 또는  PromQL인 버튼을 선택합니다.

  7. 언어 전환 버튼에 PromQL이 선택되어 있는지 확인합니다. 언어 전환 버튼은 쿼리 형식을 지정할 수 있는 동일한 툴바에 있습니다.

  8. 두 번째 편집기 창에 다음 쿼리를 입력합니다.

    bar_metric

  9. 쿼리 실행을 클릭합니다.

  10. 측정항목에 대한 세부정보를 보려면 차트 테이블 모두 라벨이 지정된 전환 버튼에서 모두를 선택합니다.

삭제

샘플 앱으로 실험을 완료했으면 run-gmp-sidecar 저장소에서 clean-up-cloud-run.sh 스크립트를 사용하여 샘플에 대해 생성되었을 수 있는 다음 리소스를 삭제할 수 있습니다.

  • Cloud Run 서비스
  • Artifact Registry 저장소
  • Cloud Build에 대해 생성된 서비스 계정

이러한 리소스를 삭제하면 샘플 실행 후 비용이 발생하지 않습니다.

샘플 앱을 삭제하려면 clean-up-cloud-run.sh 스크립트를 실행합니다.

./clean-up-cloud-run.sh

측정항목 탐색기에서 자체 측정항목 보기

Managed Service for Prometheus 사이드카는 사이드카 자체에 대해 다음 측정항목을 Cloud Monitoring에 보고합니다.

  • agent_uptime: 사이드카 수집기의 업타임입니다(카운터).
  • agent_memory_usage: 사이드카 수집기에 소비되는 메모리입니다(게이지).
  • agent_api_request_count: 사이드카 수집기의 API 요청 수입니다(카운터).
  • agent_monitoring_point_count: 사이드카 수집기에서 Cloud Monitoring에 작성된 측정항목 포인트 수입니다(카운터).

측정항목 탐색기에서 사이드카의 자체 측정항목을 보려면 다음을 수행합니다.

  1. Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후 측정항목 탐색기를 선택합니다.

    측정항목 탐색기로 이동

  2. 쿼리 빌더 창의 툴바에서 이름이  MQL 또는  PromQL인 버튼을 선택합니다.

  3. 언어 전환 버튼에 PromQL이 선택되어 있는지 확인합니다. 언어 전환 버튼은 쿼리 형식을 지정할 수 있는 동일한 툴바에 있습니다.

  4. 편집기 창에 쿼리하려는 측정항목 이름을 입력합니다. 예를 들면 다음과 같습니다.

    agent_api_request_count

  5. 쿼리 실행을 클릭합니다.

  6. 측정항목에 대한 세부정보를 보려면 차트 테이블 모두 라벨이 지정된 전환 버튼에서 모두를 선택합니다.

로그 탐색기에서 자체 로그 보기

Managed Service for Prometheus 사이드카는 Cloud Logging에 로그를 작성합니다. 사이드카는 Logging 모니터링 리소스 유형 cloud_run_revision에 대해 로그를 작성합니다.

로그 탐색기에서 사이드카의 로그를 보려면 다음을 수행합니다.

  1. Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 탐색기를 선택합니다.

    로그 탐색기로 이동

  2. Cloud Run 버전 리소스 유형을 선택하거나 다음 쿼리를 입력하고 쿼리 실행을 클릭합니다.

    resource.type="cloud_run_revision"

수집된 측정항목 정보

사이드카에서 내보낸 측정항목이 Cloud Monitoring에 수집될 때는 Cloud Monitoring prometheus_target 모니터링 리소스 유형에 대해 측정항목이 기록됩니다. 이 리소스 유형은 애플리케이션 측정항목 및 사이드카의 자체 측정항목 모두에 사용됩니다.

측정항목을 기록할 때 사이드카는 리소스 라벨을 다음과 같이 설정합니다.

  • project_id: 컨테이너가 실행되는 Google Cloud 프로젝트의 ID입니다.
  • location: 컨테이너가 실행되는 Google Cloud 리전입니다.
  • cluster: __run__ 값입니다.
  • namespace: 실행 중인 Cloud Run 서비스의 이름입니다. K_SERVICE 환경 변수에서 비롯됩니다.
  • job: RunMonitoring 구성의 이름입니다. 기본값은 run-gmp-sidecar입니다.
  • instance: 컨테이너가 측정항목을 가져오도록 구성된 로컬 워크로드의 faas.ID:PORT 값입니다. faas.ID 값은 Cloud Run 인스턴스의 인스턴스 ID입니다.

또한 사이드카는 다음 측정항목 라벨을 추가합니다.

  • instanceId: Cloud Run 인스턴스의 ID입니다.
  • service_name: 실행 중인 Cloud Run 서비스의 이름입니다.
  • revision_name: 실행 중인 Cloud Run 버전의 이름입니다.
  • configuration_name: 실행 중인 Cloud Run 구성의 이름입니다.

이러한 측정항목 라벨은 기본적으로 모두 추가됩니다. 커스텀 RunMonitoring 구성을 사용하는 경우 RunMonitoring 사양에서 targetLabels 옵션을 사용하여 이러한 라벨을 생략할 수 있습니다. 또한 커스텀 구성을 사용해서 instanceId를 제외하고 이러한 측정항목에 라벨을 다시 지정할 수 있습니다.

수집된 측정항목에 표시되는 다른 모든 라벨은 사용자 측정항목에서 시작됩니다. 사용자 정의 라벨이 시스템 제공 라벨 중 하나와 충돌할 경우 사용자 정의 라벨에 exported_ 문자열이 프리픽스로 추가됩니다. 예를 들어 사용자 지정 라벨 namespace=playground가 시스템에 정의된 namespace 라벨과 충돌할 경우 사용자 라벨이 exported_namespace=playground로 표시됩니다.

측정항목 유형

사이드카에서 내보낸 측정항목이 Cloud Monitoring에 수집될 때는 측정항목이 prometheus.googleapis.com 측정항목으로 기록되고, Prometheus 측정항목의 유형이 이름 끝에 추가됩니다. 예를 들어 샘플 앱은 foo_metric이라는 Prometheus 게이지 측정항목을 내보냅니다. Cloud Monitoring에서 측정항목은 prometheus.googleapis.com/foo_metric/gauge 측정항목 유형으로 저장됩니다.

PromQL로 측정항목을 쿼리할 때는 측정항목 탐색기에서 앱 측정항목 보기 및 측정항목 탐색기에서 자체 측정항목 보기에 표시된 것처럼 Prometheus 이름을 사용할 수 있습니다. 측정항목 탐색기에서 쿼리 빌더 또는 Monitoring 쿼리 언어(MQL)와 같은 도구를 사용할 때는 Cloud Monitoring 측정항목 유형이 중요합니다.

청구

사이드카가 내보낸 측정항목은 Cloud Monitoring에 prometheus.googleapis.com 프리픽스를 사용해서 수집됩니다. 이 프리픽스가 있는 측정항목은 수집된 샘플 수에 따라 요금이 청구됩니다. 청구 및 Managed Service for Prometheus에 대한 자세한 내용은 청구를 참조하세요.