이 문서에서는 알림 비용을 줄이기 위해 사용할 수 있는 전략에 대해 설정합니다.
더 많은 리소스에 작동하도록 알림 정책 통합
조건당 $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 100개(각 VM이 하나의 서비스에 속함)
- 총 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은 측정기준 측정항목 시스템을 사용합니다. 여기서 모든 측정항목의 총 [카디널리티][카디널리티]는 모니터링 리소스 수에 해당 측정항목의 라벨 조합 수를 곱한 값과 같습니다. 예를 들어 측정항목을 내보내는 VM이 100개 있고 이 측정항목에 각각 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 쿼리를 사용하는 경우 top-streams 연산자를 사용하여 가장 높은 값으로 반환된 시계열을 선택할 수 있습니다.
예를 들어 PromQL 쿼리의 topk(metric, 5) 절은 각 실행 기간에 반환되는 시계열 수를 5개로 제한합니다.
시계열을 상위 개수로 제한하면 다음과 같은 데이터 누락 및 잘못된 알림이 발생할 수 있습니다.
- N개를 초과하는 시계열이 기준점을 위반하면 상위 N개 시계열을 벗어난 데이터가 누락됩니다.
- 기준점을 위반하는 시계열이 상위 N개 시계열 외부에서 발생하면 제외된 시계열이 여전히 기준점을 위반하고 있음에도 불구하고 이슈가 자동으로 종료될 수 있습니다.
- 조건 쿼리에는 정상적으로 작동하는 기준 시계열과 같은 중요한 컨텍스트가 표시되지 않을 수 있습니다.
이러한 위험을 완화하려면 N에 대해 큰 값을 선택하고 개별 Kubernetes 컨테이너의 알림과 같이 여러 시계열을 평가하는 알림 정책에서만 최상위 스트림 연산자를 사용하세요.
실행 기간 길이 늘리기(PromQL만 해당)
조건이 PromQL 쿼리를 사용하는 경우 조건에서 evaluationInterval 필드를 설정하여 실행 기간의 길이를 수정할 수 있습니다.
평가 간격이 길수록 한 달에 반환되는 시계열이 줄어듭니다. 예를 들어 15초 간격의 조건 쿼리는 30초 간격의 쿼리보다 두 배 자주 실행되고 1분 간격의 쿼리는 30초 간격의 쿼리보다 절반 자주 실행됩니다.