OpenTelemetry 개념 정리

컴퓨터 공학/Backend Engineering

OpenTelemetry 개념 정리

혼새미로 2023. 5. 1. 15:41

"New York City in the style of Kay Sage" - Midjourney

사전지식: Telemetry Data

텔레메트리 데이터는 Tele (원격) + Metry (측정) + Data의 합성어로, 원격 소스에서 자동 또는 수동으로 수집 및 전송되는 데이터를 의미합니다. 이 데이터는 시스템의 상태, 성능 및 동작을 모니터링하는 데 사용됩니다.

Telemetry Data 유형

텔레메트리 데이터의 유형을 "시그널 (Signal)"이라고 하는 데, 시그널은 크게 로그, 메트릭 그리고 트레이스가 존재합니다.

Log: 로그는 인프라 및 애플리케이션에서 발생한 이벤트를 기록한 데이터를 의미합니다. 로그의 예로는 애플리케이션 예외 발생, 인프라에서 장애 발생 등을 기록할 수 있습니다.
Metric: 메트릭은 시간에 따른 특정 지표의 수치를 기록한 데이터를 의미합니다. 메트릭의 예로는 CPU 사용률, 요청 처리 속도, 메모리 사용량 등이 있습니다.
Trace: 트레이스는 분산 시스템에서의 요청 처리 과정에서 각각의 단계를 추적하는 데이터를 의미합니다. 예를 들어, 사용자의 요청이 웹서버에서 처리되고, 이후 데이터베이스에 쿼리를 보내는 과정에서 각각의 단계를 추적할 수 있습니다.

Telemetry Data가 없었다면?

많은 기업들이 AWS와 같은 CSP (Cloud Service Provider)에 마이크로서비스 아키텍처를 기반으로 다양한 서비스를 구축하여 사용하고 있습니다. 트위터는 현재 약 1000개의 서비스가 함께 동작하여 의미있는 결과를 발표하고 있습니다. 이때 텔레메트리 데이터가 없다면 문제를 해결하고 성능의 병목현상을 식별하기 어려울 수 있습니다.

다음은 애플리케이션에서 텔레메트리 데이터를 수집하지 않을 경우 발생할 수 있는 몇 가지 문제점입니다.

다운타임 시간 증가: 텔레메트리 데이터가 없으면 애플리케이션에서 발생한 문제를 식별하고 해결하기 어려워 다운타임 시간이 늘어날 수 있습니다.
성능 저하: 텔레메트리 데이터가 없으면 애플리케이션을 최적화하기 어려워 성능이 저하될 수 있습니다.
보안 위험 증가: 텔레메트리 데이터가 없으면 보안 위험을 식별하고 대응하기가 어려워 보안 위험이 증가할 수 있습니다.
- 예시 1) 악의적인 활동 식별: 텔레메트리 데이터를 사용하여 취약성을 악용하려는 사용자를 식별하고 이를 통해 해당 사용자가 시스템에 액세스하지 못하도록 차단할 수 있습니다.
- 예시 2) 취약성 패치: 텔레메트리 데이터를 사용하여 공격에 취약한 코드 영역을 식별하고 이를 사용하여 취약성을 패치하고 향후 공격을 방지할 수 있습니다.
- 예시 3) 보안 상태 모니터링: 회사가 네트워크에서 텔레메트리 데이터를 수집하는 경우 해당 데이터를 사용하여 보안 위반을 나타낼 수 있는 네트워크 트래픽의 변경 사항을 식별할 수 있습니다. 그런 다음 이 정보를 사용하여 침해를 조사하고 피해를 완화하기 위한 조치를 취할 수 있습니다.
비용 증가: 텔레메트리 데이터가 없으면 애플리케이션을 비용에 맞게 최적화하기 어려워 비용 증가로 이어질 수 있습니다.

이러한 위험을 완화하기 위해 CSP는 마이크로서비스 애플리케이션에서 텔레메트리 데이터를 수집해야 합니다. 이 데이터는 문제를 해결하고, 성능 병목 현상을 식별하고, 성능, 보안 및 비용 측면에서 애플리케이션을 최적화하는 데 사용할 수 있습니다.

Telemetry Framework

텔레메트리 프레임워크는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 분석하는 소프트웨어 플랫폼을 의미합니다.

텔레메트리 프레임워크에는 일반적으로 다음과 같은 기능이 제공됩니다.

데이터 수집: 텔레메트리 프레임워크는 소프트웨어 시스템에서 텔레메트리 데이터를 수집합니다. 이 데이터는 애플리케이션 로그, 시스템 로그 및 성능 카운터와 같은 다양한 소스에서 수집할 수 있습니다.
데이터 스토리지: 텔레메트리 프레임워크는 텔레메트리 데이터를 중앙 리포지토리에 저장합니다. 이 데이터는 CSV, JSON 및 프로메테우스와 같은 다양한 형식으로 저장할 수 있습니다.
데이터 분석: 텔레메트리 프레임워크는 텔레메트리 데이터를 분석하여 문제와 추세를 식별합니다.이 분석은 문제를 해결하고 성능을 개선하며 소프트웨어 시스템에 대한 더 나은 결정을 내리는 데 사용할 수 있습니다.

대표적인 텔레메트리 프레임워크로는 다음과 같습니다.

Prometheus: 프로메테우스는 애플리케이션 및 서비스에서 메트릭을 수집하는 오픈소스 모니터링 시스템입니다. 확장성과 유연성으로 유명합니다.
Grafana: 그라파나는 프로메테우스 및 기타 소스의 텔레메트리 데이터를 표시하는 데 사용할 수 있는 오픈소스 시각화 도구입니다.
ELK Stack: ELK 스택은 로그 수집, 저장 및 분석을 위한 인기있는 오픈소스 도구 모음입니다. Elasticsearch, Logstash, Kibana로 구성되어 있습니다.
Splunk: 스플렁크는 다양한 소스에서 텔레메트리 데이터를 수집하고 분석하는 상용 모니터링 및 분석 플랫폼입니다.
Dynatrace: 다이나트레이스는 클라우드 네이티브 애플리케이션용으로 설계된 상용 모니터링 및 분석 플랫폼입니다.
AppDynamics: 앱다이나믹스는 앤터프라이즈 애플리케이션용으로 설계된 상용 모니터링 및 분석 플랫폼입니다.

