告警关联分析与预测（告警关联分析与预测的区别）

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

本文目录一览：

• 1、相比传统运维工具，AIOps的优势在哪里
• 2、急急急！！！兄弟急问联通工作得事情！！
• 3、如何做好运维监控？
• 4、银行IT系统运维风险控制有哪些手段

相比传统运维工具，AIOps的优势在哪里

所谓的AIOps，简单理解就是基于自动化运维，将AI和运维很好的结合起来。

AIOps的落地在多方面直击传统运维的痛点，AI算法承担起分析海量运维数据的重任，能够自动、准确地发现和定位问题，从决策层面提高运营效率，为企业运营和运维工作在成本、质量和效率方面的优化提供了重要支持。

可见，AIOps 在企业中的作用正在进一步放大。但事实上，很多企业对于AIOps 能解决什么问题并不清晰，今天我们就以博睿数据的AIOps 的三大场景和算法说起。

博睿数据的AIOps 实践

作为中国领先的智能可观测平台，在AIOps实践方面，多年来博睿数据积极拥抱人工智能、机器学习等新技术变革的浪潮，并基于AI和机器学习技术，自主研发了“数据接入、处理、存储与分析技术”核心技术体系，全面布局智能基线、异常检测、智能告警、关联分析、根因分析等丰富且广泛的智能运维功能，并将AIOps能力融入端到端全栈监控产品线，可为传统企业提供强大的数据处理、存储和分析的软件工具，帮助客户整合各类IT运维监控数据，实现数据的统一存储和关联分析，打破数据孤岛，构建统一的IT运维管理平台，让企业的IT运维更加智能化、自动化。

在此基础上，博睿数据还依托完整的IT运维监控能力，利用大数据和机器学习技术持续构建先进的智能运维监控产品，2021年先后推出了搭载了AI能力的新一代APM产品Server7.0和新版的统一智能运维平台Dataview，不断落地智能异常检测、根因分析、故障预测等场景。基于人工智能的能力实现运维监控场景的信息整合、特征关联和业务洞察，帮助企业确保数字化业务平稳运行，并保障良好的数字化体验。

目前，博睿数据在AIOps 技术方面主要落地了三大场景。即智能基线预测、异常检测及告警收敛。

随着企业业务规模扩大，云原生与微服务的兴起，企业IT架构复杂性呈现指数级增长。而传统的IT运维手段面临故障发生后，查找故障原因困难，故障平均修复时间周期长，已无法满足新的运维要求。因此运用人工智能赋能运维，去取代缓慢易错的人力决策，快速给出运维决策建议，降低问题的影响并提前预警问题就成为了必然。AIOps作为目前运维发展的最高阶目标，未来将会赋能运维带给用户全新的体验。

但需要注意的是，当前智能运维的很多产品和项目在企业侧落地效果并不理想，究其原因可归类为三点：一是数据采集与AI平台割裂，多源数据之间的关联关系缺失导致AI平台缺乏高质量的数据，进而导致模型训练效果不佳；二是数据采集以metric和log为主，导致应用场景较窄且存在数据孤岛问题；三是AI平台能力尚有提升空间。当前落地的场景多以异常检测与智能告警为主，未来需要进一步提升根因分析与故障预测的能力。

因此，未来企业首先要建设一体化监控运维平台，一体化是智能化的基础。基于一体化监控运维平台采集的高质量的可观测数据数据以及数据之间的关联关系，进一步将AIOps的能力落地到一体化监控运维平台中，从而实现问题精准定位与见解能力。

此外，在实际应用中，依据信通院的相关调查，其受访企业中只有不足20%的企业具有智能化监控和运维决策能力，超过70%的企业在应用系统出现故障的10分钟内一筹莫展。

各行业的数字化转型正在改变这一现状，不仅互联网企业，更多传统企业的数字化转型为智能运维开拓了更广阔的市场，智能运维有着巨大的发展空间，这也是博睿数据等行业领先企业发力的大好时机。

提升创新能力，推广智能运维不仅是相关服务商自身发展的要求，也是提升我国企业应用管理和运维水平的使命。

