You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this is a vendor-specific component, I am a member of the OpenTelemetry organization.
If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.
Code Owner(s)
EOjeah
Sponsor (optional)
No response
Additional context
Currently, the OpenTelemetry Collector supports receiving Zipkin traces over HTTP. However, some environments with very high throughput use case can benefit from the lower overhead and simplicity of UDP.
Due to nature of UDP as inherently unreliable, packets may be lost but the risk is mitigated by the nature of tracing data, where occasional loss of spans is generally acceptable.
The text was updated successfully, but these errors were encountered:
Is there any reason it shouldn't be proposed to add UDP functionality to the existing Zipkin receiver instead of creating a separate component? Other receivers like OTLP combine multiple input methods in one component like HTTP/gRPC
Is there any reason it shouldn't be proposed to add UDP functionality to the existing Zipkin receiver instead of creating a separate component? Other receivers like OTLP combine multiple input methods in one component like HTTP/gRPC
@jackgopack4 good point, i'm not sure why i didn't do that first but created it now at #35620
The purpose and use-cases of the new component
This component will enable the Collector to receive traces in the form of Zipkin v2 JSON spans over UDP.
Example configuration for the component
Telemetry data types supported
traces
Is this a vendor-specific component?
Code Owner(s)
EOjeah
Sponsor (optional)
No response
Additional context
Currently, the OpenTelemetry Collector supports receiving Zipkin traces over HTTP. However, some environments with very high throughput use case can benefit from the lower overhead and simplicity of UDP.
Due to nature of UDP as inherently unreliable, packets may be lost but the risk is mitigated by the nature of tracing data, where occasional loss of spans is generally acceptable.
The text was updated successfully, but these errors were encountered: