VictoriaLogs: Configurable Default Time Range for Queries

[tenmozes]

Is your feature request related to a problem? Please describe

Currently, when no time range is specified in a query, the server defaults to searching the entire history. This can be inefficient and lead to unexpected performance issues.

Describe the solution you'd like

Introduce a configurable server-side default time range (e.g., last 24h) that is applied only when the query does not explicitly define a time range.

Describe alternatives you've considered

No response

Additional information

No response

[fukawi2]

This was my suggestion, so to give some more context:

We're migrating from ElasticSearch (with Kibana) where there's a default time period when users search. Having no default time period is proving to be a small issue because users aren't used to having to specify one, causing them to describe VL as being slow (because their search by default is searching the entire available log history).

Most users in our case only need to search 24 hours or less of logs, so if we could specify that as a default, we would reduce adoption friction while our users get used to the change in syntax and need to be explicit about their search period.

[vadimalekseev]

It seems to me that implicitly adding a time range to queries is unintuitive for users who are not aware of this behavior – typically only those who have configured VictoriaLogs would know about it.

An alternative solution might be to introduce a new flag that disallows search queries if no explicit time range has been specified. In that case, the user would see an error indicating that a time range filter must be specified.

[func25]

Thank you @fukawi2 for your suggestion.

Our approach expects users to specify the time range explicitly, and most clients (e.g., VMUI, Grafana) always include a time range in their queries. This means the risk of accidentally querying all logs should be quite low for most workflows.

Introducing a default time range would add implicit logic that could be confusing, as it would not match the current query syntax and most users would not expect this behavior. Plus, searching for logs without knowing the time range (e.g., "critical error on an unknown date") would require users to use the _time filter with a very large range, which feels like a workaround rather than a solution.

Because of these reasons, we believe the usability and priority of this feature are quite low at the moment. But if you can provide more context, we can make a better decision:

• How are you typically querying VictoriaLogs (e.g., HTTP API, CLI, custom scripts)?
• In your previous workflow (e.g., with Elasticsearch/Kibana), how was the default time range handled (e.g., through the UI, Elastic backend, etc.)?

If there is a reasonable use case, we can discuss implementing this feature.

[tiny-pangolin]

The context for this use case is that a user is sending an http request for just a string without a time value, then they are having timeout issues since they are doing a full text search on every part in the database.
I think @vadimalekseev's idea would be an ok workaround but the ideal fix from the user prospective is to have a flag that will be add the time parameter if it isn't specified since we cannot guarantee the client will add it and users who are coming from elastic are expecting queries to have the time added for them.

[fukawi2]

Introducing a default time range would add implicit logic that could be confusing, as it would not match the current query syntax and most users would not expect this behavior. Plus, searching for logs without knowing the time range (e.g., "critical error on an unknown date") would require users to use the _time filter with a very large range, which feels like a workaround rather than a solution.

This definitely makes sense - that's why I suggested it could be an optional configuration on each server instance. That would put the onus of having it enabled on the instance owner/operator rather than all users by default.

---

How are you typically querying VictoriaLogs (e.g., HTTP API, CLI, custom scripts)?

Yes 😄 Mostly WebUI and vlogscli at the moment, but we will be implementing some custom integration with internal tools via the HTTP API.

In your previous workflow (e.g., with Elasticsearch/Kibana), how was the default time range handled (e.g., through the UI, Elastic backend, etc.)?

The Kibana Web UI defaults to 15 mins.

---

To be clear though, this is definitely only a "nice to have" for our migration path. It's not a blocker, but it would just help our migration to be smoother since we've seen quite a few people coming to us (as the internal implementers) saying "Victoria Logs is so slow", only to find out they're searching the entire log history which of course will be slower.

[func25]

The Kibana Web UI defaults to 15 mins.

Yeah, Kibana should have a default time range, and vmui/Grafana do as well. I don't think this should be fixed from the backend side, as it would cause more confusion than benefits for common use cases (script/ webUI). Also, It would prevent queries that intentionally don't use a time range, e.g: transaction_id:="abc123-def456-ghi789" | limit 1, _stream_id:0000007b000001c850d9950ea6196b1a4812081265faa1c7 | limit 1 so this won't be implemented.

A disallow flag is a good candidate, but we should avoid adding more flags for minor use cases (though I might be wrong if we get more feedback), as it leads to bloated options and increases the learning overhead for VictoriaLogs.

only to find out they're searching the entire log history which of course will be slower.

Agree, the only thing I think should be fixed is the documentation (or maybe adding a warning to vlogscli?). It's an indication that the documentation isn't good enough to educate users to use _time for (significantly) better performance queries.

[valyala]

I like the approach with a command-line flag, which disallows LogsQL queries without _time filter (the _time filter may be specified either directly in the LogsQL query or via some additional arguments such as start and end args for the /select/logsql/query endpoint or via extra filters. If this command-line flag is set and the incoming query doesn't contain _time filter, then VictoriaLogs must return "400 Bad Request" status code with the clear error message, which should help users adding the proper _time filter. This should help quickly resolving the case described by @fukawi2 (e.g. users will instantly receive an error with the clear message on how to fix it), without introducing implicit _time filter, which could confuse users.

There is a more general problem when users send some very slow query to VictoriaLogs and then say that VictoriaLogs is slow. We are going to help users understanding why the given query is slow and provide suggestions on how to fix the slow query (e.g. by following these performance tips) . See the related issue. These suggestions should be integrated into the following places:

• built-in web UI
• Grafana plugin for VictoriaLogs
• interactive command-line tool for querying VictoriaLogs - vlogscli

One possible case on how to integrate these suggestions into these clients is to automatically re-send "get stats" query on query timeout with some smaller "timeout" option, so the essential stats for the query execution is collected according to #52 and then is shown to the user with advice on how optimize the query according to the collected stats.

[valyala]

FYI, VictoriaLogs v1.31.0 adds support for the -search.maxQueryTimeRange command-line flag, which can be used for disallowing LogsQL queries over too broad time ranges (including queries without time range filters). See these docs for details.