16 Prometheus 之 Exporter 详解

我们通常可以将 Exporter 分为两类：

直接采集型：这类 Exporter 直接内置了相应的应用程序，用于向 Prometheus 直接提供 Target 数据支持。这样设计的好处是，可以更好地监控各自系统的内部运行状态，同时也适合更多自定义监控指标的项目实施。例如 cAdvisor、Kubernetes 等，它们均内置了用于向 Prometheus 提供监控数据的端点。

间接采集型：原始监控目标并不直接支持 Prometheus，需要我们使用 Prometheus 提供的 Client Library 编写该监控目标的监控采集程序，用户可以将该程序独立运行，去获取指定的各类监控数据值。例如，由于 Linux 操作系统自身并不能直接支持 Prometheus，用户无法从操作系统层面上直接提供对 Prometheus 的支持，因此单独提供 Node exporter，还有数据库或网站 HTTP 应用类等 Exporter。

Exporter 收集的数据值转化成文本内容展示。Prometheus 基于文本的格式是面向行的。行由换行符（\n）分隔，最后一行必须以换行符结尾，空行被忽略，以 #开始的行通常都是注释内容。这些样本数据集合说明如下：

• 以 #HELP 开始的行，表示 metric 的帮助与说明注释，可以包含当前监控指标名称和对应的说明信息。

• 以 #TYPE 开始的行，表示定义 metric 类型，可以包含当前监控指标名称和类型，类型有 Counter、Gauge、Histogram、Summary 和 Untyped。

• 以非 #开始的行，即监控样本数据。

• 其他一般性注释，方便阅读使用，会被 Prometheus 忽略。

可以在 Prometheus 官网https://prometheus.io/docs/instrumenting/exporters/里看到常用的 Node/system metrics exporter（official）和 MySQL server exporter（official）。在这些 Exporter 的名称末尾都标示了（official），即官方进行维护的 Exporter。我们也可以直接到 Prometheus GitHub 官网https://github.com/prometheus上获取对应的 Exporter 最新版本。

YAML 是一种类似 XML、JSON 的标记性语言，其基本语法规则如下：

• 大小写敏感。

• 使用缩进完成层级关系展示。

• 缩进时不允许使用 Tab 键，只允许使用空格。

• 缩进的空格数目不重要（通常 2 或 4 个空格），只需要相同层级左对齐即可。

在 Prometheus 安装后，官方会提供一个默认的 prometheus.yml 文件，其中包含 global 的默认配置内容，主要有以下四个参数：

• scrape_interval，每次数据采集的时间间隔，默认为 1 秒。

• scrape_timeout，采集请求超时时间，默认为 10 秒。

• evaluation_interval，执行 rules 的频率，默认为 1 秒。

• external_labels，与外部系统通信时添加到任意时间序列或告警用的外部标签。

scrape_configs 主要用于配置被采集数据节点操作，每一个采集配置主要有以下几个参数：

• job_name，全局唯一名称。

• scrape_interval，默认等于 global 内设置的参数值，设置后可以覆盖 global 中的值。

• scrape_timeout，默认等于 global 内设置的参数值。

• metrics_path，从 targets 获取 metric 的 HTTP 资源路径，默认是/metrics。

• honor_labels，Prometheus 如何处理标签之间的冲突。若设置为"true"，则通过保留标签来解决标签冲突进行数据值采集。若设置为"false"，则通过重命名来解决标签冲突，以 exported_<original-label>格式采集数据值，例如 exported_job 形式，默认是"false"。

• scheme，用于请求的协议方式，默认是 http。

• params，数据采集访问时 HTTP URL 设定的请求参数。

• relabel_configs，采集数据重置标签配置。

• metric_relabel_configs，metric 重置标签配置。

• sample_limit，对每个被已知样本（sample）数量的每次采集进行限制，如果超过限制，该数据将被视为失败。默认值为 0，表示无限制。

对 CPU 数据进行采集的主要监控指标是 node_cpu_seconds_total。node_cpu_seconds_total 是一个计数器，即此类 metric 是 Counter 类型，用来标识每核 CPU 各个模式下占用的时间。它的标签（Label）是 cpu 和 mode。

对内存数据的采集涉及与内存相关的所有监控指标，这些数据来源于 Linux 系统中的/proc/meminfo 文件。node_memory_MemTotal_bytes 是一个常规的计量器或测量器 metric，它是 Gauge 类型。

对磁盘数据采集的所有监控指标来源于 Linux 系统中的/proc/diskstats 文件。使用 node_disk_开始的 metric。

与文件系统采集相关的所有 metric 都以“node_filesystem_”开始，标签使用了 3 个：device，fstype，mountpoint。所有数据类型均为 Gauge。

与网络采集相关的所有 metric 都以“node_network_”开始，可分为发送和接收两类，标签都使用了 device，所有数据类型均为 Counter。其中 node_network_receive_bytes_total 和 node_network_transmit_bytes_total 两个 metric 是我们主要关注的监控指标，可以利用它们来计算网络带宽使用情况。

MySQL 数据库的性能状态监控内容非常多，但通常必不可少的内容包括查询吞吐量（Query throughput）、查询执行性能（Query execution performance）、连接情况（Connections）和缓冲池使用情况（Buffer pool usage）这四个与基本的性能和资源利用率相关的指标。

MySQL 有一个名为 Questions 的内部计数器，MySQL 术语为“服务器状态变量”。对于客户端应用程序发送的所有语句，该计数器都是递增的。对应 mysqld_exporter 采集后再返回的样本数据中，使用 mysql_global_status_questions 展示当前的 Questions 大小。

关于查询执行性能表现方面，可以使用 MySQL 提供的 Slow_queries 计数器，每当查询的执行时间超过 long_query_time 参数指定的秒数时，计数器就会增加。对应 mysqld_exporter 采集后再返回的样本数据中，使用 mysql_global_status_slow_querie。

为了防止 MySQL 服务器的过载运行，数据库管理员需要根据业务量进行预评估，以便限制客户端连接 MySQL 的数量。对应 mysqld_exporter 采集后再返回的样本数据中，使用 mysql_global_status_slow_queries。

数据库管理需要查看 MySQL 当前实例的连接数，即 Threads_connected 数值，可使用 MySQL 提供的命令进行查询。对应 mysqld_exporter 采集后再返回的样本数据中，使用 mysql_global_status_slow_querie。

当 MySQL 默认的存储引擎是 InnoDB 时，会使用缓冲池来缓存表和索引的数据。即便是初级数据库管理员，在部署 MySQL 实例时，也会提前预估并在 my.cnf 文件中配置参数 innodb_buffer_pool_size。这是 InnoDB 最重要的参数，主要作用是缓存 innodb 表的索引、数据和插入数据，默认值为 128M。对应 mysqld_exporter 中，可以通过 mysql_global_status_innodb_buffer_pool_reads 查看指标数量。