如何发现 Kubernetes 中服务和工作负载的异常

简介： 本次分享为Kubernetes 监控公开课的第二节内容：如何发现 Kubernetes 中服务和工作负载的异常。 分享由三个部分组成： 一、Kubernetes 异常定位存在痛点； 二、针对这些痛点，Kubernetes 监控如何更快、更准、更全的发现异常； 三、网络性能监控、中间件监控等典型案例解析。

大家好，我是来自阿里云的李煌东，今天由我为大家分享 Kubernetes 监控公开课的第二节内容：如何发现 Kubernetes 中服务和工作负载的异常。

本次分享由三个部分组成：

一、Kubernetes 异常定位存在痛点；

二、针对这些痛点，Kubernetes 监控如何更快、更准、更全的发现异常；

三、网络性能监控、中间件监控等典型案例解析。

Kubernetes 异常定位存在痛点

当下的互联网架构中，越来越多的公司采用微服务 + Kubernetes 这样的架构，这样的架构有如下特点：

1. 首先应用层基于微服务，微服务由解耦开的几个服务相互调用构成，服务一般职责分明、边界明确，造成的结果是一个简单的产品也有几十、甚至上百个微服务，相互之间的依赖、调用是非常复杂的，这给定位问题带来比较大的成本。同时，每个服务的 owner 可能来自不同团队，不同的开发，可能使用不同的语言，对我们监控的影响是对每一种语言都需要进行监控工具的接入，投资回报率低。还有一个特点是多协议，几乎每种中间件（Redis、MySQL、Kafka）都有他们独特的协议，怎么要做到快速对这些协议进行观测，是不小的挑战。
2. 虽然 Kubernetes 和容器对上层应用屏蔽了底层的复杂度，但是带来的两个结果是：基础设施层越来越高；另一个是上层应用和基础设施之间信息变得越来越复杂了。举个例子，用户反馈网站访问很慢，管理员查看访问日志、服务状态、资源水位发现都没问题，这时候不知道问题出现在哪里，虽然怀疑基础设施有问题，但无法定界的情况下只能一个一个排查效率低，问题的根源就是上层应用和基础设施之间缺少上下问题关联，无法做到端到端串联。
3. 最后一个痛点是数据散、工具多、信息没打通。举个例子，假设我们收到一个告警，用 grafana 去查看指标，指标只能描述的比较粗略，我们得去看下日志，这时候我们要去 SLS 日志服务看下有没有对应的日志，日志也没问题，这时候我们需要登录到机器上去看，然而登录到容器里面可能又因为重启导致日志没有了。查了一波之后，可能我们会觉得可能问题不是出现在这个应用，于是我们又去看链路追踪是不是下游有问题。总而言之，工具用了一大堆，浏览器开了十几个窗口，效率低、体验差。

这三个痛点分别归纳为成本、效率、体验三个方面。针对这些痛点，接下来我们一起看下 Kubernetes 监控的数据体系，看下怎么来更好的解决成本、效率、体验三大问题。

Kubernetes 监控如何发现异常

下图金子塔自顶向下表示信息的密度或者详细程度，越往下面信息越详细。我们从底部开始讲，Trace 是我们通过eBPF技术以无入侵、多协议、多语言的方式采集应用层协议数据，如 HTTP、MySQL、Redis，协议数据会进一步解析成容易理解的请求详情、响应详情、各个阶段的耗时信息。

再上一层是指标，指标主要由黄金指标、网络、Kubernetes 体系中的指标。其中黄金指标和网络指标是基于 eBPF 采集的，所以同样他们是没有入侵的，支持各种协议的，有了黄金指标，我们就能知道服务整体上是否有异常、是否有慢、是否影响用户；网络指标主要是对socket的支持，如丢包率、重传率、RTT 等，主要用来监控网络是否正常的指标。Kubernetes 体系中的指标是指原来 Kubernetes 监控体系中的 cAdvisor/MetricServer/Node Exporter/NPD 这些指标。

再上一层是事件，事件直接明确地告诉我们发生了什么，可能我们遇到最多的是