클러스터 모니터링 가이드라인

개요

이 가이드에서는 모니터링 대상 및 Apigee Hybrid 배포 모니터링 방법에 대한 가이드라인을 제공합니다. 이 가이드는 하이브리드 클러스터 관리자 및 조직 관리자를 대상으로 합니다.

Google Cloud 모니터링을 처음 사용하는 경우 Google Cloud Monitoring 문서에서 측정항목 탐색기로 차트 만들기 및 알림 작동 방법을 참조하세요.

Apigee Hybrid 클러스터는 지정된 시간에 애플리케이션 및 시스템 서비스의 성능을 이해하는 데 도움이 되는 SLI(서비스 수준 지표) 측정항목을 제공합니다. 사용 가능한 측정항목의 전체 목록을 볼 수 있습니다.

Google Cloud Monitoring은 리소스 유형을 사용하여 모든 SLI 측정항목을 식별합니다. 모든 Apigee Hybrid 측정항목에 사용되는 리소스 유형은 세 가지입니다.

  • 시스템 수준 측정항목을 위한 k8s_container
  • Apigee API 프록시 측정항목을 위한 ProxyV2
  • Apigee API 대상 측정항목을 위한 TargetV2

리소스 유형에는 모든 연관된 측정항목에 적용되는 일반 라벨이 있습니다. 예를 들어 k8s_container 리소스 유형의 모든 측정항목에는 측정항목 라벨 외에도 cluster_name, pod_name, container_name 라벨을 사용할 수 있습니다. 리소스 유형 라벨과 측정항목 라벨의 조합은 클러스터 상태 및 성능을 효과적으로 모니터링하기 위해 사용됩니다.

알림 기준점: 완벽한 상황에서는 알림 기준점이 분명하고 제공된 문서에 알림을 트리거하는 값이 나열됩니다. 실제로는 Apigee에서 허용 가능한 성능이 무엇이고, 서비스 및 인프라의 위험한 리소스 사용이 무엇인지 정의하는 것이 다소 명확하지 않습니다. 알림 기준점은 특정 트래픽 패턴 및 SLO/SLA 계약에 따라 크게 달라집니다.

알림 기준점 최적화 및 결정은 서비스 및 인프라 사용에 따라 변경될 수 있으므로, 상시적인 프로세스입니다. 알림에 경고 및 중요 기준점을 사용하세요.

  • 정상: 값이 경고 기준점보다 작습니다.
  • 우려: 값이 경고 기준점보다 크지만 위기 기준점보다는 작습니다.
  • 위기: 값이 위기 기준점보다 큽니다.

고객은 고객이 아래 제공된 MQL을 사용하여 만들 수 있는 Cloud Monitoring 대시보드 또는 Apigee 분석인지에 관계없이 '정상' 상태를 식별하고 그에 맞게 알림 기준점을 조정할 수 있도록 제공된 도구를 사용하여 최적의 기준점을 결정합니다.

하이브리드 클러스터 모니터링은 트래픽, 데이터베이스, Apigee 컨트롤 플레인, 인프라 모니터링의 4가지 일반 그룹으로 분류할 수 있습니다. 다음 섹션에서는 이러한 그룹에 대해 자세히 설명합니다.

트래픽

Apigee 프록시 및 대상 SLI 측정항목은 API 프록시 및 대상에 대한 요청/응답 수와 지연 시간을 제공합니다. Apigee 정책 지연 시간 SLI 측정항목은 정책 응답 지연 시간을 제공합니다. 이러한 SLI 측정항목은 Apigee API 트래픽 모니터링을 위한 범위를 제공합니다.

요청 비율

프록시 요청 수

사용 사례: proxyv2/request_count를 사용하여 프록시 요청 수를 모니터링합니다. proxyv2/request_count 차트에는 프록시의 요청 비율이 표시됩니다. 이 차트는 높은 요청 비율을 수신하는 프록시, 요청 비율 패턴, 특정 프록시의 비정상적인 요청 호출 급증을 식별하는 데 유용합니다. API 트래픽에서 예기치 않은 비정상적인 급증은 봇 또는 API 프록시 공격과 관련된 보안 우려 사항일 수 있습니다. 이와 비슷하게 일반적인 트래픽의 대규모 저하는 Apigee 업스트림 구성요소의 연결 또는 클라이언트 문제를 나타낼 수 있습니다.

