• 监控的选型：

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来解决，也可以通过自行注册的方式；