Kubernetes Observability(2025)

CNCF 블로그

이 블로그는 CNCF(Cloud Native Computing Foundation)의 공식 블로그 글들을 기반으로 작성되었습니다.

1. What is Observability 2.0? (2025.01) - Observability 2.0 개념 정의
2. Observability Trends in 2025 – What's Driving Change? (2025.03)
3. Highlights from CNCF's first Open Observability Summit (2025.10)
4. From chaos to clarity: How OpenTelemetry unified observability across clouds (2025.11)

---

1. 들어가며: 왜 Observability인가?

Kubernetes 환경에서 애플리케이션을 운영하다 보면, 단순한 모니터링만으로는 복잡한 분산 시스템의 문제를 해결하기 어렵습니다. "서버 CPU가 높다"는 것은 알 수 있지만, "왜 높은지"를 파악하려면 더 깊은 가시성이 필요합니다.

Observability(관측 가능성)는 시스템의 외부 출력을 통해 내부 상태를 이해할 수 있는 능력을 의미합니다. 모니터링이 "알려진 문제를 감지"한다면, Observability는 "알지 못했던 문제까지 탐색"할 수 있게 해줍니다.

모니터링 vs Observability

구분	모니터링	Observability
접근 방식	사전 정의된 메트릭 수집	시스템 출력으로 내부 상태 추론
문제 탐지	알려진 문제 감지	알지 못했던 문제까지 탐색
질문 유형	"CPU가 80% 이상인가?"	"왜 응답이 느린가?"
데이터	메트릭 중심	메트릭 + 로그 + 트레이스 통합

---

2. Observability의 세 기둥

Observability는 세 가지 핵심 데이터 유형을 기반으로 합니다. 각각은 서로 다른 질문에 답하며, 함께 사용될 때 가장 강력한 인사이트를 제공합니다.

2.1 Metrics: "지금 시스템이 얼마나 잘 동작하는가?"

Metrics는 시간 간격으로 수집되는 숫자형 측정값입니다. CPU 사용률, 메모리 사용량, 요청 수, 응답 시간 등이 대표적인 예입니다.

메트릭 데이터 타입:

타입	설명	예시
Counter	누적 값 (단조 증가)	총 요청 수, 에러 횟수
Gauge	현재 값 (증감 가능)	현재 메모리 사용량, 활성 연결 수
Histogram	분포 측정 (버킷별)	응답 시간 분포
Summary	백분위 계산	p50, p99 레이턴시

Kubernetes 메트릭 소스:

flowchart TB
    subgraph K8s["Kubernetes 메트릭 소스"]
        KSM["kube-state-metrics<br/>K8s 객체 상태<br/>(Pod, Deployment 등)"]
        NE["node-exporter<br/>노드 하드웨어/OS 메트릭"]
        CA["cAdvisor (kubelet)<br/>컨테이너 리소스 사용량"]
        MS["metrics-server<br/>HPA/VPA용 집계 메트릭"]
    end

    KSM --> Prometheus
    NE --> Prometheus
    CA --> Prometheus
    MS --> Prometheus

    Prometheus --> Grafana

장점: 압축된 구조로 저장 비용이 낮고, 실시간 알림과 장기 트렌드 분석에 최적화되어 있습니다.

한계: "무엇이" 발생했는지 보여주지만, "왜" 발생했는지는 설명하지 못합니다.

2.2 Logs: "무슨 일이 일어났는가?"

Logs는 시스템 내 이벤트의 불변, 타임스탬프 기록입니다. 오류 메시지, 스택 트레이스, 감사 추적 등 가장 상세한 컨텍스트를 제공합니다.

Kubernetes Patterns : 컨테이너는 중요한 이벤트를 stdout과 stderr에 로깅하고, 이를 중앙 위치에서 수집하여 분석하는 것이 좋은 관행입니다. 또한 컨테이너 종료 시 /dev/termination-log에 마지막 메시지를 남기는 것도 권장됩니다.

 

