Prometheus学习笔记

介绍

概念

        Prometheus 是一个开源的系统监控（monitor）和报警工具，专为可靠和高效的时序数据（metrics）收集和存储而设计。

        时序数据是带有时间戳的数据点，通常用于监控系统的性能指标。

概述

        Prometheus 是一个时间序列数据库，但它不仅仅是一个时间序列数据库。

        Prometheus 涵盖了可以绑定的整个生态系统工具集及其功能。Prometheus主要用于对基础设施的监控，包括服务器（CPU、MEM 等）、数据库（MYSQL、PostgreSQL 等）、Web 服务等，几乎所有东西都可以通过 Prometheus 进行监控。而它的数据，则是通过配置和建立与数据源的联系来获取的。

        在 Prometheus 的架构设计中，Prometheus 并不直接服务监控特定的目标，就比如我们监控linux系统，Prometheus 不会自己亲自去监控linux的各项指标。其主要任务负责数据的收集，存储并且对外提供数据查询支持。

        因此为了能够监控到某些东西，如主机的CPU使用率，我们需要使用到 Exporter 。Exporter是一个相对开放的概念，不是专门指某一个程序。它可以是一个独立运行的程序，独立于监控目标以外（如 Node Exporter 程序，独立于操作系统，却能获取到系统各类指标）。总结就是，只要能够向 Prometheus 提供标准格式的监控样本数据，那就是一个 Exporter。

        其实还有一些其他的监控软件，比如 Cacti（画图能力强大）、Nagios（监控报警效果好）、Zabbix（前两个的集合）、Openfalcon（小米自行开源研发）等。

背景

        Prometheus 受启发于 Google 的 Brogmon 监控系统（相似的 Kubernetes 是从 Google 的Brog系统演变而来），从2012年开始由前Google工程师在 Soundcloud 以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继 Kubernetes 之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合，它也是 Cloud Native Computing Foundation（CNCF）的首批项目之一。

优势

        Prometheus 是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统和普通命令，Prometheus 的优点如下。

省时

        命令获取数据不能随时得到数据，监控软件可以时时刻刻提我们去获取数据

简化操作

        操作更加简化，界面效果更加直观，门槛更加低

易于管理

        Prometheus 核心部分只有一个单独的二进制文件，不存在任何的第三方依赖（数据库，缓存等等)，唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险

        Prometheus 基于 Pull 模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。

监控服务的内部运行状态

        Pometheus 鼓励用户监控服务的内部状态，基于 Prometheus 丰富的 Client 库，用户可以轻松的在应用程序中添加对 Prometheus 的支持，从而让用户可以获取服务和应用内部真正的运行状态。

强大的数据模型

        所有采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB）所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。

        每一条时间序列由指标名称（Metrics Name）以及一组标签（Labels）唯一标识。每条时间序列按照时间的先后顺序存储一系列的样本值。

        其中表示维度的标签可能来源于你的监控对象的状态，比如 content_path=/api/path；当然也可能来源于的你的环境定义，比如 environment=produment 。基于这些Labels我们可以方便地对监控数据进行聚合、过滤、裁剪。

强大的查询语言PromQL

        Prometheus 内置了一个强大的数据查询语言 PromQL。 通过 PromQL 可以实现对监控数据的查询、聚合。同时 PromQL 也被应用于数据可视化（如Grafana）以及告警当中。

        比如通过PromQL可以轻松回答类似于以下问题，预测在多少小时后，磁盘空间占用大致会是什么情况？内存占用率前三的服务有哪些？

高效

        对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而 Prometheus 可以高效地处理这些数据，对于单一 Prometheus Server 实例而言它可以处理数以百万的监控指标或者每秒处理数十万的数据点。

可扩展

        Prometheus 是如此简单，因此你可以在每个数据中心、每个团队运行独立的 Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区（sharding）+联邦集群（federation）可以对其进行扩展。

易于集成

        使用 Prometheus 可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持 Java、JMX、Python、Go、Ruby、.Net等语言的客户端 SDK，基于这些 SDK 可以快速让应用程序纳入到 Prometheus 的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅支持 Prometheus，还能支持 Graphite 这些其他的监控工具。

        同时Prometheus还支持与其他的监控系统进行集成，像Graphite、Statsd、Collected、Scollector、muini、Nagios等。

        Prometheus 社区还提供了大量第三方实现的监控数据采集支持，比如JMX、CloudWatch、EC2、MySQL、PostgresSQL、Haskell、Bash、SNMP、Consul、Haproxy、Mesos、Bind、CouchDB、Django、Memcached、RabbitMQ、Redis、RethinkDB、Rsyslog等。

可视化

        Prometheus Server 中自带了一个Prometheus UI，通过这个UI可以方便地直接对数据进行查询，并且支持直接以图形化的形式展示数据。同时 Prometheus 还提供了一个独立的基于 Ruby On Rails 的 Dashboard 解决方案 Promdash。

        同时 Grafana 可视化工具也已经提供了完整的 Prometheus 支持，基于 Grafana 可以创建更加精美的监控图标。基于 Prometheus 提供的 API 还可以实现自己的监控可视化 UI。

