티스토리 뷰
Observability란 무엇일까요?
Observability란 내부 동작 상황을 알 수 없는 시스템에 대하여 이해할 수 있도록 돕는 것, 정보를 의미합니다.
즉, 어떠한 문제가 발생하였을 때 Observability를 통해서 왜 이런 일이 발생했는지 유추해볼 수 있습니다.
너무 설명이 추상적인가요? 그럼, Observability 개념을 제외하고 생각해봅시다. 애플리케이션에서 어떠한 문제가 발생하였을 때, 어떻게 원인을 찾을 수 있을까요?
쉽게 생각한다면 "시스템 Log를 보죠!"라고 답할 수 있습니다.
맞아요. Log 도 Observability 범주에 속합니다. 더 넓게 trace, metrics, log, span 등과 같은 정보들. 즉, 애플리케이션의 상태를 계측할 수 있는 정보들을 의미합니다.
Terms
OpenTelmetry 내에선 여러 용어들이 사용되는데 이에 대해 정리해봅시다.
Telemetry
시스템의 동작에 대해 표현하는 데이터들을 의미합니다. 이러한 데이터는 Trace, Metric, Log, Span 같은 형태로 제공될 수 있습니다.
Reliability
'서비스가 사용자가 기대하는 것들을 제대로 100% 수행하고 있는가?'를 의미합니다.
예를 들어, 사용자가 검은색 바지에 대해 '장바구니에 추가'버튼을 눌렀다고 합시다. 근데 장바구니엔 담기지 않거나 다른 색상의 바지가 담겼다면, 이는 'Reliability하다' 또는 'Reliability 한 시스템'이라고 할 수 없습니다.
Metric
인프라 또는 애플리케이션에 대한 일정 기간동안의 숫자 데이터의 집계(aggregations)를 의미합니다. 예를 들면, CPU 사용률, Memory 사용률, 시스템 오류율, 초당 시스템 요청율 등이 있습니다.
Metric에 대한 추가적인 정보는 여길 참조해주세요.
Log
서비스 또는 구성 요소에서 출력하는 timestamp를 포함한 메시지를 의미합니다. Trace와 달리 특정 사용자의 요청이라던가, Transaction과 반드시 연관되어 있지는 않습니다. 왠만한 모든 애플리케이션에서 찾아볼 수 있으며, 개발자/운영자에게 시스템 동작을 이해하는데 도움을 줍니다.
예를 들어, 형태는 다음과 같습니다.
[2021-02-23T13:26:23.505892 #22473] INFO -- : [6459ffe1-ea53-4044-aaa3-bf902868f730] Started GET "/" for ::1 at 2021-02-23 13:26:23 -0800
단순히 애플리케이션에서 어떠한 동작을 할 때마다 메시지 남기기를 원하는 경우엔 Log를 사용하면 됩니다.
하지만 Log의 경우에 호출된 위치 같은 실행에 대한 Context 정보가 부족하기 때문에 코드 실행 프로세스를 추적하기 유용하지 않습니다. 더 욱이 MSA 같은 분산구조에서는 이를 활용해 실행 추적하는 것은 불가능에 가깝습니다.
Span의 일부로 포함되어 사용하면, 더 유용하게 사용할 수 있습니다.
Log에 대한 추가적인 정보는 여길 참조해주세요.
Span
작업, 작업의 단위를 의미합니다. 요청에 대한 작업을 추적해서 작업이 실행된 시간동안 발생한 일에 대해 정보를 가집니다.
이름, 시간 데이터, 구조화된 로그 메시지, 작업에 대한 메타데이터 등이 포함됩니다. 예를 들어, 형태는 다음과 같습니다.
{
"trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d",
"parent_id": "",
"span_id": "086e83747d0e381e",
"name": "/v1/sys/health",
"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": {
"net.transport": "IP.TCP",
"net.peer.ip": "172.17.0.1",
"net.peer.port": "51820",
"net.host.ip": "10.177.2.152",
"net.host.port": "26040",
"http.method": "GET",
"http.target": "/v1/sys/health",
"http.server_name": "mortar-gateway",
"http.route": "/v1/sys/health",
"http.user_agent": "Consul Health Check",
"http.scheme": "http",
"http.host": "10.177.2.152:26040",
"http.flavor": "1.1"
},
"events": {
"name": "",
"message": "OK",
"timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC"
}
}
Distributed Trace (Trace)
Microservice와 같은 다중 서비스(Multi-service) 아키텍처를 통해 요청 작업이 이뤄질 때, 그 실행 경로를 기록 및 추적하는 것을 의미합니다.
분산 시스템에서는 이슈, 성능문제 원인 등을 찾아내기가 어렵기 때문에, Distributed trace는 필수적입니다. 복잡한 분산 시스템에서 애플리케이션/시스템의 가시성을 향상시키고, 디버그에 도움을 주어 시스템을 분석 및 이해하는데 도움을 줍니다.
Trace는 하나 이상의 Span으로 구성됩니다. 첫 번째 Span(그림의 맨 위 막대)은 Root span을 의미하며, root span은 요청의 처음부터 끝까지를 의미합니다. 하위 span들은 root span 중 일어나는 경로들로 실행 경로들을 표현해서 심층적인 context를 제공합니다.
Trace에 대한 더 많은 정보는 여기 를 참조해주세요.
'Development > Server' 카테고리의 다른 글
Figma 원리: How Figma’s multiplayer technology works (0) | 2023.02.23 |
---|---|
[OpenTelemetry] 2. OpenTelemetry란 무엇일까? (0) | 2022.07.06 |
Linux File Permission (0) | 2022.04.05 |
Cookie, Session 그리고 Spring (0) | 2021.08.15 |
Port foward 하기 (0) | 2021.07.04 |
- Total
- Today
- Yesterday
- 백준
- 쿠버네티스
- 클린 아키텍처
- Spring boot
- HTTP
- python
- k8s
- Algorithm
- WebFlux
- java
- jasync
- 비동기
- 로그
- Log
- hexagonal architecture
- container
- 일상
- boj
- tag
- docker
- MySQL
- Kubernetes
- Spring
- c++
- Clean Architecture
- Intellij
- 하루
- gradle
- Istio
- 알고리즘
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |