Chef怎样监控节点

在 Chef 生态里，“监控节点”通常不是 Chef 本身直接做的事，而是通过 Chef 管理节点配置，再配合其他监控工具或 Chef 自身能力来完成。下面按常见分层方式给你一个清晰说明。

一、Chef 本身能“看到”的节点状态

1. Chef Server 上的节点信息

Chef Server 会保存每个节点的：

• 节点对象（Node Object）
  • 节点名
  • 运行环境（environment）
  • run_list
  • 自动属性（ohai 采集的 CPU、内存、IP、平台等）
• 最后一次 chef-client 运行时间
• 运行是否成功

查看方式：

knife node list
knife node show NODE_NAME

✅ 适合：

• 看节点是否还在“被管理”
• 看最后一次配置是否成功

❌ 不适合：

• 实时性能监控
• 故障告警

二、通过 Chef + 监控工具（最常见做法）

1. Chef 负责“安装和配置监控 Agent”

Chef 本身不监控，但负责把监控工具部署到节点上。

常见组合：

示例（概念）：

• Chef cookbook 安装 node_exporter
• 配置 systemd 服务
• 注册到 Prometheus

✅ 这是生产环境最主流方式

三、用 Chef 的“上报机制”做轻量监控

1. Chef 运行报告（Handler）

Chef 支持 report handler：

• 每次 chef-client 运行后
• 把结果发送到：
  • 日志
  • HTTP 接口
  • 消息队列
  • 监控系统

例如：

• 发送失败 run 到 Slack / 钉钉
• 写入 ELK / Splunk
• 触发告警

✅ 可以监控：

• 配置失败
• 节点失联（长时间没 run）

四、用 Chef 的 Search 做“集群状态判断”

Chef Server 支持 search：

knife search node "chef_environment:prod AND ohai_time:<$(date -d '10 minutes ago' +%s)"

可以用来判断：

• 哪些节点超过 N 分钟没运行 chef-client
• 哪些节点缺少关键角色

常用于：

• 自定义脚本
• 健康检查

五、不推荐但存在的做法

1. 用 ohai 做“采集 + 推送”

• 写自定义 ohai plugin
• 在 chef-client 运行时采集指标

❌ 缺点：

• 数据频率低
• 不适合实时监控

六、典型生产架构示例

Chef Server
   │
   ├── 管理节点配置
   │
   ├── 安装 Prometheus Node Exporter
   │
   └── 配置 Datadog / Zabbix Agent

Prometheus / Datadog
   │
   └── 实时指标 & 告警

Chef Handlers
   │
   └── chef-client 失败 → 告警

七、总结一句话

Chef 不是监控系统，而是配置管理工具。
Chef 用来“保证监控存在”，真正监控节点的是 Prometheus / Zabbix / Datadog 等。

如果你愿意，我可以：

• 给你一个 Chef + Prometheus 的完整 cookbook 示例
• 或针对 你现在的监控体系（Zabbix / Datadog / 自研） 给出落地方案