VictoriaMetrics Cloud: Prometheus & OpenTelemetry metrics, logs, traces

My main use case for VictoriaMetrics is collecting metrics and storing them. These are metrics from various systems, both business metrics and infrastructure metrics describing how the system is performing. I collect them using exporters. This is basically the standard use of VictoriaMetrics for storage.

The best features that VictoriaMetrics offers are a sensible approach to storage. A targeted approach to storing large amounts of data, as well as convenient formation of storage clusters, seem most successful and useful to me.

VictoriaMetrics has positively impacted my organization because we were able to save on metric storage by not using expensive solutions from other vendors. I estimate the savings to be around ten to fifteen percent.

I would like to add aggregated storage as a general capability. I would prefer to store raw data for a shorter period of time and aggregated data for a longer period, particularly in cases where a high degree of accuracy is not required over a long distance.

Adding AI-based analysis could be beneficial, but that is more of a future consideration. There is room to grow in terms of data management and security capabilities, and I believe there is significant potential in these areas.

I started using VictoriaMetrics around 2022, so I have been working with it quite closely for the last four years.

Regarding stability, I would rate it a ten out of ten. There were no reliability issues.

With the necessary infrastructure in place, I see no problems with scalability in VictoriaMetrics.

I used Prometheus and also Thanos before deciding to move to VictoriaMetrics because it allowed me to achieve better results.

Before choosing VictoriaMetrics, I considered other options including Prometheus, Cortex, and Grafana's storage.

I rate VictoriaMetrics an eight out of ten. The reason I rate it eight is that the solution lacks aggregation and I have to either use a custom solution or solutions from other vendors.

The accuracy and reliability of the results that VictoriaMetrics provides when working with artificial intelligence are sufficiently accurate and reliable. My advice for those considering implementing VictoriaMetrics is to carefully assess the necessity of implementation.

My main use case for VictoriaMetrics is monitoring and collecting data from a Kubernetes cluster, especially logs and traces, to understand application failures and application performance.

For example, after deploying an application with some changes, the new application went live, and I was able to see in the logs exactly what was happening there. In terms of the application's performance, I was able to see the consumption metrics, including memory consumption, data consumption, and network consumption. Since the deployment included fixes, I was able to see in the logs whether those fixes were applied in the application or not. VictoriaMetrics allows me to do all those things.

I use almost everything that VictoriaMetrics has to offer in my environment, but I do it with the open-source version. I use it for performance monitoring, database monitoring, logging, and application traces.

VictoriaMetrics positively impacts my organization by allowing me to do monitoring in a very easy way. I came from Prometheus, which was very similar for me. The switch to VictoriaMetrics has been very seamless, and I have seen the benefits of it in terms of performance. The usage of the cluster has reduced, and the query performance is faster. Additionally, I see that VictoriaMetrics comes with anomaly detection, which I plan to try out as well.

I can say that the usage is at least 30% more efficient compared to Prometheus. Because it is more efficient, the query performance is much faster.

One of the best features that VictoriaMetrics offers is that it is a time-series database, which is a like-for-like replacement for Prometheus. Since I originally came from Prometheus, VictoriaMetrics is more of an optimized version of that. It works much better, is more reliable, and is simpler and more efficient to work with. Additionally, there is a logging solution, so I am able to see logs of the application.

When comparing VictoriaMetrics to Prometheus, I saw that Prometheus itself was a bit heavy to use. With VictoriaMetrics, the query performance is faster, and it requires a lesser amount of storage space as well. Since I have deployed it on the cloud, it is scalable because it comes with Docker images which I deploy using Kubernetes. It has reduced memory usage and faster query performance.

Regarding pricing, because I am using the open-source version, it does not impact me too much. However, for people who want to go into the enterprise version, I think VictoriaMetrics needs to work on the pricing because it is quite high even if someone uses a single cluster. It is quite expensive. Otherwise, it is a very evolved product with not a lot of scope for improvement. I would say maybe more integration with the agents would be beneficial, so that it can work on its own one day.

Regarding needed improvements, I am happy with whatever I am getting from VictoriaMetrics.

I chose 9 out of 10 because it is very similar to Prometheus. Other than the performance improvements, VictoriaMetrics needs to add more features to differentiate itself from the market. That is one thing they can improve upon.

I have not noticed any other improvements needed with VictoriaMetrics that I have not discussed yet.

I have been using VictoriaMetrics for around four years.

VictoriaMetrics is very stable in my experience.

VictoriaMetrics is extremely scalable because it is deployed on the cloud, on Kubernetes, and I just need to increase the scale as needed.

However, there is a lot of community support available.

I used Prometheus before using VictoriaMetrics, and Prometheus was a bit heavy. It lagged a little bit in terms of performance and was not as optimized as VictoriaMetrics.

I have seen a lot of improvement in terms of time saved. Because VictoriaMetrics runs more efficiently and much faster, debugging an issue or understanding system performance is much easier. I do not have a number to share, but I have definitely seen a lot of improvement in terms of performance and the time taken to resolve issues.

However, I do see the pricing online, and it is a bit on the pricier side.

I came from another organization where I had used VictoriaMetrics, and I knew that I needed to change to this solution.

I would rate VictoriaMetrics 9 out of 10.

Regarding VictoriaMetrics's AI capabilities, governance, and security, I am not using it right now, but I do see that VictoriaMetrics has come up with an anomaly detection module, which provides observability with AI. I am looking forward to using that, but I think it comes with enterprise plans only, and I am on the open-source version.

