Windows 네트워크 모니터링을 위한 PRTG 및 SolarWinds의 자체 호스팅 대안

PRTG는 센서 단위로 과금합니다. 장치 자체가 아니라 한 장치의 모니터링 지표 하나가 센서입니다. Paessler가 공개한 요금 등급은 실제 비율을 대략 10 대 1로 잡습니다. 센서 500개가 약 50대, 10,000개가 약 1,000대를 커버합니다. 스위치 스택을 추가하고 포트별 처리량을 보기 시작하면 센서 수는 장비 수보다 빠르게 늘어납니다. SolarWinds는 다른 방식으로 세지만 같은 결론에 도달합니다.

Windows 비중이 높은 네트워크라면 PRTG와 SolarWinds의 자체 호스팅 대안으로 두 가지를 후보에 올리겠습니다. Zabbix, 또는 팀이 이미 운영 중이라면 Prometheus 기반 스택입니다. 둘 사이의 선택은 각각이 Windows 호스트에서 무엇을 볼 수 있는지, 그리고 그것을 보기 위해 무엇이 필요한지에 달려 있습니다.

무엇보다 먼저 한 가지 단서가 있습니다. 팀에 여유 시간이 있는 사람이 아무도 없다면 PRTG와 SolarWinds가 여전히 정답입니다. 그 사용 편의성은 의도적으로 구매하는 제품이며 값어치를 합니다. 여기서 설명하는 전환은 라이선스 비용 대신 시간을 쓰는 것이고, 이는 업그레이드가 아니라 맞바꿈입니다.

요약

• 기본 선택은 Zabbix입니다. Zabbix는 SNMP 폴링, Windows 에이전트, 템플릿, 알림을 하나의 모니터링 플랫폼 안에 담습니다. Zabbix 서버, 데이터베이스, 웹 프런트엔드는 여전히 직접 운영해야 하지만, 시작하기 위해 별도의 모니터링 구성 요소를 조립할 필요는 없습니다.
• 예외는 이미 Grafana와 Prometheus를 운영 중인 팀입니다 애플리케이션과 호스트 지표용으로요. 이미 유지 관리하는 것을 확장하는 편이 두 번째 모니터링 시스템을 세우는 것보다 저렴합니다.
• Prometheus는 자체적으로 네트워크 장치를 폴링하지 않습니다. snmp_exporter 가 그 빈틈을 메웁니다. 기본 구성이 흔한 스위치와 라우터 다수를 커버하지만, 벤더별 객체나 맞춤 폴링에는 제너레이터와 추가 MIB 작업이 필요할 수 있습니다.
• 에이전트 없는 수집은 호스트나 장치가 공개하기로 한 것만 봅니다. Zabbix에서 Windows 이벤트 로그, 서비스 상태, 세밀한 성능 카운터는 에이전트 아이템 키입니다.
• 서버 사양은 장치 수가 아니라 지표 수로 산정하세요. Zabbix는 지표 하나를 아이템 하나 + 트리거 하나 + 그래프 하나로 세며, 대략 지표 1,000개를 CPU 2코어와 메모리 8 GiB에, 대략 10,000개를 4코어와 16 GiB에 배정합니다.

PRTG와 SolarWinds가 요금을 매기는 기준

Paessler publishes its PRTG tiers publicly, priced by sensor count and billed annually, starting from a few hundred dollars a month as of September 2026. Check the current figures yourself before budgeting. There is no perpetual-licence option in the current lineup. The freeware edition stops at 100 sensors, which Paessler describes as roughly 10 devices.

