Network Sensor
A network sensor monitors the reachability and availability of network services through regular checks using ICMP Ping or port check methods.
General
The basic settings of each device include the activation state (On/Off) as well as a name under which all alarms and warnings reported by this device are displayed. This should be chosen as uniquely descriptive as possible to be able to distinguish between devices.
Alarm Group
By selecting the parent alarm group, the device is integrated into the system hierarchy.
Alarms are signaled in the parent alarm group.
Address
The IP address or hostname of the network service to be monitored. This address is used for the reachability test.
Description
Optional description of the device for better identification in the overview.
Service Type
The type of measurement can be chosen between two methods:
- ICMP Ping: Checks the basic reachability of the configured address using an ICMP ping query. This is the simplest form of network monitoring.
- Port check: Checks if a TCP connection can be established to the configured port. This enables monitoring of specific services.
Use ICMP Ping for basic reachability tests and Port check for monitoring specific applications like web servers or email services.
Port
This field only appears when selecting the "Port check" service type. Here, enter the port number of the service to be monitored (e.g., 80 for HTTP, 443 for HTTPS, 25 for SMTP).
Open in Browser
Protocol with which the address should be opened in the browser. This facilitates direct access to web-based services from the monitoring interface.
Interval (Seconds)
Time interval in seconds (60-999) at which the availability of the configured server should be checked. A shorter interval allows faster error detection but increases network load.
Connection
Connection monitoring enables alarming when the device is not reachable.
| Alarm Assignment | Selection of the alarm assignment |
| Output as Warning | Connection loss does not trigger an alarm and is only reported as a warning. |
Alarm Assignment
Here you define which alarm group is notified in case of connection problems. The selection is made via a dropdown menu with the available system notifications.
Issue as Warning
When this option is activated, a connection loss is issued as a warning instead of an alarm. This is useful for less critical monitoring targets.
| Name | API value | Description |
|---|---|---|
| Off | off | For this input, alarming is disabled and the state/measurement value is not updated. |
| Armed-Active | armed-active | When the parent alarm group has been armed, alarms can be triggered. The state/measurement value of the input is updated. |
| Always-Active | always-active | Alarms can be triggered regardless of the alarm group's switch status. The state/measurement value of the input is updated. |
| Fire | fire | Alarms can always be triggered. These are reported as fire alarms. |
| Sabotage | sabotage | Alarms can always be triggered. These are reported as sabotage/intrusion alarms. |
| System Message | system | Alarms can always be triggered. These are reported as system messages. |
Alarm Values
The alarm values define at which latency warnings or alarms should be triggered.
Latency
- Always Active: Continuous monitoring of response times
- Max.: Maximum acceptable latency in milliseconds. If this value is exceeded, a warning or alarm is triggered according to the configuration.
Warning at
Checkbox to activate warning messages when configured latency values are exceeded.
Latency monitoring is particularly useful for monitoring service quality and can provide early indication of performance problems before a complete failure occurs.
Webhooks
Webhooks enable automatic notification of external systems when network sensor events occur.
Webhook Configuration
- Webhook: Selection of the webhook profile to be used from a dropdown list
- Event: Definition of events that should trigger the webhook
- Create Link: Button to add new webhook links
Webhooks can be configured for various event types, such as connection failure, connection restoration, or latency exceedances.
Ensure that the configured webhook URLs are trustworthy, as they are automatically called when corresponding events occur.