Monitoring events in real time
Monitoring can be divided into two basic types: real-time and scheduled. In the first case, monitoring software receives events from external systems and reacts immediately. In the second, it polls a network resource at defined intervals. The two approaches are optimal under different circumstances: for example, when connectivity to a remote device is lost, real-time events alone are not enough to confirm whether the device is still reachable. Real-time monitoring also requires the monitoring system to accept incoming traffic, which is not always possible in every network.
Majority of monitors IPNetwork uses poll remote devices for data. There are, however, two monitor types that are instead listening for data, allowing implementing real-time monitoring: SNMP Generic Trap and Syslog monitor.
SNMP Generic Trap
While SNMP protocols family allow getting a value of certain SNMP variable (OID), it also allows receiving real-time events via so called SNMP traps.
To receive SNMP traps, IPNetwork Monitor listens on the SNMP trap receiver UDP port shown in “Settings > System”. By default, UDP port 162 is used when available; if it is already occupied, IPNetwork Monitor may use another port instead, so it is important to verify the actual value shown in the settings before configuring the sending device.
The specified port should be open in the local firewall and in any network security tools between the device and IPNetwork Monitor. We provide a simple instruction on setting up SNMP trap monitor. For troubleshooting, it is often best to begin with a monitor that accepts any community and any OID, confirm that traps are arriving, and only then narrow the filter to the exact events you need.
Syslog monitor
The Syslog protocol, defined by RFC 5424 (with older BSD-style formats often associated with RFC 3164), is a standard way to deliver event messages. Since all Linux and Unix-like systems do include implementation of syslog agent (facility that sends syslog events), the monitor is a convenient tool to get real-time notification from devices running the mentioned OSes.
We provide detailed instructions on setting up Syslog monitor; similarly to SNMP Generic Trap, it is recommended to create a Syslog monitor catching every event, to make sure both ends are communicating as expected.
Syslog events are listened to at standard UDP port 514 (it can be altered in nms.ini: “Syslog section”, UDPReceiverPort variable).
It is recommended to use both scheduled (polling) monitors along with Syslog monitors on the same device; the first allow quick notifying on important events; the second can check the device in question is reachable.
Note that Windows systems do not include a native syslog agent by default, so if Syslog forwarding is needed there, a third-party syslog forwarder or agent can be used.
Final notices
One known problem with real-time monitors is the monitoring system should be open to certain systems (firewall should allow incoming traffic on certain port).
Another practical issue is event flooding. IPNetwork Monitor should be protected from bursts of incoming events by restricting how many messages a real-time monitor accepts within a given interval. To prevent the monitoring system from being overloaded, the corresponding limit should be enabled and tuned to a reasonable value for the device or service being monitored. In practice, it also helps to start with broad filters only during setup and then narrow them afterward, so the monitor does not stay overly noisy in production.
Note that both monitor types reside upon starting in “Unknown” state until the appropriate monitoring event is received.