ASPIRE

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

=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=

Docker

,
, , ,

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

  3. 应用性能管理の巅峰对决：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也是一样。这是我们所完全无法接受的。
    `

    回复

  4. 基于APM的智能运维体系在京东物流的落地和实践
    https://mp.weixin.qq.com/s/SgD1djsi1lgRaxl1M0WJ9A
    `
    本文整理自 2019 年 QCon 北京站上京东物流架构师付正全的演讲，主要介绍了京东物流大规模实时监控平台、AIOps 和 APM 的相关实践。

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

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

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

    回复

  7. 开源分布式跟踪方案概览
    https://www.infoq.cn/article/f5bBD119Zv49aak_eByE
    https://developers.redhat.com/blog/2019/05/01/a-guide-to-the-open-source-distributed-tracing-landscape/
    `
    本文对最流行的工具进行了概述和分类，能够帮助你掌握分布式跟踪领域的概况。

    虽然跟踪和采样分析是密切相关的两个学科，但是分布式跟踪通常被理解将应用中不同工作单元的信息连接在一起，以便理解整个事件链的技术，这些工作单元会在不同的进程或主机中执行。在现代应用程序中，这意味着分布式跟踪可以用来描述 HTTP 请求在穿越大量微服务时的情况。

    这里所列的大多数工具可以大致分为 instrumentation 库、tracer、分析工具（analysis tool，后端 +UI），以及它们的任意组合。博文“各种跟踪方式的差异”很好地描述了分布式跟踪的这三个方面。

    对于本文来讲，我们将instrumentation定义为用来告诉记录哪些信息的库，将tracer定义为如何记录并提交数据的库，将分析工具定义为接收跟踪信息的后端。在现实中，这些分类是不断变化的，instrumentation 和 tracer 的区别并不会始终那么明显。类似的，分析工具这个术语可能会过于宽泛，因为有些工具会关注探索跟踪信息，而有些则是完整的可观察性平台。

    本指南只列出了开源的项目，不过还有一些其他的厂商和解决方案值得关注，比如 AWS X-Ray、Datadog、Google Stackdriver、Instana、LightStep 等。
    `

    回复

  8. 饿了么监控系统 EMonitor 与美团点评 CAT 的对比
    https://mp.weixin.qq.com/s/Dt-o1Cg6jcmn-Ez3n6CL5w
    `
    饿了么监控系统 EMonitor ：是一款服务于饿了么所有技术部门的一站式监控系统，覆盖了系统监控、容器监控、网络监控、中间件监控、业务监控、接入层监控以及前端监控的数据存储与查询。每日处理总数据量近 PB ，每日写入指标数据量百T，每日指标查询量几千万，配置图表个数上万，看板个数上千。

    CAT：是基于 Java 开发的实时应用监控平台，为美团点评提供了全面的实时监控告警服务。

    本文通过对比分析下两者所做的事情为契机讨论监控系统或许该有的面貌，以及浅谈下监控系统发展的各个阶段。

    # 浅谈监控系统的发展趋势

    1、日志监控阶段

    本阶段实现方式：程序打日志，使用ELK来存储和查询程序的运行日志， ELK 也能简单显示指标曲线。
    排障过程：一旦有问题，则去 ELK 中搜索可能的异常日志来进行分析排障。

    2、链路监控阶段

    上一个阶段存在的问题： ELK 只是基于一行一行日志进行聚合或者搜索分析，日志之间没有上下文关联。很难知道一次请求耗时较长究竟耗时在哪个阶段。

    本阶段实现方式： CAT 横空出世，通过建模抽象出 Transaction、Metric 等监控模型，将链路分析和简单的报表带入了大家的视野。

    告警方式：针对报表可以进行阈值监控排障过程：一旦有告警，可以通过点击报表来详细定位到是哪个 type 或 name 有一定问题，顺便找到对应的链路，查看详细的信息。

    3、指标监控阶段

    上一阶段存在的问题： CAT 对自定义指标支持的比较弱，也无法实现或者展现更加多样的查询聚合需求。

    本阶段的实现方式：支持丰富的 Metric 指标，将链路上的一些报表数据也可以划分到指标中，交给专业的时序数据库来做指标的存储和查询，对接或者自研丰富的指标看板如 Grafana 。

    告警方式：针对指标进行更加丰富的告警策略排障过程：一旦有告警，可能需要到各个系统上查看指标看板，粗略定位根因，再结合链路总和分析。

    4、平台打通整合阶段

    上一阶段存在的问题：系统监控、中间件和业务监控、部分业务监控、链路监控与指标监控都各搞一套数据收集、预处理、存储、查询、展现、告警流程，各个系统处理数据格式、使用方式不统一。

    本阶段的实现方式：打通从系统层面、容器层面、中间件层面、业务层面等等的可能的链路和指标监控，统一数据的处理流程，同时整合发布、变更、告警与监控曲线结合，成为一站式监控平台。

    告警方式：可以统一的针对各个层面的监控数据做统一化的告警排障过程：只需要在一个监控系统中就可以查看到所有的监控曲线和链路信息。

    目前我们 EMonitor 已完成这个阶段，将公司之前存在已久的 3 套独立的监控系统统一整合成现如今的一套监控系统。

    5、深度分析阶段

    上一阶段存在的问题：
    * 用户虽然可以在一个系统中看到所有各个层面的监控数据了，但是每次排障时仍然要花很多的时间去查看各个层面是否有问题，一旦漏看一项可能就错过了问题所在的根因；
    * 没有整个业务的全局监控视角，都停留在各自应用的角度。


    总之：之前的阶段都是去做一个监控平台，用户查询什么指标就展示相应的数据，监控平台并不去关心用户所存储数据的内容。现在呢就需要转变思路，监控平台需要主动去帮用户分析里面所存储的数据内容。

    本阶段的实现方式：所要做的就是把帮用户分析的过程抽象出来，为用户构建应用大盘和业务大盘，以及为大盘做相关的根因分析。

    * 应用大盘：就是为当前应用构建上下游应用依赖的监控、当前应用所关联的机器监控、redis、MQ、database 等等监控，可以时刻为应用做体检，来主动暴露出问题，而不是等用户去一个个查指标而后发现问题；

    * 业务大盘：就是根据业务来梳理或者利用链路来自动生产大盘，该大盘可以快速告诉用户是哪些业务环节出的问题。

    根因分析：一个大盘有很多的环节，每个环节绑定有很多的指标，每次某个告警出来有可能需要详细的分析下每个环节的指标，比如消费 kafka 的延迟上升，有各种各样的原因都可能导致，每次告警排查都需要将分析流程再全部人为分析排查下，非常累，所以需要将定位根因的过程通过建模抽象下，来进行统一解决。

    趋势报表分析：主动帮用户发现一些逐渐恶化的问题点，比如用户发布之后，接口耗时增加，很可能用户没有发现，虽然当前没有问题，但是很有可能在明天的高峰期就会暴露问题，这些都是已经实实在在发生的事故。

    要想做主动分析，还深度依赖指标下钻分析，即某个指标调用量下降了，能主动分析出是哪些 tag 维度组合导致的下降，这是上述很多智能分析的基础，这一块也不简单。

    告警方式：可以统一的针对各个层面的监控数据做统一化的告警排障过程： NOC 根据业务指标或者业务大盘快速得知是哪些业务或者应用出先了问题，应用的 owner 通过应用大盘的体检得知相关的变动信息，比如是 redis 波动、database 波动、上下游应用的某个方法波动等等，来达到快速定位问题目的，或者通过对大盘执行根因分析来定位到根因。

    # 再谈 Logging、Tracing、Metrics
    三者的确都不可或缺，相辅相成，但是我想说以下几点：
    * 三者在监控排障中的所占比例却大不一样： Metrics 占据大头， Tracing 次之， Logging 最后；

    * Tracing 含有重要的应用之间的依赖信息， Metrics 有更多的可深度分析和挖掘的空间，所以未来必然是在 Metrics 上大做文章，再结合 Tracing 中的应用依赖来做更深度全局分析，即 Metrics 和 Tracing 两者结合发挥出更多的可能性。

    `

    回复

  9. 漫谈分布式链路追踪
    https://juejin.im/post/5e1afbcbe51d451ca73d877b
    `
    链路跟踪
    * 基于特定语言实现的方案
    * 基于组织内编码规范的实现
    * 基于mesh的方案
    模型和协议设计
    * 数据模型
    * span之间的关系
    * 透传实现原理
    * span日志数据构成、透传与搜集
    模块拆分和设计边界
    * 系统模块拆分
    * 客户端功能拆分和实现
    * 类与接口设计
    有趣的设计细节
    * Trace-id vs log-id
    * Java-agent与字节码增强
    典型的应用场景
    * 请求染色（环境路由）
    * 其他应用场景
    `

    回复

  11. 有赞全链路追踪实践
    https://mp.weixin.qq.com/s/TAiQjfkxJd_uDkDHNE_Sjg
    `
    全链路追踪系统就是为了解决微服务场景下的这些问题而诞生的。一般地，该系统由几大部分组成：
    * 客户端埋点SDK：集成在各业务应用系统中，完成链路追踪、数据采集、数据上报等功能；
    * 实时数据处理系统：对客户端采集上来的数据进行实时计算和相关处理，建立必要索引和存储等；
    * 用户交互系统：提供用户交互界面，供开发、测试、运维等用户最终使用链路追踪系统提供的各项功能；
    * 离线分析系统：对链路追踪数据进行离线分析，提供诸多强大的链路统计分析和问题发现功能；

    有赞目前的应用类型有很多种，已经支持追踪的语言有 Java、Node.js、PHP。那么，如何让跨不同语言的调用链路串到一起呢？有赞的链路追踪目前在使用的是Cat协议，业界也已经有比较成熟的开源协议：OpenTracing，OpenTracing是一个“供应商中立”的开源协议，使用它提供的各语言的API和标准数据模型，开发人员可以方便的进行链路追踪，并能轻松打通不同语言的链路。

    Cat协议与OpenTracing协议在追踪思路和API上是大同小异的。基本思路是Trace和Span：Trace标识链路信息、Span标识链路中具体节点信息。一般在链路的入口应用中生成traceId和spanId，在后续的各节点调用中，traceId保持不变并全链路透传，各节点只产生自己的新的spanId。这样，通过traceId唯一标识一条链路，spanId标识链路中的具体节点的方式串起整个链路。

    全链路追踪系统包含几大部分：链路采集SDK、数据处理服务、用户产品。SDK部分比较偏技术。数据处理更考验数据处理的吞吐能力和存储的容量，采用更高级的链路采样解决方案可以有效降低这部分的成本。用户产品主要考验的是设计者对用户需求的把握，全链路追踪可以做很多事情，产品上可以堆叠出很多功能，怎样能让用户快速上手，简洁而又易用是链路追踪产品设计的一大挑战。
    `

    回复

  12. 监控系统选型，这篇不可不读！
    https://mp.weixin.qq.com/s/eKc8qoqNCgqrnont2nYNgA
    `
    这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括3部分：
    * 必知必会的监控基础知识
    * 主流监控系统介绍
    * 监控系统的选型建议

    # 01 必知必会的监控基础知识
    1. 监控系统的7大作用
    实时采集监控数据：包括硬件、操作系统、中间件、应用程序等各个维度的数据。
    实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。
    预知故障和告警：能够提前预知故障风险，并及时发出告警信息。
    辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。
    辅助性能调优：为性能调优提供数据支持，比如慢SQL，接口响应时间等。
    辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。
    辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

    2. 使用监控系统的正确姿势
    了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
    确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
    定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
    建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

    # 02 主流监控系统介绍
    1. Zabbix（老牌监控的优秀代表）
    2. Open-Falcon（小米出品，国内流行）
    3. Prometheus（号称下一代监控系统）

    # 03 监控系统的选型建议

    通过上面的介绍，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：

    1、先明确清楚你的监控需求：要监控的对象有哪些？机器数量和监控指标有多少？需要具备什么样的告警功能？

    2、监控是一项长期建设的事情，一开始就想做一个 All In One 的监控解决方案，我觉得没有必要。从成本角度考虑，在初期直接使用开源的监控方案即可，先解决有无问题。

    3、从系统成熟度上看，Zabbix属于老牌的监控系统，资料多，功能全面且稳定，如果机器数量在几百台以内，不用太担心性能问题，另外，采用数据库分区、SSD硬盘、Proxy架构、Push采集模式都可以提高监控性能。

    4、Zabbix在服务器监控方面占绝对优势，可以满足90%以上的监控场景，但是应用层的监控似乎并不擅长，比如要监控线程池的状态、某个内部接口的执行时间等，这种通常都要做侵入式埋点。相反，新一代的监控系统Open-Falcon和Prometheus在这一点做得很好。

    5、从整体表现上来看，新一代监控系统也有明显的优势，比如：灵活的数据模型、更成熟的时序数据库、强大的告警功能，如果之前对zabbix这种传统监控没有技术积累，建议使用Open-Falcon或者Prometheus.

    6、Open-Falcon的核心优势在于数据分片功能，能支撑更多的机器和监控项；Prometheus则是容器监控方面的标配，有Google和k8s加持。

    7、Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美观且强大的可视化体验，可以和Grafana进行组合。

    8、用合适的监控系统解决相应的问题即可，可以多套监控同时使用，这种在企业初期很常见。

    9、到中后期，随着机器数据增加和个性化需求增多（比如希望统一监控平台、打通公司的CMDB和组织架构关系），往往需要二次开发或者通过监控系统提供的API做集成，从这点来看，Open-Falcon或者Prometheus更合适。

    10、如果非要自研，可以多研究下主流监控系统的架构方案，借鉴它们的优势。
    `

    回复

  13. 快狗打车CTO沈剑：低成本搞定分布式调用链追踪系统（附PPT）
    https://mp.weixin.qq.com/s/2odEP5xHjTe_qmPs1DryIA
    `
    一、有微服务之前，我们架构是怎样的？

    二、微服务架构后，我们的痛点是什么？
    痛点一：定位线上故障的过程
    痛点二：定位性能瓶颈的过程
    痛点三：不合理调用导致扩缩容的过程

    三、分布式调用链追踪系统的特点
    解决方案是分布式调用链追踪系统，它能够解决上述的问题。分布式调用链追踪系统，它是什么？其实在解释它解决问题的过程中，基本上就能够知道它是做什么的。

    1、全链路
    2、跨进程
    3、全流量

    四、分布式调用链追踪系统的难点

    1、难点
    微服务它的难点也是因为它全流量跨进程，包括全球量化进程、全链路，所以对如何跨进程的去标识它是同一个HTTP请求过来的，跨进程的串联标识，跨进程的时序标识是个问题。上面说的单节点，用本地时间就可以做偏序，但是由于微服务它跨进程，可能另一台机器的本地时间比我这台机器的本地时间要快或者是要慢，如果用本地时间的话，可能就不能够描述全链路的请求的一个持续了。

    包括深度标识。深度标识有时候是第1个模块调第2个模块，第2个模块调第3个模块，它是深度的，与第1个模块先调第2个模块，然后第1个模块再调第2个模块，你会发现它的日志，时序可能是一样的，但是它的调用深度完全不一样。A调B，A再调C，与A调B，B调C，它可能对在日志层面都是 A和C分别被调了一次。

    深度广度如何来做？包括数据的收集和可视化。我们要精确到任何一个请求，要怎么来收集，怎么样在后端可视化，让大家看到在追踪Bug的过程中所需要掌握的信息。

    哪些信息需要要掌握呢？比如参数信息，调用的接口，数据库执行的是哪一个SQL语句，访问缓存的Key是什么？这些信息都可能是大家在追抓、追踪Bug的过程中非常重要的一些信息。能不能在后台统一的展现出来哪一个服务调到哪一个函数，参数是什么，缓存Key是什么，数据库SQL是什么，这些对于我们定位问题都非常有帮助。

    最后我还标红了一点，叫做如何低成本的去实现这个事情。首先到家集团、快狗大车，是创业型公司，14、15年才成立的，到现在，快速打车也就100来人，公司不会给我们一个20人的团队，研发半年的时间，去做出来一个系统。没有这样的资源，没有这样的成本，所以对于创业型公司来说，如何低成本去实现分布式的调用链追踪系统，解决上述难题，也是创业公司非常关注的。

    五、分布式调用链追踪系统的最佳实践

    1、统一框架
    2、统一组件
    3、统一配置管理（设计服务发现，自动扩容）
    4、分布式调用链追踪系统的核心难点
    前面说的分布式调用链的一个核心难点，如何跨进程的串联请求，如何跨进程的标识调用时序，如何跨进程的标识调用深度，只要你做到了前面我们说的统一组件，统一框架，其实这个事情是相对比较容易做的，因为如果你统一框架的话，你的内部RPC的协议你是自己可以控制的。你在自有的协议里要增加三个字段：

    第一个字段是【请求的ID】，来做全链路的请求标识；
    第二个字段是【时序的ID】，来做全链路的时序的标识；
    第三个字段是【深度的ID】，来做调用链的深度调用数是广度还是深度的一个标识。

    但是前提是上文所述协议是可控了，如果用的是Dubbo，而Dubbo不只是这样的功能，则可能要去做二开，我们的整个站点和服务都是自研的，所以加相关的字段相对比较容易。

    5、分布式调用链追踪系统的数据收集
    第一种UDP上报，每一个要收集数据的点，签一个UDP的SDK，然后往UDP 的Server去发数据。在机房内网 UDP的可靠性还是不错的，而且性能是比较高的。然后UDP收集到日志数据之后，再往日志中心或者叫搜索中心去做二次同步，然后后台要做检索，可以把它存到ES里，然后用这个调用链追踪后台，调相关的服务去做数据可视化；
    收集数据的第二种方式，对原有的架构体系的冲击会比较小，也是有一个SDK，嵌入到我们的框架，我们的组件的某些需要收日志的地方，先打本地日志，先落盘，然后通过一个异步的，将日志再同步到我们的调用链追踪系统的后台系统里面。如果要支持检索的话，落到到ES里，后台来查询。这个数据的收集无非是这两种方式，我们用的是这种方式，先打本地日志，对性能的影响也会比较小。

    6、分布式调用链追踪系统的可视化
    `

    回复

  14. 分布式链路追踪在字节跳动的实践
    https://mp.weixin.qq.com/s/a0Pm26-8toNKz0brrRVG4Q
    `
    什么是分布式链路追踪(Trace) ？

    # M T L 的关系
    可观测性的三大基础数据是 Metrics / Log / Trace。说到这三大件，可能大家会想到当需要监控变化趋势和配置告警时就去用 Metrics；当需要细查问题时去查 log；对于微服务数量较多的系统，还得有 Trace，Trace 也可以看做一种标准结构化的 log，记录了很多固定字段，例如上下游调用关系和耗时，查看上下游调用关系或者请求耗时在链路各节点上的分布可以查看 Trace。

    但是如果带着孤立的观点去用这些数据的话，数据的价值会大大降低。举例一个常见的场景，通过 Metrics 得知某服务 SLA 降低，错误率上升，怎么去排查根因呢？先去找错误日志吧，可是我看到的错误日志是不是真的和这个错误率上升有关系呢？得翻翻代码看看这些错误日志都是哪里打出来的，代表什么意思。再去找找有没有错误 Trace？找出来的 Trace 也不太确定是不是和这个错误率上升有关系，还是得看代码确认下。终于通过一行行的代码和数据比对，确认到这个错误是下一层服务返回给我的，把那个服务的负责人拉进来一起排查吧，然后这个群越拉越大，更多的人被拖进来一层一层地查下去，最终定位到是某个底层服务上线了一个变更导致 Panic，错误层层向上传播导致服务 SLA 降低。

    这个过程很不美好，需要工程师理解每一项数据的底层逻辑，才能充分利用它们去解决具体问题。而在复杂的大规模微服务系统中，没有单个工程师能够做到熟悉每一个微服务的底层逻辑，因此复杂微服务系统的排障和观测往往是一项有挑战的困难工作。

    # Trace 是数据的链接纽带
    Trace 不仅仅是用来查看耗时分布甘特图的工具，也是海量监控数据的 Context 链接纽带。基于可靠关联的 Metric / Trace / Log 数据，也构建出强大的可观测性能力，回答监控排障、SLO 调优、架构梳理、流量估算、智能化故障归因等众多复杂问题。

    字节链路追踪系统的挑战与机遇

    我们面临的挑战包括：
    * 线上流量巨大
    * 微服务数量巨大，调用关系复杂，迭代变化快
    * 研发团队庞大，分工复杂

    同时我们也有着难得的机遇：
    * 微服务框架高度统一
    * 微服务高度容器化，环境统一
    * 存储/中间件等基础设施高度统一
    `

    回复

  15. [课件+回放]《护航数据·安全未来》议题3：《基于全链路的数据隐私治理》
    https://bbs.pediy.com/thread-273109.htm
    https://vipread.com/library/topic/3758
    `
    01. 背景

    * 数字经济蓬勃发展，全球已经进入“数字经济”时代
    数据成为新型生产要素
    加快数字化发展，建设数字中国
    国家安全战略层级

    * 数据应用场景在爆发，数据对象保护范畴在变大
    数据类型变得愈发丰富
    数据应用场景更加广泛
    数据流通共享更加频繁

    * 企业面临越来越严峻的数据隐私风险挑战

    * 全球范围内，数据隐私监管态势不断趋严

    * 以3部上位法为核心，我国形成3+N数据隐私监管体系

    02. 思考

    * 数据隐私治理是首要任务，也是重要底盘支撑
    有什么->在哪里->谁在用->怎么用

    * 然而实际情况却并不乐观
    资产信息不全+数据流转不明+使用情况不清+存放地点不明

    * 数据隐私治理要达成的目标
    有哪些数据？ 数据在哪里？ 数据如何使用？ 谁在使用？

    03. 方案

    步骤一：基于业务上下游动态绘制数据流转地图
    步骤二：数据分类分级
    步骤三：业务伴随式数据库资产自动梳理
    步骤三：应用资产梳理，全面掌握数据流转载体资产信息
    步骤三：用户资产信息梳理

    资产信息多维度动态展示
    资产信息可持续动态运营

    数据发现 + 数据流转地图 + 分类分级 + 资产管理

    数据隐私治理的价值在于其结果被充分运用

    04. 价值

    全链路全域覆盖，不受复杂架构制约
    全类型数据识别，消除资产管理黑洞
    治理价值可应用，合规安全双向支撑
    `

    回复

  16. 可视化全链路日志追踪
    https://mp.weixin.qq.com/s/Er4-X8q5MKZZUgAUHyeLwA
    `
    可观测性作为系统高可用的重要保障，已经成为系统建设中不可或缺的一环。然而随着业务逻辑的日益复杂，传统的ELK方案在日志搜集、筛选和分析等方面愈加耗时耗力，而分布式会话跟踪方案虽然基于追踪能力完善了日志的串联，但更聚焦于调用链路，也难以直接应用于高效的业务追踪。

    本文介绍了可视化全链路日志追踪的新方案，它以业务链路为载体，通过有效组织业务每次执行的日志，实现了执行现场的可视化还原，支持问题的高效定位。

    * 1. 背景
    * 1.1 业务系统日益复杂
    随着互联网产品的快速发展，不断变化的商业环境和用户诉求带来了纷繁复杂的业务需求。业务系统需要支撑的业务场景越来越广、涵盖的业务逻辑越来越多，系统的复杂度也跟着快速提升。与此同时，由于微服务架构的演进，业务逻辑的实现往往需要依赖多个服务间的共同协作。总而言之，业务系统的日益复杂已经成为一种常态。

    * 1.2 业务追踪面临挑战
    业务系统往往面临着多样的日常客诉和突发问题，“业务追踪”就成为了关键的应对手段。业务追踪可以看做一次业务执行的现场还原过程，通过执行中的各种记录还原出原始现场，可用于业务逻辑执行情况的分析和问题的定位，是整个系统建设中重要的一环。

    传统的ELK方案需要开发者在编写代码时尽可能全地打印日志，再通过关键字段从ES中搜集筛选出与业务逻辑相关的日志数据，进而拼凑出业务执行的现场信息。然而该方案存在如下的痛点：

    * 日志搜集繁琐：虽然ES提供了日志检索的能力，但是日志数据往往是缺乏结构性的文本段，很难快速完整地搜集到全部相关的日志。
    * 日志筛选困难：不同业务场景、业务逻辑之间存在重叠，重叠逻辑打印的业务日志可能相互干扰，难以从中筛选出正确的关联日志。
    * 日志分析耗时：搜集到的日志只是一条条离散的数据，只能阅读代码，再结合逻辑，由人工对日志进行串联分析，尽可能地还原出现场。

    综上所述，随着业务逻辑和系统复杂度的攀升，传统的ELK方案在日志搜集、日志筛选和日志分析方面愈加的耗时耗力，很难快速实现对业务的追踪。

    分布式会话跟踪的主要作用是分析分布式系统的调用行为，并不能很好地应用于业务逻辑的追踪。
    (1) 无法同时追踪多条调用链路
    (2) 无法准确描述业务逻辑的全景
    (3) 无法聚焦于当前业务系统的逻辑执行

    * 2. 可视化全链路日志追踪
    * 2.1 设计思路

    问题1：如何高效组织业务日志？
    为了实现高效的业务追踪，首先需要准确完整地描述出业务逻辑，形成业务逻辑的全景图，而业务追踪其实就是通过执行时的日志数据，在全景图中还原出业务执行的现场。
    一次业务追踪就是逻辑链路的某一次执行情况的还原，逻辑链路完整准确地描述了业务逻辑全景，同时作为载体可以实现业务日志的高效组织。

    问题2：如何动态串联业务日志？
    业务逻辑执行时的日志数据原本是离散存储的，而此时需要实现的是，随着业务逻辑的执行动态串联各个逻辑节点的日志，进而还原出完整的业务逻辑执行现场。
    由于逻辑节点之间、逻辑节点内部往往通过MQ或者RPC等进行交互，新方案可以采用分布式会话跟踪提供的分布式参数透传能力实现业务日志的动态串联。

    * 2.2 通用方案
    * 3. 大众点评内容平台实践
    * 3.1 业务特点与挑战
    * 3.2 实践与成果

    目前，可视化全链路日志追踪系统已经成为点评内容平台的“问题排查工具”，我们可以将问题排查耗时从小时级降低到5分钟内；同时也是“测试辅助工具”，利用可视化的日志串联和展示，明显提升了RD自测、QA测试的效率。最后总结一下可视化全链路日志追踪的优点：
    * 接入成本低：DSL配置配合简单的日志上报改造，即可快速接入。
    * 追踪范围广：任意一条内容的所有逻辑链路，均可被追踪。
    * 使用效率高：管理后台支持链路和日志的可视化查询展示，简单快捷。

    * 4. 总结与展望
    持续深耕，实现覆盖告警、概况、排错和剖析等功能的可观测体系
    `

    回复

  17. 为什么你的大多数监控策略都失败了
    http://www.yunweipai.com/43193.html
    `
    未经验证的可观察性和随时待命的团队总会不可避免地遇到反应中断，而要想减少中断是很痛苦的，因为这就像蒙住双眼在大海捞针。我之所以知道这些，是因为我曾稳定了经历过混乱的团队。
    * 未检测到的降级导致用户感到痛苦。
    * 无休止的、海啸般的嘈杂警报。
    * 24 小时待命压力，难以承受，不可持续。
    这篇文章是针对那些因为一直救火而精疲力竭的工程师们，对想要将一项成熟技术加入到工具箱中的管理者来说，也有所帮助。毕竟有谁会不喜欢一支高效的团队呢？

    # 影响团队永久反应的四个原因

    脱节（Disconnect）：组织对用户体验的感知与实际用户体验之间存在鸿沟。感知与现实脱节的一些典型症状包括：
    * 尽管监控系统报告的状态为“健康”，但用户的投诉仍源源不断。
    * 缺乏主动的故障检测，只有在用户投诉时才能检测到中断。
    * 工程师试图解释页面如何影响用户。
    * 一位工程师意外地发现了残缺的功能。

    不信任（Distrust）：一个大的危险信号是对触发警报缺乏信心。监控系统发出的错误警报越多，工程师们就越不信任这个系统。不幸的是，这种低信噪比的状态加速了失修周期；工程师们厌倦了不断喊“狼来了”的监视器，直到不再关注这个问题。在这个阶段，你就应该拿着爆米花，等待不可避免的大规模中断。

    组织混乱（Disorganization）：没有特定的案例，给到的“建议方法”取决于你与谁合作。这种缺乏组织性和清晰指导的表现为监控框架激增、缺乏实战检验的工具以及临时中断补救措施。工程师们总是采取碰运气的解决方案，例如重启电脑，并希望“问题”消失）。

    失修（Disrepair）：工具、系统和警报已经失修。产生问题的原因各不相同，有的是服务处于维护模式，有的是由于损耗而缺乏专门知识，还有的则是半死不活的项目。

    # 监控策略是怎样令用户失望的
    监控的目标就是要保证用户的良好体验，主动把问题扼杀在摇篮里，或者能够迅速缓解没有捕捉到的问题。事实上，大部分方案都未能达到这个目标，原因并非是存在工具方面的差距，而是因为工具使用不当，这意味着并**没有理解核心问题出在哪里**。

    可观察性策略必须回答的关键问题就是：你的用户是否满意？要回答这个问题，就需要了解你的用户，知道什么能让他们满意。对这个问题的回答将渗透到可观测性栈中，并且会对连贯的操作实践产生影响。

    让用户满意的要素：
    * 产品团队，性能、可靠性、持久性。有关更多信息，请参见 No Surprises 文章。
    * 平台团队，不要止步于使用您服务的直接团队，还要尝试了解这些合作伙伴团队的用户。

    一些用户不满意的代理指标的要素：
    * 可靠性，由于内部系统错误而导致的故障和不可靠的结果（例如，错误对话框）。
    * 延迟性，操作花费的时间比预期的要长（例如，一个请求需要 10 秒钟而不是 2 秒钟）。
    * 可用性，不应向用户显示的内部错误（例如，隐晦的通用消息或对用户不友好的调试日志）。
    * 持久性，任务关键型系统中的数据丢失（例如，无法保存）。
    * 可用性，当需要处理请求时，系统不可用（例如，无法访问服务器）。

    # 为什么需要一个好的可观察性指标？

    以用户为中心的可观察性指标有两个目标：
    1. 指导完成目标。它们用户为改善服务提供了一个目标灯塔——帮助确定优先次序、跟踪修复工作，并将重点放在杠杆率最高的干预措施上。它们也可以被整合到组织实践中（如服务审查、事后检查等），以确保细微的偏差不会被忽视（如几周内健康趋势下降了 0.05%）。
    2. 主动警报。它们高度准确，可以提供回归的早期警报。健康指标的任何突然和持续下降都与真正的用户影响直接相关。在这些指标上设置警报将弥补生产上的可观察性差距。

    # 结束语
    大多数典型的监控策略都是“只见树木不见森林”——他们只关注资源或应用程序的健康状况，而忽略了最关键的问题：用户是否满意？
    希望你从这篇文章中学到一件事——那就是**确保你的监控策略与用户满意度直接挂钩**，即如果你的用户不能使用你的应用程序，那 10 个 9 就不重要。
    `
    Why most monitoring strategies fail
    https://abdulapopoola.com/2022/11/16/why-most-monitoring-strategies-fail/

    回复

  18. 在线评测基准（AIOps Live Benchmark）是在真实的IT系统上，通过混沌工程模拟真实的运维场景，通过可观测工具获实时数据，在线评测AIOps应用，最终提供权威的评测基准和真实数据。
    https://www.aiops.cn/model/
    `
    日志异常检测模型
    多指标时间序列异常检测模型
    Trace模型
    多模态模型
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注