github-mirrors/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2024-11-21 14:44:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
VictoriaMetrics/docs/FAQ.md

229 lines
18 KiB
Markdown
Raw Normal View History

docs: update docs ordering and formatting (#1192) The major change is adding `sort` directive to docs. For those docs which are copied from internal packages `sort` is added via makefile command. For the rest it is added manually since they're updated manually as well. The rest of changes is connected with markdown formatting. For example, changing headers in some files (`##` => `#`) makes navigation on .github.io to look better. This especially useful for `changelog` docs. Table of contents for `vmctl` is dropped, since we already have it autogenerated on .github.io. No link changes expected. The corresponding PR to `cluster` branch will be made in follow-up PR.
2021-04-07 10:39:16 +00:00
---
sort: 18
---
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
# FAQ
### What is the main purpose of VictoriaMetrics?
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
To provide the best monitoring solution.
### Who uses VictoriaMetrics?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [case studies](https://victoriametrics.github.io/CaseStudies.html).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Which features does VictoriaMetrics have?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html#prominent-features).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### How to start using VictoriaMetrics?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/Quick-Start.html).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs/FAQ.md: add a question about the difference between `vmagent` and `Prometheus`
2020-06-03 17:56:22 +00:00
### What is the difference between vmagent and Prometheus?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
While both [vmagent](https://victoriametrics.github.io/vmagent.html) and Prometheus may scrape Prometheus targets (aka `/metrics` pages)
docs/FAQ.md: add a question about the difference between `vmagent` and `Prometheus`
2020-06-03 17:56:22 +00:00
according to the provided Prometheus-compatible [scrape configs](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)
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 comparing to Prometheus when scraping big number of targets (more than 1000)
or targets with big number of exposed metrics.
- vmagent provides independent disk-backed buffers per each configured remote storage (aka `-remoteWrite.url`). This means that slow or temporarily unavailable storage
doesn't prevent from sending data to healthy storage in parallel. Prometheus uses a single shared buffer for all the configured remote storage systems (aka `remote_write->url`)
with the hardcoded retention of 2 hours.
- vmagent may accept, relabel and filter data obtained via multiple data ingestion protocols additionally to data scraped from Prometheus targets.
I.e. it supports both `pull` and `push` protocols for data ingestion.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/vmagent.html#features) for details.
docs/FAQ.md: add a question about the difference between `vmagent` and `Prometheus`
2020-06-03 17:56:22 +00:00
- vmagent may be used in different use cases:
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
- [IoT and edge monitoring](https://victoriametrics.github.io/vmagent.html#iot-and-edge-monitoring)
- [Drop-in replacement for Prometheus](https://victoriametrics.github.io/vmagent.html#drop-in-replacement-for-prometheus)
- [Replication and High Availability](https://victoriametrics.github.io/vmagent.html#replication-and-high-availability)
- [Relabeling and Filtering](https://victoriametrics.github.io/vmagent.html#relabeling-and-filtering)
- [Splitting data streams among multiple systems](https://victoriametrics.github.io/vmagent.html#splitting-data-streams-among-multiple-systems)
- [Prometheus remote_write proxy](https://victoriametrics.github.io/vmagent.html#prometheus-remote_write-proxy)
docs/FAQ.md: add a question about the difference between `vmagent` and `Prometheus`
2020-06-03 17:56:22 +00:00
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
### Is it safe to enable [remote write](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) in Prometheus?
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
Yes. Prometheus continues writing data to local storage after enabling remote write, so all the existing local storage data
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
and new data is available for querying via Prometheus as usual.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
It is recommended using [vmagent](https://victoriametrics.github.io/vmagent.html) for scraping Prometheus targets
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
and writing data to VictoriaMetrics.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs/FAQ.md: small fixes
2020-04-05 10:52:43 +00:00
### How does VictoriaMetrics compare to other remote storage solutions for Prometheus such as [M3 from Uber](https://eng.uber.com/m3/), [Thanos](https://github.com/thanos-io/thanos), [Cortex](https://github.com/cortexproject/cortex), etc.?
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
VictoriaMetrics is simpler, faster, more cost-effective and it provides [MetricsQL query language](MetricsQL) based on PromQL. The simplicity is twofold:
- It is simpler to configure and operate. There is no need in configuring [sidecars](https://github.com/thanos-io/thanos/blob/master/docs/components/sidecar.md),
fighting [gossip protocol](https://github.com/improbable-eng/thanos/blob/030bc345c12c446962225221795f4973848caab5/docs/proposals/completed/201809_gossip-removal.md)
or setting up third-party systems such as [Consul](https://github.com/cortexproject/cortex/issues/157), [Cassandra](https://cortexmetrics.io/docs/production/cassandra/),
[DynamoDB](https://cortexmetrics.io/docs/production/aws/) or [Memcached](https://cortexmetrics.io/docs/production/caching/).
- VictoriaMetrics has simpler architecture. This means less bugs and more useful features in the long run comparing to competing TSDBs.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs: add references to `Remote Write Storage Wars` Also mention than VictoriaMetrics uses less RAM than Thanos Store Gateway - see https://github.com/thanos-io/thanos/issues/448 for details.
2020-01-04 21:56:27 +00:00
See [comparing Thanos to VictoriaMetrics cluster](https://medium.com/@valyala/comparing-thanos-to-victoriametrics-cluster-b193bea1683)
and [Remote Write Storage Wars](https://promcon.io/2019-munich/talks/remote-write-storage-wars/) talk from [PromCon 2019](https://promcon.io/2019-munich/talks/remote-write-storage-wars/).
VictoriaMetrics also [uses less RAM than Thanos components](https://github.com/thanos-io/thanos/issues/448).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
### What is the difference between VictoriaMetrics and [Cortex](https://github.com/cortexproject/cortex)?
VictoriaMetrics is similar to Cortex in the following aspects:
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
- Both systems accept data from [vmagent](https://victoriametrics.github.io/vmagent.html) or Prometheus
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
via standard [remote_write API](https://prometheus.io/docs/practices/remote_write/), i.e. there is no need in running sidecars
unlike in [Thanos](https://github.com/thanos-io/thanos) case.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
- Both systems support multi-tenancy out of the box. See [the corresponding docs for VictoriaMetrics](https://victoriametrics.github.io/Cluster-VictoriaMetrics.html#multitenancy).
- Both systems support data replication. See [replication in Cortex](https://github.com/cortexproject/cortex/blob/fe56f1420099aa1bf1ce09316c186e05bddee879/docs/architecture.md#hashing) and [replication in VictoriaMetrics](https://victoriametrics.github.io/Cluster-VictoriaMetrics.html#replication-and-data-safety).
- Both systems scale horizontally to multiple nodes. See [these docs](https://victoriametrics.github.io/Cluster-VictoriaMetrics.html#cluster-resizing-and-scalability) for details.
- Both systems support alerting and recording rules via the corresponding tools such as [vmalert](https://victoriametrics.github.io/vmalert.html).
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
Fix misspelled Cortex name in the FAQ (#421)
2020-04-17 07:36:12 +00:00
The main differences between Cortex and VictoriaMetrics:
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
- 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 comparing to VictoriaMetrics' case,
which doesn't use any external services. Compare [Cortex Architecture](https://github.com/cortexproject/cortex/blob/master/docs/architecture.md)
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
to [VictoriaMetrics architecture](https://victoriametrics.github.io/Cluster-VictoriaMetrics.html#architecture-overview).
- VictoriaMetrics provides [production-ready single-node solution](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html),
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
which is much easier to setup and operate than Cortex cluster.
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
- Cortex may lose up to 12 hours of recent data on Ingestor failure - see [the corresponding docs](https://github.com/cortexproject/cortex/blob/fe56f1420099aa1bf1ce09316c186e05bddee879/docs/architecture.md#ingesters-failure-and-data-loss).
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
VictoriaMetrics may lose only a few seconds of recent data, which isn't synced to persistent storage yet.
See [this article for details](https://medium.com/@valyala/wal-usage-looks-broken-in-modern-time-series-databases-b62a627ab704).
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
- Cortex is usually slower and requires more CPU and RAM than VictoriaMetrics. See [this talk from adidas at PromCon 2019](https://promcon.io/2019-munich/talks/remote-write-storage-wars/) and [other case studies](https://victoriametrics.github.io/CaseStudies.html).
all: add native format for data export and import The data can be exported via [/api/v1/export/native](https://victoriametrics.github.io/#how-to-export-data-in-native-format) handler and imported via [/api/v1/import/native](https://victoriametrics.github.io/#how-to-import-data-in-native-format) handler.
2020-09-26 01:29:45 +00:00
- VictoriaMetrics accepts data in multiple popular data ingestion protocols additionally to Prometheus remote_write protocol - InfluxDB, OpenTSDB, Graphite, CSV, JSON, native binary.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html#how-to-import-time-series-data) for details.
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
### What is the difference between VictoriaMetrics and [Thanos](https://github.com/thanos-io/thanos)?
- Thanos re-uses Prometheus source code, while VictoriaMetrics is written from scratch.
- VictoriaMetrics accepts data via [standard remote_write API for Prometheus](https://prometheus.io/docs/practices/remote_write/),
while Thanos uses non-standard [Sidecar](https://github.com/thanos-io/thanos/blob/master/docs/components/sidecar.md), which must run alongside each Prometheus instance.
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
- Thanos Sidecar requires disabling data compaction in Prometheus, which may hurt Prometheus performance and increase RAM usage. See [these docs](https://thanos.io/components/sidecar.md/) for more details.
- Thanos stores data in object storage (Amazon S3 or Google GCS), while VictoriaMetrics stores data in block storage
([GCP persistent disks](https://cloud.google.com/compute/docs/disks#pdspecs), 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 in using more expensive SSD or NVMe disks in most cases.
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
- 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 isn't synced to persistent storage yet. See [this article for details](https://medium.com/@valyala/wal-usage-looks-broken-in-modern-time-series-databases-b62a627ab704).
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
- VictoriaMetrics provides [production-ready single-node solution](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html),
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
which is much easier to setup and operate than Thanos components.
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
- Thanos may be harder to setup and operate comparing to VictoriaMetrics, since it has more moving parts, which can be connected with less reliable networks.
See [this article for details](https://medium.com/faun/comparing-thanos-to-victoriametrics-cluster-b193bea1683).
docs: lowercase `adidas` trademark according to their request
2020-11-18 11:47:08 +00:00
- Thanos is usually slower and requires more CPU and RAM than VictoriaMetrics. See [this talk from adidas at PromCon 2019](https://promcon.io/2019-munich/talks/remote-write-storage-wars/).
all: add native format for data export and import The data can be exported via [/api/v1/export/native](https://victoriametrics.github.io/#how-to-export-data-in-native-format) handler and imported via [/api/v1/import/native](https://victoriametrics.github.io/#how-to-import-data-in-native-format) handler.
2020-09-26 01:29:45 +00:00
- VictoriaMetrics accepts data in multiple popular data ingestion protocols additionally to Prometheus remote_write protocol - InfluxDB, OpenTSDB, Graphite, CSV, JSON, native binary.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html#how-to-import-time-series-data) for details.
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### How does VictoriaMetrics compare to [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/)?
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
- VictoriaMetrics requires [10x less RAM](https://medium.com/@valyala/insert-benchmarks-with-inch-influxdb-vs-victoriametrics-e31a41ae2893) and it [works faster](https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae).
- VictoriaMetrics provides [better query language](https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085) than InfluxQL or Flux.
all: add native format for data export and import The data can be exported via [/api/v1/export/native](https://victoriametrics.github.io/#how-to-export-data-in-native-format) handler and imported via [/api/v1/import/native](https://victoriametrics.github.io/#how-to-import-data-in-native-format) handler.
2020-09-26 01:29:45 +00:00
- VictoriaMetrics accepts data in multiple popular data ingestion protocols additionally to InfluxDB - Prometheus remote_write, OpenTSDB, Graphite, CSV, JSON, native binary.
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See [these docs](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html#how-to-import-time-series-data) for details.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### How does VictoriaMetrics compare to [TimescaleDB](https://www.timescale.com/)?
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
- TimescaleDB insists on using SQL as a query language. While SQL is more powerful than PromQL, this power is rarely required during typical TSDB usage. Real-world queries usually [look clearer and simpler when written in PromQL than in SQL](https://medium.com/@valyala/promql-tutorial-for-beginners-9ab455142085).
- VictoriaMetrics requires [up to 70x less storage space comparing to TimescaleDB](https://medium.com/@valyala/when-size-matters-benchmarking-victoriametrics-vs-timescale-and-influxdb-6035811952d4) 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](https://docs.timescale.com/latest/using-timescaledb/compression) (it isn't an easy task in general case :)).
- VictoriaMetrics accepts data in multiple popular data ingestion protocols - InfluxDB, OpenTSDB, Graphite, CSV, while TimescaleDB supports only SQL inserts.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
### Does VictoriaMetrics use Prometheus technologies like other clustered TSDBs built on top of Prometheus such as [Thanos](https://github.com/thanos-io/thanos) or [Cortex](https://github.com/cortexproject/cortex)?
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
No. VictoriaMetrics core is written in Go from scratch by [fasthttp](https://github.com/valyala/fasthttp) [author](https://github.com/valyala).
The architecture is [optimized for storing and querying large amounts of time series data with high cardinality](https://medium.com/devopslinks/victoriametrics-creating-the-best-remote-storage-for-prometheus-5d92d66787ac). VictoriaMetrics storage uses [certain ideas from ClickHouse](https://medium.com/@valyala/how-victoriametrics-makes-instant-snapshots-for-multi-terabyte-time-series-data-e1f3fb0e0282). Special thanks to [Alexey Milovidov](https://github.com/alexey-milovidov).
docs/FAQ.md: add bullet comparison with Cortex and Thanos
2020-01-15 08:47:28 +00:00
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Are there performance comparisons with other solutions?
Yes:
docs/FAQ.md: add a link to https://valyala.medium.com/prometheus-vs-victoriametrics-benchmark-on-node-exporter-metrics-4ca29c75590f in `performance comparisons` section
2020-12-02 19:24:52 +00:00
* [Prometheus vs VictoriaMetrics benchmark on node-exporter metrics](https://valyala.medium.com/prometheus-vs-victoriametrics-benchmark-on-node-exporter-metrics-4ca29c75590f)
docs/FAQ.md: add a link to https://valyala.medium.com/promscale-vs-victoriametrics-resource-usage-on-production-workload-91c8e3786c03 in the question about benchmarks
2020-12-16 21:15:08 +00:00
* [Promscale vs VictoriaMetrics: measuring resource usage in production](https://valyala.medium.com/promscale-vs-victoriametrics-resource-usage-on-production-workload-91c8e3786c03)
docs/FAQ.md: add more articles about VictoriaMetrics performance
2020-04-05 10:47:31 +00:00
* [Benchmarking time series workloads on Apache Kudu using TSBS](https://blog.cloudera.com/benchmarking-time-series-workloads-on-apache-kudu-using-tsbs/)
* [Billy: how VictoriaMetrics deals with more than 500 billion rows](https://medium.com/@valyala/billy-how-victoriametrics-deals-with-more-than-500-billion-rows-e82ff8f725da)
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
* [Measuring vertical scalability for time series databases: VictoriaMetrics vs InfluxDB vs TimescaleDB](https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae).
* [Measuring insert performance on high-cardinality time series: VictoriaMetrics vs InfluxDB](https://medium.com/@valyala/insert-benchmarks-with-inch-influxdb-vs-victoriametrics-e31a41ae2893)
* [TSBS benchmark on high-cardinality time series: VictoriaMetrics vs InfluxDB vs TimescaleDB](https://medium.com/@valyala/high-cardinality-tsdb-benchmarks-victoriametrics-vs-timescaledb-vs-influxdb-13e6ee64dd6b)
* [Standard TSBS benchmark: VictoriaMetrics vs InfluxDB vs TimescaleDB](https://medium.com/@valyala/when-size-matters-benchmarking-victoriametrics-vs-timescale-and-influxdb-6035811952d4)
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
See also [other articles about VictoriaMetrics](https://victoriametrics.github.io/Articles.html).
docs: refresh docs about replication support
2020-05-27 14:47:55 +00:00
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### What is the pricing for VictoriaMetrics?
The following versions are open source and free:
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
* [Single-node version](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
* [Cluster version](https://github.com/VictoriaMetrics/VictoriaMetrics/tree/cluster).
We provide commercial support for both versions. [Contact us](mailto:info@victoriametrics.com) for the pricing.
docs: refresh docs about replication support
2020-05-27 14:47:55 +00:00
The following commercial versions of VictoriaMetrics are planned:
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
* Managed cluster in the Cloud.
* SaaS version.
docs: update FAQ.md
2020-06-02 16:58:07 +00:00
[Contact us](mailto:info@victoriametrics.com) for more information on our plans.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Why VictoriaMetrics doesn't support [Prometheus remote read API](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cremote_read%3E)?
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 had 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](https://github.com/prometheus/prometheus/issues/4456) for details.
docs/FAQ.md: use less confusing links in the chapter explaining why VictoriaMetrics doesnt support Prometheus remote_read API
2020-12-11 19:23:20 +00:00
So just query VictoriaMetrics directly via [Prometheus Querying API](https://victoriametrics.github.io/#prometheus-querying-api-usage)
or via [Prometheus datasource in Grafana](https://victoriametrics.github.io/#grafana-setup).
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Does VictoriaMetrics deduplicate data from Prometheus instances scraping the same targets (aka `HA pairs`)?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
Yes. See [these docs](https://victoriametrics.github.io/Single-server-VictoriaMetrics.html#deduplication) for details.
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
docs: refresh docs about replication support
2020-05-27 14:47:55 +00:00
### Does VictoriaMetrics support replication?
docs: consistently use links to https://victoriametrics.github.io for documentation references
2020-12-11 19:08:13 +00:00
Yes. See [these docs](https://victoriametrics.github.io/Cluster-VictoriaMetrics.html#replication-and-data-safety) for details.
docs: refresh docs about replication support
2020-05-27 14:47:55 +00:00
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Where is the source code of VictoriaMetrics?
Source code for the following versions is available in the following places:
docs: Mention Slack and Telegram channels for user questions
2020-01-22 14:46:23 +00:00
* [Single-node version](https://github.com/VictoriaMetrics/VictoriaMetrics)
* [Cluster version](https://github.com/VictoriaMetrics/VictoriaMetrics/tree/cluster)
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Does VictoriaMetrics 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](https://medium.com/@valyala/high-cardinality-tsdb-benchmarks-victoriametrics-vs-timescaledb-vs-influxdb-13e6ee64dd6b),
perfectly [scales up on a single node](https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae)
and scales horizontally to multiple nodes.
### Where can I ask questions about VictoriaMetrics?
docs: Mention Slack and Telegram channels for user questions
2020-01-22 14:46:23 +00:00
Questions about VictoriaMetrics can be asked via the following channels:
- [Slack channel](http://slack.victoriametrics.com/)
- [Telegram channel](https://t.me/VictoriaMetrics_en)
- [Google group](https://groups.google.com/forum/#!forum/victorametrics-users)
docs: add docs as in the single-node branch
2019-12-05 17:28:21 +00:00
### Where can I file bugs and feature requests regarding VictoriaMetrics?
File bugs and feature requests [here](https://github.com/VictoriaMetrics/VictoriaMetrics/issues).
### Are you looking for investors?
Yes. [Mail us](mailto:info@victoriametrics.com) if you are interested in.
Reference in a new issue Copy permalink