들어가며 — 2026년 5월, 관측성은 OpenTelemetry가 기본이 됐다

2024년만 해도 "어떤 APM을 쓸까"는 벤더 선택의 문제였다. 2026년 5월 현재, 그 질문의 앞단이 통일됐다. **계측(instrumentation)은 OpenTelemetry로**, 그 뒤의 **저장·시각화·경보·근본원인 분석**만 벤더가 갈린다. CNCF에서 K8s 다음으로 활동이 많은 프로젝트가 OTel이고, OTLP(gRPC/HTTP)가 사실상 산업 표준 와이어 포맷이 됐다. Datadog, New Relic, Splunk, Dynatrace, Honeycomb, Chronosphere, Grafana Cloud, Coralogix, Logz.io — 모두 OTLP를 1급으로 받는다.

또 한 가지 큰 변화는 **AI for observability**다. 2025년 들어 Datadog Bits AI, New Relic AI(NRAI), Dynatrace Davis AI 등이 모두 자연어 root-cause 요약, 자동 이상 탐지, 인시던트 타임라인 생성을 기본 기능으로 깔았다. "왜 p99가 튀었는지" 묻는 인터페이스가 쿼리 언어에서 자연어로 옮겨가는 중이다.

이 글은 마케팅 비교가 아니다. 2026년 프로덕션에서 무엇이 어떤 자리에 들어가는지, OTel 위에서 어떻게 조립하고, SaaS와 셀프호스트 사이에서 어떻게 결정하고, SLO와 에러 버짓을 어떻게 운영하는지 정직하게 짚는다.

세 가지 기둥(three pillars) — 그리고 그 너머

전통적인 관측성의 세 기둥은 **메트릭(metrics), 로그(logs), 트레이스(traces)**다. 2026년에는 두 가지가 더 1급 시민이 됐다.

1. **Continuous profiling**: CPU/메모리 프로파일을 24시간 수집(Pyroscope, Parca, Polar Signals, Datadog Continuous Profiler).

2. **RUM(Real User Monitoring) & Synthetics**: 브라우저/모바일에서 LCP, INP, FCP, 장기 작업, 네트워크 폭포 수집.

업계는 이제 "**MELT**"(Metrics, Events, Logs, Traces) 또는 **MELT+P**(profiling 포함)라고 부르기도 한다. 세 기둥보다 더 중요한 건 **상호 연결성**이다. 메트릭에서 트레이스로, 트레이스에서 로그로, 로그에서 프로파일로 한 클릭에 점프할 수 있어야 한다. 이 "exemplar → trace → log → profile" 체인이 2026년 관측성 UX의 표준이다.

OpenTelemetry — 표준이 된 계측 레이어

OTel은 세 가지로 구성된다.

- **API/SDK**: 11개 GA 언어(Java, Go, Python, .NET, JS, Ruby, Rust, C++, PHP, Erlang, Swift) + 베타들.

- **Collector**: 수집·변환·라우팅의 도라(Pluggable). Agent 모드와 Gateway 모드.

- **Semantic Conventions**: 속성 이름의 약속(`http.request.method`, `db.system`, `k8s.pod.name` 등). 2024년 1.0 GA 이후 2026년 1.30대까지 진행.

파이썬 자동 계측 예시는 이렇게 짧다.

requirements.txt

opentelemetry-distro==0.50b0

opentelemetry-exporter-otlp==1.30.0

한 줄로 끝나는 자동 계측

$ opentelemetry-bootstrap -a install

$ OTEL_SERVICE_NAME=checkout-api \

OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 \

opentelemetry-instrument python app.py

from fastapi import FastAPI

from opentelemetry import trace

tracer = trace.get_tracer(__name__)

app = FastAPI()

@app.get("/checkout/{order_id}")

def checkout(order_id: str):

with tracer.start_as_current_span("validate_order") as span:

span.set_attribute("order.id", order_id)

비즈니스 로직

return {"ok": True, "order_id": order_id}

`opentelemetry-instrument`만 붙이면 FastAPI, requests, SQLAlchemy, psycopg, Redis, Kafka 클라이언트 등 50개 이상의 라이브러리가 자동으로 트레이싱 및 메트릭이 붙는다. **수동 계측은 비즈니스 도메인 스팬에만** 사용한다.

