You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating some background on #33 I actually came around https://github.com/VictoriaMetrics/VictoriaMetrics and from the initial investigation it looks like it can nicely replace Prometheus, Graphite, and InfluxDB as time series storage backend - while gaining performance, supporting more platforms, and consuming less resources.
It should work with existing Venus Influx Loader with no changes in code (TODO: need to verify this claim).
While investigating some background on #33 I actually came around https://github.com/VictoriaMetrics/VictoriaMetrics and from the initial investigation it looks like it can nicely replace Prometheus, Graphite, and InfluxDB as time series storage backend - while gaining performance, supporting more platforms, and consuming less resources.
It should work with existing Venus Influx Loader with no changes in code (TODO: need to verify this claim).
The drawback remains that our existing Venus Grafana panels use https://docs.influxdata.com/influxdb/v2/query-data/influxql/ while Victoria Metrics uses https://docs.victoriametrics.com/MetricsQL.html that is largely based on https://prometheus.io/docs/prometheus/latest/querying/basics/.
The benefit of https://prometheus.io/docs/prometheus/latest/querying/basics/ is that Grafana Prometheus datasource supports great autocomplete features for Prometheus tags.
The mapping of Venus DBus paths to Prometheus tags would have to follow some kind of mixed approach outlined at https://github.com/mman/venus-mqtt-telegraf-timescaledb#alternative-3-mix-of-both-worlds when exploring possible user friendly usage of TimescaleDB as a backend for Venus Grafana.
The text was updated successfully, but these errors were encountered: