[Monitoring] Grafana Tempo 알아보기

Grafana Tempo란?

Grafana Tempo란 Distributed tracing backend(분산 트레이싱 저장소)이다.
 
Open source tracing protocol(Jaeger, OpenTelemetry, Zipkin, ..)와 연결하여 Tempo를 분산 트레이싱 저장소로써 활용 가능하다.

 

그렇다면 여기서 분산 트레이싱이란 무엇일까?
 
분산 트레이스(Distributed Tracing)는 분산 시스템에서 발생하는 작업의 수행 경로를 추적하고 모니터링하기 위한 기술이다.
 
마이크로서비스 환경에서는 수십, 수백개의 서비스가 존재하고 각 서비스들은 서로 API 간 통신, 데이터베이스, 캐시 서버등 다양한 컴포넌트간 통신하며 서비스를 이루게 된다.
 
마이크로서비스의 장점은 각 서비스가 독립적으로 이루어져 있어 장애가 발생하여도 특정 서비스에 대해서만 이슈가 발생한다는것이 장점인데, 그에 반해 단점으로는 수많은 서비스가 독립적으로 구성되어 있기 때문에 문제가 발생할 경우 어느 부분에서 문제가 발생했는지 확인이 어렵다는 것이다. 즉 이슈에 대해 디버깅 난이도가 상당히 높다는것을 의미한다.
 
이럴 경우에 도움을 줄 수 있는게 바로 분산 트레이싱이다.
 
예를 들어 홍길동이란 사용자가 특정 서비스를 결제했다고 가정해보자.
 
이 요청(Request)는 일반적으로 API의 진입점인 API Gateway를 경유하여 뒷 단의 결제 서버로 요청이 갈 것이다.
 
물론 그 사이에 잔고가 남아있는지, PG사를 통해 결제를 진행하는지 등 수많은 과정들이 존재할 것인데 사용자의 요청이 어떤 경로를 통해 각 서비스를 거쳐가는지 추적(Trace)하고 이 정보를 시각화(Visualization)할 수 있다면 많은 도움이 될 것이다.
 
여기서 Grafana Tempo는 단순 저장소 역할을 수행한다.
분산 트레이싱을 발생하기 위해서는 다른 컴포넌트(ex. OpenTelemetry)가 필요하다.
 
 
그렇다면 왜 Grafana Tempo가 최근에 많이 떠오르고 있을까? 생각나는 이유로는 다음과 같다.
 
1. Grafana Mimir(시계열 저장소), Grafana Loki(로그 저장소)와의 통합 및 연동
: Application Log에 Trace ID를 주입하여 로그와 트레이스 간 상호 연동을 할 수 있다.
: Examplars를 통해 Latency가 높은 요청의 Trace를 곧바로 조회할 수 있다.
 
2. 장기 객체 스토리지(Minio, GCS, S3) 지원
: Volume Storage가 아닌 객체 스토리지를 지원함으로써 뛰어난 확장성을 가짐
 
 

Grafana Tempo Architecture

Grafana Tempo는 다음의 아키텍쳐를 가지고 있다.

 
 
처음 이 그림을 봤을 때는 자세히 감이 안올 수 있는데 크게 2가지 영역으로 존재한다고 보면 된다.
 

쓰기 컴포넌트 (Write Components)

쓰기 영역에서 하는 역할은 다음과 같다.
 
1. 외부로부터 Trace / Span들을 전달받는다.
2. 기 정의한 규칙에 의거하여 어떤 Span들을 수집하고 어떤 Span들을 필터링할지 정한다.
3. 최종적으로 수집하기로 한 Span들은 장기 저장소(ex. S3)에 저장된다.
4. 압축 작업을 수행하고, 장기 저장소에 얼마동안 데이터들을 저장할지 정의한다.
 
 
이런 역할을 수행하는 컴포넌트들은 Distributor, Ingester, Compactor, (Optional) Metrics Generator가 있다.
 
1. Distributor (분배자)
Jaeger, OpenTelemetry, Zipkin을 포함한 다양한 포맷의 Span들을 받아들이는 컴포넌트이다. (Reveiver Layer)
 
Distributor는 Receiver Layer로써 Span들을 수집한다음에 뒷단(Ingester)에게 전달하는 역할을 한다.
 