CCC (Cross-Cutting Concern)

일반적으로 횡단 관심사 (Cross-Cutting Conern)는 애플리케이션 내 여러 레이어 또는 여러 서비스 간의 공통 관심사를 의미합니다. 예를 들어, 로그, 메트릭, 트레이스와 같은 텔레메트리 데이터는 여러 서비스에서 공통적으로 필요한 기능이므로 이러한 기능을 횡단 관심사로 분류할 수 있습니다.

OpenTelemetry는 횡단 관심사를 처리하기 위한 프레임워크입니다. 다시 말해서, OpenTelemetry는 텔레메트리 데이터를 수집하고 저장하기 위한 도구가 될 수 있습니다.

마이크로서비스 구조가 보편화되고 상호의존적이고 연관 작업을 수행하는 서비스의 수가 많아짐에 따라 이러한 횡단 관심사인 텔레메트리 데이터를 AWS와 같은 특정 공급업체 또는 프로메테우스와 같은 특정 플랫폼에 종속적이지 않고, 여러 서비스들을 통틀어 중앙 집중식으로 수집하여 다양한 모니터링 및 분석 플랫폼으로 전파하기 위한 시스템의 필요성이 높아지게 되었습니다.

사전지식: Visibility와 Observability

두 용어는 상호교차 사용이 가능하지만 실제로는 다른 의미를 갖습니다. 비지빌리티는 시스템에서 어떤 일이 발생했는지 보는 능력을 의미하고, 옵저버빌리티는 왜 그 일이 발생했는지 이해하는 능력을 의미합니다. 다시 말하면, 비지빌리티는 데이터를 보는 능력, 옵저버빌리티는 데이터를 이해하는 능력을 의미합니다.

Visibility Monitoring과 Observability의 관계 도식화

예를 들어, 시스템에는 많은 비지빌리티는 가질 수 있지만 만약 데이터 라벨링이 올바르게 구성되어 있지 않을 경우 데이터가 의미하는 바를 이해하기 어렵습니다. 이때 옵저버빌리티라는 개념이 등장합니다. 옵저버빌리티는 컨텍스트와 다른 데이터 포인트 사이의 관계를 제공하여 데이터에 대한 이해도를 높이도록 돕습니다.

클라우드 컴퓨팅 환경이 고도로 복잡해짐에 따라 옵저버빌리티가 중요해지고 있습니다. 컨텍스트와 데이터 포인트 사이의 관계를 제공함으로써 옵저버빌리티는 문제를 더 빠르고 효율적으로 트러블슈팅하도록 지원합니다. OpenTelemetry는 텔레메트리 데이터를 수집, 내보내기 및 분석할 수 있도록 지원하는 옵저버빌리티 프레임워크입니다.

(참고로, 옵저버빌리티와 유사한 의미인 모니터링 (Monitoring)은 잠재적인 문제를 해결하기 위해 시스템에 대한 데이터를 수집하고 분석하는 프로세스를 의미합니다.)

Observability Frontend와 Backend

옵저버빌리티에 대해 조금 더 깊게 들어가면 OF (Observability Frontend)와 OB (Observability Backend)로 구분할 수 있습니다.

OF는 애플리케이션의 사용자 인터페이스 및 사용자 경험과 관련된 데이터의 수집 및 분석을 의미합니다. 여기에는 페이지 로드 시간, 네트워크 요청, 오류율 등이 포함됩니다. 개발자는 이 데이터를 분석하여 사용자가 애플리케이션과 상호작용하는 방식에 대한 통찰력을 얻고 개선할 수 있는 영역을 식별할 수 있습니다.

OB는 애플리케이션의 내부 작업과 관련된 데이터 수집 및 분석을 나타냅니다. 서버의 관점에서 애플리케이션의 성능과 동작을 모니터링하고 문제를 해결할 수 있는 기능입니다. 여기에는 CPU 사용량, 메모리 사용량, 데이터베이스 쿼리 등이 포함됩니다. 개발자는 이 데이터를 분석하여 시스템의 성능과 안정성에 대한 통찰력을 얻고 병목현상을 식별하고, 시스템의 전체 성능을 최적화하기 위해 개선할 수 있습니다.

프런트엔드와 백엔드에서 옵저버빌리티를 개선하는 데 사용할 수 있는 다양한 도구가 있습니다. 가장 많이 사용되는 도구는 다음과 같습니다.

OF 도구
- Google Analytics
- New Relic Browser
- Sentry
- Datadog
- Lightstep
OB 도구
- Prometheus
- Grafana
- Jaeger
- Elasticsearch
- Splunk
- Datadog
- Dynatrace
- AWS X-Ray

이러한 도구를 사용하면 애플리케이션의 성능과 동작을 더 잘 이해할 수 있으므로 문제를 더 빨리 식별하고 해결할 수 있습니다.

OpenTelemetry는 왜 만들어졌을까?

Otel이라고도 불리는 OpenTelemetry가 개발되기 전에도 이미 많은 텔레메트리 프레임워크가 존재했습니다. 그러나, 기존 텔레메트리 프레임워크에 여러 가지 문제가 있었습니다.

대표적으로 다음과 같은 문제가 있었습니다.

조각화: 각각의 고유한 API와 형식을 가진 여러 가지 텔레메트리 프레임워크가 존재했습니다. 이로 인해 다양한 시스템에서 텔레메트리 데이터를 수집하고 사용하기가 어려웠습니다.
공급업체 종속성: 많은 텔레메트리 프레임워크가 특정 공급업체나 플랫폼에 종속되어 있었습니다. 이로 인해 텔레메트리 데이터를 다른 공급업체나 플랫폼으로 옮기는 것이 어려웠습니다.
복잡성: 기존의 텔레메트리 프레임워크는 복잡하고 사용하기 어려운 경우가 많았습니다. 이로 인해 개발자가 애플리케이션에 옵저버빌리티를 추가하기가 어려웠습니다.

이러한 문제를 해결하기 위해 OpenTelemetry가 만들어졌습니다. OpenTelemetry는 클라우드 네이티브 세계에서 텔레메트리의 표준으로 빠르게 자리잡고 있습니다.

OpenTracing과 OpenCensus 합병

