Skip to content
This repository has been archived by the owner on Oct 3, 2023. It is now read-only.

FR: Trace and Tag propagation convenience for message-based systems #265

Open
deanberris opened this issue May 25, 2019 · 1 comment
Open

Comments

@deanberris
Copy link

In census-instrumentation/opencensus-java#1013 there's an implementation of convenience functions and types for imbuing/reconstituting tags and trace information in messages meant to be processed asynchronously. As more "serverless" or "event-driven" architectures start relying on non-RPC mechanisms for triggering work, it makes a lot of sense to be able to consistently do this across the programming languages.

If we can make it so that we support more types of messages than those used in traditional message bus/broker mediated systems, then that would be better. There's #228 for Kafka messages, but the problem and design space is more general. This applies to some more message types:

  • JavaScript/Web Service Workers
  • WebRTC
  • SMTP/Email
  • Pub/Sub or Message Bus systems (Kafka, Google Pub/Sub, RabbitMQ, etc.)
  • WebSocket messages
  • DBus messages
  • HTTP messages

This may make it necessary to ensure all language implementations have a consistent way of marshalling/un-marshalling messages that are encoded in whatever message format. Java seems to already have an implementation for supporting Google Cloud Pub/Sub messages, it might make sense to start there and expand to other message bus implementations.

Ideally, the client libraries themselves would support adding hooks allowing the OpenCensus tag/trace propagation mechanics to kick in, but that's more invasive than providing users some convenience functions for marshalling/un-marshalling messages that may contain OpenCensus tag/trace information.

For my current needs, implementations at least in Python and Go would be hugely beneficial.

@mtwo
Copy link
Contributor

mtwo commented May 26, 2019

@c24t @dinooliva @SergeyKanzhelev @bogdandrutu FYI

For HTTP we have the W3C spec, but you're correct that in other formats things are less clear. For example, @SergeyKanzhelev is looking into formats for MQTT, AMQP on behalf of the W3C group.

@dinooliva, can you add the details of the PubSub context propagation format into the specs repo somewhere?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants