A payments platform reports that checkout latency doubled immediately after a deployment. The web tier has green virtual-machine health checks, but transaction completion has fallen. Its database metrics live in one workspace, application exceptions in another, and firewall logs were never collected. A design review needs to answer three questions: which signals establish customer impact, which logs explain the cause, and which access and retention policies let responders investigate without exposing payment data. Those are architecture decisions rather than instructions to turn on every Azure Monitor checkbox.<\/p>\n
For Microsoft AZ-305<\/strong>, designing logging and monitoring solutions belongs to the identity, governance, and monitoring domain. Start with a service objective and its failure path, then select Azure Monitor metrics, logs, Application Insights, diagnostic settings, alerts, and appropriate storage or streaming destinations. The broader Azure landing-zone architecture<\/a> establishes account and policy boundaries; observability must work across those boundaries while allowing application owners to diagnose their own systems.<\/p>\n Write the application service-level indicators before choosing products. A checkout system needs successful purchases per minute, failed-payment ratio, end-to-end latency, and whether queued orders finish within their promised interval. CPU percentage alone can look healthy while an authorization outage blocks all customers. Associate each indicator with an owner, target, alert threshold, and escalation. An availability objective without a way to measure failed business transactions cannot guide operations.<\/p>\n Map the request from edge routing to app code, dependent APIs, database, queue, and identity provider. Decide which hop must emit logs and which component measures transaction completion. For an asynchronous process, a successful HTTP 202 response proves only acceptance; queue age and eventual completion prove a different outcome. Architecture should expose both and avoid reporting accepted work as completed revenue.<\/p>\n Metrics are compact numeric time series suited to alerting and capacity trends. Resource logs record specific events, while distributed traces follow sampled requests across instrumented services. The Azure Activity Log captures supported subscription and resource management events; it is not a substitute for application access logs or data-plane auditing. An engineer who changed a route table and a customer whose API timed out create different forms of evidence.<\/p>\n Azure Monitor can collect platform metrics and, with the appropriate configuration, platform logs and application telemetry. The Azure Monitor overview<\/a> describes these layers. If an incident asks who modified a network security group, investigate the management audit trail. If it asks why a particular order exceeded four seconds, follow application dependencies and trace spans, supplemented by the affected service metrics.<\/p>\n Diagnostic settings route supported platform resource logs and certain metrics to destinations such as Log Analytics workspaces, storage accounts, or Event Hubs. Coverage and available categories differ by resource type. A diagnostic setting on a firewall does not magically collect all database query details; each supported source and category requires a deliberate selection. Capture representative events in a test workspace before setting expensive retention policies globally.<\/p>\n Centralize data when the security or operations team needs correlation across subscriptions, but keep workload context and access boundaries. For example, a security-owned workspace may receive privileged activity and network-denial logs while an application team accesses its own application telemetry. Use Azure Policy to enforce required diagnostic configuration where supported, and review whether an exemption has turned a critical system invisible. Retention and access decisions are part of data governance.<\/p>\n One giant Log Analytics workspace can simplify broad searches but may concentrate cost, data residency, and role assignment. Many independent workspaces provide workload isolation but can complicate cross-workspace queries and incident correlation. Select a pattern based on subscription boundaries, geography, security team access, volume, and operational ownership rather than a universal one-workspace rule.<\/p>\n Use resource-context or workspace-based access where appropriate and assign the least privilege needed to investigate incidents. Restrict access to sensitive application and authentication logs, and keep secrets, raw tokens, and payment details out of telemetry. A centralized SIEM must not become an uncontrolled copy of customer data. Compare the shared-control design against the AZ-305 governance and RBAC decisions<\/a> so policy and operational visibility support one another.<\/p>\n Application Insights can instrument supported applications and expose request duration, exception categories, dependencies, and trace context. Use consistent correlation IDs across services and choose sampling intentionally. A trace missing a payment span might mean instrumentation or sampling is incomplete, not that the payment call never happened. Keep request dimensions useful without storing personal information unnecessarily.<\/p>\n During a deployment, compare customer success metrics, request traces, and infrastructure signals in the same time window. A sudden rise in calls to an external API may be visible in dependency telemetry even if VM CPU is flat. Add deployment\/version identifiers to the investigation context so teams distinguish a code rollout from a regional platform incident. Observability needs traceability across releases, not only pretty dashboards.<\/p>\n Use metric alerts for fast, measurable signals and log alerts for conditions that require event search or aggregation. Action groups can notify responders or initiate approved workflows, but an automated remediation must have scope restrictions, safety checks, and rollback. An alert that restarts every instance because one downstream API slows could amplify the outage. Separate customer-impacting alerts from informational deviations that belong on a dashboard.<\/p>\n A robust design includes suppression or correlation for related failures, evaluation windows matched to business impact, and missing-telemetry detection. If a monitoring agent stops reporting, interpreting a zero error count as perfect health is dangerous. Test one normal load spike, one real dependency failure, and one telemetry-collection outage to distinguish expected alerts from noise.<\/p>\n Estimate the number and size of events during normal traffic and incidents. High-volume verbose application logs, duplicate export destinations, and long retention can dominate observability cost. Decide which records need immediate query access and which can be archived with a slower retrieval path. If a rule promises seven-year retention, make sure access, encryption, deletion safeguards, and legal constraints support that policy rather than treating retention as a single numeric field.<\/p>\nTranslate business commitments into useful signals<\/h2>\n
Distinguish metrics, log records, traces, and change evidence<\/h2>\n
Design diagnostic settings by resource and destination<\/h2>\n
Choose workspace topology using permissions and query needs<\/h2>\n
Make Application Insights explain the slow dependency<\/h2>\n
Route actionable alerts and prevent notification storms<\/h2>\n
Model ingestion, retention, and query cost<\/h2>\n