컬렉터 설정 파일 한 벌 완성하기

목표

프로덕션에 올릴 수 있는 컬렉터 설정 파일 한 벌을 처음부터 끝까지 작성합니다. 끝나면 남의 컬렉터 설정을 보고 프로세서 순서만으로 어떤 사고가 날지 예측할 수 있습니다.

왜 중요한가

컬렉터 설정은 YAML 한 줄만 어긋나도 프로세스가 기동하지 못하는데, 문제는 그 사실을 대부분 클러스터에서 CrashLoopBackOff 를 본 뒤에야 알게 된다는 점입니다. 더 나쁜 것은 기동은 하는데 조용히 틀린 설정입니다. memory_limiter 를 뒤에 두면 평소에는 아무 문제가 없다가 부하가 올 때만 OOM 으로 죽고, batch 를 tail_sampling 앞에 두면 트레이스가 무작위로 잘리는데 지표는 아무 이상도 보고하지 않습니다. 컴포넌트를 정의만 하고 service 에 올리지 않으면 설정 파일에는 있는데 동작은 하지 않습니다. 이 세 가지가 컬렉터 사고의 대부분이고, 셋 다 설정 파일을 읽는 것만으로 잡을 수 있습니다.

단계

1. /root/otca-collector/config.yaml 을 만들고 receivers.otlp.protocols 아래 grpc.endpoint: 0.0.0.0:4317 과 http.endpoint: 0.0.0.0:4318 을 씁니다.
2. processors.memory_limiter 에 check_interval: 1s, limit_mib: 1638, spike_limit_mib: 328 을 씁니다. (컨테이너 메모리 한도 2Gi 기준)
3. processors.k8sattributes 에 auth_type: serviceAccount 를 쓰고 extract.metadata 에 k8s.namespace.name, k8s.deployment.name, k8s.pod.name, k8s.node.name 네 개를 넣습니다.
4. processors 에 attributes/redact 를 만들고 actions 에 세 개를 넣습니다. http.request.header.authorization 은 delete, user.email 은 delete, db.query.text 는 hash.
5. processors.batch 에 timeout: 5s, send_batch_size: 8192, send_batch_max_size: 16384 를 씁니다.
6. exporters 에 세 개를 정의합니다. otlp/tempo 는 endpoint 에 4317 포트를 가진 주소, otlp/gateway 도 4317 포트를 가진 주소, prometheusremotewrite 는 /api/v1/push 로 끝나는 http URL 에 sending_queue(enabled: true, num_consumers: 10, queue_size: 5000)와 retry_on_failure(enabled: true, initial_interval: 5s, max_elapsed_time: 300s)를 붙입니다.
7. extensions 에 health_check.endpoint: 0.0.0.0:13133 과 zpages.endpoint: 0.0.0.0:55679 를 정의하고, service.extensions 에 두 이름을 모두 올립니다.
8. service.pipelines 에 세 파이프라인을 씁니다. traces 는 프로세서 [memory_limiter, k8sattributes, attributes/redact, batch] 에 익스포터 [otlp/tempo], metrics 는 [memory_limiter, k8sattributes, batch] 에 [prometheusremotewrite], logs 는 [memory_limiter, k8sattributes, attributes/redact, batch] 에 [otlp/gateway]. 세 파이프라인 모두 리시버는 [otlp] 입니다.

참고

• attributes/redact 처럼 슬래시를 붙인 이름은 같은 타입의 두 번째 인스턴스를 뜻합니다. YAML 키에 슬래시가 들어가므로 참조할 때 이름을 정확히 맞추세요.
• 흔한 실수 1: 컴포넌트를 정의만 하고 service 에 올리지 않는 것. 확장도 마찬가지입니다.
• 흔한 실수 2: send_batch_max_size 를 빠뜨리는 것. send_batch_size 는 트리거일 뿐입니다.
• 흔한 실수 3: attributes/redact 를 k8sattributes 앞에 두는 것. 새로 붙는 속성이 삭제를 빠져나갑니다.

단계 8개

1. OTLP 리시버 두 포트
2. memory_limiter 값 산정
3. 쿠버네티스 메타데이터 부착
4. 민감 속성 삭제와 해싱
5. batch 트리거와 상한
6. 익스포터 세 개와 큐·재시도
7. health_check 와 zpages
8. 파이프라인 세 개와 프로세서 순서