Azure Service Discovery resource group filter

[David-N-Perkins]

Added an optional resource_group configuration for Azure service discovery, which limits the discovery when specified. See issue 10253.

Also updated a deprecated azure auth call.

[David-N-Perkins]

@roidelapluie I implemented this using a new config value. Let me know if there's another preferred method to get the resource group.

I also don't have access to an Azure account, so not sure how to test these changes. There's not many existing unit tests.

[roidelapluie]

Thanks for this! It seems like we would need azure users to test this.

[jrauschenbusch]

@David-N-Perkins Thanks for implementing this. A new optional config value seems to be the best solution for this topic. It's backwards compatible and provide a way to reduce the amount of ARM calls massively if it's a subscription containing a lot of VMs. I'll try out you code changes and give you feedback. But maybe there are other Azure users who can also give feedback. Especially the MSI auth change will be hard to test locally.

[jrauschenbusch]

@David-N-Perkins Sorry for the late response. I've now tested your branch for ~24h within an AKS cluster.

TL;DR: LGTM! @roidelapluie Please merge 😄

• MSI authentication works (tested with azure pod identity in AKS)
• Applying the resource groups parameter also works like a charm (ARM request report comparison (#calls before/#calls after) using Export-AzLogAnalyticRequestRateByInterval)
• Backwards compatibility is given by omitting the resource_group config parameter (also tested via the report approach mentioned above)

I had previously accidentally built a container image from the main branch and was wondering why the parameter shouldn't exist in azure.plain (see log output below). Then I realized it was the wrong branch I was building the image on. But it was a good test that the parameter is accepted as soon as i was working on the correct branch.

Before using the right branch there was the following log output:

 ts=2022-03-23T09:59:23.929Z caller=main.go:870 level=error msg="Error reloading config" err="couldn't load configuration (--config.file=\"/etc/config/prometheus.yml\"): parsing YAML file /etc/config/prometheus.yml: yaml: unmarshal errors:\n  line XXX: field resource_group not found in type azure.plain" 

After using the right branch everything worked as expected.

Good job! 🚀

[roidelapluie]

But is this a beaking change for users? Do they need to change their credentials ?

[jrauschenbusch]

No, it's not a breaking change. I've just tested if the MSI authentication still works with the changes made in this PR. Service Principal and OAuth authentication were not touched and should work as before:

prometheus/discovery/azure/azure.go

Line 196 in 10b6d00

oauthConfig, err := adal.NewOAuthConfig(activeDirectoryEndpoint, cfg.TenantID)

prometheus/discovery/azure/azure.go

Line 201 in 10b6d00

spt, err = adal.NewServicePrincipalToken(*oauthConfig, cfg.ClientID, string(cfg.ClientSecret), resourceManagerEndpoint)

Just the MSI authentication was replaced, as the current methods are deprecated:

https://github.com/Azure/go-autorest/blob/b3899c1057425994796c92293e931f334af63b4e/autorest/adal/token.go#L738

Furthermore one can omit the resource_group parameter and then the behavior is the same as before. Hence also not a breaking change.

[roidelapluie]

We should check the error here to avoid deferring a nil pointer

[David-N-Perkins]

Fixed.

[roidelapluie]

Same

[David-N-Perkins]

Fixed.

[roidelapluie]

thanks. I have spin up azure vm's to test this, it indeed works. Added a comment.

[roidelapluie]

Thanks!