http://coldfusion.com logo
a

Adam Cameron

06/14/2022, 9:54 AM
I don't recall whether I did ask this before, or whether I meant to, and then never got around to it. Getting old. Anyhow, sorry if this is the second time I've asked. I do not know much about FR, other that the theoretics of how I'd expect it to work. Is it normal to have the FR application installed on the very production servers it is monitoring, or would be be more normal to have it running on its own server, and just somehow connecting to the JVM it's monitoring via the network? (in my situation read "container" for "server"). We are installing and running FR from within the Lucee container that is serving our Lucee application, which seems... odd... to me. I would expect the Lucee container to have Lucee running, and another container running FR, and FR to just be listening to the Lucee container's JVM. Or just have like an agent running in the Lucee container that the FR server talks to, or whatever.
m

mflewittintergral

06/14/2022, 9:57 AM
FR has to run in the same JVM as lucee to monitor it, so it needs to be on the same machine
p

Pete Williamson

06/14/2022, 10:17 AM
if you use FR cloud, the data is stored off server/container so you can look at your data historically and still access it if your server falls over
a

Adam Cameron

06/14/2022, 10:40 AM
Hrm. OK. My basis for wondering was because things like jconsole can connect to a remote JVM, so wondered if [whatever mechanism provided that] exposed the same information FR would need for its metrics reporting. It's been ages since I did anything with jconsole, so can't remember the tech detail of how it works.
It seems fragile to me to have the monitoring sw in the same system as that which it's monitoring. But I guess provided it can write its metrics out to something external, then another FR instance can report on it?
m

mflewittintergral

06/14/2022, 10:44 AM
you can get limited depth with something like jconsole, but tracking an application properly involves injecting into and wrapping code dynamically and being deep within the running JVM. We need to be in the java underneath lucee / CF. This is not just a FusionReactor thing, datadog, dynatrace and any other APM need this too
you can pipe the data out to cloud so its retained, or you have the logs for the instance post crash
a

Adam Cameron

06/14/2022, 10:46 AM
Well I was thinking about Dynatrace. Doesn't it just run some sort of agent on the JVM itself, and all the rest of it is [across the network]? [frantically googling] JMXsomethingsomething 😄
[can you tell how comfortable I am discussing things like this 😄 ]
m

mflewittintergral

06/14/2022, 10:46 AM
It does, thats also exactly what cloud does
tracks on the local agent, and ships the data to the cloud for storage
1
a

Adam Cameron

06/14/2022, 10:47 AM
And then another instance of FR (homed elsewhere) reports on that data?
m

mflewittintergral

06/14/2022, 10:48 AM
You access the data in the cloud, so a web app you have a log in for
a

Adam Cameron

06/14/2022, 10:49 AM
So it's like: [server/container running Lucee JVM -> FR agent] -> cloud storage <- [server/container running FR reporting server] -> Nice HTML reports for me to look at
m

mflewittintergral

06/14/2022, 10:50 AM
You don't run the instance of cloud yourself, its an app we host. so all you have to do is login
1
it essensially the same data you get in on prem, but for all instances in one place
a

Adam Cameron

06/14/2022, 10:52 AM
Gotcha.
Sounds like what I want. Currently we're running FR out of our prod container. ie: the same one running the prod app.
I'm asking cos I see the install of FR going on in our Dockerfile, and am going "erm... that seems subpar", so just trying to understand why.
m

mflewittintergral

06/14/2022, 10:58 AM
you need the agent in the docker file because in order to instrument java, you need to be in the JVM. Thats just the reality of java, so nothing we can do about it
a

Adam Cameron

06/14/2022, 11:00 AM
sorry, I mean we are running the entirety of FR in the same container. The UI bit as well. I get it'd need an agent to be installed. That's fine/necessary. As you say
c

carehart

06/20/2022, 4:00 PM
going back to this thread of last week, to summarize if it helps some: • one needs the FR agent within the jvm (so implemented "inside" CF or Lucee or a container instance for them). As noted, other java apm's work this way, to get info available only "from within" the jvm • that FR agent happens to also (by default) expose a web web server (port 8088, by default), which offers the traditional FR UI (now called the "on-prem" ui). this part may be less common with other APMs, and of course it's ephemeral: goes away with a container stop (and the data it tracked goes away with an instance stop) • even before discussing FR Cloud, note also that FR also logs a tremendous amount of info. That can be viewed across restarts, of course, which can be pushed to a logging solution, or with containers can at least be pushed to a more persistent volume • And since FR 7.2, the on-prem UI alone has offered "metrics>archive metrics", which can graph and view those logs--and you can tell it where to find those, but it presumes a traditional location within an on-prem folder • Then in the past few years, FR Cloud has come along and offers what Mikey and others refer to: pushing the metrics (and soon, the logs) out of the FR instance and up to the cloud, which offers its OWN (different) UI. The FR folks manage that FR cloud instance (and datastore), but it's secure and can be made still more secure with obfuscation, or the push to it can be disabled. • There's also plans afoot to allow a local deployment of that, for those who cannot push info to the cloud, but want that whose experience in their network but off the instance/container • Hope that helps
2 Views