Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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:
    Tristan Sloughter
    @tsloughter
    https://aws.amazon.com/blogs/opensource/distributed-tracing-with-opentelemetry/
    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
    why are all values lowercase in other semantic conventions but OS is all uppercase? https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/semantic_conventions/os.md#operating-system
    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
    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