{"id":2709,"date":"2026-10-08T15:11:12","date_gmt":"2026-10-08T15:11:12","guid":{"rendered":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-azure-monitor-network-watcher\/"},"modified":"2026-10-08T15:11:12","modified_gmt":"2026-10-08T15:11:12","slug":"microsoft-az-104-azure-monitor-network-watcher","status":"publish","type":"post","link":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-azure-monitor-network-watcher\/","title":{"rendered":"Microsoft AZ-104: Azure Monitor and Network Watcher"},"content":{"rendered":"

Monitoring is where an Azure configuration becomes an operated service. The AZ-104 exam<\/a> expects administrators to know how to observe resource health, collect useful telemetry, alert on meaningful conditions and diagnose network failures with evidence rather than guesswork. Azure Monitor provides the broad observability platform, while Network Watcher provides network-specific monitoring and diagnostic tools.<\/p>\n

The distinction matters. Azure Monitor can collect metrics and logs across many resource types, power dashboards and alerts, and support analysis through Log Analytics. Network Watcher focuses on the path packets take and the network controls that affect them. In real troubleshooting, administrators often use both.<\/p>\n

Metrics and logs answer different questions<\/h2>\n

Metrics are numerical time-series values designed for efficient monitoring and alerting. CPU percentage, request counts, latency and other platform measurements are typical examples. They are useful when the question is \u201chow much,\u201d \u201chow often\u201d or \u201cdid this threshold change?\u201d<\/p>\n

Logs contain richer records that can be queried for detail and correlation. Azure Monitor Logs stores data that can be analyzed through Log Analytics with Kusto Query Language. Logs are useful when the administrator needs to inspect events, dimensions and relationships that a single metric cannot explain.<\/p>\n

The wider Microsoft Azure infrastructure certifications<\/a> path requires both perspectives. A metric can tell you that failures increased; logs can help explain which requests, resources or conditions were involved.<\/p>\n

Diagnostic settings route platform data where it needs to go<\/h2>\n

Azure resources emit platform logs and metrics, but retaining and analyzing them often requires diagnostic settings that send selected data to destinations such as a Log Analytics workspace, storage account or event-streaming destination. The correct choice depends on whether the organization needs interactive analysis, long-term retention or integration with another system.<\/p>\n

Administrators should collect data that supports a defined operational purpose. Sending every available category everywhere increases cost and noise. Not collecting a critical category leaves a blind spot during incidents. Monitoring design therefore begins with the questions the operations team must be able to answer.<\/p>\n

Resource-specific diagnostic categories also change over time. A good deployment process treats diagnostic settings as managed configuration rather than a one-time portal choice.<\/p>\n

Log Analytics turns records into operational answers<\/h2>\n

Log Analytics can query Azure Monitor Logs using KQL. Queries can filter events, summarize counts, correlate fields and identify trends across resources. Administrators do not need to become data scientists, but they should be comfortable narrowing a large data set to the records relevant to an incident.<\/p>\n

A useful troubleshooting query normally starts with a time window and the resource or operation involved. From there, the administrator can group failures, compare before-and-after behavior or inspect individual records. Workbooks can visualize query results when a recurring operational view is needed.<\/p>\n

The key is to avoid treating logs as an archive that is only opened after an outage. Mature operations create reusable queries and dashboards for known failure modes and important service objectives.<\/p>\n

Alerts should represent conditions that require action<\/h2>\n

Azure Monitor alert rules evaluate metrics or log queries and trigger when defined conditions are met. Action groups determine what happens next, such as notifying a team or invoking an automation path. A good alert has a clear owner and a clear response.<\/p>\n

Thresholds that are too sensitive create alert fatigue. Thresholds that are too loose allow incidents to develop unnoticed. Dynamic behavior, aggregation window and evaluation frequency all affect whether an alert is useful. Administrators should tune alerts from observed workload behavior rather than copying generic values.<\/p>\n

Alerts also need context. A notification that says \u201cCPU high\u201d is less useful than one tied to the affected resource, time window and response procedure. The goal is not to produce notifications; it is to shorten the time from abnormal condition to informed action.<\/p>\n

Network Watcher exposes the actual network path<\/h2>\n

Azure Network Watcher includes tools for connectivity monitoring and diagnosis. Connection troubleshoot can test a path between supported sources and destinations. Next hop reveals how Azure intends to route a packet. Effective routes show the routes applied to a network interface. IP flow verify and NSG diagnostics help identify security rules that allow or deny traffic.<\/p>\n

These tools are valuable because a network problem can have several causes that look identical to an application. A connection timeout could come from an NSG, a route table, DNS, a guest firewall, an unavailable destination or another network dependency. Network Watcher reduces the need to edit configuration blindly.<\/p>\n

For AZ-104, remember the diagnostic intent of each tool. If the question asks which route Azure will choose, next hop is more direct than packet capture. If the question asks which NSG rule blocks a flow, IP flow verify or NSG diagnostics is more targeted.<\/p>\n

Connection troubleshoot provides path-level evidence<\/h2>\n

Connection troubleshoot can test TCP or ICMP connectivity from supported Azure resources to destinations such as VMs, IP addresses, FQDNs and URIs. It can identify problems including missing routes, NSG blocks, DNS resolution failures and certain guest or platform conditions.<\/p>\n

This makes it a strong first tool when the symptom is \u201csource cannot reach destination.\u201d It tells the administrator whether the path succeeds and surfaces likely causes when it does not. From there, a more specific tool can confirm the route or security rule.<\/p>\n

That sequence is more efficient than opening every NSG and route table manually. Start with the end-to-end symptom, then drill into the layer the diagnostic result identifies.<\/p>\n

Effective routes and next hop explain routing surprises<\/h2>\n

A VM network interface can receive routes from Azure system behavior, user-defined route tables and BGP propagation through a gateway. Looking at one route table therefore does not always reveal the route the VM will actually use. Effective routes combine those sources.<\/p>\n

Next hop answers a related but more specific question: for a given source and destination, what next-hop type and route will Azure select? This is useful in hub-and-spoke environments where a user-defined route may steer traffic through a firewall or where peering and gateway routes overlap.<\/p>\n

When the selected next hop is wrong, fix routing. When the next hop is correct but traffic is denied, move to security diagnostics. Keeping those layers separate speeds troubleshooting.<\/p>\n

Network diagnostics should be paired with application telemetry<\/h2>\n

A successful network test proves reachability, not application health. An HTTP service can accept TCP connections and still return errors. A VM can be reachable while the application process is stalled. Conversely, application errors may be caused by intermittent network latency rather than a complete outage.<\/p>\n

Azure Monitor metrics and logs provide the workload view, while Network Watcher provides the connectivity view. Correlating timestamps across both can reveal whether an application incident coincided with packet loss, routing change, resource saturation or another platform signal.<\/p>\n

This cross-layer method is central to the Azure administrator role<\/a>. Administrators are valuable because they can move between resource, network and monitoring evidence instead of escalating every symptom to a different team without analysis.<\/p>\n

Monitoring should be designed before the incident<\/h2>\n

Waiting for an outage to discover that logs were never retained is an avoidable failure. Important resources should have diagnostic settings, alert rules and ownership defined during deployment. Network topology and connection monitoring can also be prepared for critical paths before they fail.<\/p>\n

Retention and cost still matter. More telemetry is not automatically better. The organization should keep enough history to investigate likely incidents and satisfy operational or compliance requirements without collecting high-volume data that nobody uses.<\/p>\n

The broader cloud architecture certification<\/a> perspective treats observability as a design requirement. AZ-104 turns that requirement into operational work: configure the signals, query them, alert on them and use the right diagnostic tool when users report a problem.<\/p>\n

Use an evidence-first troubleshooting sequence<\/h2>\n

Define the symptom and time window. Check resource health and relevant metrics. Review logs for errors or configuration events. If the issue is connectivity, use connection troubleshoot. Inspect effective routes or next hop when routing is suspect, and use IP flow verify or NSG diagnostics when filtering is suspect.<\/p>\n

This sequence prevents random changes that destroy evidence or create new problems. On the exam and in production, the best administrator is not the person who changes the most settings. It is the person who can identify the failing layer from the available signals and make the smallest justified correction.<\/p>\n

Activity Log and Resource Health add management context<\/h2>\n

Not every Azure incident begins inside the guest operating system or application. The Azure Activity Log records subscription-level management events such as resource creation, updates and deletions. If connectivity stopped immediately after a route table or NSG change, the Activity Log can help identify who changed the configuration and when.<\/p>\n

Resource Health answers a different question by reporting the current and historical health of individual Azure resources from the platform perspective. This helps distinguish a customer configuration problem from an Azure platform issue affecting the resource. Service Health operates at a broader service and regional level, while Resource Health focuses on the specific resource experience.<\/p>\n

These signals complement metrics, logs and Network Watcher. A complete investigation may begin with an alert, identify a failed connection through Network Watcher, and then use Activity Log to find the configuration change that introduced the problem. Building that evidence chain is more valuable than relying on any one monitoring screen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Monitoring is where an Azure configuration becomes an operated service. The AZ-104 exam expects administrators to know how to observe resource health, collect useful telemetry, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2709","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/2709","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/comments?post=2709"}],"version-history":[{"count":0,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/2709\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/media?parent=2709"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/categories?post=2709"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/tags?post=2709"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}