OpenTracing 및 OpenCensus는 애플리케이션에서 텔레메트리 데이터를 수집하는 방법을 제공하는 두 가지 오픈 소스 프로젝트입니다. 애플리케이션을 모니터링 및 디버깅하고 수행 방법을 이해하는 데 사용할 수 있습니다.

OpenTracing은 개발자가 애플리케이션 코드를 수정하지 않고도 애플리케이션에 트레이스를 추가할 수 있는 분산 추적 표준입니다. OpenCensus는 개발자가 애플리케이션 코드를 수정하지 않고도 애플리케이션에서 메트릭을 수집할 수 있는 메트릭 수집 및 모니터링 프레임워크입니다.

2019년에 OpenTracing과 OpenCensus가 합쳐지면서 OpenTelemetry가 되었습니다. OpenTelemetry는 애플리케이션에서 텔레메트리 데이터를 수집하는 방법을 제공하는 통합 프로젝트입니다. 벤더 중립적이고 이식 가능하며 확장 가능하도록 설계되었습니다.

OpenTracing과 OpenCensus가 OpenTelemetry로 병합된 데는 몇 가지 이유가 있습니다.

텔레메트리 데이터 수집을 위한 단일 통합 표준을 만듭니다. OpenTracing과 OpenCensus는 둘 다 텔레메트리 데이터 수집을 위한 경쟁 표준이었습니다. 합병을 통해 그들은 모두가 사용할 수 있는 단일 표준을 만들 수 있었습니다.
텔레메트리 데이터 수집 커뮤니티에서 조각화를 방지합니다. 두 가지 경쟁 표준으로 인해 텔레메트리 데이터 수집 커뮤니티가 조각화될 위험이 있었습니다. 병합을 통해 OpenTracing과 OpenCensus는 함께 작동하여 텔레메트리 데이터 수집 상태를 개선할 수 있는 단일 커뮤니티를 만들 수 있었습니다.
조직이 텔레메트리 데이터 수집을 더 쉽게 채택할 수 있도록 합니다. 두 개의 경쟁 표준으로 인해 조직에서 어떤 표준을 채택해야 하는지 알기가 어려웠습니다. OpenTracing과 OpenCensus를 병합함으로써 조직은 단일 통합 표준을 제공하여 텔레메트리 데이터 수집을 더 쉽게 채택할 수 있었습니다.

OpenTracing과 OpenCensus의 합병은 오픈 소스 텔레메트리 커뮤니티를 위한 주요 단계였습니다. 애플리케이션에서 텔레메트리 데이터를 수집하기 위한 포괄적인 기능 세트를 제공하는 단일 프로젝트를 만들었습니다. OpenTelemetry는 이제 클라우드 네이티브 세계에서 텔레메트리 데이터 수집을 위한 사실상의 표준입니다.

OpenTelemetry 특징

OpenTelemetry는 소프트웨어 시스템에서 텔레메트리 데이터를 수집, 내보내기 및 분석하는 통합적인 방법을 제공하는 오픈소스 옵저버빌리티 프레임워크입니다.

OpenTelemetry는 다양한 텔레메트리 도구 및 플랫폼과 함께 사용할 수 있도록 공급업체 중립적이고 이식 가능하도록 설계되었습니다. 또한 사용하기 쉽도록 설계되어 개발자가 빠르고 쉽게 애플리케이션에 옵저버빌리티 기능을 추가할 수 있습니다.

OpenTelemetry 도입 후 텔레메트리 데이터 수집 프로세스 도식화

OpenTelemetry의 주요 특징은 다음과 같습니다.

통합 API: OpenTelemetry는 텔레메트리 데이터를 수집하고 내보내는 통합 API를 제공하므로 사용 및 관리가 더 쉬워집니다.
공급업체 중립: OpenTelemetry는 특정 공급업체 또는 플랫폼에 종속되지 않으므로 다양한 도구 및 시스템과 함께 사용할 수 있습니다.
이식성: OpenTelemetry 데이터는 표준 형식이므로 서로 다른 시스템 간에 쉽게 교환할 수 있습니다.
간편한 사용: OpenTelemetry는 사용하기 쉽도록 설계되어 개발자가 애플리케이션에 옵저버빌리티를 빠르고 쉽게 추가할 수 있습니다.
다양한 텔레메트리 데이터 유형 지원: OpenTelemetry는 메트릭, 로그 및 트레이스를 포함한 다양한 텔레메트리 데이터 유형을 지원합니다.
다양한 텔레메트리 데이터 내보내기 지원: OpenTelemetry는 다양한 텔레메트리 내보내기를 지원하므로 텔레메트리를 다양한 시스템으로 내보낼 수 있습니다.
다양한 프로그래밍 언어 지원: OpenTelemetry는 다양한 프로그래밍 언어를 지원하므로 다양한 애플리케이션에서 사용할 수 있습니다.

전반적으로 OpenTelemetry는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 내보내기 위한 강력하고 유연한 도구입니다. 공급업체 중립적이고 이식성이 높고 사용하기 쉽도록 설계되어 애플리케이션에 옵저버빌리티를 추가해야 하는 개발자에게 훌륭한 선택지가 될 수 있습니다.

Instrumentation

소프트웨어 관점에서 계측 (Instrumentation)은 텔레메트리 데이터를 수집하기 위해 애플리케이션에 코드를 추가하는 프로세스를 의미합니다. 그런 다음 이 데이터를 사용하여 시스템 성능을 모니터링하고 잠재적인 문제를 식별하며 시스템의 설계 및 구현을 개선할 수 있습니다.

OpenTelemetry를 사용하여 텔레메트리 데이터를 수집하고 분석하기 위해 애플리케이션을 계측해야 합니다.

계측의 방식으로 크게 자동 계측과 수동 계측이 존재합니다.

자동 계측 (Automatic Instrumentation): 자동 계측은 소스코드를 수정할 필요 없이 애플리케이션에 계측 코드를 추가하는 방식입니다. 자동 계측은 애플리케이션에 계측을 추가하는 가장 빠르고 쉬운 방법이 될 수 있지만 수동 계측만큼 유연하거나 사용자 지정이 불가능할 수 있습니다.
수동 계측 (Manual Instrumentation): 수동 계측은 소스코드를 수정하여 애플리케이션에 계측을 위한 코드를 추가하는 방식입니다. 이것은 자동 계측보다 더 많은 시간이 소요되는 프로세스일 수 있지만 더 많은 유연성과 사용자 지정을 제공합니다. 수동 계측을 사용하여 코드의 특정 부분에 대한 텔레메트리 데이터를 수집하거나 사용자 지정 계측 논리를 추가할 수 있습니다.

