cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Resolving conflicts with AppMon agents

Enrico_F
Pro

What is the current behavior with Dynatrace SaaS/Managed when the OneAgent encounters a process that is already being monitored by a "classic" AppMon agent (i.e. a Java Agent) which was configured manually?

I.e. will it recognize and report this fact accordingly and make it actionable in the sense that I am presented a warning along with the option to proceed with deep-monitoring the process by performing a restart which will then override the AppMon agent? Or will deep monitoring not be possible until the AppMon agent is removed from the application deployment by other means?

14 REPLIES 14

Mike_L
Dynatrace Pro
Dynatrace Pro

Hi Enrico,

The OneAgent will add its deep monitoring into the Java process, and seeing as there cannot be both an AppMon agent and a OneAgent in a single process, the AppMon agent will not be included. There is no error produced (except for the fact that you won't be able to see it anymore in AppMon).

Kind regards,
Mike

Thanks, much appreciated (even though it's not the answer I would have liked to hear 🙂 )

As any existing AppMon agent config will be "silently" overridden on the next restart I can see some emerging potential for bad surprises when thinking through a possible "soft" migration scenario from AppMon to SaaS/Managed...

cheers,
Enrico

dave_mauney
Dynatrace Champion
Dynatrace Champion

Hi Enrico,

You can turn off deep monitoring on those applications that you want to migrate in a more controlled manner.

HTH,

dave

Hello Dave,

Wouldn't that require that the application(s) be discovered first - and hence the OneAgent injected into the process - before it can be disabled?

Thanks,
Enrico

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

Enrico,

The discovery happens after initially installing the OneAgent on a given host. At that point the Java process is discovered but not injected yet. This is where the JVM restart is required and if restarted the Dynatrace OneAgent would be injected and replace the existing AppMon Java agent. To avoid this replacement event, simply go into Dynatrace, and disable Deep injection for that process, or disable all Java deep injection on that host.

This approach allows for a clean upgrade path so the customer can transition to the Dynatrace Java agent at a convenient time of their choosing.

Hi Joseph,

I guess on container platforms with automatic scheduling it could still happen that the process agent is injected unexpectedly as containers are automatically restarted, scaled and/or moved if deep injection is not disabled quickly enough after initial discovery of the process... Would you agree?

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

Enrico, You can disable auto-injection at the host, process, process-group level. So for example if you had a bunch of containers and you didn't want to inject the Java agent into the JVMs on those containers you could modify the Process Group and set the "Automatically monitor newly found processes" switch to OFF.

But I start to wonder why you're adding OneAgent to containers which are already using AppMon Agents. It seems you should decide which product (AppMon or Dynatrace) you're going to use and not try to mix them.

Joseph,

In an ideal world I would agree with you. But here I'm trying to think through a possible migration scenario where it's not possible to force all apps to remove their existing AppMon integration at once and where both solutions will have to coexist on the same host - at least for some limited period of time.

The ideal solution from that perspective would be either a Dynatrace setting that would prevent overriding AppMon agents or a static process (group) exclude list which can be specified in advance and would contain rules to match processes (command line arguments, linked libraries, container properties etc.) for which to disable deep injection.

Instead I understand it is currently necessary to manually identify processes or process groups which use an AppMon agent as they are discovered and make sure deep monitoring gets disabled for them before a restart happens.

Enrico,

We are actually adding a rule based concept to define which processes should or should not be injected. This would allow you to say that all processes that match a certain pattern should not be monitored by Dynatrace, which would of course leave the AppMon agent in peace.

In a Container platform this would work as well. So you can have the OneAgent installed on the actual host and the simply tell Dynatrace which processes not to deeply monitor. Once you then enable monitoring for a process that has the AppMon agent inside, a restart of that container would then inject the OneAgent and remove the AppMon agent.

hope that helps.

Hi Michael,

Sounds good! Is there a release date yet? 🙂

Maybe a Christmas present in SaaS but no promises yet 😉

Enrico_F
Pro

It seems that starting with managed version 172 the automatic disabling/overriding of configured AppMon Java agents no longer works and the result is that any configured AppMon agent (via agentpath VM option) will be injected together with Dynatrace's Java technology agent... which I assume can have all kinds of ugly sideffects....

This clearly wasn't the case with 170 so I assume there was a (silent?) change going from managed cluster version 170 to 172 - can anyone confirm this?

On our side we are currently observing Java processes being monitored with both solutions simultanously now... interestingly this has been without any functional impact so far....


This thread is almost 2 years old. I suggest you create a new topic for this question, that will help keep the issue clear and get a quicker and more accurate answer.


Having both solutions monitoring together is really bad idea. You may be lucky and do not be affected by overhead but in some case you may break your application.