(Optional) 만약 Metrics Generator가 활성화되어 있다면 Metrics Generator에게도 전달하게 된다.
 
 
2. Ingester (수집기)
Ingester는 Span들을 수집하여 일정기간동안 모아둔 뒤 장기 저장소로 Flush하는 역할을 수행한다.
(쉽게 말하면 수집 -> 일정 시간동안 모아둠 -> 기 정의된 Batch 설정에 따라 장기 저장소로 Flush)
 
 
Ingester는 다음의 구조를 통해 Span들을 저장하게 된다.

 
Block : Tempo에서 Trace 데이터를 저장하는 기본 단위이다. 각 Block은 시간에 따라 시간 범위의 데이터를 담고 있다.
Bloom Filter : 특정 데이터가 존재하는지 여부를 확인하기 위한 자료구조이며, 특정 Trace ID가 존재하는지 빠르게 확인할 수 있도록 도와준다.
Index : 특정 조건에 따라 Trace를 빠르게 찾을 수 있도록 도와주는 metadata를 관리한다.
data : 실제 data를 관리하는 파일
 
 
그렇다면 실제 어떤식으로 저장하는지 한번 확인해보자.
다음은 Tempo - Ingester의 wal(Write-ahead logging) 내 특정 block 폴더 안에 있는 파일들이다.
 

 
data.parquet는 parquet 포맷으로 저장된 data file을 의미하며 index, bloom-filter 파일들, meta.json 파일 등이 저장되어 있음을 확인할 수 있다.

 
 
3. Compactor (압축기)
압축기는 말 그대로 압축을 담당한다.
 
데이터를 효율적으로 관리하고 저장 공간을 최적화하는 역할을 담당하게 되는 컴포넌트인데 주로 디스크 공간을 효율적으로 사용하게 하고 검색 성능을 향상시키기 위한 작업을 담당한다.
 
하는 역할로는 다음과 같다.
 
- Compaction(데이터 압축)
- Index Management(인덱스 관리)
- Retention Management(저장기간 관리)
 
 
 
4. Metrics Generator (메트릭 생성기)
Metrics Generator도 말 그대로 메트릭을 생성하는 컴포넌트이다.
 
즉, Trace data를 통해 시계열 메트릭을 생성하는 컴포넌트라고 보면 된다.
 
Distributor가 맨 처음에 수집하고 그 다음에 Ingester와 Metrics Generator로 데이터들을 각각 전달하게 되며 Metrics Generator는 전달받은 데이터를 시계열 메트릭으로 가공하여 시계열 저장소로 remoteWrite하게 된다. (Mimir, Thanos, Prometheus, ..)
 
Metrics Generator를 통해 다음 화면처럼 우리가 흔히 볼 수 있는 시각화를 수행할 수 있게 된다.

 

 

 

---

 

 
 

읽기 컴포넌트 (Read Components)

실질적으로 수집된 데이터를 Grafana로부터 읽어야한다. 이를 담당하는 컴포넌트들이 Querier, Query Frontend이다.
 
 
1. Query Frontend
Query Frontend는 요청 들어오는 Query들에 대해 샤딩을 담당한다. (GET /api/traces/<TraceID>)
 
내부적으로 Query Frontend는 blockID space를 기 설정한 shard 개수로 분할하고 요청들을 queue에 넣어서 순차적으로 처리하게 된다. 이를 실제로 담당하는 Backend 컴포넌트는 Querier이며 Querier는 Query Frontend의 요청을 처리하게 된다.
 
 
2. Querier
Querier는 Query Frontend로부터 요청받은 Trace ID들에 대해 찾은 뒤 응답을 해주는 역할을 가지고 있다.
 
단기 Trace에 대해서는 Ingester에게 요청하고 만약 Ingester가 가지고 있지 않은 데이터는 장기 저장소(S3)에 요청하여 가지고오게 된다.
 
 

Grafana Tempo 활용

지금까지 Grafana Tempo의 컴포넌트별 특징에 대해서 알아보았는데 이제 Grafana Tempo를 어떻게 좀 더 잘 활용할 수 있을까에 대해서 알아보고자 한다.
 
사실 필자는 Grafana Mimir, Loki 모두 사용하고 있지만 Grafana Tempo가 제일 Docs도 좋지 않고 자료 찾기가 힘들다.
 