OpenTelemetry의 자동 계측

OpenTelemetry의 자동 계측은 다양한 언어 및 프레임워크에 대해 지원합니다. 자동 계측을 사용하려면 언어 및 프레임워크 용 SDK를 설치해야 합니다. SDK를 통해 자동으로 애플리케이션을 계측하고 텔레메트리 데이터를 수집합니다.

OpenTelemetry의 수동 계측

OpenTelemetry에서 애플리케이션을 수동으로 계측하려면 OpenTelemetry SDK를 애플리케이션에 추가하고 텔레메트리 데이터를 수집하는 계측 코드를 작성해야 합니다. 계측 코드는 애플리케이션의 모든 부분에 추가할 수 있습니다.

OpenTelemetry에서 수동 계측을 위한 작업 순서는 다음과 같습니다.

Step 1. 애플리케이션에 OpenTelemety SDK를 추가합니다.

첫 번째 단계는 애플리케이션에 OpenTelemetry SDK를 추가하는 것입니다. OpenTelemetry는 다양한 언어와 프레임워크를 지원합니다. OpenTelemetry 웹 사이트에서 언어 및 프레임워크 용 SDK를 찾을 수 있습니다.

Step 2. 텔레메트리 데이터를 수집하는 계측 코드를 작성합니다.

OpenTelemetry SDK를 애플리케이션에 추가한 후에는 텔레메트리 데이터를 수집하는 계측 코드를 작성해야 합니다. 계측 코드는 애플리케이션의 모든 부분에 추가할 수 있습니다.

다음은 트레이스를 수집하는 계측 코드의 예시입니다.

const {Tracer} = require('@opentelemetry/api')
const express = require('express')

const app = new express()

app.get('/', (req, res) => {
    // Create a tracer object
    const tracer = tracer.startSpan('my-span')
    
    // Create a span object
    const span = tracer.startSpan('my-span')

    // Add attributes to the span object
    span.setAttribute('key', 'value')

    // Set the span object's status
    span.setStatus(SpanStatus.OK)

    // End the span object
    span.end()

    // Do something with the request and response
    res.send('Hello, world!')
})

위의 계측 코드는 스팬을 만들고 작업을 수행한 다음 스팬을 완료합니다. 스팬은 OpenTelemetry SDK에서 수집하고 텔레메트리 백엔드로 전송됩니다.

Step 3. Opentelemetry SDK를 구성합니다.

텔레메트리 데이터를 다양한 텔레메트리 백엔드로 내보내도록 OpenTelemetry SDK를 구성할 수 있습니다. SDK를 구성하려면 구성 파일을 만들고 사용할 백엔드를 지정해야 합니다.

다음은 텔레메트리 데이터를 프로메테우스로 내보내는 구성 파일의 예시입니다.

exporters: 
  prometheus: 
    endpoint: http://localhost:9200/metrics

텔레메트리 백엔드를 사용하여 텔레메트리 데이터를 분석하고 시각화할 수 있습니다. 예를 들어 프로메테우스를 사용하여 대시보드에서 텔레메트리 데이터를 시각화할 수 있습니다.

OpenTelemetry의 Trace

OpenTelemetry에서 트레이스의 주요 구성요소는 다음과 같습니다.

Context
Span
Propagation
Sampling
Resource

Context

OpenTelemetry에서는 횡단 관심사를 처리하기 위해 컨텍스트를 사용합니다. 컨텍스트는 애플리케이션 코드의 실행 중에 사용되는 데이터 컨테이너로서 키-값 쌍으로 구성되어 있으며 분산 시스템에서는 여러 컴포넌트와 서비스가 함께 동작하므로 각각의 컴포넌트에서 데이터를 전달하여 전체 시스템에서 일관된 작업을 수행할 수 있도록 해야 합니다.

예를 들어, 트레이스를 처리하기 위해서는 생성한 trace ID와 span ID를 각 서비스에서 공유해야 하며 이를 위해서는 각 서비스에서 컨텍스트 정보를 다음 서비스에 전달해야 합니다.

OpenTelemetry에는 두 가지 유형의 컨텍스트가 있습니다.

Trace Context: 트레이스 컨텍스트는 분산 시스템을 통해 실행 흐름을 추적하는 데 사용됩니다. 트레이스 컨텍스트는 트레이스를 식별하는 키-값 쌍 세트입니다.
- Trace ID, Span ID 및 추적 플래그 필드 (샘플링 결정과 같은 트레이스에 대한 추가 정보) 등으로 구성됩니다.
- HTTP 헤더, gRPC 메타데이터 및 환경 변수와 같은 다양한 메커니즘을 사용하여 전파됩니다.
- 트레이스 컨텍스트는 스팬을 서로 연결하는 데 사용됩니다.
Baggage Context: 배기지 컨텍스트는 프로세스 경계를 넘어 전파될 수 있는 데이터의 임의의 키-값 쌍을 저장하는 데 사용됩니다.
- 트레이스 컨텍스트와 유사하지만 특정 트레이스와 연결되지 않습니다.
- 배기지 컨텍스트는 사용자 ID, 세션 ID 또는 요청 ID와 같은 정보를 전파하는 데 사용할 수 있습니다.

이러한 컨텍스트는 분산 시스템에서 텔레메트리 데이터를 수집하고 전파하는 데 사용됩니다. 성능 병목 현상을 식별하고 문제를 해결하며 애플리케이션의 전체 성능을 개선하는 데 사용할 수 있습니다.

Span

스팬은 분산 시스템에서 트레이스 내에 시간이 존재하는 단일 작업을 의미합니다. 스팬을 중첩하여 트레이스 트리를 구성할 수 있습니다. 각 트레이스에는 일반적으로 엔드투엔드 지연 시간을 나타내면서 트레이스의 시작점을 나타내는 루트 스팬 (Root Span)과 선택적으로 하위 작업에 대한 하나 이상의 하위 스팬 (Sub Span)이 포함됩니다.

스팬의 주요 구성요소는 다음과 같습니다.

