Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    John Watson
    @jkwatson
    you're excluding sdk-common where that class lives
    Marcin Grzejszczak
    @marcingrzejszczak
    Hello everyone! Has something changed about metrics NOT being required for 1.0.0 GA of OTel? According to https://github.com/orgs/open-telemetry/projects/4 and https://github.com/open-telemetry/opentelemetry-specification/projects/2 and open-telemetry/opentelemetry-specification#1173 metrics ARE required for 1.0.0 GA. If that's the case when, why and by whom was this decided?
    John Watson
    @jkwatson
    1.0 will not include metrics by default. the metrics modules will be available in -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
    rnterbush
    @rnterbush
    Hi java community. Since upgrading to 0.13.1 i've been having issues losing the trace context between spans, even inline on the same thread. I'm using span.setCurrent() (on parent span) followed by builder.setParent(Context.current()) (when building the child span) as in the examples, but the trace id of each span is different. Is there some additional configuration required, or did the usage change?
    John Watson
    @jkwatson
    Hmm. There is no span.setCurrent(). Do you mean span.makeCurrent() ?
    rnterbush
    @rnterbush
    sorry yes, that's what i meant
    John Watson
    @jkwatson
    Can you post a gist with your code that isn't working?
    rnterbush
    @rnterbush
        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();
            }
        }
    John Watson
    @jkwatson
    if this is your code, you don't need to make the setParent call, since your parent span is in the current context at that point.
    rnterbush
    @rnterbush
    let me try without it, thanks
    John Watson
    @jkwatson
    In fact, I think you're messing with the parenting by also updating the context again
    rnterbush
    @rnterbush
    Even without that line, the parent of the child span is still zeroed out when it gets created
    I've been checking using a debugger at line span.setAttribute("ryanKey", "ryanValue");
    John Watson
    @jkwatson
    just to make sure... you're not using the agent, correct? Just bare bones API & SDK?
    rnterbush
    @rnterbush
    oh, no i do have the agent added as well, i assumed that was necessary for the context propagation for the http call
    John Watson
    @jkwatson
    if you're using the agent, the debugger may or may not work, due to the way that the agent loads the SDK
    (it loads it off in a separate classloader and does some bytecode magic to make everything work)
    rnterbush
    @rnterbush
    I'm using a local OT collector forwarding to a zipkin UI and the spans are all disjoint there as well
    John Watson
    @jkwatson
    ok, that's a better indication that things aren't working right. :)
    Do you have all the versions of the agent and the api lined up correctly?
    rnterbush
    @rnterbush
    They are all 0.13.1, and the agent jar is the latest from https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases
    John Watson
    @jkwatson
    If you're using the agent, there's a much easier way to do all of this. See my example in this discussion topic: https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions/1945#discussioncomment-223808
    rnterbush
    @rnterbush
    fwiw i'm also seeing issues setting the parent context in the downstream http server span, after generating the context using the propagator
    thanks for the link, I'll check that out as well. Just wanted to follow up on the api/sdk on the off chance it's an actual bug and not user error
    John Watson
    @jkwatson
    I don't think this is an API/SDK issue. I suspect it's something in the way you're doing things and the interaction with the agent. If you have a full example you could post somewhere I could dig in deeper.
    (all our examples using just the API/SDK work fine in 0.13.1)
    rnterbush
    @rnterbush
    I'll fiddle around with it some more and follow up if I run out of ideas, thanks again
    John Watson
    @jkwatson
    good luck! And, I'd recommend posting these as GH discussion topics, rather than gitter, since we're phasing gitter out as a support mechanism
    rnterbush
    @rnterbush
    I've removed the agent and gotten the traces reporting intact again. Are there certain parts of the api that aren't compatible with the auto-instrumentation?
    John Watson
    @jkwatson
    There shouldn't be, but this is a great topic for a discussion in the instrumentation repo.
    It's possible there's a bug or something that was missed in the agent.
    rnterbush
    @rnterbush
    I've reproduced the issue with the http example in the repo and posted my findings in a discussion https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions/2019
    John Watson
    @jkwatson
    :thumbsup:
    Ryan Kennedy
    @rkennedy-mode

    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)

    John Watson
    @jkwatson
    There is no way to do that automatically, no.
    jason plumb
    @breedx-splk
    Is that a good use case for Baggage (even if it's not automated)?
    John Watson
    @jkwatson
    It definitely could be done with Baggage, though you'd need to be careful if you didn't want to propagate it out of the process.
    Ryan Kennedy
    @rkennedy-mode

    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

    HaloFour
    @HaloFour
    Or maybe as a property of the AttributeKey<T>?
    John Watson
    @jkwatson
    Any change of this sort would need to flow through the specification before we would implement it in Java.
    2 replies
    Scott Sue
    @scott.sue_gitlab
    Hi all, apologies as this question is related to the Google Cloud exporter and not opentelemetry itself (if theres a better place to as this question please let me know). Our project unfortunately has a restriction that requires the protobuf 2.x java binary to be used, does anyone know if this is compatible or is able to be compatible with the Google Cloud exporter? As it seems when I attempt to downgrade the protobuf 3.x to 2.x I get some incompatiblity errors.
    John Watson
    @jkwatson
    @jsuereth ^^^
    Josh Suereth
    @jsuereth
    @scott.sue_gitlab I think it's incompatible, but we might be able to "shade" it away. Please file a bug against the operations-java repo and I'll see what we can do with our upstream dependencies on proto 3
    Scott Sue
    @scott.sue_gitlab
    Ok great, let me raise a bug
    ajprakas
    @ajprakas
    I am using this example- https://github.com/open-telemetry/opentelemetry-collector/tree/master/examples/demo to instantiate a open telemetry agent and collector and publish spans to jaeger and zipkin backends via agent.How do I know which are the ports jaeger and zipkin receivers of agent are listening at so that I publish span to those port from my app.
    1 reply
    image.png
    Daniel Gomez Blanco
    @danielgblanco
    Hi, I have question about the OTLP exporter in the Java SDK. As I understand it the exporter itself does not retry requests to the collector. Using 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
    Rishibha-tech
    @Rishibha-tech
    To test open telemetry changes have written some Junit test cases using opentelemetry-sdk-testing version 0.12.0 library for OpenTelemetryExtension class . When the test cases are run independently it works fine . But when gradle build is run the tests are failing . It seems the OpenTelemetryExtension is not collecting the spans when run using command gradle build. How to resolve the same.
    6 replies
    HaloFour
    @HaloFour
    hm, where are releases of OTel API/SDK announced? I missed that 0.14.1 was released.
    1 reply
    Josh Suereth
    @jsuereth
    Follow up from SiG: I think @jkwatson was correct on the batch processor benchmark being sufficient, wrote my finding here: open-telemetry/opentelemetry-java#790