SolarWinds는 다른 단위를 세는데, 이 규칙은 갱신 견적서가 도착할 때까지 놓치기 쉽습니다. SolarWinds의 NPM 라이선스 모델 은 NPM이 "다음 모니터링 네트워크 요소 유형 중 가장 큰 수를 기준으로 라이선스된다: 노드, 인터페이스, 볼륨"이라고 명시합니다. 합계가 아닙니다. 셋 중 가장 큰 값입니다. 노드 80개와 모니터링 스위치 포트 900개가 있는 네트워크는 80이 아니라 900을 기준으로 라이선스되며, 등급은 SL100부터 SLX까지입니다. 폴링 엔진 하나는 등급과 무관하게 12,000개 요소(가장 큰 값이 아니라 노드, 인터페이스, 볼륨의 합계)에서 상한에 걸리고, 그 이상은 라이선스된 폴링 엔진을 하나 더 추가해야 합니다.

두 모델의 실질적인 효과는 같습니다. 무엇을 모니터링할지는 라이선스 등급이 결정합니다. 네트워크가 아니라요. 보고 싶은 인터페이스는 보는 순간 경계를 넘기 때문에 모니터링되지 않은 채 남고, 그 비용은 청구서에 절대 나타나지 않습니다.

운영할 가치가 있는 두 가지 자체 호스팅 경로

Zabbix는 중앙 서버, 데이터베이스, 웹 프런트엔드를 중심으로 구성된 하나의 모니터링 플랫폼입니다. 서버가 SNMP 장치를 폴링하고, Windows 에이전트로부터 데이터를 받고, 같은 제품 안에서 템플릿, 트리거, 알림을 적용합니다. Prometheus 기반 네트워크 모니터링 스택을 조립하는 것에 비해 직접 통합해야 할 별도 구성 요소가 적습니다. 설치하고, 호스트를 지정하고, 템플릿을 붙이면 됩니다. 템플릿은 한 부류의 장치를 커버하는 아이템, 트리거, 그래프의 재사용 가능한 묶음입니다.

라이선스부터 시작합니다. Zabbix의 라이선스 페이지 는 7.0 이후 모든 버전이 GNU Affero General Public License 버전 3로 배포되며, 6.4까지는 GPLv2였다고 명시합니다. 규모와 무관하게 소프트웨어 라이선스 비용은 없습니다. Zabbix는 기술 지원을 별도의 선택형 구독으로 판매하고 상용 사용자에게 일정 수준의 구독을 권하지만, 제품의 어떤 기능도 그 구매 뒤에 잠겨 있지 않습니다.

두 번째 경로는 Grafana, Prometheus, VictoriaMetrics입니다. 정확히 한 가지 상황에서만 올바른 선택입니다. 이미 이 스택을 애플리케이션과 호스트 지표용으로 운영 중이고, 이미 누군가 유지 관리하고 있는 경우입니다. 그렇다면 단일 VPS에서의 전체 구축 은 이미 풀린 문제이고, 익숙한 것을 확장하는 일입니다. 새 데이터 모델을 배워야 할 사람이 없습니다.

읽기

VPS에 Grafana + Prometheus 모니터링 스택 구축하기 (Docker Compose 가이드)

이 경로의 빈틈은 네트워크 장치입니다. Prometheus는 HTTP 엔드포인트를 스크래핑하며, SNMP를 직접 다루지 않습니다. 네트워크 장비는 보통 snmp_exporter를 통해 처리하는데, 이 컴포넌트가 장치를 폴링하고 결과를 Prometheus가 스크래핑할 수 있게 노출합니다. 그 기본 구성 에는 if_mib같은 모듈이 포함되어 있어서, 많은 스위치와 라우터에서 표준 인터페이스 모니터링을 하는 데 맞춤 구성을 생성할 필요가 없습니다. 제너레이터는 벤더별 객체, 맞춤 walk, 기본 포함되지 않은 MIB가 필요할 때 비로소 추가 작업이 됩니다. 따라서 Prometheus 경로는 Zabbix보다 유지 관리할 부품이 많지만, 제너레이터가 모든 장치에 필수인 것은 아닙니다.

LibreNMS 는 이 분야의 세 번째 이름으로, 자동 검색을 중심으로 만들어졌습니다. SNMP, CDP, LLDP, OSPF, BGP, ARP로 네트워크를 훑어 무엇이 있는지 찾아냅니다. 검색이 우선순위라면 합리적인 선택입니다. 하지만 Windows 수집 문제는 바꾸지 못하며, 이 결정은 바로 거기서 갈립니다.

