Telegraf, InfluxDB, Grafana, Kubernetes 모니터링 파이프라인의 평면 배치
글 요약
Telegraf + InfluxDB + Grafana 조합으로 Kubernetes와 ECS 환경의 메트릭을 안정적으로 수집하는 아키텍처를 정리합니다. 실시간 대시보드, 알람, 리소스 최적화까지 한 번에 끝낼 수 있거든요.
“Prometheus는 좋은 줄 알았는데, 카디널리티 폭발로 TSDB가 터졌어요.”
Telegraf + InfluxDB + Grafana 조합으로 전환하면 시계열 데이터의 압축 효율, 장기 보관, 멀티 클라우드 통합 메트릭 수집을 한꺼번에 해결할 수 있습니다. 이 글에서는 구성 절차, 흔한 실수, 대안 비교까지 모두 다뤄봅니다.
컨테이너 오케스트레이션 환경에서 메트릭 수집은 단순히 “데이터를 모으는 것”이 아니라 “운영 비용을 좌우하는 결정”이거든요. 잘못된 에이전트 선택 하나가 월 수백만 원의 클라우드 비용을 만들어내고, 반대로 잘 짜여진 파이프라인은 장애를 5분 전에 감지해 냅니다. 많은 엔지니어가 처음에 Telegraf의 다양한 input plugin을 무시한 채 cpu·memory만 수집하고는 더라고요.
📑 목차
1. Telegraf + InfluxDB + Grafana 구조 이해
2. Kubernetes 환경 구성 방법
3. ECS 환경 구성 방법
4. 메트릭 수집 노하우와 실패 사례
5. Prometheus·Datadog 등 다른 솔루션과 비교
6. 운영 최적화와 장기 보관 전략
7. 자주 묻는 질문
📌 이 글의 핵심 정리
- Telegraf는 200개 이상의 input plugin을 가진 경량 메트릭 에이전트로, K8s·ECS·클라우드 서비스 메트릭을 단일 바이너리로 수집합니다.
- InfluxDB는 시계열 전용 압축 엔진을 통해 high cardinality 데이터의 저장 비용을 최대 90%까지 절감합니다.
- Kubernetes에서는 DaemonSet으로, ECS에서는 Sidecar 또는 전용 Task 패턴으로 배포하는 것이 표준 아키텍처입니다.
- 흔한 실패 사례는 태그 라벨의 카디널리티 폭발이며, 이는 Telegraf의 tagdrop와 fielddrop 필터로 사전 차단해야 합니다.
- Prometheus 대비 장기 보관·푸시 모델이 강점이고, Datadog 대비 자체 호스팅 비용 효율성이 강점입니다.
1. Telegraf + InfluxDB + Grafana 구조 이해
이 조합은 각각의 역할이 명확하게 분리되어 있습니다. Telegraf는 수집, InfluxDB는 저장, Grafana는 시각화와 알람을 담당합니다. 흔히 TIG 스택이라 부르는데, ELK 스택과 유사한 관측 가능성(observability) 파이프라인의 대표 조합이거든요.
Telegraf의 핵심 역할
Telegraf는 Go로 작성된 단일 바이너리 에이전트입니다. 200개 이상의 input plugin이 내장되어 있어서 Kubernetes API, AWS ECS Task 메타데이터, CloudWatch, Kafka, MySQL, HTTP endpoint 등을 별도 개발 없이 바로 수집할 수 있습니다. 설정 파일만 바꾸면 같은 에이전트를 다른 용도로 재사용할 수 있어 운영 부담이 확 줄어듭니다.
InfluxDB의 핵심 역할
InfluxDB는 시계열 데이터에 특화된 TSDB입니다. TSM(Time-Structured Merge Tree) 엔진과 TSI(Time-Structured Index) 엔진을 통해 데이터를 블록 단위로 압축 저장합니다. 같은 CPU·Memory 메트릭이라도 Prometheus 대비 디스크 사용량이 5~10배 적게 나오는 경우를 실제로 많이 봤거든요.
Grafana의 핵심 역할
Grafana는 InfluxDB뿐 아니라 Prometheus, Loki, Elasticsearch 등 다양한 데이터 소스를 한 대시보드에서 합쳐 보여줍니다. 멀티 클라우드 환경에서 K8s와 ECS 메트릭을 단일 화면에 띄울 수 있는 게 가장 큰 장점이더라고요.
2. Kubernetes 환경 구성 방법
Kubernetes 환경에서 Telegraf를 배포하는 표준 패턴은 DaemonSet입니다. 모든 노드에 Pod 1개씩 떠 있게 해서 kubelet API, /metrics 엔드포인트, 호스트의 네트워크·디스크 메트릭을 한 번에 수집합니다.
필수 input plugin
- inputs.kubernetes: Pod, Deployment, Service 리소스 메타데이터 수집
- inputs.kube_inventory: 클러스터의 모든 오브젝트 메트릭화
- inputs.prometheus: 같은 Pod 내 application exporter scrape
- inputs.net: 노드 인터페이스 트래픽
- inputs.disk: 노드 디스크 사용량
권장 배포 구성
Telegraf Pod에는 보통 hostPath로 /proc, /sys, /var/lib/docker를 마운트합니다. 그래야 노드 단위 cgroup 메트릭을 정확히 읽을 수 있거든요. RBAC은 ServiceAccount에 cluster-wide read 권한을 부여해서 모든 네임스페이스의 Pod 상태를 수집할 수 있게 합니다.
⚠️ Kubernetes Telegraf 주의
- kubelet API는 /metrics/cadvisor가 deprecated 되었으므로 /metrics/resource 엔드포인트를 명시적으로 호출하세요.
- Pod 이름 같은 고유 태그를 그대로 메트릭 라벨로 사용하면 시계열이 노드 수 × Pod 수만큼 폭증합니다.
3. ECS 환경 구성 방법
ECS에서는 K8s와 달리 노드라는 개념이 약해서, 보통 두 가지 패턴 중 하나를 선택합니다. Sidecar 패턴은 Application Task 안에 Telegraf 컨테이너를 함께 띄우는 방식이고, 전용 Task 패턴은 별도의 Daemon-like ECS Service로 운영하는 방식입니다.
Sidecar 패턴의 장단점
장점은 Task 단위로 메트릭을 명확히 분리할 수 있다는 점이고, 단점은 Application Task가 늘어날 때마다 Telegraf 인스턴스도 같이 늘어난다는 거예요. 그래서 소수의 큰 컨테이너보다는 다수의 작은 마이크로서비스에는 overhead가 됩니다.
전용 Task 패턴
EC2 launch type에서 ECS_CONTAINER_METADATA_URI_V4 환경변수를 활용하면 모든 Task의 메트릭을 단일 Telegraf 인스턴스가 수집할 수 있습니다. Fargate에서는 불가능하지만 EC2에서는 가장 효율적인 구성이거든요.
AWS API 직접 수집
Telegraf의 inputs.cloudwatch와 inputs.ecs plugin을 활성화하면 CloudWatch API로 더 깊은 인프라 메트릭까지 캡처할 수 있습니다. 이때 IAM Role에 cloudwatch:GetMetricData 권한을 꼭 부여해야 합니다.
4. 메트릭 수집 노하우와 실패 사례
실무에서 자주 마주치는 실패 사례를 하나 공유할게요. 어느 팀에서 K8s DaemonSet으로 Telegraf를 띄웠는데, 2주 만에 InfluxDB 디스크가 1.2TB로 폭증한 적이 있었습니다. 원인은 kubernetes_pod_name 태그가 자동으로 모든 메트릭에 붙으면서, 노드 50개 × Pod 300개의 조합이 시계열 수를 기하급수적으로 늘린 거였어요.
실패 원인 분석
Telegraf의 tagdrop 프로세서를 설정하지 않으면 모든 Kubernetes 메타데이터가 태그로 변환됩니다. Pod 이름, 컨테이너 이미지 다이제스트, deployment revision 같은 고유값들이 메트릭 라벨에 그대로 들어가서 카디널리티가 폭발했어요. 모니터링 시스템이 모니터링 데이터에 잡아먹히는 아이러니한 상황이 발생한 거죠.
해결 노하우
해결책은 3가지 레이어로 구성했습니다. 첫째, telegraf.conf의 global_tags에서 cluster_name과 region만 남기고 나머지를 제거합니다. 둘째, processors.tagdrop로 container_id, pod_ip 같은 ephemeral 태그를 사전 필터링합니다. 셋째, InfluxDB bucket의 tag retention policy에서 불필요한 태그 키를 강제로 만료시켰습니다.
💡 카디널리티 차단 꿀팁
- 수집 시작 전에 SHOW TAG KEYS 명령으로 태그 카디널리티를 미리 측정하세요.
- 태그로 쓸지 필드로 쓸지 기준은 “이 값으로 그룹핑해서 자주 조회하는가?”입니다.
5. Prometheus·Datadog 등 다른 솔루션과 비교
TIG 스택을 도입하기 전에 실무에서 자주 비교되는 4가지 솔루션을 정리해 봤어요. 각 솔루션은 strong suit과 trade-off가 명확히 다르기 때문에, 운영 환경의 규모와 요구사항에 따라 선택 기준이 달라집니다.
상세 비교표
| 항목 | TIG 스택 | Prometheus+Grafana | Datadog | CloudWatch |
|---|---|---|---|---|
| 수집 방식 | Push (Telegraf) | Pull (scrape) | Agent push | Native SDK |
| 장기 보관 | 무제한 (저비용) | Thanos 필요 | 유료 retention | 유료 장기 보관 |
| 카디널리티 | 강함 | 취약 | 강함 | 제한적 |
| 월 100GB 비용 | 셀프호스팅 EBS 1/10 | 셀프호스팅 중간 | 약 150~300만원 | 약 50~100만원 |
| K8s·ECS 통합 | 플러그인 제공 | Operator 필요 | 자동 통합 | 부분 통합 |
TIG만의 차별화된 통찰
Prometheus는 pull 기반이라 scraper가 다운되면 메트릭이 공백이 됩니다. 반면 TIG 스택은 Telegraf가 push하기 때문에 네트워크 일시 단절 시 버퍼링 옵션으로 데이터를 임시 보관할 수 있어요. 또한 InfluxDB의 continuous query는 다운샘플링을 자동화해서 30일 지난 1초 단위 데이터를 5분 단위로 자동 집계해 줍니다. Datadog가 비싸게 파는 기능을 무료로 구현하는 셈이죠.
6. 운영 최적화와 장기 보관 전략
TIG 스택을 안정적으로 운영하려면 retention policy와 다운샘플링 정책을 처음부터 설계해 두는 게 좋습니다. 운영 6개월 후에 갑자기 디스크가 터지는 사고를 막으려면요.
권장 retention 구성
- raw bucket: 1초 단위, 7일 보관
- downsampled_5m: 5분 단위, 30일 보관
- downsampled_1h: 1시간 단위, 1년 보관
고가용성 구성
InfluxDB는 OSS 버전에서 clustering이 제한적이므로, 운영 환경에서는 InfluxDB Enterprise 또는 InfluxDB Cloud를 고려합니다. InfluxDB OSS를 그대로 운영한다면 nightly logical backup을 S3에 보관하는 것이 안전합니다.
💡 TIG 스택 운영 꿀팁
- Telegraf의 flush_interval는 10초 정도로 두면 데이터 손실과 부하의 균형이 좋습니다.
- Grafana 알람은 InfluxDB의 task와 이중화해서 false positive를 줄이세요.
자주 묻는 질문
Q. TIG 스택과 Prometheus 둘 중 무엇을 선택해야 하나요?
A. K8s 단일 클러스터와 pull 기반 단순 메트릭 수집이면 Prometheus가 가볍고 충분합니다. 다만 멀티 클라우드, long-term 보관, IoT처럼 push 기반이 유리한 환경이라면 TIG 스택이 더 적합합니다.
Q. Telegraf 플러그인 200개를 다 켜야 효율적인가요?
A. 아닙니다. 필요한 input plugin만 켜야 메모리와 CPU 사용량이 안정적으로 유지됩니다. 운영 환경에서는 보통 5~10개 정도의 핵심 플러그인만 활성화하는 게 정석이거든요.
Q. InfluxDB OSS와 Enterprise 차이는 무엇인가요?
A. OSS는 단일 노드 또는 read-replica 구조만 지원합니다. Enterprise는 clustering, fine-grained access control, multi-tenancy까지 제공해서 대규모 프로덕션 환경에 적합합니다.
Q. Fargate ECS에서도 Telegraf 전용 Task 패턴을 쓸 수 있나요?
A. Fargate는 호스트 메타데이터 접근이 제한적이라 전용 Task 패턴이 어렵습니다. Sidecar로 띄우거나 CloudWatch API 기반의 cloudwatch plugin을 활용하는 대안을 고려하세요.
Q. 데이터가 누락될 때 가장 먼저 확인해야 할 곳은?
A. Telegraf 에이전트 로그의 metric_dropped 카운터, InfluxDB의 write_error 응답 코드, 그리고 Telegraf의 flush_interval 동안의 buffer 크기를 순서대로 점검하는 것이 가장 빠른 트리아지 절차입니다.
Telegraf + InfluxDB + Grafana 조합은 클라우드 네이티브 환경의 메트릭 수집을 단순하고 안정적으로 만들어 줍니다. 카디널리티 관리라는 핵심 변수만 잘 통제하면, 비용 대비 가장 효율적인 자체 호스팅 옵션이 될 거예요.
면책조항
본 글이 제공하는 모든 구성 예시, 비용 추정, 성능 수치는 일반적인 운영 환경을 가정한 참고용입니다. 실제 적용 환경에서는 보안 정책, 클라우드 요금제, 조직의 컴플라이언스 요건에 따라 결과가 크게 달라질 수 있습니다. 프로덕션 환경에 도입하기 전에는 반드시 내부 기술 검증을 거치시길 권장합니다.
