patrol

进程监控配置说明

1.前期介绍

进程的监控方法有两种，一种是通过PatrolAgent代理自带的进程监控的KM去监

控，另外一种也可以通过自动巡检去监控，两种方法都可以实现对进程的监控，但是也

各有区别，自动巡检的监控粒度不能过于频繁，而PatrolAgent代理的进程监控KM可

以实现一分钟监控采集一次的效果，所以PatrolAgent代理监控进程信息略微优于自动

巡检监控进程，当然也得按照现场的情景来做取舍，两者没有本质的区别和优劣之分。

2.监控配置

2.1Unix/Linux进程监控配置

首先确定在Console端确保Agent端的进程监控KM正常，如下图所示

附注：进程监控最好在DCM模式下进行配置，如果不是DCM模式，有可能会导致无法正常

采集到进程的信息。

其次，右键点击PROCESS_PRESENCE选择如下图所示的选项，

会出现如下图所示的的配置界面，

下面以新建一个进程监控为例，详细说明下在配置过程中需要注意的问题，在上图的界面中

选择AddNewProcess选项，然后选择确定会出现如下所示的新建配置界面

上图中方框区域为必填项，非方框区域为选填项，以下说明这些配置的注意事项：

ProcessInstanceLabel：监控进程的实例标签，不能含某些特殊符号（必填项）

MonitorProcessString：填写需要监控的进程的详细信息（必填项）

MinimumCount：进程的最小个数（必填项）

MaximumCount：进程的最大个数（必填项）

AcceptableProcessOwners：该进程正常的属主（可选项）

ParentProcessIDMustBe1：进程的父ID必须为1，有YES和NO两个选项（可选项）

*UProcessOwnersforFiltering：该选项9800版本（含9800）以上才有该选项，9800以下

无该选项，该选项框选定代表已AcceptableProcessOwners框里输入的属主信息进行过滤统

计

AcceptableProcessOwners选项填写属主信息---------------出现---------------PROCPPOwnerCheck

当AcceptableProcessOwners选项填写属主信息并勾选UProcessOwnersforFiltering，

console上就不会再出现PROCPPOwnerCheck的指标了，因为内部已经是按照这个属主去进

行过滤统计了，所以没必要再出现进程属主用户的检查了。

ParentProcessIDMustBe1选项当选择YES时----------------出现---------------PROCPPParentPID1

以上图大概说明了配置信息与最终Console端的展示的关系。

***********************************注*****意***********************************

最最重要的一个配置信息是MonitorProcessString在此详细说明一下，这块输入的信息是

Patrol去主动监控采集的进程的信息，所以首先得保证准确无误，并且尽量保证该进程信息

在系统中唯一（Patrol进程监控默认是去模糊匹配的），比如要监控的进程是abc,如果直接

在MonitorProcessString输入abc，那样如果有用户执行viabcabc或者viaaabc或者tail–f

*.txt|grepabc等等操作就会导致在进程信息中这些本不该算做真实进程abc的信息伪装成

真实的abc被监控程序所统计，这样就会导致进程统计的个数有问题，但是真实情况是正常

的，这是进程监控的一个漏洞（之前我们项目就遇到过类似的案例），最终比较合理的解决

方案就是在MonitorProcessString中配合使用正则表达式比较精确的去匹配要监控的进程，

例如上面的那种情况，就可以在MonitorProcessString输入^abc$，通过正则表达式中的^符

号代表以某个字符开头，$符号表示以某个字符结尾，这样^abc$意思就是以字母a开头，并

以c结尾的abc这个字符串的信息，这样也就过滤了vi进程名或者grep进程名的这种特殊

情况，所以大家以后在配置进程监控的时候最好注意这块哦，当然这块也可以灵活应用，反

正保持的原则和遵旨就是这块填写的信息尽快能在进程信息能唯一标识该监控进程。

温馨提示：正则表达式的符号貌似有些操作系统不识别的，所以大家最好在配置的时候做下

测试，如果监控字段含有正则表达式符号之后采集进程个数的指标可以正常采集到数据，说

明就可以正常使用正则表达式符号，否则就不能用这些正则表达式符号了。

同时由于DCM或者PSL模式的问题或者别的原因也可以考虑使用新开发的进程监控KM。

2.2Unix/Linux进程监控告警标准化

以下对进程监控下的所有指标进行简单说明：

PROCPPCount:被监控进程的进程个数

PROCPPCPUPerc：被监控进程占用CPU的百分比

PROCPPMem：被监控进程占用内存大小

PROCPPVmSize：被监控进程占用虚拟内存大小

PROCPPCountCheck：被监控进程的个数检查

PROCPPOwnerCheck：被监控进程属主的检查

PROCPPParentPID1：被监控进行父ID是否为1的检查

PROCPPStatus:被监控进程的状态信息

在告警标准化的过程中，根据现场的要求需要选择能满足要求的指标来进行告警的传递和阀

值的设置，默认patrol的进程监控是用PROCPPCountCheck指标去做告警的传递的，这个指

标的0代表正常，即满足配置进程个数最小值≤该进程的当前值≤配置进程个数最大值

2代表进程个数异常该进程个当前值≤配置进程个数最小值或者该进程个当前值≥配

置进程个数最大值，如果通过这个指标去传递告警信息只能知道进程个数异常，无法知道到

底是小于最小值了还是大于最大值了，告警信息比较模糊，所以不建议用该指标进行传递。

经过多次测试，用PROCPPCount该指标能较PROCPPCountCheck合理点，理由有以下两点：

A．PROCPPCount指标可以传递当前的监控进程的个数，便于告警内容的合理人性化展示；

B.可以设置不同的告警区域，比如被监控的进程个数正常应该是1个，就可以设置两个告

警区域，[0-0]为主要告警，[2-5]为主要告警，当当前个数为1的时候就属于正常情况，

当前个数不为1的时候就会触发告警，如下截图，可以根据实际情况设置一个告警阀值，

或者设置两个告警阀值。

以上是使用PROCPPCount指标进行告警传递的好处，如有更好的方案希望分享哦。

接下来是UltraNMS端的配置，如下图所示：

事件所属分组：PROCPRES_PROCPPCount

事件内容：#resParentAppSys：Unix服务器#moIP的@instance进程个数异常，当前值为@value，

告警范围为[@min个-@max个]，发生时间：@occurTime，可以正常显示进程当前值，告警

范围，时间等用户关注的信息。

告警界面展示：

2.3Windows进程监控配置

Windows的进程监控只能选择已有的进程信息进行监控，

选择AddProcess选项之后会出现如下界面，

此区域信息类似于Windows的任务管理器，将当前的进程信息都已经列在其中，只需要在

里面找到需要监控的进程名，选中然后点击Add按钮并确认OK就可以了。在console端就

可以看到该监控进程的信息了（上面以java进程为例）

Windows进程监控相对于Unix进程监控灵活性欠佳

2.4Windows进程监控告警标准化

建议采用PROCStatus采数作为告警传递的变量，告警标准化的配置与之前类似，就不再累

赘了。