로깅 및 모니터링 구성

베어메탈용 Google Distributed Cloud(소프트웨어만 해당)에는 클라우드 기반 관리형 서비스, 오픈소스 도구, 서드 파티 상업용 솔루션과의 검증된 호환성을 비롯한 여러 가지 클러스터 로깅 및 모니터링 옵션이 포함되어 있습니다. 이 페이지에서는 이러한 옵션에 대해 설명하고 사용자 환경에 적합한 솔루션을 선택하는 방법에 대한 기본 안내를 제공합니다.

이 페이지는 서비스 수준 목표(SLO) 규정 준수와 같이 배포된 애플리케이션 또는 서비스의 상태를 모니터링하려는 관리자, 설계자, 운영자를 위해 작성되었습니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 작업에 대해 자세히 알아보려면 일반 GKE Enterprise 사용자 역할 및 작업을 참조하세요.

Google Distributed Cloud 옵션

클러스터에 대한 여러 로깅 및 모니터링 옵션이 있습니다.

  • 베어메탈 시스템 구성 요소에서 기본적으로 사용 설정되는 Cloud Logging 및 Cloud Monitoring
  • Prometheus 및 Grafana는 Cloud Marketplace에서 사용 가능합니다.
  • 타사 솔루션을 사용한 검증된 구성

Cloud Logging 및 Cloud Monitoring

Google Cloud Observability는 Google Cloud에 기본 제공되는 관측 가능성 솔루션입니다. 완전 관리형 로깅 솔루션, 측정항목 수집, 모니터링, 대시보드, 알림을 제공합니다. Cloud Monitoring은 클라우드 기반 GKE 클러스터와 유사한 방식으로 Google Distributed Cloud 클러스터를 모니터링합니다.

필요한 서비스 계정과 IAM 역할로 클러스터를 만들면 Cloud Logging 및 Cloud Monitoring이 기본적으로 사용 설정됩니다. Cloud Logging 및 Cloud Monitoring은 사용 중지할 수 없습니다. 서비스 계정 및 필요한 역할에 관한 자세한 내용은 서비스 계정 구성을 참조하세요.

로깅 및 모니터링 범위와 수집된 측정항목 수준을 변경하도록 에이전트를 구성할 수 있습니다.

  • 로깅 및 모니터링의 범위는 시스템 구성요소로만(기본값) 또는 시스템 구성요소와 애플리케이션에만 설정할 수 있습니다.
  • 수집된 측정항목 수준은 최적화된 측정항목 집합(기본값) 또는 전체 측정항목에 대해 구성될 수 있습니다.

자세한 내용은 이 문서의 Google Distributed Cloud용 Stackdriver 에이전트 구성을 참조하세요.

Logging 및 Monitoring에서는 구성하기 쉽고 강력한 클라우드 기반 단일 관측 가능성 솔루션을 제공합니다. Google Distributed CloudE에서 워크로드를 실행할 때는 Logging 및 Monitoring을 사용하는 것이 좋습니다. Google Distributed Cloud 및 표준 온프레미스 인프라에서 실행되는 구성요소가 있는 애플리케이션의 경우 이러한 애플리케이션을 포괄적으로 볼 수 있는 다른 솔루션을 고려할 수 있습니다.

Prometheus 및 Grafana

Prometheus와 Grafana는 Cloud Marketplace에서 사용 가능한 두 가지 인기 있는 오픈소스 모니터링 제품입니다.

  • Prometheus는 애플리케이션 및 시스템 측정항목을 수집합니다.

  • Alertmanager는 여러 알림 메커니즘을 사용하여 알림 전송을 처리합니다.

  • Grafana는 대시보드 도구입니다.

모든 모니터링 요구사항에 대해 Cloud Monitoring을 기반으로 하는 Google Cloud Managed Service for Prometheus를 사용하는 것이 좋습니다. Google Cloud Managed Service for Prometheus를 사용하면 시스템 구성요소를 무료로 모니터링할 수 있습니다. Google Cloud Managed Service for Prometheus는 Grafana와도 호환됩니다. 하지만 순수 로컬 모니터링 시스템을 선호하는 경우 클러스터에 Prometheus와 Grafana를 설치할 수 있습니다.

