庐山网站建设,大数据营销工具,淘宝官方网站登录注册,辽宁建设工程信息网新域名要解决的问题 如何记录请求经过多个分布式服务的信息#xff0c;以便分析问题所在#xff1f;如何保证这些信息得到完整的追踪#xff1f;如何尽可能不影响服务性能#xff1f; 追踪 当用户请求到达前端A#xff0c;将会发送rpc请求给中间层B、C#xff1b;B可以立刻作…要解决的问题 如何记录请求经过多个分布式服务的信息以便分析问题所在如何保证这些信息得到完整的追踪如何尽可能不影响服务性能 追踪 当用户请求到达前端A将会发送rpc请求给中间层B、CB可以立刻作出反应但是C需要后端服务D、E的配合才能应答 一个简单有用的请求追踪应该包含发送、接收消息的消息标识符、时间戳。为了关联给定发起者的这些记录在此有黑盒和基于标注的监控模式 黑盒假定并没有除了以上记录之外的额外信息使用统计回归进行推断关联性。 更加轻量化但是需要更多数据以保证准确性 基于标注基于应用或者中间件去显式采用全局标识符标注这些记录从而关联。 需要代码侵入但可以将之植入到通用组件中 追踪信息 span: 链路追踪的基本单元以追踪树结构串联起来。trace id: 对于每一个请求链路上的span都有唯一的trace id 度量点 当一个线程处理追踪控制路径时dapper附加追踪上下文到本地线程储存中当异步处理时dapper保证异步回调将会储存追踪上下文到创建者并且当回调调用时将会关联到适当的线程植入到rpc通信中 采样收集 写入span数据到本地log文件dapper拉取各主机数据最终写入到dapper bigtable bigtable中每个trace置于表行每个span置于表列 收集模式 Dapper采用out-of-band进行追踪收集主要因为 in-band收集模式追踪数据在rpc响应头中会动态影响应用网络in-band收集模式假定rpc调用完美嵌套的 in-band: 将追踪数据随着调用链进行传送 out-of-band: 通过其他链路进行追踪 收集方式 基于日志也即将trace、span等信息直接输出到应用日志中而后汇集所有节点日志最后推断出完整调用关系 对网络消息没有侵入对应用也只有少量侵入但日志本身并不追求绝对连续与一致性这意味着追踪结果可能并不准确 基于服务通过某些手段给目标应用注入追踪探针。探针在结构上可视为一个寄生在目标服务身上的小型微服务系统它一般会有自己专用的服务注册、心跳检测等功能有专门的数据收集协议把从目标系统中监控得到的服务调用信息通过另一次独立的 HTTP 或者 RPC 请求发送给追踪系统。 因此基于服务的追踪会比基于日志的追踪消耗更多的资源也有更强的侵入性换来的收益是追踪的精确性与稳定性都有所保证不必再依靠日志归集来传输追踪数据。 基于边车代理用于服务网格应用透明、语言无关、独立通道 性能损耗如何降低 追踪系统的成本可分为追踪数据生成追踪数据收集以及追踪数据分析组成。而收集和分析在紧急的时候是可以关闭的因此追踪生成就成了最关键的损耗 而追踪生成的损耗最关键的则是运行时库创建和销毁span以及annotation和写入log到硬盘中 写入硬盘合并了多个日志文件写入操作并异步进行有效地减少了由于写入log到硬盘造成的性能损耗 此外dapper还发现 从图中可以看到随着采样频率的降低延时和吞吐量都有性能上的提升。尤其是1/1024的频率下对吞吐量的影响只有万分之六而对延时的影响也只有千分之二。 这意味着是不是可以降低采样频率来降低对性能的影响呢事实上是可以的即使是降低到1/1024对于大型系统而言仍然有足够的数据进行追踪。 除了对于延时、吞吐量的影响对于数据储存规模的影响dapper也做了相应控制。 其使用二阶采样控制数据量大小。通过将traceID hash为0到1之间的度量z若z小于采用参数则将采样该数据写入到bigtable中 总结 如何记录请求经过多个分布式服务的信息以便分析问题所在 从上文可知通过引入span和trace分别从被追踪者和请求链路两个维度推断追踪树从而用于分析问题 如何保证这些信息得到完整的追踪 只要采样的绝对数量够大那么就比较好追踪。对于分布式的情况通过span组织的逻辑链路来达成对于异步关联到相关的线程 如何尽可能不影响服务性能 分析收集可以通过动态的开关来保证紧急情况下的性能稳定而追踪主要是通过尽量减少采样保证的 Ref https://storage.googleapis.com/pub-tools-public-publication-data/pdf/36356.pdfhttp://icyfenix.cn/distribution/observability/tracing.html