开放性

        通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持，因此应用程序会与所选择的监控系统进行绑定。

        为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系统的支持，要么就在外部创建单独的服务来适配不同的监控系统。

        而对于 Prometheus 来说，使用 Prometheus的client library 的输出格式不止支持 Prometheus的格式化数据，也可以输出支持其它监控系统的格式化数据，比如 Graphite。

        因此你甚至可以在不使用 Prometheus 的情况下，采用 Prometheus 的 client library 来让你的应用程序支持监控数据采集。

架构

        下面是官方架构图。

        下图类似。

​

        Prometheus Server 直接从监控目标中或者间接通过推送网关来拉取监控指标，它在本地存储所有抓取到的样本数据，并对此数据执行一系列规则，以汇总和记录现有数据的新时间序列或生成告警。可以通过 Grafana 或者其他工具来实现监控数据的可视化。

        Prometheus中主要的数据流步骤为

        Scraping（抓取）

        Prometheus Server 定期从配置的 targets（如 exporters）抓取 metrics。
        存储

        抓取的数据存储在本地时序数据库中。
        查询

        用户通过 PromQL 查询数据，进行可视化或分析。
        报警

        通过配置报警规则，Prometheus Server 将报警信息发送到 Alertmanager 。

        从上面两图中可以看到，整个 Prometheus 有以下几个重要的核心组件。

Prometheus Server

        Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询，并提供查询接口。

        Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。

        其次 Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。

        最后 Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。

        其中 Prometheus Server 内置的 Express Browser UI，通过这个 UI 可以直接通过 PromQL实现数据的查询以及可视化。

        Prometheus Server 的联邦集群能力可以使其从其他的 Prometheus Server 实例中获取数据，因此在大规模监控的情况下可以通过联邦集群以及功能分区的方式对 Prometheus Server 进行扩展。

Exporters

        用于暴露应用和系统的 metrics（指各种各样的数据，比如cpu的使用率，内存的使用率），常见的有 Node Exporter、Blackbox Exporter 等。

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

        一般来说可以将 Exporter 分为2类。

        直接采集

        这一类 Exporter 直接内置了对 Prometheus 监控的支持，比如 cAdvisor，Kubernetes，Etcd，Gokit 等，都直接内置了用于向 Prometheus 暴露监控数据的端点。

        间接采集

        间接采集，原有监控目标并不直接支持 Prometheus，因此我们需要通过 Prometheus 提供的Client Library 编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter 等。

客户端库

        用于在应用程序中直接生成metrics。

AlertManager 

        Prometheus 通过配置报警规则，如果符合报警规则，那么就将报警推送到 AlertManager，由其进行报警处理。

        在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足 PromQL 定义的规则，则会产生一条告警，而告警的后续处理流程则由 AlertManager 进行管理。在 AlertManager 中我们可以与邮件，Slack 等等内置的通知方式进行集成，也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。

管理报警，处理由Prometheus Server发送的报警信息，支持去重、分组和路由。

PushGateway（中间件/代理）

        用于短生命周期的批处理作业推送 metrics。

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

        Prometheus 收集到数据之后，由 WebUI 界面进行可视化图标展示。目前我们可以通过自定义的 API 客户端进行调用数据展示，也可以直接使用 Grafana 解决方案来展示。

        简单地说，Prometheus 的实现架构也并不复杂。其实就是收集数据、处理数据、可视化展示，再进行数据分析进行报警处理。 但其珍贵之处在于提供了一整套可行的解决方案，并且形成了一整个生态，能够极大地降低我们的研发成本。

        而且由于其中大多数组件都是用 Go 语言编写的，因此很容易构建和部署为静态二进制文件。

​

扩展

        Prometheus 中各类设备常用的监控方法。

级别	监控内容	Exporter
网络	网络协议（如http、dns、tcp、icmp）、网络硬件（如路由器、交换机等）	BlockBox Exporter、SNMP Exporter
主机	资源用量	Node Exporter
容器	资源用量	cAdvisor
应用	延迟、错误、内部状态等	代码中集成 Prometheus Client
中间件状态	资源用量及服务状态	代码中集成 Prometheus Client
编排工具	集群资源用量、调度等	Kubernetes Components

数据模型

        Prometheus 所有采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB），属于同一指标名称、同一标签集合的、有时间戳标记的数据流。除了存储的时间序列，Prometheus 还可以根据查询请求产生临时的、衍生的时间序列作为返回结果。

指标/数据类型

        Prometheus 的客户端库中提供了四种核心的指标类型。但这些类型只是在客户端库（客户端可以根据不同的数据类型调用不同的 API 接口）和在线协议中，实际在 Prometheus server 中并不对指标类型进行区分，而是简单地把这些指标统一视为无类型的时间序列。

