异常检测方法、装置、电子设备和计算机可读存储介质

技术领域

本公开涉及计算机领域，尤其涉及数据监控与云平台，具体涉及一种异常检测方法、装置、电子设备、计算机可读存储介质和计算机程序产品。

背景技术

期望实现一种异常检测和报警机制，以在系统出现异常时实现准确的告警。

发明内容

本公开提供了一种异常检测方法、装置、电子设备、计算机可读存储介质和计算机程序产品。

根据本公开的一方面，提供了一种异常检测方法，包括：获取指标数据，所述指标数据包括待监视的业务的业务指标；基于所述指标数据确定系统的风险等级；以及响应于所述风险等级高于阈值，控制终端发起告警，其中，针对所述待监视的业务获取所述指标数据包括：将所述业务的结果数据与针对所述业务设定的预期要求进行比较，并且返回所述结果数据是否满足所述预期要求的指示作为所述业务指标。

根据本公开的另一方面，提供了一种异常检测装置，包括：指标获取单元，被配置用于获取指标数据，所述指标数据包括待监视的业务的业务指标；风险确定单元，被配置用于基于所述指标数据确定系统的风险等级；以及告警单元，被配置用于响应于所述风险等级高于阈值，控制终端发起告警，其中，所述指标获取单元还被配置用于针对所述待监视的业务，将所述业务的结果数据与针对所述业务设定的预期要求进行比较，并且返回所述结果数据是否满足所述预期要求的指示作为所述业务指标。

根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中所述存储器存储有能够被所述至少一个处理器执行的计算机程序，所述计算机程序包括指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行根据本公开的实施例所述的方法。

根据本公开的另一方面，提供了一种存储有计算机程序的非瞬时计算机可读存储介质，其中，所述计算机程序包括指令，所述指令用于使所述计算机执行根据本公开的实施例所述的方法。

根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，其中，所述计算机程序包括指令，所述指令在被处理器执行时实现根据本公开的实施例所述的方法。

根据本公开的一个或多个实施例，能够更加准确地检测系统异常。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图示例性地示出了实施例并且构成说明书的一部分，与说明书的文字描述一起用于讲解实施例的示例性实施方式。所示出的实施例仅出于例示的目的，并不限制权利要求的范围。在所有附图中，相同的附图标记指代类似但不一定相同的要素。

图1示出了根据本公开的实施例的可以在其中实施本文描述的各种方法的示例性系统的示意图；

图2示出了根据本公开的实施例的异常检测方法的流程图；

图3示出了根据本公开的另一实施例的异常检测方法的流程图；

图4示出了根据本公开的实施例的异常检测装置的结构框图；

图5示出了根据本公开的实施例的异常检测系统的数据流的示意图；

图6示出了能够用于实现本公开的实施例的示例性电子设备的结构框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在本公开中，除非另有说明，否则使用术语“第一”、“第二”等来描述各种要素不意图限定这些要素的位置关系、时序关系或重要性关系，这种术语只是用于将一个元件与另一元件区分开。在一些示例中，第一要素和第二要素可以指向该要素的同一实例，而在某些情况下，基于上下文的描述，它们也可以指代不同实例。

在本公开中对各种所述示例的描述中所使用的术语只是为了描述特定示例的目的，而并非旨在进行限制。除非上下文另外明确地表明，如果不特意限定要素的数量，则该要素可以是一个也可以是多个。此外，本公开中所使用的术语“和/或”涵盖所列出的项目中的任何一个以及全部可能的组合方式。

下面将结合附图详细描述本公开的实施例。

图1示出了根据本公开的实施例可以将本文描述的各种方法和装置在其中实施的示例性系统100的示意图。参考图1，该系统100包括一个或多个客户端设备101、102、103、104、105和106、服务器120以及将一个或多个客户端设备耦接到服务器120的一个或多个通信网络110。客户端设备101、102、103、104、105和106可以被配置为执行一个或多个应用程序。

