add document defining an OpenTelemetry Collector #4313
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| <!--- Hugo front matter used to generate the website version of this page: | ||
| path_base_for_github_subdir: | ||
| from: tmp/otel/specification/collector/_index.md | ||
| to: collector/README.md | ||
| ---> | ||
|
|
||
| # OpenTelemetry Collector | ||
|
|
||
| The goal of this document is for users to be able to easily switch between | ||
| OpenTelemetry Collector Distros while also ensuring that components produced by | ||
| the OpenTelemetry Collector SIG are able to work with any vendor who claims | ||
| support for an OpenTelemetry Collector. | ||
|
Comment on lines
+9
to
+12
There was a problem hiding this comment. I'm not sure I understand this goal. If a vendor produces a collector distribution that has a subset of available components because those are the components relevant to their service offerings and that they're willing to support, where do any other components (whether hosted in an OTel repo or not) fit into that picture? Do we mean that a distribution must offer end users the ability to modify its source and create their own build? We should be explicit about that if that is the case. Given that the licensing of the collector's source code does not require that distribution of derivative works happen in source form I'm not sure that we have much ability here to enforce such a requirement. We can certainly try to use the "OpenTelemetry" mark as a cudgel, but I'm not sure it'll be as effective as may be desirable since the terms "collector" and "distribution" are very broad. It could perhaps be argued that "OpenTelemetry Collector" is a protectable mark and maybe even that "Collector" has acquired secondary meaning in this limited scope, but protecting such a mark against genericization is going to be a Sisyphean task. There was a problem hiding this comment. I see this definition as separation from the term Something is not an OpenTelemetry Collector if it cannot support OpenTelemetry Collector Components. Maybe the word There was a problem hiding this comment.
We potentially have leverage over:
I think we have enough leverage here to make this worth it |
||
|
|
||
| - An OpenTelemetry Collector _MUST_ accept an [OpenTelemetry Collector configuration | ||
| file](#opentelemetry-collector-configuration-file). | ||
| - An OpenTelemetry Collector _MUST_ be able to include any and all | ||
| additional [Collector components](#opentelemetry-collector-components) that | ||
| the user wishes to include. | ||
|
There was a problem hiding this comment. What happens when the user wishes to include two different components that both claim the same type string? Does that then make every collector implementation non-compliant? There was a problem hiding this comment. I see this as an edge case that would be up to the components to sort out, unless there's a future where There was a problem hiding this comment. I'm not sure how this needs to be resolved, but I think it does need to be resolved since as written this would make it trivial to create a situation where there can be no OpenTelemetry Collectors at all. There was a problem hiding this comment. Added some details in the components section to provide a way to resolve conflicts for components, PTAL
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## OpenTelemetry Collector configuration file | ||
jpkrohling marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## OpenTelemetry Collector components | ||
|
|
||
| For a library to be considered an OpenTelemetry Collector component, it _MUST_ | ||
| implement the [Component interface](https://pkg.go.dev/go.opentelemetry.io/collector/component#Component) | ||
| defined in the [opentelemetry-collector repository](https://github.com/open-telemetry/opentelemetry-collector). | ||
| repository. | ||
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ## OpenTelemetry Collector Distribution | ||
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| An OpenTelemetry Collector Distribution (Distro) is a compiled instance | ||
| of an OpenTelemetry Collector with a specific set of components and features. | ||
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
codeboten marked this conversation as resolved.
Show resolved
Hide resolved
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OpenTelemetry Collector is never defined. Is it a source code artifact? A binary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's one of the things I was trying to get at here. Since there's no binary plugin mechanism it seems that the source would need to be available for it to be extended in the manner contemplated, but that's not clear or explicit in the current state.