分享者：新浪CDN技术团队，负责为公司内部各业务线(微博、新浪新闻、新浪视频等)提供内容分发网络服务。
新浪 CDN 技术团队使用夜莺监控（Nightingale）和 VictoriaMetrics 构建 CDN 边缘节点监控体系，覆盖全国数千台 CDN 边缘节点服务器。方案重点不是单纯部署一套监控系统，而是把夜莺接入 CDN 边缘服务管理平台，通过 API、标签、业务组、屏蔽规则和异步队列形成自动化运维闭环。
核心要点
- 业务规模：管理全国数千台 CDN 边缘节点服务器，服务微博、新浪新闻、新浪视频等内部业务线。
- 核心诉求：高并发写入、多团队协作、监控与 CDN 管理平台联动、灵活告警和自定义通知渠道。
- 技术组合：夜莺 v8 作为监控与告警平台，VictoriaMetrics 作为时序数据库，Categraf 作为采集器。
- 部署方式：夜莺二进制使用 systemd 托管，Categraf 通过 Puppet 批量安装和配置。
- 自动化闭环：CDN 管理平台通过夜莺 API 完成监控对象注册、标签管理、告警屏蔽、事件查询和异步重试。
业务介绍
为了更好的管理CDN服务，我司建立了CDN边缘服务管理平台，这个平台包含的核心功能是：
- 设备管理: 管理全国数千台CDN边缘节点服务器
- 域名调度: 实现智能DNS调度,根据用户地理位置、运营商、服务器负载等因素进行流量分配
- 配置下发: 通过Puppet自动化工具批量下发配置到边缘节点
- 内容管理: 处理内容刷新、预热等CDN核心功能
- 热点事件保障: 针对重大活动(如春晚、体育赛事等)提供专项保障
- 监控告警: 实时监控服务状态和性能指标
其中监控告警部分，我们是基于夜莺监控实现的。本文介绍选型思考、监控架构、落地实践的一些经验等。
监控选型
我们对监控部分的核心诉求是：
高并发写入：需要监控数千台边缘节点服务器，另外CDN业务涉及带宽、请求量、命中率、回源率等多维度指标，需要监控系统支持高并发写入、鲁棒高可靠的集群能力。
多团队协作：我们会有多个团队使用这套系统，希望支持权限划分，支持功能角色、数据权限等，让各个团队自助操作，而不是有啥事都来找我们。
运维联动难：监控系统与CDN边缘服务管理平台，需要联动，监控系统需要提供各类 API，有些自定义逻辑要支持插入告警事件处理流里，否则就太过割裂了。
灵活告警: 支持复杂的告警规则，至少要同时支持指标和日志的告警配置，要支持多种通知渠道，并且支持我们自定义通知渠道，和内部渠道贯通。
这些诉求可以归纳为三类：底层要扛得住边缘节点的指标写入，上层要支持多团队自助协作，平台侧要能通过 API 和 CDN 管理系统打通。只满足其中一类，都不足以支撑 CDN 场景长期运行。
我们调研了以下监控方案：
| 方案 | 优点 | 缺点 | 评分 |
|---|---|---|---|
| Zabbix | 成熟稳定,功能全面 | 性能瓶颈,UI体验差,不支持Prometheus生态 | 6/10 |
| Prometheus + Grafana | 云原生,生态丰富 | 告警能力弱,多租户支持差,长期存储成本高 | 7/10 |
| 云厂商监控 | 开箱即用,无需运维 | 成本高,数据不可控,定制化困难 | 5/10 |
| 夜莺 v8 | 开源免费,性能优秀,告警强大,易于集成 | 社区相对较小，团队研发来自 Open-Falcon，倒也积累了10多年了 | 9/10 |
在时序数据库的选择上,我们对比了Prometheus、InfluxDB、VictoriaMetrics等方案,最终选择VictoriaMetrics，我在夜莺资深用户群里观察，其他公司大都也是使用 VictoriaMetrics，确实很强，供新用户选型参考：
| 特性 | Prometheus | VictoriaMetrics | 我们的选择 |
|---|---|---|---|
| 压缩率 | 一般 | 优秀(10倍压缩) | ✅ VM |
| 查询性能 | 好 | 优秀 | ✅ VM |
| 长期存储 | 需要额外方案 | 原生支持 | ✅ VM |
| 资源占用 | 较高 | 低 | ✅ VM |
| 集群模式 | 复杂 | 简单 | ✅ VM |
| 兼容性 | 原生 | 完全兼容 | ✅ VM |
最终方案中，夜莺负责 Web UI、API Server、告警引擎和业务组管理；VictoriaMetrics 负责高并发写入、PromQL 查询和长期存储；Categraf 负责在边缘节点侧采集 CPU、内存、磁盘、网络、进程和自定义指标。
架构介绍
夜莺在我们的体系里，当做一个后端服务对待，在 CDN 管理平台中通过 API 调用夜莺。我们直接使用二进制部署夜莺，只有一个二进制，使用 systemd 托管。
┌─────────────────────────────────────────────────────────────┐
│ 业务系统层 │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ CDN管理平台 │ │ Puppet │ │ 其他业务 │ │
│ │ (Go服务) │ │ (配置管理) │ │ │ │
│ └──────┬───────┘ └──────────────┘ └──────────────┘ │
│ │ API调用(标签管理、告警屏蔽等) │
└─────────┼────────────────────────────────────────────────────┘
│
┌─────────▼────────────────────────────────────────────────────┐
│ 夜莺监控层 │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Nightingale v8 Server │ │
│ │ - Web UI (告警规则、大盘、监控对象管理) │ │
│ │ - API Server (RESTful API) │ │
│ │ - Alert Engine (告警引擎) │ │
│ │ - Business Group (业务组管理) │ │
│ └────────────────┬─────────────────────────────────────┘ │
│ │ │
│ ┌────────────────▼─────────────────────────────────────┐ │
│ │ VictoriaMetrics (时序数据库) │ │
│ │ - Remote Write (接收categraf数据) │ │
│ │ - PromQL查询 (提供查询服务) │ │
│ │ - 高压缩存储 (10倍压缩率) │ │
│ │ - 长期存储 (支持数月甚至数年) │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
▲
│ Remote Write (Prometheus协议)
│
┌─────────┴────────────────────────────────────────────────────┐
│ 采集器层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Categraf │ │Categraf │ │Categraf │ │Categraf │ │
│ │ (节点1) │ │ (节点2) │ │ (节点3) │ │ (节点N) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ ┌────▼─────────────▼─────────────▼─────────────▼────────┐ │
│ │ 采集插件: CPU、内存、磁盘、网络、进程、自定义指标等 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
▲
│ 心跳上报
│
┌─────────┴────────────────────────────────────────────────────┐
│ 监控对象(Targets) │
│ 数千台CDN边缘节点服务器 │
│ - 标签: idc、region、cluster、role等 │
│ - 自动注册到夜莺 │
└──────────────────────────────────────────────────────────────┘
Categraf 需要在所有机器安装部署，涉及批量安装管理的问题，我们之前已经有 Puppet 做配置管理，继续使用 Puppet 安装管理 Categraf。Puppet模块结构:
console-puppet/modules/categraf/
├── files/ # 静态文件
├── manifests/ # Puppet配置清单
│ └── init.pp
└── templates/ # 配置模板
└── config.toml.erb
Categraf配置要点:
- hostname配置: 使用服务器FQDN作为唯一标识
- 采集间隔: 15秒
- Remote Write地址: 指向夜莺的指标写入端点
- 认证配置: Basic Auth用户名和密码
- 心跳上报: 启用心跳功能,自动注册监控对象
- 日志配置: 日志路径、轮转策略
批量部署流程:
- 在Puppet Master上更新categraf模块
- 通过Puppet Agent自动分发到所有节点
- Categraf自动启动并开始采集
- 通过心跳机制自动注册到夜莺
这套部署方式的关键是复用已有 Puppet 配置管理能力，而不是为 Categraf 单独建设新的分发体系。对于数千台边缘节点，采集器安装、配置更新、进程托管和心跳注册都必须自动化，否则监控系统本身会成为新的运维负担。
CDN管理平台集成夜莺
CDN 管理平台使用 API 操作夜莺，典型的操作和设计要点如下：
- 监控对象自动化管理
- 服务器上线时自动注册到夜莺
- 自动绑定到对应的业务组
- 自动打标签(IDC、集群、角色等)
- 服务器下线时自动删除或标记
- 告警自动化屏蔽
- 服务器下线时自动创建告警屏蔽规则
- 服务器上线时自动取消屏蔽
- 计划性维护时批量屏蔽告警
- 维护结束后自动恢复告警
- 标签动态管理
- 根据服务器属性自动生成标签
- 标签格式:
key=value - 常用标签: idc、cluster、role、region、isp等
- 支持标签的增删改查
- 告警事件查询
- 查询指定服务器的历史告警
- 查询指定时间范围的告警
- 支持按告警级别、状态过滤
- 用于故障分析和统计
- 异步队列处理
- CDN管理平台调用夜莺操作时，通过异步队列处理，避免阻塞主业务流程
- 支持失败重试机制
- 记录操作日志便于追踪
通过CDN管理平台与夜莺的深度集成,实现了完整的自动化运维闭环:
服务器上线
→ 自动注册到夜莺
→ 自动打标签(idc、cluster、role等)
→ 自动绑定业务组
→ 开始监控
→ 触发告警
→ 自动执行修复脚本
→ 自动恢复
服务器下线
→ 自动屏蔽告警
→ 自动解绑业务组
→ 自动删除或标记监控对象
这条闭环的价值在于把“服务器生命周期”和“监控对象生命周期”同步起来。服务器上线时自动进入夜莺监控，服务器下线或维护时自动屏蔽告警，避免值班人员收到已知无效告警；相关操作通过异步队列处理，也能减少对 CDN 管理平台主流程的影响。
实践建议
对 CDN、边缘节点或大规模主机监控团队来说，这个案例有三点可复用经验：
- 先设计标签体系：
idc、region、cluster、role、isp等标签会直接影响查询、告警路由和权限管理。 - 采集器部署要纳入配置管理：Categraf 的配置、认证、采集间隔、日志轮转和心跳上报都应通过 Puppet 等工具统一下发。
- 监控平台必须提供 API：对象注册、标签变更、屏蔽规则、事件查询等动作需要由业务管理平台自动调用，不能长期依赖人工操作。
FAQ
Q1：新浪 CDN 为什么选择夜莺 + VictoriaMetrics？ A：夜莺满足告警、权限、API 集成和多团队协作需求；VictoriaMetrics 满足高并发写入、PromQL 查询、长期存储和较低资源占用等时序数据需求。
Q2：Categraf 在方案中承担什么角色？ A：Categraf 部署在数千台 CDN 边缘节点上，通过 Remote Write 上报 CPU、内存、磁盘、网络、进程和自定义指标，并通过心跳机制自动注册监控对象。
Q3：为什么 CDN 管理平台要通过 API 集成夜莺？ A：CDN 节点上线、下线、维护、标签变化都发生在管理平台中。通过 API 集成夜莺，可以自动同步监控对象、业务组、标签和屏蔽规则，减少人工操作和配置漂移。
Q4：异步队列在集成中解决什么问题？ A：CDN 管理平台调用夜莺 API 时，异步队列可以避免阻塞主业务流程，并提供失败重试和操作日志追踪能力。
总结
新浪 CDN 的实践说明，大规模边缘节点监控的关键不只是采集指标，而是把监控平台纳入业务管理平台的自动化流程。夜莺提供告警、权限和 API 能力，VictoriaMetrics 承担时序数据压力，Categraf 和 Puppet 解决边缘节点采集器规模化部署，最终形成服务器生命周期和监控生命周期同步的闭环。
我们会继续深入使用夜莺,并积极参与社区建设,贡献我们的实践经验。希望这篇案例能够帮助更多的团队了解和使用夜莺监控系统。
夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏。
