Configuring the collector

The following section describes how to configure the collector in a performance monitoring tool.

The most important configuration options are the domains and the peers configuration options. All other configuration options are best left at their defaults and are explained within the default configuration file that is shipped with ZIMON.

The configuration file of the collector, ZIMonCollector.cfg, is located in the /opt/IBM/zimon/ folder. The ZIMonCollector.cfg file is maintained automatically by the mmperfmon config command and must not be changed manually. Manual changes might be overwritten by the next call of the mmperfmon config command. The description below is for educational purposes and the values that are shown might differ from the default values actually used on the system.
CAUTION:
If you modify any domain parameters after the data collection has started, that might cause loss of the historical data that is already collected.

Metric domain configuration

The domains configuration indicates the number of metrics to be collected and how long they must be retained and in what granularity. Multiple domains might be specified. If data no longer fits into the current domain, data is spilled over into the next domain and resampled.

A simple configuration is shown. 
domains = {
# this is the raw domain, aggregation factor for the raw domain is always 0
aggregation = 0
duration = "12h"
filesize = "1g" # maximum file size
files = 5 # number of files.
},

{
# this is the second domain that aggregates to 60 seconds
aggregation = 60
duration = "4w"
filesize = "500m" # maximum file size
files = 4 # number of files.
},

{
# this is the third domain that aggregates to 30*60 seconds == 30 minutes
aggregation = 30
duration = "1y"
filesize = "500m" # maximum file size
files = 4 # number of files.
}
The configuration file lists several data domains. At least one domain must be present, and the first domain represents the raw data collection as the data is collected by sensors. The aggregation parameter for this first domain must be set to 0.
Each domain specifies the following parameters:
  • The duration parameter indicates the time period until the collected metrics are pushed into the next (coarser-grained) domain. If this option is left out, no limit on the duration is imposed. The units are seconds, hours, days, weeks, months, and years { s, h, d, w, m, y }.
  • The filesize and files parameter indicates how much space is allocated on disk for a specific domain. When metrics are stored in memory, a persistence mechanism is in place that also stores the metrics on disk in files of size filesize. Once the number of files is reached and a new file is to be allocated, the oldest file is removed from the disk. The persistent storage must be at least as large as the amount of main memory to be allocated for a domain. The size of the persistent storage is significant because when the collector is restarted, the in-memory database is re-created from these files.

    If both the ram and the duration parameters are specified, both constraints are active at the same time. As soon as one of the constraints is impacted, the collected metrics are pushed into the next (coarser-grained) domain.

The aggregation value, which is used for the second and following domains, indicates the resampling to be performed. When data is spilled into this domain, it is resampled to be no better than indicated by the aggregation factor. The value for the second domain is in seconds, the value for domain n (n >2) is the value of domain n-1 multiplied by the aggregation value of domain n.

The collector collects the metrics from the sensors. Depending on the number of nodes and metrics that are collected, the collector requires a different amount of main memory to store the collected metrics in the memory. For example, in a five-node cluster that reports only the load values (load1, load5, load15) , the collector maintains 15 metrics (three metrics times five nodes).

The collectors can be stopped (deactivated) by issuing the systemctl stop pmcollector command.

The collectors can be started (activated) by issuing the systemctl start pmcollector command.

IPv6 or dual stack configuration

A dual stack configuration has both IPv4 and IPv6 environments. In an IPv6 or dual stack environments, the collector service interface needs to be configured so that it also accepts IPv6 request. This requires you to manually change the /opt/IBM/zimon/ZIMonCollector.cfg file and restart the pmcollector service on all the collectors in the cluster.

The ZIMON collector is deployed on the management GUI in a federated configuration. That is, the performance monitor tool installation in a management GUI can involve multiple collectors. However, in a dual stack configuration, a single name resolution must be defined for the multiple pmcollectors within the cluster. All names and IP addresses of the peers must be updated in the /opt/IBM/zimon/ZIMonCollector.cfg file for all the collector nodes. Individual pmcollectors cannot run on different IP protocol versions. Moreover, to establish a successful connection between the GUI and the pmcollector the name resolution must also be updated in the gpfsgui.properties. For example, you must assign zimonAddress == localhost6 or ::1 for IPV6 and zimonAddress == localhost for IPV4 in gpfsgui.properties. A sudo or root user can also change the order of the hosts in etc/hosts to establish the connection between GUI and the ZIMON collector.