MES的监控方法、监控装置及可读存储介质与流程

本申请涉及模具制造控制技术领域，具体涉及一种mes的监控方法、监控装置及可读存储介质。

背景技术：

制造执行系统(manufacturingexecutionsystem,mes)作为生产管理系统，扮演着承接车间现场控制与上层企业运营的重要角色，实时主动收集及监控生产资料，进行生产流程管理，确保生产质量，有效地指导工厂的生产运作。但是，对于mes自身业务状况的监控，目前尚缺乏主动有效的方式，功能缺失。由此至少造成以下问题：第一，响应异常不及时：当生产发生异常时，需操作人员报障反映后，mes团队才知道，具有滞后性，不利于运维。第二，数据流量不可知：外部系统对接mes，若环境中消息输出量爆量，即msg(message)爆量将会引起数据堵塞，影响mes处理事务的效率。第三，日志文件(log)的分析低效：mes有多台服务器上运行有ap(application,应用程序)，每一台服务器上的ap可视为运行一项业务，当前查找日志文件的内容时需在每一台服务器进行，费时费力，效率较为低下。

技术实现要素：

鉴于此，本申请提供一种mes的监控方法、监控装置及可读存储介质，以解决现有技术缺乏对mes自身业务状况的监控的问题。

本申请提供的一种mes的监控方法，包括：

读取mes的分布于多台服务器上的应用程序的日志文件；

根据所述日志文件监控mes的业务运行信息。

其中，所述根据所述日志文件监控mes的业务运行信息，包括：

根据所述日志文件进行采样以获取采样时段内的消息输出量，并将获取的采样时段内的消息输出量上报至集成监控平台。

其中，所述根据所述日志文件监控mes的业务运行信息，包括：

接收用于读取日志文件的查询请求，所述查询请求包含关键词；

搜索所述日志文件中与所述关键词相匹配的记录并回传。

其中，所述读取mes的分布于多台服务器上的应用程序的日志文件之前，所述方法包括：

监测是否存在应用程序未产生日志文件；

在监测到存在应用程序未产生日志文件时，上报集成监控平台。

其中，所述根据所述日志文件监控mes的业务运行信息，包括：

根据所述日志文件统计每一所述服务器上的应用程序运行时出现错误代码的次数；

在预定时间段内所述错误代码的发生次数超过预定次数时，将所述包含错误代码的告警消息发送给操作人员。

其中，所述根据所述日志文件监控mes的业务运行信息，包括：

在监控到服务器在超过预定时长后未输出日志文件，将所述包含所述服务器信息的告警消息发送给相关操作人员。

其中，所述读取mes的分布于多台服务器上的应用程序的日志文件之前，所述方法包括：

读取所述mes的数据库中的业务监控参数；

在监测到所述业务监控参数中缺少开始信息或结束信息的应用程序时，将所述包含所述应用程序的告警消息发送给操作人员。

其中，所述读取mes的分布于多台服务器上的应用程序的日志文件之前，所述方法包括：

获取所述mes的数据库中的业务监控参数；

在监测到所述业务监控参数中存在开始信息至结束信息的时长超过预定时长时，将所述包含所述应用程序的告警消息发送给操作人员。

本申请提供的一种mes的监控装置，包括：

读取模块，用于读取mes的分布于多台服务器上的应用程序的日志文件；

监控模块，用于根据所述日志文件监控所述mes的业务运行信息。

本申请提供的一种可读存储介质，存储有指令，所述指令适于处理器加载以执行上述任一项mes的监控方法。

本申请上述mes的监控方法、监控装置及可读存储介质，通过读取mes的分布于多台服务器上的应用程序的日志文件，并根据所述日志文件监控mes的业务运行信息，能够弥补mes业务监控的空白，及时了解mes业务的健康状况，并且及时响应生产异常情况，便于运维等操作人员主动做出及时应对，化被动为主动，另外，无需操作人员在每一台服务器进行日志查询，能够提高mes的运维效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例的mes的监控方法的流程示意图；

图2是本申请一实施例的监控mes的场景交互示意图；

图3是本申请的mes日志文件的分析方法一实施例的流程示意图；

图4是本申请的mes日志文件的查询方法一实施例的流程示意图；

图5是本申请的mes第一种异常情况的监控方法一实施例的流程示意图；

图6是本申请的mes第二种异常情况的监控方法一实施例的流程示意图；

图7是本申请的mes第三种异常情况的监控方法一实施例的流程示意图；

图8是本申请的mes第四种异常情况的监控方法一实施例的流程示意图；

图9是本申请一实施例的mes的监控装置的结构示意图。

具体实施方式

下面结合附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。在不冲突的情况下，下述各个实施例及其技术特征可以相互组合。

图1是本申请一实施例的mes的监控方法的流程示意图。请参阅图1所示，所述mes的监控方法包括如下步骤：

