在本次更新中，为了进一步加快排障速度，Kindling-OriginX优化了故障诊断页面，自动将故障节点的上下游关系关联起来，并展示了节点的响应耗时，使故障节点间的依赖关系和耗时相关性一览无余，在多节点发生故障时更容易找到根因；我们还在首页中将SLO状态与请求次数关联在一起，辅助用户判断SLO状态变化的原因。
从该版本开始，OriginX安装后开箱即用，无需再对接外部 Tracing 系统，我们大大简化了安装过程，欢迎安装试用！
自动关联故障节点的上下游关系，通过延时曲线辅助判断根因节点
在之前的版本中，我们创新性地通过北极星指标识别出故障的初步原因，并展示在故障诊断页面中，在单节点发生问题时，用户能够依据故障初因快速排障。但当同一个链路中的多个节点同时发生故障时，仅靠查看故障初因难以在多个节点之间找到联系。
为了解决这一难题，Kindling-OriginX自动化地分析出故障节点之间的上下游关系，并将其展示在故障诊断页面中，一览无余地展示了多个故障节点的调用关系；再辅助查看服务的延时曲线，能够快速在多故障节点的场景中识别出故障的源头，避免多次打开故障报告。
在下图的场景中，入口服务节点ts-travel-service发生了故障，其中有42%的初因故障节点是ts-seat-service，有44%的初因故障节点是ts-order-service，其中ts-seat-service调用了ts-order-service，在延时上存在直接的相关性。
分析ts-seat-service和ts-order-service的延时曲线以及故障初因可知，两个节点都是造成入口服务延时升高的罪魁祸首。最终分析根因报告发现，是ts-order-service节点的网卡中存在200ms的网络延时，导致ts-seat-service调用ts-order-service延时升高，同时ts-order-service调用下游的延时也升高。
将SLO状态与请求次数关联在一起
为了监控服务健康度，请求次数、请求延时与错误率三者缺一不可。通过将SLO状态与请求次数关联在一起，您能够清晰地了解当前服务的健康状态。当发生SLO违约时，根据请求次数变化能够理解SLO违约是否因请求量变化导致。
在上图所示的场景中，当延时SLO违约时，每分钟请求量发生了小规模下降，这说明故障不是由于请求量突增导致的。
更多新特性请查看下述更新列表。
新增功能
首页新增入口“所属服务名”，方便进一步检索
入口服务新增“每分钟请求量”指标，方便了解当前入口流量状态
重新设计了故障诊断页面，进一步加快排查故障的速度
简化安装使用流程，一键部署，无需对接其他系统
功能优化
加快获取响应延时历史基线，帮助用户更早地发现问题
新增配置允许将抛出exception的请求判定为错误请求
优化故障推理中网络故障的推理过程和描述
适配 Opentelemetry Java Agent 2.x 版本
优化降低探针的 CPU 和内存占用
缺陷修复
修复“故障初因”与故障根因报告结论不一致的问题
修复 SLO 延迟性目标未及时更新的问题
修复错误故障的根因报告中可能缺失日志数据的问题
其他
支持对接 Elastic APM 系统
