Cardinality explorer
In monitoring, the term cardinality defines the number of unique time series stored in a time series database (TSDB). The higher the cardinality, the more resources are usually required for metrics processing and querying.
In monitoring, the term cardinality defines the number of unique time series stored in a time series database (TSDB). The higher the cardinality, the more resources are usually required for metrics processing and querying.
Share: VictoriaMetrics is a monitoring solution. It was designed to collect and process telemetry from many systems, provide a retrospective view, and forecast metrics for capacity planning. But what about monitoring VictoriaMetrics itself? There is one of the software development approaches called Observability Driven Development (ODD). In a nutshell, it means that developers should always keep in mind that software needs to be transparent to the person who uses it. Does your software make backups?
Grafana Labs Mimir is a new time series database under AGPLv3-license. The engineering team did a great job by taking the best from Cortex TSDB, reducing its complexity and improving scalability in the same time. According to tests by Grafana Labs, Mimir can scale to a billion active time series and 50 million samples/s ingestion rate.
We need to remove a vmstorage node from VictoriaMetrics cluster gracefully. Every vmstorage node contains its own portion of data and removing the vmstorage node from the cluster creates gaps in the graph (because replication is out of scope).
When looking for a highly scalable time series database, there are a number of criteria to investigate and evaluate. First up, it’s always a good idea to consider open source software. It’s more likely to have gone through comprehensive troubleshooting, it’s typically more reliable as it has more timely and widespread peer-review, it better guarantees technology independence, it’s easier to find engineers who are familiar with it and it has great security.
vmagent supports both the pushing and pulling (scrape) of metrics and here are examples of high availability setups for both cases.
Since the beginning of the year, our team has been busy working with the open source community of VictoriaMetrics users and our customers as we continuously enhance and improve Vicky! Thanks to everyone who has contributed with their feedback, questions, feature requests, bug reports, etc.
Observability has become a critical part of many companies and their business. So did requirements for the systems which collect and store business-critical metrics. Monitoring systems need to be reliable, scalable, fast, and preferably cost-effective. Such features of any monitoring system never come for free or out of the box – you need people, a team of professionals who can build and manage it.
ARM processors become more popular and more cost-effective according to many benchmarks. One of them was made by Percona for MySQL. Some of our users reported issues with VictoriaMetrics at AWS Graviton instances. The main concerns were higher CPU and disk IO usage compared to x86 instances of the same size and for the same workload. By that time, we verified that VictoriaMetrics works fine for raspberry and IoT devices, but didn’t do any optimizations for ARM builds.
VictoriaMetrics is a fast and easy-to-use monitoring solution and time series database. It integrates well with existing monitoring systems such as Grafana, Prometheus, Graphite, InfluxDB, OpenTSDB and DataDog - see these docs for details. We are glad to announce the availability of Managed VictoriaMetrics at AWS Marketplace - try it right now!