deeplog and me

deeplog，顾名思义deep+log，一个深度的日志服务系统，这也是我的第一印象。18年入职成为数据组一员，参与deeplog系统的开发与运维，此时deeplog基本是服务CDN团队，作为菜鸟一开始负责查询服务，即golang开发的接口服务，供CDN前端取数。随着时间推移开始接手spark任务等一些其他的工作，并通过阅读前辈们记录的项目文档，才慢慢对整体架构有一些认识。

据我了解，deeplog立项之初，主要服务于lb团队，如果云产品非单一服务器，是由一大群天南海北的服务器共同服务，通过日志做的一些排除工作和分析工作就显得相当不便。这个时候就需要能够一个统一系统去收集各个服务器上的日志，并一些分析工作，deeplog应然而生。它做到实时收集lb服务器上的dpdk等运行日志，清理，统计以获取运行情况，以及排除故障等等，最大程度的挖掘日志的作用。比如某一ip突然没有流量了，那说明改服务器存在异常；也可以统计一定粒度的带宽，让业务团队更好了解自身业务承接的能力。项目初成获了奖，后面其他的团队，也纷纷接入deeplog，如CDN，paas，iaas，waf等一些云服务产品团队，当时deeplog的盛世，应该也是我云的盛世。

作为实时日志服务系统，从上到下用到组件，个人觉得还算丰富。

首先，收集日志。做服务就要把服务做到位，日志当然不能让被动的接收别人的投递，而是主动的自己去获取。前辈们选择了Rsyslog。其次，收集到这么多日志，不可能直接去处理，需要MQ去解耦，异步以及削峰。前辈们选择了Kafka。再次，海量日志进行Kafka中，为了更方便理解日志中想展示的信息，需要实时大数据计算引擎去处理这些日志，做清理，分析，统计等预处理 *** 作来直观的获得有效信息。选择了spark streaming。然后，存储日志数据。实时计算之后的数据，也需要高效的搜索的地方储存下来，同时为了深度分析信息，这个地方也需要分析能力。选择了elasticsearch最后 展示数据。避免业务直接 *** 作es，对数据查询增加一层proxy，过滤非法和不合理的查询。golang开发。

初代deeplog系统框架得以形成。

随着与CDN团队的亲和，工作以CDN各种需求为主，其他团队的需求为次的方式进行发展。

为足CDN不同时效客户对日志获取，先后有了离线日志回传服务，实时日志回传服务。在得知es聚合压力之后，大佬调研了clickhouse去满足需要大量聚合 *** 作的细粒度数据的客户面对CDN海外用户，用Java程序定时请求获取日志压缩包的方式，采集日志。融合CDN后，golang开发接收服务来，让合作伙伴直接post数据过来。