aiops框架结构（pol框架）

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

本文目录一览：

• 1、相比传统运维工具，AIOps的优势在哪里？
• 2、AIOps具体是如何落地的？
• 3、有了AIOps平台，是不是就不需要运维工程师了？
• 4、智能运维是什么？
• 5、如何做好运维监控？

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

作为一种将算法集成到工具里的新型运维方式，AIOps 可以帮助企业最大程度地简化运维工作，把 IT 从耗时又容易出错的流程中解放出来。

有了 AIOps，当 IT 出现故障隐患，运维人员不需要再等待系统发出故障告警，通过内置的机器学习算法以及大数据技术，就能自动发现系统的各类异常，从而实现从异常入手判断故障发生的可能性、严重性和影响，依赖机器对数据的分析结果，判断最佳的应对方案。

由此可以看出，基于 AIOps 的管理方法对监控式运维的底层技术实现了颠覆。传统 IT 运维管理工具更为关注突发事件（即告警）、配置和性能，而 AIOps 则更加关注问题、分析和预测，二者可谓互相补充相得益彰。

对 IT 运维人员而言，当一条告警被确认的时候，不但意味着你第一时间发现了业务故障，更意味着在故障发生的这一刻，业务已经受到了影响。而随着 AIOps 的出现，IT 部门可以通过机器学习和算法技术，事先发现 IT 系统的运行异常，提前进行故障的防范甚至规避措施，确保业务故障不出现或者少出现，这些对于 IT 和业务部门来说意义重大。

AIOps具体是如何落地的？

AIOps如何落地aiops框架结构，还是以具体案例来说比较容易理解。就拿擎创为北京农村商业银行做aiops框架结构的项目来说。

项目背景：

近年来数字化转型aiops框架结构的步伐愈发变快，随着北京农村商业银行业务规模的扩增以及业务形式的电子化加速，贯穿业务、市场、系统、应用、数据库、中间件、网络、安全等多方面的数据量迅速叠加堆积。然而，这些对于市场而言极具价值的巨量化数据并不集中，它们分散在银行的各中心服务器或设备之中，这使得银行的数据运维工作量越来越大，尤其是在日志的统一管理、监控、信息挖掘等方面极为明显。因此，北京农村商业银行对于信息技术提升和数据管理加强的需求日益加深。

根据监管部门对银行数据治理的相关指引以及中国银监会《商业银行信息科技风险管理指引》（银监发〔2009〕19号）中针对日志文件完整性、存留周期的相关要求，北京农村商业银行最终选择擎创科技助力其完善智能运维建设，保障其业务的平稳高效运行。

解决方案：

根据北京农村商业银行的需求以及现状，擎创科技通过以下手段为其建设运维大数据平台。

通过现分布式高可用，支持横向扩展，随着业务需要随时扩容平台节点aiops框架结构；

通过高效数据采集手段，实现对现有IT环境的实时数据采集，打破各个孤立运维工具中的数据孤岛；

对所有运维数据进行集中高效的存储、查询及可视化展示；

支持结构化、非结构化的数据采集支撑；

内置AI智能日志分析引擎，实现日志异常检测、日志异常定位并辅助故障定位。

平台架构图如下：

创新点：

北京农村商业银行在运维大数据平台项目的建设中，采用流批一体的处理技术、流式窗口聚合方式，实现aiops框架结构了实时采集、秒级处理、秒级查询，为运维人员提供高效的数据查询手段，为应用人员实现交易数据与日志的深度结合；

采用智能算法判断、故障根因定位，为运维人员提供便捷数据分析工具。充分挖掘了北京农村商业银行的运维数据价值、提升了运维管理水平、提高了运维效率。

建设成效：

建设日志治理平台和大数据平台，实现日志数据统一集中管理、KPI动态异常检测、日志智能聚类等功能。

日志治理+大数据平台（算法），当前日增日志6TB，设计容量10TB，热数据保存30天、冷数据保存3个月，大数据平台日志存档一年、指标类数据两年；

最高峰每秒处理日志500万条日志，其中最高按单笔业务交易日志行数达3000+行，经采集、数据提取、数据合并、数据丰富等数据处理后延时小于1s。

总结：

