PRTG menagih per sensor, yaitu satu metrik yang dipantau pada satu perangkat, bukan perangkatnya itu sendiri. Tingkatan harga Paessler sendiri menetapkan rasio praktis sekitar sepuluh banding satu: 500 sensor mencakup sekitar 50 perangkat, 10.000 mencakup sekitar 1.000. Tambahkan satu tumpukan switch dan mulai pantau throughput per port, maka hitungannya naik lebih cepat daripada jumlah perangkat. SolarWinds menghitung dengan cara berbeda dan tiba di tempat yang sama.
Untuk jaringan yang didominasi Windows, saya akan memilih dua alternatif self-hosted untuk PRTG dan SolarWinds: Zabbix, atau stack berbasis Prometheus jika tim Anda sudah mengoperasikannya. Pilihan di antara keduanya bergantung pada apa yang bisa dilihat masing-masing pada host Windows, dan apa yang dibutuhkannya untuk melihat itu.
Satu catatan sebelum semuanya. Jika tidak ada orang di tim yang punya jam luang, PRTG dan SolarWinds tetap jawaban yang benar. Kemudahan pakainya adalah produk yang Anda beli dengan sengaja, dan itu sepadan dengan harganya. Peralihan yang dijelaskan di sini menghabiskan jam kerja alih-alih biaya lisensi, dan itu adalah pertukaran, bukan peningkatan.
TL;DR
- Pilihan default-nya adalah Zabbix. Zabbix menyatukan polling SNMP, agen Windows, template, dan peringatan dalam satu platform pemantauan. Anda tetap mengoperasikan server Zabbix, database, dan frontend web, tetapi Anda tidak perlu merakit komponen pemantauan terpisah hanya untuk memulai.
- Pengecualiannya adalah tim yang sudah menjalankan Grafana dan Prometheus untuk metrik aplikasi dan host. Memperluas apa yang sudah Anda rawat lebih murah daripada membangun sistem pemantauan kedua.
- Prometheus tidak melakukan polling perangkat jaringan dengan sendirinya.
snmp_exportermengisi celah itu; konfigurasi default-nya mencakup banyak switch dan router umum, sementara objek khusus vendor atau polling kustom mungkin memerlukan generator dan pekerjaan MIB tambahan. - Pengumpulan tanpa agen hanya melihat apa yang dipilih host atau perangkat untuk dipublikasikan. Di Zabbix, log peristiwa Windows, status layanan, dan penghitung kinerja terperinci adalah item key milik agen.
- Tentukan ukuran server berdasarkan metrik, bukan perangkat. Zabbix menghitung satu metrik sebagai satu item ditambah satu trigger ditambah satu grafik, dan menempatkan sekitar 1.000 metrik pada 2 core CPU dan 8 GiB memori, sekitar 10.000 pada 4 core dan 16 GiB.
Apa yang Ditagih PRTG dan 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 menghitung satuan yang berbeda, dan aturannya mudah terlewat sampai penawaran perpanjangan tiba. Model lisensi NPM SolarWinds menyatakan bahwa NPM "dilisensikan menurut jumlah terbesar dari jenis elemen jaringan yang dipantau berikut: Node, Interface, Volume." Bukan jumlah totalnya. Yang terbesar dari ketiganya. Jaringan dengan 80 node dan 900 port switch yang dipantau dilisensikan berdasarkan 900, bukan 80, dan tingkatannya berjalan dari SL100 hingga SLX. Satu polling engine dibatasi pada 12.000 elemen (jumlah total node, interface, dan volume, bukan yang terbesar di antaranya) berapa pun tingkatannya, setelah itu Anda menambahkan polling engine berlisensi lainnya.
Efek praktis kedua model itu sama. Tingkatan lisensi yang menentukan apa yang dipantau. Bukan jaringannya. Interface yang ingin Anda pantau tetap tidak terpantau karena memantaunya melewati batas, dan biaya itu tidak pernah muncul di tagihan.
Dua Jalur Self-Hosted yang Layak Dijalankan
Zabbix adalah satu platform pemantauan yang dibangun di sekitar server pusat, database, dan frontend web. Server melakukan polling perangkat SNMP, menerima data dari agen Windows, dan menerapkan template, trigger, dan peringatan di dalam produk yang sama. Dibandingkan merakit stack pemantauan jaringan berbasis Prometheus, ada lebih sedikit komponen terpisah yang harus Anda integrasikan sendiri. Anda memasangnya, mengarahkannya ke host, dan melampirkan template, yaitu paket item, trigger, dan grafik yang dapat digunakan ulang untuk satu kelas perangkat.
Mulailah dari lisensinya. Halaman lisensi Zabbix menyatakan bahwa setiap versi mulai 7.0 dirilis di bawah GNU Affero General Public License versi 3, dan semua versi hingga 6.4 memakai GPLv2. Tidak ada biaya lisensi untuk perangkat lunaknya pada skala berapa pun. Zabbix menjual dukungan teknis sebagai langganan opsional terpisah, dan meminta pengguna komersial membeli salah satu tingkatannya, tetapi tidak ada bagian produk yang dikunci di balik pembelian itu.
Jalur kedua adalah Grafana, Prometheus, dan VictoriaMetrics. Ini pilihan yang tepat untuk tepat satu situasi: Anda sudah menjalankan stack ini untuk metrik aplikasi dan host, dan seseorang sudah merawatnya. Jika itu Anda, pembangunan lengkap di satu VPS adalah masalah yang sudah terpecahkan dan Anda sedang memperluas sesuatu yang sudah akrab. Tidak ada yang harus mempelajari model data baru.
Celah pada jalur itu adalah perangkat jaringan. Prometheus melakukan scraping endpoint HTTP; ia tidak berbicara SNMP secara langsung. Perangkat jaringan biasanya ditangani melalui snmp_exporter, yang melakukan polling perangkat dan mengekspos hasilnya untuk di-scrape oleh Prometheus. Konfigurasi default-nya menyertakan modul seperti if_mib, sehingga pemantauan interface standar pada banyak switch dan router tidak memerlukan pembuatan konfigurasi kustom. Generator baru menjadi pekerjaan tambahan ketika Anda memerlukan objek khusus vendor, walk kustom, atau MIB yang tidak disertakan secara default. Jalur Prometheus karenanya memiliki lebih banyak bagian untuk dirawat daripada Zabbix, tetapi generator tidak wajib untuk setiap perangkat.
LibreNMS adalah nama ketiga di ruang ini, dibangun di sekitar penemuan otomatis: ia menjelajahi jaringan melalui SNMP, CDP, LLDP, OSPF, BGP, dan ARP untuk menemukan apa yang ada. Ini opsi yang masuk akal ketika penemuan adalah prioritas. Ia tidak mengubah pertanyaan pengumpulan Windows, dan di situlah keputusan ini ditentukan.
Bagaimana Setiap Jalur Melihat Host Windows
Pemantauan Windows dapat melibatkan SNMP, WMI jarak jauh, atau agen terpasang. Jalur mana yang berlaku bergantung pada produk pemantauan dan metrik yang dikumpulkan. Khusus di Zabbix, pemeriksaan WMI bawaan berjalan melalui agen Windows.
SNMP
Polling SNMP meminta perangkat memberikan nilai terkini dari sebuah objek bernomor, yang dialamatkan oleh OID, yaitu posisi di dalam MIB perangkat. Yang kembali adalah apa pun yang dipublikasikan perangkat dan tidak lebih. Pada switch terkelola, firewall, atau UPS, itu biasanya cukup: penghitung interface, status port, tingkat kesalahan, suhu, kesehatan chassis.
Di Windows gambarannya lebih tipis. Pemberitahuan penghentian Microsoft untuk SNMP dan WMI SNMP Provider mengonfirmasi bahwa kedua fitur itu sudah usang, jadi saya akan memperlakukan SNMP Windows sebagai jalur kompatibilitas lama, bukan sebagai default untuk penerapan baru. Zabbix masih menyediakan template Windows by SNMP, tetapi agen bawaan memberi Anda visibilitas yang jauh lebih besar ke dalam sistem operasi.
WMI
WMI dapat dikueri dari jarak jauh tanpa memasang agen pemantauan pada target, itulah sebabnya produk seperti PRTG dapat memakainya sebagai metode pengumpulan Windows tanpa agen. Zabbix bekerja secara berbeda. Pemeriksaan WMI bawaannya, wmi.get dan wmi.getall, adalah item key milik agen Windows, sehingga agen Zabbix atau agen 2 yang menjalankan kueri tersebut di mesin yang dipantau.
WMI jarak jauh juga membawa persyaratan jaringannya sendiri ketika produk pemantauan memakainya secara langsung. Pada sistem Windows saat ini, RPC dimulai di port TCP 135 dan biasanya menegosiasikan koneksi melalui rentang port TCP tinggi yang dinamis, umumnya 49152 hingga 65535. Firewall dan izin WMI pada target harus mengizinkan koneksi tersebut.
Untuk perbandingan ini, perbedaannya lebih penting daripada protokolnya sendiri: PRTG dapat memakai WMI jarak jauh tanpa agen pemantauan terpasang, sementara Zabbix mendapatkan visibilitas WMI khusus Windows-nya melalui agennya.
Agen Bawaan
Agen adalah tempat kedalaman khusus Windows berada. Dokumentasi Zabbix mencantumkan key khusus Windows: eventlog untuk pemantauan log peristiwa Windows, perf_counter untuk penghitung kinerja Windows apa pun, service.discovery dan service.info untuk status layanan. Semuanya adalah item key milik agen.
Biayanya adalah penerapan. Agen di setiap Windows Server dan setiap workstation yang Anda pedulikan berarti satu paket untuk didistribusikan, satu versi untuk dijaga tetap mutakhir, dan satu aturan firewall untuk dirawat. Itu komitmen operasional yang terus berjalan, dan itulah penyeimbang dari penghematan lisensi.
Pengumpulan tanpa agen dibatasi oleh apa yang dipilih host atau perangkat untuk dipublikasikan, dan di Zabbix log peristiwa serta penghitung kinerja terperinci berada di balik item key milik agen.
Berdampingan
Perbandingan ini bertumpu pada empat hal: apakah alat tersebut melakukan polling perangkat jaringan melalui SNMP sama sekali, apakah ia memiliki agen Windows, seberapa dalam ia bisa melihat ke dalam host Windows, dan seberapa banyak perakitan yang memisahkan Anda dari sistem yang berfungsi. Lisensi berada di sampingnya karena itulah alasan evaluasi ini dimulai.
| Tool | Polling perangkat SNMP | Pemantauan Windows | Upaya penyiapan | Lisensi |
|---|---|---|---|---|
| Zabbix | Tertanam | Agen: log peristiwa, status layanan, penghitung kinerja, dan WMI; status kasar melalui SNMP | Sedang: satu server, lalu template | AGPLv3, tanpa biaya lisensi; dukungan dijual terpisah |
Grafana + Prometheus + VictoriaMetrics (+ snmp_exporter) | Tidak bawaan; memerlukan snmp_exporter sebagai komponen terpisah | Tanpa agen Windows bawaan; metrik host berasal dari exporter terpisah; log peristiwa tidak didukung secara bawaan | Tinggi: banyak komponen; SNMP kustom mungkin memerlukan pekerjaan generator | Komponen open source, tanpa biaya lisensi |
| Pemantau uptime dan status | Tidak ada | Hanya keterjangkauan layanan dan waktu respons | Rendah: hitungan menit | Bervariasi menurut alat |
Jika kebutuhannya adalah "beri tahu saya dalam satu menit ketika sebuah layanan berhenti merespons," pemantau uptime adalah alat dengan ukuran yang tepat dan dua lainnya berlebihan untuk itu. Yang tidak akan dilakukannya adalah melakukan polling switch untuk throughput interface atau membaca penghitung kinerja Windows, sehingga ia bukan pengganti PRTG atau SolarWinds. Ini pekerjaan berbeda yang kadang disangka sama.
Mana yang Harus Dijalankan
Jalankan Zabbix. Untuk jaringan yang didominasi Windows tanpa investasi Prometheus yang sudah ada, ini jalur yang jauh lebih pendek. Anda tetap punya server, database, dan frontend web untuk dioperasikan, tetapi model pemantauan, template, dan peringatan hidup di dalam satu produk alih-alih dirakit dari beberapa komponen pemantauan.
Untuk penerapan pemantauan jangka panjang, gunakan cabang LTS Zabbix saat ini alih-alih rilis standar jangka pendek. Siklus hidup LTS Zabbix memberi setiap rilis tiga tahun dukungan penuh diikuti dua tahun dukungan terbatas, yang di sini lebih penting daripada mengejar rilis fitur terbaru.
Pengecualiannya sempit dan spesifik. Jika tim Anda sudah menjalankan Grafana dan Prometheus di produksi untuk metrik aplikasi dan host, dan seseorang sudah memiliki stack itu, maka snmp_exporter adalah tambahan pada sesuatu yang sudah dirawat, bukan sistem kedua yang harus dirawat. Syarat itu bersifat kumulatif: kedua bagiannya harus terpenuhi. Instance Grafana terbengkalai yang dipasang satu orang tahun lalu tidak memenuhi syarat.
Dan jika tidak ada yang punya waktu, perpanjang saja. Itu bukan sikap ragu. Itu situasi berbeda dengan jawaban benar yang berbeda. Peralihan mengubah tagihan lisensi menjadi tagihan operasional: penerapan agen, pekerjaan template, upgrade, dan seseorang yang cukup memahami sistem untuk memperbaikinya pada pukul 2 pagi. Tim yang sudah penuh kapasitas akan mengerjakannya dengan buruk atau tidak sama sekali, dan pemantauan yang tidak dirawat lebih buruk daripada pemantauan yang mahal karena ia gagal dalam diam.
Pendekatan hibrida itu nyata: pertahankan produk lama pada inti sistem kritis yang terus menyusut, pindahkan semua yang lain ke Zabbix, dan biarkan tingkatan lisensi turun seiring waktu. Ini berhasil. Ini juga berarti menjalankan dua sistem pemantauan dan merekonsiliasi peringatannya, jadi perlakukan sebagai keadaan transisi dengan tanggal akhir.
Apa yang Tidak Selamat dari Perpindahan
Panduan migrasi Zabbix sendiri memiliki bagian berjudul "Apa yang TIDAK dimigrasikan," dan daftarnya lebih panjang dari yang tersirat dalam kata "migrasi". Data historis dan pembacaan sensor tidak ikut. Notifikasi dan dependensi kustom PRTG tidak ikut. Peta dan dashboard tidak ikut, karena kedua produk memodelkannya dengan cara yang cukup berbeda sehingga membangun ulang lebih baik daripada menerjemahkan. Sensor itu sendiri tidak ikut, karena Zabbix bekerja dengan konsep yang sama sekali berbeda.
Nama perangkat, alamat IP, dan jenis interface dapat dibawa. Itu pun melalui skrip ekspor dan impor kustom terhadap kedua API. Panduan itu menyatakan dengan jelas bahwa tidak ada alat resmi untuk bermigrasi langsung antara kedua platform.
Satu tim mendokumentasikan biayanya dalam praktik: sekitar 500 VM dan server fisik, sekitar tujuh tahun di PRTG, dibangun ulang dari nol selama enam bulan waktu proyek berprioritas rendah. 2.500 sensor PRTG mereka menjadi 43.000 item Zabbix, gambaran jelas betapa berbedanya cara kedua sistem menghitung.
"Mulai dari nol. Tidak ada opsi 'Tekan tombol ini dan migrasikan' dari PRTG ke Zabbix, dan kalaupun ada, hal semacam ini adalah kesempatan baik untuk tidak mengulangi kesalahan desain sebelumnya."
Itu pengalaman satu organisasi, bukan tolok ukur. Infrastruktur yang lebih kecil tidak akan menghasilkan angka seperti itu. Yang bisa dibawa adalah asumsi perencanaannya: anggarkan waktu membangun ulang, bukan waktu migrasi.
Urutkan pembangunan ulang berdasarkan apa yang tidak bisa Anda tinggalkan. Jika kekhawatiran Anda adalah kesinambungan peringatan, bangun ulang aturan notifikasi terlebih dahulu dan biarkan dashboard menyusul. Jika yang penting riwayat laporan, ekspor apa yang Anda butuhkan sebelum lisensi lama berakhir. Ia tidak akan ikut bersama Anda.
Menentukan Ukuran Server
Persyaratan perangkat keras Zabbix menempatkan instalasi kecil sekitar 1.000 metrik yang dipantau pada 2 core CPU dan 8 GiB memori, dan instalasi menengah sekitar 10.000 metrik pada 4 core dan 16 GiB. Itulah angka-angka yang dijadikan dasar pengajuan.
Satuan adalah tempat penentuan ukuran menjadi salah. Zabbix mendefinisikan satu metrik yang dipantau sebagai satu item ditambah satu trigger ditambah satu grafik. Metrik bukan perangkat dan bukan host. Satu Windows Server menyumbang metrik sebanyak item yang Anda konfigurasi: CPU, memori, setiap sistem berkas, setiap layanan, setiap penghitung yang Anda sampel. Jumlah perangkat adalah panduan yang buruk untuk mesin yang Anda butuhkan. Infrastruktur yang terdengar kecil bisa jatuh ke kategori menengah tanpa ada yang melakukan sesuatu yang tidak biasa.
Dua hal mendorong angka naik lebih cepat daripada jumlah host. Frekuensi polling yang pertama: memangkas interval refresh menjadi setengah menggandakan laju tulis untuk setiap item pada interval itu. Retensi riwayat yang kedua, karena database tumbuh seiring lamanya Anda menyimpan nilai mentah. Jumlah perangkat berpengaruh terutama lewat jumlah item yang dipantau yang disumbangkan setiap perangkat.
Jika infrastruktur Anda tetap dekat dengan contoh 1.000 metrik dengan interval refresh biasa dan retensi sedang, kategori kecil adalah titik awal yang masuk akal. Jika Anda menyampel penghitung kinerja setiap tiga puluh detik dan menyimpan riwayat mentah selama setahun, tidak. Zabbix secara eksplisit menyatakan bahwa angka yang diterbitkannya adalah "contoh ukuran dan konfigurasi perangkat keras untuk memulai," dan merekomendasikan pengujian di lingkungan staging sebelum berkomitmen pada perangkat keras produksi. Itu peringatan dari vendornya sendiri. Anggap itu serius.
Zabbix hanya mendukung komponen servernya di Linux dan UNIX; di Windows, hanya agen yang didukung.
Metrik bukanlah perangkat, dan pengali di antara keduanya adalah yang menentukan ukuran mesin.
Bangun di VPS Linux dengan akses root, NVMe, dan tenaga AMD EPYC.
Lihat Paket LinuxDi Mana Menempatkan Server Pemantauan
Jika Anda memerlukan pemantauan yang tetap hidup saat seluruh lokasi padam, tempatkan server Zabbix pusat di luar domain kegagalan lokasi tersebut. Dengan begitu, hilangnya uplink lokasi bisa membuat jaringan yang dipantau offline tanpa ikut menjatuhkan server pemantauan.
Untuk jaringan privat, sebuah proxy Zabbix dapat ditempatkan di dalam lokasi dan mengumpulkan data dari sistem di sekitarnya. Proxy dapat menangani pemeriksaan SNMP dan agen secara lokal, mengirim data yang dikumpulkan kembali ke server pusat, dan menyangga data pemantauan selama konektivitas di antara keduanya terputus. Ini memungkinkan server pusat tetap berada di luar lokasi tanpa mengharuskan setiap switch, firewall, dan host Windows privat dapat dijangkau langsung dari internet.
VPS adalah salah satu tempat praktis untuk menjalankan server pusat itu. Cloudzy menawarkan Server Zabbix sebagai penerapan sekali klik di Ubuntu Server 24.04 LTS jika Anda ingin melewati instalasi awal dan langsung mengonfigurasi host dan template.
Pertanyaan yang Sering Diajukan
Apakah Zabbix Benar-Benar Gratis?
Ya. Zabbix dirilis di bawah GNU Affero General Public License versi 3 mulai versi 7.0, dan tidak ada biaya lisensi untuk perangkat lunaknya berapa pun jumlah perangkat atau metrik yang Anda pantau. Zabbix menjual dukungan teknis sebagai langganan opsional terpisah, tetapi tidak ada fitur produk yang dikunci di baliknya. Biaya menjalankan Zabbix adalah server tempatnya berjalan dan jam kerja yang Anda habiskan untuk mengoperasikannya.
Apakah Saya Perlu Memasang Agen di Setiap Windows Server?
Tidak di setiap mesin Windows, tetapi jika Anda menginginkan kedalaman pemantauan Windows bawaan Zabbix, rencanakan pemasangan agen di server yang paling Anda pedulikan. SNMP bisa memberikan data kasar tanpa agen, meskipun fitur SNMP Windows dari Microsoft sudah usang. Pemeriksaan WMI bawaan Zabbix juga berjalan melalui agen Windows-nya, jadi WMI bukan jalur pengumpulan tanpa agen yang langsung di Zabbix. Gunakan agen untuk log peristiwa, penemuan layanan, kueri WMI, dan penghitung kinerja terperinci; simpan SNMP tanpa agen terutama untuk perangkat keras jaringan dan kasus Windows lama.
Bisakah Saya Menjalankan Server Pemantauan di Windows?
Tidak dengan Zabbix. Dokumentasi persyaratan Zabbix mencantumkan komponen server hanya didukung di Linux dan platform UNIX lainnya, dan menyatakan bahwa "UNIX adalah satu-satunya sistem operasi yang dapat secara konsisten memberikan kinerja, toleransi kesalahan, dan ketahanan yang diperlukan." Dukungan Windows mencakup agen Zabbix dan agen 2, yaitu yang Anda pasang di mesin yang dipantau. Server pemantauan berada di host Linux; infrastruktur Windows adalah yang diawasinya.
Apakah Prometheus Melakukan Pemantauan SNMP?
Tidak dengan sendirinya. Prometheus melakukan scraping endpoint HTTP dan memakai snmp_exporter untuk mengumpulkan data dari perangkat SNMP. Konfigurasi default-nya mencakup banyak switch dan router umum, sementara objek khusus vendor atau polling kustom mungkin memerlukan konfigurasi MIB tambahan dan generator.


Diskusi
Komentar
Masuk untuk bergabung dalam diskusi.