동일 호스트 실험: 동일한 Demo (service-a / service-b) 상의 DataBuff (OTLP :4318) 및 OpenObserve (OTLP HTTP :5080/api/default). 호스트: 192.168.50.140 · DataBuff v0.1.4 · OpenObserve v0.91.0-rc1. 표시: ✅ 본 실험에서 검증됨 · △ 존재하지만 제한적임 · ❌ 대응 기능 없음. 녹색 굵은 셀은 DataBuff가 명확하게 앞서는 부분입니다.

포지셔닝: DataBuff = AI 네이티브 APM (Application Performance Monitoring) 깊이; OpenObserve = 통합 관측성 (Observability) 플랫폼 (로그 / 메트릭 / 트레이스 / RUM), 로그 검색 및 오브젝트 스토리지 (Object-storage) 비용 측면에서 강력함.

1. 기능 매트릭스 (Capability matrix)

7가지 AI 기능 (v0.1.4: See → Squad → Inspect → Diagnose → Repair → Predict → Answer)

• 기능 (Capability) — OpenObserve v0.91.0-rc1 · DataBuff v0.1.4
• ① See · 자연어 질문 (natural-language questions) — ❌ · ✅ 서비스 / 토폴로지 (topology) / 트렌드에 대해 질문; AI가 텔레메트리 (telemetry)를 읽음
• ② Squad · 멀티 에이전트 협업 (multi-agent collaboration) — ❌ · ✅ 병렬적 증거 수집; 직렬적 컨텍스트 (context) 보존; 재사용 가능한 작업 오케스트레이션 (orchestration)
• ③ Inspect · 서비스 조사 + 보고 (service inspection + report) — ❌ · ✅ 증거 및 권장 조치를 포함한 원샷 (one-shot) 조사
• ④ Diagnose · 병목 현상 / RCA 증거 (bottleneck / RCA evidence) — ❌ · ✅ 트레이스 (Trace) / 메트릭 (metrics) / 토폴로지 (topology) 증거 (블랙박스 방식의 "근본 원인"이 아님)
• ⑤ Repair · 운영 전문가 조치 (Ops Expert actions) — ❌ · ✅ 정책 및 인간의 승인 하에 복구; 위험한 명령 데닐리스트 (denylist)
• ⑥ Predict · 용량 / 트렌드 (capacity / trends) — ❌ · ✅ 용량 및 트렌드 분석 — 사후 처리에서 사전 예측으로
• ⑦ Answer · 제품 Q&A (product Q&A) — ❌ · ✅ 문서 및 코드로부터 배포 / 수집 / 설정을 답변
• Extend · MCP / Skill / 커스텀 전문가 (custom experts) — ❌ · ✅ 외부 MCP / Skill 및 커스텀 디지털 전문가

가장 큰 격차: OpenObserve에는 대응하는 AI 플랫폼이 없음 (Traces에 LLM Insights 항목이 있으나, 여기서는 APM 분류(triage)로서 검증되지 않음); DataBuff는 7가지 기능을 구성 가능한 홈 엔트리로 노출하며 APM을 AI 컨텍스트로 활용함.

APM

