로그·메트릭·트레이스 말고 와이드 이벤트 — 필드를 다 넣어 두면 모르는 문제도 쪼개서 찾는다

메타(Meta) 출신 엔지니어 이반 부르미스트로프(Ivan Burmistrov)가 2024년 2월에 쓴 글이에요. 관측성(observability)을 "로그·메트릭·트레이스" 세 갈래로 나눠 가르치는 방식이 오히려 사람들을 헷갈리게 한다고 비판해요.

• OpenTelemetry 비판: 셋을 서로 다른 개념처럼 소개하고 용어집만 60개가 넘어서, 관측성이 실제보다 어렵게 느껴진다고 해요.
• 대안은 Scuba: 메타 사내 도구 Scuba는 "와이드 이벤트" 하나로 모든 걸 처리하는데, 퇴사자들이 가장 그리워하는 도구라고 해요.
• 세 갈래는 특수한 경우일 뿐: 로그·메트릭·트레이스는 모두 와이드 이벤트의 특수한 형태라고 봐요.

와이드 이벤트란 일이 하나 일어날 때마다 관련 정보를 최대한 많이 넣어 한 줄로 남기는 JSON 같은 기록이에요. 예를 들어 광고가 한 번 노출될 때마다 아래 필드를 모두 담은 이벤트 하나를 남겨요.

• 시각, 광고 ID
• 사용자 국가, OS, OS 버전, 앱 버전
• 노출 위치, 캠페인 유형

"넓다(wide)"고 부르는 건 지금 당장 쓸지 모르는 필드까지 일단 다 넣기 때문이에요. 미리 예상하지 못한 문제(unknown unknowns)를 나중에 캐내기 위해서예요.

어떻게 쓰나: 기사의 예시는 이래요. 광고 노출 그래프가 이상하다는 알림이 오면, 시스템을 잘 몰라도 그룹별로 쪼개 보면서 범위를 좁혀 가요.

1. 캠페인 유형별로 쪼개면 특정 유형만 이상해요.
2. 그 유형 안에서 OS별로 쪼개면 Android만 문제예요.
3. 다시 OS 버전·앱 버전별로 쪼개면 최신 OS에서 특정 앱 버전만 문제라는 게 드러나요.

이런 조합을 위한 메트릭을 미리 만들어 둘 수는 없죠. 원본 이벤트를 집계하지 않고 그대로 저장하니까, 필드에 값이 아무리 다양해도(카디널리티가 높아도) 문제가 되지 않아요.

세 갈래와의 관계

• 트레이스: TraceId·SpanId·ParentSpanId 필드를 가진 와이드 이벤트예요.
• 로그: 로그 메시지를 필드 하나에 넣고 메타데이터를 덧붙이면 돼요.
• 메트릭: 일정한 간격마다 시스템 상태를 이벤트로 남기면 돼요.

저자는 OpenTelemetry의 span이 와이드 이벤트에 가장 가까운 개념이라고 봐요. 이 방향을 따르는 상용 도구로는 Honeycomb과 Axiom을 꼽았어요.

출처: 원문 · Honeycomb · OpenTelemetry 용어집