대시보드가 빈 이유를 수집 단계별로 찾습니다

9월 초에는 Grafana Beyla의 eBPF 계측, Alloy 수집, Mimir 메트릭 저장, Tempo trace 저장을 연결해 확인했습니다. 애플리케이션의 요청이 보이지 않을 때 수집기가 실행 중이라는 사실만으로 전체 경로가 정상이라고 판단하지 않습니다.

Beyla가 만든 OTLP 데이터를 Alloy에서 받아 신호별로 내보냅니다. 아래 Alloy 설정은 문법과 분기 구조를 보여주는 축약 예제입니다. example.invalid 주소는 접속 가능한 운영 endpoint가 아니며 TLS, 인증, batch 처리와 resource 정규화는 생략했습니다.

RIVER
otelcol.receiver.otlp "example" {
  grpc {
    endpoint = "0.0.0.0:4317"
  }
  output {
    metrics = [otelcol.exporter.prometheus.example.input]
    traces  = [otelcol.exporter.otlp.example.input]
  }
}

otelcol.exporter.prometheus "example" {
  forward_to = [prometheus.remote_write.example.receiver]
}

prometheus.remote_write "example" {
  endpoint {
    url = "https://metrics.example.invalid/api/v1/push"
  }
}

otelcol.exporter.otlp "example" {
  client {
    endpoint = "traces.example.invalid:443"
  }
}

메트릭은 Prometheus 형식으로 변환한 뒤 remote_write로 Mimir에 보냅니다. trace는 OTLP exporter로 Tempo에 보냅니다. 운영 구성에는 필요한 인증과 네트워크 경계를 추가하고 OTLP receiver를 무인증 공개 endpoint로 노출하지 않습니다.

accepted와 exported를 다른 증거로 확인합니다

receiver가 데이터를 받았지만 exporter가 전송하지 못할 수 있습니다. Alloy component 상태와 수신·거절·전송 실패 메트릭을 확인하고, Mimir에서 HTTP 시계열을 조회하고 Tempo에서 해당 서비스의 trace를 검색했습니다. 전송 대기나 재시도가 있는 경우에는 수집기 로그와 backend 응답을 같이 봅니다.

service.name과 service.namespace를 정리해 Mimir의 경보와 Tempo의 검색이 같은 서비스를 가리키게 했습니다. collector의 노드 이름을 애플리케이션 인스턴스 식별자로 덮어쓰지 않도록 metadata도 구분했습니다.

Sloth SLO와 Grafana 조사 경로를 연결합니다

Sloth로 생성한 SLO 규칙과 Grafana 알림에 dashboard, runbook, Tempo 조사 링크를 연결했습니다. 실제 경보 판정은 메트릭으로 수행하고 trace는 원인을 조사하는 데 사용합니다. trace 보존 범위나 샘플링이 달라질 수 있으므로 trace 검색 결과를 전체 요청 수처럼 사용하지 않습니다.

검증에서는 렌더링한 규칙, 수집 component 상태, backend에서의 실제 조회를 각각 확인했습니다. 경보가 조용한 상태와 계측이 없는 상태를 구분할 수 있도록 수집 범위도 함께 기록했습니다. 설정의 각 속성과 블록은 Alloy 문법에 따라 줄바꿈으로 구분합니다.