如何获得讲师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中提到了两类：任意值形式和连续性规则。具体的时间段选择和阈值设置需要根据实际波形来确定。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 