VictoriaMetrics, Thanos, Cortex，或者其他的， Metrics 方案你们都用的是哪个？

[annoygaga]

续问https://www.v2ex.com/t/1066955?p=1#reply9

可能之前时间不讨喜

目前需要调研 Prometheus 的存储扩展，需求是降低数据量大了之后的运维压力

目前团队瓶颈主要在运维，prometheus 是给一群寻模型的同学使用，他们使用普遍乱来，而且组非常多（有对外的），所以可能会忽然来非常多数据（或者 label 非常多）

于是想要看看 prometheus 的扩展

目前服务部署在 k8s 上，目的是希望

• 存储可以扩展（主要是存储，经验上会忽然扩一大波）

• 运维压力尽可能的小 (一个人 parttime 也能 hold 住）

想问问各位的意见

目前倾向于 VictoriaMetrics ，原因是看到用的公司日益增多

[GopherDaily]

1. Prometheus 估计还是最成熟，最方便的方案
2. 优化&&限制下的话，支持个 3 千 c 的集群应该问题不大
3. 建议谁负责，谁觉得，特别是你们看山区都不了解的情况下
4. 云上存储扩容应该都支持吧

[wandehul]

VictoriaMetrics thanos 纯粹是持久化数据。

[helenfrank]

VictoriaMetrics, 我之前用来上位替换 prometheus 的, 可以看看小红书技术团队之类的设计方案, 他们也都用 VictoriaMetrics 了, 还可以保留部分集群的 prometheus, 平滑迁移.

目前看了 vmagent, vmalert 的代码, 确实在很多设计和细节上相较于 prometheus 在性能和高可用方面更好, 并且基本兼容原有的 prometheus 配置文件, 支持 prometheus 协议.

Prometheus 经常出现的问题就是一个集群节点数较多, 一个节点的 cpu 和内存都分配给它使用了, 还是不够, 经常 oomkill, 调存储时间之类的也不是个长久的办法, 并且费运维. 用 VictoriaMetrics 之后, 运维只需要关心全局集群的 VictoriaMetrics 了.

可能要关注的点是 vmstorage 的存储消耗(所有集群的数据都收集在一起了), 但不用在每个集群上都部署一个 prometheus 了, 总的消耗是更小了. vmagent 基本上给个 2 核 4G 就够了

一点经验, 仅供参考

[helenfrank]

顺带一提, vm 已经上到生产环境了(集群 150 以内, node 3000 以内, pod 100000 以内), 给 vmstorage 目前分配的存储是 2T, 有个计算公式的, 你可以找找

[annoygaga]

@GopherDaily
你指的是 promethues 单机（或者说 promethues operator ），撑 3k 的集群吗？

[annoygaga]

@wandehul 其实最想要的就是数据的可扩展，查询速度慢一点倒是可以接受，而且最好有一些租户隔离，谁知道哪个同学会怎么瞎搞

[annoygaga]

@helenfrank 是的，我也是看用的人多
计算公式有链接吗？我 google 貌似没找到
以及我这边用法有非常多异步 job （也就是 pushgateway 的用法，不知道会不会有什么影响不）

[helenfrank]

@annoygaga #7 参考他们弄的吧 https://docs.daocloud.io/insight/best-practice/vmstorage-resource-plan

[annoygaga]

@helenfrank 感谢🙏

[annoygaga]

想了解了解各个公司怎么做的

[annoygaga]

别只收藏呀，有没有过来人给点建议

[povsister]

https://www.bilibili.com/read/cv36843255

[annoygaga]

@povsister 感谢

[RedisMasterNode]

https://victoriametrics.com/case-studies/

[cloudfly]

用 Victoria Metrics 搞了两年，正经不错，最近写了个手册 https://victoriametrics.com.cn/docs

希望有帮助