65일차 발표

• [C173] 모니터링 시스템에는 메트릭 수집을 위한 두가지 방식의 메커니즘이 존재합니다. 바로 Pull 방식과 Push 방식입니다. 프로메테우스는 어떤 방식의 메커니즘을 사용하나요? 또한 Pull 방식과 Push 방식은 어떻게 다르며, 장단점은 무엇인지, 또한 해당 방식을 사용하는 모니터링 도구는 어떤 것들이 있는지 연구해보세요.

 

PULL 방식

Pull 기반 모니터링 시스템은 이름에서 알 수 있듯 능동적으로 지표를 획득하는 모니터링 시스템으로, 모니터링이 필요한 객체는 원격으로 접근할 수 있는 능력이 필요하다.

 

에이전트는 메트릭 또는 유닛과 태그와 같은 메타데이터을 수집하고 중앙 시스템에 데이터 전송을 위한 필요한 정보를 가지고 있다. 중앙 모니터링 시스템에서 에이전트로부터 구성 및 메트릭 메타데이터를 가져온다. 에이전트는 보스이고 중앙 시스템은 스트링거가 있는 잡지처럼 에이전트와 에어전트가 보내는 것을 팔로우한다.

 

 

Prometheus, Datadog, collectd이 PULL 방식을 사용한다.

 

PULL 방식의 장점

 

• 풀 시스템은 일반적으로 언제든지 임시 및 계획되지 않은 메트릭 또는 다른 단위, 태그 등의 '동일한' 메트릭까지도 허용합니다. 이것은 특히 개발자가 언제든지 메트릭을 추가하기로 결정할 수 있는 DevOps 세계에서 풀의 큰 이점입니다. 
• 풀 시스템은 더 '현대적'인 경향이 있으며 메트릭과 함께 태그 및 추가 메타데이터를 더 잘 수용합니다. 또한 메트릭, 이벤트, 심지어 로그(반구조화된 이벤트) 사이의 경계가 모호해지기 시작하여 모두 함께 혼합됩니다. 이를 통해 훨씬 더 풍부한 쿼리, 시각화 및 문제 해결이 가능합니다.

 

 

 

 

 

PUSH 방식

푸시 기반 모니터링 시스템은 능동적으로 데이터를 획득하지 않지만 모니터링되는 개체는 적극적으로 지표를 푸시합니다.

 

메트릭은 중앙에서 정의되고 할당된 호스트 및 에이전트에 푸시됩니다. 이러한 시스템은 종종 자동 검색이 가능하지만 중앙에서 정의되고 모니터링 시스템을 통해 위아래로 흐른다. 중앙 시스템은 보스이고 에이전트는 군대처럼 명령에 따릅니다. 

 

 

Nagios, Zabbix이 PUSH 방식을 사용한다.

 

PUSH 방식의 장점

• 모든 것이 중앙 집중형이므로 전역 및 광범위하거나 좁은 범위의 변경이 매우 쉽습니다. 우리는 종종 Zabbix 시스템에서 메트릭을 추가 또는 비활성화를 하여 몇 분 안에 수천 개의 호스트 집합으로 롤아웃합니다. 마찬가지로 문제가 있는 단일 호스트 그룹에서 모니터링 메트릭 또는 빈도 등을 추가하거나 변경할 수 있으며 새로운 정보는 거의 즉시 도착한다.
• 푸시는 JMX 및 MySQL(또는 CloudWatch)과 같은 일반 모니터링 에이전트에서 특히 유용하다. 이 에이전트는 수백 가지 가능한 메트릭 중 하나를 얻을 수 있으므로 주어진 세트에서 언제든지 원하는 것을 지정하기만 하면 됩니다. 서버 및 서비스. 거의 실시간으로 매우 유연하고 역동적입니다.
• 중앙 시스템에는 종종 템플릿이 있어 새 호스트와 서비스를 매우 빠르고 쉽게 정의할 수 있으며 기존 템플릿에서 필요한 모든 것을 상속합니다. 이를 통해 몇 초 만에 복잡한 새 호스트 모니터링을 설정하고 수년간의 승인된 모범 사례를 자동으로 상속할 수 있습니다.
• 모든 데이터, 유형, 단위 등이 사전에 알려져 있고 종종 DBA와 같은 서비스 전문가에 의해 정의되기 때문에 중앙 구성은 잘 정의된 그래프, 지도 및 경고를 허용합니다.

 

	PUSH	PULL
