VictoriaMetrics: Simple & Reliable Monitoring for Everyone

This project might be a better fit for the SIOT use case than InfluxDB. Several things about InfluxDB:

  • the Flux query language is very powerful, but I find it too complex for most of our use cases – the InfluxDB 1.x query language was a much better fit.
  • most of their effort is going into their new storage engine written in Rust. This may be needed for super scale, but it is not OSS, and probably not needed for most SIOT applications.
  • community does not seem very active

VictoriaMetrics is a pure Go application and is more efficient than InfuxDB – this seems to fit our values and needs better.

Performance comparison:

https://valyala.medium.com/when-size-matters-benchmarking-victoriametrics-vs-timescale-and-influxdb-6035811952d4

Why they open-sourced it:

This is an interesting video and a good primer on OSS business. In the Q&A, they asked if they look for funding. The response was that they don’t look for funding, rather they are a bootstrapped company. They earn money from support. This is different than InfluxData, which is heavily funded.

They were also asked why they used Go and not C++ or Rust – he responded that Go is much better in a team setting so that others can read the code. They seem very committed to continuing in Go.

https://valyala.medium.com/open-sourcing-victoriametrics-f31e34485c2b

Which drawbacks does VictoriaMetrics have?

  • It doesn’t support SQL. Only PromQL.
  • It is written in boring Go, not in zero-cost-abstracted Rust or in C++, which could be learnt in 21 days.
  • It is free from magic, fancy abstractions and smart algorithms — just plain Go code.
  • It is written from scratch and isn’t based on ancient reliable piece of code.

From their contributing doc:

If you like VictoriaMetrics and want to contribute, then we need the following:

  • Filing issues and feature requests here.
  • Spreading a word about VictoriaMetrics: conference talks, articles, comments, experience sharing with colleagues.
  • Updating documentation.

We are open to third-party pull requests provided they follow KISS design principle:

  • Prefer simple code and architecture.
  • Avoid complex abstractions.
  • Avoid magic code and fancy algorithms.
  • Avoid big external dependencies.
  • Minimize the number of moving parts in the distributed system.
  • Avoid automated decisions, which may hurt cluster availability, consistency or performance.

Adhering KISS principle simplifies the resulting code and architecture, so it can be reviewed, understood and verified by many people.

I really like their values.

@bminer thoughts on switching to this?

I’m glad you found this. I will have to dig into it! I agree that I am less of a fan of Influx 2. It seems a little too heavy for my taste.

I like their backup story:

This might be a deal breaker:

  • timestamps are stored with nanosecond resolution in InfluxDB, while in VictoriaMetrics it is milliseconds;