OpenTelemetry: 최신 원격 측정의 표준
오픈텔레메트리(OTel) 생성을 위한 오픈 소스, 공급업체 중립적 프레임워크, 원격 측정 데이터 수집 및 내보내기. 이전 두 프로젝트의 합병으로 탄생 (OpenTracing 및 OpenCensus), OTel은 현재 세계에서 두 번째로 활발한 프로젝트입니다. 클라우드 네이티브 컴퓨팅 재단(CNCF) Kubernetes 이후, 1,000명 이상의 기여자 보유 모든 주요 관측 가능성 공급업체의 지원을 받을 수 있습니다.
OTel은 관찰 백엔드가 아닙니다. 데이터를 저장하지 않고 대시보드를 제공하지 않습니다. 그리고 하나 계측 표준 측정항목, 로그, 추적을 수집하는 방법을 정의합니다. 애플리케이션 코드에서 호환 가능한 백엔드(Jaeger, Prometheus, Datadog, New Relic, Grafana Cloud 등).
이러한 공급업체 중립적 접근 방식은 중요한 문제를 해결합니다. 즉, 코드를 한 번만 계측하면 됩니다. OTel API를 사용하면 애플리케이션 코드 한 줄도 건드리지 않고도 관찰성 백엔드를 변경할 수 있습니다.
이 기사에서 배울 내용
- OpenTelemetry 아키텍처: API, SDK, Collector 및 OTLP
- API와 SDK의 근본적인 차이점
- 세 가지 Otel 신호: 추적, 측정항목, 로그
- 의미론적 규칙과 그것이 중요한 이유
- OTLP(OpenTelemetry 프로토콜) 프로토콜
- 각 구성 요소의 성숙도 매트릭스 및 상태
OpenTelemetry 아키텍처
Otel 아키텍처는 함께 작동하여 다음을 제공하는 네 가지 주요 구성 요소로 구성됩니다. 코드 계측부터 내보내기까지 완전한 원격 측정 파이프라인 스토리지 및 시각화 백엔드.
1. API: 계측 계약
L'아피스 애플리케이션 코드가 원격 분석을 생성하는 데 사용하는 추상화 계층입니다. 구체적인 구현 없이 인터페이스와 유형을 정의합니다. SDK 없이 API만 설치하는 경우, 모든 통화는 무작동 (빈 작업), 제로 오버헤드 보장 원격 측정이 필요하지 않은 환경에서.
이러한 분리는 기본적으로 도서관: 계측된 라이브러리 OTel API는 이를 사용하는 애플리케이션이 특정 SDK를 채택하도록 강제하지 않습니다. 응용 프로그램 SDK를 등록하여 원격 측정 수집 여부와 방법을 결정합니다.
2. SDK: 구체적인 구현
L'SDK 수집, 처리의 구체적인 논리로 API 인터페이스를 구현합니다. 그리고 수출. SDK는 다음을 관리합니다.
- 견본 추출: 수집할 트랙과 삭제할 트랙을 결정합니다.
- 일괄 처리: 효율적인 전송을 위한 그룹 원격 측정 데이터
- 자원 감지: 환경(호스트, 컨테이너, 클라우드)을 자동으로 식별합니다.
- 수출: 구성된 내보내기를 통해 백엔드로 데이터를 보냅니다.
# Setup completo dell'SDK OpenTelemetry in Python
from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.sdk.resources import Resource
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
# 1. Definire la Resource (identità del servizio)
resource = Resource.create({
"service.name": "order-service",
"service.version": "1.2.0",
"deployment.environment": "production",
"service.instance.id": "order-service-pod-abc123"
})
# 2. Configurare il TracerProvider con exporter OTLP
tracer_provider = TracerProvider(resource=resource)
otlp_trace_exporter = OTLPSpanExporter(
endpoint="http://otel-collector:4317",
insecure=True
)
tracer_provider.add_span_processor(
BatchSpanProcessor(otlp_trace_exporter)
)
trace.set_tracer_provider(tracer_provider)
# 3. Configurare il MeterProvider con exporter OTLP
otlp_metric_exporter = OTLPMetricExporter(
endpoint="http://otel-collector:4317",
insecure=True
)
metric_reader = PeriodicExportingMetricReader(
otlp_metric_exporter,
export_interval_millis=60000
)
meter_provider = MeterProvider(
resource=resource,
metric_readers=[metric_reader]
)
metrics.set_meter_provider(meter_provider)
3. 수집기: 원격 측정 라우터
L'오텔 콜렉터 데이터를 수신, 처리 및 내보내는 독립형 구성 요소 원격 측정. 애플리케이션과 백엔드 간의 지능형 프록시로 작동하여 다음을 제공합니다. 일괄 처리, 재시도, 필터링 및 데이터 변환 기능.
Collector는 선택 사항입니다. 애플리케이션은 백엔드로 직접 내보낼 수 있습니다. 그러나, Collector는 프로덕션 환경에서 응용 프로그램을 분리하는 것이 좋습니다. 백엔드 구성 및 원격 측정 관리를 중앙 집중화합니다.
4. OTLP: 전송 프로토콜
L'OTLP(OpenTelemetry 프로토콜) 원격 측정 전송을 위한 기본 프로토콜 오텔에서. gRPC(기본, 고성능), HTTP/protobuf의 세 가지 전송 모드를 지원합니다. (방화벽 호환성) 및 HTTP/JSON(디버깅 및 테스트). 세 가지 모두 동일한 데이터를 전달합니다. 다른 인코딩으로.
Otel 아키텍처: 데이터 흐름
애플리케이션 (API + SDK) → 수출업체 (OTLP) → 수집기 (수신자 → 처리자 → 수출자) → 백엔드 (예거, 프로메테우스, 그라파나 클라우드 등)
OpenTelemetry의 세 가지 신호
OTel은 각각 성숙도가 다른 세 가지 유형의 원격 측정 신호를 지원합니다.
추적(안정)
Otel의 가장 성숙한 신호. 분산 추적은 요청 경로를 나타냅니다. 속성, 이벤트 및 링크가 포함된 범위로 구성된 서비스 전반에 걸쳐. 추적 API가 안정적입니다. 모든 주요 언어로.
지표(안정적)
OTel Metrics는 카운터, 히스토그램, 게이지의 세 가지 도구 유형을 지원합니다. 측정항목 API 안정적이며 구성 가능한 집계, 시간성(누적 및 델타) 및 카디널리티를 지원합니다. 뷰를 통해 제어됩니다.
로그(안정적)
추적 및 메트릭과 달리 OTel은 로깅을 위한 새로운 API를 도입하지 않습니다. 대신 배달해준다 에 로그 브릿지 API 기존 로깅 프레임워크(Log4j, SLF4J, Python 로깅, Winston)을 Otel 파이프라인에 추가하여 자동으로 추적 컨텍스트로 로그를 강화합니다.
Otel 신호의 성숙도 매트릭스
| 신호 | 아피스 | SDK | OTLP | 자가 계측 |
|---|---|---|---|---|
| 흔적 | 안정적인 | 안정적인 | 안정적인 | 안정적(Java, Python, .NET) |
| 측정항목 | 안정적인 | 안정적인 | 안정적인 | 안정적(Java, .NET) |
| 로그 | 안정적인 | 안정적인 | 안정적인 | 안정(자바) |
의미론적 규칙: 공유 어휘
Le 의미론적 규칙 속성에 대한 표준화된 이름 집합입니다. 다양한 라이브러리, 프레임워크 및 백엔드 간의 상호 운용성을 보장하는 측정항목 및 범위입니다. 의미론적 규칙이 없으면 각 팀은 동일한 개념에 대해 서로 다른 이름을 사용하게 됩니다. 서비스 간 상관 관계 및 분석이 불가능합니다.
# Esempi di Semantic Conventions per HTTP
# Tutte le librerie HTTP usano gli stessi nomi di attributi
# Attributi per span HTTP server
span.set_attribute("http.request.method", "POST")
span.set_attribute("url.path", "/api/v1/orders")
span.set_attribute("http.response.status_code", 201)
span.set_attribute("server.address", "api.example.com")
span.set_attribute("server.port", 443)
span.set_attribute("network.protocol.version", "1.1")
span.set_attribute("http.route", "/api/v1/orders")
# Attributi per span Database
span.set_attribute("db.system", "postgresql")
span.set_attribute("db.namespace", "orders_db")
span.set_attribute("db.operation.name", "SELECT")
span.set_attribute("db.query.text", "SELECT * FROM orders WHERE id = ?")
span.set_attribute("server.address", "db.internal")
span.set_attribute("server.port", 5432)
# Attributi per span Messaging
span.set_attribute("messaging.system", "kafka")
span.set_attribute("messaging.destination.name", "order-events")
span.set_attribute("messaging.operation.type", "publish")
span.set_attribute("messaging.message.id", "msg-12345")
의미론적 규칙은 HTTP, 데이터베이스, 메시징, RPC, 클라우드 공급자, 컨테이너 런타임 및 기타 여러 가지. 이를 따르면 백엔드가 해석할 수 있습니다. 원격 측정을 올바르게 수행하고 사전 구성된 대시보드 및 분석을 제공합니다.
언어용 SDK: 다중 언어 생태계
OTel은 주요 프로그래밍 언어에 대한 공식 SDK를 제공합니다. 각 SDK는 언어별 관용구를 사용하는 동일한 API로 기본 경험을 보장합니다.
// Setup OTel SDK in Java con Spring Boot
// build.gradle.kts
// implementation("io.opentelemetry:opentelemetry-api:1.36.0")
// implementation("io.opentelemetry:opentelemetry-sdk:1.36.0")
// implementation("io.opentelemetry:opentelemetry-exporter-otlp:1.36.0")
import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.metrics.Meter;
import io.opentelemetry.api.metrics.LongCounter;
import io.opentelemetry.context.Scope;
public class OrderService {
private final Tracer tracer;
private final LongCounter orderCounter;
public OrderService(OpenTelemetry openTelemetry) {
this.tracer = openTelemetry.getTracer("order-service", "1.0.0");
Meter meter = openTelemetry.getMeter("order-service", "1.0.0");
this.orderCounter = meter.counterBuilder("orders.created")
.setDescription("Number of orders created")
.setUnit("1")
.build();
}
public Order createOrder(OrderRequest request) {
Span span = tracer.spanBuilder("create-order")
.setAttribute("order.type", request.getType())
.setAttribute("order.items_count", request.getItems().size())
.startSpan();
try (Scope scope = span.makeCurrent()) {
Order order = processOrder(request);
orderCounter.add(1);
span.setAttribute("order.id", order.getId());
return order;
} catch (Exception e) {
span.recordException(e);
span.setStatus(StatusCode.ERROR, e.getMessage());
throw e;
} finally {
span.end();
}
}
}
공식적으로 지원되는 SDK
- 자바: 자동 계측 에이전트가 포함된 성숙한 SDK(가장 완벽함)
- 파이썬: 안정적인 SDK, Django, Flask, FastAPI 자동 계측
- Go: 안정적인 SDK, 기본 컨텍스트 전파를 통한 관용적 디자인
- .그물: 안정적인 SDK, ASP.NET Core와의 긴밀한 통합
- 자바스크립트/Node.js: 안정적인 SDK, Express 자동 계측, Fastify
- Rust: SDK 성숙화, 활발한 커뮤니티
- C++: 고성능 시나리오에 사용되는 Stable SDK
- 스위프트: iOS 및 macOS 애플리케이션용 최신 SDK
리소스: 서비스 ID
La 자원 원격 측정을 생성하는 엔터티를 식별하는 속성 집합입니다. 모든 신호(트레이스, 메트릭, 로그)에서 공유되며 필요한 환경 컨텍스트를 제공합니다. 데이터를 상호 연결합니다. 리소스는 SDK가 시작될 때 한 번 설정되고 일정하게 유지됩니다. 프로세스 전체 기간 동안.
# Resource attributes tipici in un ambiente Kubernetes
resource:
attributes:
# Identita del servizio
service.name: "order-service"
service.version: "2.1.0"
service.namespace: "ecommerce"
service.instance.id: "order-service-7d8f9b-xk2mp"
# Ambiente di deployment
deployment.environment: "production"
deployment.region: "eu-west-1"
# Kubernetes metadata
k8s.namespace.name: "ecommerce-prod"
k8s.pod.name: "order-service-7d8f9b-xk2mp"
k8s.deployment.name: "order-service"
k8s.node.name: "worker-node-03"
# Cloud provider
cloud.provider: "aws"
cloud.region: "eu-west-1"
cloud.availability_zone: "eu-west-1a"
채택 로드맵: 제로에서 생산까지
점진적인 조직 및 프로세스에서 OpenTelemetry를 채택하십시오. 계측할 필요 없음 첫날부터 모든 코드. 현실적인 로드맵에는 다음 세 단계가 포함됩니다.
Otel 채택 로드맵
1단계(1~2주차): 수집기 배포, 핵심 서비스에 대한 자동 계측,
백엔드 구성(Jaeger + Prometheus). 결과: 추적 및 측정항목에 대한 기본적인 가시성이 제공됩니다.
2단계(3~6주차): 중요한 범위에 대한 사용자 정의 속성 추가, 구성
샘플링, 로그-추적 상관관계 통합. 결과: 핵심 스트림에 대한 효과적인 디버깅.
3단계(2~3개월): 비즈니스 지표를 위한 수동 계측, Grafana 대시보드
맞춤형 SLO 기반 알림. 결과: 프로덕션 수준의 관찰 가능성.
결론 및 다음 단계
OpenTelemetry는 공급업체 중립적인 모듈식 아키텍처를 제공합니다. 계측(API), 수집(SDK), 라우팅(수집기) 및 내보내기(OTLP). 의미론적 규칙은 상호 운용성을 보장하는 동시에 다국어 지원을 제공합니다. 모든 기술 스택에서 Otel을 채택할 수 있습니다.
API/SDK 분리 및 아키텍처 키: 라이브러리는 API를 사용합니다(SDK가 없으면 오버헤드 없음). 애플리케이션은 적절한 내보내기를 사용하여 SDK를 구성합니다. 이 디자인을 사용하면 다음을 수행할 수 있습니다. 강제 종속성을 생성하지 않고 전체 생태계를 계측합니다.
다음 글에서는 이에 대해 더 자세히 알아보겠습니다. 분산 추적, 자세히 분석하다 범위, 추적 컨텍스트, W3C 추적 컨텍스트 프로토콜 및 상위-하위 관계 이는 분산 추적의 그래프를 형성합니다.