발견	에이전트는 시작되는 즉시 메트릭을 자동으로 전송하여 즉시 감지하고 지속적으로 모니터링합니다. 검색 속도는 에이전트 수와 무관합니다.	검색을 위해서는 수집기가 주기적으로 주소 공간을 스윕하여 새 에이전트를 찾아야 합니다. 검색 속도는 검색 스윕 간격과 주소 공간 크기에 따라 다릅니다.
확장성	폴링 작업은 에이전트 간에 완전히 분산되어 선형 확장성을 제공합니다. 경량 중앙 수집기는 업데이트를 수신하고 측정값을 저장합니다. 에이전트가 고정된 측정 세트를 주기적으로 보내기 위한 최소한의 작업. 에이전트는 상태를 저장하지 않으며 데이터가 생성되는 즉시 내보냅니다.	중앙 폴러의 워크로드는 폴링된 장치의 수에 따라 증가합니다. 요청과 응답을 일치시키기 위해 요청을 생성하고 세션 상태를 유지하는 폴러에 대한 추가 작업. 에이전트가 요청을 구문 분석하고 처리하기 위한 추가 작업입니다. 에이전트는 나중에 폴러가 메트릭을 검색할 수 있도록 상태를 유지해야 하는 경우가 많습니다.
보안	푸시 에이전트는 네트워크 연결을 수신 대기하지 않기 때문에 본질적으로 원격 공격에 대해 안전합니다.	폴링 프로토콜은 잠재적으로 시스템을 원격 액세스 및 서비스 거부 공격에 노출시킬 수 있습니다.
운영 복잡성	에이전트에 필요한 최소 구성: 폴링 간격 및 수집기 주소. 에이전트에서 수집기로 측정값의 단방향 통신을 위해 방화벽을 구성해야 합니다.	Puller는 폴링할 장치 목록, 장치에 액세스하기 위한 보안 자격 증명 및 검색할 측정 집합으로 구성해야 합니다. 폴러와 에이전트 간의 양방향 통신을 허용하도록 방화벽을 구성해야 합니다.
지연 시간	푸시 모델의 낮은 오버헤드와 분산 특성으로 인해 측정이 더 자주 전송되어 관리 시스템이 변경 사항에 신속하게 대응할 수 있습니다. 또한 sFlow와 같은 많은 푸시 프로토콜이 UDP 위에 구현되어 측정의 비차단, 저지연 전송을 제공합니다.	폴링의 확장성 부족은 일반적으로 측정값 검색 빈도가 낮아져 성능에 대한 보기가 지연되어 관리 시스템이 변경 사항에 덜 민감하게 반응하게 됨을 의미합니다. 폴링과 관련된 양방향 통신은 측정값을 검색하기 전에 연결이 설정되고 인증될 때 대기 시간을 증가시킵니다.
유연성	상대적으로 유연하지 않음: 미리 결정된 고정 측정 세트를 주기적으로 내보냅니다.	유연성: 폴러는 언제든지 모든 메트릭을 요청할 수 있습니다.

 

++

 

 

 

 

 

 

https://blog.sflow.com/2012/08/push-vs-pull.html

https://steve-mushero.medium.com/push-vs-pull-configs-for-monitoring-c541eaf9e927

https://www.alibabacloud.com/blog/pull-or-push-how-to-select-monitoring-systems_599007

 

 

 

 

 

 

• [C174] 어떤 조직의 SLO가 다음과 같습니다. "GET 호출의 99%는 10ms 이내에 수행되어야 한다" 그렇다면, 이러한 SLO를 달성하려면 어떤 메트릭을 수집하고 어떻게 계산해야 할까요? (척도는 표준화된 범용 지표를 사용합니다)

SLI (서비스 수준 척도, Service Level Indicator)

서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값으로, 주요 SLI는 다음과 같다.

• 응답 속도: 요청에 대한 응답이 리턴되기까지의 시간
• 에러율: 전체 요청 수 대비
• 처리량(throughput): 초당 처리할 수 있는 요청 수
• 가용성: 서비스가 사용 가능한 상태로 존재하는 시간의 비율
• 내구성: 데이터 저장이 중요한 목적인 서비스의 경우 특히 중요

SLO (서비스 수준 목표, Service Level Objectives)

