腾讯罗嘉黎：基于APM的腾讯可观测平台技术与实践

嘉宾 | 罗嘉黎    整理 | 哪 吒

出品 | CSDN云原生

2022年4月26日，在CSDN云原生系列在线峰会第2期“可观测性与APM峰会”上，腾讯可观测平台技术负责人罗嘉黎分享了基于APM的腾讯可观测平台技术与实践，详细介绍了如何在大规模、海量业务场景下实现可观测性和APM。

戳👇观看罗嘉黎分享视频

腾讯罗嘉黎：基于APM的腾讯可观测平台技术与实践

腾讯可观测性发展史

可观测性的发展趋势是从单体应用逐渐向分布式服务、微服务及服务网格发展。

在单体应用时，最传统、最简单的方法是通过日志排查。日志起初对于单体应用是够用的，但随着腾讯的业务发展，只用单机查询十分不便，所以我们有了远程日志。随着后台 Server 逐渐增多，远程日志的数据量也变得非常庞大。

日志虽然是最常用的，但由于它的非结构化特性，无法对其做指标或是告警检测。逐渐的，我们就从日志这种完全无序的无结构化的数据中抽象得到了指标跟维度两种概念。

指标类似于错误数、CPU，是动态变化的。维度类似于某台虚拟机或是某个MySQL 实例，是一个维度组合，并不变化。

因为指标是一种结构化的数据，能够更有效地去表示信息，也能够给予开发者一些规范，从而可以上报更有效的数据。并且它具有聚合的特性，在提高效率的同时也可以大幅减少成本。

容器时代、微服务时代到来后，K8s 架构带来了很多很好的功能，如负载均衡、弹性可伸缩的能力。

K8s 抽象出了 Node 和 Pod 的概念。以前的服务都是部署在虚拟机或者物理机上，而现在服务则都是部署在一个个 Pod 之上。Pod 变成了一个逻辑性的概念，而不是简单地绑定到某一台机器。假若服务 CPU、内存消耗很大，它可以将其调度到资源更大的节点机器上去，提供了一种非常灵活的调度能力。

但也正是由于这样的调度能力，给可观测、监控带来了较大的挑战。如今的业务都在微服务化，一个请求会经过几十个甚至上百个服务。若还是通过这种单点方式，并没有办法快速定位到问题。

所以Tracing便应运而生，它能够将不同的节点、服务串起来。这样就能够画出拓扑图，从而快速定位问题。

云原生应用的特点

1. 效率要求越来越高：随着DevOps模式的普及，规划、开发、测试、交付的效率越来越⾼。

2.系统更加复杂：架构从开始的⼀体化到分层模式，再到现在的微服务架构模式。

3.环境动态性增强：容器化的部署模式动态性增强，每个实例的⽣命周期变得更短。

4.上下游依赖更多：云原⽣应⽤依赖云上的各类产品，上下游变得更多。

Metric，Logging，Tracing

单体应用时代，通过指标、日志去解决问题，把非结构化的日志抽象成指标，以此产生告警。

但其实日志与指标之间是串不起来的。当我们收到一个指标的告警，比如一台机器的 CPU 告警或是错误率告警，此时开发者首先会去取得类似于apid、uid 标识用户的信息，再去获取接口名称、应用名称等信息，最后再到日志中进行搜索。

这个时候虽然有日志、有指标，但本质上它们是完全独立、串不起来的。

在收到一个指标的告知后，我们可以去点开任何一条链路以寻找有问题的链路。Trace ID能够注入到这样的日志里面去。这个时候我们就能够把Trace ID 与Metrics 及 Log关联起来，此时便能够快速、高效地定位、处理问题。

腾讯的可观测实践

基础资源监控与告警

基础资源的监控与告警，例如CPU使用率、内存使用率这样的一些监控告警，都是可观测平台技术中需要关注的关键点。

前端监控

从前端的视角，不管是在Web端、小程序端还是安卓端，监控最重要的指标是首屏渲染时间。C端有一个理论：响应时间增多一秒，用户的停留的机率会降低50%以上，所以这个指标是非常重要的。

后台监控

后台接口的可用性分析，即指标、日志与 Tracing 的连通。将这个过程进行抽象，指标、Trace到日志实际上是一个宏观到微观的过程，从指标的告警到链路的情况，最后再去查日志。相较于传统一出现问题便去查看日志的处理方式，在整体上通过“指标—链路—日志”的方式能够提高定位问题的效率。

可观测性系统设计与实现

整体架构

整体架构分为三层，第一层是输入层，第二层是中台的数据处理层，第三层是应用层。输入层的数据分为两部分，一部分是 Trace 及日志的数据，另一部分是指标的数据。指标的数据会通过我们的流处理进行一个聚合，Trace 和日志的数据可以根据情况来看是否需要对其进行处理，例如计算上下游的关系等。

应用层通过一种统一查询 SQL 的DSL 方式，能够提供开源的官方插件。

接入层则是充分考虑到多协议的扩展性。

经验总结及展望

从整体的可观测性的实践过程中，我们可以总结出以下经验：

• 单独集群做⾃监控——异地容灾

• ⽹络调⽤RPC/http调⽤指标+合理告警——⽆侵⼊探针（APM/RUM）

• MySQL、Redis、ES等存储相关调⽤告警——⽆侵⼊探针（APM）

• 重点关注数据⼀致性相关问题的告警——业务指标埋点（Prometheus）

• ⽇志类数据通过中间件打印清楚上下⽂信息（比如appid、ip、返回码等）

• 重视从业务场景的拨测——持续集成测试（CAT）

• 确保告警的有效性和数量限制

• 通过压测去观测以上数据的情况

归根结底，不管是 APM 还是 SkyWalking 等这些开源的监控系统，都需要业务侧或客户或一线的开发者们参与进来。按照以上几点操作并完善，这将会让大家业务系统的可用性有很大的提升。