grafana setup Grafana Live is a real time messaging engine that pushes event data to live live ha setup live configure grafana live live live feature overview live aliases live live channel live set up grafana live a frontend when an event occurs

Answer:
---
aliases:
  - ../live/
  - ../live/configure-grafana-live/
  - ../live/live-channel/
  - ../live/live-feature-overview/
  - ../live/live-ha-setup/
  - ../live/set-up-grafana-live/
description: Grafana Live is a real-time messaging engine that pushes event data to
  a frontend when an event occurs.
labels:
  products:
    - enterprise
    - oss
menuTitle: Set up Grafana Live
title: Set up Grafana Live
weight: 1100
---

# Set up Grafana Live

Grafana Live is a real-time messaging engine you can use to push event data to a frontend as soon as an event occurs.

This could be notifications about dashboard changes, new frames for rendered data, and so on. Live features can help eliminate a page reload or polling in many places, it can stream Internet of things (IoT) sensors or any other real-time data to panels.

By `real-time`, we indicate a soft real-time. Due to network latencies, garbage collection cycles, and so on, the delay of a delivered message can be up to several hundred milliseconds or higher.

## Concepts

Grafana Live sends data to clients over persistent WebSocket connection. Grafana frontend subscribes on channels to receive data which was published into that channel – in other words PUB/SUB mechanics is used. All subscriptions on a page multiplexed inside a single WebSocket connection. There are some rules regarding Live channel names – see [Grafana Live channel]().

Handling persistent connections like WebSocket in scale may require operating system and infrastructure tuning. That's why by default Grafana Live supports 100 simultaneous connections max. For more details on how to tune this limit, refer to [Live configuration section]().

## Features

Having a way to send data to clients in real-time opens a road for new ways of data interaction and visualization. Below we describe Grafana Live features supported at the moment.

### Dashboard change notifications

As soon as there is a change to the dashboard layout, it is automatically reflected on other devices connected to Grafana Live.

### Data streaming from plugins

With Grafana Live, backend data source plugins can stream updates to frontend panels.

For data source plugin channels, Grafana uses `ds` scope. Namespace in the case of data source channels is a data source unique ID (UID) which is issued by Grafana at the moment of data source creation. The path is a custom string that plugin authors free to choose themselves (just make sure it consists of allowed symbols).

For example, a data source channel looks like this: `ds/<DATASOURCE_UID>/<CUSTOM_PATH>`.

Refer to the tutorial about [building a streaming data source backend plugin](/tutorials/build-a-streaming-data-source-plugin/) for more details.

The basic streaming example included in Grafana core streams frames with some generated data to a panel. To look at it create a new panel and point it to the `-- Grafana --` data source. Next, choose `Live Measurements` and select the `plugin/testdata/random-20Hz-stream` channel.

### Data streaming from Telegraf

A new API endpoint `/api/live/push/:streamId` allows accepting metrics data in Influx format from Telegraf. These metrics are transformed into Grafana data frames and published to channels.

Refer to the tutorial about [streaming metrics from Telegraf to Grafana](/tutorials/stream-metrics-from-telegraf-to-grafana/) for more information.

## Grafana Live channel

Grafana Live is a PUB/SUB server, clients subscribe to channels to receive real-time updates published to those channels.

### Channel structure

Channel is a string identifier. In Grafana channel consists of 3 parts delimited by `/`:

- Scope
- Namespace
- Path

For example, the channel `grafana/dashboard/xyz` has the scope `grafana`, namespace `dashboard`, and path `xyz`.

Scope, namespace and path can only have ASCII alphanumeric symbols (A-Z, a-z, 0-9), `_` (underscore) and `-` (dash) at the moment. The path part can additionally have `/`, `.` and `=` symbols. The meaning of scope, namespace and path is context-specific.

The maximum length of a channel is 160 symbols.

Scope determines the purpose of a channel in Grafana. For example, for data source plugin channels Grafana uses `ds` scope. For built-in features like dashboard edit notifications Grafana uses `grafana` scope.

Namespace has a different meaning depending on scope. For example, for `grafana` scope this could be a name of built-in real-time feature like `dashboard` (i.e. dashboards events).

The path, which is the final part of a channel, usually contains the identifier of some concrete resource such as the ID of a dashboard that a user is currently looking at. But a path can be anything.

Channels are lightweight and ephemeral - they are created automatically on user subscription and removed as soon as last user left a channel.

### Data format

All data travelling over Live channels must be JSON-encoded.

## Configure Grafana Live

Grafana Live is enabled by default. In Grafana v8.0, it has a strict default for a maximum number of connections per Grafana server instance.

### Max number of connections

Grafana Live uses persistent connections (WebSocket at the moment) to deliver real-time updates to clients.

WebSocket is a persistent connection that starts with an HTTP Upgrade request (using the same HTTP port as the rest of Grafana) and then switches to a TCP mode where WebSocket frames can travel in both directions between a client and a server. Each logged-in user opens a WebSocket connection – one per browser tab.

The number of maximum WebSocket connections users can establish with Grafana is limited to 100 by default. See [max_connections]() option.

In case you want to increase this limit, ensure that your server and infrastructure allow handling more connections. The following sections discuss several common problems which could happen when managing persistent connections, in particular WebSocket connections.

### Request origin check

To avoid hijacking of WebSocket connection Grafana Live checks the Origin request header sent by a client in an HTTP Upgrade request. Requests without Origin header pass through without any origin check.

By default, Live accepts connections with Origin header that matches configured [root_url]() (which is a public Grafana URL).

It is possible to provide a list of additional origin patterns to allow WebSocket connections from. This can be achieved using the [allowed_origins]() option of Grafana Live configuration.

#### Resource usage

Each persistent connection costs some memory on a server. Typically, this should be about 50 KB per connection at this moment. Thus a server with 1 GB RAM is expected to handle about 20k connections max. Each active connection consumes additional CPU resources since the client and server send PING/PONG frames to each other to maintain a connection.

Using the streaming functionality results in additional CPU usage. The exact CPU resource utilization can be hard to estimate as it heavily depends on the Grafana Live usage pattern.

#### Open file limit

Each WebSocket connection costs a file descriptor on a server machine where Grafana runs. Most operating systems have a quite low default limit for the maximum number of descriptors that process can open.

To look at the current limit on Unix run:

```
ulimit -n
```

On a Linux system, you can also check out the current limits for a running process with:

```
cat /proc/<PROCESS_PID>/limits
```

The open files limit shows approximately how many user connections your server can currently handle.

