ELK方案
目的
为面对各种日常客诉和突发问题，便于业务追踪。
业务追踪的主流实现方式：
1、基于日志的ELK方案
2、基于单次请求调用的会话跟踪方案(单机服务 不适用与当下业务系统)
传统的ELK方案
ELK 技术栈已经成为日志收集和分析的通用解决方案。伴随着业务逻辑的执行，业务日志会被打印，统一收集并存储至ES。此方案需要开发者在编写代码时尽可能全地打印日志，再通过关键字段从ES 中搜集筛选出与业务逻辑相关的日志数据.
缺点
(1) 日志搜集繁琐。日志数据通常为缺乏结构性的文本段。
(2) 日志筛选困难。没有办法进行精准定位
(3) 日志分析耗时。
分布式会话跟踪方案
是通过一个分布式全局唯一的 id（即 traceId），将分布在各个服务节点上的同一次请求串联起来，还原调用关系、追踪系统问题、分析调用数据、统计系统指标。
分布式会话跟踪的主要作用是分析分布式系统的调用行为，并不能很好地应用于业务逻辑的追踪。
缺点
(1) 无法同时追踪多条调用链路
(2) 无法准确描述业务逻辑的全景
(3) 无法聚焦于当前业务系统的逻辑执行
总结
传统的 ELK 方案是一种滞后的业务追踪，需要事后从大量离散的日志中搜集和筛选出需要的日志，并人工进行日志的串联分析，其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时，实时地完成了链路的动态串联，但由于是会话级别且仅关注于调用关系等问题，导致其无法很好地应用于业务追踪。
可视化全链路日志追踪
可视化全链路日志追踪考虑在前置阶段，即业务执行的同时实现业务日志的高效组织和动态串联，从而可以实现高效的业务追踪。首先需要准确完整地描述出业务逻辑，形成业务逻辑的全景图，而业务追踪其实就是通过执行时的日志数据，在全景图中还原出业务执行的现场。
新方案对业务逻辑进行了抽象，定义出业务逻辑链路。
逻辑节点：业务系统的众多逻辑可以按照业务功能进行拆分，形成一个个相互独立的业务逻辑单元。
逻辑链路：业务系统对外支撑着众多的业务场景，每个业务场景对应一个完整的业务流程，可以抽象为由逻辑节点组合而成的逻辑链路。一次业务追踪就是逻辑链路的某一次执行情况的还原，逻辑链路完整准确地描述了业务逻辑全景，同时作为载体可以实现业务日志的高效组织。
由于逻辑节点之间、逻辑节点内部往往通过 MQ 或者 RPC 等进行交互，新方案可以采用分布式会话跟踪提供的分布式参数透传能力 [5] 实现业务日志的动态串联：
● 通过在执行线程和网络通信中持续地透传参数，实现在业务逻辑执行的同时，不中断地传递链路和节点的标识，实现离散日志的染色。
● 基于标识，染色的离散日志会被动态串联至正在执行的节点，逐渐汇聚出完整的逻辑链路，最终实现业务执行现场的高效组织和可视化展示。
链路定义
使用特定语言，静态描述完整的逻辑链路，链路通常由多个逻辑节点，按照一定的业务规则组合而成，业务规则即各个逻辑节点之间存在的执行关系，包括串行、并行、条件分支。
DSL（Domain Specific Language）是为了解决某一类任务而专门设计的计算机语言，可以通过 JSON 或 XML 定义出一系列节点（逻辑节点）的组合关系（业务规则）。
通用方案是采用静态组织(链路定义)+动态串联(链路染色)+日志收集(链路上报)+现场存储(链路存储)
链路染色
在链路执行过程中，通过透传串联标识，明确具体是哪条链路在执行，执行到了哪个节点。
链路染色包括两个步骤：
(1) 确定串联标识，当逻辑链路开启时，确定唯一标识，能够明确后续待执行的链路和节点。
1》链路唯一标识 = 业务标识 + 场景标识 + 执行标识（三个标识共同决定“某个
业务场景下的某次执行”）
2》节点唯一标识 = 链路唯一标识 + 节点唯一名称（两个标识共同决定“某个业务场景下的某次执行中的某个逻辑节点”）
(2) 传递串联标识，当逻辑链路执行时，在分布式的完整链路中透传串联标识，动态串联链路中已执行的节点，实现链路的染色。
链路上报
在链路执行过程中，将日志以链路的组织形式进行上报，实现业务现场的准确保存。上报的日志数据包括：节点日志和业务日志。其中节点日志的作用是绘制链路中的已执行节点，记录了节点的开始、结束、输入、输出；业务日志的作用是展示链路节点具体业务逻辑的执行情况，记录了任何对业务逻辑起到解释作用的数据，包括与上下游交互的入参出参、复杂逻辑的中间变量、逻辑执行抛出的异常。
链路存储
将链路执行中上报的日志落地存储，并用于后续的“现场还原”。上报日志可以拆分为链路日志、节点日志和业务日志三类：
(1) 链路日志：链路单次执行中，从开始节点和结束节点的日志中提取的链路基本信息，包含链路类型、链路元信息、链路开始 / 结束时间等。
(2) 节点日志：链路单次执行中，已执行节点的基本信息，包含节点名称、节点状态、节点开始 / 结束时间等。
(3) 业务日志：链路单次执行中，已执行节点中的业务日志信息，包含日志级别、日志时间、日志数据等
案例
业务追踪建设，所需考虑的问题：
(1) 业务场景多
(2) 逻辑节点多
(3) 出发执行多
架构落地
点评内容平台是一个复杂的业务系统，对外支撑着众多的业务场景，通过对于业务场景的梳理和抽象，可以定义出实时接入、人工运营、任务导入、分发重算等多个业务逻辑链路。由于点评内容平台涉及众多的内部服务和下游依赖服务，每天支撑着大量的内容处理业务，伴随着业务的执行将生成大量的日志数据，与此同时链路上报还需要对众多的服务进行改造。
因此在通用的全链路日志追踪方案的基础上，点评内容平台进行了如下的具体实践。
(1) 支持大数据量日志的上报和存储。
(2) 实现众多后端服务的低成本改造。
TraceLogger 工具包的功能包括：
● 模仿 slf4j-api：工具包的实现在 slf4j 框架之上，并模仿 slf4j-api 对外提供相同的 API，因此使用方无学习成本。
● 屏蔽内部细节，内部封装一系列的链路日志上报逻辑，屏蔽染色等细节，降低使用方的开发成本。
○ 上报判断：
○ 判断链路标识：无标识时，进行兜底的日志上报，防止日志丢失。
○ 判断上报方式：有标识时，支持日志和 RPC 中转两种上报方式。
○ 日志组装：实现参数占位、异常堆栈输出等功能，并将相关数据组装为Trace 对象，便于进行统一的收集和处理。
○ 异常上报：通过 ErrorAPI 主动上报异常，兼容原日志上报中 ErrorAp�pender。节点日志上报：支持 API、AOP 两种上报方式，灵活且成本低。
○ 日志上报：适配 Log4j2 日志框架实现最终的日志上报
功能实现图
总结
随着分布式业务系统的日益复杂，可观测性对于业务系统的稳定运行也愈发重要 。内容平台落地了全链路的可观测建设，在日志（Logging）、指标（Metrics）和追踪（Tracing）的三个具体方向上都进行了一定的探索和建设。支持实时、多维度地展示业务系统的关键业务和技术指标，同时支持相应的告警和异常归因能力，实现了对业务系统整体运行状况的有效把控。
