Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ted Young
    @tedsuo
    There is also a Spec meeting today at 4pm pacific. I’ve added this discussion to that agenda as well.
    So, for people who want to follow along, the roadmap for this versioning and stability proposal:
    • Discussion 4pm Pacific Today Dec 1st
    • Discussion 8:30am Pacific Tomorrow Dec 2nd
    • OTEP submitted friday, Dec 4th
    • OTEP (hopefully) approved by Friday, Dec 11th
    Ted Young
    @tedsuo
    Once that process is complete, I would like to add versioning and support to the spec, and then create a release that marks tracing as stable, according to those rules.
    Once that is complete, .NET can release “v1.0 or equivalent” and we will make an annoucement as a project.
    For that announcement to happen this year, I believe we must have versioning and support resolved by the 11th.
    Tyler Yahn
    @MrAlias
    :+1:
    Thanks for the breakdown @tedsuo
    Ted Young
    @tedsuo
    NP!
    Ted Young
    @tedsuo
    Thank you everyone who attended this morning’s discussion on versioning. A second meeting has been added at 1pm pacific, today, to continue discussion.
    When: 1:00pm Pacific, Dec 2nd
    Where: https://zoom.us/j/8203130519
    What: Develop an OTEP to define versioning, stability, and support gurantees for OpenTelemetry.
    Doc: https://docs.google.com/document/d/1QHlPsMqwrBm7-IIPef9czuM8KFiLbEDMzGhPrmHcppA/edit#
    Please attend, or supply feedback asyncronously in the doc.
    Ted Young
    @tedsuo
    That was great. This versioniong proposal is shaping up. It looks like we have our basic guidelines, but we need to understand how well different languages will be able to implement them. Like everything else we spec out, we want broad cross-language agreement but there will still be language-specific details that have to be resolved.
    Ted Young
    @tedsuo
    Just to keep the train rolling, next meeting is tommorrow 8:00am Pacific
    When: 8:00pm Pacific, Dec 2nd
    Where: https://zoom.us/j/8203130519
    What: Develop an OTEP to define versioning, stability, and support gurantees for OpenTelemetry.
    Doc: https://docs.google.com/document/d/1QHlPsMqwrBm7-IIPef9czuM8KFiLbEDMzGhPrmHcppA/edit#
    Please attend, or supply feedback asyncronously in the doc.
    Tristan Sloughter
    @tsloughter
    I think that was supposed to be 8am, Dec 3rd?
    which I just realized this morning its the first thursday of the month :), so I've got a conflict. have a Erlang Ecosystem Foundation Observability working group meeting to run at the same time
    Daniel Dyla
    @dyladan
    yeah i think it starts in just under 2 hours if i understand correctly
    Andrew Hsu
    @andrewhsu
    i noticed this PR, should it be re-prioritized as P1? open-telemetry/opentelemetry-specification#1269
    Ted Young
    @tedsuo
    Sorry for the copypasta fail! Appreciate the work people are putting in to this versioning proposal.
    The OTEP will be published tomorrow.
    Andrew Hsu
    @andrewhsu
    Friendly reminder we have otel spec issue scrub 🧽 mtg tomorrow, Friday morning 8:30a PST.
    Not many spec issues to triage, so if we have quorum with collector maintainers, we’ll also continue triaging collector and collector-contrib issues.
    1 reply
    Ted Young
    @tedsuo
    Versioning OTEP is ready! Please review and comment: open-telemetry/oteps#143
    Tyler Yahn
    @MrAlias
    :tada:
    OpenTelemetry fully supports the AWS Tracing header
    uh, I guess they are equating the Java implementation with "OpenTelemetry"
    that or by "fully supports" they mean, "has pluggable propagation so any third party can be plugged in"
    Tristan Sloughter
    @tsloughter
    I think we might have to return to the vendor "support" part of the spec to document distros
    argh, its worse than I thought, I put nothing in vendors.md about propagation :)
    Ted Young
    @tedsuo
    @tsloughter definitely want to get these terms nailed down in the new year. :)
    /@all Hi all! The versioning and stability work is moving along, but the next step requires you! Language maintainers, please review the OTEP, and draft an example of how you would implement it. This draft is due wednesday. Details about the OTEP and language-specific drafts can be found in the tracking issue, here: open-telemetry/opentelemetry-specification#1267
    Ted Young
    @tedsuo
    FYI, one more meeting about versioning, tomorrow morning at 9:00am pacific.
    When: 9:00am Pacific, Dec 11th
    Where: https://zoom.us/j/8203130519
    OTEP: open-telemetry/oteps#143
    Ted Young
    @tedsuo
    /@all open-telemetry/oteps#143 is now ready for approval.
    Tristan Sloughter
    @tsloughter
    Andrew Hsu
    @andrewhsu
    @bogdandrutu you joining us for the spec issue scrub?
    Tristan Sloughter
    @tsloughter
    I'm working on implementing support for resource detectors and am not sure what the spec means here:
    Note the failure to detect any resource information MUST NOT be considered an error, whereas an error that occurs during an attempt to detect resource information SHOULD be considered an error.
    if say the ec2 detector fails, it can't fetch the information from the /metadata endpoint or whatever, what should happen?
    John Watson
    @jkwatson
    With open-telemetry/opentelemetry-specification#1269 merged, does this mean we should remove the fallback service-name settings from all the built-in exporters?
    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