基于Prometheus生态的集群化监控指标收集应用系统
1. 技术背景
随着云计算和微服务等技术的兴起，企业应用日趋集群化和复杂化：服务应用不在是一个一个的“信息孤岛”，而是相互依赖和调用，形成应用群。复杂的服务应用依赖关系带来强大的技术红利的同时，也带来了性能监控上的挑战，微服务架构下，服务按照不同的维度进行拆分，一次请求请求往往需要涉及到多个服务。尤其是大规模互联网应用，服务由不同的团队开发，用不同编程语言来实现、并部署在成千上万态几千台服务器上面。因此需要高可用、高性能、可伸缩的指标收集技术方案来采集海量的指标数据，以支持发生故障的时候，能够快速定位和解决问题。
2. Prometheus生态
Prometheus 是一套开源的系统监控报警框架。作为新一代的云原生监控系统，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型，是当前使用最为广泛的开源指标收集和监控的解决方案。
Prometheus 生态圈中包含了多个组件，其中最重要的组件包括：
- Prometheus Server: 负责指标数据的分析、计算和存储；
- Push Gateway: 推送网管，负责指标数据的收集，服务层面的指标可以直接向Push Gateway推送他们的指标数据， Prometheus server定时从Push Gateway拉取最新的指标数据；
- Alert manager: 告警管理服务，当 Prometheus server 发现指标异常需要告警时，会将告警数据推送给Alertmanager，其会进行去除重复数据，分组，并发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。
架构图如下：
image.png
3. Prometheus Server痛点
原生的解决方案中，Prometheus Server为单点服务，没有集群化的概念，存在高可用性和可扩展性上的不足：
- 由于Prometheus Server 单点服务的设计，全部请求都会集中在一台服务器上，如果请求过高或者出现故障，整个监控服务就会中断，存在故障不能及时恢复的风险；
- Prometheus 因为没有集群化的概念，是无法灵活的横向扩容，只能通过增加单点物理机的性能来对抗高流量请求；
- Prometheus Server 虽然可以监控多个 Push Gateway的数据，但是如果同一个指标分组同时存在于多个Push Gateway上但是指标值不同，Prometheus Server 会随机获取指标值，这样的限制导致无法使用Nginx等常见的代理服务来达到负载均衡的效果；
4. 重点内容
为了弥补Prometheus单点服务的设计上缺陷，本文通过将指标希散列调度和主备机流量切换等方法相结合，实现了指标收集服务的集群化方案，从而保证监控指标收集服务达到高可用、高性能和可扩展的使用目标。
4.1 指标散列调度
为了提高指标收集服务的高性能问题，本方案采用指标散列调度的方法，具体过程如下：
- 每种指标都有特定的标签组，监控服务根据不同的标签组来区分和计算不同的监控指标；
- 在收集指标数据的过程中，指标调度服务根据监控的标签组计算其唯一的散列值;
- 所有可用的Push Gateway服务地址被放入散列表中；
- 指标调度服务根据指标计算出的散列值推送到散列表中对应服务器地址；
image.png
依赖散列值唯一且均匀分布特性，指标调度服务通过散列码保证push gateway是负载均衡的，数据流量被分散到多个服务器且没有重复数据，既保证集群化高可用的同时又不会影响数据正确性；
4.2 主备服务器流量切换
为了解决指标收集服务高可用的问题，本方案采用主备服务器流量切换的方法，具体过程如下：
- 划分主备服务器，正常情况下业务流量只会推送到主服务器上；
- 服务增加push gateway定时探活机制；
- 如果发现有主服务器不可用，则启动主备切换，将业务数据流量切换到备用服务器上，备用服务器角色转化为主服务器；
- 发生故障的服务器在恢复后重新上线，以备用服务的角色重新加入服务集群，不立刻承担业务流量，避免对于业务的二次伤害；
image.png
由于主备服务器机制的存在，保证故障发生时服务不会中断，集群中只要还有一个服务器在正常工作，整个监控服务就不会收到影响，大大提高鲁棒性。
4.3 可伸缩性部署
从业务角度出发，监控数据的流量可能随时变化，监控服务集群也需要随之扩容或者缩容。 上面提到散列调度和主备服务策略可以结合使用，实现集群动态伸缩的效果。
以扩过程为例，流程如下：
- 动态伸缩服务模块，定时探测流量；
- 如果发现流量过高，可以将备用服务器池中服务器变为主服务角色，扩容到散列表中；
- 指标调度服务发现有散列表容量变化，重新生成指标散列码，让指标的目标服务器变化，并删除历史记录；
与之类似，缩容过程为：
- 动态伸缩服务模块，定时探测流量；
- 如果发现流量过地，可以将主服务池中服务器变为备用服务角色，并在散列表中删除；
- 指标调度服务发现有散列表容量变化，重新生成指标散列码，让指标的目标服务器变化，并删除历史记录；
需要注意的是，无论是主服务器和是备用服务器，都要定时探活服务的探活范围内，避免将有故障的备用机扩容上线。
通过以上方法，指标调度散列表的大小与可用主服务器的个数保持一致，如果集群要动态增加和减少服务器数量，散列表也会随之变化，保证指标只会推送到固定的服务器上，而不需要修改业务逻辑或者重启服务。
image.png
5. 增益效果
本方案通过将指标希散列调度和主备机流量切换等方法应用到指标收集服务中，在高可用、高性能和可扩展的等方面对于指标收集系统进行增强。
- 通过指标散列调度，利用散列值均匀分布原理，保证push gateway是负载均衡的，数据流量被分散到多个服务器且没有重复数据，既保证集群化高可用的同时又不会影响数据正确性；
- 通过主备服务器机制，保证故障发生时服务不会中断，集群中只要还有一个服务器在正常工作，整个监控服务就不会收到影响，大大提高鲁棒性;
- 以上两种方案可以相互结合，散列表的大小与集群服务器的个数保持一致，如果集群要动态增加和减少服务器数量，散列表也会随之变化，保证指标只会推送到固定的服务器上，而不需要修改业务逻辑或者重启服务，实现根据业务需求的弹性伸缩。
附录 标签分组示例
| 标签分组 | 指标值 |
|---|---|
| app="test-app" appInstance="test-app-instance" application="is-alarm" endpoint="test-app/webjars/springfox-swagger-ui/fonts/open-sans-v15-latin-700.woff2" instance="" job="is-alarm" metricName="endpoint_avg" type="接口（endpoint)" | 13 |
| app="test-app" appInstance="f038db1460b34a54bddb613f5fa7ced1@192.18.0.14" application="is-alarm" instance="" job="is-alarm" metricName="instance_jvm_memory_heap_max" type="虚拟机（jvm)" | 2092433408 |
| app="test-app" appInstance="test-app-instance" application="is-alarm" endpoint="/api/v1/data/searchDetail" instance="" job="is-alarm" metricName="endpoint_failed_times" type="接口（endpoint)" | 0 |
散列值计算方法：
- 去标签分组中的标签键值对，按照字母顺序排序；
- 排序后的键值对以字符串形式连接在一起，进行Base64编码；
- 根据步骤2中得出的字符串，计算得到MD5消息摘要；
- 取MD5信息摘要的哈希值，对散列表的大小取模，得到散列值；
