全链路监控方案概述与比较.docxVIP

全链路监控方案概述与比较 基本工作单元，一次链路调用（可以是RPC，DB等没有特定的限制）创建一个span，通过一个64位ID标识它，uuid较为便利，span中还有其他的数据，例如描述信息，时间戳，key-value对的（Annotation）tag信息，parent_id等,其中parent-id可以表示span调用链路来源。 上图说明白span在一次大的跟踪过程中是什么样的。Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系。假如一个span没有父ID被称为root span。全部span都挂在一个特定的跟踪上，也共用一个跟踪id。 Span数据结构： type Span struct { ? ?TraceID ? ?int64 // 用于标示一次完整的恳求id ? ?Name ? ? ? string ? ?ID ? ? ? ? int64 // 当前这次调用span_id ? ?ParentID ? int64 // 上层服务的调用span_id ?最上层服务parent_id为null ? ?Annotation []Annotation // 用于标记的时间戳 ? ?Debug ? ? ?bool } 3.2 Trace 类似于?树结构的Span集合，表示一次完整的跟踪，从恳求到服务器开头，服务器前往response结束，跟踪每次rpc调用的耗时，存在独一标识trace_id。比如：你运转的分布式大数据存储一次Trace就由你的一次恳求组成。 每种颜色的note标注了一个span，一条链路通过TraceId独一标识，Span标识发起的恳求信息。树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简约的代表span的开头和结束时间，他们在整个树形结构中却是相对独立的。 3.3 Annotation 注解，用来记录恳求特定大事相关信息（例如时间），一个span中会有多个annotation注解描述。通常包含四个注解信息： (1)?cs：Client Start，表示客户端发起恳求 (2)?sr：Server Receive，表示服务端收到恳求 (3)?ss：Server Send，表示服务端完成处理，并将结果发送给客户端 (4)?cr：Client Received，表示客户端猎取到服务端前往信息 Annotation数据结构： type Annotation struct { ? ?Timestamp int64 ? ?Value ? ? string ? ?Host ? ? ?Endpoint ? ?Duration ?int32 } 3.4 调用示例 恳求调用示例 当用户发起一个恳求时，首先到达前端A服务，然后分别对B服务和C服务进行RPC调用； B服务处理完给A做出响应，但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务，最终由A服务来响应用户的恳求； 调用过程追踪 恳求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次恳求。 除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。 一个没有parent id的span成为root span，可以看成调用链入口。 全部这些ID可用全局独一的64位整数表示； 整个调用过程中每个恳求都要透传TraceID和SpanID。 每个服务将该次恳求附带的TraceID和附带的SpanID作为parent id记录下，并且将本人生成的SpanID也记录下。 要查看某次完整的调用则?只需依据TraceID查出全部调用记录，然后通过parent id和span id组织起整个调用父子关系。 调用链核心工作 调用链数据生成，对整个调用过程的全部应用进行埋点并输出日志。 调用链数据采集，对各个应用中的日志数据进行采集。 调用链数据存储及查询，对采集到的数据进行存储，由于日志数据量一般都很大，不只要能对其存储，还需要能供应快速查询。 目标运算、存储及查询，对采集到的日志数据进行各种目标运算，将运算结果保存起来。 告警功能，供应各种阀值警告功能。 全体部署架构 通过AGENT生成调用链日志。 通过logstash采集日志到kafka。 kafka担任供应数据给下游消费。 storm计算汇聚目标结果并落到es。 storm抽取trace数据并落到es，这是为了供应比较简单的查询。比如通过时间维度查询调用链，可以很快查询出全部符合的traceID，依据这些trac