• 更好的網路管理關鍵就是了解網路的頻寬和資源消耗。
• 避免頻寬和伺服器效能的衝突。
• 找出什麼應用程式或伺服器在使用你的頻寬
• 可以替您的客戶主動提供更好服務品質
• 根據實際負載，減少購買頻寬和硬體的成本

使用簡單的 Windows 界面，你可以設置監測感應器和創建使用報告，可遠程存取 PRTG Network Monitor 在一個內置的網路伺服器提供使用的圖表。支援所有網路使用數據的常用方法:

• SNMP: Simple Network Management Protocol 是收集頻寬和網路使用情況數據的基本方法。它可以用來監測使用頻寬路由器和交換機以及裝置讀取像是記憶體，CPU負載等。
• Packet Sniffing: 藉著內置的Packet ，PRTG可以檢查所有網路數據封包，沿著LAN或WLAN去計算頻寬使用率。
• NetFlow: NetFlow的協議得到了大多數Cisco路由器測量頻寬使用，雖然是最複雜類型設置也是最強有力的方法，適合高流量的網路。

基於 Sniffer 和 NetFlow 的監控，PRTG 可以任意計算每個 IP 接口的頻寬，例如:在你的網路顯示當前的 Top Talkers, Top Connections 和 Top Protocols。 

這應用程式可以在所有 Windows 版本執行，和從 Cisco, HP, 3Com, Linksys, Nortel 等最多的網路產品相容，以及其他各種設備 (如Windows PCs或網路印表機)。

Licenses of PRTG differ by two parameters:

• The maximum number of sensors.
• The number of allowed core server installations.

sensors數計算:

The licensing options are based on the number of sensors. Each of the following items counts as one sensor:

• Monitoring traffic/bandwidth on one port of any device via SNMP (e.g. switch, firewall, server) using the MIB2 standard
• Monitoring errors/min, unicast packets/s, non-unicast packets/s on one port of a device via SNMP using the MIB2 standard
• Monitoring one other system parameter via SNMP (e.g. CPU, diskspace etc.) that is accessible via one OID value
• Monitoring traffic going through one local network card (NIC) via Packet Sniffing. If you use filtering then each set of filters counts as one sensor.
• Monitoring of one stream of data traffic via xFlow (NetFlow, sFlow) Monitoring. If you use filtering then each filterset counts as one sensor.

The number of actual hardware devices is not taken into account at all, only the number of sensors. For the "unlimited licenses" the number of sensors that can be monitored is not programmatically limited by the software itself, but may be limited by your software, hardware and network.

Recommended setup for most PRTG users
We recommend that you run the PRTG core server as well as all remote probes 

• directly on x64 PC/server hardware
• on Windows Server 2012 R2, Windows Server 2016, or Windows 10.
• .NET Framework 4.7.2 or later must be installed on your system.

There are many parameters that influence the performance and stability of PRTG, but for the vast majority of PRTG users the following sizing recommendations for the hardware of the PRTG server work fine.

V =OK
▲=not recommended
* You need to properly configure your virtual system to assign sufficient dedicated resources.
★=not officially supported: please contact 友環業務

Note: Most PRTG users have 10 sensors per device on average. So, for example, a 1,000 sensors license is enough to monitor 100 devices in most cases.

System Requirements for PRTG Core Server (PRTG on Premises)

To install a PRTG on premises server and work with it, you need to meet the following requirements:

• A PC or server with at least a dual core CPU and a minimum of 2048 MB RAM is sufficient for the PRTG server.
• The operating system Microsoft Windows Server 2012 R2, Microsoft Windows Server 2016, or Microsoft Windows 10.
• A web browser to access the web interface. The following browsers are officially supported:
  • Google Chrome 67 or later (recommended)
  • Mozilla Firefox 61 or later
  • Microsoft Internet Explorer 11

★ PRTG hosted by Paessler does not require any hardware for the PRTG server, but at least one remote probe installation is necessary to monitor your local network when using PRTG hosted by Paessler.

System Requirements for PRTG Remote Probes

• Hardware
  A PC or server with at least a dual core CPU and a minimum of 2048 MB RAM is sufficient for remote probes.
• Operating system
  We recommend that you use Microsoft Windows Server 2012 R2, Microsoft Windows Server 2016, or Microsoft Windows 10 for remote probes.
• Stable network connection
  Remote probes require a stable network connection between the PRTG server and the remote probe. Remote probes that connect to a PRTG hosted by Paessler server need a reliable internet connection. Unstable connections, for example via 3G, might work but it is possible that you lose monitoring data if the connection is non-reliable.

★ Why are remote probes helpful for monitoring with PRTG? Because they can extend your monitoring.

• Remote probes allow you to monitor different sub-networks that are separated from your PRTG on premises core server by a firewall and to keep an eye on remote locations. You can install one or more remote probes.
• Remote probes are useful if you want to distribute monitoring load by taking it from the system running the PRTG core server and putting it on one or more remote probe machines.
• You will need a remote probe if you want to monitor your local network using a PRTG hosted by Paessler instance.
• Remote probes may be suitable monitoring components in several individual scenarios that depend on your custom network setup.

Performance considerations
Most PRTG installations will never run into performance issues, but please note the following points that can affect performance:

