With OneAgent Operator version 0.8.0 there is built-in support for automated container injection via webhook for application-only monitoring at runtime based on a new custom resource of type "OneAgentAPM" and a set of dedicated labels that can be provided for the app container.
My question is this: Does this deployment method conflict in any way with the traditional operator-managed and dockerized fullstack OneAgent?
Say for example, we decide to add a custom resource of type OneAgentAPM for an operator that is already managing dockerized OneAgents and we add the label
oneagent.dynatrace.com/instance: <OneAgentAPM object name> to an application container running on a node that is already monitored via a dockerized OneAgent - is this supported and will there be any limitations with regards to fullstack monitoring of the app container?
The reason I'm asking is because it seems this would allow applications more control and flexibility over the OneAgent version that gets injected into their container as they can use label
oneagent.dynatrace.com/installer-url to install a specific OneAgent version into the container.
Solved! Go to Solution.
Hi there. I will publish a blog on this shortly. The short story is that you cannot, yet, use this with the fullstack approach. This is coming in a later release. So, for now, you must choose one or the other.
In a few months, you'll be able to control versions as you say, and do some interesting pipeline integrations as well. You could poll the deployment API, see when the latest version is available, download the agent as a docker image, run it through your pipeline, tag it, and push it when you're ready.
So. Think of this as phase 1. It's application only, and it has the advantage of central control (rather than editing Dockerfiles or deployment YAML). Phase 2 will provide full agents as docker images from the cluster via Docker pull. Phase 3 is the whole solution, with a "full stack" approach, proper licensing, logging, admission controller injection, and heap dumps.
Incidentally, we'll also have a containerized ActiveGate at that time, which will allow you to connect to the K8s API in one shot via the same Operator, rather than the two-step dance you need to do today.
So. Lots of goodness coming, but this particular release is a bit limited.
Thanks for the quick feedback - interesting stuff!
What about using the dockerized OneAgent in infrastructure mode together with a selective app-only webhook integration of individual application pods/containers, basically giving users the possibility of "selective fullstack" monitoring per namespace/container/pod? Is this a scenario that will be possible now or in a later phase and if so, how would the licensing work out for such cases?
I think it would be really useful for cases where we only want a small fraction of containers to be deep-monitored and where the fullstack licensing per node is disproportionately expensive compared to app-only monitoring...
The issue here is with the host id's. Your host agents will see unknown processes, that are actually instrumented, but the entity model will be confusing, since each container is reported as its own host.
Understood. So is this something that will be addressed in "phase 3" or is this a fundamental restriction that will hold for the foreseeable future?
Phase 3 will give you what you want. Entity model will work, licensing, all of it.
Also, I just learned that there is some injection in "IM" mode as of 196, which means that agent will oveerride the "app only" agent. Another reason you'll have to wait for phase 3.
Where are we currently with respect to "phase 3"? I realize the new Dynatrace operator is available but still doesn't have support for automated app-only injection. Also, I would like to know how/if it's currently possible to control/override the injected code module version when full-stack monitoring is deployed and whether or not the entity model has support for infrastructure-only monitoring of the worker nodes combined with automated app-only monitoring of the containers.... By "support" I mean the relationship between deep-monitored containers and the underlying worker nodes is auto-detected and used accordingly for performing automated RCA.
HI Matthew , if you have published the blog , could you please share the link here?