How to include Syslog event information in an alert email message

patriot

I am using SWOSH v2025.4.3 and have a working LA rule setup that triggers when a particular EventID is seen in a Syslog message. The Rule triggers an alert, which includes an email notification.

I would like to include certain information in the email message body. The information is highlighted by the red arrows in the screenshot.

I assume this will have to be accomplished using either a custom SQL or SWQL variable. Am I correct? If so, has anyone done this and would you be willing to share you alert formatting? Thanks so much.

Syslog alert email variables.png

jeremymayfield

To include specific Syslog event details in an alert email using SolarWinds Orion / SWOSH v2025.4.3, you do not need custom SQL or SWQL in most cases.

For Log Analyzer (LA)–based alerts, the recommended and supported approach is to use alert message macros (tokens) that reference the triggering log record. Custom SQL/SWQL is only required if you need cross-object enrichment or data not exposed in standard tokens.

1. Confirm Alert Type

If your alert triggers on:

• Log Analyzer event (Syslog)
• Condition such as EventID equals X
• Action = Email notification

Then the email body can reference Log Analyzer–specific variables.

2. Use Log Analyzer Alert Macros (Recommended Approach)

In the Alert Actions → Send an Email/Page → Message field, click “Insert Variable”.

For Log Analyzer alerts, the available variables typically include:

• ${N=SwisEntity;M=Message} – Full Syslog message text
• ${N=SwisEntity;M=Severity} – Syslog severity
• ${N=SwisEntity;M=Facility} – Syslog facility
• ${N=SwisEntity;M=HostName} – Sending host
• ${N=SwisEntity;M=IPAddress} – Source IP
• ${N=SwisEntity;M=TimeStamp} – Event timestamp
• ${N=SwisEntity;M=EventID} – Event ID (if parsed)

In LA-based alerts, SwisEntity references the triggering log record.

3. Sample Alert Email Formatting

Below is a structured example that is commonly used in production environments:

Subject:Syslog Alert: EventID ${N=SwisEntity;M=EventID} on ${N=SwisEntity;M=HostName}Body:Alert Name: ${N=Alerting;M=AlertName}Trigger Time: ${N=Alerting;M=TriggerTime}Device: ${N=SwisEntity;M=HostName}IP Address: ${N=SwisEntity;M=IPAddress}Severity: ${N=SwisEntity;M=Severity}Facility: ${N=SwisEntity;M=Facility}Event ID: ${N=SwisEntity;M=EventID}Timestamp: ${N=SwisEntity;M=TimeStamp}Message:${N=SwisEntity;M=Message}View in Orion:${N=Alerting;M=AlertDetailsUrl}

This approach ensures:

• Full event context
• Clean formatting
• Direct navigation link
• No dependency on SQL

4. When Custom SQL or SWQL Is Required

You would only need custom SWQL if:

• You want to parse part of the message using REGEX
• You need to join Syslog data to:
  • Node custom properties
  • Interface information
  • External CMDB fields
• You want to extract substrings from the message body dynamically

In those cases:

• Create a Custom SWQL Query Alert
• Return calculated fields
• Reference them in the email as ${N=Alerting;M=CustomFieldName}

However, this adds complexity and reduces supportability.

5. Best Practice Recommendation

For operational stability:

• Use built-in LA variables wherever possible
• Keep formatting structured and consistent
• Include ${N=Alerting;M=AlertDetailsUrl} for auditability
• Avoid SQL unless absolutely necessary