Skip to content
This repository has been archived by the owner on Dec 11, 2020. It is now read-only.

Is compatibility with InfluxDB 1.7.x broken? #100

Open
M0rdecay opened this issue May 19, 2020 · 16 comments
Open

Is compatibility with InfluxDB 1.7.x broken? #100

M0rdecay opened this issue May 19, 2020 · 16 comments

Comments

@M0rdecay
Copy link

M0rdecay commented May 19, 2020

After upgrading to Grafana 7.0, panels using Flux stopped working. The error is as follows:
image
In this case, the data source is ok:
image
This is a big problem, because InfluxDB newest than 1.7.3 cannot be used in highly loaded environments due to this error - influxdata/influxdb#13318

Are you planning to return compatibility with versions 1.7.x?

@ryantxu
Copy link
Member

ryantxu commented May 19, 2020

This plugin is now using this client: https://github.com/influxdata/influxdb-client-go/

I'm not sure what is involved in getting that client to read flux results from 1.7...

@ryantxu
Copy link
Member

ryantxu commented May 19, 2020

Any more details on the error you see? Is there anything in your browser console log? or maybe in the server logs?

@M0rdecay
Copy link
Author

M0rdecay commented May 20, 2020

Here is what information I managed to collect

In browser console:
image

From "Network" tab:

{results: {A: {error: ": ", refId: "A", series: null, tables: null, dataframes: null}}, message: ": "}
message: ": "
results: {A: {error: ": ", refId: "A", series: null, tables: null, dataframes: null}}
A: {error: ": ", refId: "A", series: null, tables: null, dataframes: null}
dataframes: null
error: ": "
refId: "A"
series: null
tables: null

InfluxDB logs (v1.7.3):

[httpd] 172.17.0.1 - - [20/May/2020:06:10:35 +0000] "POST /api/v2/query?org= HTTP/1.1" 500 95 "-" "influxdb-client-go/1.1.0  (linux; amd64)" 9e520a78-9a60-11ea-8dab-0242ac110002 7944
ts=2020-05-20T06:10:35.201599Z lvl=error msg="[500] - \"failed to compile query: type error 2:6-2:19: missing required parameter \\\"start\\\"\"" log_id=0Km0hH8W000 service=httpd

The time window in the request is set by the range function:

  |> range($range)

Please let me know if you need anything else.

@Akira74
Copy link

Akira74 commented May 20, 2020

Hi I also had the same error. This happens when you have setting
auth-enabled = true
In this case you must enter{username}:{password}into the token field. There will be an error shown
500 Internal Server Error: {"error":"panic: column retentionPeriod:int is not of type string"}
, when you save it but you can ignore that. The data source worked again.

@M0rdecay
Copy link
Author

In my case, the parameter is auth-enabled = false. I use Influxdb in container and the default valse is false.

List of what I redefine:

    INFLUXDB_DATA_MAX_SERIES_PER_DATABASE: "0"
    INFLUXDB_DATA_MAX_VALUES_PER_TAG: "0"
    INFLUXDB_RETENTION_ENABLED: "true"
    INFLUXDB_RETENTION_CHECK_INTERVAL: "10m"
    INFLUXDB_HTTP_MAX_BODY_SIZE: "50000000"
    INFLUXDB_META_RETENTION_AUTOCREATE: "false"
    INFLUXDB_DATA_INDEX_VERSION: "tsi1"
    INFLUXDB_DATA_WAL_FSYNC_DELAY: "100ms"
    INFLUXDB_HTTP_FLUX_ENABLED: "true"

@ext452
Copy link

ext452 commented May 26, 2020

