最近研究运维/主机监控/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自带存储
适用场景          中小规模部署                大规模分布式监控