Based on my experience, I expect VictoriaMetrics's accuracy and reliability of output to be on par with other tools in the market, such as Dynatrace. Their accuracy is very good, and more than 90% of the time, they give me the correct result. VictoriaMetrics should not be lagging behind and should reach that target.

I deploy VictoriaMetrics in my organization using public cloud. I use Azure as my cloud provider.

If you are coming from Prometheus, I recommend going for VictoriaMetrics. It is way better than Prometheus and customizable as well, similar to what Prometheus offers, but with better performance and efficiency.

My main use case for VictoriaMetrics is storing and querying infrastructure metrics in my SmartOps observability project, which include CPU, memory, latency, and error rates. Metrics flow through Kafka into VictoriaMetrics, then feed Grafana dashboards, VM Alert rules, and an anomaly detection workflow that uses the data to investigate incidents.

VictoriaMetrics fits into my SmartOps project's anomaly detection workflow by providing the metric history for detection and investigation. The detector queries the last 10 minutes of data using PromQL, compares the latest values against a baseline, and flags unusual deviation or critical thresholds, for example, CPU usage reaching 85%. Once an anomaly is detected, an AI workflow correlates it with logs and distributed traces from the same region and time window. It can also query related metrics from VictoriaMetrics to investigate whether a CPU spike coincides with rising latency or errors, then suggest a likely cause and next steps. The initial detection uses statistical checks, and the AI helps interpret the evidence.

The impact of VictoriaMetrics has been at the project level. It gives SmartOps a shared metrics store for dashboards, alerting, and anomaly investigation, simplifying integration and making it easier to connect a detected spike with its historical context.

One example where using VictoriaMetrics made a difference in my project is the simulated CPU spikes in SmartOps. It provides the recent metric history so the detector can compare CPU usage with its baseline and flag the spike. The investigation workflow then correlates that event with logs and traces from the same region and time window, bringing the metric evidence into the investigation automatically and reducing the manual work of gathering context. Since this was a project simulation, I haven't measured time saving or validated the benefit during a production incident.

The standout features VictoriaMetrics offers are Prometheus compatibility, straightforward deployment, and efficient storage. The compatible query API made connecting Grafana and building the anomaly detection queries straightforward, while the single-node setup was easy to get running. Compression and resource efficiency are strong points, although I haven't benchmarked those myself. I also value VM Alert, which supports alerting, recording rules, and integrates with Alertmanager. In SmartOps, having dashboards, alert rules, and the investigation workflow query the same metric history is particularly useful.

If I had to pick one feature as the most valuable for my daily work, it would be Prometheus compatibility. In SmartOps, it allows me to use familiar PromQL queries across Grafana dashboards, alert rules, and the anomaly detection workflow, which saves integration effort and makes it easier to investigate an incident using the same metrics across those tools. It reduced the work needed to connect everything. I can query VictoriaMetrics through the Prometheus-compatible API, display the data in Grafana, and use familiar PromQL in alert rules and anomaly detection. That allows me to spend more time investigating what the metrics mean and less time writing integration code.

These features are particularly useful together. In SmartOps, Grafana, VM Alert, and the anomaly detection workflow all use the same metric history, making it easier to move from spotting a problem on a dashboard to investigating what happened.

From my project experience, I would appreciate more practical guidance on tuning queries and diagnosing missing or delayed metrics across the ingestion pipeline. When data passes through Kafka before reaching VictoriaMetrics, tracing where a gap starts takes some work. A clearer guide for moving from a single-node setup to a production cluster would also help, especially around sizing, retention, and availability. Those are areas where I would value more guidance as the project grows.

I would add more examples of handling sparse or delayed data in anomaly detection, such as how to distinguish a genuine metric change from an ingestion gap. That is partly an application design challenge, but practical guidance would help.

I have been using VictoriaMetrics for a few months.

VictoriaMetrics has been stable in my local SmartOps setup.

For SmartOps, the single-node setup has been sufficient. Having a cluster deployment option gives it room to grow.

For my project, I have relied on the documentation.

SmartOps started with VictoriaMetrics, so there was not a migration from another solution. I chose it for its Prometheus compatibility, straightforward single-node deployment, and integration with Grafana and alerting.

For my SmartOps project, VictoriaMetrics is deployed in a local, self-hosted Docker setup on my development machine. Of those options, on-premises is the closest fit, though it is a development environment rather than an organizational production deployment.

The clearest benefit is less manual work gathering metric history for anomaly investigations.

I used the open-source single-node edition locally, so there was no software license fee. The setup cost was mainly my time configuring Docker, ingestion, Grafana, and alerting.

I considered Prometheus with remote storage and InfluxDB but didn't run a formal benchmark comparison. I chose VictoriaMetrics for its Prometheus-compatible API and straightforward single-node setup, which suited SmartOps.

I would rate VictoriaMetrics eight out of ten.

I chose eight out of ten because it has been straightforward to deploy and integrates with Grafana, alerting, and my anomaly detection workflow. Prometheus compatibility is the biggest plus for me, and I rate it that way because my experience has been positive, but it is limited to a single-node project setup. I would want more production experience before rating it higher.

In SmartOps, the AI workflow sits in the application layer and queries VictoriaMetrics for metric data. Before using that in production, I would assess access controls, audit logging, and what data is sent to the AI provider.

In SmartOps, it supplies the metric data, while a separate AI workflow interprets it. I treat those AI explanations as hypotheses to check against metrics, logs, and traces.

I would suggest starting with a single-node setup and your actual metrics workload. Check that your Grafana dashboard and PromQL queries behave as expected, then monitor ingestion, query latency, memory, and storage usage. Pay attention to label cardinality and retention early. Before production, validate backups and recovery, access controls, and whether you need a cluster.

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.