snmp采集
其实我很乐意用promdb的方式来保存数据，为什么呢？
gossip的方式，所有的指标自己算(比如网卡进出流量速率)，所有的逻辑自己写在代码里面（比如计算cpu,mem使用率)，碰到一些特别的指标（比如nas的特别指标，它在mib结构上与一般交换机完全不同，采集的重点也不同），在gossip中就只能自己增加新的代码逻辑( if xxx yyy)，如果下次再采集个ac或者其它，那么就只能继续增加代码，长此以往，这必然会变得很丑陋。
而用promdb存，再用promql的方式去做二次查询，甚至实现所谓的streaming calculate(计算字段)， 会让许多事情变得简单，并且职责明确，元数据，计算数据，告警，等等，可以说promtheus+snmp_exporter+alertmanager给我们开了一个好头，唯一不爽的就是snmp_exporter的配置文件比较麻烦，但这个也可以通过修改代码来增强
相信做过类似事情的同行应该也会有一样的感觉， 分段式的采集与生成指标会让整体逻辑变得条理有序，更容易应对不同采集目标的策略变化情况
顺便回顾下我们的监控系统架构变化
一开始我们用的ES，因为它似乎是全能的， 既能保存时序数据，又能保存日志数据，同时不需要预定义表（结构化数据库必须有建表过程，而我们做业务的时候，尤其是做日志数据处理的时候往往很难预设有哪些字段），但是用过一段时间后我们发现用ES有很多难受的地方。
1. 资源消耗
在上规模的用户场景里，ES需要占用大量的资源，统计过几乎要占用80-90%的硬件资源，也就是其它组件加起来也只是占用了个零头，而ES就是个庞然大物。许多时候向潜大客户介绍硬件规模时，ES的这一点都让客户惊诧。
2. 性能与稳定性
与上一点相关，在高负载场景下ES的性能也有问题，常常会出现查询响应缓慢现象，另外大规模集群中经常会有一些节点异常掉群，为了恢复不得不做一些运维动作，另外最可怕的是因为一些查询语法或者相关情况导致的集群僵死，甚至于直接挂掉(OOM)，每次这样的情况都会花费大量的时间处理。
- 使用复杂
其实这一点相对还好，但是ES语法导致它写的东西需要进行一定的翻译，相对来说代码的易维护性就比较差了
寻找替代者
所以2020年后我们开始寻找一些ES的替代方案，研究了clickhouse与promtheus, 首先在时序数据这块，我们选择了promtheus，它有几个好处
-
时序数据库，之前许多业务中的查询，它提供了出厂自带的API
-
相对比较好的性能与资源消耗
promdb是专门的时序数据库，天然适合做数值运算统计，在资源消耗与性能上都比较理想
- 日志
关于日志，虽然一开始调研了clickhouse，但是之后我们也没有再遇到那种每天1亿日志的客户，尽管看起来clickhouse的性能要比ES强10倍，存储消耗也只有ES的1/10甚至更低，但是没有机会做详细验证。（感觉很多地方在用CH，只是这个东西有一些上手难度，而我们没有人力来做这件事，比较遗憾）
不过CH有一点是需要注意的，在大规模场景下，它比较吃CPU，管理不好这一点，会让整个系统有性能问题。
参考链接
接下来我们计划研究下VictoriaMetrics和VictoriaLogs, 以及greptimeDB, apache doris，另外 CH？
关于VM来源的介绍
VM内部关于VL的测试数据
