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

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

本文目录一览：

• 1、运营指标与告警策略思考
• 2、Flink Metrics指标采集方案
• 3、深基坑安全监测系统的监测指标一般是哪些？
• 4、分布式定时任务调度框架实践

运营指标与告警策略思考

一、运营指标

用户指标数据 ，通过可以衡量用户体验的的核心行为表现数据指标来衡量效果

业务性能监控， 各API状态等后台不可见的算法流程和内容

举例：

新闻产品： 首页推荐结果的点击率、各类新闻的占比等（拟合推荐策略效果）

电商产品 ：单店日销售额、促销产品影响面（评估促销收益比）

云服务产品： 云服务可用率、云服务作业成功率

游戏产品： 业务规则监控（用户胜率、攻击频率上限）、系统可靠性监控

由于业务规则监控取决于业务方自己的业务属性较多，下文举例系统可靠性监控。

【1】请求数，请求到达速率

【2】正常响应数，正常响应占比

【3】错误响应数，错误响应占比

【4】响应延时

【5】消息队列长度，排队堆积时间、消息量

互联网系统根据计算机网络模型，可靠性监控可以分为下面4层。

【1】 应用层 ：用户访问的前端页面、后端接口请求

【2】 服务层 ：db，中间件等各种进程

【3】 硬件层 ：cpu，内存，磁盘，网络

可靠性监控思考：

【1】不应该用采集的难度决定你使用什么指标去告警。

例如：很多情况下cpu使用率可能是最好采集的，但是未必是最值得告警的。

【2】不要给运维他们想要的告警，而是要做“真正”想要的告警。

例如：运维告诉你它需要对db进程的cpu使用率超过x%的时候告警，它给你的是一个他认为最优的解决方案。但是他真正想要的是知道db服务是否有异常，cpu使用率超过x%未必是最好的告诉你服务是否出现异常的指标。
二、规则告警

告警规则 ：根据历史数据定义一个正常波动区间，超出波动区间就报警。

告警策略主要字段： 名称、资源类型、监控对象、告警级别、告警策略（根据资源类型展示不同的数据信息）、监控指标对象、告警指标间处理逻辑、触发条件、告警频率、状态、最近改变时间

吿警方式 ：

短信、电话 ：成本高，实时性好，到达率高

办公APP ：成本低，实时性中，到达率中

邮件 ：成本低，实时性差，到达率高

告警收敛：

【1】服务运营指标收敛 策略：按服务名、运营指标去重

【2】模块告警收敛 策略：按照集群名称做去重

【3】接口告警收敛 策略：按照接口名称做去重

【4】告警频率收敛 策略：按照M分钟N次限制告警

【5】不同时段区分告警 方式策略：工作日/非工作日，白天/夜晚区分

【6】逐层上报 告警策略：先模块负责人告警，n分钟未恢复升级，m分钟未恢复再升级

【7】黑白跳动 策略：当系统由正常变为异常，异常恢复正常都通报

是否告警：

曲线平滑 ：故障一般是对近期趋势的一个破坏，视觉上来说就是不平滑

绝对值的时间周期性 ：静态或者动态设置最近一段时间的最低值、最高值

波动的时间周期性 ：假设两个曲线不重合，在相同时间点的波动趋势和振幅也是类似的（即不同时间段的上、下限值的差是一致的）

波动回归正常值 ：当曲线开始回升到历史范围的时候，一般可以确认这个时间段是真的故障了。同时也可优统计误警率，漏警率。

告警自动消除：

告警的实质就是“ 把人当服务用 ”。在一些事情还没有办法做到程序化执行的时候，用告警通知人的方式去干预系统达到修正的目的。后续通过收集异常问题，并制定相应的自动化解决方案，实现告警的自动消除。
三、产品画像

产品画像，可以结合已有的运营指标、研发指标、部署指标、故障指标去实现云服务产品画像。

在选取指标时，需要注意：

【1】指标真实有效，即服务可用率，故障率等指标的归属责任方式明确的

【2】指标同步时，明确指标状态、流程，避免数据在同步过程中变为2份数据。一般也采用ETL离线同步的方式，结合全量表同步与增量表同步。

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同时满足监控大盘需求及指标数据长期存储和二次加工分析，该方式优势指标数据源统一，任务大盘及告警

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

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

深基坑安全监测系统的监测指标一般是基坑土体、支护结构、自然环境和周边环境等。广东地空智能 科技 有限公司开发的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.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配置部署简单易用，不需要引入多余的组件，同时提供了可视化的控制台，使用起来非常友好，是一个比较好的选择。希望直接利用开源分布式框架能力的系统，建议根据自身的情况来进行合适的选型。

附：参考文献

高可用架构

改变互联网的构建方式

关于实时任务告警指标分析和实时告警包是什么的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 实时任务告警指标分析的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于实时告警包是什么、实时任务告警指标分析的信息别忘了在本站进行查找喔。