• As a "Rule of thumb" we can say: Typical PRTG installations almost never run into performance issues when they stay under 5,000 sensors, under 30 remote probes, and under 30 user accounts. If your scenario is listed above go ahead and install PRTG.
• Please use a physical machine. Yes, really! There are several reasons why we recommend that you run PRTG (core server and remote probes) on real hardware, especially for thousands of sensors. Each sensor request will have to go through many virtualization layers, which costs performance and makes measurements less exact. In our experience, a physical machine simply works best for a thousand sensors and more. Our recommendation to use real hardware is valid for the PRTG core server and for remote probes. If you must run PRTG on a virtual machine, please stay below 5,000 sensors per virtual machine and consider running several PRTG core server instances instead.
• Halfed performance for each additional cluster node. In a PRTG failover cluster, the monitoring load doubles with each cluster node. In a single failover cluster, please divide our recommended numbers from above in half.  We recommend a single failover setup if you need fail-safe monitoring. This consists of two PRTG core servers, each working as a cluster node.
• When you use more than 5,000 sensors you should use 5 minutes intervals (instead of 1 minute) or longer.
• Some sensor types create much more load than others. For example, Ping and SNMP sensors create much less load than complex sensors like xFlow sensors, VMware sensors, Sensor Factory sensors, WMI sensors, or Syslog/Trap receiver sensors, to name just a few examples.
• We recommend that you stay below 30 active user accounts for each PRTG core server. You can work well with more users if these do not all use the UI at the same time (including public dashboards).
• Try to keep the usage of the following features down: Many quickly refreshed dashboards ("Maps"), frequent generation of huge sensor reports, heavy usage of packet sniffing, factory sensors and toplists, frequent automatically scheduled auto-discoveries for large network segments, constant queries of monitoring data via the API, among others.
• Load balancing: Balancing the monitoring load is possible using remote probes. To distribute load, you can set up multiple probes on different computers. For details, see section Remote Probes and Multiple Probes in the PRTG user manual and watch the video tutorial Distributed Monitoring with PRTG.

Stability considerations
Most PRTG installations will never run into stability issues, but please note the following points that can affect the stability of PRTG:

• Remote probes require a stable network connection between the PRTG core server and the remote probe. Unstable connections, for example via 3G or via satellite, may work but we have seen situations where stable monitoring was not possible.
• Our general recommendation is to stay below 30 remote probes on one PRTG core server. PRTG still scales well up to 60 probes as long as you have less than 100 sensors per probe.
• An internet connection is required for license activation (via HTTP or email).
• The quality of your network also plays an important role. When monitoring via UDP, for example, a high packet loss rate can lead to frequent timeouts. Remote probes that connect via unstable (WAN) connections can lead to delays as well.

System requirements for PRTG user interfaces
PRTG Web Interface
The following browsers are officially supported for the web browser based primary user interface of PRTG (in order of performance and reliability) at screen resolution of 1024x768 pixels (more recommended):

• Google Chrome 67 or later (recommended)
• Mozilla Firefox 61 or later
• Microsoft Internet Explorer 11
• Other and older browsers may not be able to access to the WebUI at all.

PRTG Windows App (Enterprise Console)
The PRTG Enterprise Console app runs under all supported Windows versions (see the list above) at screen resolutions of 1024x768 pixels or more.

Mobile Apps
We provide free apps for Android and iOS devices. Please see Mobile Apps for Smartphones and Tablets and the corresponding app pages for detailed system requirements.

Requirements for monitored devices

• SNMP monitoring: The monitored device(s) must be equipped with SNMP Version 1, 2c, or 3 (an SNMP-compatible software must be installed on the device). SNMP must be enabled on the device and the machine running PRTG must be allowed to access to the SNMP interface. For details, please see PRTG Manual: Monitoring via SNMP
• Windows/WMI monitoring: To use WMI (Windows Management Instrumentation) monitoring, you need a Windows network. Host PC and client PCs with Windows OS as given above are officially supported. Please do not use Windows Vista or Windows Server 2008 on host PCs for WMI monitoring, both have WMI performance issues. For details, please see PRTG Manual: Monitoring via WMI
• NetFlow, IPFIX, sFlow, jFlow monitoring: The device must be configured to send NetFlow (V5, V9, or IPFIX), sFlow (V5), jFlow (V5) data packets to the machine running a PRTG probe. For details, please see PRTG Manual: Monitoring Bandwidth via Flows
• Packet Sniffing: Only data packets passing the network card of the local machine can be analyzed. Switches with so-called "monitoring ports" are necessary for network-wide monitoring in switched networks. For details, please see PRTG Manual: Monitoring Bandwidth via Packet Sniffing

Licenses of PRTG differ by two parameters:

• The maximum number of sensors.
• The number of allowed core server installations.

* The Corporate License allows multiple installations of the core server in different
sites of one corporation in one country.

sensors數計算:

The licensing options are based on the number of sensors. Each of the following items counts as one sensor:

• Monitoring traffic/bandwidth on one port of any device via SNMP (e.g. switch, firewall, server) using the MIB2 standard
• Monitoring errors/min, unicast packets/s, non-unicast packets/s on one port of a device via SNMP using the MIB2 standard
• Monitoring one other system parameter via SNMP (e.g. CPU, diskspace etc.) that is accessible via one OID value
• Monitoring traffic going through one local network card (NIC) via Packet Sniffing. If you use filtering then each set of filters counts as one sensor.
• Monitoring of one stream of data traffic via xFlow (NetFlow, sFlow) Monitoring. If you use filtering then each filterset counts as one sensor.

The number of actual hardware devices is not taken into account at all, only the number of sensors. For the "unlimited licenses" the number of sensors that can be monitored is not programmatically limited by the software itself, but may be limited by your software, hardware and network.