Prometheus 与 Vertica Prometheus Exporter：技术探索¶

本次探索的目标是审查第三方编写的 Vertica Prometheus Exporter 在可用性、功能性和可扩展性方面的表现，并提供一些可能有助于其他人使用该 Exporter 的观察结果。探索的重点放在 Exporter 上，而不是 Prometheus，因此大多数发现和观察都是围绕 Exporter 展开的。

Prometheus 概述¶

Prometheus 是一个开源的面向时间序列的系统监控和告警工具包。Prometheus 从被检测的作业中抓取指标。它将所有抓取的数据（样本）存储在本地，并提供 Web 界面以表格或图形视图呈现数据。可以使用可选的规则对数据进行聚合和记录新的时间序列，或生成告警。Grafana 或其他 API 消费者可用于可视化收集的数据。

Vertica Prometheus Exporter 概述¶

Vertica Prometheus Exporter（以下简称 Vertica Exporter）是一个开源的、Vertica 感知的 Prometheus 扩展。它允许收集 Vertica 指标，并以 Prometheus 可以抓取和处理的必要格式呈现。它使用 GO 语言编写，并使用 vertica-sql-go 驱动程序。

处理流程概述¶

Vertica Exporter 启动并与 Vertica 建立连接。它提供一个简单的 HTTP 浏览器界面，URL 类似：http://<host>:8080/metrics
Prometheus 启动并读取其配置文件，其中包括定义的"jobs"。Vertica Exporter 的 job 使用该 URL 作为目标地址进行定义
在定义的全局或 job 级别时间间隔，Prometheus 从 URL 地址"抓取"时间点数据，应用定义的规则（如果有）进行聚合和告警，并将结果存储在其内部时间序列数据库中
根据定义的时间间隔继续抓取和评估。Prometheus 提供 HTTP 浏览器界面作为默认界面。打开 URL 可查看运行时、配置、状态信息以及基于时间序列数据的表格或图形视图

测试环境¶

Vertica 数据库¶

Vertica 9.3.x Enterprise Mode 单节点
Vertica 10.0.0 EON Mode 多节点
两者均使用默认配置参数值和加载了 VMart 示例数据库

Prometheus¶

Prometheus 2.19.2 运行在 CentOS 7.4 kernel 3.10.0-514.10.2.el7.x86_64
测试使用二进制 tar/gz 下载，未进行 go build
默认端口 9090

Vertica Exporter¶

Vertica Exporter 0.4 运行在 CentOS 7.4 kernel 3.10.0-693.11.6.el7.x86_64
使用 go version go1.14.4 linux/amd64 构建
默认端口 8080
测试了 Vertica Exporter 与 Prometheus 主机和 Vertica 服务器在同一主机和不同主机上运行的情况

测试范围¶

测试集中在以下特定领域： 1. 用于构建和配置 Vertica Exporter 的文档可用性 2. 开箱即用的功能 3. 可扩展性——自定义和/或扩展功能以满足需求

注意： 虽然没有专门测试性能，但包括了对 Vertica 性能潜在影响的一些观察。

测试说明¶

Prometheus 配置文件 Prometheus.yml 的基本配置如下。唯一的可选条目是将 scrape_interval 设置为不同于全局值的值：

- job_name: 'vertica'
  scrape_interval: 60s
  static_configs:
  - targets: ['nn.nn.nn.nn:8080']

Prometheus 和 Vertica Exporter 进程均使用 nohup 和 "&" 运行，以便它们可以在后台运行，在退出到主机的 putty 会话后不会终止。当两者在同一主机上运行时，它们在不同目录中运行，以便每个都有唯一的 nohup.out 便于查看和调试。

Vertica Exporter 测试了以下配置：

Prometheus、Vertica Exporter 和 Vertica 数据库在同一主机上
Prometheus 和 Vertica Exporter 在同一主机上，Vertica 数据库在不同主机上
Prometheus、Vertica Exporter 和 Vertica 数据库全部在不同主机上

所有测试均在受控环境中运行，没有其他客户端或进程在 Vertica 数据库上运行。

测试运行多次以确认响应性、可靠性或结果没有重大偏差。

Prometheus 中的所有结果都与相应的 Vertica 查询进行比较，以确保 Vertica Exporter 捕获默认指标和 Prometheus 收集正常工作。

测试详情和结果¶

独立测试¶

Vertica Exporter 使用其内置 URL 进行独立测试，以确保它能够连接到 Vertica，成功执行用于获取指标的系统表查询，并以 Prometheus 可以抓取的格式呈现结果。

