用ClickHouse搭智能运维可观测性平台,简直不要太香……

高鹏 2023-05-19 09:51:37

本文根据高鹏老师在2023 中国数据智能管理峰会-上海站〗现场演讲内容整理而成。(关注【dbaplus社群】公众号,回复“230331”可获取完整PPT)

 

 

图片

 

讲师介绍

高鹏,新浪部门主管。在高可用架构设计、业务逻辑设计和优化方面,有较为丰富的经验。目前负责新浪智能数据分析平台建设,致力于运维大数据价值挖掘,提升运维服务质量和产品用户体验度。ClickHouse中国社区发起人之一,国内最早大规模使用ClickHouse的用户之一,对ClickHouse的架构、使用、优化,有较好的理解和实践经验。

 

分享概要

一、基础设施研发

二、监控产品演进

三、AIOps应用

四、数据科学应用

五、未来展望

 

<section data-id="us-3745001" data-tools="135编辑器" style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; color: rgba(0, 0, 0, 0.9); font-family: system-ui, -apple-system, BlinkMacSystemFont, " helvetica="" neue",="" "pingfang="" sc",="" "hiragino="" sans="" gb",="" "microsoft="" yahei="" ui",="" yahei",="" arial,="" sans-serif;="" font-size:="" 17px;="" letter-spacing:="" 0.544px;="" text-align:="" justify;="" box-sizing:="" border-box="" !important;="" overflow-wrap:="" break-word="" !important;"="">

一、基础设施研发

 

我们属于新浪微博的基础研发团队,如图所示,我们需要负责三层架构:运维基础设施、服务端和客户端业务运维。

 

  • 运维基础设施层(运维平台底座):内部混合云平台、CICD系统、K8s私有云容器平台、4层/7层负载均衡等;

 

  • 服务端:SLA、服务拓扑、成本优化、服务日志;

 

  • 客户端:APP、PC、H5、小程序等的运维保障。

 

图片

 

依据不同业务场景,我们建设了垂类监控、智能报警、链路追踪,同时也基于一些经典算法,实现了智能监控告警。

 

在技术选型上,主要做了哪些考虑呢?

 

图片

 

 

1、数据分析

 

可观测本质上是以大数据为底座的,所以数据分析非常重要。所以我们引入了数据分析领域比较专精的Grafana、R语言、plotly、Shiny等,来搭建数据可视化场景和框架;

 

 

2、链路追踪

 

存量业务很难实现标准化。在两三年前,我们就在内部推广了一个全链路监控协议,虽然不如OpenTelemetry,但基本上实现后端资源监控的目标,现在我们新的业务则逐渐以OpenTelemetry作为标准;

 

 

3、大数据引擎

 

三四年前还没有可观测性的概念,当时还叫监控平台,当时还面临着比较大的数据分析问题,用传统的Hadoop框架,抽取各种数据层次,再把数据从Hive提取到MySQL,这样一通操作,只能实现T+1的分析报表功能。

 

之后流行的ES方案,也有很多问题,如复杂查询性能差、资源占用高等;Spark、Flink等流式计算,也存在上手难度大等问题。

 

监控应该是一个7*24小时的服务,不是离线服务,所以亟需一个非常高效的工具来解决慢速查询的问题。

 

图片

 

对比了业界比较常用的一些方案后,我们最终选择了ClickHouse作为查询引擎。

 

图片

 

左图是新浪微博线上的一些数据表,基本上都是百亿、千亿级的规模,由于ClickHouse速度快、性能好、资源占用率低的特点,一些复杂SQL都可以在极短时间内返回我们想的结果。目前为止,ClickHouse每天承载的数据量大概在3,000亿条,每秒的数据量大概在500万左右。

 

在一次热点事件中,峰值达到近千万QPS,我们仅用了30台服务器,就承载了这么大数据量的数据分析工作。所以,不管是运维,还是传统数据分析,ClickHouse都是一个利器。

 

