모니터링의 범주
결국 대부분의 모니터링은 하나를 위한 것인데 "event"를 위한 것이다. 그 예로는 아래와 같다.
- HTTP 요청 수신
- HTTP 400 응답 송수신
- 함수 시작
- 사용자 로그인
- 디스크에 데이터 쓰기
- 네트워크에서 데이터 읽기
- 커널에서 추가 메모리 요청
event context 구성 요소
event context를 파악하면 디버깅에 큰 도움이 되고 기술적인 관점과 비즈니스 관점 모두에서 시스템의 수행 방법을 알 수 있지만, 처리 및 저장해야하는 데이터의 양이 늘어난다. 따라서 필요에 따른 이벤트만 수집하는 것이 좋은데 방법에는 프로파일링, 트레이싱, 로깅, 메트릭이 있다.
- Http 요청
- 들어오고 나가는 IP주소, request URL, 설정된 쿠키, 요청한 사용자 정보가 들어 있다.
- 함수를 포함하는 이벤트
- 함수 상단에 있는 함수들의 콜 스택과 HTTP 요청처럼 무엇이 해당 스택의 일부를 트리거 했는지에 대한 정보가 담겨 있다.모니터링 방법
위에서 언급한 4가지의 모니터링 방법에 대해 알아보자
Profiling
모든 시간 때에 모든 이벤트 컨텍스트를 가질 수는 없지만, 제한된 기간의 일부 컨텍스트를 가져오는 방법이다.
말이 어렵지만, 예시를 통해 이해를 해보자면 TCP Dump라는 프로파일링 도구를 이용할 수 있다. 지정된 필터를 기반으로 네트워크 트래픽을 기록(모든 이벤트 컨텍스트 가져오기를)할 수 있다.
-> 실제로는 디스크 공간이 부족해 질 수 있기 때문에 제한된 기간에만 사용할 수 있다.
또다른 도구로는 debug build라는 방법이 있따. 유용한 다양한 정보를 제곡하지만 모든 함수의 호출 타이밍 같은 정보를 수집하기 때문에 성능에 영향을 준다.
-> 운영환경에서 사용하는 것은 적절하지 않다.
프로파일링은 상당히 전략적인 방법이지만 오랜 시간 프로파일링을 해야하는 경우, 다른 모니터링과 함께 사용하기 위해서는 반드시 데이터의 양을 줄여야한다.
Tracing
프로파일링과 달리, 관심 기능을 통과하는 일부 이벤트처럼 수백 개의 이벤트 중 특정 이벤틑에만 집중한다.
tracing은 Stack trace에서 관심 있는 부분의 함수를 가록하고, 때때로 이러한 함수들이 얼마나 오랫동안 수행되었는지도 기록한다.
-> 어느 코드에서 병목이 발생하고 어느 코드 경로가 지연에 큰 영향을 미치는지 알 수 있다.
또한 일부 Tracing System은 관심 지점에서 Stack trace에서 snapshot를 수집하는 대신, 관심 있는 하위의 모든 함수를 추적하고 타이밍을 기록한다.
-> 예로 수백개의 사용자 HTTP 요청 중 하나를 샘플링할 수 있고, 이 요청에 대해 db나 cache와 같은 백엔드와 통신하는데 얼마나 오랜 시간이 소비되었는지 확인할 수 있다.
Distributed Tracing
Tracing에서 한단계 더 나아가 원격 프로시져를 호출에서 한 프로세스에서 다른 프로세스로 전달되는 요청에 고유ID를 추가해 해당 요청이 추적되어야 하는지 여부 등 프로세스 전반에 걸친 작업을 추적함
ex) Zipkin, Jaeger
로깅
로깅은 제한된 이벤트 집합을 살펴보고 각 이벤트에 대한 컨텍스트 일부를 기록한다. 예로 로깅은 수신되는 모든 HTTP 요청이나 발신되는 모든 DB 호출 같은 이벤트를 살펴보고 기록한다. 자원의 낭비를 방지하려면 로그 항목별로 수백개 정도의 필드 수를 제한 해야한다. 의외로 대역폭과 저장 장치가 문제되기도 한다,
종류
- 트렌젝션 로그
- 요청 로그
- 어플리케이션 로그
- 디버그 로그
세세한 로그로 굉장히 상세해서 비용이 많이들고 프로파일링의 특성을 띈다.
트랜젝션 로그 저장을 위해 신뢰성이 중요해지게 될 경우 필요한 디버그 로그 저장 데이터 볼륨을 가지고 있는 경우, 다양한 종류의 로그를 같은 방법으로 처리할 경우 최악의 상황을 가져올 수 있다. 따라서 시스템이 커질 경우 분리 계획을 세워야한다. 로깅 시스템의 예로 ELK Stack, Gray log 등이 있다.
Metric
대부분의 컨텍스트를 무시하고 다양한 유형의 이벤트에 대해 시간에 따른 집계를 추적한다. 자원 사용을 정상적으로 유지하려면, 추적하는 메트릭 수도 제한 해야한다. 상한선으로 프로세스당 1만개의 메트릭 처리가 합리적이다.
매트릭 종류로는 Http 요청 횟수, 요청하는데 걸린 시간, 현재 진행중인 요청 수 등을 예로 들 수 있다.
그렇다고 컨텍스트가 항상 무시되는 걳은 아니고 Http 요청의 경우, 각 URL 경로마다 메트릭을 설정할 수 있다. 그러나 구별된 각 경로는 하나의 메트릭으로 간주되기 떄문에 1만개 메트릭 가이드라인을 염두에 둬야한다,.
장점
애플리케이션의 각 서브시스템에서 대기 시간과 처리하는 데이터 양을 추적해서 성능저하의 원인이 정확히 무엇인지 손쉽게 파악 할 수 있다.
예
프로메테우스
- 개별 이벤트보다 전반적인 시스템의 상태와 동작 성능을 추적하도록 설계되었다.
