大家好，又见面了，我是你们的朋友全栈君。

Promethues 监控系统

Prometheus 是个啥

• Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。

• Prometheus使 用Go语言开发，是Google BorgMon监控系统的开源版本。

• 前面我们说一个较为完整数仓集群，不管是离线数仓，还是实时数仓，为了很好的管理集群，我们还需要 任务调度框架、资源管理框架、元数据管理、权限管理和监控管理等框架。

• 而 集群资源监控就是实现对集群资源监控的一种框架，通常搭配Grafana 数据可视化展示数据。

• 类似功能的还有 Ganglia和 Zabbix等。

• Promethues 官网

监控系统

什么是监控系统

• 监控系统在这里特指对数据中心的监控，主要针对数据中心内的硬件和软件进行监控和告警
• 随着技术不断迭代，越来越复杂的数据中心环境对监控系统提出了更越来越高的要求：
  • 需要监控不同的对象，例如容器，分布式存储，SDN网络，分布式系统。
  • 需要采集和存储大量的监控数据，例如每天数TB数据的采集汇总。
  • 以及基于这些监控数据的智能分析，告警及预警等。
• 在每个企业的数据中心内，或多或少都会使用一些开源或者商业的监控系统。
• 从监控对象的角度来看，可以将监控分为网络监控，存储监控，服务器监控和应用监控等
• 因为需要监控数据中心的各个方面。所以监控系统需要做到面面俱到，在数据中心中充当“天眼“角色。

监控分类

• Google指出，监控分为白盒监控和黑盒监控之分

  • 白盒监控：通过监控内部的运行状态及指标判断可能会发生的问题，从而做出预判或对其进行优化。
  • 黑盒监控：监控系统或服务，在发生异常时做出相应措施

监控目的

• 根据历史监控数据，对为了做出预测
• 发生异常时，及时报警，或做出相应措施
• 根据监控报警及时定位问题根源
• 通过可视化图表展示，便于直观获取信息

简介

描述

• 1、2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation),将Prometheus纳入其下第二大开源项目。
• 2、Prometheus性能也足够支撑上万台规模的集群

官网

• Promethues 官网

应用场景

• 适用场景

  • 1、Prometheus在记录纯数字时间序列方面表现非常好。
    • 它既适用于面向服务器等硬件指标的监控，
    • 也适用于高动态的面向服务架构的监控。
  • 2、对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。
  • 3、Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。
  • 4、它的搭建过程对硬件和服务没有很强的依赖关系。

• 不适用场景

  • 1、Prometheus它的价值在于可靠性，甚至在很恶劣的环境下，你都可以随时访问它和查看系统服务各种指标的统计信息
  • 2、如果你对统计数据需要100%的精确，它并不适用，例如：它不适用于实时监控系统。

Promethues 的优点

1、强大的多维度数据模型

• 时间序列数据通过 metric 名和键值对来区分。
• 所有的 metrics 都可以设置任意的多维标签。
• 数据模型更随意，不需要刻意设置为以点分隔的字符串。
• 可以对数据模型进行聚合，切割和切片操作。
• 支持双精度浮点类型，标签可以设为全 unicode。

2、灵活而强大的查询语句（PromQL）

• 在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。

3、易于管理

• Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。

4、高效

• 平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics

5、 采用pull 模式采集时间序列数据

• 这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics

6、采用 push gateway 推送数据

• 采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端

7、可以通过服务发现或者静态配置去获取监控的 targets。

8、有多种可视化图形界面和易于伸缩

软件架构

Prometheus Server

• Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。
• Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。
• Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。
• Prometheus Server 对外提供了自定义的PromQL 语言，实现对数据的查询以及分析。
• Prometheus Server 内置的 Express Browser UI，通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化。

Client Library

• 客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。
• 当Prometheus server 来 pull 时，直接返回实时状态的 metrics。

Push Gateway

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

Exporters

• 用于暴露已有的第三方服务的 metrics 给 Prometheus。
• 主要用来采集数据，并通过 HTTP 服务的形式暴露给 Prometheus Server，PrometheusServer 通过访问该 Exporter 提供的接口，即可获取到需要采集的监控数据
• 常见的Exporter有很多，例如node_exporter、mysqld_exporter、haproxy_exporter 等，支持如 HAProxy、StatsD、Graphite、Redis 此类的服务监控

Alertmanager

• 警报管理器。从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。
• 常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。

工作流程

1、Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态

• 任意组件只要提供对应的HTTP接口就可以接入监控

2、输出被监控组件信息的HTTP接口被叫 exporter

3、prometheus根据配置定时去拉取各个节点的数据，默认使用的拉取方式是pull

• 也可以使用pushgateway提供的push方式获取各个监控节点的数据。

• 将获取到的数据存入TSDB（时序型数据库）

4、此时prometheus已经获取到了监控数据，可以使用内置的PromQL进行查询

• 它的报警功能使用Alertmanager提供，Alertmanager是prometheus的告警管理和发送报警的一个组件

5、在Grafana或其他API客户端中，可视化收集的数据。

数据存储

存储方式

