监控Exchange部署并不新鲜，但管理员应该做的事情发生了巨大变化。

如同其他应用一样，保持Exchange健康很关键。不辜负这个任务很难的，有时候Exchange就是坏了，没办法呀。因此，你能告知为什么它会坏或者什么时候它会坏么？

有种方法就是等人在抱怨你就知道Exchange出问题啦。虽然这种方式很实际，但附带的是糟糕的终端用户体验，可能会在以后发生灾难性后果。就如某个备份连续五天出问题，第六天磁盘就崩溃了，这就不好办了。

这个挑战并不新，自从IT系统出现的那天起就一直存在。监控也不新，但是监控的东西与手段发生了变化，尤其是监控Exchange部署。

我该监控啥？

监控对象是一个常常提及的问题。该问题太泛，所以答案也不明确。事实上，我能给的最佳答案是“随机应变”。

没有万能的方式监控Exchange部署。企业应该盯着一些基本组件，如磁盘空间使用率、CPU或服务状态。但问题不在于此。

你应该监控直接或间接影响终端用户体验的组件。虽然监控到Outlook Web的访问很有意义，但如果没人用监控它没有意义啊，坏了都没人理睬。我不是提倡不去监控你不太常用的组件。我只是指出它对你的意义没有其他的对你重要。

一些关键Exchange组件与每个人都有关，包括数据库健康与Client Access组件。数据库不健康就可能会丢失数据。如果没有健康的客户端访问基础脚骨，就无法访问数据。所以这两个组件必须监控，然后使用告警体系，让信息主动传送到你面前。

这可能是现在大家用的最普遍的监控方式，但作用却不大。查看所有的通知与告警所需要的时间忒多了。我看到很多这样的案例，IT部门都不再去查看告警，就让他们响着，实在没时间处理。

被动监控

本质上有两种方式监控Exchange。第一种是被动监控你的环境。这意味着你，或者监控工具，比如通过应用日志查看Exchange发出的信息。你可以有效地利用Exchange产生你监控所需的数据。

Exchange 2013产生大量的数据，给你一个运行状态的直观概念。不过，大量的数据意味着你在筛选时需要大量时间。找个工具帮你筛选以节省时间吧。

被动监控的另一个问题在于不能让你主动出击，至少无法使用额外的工具对数据进行分析。你所使用的工具不经能从应用日志读取警告，然后发出警告。相反，它能看到警告并决定其是否有意义。如果没有，就不应该产生警告，至少也能够追踪。

主动监控

在主动监控中，你主动去测试组件与功能，并产生报告。你经常将这种类型的监控看作是合成交易。合成交易是诸如监控软件执行脚本、模仿终端用户行为的行动。这种方式能覆盖更多事物，允许你提前检查所有功能是否正常运行。Exchange的Managed Availability使用的就是这种方法。