리소스 유형 ProxyV2
측정항목 proxyv2/request_count
그룹화 기준 method 및 모든 ProxyV2 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 비정상적인 request_count spike/drop 알림과 같은 이벤트
알림 기준점 없음
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method],
  [value_request_count_aggregate: aggregate(value.request_count)]

대상 요청 수

사용 사례: targetv2/request_count를 사용하여 Apigee 런타임 대상 요청 수를 모니터링합니다. targetv2/request_count 차트에는 Apigee 대상에서 수신되는 요청 비율이 표시됩니다. 이 차트는 요청 비율이 더 높은 대상, 요청 비율 패턴, 특정 대상에 대한 요청 호출의 비정상적인 급증을 확인하는 데 유용할 수 있습니다.

리소스 유형 TargetV2
측정항목 targetv2/request_count
그룹화 기준 method 및 모든 TargetV2 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 비정상적인 request_count spike/drop 알림과 같은 이벤트
알림 기준점 없음
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/request_count'
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, metric.endpoint],
  [value_request_count_aggregate: aggregate(value.request_count)]

오류율

프록시 오류 응답 수

사용 사례: proxyv2/response_count를 사용하여 프록시 오류 응답 비율을 모니터링합니다. proxyv2/response_count 차트에는 API 프록시의 요청 비율이 표시됩니다. 이 차트는 요청 오류율이 더 높은 프록시 또는 특정 프록시의 요청 호출에서 비정상적인 오류 급증을 확인하는 데 유용합니다.

리소스 유형 ProxyV2
측정항목 proxyv2/response_count
필터링 기준 response_code != 200

정규식을 사용하여 2xx 및 3xx response_code를 모두 제외합니다. 예를 들면 다음과 같습니다.

"response_code !=~ 1.*| 2.*|3.*"
그룹화 기준 메서드, response_code, fault_code, fault_source, apigee_fault, 모든 ProxyV2 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 프록시 응답 오류율: 총 응답 오류 / 총 응답 수
  • 총 응답 오류 = 필터 response_code가 200이 아닌 proxyv2/response_count 합계
  • 총 응답 수 = proxyv2/response_count 합계
알림 기준점 설치 SLO에 따라 다릅니다. 프로덕션 및 비프로덕션 설치는 기준점이 다를 수 있습니다. 예를 들어 프로덕션의 경우 프록시 응답 500 오류율이 5분 동안 5%일 때 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.fault_code,
   metric.fault_source, metric.apigee_fault],
  [value_response_count_aggregate: aggregate(value.response_count)]
Google Cloud 작업 알림 정책 MQL 예시: 
fetch apigee.googleapis.com/ProxyV2::apigee.googleapis.com/proxyv2/response_count
| {
   filter (metric.response_code == '500')
   ;
   ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'

대상 오류 응답 수

사용 사례: targetv2/response_count를 사용하여 API 대상 오류 응답 비율을 모니터링합니다. targetv2/response_count 차트에는 API 대상의 요청 비율이 표시됩니다. 이 차트는 요청 비율이 높은 대상 또는 요청 호출의 비정상적인 오류 급증을 식별하는 데 유용할 수 있습니다.

리소스 유형 TargetV2
측정항목 targetv2/response_count
필터링 기준 response_code != 200

정규식을 사용하여 2xx 및 3xx response_code를 모두 제외합니다. 예를 들면 다음과 같습니다.

"response_code !=~ 1.*| 2.*|3.*"
그룹화 기준 method 및 모든 TargetV2 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 프록시 응답 오류율, 예를 들면 총 응답 오류 / 총 응답 수입니다.
  • 총 응답 오류 = 필터 response_code가 200이 아닌 targetv2/response_count 합계
  • 총 응답 수 = targetv2/response_count 합계
알림 기준점 설치 SLO에 따라 다릅니다. 예를 들어 프로덕션의 경우 대상 응답 오류율이 3분 동안 5%일 때 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/TargetV2
| metric 'apigee.googleapis.com/targetv2/response_count'
| filter (metric.response_code != '200')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.type, metric.endpoint,
   metric.response_code],
  [value_response_count_aggregate: aggregate(value.response_count)]

지연 시간

프록시 지연 시간 백분위수

사용 사례: proxyv2/latencies_percentile을 사용하여 요청에 대한 모든 API 프록시 응답의 지연 시간 백분위수(p50, p90, p95, p99)를 모니터링합니다. proxyv2/latencies_percentile 차트는 전체 API 프록시 요청 지연 시간에 대해 Apigee API 프록시의 지연 시간을 식별하는 데 유용할 수 있습니다.