각 경로가 Windows 호스트를 보는 방식

Windows 모니터링에는 SNMP, 원격 WMI, 설치형 에이전트가 쓰일 수 있습니다. 어떤 경로가 적용되는지는 모니터링 제품과 수집하는 지표에 따라 다릅니다. 특히 Zabbix에서는 내장 WMI 검사가 Windows 에이전트를 통해 실행됩니다.

SNMP

SNMP 폴링은 장치에 번호가 매겨진 객체의 현재 값을 요청합니다. 그 객체는 장치 MIB 안의 위치인 OID로 지정됩니다. 돌아오는 것은 장치가 공개하는 값뿐이며 그 이상은 없습니다. 관리형 스위치, 방화벽, UPS라면 보통 그것으로 충분합니다. 인터페이스 카운터, 포트 상태, 오류율, 온도, 섀시 상태 정도입니다.

Windows에서는 그림이 더 빈약합니다. Microsoft의 SNMP 및 WMI SNMP Provider 사용 중단 공지 는 두 기능 모두 사용 중단되었음을 확인해 줍니다. 그래서 저는 Windows SNMP를 새 배포의 기본값이 아니라 레거시 호환 경로로 취급하겠습니다. Zabbix는 여전히 Windows by SNMP 템플릿을 제공하지만, 네이티브 에이전트가 운영 체제를 훨씬 깊이 들여다볼 수 있게 해 줍니다.

WMI

WMI는 대상에 모니터링 에이전트를 설치하지 않고도 원격으로 쿼리할 수 있습니다. PRTG 같은 제품이 이를 에이전트 없는 Windows 수집 방식으로 쓸 수 있는 이유입니다. Zabbix는 다르게 동작합니다. 내장 WMI 검사인, wmi.get 와 wmi.getall은 Windows 에이전트 아이템 키이므로, 모니터링 대상 머신에서 Zabbix 에이전트 또는 에이전트 2가 그 쿼리를 수행합니다.

원격 WMI는 모니터링 제품이 직접 사용할 경우 자체적인 네트워크 요구 사항도 따라옵니다. 현재 Windows 시스템에서는 RPC가 TCP 포트 135에서 시작 하며, 보통 동적 상위 TCP 포트 범위(일반적으로 49152~65535)를 통해 연결을 협상합니다. 대상의 방화벽과 WMI 권한이 이 연결을 허용해야 합니다.

이 비교에서는 프로토콜 자체보다 구분이 더 중요합니다. PRTG는 설치형 모니터링 에이전트 없이 원격 WMI를 쓸 수 있는 반면, Zabbix는 Windows 전용 WMI 가시성을 에이전트를 통해 얻습니다.

네이티브 에이전트

Windows 전용 깊이는 에이전트에 있습니다. Zabbix 문서에 나열된 Windows 전용 키: eventlog 는 Windows 이벤트 로그 모니터링용, perf_counter 는 모든 Windows 성능 카운터용, service.discovery 와 service.info 는 서비스 상태용입니다. 모두 에이전트 아이템 키입니다.

비용은 배포입니다. 중요한 모든 Windows Server와 워크스테이션에 에이전트를 두는 것은 배포해야 할 패키지, 최신으로 유지해야 할 버전, 관리해야 할 방화벽 규칙을 뜻합니다. 상시적인 운영 부담이며, 라이선스 절감의 반대급부입니다.

에이전트 없는 수집은 호스트나 장치가 공개하기로 한 것에 한정되며, Zabbix에서 이벤트 로그와 세밀한 성능 카운터는 에이전트 아이템 키 뒤에 있습니다.

나란히 비교

