Add pages for collector components

[jaydeluca]

I am experimenting with automation that scrapes collector metadata and generates these pages. Github action jobs will run nightly that look for changes, and will regenerate the pages and submit PRs accordingly.

This is a starting point, and likely to evolve as we expand the data we include for each component.

cc @tiffany76

---

PREVIEW: https://deploy-preview-8001--opentelemetry.netlify.app/docs/collector/components/

[jaydeluca]

i wasnt sure whether it made sense to include the x components?

[mx-psi]

I think we can exclude those

[dmathieu]

This is nice. But looking at it, it could be read that those are the only components anyone can use, which isn't true (if you build your own distribution, you can use any component, including private ones).

Speaking of distributions, there are 5 different official collector distributions. How about adding which of them each component is included into?

[tiffany76]

Thanks for taking a look at this POC, @dmathieu. We're just getting started and can use expert input!

We plan to update the language on the pages and will not only call out that users can use other components, but also cross-reference the registry, which includes many that are not part of core/contrib.

We're starting with a light lift for this POC while we investigate exactly what should be included and how it should be displayed. I'll add the otelcol distribution to our list of what should be included.

Thanks again!

[mx-psi]

This looks great!

Some ideas (not necessarily for this first version, just writing them down somewhere):

1. I wonder if it would make sense to style/order components differently depending on their stability level (since the stability level can vary per signal I guess the following can be done by taking the max stability level).
   For example, we could fade out in development components and strike out those that are unmaintained, and/or order components based on their max stability level (so that first you see stable components, then beta components, then alpha and lastly development). We could even separate alpha components into a collapsed box to signal that they are more experimental.
2. We are missing profiling support from the list! This is an experimental signal so maybe can be excluded
3. I think it would be great to have links to https://opentelemetry.io/docs/collector/configuration/#receivers and similar somewhere in these pages
4. It would also make sense to me to link to https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md somewhere

[mx-psi]

I think we can exclude those

[chalin]

A few broad questions and comments:

• Have you seen https://opentelemetry.io/status/#collector? The added page content seems to be mostly statuses for components. Might it make sense to put these pages (or at least their status content), under https://opentelemetry.io/status/#collector or a new subsection of https://opentelemetry.io/status/?
• Re. the automation: under which repo will the GH actions run (and where will be the associated scripts, if any)?
• There is https://opentelemetry.io/docs/collector/distributions/. Is there an overlap with what is being proposed here as content? If so, will it lead to confusion for readers?

[chalin]

OTel defines official levels of maturity in the spec(s) and elsewhere, such as https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md (as you probably know :). Could we link to that page as the main source of truth?

[tiffany76]

@mx-psi, thank you for the review!

I wonder if it would make sense to style/order components differently depending on their stability level (since the stability level can vary per signal I guess the following can be done by taking the max stability level).

That's an interesting idea. We should consider how to offer filtered/sorted views when we iterate on how the data is presented, especially if we move away from tables. 👍

We are missing profiling support from the list! This is an experimental signal so maybe can be excluded

Noted!

I think it would be great to have links to https://opentelemetry.io/docs/collector/configuration/#receivers and similar somewhere in these pages

I was thinking these pages will merge with that content to actually become the /receivers, /processors, /exporters, etc. pages in the new IA. So the corresponding content on that monolithic configuration page will be broken out into separate pages, and each page will have the OTel-maintained components listed (right now, in a table). WDYT?

It would also make sense to me to link to https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/component-stability.md somewhere

Noted! I think Patrice had the same idea. 👍

[mx-psi]

I was thinking these pages will merge with that content to actually become the /receivers, /processors, /exporters, etc. pages in the new IA. So the corresponding content on that monolithic configuration page will be broken out into separate pages, and each page will have the OTel-maintained components listed (right now, in a table). WDYT?

Ah, right, yeah, that makes sense

[tiffany76]

Thanks for giving this a look, @chalin!

Have you seen https://opentelemetry.io/status/#collector? The added page content seems to be mostly statuses for components. Might it make sense to put these pages (or at least their status content), under https://opentelemetry.io/status/#collector or a new subsection of https://opentelemetry.io/status/?

Although right now it looks like the new content is mostly adding statuses, the ultimate goal is to bridge the gap between component documentation and the official docs. As we iterate, we will hopefully be able to bring in more of the component metadata than just the stability level. So I don't think we should move this content to the /status page.

Re. the automation: under which repo will the GH actions run (and where will be the associated scripts, if any)?

I think @jaydeluca can answer that better than me.

There is https://opentelemetry.io/docs/collector/distributions/. Is there an overlap with what is being proposed here as content? If so, will it lead to confusion for readers?

No, there shouldn't be much overlap. The current Distributions page will be reworked in the new IA to help users focus on choosing a distribution. But I don't think we'll be going into component-level detail there. The only overlap I see (as of now, that could change, of course) is if we indicate which distributions each component is part of, as recommended by Damien.