• Capability (기능) — OpenObserve v0.91.0-rc1 · DataBuff v0.1.4
• 1. Global topology (전역 토폴로지) — ❌ 서비스 의존성 토폴로지 없음 · ✅ 전역 토폴로지 + 상태 색상 + 노드 드릴다운 (drill-down)
• 2. Service list & golden metrics (서비스 목록 및 골든 메트릭) — ✅ 서비스 카탈로그 (Requests / Error Rate / P99 등) · ✅ 서비스 목록 + 차트; 동일 데모에서 service-a / b 표시
• 3. Service-level topology (서비스 레벨 토폴로지) — ❌ · ✅ 전용 서비스 토폴로지
• 4. Service call analysis (up/downstream + Trace) (서비스 호출 분석 (업스트림/다운스트림 + Trace)) — ❌ · ✅ 업스트림/다운스트림 구조, 지연 시간(latency)/기여도; Trace로 드릴다운
• 5. Instance golden metrics (인스턴스 골든 메트릭) — ❌ · ✅ 인스턴스 골든 메트릭 차트 / 목록
• 6. Instance topology (인스턴스 토폴로지) — ❌ · ✅ 전용 인스턴스 토폴로지
• 7. Instance call analysis (up/downstream + Trace) (인스턴스 호출 분석 (업스트림/다운스트림 + Trace)) — ❌ · ✅ 인스턴스별 업스트림/다운스트림 + Trace
• 8. Endpoint topology (엔드포인트 토폴로지) — ❌ · ✅ 전용 엔드포인트 토폴로지
• 9. Endpoint call analysis (up/downstream + Trace) (엔드포인트 호출 분석 (업스트림/다운스트림 + Trace)) — ❌ · ✅ 엔드포인트별 호출자/피호출자(caller/callee) + Trace
• 10. Service flow (service / endpoint Trace contribution) (서비스 흐름 (서비스 / 엔드포인트 Trace 기여도)) — ❌ · ✅ 엔트리로부터의 응답 기여도; 서비스 / 엔드포인트 Trace 뷰
• 11. Middleware / external pages (DB / cache / MQ / external) (미들웨어 / 외부 페이지 (DB / 캐시 / MQ / 외부)) — ❌ Span 필드에서 db/http 확인 가능; 전용 페이지 없음 · ✅ 전용 페이지: DB / 캐시 / MQ / 외부
• 12. Error analysis (stats + endpoint) (에러 분석 (통계 + 엔드포인트)) — △ ERROR Span / 로그 필터링 가능 · ✅ 에러 통계 + 엔드포인트 드릴다운
• 13. Trace list / search (Trace 목록 / 검색) — ✅ Spans/Traces + 유연한 쿼리; 본 실험에서는 service-a · GET /demo/checkout · ✅ 차트 + 목록, 다차원 필터
• 14. Trace detail (Trace 상세) — ✅ Waterfall / Flame Graph / Trace Graph · ✅ 호출 순서 Waterfall + Span 속성(attributes)
• 15. Trace Span → logs (Trace Span → 로그) — ✅ Trace / Span에서 로그로 연결 가능 · ✅ 상단 "Log analysis" + Span Logs / Logs 탭
• 16. Log list / search (로그 목록 / 검색) — ✅ 강점: SQL / 전문 검색(full-text) + 히스토그램; 본 실험에서 수백 개의 이벤트 발생 · ✅ -
• 17. Log detail (로그 상세) — ✅ · ✅ -
• **18.

Log → Trace (로그 → 트레이스)** — ✅ Log → Trace (Span까지) · ✅ Log → Trace, Span까지

19. Flexible Metrics query (유연한 메트릭 쿼리) (SQL / PromQL) — ✅ 메트릭 페이지: SQL / PromQL / Builder · △ 내부 SQL 사용; 공개된 PromQL 엔트리 없음

20. Custom dashboards (커스텀 대시보드) — ✅ 대시보드 생성 가능 (본 실험에서는 목록이 비어 있을 수 있으나 기능은 존재함) · ❌ 아직 지원 안 함

21. Unified storage cost (통합 스토리지 비용) (객체 스토리지 + 압축) — ✅ 홈 화면에서 수집됨(Ingested) / 압축됨(Compressed) 표시 (본 실험에서 ~96MB → 10.5MB) · △ Doris 컬럼형(columnar) 방식; 객체 스토리지 비용 관점의 사례는 아님

22. RUM — ✅ 내장된 RUM (Real User Monitoring, 실사용자 모니터링) · ❌ 아직 지원 안 함

23. Pipelines (파이프라인) — ✅ 실시간 / 예약형: 수집 후 변환(transform) / 보강(enrich) / 필터링(filter) / 라우팅(route) 수행 (VRL 사용); 로그 → 메트릭 변환 등 · ❌ 아직 지원 안 함

24. Reports (리포트) — ✅ 예약형 / 캐시된 리포트; 정해진 시간에 생성 및 배포 · ❌ 아직 지원 안 함

