Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time Series: Missing support for Nanosecond precision #771

Closed
jirislav opened this issue Mar 22, 2024 · 1 comment
Closed

Time Series: Missing support for Nanosecond precision #771

jirislav opened this issue Mar 22, 2024 · 1 comment
Assignees
Labels
datasource/ClickHouse question Further information is requested

Comments

@jirislav
Copy link

What happened:

When I query the time field that includes nanoseconds (e.g. time DateTime64(9)), the data points gets cropped (in time) to the nearest millisecond, losing the information of microseconds & nanoseconds. But these data are important to me and I want to visualize the actual series of events how it happened during that one millisecond.

What you expected to happen:

To visualize the data points in time as they happened, without cropping the micros & nanos.

How to reproduce it (as minimally and precisely as possible):

Create table:

CREATE TABLE nanos (
  time DateTime64(9),
  value UInt32
) ENGINE = MergeTree
  ORDER BY time;

Fill it with some nanosecond data throughout 3 milliseconds:

INSERT INTO nanos SELECT
  now() + INTERVAL (number * 111111) NANOSECOND,
  number
FROM numbers(30);

What we'll get:

SELECT *
FROM nanos

┌──────────────────────────time─┬─value─┐
│ 2024-03-22 08:20:20.000000000 │     0 │
│ 2024-03-22 08:20:20.000111111 │     1 │
│ 2024-03-22 08:20:20.000222222 │     2 │
│ 2024-03-22 08:20:20.000333333 │     3 │
│ 2024-03-22 08:20:20.000444444 │     4 │
│ 2024-03-22 08:20:20.000555555 │     5 │
│ 2024-03-22 08:20:20.000666666 │     6 │
│ 2024-03-22 08:20:20.000777777 │     7 │
│ 2024-03-22 08:20:20.000888888 │     8 │
│ 2024-03-22 08:20:20.000999999 │     9 │
│ 2024-03-22 08:20:20.001111110 │    10 │
│ 2024-03-22 08:20:20.001222221 │    11 │
│ 2024-03-22 08:20:20.001333332 │    12 │
│ 2024-03-22 08:20:20.001444443 │    13 │
│ 2024-03-22 08:20:20.001555554 │    14 │
│ 2024-03-22 08:20:20.001666665 │    15 │
│ 2024-03-22 08:20:20.001777776 │    16 │
│ 2024-03-22 08:20:20.001888887 │    17 │
│ 2024-03-22 08:20:20.001999998 │    18 │
│ 2024-03-22 08:20:20.002111109 │    19 │
│ 2024-03-22 08:20:20.002222220 │    20 │
│ 2024-03-22 08:20:20.002333331 │    21 │
│ 2024-03-22 08:20:20.002444442 │    22 │
│ 2024-03-22 08:20:20.002555553 │    23 │
│ 2024-03-22 08:20:20.002666664 │    24 │
│ 2024-03-22 08:20:20.002777775 │    25 │
│ 2024-03-22 08:20:20.002888886 │    26 │
│ 2024-03-22 08:20:20.002999997 │    27 │
│ 2024-03-22 08:20:20.003111108 │    28 │
│ 2024-03-22 08:20:20.003222219 │    29 │
└───────────────────────────────┴───────┘

Screenshots

image

Anything else we need to know?:

🤷

Environment:

  • Grafana version: v10.0.2 (but this should be enough)
  • Plugin version: Don't know how to find out, but I've just installed it, so it's probably latest
  • OS Grafana is installed on: Docker image
  • User OS & Browser: Ubuntu 22.04 / Chrome Version 123.0.6312.58 (Official Build) (64-bit)
  • Others:
@SpencerTorres
Copy link
Collaborator

I believe this is a limitation of Grafana. The data is actually returned with nanoseconds to the browser (you can see the nanos field in the query inspector), but it will not be displayed on most panels. Internally it gets converted to a JavaScript Date, and those are limited to milliseconds. The same goes for the dashboard time range, so you cant even filter time ranges less than 1ms apart.

You might be able to find a workaround by converting the time to Unix nanos, and then instead of using a time chart just use a number chart, but filtering will be difficult. Keep in mind you might also need to scale the number to fit within JavaScript's number limit to prevent rounding issues.

Related discussion on Grafana: grafana/grafana#6252 (comment)

Related discussion on this repo #479

@SpencerTorres SpencerTorres added question Further information is requested and removed type/bug Something isn't working labels Mar 25, 2024
@SpencerTorres SpencerTorres self-assigned this Mar 25, 2024
@alyssabull alyssabull moved this from Incoming to Backlog in Partner Datasources Mar 25, 2024
@aangelisc aangelisc moved this from Backlog to Waiting in Partner Datasources Mar 25, 2024
@github-project-automation github-project-automation bot moved this from Waiting to Done in Partner Datasources Mar 25, 2024
@taleena taleena closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
datasource/ClickHouse question Further information is requested
Projects
Archived in project
Development

No branches or pull requests

3 participants