24.9. Establishing Monitoring with JBoss Operations Network (JON)
24.9.1. About AMI Monitoring
With your business application deployed to a correctly-configured AMI instance, the next step is to establish monitoring of the platform with JBoss Operations Network (JON).
The JON server is commonly located inside a corporate network, so it's necessary to establish a secure connection between the server and each of its agents. Establishing a VPN between the two points is the most common solution but this complicates the required networking configuration. This chapter provides network configuration guidelines for enabling communication between the JON agent and JON server. For more extensive information on configuration, management, and usage please refer to the official Red Hat documentation for JBoss Operations Network (JON).
![JON Server connectivity](https://access.redhat.com/webassets/avalon/d/Red_Hat_JBoss_Enterprise_Application_Platform-6.4-Administration_and_Configuration_Guide-en-US/images/ff5400b8eedb196c207d903cc51ea8ea/1477.png)
Figure 24.1. JON Server connectivity
24.9.2. About Connectivity Requirements
Registering a JON agent with its servers requires two-way communication between agent and servers. The JON Agent needs access to port
7080
on all JON servers, except in the case of SSL where port 7443
is used. Each JON server must be able to access each of the connected agents on a unique host and port pairing. The agent port is usually 16163
.
If there are multiple clustered JON servers, make sure each agent can communicate with all servers in the JON cluster via the IP and hostname pairs as configured through the JON server administration console. The JON server used by the agent to register may not be the server it tries to use after initialization.
24.9.3. About Network Address Translation (NAT)
A corporate VPN gateway acting in routed mode greatly simplifies network configuration. If your corporate VPN gateway is acting in NAT mode however, the JON server does not have direct visibility of agents. In this case, port forwarding needs to be configured for each agent.
NAT VPN configurations require a port on the gateway to be forwarded to the JON agent's address of port on the managed machine. The JON agent also needs to be configured to tell the server the forwarded port number and IP address. You can find further information in the
rhq.communications.connector.*
description for the agent-configuration.xml
configuration file.
24.9.4. About Amazon EC2 and DNS
JON servers and JON agents need to be able to resolve each others' hostnames. The DNS resolution is more complicated in the case of a VPN configuration. Connected servers have multiple possible options. One option is to use either the Amazon EC2 or the corporate network's DNS servers. Another option is to use a split DNS configuration where the corporate DNS servers are used for resolving names in particular domains, and the Amazon EC2 DNS servers are used for resolving all other names.
24.9.5. About Routing in EC2
All Amazon EC2 servers have a
source/destination checking
routing feature activated by default. This feature drops any packets being sent to the server which have a destination different from the machine's IP address. If the VPN solution selected for connecting agents to the JON server includes a router, this feature needs to be turned off for the server or servers acting as routers or VPN gateways. This configuration setting can be accessed via the Amazon AWS console. Disabled source/destination checking
is also required in a Virtual Private Cloud (VPC).
Some VPN configurations route general Internet traffic through the corporate VPN by default. It is recommended that you avoid this as it may be a slower and less efficient configuration for your particular needs.
While the use of a proper addressing schema is not a concern specific to JON, poor schemas can affect it. Amazon EC2 assigns IP addresses from the
10.0.0.0/8
network. Instances usually have a public IP address also, but only network traffic on the internal IP address within the same availability zone is free. To avoid using the 10.0.0.0/8
network in private addressing, there are a few things to consider.
- When creating a VPC, avoid allocating addresses already in use in the private network to avoid connectivity problems.
- If an instance needs access to availability zone local resources, make sure Amazon EC2 private addresses are used and traffic is not routed through the VPN.
- If an Amazon EC2 instance will access a small subset of corporate private network addresses (for example only JON servers), only these addresses should be routed through the VPN. This increases security and lowers the chance of Amazon EC2 or private network address space collisions.
24.9.6. About Terminating and Restarting with JON
One of the benefits of a cloud environment is the ease by which you can terminate and launch a machine instance. You can also launch an instance identical to the initial one. This may cause issues if the new instance tries to register with JON servers using the same agent name as the previously running agent. If this happens the JON server will not allow an agent to reconnect with a missing or non-matching identification token.
To avoid this, ensure that terminated agents are removed from the JON inventory before trying to connect an agent with the same name or specify the correct identification token when starting new agent.
Another issue that you might encounter is when an agent machine is assigned a new VPN IP address that no longer matches the address recorded in the JON configuration. An example might include a machine that is restarted or where a VPN connection is terminated. In this case, it is recommended that you bind the JON agent's life cycle to the VPN connection's life cycle. If the connection drops, you can stop the agent. When the connection is restored again, update
JON_AGENT_ADDR
in /etc/sysconfig/jon-agent-ec2
to reflect the new IP address and restart the agent.
Information on how to change the agent's IP address can be found in the Configuring JON Servers and Agents Guide available at https://access.redhat.com/documentation/en-US/JBoss_Operations_Network.
If there are a high number of instances launched and/or terminated it can become impractical to add and remove them manually from the JON inventory. JON's scripting capabilities can be used for automate these steps. Refer to the JON documentation for further information.
24.9.7. Configure an Instance to Register with JBoss Operations Network
Use the following procedure to register a JBoss EAP 6 instance with JBoss Operations Network.
- For JBoss EAP 6, add this to the User Data field.
JON_SERVER_ADDR=jon2.it.example.com ## if instance not already configured to resolve its hostname JON_AGENT_ADDR=`ip addr show dev eth0 primary to 0/0 | sed -n 's#.*inet \([0-9.]\+\)/.*#\1#p'` PORTS_ALLOWED=16163 # insert other JON options when necessary.
See Section 24.10.1, “Permanent Configuration Parameters”, parameters starting withJON_
for the format of JON options.