DT_INJECTION_RULES not supported about bosh-oneagent-release HOT 6 CLOSED

@PatrikSteuer would this be covered by putting

exclude:
    lifecycle: errand

into the runtime config? Or are these short living VMs not handled as errands?

from bosh-oneagent-release.

@arthfl this does not seem to be a feasible solution, since the processes are managed by spark, and not bosh itself. So I doubt that this can have any effect.

from bosh-oneagent-release.

So it is currently not possible to define DT_INJECTION_RULES to ignore specific processes, using the onagent with this boshrelease?

from bosh-oneagent-release.

Hi there. Matt here. PM you folks met a couple of weeks ago. I discussed this problem with people smarter than I am, and learned a bunch about the surface area of the issue, and why it is more complicated to solve than we would like.

First, allow me to describe how Dynatrace injection rules are usually applied, and also updated. After that, we can look at how the DT_INJECTION_RULES environment variable conflicts a bit with this means of applying them. Finally, I will tell you what we'll need to do to solve the problem. Apologies if none of this is new information. It certainly helps me understand the problem more deeply, and I hope the exercise of describing it in writing helps you as well.

As you may know, injection rules, along with other configurations, are provided to an agent at different times. The first is during installation through the script that you cut / paste in the dashboard. This shell script would ordinarily contain injection rules, and other things, so the agent works properly upon installation.

These configs can also be updated, at any time, on the tenant, and are subsequently sent down to the agent when they communicate during the ordinary lifecycle of reporting events and metrics. In this way, the rules that were originally placed in the installation script can be removed / enhanced at any time, dynamically.

From what I understand, the DT_INJECTION_RULE environment variable helps SAP by providing these rules using an alternative vehicle. The question from a product side is how these rules should be reconciled.

If we had an API for agent configurations, which allowed SAP, or anyone for that matter, to construct rules - this would satisfy the requirement of (1) order of operation and (2) single source of truth. Using the environment variable does not allow for (1) nor (2). This API does not exist, at present, but I am happy to begin discussing the problem with the teams responsible for it.

Also happy to jump on a call to discuss further.

Best,

M

from bosh-oneagent-release.

Solved with #55

from bosh-oneagent-release.

Thanks a lot.

from bosh-oneagent-release.