图片

 

基于这些考虑,我们把ClickHouse作为整个数据分析平台的基础设施。

 

原来的架构中,数据流是非常复杂的,导致整个数据生命周期难以维护,有了ClickHouse作为超高性能的数据底座以后,我们的数据就变得非常简单。

 

上层对接各种业务层数据,这些数据通过Kafka数据总线,最终通过ETL流程写到ClickHouse数据仓库里,运维和数据分析师则可以直接在ClickHouse上面做查询。而对于需要长期保留的数据,我们开发了一些工具把这些数据打捞到MySQL等持久化存储。

 

二、监控产品演进

 

图片

 

有了数据平台后,要由上往下去建设产品层面的监控,做好产品侧的“最后一公里”。

 

图片

 

上图是一个典型的移动端访问的链路路径,大部分场景下,大家使用的是移动互联网产品,90%的用户喜欢用手机进入微博,而移动网络本身存在很多不确定性,如网络问题、3G/4G/5G/Wifi切换的问题、IPv6的问题、DNS问题等。

 

比如早年接到用户投诉,反映安卓客户端提示APP要升级,点进去之后变成了其它APP,端上请求下载的是新浪apk,但是却变成了别人的apk,发生了DNS劫持问题。但HTTPS全量铺开后,这类问题基本上也不存在了。

 

再举一个跟DNS相关的例子,之前接到一个用户投诉,客户端访问非常慢,我们打开了他端上的日志,发现用户本人在北京,但访问到的服务到了广州,就导致了客户端访问慢的问题。大家都知道现在大部分本地化调度,基本上都是基于DNS来做的,DNS根据你的Local DNS IP来源, 返回给你一个离你最近的一个IP。由于运营商的Local DNS大部分都不是eDNS,所以无法通过用户真实IP判断。后来看了用户的APM日志和DNS,发现其可能通过某些“优化软件”,把手机系统DNS的IP篡改了。

 

再如疫情期间推出了疫情地图这样的产品,这些页面基本上都是一个接口去后端取数据,再交给前端JS渲染,逻辑非常简单。有一天早上某同事发现疫情地图白页挂掉了,但查看后端数据一切正常。后来发现,后端返回的数据里,有一个int型的数据,不知道什么原因,成了字符串,导致端上的JS在渲染的异常。

 

上述种种问题都表明,如果想做好用户产品体验的话,首先要保证的其实就是产品距离用户的最后一公里,也就是产品侧APM监控。

 

图片

 

有了产品侧的APM监控后,就能够很明确知道服务在用户层面到底是怎样的体验:访问CDN的质量怎么样?CDN作为IT成本较高的服务,不同厂商的质量到底怎么样?钱是不是花得值?

 

我们现在都是用混合CDN,有了APM数据后,就可以判断各家厂商的覆盖程度有没有达到承诺,这是产品保障非常重要的指标。

 

图片

 

除了基线层面的数据,还有Trace监控产品,如果有用户投诉,我们则能够复现其访问路径,检查网络和访问质量,以此解决问题。

 

那么有了APM是不是就够了呢?答案是否定的,当用户问题发生并进入公司内部服务后,接下来要做的就要搞清楚为什么访问慢?慢在哪里?是DB慢,还是前端慢?

 

所以有了产品侧监控后,紧接着就是做后端全链路监控。

 

图片

 

上图是内部产品的调用拓扑图,本身已经非常复杂。前面提到我们内部使用的是自定义协议来做打点的拓扑架构绘制,虽然并没有用到OpenTelemetry,但它所串联的ID和APM其实都是一一对应的,本质上和OpenTelemetry没有太大的区别。

 

有了上面这些点线关系后,我们也能知道它在后端进入内部服务后,具体是怎样的访问路径,可以很清楚看见某个服务从不同机房到后端,以及不用接口、不同pod IP到对端的服务可用性。同时,我们定义了很多SLI,如平均响应时间、P90、P95、P99响应时间、错误率等,结合ClickHouse的函数,可以实现快速的统计需求,最后形成了内部服务的metric和trace可观测。

 

