目錄

簡介

必要條件

需求

採用元件

背景資訊

RTMT警報

設定

系統警報

CallManager警報

LowAvailableVirtualMemory和LowSwapPartitionAvailableDiskSpace

LogPartitionHighWaterMarkExceeded和LogPartitionLowWaterMarkExceeded

Cpu追溯

驗證

疑難排解

簡介

本文討論思科即時監控工具(RTMT)警報，並演示如何對一些常見警報進行故障排除。

必要條件

需求

思科建議您瞭解Cisco Call Manager Web管理。

採用元件

本檔案中的資訊是根據Cisco CallManager伺服器11.0。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

背景資訊

作為使用者端應用程式執行的RTMT使用HTTPS和TCP來監控系統效能、裝置狀態、裝置探索、電腦電話整合(CTI)應用程式和語音訊息連線埠。RTMT可用於為它所監視的群集配置警報。

系統生成警報消息，以便在滿足預定義條件時（例如啟用的服務從上到下時）通知管理員。系統可以將警報作為電子郵件/電子郵件頁面傳送。

RTMT支援警報定義、設定和檢視，其中包含預配置和使用者定義的警報。儘管您可以對這兩種型別執行配置任務，但無法刪除預配置的警報。

RTMT警報

Unified RTMT在警報中心顯示預配置的警報和自定義警報，如下圖所示。

您還可以通過按一下系統抽屜中層次結構樹中的「報警中心」圖示來訪問「報警中心」。

設定

Unified RTMT在適用的頁籤下組織警報：System、CallManager、Cisco Unity Connection和Custom。

您可以在警報中心啟用或禁用預配置和自定義警報；但是，不能刪除預配置的警報。

RTMT中的警報分類如下：

- 系統警報

- CallManager警報

- 自定義警報

系統警報

此清單包含預配置的系統警報：

- 身份驗證失敗

- CiscoDRFailure

- CoreDumpFileFound

- Cpu追溯

- CriticalAuditEventGenerated

- CriticalServiceDown

- 硬體故障

- LogFileSearchStringFound

- LogPartitionHighWaterMarkExceeded

- LogPartitionLowWaterMarkExceeded

- LowActivePartitionAvailableDiskSpace

- 低可用虛擬記憶體

- LowInactivePartitionAvailableDiskSpace

- LowSwapPartitionAvailableDiskSpace

- ServerDown(適用於整合通訊管理員(CUCM)叢集)

- 超過SparePartitionHighWaterMark

- 超過SparePartitionLowWaterMark

- SyslogSeverityMatchFound

- SyslogStringMatchFound

- SystemVersion不匹配

- TotalProcessesAndThreadsExceededThreshold

CallManager警報

此清單包括預配置的CallManager警報。

- BeginThrottlingCallListBLFSsubscriptions

- CallAttemptBlockedByPolicy

- CallProcessingNodeCpu追溯

- CARIDSEngine關鍵

- CARIDSEngineFailure

- CARSchedulerJobFailed

- CDRAgentSendFileFailed

- CDRFileDeliveryFailed

- 超過CDRHighWaterMark

- CDRMaximumDiskSpaceExceeded

- 黃色代碼

- DBChangeNotifyFailure

- DBReplicationFailure

- DBReplicationTableOutofSync

- DDRBlockPrevention

- DDRDown

- EMCCFailedInLocalCluster

- EMCCFailedInRemoteCluster

- ExcessiveVoiceQualityReports

- IMEDdistributedCacheInactive

- IMEOverQuota

- IMEQualityAlert

- InsufficientFallbackIdentifiers

- IMEServiceStatus

- 憑據無效

- LowTFTPServerHeartbeatRate

- MaliousCallTrace

- MediaListExpirated

- MgcpDChannelOutOfService

- NumberOfRegisteredDevicesExceeded

- NumberOfRegisteredGatewaysReduced

- 註冊網關數量增加

- NumberOfRegisteredMediaDevices已減少

- NumberOfRegisteredMediaDevices已增加

- NumberOfRegisteredPhonesDropped

- 路由清單已用盡

- SDLLinkOutOfService

- TCPSetupToIMEilled

- TLSConnectionToIMEilled

