I am using OpenShift 4.5 to deploy Dynatrace Oneagent, using Dynatrace operator. Everything is running as intended, but what I do not understand is why are so many dependencies set up on underlying node (e.g. certificates, there are also quite some binaries set under `/opt/dynatrace/oneagent/agent/bin`)? Shouldn't those be part of image or in case of e.g. certificates mounted via configMap/secret?
Hi Bostjan B.,
I assume you have deployed the OneAgent operator and it deployed the OneAgent via container on the nodes - probably the most common way on OpenShift. Files are put on the node to be able to inject code modules into other processes running in containers and on the host itself.
I'm not sure about your question regarding certificates, as they are not involved in the deployment of the OneAgent itself, but operator uses https connection to the Dynatrace API (either to the cluster or to the ActiveGate) to fetch the installers.
If the question stands for why there are some certificate filtes in the /opt/oneagent directories, then it's because the same OneAgent is also used for non-kubernetes platforms.
There are also more deployment strategies that are available with OneAgent Operator 0.8.0 such as automated runtime injection using admission controllers.
See more here:
how to download dynatrace oneagent
Well in that case it doesn't look like the activegate is reachable by the host on port 9999/tcp, are you sure the communication from the host with oneagent to activegate on port 9999 in tcp is allowed by the network team?
Starting with Dynatrace OneAgent 1.131 and Cloud Foundry Node.js buildpack 1.6.10 Dynatrace is part of the buildpack.Using the buildpack is preferable to the npm module approach due to several improvements. For instance,you're no longer required to install a dependency on dynatrace/oneagent in your project directory.You also no longer need to add a require statement as the first statement of your application.Please review the Dynatrace product newsand documentationto learn more.
Hi Rodrigo,
Are you using build/auto/runtime injection ? -and-configuration/setup-on-cloud-platforms/amazon-web-s...
Verify if you are using alpine linux or not
(if alpine, the oneagent image name will be : /linux/oneagent-codemodules-musl: )
Check the cloudwatch logs any reference to oneAgent or add the environment variable "DT_LOGLEVELCON=info" to get more details.
If still not seeing any information, try to run the image locally and you can ssh into the container and verify if the oneagent is running inside of the container.
Some related errors I have seen in the past is that the Dynatrace cluster or the repo where the oneagent image is, does not has a valid certificate, so docker will fail when pulling the image.
Hello,
Im not aware of the flag DT_LOGLEVELSDK , where did you saw that one?
(The one I used before is " DT_LOGLEVELCON = info")
If you don't see logs (besides Info: using DT_HOME...) that means that the agent is not being injected at the process level.
Things that you could check on why it could fail the injection:
- check the technology used to be monitored (java,.net...)
- you mentioned that you are using the musl version, try also with the regular version just in case (I remember years ago I had a image that was failing the injection because we though it was alpine, but it wasn't)
- try to print the env variable LD_PRELOAD, it should have a reference to a Dynatrace library (/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so). I had an scenario where other tools where overriding the LD_PRELOAD, removing the Dynatrace library so no automatic injection was possible
- you could do a manual injection on the app process to verify if it is working, for example:
export JAVA_OPTS="$JAVA_OPTS -Xshare:off -Djava.net.preferIPv4Stack=true -agentpath:/opt/dynatrace/oneagent/agent/lib64/liboneagentloader.so=server=hhtps:///e/:443,tenant=,tenanttoken=,loglevelcon=info"
- The last troubleshooting option I had to do was to modify the dynatrace-agent64.sh to print some echos and verify which steps on that script were executed. (JUST TROUBLESHOOTING PURPOSES)
Regards
To be honest there was NO entrypoint in the original Dockerfile, somehow this container knew that starting point is /docker-enrtypoint.sh (which starts kong nginx smth, probably set in the original "FROM" image). So I knew I have to inject the LD_PRELOAD before /docker-entrypoint.sh is magically called. I came to this long ENTRYPOINT as you can see above. This runs DT magic first with a set o 3 parameters. And I think this made a change... I have to note that running /dynatrace-agent64.sh wont set the LD_PRELOAD outside the script, dunno why? Exported var is visible inside the script but not when it finishes
Otherwise, it may be that Ansible is looking for the role in the wrong directories. In this case use the ansible.cfg file to specify the roles directory where the oneagent role was installed (/root/.ansible/roles from your screenshots).
There are times (traditionally within containerized environments) where the agent is properly injected and running but its log file cannot be placed within the normal location on the host, i.e. /opt/dynatrace/oneagent/log.
Amazing , would like to know if agent is stopped however jars references are still there in Application processes which is creating log files even DT environment is down. how can we make sure those 4 jars(oneagentjava) files not get loaded without uninstallation of Oneagnet? can this is possible through command line?
A best practice is to first install the ActiveGates, after which OneAgents are deployed. However, it is possible to reconfigure a OneAgent to point to a different ActiveGate or SaaS tenant, by using the oneagentctl command-line interface. -communication
Go to Deployment status -> ActiveGates,
unfold ActiveGate and find "Number of currently connected hosts".
If the number is 0 then no Agent is connected.
If the number is > 0 , click the number and you will see the list of all Agents using this ActiveGate.
If you do not see the OneAgent on DeploymentStatus You can check AG logs.
AG reports number of agents' processes reporting data through the AG, to dynatracegateway_Debug.0.0.log. (The number is bigger than the number of OneAgents) Search for "Active agents:".
The number is reported every 10 minutes. So you can verify if there were any agent connected.
You can also download AG diagnostic data and check /debugui/Agentlist.html, but the ids on the list are runtime, they change every time when the reporting process is restarted.
May be could you keep me posted as well- As i am also chasing the same issue. I am curious to see if it is oneagent version that causes the issue- I am wondering if it is the settings of oneagent communications with SE linux ?
Both SaaS and Managed. Just imagine if you are dealing with any problems when something is not working as expected. If you don't have administrative access to systems with oneagent, you are unable to effectively determine root cause or handle support tickets in case of any issues with agent, plugins or injections.
Asking sysadmins (or anybody else who has administrative access) to copy log files over every time, just to look into oneagent log files is at least uncomfortable. Especially when Dynatrace already has the functionality to view and download any other log file.
In big enterprise companies, as administrator you do not have access to all Servers. In our case we have a Monitoring Team and if we want to see the log of the Oneagent, we always have to consult the team who is responsible for that. So i can confirm Julius statement. If there is a way to see the log file of the oneagent in die UI, this would be great.
I asked about this via chat, and the response was that this IP for the oneagentos process is assigned by the OS, and there's no way to configure that manually (like we can for the Watchdog processes in the 50000+ range).
Hi,
I am calling azure vm extension for installing dynatrace oneagent from tf. It is installing one agent but cannot configure host group.
But If I create from azure portal it is creating host group but not from terraform. Is it not possible from terraform or something is missing. Below is my code which works and provision extension but does not create hostgroup.
1) Log into OpenShift Container Platform dashboard and create a project 'dynatrace' (or any name you want).
2) On the OpenShift Container Platform dashboard, select Operators -> OperatorHub from the side menu.
This will install dynatrace.oneagent collection that consist of a single role that deploys OneAgent using dedicated configuration and ensuring the OneAgent service maintains a running state. For more information, see Using collections in Ansible documentation. You can also find the latest version at Ansible Galaxy
Using the example playbook below, replace the dynatrace_environment_url and dynatrace_paas_token variables to install OneAgent. You can tweak the command with a text editor eg. Notepad++
If you also want to deploy Dynatrace to Windows Diego cells, configure a second add-on section for the dynatrace-oneagent-windows job. The properties for environmentid, apitoken, and apiurl remain the same as with the normal Linux configuration.
To fix that, you need to deploy a component that takes OTLP/JSON and forwards OTLP/protobuf to Dynatrace. This can be achieved with the OpenTelemetry collector. Here is the documentation on how to configure it properly for Dynatrace: -dynatrace/opentelemetry/basics/collector
35fe9a5643