InfluxDB app (version >= 2.04): use of influx CLI?

[LunatiX]

Is it possible to use the influx CLI (command line interface)? Or how could we interact and export data from influxDB t.e. into a csv file?

In old influxDB versions there was a button "CSV" which unfortunately isn't available anymore:

[Sgilk]

Hi @LunatiX ,

This seems to be a known issue with this version of InfluxDB... I tried with HTTPS and Firefox and have not been able to get the CSV export button to display.

You can use the REST API or CLI to retrieve data in csv format. I would suggest the REST API as it can be used from many standard clients. See the documentation for a walkthrough.

Here is an example I just tried on a Virtual CORE using Postman.

I sent a POST request to the API query URL with my organization ID as a query paramater.

https://127.0.0.1:8443/influxdb/api/v2/query?orgID=98d3f3e96e7bd66

I used Bearer Token authorization, with an all access API token, generated within my InfluxDB.

I set the Content-type header to application/vnd.flux

In the request body, I used the following query, generated using the graphical query builder of InfluxDB.

query=from(bucket: "Test")
  |> range(start: -12h)
  |> filter(fn: (r) => r["_measurement"] == "metrics")
  |> filter(fn: (r) => r["_field"] == "cpu_usage_percent")
  |> aggregateWindow(every: 1h, fn: mean)
  |> yield(name: "mean")

I recieved a response of csv data.

,result,table,_start,_stop,_time,_value,_field,_measurement,host,node,source
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T05:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T06:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T07:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T08:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T09:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T10:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T11:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T12:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T13:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T14:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T15:00:00Z,,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T16:00:00Z,4.22110807647288,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost
,mean,0,2023-12-21T04:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,2023-12-21T16:34:28.8461513Z,4.117602427921053,cpu_usage_percent,metrics,VirtualControl-2-2-4,framework/metrics/system/cpu-utilisation-percent,localhost

[MauroRiboniMX]

Seen also,

Lready discussed with the devs but it doens't depend by us!

[ctrlXnovo]

If Influx will not add this feature back, I'd consider adding it to our InfluxDB app.  It was super useful.  I am currently setting up a system to record data for a customer and now I need to step back and develop a new way to do this since the button is gone in the later versions.  We developed instructions for the customer to get the data without us, since it was simple.  Now it is not.  Going back to an old version is probably my best choice with the time I have left.

[Mbrue]

trying this method as i need to estimate 'record' size for a specific test run for long term operation/storage.  I am getting an ssl error from postman on version error.  Anyone else run into anything like this?  has there been any movement on implementing a fix for this issue?

[Sgilk]

@Mbrue ,

As the save to CSV feature was removed by InfluxDB, I have not heard of any plans to reimplement it.

What exactly is the error message? Can you please post your Postman request configuration? I have been using this method with great results.

[Mbrue]

well dang.  Without the CSV function and easy access to CLI I will probably need another DB.  I needed to use influx as a MITM to route to custom data analytics.

the error i recieve is (using port 8443)

otherwise I recieve no data and just a standard response from port 8086.  

"cURL

curl --request POST \

 'http://##IP:8086/influxdb/api/v2/query?orgID=##number' \

--header 'Content-Type: application/vnd.flux' \

--header 'Accept-Encoding: gzip' \

--header 'Accept: application/csv' \

--header 'Authorization: Bearer ##Token \

--data 'from(bucket: "ctrlx-core-telegraf")

  |> range(start: -60d)

  |> filter(fn: (r) => r["_measurement"] == "TestData")

  |> aggregateWindow(every: 10ms, fn: max, createEmpty: false)

  |> yield(name: "max")'

any and all help is always greatly appreciated

[Sgilk]

@Mbrue ,

Try removing the port from your URL. This is handled internally by the ctrlX reverse proxy.

Example exported from Postman...

curl --location 'https://192.168.1.100/influxdb/api/v2/query?orgID=7f03e1bf427b83d0' \
--header 'Content-Type: application/vnd.flux' \
--data 'query=from(bucket: "Demo Bucket")
  |> range(start: -12h)
  |> filter(fn: (r) => r["_measurement"] == "metrics")
  |> filter(fn: (r) => r["_field"] == "tempF")
  |> aggregateWindow(every: 1h, fn: mean)
  |> yield(name: "mean")'

[Mbrue]

That part did the trick. 

Now I need to get InfluxDB to give out more than 100mb at a time.  I have a lot of time series fields.

Thanks!

Mike

[Sgilk]

@Mbrue ,

Could you issue more queries requesting smaller increments on the client side?
For example, rather than requesting the last 60 days once, request the last 24 hours 60 times. You can then compile the data in the client.

[Mbrue]

i am doing that manually right now to estimate record size for the test.  While not overly burdensome, it is a bit beyond what I would expect of operators/technicians running the test.  Ideally this could be an automated script st that lives somewhere and runs hourly to update a RDB or something.