全栈算力,加速行业AI落地 了解详情
写点什么

腾讯云原生可观测性之路:探索、实践与踩坑

演讲人:黄杰

  • 2023-08-22
    北京
  • 本文字数:5071 字

    阅读完需:约 17 分钟

腾讯云原生可观测性之路:探索、实践与踩坑

我是来自腾讯云的黄杰,目前主要负责腾讯云上云原生可观测性的产品和内部平台的落地。我从业务转做监控至今已经有十几年,我还是开源项目的实践爱好者。今天我将为大家分享腾讯在云原生可观测性领域中的探索、实践,以及一些踩坑经历。 

 

什么是云原生可观测性?


可观测性,也就是我们曾说的监控,其中包含 Log、tracing、Metrics 等等。我们要怎么将这些异构的数据进行关联?这些数据之间的关系是什么?我们又要如何应用好这些数据?

监控 vs. 可观测


传统意义上的监控其实是与当时的业务场景有一定关系的,监控所反映的是系统是否能正常工作的情况,关注点在于单个系统(如数据库是否可工作、服务是否可工作、主机是否在线等等),其中的 Log、Metric、Trace 概念相对独立。由此诞生了 OpenMetrics、OpenTracing 等组织,普罗米修斯、Jaeger 等开源产品。



另一方面,可观测性在回答系统是否正常工作的同时,也能给出无法工作的原因,如常见的系统故障原因和补救措施。可观测性解决的是整体的问题,这是与监控所解决的单点问题有所不同。此外,除了 Tracing、Log、Metric 等方面外,可观测性也包含 Event、Profiler 等其他数据源,且数据之间不相互独立。而只有在清楚了解这些数据间的关联,我们才能明白故障背后的原因和影响的业务。幸运的是,目前这一领域也出现了许多优秀的组织和较为活跃的项目,比如大家所熟知的 CNCF 中 OpenTelemetry 项目,以及做数据可视化出名 Grafana。Grafana 目前也在通过 Loki、tempo 布局可观测性,在收购了 K6 等公司负责压测的同时,也有涉足 Profiling、CI/CD 等方面。此外,还有国外热度较高的商业化公司 DataDog,以及国内诸多类型的公司。

 

服务架构在变化


监控的单点化是有原因的。传统行业的应用可能只有一台服务器和其上运行的数据库、业务代码,对监控的需求并不大,甚至只有日志输出即可。而现在的公司业务甚至可能比右图中所展示的还要错综复杂,在这种情况下,仅使用 Log、Metrics、Trace 并不能解决实际生产中的问题,服务治理的难度在增加,环境愈发复杂,对故障修复效率的要求也越来越高,短短几分钟的故障都可能造成金钱损失,服务不可用也会带来用户的流失。此外,随着公司业务扩张,角色也会随之增加,各个服务角色之间还会出现责任的推卸。



但如果我们将这个复杂的网状结构进行细分,那么其中的关系便能一目了然。服务可以运行在传统 VM 环境或 K8s 环境中,会运用一些 PaaS 类产品,如数据库、cache、消息队列等等。服务间也会存在调用关系,并因此产生 Log、Metrics、log。那么我们要如何将这些相连的关系包含在数据之中?又要如何将这些数据采集呢?



可观测性几大支柱

Metrics


常见的 Metrics 指标包含:


  • 业务指标:订单量,用户数等

  • 应用服务指标:延时、成功率或失败率、失败异常,常用的有谷歌的黄金指标

  • 中间件指标:缓存命中率、消息积压等

  • 系统基础设施指标:CPU 使用率、网络带宽等

 

人们通常都会在指标中添加告警。我们内部曾经为及时发现系统问题,将所有相关指标都添加了告警,但也由此引发了告警风暴,系统是否故障往往可以直接看手机消息的震动频率直观看出,这样一来,告警的意义也就不复存在了。


业务相关的核心指标则更为重要。比如,在接收到 CPU 使用率过高的告警后,我们可能会从 Dashboard 中找到眉目,但单独依靠指标我们只能得知故障的现象,对于故障的原因还是无法做出回答。


那么,我们要如何透过指标曲线,针对性地找出有问题的指标、Log,或 tracing?怎样才能发现上下文中故障的环节、异常的日志、Exception,或出现延迟的链路呢?这里就先容我先卖个关子。

 

Tracing


全链路 Tracing 可以通过下面这个简单的用户下单行为模拟进行分析。图中包含了网关、用户服务、订单服务。网关在接受到请求后,对用户服务进行调用,访问数据库获取到用户信息;订单服务创建订单后,将订单状态存入缓存用于后续状态的更新。



