|
|
|
对每个组件运行和系统整体运营进行持续性监控的目的在于保证所有的软件和硬件都能得到最佳利用，确保所有的为业务服务的目标都能被实现。并且能够根据监控结果对组织业务量进行合理预测。在选择监控对象时，如果对所有组件都进行监控，其成本是相当昂贵的，也是相当难以实施的。因此，必须选择基础设施中对关键业务提供支持的组件进行监控。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这些监控数据大体上被分为两类，一类是监控系统容量（比如吞吐量），另一类是监控系统的性能（比如响应时间）。
|
|
|
|
对部分组件的监控活动应当设有与正常运转时所要求基准水平，亦即阀值。一旦监控数据超过了这些阀值，应当触发警报，并生成相应的例外报告。这些阀值和基准水平值一般根据对历史记录数据的经验分析得出。一种情况是为特定的组件设定监控阀值，比如监控一个CPU在某一小时内的使用率不超过80%；另一种情况是为特定系统服务设定基准水平，比如监控某一项在线服务的响应时间不超过2秒，或者该系统服务一小时内处理的服务请求数不能超过10 000。
|
|
|
|
以上这些阀值必须低于不影响该项资源（或者该项服务所依赖的资源）正常运转的最大值，或者低于服务级别协议（SLA）中规定的相应值。因此，超过阀值的时候应该还有机会采取纠正措施，以防止超过SLA规定，使得系统性能进一步恶化。
|
|
|
|
|
|
很多的系统服务级别协议都将终端用户响应时间（user response time）列为监控对象，但对这项监控需求的支持往往不力，在这介绍几种获取系统和网络服务的用户响应时间的方案：
|
|
|
|
（1）在客户端和服务器端的应用软件内植入专门的监控代码。这可以提供“端到端”的服务响应间隔或者定时采样，将系统总体响应分解为各个组成部件的响应。这类工具提供对应某一项服务的用户端真实的响应时间。
|
|
|
|
（2）采用装有虚拟终端软件的模拟系统。这类客户端系统上装有终端模拟软件和专门用于检测作业响应时间的软件，它们可以提供“端到端”的服务响应时间，尤其针对复杂的多阶段作业可以提供具有代表意义的时间响应值。与前一种相比，这里提供的响应时间是虚拟的，而不是真实的。
|
|
|
|
（3）使用分布式代理监控软件。分散在网络各节点（比如Internet上不同的国家）的代理组成了一个分布式监控系统，它可以生成大量来自不同地域的作业，并不定期对它们进行监控评测。这类响应时间数据也不是真实用户的响应时间。
|
|
|
|
（4）通过辅助监控设备来跟踪客户端样本。这种方法依赖于网络监控系统，即通常被安插在合适的网络节点位置的“嗅探器”。“嗅探器”可以定时监控和记录通过某一网络节点处的通信量。而对这些记录下来的通信量做进一步分析便可以得到服务的响应时间。这类响应数据与真实世界的数据的相似和接近程度取决于“嗅探器”在系统基础架构中的物理和逻辑位置。
|
|
|
|
当然在很多情况下，以上这些系统或者方法常常会被混合使用。由于IT系统涉及到众多的单位和部门，以及种类繁多的信息技术，对响应时间的监控是一个相当复杂的过程。
|
|
|