中国企业数字化转型加速，无论是前端的应用服务迭代更新，还是后端IT运维架构的复杂度提升，都在加速培育智能运维的成长。

急急急！！！兄弟急问联通工作得事情！！

1、引言
随着数据网络的快速发展和移动业务的迅猛增长，很多原本从事传输网络运行维护、组织管理，甚至是产品研发、生产和销售的人们，突然找不准网络发展的节奏，因此很多人对传输网络的未来充满了忧虑。作为传输网管系统，如何跟随网络发展的步伐更好地发挥其作用成为必须思考和解决的问题。
网络的可靠性、可用性和易维护性是传统电信运营商非常关心的几个要素。其中，网络的易维护性很大程度上取决于网管系统。对于电信运营商而言，网管系统是其提供电信级服务质量不可缺少的重要保障机制。判别网管系统存在价值的大小的依据是，它能够在多大程度上辅助运营商的运维活动，降低OPEX，从而实现网络运维活动的增值。各大电信运营商的维护体制改革不论采用什么样的形式，根本上都是为了改善网络运维组织的工作效率。
2、现阶段传输网络和网管的基本情况
2.1　传输网络的基本情况
DWDM系统为长途干线和本地网提供了巨大容量，SDH（包括MSTP）设备提供了业务的快速自愈能力，微波传输和PDH设备作为快速解决用户接入的一种辅助手段仍在使用。而正在推广使用的ASON设备结合了IP的灵活性，为传输网提供了前所未有的分布式智能，但提供业务的灵活性远不及IP承载网。虽然ASON设备已经被广泛使用，但多是利用其超大容量的特点组成SDH环路，ASON的维护管理仍不成熟。
另外，随着2007年中美海缆的开工建设，国际通信传输网络的容量和安全性将得到巨大提升，但我国通信运营企业仍需提高在国际通信传输市场的地位。
据预测，在未来的25年内IP骨干网和城域网的带宽将每6个月翻一番。这对于分布广泛、网络拓扑复杂、业务类型多样的城域网来说，问题更加突出。对此需要运用多种流量模型进行预测，需要在网络的扩展性和运行维护的便利性间寻求平衡。
2.2　传输网管的基本情况
目前，各设备提供商的网管系统基本上都能够管理从SDH、DWDM到ASON的全系列产品，现有的传输网管系统仍然继承和发扬了其传统功能，即配置管理、性能管理、故障管理、计费管理和安全管理。同时，国内运营企业纷纷通过北向接口建设了上层的综合网管系统，力图解决“七国八制”的传输网络给网络运行维护带来的种种弊端，但实施效果远未达到预期目标。
值得一提的是，为了能够迅速解决光缆线路中断后抢修难度大、故障修复历时长的问题，基于光信号检测的OLP（光纤自动倒换）系统得到了广泛使用。OLP系统的网管也能对在用纤芯的光功率进行简单的监测，并能通过网管发布指令进行一些简单的倒换操作。
目前，运营商网络中共存着设备提供商的网管系统、集成服务商的网管系统、应用管理的网管系统、综合网管系统等，传输网管机房内因此摆满了各种网管设备。比较尴尬的是，企业自己开发建设的综合网管系统可以辅助运行维护工作，但离不开各类设备提供商的网管系统。维护人员的日常工作虽然已经有了较为成熟的模式，但不得不奔忙在各套网管系统之间，距离管理的自动化和简单化目标还很远。
3、现有传输网管存在的主要问题
（1）日益扩大的网络规模与网管易读性之间的矛盾
现有的各类传输网管基本上都是在早期SDH网管的基础上完善和改进的，功能越来越多且越来越复杂，处理能力较早期确实大大得到提高，但却忽视了简化网管、净化界面的重要性。这种网管功能的堆砌往往造成维护过程中信息过多，导致网管整体效率下降。传输网络的故障处理很大程度上仍然依赖于操作维护人员的经验积累。
解决这个矛盾，笔者认为网管系统应实现以下功能。
●要求网管系统既能快速、准确地上报告警，又能直观地反映出故障的真正位置。不是维护人员在告警堆里找故障，而是要求网管系统具备告警关联分析和故障呈现功能。
●在故障出现的同时，要求网管系统能够迅速提供简要的分析（如业务是否中断、业务中断比例等），指导故障恢复工作。
●要求网管系统能够对关键动态运行参数（如网络的可用率，网络的整体性能偏离情况等）、网络资源进行自动统计和分析。
●要求网管系统提供类似于Windows桌面整理助手的工具，对于长期不用的交叉连接、端口进行清理提示。
（2）越来越复杂的网管和降低维护人力成本之间的矛盾
从降低企业运行成本的角度考虑，需要降低维护人员的素质门槛要求或者减少维护人员的数量。就目前设备商提供的网管系统而言，很难实现这一点。运营商的网络的规模在迅速扩大，人力成本却相对降低了，这多是以加大现有维护人员工作强度并提高维护人员的工作效率来实现的。例如引入智能光网络后，不仅在原有网管的基础上引入了很多新的理念，还要求维护人员能够熟练地运用一些专用分析工具，才能完成一些最基本的网络操作维护（如割接的审批、网络质量的评价等），这无形之中提高了对维护人员的要求。
（3）用户接入的多样性与通过网管快速反应之间的矛盾
随着业务创新力度的不断加大，要求传输网络特别是城域网有足够的灵活性和可扩展性，尤其是快速的业务开通和故障处理能力，而网管系统的能力在这方面起着关键作用。城域网采用了FTTx、MSTP、城域以太网、T-MPLS、VPN-FRR等多种技术，但最终用户并不关心运营商网络中采用的技术、网络性能、设备成本等，最终用户需要的是高质量的业务和可靠、迅速的服务。而现有的网管系统基本上还是“以我为主”，以“网络设备”为中心。只有网管能够直接反映出“最终用户的直观感受”，以客户为中心，才能真正拥有技术手段上的支持。
（4）集中式网管与分布式处理、设备现场操作之间的矛盾
从网络负荷平衡和网络健壮性角度来看，分布式处理是未来网管的发展方向，而且可以满足网络对伸缩性的要求。
随着网络规模的日益扩大，集中式网管系统必然导致系统处理负荷急剧增加。集中网管的最大问题是指挥人员和现场操作人员的信息不对称，现有网管系统基本上都不能直观地呈现设备现场的具体情况（如线缆连接情况、机盘告警等），对现场操作人员的指挥和指导很容易出现疏漏或错误。
（5）设备厂商的网管系统与综合网管系统之间的矛盾
开发综合网管系统的目的之一是将目前的多厂商网管系统统一起来，简化和规范目前的维护工作，给网络管理者提供准确、快速的数据和分析。从目前的使用情况来看，还是存在以下一些问题。
●综合网管系统与设备厂商网管系统功能重复较多。综合网管系统利用设备厂商网管系统北向接口提供的各类信息，也提供了告警管理、拓扑管理、性能管理等功能。综合网管系统要想实现与设备厂商网管系统基本一致的实时告警呈现是非常困难的事情，更何况这种实时管理极其消耗综合网管系统的资源。
●综合网管系统自身的局限性决定了其自身维护工作量太大。为保障综合网管系统的稳定工作，首先要保证其连接的设备厂商网管系统接口长期稳定工作，需要及时地处理接口故障，需要在设备软硬件升级后及时进行相应的升级开发工作。另外，由于北向接口自身的局限性，很多信息做不到自动识别和刷新，在每次网络调整后甚至是正常的网络维护作业后，需要人工维护这些信息（包括大量的静态资源信息）。
4、对现有传输网管工作的建议
（1）合理的传输网管组织形式
●减少设备提供商的数量，采用集中式的网管监控方式和集中的数据制作。实现网管数据的集中，可以减少数据的交互，有利于提高网管系统的性能，实现并发挥数据的价值。采用集中管理方式特别要注意的是，不仅要赋予集中网管更大的责任，还要赋予它们更大的管理权。
●根据实际情况，合理配置EMS和NMS。EMS和NMS各有优缺点，很多底层功能重复。配置网管时不能生搬硬套，而要结合实际的维护体制和综合网管要实现的功能进行配置。其中EMS相对来说功能基本满足需求，北向接口功能丰富；而NMS相对来说功能较为丰富，且支持OSS。
●避免网管带外DCN重复建设，保障带外DCN的稳定运行。
●根据传输网络全程全网的特点组织网管，不能人为地按照管理制度割裂网络，至少要保证一张网内的各个业务单元可以实时“看”到全局情况。
（2）充分、有效地发挥综合网管的作用
综合网管系统的开发、建设和使用的目的不应是替代设备厂商网管系统，而应是能够屏蔽厂商差异和规范局数据的快速制作等。与此同时，综合网管系统不宜求全，尽量避免与原设备厂商网管系统的功能重复，应该利用有限的资源集中精力解决突出的一些问题。
●在维护管理上建立高效、规范的维护管理机制，实现运维管理流程自动化，能够适应运营商业务流程的灵活调整。
●通过实现告警信息与客户业务电路的关联，及时提示工作人员对受影响的大客户和高等级业务电路进行应急处理和管理。对实现SLA业务提供技术和手段上的保障。
●重点解决静态、动态的资源管理，解决好资源整合问题。
●解决好跨专业多种业务系统的协作问题。
5、未来传输网管系统的发展方向
现阶段电信运营企业正在寻找新的盈利模式，朝着综合服务运营商转型的过程中，新型的运营模式对网管系统提出了更高的要求，即网管系统的智能化、综合化、简单化和个性化。
●网管的智能化是指繁杂的维护工作由网管系统自动完成，降低人为干预的工作量和工作难度。这种智能包括网络设备之间的信息交互智能、网络设备与网络管理者之间的信息交互智能。
●网管的综合化要求网管系统能够提供面向网络、业务、用户等多个功能的统一管理。而实现网管的综合化的前提是网管系统必须能够处理更大的信息量和更复杂的业务行为，更便于集中化的管理。
●网管的简单化是指通过减少操作人员的工作难度，降低对操作人员的要求，提高运行维护工作的整体运行效率。
●网管的个性化管理是企业精细化运营的必然结果，运营商需要深入了解用户和业务的细节，提供最贴近用户的深度感知。这就要求网管系统必须具备灵活的扩展能力，其管理功能可以根据运营商管理的设备类型、管理范围、网络规模、管理形式、业务类型等方便地进行界面定制和模块调整。
6、结束语
传输网管系统发展到今天已经比较完善和成熟，但仍然需要跟着运营商转型的步伐，创新网管开发理念，以满足精细化运维管理的需要。
好处是不用天天往外跑，坏处是全天候工作，经常加班。工资不会差的

