Kiu/VictoriaMetrics
Kiu/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2024-12-15 00:13:30 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs/CaseStudies.md: update Grammarly case study with the newly published article https://www.grammarly.com/blog/engineering/monitoring-with-victoriametrics/

Browse Source 
Follow-up c0246b2e17
This commit is contained in:
Aliaksandr Valialkin 2023-09-05 17:03:21 +02:00
parent 696f143eb5
commit a0c4095ec9
No known key found for this signature in database
GPG Key ID: A72BEC6CD3D0DED1
1 changed files with 1 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/CaseStudies.md
View File

@ -336,36 +336,7 @@ Numbers:
[Grammarly](https://www.grammarly.com/) provides digital writing assistant that helps 30 million people and 30 thousand teams write more clearly and effectively every day. In building a product that scales across multiple platforms and devices, Grammarly works to empower users whenever and wherever they communicate. [Grammarly](https://www.grammarly.com/) provides digital writing assistant that helps 30 million people and 30 thousand teams write more clearly and effectively every day. In building a product that scales across multiple platforms and devices, Grammarly works to empower users whenever and wherever they communicate.
> Maintenance and scaling for our previous on-premise monitoring system was hard and required a lot of effort from our side. The previous system was not optimized for storing frequently changing metrics (moderate [churn rate](https://docs.victoriametrics.com/FAQ.html#what-is-high-churn-rate) was a concern). The costs of the previous solution were not optimal. See [this blogpost on how Grammarly reduces costs and maintenance burden for their observability solution by 10x after switching to VistoriaMetrics](https://www.grammarly.com/blog/engineering/monitoring-with-victoriametrics/).
> We evaluated various cloud-based and on-premise monitoring solutions: Sumo Logic, DataDog, SignalFX, Amazon CloudWatch, Prometheus, M3DB, Thanos, Graphite, etc. PoC results were sufficient for us to move forward with VictoriaMetrics due to the following reasons:
- High performance
- Support for Graphite and OpenMetrics data ingestion types
- Good documentation and easy bootstrap
- Responsiveness of VictoriaMetrics support team during research and afterward
> Switching from our previous on-premise monitoring system to VictoriaMetrics allowed reducing infrastructure costs by an order of magnitude while improving DevOps experience and developer experience.
Numbers:
- [Cluster version](https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html) of VictoriaMetrics
- Active time series: 35M
- Ingestion rate: 950K new samples per second
- Total number of datapoints: 44 trillions
- Churn rate: 27M new time series per day
- Data size on disk: 23 TB
- Index size on disk: 700 GB
- The average datapoint size on disk: 0.5 bytes
- Query rate:
- `/api/v1/query_range`: 350 queries per second
- `/api/v1/query`: 24 queries per second
- Query duration:
- 99th percentile: 500 milliseconds
- 90th percentile: 70 milliseconds
- median: 2 milliseconds
- CPU usage: 12 CPU cores
- RAM usage: 250 GB
## Groove X ## Groove X