介绍在这个系列的第1部分中，我们讨论了MPs，在第2部分中我们做了准备，导入了一个MP并创建了一个override MP。在第三部分中，我们探讨了这些发现。既然我们了解了这些发现，我们可以从管理包的其他各个部分开始。其中一个将变得非常关键，那就是凌驾于监管者和规则之上。重写并不意味着禁用或单独启用。这也意味着调整默认阈值，以便它们更好地匹配您的基础架构。有不同的方法来做这个或者从这个开始。我见过不同的人在微调过程中都取得了成功，每个人都使用不同的方法。这取决于你喜欢如何工作，以及什么适合你公司的工作流程/方法。"到时候我会微调"的方法不是我最喜欢的那个，但在我工作过的许多环境中都被证明是非常有用的。导入管理包后，我们等待警报出现。那时，我们会调查这是一个真正的警报还是警报不适合我们的环境。例如，导入Veeam Management Pack For System Center后，我们可能会看到基于虚拟机快照的警报。经过与相关团队的讨论，我们决定默认阈值对于我们的环境是不正确的。因此，我们决定根据我们的具体需求调整阈值。稍后您将看到该过程先查看监视器进行微调这是我喜欢的工作方式。从导入管理包的那一刻起，我们就检查所有不同的监视器和规则，并立即对它们进行微调。当你这样做，你又有两个方法。一些管理包在文档中包含了所有必需的信息，而另一些则没有。最后，运行基于特定管理包的规则并对其进行微调并不困难。更困难的是做决定。您不仅需要决定严重性、优先级、阈值，有时还需要确定覆盖是针对整个环境还是针对选定的一组对象。以一个监视器为例，监视器是Veeam HyperV:VM Checkpoint Analysis，有以下配置（如手册所示）目标默认阈值说明Hyper-V虚拟机检查点年龄>48检查点大小MB>2048状态始终=警告。优先级始终=低（可覆盖）此监视器跟踪以下检查点属性的阈值违反情况：·Checkpoint Age Hours—以小时为单位的最旧检查点的年龄·Checkpoint Size MB—所有检查点的总大小（MB）当VM上的检查点超过48小时或大于2GB时，它将触发低优先级警告。在我的具体情况下，在与虚拟化团队达成一致后，我希望将此更改为对我的生产虚拟机具有高优先级的警报，但我希望它仅作为优先级较低的信息，仅适用于我的开发人员虚拟机。我还想将该环境的小时数增加到168，大小增加到10GB。现在我构建了两个动态组，一个用于生产虚拟机，一个用于开发人员虚拟机，并将我的虚拟机放入正确的组中。手动或动态基于参数。有关动态组的详细信息，请访问：之后，我可以选择覆盖并对其进行两次覆盖。一个给生产组，一个给开发组。确保将覆盖保存在以前创建的覆盖管理包中。如果警报已经存在，我可以覆盖警报文件夹中的警报，或者转到Authoring->Monitors并在那里搜索它。通过右键单击监视器，我可以选择覆盖->覆盖监视器->对于一个组…结论您喜欢使用哪种方法取决于您自己，并且应该与您所在公司使用的特定环境和方法的要求相匹配。但是，执行此任务非常重要，并且在假定监控器为误报时，不要在默认情况下禁用监控器。只有有一个明确且一致同意的框架/方法才能确保以后不会出现问题。最后，确保管理层确信需要在这件事上投入时间和精力。他们已经投资了System Center套件，如果因为停止进一步投资而损失了这笔投资，那将是一个遗憾。 更新：你导入了一个管理包现在什么…第1部分你导入了一个管理包现在什么…第2部分你导入了一个管理包现在什么…第3部分你导入了一个管理包现在什么…第5部分你导入了一个管理包现在什么…第6部分VN:F[1.9.22_1171]评级：5.0/5（1次投票）您导入了一个管理包，现在是什么…第4部分，基于1个评级的5分之5