如何做好运维监控？

统一监控平台，说到底本质上也是一个监控系统，监控的基本能力是必不可少的，回归到监控的本质，先梳理下整个监控体系：

① 监控系统的本质是通过发现故障、解决故障、预防故障来为了保障业务的稳定。

② 监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理6大模块。而数据采集、数据检测和告警处理是监控的最小闭环，但如果想要真正把监控系统做好，那故障管理闭环、视图管理、监控管理的模块也缺一不可。

一、数据采集

1、采集方式

数据采集方式一般分为Agent模式和非Agent模式；

Agent模式包括插件采集、脚本采集、日志采集、进程采集、APM探针等

非Agent模式包括通用协议采集、Web拨测、API接口等

2、数据类型

监控的数据类型有指标、日志、跟踪数据三种类型。

指标数据是数值型的监控项，主要是通过维度来做标识。

日志数据是字符型的数据，主要是从中找一些关键字信息来做监控。

跟踪型数据反馈的是跟踪链路一个数据流转的过程，观察过程中的耗时性能是否正常。

3、采集频率

采集频率分秒级、分钟级、随机三种类型。常用的采集频率为分钟级。

4、采集传输

采集传输可按传输发起分类，也可按传输链路分类。

按传输发起分类有主动采集Pull（拉）、被动接收Push（推）

