Missing dropped_spans_count

[leonidmanieiev]

v1 trace.proto describes the following counters:

• dropped_events_count + dropped_attributes_count of the event
• dropped_links_count + dropped_attributes_count of the link
• dropped_attributes_count of the span

dropped_spans_count is missing, although it'd be as useful as the others because, as with attributes, spans can be discarded due to long names or because there are too many of them.

1. Is there a reason for the absence of dropped_spans_count?
2. Are there plans to add such a counter in the future?

[tigrannajaryan]

Where exactly (in which proto message) would this be recorded and who would know the dropped span count? There is no Trace message in the proto where we could put this field. I also don't know how would the SDK (which SDK in a distributed system?) calculate this number.

[leonidmanieiev]

Where exactly (in which proto message) would this be recorded

As I understand it, it could be either ScopeSpans or ResourceSpans. Basically, it's the burden of a Tracer that has a name that uniquely identifies the instrumentation scope. So I would say that ScopeSpans is more appropriate than ResourceSpans.

who would know the dropped span count

Tracer, because it's the only API for creating a Span.

how would the SDK calculate this number

Sorry, didn't understand this question. But Tracer can incriminate this counter every time it fails to create a new Span.

[trask]

@leonidmanieiev maybe open-telemetry/oteps#249 is what you're looking for?

[leonidmanieiev]

Will this pipeline monitoring proposal eventually become v2/trace.proto or where will it go?

[tigrannajaryan]

@leonidmanieiev I think I understand what you are looking for, but this needs more details. This is not just a proto change, it will require changes in the SDKs as well. I think an OTEP would be warranted in this case. I do not know whether the OTEP will be accepted, but that's where I would start.

[leonidmanieiev]

@tigrannajaryan Thank you, I'll try to propose in OTEP. Closing this issue.

[tigrannajaryan]

@leonidmanieiev I recommend attending Specification SIG meeting to gauge the community interest before you start working on the OTEP. I would also open an issue in the spec repo. It will get triaged and if it gets accepted only after that it makes sense to go ahead. If the issue is not accepted there is no point in proposing an OTEP.