-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation improvements - Comments in key functions #10029
Changes from 8 commits
0ba94e8
72229e7
ef29e28
cb3da5f
7756590
e0b2443
9d1deee
7dea12c
96290b0
f0aa463
393139a
a815f53
b2f7060
31f2bdf
996ef1b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
### What is where | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
There are a few resources available to understand how the collector works: | ||
Firstly, there is a [diagram](startup.md) documenting the startup flow of the collector. | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Second, the OpenTelemetry Collector's [architecture docs](https://opentelemetry.io/docs/collector/architecture/) are | ||
pretty useful. | ||
Finally, here is a brief list of useful and/or important files that you may find valuable to glance through. | ||
#### [collector.go](../otelcol/collector.go) | ||
This file contains the main Collector struct and its constructor `NewCollector`. | ||
|
||
`Collector.Run` starts the collector and sets up its lifecycle management loop. | ||
mx-psi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
`setupConfigurationComponents` is the "main" function responsible for startup - it orchestrates the loading of the | ||
configuration, the creation of the graph, and the starting of all the components. | ||
|
||
#### [graph.go](../service/internal/graph/graph.go) | ||
This file contains the internal graph representation of the pipelines. | ||
|
||
`Build` is the constructor for a Graph object. The method calls out to helpers that transform the graph from a config | ||
to a DAG of components. The configuration undergoes additional validation here as well, and is used to instantiate | ||
the components of the pipeline. | ||
|
||
`Graph.StartAll` starts every component in the pipelines. | ||
|
||
`Graph.ShutdownAll` stops each component in the pipelines | ||
mx-psi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### [component.go](../component/component.go) | ||
component.go outlines the abstraction of components within OTEL collector. It provides details on the component | ||
lifecycle as well as defining the interface that components must fulfil. | ||
mx-psi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
#### Factories | ||
Each component type contains a Factory interface along with its corresponding NewFactory function. | ||
Implementations of new components use this NewFactory function in their implementation to register key functions with | ||
the collector. For example, the collector uses this interface to give receivers a handle to a nextConsumer - | ||
representing where the receiver can send data to that it has received. | ||
|
||
[//]: # (todo rewrite this factories block it is not as clear as id like) |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
todo: build out config parts (getconfmap). document how settings and config get rendered | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
```mermaid | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am wondering if we should omit the private API bits or make them a bit more ambiguous (just describing what they do instead of giving them explicit names). I think that would be easier to maintain. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I definitely think we need to still include them in some form. I totally agree with your concerns about maintainability - but these top level private API bits are very important for how the program actually works. Without the names the diagram can't serve as a guide to reading the source code at all - I guess its the difference between documentation designed for a user of the Collector API and someone who wants to start contributing. |
||
flowchart TD | ||
A("`**command.NewCommand**`") -->|1| B("`**UpdateSettingsUsingFlags**`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
A --> |2| C("`**NewCollector** | ||
Creates and returns a new instance of Collector`") | ||
A --> |3| D("`**Collector.Run** | ||
Starts the collector and waits for its completion. Also includes the control logic for config reloading and shutdown`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
D --> E("`**SetupConfigurationComponents**`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
E --> |1| F("`**getConfMap**`") | ||
E ---> |2| G("`**Service.New** | ||
Initializes telemetry and logging, then initializes the pipelines`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
E --> |3| Q("`**Service.Start** | ||
1. Start all extensions. | ||
2. Notify extensions about Collector configuration | ||
3. Start all pipelines. | ||
4. Notify extensions that the pipeline is ready. | ||
`") | ||
Q --> R("`**Graph.StartAll** | ||
calls Start on each component in reverse topological order`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
G --> H("`**initExtensionsAndPipeline** | ||
Creates extensions and then builds the pipeline graph`") | ||
H --> I("`**Graph.Build** | ||
Converts the settings to an internal graph representation`") | ||
I --> J("`**createNodes** | ||
Builds the node objects from pipeline configuration and adds to graph. Also validates connectors`") | ||
I --> K("`**createEdges** | ||
Iterates through the pipelines and creates edges between components`") | ||
I --> L("`**buildComponents** | ||
topological sort the graph, and create each component in reverse order`") | ||
ankitpatel96 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
L --> M(Receiver Factory) & N(Processor Factory) & O(Exporter Factory) | ||
``` |
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.
I would move this to the
otelcol
folder as its README.md page. We have other examples of internal documentation being written in this way. This doc talks about files in several components, but I feel like since the entrypoint is inotelcol
that's the best place to put itThere 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.
What are the other examples of docs like this? I saw confmap had an excellent README - are there others?
I also don't know if I agree with moving it to the otelcol/ directory - I think we should keep this as a separate file that we link to to from CONTRIBUTING.md. Some of the open source projects that I've taken some inspiration from in this section are Redis and sqllite - both of which are known as well documented code bases. Those two projects have a similar section in their main README - I'm not sure if we would want to do that but I do think it should be more prominently located.
I would also love some input as to what other files you think fit into this theme - I'm pretty sure this isnt a great list and I'd love to add a few more sections (or someone could of course contribute those sections)
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.
I guess we should continue discussing over at #10068, but I will reply here to this comment just so that the convo is in one place.
Some other README examples:
I am fine with
internal-architecture.md
, let's go with that! We used to havearchitecture.md
for https://opentelemetry.io/docs/collector/architecture/, this one can be developer-focused and have implementation details.I think your list is a good start when it comes to the general structure of the Collector.