Background
안녕하세요~ 오늘은 Observability 라는 주제로 이야기를 나누어 볼까 합니다.
흔히들 Monitoring 이라는 키워드는 많이 들어보았을텐데요. 많은 사람들이 Monitoring 시스템을 구축하는 이유는 내가 관리하는 시스템의 상태를 실시간으로 확인하기 위함입니다.
Monitoring
is tooling or a technical solution that allows teams to watch and understand the state of their systems. Monitoring is based on gathering predefined sets of metrics or logs.
따라서 Monitoring 이야 말로 예전부터 시스템을 관리하기 위한 요소로 필수적인 요소로 자리 잡고 항상 구축해왔던 것이었죠
그런데 말입니다.
복잡한 요구사항을 처리하고, 시스템간 의존성을 최소화 하기 위하여 Microservice architecture 가 급부상하고, 각 기업들도 Microservice architecture 의 장점을 극대화하기 위해 팀을 쪼개는 방향성을 많이 가지게 되었습니다.
이러한 환경에서 각 microservice 별 시스템들이 기하급수적으로 늘기 시작했고, 운영과 debug 를 하자니 너무 힘들고 어려운 점들을 많이 맞이하게 되었지요.
그래서 이전에 metric 과 log 기반으로 Monitoring 하는 solution 이 더 이상 적합하지 않게 되었습니다. 이슈가 발생하면 하나의 시스템만 연관되는 것이 아닌 여러 시스템들이 서로 복잡한 관계에 얽혀 상호작용 하기 때문이죠.
그래서 Observability 가 떠오르게 되었습니다. Observability 라는 것은 무엇일까요?
Observability
is tooling or a technical solution that allows teams to actively debug their system. Observability is based on exploring properties and patterns not defined in advance.
Observability 는 Monitoring 과 같이 단순 오류 상태를 보여주는 것뿐만 아니라, 더 나아가 왜 오류가 발생했는지 이해하는 것을 목표로 합니다. 즉, Observability 는 오류 탐지, 알림을 보는 것 뿐만 아니라, 오류에 대해 근본 원인을 찾기 위한 모든 방안들을 제공하는 것이 목표라고 볼 수 있습니다.
그렇다면 어떻게 하면 Observability 를 우리가 실현할 수 있을까요?
Observability
Observability 를 실현하기 위해서는 크게 아래 3가지 주요 데이터로 이루어져 있습니다.
- Metric(Aggregatable): 시간 간격에 따라 측정된 숫자로 표시되는 데이터
- Trace(Request scoped): 요청 흐름을 추적하기 위한 데이터. MSA 에서는 Distributed Trace 라고 표현하여 Trace 와 Span 을 구분
- Log(Events): Application 의 Event 를 기록한 데이터
괄호에 있는 목적을 달성하기 위해 3가지 요소로 구분하였다 라고 이해할 수 있어요.
Metric 은 시계열 데이터 기반으로 시간 interval 집계에 용이하고,
Trace 는 Trace context 기반으로 요청 단위의 집계에 용이하고,
Log 는 특별한 Event 에 대해 자유자재로 기록하기 위한 집계에 용이합니다.
각 구성별 저장되는 database 로는 대표적으로는 아래와 같이 있습니다.
- Metric: Prometheus
- Trace: Tempo
- Log: Loki
이처럼 서로 다른 책임을 가진 요소들이기에, 이 3가지 요소들을 서로 엮을 수 있는 방법만 찾아낸다면 문제가 발생한 근본 원인을 쉽게 알아낼 수 있습니다.
이 3가지 요소를 서로 엮기 위해서 각각 요소별로 Correlation 을 만들어 운영할 수 있습니다
그림에서 볼 수 있듯이 Metric Trace Log 는 서로 다른 역할군을 가지고 있고, 각 역할군의 교집합을 이용하여 오류 발생의 원인을 쉽게 찾아낼 수 있게 됩니다.
- Metric between Trace: Exempler 를 통하여 Request 단위로 생성된 metric 기반으로 교집합을 구성
- Trace between Log: TraceId / SpanId 기반으로 Request 단위로 생성된 event 기반으로 교집합을 구성
- Log between Metric: Time period 기반으로 Time 단위로 생성된 event, metric 기반으로 교집합을 구성
이를 그림으로 나타내면 아래와 같습니다.
Correlation 을 기반으로 하는 데이터 수집이 완료된다면 visualization tool(ex. Grafana) 를 통해 쉽게 dashboard 를 구성할 수 있고, 각 Correlation 기반으로 연결시키는 것이 가능합니다.
Correlation Example
Metric between Trace
Metric 와 Trace 은 Exemplar 를 통해 연결시킬 수 있다고 위에서 언급했었는데요.
Exemplar 는 주어진 시간동안 측정된 metric 을 trace representative data 로 나타내는 것을 의미합니다.
Grafana 에서 Exemplar 옵션을 켜준다면 아래와 같이 정보를 확인해볼 수 있습니다
Exemplar 를 통해 traceId 를 찾아낼 수 있었고, 찾아낸 traceId 기반으로 Trace 저장소인 Tempo 에 query 를 할 수 있도록 지표가 발견되었죠
버튼을 누르게 되면 자동으로 traceId 기반으로 query 를 하게 되었고, 요청정보가 어떻게 흘러갔는지 순식간에 파악할 수 있게 되었네요.
Trace between Log
그렇다면 Trace 와 Log 는 어떻게 보여질까요?
Trace 와 Log 는 Request 단위로 서로를 연결하여 찾아볼 수 있습니다.
traceId 는 특정 요청에 대한 scope 이고, spanId 는 한 메서드 실행에 대한 scope 라고 이해하면 어떤 단위인지 이해하기가 조금은 쉽지 않을까 싶군요.
위 button 을 누르게 된다면?
traceId 와 spanId 기반으로 Log 저장소인 Loki 쪽으로 query 를 자동으로 완성하여, 특정 span 에 해당하는 로그를 볼 수 있게 된 것이죠.
Log between Metric
Log 에서 바로 Metric 을 연결짓는 요소는 시간 요소인데, 아쉽게도 현재 grafana 상으로 바로 이동할 수 있는 경로는 없어 trace 를 통해 시간단위를 알아내야 합니다.
Service Graph 기반으로 함수의 실행을 시각화한 툴에서 시작할 수 있는데요.
이렇게 어떤 구성요소가 어떤 span 을 실행했는지 전체적으로 연결 그래프를 볼 수 있는데요.
Request rate 버튼을 누르게된다면,
특정 span 이 발생한 시간동안 어떤 요청이 수집되었는지 바로 연결시킬 수 있게 됩니다.
Metric, Trace, Log 데이터를 수집하고 각 Correlation 이 연결될 수 있는 기반의 데이터를 저장하고만 있다면
Grafana 상으로 시각화하여 보여줄 수 있고, 각 데이터를 연결시켜줌으로써 어떤 상황이 발생했고, 왜 발생했는지를 추적할 수 있게 되는 것입니다.
정리하며
오늘은 Observability 와 관련된 전반적인 개념과 예제를 통한 설명을 드렸었습니다 ㅎㅎ
물론 각 구성요소에 대한 디테일한 설명을 제가 드리지는 못해서, Prometheus, Tempo, Loki 에 대해서는 다음 게시글로 심도있게 어떤 식으로 데이터를 다루는지 알아보도록 해볼게요.
오늘 Observability 가 무엇이고, 왜 필요한지에 대해 이해가 되었다면 성공입니다~!
참고자료
What is Observability?
Grafana Monitoring 스택 LGTM 구성기 (Loki, Mimir, Tempo)
OpenTelemetry 로 Kubernetes Observability 확보하기: Correlation
Grafana documentation
'Developer > Observability' 카테고리의 다른 글
| Observability - Integration with spring boot (3) | 2024.08.30 |
|---|
