配置 Prometheus
Prometheus 通过 YAML 文件来配置。当运行 Prometheus 二进制文件时，我们会指定一个配置文件。Prometheus 自带默认的配置文件 prometheus.yml。
- Prometheus 默认的配置文件去掉注释后，内容如下
1 | global: |
我们的默认配置文件中定义了 4 个 YAML 块: global, alerting, rule_files 和 scrape_configs。
接下来我们来看一下每个块的内容
global
配置的第一部分是 global，它包含了控制 Prometheus 服务器行为的全局配置。
scrape_interval: 指定应用程序或服务抓取数据的时间间隔，默认是 15s。这个值是时间序列的颗粒度，即该序列中每个数据点所覆盖的时间段。建议仅设置抓取间隔为全局参数以保持颗粒度一致！
evaluation_interval: 用来指定 Prometheus 评估规则的评率。目前主要有两种规则：记录规则（recording rule）和警报规则（alerting rule）。- 记录规则: 允许预先计算使用频繁且开销大的表达式，并将结果保存为一个新的时间序列数据；
- 警报规则: 允许定义警报条件.
根据这个参数，Prometheus 将每隔 15 秒重新评估这些规则。
alerting
配置的第二部分是 alerting，它用来设置 Prometheus 的警报。正如我们在之前提到的，警报是由名为 Alertmanager 的独立工具进行管理的。Alertmanager 是一个可以集群化的独立警报管理工具。
- Alertmanager 相关的配置
1 | alerting: |
在默认的配置中，alerting 部分包含服务器的警报配置，其中 alertmanagers 块会列出 Prometheus 服务器使用的每个 Alertmanager，static_configs 块表示我们要手动的指定在 targets 数组中配置的 Alertmanager。
Prometheus 还支持 Alertmanager 的服务发现功能。例如，可以通过查询外部源（如 Consul服务器）来返回可用的 Alertmanager 列表。而不是单独指定每个 Alertmanager。
上述例子中，我们没有定义 Alertmanager，而是有一行注释的alertmanager:9093。我们可以暂时不处理这个注释，因为目前并不需要特别定义一个 Alertmanager 来运行 Prometheus。后面将添加一个 Alertmanager 并对其进行配置。
rule_files
配置的第三部分是 rule_files，它用来指定包含记录规则或警报规则的文件列表。我们将在后面对它进行一些配置
scrape_configs
配置的最后一部分是 scrape_configs，用来指定 Prometheus 抓取的所有目标。
- Prometheus 的默认抓取配置如下
1 | scrape_configs: |
默认配置中定义了一个作业 prometheus，它的 static_configs 参数部分列出了要抓取的目标，这些特定的目标被单独列出来，而不是通过自动服务发现。你也可以将静态配置理解为手动或人工服务发现。
作业 prometheus 只有一个监控目标：Prometheus 服务器自身。它从本地的 9090 端口抓取数据并返回服务器的健康指标。Prometheus 假设抓取的指标将返回到 /metrics 路径下，因此它会被追加到目标中，然后抓取地址 http://localhost:9090/metrics。
指标示例
启动 Prometheus 服务器之后，我们来看看正在抓取的端点和一些原始的 Prometheus 指标。为此，我们可以浏览 http://localhost:9090/metrics 并查看返回的内容。
在所有示例中，我们假设正在查看的是运行 Prometheus 的服务器，即本地服务器。
- 原始的指标示例，如下
1 | # HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. |
这里可以看到你的第一个 Prometheus 指标，它们看起来很像我们之前见到的数据模型
1 | go_gc_duration_seconds{quantile="0.5"} 0.000246489 |
这个指标的名称是 go_gc_duration_seconds，里面有一个标签 quantile="0.5"，表示这衡量的是第 50 百分位数，后面的数字是这个指标的值。
表达式浏览器
由于上述查看指标的方式对用户不是很友好，所以我们可以使用 Prometheus 的内置表达式浏览器来查看，其可以通过在 Prometheus 服务器上浏览 http://localhost:9090/graph 来查看。
首先让我们使用表达式浏览器找出 go_gc_duration_seconds 指标。你可以打开可用指标的下拉列表来查找，也可以在查询框中键入指标名称，然后单击 Execute 按钮得到具有这个名称的所有指标。如下图
在这个指标列表中，每个指标都使用一个或多个标签来进行描述，我们需要找到表示第 50 百分位数的标签，如下
1 | go_gc_duration_seconds{instance="localhost:9090", job="prometheus",quantile="0.5"} |
我们可以看到，两个新标签已添加到指标上，这是 Prometheus 在抓取过程中自动完成的。第一个新标签 instance 是我们抓取指标的目标，第二个标签 job 则是抓取指标的作业名称。标签为指标提供了不同的维度，允许我们查询或使用单个/多个指标。
Prometheus 在服务器中内置了一种名为 PromQL 的高度灵活的表达式语言，允许查询和聚合指标。我们可以在浏览器界面顶部的查询输入框中使用此查询语言。
在上图中，我们查询了所有带有 quantile="0.5" 标签的指标，并返回了可能的1个结果。这个数据集是 PromQL 查询语言中的表达式可以返回的四种数据类型之一。此类型称为即时向量（instant vector）：一组包含每个时间序列的单个样本的时间序列集合，其中所有时间序列都共享相同的时间戳。还可以通过查询指标的名称和标签来返回它的即时向量。
接下来我们查询指标 go_gc_duration_seconds，但这次是第 75 百分位。在输入框输入以下信息
1 | go_gc_duration_seconds{quantile="0.75"} |
然后单击 Execute 进行搜索，它应该返回与查询内容匹配的即时向量。我们也可以使用正则表达式来过滤或匹配标签。如下所示：
1 | go_gc_duration_seconds{quantile!="0.75"} |
这将返回所有百分位数不等于 0.75 的指标的即时向量。
查询语法
- 官方文档: QUERYING PROMETHEUS
- 数据类型: Expression language data types
聚合时间序列
在上述查询界面中还可以进行指标的复杂聚合。我们选择另一个指标 promhttp_metric_handler_requests_total 看一下，它是 Prometheus 服务器中抓取数据所产生的的 HTTP 请求总数。现在通过指定其名称并单击 Execute 来查询，如下图所示
查询结果会返回一个 HTTP 请求指标列表，但我们真正想要的是每个作业的 HTTP 请求总数，为此，我们需要通过查询语句来创建新的指标。Prometheus 的查询语言 PromQL 具有大量的表达式和函数，可以帮助我们实现这一目标.
让我们从按作业汇总 HTTP 请求开始。将以下内容添加到查询框中，然后单击 Execute。
1 | sum(promhttp_metric_handler_requests_total) |
这个查询使用了 promhttp_metric_handler_requests_total 指标的 sum() 运算符，它对所有请求进行了累加，但没有按作业分类。为此，我们需要根据特定的标签维度进行聚合。PromQL 有一个子句 by，它允许按照特定的维度聚合。将以下类容添加到查询框中，然后单击 Execute。
1 | # 按作业 聚合 |
输入如下：
PromQL 还有一个子句
without，可以不按特定维度进行聚合
现在单击 Graph 选项，将这个查询结果显示为一张图。
根据上述结果，新的输出仍然不是很有用。让我们把它转换成一个速率，将查询语句更新为
1 | sum(rate(promhttp_metric_handler_reuqests_total[5m])) by (instance) |
这里我们添加了一个新函数 rate()，将它插入到 sum() 函数中。
1 | rate(promhttp_metric_handler_reuqests_total[5m]) |
rate() 函数用来计算一定范围内时间序列的每秒平均增长率，只能与计数器一起使用。它非常聪明且可以自适应，例如在资源重启时会重置计数器，并且通过推断来处理时间序列中的间隔，例如一次漏掉的数据抓取。rate() 函数最适合用于增长较慢的计数器或用于警报的场景。
还有一个
irate()函数可以计算增长较快的计时器的瞬时增长率。
这里我们计算 5分钟范围向量的速率。范围向量（range vector）是第二个 PromQL 数据类型，它包含一组时间序列，其中每个时间序列都包含一系列数据点。范围向量允许我们显示该时间段的时间序列，持续时间被包含在中括号中，内容是一个整数值后跟一个单位缩写，其中单位缩写如下：
- s: 表示秒
- m: 表示分
- h: 表示小时
- d: 表示天
- w: 表示周
另外两个 PromQL 数据类型是 Scalars（数字浮点值）和 String（字符串值，且暂未使用）。
接下来执行该查询并查看时间序列的结果范围向量。如下图
如果在构建 PromQL 查询方面需要帮助，则可以使用查询编辑器 Promeditor，它可以在 Prometheus 本地运行。
参考文档
容量规划
Prometheus 的性能很难估计，因为它在很大程度上取决于你的配置，所需收集的时间序列的数量以及服务器上规则的复杂性。一般容量规划关注两个问题：内存和磁盘。
内存
Prometheus 在内存中做了很多工作。每个收集的时间序列，查询和记录规则都会消耗进程内存。关于 Prometheus 的容量规划的参考数据并不多，但一个有用的，粗略的经验法则是将每秒采集的样本数乘以样本的大小。我们可以使用以下查询来查看样本收集率
1 | rate(prometheus_tsdb_head_samples_appended_total[1m]) |
这将显示你在最后一分钟添加到数据库的每秒样本率。如果想知道收集的指标数量，则可以使用以下语句
1 | sum(count by (__name__) ({__name__ =~ ".+"})) |
这里使用 sum() 聚合来计算所有匹配的指标的计数和，使用 =~ 运算符和 .+ 的正则表达式来匹配所有指标。
每个样本的大小通常为 1 到 2 个字节，让我们谨慎一点，按照 2 个字节计算。假设在 12 个小时内每秒收集 100000 个样本，那么我们可以像下面这样计算内存使用情况：
1 | 100000 * 2 bytes * 43200 seconds |
结果大概是 8.64 GB 的内存。
你还可以考虑在查询和记录规则方面的的内存使用情况。这个不太好计算，并且依赖于许多其他变量，建议根据内存使用情况灵活调整。可以通过检查 process_resident_memory_bytes 指标来查看 Prometheus 进程的内存使用情况。
磁盘
磁盘使用量受存储的时间序列数量和这些时间序列的保留时间限制。默认情况下，指标会在本地时间序列数据库中存储 15 天。数据库的位置和保留时间由命令行选项控制。
--storage.tsdb.path选项: 它的默认数据目录位于运行 Prometheus 的目录中，用于控制时间序列数据库位置。--storage.tsdb.retention选项: 控制时间序列的保留期。默认值为15d，代表15天。
建议采用SSD作为时间序列数据库的磁盘。
对于每秒10万个样本的示例，我们知道按时间序列收集的每个样本在磁盘上占用大约1到2个字节。假设每个样本有2个字节，那么保留15天的时间序列意味着需要大约 259 GB的磁盘。
有关Prometheus磁盘使用情况的更多信息，请参见 存储文档