CN115905417A - 一种系统异常检测处理方法及装置 - Google Patents

一种系统异常检测处理方法及装置 Download PDF

Info

Publication number
CN115905417A
CN115905417A CN202111152914.6A CN202111152914A CN115905417A CN 115905417 A CN115905417 A CN 115905417A CN 202111152914 A CN202111152914 A CN 202111152914A CN 115905417 A CN115905417 A CN 115905417A
Authority
CN
China
Prior art keywords
subsystems
log
anomaly detection
real
logs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111152914.6A
Other languages
English (en)
Inventor
姜磊
刘学生
徐代刚
李小进
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to CN202111152914.6A priority Critical patent/CN115905417A/zh
Priority to PCT/CN2022/104378 priority patent/WO2023050967A1/zh
Publication of CN115905417A publication Critical patent/CN115905417A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
    • G06F18/2411—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches based on the proximity to a decision surface, e.g. support vector machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
    • G06F18/2415—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches based on parametric or probabilistic models, e.g. based on likelihood ratio or false acceptance rate versus a false rejection rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Artificial Intelligence (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Evolutionary Computation (AREA)
  • Evolutionary Biology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例提供了一种系统异常检测处理方法及装置，该方法包括：获取预设时间段内系统中多个子系统的实时数据；分别对该多个子系统的实时数据中的实时日志进行分类，得到该多个子系统的实时日志的分类结果；分别根据该分类结果对应的异常检测方式对该日志进行异常检测，得到多个子系统的检测结果；根据该多个子系统的检测结果与该多个子系统的实时数据对该系统进行异常检测处理，可以解决相关技术中相同的异常检测方式不能适应不同子系统，且无法有效排除整个系统异常的问题，不同类型日志采用不同的异常检测方式进行分析，基于各个子系统的检测结果与实时数据统一对系统进行异常检测处理，便于协助定位异常和故障根因。

Description

一种系统异常检测处理方法及装置
技术领域
本申请实施例涉及通信领域，具体而言，涉及一种系统异常检测处理方法及装置。
背景技术
在电信行业的运维保障中，异常检测和定位问题是非常重要的一环。除了系统的稳定性外，运营商更关注功能是否持续可用，如上报给运营商的OSS网管的资源数据和性能数据是否缺失，上报的网元发生的告警数据是否延迟太多等。其中日志分析是一个非常重要的保障手段。设备或者上面运行的软件如果出现故障，不管是否会产生告警，定位异常根因并解决故障，日志分析都是非常关键和必要的。
图1是相关技术中电信保障网管系统数据流向的示意图，如图1所示，南向需要接受多个下级网元管理系统(Element Management System，简称为EMS)的业务数据，如告警数据、性能数据和资源数据等，经过相应处理转换后北向上报到上级运营商的运维运营系统(Operation Support Systems，简称为OSS)网管集中处理。这个系统由于业务复杂性，由多个子系统构成，有告警子系统，性能子系统，资源子系统，数据库PG和卡夫卡kafka服务等子系统。告警和性能资源属于业务子系统，而数据库PG和kafka服务以及图中未展示的FTP、NTP等属于基础服务。
仅仅对北向发送日志和南向接受日志的时间对比和个体告警性能对比，只能发现异常，但无法定位哪个模块出现异常。通过人工去检索所有内部日志以发现问题显然是不现实的，同样，对不同子系统的不同格式和不同目的的日志，采样相同的分析工具和方法也是不可行的。有些子系统如数据库、操作系统以及JAVA内存垃圾回收(Garbage Collect，简称为GC)日志，都有专门的日志分析工具，对比较复杂格式的非格式化数据，有开源的工具如Drain等，但由于日志内容有较强的目的性，各人自扫门前雪，它们并不能有效进行整体系统排查。
针对相关技术中相同的异常检测方式不能适应不同子系统，且无法有效排除整个系统异常的问题，尚未提出解决方案。
发明内容
本申请实施例提供了一种系统异常检测处理方法及装置，以至少解决相关技术中相同的异常检测方式不能适应不同子系统，且无法有效排除整个系统异常的问题。
根据本申请的一个实施例，提供了一种系统异常检测处理方法，包括：
获取预设时间段内系统中多个子系统的实时数据；
分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果；
分别根据所述分类结果对应的异常检测方式对所述日志进行异常检测，得到多个子系统的检测结果；
根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理。
根据本申请的另一个实施例，还提供了一种系统异常检测处理装置，包括：
第一获取模块，用于获取预设时间段内系统中多个子系统的实时数据；
第一分类模块，用于分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果；
第一异常检测模块，用于分别根据所述分类结果对应的异常检测方式对所述日志进行异常检测，得到多个子系统的检测结果；
第二异常检测模块，用于根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理。
根据本申请的又一个实施例，还提供了一种计算机可读的存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
根据本申请的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。
本申请实施例，获取预设时间段内系统中多个子系统的实时数据；分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果；分别根据所述分类结果对应的异常检测方式对所述日志进行异常检测，得到多个子系统的检测结果；根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理，可以解决相关技术中相同的异常检测方式不能适应不同子系统，且无法有效排除整个系统异常的问题，对各个子系统中的日志进行分类，不同日志采用不同的异常检测方式进行分析，基于各个子系统的检测结果与实时数据统一对系统进行异常检测处理，便于协助定位异常和故障根因。
附图说明
图1是相关技术中电信保障网管系统数据流向的示意图；
图2是本申请一实施例的系统异常检测处理方法的移动终端的硬件结构框图；
图3是根据本申请一实施例的系统异常检测处理方法的流程图；
图4是本申请一实施例的异常检测系统架构的示意图；
图5是本申请一实施例的南向接收一条告警打印的结构化日志的示意图；
图6是本申请一实施例的kafka处理一条告警的打印结构化日志示意图；
图7是本申请一实施例的北向模块发送给OSS一条告警打印的结构化日志的示意图；
图8是本申请一实施例的中间处理告警打印的半结构化日志的示意图；
图9是本申请一实施例的日志聚合流程的示意图；
图10是本申请一实施例的日志异常标记的示意图；
图11是本申请一实施例的两阶段异常检测流程的示意图；
图12是本申请另一实施例的系统异常检测处理装置的框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本申请的实施例。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本申请实施例中所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图2是本申请一实施例的系统异常检测处理方法的移动终端的硬件结构框图，如图2所示，移动终端可以包括一个或多个(图2中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，其中，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图2所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。
存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本申请实施例中的系统异常检测处理方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及业务链地址池切片处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。
在本实施例中提供了一种运行于上述移动终端或网络架构的系统异常检测处理方法，应用于终端，所述终端通过双连接(Dual Connection，简称为DC)接入源区域的当前主节点MN小区与当前辅节点SN小区，图3是根据本申请一实施例的系统异常检测处理方法的流程图，如图3所示，该流程至少包括如下步骤：
步骤S302，获取预设时间段内系统中多个子系统的实时数据；
步骤S304，分别对多个子系统的实时数据中的实时日志进行分类，得到多个子系统的实时日志的分类结果；
本实施例中，上述步骤S304具体可以包括：根据日志来源分别将多个子系统的实时日志分类为：操作系统日志、基础服务日志、应用日志。
本实施例中的实时数据至少包括实时日志、微服务的弹缩情况、微服务的运行资源所属范围以及微服务之间的调用消耗时间。
步骤S306，分别根据分类结果对应的异常检测方式对日志进行异常检测，得到多个子系统的检测结果；
本实施例中，上述步骤S306具体可以包括：对多个子系统中每个子系统的实时日志执行以下操作，以得到多个子系统的检测结果，其中，正在执行的实时日志称为当前日志：当前日志为操作系统日志或基础服务日志时，通过当前日志的关键字段确定当前日志的检测结果；当日志为应用日志时，将当前日志输入预先训练好的分类检测模型中，得到分类检测模型输出的当前日志的检测结果。
步骤S308，根据多个子系统的检测结果与多个子系统的实时数据对系统进行异常检测处理。
本实施例中，上述步骤S308具体可以包括：将多个子系统的检测结果与多个子系统的实时数据输入预先训练好的目标异常检测模型中，得到目标异常检测模型输出的系统的目标异常检测结果。
通过上述步骤S302至S308，可以解决相关技术中相同的异常检测方式不能适应不同子系统，且无法有效排除整个系统异常的问题，对各个子系统中的日志进行分类，不同日志采用不同的异常检测方式进行分析，基于各个子系统的检测结果与实时数据统一对系统进行异常检测处理，便于协助定位异常和故障根因。
在一实施例中，在将当前日志输入预先训练好的分类检测模型中，得到分类检测模型输出的当前日志的检测结果之前，上述方法还包括：确定当前日志为结构化日志，具体的，判断日志是否为非结构化日志或半结构化日志；当日志为非结构化日志或半结构化日志时，将日志转换为结构化日志；将当前日志进行向量化处理，得到日志向量；按照日志向量的关键字段对日志向量进行聚合，得到当前日志的多个调用链。
在另一实施例中，在上述步骤S308之前，上述方法还包括：获取预定数量的多个子系统的历史数据以及对应的系统的异常检测结果，其中，历史数据至少包括历史日志、微服务的弹缩情况、微服务的运行资源所属范围以及微服务之间的调用消耗时间；分别对预设数量的多个子系统的历史数据中的历史日志进行分类，得到多个子系统的历史日志的分类结果；分别根据分类结果对应的异常检测方式对历史日志进行异常检测，得到预定数量的多个子系统的检测结果；根据预定数量的多个子系统的检测结果、预定数量的多个子系统的数据以及对应的系统的异常检测结果对初始异常检测模型进行训练，得到训练好的目标异常检测模型，进一步地，使用预定数量的多个子系统的检测结果、预定数量的多个子系统的历史数据以及对应的系统的异常检测结果对初异常检测模型进行训练，得到目标异常检测模型，其中，预定数量的多个子系统的检测结果、预定数量的多个子系统的历史数据为初始异常检测模型的输入，训练好的目标异常检测模型输出的系统的目标异常检测结果与实际对应的系统的异常检测结果满足预设目标函数。
在另一实施例中，在根据多个子系统的检测结果与多个子系统的实时数据对系统进行异常检测处理之后，所述方法还包括：当系统的异常检测结果为存在异常时，根据多个子系统的检测结果对异常进行故障根因定位处理。
本实施例对系统中的历史日志，通过数据挖掘和机器学习，得到多个模型，对实时日志处理时，对不同日志按照不同的模型进行向量化，按照各自的模型进行深度学习分析处理，再统一集中分析，以协助定位异常和根因。先收集不同模块不同系统的日志，然后按照不同的日志格式和用途进行分类标签，设计不同的工具进行相应的处理，再进行集中分析，在异常出现时协助定位根因。
图4是本申请一实施例的异常检测系统架构的示意图,如图4所示，本实施例包括：日志分类器、日志转换器、工具分配器、异常检测器、机器学习器。初始，对网管的日志和模块和相关的异常知识库、服务调用链都进行初始化设置。具体包括：
步骤S401，日志分类器对历史日志数据进行日志分类；
步骤S402，日志转换器将历史日志转换为结构化日志；
步骤S403，日志向量化和聚合；
步骤S404，机器学习器训练异常检测模型；
步骤S405，评估是否模型是否训练完成，在判断结果为是的情况下，执行步骤S407，否则执行步骤S406；
步骤S406，机器学习器调参(即调整异常检测模型的参数)；
步骤S407，发布模型(即训练好的异常检测模型)；
步骤S408，日志分类器对实时日志数据进行日志分类；
步骤S409，日志转换器将实时日志转换为结构化日志；
步骤S410，日志向量化和聚合；
步骤S411，工具分配器对不同日志获取对应的异常检测器；
步骤S412，异常检测器通过异常检测模型检测系统异常；
步骤S413，负载定位根因。
然后，对日志按照设计域定义进行分类，然后对日志转换成结构化日志后进行向量化，再聚合，对各个模块的异常进行机器学习，得到分类模型(如果评估不过需要重新调参重新学习)，再对整体系统进行机器学习。
推理侧根据学习到的模型进行判断，然后辅助根因定位。
日志分类器对日志进行分类，日志转换器对把非结构化日志和半结构化日志转换成结构化日志，并实现向量化和聚类，工具分配器对不同的日志分配不同的检测工具或方法，机器学习器实现机器学习训练，异常检测器实现两阶段异常检测和初步定位。
本方案实现的详细步骤如下：
步骤1：建立初始知识库；
知识库分为：系统调用链，异常知识库和结构化日志的模板库。
系统调用链包括所有微服务之间的调用关系和传播关系，以及应用微服务名字、进程名、线程列表和日志文件名字。
异常知识库包括异常字典和异常超参数和故障堆栈模式。
异常字典包括如“FATAL”，“Error”,“Out Of Memory”这些常见系统错误，异常超参数包括Java虚拟机(Java Virtual Machine，简称为JVM)GC，有导致应用停顿的FULL GC，和新生代GC超过预设时间，如2秒等。
故障堆栈不一定是异常，但它对定位异常很有帮助，所以需要识别什么是堆栈日志，因此需要有一定字段或者模式来识别故障堆栈，如通过NB(Naive Bayes朴素贝叶斯)来训练和识别含有“Caused by:”和“at”字样的日志段落。
结构化日志模板库，即为了后续对结构化日志和非结构化日志以及半结构化日志的识别进行模板定义，如JSON结构日志和有明确字段定义的日志(如操作系统日志和GC日志以及应用调用Log4J和Logback输出的日志)。
步骤2：日志分类器对日志进行分类；
日志分类器对实时日志或训练数据(历史日志数据)进行分类，按照日志来源分类，如，是操作系统日志，是基础服务日志如数据库或kafka日志，还是应用日志。
步骤3：日志向量化和日志聚合；
日志向量化之前，需要把半结构化日志转换成结构化日志。所谓结构化日志，按狭义的定义就是通过JSON(JavaScript Object Notation，一种结构化数据)格式定义的日志，按广义的理解就是可以按照一定模板可以提取内容的日志，这里按广义理解泛指可以按照一定模板提取的日志，如图5、6、7所示的日志。
现在的日志，一般来说，底层支撑的操作系统或者基础服务的日志都是结构化日志，而上层应用日志，一般可以分为半结构化日志和非结构化日志。非结构化日志就是应用程序打印日志时，没有调用标准日志库，如Java应用程序没有调用log4j或者Logback等日志模块，而是自己输出的调试打印日志，随着程序的规范化和日志的规范化，这种日志都非常少了，忽略不计。半结构化日志，就是虽然应用程序如Java程序调用了log4j或Logback，能够有标准的时间戳，日志级别，类、函数、线程ID和具体调试内容，前面都是结构化了，但调试内容也是关键信息，而内容并不一定是结构化的，所以这些日志可以称作半结构化日志，图8是本申请一实施例的中间处理告警打印的半结构化日志的示意图，如图8所示，日志展示了半结构化日志中的非结构化信息。
但在大多数日志检测中，处理最多的正是这些半结构化日志的信息处理。非结构化日志转换成结构化日志有较成熟的方案，如Logstash等开源工具等，利用Grok编写正则表达式从非结构化数据中派生出结构，如果日志业务复杂，正则表达式编写并不容易，但这种日志偏少，可以使用分词后，再结合硬编码方式解决。最后对所有转换后的结构化日志进行向量化，向量化以关键特征组成，如日志关键内容，以告警数据举例，告警标题、告警发生时间、告警发生位置，它们三个可以通过哈希编码组成向量的一个维度，也可以组成三个维度，另外，本条日志记录时间也是向量的一个维度。
向量化之后对日志进行聚合。所谓聚合，是指把同一性质的日志聚合在一起，如一条南向收到的下级网元告警，它经过转换后，通过北向发送给OSS，那么这条告警除了南向北向记录日志外，还有kafka和数据库记录日志，中间告警处理模块也可能会记录，这些日志如果不聚合，和其它日志(如另外一条告警或者性能或者资源日志)会混合在一起，经过聚合，能够清晰看到这条数据的所有流程处理。
聚合按照日志向量的关键维度聚合，以记录告警的日志为例，通过告警向量中唯一标识(如告警标题+告警发生时间+告警发生位置)这个维度进行聚合，这样，记录日志时间的那个维度，能够看到这个告警在不同流程处理中的时间过程。
步骤4：异常定义和标记；
对一个软件系统来说，异常分为两类，一个是功能方面的异常，一个是非功能方面异常。在系统中，以示意图1为例，OSS系统收到北向的告警或者性能文件缺失，就属于功能方面异常，而收到但延迟了，则属于非功能方面异常。用户操作时系统返回错误，则属于功能异常，而用户操作时感觉系统卡顿等，可能内部有功能异常的可能，也有非功能异常的可能。
一个软件系统又由各子系统组成，而系统的异常肯定是一个或多个应用模块或子系统的异常导致，但子系统的异常又不一定会导致整个系统的异常。
比如一个应用作为网络时间协议(Network Time Protocol，简称为NTP)Client需要向时钟服务器NTP Server同步时钟，但某个时间可能无法连通NTP Server，这个NTPClient可能会打印Error异常，但并不一定会影响整个系统的业务运行。
要对系统和各子系统进行异常感知，如果完全是依靠用户操作感知显然不完整，毕竟用户感知不容易量化，不同用户感知也不同；另外如果仅仅依靠日志中是否存在异常字典(第一步定义)的词语或者有异常堆栈来判断也是不完整的，毕竟有些日志只是打印一些“Error”等错误信息但能处理这些错误继续正常运行而不影响整个流程，也有些程序在出现错误时并未打印异常而该功能实际已经出现异常。
因此，需要对系统是否异常通过机器学习进行判断，而机器学习有监督学习的标签，在本方案中，除了用户或测试人员在验证功能模块感知明显的功能异常外，还要把第三步日志聚合后的关键向量，如某条告警，从南向日志到北向日志通过对齐比较看是否完整而标记异常，通过日志时间戳计算是否延迟超过OSS标准，然后整合一段时间内延迟条数是否超过OSS要求(如延迟不超过1％)来标记是否异常。当然异常的种类多种多样，为了简化，只需要二分类，只要是系统不正常，即为异常。
步骤5：训练异常检测模型；
虽然感知了异常，但需要更进一步发现哪里出现了问题，哪个或者哪几个子系统、微服务出现问题导致整个系统出现异常。异常检测器，需要通过一定规则或者模型对系统进行异常检测，而这个模型是通过对历史日志数据和相应的标签训练出来的。先对不同的子系统进行异常检测判断，再汇总后进行一个总体的学习训练得到最终系统是否异常的模型。
关于整个系统的异常，并不是所有的异常信息都要通过机器学习来判断，如操作系统或底层支撑服务的异常日志，一般都是简单明了，可以直接通过关键字段，如“FatalError”等字样进行判断；并不是所有日志文件中的异常打印都是真正的异常，比如一个应用或者一个支撑服务作为NTP Client需要向时钟服务器NTP Server同步时钟，但某个时间可能无法连通NTP Server，这个NTP Client可能会打印Error异常，但并不影响整个系统的业务运行；并不是所有的异常都能够通过日志文本的异常打印直接得到，如延迟上报，可能是中间过程处理缓慢(如程序有bug)，而应用程序只会打印处理的时间戳，不会打印异常；并不是有些应用功能异常，整个系统就异常，以图1为例，如果外部系统OSS的资源接收失效了，那么系统的北向发送资源数据也会发生异常，但整个数据转换网管系统依然可能是正常的。
因此，异常检测器，需要先对不同的应用子系统进行异常检测判断，再汇总后进行一个总体的学习训练得到最终系统是否异常的模型，具体包括：给定时间窗口、调用链以及传播链得到相应模块日志；根据第一步中日志来源分类，对不同日志调用不同的异常检测模型进行检查；对操作系统和基础服务，用特殊字段，如“FATAL”等，进行检测，如有，则标识异常；对应用日志，对结构化和向量化后的历史日志数据进行聚合后，可以按照功能异常和非功能异常进行检测，可以按照结束日志和起始日志的向量进行对比；对应用日志，可以通过朴素贝叶斯(NB)或支持向量机(Support Vector Machine，简称为SVM)进行二分类学习得到模型；对应用程序运行的虚拟机日志进行检测，如GC日志，判断是否有FULL GC和新生代GC超过预设时间(如2秒)，若有，则标识异常；对应调用链之间，用正常标签的日志的时间差，按正态分布统计每个调用的时间，并以方差为特征；统一建模，按整体系统再度建模训练。正如上面所述局部异常未必会导致整个系统异常，因此需要对整体系统再度训练，标签还是整个系统是否异常，需要训练的参数特征如下：底层系统是否异常，基础服务是否异常，应用子系统是否异常，微服务是否弹缩，微服务运行资源数据所属范围(即在哪个范围)(CPU/内存/IO等)，调用链服务之间调用消耗时间N方差之内(N＝1,2,3)。训练好的模型为统一异常检测模型。
步骤6：异常检测器对实时业务进行两阶段检测和模块定位。
当实时系统运行时，业务检测器先进行两阶段检测，再进行异常初步定位，以协助最终的根因分析。
两阶段检测，第一阶段，根据从步骤5训练到的模型，对调用链中的各自服务的一个时间窗口的日志，工具分配器对不同的日志按日志分类柔性分配不同的工具和模型，按各自学习的模型进行判断是否异常；然后按照各自特征处理，再进行统一异常检测，得到系统发生异常结论。
两阶段检测在判断系统是否有非功能异常更为重要，仍然以告警从南向到北向为例，明确系统没有告警缺漏上报的问题，但系统有告警时延的异常后，即在明确南向接收数据没有缺失但有延时，根据调用链，按调用消耗时间偏离方差大小排序，再按各模块异常发生进行模块定位。
虽然是两阶段检测，但不同阶段根据不同日志柔性分配不同工具或不同方法，相比人工检测定位或者使用单一工具单一方法检测定位，其效率显然大幅提高。
步骤7：确定故障根因。
初步定位后，再结合第一步得到的异常堆栈数据(如有)以及代码进行真实的根因分析定位故障真实原因。
其中，日志分类定义和日志转换模板、常用字典、日志工具分配和机器学习训练都可以在设计态界面定义，运行态即具体执行分类、转换、工具分配等。
本实施例针对不同模块应用类型，不同的日志不同的异常检测手段，能够更准确判断系统是否异常；两阶段异常判断，能更准确判断系统是否异常；对没有告警异常只有日志的运维系统有比较好的参考作用；通过柔性分配不同方法和工具能够更快速异常定位。
日志向量化和日志聚合，图9是本申请一实施例的日志聚合流程的示意图，如图9所示，包括：
S901,准备日志；
S902,定义模板并提取相关数据；
S903,对非结构化记录内容部分分词，并提前关键字段；
S904,对这条日志语句拆分维度；
S905,对这条日志语句进行向量化；
S906,按照关键维度进行聚合。
对所有可能的关联日志，半结构化日志按照模板和关键字段转换成结构化日志，再向量化。向量的维度按照日志记录时间、级别(DEBUG/INFO/WARN/ERROR/FATAL)、调用类方法、线程名和微服务名，和日志信息关键维度。
日志信息关键维度，以告警和性能数据举例。对告警数据来说关键维度就是告警的标题/发生时间/发生的网元/相关ID等，它们可以按不同维度组合，也可以组合成一个维度，但它们共同组成关键维度。同样，对性能数据来说，就是统计网元/统计时间/统计数据文件名等。向量化后，按照关键维度进行聚合，这样能够把一个事件依照调用链从头到尾的发生的全部日志聚合起来。
标记应用异常，对底层系统和基础服务来说，异常标记相对容易，有明显的错误打印，如FATAL等字段，但对应用层来说，即使有错误堆栈也并不能说明有异常，因此需要通过调用链结合日志来分析。
根据调用链获取相关日志，在日志向量化和聚合后，获取起始日志和结束日志向量，如果获取失败，则中间肯定有异常，即使都能获取，那么日志记录的结束时间减去起始日志的时间出现异常，比如如果大于某个设计或者统计出来的数字，那么是肯定有异常，当然小于也不一定正常，中间可能有异常，直接跳过正常运行就结束了。
在这种情况下，有以下方式：
按照功能是否正常完成来标记这次应用调用是否异常。
可以统计所有调用的时间差，按正态分布来确定，极端偏差定位异常；虽然单个事件，如单个告警从南向到北向的数据体量是不变的，但如果整体系统其它事件的体量变化可能会导致时间出现偏差，所以相对来说不准确。
某些功能，类似图1这种直接从南向上报到北向数据的，有运营商规定的标准时间，如果超过，也标记为异常。此方式在电信行业的网管系统中较为常见。
图10是本申请一实施例的日志异常标记的示意图，如图10所示，包括：
S1001，准备日志；
S1002，获取聚合后日志向量；
S1003，获取起始日志向量；
S1004，获取结束日志向量；
S1005，是否获取成功，在判断结果为否的情况下，执行步骤S1006，在判断结果为是的情况下，执行步骤S1008；
S1006，粒度缺失功能异常，之后执行步骤S1007；
S1007，按聚合向量定位缺失模块，之后执行步骤S1013；
S1008，结束时间-起始时间
S1009，判断时间差是否超标，在判断结果为否的情况下，执行步骤S1010，在判断结果为是的情况下，执行步骤S1011；
S1010，标记正常；
S1011，延迟非功能异常；
S1012，统计聚合向量定位耗费时长最大模块；
S1013，标记异常.
子系统异常检测模型，图11是本申请实施例的两阶段异常检测流程的示意图，如图11所示，包括：
S1100,准备时间段内的日志和资源数据；
S1101,工具分配器根据日志类别柔性分配不同工具和模型；
S1102,通过关键字段检测基础服务是否异常；
S1103,检测应用虚拟机是否有异常；
S1104,使用日志聚合判断应用是否异常；
S1105,判断应用是否异常；
S1106,使用线性回归模型判断应用子模块调用链时长是否异常；
S1107,整体判断特征工程；
S1108,整体判断系统异常；
S1109，获取异常子系统应用模块；
S1110，协助根因定位。
整个系统是否异常是由各个子系统服务的异常共同影响决定的。先判断各子系统是否异常，再判断整个系统是否异常。如果整个系统判断异常后，再按子系统异常来协助寻找根因。对基础支撑系统，如微服务系统，直接通过日志中关键字段判断。对基础服务，如FTP,数据库，也直接通过日志中关键字段判断。对GC日志，通过是否有FULLGC和新生代GC超出标准时间来判断异常。对按功能划分的各应用子系统，按照起始结束的日志向量是否完整来判断功能异常，按照起始结束的时间差来判断非功能异常。
对各应用的各个子模块，需要用二分类来学习，特征工程按照日志的记录信息，不包括记录日志时间，其它信息，包括级别，调用类方法(有些异常会在异常处理类中出现，所以需要它)，和线程(有些异常会在异常处理线程中打印日志，所以需要它)，和日志信息各个字段，按照NB(朴素贝叶斯)来学习分类模型。
对调用链按调用时间分布来判断，对同样的业务数据，超长时间或者超短时间都不正常，因为可能中间出现异常就直接跳出异常，对不同的业务数据，如超大规模的告警风暴和稀疏的告警上报，那么时间调用不一致，因此需要按照规模进行线性回归判断是否正常，线性回归到特征可以用规定时间内的内存、线程和业务数量(如上报的告警)和日志大小(一般来说，业务量大，日志也越大)，通过这些特征来学习线性回归趋势模型。
整体系统异常，部分子系统有异常，对整个系统是否异常可能有绝对因素，也可能并不重要，因此需要通过机器学习来再次学习模型。
这里的特征工程的特征定义如下：
各个支撑子系统(包括支撑系统和基础服务)是否异常，
各个应用子系统是否异常
系统微服务数量是否超过标准
微服务是否弹缩
各微服务的资源(内存/CPU/IO)，其中资源数据本身是线性的，可以按照20％一个台阶划分成5个维度，如CPU，消耗0-20％，20％-40％，40％-60％，60％-80％，90％-100％，处在哪个维度则为1，其它维度为0，来定义。
通过SVM来学习二分类模型。
在实时运行时，通过二分类模型判断整个系统是否异常。
如果异常，再按子系统应用是否异常来辅助定位根因。
本申请实施例还提供了一种系统异常检测处理装置，图12是本申请另一实施例的系统异常检测处理装置的框图，如图12所示，包括：
第一获取模块122，用于获取预设时间段内系统中多个子系统的实时数据；
第一分类模块124，用于分别对多个子系统的实时数据中的实时日志进行分类，得到多个子系统的实时日志的分类结果；
第一异常检测模块126，用于分别根据分类结果对应的异常检测方式对日志进行异常检测，得到多个子系统的检测结果；
第二异常检测模块128，用于根据多个子系统的检测结果与多个子系统的实时数据对系统进行异常检测处理。
在一实施例中，所述第一分类模块124，还用于
根据日志来源分别将多个子系统的实时日志分类为：操作系统日志、基础服务日志、应用日志。
在一实施例中，第一异常检测模块126，还用于
对多个子系统中每个子系统的实时日志执行以下操作，以得到多个子系统的检测结果，其中，正在执行的实时日志称为当前日志：
当前日志为所述操作系统日志或基础服务日志时，通过当前日志的关键字段确定当前日志的检测结果；
当日志为应用日志时，将当前日志输入预先训练好的分类检测模型中，得到分类检测模型输出的当前日志的检测结果。
在一实施例中，所述装置还包括：
确定模块，用于确定当前日志为结构化日志；
向量化处理模块，用于将当前日志进行向量化处理，得到日志向量；
聚合模块，用于按照日志向量的关键字段对所述日志向量进行聚合，得到当前日志的多个调用链。
在一实施例中，上述的确定模块，还用于
判断日志是否为非结构化日志或半结构化日志；
当日志为非结构化日志或半结构化日志时，将日志转换为结构化日志。
在一实施例中，所述第二异常检测模块128，还用于
将多个子系统的检测结果与多个子系统的实时数据输入预先训练好的目标异常检测模型中，得到目标异常检测模型输出的系统的目标异常检测结果。
在一实施例中，上述的装置还包括：
第二获取模块，用于预定数量的多个子系统的历史数据以及对应的系统的异常检测结果；
第二分类模块，用于分别对预设数量的多个子系统的历史数据中的历史日志进行分类，得到多个子系统的历史日志的分类结果；
第三异常检测模块，用于分别根据分类结果对应的异常检测方式对历史日志进行异常检测，得到预定数量的多个子系统的检测结果；
训练模块，用于根据预定数量的多个子系统的检测结果、预定数量的多个子系统的数据以及对应的系统的异常检测结果对初始异常检测模型进行训练，得到训练好的所述目标异常检测模型。
在一实施例中，上述的训练模块，还用于
使用预定数量的多个子系统的检测结果、预定数量的多个子系统的历史数据以及对应的系统的异常检测结果对初异常检测模型进行训练，得到目标异常检测模型，其中，该预定数量的多个子系统的检测结果、预定数量的多个子系统的历史数据为初始异常检测模型的输入，训练好的目标异常检测模型输出的系统的目标异常检测结果与实际对应的系统的异常检测结果满足预设目标函数。
在一实施例中，所述装置还包括：
根因定位模块，用于当系统的异常检测结果为存在异常时，根据多个子系统的检测结果对异常进行故障根因定位处理。
本申请的实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述计算机可读存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
本申请的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。
在一个示例性实施例中，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。
本实施例中的具体示例可以参考上述实施例及示例性实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种系统异常检测处理方法，其特征在于，包括：
获取预设时间段内系统中多个子系统的实时数据；
分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果；
分别根据所述分类结果对应的异常检测方式对所述日志进行异常检测，得到所述多个子系统的检测结果；
根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理。
2.根据权利要求1所述的方法，其特征在于，分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果包括：
根据日志来源分别将所述多个子系统的实时日志分类为：操作系统日志、基础服务日志、应用日志。
3.根据权利要求2所述的方法，其特征在于，分别根据所述分类结果对应的异常检测方式对所述实时日志进行异常检测，得到多个子系统的检测结果包括：
对所述多个子系统中每个子系统的实时日志执行以下操作，以得到所述多个子系统的检测结果，其中，正在执行的实时日志称为当前日志：
当所述当前日志为所述操作系统日志或所述基础服务日志时，通过所述当前日志的关键字段确定所述当前日志的检测结果；
当所述日志为应用日志时，将所述当前日志输入预先训练好的分类检测模型中，得到所述分类检测模型输出的所述当前日志的检测结果。
4.根据权利要求3所述的方法，其特征在于，在将所述当前日志输入预先训练好的分类检测模型中，得到所述分类检测模型输出的所述当前日志的检测结果之前，所述方法还包括：
确定所述当前日志为结构化日志；
将所述当前日志进行向量化处理，得到日志向量；
按照日志向量的关键字段对所述日志向量进行聚合，得到所述当前日志的多个调用链。
5.根据权利要求4所述的方法，其特征在于，确定所述日志为结构化日志包括：
判断所述日志是否为非结构化日志或半结构化日志；
当所述日志为所述非结构化日志或所述半结构化日志时，将所述日志转换为结构化日志。
6.根据权利要求1所述的方法，其特征在于，根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理包括：
将所述多个子系统的检测结果与所述多个子系统的实时数据输入预先训练好的目标异常检测模型中，得到所述目标异常检测模型输出的所述系统的目标异常检测结果。
7.根据权利要求6所述的方法，其特征在于，在根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理之前，所述方法还包括：
获取预定数量的所述多个子系统的历史数据以及对应的系统的异常检测结果；
分别对所述预设数量的所述多个子系统的历史数据中的历史日志进行分类，得到所述多个子系统的历史日志的分类结果；
分别根据所述分类结果对应的异常检测方式对所述历史日志进行异常检测，得到预定数量的所述多个子系统的检测结果；
根据预定数量的所述多个子系统的检测结果、预定数量的所述多个子系统的数据以及对应的所述系统的异常检测结果对初始异常检测模型进行训练，得到训练好的所述目标异常检测模型。
8.根据权利要求7所述的方法，其特征在于，根据预定数量的所述多个子系统的检测结果、预定数量的所述多个子系统的数据以及对应的所述系统的异常检测结果对初始异常检测模型进行训练，得到训练好的所述目标异常检测模型包括：
使用预定数量的所述多个子系统的检测结果、预定数量的所述多个子系统的历史数据以及对应的所述系统的异常检测结果对初异常检测模型进行训练，得到所述目标异常检测模型，其中，所述预定数量的所述多个子系统的检测结果、所述预定数量的所述多个子系统的历史数据为所述初始异常检测模型的输入，训练好的所述目标异常检测模型输出的所述系统的目标异常检测结果与实际对应的所述系统的异常检测结果满足预设目标函数。
9.根据权利要求1至8中任一项所述的方法，其特征在于，在根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理之后，所述方法还包括：
若所述系统的异常检测结果为存在异常，根据所述多个子系统的检测结果对所述异常进行故障根因定位处理。
10.一种系统异常检测处理装置，其特征在于，包括：
第一获取模块，用于获取预设时间段内系统中多个子系统的实时数据；
第一分类模块，用于分别对所述多个子系统的实时数据中的实时日志进行分类，得到所述多个子系统的实时日志的分类结果；
第一异常检测模块，用于分别根据所述分类结果对应的异常检测方式对所述日志进行异常检测，得到多个子系统的检测结果；
第二异常检测模块，用于根据所述多个子系统的检测结果与所述多个子系统的实时数据对所述系统进行异常检测处理。
11.一种计算机可读的存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行所述权利要求1至9任一项中所述的方法。
12.一种电子装置，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行所述权利要求1至9任一项中所述的方法。
CN202111152914.6A 2021-09-29 2021-09-29 一种系统异常检测处理方法及装置 Pending CN115905417A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202111152914.6A CN115905417A (zh) 2021-09-29 2021-09-29 一种系统异常检测处理方法及装置
PCT/CN2022/104378 WO2023050967A1 (zh) 2021-09-29 2022-07-07 一种系统异常检测处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111152914.6A CN115905417A (zh) 2021-09-29 2021-09-29 一种系统异常检测处理方法及装置

Publications (1)

Publication Number Publication Date
CN115905417A true CN115905417A (zh) 2023-04-04

Family

ID=85729435

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111152914.6A Pending CN115905417A (zh) 2021-09-29 2021-09-29 一种系统异常检测处理方法及装置

Country Status (2)

Country Link
CN (1) CN115905417A (zh)
WO (1) WO2023050967A1 (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110659173B (zh) * 2018-06-28 2023-05-26 中兴通讯股份有限公司 一种运维系统及方法
CN110210512B (zh) * 2019-04-19 2024-03-26 北京亿阳信通科技有限公司 一种自动化日志异常检测方法及系统
CN110502412A (zh) * 2019-07-01 2019-11-26 无锡天脉聚源传媒科技有限公司 一种服务器日志处理方法、系统、装置及存储介质
CN112364285B (zh) * 2020-11-23 2024-02-02 北京八分量信息科技有限公司 基于ueba建立异常侦测模型的方法、装置及相关产品

Also Published As

Publication number Publication date
WO2023050967A1 (zh) 2023-04-06

Similar Documents

Publication Publication Date Title
US20150121136A1 (en) System and method for automatically managing fault events of data center
AU2019275633B2 (en) System and method of automated fault correction in a network environment
CN111475370A (zh) 基于数据中心的运维监控方法、装置、设备及存储介质
CN113254254B (zh) 系统故障的根因定位方法、装置、存储介质及电子装置
CN108737182A (zh) 系统异常的处理方法及系统
CN113590451A (zh) 一种根因定位方法、运维服务器及存储介质
CN113313280B (zh) 云平台的巡检方法、电子设备及非易失性存储介质
CN116361147A (zh) 测试用例根因定位方法及其装置、设备、介质、产品
García et al. Automatic alarm prioritization by data mining for fault management in cellular networks
US11792081B2 (en) Managing telecommunication network event data
Bodík et al. HiLighter: Automatically Building Robust Signatures of Performance Behavior for Small-and Large-Scale Systems.
CN111917848A (zh) 基于边缘计算和云计算协同的数据处理方法及云服务器
CN115905417A (zh) 一种系统异常检测处理方法及装置
US20230072123A1 (en) Method and system for automating analysis of log data files
KR101288535B1 (ko) 통신 시스템 모니터링 방법 및 이를 위한 장치
Chakor et al. Proposing a Layer to Integrate the Sub-classification of Monitoring Operations Based on AI and Big Data to Improve Efficiency of Information Technology Supervision
Streiffer et al. Learning to simplify distributed systems management
Afshinpour et al. Telemetry-based Software Failure Prediction by Concept-space Model Creation
Kawahara et al. Application of AI to network operation
WO2023089356A1 (en) Network attribute analysis
EP4068693A1 (en) Methods and devices for network monitoring
US11816112B1 (en) Systems and methods for automated process discovery
CN117648214A (zh) 一种异常日志处理方法及装置
CN114491044A (zh) 日志的处理方法及装置
Madaan et al. A system for predicting health of an E-Contract

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication