堆叠日志与告警关注点
堆叠的故障大多先在日志里露头：成员加入或退出、主备角色重选、MAD 检测触发与动作、堆叠口震荡，都会留下记录。把这几类事件纳入统一告警订阅并落实到值班处理，能把事后追溯变成事中响应。要注意不同版本的日志关键字不同，先用全量日志确认实际用词，再固定过滤词，否则订阅会漏事件。
基本信息
| 关注事件 | 成员加入退出、角色选举、MAD 检测与动作、堆叠口震荡 |
|---|---|
| 查看方式 | display logbuffer 全量查看后再按关键字过滤 |
| 留档要求 | 日志缓冲区会滚动覆盖，重要事件及时导出 |
| 告警要求 | 选举与 MAD 事件必须告警到人，不能只靠硬件告警 |
| 版本差异 | 关键字与严重级别随版本变化，需现场确认 |
典型使用场景
- 把成员退出事件与业务中断时间比对，判断是否存在真实影响
- 主备角色重选单独设告警，避免被其他日志淹没
- MAD 检测事件必须响应，它意味着堆叠可能已分裂
- 堆叠口反复 Up/Down 纳入接口告警，追查线缆与光模块
- 周期性导出关键日志，形成可检索的运维档案
日志过滤参考
日志过滤参考
display logbuffer | include Stack # 堆叠相关事件
display logbuffer | include MAD # 分裂检测与动作
display logbuffer # 需要上下文时全量查看
display trapbuffer # 配合查看告警缓存事件与处置方向
| 日志事件 | 安全隐患 | 处置方向 |
|---|---|---|
| 成员退出加入 | 业务中断与管理面波动 | 核对业务路径并确认成员是否重新入堆 |
| 角色选举变化 | 主备切换伴随短暂转发中断 | 确认切换原因，排除堆叠链路问题 |
| MAD 检测动作 | 堆叠可能已分裂，双主风险 | 立即核查物理连接与协议配置 |
| 堆叠口震荡 | 带宽下降与反复收敛 | 查线缆、光模块与端口错误计数 |
只订阅硬件与电源类告警会漏掉选举与 MAD 这类纯软件事件，而这恰恰是堆叠故障最常见的入口，订阅清单要按事件类型而非按硬件模块划分。
日志缓冲区容量有限、按时间滚动覆盖，故障处理期间要第一时间导出原始日志，避免关键证据被后续日志冲掉。