写点什么

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

演讲人:黄杰

  • 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:104661

评论

发布
暂无评论
发现更多内容

第二周作业

Aldaron

【Week02】框架设计

Aldaron

课程总结

GAC·DU

红警1游戏开源,代码非常规范。网友:秀色可餐

程序员生活志

开源 红警1

《实现领域驱动设计》拆书稿 DDD入门 & 领域、子域和限界上下文

三界

架构 领域驱动设计 DDD

设计模式的主要原则

看清远处模糊的事,不如做好身边清楚的事

Neco.W

创业心态 未知

【大厂面试06期】谈一谈你对Redis持久化的理解?

NotFound9

数据库 redis 后端

免费下载 | 阿里云实时计算整体解决方案白皮书重磅发布!

Apache Flink

大数据 flink 流计算 实时计算

数仓系列 | 深入解读 Flink 资源管理机制

Apache Flink

大数据 flink 流计算 实时计算

小师妹学JVM之:JDK14中JVM的性能优化

程序那些事

JVM 小师妹 JIT JDK14 签约计划第二季

第二周 作业

尔东雨田

当你启动Redis的时候,Redis做了什么

老胡爱分享

redis 源码分析 面试

编程这件事

dapaul

使用WebMaker快速预览Ionic页面效果

davidce

Ionic WebMaker 混合应用开发

第二周作业

晨光

如何构建低延时的直播体验,让互动更实时?

阿里云Edge Plus

CDN 短视频 直播 视频

20年行业变革与技术演进,当下CDN如何为政企数字化转型加速?

阿里云Edge Plus

CDN 边缘计算 移动视频

架构师训练营第二章 总结

尔东雨田

面向开发者的 WSL2 安装指南

simpleapples

Python Windows 10 wsl Go 语言

第二周总结

晨光

从字符串到常量池,一文看懂String类设计

程序员DMZ

JVM 常量池 intern

Apache Flink 误用之痛

Apache Flink

大数据 flink 流计算 实时计算 数据处理

28岁程序员期权过亿,彪悍从字节退休,网友:酸了酸了!

程序员生活志

程序员 字节跳动 开发 退休

依赖倒置架构

GAC·DU

Flink作业问题分析和调优实践

Apache Flink

大数据 flink 流计算 实时计算

极客大学架构师训练营 框架设计、设计原则、设计模式 第四课 听课总结

John(易筋)

极客时间 极客大学 极客大学架构师训练营 设计原则 框架设计

第二周总结

qqq

极客大学架构师训练营

依赖倒置原则

Jeannette

软件开发简史

Jeannette

架构师训练营 0 期第二周

Blink

腾讯云原生可观测性之路:探索、实践与踩坑_可观测_InfoQ精选文章