Elasticsearch 입문 34편 — Observability (APM·Logs·Metrics·Uptime·SLO·OpenTelemetry)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 34편이에요. 33편이 Kibana·ELK 스택으로 로그 한 화면 통합 자리를 잡았다면, 34편 Observability 는 그 위에 APM 트레이스·메트릭·Uptime·SLO 까지 한 통에 묶어 서비스가 지금 건강한지 한 페이지에서 보는 단계예요. 30편(Monitoring) 이 ES 클러스터 자체의 건강 을 봤다면, 34편은 ES 위에 얹은 우리 서비스의 건강 을 보는 자리.

Elastic Observability 가 무엇인가

운영자가 새벽 3시에 "결제 API 가 갑자기 7초 응답" 알람을 받았다고 칩시다. 예전이라면 — 로그 서버 에 들어가 grep, Datadog 에 들어가 메트릭, Jaeger 에 들어가 트레이스, Pingdom 에 들어가 외부 모니터링, PagerDuty 에서 알람 — 다섯 곳을 오가며 어디가 진짜 문제인지 짜맞춰야 했어요. 이걸 한 화면으로 끝내자는 게 Observability 의 본 의미예요.

Elastic Observability 는 ES + Kibana 위에 얹는 통합 관측 솔루션 이에요. 로그 는 33편에서 본 ELK 스택을 그대로 쓰고, 그 위에 APM (애플리케이션 성능 모니터링) · Metrics · Uptime · Synthetic · SLO · Profiling 을 한 클러스터·한 UI 로 묶어요. 모든 데이터가 같은 ES 인덱스에 들어가니, 로그·메트릭·트레이스·이벤트 를 한 쿼리로 가로질러 볼 수 있다는 점이 가장 큰 차별점이에요.

작성 시점(2026-05-19) 기준 안정 메이저는 Elastic Observability 8.x 이고, Elastic Cloud · 자체 운영 · Serverless 세 가지 배포 모드 모두 지원해요. 이 글은 8.x 기준.

3 pillar — Logs·Metrics·Traces

Observability 표준 분류는 세 기둥(three pillars) 이에요. 시리즈 7(Grafana) 에서도 같은 그림이 나왔는데, 도구가 바뀌어도 그림은 똑같아요.

Logs — 언제 무슨 일이 있었는지 를 텍스트 한 줄로 남기는 데이터예요. JSON·텍스트 모두 가능하고, 33편 ELK 스택의 본업. 낮은 카디널리티 + 풍부한 메타 가 특징.

Metrics — 지금 이 순간 숫자 를 시계열로 쌓는 데이터예요. CPU 70%, QPS 1,200, 응답 시간 p99 = 850ms 같은 자리. 높은 카디널리티 + 낮은 메타 가 특징.

Traces — 한 요청이 마이크로서비스 5개를 어떤 순서로 거쳤는지 그림을 남기는 데이터예요. 분산 트레이싱 표준이고, APM 의 본업. 요청 단위 + 시간 흐름 이 특징.

Grafana 스택은 이 세 기둥에 Loki(로그) · Prometheus(메트릭) · Tempo(트레이스) 세 도구를 따로 두는 오케스트라형. Elastic 스택은 한 ES 클러스터에 다 담는 단일 저장소형. 운영 측면에서 데이터 가로지르기 (correlation) 는 단일 저장소형이 압도적으로 쉽고, 각 도구를 따로 진화시키기 는 오케스트라형이 더 유연해요. 한국 회사 신규 환경에서 AWS OpenSearch + Grafana 조합이 자주 나오는 이유도 각자 강점을 섞고 싶어서 예요.

Elastic APM — 코드 한 줄로 분산 트레이싱

Elastic APM (Application Performance Monitoring) 은 코드에 에이전트 한 줄 만 박아 두면 모든 HTTP 요청 · DB 쿼리 · 외부 API 호출 · 메서드 단위 latency 를 자동 수집해서 ES 에 보내는 솔루션이에요.

