DeepFlow 云原生可观测性在小米落地现状以及挑战

大家好，我是来自小米的谭槊，今天非常高兴来参加 DeepFlow X 蓝鲸的线下 Meetup。我先做一下自我介绍，我是目前在小米监控系统组的高级工程师， 21 年加入小米。今天来这边分享的目的是简短地介绍一下目前 DeepFlow 在小米在业务中的切入点。因为我是一线研发，所以我大致讲一下在落地的过程中遇到了哪些挑战，以及遇到这些挑战后，我们和社区是如何努力去解决这些问题的。最后我讲一下在小米内部落地的一些业务。
我今天的分享分五部分展开：第一章会说一下小米可观测性的现状和规划，这一部分大致介绍一下我们的团队，以及我们是干什么的。我们团队在项目中会有一个主线作为年度目标，以及大致讲一下团队项目的全景图。第二章是为什么我们要引入 DeepFlow，在我们团队已经有一个很明确的主线的情况下，引入 DeepFlow 的动机和动力是什么？第三章 DeepFlow 在小米内部的部署架构介绍，我这边是从研发角度上而不是从产品角度上（来介绍部署架构），研发层面上我们是通过技术上部署（和架构调整），来介绍如何把 DeepFlow 从架构上和我们小米内部已有的一套可观测性架构进行融合。第四章讲我们已经把 DeepFlow 部署起来了，在推广它的时候遇到了一些挑战，过程不是一帆风顺的，我们针对遇到的挑战有技术上的一些解法，最后会给大家看一下，目前给我们的用户，也就是给业务方带来的可观测产品，目前产品不是很多，会有一个长期的如何跟 DeepFlow 展开深入合作的规划路线图。
我还补充一下，目前小米和 DeepFlow 合作的方式是以社区共建的形式合作的，我们这边也投入人力，然后在社区中走的都是社区的正规流程，提 FR、PR，然后我本人也提供过多个 FR 和多个 PR。

