“복잡한 Zabbix 운영을 더 효율적으로 만들고 싶다면,
블로그의 핵심 내용을 집대성한 『Zabbix 엔터프라이즈 최적화 핸드북(PDF)』을 확인해보세요.”

https://jikimy.gumroad.com/l/zabbix-master

---

일반적으로 Zabbix Kubernetes 템플릿은 CPU, 메모리, 디스크, 노드 상태, 컨테이너 상태 위주의 기본 지표만 제공한다. Pod 단위 네트워크 트래픽은 빠져 있다. 많은 운영 환경에서는 Prometheus를 통해 이 문제를 해결하지만, 여기서는 Zabbix만으로 Pod-level 네트워크 트래픽 수집을 완성한 사례를 공유한다.

이 설계는 레퍼런스가 전혀 없는 상태에서 직접 만든 것으로, 검증된 운영 환경에서 이미 활용 중이다.
관련 글 ‘Zabbix로 Kubernetes 모니터링 구축’ 글을 검색창에 검색.참조해서
읽길 바란다.

---

설계 개요

• 데이터 원천: Kubelet cAdvisor 메트릭
• 수집 구조: HTTP agent → 마스터 아이템 → Discovery(LDD) → 아이템 프로토타입 → 전처리 체인
• 최종 목표: Pod/Namespace/Interface 단위 RX, TX 트래픽(bps)

---

1. 마스터 아이템

• Kubernetes Kubelet by HTTP: Get cadvisor metrics를 마스터 아이템으로 지정.
• 모든 Discovery와 아이템 프로토타입은 이 데이터를 기반으로 동작.

---

2. Discovery 규칙 생성(Prod K8S NODE)

zabbix 웹 UI -> 데이트 수집 -> 호스트 -> 해당 호스트 디스커버리 -> 디스커버리 규칙 생성

• 이름: cadvisor network interface discovery
• 종류: 의존 아이템
• 키: kubelet.cadvisor.net.discovery
• 마스터 아이템: Prod-K8S NODE: Get cadvisor metrics

전처리 (JavaScript)

Pod, Namespace, Interface를 추출. 중복 제거 포함.

— code 시작 —

var lines = value.split(“\n”);

var seen = {};

var result = [];

for (var i = 0; i < lines.length; i++) {

var match = lines[i].match(/^container_network_receive_bytes_total{([^}]+)}/);

if (!match) continue;

var labelBlock = match[1];

var iface = (labelBlock.match(/interface=”([^”]+)”/) || [])[1];

var pod = (labelBlock.match(/pod=”([^”]+)”/) || [])[1];

var ns = (labelBlock.match(/namespace=”([^”]+)”/) || [])[1];

if (!iface || !pod || !ns) continue;

var key = iface + pod + ns;

if (seen[key]) continue;

seen[key] = true;

