*更多关于SCOM的详细内容，请关注我的资料*
SCOM是通过管理包和代理共同完成被监视设备（被监视的设备也称之为SCOM代理）的性能和事件的收集，所以要让SCOM启动对服务器的监视，首先需要完成两个步骤：
- 下载、解压并在SCOM管理控制台将SCOM管理包导入SCOM运行数据库。
- 在要监视的服务器上安装SCOM代理。
安装在服务器上的SCOM代理和SCOM服务器之间构建起所有监视信息传递的通道，或者也可以理解成桥梁。该通道的作用如下：
- 负责分发SCOM策略给被监视的设备，比如开启或关闭某个组件的监视，监视频率的更改等。
- 传递由SCOM发起的操作指令，比如Ping代理服务器、远程桌面连接代理、列出代理服务器进程和服务、远程执行代理的PowerShell命令、
- 负责传输从被监视的服务器上收集的事件和性能。
只有代理，SCOM还无法收集事件和性能数据了，因为，SCOM代理并不知道要在哪些服务器上收集、收集哪些性能和事件数据、用什么样的频率进行收集，以及收集后如何归总和展现性能视图等等。要完成这些，必须要导入SCOM管理包，使用管理包中预定义的策略进行性能和事件的收集、归总和展现。
微软免费提供很多管理包，包括微软自己和其他厂商的系统和应用。管理包中具备以下对象帮助我们收集和展现系统和应用的性能：
对象发现
一台服务器安装操作系统后，会有非常多的组件，如果再安装不同的林林总总的应用，SCOM怎么知道要收集哪些组件的性能或者事件呢？所以管理包第一步也是关键的一步就是通过管理包定义要收集哪些组件的性能和事件（也即MIB库），比如导入Windows Server管理包可以发现CPU/内存/网卡/系统等，导入SQL Server管理包就能发现SQLServer的服务和组件……SCOM代理携带这些MIB信息就能识别出被监视服务器的组件。举个例子，Windows Server Operating System管理包将发现类型为WindowsServer 2008(R2)/2012(R2)/2016 的所有组件，包括内存、CPU、磁盘、网卡、系统等。默认情况下，对象发现有开启也有关闭的，如图1所示。
图1
如果默认关闭，就意味着即使导入了管理包无法发现这个对象里，比如CPU对象发现是默认关闭的，那么我们即使导入了Windows Server Operating System管理包也无法监视CPU的活动和性能，后面的性能收集也就无从下手了，这时需要手动开启CPU的对象发现。这也就是为什么CPU、硬盘的性能默认是无法收集的，因为SCOM根本没有发现服务器上的CPU和硬盘，还怎么监视呢？还有种请况就是SCOM默认发现周期很长，比如Exchange Server CAS对象需要导入Exchange Server 管理包后24小时之后才能被SCOM发现，所以用户安装SCOM管理包以后，也要等24小时才能看到Exchange Server CAS的状态。
管理包中的对象发现是只读的，意味着我们不可在SCOM控制台新建自己的对象发现，因为管理包已经限定了对象发现范围，我们只能修改对象发现，比如开启关闭发现，修改发现周期等。
性能/事件收集规则
SCOM本身不定义性能计数器，而是使用设备/系统/应用现有的计数器，比如Windows Server 内存计数器等等，这些计数器信息跟随导入的管理包存放在SCOM运行数据库中，只不过SCOM管理包里不会包含所有的性能计数器，因此SCOM数据库也不会存放所有的性能计数器，这也是为什么有时候我们找不到一些计数器，因而无法收集到某些性能。此时，我们需要自行添加计数器并插入到SCOM运行数据库里。规则里包含了要收集哪种对象（硬件、系统、数据库还是应用）、这个对象的版本、收集哪个性能和收集频率，比如一个名为Memory\% Committed Bytes In Use Windows Server 2012的规则将收集服务器的内存对象，版本为Windows Server 2012系统，收集频率为10分钟，计数器使用% Committed Bytes In Use。
默认情况下，管理包并不会开启所有的规则，这也是我们在SCOM控制台里默认无法看到某些性能结果，即使这个组件已经开启了对象发现，如图2所示。
图2
如果要启用未被启用的规则，我们需要通过替代规则的方式将其启用。为什么叫替代呢？因为导入的SCOM管理包通常是封装过的，是只读的，里面的所有属性和设置都不能直接在现有管理包中修改，而是通过将属性和设置复制出来进行修改，然后存放到未封装的管理包（我们自己可以在控制台创建的管理包），再插入到SCOM运行数据库。通常替代的规则比默认规则优先级高，比如逻辑磁盘可用空间规则的默认收集频率是10分钟，替代后的收集频率为5分钟，那么SCOM将5分钟收集一次逻辑磁盘可用空间。
管理包中的规则是可读写的，意味着我们既可在SCOM控制台新建自己的规则，也可以修改（实际上是替代）规则，比如开启关闭规则，修改发现周期等。
性能/事件监视器
SCOM监视器可以用来评估被监控对象的不同的状况和状态。比如，监视器可以用来评估性能计数器的值、事件生成、日志文件里面的数据生成、Windows服务器状态、SNMP陷阱跟踪。监视器和规则相同之处在于，它们都借用相同的计数器和事件日志进行事件和性能的监视。两者不同的是，监视器可以定义性能告警或者严重告警阈值，设置告警出发条件并且定义告警信息，以及设置事件恢复操作，而规则更倾向于收集，并且用在后续的任务中（比如自定义性能视图、服务级别跟踪等）。监视器可以向上进行树状聚合，比如一个父监视器由4个子监视器报告的状态聚合，4个子监视器分别监视不同的目标，这4个子监视器监视的对象是互相依赖的关系或者，所以4个子监视器报告的状态决定着父监视器的状态，如图3所示。
图3
子级单元监视器-父级聚合监视器这种结构中，父级聚合监视器的状态由SCOM管理包提供不同的算法获得，而算法又由实际对象之间依赖关系的亲疏决定，通常算法有以下几类，如图4、图5和图6所示：
- 子级单元监视全都正常，父级监视器才报告正常；
- 子级单元监视只要有一个正常，父级监视器报告为正常；
- 要求有一定的比例的子监视器正常，父级监视器才报告为正常。
图4
图5
图6
为了给大家进一步的说明，我们举个例子，5个子单元监视器监视分别监视一个群集中的5个节点的可用性，如果节点出现不可用的情况时监视器就触发告警，因为群集仲裁可以保证最多2个节点同时故障，所以父聚合算法可以遵循群集的仲裁机制，保证只要报告服务器不可用的子单元监视器不超过2个，父聚合监视器的状态就报告为正常。
多个父监视器状态还可以继续向上聚合，形成一个更为丰富的树状监视结构，这种模型更加利于综合性归总监控，如图7所示。
图7
和对象发现以及规则一样，默认情况下，管理包并不会开启所有的监视器，这也是我们在SCOM控制台里默认无法看到某些性能结果，即使这个组件已经开启了对象发现，也开启了规则，但是还是无法触发监视告警。
我们可以自建自己的监视器，在监视器里指定以下属性：
- 收集哪些设备/系统/应用的性能或者事件
- 要使用哪个计数器进行收集
- 收集哪一类日志
- 设置告警阈值和警告/错误触发条件
- 设置收集频率
如果要启用未被启用的监视器，我们需要通过替代监视器的方式将其启用，方法和规则替代一样，不再赘述。
服务级别跟踪
在导入的管理包后，某些应用程序会自带服务等级对象（SLO），这些SLO我们可以通过报表来展示他们在某段时间的可用性、停机、维护模式停机、未被监控的状况。通常我们会设置某个应用程序、主机或分布式应用程序在一段时间之内可用性的目标值（也即我们所说的SLA），比如设定邮件系统或者Web服务器在一个月的可用时间至少为99.99%，然后通过SCOM的监控来跟踪邮件系统或者Web服务器在这个月实际的可用时间并通过报表展现真实值，将这两个值进行对比获得的数值差就是域控制器服务级别的体现。
SCOM管理包对象中具备2种不同的SLO，分别是：
- 监视器状态，收集服务器的可用性，如图8所示
- 收集规则，设置性能阈值，监视服务器性能在阈值之内的时间，如图9所示。
图8
图9
创建好服务级别跟踪对象后，SCOM视图并不会默认展现出来，而是需要通过报表或者自定义视图将服务级别跟踪调出来。
任务
SCOM具备一些远程和控制代理的任务，这些任务针对不同的对象进行不同的操作，比如针对网络设备有网络设备的一些操作，针对系统有系统的操作。SCOM默认的任务将随着管理包的导入一起导入到SCOM数据库，比如Windows Server Operating System管理包里有针对磁盘有碎片整理、chkdsk、chkntfs以及获取卷信息的任务，针对系统有启动服务、启动计算机、ping、ipconfig、路由打印等任务。我们可以在代理出现问题的时候，使用SCOM任务在SCOM服务器上进行远程调试。
视图
SCOM视图是SCOM监视的展现元素，在SCOM控制台的监视窗口中，可以看到各种默认视图，都是在SCOM管理包中定义的。通常这些视图插入到SCOM运行数据库以后我们无法修改默认视图的结构和配置，如图10所示。但是我们可以新建视图结构和具体的视图。
图10
替代
从官方获取的SCOM管理包通常都是封装过的，无法直接更改管理包里面的对象发现、规则和监视器，而是要用替代的方法进行修改。替代实际上是复制属性之后，保存到未封装的管理包中，在插入到SCOM运行数据库里。我们可以在SCOM管理包对象的替代里查看所有被替代过的项目，这里汇总了所有被替代的项目条目，如图11所示。只要在这里双击替代的项目，就可以查看替代过的具体信息并且可以进一步修改。
图11