Azure

Telemetry Provided

• Infrastructure Entities - Complete infrastructure topology including compute, storage, and networking resources
• Metrics - Performance metrics from applications and infrastructure
• Service Discovery - Automatic discovery of services, workloads, and infrastructure components
• Signals - Automatic Signal detection from metrics, traces, and external monitoring systems

Overview

Causely provides comprehensive native integration with Microsoft Azure to help you identify and resolve infrastructure and managed service reliability issues before they impact your users.

Rather than stopping at surface-level Signals, Causely analyzes them in real time from your Azure environment to infer the underlying Diagnosis behind performance degradation and risk across your cloud services.

By setting up the Azure integration, you will be able to:

Identify causes for reliability issues originating from your Azure infrastructure and services, including:

• Service Congestion and Service Malfunction
• Application Load Balancer Misconfiguration issues
• Authentication and Network Policy misconfigurations
• Memory Pressure and CPU Congested issues
• Disk Pressure and I/O congestion

Observe Azure resources as first-class entities in the Causely Topology Graph, including their relationships to Kubernetes workloads, cloud services, and downstream dependencies

Monitor performance and health metrics from Azure-native sources with automatic correlation to service impact and causal diagnoses

Supported Azure Services

Causely integrates with the following Azure services to provide comprehensive observability and causal inference:

• Azure Cache for Redis
• Azure Cache for Redis Enterprise
• Azure Database for MySQL Flexible Server
• Azure Database for PostgreSQL Flexible Server
• Azure Managed Disks
• Azure Key Vault
• Azure Event Hubs
• Azure Load Balancer
• Azure Storage (Blob, Queue, File, Table)
• Azure Virtual Machines (VMs)
• Azure Virtual Machine Scale Sets (VMSS)

Step 1: Create a Service Principal (SPN) and Grant Permissions

Causely authenticates to Azure with a Service Principal (client ID and client secret) and only performs read-only calls against the Azure Resource Manager (ARM) and Azure Monitor metrics APIs. It never modifies resources, and it does not need any data-plane access (no storage keys, Key Vault secrets, database logins, or Redis access keys).

Required permissions

The Service Principal needs the following actions on each subscription you want to monitor, grouped by the scraper that uses them:

Scraper	Azure resources	Required actions
All	Subscription (connectivity check)	Microsoft.Resources/subscriptions/read
All	Azure Monitor platform metrics	Microsoft.Insights/metrics/read, Microsoft.Insights/metricDefinitions/read
azure	Managed Disks	Microsoft.Compute/disks/read
azure	Virtual Machine Scale Sets and their VM instances	Microsoft.Compute/virtualMachineScaleSets/read, Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read
azure	Load Balancers (including SNAT port usage of the AKS kubernetes load balancer)	Microsoft.Network/loadBalancers/read
azure	Storage Accounts	Microsoft.Storage/storageAccounts/read
azure	Key Vaults	Microsoft.KeyVault/vaults/read
azurePostgres	Azure Database for PostgreSQL Flexible Server	Microsoft.DBforPostgreSQL/flexibleServers/read
azureMysql	Azure Database for MySQL Flexible Server	Microsoft.DBforMySQL/flexibleServers/read
azureRedis	Azure Cache for Redis and Azure Cache for Redis Enterprise	Microsoft.Cache/redis/read, Microsoft.Cache/redisEnterprise/read
azureEventhub	Event Hubs namespaces and event hubs	Microsoft.EventHub/namespaces/read, Microsoft.EventHub/namespaces/eventhubs/read

Assign the role at the subscription scope. The scrapers list resources across the whole subscription and validate access by reading the subscription itself, so a role assigned only on individual resource groups is not sufficient.

You can grant these permissions in one of two ways.

Option 1: Built-in Reader role (simplest)

The built-in Reader role includes all of the actions above. Create the SPN and assign the role in a single command:

az ad sp create-for-rbac \
  --name causely-spn \
  --role Reader \
  --scopes /subscriptions/00000000-0000-0000-0000-000000000000

Option 2: Custom least-privilege role

If your security policy does not allow the broad Reader role, create a custom role containing only the actions Causely uses.

1. Save the following role definition as causely-reader-role.json, replacing the subscription ID in AssignableScopes (add one entry per subscription you want to monitor):

