关于前端:Corona技术专题日志上报采集分流链路设计

本文作者：轻山

一. 前言

关联浏览 网易云音乐大前端监控体系（Corona）建设实际 - 开篇。

Corona 是网易云音乐的大前端监控产品。Corona 的 SDK 在利用中捕捉到各种类型日志后，经由上报、采集、分流链路达到 Corona 的生产服务进行解决。这条链路会间接影响到 数据实时性 和零碎稳定性，如何高效、稳固、便捷的将利用产生的日志交由服务端生产就显得尤为重要。本文具体介绍 Corona 中的这条链路的设计与实际。

二. 在 Corona 整体架构中的地位

在零碎架构中，日志上报、采集、分流链路所处的地位如下（图中蓝色局部）：

整条链路是在网易团体 & 云音乐的公共服务根底上做的能力整合，同时为了可能服务于团体其余事业部或者在其余事业部私有化部署，对依赖的云音乐服务节点做了可替换的设计。本文内容是这条链路进行具体的开展介绍。

三. 具体实现

3.1 通过云音乐日志服务上报日志

Corona 各端 SDK 通过云音乐日志上报服务提供的 http 接口上报日志

云音乐的利用通过日志服务上报日志的链路如下：

其中：

• 网络层

  • 不同类型的利用上报日志的形式是差异化的，比方 Android、iOS 利用是每产生一条日志就写入到本地文件，而后异步的把日志文件上传到日志服务，而 Web 前端利用是以一般的 HTTP POST 申请上传；
  • 日志服务的接口设计了业务专属域名，命名规定就是在各个业务的主域名上增加约定的前缀。因为各个业务的 Cookie 是种在主域名下的，这样设计能够使得 SDK 采集日志后主动携带 Cookie 上报，从而使得日志信息更加丰盛。

• 日志传输层

  • 日志服务集群接管到不同业务、不同利用类型上报的日志后，首先会对日志做预处理，包含：

    • 解压缩日志文件（来自 Android、iOS 等利用）、解密日志（有些加密上报的场景），最终使得各个起源的日志格局是统一的；
    • 解析 Cookie，获取用户信息（UID）等业务数据塞入日志；
    • 解析 ip 塞入日志；
    • 记录日志上报到服务器的工夫；
    • …
  • 日志预处理实现后，会先暂存在服务器本地磁盘中。为了不便日志传输到不同的目的地，会依据 日志类型 、 利用类型 、 业务 等要害信息进行归档后写入到不同的日志文件。

这条链路属于云音乐专属的日志上报通道，为不便业务接入应用做了一些定制设计（比方业务专属日志域名）。

3.2 日志采集服务

上文讲到利用的日志上报后存储在日志服务集群的本地磁盘上，如何高效、稳固、便捷的采集这些日志就显得尤为重要。Corona 应用网易团体数据迷信核心自研的一款日志采集服务实现日志实时采集、ETL 归档等性能。

如图所示，Agent 是日志采集服务外围的采集程序，部署在云音乐日志服务集群的应用服务器上，用户通过治理后盾进行 Agent 治理，并由 Manager Service 下发采集规定到 Agent 程序。

采集规定是稳固的、极少变动的，会将一个业务下所有日志都采集上来，即便新增的日志类型也会被主动采集，尽量避免变更采集规定而对下层利用造成不可预知的危险。

Agent 程序会依据规定读取指定文件的日志，记录文件采集地位，并将采集到的日志送往 2 个目的地：

1. DWD 明细数据层，是一个 HBase 数据库，用于原始日志的备份、提供给数据分析师应用、或者凋谢给开发者自助剖析；
2. 写入 kafka 音讯队列，通过一系列流转后最终会流入 ADS 层数据库（利用数据层），被 Corona 的日志生产服务订阅；这里不同的业务和日志类型会有专属的 kafka topic，这样设计的起因是因为不便在云音乐外部给业务其余服务、产品去订阅生产，做一些自定义的性能、业务指标统计等；

以上是对日志采集过程的简略介绍，想理解日志采集服务更多细节的同学能够查看 Apache 的顶级开源我的项目 flume。

3.3 面向数据消费层实现日志分流

