阿里云 ACK 容器服务生产级可观测体系建设实践

阿里云 ACK 容器服务生产级可观测体系建设实践"/>

阿里云 ACK 容器服务生产级可观测体系建设实践

作者：冯诗淳（行疾）

ACK 可观测体系介绍

全景概要介绍

上图为 ACK 可观测体系全景图金字塔，从上至下可分为四层：

最上层是最接近用户业务的 Business Monitoring，包括用户业务的前端的流量、PV、前端性能、JS 响应速度等监控。通过容器服务的 IngressDashboard 来监测 Ingress 的请求量以及请求的状态，用户可以定制业务日志，通过容器服务的日志监控来实现业务的自定义监控。

第二层是 Application Performance Monitoring，包括用户的应用监控，由 ARMS APM 产品提供用户Java Profiling 和 Tracing等能力，也支持 OpenTracing和 OpenTelemetric 协议的多语言监控方案。

第三层是 Container Monitoring，包括容器的集群资源、容器 runtime 层、容器引擎以及容器集群的稳定性。使用阿里云 Prometheus 在一张 Global view 的大盘中展示不同集群层面的资源应用，包括性能、水位、云资源，也包括事件体系和日志体系，由事件中心和日志中心覆盖。

最下层是 Infrastructure Monitoring，包括不同的云资源、虚拟化层、操作系统内核层等。容器层和基础架构层都可以使用基于 eBPF 的无侵入式架构和 K8s 监控能力做网络和调用的 tracing。

可观测体系的每一层都和可观测的三大支柱 Logging、Tracing、Metrics 有不同程度的映射。

• 场景一：异常诊断场景的可观测能力实践

用户的异常诊断案例

早上 9 点多业务流量激增时出现了异常诊断，收到容器报警提示某 Pod Down 影响业务流量。用户收到报警后快速反应，对核心业务的 Pod 进行重启或扩容，查找问题根因。首先通过 IngressDashboard 从入口流量自上而下分析，发现对外业务的访问成功率下降以及出现 4XX 返回码的请求，说明这次异常影响了用户业务。再从资源以及负载层面分析，可以发现是由于朝九晚五的流量导致水位负载，在当天早上 9 点时存在与故障对齐的明显水位飙升，这也是故障所在。

系统第一时间报警核心业务的 Pod 定位，结合业务日志进行分析，加上 ARMS Java 的 APM 应用监控，定位到产生缓存 bug 是由于早上 9 点钟业务流量飙升引发了 bug 最后造成频繁的数据库读写，调用链也反映可能出现了数据库的慢查询,最后通过修复 bug 彻底闭环整个异常。

上述流程是非常典型的贯穿了整个 ACK 可观测不同能力异常诊断的排查过程，能够帮助我们更好地理解 ACK 可观测体系如何相互协调完成工作。

事件体系介绍