PRTG tính phí theo cảm biến, tức là một chỉ số được giám sát trên một thiết bị, không phải bản thân thiết bị. Các gói của chính Paessler đặt tỷ lệ thực tế ở khoảng mười trên một: 500 cảm biến bao phủ khoảng 50 thiết bị, 10.000 bao phủ khoảng 1.000. Thêm một stack switch và bắt đầu theo dõi thông lượng theo từng cổng, con số sẽ tăng nhanh hơn cả hạ tầng. SolarWinds đếm theo cách khác và đi đến cùng một kết quả.
Với một mạng chủ yếu là Windows, tôi sẽ đưa vào danh sách rút gọn hai lựa chọn tự lưu trữ thay thế PRTG và SolarWinds: Zabbix, hoặc một stack dựa trên Prometheus nếu đội của bạn đã vận hành sẵn. Việc chọn giữa hai bên phụ thuộc vào những gì mỗi bên nhìn thấy được trên một máy chủ Windows, và nó cần gì để nhìn thấy điều đó.
Một lưu ý trước tiên. Nếu không ai trong đội có giờ rảnh, PRTG và SolarWinds vẫn là câu trả lời đúng. Sự dễ dùng của chúng là một sản phẩm bạn mua có chủ đích, và nó đáng tiền. Việc chuyển đổi mô tả ở đây tiêu tốn giờ công thay cho phí bản quyền, và đó là một sự đánh đổi, không phải nâng cấp.
Tóm tắt nhanh
- Lựa chọn mặc định là Zabbix. Zabbix gom polling SNMP, agent Windows, template và cảnh báo vào một nền tảng giám sát duy nhất. Bạn vẫn vận hành máy chủ Zabbix, cơ sở dữ liệu và giao diện web, nhưng không phải lắp ráp các thành phần giám sát riêng lẻ chỉ để bắt đầu.
- Ngoại lệ là một đội đã chạy sẵn Grafana và Prometheus cho chỉ số ứng dụng và máy chủ. Mở rộng thứ bạn đang bảo trì rẻ hơn dựng một hệ thống giám sát thứ hai.
- Prometheus không tự polling các thiết bị mạng.
snmp_exporterlấp khoảng trống đó; cấu hình mặc định của nó bao phủ nhiều switch và router phổ biến, trong khi các đối tượng đặc thù của hãng hoặc polling tùy chỉnh có thể cần đến generator và thêm công việc với MIB. - Thu thập không cần agent chỉ thấy những gì máy chủ hoặc thiết bị chọn công bố. Trong Zabbix, nhật ký sự kiện Windows, trạng thái dịch vụ và các bộ đếm hiệu năng chi tiết là các item key của agent.
- Định cỡ máy chủ theo chỉ số, không phải theo thiết bị. Zabbix tính một chỉ số là một item cộng một trigger cộng một biểu đồ, và xếp khoảng 1.000 chỉ số trên 2 nhân CPU và 8 GiB bộ nhớ, khoảng 10.000 trên 4 nhân và 16 GiB.
PRTG và SolarWinds thu tiền cho cái gì
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 đếm một đơn vị khác, và quy tắc này dễ bị bỏ qua cho đến khi báo giá gia hạn tới. Mô hình cấp phép NPM của SolarWinds nêu rằng NPM "được cấp phép theo số lượng lớn nhất trong các loại phần tử mạng được giám sát sau: Node, Interface, Volume." Không phải tổng. Là số lớn nhất trong ba. Một mạng có 80 node và 900 cổng switch được giám sát sẽ tính phí theo 900, không phải 80, và các gói chạy từ SL100 đến SLX. Một polling engine bị giới hạn ở 12.000 phần tử (tổng của node, interface và volume, không phải số lớn nhất) bất kể gói nào, sau đó bạn phải thêm một polling engine có bản quyền khác.
Tác động thực tế của cả hai mô hình là như nhau. Gói bản quyền quyết định thứ gì được giám sát. Không phải mạng. Những interface bạn muốn theo dõi vẫn không được theo dõi vì theo dõi chúng sẽ vượt ngưỡng, và chi phí đó không bao giờ xuất hiện trên hóa đơn.
Hai hướng tự lưu trữ đáng để chạy
Zabbix là một nền tảng giám sát duy nhất được xây quanh một máy chủ trung tâm, cơ sở dữ liệu và giao diện web. Máy chủ polling các thiết bị SNMP, nhận dữ liệu từ agent Windows, và áp dụng template, trigger và cảnh báo trong cùng một sản phẩm. So với việc lắp ráp một stack giám sát mạng dựa trên Prometheus, có ít thành phần riêng lẻ hơn mà bạn phải tự tích hợp. Bạn cài đặt, trỏ nó tới các máy chủ, và gắn template, tức các gói item, trigger và biểu đồ tái sử dụng được cho một lớp thiết bị.
Bắt đầu từ giấy phép. Trang giấy phép của Zabbix nêu rằng mọi phiên bản từ 7.0 trở đi được phát hành theo GNU Affero General Public License phiên bản 3, và mọi thứ đến 6.4 là GPLv2. Không có phí bản quyền cho phần mềm ở bất kỳ quy mô nào. Zabbix bán hỗ trợ kỹ thuật như một gói đăng ký tùy chọn riêng, và đề nghị người dùng thương mại mua một mức nào đó, nhưng không có gì trong sản phẩm bị khóa sau khoản mua đó.
Hướng thứ hai là Grafana, Prometheus và VictoriaMetrics. Đây là lựa chọn đúng cho đúng một tình huống: bạn đã chạy stack này cho chỉ số ứng dụng và máy chủ, và đã có người bảo trì nó. Nếu đó là bạn, bản dựng đầy đủ trên một VPS là một bài toán đã có lời giải và bạn đang mở rộng thứ quen thuộc. Không ai phải học một mô hình dữ liệu mới.
Khoảng trống trên hướng đó là các thiết bị mạng. Prometheus scrape các endpoint HTTP; nó không nói SNMP trực tiếp. Thiết bị mạng thường được xử lý qua snmp_exporter, thành phần polling thiết bị và đưa kết quả ra cho Prometheus scrape. Cấu hình mặc định của nó bao gồm các module như if_mib, nên việc giám sát interface tiêu chuẩn trên nhiều switch và router không cần tạo cấu hình tùy chỉnh. Generator chỉ trở thành việc phát sinh khi bạn cần các đối tượng đặc thù của hãng, các lượt walk tùy chỉnh hoặc MIB không có sẵn mặc định. Vì vậy hướng Prometheus có nhiều phần phải bảo trì hơn Zabbix, nhưng generator không bắt buộc cho mọi thiết bị.
LibreNMS là cái tên thứ ba trong mảng này, xây quanh khả năng tự động phát hiện: nó quét mạng qua SNMP, CDP, LLDP, OSPF, BGP và ARP để tìm những gì đang có. Đó là lựa chọn hợp lý khi phát hiện là ưu tiên. Nó không thay đổi câu hỏi về thu thập trên Windows, và đó chính là nơi quyết định này được định đoạt.
Mỗi hướng nhìn máy chủ Windows như thế nào
Giám sát Windows có thể dùng SNMP, WMI từ xa hoặc một agent được cài đặt. Hướng nào áp dụng tùy thuộc vào sản phẩm giám sát và chỉ số đang thu thập. Riêng trong Zabbix, các kiểm tra WMI tích hợp chạy qua agent Windows.
SNMP
Một lượt polling SNMP hỏi thiết bị về giá trị hiện tại của một đối tượng được đánh số, định địa chỉ bằng OID, tức một vị trí trong MIB của thiết bị. Thứ trả về là bất cứ gì thiết bị công bố và không gì khác. Trên một switch được quản lý, tường lửa hoặc UPS, thế thường là đủ: bộ đếm interface, trạng thái cổng, tỷ lệ lỗi, nhiệt độ, tình trạng khung máy.
Trên Windows bức tranh mỏng hơn. Thông báo ngừng hỗ trợ của Microsoft cho SNMP và WMI SNMP Provider xác nhận cả hai tính năng đã bị loại bỏ dần, nên tôi sẽ coi SNMP trên Windows là đường tương thích cũ thay vì mặc định cho một triển khai mới. Zabbix vẫn cung cấp template Windows by SNMP, nhưng agent gốc cho bạn cái nhìn sâu hơn đáng kể vào hệ điều hành.
WMI
WMI có thể được truy vấn từ xa mà không cần cài agent giám sát trên máy đích, đó là lý do các sản phẩm như PRTG có thể dùng nó làm phương thức thu thập Windows không cần agent. Zabbix hoạt động khác. Các kiểm tra WMI tích hợp của nó, wmi.get và wmi.getall, là các item key của agent Windows, nên agent Zabbix hoặc agent 2 thực hiện các truy vấn đó trên máy được giám sát.
WMI từ xa cũng kéo theo các yêu cầu mạng riêng khi một sản phẩm giám sát dùng nó trực tiếp. Trên các hệ thống Windows hiện nay, RPC bắt đầu ở cổng TCP 135 và thường thương lượng kết nối qua dải cổng TCP cao động, thông thường từ 49152 đến 65535. Tường lửa và quyền WMI trên máy đích phải cho phép kết nối.
Với so sánh này, sự khác biệt quan trọng hơn bản thân giao thức: PRTG có thể dùng WMI từ xa mà không cần cài agent giám sát, trong khi Zabbix có được khả năng nhìn WMI đặc thù cho Windows thông qua agent của mình.
Agent gốc
Agent là nơi chứa chiều sâu đặc thù cho Windows. Tài liệu của Zabbix liệt kê các key đặc thù cho Windows: eventlog để giám sát nhật ký sự kiện Windows, perf_counter cho bất kỳ bộ đếm hiệu năng Windows nào, service.discovery và service.info cho trạng thái dịch vụ. Tất cả đều là item key của agent.
Chi phí nằm ở triển khai. Một agent trên mọi Windows Server và mọi máy trạm bạn quan tâm là một gói cần đẩy ra, một phiên bản cần giữ cập nhật và một quy tắc tường lửa cần duy trì. Đó là một cam kết vận hành thường trực, và nó là đối trọng của khoản tiết kiệm bản quyền.
Thu thập không cần agent bị giới hạn bởi những gì máy chủ hoặc thiết bị chọn công bố, và trong Zabbix, nhật ký sự kiện cùng các bộ đếm hiệu năng chi tiết nằm sau các item key của agent.
Đặt cạnh nhau
So sánh xoay quanh bốn điều: công cụ có polling thiết bị mạng qua SNMP hay không, có agent Windows hay không, nhìn được sâu đến đâu vào một máy chủ Windows, và bao nhiêu công lắp ráp nằm giữa bạn và một hệ thống chạy được. Bản quyền đứng cạnh những điều đó vì đó là lý do việc đánh giá bắt đầu.
| Công cụ | Polling thiết bị SNMP | Giám sát Windows | Công sức thiết lập | Bản quyền |
|---|---|---|---|---|
| Zabbix | Tích hợp sẵn | Agent: nhật ký sự kiện, trạng thái dịch vụ, bộ đếm hiệu năng và WMI; trạng thái thô qua SNMP | Vừa phải: một máy chủ, rồi đến template | AGPLv3, không phí bản quyền; hỗ trợ bán riêng |
Grafana + Prometheus + VictoriaMetrics (+ snmp_exporter) | Không tích hợp sẵn; cần snmp_exporter như một thành phần riêng | Không có agent Windows gốc; chỉ số máy chủ đến từ các exporter riêng; nhật ký sự kiện không hỗ trợ gốc | Cao: nhiều thành phần; SNMP tùy chỉnh có thể cần làm việc với generator | Thành phần mã nguồn mở, không phí bản quyền |
| Công cụ giám sát uptime và trạng thái | Không gì | Chỉ khả năng truy cập dịch vụ và thời gian phản hồi | Thấp: vài phút | Tùy theo công cụ |
Nếu yêu cầu là "báo cho tôi trong vòng một phút khi một dịch vụ ngừng phản hồi," thì công cụ giám sát uptime là công cụ đúng cỡ và hai thứ còn lại là quá tay cho việc đó. Thứ nó không làm là polling switch để lấy thông lượng interface hay đọc bộ đếm hiệu năng Windows, nên nó không thay thế được PRTG hay SolarWinds. Đó là một việc khác đôi khi bị nhầm là cùng một việc.
Nên chạy cái nào
Chạy Zabbix. Với một mạng chủ yếu là Windows và chưa đầu tư vào Prometheus, đây là con đường ngắn hơn rất nhiều. Bạn vẫn có một máy chủ, cơ sở dữ liệu và giao diện web để vận hành, nhưng mô hình giám sát, template và cảnh báo nằm trong một sản phẩm thay vì được lắp ráp từ nhiều thành phần giám sát.
Với một triển khai giám sát lâu dài, hãy dùng nhánh LTS hiện tại của Zabbix thay vì bản phát hành tiêu chuẩn ngắn hạn. Vòng đời LTS của Zabbix cho mỗi bản phát hành ba năm hỗ trợ đầy đủ rồi hai năm hỗ trợ hạn chế, điều này ở đây quan trọng hơn việc đuổi theo bản phát hành tính năng mới nhất.
Ngoại lệ rất hẹp và cụ thể. Nếu đội của bạn đã chạy Grafana và Prometheus trong môi trường production cho chỉ số ứng dụng và máy chủ, và đã có người sở hữu stack đó, thì snmp_exporter là phần bổ sung cho thứ đang được bảo trì thay vì một hệ thống thứ hai phải bảo trì. Điều kiện đó là điều kiện kép: cả hai vế đều phải đúng. Một instance Grafana bị bỏ hoang do một người dựng năm ngoái không đủ điều kiện.
Và nếu không ai có giờ, hãy gia hạn. Đó không phải là né tránh. Đó là một tình huống khác với một câu trả lời đúng khác. Việc chuyển đổi biến hóa đơn bản quyền thành hóa đơn vận hành: triển khai agent, làm template, nâng cấp, và một người hiểu hệ thống đủ để sửa nó lúc 2 giờ sáng. Một đội đã hết công suất sẽ làm việc đó tệ hoặc không làm, và giám sát không được bảo trì tệ hơn giám sát đắt tiền vì nó hỏng trong im lặng.
Phương án lai là có thật: giữ sản phẩm hiện tại cho một lõi hệ thống trọng yếu ngày càng thu hẹp, chuyển mọi thứ khác sang Zabbix, và để gói bản quyền giảm dần theo thời gian. Nó hiệu quả. Nó cũng đồng nghĩa chạy hai hệ thống giám sát và đối chiếu cảnh báo của chúng, nên hãy coi đó là trạng thái chuyển tiếp có ngày kết thúc.
Những gì không sống sót qua cuộc di chuyển
Hướng dẫn di chuyển của chính Zabbix có một mục tiêu đề "Những gì KHÔNG được di chuyển," và danh sách dài hơn những gì từ "di chuyển" gợi ý. Dữ liệu lịch sử và số đọc cảm biến không sang được. Thông báo và phụ thuộc tùy chỉnh của PRTG cũng không. Bản đồ và dashboard cũng không, vì hai sản phẩm mô hình hóa chúng khác nhau đến mức dựng lại tốt hơn dịch lại. Bản thân các cảm biến cũng không, vì Zabbix làm việc với một khái niệm hoàn toàn khác.
Tên thiết bị, địa chỉ IP và loại interface có thể mang sang. Ngay cả điều đó cũng phải qua script xuất và nhập tùy chỉnh với cả hai API. Hướng dẫn nói rõ không có công cụ chính thức nào để di chuyển trực tiếp giữa hai nền tảng.
Một đội đã ghi lại chi phí thực tế: khoảng 500 VM và máy chủ vật lý, khoảng bảy năm dùng PRTG, dựng lại từ đầu trong sáu tháng thời gian dự án ưu tiên thấp. 2.500 cảm biến PRTG của họ trở thành 43.000 item Zabbix, một minh họa rõ ràng cho việc hai hệ thống đếm khác nhau đến mức nào.
"Bắt đầu lại từ đầu. Không có tùy chọn 'Nhấn nút này và di chuyển' từ PRTG sang Zabbix, và kể cả có, một việc như thế này là cơ hội tốt để không lặp lại các sai lầm thiết kế trước đây."
Đó là kinh nghiệm của một tổ chức, không phải chuẩn so sánh. Một hạ tầng nhỏ hơn sẽ không cho ra những con số đó. Điều chuyển sang được là giả định lập kế hoạch: hãy dự trù thời gian dựng lại, không phải thời gian di chuyển.
Sắp xếp việc dựng lại theo thứ bạn không thể thiếu. Nếu mối lo là tính liên tục của cảnh báo, hãy dựng lại quy tắc thông báo trước và để dashboard theo sau. Nếu là lịch sử báo cáo, hãy xuất những gì bạn cần trước khi giấy phép cũ hết hạn. Nó sẽ không đi cùng bạn.
Định cỡ máy chủ
Yêu cầu phần cứng của Zabbix xếp một cài đặt nhỏ khoảng 1.000 chỉ số được giám sát trên 2 nhân CPU và 8 GiB bộ nhớ, và một cài đặt trung bình khoảng 10.000 chỉ số trên 4 nhân và 16 GiB. Đó là những con số để làm căn cứ yêu cầu.
Đơn vị là nơi việc định cỡ đi sai. Zabbix định nghĩa một chỉ số được giám sát là một item cộng một trigger cộng một biểu đồ. Một chỉ số không phải là thiết bị và không phải là máy chủ. Một Windows Server đóng góp số chỉ số bằng số item bạn cấu hình: CPU, bộ nhớ, từng hệ thống tệp, từng dịch vụ, từng bộ đếm bạn lấy mẫu. Số thiết bị là chỉ dẫn kém cho cỗ máy bạn cần. Một hạ tầng nghe có vẻ nhỏ có thể rơi vào dải trung bình mà không ai làm gì bất thường.
Hai thứ đẩy con số lên nhanh hơn số máy chủ. Tần suất polling là thứ nhất: giảm một nửa khoảng làm mới sẽ nhân đôi tốc độ ghi cho mọi item ở khoảng đó. Lưu giữ lịch sử là thứ hai, vì cơ sở dữ liệu lớn lên theo thời gian bạn giữ giá trị thô. Số thiết bị quan trọng chủ yếu qua số item được giám sát mà mỗi thiết bị đóng góp.
Nếu hạ tầng của bạn ở gần ví dụ 1.000 chỉ số với khoảng làm mới thông thường và lưu giữ vừa phải, dải nhỏ là điểm khởi đầu hợp lý. Nếu bạn lấy mẫu bộ đếm hiệu năng mỗi ba mươi giây và giữ một năm lịch sử thô, thì không. Zabbix nói rõ các con số công bố là "ví dụ về kích thước và cấu hình phần cứng để bắt đầu," và khuyến nghị đo hiệu năng trong môi trường staging trước khi cam kết phần cứng production. Đó là lưu ý của chính nhà cung cấp. Hãy hiểu theo đúng nghĩa đen.
Zabbix chỉ hỗ trợ thành phần máy chủ trên Linux và UNIX; trên Windows chỉ agent được hỗ trợ.
Chỉ số không phải là thiết bị, và hệ số nhân giữa chúng mới là thứ quyết định kích thước cỗ máy.
Xây dựng trên VPS Linux với quyền root, NVMe và sức mạnh AMD EPYC.
Xem các gói LinuxĐặt máy chủ giám sát ở đâu
Nếu bạn cần giám sát sống sót qua sự cố toàn bộ cơ sở, hãy giữ máy chủ Zabbix trung tâm bên ngoài miền lỗi của cơ sở đó. Khi ấy mất uplink của cơ sở có thể khiến mạng được giám sát ngoại tuyến mà không kéo theo máy chủ giám sát.
Với một mạng riêng, một Zabbix proxy có thể đặt bên trong cơ sở và thu thập từ các hệ thống xung quanh. Proxy có thể xử lý cục bộ các kiểm tra SNMP và agent, gửi dữ liệu đã thu thập về máy chủ trung tâm, và đệm dữ liệu giám sát khi kết nối giữa hai bên gián đoạn. Điều đó cho phép máy chủ trung tâm nằm ngoài cơ sở mà không đòi hỏi mọi switch, tường lửa và máy chủ Windows riêng phải truy cập trực tiếp được từ internet.
Một VPS là nơi thiết thực để chạy máy chủ trung tâm đó. Cloudzy cung cấp Máy chủ Zabbix dưới dạng triển khai một cú nhấp trên Ubuntu Server 24.04 LTS nếu bạn muốn bỏ qua bước cài đặt ban đầu và đi thẳng vào cấu hình máy chủ và template.
Câu hỏi thường gặp
Zabbix có thực sự miễn phí?
Có. Zabbix được phát hành theo GNU Affero General Public License phiên bản 3 từ phiên bản 7.0 trở đi, và không có phí bản quyền cho phần mềm dù bạn giám sát bao nhiêu thiết bị hay chỉ số. Zabbix bán hỗ trợ kỹ thuật như một gói đăng ký tùy chọn riêng, nhưng không tính năng nào của sản phẩm bị khóa sau nó. Chi phí chạy Zabbix là máy chủ nó chạy trên đó và số giờ bạn bỏ ra để vận hành.
Tôi có cần cài agent trên mọi Windows Server không?
Không phải trên mọi máy Windows, nhưng nếu bạn muốn chiều sâu giám sát Windows gốc của Zabbix, hãy lên kế hoạch cài agent trên các máy chủ bạn quan tâm nhất. SNMP có thể cung cấp dữ liệu thô không cần agent, dù tính năng SNMP của Windows đã bị Microsoft ngừng hỗ trợ. Các kiểm tra WMI tích hợp của Zabbix cũng chạy qua agent Windows, nên WMI không phải là đường thu thập không cần agent trực tiếp trong Zabbix. Dùng agent cho nhật ký sự kiện, phát hiện dịch vụ, truy vấn WMI và bộ đếm hiệu năng chi tiết; giữ SNMP không cần agent chủ yếu cho phần cứng mạng và các trường hợp Windows cũ.
Tôi có thể chạy máy chủ giám sát trên Windows không?
Với Zabbix thì không. Tài liệu yêu cầu của Zabbix liệt kê thành phần máy chủ chỉ được hỗ trợ trên Linux và các nền tảng UNIX khác, và nêu rằng "UNIX là hệ điều hành duy nhất có thể cung cấp ổn định hiệu năng, khả năng chịu lỗi và độ bền cần thiết." Hỗ trợ Windows bao gồm agent Zabbix và agent 2, tức thứ bạn cài trên các máy được giám sát. Máy chủ giám sát nằm trên một máy chủ Linux; hạ tầng Windows là thứ nó theo dõi.
Prometheus có giám sát SNMP không?
Tự nó thì không. Prometheus scrape các endpoint HTTP và dùng snmp_exporter để thu thập từ các thiết bị SNMP. Cấu hình mặc định của nó bao phủ nhiều switch và router phổ biến, trong khi các đối tượng đặc thù của hãng hoặc polling tùy chỉnh có thể cần thêm cấu hình MIB và generator.
Thảo luận
Bình luận
Đăng nhập để tham gia thảo luận.