监控之Promethus+grafana概述

如今，很多监控系统开始倾向于使用Promethus+grafana的解决方案，Prometheus 是一个开源系统监控和警报工具包，最初在 SoundCloud 构建，采用go语言开发，它启发于 Google 的 borgmon 监控系统。目前，许多公司和组织都采用了 Prometheus，该项目拥有非常活跃的开发者和用户社区。它现在是一个独立的开源项目，独立于任何公司维护。为了强调这一点，并明确项目的治理结构，Prometheus 于 2016 年加入CNCF云原生计算基金会，成为继 Kubernetes 之后的第二个托管项目。

Prometheus 将其指标收集并存储为时间序列数据，即指标信息与记录它的时间戳一起存储，以及添加可选键值对的标签。Prometheus 最大优点就是可更好地记录任何纯数字时间序列，所以它有时也被称为一个时序数据库。它既适合以机器为中心的监控，也适合监控高度动态的面向服务的架构。尤其在微服务中，它对多维数据收集和查询的支持是一个特殊的优势。但Prometheus收集的数据可能不够详细和完整，Prometheus 不适合做审计计费，因为它的数据是按一定时间采集的，关注的更多是系统的运行瞬时状态以及趋势，即使有少量数据没有采集也能容忍，但是审计计费需要记录每个请求，并且数据长期存储，这个 Prometheus 无法满足，这时可配合其他系统来收集和分析数据。

产品主要特性：

• 具有由度量名称和键/值对标识的**时间序列数据（TSDB(Time Series Database)时序列数据库）**的多维数据模型
• PromQL，一种利用这种维度的灵活查询语言
• 无需依赖分布式存储；单个服务器节点是自治的，可以使用联邦集群让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务量过大时，通过使用功能分区（sharding）+联邦集群（federation）对其进行扩展；参考：平均一个采样数据占3.5B左右，共320万个时间序列，每30秒采样一次，如此持续运行60天，占用磁盘空间大约为228GB左右；
• 通过 HTTP 上的拉模型进行时间序列收集，采用拉模式为主、推模式为辅的方式采集数据。
• 通过中间网关来推送这些时间序列
• 通过服务发现或静态配置来发现目标
• 支持多种图形模式和仪表板插件，比如Grafana

与Nagios、Zabbix、Ganglia、Open-Falcon等很多监控系统相比，Prometheus最主要的特色有4个：

• 通过PromQL实现多维度数据模型的灵活查询。
• 定义了开放指标数据的标准，自定义探针（如Exporter等），编写简单方便。
• PushGateway组件让这款监控系统可以接收监控数据。
• 提供了VM和容器化的版本。

官方文档，第三方文档，参考2。

选择 Prometheus原由，请参看Prometheus与其他监控对比。

Prometheus 生态系统由多个组件组成，其中许多是可选的：

Prometheus 服务器：它是Prometheus组件中的核心部分，负责从 Exporter 拉取实现对监控数据的获取，存储及查询。可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Sever需要对采集到的数据进行存储，Prometheus Server本身就是一个实时数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。Prometheus Server对外提供了自定义的PromQL，实现对数据的查询以及分析。另外Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据。

客户端库：用于检测应用程序代码的；Prometheus 对主流语言实现了客户端库的封装，通过客户端库，企业可以根据自己的业务需求，实现不同维度，适合自身应用业务的监控体系。Prometheus 客户端库主要提供四种主要的 metric 类型：
Counter： 一种累加的 metric，典型的应用如：请求的个数，结束的任务数， 出现的错误数等等。
Gauge： 一种常规的 metric，典型的应用如：温度，运行的 goroutines 的个数。可以任意加减。
Histogram： -可以理解为柱状图，典型的应用如：请求持续时间，响应大小。

PushGateway推送网关：主要用于短期的jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus中间网关推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。（PushGatway类似zabbix proxy）

exporters：HAProxy、StatsD、Graphite 等各自对应的服务支持；Exporter将监控数据采集的端的数据通过HTTP服务的形式暴露给Prometheus Server，将其转化为Prometheus支持的格式，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。可以将Exporter分为2类：

• 直接采集：即原生支持的
  这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
  
• 间接采集：第三方厂商支持的
  原有监控目标并不直接支持Prometheus，因此需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。如：Mysql Exporter，JMX Exporter，Consul Exporter等。
  
  AlertManager：在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警。当AlertManager从 Prometheus server 端接收到 alerts后，会进行去除重复数据，分组，并路由到对的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，webhook 等。
  

工作原理： Prometheus 可直接从监控作业任务或通过一个中间者（推送网关）从短期作业中进行监控指标的抓取。并将这些所有抓取的样本存储在本地，并对这些数据执行规则匹配，以聚合现有数据和记录新的时间序列（存储到新的时间序列中）或生成警报。 而Grafana 或其他 API 消费者则可用于可视化收集的数据。Prometheus server通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。

告警流程图：

上图中的sendmessages告警模块基于springboot2进行开发，根据prometheus-manager-web设置的告警规则发送告警消息。所有alertmanager送来的告警消息，会存储至sendmessages的内存队列，通过ThreadPoolExecutor维护线程池，定时扫描内存队列里是否有消息，如有则进行发送。代码实现：

if (“firing”.equals(ai.getAlertStatus())) {
title = “告警 
”;
} else {
title = “恢复 
”;
}

使用 node_exporter，就可以轻松采集主机信息，更多 exporter 使用，请参考Third-party exporters；对于需要兼容传统 push 方式的 metrics 收集，可以使用 Push Gateway，将数据推送到 Push Gateway，即可快速实现指标采集，以下为采集本机进程数的脚本实现：

1）telegraf+prometheus+grafana+aletmanager+dingtalk实现主机监控告警

telegraf:数据采集组件，类似于zabbix的agent,作为Prometheus的采集客户端，默认端口9273

prometeus：时序型数据库，也是整套监控的核心，提供web页面，默认主动从各个telegraf拉取数据，并根据rules产生告警推送给alertmanager管理告警

alertmanager：告警管理组件，控制告警频率、支持静默和抑制告警，并将告警发送给对应的route（邮件、钉钉、企微等）

dingtalk：管理alermanager发送过来的告警，可以定制告警模板，发送给指定的钉钉群

grafana:图形化界面，可以配置多种数据源（zabbix、prometeus、influx、redis等等）将数据源进行图形化展示,也可以配置告警，并发送告警

2）监控结构层

3）k8s监控

4）监控时序：云原生 UI 根据服务端返回的 Grafana 地址，访问获取到自定义模版，界面展示；

5）zabbix架构回顾

zbbix官方文档。

zabbix告警流程：

6）open-Falcon

OpenFalcon项目最初由小米公司发起的，是一款企业级、高可用、可扩展的开源监控解决方案。整个系统的后端，全部golang编写，portal和dashboard使用python编写。更多参看官方文档。


每台服务器都安装falcon-agent。falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标。只要安装了falcon-agent，机器就会自动采集各项指标，主动上报，不需要用户在server做任何配置。虽然server端有较大的压力，但是open-falcon的服务端组件单机性能足够高，同时可以水平扩展，所以自动采集足够多的数据，更方便SRE和DEV事后追查问题。另外，falcon-agent也提供了一个proxy-gateway，用户可以方便的通过http接口，push数据到本机的gateway，gateway会帮忙高效率的转发到server端。

常见的OpenFalcon包含transfer、hbs、agent、judge、graph、API几个进程。但没有提供用户界面。用户界面的解决方案是OpenFalcon官方提供的Dashboard，由python编写的一个Web服务。Dashboard调用OpenFalcon的API节点REST，完成用户认证，查询历史等操作。 以下是各个节点的数据流向图，主数据流向是agent -> transfer -> judge/graph：

浏览器访问：http://ip:8081

7）Zabbix、Nagios、Open-Falcon这3大开源运维监控工具的比较

……

1）其他监控

java全链路追踪 Sleuth+Zipkin ： 我们已经接触过几种微服务的监控方式，比如：

Spring Boot Actuator 监控微服务，：https://blog.csdn.net/qq_33257527/article/details/88294016

Spring Boot Admin也是监控微服务，他是把Actuator的数据用可视化的方式呈现出来，Hystrix Dashboard监控Hystrix服务，Hystrix Turbine聚合多个Hystrix服务的监控信息等，接下来我们要讨论的是微服务的“跟踪"。

Prometheus jmx ：https://www.cnblogs.com/caizhenghui/p/9132414.html 下载地址： https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.1/jmx_prometheus_javaagent-0.3.1.jar

Prometheus监控tomcat：https://blog.csdn.net/tiny_du/article/details/108402265

Kube-prometheus监控jmx指标 ： https://www.cnblogs.com/leozhanggg/p/14059720.html

2）监控的一些概念

SLA：服务水平协议
你承诺向用户提供的服务，如果你无法满足，可能会受到惩罚。
例如：“99.5%”的可用性。
关键词：合同

SLO：服务水平目标
你在内部设置的目标，驱动你的测量阈值(例如，仪表板和警报)。通常，它应该比SLA更严格。
示例：“99.9%”可用性(所谓的“三个9”)。
关键字：阈值

SLI：服务水平指标
你实际测量的是什么，以确定你的SLO是否在满足目标/偏离目标。
示例：错误率、延迟。
关键词：指标。