在本公开的实施例中，服务器120可以运行使得能够执行异常检测方法的一个或多个服务或软件应用。

在某些实施例中，服务器120还可以提供可以包括非虚拟环境和虚拟环境的其他服务或软件应用。在某些实施例中，这些服务可以作为基于web的服务或云服务提供，例如在软件即服务(SaaS)模型下提供给客户端设备101、102、103、104、105和/或106的用户。

在图1所示的配置中，服务器120可以包括实现由服务器120执行的功能的一个或多个组件。这些组件可以包括可由一个或多个处理器执行的软件组件、硬件组件或其组合。操作客户端设备101、102、103、104、105和/或106的用户可以依次利用一个或多个客户端应用程序来与服务器120进行交互以利用这些组件提供的服务。应当理解，各种不同的系统配置是可能的，其可以与系统100不同。因此，图1是用于实施本文所描述的各种方法的系统的一个示例，并且不旨在进行限制。

用户可以使用客户端设备101、102、103、104、105和/或106来对系统运行进行监视、观看系统指标的展示、接收报警或者对相应的异常模块进行调试等。客户端设备可以提供使客户端设备的用户能够与客户端设备进行交互的接口。客户端设备还可以经由该接口向用户输出信息。尽管图1仅描绘了六种客户端设备，但是本领域技术人员将能够理解，本公开可以支持任何数量的客户端设备。

客户端设备101、102、103、104、105和/或106可以包括各种类型的计算机设备，例如便携式手持设备、通用计算机(诸如个人计算机和膝上型计算机)、工作站计算机、可穿戴设备、游戏系统、瘦客户端、各种消息收发设备、传感器或其他感测设备等。这些计算机设备可以运行各种类型和版本的软件应用程序和操作系统，例如Microsoft Windows、AppleiOS、类UNIX操作系统、Linux或类Linux操作系统(例如Google Chrome OS)；或包括各种移动操作系统，例如Microsoft Windows Mobile OS、iOS、Windows Phone、Android。便携式手持设备可以包括蜂窝电话、智能电话、平板电脑、个人数字助理(PDA)等。可穿戴设备可以包括头戴式显示器和其他设备。游戏系统可以包括各种手持式游戏设备、支持互联网的游戏设备等。客户端设备能够执行各种不同的应用程序，例如各种与Internet相关的应用程序、通信应用程序(例如电子邮件应用程序)、短消息服务(SMS)应用程序，并且可以使用各种通信协议。

网络110可以是本领域技术人员熟知的任何类型的网络，其可以使用多种可用协议中的任何一种(包括但不限于TCP/IP、SNA、IPX等)来支持数据通信。仅作为示例，一个或多个网络110可以是局域网(LAN)、基于以太网的网络、令牌环、广域网(WAN)、因特网、虚拟网络、虚拟专用网络(VPN)、内部网、外部网、公共交换电话网(PSTN)、红外网络、无线网络(例如蓝牙、WIFI)和/或这些和/或其他网络的任意组合。

服务器120可以包括一个或多个通用计算机、专用服务器计算机(例如PC(个人计算机)服务器、UNIX服务器、中端服务器)、刀片式服务器、大型计算机、服务器群集或任何其他适当的布置和/或组合。服务器120可以包括运行虚拟操作系统的一个或多个虚拟机，或者涉及虚拟化的其他计算架构(例如可以被虚拟化以维护服务器的虚拟存储设备的逻辑存储设备的一个或多个灵活池)。在各种实施例中，服务器120可以运行提供下文所描述的功能的一个或多个服务或软件应用。

服务器120中的计算单元可以运行包括上述任何操作系统以及任何商业上可用的服务器操作系统的一个或多个操作系统。服务器120还可以运行各种附加服务器应用程序和/或中间层应用程序中的任何一个，包括HTTP服务器、FTP服务器、CGI服务器、JAVA服务器、数据库服务器等。

