Hey You

It’s late 2025 and as the year closes, I wanted to achieve another badge on my already huge list. The AZ-305 Designing Microsoft Azure Infrastructure Solutions.

I have learned that the best way to learn is to teach. Maybe that’s why I became a Microsoft Certified Trainer. Anyway… I wanted to blog every lesson that I have learned. 

Before we dive into fancy architectures or high-availability designs… let’s talk about something that quietly decides whether your Azure environment lives or dies: MONITORING

Yeah, that thing everyone “enables by default” and then forgets about.

Spoiler: default ≠ done

Why monitoring comes first

Monitoring touches everything… management, performance, security, alerting and automation. Microsoft enables basic monitoring out of the box, but every service behaves differently. If you don’t design monitoring intentionally, you’ll end up blind when it matters most.

Metrics vs Logs – Two sided of the truth

Metrics show symptoms. Logs tell you stories. Together they form your diagnostic X-ray.

Sources: Where all data comes from

Azure doesn’t have one place for “the truth”. It has many. Each talks its own dialect:

• Azure Resources => Native logs per service (VM, Storage, SQL, etc)
• Subscription-level logs => Management actions, deployments, health events
• Tenant logs => User operations (creation, modification, deletion)
• Application logs => From your .NET, Java, Node apps, usually via Application Insights
• OS logs => Windows Event Logs or Linux Syslog (needs diagnostics agents)
• Custom sources => External apps dumping to csv. APIs or custom exporters

If it can generate data, Azure can collect it. But you decide what’s useful and where it goes.

Log analytics – The real powerhouse

A Log Analytics Workspace is where everything comes together. Here’s why every serious architect uses one:

• Store logs for longer than 90 days
• Query with Kusto Query Language (KQL)
• Correlate metrics, events and traces with multiple sources
• Visualize data with charts and dashboards

Pro tip: Log retention and data egress cost money. Forwarding logs cross-region = cross-budget pain.

Agents – Because not everything is “Cloud Native”

Azure services push data automatically but VMs need agents.

• Windows => Event logs via Diagnostics Extensions
• Linux => Syslog via Log Analytics Agent or Azure Monitor Agent (note that Log Analytics Agent will be deprecated)

Install the right one or you’ll end up monitoring nothing but silence.

Alerts – From Insight to Action

Monitoring isn’t just about watching graphs. It’s about doing something when things go wrong.

Alerts in Azure follow a clear pattern:

1. Signal => Metric or log events (e.g. CPU > 90%)
2. Criteria => When the condition is true
3. Action Groep => What happens next (email, SMS, webhook, Teams notification etc)

You can attach multiple action groups to a single rule… because when the VM’s on fire EVERYONE deserves the ping!

Designing monitoring like an architect

When building solutions around Log Analytics always ask yourself:

• Where does the data originate?
• Who needs access?
• How long should it be retained?
• Who’s paying for the ingestion and storage?

Centralized monitoring (one workspace for all subscriptions) = easier governance

Decentralized (per team or app) = better isolation

Both can be right… just… don’t mix them blindly

My takeaway from this lesson

Monitoring isn’t an afterthought. It’s the nervous system of entire Azure design. 

If you skip it your architecture isn’t secure, performant or even realistic. Every decision, from log routing to alerting, affects cost, visibility and accountability.

Now I know that this is all theoretic and no hands on… YET… I will keep on posting new articles regarding the AZ-305 (and I hope I can do it on a weekly base) and some (if not most) will be hands on. So … what’s next? Hands on off course 🙂

Thanks for reading.

Cheers, 

Engin