随着运维大数据平台的建设完成，北京农村商业银行实现了对各类运维日志数据的统一管理，能够对日志进行集中查询、聚类分析、快速分析、精细化分析等操作，结合监控告警的智能化处理，可以做到事前智能预警、事后快速定位故障并分析，进一步提升了银行数据中心的运维管理水平。

有了AIOps平台，是不是就不需要运维工程师了？

确实听说有人这样担心和误会。

实际上，AIOps平台出现并蓬勃发展的主要动力，是因为企业的IT系统数据量越来越大，结构也越来越复杂，靠单纯的运维工程师的经验和人工判断，很难应对层出不穷的运维问题。传统的运维监控软件，可以展示运维数据，却无法给出分析和处置建议，无法跟上排障的要求。

随着AI人工智能的应用，可以把运维数据做更好的分析，或提供疑似根因的定位、或提供异常的预警，使用AIOps系统，MTTR（平均故障排除时间）能从数小时缩短到数分钟，排障的经验也可以作为既有知识保存供他人参考。

所以，有AIOps之后，原先一个运维工程师管理n个应用和设备；就算是设备增加到100n，可能靠一个工程师也能管得过来，而不用等比例增加到100个运维工程师。这就是技术进步的意义。

智能运维是什么？

得益于IT外包服务的发达，现在的运维已经不包括搬机器上架、接网线、安装操作系统等基础工作，运维人员一般会从一台已安装好指定版本的操作系统、分配好IP地址和账号的服务器入手，工作范围大致包括：服务器管理（操作系统层面，比如重启、下线）、软件包管理、代码上下线、日志管理和分析、监控（区分系统、业务）和告警、流量管理（分发、转移、降级、限流等），以及一些日常的优化、故障排查等。
随着业务的发展、服务器规模的扩大，才及云化（公有云和混合云）、虚拟化的逐步落实，运维工作就扩展到了容量管理、弹性（自动化）扩缩容、安全管理，以及（引入各种容器、开源框架带来的复杂度提高而导致的）故障分析和定位等范围。
听上去每一类工作都不简单。不过，好在这些领域都有成熟的解决方案、开源软件和系统，运维工作的重点就是如何应用好这些工具来解决问题。
传统的运维工作经过不断发展（服务器规模的不断扩大），大致经历了人工、工具和自动化、平台化和智能运维（AIOps）几个阶段。这里的AIOps不是指Artificial Intelligence for IT Operations，而是指Algorithmic IT Operations（基于Gartner的定义标准）。
基于算法的IT运维，能利用数据和算法提高运维的自动化程度和效率，比如将其用于告警收敛和合并、Root分析、关联分析、容量评估、自动扩缩容等运维工作中。
在Monitoring（监控）、Service Desk（服务台）、Automation（自动化）之上，利用大数据和机器学习持续优化，用机器智能扩展人类的能力极限，这就是智能运维的实质含义。
智能运维具体的落地方式，各团队也都在摸索中，较早见效的是在异常检测、故障分析和定位（有赖于业务系统标准化的推进）等方面的应用。智能运维平台逻辑架构如图所示。
智能运维平台逻辑架构图
智能运维决不是一个跳跃发展的过程，而是一个长期演进的系统，其根基还是运维自动化、监控、数据收集、分析和处理等具体的工程。人们很容易忽略智能运维在工程上的投入，认为只要有算法就可以了，其实工程能力和算法能力在这里同样重要。
智能运维需要解决的问题有：海量数据存储、分析、处理，多维度，多数据源，信息过载，复杂业务模型下的故障定位。这些难题是否会随着智能运维的深入应用而得到一定程度的解决呢？我们会在下一篇文章中逐步展开这些问题，并提供一些解决方案。
本文选自《智能运维：从0搭建大规模分布式AIOps系统》，作者彭冬、朱伟、刘俊等，电子工业出版社2018年7月出版。
本书结合大企业的智能运维实践，全面完整地介绍智能运维的技术体系，让读者更加了解运维技术的现状和发展。同时，帮助运维工程师在一定程度上了解机器学习的常见算法模型，以及如何将它们应用到运维工作中。

如何做好运维监控？

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

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

② 监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理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层，也可以根据企业自己的情况进行调整：

基础设施层

硬件设备层

操作系统层

组件服务层

应用性能层

业务运营层

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