Counter（计数器）

        单调递增的计数器，通常用于记录事件的发生次数。

        Counter 类型代表一种样本数据单调递增的指标，即只增不减，除非监控系统发生了重置。例如，你可以使用 counter 类型的指标来表示服务的请求数、已完成的任务数、错误发生的次数等。而counter 主要有两个方法。

// 将counter值加1
Inc()
// 将指定值加到counter值上，如果指定值<0 会panic
Add(float64)

        Counter 类型数据可以让用户方便的了解事件产生的速率的变化，在 PromQL 内置的相关操作函数可以提供相应的分析，比如以 HTTP 应用请求量来进行说明。

// 通过rate()函数获取HTTP请求量的增长率
rate(http_requests_total[5m])
// 查询当前系统中，访问量前10的HTTP地址
topk(10, http_requests_total)

        不过不要将 counter 类型应用于样本数据非单调递增的指标，比如当前运行的进程数量（这应该用 Guage 类型）。

Guage（仪表盘）

        可增可减的度量值，通常用于记录瞬时值，如温度、内存使用量。

        Guage 类型代表一种样本数据可以任意变化的指标，即可增可减。

        Guage 通常用于像温度或者内存使用率这种指标数据，也可以表示能随时增加或减少的“总数”，比如当前并发请求的数量。

        对于 Gauge 类型的监控指标，通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况，比如计算 CPU 温度在两小时内的差异。

dalta(cpu_temp_celsius{host="zeus"}[2h])

        我们还可以通过PromQL 内置函数 predict_linear() 基于简单线性回归的方式，对样本数据的变化趋势做出预测。例比如用基于 2 小时的样本数据，来预测主机可用磁盘空间在 4 个小时之后的剩余情况。

predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

Histogram（直方图）

        直方图，记录值的分布情况，常用于请求延迟等度量。

        在大多数情况下人们都倾向于使用某些量化指标的平均值，比如CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。

        为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。比如统计延迟在 0~10ms 之间的请求数有多少而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。

        Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。

        Histogram 在一段时间范围内对数据进行采样（通常是请求持续时间或响应大小等），并将其计入可配置的存储桶（bucket）中，后续可通过指定区间筛选样本，也可以统计样本总数，最后一般将数据展示为直方图。

        Histogram 类型的样本会提供三种指标，样本的值分布在 bucket 中的数量，表示指标值小于等于上边界的所有样本数量；所有样本值的大小总和；样本总数。

        注意，bucket 可以理解为是对数据指标值域的一个划分，划分的依据应该基于数据值的分布。

Summary（摘要）

        摘要，类似于直方图，但提供百分位统计。

        与 Histogram 类型类似，Summary 用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。

        Summary 类型的样本也会提供三种指标，样本值的分位数分布情况；所有样本值的大小总和；样本总数。

        Histogram 与 Summary 的异同在于，它们都包含了所有样本值的大小总和，样本总数这两项指标；而 Histogram 需要通过函数计算分位数，而 Summary 则直接存储了分位数的值。

指标名称和标签

        每一条时间序列由指标名称（Metrics Name）以及一组标签（键值对）唯一标识。

        其中指标的名称（metric name）可以反映被监控样本的含义（比如 http_requests_total 表示当前系统接收到的 HTTP 请求总量）。指标名称只能由 ASCII 字符、数字、下划线以及冒号组成，同时必须匹配正则表达式 [a-zA-Z_:] [a-zA-ZO-9_:]* 。

        注意，冒号用来表示用户自定义的记录规则，不能在 exporter 中或监控对象直接暴露的指标中使用冒号来定义指标名称。

        而通过使用标签，Prometheus 开启了强大的多维数据模型。对于相同的指标名称，通过不同标签列表的集合，会形成特定的度量维度实例（例如：所有包含度量名称为 /api/tracks 的 http 请求，打上 method=POST 的标签，就会形成具体的 http 请求）。

        在查询语言在这些指标和标签列表的基础上进行过滤和聚合。改变任何度量指标上的任何标签值（包括添加或删除指标），都会创建新的时间序列。标签的名称只能由 ASCII 字符、数字以及下划线组成并满足正则表达式 [a-zA-Z_:] [a-zA-ZO-9_:]* 。其中以 _  作为前缀的标签，是系统保留的关键字，只能在系统内部使用。标签的值则可以包含任何 Unicode 编码的字符。

样本

        在时间序列中的每一个点称为一个样本（sample），样本由以下三部分组成。

        指标（metric）

        指标名称和描述当前样本特征的 labelsets。

        时间戳（timestamp）

        一个精确到毫秒的时间戳。

        样本值（value）

         一个 folat64 的浮点型数据表示当前样本的值。

表示方式

        通过如下表达方式表示指定指标名称和指定标签集合的时间序列。

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

        比如指标名称为api_http_requests_total，标签为method="POST" 和handler="/messages"的时间序列可以表示为如下。

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

        这与 OpenTSDB 中使用的标记法相同。

专业术语

