Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Justin Foote
    @justinfoote
    I don't believe there is a requirement that you remove duplicate entries from tracestate.
    Tristan Sloughter
    @tsloughter
    pretty sure you fail if there re any duplicates is how I read the spec
    err wait
    now I see that it keeps the last value
    congo=congosFirstPosition,rojo=rojosFirstPosition,congo=congosSecondPosition becomes congo=congosSecondPosition,rojo=rojosFirstPosition
    Sergey Kanzhelev
    @SergeyKanzhelev
    This sounds wrong
    Tristan Sloughter
    @tsloughter
    I don't think theinterop tests are right then
    ah
    definitely not what my impl does and it passes the interop tests, so yea, one of them is wrong :)
    to be clear, where I got that example that doesn't match the interop tests is https://w3c.github.io/trace-context/#combined-header-value
    Sergey Kanzhelev
    @SergeyKanzhelev
    File a bug?
    Assumption was always that newest (first) is the most important
    Justin Foote
    @justinfoote
    That section of the spec dictates how your tracer should handle its own entry
    I don't think it's intended to require you to deduplicate other vendor's entries
    And, in my opinion, it should be up to the vendor to decide which entry to accept if there are multiple entries in tracestate.
    Tristan Sloughter
    @tsloughter
    it calls it the newest, but that the newest is at the end
    I'll have to check, it is on my other machine but pretty sure the interop tests verify that you throw out the tracestate if it has duplicates
    Tristan Sloughter
    @tsloughter
    but yea, I'll file an issue today
    Abdelilah Zaoui
    @AbdelilahZaoui_twitter
    Salamandres
    wdengw
    @wdengw
    Hi, https://w3c.github.io/trace-context/ has tracestate header and https://w3c.github.io/trace-context/ has tracestate header.
    What is the relationship between the two? Both can add key-value pairs. How to decide, given a key-value, where to add it, tracestate, or Correlation-Context?
    Sergey Kanzhelev
    @SergeyKanzhelev
    @wdengw tracestate is for short values, typically identifiers, that enables correlation. Longer value likely will be kicked out of it. Typically used by telemetry vendors. Correlation-Context is a baggage of user-defined values with longer values.
    wdengw
    @wdengw
    @SergeyKanzhelev What do we mean by "kicked out of it", are there guidelines or enforcement rules to govern that? tracestate is typically used by telemetry vendors. What is a telemetry vendor? does the platform organization inside a company, who provide tracing libraries implementing the Open telemetry API, for other internal teams to use, a vendor?
    Daniel Dyla
    @dyladan
    @wdengw tracestate is used to propagate proprietary tracing data used in conjunction with traceparent by whatever vendor provides your tracing and your application will likely not need to access it. correlation context is a more general data store which can be used by the application to propagate values for e.g. A/B testing, fault injection, or other use cases
    What Sergey meant by “kicked out” is that values in the tracestate header may be dropped if the header becomes too large. The limits and mechanics of this are described in 3.3.1.5 here https://w3c.github.io/trace-context/#tracestate-limits
    Daniel Dyla
    @dyladan
    in this case the “vendor” is whatever library handles the traceparent header and is used to forward vendor-specific tracing data. For instance a vendor may have their own sampling info that they want to forward and ignore the trace flags
    Evgeny Yakimov
    @eyjohn
    cross posting from OpenTracing: Are there any implementations of Tracers with w3c trace context compliance, either for c++ or python?
    Yuri Shkuro
    @yurishkuro
    OpenTelemetry SDKs default to W3C Trace Context
    Tyler Yahn
    @MrAlias
    There is an open issue in the Open Telemetry Go implementation to refactor the trace-context (traceparent, tracestate, and propagators) implementation into its own repository (https://github.com/open-telemetry/opentelemetry-go/issues/391).
    The open question is where that repository should live.
    It is posed in the issue that it could live in the W3C org or possibly remain in the Open Telemetry Org.
    Is there any preference here about where implementations like this should live?
    Kai Hudalla
    @sophokles73
    Hi there, I am involved in the Eclipse Hono project where we are making use of Open Tracing to trace processing of messages across multiple service components. The messages usually originate from IoT devices using arbitrary communication protocols. We are currently supporting HTTP, AMQP 1.0, MQTT and CoAP. I have seen the Trace Context Protocols Registry and now I am wondering, what I would need to do to get a CoAP binding being added to the registry?
    Yuri Shkuro
    @yurishkuro
    @sophokles73 I would start with creating a ticket in https://github.com/w3c/trace-context to see if there is interest from other parties. It would be also helpful to provide the initial proposal of what it would look like in CoAP.
    Kai Hudalla
    @sophokles73
    @yurishkuro ok, will do ...
    Andrew Arnott
    @AArnott
    Nathan Fischer and I want to start a working group to define how tracecontext will propagate across JSON-RPC. Any recommendations to get started? We have an idea of what the protocol extension will look like, but need to know how to submit a w3c doc and changes to the trace context protocol registry to link to our w3c draft.
    Daniel Dyla
    @dyladan
    @AArnott I suggest you join the working group's remote workshop this week. We are meeing tuesday, wednesday, and thursday from 12pm - 3pm PDT / 3pm - 6pm EDT
    Yuri Shkuro
    @yurishkuro
    @AArnott how is "JSON-RPC" different from plain HTTP? Do you mean a custom protocol that does not support the notion of "headers"?
    Andrew Arnott
    @AArnott
    @yurishkuro JSON-RPC doesn't define headers at all. It's pure JSON. So we need a way to carry the tracecontext data as a JSON property.
    Thanks, @dyladan. I've added my name to the doc. Should I add JSON-RPC as a topic as well? Given it's 9 hours of meeting and my interest in it will likely take a very small % of that, do you have a suggestion as to when I drop in on the meeting?
    Yuri Shkuro
    @yurishkuro
    I assume you'd still use some standard transport protocol like HTTP, MQTT, etc. which do support headers for metadata, instead of encoding trace context directly in the JSON payload.
    Andrew Arnott
    @AArnott
    @yurishkuro That depends. Some folks put JSON-RPC over HTTP, but HTTP is strictly a request-response, client-server protocol whereas JSON-RPC is a P2P protocol, so HTTP isn't a great fit. It's not a fit at all when you have no HTTP server. For all of my use, we simply establish a duplex pipe and put JSON-RPC on it. When we have HTTP servers, we only use it to get a websocket and then once again put JSON-RPC directly on it. Headers sometimes apply (as a means to announce each incoming message's length) but it's just length. And since the headers vary by vendor, or are simply absent, we want a way that JSON-RPC itself can carry the tracecontext payload.
    Daniel Dyla
    @dyladan
    @AArnott I would suggest you join the beginning. There will be some introduction and bookkeeping and that would be a time to bring up your idea. We may not have time to cover it as a topic in full, but it could be a good starting point for discussion
    Bas van Beek
    @basvanbeek
    So I would argue not to have a discussion on how to specifically deal with tracecontext in the JSON-RPC over some wire case.
    What really should be discussed on the JSON-RPC end is then how to envelope JSON-RPC in that case for purposes of generic metadata
    then if you have established rules around key/value pairs for metadata you can probably utilize what is already there with respect to HTTP headers
    Andrew Arnott
    @AArnott
    @basvanbeek Maybe that's where we'll end up. But I'm leaning toward using the JSON-RPC envelope instead of relying on an outer one. I'd rather every JSON-RPC library can immediately implement the spec rather than passing the buck onto its transport, hoping it allows for headers to be added. When using web sockets for example, there are absolutely no headers, since web sockets implicitly provide message boundaries there's absolutely no reason for headers. To say that participating in tracecontext requires that they add headers, with all the crafting and parsing that that would require, would be unnecessarily onerous. JSON-RPC is (nearly) a full protocol and I'd rather it continue to be as self-sufficient as it is rather than create new reasons why we have to build more around it.
    Bas van Beek
    @basvanbeek
    Than make generic metadata part of the protocol.
    Andrew Arnott
    @AArnott
    @basvanbeek It's JSON. We can already throw in 'generic metadata'. But our JSON-RPC libraries need to interpret that metadata in order to propagate as well as act on the tracecontext for the app's own tracing. What we're trying to define as a standard so all JSON-RPC libraries can interoperate is what that 'generic metadata' looks like.
    Bas van Beek
    @basvanbeek
    I don’t think you understand what I meant. If JSON-RPC would establish rules on how kv metadata would be optionally added to rpc payloads you’d be done from an aspect of JSON-RPC supporting any kind of metadata. Doing a specific one use case for tracecontext does not belong at that level. Once metadata in its generic state is in you can simply establish for instrumentation to serialize/deserialize tracecontext in the same manner as http, grpc, etc.
    Andrew Arnott
    @AArnott
    The JSON-RPC 2.0 spec doesn't define how/where to add additional data to its messages. It loosely refers to 'extensions' that may be defined elsewhere but AFAIK there aren't any. So I'm left to my own devices, and adding properties to the top-level object seems reasonable to me.
    The two trace context properties are not just scalar values though. They each have structure per the trace context spec. The spec also defines how to format these structures as strings for HTTP headers, but that's specifically for HTTP headers, which don't apply here. But obviously reusing that format is an option if I wanted to store trace-context in JSON-RPC as string properties. I considered this, along with retaining the original structure by using JSON objects and arrays, and at this morning's meeting we settled on just reusing the string formatting as defined in the HTTP header spec, stored as two JSON properties.
    Abhishek Kumar
    @abhikumarblume
    Hello Guys,,, . In Springboot, just by adding sleuth dependency , we can see 'traceId' and 'spanId' in STS console. I am trying to mimic similar functionality in micronaut using Intellij . I tried injecting dependency implementation "io.micronaut:micronaut-tracing" along with use of annotation 'io.micronaut.http.annotation.NewSpan' at controller. But i am not able to see 'traceId' in Intelli console ? do i have to override logback.xml file ?
    Tristan Sloughter
    @tsloughter
    are there interop tests for w3c baggage like there are for tracecontext?