在这个过程中,我们把完成这一次操作的请求用一个叫 Trace ID 的标识出来,用于区分不同机器上、多云多机房、云上云下、多 Region 数据库 等不同场景,这其中也隐含了服务的各种信息,如服务运行的机器或 K8s 的 pod 及对应 VM、服务调用、客户端对数据库的访问、缓存访问、服务运行机、服务间关系、服务所用的 PaaS 产品等等。我们还能获取每个服务处下相应请求的时间信息(开始时间、结束时间、延时)、状态、Event,以及具体的上下文日志。

 

Logging


以下图的常规日志为例,我们能看到其中的时间戳、消息内容、log level、Trace ID,以及其他通用属性。OpenTelemetry 可在日志中提供标签功能,标明产生日志的用户、订单、服务及其所属组织、机器物理位置等状态信息。从中自然也隐含了日志归属服务、机器、其间关联等信息,从而将非结构化数据结构化。



在服务繁多的场景下,我们需要保证日志采集的中央化以及日志打印的可读性,方便他人在故障发生时快速检索相关日志,从而定位故障问题,但是做到这些是不是已经足够?

源源不断的日志采集不仅会带来高昂的成本,在问题出现后如果没有 Trace ID 或用户 ID,即使是有上下文存在,也很难对问题进行排查。



通过 Trace ID 对上下文构建,可以让我们轻松获取到发生故障机器上的请求和相关日志。进一步讲,我们也可以通过通用属性订单 ID 或交易 ID,不仅将单次请求的 Trace 相关联,还能将服务链路顺畅连接。而用户 ID 则因为用户行为的长周期性,不适用于此处的短周期事务性场景。用户维度的跟踪可以根据前端的可观测性进行串联,对用户在前端的行为进行管理,从而模仿用户的上下文。

 

目前,我们在告警时查找日志的思路是尽可能通过 Trace 提取计算 Metrics。业务指标场景中,可通过接口或 RPC 请求直接反应订单创建行为,免去用户自行标记指标的操作;应用服务指标中的许多都可以天然通过 Trace 进行提炼;中间件指标方面,则可以从客户端一侧实施可观测性,比如,数据库访问的库名、TP、快慢 SQL、成功与否等等,至于数据库响应,在已知 DP 和关联的情况下,client 和 server 间也可以很好地进行关联;系统基础设施指标基本属于传统监控范畴,通过主机 IP、host、标签,关联服务所在机器的 CPU 内存、网络带宽等等。

 

Health Check


与拨测类似,Health Check 会探测 IP 和端口是否可用,并将服务内部依赖及故障原因简单地告知可观测平台。



至于 Health Check 的运用,我们内部曾基于 Health Check 做过一个对 DB 的监控,通过 DB 的慢 SQL/TPS 及其他数据库行为判定数据库是否正常,Health Check 也可用于服务点火,及时地 check 发布后的服务是否成功,如果不成功则立刻回滚。此外,K8s 也提供对服务部署后的存活检测,云服务商的状态页也有状态异样的检测。

Event


除此之外,我认为变更也非常有用。据业务数据分析线上故障至少有五成左右都是直接来源于变更。下图的例子中,我们内部在每次变更都会把 commit 信息和环境信息包含在其中,让后台能立刻得知那些服务有变更,一旦出现故障便能立刻找到有问题的变更。



相互关联


总体来说,这些单体本身的实施并不困难,但这些数据采集如果没有运用好,也将会变为一种负担。我们的第一代系统就是具备日志打印功能的基础设施,自我感觉很好但对业务而言毫无价值,出现故障后他人很难通过搜索日志关键字找到问题原因。



为此,我们将问题根据异常类型或 Error 级别进行简单的分类统计,让 DBA 和业务关注自身类别的告警,直观地通过 Dashboard 中指标情况,找到下方 Trace 链路和环节的问题点,继而根据 Trace ID 对日志关联,查找具体日志内容。整体排查过程基本不涉及任何关键字查找,仅仅通过图示和鼠标操作上游便可轻松定位问题模块。



在 Tracing、Metrics、Log 这三大支柱下,目前开源社区如 OpenTelemetry 会对日志打印的标准进行定义,限定特定情况下日志打印的标签、日志内容,以及如何利用这些数据提取 Metrics 等等,将原本独立三大资源贯通,从而实现后续的 root cause 根因分析。

 

如何建设可观测性


搭建监控或可观测平台离不开丰富的数据采集、数据清洗和计算、数据存储及对用户展现这三个方面。