{
  "Name": "Causely Reader",
  "IsCustom": true,
  "Description": "Read-only access to the Azure resources and metrics used by Causely.",
  "Actions": [
    "Microsoft.Resources/subscriptions/read",
    "Microsoft.Insights/metrics/read",
    "Microsoft.Insights/metricDefinitions/read",
    "Microsoft.Compute/disks/read",
    "Microsoft.Compute/virtualMachineScaleSets/read",
    "Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read",
    "Microsoft.Network/loadBalancers/read",
    "Microsoft.Storage/storageAccounts/read",
    "Microsoft.KeyVault/vaults/read",
    "Microsoft.DBforPostgreSQL/flexibleServers/read",
    "Microsoft.DBforMySQL/flexibleServers/read",
    "Microsoft.Cache/redis/read",
    "Microsoft.Cache/redisEnterprise/read",
    "Microsoft.EventHub/namespaces/read",
    "Microsoft.EventHub/namespaces/eventhubs/read"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-0000-0000-0000-000000000000"
  ]
}

You can remove the actions for any services you do not plan to scrape, but keep Microsoft.Resources/subscriptions/read and the Microsoft.Insights/* actions.

2. Create the custom role:

az role definition create --role-definition @causely-reader-role.json

3. Create the SPN and assign the custom role:

az ad sp create-for-rbac \
  --name causely-spn \
  --role "Causely Reader" \
  --scopes /subscriptions/00000000-0000-0000-0000-000000000000

Using the Azure portal

You can do the same in the Azure portal: register an application under Microsoft Entra ID → App registrations, create a client secret under Certificates & secrets, and then go to Subscriptions → your subscription → Access control (IAM) → Add role assignment to assign Reader (or your Causely Reader custom role, created under Access control (IAM) → Add → Add custom role) to the application.

Note the SPN credentials

az ad sp create-for-rbac prints output similar to the following:

{
  "appId": "11111111-1111-1111-1111-111111111111",
  "displayName": "causely-spn",
  "password": "...",
  "tenant": "22222222-2222-2222-2222-222222222222"
}

These map to the values Causely needs in Step 2:

az output	Causely Secret key
tenant	tenantId
appId	clientId
password	clientSecret
ID of the subscription in --scopes	subscriptionId

The client secret expires (after one year by default). Rotate it with az ad sp credential reset --id <appId> and update the Kubernetes Secret before it expires, otherwise scraping stops.

Monitoring multiple subscriptions

Each Kubernetes Secret holds credentials for a single subscription. To monitor several subscriptions with the same SPN, assign the role on each one (for a custom role, also list each subscription in AssignableScopes):

az role assignment create \
  --assignee <appId> \
  --role Reader \
  --scope /subscriptions/<other-subscription-id>

Then create one Kubernetes Secret per subscription in Step 2, each with its own subscriptionId.

Verify the role assignment

az role assignment list --assignee <appId> --all --output table

Step 2: Create a Kubernetes Secret for the SPN Credentials

After creating the SPN, save its credentials in a Kubernetes Secret. Replace the placeholder values with the SPN's tenantId, clientId, clientSecret, and subscriptionId.

kubectl --namespace causely create secret generic spn-credentials \
  --from-literal=tenantId="..." \
  --from-literal=clientId="..." \
  --from-literal=clientSecret="..." \
  --from-literal=subscriptionId="..."

Step 3: Update Causely Configuration

Once the Secret is created, update the Causely configuration to enable scraping for the new subscription. Below is an example configuration:

scrapers:
  azure: # Scrape VMs & Disks
    enabled: true
    subscriptions:
      - secretName: spn-credentials
        namespace: causely

  azurePostgres: # Scrape Postgresql Databases
    enabled: true
    subscriptions:
      - secretName: spn-credentials
        namespace: causely

  azureMysql: # Scrape Mysql Databases
    enabled: true
    subscriptions:
      - secretName: spn-credentials
        namespace: causely

  azureRedis: # Scrape Redis
    enabled: true
    subscriptions:
      - secretName: spn-credentials
        namespace: causely

  azureEventhub: # Scrape EventHub
    enabled: true
    subscriptions:
      - secretName: spn-credentials
        namespace: causely

Alternative: Enable Credentials Autodiscovery

Causely also supports credentials autodiscovery. This feature allows you to add new scraping targets without updating the Causely configuration. Simply label the Kubernetes Secret to enable autodiscovery for the corresponding scraper.

Example: Labeling Secrets for Autodiscovery

# Azure VMs & Disks
kubectl --namespace causely label secret spn-credentials "causely.ai/scraper=Azure"

# Azure Postgresql
kubectl --namespace causely label secret spn-credentials "causely.ai/scraper=AzurePostgres"

# Azure MySQL
kubectl --namespace causely label secret spn-credentials "causely.ai/scraper=AzureMysql"

# Azure Redis
kubectl --namespace causely label secret spn-credentials "causely.ai/scraper=AzureRedis"

# Azure EventHub
kubectl --namespace causely label secret spn-credentials "causely.ai/scraper=AzureEventHub"

With these steps, you can seamlessly integrate Causely with the Azure API and configure it to monitor your desired resources.