Azure Monitor data is valuable only when administrators can connect the right signal to an operational decision. This AZ-104 guide shows how Log Analytics, KQL queries, metric\/log alert rules and action groups fit into a failure-response workflow and why missing telemetry is not proof of health.<\/p>\n
Azure operations generate multiple forms of telemetry, and the place where data is stored changes what administrators can investigate. A metric can help detect that a VM’s CPU is elevated; a log record can explain which change or operation occurred; an alert rule can evaluate a signal; and an action group can send an appropriate notification or invoke a supported automation. None of these, independently, proves that a user-facing operation failed or was repaired.<\/p>\n
A useful Azure Monitor alert begins with a claim the operations team can verify: for example, the production API’s 5xx error rate exceeded a specific threshold during the past ten minutes for a named workload. Choose a metric or KQL query that supports the claim, validate time-window behavior and data freshness, and record which action group receives a real alert and under what identity. A malformed filter may alert on test traffic or miss an outage completely. AZ-104 monitoring practice<\/a> scenarios become more informative when the correct answer distinguishes data collection, query results, rule evaluation and notification delivery rather than treating creation of a Log Analytics workspace as proof that an incident will be detected and acted on.<\/p>\n Start by asking what the operations team must learn. "Something is wrong in production" is not a measurable criterion. "The web API has exceeded its agreed server-error budget during the previous ten minutes" is closer to a testable objective. Identify which Azure metrics, logs or application telemetry support that claim, their retention and freshness, and the action the team should take if it becomes true.<\/p>\n Consider a fictional web API running on Azure VMs. The team wants to identify unexpected resource restarts and correlate them with infrastructure changes. Activity Log data covers subscription-level management activity, while guest-operating-system logs may need a configured collection method. The administrator should not assume every Windows event or Linux syslog line is automatically present in a workspace just because the VM exists.<\/p>\n Source selection affects visibility. Resource metrics may arrive through Azure Monitor without an extra diagnostic setting for every service, but many resource logs require explicit routing, supported categories and a destination. Some services offer data-collection rules and workload-specific integrations. Record which data actually reaches which table before building alert logic on it.<\/p>\n A Log Analytics workspace supports KQL queries over collected tables. Diagnostic settings for eligible resources can send supported logs to workspaces, storage or event hubs, subject to category and plan behavior. A missing record can mean the event never happened, the collection agent or rule was wrong, permissions blocked it, latency delayed ingestion or the query selected an unsuitable table.<\/p>\n Define table ownership and schema first. An AzureActivity query examines control-plane operations and will not automatically report application business errors. VM guest-performance and event tables depend on actual collection configuration. A query that returns zero rows from a workspace with no configured data collectors is not proof the environment had zero incidents.<\/p>\n For each signal, document its originating resource, table, timestamp semantics, relevant resource identifier and expected ingestion latency. A query for the last minute can look artificially healthy if events routinely arrive later. Test the observation interval before assuming a quiet dashboard indicates a healthy service.<\/p>\n KQL operators such as where, project, summarize, extend and order by let administrators select relevant evidence. Consider this illustrative query against AzureActivity, assuming that the workspace collects that table:<\/p>\n This example counts management operations by operation-name field; it does not identify whether all changes were legitimate or whether a production outage occurred. Examine actual OperationNameValue and resource fields in your workspace before treating a grouping as an incident. Aggregating by friendly operation name alone can hide which subscription or resource was affected.<\/p>\n To triage a real failed deployment, narrow the query by resource ID or operation, inspect status values and correlate the event time with application health. Use project to display only the fields a reviewer needs. Overly broad queries can consume compute and make important evidence difficult to find; overly narrow filters can conceal unexpected sources.<\/p>\n Always qualify time zones and the difference between ingestion time and event time where tables support the relevant fields. An incident that happened just before a log-collection disruption might be visible later even when a short lookback query initially returned no results.<\/p>\n Azure Monitor alert rules<\/a> can evaluate metrics, logs and other supported signals. The appropriate type depends on data frequency and what the rule is intended to detect. A metric alert may be appropriate for a sustained CPU threshold; a log-search alert can use KQL to detect a pattern across collected records. An alert rule must specify scope, evaluation conditions and supported timing settings, not just contain a query that once returned an interesting line.<\/p>\n For a synthetic service with an error budget, choose a signal that reflects failures users experience. If a log query counts the same retry operation as three separate failed customer requests, its apparent failure rate may not match the business impact. If telemetry is delayed, a narrow evaluation window can miss data. Test the signal against representative incidents before setting a paging threshold.<\/p>\n Azure offers dynamic threshold options for certain metric scenarios. Their behavior and prerequisites differ from fixed thresholds and log-based conditions. An administrator should not assume that every new service or dataset has enough historical data for a dynamic threshold to work well. Document why the threshold exists, who receives it and what constitutes recovery.<\/p>\n An action group contains supported actions for responding to alerts, such as email, SMS, push, webhooks or integrations depending on region and configuration. Reuse an action group when several alert rules intentionally share the same responders and escalation paths. Do not embed permanent personal contact details into every rule if organizational responders can be managed centrally.<\/p>\n Sending a message is not repairing the incident. Define what the recipient must examine, which runbook is appropriate and when the incident should be escalated. If a webhook triggers automation, the receiving service must still enforce authentication and authorization; an alert is not itself permission to restart all machines or delete resources.<\/p>\nChoose a signal from a failure question<\/h2>\n
Log Analytics stores queryable records<\/h2>\n
KQL helps narrow a large dataset<\/h2>\n
AzureActivity\n| where TimeGenerated > ago(30m)\n| summarize ChangeEvents = count() by OperationNameValue\n| order by ChangeEvents desc<\/code><\/pre>\nAlert rules evaluate signals under a schedule<\/h2>\n
Action groups route notifications and operations<\/h2>\n