Span ID: 트레이스 내의 스팬에 대한 고유 식별자입니다.
Trace ID: 스팬이 속한 전체 트레이스에 대한 고유 식별자입니다.
Parent Span ID: 현재 스팬의 생성에 직접적인 원인이 된 스팬의 ID 입니다.
Span 이름: 추적 중인 작업을 설명하는 사람이 읽을 수 있는 이름입니다.
Start Time: 스팬이 시작된 시간입니다.
End Time: 스팬이 종료된 시간입니다.
Status: 작업이 성공적으로 완료되었는지 또는 실패했는지를 나타내는 스팬의 상태입니다.
Attributes: 스팬에 대한 추가 정보를 제공하는 키-값 쌍 입니다.
Events: 스팬의 수명 동안 발생한 이벤트 목록으로, 사람이 읽을 수 있는 메시지입니다.
Links: 현재 스팬과 관련된 다른 스팬 또는 트레이스에 대한 링크 목록입니다.

Span Events 예시

예를 들어, 뮤텍스 아래에 있는 리소스에 대한 배타적 액세스가 필요한 함수가 있을 때, 이벤트는 두 지점에서 생성될 수 있습니다. 한 번은 리소스에 대한 액세스 권한을 얻으려고 할 때와 뮤텍스를 획득할 때 입니다. 다음 소스코드는 루비 언어의 예시입니다.

require "opentelemetry/sdk"

span = OpenTelemetry::Trace.current_span

span.add_event("Acquiring lock")
if mutex.try_lock
  span.add_event("Got lock, doing work...")
  # some code here
  span.add_event("Releasing lock")
else
  span.add_event("Lock already in use")
end

Propagation

전파는 분산 시스템에서 트레이스 정보를 전파하는 메커니즘입니다. 분산 시스템에서는 여러 컴포넌트와 서비스가 함께 동작하므로 각각의 컴포넌트에서 트레이스 정보를 전파하여 전체 트레이스 정보를 수집하는 것이 중요합니다.

OpenTelemetry에서 트레이스 정보를 전파하는 일련의 작업은 다음과 같습니다.

Step 1. 애플리케이션은 트레이스 컨텍스트를 생성합니다.
Step 2. 애플리케이션은 트레이스 컨텍스트를 다음 서비스로 전파합니다.
Step 3. 다음 서비스는 새 스팬을 생성하고 이를 트레이스 컨텍스트와 연결합니다.
Step 4. 다음 서비스는 트레이스 컨텍스트를 다음 서비스로 전파합니다.
Step 5. 이 프로세스는 트레이스가 끝날 때 까지 계속됩니다.

다음은 OpenTelemetry에서 트레이스 정보를 전파하는 방법의 예시입니다.

// Create a trace context.
const traceContext = new TraceContext()

// Propagate the trace context to the next service.
const nextService = new Service('next-service')
nextService.setTraceContext(traceContext)

// Create a new span and associate it with the trace context.
const span = new Span('my-span')
nextService.setTraceContext(traceContext)

// This process continues until the trace reaches its end.

이 코드는 다음 정보를 포함하는 트레이스를 생성합니다.

서비스 이름
스팬 이름
스팬 시작 시간
스팬 종료 시간
스팬 상태
스팬에 추가된 모든 속성

이러한 트레이스는 프로메테우스, 예거 및 집킨과 같은 다양한 형식으로 내보낼 수 있습니다.

전파 매개체: Carrier

캐리어는 분산 시스템의 서로 다른 서비스 간에 컨텍스트를 전송하는 데 사용할 수 있는 데이터 구조입니다. 가장 일반적인 캐리어는 HTTP 헤더와 gRPC 헤더입니다.

스팬이 생성되면 해당 컨텍스트가 캐리어를 사용하여 분산 시스템의 다음 서비스로 전파됩니다. 그런 다음, 다음 서비스는 캐리어에서 컨텍스트를 추출 (extract)하고 이를 사용하여 새 스팬을 생성할 수 있습니다. 이 프로세스는 트레이스가 끝에 도달할 때 까지 계속됩니다.

Carrier 예시 - HTTP Propagation

HTTP 통신에서 트레이스 정보를 전파하기 위해 HTTP 헤더에 'traceparent'와 'tracestate'를 등록할 수 있습니다.

다음은 HTTP 헤더에 트레이스 정보를 추가하는 코드의 예시입니다.

const headers = new Headers()
headers.append('traceparent', '00-000000-b3-1')
headers.append('tracestate', 'foo=bar')

const request = new Request('GET', 'https://example.com')
request.headers = headers

const response = await fetch(request)

Sampling

시스템에서 생성되는 트레이스 정보의 양을 제한하는 프로세스입니다. 이는 텔레메트리 데이터 수집 및 저장 비용을 줄이거나 특정 트레이스에 집중하는 등 다양한 이유로 수행할 수 있습니다.

Sampling 방식

OpenTelemetry는 트레이스 정보를 수집하기 위한 샘플링 방식을 크게 Head Sampling과 Tail Sampling으로 구분하고 있습니다.

Head Sampling: 트레이스 시작 부분에서 트레이스를 수집할 지 여부를 결정하는 샘플링 기술입니다. 이 방식은 구현이 간단하고 트레이스 실행에 대한 지식이 필요하지 않기 때문에 가장 일반적인 샘플링 기술입니다.
Tail Sampling: 트레이스의 끝에서 트레이스를 수집할 지 여부를 결정하는 샘플링 기술입니다. 이 기술은 헤드 샘플링보다 구현하기가 더 복잡하지만 관심이 있을 만한 트레이스만 수집하므로 더 효율적일 수 있습니다.

	Head Sampling	Tail Sampling
장점	간단한 구현 트레이스 실행에 대한 지식이 불필요 모든 트레이스 형식과 함께 사용 가능	관심있는 트레이스를 수집 관심이 있을 만한 트레이스만 수집하므로 헤드 샘플링보다 효율적임
단점	관심있는 트레이스를 수집하지 못할 수 있음 관심이 없을 수 있는 트레이스를 수집하므로 비효율적임	헤드 샘플링보다 구현이 복잡함 모든 트레이스 형식이 테일 샘플링을 지원하는 것은 아님

사용할 최상의 샘플링 기술은 애플리케이션의 요구 사항에 따라 달라집니다. 애플리케이션이 모든 트레이스를 수집해야 하는 경우 헤드 샘플링이 가장 좋은 옵션이며, 관심있는 트레이스만 수집하면 되는 경우 테일 샘플링이 더 나은 옵션일 수 있습니다.