按传输链路分类有直连模式、Proxy传输。

其中Proxy传输不仅能解决监控数据跨网传输的问题，还可以缓解监控节点数量过多导致出现的数据传输的瓶颈，用Proxy实现数据分流。

5、数据存储

对于监控系统来说，主要有以下三种存储供选择

① 关系型数据库

例如MySQL、MSSQL、DB2；典型监控系统代表：Zabbix、SCOM、Tivoli；

由于数据库本身的限制，很难搞定海量监控的场景，有性能瓶颈，只在传统监控系统常用

② 时序数据库

为监控这种场景设计的数据库，擅长于指标数据存储和计算；例如InfluxDB、OpenTSDB（基于Hbase）、Prometheus等；典型监控系统代表：TICK监控框架、 Open-falcon、Prometheus

③ 全文检索数据库

这类型数据库主要用于日志型存储，对数据检索非常友好，例如Elasticsearch。

二、数据检测

1. 数据加工

① 数据清洗

数据清洗比如日志数据的清洗，因为日志数据是非结构化的数据，信息密度较低，因此需要从中提取有用的数据。

② 数据计算

很多原始性能数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量，如果要检测磁盘使用率，就需要对现有指标进行一个简单的四则运算，才能得到磁盘使用率。

③ 数据丰富