在一些实施方式中，服务器120可以包括一个或多个应用程序，以分析和合并从客户端设备101、102、103、104、105和106的用户接收的数据馈送和/或事件更新。服务器120还可以包括一个或多个应用程序，以经由客户端设备101、102、103、104、105和106的一个或多个显示设备来显示数据馈送和/或实时事件。

在一些实施方式中，服务器120可以为分布式系统的服务器，或者是结合了区块链的服务器。服务器120也可以是云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机。云服务器是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPS，Virtual Private Server)服务中存在的管理难度大、业务扩展性弱的缺陷。

系统100还可以包括一个或多个数据库130。在某些实施例中，这些数据库可以用于存储数据和其他信息。例如，数据库130中的一个或多个可用于存储诸如音频文件和视频文件的信息。数据存储库130可以驻留在各种位置。例如，由服务器120使用的数据存储库可以在服务器120本地，或者可以远离服务器120且可以经由基于网络或专用的连接与服务器120通信。数据存储库130可以是不同的类型。在某些实施例中，由服务器120使用的数据存储库可以是数据库，例如关系数据库。这些数据库中的一个或多个可以响应于命令而存储、更新和检索到数据库以及来自数据库的数据。

在某些实施例中，数据库130中的一个或多个还可以由应用程序使用来存储应用程序数据。由应用程序使用的数据库可以是不同类型的数据库，例如键值存储库，对象存储库或由文件系统支持的常规存储库。

图1的系统100可以以各种方式配置和操作，以使得能够应用根据本公开所描述的各种方法和装置。

下面参考图2描述根据本公开的实施例的异常检测方法200。

在步骤S201处，获取指标数据，指标数据包括待监视的业务的业务指标。获取指标数据可以包括：将该业务的结果数据与针对该业务设定的预期要求进行比较，并且返回结果数据是否满足预期要求的指示作为业务指标。

在步骤S202处，基于指标数据确定系统的风险等级；以及

在步骤S203处，响应于风险等级高于阈值，控制终端发起告警。

通过方法200，可以通过监视数据指标并且基于指标来分析风险等级。具体地，在方法200中提出了“业务指标”的思想，并且从业务效果侧进行监控，使用数据运行的实际效果状态来监控系统是否异常，从业务效果来进行服务判定。由此，可以更准确全面地监视系统的运行状况。

待监视的业务可以是预先确定的业务，例如系统的关键业务或者由用户或者使用者指定的业务，并且这样的指标监控机制可以被称为关键效果监控。关键效果监控采用真实数据测试，并且用于模仿业务方对系统运行的要求。这种监控方式可以通过数据流的实际效果状态来确认。例如，如果是生效系统，可以关注最终数据流生效预期内容是否符合预期等。例如，如果系统是搜索引擎，则可以针对搜索业务进行监视，并且基于搜索结果是否满足预期要求(例如，结果的时间、数量、是否含有特定关键词等)来计算业务指标。又例如，如果系统是推荐系统，可以针对推荐业务进行监视，并且预期要求可以是推荐结果的数量、时间、类型多样性、是否含有特定关键词或其他用户设定的要求等。对于不同的系统，可以类似地类似地根据不同系统所要达到的不同效果来预先设定不同的要监视的结果数据和预期要求，以实现从业务效果来进行服务判定。这样的业务指标的示例可以是单纯的“是/否”、“Y/N”或者“1/0”等，但是当然也可以采用其他数据格式。例如业务指标可以用数值来表示，不同的数值表示对对预期要求的满足程度或者偏离程度等。通过对系统的待监视业务例如关键业务的效果进行监控，能够更好地从业务方判断系统的运行情况。

