Open Telemetry

About OpenTEelemetry

OTel로도 알려져 있는 OpenTelemetry는 vendor에 종속적이지 않은 open-source '관측' framework 입니다.

이는 traces, metrics, logs들을 계측, 생성, 수집, 전달하는 기능을 제공합니다. 

이는 '산업표준' 입니다. 

 

Application structure, 출처: https://opentelemetry.io/docs/

 

계측 데이터 송/수신을 위한 '표준'

• 표준화된 SDK, API, tool을 제공하여 특정 vendor의 S/W에 종속적이지 않은 계측 수집 시스템 구축 방법을 제공
• trace, metric and log를 생산 및 송/수신하는 방법을 제공

 

아래 두 open-source projects의 통합이 'OpenTelemetry'

• OpenTracing
  • CNCF Project
• OpenCensus
  • Google Open Source Community Project

 

측정 데이터의 생산자는 OpenMetry 'API'를 통해 표준화된 '데이터'를 생산합니다.

이후 'SDK'는 생산된 데이터를 수집하고 전달하는 기능을 제공합니다. 

 

Trace

단일 request에 대한 trace 입니다.

추적의 단위는 span

trace는 span으로 이뤄진 tree

trace는 single root path를 지님

span은 고유의 context를 지님

root span과 child span

child span은 요청의 일부로 발생하는 작업들

 

 

Concepts

Observability Primer

관측이란?

시스템을 외부에서 관측하여 이해할 수 있도록 하는 것.

Application은 적절히 '계측(instrumented)' 되어야 합니다. 즉, app은 traces, metrics, log들과 같은 signal들을 제공해야 합니다. 

 

Traces

request가 만들어졌을 때 무슨일이 일어나는지에 대한 큰 그림을 제공합니다. 

 

ex.

{
	"name": "hello",
    "context": {
    	"trace_id": "0x238u2u2899183921",
        "span_id": "0x48480234bba39",
    },
    "parent_id": ...
    "start_time": ...
    "end_time": ...
    "attributes": {
    	"http.route": ...
    },
    "events": [
    	{
        	"name": "hi",
            "timestamp": "...",
            "attributes": {
            	"event_attributes": 1
            }
        },
        {
        	"name": ...
            "timestamp": ...
            "attributes": {
            	"event_attributes": 1
            }
        }
    ],
}

.... 반복 ....

위의 각각은 하나의 item 입니다. (위에서는 item 1개만 표시)

여러 item들은 같은 "trace_id"를 가질 수 있습니다. 이들은 함께 묶인 정보들이 됩니다. 

요청의 다양한 경로, timestamp 등의 를 통한 '흔적(trail)을 제공합니다. 

 

관련 components

Tracer

Tracer Provider

Trace Exporter

Trace Context

 

• Tracer Provider
  • TracerProvider는 Tracer의 Factory 입니다.
  • 한번 초기화 되고 app이 살아있는동안 함께 유지됩니다. 
  • 초기화 시 Resource와 Exporter 초기화도 함께 수행합니다.
• Tracer
  • service 내 request와 같은 어떤 수행에 대해 무엇이 일어나는지에 대한 정보를 담고 있는 'span'들을 생성합니다. 
• Trace Exporter
  • trace를 consumer로 전송하는 역할을 수행합니다. 
• Trace Context
  • trace span에 대한 metadata 입니다.
  • service와 process boundary를 가로지르는 span간의 상관성을 제공합니다. 
  • ex. Context Propagation
    • Service A가 Service B를 호출하고 이 call을 trace하고 싶다면,
    • OpenTelemetry는 Trace Context를 사용해서 Service A로부터의 trace의 ID와 Service A의 현재 span을 저장하여,
    • Service B에서 생성된 span들이 trace를 연결하고 추가할 수 있게 합니다. 
• Context Propagation
  • 분산 tracing의 core 개념
  • span이 어디에서 생성되었는지 관계없이 context propagation으로 span들은 서로 상관을 갖고 하나의 trace로 조립됩니다.
• Context
  • 송/수신 서비스에 대한 정보를 지닙니다. 이는 하나의 span을 다른것과 상관을 갖게하고 이들을 전체적인 trace로 연관시킵니다. 
• Propagation
  • Context를 service와 process간에 이동하는 매커니즘입니다.
  • 이를 통해 분산 trace가 조립됩니다. 
  • Span context를 ser/des 하며 적절한 trace 정보가 하나의 service에서 다른 service로 propagate 될 수 있도록 합니다. 
• Span Context는 traceId와 spanId, Trace Flags, Trace State를 통해 식별합니다. 
  • Trace state는 vendor-specific한 정보를 제공합니다. W3C Trace Context를 참고합니다. 

 

Span in OpenTelemetry

Span은 일 혹은 연산의 단위를 표현합니다. Span들은 Trace들의 building block 입니다. 

포함되는 정보들은 다음과 같습니다. 

ex. Sample Span

{
	"trace_id": ....
    "parent_id": ""
    "span_id": "...
    "name": "....
    "start_time": ..
    "end_time": ...
    "status_code": "STATUS_CODE_OK",
    "status_message": "",
    "attributes": {
    	"net.transport": "IP.TCP",
        "net.peer.ip": ...
        ...
    },
    "events": [
    	{
    		"name": ...
    	    "message": ...
	        "timestamp": ....
        }
    ]    
}

child span은 sub-operation을 표현합니다. 

 

