vec2checkd

此程序/守护进程通过 Prometheus HTTP API 执行 PromQL 查询，将结果转换为被动检查结果，并将其发送到 Icinga HTTP API 以更新某些主机或服务对象。这些映射（PromQL 查询结果 -> 被动检查结果）会根据用户定义的间隔定期应用，类似于 Icinga 卫星或代理应用的活动服务检查。

显然，用于监控 Prometheus 等抓取时间序列数据的任何内容的最佳选择是 Grafana 和/或 Alertmanager。然而，这个小巧的工具在您/您的组织主要依赖 Icinga2 进行基础设施监控，但希望将一些导出时间序列数据的服务的集成到其中时可能会很有用。在这种情况下，在 Icinga2 旁边设置 Grafana 和/或 Alertmanager 可能是过度杀鸡用牛刀（或者可能不是 ... 我想这 "取决于">

安装

先决条件：Rust >= v1.58.0

.deb 包

要安装 .deb 包，请从 GitHub 下载并使用

dpkg-i<path_to_package>

或者

通过首先安装 cargo deb 命令自行构建

cargo安装 cargo-deb

然后构建包

cargodeb

.deb 包还提供了一个 systemd 单元模板文件。有关如何配置多个 vec2checkd 实例的说明，请参阅下一节。

仅二进制文件

cargo安装 vec2checkd

配置

systemd 单元设计用于通过 模板 运行多个 vec2checkd 实例。可以创建新实例如下所示

$ ln -s -T /lib/systemd/system/[email protected] /etc/systemd/system/vec2checkd@<instance_name>.service
$ systemctl enable /etc/systemd/system/vec2checkd@<instance_name>.service

每个实例从 /etc/vec2checkd/conf.d/<instance_name>.yaml 读取其配置。尽管可以通过覆盖单元文件中的设置（特别是 --config 标志）提供自定义位置。每个实例配置内容的整体结构在此 处 描述。

对于简单的用例，当然可以使用单个 vec2checkd 实例。然而，在某些情况下，创建多个守护进程实例可能会有所帮助，例如

• 单个配置的 "映射" 部分变得非常大，并且最好将其拆分为多个部分。
• “映射”部分中的查询针对不同的系统（例如多个K8s集群），可能为了清晰起见最好分开。
• 查询不同的Prometheus服务器。
• 被动检查结果发送到不同的Icinga服务器。

示例

下面是一个示例配置，开始时相当简单，主要依赖于vec2checkd设置的默认值。

# Connects to 'http://localhost:9090' by default.
prometheus: {}
icinga:
  host: 'https://my-satellite.exmaple.com:5665'
  authentication:
    method: 'x509'
    client_cert: '/var/lib/vec2checkd/ssl/kubernetes-monitoring.crt'
    client_key: '/var/lib/vec2checkd/ssl/kubernetes-monitoring.key'
mappings:
  'Failed ingress requests':
    query: 'sum(rate(nginx_ingress_controller_requests{cluster="production",status!~"2.."}[5m]))'
    host: 'Kubernetes Production'
    service: 'Failed ingress requests'

  ...

根据这里起作用的默认值，此映射将每60秒执行PromQL查询，并将以下默认插件输出和性能数据发送到Icinga2，以更新主机“Kubernetes Production”上的服务对象“失败的入站请求”。状态为0（OK），因为没有定义阈值。

# plugin output
[OK] PromQL query returned one result (34.44)

# performance data
'Failed ingress requests/2a4e86'=34.4393348197696023;;;;

现在我们通过另一个示例映射扩展配置，该映射与上面的类似，但利用了更多的可选参数。

prometheus: {}
icinga:
  host: 'https://my-satellite.exmaple.com:5665'
  authentication:
    method: 'x509'
    client_cert: '/var/lib/vec2checkd/ssl/kubernetes-monitoring.crt'
    client_key: '/var/lib/vec2checkd/ssl/kubernetes-monitoring.key'
mappings:
  'Failed ingress requests':
    query: 'sum(rate(nginx_ingress_controller_requests{cluster="production",status!~"2.."}[5m]))'
    host: 'Kubernetes Production'
    service: 'Failed ingress requests'

  'Successful ingress requests':
    query: 'sum(rate(nginx_ingress_controller_requests{cluster="production",status=~"2.."}[5m]))'
    host: 'Kubernetes Production'
    service: 'Successful ingress requests'
    interval: 300
    # In words: "WARN if the value dips below 200 or CRIT when the value dips below 100".
    thresholds:
      warning: '@200'
      critical: '@100'
    plugin_output: '[{{ exit_status }}] Nginx ingress controller processes {{ truncate prec=2 data.0.value }} requests per second (HTTP 2xx)'
    performance_data:
      enabled: true
      label: 'requests'

  ...

第二个映射将每300秒应用一次。在最终检查结果发送到Icinga2之前，也考虑了警告和关键阈值。当PromQL查询评估为“130.54098”值时，vec2checkd发送状态1（警告）以及以下插件输出和性能数据到API。

# plugin output
[WARNING] Nginx ingress controller processes 130.54 requests per second (HTTP 2xx)

# performance data
'requests'=130.54098;@0:200;@0:100;;

这里还有更多的事情发生，其中之一就是使用自定义插件输出中的handlebars模板。因此，请查阅文档以了解模板语言的使用、阈值、自定义性能数据等详细信息。

限制

• 与signalilo不同，vec2checkd旨在与Icinga2中预定义的主机和对象交互，并定期更新这些对象。因此，vec2checkd不会以任何方式创建/删除或管理主机和对象，因为Icinga2提供了创建任何类型对象的出色工具，例如通过使用Director。提供创建对象的方法将需要重新创建Director已经提供的几乎所有逻辑。
• 仅解释PromQL结果类型“向量”。这可能在未来的版本中改变

待办事项

• 扩展Prometheus配置对象以包含身份验证选项（因为服务器可能被反向代理屏蔽）。
• 还提供了解释PromQL查询结果类型“矩阵”的方法。