IT service providers with several customers want to monitor the performance of their customer’s IT infrastructure, as also companies with several branch offices want to. The former are facing a particular challenge, namely the monitoring of components, which are not directly, or via VPN, connected.
The monitoring of remote locations (locations without direct connection (VPN, MPLS, etc.) to the central NetEye server) is possible through a NSCA daemon. In the following article, I will show you on what you should pay attention.
Prerequisites of the remote location:
Servers at the remote location have to have an internet connection (no fix public IP on remote side is needed) on port 5667 to the NetEye server. On the server, which has to be monitored, an NSCA daemon has to be installed. On Linux environments, it is the NSCA, on Windows the NSClient agent is suggested, which also disposes of an NSCA daemon.
The NSCA daemon has to be configured in the way that the target IP of the NSCA daemon is the public IP of the central location, which is forwarded from the firewall to the NetEye server. Here just port 5667 should be opened.
On the NSClient for Windows environments, different monitoring possibilities can be defined on the NSCA section (expl. CPU monitoring, memory, disk space, services, processes etc.). Moreover, external scripts can be executed to monitor the exchange server or other hardware devices, which dispose of an NSCA.
For any of the services that have to be monitored, obviously, a name has to be defined, which executes the check
Furthermore, the monitoring interval has to be defined within the NSCA configuration (expl. a monitoring interval of five minutes). For Linux environments, these configurations are more extensive because the checks have to be executed over scipts of a cronjob.
Prerequisites of the central location:
At the central location a NetEye server has to be installed, on which a NSCA server runs. On normal NetEye installations, the NSCA server is already preinstalled and has just to be configured.
The configuration on the NSCA server, obviously has to be assumed by the remote location, otherwise the communication would not be possible. Here the level of encryption and the password are meant.
On the central location the firewall has to be configured in a way that a public IP on port 5667 (standard NSCA port) is active. It would be useful if the remote location disposes over a fix public IP, because using this, the firewall could be set in a more restrictive way.
In the way that the checks, which are defined on remote side, can be shown and notified in NetEye, the remote hostname of the server and the set services, have to be created with the identical name for host as well as for the service created in NetEye.
For the host check and for the service check the active check has to be switched off, otherwise the checks would run on errors.
It is suggested to define a so-called Freshness Threshold for such passive checks in NetEye. In this way, in case the remote host or certain remote services do not respond for a predefined period (expl. 15 minutes) an error can be generated in NetEye.
Conclusion
The above described approach can be used by IT service providers to monitor less complex IT infrastructures of their customers. Performance data of several customers can be collected and central alerts can be defined. In this way, the IT service provider gets a general overview about the infrastructures of his customers. However, for more complex IT infrastructures, an on-site implementation is still suggested.
Tobias Goller
Author
