Skip to content

Interval parameter for log queries #1779

@slim-bean

Description

@slim-bean

Recently I created #1773 and after merging realized that Grafana defaults to sending a step with log queries. I would consider this a bug but be that as it may keeping #1773 would result in some pretty nasty unexpected behavior when using Grafana against Loki (even if we fixed Grafana old versions would still be sending this parameter)

#1773 was reverted by #1777 however I would still like to add this feature and I can think of a couple ways to do it:

  • Use a new parameter, I am suggesting log_step
  • Use a new header such as: Accept: application/json;version=2

Some more thoughts:

I think the step functionality is worth having in Loki. While Loki is a logs database, more specifically it is a string database extended from a metric database (Cortex) and I think it's a valid use case to store string style metrics in Loki (e.g. GPS coordinates, or a more complex json doc of metrics), as such the step parameter is of great value at query time to allow range queries which return sane result sizes over different time periods.

At this point it's much too dangerous to just start using the "step" for log style queries, we use it correctly for metric style queries but previously it was just ignored by Loki for log queries.

I think of the two approaches mentioned above, I prefer the new parameter log_step for a few reasons, first it makes URL's easy to write and send (setting a header is tedious), second within our code there were also assumptions made about the use of step only being for metric queries and as a result it has specific rules applied to it which don't apply to log queries. #1773 handled this by parsing the query very early to determine the type before applying these rules to the incoming step parameter. Using a new parameter would make it more obvious which rules are applied and why within the Loki codebase.

Looking for thoughts/feedback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    keepaliveAn issue or PR that will be kept alive and never marked as stale.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions