Enterprise Dashboard not Connecting

[leontova]

Hi all. We've just installed FR on our server and it seems to be
running great. We installed FRED(Fusion Reactor Enterprise Dashboard)
entered the same address and port as what our server uses and the
proper Role and password and it generates an error about 20 seconds
after I click the login button. The error is very generic:

An Error Occurred:
Please check your login details, that your server has been started,
and try again.

Any ideas as to what I need to do next?

Thanks for your time.

[Darren Pywell]

Hello leontova,

Welcome to the group!

The problem may be the URL. Can you check that the URL looks like this:

http://demo.fusion-reactor.com:8088/fusionreactor

You may need to put the /fusionreactor on the end which sometimes catches people out.

Also you need to make sure that the URL can be reached in a web-browser also. Sometimes you need to be logged into your VPN if you are going to an internal server that is not accessible to the outside world.

Hope that helps,

Darren

[DeMarco, Alex]

Good Morning,

Is it possible to customize the crash protection email so that it
include the source ip address?

Running Requests:

176697 1330613585026 (2012-03-01 09:53:05.026) 189177ms https://someurl
177081 1330613713826 (2012-03-01 09:55:13.826) 60377ms https://someurl

It would be nice to know in the email if the request is coming from the
same ip address..

- Alex

[charlie arehart]

It would be nice to have the IP there. I've requested it before. While there
is no way for us (users) to customize them, while we await them considering
it, do note that the IP address for all those is in fact in the email. But
it's at the bottom, after the huge thread dump, where FR lists the details
(about 20 lines) for each running request.

Still, yes, it would be nice to see the IP at the top in that often what we
may see is many requests from the same IP (or close to each other: be aware
that spiders are getting sneaky now, and the same spider requesting pages
from a given domain in just a few minutes may come from many different IPs,
but often they my all share some parts of the prefix of their IP address.)

Anyway, I'm with you on wishing they'd consider adding it. That said, I
appreciate that there's only so much space on each line at the top, so that
adding more can clutter that.

While we're on the topic, I would also LOVE it if the details at the bottom
would add a line for the user agent. That IS tracked already in FR, in the
request details page, but it is not shown in these CP alert details, nor is
it ever logged by FR (though yes, it may be logged by our web server. Still,
having it here in the CPs especially could be very helpful.)

/charlie

> --
> You received this message because you are subscribed to the Google Groups
> "FusionReactor" group.
> To post to this group, send email to fusion...@googlegroups.com.
> To unsubscribe from this group, send email to
> fusionreacto...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fusionreactor?hl=en.

[DeMarco, Alex]

Real Estate is an issue.. Perhaps creating CP Message templates: Max
Detail, Detail, Lite or something like that. Then being able to apply
those templates by CP would be nice.

- Alex

[Gualtiero Sappa]

Hi Alex,
I agree with you that it could be very helpful.

I addition (not closely related to your request, but it could be
considered with it buy Intergral guys) I think it would be nice to
have the CP reason also in mail subject, in order to quickly identify
if the notification is related i.e. request time or memory.

This feature could be very helpful when you know that you application
could exceed your CP memory limit when in some particular period in
the day.
With actual CP subject, you have to open all CP mail to be sure that
are all related to memory CP. Reporting CP reason in mail subject, it
could be easier to identify request time CP occurred in this period.

Gualtiero

> >  176697 1330613585026 (2012-03-01 09:53:05.026) 189177mshttps://someurl
> >  177081 1330613713826 (2012-03-01 09:55:13.826) 60377mshttps://someurl

[Darren Pywell]

Great feedback. Changing and adding something to the existing emails is going to be easier than adding email templates (but I see the goodness of that too!). I'll see what we can do for the next update.

Thanks,

Darren

On Wednesday, February 29, 2012 10:46:27 PM UTC+1, leontova wrote:

[Darren Pywell]

I'm using the new Google Groups interface here and interestingly it
looks like it switched the Discussion Subject back to the original
subject of the thread when I posted. It's always one to watch out for
on the groups because it's so easy to change the discussion topic on a
thread instead of starting a new thread. In the case it looks like GG
decided to set the discussion back on my post to what original subject
was; I'm not using email, I'm using the GG web interface directly...

