vs和dw做网站的区别,做网站绍兴,公司网站网页设计,株洲天元区指标、日志、链路是服务可观测性的三大支柱#xff0c;在服务稳定性保障中#xff0c;通常指标侧重于发现故障和问题#xff0c;日志和链路分析侧重于定位和分析问题#xff0c;其中日志实际上是串联这三大维度的一个良好桥梁。
但日志分析往往面临成本和效果之间的权衡问…指标、日志、链路是服务可观测性的三大支柱在服务稳定性保障中通常指标侧重于发现故障和问题日志和链路分析侧重于定位和分析问题其中日志实际上是串联这三大维度的一个良好桥梁。
但日志分析往往面临成本和效果之间的权衡问题没有完美的方案只有适合的方案本文将结合实战经验介绍一种日志分析的实现分析如何在稳定性保障中用好日志这个维度以及日志如何与指标、链路相互配合形成故障定位的最佳实践。
日志分析难点 1规范问题服务模块的语言和框架各异日志格式不规范分析困难 2管理问题微服务模块众多日志收集和管理困难 3成本问题日志的保存和计算分析需要消耗大量的资源主要是存储计算资源使用成本高 日志分析方案
本文推荐一种在稳定性保障中经过考量和实战的日志分析方案。故障处理场景中日志分析的核心思路 日志到指标基于网关日志分析接口、域名、渠道、端等维度的关键指标流量、成功率、延迟指标到大盘网关日志分析计算出的维度指标流量、成功率、延迟用作全局服务大盘/大屏的建设用以观察服务的全局状态指标到日志这类维度指标的生成来源于日志计算天然可以实现指标到日志的关联在发现指标趋势异常时能够方便的调出相应时间的日志原文日志到链路具体的日志原文中带有 traceid或模块和接口的信息基于此信息可打通trace系统调出具体请求或模块的trace信息展示请求的调用链路分析调用异常的底层来源链路到日志在trace的异常点下钻查询日志系统调出对应模块和接口的详细日志做进一步的异常判断日志到特征另一个分析思路基于网关日志做异常指标的特征分析如下单接口异常则自动分析异常请求在来源IP、接入层实例分布、upstream分布等等维度上是否有聚集特征或特征变化如果在某个特征上出现了特征的变化和聚集则可以针对这类特征确定止损的方案或进一步追查的方向 优点和权衡
这个方案的优点和权衡点在于 分析性价比高网关日志通常较为规范如Nginx日志并且也容易治理同时网关日志也最为靠近用户端无论从分析和治理的难易度以及分析的价值上看都是最佳的选择治理性价比高程序模块日志由于语言格式各异治理难度高且分析的价值大打折扣。治理的重点可以转移到落地trace系统上来程序模块一旦使用了trace的sdk或agent则可以输出规范的trace信息和有价值的定位信息。落地trace也会有相当的成本但对类似Java这类语言成本会低很多可以使用javaagent方案做到无侵入实现扬长避短程序模块的日志原文格式可能各异也不标准但异常日志的信息仍然是判断问题原因的重要依据因此在这个过程中能在合适的分析步骤中查询调出即可这部分日志的价值优势在于原文信息而不在于分析计算 该方案以日志为中心实现了一条日志、指标、trace相互串联的问题发现和分析路径这条路径也是故障问题分析的典型路径。
同时从方案的落地和推动成本上来讲也是一个比较合适的取舍。如果可观测产品支持好这条路径信息的串联会大幅提升异常问题定位分析的效率。
方案落地要点
混合云资源、观测系统众多是目前很典型的企业基础设施现状在此基础上要实现这个方案可能需要重点解决以下几个问题 1存量系统如何打通指标、日志、trace都可能已经有各自独立的系统如何串联融合不同系统的数据 2云上云下如何打通很多企业使用了私有化和公有云的混合云方案日志可能也同时使用了私有化的ELK和云上的日志系统如阿里云SLS和腾讯云CLS 3风险成本如何控制如果为此要全部推导重建用一套系统替代原有系统风险和成本都太高周期长也不可控 产品实践
这里介绍快猫星云的 Flashcat 是如何解决这些问题的。 数据源抽象常见的开源和云上现有的可观测系统都可以作为一个数据源注册到 Flashcat数据交互Flashcat 底层通过 API 和各数据源交互统一分析上层对来自各个数据源的数据特别是日志数据做统一灵活的配置和分析生成各类自定义维度的报表和指标数据指标建设日志生成的指标数据可以配置到北极星、灭火图作为业务健康状态和系统健康状态的观测指标下钻关联从 Flashcat 的北极星业务健康度量化和灭火图系统健康度量化可以下钻上面描述的问题分析路径实现从业务异常的发现、到系统异常的范围收敛到具体问题的分析确认的全链路串联 Flashcat 问题下钻分析路径 总结
本文介绍了稳定性保障中日志分析系统建设面临的问题、挑战、需求和建设中的权衡取舍。并介绍了 Flashcat 如何解决这些问题做到效果和成本最佳也最具落地的可行性。
