目前业界大部分运维系统或者监控系统使用的都是IBM Omnibus产品，到现在也有很多金融机构在使用该产品，它是一个基于内存的支持SQL的报警处理引擎，它的最大问题就是单节点、单进程运行，所以对于大数据量的处理存在瓶颈。虽然在之前几年一直是处于业内的领先水平，但随着现在国内的企业架构复杂化，其处理能力就显得有些捉襟见肘了。再加上国家现在对于信创的要求，因此急需一款能够替换OMNIBUS产品的国有软件产生。而这就得力事件处理引擎（DELI_UEP）产生的由来。
我们在设计DELI_UEP的时候，考虑到了以下几点：
1）事件采集和处理要解耦，这样能够保证采集器的采集时效性
2）事件处理集中化，规则、外部对象资源都要加载，通过集中处理可以更加充分的利用资源，一次加载重复使用。
3）事件处理分布式，处理集中之后就要有分布式处理可水平扩展的能力。
4）分布式内存数据库，针对报警反复读写数据库的情况，这是从性能角度考虑。
5）对SQL的支持好，数据库的访问就能非常灵活和简洁，监控报警规则就更容易实现。
6）去商业化，自主构建。基于开源软件构建，能够最大程度满足管理要求。
上图是报警处理引擎的功能架构图，包括接入层、处理层、APP管理层、数据管理层和接口层。其中的重点是处理层，分为两大类的处理功能，下层是报警流处理，上层是报警的批处理。这些处理功能模块是动态加载和可扩展的，是在App管理层采用应用商店的模式，进行发布和编排的App。在我们的报警引擎中，将每个处理功能都作为一个App来管理。通过这样的灵活管理和部署的架构，满足报警处理的各种需求。
目前报警处理引擎正在运行的处理功能，包括一些基本的处理功能，比如报警丰富、报警压缩 、恢复关联、自动升降级、维护期等。在智能化报警方面，主要的处理功能用于报警的根因和影响分析，实现了根因升级和受影响报警的自动降级，场景包括如服务器宕机、应用服务拥堵、DWDM中断等异常场景。
由上图可以看出，DELI_UEP整体的性能效果比原有的OMNIBUS要强上许多，他还具有以下特性。特性包括：分布式处理、高可用；完全兼容之前IBM omnibus的处理规则，可以平滑过渡；支持App热部署热插拔；App可编排、调度和协作；扩展性强，支持自定义App开发和部署以及SQL函数扩展；高并发、高性能；支持告警链路追踪和处理性能统计；支持全备+增量的备份方式；支持多数据中心主备模式部署。
如果您对OMNIBUS的替换方案感兴趣，可以随时和我们联系。
联系人：郑雄
电话：13601393264
邮箱：zhengxiong@deliverservice.com.cn