实时任务告警指标分析方案（实时告警包是什么）

本篇文章给大家谈谈实时任务告警指标分析方案，以及实时告警包是什么对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享实时任务告警指标分析方案的知识，其中也会对实时告警包是什么进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Flink Metrics指标采集方案
• 2、客户服务数据指标分析解决方案
• 3、深基坑安全监测系统的监测指标一般是哪些？
• 4、项目管理系统对企业的价值
• 5、分布式定时任务调度框架实践
• 6、流批一体不只有Flink，还有实时数据模型

Flink Metrics指标采集方案

本文讨论的都是基于Flink On K8s场景下实时任务告警指标分析方案，该场景下存在几个特点，一是存在线上业务系统资源复用，二是调度节点存在"随机性"，对现有的Flink Metrics采集及使用姿势提出实时任务告警指标分析方案了新的要求：

Flink任务自动扩缩容，智能诊断场景依赖Metrics指标进行加工分析处理，现有Prometheus存储方案不再适合。
既有的指标采集需要先落本地，再由nodeexporter或lancer导出到目标存储，强依赖于Local环境，线上业务系统资源环境差异较大，扩容等维护成本较高，资源隔离性不够好。
期望在Flink On K8s场景下，Flink Metrics指标采集，能够不依赖于基础环境，对扩缩容友好，，支持指标采集及分析数据存储统一，降低指标维护使用成本，对Flink Metrics指标采集方案进行调研

2.1.1、 原理架构图如下

2.1.2、 配置方式
将flink-metrics-prometheus-1.14.3.jar 包放入到flink安装目录/lib下
修改flink-conf.yaml配置文件，设置属性
Example configuration:
metrics.reporter.promgateway.class: org.apache.flink.metrics.prometheus.PrometheusPushGatewayReporter
metrics.reporter.promgateway.host: localhost
metrics.reporter.promgateway.port: 9091
metrics.reporter.promgateway.jobName: myJob
metrics.reporter.promgateway.randomJobNameSuffix: true
metrics.reporter.promgateway.deleteOnShutdown: false
metrics.reporter.promgateway.groupingKey: k1=v1;k2=v2
metrics.reporter.promgateway.interval: 60 SECONDS

2.2.1、原理架构图如下

2.2.2、配置方式

将flink-metrics-prometheus-1.14.3.jar 包放入到flink安装目录/lib下
修改flink-conf.yaml配置文件，设置属性
Example configuration:
metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
metrics.reporter.prom.port: 9250-9260

2.3..1、原理架构图如下

2.3.2、配置方式

将flink-metrics-influxdb-1.14.3.jar 包放入到flink安装目录/lib下
修改flink-conf.yaml配置文件，设置属性
Example configuration:
metrics.reporter.influxdb.factory.class: org.apache.flink.metrics.influxdb.InfluxdbReporterFactory
metrics.reporter.influxdb.scheme: http
metrics.reporter.influxdb.host: localhost
metrics.reporter.influxdb.port: 8086
metrics.reporter.influxdb.db: flink
metrics.reporter.influxdb.username: flink-metrics
metrics.reporter.influxdb.password: qwerty
metrics.reporter.influxdb.retentionPolicy: one_hour
metrics.reporter.influxdb.consistency: ANY
metrics.reporter.influxdb.connectTimeout: 60000
metrics.reporter.influxdb.writeTimeout: 60000
metrics.reporter.influxdb.interval: 60 SECONDS

2.4.1、原理架构图如下

2.4.2、配置方式

将flink-metrics-jmx-1.14.3.jar 包放入到flink安装目录/lib下
修改flink-conf.yaml配置文件，设置属性
Example configuration:
metrics.reporter.jmx.factory.class: org.apache.flink.metrics.jmx.JMXReporterFactory
metrics.reporter.jmx.port: 9250-9260

2.5.1、配置方式

将flink-metrics-slf4j-1.14.3.jar 包放入到flink安装目录/lib下
修改flink-conf.yaml配置文件，设置属性
Example configuration:
metrics.reporter.slf4j.factory.class: org.apache.flink.metrics.slf4j.Slf4jReporterFactory
metrics.reporter.slf4j.interval: 60 SECONDS

GraphiteReporter、StatsDReporter、DatadogHttpReporter

指标采集到Kafka后，将全量指标实时写入ClickHouse.

指标采集到Kafka后，将全量指标实时写入ClickHouse同时满足监控大盘需求及指标数据长期存储和二次加工分析，该方式优势指标数据源统一，任务大盘及告警

客户服务数据指标分析解决方案

大多数企业对客户服务设置了很多追踪指标，如以下示例：

客户满意度：是对顾客满意程度的衡量指标。通过连续性的定量研究，获得客户对特定服务的满意度、消费缺陷、再次购买率与推荐率等指标的评价，找出内、外部客户的核心问题，发现最快捷、有效的途径，实现最大化价值。

首次响应时间：首次响应时间是指客户发出第一条消息客服弹窗后，客服手动回复客户的第一条消息之间的差值。

平均通话时间：指谈话时间和事后处理时间的总和。

平均应答速度：指总排队时间除以所回答的总问询数。

