[개인공부]Zabbix & Netdata 기반 Grafana 관제 대시보드 보완 및 구축

참고 문서
https://seongw00.tistory.com/15

https://docs.aws.amazon.com/ko_kr/grafana/latest/userguide/v10-dash-bestpractices.html

본 문서는 상기 모범 사례(BP)를 바탕으로 개인 서버 대시보드를 보완하고 구축한 과정을 기록합니다.

1. 들어가며

Grafana 대시보드 BP 작성과 서버 자원 확장 테스크를 진행한 후, 개인 서버 모니터링 대시보드의 개선점을 도출하여 보완 작업을 진행했습니다. USE(Utilization, Saturation, Errors) 방법론과 RED(Rate, Errors, Duration) 방법론, 그리고 Zabbix 및 Prometheus/Netdata 연동 가이드를 바탕으로 관제 효율성을 극대화하는 방향으로 대시보드를 재구성했습니다.

2. USE 방법론에 따른 '포화도(Saturation)' 지표 보강

기존 대시보드는 '사용률(Utilization)' 위주로 구성되어 있어 시스템 병목 현상을 조기에 감지하기 어려웠습니다. 이에 포화도 지표를 추가하여 인과관계를 설명할 수 있도록 개선했습니다.

2-1. CPU Load Average 지표 구축

 

• Why: 단순 CPU 사용률만으로는 시스템 부하가 연산량 증가 때문인지, 프로세스가 처리를 기다리는 '병목 현상' 때문인지 파악하기 어렵습니다.
• How & Step-by-Step:
  • Zabbix 데이터 소스에서 Load average (1m/5m/15m avg) 아이템을 추가했습니다.
  • 상단 CPU 사용률 그래프 바로 아래에 슬림한 형태로 배치하여 "CPU가 바쁨 ➔ 대기열 발생 여부"를 즉시 확인할 수 있는 시각적 동선을 만들었습니다.
  • 1분 평균(1m avg) 선 색상을 상단 CPU 사용률 톤과 맞추어 동일 계열 지표임을 직관적으로 표현했습니다.
  • Y축 Max 값을 실제 CPU 코어 수(4)로 고정하여 시각적 안정감을 주었습니다.

🔍 [Troubleshooting] Number of CPUs 'No data' 이슈 해결

• 문제 현상: CPU 코어 수 수집 쿼리는 정상이나 Grafana 패널에서 지속해서 No data가 표출됨.

  

• 원인 분석: Zabbix 확인 결과 Number of CPUs 데이터의 Last check 시간이 '22시간 30분 전'으로 확인됨. 코어 수는 변하지 않으므로 수집 주기가 길었던 것인데, Grafana는 최근 1시간 기준 데이터를 조회하므로 이를 '데이터 없음'으로 판단함

• 

• 해결 방법: Zabbix 수집 주기를 변경하는 대신, Grafana 패널의 Query options ➔ Relative time을 24h로 지정하여 해당 지표만 과거 수집 데이터를 정상 표출하도록 교정함.

 

 

2-2. Memory Swap 사용률 지표 구축

• Why: RAM(8GiB)이 가득 차 하드디스크를 메모리처럼 사용하는 Swap 상태가 되면 성능이 극도로 저하됩니다. OOM(Out Of Memory) Killer 작동으로 인한 서비스 중단을 막으려면 스왑 사용 시점을 즉시 포착해야 합니다.
• Problem: Zabbix 기본 제공 지표는 Free swap space in % (잔여량)만 존재하여, 엔지니어 시점에서 직관적인 Used swap space in % (사용량) 파악이 어려움.
• Solution (Binary Operation):
  • Grafana Transformations ➔ Add field from calculation 기능 활용.
  • 수식: 100 - (Free swap space in %) (Binary operation 적용).
  • Organize fields로 계산 재료였던 원본 Free 지표는 숨기고, 가공된 Used Swap %만 노출하여 인지 부하 최소화.

3. 디스크 관제 구축 및 I/O vs 사용률 트러블슈팅

3-1. 디스크 I/O 모니터링 구축 (xvda)

• 지표 선정 이유: CPU/RAM이 정상임에도 시스템이 느릴 경우 원인은 디스크 I/O 병목일 확률이 높습니다. 가상화 환경 특성에 맞춰 메인 디스크인 xvda를 지정하고 불필요한 장치(sr0 등)는 제외했습니다.
• 

  

• 설정 방법: Zabbix 쿼리의 Item tag에 disk: xvda를 직접 지정하고, /read rate/, /write rate/ 정규식으로 매칭했습니다. 쓰기 지표는 음수 방향으로 반전시켜 읽기/쓰기 흐름의 시각적 분리감을 높였습니다.

 

3-2. [Troubleshooting] 디스크 I/O는 요동치는데 사용률은 왜 0일까?

• 문제 현상: Disk Read/Write Rate 패널은 실시간으로 요동치는데, Disk Space Utilization 패널은 0%로 표시됨.
• 원인 분석 (관점의 차이):
  • 디스크 I/O: 데이터가 통과하는 '통행량(활동량)' 관점 (xvda 정문 센서 정상 작동).
  • 파일시스템 사용률: 공간에 데이터가 쌓인 '용량(면적)' 관점.
  • 사용률 패널이 메인 디스크(xvda2 / /)가 아닌, 텅 비어 있는 임시 마운트 포인트(tmpfs 등)를 바라보고 있었기 때문에 발생한 미스매치.
