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

本文介绍了阿里云ACK的可观测体系,包括全景概要、事件、日志、Metric和Tracing体系,展示了如何利用这些能力进行异常诊断、AIOps和FinOps体系的建设。文中分享了异常诊断案例,事件和日志的监控增强,以及Prometheus和Tracing的使用,还提到了成本治理方案在实际客户案例中的成功应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

作者:冯诗淳(行疾)

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 可观测体系如何相互协调完成工作。

事件体系介绍

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值