小米可观测性的现状与规划
第一章介绍我们团队，我们组为小米集团提供日志、指标、链路等可观测性的数据，这是可观测性数据的三个维度，通过平台将这些数据结合，帮助业务发现、定位和解决问题。先介绍一下我们的历史成果，以往我们主要面向的用户群体是 SRE，我们的第一阶段叫 SREOps，这个是我们提供的覆盖全集团的主机基础指标监控能力。这里面主要就是技术（编者按：基础设施）的指标，包括 CPU，内存，这块我们已经把它做完了，全集团已经铺开了，所有的机器都装了我们的采集器。这是第一阶段。
第二阶段主要是做可观测性，集中突破 DevOps，我们的目标用户从 SRE，也就是专业的运维同学，变成一线业务研发同学，这个阶段是当前的重点阶段，也是我们现在做的一块。目前这个平台已经差不多做完了，但是还没有向集团全部推出去，这是我们目前的目标。然后未来愿景，也是我们今年的具有挑战性的下一个目标，就是在全集团实现 DevOps 能力，覆盖任何应用，覆盖任何链路。
首先讲下 Falcon，如果是做可观测性的话，应该对 Falcon 这个产品比较了解。这是小米内部孵化的，也是我们团队目前在维护的一块，它重点面向的核心用户群体是我们的 SRE 。Falcon 提供的都是主机粒度的一些指标，比如 CPU、内存，磁盘、网络 IO 之类。目前部署范围是全部的主机，包括国内、欧洲、新加坡、印度、美国等多个机房，超过上万台主机。目前这个产品功能已经非常完善了，我们就不在上面继续进行深入迭代了。
除了我们自己做的 Falcon 之外，还有一些基于开源的知名项目（作为）我们的核心项目，我们做了一些日志链路和指标的一些单品，所谓单品即它们是各自为一个平台，没有一个统一的平台，相当于我们给业务方提供的散点指标数据，但是并没有提供一套完整的平台帮业务解决、发现问题或者定位问题。
日志相关的组件就是 Loki 和 ES，Loki 主要是面向于成本需求比较高的业务，ES 面向功能和性能要求比较高的业务。链路我就不多说了，就 OpenTelemetry 部分，我们跟他们架构是一样的，功能也是一样的。
指标相关的组件除了 Falcon 以外，Falcon 我们前面也说了它是主机维度监控，而小米最近也在做云原生的发展，所以也引入了 Prometheus 来弥补 Falcon 在云原生上的短板。
后面会重点介绍一下，这是我们今年在做的 DevOps 的能力，也就是 Hera 可观测性平台。Hera 可观测平台做了一件事情，在我们之前已经有日志、链路和指标这三个维度的基础之上，把这些指标进行融合，提出了一个应用为中心的维度，我们会有一个应用中心（作为可观测的入口）。
为什么要以应用为中心？因为现在主流的 DevOps 的展开都更加贴近业务方，应用对于业务方来说是更加亲近的，相当于我们把所有数据进行了应用维度的融合，右边是我们对接的平台，还是分两部分，一个是小米内部的容器平台，另一个就是小米内部的主机部署平台，因为小米内部在做云原生的时候迁移过程比较艰辛，导致它目前主机部署和云原生部署两套方案是并存的。我们以往在主机平台和容器化平台看指标监控的时候，或者看日志的时候，是要切换到不同平台看的，目前我们以应用为中心，相当于把这两个平台的细节对用户屏蔽了，用户现在就直接在我们应用中心去看监控数据，以应用为维度去观测我们服务的可靠性。
这边功能展开有应用状态、调用异常慢查询、服务大盘，最后还有告警。应用状态，（简单讲就是）应用有时候会存在一些大量的 （HTTP）5XX 或者慢请求，应用会进入异常状态，我们的业务方会收到报警。然后调用异常是基于 Request Scope （来区分）的，也就是 OTel 的那一套，（以及）火焰图（这一套逻辑）。业务可以根据 trace 单个的请求，比说单次的慢查询或者慢请求，假设超过两秒钟，我们会进行尾采样，然后把它放到调用异常里面去，以事件的形式提供给用户，然后用户可以通过 Request ID 把整个链路完整地串联起来。
慢查询主要是以 DB 为维度的，我们可以看到那种请求比较慢的 SQL，比如说运行超过十几秒甚至更多的SQL，这个慢查询扫描到的话会结合 DBA 的平台给出慢查询优化的建议。然后服务大盘是自动生成的，主要是一些七层协议，像 HTTP，像我们内部的 RPC 框架 R.E.D.指标，也就是黄金指标的监控。服务大盘虽然我们会自动给它生成一个，但是有的用户对 SLA 的定义是不一样的，所以这会是一个自定义大盘，我们的可观测性平台目前功能是这些，重点就以应用为中心，目前是在向外推广的阶段，也是我们现在的工作重心。
有一个比较简单的使用案例，我们的用户收到服务异常的告警，比如说 SLA 下降，他会打开并查看监控，然后可以看到下降的到底是哪几个接口，同时我们在日志和链路的追踪里面，可以关联到我们的异常事件，这下面有一个 Trace ID，我们点开后就展开看火焰图的 Span，就可以定位到那种耗时比较大的 Span。比如在这个场景下，我们发现一个 MySQL 的请求执行超过了 2 秒，就结合 DBA 系统得出故障分析，从我们的定位到发现问题到解决问题，最后到我们写出报告，整个时间周期是 20 分钟。
而且这个系统上手成本也很低，因为它比较简单，我们的核心目标就是帮助业务方可以快速地、简单地定位到问题并且快速解决，保证业务方的服务稳定性好。

然后说一下我们团队目前的规划，前面总结一下，首先是定义了 L1、L2、L3、L4 这四个工作阶段，我们这个跟行业界内的定义有一点小小区别，但是目前从上到下的规划是越来越自动化、接入成本越来越低，现在我们重点就是在 L3 这个 DevOps 上面。

]]>