{"action":"created","issue":{"url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/70","repository_url":"https://api.github.com/repos/census-instrumentation/opencensus-specs","labels_url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/70/labels{/name}","comments_url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/70/comments","events_url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/70/events","html_url":"https://github.com/census-instrumentation/opencensus-specs/issues/70","id":305396119,"node_id":"MDU6SXNzdWUzMDUzOTYxMTk=","number":70,"title":"Add support for https://github.com/w3c/distributed-tracing","user":{"login":"bogdandrutu","id":1373887,"node_id":"MDQ6VXNlcjEzNzM4ODc=","avatar_url":"https://avatars0.githubusercontent.com/u/1373887?v=4","gravatar_id":"","url":"https://api.github.com/users/bogdandrutu","html_url":"https://github.com/bogdandrutu","followers_url":"https://api.github.com/users/bogdandrutu/followers","following_url":"https://api.github.com/users/bogdandrutu/following{/other_user}","gists_url":"https://api.github.com/users/bogdandrutu/gists{/gist_id}","starred_url":"https://api.github.com/users/bogdandrutu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bogdandrutu/subscriptions","organizations_url":"https://api.github.com/users/bogdandrutu/orgs","repos_url":"https://api.github.com/users/bogdandrutu/repos","events_url":"https://api.github.com/users/bogdandrutu/events{/privacy}","received_events_url":"https://api.github.com/users/bogdandrutu/received_events","type":"User","site_admin":false},"labels":[{"id":675876859,"node_id":"MDU6TGFiZWw2NzU4NzY4NTk=","url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/labels/enhancement","name":"enhancement","color":"84b6eb","default":true},{"id":801030611,"node_id":"MDU6TGFiZWw4MDEwMzA2MTE=","url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/labels/stats","name":"stats","color":"fcb5d2","default":false},{"id":801087642,"node_id":"MDU6TGFiZWw4MDEwODc2NDI=","url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/labels/trace","name":"trace","color":"d42cf9","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-15T02:42:57Z","updated_at":"2018-07-05T20:16:43Z","closed_at":null,"author_association":"MEMBER","body":"Once https://github.com/w3c/distributed-tracing is marked as alpha the OpenCensus library should start supporting this generic format.\r\n\r\nThis is for the moment a tracking issue for this support until we have the confirmation that the standard is at least in alpha."},"comment":{"url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/comments/402840204","html_url":"https://github.com/census-instrumentation/opencensus-specs/issues/70#issuecomment-402840204","issue_url":"https://api.github.com/repos/census-instrumentation/opencensus-specs/issues/70","id":402840204,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMjg0MDIwNA==","user":{"login":"lmolkova","id":2347409,"node_id":"MDQ6VXNlcjIzNDc0MDk=","avatar_url":"https://avatars2.githubusercontent.com/u/2347409?v=4","gravatar_id":"","url":"https://api.github.com/users/lmolkova","html_url":"https://github.com/lmolkova","followers_url":"https://api.github.com/users/lmolkova/followers","following_url":"https://api.github.com/users/lmolkova/following{/other_user}","gists_url":"https://api.github.com/users/lmolkova/gists{/gist_id}","starred_url":"https://api.github.com/users/lmolkova/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lmolkova/subscriptions","organizations_url":"https://api.github.com/users/lmolkova/orgs","repos_url":"https://api.github.com/users/lmolkova/repos","events_url":"https://api.github.com/users/lmolkova/events{/privacy}","received_events_url":"https://api.github.com/users/lmolkova/received_events","type":"User","site_admin":false},"created_at":"2018-07-05T20:16:43Z","updated_at":"2018-07-05T20:16:43Z","author_association":"NONE","body":"@bogdandrutu @adriancole  @rakyll, \r\n\r\nwe've been looking into the changes needed to support the W3C protocol and wanted to share our thoughts with you.\r\nHere is a high level description of what the design might look like and which scenarios should be addressed. There are some open questions, mostly on how to implement it in the most efficient way.\r\n\r\nWould be great to hear your thoughts on it and discuss overall plan and the details.\r\n\r\n## traceparent\r\n\r\nNow the header that carries span context is called `traceparent`. [Go](https://github.com/census-instrumentation/opencensus-go/blob/master/plugin/ochttp/propagation/tracecontext/propagation.go) already have a propagation component for it, but uses a different name.\r\n\r\nSupporting traceparent seems to be straightforward in any language as it is the same as X-Cloud-Trace-Context.\r\n\r\nThe main point here: **we should agree on intention that W3C becomes default propagation component**. \r\n\r\nE.g. in python [flask collector](https://github.com/census-instrumentation/opencensus-python/blob/master/opencensus/trace/ext/flask/flask_middleware.py#L34) X-Cloud-Trace-Context. is hardcoded. \r\n\r\n## tracestate\r\n\r\nTracestate carries tracing-system specific context in a list of key value pairs. tracestate allows different vendors propagate additional information and interoperate with their legacy Id formats (and migrate from legacy format to the traceparent).\r\n\r\nOne of the possible scenarios for tracestate is:\r\n- app instrumented with OpenCensus (and configured to export data to ApplicaitonInsights), receives an incoming http request \r\n- it contains some traceparent and `tracestate: ms-id=|123.,other-id=abc` headers\r\n- propagation component extracts traceparent and tracestate\r\n- when new child span is created, a vendor plug-in is notified that a new span is created\r\n- ApplicationInsights reads ms-id on the parent context and recognizes it, it assigns new `ms-id=|123.xyz` value to the child span context\r\n- no one recognizes 'other-id', so it is copied as it to the child span context\r\n- propagation component injects child span context (including tracestate)\r\n- when span is exported, ApplicaitonInsights exporter adds ms-id into the payload it sends to ApplicationInsights ingestion backend and ignores 'other-id'\r\n\r\nSo the key requirement here is: 'unknown' pairs should be propagated blindly (in and out of process), 'known' pairs could be modified by pluggable vendor-specific component for each span.\r\n\r\nFrom the OpenCensus side, supporting tracestate would mean \r\n1. Creating a new (or updating existing in case of Go) propagation component\r\n2. Arguably, extend SpanContext to carry tracestate:\r\n\r\n * tracestate is something that is extracted and injected from/into the headers/metadata similarly to trace id and span id\r\n * while some languages could allow storing tracestate implicitly, we should have a consistent API everywhere, so tracestate should be explicit\r\n\r\n3. Syncronously notify registered vendor plugins that new span is created/starting so it can update tracestate on it's context. \r\n\r\n### General implementation considerations\r\n\r\n#### Tracestate \r\nTracestate should be represented by the class that allows to add, get, update and delete pairs. It should handle overflows of key, value and overall length. \r\nAccording to W3C spec the last updated pairs should appear first, i.e. order matters and prepend and delete should be cheap. So internally it could store the actual pairs in the linked list.\r\n\r\nIt is likely that tracestate is empty or contains just a few pairs. It's also likely that only the first pair will ever be updated (all apps in the cluster are instrumented by the same vendor and request leaves cluster boundary rarely).\r\n\r\n#### Callback\r\nCallback should be fired when new span is created/started. OpenCensus should pass child tracestate to the vendor plugins and must synchronously wait for all plugins to complete updating a child state.\r\nThe new Span should start with the child state and parent state should not be modified.\r\n\r\nOpenCensus should implement default behavior: copy parent tracestate to child tracestate (open question: can we do it efficiently, without copy?).\r\nAfter than vendor plugins may run on the child state and update it.\r\n\r\nIf there are no plugins registered, callback may be skipped (as well as copying the state).\r\nIf tracestate is empty, callback should still be fired.\r\n\r\nInstead of pub-sub callback, we could use inheritance: have an interface that vendor can implement and register. It will be invoked to update the context. If there is no registered implementation - tracestate is propagated without modification. However this will prevent cetain scenarios like multiple vendor plugins.\r\n\r\nOpen questions: \r\n1. How efficiently store tracestate to avoid copy parent state. Tracestate is likely empty or contains just a few items, so may be optimization does not worth it.\r\n2. Multiple vendor plugins: is it a common case? We already have a scenario when we want to have extensibility point to support different internal propagation formats. \r\n "}}
{"actor":{"display_login":"lmolkova"}}