Remote monitoring in the cloud

Posted by ThijsSchoemaker on 26-Apr-2010 06:02

Hi all,

According to the OpenEdge 102B documentation, a machine can be remotely configured and monitored.

I have tried this out on two instances in Amazon:

1 - Host, enabled as host with fmconfig.

  -  Host, fmconfig -query returns the right results

2 - Client, unglued OpenEdge Explorer from OpenEdge

   - Tried to setup the remote container by enabling fmconfig.

Furthermore, I have enabled my security group to communicatie on port 6835, which is the default remote container monitoring port.

However, when I try to enable my client with fmconfig -host -enable something goes wrong. The error message I get is:

Connecting to Fathom JMS Broker : Host:Port

Connecting to Fathom directory services .ERROR. Failed to establish connection to Fathom instance.

So, I am getting troubles when the client is connecting to the host, despite the fact that port 6835 is enabled. The server-hostname being used is ip-hostname, I assume this is oké. Maybe I have to enable extra portnumbers, unfortunately, logfiles do not provide me with useful information.

Can anyone help me out with this?

Best regards,

Thijs

All Replies

Posted by Roy Ellis on 26-Apr-2010 07:25

Hi Thijs,

The hardest part of the cloud is the networking.  I think your problem is using the ip-hostname.  What you should be using for "-host" is the private DNS-name (something like, ip-10-212-125-172.ec2.internal). 

May I also suggest you use the "-name" parameter and assign a name, by default you will get the "ip-hostname"+1 and that could get confusing if you need to shutdown and then restart your remote machine.  Upon restart you will get a new "ip-hostname"; if you assign a name and use is each time you use fmconfig this will keep the data correct in the fathom trend database and make the configuration more consistant. Using a "-name" to describe the machine makes the most sense, so if the machine is where your AppServer will be running, "appservermachine".

Summarizing my suggestion on the remote machine:

proenv> fmconfig -enable -host ip-10-212-125-172.ec2.internal -name appservermachine

Regards,

Roy

Posted by ThijsSchoemaker on 26-Apr-2010 09:24

Thanks for your quick reply.

Using the -name parameter is a good suggestion when enabling the client. I have tried the internal DNS (looks like domU-17-31-79-0C-ZZ-09.compute-1.internal), the external DNS (looks like ec2-188-70-95-1398.compute-1.amazonaws.com  and the name of the host(which looks like ip-73bd337). The hostname is the name which is showed after fmconfig -query on the host.

So, despite your good advice, still the error remains. Maybe I should host on a another name, if that's possible. But up till now, networking is a struggle!

Regards,

Thijs

Posted by Roy Ellis on 26-Apr-2010 10:03

Hi Thijs,

Okay, so let's step back and verify the whole process.

On the machine where you are running the OpenEdge Management Console:

1) stopped AdminServer

2) ran fmconfig -enable

3) restarted AdminServer

4) does a netstat show port 6835 is in LISTENING state?

5) on this machine you have 6835 open for TCP in the "Security Group"

On the remote machine

1) stopped the AdminServer

2) ran $DLC/bin/unglue to allow for remote administration

3) ran fmconfig -enable -host -name

4) successfully connects and configures

5) start the AdminServer

I think you are using the correct DNS values, so that should not be a problem.  So that leads me back to the 6835 port not open for connection or the AdminServer was not running on the OE Management machine or did not open the 6835 port for some reason.

Let me know what you find,

Roy

Posted by ThijsSchoemaker on 26-Apr-2010 10:52

Hi Roy

When I do a netstat on the Host the port 6835 is not returning in LISTENING state. But, in the Security Group, this portnumber is enabled for communication. Do you think I have to do something extra to make the port listening?

The other portnumbers which are enabled in the Security Group aren't depicted in the netstat result.

Regards Thijs

Posted by Roy Ellis on 26-Apr-2010 11:25

Hi Thijs,

Sorry for misleading you about the purpose of the "netstat".  The "netstat" will tell us whether or not a process is listening (or attached) to this port.  When you "fmconfig -enable" on the Management machine and then start your AdminServer, the AdminServer should then start a thread to listen on port 6835.  For reason this is not happening.

There are 2 possibilities:

1) when you start the AdminServer it is failing to start

2) when you start the AdminServer it is failing to open the port 6835

The best place to look is in the AdminServer's log file: $WRKDIR/admserv.log.  If properly configured for remote monitoring you should find another log file in $WRKDIR named Fathom1.FathomAdminserver1.log.  If you do not see this Fathom1.FathomAdminserver1.log then the "fmconfig -enable" did not work.  If you do see the Fathom1.FathomAdminserver1.log then make sure the log file shows it connecting to port 6835.

Let me know what you find,

Roy

Posted by ThijsSchoemaker on 27-Apr-2010 06:37

Hi,

Due to your good advice, the issue has been found.

I have enabled my Host on one instance with fmconfig. When an instance is stopped for a few hours, it will get a new hostname the next time it will boot. I had to disable and enable Fmconfig on my Host to give Fmconfig it the right Hostname.

However, the Fathom1.FathomAdminServer1 says it accepts tcp connections on port 6853 on the initial hostname, not the new hostname. So, there is a mismatch in hostname, which can be found in the logfile.

What is remaining is to give the Host a proper update, meaning that the right Hostname will be used. Apparently, a disable and enable isn't the right thing to do here. The new hostname will be used in the fmconfig -query result, but not in every source it needs the act as a host.

So, are the tools available to reset the hostname?

Regards,

Thijs

Posted by Roy Ellis on 27-Apr-2010 07:58

Hi Thijs,

I am sorry, I should have also mentioned this.  I was under the assumption this was the first time you had tried this so the instance had not been restarted and gotten a new hostname.  This is a limitation in the SonicMQ configuration used for remote monitoring.  The work around is found in the Product Availability Guide, along with other caveats of running in the Amazon Cloud.  The Product Availability Guide can be found at http://communities.progress.com/pcom/post!reply.jspa?message=88523 

The work around found in the Product Availability Guide is to find the "container.xml" in the $OEMgmt/MQ6.1 directory.  Change the current hostname to read localhost.

For example:

Should be

This should allow the SonicMQ broker to start no matter what the name is of the host when you start the instance.

Thank you for your patience,

Roy

Posted by ThijsSchoemaker on 27-Apr-2010 09:43

Hi Roy,

It works! The current hostname has to be added in:

C:\windows\system32\drivers\etc\hosts

The remote instance can now be monitored by the host.

Startup batches would be handy to control if the hostfile contains the current hostname.

Anyway, thanks a lot for your help!!

Thijs

This thread is closed