如何获得讲师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稳定性技术交流平台立场,如若转载,请联系原作者。