Network Services Monitoring
Availability and performance monitoring of 70 network services such as FTP, HTTP, SMTP, etc.
The monitoring of network services is the basic monitoring type in NetCrunch. A node state is determined basically by the availability of network services. When a node is in the DOWN state, it's only monitored by a single network service.
Availability and Response Time
Services monitoring checks basically:
- Connectivity
- Response received
- Response Time and Failure Rate
NetCrunch sends a request, appropriate for a given service protocol, and then checks if the response matches the defined response. The process should be at least repeated 3 times to measure response time, and then the average response time is calculated. For each request, you can set an appropriate time to wait for a response.
Each monitored service provides the following performance metrics:
- Round Trip Time - total time to send and receive a single response or a connection time for extended services
- Check Time - total checking time (including sending multiple requests in extended mode)
- % Failure Rate - calculated per each service checking
- % Packets Lost - calculated per each service checking
Leading Service
Leading Service is a network service designed to be checked as the only service when the Node is DOWN.
Monitoring in seconds interval
For some critical nodes, you might want to react in seconds instead of minutes. Then you can check for leading service monitoring Monitor in seconds interval.
The option will let the leading service be monitored more often than once per minute whenever a node is DOWN or alive. As an option, you can set NetCrunch to determine the node state solely upon the state of the leading service; otherwise, it can check other services immediately after the leading service fails.
Customizing Existing Services
NetCrunch allows the monitoring of network services by their respective default ports. When you need to monitor a service on different ports, go to SettingsResourcesNetwork Services and choose New Service. Then you will be able to duplicate the service with the new name and different port. For example, define HTTP_8080 for checking HTTP on port 8080.
Simple TCP checking service
In some cases, all you need is a simple TCP port connection checking without sending any further data. In order to create simple TCP port checking go to Settings Resources Network Services, click New Service and select a desired option.
Defining Custom Services
As a third option, you might decide to create a full request/response checking service definition. In order to create such definition, go to Settings Resources Network Services click New Service and select Create from Scratch option.
- Set Protocol Type (TCP, UDP, or TLS/SSL) and Port Number.
- Define the Request to be sent (after connection if TCP is used) - you can enter either text or binary data in the hexadecimal format.
-
Define response patterns. You can set multiple patterns and decide how they should be checked.
Patterns can be text, hexadecimal binary data, or regular expression.
Pattern matching options are:
- any of the added patterns match
- all of the added patterns match
- none of the added patterns match
Automatic Discovery of Network Services
As the node status depends on the services, each time a new node is added to the atlas, NetCrunch automatically discovers services running on the node. By default, NetCrunch is configured to check only a subset of all defined services.
You can manage the list of services being automatically discovered in Settings Monitoring Auto Discovered Services
Troubleshooting
To get some monitoring services to work properly, an additional configuration task should be performed.
DHCP Server Checking Restrictions
-
NetCrunch must be able to open the 68 UDP (DHCP client) port to receive a response to the DHCP inform request. The monitoring will not be working if NetCrunch is running on a machine where the DHCP Server has been installed, as it uses the same port.
-
The IP address of the NetCrunch machine must be included in any checked DHCP Server Scope (WINDOWS DHCP Server tested). For example, if the machine where NetCrunch is running has the address 192.168.1.100, and the DHCP Server is on 192.168.88.10, then the server must have the scope with any range from 192.168.1.x addresses. A Linux-based DHCP Server must have the authoritative option enabled.
Monitoring MSSQL Express
To monitor MSSQL Express, the TCP/IP protocol must be enabled, and the server instance must accept a remote connection on TCP port 1433. Please refer to the MSSQL Express documentation for information about enabling the TCP/IP and allowing the remote connection to the server instance.
SSH Service
NetCrunch allows monitoring of SSH service using a protocol ver. 1 and/or ver.2. By default, the SSHv2 protocol is monitored on the network nodes. Use SSHv1 service in the case when the node supports the older version of SSH.