• Span context
  • trace_id: span이 포함되는 trace에 대한 id 입니다.
• Attributes
  • k-value pair들
  • metadata를 지님
  • span이 item을 user의 cart에 추가하는 수행(operation)을 추적한다면, user의 ID와 item의 ID가 card에 추가되는 것을 capture 할 수 있습니다. 
  • attribute의 rule
    • 키들은 반드시 non-null string 값이어야 합니다.
    • value는 반드시 non-null string, boolean, floating point, integer 혹은 어떤 다른 값이어야 합니다. 
  • Semantic Attributes
    • metadata에 대한 naming convention으로 알려져 있음
    • common operation에 대한 metadata임
• Span Events
  • Span event는 하나의 Span 상의 log message(or annotation)로 보면 됨
• Span Links
  • 여러 span 간 연관을 지는 link
  • 어떤 연산들이 trace에 의해 추적된다면, 
  • 이런 연산들에 대해, 추가적인 연산이 큐잉되어 수행될 수 있습니다. 
  • 실행은 비동기입니다. 이런 경우에도 trace를 통해 뒤따르는 연산들을 추적할 수 있습니다.
  • 첫 번째 trace와 뒤따르는 연산(operation)들에 대한 trace를 연관시키고 싶습니다. 
  • 그런데, 언제 뒤따르는 연산들이 시작될지 알 수 없습니다. 
  • 이럴때 이 두 trace들을 span llink를 통해 연관 짓습니다. 
• Span Status
  • exception과 깉이 app code 상에 알려진 error가 있을 때 sapn 상태를 설정할 수 있습니다. 
  • Unset, Ok, Error
• status가 unset 상태를 유지해야 back-end의 span은 마지막에 final status로  할당되질 수 있습니다. 

 

 

Metrics

매트릭은 서비스에 대한 측정입니다. 

metric event는 측정치 뿐만 아니라 time 도 함께 구성됩니다. 

app과 request metrics은 가용성과 성능에 대한 주요 지표 입니다. 

 

3 metric instruments

• counter
  • 시간이 지나면서 커지는 값
  • odometer라고 생각하면 됨 (진행이 되고 있는 동안에만 계속 커짐)
• measure
  • 시간이 지남에 따라 합쳐지는 값
  • trip odometer와 유사
• observer
  • 특정 시점에 현재의 값들을 캡쳐

 

Logs

시간정보를 지닌 text 저장 이던가 혹은 meta data를 지닌 구조화된 혹은 구조화 되지 않은 text record임

log는 독립적인 data source 이기에 span에 추가될수도 있습니다. 

분산 trace의나 metric의 부분이 아닌 어떠한 data는 log 입니다. 

ex. events는 log 의 특별한 타입입니다. 

log는 종종 issue의 root cause를 찾는데 사용됩니다. 또한 변경에 대한 정보를 보통 포함합니다. 

 

Baggage

span간에 전달되는 문맥 정보

모든 span에 customerId가 있다고 가정합니다. 이는 여러 service에 엮을 수 있습니다만 CustomerId는 특정 service에만 가용합니다. 

span간 전달되는 문맥 정보가 baggage 입니다.

key-value store이며 trace context 내에 존재합니다. 

context propagation을 통해 Baggage를 전달합니다. 

서로 다른 lib의 구현은 propagator를 지니며, 이는 Baggage를 parse하고 가용하게 만듭니다.

 

baggage는 민감하지 않아서 3rd party에 노출되도 괜찮은 데이터를 위해서 사용해야 합니다.

 

 

Reliability & Metrics

telemetry는 system에서 나온 data, 그리고 행동임

data는 traces, metrics, log로부터 오게됨

 

Reliability: 오동작 하지 않고 의도한 대로 정상 동작하는 정도

Metrics: 특정 기간의 수치 데이터에 대한 집합 ex. system error rate, CPU utilization, request rate

SLI: Service Level Indicator: service의 행위에 대한 측정치

SLO: Serice Level Objective: 신뢰성있는 통신을 위한 수단

 

Understanding Dsitributed Tracing

Logs

log는 timestamp를 지닌 message

trace와 달리 특정 user의 request 혹은 transaction에 연관될 필요는 없음

contextual 정보가 없기에 code execution의 추적에 유용하지는 않음

span에 포함되면 좀 더 유용해짐

 

Spans

연산 혹은 작업의 단위

어떤 요청이 만드는 특정 연산을 추적

연산이 실행 되었을 시간 기간 동안 무엇이 발생했는지에 대한 그림을 그림

 

Distributed Traces

Trace로 더 잘 알려져 있음

여러 서비스 아키텍쳐(e.g., micro service)를 통해 전파되는 request에 의해 생긴 path들을 기록

tracing 없이 분산 시스템에서 성능 문제를 찾기가 어려움

system의 health에 대한 가시성을 높임

 

trace는 하나혹은 그 이상의 sapn으로 구성됨

첫 번째 span은 root span

각 root span은 하나의 request를 시작부터 종료까지 표현

부모 밑의 span들은 요청에서 무슨 일들이 일어났는지에 대한 보다 상세한 context를 제공

많은 관측 back-end는 다음과 같이 waterfall diagram으로 trace들을 시각화

 

출처: https://opentelemetry.io/docs/concepts/observability-primer/#distributed-traces

 

waterfall diagram은 부모-자식간의 관계를 보여줌