上节我们对CPU负荷进行监视警报,本节我们来设定对于内存的监视。


Sharepoint监控②:硬件监视之内存监视

警报阈值:


服务器

DB1

DB2

APP1

APP2

SCH1

WFE1

WFE2

DB3

DC

内存            
Available MBytes

1000

1000

1000

1000

1000

1000

1000

1000

1000



1. 配置内存监视

我们还是进入创作—>监视器—>Windows Server 2012 R2 FULL Operating System—>性能中

发现默认对内存的监视器有Available Megabytes of Memory和Memory Pages Per Second

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第1张图片

这里我们替代Available Megabytes of Memory,即可用内存的阈值,替代值改为1000MB。

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第2张图片


2. 测试警报

因为我这实验环境,内存配比不多的关系,设置生效后不久,就收到大量邮件,都是关于内存不足的 System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第3张图片

进入活动警报,也可以发现大量警报,但怎么都长得一个样,怎么来简单区分到底由哪个服务器发出的警报?

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第4张图片

右键点击个性化视图

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第5张图片

勾选路径后点确定使个性化视图生效

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第6张图片

这样,就能一目了然的知道到底是那台服务器的警报了。

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第7张图片

现在全选所有警报后,右键菜单点击关闭警报。

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第8张图片

可以到所有警报中查看到解决状态为已关闭(这个时候还是可以手动改变解决状态的)

System Center 2012 R2实例3—SCOM之SharePoint全方位监视9—内存监视_第9张图片

这样,直到内存恢复空闲之前都不会有活动警报通知了。


3. 监视器的警报的理解

监视器衡量托管对象某个方面的运行状况,各具有两个或三个运行状况状态。 无论何时,监视器将处于一种且仅处于一种其潜在状态。代理加载监视器时,会将监视器初始化为正常状态。 只有当检测到另一种状态的指定条件时才会更改此状态。

创建监视器时,必须为其每个运行状况状态指定一个条件。 当满足这些条件之一时,监视器会更改为该状态。每个条件都必须是唯一的,这样,在特定时间只能有一个条件为真。 如果监视器更改为“警告”或“严重”状态,则它可能会根据需要生成警报。 如果它更改为“正常”状态,则可以根据需要自动解决以前生成的任何警报。


只有当以下每项均成立时才会从监视器中生成警报:

1)将监视器配置为生成警报。

2)监视器的运行状况状态已从正常状态更改为警告或错误状态,具体取决于可能的监视器运行状况状态。

3)相同监视器创建的相同对象还没有打开的警报。

只有当监视器的运行状况状态从“正常”状态发生更改时,才会从监视器中生成警报。 即使错误情况的条件可能出现多次,在将监视器的运行状况状态设置为“警告”或“严重”后也不会生成多个警报。只有在监视器的运行状况状态返回为“正常”并且再次出现错误条件之后,才将生成新警报。


所以此实验环境中,即使现在可用内存警报状态为已关闭,由于可用内存并未恢复正常(大于1000MB),所以不会再有新的活动警报出现。只有当可用内存大于1000MB(恢复正常,重置监视器)后再次小于1000MB(超过阈值),这时才会再次出现警报。