Azure Update Management - Part 4 - Log Analytics agents

Hello there, the goal of this serie is to describe a real world implementation of Azure Update Management. This service was designed to update any machine in your infrastructure, whether they are hosted on Azure or elsewhere, provided your OSs are technically supported.

In order for every reader to understand and find answers to their need, to I’ll try to give a comprehensive feedback from my experience, as well as sharing tips about design and architecture, automation, effectivement, troubleshooting issues, and so on!

Have a nice reading.

Plan

• Part 0 - Introduction
• Part 1 - Architecture
• Part 2 - Azure Policy
• Part 3 - Azure ARC
• Part 4 - Log Analytics agents (you’re here)
• Part 5 - Automation accounts
• Part 6 - Monitoring
• Part 7 - Security patches on Azure ARC
• Part 8 - Security patches on CentOS machines

Introduction

In the previous post, we saw how to deploy Azure ARC. Now that all our machines are ready to be onboarded on the solution, let’s take a closer look at the core architecture, begining with Log Analytics.

Log Analytics workspaces

Useful information

The Log Analytics service was designed to store logs for a defined period of time (retention). You can retrieve these logs by sending queries to the Log Analytics using a powerful language named Kusto Query Language (KQL). If you have monitoring routines, you can save queries as Saved Searches : this is important for the next part. The last thing that is useful to know in the context of this project is about billing : billing should be always configured on a Pay-As-You-Go basis when first deploying the resource (it can be changed later).

ARM template

The Log Analytics workspace looks like this in an ARM object. We have the main object which is the Log Analytics, and we have a child object which is a savedSearches. There are some properties like “feature” that are mandatory but we can ignore, I already told you about the most important ones.

{
  "type": "Microsoft.OperationalInsights/workspaces",
  "apiVersion": "2020-08-01",
  "name": "[parameters('workspaceName')]",
  "location": "westeurope",
  "properties": {
      "sku": {
          "name": "[parameters('sku')]"
      },
      "retentionInDays": "[parameters('dataRetention')]",
      "features": {
          "searchVersion": 1,
          "legacy": 0
      }
  },
  "resources": [{
      "apiVersion": "2020-08-01",
      "type": "savedSearches",
      "name": "[variables('saved_search')]",
      "dependsOn": [
          "[concat('Microsoft.OperationalInsights/workspaces/', parameters('workspaceName'))]"
      ],
      "properties": {
          "category": "UpdateManagement",
          "displayName": "[variables('saved_search')]",
          "functionAlias": null,
          "functionParameters": null,
          "query": "Heartbeat | where Computer contains 'a-string-that-cant-be-matched' | distinct Computer",
          "tags": [{
              "name": "Group",
              "value": "Computer"
          }],
          "version": 2
      }
  }]
}

Log Analytics agents

About Microsoft agents

Let’s take some time to talk about Microsoft agents, because I know this is often confusing. There is a Microsoft documentation page that will help you understand all of this. There are three main agents :

• Azure Monitoring Agent (AMA) - This is the most recent agent that was developed by Microsoft. For this reason, you’ll probably read about this agent since it is going to support most of the Azure services.
• Log Analytics Agent - This is the historic agent that will be replaced with the AMA. Altough it will reach end of support on August 2024, this is currently the agent to use to enable the Update Management service. Also, keep in mind that there is a new version of the Update Management service that works differently from what I describe in this serie, and that currently prevents to patch machines in a very flexible and dynamic way i.e. we can’t patch machines based on their tags.
• Diagnostics extension (WAD & LAD) - This last agent works with an Azure extension that will collect many information from the system and allow you to monitor them. It could be useful to use this agent rather than the others if you need to monitor only Syslog and Performance (on Linux) for instance.

Note : LAD stands for something like Linux Azure Diagnostic and WAD for Windows Azure Diagnostic.

Deployment methods

Policy

From my point of view, this is the prefered method c.f. my previous posts.

Using the Azure portal

There are multiple way to install the Log Analytics agent from the portal. I won’t get into the details of each method because this is well documented by Microsoft.

Note 1 : the Azure portal - From a VM has a side effect at the time I write this article. When clicking on the enable button, it will send a request to Azure and update the Log Analytics workspace, and remove all of its tags. I think the Javascript that builds the request in the portal is not properly coded, so I don’t use this method anymore.

Note 2 : there are other ways to deploy Log Analytics agents on VMs, but they also enable other related services that we don’t need such as VM Insights.

Extensions

Local install