trace的产率说明
发布网友
发布时间：2023-03-06 19:08
共2个回答
热心网友
时间：2024-11-10 11:39
在智能运维的体系中，用来分析和建模的数据可以笼统的分为：Log + Trace + Metric，这里面的数据量是巨大的，且数据形态是复杂多样，对于企业来说，不仅仅要考虑存储系统的吞吐、以及架构在存储系统之上计算引擎的灵活性，同时也会很关注成本。
基于Trace我们可以做些什么？
业务场景
拓扑生成
架构梳理
各服务的流量估算
系统的热点分析
链路的性能分析
错误的传播分析
发布过程中，流量的灰度分析，发布质量的评估
各家根因分析系统（系统+算法）
EMonitor -> 基于Tracing和Metrics的诊断系统
该系统是来自阿里本地生活的故障诊断的分享，在特定场景中可以较好的解决如下问题：
哪些入口受到了影响？
受影响的入口的本地操作和远程操作的影响如何？
受影响的入口都抛出了哪些异常？
在该系统中，无法准确（无法直接根据数据给出，需要推断）的解决如下问题：
GC问题
容器问题
变更导致的问题
该诊断系统的上层出发点是源自于观测的核心SLO指标的抖动，去分析是哪些聚合维度的指标的异常导致了当前的扰动，从而定位到需要进一步诊断的下层入口，通过如此反复的确认，得到最终的定位信息。这里提供一张特定的图（来自知乎上的发表过的图）。
通过上述图中的描述，我们可以看到饿了么团队可以完成如下几个能力：
大量复杂的数据预处理，通过一定的手段将数据进行清洗后格式化（或者严格要求日志字段格式），较好的完成了Metrics、Logs、Trace的关联跳转；
开发了特定的计算策略（OLAP侧或者本地服务侧）支持扰动分析，提供出探寻的候选集；
在特定的业务场景中，支持多个服务模块之间的参数调用，得到较为完成的业务侧拓扑；
但是分析下来，里面必定特别多的定制化的操作和对于开发的严格日志结构的要求，且有较大的定制化开发需求，在云上快速拓展有一定的难度。
GMTA Explorer -> 基于Trace的监控和服务诊断
该系统是eBay建立并在企业中落地的诊断系统，这套系统可以解决eBay每天1500亿条Span数据，可以在一定程度上处理Trace数据中的断链和错链问题。这里最核心的概念在如下的图2中已经描述出来了，这里重新提取下：
BusinessFlow（业务流）：最终是由业务方（使用方）来确定的；
Path：同一个业务在一段时间内的请求所构成的一个链路，最终是有多条Trace的路径合并出来的（业务请求在微服务系统中流经的节点所构成的Path）
数据流图+算法设计
在上图中，我们可以看到最核心的是要通过Flink计算出单条Trace的Path，然后通过一定的手段（聚类等）实现业务流的生成（Business Flow）。在数据处理的环节有几个重要的手段进行数据的处理：
根据特定业务输入，完成一些无效操作名称的替换；
根据标准的Trace定义，丢弃一些错误的数据，比如：根节点缺失、多个根节点等；
同时要尽可能关联一些错误日志数据，叫做错误传播链（EP Chains, Error Propagation Trace）；
下图较为清晰的描述了几个核心概念之间的关系。
这里我们可以简单说下，产生最终业务流的依赖的数据。根据文中的数据来说，在图数据存储中，时刻更新着当前系统中操作粒度的调用关系图，在分析型存储中按照一定的需求，存储着Path信息和业务流信息。
通过文中这个图，我们可以基本知道分析型存储中的基本结构，其中对于后续分析问题较为重要的两个核心属性是：PathID和BusinessFlowName，其中重中之重的属性值是PathID。那么，我们查看下原文中对于PathID的生成部分的描述。这里我们就要查看下文中的一个SpanHash的策略了。
span
+ serviceName
+ operationName
+ level
+ ration
+ statusCode
+ labels
+ childSpans[]
Algorithm 1 SpanHash(span)
+ hash = HashCode(span.serviceName) + HashCode(span.operationName) + span.level * PrimeNumber
+ for each child in span.childSpans do
+ hash += SpanHash(child)
+ end for
+ return hash
这里面一个比较核心的问题在于：如何在海量的Trace数据中，以较小的成本去解决单个span在Trace链路中的level和childSpans的问题？（这个问题本质上将是：底层的存储和计算引擎的选型和问题，文中提到，在eBay中使用的是Neo4j+Druid+Flink进行存储和计算）
还有一点值得称赞的是，该平台的完整度问题，在GMTA Explorer中，提供了很多基础能力，我们一起来看下。
基于上述能力，可以解决不同场景的业务问题
作为开发人员，可视化业务流程中服务的依赖关系和依赖项，以确定服务的更改影响。
作为架构师，学习与关键业务（例如支付）相关的路径和指标，以支持架构决策。
作为 SRE，确认服务行为的变化或模式，并评估业务变化或其他因素对流量、延迟和错误率等指标的影响。
这里就提供下文中的实验例子，由于接口变更导致的服务指标的变化。
可以较为清晰的看到，上部分表达的是某个业务流中有三个核心链路，下面部分表示的是链路归并后的效果，我们可以很清晰的看到，在userCheckout这个链路中calculateMoney的调用接口由"coupon" -> "couponV2"后，可以较清楚的看到，对于createOrder来说，调用量上升了20%，延迟降低了5%。
在工程实践上的一些取舍
在后端存储和计算的选型上，不额外的造轮子，选择现有的大数据组件，且经过一些中间层粘合起来使用
对于如此大的数据规模，在实际中，也会进行一定的采样（文中提到了1%的采样率写入到Kafka中）
对于trace中数据的迟到和完整度的问题，采用Flink去解决
对于Flink消费之后的结果，一部分写入到Druid中，一部分直接提取后写入到neo4j中
在通过一些UI可视化组件解决后续的交互式分析问题
几点思考
这偏文章读下来更多的是偏向介绍数据在系统中的流转，并非过多的在介绍算法本身（单纯的看算法部分缺失不复杂），落地起来较为可行；
在PathID生成中，过分依赖Flink的State能力，并没有设计或优化下高效的生成PathID的策略，这里还需要进一步的提升；
在文末提到，对数据进行Trace数据的1%的采样，并没有透露出具体的采样策略，因为采样策略对数据质量和数据覆盖度有较为严重的影响；
文中提出了Business Flow的概念，这个让我眼前一样，继续探索下，如何能进一步自动生成BusinessFlow的策略，可以通过一个UI让用户可以来管理自己的业务就是很大的进步了；
根因诊断的下一步思考
算法侧需求
Trace场景的数据相对来说较为确定且具体，其中面临的问题也是确定的，这里更多的是是考虑如何在端上可以灵活的按需去采样，去解决后端的存储成本的问题，对于算法侧来说复杂度不是很高；
在解决Trace数据后，如何将Metric和Alarm整合在一起，去自动化的做因果分析，这个还是复杂一些的；
是否可以在以一步的让AI去学习我们的业务代码，能否将根因结果自动的和代码提交进行诊断，进一步定位到具体的更改（微软等已经在做了一些尝试）
下一步更多的需要去考虑多元数据的融合问题，能否在云上提供类似APM中的完整能力，做到简单、易用；
现阶段对于平台来说，要解决好信息抽取后的表达和管理工作，为后续的自动化分析和诊断扫清 障碍；
热心网友
时间：2024-11-10 11:40
加减号或者trace报告就是说明你的尿里有蛋白比减号的时候要多一点，但是还不足以达到一个加号的水平。所以尿蛋白trace，就是说尿里有少量的蛋白。
