question

Enrico F. avatar image
Enrico F. asked ·

Resolving conflicts with AppMon agents

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?

appmononeagent
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

Mike L. avatar image
Mike L. answered ·

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

1 comment Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

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

1 Like 1 · ·
Enrico F. avatar image
Enrico F. answered ·

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....

2 comments Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

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.

0 Likes 0 · ·

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.

0 Likes 0 · ·
Joe H. avatar image
Joe H. answered ·

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.

4 comments Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

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) blacklist 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.

0 Likes 0 · ·

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.

-1 Like -1 · ·

Hi Michael,

Sounds good! Is there a release date yet? :)

0 Likes 0 · ·

Maybe a Christmas present in SaaS but no promises yet ;)

0 Likes 0 · ·
Joe H. avatar image
Joe H. answered ·

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.

1 comment Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

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?

0 Likes 0 · ·
Dave M. avatar image
Dave M. answered ·

Hi Enrico,

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

HTH,

dave

1 comment Share
10 |2000000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

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

0 Likes 0 · ·

Space Topics

mobile monitoring dotnet synthetic monitoring reports iis chat kubernetes servicenow amazon web services mysql mainframe rest api errors cassandra dashboard oneagent sdk cmc application monitoring openkit smartscape request attributes monitoring developer community user tagging log monitoring services ufo syntheticadvisory activegate ip addresses auto-detection high five award oracle hyperion webserver uem usql iib test automation license web performance monitoring ios news migration management zones index ibm mq web services custom event alerts notifications sso host monitoring knowledge sharing reports browser monitors java hybris sap vmware maintenance window user action naming javascript appmon ai synthetic classic availability tipstricks automation extensions diagnostic tools session replay permissions davis assistant faq documentation problem detection http monitors server easytravel apdex aws-quickstart network docker tags and metadata cloud foundry google cloud platform synthetic monitoring process groups account usability dynatrace saas gui paas openshift key user actions administration user actions postgresql synthetic locations oneagent security Dynatrace Managed user management custom python technologies mongodb openstack user session monitoring continuous delivery citrix configuration alerting NGINX action naming linux nam installation masking error reporting database mission control jmeter recorder apache mobileapp RUM php threshold azure purepath davis scripting agent aix nodejs android