Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 9.0(1)
General performance monitoring for IM and Presence service
Downloads: This chapterpdf (PDF - 259.0KB) The complete bookPDF (PDF - 6.71MB) | Feedback

General performance monitoring for IM and Presence service

General performance monitoring for IM and Presence service

This appendix provides information on some of the more important counters that you can monitor for IM and Presence service. These counters provide information about Presence and Instant Messaging traffic rates.

Cisco XCP counters

Number of connected XMPP clients

Cisco XCP CM—CmConnectedSockets

View the current number of XMPP clients connected to the Cisco XCP Connection Manager on an individual IM and Presence server. This number should rise and fall based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.

Number of connected CAXL clients

Cisco XCP Web CM—WebConnectedSockets

View the current number of CAXL web clients connected to the Cisco XCP Web Connection Manager on an individual IM and Presence server. This number should rise and fall based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.

Number of active outbound SIP subscriptions

Cisco XCP SIP S2S—SIPS2SSubscriptionsOut

View the current number of active outgoing SIP Subscriptions being maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence server. Monitor this counter if IM and Presence server is configured for SIP Interdomain Federation or SIP Intradomain Federation.


Note


The total combined count of SIPS2SSubscriptionsOut and SIPS2SSubscriptionsIn must not rise above 260,000 on any single IM and Presence server.


Number of active inbound SIP subscriptions

Cisco XCP SIP S2S—SIPS2SSubscriptionsIn

View the current number of active inbound SIP Subscriptions being maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence server. Monitor this counter if IM and Presence server is configured for SIP Interdomain Federation or SIP Intradomain Federation.


Note


The total combined count of SIPS2SSubscriptionsOut and SIPS2SSubscriptionsIn must not rise above 260,000 on any single IM and Presence server.


Number of IM sessions

Cisco XCP JSM—JsmIMSessions

This counter gives the total number of IM sessions on the IM and Presence node across all users. The Presence Engine (PE), which provides presence composition services and rich, always-on, network presence, creates an IM session on behalf of all users at PE start-up 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 to any IM clients.

Every licensed user on a IM and Presence node has one IM Session for Presence Engine rich presence composition in addition to one IM Session for any logged in clients.

Example

There are 100 licensed users on the IM and Presence node as follows:
  • 50 users are not logged in
  • 40 users are logged in on one IM client
  • 10 users are logged in on two IM clients
This gives a total of 160 IM Sessions comprised of:
  • 100 x 1 for rich Presence Engine sessions
  • 40 x 1 for users logged in on a single client
  • 10 x 2 for users logged in on two clients

Total IM Packets

Cisco XCP JSM—JsmTotalMessagePackets

This counter gives the total number of IM packets handled by the IM and Presence node across all users.

Note that if user Alice sends an IM to user Bob, and both users are assigned to the same IM and Presence node, then this IM packet will be counted twice. This is because the 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 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 nodes and Alice sends an IM packet to Bob, then the IM will be counted once on Alice's node and once on Bob's node.

IMs in last 60 seconds

Cisco XCP JSM—JsmMsgsInLastSlice

This counter gives the total number of IM packets handled by the IM and Presence node across all users in the past 60 seconds. This counter is reset to 0 every 60 seconds. The same rules for counting IM packets apply as for JsmTotalMessagePackets. Monitoring of this counter will help identify the busy IM hours in your organization.

Per user and per session counters

Cisco XCP JSM Session Counters

These per session counters only exist for the duration of an IM session or user login. One set of these counters exists for each Presence Engine network presence session, and one set of these counters exists for each client login session. In the example given above for the IMSessions counters, there are 160 different sets of Cisco XCP JSM Session Counters. When a user logs out, or when the Presence Engine is stopped, the associated Cisco XCP JSM Session Counters instance is deleted.

You can use the Cisco XCP JSM Session counters to get a snapshot of all users currently logged in. These counters can be accessed from the CLI using the following command:

admin: show perf list instances "Cisco XCP JSM Session Counters"

Every user assigned to an IM and Presence node that is logged into 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 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, JSM Session counter values are cached locally by the system and only updated to RTMT every 30 minutes.

IM packets sent per session

Cisco XCP JSM Session Counters—JsmSessionMessagesIn

This counts the total number of IM packets sent by the user from his IM client or session. Note that the terminology JsmSessionMessagesIn is used as from the perspective of the IM and Presence server, the IM packet sent by the client is an inbound IM packet to IM and Presence.

IM packets received per session

Cisco XCP JSM Session Counters—JsmSessionMessagesOut

This counts the total number of IM packets sent to the user on his IM client or session. Note that the terminology SessionMessagesOut is used as from the perspective of the IM and Presence server, the IM packet is sent to the client and is an outbound IM packet from IM and Presence.


Note


JsmTotalMessagePackets, JsmMsgsInLastSlice, JsmSessionMessagesIn and JsmSessionMessagesOut each represent instant message packets being sent to IM and Presence and are not exact figures of Instant Messages on the system. The amount of IM packets sent to IM and Presence per IM can vary depending on the client in use.


Total text conferencing rooms

Cisco XCP TC—TcTotalRooms

This counter represents the total number of Text Conferencing rooms hosted on the node. This includes both AdHoc rooms and Persistent Chat rooms.

Total adhoc group chat rooms

Cisco XCP TC—TcAdHocRooms

This counter represents the total number of AdHoc chat rooms currently hosted on the node. Note that AdHoc chat rooms are automatically terminated when all users leave the room, so this counter should rise and fall in value regularly.

Total persistant chat rooms

Cisco XCP TC—TcPersistentRooms

This counter represents the total number of Persistent Chat rooms hosted on the node. Persistent Chat rooms must be explicitly terminated by the room owner. You can monitor this counter 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.

Per-chat room counters

Cisco XCP TC Room Counters

These pre-chat room counters exist only for the lifetime of a chat room. For AdHoc chat rooms, these counter instances are deleted when the AdHoc chat room is terminated. For Persistent Chat rooms, the counter instances are also deleted when the Persistent Chat room is terminated, however persistent chat rooms are long-lived, so they should rarely be terminated.

You can use these per-chat room counters to monitor the usage and participants in Persistent (and AdHoc) chat rooms over their lifetime and can help identify Persistent Chat rooms that are no longer being used frequently.

You can use the Cisco XCP TC Room counters to get a snapshot of all rooms that are currently hosted on the node. These counters can be accessed from the CLI using the following command:

admin: show perf list instances "Cisco XCP TC Room Counters"

IM packets received per room

Cisco XCP TC Room Counters—TCRoomMsgPacketsRecv

This counter represents the number of IM packets received per room.

Number of occupants per room

Cisco XCP TC Room Counters—TCRoomNumOccupants

This counter gives the current number of occupants of the chat room. Monitor this counter for Persistent Chat rooms to get an indication of the usage trend for the chat room.

It is possible to have a maximum of 16,500 Text Conferencing rooms on an IM and Presence node. Each of these rooms will have its own set of Per-Chat Room counters. Similar to JSM Session counters, updating these with new values as they change would place the system under stress. To combat this, Per-Chat Room counter values are cached locally by the system and only updated to RTMT every 30 minutes.

SIP proxy counters

Number of idle SIP proxy worker processes

SIP Proxy—NumIdleSipdWorkers

View the current number of idle, or free, SIP worker processes on the IM and Presence SIP Proxy. This counter gives a good indication of the load being applied to the SIP Proxy on each IM and Presence server. Monitor this counter if IM and Presence 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 are consistently below 5 processes, then it is an indication that the IM and Presence Server is being heavily loaded and requires further investigation