공통 기반: 서비스 목록 및 골든 메트릭(golden metrics), 트레이스(Trace) 목록/워터폴(waterfall), 로그, 그리고 Span ↔ 로그 연결. DataBuff는 토폴로지(topology) / 서비스·인스턴스·엔드포인트 호출 분석 / 서비스 흐름 / 미들웨어 페이지 측면에서 앞서 있습니다. OpenObserve는 로그 검색 및 비용, SQL/PromQL, 커스텀 대시보드, 파이프라인(Pipelines), 리포트(Reports), 통합 L/M/T(로그/메트릭/트레이스) + RUM 측면에서 앞서 있습니다.

Alerting (알림)

• Capability (기능) — OpenObserve v0.91.0-rc1 · DataBuff v0.1.4
• How rules are configured (규칙 설정 방식) — ✅ 알림 UI (먼저 목적지/템플릿 설정 필요) · ✅ 제품 내 알림 센터
• Threshold alerts (임계값 알림) — ✅ 예약형 / 실시간 · ✅ 플랫폼 내 관리
• Smart alerts (스마트 알림) — ❌ 이에 상응하는 스마트 알림 제품 없음 · ✅ APM 메트릭과 연동된 스마트 알림
• Alert event list (알림 이벤트 목록) — ✅ 트리거된 알림/규칙을 위한 알림 UI · ✅ 알림 목록 (심각도 / 서비스 / 시간)
• Alerts linked to service / middleware (서비스/미들웨어와 연동된 알림) — △ 스트림 중심 알림; APM 컨텍스트를 수동으로 연결해야 함 · ✅ 알림 목록에서 서비스/미들웨어를 APM으로 다시 연결

두 제품 모두 UI에서 알림을 설정할 수 있습니다. 차이점은 **스마트 알림(smart alerts)**과 알림 → APM 서비스 컨텍스트(alert → APM service context) 연결성입니다. OpenObserve의 알림은 로그/메트릭 스트림에 치중되어 있고, DataBuff는 APM 트리아지(triage, 우선순위 분류) 루프에 치중되어 있습니다.

When to pick which (선택 기준)

• 시나리오 (Scenario) — 더 적합한 선택 · 참고 사항
• 이미 OTLP를 사용 중이며, AI / APM의 깊이를 우선시하는 경우 — DataBuff · 익스포터(exporter)를 DataBuff로 지정하면 되며, 먼저 OpenObserve에서 이전할 필요가 없음
• 7가지 AI 기능이 필요한 경우 — DataBuff · OpenObserve에는 이에 상응하는 AI 플랫폼이 없음
• MCP / Skill 또는 커스텀 디지털 전문가가 필요한 경우 — DataBuff · AI 플랫폼은 확장 가능하지만, OO에는 그러한 계층이 없음
• 전역 토폴로지(topology)와 상태 색상을 한눈에 확인해야 하는 경우 — DataBuff · OO에는 서비스 의존성 토폴로지가 없음
• 엔트리 서비스(entry service)로부터 "누가 응답을 느리게 만들었는가"를 파악해야 하는 경우 — DataBuff · 서비스 흐름(Service flow) + 기여도(contribution) 제공; OO에는 이에 상응하는 페이지가 없음
• 서비스 / 인스턴스 / 엔드포인트 호출 분석 → 트레이스(Trace)가 필요한 경우 — DataBuff · 3단계 호출 분석이 모두 트레이스(Trace)와 연결됨; OO에는 경로(path) 기능이 없음
• 인스턴스 골든 메트릭(golden metrics) / 인스턴스 토폴로지가 필요한 경우 — DataBuff · OO에는 이에 상응하는 인스턴스 페이지가 없음
• 느린 SQL / 캐시 / MQ / 외부 서비스 페이지가 필요한 경우 — DataBuff · OO는 주로 Span 필드를 사용하며, 전용 페이지가 없음
• 전용 에러 분석이 필요한 경우 — DataBuff · OO는 수동으로 ERROR 필터링을 해야 함
• 서비스 / 미들웨어와 연동된 스마트 알림(smart alerts)이 필요한 경우 — DataBuff · OO의 알림은 스트림 지향적이며, 스마트 알림 APM 루프가 없음
• 로그 볼륨이 매우 크고, 오브젝트 스토리지(object-storage) 비용 제어가 필요한 경우 — OpenObserve · 압축 및 스토리지 관련 기능이 강점임
• SQL / PromQL 메트릭(Metrics) + 커스텀 대시보드가 필요한 경우 — OpenObserve · DataBuff는 아직 커스텀 대시보드를 지원하지 않음
• 수집 후 변환 / 강화 / 필터링 / 라우팅(post-ingest transform / enrich / filter / route)이 필요한 경우 — OpenObserve · 파이프라인(Pipelines: 실시간 / 예약형 + VRL) 제공
• 예약형 / 캐시된 보고서가 필요한 경우 — OpenObserve · 보고서(Reports: 예약형 / 캐시형) 제공
• 로그(Logs) + 메트릭(Metrics) + 트레이스(Traces) + RUM의 통합이 필요한 경우 — OpenObserve · DataBuff는 APM의 깊이에 집중함
• 단순히 동일한 데모 트레이스(Demo Trace) 워터폴(waterfall)만 필요한 경우 — 둘 다 가능 · 브랜딩을 위해 이전할 필요 없음

