Expressions #143
Expressions #143
Conversation
|
While this is quite a bit of feature bloat, I like this. However, I have to read this in depth to understand all of the code. Please bear with me.
most probably this will be bumped by the automation in this repository, as I regularly update the dependencies to the latest available packages. This lowers the burden in the long run for me, as I don't have to jump many versions in case of a urgent security issue or bug in a dependency. |
chrschn
force-pushed
the
expressions
branch
2 times, most recently
from
baa7b27 to
bc87d2a
Compare
|
I fixed the code for Go 1.14, all tests should pass now. I'm looking forward to your review. |
This change adds the new metric config option `expression` which can define a complex expression to calculate the final metric value. The expression is evaluated using github.com/antonmedv/expr as the engine, see expr-lang.org/docs/v1.9/Language-Definition for a language overview. In addition, some basic functions are available during evaluation: now, int, float, round, ceil, floor, abs, min, max. For each evaluation, the expression gets: - the current MQTT value - the last MQTT value - the result of the last evaluation - the elapsed time since the last evaluation Expressions allow more flexibility to derive metrics from sensor inputs which are very hard or even impossible to do in Prometheus, for example, integrate continuous values over time, filter extreme or zero values, or non-linear scaling. The last value, result, and timestamp are preserved even between restarts of mqtt2prometheus. This means that expressions can be used to produce continuous time series over a long time range. To make upstream integration easier, the code depends on the rather old v1.8.9 of github.com/antonmedv/expr, which is available in the main repo of all supported Debian versions.
When generating metric values using expression evaluation, there are new use-cases for more than one configuration for each sensor value. Expressions are more flexible than aggregation rules in Prometheus, so it makes sense to derive multiple metrics from the same sensor input.
|
Hi Christoph. Thanks for merging my PR #141. I rebased this PR on top of the current master. PTAL when you find the time. |
|
Thank you for the contributions and patience! |
Support metrics from arithmetic expressions
This change adds the new metric config option
expressionwhich can define a complex expression to calculate the final metric value. The expression is evaluated using github.com/antonmedv/expr as the engine, see expr-lang.org/docs/v1.9/Language-Definition for a language overview. In addition, some basic functions are available during evaluation: now, int, float, round, ceil, floor, abs, min, max.For each evaluation, the expression gets:
Expressions allow more flexibility to derive metrics from sensor inputs which are very hard or even impossible to do in Prometheus, for example, integrate continuous values over time, filter extreme or zero values, or non-linear scaling. The last value, result, and timestamp are preserved even between restarts of mqtt2prometheus. This means that expressions can be used to produce continuous time series over a long time range.
To make upstream integration easier, the code depends on the rather old v1.8.9 of github.com/antonmedv/expr, which is available in the main repo of all supported Debian versions.
In addition, this PR adds the ability to support more than one configuration for each sensor value. Expressions are more flexible than aggregation rules in Prometheus, so it makes sense to derive multiple metrics from the same sensor input.