구성요소는 세 갈래.

APM Agent — 각 언어용 라이브러리. Java·Python·Node.js·Go·Ruby·PHP·.NET·iOS·Android·RUM(브라우저) 까지 8.x 기준 10개 이상.

APM Server — 에이전트가 보낸 데이터를 받아 ES 에 색인하는 게이트웨이. 8.x 부터는 APM Server 가 Elastic Agent 의 한 integration 으로 통합돼서 Fleet 으로 관리해요.

Kibana APM UI — 서비스 맵·트랜잭션 워터폴·에러 그룹·성능 분석 화면 묶음.

Java Spring Boot 에 박는 예시는 거의 의존성 한 줄 + JVM 옵션 한 줄.

<!-- Maven pom.xml -->
<dependency>
  <groupId>co.elastic.apm</groupId>
  <artifactId>elastic-apm-agent</artifactId>
  <version>1.50.0</version>
</dependency>

# JVM 시작 시
java -javaagent:/path/to/elastic-apm-agent.jar \
     -Delastic.apm.service_name=order-service \
     -Delastic.apm.server_urls=http://apm-server:8200 \
     -Delastic.apm.environment=production \
     -Delastic.apm.application_packages=com.example \
     -jar order-service.jar

이 정도만 박아 두면 Spring Web · JPA · RestTemplate · WebClient · Kafka · Redis · Elasticsearch Client 같은 흔한 라이브러리는 자동 계측돼서, POST /orders → JPA save → Kafka publish → Redis cache invalidate 의 한 요청 워터폴이 그대로 보여요.

분산 트레이싱 (Distributed Tracing) — 마이크로서비스 5개가 주문 → 결제 → 재고 → 알림 → 로그 순으로 호출됐을 때, traceparent HTTP 헤더로 Trace ID 를 전파시켜 한 그림을 그려요. Elastic APM 은 W3C Trace Context 표준을 따라서, 서비스 A 는 Elastic APM Java, 서비스 B 는 OTel Python 으로 섞여도 한 트레이스가 이어져요.

Error Tracking — uncaught exception · 명시적 captureException(e) 호출 · log4j ERROR 로그를 자동 묶어 Error Group 을 만들어 줘요. 지난 24시간 동안 가장 많이 터진 에러 top 10 한 화면이 운영 첫 진입점.

Service Map — 서비스 간 호출 그래프를 자동 그려 줘요. 새로 합류한 개발자가 우리 시스템이 몇 개의 서비스로 어떻게 묶여 있는지 한 페이지로 보기에 가장 좋은 화면.

Elastic Logs — Filebeat·ECS·Logs UI

33편에서 ELK 스택 골격을 잡았다면, 34편 Logs 는 그 위에 Observability 일관 스키마 를 입히는 단계예요. 가장 중요한 단어가 ECS (Elastic Common Schema).

ECS = 모든 관측 데이터의 필드 이름·타입을 통일 한 스키마. 서비스 A 는 client_ip, 서비스 B 는 clientIP, 서비스 C 는 src.ip 처럼 제각각이면 한 쿼리로 가로지르기 가 망가져요. ECS 는 이걸 source.ip · host.name · service.name · event.dataset · log.level · trace.id 같은 250+ 필드로 통일해요.

ECS 의존이 강한 이유 — Logs UI · APM UI · Metrics UI · Security · SLO 가 같은 ECS 필드 이름 을 기대해요. 그래서 신규 서비스를 붙일 때 로그 JSON 을 ECS 형태로 찍거나 (가장 깔끔), Logstash·Ingest Pipeline 에서 ECS 로 변환 (현실적 타협) 둘 중 하나를 골라야 해요.

수집 도구 표준 셋업.

