[ Monitoring과 필요성 ]

서비스 장애가 발생했을 때, 그것을 재현하고 문제를 제대로 파악하고 이를 통해 서비스 복구시간을 최소화 할 수 있다.

앞으로 일어날 수 있는 것에 대해서 미리 예측할 수 있다.

[ Monitoring과 Observability ]

Monitoring = “무엇을 볼지 미리 정해놓고 감시”

Observability = “수집된 정보를 이용해서 시스템 내부 상태를 추론”

Monitoring	Observability
정해진 지표를 지속적으로 관찰	수집된 정보를 바탕으로 원인 추론
이미 알고 있는 문제 탐지	알지 못했던 문제 발견
상태 확인	원인 분석
장애 감지	장애 이해
알람 발생	병목 파악

[ Observability의 3대 요소 ]

Metric

• 숫자 데이터 (cpu, memory, network, error rate)
• 시스템 상태를 빠르게 확인할 수 있다.

Log

• 이벤트 기록 (로그인 성공, 로그인 실패, 에러 발생)
• 문제 발생 원인을 찾을 수 있다.

Trace

• 요청 이동 경로 (client → web → API → DB)
• 어디에서 지연이 발생하는지 찾을 수 있음

[ Metric ]

Metric의 개념

• 숫자 데이터 (cpu, memory, network, error rate)
• 시스템 상태를 빠르게 확인할 수 있다.

Metric의 종류

• counter : 누적해서 계속 증가하는 값 (총 요청수 , 총 에러 수 )
  • 서버 재시작 전까지 감소하지 않음
• gauge : 오르내리는 값 (CPU사용률, 메모리 사용률, 온도)
  • 실시간 상태 표현
• Histogram : 값의 분포 (응답시간, 처리시간)

Percentile

• 평균의 함정을 보완하기 위한 지표

→ 평균 응답시간이 300ms라는 건 전부다 300ms비슷하게 일수도 있지만, 99명이 10ms이고 단 한 사람만 30초일 수도 있는것이다.

• p50 : 50% 사용자가 경험한 응답시간
• p95 : 95% 사용자가 경험한 응답시간
• p99 : 99% 사용자가 경험한 응답시간 → 장애 탐지 시 가장 많이 사용되는 퍼센타일

→ 실무에서는 평균보다는 위의 값들을 많이 사용한다.

[ Monitoring 대상 ]

Application Monitoring

• 애플리케이션 관점에서의 모니터링
• 에러율, API호출, 로그, trace
• 이를 확인함으로써 사용자 요청이 정상 처리되는가를 확인할 수 있다.

Infrastructure Monitoring

• 인프라 관점에서의 모니터링
• CPU, RAM, DISK , Network, Docker, K8s, Cepth 등

[ Observability 주요 도구 ]

Prometheus

• 시계열 (time series) metric 저장소
• Pull 방식으로 대상 서버의 exporter 에게 주기적으로 직접 메트릭을 요청해서 데이터를 가져옴
  • Node exporter가 아래와 같은 매트릭을 반환한다.

cpu_usage 45
memory_usage 72
disk_usage 31

• 수집한 매트릭을 저장하고 조회할 수 있음

Fluent Bit

• 경량 로그 수집기
• 로그 수집 전용
• 서버나 컨테이너에서 생성되는 로그를 읽어서 로그 저장소로 전송한다. (Loki, OpenSearch, ElasticSearch, kafka등으로 전송)
• 가벼우며 쿠버네티스에서 많이 사용한다.

Loki

• Grafana Labs에서 만든 로그 저장소
• Fluent Bit가 보낸 로그를 저장하고 검색할 수 있다.
• Fluent bit는 수집만 하기 떄문에 어딘가에 저장해야할 필요가 있다. 그 저장소중에 하나가 Loki이다.
• ElasticSearch와 비교했을 때 최소한의 메타데이터만 인덱싱하기 때문에 더 가볍다

Grafana

• promethus, Loki등의 데이터를 시각화하고 통합 관리하는 오픈소스 대시보드 플랫폼
• Grafana는 데이터 수집을 직접 하지 않는다.
• 데이터 저장소에 연결하여 데이터를 보여준다.
• 데이터 시각화 뿐만 아니라, 통합 관제, 특정 조건 발생시 알림 전송등의 기능도 포함한다.

[ Trace ]

Trace

• 하나의 요청이 시스템 내부를 이동하면서 거치는 전체 경로와 처리 시간을 추적하는 기술
• 만약 “로그인 API 응딥시간”이 10초가 나왔다고 하자. 모니터링만 보면 “느리다”까지만 알 수 있따.
• 하지만 이떄 trace를 사용하면

사용자
 ↓
Web Server (1초)
 ↓
API Server (2초)
 ↓
DB 조회 (7초)
 ↓
응답

Span

• Trace를 구성하는 가장 작은 “작업의 단위”
• 인증 처리, DB조회, 외부 API호출등 각각의 작업들이 Span이라고 부를 수 있다.
• trace는 여러개의 span을 묶은 것이라고 볼 수 있다.

[ Observability 데이터 처리 파이프라인 ]

• Metric, Log, Trace 모두 단순히 수집만 하는 것이 아니라 수집 → 저장 → 시각화 과정을 거쳐 활용된다.

                [ Metric ]
Node Exporter
 ↓
Prometheus
 ↓
Grafana

                  [ Log ]
Fluent Bit
 ↓
Loki
 ↓
Grafana

                  [ Trace ]
OpenTelemetry
 ↓
Tempo
 ↓
Grafana

일반적으로 각 데이터는

1. 수집(Collection)
2. 저장(Storage)
3. 시각화(Visualization)

과정을 거치며, 운영자는 최종적으로 Grafana와 같은 대시보드에서 시스템 상태를 확인한다.