根据一些实施例，结果数据包括业务运行结果的时间戳，并且预期要求包括时间戳在预定时间区间内。例如，对于系统中的搜索模块诸如搜索天气的模块，预期要求可以是：返回数据的时间戳不能早于当前时刻以前十分钟。如果返回的天气数据超过当前时间十分钟，则这样的数据将会被认为是业务上不可接受的。对于其他的业务，时间区间可能是不一样的，例如不得早于当前时刻以前几天、不得晚于某个时刻，或者需要在某个特定的时间区间(例如，2020年1月-2020年6月)内等。这样的预期要求可以是针对不同的业务人为设定的。如将在下文中叙述的，这样的预期要求也可以是根据业务数据和业务使用方的反馈(例如，用户满意度或者报错数据)等通过机器学习等学习到的。

根据一些实施例，指标数据还可以包括基础指标。基础指标可以包括基础资源信息、实例信息和服务状态信息中的至少一项。例如，基础资源使用信息可以包括cpu、内存、网络、磁盘io的使用信息，实例信息可以包括实例的qps、内部队列、指标状态等，服务状态信息可以包括app的服务状态，比如升级变更重启的服务信息。基础指标也可以包括其他系统运行产生的、能够直接或者间接反映系统健康度要求的指标数据。通过这些基础指标，能够全面地监视系统的各项数据指标，并且基于这样的指标，能够全面准确地进一步分析风险等级。

根据一些实施例，指标数据还可以包括模拟指标。模拟指标指示测试数据的运行是否符合预期。由此，不仅依赖于每个模块的实际运行的各项数据指标，还通过外部模拟测试效果发送请求，对于各部分服务进行数据校验，从而更加准确地判定服务效果。根据一些实施例，获取所述指标数据还包括：使用能够遍历系统的每个分支的测试数据对系统进行测试，并且监视所述测试数据的运行指标作为所述模拟指标。使用能够遍历系统的每个模块与每个分支的测试数据，能够更完善地对系统的指标进行监控，并且预先发现一些较不频繁使用的模块或分支处的问题，能够在系统整体出现大的异常或者崩溃前发现问题所在。

这样的引入模拟指标的机制可以被称为哨兵机制。哨兵机制指的是模拟数据测试，并且用于模仿系统使用。哨兵机制可以例如定时运行，并且使用特定的数据以涵盖系统中所有模块的所有分支。哨兵机制类似于上线前的效果测试，但是在上线后仍然运行。所测量的指标是本次测试是否符合预期设定，预期设定例如每个模块的预设搜索时长、内存占用率等。

通常情况下一个问题的发现不能完全依赖于每个模块的各项数据指标，需要有额外的机制做数据补充，因为每个模块的监控指标其实能做的相对有限，有些模块或者服务的异常对整体服务效果而言并不是可以直观体现出来，这个时候需要外部模拟测试效果发送请求，对于各部分服务进行数据校验，从而判定服务效果。

根据一些实施例，获取指标数据包括：通过对应的接口接收指标的不同于日志的统计值。将数据信息打印到日志中然后进行数据提取会导致原始数据量太大。通过将模块中需要的统计值通过信息采集的接口直接对外汇报，节约了原始数据再数据采集过程中的资源消费，最大程度上减少延迟带来的性能损耗。

普通的监控数据源会使用将数据信息打印到日志中然后进行数据提取，这样做带来的最严重的问题就是原始数据量太大，需要处理的数据过多，给后续计算存储都会带来相对较重的负担。尤其是针对模块多、指标多的复杂系统，数据量将会非常大，数据的传输和时延将会带来严重的问题。本公开提出在监控端直接计算统计值，因为无论是监控延迟、qps或者各项其他数据，实际上需要的数据是相应窗口内的累加值、分位值等。由此，可以将模块中需要的统计值通过信息采集的接口直接对外汇报出来。这样操作直接节约了原始数据再数据采集过程中的资源消费，并且能够最大程度上减少延迟带来的性能损耗。

