원문 : https://blog.zabbix.com/the-evolution-of-an-snmp-auto-discovery-tool/33123/
snmpwalk 결과 앞에서 막막했던 경험, 모니터링 하는 분들이라면 한 번쯤 있으실 텐데요. 마침 그 막막함을 도구로 풀어낸 이야기가 있어 소개해봅니다. OICTS의 Zabbix 트레이너가 snmp-scanner라는 도구를 만들면서 생각이 어떻게 바뀌어 갔는지를 솔직하게 적은 글입니다.
이야기는 흔한 장면에서 출발합니다. 처음 보는 벤더의 스위치를 붙였는데 맞는 Zabbix 템플릿이 없어요. MIB 번들을 받아보니 거대하고, snmpwalk를 돌리니 수천 줄이 화면을 채웁니다. 저자는 여기서 진짜 어려운 게 뭔지를 정확히 집어냅니다. OID가 뭐가 있는지는 금방 알 수 있어요. 문제는 그중에서 어떤 게 운영 템플릿에 넣을 가치가 있고 어떤 게 노이즈나 타임아웃만 유발하는지를 판단하는 일이라는 거죠.
그래서 처음엔 당연한 접근을 했다고 합니다. "흥미로운 OID를 자동으로 찾아주자." sysObjectID로 벤더를 알아내고, MIB를 파싱하고, 스칼라와 테이블을 골라내는 식으로요. 초반엔 기대 이상으로 잘 돌아갔다는데, 곧 자기들이 잘못된 문제를 풀고 있었다는 걸 깨닫습니다.
여기서 글의 방향을 바꾼 한 문장이 나옵니다. "OID를 찾는 건 쉽고, 어떤 게 중요한지 아는 게 어렵다." walk에는 설정용 객체, 랩에서나 의미 있는 디버그 카운터, 증가는 하는데 변해도 아무도 뭘 해야 할지 모르는 카운터, 중복, 한 줄짜리에 인덱싱마저 이상한 테이블 수백 개가 섞여 있거든요. 초기 버전이 아이템 수백 개짜리 템플릿을 뽑아내고 디스커버리 룰이 줄줄이 타임아웃 나던 게 그 증거였고요. 결론은 이 도구가 디스커버리는 잘하지만 큐레이션은 못 한다는 것이었고, 그때부터 "전체 walk는 다 보여주되, 선택은 큐레이션한다"가 설계의 중심이 됩니다. 카탈로그는 제안만 하고 결정은 사람이 하는 거죠.
기술적으로 재밌는 대목 몇 개만 뽑아보면 이렇습니다. 각 후보를 두고 이건 그래프용 메트릭인지, 트리거로 쓸 상태값인지, LLD 대상 테이블인지를 분류합니다. Zabbix 7의 walk 기반 디스커버리(마스터 walk 하나에 종속 디스커버리를 얹는 방식)를 일찍 택했는데, 4천 행짜리 테이블은 "발견 가능한 것"과 "안전하게 walk 할 수 있는 것"이 다르다는 걸 알고 varbind 수를 추정해 상한을 겁니다. 그리고 지식의 출처로 raw MIB보다 기존 Zabbix 템플릿을 더 신뢰했다는 점이 인상적이에요. MIB는 "무엇이 존재하는가"를 말해주지만, 템플릿은 "사람들이 실제로 뭘 본다고 결정했는가"를 담고 있으니까요. 그래서 우선순위도 템플릿 → walk 증거 → OID 정체성 → MIB 순이고, MIB는 후보일 뿐 단독 자동 추천은 절대 안 한다고 못 박습니다.
저자가 "첫날 벽에 붙여놨어야 했다"며 남긴 교훈 여섯 개는 그대로 옮길 만합니다.
대부분의 SNMP 데이터는 쓸 만한 모니터링 데이터가 아니다
OID 디스커버리보다 장비 분류가 더 중요하다
스칼라보다 테이블이 더 가치 있다
다 뽑으면 아무도 유지보수 못 하는 템플릿이 된다
좋은 디스커버리보다 좋은 필터링이 더 중요하다
기존 모니터링 프로젝트에는 값진 도메인 지식이 들어 있다
AI를 대하는 태도도 눈여겨볼 만했습니다. 앞으로 AI를 붙이긴 하는데, 자율적으로 템플릿을 써내는 주체가 아니라 애매한 심볼을 분류하거나 매핑을 제안하는 "랭킹과 리뷰 가속기"로만 쓰겠다는 겁니다. walk에서 템플릿, 추천으로 이어지는 증거 사다리를 AI가 건너뛰게 두지 않겠다는 선이 분명해요.
정리하면 저자의 메시지는 한 줄로 압축됩니다. SNMP 자동 디스커버리는 검색 문제처럼 보이지만, 사실은 분류와 도메인 지식 위에 얹힌 큐레이션 문제라는 것. "흥미로운 것과 모니터링할 만한 것은 다르다"는 걸 인정한 순간부터 비로소 도구가 쓸모 있어졌다는 이야기입니다.