Metric (指标)

        Metric 是监控系统中用来衡量系统性能的数据点。它可以是计数器、摘要统计、直方图或其他类型的度量值。

        在 Prometheus 中，每个 metric 都有一个名称和一系列标签来唯一标识其含义。

Label (标签)

        Label 是一组键值对，用于附加元数据到 metric 上，从而允许对相同类型的 metric 进行分组和过滤。

        Labels 提供了灵活性，使得同一个 metric 可以根据不同的维度（比如实例、环境、版本等）进行区分。

Time Series (时间序列)

        Time Series 是按时间顺序排列的一系列数据点。每个数据点包含一个特定的时间戳和一个度量值。

        在 Prometheus 中，每个唯一的 metric 和 label 组合构成一个时间序列。

Pull (拉取)

        Pull 是指 Prometheus Server 主动从目标系统（如 exporters）中获取数据的过程。

        Prometheus 通过周期性地轮询这些目标系统来收集 metrics。

Push (推送)

        Push 是指目标系统主动向 Prometheus 发送数据的方式。

        由于 Prometheus 主要使用 pull 机制，但为了适应一些无法定期被轮询的情况，也可以使用Push Gateway 来实现临时性的推送。

Exporter (导出器)

        Exporter 是一种特殊的中间件，它可以从不直接支持Prometheus协议的服务中提取metrics，并将其转换为 Prometheus 可识别的格式。

        Exporters 通常是作为代理部署在目标系统前面，或者作为目标系统的一部分。

PromQL (Prometheus Query Language)

        PromQL 是 Prometheus 提供的查询语言，用于从 Prometheus Server 中检索和操作时间序列数据。

        它支持丰富的函数和运算符，可以进行聚合、过滤和计算。

Alert (报警)

        Alert 是当预定义的规则被满足时触发的通知。这些规则基于 PromQL 查询。

        当报警触发时，Prometheus Server 会把报警信息发送给 Alertmanager 进行进一步处理。

Timestamp (时间戳)

        Timestamp 是一个时间标记，通常与每个数据点相关联，用于标识该数据点的具体时间。

TSDB (Time-Series Database, 时间序列数据库)

        TSDB 是一种专门优化来存储和检索时间序列数据的数据库。

        Prometheus 使用一个内部的 TSDB 来存储收集到的 metrics 。

Pushgateway

        Pushgateway 是 Prometheus 生态系统中的一个组件，用于接收和缓存来自不能定期被轮询的系统的 metrics 。

        它作为一个临时的缓冲区，允许这些系统将 metrics 推送到 Pushgateway，然后再由Prometheus Server 周期性地从 Pushgateway 中拉取。

Grafana

        Grafana 是一个开源的度量分析和可视化套件，经常与 Prometheus 一起使用来创建仪表板和图表。

        Grafana 可以从 Prometheus Server 中读取数据，并以图形化的方式展示出来，使用户能够更好地理解和分析监控数据。

安装和配置

        Prometheus 这里有两种安装方法，二进制源码安装和容器安装。

二进制源码安装

Download | Prometheus

        可以去上面 prometheus 的官网寻找符合需求的版本进行下载，下面拿 prometheus-2.43.0.linux-amd64.tar.gz 举例。

        首先是新建放压缩包和文件的目录，放入压缩包后解压。

mkdir /prom # 方便之后记住，可以新建一个目录，名字自定义，这里拿prom举例
cd /prom # 把prometheus的压缩包文件放在这个目录下
tar xf 压缩包名 # 这里打一个p后直接tab键自动补齐就可以

        下面是具体效果图。

​

        这里是给 prometheus 重新命名，省去后面的版本号等信息，主要是为了之后输入方便，也可以略过。

​

        临时和永久修改PATH变量，添加 prometheus 的路径，最后查看效果。

PATH=/prom/prometheus:$PATH
echo 'PATH=/prom/prometheus:$PATH' >>/etc/profile
which prometheus

​

        这里是添加 service 方式管理，以后可以直接 systemctl stop/start prometheus来停止和启动 prometheus 。

        下面是 prometheus.service 里的具体内容。

[Unit]
Description=prometheus
[Service]
ExecStart=/prom/prometheus/prometheus --config.file=/prom/prometheus/prometheus.yml
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target

        修改后需要重启服务以生效，然后用 systemctl 启动 prometheus，并查看进程情况。

systemctl daemon-reload
systemctl start/restart prometheus
systemctl enable prometheus # 设置开机自启动

        下面是效果图。

​

        确定 prometheus 在运行后就可以去浏览器内进入查看。