3.2 中由日志采集服务写入 kafka 的日志，蕴含一个业务（or 利用）所有监控日志类型，比方设施沉闷日志、异样日志、性能日志等，并且这个日志品种十分动静，随时会因为新增监控指标而减少。Corona 的架构设计里，在数据消费层不同类型的日志有不同的生产服务，如果让每个生产服务间接订阅上述 kafka topics 的话，会带来极大的资源节约以及稳定性危险，假如有如下 2 个业务场景：

如图所示，每个生产服务能承载的日志流量下限，必须按所有日志类型的累计流量来设计，在服务外部用代码逻辑过滤抛弃不须要的日志，并且一旦某个日志类型呈现了流量突增，那么所有生产服务都须要承当流量峰值带来的危险。

为了解决这个问题，Corona 应用 Flink 对日志做分流，确保达到应用层各个生产服务的日志是单个生产服务所须要的日志。Flink 实时计算能力由 云音乐数据平台 提供。

用 Flink 实时工作实现日志分流的过程如下：

从日志服务集群上、按业务采集的日志会流入一张流表中，而后 Flink 实时流工作依据上游不同生产服务的须要去流表中查问相干日志。能够简略了解为，Corona 针对异样监控、性能监控、实时流量监控场景有 3 个日志生产服务，Flink 会依据这 3 个服务所须要的日志类型去查问日志，而后写入 3 个新的音讯队列。

至此，每个生产服务承接的流量就变成了下图：

每个生产服务在设计时只须要思考相干日志类型的流量下限。一方面缩小了服务器资源的节约，另一方面繁多日志类型的突增也只会影响单个生产服务的稳定性，不会导致整个零碎不可用。

3.4 极其大流量的应答措施

通过上述日志分流工作解决后，尽管曾经保障了繁多日志类型的突增只会影响单个生产服务的稳定性，但单个生产服务的宕机也会导致产品局部性能不可用，这对于用户来说是不可承受的，也不合乎监控产品自身高可用的指标。

前置链路中日志异步采集以及 kafka 音讯队列曾经可能起到削峰的作用，但在极其大流量下还不足以保障上游利用的稳定性以及实时性。

在经验屡次线上日志流量异样突增的紧急解决之后，目前 Corona 在日志链路层采取以下应答措施：

1. 数据生产服务减少日志类型流量监控、告警；
2. 收到告警后，在 Flink 分流工作中，配置针对大流量日志的过滤规定，间接抛弃；

日志分流工作计算逻辑比拟轻量，因而对流量并不敏感，而且 Flink 的实时工作扩容很不便，无需运维参加，开发者间接调整参数重启即可。

以上过程须要开发者参加响应流量告警，因为极其大流量场景比拟少见，所以人工响应老本并不大。

在 Corona 的生产服务设计中，也凋谢反对用户自主设计过滤规定、抛弃利用日志，同时应用层的服务也有针对日志波峰的主动响应策略，在本文中不作开展介绍了，将来会有专门文章介绍生产服务的设计。

至此，对上述日志分流链路图略作补充，减少极其大流量的响应、解决链路：

3.5 独立日志上报通道

3.1 所述的日志上报链路属于云音乐专属通道，有不便云音乐业务接入应用的定制设计，并不适宜团体其余事业部接入。出于将来商业化思考，为了能疾速接入其余 BU 的利用，Corona 也提供了独立的日志上报服务。

Corona Log Receiver 是一个 Node.js 利用，上报到此服务的日志并不会携带业务方的 Cookie。如果接入方须要更多业务信息（比方用户 id 等信息），能够应用 SDK 提供的 api 进行全局设置（在介绍 SDK 的文章中会具体开展），之后 SDK 在上报日志时就会携带这些额定信息。

Corona Log Receiver 在接管到日志后会将额定信息与原始日志进行重组、以及增加用户 ip 信息等操作，而后将日志写入独立的 kafka topic，间接对接分流服务。

咱们对上述数据流图略作补充，失去以下的 Corona 日志上报、采集、分流链路图：

四. 总结

本文分 5 大节介绍了云音乐大前端监控产品 Corona 的日志上报、采集、分流链路，以及极其大流量场景下的应答措施。将以上内容串联后能够失去以下残缺的日志流转链路图：

本文是 Corona 技术专题的第二篇，欢送大家多多交换。

本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！