全链路监控跟踪-资料整理和简单学习

=Start=

缘由:

业界大部分的应用分布式追踪的原理源自 Google 的一篇 Dapper系统的论文,比较出名的有:

  • Twitter贡献出来的Zipkin
  • 阿里的鹰眼
  • 腾讯的天机阁
  • 韩国人开源的Pinpoint
  • 国人开源的SkyWalking
  • 美团点评的CAT
  • 新浪的Watchman
  • 京东的Hydra [开源项目已于2013年6月停止维护]

正文:

参考解答:
微服务之熵:

为了支撑日益增长的庞大业务量,业界大量使用微服务架构。服务按照不同的维度进行拆分,互联网应用构建在不同的软件模块集上,这些软件模块可能是由不同的团队开发、可能使用不同的编程语言来实现、可能布在了几千台服务器,横跨多个不同的数据中心,分布式系统变得日趋复杂。一个请求的完整调用链可能如下图所示:

一个请求的调用链示例

基于微服务体系之下构建的业务系统存在的问题基本上分为四类:

第一个是故障定位难,今天我们淘宝下单的动作,用户在页面上点购买按钮,这么一个简单操作,其实它背后是由十几个甚至数十个的微服务去共同完成的,这十几个甚至几十个微服务也由不同的团队去负责,这是微服务的过度协同带来的结果,一旦出现问题,最坏情况下我们也许就要拉上十几个团队一起来看问题。

第二个问题是容量预估难,阿里每年要做若干次大促活动,在以前的巨石系统当中做容量预估是非常容易的,因为我们大促时候按照预估的流量与当前系统的单机压测容量做一个对比,把所有的系统按比例去扩容就可以了。而实际上在大促的场景下,每一个系统在核心链路当中的参与度、重要性都是不一样的,我们并不能对每一个系统做等比例的扩容,所以微服务架构下的容量预估也是一件难事。

第三个问题就是资源浪费多,资源浪费多首先是容量预估不准的一个后果,同时资源浪费多背后隐含的另一个问题就是性能优化难,为什么这么说呢?我们当打开一个页面发现它慢的时候,我根本不知道这个页面慢在哪里,瓶颈在哪里,怎么去优化,这些问题累积下来,资源的浪费也成为了一个巨大的问题。

第四个是链路梳理难,我们一个新人加入阿里的时候,老板让他负责一个系统,他在这个复杂的微服务体系中,就像人第一次在没有地图没有导航的情况下来到一个大城市一样,根本不知道自己身在何处。应用负责人不知道自己的系统被谁依赖了,也不知道自己的系统下游会影响其他哪些人。

整体来看,我们所说的微服务之熵主要就包含了上述这四个问题。

全链路监控系统希望达到的效果:
  1. 请求链路追踪,故障快速定位:可以通过调用链结合业务日志快速定位错误原因。
  2. 可视化: 记录各个阶段耗时,进行性能分析。
  3. 依赖优化:统计各个调用环节的可用性、梳理服务依赖关系以及优化。
  4. 数据分析,链路梳理和优化:分析用户的行为路径,梳理和优化整体调用链路。
全链路监控系统组件的一些目标要求:
  1. 探针的性能消耗——APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径。在一些高度优化过的服务,即使一点点损耗也会很容易察觉到,而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
  2. 代码的侵入性——作为业务组件,应当尽可能少入侵或者无入侵其他业务系统,对于使用方透明,减少开发人员的负担。对于应用的程序员来说,是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效,就必须需要依赖应用的开发者主动配合,那么这个跟踪系统也太脆弱了,往往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题,这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
  3. 可扩展性——一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API,对于一些没有监控到的组件,应用开发者也可以根据需要自行扩展。
  4. 数据的分析——分析的速度要尽可能快 ,分析的维度要尽可能多。监控跟踪系统越能提供足够快、足够准的信息反馈,开发、运维就越能对生产环境下的异常状况做出快速反应。
常见的开源全链路监控系统简单对比:
基本原理对比:
类别ZipkinPinpointSKYWALKINGCAT
实现方式拦截请求,发送(HTTP,MQ)数据至Zipkin服务Java探针,字节码增强Java探针,字节码增强代码埋点(拦截器,注解,过滤器等)
接入方式对比:
类别ZipkinPinpointSkyWalkingCAT
实现方式基于Linkerd或者Sleuth方式,引入配置即可JavaAgent字节码JavaAgent字节码代码侵入
分析粒度对比:
类别ZipkinPinpointSkyWalkingCAT
颗粒度接口级方法级方法级代码级
全局调用统计×
traceid查询××
报警×
JVM监控××
其它对比项:
  • 管理端功能;
  • 数据存储方式;
  • 社区活跃度;
  • 插件化、定制化难易程度;

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4438.html

《全链路监控跟踪-资料整理和简单学习》上有4条评论

  1. 应用性能管理の巅峰对决:Apache Skywalking P.K. Pinpoint
    https://mp.weixin.qq.com/s/uKqy5XX8wuMuOPZ9iNTqZg

    社区比较
    支持语言比较
    协议比较
    存储比较(重要)
    UI比较
    扩展性比较
    告警比较
    JVM监控
    服务监控
    跟踪粒度比较
    过滤追踪
    性能损耗
    发布包比较
    支持组件比较
    总结
    参考链接

    说明:本次对比基于skywalking-6.0.0-GA和Pinpoint-1.8.2(截止2019-02-19最新版本)。另外,我们这次技术选型直接否定了Zipkin,其最大原因是它对代码有侵入性,CAT也是一样。这是我们所完全无法接受的。

  2. 基于APM的智能运维体系在京东物流的落地和实践
    https://mp.weixin.qq.com/s/SgD1djsi1lgRaxl1M0WJ9A

    本文整理自 2019 年 QCon 北京站上京东物流架构师付正全的演讲,主要介绍了京东物流大规模实时监控平台、AIOps 和 APM 的相关实践。

    为了支撑业务的高速发展,京东物流在智能运维体系的落地和构建方案上一直迭代优化、持续演进。从构建基于系统指标的实时大规模智能监控平台到融合多个部门多个监控平台的统一监控平台实践,再到基于 APM 的智能运维体系落地。通过实时告警、实时预警、故障智能处理以及全方位的应用维度数据分析,大大缩短了研发人员定位问题的效率,有力保障了大促期间各系统的平稳运行。

    我们在构建这套运维体系的时候大体上分为以下三个阶段:
    第一阶段是构建实时的大规模监控平台。这个阶段是一个从 0 到 1 的过程,从基础的 CMDB 系统建设到建设大规模实时监控平台。
    第二阶段在监控平台的基础上整合了京东现有的多个应用监控系统。结合应用维度的数据整合,进一步完善了监控数据维度的同时极大提高了研发人员进行故障定位的效率。
    第三阶段我们开始了 APM 和 AIOps 相关的一些尝试。

    下面我会从以下几个方面来介绍今天的内容:
    · 智能运维发展的现状和趋势
    · 智能运维体系建设方法论
    · 大规模实时监控平台的实践方案
    · 智能故障定位与处理实践
    · APM 在京东物流的落地实践
    · 智能运维落地规划

发表评论

电子邮件地址不会被公开。 必填项已用*标注