Sampling 전략

OpenTelemetry에는 수집되는 텔레메트리 데이터의 양을 제어하는 데 사용할 수 있는 다양한 샘플링 전략이 있습니다. 샘플링 전략은 전역 수준에서 구성하거나 계측 대상 별로 구성할 수 있습니다.

OpenTelemetry의 기본 샘플링 전략은 트레이스의 100%를 샘플링하는 것입니다. 즉, 모든 트레이스가 수집되어 콜렉터로 보내집니다. 그러나 이것은 특히 트래픽이 많은 애플리케이션의 경우 많은 양의 데이터가 될 수 있습니다.

수집되는 텔레메트리 데이터의 양을 줄여야 하는 경우 트레이스의 하위 집합을 샘플링하는 전략을 사용할 수 있습니다. 다음을 포함하여 사용할 수 있는 다양한 샘플링 전략이 있습니다.

확률 샘플링: 이 전략은 확률을 기반으로 트레이스를 샘플링합니다. 예를 들어 트레이스의 1%를 샘플링하도록 샘플링 전략을 구성할 수 있습니다.
지속적인 샘플링: 이 전략은 특정 기준을 충족하는 모든 트레이스를 샘플링합니다. 예를 들어 기간이 100ms를 초과하는 모든 트레이스를 샘플링하도록 샘플링 전략을 구성할 수 있습니다.
비율 제한: 이 전략은 초당 수집되는 트레이스 수를 제한합니다. 예를 들어 트레이스 수집을 초당 100개의 트레이스로 제한하도록 샘플링 전략을 구성할 수 있습니다.

애플리케이션에 가장 적합한 샘플링 전략은 애플리케이션의 특정 요구 사항에 따라 달라집니다. 사용할 샘플링 전략이 확실하지 않은 경우 기본 샘플링 전략으로 시작한 다음 필요에 따라 조정할 수 있습니다.

Resource

OpenTelemetry에서 리소스는 텔레메트리 속성으로 생성하는 엔터티의 불변 표현을 의미합니다. 예를 들어 쿠버네티스의 컨테이너에서 실행 중인 텔레메트리 데이터를 생성하는 프로세스에는 파드 이름, 네임스페이스 및 배포 이름이 있습니다. 이 세 가지 속성 모두 리소스에 포함될 수 있습니다.

리소스는 텔레메트리를 생성하는 엔터티를 식별하고 텔레메트리 데이터에 대한 컨텍스트를 제공하는 데 사용됩니다. 예를 들어 트레이스 또는 메트릭 데이터가 시스템의 대기 시간을 나타내는 경우 특정 컨테이너, 포드 또는 쿠버네티스 배포로 범위를 좁힐 수 있습니다.

이 리소스는 텔레메트리 데이터를 분류하는 데에도 사용됩니다. 예를 들어 리소스를 사용하여 다른 애플리케이션 또는 다른 환경의 텔레메트리 데이터를 구별할 수 있습니다.

OpenTelemetry의 구성요소

OpenTelemetry의 주요 구성요소는 다음과 같습니다.

OpenTelemetry API: OpenTelemetry API는 텔레메트리 데이터를 수집하고 내보내는 표준 방법을 제공하는 언어 간 API입니다.
OpenTelemetry SDKs: OpenTelemetry SDK는 OpenTelemetry API의 언어별 구현을 제공합니다.
OpenTelemetry Collector: OpenTelemetry 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 집계하는 서비스입니다.
OpenTelemetry Exporters: OpenTelemetry 익스포터는 텔레메트리 데이터를 프로메테우스, 그라파나 및 예거와 같은 다양한 대상으로 내보냅니다.
OpenTelemetry Semantic Conventions: OpenTelemetry 시맨틱 규칙은 텔레메트리 데이터의 이름을 지정하고 형식을 지정하는 표준 방법을 제공합니다.

이들은 OpenTelemetry의 주요 구성 요소입니다. 이들은 함께 텔레메트리 데이터를 수집, 집계 및 내보내기 위한 포괄적인 솔루션을 제공합니다.

OpenTelemetry API

OpenTelemetry API는 소프트웨어를 계측하는 일관된 방법을 제공하는 언어 독립적인 API입니다. 또한 공급업체에 구애받지 않도록 설계되었으므로 모든 텔레메트리 콜렉터 또는 익스포터와 함께 사용할 수 있습니다.

OpenTelemetry SDK

OpenTelemetry SDK는 소프트웨어 시스템에서 텔레메트리 데이터를 수집하고 내보내는 일관된 방법을 제공하는 OpenTelemetry API를 구현한 라이브러리 세트입니다.

OpenTelemetry SDK는 다음과 같은 주요 구성 요소로 구성됩니다.

Instrumentation Library: 계측 라이브러리는 텔레메트리 데이터로 소프트웨어 시스템을 계측하는 데 사용됩니다. 계측 라이브러리는 다양한 프로그래밍 언어로 제공됩니다.
Tracer: 트레이서는 스팬 및 메트릭과 같은 텔레메트리 데이터를 수집하고 기록하는 일을 담당합니다.
Exporter: 익스포터는 트레이서에서 프로메테우스, 그라파나 및 엘라스틱서치와 같은 다양한 대상으로 텔레메트리 데이터를 내보내는 데 사용됩니다.

OpenTelemetry SDK는 텔레메트리 데이터를 수집하고 내보내는 강력한 도구입니다. 사용하기 쉽고 다양한 프로그래밍 언어와 플랫폼에서 지원됩니다.

OpenTelemetry Collector

OpenTelemetry 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 집계하는 서비스입니다. 메트릭, 트레이스 및 로그를 수집하는 데 사용할 수 있습니다. 콜렉터는 온프레미스, 클라우드 및 하이브리드 환경을 비롯한 다양한 환경에 배포할 수 있습니다.

OpenTelemetry Collector 구성요소

콜렉터는 다음과 같은 여러 주요 구성요소가 있습니다.

Receivers: 리시버는 애플리케이션에서 텔레메트리 데이터를 수집하는 역할을 합니다.
Processors: 프로세서는 텔레메트리 데이터 처리를 담당합니다. 여기에는 데이터 필터링, 변환 및 집계가 포함될 수 있습니다.
Exporters: 익스포터는 텔레메트리 데이터를 다양한 대상으로 내보낼 책임이 있습니다.

