Skip to content

Commit daf96d2

Browse files
committed
Fix linting issues
Signed-off-by: Tiffany Hrabusa <[email protected]>
1 parent d4ee160 commit daf96d2

File tree

4 files changed

+97
-60
lines changed

4 files changed

+97
-60
lines changed

content/en/docs/collector/building/_index.md

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,10 @@ description: Instructions on how to build your own Collector components
44
weight: 90
55
---
66

7-
You can configure the OpenTelemetry Collector with components from the [community](https://opentelemetry.io/docs/collector/components/) and [broader ecosystem](https://opentelemetry.io/ecosystem/registry/), and you can also develop and build on your own custom components. This section describes how to build some of those components. For additional
8-
details, see the documentation in the
7+
You can configure the OpenTelemetry Collector with components from the
8+
[community](https://opentelemetry.io/docs/collector/components/) and
9+
[broader ecosystem](https://opentelemetry.io/ecosystem/registry/), and you can
10+
also develop and build on your own custom components. This section describes how
11+
to build some of those components. For additional details, see the documentation
12+
in the
913
[opentelemetry-collector-contrib repository](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/README.md).

content/en/docs/collector/building/authenticator-extension.md

Lines changed: 46 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -5,18 +5,18 @@ aliases: [/docs/collector/custom-auth/]
55
cSpell:ignore: configauth oidc
66
---
77

8-
The OpenTelemetry Collector allows you to connect receivers and exporters to
9-
authenticators so you can authenticate incoming connections at the
10-
receiver side and add authentication data to outgoing requests at the exporter
11-
side.
8+
The OpenTelemetry Collector allows you to connect receivers and exporters to
9+
authenticators so you can authenticate incoming connections at the receiver side
10+
and add authentication data to outgoing requests at the exporter side.
1211

13-
Authenticators are implemented through [extensions]. This document guides you
14-
on implementing your own authenticators. If you want to learn
15-
how to use an existing authenticator, see the documentation for that specific authenticator. You can find a list of existing
16-
authenticators in the [registry](https://opentelemetry.io/ecosystem/registry/) on this website.
12+
Authenticators are implemented through [extensions]. This document guides you on
13+
implementing your own authenticators. If you want to learn how to use an
14+
existing authenticator, see the documentation for that specific authenticator.
15+
You can find a list of existing authenticators in the
16+
[registry](https://opentelemetry.io/ecosystem/registry/) on this website.
1717

1818
Use this guide for general directions on how to build a custom authenticator and
19-
see the
19+
see the
2020
[API Reference Guide](https://pkg.go.dev/go.opentelemetry.io/collector/config/configauth)
2121
for the actual semantics of each type and function.
2222

@@ -26,16 +26,23 @@ room at the [CNCF Slack workspace](https://slack.cncf.io).
2626

2727
## Architecture
2828

29-
[Authenticators] in OpenTelemetry are just like any other extension, but they also have to implement one or more specific interfaces that define how authentication is performed (for example, authenticating HTTP or gRPC requests). Use [server authenticators][sa]
30-
with receivers to intercept HTTP and gRPC requests. Use client
31-
authenticators with exporters to add authentication data to HTTP
32-
and gRPC requests. Authenticators can also implement both
33-
interfaces at the same time, allowing a single instance of the extension to
34-
handle both incoming and outgoing requests. Users of your authenticator might prefer having
35-
different authenticators for incoming and outgoing requests. Keep the design flexible so users can enable the component only on the server side, or only on the client side, or both if they choose.
29+
[Authenticators] in OpenTelemetry are just like any other extension, but they
30+
also have to implement one or more specific interfaces that define how
31+
authentication is performed (for example, authenticating HTTP or gRPC requests).
32+
Use [server authenticators][sa] with receivers to intercept HTTP and gRPC
33+
requests. Use client authenticators with exporters to add authentication data to
34+
HTTP and gRPC requests. Authenticators can also implement both interfaces at the
35+
same time, allowing a single instance of the extension to handle both incoming
36+
and outgoing requests. Users of your authenticator might prefer having different
37+
authenticators for incoming and outgoing requests. Keep the design flexible so
38+
users can enable the component only on the server side, or only on the client
39+
side, or both if they choose.
3640

3741
Once an authenticator extension is available in a Collector distribution, you
38-
can reference it in the configuration file the same as other extensions. However, an authenticator is effective only when it's referenced by a consuming component. The following configuration shows a receiver named `otlp/auth` using the `oidc` authenticator extension:
42+
can reference it in the configuration file the same as other extensions.
43+
However, an authenticator is effective only when it's referenced by a consuming
44+
component. The following configuration shows a receiver named `otlp/auth` using
45+
the `oidc` authenticator extension:
3946

4047
```yaml
4148
extensions:
@@ -118,23 +125,31 @@ service:
118125

119126
### Server authenticators
120127

121-
A [server authenticator][sa] is an extension with an `Authenticate`
122-
function. This function is called whenever a request comes in, and it checks the request’s headers to authenticate the request. If the authenticator decides the request is valid, it returns a `nil` error. If the request isn’t valid, it returns an error explaining why.
128+
A [server authenticator][sa] is an extension with an `Authenticate` function.
129+
This function is called whenever a request comes in, and it checks the request’s
130+
headers to authenticate the request. If the authenticator decides the request is
131+
valid, it returns a `nil` error. If the request isn’t valid, it returns an error
132+
explaining why.
123133

124-
Because it’s an extension, the authenticator should set up the resources it needs (like keys, clients, or caches) at
134+
Because it’s an extension, the authenticator should set up the resources it
135+
needs (like keys, clients, or caches) at
125136
[`Start`](https://pkg.go.dev/go.opentelemetry.io/collector/component#Component)
126137
and should clean everything up at `Shutdown`.
127138

128-
The `Authenticate` function runs for every incoming request, and the pipeline can’t move forward until
129-
this function finishes. Because of that, your authenticator must avoid slow or unnecessary blocking work. If the `context` sets a deadline, make sure your code follows it so the pipeline isn't delayed or left hanging.
139+
The `Authenticate` function runs for every incoming request, and the pipeline
140+
can’t move forward until this function finishes. Because of that, your
141+
authenticator must avoid slow or unnecessary blocking work. If the `context`
142+
sets a deadline, make sure your code follows it so the pipeline isn't delayed or
143+
left hanging.
130144

131-
You should also add good observability to your authenticator, especially metrics and traces. This helps users set up alerts if errors start increasing and makes it easier for them to troubleshoot authentication problems.
145+
You should also add good observability to your authenticator, especially metrics
146+
and traces. This helps users set up alerts if errors start increasing and makes
147+
it easier for them to troubleshoot authentication problems.
132148

133149
### Client authenticators
134150

135-
136-
[Client authenticators] are
137-
extensions with extra functions that implement one or more of the defined interfaces. Each authenticator receives an object that
151+
[Client authenticators] are extensions with extra functions that implement one
152+
or more of the defined interfaces. Each authenticator receives an object that
138153
allows it to inject authentication data. For instance, the HTTP client
139154
authenticator provides an
140155
[`http.RoundTripper`](https://pkg.go.dev/net/http#RoundTripper), while the gRPC
@@ -145,10 +160,11 @@ client authenticator can produce a
145160

146161
Custom authenticators must be part of the same binary as the Collector itself.
147162
When building your own authenticator, you have two options:
148-
- You can build a custom Collector
149-
distribution using
150-
the [OpenTelemetry Collector Builder][builder]
151-
- You can provide a way, such as publishing a Go module, for users to add your extension to their own distributions.
163+
164+
- You can build a custom Collector distribution using the [OpenTelemetry
165+
Collector Builder][builder]
166+
- You can provide a way, such as publishing a Go module, for users to add your
167+
extension to their own distributions.
152168

153169
[authenticators]:
154170
https://pkg.go.dev/go.opentelemetry.io/collector/config/configauth

content/en/docs/collector/building/receiver.md

Lines changed: 37 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -8,22 +8,29 @@ cSpell:ignore: backendsystem crand debugexporter mapstructure pcommon pdata ptra
88

99
<!-- markdownlint-disable heading-increment no-duplicate-heading -->
1010

11-
12-
OpenTelemetry defines [distributed tracing](/docs/concetps/glossary/#distribution) as:
13-
14-
> Traces that track the progression of a single request, known as a trace, as it is
15-
> handled by services that make up an application. The request may be initiated
16-
> by a user or an application. Distributed tracing is a form of tracing
17-
> that traverses process, network, and security boundaries.
18-
19-
Although distributed traces are defined in an application-centric way, you can think of them as a timeline for _any_ request that moves through your system. Each distributed trace shows how long a request took from start to finish and breaks down the steps taken to complete it.
20-
21-
If your system generates tracing telemetry, you can configure your [OpenTelemetry Collector](/docs/collector/) with a trace receiver designed to receive and convert that telemetry. The receiver converts your data from its original format into the OpenTelemetry trace model so the Collector can process it.
11+
OpenTelemetry defines
12+
[distributed tracing](/docs/concepts/glossary/#distributed-tracing) as:
13+
14+
> Traces that track the progression of a single request, known as a trace, as it
15+
> is handled by services that make up an application. The request may be
16+
> initiated by a user or an application. Distributed tracing is a form of
17+
> tracing that traverses process, network, and security boundaries.
18+
19+
Although distributed traces are defined in an application-centric way, you can
20+
think of them as a timeline for _any_ request that moves through your system.
21+
Each distributed trace shows how long a request took from start to finish and
22+
breaks down the steps taken to complete it.
23+
24+
If your system generates tracing telemetry, you can configure your
25+
[OpenTelemetry Collector](/docs/collector/) with a trace receiver designed to
26+
receive and convert that telemetry. The receiver converts your data from its
27+
original format into the OpenTelemetry trace model so the Collector can process
28+
it.
2229

2330
To implement a trace receiver, you need the following:
2431

25-
- A `Config` implementation so the trace receiver can gather and validate
26-
its configurations in the Collector config.yaml.
32+
- A `Config` implementation so the trace receiver can gather and validate its
33+
configurations in the Collector config.yaml.
2734

2835
- A `receiver.Factory` implementation so the Collector can properly instantiate
2936
the trace receiver component.
@@ -733,8 +740,9 @@ func (tailtracerRcvr *tailtracerReceiver) Shutdown(ctx context.Context) error {
733740

734741
{{% alert title="Check your work" %}}
735742

736-
Updated the `Start()` method by adding the initialization to the `host` field with the
737-
`component.Host` reference passed by the Collector.
743+
Updated the `Start()` method by adding the initialization to the `host` field
744+
with the `component.Host` reference passed by the Collector.
745+
738746
- Set the `cancel` function field with the cancellation based on a new context
739747
created with `context.Background()` (according to the Collector API
740748
documentation suggestions).
@@ -830,9 +838,9 @@ func (tailtracerRcvr *tailtracerReceiver) Shutdown(ctx context.Context) error {
830838
Collector pipeline.
831839
- Added a `Config` field named `config` so we can have access to receiver's
832840
configuration settings defined in the Collector config.
833-
- Added a variable named `interval` that is initialized as a `time.Duration` based on
834-
the value of the `interval` settings of the `tailtracer` receiver, defined in
835-
the Collector config.
841+
- Added a variable named `interval` that is initialized as a `time.Duration`
842+
based on the value of the `interval` settings of the `tailtracer` receiver,
843+
defined in the Collector config.
836844
- Added a `go func()` to implement the `ticker` mechanism so the receiver can
837845
generate traces every time the `ticker` reaches the amount of time specified
838846
by the `interval` variable.
@@ -1210,9 +1218,9 @@ type BackendSystem struct{
12101218
}
12111219
```
12121220

1213-
These types are meant to represent the entities as they appear in the
1214-
system being observed. They contain information that would be quite meaningful to add to
1215-
the traces as part of the `Resource` definition. You will add some helper
1221+
These types are meant to represent the entities as they appear in the system
1222+
being observed. They contain information that would be quite meaningful to add
1223+
to the traces as part of the `Resource` definition. You will add some helper
12161224
functions to generate the instances of these types.
12171225

12181226
Here is what the `model.go` file will look like with the added helper functions:
@@ -1469,8 +1477,8 @@ func fillResourceWithAtm(resource *pcommon.Resource, atm Atm){
14691477
`pcommon.Map` reference returned by the `resource.Attributes()` call.
14701478
- Used the `PutInt()` and `PutStr()` methods from `pcommon.Map` to add int and
14711479
string attributes based on the equivalent `Atm` field types. Notice that
1472-
because these attributes are specific to and only represent the `Atm`
1473-
entity, they are all grouped within the `atm.` prefix.
1480+
because these attributes are specific to and only represent the `Atm` entity,
1481+
they are all grouped within the `atm.` prefix.
14741482

14751483
{{% /alert %}}
14761484

@@ -1725,7 +1733,8 @@ instrumented either manually or automatically via an instrumentation library.
17251733

17261734
The instrumentation libraries are responsible for setting the scope (also known
17271735
as the instrumentation scope), within which the operations participating in a
1728-
trace occur, and describing these operations as spans in the context of the trace.
1736+
trace occur, and describing these operations as spans in the context of the
1737+
trace.
17291738

17301739
`pdata.ResourceSpans` has a method named `ScopeSpans()` which returns an
17311740
instance of a helper type called `ptrace.ScopeSpansSlice`. The
@@ -1828,8 +1837,8 @@ and describe as part of the trace.
18281837
- `SetTraceID(v pcommon.TraceID)` sets the `pcommon.TraceID` uniquely
18291838
identifying the trace that this span is associated with.
18301839

1831-
- `SetSpanID(v pcommon.SpanID)` sets the `pcommon.SpanID` uniquely
1832-
identifying this span in the context of the trace it is associated with.
1840+
- `SetSpanID(v pcommon.SpanID)` sets the `pcommon.SpanID` uniquely identifying
1841+
this span in the context of the trace it is associated with.
18331842

18341843
- `SetParentSpanID(v pcommon.SpanID)` sets `pcommon.SpanID` for the parent
18351844
span/operation in case the operation represented by this span is executed as
@@ -1990,8 +1999,8 @@ func generateTraces(numberOfTraces int) ptrace.Traces {
19901999
```
19912000

19922001
You now have the `BackendSystem` entity and its operations represented in spans
1993-
in a proper trace context! Next, you need to push the generated trace through the
1994-
pipeline so that the next consumer, either a processor or an exporter, can
2002+
in a proper trace context! Next, you need to push the generated trace through
2003+
the pipeline so that the next consumer, either a processor or an exporter, can
19952004
receive and process it.
19962005

19972006
Here is how the `tailtracer/model.go` file looks:

static/refcache.json

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17019,6 +17019,14 @@
1701917019
"StatusCode": 200,
1702017020
"LastSeen": "2025-12-05T09:47:06.305892751Z"
1702117021
},
17022+
"https://opentelemetry.io/docs/collector/components/": {
17023+
"StatusCode": 206,
17024+
"LastSeen": "2025-12-08T17:54:33.554293-08:00"
17025+
},
17026+
"https://opentelemetry.io/ecosystem/registry/": {
17027+
"StatusCode": 206,
17028+
"LastSeen": "2025-12-08T17:54:17.490961-08:00"
17029+
},
1702217030
"https://opentracing.io": {
1702317031
"StatusCode": 206,
1702417032
"LastSeen": "2025-12-01T09:45:41.840037425Z"

0 commit comments

Comments
 (0)