OTel Collector — 파이프라인의 심장

Collector는 receivers → processors → exporters 파이프라인을 YAML로 선언한다. 2026년 표준 배치는 "agent + gateway" 이중 레이어다.

otel-collector-gateway.yaml

receivers:

otlp:

protocols:

grpc:

endpoint: 0.0.0.0:4317

http:

endpoint: 0.0.0.0:4318

processors:

batch:

send_batch_size: 8192

timeout: 5s

memory_limiter:

check_interval: 1s

limit_percentage: 80

spike_limit_percentage: 25

resourcedetection:

detectors: [env, system, eks, gcp]

tail_sampling:

decision_wait: 30s

policies:

- name: errors-policy

type: status_code

status_code: {status_codes: [ERROR]}

- name: slow-policy

type: latency

latency: {threshold_ms: 500}

- name: baseline-policy

type: probabilistic

probabilistic: {sampling_percentage: 5}

exporters:

otlp/datadog:

endpoint: api.datadoghq.com:443

headers: {dd-api-key: "$DD_API_KEY"}

otlphttp/grafana:

endpoint: https://otlp-gateway.grafana.net/otlp

prometheus:

endpoint: 0.0.0.0:9464

service:

pipelines:

traces:

receivers: [otlp]

processors: [memory_limiter, resourcedetection, tail_sampling, batch]

exporters: [otlp/datadog, otlphttp/grafana]

metrics:

receivers: [otlp]

processors: [memory_limiter, resourcedetection, batch]

exporters: [prometheus, otlphttp/grafana]

핵심은 **tail sampling**이다. 에러 트레이스와 느린 트레이스는 100% 보존하고, 나머지는 5% 정도만 샘플링해서 비용을 잡는다. Datadog Trace API가 헤드 샘플링 위주라면, OTel Collector는 게이트웨이에서 tail decision을 내릴 수 있어 자유도가 높다.

메트릭 — Prometheus와 그 너머

Prometheus는 2026년에도 메트릭 표준이다. PromQL이 산업 공용어이고 OTel Collector → Prometheus Remote Write도 GA. 다만 단일 Prometheus는 카디널리티와 보존 기간 한계가 명확해서, 보통은 **장기 저장 백엔드**와 짝지어 쓴다.

- **Grafana Mimir**(전 Cortex): 멀티테넌트, S3 백엔드, PromQL/MQL 호환, Grafana Labs OSS.

- **Thanos**: sidecar + global query + S3, 커뮤니티 표준.

- **Cortex**: Mimir로 갈라지기 전 원조, 현재도 유지보수.

- **VictoriaMetrics**: 고밀도 압축과 단일 바이너리 배포로 강력. 2026년 OSS 모멘텀 강함.

- **Chronosphere**: 카디널리티 컨트롤이 핵심 가치 제안. M3DB 출신 팀.

전형적인 PromQL 레코딩 룰은 다음과 같다(SLI 기준 5xx 비율).

recording-rules.yaml

groups:

- name: checkout-sli

interval: 30s

rules:

- record: job:http_request_errors:ratio_5m

expr: |

sum(rate(http_server_request_duration_seconds_count{job="checkout-api",http_response_status_code=~"5.."}[5m]))

/

sum(rate(http_server_request_duration_seconds_count{job="checkout-api"}[5m]))

- record: job:http_request_latency:p99_5m

expr: |

histogram_quantile(0.99,

sum by (le) (rate(http_server_request_duration_seconds_bucket{job="checkout-api"}[5m]))

)

- alert: HighErrorRate

expr: job:http_request_errors:ratio_5m > 0.01

for: 10m

labels: {severity: page, service: checkout}

annotations:

summary: "checkout 5xx > 1% for 10m"

`histogram_quantile`과 OTel histogram 호환은 2025년 중반에 native histogram(exponential)으로 통일됐다. 이전 le-bucket 방식보다 메모리 5-10배 적게 쓰고 정확도는 높다.

카디널리티 위기와 비용 관리

OTel Collector에서 미사용 메트릭과 라벨을 드롭하는 transform processor 예시:

카디널리티 드롭 룰

processors:

transform/metrics:

metric_statements:

- context: datapoint

statements:

- delete_key(attributes, "request_id")

