[Tempo] Metrics-generator 알아보기

연휴가 참 기네요.
할 것도 없고... 그래서 이번에는 Tempo 내부 컴포넌트를 다뤄보겠습니다.

Tempo에는 (특이하게) Metrics-generator라는 컴포넌트가 존재합니다.

Tracing Backend 역할을 담당하는 Tempo가 Metrics과는 무슨 상관일까요?

이에 대해 공식문서를 보고 간단히 정리해보고자 합니다. 자세한 내용은 아래 문서를 참조해주세요.

Metrics-generator | Grafana Tempo documentation

 

---

Metrics-generator

간단하게 한글로 해석해보면 '메트릭 생성기'라고 해석해볼 수 있을 것 같습니다.

그렇다는건 Tempo 애플리케이션 자체의 Metric을 나타내는 것일까요?

그럼 컴포넌트로 따로 구성되어 문서가 정리될 필요도, 이렇게 글을 작성할 필요도 없을 것 입니다.

참고) Tempo 자체의 metrics은 기본적으로 `/metrics` HTTP endpoint로 노출됩니다.

 

Metrics-generator의 주된 목적은 수집된 Trace의 Metric을 수집하기 위함입니다.

즉, 맨 앞에 Trace가 생략되어 있다고 이해하시면 됩니다. Trace metrics generator !

기본적으로 Tempo는 Trace 정보를 저장하고 관리할 뿐, Trace 자체의 Metric을 생성하거나 관리하지 않습니다.

metrics-generator 컴포넌트를 활성화 하게 되면, 그때부터 Trace의 Metric을 생성, 관리하게 됩니다.

 

글 처음 부분의 그림에서 보셨듯, 그리고 아래 그림을 통해 알 수 있 metrics-generator를 활성화 하게 되면,

그때부터 distributor는 받은 span 정보를 ingester에게 보낼 뿐 아니라 metrics-generator에게도 보내게 됩니다.

(alloy는 opentelemetry collector, mimir는 prometheus로 이해하셔도 무방합니다)

 

metrics-generator는 받은 span 정보를 이용하여 Metric을 생성하고, 이를 metrics 저장소로 전송하게 됩니다.

metrics 저장소로 보낼 때는 Prometheus remote write Protocol을 이용하여 전송하게 됩니다.

 

즉, 기존 Metric에서 기본적으로 이용하는 Pooling 방식이 아닌 직접 Metric 생산지에서 전송하는 방식을 이용하는 것입니다.

그렇기에 사용하고 있는 Metric 저장소(ex. Prometheus, Thanos, VictoriaMetrics 등)에서 Remote write을 제공하지 않거나 옵션이 활성화 되어 있지 않다면 사용이 불가능합니다.

최근 Cloud Native 환경의 Infra Application들을 보다보면 Remote Write Protocol을 사용하는 사례가 종종 보이곤 합니다.
처음에 Prometheus를 학습할 땐 Pooling 방식을 기본 철학으로 설계되었다고 배웠는데 말이죠.

Remote Write Protocol은 기존 Prometheus에서 Metric을 Scrap 하는 개념과 조금 다릅니다.
(공식문서에 따르면) Remote Write Protocol의 주요 용도는 모니터링 시스템 간의 메트릭 전송입니다.
개별 애플리케이션이 직접 메트릭을 푸시하는 용도로는 설계되지 않았습니다.

 

---

왜 사용할까? 어떤 정보를 확인할 수 있는가?

그럼 왜 Trace Metric을 생성하고, 저장하는 것일까요? 단순합니다.

Trace에 부가 정보를 제공함으로써, 서비스 상태 정보 Observability에 추가적인 가치를 제공하기 위함입니다.

 

현재 Metrics-generator에서는 3가지 Processor를 제공하고 있습니다.

• Service graphs
• Span metrics
• Local blocks

필요에 따라 원하는 Processor만 활성화시켜 사용할 수 있습니다.

 

 

Service Graph

Service graphs | Grafana Tempo documentation

Service Graph는 분산 시스템 구조(MSA)에서 유용하게 활용될 수 있는 Processor 입니다.
단순한 서비스 간의 연결을 보여주는 것을 넘어서 시스템의 구조와 상태를 파악할 수 있도록 돕습니다.
(zipkin, pinpoint를 사용해보셨더라면 위와 비슷한 그래프를 보신 적이 있으실 겁니다)

3가지 유형을 감지하여 위 그림처럼 시각화하여 보여줍니다.

1. 서비스 간 직접 요청

두 서비스 간의 직접적인 통신을 의미합니다.
발신 Span의 경우 `client`, 수신 Span의 경우 `server` 속성을 가지고 있습니다.

 

2. 메시징 시스템을 통한 요청

Kafka와 같은 메시징 시스템을 통해 서비스들이 통신하는 경우가 해당됩니다.
발신 Span은 `producer`, 수신 Span은 `consumer` 속성을 가지고 있습니다.

 

3. 데이터베이스 요청

데이터베이스로 요청하는 경우를 의미합니다.
`client` Span 속성 중 `db.name` 혹은 `db.system` 하나가 포함되는 경우, 데이터베이스 요청으로 간주합니다.

 

Service Graph는 Virtual Node라는 개념을 도입하여, 실제로 계측되지 않은 외부 시스템 또한 포현합니다.

• Root Span의 `span.kind`가 `server`인 경우
  • 계측되지 않은 외부 시스템(ex. FE App)으로 부터 요청이 시작되었음을 의미합니다.
• `server` Span에 매칭되는 `client` Span이 없지만, `peer` 속성을 가진 Span이 있는 경우
  • 계측되지 않은 외부 서비스로의 호출을 의미합니다.

 

 

Span Metrics

Span metrics | Grafana Tempo documentation

https://grafana.com/docs/tempo/latest/getting-started/metrics-from-traces/

Span Metrics는 Tracing 데이터로부터 RED (Request, Error, Duration) Metric을 생성할 수 있는 Processor 입니다.

요청을 계산하는 Counter와 요청의 지속시간 분포를 추적하는 Histogram 같은 Tracing의 핵심적인 Metric 정보를 제공하여 전체적인 서비스의 상태를 추적하는데 큰 도움을 받을 수 있습니다.

 

마지막으로, Span Metrics의 중요한 특징 중 하나는 Exemplars와의 통합입니다.

Examplars는 특정 시간 간격에서 측정된 대표적인 Trace를 의미하며, Metric과 Trace가 Metric generator를 통해 공존하는 상황이기 때문에 자동으로 추가될 수 있습니다.

• 문제 발생 시 해당 Metric과 관련된 구체적인 Trace를 빠르게 찾아볼 수 있게 해주는 강력한 디버깅 도구 입니다.

 

Local Blocks

Span 데이터를 일정기간 동안 저장하고, 이를 기반으로 복잡한 계산을 수행할 수 있게 해줍니다.

이 프로세서는 특별한 Metric API들을 위한 기반이 되며, 이러한 API들을 사용하기 위해서는 반드시 이 프로세서가 활성화되어 있어야 합니다.

 

---

Tempo에서 제공하는 Metrics-generator에 대하여 간단하게 정리해보았는데요.

사실 제공되는 각 Processor마다의 상세 문서에서 더 자세한 내용들을 다루고 있습니다.

저도 다 보지는 않았지만 각 기능들에 대한 자세한 설명과 더불어 Grafana에서 어떻게 활용할 수 있는지 다루고 있어, 사용 예정에 있다면 한 번 살펴보면 좋을 것 같습니다.

 

긴 글 읽어주셔서 감사합니다.