You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: restructure ADX page as connector capability, remove toast-dismiss
- Reframe adx-cluster-grouping as Azure Data Explorer connector capability
- Remove wizard step-by-step (tutorial covers it), keep cluster groups and health checks
- Delete toast-dismiss article (UI polish, not a capability)
Copy file name to clipboardExpand all lines: articles/sre-agent/adx-cluster-grouping.md
+28-94Lines changed: 28 additions & 94 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,110 +1,60 @@
1
1
---
2
-
title: ADX cluster grouping in Azure SRE Agent
3
-
description: Connect multiple Azure Data Explorer clusters through a single connector using identity-based groups instead of one connector percluster.
2
+
title: Azure Data Explorer connector in Azure SRE Agent
3
+
description: Connect your agent to Azure Data Explorer (Kusto) clusters to query logs and telemetry, with support for multiple clusters, per-cluster health checks, and identity-based grouping.
#customer intent: As an SRE, I want to group multiple ADX clusters under a single connector so that I can manage telemetry connections without connector sprawl.
#customer intent: As an SRE, I want to connect my agent to Azure Data Explorer clusters so that it can query logs and telemetry for incident diagnosis and health checks.
12
12
---
13
13
14
-
# ADX cluster grouping in Azure SRE Agent
14
+
# Azure Data Explorer connector in Azure SRE Agent
15
15
16
16
> [!TIP]
17
-
> -**One connector per identity group** - Connect multiple ADX clusters with a single connector instead of creating one per cluster.
18
-
> -**Per-cluster health status** - See which clusters are healthy and which need attention, individually.
19
-
> -**Group management** - Organize clusters by identity, add or remove clusters without recreating connectors.
20
-
> -**Parallel connection testing** - All clusters in a group are tested simultaneously during setup.
17
+
> -**Connect to ADX clusters** - Give your agent access to logs and telemetry stored in Azure Data Explorer.
18
+
> -**Multiple clusters in one connector** - Group cluster URIs by managed identity instead of creating separate connectors.
19
+
> -**Per-cluster health checks** - See which clusters are healthy and which need attention, individually.
20
+
> -**Test before you save** - The wizard tests connectivity to each cluster before creating the connector.
21
21
22
-
## The problem: connector sprawl
22
+
## Why connect to Azure Data Explorer?
23
23
24
-
Teams with telemetry spread across multiple Azure Data Explorer clusters—by region, by service, or by team—end up creating a separate connector for each cluster. A team with eight regional clusters needs eight connectors, all configured with the same managed identity, all appearing as separate rows in the Connectors list.
24
+
Azure Data Explorer (Kusto) is where teams store operational telemetry—application logs, infrastructure metrics, deployment traces, and service health signals. Connecting your agent to ADX lets it query this data directly when diagnosing incidents, running health checks, or generating reports.
25
25
26
-
This creates three problems:
26
+
With the ADX connector, your agent can:
27
27
28
-
1.**Setup overhead** - Each cluster means walking through the full connector wizard again with the same identity configuration.
29
-
1.**No logical grouping** - The Connectors list shows eight flat rows with no way to see that they belong together.
30
-
1.**Scattered health status** - If one cluster in a logical group has a connectivity issue, you scan all eight rows to find it.
28
+
- Query logs across multiple clusters and databases.
29
+
- Correlate telemetry from different regions or services during an incident.
30
+
- Run scheduled health checks against your telemetry data.
31
+
- Power [Kusto tools](kusto-tools.md) with deterministic, parameterized queries.
31
32
32
-
## How cluster grouping works
33
+
## How the ADX connector works
33
34
34
-
The ADX connector wizard lets you create **one connector per managed identity group**with multiple cluster URIs. Instead of creating separate connectors, you add all your cluster URIs to a single connector and organize them into groups.
35
+
The ADX connector supports **multiple clusters in a single connector**through cluster groups. Each group shares a managed identity, so you don't need to create separate connectors for every cluster.
35
36
36
37
:::image type="content" source="media/adx-cluster-grouping/step-03-add-clusters-form.png" alt-text="Screenshot showing the Add clusters step with group name, managed identity dropdown, and cluster URI fields.":::
37
38
38
-
The four-step wizard guides you through:
39
+
### Cluster groups
39
40
40
-
1.**Choose a connector** - Select Azure Data Explorer from the Telemetry tab.
41
-
1.**Set up connector** - Enter a name and select the managed identity.
42
-
1.**Add clusters** - Define cluster groups with URIs and optional per-group identity overrides.
43
-
1.**Review + test connection** - Test all clusters in parallel and see per-cluster results.
41
+
A cluster group is a collection of ADX cluster URIs that share the same managed identity. You can have multiple groups within one connector—each with its own identity—to handle clusters across different tenants or permission boundaries.
44
42
45
-
Each cluster group has:
43
+
For example, if your production clusters use one managed identity and your staging clusters use another, you create two groups within the same connector. The "(inherit)" option on each group uses the connector-level identity by default; override it per group when needed.
46
44
47
-
| Field | Description |
48
-
|-------|-------------|
49
-
|**Group name**| A label for this group (default: "ClusterGroup"). |
50
-
|**Managed identity**| Defaults to "(inherit)" from the connector-level identity. Override with a specific identity per group. |
51
-
|**Cluster URIs**| One or more URIs in format `https://<CLUSTER>.<REGION>.kusto.windows.net/<DATABASE>`. New rows appear automatically as you fill existing ones. |
52
-
53
-
Select **+ Create new group** to add additional groups with different identity assignments.
54
-
55
-
> [!TIP]
56
-
> Each cluster URI must include the database name in the path—for example, `https://mycluster.westus.kusto.windows.net/mydb`. A URI without a database path is rejected during validation.
57
-
58
-
### Per-cluster connection testing
45
+
:::image type="content" source="media/adx-cluster-grouping/step-03-add-clusters-empty.png" alt-text="Screenshot showing the Add clusters step with one cluster URI filled and an auto-added empty row.":::
59
46
60
-
When you select **Test connection** on the review step, the wizard runs a lightweight query against each cluster in parallel:
47
+
### Per-cluster health checks
61
48
62
-
| Icon | Meaning |
63
-
|------|---------|
64
-
| Green checkmark | Cluster connected and responding |
The connector tests each cluster individually—both during setup and on an ongoing basis. If some clusters become unreachable after saving, the connector status calls out the failing clusters by name (for example, *"2 cluster(s) failed: cluster1, cluster2"*) so you know exactly which cluster needs attention.
67
50
68
51
:::image type="content" source="media/adx-cluster-grouping/step-04-review-before-test.png" alt-text="Screenshot showing the Review and test connection step with connector summary and Test connection button.":::
1. Select **Add connector**—saves the connector (only appears after testing completes).
74
-
75
-
### Health monitoring after save
76
-
77
-
Health checks continue to report per-cluster status after the connector is saved. If some clusters become unreachable, the connector status calls out the failing clusters by name—for example, *"2 cluster(s) failed: cluster1, cluster2"*—no need to check individual connector rows.
78
-
79
-
The connector appears in your Connectors list under the **Telemetry** category.
80
-
81
-
## What makes this different
82
-
83
-
**Unlike one-connector-per-cluster**, cluster grouping reflects how teams actually organize their telemetry. Clusters that share an identity belong together—the connector model now matches that reality.
84
-
85
-
**Unlike manual tracking**, the per-cluster health check surfaces problems at the individual cluster level. When one cluster in a group of eight has a permission issue, you see exactly which one failed—not a generic "connector unhealthy" status across eight separate rows.
86
-
87
-
**Unlike recreating connectors**, you can edit an existing grouped connector to add or remove cluster URIs without starting over.
53
+
### Edit connectors
88
54
89
-
## Before and after
55
+
You can add or remove cluster URIs from an existing connector without recreating it. The edit dialog opens directly to the cluster configuration—update URIs, adjust group identities, and re-test.
90
56
91
-
|| Before | After |
92
-
|---|--------|-------|
93
-
|**Connectors for 8 clusters**| 8 separate connectors, identical identity | 1 connector with 8 cluster URIs |
94
-
|**Adding a new cluster**| Full wizard walkthrough | Edit existing connector, add one URI |
95
-
|**Finding a failing cluster**| Scan all 8 connector rows | Per-cluster status in one view |
|**Connectors list**| 8 flat rows under Telemetry | 1 row representing the whole group |
98
-
99
-
## Multiple identity groups
100
-
101
-
If your clusters use different managed identities—for example, one set of clusters in a production tenant and another in a staging tenant—use the **+ Create new group** button to add additional groups within the same connector.
102
-
103
-
Each group can override the connector-level identity with its own managed identity. The "(inherit)" option uses whatever identity you selected in step 2.
104
-
105
-
:::image type="content" source="media/adx-cluster-grouping/step-03-add-clusters-empty.png" alt-text="Screenshot showing the Add clusters step with one cluster URI filled and an auto-added empty row.":::
Your team runs services across three Azure regions, each with its own ADX cluster:
110
60
@@ -114,23 +64,7 @@ Your team runs services across three Azure regions, each with its own ADX cluste
114
64
|`https://prod-eastus.eastus.kusto.windows.net/servicetelemetry`| servicetelemetry | East US |
115
65
|`https://prod-westeu.westeurope.kusto.windows.net/servicetelemetry`| servicetelemetry | West Europe |
116
66
117
-
With cluster grouping, you create one connector named `prod-telemetry`, select your managed identity in the setup step, then add all three cluster URIs in a single group called "Production Regions." After testing confirms all three clusters connect, your agent can query telemetry from any region through a single connector.
118
-
119
-
## Edit grouped connectors
120
-
121
-
To add or remove clusters from an existing connector:
122
-
123
-
1. Select the connector's **...** menu > **Edit**.
124
-
1. The edit dialog opens with the connector name locked but cluster configuration editable.
125
-
1. Add new cluster URIs, remove existing ones, or adjust group identities.
126
-
1. Save your changes.
127
-
128
-
## Existing connectors
129
-
130
-
Connectors created before cluster grouping continue to work. They aren't migrated automatically. To consolidate, create a new grouped connector with all your cluster URIs, verify all clusters connect, and remove the old individual connectors.
131
-
132
-
> [!NOTE]
133
-
> New connectors use the grouped architecture by default.
67
+
With cluster grouping, you create one connector named `prod-telemetry`, select your managed identity, and add all three cluster URIs in a single group. After testing confirms all three clusters connect, your agent can query telemetry from any region through one connector.
0 commit comments