Create historical data collections
Tips
To ensure that ODP forwards attributes to Instana as soon as you start collecting them, update the ODP collection configuration member KAYOPEN before creating the corresponding historical data collections.
Warning
With higher granularity (a smaller interval means more data collected) there are 2 obvious considerations:
- CPU overhead on data collection and retrieval;
- DASD space to hold historical tables.
Should you grow in CPU usage or Persistent Data Store, consider raising the interval and/or skipping warehousing for certain tables on PDS and just go with open data.
Create the following historical data collections for the MQ agent. This can be done via the E3270UI or the Tivoli Enterprise Portal within the MQ workspace.
table_name field value | Attribute group | Collection interval (minutes) |
|---|---|---|
| qmcurstat | Current Queue Manager Status | 1 |
| qmq_lh | Queue Long-Term History | 5 |
| qmq_qu_st | Queue Status | 1 |
| qmq_hdl_st | Queue_Handle_Status | 1 |
| qmchan_st | Channel_Status | 1 |
| qmtpcst | Topic Status | 1 |
| qmch_data | Channel_Data | 1 |
| qmlsstatus | Listener_Status | 1 |
| qmqueue | Queue_Definitions | 5 |
| qmq_data | Queue_Data | 1 |
Warning
For all on-demand attribute groups with “Queue” in the name (except Current Queue Manager Status), if there is too much data, you should specify a longer interval. This is very customer-dependent – some have many (thousands of) queues per queue manager, some do not. Topics and channels could have the same issue, but perhaps not as likely as queues.
The basic rule is that a sampled table should not have an interval any more often than the sample interval (SAMPINT parameter) to the agent, which is 5 minutes by default; other tables can be more frequent if desired. This chapter should be consulted for considerations: IBM OMEGAMON for Messaging on z/OS