监控系统评估

监控对于任何一个互联网产品是重中之重。无论你是ToB的产品，还是ToC的产品，监控永远是一个必须项。没有监控的产品那不就跟裸奔一样。

那我们如何来评估一个监控产品呢？以下是按照一个完整的监控系统去评估的，对于有些单机部署的产品，那我们完全可以舍弃其中一些指标，从来选择各适合自己产品线的监控系统。

在OOP里我们一般使用4个指标来度量。

1. 耦合性
2. 内聚性
3. 充分性
4. 完整性

那监控系统是否也可以按照这些指标呢？

1. 耦合性： 这个应该是衡量的一个指标，如果一个监控系统对于现有系统侵入性太高，那必然会增加集成难度，易用性也会大打折扣，带来的结果就是无法广泛使用。
2. 完整性：这个是任何一个监控系统的基本要求了。要是监控的内容都不完整，那这个监控系统也可以跳过不用了。但是现在随着各个系统越来越复杂，所以为了保证完整性，一般现在的监控系统都会有主动上报和接收上报的功能。
   1. 主动上报：这些就是跟硬件和操作系统相关的监控项的上报。还有一些标准中间件的上报。
   2. 接收上报：提供api接口或者其他方式来接收其他程序推送过来的监控内容。这里当然要支持不同的metric类型，比如Counter，Gauge等等这种类型
   3. 容器接收：是否能够接收容器内上报的相关指标
3. 充分性：针对监控系统来说，也就是可靠性。不能监控项已经宕机很久了，但是监控内容还是正常，或者明明已经宕机了，但是却无法展示出来。这个之前有碰到过有公司设计的数据报警就是这样的，都是从本机发起的监控，这种一旦自己网络有问题，要么自己没发现，要么自己发现了但是也无法推送出来。导致监控失效。
4. 内聚性：通俗的说就是只是包含监控，不包含其他的。那这个因为是产品级别了，所以大部分问题都不大。这里可能就涉及到监控系统内部各个服务的评估是否符合内聚性。

除了以上几点，对于监控产品我觉得还有3个特性需要考量。

1. 可扩展性：如果你使用早期zabbix,你就明白zabbix很依赖MySQL,特别是监控历史都放在一张表里，导致这个查询是相当的慢，于是后来大家都会魔改这块代码。而prometheus的问题虽然是有联邦模式，但是一般一个集群内部都是就一个server,这样导致server的压力会非常大。而这块victoria metrics却很好的解决了。
2. 经济性：存储1B数据的单价，从1B数据中获得需要的数据的单价。还有就是历史数据的保存颗粒度，有些监控系统是可以自定义的。比如有些系统需要保留5年的数据，但是2年以上的颗粒短是否还需要1s这种去保存，还是1m或者15m就可以了。这样合并后就会大大降低存储的容量。降低了整体成本。
3. 颗粒度：最小的监控时间颗粒度是多少，1s还是1ms这种，之前在cuda计算的一些场景，有些研究员就需要1ms的数据。

其实以上这些在我们选择各种中间件的时候也可以套入进去进行考量。