- delete_key(attributes, "build_sha")

- context: metric

statements:

- drop() where name == "unused_metric_legacy"

filter/spans:

spans:

exclude:

match_type: regexp

attributes:

- key: http.url

value: "/healthz|/metrics|/readyz"

2024년부터 산업 전반의 골치는 **카디널리티 폭증**이다. user_id, request_id, build_sha 같은 라벨을 무심코 붙이면 시계열이 백만 단위로 폭발한다. Datadog, Splunk Observability, New Relic 모두 "custom metric"당 단가가 붙어서 청구서가 분기마다 두 배가 되는 사고가 흔하다.

2026년 모범 답안은 세 갈래다.

1. **고카디널리티는 트레이스/로그로**: 메트릭 라벨로 박지 말고 이벤트 속성으로 저장(Honeycomb 철학).

2. **Adaptive sampling + drop rules**: OTel Collector의 `transformprocessor`나 Datadog의 metric pipelines로 미사용 라벨 자동 드롭.

3. **Cardinality 컨트롤 SaaS**: Chronosphere Control Plane, Grafana Adaptive Metrics, Cribl Stream이 미사용 시리즈를 식별해 자동 제거.

Honeycomb의 Charity Majors가 2017년부터 외친 "wide, structured events"가 2026년 실제 표준이 됐다. 메트릭은 SLI/SLA용 카운터·게이지만, 차원이 많은 데이터는 events/traces로 흘려보낸다.

Datadog — 통합 SaaS의 절대 강자

Datadog은 2026년 매출 30억 달러+, 800개 이상의 통합을 가진 사실상의 카테고리 정의자다. APM, Logs, RUM, Synthetic, Continuous Profiler, Database Monitoring, Network Performance Monitoring, CWPP/CNAPP까지 한 콘솔에서 본다. 2025년 Bits AI가 자연어로 트레이스 분석, 인시던트 요약, IaC 코드 생성을 지원한다.

장점은 명확하다.

- 통합 천국. Kubernetes, Lambda, Postgres, Kafka, Stripe 모두 1-클릭.

- 강력한 UI/UX와 빠른 쿼리. p99도 인덱스 친화적.

- AI/ML 자동 이상 탐지(Watchdog)가 진짜 잘 작동한다.

- LLM Observability(2025년 GA): 프롬프트, 토큰, 모델별 비용 집계.

단점도 명확하다.

- **비싸다**. 호스트당 월 23-40달러 + 인덱싱 로그당 + 커스텀 메트릭 + RUM 세션. 분기마다 청구서 시뮬레이션을 안 하면 큰일 난다.

- 락인. DD agent + DogStatsD에서 OTel로 갈아타면 1-2분기 작업.

Grafana Stack — OSS 진영의 LGTM+Beyla

Grafana Labs는 Loki(로그) + Mimir(메트릭) + Tempo(트레이스) + Pyroscope(프로파일) + Beyla(eBPF 자동계측)로 풀스택을 갖췄다. Apache 2.0 + AGPL 라이선스(에디션별)로 셀프호스팅도, Grafana Cloud SaaS도 가능.

Loki의 LogQL은 PromQL과 닮은 직관적 쿼리.

Loki LogQL — 최근 5분 checkout 5xx 추세

{service_name="checkout-api"} |= "ERROR"

| json

| http_response_status_code >= 500

| rate(5m)

Tempo TraceQL — p99 1초 초과한 checkout 트레이스

{ resource.service.name = "checkout-api" && duration > 1s && status = error }

Mimir PromQL — node CPU 사용률

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Tempo TraceQL은 2024년 GA 후 2026년에 가장 표현력 좋은 트레이스 쿼리 언어로 평가받는다. 스팬 속성, 리소스 속성, 자식 스팬 조건을 한 쿼리에 표현 가능하다.

**Beyla**는 2024년 출시된 zero-instrumentation eBPF 자동 계측기다. 코드 한 줄 안 바꾸고 HTTP/gRPC 스팬과 RED 메트릭을 추출한다. Go, Java, Python, Node.js, Rust 모두 지원. 2026년 Beyla 1.10대에서 mTLS 트래픽도 디코딩한다.

Honeycomb — wide events와 BubbleUp의 철학

