28ca163a92
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Code ownership and maintenance of components continues to be an issue, with varying levels of support across contrib. As we approach 1.0 and the ability to mark components as stable, we want to make sure that components that we deem as 'stable' have a healthy community around them. We have three datapoints that we can leverage here: how many codeowners a component has, how diverse these are in terms of employers and how actively the codeowners have been responding to issues/PRs in the recent past. We need criteria that 1. Are reasonable predictors of the component health over the short/medium term 2. Are not too onerous on the code owners Some notes: 1. Some beta components do not meet the criteria listed on the PR. This will be the case even after the transition for some components. This PR makes no claim as to what should happen to these components stability (so, de facto, they will stay as is). 2. The OTLP receiver and exporters do not meet this criteria today because they don't have listed code owners. We can solve this either by carving out an exception or by listing code owners. 3. We need automation and templates to enforce this. <!-- Issue number if applicable --> #### Link to tracking issue Fixes #11850 --------- Co-authored-by: Christos Markou <chrismarkou92@gmail.com> |
||
|---|---|---|
| .. | ||
| img | ||
| rfcs | ||
| README.md | ||
| coding-guidelines.md | ||
| component-stability.md | ||
| component-status.md | ||
| ga-roadmap.md | ||
| internal-architecture.md | ||
| observability.md | ||
| platform-support.md | ||
| release.md | ||
| scraping-receivers.md | ||
| security-best-practices.md | ||
| standard-warnings.md | ||
| vision.md | ||
README.md
OpenTelemetry Collector
Status: Beta
The OpenTelemetry Collector consists of the following components:
- A mechanism that MUST be able to load and parse an OpenTelemetry Collector configuration file.
- A mechanism that MUST be able to include compatible Collector components that the user wishes to include.
These combined provide users the ability to easily switch between OpenTelemetry Collector Distributions 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.
Configuration file
An OpenTelemetry Collector configuration file is defined as YAML and MUST support the following minimum structure:
receivers:
processors:
exporters:
connectors:
extensions:
service:
telemetry:
pipelines:
OpenTelemetry Collector components
For a library to be considered an OpenTelemetry Collector component, it MUST implement a Component interface defined by the OpenTelemetry Collector SIG.
Components require a unique identfier to be included in an OpenTelemetry Collector. In the event of a name collision, the components resulting in the collision cannot be used simultaneously in a single OpenTelemetry Collector. In order to resolve this, the clashing components must use different identifiers.
Compatibility requirements
A component is defined as compatible with an OpenTelemetry Collector when its dependencies are source- and version-compatible with the Component interfaces of that Collector.
For example, a Collector derived from version tag v0.100.0 of the OpenTelemetry Collector MUST support all components that
are version-compatible with the Golang Component API defined in the github.com/open-telemetry/opentelemetry-collector/component module found in that repository for that version tag.
OpenTelemetry Collector Distribution
An OpenTelemetry Collector Distribution (Distro) is a compiled instance of an OpenTelemetry Collector with a specific set of components and features. A Distribution author MAY choose to produce a distribution by utilizing tools and/or documentation supported by the OpenTelemetry project. Alternatively, a Distribution author MUST provide end users with the capability for adding their own components to the Distribution's components. Note that the resulting binary from updating a Distribution to include new components is a different Distribution.