一种基于ES的运营商告警检索方法

一种基于ES的运营商告警检索方法

杨勋城,   ,陆恩波

中国移动通信集团贵州有限公司   贵州贵阳   550000

摘要：针对通信运营商海量告警数据的查询，现有技术是基于传统的关系型数据库方式进行查询，但其查询效率低、速度慢，且往往会因为对数据库的压力大而造成系统实时告警处理功能受到极大影响，一直以来没有特别好的解决手段。本文基于ES技术的运营商告警数据检索方法，融合了关系型数据库和ES的优点，同时增加应用层与数据层读写分离和ES差异化屏蔽机制，既解决关系型数据库性能瓶颈，又提升运营商告警检索和分析效率，达到快速查询和分析告警目的。

关键词：通信运营商；关系型数据库；ElasticSearch；集中故障管理平台；数据检索

一、概述

随着通信业务的快速发展，越来越多的专业网管OMC/EMS或者网元，每天都会产生大量的告警数据。同时，上层的应用系统每天需要处理几PB，几百PB级的告警数据。目前告警实时表的数据量每天大约有600多万，移除进程每隔一小时会从告警实时表中把大约20万的告警从实时表移到告警历史表中。告警历史表是月表，每个月的数据量大约是12000多万。同时应用系统查询告警需要跨几日、跨周、甚至可能跨月。

以现有的传统方法，一般是通过限定查询功能时间段的方式来规避该类问题，如果需要查询较长时间段的告警，就需要经过多次查询、导出操作，最后还需要对多次导出的告警数据结果进行人工整合,以获取最终的结果。所以该实现方案存在以下缺点：

1、告警数据组合较多，查询过滤条件关联字段多且复杂。虽说传统关系型数据库可以通过建索引方式来加快查询速度，但这么多组合条件，需要建很多索引，索引多了，也会降低数据的插入和更新效率，导致业务系统异常。

2、庞大的数据量，反复多次的查询，数据库承受着较大的负荷压力，也是导致目前历史告警查询、导出缓慢的原因之一。

3、在传统关系型数据库中，通过like “%”进行模糊匹配查询，是要进行全表扫描，无法走数据库索引。而告警历史查询、导出，确需对告警标题做模糊匹配。目前库表的数据量，如果是全表扫描，是非常耗费时，实操应用中，最少需要40秒才能查询出结果，更甚会查询不出结果，导不出数据。

综上所述，究其原因是没有一种切实高效的检索方法，如何便捷地检索和分析运营商告警信息，该难题已成为当前告警检索效率提升过程中亟待解决的问题。本文提出基于ES的运营商网络告警数据检索方法，融合到集中故障管理管理系统中，以解决传统方案存在的问题，支持快速检索、分析所需的告警信息，提升了日常告警信息维护管理工作的效率，从而解决关系型数据库性能瓶颈，提升告警查询效率，达到快速查询和分析告警目的。

二、基于ES的运营商告警检索方法

ElasticSearch （本文成为：ES）是一个分布式、高扩展、高实时的搜索与数据分析引擎，它能很方便的使大量数据具有搜索、分析和探索的能力。ES 的实现原理主要分为以下几个步骤，首先用户将数据提交到ES数据库中，再通过分词控制器去将对应的语句分词，将其权重和分词结果一并存入数据，当用户搜索数据时候，再根据权重将结果排名，打分，再将返回结果呈现给用户。

本文基于ES的运营商告警数据检索方法，具备全文搜索，结构化检索，搜索纠错，搜索推荐等功能优势。其检索主要步骤如下：

1、目标用户向搜索引擎ES发起查询请求；

2、对查询请求和历史查询集群进行匹配，所述的历史查询集群是指历史查询请求的集合；所述的匹配，分为两种情况，一种是完全匹配，另外一种是不完全匹配；

3、若完全匹配，则根据历史查询结果和继续查询的结果得出第一结果，若不完全匹配，则重新执行查询得到第二结果，将查询的第一结果或第二结果反馈给用户；

4、对于不完全匹配的查询，则将本次查询的第二结果更新至历史查询集群中，可以理解为查询结果记忆功能。

运营商实时告警从采集到接收处理，经过告警标准化、告警工程标准、告警排重、告警关联、集客业务关联等各个处理环节后推送至kafka队列；同时告警派单、告警预处理、告警通知等告警处理环节处理完成后发生告警变更消息也入kafka集群。

ES库采用多集群的方式，具有两方面的优势：一方面实现高可用，避免单点故障引起的系统拥塞；另一方面实现负载均衡，提高数据查询效率。

进入kafka集群的告警数据需要与快搜的ES库、上层应用之间的对接，其中ES同步程序从kafka接收告警入ES集群，上层应用对接ES则需适配RESTful、dubbo两种接口交互协议的任意一种即可。

目前中间的ES集群是基于现有技术直接部署，其余包括但不限于ES实时同步、ES与关系型数据库定时同步、ES-SQL-Proxy均等模块均需要进行上层改造。

告警数据检索关键技术架构图如“图1”所示：

图1：告警数据检索关键技术流程

其分层处理逻辑如下：

