Closed
Description
This is an offshoot of #76.
There are some questions about whether active
and disableInstrumentations
config should be reloadable, or whether they should be static.
Currently, in the Node.js agent, starting the agent with active: false
would skip instrumentation entirely. This means that it is not possible to dynamically "activate" the agent.
Elsewhere, users of the Java agent have assumed that setting active: false
would completely disable the agent: elastic/apm-agent-java#639. Given the config's name, this is pretty a fair assumption. In that case it was due to metrics which we can fix, but still leaves a question about remote config polling in the future.
So, open questions:
- What should
active: false
do? Should this just disable event generation, or should it disable all code paths, including remote config polling?- If
active: false
disables remote config polling, should we have some other config that allows the agent to run "dormant" - polling remote config, but not generating events? - If
active: false
disables only event generation, should we have some other config which disables everything, including remote config polling?
- If
- Should we have ternary state for disabling instrumentation? On, off (but possible to turn on), skipped entirely (never instrumented in the first place - cannot turn on).