From e09a8bfc8bdd5b22990ad0c3f7f3d77c39d8a37a Mon Sep 17 00:00:00 2001 From: Tiffany Hrabusa <30397949+tiffany76@users.noreply.github.com> Date: Wed, 21 Feb 2024 10:47:20 -0800 Subject: [PATCH] Apply suggestions from initial review Co-authored-by: Severin Neumann --- content/en/docs/collector/architecture.md | 34 +++++++++++++---------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/content/en/docs/collector/architecture.md b/content/en/docs/collector/architecture.md index b4bfce9b50e5..5a5ac13d5311 100644 --- a/content/en/docs/collector/architecture.md +++ b/content/en/docs/collector/architecture.md @@ -2,7 +2,7 @@ title: Architecture weight: 28 # prettier-ignore -cSpell:ignore: # TODO: Add keywords to ignore. +cSpell:ignore: fanoutconsumer probabilisticsampler spanmetrics zpages --- OpenTelemetry Collector is an executable that can receive telemetry data, @@ -70,12 +70,12 @@ A pipeline configuration typically looks like this: service: pipelines: # section that can contain multiple subsections, one per pipeline traces: # type of the pipeline - receivers: [otlp, jaeger, zipkin] + receivers: [otlp, zipkin] processors: [memory_limiter, batch] - exporters: [otlp, jaeger, zipkin] + exporters: [otlp, zipkin] ``` -The above example defines a pipeline for the “traces” type of telemetry data, +The above example defines a pipeline for the traces type of telemetry data, with three receivers, two processors, and three exporters. For details of config file format see @@ -105,7 +105,7 @@ service: traces/2: # another pipeline of “traces” type receivers: [otlp] processors: [batch] - exporters: [opencensus] + exporters: [otlp] ``` In the above example, `otlp` receiver will send the same data to pipeline @@ -118,19 +118,25 @@ When the Collector loads this config, the result will look like this diagram -> Important: When the same receiver is referenced in more than one pipeline, the -> Collector creates only one receiver instance at runtime that sends the data to -> a fan out consumer. The fan out consumer in turn sends the data to the first -> processor of each pipeline. The data propagation from receiver to the fan out -> consumer and then to processors is completed using a synchronous function -> call. This means that if one processor blocks the call, the other pipelines -> attached to this receiver are blocked from receiving the same data, and the -> receiver itself stops processing and forwarding newly received data. + +{{% alert title="Important" color="warning" %}} + +When the same receiver is referenced in more than one pipeline, the +Collector creates only one receiver instance at runtime that sends the data to +a fan out consumer. The fan out consumer in turn sends the data to the first +processor of each pipeline. The data propagation from receiver to the fan out +consumer and then to processors is completed using a synchronous function +call. This means that if one processor blocks the call, the other pipelines +attached to this receiver are blocked from receiving the same data, and the +receiver itself stops processing and forwarding newly received data. + +{{% /alert %}} + ### Exporters Exporters typically forward the data they get to a destination on a network, but -they can also send the data elsewhere. For example, `logging` exporter writes +they can also send the data elsewhere. For example, `debug` exporter writes the telemetry data to the logging destination. The configuration allows for multiple exporters of the same type, even in the