SLI에 의해 측정된 서비스 수준의 목표 값, 또는 일정 범위의 값을 의미합니다. 즉 SLO는 다음과 같이 표현됩니다.

SLI ≤ 목표치
최소값 ≤ SLI ≤ 최댓값

 

"GET 호출의 99%는 10ms 이내에 수행되어야 한다"는 요청에 대한 응답이 리턴되기까지의 시간이 10ms 이하이어야한다는 말이고 즉, 지연시간이 10ms 이내여야한다.

지연시간 계산법

histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[7d]))

 

잘못된 방법: 백분위수 집계

SLO를 계산할 때 가장 잘못 사용되는 기술은 백분위수 집계이다. 기본적인 집계 작업도 백분위수 메트릭으로 수용할 수 없으므로 백분위수를 평균화해서는 안 된다. 백분위수는 대부분의 원격 분석 시스템에서 얻을 수 있고 적은 노력으로 충분히 사용할 수 있기 때문에 대부분의 경우 집계 및 시스템 전체 성능 분석에 적합하다고 생각되지만 불행히도 데이터가 거짓말을 하고 있는지 판단할 수 있는 능력을 잃게 된다.

 

위 이미지는 서버 지연시간 분포를 측정하기 위해 사용되는 일반적인 그래프입니다. 6월 초부터 7월 말까지 두 달 동안 진행되며 여기의 모든 픽셀은 하나의 값을 나타냅니다. 50번째 백분위수 또는 평균은 요청의 약 절반(파란색 선 아래에 있는 요청)이 약 140밀리초보다 빠르게 제공되었고 약 절반은 140밀리초보다 느리게 제공되었음을 의미한다.

 

물론 대부분의 엔지니어는 고객의 절반이 아니라 99%가 훌륭한 경험을 받기를 원합니다. 따라서 평균 또는 50번째 백분위수를 계산하는 대신 99번째 백분위수를 계산하기 시작합니다. 맨 위에 있는 보라색 선을 보면 이러한 각 지점의 99번째 백분위수는 해당 픽셀이 그려지는 곳에서 수백, 수천 등의 많은 요청이 제공되었음을 나타냅니다. 해당 라인 아래의 요청 중 99%가 더 빨랐지만 위의 요청 중 1%는 더 느렸습니다. 이러한 요청이 얼마나 더 빠르거나 더 느린지 알 수 없으므로 상위 백분율만 보는 것은 매우 오해의 소지가 있다는 점에 유의하는 것이 중요합니다.

 

여기서 중요한 계산 문제는 그래프의 각 픽셀이 시간이 지남에 따라 해당 시간 슬롯에 발생한 모든 요청을 나타냅니다. 그래프에 1400개의 픽셀과 60일이 표시되어 있다고 가정해 보겠습니다. 즉, 각 픽셀은 한 시간 동안 발생하는 모든 요청을 나타냅니다. 따라서 오른쪽 상단의 피크를 상상할 수 있다면 99번째 백분위수에서 스파이크가 발생했습니다. 즉, 그래프에서 스파이크가 나타내는 시간에 실제로 발생한 요청은 몇 개입니까?

문제는 많은 도구가 99번째 백분위수를 계산하기 위해 데이터를 샘플링하는 기술을 사용한다는 것입니다. 1분마다와 같이 일정 기간 동안 해당 데이터를 수집합니다. 한 시간 동안 60개의 1분 99번째 백분위수 계산이 있고 전체 시간 동안의 99번째 백분위수가 무엇인지 알고 싶다면 이를 계산할 방법이 없습니다. 이 그래프가 하는 일: 축소하고 더 ​​이상 픽셀이 충분하지 않으면 해당 픽셀을 구성하는 포인트를 가져와 평균을 냅니다. 여기에서 실제로 보고 있는 것은 시간당 평균 99%이며 통계적으로 아무 의미가 없습니다.

이 점을 더 잘 설명하기 위해 아래에서 지연 분포 그래프를 확대한 모습을 살펴보겠습니다.

이 그래프는 롤링 1분 동안 90번째 백분위수를 계산하고 있으며 꽤 많이 튀는 것을 볼 수 있습니다. 백분위수를 집계하는 것은 매력적이지만, 특히 부하가 매우 변동성이 심한 경우에 실질적으로 잘못된 결과를 생성할 수 있습니다.

