Migrate to Azure Monitor Agent for better security, reliability and ease of management

Posted by

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

About a year ago, we launched the Azure Monitor Agent (or AMA) as a powerful new agent from Azure Monitor and a simpler world of data collection. A lot of you adopted it already. Some witnessed a 50% cost reduction with the agent's filtering capabilities while others saw a reduction of 2000 person-hours using Data Collection Rules to centrally manage agent configuration. We also made a bunch of improvements (view past releases) in response to your growing needs around security, reliability, supporting new information, resource types, distros, operating systems, and network perimeters, to make the agent even more powerful and resilient. If you haven't already, adopt and migrate to AMA today to get all the benefits with more coming soon!

 

I'm using the Log Analytics agents today - why should I migrate?

Azure Monitor Agent was also created to consolidate legacy agents within Azure Monitor, especially the Log Analytics Agents (also referred to as "MMA" or "OMS" agent). With the Log Analytics agent deprecation date of August 2024 getting closer, you should start testing and rolling out the new agent. Say goodbye to support ticket marathons, management headaches, unmanageable costs and security concerns by moving off of the legacy agents and adopting AMA today!

Here are some key benefits of migrating to AMA:

  • Security and performance
    • AMA uses Managed Identity or Azure Active Directory (Azure AD) tokens (for clients), which are much more secure than the legacy authentication methods.
    • AMA provides a higher events per second (EPS) upload rate compared to legacy agents.
  • Cost savings 
    • AMA relies on Data Collection Rules (DCRs) as the control plane, which lets you target data collection from groups of machines connected to the same or different workspaces, as compared to the “all or nothing” approach of the legacy agents.
    • Using DCRs you can define which data to ingest and which data to filter out to reduce workspace clutter and save on costs.
    • Support for additional destinations, like Azure Storage accounts, will be available in the future, which will enable you to optimize for longer storage periods at cheaper costs.
  • Simpler management of data collection, including ease of troubleshooting
    • Easy multihoming on Windows and Linux, across regions and tenants.
    • Centralized, ‘in the cloud’ agent configuration makes every action across the data collection lifecycle, simpler and scalable, from onboarding to deployment to updates and all related changes over time.
    • Greater transparency and control over services and related updates, such as Sentinel, Defender for Cloud, and VM Insights.
  • A single agent that consolidates all features necessary to address all telemetry data collection needs across servers and client devices (running Windows 10, 11). The Azure Monitor agent currently completely replaces the Log Analytics agent and will soon replace the diagnostic extension.

 

Okay I'm convinced! When should I migrate?

The short answer is - Start TODAY!

Besides serving as a means for you to collect data from your resources, other Azure services and solutions also use the agent as the to upload the data they require to Azure Monitor to then power their service/solution. If you've been waiting for Azure services and solutions to be available on AMA, your wait ends now. The following services are now in the general availability or public preview phase. which means you no longer need the legacy agent for these and can begin migrating to AMA:

Start testing and rolling out these features with AMA today, so that you're ready to deploy to production as soon as they hit general availability by end of this year. Testing earlier gives you the advantage of identifying potential blockers that may be specific to your organization's needs and that we'd love to eliminate for you sooner rather than later. Read our detailed migration guidance here.

 

So how easy is it to migrate?

There are numerous benefits to using AMA, but we understand that it could be a tedious process to migrate something as fundamental as the agent running on every machine. Downstream dependencies like dashboards and alerts must be validated as part of the migration to ensure there is no impact to business. We understand your pain and have created some tools to make the migration journey (depicted below) easier:

 

mma-to-ama-migration-steps.png

 

 

  • Migration Helper: Discover what to migrate and track the migration across all resources; includes a central view into DCRs, agent heartbeats, Arc Connected Machine agent status and more.
    • Use this workbook to track the status of migration as you progress across resources in your organization
    • Start your journey by discovering the scope of migration, i.e., what services and solutions you use today that depend on the legacy agent.
    • Next, review the list of virtual machines, scale sets, and on-premises servers that are running the legacy agent.
    • As you deploy Azure Monitor Agent and create/associate data collection rules, you will see heartbeat signals to indicate whether the deployment completed successfully, or if there are issues you need to fix.
    • Overall, use this workbook to track the status of migration as you progress across resources in your organization.
  •  DCR Generator: Convert legacy agent configuration into DCRs, ready to deploy! 
    • Use the script to parse legacy agent configuration stored within Log Analytics workspaces, along with other workspace-specific settings.
    • The script generates corresponding data collection rules for AMA - specifying what to collect and where to collect data from - either as ready-to-deploy ARM templates or JSON files that you can review and modify (recommended) and then deploy however you want. 
    • Support for parsing and creating rules for solutions and services is coming soon! Note: Solutions/services have predefined DCR definitions that get created and deployed on your behalf when you onboard, so you aren't required to create these yourself. 

...and we're not stopping here, there's more coming! As always, tell us what you need to make it simpler for you, and let us help you!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.