对于简单系统，可以仅仅采用简单的指标计算而无需数据分析模块，但是对于复杂的数据通路而言，单个模块的数据状态不能直观反映数据系统状态。对于关键的复杂问题，需要需要根据拓扑结构分析问题数据源，拓扑结构通过架构化数据注册到数据分析模块中，针对是存在关键数据流，模块需要针对数据的前后依赖关系分析出来真正出问题的模块和问题,并且通过预定好的服务措施判断服务是否可以进行自动处理(如重启、迁移，切换通路等)。根据一些实施例，基于指标数据确定系统的风险等级包括：使用预先设定的规则引擎对指标进行分析以获得风险等级。除了基本的数值计算之外和数值判断(例如将指标值与阈值进行比较，并且当超过阈值例如当内存超过警戒值时即告警的的简单逻辑)之外，可以通过预先设定的规则来基于指标判断风险。

根据一些实施例，规则引擎是通过机器学习而获得的。通过机器学习来优化规则设定，能够发现指标间的深层次关系，有利于指标异常的监控。可以通过人工控制和/或机器学习的方式来设定规则。

例如，可以通过人为设定“当某模块出现某指标异常时，认为发生了某问题并且进行告警”等来设定规则。也可以通过机器学习来学习会导致较严重后果的指标异常。例如，通过机器学习等手段，可以学习到“当内存在两个小时内持续上涨(虽然未达到警戒值)和/或触发其他指标异常时，应当发出警告”。

根据一些实施例，获取指标数据包括从数据库读取存储的指标数据，其中，数据库支持数据订阅功能，并且存储的指标数据是由数据库从数据采集源订阅而获得的。选取具有订阅功能的数据库，可以减少数据的采集模块。数据监控源存在的情况下，可以通过数据推送的方式进行数据传递，服务端直接订阅原始模块数据，将原始数据直接保存到数据库中。对于不支持订阅功能的数据库或者数据类型，可以为其开发代理以主动拉取数据然后更新写入数据库。

根据一些实施例，数据库是时序数据库。时序数据库针对按照时间顺序的数据写入和存储的优化，保证数据写入的高效和数据的时效性，并且时序数据库有丰富的关于时序操作聚合操作函数，便于后续进行数据聚合。

根据一些实施例，系统是采用云原生架构的系统。目前复杂的架构系统如搜索引擎、推荐系统、智能交互训练系统等，都是在朝着云原生的方向发展，云原生改造逐步体现出速度、安全性、扩展性方面的优势，具有强大的生命力。由于将原来的巨型模块拆分出多个独立服务小模块是改造过程的关键步骤之一，模块越拆越细，服务向微服务、云原生进化的同时，发现系统维护的模块越来越多，配置的报警项也越来越多。在出问题的时候，往往需要多个模块多个指标共同分析梳理才能最终确认问题所在，并且往往需要对多个模块都熟悉了解的人或者需要多个模块的负责人协助排查才能确认，由此导致排查解决问题的成本非常高。同时，在多指标的场景下，整个系统会配置非常多的指标，常态下也会有报警信息，多数情况下不需要处理。久而久之，导致大家对报警信息不敏感，并且在真正系统出现严重问题的时候，报警信息又多又杂无法将真实有效的消息提取出来，系统报警信息也会淹没到普通信息中。通过根据本公开的实施例的方法，能够准确有效甄别风险等级信息，准确定位异常模块。

根据一些实施例，控制终端发起告警包括：基于风险等级在不同的区间内，控制终端采用不同的路径发起告警。对于众多繁杂的报警信息，需要对所有的报警信息按照服务等级信息分级处理，并且根据风险等级，采用实时电话、推送消息到群、推送到公告等不同的路径进行推送。例如，可以将风险等级分成高中低三级。最高级报警影响服务效果，需要立即处理，这种需要实时电话，保证即使夜间出问题也可以立刻进行处理。中等级别的风险代表普通级别，服务很重要，长时间异常可能有严重后果，需要夜间处理，可以发送信息到群里面。低级别的风险可以采用通知信息，例如当有模块数据异常会将消息推送到公告栏，只是启一个在意通知的作用。由此，实现不同风险等级的不同告警，免除人为对风险等级进行区分的复杂劳力，也不会被不重要的告警通知频繁打扰或者漏掉了重要的系统异常告警。

