[서비스 모니터링] 쿠버네티스 클러스터 모니터링, 서비스 수준 목표 조사 및 발표 준비

# 조사 및 발표

발표 주제 1

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

메트릭 수집을 위한 메커니즘 방식

- 데이터를 수집하는 방식에 따라 push, pull로 구분

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

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

pull

특징

- pull 기반 모니터링 시스템은 능동적으로 지표를 획득하는 모니터링 시스템

- 모니터링 시스템은 원격으로  애플리케이션에 액세스할 수 있는 기능이 필요

- 중앙 모니터링 시스템에서 에이전트로부터 구성 및 메트릭 메타데이터를 가져옴

- 에이전트가 수집한 메트릭을 중앙 서버에서 읽음

장단점

- 배치 방법 : Pull 모델의 배치 방법은 미들웨어 및 기타 시스템을 모니터링하기에는 너무 복잡하고 유지 관리 비용이 높음

- 리소스 비용 : Pull 모드의 리소스 비용은 주로 모니터링 시스템 엔드에 집중되며, 애플리케이션 엔드의 소모량은 낮음

- 헬스 체크 : 대상 애플리케이션의 기동 여부를 모니터링하는 것이 간단

- 데이터 완전성 : pull 모드는 데이터를 차례로 당겨오므로 한 차례가 마칠 경우에만 수집이 완료되며, 풀이 실패했을 경우에도 실패한 비율을 알 수 있음

- 짧은 생명 주기/서버리스 애플리케이션 모니터링 : 수명이 짧으므로 모니터링하기 어려움

- 유연성 및 결합도 :  유연성이 높으며 결합도가 낮음(인터페이스만 제공하면 됨)

사용하는 모니터링 도구

- prometheus, collected, datalog

push

특징

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

- 메트릭은 중앙에서 정의되며 할당된 호스트 및 에이전트에 푸시되어 에이전트가 중앙 서버로 보냄

장단점

- 배치 방법 : 푸시 모드 배치는 비교적 편리하나 애플리케이션의 메트릭 포트 비용이나 배포를 위해 푸시하는 비용은 얼추 비슷

- 리소스 비용 : Push 모드의 리소스 핵심 소모량은 Push Agent에 집중되며, 모니터링 시스템 엔드의 소모량은 Pull보다 훨씬 낮음

- 헬스 체크 : 애플리케이션에서 푸시하지 않을 경우 다양한 문제가 발생할 수 있으나 앱을 확인하기 전까지 특정 오류 원인을 알기 어려움

- 데이터 완전성 : push 모드에서 사전에 에이전트가 푸시하므로 각 클라이언트의 푸시 간격, 네트워크 지연 시간이 다르고 데이터 완전성을 확인하기 위해 많은 비용이 소모

- 짧은 생명 주기/서버리스 애플리케이션 모니터링 : 수명이 짧으므로 push 방식이 보다 안전

- 유연성 및 결합도 :  상대적으로 유연성이 낮고 결합도가 높은 편(응용 프로그램에서 백엔드 주소 및 인증 정보 구성해야 함)

사용하는 모니터링 도구

- Nagios, Zabbix

---

발표 주제 2

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

1. 필요 지표

• 응답 속도: 요청에 대한 응답이 리턴되기까지의 시간
• 에러율: 전체 요청 수 대비
• 처리량(throughput): 초당 처리할 수 있는 요청 수

2. 계산 방법

- 총 GET 호출 수

 >  총 GET 호출 중 성공한 호출 수

 > 총 GET 호출 중 실패한 호출 수

- 총 GET 요청의 성공/실패율

 > 총 GET 호출 중 성공한 호출 수 / 총 GET 호출 수

 > 총 GET 호출 중 실패한 호출 수 / 총 GET 호출 수

- 총 GET 호출이 응답되기 까지 시간의 합/ 총 GET 요청 수

 > 성공한 GET 출이 응답되기 까지 시간의 합 / 총 GET 호출 중 성공한 호출 수

- 각 GET 요청의 응답 속도가 10ms 이내인 호출 수 / 총 GET 호출 수

 

# references

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

Pull or Push: How to Select Monitoring Systems?

https://prometheus.io/docs/introduction/faq/#why-do-you-pull-rather-than-push? 

FAQ | Prometheus

https://engineering.linecorp.com/en/blog/monitoring-applications-prometheus-metricat

Monitoring applications with Prometheus and Metricat

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

Push vs. Pull Configs for Monitoring

https://docs.datadoghq.com/service_management/service_level_objectives/metric/

Metric-based SLOs

https://sre.google/workbook/implementing-slos/

Chapter 2 - Implementing SLOs, Google SRE Book