• Prometheus提供了两种数据持久化方式

  • 本地存储

    • 通过Prometheus自带的TSDB（时序数据库），将数据保存到本地磁盘，为了性能考虑，建议使用SSD(固态)
    • 但本地存储的容量毕竟有限，建议不要保存超过一个月的数据。
    • Prometheus本地存储经过多年改进，自Prometheus 2.0后提供的V3版本TSDB性能已经非常高，可以支持单机每秒1000w个指标的收集。

  • 远端存储

    • 适用于大量历史监控数据的存储和查询
    • 通过中间层的适配器的转化，Prometheus将数据保存到远端存储
    • 适配器实现Prometheus存储的remote write和remote read接口，并把数据转化为远端存储支持的数据格式
    • 目前，远端存储主要包括OpenTSDB、InfluxDB、Elasticsearch、M3DB等，其中M3DB是目前非常受欢迎的后端存储

• 注意

  • Prometheus本地数据存储能力一直为大家诟病
  • 但Prometheus本地存储设计的初衷就是为了监控数据的查询
  • Facebook发现85％的查询是针对26小时内的数据。
  • 所以Prometheus本地时序数据库的设计更多考虑的是高性能而非分布式大容量。

TSDB

• 概念

  • TSDB(Time Series Database)时序列数据库
  • 我们可以简单的理解为一个优化后用来处理时间序列数据的软件，并且数据中的数组是由时间进行索引的

• 数据库特点

  • 大部分时间都是写入操作
  • 写入操作几乎是顺序添加，大多数时候数据到达都以时间排序
  • 写操作很少写入很久之前的数据，也很少更新数据。大多数情况在数据被采集到数秒或者数分钟后就会被写入数据库
  • 删除操作一般为区块删除，选定开始的历史时间并指定后续的区块。很少单独删除某个时间或者分开的随机时间的数据
  • 基本数据大，一般超过内存大小。一般选取的只是其中一小部分且没有规律，缓存几乎不起任何作用
  • 读操作是十分典型的升序或者降序的顺序读。
  • 高并发的读操作十分常见

数据模型

• prometheus采集到的监控数据均以metric（指标）形式保存在时序数据库中（TSDB），属于同一指标名称，同一标签集合的、有时间戳标记的数据流。

• 每一条时间序列由metric 和 labels组成，每条时间序列按照时间的先后顺序存储它的样本值

• 默认情况下各监控client向外暴露一个HTTP服务，prometheus会通过pull方式获取client的数据

• Prometheus会将所有采集到的监控数据以时间序列的方式保存在内存数据库中，并且定时保存到硬盘上

  • 每一条数据由以下三部分组成：

    • 指标（metric）：指标名称和描述当前样本特征的 labelsets标签集组成；
    • 时间戳（timestamp）：一个精确到毫秒的时间戳；
    • 样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。

指标格式

• 指标（metric）的格式如下：

  <metric name>{<label name>=<label value>, ...}
  

  • 指标名称反映的是监控了什么。
  • 标签反映的是样本的维度，可以理解成指标的细化
  • 标签的名称只能由 ASCII 字符、数字以及下划线组成
  • 并满足正则表达式 [a-zA-Z_][a-zA-Z0-9_]*
  • 其中以_作为前缀的标签是系统保留的关键字，只能在系统内部使用。
  • 标签的值则可以包含任何 Unicode 编码的字符。

• 案例数据

  api_http_requests_total{ 
       method=``"POST"``, handler=``"/messages"``}
  

  • 指标是“api_http_requests_total”，含义是通过api请求的http总数。
  • 标签“method=“POST”” “handler=”/messages””代表了这些http请求中 POST 请求 ,并且handler是/messages的数量

指标类型

• Prometheus 的客户端库中提供了四种核心的指标类型

• Counter（计数器）

  • 一种累加的 metric，典型的应用如：请求的个数，结束的任务数， 出现的错误数等等。

• Gauge（仪表盘）

  • 一种常规的 metric，典型的应用如：温度，运行的 goroutines 的个数。可以任意加减。

• Histogram（直方图）

  • 可以理解为柱状图，典型的应用如：请求持续时间，响应大小。可以对观察结果采样，分组及统计。

• Summary（摘要）

  • 类似于 Histogram, 典型的应用如：请求持续时间，响应大小
  • 提供观测值的 count 和 sum 功能。
  • 提供百分位的功能，即可以按百分比划分跟踪结果

PromQL

概念

• PromQL (Prometheus Query Language)是 Prometheus 自己开发的数据查询DSL 语言。

说明

• 1、Prometheus数据展现除了自带的WebUI还可以通过Grafana，他们本质上都是通过HTTP + PromQL的方式查询Prometheus数据
• 2、和关系型数据库的SQL类似，Prometheus也内置了数据查询语言PromQL，它提供对时间序列数据丰富的查询，聚合以及逻辑运算的能力。

数据运算方式

• +（加法）
• -（减法）
• *（乘法）
• /（除法）
• %（求余）
• ^（幂运算）

聚合函数

• sum（求和）
• min（最小值）
• max（最大值）
• avg（平均值）
• stddev（标准差）
• stdvar（标准差异）
• count（计数）
• count_values（对value进行计数）
• bottomk（后n条）
• topk（前n条）
• quantile（分布统计）

软件的安装

略（我好懒不想写）。。。

再回(๑•̀ㅂ•́)و✧