基于复杂系统的监控报警，尤其是基于全局状态云原生架构系统，相对于传统场景相比主要存在几方面的不同：架构模块非常多，模块内部监控的指标虽然相对固定，但是种类很多，导致整体的数据量数据维度都较大；架构迭代较快，数据变化新增的速度较快，监控报警接入成本需要足够低；监控报警本身需要尽量少占用系统资源；监控报警的时效性要求达到1分钟以内，甚至达到秒级。

由于系统复杂，并且架构数据维度多，导致需要监视的指标非常多，并且基于众多指标计算出的报警数据难以反映哪个模块出现问题，经常需要人工介入，并且即使是经过专业人员的分析，从多维数据中找到出现问题的模块也存在难度。为了减少数据维度，则往往在复杂系统的整体配置少数通用指标，当指标监控异常后，由熟悉系统整体的专业人士进行初步判断，然后联系相关模块的负责人员共同追查问题，这种方式依赖人工排查，人力耗损严重，对人员的依赖性强，风险大，并且通常情况下排查周期较长。

此外，往往是在系统出现故障后才发现问题。当前监控和报警处理都倾向于系统出现问题，造成线上有损失后，再进行线上问题的止损和修复。然而，对于很多问题在真正产生系统有损后再进行修复，对于线上已经造成损失，属于亡羊补牢。因此，希望获取一种能够预先感知系统故障、类似于系统“体检”的报警机制，把问题扼杀在前，尽可能避免异常或者损失。

根据本公开的实施例，能够实现一种系统健康检测和报警机制，能够针对多维的数据指标和尤其是由多个模块构成的系统，准确、实时地定位问题模块。本公开的方法能够适用于复杂系统尤其是复杂的云原生架构系统，能够有效地进行系统健康度程度衡量，可以查看整个系统从整体到部分的健康状态。通过指标异常预测与干预，能够将大部分问题潜在的风险点在发展成为大的异常之前提前暴露。此外，能够实现系统的多模块多指标的整体分析准确定位问题。根据本公开的实施例的方法，能够自动/半自动的处理绝大多数问题，极大的降低系统的异常风险，快速解决问题，降低人力成本。

下面结合图3描述根据本公开的另一实施例的异常检测方法300。

在步骤S301处，从一个或多个服务监视数据指标。数据指标可以包括基础指标、模拟指标和业务指标中的一个或多个。相较于采用基础指标(例如，时延、CPU占用率等)的简单指标监视系统，本公开还增加了模拟指标和业务指标，或者如前文所述，可以分别称为哨兵机制和关键效果监控机制。对这些指标的监视方法已经结合方法200进行了详细描述，并且在这里不再赘述。

如前文已经描述的，这里监视的指标数据可以是实时的指标数据的统计值(例如，中位数、平均值、累计值等)。例如，可以从服务的不同接口实时接收当前时间窗口的各类所需数据的统计值。由此，可以不需要指标日志的生成、传输、接收与提取过程。使用统计值输出而非打印日志主要是能够节省传输资源，因为大量维度的数据的日志的传输将会耗费很大的带宽。可以预先设定好要监控的指标，例如“每秒请求数”等，并且以例如串行化的方式实时输出当前统计值。

在步骤S302处，存储指标数据。如前文所述，可以通过数据库直接接收指标订阅来存储指标数据。或者，也可以通过将采集的数据转发到数据存储单元，将指标数据存储在数据库中。可以对指标数据进行聚合的存储。如前文所述，这里可以采用时序数据库以方便后续的数据提取。可选地，在步骤S3021处，可以在数据展示平台中展示存储的指标数据。可以借助任何数据展示工具和组件来实现这里的展示功能，并且本公开不限于此。

在步骤S303处，可以对数据进行基础分析。基础分析可以包括一些比较基本的数据处理，例如对原始数值进行处理以生成趋势(上升或下降、斜率)等。可选地，在步骤S3031处，可以使用基础分析的结果计算系统健康程度，并且在步骤S3032处，可以在数据展示平台中展示系统健康计算结果，由此能够实现基于提取数据的多维度的数据效果展示。

在步骤S304处，可以使用规则引擎对数据进行进一步分析。如上所述，规则引擎可以使用机器学习和人工控制来设定。可选地，可以例如使用控制接口，基于规则引擎生成的分析结果，进行业务干预和服务控制。例如当结果指示某个实例已经异常或者有潜在异常风险，工作人员可以人为更改实例位置、重启实例等。

在步骤S305处，可以基于分析结果输出告警。具体地，可以基于基础分析和规则引擎分析中的至少一个输出告警。由此，能够实现数据异常的感知和服务异常报警。如前所述，可以将告警分成不同的等级，并且可以基于不同的风险等级，采用不同的途径或者向不同的人员输出警报。

针对复杂拓扑关系的架构系统，通过当前健康报警机制，可以实现多数已知问题准确定位，半自动、自动处理解决，对于重要恢复的问题，可以准确的及时的通知直达负责人，在降低系统维护人力的同时降低系统风险。根据本公开的实施例的方法可以应用于搜索、推荐、服务等复杂架构场景。通过应用根据本公开的实施例的方法，例如方法200或300，能够降低系统的异常风险，自动解决线上复杂问题，降低服务维护的人力成本。

下面参考图4描述根据本公开的实施例的异常检测装置400。装置400可以包括指标获取单元401、风险确定单元402和告警单元403。指标获取单元401可以被配置用于获取指标数据，指标数据包括待监视的业务的业务指标。风险确定单元402可以被配置用于基于指标数据确定系统的风险等级。告警单元403可以被配置用于响应于风险等级高于阈值，控制终端发起告警。其中，指标获取单元401还可以被配置用于，针对待监视的业务，将该业务的结果数据与针对该业务设定的预期要求进行比较，并且返回结果数据是否满足预期要求的指示作为业务指标。

根据一些实施例，结果数据包括业务运行结果的时间戳，并且预期要求包括时间戳在预定时间区间内。根据一些实施例，指标数据还包括基础指标，基础指标包括基础资源信息、实例信息和服务状态信息中的至少一项。根据一些实施例，指标数据还包括模拟指标，模拟指标指示测试数据的运行是否符合预期。根据一些实施例，指标获取单元401还包括：使用能够遍历系统的每个分支的测试数据对系统进行测试，并且监视测试数据的运行指标作为模拟指标的单元。

下面参考图5描述根据本公开的另一实施例的异常检测系统及其示例数据流。

指标获取单元501用于监视系统服务504并且产生指标数据。具体地，指标获取单元可以包括指标监视单元5011、指标采集单元5012(可选)和数据存储单元5013。系统服务504可以包括多个服务A、B、C等，并且指标监视单元5011可以针对预先设定的指标，从对应服务的接口读取实时的原始指标数据。指标监视单元5011监视的指标数据可以包括模拟指标、基础指标、业务指标等。根据一些实施例，指标监视单元5011可以被配置成从系统获取原始指标，并且实时地输出原始指标的所需的统计值。根据一些实施例，数据存储单元被配置成从数据采集源订阅指标数据并且存储订阅数据。在数据存储单元5013所采用的数据存储架构具有订阅功能的情况下，可以省略虚线框中的指标采集单元5012，并且由数据存储单元直接接收收集的数据指标推送。否则，可以设置数据指标采集单元5012以接收指标订阅，并且将数据转发到数据存储单元5013。存储在数据存储单元5013中的数据可以被发送到数据展示平台进行指标数据的展示，以供运维人员等查看。存储在数据存储单元5013中的数据也可以被用于风险等级的计算。

