采集频率的取舍
采集频率决定了观测能看见什么：秒级粒度抓得住秒级抖动，但采集端、网络与时序库的写入成本随频率线性上升。常态下 10-60 秒足够看清趋势，压测与故障窗口再临时提到秒级。计数类指标要按两次采样的差值算速率，而差值逻辑必须处理实例重启导致的计数归零，否则会算出负速率或异常尖峰。
基本信息
| 常态频率 | 10-60 秒，按实例规模与存储成本确定 |
|---|---|
| 故障窗口 | 临时提到 1-5 秒，排查结束回落 |
| 数据来源 | INFO 的 stats、memory、clients、replication 等区块 |
| 计数处理 | 取差值算速率，注意重启归零与主从切换重置 |
| 成本构成 | 采集端 CPU、网络往返、时序库写入与保留周期 |
典型使用场景
- 容量趋势：低频采集用于观察 used_memory 与键数的长周期走向
- 故障取证：临时提频，把延迟尖峰对应到具体时间点
- 压测观测：秒级采集配合压测轮次，看水位随并发变化
- 告警定阈：先按常态频率跑一段时间，用真实分布定阈值
- 成本控制：实例多时降单实例频率，关键实例保持高频
只采需要的字段
只采需要的字段
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses' # 速率与命中
redis-cli INFO memory | grep -E 'used_memory_human|mem_fragmentation_ratio' # 水位与碎片
redis-cli INFO clients | grep -E 'connected_clients|rejected_connections' # 连接与拒绝
redis-cli INFO stats | grep total_commands_processed # 累计计数，差值算速率
redis-cli INFO stats | grep total_net_input_bytes # 带宽用量趋势各区块看什么
| 区块 | 关键字段 | 频率建议 |
|---|---|---|
| stats | total_commands_processed、keyspace_hits/misses | 30-60 秒，用差值算速率 |
| memory | used_memory、mem_fragmentation_ratio | 30-60 秒，看趋势为主 |
| clients | connected_clients、rejected_connections | 10-30 秒，拒绝事件要及时看见 |
| latency | latency_percentiles_usec 系列（需先开启监控） | 秒级，用于配合延迟排查 |
采集脚本要识别重启：累计计数从大数归零时按新基线重新起算。实例升级、主从切换同样会重置计数，识别不出来就会在每次发布后误报一轮。
秒级高频采集长期开启会给采集端和 Redis 自身都增加负担，INFO 本身也要占用主线程时间；排障窗口结束后把频率降回常态，别让它长期运行。