모니터링 시스템에는 메트릭 수집을 위한 두가지 방식의 메커니즘이 존재합니다.
바로 Pull 방식과 Push 방식입니다. 프로메테우스는 어떤 방식의 메커니즘을 사용하나요?
또한 Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해보세요.
HTTP를 통한 Pulling은 다음과 같은 많은 이점을 제공합니다.
푸시해야 하는 경우 Pushgateway
를 사용해야 합니다.
때때로 긁어낼 수 없는 구성 요소를 모니터링해야 하는 경우, Prometheus Pushgateway를 사용하면 수명 이 짧은 서비스 수준 일괄 작업 에서 Prometheus가 스크랩할 수 있는 중간 작업 으로 시계열을 푸시할 수 있습니다.
https://prometheus.io/docs/instrumenting/pushing/
https://github.com/prometheus/pushgateway
어떤 조직의 SLO가 다음과 같습니다.
"GET 호출의 99%는 10ms 이내에 수행되어야 한다" 그렇다면, 이러한 SLO를 달성하려면 어떤 메트릭을 수집하고 어떻게 계산해야 할까요? (척도는 표준화된 범용 지표를 사용합니다)
SLO ( 서비스 수준 목표 ) 는 서비스 공급자 와 고객 간의 SLA(서비스 수준 계약)의 핵심 요소입니다.
SLO는 서비스 제공자의 성과를 측정하는 수단으로 합의되며, 오해에 기반한 두 당사자 간의 분쟁을 피하기 위한 방법으로 요약됩니다.
SLO는 가용성, 처리량, 빈도, 응답 시간 또는 품질과 같은 SLA의 측정 가능한 특정 특성입니다. 이러한 SLO는 함께 제공자와 고객 간의 예상 서비스를 정의하기 위한 것이며 서비스의 긴급성, 리소스 및 예산에 따라 다릅니다. SLO는 고객이 공급자에게 기대할 수 있는 서비스 수준을 정의하는 정량적 수단을 제공합니다.
SLO 달성 값을 생성하기 위해 결합되는 하나 이상의 서비스 품질 (QoS) 측정( 서비스 수준 표시기 , SLI)으로 구성될 수 있습니다. 예를 들어, 가용성 SLO는 각각 QoS 가용성 측정을 가질 수 있는 여러 구성요소에 의존할 수 있습니다. QoS 측정을 SLO 달성 값으로 결합하는 것은 서비스의 특성과 아키텍처에 따라 다릅니다.
Sturm과 Morris는 SLO가 다음과 같아야 한다고 주장합니다.
SLO를 여러 구성 요소로 나눌 수 있습니다.
선택적으로 EvaluationEvent가 SLO에 할당될 수 있으며, EvaluationEvent는 SLO가 표현식을 충족하는지 확인하기 위해 검사할 측정으로 정의됩니다.
SLO는 일반적으로 달성 가치 또는 서비스 수준, 목표 측정, 측정 기간, 측정 위치 및 방법 측면에서 지정되어야 합니다. 예를 들어, "헬프데스크에 대한 호출의 90%는 ACD 시스템 에서 보고한 대로 한 달 동안 측정한 20초 이내에 응답해야 합니다." 결과는 목표 응답 시간에 도달한 시간의 백분율로 보고한 다음 원하는 서비스 수준(90%)과 비교할 수 있습니다.
측정 유형 | SLO 요구 사항 예시 | 측정 기간 |
---|---|---|
유효성 | 애플리케이션은 99.95%의 시간 동안 사용 가능합니다. | 1년 이상 |
서비스 데스크 응답 | 헬프 데스크 통화의 75%가 1분 이내에 응답됩니다. 헬프 데스크 통화의 85%가 2분 이내에 응답됩니다. 헬프데스크 전화는 3분 이내에 100% 응답합니다. | 한 달 이상 |
사고 대응 시간 | 심각도 1 티켓의 99%가 3시간 이내에 해결됩니다. 심각도 2 티켓의 98%가 8시간 이내에 해결됩니다. 심각도 3 티켓의 98%는 영업일 기준 3일 이내에 해결됩니다. 심각도 4 티켓의 98%는 영업일 기준 5일 이내에 해결됩니다. | 4분의 1 이상 |
응답 시간 | TCP의 85%는 요청 수신 후 1.5초 이내에 응답 요청을 받은 후 4초 이내에 TCP의 99.5% 응답 | 한 달 이상 |
https://sre.google/workbook/slo-document/
https://sre.google/workbook/implementing-slos/