1. 背景

​ 随着互联网技术的发展与普及，互联网应用在我们的日常生活中所占的比重逐渐增加，改善了我们的生活质量降低了我们的生活成本同时让我们的生活更加的便利。

​ 但对于互联网企业而言响应客户需求的应用程序也日益复杂，功能模块也越来越多。并且对于企业级应用项目我们追求系统的高可用高并发高性能，那么我们应用系统的复杂度会更高，随之而来的是运维成本以及运维人员的能力也越来越高。

​ 特别是在从单体应用过渡到微服务应用后微服务中功能拆分的粒度更细、各服务独立部署并且部署的服务更多、服务独立维护、服务治理能力要求高，系统的复杂度也更高，对于用户的服务请求响应的链路也越长，业务数据流向与中转更复杂。特别是不同应用之的互相调用的问题排查更加困难。同时微服务存在固有复杂度。

​ 如果应用出现异常，那么我应该如何快速定位并解决问题？在平时我们如何实时查看系统应用的健康状态？在问题发生前如何提前预知避免程序错误？对于复杂应用如果没有强大的监控能力，应用一旦出现问题，如果不能快速发现系统的问题，对于业务来说是一场灾难。

2. 现状

​ 在我们传统的应用维护与运维过程中，通常是应用出现错误之后再来由运维人员或程序人员采取相应的补救措施，并且响应问题的速度也可能相对低效。随着系统复杂度的增加对运维成本和运维人员的能力要求更高，日常服务巡检工作量大且繁琐。通常有这样几个问题：

• 运行维护人员被动、低效
• 缺乏有效的IT运维机制
• 缺乏有效的IT运维工具

3. 方案

​ 我们如何将运维可视化？如何对服务应用进行业务监控、应用监控、操作系统监控、硬件资源监控？从而降低我们的应用维护与运维成本，提高问题的响应速度。

​ 服务监控的本身是需要系统应用相关的数据支撑的，通过对数据的分析和计算，得到数据背后产生的行为和状态，根据行为和状态分析程序系统是否运行良好。将得到的数据信息进行可视化，更直观的了解我们应用系统的健康状态。

3.1 监控方案

• mrtg：通过snmp协议得到设备的流量信息，并以包含PNG格式的图形的HTML文档方式显示给用户
• cacti（仙人掌）：通过snmp服务获取数据，使用rrdtool存储和更新
• ntop
• nagios：夸平台，插件多，告警功能强大
• centreon：底层使用nagios，是nagios整合版软件
• ganglia：设计用于测量数以千计的节点，资源消耗小
• Open-Falcon ：小米开源的企业级监控工具
• zabbix：跨平台，支持图形化，多规则告警，提供多种API接口，使用广泛。由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘
• prometheus：基于时间序列数据存储的容器监控解决方案

3.2 prometheus

3.2.1 简介

​ Prometheus是一个最初在SoundCloud上构建的监控系统。在2012年成为社区开源项目，拥有非常活跃的开发人员和用户社区。Prometheus于2016年加入云原生计算基金会（FNCF），成为继Kubernetes之后的第二个托管项目，prometheus成为新一代云原生监控系统

3.2.2 Prometheus架构

​ prometheus是一个时间序列数据库，在此基础上提供数据收集分析与告警功能。相同的 metrics(指标名称) 和 label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。

从左到右，可分为采集层，存储计算层，应用层

• 存储计算层：

  • Prometheus Server：包含了存储引擎和计算引擎。Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
  • Retrieval：取数组件，主动从PushGateway或者Exporter拉取指标数据
  • Service discovery：动态发现要监控的目标
  • TSDB：数据核心存储与查询
  • HTTP Server：对外提供HTTP服务

• 采集层：

  • Exporter：将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

    • 直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
    • 间接采集：原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

  • PushGateway：

    • Prometheus 采用 pull 模式，但是可能由于不在一个子网或者基于安全原因，导致 Prometheus 无法直接拉取各个 target 数据。
    • 在监控业务数据的时候，需要将不同数据汇总, 由 Prometheus 统一收集。

  由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。

采集层分为两类，一类是周期较短的作业，还有一类是周期较长的作业

• 短作业：直接通过API，将指标推送给PushGateway
• 长作业：Retrieval组件直接从Job或者Exporter拉取数据

• 应用层：

  • AlertManager：告警推送，在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。
  • 可视化：提供Prometheus Web UI并且整合Grafana

3.2.3 特点

• 多维数据模型：底层存储为时间序列（time series）。时间序列由metric名称、一组key/value标签组成，同一组时间序具有相同的metric名称和标签组合。
• 数据采集更加精细：理论上可以达到每秒采集
• PromQL：一种灵活的查询语言，可以利用多维数据完成复杂查询

• 高效：大量的监控任务必然导致有大量的数据产生，prometheus可以高效的处理这些数据

  • 每秒处理上百万的监控指标
  • 每秒处理数十万的数据结点
• 可扩展，并且不依赖分布式存储，单个服务器节点和直接工作，同时也支持集群

• 易于集成：

  • 支持多种语言(java、Python、Go、Ruby、.Net、Node.js)等语言的客户端SDK
  • 还支持与其他的监控系统集成：Graphite,Statsd,Collected 等
• 可视化提供prometheus web UI
• 占用空间小，每个采样数据仅仅占用3.5byte左右空间，上百万条时间序列，间隔30s保留60天，大概花费磁盘200多G

未完待续......