JmxCollector The JmxCollector collects performance data via JMX. Attributes are extracted from the available MBeans. Collector Facts Class Name org.opennms.netmgt.collectd.Jsr160Collector Package core Supported on Minion Yes Collector Parameters Use these parameters in the collectd-configuration.xml file. Table 1. Collector-specific parameters for the Jsr160Collector Parameter Description Required Default value collection The name of the JMX Collection to use. required (none) thresholding-enabled Whether collected performance data should be tested against thresholds optional true retry Number of retries optional 3 friendlyName Name of the path in which the metrics should be stored optional Value of the port, or 'jsr160' if no port is set. factory The password strategy to use. Supported values are: STANDARD (for authentication), PASSWORD_CLEAR (same as STANDARD) and SASL (if secure connection is required). optional STANDARD url The connection url, e.g., service:jmx:rmi:localhost:18980. The IP address can be substituted. Use ${ipaddr} in that case, e.g., service:jmx:rmi:${ipaddr}:18980 optional (none) username The username if authentication is required. optional (none) password The password if authentication is required. optional (none) port Deprecated. JMX port. optional 1099 protocol Deprecated. Protocol used in the JMX connection string. optional rmi urlPath Deprecated. Path used in JMX connection string. optional /jmxrmi rmiServerPort Deprecated. RMI port. optional 45444 remoteJMX Deprecated. Use an alternative JMX URL scheme. optional false The deprecated parameters port, protocol, urlPath, rmiServerPort and remoteJMX should be replaced with the url parameter. If url is not defined the collector falls back to legacy mode and the deprecated parameters are used instead to build the connection url. If a service requires different configuration, an entry in ${OPENNMS_HOME}/etc/jmx-config.xml can overwrite it. JMX Collection Configuration Understanding resource types helps when editing collector-specific configuration files. Define JMX Collections in etc/jmx-datacollection-config.xml and etc/jmx-datacollection-config.d/. This snippet provides a collection definition named opennms-poller: <jmx-collection name="opennms-poller"> <rrd step="300"> <rra>RRA:AVERAGE:0.5:1:2016</rra> <rra>RRA:AVERAGE:0.5:12:1488</rra> <rra>RRA:AVERAGE:0.5:288:366</rra> <rra>RRA:MAX:0.5:288:366</rra> <rra>RRA:MIN:0.5:288:366</rra> </rrd> <mbeans> <mbean name="OpenNMS Pollerd" objectname="OpenNMS:Name=Pollerd"> <attrib name="NumPolls" alias="ONMSPollCount" type="counter"/> </mbean> </mbeans> </jmx-collection> Once added to etc/jmx-datacollection-config.xml you can test it using the collect command available in the Karaf Shell: opennms:collect org.opennms.netmgt.collectd.Jsr160Collector 127.0.0.1 collection=opennms-poller port=18980 Generic Resource Type To support wildcard (*) in objectname, JMX collector supports generic resource types. JMX configuration requires two changes for this to work: Create a custom resource type in etc/resource-types.d/. For example, there is already a definition in jmx-resource.xml that defines a custom resource for Kafka lag <resource-types> <resourceType name="kafkaLag" label="Kafka Lag" resourceLabel="${index}"> <persistenceSelectorStrategy class="org.opennms.netmgt.collection.support.PersistAllSelectorStrategy"/> <storageStrategy class="org.opennms.netmgt.dao.support.SiblingColumnStorageStrategy"> <parameter key="sibling-column-name" value="name" /> </storageStrategy> </resourceType> </resource-types> Match the resourceType name as resource-type in MBean definition: <mbean name="org.opennms.core.ipc.sink.kafka.heartbeat" resource-type="kafkaLag" objectname="org.opennms.core.ipc.sink.kafka:name=OpenNMS.Sink.*.Lag"> <attrib name="Value" alias="Lag" type="gauge"/> </mbean> Resource definition JMX objectname is the full name of MBean in form of ( domain:key=value, key=value, ..). Wildcard (*) can exist anywhere in the objectname. Depending on wildcard definition, use SiblingColumnStorageStrategy to extract resource label. If wildcard exists in the value (usual case), use corresponding key as the sibling-column-name parameter. For example: org.apache.activemq:BrokerName=*,Type=Queue,Destination=com.mycompany.myqueue Here BrokerName can be defined as parameter for SiblingColumnStorageStrategy <parameter key="sibling-column-name" value="BrokerName" /> The extracted BrokerNames from the wildcard will be the resource folders in the form of nodeId/resourceTypeName/{resource-label} Wildcard may exist in domain as well. For example: org.apache.*:BrokerName=trap, Type=Queue. Then domain can be defined as the sibling-column-name parameter. <parameter key="sibling-column-name" value="domain" /> To use the objectname itself as a resource label, use IndexStorageStrategy as storageStrategy in resource-type definition. Third-Party JMX Services Some Java applications provide their own JMX implementation and require certain libraries to be present on the classpath, e.g., the Java application server Wildfly. To successfully collect data, you may need to do the following: Place the jmx client lib to the ${OPENNMS_HOME}/lib folder (e.g., jboss-cli-client.jar) Configure the collection accordingly (see above) Configure the JMX-Collector in collectd-configuration.xml (see below) Example <service name="JMX-WILDFLY" interval="300000" user-defined="false" status="on"> <parameter key="url" value="service:jmx:http-remoting-jmx://$\{ipaddr}:9990"/> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="factory" value="PASSWORD-CLEAR"/> <parameter key="username" value="admin"/> <parameter key="password" value="admin"/> <parameter key="rrd-base-name" value="java"/> <parameter key="collection" value="jsr160"/> <parameter key="thresholding-enabled" value="true"/> <parameter key="ds-name" value="jmx-wildfly"/> <parameter key="friendly-name" value="jmx-wildfly"/> </service> <collector service="JMX-WILDFLY" class-name="org.opennms.netmgt.collectd.Jsr160Collector"/> SnmpCollector HttpCollector