Set up Grafana on Grafana Labs

Install Grafana

Fri, 07 Mar 2025 11:34:44 +0100

Install Grafana

This page lists the minimum hardware and software requirements to install Grafana.

To run Grafana, you must have a supported operating system, hardware that meets or exceeds minimum requirements, a supported database, and a supported browser.

Grafana relies on other open source software to operate. For a list of open source software that Grafana uses, refer to package.json.

Supported operating systems

Grafana supports the following operating systems:

Note
Installation of Grafana on other operating systems is possible, but is not recommended or supported.

Hardware recommendations

Grafana requires the minimum system resources:

Minimum recommended memory: 255 MB
Minimum recommended CPU: 1

Some features might require more memory or CPUs, including:

Supported databases

Grafana requires a database to store its configuration data, such as users, data sources, and dashboards. The exact requirements depend on the size of the Grafana installation and the features you use.

Grafana supports the following databases:

By default Grafana uses an embedded SQLite database, which is stored in the Grafana installation location.

Note
SQLite works well if your environment is small, but is not recommended when your environment starts growing. For more information about the limitations of SQLite, refer to Appropriate Uses For SQLite. If you want high availability, you must use either a MySQL or PostgreSQL database. For information about how to define the database configuration parameters inside the grafana.ini file, refer to [database].

Grafana supports the versions of these databases that are officially supported by the project at the time a version of Grafana is released. When a Grafana version becomes unsupported, Grafana Labs might also drop support for that database version. See the links above for the support policies for each project.

Note
PostgreSQL versions 10.9, 11.4, and 12-beta2 are affected by a bug (tracked by the PostgreSQL project as bug #15865) which prevents those versions from being used with Grafana. The bug has been fixed in more recent versions of PostgreSQL.

Grafana can report errors when relying on read-only MySQL servers, such as in high-availability failover scenarios or serverless AWS Aurora MySQL. This is a known issue; for more information, see issue #13399.

Supported web browsers

Grafana supports the current version of the following browsers. Older versions of these browsers might not be supported, so you should always upgrade to the latest browser version when using Grafana.

Note
Enable JavaScript in your browser. Running Grafana without JavaScript enabled in the browser is not supported.

Chrome/Chromium
Firefox
Safari
Microsoft Edge

Configure Grafana

Fri, 07 Mar 2025 11:34:44 +0100

Configure Grafana

Grafana has default and custom configuration files. You can customize your Grafana instance by modifying the custom configuration file or by using environment variables. To see the list of settings for a Grafana instance, refer to View server settings.

Note
After you add custom options, uncomment the relevant sections of the configuration file. Restart Grafana for your changes to take effect.

Configuration file location

The default settings for a Grafana instance are stored in the $WORKING_DIR/conf/defaults.ini file. Do not change this file.

Depending on your OS, your custom configuration file is either the $WORKING_DIR/conf/custom.ini file or the /usr/local/etc/grafana/grafana.ini file. The custom configuration file path can be overridden using the --config parameter.

Linux

If you installed Grafana using the deb or rpm packages, then your configuration file is located at /etc/grafana/grafana.ini and a separate custom.ini is not used. This path is specified in the Grafana init.d script using --config file parameter.

Docker

Refer to Configure a Grafana Docker image for information about environmental variables, persistent storage, and building custom Docker images.

Windows

On Windows, the sample.ini file is located in the same directory as defaults.ini file. It contains all the settings commented out. Copy sample.ini and name it custom.ini.

macOS

By default, the configuration file is located at /usr/local/etc/grafana/grafana.ini. For a Grafana instance installed using Homebrew, edit the grafana.ini file directly. Otherwise, add a configuration file named custom.ini to the conf folder to override the settings defined in conf/defaults.ini.

Remove comments in the .ini files

Grafana uses semicolons (the ; char) to comment out lines in a .ini file. You must uncomment each line in the custom.ini or the grafana.ini file that you are modify by removing ; from the beginning of that line. Otherwise your changes will be ignored.

For example:

# The HTTP port  to use
;http_port = 3000

Override configuration with environment variables

Do not use environment variables to add new configuration settings. Instead, use environmental variables to override existing options.

To override an option:

GF_<SectionName>_<KeyName>

Where the section name is the text within the brackets. Everything should be uppercase, . and - should be replaced by _. For example, if you have these configuration settings:

# default section
instance_name = ${HOSTNAME}

[security]
admin_user = admin

[auth.google]
client_secret = 0ldS3cretKey

[plugin.grafana-image-renderer]
rendering_ignore_https_errors = true

[feature_toggles]
enable = newNavigation

You can override variables on Linux machines with:

export GF_DEFAULT_INSTANCE_NAME=my-instance
export GF_SECURITY_ADMIN_USER=owner
export GF_AUTH_GOOGLE_CLIENT_SECRET=newS3cretKey
export GF_PLUGIN_GRAFANA_IMAGE_RENDERER_RENDERING_IGNORE_HTTPS_ERRORS=true
export GF_FEATURE_TOGGLES_ENABLE=newNavigation

Variable expansion

Note
Only available in Grafana 7.1+.

If any of your options contains the expression $__<provider>{<argument>} or ${<environment variable>}, then they will be processed by Grafana’s variable expander. The expander runs the provider with the provided argument to get the final value of the option.

There are three providers: env, file, and vault.

Env provider

The env provider can be used to expand an environment variable. If you set an option to $__env{PORT} the PORT environment variable will be used in its place. For environment variables you can also use the short-hand syntax ${PORT}. Grafana’s log directory would be set to the grafana directory in the directory behind the LOGDIR environment variable in the following example.

[paths]
logs = $__env{LOGDIR}/grafana

File provider

file reads a file from the filesystem. It trims whitespace from the beginning and the end of files. The database password in the following example would be replaced by the content of the /etc/secrets/gf_sql_password file:

[database]
password = $__file{/etc/secrets/gf_sql_password}

Vault provider

The vault provider allows you to manage your secrets with Hashicorp Vault.

Vault provider is only available in Grafana Enterprise v7.1+. For more information, refer to Vault integration in Grafana Enterprise.

app_mode

Options are production and development. Default is production. Do not change this option unless you are working on Grafana development.

instance_name

Set the name of the grafana-server instance. Used in logging, internal metrics, and clustering info. Defaults to: ${HOSTNAME}, which will be replaced with environment variable HOSTNAME, if that is empty or does not exist Grafana will try to use system calls to get the machine name.

force_migration

Force migration will run migrations that might cause data loss. Default is false.

Set force_migration=true in your grafana.ini and restart Grafana to roll back and delete Unified Alerting configuration data. Any alert rules created while using Unified Alerting will be deleted by rolling back.

[paths]

data

Path to where Grafana stores the sqlite3 database (if used), file-based sessions (if used), and other data. This path is usually specified via command line in the init.d script or the systemd service file.

macOS: The default SQLite database is located at /usr/local/var/lib/grafana

temp_data_lifetime

How long temporary images in data directory should be kept. Defaults to: 24h. Supported modifiers: h (hours), m (minutes), for example: 168h, 30m, 10h30m. Use 0 to never clean up temporary files.

logs

Path to where Grafana stores logs. This path is usually specified via command line in the init.d script or the systemd service file. You can override it in the configuration file or in the default environment variable file. However, please note that by overriding this the default log path will be used temporarily until Grafana has fully initialized/started.

Override log path using the command line argument cfg:default.paths.logs:

./grafana-server --config /custom/config.ini --homepath /custom/homepath cfg:default.paths.logs=/custom/path

macOS: By default, the log file should be located at /usr/local/var/log/grafana/grafana.log.

plugins

Directory where Grafana automatically scans and looks for plugins. For information about manually or automatically installing plugins, refer to Install Grafana plugins.

macOS: By default, the Mac plugin location is: /usr/local/var/lib/grafana/plugins.

provisioning

Folder that contains provisioning config files that Grafana will apply on startup. Dashboards will be reloaded when the json files changes.

[server]

protocol

http,https,h2 or socket

http_addr

The host for the server to listen on. If your machine has more than one network interface, you can use this setting to expose the Grafana service on only one network interface and not have it available on others, such as the loopback interface. An empty value is equivalent to setting the value to 0.0.0.0, which means the Grafana service binds to all interfaces.

In environments where network address translation (NAT) is used, ensure you use the network interface address and not a final public address; otherwise, you might see errors such as bind: cannot assign requested address in the logs.

http_port

The port to bind to, defaults to 3000. To use port 80 you need to either give the Grafana binary permission for example:

$ sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/grafana-server

Or redirect port 80 to the Grafana port using:

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3000

Another way is to put a web server like Nginx or Apache in front of Grafana and have them proxy requests to Grafana.

domain

This setting is only used in as a part of the root_url setting (see below). Important if you use GitHub or Google OAuth.

enforce_domain

Redirect to correct domain if the host header does not match the domain. Prevents DNS rebinding attacks. Default is false.

root_url

This is the full URL used to access Grafana from a web browser. This is important if you use Google or GitHub OAuth authentication (for the callback URL to be correct).

Note
This setting is also important if you have a reverse proxy in front of Grafana that exposes it through a subpath. In that case add the subpath to the end of this URL setting.

serve_from_sub_path

Serve Grafana from subpath specified in root_url setting. By default it is set to false for compatibility reasons.

By enabling this setting and using a subpath in root_url above, e.g.root_url = http://localhost:3000/grafana, Grafana is accessible on http://localhost:3000/grafana. If accessed without subpath Grafana will redirect to an URL with the subpath.

router_logging

Set to true for Grafana to log all HTTP requests (not just errors). These are logged as Info level events to the Grafana log.

static_root_path

The path to the directory where the front end files (HTML, JS, and CSS files). Defaults to public which is why the Grafana binary needs to be executed with working directory set to the installation path.

enable_gzip

Set this option to true to enable HTTP compression, this can improve transfer speed and bandwidth utilization. It is recommended that most users set it to true. By default it is set to false for compatibility reasons.

cert_file

Path to the certificate file (if protocol is set to https or h2).

cert_key

Path to the certificate key file (if protocol is set to https or h2).

socket_gid

GID where the socket should be set when protocol=socket. Make sure that the target group is in the group of Grafana process and that Grafana process is the file owner before you change this setting. It is recommended to set the gid as http server user gid. Not set when the value is -1.

socket_mode

Mode where the socket should be set when protocol=socket. Make sure that Grafana process is the file owner before you change this setting.

socket

Path where the socket should be created when protocol=socket. Make sure Grafana has appropriate permissions for that path before you change this setting.

cdn_url

Note
Available in Grafana v7.4 and later versions.

Specify a full HTTP URL address to the root of your Grafana CDN assets. Grafana will add edition and version paths.

For example, given a cdn url like https://cdn.myserver.com grafana will try to load a javascript file from http://cdn.myserver.com/grafana-oss/7.4.0/public/build/app.<hash>.js.

read_timeout

Sets the maximum time using a duration format (5s/5m/5ms) before timing out read of an incoming request and closing idle connections. 0 means there is no timeout for reading the request.

[server.custom_response_headers]

This setting enables you to specify additional headers that the server adds to HTTP(S) responses.

exampleHeader1 = exampleValue1
exampleHeader2 = exampleValue2

[database]

Grafana needs a database to store users and dashboards (and other things). By default it is configured to use sqlite3 which is an embedded database (included in the main Grafana binary).

type

Either mysql, postgres or sqlite3, it’s your choice.

host

Only applicable to MySQL or Postgres. Includes IP or hostname and port or in case of Unix sockets the path to it. For example, for MySQL running on the same host as Grafana: host = 127.0.0.1:3306 or with Unix sockets: host = /var/run/mysqld/mysqld.sock

name

The name of the Grafana database. Leave it set to grafana or some other name.

user

The database user (not applicable for sqlite3).

password

The database user’s password (not applicable for sqlite3). If the password contains # or ; you have to wrap it with triple quotes. For example """#password;"""

url

Use either URL or the other fields below to configure the database Example: mysql://user:secret@host:port/database

max_idle_conn

The maximum number of connections in the idle connection pool.

max_open_conn

The maximum number of open connections to the database.

conn_max_lifetime

Sets the maximum amount of time a connection may be reused. The default is 14400 (which means 14400 seconds or 4 hours). For MySQL, this setting should be shorter than the wait_timeout variable.

locking_attempt_timeout_sec

For “mysql”, if the migrationLocking feature toggle is set, specify the time (in seconds) to wait before failing to lock the database for the migrations. Default is 0.

log_queries

Set to true to log the sql calls and execution times.

ssl_mode

For Postgres, use either disable, require or verify-full. For MySQL, use either true, false, or skip-verify.

isolation_level

Only the MySQL driver supports isolation levels in Grafana. In case the value is empty, the driver’s default isolation level is applied. Available options are “READ-UNCOMMITTED”, “READ-COMMITTED”, “REPEATABLE-READ” or “SERIALIZABLE”.

ca_cert_path

The path to the CA certificate to use. On many Linux systems, certs can be found in /etc/ssl/certs.

client_key_path

The path to the client key. Only if server requires client authentication.

client_cert_path

The path to the client cert. Only if server requires client authentication.

server_cert_name

The common name field of the certificate used by the mysql or postgres server. Not necessary if ssl_mode is set to skip-verify.

path

Only applicable for sqlite3 database. The file path where the database will be stored.

cache_mode

For “sqlite3” only. Shared cache setting used for connecting to the database. (private, shared) Defaults to private.

wal

For “sqlite3” only. Setting to enable/disable Write-Ahead Logging. The default value is false (disabled).

query_retries

This setting applies to sqlite only and controls the number of times the system retries a query when the database is locked. The default value is 0 (disabled).

transaction_retries

This setting applies to sqlite only and controls the number of times the system retries a transaction when the database is locked. The default value is 5.

instrument_queries

Set to true to add metrics and tracing for database queries. The default value is false.

[remote_cache]

Caches authentication details and session information in the configured database, Redis or Memcached. This setting does not configure Query Caching in Grafana Enterprise.

type

Either redis, memcached, or database. Defaults to database

connstr

The remote cache connection string. The format depends on the type of the remote cache. Options are database, redis, and memcache.

database

Leave empty when using database since it will use the primary database.

redis

Example connstr: addr=127.0.0.1:6379,pool_size=100,db=0,ssl=false

addr is the host : port of the redis server.
pool_size (optional) is the number of underlying connections that can be made to redis.
db (optional) is the number identifier of the redis database you want to use.
ssl (optional) is if SSL should be used to connect to redis server. The value may be true, false, or insecure. Setting the value to insecure skips verification of the certificate chain and hostname when making the connection.

memcache

Example connstr: 127.0.0.1:11211

[dataproxy]

logging

This enables data proxy logging, default is false.

timeout

How long the data proxy should wait before timing out. Default is 30 seconds.

This setting also applies to core backend HTTP data sources where query requests use an HTTP client with timeout set.

keep_alive_seconds

Interval between keep-alive probes. Default is 30 seconds. For more details check the Dialer.KeepAlive documentation.

tls_handshake_timeout_seconds

The length of time that Grafana will wait for a successful TLS handshake with the datasource. Default is 10 seconds. For more details check the Transport.TLSHandshakeTimeout documentation.

expect_continue_timeout_seconds

The length of time that Grafana will wait for a datasource’s first response headers after fully writing the request headers, if the request has an “Expect: 100-continue” header. A value of 0 will result in the body being sent immediately. Default is 1 second. For more details check the Transport.ExpectContinueTimeout documentation.

max_conns_per_host

Optionally limits the total number of connections per host, including connections in the dialing, active, and idle states. On limit violation, dials are blocked. A value of 0 means that there are no limits. Default is 0. For more details check the Transport.MaxConnsPerHost documentation.

max_idle_connections

The maximum number of idle connections that Grafana will maintain. Default is 100. For more details check the Transport.MaxIdleConns documentation.

idle_conn_timeout_seconds

The length of time that Grafana maintains idle connections before closing them. Default is 90 seconds. For more details check the Transport.IdleConnTimeout documentation.

send_user_header

If enabled and user is not anonymous, data proxy will add X-Grafana-User header with username into the request. Default is false.

response_limit

Limits the amount of bytes that will be read/accepted from responses of outgoing HTTP requests. Default is 0 which means disabled.

row_limit

Limits the number of rows that Grafana will process from SQL (relational) data sources. Default is 1000000.

user_agent

Sets a custom value for the User-Agent header for outgoing data proxy requests. If empty, the default value is Grafana/<BuildVersion> (for example Grafana/9.0.0).

[analytics]

enabled

This option is also known as usage analytics. When false, this option disables the writers that read/write from and to the Grafana databases. The default value is true.

reporting_enabled

When enabled Grafana will send anonymous usage statistics to stats.grafana.org. No IP addresses are being tracked, only simple counters to track running instances, versions, dashboard and error counts. It is very helpful to us, so please leave this enabled. Counters are sent every 24 hours. Default value is true.

check_for_updates

Set to false, disables checking for new versions of Grafana from Grafana’s GitHub repository. When enabled, the check for a new version runs every 10 minutes. It will notify, via the UI, when a new version is available. The check itself will not prompt any auto-updates of the Grafana software, nor will it send any sensitive information.

check_for_plugin_updates

Note
Available in Grafana v8.5.0 and later versions.

Set to false disables checking for new versions of installed plugins from https://grafana.com. When enabled, the check for a new plugin runs every 10 minutes. It will notify, via the UI, when a new plugin update exists. The check itself will not prompt any auto-updates of the plugin, nor will it send any sensitive information.

google_analytics_ua_id

If you want to track Grafana usage via Google analytics specify your Universal Analytics ID here. By default this feature is disabled.

google_analytics_4_id

If you want to track Grafana usage via Google Analytics 4 specify your GA4 ID here. By default this feature is disabled.

google_tag_manager_id

Google Tag Manager ID, only enabled if you enter an ID here.

rudderstack_write_key

If you want to track Grafana usage via Rudderstack specify your Rudderstack Write Key here. The rudderstack_data_plane_url must also be provided for this feature to be enabled. By default this feature is disabled.

rudderstack_data_plane_url

Rudderstack data plane url that will receive Rudderstack events. The rudderstack_write_key must also be provided for this feature to be enabled.

rudderstack_sdk_url

Optional. If tracking with Rudderstack is enabled, you can provide a custom URL to load the Rudderstack SDK.

rudderstack_config_url

Optional. If tracking with Rudderstack is enabled, you can provide a custom URL to load the Rudderstack config.

application_insights_connection_string

If you want to track Grafana usage via Azure Application Insights, then specify your Application Insights connection string. Since the connection string contains semicolons, you need to wrap it in backticks (`). By default, tracking usage is disabled.

application_insights_endpoint_url

Optionally, use this option to override the default endpoint address for Application Insights data collecting. For details, refer to the Azure documentation.

feedback_links_enabled

Set to false to remove all feedback links from the UI. Default is true.

[security]

disable_initial_admin_creation

Only available in Grafana v6.5+.

Disable creation of admin user on first start of Grafana. Default is false.

admin_user

The name of the default Grafana Admin user, who has full permissions. Default is admin.

admin_password

The password of the default Grafana Admin. Set once on first-run. Default is admin.

admin_email

The email of the default Grafana Admin, created on startup. Default is admin@localhost.

secret_key

Used for signing some data source settings like secrets and passwords, the encryption format used is AES-256 in CFB mode. Cannot be changed without requiring an update to data source settings to re-encode them.

disable_gravatar

Set to true to disable the use of Gravatar for user profile images. Default is false.

data_source_proxy_whitelist

Define a whitelist of allowed IP addresses or domains, with ports, to be used in data source URLs with the Grafana data source proxy. Format: ip_or_domain:port separated by spaces. PostgreSQL, MySQL, and MSSQL data sources do not use the proxy and are therefore unaffected by this setting.

disable_brute_force_login_protection

Set to true to disable brute force login protection. Default is false. An existing user’s account will be locked after 5 attempts in 5 minutes.

cookie_secure

Set to true if you host Grafana behind HTTPS. Default is false.

cookie_samesite

Sets the SameSite cookie attribute and prevents the browser from sending this cookie along with cross-site requests. The main goal is to mitigate the risk of cross-origin information leakage. This setting also provides some protection against cross-site request forgery attacks (CSRF), read more about SameSite here. Valid values are lax, strict, none, and disabled. Default is lax. Using value disabled does not add any SameSite attribute to cookies.

allow_embedding

When false, the HTTP header X-Frame-Options: deny will be set in Grafana HTTP responses which will instruct browsers to not allow rendering Grafana in a <frame>, <iframe>, <embed> or <object>. The main goal is to mitigate the risk of Clickjacking. Default is false.

strict_transport_security

Set to true if you want to enable HTTP Strict-Transport-Security (HSTS) response header. Only use this when HTTPS is enabled in your configuration, or when there is another upstream system that ensures your application does HTTPS (like a frontend load balancer). HSTS tells browsers that the site should only be accessed using HTTPS.

strict_transport_security_max_age_seconds

Sets how long a browser should cache HSTS in seconds. Only applied if strict_transport_security is enabled. The default value is 86400.

strict_transport_security_preload

Set to true to enable HSTS preloading option. Only applied if strict_transport_security is enabled. The default value is false.

strict_transport_security_subdomains

Set to true to enable the HSTS includeSubDomains option. Only applied if strict_transport_security is enabled. The default value is false.

x_content_type_options

Set to false to disable the X-Content-Type-Options response header. The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. The default value is true.

x_xss_protection

Set to false to disable the X-XSS-Protection header, which tells browsers to stop pages from loading when they detect reflected cross-site scripting (XSS) attacks. The default value is true.

content_security_policy

Set to true to add the Content-Security-Policy header to your requests. CSP allows to control resources that the user agent can load and helps prevent XSS attacks.

content_security_policy_template

Set the policy template that will be used when adding the Content-Security-Policy header to your requests. $NONCE in the template includes a random nonce.

content_security_policy_report_only

Set to true to add the Content-Security-Policy-Report-Only header to your requests. CSP in Report Only mode enables you to experiment with policies by monitoring their effects without enforcing them. You can enable both policies simultaneously.

content_security_policy_template

Set the policy template that will be used when adding the Content-Security-Policy-Report-Only header to your requests. $NONCE in the template includes a random nonce.

angular_support_enabled

This currently defaults to true but will default to false in a future release. When set to false the angular framework and support components will not be loaded. This means that all plugins and core features that depend on angular support will stop working.

The core features that depend on angular are:

Old graph panel
Old table panel
Legacy alerting edit rule UI

These features each have supported alternatives, and we recommend using them.

csrf_trusted_origins

List of additional allowed URLs to pass by the CSRF check. Suggested when authentication comes from an IdP.

csrf_additional_headers

List of allowed headers to be set by the user. Suggested to use for if authentication lives behind reverse proxies.

csrf_always_check

Set to true to execute the CSRF check even if the login cookie is not in a request (default false).

[snapshots]

enabled

Set to false to disable the snapshot feature (default true).

external_enabled

Set to false to disable external snapshot publish endpoint (default true).

external_snapshot_url

Set root URL to a Grafana instance where you want to publish external snapshots (defaults to https://snapshots.raintank.io).

external_snapshot_name

Set name for external snapshot button. Defaults to Publish to snapshots.raintank.io.

public_mode

Set to true to enable this Grafana instance to act as an external snapshot server and allow unauthenticated requests for creating and deleting snapshots. Default is false.

snapshot_remove_expired

Enable this to automatically remove expired snapshots. Default is true.

[dashboards]

versions_to_keep

Number dashboard versions to keep (per dashboard). Default: 20, Minimum: 1.

min_refresh_interval

Only available in Grafana v6.7+.

This feature prevents users from setting the dashboard refresh interval to a lower value than a given interval value. The default interval value is 5 seconds. The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

As of Grafana v7.3, this also limits the refresh interval options in Explore.

default_home_dashboard_path

Path to the default home dashboard. If this value is empty, then Grafana uses StaticRootPath + “dashboards/home.json”.

Note
On Linux, Grafana uses /usr/share/grafana/public/dashboards/home.json as the default home dashboard location.

[sql_datasources]

max_open_conns_default

For SQL data sources (MySql, Postgres, MSSQL) you can override the default maximum number of open connections (default: 100). The value configured in data source settings will be preferred over the default value.

max_idle_conns_default

For SQL data sources (MySql, Postgres, MSSQL) you can override the default allowed number of idle connections (default: 100). The value configured in data source settings will be preferred over the default value.

max_conn_lifetime_default

For SQL data sources (MySql, Postgres, MSSQL) you can override the default maximum connection lifetime specified in seconds (default: 14400). The value configured in data source settings will be preferred over the default value.

[users]

allow_sign_up

Set to false to prohibit users from being able to sign up / create user accounts. Default is false. The admin user can still create users. For more information about creating a user, refer to Add a user.

allow_org_create

Set to false to prohibit users from creating new organizations. Default is false.

auto_assign_org

Set to true to automatically add new users to the main organization (id 1). When set to false, new users automatically cause a new organization to be created for that new user. The organization will be created even if the allow_org_create setting is set to false. Default is true.

auto_assign_org_id

Set this value to automatically add new users to the provided org. This requires auto_assign_org to be set to true. Please make sure that this organization already exists. Default is 1.

auto_assign_org_role

The auto_assign_org_role setting determines the default role assigned to new users in the main organization (if auto_assign_org setting is set to true). The available options are Viewer (default), Admin, Editor, and None. For example:

auto_assign_org_role = Viewer

verify_email_enabled

Require email validation before sign up completes. Default is false.

login_hint

Text used as placeholder text on login page for login/username input.

password_hint

Text used as placeholder text on login page for password input.

default_theme

Sets the default UI theme: dark, light, or system. The default theme is dark.

system matches the user’s system theme.

default_language

This setting configures the default UI language, which must be a supported IETF language tag, such as en-US.

home_page

Path to a custom home page. Users are only redirected to this if the default home dashboard is used. It should match a frontend route and contain a leading slash.

External user management

If you manage users externally you can replace the user invite button for organizations with a link to an external site together with a description.

viewers_can_edit

Viewers can access and use Explore and perform temporary edits on panels in dashboards they have access to. They cannot save their changes. Default is false.

editors_can_admin

Editors can administrate dashboards, folders and teams they create. Default is false.

user_invite_max_lifetime_duration

The duration in time a user invitation remains valid before expiring. This setting should be expressed as a duration. Examples: 6h (hours), 2d (days), 1w (week). Default is 24h (24 hours). The minimum supported duration is 15m (15 minutes).

hidden_users

This is a comma-separated list of usernames. Users specified here are hidden in the Grafana UI. They are still visible to Grafana administrators and to themselves.

[auth]

Grafana provides many ways to authenticate users. Refer to the Grafana Authentication overview and other authentication documentation for detailed instructions on how to set up and configure authentication.

login_cookie_name

The cookie name for storing the auth token. Default is grafana_session.

login_maximum_inactive_lifetime_duration

The maximum lifetime (duration) an authenticated user can be inactive before being required to login at next visit. Default is 7 days (7d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month). The lifetime resets at each successful token rotation (token_rotation_interval_minutes).

login_maximum_lifetime_duration

The maximum lifetime (duration) an authenticated user can be logged in since login time before being required to login. Default is 30 days (30d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month).

token_rotation_interval_minutes

How often auth tokens are rotated for authenticated users when the user is active. The default is each 10 minutes.

disable_login_form

Set to true to disable (hide) the login form, useful if you use OAuth. Default is false.

disable_signout_menu

Set to true to disable the signout link in the side menu. This is useful if you use auth.proxy. Default is false.

signout_redirect_url

URL to redirect the user to after they sign out.

oauth_auto_login

Note
This option is deprecated - use auto_login option for specific OAuth provider instead.

Set to true to attempt login with OAuth automatically, skipping the login screen. This setting is ignored if multiple OAuth providers are configured. Default is false.

oauth_state_cookie_max_age

How many seconds the OAuth state cookie lives before being deleted. Default is 600 (seconds) Administrators can increase this if they experience OAuth login state mismatch errors.

oauth_skip_org_role_update_sync

Note
This option is deprecated in favor of OAuth provider specific skip_org_role_sync settings. The following sections explain settings for each provider.

If you want to change the oauth_skip_org_role_update_sync setting to false, then for each provider you have set up, use the skip_org_role_sync setting to specify whether you want to skip the synchronization.

Warning
Currently if no organization role mapping is found for a user, Grafana doesn’t update the user’s organization role. With Grafana 10, if oauth_skip_org_role_update_sync option is set to false, users with no mapping will be reset to the default organization role on every login. See auto_assign_org_role option.

skip_org_role_sync

skip_org_role_sync prevents the synchronization of organization roles for a specific OAuth integration, while the deprecated setting oauth_skip_org_role_update_sync affects all configured OAuth providers.

skip_org_role_sync default value is false.

With skip_org_role_sync set to false, the users’ organization and role is reset on every new login, based on the external provider’s role. See your provider in the tables below.

With skip_org_role_sync set to true, when a user logs in for the first time, Grafana sets the organization role based on the value specified in auto_assign_org_role and forces the organization to auto_assign_org_id when specified, otherwise it falls back to OrgID 1.

Use this setting when you want to manage the organization roles of your users from within Grafana and be able to manually assign them to multiple organizations, or to prevent synchronization conflicts when they can be synchronized from another provider.

The behavior of oauth_skip_org_role_update_sync and skip_org_role_sync, can be seen in the tables below:

[auth.grafana_com]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with Grafana.com role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role synchronization for Grafana.com users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for Grafana.com users and all other OAuth providers. Role is set to `auto_assign_org_role`.	true

[auth.azuread]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with AzureAD role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role synchronization for AzureAD users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for AzureAD users and all other OAuth providers. Role is set to `auto_assign_org_role`.	true

[auth.google]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	User organization role is set to `auto_assign_org_role` and cannot be changed.	false
true	false	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true
false	true	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true
true	true	User organization role is set to `auto_assign_org_role` and can be changed in Grafana.	true

Note
For GitLab, GitHub, Okta, Generic OAuth providers, Grafana synchronizes organization roles and sets Grafana Admins. The allow_assign_grafana_admin setting is also accounted for, to allow or not setting the Grafana Admin role from the external provider.

[auth.github]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with GitHub role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for GitHub users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for GitHub users. Role is set to `auto_assign_org_role`.	true

[auth.gitlab]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with Gitlab role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for Gitlab users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for Gitlab users. Role is set to `auto_assign_org_role`.	true

[auth.generic_oauth]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with the provider’s role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for the provider’s users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for the provider’s users. Role is set to `auto_assign_org_role`.	true

[auth.okta]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Modifiable
false	false	Synchronize user organization role with Okta role. If no role is provided, `auto_assign_org_role` is set.	false
true	false	Skips organization role synchronization for all OAuth providers’ users. Role is set to `auto_assign_org_role`.	true
false	true	Skips organization role and Grafana Admin synchronization for Okta users. Role is set to `auto_assign_org_role`.	true
true	true	Skips organization role synchronization for all OAuth providers and skips Grafana Admin synchronization for Okta users. Role is set to `auto_assign_org_role`.	true

Example skip_org_role_sync

[auth.google]

`oauth_skip_org_role_update_sync`	`skip_org_role_sync`	Resulting Org Role	Example Scenario
false	false	Synchronized with Google Auth organization roles	A user logs in to Grafana using their Google account and their organization role is automatically set based on their role in Google.
true	false	Skipped synchronization of organization roles from all OAuth providers	A user logs in to Grafana using their Google account and their organization role is not set based on their role. But Grafana Administrators can modify the role from the UI.
false	true	Skipped synchronization of organization roles Google	A user logs in to Grafana using their Google account and their organization role is not set based on their role in Google. But Grafana Administrators can modify the role from the UI.
true	true	Skipped synchronization of organization roles from all OAuth providers including Google	A user logs in to Grafana using their Google account and their organization role is not set based on their role in Google. But Grafana Administrators can modify the role from the UI.

api_key_max_seconds_to_live

Limit of API key seconds to live before expiration. Default is -1 (unlimited).

sigv4_auth_enabled

Only available in Grafana 7.3+.

Set to true to enable the AWS Signature Version 4 Authentication option for HTTP-based datasources. Default is false.

sigv4_verbose_logging

Only available in Grafana 8.4+.

Set to true to enable verbose request signature logging when AWS Signature Version 4 Authentication is enabled. Default is false.

[auth.anonymous]

Refer to Anonymous authentication for detailed instructions.

[auth.github]

Refer to GitHub OAuth2 authentication for detailed instructions.

[auth.gitlab]

Refer to Gitlab OAuth2 authentication for detailed instructions.

[auth.google]

Refer to Google OAuth2 authentication for detailed instructions.

[auth.grafananet]

Legacy key names, still in the config file so they work in env variables.

[auth.grafana_com]

Legacy key names, still in the config file so they work in env variables.

[auth.azuread]

Refer to Azure AD OAuth2 authentication for detailed instructions.

[auth.okta]

Refer to Okta OAuth2 authentication for detailed instructions.

[auth.generic_oauth]

Refer to Generic OAuth authentication for detailed instructions.

[auth.basic]

Refer to Basic authentication for detailed instructions.

[auth.proxy]

Refer to Auth proxy authentication for detailed instructions.

[auth.ldap]

Refer to LDAP authentication for detailed instructions.

[aws]

You can configure core and external AWS plugins.

allowed_auth_providers

Specify what authentication providers the AWS plugins allow. For a list of allowed providers, refer to the data-source configuration page for a given plugin. If you configure a plugin by provisioning, only providers that are specified in allowed_auth_providers are allowed.

Options: default (AWS SDK default), keys (Access and secret key), credentials (Credentials file), ec2_iam_role (EC2 IAM role)

assume_role_enabled

Set to false to disable AWS authentication from using an assumed role with temporary security credentials. For details about assume roles, refer to the AWS API reference documentation about the AssumeRole operation.

If this option is disabled, the Assume Role and the External Id field are removed from the AWS data source configuration page. If the plugin is configured using provisioning, it is possible to use an assumed role as long as assume_role_enabled is set to true.

list_metrics_page_limit

Use the List Metrics API option to load metrics for custom namespaces in the CloudWatch data source. By default, the page limit is 500.

[azure]

Grafana supports additional integration with Azure services when hosted in the Azure Cloud.

cloud

Azure cloud environment where Grafana is hosted:

Azure Cloud	Value
Microsoft Azure public cloud	AzureCloud (default)
Microsoft Chinese national cloud	AzureChinaCloud
US Government cloud	AzureUSGovernment
Microsoft German national cloud (“Black Forest”)	AzureGermanCloud

managed_identity_enabled

Specifies whether Grafana hosted in Azure service with Managed Identity configured (e.g. Azure Virtual Machines instance). Disabled by default, needs to be explicitly enabled.

managed_identity_client_id

The client ID to use for user-assigned managed identity.

Should be set for user-assigned identity and should be empty for system-assigned identity.

workload_identity_enabled

Specifies whether Azure AD Workload Identity authentication should be enabled in datasources that support it.

For more documentation on Azure AD Workload Identity, review Azure AD Workload Identity documentation.

Disabled by default, needs to be explicitly enabled.

workload_identity_tenant_id

Tenant ID of the Azure AD Workload Identity.

Allows to override default tenant ID of the Azure AD identity associated with the Kubernetes service account.

workload_identity_client_id

Client ID of the Azure AD Workload Identity.

Allows to override default client ID of the Azure AD identity associated with the Kubernetes service account.

workload_identity_token_file

Custom path to token file for the Azure AD Workload Identity.

Allows to set a custom path to the projected service account token file.

[auth.jwt]

Refer to JWT authentication for more information.

[smtp]

Email server settings.

enabled

Enable this to allow Grafana to send email. Default is false.

host

Default is localhost:25. Use port 465 for implicit TLS.

user

In case of SMTP auth, default is empty.

password

In case of SMTP auth, default is empty. If the password contains # or ;, then you have to wrap it with triple quotes. Example: “”"#password;"""

cert_file

File path to a cert file, default is empty.

key_file

File path to a key file, default is empty.

skip_verify

Verify SSL for SMTP server, default is false.

from_address

Address used when sending out emails, default is admin@grafana.localhost.

from_name

Name to be used when sending out emails, default is Grafana.

ehlo_identity

Name to be used as client identity for EHLO in SMTP dialog, default is <instance_name>.

startTLS_policy

Either “OpportunisticStartTLS”, “MandatoryStartTLS”, “NoStartTLS”. Default is empty.

[emails]

welcome_email_on_sign_up

Default is false.

templates_pattern

Enter a comma separated list of template patterns. Default is emails/*.html, emails/*.txt.

content_types

Enter a comma-separated list of content types that should be included in the emails that are sent. List the content types according descending preference, e.g. text/html, text/plain for HTML as the most preferred. The order of the parts is significant as the mail clients will use the content type that is supported and most preferred by the sender. Supported content types are text/html and text/plain. Default is text/html.

[log]

Grafana logging options.

mode

Options are “console”, “file”, and “syslog”. Default is “console” and “file”. Use spaces to separate multiple modes, e.g. console file.

level

Options are “debug”, “info”, “warn”, “error”, and “critical”. Default is info.

filters

Optional settings to set different levels for specific loggers. For example: filters = sqlstore:debug

[log.console]

Only applicable when “console” is used in [log] mode.

level

Options are “debug”, “info”, “warn”, “error”, and “critical”. Default is inherited from [log] level.

format

Log line format, valid options are text, console and json. Default is console.

[log.file]

Only applicable when “file” used in [log] mode.

level

Options are “debug”, “info”, “warn”, “error”, and “critical”. Default is inherited from [log] level.

format

Log line format, valid options are text, console and json. Default is text.

log_rotate

Enable automated log rotation, valid options are false or true. Default is true. When enabled use the max_lines, max_size_shift, daily_rotate and max_days to configure the behavior of the log rotation.

max_lines

Maximum lines per file before rotating it. Default is 1000000.

max_size_shift

Maximum size of file before rotating it. Default is 28, which means 1 << 28, 256MB.

daily_rotate

Enable daily rotation of files, valid options are false or true. Default is true.

max_days

Maximum number of days to keep log files. Default is 7.

[log.syslog]

Only applicable when “syslog” used in [log] mode.

level

Options are “debug”, “info”, “warn”, “error”, and “critical”. Default is inherited from [log] level.

format

Log line format, valid options are text, console, and json. Default is text.

network and address

Syslog network type and address. This can be UDP, TCP, or UNIX. If left blank, then the default UNIX endpoints are used.

facility

Syslog facility. Valid options are user, daemon or local0 through local7. Default is empty.

tag

Syslog tag. By default, the process’s argv[0] is used.

[log.frontend]

Note: This feature is available in Grafana 7.4+.

enabled

Sentry javascript agent is initialized. Default is false.

provider

Defines which provider to use sentry or grafana. Default is sentry

sentry_dsn

Sentry DSN if you want to send events to Sentry

custom_endpoint

Custom HTTP endpoint to send events captured by the Sentry agent to. Default, /log, will log the events to stdout.

sample_rate

Rate of events to be reported between 0 (none) and 1 (all, default), float.

log_endpoint_requests_per_second_limit

Requests per second limit enforced per an extended period, for Grafana backend log ingestion endpoint, /log. Default is 3.

log_endpoint_burst_limit

Maximum requests accepted per short interval of time for Grafana backend log ingestion endpoint, /log. Default is 15.

instrumentations_errors_enabled

Turn on error instrumentation. Only affects Grafana Javascript Agent.

instrumentations_console_enabled

Turn on console instrumentation. Only affects Grafana Javascript Agent

instrumentations_webvitals_enabled

Turn on webvitals instrumentation. Only affects Grafana Javascript Agent

api_key

If custom_endpoint required authentication, you can set the api key here. Only relevant for Grafana Javascript Agent provider.

[quota]

Set quotas to -1 to make unlimited.

enabled

Enable usage quotas. Default is false.

org_user

Limit the number of users allowed per organization. Default is 10.

org_dashboard

Limit the number of dashboards allowed per organization. Default is 100.

org_data_source

Limit the number of data sources allowed per organization. Default is 10.

org_api_key

Limit the number of API keys that can be entered per organization. Default is 10.

org_alert_rule

Limit the number of alert rules that can be entered per organization. Default is 100.

user_org

Limit the number of organizations a user can create. Default is 10.

global_user

Sets a global limit of users. Default is -1 (unlimited).

global_org

Sets a global limit on the number of organizations that can be created. Default is -1 (unlimited).

global_dashboard

Sets a global limit on the number of dashboards that can be created. Default is -1 (unlimited).

global_api_key

Sets global limit of API keys that can be entered. Default is -1 (unlimited).

global_session

Sets a global limit on number of users that can be logged in at one time. Default is -1 (unlimited).

global_alert_rule

Sets a global limit on number of alert rules that can be created. Default is -1 (unlimited).

global_correlations

Sets a global limit on number of correlations that can be created. Default is -1 (unlimited).

[unified_alerting]

For more information about the Grafana alerts, refer to About Grafana Alerting.

enabled

Enable or disable Grafana Alerting. If disabled, all your legacy alerting data will be available again, but the data you created using Grafana Alerting will be deleted. Set force_migration=true to avoid deletion of data. The default value is true.

Alerting Rules migrated from dashboards and panels will include a link back via the annotations.

disabled_orgs

Comma-separated list of organization IDs for which to disable Grafana 8 Unified Alerting.

admin_config_poll_interval

Specify the frequency of polling for admin config changes. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

alertmanager_config_poll_interval

Specify the frequency of polling for Alertmanager config changes. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

ha_listen_address

Listen IP address and port to receive unified alerting messages for other Grafana instances. The port is used for both TCP and UDP. It is assumed other Grafana instances are also running on the same port. The default value is 0.0.0.0:9094.

ha_advertise_address

Explicit IP address and port to advertise other Grafana instances. The port is used for both TCP and UDP.

ha_peers

Comma-separated list of initial instances (in a format of host:port) that will form the HA cluster. Configuring this setting will enable High Availability mode for alerting.

ha_peer_timeout

Time to wait for an instance to send a notification via the Alertmanager. In HA, each Grafana instance will be assigned a position (e.g. 0, 1). We then multiply this position with the timeout to indicate how long should each instance wait before sending the notification to take into account replication lag. The default value is 15s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

ha_gossip_interval

The interval between sending gossip messages. By lowering this value (more frequent) gossip messages are propagated across cluster more quickly at the expense of increased bandwidth usage. The default value is 200ms.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

ha_push_pull_interval

The interval between gossip full state syncs. Setting this interval lower (more frequent) will increase convergence speeds across larger clusters at the expense of increased bandwidth usage. The default value is 60s.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

execute_alerts

Enable or disable alerting rule execution. The default value is true. The alerting UI remains visible. This option has a legacy version in the alerting section that takes precedence.

evaluation_timeout

Sets the alert evaluation timeout when fetching data from the datasource. The default value is 30s. This option has a legacy version in the alerting section that takes precedence.

The timeout string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

max_attempts

Sets a maximum number of times we’ll attempt to evaluate an alert rule before giving up on that evaluation. The default value is 1.

min_interval

Sets the minimum interval to enforce between rule evaluations. The default value is 10s which equals the scheduler interval. Rules will be adjusted if they are less than this value or if they are not multiple of the scheduler interval (10s). Higher values can help with resource management as we’ll schedule fewer evaluations over time. This option has a legacy version in the alerting section that takes precedence.

The interval string is a possibly signed sequence of decimal numbers, followed by a unit suffix (ms, s, m, h, d), e.g. 30s or 1m.

Note. This setting has precedence over each individual rule frequency. If a rule frequency is lower than this value, then this value is enforced.

[unified_alerting.screenshots]

For more information about screenshots, refer to Images in notifications.

capture

Enable screenshots in notifications. This option requires a remote HTTP image rendering service. Please see [rendering] for further configuration options.

max_concurrent_screenshots

The maximum number of screenshots that can be taken at the same time. This option is different from concurrent_render_request_limit as max_concurrent_screenshots sets the number of concurrent screenshots that can be taken at the same time for all firing alerts where as concurrent_render_request_limit sets the total number of concurrent screenshots across all Grafana services.

upload_external_image_storage

Uploads screenshots to the local Grafana server or remote storage such as Azure, S3 and GCS. Please see [external_image_storage] for further configuration options. If this option is false then screenshots will be persisted to disk for up to temp_data_lifetime.

[unified_alerting.reserved_labels]

For more information about Grafana Reserved Labels, refer to Labels in Grafana Alerting

disabled_labels

Comma-separated list of reserved labels added by the Grafana Alerting engine that should be disabled.

For example: disabled_labels=grafana_folder

[alerting]

For more information about the legacy dashboard alerting feature in Grafana, refer to the legacy Grafana alerts.

enabled

Set to true to enable legacy dashboard alerting. The default value is false.

execute_alerts

Turns off alert rule execution, but alerting is still visible in the Grafana UI.

error_or_timeout

Default setting for new alert rules. Defaults to categorize error and timeouts as alerting. (alerting, keep_state)

nodata_or_nullvalues

Defines how Grafana handles nodata or null values in alerting. Options are alerting, no_data, keep_state, and ok. Default is no_data.

concurrent_render_limit

Alert notifications can include images, but rendering many images at the same time can overload the server. This limit protects the server from render overloading and ensures notifications are sent out quickly. Default value is 5.

evaluation_timeout_seconds

Sets the alert calculation timeout. Default value is 30.

notification_timeout_seconds

Sets the alert notification timeout. Default value is 30.

max_attempts

Sets a maximum limit on attempts to sending alert notifications. Default value is 3.

min_interval_seconds

Sets the minimum interval between rule evaluations. Default value is 1.

Note. This setting has precedence over each individual rule frequency. If a rule frequency is lower than this value, then this value is enforced.

max_annotation_age =

Configures for how long alert annotations are stored. Default is 0, which keeps them forever. This setting should be expressed as a duration. Examples: 6h (hours), 10d (days), 2w (weeks), 1M (month).

max_annotations_to_keep =

Configures max number of alert annotations that Grafana stores. Default value is 0, which keeps all alert annotations.

[annotations]

cleanupjob_batchsize

Configures the batch size for the annotation clean-up job. This setting is used for dashboard, API, and alert annotations.

tags_length

Enforces the maximum allowed length of the tags for any newly introduced annotations. It can be between 500 and 4096 (inclusive). Default value is 500. Setting it to a higher value would impact performance therefore is not recommended.

[annotations.dashboard]

Dashboard annotations means that annotations are associated with the dashboard they are created on.

max_age

Configures how long dashboard annotations are stored. Default is 0, which keeps them forever. This setting should be expressed as a duration. Examples: 6h (hours), 10d (days), 2w (weeks), 1M (month).

max_annotations_to_keep

Configures max number of dashboard annotations that Grafana stores. Default value is 0, which keeps all dashboard annotations.

[annotations.api]

API annotations means that the annotations have been created using the API without any association with a dashboard.

max_age

Configures how long Grafana stores API annotations. Default is 0, which keeps them forever. This setting should be expressed as a duration. Examples: 6h (hours), 10d (days), 2w (weeks), 1M (month).

max_annotations_to_keep

Configures max number of API annotations that Grafana keeps. Default value is 0, which keeps all API annotations.

[explore]

For more information about this feature, refer to Explore.

enabled

Enable or disable the Explore section. Default is enabled.

[help]

Configures the help section.

enabled

Enable or disable the Help section. Default is enabled.

[profile]

Configures the Profile section.

enabled

Enable or disable the Profile section. Default is enabled.

[query_history]

Configures Query history in Explore.

enabled

Enable or disable the Query history. Default is enabled.

[metrics]

For detailed instructions, refer to Internal Grafana metrics.

enabled

Enable metrics reporting. defaults true. Available via HTTP API <URL>/metrics.

interval_seconds

Flush/write interval when sending metrics to external TSDB. Defaults to 10.

disable_total_stats

If set to true, then total stats generation (stat_totals_* metrics) is disabled. Default is false.

total_stats_collector_interval_seconds

Sets the total stats collector interval. The default is 1800 seconds (30 minutes).

basic_auth_username and basic_auth_password

If both are set, then basic authentication is required to access the metrics endpoint.

[metrics.environment_info]

Adds dimensions to the grafana_environment_info metric, which can expose more information about the Grafana instance.

; exampleLabel1 = exampleValue1
; exampleLabel2 = exampleValue2

[metrics.graphite]

Use these options if you want to send internal Grafana metrics to Graphite.

address

Enable by setting the address. Format is <Hostname or ip>:port.

prefix

Graphite metric prefix. Defaults to prod.grafana.%(instance_name)s.

[grafana_net]

url

Default is https://grafana.com.

[grafana_com]

url

Default is https://grafana.com.

[tracing.jaeger]

[Deprecated - use tracing.opentelemetry.jaeger or tracing.opentelemetry.otlp instead]

Configure Grafana’s Jaeger client for distributed tracing.

You can also use the standard JAEGER_* environment variables to configure Jaeger. See the table at the end of https://www.jaegertracing.io/docs/1.16/client-features/ for the full list. Environment variables will override any settings provided here.

address

The host:port destination for reporting spans. (ex: localhost:6831)

Can be set with the environment variables JAEGER_AGENT_HOST and JAEGER_AGENT_PORT.

always_included_tag

Comma-separated list of tags to include in all new spans, such as tag1:value1,tag2:value2.

Can be set with the environment variable JAEGER_TAGS (use = instead of : with the environment variable).

sampler_type

Default value is const.

Specifies the type of sampler: const, probabilistic, ratelimiting, or remote.

Refer to https://www.jaegertracing.io/docs/1.16/sampling/#client-sampling-configuration for details on the different tracing types.

Can be set with the environment variable JAEGER_SAMPLER_TYPE.

sampler_param

Default value is 1.

This is the sampler configuration parameter. Depending on the value of sampler_type, it can be 0, 1, or a decimal value in between.

For const sampler, 0 or 1 for always false/true respectively
For probabilistic sampler, a probability between 0 and 1.0
For rateLimiting sampler, the number of spans per second
For remote sampler, param is the same as for probabilistic and indicates the initial sampling rate before the actual one is received from the mothership

May be set with the environment variable JAEGER_SAMPLER_PARAM.

sampling_server_url

sampling_server_url is the URL of a sampling manager providing a sampling strategy.

zipkin_propagation

Default value is false.

Controls whether or not to use Zipkin’s span propagation format (with x-b3- HTTP headers). By default, Jaeger’s format is used.

Can be set with the environment variable and value JAEGER_PROPAGATION=b3.

disable_shared_zipkin_spans

Default value is false.

Setting this to true turns off shared RPC spans. Leaving this available is the most common setting when using Zipkin elsewhere in your infrastructure.

[tracing.opentelemetry]

Configure general parameters shared between OpenTelemetry providers.

custom_attributes

Comma-separated list of attributes to include in all new spans, such as key1:value1,key2:value2.

Can be set with the environment variable OTEL_RESOURCE_ATTRIBUTES (use = instead of : with the environment variable).

[tracing.opentelemetry.jaeger]

Configure Grafana’s Jaeger client for distributed tracing.

address

The host:port destination for reporting spans. (ex: localhost:14268/api/traces)

propagation

The propagation specifies the text map propagation format. The values jaeger and w3c are supported. Add a comma (,) between values to specify multiple formats (for example, "jaeger,w3c"). The default value is w3c.

[tracing.opentelemetry.otlp]

Configure Grafana’s otlp client for distributed tracing.

address

The host:port destination for reporting spans. (ex: localhost:4317)

propagation

[external_image_storage]

These options control how images should be made public so they can be shared on services like Slack or email message.

provider

Options are s3, webdav, gcs, azure_blob, local). If left empty, then Grafana ignores the upload action.

[external_image_storage.s3]

endpoint

Optional endpoint URL (hostname or fully qualified URI) to override the default generated S3 endpoint. If you want to keep the default, just leave this empty. You must still provide a region value if you specify an endpoint.

path_style_access

Set this to true to force path-style addressing in S3 requests, i.e., http://s3.amazonaws.com/BUCKET/KEY, instead of the default, which is virtual hosted bucket addressing when possible (http://BUCKET.s3.amazonaws.com/KEY).

Note
This option is specific to the Amazon S3 service.

bucket_url

(for backward compatibility, only works when no bucket or region are configured) Bucket URL for S3. AWS region can be specified within URL or defaults to ‘us-east-1’, e.g.

bucket

Bucket name for S3. e.g. grafana.snapshot.

region

Region name for S3. e.g. ‘us-east-1’, ‘cn-north-1’, etc.

path

Optional extra path inside bucket, useful to apply expiration policies.

access_key

Access key, e.g. AAAAAAAAAAAAAAAAAAAA.

Access key requires permissions to the S3 bucket for the ‘s3:PutObject’ and ‘s3:PutObjectAcl’ actions.

secret_key

Secret key, e.g. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.

[external_image_storage.webdav]

url

URL where Grafana sends PUT request with images.

username

Basic auth username.

password

Basic auth password.

public_url

Optional URL to send to users in notifications. If the string contains the sequence ${file}, it is replaced with the uploaded filename. Otherwise, the file name is appended to the path part of the URL, leaving any query string unchanged.

[external_image_storage.gcs]

key_file

Optional path to JSON key file associated with a Google service account to authenticate and authorize. If no value is provided it tries to use the application default credentials. Service Account keys can be created and downloaded from https://console.developers.google.com/permissions/serviceaccounts.

Service Account should have “Storage Object Writer” role. The access control model of the bucket needs to be “Set object-level and bucket-level permissions”. Grafana itself will make the images public readable when signed urls are not enabled.

bucket

Bucket Name on Google Cloud Storage.

path

Optional extra path inside bucket.

enable_signed_urls

If set to true, Grafana creates a signed URL for the image uploaded to Google Cloud Storage.

signed_url_expiration

Sets the signed URL expiration, which defaults to seven days.

[external_image_storage.azure_blob]

account_name

Storage account name.

account_key

Storage account key

container_name

Container name where to store “Blob” images with random names. Creating the blob container beforehand is required. Only public containers are supported.

sas_token_expiration_days

Number of days for SAS token validity. If specified SAS token will be attached to image URL. Allow storing images in private containers.

[external_image_storage.local]

This option does not require any configuration.

[rendering]

Options to configure a remote HTTP image rendering service, e.g. using https://github.com/grafana/grafana-image-renderer.

renderer_token

Note
Available in Grafana v9.1.2 and Image Renderer v3.6.1 or later.

An auth token will be sent to and verified by the renderer. The renderer will deny any request without an auth token matching the one configured on the renderer.

server_url

URL to a remote HTTP image renderer service, e.g. http://localhost:8081/render, will enable Grafana to render panels and dashboards to PNG-images using HTTP requests to an external service.

callback_url

If the remote HTTP image renderer service runs on a different server than the Grafana server you may have to configure this to a URL where Grafana is reachable, e.g. http://grafana.domain/.

concurrent_render_request_limit

Concurrent render request limit affects when the /render HTTP endpoint is used. Rendering many images at the same time can overload the server, which this setting can help protect against by only allowing a certain number of concurrent requests. Default is 30.

[panels]

enable_alpha

Set to true if you want to test alpha panels that are not yet ready for general usage. Default is false.

disable_sanitize_html

If set to true Grafana will allow script tags in text panels. Not recommended as it enables XSS vulnerabilities. Default is false. This setting was introduced in Grafana v6.0.

[plugins]

enable_alpha

Set to true if you want to test alpha plugins that are not yet ready for general usage. Default is false.

allow_loading_unsigned_plugins

Enter a comma-separated list of plugin identifiers to identify plugins to load even if they are unsigned. Plugins with modified signatures are never loaded.

We do not recommend using this option. For more information, refer to Plugin signatures.

plugin_admin_enabled

Available to Grafana administrators only, enables installing / uninstalling / updating plugins directly from the Grafana UI. Set to true by default. Setting it to false will hide the install / uninstall / update controls.

For more information, refer to Plugin catalog.

plugin_admin_external_manage_enabled

Set to true if you want to enable external management of plugins. Default is false. This is only applicable to Grafana Cloud users.

plugin_catalog_url

Custom install/learn more URL for enterprise plugins. Defaults to https://grafana.com/grafana/plugins/.

plugin_catalog_hidden_plugins

Enter a comma-separated list of plugin identifiers to hide in the plugin catalog.

[live]

max_connections

Note
Available in Grafana v8.0 and later versions.

The max_connections option specifies the maximum number of connections to the Grafana Live WebSocket endpoint per Grafana server instance. Default is 100.

Refer to Grafana Live configuration documentation if you specify a number higher than default since this can require some operating system and infrastructure tuning.

0 disables Grafana Live, -1 means unlimited connections.

allowed_origins

Note
Available in Grafana v8.0.4 and later versions.

The allowed_origins option is a comma-separated list of additional origins (Origin header of HTTP Upgrade request during WebSocket connection establishment) that will be accepted by Grafana Live.

If not set (default), then the origin is matched over root_url which should be sufficient for most scenarios.

Origin patterns support wildcard symbol “*”.

For example:

[live]
allowed_origins = "https://*.example.com"

ha_engine

Note
Available in Grafana v8.1 and later versions.

Experimental

The high availability (HA) engine name for Grafana Live. By default, it’s not set. The only possible value is “redis”.

For more information, refer to the Configure Grafana Live HA setup.

ha_engine_address

Note
Available in Grafana v8.1 and later versions.

Experimental

Address string of selected the high availability (HA) Live engine. For Redis, it’s a host:port string. Example:

[live]
ha_engine = redis
ha_engine_address = 127.0.0.1:6379

[plugin.plugin_id]

This section can be used to configure plugin-specific settings. Replace the plugin_id attribute with the plugin ID present in plugin.json.

Properties described in this section are available for all plugins, but you must set them individually for each plugin.

tracing

Note
Available in Grafana v9.5.0 or later, and OpenTelemetry must be configured as well.

If true, propagate the tracing context to the plugin backend and enable tracing (if the backend supports it).

[plugin.grafana-image-renderer]

For more information, refer to Image rendering.

rendering_timezone

Instruct headless browser instance to use a default timezone when not provided by Grafana, e.g. when rendering panel image of alert. See ICUs metaZones.txt for a list of supported timezone IDs. Fallbacks to TZ environment variable if not set.

rendering_language

Instruct headless browser instance to use a default language when not provided by Grafana, e.g. when rendering panel image of alert. Refer to the HTTP header Accept-Language to understand how to format this value, e.g. ‘fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5’.

rendering_viewport_device_scale_factor

Instruct headless browser instance to use a default device scale factor when not provided by Grafana, e.g. when rendering panel image of alert. Default is 1. Using a higher value will produce more detailed images (higher DPI), but requires more disk space to store an image.

rendering_ignore_https_errors

Instruct headless browser instance whether to ignore HTTPS errors during navigation. Per default HTTPS errors are not ignored. Due to the security risk, we do not recommend that you ignore HTTPS errors.

rendering_verbose_logging

Instruct headless browser instance whether to capture and log verbose information when rendering an image. Default is false and will only capture and log error messages.

When enabled, debug messages are captured and logged as well.

For the verbose information to be included in the Grafana server log you have to adjust the rendering log level to debug, configure [log].filter = rendering:debug.

rendering_dumpio

Instruct headless browser instance whether to output its debug and error messages into running process of remote rendering service. Default is false.

It can be useful to set this to true when troubleshooting.

rendering_args

Additional arguments to pass to the headless browser instance. Defaults are --no-sandbox,--disable-gpu. The list of Chromium flags can be found at (https://peter.sh/experiments/chromium-command-line-switches/). Separate multiple arguments with commas.

rendering_chrome_bin

You can configure the plugin to use a different browser binary instead of the pre-packaged version of Chromium.

Please note that this is not recommended. You might encounter problems if the installed version of Chrome/Chromium is not compatible with the plugin.

rendering_mode

Instruct how headless browser instances are created. Default is default and will create a new browser instance on each request.

Mode clustered will make sure that only a maximum of browsers/incognito pages can execute concurrently.

Mode reusable will have one browser instance and will create a new incognito page on each request.

rendering_clustering_mode

When rendering_mode = clustered, you can instruct how many browsers or incognito pages can execute concurrently. Default is browser and will cluster using browser instances.

Mode context will cluster using incognito pages.

rendering_clustering_max_concurrency

When rendering_mode = clustered, you can define the maximum number of browser instances/incognito pages that can execute concurrently. Default is 5.

rendering_clustering_timeout

Note
Available in grafana-image-renderer v3.3.0 and later versions.

When rendering_mode = clustered, you can specify the duration a rendering request can take before it will time out. Default is 30 seconds.

rendering_viewport_max_width

Limit the maximum viewport width that can be requested.

rendering_viewport_max_height

Limit the maximum viewport height that can be requested.

rendering_viewport_max_device_scale_factor

Limit the maximum viewport device scale factor that can be requested.

grpc_host

Change the listening host of the gRPC server. Default host is 127.0.0.1.

grpc_port

Change the listening port of the gRPC server. Default port is 0 and will automatically assign a port not in use.

[enterprise]

For more information about Grafana Enterprise, refer to Grafana Enterprise.

[feature_toggles]

enable

Keys of features to enable, separated by space.

FEATURE_TOGGLE_NAME = false

Some feature toggles for stable features are on by default. Use this setting to disable an on-by-default feature toggle with the name FEATURE_TOGGLE_NAME, for example, exploreMixedDatasource = false.

[date_formats]

Note
The date format options below are only available in Grafana v7.2+.

This section controls system-wide defaults for date formats used in time ranges, graphs, and date input boxes.

The format patterns use Moment.js formatting tokens.

full_date

Full date format used by time range picker and in other places where a full date is rendered.

intervals

These intervals formats are used in the graph to show only a partial date or time. For example, if there are only minutes between Y-axis tick labels then the interval_minute format is used.

Defaults

interval_second = HH:mm:ss
interval_minute = HH:mm
interval_hour = MM/DD HH:mm
interval_day = MM/DD
interval_month = YYYY-MM
interval_year = YYYY

use_browser_locale

Set this to true to have date formats automatically derived from your browser location. Defaults to false. This is an experimental feature.

default_timezone

Used as the default time zone for user preferences. Can be either browser for the browser local time zone or a time zone name from the IANA Time Zone database, such as UTC or Europe/Amsterdam.

default_week_start

Set the default start of the week, valid values are: saturday, sunday, monday or browser to use the browser locale to define the first day of the week. Default is browser.

[expressions]

Note
This feature is available in Grafana v7.4 and later versions.

enabled

Set this to false to disable expressions and hide them in the Grafana UI. Default is true.

[geomap]

This section controls the defaults settings for Geomap Plugin.

default_baselayer_config

The json config used to define the default base map. Four base map options to choose from are carto, esriXYZTiles, xyzTiles, standard. For example, to set cartoDB light as the default base layer:

default_baselayer_config = `{
  "type": "xyz",
  "config": {
    "attribution": "Open street map",
    "url": "https://tile.openstreetmap.org/{z}/{x}/{y}.png"
  }
}`

enable_custom_baselayers

Set this to false to disable loading other custom base maps and hide them in the Grafana UI. Default is true.

[rbac]

Refer to Role-based access control for more information.

Start the Grafana server

Fri, 07 Mar 2025 11:34:44 +0100

Start the Grafana server

This topic includes instructions for starting the Grafana server. For certain configuration changes, you might have to restart the Grafana server for them to take effect.

The following instructions start the grafana-server process as the grafana user, which was created during the package installation.

If you installed with the APT repository or .deb package, then you can start the server using systemd or init.d. If you installed a binary .tar.gz file, then you execute the binary.

Linux

The following subsections describe three methods of starting and restarting the Grafana server: with systemd, initd, or by directly running the binary. You should follow only one set of instructions, depending on how your machine is configured.

Start the Grafana server with systemd

Complete the following steps to start the Grafana server using systemd and verify that it is running.

To start the service, run the following commands:

sudo systemctl daemon-reload
sudo systemctl start grafana-server
sudo systemctl status grafana-server

To verify that the service is running, run the following command:
```
sudo systemctl status grafana-server
```

Configure the Grafana server to start at boot using systemd

To configure the Grafana server to start at boot, run the following command:

sudo systemctl enable grafana-server.service

Serve Grafana on a port < 1024

If you are using systemd and want to start Grafana on a port that is lower than 1024, you must add a systemd unit override.

Run the following command to create an override file in your configured editor.

# Alternatively, create a file in /etc/systemd/system/grafana-server.service.d/override.conf
sudo systemctl edit grafana-server.service

Add the following additional settings to grant the CAP_NET_BIND_SERVICE capability.

To learn more about capabilities, refer to capabilities(7) — Linux manual page.

[Service]
# Give the CAP_NET_BIND_SERVICE capability
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# A private user cannot have process capabilities on the host's user
# namespace and thus CAP_NET_BIND_SERVICE has no effect.
PrivateUsers=false

Restart the Grafana server using systemd

To restart the Grafana server, run the following commands:

sudo systemctl restart grafana-server

Note
SUSE or openSUSE users might need to start the server with the systemd method, then use the init.d method to configure Grafana to start at boot.

Start the Grafana server using init.d

Complete the following steps to start the Grafana server using init.d and verify that it is running:

To start the Grafana server, run the following commands:

sudo service grafana-server start
sudo service grafana-server status

To verify that the service is running, run the following command:
```
sudo service grafana-server status
```

Configure the Grafana server to start at boot using init.d

To configure the Grafana server to start at boot, run the following command:

sudo update-rc.d grafana-server defaults

Restart the Grafana server using init.d

To restart the Grafana server, run the following commands:

sudo service grafana-server restart

Start the server using the binary

The grafana binary .tar.gz needs the working directory to be the root install directory where the binary and the public folder are located.

To start the Grafana server, run the following command:

./bin/grafana server

Docker

To restart the Grafana service, use the docker restart command.

docker restart grafana

Alternatively, you can use the docker compose restart command to restart Grafana. For more information, refer to docker compose documentation.

Docker compose example

Configure your docker-compose.yml file. For example:

version: "3.8"
services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    restart: unless-stopped
    environment:
      - TERM=linux
      - GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-polystat-panel
    ports:
      - '3000:3000'
    volumes:
      - 'grafana_storage:/var/lib/grafana'
volumes:
  grafana_storage: {}

Start the Grafana server:

docker compose up -d

This starts the Grafana server container in detached mode along with the two plugins specified in the YAML file.

To restart the running container, use this command:

docker compose restart grafana

Windows

Complete the following steps to start the Grafana server on Windows:

Execute grafana.exe server; the grafana binary is located in the bin directory.

We recommend that you run grafana.exe server from the command line.

If you want to run Grafana as a Windows service, you can download NSSM.
To run Grafana, open your browser and go to the Grafana port (http://localhost:3000/ is default).

Note: The default Grafana port is 3000. This port might require extra permissions on Windows. If it does not appear in the default port, you can try changing to a different port.
To change the port, complete the following steps:

a. In the conf directory, copy sample.ini to custom.ini.

Note: You should edit custom.ini, never defaults.ini.

b. Edit custom.ini and uncomment the http_port configuration option (; is the comment character in ini files) and change it to something similar to 8080, which should not require extra Windows privileges.

To restart the Grafana server, complete the following steps:

Open the Services app.
Right-click on the Grafana service.
In the context menu, click Restart.

macOS

Restart methods differ depending on whether you installed Grafana using Homebrew or as standalone macOS binaries.

Start Grafana using Homebrew

To start Grafana using Homebrew, run the following start command:

brew services start grafana

Restart Grafana using Homebrew

Use the Homebrew restart command:

brew services restart grafana

Restart standalone macOS binaries

To restart Grafana:

Open a terminal and go to the directory where you copied the install setup files.
Run the command:

./bin/grafana server

Next steps

After the Grafana server is up and running, consider taking the next steps:

Refer to Get Started to learn how to build your first dashboard.
Refer to Configuration to learn about how you can customize your environment.

Sign in to Grafana

Fri, 07 Mar 2025 11:34:44 +0100

This topic describes how to sign in to Grafana.

Before you begin

Install Grafana

Steps

To sign in to Grafana for the first time, follow these steps:

Open your web browser and go to root URL specified in Grafana configuration file.

Unless you have configured Grafana differently, it is set to use http://localhost:3000 by default.
On the signin page, enter admin for username and password.
Click Sign in.

If successful, you will see a prompt to change the password.
Click OK on the prompt and change your password.

Note: We strongly recommend that you change the default administrator password.

Configure security

Fri, 07 Mar 2025 11:34:44 +0100

Configure security

If you run non-Grafana web services on your Grafana server or within its local network, then they might be vulnerable to exploitation through the Grafana data source proxy or other methods.

To prevent this type of exploitation from happening, we recommend that you apply one or more of the precautions listed below.

Limit IP addresses/hostnames for data source URL

You can configure Grafana to only allow certain IP addresses or hostnames to be used as data source URLs and proxied through the Grafana data source proxy. Refer to data_source_proxy_whitelist for usage instructions.

Request security

The request security configuration option allows users to limit requests from the Grafana server. It targets requests that are generated by users. For more information, refer to Request security.

Note
Request security is available in Grafana Enterprise v7.4 and later versions.

Firewall rules

Configure a firewall to restrict Grafana from making network requests to sensitive internal web services.

There are many firewall tools available, refer to the documentation for your specific security tool. For example, Linux users can use iptables.

Proxy server

Require all network requests being made by Grafana to go through a proxy server.

Self-hosted reverse proxy options include but are not limited to:

Pomerium, which has a guide for securing Grafana
NGINX using their guide on restricting access with HTTP basic authentication
OAuth2 proxy

Limit Viewer query permissions

Users with the Viewer role can enter any possible query in any of the data sources available in the organization, not just the queries that are defined on the dashboards for which the user has Viewer permissions.

For example: In a Grafana instance with one data source, one dashboard, and one panel that has one query defined, you might assume that a Viewer can only see the result of the query defined in that panel. Actually, the Viewer has access to send any query to the data source. With a command-line tool like curl (there are lots of tools for this), the Viewer can make their own query to the data source and potentially access sensitive data.

To address this vulnerability, you can restrict data source query access in the following ways:

Create multiple data sources with some restrictions added in data source configuration that restrict access (like database name or credentials). Then use the Data Source Permissions Enterprise feature to restrict user access to the data source in Grafana.
Create a separate Grafana organization, and in that organization, create a separate data source. Make sure the data source has some option/user/credentials setting that limits access to a subset of the data. Not all data sources have an option to limit access.

Implications of enabling anonymous access to dashboards

When you enable anonymous access to a dashboard, it is publicly available. This section lists the security implications of enabling Anonymous access.

Anyone with the URL can access the dashboard.
Anyone can make view calls to the API and list all folders, dashboards, and data sources.
Anyone can make arbitrary queries to any data source that the Grafana instance is configured with.

Set up Grafana monitoring

Fri, 07 Mar 2025 11:34:44 +0100

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 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.

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

(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 =
```
Restart Grafana. Grafana now exposes metrics at http://localhost:3000/metrics.

Add the job to your prometheus.yml file. Example:

- job_name: 'grafana_metrics'

   scrape_interval: 15s
   scrape_timeout: 5s

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

Restart Prometheus. Your new job should appear on the Targets tab.
In Grafana, hover your mouse over the Configuration (gear) icon on the left sidebar and then click Data Sources.
Select the Prometheus data source.
On the Dashboards tab, 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.

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

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.

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 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.

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

(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 =
```
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 installed.

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']

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

Set up Grafana for high availability

Fri, 07 Mar 2025 11:34:44 +0100

Set up Grafana for high availability

Note
To prevent duplicate alerts in Grafana high availability, additional steps are required.

Please refer to Alerting high availability for more information.

Grafana uses an embedded sqlite3 database to store users, dashboards, and other persistent data by default. For high availability, you must use a shared database to store this data. This shared database can be either MySQL or Postgres.

Before you begin

Before you complete the following tasks, configure a MySQL or Postgres database to be highly available. Configuring the MySQL or Postgres database for high availability is out of the scope of this guide, but you can find instructions online for each database.

Configure multiple Grafana servers to use the same database

Once you have a Postgres or MySQL database available, you can configure your multiple Grafana instances to use a shared backend database. Grafana has default and custom configuration files, and you can update the database settings by updating your custom configuration file as described in the [database]. Once configured to use a shared database, your multiple Grafana instances will persist all long-term data in that database.

Alerting high availability

Grafana Alerting provides a high availability mode.

It preserves the semantics of legacy dashboard alerting by executing all alerts on every server and by sending notifications only once per alert. Load distribution between servers is not supported at this time.

For instructions on setting up alerting high availability, refer to Enable alerting high availability.

Legacy dashboard alerts

Legacy Grafana Alerting supports a limited form of high availability. In this model, alert notifications are deduplicated when running multiple servers. This means all alerts are executed on every server, but alert notifications are only sent once per alert. Grafana does not support load distribution between servers.

Grafana Live

Grafana Live works with limitations in highly available setup. For details, refer to the Configure Grafana Live HA setup.

User sessions

Grafana uses auth token strategy with database by default. This means that a load balancer can send a user to any Grafana server without having to log in on each server.

Set up Grafana HTTPS for secure web traffic

Fri, 07 Mar 2025 11:34:44 +0100

Set up Grafana HTTPS for secure web traffic

When accessing the Grafana UI through the web, it is important to set up HTTPS to ensure the communication between Grafana and the end user is encrypted, including login credentials and retrieved metric data.

In order to ensure secure traffic over the internet, Grafana must have a key for encryption and a Secure Socket Layer (SSL) Certificate to verify the identity of the site.

The following image shows a browser lock icon which confirms the connection is safe.

This topic shows you how to:

Obtain a certificate and key
Configure Grafana HTTPS
Restart the Grafana server

Before you begin

To follow these instructions, you need:

You must have shell access to the system and sudo access to perform actions as root or administrator.
For the CA-signed option, you need a domain name that you possess and that is associated with the machine you are using.

Obtain a certificate and key

You can use one of two methods to obtain a certificate and a key. The faster and easier self-signed option might show browser warnings to the user that they will have to accept each time they visit the site. Alternatively, the Certificate Authority (CA) signed option requires more steps to complete, but it enables full trust with the browser. To learn more about the difference between these options, refer to Difference between self-signed CA and self-signed certificate.

Generate a self-signed certificate

This section shows you how to use openssl tooling to generate all necessary files from the command line.

Run the following command to generate a 2048-bit RSA private key, which is used to decrypt traffic:
Bash
```
$ sudo openssl genrsa -out /etc/grafana/grafana.key 2048
```

Run the following command to generate a certificate, using the private key from the previous step.

$ sudo openssl req -new -key /etc/grafana/grafana.key -out /etc/grafana/grafana.csr

When prompted, answer the questions, which might include your fully-qualified domain name, email address, country code, and others. The following example is similar to the prompts you will see.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Virginia
Locality Name (eg, city) []:Richmond
Organization Name (eg, company) [Internet Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:subdomain.mysite.com
Email Address []:me@mysite.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Run the following command to self-sign the certificate with the private key, for a period of validity of 365 days:

sudo openssl x509 -req -days 365 -in /etc/grafana/grafana.csr -signkey /etc/grafana/grafana.key -out /etc/grafana/grafana.crt

Run the following commands to set the appropriate permissions for the files:
Bash
```
sudo chown grafana:grafana /etc/grafana/grafana.crt
sudo chown grafana:grafana /etc/grafana/grafana.key
sudo chmod 400 /etc/grafana/grafana.key /etc/grafana/grafana.crt
```
Note: When using these files, browsers might provide warnings for the resulting website because a third-party source does not trust the certificate. Browsers will show trust warnings; however, the connection will remain encrypted.

The following image shows an insecure HTTP connection.

Insecure HTTPS connection

Obtain a signed certificate from LetsEncrypt

LetsEncrypt is a nonprofit certificate authority that provides certificates without any charge. For signed certificates, there are multiple companies and certificate authorities (CAs) available. The principles for generating the certificates might vary slightly in accordance with the provider but will generally remain the same.

The examples in this section use LetsEncrypt because it is free.

Note
The instructions provided in this section are for a Debian-based Linux system. For other distributions and operating systems, please refer to the certbot instructions. Also, these instructions require you to have a domain name that you are in control of. Dynamic domain names like those from Amazon EC2 or DynDNS providers will not function.

Install `snapd` and `certbot`

certbot is an open-source program used to manage LetsEncrypt certificates, and snapd is a tool that assists in running certbot and installing the certificates.

To install snapd, run the following commands:

sudo apt-get install snapd
sudo snap install core; sudo snap refresh core

Run the following commands to install:
Bash
```
sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
```
These commands:
- Uninstall certbot from your system if it has been installed using a package manager
- Install certbot using snapd

Generate certificates using `certbot`

The sudo certbot certonly --standalone command prompts you to answer questions before it generates a certificate. This process temporarily opens a service on port 80 that LetsEncrypt uses to verify communication with your host.

To generate certificates using certbot, complete the following steps:

Ensure that port 80 traffic is permitted by applicable firewall rules.

Run the following command to generate certificates:

$ sudo certbot certonly --standalone

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
(Enter 'c' to cancel): me@mysite.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let’s Encrypt project and the non-profit organization that
develops Certbot? We’d like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: n
Account registered.
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): subdomain.mysite.com
Requesting a certificate for subdomain.mysite.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem
This certificate expires on 2023-06-20.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let’s Encrypt:   https://letsencrypt.org/donate
* Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Set up symlinks to Grafana

Symbolic links, also known as symlinks, enable you to create pointers to existing LetsEncrypt files in the /etc/grafana directory. By using symlinks rather than copying files, you can use certbot to refresh or request updated certificates from LetsEncrypt without the need to reconfigure the Grafana settings.

To set up symlinks to Grafana, run the following commands:

$ sudo ln -s /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem /etc/grafana/grafana.key
$ sudo ln -s /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem /etc/grafana/grafana.crt

Adjust permissions

Grafana usually runs under the grafana Linux group, and you must ensure that the Grafana server process has permission to read the relevant files. Without read access, the HTTPS server fails to start properly.

To adjust permissions, perform the following steps:

Run the following commands to set the appropriate permissions and groups for the files:

$ sudo chgrp -R grafana /etc/letsencrypt/*
$ sudo chmod -R g+rx /etc/letsencrypt/*
$ sudo chgrp -R grafana /etc/grafana/grafana.crt /etc/grafana/grafana.key
$ sudo chmod 400 /etc/grafana/grafana.crt /etc/grafana/grafana.key

Run the following command to verify that the grafana group can read the symlinks:

$ $ ls -l /etc/grafana/grafana.*

lrwxrwxrwx 1 root grafana    67 Mar 22 14:15 /etc/grafana/grafana.crt -> /etc/letsencrypt/live/subdomain.mysite.com/fullchain.pem
-rw-r----- 1 root grafana 54554 Mar 22 14:13 /etc/grafana/grafana.ini
lrwxrwxrwx 1 root grafana    65 Mar 22 14:15 /etc/grafana/grafana.key -> /etc/letsencrypt/live/subdomain.mysite.com/privkey.pem

Configure Grafana HTTPS and restart Grafana

In this section you edit the grafana.ini file so that it includes the certificate you created. If you need help identifying where to find this file, or what each key means, refer to Configuration file location.

To configure Grafana HTTPS and restart Grafana, complete the following steps.

Open the grafana.ini file and edit the following configuration parameters:
```
[server]
http_addr =
http_port = 3000
domain = mysite.com
root_url = https://subdomain.mysite.com:3000
cert_key = /etc/grafana/grafana.key
cert_file = /etc/grafana/grafana.crt
enforce_domain = False
protocol = https
```
Note: The standard port for SSL traffic is 443, which you can use instead of Grafana’s default port 3000. This change might require additional operating system privileges or configuration to bind to lower-numbered privileged ports.
Restart the Grafana server using systemd, init.d, or the binary as appropriate for your environment.

Troubleshooting

Refer to the following troubleshooting tips as required.

Failure to obtain a certificate

The following reasons explain why the certbot process might fail:

To make sure you can get a certificate from LetsEncrypt, you need to ensure that port 80 is open so that LetsEncrypt can communicate with your machine. If port 80 is blocked or firewall is enabled, the exchange will fail and you won’t be able to receive a certificate.
LetsEncrypt requires proof that you control the domain, so attempts to obtain certificates for domains you do not control might be rejected.

Grafana starts, but HTTPS is unavailable

When you configure HTTPS, the following errors might appear in Grafana’s logs.

Permission denied

level=error msg="Stopped background service" service=*api.HTTPServer reason="open /etc/grafana/grafana.crt: permission denied"

Resolution

To ensure secure HTTPS setup, it is essential that the cryptographic keys and certificates are as restricted as possible. However, if the file permissions are too restricted, the Grafana process may not have access to the necessary files, thus impeding a successful HTTPS setup. Please re-examine the listed instructions to double check the file permissions and try again.

Cannot assign requested address

listen tcp 34.148.30.243:3000: bind: cannot assign requested address

Resolution

Check the config to ensure the http_addr is left blank, allowing Grafana to bind to all interfaces. If you have set http_addr to a specific subdomain, such as subdomain.mysite.com, this might prevent the Grafana process from binding to an external address, due to network address translation layers being present.

Set up image rendering

Fri, 07 Mar 2025 11:34:44 +0100

Set up image rendering

Grafana supports automatic rendering of panels as PNG images. This allows Grafana to automatically generate images of your panels to include in alert notifications, PDF export, and Reporting. PDF Export and Reporting are available only in Grafana Enterprise.

Note: Image rendering of dashboards is not supported at this time.

While an image is being rendered, the PNG image is temporarily written to the file system. When the image is rendered, the PNG image is temporarily written to the png folder in the Grafana data folder.

A background job runs every 10 minutes and removes temporary images. You can configure how long an image should be stored before being removed by configuring the temp_data_lifetime setting.

You can also render a PNG by hovering over the panel to display the actions menu in the top right corner, and then clicking Share > Direct link rendered image in the Link tab.

Alerting and render limits

Alert notifications can include images, but rendering many images at the same time can overload the server where the renderer is running. For instructions of how to configure this, see concurrent_render_limit.

Install Grafana Image Renderer plugin

Note
Starting from Grafana v7.0.0, all PhantomJS support has been removed. Please use the Grafana Image Renderer plugin or remote rendering service.

To install the plugin, refer to the Grafana Image Renderer Installation instructions.

Configuration

The Grafana Image Renderer plugin has a number of configuration options that are used in plugin or remote rendering modes.

In plugin mode, you can specify them directly in the Grafana configuration file.

In remote rendering mode, you can specify them in a .json configuration file or, for some of them, you can override the configuration defaults using environment variables.

Configuration file

You can update your settings by using a configuration file, see default.json for defaults. Note that any configured environment variable takes precedence over configuration file settings.

You can volume mount your custom configuration file when starting the docker container:

docker run -d --name=renderer --network=host -v /some/path/config.json:/usr/src/app/config.json grafana/grafana-image-renderer:latest

You can see a docker-compose example using a custom configuration file here.

Security

Note
This feature is available in Image Renderer v3.6.1 and later.

You can restrict access to the rendering endpoint by specifying a secret token. The token should be configured in the Grafana configuration file and the renderer configuration file. This token is important when you run the plugin in remote rendering mode.

Renderer versions v3.6.1 or later require a Grafana version with this feature. These include:

Grafana v9.1.2 or later
Grafana v9.0.8 or later patch releases
Grafana v8.5.11 or later patch releases
Grafana v8.4.11 or later patch releases
Grafana v8.3.11 or later patch releases

AUTH_TOKEN=-

{
  "security": {
    "authToken": "-"
  }
}

See Grafana configuration for how to configure the token in Grafana.

Rendering mode

You can instruct how headless browser instances are created by configuring a rendering mode. Default is default, other supported values are clustered and reusable.

Default

Default mode will create a new browser instance on each request. When handling multiple concurrent requests, this mode increases memory usage as it will launch multiple browsers at the same time. If you want to set a maximum number of browser to open, you’ll need to use the clustered mode.

Note
When using the default mode, it’s recommended to not remove the default Chromium flag --disable-gpu. When receiving a lot of concurrent requests, not using this flag can cause Puppeteer newPage function to freeze, causing request timeouts and leaving browsers open.

RENDERING_MODE=default

{
  "rendering": {
    "mode": "default"
  }
}

Clustered

With the clustered mode, you can configure how many browser instances or incognito pages can execute concurrently. Default is browser and will ensure a maximum amount of browser instances can execute concurrently. Mode context will ensure a maximum amount of incognito pages can execute concurrently. You can also configure the maximum concurrency allowed, which per default is 5, and the maximum duration of a rendering request, which per default is 30 seconds.

Using a cluster of incognito pages is more performant and consumes less CPU and memory than a cluster of browsers. However, if one page crashes it can bring down the entire browser with it (making all the rendering requests happening at the same time fail). Also, each page isn’t guaranteed to be totally clean (cookies and storage might bleed-through as seen here).

RENDERING_MODE=clustered
RENDERING_CLUSTERING_MODE=browser
RENDERING_CLUSTERING_MAX_CONCURRENCY=5
RENDERING_CLUSTERING_TIMEOUT=30

{
  "rendering": {
    "mode": "clustered",
    "clustering": {
      "mode": "browser",
      "maxConcurrency": 5,
      "timeout": 30
    }
  }
}

Reusable (experimental)

When using the rendering mode reusable, one browser instance will be created and reused. A new incognito page will be opened for each request. This mode is experimental since, if the browser instance crashes, it will not automatically be restarted. You can achieve a similar behavior using clustered mode with a high maxConcurrency setting.

RENDERING_MODE=reusable

{
  "rendering": {
    "mode": "reusable"
  }
}

Optimize the performance, CPU and memory usage of the image renderer

The performance and resources consumption of the different modes depend a lot on the number of concurrent requests your service is handling. To understand how many concurrent requests your service is handling, monitor your image renderer service.

With no concurrent requests, the different modes show very similar performance and CPU / memory usage.

When handling concurrent requests, we see the following trends:

To improve performance and reduce CPU and memory consumption, use clustered mode with RENDERING_CLUSTERING_MODE set as context. This parallelizes incognito pages instead of browsers.
If you use the clustered mode with a maxConcurrency setting below your average number of concurrent requests, performance will drop as the rendering requests will need to wait for the other to finish before getting access to an incognito page / browser.

To achieve better performance, monitor the machine on which your service is running. If you don’t have enough memory and / or CPU, every rendering step will be slower than usual, increasing the duration of every rendering request.

Other available settings

Note
Please note that not all settings are available using environment variables. If there is no example using environment variable below, it means that you need to update the configuration file.

HTTP host

Change the listening host of the HTTP server. Default is unset and will use the local host.

HTTP_HOST=localhost

{
  "service": {
    "host": "localhost"
  }
}

HTTP port

Change the listening port of the HTTP server. Default is 8081. Setting 0 will automatically assign a port not in use.

HTTP_PORT=0

{
  "service": {
    "port": 0
  }
}

Enable Prometheus metrics

You can enable Prometheus metrics endpoint /metrics using the environment variable ENABLE_METRICS. Node.js and render request duration metrics are included, see Enable Prometheus metrics endpoint for details.

Default is false.

ENABLE_METRICS=true

{
  "service": {
    "metrics": {
      "enabled": true,
      "collectDefaultMetrics": true,
      "requestDurationBuckets": [1, 5, 7, 9, 11, 13, 15, 20, 30]
    }
  }
}

Log level

Change the log level. Default is info and will include log messages with level error, warning and info.

LOG_LEVEL=debug

{
  "service": {
    "logging": {
      "level": "debug",
      "console": {
        "json": false,
        "colorize": true
      }
    }
  }
}

Verbose logging

Instruct headless browser instance whether to capture and log verbose information when rendering an image. Default is false and will only capture and log error messages. When enabled (true) debug messages are captured and logged as well.

Note that you need to change log level to debug, see above, for the verbose information to be included in the logs.

RENDERING_VERBOSE_LOGGING=true

{
  "rendering": {
    "verboseLogging": true
  }
}

Capture browser output

Instruct headless browser instance whether to output its debug and error messages into running process of remote rendering service. Default is false. This can be useful to enable (true) when troubleshooting.

RENDERING_DUMPIO=true

{
  "rendering": {
    "dumpio": true
  }
}

Custom Chrome/Chromium

If you already have Chrome or Chromium installed on your system, then you can use this instead of the pre-packaged version of Chromium.

Note
Please note that this is not recommended, since you may encounter problems if the installed version of Chrome/Chromium is not compatible with the Grafana Image renderer plugin.

You need to make sure that the Chrome/Chromium executable is available for the Grafana/image rendering service process.

CHROME_BIN="/usr/bin/chromium-browser"

{
  "rendering": {
    "chromeBin": "/usr/bin/chromium-browser"
  }
}

Start browser with additional arguments

Additional arguments to pass to the headless browser instance. Defaults are --no-sandbox,--disable-gpu. The list of Chromium flags can be found here and the list of flags used as defaults by Puppeteer can be found there. Multiple arguments is separated with comma-character.

RENDERING_ARGS=--no-sandbox,--disable-setuid-sandbox,--disable-dev-shm-usage,--disable-accelerated-2d-canvas,--disable-gpu,--window-size=1280x758

{
  "rendering": {
    "args": [
      "--no-sandbox",
      "--disable-setuid-sandbox",
      "--disable-dev-shm-usage",
      "--disable-accelerated-2d-canvas",
      "--disable-gpu",
      "--window-size=1280x758"
    ]
  }
}

Ignore HTTPS errors

Instruct headless browser instance whether to ignore HTTPS errors during navigation. Per default HTTPS errors are not ignored. Due to the security risk it’s not recommended to ignore HTTPS errors.

IGNORE_HTTPS_ERRORS=true

{
  "rendering": {
    "ignoresHttpsErrors": true
  }
}

Default timezone

Instruct headless browser instance to use a default timezone when not provided by Grafana, .e.g. when rendering panel image of alert. See ICU’s metaZones.txt for a list of supported timezone IDs. Fallbacks to TZ environment variable if not set.

BROWSER_TZ=Europe/Stockholm

{
  "rendering": {
    "timezone": "Europe/Stockholm"
  }
}

Default language

{
  "rendering": {
    "acceptLanguage": "fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5"
  }
}

Viewport width

Default viewport width when width is not specified in the rendering request. Default is 1000.

{
  "rendering": {
    "width": 1000
  }
}

Viewport height

Default viewport height when height is not specified in the rendering request. Default is 500.

{
  "rendering": {
    "height": 500
  }
}

Viewport maximum width

Limit the maximum viewport width that can be requested. Default is 3000.

{
  "rendering": {
    "maxWidth": 1000
  }
}

Viewport maximum height

Limit the maximum viewport height that can be requested. Default is 3000.

{
  "rendering": {
    "maxHeight": 500
  }
}

Device scale factor

Specify default device scale factor for rendering images. 2 is enough for monitor resolutions, 4 would be better for printed material. Setting a higher value affects performance and memory. Default is 1. This can be overridden in the rendering request.

{
  "rendering": {
    "deviceScaleFactor": 2
  }
}

Maximum device scale factor

Limit the maximum device scale factor that can be requested. Default is 4.

{
  "rendering": {
    "maxDeviceScaleFactor": 4
  }
}

Page zoom level

The following command sets a page zoom level. The default value is 1. A value of 1.5 equals 150% zoom.

RENDERING_VIEWPORT_PAGE_ZOOM_LEVEL=1

{
  "rendering": {
    "pageZoomLevel": 1
  }
}

Set up Grafana Live

Fri, 07 Mar 2025 11:34:44 +0100

Set up Grafana Live

Grafana Live is a real-time messaging engine introduced in Grafana v8.0.

With Grafana Live, you can 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.

Note
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 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 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 instructionsfor 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 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 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.

Configure a Grafana Docker image

Fri, 07 Mar 2025 11:34:44 +0100

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 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 base image, which can be found in the Alpine docker repo. 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 instead of glibc and others. 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 base image, which can be found in the Ubuntu docker repo. 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.

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.

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

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.

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.

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 and grafana/grafana-oss-dev.

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_INSTALL_PLUGINS environment variable: GF_INSTALL_PLUGINS=<url to plugin zip>;<plugin name>.

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_INSTALL_PLUGINS environment variable.

docker run -d -p 3000:3000 --name=grafana \
  -e "GF_INSTALL_PLUGINS=http://plugin-domain.com/my-custom-plugin.zip;custom-plugin,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:

# 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 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.

# 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. 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.

# 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.

# 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.

# 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, 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.

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:

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

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

echo "aws01us02" | docker secret create aws_access_key_id -

echo "topsecret9b78c6" | docker secret create aws_secret_access_key -

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

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

$ 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

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

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.

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.

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.

# 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.