아직 레퍼런스도 많이 없고 개발 초~중기 단계라 사용성이 많이 좋지 않은게 사실이다.
 
아래 글에서 얼추 설명하긴 했지만 좀 더 보완해서 정리해보려고 한다.
 
https://nyyang.tistory.com/175

Grafana Monitoring 스택 LGTM 구성기 (Loki, Mimir, Tempo)

 
 
 
 
1. Trace Pipeline
Application으로부터 발생된 메트릭이 최종적으로 Grafna Tempo로 전달되는 과정을 파이프라인이라고 해봤다.
 

https://faun.pub/grafana-cloud-tempo-3b95373ff9d0

 
 
필자는 Opentelemetry SDK를 사용하지 않고 좀 더 간편한 설치를 위해 Auto Instrumentation - Opentelemtry Agent 방식을 채택했으며 바로 Grafana Tempo로 보내는 것이 아니라 중간에 Opentelemetry Collector를 두어 최종적으로 Grafana Tempo로 전달되도록 했다.
 
Auto Instrumentation - Opentelemtry Agent 방식으로 Trace를 Application에서 발생시키고 있다면 당연히 간편한 설정이 장점인데 그에 반해 불필요한 Trace도 많이 발생한다는게 단점이다.
 
 
이러한 이유로 중간에 Opentelemetry Collector를 두어 불필요한 Trace들을 필터링하는 용도로 주로 사용하고 있다.
 
Opentelemetry는 크게 3가지 컴포넌트로 나뉜다.
- Receiver
- Processor
- Exporter
 
Receiver에서는 1) OTLP를 받고 추가로 2) Opentelemetry Collector 자신의 메트릭을 수집하는 prometheus receiver를 설정해주는게 필요하다.
 
Opentelemetry Collector에서 정상적으로 Trace를 잘 처리한 뒤 Exporter를 통해 Backend로 보내는지를 확인하는 과정 또한 중요하기 때문이다.
이렇게 발생된 메트릭들을 Grafana 대시보드화하여 모니터링하는게 좋다.
 
 
Processor에서는 필요한 정보는 주입해주고 불필요한 Attribute / Resource 정보는 없애거나 애초에 아예 제외시키고싶은 Trace는 제거하는 작업을 할 수 있다.
 
주로 많이 사용하는 Processor로는 다음과 같다.
 
 
- groupbytrace : 동일한 추적에서 모든 범위를 수집하고 다음 프로세서에 추적을 해제하기 전에 미리 결정된 시간 동안 기다림
- resource : resource 정보를 추가/삭제/변경할 수 있도록 도와준다.
- tail_sampling : 정의된 정책 기반으로 Trace를 Sampling하는 Processor인데 주로 불필요한 Trace를 필터링할 때 많이 쓰이곤 한다.

 

 
example)

        - name: delete_noisy_url
          type: string_attribute
          string_attribute:
            key: http.target
            values:
              - \/actuator*
              - \/health
            enabled_regex_matching: true
            invert_match: true

 
 
- memory_limiter
- batch
- ...
 
 
2. Metrics Generator
OTel을 통해 발생된 Trace data를 기반으로 Metric을 만들 수 있다. 이는 Tempo의 Metrics Generator 컴포넌트를 통해 할 수 있는데 이 메트릭들을 기반으로 대시보드 시각화가 가능하다.
 
 
그림에서 나오는 시각화 데이터가 바로 Metrics Generator를 통해 발생된 시계열 메트릭들이다.

 
 
설정값을 통해 좀 더 자세히 알아보자.

  config:
    registry:
      collection_interval: 15s
      external_labels: {}
      stale_duration: 15m
    processor:
      service_graphs:
        # -- Additional dimensions to add to the metrics. Dimensions are searched for in the
        # -- resource and span attributes and are added to the metrics if present.
        dimensions: []
        histogram_buckets: [0.1, 0.2, 0.4, 0.8, 1.6, 3.2, 6.4, 12.8]
        max_items: 10000
        wait: 10s
        workers: 10
      span_metrics:
        # -- Additional dimensions to add to the metrics along with the default dimensions.
        # -- Dimensions are searched for in the resource and span attributes and are added to the metrics if present.
        dimensions: []
        histogram_buckets: [0.002, 0.004, 0.008, 0.016, 0.032, 0.064, 0.128, 0.256, 0.512, 1.02, 2.05, 4.10]
    storage:
      path: /var/tempo/wal
      wal:
      remote_write_flush_deadline: 1m
      # -- A list of remote write endpoints.
      # -- https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
      remote_write: []
    metrics_ingestion_time_range_slack: 30s

 
 