비교는 네 가지에 달려 있습니다. 도구가 SNMP로 네트워크 장치를 폴링하는지, Windows 에이전트가 있는지, Windows 호스트를 얼마나 깊이 볼 수 있는지, 그리고 작동하는 시스템까지 얼마나 많은 조립이 필요한지입니다. 라이선스는 이 평가가 시작된 이유이므로 그 옆에 놓입니다.

요구 사항이 "서비스가 응답을 멈추면 1분 안에 알려 달라"라면, 업타임 모니터가 딱 맞는 크기의 도구이고 다른 둘은 그 용도에 과합니다. 다만 스위치를 폴링해 인터페이스 처리량을 얻거나 Windows 성능 카운터를 읽지는 못하므로 PRTG나 SolarWinds의 대체재는 아닙니다. 가끔 같은 일로 오해받는 다른 일입니다.

읽기

VPS에 Uptime Kuma를 설치하는 방법

어느 것을 운영할 것인가

Zabbix를 운영하세요. 기존 Prometheus 투자가 없는 Windows 비중 높은 네트워크에서는 압도적으로 짧은 경로입니다. 서버, 데이터베이스, 웹 프런트엔드는 여전히 운영해야 하지만, 모니터링 모델, 템플릿, 알림이 여러 모니터링 구성 요소에 걸쳐 조립되는 대신 하나의 제품 안에 있습니다.

오래 운영할 모니터링 배포라면 단기 표준 릴리스 대신 현재의 Zabbix LTS 브랜치를 사용하세요. Zabbix의 LTS 라이프사이클 은 각 릴리스에 3년의 전체 지원과 이어지는 2년의 제한 지원을 제공하며, 여기서는 최신 기능 릴리스를 좇는 것보다 이것이 더 중요합니다.

예외는 좁고 구체적입니다. 팀이 이미 프로덕션에서 애플리케이션과 호스트 지표용으로 Grafana와 Prometheus를 운영하고 있고, 이미 그 스택의 담당자가 있다면, snmp_exporter 는 유지 관리할 두 번째 시스템이 아니라 이미 관리되는 것에 대한 추가입니다. 이 조건은 결합 조건입니다. 두 절반이 모두 성립해야 합니다. 작년에 한 사람이 세워 두고 방치한 Grafana 인스턴스는 해당하지 않습니다.

그리고 아무도 시간이 없다면 갱신하세요. 얼버무리는 말이 아닙니다. 다른 정답이 있는 다른 상황입니다. 전환은 라이선스 청구서를 운영 청구서로 바꿉니다. 에이전트 배포, 템플릿 작업, 업그레이드, 그리고 새벽 2시에 고칠 수 있을 만큼 시스템을 이해하는 사람이 필요합니다. 이미 여력이 없는 팀은 그 일을 엉망으로 하거나 아예 하지 않을 것이고, 관리되지 않는 모니터링은 조용히 실패하기 때문에 비싼 모니터링보다 나쁩니다.

하이브리드는 실재합니다. 기존 제품을 줄어드는 핵심 시스템에만 남기고, 나머지는 모두 Zabbix로 옮기고, 라이선스 등급이 시간이 지나며 내려가게 두는 것입니다. 효과가 있습니다. 다만 두 모니터링 시스템을 운영하고 알림을 대조해야 하므로, 종료일이 있는 과도기 상태로 다루세요.

이전에서 살아남지 못하는 것

Zabbix 자체 마이그레이션 가이드 에는 "마이그레이션되지 않는 것"이라는 절이 있고, 그 목록은 "마이그레이션"이라는 단어가 암시하는 것보다 깁니다. 과거 데이터와 센서 측정값은 넘어오지 않습니다. 맞춤 PRTG 알림과 종속성도 마찬가지입니다. 맵과 대시보드도 넘어오지 않는데, 두 제품이 이를 모델링하는 방식이 너무 달라 변환보다 재구축이 낫기 때문입니다. 센서 자체도 넘어오지 않습니다. Zabbix는 완전히 다른 개념으로 동작하기 때문입니다.

