#Sending Telemetry Data to the Collector

The OpenTelemetry Collector serves as a central telemetry processing hub that receives, processes, and exports traces, logs, and metrics generated by your applications. Properly configuring how applications send telemetry data to the Collector is essential for building an effective observability pipeline.

Depending on your deployment architecture and requirements, there are two primary approaches for sending telemetry data to the Collector:

#Deployment Approaches

#Sidecar Injection Mode

In the sidecar mode, the OpenTelemetry Collector is automatically injected as a sidecar container into your application pods. This approach offers several advantages:

• Automated deployment - No manual configuration required for each application
• Pod-level isolation - Each application pod has its own dedicated Collector instance
• Simplified networking - Applications communicate with the Collector via localhost
• Resource isolation - Collector resources are allocated per pod
• Ideal for - Scenarios requiring pod-level data isolation or when applications expect localhost endpoints

#Standalone Deployment Mode

In this mode, applications connect directly to an independently deployed Collector service. Key characteristics include:

• Centralized management - Single Collector configuration for multiple applications
• Resource efficiency - Shared Collector instances reduce overall resource consumption
• Scalability - Easier to scale Collector independently from applications
• Network flexibility - Applications can send data across namespaces
• Ideal for - Large-scale cluster deployments and centralized observability architectures

#Choosing the Right Approach

Consider the sidecar mode when:

• Applications require strict pod-level data isolation
• You need to collect logs from application containers
• Applications are configured to send telemetry to localhost
• Each application has unique Collector configuration requirements

Consider the standalone mode when:

• Managing a large number of applications
• Resource efficiency is a priority
• You want centralized Collector configuration and monitoring
• Applications can tolerate shared Collector infrastructure