What is Syslog alerting?

What is Syslog alerting?

Many problems show up in device logs before they appear in traditional monitoring.

Auvik’s Syslog alerting lets you:

• Turn specific Syslog messages into actionable alerts
• Use Syslog as an early warning signal instead of a “post‑incident” forensic tool
• Reduce noise using Number of occurrences and grouping
• Control how long Syslog alerts stay open using manual dismiss.

Feature availability and requirements

Tiers and licensing

Auvik’s Syslog alerting is available on tenants with:

• Auvik Network Management Performance
• Auvik IT Management Core

If a tenant that should have these capabilities does not show the options described below, contact Support.

Technical Prerequisites

1. Devices must send Syslog to Auvik
   • Configure network devices (firewalls, switches, routers, wireless controllers, etc.) to send Syslog to the Auvik collector.
   • Choose appropriate Syslog severity levels on the devices (for example, warning and above).
2. Alerting v2 must be enabled
   • Syslog alerting and Number of occurrences are implemented in Alerting v2.
   • These capabilities aren’t available in the legacy v1 alert experience.

How Syslog alerting works

Grouping of related Syslog messages

Syslog alerting introduces grouping, based on Auvik’s best determined grouping about which logs belong together.

In practice:

• Auvik groups Syslog messages for an alert based on a combination of fields such as:
  • Device / source
  • Severity
  • Facility
  • Tag / program
• Messages that share the same grouping key and match your trigger conditions are treated as part of one alert.

Benefits:

• Noise reduction – Many related log lines roll up into a single alert.
• Better temporal logic – “X times in Y minutes” provides the ability to alert on frequency of occurrence.

Note: User‑defined grouping (picking exactly which fields to group by) is not available yet.

Controlling noise with delays

Syslog can be extremely verbose. To prevent floods of alerts, Auvik provides several delay options.

Alert delays (trigger‑side)

Under Alerting v2, you will see delay options such as:

1. No delay – Alert immediately
   • Auvik generates an alert as soon as the trigger condition is met.
   • For Syslog, this is typically not recommended except for very rare, critical conditions, because it can be extremely noisy.
2. Number of occurrences (new for Syslog and selected alerts)
   • “Create an alert only if this condition is met N times in T minutes.”
   • Counts how often an event occurs within a group; when the threshold is reached in the time window, the alert fires.

Example use case:

• Grouping by device
• Interface flapping:
  • A single flap may be acceptable.
  • 30 flaps in 10 minutes usually indicates real trouble.
• Configure:
  • Number of Occurrences: “30 occurrences in 10 minutes”
  • Auvik will only trigger the alert when the count threshold is reached in the time window.

Number of Occurrences is the main way to group “multiple similar events over time” into a single alert in Phase 1, and works even better when combined with Phase 2 grouping.

Clear conditions

Manual dismiss

• The alert remains open until a user dismisses or a condition is met.
• Use when:
  • You want a human to explicitly acknowledge / close the issue.
  • There’s no occurrence or frequency decrease indicating resolution.

Custom clear conditions

For Syslog alerts:

• Clear conditions can be configured using similar condition builders as triggers.
• There is no inverse condition option available for Syslog.

Creating a Syslog alert definition

Alert examples

Example: VPN brute force detection on a firewall

A firewall logs a syslog message each time a VPN login attempt fails. A single failure is normal — a user mistyped their password. But 10 failures from the same source in 5 minutes is a potential brute force attack and warrants an alert.

Real-world syslog message (Cisco FTD/ASA): %FTD-6-722051: Group <AnyConnect_VPN> User <jsmith> IP <203.0.113.15> Authentication failed: reason = Invalid password

• Trigger: severity equals Warning OR message contains "Authentication failed"
• Grouping: device/source + tag/program
• Delay: Number of occurrences: 10 occurrences in 5 minutes
• Clear condition: Manual dismiss
• Fields used: device/source, severity, tag/program, message

1. Add a new alert
   • Click Add alert definition.
   • Choose Syslog (or the Syslog‑based trigger type).
2. Select Sites and Devices
   Decide where this alert definition applies:
   • All tenants / orgs, or
   • Specific sites / organizations, or
   • Specific device types or tag (for example, only firewalls).
3. For new Syslog alerts, consider starting with a limited scope (one tenant or device set) to validate noise levels.
4. Configure trigger conditions
   You can combine:
   • Syslog severity
     • Recommended: severity equals Warning (Cisco FTD/ASA logs VPN auth failures at severity 6 – Informational – but Warning or above will also capture escalations).
   • Message content
     • Use conditions specific to VPN brute force (consistent with the example above):
       • message contains "Authentication failed"
       • message contains "722051" (Cisco VPN auth failure ID)
   • Combine with AND/OR as needed. For example:
   • (severity equals Warning) OR (message contains "Authentication failed" AND message contains "722051")
5. Set delays
   Choose a delay strategy:
   • Number of Occurrences delay (recommended for Syslog):
     • Example: “5 occurrences in 10 minutes”
     • Good for:
       • Authentication failures
       • Interface flaps
       • Repeated policy denies
   • No delay:
     • Use only for extremely rare, high‑severity events to avoid noise.
   • Configure resolution behavior
     For Syslog triggers, pick:
     • Manual dismiss
       • Alert stays open until a user dismisses it.
   • Create the alert and monitor
     • Save the definition.
     • Monitor actual alert volume and adjust message filters and thresholds as needed.
     • Consider rolling out to more tenants/devices once you’ve tuned noise.

Grouping: how it affects alerts

Auvik groups messages on Auvik’s recommended grouping (for example, device, severity, facility, tag). And alerts can clear more naturally by a measurement of event frequency decrease.

What this means practically:

• When grouping is active:
  • Multiple related Syslog messages are treated as one alert “incident”.
    • Because groups can consist of various combinations of attributes - it is possible that duplicate alerts are created per unique group but this will still be a significant reduction compared to alerting without grouping.
  • Number of Occurrences can only apply across the grouped set.

Because grouping significantly changes noise behavior, you may want to:

• Start with a small number of Syslog alerts.
• Re‑evaluate your rules when grouping is rolled out more broadly (for example, you may be able to relax some thresholds once grouping is in place).

Best practices

1. Start with a few high‑value use cases
   • Route Changes
   • LACP/Port Channel Changes
   • Certificate Expiration
   • Interface flapping
2. Be specific in message filters
   • Use concrete phrases or key‑value patterns, not broad substrings like "error" on all devices.
3. Always consider count delay for Syslog
   • Treat Syslog as a fire hose.
   • Focus alerts on patterns that repeat in a short window.
4. Choose the right clear mode
   • Manual dismiss when human review is required.
   • Custom clear conditions (Syslog) when:
     • You mainly need the alert in history/PSA and want it to close once the clear condition holds for the configured delay.
     • You don’t want to manage manual dismissals for every incident.
5. Use low severity until it has been verified to be infrequent enough to integrate with the PSA.
6. Review and tune
   • Periodically review:
     • Which Syslog alerts fire most often
     • Which actually drove action
   • Adjust thresholds, time windows, and message patterns accordingly.