风险确定单元502可以基于指标获取单元501获得的指标数据，对其进行分析和计算，并且确定风险等级。风险确定单元502包括基础分析单元5021和规则引擎5022。基础分析单元5021从数据存储单元5013读取存储的指标，并且对其进行基础分析。基础分析可以包括一些比较基本的数据处理，例如对原始数值进行处理以生成趋势(上升或下降、斜率)等。

经过基础分析单元5021分析获得的数据可以被发送到数据展示平台(例如，经过初步的计算或者绘制之后)以进行系统运行状况的展示。经过基础分析单元5021分析获得的数据也被传递到规则引擎5022以进行基于更复杂规则的风险分析。此外，基础分析单元5021可以向告警单元503发送风险确定结果。替选地，可以仅在基础分析单元确定当前存在较高的风险水平，例如在经过基础分析单元5021分析获得的数据满足一定的风险阈值(例如，CPU使用率超过阈值)的情况下，基础分析单元5021向告警单元503发送风险确定结果(以及可选地，相应的风险等级)。

如前文所述，规则引擎5022可以基于预先设定和/或不断更新学习的规则进行风险分析。可以通过规则设定单元507对规则引擎进行设置。规则设定单元可以包括机器学习单元和人工控制平台(未示出)。还可以基于规则引擎5022的分析结果，调用控制接口506进行业务干预和服务控制等，例如，当结果指示某个实例已经异常或者有潜在异常风险，工作人员可以人为更改实例位置、重启实例等。规则引擎5022也可以向告警单元503发送风险确定结果。

告警单元503可以被配置成控制终端例如服务通告终端508发起告警。可以存在多个服务通告终端508，例如不同的终端对应不同的报警路径和不同的风险等级等。或者，一个终端也可以对应不同的报警路径。不同的路径可以包括电话呼叫告警、SMS短消息告警、即时聊天软件警报、邮件通知、发布到公共平台等。

根据本公开的实施例，还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

参考图6，现将描述可以作为本公开的服务器或客户端的电子设备600的结构框图，其是可以应用于本公开的各方面的硬件设备的示例。电子设备旨在表示各种形式的数字电子的计算机设备，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图6所示，设备600包括计算单元601，其可以根据存储在只读存储器(ROM)602中的计算机程序或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序，来执行各种适当的动作和处理。在RAM 603中，还可存储设备600操作所需的各种程序和数据。计算单元601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

设备600中的多个部件连接至I/O接口605，包括：输入单元606、输出单元607、存储单元608以及通信单元609。输入单元606可以是能向设备600输入信息的任何类型的设备，输入单元606可以接收输入的数字或字符信息，以及产生与电子设备的用户设置和/或功能控制有关的键信号输入，并且可以包括但不限于鼠标、键盘、触摸屏、轨迹板、轨迹球、操作杆、麦克风和/或遥控器。输出单元607可以是能呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。存储单元608可以包括但不限于磁盘、光盘。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据，并且可以包括但不限于调制解调器、网卡、红外通信设备、无线通信收发机和/或芯片组，例如蓝牙TM设备、1302.11设备、WiFi设备、WiMax设备、蜂窝通信设备和/或类似物。

计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理，例如方法200或300。例如，在一些实施例中，方法200或300可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到RAM 603并由计算单元601执行时，可以执行上文描述的方法200或300的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法200或300。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行、也可以顺序地或以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

虽然已经参照附图描述了本公开的实施例或示例，但应理解，上述的方法、系统和设备仅仅是示例性的实施例或示例，本公开的范围并不由这些实施例或示例限制，而是仅由授权后的权利要求书及其等同范围来限定。实施例或示例中的各种要素可以被省略或者可由其等同要素替代。此外，可以通过不同于本公开中描述的次序来执行各步骤。进一步地，可以以各种方式组合实施例或示例中的各种要素。重要的是随着技术的演进，在此描述的很多要素可以由本公开之后出现的等同要素进行替换。