方案1：基于skywalking的链路追踪与日志收集方案
概述
SkyWalking: 一个开源的可观测平台, 用于从服务和云原生基础设施收集, 分析, 聚合及可视化数据。SkyWalking 提供了一种简便的方式来清晰地观测分布式系统, 甚至横跨多个云平台。SkyWalking 更是一个现代化的应用程序性能监控(Application Performance Monitoring)系统, 尤其专为云原生、基于容器的分布式系统设计。
SkyWalking 逻辑上分为四部分: 探针, 平台后端, 存储和用户界面。
image.png
skywalking能为我们做什么
- 链路追踪: skywalking的核心功能是链路追踪，使用java-agent探针采集数据，通过grpc协议传输数据到平台后端(OAP)，存储数据到h2或elasticSearch，最后在skywalking-ui界面查看与分析；
- 日志收集: skywalking能够实现简单的日志收集。通过logback grpc appender将日志发送到平台后端(OAP)，存储到elasticSearch。通过skywalking-ui查看链路时可以查看对应链路的日志，也可以通过kibana直接检索日志索引；
- 其他指标收集: jvm指标收集等额外功能；
- 告警: 支持配置告警指标。
整体架构
image.png
方案优缺点
优点
- 使用skywalking实现了链路追踪；
- 日志收集过程无需引入ELK中的filebeat、logstash等组件，在链路追踪过程中顺带实现了日志收集；
- 链路数据与日志数据均使用skywalking的grpc轻量级rpc协议实现。
缺点
- 关于skywalking
- 虽然skywalking号称对代码零侵入，但这只是针对其java agent。要实现 日志写入traceId、日志上报、链路数据子线程传递 等功能，仍需要在程序中添加配置或代码；
- skywalking使用grpc实时上报数据，没有消息队列缓冲。官方解释这不是缺点，是设计: 链路数据可以容忍丢失，可以通过降低采样率解决数据堆积问题；
- 对比广泛使用的springcloud sleuth + zipkin方案，skywalking的确功能更丰富，至少UI上已经丰富多了，支持直接查看链路日志，还有一些告警、jvm指标收集等额外功能。但springcloud支持消息队列缓冲。
- 日志收集
- skywalking主要为链路追踪服务，所以，链路以外的日志不会上报: 如程序启动日志、没有特殊处理的子线程日志等;
- skywalking的日志上报模块较为简单，所有日志均收集到一个按日期滚动的索引，没有办法（我没找到）实现根据不同应用区分索引的需求；
- 关于日志归档: logstash包含以elasticsearch输入、s3输出的插件。但引入了logstash，为啥不直接用ELK呢？
方案2：基于ELK的日志收集与skywalking的链路追踪方案
概述
ELK: ElasticStack提供的一套被广泛使用的日志收集与分析套件。是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。Elasticsearch 是一个搜索和分析引擎。Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。
image.png
skywalking: 介绍见前文。
整体架构
image.png
方案优缺点
优点
- 使用filebeat采集本地日志，日志采集过程程序无感知，并且能采集到所有日志；
- 使用logstash做为中转环节，可以通过gork脚本等方式，对日志做精细控制: 例如不同应用收集到不同索引、info与error日志收集到不同索引等；
- logstash可以配置多个output，同时输出到elasticsearch与s3，实现日志查询与归档需求；
- 链路追踪仍使用skywalking实现。
缺点
- 方案较复杂，引入组件较多；
- 如果想在skywalking-ui直接查看链路日志，elasticsearch上将会存在两份日志: logstash和skywalking-agent分别上报了一份，这样会造成存储资源的浪费。当然，可以通过牺牲一定的便利性，节省存储资源: 关闭skywalking的日志上报，链路日志通过traceId到kibana上查找。
