OpenTelemetry 이벤트 vs. New Relic 맞춤 이벤트: 기능, 맥락, 그리고 ‘왜’

Source: Dev.to

현대적인 가시성은 단순히 로그와 트레이스에 국한되지 않는다; 행동 가능한 신호에 관한 것이다. OpenTelemetry (OTel) Events와 New Relic Custom Events는 모두 이벤트 기반 신호이지만, 해결하는 문제가 다르다. 각각의 “왜”는 데이터를 누가 소비하고 어떤 결정을 가능하게 하는가에 달려 있다.

팀이 AI 기반 서비스, LLM 파이프라인, 복잡한 분산 아키텍처를 도입함에 따라 신호의 양은 기하급수적으로 증가한다. 어떤 이벤트 메커니즘을 언제 사용해야 하는지는 사고에 대응하는 팀과 시스템을 사전에 개선하는 팀을 가르는 차이가 된다.

Why This Matters

신호가 디버깅에만 유용하다면, 제품 및 AI 팀은 중요한 인사이트를 놓치게 된다. 신호가 분석에만 유용하다면, 엔지니어는 진단 흔적을 잃게 된다. 최고의 팀은 두 가지를 모두 수행한다:

• OTel Events → 트레이스에 연결된 정밀 진단(로그) 컨텍스트
• New Relic Custom Events → 대시보드, 알림, 모델 평가를 구동하는 분석‑준비 신호

예를 들어, LLM 기반 챗봇이 낮은 품질의 답변을 반환하기 시작했다고 가정한다. 엔지니어링 팀은 루트 원인을 찾기 위해 트레이스 수준의 상세 정보가 필요하다(느린 임베딩 조회? 잘못된 프롬프트 템플릿?). 반면 제품 팀은 모델 버전을 롤백할지 결정하기 위해 집계된 품질 점수가 필요하다. 이는 근본적으로 다른 질문이며, 근본적으로 다른 이벤트 타입으로 답한다.

이러한 구분을 이해하는 것이 “우리는 디버깅할 수 있다”와 “우리는 개선할 수 있다” 사이의 차이를 만든다.

OpenTelemetry Events: The “Why”

OpenTelemetry Events는 OTel Events 사양에 정의된 의미 있는 이름을 가진 구조화된 로그로 이해하면 된다. 목적은 트레이스와 타임라인을 풍부하게 하여 엔지니어가 무엇이 일어났고 왜 일어났는지 진단할 수 있게 하는 것이다. 일반 로그 라인과 달리 OTel Events는 명확한 스키마, 의미 있는 이벤트 이름, 그리고 활성 트레이스와 스팬에 대한 자동 연관성을 제공하므로 사고 조사 시 훨씬 유용하다.

Why use OTel Events?

• 벤더 중립성 – 한 번 계측하면 New Relic, Jaeger 등 어떤 백엔드에도 내보낼 수 있다. 독점 SDK에 얽매이지 않는다.
• 풍부하고 구조화된 컨텍스트 – 모든 이벤트는 자유 형식 텍스트가 아닌 타입이 지정된 키‑값 속성을 포함해 정밀한 필터링과 집계가 가능하다.
• 트레이스 연관 – 이벤트는 자동으로 trace.id와 span.id에 연결돼 요청 라이프사이클의 어느 지점에서 발생했는지 정확히 파악할 수 있다.
• 디버깅 및 근본 원인 분석 – 문제가 발생했을 때 OTel Events는 인과 사슬 전체를 재구성할 수 있는 빵 부스러기를 제공한다.

Capabilities

OTel Events는 event.name 속성이 설정된 LogRecord 엔트리로 구현된다. 이는 표준 OTel 로깅 파이프라인을 통해 흐르고, OTel 호환 컬렉터라면 어디서든 수집할 수 있다.

Example: OTel Event as a LogRecord (Python)

import uuid

if feedback not in ['positive', 'negative']:
    return jsonify({
        'success': False,
        'error': 'feedback must be either "positive" or "negative"'
}), 400

# Map feedback to rating (1 for positive/thumbs up, 0 for negative/thumbs down)
rating = 1 if feedback == 'positive' else 0

logger.info("[llm_feedback]", extra={
   "rating": rating,
   "category": feedback,
   "feedback.id": str(uuid.uuid4()),
   "vendor": "openai",
   "model": "gpt-4o",
   "event.name": "LlmFeedbackMessage",
   "prompt.tokens": prompt_tokens,
   "completion.tokens": completion_tokens,
})

trace.id와 span.id가 포함되어 있기 때문에, 이 이벤트는 이후 어떤 OTel‑호환 백엔드에서도 전체 분산 트레이스와 함께 조회할 수 있어 피드백을 둘러싼 정확한 요청 컨텍스트를 제공한다.

New Relic Custom Events: The “Why”

New Relic Custom Events는 비즈니스 및 AI 신호를 관측 플랫폼에서 일급 객체로 만들기 위해 존재한다. 중요한 메트릭을 로그 라인 안에 숨기는 대신, Custom Events는 전용 쿼리 가능한 이벤트 타입으로 승격돼 대시보드, 비교, 알림, 자동 평가를 구동한다.

Custom Events를 데이터 테이블에 비유하면 된다. 각 이벤트 타입(LlmFeedbackMessage, OrderCompleted, ModelEvaluation 등)은 NRDB(New Relic Database) 내 자체 쿼리 가능한 테이블이 되며, 빠른 집계와 시계열 분석에 최적화된다.

Why use Custom Events?

• 빠른 분석 및 트렌드 파악 – 컬럼형 포맷에 저장돼 집계에 최적화된다. 원시 로그에 비해 밀리초 단위로 결과를 반환한다.
• NRQL 기반 대시보드 – 전체 NRQL 지원을 통해 실시간 대시보드 구축이 가능하며, 파싯된 분류, 퍼센타일, 히스토그램, 시계열 비교 등을 수행한다.
• 알림 – Custom Event 데이터에 직접 NRQL 알림 조건을 설정할 수 있다(예: average(quality.score)가 임계값 이하로 떨어질 때 알림).
• AI 및 모델 평가 – 품질 점수, 토큰 사용량, 레이턴시, 사용자 피드백을 모델 버전별로 추적해 롤백·프로모션 결정을 지원한다.
• 보존 유연성 – 기본 30일 보존(확장 가능)으로 로그 보존 정책과 별개로 관리한다.

Capabilities

Example: Emit a New Relic Custom Event via OTel LogRecord

핵심 인사이트는 Custom Event를 만들기 위해 New Relic 전용 SDK가 필요 없다는 것이다. 이미 OTel 데이터를 New Relic에 전송하고 있다면, LogRecord에 하나의 속성만 추가하면 Custom Event로 승격할 수 있다:

newrelic.event.type=

예를 들어, newrelic.event.type=MyEvent 속성을 가진 LogRecord는 type=MyEvent인 Custom Event로 수집된다.

Python 예시:

logger.info("[model_evaluation]", extra={
   "newrelic.event.type": "ModelEvaluation",
   "model.name": "gpt-4o",
   "model.version": "2026-02-01",
   "quality.score": 0.87,
   "latency.ms": 1230,
   "prompt.tokens": 512,
   "completion.tokens": 256,
   "evaluation.method": "cosine_similarity",
   "environment": "production",
})

이 이벤트는 이제 NRQL로 조회 가능하다:

SELECT average(quality.score), percentile(latency.ms, 95)
FROM ModelEvaluation
WHERE model.name = 'gpt-4o'
SINCE 1 day ago
TIMESERIES

Practical “Why” Scenarios

Scenario 1: Debugging a Bad Response

사용