Cheers,
Darren

[leontova]

Hi Darren. Thanks for helping out (and yes it is a bit odd the threads
are jumbled)
So the the URL is: as you have formatted it. The same URL works if I
pull open FR in a browser in the local server. The URL cannot be
reached from a browser outside - it just times out. Not using a VPN
though.

Any other ideas?

Thanks for your time.
-Andy

[Darren Pywell]

Hi Andy,

Could you just check for me that there are no spaces in the URL. It's
a long shot but worth a check. Also might be worth checking for
windows firewall and antivirus software. You could try turning them
off to see if they are blocking the port.

Thanks,
Darren

[charlie arehart]

Andy, are you testing that in a browser running on the machine where the FR
ED is located, as opposed to where you are browsing the ED itself?

Let me be more clear: you may be viewing the ED via your browser running on
your desktop at location a (let's say, your home), but the server with the
ED may be in location b (let's say, your work environment). And *that* may
be set to watch an FR server instance running in yet another location, c
(let's say, where your CF server is hosted).

In particular, you mention using a port in the URL, and as Darren showed for
the demo server, the URL may be like
http://demo.fusion-reactor.com:8088/fusionreactor . In that case, note that
the firewall on the server (location c, using my scenario above) has to be
set to allow requests to that port (8088, if it's that) from location b (or
wherever you want the FR ED to talk to the server), or indeed to allow any
user to access the FR interface via that port.

As such, your browser test (to confirm the URL used in the ED) must be done
at location b (where the FR ED is), not location a (where you may be
browsing the ED itself).

Hope that makes sense.

Finally, consider also that many are surprised to learn that they may be
able to browse an FR instance by way of their external web server (on the
server) rather than the built-in web server that comes with FR (the port
8088 Darren showed, and which you may be using also). Consider that the demo
server Darren showed can be reached just as well without the use of port
8088, as in http://demo.fusion-reactor.com/fusionreactor.

If removing that port may leave that a working URL for you (particularly in
a test from the location of the FR ED), then use that instead of the one
with the port.

Let us know how you go.

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of leontova
> Sent: Friday, March 02, 2012 11:49 AM
> To: FusionReactor

> Subject: [fusionreactor] Re: Enterprise Dashboard not Connecting
>
<snip>

[leontova]

Hi Darren. There are no spaces in the URL and the firewall and
antivirus is turned off for now.

Thanks for your help in this.
-Andy

[leontova]

Hi Charlie. Browsing FR on the host server works fine with the URL
that includes the port number. I cannot get to that server using FRED
from my desktop (which is on the same network as my server). When I
remove the port number from the FRED URL, I get the
cfusion.JRUN.myservername in the dashboard. Clicking on the blue cube
gets me an error that 'cfusion.JRUN.myservername' monitored server
could not be contacted.

Thanks for your help in this.

-Andy

On Mar 3, 6:24 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:

> Andy, are you testing that in a browser running on the machine where the FR
> ED is located, as opposed to where you are browsing the ED itself?
>
> Let me be more clear: you may be viewing the ED via your browser running on
> your desktop at location a (let's say, your home), but the server with the
> ED may be in location b (let's say, your work environment). And *that* may
> be set to watch an FR server instance running in yet another location, c
> (let's say, where your CF server is hosted).
>
> In particular, you mention using a port in the URL, and as Darren showed for

> the demo server, the URL may be likehttp://demo.fusion-reactor.com:8088/fusionreactor. In that case, note that

> the firewall on the server (location c, using my scenario above) has to be
> set to allow requests to that port (8088, if it's that) from location b (or
> wherever you want the FR ED to talk to the server), or indeed to allow any
> user to access the FR interface via that port.
>
> As such, your browser test (to confirm the URL used in the ED) must be done
> at location b (where the FR ED is), not location a (where you may be
> browsing the ED itself).
>
> Hope that makes sense.
>
> Finally, consider also that many are surprised to learn that they may be
> able to browse an FR instance by way of their external web server (on the
> server) rather than the built-in web server that comes with FR (the port
> 8088 Darren showed, and which you may be using also). Consider that the demo
> server Darren showed can be reached just as well without the use of port

> 8088, as inhttp://demo.fusion-reactor.com/fusionreactor.

[charlie arehart]

But let's remove the ED from the equation entirely. What happens when you
browse the URLs in your browser (with and without the port), first from your
desktop, then from your "host server". By that, do you mean where the FRED
is located? Or the server that it's watching? They can be different, so I
want to be clear. Also, are you using the full URL, with the fhtml.cfm
filename? No, you don't want that for the ED setup, but it can be helpful
for understanding what's going on just trying to get to the FR instance
itself from different places.

Also, is the cfusionjrun.myservername the CF instance you're interested in
watching in the ED? Or is it another instance, perhaps in the same CF
Multiserver setup? To be clear, when you use no port, that means it's going
to IIS, so IIS will hand that request to whichever instance it's configured
to hand cfm pages to (which is why it's important to add the .cfm filename,
when using a URL that would go through IIS. That's not needed when using the
FR built-in port, nor for the FRED since it uses still another communication
protocol.)

Finally, yes, I heard you say the desktop is in the same network as your
server. Still, please do proceed to these tests and let us know how it goes.
There's always an explanation for when things don't seem to work. :-)

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of leontova
> Sent: Tuesday, March 06, 2012 2:25 PM
> To: FusionReactor
> Subject: [fusionreactor] Re: Enterprise Dashboard not Connecting
>

[leontova]

Hi Charlie. FRED is being run from my desktop.

Q. What happens when you browse the URLs in your browser (with and
without the port) first from your desktop, then from your "host
server"?
A. From the Desktop, I can get to the exact same site
http://servername:8087/fusionreactor/fhtml.cfm?mode=main as I do on
the host server at http://127.0.0.1:8087/fusionreactor/fhtml.cfm?mode=main
A1. Without using the port, I get a Login failed From both Desktop and
host server

Q. Also, are you using the full URL, with the fhtml.cfm filename?
A. Yes

Q. No, you don't want that for the ED setup, but it can be helpful for

understanding what's going on just trying to get to the FR instance
itself from different places.

A. For ED I'm using http://servername:8087/fusionreactor

Q. Also, is the cfusionjrun.myservername the CF instance you're

interested in watching in the ED? Or is it another instance, perhaps
in the same CF Multiserver setup?

A. I have a server farm where the other cf servers are grouped on my
host cf server. I am using FRED on my desktop to log into the host
server and view the farm. The host server is included in the farm.

Thanks for your time!

-Andy


On Mar 6, 3:25 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:

[charlie arehart]

Thanks, Andy. That info may help the FR support folks if they have more
ideas. In the meantime, do check out the reactor.log in whatever instance is
hosting your Enterprise Dashboard, to see if it's logging any additional
diagnostic info to help with your challenge.

And to be clear, if you're on FR 4, don't rely solely on the display of logs
in the FR interface, since FR4 by default now clears out the logs every hour
to zip them into the archives directory. Look instead at the actual
logs/archives directory itself to view the logs. And again, be careful to be
sure you're looking at the reactor-*.log for the instance in which you
implemented the dashboard (since that's the caller from the ED to the server
you're trying to watch).

Hope that helps.

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of leontova
> Sent: Wednesday, March 07, 2012 1:18 PM
> To: FusionReactor
> Subject: [fusionreactor] Re: Enterprise Dashboard not Connecting
>

[Darren Pywell]

Hi Andy,

If you get the message that the server could not be contacted it is
typically that the URL that is entered in the managed servers has a
URL that cannot be accessed directly from that client. Can you check
that the URL entered in Managed Servers is accessible from the client
where you are running FRED.

If that isn't the issue, could you send the reactor.conf file from the
instance that you are connecting the ED to, to support at fusion-
reactor .com. You can find the reactor.conf under the FusionReactor/
instance/<instance name>/conf folder. We should be able to take a look
at the URL's and see if there are any issues.

Thanks,
Darren

[leontova]

Thanks Darren. I will send the .conf file now.

-Andy

[Darren Pywell]

Just to update. We are working with Andy over support. We will publish
our findings once we understand the problem better.

Best,
Darren