共计 2607 个字符，预计需要花费 7 分钟才能阅读完成。
一、背景介绍
百度商业产品是服务于百度广告主用来投放广告而打造的产品生态。蕴含搜寻推广、信息流推广、品牌等推广渠道以及观星盘、基木鱼等营销工具。
百度商业产品全景图
这一系列商业产品底层多为简单的 Java 业务零碎。复杂性次要体现在底层微服务子系统多、利用间调用关系简单、根底组件依赖多。复杂性高就就意味着容易出问题，并且出了问题定位艰难。然而这些产品出问题会间接导致广告主是否胜利投放广告或者批改出价、创意等操作失败。
「如果有过在广告业务零碎一线工作经验的同学，应该深知排查线上问题的干燥和耗时」
如何在出问题第一工夫定位问题，从而疾速止损和修复问题，是商业产品零碎中一个要害的技术痛点。为了解决这个痛点，百度商业平台部打造了大规模散布式微服务监控零碎。公众号前文 「 百度商业大规模微服务业务监控零碎 - 凤睛 」 曾经讲述了凤睛如何通过自研无侵入探针以及高性能调用链存储系统为百度各业务线提供微服务零碎性能指标、业务黄金指标、健康状况、监控告警等。
当收到线上报警时，值班同学须要首先找到出问题的根因模块，而后找出该模块出错的服务接口，最初定位到问题代码行栈。凤睛提供了调用链数据可能查看各个调用环节的状态码、耗时等，同时也收录了业务零碎打印的谬误堆栈。
凤睛提供的调用链表格视图（红色箭头标识的是耗时长要害门路）
大部分状况下，通过调用链以及零碎打印的谬误堆栈能够确定问题。然而，局部状况下问题与用户申请返回、业务拜访缓存的状况等等比拟非凡的场景无关。这须要通过零碎打印的业务日志辅助定位。
凤睛并没有采集和存储业务日志，这与数据量无关，它部署在数千个微服务子系统上，运行在数万个容器中。每天采集的调用链数据条数达千亿，日存储数据在 TB 级别。而更加宏大、形象水平最低的业务日志，预估单日总量靠近 PB 级别，存储开销切实太大。
二、技术原理
传统做法：为了检索到单个申请相干的所有业务日志，日志会被采集走存储在 ES 外面提供检索性能。
日志采集架构
诚然，Kibana+ES 会提供更丰盛灵便的检索性能，然而对于凤睛这种平台级别监控零碎，根本不可行。ES 的资源老本过于低廉，整个平台单日日志数据靠近 PB。如果全副存储在 ES 中，那么集群资源耗费以及保护老本都是很高的。并且，单纯定位线上问题，并不需要特地简单的日志检索性能。
那么是否在大量资源耗费下，满足用户能够看到单个申请相干的残缺调用链以及业务日志呢？
凤睛整个迭代过程就是一直利用无限资源来创造性解决理论问题的过程。而真正好的零碎架构亦然如此，要「就地取材」。在阿里巴巴钟华同学的《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》一书中，开篇就提到过「好的翻新肯定是基于企业现状就地取材」。
目前商业平台 Java 零碎对立部署在企业级微服务托管平台 Jarvis 上，同时凤睛探针可能无侵入式跟踪和采集零碎的动作，这是咱们的技术劣势。是否利用这个劣势，来躲避掉存储资源无限的短板。探针既然可能记录零碎在每个申请产生过程中的所有的动作；那么同样能够记录零碎打印日志的动作。
全息日志技术思路示意图
咱们通过探针记录下申请相干的业务日志文件名、日志偏移量，并且存储数据库中。当用户在 Jarvis 治理端检索调用链相干的业务日志时，零碎会先通过调用链 ID 去获取相干的虚构容器地址、日志文件名、日志偏移量等元数据信息，而后通过这些元数据去具体的容器中取到残缺的日志内容，最初展示给用户。
全息日志理论产品效果图
这样尽管咱们只耗费大量的存储和计算资源，也能够轻松检索到海量调用链相干的业务日志。这个受限于日志在容器中的理论存储工夫，然而线上问题很少须要借助远久历史日志来剖析定位。绝大多数状况下借助以后日志就能够满足需要了。
「全息日志技术是凤睛自研技术，也申请了相干专利」
三、算法实现
全息日志技术设计中分为两个次要的局部：
- 日志元数据采集：拦挡打印日志的前后操作，进行元数据采集。
- 元数据解析：解析元数据定位出日志文件以后地位以及日志所在文件的地位。
在通常状况下，一份日志音讯可能打印到多个日志文件中，日志文件可能依据配置的滚动策略进行基于工夫或者大小的滚动，不同的工夫进行日志检索须要可能主动辨别出日志以后所在的理论地位，用户不须要感知底层日志文件地位变动。
在设计和实现中关键问题的解决：
- 元数据采集的性能和准确性问题
为了保障元数据可能被精确的采集，须要基于凤睛探针拦挡打印日志的办法。
元数据项与采集原理图
- 在原始打印日志操作之前插入字节码，记录开始工夫、读文件标识符获取打印前文件偏移量、文件的滚动策略（包含文件最大大小、文件滚动工夫等）、日志级别;
- 在原始打印日志操作之后插入字节码，记录完结工夫、读文件标识符获取打印后文件偏移量、日志内容以后写入的文件、文件按滚动策略归档后策略、同名归档时归档序号等.
- 在采集文件偏移量时通过间接读取文件描述符而不是间接读文件内容来进步性能。同时，在日志打印内容里注入每次调用惟一的 traceId 做更精准的标注，其余数据的采集用来日志检索时解析应用。
- 元数据解析
用户发动日志检索时，应用算法解析出此时此刻日志内容所在位置。
检索算法流程图
- 依据调用链 traceId 查问出与该 traceId 雷同的所以日志元数据记录；
- 别离获取日志打印完结工夫、日志打印时以后文件名、文件归档策略；
- 解析归档策略；
- 依据归档策略注入不同基准参数，模拟出一个日志打印器，以此获取到此时此刻文件地位；
- 依据文件地位，以及文件前后偏移量，读取出两个偏移量之前的日志内容；
- 用 traceId 进行内容校准.
四、结语
凤睛通过自研的全息日志技术可能帮忙业务方疾速检索到业务申请相干的残缺调用链以及残缺的业务日志。作为分布式追踪零碎，咱们也补齐了追踪畛域最初一块短板。然而业务零碎的复杂性，也决定了凤睛作为一个平台化的业务监控产品所面临的诸多挑战。
作者介绍：
李奇原，百度商业平台研发部 - 资深研发工程师
前后负责过商业平台 API 网关、商业平台部微服务凤睛监控零碎。对构建高性能、高可用分布式系统有较多实际和较深刻的了解。
举荐浏览：
|深刻了解 WKWebView（入门篇）—— WebKit 源码调试与剖析
|疾速剪辑 - 助力度咔智能剪辑提效实际
|短视频个性化 Push 工程精进之路
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注
