SNMP 미지원 라우터를 Zabbix로 시각화하기 (레이와 버전) - AI 시대의 템플릿 개발과 변치 않는 모니터링 설계의 핵심

echo '===TOP===' 
top -b -n1 | head -n 5
echo '===UPTIME===' 
...```

이 출력을 마스터 아이템( `history: 0`로 DB에 저장하지 않음)으로 받아, 나머지는 Zabbix Server 측의 전처리(정규표현식이나 JavaScript)로 각 메트릭으로 전개합니다.

무거운 SSH 암호화 세션 확립이 30초에 한 번만으로 충분하기 때문에, 라우터에 가해지는 부하를 최소한으로 유지할 수 있습니다.

Linux 서버의 표준 명령어( `top`, `cat /proc/meminfo` 등)라면, 오랫동안 인프라를 다뤄온 엔지니어라면 숨 쉬는 것처럼 능숙하게 다룰 수 있습니다.

하지만 임베디드 라우터, 게다가 특정 SoC(Qualcomm IPQ8074)에 의존하는 무선 드라이버 고유의 명령어( `wlanconfig athX list sta`나 써멀 존 노출 경로 등)가 되면 이야기가 달라집니다.

이런 종류의 임베디드 시스템 명령어는 웹상에서 찾아봐도 공식적인 레퍼런스가 거의 존재하지 않습니다. 벤더의 폐쇄된 사양서, 해외 포럼의 단편적인 글, 혹은 커널 소스 깊숙한 곳에 파묻혀 있는 경우가 대부분이라, 제로베이스(zero-base)에서 조사하려면 엄청난 시간이 소요됩니다.

여기서 AI가 진가를 발휘했습니다.

"Qualcomm SoC 환경에서 연결된 단말기별 RSSI나 SNR을 가져오는 명령어는 무엇인가?"

"sysfs에 노출된 써멀 존의 모델명과 온도를 한 줄로 덤프하려면 어떻게 작성해야 하는가?"

라고 질문하자, AI는 파편적인 임베디드 드라이버 지식을 끌어모아 필요한 최소한의 수집 명령어를 빠르게 제시해 주었습니다.

또한, Zabbix 7.0 대시보드 위젯 사양(LLD로 감지된 15개의 그래프를 그리드 형태로 표시하는 그래프 프로토타입 위젯 설정) 조사나 YAML 템플릿의 고속 생성 등, 구현 속도는 AI 덕분에 극적으로 가속화되었습니다.

여기까지 읽으면 '이제 인간은 필요 없고, AI에게 맡기면 전자동으로 만들 수 있지 않을까?'라고 생각할지도 모릅니다.

하지만 실제로 현장에서 직접 만져보면서 절실히 느낀 것은, **'AI는 그럴듯한 거짓말(환각, Hallucination)을 거리낌 없이 말하며, 그 차트에서 무엇을 읽어내고 싶은지라는 의도(감각, Sense)를 가지고 있지 않다'**는 현실이었습니다.

개발 과정에서 AI에게 설계 요약을 부탁했을 때, AI는 아무렇지도 않게 다음과 같은 '사실과 다른 스토리'를 내놓았습니다.

- "라우터에서 클린한 JSON 페이로드를 출력하게 하고, JSONPath로 전개했습니다"

➔**거짓.** 임베디드 기기의 BusyBox에는 jq 등이 들어있지 않고, 쉘만으로 견고한 JSON을 구성하는 것은 오히려 처리가 무겁습니다. 실제 구현은 위와 같이 `===TOP===` 같은 구분 텍스트 + 정규표현식/JS 전처리에 의존합니다. -
- "grep이나 awk의 다단계 fork를 철저히 배제하여 프로세스 부하를 제로에 가깝게 만들었습니다"

➔**엉뚱함.** 실제로는 `top | head`나 15개 존 각각에 대해 `cat` 등을 호출하고 있으며, 대략 세어봐도 수십 번의 프로세스 생성이 정상적으로 발생합니다. 단일 SSH를 목표로 한 것이 아니라, 'SSH 연결 확립(키 교환)을 메트릭 개수만큼 반복하지 않고 30초에 한 번으로 통합하는 것'이 목적입니다.

AI는 '그럴싸한 기술 해설'을 유창하게 출력하지만, **실제 장비의 코드와 물리적 제약을 대조하여 '그것은 구현과 다르다', '본질은 저기가 아니다'라고 간파할 수 있는 것은 현장에서 직접 손대어 본 인간뿐**입니다.

또 다른 결정적인 차이는 시각화에서의 '해독 능력(Sense)'입니다. 상징적이었던 것이 Wi-Fi의 '연결 단말기 수' 그래프 표현이었습니다.

AI에게 대시보드 생성을 맡기면, 아무 말 없으면 일반적인 '꺾은선 그래프(描画: 선. YAML상으로는 `ds.type: 0`)'로 그리려고 합니다.

하지만, **연결 단말기 수는 '개수(이산값)'**입니다. 2.4대나 3.7대 같은 중간 상태는 물리적으로 존재하지 않습니다. 단말기가 Wi-Fi 범위 안으로 들어온 순간, 혹은 끊어진 순간에 수치가 확 떨어지거나 올라갑니다.

이것을 선으로 그려버리면, '언제 단말기가 증감했는지'라는 경계선이 부드럽게 보간되어 버려, 네트워크 트러블슈팅에서 극도로 읽기 어려운 그래프가 되어버립니다.

'단말기 수 데이터셋에는 `ds.type: 2` (描画: 계단형 / Staircase)를 적용하여, 단계 변화를 직관적으로 파악할 수 있도록 한다'라는 지정은, **'이 그래프를 운영에서 어떻게 읽어내고 싶은가'라는 강한 의도를 가진 엔지니어**가 아니면 할 수 없습니다.

AI는 빌보드(단일 값 카드)나 게이지, 패널 같은 개별 UI 컴포넌트를 제안하는 것은 능숙합니다.

하지만, 이들을 어떻게 그룹화하고 어떤 시선 이동으로 장애를 구분할 것인가 하는 '대시보드의 맥락'은 인간만이 설계할 수 있습니다.

이번에 구현한 템플릿 대시보드는 다음의 **명확한 3개 탭 구성**을 갖추고 있습니다.

- 
**탭1: 시스템 개요 (System Overview)** - 라우터 자체의 기초 체력(CPU 반원 게이지, 메모리 도넛, CPU 상세 부하 추이, 메모리 추이, Google 응답 시간)을 한눈에 볼 수 있습니다.
- 먼저 '라우터 자체의 처리 능력이 과부하 상태는 아닌지'를 5초 만에 판별하는 화면입니다.

- 
**탭2: Wi-Fi 6 무선 품질 (Wi-Fi Quality)** - 연결 단말기 수 카드(총합・5GHz・2.4GHz)와 임계값 컬러가 적용된 Wi-Fi 품질 카드(5GHz / 2.4GHz의 평균 RSSI・평균 SNR, 총 4개).
- 단말기 수 증감 추이가 명확하게 보이는 계단식 추이 그래프.
- 5GHz 대역 및 2.4GHz 대역의 전파 환경 추이(평균 RSSI, 최소 RSSI, 평균 SNR)와 플로어 노이즈 추이(참고값: 후술하듯이 이 모델에서는 고정값이었습니다).
- '네트워크가 느리다', 'IoT 기기가 끊긴다'고 느꼈을 때, 그것이 라우터 부하 때문인지 아니면 '전파 간섭이나 저속 단말기의 독점 사용' 때문인지를 구분할 수 있는 화면입니다.

- 
**탭3: 각 부분 온도 추이 (총 15개) (Thermal Zones)** - 기판 위의 전체 15개 열(Thermal Zone)을 LLD로 자동 감지하여 타일 형태로 그리드 표시합니다.
- 고부하 통신 시 등에 국소적인 열 축적이나 서멀 스로틀링(thermal throttling)이 발생하지 않는지 모니터링하는 화면입니다.

장애가 발생했을 때, 운영자는 **'시스템(CPU/메모리) ➔ 무선 환경(전파/간섭) ➔ 하드웨어(열)'** 순서로 가설을 검증해 나갑니다. 이 스토리(읽기 흐름)를 만드는 것이 바로 모니터링 설계의 본질입니다.

집에서 인터넷이 '왠지 느리다', '온라인 회의에서 목소리가 끊긴다'고 느낄 때, 많은 사람은 가장 먼저 '통신사 탓이 아닐까', '광케이블 계약을 바꿔야 하나(회선 가챠)'라고 생각하기 쉽습니다.

하지만 손안에 라우터의 모니터링 데이터가 있다면, 더 객관적으로 가설을 세울 수 있습니다.

라우터의 CPU 부하 추이를 모니터링하다 보면, `sirq`

(소프트웨어 인터럽트)가 집중적으로 상승하는 장면을 관측할 때가 있습니다. 이전 템플릿에서도 확인했지만, 원인은 아직 밝혀지지 않았습니다.

패킷 전송 처리 때문인지, 라우터 측의 기능 설정 영향 때문인지, 가설은 몇 가지 세울 수 있지만, 아직 특정하지 못했습니다. 관측은 할 수 있어도 원인을 알 수 없는 상태입니다. 그럼에도 '회선 탓을 하기 전에 라우터 내부를 의심'할 수 있는 출발점은 됩니다.

저희 집에서는 2.4GHz 대역에 연결된 SwitchBot 기기가 가끔 불안정해지지만, 원인은 아직 밝혀지지 않았습니다.

Wi-Fi에서는 전파가 좋지 않은 단말기가 섞이면 낮은 변조율(MCS)로 통신하기 때문에 전파를 오랫동안 독점하여 주변 통신까지 영향을 받는 현상(802.11의 performance anomaly)이 알려져 있습니다. SwitchBot의 불안정함이 이것에 해당하는지, 아니면 단말기 고유 문제나 주변 전파 간섭인지를 구분하려면 2.4GHz 대역의 전파 강도(RSSI) 같은 객관 데이터가 필수적입니다.

그래서 이번 템플릿에서는 5GHz 대역뿐만 아니라 **2.4GHz 대역의 전파 환경 추이(평균 RSSI・최소 RSSI・평균 SNR)**도 대시보드(탭2)에 통합했습니다. 이를 통해 SwitchBot이 끊긴 순간에 '최소 RSSI가 악화되어 저속 단말기의 독점 사용이 발생했는지'를 대시보드 상에서 간접적으로 교차 확인할 수 있게 되었습니다. 최소 RSSI는 어디까지나 낮은 속도의 '단서'일 뿐이며, 각 단말의 통신 속도(`wlanconfig`

의 `TXRATE` / `RXRATE`)까지는 아직 아이템화하지 못했습니다.

참고로 플로어 노이즈도 수집하여 그래프화했지만, 실제 장비에서 `iwconfig`를 확인해 보니 5GHz와 2.4GHz 모두 `Noise level=-97 dBm`으로 변화가 없었고, 몇 초 간격으로 가져와도 변하지 않았습니다(`Signal level`도 마찬가지로 -97 dBm이며, AP 자체 인터페이스가 반환하는 형식적인 값으로 보입니다). **이 모델에서는 `iwconfig`의 노이즈 플로어는 간섭 감지 지표가 되지 않습니다.** 이 부분 역시 AI 설명을 맹신하지 않고 실제 장비 출력을 보고서야 알게 된 것입니다.

데이터가 갖춰지면서, 마침내 근본 원인을 분리해 나가는 본격적인 관찰의 출발선에 섰다고 할 수 있습니다.

저희 집에서는 공유기를 에어컨 바로 아래에 설치하고 있어 현재는 열 폭주(thermal runaway) 걱정은 없지만, 약 15년 전에 사용했던 NEC 사의 공유기에서 열이 원인인지 의심되는 현상이 있었습니다.

실제로는 RT-AX89X의 sysfs(`/sys/class/thermal/thermal_zone*`)에는 무려 15개의 온도 센서가 존재하지만, 제조사 설명서에 부위별 대응표가 실려 있는 것은 아닙니다. AI가 제시하는 부위명(NSS나 PA 등) 역시 어쨌든 칩셋의 센서 이름(tsens)에서 나온 '추정'에 불과합니다. 실제 장비로 확인할 수 있는 일차 정보는 `tsens_tz_sensor4`부터 `15`까지와 `pa_therm1`부터 `3`까지라는 `type`명과 온도 값뿐이며, 템플릿상의 일본어 부위명은 임시 라벨일 뿐입니다.

그렇기 때문에 단순히 추측만으로 특정 센서만을 감시하는 것이 아니라, **LLD(Low-Level Discovery)를 이용해 전 15개를 통째로 발견하고 평소의 정상 온도와 파형을 파악해 두는 것**에 의미가 있습니다. '에어컨 바로 아래에서 정말 식고 있는지', '높은 부하 시에도 경고 임계치(기본 80℃)에 도달하지 않았는지'를 수치로 뒷받침할 수 있는 안심감은 운영자에게 큰 가치를 제공합니다.

이번에 개발한 템플릿은 GitHub 리포지토리에서 MIT 라이선스로 전면 공개했습니다.

또한, 전 세계 ASUS 공유기 사용자들을 위해 일본어판과 영어판의 바이링구얼 대응을 진행하여, **Zabbix 공식 커뮤니티 템플릿(PR #865)** 에도 기여 및 신청 중입니다.

-
**GitHub 리포지토리**: qryuu/zabbix-template-asus-rt-ax89x -
**Zabbix Community Templates PR**: zabbix/community-templates#865

-
**템플릿 임포트**:- 리포지토리에서 `template/template_asus_rt_ax89x_ja.yaml`을 다운로드합니다. - Zabbix Web UI의 '데이터 수집' → '템플릿' → '임포트'를 통해 가져옵니다.

- 리포지토리에서
- **호스트 생성 및 링크**:- 공유기 호스트를 생성하고 템플릿 `ASUS-Router`를 연결합니다. - 인터페이스에는 공유기의 IP 주소(예: `192.168.1.1`)를 설정합니다. - 공유기 측에서 SSH 서버를 활성화해 둡니다 (LAN 전용. 접속 포트는 22로 고정입니다).

- 공유기 호스트를 생성하고 템플릿-
- **사용자 매크로 설정**:- 호스트의 '매크로' 탭에서 SSH 연결 정보를 설정합니다.

| 매크로명 | 기본값 | 타입 | 설명 |
|---|---|---|---|
`{$SSH_USER}` | (미설정・필수) | 텍스트 | 공유기의 SSH 로그인 사용자 이름 |
`{$SSH_PASS}` | (미설정) | 시크릿 텍스트 | SSH 로그인 비밀번호 |
`{$AX89X.TEMP.WARN}` | `80` | 텍스트 | 열 구역 온도 경고 임계치 (°C) |

⚠️ 보안상 중요 사항:

ASUS 공유기의 표준 펌웨어(Asuswrt)에서 SSH 로그인 계정은 공유기 웹 관리 화면의 관리자 계정 그 자체입니다.

보안을 확보하기 위해, 관리 화면의 '관리' → '시스템' SSH 설정에서 WAN 측으로부터의 SSH 연결은 절대 허용하지 말고 (LAN 측만 허용), Zabbix 호스트 매크로의 `{$SSH_PASS}`에는 반드시 '시크릿 텍스트'를 사용하여 비밀번호가 평문으로 노출되는 것을 막아주십시오.

설정 후, 약 30초 정도 기다리면 호스트의 '대시보드'에 3개의 탭 화면이 자동으로 열립니다.

2020년 RT-AC87U부터 6년. 

Zabbix 3.4에서 Zabbix 7.0으로, 그리고 수동 셸 스크립트(shell script) 작업에서 AI 에이전트와의 페어 프로그래밍으로, 기술의 도구들은 크게 변화했습니다.

AI는 번거로운 YAML 구문 작성이나 내장 명령어 탐색 같은 '구현 노력'을 놀라운 속도로 대신해 줍니다. 

하지만, **AI가 제시한 그럴듯한 설명의 거짓을 간파하고, 구현의 물리적 제약을 이해하며, '어떤 데이터를 어떻게 그려야 현장에서 판독할 수 있을지'라는 모니터링의 맥락을 부여하는 것**은 현장에서 장비와 마주하는 엔지니어만이 할 수 있습니다.

회선 계약을 검토하기 전에, 일단 눈앞의 라우터부터 과학(scout)해 보는 건 어떨까요?

그럼, 즐거운 Zabbix 라이프 되세요.