图片

 

我们现在也在积极拥抱OpenTelemetry,上右图是一个使用Jaeger展示存在ClickHouse里的一个调用瀑布图。

 

三、AIOps应用

 

前面提到,有了端上、链路等日志后,数据量会非常庞大,远不是人肉去配置报警规则就能搞定的。

 

所有的可观测指标,不可能让工程师盯着大屏发现异常,最终一定都要落地到监控报警,以下是传统监控面临的一些困境:

 

图片

 

  • 业务多样性:同一场景不同业务,差异巨大,导致添加报警繁琐无比;

 

比如同一个DB,有两个业务或接口,背后的SQL、业务逻辑都是不一样的,这一块的报警就要引入算法去做。

 

  • 周期差异性:不同时间范围,波动巨大,导致无法固定阈值“一刀切”;

 

新浪的业务是偏媒体类的,早上9点、晚上23点会存在访问高峰,中间时间段的流量则不是很规律,对于这种场景,也需要算法去实现。

 

  • 数据多维度:维度众多,出现问题不知道是什么导致的,导致报警只能是“吹哨”。

 

传统的报警,只会告诉你出了什么事,运维人员需要登录机器,一顿shell操作排查原因,我们则希望是收到报警后,能及时告诉我们是什么原因,具体是哪个组件出了问题等。

 

图片

 

基于以上思考,我们做了无阈值的异常检测。

 

如上右图,是同一MySQL的两个不同业务,我们看到基准值相差非常大,一个1ms,一个5ms,靠人工加报警阈值,已然不现实。

 

因此,我们的监控系统在不同的业务调用链上,有各自不同的阈值,报警系统会根据各自的模型判断报警。

 

图片

 

当触发报警条件时,能不能告诉用户一些信息,以此提升信息的有效荷载呢?

 

举个例子,上图是一个web服务5xx的报警,传统运维可能会配置500、502、504多个报警,无疑会增加工作量。现在我们支持配置一个5xx的报警,让报警告诉你现在是谁占得多?哪个运营商的用户受影响最大?具体是哪个接口?有了这些信息,就可以帮助运维减少大量的排查工作。

 

目前报警特征这部分的功能,我们用了较经典的算法——关联规则算法,该算法不是简单每个维度group by,一份日志会有个几十上百个字段,特征组合是Cn1的复杂度,它能够有效减少计算的时间复杂度。

 

图片

 

在AIOps应用上,我们还做了多级服务日志关联,定位问题产品位置。如图是端上发生的一次链路,我们展示了它在后端整个调用链路,在这个过程中,它对哪些资源依赖、对各个链路上是否有问题,我们都可以很直观看到。

 

以上就是我们在算法层面的一些应用。

 

四、数据科学应用

 

数据科学应用是我们近两年重点发力的方向,这块更偏向于运维垂直领域下的数据分析,和我们传统业务的数据分析不大一样。

 

近两年,大家都在讲降本增效,在整个运维体系中,也避免不了降本增效的需求。

 

图片

 

在增效方面,我们的运维生命周期,以及运维生命周期中的故障排查、处理流程,也完全用数据走成了闭环。

 

图片

 

在降本方面,我们进行了K8s资源智能分配。

 

如图是K8s资源分配的模板,K8s组员分配是按照request和limit来预分配的,但因为实际使用是动态、不确定的,这就可能会造成资源浪费,如果用HPA覆盖的话,又存在滞后性,业务会抖动一下,才能把资源拉高。那么这个问题怎么解决呢?

 

图片

 

我们用一些简单的数据分析,就把问题解决了。如上图所示是财经类的业务,周六日不开盘,量非常少,工作日9-11点、14-16点开盘,黄色曲线是K8s request给某个项目两周时间全部CPU,绿色是实际CPU的使用情况,可以看到有明显的大周期和小周期,如果把黄线拉得过高,大部分业务空闲的时候,资源就会白白浪费。

 

