指标设计的基本顺序
监控体系常见的失败方式是先堆工具与采集项，再讨论告警太多。合理的顺序相反：先明确监控对象与要回答的问题，再挑选能回答这些问题的指标，然后确定口径、采样粒度、阈值来源与响应动作。指标一旦上线就要定期复核，因为业务负载与硬件状态都会变化，去年合理的阈值今年可能天天误报或永远不报。
基本信息
| 设计步骤 | 明确对象与问题 → 选指标 → 定口径与采样 → 定阈值与分级 → 定动作与责任人 → 定期复核 |
|---|---|
| 指标分层 | 可用性状态类、性能类、容量与寿命类、配置与安全类 |
| 口径要求 | 采样粒度、聚合方式、标签维度三项固定并写入文档 |
| 基线来源 | 历史数据区间、设计指标、厂商参考值，优先用自身历史基线 |
| 避免做法 | 高基数标签、重复采集、只看瞬时值不看趋势、指标无对应动作 |
| 复核周期 | 结合业务变化与阈值误报率定期调整，调整需留记录 |
典型使用场景
- 新建存储监控体系，需要确定采什么、报什么、谁来处理时
- 告警数量失控，需要梳理指标、去掉无动作项时
- 接手他人搭建的监控，快速理解现有阈值的来源与合理性时
- 性能投诉需要数据佐证，补充延迟分位与队列类指标时
- 容量预测需要历史序列，补齐增长类指标的长期留存时
便于入库的采集输出
便于入库的采集输出
# 以键值形式输出，便于统一入库与做趋势
# 示例：把设备侧计数整理成带标签的指标行
printf 'storage_disk_errors{device="sdb"} %s\n' "$(smartctl -A /dev/sdb | awk '/Reallocated/{print $10}')"
printf 'storage_df_used_percent{mount="/data"} %s\n' "$(df --output=pcent /data | tail -1 | tr -d ' %')"
# 采集脚本要带超时与失败标记，避免静默断采
# 具体指标名与标签规范由团队约定，保持一致比好看更重要指标分层与判读
| 层次 | 代表指标 | 判读要点 |
|---|---|---|
| 可用性 | 卷状态、冗余状态、路径数量 | 状态类变化要立即报警，不做趋势等待 |
| 性能 | IOPS、带宽、平均与 P99 延迟、队列深度 | 必须含分位数并绑定基线 |
| 容量与寿命 | 池与卷用量、增长率、介质错误计数 | 看趋势与预测，不看单点绝对值 |
| 配置与安全 | 版本一致性、管理面访问、变更记录 | 漂移即风险，按周期核对 |
指标的第一判据是「有人会因它行动」。不存在响应动作的指标，要么补上动作，要么删除，否则只会稀释真正重要的告警。
只采集瞬时值不留历史序列，等于放弃了监控最重要的能力：趋势与预测。容量与介质错误这类指标，没有历史就没有判断依据。