Skip to content

[agents] definition of ACTIVE/DISABLED_INSTRUMENTATION #92

Closed
@axw

Description

@axw

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?
  • 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).

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions