Skip to content
This repository has been archived by the owner on May 25, 2022. It is now read-only.

Document relation with the OTel Collector #6

Closed
alexvanboxel opened this issue Jan 29, 2021 · 2 comments
Closed

Document relation with the OTel Collector #6

alexvanboxel opened this issue Jan 29, 2021 · 2 comments

Comments

@alexvanboxel
Copy link
Contributor

The relation to the collector is not clear. It would be helpful how they are related. I have the following questions:

  • I like the otel-collector model because you have one common place to configure your egress to an observability platform. This is a completely separate collector and IIsee that this collector has exporters. Will these exporters be moved to the collector or will they be duplicated (or shared).
  • As far as I'm aware, it doesn't share the same pipeline architecture as the otel-collector. Are there plans to share the same architecture, so that we could at least build the opentelemetry-collector with the exporters?

I assume I will not be the only one with these questions, so it's probably useful to have an otel-collector relationship FAQ. Thanks.

@djaglowski
Copy link
Member

djaglowski commented Jan 29, 2021

These are very reasonable questions. We may end up with an FAQ, but we're expecting to implement some changes to this repository that will likely clear things up quite a bit. For now, I'll try to answer your immediate questions by offering some context.

This issue captures a bit more of the intention behind this repository being part of OpenTelemetry. It's a good place to start if you haven't seen it yet. Note that the focus is on integrating log consumption capabilities directly into the collector. In other words, this codebase will be consumed in a variety of receivers and really only exists temporarily, though it may be a year or more before it can be fully deprecated.

Much of the codebase is not relevant to collector and is currently being reviewed. For instance, the ability to run as a standalone agent will most likely be retained. Additionally, the exporters will likely be removed.

The pipeline architecture used here may end up being useful under the covers of the new log receivers, but this is to be determined as well.

I hope this helps, and we'll try to clarify the intention of the repository more formally once the roadmap is understood a bit better.

@alexvanboxel
Copy link
Contributor Author

Thanks for clarifying. This is the answer I was hoping for.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants