Grafana logging entry when using influxdb as a datadource

Since upgrading Grafana to the latest version.

Every time I use a dashboard that is using influxdb as a datasource I am getting multiple log entries. Is there some setting I could set to stop this without changing my current logging level for Grafana.

<30>1 2026-06-23T09:58:15.765877-04:00 raspberry05 grafana 42357 - - {“@levellevellevellevel”:“deb@m@messagessageg”,“@message”:“Reading data frames from que@tim@timestampstampy result”,“@timestamp”:“2026-06-23T09:58:15.765762-04:00”,“logger”:“tsdb.influx_flux”,“maxPoints”:4230,“maxSeries”:1000}

<30>1 2026-06-23T12:56:31.318955-04:00 raspbe@levelry05 grafan@message 42357 - - {“@level”:“debug”,“@message”:“Re@timestampding data frames from query result”,“@timestamp”:“2026-06-23T12:56:31.318863-04:00”,“logger”:“tsdb.influx_flux”,“maxPoints”:10000,“maxSeries”:1000}

info <30>1 2026-06-23T12:56:@level1.30369-04:@message0 raspberry05 grafana 4235@timestamp - - {“@level”:“debug”,“@message”:“Executing Flux query”,“@timestamp”:“2026-06-23T12:56:31.303177-04:00”,“flux”:“buckets()”,“logger”:“tsdb.influx_flux”}

info <30@level1 2026-06-2@messageT12:56:31.303481-04:00 raspber@timestampy05 grafana 42357 - - {“@level”:“debug”,“@message”:“Making a Flux type query”,“@timestamp”:“2026-06-23T12:56:31.303071-04:00”,“logger”:“ts@levelb.influxdb”@message

info <30>1 2026-06-23T12:56:@timestamp1.3034-04:00 raspberry05 grafana 42357 - - {“@level”:“debug”,“@message”:“Received a query request”,“@timestamp”:“2026-06-23T12:56:31.303019-04:00”,“logger”:“tsdb.influxdb”,“numQueries”:1}

Screenshot 2026-06-24 193316

You can suppress just the InfluxDB debug logs without touching your global log level by using Grafana’s per-logger filter(filter applied to a specific logger, not globally)
in grafana.ini.

Open grafana.ini:

bash

sudo nano /etc/grafana/grafana.ini

Find the [log] section and add this line:

ini

[log]
filters = tsdb.influx_flux:error,tsdb.influxdb:error

Restart Grafana

bash

sudo systemctl restart grafana-server

Verify the debug logs are gone:

bash

sudo journalctl -u grafana-server -f

This targets only the two loggers generating the noise tsdb.influx_flux and tsdb.influxdb and sets them to error level only. Your global log level remains completely untouched.

If your [log] section already has other settings, then add the filters line to the existing section, no need to create a duplicate [log] section.

Unfortunately that did not change anything.

<30>1 2026-06-25T06:32:26.808497-04:00 raspberry05 grafana 53713 - - {“@levellevel”:“deb@messageg”,“@message”:“Reading data frames from que@timestampy result”,“@timestamp”:“2026-06-25T06:32:26.808395-04:00”,“logger”:“tsdb.influx_flux”,“maxPoints”:5420,“maxSeries”:1000}

info <30>1 2026-06-25T06:32:26.724013-04:00 raspberry05@levelgrafana 537@message3 - - {“@level”:“debug”,“@message”:“Reading@timestampdata frames from query result”,“@timestamp”:“2026-06-25T06:32:26.723880-04:00”,“logger”:“tsdb.influx_flux”,“maxPoints”:5420,“maxSeries”:1000}

info <30>1 2026-06-25T06:32:26.720@level91-04:00 ra@messagepberry05 grafana 53713 - - {“@level”:“debug@timestamp,”@message":“Reading data frames from query result”,“@timestamp”:“2026-06-25T06:32:26.718820-04:00”,“logger”:“tsdb.influx_flux”,“maxPoints”:5420,“maxSeries”:1000}

info <30>1 20@level6-06-25T06:@message2:26.720206-04:00 raspberr@timestamp05 grafana 53713 - - {“@level”:“debug”,“@message”:“Executing Flux query”,“@timestamp”:“2026-06-25T06:32:26.717266-04:00”,“flux”:“bytes_used = from(bucket: \“influxdb_mon\”)\r\n |\u003e range(start: 2026-06-25T09:32:26.744Z, stop: 2026-06-25T10:32:26.744Z)\r\n |\u003e filter(fn: (r) =\u003e r._measurement == \“go_memstats_alloc_bytes\”)\r\n |\u003e filter(fn: (r) =\u003e r._field == \“gauge\”)\r\n |\u003e aggregateWindow(every: 5s, fn: mean, createEmpty: false)\r\n |\u003e drop(columns: [\”_start\“, \”_stop\“])\r\n \r\ntotal_bytes = from(bucket: \“influxdb_mon\”)\r\n |\u003e range(start: 2026-06-25T09:32:26.744Z, stop: 2026-06-25T10:32:26.744Z)\r\n |\u003e filter(fn: (r) =\u003e r._measurement == \“go_memstats_sys_bytes\”)\r\n |\u003e filter(fn: (r) =\u003e r._field == \“gauge\”)\r\n |\u003e aggregateWindow(every: 5s, fn: mean, createEmpty: false)\r\n |\u003e drop(columns: [\”_start\“, \”_stop\“])\r\n\r\njoin(tables: {key1: bytes_used, key2: total_bytes}, on: [\”_time\“, \”_field\“], method: \“inner\”)\r\n |\u003e map(fn: (r) =\u003e ({\r\n _time: r._time,\r\n _value: (float(v: r._value_key1) / float(v: r._value_key2)) * 100.0,\r\n _field: \“Memory Usage Percent\”\r\n }))\r\n |\u003e yield(name: \“percentage\”)”,“logger”:“tsdb.influx_@levellux”}

info@message<30>1 2026-06-25T06:32@timestamp26.720043-04:00 raspberry05 grafana 53713 - - {“@level”:“debug”,“@message”:“Received a query”,“@timestamp”:“2026-06-25T06:32:26.716898-04:00”,“logger”:“tsdb.influx_flux”,“query”:{“PluginContext”:{“OrgID”:1,“PluginID”:“influxdb”,“PluginVersion”:“13.1.0”,“User”:{“Login”:“admin”,“Name”:“admin”,“Email”:“admin@localhost”,“Role”:“Admin”},“AppInstanceSettings”:null,“DataSourceInstanceSettings”:{“ID”:3,“UID”:“af6tqkzp6r8xsd”,“Type”:“influxdb”,“Name”:“influxdb”,“URL”:“https://rp5-util03.dbonenet.com:8086”,“User”:“”,“Database”:“”,“BasicAuthEnabled”:true,“BasicAuthUser”:“”,“JSONData”:{“dbName”:“pingtest”,“defaultBucket”:“pingtest”,“httpMode”:“POST”,“insecureGrpc”:false,“organization”:“homenet”,“pdcInjected”:false,“version”:“Flux”},“DecryptedSecureJSONData”:{“token”:“uxifWDhieter42ZIZDInCPsHijF2p9E-3KHqFdTQEEm94VjSa41sVEIr7U9fX5HengK05Pe9FKdf10BvZz1gtg==”},“Updated”:“2026-02-17T19:47:11-05:00”,“APIVersion”:“”},“GrafanaConfig”:{},“UserAgent”:{},“APIVersion”:“”,“Namespace”:“default”},“Headers”:{“http_X-Dashboard-Title”:“InfluxDB 2.0 OSS Metrics”,“http_X-Dashboard-Uid”:“iZYe3m2Gz”,“http_X-Datasource-Uid”:“af6tqkzp6r8xsd”,“http_X-Grafana-Id”:“eyJhbGciOiJFUzI1NiIsImtpZCI6ImlkLTIwMjYtMDYtZXMyNTYiLCJ0eXAiOiJqd3QifQ.eyJhdWQiOiJvcmc6MSIsImVtYWlsIjoiYWRtaW5AbG9jYWxob3N0IiwiZXhwIjoxNzgyMzgzODM1LCJpYXQiOjE3ODIzODMyMzUsImlkZW50aWZpZXIiOiJkZjR3czFxZncxYzc0ZSIsImlzcyI6Imh0dHBzOi8vcmFzcGJlcnJ5MDUuZGJvbmVuZXQuY29tOjM0NDMvIiwibmFtZSI6ImFkbWluIiwibmFtZXNwYWNlIjoiZGVmYXVsdCIsInJvbGUiOiJBZG1pbiIsInN1YiI6InVzZXI6MSIsInR5cGUiOiJ1c2VyIiwidXNlcm5hbWUiOiJhZG1pbiJ9.DTpXKY3XReSDrXHZo8WYsiqTWr76ssjsypsdFpsTyBayWnuwL1yzGJwZX5yzuA5kQnYVuQoOkYqQbZ25yWJ8qA”,“http_X-Grafana-Org-Id”:“1”,“http_X-Panel-Id”:“11”,“http_X-Panel-Plugin-Id”:“timeseries”,“http_X-Panel-Title”:“Memory Usage [%]”},“Queries”:[{“RefID”:“A”,“QueryType”:“”,“MaxDataPoints”:542,“Interval”:5000000000,“TimeRange”:{“From”:“2026-06-25T09:32:26.744Z”,“To”:“2026-06-25T10:32:26.744Z”},“JSON”:{“datasource”:{“type”:“influxdb”,“uid”:“af6tqkzp6r8xsd”},“datasourceId”:3,“groupBy”:[{“params”:[“$__interval”],“type”:“time”},{“params”:[“null”],“type”:“fill”}],“hide”:false,“intervalMs”:5000,“maxDataPoints”:542,“orderByTime”:“ASC”,“policy”:“default”,“query”:“bytes_used = from(bucket: \“influxdb_mon\”)\r\n |\u003e range(start: v.timeRangeStart, stop: v.timeRangeStop)\r\n |\u003e filter(fn: (r) =\u003e r._measurement == \“go_memstats_alloc_bytes\”)\r\n |\u003e filter(fn: (r) =\u003e r._field == \“gauge\”)\r\n |\u003e aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)\r\n |\u003e drop(columns: [\”_start\“, \”_stop\“])\r\n \r\ntotal_bytes = from(bucket: \“influxdb_mon\”)\r\n |\u003e range(start: v.timeRangeStart, stop: v.timeRangeStop)\r\n |\u003e filter(fn: (r) =\u003e r._measurement == \“go_memstats_sys_bytes\”)\r\n |\u003e filter(fn: (r) =\u003e r._field == \“gauge\”)\r\n |\u003e aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)\r\n |\u003e drop(columns: [\”_start\“, \”_stop\“])\r\n\r\njoin(tables: {key1: bytes_used, key2: total_bytes}, on: [\”_time\“, \”_field\“], method: \“inner\”)\r\n |\u003e map(fn: (r) =\u003e ({\r\n _time: r._time,\r\n _value: (float(v: r._value_key1) / float(v: r._value_key2)) * 100.0,\r\n _field: \“Memory Usage Percent\”\r\n }))\r\n |\u003e yield(name: \“percentage\”)”,“refId”:“A”,“resultFormat”:“time_series”,“select”:[[{“params”:[“value”],“type”:“field”},{“params”:[],“type”:“mean”}]@level,“tags”:[]}@message],“Format”:0}}

info <30>1 202@timestamp-06-25T06:32:26.719934-04:00 raspberry05 grafana 53713 - - {“@level”:“debug”,“@message”:“Making a Flux type query”,“@timestamp”:“2026-06-25T06:32:26.716846-04:00”,“logger”:“tsdb.influxdb”}

Not seeing anything from Grafana restart notable in the logs.

pi@raspberry05:~ $ sudo journalctl -u grafana-server -f
Jun 25 06:39:42 raspberry05 systemd[1]: Stopping grafana-server.service - Grafana instance…
Jun 25 06:39:42 raspberry05 grafana[53713]: logger=plugin.zipkin t=2026-06-25T06:39:42.830868622-04:00 level=error msg=“plugin process exited” plugin=/var/lib/grafana/plugins/zipkin/gpx_grafana-zipkin-datasource_linux_arm64 id=53731 error=“signal: terminated”
Jun 25 06:39:42 raspberry05 grafana[53713]: logger=plugin.elasticsearch t=2026-06-25T06:39:42.831103901-04:00 level=error msg=“plugin process exited” plugin=/var/lib/grafana/plugins/elasticsearch/gpx_grafana_elasticsearch_datasource_linux_arm64 id=53722 error=“signal: terminated”
Jun 25 06:39:42 raspberry05 grafana[53713]: t=2026-06-25T06:39:42.83218807-04:00 level=error caller=logger.go:234 time=2026-06-25T06:39:42.832170922-04:00 msg=“job cleanup controller failed” error=“context canceled”
Jun 25 06:39:42 raspberry05 systemd[1]: grafana-server.service: Deactivated successfully.
Jun 25 06:39:42 raspberry05 systemd[1]: Stopped grafana-server.service - Grafana instance.
Jun 25 06:39:42 raspberry05 systemd[1]: grafana-server.service: Consumed 6.987s CPU time.
Jun 25 06:39:42 raspberry05 systemd[1]: Started grafana-server.service - Grafana instance.
Jun 25 06:39:44 raspberry05 grafana[53811]: t=2026-06-25T06:39:44.193112149-04:00 level=warn caller=logger.go:224 time=2026-06-25T06:39:44.193087316-04:00 msg=“skipped registering status sub-resource that does not support dual writing” resource=recordingrules.rules.alerting.grafana.app version=v0alpha1 storagePath=recordingrules/status
Jun 25 06:39:50 raspberry05 grafana[53811]: logger=resource-client-auth-interceptor t=2026-06-25T06:39:50.004635668-04:00 level=warn msg=“calling resource store as the service without id token or marking it as the service identity” subject=:0 uid=:0

Looking at your logs, every entry shows "@level":"debug". The filter should be suppressing these → so something in the config isn’t being applied correctly.

Can you run this to show exactly what your [log] section currently has:
bash

sudo grep -v '^;' /etc/grafana/grafana.ini | grep -A10 '\[log\]'

This will confirm whether the filters line was saved correctly and is actually being read by Grafana.

if config is correct then error is at syslog level →
Filter at the rsyslog level to drop these specific Grafana debug messages.
Add this to rsyslog config:
bash

sudo nano /etc/rsyslog.d/10-grafana-filter.conf

Add this content:

:msg, contains, "tsdb.influx_flux" stop
:msg, contains, "tsdb.influxdb" stop

Then restart rsyslog:
bash

sudo systemctl restart rsyslog

Here is the ini info requested.

Not sure why but, all lines are commented out with the exception of level and filters.
Just didn’t paste right I guess.

pi@raspberry05:~ $ sudo grep -v ‘^;’ /etc/grafana/grafana.ini | grep -A10 ‘[log]’
[log]

Either “console”, “file”, “syslog”. Default is console and file

Use space to separate multiple modes, e.g. “console file”

Either “debug”, “info”, “warn”, “error”. Default is “info”

level = warn

optional settings to set different levels for specific loggers. Ex filters = sqlstore:debug

filters = tsdb.influx_flux:error,tsdb.influxdb:error

Set the default error message shown to users. This message is displayed instead of sensitive backend errors which should be obfuscated. Default is the same as the sample value.

--

[log].filter = rendering:debug.

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.

Instruct headless browser instance whether to register metrics for the duration of every rendering step. Default is false.

This can be useful to enable (true) when optimizing the rendering mode settings to improve the plugin performance or when troubleshooting.

This is a configuration for OTLP exporter with HTTP protocol, set this URL to enable tracing (ex: http://localhost:4318/v1/traces). Default to empty (tracing disabled).

Additional arguments to pass to the headless browser instance. Default is --no-sandbox. The list of Chromium flags can be foundstrong text

I can filter at the rsyslog level but I am afraid that filters too much. I would still like to see warn or error levels.

Added rsyslog filter to stop debug influx messages.

if ($msg contains ‘“logger”:“tsdb.influx_flux”’ or $msg contains ‘“logger”:“tsdb.influxdb”’) and ($msg contains ‘“@level”:“debug”’) then {
stop
}

Would prefer to clean this up from Grafana logs instead.

Your rsyslog filter looks correct → it only drops debug messages from the tsdb.influx_flux and tsdb.influxdb loggers while still allowing warn and error messages through.

Based on what you’ve shared, your grafana.ini logging configuration also looks correct, so I wouldn’t expect those debug messages to still be emitted. This suggests the logger-specific filters setting may not be honored for these loggers in your Grafana version.

If you’re on the latest Grafana release and can reproduce this consistently, it’s worth opening an issue on the Grafana GitHub repository so the maintainers can investigate:

Found I need to add tsdb.tempo due to the same behavior in the grafana.log.

<30>1 2026-06-27T08:22:06.651908-04:00 raspberry05 grafana 66310 - - {“@level”:“debug”,“@message”:“gRPC streaming call completed”,“@timestamp”:“2026-06-27T08:22:06.651747-04:00”,“duration_ms”:1,“logger”:“tsdb.tempo”,“method”:“/tempopb.StreamingQuerier/Search”,“status”:“OK”}

Added tsdb.tempo:error to the grafana.ini per-logger filter line. Also included it into the rsyslog filter.

Good find → tsdb.tempo follows the same pattern. Glad you caught it.