一、目前业务打点现状以及痛点

• 大量额外的定制化开发工作量
  • 根据大屏展示的内容，很多展示的业务数据需要定制化开发，开发过程中需要大量的接口协议规范制定、开发、联调、上线部署、沟通协调等工作。
• 代码侵入
  • 定制化开发的代码会对应用程序原本的业务逻辑造成影响，进而影响应用的可用性和健壮性。
• 与业务代码耦合性强
  • 如果业务代码逻辑变更则大屏相关代码也需要跟着变更。一个需求影响两条业务线，对开发和联调，部署都带来巨大挑战。
• 后期的维护工作量大
  • 大量定制化的接口规范，在不同团队之间不尽相同，随着后续大屏展示逻辑的不断变化，会为各个团队带来巨大的后期维护工作。

二、如何解决痛点
设计思想

• 统一业务数据采集规范
  • 必要性：
    • 面对不同团队，不同业务，不同接口，巨大的设计开发成本，我们十分需要设计一个统一的业务数据采集规范。
  • 规范特点：
    • 规范必须具有良好的通用性，扩展性。
    • 便于理解和解析，轻量，易于传输等特点。
• 统一数据结构：
  • 我们采用一种类似json数据结构 {业务指标{标签key1=“标签value1”,标签key2=“标签value2”,………………} } 业务指标value
  • 类如：jvm_threads_states_threads{application="cloud-gateway-service-demo-2-0-3",state="runnable",} 14.0
  • 基于这种设计我们可以给一个业务指标设置任意多个维度的标签，然后再基于维度标签做任何想要的聚合计算即可得到一个业务指标数据。
• 业务代码零侵入
  • 基于统一业务数据采集规范我们设计了基于spring 注解的方式来实现代码零入侵，加上注解可以采集业务数据，去掉注解业务代码还是原来的样子，完全没有影响业务代码的逻辑。
• 与业务代码解耦
  • 提供接入SDK ：
    • 我们既然有统一的统一业务数据采集规范，那就很容易将这个规范抽象出来，业务指标的设置、解析、聚合汇总可以统一实现成一个SDK，来实现业务代码与打点代码的解耦。
  • 数据采集解耦：
    • 业务开发人员只需要简单的集成一下SDK，设置采集的指标即可完成业务数据的采集。
  • 数据处理解耦：
    • 数据处理我们完全可以托管给数据收集层，由数据收集层提供数据存储，数据集合函数，API接口各种能力，完美的解决统一数据处理的问题。
• 灵活易扩展的架构
  • 架构分层：
    • 我们将整个架构分为三层，业务数据层、数据收集存储层，展示层。每一层都可以进行分布式集群部署来实现易扩展的能力。
  • 统一SDK以及扩展：
    • 有了统一的SDK的，我们可以轻松应对后续业务数据采集需求的变化，我们无需改动业务逻辑代码，只需要升级一下SDK的版本即可。完全遵守了开闭原则。
    • 如果业务有特殊的采集需求，也可以基于SDK提供的接口来进行采集指标的个性化实现。
  • 展示层：
    • 展示层我们可以灵活选用开源方案或者自定义展示UI，数据源我们直接调用数据收集层提供的http API 即可。

架构选型

• 为什么选择prometheus
  • 从开发语言上看：
    • 为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到Go。不得不说，Go凭借简洁的语法和优雅的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。
  • 从系统成熟度上看：
    • Zabbix和Nagios都是老牌的监控系统：Nagios是在1999年出现的，Zabbix是在1998年出现的，系统功能比较稳定，成熟度较高。而Prometheus和Open
  • 从系统扩展性方面看：
    • Zabbix和Open-Falcon都可以自定义各种监控脚本，并且Zabbix不仅可以做到主动推送，还可以做到被动拉取，Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。
  • 从数据存储方面来看：
    • Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能，Nagios和Open-Falcon都采用RDD数据存储，Open-Falcon还加入了一致性hash算法分片数据，并且可以对接到OpenTSDB，而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储；
  • 从配置复杂度上看：
    • Prometheus只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，尤其是Open-Falcon。
  • 从社区活跃度上看：
    • 目前Zabbix和Nagios的社区活跃度比较低，尤其是Nagios，Open-Falcon虽然也比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势，社区活跃度最高，并且受到CNCF的支持，后期的发展值得期待；
  • 从容器支持角度看：
    • 由于Zabbix和Nagios出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。Open-Falcon虽然提供了容器的监控，但支持力度有限。Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。而Nagios则在网络监控方面有广泛应用，伴随着容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。
  • 总体来说，对比各种监控系统的优劣，Prometheus可以说是目前监控领域最锋利的“瑞士军刀”了。