下图中整理了采集、存储、计算整体流程的简单示意图。目前许多基础设施软件都已在内部集成各式 SDK,导致传统的闭源很难继续存活,因此我们选择拥抱开源,使用 Jaeger Agent、SkyWalking、普罗米修斯、OpenTelemetry、OTEL Agent、Log Agent,以及一些内部传统 Agent 等进行数据采集,并将采集到的数据汇总到扩展性较好的 OpenTelemetry Collector 中,通过鉴权路由把数据分发到 Kafka,再兵分两路;一路用于日志分析、数据提取,将指标保存于 Clickhouse 或 CTSDB 后闭环到数据清洗和计算,从而完成其他告警和监测工作。另外一路则相对简单,将数据按照是否存在问题进行分离存储(ES、COS、或 Clickhouse),统一挂载查询引擎,允许用户使用类似 SQL 查询的形式对数据进行查找 Log、指标、Trace 等等。



如何采集


我们将开源社区内的 Receive 根据业务需求进行了简单的改造和扩展,将所有 Receiver 中的异构数据转换为统一的内部 OpenTelemetry 协议进行存储。



此外,云上服务中的鉴权、采样、限流/限频方面,以及我认为较重要的路由,即提前根据租户、产品类型,以及监控场景分类数据,将分类后同类型数据进行简单合并,从而方便后续操作并减轻网络传输压力。为保证监控数据的时效性,延时数据不会对后续造成影响,我们采用了本地+内存的缓存机制,一份存储数据可被多人消费,类似于一个本地的简单 Kafka;将最新的数据保存至内存,历史数据保存至本地磁盘,日志消费等则由 Kafka 负责。整体过程直接套用开源方案,我们只在其中进行了标准化的工作,确保数据的统一性。

 

如何计算


我们是近些年才将计算迁移至 Flink 的,其中最具特色的便是我们的视图级联运算和延时数据运算,以及其他常规的平滑重启、数据补算、动态规则加载、状态自监控(告知上一级数据路由的问题)。



为实现监控大数据量下的高吞吐,我们需要在上游做好数据分类的前提下,对监控数据进行裁剪,在 Flink 的前置 Route 中进行数据的合并压缩;废弃了过重的 Checkpoint,通过异常时间点的补算保障数据的完整性;将业务中的大任务进行拆解,便于系统整体维护;引入了迭代流,将计算结果循环利用。



我们通过抽象十数种通用算子(如 count、gauge、采样等),将 SQL 翻译为 Flink 算子进行 pipeline 计算,从而实现系统逻辑的通用性。


在稳定性方面,我们主要关注的是积压数据的实时性,通过新任务补算,确保 delay 的数据不会影响后续计算流;无缝重启则是通过下发停止计算的时间点,让新任务在该时间点处理后续数据,为避免中间数据的重复性,我们在设计算子时也考虑到这一点,故而所有数据都是可以再计算的。

 

如何存储


存储主要分为三部分,Log、Trace、Metrics。通过抽象数据 ID 化,以类似数据库组件的形式,对这些数据进行打标,对于 CVM/CDB 这种云上产品而言,数据 ID 也可方便的针对不同用户的需求进行补打标和补算。



此外,我们也统一了数据查写的方式,这里就涉及到了异构存储的上层查询、ES 动态分片、监控数据 TTL 及时间的计算。我们还针对大范围数据查询的自动 Rollup,在查询时按时间分片聚合,将告警等静态数据缓存等等。沿用流处理的思路,我们限制了分片上限,并基于数据的周期性进行动态分片调整。

 

简而言之,我们在采集和存储阶段确保输入输出数据的标准化,计算阶段通用化,让研发和产品都可简单通过 POC 写 SQL 等等。

 

一体化可观测


图中所示是腾讯云目前的可观测平台,我们可以看到其中包含了拨测、用户端、web、小程序等各种语言,应用了各类协议和云产品,以及后续对数据的运用、处理数据的存储,以及产品的运用形式。



以 RUM 为例,我们可以直观地看到前端的每一次请求情况、行业数据、可观测标准、数据采集、主要请求量、环比问题等等,允许我们通过前端的监控和日志,快速对接后端的服务异常。




因为我们所有的数据均是由 Trace 产生,因此正如图中所示,我们能直观地看到服务的吞吐量、延时等情况,找到出现异常的链路环节及 Trace 日志,进而在告警出现后快速得出异常根因。



在 DBA 发现数据库出现问题后,我们也可以发现受到影响的服务,如数据库中有哪些慢 SQL 对服务造成影响、服务访问的 DB 出现异常等等。

 


总结展望


正是有了目前社区中数据的标准化,才能为我们的 AIOps 奠定基础,从而允许云厂商或可观测平台能将精力聚焦于产品能力和成本之上。

 

 相关阅读:


云原生 + 国产化,腾讯云数据库不做选择题

腾讯云数据库技术实践精选集 2022 年版

腾讯云 ES:一站式配置,TKE 容器日志采集与分析就是这么简单

腾讯云数据湖解决方案及 DLC 内核技术介绍

2023-08-22 16:103584

评论

发布
暂无评论
发现更多内容
腾讯云原生可观测性之路:探索、实践与踩坑_可观测_InfoQ精选文章