☰
Navigation :

zipkin.proto

Package: solo.io.envoy.config.trace.v3

Types:

Source File: github.com/solo-io/gloo/projects/gloo/api/external/envoy/config/trace/v3/zipkin.proto

ZipkinConfig

Configuration for the Zipkin tracer. [#extension: envoy.tracers.zipkin] [#next-free-field: 6]

"collectorUpstreamRef": .core.solo.io.ResourceRef
"clusterName": string
"collectorEndpoint": string
"traceId128Bit": .google.protobuf.BoolValue
"sharedSpanContext": .google.protobuf.BoolValue
"collectorEndpointVersion": .solo.io.envoy.config.trace.v3.ZipkinConfig.CollectorEndpointVersion
Field Type Description
collectorUpstreamRef .core.solo.io.ResourceRef The upstream that hosts the Zipkin collectors. Only one of collectorUpstreamRef or clusterName can be set.
clusterName string The name of the cluster that hosts the Zipkin collectors. Note that the Zipkin cluster must be defined in the :ref:Bootstrap static cluster resources <envoy_api_field_config.bootstrap.v3.Bootstrap.StaticResources.clusters>. Only one of clusterName or collectorUpstreamRef can be set.
collectorEndpoint string The API endpoint of the Zipkin service where the spans will be sent. When using a standard Zipkin installation, the API endpoint is typically /api/v1/spans, which is the default value.
traceId128Bit .google.protobuf.BoolValue Determines whether a 128bit trace id will be used when creating a new trace instance. The default value is false, which will result in a 64 bit trace id being used.
sharedSpanContext .google.protobuf.BoolValue Determines whether client and server spans will share the same span context. The default value is true.
collectorEndpointVersion .solo.io.envoy.config.trace.v3.ZipkinConfig.CollectorEndpointVersion Determines the selected collector endpoint version. By default, the HTTP_JSON_V1 will be used.

CollectorEndpointVersion

Available Zipkin collector endpoint versions.

Name Description
DEPRECATED_AND_UNAVAILABLE_DO_NOT_USE Zipkin API v1, JSON over HTTP. [#comment: The default implementation of Zipkin client before this field is added was only v1 and the way user configure this was by not explicitly specifying the version. Consequently, before this is added, the corresponding Zipkin collector expected to receive v1 payload. Hence the motivation of adding HTTP_JSON_V1 as the default is to avoid a breaking change when user upgrading Envoy with this change. Furthermore, we also immediately deprecate this field, since in Zipkin realm this v1 version is considered to be not preferable anymore.]
HTTP_JSON Zipkin API v2, JSON over HTTP.
HTTP_PROTO Zipkin API v2, protobuf over HTTP.