农业银行总行门户网站建设,一个企业网站文章多少适合,风景旅游网站建设的设计思路,网络公关公司联系方式简介#xff1a;报警是一个公司的日常需求#xff0c;常见的形态除了满足运维过程中的基础设施监控报警#xff08;CPU/内存/磁盘等#xff09;之外#xff0c;部分公司也会在应用指标#xff08;如 QPS、RT 等#xff09;及业务指标#xff08;如 GMV/日活 等#xf…简介报警是一个公司的日常需求常见的形态除了满足运维过程中的基础设施监控报警CPU/内存/磁盘等之外部分公司也会在应用指标如 QPS、RT 等及业务指标如 GMV/日活 等上有相应的报警需求。
作者 | 黄晓萌
01 问题背景
报警是一个公司的日常需求常见的形态除了满足运维过程中的基础设施监控报警CPU/内存/磁盘等之外部分公司也会在应用指标如 QPS、RT 等及业务指标如 GMV/日活 等上有相应的报警需求。
在业务发展初期基础设施较少且应用形态单一所以处理这一类需求往往会比较粗暴直接但是随着业务的增长尤其发展到日活百万甚至上亿级的时候监控指标也会呈指数级上涨在这种情况下对于报警体系就提出了巨大的挑战如何解决这种体量下报警的有效性和时效性就成为了 IT 治理的重中之重。本篇文章我们将从监控指标的体量出发详解各个阶段报警体系中遇到的各个挑战。 02 一次常规的报警流程示意图
如下图所示一次常规意义上的报警流程主要会包含并发检查、齐全度检查、数据追补、阈值判断等核心环节。同时为了保证报警的时效性基本上整个流程会是一个秒级触发的形态具体如下 其中报警后台任务处理系统是我们这次讨论的重点几个核心流程的说明如下
并发检查检查当前告警规则是不是在其他进程或者节点中执行中避免有些告警规则检查耗时过长被重复执行了或被其他的任务节点抢占执行。齐全度检查获取当前告警规则对应的数据源的齐全度时间即最新数据上报到什么时间了。因为数据源数据采集和上报一定会有延时的如果数据不齐就进行检查很容易漏报和误报。数据查询从监控数据中获取该规则的数据一般会从收集上来的日志服务如ElasticSearch 服务等或者基础监控指标存储服务如Zabbix、Prometheus 等中获取。数据追补由某些报警任务设置的策略没有数据点的情况下怎么处理。有补0补满和不补三种。如在针对业务数据跌零报警的场景我们会更倾向于补 0 但是针对 CPU 平均值超 80% 的场景我们会倾向于不补。阈值判断根据获取的数据和报警条件判断是否需要触发报警。告警将告警信息通过短信、钉钉、邮件等方式通知到配置的人以便后续有人处理。
03 进程内调度方案
一开始的业务很少的时候报警任务也趋于少数这个时候一般的实现都会基于一个进程内的线程池执行相关的操作架构图如下 把上图的“后台任务处理系统”放到一台机器上运行能很快速的满足小规模的场景。但是等到业务量持续上涨的时候一台机器就出现了资源瓶颈这个时候一个下意识的反应就是扩容上面的任务处理系统让不同的 Server 处理不同的报警规则。但是随着报警规则在不断增加负载的持续上涨会引起 Server 也会重启或者突然挂掉。于是高可用、任务幂等执行、failover 等分布式问题又是面临的一个复杂的难题。
04 分布式调度解决方案
如果任务数达到万级别寻求一个轻量的分布式的方案是我们的目标。分布式调度方案的基本思路都是通过单独的任务调度中心来调度任务报警后台只管执行任务即任务调度和任务执行隔离的思路使得两层都能做很好的横向扩容来达到容量上涨的目的。业务实现上每个报警规则会生成一个定时任务这样可以保证每个报警规则负载均衡地执行。开源市场有挺多产品比如Quartz、xxl-job、elastic-job 等。以 quartz 为例示意图如下 如上图所示quartz 的每个 Server会加载全量的所有任务每次任务时间到了所有 Server 会通过数据库抢锁抢到锁的 Server 触发该任务给报警中心。
这个架构解决了任务的分布式调度、幂等执行的问题并且执行层可以水平扩展在任务量低的情况下可以稳定运行。
可是从上面的架构图可以看出Quartz 的调度主要通过轮询 DB 和通过 DB 加锁的方式而实现这个时候整个系统的吞吐基本上和 DB 的规格和性能息息相关。经测试如果在任务量调度频率 1 分钟级别的触发达到1万就会出现比较明显的调度延时。
05 基于 SchedulerX 2.0 的超大规模任务调度方案
1、SchedulerX 2.0 优势
SchedulerX 2.0 是阿里巴巴自研的一款商业化分布式任务调度平台相对于开源任务调度系统它有几大优势
支持海量任务自研轻量级分布式跑批模型可视化任务编排商业化报警可视化日志服务SchedulerX2.0 基础架构图
与常见方案相比SchedulerX2.0 会将任务分布式到不同的 Server 调度每次任务调度也不需要抢锁触发和数据库无任何交互没有性能瓶颈。
2、高可用能力
在分布系统中最常见的就是高可用问题如果 SchedulerX 2.0 的某个 Server 挂了会怎么办 如上图所示每个应用都会做三备份通过 zk 抢锁一主两备如果某台 Server 挂了会进行 failover由其他 Server 接管调度任务。 3、商业化报警
SchedulerX 2.0 当前支持钉钉、短信、邮件三种报警通道 支持任务失败、超时、无可用机器报警 以钉钉告警为例您可以实时收到报警 06 总结
SchedulerX 2.0 在阿里巴巴集团内支撑了所有事业群的业务经历了多次双十一的考验当前在公有云已接入1000家企业在海量任务和高可用方面有充足的经验。显然在超大规模任务调度领域SchedulerX 2.0 已经是目前最优解决方案之一。
原文链接 本文为阿里云原创内容未经允许不得转载。
