对于监控选型的一些思考

  • 监控的选型:

1.首先是拉模式(例如prometheus)和推模式:

拉可以随意控制拉取频率和指标,可大可小,推的话收集者可以下发改变推频率的指令,实现比较麻烦;拉失败快速知道客户端节点agent监控异常,推的话只能看哪个节点没上报比较麻烦;

拉模式下客户端agent只需要读取数据放到指定地方即可,不管发送,避免像推一样推失败导致进程整体退出;拉模式需要知道从哪拉,可以借助k8s实现,推模式需要知道往哪推,需要通过watch长连接监听注册的接收者节点的状态(如果不监听,agent推送数据失败没问题,就重新选择一个接收点推送,并随机一段时间后重新从注册中心拉取数据,但是接收节点添加新节点了呢,能不能手动关掉接收点,让他们重新拉取,或者给所有点发一个重新拉取的命令);

节点比较多的时候,拉模式需要进行分片比较难做,负载均衡的任务在收集者(哪个收集器去拉哪几个客户端agent),推模式下客户端agent做负载均衡,实现更容易;拉模式是时间触发,推模式可以做到事件触发,更灵活;

2. 对于注册中心的选择到底是ETCD还是DNS域名:

DNS 服务发现ip,添加ip是比较容易的,但是下掉ip是没有相应的事件驱动的,只能适用于小量的服务请求,因为客户端不知道哪个ip坏掉了,但是又不能放弃这个坏掉的ip(万一已经好了呢);还有个问题,每次请求域名都是走DNS吗,会不会走缓存,如果走缓存,添加了节点多久更新一次呢?(DNS缓存失败的怎么容灾)究其根本,域名是有缓存的,并且不能像注册中心那样主动推送事件,只能失败重试。

对于监控来说,流行的是prometheus是agent起端口然后拉的模式,这样的好处呢,一个不用维护长连接的问题,每次短连接并不影响容器的性能,拉不通能够瞬间感知,但是同样也有问题,怎么做分片,实现多机器节点任务分发,首先monitor节点会做list/watch所有IP,接下来解决就是分片,哪台机器拉取那一片(可以通过取余数解决),可以每台机器占有一个片,然后占有的片去执行任务,执行完后再去占有下一片。但是又有个问题,机器占有这一片之后挂了呢,可以让agent保有未拉取的片,然后等待下一次一起拉取出来。那分片不均等的问题怎么解决呢,分片不均等是存在的,这也是一种权衡吧,可以加大片的数量,但是对于监控场景来说是接受的

Promethus更偏向于优先export的扩展,因为pull的模式下agent没有必要知道往哪个地方发送数据

pull 和 push 最大的区别在于 单条连接的复用程度 。pull 需要知道从哪里pull,push需要知道往哪里push,因此需要注册中心来记录。pull 可以通过注册中心来 做,promethus通过list/watch k8s的相关数据,push的话可以通过DNS来解决,也可以通过自行注册的方式;