장치 이름, IP 주소, 인터페이스 유형은 옮길 수 있습니다. 그마저도 두 API를 상대로 하는 맞춤 내보내기·가져오기 스크립트를 거쳐야 합니다. 가이드는 두 플랫폼 사이를 직접 마이그레이션하는 공식 도구가 없다고 분명히 밝힙니다.

한 팀이 실제 비용을 기록했습니다. VM과 물리 서버 약 500대, PRTG 사용 약 7년, 낮은 우선순위의 프로젝트 시간 6개월에 걸쳐 처음부터 재구축했습니다. PRTG 센서 2,500개가 Zabbix 아이템 43,000개가 되었는데, 두 시스템이 얼마나 다르게 세는지를 잘 보여 줍니다.

"처음부터 시작하세요. PRTG에서 Zabbix로 '이 버튼을 누르면 마이그레이션' 되는 옵션은 없고, 있다 해도 이런 일은 이전 설계 실수를 반복하지 않을 좋은 기회입니다."

Digital Dilemma의 마이그레이션 기록

이는 한 조직의 경험이지 벤치마크가 아닙니다. 더 작은 환경에서는 그런 수치가 나오지 않습니다. 옮겨 갈 수 있는 것은 계획 가정입니다. 마이그레이션 시간이 아니라 재구축 시간을 예산에 잡으세요.

없이는 안 되는 것부터 재구축 순서를 정하세요. 알림의 연속성이 걱정이라면 알림 규칙을 먼저 재구축하고 대시보드는 뒤로 미루세요. 보고 이력이 걱정이라면 기존 라이선스가 만료되기 전에 필요한 것을 내보내세요. 그것은 따라오지 않습니다.

서버 사양 산정

Zabbix의 하드웨어 요구 사항 은 모니터링 지표 약 1,000개의 소규모 설치를 CPU 2코어와 메모리 8 GiB에, 지표 약 10,000개의 중규모 설치를 4코어와 16 GiB에 배정합니다. 이것이 요청 근거로 삼을 수치입니다.

사양 산정이 틀어지는 지점은 단위입니다. Zabbix는 모니터링 지표 하나를 아이템 하나 + 트리거 하나 + 그래프 하나로 정의합니다. 지표는 장치도 호스트도 아닙니다. Windows Server 한 대는 설정한 아이템 수만큼 지표를 만들어 냅니다. CPU, 메모리, 파일 시스템마다, 서비스마다, 샘플링하는 카운터마다요. 장치 수는 필요한 머신을 가늠하기에 나쁜 기준입니다. 작아 보이는 환경도 누구 하나 특별한 일을 하지 않았는데 중규모 대역에 들어갈 수 있습니다.

호스트 수보다 숫자를 더 빨리 밀어 올리는 것이 두 가지 있습니다. 첫째는 폴링 주기입니다. 갱신 간격을 절반으로 줄이면 그 간격의 모든 아이템에 대해 쓰기 속도가 두 배가 됩니다. 둘째는 이력 보존입니다. 원시 값을 얼마나 오래 보관하느냐에 따라 데이터베이스가 커집니다. 장치 수는 주로 각 장치가 기여하는 모니터링 아이템 수를 통해서 영향을 줍니다.

환경이 일반적인 갱신 간격과 적당한 보존 기간으로 지표 1,000개 예시 근처에 머문다면, 소규모 대역이 합리적인 출발점입니다. 30초마다 성능 카운터를 샘플링하고 원시 이력을 1년간 보관한다면 그렇지 않습니다. Zabbix는 공개 수치가 "시작을 위한 규모와 하드웨어 구성 예시"라고 명시하고, 프로덕션 하드웨어를 확정하기 전에 스테이징 환경에서 벤치마크할 것을 권합니다. 벤더 스스로의 단서입니다. 말 그대로 받아들이세요.

Zabbix는 서버 구성 요소를 Linux와 UNIX에서만 지원하며, Windows에서는 에이전트만 지원됩니다.

