百度商业大规模微服务分布式监控系统——凤睛

1. 核心服务问题定位周期长。多个模块大量报错后，花费了很长时间才定位问题。

2. 集群日志获取代价非常高，缺乏日志调用链关系等原因导致定位代价很高，甚至有些问题无法定位。

3. 异常日志需要登录具体的线上实例查看。而线上部署实例数目多，排错时间长。

   
   

凤巢业务端急需一个分布式追踪系统来完成整个业务端日志的“大串联”。所以百度商业平台基础架构组发起了凤睛的项目，名曰“凤巢之眼”。

△编码示例

04  凤睛3.0 

凤睛3.0架构设计中，项目组成员一直在思考两个问题：

1. 如何让业务方快速接入，尽量少改动，甚至“无感知接入”？

2. 如何降低架构运维难度，既能处理海量数据，又能低成本运维？

为了解决问题1，探针3.0 决定完全放弃侵入式方式，改为无侵入即字节码增强方式。

对当时几种流行的监控诊断工具进行了调研：

△Newrelic，pinpoint，greys监控探针调研

3.0探针参考了Greys支持运行时增强的特点以及 pinpoint、Newrelic基于插件扩展开发的设计理念。最终效果是探针能够自动对业务进程植入监控代码，监控具体工作交由插件体系完成，完全面向切面监控。

△探针主动加载示意图

后端存储系统转而依托Doris。Doris是百度自研的基于 MPP 的交互式 SQL 数据仓库，兼容mysql协议，学习成本低。既可以做存储又可以做分析计算，初期避免引入spark，storm等技术，降低系统复杂度。

△架构设计如图所示

架构升级后，作为小团队，也能快速批量部署探针，计算存储能力也能满足需求。截止2017年，凤睛3.0上线了100多个应用，跑在1000多个容器上面。

05  凤睛4.0

2018年，微服务和虚拟化浪潮席卷而来。随着部署平台的不断升级和 springboot体系的成熟完善，单体能够被快速拆分成了数目众多的微服务，依托平台进行高效的运维部署。凤睛作为基础组件被微服务托管平台集成，并得到公司级的推广应用，整体部署应用规模从百级别激增到了千级别，部署容器从千级别变成了万级别。

这个阶段爆发了很多问题，技术核心问题主要有两点：

1. 探针升级需要重启业务应用生效，而线上应用重启流量有损。导致难以频繁升级探针版本，快速引入新功能。

2. 每天实时写入150亿条，峰值流量 300w 条/s。数据导入容易丢失；检索单条调用链性能查，大概需要100多秒。

2019年，凤睛进行了进一步的改造升级，针对1、2两个问题，进行了技术攻坚。

探针层面研究如何支持热插拔，也就是探针在业务进程运行的情况下自动完成升级。起初为了保证业务类对探针插件类的可见性，探针类统一放到了 System Classloader里。但是System Classloader 作为系统默认的，不支持卸载。反之，如果把探针类全部放到自定义类加载器中。探针类则对业务类完全不可见，也就无法完成字节码增强。

△探针热插拔classloader体系

为了解决可见性问题，探针引入了桥接类，通过桥接类提供的代码桩和插件类库投影，用户类可以访问实际使用的探针类，完成监控改造的目的。对于不同插件，则放在不同的自定义 Classloader 里面。这样来插件之间互不可见。单个插件也可以完成热插拔。具体的设计细节后面会有文章详细解读。

首先分析下我们的底层存储结构：

通过对慢查询的分析，发现检索慢主要是两个原因：一是大量查询没有走任何索引，全表扫描海量数据非常慢。二是，导入碎片过多，导致文件Compaction特别慢，典型的LSM-Tree 的读放大。为了解决这些问题，调用链存储层重构表结构，通过大量Rollup配合基本表，优化查询时间。Doris 此时已经具备流式导入的能力，也借机从小批量导入切换到流式导入。

△调用链处理架构