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.

FR has to run in the same JVM as lucee to monitor it, so it needs to be on the same machine

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

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.

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

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 😄

It does, thats also exactly what cloud does

And then another instance of FR (homed elsewhere) reports on that data?

You access the data in the cloud, so a web app you have a log in for

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

You don't run the instance of cloud yourself, its an app we host. so all you have to do is login

Gotcha.

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

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

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