소개: 분산 시스템의 관찰 가능성
L'관찰 가능성 복잡한 시스템의 내부 상태를 이해하는 능력 외부를 향해 생성되는 신호를 분석합니다. 반응하는 기존 모니터링과 달리 미리 정의된 질문("서버가 활성 상태입니까?", "CPU가 80% 이상입니까?")에 대해 관찰 기능을 사용하면 다음을 수행할 수 있습니다. 탐험하다 알 수 없는 질문: 이 요청은 왜 3초가 걸렸나요? 예 12개의 마이크로서비스를 통과하는 흐름의 병목 현상을 확인했습니까?
마이크로서비스, 컨테이너 및 클라우드 네이티브 아키텍처를 기반으로 하는 최신 시스템에서는 기존 모니터링이 더 이상 충분하지 않습니다. 단일 사용자 요청은 수십 개의 서비스, 메시지 대기열 및 완료하기 전에 데이터베이스. 관찰 가능성이 없으면 이러한 환경에서 문제를 진단하는 것이 어려워집니다. 추측 연습.
이 시리즈에서는 기사 12개, 우리는 다음을 통해 현대적인 관찰 가능성을 탐구할 것입니다. 오픈텔레메트리(OTel), 원격 측정 수집을 통합하는 오픈 소스 표준입니다. 우리는 기초부터 시작하여 Jaeger, Prometheus 및 Grafana를 사용하여 프로덕션급 구현까지 진행해 나갈 것입니다.
이 기사에서 배울 내용
- 모니터링과 관찰 가능성의 근본적인 차이점
- 관측 가능성의 세 가지 기둥: 측정항목, 로그, 추적
- 카디널리티의 개념과 비용에 미치는 영향
- 원격 측정 신호가 서로 관련되는 방식
- 최신 관측 가능성 도구의 환경
- OpenTelemetry가 사실상의 표준이 되고 있기 때문입니다.
모니터링과 관찰 가능성: 근본적인 차이점
Il 모니터링 사전 정의된 지표를 수집하는 확립된 관행 그리고 이를 설정된 임계값과 비교합니다. 측정항목이 임계값을 초과하면 경고가 트리거됩니다. 이 접근 방식은 오류 모드가 알려져 있고 예측 가능한 모놀리식 시스템에 적합합니다.
L'관찰 가능성그러나 이는 분산 시스템에 실패 모드가 존재한다는 가정에서 시작됩니다. 그들은 예측할 수 없습니다. 아직 모르는 문제에 대해서는 경고를 생성할 수 없습니다. 관찰 가능성 당신이 할 수 있습니다 탐구하다 실시간으로 시스템의 동작을 확인하고 질문을 던집니다. 사용 가능한 신호를 기반으로 임시.
실제 모니터링과 관찰 가능성
| 나는 기다린다 | 모니터링 | 관찰 가능성 |
|---|---|---|
| 접근하다 | 반응성(임계값 경고) | 탐색적(임시 쿼리) |
| 요청사항 | 사전 설정 및 메모 | 알 수 없고 동적임 |
| 데이터 | 측정항목 집계 | 관련 측정항목, 로그, 추적 |
| 디버깅 | "뭐가 고장났어?" | "왜 깨졌나요?" |
| 확장성 | 정적 대시보드 | 대화형 탐색 |
유용한 비유: 모니터링은 미리 정의된 조명(온도, 오일, 휘발유). 관찰 가능성은 분석을 가능하게 하는 완전한 진단 시스템을 갖는 것과 같습니다. 실시간으로 모든 엔진 매개변수를 확인해야 합니다. 심지어 당신이 몰랐던 매개변수도 확인해야 합니다.
관찰 가능성의 세 가지 기둥
관측 가능성은 세 가지 기본 유형의 원격 측정 신호를 기반으로 합니다. 세 개의 기둥: 지표, 로그 및 추적. 각각은 문제에 대해 서로 다른 관점을 제시합니다. 시스템의 동작을 파악하고 함께 완전한 보기를 제공합니다.
1. 지표: 수치 데이터 집계
Le 측정항목 시간이 지남에 따라 측정된 수치입니다. 시스템의 상태를 나타냅니다. 집계 형태로 저장 및 쿼리 측면에서 가장 효율적인 원격 분석 유형입니다. 측정항목은 다음 질문에 답합니다. "얼마나 많이?"
# Esempio: definire metriche con OpenTelemetry Python SDK
from opentelemetry import metrics
meter = metrics.get_meter("my-service")
# Counter: valori che solo aumentano
request_counter = meter.create_counter(
name="http.server.request.count",
description="Numero totale di richieste HTTP",
unit="1"
)
# Histogram: distribuzione di valori
latency_histogram = meter.create_histogram(
name="http.server.request.duration",
description="Durata delle richieste HTTP",
unit="ms"
)
# UpDownCounter: valori che possono aumentare o diminuire
active_connections = meter.create_up_down_counter(
name="http.server.active_connections",
description="Connessioni attive correnti"
)
# Registrare valori
request_counter.add(1, {"http.method": "GET", "http.route": "/api/users"})
latency_histogram.record(45.2, {"http.method": "GET", "http.status_code": "200"})
active_connections.add(1)
지표는 대시보드, 경고 및 추세 분석에 이상적입니다. 고정된 저장 비용이 있습니다. 트래픽 양과 무관하므로 장기 모니터링에 적합합니다.
2. 로그: 컨텍스트가 있는 개별 이벤트
I 로그 타임스탬프와 텍스트 또는 구조화된 페이로드가 포함된 개별 이벤트 레코드입니다. 이는 개발자에게 가장 친숙한 원격 측정 신호이며 다음 질문에 답합니다. "무슨 일이에요?"
import logging
import json
# Log strutturato con contesto di tracing
logger = logging.getLogger("order-service")
def process_order(order_id, user_id):
logger.info(json.dumps({
"event": "order.processing.started",
"order_id": order_id,
"user_id": user_id,
"timestamp": "2026-02-17T10:30:00Z",
"trace_id": "abc123def456",
"span_id": "span789",
"service": "order-service",
"environment": "production"
}))
# ... logica di business ...
logger.info(json.dumps({
"event": "order.processing.completed",
"order_id": order_id,
"duration_ms": 234,
"trace_id": "abc123def456",
"span_id": "span789"
}))
구조화된 로그(JSON)는 효율적인 쿼리를 허용하므로 텍스트 로그보다 선호됩니다.
추적 및 메트릭과의 자동 상관 관계. 핵심 패턴은 항상 다음을 포함하는 것입니다.
trace_id e span_id 로그에서 상관관계를 활성화합니다.
3. 추적: 요청 경로
Le 흔적 (분산 추적)은 요청의 전체 경로를 나타냅니다. 분산 시스템을 통해. 각 트랙은 다음과 같이 구성됩니다. 기간, 여기서 모든 범위 서비스 내의 작업을 나타냅니다. 트랙은 다음 질문에 답합니다. "어디서 일어난 일이에요?"
from opentelemetry import trace
tracer = trace.get_tracer("order-service")
def handle_order_request(request):
# Span root: rappresenta l'intera operazione
with tracer.start_as_current_span("process-order") as span:
span.set_attribute("order.id", request.order_id)
span.set_attribute("user.id", request.user_id)
# Span figlio: validazione
with tracer.start_as_current_span("validate-order") as child:
child.set_attribute("validation.rules_count", 5)
validate(request)
# Span figlio: pagamento
with tracer.start_as_current_span("process-payment") as child:
child.set_attribute("payment.method", "credit_card")
child.set_attribute("payment.amount", request.total)
charge_payment(request)
# Span figlio: notifica
with tracer.start_as_current_span("send-notification") as child:
child.set_attribute("notification.type", "email")
notify_user(request.user_id)
추적은 분산 시스템에서 디버깅하는 데 중요합니다. 그들은 당신이 볼 수 있습니다 정확히 어디서 시간이 소요되는지, 어떤 서비스에서 오류가 발생했는지, 작업이 어떻게 진행되는지 종속성 그래프를 통해 서로 관련됩니다.
신호 상관관계: 관찰 가능성의 진정한 힘
세 기둥은 다음과 같을 때 진정으로 강력해집니다. 관련된 그들 사이. 추적 ID 해당 요청 중에 생성된 로그에 추적을 연결합니다. 서비스 라벨이 있는 측정항목 추적에 나타나는 동일한 서비스에 대한 데이터를 집계할 수 있습니다. 이 상관관계 격리된 데이터를 다음으로 변환합니다. 운영 상황.
상관 신호를 사용한 디버깅 흐름
1. 측정항목별 알림: "/checkout 엔드포인트 P99 대기 시간이 2초를 초과합니다."
2. 트랙을 자세히 살펴보세요.: 대기 시간이 2초를 초과하는 엔드포인트/결제를 필터링하면 결제 게이트웨이 범위가 1.8초가 소요되는 것을 알 수 있습니다.
3. 로그 검토: Trace_id를 사용하면 결제 게이트웨이 로그에서 외부 공급자에 대한 시간 초과를 발견합니다.
4. 근본 원인: 결제 제공업체에 네트워크 문제가 있어 재시도가 발생하여 전체 지연 시간이 늘어납니다.
카르디날리타: 침묵의 적
La 카디널리티 라벨/속성이 부여하는 고유한 값 조합의 수 측정항목이 걸릴 수 있습니다. 이는 관찰 가능성에 영향을 미치기 때문에 가장 중요한 개념 중 하나입니다. 스토리지 비용, 쿼리 성능 및 시스템 확장성에 직접적인 영향을 미칩니다.
예를 들어 측정항목 http_requests_total 라벨 포함 method (4개 값),
status (5개 값) e endpoint (20개 값)은 4 x 5 x 20 = 400세트를 산출합니다.
뇌우. 하지만 추가하면 user_id 사용자 10만명으로 시리즈 4천만개로 폭발.
이 현상을 카디널리티 폭발.
카디널리티에 대한 황금률
- 절대 사용자 ID, 세션 ID 또는 요청 ID를 측정항목 라벨로 사용
- 사용 낮은 카디널리티 값: 메소드, 상태 코드, 서비스 이름, 환경
- 이동하다 추적(범위 속성) 또는 로그의 높은 카디널리티 데이터
- 감시 장치 측정항목 백엔드의 활성 시계열 수
- 한계 제한된 값을 사용하여 측정항목당 최대 5~7개의 라벨을 지정합니다.
관찰 가능성 도구 환경
관찰 가능성 도구 시장은 풍부하고 끊임없이 진화하고 있습니다. 우리는 그것들을 분류할 수 있습니다 세 가지 주요 범주로 나뉩니다.
상업용 SaaS 솔루션
다음과 같은 플랫폼 데이터독, 새로운 유물, 다이나트레이스 e 스플렁크 통합된 메트릭, 로그, 추적, 프로파일링 및 APM을 갖춘 올인원 솔루션을 제공합니다. 채택하기는 쉽지만 대량의 원격 측정으로 인해 비용이 많이 들 수 있습니다.
오픈 소스 스택
가장 일반적인 오픈 소스 스택은 다음과 같습니다. 프로메테우스 (측정항목), 저격병 o 시간 (흔적), 로키 (로그) 전자 그라파나 (보다). 최대의 제어 기능을 제공하고 라이선스 비용이 전혀 들지 않지만 배포하려면 운영 전문 지식이 필요합니다. 그리고 유지 보수.
OpenTelemetry: 통합 표준
오픈텔레메트리 관측 가능성 백엔드는 아니지만 수집기준 및 원격 측정 내보내기. 언어별 SDK, 라우팅용 콜렉터 제공 속성 이름을 표준화하기 위한 데이터 및 의미론적 규칙. Otel 및 공급업체 중립: 다음을 수행할 수 있습니다. 코드를 한 번 계측하고 호환되는 백엔드로 데이터를 보냅니다.
OpenTelemetry가 미래인 이유
OpenTelemetry는 세계에서 두 번째로 활발한 프로젝트입니다. 클라우드 네이티브 컴퓨팅 재단(CNCF) 쿠버네티스 이후. 1,000명 이상의 기여자와 모든 주요 관측 가능성 공급업체의 지원을 바탕으로 OTel은 사실상 원격 측정의 표준이 되고 있습니다. 오늘 Otel을 사용한 계측은 다음을 의미합니다. 애플리케이션 코드를 변경하지 않고도 내일 백엔드를 자유롭게 변경할 수 있습니다.
관찰 가능성에 대한 주요 지표
어떤 도구를 선택하든 모든 시스템이 갖추어야 할 주요 지표가 있습니다. 모니터. 프레임워크 빨간색 (비율, 오류, 기간) 및 서비스에 가장 많이 사용되는, 반면 프레임워크 사용 (사용률, 포화도, 오류)는 리소스에 적용됩니다. 인프라.
# Esempio: alert rules basate su RED method (Prometheus)
groups:
- name: red-alerts
rules:
# Rate: richieste al secondo
- alert: HighRequestRate
expr: rate(http_requests_total[5m]) > 1000
for: 5m
labels:
severity: warning
annotations:
summary: "Tasso di richieste elevato"
# Errors: tasso di errori
- alert: HighErrorRate
expr: |
rate(http_requests_total{status_code=~"5.."}[5m])
/ rate(http_requests_total[5m]) > 0.05
for: 2m
labels:
severity: critical
annotations:
summary: "Tasso di errori superiore al 5%"
# Duration: latenza P99
- alert: HighLatency
expr: |
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m])
) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "Latenza P99 superiore a 2 secondi"
결론 및 다음 단계
관찰가능성은 구매할 제품이 아니라 시스템 속성 그렇죠 정확한 계측 및 신호 상관 관계를 통해 구축됩니다. 세 가지 기둥(측정항목, 로그, 추적)은 함께 진단할 수 있는 세 가지 보완적인 관점을 제공합니다. 분산 시스템의 모든 문제.
효과적인 관찰의 핵심은 상관관계: 지표, 로그 및 유동적으로 탐색할 수 있도록 공유 식별자(추적 ID, 서비스 이름)를 통한 추적 경고에서 추적으로, 추적에서 관련 로그로, 또는 그 반대로.
다음 기사에서는 더 자세히 알아보겠습니다. 오픈텔레메트리, 아키텍처를 분석하고, API와 SDK의 차이점, OTLP 프로토콜 및 표준화된 의미 규칙 원격 측정 명명법.