Grafana Enterprise features
Grafana Enterprise is a commercial edition that includes exclusive data source plugins and additional features not found in the open source version. It provides 24x7x365 support and training from the core Grafana team.
Grafana dashboards · all subjects
overview
262 notes in this subject, read out of this brain and free to use. This is page 1 of 5.
Grafana OSS capabilities
Grafana Open Source Software (OSS) enables you to query, visualize, alert on, and explore your metrics, logs, and traces wherever they are stored. It supports data source plugins for time series databases like Prometheus and CloudWatch, logging tools like Loki and Elasticsearch, NoSQL/SQL databases like Postgres, CI/CD tooling like GitHub, and many more. Grafana OSS provides tools to display data on live dashboards with graphs and visualizations.
Migration progress tracking and sorting
During migration, the migration assistant provides real-time progress tracking. You can sort resources by Name (alphabetically), Type (group and sort by resource type), and Status (group and sort by upload status: pending upload, uploaded successfully, or experienced errors). The Snapshot information updates to show total resources, errors, and total successfully migrated resources.
Folders and RBAC for resource isolation in Grafana Cloud
To achieve resource isolation in Grafana Cloud when migrating from a multi-organization setup, organize resources into folders and set up teams and permissions that correspond to your organizations. This replaces the organizations feature which is not supported in Grafana Cloud.
Multiple organizations migration strategy
Grafana Cloud does not support the organizations feature. When migrating from an instance with multiple organizations, migrate multiple organizations to a single cloud stack. The migration assistant creates snapshots based on resources within a specific organization, so you must run the migration process separately for each organization. Organization administrators can be granted the Migration Assistant:Organization resource migrator RBAC role to run the migration process for their respective organizations.
Plugin migration requirements
The migration assistant supports any plugins found in the plugins catalog that are signed or are core plugins built into Grafana. Grafana Cloud does not support unsigned plugins due to security reasons. Plugins should be upgraded before migration as migrated plugins will be configured on the Grafana Cloud instance as the latest version of that plugin. For Enterprise plugins, check whether the Grafana Cloud plan requires an Enterprise plugin add-on.
Migration snapshot reflects current resource state
When a snapshot is created by the migration assistant, it makes a copy of all selected resources and saves them in the snapshot. The snapshot reflects the current state of the resources when the snapshot is built and is stored locally on the instance, ready to be uploaded in the final stage. Resources in snapshots are limited to resources stored within an organization.
Grafana Cloud Migration Assistant supported resources
The Grafana Cloud Migration Assistant supports migration of the following resources: Dashboards, Folders, Data sources, App Plugins, Panel Plugins, Library Panels, and Grafana Alerting resources.
Resource dependencies during migration
When migrating resources, some resources require others to be migrated together. Dashboards require Library Elements, Data Sources, Plugins, and Folders. Library Elements require Folders. Data Sources require Plugins. Plugins require nothing. Folders require nothing. Alert Rules require Dashboards, Library Elements, Data Sources, Plugins, Folders, Notification Policies, Notification Templates, Contact Points, and Mute Timings. Notification Policies require Notification Templates, Contact Points, and Mute Timings. Notification Templates require nothing. Contact Points require Notification Templates. Mute Timings require nothing.
Resource permissions not migrated
The migration assistant does not migrate teams or RBAC permissions, so resources migrate with default permissions. Permissions must be reconfigured in the cloud stack after migration.
Migration token required for connecting self-managed to Grafana Cloud
To connect a self-managed Grafana instance to Grafana Cloud using the migration assistant, you must first generate a migration token on the destination cloud instance. Navigate to Home > Administration > General > Migrate to Grafana Cloud in the cloud instance and click Generate a migration token. The token must then be entered in the self-managed instance's Migrate to Grafana Cloud page.
Resource UIDs preserved during migration
During migration, resource UIDs are preserved, allowing correlation between local and cloud resources. If the same migration is performed multiple times, resources in the Grafana Cloud stack that were previously migrated are updated. The migration assistant never modifies the self-managed resources or cloud resources that didn't come from a snapshot.
Grafana Enterprise RBAC role for migration access
In Grafana Enterprise, the Organization resource migrator role can be granted to other Admins to enable them to view, build snapshots, and upload resources to Grafana Cloud. To grant this access, navigate to Home > Administration > Users and access > Users, click an Admin, in the Organizations section click Change role, and select Organization resource migrator from the role selector menu under Migration Assistant.
Minimum requirements for Grafana Cloud migration
To use the Grafana migration assistant, you need: a self-managed Grafana instance, a Grafana Cloud Stack to migrate resources to, Admin access to the Grafana Cloud Stack, Grafana server administrator access to the self-managed instance, Internet access from the self-managed instance, and if running Grafana in a highly-available setup, scale down to one replica to avoid a known bug. If your network requires external services on an allowlist, add Hosted Grafana, Hosted Alerts, AWS S3 IP address ranges, and *.grafana.net.
Migration process: snapshots and upload
The migration process has three stages: (1) Generate a migration token on the destination Grafana Cloud instance, (2) Connect the self-managed instance using that token, (3) Select resources and build a snapshot to create a copy of the resources, (4) Upload the snapshot to migrate resources to the cloud.
Data source credentials migrated securely
Data sources, including their credentials, are migrated securely and seamlessly to the Grafana Cloud instance so you do not need to re-enter all data source credentials manually.
Dashboard and folder hierarchy preserved in migration
Dashboard names and UIDs are preserved along with references to data sources during migration. Folder hierarchy is also preserved, so dashboards and other resources saved in identical folder locations maintain their structure in Grafana Cloud.
Terraform example: migrate API keys to service accounts
Old Terraform configuration for API keys: ```tf terraform { required_providers { grafana = { source = "grafana/grafana" } } } provider "grafana" { url = "http://localhost:3000" auth = "admin:admin" } resource "grafana_api_key" "foo" { name = "key_foo" role = "Viewer" } resource "grafana_api_key" "bar" { name = "key_bar" role = "Admin" seconds_to_live = 30 } ``` New Terraform configuration for service accounts: ```tf terraform { required_providers { grafana = { source = "grafana/grafana" } } } provider "grafana" { url = "http://localhost:3000" auth = "admin:admin" } resource "grafana_service_account" "sa-admin" { name = "sa-admin" role = "Admin" } resource "grafana_service_account_token" "sat-bar" { name = "sat-bar" service_account_id = grafana_service_account.sa-admin.id } resource "grafana_service_account_token" "sat-foo" { name = "sat-foo" service_account_id = grafana_service_account.sa-admin.id seconds_to_live = 30 } ```
Pin Grafana Terraform Provider to v2.19.0
To pin the Grafana Terraform Provider to v2.19.0: ```hcl terraform { required_providers { grafana = { source = "grafana/grafana" version = "2.19.0" } } } ```
HTTP API example: migrate from API keys to service account tokens
Old setup using API keys: ```sh curl -X POST -H "Content-Type: application/json" -d '{"name": "my-api-key", "role": "Viewer"}' http://admin:admin@localhost:3000/api/auth/keys # response: {"id":2,"name":"my-api-key","key":"eyJrIjoiTFRSN1RBOVc3SGhjblc0bWZodXZ3MnNDcU92Um5VZUIiLKJuIjoibXktYXBpLWtleSIsImlkIjoxfQ=="} ``` New setup using service account tokens: ```sh # create a service account curl -X POST -H "Content-Type: application/json" -d '{"name": "my-service-account", "role": "Viewer"}' http://admin:admin@localhost:3000/api/serviceaccounts # response: {"id":1,"name":"my-service-account","login":"sa-my-service-account","orgId":1,"isDisabled":false,"role":"Viewer","tokens":0,"avatarUrl":""} # create the service account token with service account id 1 curl -X POST -H "Content-Type: application/json" -d '{"name": "my-service-account-token"}' http://admin:admin@localhost:3000/api/serviceaccounts/1/tokens # response: {"id":2,"name":"my-service-account-token","key":"glsa_iNValIdinValiDinvalidinvalidinva_5b582697"} # authenticate with the SAT curl --request GET --url http://localhost:3000/api/folders --header 'Authorization: Bearer glsa_iNValIdinValiDinvalidinvalidinva_5b582697' # response: [{"id":1,"uid":"a5261a84-eebc-4733-83a9-61f4713561d1","title":"gdev dashboards"}] ```
Locate migrated API key token
To find the migrated API keys, click Administration in the left-side menu, then Users and access -> Service Accounts, select the service account, and locate the Token.
HTTP API endpoints for API key migration
To migrate API keys using the HTTP API, call the POST /api/serviceaccounts endpoint and the POST /api/serviceaccounts/<id>/tokens endpoint. This action generates a service account token. Store the ID and secret that the system returns. Pass the token in the Authorization header, prefixed with Bearer to authenticate API requests.
Terraform migration steps from API keys to service accounts
To migrate from API keys to service accounts using Terraform: 1. Generate grafana_service_account and grafana_service_account_token resources. 2. Specify the desired scopes and expiration date when creating the service account. 3. Use the token returned from grafana_service_account_token to authenticate the API requests. 4. Remove the terraform configuration for creating your grafana_api_key resources.
Migrate all API keys to service accounts via UI
To migrate all API keys to service accounts in the UI: Sign in to Grafana, point to Administration, Users and access, and click API Keys. Find the section which says Switch from API keys to service accounts. Click Migrate to service accounts now. A confirmation window will appear. Click Yes, migrate now to continue. Once migration is successful, you can choose to hide the API keys page by clicking Hide API keys page forever.
Migrate single API key to service account via UI
To migrate a single API key to a service account: Sign in to Grafana. Click Administration in the left-side menu, Users and access, and select API Keys. Find the API Key you want to migrate. Click Migrate to service account.
Terraform grafana_api_key resource removed in v3.0.0
The terraform resource grafana_api_key is removed from the Grafana Terraform Provider in v3.0.0. Before you migrate and remove the use of the resource, you should pin your terraform version to a version less-than or equal-to v2.19.0.
UI path to API Keys page
In the Grafana user interface, click Administration in the left-side menu, then Users and access, and click API Keys.
Migrated API key continues working as service account token
When you migrate an API key to a service account, a service account is created with a service account token. Your existing API key—now migrated to a service account token—will continue working as before.
API keys deprecated, replaced by service accounts
API keys are deprecated. Service accounts now replace API keys for authenticating with the HTTP APIs and interacting with Grafana.
Multiple tokens can attach to one service account
You can create multiple tokens using one service account in Terraform.
Service accounts provide more security than API keys
Compared to API keys, service accounts have limited scopes that provide more security.
Terraform example: migrate Grafana Cloud Stack API keys to service accounts
Old Terraform configuration for Grafana Cloud Stack API keys: ```tf terraform { required_providers { grafana = { source = "grafana/grafana" } } } provider "grafana" { alias = "cloud" cloud_api_key = "<API-Key>" } resource "grafana_cloud_stack" "my_stack" { provider = grafana.cloud name = "my_stack" slug = "my_stack" region_slug = "eu" } resource "grafana_cloud_stack_api_key" "management" { provider = grafana.cloud stack_slug = grafana_cloud_stack.my_stack.slug name = "management-key" role = "Admin" } ``` New Terraform configuration for Grafana Cloud Stack service accounts: ```tf terraform { required_providers { grafana = { source = "grafana/grafana" } } } provider "grafana" { alias = "cloud" cloud_api_key = "<API-Key>" } resource "grafana_cloud_stack" "my_stack" { provider = grafana.cloud name = "my_stack" slug = "my_stack" region_slug = "eu" } resource "grafana_cloud_stack_service_account" "mystack_cloud-stack_service_account" { provider = grafana.cloud stack_slug = grafana_cloud_stack.my_stack.slug name = "mystack-cloud-stack-sa" role = "Admin" } resource "grafana_cloud_stack_service_account_token" "mystack_cloud-stack_service-account_token" { provider = grafana.cloud stack_slug = grafana_cloud_stack.my_stack.slug name = "mystack-cloud-stack-sa-token" service_account_id = grafana_cloud_stack_service_account.mystack_cloud-stack_service_account.id } ```
Grafana Cloud Stack API keys vs Grafana Cloud API keys
Grafana Cloud Stack API keys (grafana_cloud_stack_api_key) are deprecated and should be migrated to service accounts. However, Grafana Cloud API keys (grafana_cloud_api_key) are not deprecated and should be used for authentication for managing your Grafana cloud.
Terraform Grafana Cloud Stack service account migration
To migrate Grafana Cloud Stack API keys to service accounts using Terraform: 1. Generate grafana_cloud_stack_service_account and grafana_cloud_stack_service_account_token resources. 2. Specify the desired scopes and expiration date when creating the service account. 3. Use the token returned from grafana_cloud_stack_service_account_token to authenticate the API requests. 4. Remove the Terraform configuration for creating your grafana_cloud_stack_api_key resources.
As-code workflows cover multiple resource types
As-code workflows in Grafana allow you to manage resources including folders and dashboards, and configurations. This includes provisioning dashboards and observability workflows through code management best practices.
Infrastructure as code in Grafana Cloud
In Grafana Cloud, you can use Infrastructure as code to declaratively create and manage dashboards via configuration files in source code. This enables you to review code, reuse it, and create better workflows. Infrastructure as code tools that can be used include Terraform, Ansible, the Grafana Operator, and Grizzly.
Observability as code definition and benefits
Observability as code lets you apply code management best practices to observability resources. By representing Grafana resources as code, you can integrate them into existing infrastructure-as-code workflows and apply standard development practices. You can write configurations in code to define dashboards in JSON or other supported formats, sync your Grafana setup to GitHub to track changes and collaborate, automate with CI/CD by integrating Grafana into development and deployment pipelines, and standardize workflows to ensure consistency across teams using repeatable codified processes.
Saved query target properties as JSON
Query targets in saved queries are defined using properties_json, a raw JSON string that contains the query shape specific to the data source. The properties_json must include refId, the query expression (such as expr for Prometheus), and a datasource object with type and uid fields. Use jsonencode() to construct the JSON string.
Saved queries availability
Saved queries are only available on Grafana Enterprise and Grafana Cloud.
Knowledge Graph stack Terraform configuration
The Knowledge Graph stack configuration in Terraform includes token provisioning, dataset configuration, and stack enablement.
Knowledge Graph Terraform management capabilities
Terraform enables you to manage Grafana Cloud Knowledge Graph resources using infrastructure as code. With Terraform, you can define, version control, and deploy Knowledge Graph configurations including stack onboarding, alert rules, suppression policies, entity models, log, trace, and profile correlations, and thresholds.
Custom model rules Terraform configuration
Custom model rules in Terraform enable you to create custom entity models and define how entities are discovered based on Prometheus queries.
Prometheus rules Terraform configuration
Prometheus rules in Terraform enable you to define custom Prometheus recording and alerting rules that are evaluated against your metrics data.
Knowledge Graph Terraform documentation topics
The Knowledge Graph Terraform documentation covers the following topics: Getting started with Terraform, Knowledge Graph stack configuration, notification alerts, suppressed assertions, custom model rules, log configurations, trace configurations, profile configurations, thresholds, and Prometheus rules.
Thresholds Terraform configuration
Thresholds in Terraform allow you to set custom thresholds for request, resource, and health assertions to monitor your services.
SystemJS removed from @grafana/runtime
SystemJS is no longer exported from @grafana/runtime in Grafana v11. Plugin developers should use standard TypeScript import syntax and npm/yarn for package installation instead.
Vector interface ArrayVector further deprecated with TypeScript errors
The Vector interface deprecated in Grafana v10 is further deprecated in v11. Using ArrayVector now generates build-time TypeScript errors, though it remains working at runtime. Plugins compiled against older versions depending on get/set calls continue to work because the Array prototype still has a modified prototype, but this will be removed in the future.
Cypress-based grafana/e2e testing tool deprecated
The Cypress-based grafana/e2e end-to-end testing tool is now deprecated. Plugin authors should migrate to the new Playwright-based @grafana/plugin-e2e package.
React Router v5 deprecated for app plugins in v11
In Grafana v11, react-router v5 is marked as deprecated. App plugins should start migrating to react-router v6.
Disable Google OAuth HD parameter validation via configuration
The HD parameter validation in Google OAuth can be turned off through the configuration toggle `validate_hd`. Users with legacy Google OAuth configuration should disable this validation if the ID Token response does not have the HD parameter.
Google OAuth HD parameter validation added in v11
Grafana v11 adds validation between the ID token HD parameter response and the list of allowed domains. If the HD parameter does not match the list of allowed domains, access to Grafana is denied. Users with legacy Google OAuth configuration using api_url may not have the HD parameter, which could break their login flow.
filterQuery method called before datasource query in v11
In Grafana v11, the call to the datasource.filterQuery method is moved to the query runner. This allows frontend-only data sources and any data source not extending DataSourceWithBackend class to implement this method. For data sources extending DataSourceWithBackend, filterQuery is now called before the data source query method. If filterQuery assumes query migration happens before it is called, migration must now happen inside filterQuery itself.
Query Hide response button changes behavior in v11
Starting in Grafana v11, the tooltip of the Disable query button in the query editor is changed to Hide response/Show response. Responses associated with hidden queries are removed by Grafana before being passed to the panel. Previously, clicking Disable query had no impact on the query result. Now responses associated with hidden queries are no longer returned to the panel.
Repeated panel view URL format changed in v11
With the introduction of the Scenes library to dashboards, the URL format for viewing individual repeated panels has changed. What used to be `&viewPanel=panel-5` is now `&viewPanel=panel-3-clone1`. Previous URLs will not work and will redirect to the dashboard view with a Panel not found error.
Input data source removed in v11
The direct input data source plugin has been removed in Grafana v11. It was in alpha for four years and is superseded by TestData, which ships with Grafana.
Custom branding public dashboard footer defaults to Grafana logo in v11
In Grafana v11, custom branding public dashboard footer behavior changes to default to the Grafana logo if no footer logo or footer text is set. There is no option to hide the public dashboard footer. This affects Cloud Advanced and Enterprise customers.
Deprecated Reporting endpoints and fields removed in v11
In Grafana v11, support for deprecated endpoints and fields in Reporting related to the old scheduling format, email, and dashboard is fully removed. Calls to deprecated endpoints and values passed to deprecated fields will fail. This affects Cloud and Enterprise customers who use the API to generate reports.
React 17 peer dependency removed
Grafana v11 removes React 17 as a peer dependency from its packages. Anyone using new versions of these packages must ensure they have upgraded to React 18.
Re-enable AngularJS support temporarily via configuration
For self-managed Grafana users and existing Grafana Cloud instances, support for AngularJS can be temporarily re-enabled through the configuration parameter `angular_support_enabled=false`. However, this configuration parameter will be removed in the next major release after Grafana v11. AngularJS-based plugins will not receive further updates.
AngularJS support turned off by default in v11
In Grafana v11, support for the deprecated AngularJS framework is turned off by default for all self-managed and Cloud instances. This prevents any data source or panel visualization relying on AngularJS from being loaded. Support will be fully removed in the next major release. A warning icon and message will display in the plugins catalog and on dashboard panels using AngularJS plugins. A warning banner appears in impacted dashboards. The detect-angular-dashboards tool can generate a list of all impacted dashboards.