目前,我们是贴着实际使用量去分配资源的,首先通过长期实际使用的数据进行观测,再根据实际使用的CPU情况,判断出下一时刻资源的预期,把下一时刻的资源改成预期数值,最终实现降本的目标。

 

接下来分享我们在数据可视化方面的一些案例。

 

图片

 

大家在做数据分析的时候,往往会使用一些平均值、P99、中位数等,但有时候这类数据会造成极大的信息偏差,如上右图,散点形状一直在变化,均值、方差基本上在小数点后3位才有差异。

 

这提醒我们,在做数据可观测、数据分析的时候,提取的指标本身可能没有意义,无法反馈处问题的真实情况。

 

那么我们是如何利用数据可视化解决实际问题的呢?

 

图片

 

前面提到的降本增效,除了要减少资源的不合理分配,还有一个目标就是要通过数据分析,找到不合理的服务器利用率。

 

上右图是内部针对服务器的利用率做的散点图分析,由图可见,有的业务利用率都集中在上部,这种一般是离线计算业务,CPU越高越好;有的业务CPU分布呈现枣核型,分布比较平均,一般常见于在线业务,因为要保障响应时间,所以不能把CPU堆的特别高,有的又全是很低,这种就不太合理。

 

有时候运维总说服务器不够用,通过实际的利用率分析观察,发现服务器不够用只是个假象。就如K8s问题,预期和实际使用的GAP其实是非常大的,把GAP消除掉之后,就发现有大把的资源闲置。

 

在提高服务器利用率上,我们往前延伸了一步,把散点图增加了时间序列,变成了时间序列热力图。

 

图片

 

如图是某个业务线某天所有服务器CPU使用率的热力图,右上角X轴是CPU利用率,越靠右越高,Y轴是对应的服务器数量。

 

上右图服务器利用率一部分较高、一部分较低,但是这个图它只能体现出一天的情况,为增加时间维度,我们把这个图做成了下面的时间序列热力图,X轴又变成了日期,颜色的深浅来代表多少服务器的多少,然后 Y轴变成了CPU利用率。

 

明显看到,随着时间的变化,集中在上半部的颜色越来越深,说明这个部门CPU的利用率高的机器是越来越多的,这样的话,就避免了我们只用某一时刻的数据来简单描述数据,让数据变得更加客观真实。

 

这个案例属于宏观层面的分析,业界有做eBPF分析的,比如IO的latency分布,也会使用这种时间序列热力图进行展示。

 

图片

 

如上图所示,我们在数据分析上,也对CDN服务做了多维度的数据展示。图中是一个多家CDN性能的综合对比,展示了五个维度的动态数据,其中包括日期数据,颜色代表厂家,圆圈大小代表体量,X轴和Y轴分别代表了CDN的响应时间和下载时间。

 

通过这个图,我们可以非常直观判断厂商产品质量,实现多维度的数据可观测。

 

图片

 

除此之外,我们还做了能够给运维直接赋能数据能力的工具——交互式BI分析工具。

 

数据分析的最后一公里,是让需要用的人,以一个很低的成本用起来,如我们内部的APM日志回捞的工具,CDN的同事就会经常用来分析问题。作为基础服务,需要快速排查用户的投诉问题,比如用户反馈视频的首帧慢了、图片加载异常了,使用这些工具,就能够快速的看到到底是DNS的原因,还是TCP建联的问题,还是后端服务的确是慢了。

 

图片

 

图片

 

前面提到,ClickHouse解决了从数据存储、查询的问题,但实际上让数据用起来,还是有一定难度的。很多运维人员不太会写SQL,因此我们内容做了类似数据打捞的工具,使用者可以简单通过勾选,完成数据提取和数据聚合等查询工作。

 

