You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Azure Monitor collects and stores numerical values called metrics that describe aspects of a system at a particular point in time. These metrics are automatically gathered at regular intervals from Azure resources. The key metrics you need to interpret include CPU usage, memory usage, disk I/O, and network traffic. Each of these values directly affects the performance and health of a resource. For example, high CPU usage signals a compute bottleneck, while elevated disk I/O may indicate storage contention. Understanding what each metric represents allows you to evaluate whether a resource is operating within expected limits.
Metrics are collected automatically and stored in a time-series database. You can view them using the Metrics Explorer in the Azure portal, which provides charts and aggregation options. For deeper analysis, you can route platform metrics to a Log Analytics workspace and query them with the Kusto query language (KQL). Additional tools include Dashboards for combining data in a single pane, Workbooks for customizable reports, Grafana for open-platform dashboards, and Power BI for interactive visualizations. The Azure Monitor REST API and client libraries let you extract metric data for use in external tools.
Azure Monitor alerts allow you to proactively identify and address issues by checking metrics or log data against conditions you define. You can set up alerts on any metric or log data source in the platform. When a metric crosses a threshold—such as CPU usage exceeding 90%—the alert triggers a notification, enabling you to respond before the problem affects users. This connection between metric interpretation and alerting is essential for maintaining resource availability.
Aggregation combines multiple metric values into a single data point using specific logic. Azure Monitor supports Sum (total of all values), Average (mean, often calculated as Sum/Count), Min and Max (smallest or largest values), and Count (number of measurements). Choosing the correct aggregation type is critical because it determines how the data is summarized. For instance, Average smooths out spikes, while Max highlights worst-case behavior. An administrator looking at disk I/O might use Average to see typical load but switch to Max to detect rare bursts.
The Time Range defines the total duration of data shown on a chart, while Time Granularity (or time grain) sets the interval used for each data point. A smaller granularity gives more detail but can produce a noisy chart; a larger granularity smooths fluctuations. The time brush feature lets you zoom into specific spikes or dips for root-cause analysis. When you adjust the time range, you decide whether to view a short window for anomaly investigation or a longer window for trend evaluation.
Dimensions are metadata categories that add context to a metric, such as the name of a server or the status code of a request. Filtering isolates a subset of data—for example, showing only throttled requests. Splitting displays separate lines for each dimension value, making it easy to compare individual instances within a group. By combining filtering and splitting, you can compare the performance of different virtual machines or API endpoints side by side on the same chart.
Beyond basic charts, Workbooks and Dashboards combine metrics, logs, and traces into a unified view. Integration with Grafana and Power BI supports advanced business analytics and cross-platform visualization. These tools help transform raw numerical data into actionable intelligence, allowing stakeholders to see performance trends and anomalies at a glance.
To diagnose resource health, you first select relevant metrics that reflect the resource's condition, such as CPU percentage, Disk IOPS, or Network In/Out. Then you aggregate values using Average, Sum, Minimum, or Maximum to understand overall trends or spot spikes. Adjusting time granularity lets you zoom in on short-term anomalies or examine long-term patterns. Finally, applying filters and splitting by dimensions (for example, region or operation type) helps you isolate outliers and compare segments.
For deeper root-cause analysis, you can use Log Analytics with the Kusto query language (KQL) to correlate metric data with log data. This combination allows you to trace a CPU spike to a specific code error or a network latency increase to a regional outage. Azure Monitor stores metrics in a time-series database, making them suitable for real-time analysis and trend identification. By correlating metric patterns with incidents, you can determine the underlying cause of performance or availability issues.
Azure Monitor's alerting system supports metric alerts, log alerts, and activity log alerts, each suited for different scenarios. You can set dynamic thresholds for anomaly detection, so the system learns normal behavior and alerts only when metrics deviate significantly. When a metric crosses a defined threshold—such as degraded resource health or high CPU usage—an alert triggers, enabling proactive response. This analytical capability, combined with the ability to export metric data via the REST API and integrate with Dashboards, Workbooks, Grafana, or Power BI, gives you comprehensive insight into resource health and helps you quickly diagnose and resolve issues.
A Log Analytics Workspace acts as the central data store where Azure Monitor collects and stores telemetry from cloud and on-premises resources. Administrators must choose a pricing model, selecting between Pay-as-you-go for flexibility or Commitment Tiers that offer discounts for ingesting at least 100 GB daily. Consolidating data into a single workspace helps reach commitment tier thresholds faster and reduces the administrative burden of managing multiple workspaces.
The cost and capabilities of stored logs depend on Table Plans. The Analytics plan provides full query and alerting features for high-value data, while the Basic and Auxiliary plans offer lower costs for debugging or compliance storage. Retention policies can be set interactively for immediate querying or configured for Long-term retention reaching up to 12 years for regulatory requirements.
Data flows into the workspace through two main pathways: Diagnostic Settings capture Azure platform logs, while the Azure Monitor Agent (AMA) collects guest operating system data from virtual machines. Both methods use Data Collection Rules (DCRs) to define what data gets gathered and where it goes. Key log sources include Azure Activity Logs for subscription-level events, Resource Logs for service-specific operational data, and Custom Logs ingested via the Logs Ingestion API.
Access to log data is controlled through the Access Control Mode, which determines how users authenticate to view data. Workspace-context permissions grant access to the entire workspace, while Resource-context RBAC allows users to see logs only for resources they already own. For sensitive data, Table-level RBAC can restrict access to specific security tables while keeping operational data visible.
To maintain a healthy environment, administrators use Log Analytics Workspace Insights to track ingestion trends and identify cost-saving opportunities. A Daily Cap can prevent budget overruns by stopping collection once a limit is reached, though this should be used carefully to avoid losing critical monitoring data.
Log data moves through a lifecycle that begins with interactive retention in the workspace, where it can be queried immediately using Kusto Query Language. Administrators can set different retention periods for specific data types or move older data to long-term retention reaching up to 12 years. When archiving to an Azure Storage Account, a lifecycle management policy automates when data moves to cheaper storage tiers or gets deleted.
Continuous export automatically streams log data to Azure Event Hubs or Azure Storage Accounts as it arrives, enabling integration with third-party SIEM systems or external analytics platforms. Export destinations must reside in the same region as the workspace to function properly. Administrators should avoid exporting to the same storage account being monitored, as this creates recursive logging that inflates data volumes.
The choice of Table Plans affects export capabilities. The Analytics plan works best for data used in active alerting, while the Basic plan reduces ingestion costs for troubleshooting logs. The Auxiliary plan provides a cost-effective solution for meeting compliance requirements on large data volumes with limited query needs.
Compliance requirements are met through features like immutable storage, which prevents data alteration during a set period, and Customer-managed keys (CMK) for encryption. Azure Private Link restricts workspace access to authorized networks, preventing data exposure to the public internet.
Monitoring export health involves tracking Azure Monitor metrics for Bytes Exported and Export Failures. Alerts on these metrics enable proactive responses such as increasing storage limits, enabling Auto-inflate on Event Hubs, or splitting high-volume tables across multiple export rules to distribute load.
Diagnostic settings determine which logs and metrics Azure Monitor collects from resources, making them essential for effective monitoring. These settings define the data categories to capture and where that data gets sent, enabling troubleshooting, security analysis, and compliance reporting.
The primary logging destination options include Log Analytics workspace for advanced querying, Azure Storage Account for long-term archival, and Azure Event Hubs for real-time streaming to external systems. Each destination serves different needs: workspace analysis, compliance storage, or integration with security tools.
Enabling diagnostic logging requires navigating to the resource in the Azure portal and accessing its Diagnostic settings panel. Here, administrators select the log categories needed—such as activity logs, resource logs, and metrics—and specify the destination for storage. The workspace must be in a supported region, and destinations should remain within the same network security perimeter as the source resource to maintain log flow.
Proper configuration also involves setting retention policies that balance cost against compliance requirements. Longer retention increases storage costs but may be necessary for regulatory compliance, while shorter retention reduces expenses but may limit investigation capabilities.
For automation, administrators can use PowerShell cmdlets to configure diagnostic settings at scale. Telemetry settings can be tuned by adjusting log levels and sampling rates, ensuring critical information gets captured without overwhelming storage and processing resources.
A Log Analytics workspace serves as a centralized data store in Azure to collect and analyze telemetry from diverse cloud and on-premises sources. When designing a workspace architecture, administrators must balance data isolation requirements with administrative simplicity. While a single workspace reduces overall management complexity, creating multiple workspaces is often necessary to meet strict regional, regulatory, or billing boundaries.
To control costs, workspaces manage incoming data using specific table plans and retention policies. The Analytics plan supports full query capabilities for active investigation, whereas the Basic plan offers a lower-cost option for high-volume logs with limited query features. Data can reside in interactive retention for immediate querying or shift to long-term retention for up to 12 years to meet compliance mandates.
Securing this telemetry requires implementing Azure Role-Based Access Control (RBAC) at various scopes. Administrators can grant wide access using workspace-context permissions, or they can restrict visibility using resource-context permissions, which limit users to viewing logs only for the specific Azure resources they manage. For even tighter security boundaries, table-level RBAC restricts access to specific sensitive tables, and built-in roles like Log Analytics Reader and Log Analytics Contributor establish base operational permissions.
To enforce governance and manage expenses, organizations can deploy Azure Policy to prevent unauthorized workspace creation. Budget spikes can be avoided by setting a daily cap on data ingestion or by choosing commitment tiers to receive discounted rates on predictable, high volumes of data. In high-security environments, dedicated clusters support customer-managed keys for encryption, while Azure Private Link secures data transfer by disabling public network endpoints.
Azure Monitor Logs serves as a centralized platform that gathers telemetry across multiple environments. To retrieve and manipulate this data, administrators use Log Analytics in the Azure portal, which supports both a Simple mode for basic exploration and a KQL mode for advanced query editing. To analyze complex systems, administrators can execute cross-resource queries to pull data across multiple workspaces and resources simultaneously.
Processing massive datasets can lead to query timeouts or performance issues. To solve this, administrators implement summary rules to aggregate raw logs as they are ingested into the workspace. This practice optimizes cost by reducing raw data storage, increases dashboard loading speed, and improves overall query reliability.
Once data is retrieved, it can be displayed using various visualization tools depending on the target audience. Azure Monitor Workbooks provide an interactive canvas to combine text, queries, and metrics from multiple sources into rich, shareable reports. For a continuous, high-level overview of system health, administrators can pin critical query results to Azure Dashboards.
Proactive operations rely on identifying system issues before they cause downtime. By applying machine learning pipelines and anomaly detection, administrators can automatically spot long-term seasonal trends and unexpected deviations. These analytical insights can trigger log search alerts to run automated response workflows when specific threshold violations occur.
Kusto Query Language (KQL) is the primary query tool used to analyze log data within Azure Monitor. Similar to SQL, KQL operates on schema entities structured as tables and columns. It supports common relational operators such as project to select columns, where to filter rows, join to combine tables, and summarize to aggregate data.
Basic queries often target resource diagnostics to identify performance bottlenecks. For example, a query can filter diagnostic logs for resource usage stats over a specific time threshold to isolate instances with an average CPU utilization above 95%. Another query can calculate storage space usage as a percentage of reserved storage to surface managed instances exceeding 90% capacity.
For advanced analysis, KQL provides native machine learning operators to perform time series analysis, forecasting, and root cause analysis directly within the workspace. This built-in capability removes the need to export data to external tools for deep analysis. However, when external reporting is required, data can be exported using the REST API for metrics and logs, or through Workspace Data Export.
Visualizing KQL results can be accomplished through native tools like dashboards and workbooks, as well as external integrations like Grafana and Power BI. Integrating these visualizations with Azure Monitor alerts ensures that administrators receive prompt notifications when specific data conditions are met. This setup enables operations teams to move quickly from passive observation to active incident response.
Alert rules in Azure Monitor are the foundation of proactive monitoring. They define the conditions—such as a metric crossing a threshold or a log query returning a specific result—that trigger alerts. When an alert fires, the rule determines what happens next by specifying one or more action groups and optionally linking to alert processing rules. You can create alert rules manually for any Azure resource, or you can use Recommended Alerts to quickly enable predefined rules for a supported service. A more scalable approach is Azure Monitor Baseline Alerts (AMBA), which provides product-group and field-tested alert definitions for compute, networking, and Service Health resources. AMBA ships as deployable ARM, BICEP, or policy definitions, making it easier to enforce consistent alerting across many resources at once.
Azure Policy takes automation further by automatically applying alert rules to every current and future resource of a given type. This ensures that no new virtual machine or storage account escapes monitoring. When you define the alert logic in a policy, the alert rules are created behind the scenes for each resource. No matter which creation method you choose, each alert rule must be associated with at least one action group to define the response—whether that is a notification, an automated task, or both.
Action groups are reusable collections of notification methods and automated actions that execute when an alert fires. Each action group can include email, SMS, push notifications via the Azure mobile app, voice calls, and more advanced integrations such as webhooks, Azure Functions, Logic Apps, Automation Runbooks, and ITSM connectors like ServiceNow. By attaching the same action group to multiple alert rules, you centralize who gets paged and which workflows run, reducing duplicated configuration. A single alert rule can reference up to five action groups, and all actions within those groups run concurrently.
Action groups support an especially useful notification channel: Email Azure Resource Manager Role sends alerts to everyone who holds a specific RBAC role rather than a fixed list of addresses. For SMS and voice, recipients can reply to unsubscribe or resubscribe without leaving the workflow. When you need to suppress notifications during planned maintenance or route alerts to different teams based on severity, you combine action groups with alert processing rules. Because action groups execute in parallel and can be deployed globally or regionally, they remain resilient even if one region experiences an outage. Service limits on email and SMS volume mean that large-scale environments should prefer automation endpoints—such as an Automation Runbook that creates an incident ticket—over human notification channels.
Alert processing rules (formerly called action rules) do not create alerts; they modify the behavior of alerts that have already fired. Their two primary actions are Suppression and Apply action groups. Suppression stops all notifications during a defined window—for example, during a maintenance period—without disabling the underlying alert rules. The Apply action groups action adds extra notification channels to alerts, which is especially useful for older Azure services that do not natively support action groups.
The scope of an alert processing rule can be a single resource, a resource group, or an entire subscription. Within that scope you add Filters to narrow the rule's effect based on criteria such as severity, monitor service, or resource type. Multiple different filters use AND logic, meaning all conditions must match for the rule to apply. Within a single filter, multiple values use OR logic, so a filter monitoring severity can catch both Error and Critical in one condition. When an alert is matched by more than one processing rule, a Suppression action always takes priority over an Apply action group action. This hierarchy prevents conflicting rules from accidentally sending notifications during a suppression window.
Scheduling gives you fine-grained control over when a processing rule is active. You can set it to be Always active, use a One-time window for a specific event, or define a Recurring schedule for weekly maintenance. By combining scope, filters, and scheduling, a single alert processing rule can manage thousands of underlying alert rules. This reduces human error and ensures that high-severity incidents always reach the correct response team, while expected noise from planned work is silently dropped. Administrators can create and manage these rules through the Azure Portal, Azure CLI (az monitor alert-processing-rule), or PowerShell (Set-AzAlertProcessingRule).
Diagnostic settings are the primary mechanism for routing resource logs and platform metrics to destinations such as a Log Analytics workspace, an Azure Storage account, or an Azure Event Hub. These settings capture granular operational data that is not collected by default, and by selecting specific log categories administrators can control which information is stored to manage costs. For virtual machines, Data Collection Rules (DCRs) define the telemetry gathered by the Azure Monitor Agent (AMA). A DCR acts as a blueprint specifying which performance counters and Windows or Syslog events to send to a workspace, and a single DCR can apply to multiple VMs for consistent monitoring across the environment. This method replaces older agents and offers granular control over data filtering through transformations.
Monitoring virtual machines involves tracking both the VM host and the guest operating system. Host metrics such as CPU and disk utilization are collected automatically, but guest-level data requires the AMA and a DCR. VM Insights streamlines this process by automatically deploying the agent and configuring a default DCR. Key features include performance views with predefined charts for core metrics, a map feature that visualizes processes and dependencies between machines, and health monitoring that tracks the availability and status of workloads. Azure Storage accounts and Virtual Networks also require specific diagnostic configurations. For storage, you must enable diagnostic settings for each service type, such as Blobs or Files, to capture access logs and transaction data. Networking resources use diagnostic settings to record NSG flow logs and resource logs vital for security auditing. Integrating this data into a Log Analytics workspace enables complex cross-resource analysis using the Kusto Query Language (KQL).
Effective data collection requires balancing visibility with cost optimization. Azure Monitor allows transformations within a DCR to filter out unnecessary columns or rows before ingestion. Reducing the polling frequency of performance counters and avoiding duplicate data streams are critical steps for maintaining a budget. Administrators should regularly use Log Analytics workspace insights to identify high-volume data sources and adjust collection settings accordingly.
Azure Monitor Insights provides comprehensive monitoring of health, performance, and availability for virtual machines, storage accounts, and networks through dedicated tools: VM Insights, Storage Insights, and Network Insights. These tools visualize and analyze key metrics and logs such as CPU, memory, disk, network utilization, and application dependencies, helping identify trends, troubleshoot issues, and optimize resource usage. Data collection relies on platform metrics, activity logs, and resource logs. Metrics like CPU usage are collected automatically and stored in the Azure Monitor metrics database. For deeper analysis, install the Azure Monitor Agent on VMs and configure Data Collection Rules (DCRs) to gather guest OS performance counters, application logs, and custom events. Use Log Analytics and Kusto Query Language (KQL) to query and correlate data across resources for advanced troubleshooting and reporting.
Visualization tools within Azure Monitor include Metrics Explorer for charting performance trends, Workbooks for creating interactive dashboards with metrics and log queries, Dependency Maps for understanding process relationships, and integrations with Grafana and Power BI for custom dashboards. To proactively address issues, configure alert rules in Azure Monitor. You can create metric alerts based on threshold breaches, log alerts using KQL queries, and activity log alerts for resource changes. Alerts can be set at scale using multi-resource alert rules and Azure Monitor Baseline Alerts (AMBA). Action groups automate responses such as email or SMS notifications, webhooks, and Logic Apps for remediation workflows.
Recommended practices include enabling recommended alerts for common VM issues like server downtime or agent heartbeat failures, using dynamic thresholds for metric alerts that leverage machine learning for baseline detection, and routinely reviewing Advisor recommendations for personalized guidance. Integration with Microsoft Defender for Cloud and Microsoft Sentinel enhances security and threat detection, while Azure RBAC manages access. By leveraging these insights and robust alerting, you ensure a healthy, secure, and performant Azure infrastructure with proactive monitoring and rapid incident response.
Azure Monitor Insights helps monitor and analyze performance across virtual machines, storage accounts, and networks. To monitor session hosts, install the Azure Monitor Agent on all hosts in the pool and send data to a Log Analytics workspace. If some hosts are not sending data, select the Data Collection Rule (DCR) for data collection, deploy the agent, configure the required managed identity, and refresh the configuration workbook. Performance counters are essential for collecting performance data from session hosts. Check the Configured counters and Missing counters in the configuration workbook, enable any missing counters by selecting Configure performance counters, and then refresh the workbook to verify all required counters are enabled.
Windows Event Logs collect errors, warnings, and information from session hosts. Check Configured Event Logs and Missing Event Logs in the configuration workbook, enable missing logs by selecting Configure Events, and refresh the workbook. Azure Monitor allows setting up alerts for various metrics and logs to identify performance issues and take corrective actions. The Traffic tab in Azure Monitor Insights provides a detailed view of network security groups and their configurations for NSG flow logs and Traffic analytics. You can search for specific IP addresses and view configuration status and alerts. The Diagnostic Toolkit offers tools such as packet capture, VPN troubleshoot, connection troubleshoot, next hop, and IP flow verify for diagnosing network performance problems.
Azure Monitor Insights also provides visibility into the health of networking resources. Some resources are Onboarded, offering a specific topology view and built-in metrics workbook for easier exploration. To troubleshoot performance problems, refer to the documentation for the malfunctioning resource. You can make changes or add visualizations by selecting Edit Mode in the workbook. The diagnostics service tracks activity logs such as WVDCheckpoints, WVDConnections, WVDErrors, and more, and estimating data ingestion per VM per day helps manage monitoring costs. Use custom queries to analyze data ingestion in your Log Analytics workspace, tracking frequency and size of performance counter data to identify cost-reduction opportunities. Estimate total costs based on size estimates per day for performance counters, events, and diagnostics, and consider the Pay-as-you-go or Capacity Reservation model for Log Analytics pricing. Measure and manage data ingestion to optimize costs, and be aware of known issues such as query errors or missing connection events, regularly reviewing and updating monitoring configurations.
Connection Monitor is a tool within Azure Network Watcher for monitoring connectivity and performance across cloud and hybrid networks. You create a test by defining a Test Group, which links your source endpoints (like Azure VMs or on-premises servers) to destination endpoints (which can be IPs, URLs, or other VMs). Each test uses a Test Configuration that specifies the protocol (TCP, ICMP, or HTTP) and how often the test runs.
For the tests to work, specific software must be installed on the resources. Azure VMs need the Network Watcher extension, while on-premises machines require the Azure Arc agent and Azure Monitor Agent to act as sources. You also set Success Thresholds for metrics like round-trip time and packet loss; if performance drops below these levels, the test state changes to Warning or Fail.
After tests run, you can analyze results through a Unified Topology view. This map shows every network hop between source and destination, visually pinpointing where latency or packet loss occurs. You can also create Metric-based alerts in Azure Monitor to get automatic notifications when connectivity issues, like a high percentage of failed checks, are detected.
Azure Network Watcher is a regional service for monitoring and diagnosing network issues in Azure. To use it, you must first enable it in your desired Azure region. This can be done via the Azure portal, PowerShell, Azure CLI, or an ARM template. When created, its name is automatically set to NetworkWatcher_region and it is placed in a resource group named NetworkWatcherRG.
Network Watcher provides several diagnostic tools. Packet Capture allows you to record traffic to and from a VM for deep analysis, storing the data in a storage account. Connection Monitor (covered in detail in the previous section) is used to track network performance metrics. These tools can be integrated into automated workflows; for example, an alert from a VM could trigger an Azure Function to start a packet capture session automatically.
To use Network Watcher effectively, you need the latest Azure PowerShell module and a VM in the same region with the necessary extensions installed. By setting up Network Watcher and its tools, you gain the ability to proactively diagnose and resolve network performance and connectivity problems across your Azure resources.
Network Watcher includes several specialized tools for troubleshooting. IP flow verify checks if traffic is allowed or denied to a specific VM. It identifies the exact Network Security Group (NSG) rule causing the action, which is crucial for fixing security rule misconfigurations. Similarly, Next hop determines the routing path for traffic, showing the next hop type and route table ID to help verify if packets are being routed correctly through Azure's network.
For testing connectivity at a specific moment, Connection troubleshoot evaluates whether a source (like a VM) can reach a destination, such as an FQDN or URI. This is useful for diagnosing outbound connection failures. For ongoing, detailed traffic analysis, Packet capture can be started remotely to collect network packets, which can then be analyzed with external tools to measure round-trip time or spot unusual protocols.
For hybrid network issues, VPN troubleshoot diagnoses problems with virtual network gateways and their connections to on-premises sites. Finally, Flow logs (when enabled for NSGs) and Traffic analytics provide broad visibility into network traffic patterns. They help identify malicious activity, understand application behavior, and optimize network capacity planning across your subscriptions.
Azure Monitor collects and stores numerical values called metrics that describe aspects of a system at a particular point in time. These metrics are automatically gathered at regular intervals f…
Azure Monitor collects and stores numerical values called metrics that describe aspects of a system at a particular point in time. These metrics are automatically gathered at regular intervals f…
Alert rules in Azure Monitor are the foundation of proactive monitoring. They define the conditions—such as a metric crossing a threshold or a log query returning a specific result—that trigger al…
Alert rules in Azure Monitor are the foundation of proactive monitoring. They define the conditions—such as a metric crossing a threshold or a log query returning a specific result—that trigger al…
A Log Analytics Workspace acts as the central data store where Azure Monitor collects and stores telemetry from cloud and on-premises resources. Administrators must choose a pricing model, selecti…
A Log Analytics Workspace acts as the central data store where Azure Monitor collects and stores telemetry from cloud and on-premises resources. Administrators must choose a pricing model, selecti…
A Log Analytics workspace serves as a centralized data store in Azure to collect and analyze telemetry from diverse cloud and on-premises sources. When designing a workspace architecture, administ…
A Log Analytics workspace serves as a centralized data store in Azure to collect and analyze telemetry from diverse cloud and on-premises sources. When designing a workspace architecture, administ…
Diagnostic settings are the primary mechanism for routing resource logs and platform metrics to destinations such as a Log Analytics workspace, an Azure Storage account, or an **Azure …
Diagnostic settings are the primary mechanism for routing resource logs and platform metrics to destinations such as a Log Analytics workspace, an Azure Storage account, or an **Azure …
Connection Monitor is a tool within Azure Network Watcher for monitoring connectivity and performance across cloud and hybrid networks. You create a test by defining a Test Group, which links …
Connection Monitor is a tool within Azure Network Watcher for monitoring connectivity and performance across cloud and hybrid networks. You create a test by defining a Test Group, which links …
StudyCerts
StudyCerts