Hello,
My application is running inside a docker container. If i use jvm args for apm agent attached like below, working fine
javaagent:/opt/elastic-apm-agent.jar -Delastic.apm.service_name=myApp -Delastic.apm.server_url=http://test:8200
i am trying to use self-attach as per the below documentation, which mentioned Use this script to automatically attach to all docker containers running on a host. not able to get it up.
What i tried:
Created a selfattach.sh file inside root folder of the container with below:
#!/usr/bin/env bash
set -ex
attach () {
# only attempt attachment if this looks like a java container
if [[ $(docker inspect ${container_id} | jq --raw-output .[0].Config.Cmd[0]) == java ]]
then
echo attaching to $(docker ps --no-trunc | grep ${container_id})
docker cp ./apm-agent-attach-*-cli.jar ${container_id}:/apm-agent-attach-cli.jar
docker exec ${container_id} java -jar /apm-agent-attach-cli.jar --config service_name=App_Perf --config server_url=http://Test:8200
fi
}
# attach to running containers
for container_id in $(docker ps --quiet --no-trunc) ; do
attach
done
# listen for starting containers and attach to those
docker events --filter 'event=start' --format '{{.ID}}' |
while IFS= read -r container_id
do
attach
done
Tried to run the bash file, getting below error, not sure what this related to. Request to let me know the fix.
Caused by: java.nio.file.AccessDeniedException: /tmp/whoami5350918110509627295.tmp
The container is running as eoadmin user and he has access to the root folder of the container.
Hi @Bhanu_Praveen ,
If I understand this correctly, you are trying to use the CLI attacher to automatically attach to JVMs that run within docker containers. This shell script is provided as an example only, and there aren't any strong guarantees it works in all cases. As mentioned in this page, this script is experimental.
For attach to work properly, the attach process needs to have the ability to run with exactly the same user and permissions as the user running the process, which is something that can be tricky to achieve with containers.
As a simpler alternative, I would suggest to change the container environment variables and set the JAVA_TOOL_OPTIONS
to include the -javaagent:
argument, which can be done without modifying the container.
Ya, that's what we are doing for individual jvms by setting below in jvm args. Looking to self attach instead of restarting my jvm and on-demand enabled/disable APM metrics pull.
-javaagent:/opt/trade/elastic-apm-agent.jar -Delastic.apm.service_name=GTMApp -Delastic.apm.server_url=http://test:8200
Maybe as an alternative, you could always add the agent, but use the recording
configuration option.
When set to true
the agent will record and send data, when set to false
it won't send anything.
The advantage here is that you can change dynamically this setting at runtime without restart using either central configuration (remotely) or when agent configuration is in a properties file that you can edit at runtime.
When the agent is attached there is always some overhead involved due to instrumentation, so the application response time tends to be impacted when this happens, if it's already under load it won't help.