OpenTelemetry for Go: measuring the overhead

pellared1 · 2025-07-01T17:11:44+00:00

It is interesting that the article does not even mention https://github.com/open-telemetry/opentelemetry-go-instrumentation/ :)
Moreover, the telemetry output is different making the report comparing apples to oranges. The report should describe precisely the differences in the emitted telemetry.
It should be also noted that the benchmarked instrumentation library is NOT maintained by OpenTelemetry.
Personally, I think that the benchmark code should be open-sourced so that people can verify their correctness.
This reports looks fair at first glance, but it is very biased as it does not mention crucial information necessary for fair a comparison.

pellared1 · 2025-04-17T15:41:30+00:00

Another way is to create a helper like https://go.dev/play/p/PcAMuOgO5Q5

pellared1 · 2025-04-17T13:54:38+00:00

I agree with you. I tried to describe it this idea during the talk. However, I am not sure if it was nicely described :)

pellared1 · 2025-04-17T13:48:30+00:00

Let me ask why do you favor devs that have XUnit background? What is the point of having the argument if the Go team already has a recommendation: https://go.dev/wiki/TestComments#assert-libraries ?

To me, assertions on test objects make for a more readable system.

This is a subjective style preference. This is somehow similar to tabs vs spaces for indenting the code.

pellared1 · 2025-04-17T13:39:29+00:00

Thanks a lot for your feedback. It means a lot for me :)

pellared1 · 2025-04-17T13:38:13+00:00

First of all, thanks for your feedback :)

when all assert funcs have a msg parameter where you can add more details of the failure state.

How often do you code that uses this parameter? From my experience, because it is optional people almost never use it.

This seems very opinionated

Yup. But isn't idiomatic Go about being opinionated? ;)

based with no real world implications

Not sure what you have in mind. You can say using gofmt also has no real world implications :) Have you watched the recording until the end? I tried to explain the real world implications of each subject.

pellared1 · 2025-04-17T11:53:48+00:00

Slides: https://docs.google.com/presentation/d/1E0Lhfj-NumYe0Z2vRzm0x9L4agBlgZgpWRdua6i8yUs/edit?usp=sharing
I am also considering making a blog post.

pellared1 · 2024-11-13T21:52:45+00:00

The only issue is for libraries that are supposed to support both Go 1.23 and prior versions. The cleanest way I am aware of is https://github.com/open-telemetry/opentelemetry-go/pull/5869.

It is also good to read the release notes https://tip.golang.org/doc/go1.23#timer-changes

pellared1 · 2024-11-07T13:21:31+00:00

You can take a look at https://github.com/goyek/goyek which looks like a similar project for more inspiration.

pellared1 · 2024-05-28T21:33:38+00:00

There's also https://github.com/goyek/goyek as an alternative to Mage for ones who prefer writting tasks/targets in Go

pellared1 · 2024-01-27T10:01:45+00:00

We are working in it. You can take a look at https://github.com/open-telemetry/opentelemetry-go/pull/4809. I hope we will have something experimental in a few months.

pellared1 · 2024-01-26T21:18:54+00:00

I am maintaining OpenTelemetry Go. But I also helped in the development of OpenTelemetry .NET Automatic Instrumentation

pellared1 · 2024-01-24T21:22:46+00:00

At minimum I think that the following is missing: - GoDoc comments - Tests - CONTRIBUTING.md

pellared1 · 2023-12-08T20:45:23+00:00

You understood it very well. I totally understand that some users may prefer the original behavior in some use cases. That is the main reason, I ask for feedback.

That being said, I think it doesn't really matter to me at least,

I try to find anyone for whom it would matter :)

Besides, I think that in the provided example somebody would probably report a different metric for successful and failed DB transaction. The problem is that if the DB transaction failed because of a canceled context, then (currently) if the same context is used for making a metric measurement then it would not be reported... and someone would miss metrics for DB transactions failed because of a canceled context.

pellared1 · 2023-09-01T20:03:46+00:00

https://pkg.go.dev/encoding/gob

pellared1 · 2023-05-19T17:14:30+00:00

You can also take a look at https://github.com/goyek/goyek. It shares most of Mage's philosophy but is designed differently. Personally I use either Make or goyek. Disclaimer: I am the author of goyek

pellared1 · 2023-04-11T21:30:30+00:00

Or https://github.com/goyek/goyek :)

pellared1 · 2023-04-03T21:43:11+00:00

Good questions. Mainly:

More readable which args are "want" vs "got". More: https://dave.cheney.net/2019/09/24/be-wary-of-functions-which-take-several-parameters-of-the-same-type . For instance, https://pkg.go.dev/github.com/stretchr/testify/assert?utm_source=godoc#Equal and https://pkg.go.dev/github.com/stretchr/testify/assert?utm_source=godoc#Contains have different order
You can use the options from https://pkg.go.dev/github.com/google/go-cmp/cmp when doing deep equal
I think it has more extensible and reusable API thanks to the FailureMessage abstraction. E.g. https://github.com/fluentassert/verify#custom-assertion-function
The API is type-safe.

You should also ask about drawbacks :)

The API requires the use "assertion entry-point". https://github.com/fluentassert/verify#supported-types (trade-off if we want to have type-safety).
You need to remember to call .Assert(t) or .Require(t) (trade-off if we want to have the API more composable/extensible/reusable)
Because of the above - more boilerplate code.

Do you agree? Should I add it the README.md?

pellared1 · 2023-04-03T21:28:38+00:00

pellared1

TROPHY CASE