지표는 장치가 아니며, 둘 사이의 배수가 머신의 크기를 결정합니다.

모니터링 서버를 어디에 둘 것인가

사이트 전체 장애에도 모니터링이 살아남아야 한다면, 중앙 Zabbix 서버를 그 사이트의 장애 영역 밖에 두세요. 그러면 사이트 업링크가 끊겨도 모니터링 서버까지 함께 다운되지 않고 모니터링 대상 네트워크만 오프라인이 됩니다.

사설 네트워크에서는 Zabbix 프록시 가 사이트 안에 자리 잡고 주변 시스템에서 수집할 수 있습니다. 프록시는 SNMP와 에이전트 검사를 로컬에서 처리하고, 수집한 데이터를 중앙 서버로 보내며, 둘 사이의 연결이 끊긴 동안 모니터링 데이터를 버퍼링할 수 있습니다. 덕분에 모든 사설 스위치, 방화벽, Windows 호스트가 인터넷에서 직접 접근 가능하지 않아도 중앙 서버를 사이트 밖에 둘 수 있습니다.

그 중앙 서버를 운영하기에 VPS는 실용적인 장소입니다. 초기 설치를 건너뛰고 바로 호스트와 템플릿 구성으로 넘어가고 싶다면, Cloudzy는 Zabbix 서버 를 Ubuntu Server 24.04 LTS 위의 원클릭 배포로 제공합니다.

자주 묻는 질문

Zabbix는 정말 무료인가요?

네. Zabbix는 버전 7.0부터 GNU Affero General Public License 버전 3로 배포되며, 모니터링하는 장치나 지표 수와 무관하게 소프트웨어 라이선스 비용이 없습니다. Zabbix는 기술 지원을 별도의 선택형 구독으로 판매하지만, 제품의 어떤 기능도 그 뒤에 잠겨 있지 않습니다. Zabbix 운영 비용은 그것이 돌아가는 서버와 운영에 쓰는 시간입니다.

모든 Windows Server에 에이전트를 설치해야 하나요?

모든 Windows 머신에 설치할 필요는 없지만, Zabbix의 네이티브 Windows 모니터링 깊이를 원한다면 가장 중요한 서버에는 에이전트를 설치할 계획을 세우세요. SNMP로 에이전트 없이 대략적인 데이터를 얻을 수는 있지만, Microsoft의 Windows SNMP 기능은 사용 중단되었습니다. Zabbix의 내장 WMI 검사도 Windows 에이전트를 통해 실행되므로, Zabbix에서 WMI는 직접적인 에이전트 없는 수집 경로가 아닙니다. 이벤트 로그, 서비스 검색, WMI 쿼리, 세밀한 성능 카운터에는 에이전트를 쓰고, 에이전트 없는 SNMP는 주로 네트워크 하드웨어와 레거시 Windows 경우에 남겨 두세요.

모니터링 서버를 Windows에서 운영할 수 있나요?

Zabbix로는 안 됩니다. Zabbix의 요구 사항 문서 는 서버 구성 요소가 Linux와 기타 UNIX 플랫폼에서만 지원된다고 나열하며, "UNIX는 필요한 성능, 내결함성, 복원력을 일관되게 제공할 수 있는 유일한 운영 체제"라고 명시합니다. Windows 지원은 모니터링 대상 머신에 설치하는 Zabbix 에이전트와 에이전트 2를 대상으로 합니다. 모니터링 서버는 Linux 호스트에 있고, Windows 환경은 그것이 지켜보는 대상입니다.

Prometheus는 SNMP 모니터링을 하나요?

자체적으로는 하지 않습니다. Prometheus는 HTTP 엔드포인트를 스크래핑하며, SNMP 장치에서 수집하기 위해 snmp_exporter 를 사용합니다. 기본 구성이 흔한 스위치와 라우터 다수를 커버하지만, 벤더별 객체나 맞춤 폴링에는 추가 MIB 구성과 제너레이터가 필요할 수 있습니다.