Prometheus를 로컬에 설치했으며 시스템 구성요소에서 측정항목을 수집하려면 로컬 Prometheus 인스턴스에 시스템 구성요소의 측정항목 엔드포인트에 액세스할 수 있는 권한을 부여해야 합니다.

  • Prometheus 인스턴스의 서비스 계정을 사전 정의된 gke-metrics-agent ClusterRole에 바인딩하고 서비스 계정 토큰을 사용자 인증 정보로 사용하여 다음 시스템 구성요소에서 측정항목을 스크래핑합니다.

    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • node-exporter

  • kube-system/stackdriver-prometheus-etcd-scrape 보안 비밀번호에 저장된 클라이언트 키와 인증서를 사용하여 etcd의 측정항목 스크래핑을 인증합니다.

  • 네임스페이스에서 kube-state-metrics로 액세스를 허용하는 NetworkPolicy를 만듭니다.

타사 솔루션

Google은 서드 파티 로깅 및 모니터링 솔루션 제공업체와 협력을 통해 해당 업체 제품이 Google Distributed Cloud에서 잘 작동할 수 있도록 지원합니다. 여기에는 Datadog, Elastic, Splunk가 포함됩니다. 이후에도 다른 검증된 타사 제공업체가 추가될 예정입니다.

다음 솔루션 가이드는 Google Distributed Cloud에서 서드 파티 솔루션을 사용할 때 사용 가능합니다.

Google Distributed Cloud의 Logging 및 Monitoring 작동 방식

새 관리자 클러스터 또는 사용자 클러스터를 만들 때 각 클러스터에 Cloud Logging 및 Cloud Monitoring이 설치되고 활성화됩니다.

Stackdriver 에이전트에는 각 클러스터에 다음과 같은 여러 구성요소가 포함됩니다.

  • Stackdriver 연산자(stackdriver-operator-*). 클러스터에 배포되는 다른 모든 Stackdriver 에이전트의 수명 주기를 관리합니다.

  • Stackdriver 커스텀 리소스. Google Distributed Cloud 설치 프로세스 중에 자동으로 생성되는 리소스입니다.

  • GKE 측정항목 에이전트(gke-metrics-agent-*). 각 노드에서 Cloud Monitoring으로 측정항목을 스크랩하는 OpenTelemetry Collector 기반 DaemonSet입니다. 클러스터에 대한 더 많은 측정항목을 제공하도록 node-exporter DaemonSet 및 kube-state-metrics 배포가 포함됩니다.

  • Stackdriver 로그 전달자(stackdriver-log-forwarder-*). 각 머신의 로그를 Cloud Logging으로 전달하는 Fluent Bit DaemonSet입니다. 로그 전달자는 노드의 로그 항목을 로컬로 버퍼링하여 최대 4시간 동안 다시 전송합니다. 버퍼가 가득 차거나 로그 전달자가 4시간을 초과하여 Cloud Logging API에 연결할 수 없으면 로그가 삭제됩니다.

  • 메타데이터 에이전트(stackdriver-metadata-agent-). 포드, 배포, 노드와 같은 Kubernetes 리소스의 메타데이터를 Config Monitoring for Ops API에 보내는 배포를 나타냅니다. 이 데이터는 배포 이름, 노드 이름 또는 Kubernetes 서비스 이름으로 쿼리할 수 있도록 하여 측정항목 쿼리를 강화하는 데 사용됩니다.

다음 명령어를 실행하여 Stackdriver에서 설치한 에이전트를 확인할 수 있습니다.

kubectl -n kube-system get pods -l "managed-by=stackdriver"

이 명령어 결과는 다음과 비슷합니다.

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Cloud Monitoring 측정항목

Cloud Monitoring에서 수집한 측정항목 목록은 Google Distributed Cloud 측정항목 보기를 참조하세요.

Google Distributed Cloud용 Stackdriver 에이전트 구성

