Collector Instancing Example

collector-instances.md

receivers:
  otlp/in:
processors:
  batch:
exporters:
  otlp/out:

service:
  pipelines:
    logs/1:
      receivers: [ otlp/in ]
      processors: [ batch ]
      exporters: [ otlp/out ]
    logs/2:
      receivers: [ otlp/in ]
      processors: [ batch ]
      exporters: [ otlp/out ]
    traces/1:
      receivers: [ otlp/in ]
      processors: [ batch ]
      exporters: [ otlp/out ]

1. How many Component Instances are instantiated for the above configuration?

There are 6 Component Instances:

• 1 instance of otlp/in
• 3 instances of batch
• 2 instances of otlp/out

Why?

• Processors are instanced per pipeline, so each of the three pipelines gets a dedicated copy of the batch processor.
• Exporters are instanced per data type, so there is one instance for logs (shared by the two logs pipelines) and one instance for traces.
• Receivers are also instanced per data type but the otlp receiver uses a workaround called sharedcomponent which effectively makes this a singleton instance shared by all three pipelines.

2. For each instance, what is an appropriate set of attributes that allows a user to understand that a given piece of telemetry originated from that instance?

A reasonable set of attributes for each instance might look like this:

- class: receiver
  component.id: otlp/in
- class: processor
  component.id: batch
  pipeline.id: logs/1
- class: processor
  component.id: batch
  pipeline.id: logs/2
- class: processor
  component.id: batch
  pipeline.id: traces/1
- class: exporter
  component.id: otlp/out
  data.type: logs
- class: exporter
  component.id: otlp/out
  data.type: traces