Inspecting Summary Messages

Each of these three main threads in a GISNodeService produce log metrics, once an hour, for each B2Bi server monitored by IBM® Sterling Control Center Monitor. When troubleshooting performance issues related to the monitoring of B2Bi servers, always start by looking at the high level summary messages, output to the B2Bi metrics log file.

Example

14 Jan 2019 17:00:00,006 629602 [qasimnt3(3)] INFO  B2BiMetrics - CGIS007I AFT Avg ms/req: 508, Avg # records/req: 2, # recs: 23, # reqs: 11 (1 in catchup), Avg ms to build events/req: 27, Avg events/req: 7, Avg log ms: 117, Avg # events/batch: 39, # events: 78

14 Jan 2019 17:00:00,006 629602 [qasimnt3(3)] INFO  B2BiMetrics - CGIS008I SFG Avg ms/req: 714, Avg # records/req: 82, # recs: 909, # reqs: 11 (1 in catchup), Avg ms to build events/req: 42, Avg events/req: 27, Avg log ms: 296, Avg # events/batch: 74, # events: 298

14 Jan 2019 17:00:00,006 629602 [qasimnt3(3)] INFO  B2BiMetrics - CGIS009I BP  Avg ms/req: 2362, Avg # records/req: 3473, # recs: 79886, # reqs: 23 (17 in catchup), Avg ms to build events/req: 3028, Avg events/req: 7021, Avg log ms: 55, Avg # events/batch: 98, # events: 161496

Note that summary messages described above indicate the identity of the monitored server they’re related to inside the square brackets [] that follow the time stamp for each log message.

For performance issues related to:

Protocol data collection, focus on the CGIS007I message data, and the output that follows it
Sterling Filegateway data collection, focus on the CGIS008I message data, and the output that follows it
Business process data collection, focus on the CGIS009I message data, and the output that follows it

Summary messages provide a wealth of information that can quickly help isolate where to look for problems, if not to identify what they are. The following table includes summary messages details:

Value	Description
Avg ms/req	Response time for requests to the B2Bi server for data. The response time is affected by the number of records received per request, but it should never exceed 20 seconds and it should be much lower – sub 10 seconds. Long request response times are typically due to unmaintained B2Bi database tables and/or indices.
Avg # records/req	Average number of records received per request by IBM Sterling Control Center Monitor. When B2Bi servers are busy, this number should match, or be close to, the limit specified for requests in IBM Sterling Control Center Monitor, which comes either from the CCEngineService configuration value for recordLimit, or siRecordLimit, when specified. Note these configuration values can set via the IBM Sterling Control Center Monitor Web Console. The default value for siRecordLimit is 4999. Better performance is obtained from busy B2Bi servers when it is set higher. 20000 is the recommended value for siRecordLimit to use but increasing the value beyond the default of 4999 may require changes to B2Bi. Always consult support prior to increasing siRecordLimit beyond its default value.
# recs	Total number of records received from B2Bi for the hour reported on.
#reqs	Total number of requests made by IBM Sterling Control Center Monitor for data from B2Bi during the hour reported on. Following the number of requests, you may see a catchup count also such as, 17 in catchup. When the catchup count matches, or is a large percentage, of the number of requests made, it’s an indication that IBM Sterling Control Center Monitor was unable to keep up with the level of activity on the B2Bi server during the hour reported. IBM Sterling Control Center Monitor is typically unable to keep up because of long response times, but it may be due to other factors including the time to insert events into the IBM Sterling Control Center Monitor database, or the time IBM Sterling Control Center Monitor takes to build events to be inserted.
Avg ms to build events/req	Average time IBM Sterling Control Center Monitor takes to construct events from data received from B2Bi. When this number is large it can cause IBM Sterling Control Center Monitor to fall behind in monitoring B2Bi.
Avg events/req	Average number of events generated from data received per request to B2Bi.
Avg log ms	Average time IBM Sterling Control Center Monitor took to add the events it created to the IBM Sterling Control Center Monitor database from the B2Bi data it received. When this number is large it can cause IBM Sterling Control Center Monitor to fall behind in monitoring B2Bi.
Avg # events/batch	Average number of events inserted per SQL INSERT initiated by IBM Sterling Control Center Monitor to add the events it created to the IBM Sterling Control Center Monitor database.
# events	Total number of events generated by IBM Sterling Control Center Monitor from the data received from B2Bi during the hour reported on. You can use this value to ascertain the times of heavy loads on the B2Bi server.