Introduction
Syslog events are messages generated by devices, applications, or systems, which are then captured and sent to a syslog server for storage, monitoring, and analysis. These events offer crucial insights into system operation and status, essential for troubleshooting and security assessments.
Prerequisites
The gateway server must be installed in the managed environment.
Tip
If you are unfamiliar with RegEx, there are free websites that provide RegEx reference materials, tutorials, and development tools to fine-tune the RegEx expressions you might need to define rules.Monitor syslog events through OpsRamp tool
You should create rules and configuration profiles to monitor required syslog events through the OpsRamp tool. OpsRamp tool then generates alerts for the required syslog events as per rules and configuration profiles.
What is SysLog monitoring rule?
The syslog monitoring rule filters syslog events based on a RegEx pattern and generates alerts in the OpsRamp UI according to user-specified metric names, component names, alert subjects, alert descriptions, and alert severities.
You can define the metric, component, alert subject, and alert description in two ways:
Static approach
In static approach, you define fixed values for the metric name, component name, alert subject, and alert description based on syslog events.
Example:
If you want to generate an alert when a syslog message contains the term invalid_user, you would create a rule specifying RegEx as invalid_user.
Whenever a syslog event matches RegEx, OpsRamp tool generates an alert using the predefined metric name, component name, alert description, and alert subject.
The screenshot below illustrates this setup.
Sample Syslog Event: “
Jun 17 12:45:02 localhost sshd[1234]: Failed password for invalid_user from 192.168.1.200 port 5678 ssh2
”
Dynamic approach
With this approach, you can dynamically derive the metric name, component name, description, and subject from syslog event using the grouping concept in RegEx. Additionally, it supports predefined macros that can be used when defining rules.
Sample Syslog Event:
"devname="abcserver" devid="F22004743" eventtime=1714470971124258725 tz="+0200" logid="0100040704" type="event" subtype="system" level="notice" vd="root" logdesc="System performance statistics" action="perf-stats" msg=Performance statistics: average CPU: 0, memory: 4, concurrent sessions: 20517, setup-rate: 1"
Example: If you want to go with dynamic approach to generate an alert and derive the metric name, component name, description, and subject from the syslog message and want to see the logdesc value as the metric name, the devname value as the component, the msg=Performance statistics value as the subject, and the entire syslog event message as the description. When you receive the above syslog event, you have to define the RegEx as mentioned below:
Regex pattern:
"(devname=(.*)devid.*(logdesc=(.*)(action=(.*)(msg=(.*(Performance statistics).*)))))"
Alert Details in OpsRamp: Below is a sample alert.
The rules have to be defined as mentioned in the screenshot.Metric name: system performance statistics
Component name: abcserver
Subject: Performance statistics: average CPU: 0, memory: 4, concurrent sessions: 20517, setup-rate: 1
Description: devname=“abcserver” devid=“F22004743” eventtime=1714470971124258725 tz="+0200" logid=“0100040704” type=“event” subtype=“system” level=“notice” vd=“root” logdesc=“System performance statistics” action=“perf-stats” msg=Performance statistics: average CPU: 0, memory: 4, concurrent sessions: 20517, setup-rate: 1
Supporting Macros
- ${received.syslog.message}: It provides a description of the event or message. In a syslog event message, the description typically provides specific details about what occurred or what was detected by the system or application.
- ${timestamp}: It shows the timestamp of the event when it was received at the gateway in Unix Time.
Configure SysLog monitor
Follow these steps to configure syslog monitor:
To select your client, navigate to All Clients, and click the Client/Partner dropdown menu.
Note: You may either type your client’s name in the search bar or select your client from the list.Navigate to Setup > Account. The Account Details screen is displayed.
Click Integrations. The Installed Integrations screen is displayed with all the installed applications.
Note: If you do not have any installed applications, you will be navigated to the Available Integrations page with all the available applications along with the newly created application.Click +ADD on the Installed Integrations page.
Note: Search for the integration either by entering the name of the integration in the search bar or by selecting the category of the integration from the All Categories dropdown list.Click +ADD in the SysLog Monitor Configuration application tile.
Enter the following information:
CONFIGURATIONField Name Field Type Description Name String (required) Enter Configuration name. Description String Provide a description. FILTERS
Field Name Field Type Description SEVERITY Dropdown (required) Select severity level from dropdown. See RFC 5424.
Syslog messages having selected severity level will only be processed. Rest of the messages will be dropped.FACILITY Dropdown (required) Type of message to monitor dropdown from RFC 5424.
Syslog messages having the selected facility codes will only be processed. Rest of the messages will be dropped.Click + or Add a IP range filter in the IP FILTER RANGE section. The ADD IP FILTER window is displayed.
IP FILTER RANGE
Follow these steps to configure syslog monitoring rules:Field Name Field Type Description IP Filter Range String (required) IP address range of servers to monitor syslog messages.
Enter asterisk (*) to receive messages from all devices, although, this is not recommended because of the heavy traffic load imposed on the gateway.Click +RULE in the RULES section.
Click the Name dropdown.
Click +ADD. The ADD SYSLOG RULE window is displayed.
Enter the following information:
Field Name Field Type Description Name String (required) Rule name. Action Dropdown (required) Action to apply to messages that match this rule: - INCLUDE: If the event matches a rule, it is processed further.
- EXCLUDE: If the event matches a rule, it will not be processed further.
RegEx Pattern String (required) RegEx pattern to apply for matching messages. Matching groups can be used as parameters, such as ${1}
, in generating alert messages.Metric Name String (required) User-defined metric name, which can be specified using RegEx. Component String (required) User-defined component name. Alert Subject String (required) User-defined alert subject. Alert Description String User-defined Alert description. Alert Severity Dropdown (required) Alert severity level: - Critical
- Warning
- Info
- Ok
Tags String User-defined tag name. Click ADD SYSLOG RULE. The rule is added and listed in the RULES section.
- To select an existing rule, click the Name dropdown and select a rule.
- To delete a rule, click delete icon.
Click ADD IP FILTER in the ADD IP FILTER window. The details are added.
To view or modify the IP Filter details:
- Hover over the row and click action (three dots) icon.
- Select View Details.
- Edit the required fields and click SAVE.
To remove the IP Filter details:
- Hover over the row and click action (three dots) icon.
- Select Remove. A confirmation popup is displayed.
- Click REMOVE. The IP Filter is removed.
After adding the information, the Configuration screen looks something like this:
Click NEXT. The FILTER screen is displayed.
Select a collector profile that is connected.
Click FINISH.
The integration is installed and displayed on the Installed Integrations page. Use the search icon to search the installed integration.
Modify the Integration
See Modify an Installed Integration or Application article.
Note: Select SysLog Monitor Configuration.
How to process the received syslog event message
If any SysLog event is received by the gateway, it first checks the event Severity against the criteria specified in the first profile that is sorted alphabetically. If the severity matches, it proceeds to check the Facility. If the facility also matches, it proceeds to evaluate the Rules within that profile. If a rule is matched, the process stops; otherwise, it moves on to the next profile and repeats the same sequence of checks.
Examples:
- Let us consider three configuration profiles: P1, P2, and P3, and event E1 is received by the gateway. The gateway first checks the event against P1 profile. If event E1 matches the severity specified in profile P1, then the gateway checks the facility in profile P1. If it matches, then it proceeds to check the rules one by one in the P1 profile. If any of the rules in P1 do not match, the gateway moves on to profile P2 and checks the severity specified in the profile P2, it matches then checks the facility. If the facility matches the selected facility of the profile P2, it then checks the rules in the profile P2. If any of the rules match, the alert will be generated, and it will not check other profiles.
- If Event E2 is received by the gateway, it checks against profile P1. If the Severity of the event matches, then it checks the Facility in profile P2. If it matches, then it checks the rules in profile P1. If any of the rules do not match in profile P1 then it moves to profile P2. If it checks the severity of the profile P2 it matches, it checks the facility and it also matches, then checks the rules. If the rules do not match, then it moves to profile P3. If the severity of profile P3 does not match, the gateway will drop the event.
- If Event E3 is received by the gateway, it checks the Severity in profile P1. If it matches, then it proceeds to check the Facility in profile P1 and checks the rules in P1 one by one. If any rule matches in any profile, an alert is generated.
- If Event E4 is received by the gateway, it first verifies the Severity in profile P1. If it does not match, the gateway will drop the event.
- If Event E5 is received by the gateway, it initially verifies the Severity in profile P1. If it matches, then it proceeds to check the Facility in profile P1. If the facility does not match, the gateway will drop the event.
Additional Information
SysLog events can be categorized into 8 types of events based on severity: Emergency, Alert, Critical, Error, Warning, Notice, Informational, and Debug. OpsRamp can generate Critical, Warning, OK, and Info alerts. These alerts are generated based on rules defined in the OpsRamp UI.
If you want an OK alert, you must define a specific rule for it. If the OK alert needs to be appended to an existing critical/warning alert, the OpsRamp tool allows it, but it requires the Metric name, component name, and resource to remain the same; otherwise, it generates a separate alert.
The Priority value is calculated by first multiplying the Facility number by 8, and then adding the numerical value of the Severity.