Trace链异常检测汇总

        微服务应用与单块应用完全不同，一个微服务系统少则有几十个微服务组成，多则可能有上百个服务。比如BAT级别的互联网公司，一般都超过上百个服务，服务之间的依赖关系错综复杂，如果没有有效的监控手段，那么出现问题很难快速排查，最终会导致业务损失。在微服务监控领域，当分布式系统发生故障时，由于服务之间复杂且动态的互相依赖关系，诊断与定位故障根因往往是非常困难的, 调用链监控是比较有效的手段，它不仅可以实时监控服务调用性能，也可以实时跟踪服务的依赖关系，出现问题的时候，通过调用链监控，可以帮助我们快速定位问题和排障，可以说微服务离不开调用链监控。

假设有3个服务，service1, service2, service3. 他们之间是有调用关系的。当外部请求进来的时候：用户请求先到service1, service1调用redis缓存（红色小方块），redis返回service1数据。service1调用service2，service2调用mysql，mysql返回service2数据。service2调用service3, service3返回给service2service2返回给service1service1返回给用户。

架构知识

微服务系统一般采用K8S（Kubernetes）微服务架构，在这个架构下，与trace链相关的概念有三个：pod，node，service，通常做trace链异常定位时，需要知道是pod级别还是node级别或者service级别的故障，并且需要知道对应的编号（如node-1）。

Kubernetes创建了一个Pod来放置你的应用实例，pod是Kubernetes上最小部署单元。Pod是Kubernetes中的一个抽象概念，一个Pod包含了一组应用容器（比如Docker或者rkt）和这些容器共用的资源。pod模拟出了一个应用运行所需要的“逻辑主机”；一个Pod总是运行在一个Node上。在Kubernetes中一个Node是一个执行具体工作的机器，它可用是虚拟机也可用是物理机，这个取决于所在的集群。每个Node都由Master统一管理。每个Node上面可用有多个Pod，Kubernetes Master会自动在Node之间处理调度相关的处理。Master自动调度会记录每个Node上的可用资源。

按故障粒度来分的话，service最粗糙，node次之，pod最细粒度，node可以理解成一个物理虚拟机，pod可以理解成一个虚拟机上的容器（如docker这种），每个service可以调用不同虚拟机上的容器服务（一个service包含3-4个pod），但是这个3-4pod不一定部署在一台虚拟机上（分布式系统的特点，能最大程度利用资源）。

trace链实现异常检测与根因定位

Trace链做异常检测时，是以每条trace链作为研究对象或一个样本，由于trace调用结构有差异性，所以需要先要确定trace的常用标准模式，然后在常用标准模式下构建模型训练集去判断是否异常；判断完一条trace链异常之后需要做根因定位，根因定位的研究对象是trace链上的每一个节点（span、service等视数据粒度而定），一般定位结果[cmdb_id, fault_type, prob, topk]，其中cmdb_id可以理解为是哪个级别（pod、node、service）的故障，fault_type(结合metic指标，如容器类故障、磁盘故障等)，prob指故障概率，topk是指出现故障的前K个节点，这个取K不一定根据异常分数，也需要考虑调用顺序。

trace链构建算法输入

Trace链中一个样本可以是一个trace也可以是一个span，当样本为一个trace时，特征一般为trace下子节点（span、operation等）的时延、日志、状态码信息，当以span作为子节点时，每条trace的节点长度不一致（除非采取类似于词向量embedding的方式编码成等长的向量），导致模型输入特征长度不一致，需要构建多个trace异常检测模型对trace链进行异常检测，由于实际数据中的标签缺乏，通常问题会定义为无监督、半监督的问题。一般来说，适用span作为一个样本时，主要是用来做根因检测，由于trace链数据频率高且多，所以做根因定位时不应用较为复杂的方法，通常会对每个trace模式下的span进行统计上异常判断。

1）对每一个trace_id进行LOUDS编码（30年前，现在有surf），LOUDS利用每个trace下的服务（span_id、operation）进行编码形成调用树，调用树表示调用结构，可以还原调用关系，除此之外会对trace_id和operation进行重新编码、去重，对每一个operation，存储其时延信息。

2）在训练集上分别统计normal和fault的trace调用模式，筛选调用次数多（>5000次）的作为调用的关键模式，目的为了提高搜索匹配效率

3）实时检测时，对一定时间间隔内（5分钟内）的调用信息中的每一个trace先进行编码，与调用模式库进行匹配（只匹配标准模式），对于标准模式匹配上的调用树，导出对应trace模式下的训练集，先进行无监督或半监督的异常检测，判断待检测trace链是否异常。如若异常，则对trace链从上至下进行时延6_sigma进行异常检测，超出6sigma的视为异常，同时统计历史样本中该服务的次数与异常次数，将其比值作为后验概率，加入trace链异常检测理论上能搞提高检测效率，因为新来一条trace不一定都要做根因分析。