경계(Boundary): OpenObserve의 로그 파이프라인 (log pipelines) / 대시보드 (dashboards) / 파이프라인 (Pipelines) / 보고서 (Reports) / 비용 구조 (cost story)에 깊게 결합되어 있다면 OpenObserve를 유지하는 것이 합리적입니다. DataBuff는 OTLP + 7가지 AI + 토폴로지 (topology) / 호출 분석 (call analysis) / 서비스 흐름 (service flow) / 전용 페이지 (dedicated pages) / 스마트 알림 (smart alerts)에 적합합니다. 대시보드 (Dashboards), 파이프라인 (Pipelines), 보고서 (Reports), 그리고 대규모 로그 비용 (large-scale log cost) 측면은 아직 대등한 역량을 갖추고 있지 않습니다.

2. 스크린샷 증거 (표에 대한 설명)

동일한 실험실 (192.168.50.140)의 스크린샷입니다. 캡션은 기능 행(capability rows)과 매칭됩니다. DataBuff의 AI / 토폴로지 (topology) / 전용 페이지 (dedicated pages) / 알림 (alerts), 그리고 OpenObserve의 로그 (logs) / 트레이스 (Trace) / 메트릭 (Metrics) / 대시보드 진입점 (dashboard entry points)에 집중하십시오.

7가지 AI 기능 (OpenObserve에 상응하는 UI 없음; DataBuff 증거)

DataBuff AI home

DataBuff AI 채팅 홈 및 7가지 기능 항목: See / Squad / Inspect / Diagnose / Repair / Predict / Answer

DataBuff AI chat

DataBuff ① See: service-a checkout / service-b에 대한 실제 질문; AI가 텔레메트리 (telemetry)를 읽음

DataBuff digital experts

DataBuff ② Squad: 디지털 전문가 / 멀티 에이전트 (multi-agent) 항목 (OpenObserve에 상응하는 기능 없음)

개요 및 데이터 평면 (Overview & data plane)

OpenObserve Home

OpenObserve 홈: 스트림 (Streams)≈38 · 이벤트 (Events)≈205K · 수집된 데이터 (Ingested) 96MB → 압축된 데이터 (Compressed) 10.5MB (매트릭스 21행)

OpenObserve Streams

OpenObserve Streams: 통합된 로그(Logs) / 메트릭(Metrics) / 트레이스(Traces) 데이터 플레인(

서비스 및 토폴로지(Services & topology)

DataBuff services

DataBuff 서비스 목록 + 골든 메트릭 차트 (OO 서비스 카탈로그와 비교)

DataBuff topology

DataBuff 글로벌 토폴로지 + 상태 색상 (mysql은 빨간색 표시 가능); OpenObserve는 토폴로지 뷰가 없음

서비스/엔드포인트 호출 분석 + 서비스 흐름(Service / endpoint call analysis + service flow) (매트릭스 행 4 / 9 / 10)

OpenObserve는 트레이스(Trace) / 스팬(Span)을 나열할 수 있지만, 서비스/인스턴스/엔드포인트 호출 분석 기능이 없고, 서비스 흐름 기여도 뷰가 없습니다. DataBuff는