Background

At Enabler, we are big fans of Uptime Kuma for uptime monitoring. However, it has two main drawbacks: it doesn't scale well with numerous probes, and it's not suitable for a GitOps scenario due to its heavy usage of GUI for configuring probes

Our goal is to add probes automatically as part of the GitOps setup when deploying new applications that need monitoring. Recently, we tested Application Insights Availability for this purpose.

Deploying Application Insights Infrastructure

To start, you need to deploy the Application Insights infrastructure if you don't already have one. This requires the Azure Insights provider for Crossplane. We assume you're already using Crossplane and are familiar with its operation.

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-azure-insights
spec:
  package: xpkg.upbound.io/upbound/provider-azure-insights:v1.5.0

When the provider is deployed you can provision an Application Insight instance, a Log Analytics Workspace and a resource group:

apiVersion: azure.upbound.io/v1beta1
kind: ResourceGroup
metadata:
  labels:
    enabler.no/system: app-insights
  name: app-insights
spec:
  forProvider:
    location: West Europe
---
apiVersion: operationalinsights.azure.upbound.io/v1beta1
kind: Workspace
metadata:
  labels:
    enabler.no/system: app-insights
  name: app-insight
spec:
  forProvider:
    location: West Europe
    resourceGroupNameSelector:
      matchLabels:
        enabler.no/system: app-insights
    retentionInDays: 30
    sku: PerGB2018
---
apiVersion: insights.azure.upbound.io/v1beta1
kind: ApplicationInsights
metadata:
  labels:
    enabler.no/system: app-insights
  name: app-insights
spec:
  forProvider:
    applicationType: other
    location: West Europe
    workspaceIdSelector:
      matchLabels:
         enabler.no/system: app-insight
    resourceGroupNameSelector:
      matchLabels:
        enabler.no/system: app-insights

Ensuring Resource Provider Registration

If Application Insights isn't provisioned, it's likely because the Azure Resource Providers "microsoft.insights" and "Microsoft.OperationalInsights" aren't registered. You can check this under your subscription in Azure → Settings → Resource providers.

More about the deprecated Application Insights here: link

Once everything is provisioned, you can start adding probes.

apiVersion: insights.azure.upbound.io/v1beta1
kind: ApplicationInsightsStandardWebTest
metadata:
  labels:
	   enabler.no/system: app-insights
  name: exampleappinsightwebtest
spec:
  forProvider:
    applicationInsightsIdSelector:
      matchLabels:
        enabler.no/system: app-insights
    geoLocations:
      - us-va-ash-azr # Test from East US
    location: West Europe
    request:
      - url: http://www.enabler.no
    resourceGroupNameSelector:
      matchLabels:
        enabler.no/system: app-insights

This will add a probe checking that enabler.no is up every 300 seconds (the default interval).

To make effective use of the probes, you should add alerts to appropriate channels. We prefer using collaboration tools like Slack or Teams to collect alerts and collaborate on them as a team.

Final thoughts

The GitOps experience with this setup is excellent and precisely what we're aiming for. However, one significant drawback is the pricing. As the number of probes increases, the cost can become substantial compared to alternative solutions.

The example above is for 50 endpoints checked every 5 minutes from one geolocation. If you want to check more endpoints, more frequently, and from multiple geolocations simultaneously, it can quickly become expensive.

For a smaller number of probes, or if you already use Azure and don't want to introduce new third-party services, Azure Monitor Availability can be a good choice. However, we are still looking for other solutions suitable for a GitOps situation with a larger number of probes.