리소스 유형 ProxyV2
측정항목 proxyv2/latencies_percentile
필터링 기준 percentile = p99
그룹화 기준 메서드, 백분위수, 모든 ProxyV2 리소스 유형 라벨
애그리게이터 p99(99번째 백분위수)
알림 고려사항 p99 latencies_percentile의 높은 값
알림 기준점 설치 SLO에 따라 다릅니다. 예를 들어 프로덕션의 경우 프록시 p99 latencies_percentile의 값이 5분 동안 5초일 때 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

대상 지연 시간 백분위수

사용 사례: targetv2/latencies_percentile을 사용하여 요청에 대한 모든 API 프록시 응답의 지연 시간 백분위수(p50, p90, p95, p99)를 모니터링합니다. targetv2/latencies_percentile 차트는 Apigee API 프록시 대상이 요청에 응답하는 총 시간을 식별합니다. 이 값에는 Apigee API 프록시 오버헤드가 포함되지 않습니다.

리소스 유형 TargetV2
측정항목 targetv2/latencies_percentile
필터링 기준 percentile = p99
그룹화 기준 method, 백분위수, 모든 TargetV2 리소스 유형 라벨
애그리게이터 p99(99번째 백분위수)
알림 고려사항 p99 latencies_percentile의 높은 값
알림 기준점 설치 SLO에 따라 다릅니다. 예를 들어 프로덕션의 경우 대상 p99 latencies_percentile의 값이 5분 동안 5초일 때 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/proxyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.method, metric.percentile],
  [value_latencies_percentile_mean_percentile:
     percentile(value_latencies_percentile_mean, 99)]

정책 지연 시간 백분위수

사용 사례: policyv2/latencies_percentile을 사용하여 모든 Apigee 정책의 처리 지연 시간 백분위수(p50, p90, p95, p99)를 모니터링합니다. policyv2/latencies_percentile 차트는 전체 API 프록시 요청 지연 시간에 대해 Apigee API 정책의 지연 시간을 식별하는 데 유용할 수 있습니다.

리소스 유형 ProxyV2
측정항목 proxyv2/latencies_percentile
필터링 기준 percentile = p99
그룹화 기준 메서드, 백분위수, 모든 ProxyV2 리소스 유형 라벨
애그리게이터 p99(99번째 백분위수)
알림 고려사항 p99 latencies_percentile의 높은 값
알림 기준점 설치 SLO에 따라 다릅니다. 예를 들어 프로덕션의 경우 프록시 p99 latencies_percentile의 값이 5분 동안 5초일 때 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch apigee.googleapis.com/ProxyV2
| metric 'apigee.googleapis.com/policyv2/latencies_percentile'
| filter (metric.percentile == 'p99')
| group_by 1m,
  [value_latencies_percentile_mean: mean(value.latencies_percentile)]
| every 1m
| group_by [metric.policy_name, metric.percentile],
  [value_latencies_percentile_mean_aggregate:
     aggregate(value_latencies_percentile_mean)]

데이터베이스

Cassandra

Apigee Cassandra 데이터베이스 서버에는 여러 개의 Cassandra SLI 측정항목이 있습니다. 이러한 SLI 측정항목은 Apigee Cassandra 서비스에 대해 포괄적인 모니터링을 제공할 수 있습니다. 최소한 Cassandra 서비스 상태에 대해 Cassandra 리소스 사용(CPU, 메모리, 디스크 볼륨)과 함께 클라이언트의 읽기 및 쓰기 요청 지연 시간을 모니터링해야 합니다.

Cassandra 읽기 요청 비율

사용 사례: cassandra/clientrequest_rate(범위 = 읽기) SLI 측정항목은 지정된 특정 시간에 Cassandra 서비스 읽기 요청 평균 비율에 대한 인사이트를 제공합니다. 이러한 측정항목은 클라이언트의 읽기 요청 활동 수준 추세를 이해하는 데 도움이 됩니다.

리소스 유형 k8s_container
측정항목 cassandra/clientrequest_rate
필터링 기준 scope = Read 및 unit = OneMinuteRate
그룹화 기준 scope, unit, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 갑작스럽고 예기치 않은 읽기 요청 비율의 급증 또는 저하와 같이 클라이언트 쿼리 패턴에서 모든 잠재적인 문제 또는 중요한 변경사항을 고려합니다.
알림 기준점 없음
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra 쓰기 요청 비율