s11：读取mes的分布于多台服务器上的应用程序的日志文件。

s12：根据所述日志文件监控mes的业务运行信息。

mes的业务是分布于多台服务器(server)上的，并由各台服务器上的应用程序运行得以实现。每台服务器上的应用程序可视为运行mes所分配的一项业务。每台服务器上应用程序产生的日志文件是用于记录其运行相关业务的记录文件或文件集合，可分为事件日志和消息日志，其可用于处理历史数据、追踪诊断问题以及理解系统的活动等。

本申请实施例相当于为mes增加了一项监控业务运行状况的功能。在现实应用场景中，该功能的实现方式包括但不限于：预先编程一脚本或者应用程序并将其安装于mes的操作系统中，由此在mes的设置界面中增加一例如“监控业务运行状况”选项；然后，用户通过开启或关闭该选项，即可对应开启或关闭该功能。

也就是说，本申请实施例可以利用计算机软件实时监控mes自身的业务运行状况，以此弥补mes业务监控的空白，及时了解mes业务的健康状况，并且及时响应生产异常情况，便于运维等操作人员主动做出及时应对，化被动为主动，另外，无需操作人员在每一台服务器进行日志文件内容的查询，从有利于提高mes的运维效率。

请参阅图2所示，本申请实施例监控mes自身的业务运行状况，不仅可以便于日志文件的查询，还可以至少对四种异常情况进行监控。下面结合以下实施例对此进行详细介绍。

图3是本申请的mes日志文件的分析方法一实施例的流程示意图。如图3所示，所述mes日志文件的分析方法包括如下步骤：

s31：读取mes的分布于多台服务器上的应用程序的日志文件。

s32：根据所述日志文件进行采样以获取采样时段内的消息输出量，并将获取的采样时段内的消息输出量上报至集成监控平台。

步骤s32可视为监控mes的业务运行信息中的日志文件分析(loganalysis)，具体地，各台服务器产生的日志文件初步归集到一起，利用软件实时读取每一日志文件的内容，通过统计关键词进行采样，采样的关键词可以包括反应采样时段及消息输出量的字符，再将数据上报到前端监控集成平台，最终呈现出消息输出量的实时示意图。该图的横坐标可以为时间，纵坐标可以为消息输出量。

由此，本实施例可以实时监控mes的消息输出量，及时发现和预防msg爆量，避免引起数据堵塞，确保mes处理业务的效率。

图4是本申请的mes日志文件的查询方法一实施例的流程示意图。如图4所示，所述mes日志文件的查询方法包括如下步骤：

s41：读取mes的分布于多台服务器上的应用程序的日志文件。

s42：接收用于读取日志文件的查询请求，该查询请求包含关键词。

s43：搜索所述日志文件中与所述关键词相匹配的记录并回传。

步骤s42和s43可视为监控mes的业务运行信息中的日志文件查询(logview)，具体地，各台服务器产生的日志文件归集到一起，由前端发送查询请求到后台，以读取各台服务器产生的日志文件，搜索符合条件(即与查询请求中关键词相匹配)的日志记录，再通过tibcorv(mes使用的消息中间件)传输结果回前端，供相关操作人员分析。由此，本实施例可以避免操作人员到每台服务器上手动搜索日志文件这一重复繁琐劳动。

图5是本申请的mes第一种异常情况的监控方法一实施例的流程示意图。如图5所示，所述监控方法包括如下步骤：

s51：监测是否存在应用程序未产生日志文件。

在测到未存在应用程序未产生日志文件时，执行步骤s53。在测到存在应用程序未产生日志文件时，执行步骤s52。

s52：在监测到存在应用程序未产生日志文件时上报集成监控平台。

s53：读取mes的分布于多台服务器上的应用程序的日志文件。

s54：根据所述日志文件监控mes的业务运行信息。

步骤s51和s52可视为监控mes的业务运行信息中的故障跟踪监控(trackoutfailmonitor)，具体地，本实施例对关注度高及重要的业务实时监控，当业务受阻及发生异常时监控软件抛出异常(throwexception)，同时将异常内容通过tibcorv上报到监控集成平台，以便于相关操作人员实时感知到业务异常现状，进而采取有效措施。

图6是本申请的mes第二种异常情况的监控方法一实施例的流程示意图。如图6所示，所述监控方法包括如下步骤：

s61：读取mes的分布于多台服务器上的应用程序的日志文件。

s62：根据所述日志文件统计每一服务器上的应用程序运行时出现错误代码的次数。

s63：在预定时间段内错误代码的发生次数超过预定次数时，将包含错误代码的告警消息发送给操作人员。