Kubernetes 로그 수집 위치:

경로	설명
/var/log/containers/*.log	컨테이너 stdout/stderr 로그 (JSON 형식)
/var/log/pods/	Pod별 로그 디렉토리
/dev/termination-log	컨테이너 종료 메시지

구조화된 로그 예시 (JSON):

{
  "timestamp": "2025-01-15T10:30:45.123Z",
  "level": "ERROR",
  "service": "payment-service",
  "trace_id": "abc123def456",
  "span_id": "span789",
  "message": "Payment processing failed",
  "error": "Connection timeout to payment gateway",
  "user_id": "user-12345",
  "amount": 99.99
}

2.3 Traces: "요청이 어떤 경로로 흘러갔는가?"

Traces는 분산 시스템에서 개별 요청이 서비스를 통과하는 경로를 시각화합니다. 마이크로서비스 환경에서 병목 지점을 찾고 서비스 간 의존성을 이해하는 데 필수적입니다.

핵심 개념:

개념	설명
Trace	하나의 요청이 시스템을 통과하는 전체 여정
Span	Trace 내의 개별 작업 단위 (API 호출, DB 쿼리 등)
Context Propagation	서비스 간 추적 컨텍스트 전달 (W3C Trace Context)

분산 트레이스 흐름 예시:

sequenceDiagram
    participant C as Client
    participant AG as API Gateway
    participant OS as Order Service
    participant DB as Database
    participant PS as Payment Service
    participant EA as External API

    Note over C,EA: Trace ID: abc123def456

    C->>AG: HTTP Request
    activate AG
    Note right of AG: Span 1: 50ms

    AG->>OS: gRPC Call
    activate OS
    Note right of OS: Span 2: 30ms

    OS->>DB: SQL Query
    activate DB
    Note right of DB: Span 3: 15ms
    DB-->>OS: Result
    deactivate DB

    OS-->>AG: Response
    deactivate OS

    AG->>PS: gRPC Call
    activate PS
    Note right of PS: Span 4: 45ms

    PS->>EA: HTTP Call
    activate EA
    Note right of EA: Span 5: 40ms
    EA-->>PS: Response
    deactivate EA

    PS-->>AG: Response
    deactivate PS

    AG-->>C: HTTP Response
    deactivate AG

2.4 세 기둥 비교

구분	Metrics	Logs	Traces
데이터 형태	숫자 (시계열)	텍스트/JSON	구조화된 스팬
질문	"얼마나?"	"무엇이?"	"어디서?"
저장 비용	낮음	높음	중간
용도	알림, 트렌드	디버깅, 감사	병목 분석
카디널리티	낮음	높음	중간

실제 트러블슈팅 워크플로우:

flowchart LR
    A["Metric 알림 발생<br/>(CPU 90% 초과)"] --> B["Trace로 병목 위치 확인<br/>(Payment Service 지연)"]
    B --> C["Log로 근본 원인 분석<br/>(DB Connection Timeout)"]
    C --> D["문제 해결"]

    style A fill:#ff6b6b,color:#fff
    style B fill:#4ecdc4,color:#fff
    style C fill:#45b7d1,color:#fff
    style D fill:#96ceb4,color:#fff

---

3. Observability 2.0: 새로운 패러다임

 

CNCF Blog (What is Observability 2.0?): "In the race to adopt cutting-edge technologies like Kubernetes, microservices, and serverless computing, monitoring often becomes an afterthought. Many enterprises assume their legacy observability tools will suffice. However, as they transition to the cloud and adopt distributed architectures, they face challenges that are significantly harder to resolve."

 

Kubernetes, 마이크로서비스, 서버리스 같은 최신 기술을 도입하면서, 많은 기업들이 기존 레거시 관측 도구로 충분하다고 가정합니다. 하지만 분산 아키텍처로 전환하면서 기존 방식으로는 해결하기 훨씬 어려운 문제들에 직면합니다.

3.1 전통적 Observability vs Observability 2.0

CNCF Blog: "Traditional: Relies on separate tools for metrics, logs, and traces, creating silos. 2.0: Unifies telemetry data into a single platform, offering a comprehensive view of system health."

구분	전통적 Observability	Observability 2.0
데이터 처리	별도 도구로 메트릭/로그/트레이스 분리, 사일로 생성	단일 플랫폼에 텔레메트리 통합, 종합적 시스템 뷰
문제 탐지	정적 임계값, 반응적(Reactive) 대응	AI/ML로 실시간 이상 탐지, 선제적(Proactive) 대응
컨텍스트	기술적 데이터만, 비즈니스 연계 부족	비즈니스 메트릭과 연결, 의사결정 지원
확장성	동적 환경(K8s, 서버리스)에서 어려움	클라우드 네이티브 아키텍처에 맞춤 설계

3.2 Observability 2.0의 5가지 핵심 기능

CNCF Blog: "Observability 2.0 brings a modern approach to monitoring systems: unified telemetry streams, AI-powered anomaly detection, telemetry data contextualization, proactive root cause analysis, and scalability and flexibility."

mindmap
  root((Observability 2.0))
    통합 텔레메트리
      메트릭
      로그
      트레이스
      이벤트
    AI 기반 탐지
      동적 베이스라인
      이상 탐지
      패턴 인식
    데이터 컨텍스트화
      비즈니스 메트릭 연결
      매출 영향 분석
      고객 만족도
    선제적 RCA
      자동 상관관계
      근본 원인 식별
      예측적 분석
    확장성/유연성
      K8s 네이티브
      멀티 클라우드
      서버리스 지원

1. 통합 텔레메트리 스트림: 메트릭, 로그, 트레이스, 이벤트를 하나의 플랫폼에서 통합
2. AI 기반 이상 탐지: ML로 시스템 동작 이해, 동적 베이스라인 설정
3. 데이터 컨텍스트화: 원시 데이터와 비즈니스 메트릭(매출, 고객 만족도) 연결
4. 선제적 근본 원인 분석: 텔레메트리 데이터 자동 상관관계로 문제 원인 즉시 파악
5. 확장성과 유연성: Kubernetes, 멀티 클라우드 환경에서 원활한 확장

---

4. Tool Sprawl: 혼돈에서 명확함으로

CNCF Blog (From chaos to clarity): "Modern applications rarely live in a single place anymore. One organization's application footprint was spread across AWS, Azure, and GCP, with some workloads still running on-prem. This multi-cloud approach gave them resilience and flexibility, but it came with a hidden cost: observability sprawl."

 

현대 애플리케이션은 더 이상 단일 위치에 존재하지 않습니다. AWS, Azure, GCP에 워크로드가 분산되고, 일부는 온프레미스에서 실행됩니다. 이 멀티 클라우드 접근법은 회복력과 유연성을 제공하지만, "관측 가능성 스프롤(observability sprawl)"이라는 숨겨진 비용이 따릅니다.

 

툴 스프롤 ???

툴 스프롤(Tool Sprawl)은 단어 그대로 '도구(Tool)가 무분별하게 확산(Sprawl)'된 상태를 의미합니다. 특히 최신 MSA(Microservice Architecture) 환경에서는 각 기능과 목적에 따라 다양한 기술 스택과 오픈소스, SaaS 솔루션을 도입하는 경우가 많습니다.

• 로그 수집: ELK Stack (Elasticsearch, Logstash, Kibana)
• 메트릭 수집/모니터링: Prometheus, Grafana
• 분산 추적: Jaeger, Zipkin
• APM: Datadog, New Relic

각각의 도구는 특정 영역에서 뛰어난 성능을 보이지만, 조직 전체적으로 통합 전략 없이 도입되다 보면 데이터가 각 도구에 갇히는 '데이터 사일로(Data Silo)' 현상을 초래합니다.

4.1 실제 문제 상황

CNCF Blog: "On AWS, they used CloudWatch; on Azure, Azure Monitor; on GCP, Stackdriver; and in their on-prem setup, a mix of Prometheus and ELK. Add to that some third-party APM tools, and suddenly engineers were juggling five dashboards just to debug one request."

 

한 기업의 실제 상황: AWS에서는 CloudWatch, Azure에서는 Azure Monitor, GCP에서는 Stackdriver, 온프레미스에서는 Prometheus와 ELK. 여기에 서드파티 APM 도구까지 더하면, 엔지니어들은 하나의 요청을 디버깅하기 위해 5개의 대시보드를 오가야 했습니다.

Tool Sprawl의 결과:

• 엔드투엔드 가시성 부재: AWS Lambda → Azure API → GCP DB 요청 추적 불가
• 일관성 없는 계측: 각 도구마다 별도 SDK와 에이전트 필요
• 벤더 종속: 도구 전환 시 계측 전체를 재작성해야 함
• MTTR 증가: 평균 복구 시간이 지속적으로 상승

4.2 아키텍처 변화: Before vs After

Before (혼돈):

flowchart TB
    subgraph AWS["AWS"]
        A1[Service A] --> CW[CloudWatch]
    end

    subgraph Azure["Azure"]
        A2[Service B] --> AM[Azure Monitor]
    end

    subgraph GCP["GCP"]
        A3[Service C] --> SD[Stackdriver]
    end

    subgraph OnPrem["On-Premise"]
        A4[Service D] --> PM[Prometheus]
        A4 --> ELK[ELK Stack]
    end

    Engineer["Engineer"] --> CW
    Engineer --> AM
    Engineer --> SD
    Engineer --> PM
    Engineer --> ELK

    style Engineer fill:#ff6b6b,color:#fff
    style CW fill:#ff9f43,color:#fff
    style AM fill:#54a0ff,color:#fff
    style SD fill:#5f27cd,color:#fff
    style PM fill:#00d2d3,color:#fff
    style ELK fill:#10ac84,color:#fff

After (OpenTelemetry 통합):

flowchart TB
    subgraph Apps["Applications"]
        A1[Service A<br/>AWS]
        A2[Service B<br/>Azure]
        A3[Service C<br/>GCP]
        A4[Service D<br/>On-Prem]
    end

    A1 --> SDK[OTel SDK]
    A2 --> SDK
    A3 --> SDK
    A4 --> SDK

    SDK --> Collector[OTel Collector]

    subgraph Backend["Unified Backend"]
        Collector --> Jaeger[Jaeger<br/>Traces]
        Collector --> Prom[Prometheus<br/>Metrics]
        Collector --> Loki[Loki<br/>Logs]
    end

    Jaeger --> Grafana
    Prom --> Grafana
    Loki --> Grafana

    Engineer["Engineer"] --> Grafana

    style SDK fill:#4ecdc4,color:#fff
    style Collector fill:#45b7d1,color:#fff
    style Grafana fill:#f39c12,color:#fff
    style Engineer fill:#2ecc71,color:#fff

4.3 OpenTelemetry

CNCF Blog: "OpenTelemetry is an open-source standard for collecting traces, metrics, and logs. As part of the CNCF ecosystem, OTel provides Language SDKs, a Collector that receives telemetry, processes it, and exports to any backend, and Semantic conventions to standardize telemetry. In other words: instrument once, export anywhere."

 

OpenTelemetry는 트레이스, 메트릭, 로그를 수집하는 오픈소스 표준입니다. 핵심 원칙은 *"한 번 계측하면, 어디로든 내보낼 수 있다(instrument once, export anywhere)"*입니다.

OpenTelemetry 도입 3단계:

1. 애플리케이션 계측: OTel SDK로 주요 마이크로서비스에 자동 트레이스/메트릭/로그 수집
2. OTel Collector 배포: 앱 → Collector로 전송, Collector가 처리 후 백엔드로 라우팅
3. 통합 관측: Jaeger(트레이스) + Prometheus(메트릭) + Grafana(대시보드)

OTel Collector 설정 예시:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
    timeout: 10s
  memory_limiter:
    limit_mib: 512

exporters:
  prometheus:
    endpoint: "0.0.0.0:9464"
  jaeger:
    endpoint: "jaeger:14250"
    tls:
      insecure: true
  loki:
    endpoint: "http://loki:3100/loki/api/v1/push"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [loki]

---

5. 2025년 Observability 핵심 트렌드

CNCF Blog (Trends 2025): "Looking back at 2024, modern observability has focused on handling the complexity of cloud systems. Key trends like automation, AI, and better data management have helped teams monitor performance and fix problems faster."

5.1 데이터 관리로 60-80% 비용 절감

CNCF Blog: "Organizations have realized that nearly 70% of collected observability data is unnecessary, leading to inflated costs. By sampling key traces, storing only important logs, and moving less critical data to lower-cost storage, businesses can cut costs by 60-80%."

수집되는 관측 데이터의 약 70%가 불필요합니다. 스마트한 데이터 전략으로 60-80% 비용 절감이 가능합니다:

pie title 관측 데이터 분포
    "필요한 데이터" : 30
    "불필요한 데이터" : 70

비용 최적화 전략:

전략	설명	예상 절감
샘플링	에러/지연 이상치 100%, 정상 트래픽 10%	40-60%
로그 필터링	프로덕션에서 DEBUG 레벨 드롭	30-50%
계층 스토리지	Hot → Warm → Cold 티어링	20-40%
카디널리티 관리	고카디널리티 레이블 제한	15-30%

5.2 AI 기반 예측 운영

CNCF Blog: "According to the 2024 Observability Pulse Survey, only 10% of organizations report achieving full observability. AI-driven automation improves this by providing guided debugging steps, reducing human error, and accelerating issue resolution."

2024년 설문조사에서 단 10%만 완전한 관측 가능성 달성. AI가 가이드 디버깅, 인적 오류 감소, MTTR 단축을 통해 이 격차를 메웁니다.

CNCF Blog (What is Observability 2.0?): "AI-driven anomaly detection capabilities enable the identification of unknown unknowns, detecting unusual patterns of behavior not seen before."

5.3 DevOps + SecOps + FinOps 통합

CNCF Blog: "Organizations are including cost, compliance, and security data in their observability frameworks. Under this one framework, teams from DevOps, SecOps, and FinOps can collaborate and make better, more informed decisions."

flowchart TB
    subgraph Framework["통합 Observability 프레임워크"]
        M[Metrics]
        L[Logs]
        T[Traces]
        Cost[비용 데이터]
        Sec[보안 데이터]
        Comp[규정 준수]
    end

    M --> Platform[통합 플랫폼]
    L --> Platform
    T --> Platform
    Cost --> Platform
    Sec --> Platform
    Comp --> Platform

    Platform --> DevOps
    Platform --> SecOps
    Platform --> FinOps

    style Platform fill:#3498db,color:#fff
    style DevOps fill:#2ecc71,color:#fff
    style SecOps fill:#e74c3c,color:#fff
    style FinOps fill:#f39c12,color:#fff

성능 메트릭 외에도 비용, 규정 준수, 보안 데이터를 관측 가능성 프레임워크에 통합. DevOps, SecOps, FinOps 팀이 하나의 프레임워크에서 협업합니다.

---

6. (추가) LGTM 스택: Grafana 기반 통합 Observability

LGTM 스택은 Grafana Labs가 제공하는 오픈소스 Observability 솔루션으로, 세 기둥(Metrics, Logs, Traces)을 단일 플랫폼에서 통합 관리합니다.

6.1 LGTM 구성 요소

컴포넌트	역할	특징
Loki	로그 집계	Prometheus 스타일 레이블 기반, 인덱싱 최소화로 비용 효율적
Grafana	시각화/대시보드	통합 UI, 메트릭-로그-트레이스 연계
Tempo	분산 트레이싱	인덱스 없는 설계, 오브젝트 스토리지 활용
Mimir	메트릭 저장소	Prometheus 호환, 수평 확장, 장기 보관

6.2 LGTM 아키텍처

flowchart TB
    subgraph Apps["Applications"]
        S1[Service A]
        S2[Service B]
        S3[Service C]
        S4[Service D]
    end

    S1 --> OTel
    S2 --> OTel
    S3 --> OTel
    S4 --> OTel

    subgraph Collection["OpenTelemetry Collector"]
        OTel[Receivers] --> Proc[Processors]
        Proc --> Exp[Exporters]
    end

    Exp --> Mimir
    Exp --> Loki
    Exp --> Tempo

    subgraph Storage["Storage Layer"]
        Mimir["Mimir<br/>(Metrics)"]
        Loki["Loki<br/>(Logs)"]
        Tempo["Tempo<br/>(Traces)"]
    end

    Mimir --> Grafana
    Loki --> Grafana
    Tempo --> Grafana

    subgraph Visualization["Visualization"]
        Grafana["Grafana<br/>(Unified Dashboard)"]
    end

    style OTel fill:#4ecdc4,color:#fff
    style Mimir fill:#e74c3c,color:#fff
    style Loki fill:#3498db,color:#fff
    style Tempo fill:#9b59b6,color:#fff
    style Grafana fill:#f39c12,color:#fff

6.3 상관관계 설정

LGTM 스택의 핵심 강점은 세 기둥 간 상관관계(Correlation)입니다.

flowchart LR
    subgraph Correlation["상관관계 연결"]
        M["Metrics<br/>(Exemplars)"]
        L["Logs<br/>(trace_id)"]
        T["Traces<br/>(span_id)"]
    end

    M <-->|"Exemplar<br/>trace_id"| T
    L <-->|"derivedFields<br/>trace_id"| T
    T <-->|"tracesToLogs<br/>service.name"| L
    T <-->|"tracesToMetrics<br/>service.name"| M

    style M fill:#e74c3c,color:#fff
    style L fill:#3498db,color:#fff
    style T fill:#9b59b6,color:#fff

 

6.4 EFK vs PLG(LGTM) 비교

구분	EFK (Elasticsearch, Fluentd, Kibana)	PLG/LGTM (Promtail, Loki, Grafana)
인덱싱	전문 인덱싱 (Full-text)	레이블 기반 최소 인덱싱
저장 비용	높음 (인덱스 오버헤드)	낮음 (압축된 청크)
쿼리 속도	빠름 (인덱스 활용)	상대적으로 느림
확장성	복잡한 클러스터 관리	간단한 수평 확장
학습 곡선	높음 (ELK 쿼리 언어)	낮음 (PromQL 유사)
통합	Kibana 독립 UI	Grafana에서 메트릭/트레이스와 통합
적합 환경	로그 검색 중심, 대규모 분석	비용 효율, K8s 네이티브 환경

7. (추가) eBPF 기반 Observability

eBPF(extended Berkeley Packet Filter)는 커널 수준에서 프로그램을 실행할 수 있는 기술로, 코드 수정 없이 애플리케이션을 관측할 수 있는 혁신적인 방법을 제공합니다.

7.1 eBPF란?

eBPF는 리눅스 커널 내에서 안전하게 샌드박스된 프로그램을 실행할 수 있는 기술입니다. 원래 네트워크 패킷 필터링을 위해 설계되었지만, 현재는 Observability, 보안, 네트워킹 등 다양한 영역에서 활용됩니다.

eBPF의 작동 원리:

flowchart TB
    subgraph UserSpace["User Space"]
        Cilium["Cilium<br/>Hubble"]
        Pixie["Pixie"]
        Beyla["Grafana<br/>Beyla"]
    end

    subgraph eBPF["eBPF Runtime"]
        Verifier["Verifier"] --> JIT["JIT Compiler"]
        JIT --> Exec["Kernel Execution"]
    end

    subgraph Kernel["Kernel Space"]
        Net["Network<br/>Stack"]
        Syscall["System<br/>Calls"]
        Trace["Tracing<br/>Points"]
    end

    Cilium --> eBPF
    Pixie --> eBPF
    Beyla --> eBPF

    Exec --> Net
    Exec --> Syscall
    Exec --> Trace

    style eBPF fill:#9b59b6,color:#fff
    style Kernel fill:#2c3e50,color:#fff

7.2 eBPF Observability 장점

장점	설명
제로 계측	애플리케이션 코드 수정 없이 관측 가능
낮은 오버헤드	커널 레벨 실행으로 최소한의 성능 영향
심층 가시성	커널, 네트워크, 시스템 콜 레벨 데이터 수집
언어 무관	모든 프로그래밍 언어의 애플리케이션 지원
실시간 분석	이벤트 발생 즉시 처리

7.3 주요 eBPF Observability 도구

flowchart TB
    subgraph CNCF["CNCF Projects"]
        subgraph Graduated["Graduated"]
            Cilium["Cilium Hubble<br/>네트워크 관측"]
            Falco["Falco<br/>런타임 보안"]
        end

        subgraph Sandbox["Sandbox"]
            Pixie["Pixie<br/>자동 텔레메트리"]
        end
    end

    subgraph Others["Other Projects"]
        Beyla["Grafana Beyla<br/>자동 계측"]
        Tetragon["Tetragon<br/>보안 관측"]
    end

    style Graduated fill:#2ecc71,color:#fff
    style Sandbox fill:#f39c12,color:#fff

도구	CNCF 상태	주요 기능
Cilium Hubble	Graduated	네트워크 관측, 서비스 맵, 보안 정책
Pixie	Sandbox	자동 텔레메트리, 스크립트 기반 분석
Grafana Beyla	-	자동 계측, OTel 호환
Falco	Graduated	런타임 보안, 이상 탐지
Tetragon	-	보안 관측, 런타임 정책 시행

7.4 eBPF vs 전통적 계측 비교

flowchart TB
    subgraph Traditional["전통적 계측"]
        T1["애플리케이션"] --> T2["SDK/Agent<br/>삽입"]
        T2 --> T3["데이터 수집"]
    end

    subgraph eBPF_Based["eBPF 기반 계측"]
        E1["애플리케이션<br/>(수정 없음)"] --> E2["커널"]
        E2 --> E3["eBPF 프로그램"]
        E3 --> E4["데이터 수집"]
    end

    style T2 fill:#e74c3c,color:#fff
    style E3 fill:#2ecc71,color:#fff

 

구분	전통적 계측 (SDK/Agent)	eBPF 기반 계측
코드 수정	필요	불필요
배포 방식	애플리케이션 내 SDK	DaemonSet/Sidecar
오버헤드	중간 (에이전트 의존)	낮음 (커널 레벨)
데이터 깊이	애플리케이션 레벨	커널 + 애플리케이션
언어 지원	언어별 SDK 필요	언어 무관
시작 비용	높음 (계측 작업)	낮음 (즉시 관측)
커스터마이징	유연함	제한적

 

---

참고 자료

CNCF 블로그:

• What is Observability 2.0? (2025.01)
• Observability Trends in 2025 (2025.03)
• Highlights from Open Observability Summit (2025.10)
• From chaos to clarity - OpenTelemetry (2025.11)

공식 문서:

• OpenTelemetry Documentation
• Grafana Loki Documentation
• Grafana Tempo Documentation
• Cilium Hubble Documentation
• Pixie Documentation