Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Punyashloka Biswal
    @punya
    If so, we'll need to move metric-related dependencies out of the global package.
    Tyler Yahn
    @MrAlias
    yes, and yes
    Though I wonder if we could try to be smarter about how that is staged
    it will be quite frustrating to not have a global function to get a MeterProvider
    but I haven't though of a better way
    Punyashloka Biswal
    @punya
    Could we move the function to a metric-specific package?
    Just a different import, still the same process-wide scope.
    Tyler Yahn
    @MrAlias
    Possibly. If we wanted to unify when it becomes GA that would mean the function would move and be a breaking change
    also, it could also mean that all the global functions would need to move
    Punyashloka Biswal
    @punya
    At GA, we could add a forwarding shim to the global package. The signal-specific function would keep working indefinitely.
    The other option, which has its own trade-offs, is to have the global package remain pre-1.0 at GA - just have the individual trace, propagation and baggage modules be v1.0.
    Tyler Yahn
    @MrAlias
    Having a shim will leave two options to accomplish the same task which is not the ideal.
    The other option where the global package remains pre-1.0 means that the global package will always be pre-1.0. There will be additional signals (logs) added in the future and if we want to take this approach those signals while in development would be added to the otel package prior to their GA release.
    I think with all this in mind, the idea of just not having a global function for non-GA-ed signals seems like the best option.
    When they become stable is when we are recommending their general use. Which means prior to that convenience functionality should not be expected.
    Punyashloka Biswal
    @punya
    That also lines up best with the language in the versioning OTEP ("No stable signal can reference an experimental signal, including the Global API")
    Punyashloka Biswal
    @punya
    Is there an existing issue tracking the package and module splits/moves we need in order to get to GA?
    Tyler Yahn
    @MrAlias
    There is not. @punya please feel free to create one if you have the time
    we can also discuss it more at Thursday's SIG meeting
    Punyashloka Biswal
    @punya
    I'll create something as a starting point, and would love to refine/discuss in the SIG meeting.
    Tyler Yahn
    @MrAlias
    Awesome, thanks
    3 replies
    Tyler Yahn
    @MrAlias
    @jmacd would you be okay with us doing a release? Is there anything you think needs to merge before we do that?
    3 replies
    Anthony Mirabella
    @Aneurysm9
    https://github.com/open-telemetry/opentelemetry-go/releases/tag/v0.16.0
    6 replies
    Anthony Mirabella
    @Aneurysm9
    @jmacd I could use your eyes on the contrib release PR to ensure I dealt with the metrics changes appropriately open-telemetry/opentelemetry-go-contrib#523
    7 replies
    Tyler Yahn
    @MrAlias
    I'm dealing with a power outage at my place currently with pretty limited internet connectivity. Not sure I'm going to be able to make the SIG meeting.
    @Aneurysm9 would you be able to lead the meeting?
    Anthony Mirabella
    @Aneurysm9
    will do my best
    Joshua MacDonald
    @jmacd
    @Aneurysm9 I can repro the datadog problem, looking into it
    Anthony Mirabella
    @Aneurysm9
    :thumbsup:
    Joshua MacDonald
    @jmacd
    @Aneurysm9 I have trouble with git so won't try to push a fix. It's missing a defer pusher.Stop(context.Background()) somewhere after the Start
    6 replies
    that'l flush the SDK before the exporter closes
    Anthony Mirabella
    @Aneurysm9
    https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v0.16.0 thanks @jmacd for helping me find the silly mistake I made on that test
    Joshua MacDonald
    @jmacd
    Thanks @Aneurysm9 for the release! :tada:
    ET
    @evantorrie
    @MrAlias @Aneurysm9 I'm not much of a fan of the 20+ commits required for these dependency updates (e.g. for stretchr/testify v1.6.1 to v1.7.0 in opentelemetry-go-contrib). Aneurysm9, I think in a prior instance you had just combined all of the individual updates to a specific package into a single PR (and closed the individual automatic update PRs). Am I remembering correctly?
    Anthony Mirabella
    @Aneurysm9
    I did, yes, basically just merge all of them into a branch and make a PR from that branch, otherwise it takes forever and a day to wait for the CI to run on each one after re-integrating with the trunk from the previous merge
    3 replies
    Rashmi Modhwadia
    @rushminatorr
    Anyone else getting module go.opentelemetry.io/otel@latest found (v0.16.0), but does not contain package go.opentelemetry.io/otel/api/propagation or am i doing something incorrect? just following the doc examples on https://opentelemetry.io/docs/go/getting-started/
    module go.opentelemetry.io/otel@latest found (v0.16.0), but does not contain package go.opentelemetry.io/otel/api/trace
    Anthony Mirabella
    @Aneurysm9
    I think we may need to add a reminder to update those documents to our release process, at least while things are still in flux and changing significantly
    can you see if updating all of the go.opentelemetry.io modules in your go.mod to v0.16.0 helps resolve the issue?
    Rashmi Modhwadia
    @rushminatorr
    i did try that too..
    Anthony Mirabella
    @Aneurysm9
    are you perhaps working off of an old version of that document? Even at v0.15.0 the api/propagation and api/trace packages had moved to propagation and trace, respectively.
    can you try https://deploy-preview-361--opentelemetry.netlify.app/docs/go/getting-started/ from the open-telemetry/opentelemetry.io#361 I just created to update the docs for v0.16.0?
    Rashmi Modhwadia
    @rushminatorr
    thanks - will try this
    Rashmi Modhwadia
    @rushminatorr
    okay - i did a clean start - works okay.
    i am going to add my code now - i am suspecting some conflict with "net/http" package dependency maybe? when using the instrumentation?
    i will test this.
    Rashmi Modhwadia
    @rushminatorr
    I been trying to use - https://pkg.go.dev/go.opentelemetry.io/otel/exporters/otlp#pkg-overview
    fails at exporter, err := otlp.NewExporter(ctx)
    seems like it now need driver, options interfaces. Do the docs need updating?
    6 replies
    taman9333
    @taman9333

    Hello folks, I had 2 problems with OTEL Implementation in Golang
    1 - Golang service don't show in the trace despite the headers are sent in b3 multi format
    2 - I can't propate headers (forward headers) from Golang service as In the endpoint I am doing a http request to another service

    I've followed example from OTEL gorilla mux instrumentation but in vain, can anyone help please

    Peter
    @Petrovich172
    Hey guys! I made a PR with remote sampling instruments open-telemetry/opentelemetry-go#1479
    It's my first contribute, so I would be very grateful for your feedback
    Rashmi Modhwadia
    @rushminatorr
    I am using the collector, i have zpages setup with defaults, i dont know how to access it? /zpages gives a 404, i know its running but do not know the endpoint. anyone has any tips please?
    Anthony Mirabella
    @Aneurysm9
    the Go SDK does not provide zpages at this time, for questions about the collector you may have better luck if you ask in https://gitter.im/open-telemetry/opentelemetry-service
    Rashmi Modhwadia
    @rushminatorr
    ah okay - thanks
    Punyashloka Biswal
    @punya
    @MrAlias I created a draft PR with the home-grown tool I used to analyze the impact of the refactors we were discussing: https://github.com/open-telemetry/opentelemetry-go/pull/1483/files. If it seems useful, I can clean it up a bit more and actually merge it into the repo.
    Steven E. Harris
    @seh

    I'm using the OpenTelemetry libraries at version 0.15 right now. I noticed that the documentation for (*BatchSpanProcessor).Shutdown claims that it "flushes the queue and waits until all spans are processed." What I see, though, and by my reading of the code, it does not flush spans that have not made it through the queue yet.

    Does anyone know if this has changed in the latest version 0.16?

    3 replies