VictoriaMetrics
Last Updated:
Analyst Coverage: Philip Howard
VictoriaMetrics was founded in the Ukraine in 2018, where product development continues. The company is also represented in both the UK and USA. It offers long-term remote storage for Prometheus, which is a Linux Foundation open source time-series database and monitoring system. Both Prometheus itself, and VictoriaMetrics are available via Apache licenses.
VictoriaMetrics (Prometheus)
Last Updated: 28th February 2020
Fig 01 Prometheus architecture
Prometheus is a database that supports the monitoring (and alerting and other related capabilities) of applications, DevOps environments (a common use case), Linux Servers, MySQL daemons, networks (not necessarily computer networks) and other infrastructure in which you want to monitor the health of the systems under review. It is not targeted at Internet of Things (IoT) and similar environments. As Figure 1 (which illustrates the architecture of Prometheus) shows, the emphasis here is on collecting and visualising (via Grafana) metrics, rather than supporting the analytics that would typically be required in an IoT environment.
Prometheus only provides local storage, which is neither clustered nor replicated. Specifically, “it is not arbitrarily scalable or durable in the face of disk or node outages”. VictoriaMetrics offers remote storage to complement this local storage and enable durability. It also offers improved data compaction: Prometheus, along with some other time-series databases, uses the Gorilla algorithm (developed by Facebook) for compaction but VictoriaMetrics has improved upon this by a factor, it claims, of an order of magnitude. Thus long-term storage requirements will be significantly reduced. The company also provides facilities to define retention periods, starting from one month.
Fig 02 VictoriaMetrics cluster architecture
VictoriaMetrics is available in both single-node and cluster versions (see Figure 2) with the horizontal scalability of the latter potentially supporting IoT environments – or at least some of them, where scale and ingestion rates with respect to metrics are the issue, rather than analytics – that Prometheus cannot address. Note that the clustered version offers high availability characteristics and has been optimised to run in multi-tenancy cloud environments.
Customer Quotes
“I switched to remote writing our Prometheus instances to a VictoriaMetrics server and couldn’t be happier.”
Contributor to GitHub
“We have done VictoriaMetrics benchmark… and the result has showed that as to our current architecture, VictoriaMetrics currently outperforms native Prometheus… and we are ready to migrate!”
Suning (on Twitter)
As can be seen from Figure 1, Prometheus is a pull-based as opposed to a push-based system, which relies on HTTP. What this means is that the logic for how data is to be collected, and how frequently, is determined centrally by Prometheus, where the relevant rules can easily be inspected and adjusted if necessary. However, while there are advantages to this architecture it also means that data cannot be guaranteed to be one hundred percent accurate or up-to-date. For the sort of metrics-based applications under discussion, this typically isn’t relevant.
The other notable feature of Prometheus is PromQL, which is the query language. This is functional rather than declarative and is quite rich, including aggregation, calculation and predictive functions. VictoriaMetrics extends PromQL with additional functions. There are too many of these to list here but they include capabilities such as “with templates” and running, range and trigonometric functions, amongst others.
Going beyond Prometheus, VictoriaMetrics also supports the Influx Line Protocol, which means that you can migrate from InfluxDB to VictoriaMetrics should you wish to do so. The company also supports the Graphite plaintext and OpenTSDB protocols.
Prometheus is a time-series database focused on the collection of time-series metrics and the analysis thereof. It is not a general-purpose database with time-series capabilities. Assuming that the former is what you are looking for your choice is between a push-based and pull-based approach, with Prometheus supporting the latter. This has the advantage of easy control but the downside of not guaranteeing that the data is completely up-to-date. It also has the disadvantage that you need to learn PromQL as opposed to using SQL.
Deployment of VictoriaMetrics potentially changes this equation because of its richer environment, improved compaction, enhanced performance and scalability. While Bloor Research is always somewhat skeptical about vendor conducted benchmarks, VictoriaMetrics has published benchmark comparisons – available on its web site – with leading competitors, for ingestion, compression, high cardinality and vertical scalability. These appear impressive.
One further consideration is the use of remote storage with Prometheus. This is not absolutely necessary but is likely to be a requirement for many companies and it is certainly something that we would recommend. In that case, VictoriaMetrics is one of several choices and it is somewhat surprising that the company has not conducted and published performance comparisons against these, though perhaps it does not want to give them the benefit of publicity. We would expect VictoriaMetrics to do well in any such benchmarks.
The Bottom Line
If you want time-series monitoring capability at scale, as opposed to a small local implementation, then VictoriaMetrics represents an excellent choice: it offers significantly superior performance, not only compared to Prometheus itself but also when considered versus other technologies.
Commentary
Coming soon.
Solutions
Research
Time-Series and Temporal databases and analytics
