본문으로 건너뛰기

OpenTelemetry

OpenTelemetry 수집기는 Lumie 텔레메트리 파이프라인의 중심입니다. DaemonSet으로 실행되며 다음 세 가지 일을 동시에 처리합니다.

  • 계측된 서비스에서 OTLP 텔레메트리 수신
  • ServiceMonitor와 PodMonitor 리소스에서 발견한 메트릭 대상을 스크레이프
  • 노드 파일시스템에서 컨테이너 로그 따라 읽기

소스 경로​

  • lumie-infra/observability/opentelemetry/argocd.yaml
  • lumie-infra/observability/opentelemetry/kustomization.yaml
  • lumie-infra/observability/opentelemetry/manifests/collector.yaml
  • lumie-infra/observability/opentelemetry/manifests/targetallocator-rbac.yaml

런타임 흐름​

수집기 계약​

  • 모드: daemonset
  • 호스트 포트:
    • OTLP gRPC용 4317
    • OTLP HTTP용 4318
  • hostPath 마운트:
    • /var/log/pods
    • /var/lib/docker/containers
  • exporter:
    • otlphttp/prometheus
    • otlphttp/loki
    • otlp/tempo

왜 중요한가​

Lumie의 스크레이프 모델은 수집기를 먼저 거칩니다.

  • prometheus.receiver.target_allocator가 ServiceMonitor와 PodMonitor 정의를 읽습니다.
  • Prometheus 자체는 scrape-by: prometheus-only 라벨에만 매칭되도록 구성되어 있습니다.
  • 따라서 대부분의 워크로드 메트릭은 target -> collector -> Prometheus OTLP receiver 경로를 따르며, target -> Prometheus로 직접 가지 않습니다.

로그 파이프라인​

filelog 수신기는 Docker 스타일 JSON 로그와 containerd 로그를 구분하고, 파일 경로에서 namespace, pod, container, pod UID를 추출하며, Loki용 라벨 힌트를 붙입니다. 즉, Loki 쿼리 라벨은 별도 Promtail 배포가 아니라 수집기의 파싱 결과에 의존합니다.

장애 지점​

  • 수집기 DaemonSet이 비정상이면 메트릭, 로그, 트레이스가 모두 함께 저하될 수 있습니다.
  • Target Allocator RBAC가 깨지면 수집기는 계속 실행되지만 스크레이프 대상을 더 이상 발견하지 못합니다.
  • 노드 로그 마운트가 바뀌면 filelog 수신기가 컨테이너 로그를 조용히 잃습니다.
  • 호스트 포트 4317 또는 4318이 막히면 앱 계측은 로컬에서 정상처럼 보여도 하류에는 아무것도 도착하지 않습니다.

검증​

kubectl get applications.argoproj.io -n argocd opentelemetry
kubectl get opentelemetrycollectors.opentelemetry.io -n opentelemetry
kubectl get pods -n opentelemetry
kubectl logs -n opentelemetry daemonset/otel-collector-collector --tail=200
kubectl get clusterrole,clusterrolebinding | rg 'otel-collector|otel-targetallocator'

관련 페이지​