作者：冯诗淳（行疾），阿里云-云原生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可观测体系如何相互协调完成工作。
社区的K8s中包含了非常成熟的事件体系，提供了应用层的事件以及runtime层的事件。ACK可观测体系在社区的事件体系之上，从表层到底层都进行了覆盖和增强，做到了可观测事件体系的全覆盖。
• 应用异常：对于K8s的应用事件提供了用户灰度发布以及HPA等异常行为的事件监控。
• 管控操作事件：增加了集群的管控事件、用户对集群的异常操作以及重要变更，甚至包括成本和预算超标等。
• 集群核心组件异常：集群的稳定性很大一部分由集群核心组件的健康来保证。对于集群核心组件包括 API server、ETCD、Scheduler、CCM等都做了异常事件的增强，出现异常事件能够第一时间进行触达。此外，还包括用户侧核心组件addon事件，比如Terway、存储等。
• 集群容器引擎层异常：对集群容器引擎层做了增强，包括了Container Runtime、Kubelet、Cgroup等异常。
• 节点异常：包括OS/内核层异常，比如操作系统内核宕机、操作系统配置的异常等，也包括资源层异常比如网络资源异常、存储资源异常、其他云资源异常等，为容器服务的运维保障及功能更强的覆盖提供了支持。
ACK提供了开箱即用的事件中心能力，一键开启事件中心，即可享受复杂的事件体系带来的强大功能。它提供了预置的试验中心大盘，能够对重要的事件进行突出以及统计，也提供了强大、灵活易用的数据分析能力，为后面基于事件驱动的OPS体系提供了基础。ACK K8s集群更多的是对资源的生命周期进行管控，事件中心也提供了以事件为锚点的资源生命周期的管控能力。可以对生命周期中最重要的几个时间点进行性能的调试优化以及对异常Pod状态快速反应。
Logging在K8s中的第一个使用场景是重要流量，如Ingress等。ACK的日志中心默认提供了Ingress等重要场景的大盘，一键接入Ingress大盘后即可快速查看集群Ingress流量，此外还包括PV、UV、应用的异常状态以及统计，快速清晰，易于应用。
第二个日志使用场景是审计。集群中的资源经常被不同的账号访问使用，集群的安全也迫切需要重点关注。我们提供了审计日志大盘，可以快速分析集群资源的访问和使用轨迹，针对未被授权的访问可进行报警和预警，为集群提供更安全的环境。
我们提供了云原生无侵入式的日志获取方式，用户只需通过简单的CRD或在Pod上打annotation，即可将日志采集到日志中心，并享受日志中心多维、强大的分析能力。
Metrics体系是做稳定性保障和性能调优时最常用的体系，水位等关键指标都能通过大盘进行直观展示。产品侧预置了ARMS Prometheus大盘产品，购买了ACK K8s集群后，可以一键开启Prometheus大盘。此外，体系内预置了重要场景的Prometheus大盘，都是经过K8s上业务运维成熟经验的沉淀。Prometheus方案涉及到不同的服务，不仅包括容器服务侧最核心的K8s应用、网络、核心控制面指标，还包括比如AI场景、GPU指标以及存储CSI等外部存储场景，以及资源的优化或成本的优化指标。
使用统一的Prometheus数据链路方案，不仅能够支持容器场景的指标，也支持不同云产品的指标以及云产品上不同中间件的指标，可以将所有层级指标都在Prometheus数据链路中进行统一展示。
ACK集群控制面的核心组件API Server、ETCD、scheduler、CCM等也做了指标加强。Pro集群不只负责托管这部分核心组件、维护其SLA，同时也会将透明指标性能暴露给用户，让用户使用安心。
指标场景是稳定性保障的重要支持能力。ACK非常荣幸地为2022年的冬奥会服务，助力冬奥系统圆满平稳运行。
ACK集群中部署了冬奥会多个核心业务系统，包括冬奥的国际官网、比赛场馆、票务系统等，为多个核心系统保驾护航。核心系统多为Java系微服务架构，实际使用时有近千个Deployment实例。我们通过引入压测的方式进行容量评估，同时配合为冬奥定制的首屏运维大盘，实时进行应用和集群稳定性的保障，保证了冬奥访系统访问的顺滑。
很多用户的生产系统规模很大，到达千级别节点的集群规模后，用户在集群上会进行密集、大规模的集群资源访问，极易出现集群稳定性问题。
比如，用户在大规模集群中频繁密集地访问集群资源，首先会使API Server的请求数较高，API ServerMutating请求数也会处于高位。API Server负载过高会导致出现丢弃请求的情况，这也是API Server的降级特性，会影响用户业务的发布或用户的变更。
再比如，密集的集群资源访问也可能打满API Server带宽，API Server的请求延时RT会升至高位，一次API的访问可能需要几十秒，会严重影响用户的业务，API Server的只读请求数也会飙升。
我们提供了control plane核心组件的监控大盘，可以快速发现API Server的水位和请求响应时间的延时问题，然后根据API Server的访问日志快速定位是哪个应用的什么动作导致API Server的水位和资源请求高，最终找到具体应用进行止血，解决问题。
接下篇：
https://developer.aliyun.com/article/1222685?spm=a2c6h.13148508.setting.27.4f394f0em1x0Jq
