Java agent to monitor Micro-services

Elastic Observability APM
1

Can we use Java Agent to monitor micro-services

2

Hello,
What framework, tehcnologies do you use in your java micro-services?
Here you can find supported technologies by java-apm-agent.

3

Thank you. Actually let me re-frame my question: my application is consists of 10+ micro-services (Java based). Now, do I need to install APM agent in the tomcat alone? Or in all the 10+ micro-services

image
image739×460 3.25 KB

4

Hi @AshishC, it all depends on what level of visibility do you want to have

  • if you deploy on Tomcat alone, you will see transactions handled by Tomcat, with some spans when work is delegated to other micro-services, in other words those services will be 'black boxes'
  • if you deploy to all those services, you will get distributed tracing, and being able to trace every transaction including what is executed on those micro-services. This also works when those services use another platform (like PHP or Ruby) as long as there is an APM agent available.
5

Thank you Sylvain_Juge. Actually I am doing the performance impact analysis of APM Java agent. Primarily results are good and I don't see any deviation in the overall app performance. Just wondering, if there's any best practice - to have one agent for all the micro-services ( all micro-services and tomcat are hosted on same server) Or separate agent for each of the Java application.

In order words-

  1. Single agent for multiple apps ( more load on the agent)
  2. One agent per app ( more agents and hence more load the server)

thanks

6

Making APM agent having minimal overhead on the application is one of our top priorities, thus if you have any issue here, we'll be happy to fix it !

On Java applications, there is one java agent deployed per JVM process, thus there is no way to share agent instances. You can however use the same java agent jar as they all run on the same server, but that makes upgrading a challenge since you have to stop/start all JVMs at once.

Also, it means there is potentially a separate configuration for all of those services, thus you can either monitor them together as a single application, or monitor each micro-services or group of micro-services as a separate service.

Thus in your case, my advice is to

  • deploy APM agent on all JVMs running your micro-services
  • use a separate copy of agent jar to allow upgrading them independently afterwards
  • (maybe) use a single remote configuration for all of them since you have a dozen to manage.
1 Like
7

Thank you.

  • deploy APM agent on all JVMs running your micro-services
    I assume deploy means, setting up below config changes-
    -javaagent:/opt/elk_apm/elastic-apm-agent-1.13.0.jar -Delastic.apm.environment=performance_env -Delastic.apm.service_name={tomcat/msvc1/mscv2..} -Delastic.apm.server_url={Host_URL} -Delastic.apm.application_packages=com.pkgname"
  • use a separate copy of agent jar to allow upgrading them independently afterwards
    Since all msvc are hosted on the same server, so we have placed the jar in common location
  • (maybe) use a single remote configuration for all of them since you have a dozen to manage.
    Thanks for sharing this , this is all good
8

Regarding having only a single copy of the agent, since you kept the full agent jar name (including version) in the file name, you will not have any issue to upgrade.

However, let me explain what happens when it's not the case:

If for convenience you deploy agent and renaming it to something like /opt/elastic-apm.jar, that allows to update agent without changing you JVM parameters, which could be convenient since an update would just require to overwrite the file (this might be stored in a application server xml file, thus not really easy to edit on the fly).

Then, if multiple JVMs use this agent, you have to shutdown them all, update the agent file, then restart them all. If you do not do this and only shut down a single JVM, the following happens:

  • the OS (Linux, Windows prevents it) will let you overwrite the agent jar file, even if it's still opened by another JVM
  • if the running JVMs need to load new classes from agent, it will throw exceptions since they aren't available anymore or are incompatible with the ones previously loaded.

This is also the same that happens if you overwrite the agent while the JVM is running, while you can do it, but you should probably not do it.

1 Like
9

Very clear, thank you so much for taking time in writing such a wonderful explanation. A Big Thank!

10

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.