@Akira74 not working (

@M0rdecay
Copy link
Author

Hello! Is there any news on this and #101?

@ryantxu
Copy link
Member

ryantxu commented May 31, 2020

@M0rdecay for your time filter, can you try:

|> range(start: v.timeRangeStart, stop:v.timeRangeStop)

rather than $range? if that change works, I'll look at adding some of the old macro expansions to help with migratoin. In v7, we aimed for getting copy/paste from chronograph to work

@M0rdecay
Copy link
Author

M0rdecay commented Jun 1, 2020

Thank you, I will try this solution:
|> range(start: v.timeRangeStart, stop:v.timeRangeStop)

we aimed for getting copy/paste from chronograph to work

IMHO, this breaks uniformity with Grafana as a whole. Variables are expected to have the same syntax everywhere.

@ryantxu
Copy link
Member

ryantxu commented Jun 1, 2020

Let me know if it works!

I wish variables had the same syntax everywhere! weirdly there are two concepts "template variables" and "macros" -- they look the same, but are actually totally differnt, when this switched to a backend plugin, it switched form a frontend template variable to a backend macro

@M0rdecay
Copy link
Author

M0rdecay commented Jun 1, 2020

Hm...
It works good with simple request:

from(bucket:"$database/$ret_policy")
  |> range(start: v.timeRangeStart, stop:v.timeRangeStop)
  |> filter(fn: (r) =>
    r._measurement == "cpu" and
    r._field == "usage_system" and
    r.cpu == "cpu-total"
  )

But it fails when request has group() function (Grafana log, 7.0.1, image grafana/grafana:7.0.1):

t=2020-06-01T06:24:30+0000 lvl=eror msg="Metric request error" logger=context userId=1 orgId=1 uname=admin error="rpc error: code = Unavailable desc = transport is closing" remote_addr=xxx.xxx.xxx.xxx
t=2020-06-01T06:24:30+0000 lvl=eror msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=POST path=/api/ds/query status=500 remote_addr=xxx.xxx.xxx.xxx time_ms=1752 size=34 referer="http://grafana:3001/d/NtNnqDjWk/area?orgId=1&refresh=1m&editPanel=49"
t=2020-06-01T06:24:31+0000 lvl=info msg=Profiler logger=plugins.backend pluginId=grafana-influxdb-flux-datasource enabled=false
t=2020-06-01T06:24:31+0000 lvl=eror msg="Metric request error" logger=context userId=1 orgId=1 uname=admin error="rpc error: code = Unavailable desc = connection error: desc = \"transport: error while dialing: dial unix /tmp/plugin105981337: connect: connection refused\"" remote_addr=xxx.xxx.xxx.xxx
t=2020-06-01T06:24:31+0000 lvl=eror msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=POST path=/api/ds/query status=500 remote_addr=xxx.xxx.xxx.xxx time_ms=0 size=34 referer="http://grafana:3001/d/NtNnqDjWk/area?orgId=1&refresh=1m&editPanel=49"

Very strange, but everything is fine in the InfluxDB log:

[httpd] 172.17.0.1 - - [01/Jun/2020:06:24:30 +0000] "POST /api/v2/query?org= HTTP/1.1" 200 948 "-" "influxdb-client-go/1.1.0  (linux; amd64)" aec707f3-a3d1-11ea-8d6e-0242ac110002 1596765

Upd. group statement: |> group(columns: ["appl"], mode:"by")

@M0rdecay
Copy link
Author

M0rdecay commented Jun 1, 2020

It seems that the situation is also happening on other versions of InfluxDB - #109

@M0rdecay
Copy link
Author

M0rdecay commented Jun 1, 2020

This is an example of a query that has a problem. The first filter is intentionally replaced by neutral data, but still displays the essence of the situation:

errs = from(bucket: "$database/$ret_policy")
  |> range(start: v.timeRangeStart, stop:v.timeRangeStop)
  |> filter(fn:(r) => (r._measurement == "cpu" 
                       or r._measurement == "mem")
                   and (r._field == "used_percent"
                       or r._field == "usage_system"))
  |> group(columns: ["host"], mode:"by")
  |> derivative(unit: $coll_interval, nonNegative: true)
  |> aggregateWindow(every: $coll_interval, fn: sum)
  |> filter(fn: (r) => r["_value"] >= 0)
  |> yield()

But this request is working fine:

errs = from(bucket: "$database/$ret_policy")
  |> range(start: v.timeRangeStart, stop:v.timeRangeStop)
  |> filter(fn:(r) => (r._measurement == "cpu" 
                       or r._measurement == "mem")
                   and (r._field == "used_percent"
                       or r._field == "usage_system"))

  |> derivative(unit: $coll_interval, nonNegative: true)
  |> aggregateWindow(every: $coll_interval, fn: sum)
  |> filter(fn: (r) => r["_value"] >= 0)
  |> yield()

@M0rdecay
Copy link
Author

M0rdecay commented Jun 3, 2020

Let's leave this issue open with the following wording - for compatibility with previous versions of the plugin needs support for the $range variable.

A discussion of the function of the group() function, let's continue at #105

@andig
Copy link

andig commented Jun 5, 2020

for compatibility with previous versions of the plugin needs support for the $range variable.

How are dashboard variables handled? Are those still supported with their $var notation?

@M0rdecay
Copy link
Author

M0rdecay commented Jun 5, 2020

Are those still supported with their $var notation?

Yes, the rest of the variables work, I had no problems using them. Only plugin-specific variables have changed. The full list can be found here - https://github.com/grafana/influxdb-flux-datasource/blob/master/pkg/influx/macros.go

This plugin really needs documentation!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants