Migrating from a legacy monitoring platform isn't about recreating every alert. It's about asking which ones actually matter.

When I inherited the monitoring migration for 500+ VMs in a hybrid environment, the first thing I did was export the existing alert inventory. 389 rules. Three hundred eighty-nine. For an infrastructure that had been accumulating alerts like a hoarder accumulates newspaper clippings.

Half of them were duplicates with slightly different thresholds. A quarter were for servers that no longer existed. Some were alerting on conditions that hadn't been relevant since the previous decade.

Nobody questioned them. Because that's how enterprise monitoring works — you add alerts, never remove them, and eventually your on-call team learns to ignore the noise. Which defeats the entire purpose.

The Consolidation

I didn't migrate 389 rules. I designed 31.

Not because I'm lazy (well, partly). But because good monitoring isn't about volume. It's about signal-to-noise ratio. Every alert should wake someone up for a reason. If it doesn't — it shouldn't exist.

The 31 rules cover everything that actually matters:

  • Infrastructure (5 rules): Node down, critical syslog, critical event logs — the basics that should never be negotiable
  • Domain Controllers (4 rules): ADDS service, AD replication, time sync — because when your DCs fail, everything fails
  • Application Services (12 rules): Each business-critical service gets exactly one alert. Not five. One.
  • Security (2 rules): Account lockouts and failed logon bursts — the early warning system
  • Everything else (8 rules): Network, Exchange, specialized services

92% reduction. From 389 to 31. And you know what happened to incident response? It got faster. Because when every alert matters, people actually respond.

The DCR Split Nobody Asks About

Here's where it gets interesting. Azure Monitor uses Data Collection Rules (DCRs) to determine what logs get collected from which machines. The obvious approach: one DCR for Windows, one for Linux, done.

The obvious approach is also expensive.

I built 5 DCR types:

  1. VM Insights — performance metrics for all VMs
  2. Windows Generic Logs — System, Application, Security events (Levels 1-3 only)
  3. Windows Domain Controller Logs — AD, DNS, DFS replication (6 DCs only)
  4. Linux Logs — Syslog from all Linux servers
  5. SQL Server Custom Logs — ERRORLOG parsing into custom tables

The magic is in the split between #2 and #3.

Before the split: Active Directory logs, DNS Server logs, and DFS Replication logs were being collected from every Windows server. All 200+ of them. But only 6 are Domain Controllers. Which means 97% of that collection was paying for logs that would never contain a single relevant event.

After the split: DC-specific logs come from 6 machines. Generic Windows logs come from 200+. Same coverage. Fraction of the cost.

The Information Log Problem

Here's a dirty secret about Windows Event Logs: Level 4 is "Information." And Information events are the noisiest, most voluminous, least actionable data in your entire monitoring stack.

Every service startup. Every scheduled task completion. Every successful login. All Level 4. All collected. All billed per gigabyte.

I cut Level 4 from the generic Windows DCR. Levels 1 through 3 only — Critical, Error, Warning. The stuff you actually investigate.

The volume reduction across 200+ servers was massive. Not a single actionable alert was lost. Because nobody — literally nobody — was ever going to write a KQL query that starts with "show me all the times a service started successfully."

The Action Group Architecture

31 alert rules need to reach the right people. Not everyone. The right people.

8 Action Groups, organized by responsibility:

  • Linux team gets Linux alerts
  • Windows team gets Windows alerts
  • InfoSec gets security alerts
  • Application owners get their application alerts
  • General catchall for everything else

Sounds obvious? You'd be surprised how many enterprises route everything to one email distribution list and call it a day. Then wonder why nobody responds.

Real-World Validation

Theory is nice. Production is truth.

One night, DNS Server errors started firing on two Domain Controllers. The DC-specific alert rule caught it at 2:53 AM. The right team was notified. The issue auto-resolved 48 minutes later.

Not a single false positive. Not a single missed event. The alert fired, the team responded, the system healed. That's monitoring done right.

If I had migrated all 389 rules? That alert would have been buried under noise. Another notification in a sea of notifications. Ignored like all the rest.

The Takeaway

More alerts don't mean better monitoring. Fewer, smarter alerts do.

If your monitoring stack has more than 50 rules and you don't have 50 distinct failure scenarios — you have an alert pollution problem. Fix it before your team learns to ignore everything.

389 rules. 31 survivors. Zero false negatives. 92% less noise.

That's not a reduction. That's a redesign.