WinSyslog - Services

Services inside WinSyslog gather or generate the data that is processed by rules. In plain language, they are the configured inputs and generators inside the product. For example, the Syslog server service receives incoming syslog messages and the Windows Event Log Monitor service reads Windows Event Log entries.

In this manual, service is the main operational term and input is the plain-language concept for the receive side. Some GUI pages still use exact labels such as Syslog server, RELP Listener, and SETP Server for individual service types. Use What do “service”, “input”, “listener”, and “server” mean in WinSyslog? for the terminology mapping.

Typically, there can be multiple instances of the same service running, as long as their listen settings do not conflict. For example, there can be multiple syslog input services on a given system as long as they use different port, address, or transport combinations. For example, there could be three of them: two on the default port of 514, one with TCP and one with UDP, and a third on UDP port 10514. All three can coexist and run at the same time.

The following services are supported:

Heartbeat

This service generates a special information type. Its primary purpose is to notify a receiving system that WinSyslog, set for heart beating is still alive. So the receiving system can be configured to raise alarms (or corrective actions) if it does not receive heartbeats from WinSyslog.

MonitorWare Echo Reply

A central agent running WinSyslog is using the echo request and instructs to poll each of the other WinSyslog services. When the request is not carried out successfully, an alert is generated. The MonitorWare echo protocol

RELP Listener

The RELP Listener service receives messages over the reliable event logging protocol (RELP). In practice, it is a network input service for RELP traffic. It automatically listens on all available IP addresses, including IPv4 and IPv6, due to the librelp implementation.

Apart from using a different application protocol over TCP, the RELP Listener service plays the same operational role as the Syslog server service: it receives incoming events and passes them into a ruleset.

SETP server

Implements the SETP Server service. It is used to receive event notifications reliably from compatible Adiscon products and pass them into a ruleset. In plain language, it is a SETP input service.

SNMP Trap Receiver

The SNMP Trap Receiver service allows you to receive SNMP trap messages. Roughly speaking, a trap is similar to a syslog message, but it is sent over SNMP. It is generated by the device when the device decides it should send a notification, and it includes the information the device wants to transmit, plus a small set of standard SNMP fields such as version and community.

Syslog server

Implements the Syslog server service. It receives syslog messages and can listen on any valid port. UDP and TCP communication are supported.

Event Log Monitor

Monitors Windows event logs. As soon as new events are detected, these are forwarded to WinSyslog processing. This service is similar to the Adiscon EventReporter functionality.

Associated rulesets

Each instance of a service has an associated ruleset. This allows easy creation of customized rulesets on a per-service basis. Of course, multiple services can also operate on a common ruleset.

All services are executed as multiple threads inside WinSyslog. From the operating point of view, there is only one system service called the “WinSyslog”. If the service configuration of WinSyslog is modified, the WinSyslog service needs to be restarted in order to activate the new configuration. Later releases will have some options to automate this task.