사용 사례: cassandra/clientrequest_rate(범위 = 쓰기) SLI 측정항목은 지정된 특정 시간에 Cassandra 서비스 쓰기 요청 평균 비율에 대한 인사이트를 제공합니다. 이러한 측정항목은 클라이언트의 쓰기 요청 활동 수준 추세를 이해하는 데 도움이 됩니다.

리소스 유형 k8s_container
측정항목 cassandra/clientrequest_rate
필터링 기준 scope = Read 및 unit = OneMinuteRate
그룹화 기준 scope, unit, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 추가 조사가 보장되는 갑작스럽고 예기치 않은 쓰기 요청의 급증 또는 저하와 같이 클라이언트 쿼리 패턴에서 모든 잠재적인 문제 또는 중요한 변경사항을 고려합니다.
알림 기준점 없음
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra 읽기 요청 지연 시간

사용 사례: cassandra/clientrequest_latency(범위 = 읽기) SLI 측정항목은 Cassandra 서비스 읽기 요청 지연 시간(99번째 백분위수, 95번째 백분위수, 75번째 백분위수)을 제공합니다. 이러한 측정항목은 Cassandra 성능을 전반적으로 확인하는 데 도움이 되며, 사용 패턴의 변화 또는 시간 경과에 따른 자체 매니페스팅 문제를 나타낼 수 있습니다.

리소스 유형 k8s_container
측정항목 cassandra/clientrequest_latency
필터링 기준 scope = Read 및 unit = 99thPercentile
그룹화 기준 scope, unit, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 읽기 요청 지연 시간 SLI에 99번째 백분위수 지연 시간이 연속적으로 상향 조정되는 것으로 표시되는 경우를 고려합니다.
알림 기준점 Cassandra 서비스의 SLO에 따라 달라집니다. 예를 들어 프로덕션에서는 99번째 백분위수의 읽기 clientrequest_latency 값이 3분 동안 5초일 대 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Cassandra 쓰기 요청 지연 시간

사용 사례: cassandra/clientrequest_latency(범위 = 쓰기) SLI 측정항목은 Cassandra 서비스 쓰기 요청 지연 시간(99번째 백분위수, 95번째 백분위수, 75번째 백분위수)을 제공합니다. 이러한 측정항목은 Cassandra 성능을 전반적으로 확인하는 데 도움이 되며, 사용 패턴의 변화 또는 시간 경과에 따른 자체 매니페스팅 문제를 나타낼 수 있습니다.

