Package Usage: go: go.opentelemetry.io/collector/client
Package client contains generic representations of clients connecting to
different receivers. Components, such as processors or exporters, can make
use of this information to make decisions related to grouping of batches,
tenancy, load balancing, tagging, among others.
The structs defined here are typically used within the context that is
propagated down the pipeline, with the values being produced by
authenticators and/or receivers, and consumed by processors and exporters.
Receivers are responsible for obtaining a client.Info from the current
context and enhancing the client.Info with the net.Addr from the peer,
storing a new client.Info into the context that it passes down. For HTTP
requests, the net.Addr is typically the IP address of the client.
Typically, however, receivers would delegate this processing to helpers such
as the confighttp or configgrpc packages: both contain interceptors that will
enhance the context with the client.Info, such that no actions are needed by
receivers that are built using confighttp.HTTPServerSettings or
configgrpc.GRPCServerSettings.
Authenticators are responsible for obtaining a client.Info from the current
context, enhancing the client.Info with an implementation of client.AuthData,
and storing a new client.Info into the context that it passes down. The
attribute names should be documented with their return types and considered
part of the public API for the authenticator.
Provided that the pipeline does not contain processors that would discard or
rewrite the context, such as the batch processor, processors and exporters
have access to the client.Info via client.FromContext. Among other usages,
this data can be used to:
- annotate data points with authentication data (username, tenant, ...)
- route data points based on authentication data
- rate limit client calls based on IP addresses
Processors and exporters relying on the existence of data from the
client.Info, especially client.AuthData, should clearly document this as part
of the component's README file. The expected pattern for consuming data is to
allow users to specify the attribute name to use in the component. The
expected data type should also be communicated to users, who should then
compare this with the authenticators that are part of the pipeline. For
example, assuming that the OIDC authenticator pushes a "subject" string
attribute and that we have a hypothetical "authprinter" processor that prints
the "username" to the console, this is how an OpenTelemetry Collector
configuration would look like:
0 versions
Latest release: 7 months ago
View more package details: https://packages.ecosystem.code.gouv.fr/registries/proxy.golang.org/packages/go.opentelemetry.io/collector/client