爱奇艺在日志实时数据监控的探索与实践

传统监控的痛点

以往监控依赖虚机部署的 shell、py 脚本，单台虚机异常数目达到阈值，即推送报警，这种方式存在如下问题。

为解决如上痛点，我们实时分析线上日志，采集各业务访问日志、异常日志、Nginx 日志、前端日志，四种维度数据上报，衡量应用系统质量的标准得以完善；对四种日志不同指标进行数据监控，各应用具备了分钟级应用的报警能力；搭建日志体系，整个系统有了提取关键线索能力，多维度快速定位问题。问题一旦定位就能通过会员的线上运维规范进行容灾操作：降级，切换通道或限流，从而保证整体的核心链路稳定性，避免客诉、用户报障。

目前会员监控分为基础监控及上层监控，基础监控依赖于 shell 脚本，进行数据上报，监控机器相关指标（CPU、内存、线程数等）；上层监控依赖于各层日志数据，监控各业务的网络状态、成功率、RT 时间、业务异常、业务状态码等上层指标，目前已实现分钟粒度报警，5min 内快速响应。

技术方案

线上实时日志量是巨大的，当数据量增长到 10 亿至百亿级别，传统的关系型数据库基本被排除在可选的集数架构之外了，同时基于日志的时间序列特点及公司体系建设情况，经过对功能性、可扩展性、社区活跃度和文档完善度的对比后，我们选择 Spark Streaming 和 Flink 作为流计算引擎，选择 Druid 作为实时分析数据库。Spark Streaming 通过微批次将实时数据拆成一个个批处理任务，通过批处理的方式完成各个子 Batch，API 非常简单灵活。Flink 基于原生数据流计算实现，保证 Exactly once 语义，支持延时数据处理，可以达到毫秒级低延时。Druid 是一款开源的为实时数据的亚秒级查询设计的数据存储引擎。主要用于进行 OLAP 聚合分析。这些工具的 API 和文档都比较完善，社区活跃度较高，通过服务云实时分析平台（RAP）能够快速搭建，维护成本低。

数据流图

数据采集：虚机中安装 Venus-Agent（爱奇艺自研基于 Filebeat 数据采集）进行实时数据采集，上报至指定 kafka 集群。

实时处理：会员日志监控 90% 指标是由实时计算产生的，相关报警数据处理依赖大数据实时分析平台（Realtime analysis platform）进行解析，过滤，处理，聚合之后写入分布式存储当中。

存储：Druid 集群在整个会员监控中是集数据存储、展现的数据中心，所有的实时计算结果数据、阈值数据、其他时间序列的数据都要汇总到 Druid 存储当中。

离线计算：离线计算部分主要处理的是离线的数据表，数据来源为 Druid 及 Mysql 集群中，用于每天的日报、周报，用来进行长时间跨度的分析，智能化指标数据训练。

监控相关功能

下图为已有相关功能图：

利用 Nginx 日志、应用异常日志、应用访问、前端投递日志进行如上不同维度的分析，实现了固定阈值、实时突增等触发方式，热聊、邮件、电话等推送方式。

日志监控

Nginx 日志：可获取网络层信息，如: 接口、机房、HTTP 状态码、域名、IP、RT 时间等，我们对这些信息进行实时聚合、监控、报警后二次分析，进行精细化告警，提供排查方向，极大提高排查效率。例如下图中，通过报警截图可知单台机器 499 状态码占比过高，引起成功率降低，排查方向可确定为这台机器问题，极大提高排查效率。

前端投递日志：后端监控到的响应时间，往往不能完全真实反映用户的网络状况，因此我们在关键业务相关页面，进行接口相关数据投递，从用户侧反映后端接口状态，更具有价值。目前监控维度包括页面加载耗时、后端接口耗时、静态资源耗时等，区分地区、地域、运营商等信息。如通过指标分析出某个运营商、某个地区的用户请求存在较高延时，则可进一步调整对应 DNS 配置，从用户侧优化网络状态。

业务访问日志：业务返回的状态码，可从业务角度实时监测服务状态，提取 ERROR 日志，进行实时分析告警；比如会员鉴权业务，Code-Q00508 代表平台值不匹配，对应业务可能存在编辑划价错误；实现方式同异常告警相似，同样进行了问题分析定位，给与排查方向。

业务异常日志：对于业务来说，每一次异常都代表了系统间的一个问题，就是隐藏的一次客诉，比如 ResourceAccessException 超时问题、NEP 空指针问题、UnknownHostExcepiton 解析问题，都会对线上用户带来影响；

如下报警截图所示，ResourceAccessException 异常集中于电信机房，问题出在下游系统中电信机房服务超时，同时提供接口名称，可快速定位问题方，提高排查效率，避免客诉问题。

Js中文网 – 前端进阶资源教程 www.javascriptC.com,typescript 中文手册
专注分享前端知识，你想要的，在这里都能找到

