IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2024-11-30 04:34:23 -06:00
Code Issues Packages Projects Releases Wiki Activity
e32e135c73
grafana/docs/sources/best-practices/best-practices-for-managing-dashboards.md
achatterjee-grafana e32e135c73
Docs move "visualizations" folder up one level in TOC (#38523) 
* Moved Visualizations folder one level up. Fixed a bunch of broken relrefs.

* More broken relrefs.

* Fixed the last of the broken relrefs

* Adjusted weight and added alias.

* Added aliases to a bunch of visualization topics.

* More topics with aliases.

* More aliases, adjusted some weight and other metadata information.
2021-08-25 14:14:00 -04:00

2.7 KiB
Raw Blame History

+++ title = "Best practices for managing dashboards" description = "Best practices for managing dashboards in Grafana" 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.md" >}}). 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.md" >}}). 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 "../linking/data-link-variables.md" >}}).
  • 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 [Linking]({{< relref "../linking/_index.md" >}}).
    • Add a [Dashboard list panel]({{< relref "../visualizations/dashboard-list-panel.md" >}}). You can then customize what you see by doing tag or folder searches.
    • Add a [Text panel]({{< relref "../visualizations/text-panel.md" >}}) and use markdown to customize the display.