What is our primary use case?
The main scenario we tested during our proof of concept was against its competitors in the field, which are Thanos and Mimir.
We were looking into how it works with our existing infrastructure in terms of having already running Prometheus instances and how it works with remote write, which was one of our goals.
We also examined storage patterns and additional factors that were very relevant for us, such as downsampling, which was quite necessary to actually save on storage costs.
We evaluated it based on approximately 10 points. Those evaluation points included storage, how it queries, how it reads and writes, how it compacts, how it downsamples, how it supports multi-tenancy, which is also very important for us, and the query language.
How has it helped my organization?
VictoriaMetrics, or specifically VM agent, has positively impacted my organization because it allows us to feed metrics into our centralized metrics storage, which gives us visibility of our infrastructure.
I would not say the same about the overall impact in terms of differentiation.
Any other agent would give us the same visibility, and the VM agent simply does it with less resource usage.
What is most valuable?
Out of those evaluation points, the thing that really stood out to me about VictoriaMetrics compared to the others was that it was the least resource-intensive.
For a larger scale, you would really save on resources and compute power.
The selection of VictoriaMetrics-related items, not VictoriaMetrics storage and metrics backend itself, is actually very impressive.
We currently use VM agent, which is VictoriaMetrics agent, as one of our main ways to get metrics from our environments to our final storage.
The product itself has some negatives.
It is very enterprise-oriented, in my opinion.
The storage is not the best in my view.
The local and block disks that it had when we tested it was neither particularly bad nor particularly good, in my opinion.
Object storage and S3-like storage is something that is basically a company and industry standard now.
However, it was good on resources and it did not do things how we wanted, so we landed on something different.
We still use VictoriaMetrics agent to deliver metrics from our multi-tenancy, multi-region clusters to one centralized object storage.
In my experience, the best features VictoriaMetrics offers include that VM agent does its work very efficiently and does not use a lot of resources.
It supports all of the relevant Prometheus-like scrape configs, so you can manage the labels and relabel things before writing or sending them.
It does everything well, and due to the resource usage, it does it the best in our opinion.
In addition to that, we also run it in quite an unusual pattern.
We have three zones in one of the clusters, and what helps us is ensuring that we get all the metrics from the relevant zones without any duplicates.
We also run in parallel a zoneless setup, which allows us to quickly switch if, for example, the zones are not working correctly.
This gives us replication factors so that we never lose our metrics.
Most of all, I value the VM agent for the resource efficiency and because it supports all of the common scrape, relabel, and all of the other necessary operational jobs so that you actually get your metrics with valuable labels.
What needs improvement?
I am sad that VictoriaMetrics moves towards enterprise only for features that it is really good at, such as downsampling.
Hopefully this product keeps on improving on the basis of VM operators and VM agents, and from there, moves toward less enterprise and more open source with fewer features gated behind enterprise prices.
VictoriaMetrics needs to be less enterprise-gated and more open source, allowing people to actually experience full scalability and the full feature set without being forced to pay enterprise prices, get quotes, or pay for licenses.
I do not remember the exact enterprise gate that prevented us from using certain features, but I remember that we could not enable some of the features and use it efficiently because there was no downsampling.
We really needed it because it is what saves on storage costs.
Other than that, I would encourage continuing to improve what already exists.
For how long have I used the solution?
We have not been using VictoriaMetrics per se.
We did conduct quite an extensive proof of concept for three options: Thanos, Mimir, and VictoriaMetrics.
In terms of how long I have been using similar applications, it would be around three to five years, actually owning them and configuring them end to end.
I can share insights regarding that experience.
What do I think about the stability of the solution?
VictoriaMetrics stores metrics and when you query it, it gives you metrics.
It should be quite accurate and reliable if the metrics have been stored correctly.
What was our ROI?
The resource efficiency of VictoriaMetrics allows you to reduce infrastructure costs.
What other advice do I have?
The advice I would give to others looking into using VictoriaMetrics is to always run your proof of concepts and test other storage backends such as Thanos and Mimir.
I would rate VictoriaMetrics a four out of ten.
I chose a four out of ten because it simply finished last in our proof of concept, so there is no reason to rate it higher.
Even the solution that we use now does not receive a ten out of ten.
It finished last because of the enterprise gate mostly.
