InfluxDB Exporter uses unsupported ns precision instead of nanosecond for InfluxDB 3 Core

[StevenSeeger]

Component(s)

No response

What happened?

Description

When exporting logs to InfluxDB 3 Core using the official influxdb exporter in opentelemetry-collector-contrib, the exporter sends the timestamp precision as ns. InfluxDB 3 Core expects nanosecond (not ns), resulting in errors like:

serde error: unknown variant `ns`, expected one of `auto`, `second`, `millisecond`, `microsecond`, `nanosecond`

Steps to Reproduce

1. Configure the OpenTelemetry Collector with the influxdb exporter targeting InfluxDB 3 Core.
2. Send logs via OTLP to the collector.
3. Observe the error in the collector logs and InfluxDB response.

Expected Result

The exporter should use nanosecond as the precision value, or allow configuration of the precision.

Actual Result

The exporter hardcodes ns as the precision, which is rejected by InfluxDB 3 Core.

Collector version

0.137.0

Environment information

Environment:

OpenTelemetry Collector Contrib version: 0.137.0 (latest)
InfluxDB version: 3-core
Exporter config:

exporters:
  influxdb:
    endpoint: http://influxdb:8086/api/v3/write_lp
    token: <token>
    org: <org>
    bucket: <bucket>
    timeout: 30s

OpenTelemetry Collector configuration

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

exporters:
  influxdb:
    endpoint: http://influxdb:8086/api/v3/write_lp?precision=nanosecond
    token: <token>
    org: <org>
    bucket: <bucket>
    timeout: 30s
    metrics_schema: telegraf-prometheus-v2
    
  debug:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 200

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, influxdb]
    
  telemetry:
    logs:
      level: debug

Log output

"exporter", "otelcol.signal": "logs", "error": "not retryable error: Permanent error: line protocol write returned \"400 Bad Request\" \"serde error: unknown variant `ns`, expected one of `auto`, `second`, `millisecond`, `microsecond`, `nanosecond`\"", "dropped_items": 1}

Additional context

Direct HTTP API ingestion with precision=nanosecond works as expected.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[paulojmdias]

/label exporter/influxdb -needs-triage

[github-actions]

Pinging code owners for exporter/influxdb: @jacobmarble. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triage' to set the priority and remove the needs-triage label.

[jacobmarble]

InfluxDB 3 Core expects nanosecond (not ns)

The /api/v3/write_lp prefix is new to me, but it's well documented here:

By default, InfluxDB 3 Core uses the timestamp magnitude to auto-detect the precision.

A couple of suggestions:

• Try the v2 API instead. I notice that even Telegraf doesn't have an InfluxDB v3 output plugin yet.
• Drop ?precision=nanosecond from the endpoint parameter in the otelcol-contrib config.
• Open a new issue in https://github.com/influxdata/influxdb

[jacobmarble]

@srebhan can you assist?

[StevenSeeger]

V2 api works, but I think there is value in adding the option to configure the precision that is used. InfluxDB has better performance when the coarseness of the precision is higher

[philjb]

We're having a discussion within influxdbv3 for the api/v3/write_lp endpoint to decide if we want to stick to full names second, nanosecond, etc or additionally support the full and short forms: which would be a superset of what the v1 or v2 endpoints support.

I do agree with this observation:

there is value in adding the option to configure the precision that is used

I think you should hold off on your pr for a moment though.

[StevenSeeger]

I think you should hold off on your pr for a moment though.

Happy to hold off - will wait on your decision for the PR at the moment.

[jacobmarble]

Let's determine whether https://github.com/influxdata/influxdb-observability/ needs an update.

@StevenSeeger:

Why have you configured otelcol to write to /api/v3/write_lp instead of /api/v2/write?

@philjb:

Should people expect a line protocol client tested with /write ("v1") and /api/v2/write ("v2") to work with the new /api/v3/write_lp endpoint, without modifications?

What advantage does /api/v3/write_lp offer? Should people be encouraged to switch?

[StevenSeeger]

Why have you configured otelcol to write to /api/v3/write_lp instead of /api/v2/write?

Just following the docs - no better reason than that haha. Ended up using /api/v2/write to get things to work in the meantime