@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
2 replies
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?
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.
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.
/@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.
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.
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
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.
Thanks for the breakdown @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.
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.
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.
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.
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.
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
i noticed this PR, should it be re-prioritized as P1? open-telemetry/opentelemetry-specification#1269
The OTEP will be published tomorrow.
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"
argh, its worse than I thought, I put nothing in vendors.md about propagation :)
/@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
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
When: 9:00am Pacific, Dec 11th
Where: https://zoom.us/j/8203130519
OTEP: open-telemetry/oteps#143
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
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?
With open-telemetry/opentelemetry-specification#1269 merged, does this mean we should remove the fallback service-name settings from all the built-in exporters?
/@all a spec PR for versioning and stability now available: open-telemetry/opentelemetry-specification#1291
Would be great to get dat OTEP merged
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