Creating historical data collections

Edit online

You will need to turn on near-term historical data collection by specifying collection intervals for each attribute table using either the E3270UI or Tivoli Enterprise Portal - TEP. Some of these are turned on automatically for existing OMEGAMON® deployments. Each line of JSON Lines from OMEGAMON Data Connect contains a table_name field that identifies the OMEGAMON attribute table to which the data belongs. The tables used by the monitoring agents are different, and hence the historical data collected will also vary.

OMEGAMON AI for CICS

Create the following historical data collections if you are using OMEGAMON AI for CICS.

Table 1. Historical data collections using OMEGAMON AI for CICS
`table_name` field	Attribute group	Collection interval (minutes)
`wss`	CICSplex Service Class Analysis	15

OMEGAMON AI for JVM

Create the following historical data collections if you are using OMEGAMON AI for JVM.

Table 2. Historical data collections using OMEGAMON AI for JVM
`table_name` field	Attribute group	Collection interval (minutes)
`gcsumm`	JVM Garbage Collection attributes	5
`cpu`	JVM CPU attributes	5
`zcsumm`	z/OS Connect Request Summary	5

Note: The following changes are also required for some of the attribute tables used by OMEGAMON AI for JVM. This can be done via the E3270UI or the Tivoli Enterprise Portal within the JVM workspace.

Any JVM that needs to be monitored must be configured with the OMEGAMON Java Agent and -agentpath. For more information, see Configuring a JVM with the OMEGAMON for JVM Agents.
z/OS connect servers need an OSGI interceptor and log streams to be defined in order to get API provider and requester data. For more information, see Configuring z/OS Connect EE for extended request monitoring.
Liberty servers must have the monitoring MBean defined in the server.xml file of the server. For more information, see Configuring JVMs in WebSphere Liberty.

OMEGAMON AI for Networks

Create the following historical data collections if you are using OMEGAMON AI for Networks.

Table 3. Historical data collections for OMEGAMON AI for Networks
`table_name` field	Attribute group	Collection interval (minutes)
`kn3gtc`	TCP Counter Statistics attributes	5
`kn3tcp`	TCP/IP Details attributes	5
`kn3tap`	TCP/IP Applications attributes	5

OMEGAMON AI for z/OS

Create the following historical data collections if you are using OMEGAMON AI for z/OS.

Table 4. Historical data collections for OMEGAMON AI for z/OS
`table_name` field	Attribute group	Collection interval (minutes)
`km5wlmclrx`	WLM Class Sysplex Metrics attributes	1
`ascpuutil`	Address Space CPU Utilization attributes	1

Note: With increased granularity (achieved through smaller intervals leading to more frequent data collection), two primary factors come into play:

Increase in CPU overhead during data collection and retrieval.
Expansion of DASD space required to accommodate historical tables.

If your CPU usage or persistent data storage demands escalate, consider adjusting the interval or even opting against warehousing specific tables on persistent data store (PDS). In such cases, favoring open data might be a more suitable approach.