写文章

去哪儿网《1-5-10故障体系建设—秒级监控预警落地实践》

• 课程学习 • 阅读 382

如何获得讲师PPT：

扫码关注公众号，后台回复「Q419」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

走出故障迷局的三重奏：逃生、复盘和推演

Q&A环节答疑：

1、定位是怎么做的？有考虑把metric和trace结合么？

定位这块儿我简单跟大家说一下在故障定位阶段根因分析的思路。我曾分享过相关文章，如果大家感兴趣，可以去查看“去哪儿网根因分析实践”。我们考虑将metric和trace结合，这涉及到我们的定位工作。metric和trace已在早期结合，大约在2018年或2019年。我们的trace系统是自研的，名为Qtrace；我们的metric也是自研的，我们的采集器名为Qmonitor。因此，我们能够自然地将它们结合。在采集metric指标时，我们会调用trace的SDK API，将metric指标与其流经的链路关联，并存储在ES中。这样，我们可以根据指标名和时间范围查询特定时间段内的trace，也可以根据trace反查metric。我们很早就实现了这种结合，

因为定位的核心思路，即结合可观测性的三要素：metric、trace和log进行定位。无论是故障还是报警，都依赖于指标。指标和trace结合之后，在报警或故障期间，我们会将报警相关的指标与trace关联，然后根据链路定位报警应用的下游，重点是排查下游，同时也会排查一些特殊的上游应用，如异常或核心报警。我们会根据链路上可能的异常应用进行排查，然后根据异常应用进行深入分析，比如运行时的主机、数据库状态、事件变更和异常日志等。收集这些异常数据后，我们会根据设置的权重体系进行排序，并调用我们的AI模型，如AI Agent，通过人工智能给出top3或top5的答案，这是我们整体定位的思路。

2、我也有这个问题，监控的时候，数据量大幅增加，怎么来优化存储方案来提高效率和降低成本？ 

数据量增加的原因是因为监控粒度从分钟级变为秒级，甚至更细，导致数据膨胀可能达到几十倍。原先使用的graphite存储系统，其whisper格式是固定的，创建指标时会根据预配置自动生成固定大小的文件。例如，如果原来是每分钟存储一个数据点，一年的数据量在变为秒级监控后，存储需求将增加几十倍，导致原有存储容量不足。

因此，我们探索了新的存储方案，重点考察了M3DB和VictoriaMetrics（VM）。最终选择了VM，因为它在查询和存储性能上表现优异，并且没有whisper的预分配问题，压缩比也更高，大约是whisper的8到10倍。这样的压缩比有助于优化存储并降低成本。

秒级监控的主要目的是为了更快地发现问题，因此我们对接入秒级的指标有所限制，并不是所有指标都需要以秒级监控，而是选择适合秒级监控的指标，如核心指标，以便进行深入分析。此外，我们的存储策略是自动保存秒级指标30天，这样既能通过技术选型优化存储，又能确保秒级监控的定位符合快速发现问题的需求。

3、配置秒级报警时，你们是怎么设置报警阈值和规则？

我们的情况分为两类：一是报警阈值的规则设置，二是秒级雷达的引入。对于规则设置，我们会根据指标的日常趋势变化进行配置，因为不同时间段的趋势可能不同。例如，从早上十点到下午三点的趋势与下午四点到晚上九点的趋势不同，我们会为每个时间段细致地设置阈值。在节假日高峰期间，我们也会实施分钟级和秒级监控，并行运行，同时为秒级监控设置临时规则以应对节假日的特殊情况。关于规则，我们的PPT中提到了两类：任意值形式和连续性规则。具体的时间段选择和阈值设置需要根据实际波形来确定。

4、告警的延迟和误报问题也是让人比较头痛的，老师们看有没有什么好的解决方案？

我们从业务方的角度出发，采取了多种措施来应对延迟问题。除了使用不同级别的监控工具，如分钟级和秒级监控外，我们还根据不同的报警模板和触达方式（包括电话、内部工作群和QT）并行通知，以确保信息能够迅速传达。 在减少误报方面，我们进行了大量的调整工作。无论是规则还是雷达，我们都在前期进行了人工运维，包括预值的准确性、时间段选择的合理性以及每周的有效率。我们会根据统计数据评估有效率是否达到标准，如果没有，我们会分析具体原因，包括哪个指标或分类出现问题。 对于雷达，我们将指标分为多个层级，包括时间型、失败率型、成功率型等，并根据波形进一步细分为连续型、周期型、抖动型、离散型和平稳型。针对每种波形和分类，我们定义了不同的优先级（P1、P2、P3、P4），每个优先级的规则和时间段的阈值范围都有所不同。这些都需要我们在前期进行人工运维和调整，以达到真正的准确率和有效率标准。一旦达到标准，我们会停止调整，并继续观察以确保持续满足要求。

5、告警后有进一步的自动分析场景吗？

是的，自动分析和自动定位的能力，这是基于我们的分析系统，我先前提到的是实践思路。我可以分享一下我们的运营策略，即具体的实施方法。我们的监控系统会监听报警和故障。一旦检测到核心报警，我们会自动触发根因分析，并将分析结果推送给相关人员，包括电话通知相关人员。同时，我们也会提供一份分析报告。 我们会配置核心面板，并根据这些面板设置核心报警，这些都是可配置的。例如，我们可以在配置中心设置自动根因分析触达。一旦报警触发，我们会自动进行分析，并支持将结果推送给个人或群组，如工作群。 对于故障处理，我们也在不断建设故障平台。该平台能够自动报告故障并健全我们的响应机制。我们的分析系统会监听故障动作，一旦检测到故障，我们会及时获取故障信息，包括受影响方、故障开始时间等，并调用根因分析以获得结果。然后，我们会综合分析报告，并利用AI大模型将结果推送到故障群中。以昨天的某故障为例，我们及时推进并确定了故障原因，结果显示分析还是挺准确的。

6、另外后续引入AI有初步的思路和方向吗？

我们对更新分析的实践思路是将定位到的异常案例与我们的权重体系结合起来进行排序。排序后的结果将被提交给我们的大模型，该模型主要由我们公司的算法团队负责。此外，我们可能会利用embedding技术或通过其他方式整合我们自己的外部数据和领域知识。我们还采用思维链的方式调用我们自己的AI代理（Ai agent）来得出结果。这是一个大致的实现思路，具体的AI支持也是由我们的算法团队提供的，后续有机会可以和大家一起交流一下。

7、从实践来看，trace断链率对定位效果的影响怎么样？

断链对定位的影响确实很大。在进行根因分析时，我们前期做了大量的工作，主要是推动架构团队解决断链率问题。我们分析了许多trace，探究为何会出现断链，例如是否因为异步操作。我们的团队非常强大，能够确保即使使用公司的组件如QMQ等，即使是异步操作，链路也不会中断，除非使用了外部一些非常小众的异步框架，才可能导致链路断裂。我们的数据性能稳定，经过治理后，断链现象减少。当然，我们也有降级策略。如果链路中断，我们可能会通过TC同学维护的知识图谱来进行降级分析，但这可能不如直接分析准确，因为它可能会引入与本次报警无关的应用，尤其是在这些应用存在较大问题时。

本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。

赞 (1)
0 0 打赏 微信扫一扫 微信扫一扫
上一篇 2024年9月26日 下午5:09

相关推荐

发表评论

邮箱地址不会被公开。