连接和驱动版本¶

检查了 Vertica 系统表和 vertica.log，确定 Vertica Exporter 连接是在首次启动浏览器页面时的一次性连接。检查了驱动程序和驱动程序版本以确保使用最新版本。

dbadmin=> SELECT user_name, client_hostname, client_type, client_version FROM sessions;
 user_name | client_hostname    | client_type    | client_version
-----------+--------------------+----------------+----------------
 dbadmin   | [::1]:59844        | vsql           | 09.03.0000
 dbadmin   | 10.20.43.234:53824 | vertica-sql-go | 1.1.0

页面刷新会触发查询执行并报告新值。注意 Vertica Exporter 的结果是非持久性的时间点快照。它们是未存储的原始实时结果。

多数据库监控¶

在同一主机上运行了两个指向不同 Vertica 数据库的 Vertica Exporter，使用不同的监听端口。重新配置 Prometheus 添加了指向第二个 Vertica Exporter 监听端口的 vertica2 job。它成功报告了两个数据库的指标，证明可以运行多个 Vertica Exporter 来监控多个数据库。

扩展自定义指标¶

我们扩展了 Vertica Exporter 监控包指标，并在 Vertica Exporter Web 界面中确认新数据出现。注意这是特意使用用户定义表而不是系统表，以证明您也可以使用 Vertica Exporter 在 Prometheus 中监控该类型数据。

用户表定义：

dbadmin=> \d stocks
List of Fields by Tables
Schema | Table  | Column        | Type        | Size | Default | Not Null | Primary Key | Foreign Key
--------+--------+---------------+-------------+------+---------+----------+-------------+-------------
public | stocks | ticker_name   | varchar(4)  |    4 |         | f        | f           |
public | stocks | shares_traded | int         |    8 |         | f        | f           |
public | stocks | share_value   | int         |    8 |         | f        | f           |
public | stocks | date_sold     | timestamp   |    8 |         | f        | f           |

dbadmin=> SELECT * FROM stocks ORDER BY date_sold;
 ticker_name | shares_traded | share_value | date_sold
-------------+---------------+-------------+---------------------
 ABCD        |           150 |          38 | 2020-08-19 12:00:00

添加的 Go 扩展代码（在 Vertica Exporter 的 monitoring 目录中创建 stocks.go）：

package monitoring

import (
    "fmt"
    "log"
    "github.com/jmoiron/sqlx"
)

type QueryRequest3 struct {
    TickerName   string `db:"ticker_name"`
    SharesTraded int    `db:"shares_traded"`
    ShareValue   int    `db:"share_value"`
}

func NewQueryRequests3(db *sqlx.DB) []QueryRequest3 {
    sql := `SELECT ticker_name, shares_traded, share_value FROM stocks ORDER BY date_sold DESC;`
    queryRequests3 := []QueryRequest3{}
    err := db.Select(&queryRequests3, sql)
    if err != nil {
        log.Fatal(err)
    }
    return queryRequests3
}

func (qr QueryRequest3) ToMetric() map[string]int {
    metrics := map[string]int{}
    tickername := fmt.Sprintf("ticker_name=%q", qr.TickerName)
    metrics[fmt.Sprintf("vertica_shares_traded{%s}", tickername)] = qr.SharesTraded
    metrics[fmt.Sprintf("vertica_share_value{%s}", tickername)] = qr.ShareValue
    return metrics
}

在 prometheus.go 中添加的条目：

for _, queryRequest3 := range NewQueryRequests3(&db) {
    metrics = append(metrics, queryRequest3)
}

使用 go build 重建 Exporter 后，启动并检查 Web 页面：

vertica_shares_traded{ticker_name="ABCD"} 150
vertica_share_value{ticker_name="ABCD"} 38

向 Vertica 插入新记录后，验证新数据在 Prometheus 中显示。

观察结果¶

总体而言，这是 Prometheus 的一个相对易用、可自定义和可扩展的扩展，使其能够感知 Vertica 并以简单的表格或图形视图报告指标。

文档可用性¶

Vertica Exporter 附带的 README.md 足以让您开始使用二进制文件。如果要安装 master 并进行自定义或扩展 Exporter，则需要具备设置 GO 环境的一些知识。

开箱即用功能¶

Vertica Exporter 附带了一些特定的 Vertica 系统表指标，重点关注节点状态、内存使用、资源池使用以及一些系统表细节（如 ROS 行数和大小）。开箱即用的指标有一定的价值，但没有什么是通过 vsql、Management Console 或任何连接到 Vertica 的 SQL 客户端无法获得的。其价值在于能够与使用其他导出器收集的任何其他指标一起监控多个 Vertica 数据库。

