《Prometheus监控实战》笔记【一到三章】

本文内容为书籍《Prometheus监控实战》的读书笔记，书籍链接Prometheus监控实战 (豆瓣)

一 监控简介

1 监控的两个客户：

• 技术  了解技术状况，诊断技术问题
• 业务  支撑业务持续发展

2 监控是管理基础设施和业务的核心工具

• 全局视角，从最高层（业务）依次展开。
• 协助故障诊断。
• 作为基础设施、应用程序开发和业务人员的信息源。
• 内置于应用程序设计、开发和部署的生命周期中。
• 尽可能自动化，并提供自服务

3 监控方式

• 探针/黑盒：在应用程序的外部，它查询应用程序的外部特征：监听端口是否有响应并返回正确的数据或状态码。探针监控的一个例子是执行ICMP检查并确认可以收到响应。
• 内省/白盒：主要查看应用程序内部的内容。应用程序经过检测，并返回其状态、内部组件，或者事务和事件性能的度量

4 监控执行方式

• 拉取（pull）提取或检查远程应用程序——例如包含指标的端点，或是探针监控中使用ICMP进行的检查。
• 推送（push）应用程序发送事件给监控系统接收

Prometheus主要是一个基于拉取的系统，但它也支持接收推送到网关的事件

5 监控数据类型  

• 指标：依赖指标来帮助了解系统的情况。指标存储为时间序列数据，用于记录应用程序度量的状态。
• 日志：日志是从应用程序发出的（通常是文本的）事件。同样用于故障的诊断。

6 指标

Prometheus中指标变成了监控工作流程中最重要的部分。颠覆了以故障检测为中心的模型。通过异常检测和模式分析，指标有可能在故障发生之前就有所察觉。

指标是软件或硬件组件属性的度量。为了使指标有价值，通常记录一段时间内的数据点。这些数据点称为观察点（observation），观察点通常包括值、时间戳，有时也涵盖描述观察点的一系列属性（如源或标签）。观察的集合称为时间序列。

通常以固定的时间间隔收集数据，该时间间隔被称为颗粒度（granularity）或分辨率
（resolution）

7 指标类型

测量型（gauge）： 上下增减的数字，如CPU使用率

计数型（counter）：随时间增加不会减少，如系统运行时间，收发包字节数，优势是可以计算变化率

直方图（histogram）：是对观察点进行采样的指标类型，可以展现数据集的频率分布。数据分组
被称为“分箱”（binning）

摘要型（summary）：类似直方图，会计算百分位数

8 指标摘要与聚合

摘要：如计数，求和，平均值，中间数，百分位数，标准差，变化率

聚合：多个指标

*百分位数：百分位数度量的是占总数特定百分比的观察点的值。

9 监控方法论

USE方法：用于主机监控，使用率（Utilization）、饱和度（Saturation）和错误（Error）

谷歌四个黄金指标：用于应用监控，延迟、流量、错误、饱和度

10 警报和通知

• 使通知清晰、准确、可操作。使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异。
• 为通知添加上下文。通知应包含组件的其他相关信息。
• 仅发送有意义的通知。最简单的建议是记住“通知是供人而不是计算机阅读的”

二 prometheus简介

1  起源

Prometheus的灵感来自谷歌的Borgmon，主要用于提供近实时的、基于动态云环境和容器的微服务、服务和应用程序的内省监控。也用来监控传统架构的资源，专注于现在正在发生的事情，而不是追踪数周或数月前的数据，反映在强大的查询语言和通常有限的监控数据保留期上

2 架构：

2.1官网架构图：

2.2 概述

Prometheus通过抓取或拉取应用程序中暴露的时间序列数据来工作。时间序列数据通常由应用程序本身通过客户端库或称为exporter（导出器）的代理来作为HTTP端点暴露。Prometheus还有一个推送网关（push gateway），可用于接收少量数据——例如，来自无法拉取的目标数据（如临时作业或者防火墙后面的目标）。简化架构图：

2.3 指标收集

Prometheus称其可以抓取的指标来源为端点（endpoint），为了抓取端点数据，Prometheus定义了名为目标（target）的配置。一组目标被称为作业（job）。作业通常是具有相同角色的目标组。生成的时间序列数据将被收集并存储在Prometheus服务器本地，也可以设置从服务器发送数据到
外部存储器或其他时间序列数据库

2.4 服务发现

通过多种方式来处理要监控的资源的发现，包括：

• 用户提供的静态资源列表。
• 基于文件的发现。
• 自动发现。

2.5 聚合与警报

• 可以创建规则来记录常用的查询和聚合时间序列数据
• 可以定义警报规则。这些是为系统配置的在满足条件时触发警报的标准，将警报从Prometheus服务器推送到名为Alertmanager（警报管理器）的单独服务器

2.6 查询数据与自治，可视化

• 提供了一套内置查询语言PromQL、一个表达式浏览器以及一个用于浏览服务器上数据的图形界面。
• 数据存储格式被设计为尽可能降低磁盘的使用率，并在查询和聚合期间快速检索时间序列。充分使用内存（Prometheus在内存中做很多事）和SSD磁盘。
• 可视化通常与开源仪表板Grafana集成。

2.7 冗余与高可用

侧重弹性而非数据持久性，确实要部署高可用HA模式，则可以使用两个或多个配置相同的Prometheus服务器来收集时间序列数据，并且所有生成的警报都由可消除重复警报的高可用Alertmanager集群来处理。

3 数据模型

3.1 模型

多维时间序列数据模型，结合了时间序列名称和称为标签（label）的键/值对

