이 문서에서는 알림 비용을 줄이기 위해 사용할 수 있는 전략에 대해 설정합니다.
더 많은 리소스로 운영되도록 알림 정책 통합
조건당 $1.50의 비용이 발생하므로 하나의 알림 정책을 사용하여 각 리소스를 모니터링하는 것보다 하나의 알림 정책을 사용하여 여러 리소스를 모니터링하는 것이 더 비용 효율적입니다. 다음 예를 고려하세요.
예시 1
데이터
- VM 100개
- 각 VM은 하나의 측정항목
metric_name을 내보냄 metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
- 알림 조건 1개
- 조건이 VM 수준으로 집계됨
- 30초 실행 기간
- 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
- 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
- 월별 총비용: $4.52/월
예시 2
데이터
- VM 100개
- 각 VM은 하나의 측정항목
metric_name을 내보냄 metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
- 조건 100개
- 각 조건이 필터링되고 하나의 VM으로 집계됨
- 30초 실행 기간
- 조건 비용: 조건 100개 * 월별 $1.50 = 월별 $150
- 시계열 비용 : 조건 100개 * 기간별 조건당 반환된 시계열 1개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
- 총비용: $153.02/월
두 예시 모두 동일한 수의 리소스를 모니터링합니다. 하지만 예시 2는 100개의 알림 정책을 사용하지만 예시 1은 알림 정책을 하나만 사용합니다. 따라서 예시 1은 매월 거의 $150 저렴합니다.
알림을 보내야 하는 수준으로만 집계
높은 세분화 수준으로 집계하면 낮은 세분화 수준으로 집계하는 것보다 비용이 높습니다. 예를 들어 Google Cloud 프로젝트 수준으로 집계하는 것이 클러스터 수준으로 집계하는 것보다 저렴하고, 클러스터 수준으로 집계하는 것은 클러스터 및 네임스페이스 수준으로 집계하는 것보다 저렴합니다.
다음 예를 고려하세요.
예시 1
데이터
- VM 100개
- 각 VM은 하나의 측정항목
metric_name을 내보냄 metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
- 알림 조건 1개
- 조건이 VM 수준으로 집계됨
- 30초 실행 기간
- 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
- 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
- 월별 총비용: $4.52/월
예시 4
데이터
- 각 VM이 하나의 서비스에 속하는 VM 100개
- 총 서비스 5개
- 각 VM은 하나의 측정항목
metric_name을 내보냄 metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음
- 조건 1개
- 조건이 서비스 수준으로 집계됨
- 30초 실행 기간
- 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
- 시계열 비용 기간당 반환된 시계열 5개 * 월별 기간 86,400개 = 월별 반환된 시계열 432,000개 * 시계열 100만 개당 $0.35 = 월별 $0.14
- 총비용: $1.64/월
예시 5
데이터
- VM 100개
- 각 VM은 하나의 측정항목
metric_name을 내보냄 metric_name에 100개의 라벨이 있고, 각 라벨에는 1,000개의 값이 있음
- 조건 1개
- 조건이 VM 수준으로 집계됨
- 30초 실행 기간
- 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
- 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 850만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
- 월별 총비용: $4.52/월
예시 1과 예시 4 비교: 두 예시 모두 동일한 기본 데이터에서 작동하며 단일 알림 정책이 있습니다. 그러나 예시 4의 알림 정책이 서비스에 집계되므로 VM에 더 세부적으로 집계되는 예시 1의 알림 정책보다 비용이 저렴합니다.
또한 예시 1과 예시 5를 비교하면, 예시 5의 측정항목 카디널리티는 예시 1의 측정항목 카디널리티보다 10,000배 더 높습니다. 그러나 예시 1과 예시 5의 알림 정책이 모두 VM에 집계되고 두 예시의 VM 수가 동일하므로 예시의 가격은 동일합니다.
알림 정책을 구성할 때 사용 사례에 가장 적합한 집계 수준을 선택하세요. 예를 들어 CPU 사용률에 대한 알림이 중요한 경우 VM 및 CPU 수준으로 집계할 수 있습니다. 엔드포인트별 지연 시간에 대한 알림이 중요한 경우 엔드포인트 수준으로 집계할 수 있습니다.
집계되지 않은 원시 데이터에 대한 알림 표시 안 함
Monitoring은 측정기준 측정항목 시스템을 사용합니다. 여기서 모든 측정항목의 총 [카디널리티][카디널리티]는 모니터링 리소스 수에 해당 측정항목의 라벨 조합 수를 곱한 값과 같습니다. 예를 들어 100개의 VM에서 측정항목을 내보내고 이 측정항목에 각각 10개의 값이 있는 라벨이 10개 있는 경우 총 카디널리티는 100 * 10 * 10 = 10,000입니다.
카디널리티가 확장되는 방식 때문에 원시 데이터에 대한 알림 비용은 매우 클 수 있습니다. 이전 예시에서는 실행 기간마다 시계열이 10,000개 반환됩니다. 그러나 VM에 집계하면 기본 데이터의 라벨 카디널리티에 관계없이 실행 기간별로 100개의 시계열만 반환됩니다.
또한 원시 데이터에 대한 알림을 사용하면 측정항목에 새 라벨이 수신될 때 시계열이 증가할 위험이 있습니다. 이전 예시에서 사용자가 측정항목에 새 라벨을 추가하면 총 카디널리티가 100 * 11 * 10 = 11,000개의 시계열로 증가합니다. 이 경우 알림 정책이 변경되지 않아도 반환된 시계열 수는 실행 기간마다 1,000개씩 증가합니다. 대신 VM으로 집계하면 기본 카디널리티가 증가해도 여전히 100개의 시계열만 반환됩니다.
불필요한 응답 필터링
알림 요구에 필요한 데이터만 평가하도록 조건을 구성합니다. 문제를 해결하기 위한 조치를 취하지 않는다면 알림 정책에서 해당 부분을 제외하세요. 예를 들어 인턴의 개발 VM에 대한 알림이 필요하지 않을 수 있습니다.
불필요한 알림과 비용을 줄이기 위해 중요하지 않은 시계열을 필터링하는 것도 하나의 방법입니다. Google Cloud 메타데이터 라벨을 사용하여 애셋에 카테고리로 태그를 지정한 후 불필요한 메타데이터 카테고리를 필터링할 수 있습니다.
최상위 스트림 연산자를 사용하여 반환되는 시계열 수 줄이기
조건에서 PromQL 또는 MQL 쿼리를 사용하는 경우 최상위 스트림 연산자를 사용하여 가장 높은 값으로 반환된 시계열 수를 선택할 수 있습니다.
예를 들어 PromQL 쿼리의 topk(metric, 5) 절은 각 실행 기간에서 반환되는 시계열 수를 5개로 제한합니다.
최상위 시계열 수로 제한하면 데이터 누락 및 다음과 같은 알림 오류가 발생할 수 있습니다.
- N개를 초과하는 시계열이 기준점을 위반하면 상위 N개 시계열을 벗어난 데이터가 누락됩니다.
- 위반 시계열이 상위 N개 시계열 외부에서 발생하는 경우 제외된 시계열이 여전히 기준을 위반해도 이슈가 자동으로 종료될 수 있습니다.
- 조건 쿼리에 의도한 대로 작동하는 기준 시계열과 같은 중요한 컨텍스트가 표시되지 않을 수 있습니다.
이러한 위험을 완화하려면 N에 대해 큰 값을 선택하고 개별 Kubernetes 컨테이너의 알림과 같이 여러 시계열을 평가하는 알림 정책에서만 최상위 스트림 연산자를 사용하세요.
실행 기간 길이 늘리기(PromQL만 해당)
조건이 PromQL 쿼리를 사용하는 경우 조건에서 evaluationInterval 필드를 설정하여 실행 기간의 길이를 수정할 수 있습니다.
평가 간격이 길수록 매월 반환되는 시계열 수가 줄어듭니다. 예를 들어 15초 간격의 조건 쿼리는 30초 간격의 쿼리보다 2배, 1 -분 간격은 30초 간격의 쿼리만큼 자주 실행됩니다.