리소스 유형 k8s_container
측정항목 cassandra/clientrequest_latency
필터링 기준 scope = Write 및 unit = 99thPercentile
그룹화 기준 scope, unit, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 쓰기 요청 지연 시간 SLI에 99번째 백분위수 지연 시간이 연속적으로 상향 조정되는 것으로 표시되는 경우를 고려합니다.
알림 기준점 Cassandra 서비스의 SLO에 따라 달라집니다. 예를 들어 프로덕션에서는 99번째 백분위수의 쓰기 clientrequest_latency 값이 3분 동안 5초일 대 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == '99thPercentile')
| group_by 1m,
  [value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
  [value_clientrequest_latency_mean_aggregate:
     aggregate(value_clientrequest_latency_mean)]

Apigee 컨트롤 플레인

Apigee 동기화 담당자 서비스 SLI 측정항목은 요청 및 응답 수와 Apigee 컨트롤 플레인 및 Hybrid 런타임 영역 사이의 지연 시간을 제공합니다. 런타임 영역에서 실행되는 동기화 담당자 인스턴스는 컨트롤 플레인을 정기적으로 폴링하고, 계약을 다운로드하고, 로컬 런타임 인스턴스에 동일하게 제공해야 합니다.

요청 비율

업스트림 요청 수

사용 사례: upstream/request_count 측정항목은 동기화 담당자 서비스가 Apigee 컨트롤 플레인에 수행하는 요청 수를 나타냅니다.

리소스 유형 k8s_container
측정항목 upstream/request_count
필터링 기준 container_name = apigee-synchronizer 및 type = CONTRACT
그룹화 기준 method, type, container_name, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 request_count 급증 또는 저하 알림과 같은 트래픽 이상치에 이를 사용합니다.
알림 기준점 없음
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/request_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by [metric.method, metric.type, resource.container_name],
  [value_request_count_aggregate: aggregate(value.request_count)]

오류율

업스트림 응답 수

사용 사례: upstream/response_count SLI 측정항목은 동기화 담당자가 Apigee 컨트롤 플레인에서 수신한 응답 수를 제공합니다. 이 차트는 Apigee Hybrid 런타임 영역 및 컨트롤 플레인 사이의 연결 또는 구성 문제를 식별하는 데 유용할 수 있습니다.

리소스 유형 k8s_container
측정항목 upstream/request_count
필터링 기준 method, response_type, container_name, 모든 k8s_container 리소스 유형 라벨
그룹화 기준
애그리게이터 sum
알림 고려사항 Apigee 컨트롤 플레인에서 반환된 200 이외의 응답 코드를 포함하는 upstream/response_count 측정항목에 오류가 있으면 해당 오류에 대한 추가 조사가 필요합니다.
알림 기준점 Cassandra 서비스의 SLO에 따라 달라집니다. 예를 들어 프로덕션에서는 동기화 담당자에서 3분 마다 response_code 오류가 1회 넘게 발생하는 경우 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'apigee.googleapis.com/upstream/response_count'
| filter
  (resource.container_name == 'apigee-synchronizer')
  && (metric.response_code != '200' && metric.type == 'CONTRACT')
| align rate(1m)
| every 1m
| group_by
  [metric.method, metric.response_code, metric.type, resource.container_name],
  [value_response_count_aggregate: aggregate(value.response_count)]

인프라

GKE 및 기타 Kubernetes 플랫폼은 시스템 수준의 SLI 측정항목을 제공합니다. SLI 측정항목 라벨을 필터링 및 그룹화하여 특정 컨테이너 및 해당 리소스 사용을 모니터링할 수 있습니다. Apigee 런타임 클러스터 인프라 상태 및 가용성을 모니터링하기 위해 클러스터 관리자는 CPU, 메모리, 디스크, 컨테이너 다시 시작 횟수와 같은 컨테이너 및 포드 일반 리소스 사용을 모니터링할 수 있습니다. 사용 가능한 측정항목 및 라벨에 대한 자세한 내용은 GKE 문서를 참조하세요.

다음 표에는 각 서비스에 대해 모니터링할 수 있는 서비스 및 컨테이너 일부가 나열됩니다.

서비스 이름 컨테이너 이름
Cassandra apigee-cassandra
메시지 프로세서(MP) apigee-runtime
동기화 담당자 apigee-synchronizer
원격 분석 apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

컨테이너/포드

재시작 횟수

사용 사례: kubernetes.io/container/restart_count 시스템 SLI 측정항목은 컨테이너가 다시 시작된 횟수를 제공합니다. 이 차트는 컨테이너의 비정상 종료/다시 시작이 자주 발생하는지 식별하는 데 유용할 수 있습니다. 특정 서비스 컨테이너를 특정 서비스 컨테이너 모니터링에 대한 측정항목 라벨로 필터링할 수 있습니다.

다음은 Cassandra 컨테이너에 대한 kubernetes.io/container/restart_count 측정항목 사용을 보여줍니다. 위 테이블에서 컨테이너에 이 측정항목을 사용할 수 있습니다.

리소스 유형 k8s_container
측정항목 kubernetes.io/container/restart_count
필터링 기준 namespace_name = apigee 및 container_name =~ .*cassandra.*
그룹화 기준 cluster_name, namespace_name, pod_name, container_name, 모든 k8s_container 리소스 유형 라벨
애그리게이터 sum
알림 고려사항 컨테이너 다시 시작이 자주 수행되는 경우 근본 원인에 대한 추가 조사가 필요합니다. OOMKilled, 데이터 디스크 꽉 참, 구성 문제 등 컨테이너가 다시 시작되는 이유는 여러 가지입니다.
알림 기준점 설치 SLO에 따라 다릅니다. 예를 들어 프로덕션의 경우 컨테이너가 30분 내에 5번 넘게 다시 시작되면 이벤트 알림을 트리거합니다.
Cloud Monitoring 대시보드 MQL 쿼리: 
fetch k8s_container
| metric 'kubernetes.io/container/restart_count'
| filter
  (resource.container_name =~ '.*cassandra.*'
   && resource.namespace_name == 'apigee')
| align rate(1m)
| every 1m
| group_by
  [resource.cluster_name, resource.namespace_name, resource.pod_name,
   resource.container_name],
  [value_restart_count_aggregate: aggregate(value.restart_count)]