백분위수 메트릭을 사용하면 몇 시간 또는 몇 주에 대해 공식화된 정확한 서비스 수준 목표를 구현할 수 없습니다. 5분(또는 이와 유사한) 간격으로 백분위수를 저장하는 오픈 소스 및 상업용 시계열 데이터 모니터링 시스템이 상당히 많이 있습니다. 그러나 백분위수는 그래프의 시간 창에 있는 픽셀 수에 맞게 평균을 냈고 평균 데이터는 수학적으로 잘못되었습니다.

백분위수는 실제 시스템 모니터링의 주요 도구이지만 그 한계를 이해해야 합니다. 백분위수는 사용 제한 없이 거의 모든 모니터링 및 관찰 가능성 도구 세트에서 제공되기 때문에 운영자가 적용 방법의 결과를 이해할 필요 없이 쉽게 SLO 분석에 적용할 수 있습니다.

 

SLO 지연 시간 계산 방법 재고: 히스토그램

히스토그램(histogram)은 표로 되어 있는 도수 분포를 정보 그림으로 나타낸 것이다. 더 간단하게 말하면, 도수분포표를 그래프로 나타낸 것이다. 

 

서비스가 커지고 더 많은 요청을 처리할수록 데이터가 너무 많아 실시간으로 계산하기가 어려워지고 항상 저장하기 쉽지 않다. 예를 들어 99번째 백분위수를 계산한 다음 나중에 결정하려고 한다고 가정해볼때 만약 99번째 백분위수는 옳지 않으면 과거 로그를 보고 모든 것을 다시 계산해야만 한다. 이러한 로그는 계산을 수행 및 저장하는 데 비용이 많이 들 수 있다.

 

백분위수를 저장하는 것보다 더 나은 접근 방식은 단일 샘플을 저장하는 것이며 효율적이지만 통계적으로 유의미한 집계를 생성할 수 있는 방식으로 소스 샘플 데이터를 저장하는 것입니다. 히스토그램을 입력하는 것은 SLO 대기 시간을 계산하는 가장 정확하고 빠르며 저렴한 방법이다. 히스토그램은 값의 전체 범위가 일련의 간격(또는 "빈")으로 나뉘고 각 빈에 속하는 값의 수를 표시하는 연속형 변수의 분포를 나타냅니다. 히스토그램은 소수의 분위수를 저장하는 대신 대규모 데이터의 전체 분포를 저장할 수 있기 때문에 SLO 분석 또는 모든 고주파, 대용량 데이터에 이상적입니다. 히스토그램 데이터 사용의 장점은 시간이 지남에 따라 히스토그램을 집계할 수 있다는 것입니다.

 

SLO 관련 데이터의 경우 대부분의 실무자는 오픈 소스 히스토그램 라이브러리를 구현합니다. 많은 구현이 있지만 여기 Circonus에서는 로그 선형 히스토그램, 특히 OpenHistogram을 사용합니다. 스토리지 효율성과 통계적 정확성을 모두 제공합니다. 한 자릿수 샘플 크기에서 최악의 오류는 5%로 평균 백분위수에서 볼 수 있는 수백 퍼센트의 오류보다 훨씬 낫습니다. 일부 분석가는 t-digest와 같은 근사 히스토그램을 사용합니다. 그러나 이러한 구현은 종종 중앙값 근처에서 두 자릿수 오류율을 나타냅니다. 히스토그램 기반 구현에는 항상 일정 수준의 오류가 있지만 로그 선형과 같은 구현은 일반적으로 특히 많은 수의 샘플에서 해당 오류를 1% 미만으로 최소화할 수 있습니다.

위의 이 히스토그램에는 특정 대기 시간 분포(총 6백만 개의 대기 시간 샘플)에 대해 제공된 모든 단일 샘플이 포함됩니다. 예를 들어, 100만 개의 샘플이 370,000~380,000마이크로초 범위에 속하며 대기 시간 샘플의 99%가 120만 마이크로초보다 빠릅니다. 이 모든 샘플을 600바이트로 저장할 수 있고 백분위수와 역 백분위수를 정확하게 계산할 수 있으며 저장, 분석 및 회수 비용이 매우 저렴합니다.

 

 

 

 

 

 

 

https://sre.google/workbook/implementing-slos/#calculations-for-slis

https://thenewstack.io/how-to-correctly-frame-and-calculate-latency-slos/