整個監視程序包含收集執行階段資料、顯示資料及運算服務品質標準,以便系統管理員可評估效能,並收到警示通知。在執行階段作業期間,管理員只需要與 Monitoring Console 互動,即可檢視效能統計資料、建立規則以進行自動監視和確認警示。但是對於配置、疑難排解和進階監視而言,這可協助瞭解 Monitoring Framework 的架構,以及與 Monitoring Console 連線的方式。
Java ES 中的監視基於下列概念:
Common Monitoring Model (CMM) 可確保所有 Java ES 元件都顯示可比對屬性的統一物件和值。
CMM 介面定義的 Java 物件會為產品元件提供標準化的設備。
節點代理程式會顯示系統上所有已安裝元件的受監視物件,並管理這些物件的統計資料、規則和警示。
獨立主機上的主代理程式會收集所有節點代理程式的所有受監視物件,並且將資料提供給 Monitoring Console。
以下各節將詳細說明上述各項關於監視架構的概念。
標準化監視機制的基礎,是定義哪些物件需要受到監視,並且在所有受監視元件上採用這些物件。為達成此目標,監視架構將 Common Monitoring Model (CMM) 定義為分散式管理專案小組 (DMTF) 所維護之共用資訊模型 (CIM) 的延伸。CMM 既是可指定受監視物件 (例如電腦、應用程式等等) 的資訊模型,也是可指定統一值 (例如作業狀態值) 的資料模型。就資訊模型而言,CMM 也會定義物件的屬性,例如服務所處理的請求數量,以及物件之間的關係,例如服務由某部電腦代管。
由於有 CMM,所以即使基礎實作不同,所有產品元件的概念 (例如應用程式、服務、存取點等等) 仍然會一樣。舉例來說,Web Server 可能會顯示處理 HTTP 請求的服務,而 Directory Server 可能會顯示處理 LDAP 請求的服務。但標準物件會擷取這兩項功能的共通點,例如測量已處理請求數量的功能、在指定時間內回應請求的平均時間等。
此外,某些資料值已經過標準化,所以其意義在整個系統中是一致的。例如,不管受監視的是哪個產品元件,作業狀態 DEGRADED 表示服務仍然可用,但效能都已大幅度降低。
CMM 規格納入於設備使用的 Java 介面和類別中,如附錄 ACMM 物件引用 中所述。
在 Monitoring Framework 中,設備是實作 CMM 定義的一組 Java 介面和類別。對於 Java ES 的新監視功能,產品元件已提供程式碼實例化 CMM 物件,並透過受監視物件的屬性顯示即時值。各個元件實作的 CMM 物件會決定可監視的項目,因此,某些元件會比其他元件顯示較少的屬性。附錄 B各項元件顯示的受監視物件 中提供了一份清單,列出各個產品元件所顯示的受監視物件和屬性。
在監視術語中,節點表示由唯一完全合格之網域名稱或 IP 位址所識別的單一邏輯主機。節點可以是整個系統,也可以是配置為虛擬系統的 Solaris Zone。節點代理程式會與該主機上配備的所有元件相互通訊,並顯示其中所有的受監視物件。節點代理程式也會管理所有邏輯,以收集效能統計資料、監視規則中定義的臨界值,並針對其中所包含的受監視物件產生警示。
下圖表示單一主機上的節點代理程式內容,其中包含三個 Java ES 產品元件的實例。還顯示如何在節點代理程式中實例化設備,以顯示產品元件所提供的值。
節點代理程式已實作為載入 Common Agent Container (其本身為 Java 虛擬機器) 中的模組。節點代理程式根據 Java Management Extensions (JMX) 進行實作,JMX 為監視和遠端管理的標準 Java 延伸。任何啟用 JMX 的監視應用程式只要支援 CMM,都可以存取節點代理程式中的受監視物件。節點代理程式也可以使用 JMX 功能,透過簡易網路監視協定 (SNMP) 顯示某些受監視物件。
主代理程式會在 Monitoring Console 安裝時部署在獨立機器上。主代理程式是以所有節點的名稱和位址加以配置,因此可集合所有節點代理程式的受監視物件。主代理程式也以 JMX 為基礎,與節點代理程式相互通訊,並且會載入於本機 Common Agent Container。
下圖表示連線至兩個節點的主代理程式。Monitoring Console 會連線至主代理程式,監視各節點上的三個元件。如果需要使用 SNMP 進行監視,由於主代理程式不會集合 SNMP 屬性,所以您必須分別連線至各個節點。主代理程式僅能搭配 Monitoring Console,其他監視應用程式無法存取。