extensions: rename tracers

[florianl]

Implement the idea shared in #1388 (comment).

Overall, rename package interpreter to extensions and promote a extension specific configuration.

The respective receiver config part would looks like this:

  receivers:
    profiling:
      extensions:
        # Disable Go symbolization via the plugins config
        go:
          disabled: true
        # You can selectively disable other plugins as well:
        # python:
        #   disabled: true
        # hotspot:
        #   disabled: true
        # dotnet:
        #   disabled: true

[christos68k]

Implement the idea shared in #1388 (comment).

Overall, rename package interpreter to plugins and promote a plugin specific configuration.

I'm not sure about this, plugin has specific connotations with Go that do not apply here and this renaming is apt to mislead. I don't see what we gain from this change other than confusion and lots of extra work.

[fabled]

I'm not sure about this, plugin has specific connotations with Go that do not apply here and this renaming is apt to mislead. I don't see what we gain from this change other than confusion and lots of extra work.

Ah forgot this.

But we've now seen that tying the name to interpreter or the tracer flags to tracer seems to have created some confusion.

Agreeably it does create jitter. But I wonder if it would be still helpful in the long term to reduce confusion on the intended usage.

Potential other names for the feature flag / plugin tree: feature or module. Other suggestions?

[florianl]

I just picked plugins as it was suggested, but any other name is also fine by me - like extensions, components (just to name a few).

If plugins is rejected because of Go's connotations, then module might also not be a good option. So far, I think, we can agree, that interpreter might also not be a good option going forward - labels, go symbolization, apmint and potentially #1388 conflict here as well, as they are not interpreters but implement other functionaltiy.

[christos68k]

I just picked plugins as it was suggested, but any other name is also fine by me - like extensions, components (just to name a few).

If plugins is rejected because of Go's connotations, then module might also not be a good option. So far, I think, we can agree, that interpreter might also not be a good option going forward - labels, go symbolization, apmint and potentially #1388 conflict here as well, as they are not interpreters but implement other functionaltiy.

extension or feature SGTM. I haven't read the original PR yet, I'll take a look later today and see if something else fits.

[florianl]

extension or feature SGTM.

Updated the PR to rename interpreter to extension.

[rogercoll]

I reckon extensions will create confusion with actual OpenTelemetry Collector extensions, see this possible configuration:

extensions:
  bearertoken:
  
receivers:
  profiling:
    extensions:
      go:

I will give it a though on other alternatives.

[florianl]

Here are some alternatives:

• addons
• components
• integrations

All of them sound good to me and I don't have a preference. Please let me know, which one you prefer.

[rogercoll]

Why do we need a generic name for different features? My understanding is that symbolization does make sense without a tracer/interpreter, thus it should be a configuration option within the tracer. The idea would be having a custom configuration for each tracer/interpreter. For example:

  profiling:
    tracer:
      go:
        enabled: true
        labels: true
      native:
        enabled: true
        symbolization:
          enabled: true
          lru_symbols: 1234

[florianl]

My understanding is that symbolization does make sense without a tracer/interpreter, thus it should be a configuration option within the tracer.

To stick with the Go example, there is no Go unwinder as Go is handled as part of native unwinding. And by design, native unwinding is always enabled not can not be configured.

Thinking about other current "interpreter" like apmint or golabels, that can also not be accounted to a dedicted "interpreter". For that reason, the current naming "interpreter" no longer fits and should be changed to something future proof.

But I also support the idea of extending the per "interpreter" configuration, as what this proposal already does, and make it configurable for the use to enable/disable certain features, like symbolization or the size of their internal caches.

[florianl]

@christos68k && @fabled :
Do you have preferences on the name?

Here are some alternatives:

• addons
• components
• integrations