Honeycomb은 2016년 Charity Majors와 Christine Yen이 Facebook Scuba에서 영감 받아 시작했다. **"수십~수백 개 차원의 wide event"**가 기본 단위이고, 모든 쿼리는 ad-hoc으로 모든 차원을 즉시 그룹/필터할 수 있다. 카디널리티 제한이 없는 것이 특징.

- **BubbleUp**: "이 이상한 슬로우 트레이스 군집과 정상 군집의 차이"를 자동으로 차원별 비교해서 보여준다. 2026년에 가장 모방되는 UX 패턴.

- **SLOs**: 에러 버짓을 1급 시민으로 다룬다. burn rate 알람이 단순한 임계값보다 똑똑하다.

- **OpenTelemetry-native**: 처음부터 OTLP 친화적. 2024년 Refinery(샘플링 게이트웨이)도 오픈소스화.

가격은 이벤트 수 기반이고 Datadog 대비 저렴한 편이지만, 메트릭과 로그를 따로 처리하려면 추가 비용이 든다. 2026년 Datadog/New Relic 대안으로 "디버깅과 SLO에 진심인 팀"이 선호한다.

Jaeger / Tempo / Zipkin — 분산 트레이싱 3대장

OSS 트레이스 백엔드는 세 가지로 정리된다.

- **Jaeger**: Uber 출신, CNCF Graduated. 2024년 v2가 OTel Collector 위에서 동작하는 디스트로로 재출발. ClickHouse, Cassandra, Elasticsearch 스토리지 지원.

- **Tempo**: Grafana Labs, 객체 스토리지 친화. 인덱스를 최소화하고 트레이스 ID로만 검색하는 설계로 비용 효율 높음. TraceQL이 강점.

- **Zipkin**: Twitter 출신, 2012년부터 운영. 단순함이 장점. 신규 채택보다 레거시 호환.

Jaeger v2 + Tempo + OTel Collector 조합이 2026년 셀프호스트 표준이다. ClickHouse를 트레이스 백엔드로 직접 쓰는 회사(Uber, Cloudflare)도 늘었다.

eBPF Observability — 코드 변경 없는 관측

eBPF가 관측 도구 카테고리를 새로 만들었다. 커널에서 직접 syscall/네트워크/CPU 이벤트를 가로채서 코드 변경 없이 RED 메트릭, 분산 트레이스, 프로파일을 추출한다.

- **Pixie**(New Relic 인수): K8s 클러스터에 DaemonSet 하나 깔면 HTTP/gRPC/DNS/MySQL 트래픽이 자동으로 수집된다. PxL 스크립트 언어.

- **Cilium Tetragon**: 보안·관측 통합. syscall + 정책 + 트레이스를 한 데이터 모델로.

- **Grafana Beyla**: 위에서 본 자동 계측기. Cilium Hubble과도 연동.

- **Parca**: 클러스터 전체 continuous profiling. CPU 프로파일을 pprof로 항상 수집.

- **Coroot**: SaaS·OSS 듀얼. eBPF 기반 service map + SLO 자동 생성.

- **Polar Signals**: Parca 기반 SaaS. continuous profiling 카테고리의 New Relic.

eBPF의 약점은 **Go 등 사용자 공간 런타임에서 매개변수 추출이 한정적**이라는 것. 그래서 비즈니스 로직 스팬은 여전히 OTel SDK가 필요하다. 2026년 표준은 "eBPF로 RED + 골든 시그널, OTel SDK로 도메인 스팬" 분업이다.

Prometheus 운영의 현실 — Mimir vs Thanos vs Cortex vs VictoriaMetrics

장기 저장 백엔드 선택은 2026년에도 끝나지 않은 논쟁이다.

| 항목 | Mimir | Thanos | Cortex | VictoriaMetrics |

| --- | --- | --- | --- | --- |

| 라이선스 | AGPL v3 | Apache 2.0 | Apache 2.0 | Apache 2.0 |

| 멀티테넌시 | 강함 | 보통 | 강함 | 강함 |

| 압축 효율 | 좋음 | 좋음 | 좋음 | 매우 좋음 |

| 단일 바이너리 | X | X | X | O |

| 운영 복잡도 | 높음 | 중간 | 높음 | 낮음 |

