Opentelemetry-js: Which plugins are loaded by default

[dyladan]

As we approach beta, we need to decide which plugins should be loaded by default. Some modules are likely uncontroversial, but should all plugins be enabled by default? Here are at least a few options, but whichever we decide should be documented. We should probably make this decision before we get to beta.

note: Web plugins do not load the same way as node plugins and need to be manually added anyways, so this only applies to node. Someone correct me if I'm wrong.

1. Do not enable any plugins by default.
2. Only enable some set of "core" plugins by default (http, gRPC, mysql, postgresql, xhr) which we as OpenTelemetry authors certify are supported by us and recommended for production use (when we get to release).
3. Enable all plugins in the main repo, but not plugins in the contrib repo (contrib repo doesn't exist yet, but may soon).
4. Enable all plugins with @opentelemetry/plugin-* names.

For 3 and 4 it is important to remember that, even if a plugin is "enabled," if the user does not have it installed then it won't be loaded anyways.

Another consideration is that users who don't read the documentation as fully as others may be confused why some plugins are auto-loaded just by being installed and others are not.

[vmarchaud]

In the scenario 3 (if the plugin is inside a contrib repo), does it means we don't officially support/maintain it ?

[dyladan]

If we are going to do 4, then why are we maintaining a default enabled plugins list at all?

At least for me, here is what I would recommend.

Continue maintaining a default plugins list, but do so in a separate package called @opentelemetry/plugins (or plugins-core or whatever else we want to call it). @opentelemetry/plugins has all default plugins as regular dependencies. @opentelemetry/node depends on @opentelemetry/plugins as a DEV dependency ONLY.

@opentelemetry/plugins contains the following code

// example values only
export enum Plugin {

}

export const enum Plugins {
  stable = "@opentelemetry/plugin-foo,@opentelemetry/plugin-bar", // and so on
  beta = "@opentelemetry/plugin-baz,@opentelemetry/plugin-quux", // and so on
}

NodeTracerProvider construction now looks like this (const enums are compiled away)

import { Plugins } from "@opentelemetry/plugins"
import httpPlugin from "@opentelemetry/plugin-http"
import communityPlugin from "some-community-plugin"

const providerWithStable = new NodeTraceProvider({
  plugins: Plugins.stable,
});
const providerWithAllPlugins = new NodeTraceProvider({
  plugins: [Plugins.stable, Plugins.beta],
});
const providerWithSpecificPlugins = new NodeTraceProvider({
  plugins: [httpPlugin, communityPlugin],
})

[dyladan]

n the scenario 3 (if the plugin is inside a contrib repo), does it means we don't officially support/maintain it ?

I think the whole point of having a contrib repo would be that anything in it is _community_ supported instead of being explicitly supported by OpenTelemetry authors.

[mayurkale22]

I would like to see all core plugins/instrumentations enabled by default (even install the respective dependency), to make it super easy for users to use i.e no extra steps required to do to use core plugins. To load an additional(non-core) plugin, they can specify in the config and install the package themselves.

[obecny]

I'm in favour of enabling all plugins that are installed by default, this way it will be at least easy and straightforward and users don't need to worry when we decide to change the default list so then suddenly something will stop working or not. But I think we should still give users the options to enable the plugins one by one and to set a "default" list to no plugins. This way it will be up to users to decide how they want to handle that but also it will be super easy for majority of them (enable all installed plugins).
And with regards to default list I would recommend not to create such as it might confuse users and will require to explain this more and more.

[dyladan]

How do we determine which plugins are installed? We can do that for plugins under our namespace, but if there are third party plugins that we don't control they won't be discovered.

[OlivierAlbertini]

if there are third party plugins that we don't control they won't be discovered.

We can also create an "awesome openTelemetry plugins" repo, where developers can make a PR to add . their plugin repos.... It's less job and users will decide to trust or not.

Having a contrib repo means that we need to have people to review code and also manage release in npm registry.

I think we will have more quality with a contrib repo but it will be also more job.

[dyladan]

@OlivierAlbertini definitely. I think we could even just have a JSON of autodetected plugins in @opentelemetry/node that is a simple list of packages to try to require. Very low barrier to entry, and individual plugins can always be disabled by name.

[naseemkullah]

If both http and express are enabled (by default), do we get twice the telemetry? E.g. 2 spans per request received?

[OlivierAlbertini]

If both http and express are enabled (by default), do we get twice the telemetry? E.g. 2 spans per request received?

Express plugins will give you observability on middlewares whereas http is only on the request. Middleware spans should be under request span.

Only issue I see, if you are filtering requests on http, you will see them with the express plugin and it doesn’t make sens to me.

We should share the same config among all plugins... we are encoutering several issues about that

[mayurkale22]

Per SIG discussion, removed this from the Beta milestone. Will come back to this after Beta.

[pauldraper]

I believe https://github.com/open-telemetry/opentelemetry-js/issues/783#issuecomment-585794357 is the clear and simple approach, where the list of plugins is passed to the TraceProvider.

For ease of use, OpenTelemetry exports -- say -- a list of common plugins and a list of all plugins.

3rd party libs work the same way, where they export a list of plugins.

Users can filter the lists if there is one specific problematic one.

Users can combine lists and reuse them.