Prometheus配置与管理全解析

### Prometheus 配置与管理全解析 #### 1. 配置文件路径设置 通常，设置 Prometheus 配置文件路径非常重要，可通过 `--config.file` 标志来完成。默认情况下，Prometheus 会在当前工作目录中查找名为 `prometheus.yml` 的文件。对于本地测试而言，这种默认设置很方便，但在生产部署中，服务器二进制文件和配置文件通常存放在各自的路径下，因此这个标志经常会被用到。需要注意的是，配置文件路径和存储目录是启动 Prometheus 服务器的硬性要求；没有配置文件，Prometheus 将拒绝启动。 #### 2. 存储配置 同样，需要使用 `--storage.tsdb.path` 标志来配置数据存储的基础路径。默认情况下，该路径为当前工作目录下的 `data/`，建议将其指向更合适的路径，比如不同的驱动器或卷，这样可以安全地持久化数据并减少 I/O 争用。需要注意的是，NFS（包括 AWS EFS）不被支持，因为它不支持安全管理数据库文件所需的 POSIX 锁定原语。将 Prometheus 数据存储目录放在网络共享中也不可取，因为短暂的网络故障可能会影响监控系统的正常运行，而这恰恰是你最需要它的时候。 Prometheus 本地存储一次只能由一个 Prometheus 实例写入。为确保这一点，它会在数据目录中使用一个锁文件。启动时，它会使用特定于操作系统的系统调用来锁定该文件，如果该文件已被其他进程锁定，则拒绝启动。 不过，在使用持久卷存储数据目录时，可能会出现一种特殊情况：当使用相同的卷以另一个容器实例重新启动 Prometheus 时，前一个实例可能没有解锁数据库。这可能会导致竞态条件。幸运的是，可以使用 `--storage.tsdb.no-lockfile` 标志来处理这种情况。但要注意，在大多数 Prometheus 部署中，禁用锁文件通常不是一个好主意，因为这更容易导致意外的数据损坏。 #### 3. Web 配置 接下来，需要配置用户访问 Prometheus 服务器的地址。`--web.external-url` 标志用于设置基本 URL，这样在 Web 用户界面和传出警报中生成的链接才能正确指向 Prometheus 服务器。这可能是负载均衡器或反向代理的 DNS 名称、Kubernetes 服务，或者在最简单的部署中，是运行服务器的主机的公共可访问的完全限定域名。 Prometheus 服务器在收到 SIGHUP 信号时，会像传统的 *nix 守护进程一样重新加载其配置文件（以及规则文件）。但在某些情况下，发送此信号可能不方便（例如，在 Kubernetes 等容器编排系统中运行或使用自定义自动化时），甚至不可能（在 Windows 上运行 Prometheus 时）。在这些情况下，可以使用 `--web.enable-lifecycle` 标志来启用 `/-/reload` 和 `/-/quit` HTTP 端点，分别用于控制、重新加载和关闭服务器。为防止意外触发这些端点，并且由于 GET 请求在语义上不正确，需要使用 POST 请求。此标志默认关闭，因为无限制地访问这些端点会带来安全风险。 同样，`--web.enable-admin-api` 标志默认也关闭，原因相同。该标志启用的 HTTP 端点可提供一些高级管理操作，如创建数据快照、删除时间序列和清理墓碑。 官方的 Prometheus 压缩包还包含两个额外的目录 `consoles` 和 `console_libraries`，用于启用 Prometheus 的原生仪表盘功能，但这一功能常被忽视。这些目录包含一些预配置的仪表盘（称为控制台）和支持模板库，使用 Go 模板语言编写。可以使用 `--web.console.templates` 和 `--web.console.libraries` 标志来配置 Prometheus 加载这些文件。之后，这些仪表盘将在 `/consoles` 端点可用（如果存在 `index.html` 文件，主 Web UI 中将提供链接）。 #### 4. 查询配置 此部分主要用于调整查询引擎的内部工作方式。一些配置比较容易理解，例如 `--query.timeout` 用于设置查询在被中止前可以运行的最长时间，`--query.max-concurrency` 用于设置可以同时运行的查询数量。 但有两个配置设置的限制可能会产生不明显的后果。第一个是 `--query.max-samples`，它在 Prometheus 2.5.0 中引入，用于设置可以加载到内存中的最大样本数。这是为了限制查询子系统使用的最大内存（结合 `--query.max-concurrency`），以防止可怕的“死亡查询”，即查询加载过多数据到内存中，导致 Prometheus 达到内存限制并终止进程。在 2.5.0 之后，如果任何查询达到此标志设置的限制（默认值为 50,000,000 个样本），查询将直接失败。 第二个是 `--query.lookback-delta`，它设置了 Prometheus 在将时间序列数据点视为过时之前，会向前查找的最大时间范围。这意味着，如果数据收集间隔大于此处设置的值（默认值为五分钟），警报和图表可能会出现不一致的结果。因此，允许失败的最大合理值为两分钟。 #### 5. Prometheus 配置文件详解 配置文件声明了 Prometheus 实例的运行时配置，包括抓取作业、规则评估和远程读写配置等。这些配置可以在不关闭 Prometheus 服务器的情况下重新加载，方法是向进程发送 SIGHUP 信号，或者在启动时使用 `--web.enable-lifecycle` 标志后，发送 HTTP POST 请求到 `/-/reload` 端点。 配置文件大致可分为以下几个部分： - `global` - `scrape_configs` - `alerting` - `rule_files` - `remote_read` - `remote_write` 以下是一个示例配置： ```yaml global: scrape_interval: 1m ... scrape_configs: - job_name: 'prometheus' scrape_interval: 15s scrape_timeout: 5s sample_limit: 1000 static_configs: - targets: ['localhost:9090'] metric_relabel_configs: - source_labels: [ __name__ ] regex: expensive_metric_.+ action: drop ``` ##### 5.1 全局配置 全局配置定义了其他配置部分的默认参数，并设置了要添加到发送到外部系统的指标或警报上的标签。示例如下： ```yaml global: scrape_interval: 1m scrape_timeout: 10s evaluation_interval: 1m external_labels: dc: dc1 prom: prom1 ``` 持续时间只能是整数值，且只能有一个单位。例如，使用 0.5 分钟而不是 30 秒，或者使用 1 分 30 秒而不是 90 秒，都将被视为配置错误。 `scrape_interval` 设置了抓取目标的默认频率，通常在 10 秒到 1 分钟之间，默认的 1 分钟是一个不错的保守起始值。较长的间隔不可取，因为丢失的粒度（尤其是在计量器中）会影响对问题的正确警报能力，并且查询会变得棘手，因为需要注意某些较短的间隔可能不会返回数据。此外，考虑到默认的回溯时间为五分钟，如果抓取间隔超过 150 秒（2 分 30 秒），那么如果单次抓取失败，给定目标的每个时间序列都将被视为过时。 `scrape_timeout` 定义了 Prometheus 在关闭连接并将抓取标记为失败