Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrew Hsu
    @andrewhsu
    @bogdandrutu from the metrics sig mtg today, we discussed tracking of metrics issues outstanding for otel GA. we don’t have that many spec issues to triage at tomorrows otel spec issue scrub 🧽 at 8:30a PST, so we could use the remaining time to go over the metrics issues. i’ve added to the agenda cc @jmacd
    Bogdan Drutu
    @bogdandrutu
    Sure
    akash19980
    @akash19980
    Is there any way of exporting Otel traces to Elastic Search
    2 replies
    Tristan Sloughter
    @tsloughter
    crap, just realized, is there a difference between the "noop tracer" and the "no api noop tracer" . I'm finally implementing https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#behavior-of-the-api-in-the-absence-of-an-installed-sdk and realized it could be saying that if there is an SDK but th eno-op tracer is being used then none of this applies?
    or does it (the noop tracer) function the same whether or not an SDK is included?
    Chris Gilbert
    @cg110
    Hi, are there any good examples of when to use what type of Span, and what lifespan they should have. Specifically thinking about requests that become async, where a user requests some activity, we put it in a queue to then do the work, and the start request completes. The code later on complete that work, and the user has an event/polling for the status. The original request/span is done, and I'm not sure if that's a producer/consumer span kind, or if it's a span link, so it's a new trace, but links back to the original request trace.
    It'd also be good to know what's the expectation of span lifetimes, should all spans complete in the lifetime of the root span, I think I saw an example on OpenTracing website where a child span activity was timed-out, but that long child span still complete the span after the parent. Producer/consumer which clearly say that that consumer can be some time later.
    Ted Young
    @tedsuo
    /@all I’ve scheduled a meeting to further discuss versioning and stability for tomorrow, 8:30am pacific, as that is a eurpoe-friendly timeblock with no other OTel meetings.
    When: 8:30am 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. I can also also schedule another meetings for tomorrow afternoon, if that is needed.
    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.