Introduction
Kubernetes 내 Metric, Logs, Traces(MLT) pipelines를 OpenTelemetry Collector로 교체하는 방법, 특히 각 signal 관점에서 어떻게 OpenTelemetry Collector workload를 나눌지에 대해 논한다.
OpenTelemetry의 사용자 관점 Overview, OpenTelemetry 설치 준비: Operator 설치, OpenTelemetry Collector로 Prometheus (scraper) 교체하기 의 연장선 상에 위치한 OpenTelemetry Collector의 상세 검토 중 하나이다.예제 코드는 버전으로 따지면 alpha 수준으로 글과 함께 지속 업데이트 예정이다. 완료 시 본 callout은 제거 예정이다.
Motivation
OpenTelemetry Collector는 일반적으로 보이는 아키텍처 그림과는 달리 다수의 workload로 나누어야 하는데, 이는 무엇보다 OTel receiver, 즉 signal 종류가 workload 형식, 즉 배포 패턴(e.g. Deployment, DaemonSet)을 사실 상 규정하기 때문이다. 그렇다고 receiver 종류 별로 workload를 나누기에는 그 종류가 너무도 많다. 결국에는 이들에 대한 분류가 요구된다.
조직 관점 분류 방법에 대하여
운영 조직 관점으로도 나누는 것을 고려해볼 수 있지만, signal 자체가 운영 조직 별 분리를 반영하기 어려운 경우가 더 많을 뿐 아니라 OpenTelemetry 이전의 pipeline에서도 이와 같은 분리를 찾기는 어려울 듯 예상된다.
Collectors
다행히도 receiver 이외에 타 OpenTelemetry component는 workload 형식에 대한 제한이 없다. 또한 유지보수성을 고려하자면 workload는 적을 수록 좋다. 따라서 최소 workload 분류 단위인 workload 형식 별로 나누는 것을 고려한다. 참고로, OpenTelemetry Collector는 Deployment, DaemonSet, StatefulSet 이외에도 sidecar 형식의 배포 패턴으로 지원한다(공식 문서는 DaemonSet과 sidecar를 Agent로, 이외를 Gateway로 표현하며 receiver 수준에서야 구체적인 형식을 논한다).
아래는 위 관점에 따라 분류한 결과(우측)와 각각에 해당하는 OpenTelemetry 사용 전의 MLT 수집기를 나타낸다. 실선은 OTel 적용 전에도 사용되는 signal에 대한 관계를, 점선은 OTel 적용 후에 추가 가능한 경우를 나타낸다. 참고로 trace의 경우 OTel 전에는 Trace backend로 signal을 직접 보내는 것이 일반적이라 예상된다.
OpenTelemetry Collector 적용 전 components와 적용 후의 collectors 간 관계. Collector 명칭은 직관성을 위해 workload 형식이 아닌 signal의 공통 속성에서 추출
보다시피 OpenTelemetry Collector의 사용 결과, MLT에 대한 일관된 관리의 장점 뿐 아니라 최소 7개의 workload를 4개로 줄일 수 있다(물론, workload 별 부하는 더욱 커질 것이므로 이에 대한 적절한 resource 추가 할당이 필요하겠다).
아래 각 Collector에 대한 설명과 예제 코드로, 해당 collector가 담당하는 각 signal의 종류를 log, metric, trace 로 표현했다. Signal backends로는 Prometheus, Elasticsearch, Jaeger를 상정했다.
Node Collector
공식 문서에서 DaemonSet 을 권장하는 receiver가 모인 collector이다.
log | Filelog
수집 대상은 stdout/stderr로 생성된 Kubernetes, apps log으로, 사실 상 Fluentbit를 대체한다. 이를 위해 log scraping 및 전달 뿐 아니라 Processors 에서 언급한 다양한 processor 사용을 고려해야 한다.
•
•
metric | Kubelet Stats
node, pod, container, volume, filesystem network I/O and error metrics 등 CPU, memory 등 infra resource에 관한 metric을 다루어, 각 노드의 kubelet이 노출하는 API에서 추출한다. 사실 상 cAdvisor의 대체이다.
•
•
metric | Host Metrics
수집 대상은 node (cpu, disk, CPU load, filesystem, memory, network, paging, process..)의 metric으로, 사실 상 Prometheus Node Exporter를 대체한다. Kubelet Stats Receiver와 일부 항목이 겹치므로 동시 운용 시 중복 처리가 필요하다.
•
•
예제 코드(Filelog , Host Metrics 미완료)
Cluster Collector
단일 replica 사용 권장인 receivers 대상으로, 이들 receiver는 2개 이상의 instance 사용 시 중복이 발생 가능하기 때문이라고 공식 문서에서 논한다. 두 receiver 모두 cluster 관점에서 추출하기 때문이라고. 이에 따라 deployment type에 1개의 replica로 설정한다.
log | Kubernetes Objects
주로 Kubernetes event 수집용으로 Kubernetes API server 출처의 objects(전체 목록은 kubectl api-resources 로 확인) 수집에도 사용한다.
•
•
metric | Kubernetes Cluster
•
•
예제 코드
Prometheus Collector
Istio를 포함한 기존 동적 Prometheus metric scraping이 설정된 metric 대상의 collector이다. 이에 대해서는OpenTelemetry Collector로 Prometheus (scraper) 교체하기 에서 자세히 다룬다.
OpenTelemetry Collector로 Prometheus (scraper) 교체하기 에서 자세히 다룬다.OTLP Collector
공용 receiver, exporter 공통적으로 otlp 프로토콜을 사용하고 replica 개수 제약이 없는 signal 대상 collector로서, 제약이 없을 경우 가장 운용에 유리한 배포 패턴인 Deployment 를 사용한다. MLT 모두를 대상으로 한다.
trace | Generic OTEL trace
•
•
metric | Generic OTEL metric
앞서 논한 metric 이외의 app level metrics 등의 여타 metric 수집을 위한 endpoint이다.
•
•
log | Generic OTEL log
Istio의 OTel access log를 포함한 여타 log 수집을 위한 endpoint이다.
•
•