metrico / qryn

⭐️ All-in-One Polyglot Observability with OLAP Storage for Logs, Metrics, Traces & Profiles. Drop-in Grafana Cloud replacement compatible with Loki, Prometheus, Tempo, Pyroscope, Opentelemetry, Datadog and beyond :rocket:
https://qryn.dev
GNU Affero General Public License v3.0
1.19k stars 67 forks source link

Post to /influxapi produce an error #462

Closed Friz-zy closed 7 months ago

Friz-zy commented 7 months ago

I'm testing latest qxip/qryn:bun with telegraf. I have a problem with password authorization:

When telegraf is configured with "Authorization" header in outputs.influxdb_v2

[[outputs.influxdb_v2]]
  urls = ["http://qryn:3100/influx"]
  http_headers = {"Authorization" = "Basic dGVzdDp0ZXN0"}

qryn produce metric parse error

qryn  | {"level":30,"time":1707766297655,"pid":1,"hostname":"66fe100c097b","name":"qryn","msg":"http://qryn:3100/influx/api/v2/write?bucket=&org="}
qryn  | 1 | const { asyncLogError } = require('../../common')
qryn  | 2 | 
qryn  | 3 | class QrynError extends Error {
qryn  | 4 |   constructor (code, name, message) {
qryn  | 5 |     super(message)
qryn  |         ^
qryn  | Bad Request: Error: metric parse error: expected tag at 1:187: "\x1f�\b\x00\x00\x00\x00\x00\x00��\\�r�Ǝ��O�\a���\x1b�\x1f|\x16���U�%�$�$�鷚�(~4)Mb�d���MKT��4\x1a8\a��m�{l\x0e��z�\x1d���yi���_\x7f9�뗇��Y?\x1dj߬6O/M<-- here"
qryn  |  code: "400"
qryn  | 
qryn  |       at new QrynError (/app/lib/handlers/errors.js:5:5)
qryn  |       at new QrynBadRequest (/app/lib/handlers/errors.js:13:5)
qryn  |       at /app/lib/handlers/influx_write.js:62:11
qryn  | POST - http://qryn:3100/influx/api/v2/write?bucket=&org= failed

Possibly this is a problem real metrics parsing because simple curl request works fine

curl -i -H "Authorization: Basic dGVzdDp0ZXN0" -XPOST 'http://192.168.99.101:3100/influx/api/v2/write?bucket=&org='   --data-raw 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Date: Mon, 12 Feb 2024 19:32:51 GMT
Content-Length: 0

When I tried url substitution in telegraf config

[[outputs.influxdb_v2]]
  urls = ["http://test:test@qryn:3100/influx"]

then telegraf just can't pass the authorization

telegraf  | 2024-02-12T19:35:26Z E! [outputs.influxdb_v2] When writing to [http://test:test@qryn:3100/influx]: failed to write metric to  (401 Unauthorized): 401 Unauthorized

Curl request works fine

curl -i -XPOST 'http://test:test@192.168.99.101:3100/influx/api/v2/write'   --data-raw 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Date: Mon, 12 Feb 2024 19:36:22 GMT
Content-Length: 0

Qryn is configured to use test as admin login and password

akvlad commented 7 months ago

Hello @Friz-zy A couple of questions of what you are trying to send. A very simple test

[[inputs.cpu]]
[[outputs.influxdb_v2]]
urls = ["http://localhost:3100/influx"]

worked. Can you share some information about what inputs you're using?

Friz-zy commented 7 months ago

@akvlad you can check telegraf config here. This repo contain whole test setup

lmangani commented 7 months ago

@Friz-zy I believe you need to use the influxdb_v2 output as @akvlad also suggested

Friz-zy commented 7 months ago

@lmangani this problem appears just when influxdb_v2 used, which you can see in my first comment. Right now this section is comment out in the config as latest what I tested was vmagent from victoriametrics as a proxy between telegraf and qryn. I haven't tried outputs.influxdb directly with qryn

akvlad commented 7 months ago

@Friz-zy Couldn't reproduce your case locally with a small local setup. Will try your whole environment.

I'll send a couple of issues into your github repo as I can't make it start.

Friz-zy commented 7 months ago

@akvlad I created a branch for you

git clone -b issues/462 git@github.com:Friz-zy/qryn-docker-s3.git /tmp/qryn
cd /tmp/qryn
docker-compose up -d
docker-compose ps
docker-compose logs -f telegraf
docker-compose logs -f qryn
docker-compose down
akvlad commented 7 months ago

@Friz-zy thanks. Will check and fix the issue. Can't reproduce for now.

akvlad commented 7 months ago

Hello @Friz-zy I have one suggestion for the error you experience. Please add a header to your configuration:

http_headers = {"Authorization" = "Basic dGVzdDp0ZXN0", "Content-Encoding" = "gzip"}

Is it possible that you send a gzipped body without the appropriate header? Please make sure that:

That is the only case when I see a similar error as you provide. On the other hand your telegram conf file provides no compression. It seems OK. Please try experimenting with the configuration:

  ## Content-Encoding for write request body, can be set to "gzip" to
  ## compress body or "identity" to apply no encoding.
  # content_encoding = "gzip"
akvlad commented 7 months ago

@Friz-zy fixed: https://github.com/Friz-zy/qryn-docker-s3/pull/1

Friz-zy commented 7 months ago

@akvlad that works, thank you. But but I'm seeing some strange behavior in the metric names: when I use outputs.prometheus_client or forward metrics via vmagent, then in tsdb metrics are stored in <module>_<metric name> format, for example system_n_cpus. But now with a direct entry in qryn I see a list of metrics without a module, for example n_cpus. Thus a very important part of the metric name is eaten.... I pushed everything to main so you can check with grafana

@lmangani possibly need to update docs with examples how to connect collectors using login & password. Also I can update my fork and open a pull request to your original repo qryn-docker-s3

akvlad commented 7 months ago

@Friz-zy As far as I understand module you say about is saved inside measurement tag value. Can you try reviewing the value of the measurement field?

Friz-zy commented 7 months ago

@akvlad yeah, measurement has the right information. It's a little unusual but works, thank you

akvlad commented 7 months ago

@Friz-zy It's about the format of influx -> prometheus conversion. We may reconsider the feature.

Friz-zy commented 7 months ago

@akvlad yeah, I can totally picture it. After victoriametrics it is unusual for me, but ideologically this variant may be more correct. Although again telegraf itself generates metrics for Prometheus exactly in the <module>_<metric> format...

lmangani commented 7 months ago

Can this issue be closed?