本书介绍了 Sun JavaTM Enterprise System (Java ES) 的 Monitoring Framework 2.0 和 Monitoring Console 1.0 组件。这些组件一起实现版本 5 中引入的新的监视功能。
本指南中的过程说明了如何为每个安装的组件启用 Monitoring Framework,以及如何在 Monitoring Console 中查看所有受监视的数据。本指南未阐述此框架之外各个组件可能实现的日志文件、错误消息及其他监视机制。Monitoring Framework 和 Monitoring Console 都不提供对受监视的组件进行管理的功能。有关管理某个组件的信息,请参见该产品附带的文档。
本章介绍监视概念并说明 Monitoring Framework 的体系结构。
本章包括以下各节:
Sun Java System Monitoring Framework 提供用于为组件提供程序设备并公开其属性以便观察的基础结构。它根据行业标准通用信息模型 (Common Information Model, CIM) 规范定义受监视对象的分层结构,该结构称为通用监视模型 (Common Monitoring Model, CMM)。每个产品组件公开了提供其可观察属性的对象,节点代理聚合一个主机上多个组件的视图。Monitoring Framework 还提供了收集操作统计信息以及基于用户定义的阈值定义报警的机制。
Sun Java System Monitoring Console 是用于监视 Java ES 组件的图形界面。它包括一个连接到 Java ES 部署中所有节点代理的主代理。Monitoring Console 是基于 Web 的应用程序,它依赖于可在任何位置通过 HTTP 访问的 Sun Java System Web Console。在主屏幕上,它提供所有已启用的组件的汇总状态,包括所有已触发的报警。这样,您可以访问每个组件中受监视对象的分层结构,并且可以查看所有受监视属性的详细状态和实时值。通过 Monitoring Console 界面,可以显示任何报警的详细信息,确认该信息,或者基于任何属性创建新的监视规则。
监视是收集运行时数据,公开这些数据,以及计算服务质量标准以便系统管理员可以评估性能并接收报警通知的整个过程。在运行时操作过程中,管理员仅需与 Monitoring Console 交互即可查看性能统计信息、创建自动监视规则以及确认报警。但是,了解 Monitoring Framework 的体系结构以及 Monitoring Framework 如何连接到 Monitoring Console 对执行配置、故障排除和高级监视是有所帮助的。
Java ES 中的监视基于以下概念:
通用监视模型 (Common Monitoring Model, CMM) 确保所有 Java ES 组件公开统一对象和可比较属性的值。
CMM 接口定义的 Java 对象为产品组件提供标准化的程序设备。
节点代理公开系统上安装的所有组件的所有受监视对象,并管理这些对象的统计信息、规则和报警。
独立主机上的主代理聚合所有节点代理的所有受监视对象,并使数据可为 Monitoring Console 使用。
以下各节分别对监视体系结构的这些概念进行了更详细的介绍。
标准化监视机制的基础是定义受监视的对象并在所有受监视的组件中应用这些对象。为此,监视体系结构将通用监视模型 (Common Monitoring Model, CMM) 定义为由分布式管理任务组 (Distributed Management Task Force, DMTF) 维护的通用信息模型 (Common Information Model, CIM) 的扩展。CMM 既是信息模型(指定受监视的对象,如计算机、应用程序等),也是数据模型(指定统一值,如操作状态值)。作为信息模型的一部分,CMM 还定义对象的属性(例如由服务处理的请求数)以及对象之间的关系(如在某台计算机上托管某个服务的事实)。
由于 CMM,一些概念(如应用程序、服务、访问点等)对于所有产品组件都是相同的,即使底层实现不同也如此。例如,Web Server 可能公开用于处理 HTTP 请求的服务,而 Directory Server 可能公开用于处理 LDAP 请求的服务。但是,标准对象会捕获这两种功能的公共特性,例如可以度量已处理的请求数,给定时间段内响应请求的平均时间,等等。
而且,某些数据值已标准化,这样其含义在整个系统中是统一的。例如,不论正在监视的是什么产品组件,操作状态 DEGRADED 始终意味着服务仍然可用,但性能已极大下降。
CMM 规范体现在用于程序设备的 Java 接口和类中,如附录 A,CMM 对象参考 中所述。
在 Monitoring Framework 中,程序设备是实现 CMM 定义的一组 Java 接口和类。为了实现 Java ES 中新的监视功能,产品组件已为其代码提供了程序设备,这些代码用于实例化 CMM 对象,并通过受监视对象的属性公开运行时值。每个组件实现的 CMM 对象确定可以监视的内容,因此,一些组件公开的属性可能少于其他组件。附录 B,每个组件公开的受监视对象 中给出了每个产品组件公开以便进行监视的对象和属性的列表。
在监视术语中,节点是由唯一的全限定域名或 IP 地址标识的单个逻辑主机。节点可以是整个系统,也可以是配置为虚拟系统的 Solaris zone。节点代理与该主机上所有具有程序设备的组件通信,并公开这些节点的所有受监视的对象。节点代理还管理所有用来收集性能统计信息、监视规则中定义的阈值以及为节点代理包含的受监视对象生成报警的逻辑。
下图显示了具有三个 Java ES 产品组件实例的单个主机上的节点代理的内容。它还显示了如何在节点代理中实例化程序设备,以便公开由产品组件提供的值。
该节点代理被实现为加载到 Common Agent Container(本身为 Java 虚拟机)中的一个模块。节点代理的实现基于 Java Management Extensions (JMX)(用于监视和远程管理的标准 Java 扩展)。任何启用了 JMX 且理解 CMM 的监视应用程序都可以访问节点代理中的受监视对象。使用 JMX 功能时,节点代理还可以通过简单网络监视协议 (Simple Network Monitoring Protocol, SNMP) 公开某些受监视的对象。
作为 Monitoring Console 安装的一部分,主代理被部署在一台独立的计算机上。主代理中配置了所有节点的名称或地址,这样它可以聚合所有节点代理的受监视对象。主代理也基于 JMX,主代理使用 JMX(也被加载到主代理的本地 Common Agent Container 中)与节点代理通信。
下图显示了连接到两个节点的主代理。Monitoring Console 连接到主代理以监视每个节点上的三个组件。如果希望使用 SNMP 进行监视,必须分别连接到每个节点,因为主代理不聚合 SNMP 属性。主代理被设计为仅与 Monitoring Console 配合使用,不能通过其他监视应用程序访问主代理。
如果选择评估或部署 Java ES 的监视功能,按以下顺序执行安装最简单:
按照《适用于 UNIX 的 Sun Java Enterprise System 5 安装指南》中的建议和说明在部署中安装并配置所有组件。
按照第 2 章,启用和配置 Monitoring Framework中的说明为所有受监视的组件启用并配置 Monitoring Framework。
按照第 3 章,安装和使用 Monitoring Console中的说明在单独的主机上安装 Monitoring Console,启动主代理,然后启动 Web Server。此时,所有受监视的组件都应在 Monitoring Console 中可见并受到监视。
由于此版本中的节点代理和主代理之间不兼容,因此必须将 Monitoring Console 安装在不包含任何其他 Java ES 组件的主机上。有关更多详细信息,请参见Monitoring Console 故障排除。
启用监视后,只要修改部署的组件,就需要重新启动主代理的容器和 Monitoring Console 的 Web 服务器,如Monitoring Framework 故障排除中所述。