Match Prometheus remote-write authentication to the installed client version

Source facts

Azure Monitor’s direct Prometheus remote-write guide sets different minimum client versions: 2.45 for user-assigned managed identity, 2.48 for Microsoft Entra application authentication, 3.5.0 for system-assigned managed identity and 3.7.0 for workload identity. Supported hosting environments also differ by method; the documented workload-identity path lists AKS and Arc-enabled Kubernetes. Microsoft recommends direct configuration when replacing its remote-write sidecar. Microsoft Learn.

Applicability

Apply this compatibility check before changing authentication on a self-managed sender. A supported identity mechanism in Azure does not establish that an older Prometheus binary or every hosting environment supports that same path.

DSE recommendation

Record the running Prometheus version and hosting environment before selecting its Azure authentication method. Compare both with the documented requirements, then plan any needed client upgrade separately from the identity change. Preserve the current working configuration and agree how the team will identify a failed cutover. Do not substitute a credential-bearing method merely to avoid investigating a client-version mismatch.

Verification

Confirm the version of the actual running sender, not only a proposed image tag or a workstation’s command output. Check that its selected authentication configuration matches the approved environment and method. During a bounded cutover, inspect sender errors and verify expected new samples at the intended workspace. Treat successful identity creation and successful metric ingestion as separate results, and retain unresolved compatibility failures before expanding the change.

Official references

Microsoft Learn: Self-managed Prometheus remote write. Source reviewed September 9, 2026.