OpenTelemetry 도입 과정

Kubernetes 도입 이후 서비스들이 MSA로 빠르게 전환되면서 서비스 간 연결이 복잡해졌고, Filebeat와 Metricbeat로 파편화해 수집하던 방식으로는 CS 분석이 어려워졌다. 이를 해결하기 위해 사실상 관측 가능성의 표준으로 자리 잡은 OpenTelemetry 도입을 검토했고, 사람인의 적용 사례를 참고해 운영 환경에 맞게 구성했다.

OpenTelemetry Operator는 Kubernetes의 MutatingWebhookConfiguration과 ValidatingWebhookConfiguration을 활용해 Pod에 Instrumentation을 주입하고, OpenTelemetryCollector와 Instrumentation CRD의 유효성을 검증한다. 설치는 opentelemetry-operator Helm Chart 0.105.1로 진행했으며, Pod 생성·업데이트 시 동작하는 Dynamic Admission Control 특성상 TLS 인증서가 필요해 cert-manager 설치도 권장했다.

Collector는 벤더에 종속되지 않고 원격 측정 데이터를 통합 수집·처리·전송하는 중심 구성요소로 사용했다. 배포판은 otelcol-k8s를 기준으로 잡았고, 파이프라인은 다음처럼 구성했다.

• Receivers: otlp, filelog, hostmetrics, k8s_cluster, k8sobjects, kubeletstats
• Processors: memory_limiter, k8sattributes, filter, transform
• Exporter: otlp_grpc로 Gateway Collector 전송
• Mode: 노드 단위 메트릭과 파일 로그 수집을 위해 daemonset

RBAC도 함께 설정했다. ServiceAccount를 만들고, k8sclusterreceiver, k8sobjectsreceiver, kubeletstatsreceiver, k8sattributesprocessor가 요구하는 권한을 반영한 ClusterRole과 ClusterRoleBinding을 연결한 뒤 Collector에 serviceAccount를 지정해 배포를 완료했다.

애플리케이션 계측은 Instrumentation CRD 하나로 통합했다. exporter endpoint를 http://otel-collector.otel-namespace.svc:4317로 지정하고, propagators는 tracecontext와 baggage, sampler는 parentbased_traceidratio에 "1"을 사용했다. 이후 Deployment에는 instrumentation.opentelemetry.io/inject-java: otel-namespace/instrumentation 어노테이션만 추가하면 자동 계측이 적용되도록 했다.

기본 도입은 끝났지만, 파일 오프셋과 exporter 큐가 메모리에만 남는 구조는 Collector 재시작이나 네트워크 장애 시 데이터 유실 위험이 있었다. 이를 보완하기 위해 File Storage Extension을 도입해 저장 공간을 디스크로 전환하고, 장애 상황에서도 데이터 지속성과 무결성을 높이는 방향으로 개선을 이어갔다.