图片

 

最近ChatGPT特别火,我们也在尝试与其建立连接。

 

前面提到使用勾选工具,解决写SQL难的问题,那么能否通过自然语言描述的形式,让ChatGPT生成我们想要的SQL呢?

 

通过测试,90%的情况下,ChatGPT都能“听懂”描述,给出正确的SQL,未来相信也能不断帮助我们降低数据获取的难度。

 

五、未来展望

 

 

1、数仓的可拓展

 

图片

 

近几年OLAP领域发展火爆,国产产品也非常优秀,比如databend这种定位于存算分离架构的数据仓库。

 

ClickHouse虽已经一款高性能的数仓产品,但在运维层还有一定的复杂度,未来我们会引入存算分离的数据仓库,进一步地减少在数据存储、运维方面的压力。

 

 

2、数据分析的未来

 

图片

 

前面讨论了很多用工具降低数据分析难度的时间,那么ChatGPT是否也能让数据分析变得简单?能否直接把数据给ChatGPT,让AI直接给我们结论呢?

 

如图是直接从Nginx7层服务里导出来的一些日志,直接给到ChatGPT后,发现它可以直接做好初步的数据分析结论,判断异常、响应时间分布等情况,结果让我们感到兴奋,AI的思考能力实在强大。

 

 

3、全路径可观测

 

图片

 

有了全链路、端上监控后,发现端上报的指标都是非常宏观的,不能马上定位到根本问题,这些工作非常依赖于资深SRE,通过抓包、系统工具,排查系统层、内核层的指标才能找到根因所在,整体非常耗时。

 

再如,客户端、后端、DB层、TCP层等都需要更微观的监控,线上有很多异常,可能是TCP重传、RTT恶化导致的,这些根因数据我们在应用宏观层面是没办法拿到的。

 

因此,我们未来要做更微观的可观测。目前我们做的是基于eBPF,去拿一些内核层面的微观数据做解释,逐步让可观测“深入骨髓”。

 

最后和大家分享业界常说的一句名言:“If You Can't Measure lt,  You Can't lmprove lt.”

 

做数据可观测,本质上是通过各种手段降低数据衡量的难度、数据使用的复杂度,让数据成为武器,让开发提效,让运维“安稳长满优”。

 

Q&A

 

Q1:底层用ClickHouse作为OLAP的数据库,如何支撑实时的并发查询呢?

 

A1:OLAP产品谈并发本身是个伪命题,这个场景大部分是热数据,真正需要并发需求的,可能就是近几分钟的数据,这类热数据,本身就有较高的并发性能。

 

其次,ClickHouse本身也会有各种各样的机制去提升并发性能,比如物化视图等,通过构建视图,把原始数据做提取并物理存储,提取后的数据再查询,基本上也能达到千级别QPS。

 

Q2:AIOps的链路图是通过聚合出来的吗?通过自定义协议怎么采集这些节点?

 

首先,拓扑图本身没有太大的技术含量,主要就是依赖端上日志的记录,包括我们看到从APP到后端,链路管理本质上有记录全局ID,有了ID就能知道先后,OpenTelemetry也是一样的逻辑,只不过OpenTelemetry增加了Span ID的概念,可以看到调用的上下游关系,本身没有什么特殊的地方。

 

Q3:AIOps链路的采样率是怎样的?会不会影响性能?

 

端上的采样率是严格控制的,比如采用率低于1%,数据量也非常大的。如果采样率不合理,对数据的观测肯定会有影响,所以可以通过针对VIP用户全量采集的方式,去规避问题排查缺少数据支撑的情况。

 

采样规则的开关是可以随时去调的,比如某段时间需要增加采集量,就可以随时把开关调大。其次在采访的时候,错误日志是全量上报的,这样也能保障数据的客观性。后端链路监控也是类似的规则,业务量较小是,基本上是全量采集。

 

所以目前来看,对性能的影响是微乎其微的。

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告