步骤s62和s63可视为监控mes的业务运行信息中的业务运行错误告警(erroralarm)，具体地，在业务发生异常、在监控软件抛出异常的同时，将异常情况收集并写入到日志文件数据库(该数据库存储有所有日志文件的信息，其中的数据又称mesdbaplog)中，作为数据源。监控程序定时统计错误代码，根据预先设定的监控规则，当符合警告阀值，例如预定时间段内错误代码的发生次数超过预定次数时，则将错误代码发送给相关人员，用于提前预警可能会发生的异常。其中，错误代码发送给相关人员的方式包括但不限于为邮件或微信等。

图7是本申请的mes第三种异常情况的监控方法一实施例的流程示意图。如图7所示，所述监控方法包括如下步骤：

s71：读取mes的分布于多台服务器上的应用程序的日志文件。

s72：在监控到服务器在超过预定时长后未输出日志文件，将包含服务器信息的告警消息发送给相关操作人员。

步骤s72可视为监控mes的业务运行信息中的服务器停止告警(serverstopalarm)。服务器正常工作时会有日志记录输出，通过实时监控日志记录的输出情况，若某一服务器超过一定时间无日志记录输出，说明该服务器已经处于停止状态，此时监控软件可以通过发送邮件或微信提醒相关人员及时跟进异常情况。其中，本步骤的数据来源于存储有所有日志文件信息的数据库，其中的数据又称mesdbaplog。

图8是本申请的mes第四种异常情况的监控方法一实施例的流程示意图。如图8所示，所述监控方法包括如下步骤：

s81：读取所述mes的数据库中的业务监控参数。

该mes的数据库又称之为mes的业务数据库(mesdb)，因此该业务监控参数又称之为mesdbtransactiondata。

s82：在监测到业务监控参数中缺少开始信息或结束信息的应用程序，以及开始信息至结束信息的时长超过预定时长时，将包含应用程序的告警消息发送给操作人员。

s83：读取mes的分布于多台服务器上的应用程序的日志文件。

s84：根据所述日志文件监控mes的业务运行信息。

步骤s81和s82可视为监控mes的业务运行信息中的业务运行监控(transactionmonitor)，具体地，本实施例收集各项业务的“开始”及“结束”记录，形成对业务的监控：结合“开始-结束”数据组，可监控业务有“开始”却无“结束”，也可监控业务超时之类异常情况，以便于让运维人员及时了解mes业务的健康状况。

图9是本申请一实施例的mes的监控装置的结构示意图。如图9所示，所述mes的监控装置90包括读取模块91和监控模块92。

读取模块91用于读取mes的分布于多台服务器上的应用程序的日志文件。

监控模块92用于根据所述日志文件监控mes的业务运行信息。

其中，读取模块91和监控模块92的工作原理及过程可以参阅上述mes的监控方法，此处不再予以赘述。

本申请实施例的mes的监控装置90可以实时监控mes自身的业务运行状况，以此弥补mes业务监控的空白，及时了解mes业务的健康状况，并且及时响应生产异常情况，便于运维等操作人员主动做出及时应对，化被动为主动，另外，无需操作人员在每一台服务器进行日志文件内容的查询，从有利于提高mes的运维效率。

应该理解到，上述模块的划分为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如两个模块可以集成到另一个系统中，或一些特征可以忽略，或不执行。另外，模块相互之间的连接可以通过一些接口，也可以是电性或其它形式。上述模块既可以采用软件功能框的形式实现，也可以采用硬件的形式实现。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。为此，本申请实施例提供一种可读存储介质，该可读存储介质中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种mes的监控方法中的步骤。

由于该可读存储介质中所存储的指令，可以执行本申请实施例所提供的任一种mes的监控方法中的步骤，因此，可以实现本申请实施例所提供的任一种mes的监控方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

尽管已经相对于一个或多个实现方式示出并描述了本申请，但是本领域技术人员基于对本说明书和附图的阅读和理解将会想到等价变型和修改。本申请包括所有这样的修改和变型，并且仅由所附权利要求的范围限制。特别地关于由上述组件执行的各种功能，用于描述这样的组件的术语旨在对应于执行所述组件的指定功能(例如其在功能上是等价的)的任意组件(除非另外指示)，即使在结构上与执行本文所示的本说明书的示范性实现方式中的功能的公开结构不等同。

即，以上所述仅为本申请的实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，例如各实施例之间技术特征的相互结合，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

另外，在本申请的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。另外，对于特性相同或相似的结构元件，本申请可采用相同或者不相同的标号进行标识。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本申请中，“示例性”一词是用来表示“用作例子、例证或说明”。本申请中被描述为“示例性”的任何一个实施例不一定被解释为比其它实施例更加优选或更加具优势。为了使本领域任何技术人员能够实现和使用本申请，本申请给出了以上描述。在以上描述中，为了解释的目的而列出了各个细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本申请。在其它实施例中，不会对公知的结构和过程进行详细阐述，以避免不必要的细节使本申请的描述变得晦涩。因此，本申请并非旨在限于所示的实施例，而是与符合本申请所公开的原理和特征的最广范围相一致。