平均交谈时间：指用户与客服联系后交谈的时间长度。

平均排队时间：在客户咨询产生排队的时候，每个客户排队等待的时间的平均值。

事后处理时间：即一次会话结束前，客服需要完成与此次会话相关的整理工作所需要的时间，例如：转工单、填写会话标签、客户标签、客户资料。有些填写可以在客户咨询的同时完成。

转接率：转接电话数占全部接通电话数的百分比。

平均持线时间：值机业务员让顾客在线上等待的平均时间。

平均振铃次数：指顾客听到回话之前电话玲振响的次数，不论这个电话是由业务员、 还是IVR回的。

呼叫数：指所有打入/打出中心的电话，包括收到阻塞的、中途放弃的和已经答复的电话。

呼叫放弃率：一个放弃电话是指已经被接通到中心，但又被呼叫者在值机业务员、呼出电话员和信息通知部接听之前自动挂断了的电话。放弃电话数占全部接通电话数的百分比。

平均放弃时间：指呼叫者放弃呼叫前平均等待的时间，以秒来计算。

平均单呼成本：等于某段时间内中心所花的全部费用除以这段时间中中心所接听的所有电话数，它包括无论何种理由打入的无论什么电话，不管是由业务员接听的，还是由技术系统接听的。

……

需要考核的指标有很多，出现了很多问题：

过多的考核指标对被考核人来说会引起心理上的无所适从，搞不清楚工作的轻重缓急，无法更为有效地安排自己的工作，搞不清楚怎么做才能达成绩效考核要求，进而会使绩效考核流于形式。而对于管理者和企业来说，数据太多太混乱，容易导致分析困难、思路混乱、找不到需要关注的重点，不知道数据反映出的真相到底是什么？从而无法做出更明智的策略来改善客户服务和优化客户体验。因此，你可以试着先关注3-5个最重要的绩效考核指标，通过如怡海软件客户服务解决方案 ，能让你保持专注，获得更条理清晰、经络分明的数据结果。为被考核人工作努力方向选择和目标达成创造更好的前提条件。

客户满意度

到底什么是客户满意度呢？客户满意度的衡量有多重要？企业又该如何衡量客户满意度？

从根本上来说，客户满意度决定着客户忠诚度。一般来说，企业每5年就会失去一半的客户，导致企业需要不断获取新客户。客户满意度可以通过允许企业“消除痛点并提高客户忠诚度”来限制客户流失。通过对客户满意度的调查，客服团队才可以找出不足，弥补缺点，提供有针对性的服务，促进与客户间的沟通，进而提升客户忠诚度。

高效的跟踪客户满意度情况的方式有多种，根据平均分、表情变化、星级评分、净推荐值等，但最好是多种方法结合在一起使用。

平均等待时间

客户在给我们发邮件后或打电话给我的代表后，需要等待多长时间才能收到我们的回复？

据ATT调查及某语音应答公司统计：

客户一般等待90秒后就会挂断电话，

在等待时听音乐的客户会认为30秒的等待时间只有15秒；

在没有成功接入电话的客户中大约有34%的人不会再打电话进来，因此呼叫中心通常只有一次机会接入客户的电话。

平均等待时间以及等待期间的客户体验是衡量客户服务水平的重要指标，因此如何高效监控这些数据以及能如何更快速的响应客户需求、问题非常重要，这些CRM能帮你解决。

平均处理时间

