4 posts tagged with "KQL"

Hello Friends, Welcome back to the Part 3. In Part 1, We covered the security concern behind broad outbound firewall rules and explained why tenant visibility matters. In Part 2, We have walked through the PowerShell script that takes a list of storage FQDNs and resolves each one to a tenant ID using the WWW-Authenticate header trick.

The script is ready. The missing piece is the list itself. In a real environment you are not going to type out FQDNs with your hands; you are going to pull them from Azure Firewall logs. That is what this part covers. I will walk through both Azure Firewall log formats, show the KQL queries I use to extract storage FQDNs from each, and then connect the output directly to the script so the full pipeline runs end to end.

Hello Friends,

Welcome to the final part of this series. In Part 1 we covered why Premium SSD creates the oversizing problem in the first place, how the pricing model for Premium SSD v2 actually works, and how to identify which disks in your environment are worth migrating. In Part 2 we went through the snapshot-based migration itself, built a PowerShell script that handles the full workflow with a WhatIf mode, and looked at a Bicep pattern for new deployments with zone alignment done correctly from the start.

Now that the disks are running on Premium SSD v2, there is one more thing I want to address, because this is where I see most teams leave money on the table. When you create a Premium SSD v2 disk, you have to decide on IOPS and throughput values at that moment. Most people base that decision on what the old Premium SSD tier was delivering, which was itself a number that came from disk size, not from any measurement of what the workload actually needed. So you migrate, and you carry the same inflated numbers across to the new SKU.

In this part we will look at how to use real utilization data to right-size those values, how to write KQL queries that show you what the disk is actually doing, and how to set up Azure Monitor alerts that surface problems before they affect anything.

Hello Folks, Welcome back to the second part of our journey to transition from the Log Analytics agents to the Azure Monitor Agent (AMA). In the first part, we learned how to find and check the monitoring agents using KQL. In this part, we'll continue our journey by identifying the agents that have reported to the Log Analytics Workspace and then extend our query to include all virtual machines within your subscription or tenant.

Last time, we discovered which virtual machines were running the old MMA or OMS agents. This time, we're refining our search to quickly determine whether a machine uses MMA or the updated AMA.

Hello Folks, We're going to look closely at Azure's monitoring tools, focusing on moving from the Log Analytics agents to Azure Monitor Agent (AMA). This is the first step in our journey. We'll learn how to find and check the monitoring agents using KQL to help us identify the agents we need to migrate.

As Microsoft announced the retirement of the Log Analytics agent on August 31, 2024, it's imperative to gear up for what lies ahead. Post-retirement, utilizing the MMA or OMS agent could lead to certain expectations and operational shifts that we need to be prepared for.

🕐 The Clock is Ticking for MMA and OMS​

Why focus on this transition, you might wonder? Moving from MMA (Microsoft Monitoring Agent) and OMS (Operations Management Suite) to AMA isn't just about staying current with Azure's offerings. It's about tapping into improved security, efficiency, and the fresh features that AMA offers. Microsoft's decision to retire MMA and OMS is a strategic step towards enhancing and simplifying the monitoring experience for infrastructure.