第一层：数据接入层，主要用于网络告警数据获取，网络告警数据创新性的实时入库程序从KAFKA获取实时处理完成的告警数据，并实时入库；同时通过与系统的RDB原始库的数据进行定时比对，将状态不一致的告警通过定时程序进行批量导入。两个通道的告警数据获取和同步机制保证了整个ES库中网络告警数据的实时性和准确性，从而为上层告警检索应用提供数据质量保障。

第二层：数据处理层，完成网络告警数据处理，基于第一步的同步采集获取的数据，如何进行数据存储和处理则尤为重要。基于ES技术将网络告警数据进行集群化部署存储，即通过对ES库做集群的方式对系统进行设计，在网管应用系统中同时运行两个以上的同源ES库对告警数据源的复制存储，保证系网络告警数据的分类存储。基于SQL-Proxy技术将不同的ES库做SQL-API处理，将类似SQL语句解析换成ES的API接口进行调用，确保应用层调用数据的时效性和安全性。

第三层：数据适配层，通过SQL-Proxy技术间接调用ES接口来检索查询告警数据。这样的机制保证了在某个集群出现故障的情况下，能够自动关联匹配到其他ES集群，保证应用能够快速查询到指定数据。

第四层：数据应用层，主要用于上层应用诸如告警快搜、告警导出、告警统计、告警分析等。

三、基于ES的运营商告警检索方法创新点

基于Elasticsearch的告警数据检索方案的数据流程如“图2”所示：

图2：Elasticsearch的告警检索数据流程图

基于ES技术基础，上层技术的实现涉及到三个方面的工作，具体操作描述如下：

（一）实时告警数据存储与更新机制：告警实时入库程序从kafka实时接入告警和各类型其他消息，实时持久化到ES集群，该程序进行快速频繁的，数据持久化入库和更新操作，默认周期为3秒，上层数据的查询分析时长提升至不超过5秒。

（二）告警数据完整性和准确性保证机制：由于告警数据量大，通过告警定时同步程序，周期定时同步比对关系型数据库中告警数据来保证ES集群的数据完整性和一致性，另外还可以通过同步指定时间范围的历史数据，通过网管告警级别、告警类型、告警标题、设备厂商等字段的，灵活控制同步数据范围。

关系姓数据库RDB与ES的内部同步流程“图2”所示：

图2：RDB与ES同步流程

（三）客户端应用调用版本差异屏蔽机制：传统方式是通过ES自己的API接入，复杂度高，可读性差门槛高。同时ES版本发布更新快，上层接入应用需要频繁变更API。为了避免上述问题，使用SQL-Proxy接入，通过SQL-Proxy对各种版本做适配屏蔽差异，即上层应用通过SQL-Proxy来间接调用ES接口来查询检索告警数据，SQL-Proxy可通过应用传不同的版本号来确定调用哪个ES集群。

（四）具备负载均衡、高可用、故障快速恢复的能力：SQL-Proxy调用ES具备负载均衡的策略，另外会和ES集群保持长连接心跳，一旦检测到某个集群不可用会从负载均衡列表中进行摘除，直到检测到心跳正常后会重新加入负载列表。具备动态添加ES集群地址的功能。

四、结束语

本方案是基于ES技术实现的运营商告警数据检索办法，它通过对网络告警数据进行分片存储，并与关系型数据库中的告警数据进行实时对比，不断更新ES库的历史查询集群，实现了实时告警数据和历史告警数据同库存储与更新机制，保障了告警数据的完整性、准确性和持久化存储。相较于传统关系型数据依赖于B树索引，ES方案采用的反序索引，通过SQL-Proxy中间件来解析客户端使用类SQL语法编写的查询语句，翻译成ES的API接口进行应用调用，大大提高了告警数据检索效率，屏蔽了客户端应用调用版本差异，使得应用层实现了负载均衡、高可用、故障快速恢复等能力，从而保障业务的正常运行，从效率提升及稳定性两个方面极大提升了运营商告警数据检索及分析有关业务。

参考文献

[1]王槊，邵柱. 浅析ElasticSearch在CentOS环境下的部署与应用[J]. 网络安全和信息化 2020(08).

[2]徐伟杰，王挺，薛婉婷. 基于ElasticSearch的搜索引擎设计与实现[J]. 智库时代. 2019(05).

[3]田兆丰; 王歌吟. 基于ElasticSearch智能搜索引擎的宽带线上选址平台的设计与实现[J]. 通信与信息技术. 2020(07).

[4]郝胜男，赵领杰. 一种基于ElasticSearch的推荐系统架构 [J]. 电脑知识与技术. 2017(06).

作者简介：

杨勋城（1985-06-11），男，汉族，贵州贵阳人，贵州大学通信工程专业本科毕业，网络工程师、通信工程师，从事动环设施维护管理、机电项目建维管理、暖通能耗管理等方面的研究。

陆恩波（1987-9-8），男，土家族，贵州遵义人，贵州大学硕士研究生，通信工程师，信息系统项目管理师，从事IT运维管理、IT项目管理、云计算应用、大数据应用等方面的研究。

1