背景
全链路日志监控在现在盛行的微服务和分布式环境下，能有效地提高问题定位分析效率，成为开发和运维利器。当前已有开源解决方案和成熟的厂商提供。
比如Twitter的zipkin基于Google的Dapper论文设计开发了分布式跟踪系统，用于采集各处理节点间的日志和耗时信息，帮助用户排查请求链路的异常环节。
在有统一RPC中间件框架的业务部门容易接入zipkin。但织云全链路日志监控平台（后成全链路）面对的实际业务场景更为复杂，全链路日志监控实现遇到更多的挑战，全链路技术选型经历了从开源组件到自研的变化。
使用场景
归纳全链路日志监控的使用场景主要有三大类：
一是个例分析，主要有处理用户投诉和从面到点的异常分析；
二是开发调试，主要用于开发过程中查看关联模块的日志和作为测试提单线索；
三是监控告警，主要是从日志数据中提取维度，统计为多维数据用于异常检测和原因分析。
Case分析
分布式系统越做越大，服服务化规模也越来越复杂，为了减轻运维压力、提高排错能力，分布式系统的全链路监控系统就显得尤为重要了。监控系统通常会包括几个部分：
第一， 数据埋点和采集 ，这个相当重要，其实说白了，数据是整个监控系统最核心的部分，必须有能力快速和正确和方便地采集日志，所以我们在数据埋点和采集上做了很多文章。
第二， 指标计算 。指标计算有好几种方式，一种我可以在客户端做一些计算，通过 agent 上报计算结果，然后到服务端再做加工。还有一种策略是完全在服务端的计算，客户端只做简单的数据采集，所有的指标计算全放在服务端。这二种架构其实都有不同的优缺点。
第三， 指标存储、查询、展现 ，这个也非常重要。算完后的指标放在哪里，这些指标怎么样快速的查询出来，指标怎么样很灵活的展现给我们的运营人员、开发人员。
第四， 调用链的存储、查询、展现 。因为我们是全链路监控系统，调用链怎么存、怎么查、怎么看，这个也是非常重要的。
第五， 告警、问题定位 ，因为你单纯只有查询远远不够，我们需要一个很快速很高效的告警，同时产生告警之后，我们需要很快速的去定位这个告警是什么原因导致的。
第六， 自监控 。我们的体系需要一个自监控的功能，假如我在大促的时候挂了，我需要很快的恢复我们的平台，自监控非常重要。
第七， 治理 。大促之前需要动态地调整日志采样率，或者对日志采集做一些功能降级，例如不采集缓存相关日志。
海量数据挑战
同时在线超2亿用户上报的状态数据，日存储量超10T，带宽超过30GB/s。需要稳定和高效的数据处理、高性能和低成本的数据存储服务。在使用开源组件完成原型开发后，逐渐遇到性能瓶颈和稳定性挑战，驱使我们通过自研逐渐替换开源组件。
本文将从分布式系统调用的复杂现状说起，具体分析调用链的三大使用场景，以及调用链的最佳实践，简述如何将调用链作为排查问题的核心，通过其可以将各类数据关联在一起，提高问题排查能力。
技术栈：Spark 、 Open TSDB 、HBase 、Elastic Search，Kafka，Flume，Python；日志监控框架（Logstash, ElasticSearch, kibana）具体参见：http://www.open-open.com/lib/view/open1470732672604.html
【参考文章】
1、开源or自研？腾讯全链路日志监控实践告诉你 https://www.sohu.com/a/204621202_262549
2、Dapper，大规模分布式系统的跟踪系统 http://bigbully.github.io/Dapper-translation/
3、开普勒鑫球全链路监控系统Talos正式开源 - 简书 https://www.jianshu.com/p/576a8ee06dd6
4、知名的开源apm(Application Performance Management)工具https://blog.csdn.net/konglongaa/article/details/55807192
5、全链路压测平台（Quake）在美团中的实践https://mp.weixin.qq.com/s/7kKhAYtkIuvlBnZlaYATnw
6、3.架构篇 - Tracing - 鹰眼系统 - 简书 https://www.jianshu.com/p/a125bea43abe