Introduction

Orchestra 6.1, and later, comes with a feature called Hardware Monitoring. It is used to keep track of the status of many different parts of the system. It monitors the current status of Queue Agents, Device Controllers and some devices, as well as keeping statistics and raw data about their status in the stat database. This way, it allows for organizations to act on events in real time, by adding custom logic to the event system.

For more information about the Hardware Monitoring application, please see the Administrator’s Guide, found on Qmatic World.

Prerequisite:

For distributed systems, port 5445 needs to be opened in the firewall.

Data Integration

For more information about Data Integration, please refer to “Hardware Monitoring - Data Integration” .

Configuration - Stat on a Separate Server

Configuration of Standalone Stat Server on Wildfly

If stat.war is deployed in a different application server than qSystem.ear, it is necessary to do a number of changes to the JMS configuration in order to get events forwarded from the Central server to the Stat server.

JMS queues and bridges are defined in the configuration file <ORCHESTRA>/app/wildfly-8.2.0.Final/standalone/configuration/standalone-full.xml, which is present in both installations.

1. On the server where Orchestra stat (stat.war) is deployed, create a user. In this example we use username="jms" and password="password", for the lookup of Queues, by running the script add-user, <ORCHESTRA>/app/wildfly-8.2.0.Final/bin/add-user.bat, on Windows, or <ORCHESTRA>/app/wildfly-8.2.0.Final/bin/add-user.sh, on Linux.

When running the script, supply the following input when prompted:

• b (application user)

• username you selected

• password you selected

• password again

• (blank) - simply press enter to indicate that the user should not belong to a particular group

• yes (validate the input settings)

• no (indicate that the user is not going to connect from another AS process, for e.g. EJB remoting)

If you enter a weak/short password, for example password, as in this example, you might get a warning such as “JBAS015264: Password is not strong enough, it is 'MODERATE'. It should be at least 'MEDIUM'. Are you sure you want to use the password entered yes/no?” or “JBAS015269: Password must have at least 4 characters! Are you sure you want to use the password entered yes/no?”. If this is the case, enter “no” and the script will prompt you for user/password again, or enter “yes” to use the password anyway.

Example execution:

What type of user do you wish to add?

a) Management User (mgmt-users.properties)

b) Application User (application-users.properties)

(a): b

Enter the details of the new user to add.

Using realm 'ApplicationRealm' as discovered from the existing property files.

Username : jms

Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.

- The password should not be one of the following restricted values {root, admin, administrator}

- The password should contain at least 4 characters, 1 alphabetic character(s)

- The password should be different from the username

Password :

Re-enter Password :

What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]:

About to add user 'jms' for realm 'ApplicationRealm'

Is this correct yes/no? yes

Added user 'jms' to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\standalone\configuration\application-users.properties'

Added user 'jms' to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\domain\configuration\application-users.properties'

Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\standalone\configuration\application-roles.properties'

Added user 'jms' with groups to file 'C:\qmatic\orchestra\61evtpsql\app\wildfly-8.2.0.Final\domain\configuration\application-roles.properties'

Is this new user going to be used for one AS process to connect to another AS process?

e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.

yes/no? no

2. On the server where Orchestra Central (qSystem.ear) is deployed, open the file <ORCHESTRA>/app/wildfly-8.2.0.Final/standalone/configuration/standalone-full.xml and locate the section:

<jms-bridge name="centralAgentEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="ConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

3. Then, replace the <target> sections with the following, where the java.naming.provider.url should contain the IP-address of the application server where stat.war is deployed:

There are two instances of the <target> section!

<connection-factory name="jms/RemoteConnectionFactory"/>

</context>

</target>

If Central has trouble connecting to the remote stat server, make sure that firewall rules allow connections to port 8080.

If Orchestra Central still experiences JMS connection errors, such as:

WARN [org.hornetq.jms.server] (pool-3-thread-3) HQ122010: Failed to connect JMS Bridge: javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://192.168.1.2:8080 (Operation failed with status WAITING after 5000 MILLISECONDS)] [Root exception is java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS]

Or the following error in the stat server’s Wildfly server.log:

INFO [org.jboss.as.naming] (default task-16) JBAS011806: Channel end notification received, closing channel Channel ID 1362678f (inbound) of Remoting connection 02b0b61f to /192.168.1.2:55380

This combination of messages means that the remote stat Wildfly installation has trouble making an internal JMS connection which it may be trying to perform against address 0.0.0.0 by default, which must be changed. It is changed by editing the remote stat’s Orchestra run.bat / run.sh script, which resides in the <remote stat install dir>/bin folder.

For Linux installations, change the last line to this (change IP as needed):

"$QP_HOME"/app/wildfly-8.2.0.Final/bin/standalone.sh -b=192.168.1.2 --server-config=standalone-full.xml

For Windows installations, change the following line:

CALL standalone.bat --server-config=standalone-full.xml

to this:

CALL standalone.bat -b=192.168.1.2 --server-config=standalone-full.xml

Configuration of Standalone Stat Server on JBoss

Follow these steps:

1. Open the file <ORCHESTRA>/app/jboss-eap-6.3-8.2.0.Final/standalone/configuration/standalone-full.xml on the Central server.

2. Locate the section socket-binding-group entry remote-jms and change the remote-destination host from "localhost" to the address of the stat server:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>

<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>

<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>

<socket-binding name="ajp" port="8009"/>

<socket-binding name="http" port="8080"/>

<socket-binding name="https" port="8443"/>

<socket-binding name="jacorb" interface="unsecure" port="3528"/>

<socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>

<socket-binding name="messaging" port="5445"/>

<socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>

<socket-binding name="messaging-throughput" port="5455"/>

<socket-binding name="remoting" port="4447"/>

<socket-binding name="txn-recovery-environment" port="4712"/>

<socket-binding name="txn-status-manager" port="4713"/>

<outbound-socket-binding name="mail-smtp">

<remote-destination host="localhost" port="25"/>

</outbound-socket-binding>

<outbound-socket-binding name="remote-jms">

<remote-destination host="statServerHost" port="5445"/>

</outbound-socket-binding>

</socket-binding-group>

3. Then, modify the jms-bridge to use the connection-factory "QPStatEventConnectionFactory" instead of "ConnectionFactory":

<jms-bridge name="qpStatEventBridge">

<connection-factory name="ConnectionFactory"/>

</source>

<connection-factory name="QPStatEventConnectionFactory"/>

</target>

<quality-of-service>AT_MOST_ONCE</quality-of-service>

<failure-retry-interval>10000</failure-retry-interval>

<max-retries>-1</max-retries>

<max-batch-size>10</max-batch-size>

<max-batch-time>100</max-batch-time>

</jms-bridge>

4. Restart the Central server