The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Unified Operations Manager 9.0 allows the monitoring of the following counters in the following categories.
Counter Value | Counter Name |
Folder Location | Default Alert Threshold |
---|---|---|---|
Number of connected XMPP clients |
Cisco XCP CM | None |
|
Number of connected CAXL clients |
Cisco XCP WebCM | None |
Counter Value |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Database Space Used |
DB Local_DSN |
Yes ( > 90%) |
|
Replication Status |
Number of Replicates Created and State of Replication |
None |
|
Replication Queue Depth |
Enterprise Replication Perfmon Counters |
None |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Number of Instant Message Sessions |
JsmIMSessions | Cisco XCP JSM |
None |
Total Instant Message Packets |
JsmTotalMessagePackets | Cisco XCP JSM |
None |
Instant Message Packets in the last 60 seconds |
JsmMsgsInLastSlice | Cisco XCP JSM |
None |
MessagePackets Received per Session |
JsmSessionMessagesIn | Cisco XCP JSM Session Counters |
None |
Messages Sent per Session |
JsmSessionMessagesOut | Cisco XCP JSM Session Counters |
None |
Per User/Per Session counters existing for the duration of an IM session or user login. |
Cisco XCP JSM Session Counters | Cisco XCP JSM Session Counters |
None |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Number of Active JSM Sessions |
ActiveJsmSessions | Cisco Presence Engine |
None |
Number of Active Calendar Subscriptions |
ActiveCalendarSubscriptions | Cisco Presence Engine |
None |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
A Cisco DB CPU Usage |
cmoninit |
% CPU Time |
Yes (CPU > 90%) |
Cisco SIP Proxy CPU Usage |
sipd |
% CPU Time |
Yes (CPU > 90%) |
Cisco Tomcat CPU Usage |
tomcat |
% CPU Time |
Yes (CPU > 90%) |
Cisco Presence Engine CPU Usage |
pe |
% CPU Time |
Yes (CPU > 90%) |
Cisco XCP Router CPU Usage |
jabberd |
% CPU Time |
Yes (CPU > 90%) |
Cisco XCP Connection Manager CPU usage |
cm |
% CPU Time |
Yes (CPU > 90%) |
Cisco XCP SIP Federation Connection Manager CPU usage |
cm#2 |
% CPU Time |
Yes (CPU > 90%) |
Cisco XCP XMPP Federation Connection Manager CPU usage |
cm#3 |
% CPU Time |
Yes (CPU > 90%) |
Cisco XCP Web Connection Manager CPU usage |
cm#1 |
% CPU Time |
Yes (CPU > 90%) |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Database Memory Usage |
cmoninit |
VmSize |
None |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Number of Active SIP Subscriptions |
SIPS2SSubscriptionsOut SIPS2SSubscriptionsIn | Cisco XCP SIP S2S Cisco XCP SIP S2S |
Yes ( > 260,000) |
Number of Idle SIP Proxy Worker Processes |
NumIdleSipdWorkers | Cisco SIP Proxy |
Yes (< 5 for 60 minutes) |
Counter Attribute |
Counter Name |
Folder Location |
Default Alert Threshold |
---|---|---|---|
Total Text Conferencing Rooms |
TcTotalRooms | Cisco XCP TC |
None |
Total AdHoc Group Chat rooms |
TcAdHocRooms | Cisco XCP TC |
None |
Total Persistent Chat Rooms |
TcPersistentRooms | Cisco XCP TC |
None |
Room Message Packets Received |
TCRoomMsgPacketsRecv | Cisco XCP TC Room Counters |
None |
Room Number of Occupants |
TCRoomNumOccupants | Cisco XCP TC Room Counters |
None |
All IM and Presence Service counters are monitored in Unified RTMT through the Performance menu item, under the System tools:
Using Unified RTMT it is possible to create custom alerts based on the values of any Performance Counter. The following procedure is an example of creating a custom alert for Cisco SIP Proxy – NumIdleSipdWorkers.
Step 1 | Select Performance from the Performance menu item in Unified RTMT. | ||
Step 2 | Double-click the NumIdleSipdWorkers counter. | ||
Step 3 |
Select the counter graph in the main Unified RTMT pane.
![]() |
||
Step 4 |
Right-click, select Set Alert/Properties The Alert Properties: General window opens. ![]() |
||
Step 5 | Ensure the Enable Alert check box is checked. | ||
Step 6 | In the Description field, enter a brief description for the alert. | ||
Step 7 | In the Recommended Action field, enter a brief action for the alert. | ||
Step 8 | Choose a severity from the Severity drop-down menu. | ||
Step 9 |
Click Next. The Alert Properties: Threshold & Duration window opens. ![]() |
||
Step 10 | In the Threshold field, specify the alerting threshold for the counter. | ||
Step 11 | In the Value Calculated As field, specify how this threshold is calculated. | ||
Step 12 |
In the Duration field, specify duration of time that the counter value must be above or below the specified threshold before the alert is triggered.
|
||
Step 13 |
Click Next. The Alert Properties: Frequency & Schedule window opens. ![]() |
||
Step 14 |
In the Frequency field, specify the amount of times the custom alert is triggered. The default is: "Trigger alert on every poll." |
||
Step 15 |
In the Schedule field, specify when the alert is triggered. The default is: "Trigger Alert when it occurs (Non-Stop Monitoring)." |
||
Step 16 |
Click Next The Alert Properties: Email Notification window opens. ![]() |
||
Step 17 |
To receive email notifications, ensure the Enable Email check box is checked.
|
||
Step 18 | In the Trigger Alert Action field, use the drop-down menu to select the profile this alert will use. | ||
Step 19 | In the User-defined email text field, enter a brief message for the alert. | ||
Step 20 | Click Save. |
![]() Note |
You can find the CSV files by navigating down the directory structure to cm/log/ris/csv. This unusual directory structure is necessary as it is possible to use Unified RTMT to archive many different logs in one query. It is possible to use Trace and Log collection to archive every log the server generates. Each log will have its own specific path for the sake of organization. |
The WebCMConnectedSockets performance counter in the Cisco XCP WebCM folder contains the current number of CAXL web clients that are connected to the Cisco XCP Web Connection Manager on an individual IM and Presence Service server. This number rises and falls based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.
The ConnectedSockets performance counter in the Cisco XCP CM folder contains the current number of XMPP clients that are connected to the Cisco XCP Connection Manager on an individual IM and Presence Service server. This number rises and falls based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.
The Database Space Used performance counter contains the percentage of ccm dbspace used. Monitor this counter for an indication of when you will run out of database space.
The Replication Queue Depth performance counter contains the replication queue depth. A high value is an indication of replication issues.
The total number of IM packets handled by the IM and Presence Service node across all users in the past 60 seconds. This counter is reset to zero every 60 seconds. The same rules for counting IM packets apply as for TotalMessagePackets. Monitoring of this counter helps identify the busy IM hours in your organization.
The IM Packets received per session performance counter contains the total number of IMs that are sent by the user from the user's IM client or session. Note that the term SessionMessagesIn is defined from the perspective of IM and Presence Service: the IM packet that was sent by the client is an inbound IM packet to IM and Presence Service. On large deployments of IM and Presence Service there can be many instances of this counter, and viewing individual counters in Unified RTMT can be time consuming. To get a long list of the value of this counter for every user on IM and Presence Service, use the CLI command:
show perf query counter "Cisco XCP JSM Session Counters" JsmSessionMessagesOut
JsmTotalMessagePackets, JsmMsgsInLastSlice, JsmSessionMessagesIn and JsmSessionMessagesOut each represent instant message packets being sent to IM and Presence Service and are not exact figures of Instant Messages on the system. The amount of IM packets that are sent to IM and Presence Service per IM can vary depending on the client in use.
In this scenario JSM counters will increment by three.
The IM Packets sent per session performance counter counts the total number of IM packets that are sent to the user on the user's IM client or session. Note that the term SessionMessagesOut is defined from the perspective of IM and Presence Service: the IM packet is sent to the client and is an outbound IM packet from IM and Presence Service. On large deployments of IM and Presence Service there can be many instances of this counter, and viewing individual counters in Unified RTMT can be time consuming. To get a long list of the value of this counter for every user on IM and Presence Service use the CLI command:
show perf query counter "Cisco XCP JSM Session Counters" JsmSessionMessagesInThe Number of IM Sessions performance counter contains the total number of IM sessions on the IM and Presence Service node across all users. The Cisco Presence Engine, which provides presence composition services and rich, always-on network presence, creates an IM session on behalf of all users at Presence Engine (PE) startup time. This is necessary so that network presence events such as Cisco Unified Communications Manager Telephony Presence and Exchange Calendar notifications are reflected in a user’s presence even if that user is not logged in on any of their IM clients. Every licensed user that is assigned to an IM and Presence Service node will have one IM Session for PE rich presence composition in addition to one IM Session for any logged-in clients.
If:
The Per User/Per Session counters exist only for the duration of an IM session or user login. One set of these counters exists per Presence Engine network presence session, and one set of these counters exists per client login session. In the example given above for IM Sessions, 160 different sets of Cisco XCP JSM Session Counters would exist. When a user logs out, or when the Cisco Presence Engine is stopped, the associated Cisco XCP JSM Session Counters instance is deleted.
Administrators can use these counters to get a snapshot of all users that are currently logged in. These can be accessed by entering the following command on the CLI:
show perf list instances "Cisco XCP JSM Session Counters"Every user that is assigned to an IM and Presence Service node that is logged in to the system will have a set of JSM session counters for their current logged-in client session and also their Presence Engine network session. On an IM and Presence Service node with 5000 users logged in, this would result in a minimum of 10,000 sets of JSM Session counters. Updating these counters with new values as they change would place the system under stress. To combat this problem, JSM Session counter values are cached locally by the system and are only updated to Unified RTMT every 30 minutes.
The Total IM Packets performance counter gives the total number of IM packets that are handled by the IM and Presence Service node across all users.
If user Alice sends an IM packet to user Bob, and both users are assigned to the same IM and Presence Service node, then this IM packet will be counted twice. This is because The Cisco XCP Router and Jabber Session Manager treat the two users separately. For example, Alice’s privacy rules will be applied to the IM packet before it is delivered to Bob, and then Bob’s privacy rules will be applied to the IM packet before it is delivered to Bob’s client. Whenever IM and Presence Service handles an IM packet, it is counted once for the originator and once for the terminator.
If Alice and Bob are assigned to different IM and Presence Service nodes and Alice sends an IM packet to Bob, then the IM packet will be counted once on Alice’s node and once on Bob’s node.
The Number of Active Calendar Subscriptions performance counter contains the number of calendar subscriptions that are currently active on the box.
The Number of Active JSM Sessions performance counter contains the number of client emulation sessions between the Cisco Presence Engine and Cisco XCP Router. The value of this counter should always equal the number of licensed users on the box.
The Number of Active Inbound SIP Subscriptions performance counter contains the current number of active inbound SIP Subscriptions that are maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence Service server. Monitor this counter if the IM and Presence Service server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
The total combined count of SubscriptionsOut and SubscriptionsIn must not rise above 260,000 on any single IM and Presence Service server.
The Number of Active Outbound SIP Subscriptions performance counter contains the current number of active outgoing SIP Subscriptions being maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence Service server. Monitor this counter if IM and Presence Service server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
The sum of the values of the SubscriptionsOut and SubscriptionsIn performance counters must not rise above 260,000 on any single IM and Presence Service server.
The Number of Idle SIP Proxy Worker Processes performance counter contains the current number of idle/free SIP worker processes on the IM and Presence Service SIP Proxy. This counter gives a good indication of the load being applied to the Cisco SIP Proxy on each IM and Presence Service server. Monitor this counter if IM and Presence Service server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
The number of idle processes can drop to zero on occasion and is not a cause for concern. However, if the number of idle processes is consistently below five processes, then it is an indication that the IM and Presence Service Server is being heavily loaded and requires further investigation.
The Number of MESSAGE Requests Received performance counter is a cumulative count of the number of SIP MESSAGE requests arriving into the Cisco SIP Proxy since the service was last started. This is useful on the Routing IM and Presence Service server in terms of understanding the rate of IMs that are associated with SIP and federated SIP conversations. Depending on the role of the IM and Presence Service server, these SIP MESSAGE requests can come from multiple sources.
The Number of SIP INVITE Messages Received performance counter is a cumulative total of the number of SIP INVITE messages that were received by the Cisco XCP SIP Federation Connection Manager service since the service was last started. A SIP INVITE message arrives from each IM conversation that is initiated by a federated SIP user. So this count equates to the number of inbound IM conversations that were established since the Cisco XCP SIP Federation Connection Manager was last started.
The Number of SIP INVITE Messages Sent performance counter contains the total number of SIP INVITE messages that were sent out by the Cisco XCP SIP Federation Connection Manager since the service was last started. A SIP INVITE message is sent out for each IM conversation that is initiated by a Cisco Unified Personal Communicator user to a federated SIP user. So this count equates to the number of outbound IM conversations that were established since the Cisco XCP SIP Federation Connection Manager was last started.
The Number of SIP MESSAGES Received performance counter contains the total number of SIP MESSAGE packets that were received by the Cisco XCP SIP Federation Connection Manager service since the service was last started. Each Instant Message is sent in a SIP MESSAGE packet. So this count equates to the number of inbound IMs since the Cisco XCP SIP Federation Connection Manager was last started.
The Number of SIP MESSAGES Sent performance counter contains the total number of SIP MESSAGE packets that were sent out by the Cisco XCP SIP Federation Connection Manager since the service was last started. Each Instant Message is sent in a SIP MESSAGE packet. So this count equates to the number of inbound IMs since the Cisco XCP SIP Federation Connection Manager was last started.
The Number of SIP NOTIFY Messages Received performance counter contains the total number of SIP NOTIFY messages that were received by the Cisco XCP SIP Federation Connection Manager service since the service was last started.
The Number of SIP NOTIFY Messages Sent performance counter contains the total number of SIP NOTIFY messages that were sent out from the Cisco XCP SIP Federation Connection Manager service since the service was last started.
The Number of SUBSCRIBE Requests Received performance counter contains the total number of SIP SUBSCRIBE requests arriving at the Cisco SIP Proxy service since the service was last started. This counter captures all SUBSCRIBE requests, including refresh SUBSCRIBE requests (sent every 2 hours to keep a SIP Subscription alive) and unSUBSCRIBE requests (to terminate the subscription). Depending on the role of the IM and Presence Service server, these SIP SUBSCRIBE requests can come from multiple sources.
The Number of TCP Requests Received performance counter contains a time-sliced count of the number of generic SIP packets arriving per second at the Cisco SIP Proxy over TCP connections, regardless of type. This includes any SIP requests (SUBSCRIBE/INVITE/MESSAGE/NOTIFY/INFO, etc.) and any SIP responses (100: Trying, 200: OK, 404: Not Found, etc.). You can use it to check for spikes in activity on the IM and Presence Service SIP Proxy.
The IMs received per room performance counter contains the number of IMs that are received by the room. On large deployments of IM and Presence Service there can be many instances of this counter, and viewing individual counters in Unified RTMT can be time consuming. To get a long list of the value of this counter for every user on IM and Presence Service, use the CLI command:
show perf query counter "Cisco XCP TC Room Counters" TCRoomMsgPacketsRecvThe Number of occupants per room performance counter contains the current number of occupants of the chat room. For Persistent Chat rooms, monitoring the Number of occupants per room performance counter will give an indication of the room's usage trend. On large deployments of IM and Presence there can be many instances of this counter and viewing individual counters in Unified RTMT can be time consuming. To get a long list of the value of this counter for every user on IM and Presence use the CLI command:
show perf query counter "Cisco XCP TC Room Counters" TCRoomNumOccupants
It is possible to have a maximum of 16,500 Text Conferencing rooms on a IM and Presence Service node. Each of these rooms will have its own set of Per Chat Room counters. In a similar fashion to JSM Session counters, updating these with new values as they change would place the system under stress. To reduce the stress, Per Chat Room counter values are cached locally by the system and only updated to Unified RTMT every 30 minutes.
Per Chat Room performance counters only exist for the lifetime of a chat room. For ad hoc chat rooms, these counter instances will be destroyed when the ad hoc chat room is destroyed. For persistent chat rooms, the counter instances will also be destroyed when the persistent chat room is destroyed; however, persistent chat rooms are long lived, so they should rarely be destroyed.
Per Chat Room counters can be used to monitor the usage and participants in persistent (and ad hoc) chat rooms over their lifetime and can help identify persistent chat rooms that are no longer being used frequently.
Administrators can use Per Chat Room counters to get a snapshot of all rooms that are currently hosted on the node. These can be accessed by using the following CLI command:
show perf list instances "Cisco XCP TC Room Counters"The Total ad hoc Group Chat Rooms performance counter contains the total number of ad hoc chat rooms that are currently hosted on the node. Note that ad hoc chat rooms are automatically destroyed when all users leave the room, so this counter should rise and fall in value regularly.
The Total Persistent Chat Rooms performance counter contains the total number of persistent chat rooms hosted on the node. Persistent chat rooms must be explicitly destroyed by the room owner. This counter can be monitored to identify if the total number of persistent chat rooms is very large and also to help identify if some persistent chat rooms are not being used regularly anymore.
The Total Text Conferencing Rooms performance counter contains the total number of Text Conferencing rooms that are hosted on the node. This includes both ad hoc rooms and persistent chat rooms.