AHT（平均处理时间）指处理一次联络所需的平均时间。以一通电话呼叫为例，AHT指与客户沟通的时间以及在呼叫后所需完成的工作 (如行政信息、后台操作、甚至简单地处理呼叫信息作统计分析用途等）的时间总和。各种各样的AHT追踪着不同的环节或技能，因此是一项至关重要的数据集，能帮助呼叫中心实施有效的管理，例如在规划团队和工作量方面，以及有助达到关于呼叫等候的服务质量目标。

平均放弃时间

指呼叫者放弃呼叫前平均等待的时间，以秒来计算。此一数据可以收集记录在CRM中，随时获得每日和每周报告。全行业平均时间为60秒，建议标准范围为20-60秒。建议管理措施：等待时间很短即放弃，表明顾客等待的耐心有限，原因可能是有其它中心可以选择，也可能是不喜欢拨叫你们中心时老是不成功。两者都值得引起重视，并采取相应措施。检查放弃者的数目、没有拨通的情况和排队的时间，看是否存在呼叫者拨不进来的问题，这一问题如果在顾客那里显得很重要，呼叫者的满意率就会明显下降。

事后处理时间

即指一次呼叫电话接听完后，值机员完成与此一呼叫有关的整理工作所需要的时间。呼后处理可能有值机员做的，也可能由客服小组或者中心做，是一种有益的资料，可从CRM中得到。这一规范可由CRM中获得日表、周表和月表，或以柱状图形等方式与过去的记录进行比较。

中心平均事后处理时间建议目标是30秒至60秒。建议管理措施：如出现此一方面的问题而又与训练、程序和技术等因素无关，建议客服小组每一小时贴出此一规范的标准目标，直到情况改善为止。

平均需要联系的次数

在客户问题解决前需要和我们的客户服务部门沟通多少次？又要和多少不同的服务人员进行沟通？

这个指标往往被很多企业客服部门所忽略，实际上，这项指标对提高客户满意度和客户体验十分重要，检测这项数据将帮助企业发现客户服务存在的短板和问题，并想办法去进行优化。

对于客服管理人员来说，如何通过数据找到问题，提升管理、提高服务质量是非常重要的。怡海软件基于云CRM的客服服务管理平台提供了功能强大的数据分析工具，让你对关键数据指标数据一目了然。

深基坑安全监测系统的监测指标一般是哪些？

深基坑安全监测系统的监测指标一般是基坑土体、支护结构、自然环境和周边环境等实时任务告警指标分析方案，据实时任务告警指标分析方案我所知，“全球共德”在数字建筑领域内评价挺不错的，智慧工地管理系统深受好评。但我们公司还没用过实时任务告警指标分析方案他们的深基坑检测系统，你可以先问问他们的业务

深基坑安全监测系统的监测指标一般是基坑土体、支护结构、自然环境和周边环境等。广东地空智能 科技 有限公司开发的GSI-FM基坑安全监测平台支持电脑、手机、平板等多客户端应用，实现在各种环境下便捷查看基坑情况及辅助办公，提高工作效率。GSI-FM基坑安全监测平台是数智化理念在基坑工程监测领域的行业具现，通过高精度北斗定位技术、智能传感技术、通讯技术融合物联网、云服务等多项前沿技术于一体获取生产、施工过程中显示与隐形信息，结合施工规范和技术标准，进行隐蔽工程或关键工序质量管控。利用GIS和BIM模型，通过前端检测设备全天监测支撑轴力、锚杆拉力、立柱内力、孔隙水压力、土压力等基坑数值，实时传输至平台分析，及时发现危险预兆，采取补救措施，根据数据优化设计方案，预防工程安全事故发生。

一、平台优势：

基坑监测一张图 ：BI大数据一张图全方位数智化统计分析基坑工程情况

GIS+三维可视化 ：高精度定位可全面检测整个基坑区域，过程无缝监测

视频+传感器融合 ：边施工边检测，实时视频、图像监测，可在线查看现场情况

报告生成 ：基坑概况统计、传感器数据、预警列表均可通过手机端查看

辅助决策 ：通过远程实时监控系统等可以建立施工进度和质量管理系统

二、平台特色：

GSI-FM项目一览

由手持端（M/S）和PC端（B/S）构成，使内外业务管理相结合，实现日常监测工作的科学化、规范化、数智化管理。基于大数据平台提炼基坑监测工程各专业指标，形成专题的数据大屏，将数据真实可靠的动态直观展示在BI大屏幕上，用户和决策层可以实时查看基坑工程建筑的进度、重要区域的核心问题，结合智能模型的预测以及分析，辅助决策。

主要功能

①项目列表：可筛选项目测点，查阅水位、位移、压力、沉降、巡检记录、数据时间关系曲线、告警记录情况

②安全状态：实行正常、控制、预警、报警四级预警机制，异常事件上报，快速流转到后台进行统一处理

③地理位置：支持各类地图服务的接入，包括谷歌地图、百度地图、腾讯地图等，可快速定位到需要查找的地段

④完成程度：实行0%-20%、20%-50%、50%-80%、80%-100%四种梯度，可统计各地基坑工程整体完成进度

核心价值

集成展示，资源共享 宏观运营，全知全能

基础支撑，智能监控 实时感知，异常预警

科学评价，数智分析 精确定位，快速补救

GSI-FM项目管理

项目管理包括项目信息详情、项目测点布置、监测情况统计、测斜监测情况统计、监测分区设置及分析、监测剖面设置及分析、项目通信节点管理、项目平面图、项目巡检。系统将基坑监测工程立项、实施、验收等环节的信息及时上图入库，明确项目位置、规模、类型、内容及建设及进展与成效等。综合运用遥感、大数据、物联网、云计算等技术手段进行比对核查，实现实时动态、可视化、可追踪的全程全面监测监管。

主要功能

①项目信息详情：直观显示开挖深度、基坑周长、开挖面积、支护形式、基坑安全等级信息

②项目测点布置：可进行测点分组设置，识别测点名称，分析监测项类型、解算方案、累计值报警、采集频率情况

③监测情况统计：统计分析监测项目的测点从开始时间至结束时间产生的数据情况

④分区设置分析：可进入具体分区查询分区项目进度、工况记录，在详情页可了解测点布置及相应的数据分析情况

⑤剖面设计分析：分析剖面点使用的支护形式、开挖深度、安全等级、土层结构、工况记录情况，可查看测点布置数据分析

⑥通信节点管理：使用组网结构，分析基坑项目使用的采仪器类型，进行节点管理

⑦项目平面巡检：可视化巡检支护结构、施工工况、周边环境、测点情况，智能化监测异常状态

核心价值

①对项目工程信息进行综合管理和辅助决策，实现办公自动化和现代化

②项目完成程度、安全状态、测点情况实时掌控，辅助任务监管与考核

③基坑地图可视化，实时获取监测到的坐标信息，及时发现问题，保障基坑监测质量

④工程资料统一信息化，系统自动成图，内外业务一体化，降低内业整理人工与时间成本

⑤项目资产精细化管理，规范并简化任务处理流程，提高基坑监测入库、异常事件流出效率

GSI-FM设备管理

设备管理包括常规监测仪器、自动化监测仪器和通信节点管理。通过大数据平台提供的基坑监测项目信息、传感器、采集仪器、现场监测数据，利用各业务系统通过人工解译、深度学习自动化解译等方式提取的各类监测指标信息进行综合评价和分析。在工程实施范围内，根据基坑监测目标和标准，建立三级监测评估内容和指标。

主要功能

①常规监测仪器管理：统一规范管理常规监测仪器，按名称、编号、类型、厂商、型号、智能程度归类划分

②自动化监测仪器管理：按传感器、DTUMCU、采集仪器三大类分区管理，按型号、地址、单元、状态等进行划分归纳

③通信节点管理：根据所属部门、关联项目、通信节点名称、物联卡号码、网络类型进行设备管理，并赋予拓扑图进行分析

核心价值

①整合硬件设备状态、智能程度信息等，实现设备管理一张图，宏观把控设备运行状况

②结合常规与自动化仪器设备，提取各类监测指标信息进行综合分析与评估

③根据所属部门、关联项目进行设备管理，打通信息化孤岛

④任务量化管理，人员工作科学评价

⑤维修现场实时反馈，设备 历史 可查阅追溯

GSI-FM预警管理

通过PC端和移动端小程序，实现基坑工程监测预警管理自动化流转与分派，对基坑开挖深度、安全等级、开挖面积、基坑周长、支护形式、项目安全状态、项目完成度、测点安全状态、项目地理位置和项目运行状态进行实时监测，当监测值超过设定预警值时，系统及时反馈告警信息，自动启动现场预警提醒，预防事故发生，减少人员和财产损失。

主要功能

①告警日志：记录整体各个区域基坑工程项目的测点、告警级别、告警详情、发生时间信息

②异常上报：异常事件上报，快速流转到后台进行统一处理

③任务监督：实时了解工作进度，对现有工作情况进行指导，支持日常报表的生成

④视频监控：结合监控视频实时查看施工现场发展状态和工作人员操作情况

⑤辅助决策：可查看异常事件详情、设备维护 历史 、上报现场信息、申请支援等，辅助调度

核心价值

①现场异常及时上报，后台监管快速响应，降低影响

②任务进度实时掌控，统计报表一键生成

③为运维现场提供信息支持，快速查询现场基坑周边情况

④加强现场运维情况的动态监控力度

⑤科学管理应急事件，合理处置突发事件

项目管理系统对企业的价值

项目管理的价值
如果你或你的团队成员想要知道项目管理能带来怎样的结果，可以看看以下切实的好处：
1、有效的项目计划
精心制定的项目计划：
▪ 创建可实现的日程表。         
▪ 改善资源管理。         
▪ 提供跟踪项目进展的基线。         
▪ 带来准确的预算估计值。
另外，对于未来的项目规划来说，来自先前项目的数据是有价值的输入。
2、标准化的工作方式
在缺乏明确的项目方法的情况下，个人会变得有创造力，并发展出自己的工作方式，从而导致一个企业中出现多种风格。
有合适工具支持的标准化项目方法具有这些特点：
▪ 增加项目选择的透明度。         
▪ 使用模板简化项目规划。         
▪ 帮助团队成员在项目之间快速移动。         
▪ 改善团队内部和团队之间的协作。         
▪ 提高可见性和改善报告。         
3、成功的变更管理
变更管理可以提高最终用户对项目创建的解决方案的采用率。解决方案包括使用公司内部网或新的文档管理软件等。当变更管理纳入项目规划并贯穿整个项目，变更管理会使从项目中交付真正的业务价值变得更加容易。
变更管理还降低了范围蔓延或不受控变更对项目的影响。从一开始就让关键利害关系人和用户参与进来，降低了交付不可用产品的可能性。
4、更好的风险管理
使用项目管理流程，团队可以在工作开始之前识别潜在风险。如果这些风险在执行过程中影响了项目，团队可以更快发现和更好地解决问题。
5、提升质量
项目管理有助于使结果符合利害关系人的期望，有助于定期收集反馈，并利用新技术提供更高质量的解决方案。有证明文件的流程还有助于减少错误和返工。
6、加强协作
通过明确的角色、职责和标准化模板，项目管理可以帮助团队快速制定目标，并为实现目标共同努力。
由于每个人都在说同样的“语言”，用同样的工具，因此与其他团队或业务部门协作变得更加容易。
7、提高声誉
随着时间的推移，成功的项目团队会得到同事和经理的认可。企业也会受益于其在竞争对手和未来客户中地位的提高。
8、领导能力
在清晰的愿景下，项目经理团结团队成员，并激励每个人。项目经理可以根据需要指导团队成员，这样他们就能把工作做到最好。
9、新的组织能力
改善项目管理流程不仅与财务收益有关，企业还可以改变内部文化和工作方式。
最好将现代工作描述为一组自我管理的任务，而引入项目管理有助于企业转向关注目标、指标和流程，从而支持这些任务的执行。
项目管理技术
项目规划和跟踪涉及大量动态及相互关联的数据。由于信息的丰富性、动态性、互联性和细节性，信息的复杂程度很容易超出人类记忆、大型白板或Excel等静态电子工具的能力范围。
使用8Manage项目管理软件，充分利用团队的生产力，是明智的选择。现代项目管理软件通常用于项目规划、时间管理、资源分配、预算、实际成本跟踪和变更管理等。

分布式定时任务调度框架实践

分布式任务调度框架几乎是每个大型应用必备的工具，本文介绍实时任务告警指标分析方案了任务调度框架使用的需求背景和痛点，对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践，并分析了这几种框架的优劣势和对自身业务的思考。

一、业务背景

1.1 为什么需要使用定时任务调度

（1）时间驱动处理场景实时任务告警指标分析方案： 整点发送优惠券，每天更新收益，每天刷新标签数据和人群数据。

（2）批量处理数据： 按月批量统计报表数据，批量更新短信状态，实时性要求不高。

（3）异步执行解耦： 活动状态刷新，异步执行离线查询，与内部逻辑解耦。

1.2 使用需求和痛点

（1）任务执行监控告警能力。

（2）任务可灵活动态配置，无需重启。

（3）业务透明，低耦合，配置精简，开发方便。

（4）易测试。

（5）高可用，无单点故障。

（6）任务不可重复执行，防止逻辑异常。

（7）大任务的分发并行处理能力。

二、开源框架实践与 探索

2.1 Java 原生 Timer 和

ScheduledExecutorService

2.1.1 Timer使用

Timer缺陷：

由于上述缺陷，尽量不要使用Timer， idea中也会明确提示，使用ScheduledThreadPoolExecutor替代Timer 。

2.1.2 ScheduledExecutorService使用

ScheduledExecutorService对于Timer的缺陷进行了修补，首先ScheduledExecutorService内部实现是ScheduledThreadPool线程池，可以支持多个任务并发执行。

对于某一个线程执行的任务出现异常，也会处理，不会影响其他线程任务的执行，另外ScheduledExecutorService是基于时间间隔的延迟，执行不会由于系统时间的改变发生变化。

当然，ScheduledExecutorService也有自己的局限性：只能根据任务的延迟来进行调度，无法满足基于绝对时间和日历调度的需求。

2.2 Spring Task

2.2.1 Spring Task 使用

spring task 是spring自主开发的轻量级定时任务框架，不需要依赖其他额外的包，配置较为简单。

此处使用注解配置

2.2.2 Spring Task缺陷

Spring Task 本身不支持持久化，也没有推出官方的分布式集群模式，只能靠开发者在业务应用中自己手动扩展实现，无法满足可视化，易配置的需求。

2.3 永远经典的 Quartz

2.3.1 基本介绍

Quartz框架是Java领域最著名的开源任务调度工具，也是目前事实上的定时任务标准，几乎全部的开源定时任务框架都是基于Quartz核心调度构建而成。

2.3.2 原理解析

核心组件和架构

关键概念

（1） Scheduler ：任务调度器，是执行任务调度的控制器。本质上是一个计划调度容器，注册了全部Trigger和对应的JobDetail， 使用线程池作为任务运行的基础组件，提高任务执行效率。

（2） Trigger ：触发器，用于定义任务调度的时间规则，告诉任务调度器什么时候触发任务，其中CronTrigger是基于cron表达式构建的功能强大的触发器。

（3） Calendar ：日历特定时间点的集合。一个trigger可以包含多个Calendar，可用于排除或包含某些时间点。

（4） JobDetail ：是一个可执行的工作，用来描述Job实现类及其它相关的静态信息，如Job的名称、监听器等相关信息。

（5） Job ：任务执行接口，只有一个execute方法，用于执行真正的业务逻辑。

（6） JobStore ：任务存储方式，主要有RAMJobStore和JDBCJobStore，RAMJobStore是存储在JVM的内存中，有丢失和数量受限的风险，JDBCJobStore是将任务信息持久化到数据库中，支持集群。

2.3.3 实践说明

（1）关于Quartz的基本使用

（2）业务使用要满足动态修改和重启不丢失， 一般需要使用数据库进行保存。

（3）组件化

（4）扩展

2.3.4 缺陷和不足

（1）需要把任务信息持久化到业务数据表，和业务有耦合。

（2）调度逻辑和执行逻辑并存于同一个项目中，在机器性能固定的情况下，业务和调度之间不可避免地会相互影响。

（3）quartz集群模式下，是通过数据库独占锁来唯一获取任务，任务执行并没有实现完善的负载均衡机制。

2.4 轻量级神器 XXL-JOB

2.4.1 基本介绍

XXL-JOB是一个轻量级分布式任务调度平台，主打特点是平台化，易部署，开发迅速、学习简单、轻量级、易扩展，代码仍在持续更新中。

主要提供了任务的动态配置管理、任务监控和统计报表以及调度日志几大功能模块，支持多种运行模式和路由策略，可基于对应执行器机器集群数量进行简单分片数据处理。

2.4.2 原理解析

2.1.0版本前核心调度模块都是基于quartz框架，2.1.0版本开始自研调度组件，移除quartz依赖 ，使用时间轮调度。

2.4.3 实践说明

详细配置和介绍参考官方文档。

2.4.3.1 demo使用：

@JobHandler(value="offlineTaskJobHandler") ，实现业务逻辑即可。（注：此次引入了dubbo，后文介绍）。

（滑动可查看）

示例2：分片广播任务。

（滑动可查看）

2.4.3.2 整合dubbo

（1）引入dubbo-spring-boot-starter和业务facade jar包依赖。

（滑动可查看）

（2）配置文件加入dubbo消费端配置（可根据环境定义多个配置文件，通过profile切换）。

（滑动可查看）

（3）代码中通过@Reference注入facade接口即可。

（滑动可查看）

（4）启动程序加入@EnableDubboConfiguration注解。

（滑动可查看）

2.4.4 任务可视化配置

内置了平台项目，方便了开发者对任务的管理和执行日志的监控，并提供了一些便于测试的功能。

2.4.5 扩展

（1）任务监控和报表的优化。

（2）任务报警方式的扩展，比如加入告警中心，提供内部消息，短信告警。

（3）对实际业务内部执行出现异常情况下的不同监控告警和重试策略。

2.5 高可用 Elastic-Job

2.5.1 基本介绍

Elastic-Job是一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成。

Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。

Elastic-Job-Cloud使用Mesos + Docker的解决方案，额外提供资源治理、应用分发以及进程隔离等服务。

可惜的是已经两年没有迭代更新记录。

2.5.2 原理解析

2.5.3 实践说明

2.5.3.1 demo使用

（1）安装zookeeper，配置注册中心config，配置文件加入注册中心zk的配置。

（滑动可查看）

（滑动可查看）

（2）配置数据源config，并配置文件中加入数据源配置。

（滑动可查看）

（滑动可查看）

（3）配置事件config。

（滑动可查看）

（4）为了便于灵活配置不同的任务触发事件，加入ElasticSimpleJob注解。

（滑动可查看）

（5）对配置进行初始化。

（滑动可查看）

（6）实现 SimpleJob接口，按上文中方法整合dubbo, 完成业务逻辑。

（滑动可查看）

2.6 其余开源框架

（1） Saturn ：Saturn是唯品会开源的一个分布式任务调度平台，在Elastic Job的基础上进行了改造。

（2） SIA-TASK ：是宜信开源的分布式任务调度平台。

三、优劣势对比和业务场景适配思考

业务思考：

四、结语

对于并发场景不是特别高的系统来说，xxl-job配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。希望直接利用开源分布式框架能力的系统，建议根据自身的情况来进行合适的选型。

附：参考文献

高可用架构

改变互联网的构建方式

流批一体不只有Flink，还有实时数据模型

通常来讲，数据仓库的建设，都是以离线作为主要的密报，下游的应用，不论是报表还是接口，所提供的数据也大多是T-1时效性。

但伴随着业务的变化，当离线做到没什么可以继续做的时候，实时就会被拿出来，作为新一个阶段的目标进行攻克。

在流批一体建设之前，这种实时诉求通常会开发成分钟级的任务，通过近实时的方案来解决业务的问题，但分钟级会带来诸如任务过多、资源挤占较大、无法支持复杂逻辑等问题。

因此专门支持实时计算的框架，比如早期的Storm，能够尝试从纯实时的角度解决业务问题，就被拿出来作为尝试。然而Storm的局限性也很大，因为那会的任务开发只能通过Java的方式来进行，与Hive所推崇的纯SQL方案相比，上手难度大了不少，同时两套代码的逻辑几乎没有可比性，这种方案也就一直没有什么声音。

尽管实时技术有各种缺陷，但作为一种能够很容易讲清楚价值的项目，同时又非常便于向上汇报的技术方案，实时技术还是被或多或少的做了起来。在大多数的公司里，实时和离线就会有不同的团队进行维护，或者是同一个团队，但分成不同的项目来执行。这个阶段，优先高效的把业务做起来，哪怕场景再简单，但能够证明实时有价值和前景，这个阶段的目标就算完成了。

以上的各种方案，难免会带来三个特别难以解决的问题：

（1）数据的口径上，实时和离线很容易不统一；
（2）数据模型的规范上，实时和离线也往往是分开建设；
（3）即便是同一种口径和同一种规范，实时和离线也要分成两套代码来维护。

这三个问题短时间内会被高速发展掩盖掉，但当业务对实时的诉求越来越多、压力越来越大的时候，口径和代码的不统一，就会越来越成为阻碍敏捷开发的障碍，需要有方案进行解决。

后来Flink出现了，带来了流批一体的全新方案，这个问题便出现了解决的曙光，这也比较接近我们对于实时计算的理想方案，因为其意义堪比Hive，也成为了各个大厂面试的标配问题。

然而，仅仅学会Flink是不够的，因为流批一体带来的并不仅仅是技术方案或者是框架的改变，同样带来了数据模型的改变，这就要求我们从数据模型上，而不是技术方案上，来制定我们的实时方案。

那么我们如何理解“实时数据模型”这件事情呢？

通常而言，我们关心的内容，包括如下几个方面：

（1）实时数据源与离线数据源存在差异，导致相同的字段，取值或者类型会存在不相等的情况；
（2）实时和离线由于底层执行机制的不同，通常需要维护两套代码，会带来诸如口径不统一、质量检测难的问题；
（3）产品逻辑变化较快时，离线模型修改相对容易，但实时模型需要考虑压测、削峰、重启等技术问题，维护成本非常高昂。

数据仓库之所以能够普及并被业务接受，正是因为其模型能够屏蔽掉底层差异的问题，并且有相对可靠的数据质量监控方法，并且变更成本非常低。而实时数仓如果想要替代掉离线数仓，以上的问题通常是需要一些模型设计甚至是平台工具的来解决，这些问题解决的重要性，并不比Flink弱。

我们先从比较可控的模型层面说起。

在离线的概念里，数仓模型设计成了DWD/DWS/ADS三个层级，原本的概念是DWD面向事实表的构建，DWS面向公共指标的统一，ADS负责灵活的口径变化问题。

在离线的概念里，DWD/DWS/ADS三个层级需要保留，但负责的目标会有一些变化，同时还需要增加存储统一层，也就是以TiDB/Holo为代表的数据库，来承担服务分析一体化的诉求。

让我们先看DWD层，DWD承担了屏蔽实时离线链路差异的问题，最重要的作用是保证表结构的统一及字段内容的对齐。DWD最重要的意义，是保证离线表和实时表，其表结构和字段概念是相同的。

为什么这么强调？试想一下，在离线场景下，我们可以在DWD上灵活的增加各种统计标签，或者是将维度退化到事实表，都是一些left join或者是服务端直接打标可以解决的事情。但在实时场景下，这会变成多流join或者是缓存等更复杂的技术场景，导致这些信息并不能有效的记录到DWD，因此DWD的设计就要产生一些变化，有一些内容在实时场景下无法准确记录，这一类信息需要标识到对应的字段描述上，下游使用时才不会出错。

同时，实时和离线存储数据的介质，也必然有一些区别。例如离线可以存在HDFS上，实时则可能视情况保存在数据库、HDFS甚至是内存中，这时候对于字段格式、读取方式都会有差异，设计表时其约束条件也会更多。

因而，DWD更多承担了逻辑统一的职责，依旧以事实表为基础，但约束条款要比离线更多。

再看一下DWS层，离线上DWS是负责口径统一的重要一环，将通用的维度和口径计算方法抽象出现，以提供跨数据域的灵活使用。但在实时场景下，这一类的维护收益通常都比较低，不仅因为实时只看当天的数据，也是因为实时本身的维度难度就较大，多一层模型其收益会急速下降，因而大多数时候会忽略掉DWS的建设，ADS直接引用DWD进行统计。

然而，DWS毕竟存储的内容要比DWD少很多，因此如果计算资源瓶颈非常明显，或者是业务场景不需要分析实时明细数据的情况下，或者是DWD的下游引用过多时，DWS可以承担削峰的重任，通过减少数据量以应对大促等场景，还是有一定意义的。

接下来就是最重要的ADS层，在这一层上，逻辑统一、口径统一、大促削峰在前置模型上都得到了一定程度的解决，ADS则像离线一样承担了应对需求变化的重任。

但ADS所面临的情况和离线还是有所不同的，因为ADS的任务启动，不仅要启动一个离线的跑批任务，还要同时启动一个实时的流式任务，而ADS往往会同时统计离线+实时的结果，以应对同比、环比等场景。

这时候很多具体Case要具体分析了，因为特定场景的坑会非常多。例如最常见的“同比”，要对比今年和去年的结果变化，离线往往会统计分小时的结果，但实时会累计起始时刻到当期时刻的结果，因而当一个小时没有结束的时候，这个同比的波动变化会非常大，给人一种“数据是错误的”印象，新手很容易踩这个坑，从而被业务质疑。

因此，针对累计统计指标，从代码设计上就要考虑到这种情况，都根据时间字段统计起始到当前时刻的结果的，在代码逻辑上会要求一些统计技巧。

很多时候，因为业务指标变化太快，改实时代码是来不及的，这时候一部分的工作量甚至需要报表工具的数据集来解决，改动查询sql，要比改动任务来的快捷多了。但这部分的能力，其实是依赖于存储工具的，个人认为可以分到存储统一层来解决。

最后是存储统一层，因为一些特殊的场景，比如实时分析明细数据，或者是不确定时间周期的多天统计结果，如果依赖Flink SQL来解决是有些不现实的，因而这部分的压力需要数据库来承担。

简单讲，就是将明细做轻度的汇总后，直接写到数据库，实时更新，下游自定义条件，并直接读库统计结果。这种场景既要求数据库有OLAP的计算能力，也要有OLTP的稳定特点，因而TiDB和Holo这一类HTAP的引擎就变得非常重要。

因为多了实时的部分，因此过去面向离线的开发工具，也需要有一些特定的改造，以适应实时的开发和运维诉求。

对于开发工具而言，其目标集中在四个场景上：元数据定义与获取、数据建模、开发与测试、运维与监控。

其次讲数据建模，因为建模的理论已经稳定了有些年头了，绝大多数场景下都是按照既定的方案来执行。过去离线当道时，规范执行的弱一些不是什么大问题，但流批一体当道的年代，规范是需要强约束的，这就对了开发工具提出了一定的要求，是否能够从平台层面上对规范进行内置，并以此来约束开发的同学，降低不规范模型对后期维护带来的压力。

这种建模能力的代表有两种，一种是规范表的命名，填写相应的分层+主题域+数据域+统计刷新方式，从源头上规范表的目标和作用；一种是规范指标的定义和使用，例如原子指标还是派生指标，统计周期多少，业务限定用语如何规范，统计粒度怎么填写。

在实际开发中，通过工具的限制，如果规范可以做的好，代码是可以自动生成出来的。当然，以上的功能，都属于通过牺牲开发效率，来提升数据质量的范畴，使用时需要根据团队的情况来限定。

再次是开发和测试，这是平台提供的最重要的能力。在开发层面，就是代码的预编译能力+发布功能。预编译不仅要检查代码的逻辑是否正确，同时对于代码中依赖的其他数据源，获取到的元数据信息是否准确，至少字段的命名不会有大的问题。当代码预编译通过，发布上线后，还需要检测当前是否有资源支持任务启动，并且上游的消息队列是否是启动的状态。

实时的测试一直都是比较大的问题，它不像离线可以启动一个SQL任务看看结果，实时在每个阶段的输入和输出，是需要通过平台支持的日志打印功能来进行辅助的。很多时候我们会新建一个测试专用的topic来测试结果，但对于流量较大的线上任务而言，这种方式无法像离线区分Dev环境一样，能够对资源进行隔离，因而如果能够支持圈定数据的输入和打印输出，对于测试的效率而言无疑是最佳的。

最后要提到的是运维与监控能力。运维能力是指根据输入的RPS，或者是cu使用情况，或者是任务的整体延迟，提供相应的参数调优能力，通过参数来调整任务的执行情况。并且能够根据以上指标的变化，自定义相应的阈值，提供相应的告警能力，通过短信或者是消息工具的方式触达任务维护者。

实时与离线有一些不同的是，离线可以通过增加一个监控节点的方式，通过group by判断数据是否重复，而实时任务则非常依赖Flink自身的一致性能力，因而发现和解决问题的成本更高。

其实做到运维这个环节，对人的要求其实是更高的。因为流批一体在运维上会带来一个好处，即实时任务和离线任务能够错峰执行，实时在白天压力大，而离线在晚上压力大。但同样的，这种方式对于维护者而言更加痛苦，因为不仅晚上要熬夜值班，白天同样不能休息，在大促期间甚至需要轮班来维护任务，可以说是“汇报一时爽，痛苦长相伴”。

从远处来看，流任务和批任务，在自身的机制上就存在非常大的差异，批程序面上的是特定时间内相对静态的数据，而流程序处理的则是change-log，虽然有可能数据在表结构层面，通过数据模型的设计来保持一致，但是在语义层面，其根本还是不一样的。这一点可能是最制约批流一体发展的问题，也是最难实现统一或者永远也不可能统一的。

综上，对于实时模型，开发工具需要将监控实时部分的能力进行补全，就像DWD层需要分别维护实时和离线两套架构一样，开发工具也需要分别维护两套架构的结果，因而现阶段的实时开发，还做不到降低维护和开发的成本，只能减轻其中部分环节的工作量。

以上讲了很长时间的实时模型，但从实际的效果上看，业务并不会感知到多么明显的技术变化，相反会有一种“面子工程”的感觉在里面。

当然，我并不否认实时的价值，在“搜广推”这三个技术占主导的领域内，作用还是很大的。但实时毕竟要比离线的内容，更加的难以理解，出现问题的排查成本也更高。这种复杂性使得我们在应对变化时，往往做不出有效的应对，就会变得特别被动。

因而，说一句事后的话，就是“实时的价值取决于业务方，而不是技术方”。只有业务对实时痛点强烈的场景下，我们做如此复杂的研究和应对，才能体现出自己的价值，更多的时候，是在“王婆卖瓜，自卖自夸”。有这种投入，还不如多招几个分析师更靠谱和实在。

本人之前的文章《天下数据，唯快不破》，重点强调了一个“快”字。但“天下熙熙皆为利来，天下攘攘皆为利往”，这个快更多的是在讲应对“变化”的快，而不是“技术”自己的快。

所以，为了以后的职业发展，我们要跟进实时技术的变化，但从自身的工作角度出发，如何应对业务的变化，才是自己要关心的课题。 关于实时任务告警指标分析方案和实时告警包是什么的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 实时任务告警指标分析方案的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于实时告警包是什么、实时任务告警指标分析方案的信息别忘了在本站进行查找喔。