网络运维数据：以往线上机器数量及流量配比，多依赖于运维经验，容易出现错误；利用 Nginx 日志，可离线统计每日流量峰值，进一步分析机器数量，提出优化建议，提高机器利用率，避免机器浪费；同时检测 Nginx 机房流量不均问题，提供予运维人员以数据指导，极大增加了操作的安全性、及时性。

除此之外提供网络拓扑、流量拓扑等功能，也能进一步增加开发人员对网络感知。

遇到的问题

1、数据标准化

处理日志信息首要问题是要统一日志格式，保证采集到数据的准确性，同时会员这边 80% 的应用部署在虚机上，20% 部署在 QAE 中，监控采集需同时兼容两种部署方式；

• Nginx 日志，提供统一化运维平台，封装 Nginx 安装、扩容、克隆等操作，内置工具统一 Nginx 日志模块，统一日志格式；
• Exception 日志，提供通用化配置方案，支持 QAE 应用及虚机应用，分别采用不同数据流处理，将 kafka 流合并后统一消费；
• 业务日志，提供统一日志组件，打印 request、response 相应信息即可。

2、机器采集性能瓶颈，延迟

采集日志客户端（Venus-Agent）部署在应用机器上，目前通过 CGroup 限制资源使用（默认使用 1 核 128M 内存），采集效率依赖于 CPU、内存资源等资源，同时也被提取规则的复杂程度所影响。

• 对于大流量应用来说，应尽可能精简提取规则，同时平衡资源等关系 ;
• 精简无用日志打印，尽可能一条请求打印一条日志，避免重复打印；
• 日志流量过大，考虑采样提取。

历史教训 :

• 20WQPS 应用，一条请求打印 5 条日志，日志量放大至 100WQPS，资源集群濒临崩溃；
• 经过总结：经反复实践，对于 Nginx 机器（8core32G），限制在 2core 2G 可保证 4WQPS 同时采集；
• 对于虚机（6core8G），可维持在 1core 512M 进行采集 。

3、减少计算资源，节约成本

计算资源同样需要合理分配，Druid 单 Task 预计能消费 15Wqps 的消息，增加 Task 可以提高处理能力。由于 Druid 自身的 partition 能力不是特别出色，所以多 5 倍资源并不能提升 5 倍的处理能力。所以采取将高 QPS 的实时数据拆分成多个子 Topic 的方式，接入 Druid 多个 Datasource，对于百万 QPS 的 Nginx 流量来说，有如下两种节约方案，采用第二点方案，拆分多个数据流后，相应计算资源节约了 120core。：

• 采样流量数据。优点：改造成本小；缺点：Nginx 日志对排查问题极为重要，采样会缺少相应日志；
• Nginx 机器流量拆分，高流量应用 Nginx 集群独立部署，拆分多个数据流。优点：可避免流量冲击对其他 Nginx 集群造成影响，保证核心业务的稳定性；缺点：改造成本高，依赖于基础运维体系。

4、Spark Streaming/Flink 消费延迟

对于监控系统，报警时间尤为重要，如何保证消费时能平稳进行，不出现延迟尤为重要，将调优 Kafka Partition 数以及 Druid Task 数，调整到最优的值。

另外，由于 Spark Streaming 伪实时，将实时任务拆分成一个个批处理逐一阻塞处理。从中发现 SparkStreaming 任务中的平均处理时间并不高，常常由于单个 Task 太慢，导致单批次处理太慢。于是针对实时 OLAP、并不关注消息的到达顺序的场景，将 spark.streaming.concurrentJobs 配置成流任务的并行度，以提高流计算任务并行处理能力。

价值与未来规划

爱奇艺会员服务团队供通用化监控平台，接入方式简单，可快速对系统搭建以上监控体系，并可以面向公司的其他业务团队监控服务。建立完整的跟进机制，多级反馈，提高告警感知，提升排查效率 80% 以上，预先发现 90+ 次会员客诉问题，客诉率极大降低，监控覆盖 400+种异常，提供有效告警 4800+ 次。

未来，爱奇艺会员服务团队将从监控阈值智能化、流量问题预测、辅助定位等方面进行进一步优化：

• 监控阈值智能化：将监控向智能化增强，在业务监控的某些环节上代替人工执行和判断的过程。人工维护监控目标和阈值是以经验为参考的；依赖对历史样本数据统计分析、以往问题场景判断，得出依据，系统自动判断哪些目标需要监控、同时智能调整相应阈值策略。
• 流量问题预测：通过对 Nginx 流量日志的收集，使用智能预测算法模型，收集原有流量数据及收集相应热剧、营销等流量指标，预测服务流量峰值，给开发人员以流量预警机制。
• 辅助定位：监控覆盖更多的链路及模块，将报警关联，智能分析出问题场景，提高分析问题原因准确性，降低报警漏报率、误报率。

链接：https://www.infoq.cn/article/TLxQWhgOLrcL8vUrwyqd