@jsuereth here is where the spec says metric labels and span attributes must have identical meanings: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/common/common.md#recommendations-for-opentelemetry-authors
Semantic conventions exist for four areas: for Resource, Span and Log attribute names as well as Metric label keys. In addition, for spans we have two more areas: Event and Link attribute names. Identical namespaces or names in all these areas MUST have identical meanings. For example the http.method span attribute name denotes exactly the same concept as the http.method metric label, has the same data type and the same set of possible values (in both cases it records the value of the HTTP protocol's request method as a string).
today i (re)learned the opentelemetry-colllector gitter channel is https://gitter.im/open-telemetry/opentelemetry-service
should the context still be extracted even if the url is excluded?
Dears,
Appreciate your support for the below issue,
I built my open telemetry demo as the below steps,
- I built two microservices one by Django and the another by Go, Django send HTTP request to Go service,
- Jaeger tool is configured for UI tracing,
- Unfortunately, Django tracing and Go tracing are separated in Jaeger tool and I do not know the reason although I received Django parent trace id in the request header and it is normal to be all Django request tracing including Go tracing as one request tracing in Jaeger,
My Git repo: https://github.com/OmarEltamasehy/django-gotracing-example
Thanks for your time and consideration.
Hello everyone, I am happy to announce the v0.7.0 release of the specifications. See https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v0.7.0
2 replies
@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
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?