Google Distributed Cloud와 함께 설치된 Stackdriver 에이전트는 클러스터의 문제를 유지보수하고 해결하기 위해 시스템 구성요소에 대한 데이터를 수집합니다. 다음 섹션에서는 Stackdriver 구성 및 작동 모드를 설명합니다.

시스템 구성요소만(기본 모드)

설치 시 Stackdriver 에이전트는 기본적으로 Google에서 제공하는 시스템 구성요소의 성능 세부정보(예: CPU 및 메모리 사용률) 및 유사한 메타데이터 등 로그 및 측정항목을 수집하도록 구성됩니다. 여기에는 관리자 클러스터의 모든 워크로드가 포함되고, 사용자 클러스터의 메타데이터에는 kube-system, gke-system, gke-connect, istio-system, config-management-system 네임스페이스의 워크로드가 포함됩니다.

시스템 구성요소 및 애플리케이션

기본 모드에서 애플리케이션 로깅 및 모니터링을 사용 설정하려면 애플리케이션 로깅 및 모니터링 사용 설정 단계를 수행합니다.

최적화된 측정항목(기본 측정항목)

기본적으로 클러스터에서 실행되는 kube-state-metrics 배포는 최적화된 kube 측정항목 집합을 수집하고 Google Cloud Observability(이전 명칭: Stackdriver)에 보고합니다.

이 최적화 측정항목 집합을 수집하는 데 필요한 리소스가 줄어들어 전반적인 성능과 확장성이 향상됩니다.

최적화된 측정항목을 사용 중지(권장되지 않음)하려면 Stackdriver 커스텀 리소스의 기본 설정을 재정의합니다.

선택한 시스템 구성요소에 Google Cloud Managed Service for Prometheus 사용

Google Cloud Managed Service for Prometheus는 Cloud Monitoring의 일부이며 시스템 구성요소 옵션으로 사용할 수 있습니다. Google Cloud Managed Service for Prometheus의 이점은 다음과 같습니다.

  • 알림 및 Grafana 대시보드를 변경하지 않고도 기존 Prometheus 기반 모니터링을 계속 사용할 수 있습니다.

  • GKE와 Google Distributed Cloud를 모두 사용하는 경우 모든 클러스터의 측정항목에 같은 Prometheus 쿼리 언어(PromQL)를 사용할 수 있습니다. Google Cloud 콘솔의 측정항목 탐색기에 있는 PromQL 탭을 사용할 수도 있습니다.

Google Cloud Managed Service for Prometheus 사용 설정 및 중지

Google Cloud Managed Service for Prometheus는 Google Distributed Cloud에서 기본적으로 사용 설정됩니다.

Google Cloud Managed Service for Prometheus를 사용 중지하려면 다음 안내를 따르세요.

  1. stackdriver라는 수정할 Stackdriver 객체를 엽니다.

    kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

  2. enableGMPForSystemMetrics 기능 게이트를 추가하고 false로 설정합니다.

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

  3. 수정 세션을 닫습니다.

측정항목 데이터 보기

enableGMPForSystemMetrics가 true로 설정되면 다음 구성요소의 측정항목 형식은 Cloud Monitoring에서 저장 및 쿼리되는 방법과 다릅니다

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet 및 cadvisor
  • kube-state-metrics
  • node-exporter

새 형식에는 PromQL 또는 Monitoring 쿼리 언어(MQL)를 사용하여 이전 측정항목을 쿼리할 수 있습니다.

PromQL

PromQL 쿼리 예시:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

MQL

MQL을 사용하려면 모니터링 리소스를 prometheus_target으로 설정하고 kubernetes.io/anthos 프리픽스가 있는 측정항목 이름을 사용하고 Prometheus 유형을 측정항목 이름에 서픽스로 추가합니다.

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Google Cloud Managed Service for Prometheus로 Grafana 대시보드 구성