- UserInputFailure

LowAvailableVirtualMemory和LowSwapPartitionAvailableDiskSpace

Linux伺服器傾向於在一段時間內「不清除」虛擬記憶體的使用量，並且會積累這些警報。

Linux作為一個作業系統運行起來有點不同。

記憶體分配給進程後，處理器將不會收回記憶體，除非其它進程請求記憶體大於可用記憶體。

這會導致虛擬記憶體過高。

在更高版本的Call Manager中請求增加警報閾值，該缺陷已記錄在案；https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq75767/?reffering_site=dumpcr

對於交換分割槽，此警報表示交換分割槽的可用空間不足，並且被系統大量使用。交換分割槽通常用於在需要時擴展物理RAM容量。在正常情況下，如果RAM足夠，則交換操作不應使用太多。

此外，臨時檔案的建立可能會引發這些RTMT警報，建議重新啟動伺服器以清除任何不必要的臨時檔案。

LogPartitionHighWaterMarkExceeded和LogPartitionLowWaterMarkExceeded

在CUCM伺服器的CLI上運行show status時，將顯示一個值，該值指定了CUCM磁碟空間中日誌分割槽的已用和空閒百分比。也稱為公共分割槽，這些值指定伺服器中的日誌/跟蹤和CDR檔案所佔用的空間，即使這些空間是無害的，也可能會由於缺少空間而造成安裝/升級過程的問題。這些警報對管理員發出警告，以清除群集/伺服器中隨時間累積的日誌。

LogPartitionLowWaterMarkExceeded：當填充空間達到為警報配置的閾值時生成此警報。此警報用作磁碟使用情況的預檢查指示器。

LogPartitionHighWaterMarkExceeded：當填充空間達到為警報配置的閾值時生成此警報。生成警報後，伺服器開始自動清除最舊的日誌，以便將空間縮小到允許出現HighWaterMark閾值的值。

最佳做法是在收到LogPartitionLowWaterMarkExceeded警報後立即手動清除日誌。

具體步驟如下：

步驟1.啟動RTMT。

步驟2.選擇Alert Central，然後執行以下任務：

選擇LogPartitionHighWaterMarkExceeded，注意其值並將其閾值更改為60%。

選擇LogPartitionLowWaterMarkExceeded，注意其值並將其閾值更改為50%。

輪詢每5分鐘進行一次，因此等待5-10分鐘，然後驗證所需的磁碟空間是否可用。如果要釋放公共分割槽中的更多磁碟空間，請再次將LogPartitionHighWaterMarkExceeded和LogPartitionLowWaterMarkExceeded執行緒值更改為較低的值（例如，30%和20%）。

給它15到20分鐘的時間來清除公共分割槽中的空間。您可以使用show status指令，從CLI監控磁碟使用量的減少。

那將摧毀共同的分割槽。

Cpu追溯

CpuPegging警報根據配置的閾值監視CPU使用情況。

當收到CPU追溯警報時，佔用最高CPU的進程可以通過轉到左邊的「系統抽屜」即「進程」佔用。

從相關伺服器的CLI中，這些輸出將提供一些見解。

- 實用程式診斷測試

- show process load cpu sorted

- 顯示狀態

- utils core active list

建議觀察CPU峰值是在特定時間還是隨機發生的。如果該事件隨機發生，則所需的詳細CUCM跟蹤以及RisDC perfmon日誌檢查CPU中觸發該事件的原因。如果在一天中的特定時間發生警報，則可能是由於災難恢復系統(DRS)備份、CDR載入等計畫活動。

此外，根據哪個進程佔用CPU最多的資訊，將採用特定日誌進行進一步調查。例如如果罪魁禍首是Tomcat，則需要Tomcat相關日誌。

驗證

使用本節內容，確認您的組態是否正常運作。

如果在遵循此處建議的變通方法後警報沒有被解除，或者警報似乎對服務有直接影響，請與Cisco TAC聯絡，提供有關呼叫管理器版本、群集中的節點數、警報的時間和持續時間以及CPU追溯時所需的進程縮窄的必要詳細資訊。

疑難排解

目前尚無適用於此組態的具體疑難排解資訊。