本節說明 Monitoring Console 與 Monitoring Framework 中的已知問題。Monitoring Framework 為一共用元件,會自動與其他元件一同安裝,以啟用監視。
為避免出現 Monitoring Framework 中的一些已知問題,需具備下列修補程式。這些修補程式包含於 Java ES 所需的其他修補程式軟體集或 Solaris 作業環境的更新版本中。然而,您應驗證在要監視 Java ES 產品元件的主機上,這些修補程式或其替代程式是否存在:
表 1 在 Solaris 作業環境中用於監視的修補程式
Solaris 版本 |
修補程式編號 |
---|---|
Solaris 9 Sparc 平台 (最高可為版本 s9u7_06) |
114344-17 |
Solaris 9 i386 平台 (最高可為版本 s9u7_06) |
114345-08 (已淘汰,由 117172-17 取代),118559-28 (或更新版本) |
Solaris 10 Sparc 平台 (最高可為版本 s10_58) |
114344-17 |
Solaris 10 i386 平台 (最高可為版本 s10_58) |
114345-08 (已淘汰,由 117172-17 取代),118855-15 (或更新版本) |
對於 HP-UX 作業系統,監視所需的修補程式包含於 HP-UX 需求和問題的說明中。
當新增要監視的新主機時,Monitoring Console 使用 SSL 來保護連線安全,但不會顯示所選主機呈現的憑證。因為 Monitoring Console 會將主機的根密碼傳輸至節點代理程式,因此攻擊者很容易偽造預訂主機的 IP 位址並接收密碼。發生這種狀況的風險很低,因為大部分的節點代理程式已在位於安全網路的主機上執行。
解決方案:如果您的節點代理程式主機沒有在安全網路內,您應先驗證其可信賴性,然後再將這些主機新增為 Monitoring Console 內的新主機。若要驗證主機的可信賴性,請登入主機並確定您可識別其配置和檔案系統。對於 UNIX 主機,您可使用 ssh 登入來檢視憑證資訊。
包含於產品中的物件在 Monitoring Console 中稱為「應用程式伺服器」。請勿將此詞彙與 Sun Java System Application Server 混淆。
解決方案:在 Monitoring Console 環境中,應用程式伺服器是指已安裝 Java ES 元件的執行中實例。
在 Monitoring Console 中顯示及切換頁面時,有時須花上 30 秒。
解決方案:於未安裝其他應用程式的功能強大的主機上執行 Monitoring Console。
左邊樹狀結構的標籤中未包含主機或網域名稱,僅有元件名稱。這樣很難辨別不同主機上的相似元件。同樣的,建立監視規則並選擇受監視的元件時,很難辨別不同主機上相同元件的實例。
解決方案:在受監視元件之詳細檢視中,查看主機識別碼。有些元件的實例名稱中包含其程序 ID,因此您必須知道各主機上實例之程序 ID。
Monitoring Console 無法以個別元件的基礎啟用或停用監視。
解決方案:您必須透過每個元件自己的機制啟用和停用元件監視。如需指示,請參閱「Sun Java Enterprise System 5 監視指南」中的第 2 章「啟用和配置 Monitoring Framework」中元件特定的小節。
當受監視元件當機或正常停止時,其受監視物件不會自節點代理程式中移除,且仍會在 Monitoring Console 左側的樹狀結構中顯示。同樣的,如果您停止整個節點代理程式,那麼主機節點不會從左側樹狀結構中移除。此問題會間歇性發生。
解決方案:停止或重新啟動伺服器實例時,可能需要重新啟動節點代理程式、主代理程式與 Monitoring Console。如果您停止主機及其節點代理程式,則需要重新啟動主代理程式和 Monitoring Console。「Sun Java Enterprise System 5 監視指南」中的「重新啟動節點代理程式」的「重新啟動節點代理程式」說明了兩者的程序。
若有主機從 Monitoring Console 中移除,與此受監視元件相關聯的監視規則與警報不會自動刪除。這會在您再次新增相同的主機時讓規則和警示狀態持續。
解決方案:如果您沒有計劃再次新增該主機,則使用「規則」 對話方塊尋找並刪除與該主機關聯的所有規則。當主機移除時存在的警示可被確認,但會保留在 Monitoring Console 中,這是因為無法再存取觸發警示的受監視屬性。為避免讓警示一直處於確認狀態,請在移除主機之前,先解決受監視元件中所有的警示狀況,並確認 Monitoring Console 中的警示。
下列清單追蹤 Monitoring Console 中的其他已知問題。
預設未排序各種表格
從「使用此已安裝產品的物件」連結的主機,不該是未知的物件
使用 AppServer 外掛程式,「此伺服器包含的物件」應不會包含子物件的子物件
主機表中,啟用與停用功能未正確運作
標題與描述欄位顯示 Statistics 與 Settings 物件,但不顯示基本物件
選擇物件並按一下「監視規則」->「新增」時,不應要求使用者再次選擇物件
列出的已知主機之 JVM 物件名稱不一致
「應用程式伺服器」建立的 CMM_Cluster 物件未在任何位置顯示
「新增規則」對話方塊中的可見物件清單不清楚
「入口網站」、「Web」和「應用程式伺服器」物件的「物件」與「運作狀態」未知
Application Server 中所部署的 Enterprise Java Bean 應具備多個描述性名稱
Application Server 監視物件中的屬性名稱無法使用
Application Server 的內部配置變更未反映在「Monitoring Console」中
在 Linux 系統上,若啟用 IPv6,就無法使用 Monitoring Framework 。結果,此系統上您所監視元件之設備就不會載入 cacao 容器,而您也就不會在「Monitoring Console」上看到。
解決方案:可能的解決方案有兩種:
將 Monitoring Framework 配置為不使用迴路介面:
在 Monitoring Framework 配置目錄中 (預設為 /etc/opt/sun/mfwk/config),複製範例特性檔案:
cp mfwk.properties.sample mfwk.properties |
在新複製的 mfwk.properties 檔案中設定下列參數:
mfwk.multicast.disableloopback=true |
使用「Sun Java Enterprise System 5 監視指南」中的「重新啟動節點代理程式」一節的程序,重新啟動節點代理程式、主代理程式和 Monitoring Console。
或以下列步驟停用 Red Hat 3.0 上的 IPv6:
尋找此行是否出現於 /etc/modprobe.conf 檔案中:
alias net-pf-10 ipv6 |
變更此行,或加入下列行:
alias net-pf-10 off |
重新啟動系統。現在 IPv6 應已停用。
在 Red Hat 4.0 上,以相同步驟使用 /etc/modules.conf 檔案。
在停用受監視元件的程序中,應從節點代理程式中取消部署,但有時會停頓住。特別是永遠不會傳回 cacaoadm undeploy 指令,而監視會被封鎖在整個節點代理程式中。
解決方案:結束程序,然後使用「Sun Java Enterprise System 5 監視指南」中的「重新啟動節點代理程式」一節的程序,重新啟動節點代理程式、主代理程式和 Monitoring Console。
依靠 C 程式庫與 Monitoring Framework 連繫的元件在 Linux 作業環境執行時,在 Monitoring Console 中可能顯示較緩慢
解決方案:無。
依靠 C 程式庫的元件在重新部署或終止同一節點代理程式中的其他元件後,在 Monitoring Console 中可能顯示較緩慢的監視效能
解決方案:重新啟動包含節點代理程式之節點的 Common Agent Container,然後使用「Sun Java Enterprise System 5 監視指南」中的「重新啟動節點代理程式」一節的程序重新啟動主代理程式和 Monitoring Console。
依靠 C 程式庫的元件與同一主機上節點代理程式之間的通訊不安全。依照預設,通訊使用迴路介面,因此會降低安全性風險。
解決方案:無。
透過 SNMP 存取時,依靠 Java 程式庫與 Monitoring Framework 聯繫的元件會遭遇效能問題。
解決方案:無。
因 Solaris 9 中的一個錯誤,發往 IPv4 位址的封包未傳遞給 IPv6 通訊端上的偵聽程式。這樣便會中斷節點代理程式與該主機上受監視元件之間的探索機制。
解決方案:強制節點代理程式的 JVM 以下列指令偵聽 IPv4 通訊端:
cacaoadm stop oldvalue=`cacaoadm get-param java-flags --value` cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true" |
然後使用「Sun Java Enterprise System 5 監視指南」中的「重新啟動節點代理程式」一節的程序,重新啟動節點代理程式、主代理程式和 Monitoring Console。
若節點代理程式主機與主代理程式主機的時間相差太多,則在 Monitoring Console 中增加節點的動作會失敗。主代理程式 Monitoring Framework 的錯誤記錄會「在建立 JRMP 連線過程中」報告發生嚴重錯誤。
解決方案:設定兩台主機的時間讓它們同步化。
誤將私用 C API 的說明文件附加於執行階段套裝軟體中。所描述的介面屬於私用,且可能隨時變更,因此不建議使用。
解決方案:無。
當在 HP-UX 作業系統的節點代理程式中平行建立許多監視規則時,Java 虛擬機器 (JVM) 中的執行緒數字會超過核心參數限制,並導致 OutOfMemory 例外。
解決方案:下載並執行 HPjconfig 工具,如「Sun Java Enterprise System 5 監視指南」中「在 HP-UX 上針對 Monitoring Framework 最佳化核心參數 」一節的程序所述。