Google Cloud Managed Service for Prometheus의 측정항목 데이터와 함께 Grafana를 사용하려면 먼저 Grafana 데이터 소스를 구성하고 인증해야 합니다. 데이터 소스를 구성하고 인증하려면 데이터 소스 동기화(datasource-syncer)를 사용하여 OAuth2 사용자 인증 정보를 생성하고 Grafana 데이터 소스 API를 통해 Grafana에 동기화합니다. 데이터 소스 동기화는 Cloud Monitoring API를 Grafana의 데이터 소스 아래에 있는 Prometheus 서버 URL(URL 값이 https://monitoring.googleapis.com으로 시작)로 설정합니다.

Grafana를 사용하여 쿼리의 단계를 수행하여 Google Cloud Managed Service for Prometheus의 데이터를 쿼리하도록 Grafana 데이터 소스를 인증하고 구성합니다.

샘플 Grafana 대시보드 집합은 GitHub의 anthos-samples 저장소에서 제공됩니다. 샘플 대시보드를 설치하려면 다음을 수행합니다.

  1. 샘플 JSON 파일을 다운로드합니다.

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Grafana 데이터 소스가 Managed Service for Prometheus와 다른 이름으로 생성된 경우 모든 JSON 파일에서 datasource 필드를 변경합니다.

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    [DATASOURCE_NAME]을 Prometheus frontend 서비스를 가리키는 Grafana의 데이터 소스 이름으로 바꿉니다.

  3. 브라우저에서 Grafana UI에 액세스하고 대시보드 메뉴에서 + 가져오기를 선택합니다.

    Grafana에서 대시보드 가져오기로 이동

  4. JSON 파일을 업로드하거나 파일 콘텐츠를 복사하여 붙여넣고 로드를 선택합니다. 파일 콘텐츠가 성공적으로 로드되면 가져오기를 선택합니다. 가져오기 전에 대시보드 이름과 UID를 변경할 수도 있습니다(선택사항).

    Grafana에서 대시보드 가져오기

  5. Google Distributed Cloud 및 데이터 소스가 올바르게 구성되면 가져온 대시보드가 성공적으로 로드됩니다. 예를 들어 다음 스크린샷에서는 cluster-capacity.json으로 구성된 대시보드를 보여줍니다.

    Grafana의 클러스터 용량 대시보드

추가 리소스

Google Cloud Managed Service for Prometheus에 대한 자세한 내용은 다음을 참조하세요.

Stackdriver 구성요소 리소스 구성

클러스터를 만들면 Google Distributed Cloud에서 Stackdriver 커스텀 리소스를 자동으로 만듭니다. Stackdriver 구성요소에 대해 CPU 및 메모리 요청과 제한의 기본값을 재정의하도록 커스텀 리소스의 사양을 수정할 수 있습니다. 그리고 최적화된 기본 측정항목 설정을 개별적으로 재정의할 수 있습니다.

Stackdriver 구성요소의 기본 CPU 및 메모리 요청과 한도 재정의

pod 밀도가 높은 클러스터는 높은 로깅 및 모니터링 오버헤드가 발생합니다. 극단적인 경우에는 Stackdriver 구성요소가 CPU 및 메모리 사용률 한도에 가깝게 보고되거나 리소스 제한으로 인해 지속적으로 재시작될 수도 있습니다. 이 경우 Stackdriver 구성요소의 CPU, 메모리 요청, 한도의 기본값을 재정의하려면 다음 단계를 수행합니다.

  1. 다음 명령어를 실행하여 명령줄 편집기에서 Stackdriver 커스텀 리소스를 엽니다.

    kubectl -n kube-system edit stackdriver stackdriver

  2. Stackdriver 커스텀 리소스에서 spec 필드 아래에 resourceAttrOverride 섹션을 추가합니다.

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    resourceAttrOverride 섹션은 지정한 구성요소의 모든 기존 기본 한도 및 요청을 재정의합니다. resourceAttrOverride에서 지원하는 구성요소는 다음과 같습니다.

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    예시 파일은 다음과 같습니다.

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Stackdriver 커스텀 리소스에 대한 변경사항을 저장하려면 명령줄 편집기를 저장하고 종료합니다.

  4. 포드 상태를 확인합니다.

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    정상 상태의 포드에 대한 응답은 다음과 같습니다.

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. 구성요소의 포드 사양을 확인하여 리소스가 올바르게 설정되었는지 확인합니다.

    kubectl -n kube-system describe pod POD_NAME

    POD_NAME을 방금 변경한 포드의 이름으로 바꿉니다. 예를 들면 gke-metrics-agent-4th8r입니다.

    응답은 다음과 같습니다.

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

최적화된 측정항목 사용 중지

기본적으로 클러스터에서 실행되는 kube-state-metrics 배포는 최적화된 kube 측정항목 집합을 수집하고 Stackdriver에 보고합니다. 추가 측정항목이 필요한 경우 Google Distributed Cloud 측정항목 목록에서 대체 항목을 찾는 것이 좋습니다.

사용할 수 있는 교체 예시는 다음과 같습니다.

사용 중지된 측정항목 교체
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

최적화된 측정항목 기본 설정을 사용 중지하려면(권장하지 않음) 다음을 수행합니다.

  1. 명령줄 편집기에서 Stackdriver 커스텀 리소스를 엽니다.

    kubectl -n kube-system edit stackdriver stackdriver

  2. optimizedMetrics 필드를 false로 설정합니다.

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. 변경사항을 저장하고 명령줄 편집기를 종료합니다.

측정항목 서버

측정항목 서버는 다양한 자동 확장 파이프라인에 대한 컨테이너 리소스 측정항목의 소스입니다. 측정항목 서버는 kubelets에서 측정항목을 검색하고 Kubernetes Metrics API를 통해 노출합니다. 그런 후 HPA 및 VPA는 이러한 측정항목을 사용하여 자동 확장을 트리거할 시간을 결정합니다. 측정항목 서버는 부가기능 크기 조정 도구를 사용하여 확장됩니다.

포드 밀도가 높아 로깅 및 모니터링 오버헤드가 너무 많은 극단적인 경우에는 리소스 제한으로 인해 측정항목 서버가 중지되었다가 다시 시작될 수 있습니다. 이 경우 gke-managed-metrics-server 네임스페이스의 metrics-server-config configmap을 수정하고 cpuPerNode 값과 memoryPerNode 값을 변경하여 측정항목 서버에 더 많은 리소스를 할당할 수 있습니다.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

ConfigMap의 예시 콘텐츠는 다음과 같습니다.

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

ConfigMap을 업데이트한 후 다음 명령어를 사용하여 metrics-server 포드를 다시 만듭니다.

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Logging 및 Monitoring을 위한 구성 요구사항

Google Distributed Cloud에서 Cloud Logging 및 Cloud Monitoring을 사용 설정하려면 몇 가지 구성 요구사항이 있습니다. 이 단계는 Google 서비스 사용 설정 페이지의 Logging 및 Monitoring에 사용할 서비스 계정 구성 및 다음 목록에 포함되어 있습니다.

  1. Cloud Monitoring 작업공간을 Google Cloud 프로젝트 내에 만들어야 합니다. 이를 위해 Google Cloud 콘솔에서 Monitoring을 클릭하고 워크플로를 따릅니다.

  2. 다음 Stackdriver API를 사용 설정해야 합니다.

  3. Stackdriver 에이전트에서 사용되는 서비스 계정에 다음 IAM 역할을 할당해야 합니다.

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

가격 책정

Google Kubernetes Engine(GKE) Enterprise 버전 시스템 로그 및 측정항목에는 요금이 부과되지 않습니다.

Google Distributed Cloud 클러스터에서 Google Kubernetes Engine(GKE) Enterprise 버전 시스템 로그 및 측정항목에는 다음이 포함됩니다.

  • 관리자 클러스터에 있는 모든 구성요소의 로그 및 측정항목
  • 사용자 클러스터의 다음 네임스페이스에 있는 구성요소의 로그 및 측정항목: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

자세한 내용은 Google Cloud Observability 가격 책정을 참조하세요.

Cloud Logging 측정항목의 크레딧에 대한 자세한 내용은 영업팀에 가격 책정을 문의하세요.