| 상용 지원 | Grafana | 커뮤니티 | 커뮤니티 | VictoriaMetrics |

| 카디널리티 한계 | 1억+ | 5천만 | 1억+ | 5억+ |

대형 SRE 팀이라면 Mimir, 운영 인력이 적으면 VictoriaMetrics, 이미 Thanos 운영 중이면 굳이 옮길 이유는 없다.

Continuous Profiling — Pyroscope, Parca, Polar Signals

Continuous profiling은 2024-2025년에 카테고리로 굳어졌다. CPU/메모리/락 프로파일을 24시간 수집해서 회귀를 잡고 비용을 최적화한다.

- **Pyroscope**(Grafana Labs 인수): Go, Python, Java, Ruby, Node.js 지원. flame graph 비교 UX가 강점.

- **Parca**: Polar Signals OSS. eBPF 기반으로 어떤 언어든 zero-config 프로파일.

- **Polar Signals**: Parca SaaS 버전. 클러스터 전체 비용 절감 분석.

- **Datadog Continuous Profiler**: 1년 이상 production-grade. ASP.NET, JVM, Go, Python 지원.

- **AWS CodeGuru Profiler**: Java/Python 한정. AWS native.

회사들이 가장 자주 발견하는 이슈는 (1) JSON 직렬화 핫스팟, (2) 정규식 컴파일 누락, (3) Go GC GOGC 미튜닝, (4) Python GIL contention이다.

RUM과 Synthetic — 사용자 관점의 관측

서버 메트릭만 봐서는 "왜 사용자가 느리다고 하는지"를 모른다. **RUM(Real User Monitoring)** 과 **Synthetic monitoring**이 그 갭을 메운다.

- **Datadog RUM**: 자동 세션 재생, INP/LCP/CLS 수집, OTel RUM 호환.

- **New Relic Browser**: APM과 통합. distributed trace를 브라우저까지.

- **Sentry**(원래 에러 추적 → 관측): JS·모바일 RUM, replay, performance.

- **Grafana Faro**(2024년 GA): OSS RUM SDK + Loki/Tempo로 자체 호스팅.

- **SpeedCurve, Calibre**: Core Web Vitals 전문 SaaS.

- **Synthetic**: Catchpoint, Checkly, Datadog Synthetic, k6 Cloud(Grafana). Checkly가 Playwright 기반으로 가장 빠른 신규 채택.

2025년 Google이 INP를 LCP·CLS와 함께 Core Web Vitals 1급으로 승격하면서, RUM에서 long task와 input delay 측정이 필수가 됐다.

SLO와 에러 버짓 — Google SRE의 유산

SLO(Service Level Objective)는 2018년 Google SRE 책 출간 이후 업계 공용어가 됐다. 2026년에는 SLO 전용 도구 카테고리도 굳어졌다.

- **Nobl9**: 멀티 데이터 소스(Datadog, Prometheus, NR) SLO 통합. 2025년 BSD 기반 OSS 코어 공개.

- **Datadog SLO**: 네이티브 통합, burn rate 알림 자동.

- **Grafana Cloud SLO**: Mimir/Loki/Tempo 위에서 동작.

- **OpenSLO**: 스펙. YAML로 SLO를 선언적으로 정의해 도구 사이를 옮긴다.

- **Sloth**: PromQL SLO 룰 생성기. Prometheus 자체에서 SLO 운영.

전형적인 SLO 정의:

slo.yaml — Sloth 형식

version: prometheus/v1

service: checkout-api

slos:

- name: availability

objective: 99.9

description: "checkout 5xx 비율 0.1% 이하"

sli:

events:

error_query: sum(rate(http_server_request_duration_seconds_count{job="checkout-api",http_response_status_code=~"5.."}[{{.window}}]))

total_query: sum(rate(http_server_request_duration_seconds_count{job="checkout-api"}[{{.window}}]))

alerting:

page_alert:

labels: {severity: page}

ticket_alert:

labels: {severity: ticket}

99.9% SLO는 월간 43.2분 다운타임 예산이다. 이 예산을 **burn rate**로 추적하면 단순 임계값 알림보다 훨씬 똑똑하다. 5분 윈도에서 14.4배 burn(예산 1시간이면 1년 다 쓰는 속도)이면 즉시 페이지, 6시간 윈도에서 6배면 티켓.

