20.规则监控

简介

​ 规则监控针对的是对知识包调用的监控。在URule Pro当中,规则是放在知识包是调用的,所以规则监控也就是对知识包的监控。

​ 打开项目的知识包页面,在已启用的知识包上点击右键,在弹出菜单中选择知识包调用监控配置,如下图所示:

​ 点击该菜单项,即可打开针对当前知识包的监控配置窗口,如下图所示:

​ 勾选“启用对当前知识包的调用监控”选项,即可开始配置具体的要监控的信息。

监控配置

​ 勾选“启用对当前知识包的调用监控”选项后,就可以看到具体可配置的监控选项,整个监控的选项分为两个部分,既输入数据以及输出数据。

​ 当前知识包中规则如果开启“允许调试信息输出”属性,同时运行项目中将urule.debug属性配置为true,那么监控时会自动记录规则运行时产生的日志。

之前我们对规则中“允许调试信息输出”属性以及运行项目中urule.debug属性有过介绍,要求在生产环境中一定要把urule.debug属性设置为false,这样所有的调试信息都将不再产生,就不会对性能产生影响。

​ 监控配置窗口会把当前知识包中用到的所有变量及参数根据其用途属性罗列出来,我们需要做的就是根据需要进行勾选,这样在监控运行时会所勾选的输入以及输出信息都记录下来,给我们自定义的监控实现类使用。

监控配置窗口在输入数据部分只会罗列变量及参数中用途为In及InOut类型,输出只会罗列Out及InOut类型。

注意:监控操作针对的是规则的执行,规则执行调用的是已发布的知识包,因此,监控中配置的输入和输出变量及参数也是来自当前知识包中处于启用状态的已发布的知识包。所以配置知识包监控,要确保当前知识包已经发布,且处于启用状态的已发布的知识包必须是我们需要的那个。

​ 如果我们当前调用规则采用的是Rest服务方式,那么配置好监控内容后,在通过Rest服务调用规则时系统会自动根据这里的配置对规则调用进行记录监控,无须再做别的配置;如果我们使用的是API方式调用规则,那么还需要编写具体的监控数据处理实现类,该类编写完成后需要配置到Spring上下文中,使其成为一个标准的Spring Bean,这样引擎才能发现并使用它,该类接口源码如下:

package com.bstek.urule.runtime.monitor;
/**
 * @author Jacky.gao
 * @since 2018年12月17日
 */
public interface InvokeMonitor {
    void doMonitor(MonitorData data);
}

​ 在这个接口中,需要实现的方法只有一个,参数也只有一个,在这个MonitorData参数里,已经把上述知识包监控配置里要求监控的内容都准备好了,我们直接调用即可,MonitorData源码如下:

package com.bstek.urule.runtime.monitor;

import java.util.List;

import com.bstek.urule.model.rete.RuleData;
import com.bstek.urule.runtime.log.FlowNodeLog;
import com.bstek.urule.runtime.log.Log;
import com.bstek.urule.runtime.log.MatchedRuleLog;

/**
 * @author Jacky.gao
 * @since 2018年12月18日
 */
public interface MonitorData {

    /**
     * @return 返回当前监控的知识包名称信息:项目名称/知识包ID
     */
    String getPackageInfo();

    /**
     * @return 返回规则运行总的耗时,单位为毫秒
     */
    long getTotalDuration();

    /**
     * @return 返回当前知识包版本,如果当前知识包没有发布版本,则该值为空
     */
    String getVersion();

    /**
     * @return 返回所有匹配的规则对象信息
     */
    List<MatchedRuleLog> getMatchedRuleList();

    /**
     * @return 返回所有不匹配的规则对象信息
     */
    List<RuleData> getNotMatchRuleList();

    /**
     * @return 返回所有触发了的规则流节点信息(如果当前有规则流的话)
     */
    List<FlowNodeLog> getFiredFlowNodeList();

    /**
     * @return 返回所有输入日志信息(如果当前配置的日志信息输出的话)
     */
    List<Log> getLogs();

    /**
     * @return 返回指定的输入信息
     */
    List<IOData> getInputData();

    /** 
     * @return 返回规则计算后指定的输出信息
     */
    List<IOData> getOutputData();

}

​ 可以看到,在MonitorData接口中,可以获取到当前知识包监控配置的所有信息,这样在记录这个信息时可以先判断系统是否配置了要监控这项信息,以防获取到的信息为空情况发生。下面的这个实现类在输出要监控的信息时就加了判断:

package test;

import com.bstek.urule.runtime.monitor.InvokeMonitor;
import com.bstek.urule.runtime.monitor.MonitorData;

/**
 * @author Jacky.gao
 * @since 2018年12月17日
 */
public class TestInvokeMonitor implements InvokeMonitor {

    public void doMonitor(MonitorData data) {
        System.out.println("日志:"+data.getLogs());
        System.out.println("触发的规则节点列表:"+data.getFiredFlowNodeList());
        System.out.println("匹配的规则列表:"+data.getMatchedRuleList());
        System.out.println("不匹配的规则列表:"+data.getNotMatchRuleList());
        System.out.println("耗时:"+data.getTotalDuration());
        System.out.println("packageInfo:"+data.getPackageInfo());
        System.out.println("输入数据:"+data.getInputData());
        System.out.println("输出数据:"+data.getOutputData());
    }
}

需要注意的是,如果我们使用URule Pro的方式为客户端服务器模式,同时又想对知识包调用进行监控,那么InvokeMonitor的实现类则必须配置在知识包实际运行的客户端,原因很简单,因为知识包是在客户端运行,要监控知识包,必须要保证当前知识包运行环境里能检测到InvokeMonitor的实现类,所以需要这么配置。

results matching ""

    No results matching ""