Filtering Events on the Microsoft AMA Syslog Agent for Microsoft Sentinel

When you’re collecting syslog events from VMware hosts, Cisco switches and routers, it’s easy to find yourself drowning in noise—hundreds of messages you’ll never use, each one eating into your ingestion quota and driving up costs. Microsoft’s new Azure Monitor Agent (AMA) for syslog can forward everything by default, and although their documentation hints at filtering via Data Collection Rules (DCRs), in practice those filters vanish whenever you make any edit in the Sentinel console.

A more reliable approach is to drop unwanted messages at the source—on your Ubuntu syslog collector—so they never hit Sentinel in the first place. Here’s how to do it using rsyslog:

Why Filter at the Source?

Cost savings: Every message forwarded to Sentinel counts toward your log ingestion bill.
Performance: Less noise means faster searches and more relevant alerts.
Reliability: Unlike DCR-based filters in Azure, local rsyslog rules won’t disappear after a console change.

Prerequisites

Ubuntu server running rsyslog
Azure Monitor Agent (AMA) already configured to forward your syslog traffic

Step-by-Step Configuration

SSH into your syslog collector

ssh azureuser@your-log-collector

Open the AMA forwarding config

sudo nano /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf

Add your exclusion rules
Place them above the action(type="omfwd" … ) stanza. Each rule looks like this:

# Drop any message containing “PATTERN_TO_EXCLUDE”
if $rawmsg contains 'PATTERN_TO_EXCLUDE' then stop

Tip: Be as specific as possible in your pattern to avoid accidentally dropping useful logs.

Multiple exclusions: Simply repeat the if … then stop line for each pattern.

Save and exit, then restart rsyslog:

sudo systemctl restart rsyslog

Example

Assume you want to drop all “Link up/down” messages from Cisco devices and any VMware heartbeat messages:


# Exclude Cisco interface flaps
if $rawmsg contains 'LINK-3-UPDOWN' then stop

# Exclude VMware heartbeat checks
if $rawmsg contains 'heartbeat check' then stop

Results

Unwanted logs never reach your syslog server
Sentinel only ingests relevant events
Immediate savings on ingestion fees—and time

Conclusion

Filtering at the rsyslog level is a one-and-done solution. Once you’ve nailed down the right patterns, your log stream stays lean and cost-effective—no more lost filters or hidden charges. I hope this guide saves you the troubleshooting time I spent digging through Azure settings!