Java|行业 SaaS 微服务稳定性保障实战( 三 )

JmxExporter 快速支持云原生 Java 组件的 jvm 信息展示
进行云原生化改造后，监控模型也发生了改变。最早的监控模型是 push ， Zorka 每次发布都在同一台机器上，因此它有固定的 host；而上云后，容器化改造导致 Pod 不再固定，且可能会出现新的应用扩缩容等问题。因此，我们将监控模型逐步从 push 转换成 pull 模式，也更加契合 Prometheus 的收集模型，并逐步将 Zorka 从可观测体系中剥离。
没有使用 ARMS 直接收集 JMX 指标是因为 ARMS 不会覆盖线上和线下所有 java 应用，没有被覆盖的应用也期望有 JVM 数据收集功能，而 ARMS 成本略高。因此，出于成本的考虑，我们没有将 ARMS 作为完整接入，而是选择了 JMX Exporter 组件。
JMX Export 也是 Prometheus 官方社区提供的 exporter 之一。它通过 Java Agent 利用 Java JMX 机制读取 JVM 信息，可以将数据直接转化成为 Prometheus 可以辨识的 metrics 格式，使 Prometheus 能够对其进行监控和采集，并通过 Prometheus Operator 注册对应的 Service Moninor 完成指标收集。
利用配置中心完成应用到 owner 的精准告警
随着公司业务蓬勃发展，人员激增，微服务暴增，研发人数和告警也剧烈增长。为了提升告警触达率和响应率，我们重新使用了 Apollo 配置中心的多语言 SDK ，通过 Go 自研了一套基于 Apollo 业务的应用提醒，整体流程如下：
通过 Grafana 收集到 ES 告警或其他场景下的告警，再通过 metrics 应用关联到 alert，告警时会转发到前文提到的 Go 语言编写的精准告警服务上。精准告警服务解析到对应应用，根据应用从 Apollo 配置中心中获取到 owner 姓名、手机号等信息，再基于此信息通过钉钉进行告警，极大提升了消息阅读率。
ARMS：无侵入支持 Trace
此外，我们还引入了阿里云的应用实时监控服务 ARMS，能够在没有任何代码改造的前提下，支持绝大部分中间件和框架，比如 Kafka、MySQL、Dubbo 等。云原生化后，仅需要在 deployment 里添加注解即可支持相关探针的加载，微服务的可维护性极为友好。同时，还提供了较为完整的 trace 视图，可以查看线上应用节点调用日志的整个 trace 链路，也提供了甘特图的查看方式和依赖拓扑图、上下游耗时图等数据。
可观测升级 Log Trace Metrics 理念升级
可观测在国内微服务领域已遍地开花。因此， F6 公司也升级了可观测思路。业界广泛推行的可观测性包含三大支柱，分别是日志事件、分布式链路追踪以及指标监控。任何时代都需要监控，但是它已经不再是核心需求。上图可以看出，监控仅包含告警和应用概览，而事实上可观测性还需包括排错剖析以及依赖分析。
最早的监控功能使用主体是运维人员，但运维人员大多只能处理系统服务告警。而上升到整个微服务领域，更多问题可能出现在应用之间，需要进行问题排障。比如服务出现了慢请求，有可能是因为代码问题，也可能因为锁或线程池不足，或连接数不够等，以上种种问题最终表现出来的特征是慢和服务无法响应。而如此多的可能性，需要通过可观测性才能定位到真正根因。然而，定位根因并非真实需求，真实需求更多的是利用可观测性分析出问题所处节点，然后通过替换对应组件、进行熔断或限流等措施，尽可能提升整体 SLA。
可观测性还可以很好的剖析问题，比如线上服务慢，可以观测其每个节点的耗时、每个请求中的耗时等。依赖分析也可以得到解决，比如服务依赖是否合理、服务依赖调用链路是否正常等。