Victoria metrics что это
Recently the Evaluating Performance and Correctness article has been published by Prometheus author. The article points to a few data model discrepancies between VictoriaMetrics and Prometheus. It also contains benchmark results showing poor compression ratio and poor performance for VictoriaMetrics comparing to Prometheus. Unfortunately the original article doesn’t support comments to leave the response, so let’s discuss all these issues in the post below.
This code has been used for generating time series for the benchmark. The code generates series of floating-point values with random 9 decimal digits after the point. Such series cannot be compressed well because 9 random decimal digits require at least 9*log2(10)=30 bits or 4 bytes according to information theory. I.e. each sample in such series would occupy at least 4 bytes on disk not counting the encoded timestamp in any system — Prometheus, VictoriaMetrics, Thanos, Cortex, M3DB, InfluxDB or TimescaleDB.
VictoriaMetrics users report 0.4–0.6 bytes per sample for production data according to the following PromQL query for the exported metrics:
So how 4 bytes per sample from Brian’s benchmark can be converted to 0.4 bytes per sample for real-world data? The answer is:
- The time series from the benchmark are far from real world.
- Real-world measurements usually contain small number of decimal digits on limited range. For instance, the usual temperature range is from -460 F to 1000 F with 0.1 F precision, the usual speed range is from 0 m/s to 10K m/s with 1 m/s precision, the usual qps range is from 0 to 1M with 0.1 qps precision, the usual price range is from $0 to $1M with $0.01 precision.
- The number of decimal digits becomes even smaller after applying delta-coding, i.e. calculating the difference between adjacent samples. The difference is small for Gauges, since they tend to change slowly. The difference is small for Counters, since their rate is usually limited by relatively small range. The number of decimal digits for Counters can be reduced further by applying double delta-coding to them.
VictoriaMetrics takes full advantage of these properties for real-world time series. Try storing real-world series into VictoriaMetrics such as metrics from node_exporter and enjoy much better on-disk compression ratio than Prometheus, Thanos or Cortex could provide. VictoriaMetrics compresses real-world node_exporter data up to 7x better than Prometheus — see this benchmark.
High-entropy data (aka random numbers with big number of decimal digits) has not so good compression ratio comparing to typical time series data. So it is recommended reducing the number of decimal digits for measurements stored in TSDB in order to improve compression ratio and reduce disk space usage. vmagent provides -remoteWrite.roundDigits command-line flag, which allows reducing storage requirements for the data written to VictoriaMetrics.
It is unclear why Brian decided to use random series instead of real-world series for measuring compression ratio in the article.
The original article contains an example where VictoriaMetrics trims the last decimal digits for the go_memstats_gc_cpu_fraction metric — Prometheus returns 0.0003083021835007435, while VictoriaMetrics returns 0.0003083021835007. As you can see, the last 3 out of 20 digits are missing. This is due to precision loss during the conversion of floating-point number to decimal number plus decimal exponent. All the calculations on floating-point numbers result in precision loss for the lowest digits — see this Wikipedia article for details. VictoriaMetrics performs the conversion in order to improve compression ratio for floating-point values with small number of significant decimal digits comparing to Gorilla compression — see this article for details.
Should VictoriaMetrics users worry about this? Mostly no, since:
- The precision loss can occur only on values with more than 12 significant decimal digits. Such values are rare in real world. Even summary counters for nanoseconds shouldn’t lose precision. Of course, if you work in NASA, then you would need up to 15 decimal digits :)
- Real-world measurements usually contain small number of precise leading decimal digits. The rest of digits are just noise, which has little value because of measurement errors. For instance, the mentioned above metric — go_memstats_gc_cpu_fraction — contains only 4 or 5 precise digits after the point — 0.00308 in the best case — all the other digits are just garbage, which worsens series compression ratio.
Did you know that Prometheus also loses precision? Try storing 9.234567890123009 to it. It will be stored as 9.234567890123008 . See the verification link. Prometheus, like any solution that works with float64 values, has precision loss issues — see this link.
The article mentions that VictoriaMetrics adjusts the returned timestamp for /api/v1/query results if it is closer than 1 minute to now . This is by design — it prevents from returning incomplete data if certain Prometheus instances lag behind when sending data to VictoriaMetrics via remote_write API. The offset from now can be configured via -search.latencyOffset command-line flag:
Why Prometheus doesn’t have similar option? Because it controls data scraping — the data becomes visible for querying almost immediately after the scrape. VictoriaMetrics receives scraped data from Prometheus instances via remote_write API. The data can be delayed for extended periods of time before it becomes visible for querying in VictoriaMetrics. Additionally, non-zero -search.latencyOffset allows avoiding issues related to query isolation.
The original article shows that VictoriaMetrics returns the expected result from the sum(time()) query, while Prometheus returns cryptic expected type instant vector in aggregation expression, got scalar error. Another example from the article is PromQL query vector(0)-prometheus_tsdb_blocks_loaded — Prometheus returns unexpectedly empty result, while VictoriaMetrics returns the expected negative value for all the prometheus_tsdb_blocks_loaded series.
This deviation in behavior between Prometheus and VictoriaMetrics is deliberate — it simplifies using PromQL for users, who don’t know the difference between scalar, instant vector and range vector in Prometheus. Are there people except Prometheus developers who know the difference? :)
When developing PromQL-compatible engine for VictoriaMetrics I tried avoiding its rough edges based on my experience in order to make more user-friendly PromQL with expected behavior. For instance, VictoriaMetrics allows writing rate(q) instead of frequently used rate(q[$__interval]) in Grafana dashboards. The full list of additional features is available on this page.
Note that VictoriaMetrics is fully backwards-compatible with PromQL, i.e. all the valid queries from Prometheus should return the same results in VictoriaMetrics. There are a few exceptions like more consistent handling for increase() function — VictoriaMetrics always returns the expected integer value for increase() over counter without floating-point increases. See also VictoriaMetrics: PromQL compliance article for more details on intentional discrepancies between PromQL and MetricsQL.
Brian mentions in the article that VictoriaMetrics drops all the incoming NaN values and this breaks staleness handling. This handling is quite complicated and I bet nobody except of a few Prometheus developers know all its details and corner cases. I’ll try explaining simplified staleness handling for Prometheus as I understood it. Prometheus stops returning data points for time series as soon as one of the following conditions are met:
- After a special NaN value is found. This value is inserted by Prometheus when the metric disappears from the scrape target or the scrape target is unavailable.
- After 5 minutes of silence from the previous value.
This logic doesn’t work on time series with scrape intervals exceeding 5 minutes, since Prometheus mistakenly thinks the time series contains a gap in 5 minutes after each scrape.
VictoriaMetrics drops NaNs, but it still detects stale series with much easier logic without corner cases — it stops returning data points if they are missing during the last 2 scrape intervals. For instance, if Prometheus scrapes time series every 10 seconds, then VictoriaMetrics detects that the series is stale after 20 seconds of missing data points.
Update: VictoriaMetrics gained Prometheus-compatible staleness handling in latest releases — see the changelog for details.
The initial version of the article outlined that VictoriaMetrics is more than an order of magnitude slower than Prometheus on time series lookups in this micro-benchmark from Prometheus source code. This was unexpected. The article didn’t contain source code for the corresponding benchmark in VictoriaMetrics, so I implemented it in VictoriaMetrics sources. The end result is quite different — VictoriaMetrics outperforms Prometheus in all the benchmarks by 5x-30x while using 3.5x less RAM. Feel free re-running these benchmarks with the following code from root folder of Prometheus and VictoriaMetrics source codes:
Brian updated performance numbers in the original article after I pointed him to real numbers via Twitter. Now the article claims VictoriaMetrics is 2x-5x slower than Prometheus on the modified end-to-end tests. Unfortunately Brian didn’t provide source code for the updated tests yet. The source code is required in order to reproduce the test and to determine why VictoriaMetrics is slower than Prometheus in these tests.
Usually VictoriaMetrics is much faster than competitors (InfluxDB and TimescaleDB) — see this article for details. VictoriaMetrics users report it is faster on real production data than Prometheus, Cortex and Thanos. They also report that VictoriaMetrics consumes lower amounts of RAM and disk space comparing to Prometheus, Cortex and Thanos. As I know, VictoriaMetrics users never return back to Thanos and Cortex. Additionally, they were frequently requesting to create stripped-down Prometheus without local storage, since Prometheus instances usually eat too much RAM in their highly loaded setups. So we created vmagent.
Don’t trust articles on the internet, including this one, since they may be biased. Just give a try to VictoriaMetrics — it is easy to configure and it can run in parallel with other long-term storage solutions for Prometheus such as Thanos or Cortex. Then decide whether it is better than Thanos or Cortex. I’d recommend reading this article, which compares Thanos to VictoriaMetrics from various PoVs: operational complexity, reliability, performance, cost, etc.
Contrary to the original article, this post can be commented below, so feel free leaving comments and questions.
P.S. Join our Slack channel and keep up to date with all the news regarding VictoriaMetrics.
P.S. See also this VictoriaMetrics vs Prometheus benchmark, which is based on real production data.
What is the main purpose of VictoriaMetrics?
To provide the best monitoring solution.
Who uses VictoriaMetrics?
Which features does VictoriaMetrics have?
Are there performance comparisons with other solutions?
How to start using VictoriaMetrics?
Does VictoriaMetrics support replication?
Yes. See these docs for details.
Can I use VictoriaMetrics instead of Prometheus?
Yes in most cases. VictoriaMetrics can substitute Prometheus in the following aspects:
- Prometheus-compatible service discovery and target scraping can be done with vmagent and with single-node VictoriaMetrics. See these docs.
- Prometheus-compatible alerting rules and recording rules can be processed with vmalert.
- Prometheus-compatible querying in Grafana is supported by VictoriaMetrics. See these docs.
What is the difference between vmagent and Prometheus?
While both vmagent and Prometheus may scrape Prometheus targets (aka /metrics pages) according to the provided Prometheus-compatible scrape configs and send data to multiple remote storage systems, vmagent has the following additional features:
- vmagent usually requires lower amounts of CPU, RAM and disk IO compared to Prometheus when scraping an enormous number of targets (more than 1000) or targets with a great number of exposed metrics.
- vmagent provides independent disk-backed buffers for each configured remote storage (see -remoteWrite.url ). This means that slow or temporarily unavailable storage doesn't prevent it from sending data to healthy storage in parallel. Prometheus uses a single shared buffer for all the configured remote storage systems (see remote_write->url ) with a hardcoded retention of 2 hours.
- vmagent may accept, relabel and filter data obtained via multiple data ingestion protocols in addition to data scraped from Prometheus targets. That means it supports both pull and push protocols for data ingestion. See these docs for details.
- vmagent may be used in different use cases:
What is the difference between vmagent and Prometheus agent?
Both vmagent and Prometheus agent serve the same purpose – to efficently scrape Prometheus-compatible targets at the edge. They have the following differences:
Is it safe to enable remote write in Prometheus?
Yes. Prometheus continues writing data to local storage after enabling remote write, so all the existing local storage data and new data is available for querying via Prometheus as usual.
It is recommended using vmagent for scraping Prometheus targets and writing data to VictoriaMetrics.
How does VictoriaMetrics compare to other remote storage solutions for Prometheus such as M3 from Uber, Thanos, Cortex, etc.?
VictoriaMetrics is simpler, faster, more cost-effective and it provides MetricsQL query language based on PromQL. The simplicity is twofold:
- It is simpler to configure and operate. There is no need for configuring sidecars, fighting the gossip protocol or setting up third-party systems such as Consul, Cassandra, DynamoDB or Memcached.
- VictoriaMetrics has a simpler architecture. This means fewer bugs and more useful features in the long run compared to competing TSDBs.
What is the difference between VictoriaMetrics and QuestDB?
- QuestDB needs more than 20x storage space than VictoriaMetrics. This translates to higher storage costs and slower queries over historical data, which must be read from the disk.
- QuestDB is much harder to set up and operate than VictoriaMetrics. Compare setup instructions for QuestDB to setup instructions for VictoriaMetrics.
- VictoriaMetrics provides the MetricsQL query language, which is better suited for typical queries over time series data than the SQL-like query language provided by QuestDB. See this article for details.
- VictoriaMetrics can be queried via the Prometheus querying API and via Graphite's API.
- Thanks to PromQL support, VictoriaMetrics can be used as a drop-in replacement for Prometheus in Grafana, while QuestDB needs a full rewrite of existing dashboards in Grafana.
- Thanks to Prometheus' remote_write API support, VictoriaMetrics can be used as a long-term storage for Prometheus or for vmagent, while QuestDB has no integration with Prometheus.
- QuestDB supports a smaller range of popular data ingestion protocols compared to VictoriaMetrics (compare to the list of supported data ingestion protocols for VictoriaMetrics).
- VictoriaMetrics supports backfilling (e.g. storing historical data) out of the box, while QuestDB provides very limited support for backfilling.
What is the difference between VictoriaMetrics and Cortex?
VictoriaMetrics is similar to Cortex in the following aspects:
- Both systems accept data from vmagent or Prometheus via the standard remote_write API, so there is no need for running sidecars unlike in Thanos' case.
- Both systems support multi-tenancy out of the box. See the corresponding docs for VictoriaMetrics.
- Both systems support data replication. See replication in Cortex and replication in VictoriaMetrics.
- Both systems scale horizontally to multiple nodes. See these docs for details.
- Both systems support alerting and recording rules via the corresponding tools such as vmalert.
- Both systems can be queried via the Prometheus querying API and integrate perfectly with Grafana.
The main differences between Cortex and VictoriaMetrics:
- Cortex re-uses Prometheus source code, while VictoriaMetrics is written from scratch.
- Cortex heavily relies on third-party services such as Consul, Memcache, DynamoDB, BigTable, Cassandra, etc. This may increase operational complexity and reduce system reliability compared to VictoriaMetrics' case, which doesn't use any external services. Compare Cortex' Architecture to VictoriaMetrics' architecture.
- VictoriaMetrics provides production-ready single-node solution, which is much easier to set up and operate than a Cortex cluster.
- Cortex may lose up to 12 hours of recent data on Ingestor failure – see the corresponding docs. VictoriaMetrics may lose only a few seconds of recent data, which isn't synced to persistent storage yet. See this article for details.
- Cortex is usually slower and requires more CPU and RAM than VictoriaMetrics. See this talk from adidas at PromCon 2019 and other case studies.
- VictoriaMetrics accepts data in multiple popular data ingestion protocols additionally to Prometheus remote_write protocol – InfluxDB, OpenTSDB, Graphite, CSV, JSON, native binary. See these docs for details.
- VictoriaMetrics provides the MetricsQL query language, while Cortex provides the PromQL query language.
- VictoriaMetrics can be queried via Graphite's API.
What is the difference between VictoriaMetrics and Thanos?
- Thanos re-uses Prometheus source code, while VictoriaMetrics is written from scratch.
- VictoriaMetrics accepts data via the standard remote_write API for Prometheus, while Thanos uses a non-standard sidecar which must run alongside each Prometheus instance.
- The Thanos sidecar requires disabling data compaction in Prometheus, which may hurt Prometheus performance and increase RAM usage. See these docs for more details.
- Thanos stores data in object storage (Amazon S3 or Google GCS), while VictoriaMetrics stores data in block storage (GCP persistent disks, Amazon EBS or bare metal HDD). While object storage is usually less expensive, block storage provides much lower latencies and higher throughput. VictoriaMetrics works perfectly with HDD-based block storage – there is no need for using more expensive SSD or NVMe disks in most cases.
- Thanos may lose up to 2 hours of recent data, which wasn't uploaded yet to object storage. VictoriaMetrics may lose only a few seconds of recent data, which hasn't been synced to persistent storage yet. See this article for details.
- VictoriaMetrics provides a production-ready single-node solution, which is much easier to set up and operate than Thanos components.
- Thanos may be harder to set up and operate compared to VictoriaMetrics, since it has more moving parts, which can be connected with fewer reliable networks. See this article for details.
- Thanos is usually slower and requires more CPU and RAM than VictoriaMetrics. See this talk from adidas at PromCon 2019.
- VictoriaMetrics accepts data via multiple popular data ingestion protocols in addition to the Prometheus remote_write protocol – InfluxDB, OpenTSDB, Graphite, CSV, JSON, native binary. See these docs for details.
- VictoriaMetrics provides the MetricsQL query language, while Thanos provides the PromQL query language.
- VictoriaMetrics can be queried via Graphite's API.
How does VictoriaMetrics compare to InfluxDB?
- VictoriaMetrics requires 10x less RAM and it works faster.
- VictoriaMetrics needs lower amounts of storage space than InfluxDB for production data.
- VictoriaMetrics doesn't support InfluxQL or Flux but provides a better query language – MetricsQL. See this tutorial for details.
- VictoriaMetrics accepts data in multiple popular data ingestion protocols in addition to InfluxDB – Prometheus remote_write, OpenTSDB, Graphite, CSV, JSON, native binary. See these docs for details.
- VictoriaMetrics can be queried via Graphite's API.
How does VictoriaMetrics compare to TimescaleDB?
- TimescaleDB insists on using SQL as a query language. While SQL is more powerful than PromQL, this power is rarely required during typical usages of a TSDB. Real-world queries usually look clearer and simpler when written in PromQL than in SQL.
- VictoriaMetrics requires up to 70x less storage space compared to TimescaleDB for storing the same amount of time series data. The gap in storage space usage can be lowered from 70x to 3x if compression in TimescaleDB is properly configured (it isn't an easy task in general :)).
- VictoriaMetrics requires up to 10x less CPU and RAM resources than TimescaleDB for processing production data. See this article for details.
- TimescaleDB is harder to set up, configure and operate than VictoriaMetrics (see how to run VictoriaMetrics).
- VictoriaMetrics accepts data in multiple popular data ingestion protocols – InfluxDB, OpenTSDB, Graphite, CSV – while TimescaleDB supports only SQL inserts.
- VictoriaMetrics can be queried via Graphite's API.
Does VictoriaMetrics use Prometheus technologies like other clustered TSDBs built on top of Prometheus such as Thanos or Cortex?
What is the pricing for VictoriaMetrics?
The following versions are open source and free:
We provide commercial support for both versions. Contact us for the pricing.
The following commercial versions of VictoriaMetrics are available:
The following commercial versions of VictoriaMetrics are planned:
- Managed VictoriaMetrics at Google Cloud.
- Cloud monitoring solution based on VictoriaMetrics.
Contact us for more information on our plans.
Why doesn't VictoriaMetrics support the Prometheus remote read API?
The remote read API requires transferring all the raw data for all the requested metrics over the given time range. For instance, if a query covers 1000 metrics with 10K values each, then the remote read API has to return 1000*10K =10M metric values to Prometheus. This is slow and expensive. Prometheus' remote read API isn't intended for querying foreign data – aka global query view . See this issue for details.
So just query VictoriaMetrics directly via vmui, the Prometheus Querying API or via Prometheus datasource in Grafana.
Does VictoriaMetrics deduplicate data from Prometheus instances scraping the same targets (aka HA pairs )?
Yes. See these docs for details.
Where is the source code of VictoriaMetrics?
Source code for the following versions is available in the following places:
Is VictoriaMetrics a good fit for data from IoT sensors and industrial sensors?
VictoriaMetrics is able to handle data from hundreds of millions of IoT sensors and industrial sensors. It supports high cardinality data, perfectly scales up on a single node and scales horizontally to multiple nodes.
Where can I ask questions about VictoriaMetrics?
Questions about VictoriaMetrics can be asked via the following channels:
Where can I file bugs and feature requests regarding VictoriaMetrics?
File bugs and feature requests here.
Where can I find information about multi-tenancy?
See these docs. Multitenancy is supported only by the cluster version of VictoriaMetrics.
How to set a memory limit for VictoriaMetrics components?
All the VictoriaMetrics components provide command-line flags to control the size of internal buffers and caches: -memory.allowedPercent and -memory.allowedBytes (pass -help to any VictoriaMetrics component in order to see the description for these flags). These limits don't take into account additional memory, which may be needed for processing incoming queries. Hard limits may be enforced only by the OS via cgroups, Docker (see these docs) or Kubernetes (see these docs).
Memory usage for VictoriaMetrics components can be tuned according to the following docs:
How can I run VictoriaMetrics on FreeBSD?
VictoriaMetrics is included in FreeBSD ports, so just install it from there. See this link.
Does VictoriaMetrics support the Graphite query language?
What is an active time series?
A time series is uniquely identified by its name plus a set of its labels. For example, temperature and temperature are two distinct series, since they differ by the city label. A time series is considered active if it receives at least a single new sample during the last hour.
What is high churn rate?
If old time series are constantly substituted by new time series at a high rate, then such a state is called high churn rate . High churn rate has the following negative consequences:
- Increased total number of time series stored in the database.
- Increased size of inverted index, which is stored at /indexdb , since the inverted index contains entries for every label of every time series with at least a single ingested sample.
- Slow-down of queries over multiple days.
The main reason for high churn rate is a metric label with frequently changed value. Examples of such labels:
- queryid , which changes with each query at postgres_exporter .
- app_name or deployment_id , which changes with each new deployment in Kubernetes.
- A label derived from the current time such as timestamp , minute or hour .
- A hash or uuid label, which changes frequently.
The solution against high churn rate is to identify and eliminate labels with frequently changed values. The /api/v1/status/tsdb page can help determining these labels.
What is high cardinality?
High cardinality usually means a high number of active time series. High cardinality may lead to high memory usage and/or to a high percentage of slow inserts. The source of high cardinality is usually a label with a large number of unique values, which presents a big share of the ingested time series. The solution is to identify and remove the source of high cardinality with the help of /api/v1/status/tsdb.
What is a slow insert?
VictoriaMetrics maintains in-memory cache for mapping of active time series into internal series ids. The cache size depends on the available memory for VictoriaMetrics in the host system. If the information about all the active time series doesn't fit the cache, then VictoriaMetrics needs to read and unpack the information from disk on every incoming sample for time series missing in the cache. This operation is much slower than the cache lookup, so such an insert is named a slow insert . A high percentage of slow inserts on the official dashboard for VictoriaMetrics indicates a memory shortage for the current number of active time series. Such a condition usually leads to a significant slowdown for data ingestion and to significantly increased disk IO and CPU usage. The solution is to add more memory or to reduce the number of active time series. The /api/v1/status/tsdb page can be helpful for locating the source of high number of active time seriess – see these docs.
How to optimize MetricsQL query?
Why isn't MetricsQL 100% compatible with PromQL?
MetricsQL provides better user experience than PromQL. It fixes a few annoying issues in PromQL. This prevents MetricsQL to be 100% compatible with PromQL. See this article for details.
How to migrate data from Prometheus to VictoriaMetrics?
How to migrate data from InfluxDB to VictoriaMetrics?
How to migrate data from OpenTSDB to VictoriaMetrics?
How to migrate data from Graphite to VictoriaMetrics?
Please use the whisper-to-graphite tool for reading data from Graphite and pushing them to VictoriaMetrics via Graphite's import API.
Why do the same metrics have differences in VictoriaMetrics' and Prometheus' dashboards?
There could be a slight difference in stored values for time series. Due to different compression algorithms, VM may reduce the precision for float values with more than 12 significant decimal digits. Please see this article.
The query engine may behave differently for some functions. Please see this article.
If downsampling and deduplication are enabled how will this work?
Deduplication is a special case of zero-offset downsampling. So, if both downsampling and deduplication are enabled, then deduplication is replaced by zero-offset downsampling
Добрый день, меня зовут Николай Храмчихин. Сегодня я расскажу о vmagent ’е, нашем комбайне для мониторинга .
Вначале краткий экскурс в историю — с чего все началось и зачем был разработан vmagent . Сначала была VictoriaMetrics, это быстрая и простая в установке БД для временных рядов . Она принимала данные в себя из Prometheus по remote_write -протоколу. В ходе эксплуатации Prometheus ’а мы и наши клиенты столкнулись с определенными проблемами. Проблемы были актуальны на тот период — где-то полтора года назад. Сейчас, возможно, что-то изменилось, и они уже не актуальны.
В первую очередь, Prometheus потреблял много оперативной памяти (RAM), это приводило к ошибкам out-of-memory . Он глючил и тормозил после unclean shutdown , думаю, многие сталкивались с этой проблемой — его сложно запустить после этого. Нужно было либо удалять все данные, либо добавлять ему оперативной памяти.
Также он мог терять метрики, если удаленное хранилище было недоступно какой-то период. Это было очень неприятно — на графиках были пропуски, и работать с удаленным хранилищем было невозможно.
В ответ на все эти проблемы был разработан vmagent как легковесная замена Prometheus .
Помимо этого он может фильтровать собранные метрики . Есть определенный набор правил, по которым это можно сделать, и модифицировать имена метрик с их лейблами.
Конечно же он может сохранять метрики в удаленное хранилище, как это делал Prometheus , по remote_write -протоколу. С его помощью можно настроить репликацию в несколько хранилищ, главное, чтобы они понимали протокол. Например, можно записывать в VictoriaMetrics , в vmagent , в Cortex и в некоторые другие удаленные хранилища. При недоступности хранилища vmagent не теряет метрики, у него есть дисковый буфер (на каждое удаленное хранилище отдельный).
Самое главное: он использует небольшое количество ресурсов CPU и оперативной памяти . Конечно же, он легко устанавливается: у него всего один исполняемый файл без внешних зависимостей.
Помимо этого, у vmagent есть дополнительные фичи. Это, в первую очередь, кластеризация . Можно разделить таргеты между разными vmagent ’ами при помощи простой конфигурации. Это бывает полезно, когда не хватает ресурсов одного vmagent ’a для сбора метрик, либо можно таким образом распределить точки отказа: если одна виртуальная машина с vmagent ’ом вышла из строя, можно продолжить собирать часть метрик со второй машины. Соответственно, достаточно указать количество агентов в кластере и каждому из них присвоить уникальный номер.
Где кластеризация, там уже может быть и репликация . И да, vmagent умеет в репликацию. Настроив replication factor , можно собирать несколько метрик с разных таргетов.
Одна из важных фичей, которые позволяют vmagent ’у использовать небольшое количество RAM — это потоковое чтение метрик . В данном случае, если таргет экспортирует более 10 млн метрик, то потребление памяти будет достаточно большое. Настраивается все достаточно просто: нужно указать stream_parse:true в конфигурационном файле для конкретной job, либо глобально для всего vmagent’ а. Prometheus -экспортеры отдают метрики в построчном формате (prometheus text exposition), поэтому vmagent читает первые n-строк, обрабатывает их и отправляет на запись в удаленное хранилище, потом продолжает обрабатывать следующий блок данных, пока не обработает все.
Список принимаемых форматов метрик:
Та самая фильтрация метрик, о которой я хотел рассказать. Она осуществляется с помощью Prometheus-compatible relabeling , то есть поддерживается весь тот синтаксис, который предоставляет Prometheus для релейблинга . Можно фильтровать по имени метрики, по значению тэгов (лейблов) и по регулярным выражениям. Модифицировать можно с тем же совместимым с Prometheus -форматом. Можно переименовать метрики, добавить новые лейблы, изменить или удалить их.
Где может происходить фильтрация и модификация метрик? В vmagent’е она может происходить практически везде . Можно настроить в конфигурационном файле на уровне relable_configs , в этом случае релейбелинг будет применяться, когда vmagent определяет таргеты, получая список таргетов от Kubernetes ’а.
Во время сбора метрик можно настроить metric_relabel_configs . На этом этапе уже не будут доступны металейблы от Kubernetes ’а. Это нужно делать немного заранее. Перед записью в remote storage тоже можно делать релейбелинг, как для каждого хранилища, так и глобально для всех. И да, релейбелинг работает как для push-метрик, так и для pull.
О других возможностях vmagent ’a. Он может ограничивать скорость записи метрик в удаленное хранилище . Настраивается это для каждого хранилища отдельно или глобально для всех. Это бывает полезно, когда удаленное хранилище недоступно, vmagent забуферизировал метрики, и ему нужно записать большое количество метрик в удаленное хранилище, что может его перегрузить. В данном случае можно ограничить количество записываемых метрик в секунду.
Совсем недавняя фича — можно ограничивать количество уникальных метрик (high cardinality) в час и в день. Соответственно, это может спасти от ошибок конфигурации экспортеров, когда они начинают неправильно работать и выдавать высоко кардинальные метрики. Это очень сильно нагружает БД, так как хранение уникальных метрик грузит RAM и CPU, а регистрация новых метрик ID достаточно дорогой процесс. Для улучшения сжатия данных можно ограничить количество знаков после запятой (настраивается для каждого хранилища).
Где и как можно внедрить vmagent? И какие конфигурации могут быть? Самая простая и логичная — легковесная замена Prometheus . Если у вас есть связка с Prometheus , которая пишет данные в VictoriaMetrics , можно его остановить и запустить с тем же конфигурационным файлом vmagent и указать запись в удаленное хранилище VictoriaMetrics .
Для настройки алертинга, если вы используете его вместе с Prometheus , можно запустить vmalert , он понимает алерты в Prometheus -совместимом формате и умеет отправлять их в Alertmanager .
Также vmagent можно использовать для репликации между несколькими ЦОДами для обеспечения отказоустойчивости. Можно сконфигурировать несколько -remoteWrite.url ’ов, и, соответственно, между ЦОДами будут реплицироваться данные.
Фильтрация и запись определенных метрик в разные хранилища. Да, один из популярных вопросов, как сделать в VictoriaMetrics разное время хранения разных метрик (retention) в зависимости от лейбла. У нас есть открытый issue, как это сделать на уровне одной базы данных, но сейчас это можно реализовать, запустив две разных VictoriaMetrics с разным временем хранения и добавив для одной из них фильтр, который будет сохранять метрики только с определенным лейблом. А в другую БД писать все метрики. Сверху можно поставить какой-нибудь Promxy или что-то подобное, чтобы он опрашивал две VictoriaMetrics и уже показывал результат в Grafan ’е.
При помощи vmagent ’а также можно разделять метрики между разными тенантами . Это актуально для кластерной версии, где можно указать два remoteWright.url ’а. Первый будет писать в один тенант, другой — во второй, и уже на основе каких-то правил будет маршрутизировать между тенантами эти метрики. Это полезно, чтобы разделить метрики разных команд и окружений.
Также можно переводить метрики в “человекочитаемый” формат. Если странный экспортер отдает метрики вот в таком странном формате “ foo_temp ”, с помощью трансформации и релейблинга сделать более приемлемый формат с понятной температурой и названием компании.
Один из популярных кейсов — централизованный сбор метрик из изолированных сетей. Если применение Prometheus недоступно или сложно настроить, то можно использовать vmagent для сбора этих метрик и отправки в централизованное хранилище.
Также vmagent можно использовать в сетях с неустойчивой связью — кассовые терминалы, электростанции и даже спутники. Если связью с Землей нет, то vmagent будет буферизировать данные, как только связь появится, он их отправит VictoriaMetrics .
Какие у нас планы на будущее? Это поддержка statsd и DogStatsD -протоколов. И мы очень хотели бы разработать новый протокол передачи данных между vmagent и VictoriaMetrics , который потреблял бы гораздо меньше пропускную способность и ее было бы удобнее эксплуатировать в таких случаях, как кассы и спутники. И мы всегда готовы реализовать ваши фичи.
- pull и push модели для сбора метрик
- Фильтрация и редактирование метрик
- Репликация
- Буферизация на диск при отсутствии связи с удаленным хранилищем
- Простота использования
- Легковесность
- Open Source
Установка бенчмарка
TSBS – это отличный инструмент бенчмаркинга для TSDBs. Он позволяет генерировать произвольное количество метрик, передавая необходимое количество временных рядов, разделенных на 10 — флаг -scale (бывший -scale-var ). 10 – это количество измерений (метрик), генерируемых на каждом хосте, сервере. Следующие наборы данных были созданы с помощью TSBS для бенчмарка:
- 400K уникальный временной ряд, 60 секунд интервал между точками данных, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.
- 4M уникальный временной ряд, интервал 600 секунд, данные охватывают полные 3 дня, ~1.7B общее количество точек данных.
- 40M уникальный временной ряд, интервал 1 час, данные охватывают полные 3 дня, ~2.8 B общее количество точек данных.
Клиент и сервер были запущены на выделенных экземплярах n1-standard-16 в облаке Google. Эти экземпляры имели следующие конфигурации:
- vCPUs: 16
- ОЗУ: 60 ГБ
- Хранение: стандартный жесткий диск емкостью 1 ТБ. Он обеспечивает пропускную способность чтения/записи 120 Мбит/с, 750 операций чтения в секунду и 1,5К операций записи в секунду.
TSDBs были извлечены из официальных образов docker и запущены в docker со следующими конфигурациями:
Значения InfluxDB (- e необходимы для поддержки высокой мощности. Подробности смотрите в документации ):
TimescaleDB (конфигурация была принята из этого файла):
Загрузчик данных был запущен с 16 параллельными потоками.
Эта статья содержит только результаты для контрольных показателей вставки. Результаты выборочного бенчмарка будут опубликованы в отдельной статье.
Мониторинг: сбор данных
Мы используем в работе Prometheus — систему мониторинга высококардинальных метрик, которая помогает системным администраторам собирать данные о текущих параметрах систем и сервисов в удобном виде и настраивать оповещения для получения уведомлений об отклонениях. Однако у него есть некоторые критические для нас архитектурные ограничения: он не позволяет длительно хранить данные, сложен в масштабировании и потребляет много системных ресурсов. Поэтому нужно дополнительное решение для хранения данных, собранных Prometheus.
Alertmanager+Alerta
Alertmanager — это часть стека Prometheus для управления потоками алертов, которое мы продолжаем использовать. В дополнение к нему у нас появилась Alerta — удобное решение для отображения алертов и управления уведомлениями. Быстро устанавливается и легко масштабируется по мере роста требований и объемов. Она также гибко интегрируется с современными системами, предоставляющими свои специфичные метрики — например, netdata, Sensu, Pingdom и другими. Также можно разграничить уведомления для заказчиков и наших инженеров, которые работают с несколькими проектами. У Alerta удобный WebUI, который мы уже оценили: раньше мы использовали самописную php-страницу, которая выдергивала данные из Zabbix.
Для кого пригодится?
Традиционно, снова вернемся к базовым определениям: кого можно назвать системным администратором и кого считаем им мы в NGENIX. В прошлом году я рассказывал, чем занимаются каждый день наши ребята, а также порефлексировал на тему путей карьерного развития системного администратора и о том, почему его не стоит путать с эникейщиком.
Поэтому набор инструментов, которые инженеры используют каждый день, прежде всего связан с коммуникацией в команде и с заказчиком, c мониторингом состояния веб-ресурса, системой алертов об отклонениях в работе администрируемых систем — словом, со всем, что поможет настроить самый полный «центр управления полетами» и иметь представление о том, как работают веб-ресурсы в реальном времени и где им нужно помочь.
ВОПРОСЫ К СПИКЕРУ:
— Можно ознакомиться с какими-то бенчмарками, чтобы сравнить Prometheus и vmagent ?
— Мы проводили честный бенчмарк VictoriaMetrics , базы данных, который может не только при помощи vmagent ’а, но и самостоятельно собирать данные. Результаты можно посмотреть в документации.
— У Alertmanager есть возможность создания дополнительной crd по поводу рутов и ресиверов, вот для vmalert вы отписывались, что не очень хорошо используется создание дополнительной crd , ну, какой-то другой механизм существует в vmalert, подписывать ConfigMap ’ы на основании лейблов или аннотаций, ну или что-то другое, чтобы можно было динамически создавать пары?
— Да, эта имплементация планируется, возможно, в следующем релизе.
— Когда падает remote storage , возрастает ли потребление ресурсов?
— Нет, по идее ничего не возрастает. Есть два буфера — в памяти и дисковый. Второй заполняется после. И потреблять vmagent будет меньше, чем “single-версия” VictoriaMetrics .
— По поводу кластерности для vmagent . Не является ли это дополнительной точкой отказа? Используется ли кворум? Не проще ли использовать просто пару vmagent с дупликацией?
— Кворума нет. Указывается уникальный идентификатор для каждого vmagent ’а, он собирает часть данных с определенных таргетов. Можно запустить пару агентов, но будет повышенная нагрузка на экспортеры.
— В планах нет ли замены Alertmanager на что-то свое?
— Нет. Пока есть issue на поддержку Webhook , чтобы можно было отправлять алерты в разные системы.
— Когда теряется связь, данные буферизуются в сжатом или сыром виде?
— На диске они хранятся в сжатом виде, отправляются в бинарном Prometheus -формате.
— Были ли какие-то тесты, когда и связь пропадает и ноды рестартуются, теряются ли метрики?
— Да, они могут теряться, если происходит неправильное включение vmagent ’а. Если корректно завершить работу, то ничего не теряется.
Не так давно мы серьезно обновили стек инструментов, которые используют наши системные администраторы в повседневной работе, и готовы поделиться списком. Этому предшествовали годы использования различных решений, которые также не стояли на месте и развивались параллельно нашей работе — как в хорошую, так и в плохую, на наш взгляд, сторону. В этой статье я разберу тулсет, который сформировался у нас на начало 2021 года, расскажу, чем он хорош, и объясню плюсы и минусы его альтернатив.
Альтернатива: Elastic Search, Hadoop
Всем в сообществе известные базы данных — но в нашем случае (логирование клиентских сервисов) по производительности они сильно отстают от Clickhouse — в частности, Hadoop, от которого мы отказались.
Альтернатива: Notion
Notion в качестве wiki обладает обширными возможностями: можно работать с документами, управлять проектами, вести базы знаний, хранить базы данных. Клиент Notion работает быстро, есть некоторые преимущества по сравнению с Confluence — например, маркдауны, подсветка кода. Для нас удобнее было пользоваться продуктами Atlassian, но каждый делает свой выбор.
4M уникальные временные ряды
4M временные ряды выглядят немного вызывающе. Но наши конкуренты успешно сдают этот экзамен. Результаты бенчмарка:
- VictoriaMetrics: 2,2М точек данных в секунду; использование оперативной памяти: 6 ГБ; окончательный размер данных на диске: 3 ГБ.
- InfluxDB: 330К точек данных в секунду; использование оперативной памяти: 20,5 ГБ; окончательный размер данных на диске: 18,4 ГБ.
- TimescaleDB: 480K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 52 ГБ.
Производительность InfluxDB упала с 1,2 млн точек данных в секунду для 400К временного ряда до 330 тыс. точек данных в секунду для 4M временного ряда. Это значительная потеря производительности по сравнению с другими конкурентами. Давайте посмотрим на графики использования процессора, чтобы понять первопричину этой потери:
Выше скриншот: VictoriaMetrics — Использование CPU при тесте вставки для уникального временного ряда 4M.
Выше скриншот: InfluxDB — Использование CPU при тесте вставки для уникального временного ряда 4M.
Выше скриншот: TimescaleDB — Использование CPU при тесте вставки для уникального временного ряда 4M.
VictoriaMetrics использует почти всю мощность процессора (CPU). Снижение в конце соответствует оставшимся LSM слияниям после вставки всех данных.
InfluxDB использует только 8 из 16 vCPUs, в то время как TimsecaleDB использует 4 из 16 vCPUs. Что общего у их графиков? Высокая доля iowait , что, опять же, указывает на узкое место ввода-вывода.
TimescaleDB имеет высокую долю system . Полагаем, что высокая мощность привела ко многим системным вызовам или ко многим minor page faults .
Давайте посмотрим на графики пропускной способности диска:
Выше скриншот: VictoriaMetrics — Использование полосы пропускания диска для вставки 4M уникальных метрик.
Выше скриншот: InfluxDB — Использование полосы пропускания диска для вставки 4M уникальных метрик.
Выше скриншот: TimescaleDB — Использование полосы пропускания диска для вставки 4M уникальных метрик.
VictoriaMetrics достигали предела 120 МБ/с в пик, в то время как средняя скорость записи составляла 40 МБ/с. Вероятно, во время пика было выполнено несколько тяжелых слияний LSM.
InfluxDB снова выжимает среднюю пропускную способность записи 200 МБ/с с пиками до 340 МБ/с на диске с ограничением записи 120 МБ/с 🙂
TimescaleDB больше не ограничена диском. Похоже, что он ограничен чем-то еще, связанным с высокой долей системной загрузки CPU.
Давайте посмотрим на графики использования IO:
Выше скриншот: VictoriaMetrics — Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.
Выше скриншот: InfluxDB — Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.
Выше скриншот: TimescaleDB — Использование ввода-вывода во время теста вставки для уникального временного ряда 4M.
Графики использования IO повторяют графики использования полосы пропускания диска — InfluxDB ограничен IO, в то время как VictoriaMetrics и TimescaleDB имеют запасные ресурсы ввода-вывода IO.
Zendesk
Мы используем Zendesk — это, наверное, один из самых знаменитых SaaS-хелпдесков среди систем обработки обращений клиентов. Zendesk имеет интуитивный интерфейс, очень широкие возможности интеграции, поддерживает REST, JSON, RSS, email, различные виджеты. Заказчик может создать тикет через почту, веб-интерфейс или через другие каналы — например, есть удобная интеграция с Telegram. Мы также интегрировали Zendesk с нашей системой мониторинга для соблюдения SLA, а также телефонией.
400К уникальных временных рядов
Давайте начнем с простых элементов — 400К. Результаты бенчмарка:
- VictoriaMetrics: 2,6М точек данных в секунду; использование оперативной памяти: 3 ГБ; окончательный размер данных на диске: 965 МБ
- InfluxDB: 1.2M точек данных в секунду; использование оперативной памяти: 8.5 GB; окончательный размер данных на диске: 1.6 GB
- Timescale: 849K точек данных в секунду; использование оперативной памяти: 2,5 ГБ; окончательный размер данных на диске: 50 ГБ
Как вы можете видеть из приведенных выше результатов, VictoriaMetrics выигрывает в производительности вставки и степени сжатия. Временная шкала выигрывает в использовании оперативной памяти, но она использует много дискового пространства — 29 байт на точку данных.
Ниже приведены графики использования процессора (CPU) для каждого из TSDBs во время бенчмарка:
Выше скриншот: VictoriaMetrics — Загрузка CPU при тесте вставки для уникальной метрики 400K.
Выше скриншот: InfluxDB — Загрузка CPU при тесте вставки для уникальной метрики 400K.
Выше скриншот: TimescaleDB — Загрузка CPU при тесте вставки для уникальной метрики 400K.
VictoriaMetrics использует все доступные vCPUs, в то время как InfluxDB недостаточно использует ~2 из 16 vCPUs.
Timescale использует только 3-4 из 16 vCPUs. Высокие доли iowait и system на TimescaleDB графике временных масштабов указывают на узкое место в подсистеме ввода-вывода (I/O). Давайте посмотрим на графики использования пропускной способности диска:
Выше скриншот: VictoriaMetrics — Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.
Выше скриншот: InfluxDB — Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.
Выше скриншот: TimescaleDB — Использование пропускной способности диска при тесте вставки для уникальных показателей 400K.
VictoriaMetrics записывает данные со скоростью 20 Мбит/с с пиками до 45 Мбит/с. Пики соответствуют большим частичным слияниям в дереве LSM .
InfluxDB записывает данные со скоростью 160 МБ/с, в то время как 1 ТБ диск должен быть ограничен пропускной способностью записи 120 МБ/с.
TimescaleDB ограничена пропускной способностью записи 120 Мбит/с, но иногда она нарушает этот предел и достигает 220 Мбит/с в пиковых значениях. Эти пики соответствуют провалам недостаточной загрузки процессора на предыдущем графике.
Давайте посмотрим на графики использования ввода-вывода (I/O):
Выше скриншот: VictoriaMetrics — Использование ввода-вывода при тесте вставки для 400K уникальных метрик.
Выше скриншот: InfluxDB — Использование ввода-вывода при тесте вставки для 400K уникальных метрик.
Выше скриншот: TimescaleDB — Использование ввода-вывода при тесте вставки для 400K уникальных метрик.
Теперь ясно, что TimescaleDB достигает предела ввода-вывода, поэтому он не может использовать оставшиеся 12 vCPUs.
Альтернатива: Jira Service Desk
Функционально нативный хелпдеск Jira практически идентичен Zendesk. Это онлайн-сервис обработки тикетов от Atlassian, который предлагает огромное количество настроек и интеграций, а также большие возможности для масштабирования. Выбирая между JIRA Service Desk и Zendesk, скорее всего, вам стоит обратить внимание на простоту интеграции с имеющимися инструментами, потому что миграция может быть долгой и сложной, что очень неудобно, если вы живете в мире жесткого SLA.
Альтернативы: Thanos, Graphite, Influx, Zabbix
Мы долгое время полагались на комбинацию Prometheus и Zabbix, но ограничения Zabbix в плане производительности заставили нас поискать альтернативы. Сами мы рассматривали очевидный выбор — Thanos, но технологически он был намного сложнее Victoria Metrics, и в итоге мы выбрали последнее.
Автоматизация хелпдеска
Если вы работаете с высоконагруженными сервисами, крупными веб-ресурсами, критически важными системами, процесс поступления тикетов обязан быть максимально автоматизированным, потому что хаосу здесь не место.
Confluence
Также стандарт отрасли в качестве инструмента хранения и систематизации базы знаний — в Confluence мы описываем и разбираем инциденты, фиксируем решения. Confluence очень проста в управлении, в то время как многие автономные инструменты требуют наработки определенных знаний в настройке и эксплуатации. За что еще можно любить Confluence? За отличную и интуитивную систему управления версиями, которая упрощает внутреннюю документацию, а также за удобную навигацию и возможность интеграции с многочисленными плагинами.
Выводы
- Современные TSDBs способны обрабатывать вставки для миллионов уникальных временных рядов на одном сервере. В следующей статье мы проверим, насколько хорошо TSDBs выполняет выбор по миллионам уникальных временных рядов.
- Недостаточная загрузка процессора обычно указывает на узкое место ввода-вывода. Кроме того, это может указывать на слишком грубую блокировку, когда одновременно может работать только несколько потоков.
- Узкое место ввода-вывода действительно существует, особенно в хранилищах без SSD, таких как виртуализированные блочные устройства облачных провайдеров.
- VictoriaMetrics обеспечивает наилучшую оптимизацию для медленных хранилищ с низким уровнем ввода-вывода. Он обеспечивает наилучшую скорость и наилучшую степень сжатия.
Загрузите односерверный образ VictoriaMetrics и попробуйте его на своих данных. Соответствующий статический двоичный файл доступен на GitHub .
Мониторинг: визуализация данных
Grafana предоставляет интерфейс работы с графиками, обновляемыми в режиме real-time — пользователь системы может настроить себе удобную «приборную панель», используя различные виды графиков (используя уже разработанные сообществом или собственные дашборды) — это особенно важно, если нужно мониторить большое количество параметров — в нашем случае это, например, параметры работы сервисов заказчика: количество запросов, их статус, время ответа и т.п. Де-факто это стандарт отрасли, даже добавить нечего.
ВОПРОСЫ К СПИКЕРУ:
— Можно ознакомиться с какими-то бенчмарками, чтобы сравнить Prometheus и vmagent ?
— Мы проводили честный бенчмарк VictoriaMetrics , базы данных, который может не только при помощи vmagent ’а, но и самостоятельно собирать данные. Результаты можно посмотреть в документации.
— У Alertmanager есть возможность создания дополнительной crd по поводу рутов и ресиверов, вот для vmalert вы отписывались, что не очень хорошо используется создание дополнительной crd , ну, какой-то другой механизм существует в vmalert, подписывать ConfigMap ’ы на основании лейблов или аннотаций, ну или что-то другое, чтобы можно было динамически создавать пары?
— Да, эта имплементация планируется, возможно, в следующем релизе.
— Когда падает remote storage , возрастает ли потребление ресурсов?
— Нет, по идее ничего не возрастает. Есть два буфера — в памяти и дисковый. Второй заполняется после. И потреблять vmagent будет меньше, чем “single-версия” VictoriaMetrics .
— По поводу кластерности для vmagent . Не является ли это дополнительной точкой отказа? Используется ли кворум? Не проще ли использовать просто пару vmagent с дупликацией?
— Кворума нет. Указывается уникальный идентификатор для каждого vmagent ’а, он собирает часть данных с определенных таргетов. Можно запустить пару агентов, но будет повышенная нагрузка на экспортеры.
— В планах нет ли замены Alertmanager на что-то свое?
— Нет. Пока есть issue на поддержку Webhook , чтобы можно было отправлять алерты в разные системы.
— Когда теряется связь, данные буферизуются в сжатом или сыром виде?
— На диске они хранятся в сжатом виде, отправляются в бинарном Prometheus -формате.
— Были ли какие-то тесты, когда и связь пропадает и ноды рестартуются, теряются ли метрики?
— Да, они могут теряться, если происходит неправильное включение vmagent ’а. Если корректно завершить работу, то ничего не теряется.
Не так давно мы серьезно обновили стек инструментов, которые используют наши системные администраторы в повседневной работе, и готовы поделиться списком. Этому предшествовали годы использования различных решений, которые также не стояли на месте и развивались параллельно нашей работе — как в хорошую, так и в плохую, на наш взгляд, сторону. В этой статье я разберу тулсет, который сформировался у нас на начало 2021 года, расскажу, чем он хорош, и объясню плюсы и минусы его альтернатив.
Таск-трекинг
Это также стандарт отрасли, который изначально создавался под идеологию работы ИТ-бизнеса, и здесь даже трудно предложить сопоставимые альтернативы. Jira — невероятно гибкий инструмент, у него бесчисленное количество плагинов, широкие возможности интеграции «из коробки» с практически всеми известными инструментами, и каждый год появляются новые, что повышает ценность Jira в отрасли еще больше. Маленькие команды могут использовать более доступную версию, большие компании могут позволить себе более дорогую лицензию и расширить функциональность. Другими словами — Jira объединяет =)
Конечно, есть множество платных, бесплатных, условно бесплатных альтернатив, их можно допиливать, дописывать, страдать в процессе, но это не для нас. И не для вас, если вы приоритизируете свой продукт и клиентский сервис.
Clickhouse
Clickhouse — это колоночная база данных для хранения логов. Если логи структурированы, с ней очень удобно работать через SQL-подобный синтаксис — любые нужные данные, в том числе для работы нашей аналитики трафика в реальном времени, предоставляются в удобном виде и очень быстро (а скорость для нас критически важна). Благодаря высокой производительности и гибкости можно посмотреть на наши данные под любым углом и, например, быстро проанализировать критический инцидент. Удобно, просто интегрировать — иными словами, стильно, модно, молодежно.
Коммуникация в команде
Здесь можно поломать много копий. Что удобнее — Slack или Basecamp? Лучше созваниваться в Teams или Zoom? Однозначного ответа на эти вопросы нет, и здесь особенно трудно посоветовать что-то конкретное, поэтому выбирайте сердцем.
Victoria Metrics
Victoria metrics — решение для мониторинга на базе открытого кода с расширенным функционалом и возможностями масштабирования как вертикально, так и горизонтально. Victoria metrics умеет долго хранить метрики, как и многие другие инструменты, но при этом быстро обрабатывает их, не требуя больших вычислительных ресурсов, что важно при высокой нагрузке на системы. Именно рост нагрузки выявил ограничения Zabbix в качестве хранилища данных Prometheus, но Victoria Metrics решала их задачи разом, экономя при этом ресурсы.
Альтернатива: Telegram
До этого мы активно использовали Telegram в службе сопровождения: общались в мессенжере как между собой, так и с заказчиками, применяли бота для срочных клиентских обращений. Все-таки как продукт разработки Telegram можно вполне смело поставить рядом со Slack — постоянно добавляются улучшения и новые фичи, которые делают жизнь легче. С переездом в Slack мы решили унифицировать все каналы коммуникации в команде и в Telegram больше не общаемся столь регулярно, но временами ностальгируем — даже стикерпак запилили. Кто в теме — пользуйте =)
VictoriaMetrics, TimescaleDB и InfluxDB были сравнены в предыдущей статье по набору данных с миллиардом точек данных, принадлежащих 40K уникальным временным рядам.
Несколько лет назад была эпоха Zabbix. Каждый bare metal сервер имел не более нескольких показателей – использование процессора, использование оперативной памяти, использование диска и использование сети. Таким образом метрики с тысяч серверов могут поместиться в 40 тысяч уникальных временных рядов, а Zabbix может использовать MySQL в качестве бэкенда для данных временных рядов 🙂
В настоящее время один node_exporter с конфигурациями по умолчанию предоставляет более 500 метрик на среднем хосте. Существует множество экспортеров для различных баз данных, веб-серверов, аппаратных систем и т. д. Все они предоставляют множество полезных показателей. Все больше и больше приложений начинают выставлять различные показатели на себя. Существует Kubernetes с кластерами и pod-ами, раскрывающими множество метрик. Это приводит к тому, что серверы выставляют тысячи уникальных метрик на хост. Таким образом, уникальный временной ряд 40K больше не является высокой мощностью. Он становится мейнстримом, который должен быть легко обработан любой современной TSDB на одном сервере.
Что такое большое количество уникальных временных рядов на данный момент? Наверное, 400К или 4М? Или 40м? Давайте сравним современные TSDBs с этими цифрами.
Мониторинг
Это важнейшая часть нашего воркфлоу: служба сопровождения и технической поддержки должна иметь полное и наглядное представление о том, что происходит с системами клиентов и нашей собственной инфраструктурой, а также получать своевременные уведомления об инцидентах и состоянии систем. В конце прошлого года мы провели ревизию инструментов мониторинга: выросло количество систем и ПО, которые нужно мониторить; из-за роста нагрузки пришло время разделиться на несколько команд; требовалось более точно и быстро реагировать на инциденты.
Инструменты мониторинга, которые мы использовали раньше, в этих условиях нам уже не подходили: отслеживать изменения стало сложнее, на новых объемах вскрылись ограничения, обусловленные легаси-системами, возникла потребность в более гибком алертинге. После того, как мы сменили стек инструментов, мы смогли унифицировать работу трех составляющих системы мониторинга (сбор данных, их визуализацию в графики и дэшборды, алерты), избавились таким образом от большой доли легаси, получили больше прозрачности, масштабируемости, воспроизводимости.
Управление знаниями
40М уникальные тайм серии
40М уникальные временные ряды были слишком большими для InfluxDB 🙁
- VictoriaMetrics: 1,7М точек данных в секунду; использование оперативной памяти: 29 ГБ; использование дискового пространства: 17 ГБ.
- InfluxDB: не закончил, потому что для этого требовалось более 60 ГБ оперативной памяти.
- TimescaleDB: 330К точек данных в секунду, использование оперативной памяти: 2,5 ГБ; использование дискового пространства: 84GB.
TimescaleDB показывает исключительно низкое и стабильное использование оперативной памяти – 2,5 ГБ — столько же, сколько и для уникальных метрик 4M и 400K.
VictoriaMetrics медленно увеличивались со скоростью 100 тысяч точек данных в секунду, пока не были обработаны все 40М метрических имен с метками. Затем он достиг устойчивой скорости вставки 1,5-2,0М точек данных в секунду, так что конечный результат составил 1,7М точек данных в секунду.
Графики для 40М уникальных временных рядов аналогичны графикам для 4М уникальных временных рядов, поэтому давайте их пропустим.
Альтернатива: Zabbix
Мониторинг: алертинг
Slack
Мы выбрали Slack для внутренней коммуникации, настроили нужные нам интеграции с другими системами — в среде ИТ и разработки Slack очень популярен, поэтому интегрировать можно много чего. В канал команды в Slack приходят важные алерты: например, о только что сформированном тикете. Через простые команды можно начать срочный звонок в Зуме, создать тикет, получать уведомления по инцидентам и многому другому. Классно — честно, мы были очень рады, когда переехали из Teams в Slack.
База данных для логирования
Читайте также: