mirror of
https://github.com/grafana/grafana.git
synced 2025-02-25 18:55:37 -06:00
Docs: manual backport (#55945)
* resolves merge conflict * resolves conflicts
This commit is contained in:
Christopher Moyer
GitHub
parent
08d12df9f3
commit
8c306dfe53
@ -319,7 +319,7 @@ Note: The JSON definition in the input field when using `Copy JSON to Clipboard`
|
||||
|
||||
### Reusable Dashboard URLs
|
||||
|
||||
If the dashboard in the JSON file contains an [UID]({{< relref "../../dashboards/json-model/" >}}), Grafana forces insert/update on that UID. This allows you to migrate dashboards between Grafana instances and provisioning Grafana from configuration without breaking the URLs given because the new dashboard URL uses the UID as identifier.
|
||||
If the dashboard in the JSON file contains an [UID]({{< relref "../../dashboards/build-dashboards/view-dashboard-json-model" >}}), Grafana forces insert/update on that UID. This allows you to migrate dashboards between Grafana instances and provisioning Grafana from configuration without breaking the URLs given because the new dashboard URL uses the UID as identifier.
|
||||
When Grafana starts, it updates/inserts all dashboards available in the configured folders. If you modify the file, then the dashboard is also updated.
|
||||
By default, Grafana deletes dashboards in the database if the file is removed. You can disable this behavior using the `disableDeletion` setting.
|
||||
|
||||
|
||||
@ -78,7 +78,7 @@ Grafana Enterprise includes the ability for you to assign discrete fixed roles t
|
||||
Assign fixed roles when the basic roles do not meet your permission requirements. For example, you might want a user with the basic viewer role to also edit dashboards. Or, you might want anyone with the editor role to also add and manage users. Fixed roles provide users more granular access to create, view, and update the following Grafana resources:
|
||||
|
||||
- [Alerting]({{< relref "../../../alerting/" >}})
|
||||
- [Annotations]({{< relref "../../../dashboards/annotations/" >}})
|
||||
- [Annotations]({{< relref "../../../dashboards/build-dashboards/annotate-visualizations" >}})
|
||||
- [API keys]({{< relref "../../api-keys/" >}})
|
||||
- [Dashboards and folders]({{< relref "../../../dashboards/" >}})
|
||||
- [Data sources]({{< relref "../../../datasources/" >}})
|
||||
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/
|
||||
description: Best practices for working with Grafana
|
||||
title: Best practices
|
||||
weight: 20
|
||||
---
|
||||
|
||||
# Best practices
|
||||
|
||||
This section provides information about best practices for intermediate Grafana administrators and users. Click on each of the links before for more information.
|
||||
|
||||
- [Best practices for creating dashboards]({{< relref "best-practices-for-creating-dashboards/" >}})
|
||||
- [Best practices for managing dashboards]({{< relref "best-practices-for-managing-dashboards/" >}})
|
||||
- [Common observability strategies]({{< relref "common-observability-strategies/" >}})
|
||||
- [Dashboard management maturity model]({{< relref "dashboard-management-maturity-levels/" >}})
|
||||
@ -1,56 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/best-practices-for-creating-dashboards/
|
||||
description: Best practices for creating dashboards in Grafana
|
||||
title: Best practices for creating dashboards
|
||||
weight: 100
|
||||
---
|
||||
|
||||
# Best practices for creating dashboards
|
||||
|
||||
This page outlines some best practices to follow when creating Grafana dashboards.
|
||||
|
||||
## Before you begin
|
||||
|
||||
Here are some principles to consider before you create a dashboard.
|
||||
|
||||
### A dashboard should tell a story or answer a question
|
||||
|
||||
What story are you trying to tell with your dashboard? Try to create a logical progression of data, such as large to small or general to specific. What is the goal for this dashboard? (Hint: If the dashboard doesn't have a goal, then ask yourself if you really need the dashboard.)
|
||||
|
||||
Keep your graphs simple and focused on answering the question that you are asking. For example, if your question is "which servers are in trouble?", then maybe you don't need to show all the server data. Just show data for the ones in trouble.
|
||||
|
||||
### Dashboards should reduce cognitive load, not add to it
|
||||
|
||||
_Cognitive load_ is basically how hard you need to think about something in order to figure it out. Make your dashboard easy to interpret. Other users and future you (when you're trying to figure out what broke at 2AM) will appreciate it.
|
||||
|
||||
Ask yourself:
|
||||
|
||||
- Can I tell what exactly each graph represents? Is it obvious, or do I have to think about it?
|
||||
- If I show this to someone else, how long will it take them to figure it out? Will they get lost?
|
||||
|
||||
### Have a monitoring strategy
|
||||
|
||||
It's easy to make new dashboards. It's harder to optimize dashboard creation and adhere to a plan, but it's worth it. This strategy should govern both your overall dashboard scheme and enforce consistency in individual dashboard design.
|
||||
|
||||
Refer to [Common observability strategies]({{< relref "common-observability-strategies/" >}}) and [Dashboard management maturity levels]({{< relref "dashboard-management-maturity-levels/" >}}) for more information.
|
||||
|
||||
### Write it down
|
||||
|
||||
Once you have a strategy or design guidelines, write them down to help maintain consistency over time. Check out this [Wikimedia runbook example](https://wikitech.wikimedia.org/wiki/Performance/Runbook/Grafana_best_practices).
|
||||
|
||||
## Best practices to follow
|
||||
|
||||
- When creating a new dashboard, make sure it has a meaningful name.
|
||||
- If you are creating a dashboard to play or experiment, then put the word `TEST` or `TMP` in the name.
|
||||
- Consider including your name or initials in the dashboard name or as a tag so that people know who owns the dashboard.
|
||||
- Remove temporary experiment dashboards when you are done with them.
|
||||
- If you create many related dashboards, think about how to cross-reference them for easy navigation. Refer to [Best practices for managing dashboards]({{< relref "best-practices-for-managing-dashboards/" >}}) for more information.
|
||||
- Grafana retrieves data from a data source. A basic understanding of [data sources]({{< relref "../datasources/" >}}) in general and your specific is important.
|
||||
- Avoid unnecessary dashboard refreshing to reduce the load on the network or backend. For example, if your data changes every hour, then you don't need to set the dashboard refresh rate to 30 seconds.
|
||||
- Use the left and right Y-axes when displaying time series with different units or ranges.
|
||||
- Add documentation to dashboards and panels.
|
||||
- To add documentation to a dashboard, add a [Text panel visualization]({{< relref "../visualizations/text-panel/" >}}) to the dashboard. Record things like the purpose of the dashboard, useful resource links, and any instructions users might need to interact with the dashboard. Check out this [Wikimedia example](https://grafana.wikimedia.org/d/000000066/resourceloader?orgId=1).
|
||||
- To add documentation to a panel, edit the panel settings and add a description. Any text you add will appear if you hover your cursor over the small `i` in the top left corner of the panel.
|
||||
- Reuse your dashboards and enforce consistency by using [templates and variables]({{< relref "../dashboards/variables" >}}).
|
||||
- Be careful with stacking graph data. The visualizations can be misleading, and hide important data. We recommend turning it off in most cases.
|
||||
@ -1,39 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/best-practices-for-managing-dashboards/
|
||||
description: Best practices for managing dashboards in Grafana
|
||||
title: Best practices for managing dashboards
|
||||
weight: 200
|
||||
---
|
||||
|
||||
# Best practices for managing dashboards
|
||||
|
||||
This page outlines some best practices to follow when managing Grafana dashboards.
|
||||
|
||||
## Before you begin
|
||||
|
||||
Here are some principles to consider before you start managing dashboards.
|
||||
|
||||
### Strategic observability
|
||||
|
||||
There are several [common observability strategies]({{< relref "common-observability-strategies/" >}}). You should research them and decide whether one of them works for you or if you want to come up with your own. Either way, have a plan, write it down, and stick to it.
|
||||
|
||||
Adapt your strategy to changing needs as necessary.
|
||||
|
||||
### Maturity level
|
||||
|
||||
What is your dashboard maturity level? Analyze your current dashboard setup and compare it to the [Dashboard management maturity model]({{< relref "dashboard-management-maturity-levels/" >}}). Understanding where you are can help you decide how to get to where you want to be.
|
||||
|
||||
## Best practices to follow
|
||||
|
||||
- Avoid dashboard sprawl, meaning the uncontrolled growth of dashboards. Dashboard sprawl negatively affects time to find the right dashboard. Duplicating dashboards and changing “one thing” (worse: keeping original tags) is the easiest kind of sprawl.
|
||||
- Periodically review the dashboards and remove unnecessary ones.
|
||||
- If you create a temporary dashboard, perhaps to test something, prefix the name with `TEST: `. Delete the dashboard when you are finished.
|
||||
- Copying dashboards with no significant changes is not a good idea.
|
||||
- You miss out on updates to the original dashboard, such as documentation changes, bug fixes, or additions to metrics.
|
||||
- In many cases copies are being made to simply customize the view by setting template parameters. This should instead be done by maintaining a link to the master dashboard and customizing the view with [URL parameters]({{< relref "../panels/configure-data-links/#data-link-variables" >}}).
|
||||
- When you must copy a dashboard, clearly rename it and _do not_ copy the dashboard tags. Tags are important metadata for dashboards that are used during search. Copying tags can result in false matches.
|
||||
- Maintain a dashboard of dashboards or cross-reference dashboards. This can be done in several ways:
|
||||
- Create dashboard links, panel, or data links. Links can go to other dashboards or to external systems. For more information, refer to [Manage dashboard links]({{< relref "../dashboards/manage-dashboard-links/" >}}).
|
||||
- Add a [Dashboard list panel]({{< relref "../visualizations/dashboard-list-panel/" >}}). You can then customize what you see by doing tag or folder searches.
|
||||
- Add a [Text panel]({{< relref "../visualizations/text-panel/" >}}) and use markdown to customize the display.
|
||||
@ -1,62 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/common-observability-strategies/
|
||||
- /docs/grafana/latest/getting-started/strategies/
|
||||
description: Common observability strategies
|
||||
keywords:
|
||||
- grafana
|
||||
- intro
|
||||
- guide
|
||||
- concepts
|
||||
- methods
|
||||
title: Common observability strategies
|
||||
weight: 300
|
||||
---
|
||||
|
||||
# Common observability strategies
|
||||
|
||||
When you have a lot to monitor, like a server farm, you need a strategy to decide what is important enough to monitor. This page describes several common methods for choosing what to monitor.
|
||||
|
||||
A logical strategy allows you to make uniform dashboards and scale your observability platform more easily.
|
||||
|
||||
## Guidelines for usage
|
||||
|
||||
- The USE method tells you how happy your machines are, the RED method tells you how happy your users are.
|
||||
- USE reports on causes of issues.
|
||||
- RED reports on user experience and is more likely to report symptoms of problems.
|
||||
- The best practice of alerting is to alert on symptoms rather than causes, so alerting should be done on RED dashboards.
|
||||
|
||||
## USE method
|
||||
|
||||
USE stands for:
|
||||
|
||||
- **Utilization -** Percent time the resource is busy, such as node CPU usage
|
||||
- **Saturation -** Amount of work a resource has to do, often queue length or node load
|
||||
- **Errors -** Count of error events
|
||||
|
||||
This method is best for hardware resources in infrastructure, such as CPU, memory, and network devices. For more information, refer to [The USE Method](http://www.brendangregg.com/usemethod.html).
|
||||
|
||||
## RED method
|
||||
|
||||
RED stands for:
|
||||
|
||||
- **Rate -** Requests per second
|
||||
- **Errors -** Number of requests that are failing
|
||||
- **Duration -** Amount of time these requests take, distribution of latency measurements
|
||||
|
||||
This method is most applicable to services, especially a microservices environment. For each of your services, instrument the code to expose these metrics for each component. RED dashboards are good for alerting and SLAs. A well-designed RED dashboard is a proxy for user experience.
|
||||
|
||||
For more information, refer to Tom Wilkie's blog post [The RED method: How to instrument your services](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services).
|
||||
|
||||
## The Four Golden Signals
|
||||
|
||||
According to the [Google SRE handbook](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals), if you can only measure four metrics of your user-facing system, focus on these four.
|
||||
|
||||
This method is similar to the RED method, but it includes saturation.
|
||||
|
||||
- **Latency -** Time taken to serve a request
|
||||
- **Traffic -** How much demand is placed on your system
|
||||
- **Errors -** Rate of requests that are failing
|
||||
- **Saturation -** How "full" your system is
|
||||
|
||||
[Here's an example from Grafana Play](https://play.grafana.org/d/000000109/the-four-golden-signals?orgId=1).
|
||||
@ -1,73 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/dashboard-management-maturity-levels/
|
||||
description: Explanation of dashboard management maturity model
|
||||
title: Dashboard management maturity model
|
||||
weight: 400
|
||||
---
|
||||
|
||||
# Dashboard management maturity model
|
||||
|
||||
_Dashboard management maturity_ refers to how well-designed and efficient your dashboard ecosystem is. We recommend periodically reviewing your dashboard setup to gauge where you are and how you can improve.
|
||||
|
||||
Broadly speaking, dashboard maturity can be defined as low, medium, or high.
|
||||
|
||||
Much of the content for this topic was taken from the KubeCon 2019 talk [Fool-Proof Kubernetes Dashboards for Sleep-Deprived Oncalls](https://www.youtube.com/watch?v=YE2aQFiMGfY).
|
||||
|
||||
## Low - default state
|
||||
|
||||
At this stage, you have no coherent dashboard management strategy. Almost everyone starts here.
|
||||
|
||||
How can you tell you are here?
|
||||
|
||||
- Everyone can modify your dashboards.
|
||||
- Lots of copied dashboards, little to no dashboard reuse.
|
||||
- One-off dashboards that hang around forever.
|
||||
- No version control (dashboard JSON in version control).
|
||||
- Lots of browsing for dashboards, searching for the right dashboard. This means lots of wasted time trying to find the dashboard you need.
|
||||
- Not having any alerts to direct you to the right dashboard.
|
||||
|
||||
## Medium - methodical dashboards
|
||||
|
||||
At this stage, you are starting to manage your dashboard use with methodical dashboards. You might have laid out a strategy, but there are some things you could improve.
|
||||
|
||||
How can you tell you are here?
|
||||
|
||||
- Prevent sprawl by using template variables. For example, you don't need a separate dashboard for each node, you can use query variables. Even better, you can make the data source a template variable too, so you can reuse the same dashboard across different clusters and monitoring backends.
|
||||
|
||||
Refer to the list of [Variable examples]({{< relref "../dashboards/variables/#examples-of-templates-and-variables" >}}) if you want some ideas.
|
||||
|
||||
- Methodical dashboards according to an [observability strategy]({{< relref "common-observability-strategies/" >}}).
|
||||
- Hierarchical dashboards with drill-downs to the next level.
|
||||
|
||||
{{< figure class="float-right" max-width="100%" src="/static/img/docs/best-practices/drill-down-example.png" caption="Example of using drill-down" >}}
|
||||
|
||||
- Dashboard design reflects service hierarchies. The example shown below uses the RED method (request and error rate on the left, latency duration on the right) with one row per service. The row order reflects the data flow.
|
||||
|
||||
{{< figure class="float-right" max-width="100%" src="/static/img/docs/best-practices/service-hierarchy-example.png" caption="Example of a service hierarchy" >}}
|
||||
|
||||
- Compare like to like: split service dashboards when the magnitude differs. Make sure aggregated metrics don't drown out important information.
|
||||
- Expressive charts with meaningful use of color and normalizing axes where you can.
|
||||
- Example of meaningful color: Blue means it's good, red means it's bad. [Thresholds]({{< relref "../panels/configure-thresholds/" >}}) can help with that.
|
||||
- Example of normalizing axes: When comparing CPU usage, measure by percentage rather than raw number, because machines can have a different number of cores. Normalizing CPU usage by the number of cores reduces cognitive load because the viewer can trust that at 100% all cores are being used, without having to know the number of CPUs.
|
||||
- Directed browsing cuts down on "guessing."
|
||||
- Template variables make it harder to “just browse” randomly or aimlessly.
|
||||
- Most dashboards should be linked to by alerts.
|
||||
- Browsing is directed with links. For more information, refer to [Manage dashboard links]({{< relref "../dashboards/manage-dashboard-links/" >}}).
|
||||
- Version-controlled dashboard JSON.
|
||||
|
||||
## High - optimized use
|
||||
|
||||
At this stage, you have optimized your dashboard management use with a consistent and thoughtful strategy. It requires maintenance, but the results are worth it.
|
||||
|
||||
- Actively reducing sprawl.
|
||||
- Regularly review existing dashboards to make sure they are still relevant.
|
||||
- Only approved dashboards added to master dashboard list.
|
||||
- Tracking dashboard use. If you're an Enterprise user, you can take advantage of [Usage insights]({{< relref "../dashboards/assess-dashboard-usage/" >}}).
|
||||
- Consistency by design.
|
||||
- Use scripting libraries to generate dashboards, ensure consistency in pattern and style.
|
||||
- grafonnet (Jsonnet)
|
||||
- grafanalib (Python)
|
||||
- No editing in the browser. Dashboard viewers change views with variables.
|
||||
- Browsing for dashboards is the exception, not the rule.
|
||||
- Perform experimentation and testing in a separate Grafana instance dedicated to that purpose, not your production instance. When a dashboard in the test environment is proven useful, then add that dashboard to your main Grafana instance.
|
||||
@ -16,13 +16,13 @@ Before you begin, ensure that you have configured a data source. See also:
|
||||
|
||||
- [Use dashboards]({{< relref "use-dashboards/" >}})
|
||||
- [Create dashboard folders]({{< relref "./manage-dashboards/#create-a-dashboard-folder" >}})
|
||||
- [Add and organize panels]({{< relref "add-organize-panels/" >}})
|
||||
- [Add and organize panels]({{< relref "./build-dashboards/add-organize-panels" >}})
|
||||
- [Manage dashboards]({{< relref "./manage-dashboards" >}})
|
||||
- [Public dashboards]({{< relref "dashboard-public/" >}})
|
||||
- [Annotations]({{< relref "annotations/" >}})
|
||||
- [Annotations]({{< relref "./build-dashboards/annotate-visualizations" >}})
|
||||
- [Playlist]({{< relref "./create-manage-playlists/" >}})
|
||||
- [Reporting]({{< relref "./create-reports" >}})
|
||||
- [Time range controls]({{< relref "./manage-dashboards/#common-time-range-controls" >}})
|
||||
- [Dashboard version history]({{< relref "dashboard-history/" >}})
|
||||
- [Dashboard version history]({{< relref "./build-dashboards/manage-version-history" >}})
|
||||
- [Dashboard export and import]({{< relref "./manage-dashboards/#export-and-import-dashboards" >}})
|
||||
- [Dashboard JSON model]({{< relref "json-model/" >}})
|
||||
- [Dashboard JSON model]({{< relref "./build-dashboards/view-dashboard-json-model/" >}})
|
||||
|
||||
20
docs/sources/dashboards/build-dashboards/_index.md
Normal file
20
docs/sources/dashboards/build-dashboards/_index.md
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/next/dashboards/build-dashboards/
|
||||
title: Build dashboards
|
||||
menuTitle: Build dashboards
|
||||
weight: 2
|
||||
keywords:
|
||||
- grafana
|
||||
- dashboard
|
||||
- dashboard folders
|
||||
- create
|
||||
- build
|
||||
- design
|
||||
---
|
||||
|
||||
# Build dashboards
|
||||
|
||||
This section includes the following topics:
|
||||
|
||||
{{< section >}}
|
||||
@ -9,9 +9,10 @@ aliases:
|
||||
- /docs/grafana/latest/panels/add-panels-dynamically/about-repeating-panels-rows/
|
||||
- /docs/grafana/latest/panels/add-panels-dynamically/configure-repeating-rows/
|
||||
- /docs/grafana/latest/panels/add-panels-dynamically/configure-repeating-panels/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/add-organize-panels/
|
||||
title: Add and organize panels
|
||||
menuTitle: Add and organize panels
|
||||
weight: 2
|
||||
weight: 200
|
||||
keywords:
|
||||
- panel
|
||||
- dashboard
|
||||
@ -36,13 +37,13 @@ This section describes the areas of the Grafana panel editor.
|
||||
- **Table view:** Convert any visualization to a table so that you can see the data. Table views are useful for troubleshooting.
|
||||
- **Fill:** The visualization preview fills the available space. If you change the width of the side pane or height of the bottom pane the visualization changes to fill the available space.
|
||||
- **Actual:** The visualization preview will have the exact size as the size on the dashboard. If not enough space is available, the visualization will scale down preserving the aspect ratio.
|
||||
- **Time range controls:** For more information, refer to [Time range controls]({{< relref "../manage-dashboards/#configure-dashboard-time-range-controls" >}}).
|
||||
- **Time range controls:** For more information, refer to [Time range controls]({{< relref "../../manage-dashboards/#configure-dashboard-time-range-controls" >}}).
|
||||
|
||||
1. Data section: The data section contains tabs where you enter queries, transform your data, and create alert rules (if applicable).
|
||||
|
||||
- **Query tab:** Select your data source and enter queries here. For more information, refer to [Add a query]({{< relref "../../panels/query-a-data-source/add-a-query/" >}}).
|
||||
- **Transform tab:** Apply data transformations. For more information, refer to [Transform data]({{< relref "../../panels/transform-data/" >}}).
|
||||
- **Alert tab:** Write alert rules. For more information, refer to [Overview of Grafana 8 alerting]({{< relref "../../alerting/" >}}).
|
||||
- **Query tab:** Select your data source and enter queries here. For more information, refer to [Add a query]({{< relref "../../../panels/query-a-data-source/add-a-query/" >}}).
|
||||
- **Transform tab:** Apply data transformations. For more information, refer to [Transform data]({{< relref "../../../panels/transform-data/" >}}).
|
||||
- **Alert tab:** Write alert rules. For more information, refer to [Overview of Grafana 8 alerting]({{< relref "../../../alerting/" >}}).
|
||||
|
||||
1. Panel display options: The display options section contains tabs where you configure almost every aspect of your data visualization.
|
||||
|
||||
@ -76,10 +77,10 @@ Dashboards and panels allow you to show your data in visual form. Each panel nee
|
||||
|
||||
**Before you begin:**
|
||||
|
||||
- Ensure that you have the proper permissions. For more information about permissions, refer to [About users and permissions]({{< relref "../../administration/roles-and-permissions/" >}}).
|
||||
- Ensure that you have the proper permissions. For more information about permissions, refer to [About users and permissions]({{< relref "../../../administration/roles-and-permissions/" >}}).
|
||||
- Identify the dashboard to which you want to add the panel.
|
||||
- Understand the query language of the target data source.
|
||||
- Ensure that data source for which you are writing a query has been added. For more information about adding a data source, refer to [Add a data source]({{< relref "../../datasources/add-a-data-source/" >}}) if you need instructions.
|
||||
- Ensure that data source for which you are writing a query has been added. For more information about adding a data source, refer to [Add a data source]({{< relref "../../../datasources/add-a-data-source/" >}}) if you need instructions.
|
||||
|
||||
**To create a dashboard and add a panel**:
|
||||
|
||||
@ -88,7 +89,7 @@ Dashboards and panels allow you to show your data in visual form. Each panel nee
|
||||
1. In the first line of the **Query** tab, click the drop-down list and select a data source.
|
||||
1. Write or construct a query in the query language of your data source.
|
||||
|
||||
For more information about data sources, refer to [Data sources]({{< relref "../../datasources/" >}}) for specific guidelines.
|
||||
For more information about data sources, refer to [Data sources]({{< relref "../../../datasources/" >}}) for specific guidelines.
|
||||
|
||||
1. In the Visualization list, select a visualization type.
|
||||
|
||||
@ -96,17 +97,17 @@ Dashboards and panels allow you to show your data in visual form. Each panel nee
|
||||
|
||||
|
||||
|
||||
For more information about individual visualizations, refer to [Visualizations options]({{< relref "../../visualizations/" >}}).
|
||||
For more information about individual visualizations, refer to [Visualizations options]({{< relref "../../../visualizations/" >}}).
|
||||
|
||||
1. Refer to the following documentation for ways you can adjust panel settings.
|
||||
|
||||
While not required, most visualizations need some adjustment before they properly display the information that you need.
|
||||
|
||||
- [Configure value mappings]({{< relref "../../panels/configure-value-mappings" >}})
|
||||
- [Visualization-specific options]({{< relref "../../visualizations/" >}})
|
||||
- [Override field values]({{< relref "../../panels/configure-overrides/" >}})
|
||||
- [Configure thresholds]({{< relref "../../panels/configure-thresholds/" >}})
|
||||
- [Configure standard options]({{< relref "../../panels/configure-standard-options/" >}})
|
||||
- [Configure value mappings]({{< relref "../../../panels/configure-value-mappings" >}})
|
||||
- [Visualization-specific options]({{< relref "../../../visualizations/" >}})
|
||||
- [Override field values]({{< relref "../../../panels/configure-overrides/" >}})
|
||||
- [Configure thresholds]({{< relref "../../../panels/configure-thresholds/" >}})
|
||||
- [Configure standard options]({{< relref "../../../panels/configure-standard-options/" >}})
|
||||
|
||||
1. Add a note to describe the visualization (or describe your changes) and then click **Save** in the upper-right corner of the page.
|
||||
|
||||
@ -2,16 +2,18 @@
|
||||
aliases:
|
||||
- /docs/grafana/latest/dashboards/annotations/
|
||||
- /docs/grafana/latest/reference/annotations/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/annotate-visualizations/
|
||||
keywords:
|
||||
- grafana
|
||||
- annotations
|
||||
- documentation
|
||||
- guide
|
||||
title: Annotations
|
||||
weight: 9
|
||||
title: Annotate visualizations
|
||||
menuTitle: Annotate visualizations
|
||||
weight: 600
|
||||
---
|
||||
|
||||
# Annotations
|
||||
# Annotate visualizations
|
||||
|
||||
Annotations provide a way to mark points on the graph with rich events. When you hover over an annotation
|
||||
you can get event description and event tags. The text field can include links to other systems with more detail.
|
||||
@ -20,7 +22,7 @@ you can get event description and event tags. The text field can include links t
|
||||
|
||||
## Native annotations
|
||||
|
||||
Grafana comes with a native annotation store and the ability to add annotation events directly from the graph panel or via the [HTTP API]({{< relref "../developers/http_api/annotations/" >}}).
|
||||
Grafana comes with a native annotation store and the ability to add annotation events directly from the graph panel or via the [HTTP API]({{< relref "../../../developers/http_api/annotations/" >}}).
|
||||
|
||||
### Add annotation
|
||||
|
||||
@ -94,4 +96,4 @@ to show.
|
||||
|
||||
### Annotation query details
|
||||
|
||||
The annotation query options are different for each data source. For information about annotations in a specific data source, refer to the specific [data source]({{< relref "../datasources/" >}}) topic.
|
||||
The annotation query options are different for each data source. For information about annotations in a specific data source, refer to the specific [data source]({{< relref "../../../datasources/" >}}) topic.
|
||||
213
docs/sources/dashboards/build-dashboards/best-practices/index.md
Normal file
213
docs/sources/dashboards/build-dashboards/best-practices/index.md
Normal file
@ -0,0 +1,213 @@
|
||||
---
|
||||
aliases:
|
||||
- /docs/grafana/latest/best-practices/
|
||||
- /docs/grafana/latest/best-practices/common-observability-strategies/
|
||||
- /docs/grafana/latest/getting-started/strategies/
|
||||
- /docs/grafana/latest/best-practices/dashboard-management-maturity-levels/
|
||||
- /docs/grafana/latest/best-practices/best-practices-for-creating-dashboards/
|
||||
- /docs/grafana/latest/best-practices/best-practices-for-managing-dashboards/
|
||||
- /docs/grafana/latest/dashboards/build-dashboards/best-practices/
|
||||
description: Best practices for working with Grafana
|
||||
title: Grafana dashboard best practices
|
||||
menuTitle: Best practices
|
||||
weight: 100
|
||||
---
|
||||
|
||||
# Grafana dashboard best practices
|
||||
|
||||
This section provides information about best practices for intermediate Grafana administrators and users. Click on each of the links before for more information.
|
||||
|
||||
## Common observability strategies
|
||||
|
||||
When you have a lot to monitor, like a server farm, you need a strategy to decide what is important enough to monitor. This page describes several common methods for choosing what to monitor.
|
||||
|
||||
A logical strategy allows you to make uniform dashboards and scale your observability platform more easily.
|
||||
|
||||
### Guidelines for usage
|
||||
|
||||
- The USE method tells you how happy your machines are, the RED method tells you how happy your users are.
|
||||
- USE reports on causes of issues.
|
||||
- RED reports on user experience and is more likely to report symptoms of problems.
|
||||
- The best practice of alerting is to alert on symptoms rather than causes, so alerting should be done on RED dashboards.
|
||||
|
||||
### USE method
|
||||
|
||||
USE stands for:
|
||||
|
||||
- **Utilization -** Percent time the resource is busy, such as node CPU usage
|
||||
- **Saturation -** Amount of work a resource has to do, often queue length or node load
|
||||
- **Errors -** Count of error events
|
||||
|
||||
This method is best for hardware resources in infrastructure, such as CPU, memory, and network devices. For more information, refer to [The USE Method](http://www.brendangregg.com/usemethod.html).
|
||||
|
||||
### RED method
|
||||
|
||||
RED stands for:
|
||||
|
||||
- **Rate -** Requests per second
|
||||
- **Errors -** Number of requests that are failing
|
||||
- **Duration -** Amount of time these requests take, distribution of latency measurements
|
||||
|
||||
This method is most applicable to services, especially a microservices environment. For each of your services, instrument the code to expose these metrics for each component. RED dashboards are good for alerting and SLAs. A well-designed RED dashboard is a proxy for user experience.
|
||||
|
||||
For more information, refer to Tom Wilkie's blog post [The RED method: How to instrument your services](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services).
|
||||
|
||||
### The Four Golden Signals
|
||||
|
||||
According to the [Google SRE handbook](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals), if you can only measure four metrics of your user-facing system, focus on these four.
|
||||
|
||||
This method is similar to the RED method, but it includes saturation.
|
||||
|
||||
- **Latency -** Time taken to serve a request
|
||||
- **Traffic -** How much demand is placed on your system
|
||||
- **Errors -** Rate of requests that are failing
|
||||
- **Saturation -** How "full" your system is
|
||||
|
||||
[Here's an example from Grafana Play](https://play.grafana.org/d/000000109/the-four-golden-signals?orgId=1).
|
||||
|
||||
## Dashboard management maturity model
|
||||
|
||||
_Dashboard management maturity_ refers to how well-designed and efficient your dashboard ecosystem is. We recommend periodically reviewing your dashboard setup to gauge where you are and how you can improve.
|
||||
|
||||
Broadly speaking, dashboard maturity can be defined as low, medium, or high.
|
||||
|
||||
Much of the content for this topic was taken from the KubeCon 2019 talk [Fool-Proof Kubernetes Dashboards for Sleep-Deprived Oncalls](https://www.youtube.com/watch?v=YE2aQFiMGfY).
|
||||
|
||||
### Low - default state
|
||||
|
||||
At this stage, you have no coherent dashboard management strategy. Almost everyone starts here.
|
||||
|
||||
How can you tell you are here?
|
||||
|
||||
- Everyone can modify your dashboards.
|
||||
- Lots of copied dashboards, little to no dashboard reuse.
|
||||
- One-off dashboards that hang around forever.
|
||||
- No version control (dashboard JSON in version control).
|
||||
- Lots of browsing for dashboards, searching for the right dashboard. This means lots of wasted time trying to find the dashboard you need.
|
||||
- Not having any alerts to direct you to the right dashboard.
|
||||
|
||||
### Medium - methodical dashboards
|
||||
|
||||
At this stage, you are starting to manage your dashboard use with methodical dashboards. You might have laid out a strategy, but there are some things you could improve.
|
||||
|
||||
How can you tell you are here?
|
||||
|
||||
- Prevent sprawl by using template variables. For example, you don't need a separate dashboard for each node, you can use query variables. Even better, you can make the data source a template variable too, so you can reuse the same dashboard across different clusters and monitoring backends.
|
||||
|
||||
Refer to the list of [Variable examples]({{< relref "../../variables/#examples-of-templates-and-variables" >}}) if you want some ideas.
|
||||
|
||||
- Methodical dashboards according to an [observability strategy]({{< relref "#common-observability-strategies" >}}).
|
||||
- Hierarchical dashboards with drill-downs to the next level.
|
||||
|
||||
{{< figure class="float-right" max-width="100%" src="/static/img/docs/best-practices/drill-down-example.png" caption="Example of using drill-down" >}}
|
||||
|
||||
- Dashboard design reflects service hierarchies. The example shown below uses the RED method (request and error rate on the left, latency duration on the right) with one row per service. The row order reflects the data flow.
|
||||
|
||||
{{< figure class="float-right" max-width="100%" src="/static/img/docs/best-practices/service-hierarchy-example.png" caption="Example of a service hierarchy" >}}
|
||||
|
||||
- Compare like to like: split service dashboards when the magnitude differs. Make sure aggregated metrics don't drown out important information.
|
||||
- Expressive charts with meaningful use of color and normalizing axes where you can.
|
||||
- Example of meaningful color: Blue means it's good, red means it's bad. [Thresholds]({{< relref "../../../panels/configure-thresholds/" >}}) can help with that.
|
||||
- Example of normalizing axes: When comparing CPU usage, measure by percentage rather than raw number, because machines can have a different number of cores. Normalizing CPU usage by the number of cores reduces cognitive load because the viewer can trust that at 100% all cores are being used, without having to know the number of CPUs.
|
||||
- Directed browsing cuts down on "guessing."
|
||||
- Template variables make it harder to “just browse” randomly or aimlessly.
|
||||
- Most dashboards should be linked to by alerts.
|
||||
- Browsing is directed with links. For more information, refer to [Manage dashboard links]({{< relref "../manage-dashboard-links" >}}).
|
||||
- Version-controlled dashboard JSON.
|
||||
|
||||
### High - optimized use
|
||||
|
||||
At this stage, you have optimized your dashboard management use with a consistent and thoughtful strategy. It requires maintenance, but the results are worth it.
|
||||
|
||||
- Actively reducing sprawl.
|
||||
- Regularly review existing dashboards to make sure they are still relevant.
|
||||
- Only approved dashboards added to master dashboard list.
|
||||
- Tracking dashboard use. If you're an Enterprise user, you can take advantage of [Usage insights]({{< relref "../../assess-dashboard-usage/" >}}).
|
||||
- Consistency by design.
|
||||
- Use scripting libraries to generate dashboards, ensure consistency in pattern and style.
|
||||
- grafonnet (Jsonnet)
|
||||
- grafanalib (Python)
|
||||
- No editing in the browser. Dashboard viewers change views with variables.
|
||||
- Browsing for dashboards is the exception, not the rule.
|
||||
- Perform experimentation and testing in a separate Grafana instance dedicated to that purpose, not your production instance. When a dashboard in the test environment is proven useful, then add that dashboard to your main Grafana instance.
|
||||
|
||||
## Best practices for creating dashboards
|
||||
|
||||
This page outlines some best practices to follow when creating Grafana dashboards.
|
||||
|
||||
### Before you begin
|
||||
|
||||
Here are some principles to consider before you create a dashboard.
|
||||
|
||||
#### A dashboard should tell a story or answer a question
|
||||
|
||||
What story are you trying to tell with your dashboard? Try to create a logical progression of data, such as large to small or general to specific. What is the goal for this dashboard? (Hint: If the dashboard doesn't have a goal, then ask yourself if you really need the dashboard.)
|
||||
|
||||
Keep your graphs simple and focused on answering the question that you are asking. For example, if your question is "which servers are in trouble?", then maybe you don't need to show all the server data. Just show data for the ones in trouble.
|
||||
|
||||
#### Dashboards should reduce cognitive load, not add to it
|
||||
|
||||
_Cognitive load_ is basically how hard you need to think about something in order to figure it out. Make your dashboard easy to interpret. Other users and future you (when you're trying to figure out what broke at 2AM) will appreciate it.
|
||||
|
||||
Ask yourself:
|
||||
|
||||
- Can I tell what exactly each graph represents? Is it obvious, or do I have to think about it?
|
||||
- If I show this to someone else, how long will it take them to figure it out? Will they get lost?
|
||||
|
||||
#### Have a monitoring strategy
|
||||
|
||||
It's easy to make new dashboards. It's harder to optimize dashboard creation and adhere to a plan, but it's worth it. This strategy should govern both your overall dashboard scheme and enforce consistency in individual dashboard design.
|
||||
|
||||
Refer to [Common observability strategies]({{< relref "#common-observability-strategies" >}}) and [Dashboard management maturity levels]({{< relref "#dashboard-management-maturity-model" >}}) for more information.
|
||||
|
||||
#### Write it down
|
||||
|
||||
Once you have a strategy or design guidelines, write them down to help maintain consistency over time. Check out this [Wikimedia runbook example](https://wikitech.wikimedia.org/wiki/Performance/Runbook/Grafana_best_practices).
|
||||
|
||||
### Best practices to follow
|
||||
|
||||
- When creating a new dashboard, make sure it has a meaningful name.
|
||||
- If you are creating a dashboard to play or experiment, then put the word `TEST` or `TMP` in the name.
|
||||
- Consider including your name or initials in the dashboard name or as a tag so that people know who owns the dashboard.
|
||||
- Remove temporary experiment dashboards when you are done with them.
|
||||
- If you create many related dashboards, think about how to cross-reference them for easy navigation. Refer to [Best practices for managing dashboards]({{< relref "#best-practices-for-managing-dashboards" >}}) for more information.
|
||||
- Grafana retrieves data from a data source. A basic understanding of [data sources]({{< relref "../../../datasources/" >}}) in general and your specific is important.
|
||||
- Avoid unnecessary dashboard refreshing to reduce the load on the network or backend. For example, if your data changes every hour, then you don't need to set the dashboard refresh rate to 30 seconds.
|
||||
- Use the left and right Y-axes when displaying time series with different units or ranges.
|
||||
- Add documentation to dashboards and panels.
|
||||
- To add documentation to a dashboard, add a [Text panel visualization]({{< relref "../../../visualizations/text-panel/" >}}) to the dashboard. Record things like the purpose of the dashboard, useful resource links, and any instructions users might need to interact with the dashboard. Check out this [Wikimedia example](https://grafana.wikimedia.org/d/000000066/resourceloader?orgId=1).
|
||||
- To add documentation to a panel, edit the panel settings and add a description. Any text you add will appear if you hover your cursor over the small `i` in the top left corner of the panel.
|
||||
- Reuse your dashboards and enforce consistency by using [templates and variables]({{< relref "../../variables" >}}).
|
||||
- Be careful with stacking graph data. The visualizations can be misleading, and hide important data. We recommend turning it off in most cases.
|
||||
|
||||
## Best practices for managing dashboards
|
||||
|
||||
This page outlines some best practices to follow when managing Grafana dashboards.
|
||||
|
||||
### Before you begin
|
||||
|
||||
Here are some principles to consider before you start managing dashboards.
|
||||
|
||||
#### Strategic observability
|
||||
|
||||
There are several [common observability strategies]({{< relref "#common-observability-strategies" >}}). You should research them and decide whether one of them works for you or if you want to come up with your own. Either way, have a plan, write it down, and stick to it.
|
||||
|
||||
Adapt your strategy to changing needs as necessary.
|
||||
|
||||
#### Maturity level
|
||||
|
||||
What is your dashboard maturity level? Analyze your current dashboard setup and compare it to the [Dashboard management maturity model]({{< relref "#dashboard-management-maturity-model" >}}). Understanding where you are can help you decide how to get to where you want to be.
|
||||
|
||||
### Best practices to follow
|
||||
|
||||
- Avoid dashboard sprawl, meaning the uncontrolled growth of dashboards. Dashboard sprawl negatively affects time to find the right dashboard. Duplicating dashboards and changing “one thing” (worse: keeping original tags) is the easiest kind of sprawl.
|
||||
- Periodically review the dashboards and remove unnecessary ones.
|
||||
- If you create a temporary dashboard, perhaps to test something, prefix the name with `TEST: `. Delete the dashboard when you are finished.
|
||||
- Copying dashboards with no significant changes is not a good idea.
|
||||
- You miss out on updates to the original dashboard, such as documentation changes, bug fixes, or additions to metrics.
|
||||
- In many cases copies are being made to simply customize the view by setting template parameters. This should instead be done by maintaining a link to the master dashboard and customizing the view with [URL parameters]({{< relref "../../../panels/configure-data-links/#data-link-variables" >}}).
|
||||
- When you must copy a dashboard, clearly rename it and _do not_ copy the dashboard tags. Tags are important metadata for dashboards that are used during search. Copying tags can result in false matches.
|
||||
- Maintain a dashboard of dashboards or cross-reference dashboards. This can be done in several ways:
|
||||
- Create dashboard links, panel, or data links. Links can go to other dashboards or to external systems. For more information, refer to [Manage dashboard links]({{< relref "../manage-dashboard-links/" >}}).
|
||||
- Add a [Dashboard list panel]({{< relref "../../../visualizations/dashboard-list-panel/" >}}). You can then customize what you see by doing tag or folder searches.
|
||||
- Add a [Text panel]({{< relref "../../../visualizations/text-panel/" >}}) and use markdown to customize the display.
|
||||
@ -6,6 +6,7 @@ aliases:
|
||||
- /docs/grafana/latest/linking/dashboard-links/
|
||||
- /docs/grafana/latest/dashboards/manage-dashboard-links/
|
||||
- /docs/grafana/latest/panels/working-with-panels/add-link-to-panel/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/manage-dashboard-links/
|
||||
description: How to link Grafana dashboards.
|
||||
keywords:
|
||||
- link
|
||||
@ -17,7 +18,7 @@ keywords:
|
||||
- navigate
|
||||
title: Manage dashboard links
|
||||
menuTitle: Manage dashboard links
|
||||
weight: 400
|
||||
weight: 500
|
||||
---
|
||||
|
||||
# Manage dashboard links
|
||||
@ -35,7 +36,7 @@ The next step is to figure out which link type is right for your workflow. Even
|
||||
- If the link relates to most if not all of the panels in the dashboard, use [dashboard links]({{< relref "#dashboard-links" >}}).
|
||||
- If you want to drill down into specific panels, use [panel links]({{< relref "#panel-links" >}}).
|
||||
- If you want to link to an external site, you can use either a dashboard link or a panel link.
|
||||
- If you want to drill down into a specific series, or even a single measurement, use [data links]({{< relref "../../panels/configure-data-links/#data-links" >}}).
|
||||
- If you want to drill down into a specific series, or even a single measurement, use [data links]({{< relref "../../../panels/configure-data-links/#data-links" >}}).
|
||||
|
||||
## Controlling time range using the URL
|
||||
|
||||
@ -47,7 +48,7 @@ You can control the time range of a panel or dashboard by providing following qu
|
||||
|
||||
## Dashboard links
|
||||
|
||||
When you create a dashboard link, you can include the time range and current template variables to directly jump to the same context in another dashboard. This way, you don’t have to worry whether the person you send the link to is looking at the right data. For other types of links, refer to [Data link variables]({{< relref "../../panels/configure-data-links/#data-link-variables/" >}}).
|
||||
When you create a dashboard link, you can include the time range and current template variables to directly jump to the same context in another dashboard. This way, you don’t have to worry whether the person you send the link to is looking at the right data. For other types of links, refer to [Data link variables]({{< relref "../../../panels/configure-data-links/#data-link-variables/" >}}).
|
||||
|
||||
Dashboard links can also be used as shortcuts to external systems, such as submitting [a GitHub issue with the current dashboard name](https://github.com/grafana/grafana/issues/new?title=Dashboard%3A%20HTTP%20Requests).
|
||||
|
||||
@ -7,10 +7,11 @@ aliases:
|
||||
- /docs/grafana/latest/panels/library-panels/unlink-library-panel/
|
||||
- /docs/grafana/latest/panels/library-panels/manage-library-panel/
|
||||
- /docs/grafana/latest/panels/library-panels/delete-library-panel/
|
||||
- /docs/grafana/latest/dashboards/manage-library-panels/
|
||||
- /docs/grafana/next/dashboards/manage-library-panels/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/manage-library-panels/
|
||||
title: Manage Grafana library panels
|
||||
menuTitle: Manage library panels
|
||||
weight: 3
|
||||
weight: 300
|
||||
---
|
||||
|
||||
# Manage Grafana library panels
|
||||
@ -2,17 +2,19 @@
|
||||
aliases:
|
||||
- /docs/grafana/latest/dashboards/dashboard-history/
|
||||
- /docs/grafana/latest/reference/dashboard_history/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/manage-version-history/
|
||||
keywords:
|
||||
- grafana
|
||||
- dashboard
|
||||
- documentation
|
||||
- version
|
||||
- history
|
||||
title: Dashboard version history
|
||||
weight: 14
|
||||
title: Manage dashboard version history
|
||||
menutitle: Manage version history
|
||||
weight: 400
|
||||
---
|
||||
|
||||
# Dashboard version history
|
||||
# Manage dashboard version history
|
||||
|
||||
Whenever you save a version of your dashboard, a copy of that version is saved so that previous versions of your dashboard are never lost. A list of these versions is available by entering the dashboard settings and then selecting "Versions" in the left side menu.
|
||||
|
||||
@ -2,6 +2,7 @@
|
||||
aliases:
|
||||
- /docs/grafana/latest/dashboards/json-model/
|
||||
- /docs/grafana/latest/reference/dashboard/
|
||||
- /docs/grafana/next/dashboards/build-dashboards/view-dashboard-json-model/
|
||||
keywords:
|
||||
- grafana
|
||||
- dashboard
|
||||
@ -9,7 +10,7 @@ keywords:
|
||||
- json
|
||||
- model
|
||||
title: JSON model
|
||||
weight: 1200
|
||||
weight: 700
|
||||
---
|
||||
|
||||
# Dashboard JSON model
|
||||
@ -14,7 +14,7 @@ aliases:
|
||||
title: Manage dashboards
|
||||
menuTitle: Manage dashboards
|
||||
weight: 8
|
||||
eywords:
|
||||
keywords:
|
||||
- grafana
|
||||
- dashboard
|
||||
- dashboard folders
|
||||
|
||||
@ -80,7 +80,7 @@ Use the new [contextPerRenderKey]({{< relref "../setup-grafana/image-rendering/#
|
||||
|
||||
### Saving previews
|
||||
|
||||
The crawler saves previews and their metadata in Grafana's DB. Preview's metadata contains, among other things, the [dashboard version]({{< relref "dashboard-history/" >}}) from the time of taking the screenshot. During subsequent runs, the crawler uses the saved version to find stale dashboard previews.
|
||||
The crawler saves previews and their metadata in Grafana's DB. Preview's metadata contains, among other things, the [dashboard version]({{< relref "./build-dashboards/manage-version-history" >}}) from the time of taking the screenshot. During subsequent runs, the crawler uses the saved version to find stale dashboard previews.
|
||||
|
||||
## Permissions
|
||||
|
||||
|
||||
@ -180,7 +180,7 @@ Example dashboard:
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
queries via the Dashboard menu / Annotations view. Grafana can query any Elasticsearch index
|
||||
for annotation events.
|
||||
|
||||
|
||||
@ -280,7 +280,7 @@ Refer to the [variable syntax documentation]({{< relref "../../dashboards/variab
|
||||
|
||||
{{< figure src="/static/img/docs/google-cloud-monitoring/annotations-8-0.png" max-width= "400px" class="docs-image--right" >}}
|
||||
|
||||
[Annotations]({{< relref "../../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
[Annotations]({{< relref "../../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
queries via the Dashboard menu / Annotations view. Annotation rendering is expensive so it is important to limit the number of rows returned. There is no support for showing Google Cloud Monitoring annotations and events yet but it works well with [custom metrics](https://cloud.google.com/monitoring/custom-metrics/) in Google Cloud Monitoring.
|
||||
|
||||
With the query editor for annotations, you can select a metric and filters. The `Title` and `Text` fields support templating and can use data returned from the query. For example, the Title field could have the following text:
|
||||
|
||||
@ -216,7 +216,7 @@ For more information, refer to [Advanced variable format options]({{< relref "..
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
queries via the Dashboard menu / Annotations view.
|
||||
|
||||
Graphite supports two ways to query annotations. A regular metric query, for this you use the `Graphite query` textbox. A Graphite events query, use the `Graphite event tags` textbox,
|
||||
|
||||
@ -146,7 +146,7 @@ To add a filter, click the plus icon to the right of the `Measurements/Fields` b
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../../dashboards/annotations/" >}}) allows you to overlay rich event information on top of graphs. Add annotation queries using the Annotations view in the Dashboard menu.
|
||||
[Annotations]({{< relref "../../dashboards/build-dashboards/annotate-visualizations" >}}) allows you to overlay rich event information on top of graphs. Add annotation queries using the Annotations view in the Dashboard menu.
|
||||
|
||||
An example query:
|
||||
|
||||
|
||||
@ -232,7 +232,7 @@ You can use some global built-in variables in query variables; `$__interval`, `$
|
||||
|
||||
## Annotations
|
||||
|
||||
You can use any non-metric Loki query as a source for [annotations]({{< relref "../dashboards/annotations/" >}}). Log content will be used as annotation text and your log stream labels as tags, so there is no need for additional mapping.
|
||||
You can use any non-metric Loki query as a source for [annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}). Log content will be used as annotation text and your log stream labels as tags, so there is no need for additional mapping.
|
||||
|
||||
## Configure the data source with provisioning
|
||||
|
||||
|
||||
@ -345,7 +345,7 @@ Read more about variable formatting options in the [Variables]({{< relref "../da
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
|
||||
**Columns:**
|
||||
|
||||
|
||||
@ -382,7 +382,7 @@ Read more about variable formatting options in the [Variables]({{< relref "../da
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
|
||||
**Example query using time column with epoch values:**
|
||||
|
||||
|
||||
@ -380,7 +380,7 @@ Read more about variable formatting options in the [Variables]({{< relref "../da
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation queries via the Dashboard menu / Annotations view.
|
||||
|
||||
**Example query using time column with epoch values:**
|
||||
|
||||
|
||||
@ -240,7 +240,7 @@ applied to all your Prometheus queries.
|
||||
|
||||
## Annotations
|
||||
|
||||
[Annotations]({{< relref "../dashboards/annotations/" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
[Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) allow you to overlay rich event information on top of graphs. You add annotation
|
||||
queries via the Dashboard menu / Annotations view.
|
||||
|
||||
Prometheus supports two ways to query annotations.
|
||||
|
||||
@ -6,7 +6,7 @@ title: Add support for annotations
|
||||
|
||||
# Add support for annotations
|
||||
|
||||
This guide explains how to add support for [annotations]({{< relref "../../dashboards/annotations/" >}}) to an existing data source plugin.
|
||||
This guide explains how to add support for [annotations]({{< relref "../../dashboards/build-dashboards/annotate-visualizations" >}}) to an existing data source plugin.
|
||||
|
||||
This guide assumes that you're already familiar with how to [Build a data source plugin]({{< ref "build-a-data-source-plugin.md" >}}).
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ title: Legacy snapshot mode
|
||||
|
||||
{{< figure class="float-right" src="/static/img/docs/Grafana-snapshot-example.png" caption="A dashboard using snapshot data and not live data." >}}
|
||||
|
||||
Grafana has this great feature where you can [save a snapshot of your dashboard]({{< relref "../../../dashboards/json-model/" >}}). Instead of sending a screenshot of a dashboard to someone, you can send them a working, interactive Grafana dashboard with the snapshot data embedded inside it. The snapshot can be saved on your Grafana server and is available to all your co-workers. Raintank also hosts a [snapshot server](https://snapshots.raintank.io) if you want to send the snapshot to someone who does not have access to your Grafana server.
|
||||
Grafana has this great feature where you can [save a snapshot of your dashboard]({{< relref "../../../dashboards/build-dashboards/view-dashboard-json-model" >}}). Instead of sending a screenshot of a dashboard to someone, you can send them a working, interactive Grafana dashboard with the snapshot data embedded inside it. The snapshot can be saved on your Grafana server and is available to all your co-workers. Raintank also hosts a [snapshot server](https://snapshots.raintank.io) if you want to send the snapshot to someone who does not have access to your Grafana server.
|
||||
|
||||
{{< figure class="float-right" src="/static/img/docs/animated_gifs/snapshots.gif" caption="Selecting a snapshot" >}}
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ Alert hooks allow you to create different notifiers with a bit of code if you pr
|
||||
|
||||
Annotate graphs with rich events from different data sources. Hover over events to see the full event metadata and tags.
|
||||
|
||||
This feature, which shows up as a graph marker in Grafana, is useful for correlating data in case something goes wrong. You can create the annotations manually—just control-click on a graph and input some text—or you can fetch data from any data source. Refer to [Annotations]({{< relref "../dashboards/annotations.md" >}}) for more information.
|
||||
This feature, which shows up as a graph marker in Grafana, is useful for correlating data in case something goes wrong. You can create the annotations manually—just control-click on a graph and input some text—or you can fetch data from any data source. Refer to [Annotations]({{< relref "../dashboards/build-dashboards/annotate-visualizations" >}}) for more information.
|
||||
|
||||
## Dashboard variables
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ The Dashboard data source lets you select a panel in your dashboard that contain
|
||||
|
||||
This strategy can drastically reduce the number of queries being made when you for example have several panels visualizing the same data.
|
||||
|
||||
1. [Create a dashboard and add a panel]({{< relref "../../dashboards/add-organize-panels/#create-a-dashboard-and-add-a-panel" >}}).
|
||||
1. [Create a dashboard and add a panel]({{< relref "../../dashboards/build-dashboards/add-organize-panels/#create-a-dashboard-and-add-a-panel" >}}).
|
||||
1. Change the title to "Source panel". You'll use this panel as a source for the other panels.
|
||||
1. Define the [query]({{< relref "add-a-query/" >}}) or queries that you want share.
|
||||
|
||||
|
||||
@ -129,7 +129,7 @@ grafana-cli plugins update-all
|
||||
|
||||
The dashboard grid layout engine has changed. All dashboards will be automatically upgraded to new positioning system when you load them in v5. Dashboards saved in v5 will not work in older versions of Grafana. Some external panel plugins might need to be updated to work properly.
|
||||
|
||||
For more details on the new panel positioning system, refer to [panel size position]({{< relref "../dashboards/json-model/#panel-size-position" >}})
|
||||
For more details on the new panel positioning system, refer to [panel size position]({{< relref "../dashboards/build-dashboards/view-dashboard-json-model/#panel-size-and-position" >}}).
|
||||
|
||||
## Upgrading to v5.2
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ To learn more about the differences between new alerts and the legacy alerts, re
|
||||
|
||||
### Library panels
|
||||
|
||||
Library panels allow users to build panels that can be used in multiple dashboards. Any updates made to that shared panel will then automatically be applied to all the dashboards that have that panel. For instructions on how to create, add, unlink and manage library panels, refer to [Library panels]({{< relref "../dashboards/manage-library-panels/" >}}).
|
||||
Library panels allow users to build panels that can be used in multiple dashboards. Any updates made to that shared panel will then automatically be applied to all the dashboards that have that panel. For instructions on how to create, add, unlink and manage library panels, refer to [Library panels]({{< relref "../dashboards/build-dashboards/manage-library-panels" >}}).
|
||||
|
||||
### Real-time streaming
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user