2. 容量规划基础：容量规划的定义与目标、日志平台容量模型（存储、计算、网络）、容量规划的输入与输出
2.1 容量规划的定义与核心目标
容量规划（Capacity Planning）是确保 IT 资源在满足当前业务负载的同时，能够以可预测的成本和性能水平支撑未来增长的系统性方法。在日志平台场景中，容量规划直接决定了数据写入延迟、查询响应时间以及历史数据的可回溯周期。
核心目标：在“资源过度供应”与“资源不足导致服务降级”之间找到最优平衡点，使日志平台始终运行在健康水位。
| 目标维度 | 说明 | 日志平台关键指标 |
|---|---|---|
| 性能保障 | 确保写入吞吐与查询延迟满足 SLA | 写入 TPS、P99 查询延迟 |
| 成本控制 | 避免过度采购硬件或云资源 | 每 TB 存储成本、每万条日志写入成本 |
| 可扩展性 | 容量模型支持水平扩展，无单点瓶颈 | 节点数 vs 吞吐量线性度 |
| 数据持久性 | 满足合规保留周期，防止数据丢失 | 副本因子、磁盘利用率、冷热数据比例 |
2.2 日志平台容量模型：存储、计算、网络
日志平台的容量模型可拆解为三个相互耦合的资源域。任何单一维度的瓶颈都会导致整体服务质量下降。
2.2.1 存储容量模型
存储是日志平台最直观的容量约束。模型需考虑原始数据量、压缩比、副本因子以及索引开销。
有效存储容量 = 原始日志量 × (1 / 压缩比) × 副本因子 × (1 + 索引膨胀率)
示例：
原始日志量 = 10 TB/天
压缩比 = 5:1（Gzip）
副本因子 = 2
索引膨胀率 = 15%
有效存储容量 = 10 × (1/5) × 2 × 1.15 = 4.6 TB/天| 参数 | 典型值范围 | 影响因素 |
|---|---|---|
| 压缩比 | 3:1 ~ 8:1 | 日志文本重复度、编码格式（Gzip/Zstd） |
| 副本因子 | 1 ~ 3 | 高可用策略、数据恢复时间目标（RTO） |
| 索引膨胀率 | 10% ~ 30% | 字段数量、分词粒度、索引类型（倒排/列存） |
2.2.2 计算容量模型
计算资源主要消耗在数据写入（解析、索引、分词）和查询（聚合、过滤、排序）两个阶段。模型通常以 CPU 核心数和内存大小作为主要约束。
写入所需 CPU = 日志条数/秒 × 单条处理耗时(ms) / 1000
查询所需 CPU = 并发查询数 × 平均查询耗时(ms) / 1000
示例：
写入 50,000 条/秒，单条处理 0.5ms → 25 核
并发查询 20 个，平均耗时 800ms → 16 核
总计算需求 ≈ 41 核（不含系统开销）
容量规划提示：计算容量需预留 20%~30% 的缓冲水位，用于应对突发流量峰值和版本升级期间的资源消耗增加。
2.2.3 网络容量模型
网络带宽决定了数据从采集端到存储节点的传输能力，以及跨节点数据同步的效率。瓶颈通常出现在日志采集 Agent 与 Broker 之间，以及存储节点间的副本同步链路。
| 网络路径 | 流量方向 | 带宽计算公式 |
|---|---|---|
| 采集 → Broker | 上行 | 原始日志量(GB/s) × 网络协议开销(1.1~1.3) |
| Broker → 存储 | 上行 | 压缩后日志量(GB/s) × 副本因子 |
| 存储节点间同步 | 内网 | 压缩后日志量(GB/s) × (副本因子 - 1) |
| 查询响应 | 下行 | 查询结果集大小(MB) × 并发查询数 / 响应时间 |
2.3 容量规划的输入与输出
容量规划不是一次性的估算活动，而是一个持续迭代的闭环流程。清晰的输入与输出定义是保证规划结果可落地、可验证的前提。
2.3.1 输入要素
- 业务增长预测：未来 6~18 个月的日志量增长率（通常参考历史月环比 + 业务线扩展计划）。
- SLA 要求：写入延迟上限、查询 P99 响应时间、数据可用性百分比。
- 数据保留策略：热数据保留天数、温数据保留月数、冷数据归档周期。
- 版本升级计划：目标版本对资源消耗的变化（如新索引格式、压缩算法变更）。
- 硬件/云资源清单：现有节点规格、磁盘类型（SSD/HDD）、网络带宽上限。
2.3.2 输出产物
| 输出项 | 内容描述 | 使用场景 |
|---|---|---|
| 容量基线报告 | 当前各资源域利用率、峰值水位、瓶颈点 | 日常运维、故障排查 |
| 增长预测模型 | 按时间轴（月/季度）的资源需求曲线 | 预算编制、采购申请 |
| 版本升级影响评估 | 目标版本对存储/计算/网络的增量需求 | 升级窗口规划、回滚预案 |
| 扩容建议方案 | 扩容节点数、规格、时间窗口、成本估算 | 变更执行、架构评审 |
常见误区：只关注存储容量而忽略计算和网络。日志平台在版本升级后，经常出现因查询语法变更导致 CPU 消耗激增，或副本同步带宽打满引发写入积压。容量规划必须三域联动。
2.4 容量规划闭环：从输入到决策
完整的容量规划流程应形成 PDCA 循环：
- Plan（计划）：收集输入，建立基线，设定增长模型。
- Do（执行）：根据规划进行扩容或版本升级。
- Check（检查）：监控升级后实际资源消耗，对比规划预期。
- Act（改进）：修正模型参数，更新下一轮规划输入。