processor는 프로세서(뭔가를 처리하는) 부분인데 processor의 service_graphs와 span_metrics 2가지 부분이 중요하다.
 
service_graphs는 말 그대로 서비스 그래프이다. A 서비스 <-> B 서비스 <-> C 데이터베이스 간 어떻게 연결되었는지를 시계열 메트릭으로 만들어주는 프로세서이다.
 
dimensions은 Trace 내 Span attribute 중 시계열 메트릭의 label로 변환하고 싶은것을 기입하면 되는 부분이다.
 
예를 들어 span attribute 중 http.status_code를 시계열 메트릭의 label로 추가하고 싶다면 dimensions에 넣어주면 된다는 뜻이다.

 
histogram_bucket은 '히스토그램에서 동일한 크기의 구간을 몇개로 잡을 것이냐'를 결정하는 부분이다. 뭐라고 설명해야 되는지를 몰라서 그냥 링크 하나 가져왔으니 궁금하시다면 들어가서 읽어보시면 될 것 같음
 
https://datamod.tistory.com/129

[데이터 기초] 버킷(혹은 버켓, bucket)에 관하여

 
 
span_metrics는 말 그대로 개별 Span과 관련된 시계열 메트릭 프로세서이다.
 
Span metrics을 통해 RED(Request, Error, Duration)를 뽑아낼 수 있으므로 해당 metric은 활용 가능성이 매우 높다.

 

 

하지만 Metrics Generator는 치명적인 단점이 있다.

 

OTEL Collector단에서 샘플링을 수행하게 되면 RED Metric을 제대로 만들어낼 수 없기 때문에 모든 Trace를 보내게 되며 이로 인해 불필요한 Trace 데이터를 저장하기에 Network 전송 비용 + 데이터 저장 비용 + 쿼리 속도 저하 등 여러가지 문제가 발생할 수 있다.

 

이런 이유로 필자는 Tempo의 Metrics Generator의 종속성을 해결하기 위해 RED Metric을 생성하는 부분을 OTEL Collector에서 생성하도록 변경하려고 준비하고 있다.

 

다만 RED Metric을 OTEL Collector에서 생성해내기 위해서는 좀 귀찮은 작업들이 필요해진다.

 

OTEL Collector를 2 layer로 구성해야 한다는 것이다.

 

 

따라서 다음의 OTEL Collector 구조로 구성해야 하게 될 것이다.

 

OTEL Collector (Load Balancing) -> OTEL Collector (Spanmetrics)

                                                                   -> OTEL Collector (Tail Sampling)

 

 

(참고)

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/exporter/loadbalancingexporter/README.md#configuration

 

물론 Metrics Generator로 Spanmetric을 생성하면 매우 쉽고 간편하게 메트릭을 생성할 수 있다는 장점이 있으니 각 상황에 맞게 선택할 것을 권장한다.

 

 
 

3. vParquet3
 
vParquet3는 최근 Grafana Tempo에서 도입된 Dedicated attribute columns이다. (전용 Attribute 컬럼)
 
https://grafana.com/blog/2023/11/01/grafana-tempo-2.3-release-faster-trace-queries-traceql-upgrades/

Grafana Tempo 2.3 release: faster trace queries, TraceQL upgrades | Grafana Labs

 
https://grafana.com/docs/tempo/latest/operations/dedicated_columns/

Dedicated attribute columns |  Grafana Tempo documentation

 
Grafana를 통해 Grafana Tempo의 Trace를 조회할 때 일반적으로 속도가 느릴 수 밖에 없다.
 
Grafana Tempo는 일반적으로 Full Search를 수행하기 때문인데 여기서 나온 아이디어로 '자주 접근하는 / 자주 사용되는' Attribute들을 Dedicated Column에 저장한다면 좀 더 빠르게 접근할 수 있다는 것으로부터 나온 개념이다.
 

 
 
