Linux Cassandra告警策略与常见性能瓶颈分析

一、告警策略设计原则

1.1 告警黄金法则

• 行动导向：每条告警必须对应可操作的SOP（Standard Operating Procedure）
• 避免疲劳：阈值太松 → 漏警；太紧 → 噪声。目标：每日告警<10条
• 分级严重度：Critical（立即处理）、Warning（关注）、Info
• 抑制与聚合：同类告警聚合，故障期间抑制衍生告警
• 持续优化：每周复盘误报/漏报，调整阈值

1.2 告警来源

• Prometheus Alertmanager（第10篇规则为基础）
• Grafana内置告警
• 外部工具：PagerDuty、OpsGenie、企业微信

生产实践：Critical走电话/短信，Warning走群聊。

1.3 阈值设定方法

• 基线法：正常负载下采集1周数据，取P95/P99作为阈值
• 业务关联：延迟告警结合SLA（如P99<50ms）
• 动态阈值：大集群用rate()或increase()变化率

二、关键告警指标与推荐规则

基于第10篇Metrics，精选Top20告警（PromQL示例）。

生产优化：加for: 5m-15m避免瞬时抖动；annotations描述根因与SOP链接。

三、常见性能瓶颈分类与诊断流程

3.1 读延迟高（最常见）

症状：P99 Read Latency >100ms

诊断流程：

1. nodetool proxyhistograms → 确认读P99高
2. nodetool tablestats → SSTables per read >10？ → Compaction落后 → 检查pending_tasks
3. Bloom Filter miss高？ → 调bloom_filter_fp_chance
4. Tombstones高？ → 降低gc_grace_seconds或repair
5. 磁盘iostat慢？ → IO瓶颈 → 分离盘或SSD
6. GC暂停？ → jvm_gc_pause → 调Heap/GC

3.2 写延迟高

症状：Write Latency上升，MutationStage Pending高

流程：

1. nodetool tpstats → Write/Mutation Pending高
2. CommitLog盘iostat？ → 顺序写慢 → NVMe分离
3. Memtable offheap满？ → flush慢 → 增加flush_writers
4. concurrent_writes不足？
5. Dropped Write？ → 过载限流

3.3 吞吐下降/请求丢弃

症状：QPS掉、Dropped >0

流程：

1. ThreadPools Dropped → 哪个Stage？
2. ClientRequest Unavailable → 一致性未达
3. 节点Load不均 → 数据倾斜 → 检查Partition Key熵

3.4 空间异常增长

症状：Disk Used快速上升

流程：

1. nodetool cfstats → 哪个表空间大？
2. Tombstones/Deleted Cells高？ → TTL不当或删除风暴
3. Compaction不回收？ → 策略错（STCS墓碑多用TWCS）
4. Snapshots残留？ → nodetool listsnapshots清理

3.5 GC/内存问题

症状：延迟抖动、暂停

流程：

1. Grafana JVM面板 → GC时间长
2. Heap接近上限 → offheap不足
3. THP启用？ → disable
4. 大查询？ → 应用层分页

四、典型故障复盘案例

1. 读P99飙升到秒级：Compaction Pending 500+ → UCS自适应失败 → 回退LCS + 提高concurrent_compactors，恢复ms级。
2. 写超时频繁：CommitLog同Data盘 → IO竞争 → 分离NVMe，延迟降90%。
3. 凌晨空间告警：批量删除未设TTL → 墓碑爆炸 → 补repair + 调整gc_grace=0（短期）。
4. 单节点负载高：热点Partition → Key设计无熵 → 加盐或复合键。
5. 扩容后延迟抖：Streaming未限速 → 网络风暴 → 调stream_throughput。
6. GC暂停10s+：Heap 32G + CMS → 降16G + G1，暂停<1s。
7. Hints堆积百万：节点宕机一周 → 恢复后递交慢 → 手动truncate hints。
8. Dropped Read：大范围扫描查询 → 应用加ALLOW FILTERING限或二级索引。
9. Owns偏差20%：vnodes=256但节点异构 → 统一硬件或调num_tokens=32。
10. 5.0 Trie OOM：offheap_objects但Direct Memory不足 → ulimit -l unlimited + JVM -XX:MaxDirectMemorySize。

每个案例都强调：先看监控 → nodetool验证 → 日志确认 → 配置/应用调优。

五、生产告警最佳实践

• 沉默期：维护窗口抑制告警
• 依赖树：节点DOWN抑制衍生延迟告警
• 自动恢复：轻微告警自愈脚本（如nodetool cleanup）
• 周复盘：误报率>20%必调阈值
• 多维度：加标签（dc、rack）区分多DC告警

工具链：Alertmanager + Grafana OnCall + SOP文档。