全面介绍Prometheus的官方导出器Blackbox

译文
开发 开发工具
本文介绍了作为一种新的导出器,Blackbox如何被部署到Prometheus平台上,以检测应用基础架构的关键指标,以及如何通过与Grafana仪表板的动态结合,为团队提供应用的整体概览。

[[428986]]

【51CTO.com快译】众所周知,Prometheus是一个开源的、基于指标的监控系统。它能够通过强大的数据模型和查询语言,来分析应用程序和基础架构的执行方式与状态。目前,Prometheus栈是由多个部分组成,其中包括:负责存储和提供数据的Prometheus服务器、负责管理警告的警报管理器、以及具体执行指标收集任务的大量Prometheus导出器。导出器通过从一个应用程序处获取统计信息,并将它们公布给特定的端点(通常是某个端口和路径),以允许远程Prometheus服务器收集到此类指标。

在应用社区中,我们可以轻松地获取各种导出器。它们有的是作为官方的Prometheus GitHub组织的一部分被维护,其他则是由外部贡献者进行维护的。我们即将介绍到的Blackbox,便是一种由Prometheus组织维护的官方导出器。

作为一种导出工具,Blackbox能够协助系统管理员执行HTTP/S、DNS、TCP和ICMP端点的可用性检查等日常任务。简单而言,我们可以将Prometheus Blackbox导出器视为PingDOM、Freshping或Uptime.com等工具的免费、简单替代品,可以被用于监控那些未在互联网上公布的内部端点。

为什么需要Prometheus Blackbox?

Prometheus Blackbox导出器的主要功能是检测远程的内、外部端点,在HTTP/S、DNS、TCP和ICMP等方面的响应时间。其具体捕获的指标包括:

  • HTTP延迟 - 访问远程端点需要多长时间?
  • DNS查找延迟 - 解析DNS记录需要多长时间?
  • SSL证书信息 - 远程端点是否安全?是否持有有效的证书?证书的有效期到何时?
  • TLS版本 - 远程端点使用什么版本的TLS?
  • 基本身份验证 – 是否可以在远程端点上运行一个简单的网络场景,比如身份验证?
  • 标头(Header)验证 – 是否可以在HTTP标头中找到必需的参数?其标头是否符合安全合规性?

这些指标对于应用基础架构来说,都是重要的组成部分。我们需要通过针对各个面向客户(外部)和内部端点的持续监控,以确保应用服务的连续性,以及某些安全认证的合规性。

应用程序通常需要显性地将各种客户端库添加到代码之中,以公布出待检测的指标。而Blackbox则会隐性地验证诸如:DNS解析、网络连接、证书颁发机构(CA)等外部服务的状态,而且侧重于检测应用程序的性能。因此,Blackbox通常会被部署在 Kubernetes集群上,提供免费、具有高度可用性的监控过程,以全面了解远程端点。

如何部署

与其他Prometheus导出器类似,Blackbox可以被部署在任何操作系统上,或以容器的形式被部署。不过,鉴于其主要目的是为了监控应用基础架构的关键方面,因此我强烈建议您将其部署在容器编排的平台上,并发挥如下优势:

  • 高可用性 – 作为最重要的方面,保证监控工具的可用性,是每位管理员的头等大事。
  • 可扩展性 - 根据检查的次数需要,Blackbox可以按需扩展。
  • 可移植性 – 由于无法预知应用基础架构的演变,因此我们需要确保可以在本地或云端,以不同的方式流畅地部署该工具。这也是其作为监控栈的另一个重要方面。
  • 灵活性 – 能够与Kubernetes等现有平台轻松地集成。这是该工具的一大优势所在。

由于Blackbox是由Prometheus组织在GitHub上管理的官方导出器,因此Helm chart能够很容易地被部署到Kubernetes群集上。具体设置与部署,请参见如下命令行:

部署Prometheus

由于在完成默认安装后,它会自带有了一个简单的HTTP探测器,因此我们可以轻松地启动针对不同HTTP/S端点的监控。

Prometheus的默认安装

Blackbox会带有一个简单的Web UI,可以轻松地访问到每个健康检查服务的日志。您可以在Helm chart中启用一个入口规则(ingress rule),以开启对于UI的访问,并调试针对的各项Web检查:

