陈晓宇 杨川胡 陈啸编著
Prometheus由 Go 语言编写而成，采用 Pull 方式获取监控信息，并提供了多维度的数据模型和灵活的查询接口。Prometheus不仅可以通过静态文件配置监控对象，还支持自动发现机制，能够通过 Kubernetes、Consul、DNS 等多种方式动态获取监控对象。在数据采集方面，借助 Go语言的高并发特性，单机 Prometheus可以采集数百个节点的监控数据；在数据存储方面，随着本地时序数据库的不断优化，单机Prometheus 每秒可以采集一千万个指标，如果需要存储大量的历史监控数据，则还支持远端存储。
中间件指系统软件和应用软件之间的连接软件，无论是在分布式系统中还是在单体系统中，中间件都发挥着重要的作用。
◎ 消息中间件，例如RabbitMQ、Kafka。◎ Web服务中间件，例如Tomcat、Jetty。◎ 缓存中间件，例如Redis、Memcached。◎ 数据库中间件，例如MySQL、PostgreSQL。
APM 主要是针对应用程序的监控，包括应用程序的运行状态监控、性能监控、日志监控及调用链跟踪等。调用链跟踪是指追踪整个请求过程，从用户发送请求（通常指浏览器或者应用客户端）到后端API服务，以及API服务和关联的中间件或者其他组件之间的调用，构建出一个完整的调用拓扑结构。
◎ Fluentd主要负责日志采集，其他开源组件还有Filebeat、Flume、Fluent Bit等，也有一些应用集成 Log4g等日志组件直接输出日志。 ◎ Kafka主要负责数据整流合并，避免突发日志流量直接冲击Logstash，业内也有用Redis替换Kafka的方案。 ◎ Logstash负责日志整理，可以完成日志过滤、日志修改等功能。 ◎ Elasticsearch负责日志存储和日志检索，自带分布式存储，可以将采集的日志进行分片存储。为保证数据高可用，Elasticsearch引入多副本概念，并通过Lucene实现日志的索引和查询。 ◎ Kibana是一个日志查询组件，负责日志展现，主要通过Elasticsearch的HTTP接口展现日志。
在数据采集方面，有的监控系统采用主动采集方式，有的监控系统采用被动上报方式，有的监控系统采用上述两者兼备的方式。
◎ 在数据传输方面，有的监控系统采用Socket传输，有的监控系统采用HTTP传输。
◎ 在数据存储方面，有的监控系统将监控数据保存在MySQL中，有的监控系统将监控数据保存在MongoDB、OpenTSDB、InfluxDB等时序数据库中。
◎ 指标采集子系统主要负责信息采集、过滤、汇总和存储。◎ 数据处理子系统主要负责数据分析、展现、预警、告警动作触发和告警等。
监控系统朝着自动化和智能化的方向发展，我们把性能监控、健康状态监控、应用监控等提供基础能力的监控称为传统监控；把具备机器学习和自动化运维能力，能够进行智能分析和故障处理的监控系统称为智能监控。
智能监控需要具备以下能力。◎ 通过多种维度的指标分析定位问题的故障点。数据中心内的指标种类繁多，需要根据从硬件（机房温度、风扇转速）到软件（TCP延迟、网络丢包率）等多个维度的监控指标，准确定位故障点。◎ 故障和风险预测。指通过对以往故障的学习，预测未来的故障时间。AWS通过对大量服务器发生故障的时间、故障前某些指标的异常等数据进行机器学习，可以准确预测服务器发生故障的时间，从而提前更换服务器。在AWS数据中心内有百万量级的服务器，故障发生的频率非常高，如果能够提前更换服务器，则会极大降低故障率。另外在互联网场景中，风险预测也非常重要，为了应对突发流量，通过对历史服务请求的 QPS 的学习，可以预测未来某个时间段将会出现的流量高峰，从而提前将服务扩容。
◎ 智能处理。单纯的通知告警并不能解决问题，现在的告警处理逐步从完全的人工处理，发展为目前的专家系统（机器提供一些处理意见），下一阶段将会是机器的自动化运维，在不需要人为干涉的情况下，能够通过机器处理故障，而智能监控系统正是运维自动化的首要环节。
智能监控将会是监控的发展趋势，但它并不是空中楼阁，而是建立在传统运维基础之上的，如果没有传统监控的支持，就没有实时数据的支持；如果没有对大量基础指标监控数据的学习，就没有智能决策。
Prometheus 也成为Kubernetes容器监控的标配。
Pull方式的优势是能够自动进行上游监控和水平监控，配置更少，更容易扩展，更灵活，更容易实现高可用。展开来说就是Pull方式可以降低耦合。由于在推送系统中很容易出现因为向监控系统推送数据失败而导致被监控系统瘫痪的问题，所以通过Pull方式，被采集端无须感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制，增强了整个系统的可控性。
如何获取监控对象呢？Prometheus支持两种方式：第1种是通过配置文件、文本文件等进行静态配置；第2种是支持ZooKeeper、Consul、Kubernetes等方式进行动态发现，例如对于Kubernetes的动态发现，Prometheus使用Kubernetes的API查询和监控容器信息的变化，动态更新监控对象，这样容器的创建和删除就都可以被Prometheus感知。
另一种是远端存储，适用于存储大量监控数据。通过中间层的适配器的转化，目前Prometheus支持OpenTSDB、InfluxDB、Elasticsearch等后端存储，通过适配器实现Prometheus存储的remote write和remoteread接口，便可以接入Prometheus作为远端存储使用。
Prometheus通过PromQL和其他 API可视化地展示收集的数据。Prometheus支持多种方式的图表可视化，例如Grafana、自带的PromDash及自身提供的模版引擎等。Prometheus还提供HTTP API查询方式，自定义所需要的输出。
Prometheus通过Pull方式拉取数据，但某些现有系统是通过 Push方式实现的，为了接入这些系统，Prometheus提供了对 PushGateway的支持，这些系统主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。
Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。
◎ 设备注册。有两种方式可以将监控对象注册到设备中：一种是手动配置Agent地址，但如果需要将机房中的几百台机器一次性加入，则将是很大的工作量；另一种是采用自动发现机制，可以配置整个网段，Server会检测整个网段的主机，并且可以自动配置模板、触发器等一系列相关配置。
◎ 数据收集。这里既包括主动采集，也包括被动接收，采集到的数据首先会被放置在内存中，然后被批量保存在数据库中。
Nagios原名为NetSaint，由Ethan Galstad开发并维护。Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控（CPU、内存、磁盘等）和网络监控（SMTP、POP3、HTTP和NNTP等），当然也支持用户自定义的监控脚本，如图1-13所示。
：Zabbix 是在1998年出现的，Nagios 是在1999年出现的，系统功能比较稳定，成熟度较高。而Prometheus和Open-Falcon都是最近几年才诞生的，虽然功能还在不断迭代、更新，但它们站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。
Zabbix采用关系数据库存储数据，这极大限制了 Zabbix的数据采集性能。Nagios和Open-Falcon都采用了RDD数据存储方式。Open-Falcon还加入了一致性 Hash 算法进行数据分片，并且可以对接到OpenTSDB，而且Prometheus 自研的一套高性能时序数据库，在 V3版本时可以达到每秒千万级别的数据存储，可通过对接第三方时序数据库扩展对历史数据的存储性能。
从容器支持方面来看，由于 Zabbix 和 Nagios 出现得比较早，当时容器还没有诞生，所以它们对容器的支持自然也比较差。
Prometheus的动态发现机制，不仅支持Swarm原生集群，还支持Kubernetes 容器集群监控，是目前容器监控的最佳解决方案。Zabbix 在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。Nagios则在网络监控方面有广泛应用。伴随着容器的发展，Prometheus 开始成为容器监控方面的标配，并将被广泛应用。总体来说，Prometheus可以说是目前监控领域最锋利的“瑞士军刀”了。
Counter是计数器类型，它的特点是只增不减，例如机器启动时间、HTTP访问量等。
Counter 具有很好的不相关性，不会因为机器重启而置0。我们在使用 Counter指标时，通常会结合 rate()方法获取该指标在某个时间段的变化率，例如，“HTTP请求总量”指标就属于典型的Counter指标，通过对它进行rate()操作，可以得出请求的变化率，如图2-2所示为HTTP的每秒请求数。
Gauge是仪表盘，表征指标的实时变化情况，可增可减，例如CPU和内存的使用量、网络 I/O 大小等，大部分监控数据都是 Gauge 类型的。如图2-3所示是内存使用量监控图，内存使用量随着时间的推移不断变化。
Summary 同 Histogram 一样，都属于高级指标，用于凸显数据的分布状况。如果需要了解某个时间段内请求的响应时间，则通常使用平均响应时间，但这样做无法体现数据的长尾效应。
Histogram反映了某个区间内的样本个数，通过{le="上边界"}指定这个范围内的样本数。
为了兼容 Push方式，Prometheus 提供了 Pushgateway组件。Pushgateway组件接收客户端发送过来的数据，按照 Job 和 Instance 两个层级进行组织，支持数据的追加和删除，并且为防止数据丢失，还支持本地存储。
Push方式的实时性相对较好，可以将采集数据立即上报到监控中心。Pull 方式通常进行周期性采集，采集时间为30s 或者更长时间。所以，如果对监控系统的实时性要求非常高，则建议采用Push方式。
Push 方式通常在采集完成后立即上报，本地不会保存采集数据，Agent 本身是没有状态的，而Master需要维护各种Agent状态。Pull 方式正好相反，Agent 本身需要有一定的数据存储能力，Master 只负责简单的数据拉取，而且Master本身可以做到无状态。
采用Push方式时，控制方为Agent,Agent上报的数据决定了上报的周期和内容。采用Pull方式时，Master更加主动，控制采集的内容和频率。
动态发现方式比较适合在云环境下使用。云的理念就是按需供给，资源是动态分配的，并且生命周期比物理机器短。
（1）需要在 Prometheus 里配置 Kubernetes API 的地址和认证凭据，这样Prometheus就可以连接到Kubernetes的API来获取信息。
Prometheus采用统一的Restful API方式获取数据，具体来说是调用HTTP GET请求或metrics数据接口获取监控数据。为了高效地采集数据，Prometheus对每个采集点都启动了一个线程去定时采集数据。在修改了采集的时间间隔后，Prometheus会提供两种配置更新方式：◎ 第1种是通过调用Prometheus的reload接口进行配置更新；◎ 第2种是发送信号，通过“kill –HUP Prometheus进程ID”动态加载配置，从而更新采集时间间隔。
具体解析方法不再赘述。如果是其他监控指标，则可以采用类似的方法从 proc文件系统中获取，例如通过/proc/net/arp获取ARP信息，通过/proc/cpuinfo获取 CPU信息。
kube-state-metrics通过监听API Server生成有关资源对象的状态指标，比如：◎ Deployment调度了多少个Pod副本？现在可用的有几个？◎ 有多少个Pod是running、stopped或terminated状态？◎ Pod重启了多少次？如图5-4所示是通过Grafana展现kube-state-metrics监控数据的样例，图中主要展现各种状态的容器的数量。
metrics-server（项目主页地址为 https://github.com/kubernetes-incubator/metricsserver）也是一个针对 Kubernetes 监控的数据聚合工具，是 Heapster 的替代品。在Kubernetes 1.11版本发布之后，Heapster已经被废弃。 Kubernetes 集群中的 HPA 水平自动扩缩容和 kubectl top 命令都依赖heapster/metrics-server，要使用这两个功能，需要保证已经安装 Heapster 或者metrics-server组件，推荐使用 metrics-server。
◎ metrics-server 主要关注资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等实时指标。
上面这个任务是定义一个 role为 endpoints的 kubernetes_sd_configs，现在将其添加到Prometheus的ConfigMap的配置文件中，
在Grafana WebUI的Alert页面测试邮件告警功能
Grafana也是支持钉钉告警的。在钉钉群里添加群机器人，选择最后的自定义机器
Grafana 的优势在于图表展示，而告警功能较弱，所以一般来说，在生产环境下不会直接使用 Grafana 的告警功能，而是使用功能更加强大的AlertManager，之后会进行相关讲解。