result.push({

“{#IFACE}”: iface,

“{#POD}”: pod,

“{#NAMESPACE}”: ns

});
}

return JSON.stringify({ data: result });

— code 끝 —

---

3. 아이템 프로토타입

A. RX 트래픽

만들어진 디스커버리의 규칙의 아이템 프로토타입 클릭 -> 아이템 프로토타입 생성

• 이름: RX: [{#NAMESPACE}] {#POD} ({#IFACE})
• 종류 : 의존 아이템
• 키: cadvisor.net.rx[{#IFACE},{#POD},{#NAMESPACE}]
• 단위: bps
• 데이터형: 수치(float)
• 마스터 아이템: Prod K8S NODE: Get cadvisor metrics

전처리 체인

1. JavaScript: RX 최신값 추출

— code 시작 —

var lines = value.split(“\n”);

var iface = “{#IFACE}”;

var pod = “{#POD}”;

var ns = “{#NAMESPACE}”;

var latestTs = 0;

var latestVal = 0;

for (var i = 0; i < lines.length; i++) {

var m = lines[i].match(/^container_network_receive_bytes_total{([^}]+)}\s+([0-9.eE+-]+)\s+(\d+)$/);

if (!m) continue;

var labels = m[1];

var val = parseFloat(m[2]);

var ts = parseInt(m[3], 10);

if (labels.includes(‘interface=”‘ + iface + ‘”‘) &&

labels.includes(‘pod=”‘ + pod + ‘”‘) &&

labels.includes(‘namespace=”‘ + ns + ‘”‘)) {

if (ts > latestTs) {

latestTs = ts;

latestVal = val;
}

}

}

if (latestTs > 0) return latestVal;

throw “No matching metric found”;

— code 끝 —

2. 1초 단위 변경(per second)
   
3. JavaScript: bps 환산 (cadvisor 카운터 원본 = Byte)
   
   — code 시작 —

return value * 8;

— code 끝 —

---

B. TX 트래픽

만들어진 디스커버리의 규칙의 아이템 프로토타입 클릭 -> 아이템 프로토타입 생성

• 이름: TX: [{#NAMESPACE}] {#POD} ({#IFACE})
• 종류 : 의존 아이템
• 키: cadvisor.net.tx[{#IFACE},{#POD},{#NAMESPACE}]
• 단위: bps
• 데이터형: 수치(float)
• 마스터 아이템: Prod K8S NODE: Get cadvisor metrics

전처리 체인

1. JavaScript: TX 최신값 추출
   
   — code 시작 —

var lines = value.split(“\n”);

var iface = “{#IFACE}”;

var pod = “{#POD}”;

var ns = “{#NAMESPACE}”;

var latestTs = 0;

var latestVal = 0;

for (var i = 0; i < lines.length; i++) {

var m = lines[i].match(/^container_network_transmit_bytes_total\{([^}]+)\}\s+([0-9.eE+-]+)\s+(\d+)$/);

if (!m) continue;

var labels = m[1];

var val = parseFloat(m[2]);

var ts = parseInt(m[3]);

if (labels.includes(‘interface=”‘ + iface + ‘”‘) &&

labels.includes(‘pod=”‘ + pod + ‘”‘) &&

labels.includes(‘namespace=”‘ + ns + ‘”‘)) {

if (ts > latestTs) {

latestTs = ts;

latestVal = val;

}

}

}

if (latestTs > 0) return latestVal;

throw”No matching metric found”;

— code 끝 —

2. 1초 단위 변경(per second)
   
3. JavaScript: bps 환산
   
   — code 시작 —

return value * 8;

— code 끝 —

Tip.

지금까지 Prod K8S NODE 호스트에 설정한 {$KUBE.KUBELET.URL} 매크로가
마스터 노드의 IP를 향하도록 구성되어 있었다면,
Zabbix는 당연히 마스터 노드에 존재하는 Pod들의 네트워크 메트릭만 수집하게 된다.
이는 cAdvisor가 “해당 노드에서 실행 중인 컨테이너의 정보만 제공한다”는 구조적 특성 때문이며,
다른 노드에 배포된 애플리케이션 Pod의 트래픽은 이 방식으로는 확인할 수 없다.

따라서 각 노드의 Pod 트래픽을 수집하려면,
해당 노드 호스트를 Zabbix에 추가하고
그 호스트의 {$KUBE.KUBELET.URL} 값을
https://<노드_IP>:10250 형태로 각각 설정해야 한다.
이렇게 노드별로 cAdvisor 엔드포인트를 지정해야
전체 Kubernetes 클러스터의 Pod 트래픽을 정확하게 수집할 수 있다.

결과적으로, 이러한 구조는 Prometheus가 중앙에서 모든 노드를 자동으로 긁어오는 방식에 비해
Zabbix는 노드 단위 설정이 필요해 다소 번거로운 점을 피하기 어렵다.
자세한 부분은 아래 사항을 참고하기 바란다.

cAdvisor 특성과 NODE별 설정 필요성

Zabbix로 Kubernetes Pod 트래픽을 수집할 때 반드시 이해해야 할 점은,
cAdvisor는 각 노드의 kubelet 내부에서 동작하며 해당 노드에 존재하는 컨테이너만 메트릭으로 제공한다는 사실이다.
즉, 마스터 노드는 마스터에 배치된 시스템 Pod만 보고,
애플리케이션 Pod가 떠 있는 워커 노드의 트래픽은 그 워커 노드를 직접 조회해야만 확인할 수 있다.

이 특성 때문에 단일 노드(예: 마스터)만을 대상으로 디스커버리를 수행하면
해당 노드에 존재하는 kube-proxy, calico-node, node-local-dns 같은 시스템 도구들만 탐색되고,
실제 업무 트래픽이 발생하는 애플리케이션 Pod는 전혀 탐지되지 않는다.
따라서 클러스터 전체 Pod 네트워크를 수집하려면 모든 노드를 개별적으로 Zabbix 호스트로 등록하고
각 노드의 cAdvisor 엔드포인트를 직접 조회해야 한다.

이를 위해 Kubernetes Kubelet by HTTP 템플릿을 각 노드 호스트에 추가하고,
호스트 매크로에 다음과 같이 kubelet cAdvisor URL을 지정해 준다.

{$KUBE.KUBELET.URL} = https://<노드_IP>:10250

예를 들어, 워커 노드가 여러 대라면 각 호스트에 다음처럼 서로 다른 값을 설정한다.

• https://192.168.50.11:10250
• https://192.168.50.12:10250
• https://192.168.50.13:10250

이 과정을 거치면 각 노드에 적용된 템플릿이 해당 노드의 kubelet cAdvisor 데이터를 직접 조회하게 되고,
노드마다 설정된 디스커버리 규칙이 그 노드에서 실제로 실행 중인 Pod들을 기준으로
RX/TX 아이템을 개별적으로 생성한다.
즉, 디스커버리는 노드별로 독립적으로 동작하며,
시스템 구성요소와 같이 모든 노드에 존재하는 Pod는 여러 노드에서 공통적으로 탐지되고,
애플리케이션 Pod의 트래픽은 그 Pod가 위치한 노드에서만 정확하게 수집되는 구조가 된다.

---

4. 트리거 전략

물리 네트워크 인터페이스 트래픽은 별도 모니터링으로 커버 중. Pod-level 지표는 흐름 분석 용도로만 사용. 따라서 트리거는 생성하지 않았다. 필요 시 동일한 프로토타입 기반으로 트리거 추가 가능.

---

5. 엔터프라이즈 활용 가치

• Zabbix 기본 템플릿 한계를 직접 보완.
• Prometheus 없이도 Pod-level 네트워크 가시성 확보.
• Discovery + 프로토타입 구조로 자동 확장 대응.
• 운영 환경에서 안정성 검증 완료.

이 설계는 Zabbix를 단순 노드/리소스 모니터링 도구에서 Pod-level 네트워크까지 커버하는 엔터프라이즈급 솔루션으로 확장시킨 사례라고 할 수 있을 것이다.

🛠 마지막 수정일: 2025.12.19