* Add limit type field selection
* Take into account LimitType to generate SQL request for Line graph
Also, add LimitType in default configuration for console
* Take into account LimitType to generate SQL request for Sankey graph
* Refactor on SQL query used by line and sankey
* Add limitType description in doc
* Order by max in graphLine when limitType max is used
* Fix query when using top max
Revert some modifications, as they were no longer relevant with the query fixed.
* Rework way to sort by max in line graph type
* Add configuration validation on LimitType
---------
Co-authored-by: Dimitri Baudrier <github.52grm@simplelogin.com>
This is useful to detect interfaces that are close to saturation
quickly. It would usually require to group by exporter name and
interface name and it may not make sense for some graph types (like
stacked 100%). It is useful with Lines and Grid.
This is a first step to make it accept configuration. Most of the
changes are quite trivial, but I also ran into some difficulties with
query columns and filters. They need the schema for parsing, but parsing
happens before dependencies are instantiated (and even if it was not the
case, parsing is stateless). Therefore, I have added a `Validate()`
method that must be called after instantiation. Various bits `panic()`
if not validated to ensure we catch all cases.
The alternative to make the component manages a global state would have
been simpler but it would break once we add the ability to add or
disable columns.
But not using it as some linters are either plain incorrect (the one
suggesting to not use nil for `c.t.Context()`) or just
debatable (checking for err value is a good practice, but there are
good reasons to opt out in some cases).
This displays a line for the previous period on stacked graphs.
Previous period depends on the current period. It could be hour, day,
week, month, or year.
BETWEEN is inclusive, while FILL excludes the upper bound. This may
trigger a subtle bug where sometimes, one axis has one value the other
does not have.
This is needed if we want to be able to mix use of several tables
inside a single query (for example, flows_1m0s for a part of the query
and flows_5m0s for another part to overlay historical data).
Also, the way we handle time buckets is now cleaner. The previous way
had two stages of rounding and was incorrect. We were discarding the
first and last value for this reason. The new way only has one stage
of rounding and is correct. It tries hard to align the buckets at the
specified start time. We don't need to discard these values anymore.
We still discard the last one because it could be incomplete (when end
is "now").
This is more reliable and efficient but it also remove a bug with
equality comparison failing and thus inability to remove entries.
Also, sorted exactly as we want.
