weixin_40003478
weixin_40003478
2020-12-01 11:17

exporter/zipkin: allow NewExporter to set remote endpoint

Currently the zipkin exporter was implemented with only the ability to create a localEndpoint in the call https://godoc.org/go.opencensus.io/exporter/zipkin#NewExporter

https://github.com/census-instrumentation/opencensus-go/blob/96e75b88df843315da521168a0e3b11792088728/exporter/zipkin/zipkin.go#L34-L50

We need the ability to add a remote endpoint if need be. That is because RemoteEndpoint https://github.com/openzipkin/zipkin-go/blob/70244c9703277c13566aac289c530a1143b14cf5/model/span.go#L39-L40 is essential when creating the service graph of elements by Zipkin later.

I am currently wrapping up the Zipkin interceptor for the OpenCensus Agent/Service in https://github.com/census-instrumentation/opencensus-service/pull/111 and the only thing lacking here is the ability to create an OpenCensus exporter that also adds the endpoint.

Since the exporter seems to have suggested optionality of the RemoteEndpoint, perhaps let's add an option WithRemoteEndpoint and with that always transmit one when uploading Zipkin spans to a backend.

该提问来源于开源项目:census-instrumentation/opencensus-go

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_40003478 weixin_40003478 5月前

    While each SpanData could have a unique RemoteEndpoint and LocalEndpoint, this exporter's constructor seems to be usable by only one LocalEndpoint which also alludes to just using one RemoteEndpoint for parity.

    A patching fix would be to interpret fields in the Attributes map e.g. "zipkin.remoteEndpoint.serviceName" or "zipkin.localEndpoint.serviceName" but that ship sailed when we made the signature for NewExporter take a LocalEndpoint hence for each unique localEndpoint-remoteEndpoint consumer we have to initiate a new exporter.

    点赞 评论 复制链接分享
  • weixin_39668408 weixin_39668408 5月前

    It is much more common to have a sticky local endpoint (as you are describing your own service) even though Zipkin allows per span local endpoint (as you may be a proxying service or a multi homed service). It is very uncommon for a remote endpoint to be sticky on the service level (service A always calling the same peer service B does not make a lot of sense in most cases).

    So what would make sense is for adding an option to allow inspection of the span attributes to pick up the remote endpoint tags and convert them back into remote endpoint (span level). Unfortunately this comes at a cost. I added an issue report some time ago, stating the desire for making endpoints a first class citizen in OpenCensus: https://github.com/census-instrumentation/opencensus-specs/issues/135

    The later would be more efficient and I think beneficial to the OC data model.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    -em can this be closed given 's update? I agree with that it probably doesn't make sense to set this globally on an exporter.

    点赞 评论 复制链接分享
  • weixin_40003478 weixin_40003478 5月前

    I guess so, but as is currently we won't be able to use the OpenCensus-Go Zipkin exporter so for the OpenCensus-Service thus we've reimplemented it as per https://github.com/census-instrumentation/opencensus-service/pull/145 to allow for per-span {LocalEndpoint, RemoteEndpoint} extraction and using a single exporter, and one day will eventually have to redesign the OpenCensus-Go Zipkin exporter and then bring that code here, over from the OpenCensus-Service.

    点赞 评论 复制链接分享
  • weixin_39928106 weixin_39928106 5月前

    Let's discuss a general solution on the specs repo.

    点赞 评论 复制链接分享

相关推荐