For more information about using Grafana, refer to the Cisco Policy Suite Operations Guide.

The following diagram represents the various statistic gathering points for incoming and outgoing messages.

Figure 2. Various Statistic Gathering Points for Incoming and Outgoing Messages

Measurements Legend

A – Inbound queue counts and times*
B – policy action counts and times
c – interface specific counts and times
D – policy message counts and times
E – outbound queue counts and times*
F – round trip counts and times*
* – statistics only apply to diameter messages

A brief description of each statistic gathering points is given below:

• Upon receipt of a message on the Policy Director (lb) node, the message is registered as received and forwarded to a middle tier processing node.

• This middle tier processing node tracks the inbound message counts and time spent within the inbound processing queue. If a message is discarded due to SLA violation, then counters are incremented at this point. This occurs at point A within the diagram.

• Upon arrival within the policy engine all messages are counted and timers are started to measure the duration of processing.

• Any internal or external actions are tracked at this point and the round trip time is measured from the policy engine invocation of the action and success or failure of the action. This occurs at point B within the diagram.

• For external actions (e.g. LDAP), interface specific statistics maybe captured. This occurs at point C in the diagram and is gathered from the Policy Director nodes.

• Upon completion of the message in the policy engine, the total elapsed time is measured and whether success or failure occurred in processing.

  Note	A message is considered a success even if the policy returns an error (such as 5002). These application errors are tracked at point D within the diagram.

• Outbound messages are tracked from the policy engine to the Policy Directors at point E within the diagram.

• Upon receipt of outbound messages, the Policy Directors tracks either end to end completion time for inbound requests OR starts a timer and counts outbound requests. This occurs at point F within the diagram.

This section describes various forms of statistics generated by CPS.

Changing the interval to a lower value allows for easier identification of peaks and valleys in response time. However, only the last statistic measured during a 5 minute period is reported in the CSV file and this fact should be taken into account when interpreting the bulk statistics.

CPS retains each bulk statistic CSV file on the pcrfclient01/02 VM for 2 days, after which the file is automatically removed. If you need to preserve these CSV files, you must back up or move them to an alternate system.

Configuration of the CPS application statistics is controlled in the /etc/collectd.d/logback.xml file.

Refer to http:/​/​logback.qos.ch/​manual/​appenders.html for more information about the configuration of the logback.xml file.

Collectd is configured in the following files:

• /etc/collectd.conf

• /etc/collectd.d/jmxplugin.conf

• /etc/collectd.d/exec.conf

After making any configuration changes to logback.xml, restart the collectd service:

service collectd restart

By default, the diameter statistics that are generated do not include the realm names. To include realms in the statistics collected, add the following line in the qns.conf file (comma separated auth-appl-id).

-Ddiameter.appid.realm.stats=Auth-Appl-Id-1,Auth-Appl-Id-2,… Auth-Appl-Id-n

where each Auth-Appl-Id refers to the specific protocol's Auth-Application-Id for which realms are needed in the statistics.

For example, to add Gx, Gy, Rx and Sy realms to the statistic names, use the following Auth-Appl-Ids:

-Ddiameter.appid.realm.stats=16777238,16777235,16777236,9

where

• Gx Auth-Application-ID = 16777238

• Rx Auth-Application-ID = 16777236

• Gy Auth-Application-ID = 4

• Sy Auth-Application-ID = 7

Note	Adding a realm will increase the number of statistics generated/collected. Add realms only when necessary.

As an example, statistic names with and without the realms are shown below for reference for the following statistic:

e2e_<domain>_[realm_][alias_]<message id>

Counter name with Realm (with qns.conf file modification):

C,lb02,node2.messages.e2e_PHONE_sy-ac.cisco.com_AC_Syp_AAR_2001.qns_stat.success,528

C,lb02.node2.messages.e2e_PHONE_sy-bm.cisco.com_BM_Syp_AAR_2001.qns_stat.success,1221

Counter name without Realm (without qns.conf file modification):

C,lb01,node2.messages.e2e_PHONE_AC_Syp_AAR_2001.qns_stat.success,1495

C,lb01,node2.messages.e2e_PHONE_BM_Syp_AAR_2001.qns_stat.success,4

Each statistic field has a fixed maximum length of 63 characters. Based on the current syntax, the length of the realm should not exceed 16 characters, otherwise it will lead to truncation of the counter name.