Vigil探针模式详解：Poll、Push、Script、Local的实战应用

Vigil探针模式详解：Poll、Push、Script、Local的实战应用

【免费下载链接】vigil🚦 Microservices Status Page. Monitors a distributed infrastructure and sends alerts (Slack, SMS, etc.).项目地址: https://gitcode.com/gh_mirrors/vig/vigil

Vigil是一款强大的微服务状态监控工具，能够自动监控基础设施服务并在服务出现故障时通过Slack、SMS等多种渠道发送警报。本文将详细解析Vigil的四种探针模式——Poll、Push、Script和Local，帮助新手和普通用户快速掌握它们的实战应用。

Poll模式：主动探测远程服务状态

Poll模式是Vigil最常用的探针模式之一，它通过定期主动探测HTTP、TCP或ICMP目标来监控服务状态。这种模式适用于大多数可以通过网络直接访问的服务。

Poll模式的核心配置

在Vigil的配置文件中，与Poll模式相关的关键参数包括：

• poll_interval：探测间隔时间（秒），默认值为120秒
• poll_retry：首次探测失败后的重试间隔（秒），默认值为2秒
• poll_delay_dead：判定节点为"dead"状态的延迟时间（秒），默认值为10秒
• poll_delay_sick：判定节点为"sick"状态的延迟时间（秒），默认值为5秒

这些参数可以在配置文件的[metrics]部分进行设置，以适应不同服务的监控需求。

Poll模式的工作原理

当节点设置为Poll模式时，Vigil会根据配置的时间间隔定期向指定的副本URL发送请求。例如，对于HTTP服务，Vigil会检查响应状态码是否在健康范围内（默认200-400之间）。如果响应时间超过poll_delay_sick阈值，节点会被标记为"sick"；如果超过poll_delay_dead阈值或完全无响应，则会被标记为"dead"。

Poll模式的实战配置示例

在配置文件中，Poll模式的节点可以这样设置：

[[probe.service.node]] id = "web-server" label = "Web Server" mode = "poll" replicas = ["http://192.168.1.100:8080", "tcp://192.168.1.101:22"] http_headers = { "Authorization" = "Bearer xxxx" }

这个配置定义了一个名为"Web Server"的节点，它会定期探测两个副本：一个HTTP服务和一个TCP服务。

Push模式：应用主动上报健康状态

Push模式与Poll模式相反，它不是由Vigil主动探测服务，而是由应用程序通过Vigil Reporter库主动向Vigil上报健康状态。这种模式特别适用于需要监控应用内部状态的场景。

Push模式的优势

Push模式的主要优势在于：

1. 能够提供更详细的应用内部状态信息，如CPU和内存使用率
2. 减少监控服务器的网络负载，尤其适用于监控大量微服务
3. 可以更快地发现应用级别的问题，而不仅仅是网络可达性

Push模式的核心配置

与Push模式相关的关键参数包括：

• push_delay_dead：判定节点为"dead"状态的延迟时间（秒），默认值为20秒
• push_system_cpu_sick_above：CPU使用率阈值，超过此值节点被标记为"sick"，默认0.90
• push_system_ram_sick_above：内存使用率阈值，超过此值节点被标记为"sick"，默认0.90

Push模式的实现方式

要使用Push模式，需要在应用程序中集成Vigil Reporter库。Vigil提供了多种编程语言的Reporter库，包括：

• NodeJS: node-vigil-reporter
• Python: py-vigil-reporter
• Golang: go-vigil-reporter
• Rust: rs-vigil-reporter

集成后，应用程序会定期向Vigil服务器发送健康状态报告。如果Vigil在push_delay_dead时间内没有收到报告，节点将被标记为"dead"。

Script模式：自定义脚本实现灵活监控

Script模式允许用户编写自定义的shell脚本来实现复杂的监控逻辑，当Poll和Push模式无法满足需求时，Script模式提供了极大的灵活性。

Script模式的适用场景

Script模式特别适用于以下场景：

• 需要执行多步骤检查的复杂服务
• 需要解析响应内容来判断健康状态的服务
• 监控内部系统或非标准协议的服务

Script模式的核心配置

与Script模式相关的关键参数包括：

• script_interval：脚本执行间隔时间（秒），默认值为300秒
• script_parallelism：最大并行执行的脚本数量，默认值为2

Script模式的实现方式

在Script模式下，用户需要提供一个或多个shell脚本，Vigil会定期执行这些脚本并根据返回码判断服务状态：

• 返回码0：服务状态为"healthy"
• 返回码1：服务状态为"sick"
• 返回码2及以上：服务状态为"dead"

Script模式的配置示例

以下是一个Script模式节点的配置示例：

[[probe.service.node]] id = "custom-check" label = "Custom Service Check" mode = "script" scripts = [ ''' #!/bin/bash # 检查数据库连接 if ! mysqladmin ping -h db.example.com -u monitor -psecret; then exit 2 # 返回码2表示dead状态 fi # 检查磁盘空间 DISK_USAGE=$(df -P / | awk 'NR==2 {print $5}' | sed 's/%//') if [ $DISK_USAGE -gt 90 ]; then exit 1 # 返回码1表示sick状态 fi exit 0 # 返回码0表示healthy状态 ''' ]

这个脚本首先检查数据库连接，如果失败返回2（dead）；然后检查磁盘使用率，如果超过90%返回1（sick）；否则返回0（healthy）。

Local模式：监控内网服务的解决方案

Local模式用于监控无法从Vigil服务器直接访问的内部服务，通常与Vigil Local slave daemon配合使用。这种模式适用于监控防火墙后的服务或本地环回地址上的服务。

Local模式的工作原理

Local模式的工作流程如下：

1. 在内部网络中部署Vigil Local slave daemon
2. 配置Vigil Local监控本地服务（可以使用Poll或Script模式）
3. Vigil Local定期向主Vigil服务器报告监控结果
4. 如果主Vigil服务器在local_delay_dead时间内没有收到报告，节点将被标记为"dead"

Local模式的核心配置

与Local模式相关的关键参数是：

• local_delay_dead：判定节点为"dead"状态的延迟时间（秒），默认值为40秒

Local模式的配置示例

以下是一个Local模式节点的配置示例：

[[probe.service.node]] id = "intranet-service" label = "Intranet Service" mode = "local"

要使这个配置生效，还需要在内部网络中正确部署和配置Vigil Local。具体步骤可以参考Vigil Local的官方文档。

四种探针模式的对比与选择建议

选择建议：

• 对于大多数外部服务，优先考虑使用Poll模式
• 对于重要的应用服务，建议使用Push模式以获取更详细的状态信息
• 对于特殊的监控需求，如复杂的业务逻辑检查，可使用Script模式
• 对于内网服务或无法直接访问的服务，使用Local模式

总结

Vigil提供的四种探针模式各有特点，能够满足不同场景下的监控需求。通过灵活配置和组合这些模式，可以构建一个全面而高效的微服务监控系统。无论是简单的网络可达性检查，还是复杂的应用内部状态监控，Vigil都能提供可靠的解决方案。

要开始使用Vigil，你可以通过以下命令克隆仓库：

git clone https://gitcode.com/gh_mirrors/vig/vigil

然后参考项目中的配置文件示例和文档，根据你的具体需求选择合适的探针模式进行配置。

【免费下载链接】vigil🚦 Microservices Status Page. Monitors a distributed infrastructure and sends alerts (Slack, SMS, etc.).项目地址: https://gitcode.com/gh_mirrors/vig/vigil