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

HearstMichell 发布于28天前
0 条问题

2019年6月爱奇艺会员规模突破1亿,爱奇艺的会员服务业务随之迅速增长,同时也带来了机器集群规模的增加,原有的监控体系也暴露出一些问题。数据监控体系是业务维持稳定服务的基石,会员日志监控体系形成闭环,从网络、应用、异常、页面加载多维度监控,极大提高了系统的成功率、稳定性,对会员视频播放、营销、下单等核心功能增强异常感知。 提高定位的效率,快速发现问题,缩短解决问题时间,避免客诉等。 爱奇艺会员服务团队基于线上实时日志,抽取相应监控指标,进行了监控体系的迭代。 本文将分享一下会员服务团队在日志实时数据监控的探索与实践。

传统监控的痛点

以往监控依赖虚机部署的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流量日志的收集,使用智能预测算法模型,收集原有流量数据及收集相应热剧、营销等流量指标,预测服务流量峰值,给开发人员以流量预警机制。

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

欢迎加入 DataFunTalk 大数据 技术交流群,跟同行零距离交流。如想进群,请加逃课儿同学的微信(微信号: DataFunTalker ),回复: 大数据 ,逃课儿会自动拉你进群。

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

也许你还想看

Flink如何支持特征工程、在线学习、在线预测等AI场景?

推荐关注:

DataFunTalk 专注于大数据、人工智能技术应用的分享与交流。发起于2017.12,至今已在全国7个数据智能企业和人才聚集的城市( 北京、上海、深圳、杭州等)举办超过100场线下技术分享和数场千人规模的行业论坛及峰会,邀请300余位工业界专家和50位知名学者参与分享,30000+从业者参与线下交流。合作企业包括BATTMDJ等知名互联网公司和数据智能方向的独角兽公司,旗下DataFunTalk公众号共生产原创文章300+,百万+阅读,5万+精准粉丝。

左侧关注" 社区小助手 "加入各种 技术交流群 ,右侧关注" DataFunTalk "公众号 最新干货文章 不错过!

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

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

一个 在看 ,一段 时光 :point_down:

查看原文: 爱奇艺在日志实时数据监控的探索与实践

  • yellowswan
  • orangepeacock
  • smallkoala
  • beautifultiger
需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。