2月5-7日QCon全球软件开发大会携手100+位大咖讲师与你相约北京,完整日程已上线>> 了解详情
写点什么

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

  • 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:003379

评论 1 条评论

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

面经手册 · 第18篇《AQS 共享锁,Semaphore、CountDownLatch,听说数据库连接池可以用到!》

小傅哥

Java 并发编程 共享锁 Semaphore 信号量

Dubbo 接口,导出 Markdown ,这些功能 DocView 现在都有了!

程序员小航

markdown idea插件 IntelliJ IDEA 文档生成 Doc View

一瞬间让我秒变“快男”!腾讯内部强推Java性能优化手册,快了不止一点点。

Java架构追梦

Java 架构 jdk 面试 性能优化

DàYé的CTO姗姗学步路

曲水流觞TechRill

管理 CTO

vue项目实战经验汇总

徐小夕

Java 面试 Vue 大前端 Vue3

什么是低代码(Low-Code)?

移动研发平台EMAS

工具 研发效能 低代码 开发 代码

#不吐不快# CV千千条,修改最重要。代码不规范,伙伴两行泪!

程序员小航

奇葩的经历 不吐不快

我真的尽力了,最经典Redis面试14题,没时间复习就看这个吧

小Q

redis 学习 编程 架构 面试

MySQL中的锁机制

AI乔治

Java MySQL 架构 线程 锁机制

【薪火计划】03 - 从错误中认识到管理

dstweihao

管理

甲方日常53

句子

工作 随笔杂谈 日常

IoT企业物联网平台,从设备端到云端业务系统全链路开发实战

不吃米饭

阿里云 最佳实践 物联网 IoT

#不吐不快# 三观很正的Boss,你遇到过么?

架构精进之路

职场成长 奇葩的经历 不吐不快

注册中心原理剖析

石刻掌纹

MySQL从库维护经验分享

Simon

MySQL 主从复制

智变的八个瞬间,京东智联云化“?”为“!”

脑极体

圆通快递回应内鬼泄露用户信息:严打数据倒卖灰色产业

石头IT视角

Redis 持久化之 RDB 与 AOF 详解

AI乔治

Java 架构 redis持久化 redia

11.11 应对海量访问的网络基石 京东智联云自研交换机发展之路

京东科技开发者

运维 网络 交换机

Nginx-技术专题-技术介绍

洛神灬殇

Jira停售Server版政策客观解读——如何最小化风险?

PingCode

项目管理 研发管理 Jira Atlassian

会装虚拟机,删库不用跑

MySQL从删库到跑路

虚拟机 virtualbox

什么是云服务?

anyRTC开发者

音视频 WebRTC 云服务 RTC

CSS 排版与正常流 —— 重学CSS

三钻

CSS 排版

前嗅教你大数据——什么是代理IP?

前嗅大数据

爬虫 数据采集 静态IP 代理IP 动态IP

《网络是怎样连接的》PDF下载

计算机与AI

网络

Springboot过滤器和拦截器详解及使用场景

AI乔治

Java spring 架构 Spring Boot

阿里P8以hashmap讲解如何学习jdk源码,还不学习

小Q

Java 学习 源码 jdk mybatis

SQL数据库:窗口函数

正向成长

窗口函数

Glide.with(view)挂在了谁的生命周期上

mengxn

生命周期 Glide Activity Fragment

【活动回顾】WebRTC服务端工程实践和优化探索

ZEGO即构

WebRTC 服务端工程

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