public/grafana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

resolves merge conflicts (#57840)

Browse Source
This commit is contained in:
Christopher Moyer
2022-10-28 13:57:12 -05:00
committed by GitHub
parent 85f1aab363
commit 82430165ee
29 changed files with 137 additions and 147 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sources/enterprise/query-caching.md
-97
View File
@@ -1,97 +0,0 @@
---
aliases:
- /docs/grafana/latest/enterprise/query-caching/
description: Grafana Enterprise data source query caching
keywords:
- grafana
- plugins
- query
- caching
title: Query caching
weight: 300
---
# Query caching
When query caching is enabled, Grafana temporarily stores the results of data source queries. When you or another user submit the exact same query again, the results will come back from the cache instead of from the data source (like Splunk or ServiceNow) itself.
Query caching works for all backend data sources. You can enable the cache globally and configure the cache duration (also called Time to Live, or TTL).
> **Note:** Available in [Grafana Enterprise]({{< relref "../enterprise/" >}}) and [Grafana Cloud Pro and Advanced]({{< ref "/grafana-cloud" >}}).
The following cache backends are available: in-memory, Redis, and Memcached.
> **Note:** Storing cached queries in-memory can increase Grafana's memory footprint. In production environments, a Redis or Memcached backend is highly recommended.
When a panel queries a cached data source, the time until this query fetches fresh data is determined by the panel's **interval.** This means that wider panels and dashboards with shorter time ranges fetch new data more frequently than narrower panels and dashboards with longer time ranges.
Interval is visible in a panel's [query options]({{< relref "../panels-visualizations/query-transform-data/" >}}). It is calculated like this: `(max data points) / time range`. Max data points are calculated based on the width of the panel. For example, a full-width panel on a dashboard with a time range of `last 7 days` will retrieve fresh data every 10 minutes. In this example, cached data for this panel will be served for up to 10 minutes before Grafana queries the data source again and returns new data.
You can make a panel retrieve fresh data more frequently by increasing the **Max data points** setting in the panel's [query options]({{< relref "../panels-visualizations/query-transform-data/" >}}).
## Query caching benefits
- Faster dashboard load times, especially for popular dashboards.
- Reduced API costs.
- Reduced likelihood that APIs will rate-limit or throttle requests.
## Data sources that work with query caching
Query caching works for all [Enterprise data sources](https://grafana.com/grafana/plugins/?type=datasource&enterprise=1) as well as the following [built-in data sources]({{< relref "../datasources/" >}}):
- CloudWatch Metrics
- Google Cloud Monitoring
- InfluxDB
- Microsoft SQL Server
- MySQL
- Postgres
- Tempo
Some data sources, such as Elasticsearch, Prometheus, and Loki, cache queries themselves, so Grafana query caching does not improve performance.
Query caching also works for all data sources that include a backend. More specifically, caching works with data sources that extend the `DataSourceWithBackend` class in the plugins SDK.
To tell if a data source works with query caching, follow the instructions below to **Enable and Configure query caching**. If caching is enabled in Grafana but the Caching tab is not visible for the given data source, then query caching is not available for that data source.
## Enable and configure query caching
You must be an Org admin or Grafana admin to enable query caching for a data source. For more information on Grafana roles and permissions, refer to [About users and permissions]({{< relref "../administration/roles-and-permissions/" >}}).
By default, data source queries are not cached. To enable query caching for a single data source:
1. On the side menu, click Configuration > Data Sources.
1. In the data source list, click the data source that you want to turn on caching for.
1. Open the Cache tab.
1. Press the Enable button.
1. (Optional) Choose custom TTLs for the data source's queries and resources caching. If you skip this step, then Grafana uses the default TTL.
> **Note:** If query caching is enabled and the Cache tab is not visible in a data source's settings, then query caching is not available for that data source.
To configure global settings for query caching, refer to the [Query caching section of Enterprise Configuration]({{< relref "../setup-grafana/configure-grafana/enterprise-configuration/#caching" >}}).
## Disable query caching
To disable query caching for a single data source:
1. On the side menu, click Configuration > Data Sources.
1. In the data source list, click the data source that you want to turn off caching for.
1. In the Cache tab, click Disable.
To disable query caching for an entire Grafana instance, set the `enabled` flag to `false` in the [Query caching section of Enterprise Configuration]({{< relref "../setup-grafana/configure-grafana/enterprise-configuration/#caching" >}}). You will no longer see the Cache tab on any data sources, and no data source queries will be cached.
## Clear cache
If you experience performance issues or repeated queries become slower to execute, consider clearing your cache.
> **Note:** This action impacts all cache-enabled data sources. If you are using Memcached, the system clears all data from the Memcached instance.
**To clear the cache**:
1. Sign in to Grafana and click **Settings > Data Sources**.
1. Select a data source.
1. Click the **Cache** tab.
1. Click **Clear cache**.
## Sending a request without cache
If a data source query request contains an `X-Cache-Skip` header, then Grafana skips the caching middleware, and does not search the cache for a response. This can be particularly useful when debugging data source queries using cURL.
docs/sources/enterprise/recorded-queries.md
-74
View File
@@ -1,74 +0,0 @@
---
aliases:
- /docs/grafana/latest/enterprise/recorded-queries/
description: Grafana Enterprise recorded queries
keywords:
- grafana
- query
- queries
- recorded
title: Recorded queries
weight: 300
---
# Recorded queries
Recorded queries allow you to see trends over time by taking a snapshot of a data point on a set interval. This can give you insight into historic trends.
For our plugins that do not return time series, it might be useful to plot historical data. For example, you might want to query ServiceNow to see a history of request response times but it can only return current point-in-time metrics.
> **Note:** Available in [Grafana Enterprise]({{< relref "../enterprise/" >}}).
## How recorded queries work
> **Note:** An administrator must configure a Prometheus data source and associate it with a [Remote write target](#remote-write-target) before recorded queries can be used.
Recorded queries only work with backend data source plugins. Refer to [Backend data source plugin](https://grafana.com/tutorials/build-a-data-source-backend-plugin/) for more information about backend data source plugins. You can recorded three types of queries:
- single row and column - A query that returns a single row and column.
- row count - A query that returns meaningful rows to be counted.
- expression - Any expression. To learn more about creating and using expressions, see [Expressions](https://grafana.com/docs/grafana/latest/panels/expressions/).
After a recorded query is created or enabled, it immediately creates a snapshot and continues to create snapshots at the set interval. The recorded query stops taking snapshots when it is disabled, deleted, or when Grafana is not running. Data points are gathered in the backend by running the recorded query and forwarding each result to a remote-write enabled Prometheus instance.
## Using a recorded query
To use a recorded query, create one and add it to a dashboard. After that, it can be managed in **Preferences** from the **Recorded queries** tab.
### Create a recorded query
1. Find/create a query you want to record on a dashboard in an edit panel. The query must only return one row and column. If it returns more, you can still record the number of results returned using the “count” option.
- The query's data source must be a backend data source.
- Expressions can be used to aggregate data from a time series query. Refer to [Expressions](https://grafana.com/docs/grafana/latest/panels/expressions/) to learn more about creating and using expressions.
1. Click the record query button located in the top right of the query editor.
1. Enter recorded query information. All fields are required unless otherwise indicated.
- Name - Name of the recorded query.
- Description - (optional) Describe the recorded query as you want it to appear in the recorded query list.
- Interval - The interval on which the snapshot will be taken. The interval starts when you create the recorded query and will stop if you pause or delete the recorded query. Refer to [Managing recorded queries](#manage-recorded-queries) for more information on pausing and deleting recorded queries.
- Range - The relative time range of the query. If you select a range of `30m` and an interval of `1h` the query will take a snapshot every hour of the past 30 minutes.
- Count query results - If you want to count the rows returned from your query toggle this option on. If this option is off, your query must return one row with one value.
1. Test your recorded query by clicking the test recorded query button.
1. Click `Start recording query` to start recording your query.
### Add a recorded query
You can add existing recorded queries to panels in a dashboard. For each recorded query that you add, a Prometheus query is created: `generated_recorded_query_name{id="generated_id", name="recorded query name"}`. The created query from Prometheus returns all the recorded query’s gathered snapshots.
1. Navigate to a panel in a dashboard where you wish to add a recorded query.
1. Click the `+ Recorded query` button located below the queries.
1. If you want to filter recorded queries by data source, select a data source from the filter by data source drop down menu.
1. Click the `Add` button on your recorded query to add it to the panel.
After adding your recorded query to the panel, the panel data source will become `-- Mixed --`. Your recorded query is represented by a `Prometheus` query with a name label matching your recorded query name. Refer to [Prometheus](https://grafana.com/docs/grafana/latest/datasources/prometheus/) to learn more about the `Prometheus` data source.
If after adding a recorded query, a query with a `-- Mixed --` data source instead of `Prometheus` data source appears, this could mean that a Prometheus remote write target was not set up for recorded queries. Refer to [Remote write target](#remote-write-target) to set up a remote write point.
### Manage recorded queries
Recorded queries can be paused/activated and deleted from the Recorded queries tab in Preferences. Deleting a recorded query will remove it from Grafana, but the information that was gathered in Prometheus will still be there. Pausing a recorded query will no longer gather new data points until it is resumed.
### Remote write target
The remote write target is the Prometheus data source that recorded query data points are written to. You will need a Prometheus with remote write enabled and you will need to create a data source for this Prometheus.
The remote write target can be edited by clicking `Edit Remote Write Target` in the upper right on the Recorded Queries tab in Preferences. Select the Prometheus data source that has remote write enabled and enter the remote write path.
docs/sources/enterprise/settings-updates.md
-96
View File
@@ -1,96 +0,0 @@
---
aliases:
- /docs/grafana/latest/enterprise/settings-updates/
description: Settings updates at runtime
keywords:
- grafana
- runtime
- settings
title: Settings updates at runtime
weight: 500
---
# Settings updates at runtime
> **Note:** Available in Grafana Enterprise version 8.0 and later.
By updating settings at runtime, you can update Grafana settings without needing to restart the Grafana server.
Updates that happen at runtime are stored in the database and override
[settings from the other sources]({{< relref "../setup-grafana/configure-grafana/" >}})
(arguments, environment variables, settings file, etc). Therefore, every time a specific setting key is removed at runtime,
the value used for that key is the inherited one from the other sources in the reverse order of precedence
(`arguments > environment variables > settings file`), being the application default the value used when no one provided
through one of these, at least.
Currently, **it only supports updates on the `auth.saml` section.**
## Update settings via the API
You can update settings through the [Admin API]({{< relref "../developers/http_api/admin/#update-settings" >}}).
When you submit a settings update via API, Grafana verifies if the given settings updates are allowed and valid. If they are, then Grafana stores the settings in the database and reloads
Grafana services with no need to restart the instance.
So, the payload of a `PUT` request to the update settings endpoint (`/api/admin/settings`)
should contain (either one or both):
- An `updates` map with a key, and a value per section you want to set.
- A `removals` list with keys per section you want to unset.
For example, if you provide the following `updates`:
```json
{
"updates": {
"auth.saml": {
"enabled": "true",
"single_logout": "false"
}
}
}
```
it would enable SAML and disable single logouts. And, if you provide the following `removals`:
```json
{
"auth.saml": ["allow_idp_initiated"]
}
```
it would remove the key/value setting identified by `allow_idp_initiated` within the `auth.saml`.
So, the SAML service would be reloaded and that value would be inherited for either (settings `.ini` file,
environment variable, command line arguments or any other accepted mechanism to provide configuration).
Therefore, the complete HTTP payload would looks like:
```json
{
"updates": {
"auth.saml": {
"enabled": "true",
"single_logout": "false"
}
},
"removals": {
"auth.saml": ["allow_idp_initiated"]
}
}
```
In case any of these settings cannot be overridden nor valid, it would return an error and these settings
won't be persisted into the database.
## Background job (high availability set-ups)
Grafana Enterprise has a built-in scheduled background job that looks into the database every minute for
settings updates. If there are updates, it reloads the Grafana services affected by the detected changes.
The background job synchronizes settings between instances in high availability set-ups. So, after you perform some changes through the
HTTP API, then the other instances are synchronized through the database and the background job.
## Control access with role-based access control
If you have [role-based access control]({{< relref "../administration/roles-and-permissions/access-control/" >}}) enabled, you can control who can read or update settings.
Refer to the [Admin API]({{< relref "../developers/http_api/admin/#update-settings" >}}) for more information.