在 Apache Storm 中，监控和告警机制的常见设计思路是什么？为了实现对 Topology 的实时监控，通常需要关注哪些指标和采用什么手段？
考察说明
考查对 Storm 集群和 Topology 运行监控体系的理解，以及设计告警机制的实际经验。
回答思路
- 【回答框架 1】Storm 监控主要关注集群资源和 Topology 运行状态两大类指标。集群层面包括 Nimbus、Supervisor 进程健康、ZooKeeper 连接、各节点 CPU/内存/磁盘、网络 IO；Topology 层面包括各 Spout/Bolt 的吞吐量、延迟、失败率、Queue 积压、Executors 数量等。
- 【回答框架 2】实时监控通常基于 Storm UI 的 REST API 获取 Topology 和集群统计信息，可定时拉取并存入时序数据库，再用 Grafana 等工具展示。更精细的监控可通过在 Spout/Bolt 中自定义计数器，利用 Storm 内置的 metrics 框架上报自定义指标，或接入外部监控系统如 Graphite、Prometheus。
- 【回答框架 3】告警机制一般基于阈值规则，对关键指标设置阈值，如 Spout 发送失败率、Bolt 处理延迟、集群资源使用率等。当指标持续超过阈值时，通过邮件、短信、即时通讯工具发出告警，并可将告警信息关联到 Topology 的重启或升级流程。
- 【回答框架 4】为确定合理阈值，需结合历史监控数据做基线分析，并区分瞬时抖动和持续异常。监控和告警本身也可能成为瓶颈，需控制数据采集频率和存储量。
- 【回答框架 5】对于 Topology 的实时监控，优先保证指标采集的及时性和准确性，同时监控系统自身需具备高可用，避免单点故障导致监控失效。
- 【关键点 1】监控指标包括集群资源（CPU、内存、磁盘、网络）和 Topology 运行指标（吞吐量、延迟、失败率、Queue 积压）。
- 【关键点 2】常见实现为通过 Storm UI REST API 拉取数据，结合时序数据库和 Grafana 展示，或使用自定义 metrics 上报。
- 【关键点 3】告警机制基于阈值规则，需区分瞬时抖动和持续异常，并关联重启或升级流程。
- 【关键点 4】监控系统自身需要高可用，避免单点故障。
- 【关键点 5】合理阈值需基于历史基线分析确定。
- 【易错点 1】不要只关注 Topology 指标而忽略集群资源指标，可能导致资源耗尽而未被发现。
- 【易错点 2】告警阈值设置不合理（过灵敏或过迟钝）会导致大量误报或漏报，需动态调整。
- 【易错点 3】监控系统本身可能成为瓶颈，采集频率过高会占用网络和计算资源。