-alphaversioned modules. "GA" will include both metrics and traces, but will be some version beyond 1.0. This decision was made globally across of of OTel by the tech and governance committees, in collaboration with the maintainers.
7 replies
public static void doTheThing(Tracer tracer) {
Span span = tracer.spanBuilder("doTheThing").startSpan();
try (Scope scope = span.makeCurrent()) {
makeExitCall(tracer, span);
} catch (Exception e) {
span.setStatus(StatusCode.ERROR, "Hit Exception");
} finally {
span.end();
}
}
public static void makeExitCall(Tracer tracer, Span inputSpan) {
Span span = tracer.spanBuilder("makeTheCall").setParent(Context.current().with(inputSpan))
.setSpanKind(Span.Kind.CLIENT).startSpan();
span.setAttribute("ryanKey", "ryanValue");
try (Scope scope = span.makeCurrent()) {
String url = "http://localhost:8084/aws/print";
System.out.println("Pinging URL: " + url);
try {
URL urlObj = new URL(url);
HttpURLConnection connection = (HttpURLConnection) urlObj.openConnection();
openTelemetry.getPropagators().getTextMapPropagator().inject(Context.current(), connection, setter);
connection.setRequestProperty("Connection", "Keep-Alive");
connection.getInputStream();
} catch (Exception e) {
e.printStackTrace();
}
} catch (Exception e) {
} finally {
span.end();
}
}span.setAttribute("ryanKey", "ryanValue");
I tried looking in the docs but didn't see anything obvious. is there a way to set a Span attribute that propagates to child spans?
we know our customer ID early in the request process and would like it to be available as a dimension on all child Spans so it's available for filtering and grouping. it doesn't currently seem to be propagating on its own in a trace with spans A -> B -> C where the attribute is set in B (i.e. it's not showing up in C so far as I can tell)
thanks for confirming, John. I wonder if it would ever make sense for Span.setAttribute(…) to take an optional third parameter allowing the caller to specify if/how the attribute should propagate (e.g. NO_PROPAGATION, PROPAGATE_WITHIN_SERVICE, PROPAGATE_ACROSS_SERVICES). seems like a fair bit of complexity, though
maybe we're thinking about this the wrong way around. we're using Honeycomb and are spinning up a new service using the auto instrumentation agent. we're concerned that we'll set the customer ID on one span and then do the bulk of the work in a child span and not have the customer ID available where we need it. Honeycomb, unfortunately, is wholly event (Span) centric and can't handle queries of the form (find all Spans of type X with attribute customer_id=Y somewhere in the Trace)
auto instrumentation increases the likelihood of an extra Span layer being magically inserted between where the attribute is set and where the interesting work is being measured
1 reply
BatchSpanProcessor will keep trying to export the current batch in the configured delay interval until the queue reaches its max size, at which point it'll start to drop spans. Is this correct?
7 replies
6 replies