RED, USE, LETS, Golden Signals — 메서드 정리

관측 메트릭 선정의 방법론은 네 가지로 정리된다.

- **RED**(Tom Wilkie): **R**ate · **E**rrors · **D**uration. 요청-응답 서비스 표준.

- **USE**(Brendan Gregg): **U**tilization · **S**aturation · **E**rrors. 시스템 리소스 표준.

- **LETS**(Tammy Bryant): **L**atency · **E**rrors · **T**raffic · **S**aturation. Honeycomb 변형.

- **Google Four Golden Signals**: Latency · Traffic · Errors · Saturation. SRE 책 표준.

실무에서는 "사용자가 영향받는 표면(API, 페이지) = RED + Saturation"과 "인프라 리소스(노드, DB, 큐) = USE"를 함께 본다.

분산 트레이싱 컨텍스트 전파 — W3C TraceContext + Baggage

분산 트레이싱이 작동하려면 모든 서비스 hop마다 trace ID/span ID/sampling decision이 전파돼야 한다. 2026년 표준은 **W3C TraceContext + W3C Baggage**다.

- `traceparent` 헤더: 00 dash trace-id dash parent-id dash flags

- `tracestate` 헤더: 벤더 확장

- `baggage` 헤더: 사용자 정의 컨텍스트(user_id, tenant_id 등)

OTel SDK는 기본 propagator로 이걸 자동 처리하지만, gRPC metadata, Kafka 메시지 헤더, Lambda 컨텍스트 등 비HTTP 경로에서는 명시 인스트루멘테이션이 필요하다.

ClickHouse를 트레이스 백엔드로 쓸 때의 전형적 쿼리:

-- 최근 1시간 p99 트레이스 검색

SELECT

TraceId,

SpanName,

Duration / 1e6 AS duration_ms,

SpanAttributes['http.url'] AS url,

ResourceAttributes['service.name'] AS service

FROM otel_traces

WHERE Timestamp > now() - INTERVAL 1 HOUR

AND ResourceAttributes['service.name'] = 'checkout-api'

AND StatusCode = 'STATUS_CODE_ERROR'

ORDER BY duration_ms DESC

LIMIT 50;

로그 파이프라인 — Vector, Fluent Bit, Logstash, Elastic, Splunk

로그는 메트릭/트레이스보다 비싸고 까다롭다. 2026년 표준은 collector 단에서 정제·드롭·필드 추출을 하고 cold storage 분리.

- **Vector**(Datadog OSS): Rust 기반, 처리량과 메모리가 최고. VRL 변환 언어.

- **Fluent Bit**: CNCF Graduated. 경량 K8s 사이드카 표준. Lua/Wasm 필터.

- **Fluentd**: Fluent Bit 부모. 노드 에이전트로 여전히 많이 쓰임.

- **Logstash**: Elastic 진영의 ETL. 무거우나 grok 패턴이 풍부.

- **OTel Collector**: 로그 receiver/exporter도 GA. 메트릭·트레이스와 한 파이프라인.

스토리지 백엔드는 세 갈래다.

- **Elasticsearch / OpenSearch**: 전문 검색·집계가 강함. Elastic Observability는 완성도 높음.

- **Loki**: 라벨 인덱스만, 본문은 압축 청크. 비용 효율 최고. 풀텍스트 검색은 약함.

- **ClickHouse**: 컬럼 스토어. Cloudflare, Uber, Discord가 자체 구축. 비용/속도 모두 우수, 운영 부담.

- **Splunk**: 전통의 강자, 검색 언어(SPL)가 강력. 비용은 가장 비싸기로 유명.

인시던트 관리 — Alertmanager · PagerDuty · Opsgenie · Incident.io · FireHydrant · Squadcast

경보가 울리고 나서가 진짜 시작이다. 2026년 인시던트 관리 라인업.

- **PagerDuty**: 2009년부터의 카테고리 정의자. 2024년 PagerDuty Operations Cloud로 리브랜드.

- **Opsgenie**(Atlassian): Jira·Confluence·Statuspage 통합 강점. 2026년 들어 신규 채택은 줄고 PagerDuty/Incident.io로 이동.

