把监控规则散落在几十台机器的本地配置里，是不少团队经历过的事故源头：某台机器的磁盘告警阈值改了没同步，某次扩容后新节点漏加了订阅，等问题爆发才发现监控根本没生效。监控即代码（Monitoring as Code）要解决的正是这个问题——所有监控相关的检查项、处理器、告警规则都以声明式配置存在，进Git仓库，走评审流程，靠工具下发，人和流程都不再依赖手工操作。Sensu Go作为一套面向云原生场景的监控方案，天然适合这种玩法，本文就以Debian系统为例，讲清楚从零搭建到配置管理的完整路径。
在Debian上部署Sensu Go后端与Agent
Sensu Go采用前后端分离架构，后端负责存储事件、调度检查、对接Web UI，Agent部署在被监控节点上执行具体任务。Debian官方源里没有Sensu包，需要先添加Sensu官方的APT仓库并导入签名密钥，这一步是保证后续自动更新的前提。
在管理节点上安装后端：
# 导入GPG密钥并添加仓库 curl -s https://packagecloud.io/sensu/stable/gpgkey | sudo apt-key add - echo "deb https://packagecloud.io/sensu/stable/debian/ bullseye main" | sudo tee /etc/apt/sources.list.d/sensu.list sudo apt update sudo apt install sensu-go-backend -y # 生成后端配置并启动 sudo curl -L https://docs.sensu.io/sensu-go/latest/files/backend.yml -o /etc/sensu/backend.yml sudo systemctl enable --now sensu-backend
后端起来之后，第一件事是配置sensuctl命令行工具，它是后面实现监控即代码的核心入口。用默认账号admin和密码P@ssw0rd!登录，然后记得改掉默认密码：
sudo apt install sensu-go-cli -y sensuctl configure -n \ --url http://127.0.0.1:8080 \ --username admin \ --password 'P@ssw0rd!' # 修改默认密码，避免安全风险 sensuctl user change-password admin
被监控节点上安装Agent的方式类似，装完sensu-go-agent包后，编辑/etc/sensu/agent.yml，关键是填对backend地址和订阅名。订阅是Sensu的逻辑分组机制，Agent声明自己属于哪些订阅，后端下发的检查会按订阅匹配到目标节点，这比按主机逐个配置灵活得多：
# /etc/sensu/agent.yml backend-url: ["ws://192.168.1.10:8081"] subscriptions: - webserver - debian-prod namespace: default
用YAML定义监控资源，让配置进Git
Sensu的一切资源都可以表达为YAML：检查、处理器、过滤器、钩子、资产。所谓监控即代码，本质就是把这些YAML文件放进仓库管理。举个典型例子，定义一个CPU负载检查，超阈值时通过处理器发消息：
# checks/cpu.yml
type: CheckConfig
api_version: core/v2
metadata:
name: cpu-usage
labels:
env: production
spec:
command: check-cpu.rb -w 80 -c 90
subscriptions:
- webserver
interval: 60
handlers:
- slack-alert
runtime_assets:
- sensu-ruby-runtime
- sensu-plugins-cpu-checks
这里的runtime_assets是Sensu比较有特色的设计。检查脚本依赖的运行时和插件不需要提前装到每台Agent上，Sensu会在执行前自动把资产分发到目标节点，新机器上线只要装好Agent就具备全部监控能力，这大大降低了批量部署的心智负担。
处理器配置同样用YAML表达，比如对接Slack的告警通道，webhook地址和模板都写进配置文件，变更走Git提交记录，谁改了告警文案一目了然：
# handlers/slack.yml
type: Handler
api_version: core/v2
metadata:
name: slack-alert
spec:
type: pipe
command: sensu-slack-handler --channel '#ops-alerts'
env_vars: "SLACK_WEBHOOK_URL=https://hooks.slack.com/services/xxx"
runtime_assets:
- sensu-slack-handler
写好之后用一条命令批量下发：sensuctl create -f checks/。也可以反向操作，用sensuctl dump把线上现有配置导出成YAML，作为迁入版本管理的起点：
sensuctl dump checks,handlers,filters \ --format yaml --all-namespaces > sensu-config/
接入CI做配置校验，杜绝坏配置上线
配置进了Git只是第一步，真正体现监控即代码价值的是变更流程自动化。最简单的做法是在CI流水线里加一个校验阶段，每次提交先跑sensuctl create --dry-run式的语法检查，或者用lint工具验证YAML结构，校验通过才允许应用变更。这样一条写错缩进的配置永远不会污染生产环境。
进阶一些可以引入环境分层。用目录区分dev和prod两套命名空间，CI根据分支自动推送到对应环境，master分支合并即发布生产。配合Sensu的多命名空间特性，测试环境的告警规则可以在隔离的命名空间里先跑一段时间，验证无误再提升到生产：
# CI部署脚本示意 if [ "$BRANCH" = "master" ]; then sensuctl create -f config/prod/ --namespace production else sensuctl create -f config/dev/ --namespace staging fi
还有一点容易被忽视：Agent本身的配置也应该纳入管理。可以用Ansible的template模块统一分发agent.yml，主机变量里维护订阅列表，这样新增一台Debian服务器，Ansible跑一遍就能完成系统初始化加监控接入，真正做到机器即插即用、监控随配置自动到位。
整体来看，Sensu在Debian上落地监控即代码的路径并不复杂：APT仓库装后端和Agent，全部资源用YAML描述，sensuctl负责下发，CI负责把关。一旦这套流程跑通，监控就不再是一个需要人肉维护的负担，而是随代码演进、可回溯、可复现的基础设施组件。团队规模越大、节点数量越多，这种方式的收益就越明显。