parquet_dedicated_columns에 자주 사용되는 속성들 (ex. http.target, http.status_code, http.url, ..)을 parquet_dedicated_column에 저장하게 된다.
 
따라서 더 적은 데이터를 스캐닝하기 때문에 처리 속도가 빨라질 수 밖에 없다.
 
실제로 필자로 vParquet2 -> vParquet3를 적용하고 나서 현저히 빨라진 속도를 경험했다.

당연한게 더 적은 데이터를 스캐닝하기 때문이다.
 
 
그럼 어떤 Attribute를 Dedicated Column으로 저장하면 좋을까?
 
tempo-cli를 활용하면 어떤 컬럼을 추가할지 알 수 있다.
 
tempo-cli analyse blocks --backend=local --bucket=./cmd/tempo-cli/test-data/ single-tenant
 
이를 통해 테넌트의 모든 블록에 대해 크기별로 상위 N개의 Attribute를 확인할 수 있으며 이를 참고하여 vParquet3의 전용 속성 컬럼을 설정할 수 있다.

 

 

자세한 내용은 아래 블로그 내용을 확인하자.

 

https://grafana.com/blog/2024/01/22/accelerate-traceql-queries-at-scale-with-dedicated-attribute-columns-in-grafana-tempo/
 
 
 
 
4. 일반적으로 읽기 성능을 향상시키는 방법
 
Time range 동안의 Parquet Column을 모두 조회(풀서치)하는데 게다가 오브젝트 스토리지라서 상대적으로 느릴 수 밖에 없다.

 

아래 내용들에는 일반적으로 Read Performance를 향상시키는 방법에 대해 간략히 소개하지만

다른 포스팅에서는 좀 더 세분화하여 Tempo 읽기 속도를 최적화하는 방법에 대해 읽기 / 쓰기 부분으로 나누어 정리해볼까 한다.
 

 

#1. Cardinality가 높은 Attribute들 / 불필요한 Attribute들을 Opentelemetry Collector에서 필터링 (애초에 Grafana Tempo로 저장하지 않도록 하기 위함)
-> 이 때 주의해야 할 사항이 개별 Trace 전체를 없애는게 아니라 Span 내 Cardinality가 높은데 불필요한 특정 Attribute만 없애는게 좋다는 뜻이다.
 

 
 
#2. concurrent_job(동시성)을 올리고, query_shard(쿼리 프론트엔드에서 분할하는 단위)를 올리고, 읽기 컴포넌트를 수평 스케일링..
: 일반적으로 많이 소개되는 방법인데 좀 더 많은 리소스를 할당함으로써 쿼리 속도를 개선할 수 있는데, 더 많은 데이터를 처리해야하는 만큼 쿼리어에서 OOM이 날 수 있으니 조심하자
 
 
 
#3. AWS Lambda / Google Cloud Run와 같은 Serverless를 external Backend로 설정
대규모 환경에서만 권장된다고 한다... 실제로 사용해봤을 때 쿼리 속도가 빠르긴 하지만 Tempo 개발진에서는 대규모 환경에서만 권장된다고 해서 사용 안하고 있다.

 

왠만한 규모에서는 사용하지 않아도 충분히 커버할 수 있다.

 

#4. Memcached Caching
: Grafana Tempo의 자료구조인 Bloom Filter를 저장함으로써 좀 더 빠르게 parquet data에 접근할 수 있도록 도와준다고 한다.

물론 단순 설정만 한다고 도움이 되는게 아니라 Hit rate라던가 Compaction level 등 또한 확인하면서 적용하는게 필요할 것 같다.
 
https://grafana.com/docs/tempo/latest/operations/caching/

Accelerate TraceQL queries at scale with dedicated attribute columns in Grafana Tempo | Grafana Labs

 

 

 
#5. Compactor 처리량 모니터링
: Compactor는 Compaction(압축)을 담당하는 컴포넌트인데 압축기의 성능을 높이는 건 Block들의 크기를 좀 더 작게 해주는 역할을 하기 때문에 Network latency나 Querier가 처리하는 데이터양이 그만큼 줄어들기 때문에 읽기 성능 또한 늘어나게 된다.
 
또한 RF를 일반적으로 3개로 설정할텐데 이 때 데이터의 중복성을 줄여주는 것도 원인 중 하나이다. (Data Deduplication)
 
