https://grafana.com/docs/tempo/latest/introduction/telemetry/
grafana 공식 docs의 내용을 요약하면 아래 표와 같다
분류 | 용도 | 설명 |
prometheus
|
metrics
|
메트릭은 시스템 상태에 대한 높은 수준의 그림을 제공합니다. 메트릭은 숫자 값이기 때문에 알려진 임계값과 쉽게 비교할 수 있기 때문에 메트릭은 백그라운드에서 지속적으로 실행되고 값이 예상 범위를 벗어날 때 트리거되는 경고의 기초입니다. |
loki
|
logs
|
로그는 정보적 맥락을 만드는 단일 프로세스의 활동에 대한 감사 추적을 제공합니다. 로그는 더 높은 수준의 세부 정보를 제공하지만 상당히 더 많은 데이터 볼륨을 생성하는 대가를 치릅니다. 로그는 애플리케이션에서 무슨 일이 일어나고 있는지 알려줍니다. |
tempo
|
traces
|
추적은 데이터 경로의 각 단계 또는 작업에서 무슨 일이 일어나는지 알려줌으로써 관찰 가능성에 더욱 기여합니다. 추적은 무언가 잘못되고 있는 곳을 알려주는 지도를 제공합니다. 추적은 데이터 흐름 경로의 각 단계(예: HTTP 요청, 데이터베이스 조회, 타사 서비스 호출)가 완료되는 데 걸리는 시간을 그래픽으로 표현합니다. 새로운 요청이 시작되고 완료되는 위치와 시스템이 어떻게 대응하는지 보여줄 수 있습니다. 이 데이터는 문제 영역을 찾고 그 영향을 평가하는 데 도움이 되며, 요청 흐름을 추적하는 이 기능 없이는 결코 예상하거나 찾을 수 없었을 곳에서도 종종 발생합니다. |
결론적으로 tempo를 사용하면 시스템 성능 분석, 병목 현상 식별, 지연 시간 모니터링, 요청 처리 방법에 대한 전체적인 그림을 제공하는데 적합하다.
아래와 같은 구성으로 이루어진다.
instrumentation(계측) frameworks 에는 크게 3가지를 권장하고 있다.
https://grafana.com/docs/tempo/latest/getting-started/instrumentation/
- Zipkin은 주로 분산 시스템의 성능 문제를 해결하는 데 중점을 두고 있으며, 사용이 간편하고 설치가 쉽지만, 다른 데이터 유형과의 통합에는 제한적입니다.
- OpenTelemetry는 훨씬 더 포괄적인 솔루션으로, 다양한 데이터 수집 방식과 백엔드를 지원하여 유연성과 통합성이 뛰어나지만, 초기 설정이 다소 복잡할 수 있습니다.
- OpenTracing/Jaeger(deprecated)
Zipkin | OpenTelemetry | |
목적 | 분산 시스템의 요청 흐름을 추적하고 성능 문제를 파악 | 종합적인 관측성 구현 (추적, 메트릭, 로깅) |
범위 |
|
|
구성 요소 |
|
|
유연성 |
|
다양한 백엔드로의 데이터 전송 가능 (Jaeger, Prometheus, zipkin 등) |
구축 비용 | 상대적으로 간단한 설치 및 구성 | 초기 설정이 다소 복잡할 수 있지만, 표준화된 방식 제공 |
정밀도 | 고유한 ID를 통해 요청 추적 가능 | 다양한 메트릭 및 로그와 결합하여 더 정밀한 분석 가능 |
성능 | 높은 성능으로 실시간 데이터 처리 가능 | 성능은 구현 방식에 따라 다르며, 최적화 필요 |
OpenTelemetry Collector에 대한 고찰
항목 | 적용 O | 적용 X |
설정 및 관리 | 중앙 집중식 관리로 일관된 구성 가능 설정 변경이 한 곳에서 이루어짐 |
각 서비스에 SDK를 직접 통합해야 함 개별 서비스마다 별도의 설정 관리 필요 |
데이터 수집 | 다양한 데이터 유형을 통합적으로 수집 여러 통합 지원 (OTLP, Jaeger 등) |
메트릭, 트레이스, 로그를 각각 따로 수집해야 함 여러 통합 미지원 |
데이터 변환 | 수집된 데이터를 변환, 필터링 가능 필요한 정보만을 선택적으로 전송 |
데이터 전처리 및 변환이 어려움 수집한 데이터를 바로 전송 |
스케일링 | Collector를 통해 쉽게 스케일링 가능 로드 밸런싱과 고가용성 구현 가능 |
각 서비스가 직접 데이터 전송으로 스케일링 어려움 부하 분산이 복잡 |
모니터링 및 경고 | Collector를 통한 통합 모니터링 가능 이상 징후 감지 및 경고 설정 용이 |
별도의 모니터링 솔루션 필요 통합된 관측성 확보 어려움 |
유지 보수 | 유지 보수 용이 일관된 업데이트 및 관리 가능 |
각 서비스의 유지 보수가 복잡함 중복된 설정과 코드 필요 |
확장성 | 새로운 데이터 저장소나 분석 도구 추가 용이 확장성 있는 아키텍처 |
새로운 백엔드 추가 시 복잡함 시스템 확장성 제한 |
성능 | Collector를 통해 성능 최적화 가능 병목 현상 최소화 |
각 서비스에서 직접 데이터 전송으로 성능 저하 가능 최적화 어려움 |
커뮤니티 및 지원 | OpenTelemetry 커뮤니티의 지속적인 지원 문서화와 사례 공유 가능 |
개별 프로젝트에 의존 표준화 부족 |
도입을 통해 얻을 수 있는 이점
1. 강력한 추적 기능
- OpenTelemetry는 분산 시스템에서의 요청을 효과적으로 추적할 수 있는 표준화된 API를 제공합니다.
각 서비스 간의 호출 관계를 명확히 파악할 수 있어, 시스템의 복잡성을 관리하는 데 큰 도움이 됩니다. - Tempo는 이러한 트레이스를 수집하여 시각화합니다.
이를 통해 특정 요청의 흐름을 한눈에 확인할 수 있으며, 병목 지점을 쉽게 찾아낼 수 있습니다.
2. 문제 해결 속도 향상
문제 발생 시, OpenTelemetry가 수집한 데이터를 기반으로 Tempo에서 요청의 경과를 추적할 수 있습니다. 이는 문제의 원인을 신속하게 파악하고, 적절한 대응을 할 수 있도록 도와줍니다. 예를 들어, 성능 저하가 발생했을 때, 어떤 서비스에서 시간이 소요되는지를 즉시 확인할 수 있습니다.
3. 비용 효율적인 데이터 저장
Tempo는 데이터 저장에 있어 경량화된 접근 방식을 취하고 있습니다. 필요하지 않은 데이터를 저장하지 않고, 중요한 트레이스 정보만을 보존함으로써 스토리지 비용을 줄일 수 있습니다. 이는 대규모 환경에서 특히 유용합니다.
4. 확장성과 유연성
OpenTelemetry는 다양한 프로그래밍 언어와 프레임워크를 지원하므로, 우리의 기술 스택에 맞춰 쉽게 통합할 수 있습니다. 시스템이 확장될 때도 이점이 큽니다. 새로운 서비스나 기능이 추가될 때, 동일한 추적 체계를 유지할 수 있습니다.
5. 시각화 및 인사이트 제공
Grafana 대시보드를 통해 수집된 데이터를 시각화할 수 있습니다. 이를 통해 시스템 상태를 한눈에 모니터링하고, 데이터를 기반으로 한 인사이트를 팀과 공유할 수 있습니다. 이는 의사결정의 질을 높이는 데 기여합니다.
적용기
https://dev-junhee.tistory.com/82
[Tempo] Grafana Tempo 적용기 (2)
도입 배경기존에 Prometheus & Prometail + Loki 를 통해 로그, VM 메트릭 등의 데이터를 수집하고 Grafana를 이용한 시각 화를 통해 모니터링 기능을 구축하였었다. 추가적으로 이용자의 활동, 병목 구간
dev-junhee.tistory.com
Tempo + Prometheus API Dashboard

Prometheus JVM Dashboad
Tempo 도입 후 느낀점
- 어느 포인트에서 문제가 발생했는지 보기 쉽다. 오류가 난 영역에 대한 부분을 찾을 수 있다.
- 메소드에서 지연이 걸리는 부분을 분석하기 쉽다.
- GUI기반으로 한눈에 보기 쉽다.
- 오류 트래킹을 목적으로 사용하기는 어려운 점이 있고, API단위의 응답시간을 리포팅하기에 이점이 있다.
'Cloud' 카테고리의 다른 글
[ArgoCD] FE 배포 Helm 구성기 (2) | 2024.12.27 |
---|---|
[Tempo] Grafana Tempo 적용기 (2) (1) | 2024.11.19 |
[Kafka] CDC 도입기 (1) (0) | 2024.11.18 |
Kustomize, Helm Chart 시스템 구축 (0) | 2024.02.09 |
[ArgoCD] K8S 환경에 ArgoCD 뿌리기! (1) | 2024.02.09 |
댓글