OpenTelemetry: Instrumenting

Instrumenting

core

OpenTelemetry API와 SDK의 구현을 제공

 

Instrumentation

모든 핵심 기능이 자동으로 다양한 lib과 framework에 더해짐

 

contrib

JmX metric gather와 같은 optional components

 

Automatic Instrumentation

자동 측정이 가능하려면 하나 이상의 의존이 필요.

환경변수, system property (e.g., Java의 system properties)

 

data source specific configuration

exporter configuration

propagator configuration

resource configuration

 

Manual Instrumentation

service code로 OpenTelemetry를 import 해야함 

lib이나 component를 개발하고 있다면, API의 의존성을 가져가야 함

standalone process 혹은 service라면, API 및 SDK의 의존성을 가져야함

 

Configure the OpenTelemetry API 

trace, metrics를 만들기 위해서는 일단 'tracer'를 생성해야 함 (혹은 meter provider)

보통 SDK가 하나의 기본 provider를 제공하기를 권장함

이후 tracer 혹은 meter instance를 provider로부터 얻고, name과 version을 제공

name은 무엇이 측정되는지를 식별할 수 있도록 지정

 

만약 lib을 작성중이라면, name은 

com.legitimatebusiness.myLibrary와 같은 식이 되어 고유 식별 가능하게 해야 함

version 정보도 주는 것을 권장함

i.e., semver:1.0.0

 

Configure the OpenTelemetry SDK

service process를 만들고 있다면, SDK를 설정해야 함

telemetry data를 다른 분석 backend로 제공하기 위한 적절한 설정이 필요

이런 설정은 configuration file을 통해 프로그램으로 다뤄지기를 추천

언어별 tuning 옵션들이 있음

 

Create Telemetry Data

API와 SDK를 일단 설정하고 나면, trace, metric event를 tracer를 통해 (그리고 meter object를 통해) 만들수 있음

trace를 생성하고 metric event를 생성하는 plugin 혹은 integration을 활용할수도 있음

https://opentelemetry.io/registry/

Registry

 

Export Data

일단 telemetry data를 만들었으면, 어딘가로 보낼 수 있음.

2가지 방법을 제공

바로 보내던가 혹은 OpenTelemetry Collector를 통해서 proxying 하여 보내던가 할 수 있음

 

metric object와 in-memory span을 적절한 format으로 translate

Jaeger 혹은 Prometheus같은 tool들을 위해서 

 

OTLP로 알려진 wire protocol도 제공

이는 data를 OpenTelemetry Collector로 전송하는데 사용

OpenTelemetry Collector는 standalone binary processs이며 proxy로서 혹은 service instance의 sidecar로서 별도의 host 상에서 동작

 

Collector는 원하는 분석 tool에 맞게 data를 전송 혹은 export 하도록 설정될 수 있음