tempodb_compaction_outstanding_blocks 을 모니터링하면서 지연되고 있는 block들이 얼마나 있는지 확인해보면 된다.

 

가급적 compaction_outstanding_blocks이 되도록 0 언저리에 유지되도록 하자. 이 값을 기반으로 KEDA HPA를 적용할 수도 있고 Cron based HPA를 적용할 수도 있을 것이다.

 
https://github.com/grafana/tempo/blob/main/operations/tempo-mixin/runbook.md#tempocompactorstoomanyoutstandingblocks
 

 

#6. traceqlStreaming 활성화
trace가 처리될 때 querier 내부에 데이터를 쌓고 있는게 아니라 Grafana로 바로 Streaming하여 전달해주는 기능이다.
 
이 설정을 통해 Querier OOM(Out of memory)를 줄일 수 있음을 참고하자.
 
물론 이 기능을 사용하려면 Grafana feature toggle 설정을 해줘야 하고, tempo config 최상단에 stream_over_http_enabled 또한 설정해줘야 한다.
 
https://www.youtube.com/watch?v=7BRapaDM_2c

 
 

https://grafana.com/docs/tempo/latest/api_docs/

Tempo HTTP API |  Grafana Tempo documentation

 

 

 

#7. Ingester CPU 쓰로틀링 확인

 

Grafana Tempo Explore UI에서 Tag Values를 미리보여주기로 보여주곤 하는데 이 때 Querier는 Ingester의 Trace 데이터를 쿼리하여 값을 가져오게 된다.

 

만약 Querier -> Ingester로 Attribute Tag Values 값을 가져오는데 병목 현상이 발생할 경우 무한 로딩이 발생하는 현상을 확인할 수 있을 것이다.

 

따라서 Tempo Ingester가 배포되어 있는 EC2 혹은 VM의 CPU Usage 혹은 Load average를 주의깊게 확인해보자.

다른 Pod들이 CPU를 많이 쓰고 있는 상태에서 Querier -> Ingester로 Tag Values 요청이 왔다면 이 때 병목현상이 발생할 수 있다.

 

(실제로 Tag values 요청이 올 때 Ingester는 평상시 대비 수십배의 CPU를 사용함을 확인할 수 있다.)

 

 

 

 

(디버깅용도) Jaeger Tracing 활성화를 하려면?

 

아래 화면처럼 Query 요청이 들어올 경우 어디서 많은 시간이 소모되는지 확인하기 위해 jaeger Tracing을 활성화할 수 있다.

 

 

Docs에도 정리되어 있지만 정보가 부족하다.

 

https://grafana.com/docs/tempo/latest/operations/monitoring/#traces

Monitor Tempo | Grafana Tempo documentation

 

 

해당 Github Issue를 통해 활성화하는 방법을 좀 더 자세히 확인할 수 있다.

 

https://github.com/grafana/tempo/issues/1281#issuecomment-1036130124

Backend not hit · Issue #1281 · grafana/tempo

 

 

여기까지 간단하게 Grafana Tempo에 대해서 알아보았다.
 
물론 이를 전체적으로 모니터링하기위한 메트릭들 및 대시보드 구성, 쓰기 컴포넌트들에 대한 최적화, Metrics Generator를 통해 발생된 메트릭으로 대시보드를 세팅하는 방법, Examplars와 Log, Trace 간 연동하는 방법 등 소개하면 좋을 내용들이 더 있긴한데 분량상 이정도까지만 정리해보았다.
 
요즘 많은 회사들이 Prometheus와 Loki를 도입하는걸로 알고있고, 여기에 Tempo까지 같이 쓰기 위해 여러 회사들이 PoC를 진행중인 것으로 알고 있다.
 
LGTM Stack과 같이 쓰인다면 메트릭 - 로그 - 트레이스 간 연동의 장점때문에 요즘들어 많은 회사들이 조금씩 도입하려 하는 것 같다.
 

필자는 Tempo를 도입하면서 수많은 고통을 받았지만 누군가는 고통을 덜 받길 바라며 글을 마무리한다.
 

 
Ref
https://grafana.com/docs/tempo/latest/
https://faun.pub/grafana-cloud-tempo-3b95373ff9d0