# filebeat.yml
filebeat.inputs:
  - type: filestream
    id: app-logs
    paths:
      - /var/log/app/*.json
    parsers:
      - ndjson:
          target: ""
          overwrite_keys: true

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_kubernetes_metadata: ~

output.elasticsearch:
  hosts: ["es:9200"]
  index: "logs-app-default"

setup.template.enabled: false
setup.ilm.enabled: false

Logs UI (Kibana → Observability → Logs) — tail -f 처럼 실시간 로그가 흐르는 Stream 화면, Anomalies (ML 기반 이상 탐지) 화면, Categories (비슷한 로그 그룹화) 화면 세 가지가 표준. trace.id 가 박힌 로그는 APM 워터폴에서 해당 트레이스의 로그만 따로 보기 가 한 클릭에 돼요.

Categories 가 흥미로워요 — 수만 줄 로그 를 비슷한 패턴 으로 자동 묶어, 지난 1시간 동안 새로 나타난 로그 카테고리 같은 알 수 없는 미지의 사고 신호를 잡아내요. Elastic ML 이 백그라운드에서 도는 자리.

Elastic Metrics — Metricbeat·host·service 단위

Metrics 화면은 host · container · pod · service · cluster 다섯 레이어를 Inventory 라는 한 화면에서 격자로 보여 줘요. 색깔이 CPU · memory · network · 우리가 지정한 metric 어느 기준으로든 칠해질 수 있어서, 지금 우리 인프라에서 어느 노드가 가장 위험한지 한 눈에 잡혀요.

수집 도구는 Metricbeat 또는 Elastic Agent (Fleet 통합). Metricbeat 는 system · docker · kubernetes · nginx · mysql · postgresql · redis · kafka · jvm 등 80+ 모듈을 제공해서, 서비스 한 줄 설정 으로 그 서비스 표준 메트릭을 시작할 수 있어요.

# metricbeat.yml — Kubernetes 환경
metricbeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: true

metricbeat.modules:
  - module: kubernetes
    metricsets:
      - state_node
      - state_deployment
      - state_pod
      - state_container
    period: 10s
    hosts: ["kube-state-metrics:8080"]

  - module: system
    metricsets: [cpu, load, memory, network, process, process_summary, diskio, filesystem]
    period: 10s
    processes: ['.*']

output.elasticsearch:
  hosts: ["es:9200"]

Service-level metrics — APM agent 가 보내는 transaction throughput · transaction latency · error rate 같은 서비스 단위 메트릭 은 자동으로 Metrics UI 에 합쳐져요. 그러니 호스트 CPU 70% + 서비스 latency p99 850ms 를 같은 시간 축 한 화면 에서 보는 게 가능해요. 원인 (호스트 CPU) 과 결과 (서비스 latency) 가 같은 그래프에 겹쳐 그려져서 어디가 진짜 원인인지 빠르게 좁혀져요.

Uptime·Synthetic — 외부에서 두드리기

Uptime 은 우리 서비스가 외부 사용자 입장에서 살아 있는지 두드리는 자리예요. 내부 메트릭이 서비스가 자기 자신을 어떻게 보는지 라면, Uptime 은 외부에서 어떻게 보이는지. 둘 다 필요해요.

도구는 Heartbeat (Elastic Agent integration 가능). 단순 ping · TCP · HTTP 모니터링.

# heartbeat.yml
heartbeat.monitors:
  - type: http
    id: order-api
    name: "Order API health"
    schedule: '@every 10s'
    urls: ["https://api.example.com/health"]
    check.response.status: [200]
    check.response.body:
      - "ok"

  - type: tcp
    id: redis-tcp
    name: "Redis port"
    schedule: '@every 30s'
    hosts: ["redis.internal:6379"]

  - type: icmp
    id: internal-gw
    name: "Internal gateway"
    schedule: '@every 1m'
    hosts: ["10.0.0.1"]

output.elasticsearch:
  hosts: ["es:9200"]

Synthetic Monitoring 은 Heartbeat 의 진화형. 단순 HTTP 200 확인을 넘어서 Playwright 기반 실제 브라우저 시나리오 를 돌려요. 로그인 → 검색 → 장바구니 → 결제 같은 사용자 여정 (user journey) 을 5분마다 자동 실행해서, 어느 단계에서 몇 초 걸렸는지 단계별 측정.

// monitor.journey.js
import { journey, step, monitor, expect } from '@elastic/synthetics';

journey('Order checkout', ({ page }) => {
  monitor.use({
    id: 'order-checkout',
    schedule: 5,
    locations: ['seoul', 'tokyo'],
  });

  step('Visit homepage', async () => {
    await page.goto('https://shop.example.com');
    await expect(page).toHaveTitle(/Shop/);
  });

  step('Search product', async () => {
    await page.fill('#search', '키보드');
    await page.press('#search', 'Enter');
    await page.waitForSelector('.product-card');
  });

  step('Add to cart', async () => {
    await page.click('.product-card:first-child .add-cart');
    await page.waitForSelector('.cart-count:has-text("1")');
  });
});

여러 Location 에서 동시에 도는 게 핵심. 서울에서는 빠른데 도쿄에서는 4초 같은 지역별 차이 가 보이면 CDN·DNS·Network 어디가 문제인지 좁히기 쉬워요.

SLO Management — Error Budget·Burn Rate

SLO (Service Level Objective) 는 우리 서비스 품질 목표 예요. 지난 30일 동안 99.9% 의 요청이 1초 안에 응답 같은 수치 약속. Google SRE 책에서 표준화한 개념이고, Elastic 8.x 부터 SLO Management 가 정식 제품화됐어요.

핵심 단어 셋.

SLI (Service Level Indicator) — 측정 가능한 지표. 2xx 응답률 · 1초 이내 응답률 · 에러율 같은 자리.

SLO (Service Level Objective) — SLI 에 대한 목표값. 2xx 응답률 ≥ 99.9% / 30일 같은 자리.

Error Budget — SLO 100% 에서 SLO 목표를 뺀 여유분. 99.9% SLO 면 0.1% 가 허용 가능한 실패 예요. 30일이면 43.2분 다운타임 허용.

Burn Rate — Error Budget 을 얼마나 빨리 소진하고 있는지 비율. 1.0 이면 정확히 한 달에 100% 소진 페이스. 14.4 이면 1시간 안에 한 달 budget 다 소진 비상 페이스.

Kibana SLO UI 에서 SLO 정의 예시.

{
  "name": "Order API availability",
  "description": "99.9% of /orders requests return 2xx",
  "indicator": {
    "type": "sli.kql.custom",
    "params": {
      "index": "apm-*",
      "good": "service.name : \"order-service\" AND transaction.result : \"HTTP 2xx\"",
      "total": "service.name : \"order-service\" AND transaction.type : \"request\"",
      "timestampField": "@timestamp"
    }
  },
  "timeWindow": {
    "duration": "30d",
    "type": "rolling"
  },
  "budgetingMethod": "occurrences",
  "objective": {
    "target": 0.999
  }
}

Burn Rate Alert — 표준 권장은 2-window 알람. 지난 1시간 burn rate ≥ 14.4 AND 지난 5분 burn rate ≥ 14.4 같이 두 창을 AND 로 묶어 순간 스파이크 오탐 을 거르고 진짜 사고 만 잡는 패턴. Google SRE 책 Site Reliability Workbook 의 Alerting on SLO 챕터가 원본 레시피.

운영자 관점에서 SLO 가 주는 가장 큰 가치 — 알람을 줄이는 기준 이에요. CPU 80% 같은 원인 메트릭 알람 은 고객이 안 느끼는 가짜 알람 이 많아요. SLO Burn Rate 는 고객이 진짜 느끼는 품질 저하 만 잡아서 새벽 알람 수를 60~80% 줄일 수 있어요.

OpenTelemetry 통합 — vendor-neutral 표준

OpenTelemetry (줄여서 OTel) 는 CNCF 가 후원하는 관측 데이터 vendor-neutral 표준. 어느 벤더 도구로 보내든 같은 SDK·같은 데이터 모델 을 쓰자는 표준이고, 2026 시점에는 APM 분야의 사실상 표준 자리에 올라왔어요.

Elastic 도 OTel native 지원 으로 방향을 굳혔어요. 정확히는 — 기존 Elastic APM agent 와 OTel SDK 두 가지를 모두 받음. 신규 프로젝트는 OTel SDK + OTel Collector → Elastic 조합이 권장 패턴이에요.

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert

exporters:
  otlphttp/elastic:
    endpoint: "https://otel.example.es.io:443"
    headers:
      Authorization: "ApiKey ${ELASTIC_API_KEY}"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlphttp/elastic]
    metrics:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlphttp/elastic]
    logs:
      receivers: [otlp]
      processors: [batch, resource]
      exporters: [otlphttp/elastic]

장점이 두 가지 — 벤더 락인 해소 (나중에 Datadog·Grafana 로 갈아탈 때 코드 변경 X) 와 생태계 확장 속도 (자동 계측 라이브러리가 OTel 진영에서 더 빨리 나옴). 단점은 Elastic APM agent 의 일부 고급 기능 (예: 일부 자동 계측·일부 분석 기능) 이 OTel 경로에서는 살짝 늦거나 빠질 수 있다는 점. 8.x 후반 들면서 격차는 빠르게 좁혀지는 중.

선택 가이드 — 기존 Elastic APM 환경 은 그대로 유지하다 신규 서비스만 OTel 로 시작, 완전 신규 환경 은 처음부터 OTel + Elastic 조합 권장.

자주 만나는 사고

사고 1 — APM Agent 버전과 Server 버전 불일치

원인 — APM Agent 가 8.13, APM Server 가 8.8 처럼 Agent 가 더 최신 이면 일부 필드가 unknown 으로 들어오거나 아예 reject 돼서 트레이스 일부가 사라져요.

해결 — Elastic 공식 호환성 표를 보고 Agent ≤ Server 가 원칙. 회사 표준 매트릭스에 Server 버전 + 각 언어 Agent 최대 버전 을 명시하고 배포 파이프라인에서 강제.

사고 2 — high-cardinality label 폭주

원인 — APM 트랜잭션 이름이나 메트릭 라벨에 user_id · request_id · timestamp 같은 사실상 모든 값이 unique 한 필드를 박으면, ES 인덱스 필드 수가 폭증하고 메모리가 터져요. Mapping Explosion 사고(8편) 의 Observability 판.

해결 — APM agent 설정에서 transaction name template 을 route 패턴 (예: /orders/:id) 으로 박고, custom label 에는 low cardinality 만 (환경·리전·서비스 버전 같은 자리). user_id 류는 label 이 아니라 trace attribute 로 박아 검색만 가능하게.

사고 3 — ECS 누락된 신규 서비스

원인 — 신규 서비스가 로그를 자체 JSON 키 (userId · reqId · errMsg) 로 찍고 ECS 필드 (user.id · trace.id · error.message) 를 안 박으면, Observability UI 에서 그 서비스만 비어 보여요. 트레이스·로그 가로지르기가 끊겨요.

해결 — 신규 서비스 체크리스트에 ECS 호환 로깅 라이브러리 사용 을 박아요. Java 는 ecs-logging-java, Node.js 는 @elastic/ecs-pino-format, Python 은 ecs-logging 같은 표준 라이브러리가 있어요. 레거시는 Ingest Pipeline 에서 ECS 로 변환.

사고 4 — Heartbeat URL 잘못 설정

원인 — Synthetic 모니터가 내부 health endpoint (예: /actuator/health) 만 두드리면, Spring Boot 자체 가 살아 있어도 DB 연결·Redis 연결 이 죽은 부분 장애 를 못 잡아요. health endpoint 가 too healthy 한 자리.

해결 — Heartbeat 는 고객이 실제로 두드리는 외부 endpoint (예: GET /api/products/popular) 를 한 번 더 두드리고, 응답 body 에 실제 데이터가 들어있는지 check.response.body 로 검증. Synthetic 은 로그인·결제 같은 돈 도는 사용자 여정 을 우선.

사고 5 — SLO threshold 너무 빡빡

원인 — p99 = 100ms · 99.99% availability 같이 현실보다 빡빡한 SLO 를 박으면 Error Budget 이 며칠 만에 소진돼서 모든 알람이 항상 burning. 알람 피로(alert fatigue) 가 폭발해 진짜 사고를 놓쳐요.

해결 — 현재 성능 측정 → 90 percentile 정도 에서 SLO 시작. 처음 한 달 실측 → 조정 → 실측 사이클을 두 번 돌리고 정착. 너무 느슨하면 의미 X · 너무 빡빡하면 알람 폭주 의 균형이 핵심.

사고 6 — OTel Collector 비활성 시 데이터 손실

원인 — OTel Collector 가 batch processor 만 쓰고 queue/retry 가 없으면, Collector 재시작·ES 일시 다운 동안 메모리에 쌓인 트레이스가 그대로 증발. 사고 시점 트레이스가 가장 중요한데 빠지는 자리.

해결 — Collector 설정에 sending_queue + retry_on_failure + file_storage extension 을 박아 디스크 큐 를 만들어요. ES 일시 다운에도 데이터를 디스크에 쌓아 두고 복구 후 재전송.

사고 7 — 로그·트레이스·메트릭 retention 미스매치

원인 — 로그는 7일 · 메트릭은 30일 · 트레이스는 3일 처럼 retention 이 제각각이면, 2주 전 어느 새벽 사고 를 분석할 때 로그·메트릭은 있는데 트레이스만 없는 빈자리가 생겨요. 사고 분석 효용이 크게 떨어져요.

해결 — 세 데이터 retention 을 같은 정책 으로 통일. 비용 부담이면 cold/frozen tier (28편 ILM 깊이) 로 7일 이후 cold + 30일 후 frozen 같이 비싼 hot tier 만 줄이고 논리적 retention 은 길게.

운영 권장 패턴

운영 진입 0순위는 ECS 호환 로깅 라이브러리 표준화예요. 신규 서비스 첫 PR 체크리스트에 ecs-logging- 의존 + trace.id 자동 박힘 확인 을 박아 두면, Observability UI 가 그날부터 일관된 모습으로 보이기 시작해요. 레거시는 한꺼번에 못 바꿔도 새 서비스부터* 가 원칙.

알람 표준 패턴으로 SLO Burn Rate 2-window 만 채택하는 게 운영 부담 최소. CPU 80% · disk 90% 같은 원인 메트릭 알람 은 daily summary 메일 로 격하시키고, 새벽 깨우는 알람은 고객이 진짜 느끼는 SLO 만. 알람 수가 한 달 안에 절반 이하로 줄어요.

신규 서비스는 OTel SDK + Elastic exporter 로 시작. 기존 서비스가 Elastic APM agent 면 그대로 두고, 신규부터 OTel 로 굳혀 가는 점진 전환이 현실적. 둘이 같은 ES 클러스터에 들어가니 traceparent 표준만 지키면 한 트레이스에서 만나요.

Heartbeat·Synthetic 은 외부 사용자 시점 health 로만 씁니다. 내부 /actuator/health 는 K8s liveness 용 따로, Synthetic 은 로그인·검색·결제 같은 사용자 여정 시나리오 가 표준. 외부 사용자 입장과 내부 진단 입장 두 갈래를 분리해야 부분 장애 가 잡혀요.

monitoring·observability 데이터는 운영 ES 클러스터와 별도 클러스터 로 분리. 30편 권장 패턴과 같은 이유로, 관측 데이터 쓰기 폭증이 검색 응답을 막는 자리를 만들지 않기 위함. 작은 회사라도 최소 별도 인덱스 + 별도 노드 그룹 까지는 분리.

시험 직전 한 번 더 — 압축 노트

• Elastic Observability = ES + Kibana 위에 APM · Logs · Metrics · Uptime · SLO 통합 솔루션. 한 ES 클러스터에 다 담는 단일 저장소형 관측 플랫폼.
• 3 pillar = Logs(텍스트 · 낮은 카디널리티) · Metrics(시계열 숫자 · 높은 카디널리티) · Traces(요청 워터폴).
• APM = Agent + APM Server (8.x 부터 Elastic Agent integration) + Kibana APM UI. traceparent (W3C Trace Context) 로 분산 트레이싱.
• Elastic APM Agent 언어 — Java · Python · Node.js · Go · Ruby · PHP · .NET · iOS · Android · RUM.
• Java Spring Boot APM = elastic-apm-agent 의존 + -javaagent JVM 옵션 + service_name · server_urls · environment · application_packages 4종 설정.
• ECS (Elastic Common Schema) = 250+ 표준 필드. source.ip · service.name · trace.id · log.level · event.dataset. 모든 Observability UI 가 ECS 기대.
• Logs UI = Stream(실시간) · Anomalies(ML) · Categories(자동 그룹화). trace.id 로 APM 워터폴과 한 클릭 연결.
• Metricbeat = 80+ 모듈. system · kubernetes · docker · mysql · postgres · redis · kafka · jvm 등.
• Metrics Inventory = host · container · pod · service · cluster 5 레이어 격자.
• Heartbeat = HTTP · TCP · ICMP 외부 health 두드리기. Synthetic Monitoring = Playwright 기반 사용자 여정 시나리오.
• SLI/SLO/Error Budget/Burn Rate = SRE 책 표준 4단어. 99.9% SLO → 30일 43.2분 다운타임 허용.
• Burn Rate Alert 표준 = 2-window (예: 1h ≥ 14.4 AND 5m ≥ 14.4) 로 오탐 거르기.
• OpenTelemetry = CNCF vendor-neutral 표준. 2026 시점 APM 사실상 표준. Elastic 도 OTel native 지원, 신규는 OTel SDK + OTel Collector → Elastic 권장.
• OTel Collector 필수 설정 = sending_queue + retry_on_failure + file_storage 디스크 큐 (재시작·다운 시 데이터 손실 방지).
• 7대 사고 = Agent/Server 버전 불일치 · high cardinality 폭주 · ECS 누락 · Heartbeat URL too healthy · SLO 너무 빡빡 · OTel Collector 큐 없음 · retention 미스매치.
• 5대 운영 패턴 = ECS 표준화 · SLO Burn Rate 알람 단일화 · 신규 OTel · Heartbeat 외부 시점 · 별도 클러스터.
• 30편 vs 34편 — 30편 = ES 클러스터 자체 건강(_cluster·_nodes·slow log). 34편 = ES 위에 얹은 우리 서비스 건강(APM·SLO·Synthetic).

시리즈 다른 편

• 이전 글 = 33편 Kibana·ELK — Discover·Visualize·Dashboard·Logstash·Filebeat
• 다음 글 = 35편 AWS OpenSearch Service — Domain·Serverless·Provisioned
• 30편 = Monitoring — _cluster/health·_nodes/stats·Slow Log·Stack Monitoring
• 25편 = Logstash·Beats·Fluentd — 로그 수집 비교
• 32편 = Spring Data Elasticsearch — Repository·Template·POJO
• 36편 = Elastic Cloud — Hosted·Serverless·Region·요금
• 37편 = IaC — Terraform·CloudFormation·Pulumi
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — Elastic Observability = ES + Kibana 위에 APM · Logs · Metrics · Uptime · SLO 를 한 통에 묶은 vendor-neutral OpenTelemetry 표준 관측 플랫폼. ECS 표준화 + SLO Burn Rate 알람 두 가지가 운영 진입 0순위.