victorialogs-datasource
victorialogs-datasource copied to clipboard
VictoriaMetrics
Field Names Limits
Hi team,
When using the query builder, loading the Field Names
is usually very slow, and most of the times it actually crashes the browser due our internal amount of indexed fields. See scroll bar size 😓
However, most of the time, this query builder is used to select only known, "top level" selectors. Stuff like app name, pod, container, namespaces, services, etc etc.
Realistically, most of the "indexed" fields are app specific etc so not really useful for "bootstraping" the initial query.
Are there plans to set a limit on return fields, maybe some hinting on the query, or maybe consider pre-defined include list of fields names instead of going to the API? etc
Waiting for feedback
Hi @dmitryk-dk
In our use, after taking a look at the data model, we have around 7K fields with payload of select/logsql/field_names being around 568K.
After looking the issue, we dont have the problem of creating field names with numbers etc, but we do have a significant diversity of log structures in JSON, that when unmarshalled and indexed do cause a significant amount of variety.
What is the expected/recommended size of unique fields_names? Is 7K even a lot? Or will it degrade performance? Are there some recomendation?
P.S: We did not even notice any performance degradation in day to day use, without the exception of the query builder fetching this initial payload for auto-complete.
Hi @func25 ! Could you please check this issue? I think we need to provide the ability to fetch fields with the proposition to have a query like this
* | field_names as name | filter name:~"^kub" | limit 2
Maybe you have another vision or thoughts.
Yeah, something like that work indeed.
In our use case, the fields we most use for bootstraping queries are all under kubernetes_* and metadata_* so a simple filter like that would cut down the 7K to like 50 fields which is much more usable.
the fields we most use for bootstraping queries are all under kubernetes_* and metadata_*
We need to consider cases where the user hasn’t typed anything, or has typed only a single letter (e.g., “a” or “b”).
There are a couple of options:
- Fetch all ~7,000 field names from the data source, but display only 1,000 (or less depends on Grafana performance) in the dropdown initially. Reveal more as the user types.
- If the number of field names is very large (thousands, hundreds of thousands), the backend should not return a partial list (to avoid confusing users). Instead, have the frontend display a warning such as “Please type a few characters to narrow down the search,” with a link to documentation explaining why too many field names is problematic.
We’ll do option 1 first if there are no performance or memory issues with frontend filtering.
I'd expect that VictoriaLogs plugin should process lists with up to 10k string items (such as field names or field values) with the total size of up to 10MB in a blink of eye on modern computers with gigabytes of RAM. If this in't the case, this points to serious problems with the performance and resource usage at the VictoriaLogs plugin side. These problems must be fixed at first before thinking on how to limit the number of returned log field names from VictoriaLogs side.
Hi team,
In my practice, stream labels (like app, env, namespace, level, etc.) are used in approximately 99% of query building scenarios as they define the log stream selection. Having to scroll through hundreds of application-specific fields to find these selectors significantly impacts usability.
I would like to propose displaying stream labels at the top of the field name list by default. This would allow users to quickly access the most commonly needed fields without triggering the rendering of the entire field list.
