最近研究运维/主机监控/AIOps/容灾备份系统，现分析夜莺监控系统各个环节的资源压力对比：
1. Categraf (采集端)
资源类型 典型消耗 压力点
--------------------------------
内存 30-50MB • 采集项过多时内存上升
CPU 1-5% • 采集频率过高
磁盘IO 很少 • 主要是日志写入
网络 较轻 • 数据上报带宽
主要压力来源：
- 采集指标数量
- 采集频率设置
- 并发采集任务数
2. Transfer (传输层)
资源类型 典型消耗 压力点
--------------------------------
内存 1-2GB • 数据缓冲队列
CPU 10-30% • 数据解析和转发
网络 中等 • 上下行数据传输
磁盘IO 中等 • 数据落盘(如果配置)
关键压力点：
- 大量 agent 同时上报
- 数据转发队列堆积
- 网络带宽瓶颈
3. Index (索引服务)
资源类型 典型消耗 压力点
--------------------------------
内存 4-8GB • 索引缓存
CPU 20-40% • 索引更新计算
磁盘IO 较高 • 索引持久化
网络 中等 • 集群同步
主要压力：
- 指标元数据更新
- 索引重建
- 查询请求处理
4. TSDB (时序数据库)
资源类型 典型消耗 压力点
--------------------------------
内存 8GB+ • 数据缓存
CPU 30-50% • 数据压缩/查询
磁盘IO 很高 • 数据写入/查询
磁盘空间 取决于保留策略 • 历史数据存储
关键压力：
- 写入吞吐量
- 查询并发
- 数据压缩和清理
5. 告警模块
资源类型 典型消耗 压力点
--------------------------------
内存 2-4GB • 规则计算
CPU 10-30% • 告警判断
网络 较轻 • 告警通知
磁盘IO 中等 • 历史记录
压力来源：
- 告警规则数量
- 告警计算频率
- 通知发送量
对比Prometheus
特性 Categraf Node Exporter + Prometheus
----------------------------------------------------------------
部署复杂度 低(单个agent) 高(需要多个组件)
资源占用 较低 中等到较高
配置管理 统一、简单 分散、相对复杂
监控能力 一体化 需要多个exporter配合
社区支持 夜莺社区 大型开源社区
扩展性 内置插件机制 独立exporter开发
数据存储 推送到夜莺 Prometheus自带存储
适用场景 中小规模部署 大规模分布式监控