Monitoring Starts With Questions, Not Workspaces
A common monitoring design begins with:
“How many Log Analytics workspaces should we have?”
That is useful eventually.
It is not the first question.
Start with what services must remain available, what business flows matter, which failures must be detected quickly, which changes need an audit trail, which evidence troubleshooting and security need, and who will actually respond to alerts.
Only then decide where telemetry belongs.
This changes monitoring from a storage architecture into an operating model.
Microsoft’s current architecture guidance treats health monitoring as a way to understand whether system components are functioning as expected and recommends connecting collected health data to alerting and operational response. Microsoft Learn: Monitoring best practices
Know the Different Kinds of Azure Evidence
“Logs” is often used as a catch-all term.
Azure produces different forms of evidence.
Activity Log answers questions about Azure control-plane activity—what changed and which operation occurred.
Microsoft currently retains Azure Activity Log events for 90 days in Azure. If longer retention, correlation, or downstream processing is required, diagnostic settings can export the data to destinations such as Log Analytics, Storage, or Event Hubs. Microsoft Learn: Azure Activity Log
Platform metrics provide numerical time-series signals useful for utilization, latency, failures, queue depth, capacity, and other health indicators.
Resource logs provide service-specific operational information and usually require deliberate collection configuration. Microsoft’s current diagnostic-settings documentation makes the collection categories and destinations explicit. Microsoft Learn: Diagnostic settings in Azure Monitor
Application telemetry is necessary because infrastructure can be healthy while the application is failing. Application Insights and OpenTelemetry-based instrumentation can expose requests, dependencies, errors, traces, and application behavior.
Do Not Collect Everything “Just in Case”
The safest sounding strategy is:
Send everything to Log Analytics and keep it for a long time.
That can become expensive.
It can also produce data nobody understands.
For every log category, ask:
- What question does this data answer?
- Who uses it?
- How quickly must it be searchable?
- How long is it useful?
- Is it required for security or compliance?
- What does ingestion and retention cost?
- Could another destination satisfy the requirement?
More telemetry does not automatically create better observability.
Decide the Log Analytics Architecture Before Workspaces Multiply
A small environment may reasonably start with one workspace.
Do not turn that into a permanent rule without understanding the boundary.
Workspace decisions can be influenced by data residency, security, access, retention, Sentinel architecture, operational ownership, regional design, volume, and cost.
Microsoft’s current Well-Architected guidance describes Log Analytics workspaces as centralized repositories for collected log and performance information, but the architecture still needs to account for the broader reliability, security, operations, performance, and cost model. Microsoft Learn: Azure Log Analytics design considerations
A useful rule is:
Create another workspace because a real boundary requires it, not because another subscription exists.
Monitoring Needs Ownership at Collection Time
Someone must own the collection standard, the workspace, retention, access, alert creation, alert response, and eventual cleanup of obsolete telemetry.
A simple responsibility model:
| Responsibility | Typical owner |
|---|---|
| Platform collection standards | Platform / operations |
| Security log requirements | Security |
| Application instrumentation | Workload team |
| Alert response | Operations / workload owner |
| Retention requirements | Security / compliance / operations |
| Monitoring cost review | Platform / FinOps |
The same person may fill several roles.
The responsibilities still need names.
Alert on Conditions That Require Action
An alert is not useful because a threshold was crossed.
It is useful because somebody should do something.
Before creating one, answer who receives it, what it means, how urgent it is, what action should follow, and what happens if nobody responds.
Microsoft’s current Azure Monitor guidance covers alert design and action groups. Microsoft has also introduced Azure Monitor health models in preview, which add workload and dependency context and are explicitly intended to help move away from purely resource-centric alerting and reduce alert noise. Microsoft Learn: Azure Monitor alert best practices
You do not need a preview feature to adopt the underlying rule:
Alert on service impact and actionable risk, not every interesting signal.
Avoid the “One Threshold for Everything” Trap
CPU at 80 percent can indicate risk in one workload and perfectly healthy utilization in another.
The same applies to memory, latency, storage, queues, and errors.
Consider baseline behavior, peaks, request volume, dependency health, scaling, error rates, user experience, and recovery behavior.
If an alert fires every morning and nobody acts, the monitoring system is training people to ignore it.
Separate Health, Performance, Security, Change, and Cost Signals
A useful monitoring architecture distinguishes the reason a signal matters.
Health: Is the service functioning?
Performance: Is it meeting capacity and latency targets?
Security: Is suspicious behavior or risky configuration occurring?
Change: What changed?
Cost: Is consumption behaving unexpectedly?
The categories overlap, but their owners and actions can differ.
Retention Is a Requirement, Not a Habit
“Keep everything for one year” is not a monitoring strategy.
Security investigations, application troubleshooting, operational trends, and compliance may all require different retention models.
The day-one decision is not necessarily the final number of days.
It is that:
Retention has an owner, reason, and cost model.
Monitoring Should Be Part of Deployment
If diagnostic settings and alert rules are added manually after go-live, they will drift.
One application gets full telemetry.
Another gets partial telemetry.
A third launches without alerts.
Required monitoring can instead be represented in Infrastructure as Code where practical: diagnostic settings, workspace connections, data collection, alerts, action groups, dashboards, and other repeatable controls.
Not every workload requires identical telemetry.
Every production workload should answer the same question:
What evidence is required to operate this safely?
Dashboards Are Not Operations
Dashboards answer:
What can we see?
Operations asks:
What do we do when this changes?
A dashboard without ownership is presentation.
Monitoring becomes operational when signals lead to decisions.
A Day-One Azure Monitoring Minimum
A practical starting model includes control-plane evidence, core resource telemetry, application instrumentation, actionable alerts, intentional Log Analytics architecture, retention rules, monitoring-cost visibility, and repeatable deployment configuration.
This is enough to establish an operating model without creating a full enterprise observability program on day one.
Azure Monitoring Warning Signs
Question statements such as:
- “We turned on all logs.”
- “Everything goes to one workspace because that is simpler.”
- “Every subscription gets its own workspace.”
- “We keep everything for a year.”
- “The alert goes to the cloud team.”
- “That alert always fires; ignore it.”
- “The dashboard is green, so the application is healthy.”
- “We can enable logging if something happens.”
Each hides a decision that should be explicit.
Before Production, Ask This
Can you identify important business flows, control-plane history, required resource logs, application telemetry, retention rules, alert owners, action paths, ingestion cost, and the evidence you would need to investigate yesterday’s incident tomorrow?
If several answers are no, monitoring is still a collection project rather than an operational capability.
Collect the Evidence Before You Need the Explanation
Azure Monitor makes it possible to collect enormous amounts of telemetry.
The architecture question is not how much you can collect.
It is how much evidence you need to operate the platform and workloads confidently.
Start with service flows. Collect signals that explain health. Retain evidence according to real requirements. Design alerts around action. Give monitoring an owner. Make configuration repeatable.
BI Cloud Tech’s Azure Monitor and Application Insights expertise, Azure Operations, and Managed Services are relevant resources for organizations that need to design or operate a more consistent Azure monitoring model.
Monitoring is successful when the right person can understand what is happening and act before a technical signal becomes a business surprise.
