数据采集

先来聊数据的源头,看官可能觉得不就是个agent么,搞好cpu、mem等基础指标的采集,上报上来不就好了,其实不然
首先,作为agent,一个最大的特点就是离中心太远了,远到无法很好的控制它。
尤其前期,不断的更新、迭代、修bug,当你有几十几百台机器时,都不是问题,什么ssh、ansible分分钟就搞定了。
但当你的规模成千上万的时候,就会发现,版本迭代是在是太痛苦了。
而且数量不是唯一的问题,例如你的上报中心地址变了,有网络分区了,有各种各样恶心的场景。

所以agent最应优先考虑的应该是

  • 如何方便的升级、灰度
  • 如何尽可能少的变动二进制

因此,一个中心式的配置是很有必要的。

其次,作为监控开发者,你永远考虑不到SRE同学会对你认为最最简单的基础指标有着什么样的需求(即使我是SRE出身^_^)
例如,我们觉得对于内存的指标,total、free、buffer、cached、swapd已经足够了,但仍有需求要监控SReclaimable、Slab、Shmem等指标
如何快速的满足这些需求,就成为了另一个问题。
又不可能把所有/proc下的东西都上报,相信我,总有你意想不到的。
因此,一个可动态增加上报指标的agent设计还是很有必要的。

最后,作为数据的来源,准确性与完整的自监控也是非常重要的。
例如,我曾遇到这样的case,用户反馈其某个机器的cpu.idle不准,我在目标的机器上追查好久也没有找到原因。
最后是在中心通过抓包的方式,发现有2个IP,使用相同的主机名在上报数据。
根本原因是,我们的agent使用了golang的os.Hostname()来获取主机名,而root用户可以轻易的通过hostname命令来修改主机名,进而影响我们的agent结果。

再例如我给falcon官方使用的nux包提的 inode free在一些文件系统上计算错误的PR
所以,一些涉及边界值的防御性编码,也是非常重要的。

仍然是数据采集

上一段的数据采集,是死采集。而这里要说的,是活采集。
何谓活采集,用户上报的,即为活采集。
丑陋是这种采集最大的特点,因为自定义采集一旦学会了,往往就是不过脑式的上报,这里没有黑这些自定义上报者的意思。
例如,我司有非常多的同学,将http的path作为measurement或者tag上报,在这个restful满天飞的时代,我们的监控系统会发现各种各样有趣的指标:
md5的、sha1的、订单号的、公网盲扫进来的sql语句的、xxx.asp的(你说我们用世界上最好的语言写就的页面,你扫asp,这是在侮辱我们么^_^)
所以,如何过滤脏数据的上报,就是自定义数据最大的问题所在。

白名单

一个非常极端但也非常有效的做法就是,自定义上报,一律使用白名单的方式。
非白名单者,一律拦截在采集层,不再流向更远的数据链路。

quota

而友好一些的方式,则是提供quota机制,例如节点+主机层面,限制多少个指标上报,节点+主机+指标层面,限制多少个tagk,一个tagk下面最多又允许多少个tagv。
quota做好了,对系统将是大有裨益的。

数据上报

在falcon里面,agent的上报,是直接push给transfer的,而我司则采用在中间加一层消息队列的方式
当然利弊都有,削峰解耦的同时,也需要多维护一个组件

-EOF-