VictoriaMetrics Reviews

My main use case for VictoriaMetrics is monitoring, capacity planning, and observability.

In my day-to-day work, we monitor CPU utilization and memory utilization associated with application tags. When a certain threshold is breached, we send out an alert to the team responsible for monitoring that particular application. This allows us to see in advance if the number of connections or users is growing, which helps us look at the trend over the past few months and plan in advance whether we need to increase our capacity, whether we need to scale by adding more nodes, or whether we need to scale vertically by adding more CPU or more RAM.

Regarding my main use cases with VictoriaMetrics, after getting all the metrics, we learned that our select and insert nodes were barely hitting any CPU and memory usage, and we had overprovisioned them, so we scaled them down to the right size and number. However, we also noticed that the storage nodes are the ones heavy on CPU and memory usage, so we scaled them up vertically and added many more nodes because we had been watching the trend and the disk space was constantly growing due to our organization's growth and increased logging. We could see the trend, reduce costs on the select and insert nodes that are barely used, and move that cost elsewhere, which is great.

Another specific example I can give is that we use VictoriaLogs for our logging infrastructure.

VictoriaMetrics has positively impacted my organization in that before it, we didn't really have much to identify alerts or look at short-term trends, and we struggled to pinpoint the cause of issues or at least what was happening when the system misbehaved. This has added a lot of value, including that alerts are simplified now because of VictoriaMetrics.

Incident detection has been faster, so rather than the team reaching out to us, we can see it before they reach out to us.

The best feature VictoriaMetrics offers is that from my observability point of view, it allows you to copy data across the same size node, so data is replicated, which is a really good feature, something that I think is missing in VictoriaLogs.

That replication helps my team day-to-day in that we have planned for situations where we were to lose an entire zone. We would be safe and able to use the data, and we can rely on VictoriaMetrics to use the data because we could replicate it across different zones, which helps us justify our high availability design for VictoriaMetrics.

Regarding the features of VictoriaMetrics, I think the standout is where you can send your query to a different node if data is missing on the one node where the full data set is available. We are actually using this feature and finding it very useful for the migration from the single node to the clustered environment while the data is being hydrated.

I think it would be beneficial to have monthly notifications regarding internal positions.

I have been using VictoriaMetrics for about a year and a half.

VictoriaMetrics is stable in my experience.

VictoriaMetrics's scalability is very stable and easy to scale.

VictoriaMetrics customer support is exceptional. We have used it now and then, and responses are very quick, and the solutions are usually worked through. I would rate the customer support for VictoriaMetrics a 10.

We did use Prometheus before switching to VictoriaMetrics. The motivation to switch was that VictoriaMetrics provided the cluster feature out of the box, whereas with Prometheus, we would have to put Thanos on top of it, which was a slightly more complicated setup.

I haven't seen a return on investment with VictoriaMetrics, as I'm not at that level to see ROI.

My experience with pricing, setup cost, and licensing for VictoriaMetrics is that I'm not involved with those parts. However, I can say it's also good judging by team memebers who dealt on those aspect.

Before choosing VictoriaMetrics, I only evaluated Prometheus.

I would rate VictoriaMetrics a 10, because it meets our expectations. Regarding VictoriaMetrics's AI capabilities, we haven't explored that feature yet, but it's good to know you have this feature.

My main use case for VictoriaMetrics at Billtapi is to monitor and observe my Kubernetes clusters, including logging, events, errors, and more.

VictoriaMetrics helps me significantly for monitoring in my clusters. For example, when we have a problem with pods, nodes, or traffic, I can see it on dashboards and receive alerts about the problems. VictoriaMetrics works very fast and efficiently, and it is easy to set up and run.

I do not use another way and want to mention that VictoriaMetrics covers all my needs related to monitoring and logging, and I am happy to use it.

VictoriaMetrics has positively impacted my organization by being very efficient, resulting in low workload on my infrastructure.

The specific improvements I have noticed include lower load on my infrastructure and efficient data management.

Before using VictoriaMetrics, I relied on Prometheus, which was not as efficient and required much more CPU and storage. When we transitioned to VictoriaMetrics, we noted significant improvements.

In my experience, the best features VictoriaMetrics offers are seen in my Kubernetes clusters.

Regarding my Kubernetes clusters, all of the specific features of VictoriaMetrics stand out for me, such as its speed, scalability, alerting, and ease of integration. I am able to easily install it on my cluster using a Helm chart, which takes about ten minutes, and after that, I can already use it. It is very easy to set up and really efficient, as I practically do not see any effect from VictoriaMetrics on my working workloads, and it handles storage well, keeping its data very efficiently.

VictoriaMetrics could be improved perhaps by working with logs in a similar way to metrics, allowing logs to be treated as metrics, which would facilitate usage in threads or alerts, making logs more specific and sharp.

I would find it beneficial for alerts to work natively with log data.

I chose an eight out of ten because for a perfect score of ten, VictoriaMetrics would need to be effortless to install, set up, run, and use—essentially, it should just work without me having to do anything.

I have been using VictoriaMetrics for about two years.

In terms of accuracy and reliability, VictoriaMetrics's output is pretty sufficient and works very well in a native Kubernetes setup, which I appreciate.

VictoriaMetrics is very stable in my experience.

Regarding the scalability of VictoriaMetrics, I typically use it on a cluster with three instances, and it works well.

Previously, I used Prometheus, but after conducting tests and research on VictoriaMetrics, I found it to be much more efficient, so I decided to switch and have integrated it into my infrastructure.

VictoriaMetrics is deployed in my organization on-premises using our dedicated hardware within Kubernetes clusters, and it is very well deployed.

I believe we have improved our reaction time to incidents due to using VictoriaMetrics, leading to happier clients as we can now react faster to incidents.

I am using the community version of VictoriaMetrics for free, so I do not experience any issues with pricing or licensing.

Before choosing VictoriaMetrics, I did not evaluate other options; I just tried it on one cluster.

My advice for others looking into using VictoriaMetrics is to try it; I am sure you will appreciate it as it is a good option for anyone seeking a stable, mature, and fast monitoring and logging system. I would rate VictoriaMetrics an eight out of ten.