Java|行业 SaaS 微服务稳定性保障实战( 四 ) 组织架构|阿波罗|jvm

随着应用越来越多，对于可观测性和稳定性的诉求也越来越多。因此，我们自研了一套简单的根因分析系统，通过文本相似度算法将当前服务日志进行归类聚类分析。
简版根因分析上线
上图为典型 ONS 故障，依赖服务进行服务升级。如果这是通过日志抓取智能分析出来的日志，做了很长时间 SRE 后，变更也会对于线上稳定性造成很大破坏。如果能将变更等也收集到可观测体系中，将会带来很大好处。同理，如果能将 ONS 要升级的信息收集到可观测体系统中，通过种种事件关联，能够分析出根因，对于系统稳定性和问题排查将极为有益。
ARMS 支持 traceId 透出 responseHeader
F6 公司和 ARMS 团队也进行了深入合作，探索了可观测的最佳实践。 ARMS 近期退出了一项新功能，将 traceID 直接透出到 HTTP 头，可以在接入层日志中将它输出到对应日志，通过 Kibana 进行检索。
客户在发生故障时，将日志信息和 traceID 一起上报给技术支持人员，最后研发人员可通过 traceID 快速定位到问题原因、上下游链路，因为 traceID 在整个调用链路中是唯一的，非常适合作为检索条件。
同时， ARMS 支持直接通过 MDC 透传 traceID，支持 Java 主流日志框架，包括 Logback、Log4j、Log4j2 等，也可以将 traceID 作为标准 Python 输出。
上图展示了典型的日志输出场景下 ARMS 的后台配置，可以打开关联业务日志和 traceID，支持各种各样的组件，只需在日志系统中定义 eagleeye_traceid 即可输出 traceID 。
上述方案较为简单，研发的修改也很少，甚至可以做到免修改，且对于 Loggin 和 Trace 的关联程度做到了较大提升，减少了数据孤岛。
ARMS 支持运维告警平台
ARMS 为进一步降低 MTTR，提供了很多数据，但是数据如何到达 SRE 、DevOps 或研发运维人员手里，依然需要花费一些心思。
因此， ARMS 上线了运维告警平台，通过可视化方式完成了告警转发、分流等事件处理，可以通过静默功能、分组等，支持多种集成方式。目前 F6 在用的包括 Prometheus、buffalo、ARMS 以及云监控，其中云监控包含了包括 ONS、Redis 在内的很多数据，研发人员或 SRE 人员在钉钉群里认领对应的响应事件即可。同时还支持报表、定时提醒、事件升级等功能，便于事后复盘和改善。

上图为线上处理问题的界面截图。比如钉钉群里的告警会提示上一次相似告警由谁处理、告警列表以及对应事件处理流程等。同时，还提供了过滤功能，可以分割内容，通过字段丰富或匹配更新等方式替换内容填充模板，用于精准告警，比如识别到应用名称后，可以关联到对应应用的 owner 或告警人员。此功能后续也将逐步替代前文用 Go 语言写的 Apollo SDK 应用。
Java 生态免修改注入 agent 方式-JAVA_TOOL_OPTIONS
同时，我们也借鉴了 ARMS 免修改注入 Agent 的方式。 ARMS 通过one point initContainer 的方式注入了很多 ARMS 信息，也挂载了一个名为 home/admin/.opt 的 mount 用于存储日志。正因为有 initContainer，它才能够实现自动升级。
在 initContainer 中，可以通过调用 ARMS 接口获取到当前 ARMS Agent 最新版本，然后下载 Java Agent 最新版本，放到 mount 目录下，与目录下对应的数组 Pod 进行通信，通过共享 volume 的方式完成 Java Agent 共享。过程中最核心的点在于，通过 JAVA_TOOL_OPTIONS 实现了 Java Agent 挂载。
通过上述方式，我们模拟了一套流程，通过openkruise 组件 workspread 使用 patch 方式修改 deployment 。最简单的实践是利用 openkruise workspread给对应的 deployment 打注解，从而使得无需由研发或 SRE 团队进行处理，只要编写对应 CRD 即可， CRD 过程直接注入 JAVA_TOOL_OPTIONS（见上图右下角代码）。其应用场景也较为丰富，可以做应用流量回放、自动化测试等。