2022-05-31 监控系统选型
监控系统选型
在 nash 的业务内，监控系统的目的是：
- 及时获取物理机器的信息
- 快速配置业务监控的需求
- 自动化的响应底层物理机器快速变动的场景
- 多个网络子段互相隔离
目的详解
及时获取物理机器的信息
没有压力，大部分监控系统都可以做到。
快速配置业务监控的需求
可以从两个角度去考虑：
- 业务监控需求的实现
- 业务监控和节点进行绑定
前者可以是脚本触发，或 metrics 暴露，从而获得数据。后者需要一个中间调度平台去实现，通过中间件人为的对业务和节点进行绑定。需要注意的是，多个业务可以对应单个节点。
自动化的响应底层物理机器快速变动的场景
这是比较难做到的。这和第四点需要的技术有关联。一般来说，对于监控中心来说，会有两种模式：
- pull：集中化配置，由主节点主动的获取数据
- push：分布式配置，由被监控节点主动上报数据
两者没有绝对的好与坏，得看场景，在不需要考虑网络隔离/网络不可达的情况下，pull 模式更好，自动化的模式更容易做；而出现了网络隔离/网络不可达，或集群内节点过多，则会用到 push 模式，对于监控中心来说是相对被动的。
当然也有折中的方案，例如 zabbix server + zabbix proxy。对于 zabbix server 来说是 push 模式，被动的接受 zabbix proxy 推送数据，但对于 zabbix proxy 来说可以是 pull 模式，集中化配置。
在初期还是先考虑手动响应物理机器的快速变动，通过中间平台确认下架机器，上架机器。
一个方案就是机器上架后运行脚本，告诉中间件，然后开始进行监控部署。下架在另一个接口实现。
多个网络子段互相隔离
多个网段的隔离在没有足够好的管理平台下，无论做什么都是比较麻烦的，这里先不去考虑这个问题怎么处理，直接使用 push /部分 push 的方案。
选择
市场上能够直接实现上述四个目的的系统，应该是不存在的。
- Prometheus：不通过，一个根本的原因就是网络问题，该系统只支持 pull 模式，它更适合云平台，网络互通情况。
- zabbix：可以使用，但需要中间件和它的 api 进行优化，但这是单点系统，需要考虑负载问题。
- Open-Falcon：不推荐使用，停更四年，二开成本不低，架构复杂
- cat：美团的监控系统，已开源。美团的技术是可以信任的，这个项目的热度也挺高的，还在维护中，接入公司比较多，可以考虑。但需要机器去验证适不适合nash的环境。