• 해결: 마운트 포인트 대상을 루트(/) 파일시스템으로 정확히 재지정하여 실제 사용량(15%)이 표출되도록 교정.

4. Status Timeline 및 네트워크 패널 최적화

4-1. 24시간 생존 기록 Status Timeline 구축

• 개념: "지금 살아있는가?" 뿐만 아니라 "자리를 비운 시간 동안에도 잘 살아있었는가?"를 증명하는 패널.
• 구축 방법: Zabbix agent ping 지표(1/0)를 활용하여 1 ➔ ONLINE(초록색), 0 ➔ OFFLINE(빨간색)으로 Value Mapping 지정. Relative time을 24h로 고정하여 24시간 생존 이력을 한눈에 감시하도록 설정.

4-2. 네트워크 패널 단권화 및 재구성

• 문제점: 미연결 인터페이스(enX2, enX3) 및 임시 가상 인터페이스(veth*, br-*) 등 15개 이상의 패널이 분산되어 N/A 도배 및 인지 부하 가중.
• 해결 방안 (인터페이스 핑거프린팅):

  

  
  • CLI(ip -br link) 검증을 통해 유효 트래픽이 발생하는 3개 핵심 인터페이스만 선별.
    • enX0: 메인 외부 통신 관문 (필수)
    • enX1: 사설망/VPC 통신 관문 (필수)
    • wg0: WireGuard 보안 VPN 터널 (필수)
  • 통합 패널 구축: enX0과 enX1의 In/Out 트래픽 4개를 단일 Time Series 패널로 통합하고, wg0 보안 트래픽 패널을 독립 분리하여 관제 이원화 완성.

 

5. Netdata 연동을 통한 Top 5 프로세스/컨테이너 관제 (Prometheus)

OS 프로세스 및 Docker 컨테이너 자원 점유율(%CPU)을 top 명령어처럼 실시간 추적하기 위해 Netdata 및 Prometheus 연동을 진행했습니다.

5-1. 연동 구조 및 PromQL 설정

Netdata의 Prometheus 익스포터 엔드포인트를 Prometheus와 연동 후 Grafana Table 패널로 시각화했습니다.

• Top 5 OS 프로세스 패널 (Top 5 Resource Consuming Processes):
• topk(5, sum by (app_group) (netdata_app_cpu_utilization_percentage_average))
• Top 5 Docker 컨테이너 패널 (Docker Containers Resource Usage):
• topk(5, sum by (cgroup_name) (netdata_cgroup_cpu_percentage_average))

5-2. [Troubleshooting] Instant 조회의 Table 데이터 뭉개짐 & No Data 해결

• Issue 1. Table 패널 데이터 통뭉침 현상: PromQL sum by 연산 시 레이블이 손실되어 Value 하나로 합쳐짐 ➔ Format을 Table, Type을 Instant로 지정 후 Transformations의 Organize fields를 추가하여 app_group/cgroup_name 필드를 Show(ON) 처리하고 COMMAND/CONTAINER로 이름을 변경하여 해결.
• Issue 2. Instant 적용 시 No data 발생: Grafana 시간 범위(Time Picker)가 미래 시간을 포함하고 있어 평가 시점 격차 발생 ➔ 대시보드 조회를 Last 1 hour (현재 시간 now 기준)로 맞춰 Instant 평가 시점을 최신 데이터 타임스탬프와 일치시켜 해결.

6. SRE/DevOps 관점의 대시보드 최종 레이아웃 배치 전략

장애 발생 시 'MTTD(평균 탐지 시간) 최소화'와 '원인 분석(Root Cause Analysis)의 신속성'을 최우선 목표로 두고 4단계 Top-to-Bottom 레이어로 대시보드를 배치했습니다.

+-----------------------------------------------------------------------------------+
| LAYER 1: Health Overview (Host, Uptime, Online Status, Active Alerts)             |
+------------------------------------+----------------------------------------------+
| LAYER 2: System Resources          | Resource Trends (CPU/RAM/Load Avg 차트)      |
| (CPU, Memory, Load Gauge)          |                                              |
+------------------------------------+----------------------------------------------+
| LAYER 3: Root Cause Analysis                                                      |
| [ Top 5 OS Processes ]             | [ Top 5 Docker Containers ]                  |
+------------------------------------+----------------------------------------------+
| LAYER 4: Deep Dive & Logs (Disk I/O, Network Traffic, Zabbix Alert Logs)          |
+-----------------------------------------------------------------------------------+

1. 최상단 (Health Overview): 서버 식별자, Uptime, Online 상태 등 기본 지표를 슬림한 1행 카드로 배치해 1초 만에 전체 시스템의 정상 가동 여부를 파악합니다.
2. 상단 (System Resources): CPU, Memory 전체 사용률 게이지와 Load Average 추이를 배치하여 호스트 차원의 리소스 병목 유무를 한눈에 진단합니다.
3. 중단 (Root Cause Analysis - 핵심): OS 프로세스 Top 5와 Docker 컨테이너 Top 5 테이블 패널을 1:1 반반(50:50)으로 대조 배치했습니다. 리소스 급증 시 OS 계층과 컨테이너 계층 중 어느 곳이 주범인지 즉시 교차 검증할 수 있습니다.
4. 하단 (Deep Dive & Logs): Disk I/O, 네트워크 트래픽 추이 및 알람 이력을 모아두어, 필요시 세부 인프라 영역까지 깊이 있게 추적할 수 있도록 시선 흐름에 맞춰 직관적으로 구성했습니다.