- **Incident.io**: 2021년 영국 스타트업, Slack 네이티브 인시던트 관리. 2024년 on-call 추가하면서 PagerDuty 대체 자리매김.

- **FireHydrant**: 미국 발 인시던트 관리·러닝북. Slack 워크플로 자동화 강점.

- **Squadcast**: 인도/SF 발, 가성비 좋은 on-call + 인시던트.

- **Rootly**: Slack 네이티브, status page 통합.

- **Grafana OnCall**(2023 GA, Apache 2.0): OSS 대안. PagerDuty 가져가지 않으려는 팀.

- **Alertmanager**: Prometheus 진영 표준. routing/grouping/silencing.

Alertmanager 라우팅의 전형적 구성:

alertmanager.yml — severity별 라우팅

route:

receiver: default

group_by: [alertname, service]

group_wait: 30s

group_interval: 5m

repeat_interval: 4h

routes:

- matchers: [severity="page"]

receiver: pagerduty-critical

continue: true

- matchers: [severity="ticket"]

receiver: jira-ops

- matchers: [service="checkout"]

receiver: slack-checkout

receivers:

- name: pagerduty-critical

pagerduty_configs:

- service_key: '$PAGERDUTY_KEY'

- name: slack-checkout

slack_configs:

- api_url: '$SLACK_WEBHOOK'

channel: '#checkout-alerts'

Slack 기반 ChatOps는 2026년 모든 도구의 기본이다. 인시던트 채널 자동 생성, 역할(IC, comms, scribe) 자동 할당, postmortem 템플릿 생성까지 한다.

AI for Observability — Bits AI, Davis AI, NRAI

2025년 모든 메이저 SaaS가 LLM 기반 어시스턴트를 출시했다.

- **Datadog Bits AI**: 자연어로 트레이스/로그 분석, 인시던트 요약, IaC 코드 생성, runbook 자동화.

- **New Relic AI(NRAI)**: 쿼리 생성, 이상 탐지 설명, 에러 클러스터링.

- **Dynatrace Davis AI**: 인과 분석 엔진(2017년부터). 2025년 LLM 결합한 Davis CoPilot.

- **Honeycomb Query Assistant**: 자연어 → BubbleUp 쿼리.

- **Grafana ML / LLM**: 이상 탐지, 자연어 대시보드 생성.

- **Splunk AI Assistant for SPL**: 자연어 → SPL 변환.

현실적 평가는 "예측은 부풀려졌고, 검색·요약은 진짜 시간을 아낀다"다. RCA(root cause analysis)는 아직 사람이 한다.

한국 적용 — PinPoint, Naver D2, Toss, 카카오

한국 관측 생태계는 OSS 기여 측면에서 의외로 강하다.

- **Naver PinPoint**(2015년 오픈소스): 자바 APM, Apache 2.0. Java/PHP/Python/Go 에이전트. 2026년에도 활발히 유지보수.

- **Naver D2 metrics 문화**: 검색·라인 시절부터의 메트릭 운영 노하우. ELK 기반 로그 분석 가이드 공개.

- **Toss SRE**: 자체 OTel + Grafana Stack + Pyroscope. Toss 공식 블로그에 운영 사례 다수.

- **카카오**: 자체 모니터링 KAMS → Datadog·Grafana 하이브리드. tech.kakao.com에 트레이스·메트릭 글 다수.

- **NHN**: 클라우드(NHN Cloud)에 자체 모니터링 Watch 서비스. PinPoint 호환.

- **쿠팡**: Datadog 대형 고객. 한국 최대 규모 사용 사례 중 하나.

- **당근**: Datadog + Sentry. 모바일 RUM 중심.

PinPoint는 자바 진영에서 "agent 부착 형 OSS APM"으로 여전히 압도적이고, MSA 트랜잭션 시각화가 강점이다.

일본 적용 — LINE Promgen, Mercari Datadog, GREE Elastic

일본 인터넷 기업의 관측 스택도 깊다.

- **LINE Promgen / Promscale**: LINE 자체 Prometheus 운영 자동화 도구. 2018년 오픈소스. 수만 타깃 관리.

- **Mercari**: 2017년부터 Datadog 대형 고객. SRE 블로그에 KPI 운영, Bits AI 도입기 다수.

- **GREE**: 게임 인프라에서 Elastic Stack(ELK + APM) 운영.