(http://)IP:9090

        效果图如下。

​

        点击 status 的 Targets 就可以看到当前主机采集的所有数据来源。

        解析图如下。

​

​

Docker 安装

        Docker 安装的优势是轻量级安装，不会占用太多空间，但缺点是会缺少一些需要的文件，比如 prometheus.yml ，这就需要自行创建后怪再到容器的相关目录下，所以在选择两种安装方式时应结合自身需求再进行安装。

        首先如果还在使用默认官方源的话，应该要先给现有的 docker 换源，因为官方源基本拉取不了镜像。

cd /etc/docker
vim daemon.json # 没有这个文件就直接创建，有就修改

{
  "registry-mirrors":["https://ruklgp3w.mirror.aliyuncs.com"]
}

        这里如果阿里云的源也不行就需要我们自己从网上寻找可用的源，因为这种源随时可能被封掉。

        换源后就是重启 docker 。

systemctl stop docker 
systemctl start docker 
# 或者直接 restart
systemctl restart docker 

        具体效果图如下。

​

        然后就是直接拉取 prometheus 的镜像生成容器运行。

docker run -d -p 自定义端口号:9090 --name 自定义容器名 prom/prometheus

        当你看到如下效果图时，说明已经成功。

​

        然后就是进入浏览器，输入IP和端口号。（注意如果像我一样在下图中用了云服务器的公网IP，需要先去安全组添加规则，授权端口访问资格才可以）

​

        而且容器安装方法在本机上会不太容易成功，因为拉取速度慢，容易超时。        

        这里就是 prometheus 的基础安装，这是第一步，如果想要发挥它的全部功能，就得在你想要监控的其他虚拟机或者主机上安装 node exporter，还有一些其他种类的 exporter，可以自行在之前的官网里的下面寻找符合要求的 exporter，如下图。

Node Exporter 安装

        因为主要用到的是node exporter，所以下面以node_exporter举例。

        这里的 node_exporter 可以通过 xftp 上传，如果想要同时监控多个主机，可以参考之间的ansible 笔记，在监控主机上安装 ansible 后直接从 ansible 主机传到其他被监控主机，会方便很多。（xftp上传方法在前面的笔记也讲过，这里不再重复了）

scp node_exporter-1.4.0-rc.0.linux-amd64.tar.gz（下载的压缩包名） root@被监控主机IP:/root（目标目录路径名）
# 这里的被监控主机一定要和安装了ansible的主机建立了免密通道才可以执行成功这条命令
ansible all -m copy  -a 'src=node_exporter-1.4.0-rc.0.linux-amd64.tar.gz（下载的压缩包名） dest=/root/（目标目录路径名）'
# 这条命令是一键将node_exporter压缩包复制到所有建立了免密通道的被控主机上的规定目录里

        下面是一键安装 node_expoter 的脚本，大家如果有在几个虚机上安装同一个软件的需求就可以自己在第一台上安装后，把步骤总结成脚本，在其他虚拟机上直接运行脚本即可，会方便很多。

        下面的代码中注意 node_exporter 的版本号和端口号要注意，不要写错或者冲突，后续会很麻烦。

        注意node_exporter是安装在被监控的主机上，被监控的主机不需要再额外安装prometheus。

#!/bin/bash

#下面node_exporter压缩包的安装目录大家以自己的实际目录为准
tar xf /root/node_exporter-1.4.0-rc.0.linux-amd64.tar.gz  -C /
cd  /
mv node_exporter-1.4.0-rc.0.linux-amd64/ node_exporter
cd /node_exporter/
echo 'PATH=/node_exporter/:$PATH' >>/etc/profile

#生成nodeexporter.service文件
cat >/usr/lib/systemd/system/node_exporter.service  <<EOF
[Unit]
Description=node_exporter
[Service]
ExecStart=/node_exporter/node_exporter --web.listen-address 0.0.0.0:9090 
# 这里的端口号9090要注意，如果有冲突就要改掉
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF

#让systemd进程识别node_exporter服务
systemctl daemon-reload
#设置开机启动
systemctl  enable node_exporter
#启动node_exporter
systemctl  start node_exporter

        这是运行的效果图。

​

        在被监控的主机上运行成功 node_exporter 后，就需要去安装了 prometheus 的监控主机上添加抓取数据的配置，也就是添加node节点服务器，将抓取的数据存储到时序数据库里

        具体格式代码如下，注意格式，一定要规范对齐，不然会出错。

# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).
  
# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # - alertmanager:9093
          
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  #   # - "second_rules.yml"
  
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: "prometheus"
    static_configs:
    - targets: ["localhost:9090"]

#以上是原文件部分，下面是需要增加的信息，记住这里的格式要严谨，必须对齐


  - job_name: "test" # 这里自定义名字
    static_configs:
      - targets: ["192.168.31.178:9090"] #这里是安装了node_exporter,也就是被采集的主机IP

        效果图如下。

        这里有两点需要提醒一下。

        首先端口号冲突问题。

        如果都安装后发现冲突可以去 /usr/lib/systemd/system 这个页面，找到 node_exporter 或者prometheus 相关 .service，如下图，编辑，在里面修改端口号后重启所有相关服务。

​

        其次容器安装后 yml 文件创建挂载问题。

        注意文件名 prometheus.yml 千万不要打错任何一个字母，挂载时两边都只需要填到目录，不需要加入具体文件名。具体内容可以直接复制我上面的代码，不过注意，由于#的原因，当你全部复制后全部代码的格式会大变，你可能需要慢慢对齐调整位置，不要对错。

docker exec -it sc-prom-1（这是你创建的容器名） sh（不支持bash）#进入容器内部
pwd #找到所在路径
exit #退出
docker stop sc-prom-1
docker run -d -p 9090:9090 --name 自定义 -v （新建的prometheus.yml所在的目录路径名）:/etc/（在容器内部找到的目录路径名） prom/prometheus
service prometheus restart

        所以这里，就 prometheus 而言还是建议二进制源码安装，会方便很多。

        效果图如下，我这里是因为没有启动那边的服务，所以是红色，正常两台主机上按照上面的步骤后，确保启动 prometheus 和 node_exporter 的情况下 test 的位置会显示绿色。

​

Grafana安装

        最后为了更加直观、便捷地观察结果，我我们需要安装grafana这个出图软件。

        第一步还是需要下载相关包，具体可参照下图。

​

        然后就是对 grafana 进行重启和设置开机自启。

systemctl restart geafana-server
systemctl enable grafana-server

        启动后查看进程相关情况和端口号。

ps aux|grep grafana
netstat -anplut|grep grafana

        效果图如下。

​

        发现端口号是3000后进入浏览器打开 grafana，初始账号密码一般都是admin。

​

        如果看到要你输入新密码，需要可以更改，或者点左下角的 skip 跳过。

        下面就是 grafana 的主页面。

​

Grafana出图配置

        先配置prometheus的数据源。

        依次点击管理、数据源、add new data source、prometheus，具体如下。

​

​

​

        然后填写 URL，再进行连接测试。

​

​

        点击 Dashboards 进入仪表盘设置，我们需要导入 grafana 的模板。

​

​

        比如导入模版8919。（其实模版有很多，大家可以去网上搜索符合需求的，也可以自己做，不过需要掌握的知识更深，操作可能有点难度）

​

        然后自定义名字，导入之前连接的数据库，最后 import 导入。

​

        展示的大致效果图如下。

​

        其实还有很多监控不同信息的 exporter ，比如监控mysql和redis，步骤和 node_exporter 的大致一样，区别只是采集的具体信息不一样，所以这里限于篇幅，我就不在细讲。

        后面的部分我暂时还没有过多地去深入学习，所以很多知识可能只会停在比较浅层的地方。

PromQL

        PromQL (Prometheus Query Language) 是 Prometheus 自己开发的数据查询 DSL 语言，语言表现力非常丰富，内置函数很多，在日常数据可视化以及rule 告警中都会使用到它。
        在查询语句中，字符串往往作为查询条件 labels（标签）的值，和 Golang 字符串语法一致，可以使用 ""、''、 或者 ``  也可以使用正数或浮点数。

        Prometheus 提供了一种功能表达式语言 PromQL，允许用户实时选择和汇聚时间序列数据。表达式的结果可以在浏览器中显示为图形，也可以显示为表格数据，或者由外部系统通过 HTTP API 调用。

        比如下图中查询 node_loadl 会出来直观的图像显示数据。

​

        PromQL 是 Prometheus 自定义的一套强大的数据查询语言，除了使用监控指标作为查询关键字以为，还内置了大量的函数，帮助用户进一步对时序数据进行处理。

        下图是点击查看 metric 出来的页面。

​

        其中非 # 开头的每一行表示当前 Node Exporter 采集到的一个监控样本，而比如 go_info 则表明了当前指标的名称、大括号中的标签则反映了当前样本的一些特征和维度、浮点数则是该监控样本的具体值。

基础查询

        在 Prometheus 的表达式语言中，表达式或子表达式包括以下四种类型之一。

        瞬时向量（Instant vector） 

        一组时间序列，每个时间序列包含单个样本，它们共享相同的时间戳。也就是说，表达式的返回值中只会包含该时间序列中的最新的一个样本值。而相应的这样的表达式称之为瞬时向量表达式。

        区间向量（Range vector）

        一组时间序列，每个时间序列包含一段时间范围内的样本数据。

        标量（Scalar）

        一个浮点型的数据值。

        字符串（String）

        一个简单的字符串值。

        根据用户输入的表达式返回的数据类型是否合法取决于用例的不同，比如瞬时向量表达式返回的数据类型是唯一可以直接绘制成图表的数据类型。

查询时间序列

        当 Prometheus 通过 Exporter 采集到相应的监控指标样本数据后，我们就可以通过 PromQL对监控样本数据进行查询。

        当我们直接使用监控指标名称查询时，可以查询该指标下的所有时间序列，如下。

http_requests_total

        这等同于下面。

http_requests_total{}

        该表达式会返回指标名称为 http_requests_total 的所有时间序列。

http_requests_total{code="200",handler="alerts",instance="localhost:9090",job="prometheus",method="get"}=(20889@1518096812.326)
http_requests_total{code="200",handler="graph",instance="localhost:9090",job="prometheus",method="get"}=(21287@1518096812.326)

        PromQL 还支持用户根据时间序列的标签匹配模式来对时间序列进行过滤，目前主要支持两种匹配模式，完全匹配和正则匹配。

        PromQL支持使用 = 和 != 两种完全匹配模式。

        通过使用 label=value可以选择那些标签满足表达式定义的时间序列；反之使用 label != value 则可以根据标签匹配排除时间序列。

        例如，如果我们只需要查询所有 http_requests_total 时间序列中满足标签 instance 为localhost:9090 的时间序列，则可以使用如下表达式。

http_requests_total{instance="localhost:9090"}

        反之使用 instance != "localhost:9090" 则可以排除这些时间序列。

http_requests_total{instance!="localhost:9090"}

        除了使用完全匹配的方式对时间序列进行过滤以外，PromQL 还可以支持使用正则表达式作为匹配条件，多个表达式之间使用 "|" 进行分离。

范围查询

        我们直接通过类似于 PromQL 表达式 httprequeststotal 查询时间序列时，返回值中只会包含该时间序列中的最新的一个样本值，这样的返回结果我们称之为瞬时向量。而相应的这样的表达式称之为__瞬时向量表达式。

        而如果我们想过去一段时间范围内的样本数据时，我们则需要使用区间向量表达式。区间向量表达式和瞬时向量表达式之间的差异在于在区间向量表达式中我们需要定义时间选择的范围，时间范围通过时间范围选择器[]进行定义。例如，通过以下表达式可以选择最近10分钟内的所有样本数据。

http_request_total{}[10m]

        通过区间向量表达式查询到的结果我们称为区间向量。

        除了使用m表示分钟以外，PromQL的时间范围选择器支持其它时间单位，比如s - 秒、m - 分钟、w - 周、y - 年等。

时间位移操作

        在瞬时向量表达式或者区间向量表达式中，都是以当前时间为基准。

http_request_total{} # 瞬时向量表达式，选择当前最新的数据
http_request_total{}[5m] # 区间向量表达式，选择以当前时间为基准，5分钟内的数据

        而如果我们想查询，5分钟前的瞬时样本数据，或昨天一天的区间内的样本数据呢? 这个时候我们就可以使用位移操作，位移操作的关键字为 offset。

        可以使用offset时间位移操作，如下。

http_request_total{} offset 5m
http_request_total{}[1d] offset 1d

聚合操作

        一般来说，如果描述样本特征的标签(label)在并非唯一的情况下，通过 PromQL 查询数据，会返回多条满足这些特征维度的时间序列。而 PromQL 提供的聚合操作可以用来对这些时间序列进行处理，形成一条新的时间序列。

# 查询系统所有http请求的总量
sum(http_request_total)

# 按照mode计算主机CPU的平均使用时间
avg(node_cpu) by (mode)

# 按照主机查询各个主机的CPU使用率
sum(sum(irate(node_cpu{mode!='idle'}[5m]))  / sum(irate(node_cpu[5m]))) by (instance)

标量和字符串

        除了使用瞬时向量表达式和区间向量表达式以外，PromQL 直接支持用户使用标量(Scalar)和字符串(String)。

        标量（Scalar），一个浮点型的数字值。标量只有一个数字，没有时序，如下。

10

        需要注意的是，当使用表达式 count(http_requests_total)，返回的数据类型，依然是瞬时向量。用户可以通过内置函数 scalar() 将单个瞬时向量转换为标量。

        字符串（String），一个简单的字符串值。如果直接使用字符串作为PromQL表达式，则会直接返回字符串。

"this is a string"
'these are unescaped: \n \\ \t'
`these are not unescaped: \n ' " \t`

合法的PromQL表达式

        所有的 PromQL 表达式都必须至少包含一个指标名称(例如 http_request_total )，或者一个不会匹配到空字符串的标签过滤器(例如{code="200"})。

        因此以下两种方式，均为合法的表达式。

http_request_total # 合法
http_request_total{} # 合法
{method="get"} # 合法

        而如下表达式，则不合法。

{job=~".*"} # 不合法

        同时，除了使用<metric name>{label=value}的形式以外，我们还可以使用内置的__name__标签来指定监控指标名称。

{__name__=~"http_request_total"} # 合法
{__name__=~"node_disk_bytes_read|node_disk_bytes_written"} # 合法

操作符

二元算术运算符

+	加法	-	减法
*	乘法	/	除法
%	模	^	幂

        二元运算操作符支持 scalar/scalar（标量/标量）、vector/scalar（向量/标量）、vector/vector（向量/向量）之间的操作。

        在两个标量之间进行数学运算，得到的结果也是标量。

布尔运算符

==	等于	!=	不等于
>	大于	<	小于
>=	大于等于	<=	小于等于

        布尔运算符被用于  scalar/scalar（标量/标量）、vector/scalar（向量/标量）、vector/vector（向量/向量）。默认情况下布尔运算符只会根据时间序列中样本的值，对时间序列进行过滤。

        我们可以通过在运算符后面使用 bool 修饰符来改变布尔运算的默认行为。使用 bool 修改符后，布尔运算不会对时间序列进行过滤，而是直接依次瞬时向量中的各个样本数据与标量的比较结果 0 或者 1。

        在两个标量之间进行布尔运算，必须提供 bool 修饰符，得到的结果也是标量，即 0（false） 或 1（true）。

集合运算符

and

并且

or

或者

unless

排除

        a and b 会产生一个由 a 的元素组成的新的向量。该向量包含 a 中完全匹配 b  中的元素组成。

        a or b 会产生一个新的向量，该向量包含 a 中所有的样本数据，以及 b 中没有与 a  匹配到的样本数据。

        a unless b 会产生一个新的向量，新向量中的元素由 a 中没有与 b 匹配的元素组成。

聚合操作

        Prometheus 还提供了下列内置的聚合操作符，这些操作符作用域瞬时向量。可以将瞬时表达式返回的样本数据进行聚合，形成一个具有较少样本值的新的时间序列。

sum (求和)	min (最小值)	max (最大值)	avg (平均值)	stddev (标准差)
count (计数)	bottomk (样本值最小的 k 个元素)	topk (样本值最大的k个元素)	quantile (分布统计)	stdvar (标准差异)

        在 Prometheus 系统中，二元运算符优先级从高到低的顺序如下。

"^" > "*", "/", "%" > "+","-" > "==", "!=", "<=", "<", ">=", ">" > "and", "unless" > "or"

        具有相同优先级的运算符是满足结合律的（左结合）。

        本来还有内置函数等一些知识，但因为不是很了解，所以这里就略过了。

Alertmanager

        告警能力在 Prometheus 的架构中被划分成两个独立的部分。如下所示，通过在 Prometheus中定义 AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向 Alertmanager 发送告警信息。

​

        在 Prometheus 中一条告警规则主要由以下几部分组成。

        1、告警名称。用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容

        2、告警规则。告警规则实际上主要由 PromQL 进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警

        在 Prometheus 中，还可以通过Group（告警组）对一组相关的告警进行统一定义。当然这些定义都是通过 YAML 文件来统一管理的。

        Alertmanager 作为一个独立的组件，负责接收并处理来自 Prometheus Server (也可以是其它的客户端程序)的告警信息。Alertmanager 可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus 内置了对邮件，Slack 等多种通知方式的支持，同时还支持与 Webhook的集成，以支持更多定制化的场景。例如，目前 Alertmanager 还不支持钉钉，那用户完全可以通过 Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。

特性

        Alertmanager除了提供基本的告警通知能力以外，还主要提供了如：分组、抑制以及静默等告警特性：

​

分组

        分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。

        例如，当集群中有数百个正在运行的服务实例，并且为每一个实例设置了告警规则。假如此时发生了网络故障，可能导致大量的服务实例无法连接到数据库，结果就会有数百个告警被发送到Alertmanager。

        而作为用户，可能只希望能够在一个通知中中就能查看哪些服务实例收到影响。这时可以按照服务所在集群或者告警名称对告警进行分组，而将这些告警内聚在一起成为一个通知。

        告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。

抑制

        抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。

        例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。

        抑制机制同样通过 Alertmanager 的配置文件进行设置。

静默

        静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager 则不会发送告警通知。

        静默设置需要在 Alertmanager 的 Werb 页面上进行设置。

自定义报警规则

        一条典型的告警规则如下所示。

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency
      description: description info

        在告警规则文件中，我们可以将一组相关的规则设置定义在一个 group 下。在每一个 group中我们可以定义多个告警规则(rule)。一条告警规则主要由以下几部分组成：

        alert

        告警规则的名称。

        expr

        基于 PromQL 表达式告警触发条件，用于计算是否有时间序列满足该条件。

        for

        评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为 pending。

        labels

        自定义标签，允许用户指定要附加到告警上的一组附加标签。

        annotations

        用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations 的内容在告警产生时会一同作为参数发送到 Alertmanager。

        为了能够让 Prometheus 能够启用定义的告警规则，我们需要在 Prometheus 全局配置文件中通过 rule_files 指定一组告警规则文件的访问路径，Prometheus 启动后会自动扫描这些路径下规则文件中定义的内容，并且根据这些规则计算是否向外部发送通知。

rule_files:
  [ - <filepath_glob> ... ]

        默认情况下Prometheus会每分钟对这些告警规则进行计算，如果用户想定义自己的告警计算周期，则可以通过 evaluation_interval 来覆盖默认的计算周期。

global:
  [ evaluation_interval: <duration> | default = 1m ]

        在 Prometheus 配置文件中引用报警规则。

  ```yaml
  rule_files:
    - "alert.rules.yml"
  ```

        后面还有一些安装、配置、运行等内容，但我自己还没学到，所以先到这里，下面有文档链接，大家想了解可以去文档里学习。

第1章 天降奇兵 · Prometheus中文技术文档