• 时间序列名称 通常描述收集的时间序列数据的一般性质
• 标签为Prometheus数据模型提供了维度。它们为特定时间序列添加上下文 ，分为插桩标签（instrumentation label）和目标标签（target label）。插桩标签来自被监控的资源；目标标签由Prometheus在抓取期间和之后添加。

注意：如果在时间序列中添加或更改标签，那么Prometheus会将其视为新的时间序列。带有__前缀的标签名称保留给Prometheus内部使用

3.2 数据

时间序列的真实值是采样（sample）的结果，它包括两部分：

• 一个float64类型的数值
• 一个毫秒精度的时间戳

时间序列表示为符号（notation）：

 例子：

首先是时间序列名称，后面跟着一组键/值对标签。通常所有时间序列都有一个instance标签（标识源主机或应用程序）以及一个job标签（包含抓取特定时间序列的作业名称）

3.3 存储与访问

Prometheus专为短期监控和警报需求而设计。默认情况下，它在其数据库中保留15天的时间序列
数据。如果要保留更长时间的数据，则建议将所需数据发送到远程的第三方平台。Prometheus能够写入外部数据存储

在安全上：

• 不受信任的用户将能够访问Prometheus服务器的HTTP API，从而访问数据库中的所有数据。
• 只有受信任的用户才能访问Prometheus命令行、配置文件、规则文件和运行时配置。Prometheus及其组件不提供任何服务器端的身份验证、授权或加密。

3.4 生态系统

Prometheus服务器： 核心

Alertmanager：为Prometheus提供警报引擎并进行管理

Exporter ：用于监控应用程序和服务，并在端点上公开相关指标以进行抓取。

客户端库 ：支持监控由多种语言编写的应用程序和服务

三 安装与启动

1 安装

可直接二进制包安装，

promtool是自带的代码校验工具，使用方式：

promtool check config prometheus.yml

 检查版本：

prometheus --version 

2 配置信息

通过YAML文件配置，在线解析可通过 YAMLlint - The YAML Validator

例子如下：

 2.1 global

scrape_interval用来指定应用程序或服务抓取数据的时间间隔，即时间序列的颗粒度

evaluation_interval用来指定Prometheus评估规则的频率。目前主要有两种规则：记录规则
（recording rule）和警报规则（alerting rule）

• 记录规则：允许预先计算使用频繁且开销大的表达式，并将结果保存为一个新的时间序列数据。
• 警报规则：允许定义警报条件。

 2.2 alerting

alertmanagers块会列出Prometheus服务器使用的每个Alertmanager;static_configs块表示我们要手动指定在targets数组中配置的Alertmanager，也支持服务发现功能

2.3 rule_files

用来指定包含记录规则或警报规则的文件列表 

2.4 scrape_configs

用来指定Prometheus抓取的所有目标.rometheus将它抓取的指标的数据源称为端点;这个目标里包含的信息是抓取数据所必需的，比如用到的标签、建立连接所需的身份验证，或者其他定义数据抓取的信息。若干目标构成的组称为作业，作业里每个目标都有一个名为实例（instance）的标签，用来唯一标识这个目标。

3 检查配置与启动：

promtool check config /etc/prometheus/prometheus.yml
prometheus --config.file "/etc/prometheus/prometheus.yml"

 浏览 http://localhost:9090/metrics 可以查看返回内容

其中一行指标的名称是go_gc_duration_seconds，里面有一个标签quantile="0.5"，表示这衡量的是第50百分位数，后面的数字是这个指标的值。

即时向量（instantvector）：一组包含每个时间序列的单个样本的时间序列集合，其中所有时间序列都共享相同的时间戳。可以通过查询指标的名称和标签来返回它的即时向量

4 数据展示

 浏览 http://localhost:9090/graph 可以浏览数据，

两个新标签已添加到指标上，这是Prometheus在抓取过程中自动完成的。第一个新
标签instance是我们抓取指标的目标，第二个标签job则是抓取指标的作业名称。

通过指标将信息传递到Prometheus服务器的常见模式，它使用恒定值为1的指标，并且添加了可能希望通过标签附加的相关信息。

Prometheus在服务器中内置了一种名为PromQL的高度灵活的表达式语言，允许查询和聚合指
标。我们可以在浏览器界面顶部的查询输入框中使用此查询语言。

5 聚合时间序列

如计算5分钟范围向量的速率：

 sum(rate(promhttp_metric_handler_requests_total[5m])) by (job)

范围向量（range vector）是第二个PromQL数据类型，它包含一组时间序列，其中每个时间序列都包含一系列数据点。范围向量允许显示该时间段的时间序列，持续时间被包含在中括号[ ]中，内容是一个整数值后跟一个单位缩写，其中单位缩写：

• ·s表示秒
• ·m表示分钟
• ·h表示小时
• ·d表示天
• ·w表示周

还有两种数据类型是Scalars（数字浮点值）和Strings（字符串值） 

6 硬件规划

内存：一个有用的、粗略的经验法则是将每秒采集的样本数乘以样本的大小。每个样本的大小通常为1到2个字节，让我们谨慎一点，按照2个字节计算。假设在12小时内每秒收集100 000个样本，那可以像下面这样计算内存使用情况：

结果大概是8.64GB的内存。

磁盘：数据库的位置和保留时间由命令行选项控制。
·--storage.tsdb.path选项：它的默认数据目录位于运行Prometheus的目录中，用于控制时间序列数
据库位置。
·--storage.tsdb.retention选项：控制时间序列的保留期。默认值为15d，代表15天。

每秒10万个样本的示例，我们知道按时间序列收集的每个样本在磁盘上占用大约1到2个字节。假设每个样本有2个字节，那么保留15天的时间序列意味着需要大约259 GB的磁盘。