Loading
Latest posts
Your Intune Compliance Is Moving to Azure Attestation… and Your Firewall Might Break it
Microsoft is Unifying the Copilot Apps… What IT Admins need to know before September 2026
Remove Device Everywhere – Because Microsoft Thought 3 Portals Was a Good Idea
I Asked Copilot To Make ASCII Art… and It Broke My Soul
AZ-140 Renewal 2025 – What Microsoft Really Tested (and what they didn’t)
Related posts
- Your Intune Compliance Is Moving to Azure Attestation… and Your Firewall Might Break it
- Microsoft is Unifying the Copilot Apps… What IT Admins need to know before September 2026
- Remove Device Everywhere – Because Microsoft Thought 3 Portals Was a Good Idea
- I Asked Copilot To Make ASCII Art… and It Broke My Soul
- AZ-140 Renewal 2025 – What Microsoft Really Tested (and what they didn’t)
AZ-305 #1 – Logging & Monitoring: Or How I Learned to Stop Worrying and Love the Logs
Engin Soysal
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
| Type | What it is | Example |
| Metrics | Numbers that describe system state at a single point in time | CPU = 82%, Memory = 71% |
| Logs | Detailed records of events, traces or actions | VM restarted, user deleted, deployment failed |
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:
- Signal => Metric or log events (e.g. CPU > 90%)
- Criteria => When the condition is true
- 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
Engin SoysalMicrosoft MVP and Microsoft Certified Trainer, sharing practical experience with Azure, Microsoft Intune and endpoint engineering.
43 stories · read them all
0 Comments