I already wrote a pretty informative article about using PowerShell DSC to configure Azure DevOps build servers. Here, I would like to share a solution for a more common task: onboarding your servers for monitoring with Azure Monitor. Additionally, you will see how to use the discussed approach with other monitoring solutions of your choice.
Note. I prefer the following approach for configuring mostly non-Azure servers as there are other, more convenient ways as of me, for Azure VMs (more on this later in the post).
Prerequisites
If you are using Azure services and cannot stand repetitive manual tasks, I strongly encourage you to explore the Azure Automation service. Specifically, take a look at its Azure Automation State Configuration feature, which you can think of as a managed DSC Pull Server. Microsoft already has an extensive guide for onboarding machines for management by Azure Automation State Configuration, so I see no reason to repeat it here.
DSC configuration for the Microsoft Monitoring Agent
For your DSC configuration, you need to use the xPSDesiredStateConfiguration module and, optionally, the default PSDesiredStateConfiguration module if you want to implement additional logging at the OS level. Also, if I were you, I would avoid putting any keys and secrets, such as Log Analytics Workplace ID and key, into the configuration itself. It is better to store them as encrypted variables in your Azure Automation account and reference them from your DSC configuration. So, let’s look at the following sample configuration:
As you might see, the configuration logic is pretty straightforward. Firstly, you need the installation package on the target host. You can use the xRemoteFile DSC resource, which downloads a remote file to a target local destination. Secondly, use the xPackage resource to install software from a Windows Installer or EXE package. You can use just a regular Package resource from the PSDesiredStateConfiguration module and not the ‘experimental’ one, but, to my mind, xPackage is also relatively stable and has richer functionality. Thirdly, you can double-check that the agent was installed and the corresponding service is up and running. Lastly, log the installation event into the system journal, which might be very handy for debugging and troubleshooting.
In the same way, you can implement the configuration for the Microsoft Dependency agent, which is installed separately from the Microsoft Monitoring Agent (MMA). The only difference you should pay attention to is that the Dependency agent requires MMA to be installed first, so you need to specify that dependency.
Bonus: DSC configuration for the Datadog monitoring agent
To be sure, you can use the described approach with any other monitoring solution. For example, you can install the Datadog monitoring agent the same way we did for the Microsoft Monitoring Agent:
Installing the Microsoft Monitoring Agent on Azure VMs
Basically, you can use the same approach with Azure VMs. For the sake of consistency, you can manage the configuration of your VMs exclusively with Azure Automation State Configuration and ensure the Microsoft Monitoring Agent is present on them as part of their setup. However, with Azure VMs, you might find it more convenient to install the Log Analytics agent, which is another name for the Microsoft Monitoring Agent, as a VM extension.
If you need to have MMA installed and aren’t going to configure your Azure VMs with PowerShell DSC, it might be an unnecessary overhead to do that with Azure Automation State Configuration. By deploying MMA in your ARM template for VMs, you can save time and effort.
I’m not advocating for the approach with the extension for Azure VMs; I just want you to be aware of other options. You should understand that there are many ways to accomplish the task, and you should choose a solution that best fulfills your requirements.
What is your experience with onboarding machines to Azure Monitor? Please share it in the comments!
