How Grafana connects to Azure Monitor for one view of Azure and on-premises monitoring
If you run Grafana on your own infrastructure and also need Azure telemetry next to on-premises data, the supported route is the built-in Azure Monitor data source. Grafana's data source documentation places Azure Monitor among its core data sources in the metrics and time series category, so you do not need a third-party plugin to start. The data source covers three query surfaces that matter for this work: Azure Monitor metrics for resource-level time series, Log Analytics for logs queried with Kusto Query Language, and Azure Resource Graph for inventory-style queries across subscriptions. Each surface answers a different question, so decide early which dashboards need which one.
The first decision is how Grafana authenticates to Azure. Your choice between an app registration with a client secret or certificate and a managed identity, where Grafana runs on Azure infrastructure that supports one, shapes secret rotation, who can see credentials and how access is audited. Whichever you choose, grant the identity only the read roles needed for the subscriptions, resource groups and workspaces your dashboards use. Confirm the exact built-in role names and the authentication options your Grafana version offers in the data source settings and the Grafana data sources documentation before you write the role assignments into your plan.
Keeping both estates in one place also means keeping the Azure data source current. Grafana published CVE-2026-93294 on 13 October 2026, a medium-severity issue (CVSS 6.3) in which the Azure Monitor data source proxy could call arbitrary Azure Resource Manager APIs. Check the Grafana security advisories page against the Grafana version you run, confirm whether your build is affected, and make patching of this data source part of your normal Grafana maintenance cycle.
What you need before connecting Azure Monitor to Grafana
Connecting Azure Monitor to self-hosted Grafana depends on five things settled before any data source is configured: the Grafana build, the database behind it, the network path to Azure, the Entra ID and subscription scope, and the people who approve the identity. Confirm each one with your own environment and with the Grafana data source docs before you start the build.
Grafana version and edition
Confirm which Grafana major and minor version you run, and whether it is Grafana Enterprise or the open-source edition. Support windows differ by release, so check current version support for the Azure Monitor data source in the Grafana data source docs before you pin a version. Note the edition as well, because some identity options for signing users in depend on it. Record the exact version in your change ticket so the upgrade path can be planned later.
Production database behind Grafana
Grafana stores its configuration in SQLite by default, and the installation docs state that SQLite does not scale for production. Plan MySQL 8.0 or later, or PostgreSQL 12 or later, before adding Azure data sources, since data source definitions, dashboards and users all live there. Confirm backup and restore for this database, because recreating Azure connections and dashboards by hand is slow and error-prone.
Outbound network path to Azure
Grafana queries Azure Monitor, Log Analytics and Resource Graph over outbound HTTPS, and the Azure endpoints it calls depend on your cloud, such as public Azure or a sovereign cloud. Map the egress path from the Grafana host through any proxy or firewall, and confirm that DNS resolves the Azure endpoints from that host. Restricted or air-gapped networks need a deliberate design for this path, not a default allow rule.
Entra ID tenant and subscription access
Identify the Entra ID tenant that holds the subscriptions, management groups and Log Analytics workspaces you want to query. Confirm which subscriptions are in scope and whether any belong to a different tenant, since cross-tenant access needs its own design. Ask the Azure platform team who owns the tenant and who can grant reader roles on each subscription, resource group or workspace.
Identity choice and approval
Decide between an app registration with a client secret or certificate, or a managed identity where Grafana runs on Azure compute that supports one. Each option has different credential lifecycle, rotation and audit consequences. Name the approver for the identity, usually the Entra ID or cloud platform owner, and agree in writing who holds the secret or certificate and who reviews the role assignments.
Least-privilege role scope
Decide the narrowest read role and scope the integration needs, such as reader on specific resource groups or workspaces rather than whole subscriptions. Confirm which Azure Monitor data types your dashboards use, because metrics, Log Analytics and Resource Graph may need different assignments. Record the planned scope so the approver can review it against your access model.
App registration or managed identity: choosing how Grafana authenticates to Azure
The core choice is whether Grafana holds a credential that you create and manage, or whether the Azure platform issues a short-lived identity to the host it runs on. An Entra ID app registration is an identity you define in your tenant, and it authenticates with a client secret or a certificate that you generate, store and rotate. A managed identity is attached to an Azure resource such as a virtual machine, container app or AKS workload, and Azure supplies its tokens without a password your team stores. Grafana runs on whatever host you choose, so the right answer depends on where Grafana sits and what the Azure Monitor data source accepts in your version.
- Managed identity on Azure compute: Azure issues and rotates the token, so no long-lived secret sits in Grafana's configuration.
- App registration with a secret: You own the secret lifecycle, including expiry, renewal and removal from every host that uses it.
- App registration with a certificate: Private key material replaces a shared string, but you still manage issuance, distribution and renewal.
- Role assignment scope: Either identity needs only the Azure roles that the queries require, granted at the narrowest scope your subscriptions allow.
- Confirm first: Check which authentication methods the current Azure Monitor data source lists, because support can differ by Grafana version.
Before you choose, confirm with your Grafana version's Azure Monitor data source documentation which credential types it supports, and record the answer in your design.
When Grafana runs on Azure virtual machines, App Service, container services or AKS, a managed identity is usually the lower-maintenance option. The platform authenticates the host, so the team does not generate a client secret, copy it into a configuration file or calendar a renewal. Credential rotation becomes a platform function rather than a Grafana task. The trade-off is that the identity is tied to the Azure resource, so it does not fit Grafana hosts that live on your data center network.
- Rotation: Azure handles token issuance, and no secret appears in Grafana provisioning files.
- Secret storage: Nothing sensitive is stored in the Grafana database or YAML for this method.
- Audit: Sign-in and activity logs show the managed identity, which ties each query to a specific resource.
- Offboarding: Removing the resource or its role assignment cuts access without touching Grafana configuration.
- Limit: Hosts outside Azure cannot use a managed identity, so this option does not cover on-premises Grafana.
Confirm that your Grafana version's Azure Monitor data source offers the managed identity option for your hosting model, and test it from the exact host type you plan to run.
An app registration with a client secret works wherever Grafana can reach Entra ID, including on-premises hosts and other clouds. It is the most flexible option and the one most teams already understand, but it moves rotation and secret protection onto your team. Each secret has an expiry date, and a missed renewal stops dashboards and alerts that depend on Azure data. Every host that holds the secret becomes part of the credential's exposure.
- Rotation: Your team sets expiry, renews the secret and updates every Grafana host that uses it.
- Secret storage: Store the value in a secrets manager or the Grafana secret store your version supports, not in plain configuration files or Git.
- Audit: Sign-in logs show the application identity, so several Grafana hosts sharing one app appear as one caller unless you separate them.
- Offboarding: Disabling the app or deleting the secret revokes access for all hosts at once, which is fast but affects every consumer.
- Scope control: Use one app per environment or per Grafana instance so revocation does not break unrelated dashboards.
Ask your security team which secret lifetime and storage location they require, and confirm the data source's secret handling in the version you run.
On-premises Grafana hosts cannot use a managed identity, so the realistic options are an app registration with a client secret or with a certificate. A certificate-based app registration avoids a shared password string, since the private key stays on the host and can be protected by file permissions or a hardware or software key store. The cost is operational: you issue the certificate, track its expiry, distribute it to each host and replace it before it lapses. Many teams find that certificate management needs the same discipline as TLS certificate management, and the same tooling can help.
- Rotation: Certificates have their own validity periods, and renewal requires copying the new key pair to each host.
- Secret storage: The private key must be readable only by the Grafana service account, and backups need the same protection.
- Audit: Each host can use a separate certificate, which makes sign-in logs easier to attribute to one Grafana server.
- Offboarding: Remove the certificate from the app registration and delete the key from the host when a server is retired.
- Network path: Confirm that Grafana can reach Entra ID and Azure endpoints from the on-premises network, including any proxy rules.
Confirm with the data source documentation whether certificate authentication is supported for your Grafana version before you commit to this design.
The authentication choice shapes how easily you can answer who queried Azure, from which Grafana host, and when access must end. Shared identities hide the source of a query, while per-host identities make attribution simple but multiply the number of credentials to manage. Offboarding has two parts: retiring a Grafana host and removing a person or team from Grafana. Azure access for a retired host should be removed in the same change record, not left to expire on its own. Grafana user access and Azure identity access are separate controls, and both need a clear owner.
- Per-host identities: Each server gets its own identity or certificate, so sign-in logs point to a single Grafana node.
- Shared identities: One app for many hosts reduces credential count but makes attribution and selective revocation harder.
- Retirement steps: Remove the role assignment, the credential and the Grafana data source configuration as one documented change.
- Owner assignment: Name who approves renewals, who revokes access and who reviews sign-in logs on a set schedule.
- Log retention: Confirm how long Azure sign-in and activity logs are kept in your workspace, since audit questions can arrive long after an event.
Before approval, ask your team to write down the credential owner, the revocation procedure and the log location for each Grafana host.
How to configure the Azure Monitor data source in Grafana, step by step
This sequence takes a self-hosted Grafana instance from an Entra ID identity with narrow read access to a working, verified Azure Monitor connection, and then to a provisioned configuration that can be repeated across environments.
Confirm the Grafana instance and its security baseline
The platform owner confirms the Grafana version, the production database (MySQL or PostgreSQL rather than SQLite), and the hardening settings the security team requires before any cloud credential is stored. Grafana's current minor and patch releases matter here because the Azure Monitor data source has had security advisories. Check the Grafana security advisories page for the version you run. The step is done when the team can name the Grafana version, the database engine, and the advisory status it checked.
Prepare the Entra ID identity
An Azure administrator decides between a managed identity and an app registration with a client secret or certificate, based on where Grafana runs and who controls the host. A managed identity avoids storing a secret but only works when Grafana runs on Azure infrastructure that supports it. An app registration works from any host, but its secret or certificate becomes a credential that needs rotation and vault storage. Record the tenant ID, the client or identity ID, and the owner of the credential. The step is done when the identity exists in the right tenant and its owner is named in the change record.
Assign least-privilege reader roles
The Azure administrator assigns the identity read-only roles at the narrowest scope that covers the dashboards, such as individual resource groups rather than the whole subscription where possible. Monitoring Reader and Log Analytics Reader are the roles to confirm for metrics, logs and Resource Graph access, and the team should verify the current role names and their data actions in Azure documentation before assigning them. Avoid Contributor or Owner, because a data source only needs to read. The step is done when the Azure activity log or role assignment list shows the identity with read roles at the chosen scopes only.
Add the Azure Monitor data source in Grafana
A Grafana administrator adds the Azure Monitor data source from the connections menu and selects the authentication method that matches the identity from step two, such as managed identity, app registration with client secret, or app registration with certificate. The administrator enters the tenant ID, client ID and cloud, and stores secrets in Grafana's encrypted settings rather than in plain text. Confirm which Azure cloud and authentication options your Grafana version offers in its data source documentation. The step is done when the data source is saved and the form shows no validation errors for the chosen method.
Test the connection and confirm subscription visibility
Use the data source's Save and test action, then open the subscription, resource group and resource pickers in a query editor to check that the identity sees only the scopes it was granted. A successful test with a missing subscription means the role scope is too narrow for the dashboards planned. A failed test usually points to tenant, client or secret values, or to a missing role assignment that has not yet propagated. The step is done when the test returns a success message and the expected subscriptions appear in the picker.
Validate metrics queries
Build one Azure Monitor metrics query in Explore against a known resource, such as a virtual machine or app service whose metric values the operations team can check in the Azure portal. Compare the time series, aggregation and time range in both places. Repeat with one resource that sits outside the granted scope to confirm access is denied. The step is done when the Grafana values match the portal for the same resource and time window, and the out-of-scope resource returns no data or an error.
Validate Log Analytics and Resource Graph queries
Run a Log Analytics query against a table the team knows contains recent rows, then run a Resource Graph query that counts resources by type in the granted scope. Check the row counts against the Azure portal's Logs and Resource Graph Explorer for the same scope. Confirm that the query editor uses the workspace or subscription the team selected, not a broader default. The step is done when both query types return results that match the portal and no query reaches a workspace or scope outside the planned boundary.
Provision the configuration for repeatable setup
Export the working data source into a provisioning file so that new Grafana instances and rebuilds load the same settings at startup. Keep secrets out of the file by referencing environment variables or the secrets mechanism your platform uses, and store the file in version control with review. Grafana's provisioning documentation describes the YAML format and the further as-code options. The step is done when a clean test instance starts with the data source present, the connection test passes, and the secrets come from the environment rather than the file.
Mapping Azure subscriptions, resources and Grafana permissions
This table maps each Azure scope, from management group down to individual resource, to the Azure roles a Grafana connection would use and to the Grafana folders, data source permissions and team access that control what users see. Read each row as two separate layers: Azure decides what the Grafana identity can read, and Grafana decides what each signed-in user can open. The main takeaway is that a broad Azure grant held by the Grafana identity is visible to every Grafana user who can reach the data source, so scope the Azure side as narrowly as your dashboards allow.
| Azure scope | Azure role to confirm | Grafana control | Watch for |
|---|---|---|---|
| Management group | Reader inherited to child subscriptions (confirm role name with Microsoft Learn) | Not directly mapped in Grafana | Inheritance reaches every subscription below, so a grant here widens access for all Grafana users on the connection |
| Subscription | Monitoring Reader (confirm with Microsoft Learn) | Data source per subscription or per tenant scope, restricted by data source permissions | Metrics and logs from unrelated workloads become queryable if the identity has subscription scope |
| Resource group | Reader or Monitoring Reader scoped to the group (confirm) | Dashboard folder per application team, paired with a team that holds Query access to the matching data source | Resource groups do not isolate Log Analytics workspaces that span several groups |
| Log Analytics workspace | Log Analytics Reader (confirm role name with Microsoft Learn) | Data source entry pointing to the workspace, with Query permission granted to named teams only | Table-level or resource-context access can differ from workspace access, so test with a non-admin account |
| Individual resource | Monitoring Reader or Reader on the resource (confirm) | Panel-level queries using resource IDs, controlled by the parent data source and folder | Users with edit rights in a folder can change queries to reference resources the data source did not intend to expose |
| Resource Graph queries | Reader at the scopes the query covers (confirm) | Shared dashboards that query inventory, governed by folder access | Inventory results expose resource names and tags, so treat them as sensitive even when metrics are not |
| Grafana organization and folders | Not applicable in Azure | Folder permissions: View, Edit, Admin for teams and roles | Folder access controls dashboards, not the underlying data, so a viewer can still see data the data source returns |
| Grafana data source permissions | Not applicable in Azure | Query permission per team or role on each data source (available in Grafana Enterprise, confirm in the access control docs) | Open source editions may not offer per-data-source permissions, so confirm the edition before designing around them |
Securing the Azure Monitor data source against over-broad access
The Azure Monitor data source runs with whatever Azure identity you give it and whatever Grafana users are allowed to change. Limiting both, keeping client secrets out of view, and patching the proxy issue in CVE-2026-93294 are the controls that keep a shared Grafana from becoming a broad path into your Azure subscriptions.
Scope the Azure reader role
Grant the Grafana identity only read roles on the subscriptions, resource groups or resources its dashboards query. Metrics, Log Analytics and Resource Graph reads need different rights, so confirm which roles each query type requires in your tenant before you assign them. Avoid broad built-in roles at subscription scope for a dashboard server. Review assignments after each new dashboard set is added, because scope creep usually happens one dashboard at a time.
Restrict who can edit data sources
Anyone who can edit an Azure Monitor data source can change its tenant, client ID, subscription and sometimes its target endpoints, which affects every panel that uses it. Limit data source edit rights to a small platform group and give most viewers read-only access to dashboards. Confirm how your Grafana edition handles team and role mapping, since some group sync features are limited to Enterprise and Grafana Cloud.
Keep client secrets out of the UI
If you use an app registration, the client secret is stored in Grafana configuration or provisioning. Prefer provisioning files that read the secret from an environment variable or a file mounted from your secrets store, and check that the secret is not visible in exported dashboards or API responses. Where your platform already runs Azure Key Vault, decide whether Grafana fetches the secret at startup or your deployment tooling injects it, and document the rotation owner.
Prefer managed identity where it fits
When Grafana runs on Azure compute that supports a managed identity, it removes a long-lived client secret from the deployment. Confirm that the hosting service and your Grafana build support managed identity for the Azure Monitor data source before you design around it. For Grafana on-premises, the app registration path remains, so the secret controls above still apply.
Understand the outbound proxy exposure
CVE-2026-93294, published on 13 October 2026 with a medium rating of CVSS 6.3, describes a case where the Azure Monitor data source proxy could call arbitrary Azure Resource Manager APIs. An identity with broader rights than the dashboards need would widen the effect of that flaw. Treat the Azure identity's scope as the second control behind the patch, and review what the identity can reach before and after you upgrade.
Patch to fixed releases
Check the Grafana security advisories page for the fixed releases named in CVE-2026-93294 and confirm which of your running versions are affected. Patch releases come at least monthly, so schedule the upgrade in your normal maintenance window rather than waiting for a crisis. After patching, verify the Azure Monitor data source still returns results and review logs for unexpected Azure Resource Manager calls over the exposure period.
Common Azure Monitor connection failures in Grafana and how to fix them
This table pairs each common Azure Monitor connection failure with its likely cause and the check to run first. Read it top to bottom when a data source test fails or a panel returns no data, because the first rows cover identity problems that block everything else.
| Failure | Likely cause | Check to run |
|---|---|---|
| Authentication fails when saving the data source | Tenant ID, client ID or secret copied from the wrong app registration, or a secret that has expired | Confirm the tenant ID, client ID and secret belong to the same app registration, and check the secret's expiry date in Entra ID |
| Authentication works but queries return an access error | The identity has no Reader role, or the role was granted at a narrower or different scope than the resources being queried | Review role assignments on the subscription, resource group or workspace that holds the data, and confirm the scope matches the query |
| Log Analytics workspace does not appear in the query editor | Workspace sits in a subscription the identity cannot read, or the subscription is not selected in the data source settings | Check the subscription list in the data source configuration and confirm the identity has read access to the workspace's subscription |
| Resource Graph returns fewer resources than the portal shows | Query is limited to subscriptions the identity can see, or results are paged and the query stops before all rows return | Compare subscription scope against the portal view, then confirm the query handles pagination and filters on the expected subscriptions |
| Queries fail intermittently under heavy load | Azure Monitor throttling on large or frequent queries, often from many dashboards refreshing at once | Reduce refresh frequency, narrow time ranges, and review panel query counts before raising limits on the Grafana side |
| Data source test times out or cannot reach Azure | Outbound traffic from the Grafana host is blocked by a firewall, proxy or missing DNS resolution for Azure endpoints | Test outbound HTTPS from the Grafana server to the Azure management and login endpoints, and check proxy settings in the Grafana configuration |
| Results differ between Grafana and Azure portal queries | Different time zones, time range boundaries or aggregation intervals between the two tools | Align the time range and aggregation interval in both tools and compare the same query text on the same workspace |
Keeping Azure and on-premises monitoring in one Grafana
Putting Azure Monitor data beside on-premises Prometheus or Zabbix data in one Grafana works only if the teams agree on a few shared conventions first. Most dashboard confusion in mixed estates comes from time, labels and naming, not from the data source plugins. Before building a combined dashboard, agree on one time zone and time standard for display and storage, and confirm how each source reports timestamps, since Azure resource logs and metrics use UTC while on-premises tools often use local time. Next, agree on a label schema: a common set such as environment, region, service and owner, with the same spelling and casing in Prometheus labels, Zabbix host groups and Azure resource tags. Without that, the same workload appears as three unrelated series. Document the mapping in a single table that dashboard authors can reuse.
Decide early which system owns each alert. Grafana Alerting is useful for rules that span sources, such as an Azure database metric compared with an on-premises application error rate, and for one routing policy across the estate. A source system is usually the better owner for alerts that depend on its own state, such as Zabbix triggers on hosts it already polls, or Azure Monitor alert rules tied to platform health signals. Avoid defining the same condition in two places, because it produces duplicate pages. Grafana's high availability documentation describes running two or more active-active Grafana servers behind a load balancer on a shared MySQL or PostgreSQL database. It also notes that alerting needs additional configuration to avoid duplicate notifications, and that Grafana Live has limitations in that setup. Confirm that alert evaluation and notification delivery are tested on a multi-node build before relying on it, and read the Grafana high availability guide for the current requirements.
Questions buyers ask before connecting Grafana to Azure Monitor
What drives the cost of connecting Grafana to Azure Monitor?
The cost is driven by the number of Azure subscriptions and data sources in scope, how many dashboards and alert rules you need, and how much identity and network work sits between Grafana and your tenant. Most of the effort is one-time: registering the identity, assigning roles, building the first dashboards and testing. Recurring costs are your own team's time for role reviews, Grafana upgrades and dashboard upkeep, plus any support retainer. Ask for the quote to split one-time build from recurring support, and to list each subscription, workspace and query type it covers.
How long does a scoped Azure Monitor integration take?
The duration depends mostly on identity and role decisions, not on Grafana itself. A managed identity on a virtual machine you control is usually simpler to approve than an app registration with a client secret that must be issued, stored and rotated, and both are faster when the tenant owners agree the role model before the build starts. Duration also grows with the number of subscriptions, Log Analytics workspaces and Resource Graph queries. Ask the partner to state the duration against your written scope and to name which approvals fall on your side.
What must our internal team provide before the work starts?
Your team needs to provide access to the Azure tenant and the subscriptions in scope, a named approver for role assignments, and a decision on whether Grafana runs on infrastructure where a managed identity is available. Sample queries are equally important: a short list of the metrics, Log Analytics tables and Resource Graph queries your operators use today lets the build test real questions. Also provide the target Grafana host details, network paths to Azure endpoints, and the people who will own the dashboards after handover.
Can our own team connect Grafana to Azure Monitor without a partner?
Yes, an experienced platform team can configure the Azure Monitor data source in Grafana by following the vendor documentation. The steps that most often need care are the identity choice, least-privilege role assignment, and checking that each query type returns data in the right subscription. A partner adds value when many subscriptions, cross-tenant access, or on-premises sources need one consistent model, or when your team lacks time for testing and documentation. Consider the Grafana data sources documentation as your starting point for the Azure Monitor data source.
Does the open-source edition support SAML or SCIM for Azure users?
The open-source edition supports Entra ID sign-in through OAuth, which covers most single sign-on needs for users. According to the Grafana authentication docs, SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your organization requires SAML or automated user provisioning from Entra ID, that is a licensing decision to make before the design is final. Confirm the exact edition and feature list with Grafana Labs, since licensing terms can change, and state the chosen edition in the written scope.
How does Azure API usage affect the cost of monitoring?
Grafana does not charge for Azure Monitor queries, but Azure may bill for the API calls, metrics and log queries your dashboards and alerts generate. Each panel refresh, alert evaluation and Resource Graph query adds load, so dashboards with short refresh intervals across many resources cost more to run than a few well-scoped views. Ask the partner to show which queries run on refresh and which run on alert evaluation, and to set refresh intervals and time ranges that match what operators need. Check Azure's own pricing for the services you query, since those rates are not part of this quote.
What security risk should we review in the Azure Monitor data source?
Review the data source proxy and the permissions granted to it. Grafana published CVE-2026-93294 on 13 October 2026, rated medium with a CVSS score of 6.3, in which the Azure Monitor data source proxy could call arbitrary Azure Resource Manager APIs. Patch Grafana to a release that includes the fix, and check the Grafana security advisories for the affected versions. Because the risk is tied to what the identity can reach, a least-privilege role is also your main control: it limits damage even if a future flaw appears.
Official Grafana sources for the Azure Monitor integration
Before you configure the Azure Monitor data source, read the Grafana data sources documentation. It lists Azure Monitor as a core data source in the metrics and time series category, and it is the place to confirm which Azure Monitor query types your Grafana version supports, how the data source is named and enabled, and which settings it expects for authentication. Use it as the baseline for your build, then check each setting against the Grafana version you plan to run, since options can change between major releases. Keep a record of the exact version you tested so your runbook matches the instance in production.
Next, read the Grafana Labs security advisories page and filter for the Azure Monitor data source. Grafana published CVE-2026-93294 on 13 October 2026, a medium-severity issue (CVSS 6.3) in which the Azure Monitor data source proxy could call arbitrary Azure Resource Manager APIs. The advisory is a reason to check which fixed release you are running and whether the credentials behind the data source are scoped tightly enough to limit the impact of a flaw like this. Confirm the affected and fixed versions on the advisory itself rather than relying on a summary.
Treat these two pages as a standing check, not a one-time read. Put the data sources page and the advisories feed into your upgrade review, so that each Grafana patch or minor release triggers a check of Azure Monitor behavior and any open advisories. Ask your partner or internal team to record which version was validated against your Azure subscriptions, which roles the data source identity holds, and who reviews advisories. That record is the evidence a security or compliance reviewer will ask for when the integration is in scope.
How DeployOpen scopes and delivers a Grafana and Azure Monitor integration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Grafana and Azure Monitor integration described on this page. Engagements start from a written scope, so access model, data sources and handover expectations are agreed before any configuration begins.
How we scope
- Inventory the Azure subscriptions, Log Analytics workspaces and resource groups that Grafana should query.
- Agree the identity model, either an app registration or a managed identity, and the least-privilege roles each query path needs.
- Define which on-premises data sources sit beside Azure data in shared dashboards and alert rules.
How we build
- Deploy self-hosted Grafana in your environment and configure the Azure Monitor data source against the agreed identity.
- Build and test Metrics, Log Analytics and Resource Graph queries with the access boundaries you approved.
- Store data source and dashboard definitions as provisioning files so the setup can be reviewed and rebuilt.
How we hand over
- Document the identity configuration, role assignments, data source settings and the query patterns your teams should reuse.
- Walk your operators through verification steps, including checks that Azure queries return the expected scope.
- Record which items remain with your team, such as role approvals, subscription changes and credential rotation.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, Grafana upgrades and continuous security testing are available as retainers.
- Ask any partner to confirm how they will track Grafana security advisories, such as those published by Grafana Labs, against your deployed version.