To increase this limit, refer to [these instructions](https://docs.riak.com/riak/kv/2.2.3/using/performance/open-files-limit.1.html) for popular operating systems.

#### Ephemeral port exhaustion

Ephemeral port exhaustion problem can happen between your load balancer (or reverse proxy) software and Grafana server. For example, when you load balance requests/connections between different Grafana instances. If you connect directly to a single Grafana server instance, then you should not come across this issue.

The problem arises because each TCP connection uniquely identified in the OS by the 4-part-tuple:

```
source ip | source port | destination ip | destination port
```

By default, on load balancer/server boundary you are limited to 65535 possible variants. But actually, due to some OS limits (for example on Unix available ports defined in `ip_local_port_range` sysctl parameter) and sockets in TIME_WAIT state, the number is even less.

In order to eliminate a problem you can:

- Increase the ephemeral port range by tuning `ip_local_port_range` kernel option.
- Deploy more Grafana server instances to load balance across.
- Deploy more load balancer instances.
- Use virtual network interfaces.

#### WebSocket and proxies

Not all proxies can transparently proxy WebSocket connections by default. For example, if you are using Nginx before Grafana you need to configure WebSocket proxy like this:

```
http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}
```

See the [Nginx blog on their website](https://www.nginx.com/blog/websocket-nginx/) for more information. Also, refer to your load balancer/reverse proxy documentation to find out more information on dealing with WebSocket connections.

Some corporate proxies can remove headers required to properly establish a WebSocket connection. In this case, you should tune intermediate proxies to not remove required headers. However, the better option is to use Grafana with TLS. Now WebSocket connection will inherit TLS and thus must be handled transparently by proxies.

Proxies like Nginx and Envoy have default limits on maximum number of connections which can be established. Make sure you have a reasonable limit for max number of incoming and outgoing connections in your proxy configuration.

## Configure Grafana Live HA setup

By default, Grafana Live uses in-memory data structures and in-memory PUB/SUB hub for handling subscriptions.

In a high availability Grafana setup involving several Grafana server instances behind a load balancer, you can find the following limitations:

- Built-in features like dashboard change notifications will only be broadcasted to users connected to the same Grafana server process instance.
- Streaming from Telegraf will deliver data only to clients connected to the same instance which received Telegraf data, active stream cache is not shared between different Grafana instances.
- A separate unidirectional stream between Grafana and backend data source may be opened on different Grafana servers for the same channel.

To bypass these limitations, Grafana v8.1 has an experimental Live HA engine that requires Redis to work.

### Configure Redis Live engine

When the Redis engine is configured, Grafana Live keeps its state in Redis and uses Redis PUB/SUB functionality to deliver messages to all subscribers throughout all Grafana server nodes.

Here is an example configuration:

```
[live]
ha_engine = redis
ha_engine_address = 127.0.0.1:6379
```

For additional information, refer to the [ha_engine]() and [ha_engine_address]() options.

After running:

- All built-in real-time notifications like dashboard changes are delivered to all Grafana server instances and broadcasted to all subscribers.
- Streaming from Telegraf delivers messages to all subscribers.
- A separate unidirectional stream between Grafana and backend data source opens on different Grafana servers. Publishing data to a channel delivers messages to instance subscribers, as a result, publications from different instances on different machines do not produce duplicate data on panels.

At the moment we only support single Redis node.

> **Note:** It's possible to use Redis Sentinel and Haproxy to achieve a highly available Redis setup. Redis nodes should be managed by [Redis Sentinel](https://redis.io/topics/sentinel) to achieve automatic failover. Haproxy configuration example:
>
> ```
> listen redis
>   server redis-01 127.0.0.1:6380 check port 6380 check inter 2s weight 1 inter 2s downinter 5s rise 10 fall 2 on-marked-down shutdown-sessions on-marked-up shutdown-backup-sessions
>   server redis-02 127.0.0.1:6381 check port 6381 check inter 2s weight 1 inter 2s downinter 5s rise 10 fall 2 backup
>   bind *:6379
>   mode tcp
>   option tcpka
>   option tcplog
>   option tcp-check
>   tcp-check send PING\r\n
>   tcp-check expect string +PONG
>   tcp-check send info\ replication\r\n
>   tcp-check expect string role:master
>   tcp-check send QUIT\r\n
>   tcp-check expect string +OK
>   balance roundrobin
> ```
>
> Next, point Grafana Live to Haproxy address:port.

aliases         live         live configure grafana live         live live channel         live live feature overview         live live ha setup         live set up grafana live  description  Grafana Live is a real time messaging engine that pushes event data to   a frontend when an event occurs  labels    products        enterprise       oss menuTitle  Set up Grafana Live title  Set up Grafana Live weight  1100        Set up Grafana Live  Grafana Live is a real time messaging engine you can use to push event data to a frontend as soon as an event occurs   This could be notifications about dashboard changes  new frames for rendered data  and so on  Live features can help eliminate a page reload or polling in many places  it can stream Internet of things  IoT  sensors or any other real time data to panels    By  real time   we indicate a soft real time  Due to network latencies  garbage collection cycles  and so on  the delay of a delivered message can be up to several hundred milliseconds or higher       Concepts  Grafana Live sends data to clients over persistent WebSocket connection  Grafana frontend subscribes on channels to receive data which was published into that channel   in other words PUB SUB mechanics is used  All subscriptions on a page multiplexed inside a single WebSocket connection  There are some rules regarding Live channel names   see  Grafana Live channel      Handling persistent connections like WebSocket in scale may require operating system and infrastructure tuning  That s why by default Grafana Live supports 100 simultaneous connections max  For more details on how to tune this limit  refer to  Live configuration section         Features  Having a way to send data to clients in real time opens a road for new ways of data interaction and visualization  Below we describe Grafana Live features supported at the moment       Dashboard change notifications  As soon as there is a change to the dashboard layout  it is automatically reflected on other devices connected to Grafana Live       Data streaming from plugins  With Grafana Live  backend data source plugins can stream updates to frontend panels   For data source plugin channels  Grafana uses  ds  scope  Namespace in the case of data source channels is a data source unique ID  UID  which is issued by Grafana at the moment of data source creation  The path is a custom string that plugin authors free to choose themselves  just make sure it consists of allowed symbols    For example  a data source channel looks like this   ds  DATASOURCE UID   CUSTOM PATH     Refer to the tutorial about  building a streaming data source backend plugin   tutorials build a streaming data source plugin   for more details   The basic streaming example included in Grafana core streams frames with some generated data to a panel  To look at it create a new panel and point it to the     Grafana     data source  Next  choose  Live Measurements  and select the  plugin testdata random 20Hz stream  channel       Data streaming from Telegraf  A new API endpoint   api live push  streamId  allows accepting metrics data in Influx format from Telegraf  These metrics are transformed into Grafana data frames and published to channels   Refer to the tutorial about  streaming metrics from Telegraf to Grafana   tutorials stream metrics from telegraf to grafana   for more information      Grafana Live channel  Grafana Live is a PUB SUB server  clients subscribe to channels to receive real time updates published to those channels       Channel structure  Channel is a string identifier  In Grafana channel consists of 3 parts delimited by         Scope   Namespace   Path  For example  the channel  grafana dashboard xyz  has the scope  grafana   namespace  dashboard   and path  xyz    Scope  namespace and path can only have ASCII alphanumeric symbols  A Z  a z  0 9        underscore  and      dash  at the moment  The path part can additionally have          and     symbols  The meaning of scope  namespace and path is context specific   The maximum length of a channel is 160 symbols   Scope determines the purpose of a channel in Grafana  For example  for data source plugin channels Grafana uses  ds  scope  For built in features like dashboard edit notifications Grafana uses  grafana  scope   Namespace has a different meaning depending on scope  For example  for  grafana  scope this could be a name of built in real time feature like  dashboard   i e  dashboards events    The path  which is the final part of a channel  usually contains the identifier of some concrete resource such as the ID of a dashboard that a user is currently looking at  But a path can be anything   Channels are lightweight and ephemeral   they are created automatically on user subscription and removed as soon as last user left a channel       Data format  All data travelling over Live channels must be JSON encoded      Configure Grafana Live  Grafana Live is enabled by default  In Grafana v8 0  it has a strict default for a maximum number of connections per Grafana server instance       Max number of connections  Grafana Live uses persistent connections  WebSocket at the moment  to deliver real time updates to clients   WebSocket is a persistent connection that starts with an HTTP Upgrade request  using the same HTTP port as the rest of Grafana  and then switches to a TCP mode where WebSocket frames can travel in both directions between a client and a server  Each logged in user opens a WebSocket connection   one per browser tab   The number of maximum WebSocket connections users can establish with Grafana is limited to 100 by default  See  max connections    option   In case you want to increase this limit  ensure that your server and infrastructure allow handling more connections  The following sections discuss several common problems which could happen when managing persistent connections  in particular WebSocket connections       Request origin check  To avoid hijacking of WebSocket connection Grafana Live checks the Origin request header sent by a client in an HTTP Upgrade request  Requests without Origin header pass through without any origin check   By default  Live accepts connections with Origin header that matches configured  root url     which is a public Grafana URL    It is possible to provide a list of additional origin patterns to allow WebSocket connections from  This can be achieved using the  allowed origins    option of Grafana Live configuration        Resource usage  Each persistent connection costs some memory on a server  Typically  this should be about 50 KB per connection at this moment  Thus a server with 1 GB RAM is expected to handle about 20k connections max  Each active connection consumes additional CPU resources since the client and server send PING PONG frames to each other to maintain a connection   Using the streaming functionality results in additional CPU usage  The exact CPU resource utilization can be hard to estimate as it heavily depends on the Grafana Live usage pattern        Open file limit  Each WebSocket connection costs a file descriptor on a server machine where Grafana runs  Most operating systems have a quite low default limit for the maximum number of descriptors that process can open   To look at the current limit on Unix run       ulimit  n      On a Linux system  you can also check out the current limits for a running process with       cat  proc  PROCESS PID  limits      The open files limit shows approximately how many user connections your server can currently handle   To increase this limit  refer to  these instructions  https   docs riak com riak kv 2 2 3 using performance open files limit 1 html  for popular operating systems        Ephemeral port exhaustion  Ephemeral port exhaustion problem can happen between your load balancer  or reverse proxy  software and Grafana server  For example  when you load balance requests connections between different Grafana instances  If you connect directly to a single Grafana server instance  then you should not come across this issue   The problem arises because each TCP connection uniquely identified in the OS by the 4 part tuple       source ip   source port   destination ip   destination port      By default  on load balancer server boundary you are limited to 65535 possible variants  But actually  due to some OS limits  for example on Unix available ports defined in  ip local port range  sysctl parameter  and sockets in TIME WAIT state  the number is even less   In order to eliminate a problem you can     Increase the ephemeral port range by tuning  ip local port range  kernel option    Deploy more Grafana server instances to load balance across    Deploy more load balancer instances    Use virtual network interfaces        WebSocket and proxies  Not all proxies can transparently proxy WebSocket connections by default  For example  if you are using Nginx before Grafana you need to configure WebSocket proxy like this       http       map  http upgrade  connection upgrade           default upgrade             close             upstream grafana           server 127 0 0 1 3000             server           listen 8000           location                 proxy http version 1 1              proxy set header Upgrade  http upgrade              proxy set header Connection  connection upgrade              proxy set header Host  http host              proxy pass http   grafana                         See the  Nginx blog on their website  https   www nginx com blog websocket nginx   for more information  Also  refer to your load balancer reverse proxy documentation to find out more information on dealing with WebSocket connections   Some corporate proxies can remove headers required to properly establish a WebSocket connection  In this case  you should tune intermediate proxies to not remove required headers  However  the better option is to use Grafana with TLS  Now WebSocket connection will inherit TLS and thus must be handled transparently by proxies   Proxies like Nginx and Envoy have default limits on maximum number of connections which can be established  Make sure you have a reasonable limit for max number of incoming and outgoing connections in your proxy configuration      Configure Grafana Live HA setup  By default  Grafana Live uses in memory data structures and in memory PUB SUB hub for handling subscriptions   In a high availability Grafana setup involving several Grafana server instances behind a load balancer  you can find the following limitations     Built in features like dashboard change notifications will only be broadcasted to users connected to the same Grafana server process instance    Streaming from Telegraf will deliver data only to clients connected to the same instance which received Telegraf data  active stream cache is not shared between different Grafana instances    A separate unidirectional stream between Grafana and backend data source may be opened on different Grafana servers for the same channel   To bypass these limitations  Grafana v8 1 has an experimental Live HA engine that requires Redis to work       Configure Redis Live engine  When the Redis engine is configured  Grafana Live keeps its state in Redis and uses Redis PUB SUB functionality to deliver messages to all subscribers throughout all Grafana server nodes   Here is an example configuration        live  ha engine   redis ha engine address   127 0 0 1 6379      For additional information  refer to the  ha engine    and  ha engine address    options   After running     All built in real time notifications like dashboard changes are delivered to all Grafana server instances and broadcasted to all subscribers    Streaming from Telegraf delivers messages to all subscribers    A separate unidirectional stream between Grafana and backend data source opens on different Grafana servers  Publishing data to a channel delivers messages to instance subscribers  as a result  publications from different instances on different machines do not produce duplicate data on panels   At the moment we only support single Redis node       Note    It s possible to use Redis Sentinel and Haproxy to achieve a highly available Redis setup  Redis nodes should be managed by  Redis Sentinel  https   redis io topics sentinel  to achieve automatic failover  Haproxy configuration example            listen redis     server redis 01 127 0 0 1 6380 check port 6380 check inter 2s weight 1 inter 2s downinter 5s rise 10 fall 2 on marked down shutdown sessions on marked up shutdown backup sessions     server redis 02 127 0 0 1 6381 check port 6381 check inter 2s weight 1 inter 2s downinter 5s rise 10 fall 2 backup     bind   6379     mode tcp     option tcpka     option tcplog     option tcp check     tcp check send PING r n     tcp check expect string  PONG     tcp check send info  replication r n     tcp check expect string role master     tcp check send QUIT r n     tcp check expect string  OK     balance roundrobin           Next  point Grafana Live to Haproxy address port


grafana setup documentation Guide for configuring the Grafana Docker image installation configure docker aliases administration configure docker keywords configuration grafana docker

Answer:
---
aliases:
  - ../administration/configure-docker/
  - ../installation/configure-docker/
description: Guide for configuring the Grafana Docker image
keywords:
  - grafana
  - configuration
  - documentation
  - docker
  - docker compose
labels:
  products:
    - enterprise
    - oss
menuTitle: Configure a Docker image
title: Configure a Grafana Docker image
weight: 1800
---

# Configure a Grafana Docker image

This topic explains how to run Grafana on Docker in complex environments that require you to:

- Use different images
- Change logging levels
- Define secrets on the Cloud
- Configure plugins

> **Note:** The examples in this topic use the Grafana Enterprise Docker image. You can use the Grafana Open Source edition by changing the Docker image to `grafana/grafana-oss`.

## Supported Docker image variants

You can install and run Grafana using the following official Docker images.

- **Grafana Enterprise**: `grafana/grafana-enterprise`

- **Grafana Open Source**: `grafana/grafana-oss`

Each edition is available in two variants: Alpine and Ubuntu.

## Alpine image (recommended)

[Alpine Linux](https://alpinelinux.org/about/) is a Linux distribution not affiliated with any commercial entity. It is a versatile operating system that caters to users who prioritize security, efficiency, and user-friendliness. Alpine Linux is much smaller than other distribution base images, allowing for slimmer and more secure images to be created.

By default, the images are built using the widely used [Alpine Linux project](http://alpinelinux.org/) base image, which can be found in the [Alpine docker repo](https://hub.docker.com/_/alpine).
If you prioritize security and want to minimize the size of your image, it is recommended that you use the Alpine variant. However, it's important to note that the Alpine variant uses [musl libc](http://www.musl-libc.org/) instead of [glibc and others](http://www.etalabs.net/compare_libcs.html). As a result, some software might encounter problems depending on their libc requirements. Nonetheless, most software should not experience any issues, so the Alpine variant is generally reliable.

## Ubuntu image

The Ubuntu-based Grafana Enterprise and OSS images are built using the [Ubuntu](https://ubuntu.com/) base image, which can be found in the [Ubuntu docker repo](https://hub.docker.com/_/ubuntu). An Ubuntu-based image can be a good option for users who prefer an Ubuntu-based image or require certain tools unavailable on Alpine.

- **Grafana Enterprise**: `grafana/grafana-enterprise:<version>-ubuntu`

- **Grafana Open Source**: `grafana/grafana-oss:<version>-ubuntu`

## Run a specific version of Grafana

You can also run a specific version of Grafana or a beta version based on the main branch of the [grafana/grafana GitHub repository](https://github.com/grafana/grafana).

> **Note:** If you use a Linux operating system such as Debian or Ubuntu and encounter permission errors when running Docker commands, you might need to prefix the command with `sudo` or add your user to the `docker` group. The official Docker documentation provides instructions on how to [run Docker without a non-root user](https://docs.docker.com/engine/install/linux-postinstall/).

To run a specific version of Grafana, add it in the command <version number> section:

```bash
docker run -d -p 3000:3000 --name grafana grafana/grafana-enterprise:<version number>
```

Example:

The following command runs the Grafana Enterprise container and specifies version 9.4.7. If you want to run a different version, modify the version number section.

```bash
docker run -d -p 3000:3000 --name grafana grafana/grafana-enterprise:9.4.7
```

## Run the Grafana main branch

After every successful build of the main branch, two tags, `grafana/grafana-oss:main` and `grafana/grafana-oss:main-ubuntu`, are updated. Additionally, two new tags are created: `grafana/grafana-oss-dev:<version><build ID>-pre` and `grafana/grafana-oss-dev:<version><build ID>-pre-ubuntu`, where `version` is the next version of Grafana and `build ID `is the ID of the corresponding CI build. These tags provide access to the most recent Grafana main builds. For more information, refer to [grafana/grafana-oss-dev](https://hub.docker.com/r/grafana/grafana-oss-dev/tags).

To ensure stability and consistency, we strongly recommend using the `grafana/grafana-oss-dev:<version><build ID>-pre` tag when running the Grafana main branch in a production environment. This tag ensures that you are using a specific version of Grafana instead of the most recent commit, which could potentially introduce bugs or issues. It also avoids polluting the tag namespace for the main Grafana images with thousands of pre-release tags.

For a list of available tags, refer to [grafana/grafana-oss](https://hub.docker.com/r/grafana/grafana-oss/tags/) and [grafana/grafana-oss-dev](https://hub.docker.com/r/grafana/grafana-oss-dev/tags/).

## Default paths

Grafana comes with default configuration parameters that remain the same among versions regardless of the operating system or the environment (for example, virtual machine, Docker, Kubernetes, etc.). You can refer to the [Configure Grafana]() documentation to view all the default configuration settings.

The following configurations are set by default when you start the Grafana Docker container. When running in Docker you cannot change the configurations by editing the `conf/grafana.ini` file. Instead, you can modify the configuration using [environment variables]().

| Setting               | Default value             |
| --------------------- | ------------------------- |
| GF_PATHS_CONFIG       | /etc/grafana/grafana.ini  |
| GF_PATHS_DATA         | /var/lib/grafana          |
| GF_PATHS_HOME         | /usr/share/grafana        |
| GF_PATHS_LOGS         | /var/log/grafana          |
| GF_PATHS_PLUGINS      | /var/lib/grafana/plugins  |
| GF_PATHS_PROVISIONING | /etc/grafana/provisioning |

## Install plugins in the Docker container

You can install publicly available plugins and plugins that are private or used internally in an organization. For plugin installation instructions, refer to [Install plugins in the Docker container]().

### Install plugins from other sources

To install plugins from other sources, you must define the custom URL and specify it immediately before the plugin name in the `GF_PLUGINS_PREINSTALL` environment variable: `GF_PLUGINS_PREINSTALL=<plugin ID>@[<plugin version>]@<url to plugin zip>`.

Example:

The following command runs Grafana Enterprise on **port 3000** in detached mode and installs the custom plugin, which is specified as a URL parameter in the `GF_PLUGINS_PREINSTALL` environment variable.

```bash
docker run -d -p 3000:3000 --name=grafana \
  -e "GF_PLUGINS_PREINSTALL=custom-plugin@@http://plugin-domain.com/my-custom-plugin.zip,grafana-clock-panel" \
  grafana/grafana-enterprise
```

## Build a custom Grafana Docker image

In the Grafana GitHub repository, the `packaging/docker/custom/` folder includes a `Dockerfile` that you can use to build a custom Grafana image. The `Dockerfile` accepts `GRAFANA_VERSION`, `GF_INSTALL_PLUGINS`, and `GF_INSTALL_IMAGE_RENDERER_PLUGIN` as build arguments.

The `GRAFANA_VERSION` build argument must be a valid `grafana/grafana` Docker image tag. By default, Grafana builds an Alpine-based image. To build an Ubuntu-based image, append `-ubuntu` to the `GRAFANA_VERSION` build argument.

Example:

The following example shows you how to build and run a custom Grafana Docker image based on the latest official Ubuntu-based Grafana Docker image:

```bash
# go to the custom directory
cd packaging/docker/custom

# run the docker build command to build the image
docker build \
  --build-arg "GRAFANA_VERSION=latest-ubuntu" \
  -t grafana-custom .

# run the custom grafana container using docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom
```

### Build Grafana with the Image Renderer plugin pre-installed

> **Note:** This feature is experimental.

Currently, the Grafana Image Renderer plugin requires dependencies that are not available in the Grafana Docker image (see [GitHub Issue#301](https://github.com/grafana/grafana-image-renderer/issues/301) for more details). However, you can create a customized Docker image using the `GF_INSTALL_IMAGE_RENDERER_PLUGIN` build argument as a solution. This will install the necessary dependencies for the Grafana Image Renderer plugin to run.

Example:

The following example shows how to build a customized Grafana Docker image that includes the Image Renderer plugin.

```bash
# go to the folder
cd packaging/docker/custom

# running the build command
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_IMAGE_RENDERER_PLUGIN=true" \
  -t grafana-custom .

# running the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom
```

### Build a Grafana Docker image with pre-installed plugins

If you run multiple Grafana installations with the same plugins, you can save time by building a customized image that includes plugins available on the [Grafana Plugin download page](/grafana/plugins). When you build a customized image, Grafana doesn't have to install the plugins each time it starts, making the startup process more efficient.

> **Note:** To specify the version of a plugin, you can use the `GF_INSTALL_PLUGINS` build argument and add the version number. The latest version is used if you don't specify a version number. For example, you can use `--build-arg "GF_INSTALL_PLUGINS=grafana-clock-panel 1.0.1,grafana-simple-json-datasource 1.3.5"` to specify the versions of two plugins.

Example:

The following example shows how to build and run a custom Grafana Docker image with pre-installed plugins.

```bash
# go to the custom directory
cd packaging/docker/custom

# running the build command
# include the plugins you want e.g. clock planel etc
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-simple-json-datasource" \
  -t grafana-custom .

# running the custom Grafana container using the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom
```

### Build a Grafana Docker image with pre-installed plugins from other sources

You can create a Docker image containing a plugin that is exclusive to your organization, even if it is not accessible to the public. Simply use the `GF_INSTALL_PLUGINS` build argument to specify the plugin's URL and installation folder name, such as `GF_INSTALL_PLUGINS=<url to plugin zip>;<plugin install folder name>`.

The following example demonstrates creating a customized Grafana Docker image that includes a custom plugin from a URL link, the clock panel plugin, and the simple-json-datasource plugin. You can define these plugins in the build argument using the Grafana Plugin environment variable.

```bash
# go to the folder
cd packaging/docker/custom

# running the build command
docker build \
  --build-arg "GRAFANA_VERSION=latest" \
  --build-arg "GF_INSTALL_PLUGINS=http://plugin-domain.com/my-custom-plugin.zip;my-custom-plugin,grafana-clock-panel,grafana-simple-json-datasource" \
  -t grafana-custom .

# running the docker run command
docker run -d -p 3000:3000 --name=grafana grafana-custom
```

## Logging

By default, Docker container logs are directed to `STDOUT`, a common practice in the Docker community. You can change this by setting a different [log mode]() such as `console`, `file`, or `syslog`. You can use one or more modes by separating them with spaces, for example, `console file`. By default, both `console` and `file` modes are enabled.

Example:

The following example runs Grafana using the `console file` log mode that is set in the `GF_LOG_MODE` environment variable.

```bash
# Run Grafana while logging to both standard out
# and /var/log/grafana/grafana.log

docker run -p 3000:3000 -e "GF_LOG_MODE=console file" grafana/grafana-enterprise
```

## Configure Grafana with Docker Secrets

You can input confidential data like login credentials and secrets into Grafana using configuration files. This method works well with [Docker Secrets](https://docs.docker.com/engine/swarm/secrets/), as the secrets are automatically mapped to the `/run/secrets/` location within the container.

You can apply this technique to any configuration options in `conf/grafana.ini` by setting `GF_<SectionName>_<KeyName>__FILE` to the file path that contains the secret information. For more information about Docker secret command usage, refer to [docker secret](https://docs.docker.com/engine/reference/commandline/secret/).

The following example demonstrates how to set the admin password:

- Admin password secret: `/run/secrets/admin_password`
- Environment variable: `GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/admin_password`

### Configure Docker secrets credentials for AWS CloudWatch

Grafana ships with built-in support for the [Amazon CloudWatch datasource](). To configure the data source, you must provide information such as the AWS ID-Key, secret access key, region, and so on. You can use Docker secrets as a way to provide this information.

Example:

The example below shows how to use Grafana environment variables via Docker Secrets for the AWS ID-Key, secret access key, region, and profile.

The example uses the following values for the AWS Cloudwatch data source:

```bash
AWS_default_ACCESS_KEY_ID=aws01us02
AWS_default_SECRET_ACCESS_KEY=topsecret9b78c6
AWS_default_REGION=us-east-1
```

1. Create a Docker secret for each of the values noted above.

   ```bash
   echo "aws01us02" | docker secret create aws_access_key_id -
   ```

   ```bash
   echo "topsecret9b78c6" | docker secret create aws_secret_access_key -
   ```

   ```bash
   echo "us-east-1" | docker secret create aws_region -
   ```

1. Run the following command to determine that the secrets were created.

   ```bash
   $ docker secret ls
   ```

   The output from the command should look similar to the following:

   ```
   ID                          NAME           DRIVER    CREATED              UPDATED
   i4g62kyuy80lnti5d05oqzgwh   aws_access_key_id             5 minutes ago        5 minutes ago
   uegit5plcwodp57fxbqbnke7h   aws_secret_access_key         3 minutes ago        3 minutes ago
   fxbqbnke7hplcwodp57fuegit   aws_region                    About a minute ago   About a minute ago
   ```

   Where:

   ID = the secret unique ID that will be use in the docker run command

   NAME = the logical name defined for each secret

1. Add the secrets to the command line when you run Docker.

   ```bash
   docker run -d -p 3000:3000 --name grafana \
     -e "GF_DEFAULT_INSTANCE_NAME=my-grafana" \
     -e "GF_AWS_PROFILES=default" \
     -e "GF_AWS_default_ACCESS_KEY_ID__FILE=/run/secrets/aws_access_key_id" \
     -e "GF_AWS_default_SECRET_ACCESS_KEY__FILE=/run/secrets/aws_secret_access_key" \
     -e "GF_AWS_default_REGION__FILE=/run/secrets/aws_region" \
     -v grafana-data:/var/lib/grafana \
     grafana/grafana-enterprise
   ```

You can also specify multiple profiles to `GF_AWS_PROFILES` (for example, `GF_AWS_PROFILES=default another`).

The following list includes the supported environment variables:

- `GF_AWS_${profile}_ACCESS_KEY_ID`: AWS access key ID (required).
- `GF_AWS_${profile}_SECRET_ACCESS_KEY`: AWS secret access key (required).
- `GF_AWS_${profile}_REGION`: AWS region (optional).

## Troubleshoot a Docker deployment

By default, the Grafana log level is set to `INFO`, but you can increase the log level to `DEBUG` mode when you want to reproduce a problem.

For more information about logging, refer to [logs]().

### Increase log level using the Docker run (CLI) command

To increase the log level to `DEBUG` mode, add the environment variable `GF_LOG_LEVEL` to the command line.

```bash
docker run -d -p 3000:3000 --name=grafana \
  -e "GF_LOG_LEVEL=debug" \
  grafana/grafana-enterprise
```

### Increase log level using the Docker Compose

To increase the log level to `DEBUG` mode, add the environment variable `GF_LOG_LEVEL` to the `docker-compose.yaml` file.

```yaml
version: '3.8'
services:
  grafana:
    image: grafana/grafana-enterprise
    container_name: grafana
    restart: unless-stopped
    environment:
      # increases the log level from info to debug
      - GF_LOG_LEVEL=debug
    ports:
      - '3000:3000'
    volumes:
      - 'grafana_storage:/var/lib/grafana'
volumes:
  grafana_storage: {}
```

### Validate Docker Compose YAML file

The chance of syntax errors appearing in a YAML file increases as the file becomes more complex. You can use the following command to check for syntax errors.

```bash
# go to your docker-compose.yaml directory
cd /path-to/docker-compose/file

# run the validation command
docker compose config
```

If there are errors in the YAML file, the command output highlights the lines that contain errors. If there are no errors in the YAML file, the output includes the content of the `docker-compose.yaml` file in detailed YAML format.

aliases         administration configure docker         installation configure docker  description  Guide for configuring the Grafana Docker image keywords      grafana     configuration     documentation     docker     docker compose labels    products        enterprise       oss menuTitle  Configure a Docker image title  Configure a Grafana Docker image weight  1800        Configure a Grafana Docker image  This topic explains how to run Grafana on Docker in complex environments that require you to     Use different images   Change logging levels   Define secrets on the Cloud   Configure plugins      Note    The examples in this topic use the Grafana Enterprise Docker image  You can use the Grafana Open Source edition by changing the Docker image to  grafana grafana oss       Supported Docker image variants  You can install and run Grafana using the following official Docker images       Grafana Enterprise     grafana grafana enterprise       Grafana Open Source     grafana grafana oss   Each edition is available in two variants  Alpine and Ubuntu      Alpine image  recommended    Alpine Linux  https   alpinelinux org about   is a Linux distribution not affiliated with any commercial entity  It is a versatile operating system that caters to users who prioritize security  efficiency  and user friendliness  Alpine Linux is much smaller than other distribution base images  allowing for slimmer and more secure images to be created   By default  the images are built using the widely used  Alpine Linux project  http   alpinelinux org   base image  which can be found in the  Alpine docker repo  https   hub docker com   alpine   If you prioritize security and want to minimize the size of your image  it is recommended that you use the Alpine variant  However  it s important to note that the Alpine variant uses  musl libc  http   www musl libc org   instead of  glibc and others  http   www etalabs net compare libcs html   As a result  some software might encounter problems depending on their libc requirements  Nonetheless  most software should not experience any issues  so the Alpine variant is generally reliable      Ubuntu image  The Ubuntu based Grafana Enterprise and OSS images are built using the  Ubuntu  https   ubuntu com   base image  which can be found in the  Ubuntu docker repo  https   hub docker com   ubuntu   An Ubuntu based image can be a good option for users who prefer an Ubuntu based image or require certain tools unavailable on Alpine       Grafana Enterprise     grafana grafana enterprise  version  ubuntu       Grafana Open Source     grafana grafana oss  version  ubuntu      Run a specific version of Grafana  You can also run a specific version of Grafana or a beta version based on the main branch of the  grafana grafana GitHub repository  https   github com grafana grafana        Note    If you use a Linux operating system such as Debian or Ubuntu and encounter permission errors when running Docker commands  you might need to prefix the command with  sudo  or add your user to the  docker  group  The official Docker documentation provides instructions on how to  run Docker without a non root user  https   docs docker com engine install linux postinstall     To run a specific version of Grafana  add it in the command  version number  section      bash docker run  d  p 3000 3000   name grafana grafana grafana enterprise  version number       Example   The following command runs the Grafana Enterprise container and specifies version 9 4 7  If you want to run a different version  modify the version number section      bash docker run  d  p 3000 3000   name grafana grafana grafana enterprise 9 4 7         Run the Grafana main branch  After every successful build of the main branch  two tags   grafana grafana oss main  and  grafana grafana oss main ubuntu   are updated  Additionally  two new tags are created   grafana grafana oss dev  version  build ID  pre  and  grafana grafana oss dev  version  build ID  pre ubuntu   where  version  is the next version of Grafana and  build ID  is the ID of the corresponding CI build  These tags provide access to the most recent Grafana main builds  For more information  refer to  grafana grafana oss dev  https   hub docker com r grafana grafana oss dev tags    To ensure stability and consistency  we strongly recommend using the  grafana grafana oss dev  version  build ID  pre  tag when running the Grafana main branch in a production environment  This tag ensures that you are using a specific version of Grafana instead of the most recent commit  which could potentially introduce bugs or issues  It also avoids polluting the tag namespace for the main Grafana images with thousands of pre release tags   For a list of available tags  refer to  grafana grafana oss  https   hub docker com r grafana grafana oss tags   and  grafana grafana oss dev  https   hub docker com r grafana grafana oss dev tags        Default paths  Grafana comes with default configuration parameters that remain the same among versions regardless of the operating system or the environment  for example  virtual machine  Docker  Kubernetes  etc    You can refer to the  Configure Grafana    documentation to view all the default configuration settings   The following configurations are set by default when you start the Grafana Docker container  When running in Docker you cannot change the configurations by editing the  conf grafana ini  file  Instead  you can modify the configuration using  environment variables        Setting                 Default value                                                                       GF PATHS CONFIG          etc grafana grafana ini      GF PATHS DATA            var lib grafana              GF PATHS HOME            usr share grafana            GF PATHS LOGS            var log grafana              GF PATHS PLUGINS         var lib grafana plugins      GF PATHS PROVISIONING    etc grafana provisioning       Install plugins in the Docker container  You can install publicly available plugins and plugins that are private or used internally in an organization  For plugin installation instructions  refer to  Install plugins in the Docker container          Install plugins from other sources  To install plugins from other sources  you must define the custom URL and specify it immediately before the plugin name in the  GF PLUGINS PREINSTALL  environment variable   GF PLUGINS PREINSTALL  plugin ID    plugin version    url to plugin zip     Example   The following command runs Grafana Enterprise on   port 3000   in detached mode and installs the custom plugin  which is specified as a URL parameter in the  GF PLUGINS PREINSTALL  environment variable      bash docker run  d  p 3000 3000   name grafana      e  GF PLUGINS PREINSTALL custom plugin  http   plugin domain com my custom plugin zip grafana clock panel      grafana grafana enterprise         Build a custom Grafana Docker image  In the Grafana GitHub repository  the  packaging docker custom   folder includes a  Dockerfile  that you can use to build a custom Grafana image  The  Dockerfile  accepts  GRAFANA VERSION    GF INSTALL PLUGINS   and  GF INSTALL IMAGE RENDERER PLUGIN  as build arguments   The  GRAFANA VERSION  build argument must be a valid  grafana grafana  Docker image tag  By default  Grafana builds an Alpine based image  To build an Ubuntu based image  append   ubuntu  to the  GRAFANA VERSION  build argument   Example   The following example shows you how to build and run a custom Grafana Docker image based on the latest official Ubuntu based Grafana Docker image      bash   go to the custom directory cd packaging docker custom    run the docker build command to build the image docker build       build arg  GRAFANA VERSION latest ubuntu       t grafana custom      run the custom grafana container using docker run command docker run  d  p 3000 3000   name grafana grafana custom          Build Grafana with the Image Renderer plugin pre installed      Note    This feature is experimental   Currently  the Grafana Image Renderer plugin requires dependencies that are not available in the Grafana Docker image  see  GitHub Issue 301  https   github com grafana grafana image renderer issues 301  for more details   However  you can create a customized Docker image using the  GF INSTALL IMAGE RENDERER PLUGIN  build argument as a solution  This will install the necessary dependencies for the Grafana Image Renderer plugin to run   Example   The following example shows how to build a customized Grafana Docker image that includes the Image Renderer plugin      bash   go to the folder cd packaging docker custom    running the build command docker build       build arg  GRAFANA VERSION latest        build arg  GF INSTALL IMAGE RENDERER PLUGIN true       t grafana custom      running the docker run command docker run  d  p 3000 3000   name grafana grafana custom          Build a Grafana Docker image with pre installed plugins  If you run multiple Grafana installations with the same plugins  you can save time by building a customized image that includes plugins available on the  Grafana Plugin download page   grafana plugins   When you build a customized image  Grafana doesn t have to install the plugins each time it starts  making the startup process more efficient       Note    To specify the version of a plugin  you can use the  GF INSTALL PLUGINS  build argument and add the version number  The latest version is used if you don t specify a version number  For example  you can use    build arg  GF INSTALL PLUGINS grafana clock panel 1 0 1 grafana simple json datasource 1 3 5   to specify the versions of two plugins   Example   The following example shows how to build and run a custom Grafana Docker image with pre installed plugins      bash   go to the custom directory cd packaging docker custom    running the build command   include the plugins you want e g  clock planel etc docker build       build arg  GRAFANA VERSION latest        build arg  GF INSTALL PLUGINS grafana clock panel grafana simple json datasource       t grafana custom      running the custom Grafana container using the docker run command docker run  d  p 3000 3000   name grafana grafana custom          Build a Grafana Docker image with pre installed plugins from other sources  You can create a Docker image containing a plugin that is exclusive to your organization  even if it is not accessible to the public  Simply use the  GF INSTALL PLUGINS  build argument to specify the plugin s URL and installation folder name  such as  GF INSTALL PLUGINS  url to plugin zip   plugin install folder name     The following example demonstrates creating a customized Grafana Docker image that includes a custom plugin from a URL link  the clock panel plugin  and the simple json datasource plugin  You can define these plugins in the build argument using the Grafana Plugin environment variable      bash   go to the folder cd packaging docker custom    running the build command docker build       build arg  GRAFANA VERSION latest        build arg  GF INSTALL PLUGINS http   plugin domain com my custom plugin zip my custom plugin grafana clock panel grafana simple json datasource       t grafana custom      running the docker run command docker run  d  p 3000 3000   name grafana grafana custom         Logging  By default  Docker container logs are directed to  STDOUT   a common practice in the Docker community  You can change this by setting a different  log mode    such as  console    file   or  syslog   You can use one or more modes by separating them with spaces  for example   console file   By default  both  console  and  file  modes are enabled   Example   The following example runs Grafana using the  console file  log mode that is set in the  GF LOG MODE  environment variable      bash   Run Grafana while logging to both standard out   and  var log grafana grafana log  docker run  p 3000 3000  e  GF LOG MODE console file  grafana grafana enterprise         Configure Grafana with Docker Secrets  You can input confidential data like login credentials and secrets into Grafana using configuration files  This method works well with  Docker Secrets  https   docs docker com engine swarm secrets    as the secrets are automatically mapped to the   run secrets   location within the container   You can apply this technique to any configuration options in  conf grafana ini  by setting  GF  SectionName   KeyName   FILE  to the file path that contains the secret information  For more information about Docker secret command usage  refer to  docker secret  https   docs docker com engine reference commandline secret     The following example demonstrates how to set the admin password     Admin password secret    run secrets admin password    Environment variable   GF SECURITY ADMIN PASSWORD  FILE  run secrets admin password       Configure Docker secrets credentials for AWS CloudWatch  Grafana ships with built in support for the  Amazon CloudWatch datasource     To configure the data source  you must provide information such as the AWS ID Key  secret access key  region  and so on  You can use Docker secrets as a way to provide this information   Example   The example below shows how to use Grafana environment variables via Docker Secrets for the AWS ID Key  secret access key  region  and profile   The example uses the following values for the AWS Cloudwatch data source      bash AWS default ACCESS KEY ID aws01us02 AWS default SECRET ACCESS KEY topsecret9b78c6 AWS default REGION us east 1      1  Create a Docker secret for each of the values noted above         bash    echo  aws01us02    docker secret create aws access key id                 bash    echo  topsecret9b78c6    docker secret create aws secret access key                 bash    echo  us east 1    docker secret create aws region           1  Run the following command to determine that the secrets were created         bash      docker secret ls            The output from the command should look similar to the following             ID                          NAME           DRIVER    CREATED              UPDATED    i4g62kyuy80lnti5d05oqzgwh   aws access key id             5 minutes ago        5 minutes ago    uegit5plcwodp57fxbqbnke7h   aws secret access key         3 minutes ago        3 minutes ago    fxbqbnke7hplcwodp57fuegit   aws region                    About a minute ago   About a minute ago            Where      ID   the secret unique ID that will be use in the docker run command     NAME   the logical name defined for each secret  1  Add the secrets to the command line when you run Docker         bash    docker run  d  p 3000 3000   name grafana         e  GF DEFAULT INSTANCE NAME my grafana          e  GF AWS PROFILES default          e  GF AWS default ACCESS KEY ID  FILE  run secrets aws access key id          e  GF AWS default SECRET ACCESS KEY  FILE  run secrets aws secret access key          e  GF AWS default REGION  FILE  run secrets aws region          v grafana data  var lib grafana        grafana grafana enterprise         You can also specify multiple profiles to  GF AWS PROFILES   for example   GF AWS PROFILES default another     The following list includes the supported environment variables      GF AWS   profile  ACCESS KEY ID   AWS access key ID  required      GF AWS   profile  SECRET ACCESS KEY   AWS secret access key  required      GF AWS   profile  REGION   AWS region  optional       Troubleshoot a Docker deployment  By default  the Grafana log level is set to  INFO   but you can increase the log level to  DEBUG  mode when you want to reproduce a problem   For more information about logging  refer to  logs          Increase log level using the Docker run  CLI  command  To increase the log level to  DEBUG  mode  add the environment variable  GF LOG LEVEL  to the command line      bash docker run  d  p 3000 3000   name grafana      e  GF LOG LEVEL debug      grafana grafana enterprise          Increase log level using the Docker Compose  To increase the log level to  DEBUG  mode  add the environment variable  GF LOG LEVEL  to the  docker compose yaml  file      yaml version   3 8  services    grafana      image  grafana grafana enterprise     container name  grafana     restart  unless stopped     environment          increases the log level from info to debug         GF LOG LEVEL debug     ports           3000 3000      volumes           grafana storage  var lib grafana  volumes    grafana storage              Validate Docker Compose YAML file  The chance of syntax errors appearing in a YAML file increases as the file becomes more complex  You can use the following command to check for syntax errors      bash   go to your docker compose yaml directory cd  path to docker compose file    run the validation command docker compose config      If there are errors in the YAML file  the command output highlights the lines that contain errors  If there are no errors in the YAML file  the output includes the content of the  docker compose yaml  file in detailed YAML format


grafana setup administration jaeger instrumentation Jaeger traces emitted and propagation by Grafana administration view server internal metrics tracing jaeger aliases keywords admin metrics grafana

Answer:
---
aliases:
  - ../admin/metrics/
  - ../administration/jaeger-instrumentation/
  - ../administration/view-server/internal-metrics/
description: Jaeger traces emitted and propagation by Grafana
keywords:
  - grafana
  - jaeger
  - tracing
labels:
  products:
    - enterprise
    - oss
title: Set up Grafana monitoring
weight: 800
---

# Set up Grafana monitoring

Grafana supports tracing.

Grafana can emit Jaeger or OpenTelemetry Protocol (OTLP) traces for its HTTP API endpoints and propagate Jaeger and [w3c Trace Context](https://www.w3.org/TR/trace-context/) trace information to compatible data sources.
All HTTP endpoints are logged evenly (annotations, dashboard, tags, and so on).
When a trace ID is propagated, it is reported with operation 'HTTP /datasources/proxy/:id/\*'.

Refer to [Configuration's OpenTelemetry section]() for a reference of tracing options available in Grafana.

## View Grafana internal metrics

Grafana collects some metrics about itself internally. Grafana supports pushing metrics to Graphite or exposing them to be scraped by Prometheus.

For more information about configuration options related to Grafana metrics, refer to [metrics]() and [metrics.graphite]() in [Configuration]().

### Available metrics

When enabled, Grafana exposes a number of metrics, including:

- Active Grafana instances
- Number of dashboards, users, and playlists
- HTTP status codes
- Requests by routing group
- Grafana active alerts
- Grafana performance

### Pull metrics from Grafana into Prometheus

These instructions assume you have already added Prometheus as a data source in Grafana.

1. Enable Prometheus to scrape metrics from Grafana. In your configuration file (`grafana.ini` or `custom.ini` depending on your operating system) remove the semicolon to enable the following configuration options:

   ```
   # Metrics available at HTTP URL /metrics and /metrics/plugins/:pluginId
   [metrics]
   # Disable / Enable internal metrics
   enabled           = true

   # Disable total stats (stat_totals_*) metrics to be generated
   disable_total_stats = false
   ```

1. (optional) If you want to require authorization to view the metrics endpoints, then uncomment and set the following options:

   ```
   basic_auth_username =
   basic_auth_password =
   ```

1. Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics.
1. Add the job to your prometheus.yml file.
   Example:

   ```
   - job_name: 'grafana_metrics'

      scrape_interval: 15s
      scrape_timeout: 5s

      static_configs:
        - targets: ['localhost:3000']
   ```

1. Restart Prometheus. Your new job should appear on the Targets tab.
1. In Grafana, click **Connections** in the left-side menu.
1. Under your connections, click **Data Sources**.
1. Select the **Prometheus** data source.
1. Under the name of your data source, click **Dashboards**.
1. On the Dashboards tab, click **Import** in the _Grafana metrics_ row to import the Grafana metrics dashboard. All scraped Grafana metrics are available in the dashboard.

### View Grafana metrics in Graphite

These instructions assume you have already added Graphite as a data source in Grafana.

1. Enable sending metrics to Graphite. In your configuration file (`grafana.ini` or `custom.ini` depending on your operating system) remove the semicolon to enable the following configuration options:

   ```
   # Metrics available at HTTP API Url /metrics
   [metrics]
   # Disable / Enable internal metrics
   enabled           = true

   # Disable total stats (stat_totals_*) metrics to be generated
   disable_total_stats = false
   ```

1. Enable [metrics.graphite] options:

   ```
   # Send internal metrics to Graphite
   [metrics.graphite]
   # Enable by setting the address setting (ex localhost:2003)
   address = <hostname or ip>:<port#>
   prefix = prod.grafana.%(instance_name)s.
   ```

1. Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics and sends them to the Graphite location you specified.

### Pull metrics from Grafana backend plugin into Prometheus

Any installed [backend plugin](https://grafana.com/developers/plugin-tools/key-concepts/backend-plugins/) exposes a metrics endpoint through Grafana that you can configure Prometheus to scrape.

These instructions assume you have already added Prometheus as a data source in Grafana.

1. Enable Prometheus to scrape backend plugin metrics from Grafana. In your configuration file (`grafana.ini` or `custom.ini` depending on your operating system) remove the semicolon to enable the following configuration options:

   ```
   # Metrics available at HTTP URL /metrics and /metrics/plugins/:pluginId
   [metrics]
   # Disable / Enable internal metrics
   enabled           = true

   # Disable total stats (stat_totals_*) metrics to be generated
   disable_total_stats = false
   ```

1. (optional) If you want to require authorization to view the metrics endpoints, then uncomment and set the following options:

   ```
   basic_auth_username =
   basic_auth_password =
   ```

1. Restart Grafana. Grafana now exposes metrics at `http://localhost:3000/metrics/plugins/<plugin id>`, e.g. http://localhost:3000/metrics/plugins/grafana-github-datasource if you have the [Grafana GitHub datasource](/grafana/plugins/grafana-github-datasource/) installed.
1. Add the job to your prometheus.yml file.
   Example:

   ```
   - job_name: 'grafana_github_datasource'

      scrape_interval: 15s
      scrape_timeout: 5s
      metrics_path: /metrics/plugins/grafana-test-datasource

      static_configs:
        - targets: ['localhost:3000']
   ```

1. Restart Prometheus. Your new job should appear on the Targets tab.
1. In Grafana, hover your mouse over the **Configuration** (gear) icon on the left sidebar and then click **Data Sources**.
1. Select the **Prometheus** data source.
1. Import a Golang application metrics dashboard - for example [Go Processes](/grafana/dashboards/6671).

aliases         admin metrics         administration jaeger instrumentation         administration view server internal metrics  description  Jaeger traces emitted and propagation by Grafana keywords      grafana     jaeger     tracing labels    products        enterprise       oss title  Set up Grafana monitoring weight  800        Set up Grafana monitoring  Grafana supports tracing   Grafana can emit Jaeger or OpenTelemetry Protocol  OTLP  traces for its HTTP API endpoints and propagate Jaeger and  w3c Trace Context  https   www w3 org TR trace context   trace information to compatible data sources  All HTTP endpoints are logged evenly  annotations  dashboard  tags  and so on   When a trace ID is propagated  it is reported with operation  HTTP  datasources proxy  id       Refer to  Configuration s OpenTelemetry section    for a reference of tracing options available in Grafana      View Grafana internal metrics  Grafana collects some metrics about itself internally  Grafana supports pushing metrics to Graphite or exposing them to be scraped by Prometheus   For more information about configuration options related to Grafana metrics  refer to  metrics    and  metrics graphite    in  Configuration          Available metrics  When enabled  Grafana exposes a number of metrics  including     Active Grafana instances   Number of dashboards  users  and playlists   HTTP status codes   Requests by routing group   Grafana active alerts   Grafana performance      Pull metrics from Grafana into Prometheus  These instructions assume you have already added Prometheus as a data source in Grafana   1  Enable Prometheus to scrape metrics from Grafana  In your configuration file   grafana ini  or  custom ini  depending on your operating system  remove the semicolon to enable the following configuration options               Metrics available at HTTP URL  metrics and  metrics plugins  pluginId     metrics       Disable   Enable internal metrics    enabled             true       Disable total stats  stat totals    metrics to be generated    disable total stats   false         1   optional  If you want to require authorization to view the metrics endpoints  then uncomment and set the following options             basic auth username      basic auth password           1  Restart Grafana  Grafana now exposes metrics at http   localhost 3000 metrics  1  Add the job to your prometheus yml file     Example               job name   grafana metrics         scrape interval  15s       scrape timeout  5s        static configs            targets    localhost 3000           1  Restart Prometheus  Your new job should appear on the Targets tab  1  In Grafana  click   Connections   in the left side menu  1  Under your connections  click   Data Sources    1  Select the   Prometheus   data source  1  Under the name of your data source  click   Dashboards    1  On the Dashboards tab  click   Import   in the  Grafana metrics  row to import the Grafana metrics dashboard  All scraped Grafana metrics are available in the dashboard       View Grafana metrics in Graphite  These instructions assume you have already added Graphite as a data source in Grafana   1  Enable sending metrics to Graphite  In your configuration file   grafana ini  or  custom ini  depending on your operating system  remove the semicolon to enable the following configuration options               Metrics available at HTTP API Url  metrics     metrics       Disable   Enable internal metrics    enabled             true       Disable total stats  stat totals    metrics to be generated    disable total stats   false         1  Enable  metrics graphite  options               Send internal metrics to Graphite     metrics graphite       Enable by setting the address setting  ex localhost 2003     address    hostname or ip   port      prefix   prod grafana   instance name s          1  Restart Grafana  Grafana now exposes metrics at http   localhost 3000 metrics and sends them to the Graphite location you specified       Pull metrics from Grafana backend plugin into Prometheus  Any installed  backend plugin  https   grafana com developers plugin tools key concepts backend plugins   exposes a metrics endpoint through Grafana that you can configure Prometheus to scrape   These instructions assume you have already added Prometheus as a data source in Grafana   1  Enable Prometheus to scrape backend plugin metrics from Grafana  In your configuration file   grafana ini  or  custom ini  depending on your operating system  remove the semicolon to enable the following configuration options               Metrics available at HTTP URL  metrics and  metrics plugins  pluginId     metrics       Disable   Enable internal metrics    enabled             true       Disable total stats  stat totals    metrics to be generated    disable total stats   false         1   optional  If you want to require authorization to view the metrics endpoints  then uncomment and set the following options             basic auth username      basic auth password           1  Restart Grafana  Grafana now exposes metrics at  http   localhost 3000 metrics plugins  plugin id    e g  http   localhost 3000 metrics plugins grafana github datasource if you have the  Grafana GitHub datasource   grafana plugins grafana github datasource   installed  1  Add the job to your prometheus yml file     Example               job name   grafana github datasource         scrape interval  15s       scrape timeout  5s       metrics path   metrics plugins grafana test datasource        static configs            targets    localhost 3000           1  Restart Prometheus  Your new job should appear on the Targets tab  1  In Grafana  hover your mouse over the   Configuration    gear  icon on the left sidebar and then click   Data Sources    1  Select the   Prometheus   data source  1  Import a Golang application metrics dashboard   for example  Go Processes   grafana dashboards 6671