• prometheus 是什么

  • prometheus 工作原理图

    
    
    architecture.png
• prometheus组件介绍
  • Retrieval：
    • 定义了 Prometheus Server 需要从哪些地方拉取数据
  • Jobs / Exporters：
    • Prometheus 可以从 Jobs 或 Exporters 中拉取监控数据。Exporter 以 Web API 的形式对外暴露数据采集接口。
  • Prometheus Server：
    • Prometheus 还可以从其他的 Prometheus Server 中拉取数据。
  • Pushgateway：
    • 对于一些以临时性 Job 运行的组件，Prometheus 可能还没有来得及从中 pull 监控数据的情况下，这些 Job 已经结束了，Job 运行时可以在运行时将监控数据推送到 Pushgateway 中，Prometheus 从 Pushgateway 中拉取数据，防止监控数据丢失
  • Service：
    • 指 Prometheus 可以动态的发现一些服务，拉取数据进行监控，如从DNS，Kubernetes，Consul 中发现
  • Storage：
    • 即 Prometheus 的存储，利用 Prometheus Server 的本地存储。
  • PromQL：
    • Prometheus 的查询语句，利用 PromQL 可以和一些 WEBUI (如 Grafana )集成
  • AlertManager：
    • 一个独立于 Prometheus 的外部组件，用于监控系统的告警，通过配置文件可以配置一些告警规则，Prometheus 会把告警推送到 AlertManager。
• prometheus metrics主要类型
  • Gauges

    • 表示搜集的数据是一个瞬时的，与时间没有关系，可以任意变高变低，往往可以用来记录内存使用率、磁盘使用率等。表达一个瞬时的状态。

      
      
      image2022-3-30_23-36-5.png
  • Counter
    • 计数器。只允许重置或者增加。我们往往用它记录服务请求总量，错误总数等。例如 Prometheus server 中 http_requests_total, 表示 Prometheus 处理的 http 请求总数，我们可以使用data, 很容易得到任意区间数据的增量
  • Histogram
    • 采样观测值，可进行分位计算和数据聚合，计算在server端完成。一个名为<basename>的metric，其histogram有3个固定的时间序列:
    • <basename>_bucket 不同bucket下的观测值的累加数量
    • <basename>_sum 观测值的总和
    • <basename>_count 观测值的数量
    • 例如可以计算一个请求的耗时分布，95线、99线等
  • Summary
    • 与Histogram类似，只是Summary直接存储了quantile的值

grafana介绍

• grafana官方网站
• grafana是什么：
  • grafana是开源的、炫酷的可视化监控、分析利器，无论您的数据在哪里，或者它所处的数据库是什么类型，您都可以将它与Grafana精美地结合在一起。它还有丰富的套件供您选择，目前，它已拥有54个数据源，50个面板，17个应用程序和1732个仪表盘。grafana社区活跃，目前使用grafana的公司有很多，如paypal、ebay、intel、腾讯等。
• 七大特点
  • 可视化：
    • 快速和灵活的客户端图形具有多种选项。面板插件为许多不同的方式可视化指标和日志。
  • 报警：
    • 可视化地为最重要的指标定义警报规则。Grafana将持续评估它们，并发送通知。
  • 通知：
    • 警报更改状态时，它会发出通知。接收电子邮件通知。
  • 动态仪表盘：
    • 使用模板变量创建动态和可重用的仪表板，这些模板变量作为下拉菜单出现在仪表板顶部。
  • 混合数据源：
    • 在同一个图中混合不同的数据源!可以根据每个查询指定数据源。这甚至适用于自定义数据源。
  • 注释：
    • 注释来自不同数据源图表。将鼠标悬停在事件上可以显示完整的事件元数据和标记。
  • 过滤器：
    • 过滤器允许您动态创建新的键/值过滤器，这些过滤器将自动应用于使用该数据源的所有查询。

架构体系

• 架构总览

架构图.png