- **DeNA**: AWS + Datadog + 자체 모니터링. Pococha 등 실시간 서비스 관측 노하우 공유.

- **CyberAgent / AbemaTV**: Datadog + New Relic 병행. AbemaTV는 라이브 스트리밍 관측 사례 공개.

- **Rakuten**: 다목적 마이크로서비스 → 자체 모니터링 + New Relic + Datadog 혼합.

- **SmartHR / freee**: 신흥 SaaS, Datadog + Sentry 표준.

LINE Engineering 블로그와 Mercari Engineering 블로그가 일본어 관측 자료의 1차 출처다.

SaaS vs 셀프호스트 결정 가이드

이 질문에 정답은 없지만 패턴은 있다.

- **연간 관측 청구서가 100만 달러 미만**: SaaS가 압도적으로 싸다. 인력·기회비용 포함하면 셀프호스트는 보통 손해.

- **연간 청구서가 100만-500만 달러**: 손익분기점. 보통 SaaS + 일부 셀프호스트(로그 cold tier).

- **연간 청구서가 500만 달러 이상**: 셀프호스트가 정당화된다. ClickHouse + Tempo + Mimir + Pyroscope + Beyla 풀스택을 갖춘 팀이 늘고 있다.

또한 **데이터 주권**(EU GDPR, 한국 클라우드 보안 인증) 요구가 강하면 셀프호스트가 강제되기도 한다.

비용 컨트롤 체크리스트

청구서 폭증 사고를 피하려면 다음 7개를 체크한다.

1. **High-cardinality 라벨 금지**: user_id, request_id를 메트릭 라벨에 넣지 마라.

2. **Adaptive sampling**: 에러는 100%, 정상은 1-5%.

3. **Log tiering**: hot 7-14일, warm 30-90일, cold 1년+. S3 Glacier 활용.

4. **Drop rules**: OTel Collector나 Cribl에서 미사용 시리즈/로그 자동 드롭.

5. **TTL 명시**: 모든 데이터 타입에 보존 기간 정책.

6. **분기 청구서 시뮬레이션**: 트래픽 2배 가정 비용 계산.

7. **카디널리티 알람**: 새 라벨이 추가될 때 자동 알람.

2026년 관측 트렌드 5선

1. **OTel-default**: 신규 프로젝트는 처음부터 OTel SDK로 시작.

2. **eBPF zero-instrumentation**: Beyla, Pixie가 자바·Go·Python의 RED 메트릭을 코드 변경 없이.

3. **AI 어시스턴트의 일상화**: 자연어 → 쿼리, 인시던트 요약, runbook 생성.

4. **카디널리티 SaaS의 부상**: Chronosphere, Adaptive Metrics, Cribl의 가치 제안 명확화.

5. **OpenTelemetry Logs GA**: 메트릭·트레이스에 이어 로그 시그널 1.0 안정화. 단일 SDK로 세 시그널 모두.

References

- [OpenTelemetry 공식](https://opentelemetry.io/) — 표준 사양, SDK, Collector

- [Datadog](https://www.datadoghq.com/) — 통합 SaaS APM

- [Grafana](https://grafana.com/) — Loki/Mimir/Tempo/Pyroscope/Beyla

- [Honeycomb](https://www.honeycomb.io/) — wide events 관측

- [New Relic](https://newrelic.com/) — APM + Pixie + NRAI

- [Dynatrace](https://www.dynatrace.com/) — Davis AI, OneAgent

- [Splunk](https://www.splunk.com/) — Splunk Observability Cloud

- [Prometheus](https://prometheus.io/) — 메트릭 표준

- [Jaeger](https://www.jaegertracing.io/) — 분산 트레이싱 OSS

- [Google SRE Book](https://sre.google/) — SLO/SLI 표준 교과서

- [Google SRE — Embracing Risk](https://sre.google/sre-book/embracing-risk/) — 에러 버짓 원전

- [OpenTelemetry Community](https://github.com/open-telemetry/community) — 거버넌스

- [Chronosphere](https://chronosphere.io/) — 카디널리티 컨트롤

- [Coralogix](https://coralogix.com/) — 로그 분석 SaaS

- [Sentry](https://sentry.io/) — 에러 추적 + 성능