콜렉터는 다음을 비롯한 다양한 소스에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.

애플리케이션: 콜렉터는 OpenTelemetry SDK로 계측된 애플리케이션에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.
인프라: 콜렉터는 서버, 데이터베이스 및 네트워크와 같은 인프라 구성 요소에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.
클라우드 서비스: 콜렉터는 AWS, Azure 및 Google Cloud Platform과 같은 클라우드 서비스에서 텔레메트리 데이터를 수집하는 데 사용할 수 있습니다.

OpenTelemetry Collector에서 Processor의 처리 방식

OpenTelemetry 콜렉터에서 프로세서의 데이터 처리 방식은 크게 '배치 프로세서 (Batch Processor)'와 '심플 프로세서 (Simple Processor)'로 구분됩니다. 배치 프로세서와 심플 프로세서의 주요 차이점은 배치 프로세서는 텔레메트리 데이터를 내보내기 전에 함께 그룹화하는 반면, 심플 프로세서는 텔레메트리 데이터를 수신하는 즉시 내보냅니다.

배치 프로세서를 사용하여 수행되는 네트워크 요청 수를 줄임으로써 OpenTelemetry 콜렉터의 성능을 향상시킬 수 있습니다. 이는 배치 프로세서가 텔레메트리 데이터를 함께 그룹화하고 단일 요청으로 내보낼 수 있기 때문입니다. 이는 대량의 텔레메트리 데이터에 특히 유용할 수 있습니다.

심플 프로세서는 일반적으로 OpenTelemetry 콜렉터의 성능이 문제가 되지 않을 때 사용됩니다. 이는 심플 프로세서가 원격 측정 데이터를 수신하는 즉시 내보내기 때문입니다. 이는 실시간 텔레메트리 데이터가 필요한 애플리케이션에 유용할 수 있습니다.

	배치 프로세서	심플 프로세서
텔레메트리 데이터를 내보내기 전에 함께 그룹화합니다	아니오	예
네트워크 요청 수 감소	예	아니오
대량의 텔레메트리 데이터에 유용	예	아니오
실시간 텔레메트리 데이터가 필요한 애플리케이션에 유용	아니오	예

궁극적으로 최상의 프로세서 선택은 특정 요구 사항에 따라 다릅니다. OpenTelemetry 콜렉터의 성능이 우려되는 경우 배치 프로세서를 사용해야 합니다. OpenTelemetry 콜렉터의 성능에 대해 걱정하지 않는다면 심플 프로세서를 사용할 수 있습니다.

OpenTelemetry Collector의 배포 모드

OpenTelemetry 콜렉터는 에이전트 모드와 게이트웨이 모드의 두 가지 모드로 배포할 수 있습니다.

Agent Mode: 에이전트 모드에서 콜렉터는 모니터링 중인 애플리케이션과 함께 배포됩니다. 콜렉터는 애플리케이션에서 텔레메트리 데이터를 수집하여 중앙 위치로 보냅니다.
Gateway Mode: 게이트웨이 모드에서 콜렉터는 독립 실행형 서비스로 배포됩니다. 콜렉터는 여러 소스에서 텔레메트리 데이터를 수집하고 중앙 위치로 보내기 전에 집계합니다.

에이전트와 게이트웨이의 주요 차이점은 텔레메트리 데이터를 수집하는 방법입니다. 에이전트는 함께 배포된 애플리케이션에서 텔레메트리 데이터를 수집합니다. 게이트웨이는 여러 소스에서 텔레메트리 데이터를 수집합니다.

게이트웨이는 에이전트에 비해 다음과 같은 몇 가지 이점을 제공합니다.

중앙 집중식 수집: 게이트웨이는 애플리케이션의 관리 및 모니터링을 단순화할 수 있는 여러 소스에서 텔레메트리 데이터를 수집합니다.
향상된 성능: 게이트웨이는 텔레메트리 수집을 전용 서비스로 오프로드하여 애플리케이션의 성능을 향상시킬 수 있습니다.
유연성: 게이트웨이는 다양한 환경에 배포할 수 있으므로 에이전트보다 더 유연합니다.

애플리케이션의 옵저버빌리티를 개선할 방법을 찾고 있다면 게이트웨이를 사용하는 것이 좋습니다. 게이트웨이는 중앙 집중식 수집, 향상된 성능 및 유연성을 포함하여 에이전트에 비해 많은 이점을 제공합니다.

OpenTelemetry Exporter

OpenTelemetry 익스포터는 수집된 트레이스 데이터를 외부 시스템으로 전송하는 역할을 합니다. 익스포터는 수집된 트레이스 데이터를 다양한 형식으로 변환하여 원하는 시스템으로 전송합니다.

예를 들어, 트레이스 데이터를 JSON 형식으로 변환하여 HTTP 프로토콜을 사용하여 Elasticsearch로 전송할 수 있습니다. 또는, 트레이스 데이터를 Protocol Buffers 형식으로 변환하여 gRPC 프로토콜을 사용하여 Jaeger로 전송할 수도 있습니다.

OpenTelemetry에서는 다양한 익스포터를 제공합니다. 예를 들어, Jaeger, Zipkin, Prometheus, Elasticsearch, AWS X-Ray 등이 있습니다. 이러한 익스포터를 사용하여 트레이스 데이터를 다양한 시스템으로 전송할 수 있습니다. 또한, 사용자 정의 익스포터를 작성하여 원하는 시스템으로 트레이스 데이터를 전송할 수도 있습니다.

OpenTelemetry Semantic Conventions

시맨틱 규칙은 텔레메트리 데이터의 일관된 수집 및 분석을 허용하기 때문에 OpenTelemetry에서 중요합니다. 이러한 일관성은 다음과 같은 여러 가지 이유로 중요합니다.