数据丰富就是给数据打上一些tags标签，比如打上主机、机房的标签，方便进行聚合计算。

④ 指标派生

指标派生指的是通过已有的指标，通过计算得出新的指标。

2. 检测算法

有固定规则和机器学习算法。固定算法是较为常见的算法，静态阈值、同比环比、自定义规则，而机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。

无论是固定规则还是机器学习，都会有相应的判断规则，即常见的< =和and/or的组合判断等。

三、告警管理

1. 告警丰富

告警丰富是为了后续告警事件分析做准备，需要辅助信息去判断该怎么处理、分析和通知。

告警丰富一般是通过规则，联动CMDB、知识库、作业历史记录等数据源，实现告警字段、关联信息的丰富；通过人工打Tags也是一种丰富方式，不过实际场景下由于人工成本高导致难以落地。

2. 告警收敛

告警收敛有三种思路：抑制、屏蔽和聚合

① 抑制

即抑制同样的问题，避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。

② 屏蔽

屏蔽可预知的情况，比如变更维护期、固定的周期任务这些已经知道会发生的事件，心里已经有预期。

③ 聚合

聚合是把类似或相同的告警进行合并，因为可能反馈的是同一个现象。比如业务访问量升高，那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升，这样把这些性能指标都聚合到一块，更加便于告警的分析处理。

3. 告警通知

① 通知到人

通过一些常规的通知渠道，能够触达到人。

这样在没有人盯屏的时候，可以通过微信、短信、邮件触发到工作人员。

② 通知到系统

一般通过API推送给第三方系统，便于进行后续的事件处理

另外还需要支持自定义渠道扩展（比如企业里有自己的IM系统，可以自行接入）

四、故障管理

告警事件必须要处理有闭环，否则监控是没有意义的。

最常见还是人工处理：值班、工单、故障升级等。

经验积累可以把人工处理的故障积累到知识库里面，用于后续故障处理的参考。

自动处理，通过提取一些特定告警的固化的处理流程，实现特定场景的故障自愈；比如磁盘空间告警时把一些无用日志清掉。

智能分析主要是通过故障的关联分析、定位、预测等AI算法，进一步提升故障定位和处理的效率；

1. 视图管理

视图管理也属于增值性功能，主要是满足人的心理述求，做到心中有底，面向的角色很多（领导、管理员、值班员等）。

大屏：面向领导，提供全局概览

拓扑：面向运维人员，提供告警关联关系和影响面视图

仪表盘：面向运维人员，提供自定义的关注指标的视图

报表：面向运维人员、领导，提供一些统计汇总报表信息，例如周报、日报等

检索：面向运维人员，用于故障分析场景下的各类数据检索

2. 监控管理

监控管理是企业监控落地过程中的最大挑战。前5个模块都是监控系统对外提供的服务功能，而监控管理才是面向监控系统自身的管理和控制，关注真正落地的过程的功能呈现。主要有以下几个方面：

配置：简单、批量、自动

覆盖率：监控水平的衡量指标

指标库：监控指标的规范

移动端：随时随地处理问题

权限：使用控制

审计：管理合规

API：运维数据最大的来源，用于数据消费

自监控：自身稳定的保障

为了实现上述监控六大基础能力模块，我们可以按如下架构设计我们的统一监控平台。

主要分三层，接入层，能力层，功能层。

接入层主要考虑各种数据的接入，除了本身Agent和插件的采集接入，还需要支持第三方监控源的数据接入，才能算一个完整的统一监控平台。

能力层主要考虑监控的基础通用能力，包含数据采集模块、数据存储模块、数据加工模块、数据检测模块、AI分析模块。

功能层需要贴近用户使用场景，主要有管理、展示两类功能，在建设的过程中可以不断丰富功能场景。

另外，考虑到数据的关联关系，为未来的数据分析打下基础，监控和CMDB也需要紧密联动，所有的监控对象都应该用CMDB进行管理，另外，还可以配置驱动监控为指导理念，实现监控的自动上下线，告警通知自动识别负责人等场景，简化监控的维护管理。

为了统一监控平台能够在企业更好的落地，我们需要配备对应的管理体系，其中最重要的是指标管理体系。

指标管理体系的核心理念：

监控的指标体系是以CMDB为骨架，以监控指标为经脉，将整个统一监控平台的数据有机整合起来。

贯穿指标的生命周期管理，辅以指标的管理规范，保障监控平台长久有序的运行。

从企业业务应用的视角出发，一般将企业监控的对象分为6层，也可以根据企业自己的情况进行调整：

基础设施层

硬件设备层

操作系统层

组件服务层

应用性能层

业务运营层

银行IT系统运维风险控制有哪些手段

数字化时代，银行业务的快速发展，计算机的系统数量和部署规模均呈快速增长态势，且加上应用系统的微服务化，系统间的关联更为复杂，也相应提升了对运维系统的要求与难度。虽然银行内建立了较为全面的监控体系，但是面对千百万的告警风暴时，故障定位解决问题十分困难，特别不利于系统安全、持续、稳定运行。

数字化转型中，以用户为中心是驱动金融行业的核心基础。所以，对于像银行、证券公司这样拥有海量运维数据的金融行业来说，智能运维势在必行。采用先进的运维手段（智能运维）则是企业不断前行的源源动力。

说一个我们正在服务的客户案例吧，客户是一家商业银行。

这家商业银行通过擎创科技提供的夏洛克AIOps解决方案，建设了一套智能运维数据分析系统，集中收集和分析十多个系统的运维数据，包括应用系统日志、告警、性能指标、交易指标和网络性能指标等，并通过机器学习算法实现指标异常检测、关联分析和告警收敛，以此加快问题定位效率，保障系统运行。为了有效提高对异常情况的监测和未来趋势预测，提前发现系统隐患，该商业银行通过擎创夏洛克AI实验室，训练并生成了基于业务场景的多类算法，实现系统的单指标异常检测，极大降低系统故障发生的概率。

与此同时，该商业银行还用了擎创夏洛克指标解析中心和告警辨析中心，通过此实现多维指标关联分析，帮助快速发现和定位系统问题，提升排障效率；实现告警收敛，降低告警风暴，加快定位时间。目前告警压缩率达到了80%以上，运维人员的告警处理效率明显提高。实现了IT系统运维的智能化，为业务健康运转提高强力保障。

其实，擎创科技此前便服务过众多银行类客户，如中国银联、交通银行、浦发银行和宁波银行等，帮助其构建了智能化的运维平台，提升了客户运维效率，且目前很多项目都进入到二期、三期建设阶段。

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