Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tyler Yahn
    @MrAlias
    Makes sense to me to remove the fallback for the exporters ^
    John Watson
    @jkwatson
    :thumbsup:
    Ted Young
    @tedsuo
    /@all a spec PR for versioning and stability now available: open-telemetry/opentelemetry-specification#1291
    Would be great to get dat OTEP merged
    Ritick Gautam
    @riticksingh
    Hi I am developing Span Instrumentation for php , while doing so I am not getting exact definition for the same in specification repo will anyone help over this
    Daniel Dyla
    @dyladan

    I was doing a final comb of the tracing spec to prepare for the release of the JS API and I noticed current trace API spec states:

    The API MUST implement methods to create a SpanContext. These methods SHOULD be the only way to create a SpanContext. This functionality MUST be fully implemented in the API, and SHOULD NOT be overridable.

    In JS the SpanContext is just an interface that any plain object can meet and there currently exists no API to create a span context. What is the intention behind requiring the API to be the only way to create a SpanContext

    John Watson
    @jkwatson
    It's an interface in java as well, and we put a bunch of scary words in the javadoc to encourage people not to try to roll their own.
    The intention in java is that we really really need it to be immutable, and have well defined equals/hashcode implementations, and obviously if someone rolls their own, we can't enforce it.
    Daniel Dyla
    @dyladan
    I think this spec wording is too restrictive
    it's essentially impossible to have such properties in JS
    Alex Van Boxel
    @alexvanboxel
    As @anuraaga suggested in this PR (https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/1892#discussion_r548358724) it would be good to add the behaviour to the spec if the OTLP messages are routed over a messaging system. I will try to join the SIG on Januari 5th to discuss this. I see different implementations in the collector: The kenesis (contrib) implementation converts the messages to Jeager format, while the kafka implementation gives you the option of converting to Jeager or push the Request messages as is. My Google Pubsub implementation also pushes the Request, as it is easy... but is it correct. Wouldn't it be better to unravel the request and send each message, one-by-one. I'm prepared to make an OTEP but would like to discuss this first. Is the SIG meeting a good place todo this?
    2 replies
    Evan Anderson
    @evankanderson

    Hey, I just started looking at implementing traces and metrics in the same application, and I noticed that http.target recommendations for traces (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/http.md#http-server-semantic-conventions) and metrics (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/metrics/semantic_conventions/http-metrics.md#parameterized-labels) seem incompatible.

    In particular, metrics recommends converting http.target to a parameterized version, while tracing seems to suggest the non-parameterized version. Is it expected to use different values for the same label for traces and metrics?

    5 replies
    Joshua MacDonald
    @jmacd
    Hi all, I've posted a Doodle to help us find a time next week for an all-day Metrics Specification workshop: https://doodle.com/poll/m4vzn57bd2tww9bd
    Josh Suereth
    @jsuereth

    Hey Specification folks! I'm implementing some throughput benchmarks for the Java API/SDK and had a question on https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/performance-benchmark.md#create-spans

    I'm assuming we're meant to have attribute strings of size 20 bytes vs. 20 characters (i.e. should I be using long-unicode here at all?) Want to make sure our throughput metrics are consistent.

    1 reply
    Cijo Thomas
    @cijothomas
    https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#tracing-api The tracing api spec has a status "feature-freeze", but the Tracing SDK spec does not have any https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#tracing-sdk. From the blog post (https://medium.com/opentelemetry/tracing-specification-release-candidate-ga-p-eec434d220f2), its mentioned that tracing API/SDK is frozen (except for any P1s). It the omission of status "feature-freeze" in Tracing SDK spec intentional or accidentally missed it?
    Joshua MacDonald
    @jmacd

    The @opentelemetry Metrics Workshop happens tomorrow at 9:30 PST at https://zoom.us/j/8203130519

    9:30 - 9:45am PST: Opening remarks, organization of the day, how we got here, and the many streams of work. We have an API, language SDKs, a Protocol, a Collector, Receivers, Exporters, Semantic Conventions, and a connection to Tracing [organizer: OTel Committee]

    9:45-10:15am PST: Community building: @opentelemetry has first-class @OpenMetricsIO support, and @PrometheusIO users are first-class users. These projects are meant to get along, and committed to it. [organizer: Alolita Sharma]

    10:15 - 11:00am PST: @opentelemetry Collector deployment models (e.g., Daemonset vs. Statefulset), Agents, Sidecars, and first-class support for Prometheus Remote-Write [organizer: Jaana Dogan]

    11:30 - 12:15pm The Metrics API and Data Model, how we integrated the @opencensusio feature set (Tracing and Metrics, combined!) with the @OpenMetricsIO and StatsD data models. Presenting the six @opentelemetry metric instruments [organizer: Bogdan Drutu]

    12:15 - 13:00pm Histograms! How we’ll support high-resolution and variable-boundary histograms and the connection to sampling metric events [organizers: Josh MacDonald, Michael Gerstenhaber]

    13:30 - 15:00pm Questions and answers

    1 reply
    Srikanth Chekuri
    @lonewolf3739
    /@spec-approvers Why does ShouldSample take span name, kind and links as required arguments when they are neither used for making sampling decision nor part of return value SamplingResult(decision, attrs, tracestate).
    7 replies
    Tristan Sloughter
    @tsloughter
    finally adding support for these environment variables and his a snag hprttps://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/sdk-environment-variables.md
    I think OTEL_PROPAGATORS needs to be OTEL_TEXT_MAP_PROPAGATORS?
    other usage in the spec uses "text map" to distinguish from the future "binary" propagator
    Jonatan Ivanov
    @jonatan-ivanov
    I mistakenly posted this into open-telemetry as well, sorry for the cross-post:
    Are there plans to enable GH Discussions on https://github.com/open-telemetry/opentelemetry-specification too as it was enabled for other repos?
    Daniel Dyla
    @dyladan
    WRT tracestate (https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#tracestate) is it required to provide working implementations in the API or is this just specifying the interface?
    Tristan Sloughter
    @tsloughter
    propagation is suposed to work without the SDK, so I assumed it had to be a working implementation
    Daniel Dyla
    @dyladan
    propagation yes, but an implementation with operations?
    propagation can be done by simply carrying the exact string
    Tristan Sloughter
    @tsloughter
    hm, true. it would limit propagation to only between the same formats.. but maybe thats ok
    Daniel Dyla
    @dyladan
    yeah i hadn't really thought of other formats. maybe have to do it just for that
    since tracestate is so intrinsic to w3c
    Tristan Sloughter
    @tsloughter
    there are environment variables for configuration of the BSP, but doesn't seem to be any configuration for enabling BSP. is that just expected to be done in language specific configuration? is it expected to always be enabled?
    Daniel Dyla
    @dyladan
    what is BSP?
    something something propagator i have to assume
    John Watson
    @jkwatson
    BatchSpanProcessor
    Daniel Dyla
    @dyladan
    oh we changed topics
    haha
    ok
    I did not interpret bsp configuration env vars as implicitly enabling the bsp. They just configure a bsp if it happens to be in use (and does not have in-code configuration that conflicts with the var)
    Tristan Sloughter
    @tsloughter
    oh yea, sorry, changed topics :), back to my questions about env variables, hehe
    ok, thats what I figured, just found it then missing to enable it. maybe need an OTEL_SPAN_PROCESSORS
    Daniel Dyla
    @dyladan
    Also, nobody replied to @jonatan-ivanov but I would like to point out that github discussions would be very helpful to document the answers to some of these implementation questions. We could use it for implementers and point users towards the appropriate SIG
    Tristan Sloughter
    @tsloughter
    definitely
    John Watson
    @jkwatson
    +100 on using discussions
    Daniel Dyla
    @dyladan
    I think i remember in december a quick mention the TC didn't want to because "issues are working for us" but now that i've used discussions in some other repos I definitely think they would add value for SIG contributors. I don't want to pollute the spec issues with implementation questions but I do want them to be somewhere that they can be answered async and easily searched later.
    jimshowalter
    @jimshowalter
    Is this where typos in the specification should be reported? This sentence is garbled; "The API and the SDK are split into multiple packages, based on signal type (e.g. one for api-trace, one for api-metric, one for sdk-trace, one for sdk-metric) is considered an implementation detail as long as the API artifact(s) stay separate from the SDK artifact(s)." Remove the parenthetical, and you get "The API and the SDK are split into multiple packages, based on signal type is considered an implementation detail as long as the API artifact(s) stay separate from the SDK artifact(s)." "based on signal type is considered" is garbled.
    Tristan Sloughter
    @tsloughter
    typos are best reported as PRs :)
    jimshowalter
    @jimshowalter
    What is a "SIG", as in "Language SIGs MAY provide methods other than End in the API that also end the span to support language-specific features like with statements in Python."?
    John Watson
    @jkwatson
    "special interest group"
    jimshowalter
    @jimshowalter
    Thanks!
    Regarding submitting a PR to fix the above typo, I'd do that but don't know what the sentence was trying to say.
    Ted Young
    @tedsuo
    I’ve created a PR to bump the version of the specification to v1.0. I see one or two remaining issues officially marked as required for tracing, but I want this PR to exist to raise awareness: open-telemetry/opentelemetry-specification#1372
    @/all :point_up: