只需一步,快速开始
主题 692|帖子 692|积分 2076
1)规范问题:服务模块的语言和框架各异,日志格式不规范,分析困难; 2)管理问题:微服务模块众多,日志收集和管理困难; 3)成本问题:日志的保存和计算分析需要斲丧大量的资源,主要是存储计算资源,使用成本高;
日志到指标:基于网关日志分析接口、域名、渠道、端等维度的关键指标(流量、乐成率、延迟); 指标到大盘:网关日志分析计算出的维度指标(流量、乐成率、延迟)用作全局服务大盘/大屏的建设,用以观察服务的全局状态; 指标到日志:这类维度指标的生成来源于日志计算,自然可以实现指标到日志的关联,在发现指标趋势异常时,能够方便的调出相应时间的日志原文; 日志到链路:具体的日志原文中带有 traceid,或模块和接口的信息,基于此信息可打通trace体系,调出具体请求或模块的trace信息,展示请求的调用链路,分析调用异常的底层来源; 链路到日志:在trace的异常点下钻查询日志体系,调出对应模块和接口的具体日志,做进一步的异常判定; 日志到特征:另一个分析思路,基于网关日志做异常指标的特征分析,如,下单接口异常,则自动分析异常请求在来源IP、接入层实例分布、upstream分布等等维度上是否有聚集特征或特征变化,如果在某个特征上出现了特征的变化和聚集,则可以针对这类特征确定止损的方案或进一步追查的方向;
分析性价比高:网关日志通常较为规范,如Nginx日志,并且也容易治理,同时网关日志也最为靠近用户端,无论从分析和治理的难易度,以及分析的价值上看,都是最佳的选择; 治理性价比高:程序模块日志由于语言格式各异,治理难度高,且分析的价值大打折扣。治理的重点可以转移到落地trace体系上来,程序模块一旦使用了trace的sdk或agent,则可以输出规范的trace信息和有价值的定位信息。落地trace也会有相当的成本,但对雷同Java这类语言,成本会低很多,可以使用javaagent方案做到无侵入实现; 扬长避短:程序模块的日志原文格式可能各异也不标准,但异常日志的信息仍然是判定问题原因的告急依据,因此在这个过程中能在合适的分析步骤中查询调出即可,这部分日志的价值上风在于原文信息而不在于分析计算;
1)存量体系如何打通:指标、日志、trace都可能已经有各自独立的体系,如何串联融合不同体系的数据? 2)云上云下如何打通:很多企业使用了私有化和公有云的混淆云方案,日志可能也同时使用了私有化的ELK和云上的日志体系,如阿里云SLS和腾讯云CLS; 3)风险成本如何控制:如果为此要全部推导重建,用一套体系替换原有体系,风险和成本都太高,周期长也不可控;
数据源抽象:常见的开源和云上现有的可观测体系都可以作为一个数据源注册到 Flashcat; 数据交互:Flashcat 底层通过 API 和各数据源交互; 同一分析:上层对来自各个数据源的数据,特殊是日志数据做同一机动的配置和分析,生成各类自定义维度的报表和指标数据; 指标建设:日志生成的指标数据可以配置到北极星、灭火图,作为业务健康状态和体系健康状态的观测指标; 下钻关联:从 Flashcat 的北极星(业务健康度量化)和灭火图(体系健康度量化)可以下钻上面描述的问题分析路径,实现从业务异常的发现、到体系异常的范围收敛,到具体问题的分析确认的全链路串联;
您需要 登录 才可以下载或查看,没有账号?立即注册
使用道具 举报
本版积分规则 发表回复 回帖并转播
卖不甜枣