We are heading for the IoT (Internet of Things), so the new version has checks that allow us to use our program not only to monitor servers, network equipment and computers, but also to control industrial equipment and video surveillance systems.
Industrial equipment monitoring with OPC
With the new OPC Server check, you can now get parameters from CNC and PLC machines that support the Open Platform Communications Data Access (OPC DA) protocol. The program, acting as an OPC client, at a specified interval connects to the existing OPC server and receives from it the value of a tag selected for monitoring. The application Agent allows you to connect to OPC servers located in remote networks behind routers and NAT.
Monitoring Bitrate of CCTV Camera Video Stream
In the previous version, we already focused on checking CCTV cameras and even collected in one place 9 ways to monitor them using the 10-Strike Network Monitor program. Now we have added the 10th method – the most useful, indicative, and interesting one. Now the program can directly connect to IP cameras and DVRs with analog cameras connected using the RTSP protocol and calculate the current network bitrate (speed) of the video stream.
This is the most guaranteed way to know if a camera is working fine or not. After all, the camera can respond perfectly if you ping it, but at the same time not transmit the picture for various reasons. For example, if it is covered with snow or someone deliberately sealed it with tape. In such cases, the camera starts generating a black image that compresses very well. The channel begins to receive a stream with a relatively low bitrate (below 20 KB / sec). The program can monitor this bitrate and generate an alert if it becomes too low. The same situation occurs with strong illumination – the more uniform the picture, the less it weighs.
The bitrate can generally drop to zero if the camera is broken – the program will notify you in time too.
To configure the camera check, you need to set its URL using the RTSP protocol.
For example, rtsp://192.168.1.1:554/user=admin&password=123&channel=1&stream=0.sdp
You can find the URL format in the documentation for the camera/DVR or on the Internet. In this case, the RTSP protocol on the camera (video recorder) must be activated, and the port (TCP 554 by default) must be forwarded and accessible from the outside.
When setting up the check, you need to get the current camera bitrate in order to estimate the minimum threshold value. The normal bitrate for each camera is determined empirically, based on several measurements at different times of the day. The threshold is usually the minimum bitrate value, if the camera was transmitting an image. We tested the program on several cameras and in all cases the bitrate did not drop below 40-50 kilobytes per second.
By default, the program measures the bitrate of the video stream for 10 seconds, but this time can be increased (up to a maximum of 60 seconds). It should be borne in mind that the scan generates network traffic, so you should not perform it too often. It is enough to make a check interval of 10 minutes or more. The more camera checks on one monitoring server, the longer you need to take a break between them.
The bitrate can drop below the threshold value even during normal camera operation. For example, if a network failure occurs. Therefore, it is advisable to turn on the protection against false alarms in the check parameters and set it to 3 attempts or more with an interval of one minute.
We have added filters that allow you to group checks of one host by a set of parameters. For example, by clicking on a filter, you can display only failed checks in the list, or checks of a single type.
All changes in the version 6.6 are listed here
- Added the bitrate monitoring check for the surveillance camera video stream using the RTSP protocol. Now the program provides full monitoring of video surveillance systems.
- Added the OPC server monitoring. This allows you to perform the real-time monitoring of CNC machines and other industrial equipment that support this protocol.
- Pro: Added the check filter groups that are created at the host level in the host tree. The filters form a list of host checks selected according to the specified criteria. For example, you can display only failed checks, or only checks of one type, or checks with a given word in comments.
- Pro: Added ability to move from a check and a host in the lists to the corresponding device icon on the map.
- Pro: Added the archived statistics deletion.
- Fixed bug with traffic counting when working with 64-bit SNMP counters.
- Fixed bug with sending messages via Telegram and Slack when using the latest versions of SSL libraries.
- Fixed other minor bugs.