로그
시스템 프로세스의 개별 이벤트를 기록하는 것
- 예를 들어 애플리케이션이 충돌하면 로그 메시지가 생성되고 수집되어 향후 처리
- 이 메시지의 내용은 충돌이 발생한 시간과 응용 프로그램이 충돌한 페이지/파일일 수 있음. 나중에 해당 로그를 분석하고 이들 사이에 상관 관계가 있는지 확인가능.
- 하지만 각 로그 스트림은 단일 인스턴스에 대해서만 알려주기 때문에 마이크로 서비스에서 전체적인 모니터링을 하기엔 어려움이 있음
Fluentd - Kibana
수집을 위해서 Elastic, Splunk, Fluentd,
로그 저장소는 Elasticsearch 활용하고 있음
메트릭
- 시간에 따른 변화를 나타내며 CPU 사용률, RAM 용량 또는 디스크 사용률과 같은 하드웨어 리소스를 모니터링하는 데 사용됨
- 미리 정의된 특정 간격으로 수집됨
- 예를 들어 CPU가 과열되었는지 또는 RAM에 할당된 공간이 얼마인지 매초 확인 가능
수집을 위해서 Prometheus, Graphite, Influx, DataDog 사용
트레이싱
사용자의 트래픽에 지나가는 애플리케이션의 전체 스택을 추적,
주로 서비스를 최적화하는데 사용됨
- 예를 들어, 특정 서비스에 병목이 예상되는 경우 트레이싱해서 어떤 부분인지 확인하고 최적화를 시도해볼 수 있음
- 트레이싱은 구조화된 형태의 로그 이벤트로도 볼 수 있음
- 트레이싱은 주로 개발자가 소비하며, low level 정보 (thrown exception)로 구성
Jaeger
수집을 위해서 AppDynamics, Jaeger, Zipkin 등을 사용할 수 있음
수집할 때 사용하는 것만 봐도 오픈 소스
이건 그냥 참고용:
- Track : 현재 시점에서 앞으로 어딜 갈지 추적하는 것
- Trace : 거꾸로, 현재 시점에서 시작된 지점까지 이미 완료된 경로를 따라가는 것
graphana enterprise는 선택하는 도구와 관계없이 이런 요소 간 상관관계를 볼 수 있고 메트릭에서 로그 및 분산 트레이스로 쉽게 이동할 수 있는 방법을 제공하고,
고객이 원하는 use case에 따라 가장 적합한 도구를 선택하고 이를 하나의 UX로 통합할 수 있도록 돕는다는데, 이건 추후에 kibana vs graphana에서 알아보자
참고자료:
https://markruler.github.io/posts/cloud/monitor-trace-log-metric/#software-tracing
모니터링
ex) Grafana
어플리케이션 계측 (measure), 매트릭 수집 (collect), 집계 (aggregate), 분석(analyze) 등을 포함하는 시스템.
- 진단 목적으로 가장 많이 사용
- 문제가 생길 시, 또는 설정한 임계점(threshold)를 넘길 시 관리자에게 알림을 보냄