교차 도구 분석 활성화: 시맨틱 규칙을 통해 도구는 다른 도구를 사용하여 데이터를 수집한 경우에도 텔레메트리 데이터의 의미를 이해할 수 있습니다. 이를 통해 서로 다른 도구의 데이터를 함께 사용할 수 있으므로 보다 포괄적이고 정확한 분석이 가능합니다.
텔레메트리 데이터의 품질 향상: 의미 체계는 일관되고 표준화된 방식으로 수집되도록 하여 텔레메트리 데이터의 품질을 향상시키는 데 도움이 될 수 있습니다. 이렇게 하면 오류를 줄이고 문제를 더 쉽게 해결할 수 있습니다.
텔레메트리 분석 데이터의 접근성 향상: 시맨틱 규칙은 텔레메트리 분석 데이터를 보다 쉽게 이해하고 사용할 수 있도록 하여 접근성을 높일 수 있습니다. 이를 통해 문제 해결 및 분석의 효율성을 높일 수 있습니다.

시맨틱 규칙이 없으면 텔레메트리 데이터를 이해하기 어려울 수 있습니다. 예를 들어 서로 다른 두 팀이 동시에 동일한 애플리케이션에 대한 메트릭을 수집하는 경우 동일한 메트릭에 대해 서로 다른 이름을 사용하거나 동일한 메트릭에 대해 서로 다른 속성을 수집할 수 있습니다. 이로 인해 두 팀의 데이터를 비교하거나 데이터를 사용하여 문제를 해결하기가 어려울 수 있습니다.

시맨틱 규칙은 텔레메트리 데이터를 설명하기 위한 공통 어휘를 제공하여 이 문제를 해결하는 데 도움이 됩니다. 이를 통해 다양한 도구와 팀에서 텔레메트리 데이터를 일괄되게 수집, 분석 및 시각화할 수 있습니다.

현재 시맨틱 규칙은 트레이스, 메트릭 및 리소스에 사용할 수 있습니다.

Semantic Conventions | OpenTelemetry.io

Semantic Convention 예시

다음은 OpenTelemetry의 시맨틱 규칙의 예시입니다.

메트릭 이름: 메트릭 이름을 설명적이어야 하며 일관된 명명 규칙을 따라야 합니다. 예를 들어 현재 진행 중인 동시 HTTP 요청 수를 측정하는 메트릭은 "http.server.active_requests"라는 이름을 가져야 합니다.

이 이름은 설명적이며 일관된 명명 규칙을 따릅니다. 메트릭이 무엇을 측정하는 지 명확하고 다른 메트릭과 어떻게 관련되는 지 쉽게 이해할 수 있습니다.

시맨틱 규칙을 따르면 텔레메트리 데이터가 일관되고 정확하고 사용하기 쉬운지 확인할 수 있습니다. 이는 보다 포괄적이고 정확한 분석으로 이어져 애플리케이션 및 서비스의 성능과 안정성을 개선하는 데 도움이 될 수 있습니다.

기타: OTLP

OTLP는 OpenTelemetry 프로토콜을 나타냅니다. 텔레메트리 데이터를 수집하고 내보내는 표준 방법입니다. OTLP는 효율적이고 확장 가능하며 안전하도록 설계되었습니다. 또한 다른 옵저버빌리티 도구와 상호 운용이 가능하도록 설계되었습니다.

OTLP 사용의 이점은 다음과 같습니다.

효율성: OTLP는 효율적으로 설계되어 텔레메트리 데이터를 수집하고 내보내는 오버헤드를 줄이는 데 도움이 될 수 있습니다.
확장성: OTLP는 확장 가능하도록 설계되어 대규모 시스템에서 텔레메트리 데이터의 수집 및 내보내기를 지원하는 데 도움이 될 수 있습니다.
보안: OTLP는 텔레메트리 데이터의 기밀성, 무결성 및 가용성을 보호하는 데 도움이 되도록 안전하게 설계되었습니다.
상호 운용성: OTLP는 텔레메트리 데이터를 최대한 활용하는 데 도움이 되는 다른 옵저버빌리티 도구와 상호 운용이 가능하도록 설계되었습니다.

텔레메트리 데이터를 수집하고 내보내는 방법을 찾고 있다면 OTLP를 사용하는 것이 좋습니다. 효율적이고 확장 가능하며 안전하고 상호 운용 가능한 원격 측정 데이터를 수집하고 내보내는 표준 방법입니다.

기타: OpenTelemetry Metric 유형

OpenTelemetry는 네 가지 메트릭 유형을 정의합니다.

카운터: 카운터는 누적 값을 추적하는 데 사용됩니다. 증가하거나 감소할 수 있습니다.
게이지: 게이지는 현재 값을 추적하는 데 사용됩니다. 임의의 값으로 설정할 수 있습니다.
히스토그램: 히스토그램은 값의 분포를 추적하는 데 사용됩니다. 요청 대기 시간 또는 응답 크기와 같은 항목을 추적하는 데 사용할 수 있습니다.
요약 (legacy): 요약은 히스토그램과 비슷하지만 더 가볍습니다. 오류 또는 시간 초과와 같은 항목을 추적하는 데 사용할 수 있습니다. 요약은 OpenTelemetry의 다른 유형과 달리 요약은 항상 의미있는 방식으로 병합될 수 없습니다. 이 유형은 새 애플리케이션에 권장되지 않으며 다른 형식과 호환성을 위해 존재합니다.

Metric data model | OpenTelemetry.io

Unified ServerlessObservability With OpenTelemetry and StackState v4.6 | StackState

마무리

결론적으로 OpenTelemetry는 텔레메트리 데이터를 수집하고 내보내는 강력한 도구입니다. 사용하기 쉽고 다양한 프로그래밍 언어와 플랫폼에서 지원됩니다. 텔레메트리 데이터를 수집하고 내보내는 방법을 찾고 있다면 OpenTelemetry가 좋은 선택지입니다.

Assisted by

ChatGPT, Bard

저작자표시

'컴퓨터 공학 > Backend Engineering' 카테고리의 다른 글

AWS의 OpenTelemetry 지원 (0)	2023.05.13
Kubernetes의 OpenTelemetry 지원 (0)	2023.05.13

현재글OpenTelemetry 개념 정리

혼새미로의 종합 블로그입니다. Youtube: Honsemiro

데이터통신, 유니티, typeScript, c++, 큐티프로그래밍, 알고리즘, qt프로그래밍, JavaScript, 영어, 게임, It, node.js, 맵핑, QT, 자바스크립트, 타입스크립트, 포탈스마일, 빅데이터, nodejs, 컴퓨터,

Today :
Yesterday :

일	월	화	수	목	금	토
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30