用Blackbox进行健康检查

为何以及如何使用Kubernetes ServiceMonitor

如今,监控不再只是某个专职团队的任务。它往往会被分散到各个协作团队,以确保能够覆盖到应用架构的每个部分。因此,我们只有让整个监测过程越易于被理解,也就越易于被频繁使用。

为此,Prometheus operator引入了一个名为ServiceMonitor的全新Kubernetes对象。该资源可以被用于描述Prometheus监控的一组目标,而无需在Prometheus服务器端进行任何额外的配置。

通过这种自动化配置Prometheus新目标的简单方法,服务器就能够找到任何被配置了特定标签的Kubernetes ServicesMonitor,并自动将其添加到当前的列表中(默认情况下,它使用的标签是“release=kube-prometheus-stack”)。

我们推荐您使用带有Blackbox的ServiceMonitor对象,去监视各个内、外部端点。值得注意的是,添加新的检测节点属于创建的独立对象,它是与Prometheus服务器的配置相分离的。这就意味着任何想要部署新应用的运维人员,都可以独立地管理对其应用的监控,而无需借助管理员的干预,去配置Prometheus scratch。这样设计的主要好处在于,它分担了运维人员对于每个部署资源进行监控的责任。

如下配置所示,Blackbox Helm chart也可以通过ServiceMonitor,去轻松创建并管理任何新加入到监控目标。

可用于服务监控的Blackbox Helm chart

上述配置命令的结果是创建了三个具有特定标签:kube-prometheus-stack的不同ServiceMonitor对象。每个对象都被专用于配置新的Prometheus目标。

如何绘制数据图表

Blackbox自带有一个Web UI,可提供检测的相关信息。不过,该UI无法持续被用来监控多个端点的状态。对此,为了绘制由Prometheus导出器收集到的指标图表,我们需要根据默认选项,将Grafana与Prometheus相集成。

具体说来,我们可以通过如下两种Blackbox仪表板,来构建可读的数据图表。

  • 9115-blackbox - 在单个图表中,提供所有受监控端点的整体概览,以快速获取每个端点的状态。
  • Prometheus Blackbox Exporter - 在每个端点的专用部分,提供每个受监控端点的概览。

当然,我们也可以将上述仪表板合并在一起,通过优化和渲染,一站式地呈现数据,以避免将同一数据源的仪表板数量翻倍。如果您想了解更多的仪表板类型,请参见--https://grafana.com/grafana/dashboards?search=blackbox。

通过合并两个仪表板,以实现更好的可视化

小结

作为一种新的导出器,Blackbox可以轻松地被部署到Prometheus平台上,以检测应用基础架构的关键指标。通过将其与Grafana仪表板动态结合,我们不但可以改进SLA的检测质量,还能够为执行团队提供应用基础架构的整体概览。如果您有兴趣了解更多有关Prometheus Blackbox的信息,请参见:

原文标题:Prometheus Blackbox: What? Why? How?,作者: Nicolas Giron

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

责任编辑:华轩 来源: 51CTO
相关推荐

2022-12-13 08:01:06

监控黑盒集成

2011-03-02 10:51:09

vsftpd

2009-06-11 10:54:25

GlassFish服务

2009-09-17 09:11:59

CCNA实验模拟器CCNA

2010-08-05 10:06:23

路由器设置

2009-12-14 17:15:15

协议转换器

2009-11-11 13:16:02

2009-11-12 14:07:16

路由器故障

2010-09-10 15:18:28

SOAP协议

2009-09-16 10:38:43

LINQ查询

2009-09-28 13:49:44

Hibernate Q

2009-09-28 10:24:58

Hibernate基础

2009-09-25 09:46:03

Hibernate s

2009-07-10 13:36:32

Swing容器

2019-11-10 09:30:44

LinuxLinux权限

2009-07-09 14:22:44

2009-09-23 17:41:05

Hibernate事务

2009-11-12 16:26:44

宽带路由器

2009-11-20 15:00:16

路由器端口映射设置

2009-12-14 18:25:08

水星无线路由器设置
点赞
收藏

51CTO技术栈公众号