마이크로서비스 아키텍처와 같이 여러 컴포넌트끼리 상호작용하는 시스템을 운영할 때, 특정 기능에서 에러가 발생하거나, 특정 조건에서 특정 기능의 처리량이 느리다거나 하는 이상 현상이 발생한다고 하자. 그러면 어떤 구간에서 에러가 발생했는지, 어떤 구간에서 병목현상이 발생했는지를 확인하고, 해결하는 과정이 필요한데 이를 분석할 환경이 따로 마련되어있지 않는다면 원인을 찾기 힘들 것이다.
이러한 복잡한 시스템을 운영하려면 시스템에 대한 상황을 종합적으로 확인할 수 있도록 돕는 도구가 반드시 필요하다. OpenTelemetry는 이러한 시스템을 관찰 가능하게 하도록 환경을 마련하는 데 돕는 오픈소스이다.
OpenTelemetry
OpenTelemetry는 분산 시스템의 관찰 가능성(Observability)을 제공하기 위한 오픈소스로, 애플리케이션의 로그, 메트릭, 추적 데이터를 수집, 처리, 보관하는 오픈소스이다.OpenTelemetry는 분산 시스템의 관찰 가능성을 제공하기 위한 오픈소스로, 애플리케이션의 로그, 메트릭, 추적 데이터를 수집, 처리, 보관하는 방법을 제공한다.
Observability
Observability는 로그, 메트릭, 추적과 같은 데이터를 기반으로 시스템에 대한 상태와 내부 동작을 파악하고 이해하는 능력을 말한다. 시스템에 대한 상태와 내부 동작을 이해하려면 그에 걸맞는 데이터가 쌓여있어야 한다. 이러한 데이터는 애플리케이션에서 만들어내야 한다. 이러한 데이터를 생성하고 수집하는 것을 계측이라고 한다. 즉, Observability는 계측된 데이터를 활용하여 시스템의 내부 상태를 분석하고 이해하는 것을 말한다.
Observability와 OpenTelemetry
Observability를 구성하려면 결국에 애플리케이션의 로그, 메트릭, 추적 데이터가 계측 되어야 한다. OpenTelemetry는 이러한 원격 분석 데이터를 생성하고, 수집하고 내보내는 일련의 프로세스를 관리하는 방식을 제공해준다. OpenTelemetry 자체에서는 애플리케이션 수준에서의 계측 라이브러리 또는 에이전트와, 원격 분석 데이터를 수집하는 적절한 백엔드로 전달해주는 Collector를 제공해주며 라이브러리/에이전트와 Collector, 백엔드 간의 데이터 전달 통신 규칙인 OTLP를 제공해준다.
OpenTelemetry 구성요소
OpenTeleemtry는 다음과 같은 구성요소로 이루어진다
- [Protocol] Log, Trace, Metric 등 계측 데이터와 그 데이터 전송을 위한 프로토콜 (OTLP)
- [For Application] Java/Kotlin을 포함한 여러 언어에 대한 독립적인 계측 라이브러리 / SDK / Agent 등
- 수동 계측이 있고, 자동 계측을 지원할 수도 있다.
- [Collector] 애플리케이션으로부터 데이터를 수집하여 계측 데이터 백엔드로 전송하는 OpenTelemetry Collector
- [Exporter] SDK, Collector에서 외부로 전송하는 도구이다.
- [Backend] 실제 Log, Trace, Metric 등의 원격 분석 데이터를 저장하는 백엔드이다. OpenTelemetry에서는 백엔드를 직접 관리하고 있지는 않지만 여러 백엔드에 데이터를 저장할 수 있도록 다양한 Exporter를 제공해준다.
대략적인 아키텍쳐 및 흐름
OpenTelemetry의 대략적인 아키텍처와 데이터 흐름은 다음과 같다.
- 애플리케이션에서는 OpenTelemetry Agent, API, SDK를 사용하여 애플리케이션 내 로그, 메트릭, 추적 정보를 주기적으로 OpenTelemetry Collector로 보낸다. 그외에도 여러가지 방식의 데이터를 OpenTelemetry Collector로 전송이 가능하다. (Jaeger, Prometheus, Kafka 등등)
- OpenTelemetry Collector는 여러개의 Receiver를 둘 수 있는데 여기서 등록된 Receiver에 데이터가 전달되면 데이터를 받아서 Processor에 전달한다.
- Receiver -> Processor -> Exporter 순으로 데이터가 흐른다.
- Processor는 데이터 종류(Log, Trace, Metric) 에 따라 다르게 설정할 수 있다.
- Processor는 Receiver로부터 받은 데이터를 필터링하거나 샘플링하거나 어트리뷰트를 추가/변경/삭제 하는 등 데이터를 처리한 다음에 Exporter로 전달한다.
- Exporter에는 등록된 백엔드로 데이터를 보낸다.
Data 구조
Trace
Trace는 요청이 전달될 때 애플리케이션에서 어떤 일이 발생했는지에 대한 전반적인 그림을 제공한다. Trace는 하나의 트랜잭션에서 거치는 전체적인 흐름을 이해하는 데 사용된다.
Trace 구조
Trace는 여러개의 Span을 가지며, 하나의 Span은 단일 작업에 대한 정보를 담고있다. 한 Trace에 있는 여러 Span은 고유의 traceId를 공유한다.
그리고 각 Span은 다음과 같은 정보를 포함한다.
{
"name": "/v1/sys/health",
"context": {
"trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d",
"span_id": "086e83747d0e381e"
},
"parent_id": "",
"start_time": "2021-10-22 16:04:01.209458162 +0000 UTC",
"end_time": "2021-10-22 16:04:01.209514132 +0000 UTC",
"status_code": "STATUS_CODE_OK",
"status_message": "",
"attributes": {
"http.method": "GET",
"http.target": "/v1/sys/health",
"http.server_name": "mortar-gateway",
"http.route": "/v1/sys/health",
...
},
"events": [
{
"name": "",
"message": "OK",
"timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC"
}
]
}- name (Span name)
- traceId, spanId, parentId (root span이면 parentId는 없다.) - trace와 span 간의 관계를 설명하는 정보
- start, end timestamp (해당 정보로 한 Span에서 소요되는 시간을 알 수 있다.)
- span status (status_code, status_message 등)
- event: Span의 구조화된 로그 메시지로, Span에서 어떤 일이 발생했는지를 간략하게 설명한다.
- attributes: key-value 쌍의 데이터로, Span에 대한 추가 정보를 기록하기 위해 사용된다.
- HTTP, SQL 등 Span에서 행한 요청 정보
- Span이 발생한 애플리케이션 및 인프라 정보 (애플리케이션 이름, 노드 이름, 가용성존 등)
- Attributes를 잘 활용하면 Observability의 퀄리티가 좋아질 수 있다.
Log
Log는 타임스탬프가 찍힌 텍스트 레코드이다. 보통은 애플리케이션이 특정 시간에 한 작업 내용이나 에러 등 여러가지를 기록하기 위해 사용한다. Log는 구조화될 수도 있고, 구조화되지 않을 수도 있다.
OpenTelemetry Log Record
OpenTelemetry에서는 결국은 구조화된 로그로 저장하게 된다. 로그 레코드의 필드 구조는 다음과 같다.
- Timestamp: 이벤트가 발생한 시간
- ObservedTimestamp: 이벤트가 관측된 시간
- TraceId, SpanId: 로그 발생 시점에서의 traceId 및 spanId, 이 값으로 한 트랜잭션에 있는 모든 로그를 수집할 수 있다.
- TraceFlags
- SeverityText: 로그레벨
- SeverityNumber: 로그 위험수준 정도
- Body: 로그 레코드 내용
- Resource: 로그의 출처를 나타낸다.
- InstrumentationScope: 로그를 방출한 범위
- Attributes: 이벤트에 대한 추가 정보
Metric
Metric은 CPU 사용량이나 메모리 사용량과 같이 특정 시점에서 측정된 데이터이다. 애플리케이션과 요청 메트릭은 가용성과 성능을 나타내는 중요한 지표이다. 이렇게 수집된 데이터를 통해 사용자 경험(API Latency 등)이나 시스템 전반에 대한 상황을 개괄적으로 파악할 수 있다. 추가로, 서비스 상태를 주기적으로 확인하여 서비스가 중단된 경우 알림 등을 구성하기 위해 활용되기도 한다.
댓글