写点什么

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

  • 2020-03-09
  • 本文字数:3581 字

    阅读完需:约 12 分钟

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

传统监控的痛点

以往监控依赖虚机部署的 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 异常集中于电信机房,问题出在下游系统中电信机房服务超时,同时提供接口名称,可快速定位问题方,提高排查效率,避免客诉问题。



网络运维数据:以往线上机器数量及流量配比,多依赖于运维经验,容易出现错误;利用 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 流量日志的收集,使用智能预测算法模型,收集原有流量数据及收集相应热剧、营销等流量指标,预测服务流量峰值,给开发人员以流量预警机制。

  • 辅助定位:监控覆盖更多的链路及模块,将报警关联,智能分析出问题场景,提高分析问题原因准确性,降低报警漏报率、误报率。


本文转载自公众号爱奇艺技术产品团队(ID:iQIYI-TP)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI0MjczMjM2NA==&mid=2247486371&idx=1&sn=3d5c15fb99c45c0eb1701090e1a0a6df&chksm=e9769780de011e9688313d7c0241c5592596f23c0e62adb64dd035a569226c4de2b04b7b3e94&scene=27#wechat_redirect


2020-03-09 10:004042

评论 1 条评论

发布
暂无评论
发现更多内容

架构师 3 期 3 班 -week2- 总结

zbest

总结 week2

在K8S/OpenShift上开发应用程序的14种最佳实践

东风微鸣

Kubernetes 最佳实践 k8s最佳实践 openshift

LeetCode题解:455. 分发饼干,贪心while循环,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

「云原生上云」后的聚石塔是如何应对 双11 下大规模应用挑战的

阿里巴巴云原生

阿里云 云原生

Serverless 应用引擎的远程调试和云端联调

阿里巴巴云原生

Java Serverless 云原生 后端

从零做网站开发:基于Flask和JQuery,实现表格管理平台

华为云开发者联盟

jquery flask 框架

进一步深挖工业数据价值

CECBC

数据安全;工业互联网

《视觉系统中的深度学习》PDF及源代码免费下载

计算机与AI

学习 计算机视觉

你敢信?就是这个Netty的网络框架差点把我整疯了,哭jj

小Q

学习 编程 面试 Netty 网络

linux后台开发必知的linux系统内存知识总结

linux大本营

c++ Linux 后台开发 架构师 内存管理

中国CRM突围指南

ToB行业头条

CRM

同步与异步,回调与协程

Linux服务器开发

线程 后端 协程 底层应用开发 Linux服务器开发

浅谈互斥锁与进程间的通信(举例说明)

ShenDu_Linux

Linux 程序员 架构师 进程线程区别

年轻人快来学习TCP 协议如何解决粘包、半包问题!

程序员小灰

c++ Linux TCP 后台开发 Linux服务器开发

数字货币将带来怎样的“革命”

CECBC

数字货币 货币

测试过程中如何快速定位一个bug

测试人生路

软件测试

区块链技术应用打造智慧物流

13828808769

区块链技术应用开发

为什么从蚂蚁离职?base拉胯,高潜也被倒挂,就是酸,忍不了

Java架构师迁哥

架构师 3 期 3 班 -week2- 作业

zbest

作业 week2

技术应用丨DWS 空间释放(vacuum full) 最佳实践

华为云开发者联盟

内存 存储 磁盘

区块链在国际贸易领域应用的法律问题

CECBC

区块链

当居住空间被智能包裹:OTA智能社区改变了什么?

脑极体

关于物联网规则引擎技术,你想要知道的都在这儿!

华为云开发者联盟

数据 联动 iotda

大企软件系统问题多?归乡名企工程师:解决很简单,分分钟做个新系统

Learun

敏捷开发 快速开发 企业开发 CRM 企业应用

《迅雷链精品课》第九课:区块链P2P网络

迅雷链

区块链

爆买剁手之后,我们的快乐为什么越来越贬值?

脑极体

设备常用网管配置举例

cncf serverless 所有项目全解读

coldTea214

云计算 Serverless 容器 cncf

OPPO技术开放日第六期丨OPPO安全解析“应用与数据安全防护”背后的技术

OPPO安全

OPPO安全

精彩回顾 | 一张图读懂OPPO应用与数据安全防护

OPPO安全

OPPO安全

深入了解进程间通信:System V信号量+共享内存

ShenDu_Linux

Linux 进程 内存管理 通信协议

爱奇艺在日志实时数据监控的探索与实践_大前端_爱奇艺技术产品团队_InfoQ精选文章