幸运飞艇
主页 > 技术专区 > 故障排查 >

随手记统一监控平台Focus设计解析

2019-08-06 20:59 故障排查 已读

  应用监控是多数互联网公司最重要的基础设施之一,其意义不仅在于可以帮助开发人员应对分布式环境下的 Trouble Shooting 和性能管理难题,更是系统可用性的第一步。Focus 是由随手记研发的统一应用监控平台,承载了随手旗下随手记、卡牛两款产品数百个服务的应用监控任务。本文将对 Focus 的设计思路和关键实现进行剖析。(本文根据 2018 年 10 月张越在 QCon 上海站的演讲整理而成,有一定的补充和删减。)

  “监控是一个宽泛的概念,代表了很大的一块领域,有很多独立的系统在其中发挥作用。在介绍具体内容之前,我想先阐述一下通常互联网公司的监控的体系是什么样的。

  在实际运用中,运营和开发人员都会关注业务指标,如果业务指标◁☆●•○△异常,则首先 check 应用监控了解是否系统原因导致,如不是则可能是外部原因如营销活动、渠道问题等。开发人员在日常 DevOps 活动中则重度依赖应用监控,任何动作都需要确保对线上的影响是可控的。若发生问题时问题根因指向系统层面,则运维 check 系统监控是否存在系统级问题,如磁盘满,网络抖动。

  以上就是一个互联网公司的典型▪▲□◁监控体系,本文介绍的 Focus 系统是一个应用层监控系统,专注于为开发人员提供线上应用的故障排查与性能管理能力。

  开源社区在监控体系内各方向上均有成熟的产品贡献。和大多数公司一样,随手记最也选择基于开源产品来组建应用监控系统,并摸索实践了 1 年多的时间。直到架构发展到如下阶段:

  在这个阶段我们实际搭建了三个子系统作用于日志、调用链和指标的处理,并且通过二次开发的方式对其进行了很多适用性和易用性改造,基本实现了开发人员的常见需求。但我们的问题还没有解决完,当我们想要更进一步的时候我们遇到的问题是:

  因此我们在 2017 年决定使用平台化手段解决上述问题,开始着手建设统一监控平台。力求整合资源,统一处理,用一套系统解决应用监控问题。Focus 就是为▲●…△满足上述目的开发的监控平台,目前承载着“随手记”、“卡牛”两个产品近千个核心服务的应用监控任务。

  监控系统本质是一个采集和分析系统,设计上则要遵循分析指导采集的思路。应用监控的难点就在于不仅要回答“有没有问题”,还要回答“是什么原因”。我认为要回答好这两个问题,至少需要以下 3 个维度的信息做支持:

  Transaction 事务 :一个应用系统必然是为了完成某样事务存在的,那么它的事务完成的如何? 例如对请求的响应是否成功,每个环节性能快慢?可以说事务执行情况代表了应用的可用性。

  Event 事件:应用内部发生了什么事情? 例如是否有异常发生?是否发生过主从切换?事件溯源为解决问题提供重要的细节信息。

  Stats 状态 :应用内部的状态如何? 例如当前队列的长度? 线程池空闲线程数?一共处理了多少数据? 状态的观测和预测在发现问题方面非常有用。

  Focus 不仅要满足对这三种监控信息进行的采集和分析,还要利用它们之间的配合来组成一个完善的故障排查逻辑。通过数据来支撑工程师做出判断,逐步收敛和排除噪声最终过滤出根因,这是 Focus 系统能够高效排障的思路。

  实现方面,平台化的核心优势是可以进行多种数据的联合分析与展现。在出报表上做到原先单一系统做不出的报表,提供更有力的决策数据;在报表的规划上则可以做完整排查逻辑并衔接成清晰的排查步骤,提升故障排查能力。

  整个排查过程思路清晰且每个跳转均提供有力的数据支撑,没有多余噪音。该操作逻辑的背后则是多维数据的相互协作。

  事务观测:基于 Google Dapper 理念的 Span 数据结构。 包含耗时和失败等事务状态信息,通过 Tracing ID 支持分布式事务。

  事件观◆●△▼●测 :事件日志,KV 数据结构,可以附加任意多的额外信息。如果是事务内发生的事件则可以通过 Tracing ID 追溯到。

  在数据处理流程方面,Focus 设计为一个全量采集系统,但不支持全量数据检索。我认为全量数据检索是导致监控系统臃肿复杂的重要原因。在监控场景中,用户需要有代表性的数据以支持决策,而不是海量原始数据的直接检索。因此 Focus 从一开始就放弃了做全量数据存储的念头,只保留典型样本数据即可。这样的设计还降低了流量敏感性,在 11.11、除夕红包等大型活动下,业务流量突然增大不会导致系统存储压力有明显的变化。不过 Focus 保▼▲留了原数据实时供数能力 (Kafka)。在随手记内部,额外的分析需求是由单独的大数据系统负责的。

  对目标的把握和清晰的设计思路让 Focus 面对海量数据流量时可以保持简单,高效,低成本。

  Focus 服务端本质上是一个流计算系统。而如何化解流计算系统固有的挑战是主要设计问题。我主要讲以下几个关键问题的决策:

  由于 Focus 同时处理 3 种异构数据,并且每一种数据结构的吞吐量都非常大。在早期设计中为了接纳这些数据存储需求,使用了不同的针对性数据库产品。最多的时候平台需要依赖 4 种不同的数据库产品才可以跑起来。这带来了很大的存储方面的复杂性,于是我们开始想办法着手简化。

  存储的问题在于:需要用一个数据库支持三种数据结构的高性能存储。考察了一圈,我们决定使用 ElasticSearch 作为低层引擎。理由是 ElasticSearch 可以很好的存储 Span 和 Log 数据,并拥有胜任海量时间序列存储和检索的基础特性:

  依靠 ElasticSearch 的强大可塑性,我们在其上设计了一个装饰层。 通过装饰层,ElasticSearch 将作为低层存储引擎按需提供以下几种形态的服务:

  以时间序列为例,上图为列举的一些大块的优化点,在装饰服务的针对优化下,最终我们做到了压缩比 10:1 的时序存储,单节点~1w 读和~12w 写的性能,90% 的聚合查询都可以在 2 秒内返回结果, 并且支持复杂聚合查询。 这个结果在我们的场景中相比 InfluxDB 也是毫不逊色的。

  Focus 客户端会一次性把全部需要的信息采集到,包括 Span、Log、Metric 和一些 Meta△▪▲□△data。是一个一站式采集客户端。

  在接入方面提供针对事务、事件、状态的三套埋◇=△▲点 Low-Level API。开发人员可以按需埋点满足个性化需求。在 Low-Level API 的基础上,Focus 提供常见中间件的预埋点包,大多数应用的接入都只需要引包即可,甚至可以不需要配置文件。

  在设计上我们让客户端尽量的简单,只做好采集这一件事情就可以了。因此放弃了一些有诱惑力的想法,包括在客户端进行聚合、配置下达、字节码修改等。事实证明这样带来了很多好处:客户端更不易出错且设计稳定不易变化。出错和易变是客户最不愿意接受的;整个客户端的逻辑很少且容易理解,在开发跨语言客户端和用户自行扩展时都非常的容易;另外性能也很容易做到很高。

  在实现上客户端的整个处理步骤都是异步的,减轻对业务的影响。 优化方面手段主要是针对队列◇•■★▼和序列化的优化、对消费线程唤醒的控制、以及严格控制内存和对象的使用,防止因为监控导致 GC。

  事实上监控系统内的设计决策远不止这些,篇幅所限就不全部介绍了。最后我总结了◆▼一些在进行监控系统设计时的心得可以供大家参考:

  Simple is powerful 少就是多。做设计抉择时,只有一个核心评判◆◁•标准:哪个方案更简单。

  不要让客户端做太多▲★-●事情。我们曾经维护了一个功能强大而智能化的客户端,直到不得不下决心重做。Focus 版本越高的客户端功能反而越少。

  考虑全量存储的必要性。存储很容易成为系统的瓶颈,我们尝试在全量存储上做优化,后来发现 90% 的信息都没人看,于是我们转变了思路。

  利用开源工具来实现你不感兴趣的部分,只做感兴趣的那部分就行了。 Focus 把很多枯燥困难的工作都甩给 Kafka 和 ES 来解决了:) 。

  为目标设计。先了解用户想看什么并为此设计报表,然后为了实现该报表而反推数据处理和采集设计。错误的思路:采集一堆数据再进行数据挖掘最后看看能出什么报表。

  不追求★▽…◇完美。勇于把不完美的东西发布给用户用,吐槽是必然的,但有用户才有演化的方向。

  最后我想说 Focus 仍然在不断的迭代中,很多设计取舍也和公司规模和具体场景有很大关系,所谓抛砖引玉,欢迎大家和我们交流。

  监控系统•●是整个 IT 架构中的重中之重,小到故障排查、问题定位,大到业务预测、运营管理,都离不开监控系统,可以说一个•□▼◁▼稳定、健康的 IT 架构中必然会有一个可信赖的监控系统。InfoQ 的编辑们收集了一些好用且开源的监控工具,请在 InfoQ 后台回复关键词:工具,获取文章地址。

  张越,随手记基础平台部架构师,负责随手记统一监控平台 (Fo○▲-•■□cus) 的设计和研发,同时负责基础中间件的设计研发。拥有 10 年服务端经□◁验,既负责过业务架构设计,也经历过工具化平台建设,致力于使用平台化手段解决业务效率问题。目前专注于分布式环境下的应用观测和监控。

  新时代的运维不在乎局限于操作和维护,转型 DevOps、SRE 的路★△◁◁▽▼上还有更多的挑战,关注新一届的 QCon 大会,100+ 技术大咖给你解答启发。

  QCon 北京 2019 现已全新起航,除了一些常规的专题设置外,新增了用户增长、智慧零售等当下热点话题,在技术深度和广度上不断延展。目前大会 7 折报名中,立减 2640 元。识别二维码了解 QCon 十周年的精心策划。

  议题讲师持续邀约中,如果你有好的话题并乐于与他人分享,欢迎点击「 阅读原文 」提交议题。返回搜狐,查看更多

幸运飞艇

电话:4008-888-2414 邮箱:http://www.iecofire.com

地址:江苏省南京市玄武区玄武湖

Copyright ©幸运飞艇官网注册 版权所有 | Sitemap | 网站导航 苏ICP564654

Powered by