5장 지표 모니터링 및 경보 시스템

끄적끄적

기본 사항
- Data Collection
- Data Transmission
- Pull 방식
  - Service Discovery Service("SDS", e.g. etcd, Apache Zookeeper, ...)를 사용해서 서버들을 찾아서 메트릭 데이터 요청
  - Consistent Hash Ring으로 Collector당 server 수를 고르게 분산
  - metric API 등을 통해서 수집되는 메트릭 바로바로 확인 가능
  - e.g. Prometheus
- Push 방식
  - Pull 방식은 신경써야할게 많으니 Push방식이 나을 듯
  - Batch Job 같은 것들은 Push 방식이 나음 (Pull방식으로 구성하면, 언제 메트릭을 수집해야할지 알기 힘듦)
  - Push Gateway
  - 아무나 Collector에 전송할 수 있다는 문제가 있지만 Authentication을 강제하면 해결됨
  - e.g. AWS CloudWatch, Graphite
- 하이브리드 방식: 각 서버에 agent를 두고, agent가 pull한 후, collector에 push (SDS, Consistent Hash Ring 불필요)
- Data Storage
- RDB 또는 NoSQL을 사용하기 보다는, 잘 구현된 TSDB가 많으니 그것들을 사용하자
  - InfluxDB, Prometheus, Mimir
- 대부분의 조회는 최근 1일 데이터에서 발생한다
  - Down Sampling: 오래된 데이터는 Resolution을 낮춰서 저장하면 저장 용량을 대폭 줄일 수 있다
  - e.g. 7일 이후엔 1분 간격, 30일 이후엔 1시간 간격, ...
  - 비활성 데이터들은 아예 Cold Storage에 보관하면 된다
- 메트릭의 Cardinality는 낮아야 한다
  - e.g. 메트릭 ID에 Entity ID같은걸 사용하면 안됨
- Alert
- Visualization
- e.g. Grafana
각 서버와 Collector 사이에 Kafka를 두고, Kafka를 consume해서 저장하면 DB 장애 시에도 데이터 소실되지 않음
Alert/Visualization System은 개발 ROI가 좋지 않으니, 그냥 상용 제품을 구매해서 사용하자

지표의 해상도에 따라 데이터 양이 결정됨
데이터 저장소를 고르는 노력도 필요한데, RDB나 NoSQL보다 프로메테우스나 InfluxDB와 같이 시계열에 최적화된 데이터 베이스를 쓰는 것이 좋음 (시계열 데이터 연산, Tag Index등을 지원하려면)
각 레이블이 가질 수 있는 Cardinality가 낮아야 한다. Peformance와 연관 있음
Pull vs Pushing 방식
- 배치성의 job과 같은 경우 Pull 방식으로 메트릭 집계하기 어려운 경우가 있기에 특성에 따라 Push Gateway와 같은 Push방식을 쓰기도 함(https://jaykos96.tistory.com/62)
- Consistent Hashing을 통해 Pull 방식에서의 부하 분산 - https://www.baeldung.com/cs/consistent-hashing
- Push 방식은 Load balancer를 통해 부하 분산
시계열 데이터베이스란
https://www.youtube.com/watch?v=OUyXPgVcdw4

DevSprout / System-Design-Interview-2

5장 지표 모니터링 및 경보 시스템 #5

끄적끄적