Vertica Exporter 连接而不断开，这阻止了使用 Vertica 原生负载均衡器和备份服务器功能。

可扩展性¶

非常可定制，因为 Prometheus 和 Vertica Exporter 都是基于 GO 的开源应用程序。对于两者，您都可以修改源代码以满足需求并重建。

Vertica Exporter 提供基于几个不同系统表的指标。通过在 Master 的 /monitoring 目录中添加更多指标 .go 文件、更新 Prometheus.go 并重建，您可以收集更多选择的指标。测试证明，您不仅可以捕获系统表指标，还可以捕获用户定义表的指标。

其他观察¶

Prometheus 使用自己的内置时间序列数据库存储收集的数据，因此需要确保拥有足够的可用磁盘空间来满足随时间收集的数据需求。这取决于导出的指标数量和抓取频率
Vertica Exporter 在进程启动时打开到 Vertica 数据库的连接并保持打开状态。如果该节点宕机，需要终止 Vertica Exporter 进程并使用 -db_host 参数重新启动指向 Vertica 集群中的备用主机
由于上述持久单连接特性，开箱即用的 Vertica Exporter 不支持 Vertica 原生负载均衡和备份服务器功能。要支持它们，必须自定义 Vertica Exporter 源代码以定期断开/重新连接，并在传递给连接字符串的参数中接受负载均衡和备份服务器连接属性
如果有新版本的 vertica-sql-go 并且希望在作者更新 master 和二进制文件之前使用它，则需要安装 master、更新驱动程序并重建 Exporter
Exporter 没有提供任何 vsql、Management Console 或 Grafana 插件无法提供的内容。主要好处是能够以时间序列格式保留指标，以及能够在 Prometheus 中使用多个导出器在一个工具中监控多个不同的系统

故障排查¶

此问题和解决方案仅适用于 Vertica Prometheus Exporter 0.4 或更早版本。在 Vertica Exporter 控制台日志中遇到了 ParameterStatus 警告消息：

WARN connection: unhandled message: ParameterStatus: standard_conforming_strings='on'
WARN connection: unhandled message: ParameterStatus: MARS='off'
WARN connection: unhandled message: ParameterStatus: client_locale='en_US@collation=binary'

vertica-sql-go 驱动程序有一个相关的 pull request，已在 1.0.0 版本中修复： https://github.com/vertica/vertica-sql-go/pull/74

通过查询 V_MONITOR.SESSIONS 系统表，确定 Vertica Exporter 使用的是较旧版本的驱动 0.2。解决方案：拉取 Vertica Exporter master，展开，然后运行：

go get -u github.com/vertica/vertica-sql-go
go build

重启 Vertica Exporter 进程后确认新驱动已在使用且控制台中不再有 WARN 消息。

注意： 这是在 Vertica Prometheus Exporter 0.4 版本中出现的。作者在我们报告后一天更新了 vertica-sql-go 驱动程序。最近的 0.5 版本包含了 vertica-sql-go 1.1.0 驱动程序。

建议¶

基于测试，以下是 Vertica Prometheus Exporter 的建议清单：

将 Exporter 抓取和评估间隔设置为既能最小化对 Vertica 的影响，又能提供所需结果粒度的值。尽量将指标数量和处理时间控制在合理范围内。可能在高峰时段对这些查询进行计时，确保抓取间隔设置得比查询运行时间更长
某些系统表已知性能较差，会显著增加抓取时间。storage_containers 和 delete_vectors 特别消耗资源。在将查询实现到 Exporter 之前，请先对查询计时
Prometheus 默认端口为 9090，Exporter 默认端口为 8080。确保这些端口可用且未被防火墙阻止。Prometheus 有一个基于 GitHub 的端口站点供导出器开发者预留 9100 以上的端口，但 Vertica Exporter 的作者选择了该范围之外的默认端口

2022 年 6 月更新¶

Prometheus 与 Vertica 的初始测试是探索性研究，以了解该 Exporter 解决方案的可行性。自从使用 Exporter 0.4 和 Prometheus 2.19 测试以来，两者都有几个新版本发布，但没有任何影响 Exporter 功能的更改。

Vertica 正在开发自己的 Prometheus Exporter，将以开源形式发布在 Github 上。因此，将不再对此 Exporter 进行进一步测试。新的 Vertica Exporter 将与最新版本的 Prometheus 一起测试以确保兼容性。