opentelemetry-go-contrib VS skywalking

While many programming languages provide robust support for Open Telemetry, this instance focuses on Golang. It's important to note that, in the current context, the logs SDK for Golang is not implemented. For future reference consult the list of supported languages and explore the Open Telemetry repositories. Always prioritize the main repository and its contrib repository, housing extensions and instrumentation libraries crucial to the Open Telemetry framework. Stay updated with the latest developments to ensure seamless integration and enhanced functionality.

It’s assumed that the instrumentation of each component has been completed, and the HTTP communication has also been instrumented by net/http auto instrumentation library.

Tracing, including context propagation, is easy to set up with REST or gRPC. You can instrument most important parts of your application with the contrib package. Some libraries like go-redis have their own otel features, which could be a promising trend in the future. There are some important gaps though; for example, you'll have to go third party for database/sql.

I see! Yeah, this is one where where otel-go is a lot harder to use, but it's something the SIG is looking at. A coworker of mine is helping drive a design that's sort of an "easy button" to configure all the things with the least-surprising defaults[0] and we're seeing how people like it in our SDK distribution that uses it[1]. I hope that sometime soon we'll have the design polished-up enough to get merged in. Like most OSS projects, it'll take some time but I'm confident we can get it done.

The main challenge is that there's a large variety of use cases to fulfill (e.g., someone wants custom context propagation, a custom span processor, and export over HTTP+json but not HTTP+protobuf) and today the answer to that is that you have to pull in all the libraries for all the things you need. It's a lot more energy you need to expend to get started with all of this than it needs to be.

As for logging support in the Go SDK, it's frozen mostly just due to lack of bandwidth and a need to finish what's already been started. Metrics have proven to be much more difficult and time-consuming to implement correctly across all languages, with Go being impacted harder than other languages (e.g., Python and .NET). I think you can expect logging integrations in the near-ish future though.

This is great feedback. I'll pass it on folks who haven't seen it. Thank you! And please feel free to file issues about all the things that rub you the wrong way

[0]: https://github.com/open-telemetry/opentelemetry-go-contrib/p...

[1]: https://github.com/honeycombio/honeycomb-opentelemetry-go

OpenTelemetry middleware for Gin

OpenTelemetry is the work-in-progress merge of OpenCensus and OpenTracing. It is still in early stages as of 2021. We are using its instrumentation libraries opentelemetry-go and [opentelemetry-go-contrib]https://github.com/open-telemetry/opentelemetry-go-contrib/) for our Go services.

Usually the span propagation is located in headers Here you can see an example https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/github.com/gin-gonic/gin/otelgin/gintrace.go

OpenTelemetry has specific instrumentation packages to support popular Golang packages and use cases. For example, this app uses the Gin framework for request routing. OpenTelemetry provides instrumentation package named otelgin to instrument the Gin framework which you need to import in your app. You can find the complete list of supported Golang packages by OpenTelemetry here.

Hi u/brofesor, Your understanding is correct. Though the library you mentioned is not official. I found an issue in the official repo regarding this https://github.com/open-telemetry/opentelemetry-go-contrib/issues/714

Here I described all my experiments: https://github.com/open-telemetry/opentelemetry-go-contrib/issues/746

When choosing distributed tracing tools, considerations include your technology stack, business requirements, and monitoring complexity. Zipkin, SkyWalking, and OpenTelemetry are popular distributed tracing solutions, each with its unique features.

Apache SkyWalking is an APM tool, focusing on microservices, Cloud Native apps, and Kuernetes architectures. It builds its architecture on four kinds of components:

Trying to play devil's advocate here.

> It needs at least a stable set of users, but maintaining a set of users is essentially managing the set of people onboarding and the set of people migrating off.

I could say that I don't care very much about how much users a piece of software has, only that it has enough information on how to use it and enough maintainers to patch any security vulnerabilities and do occasional releases with updated dependencies, as well as address any serious issues or bugs.

For example, Apache Skywalking is an APM solution that most people haven't even heard of (in contrast to something like Sentry), yet it fits those qualities and I see few to no issues with it: https://skywalking.apache.org/

> If you're shrinking then a competitor is providing better options, or your problem space has shifted.

Again, as a user, I might not care that Sentry or another piece of software is better in any number of ways than Apache Skywalking. Similarly, I might not care that something like PostgreSQL is more correct or has a large market share (at least on HN) in comparison to something like MariaDB/MySQL.

If a piece of software meets the needs of my project and won't effectively rot with time, then it's quite possibly good enough as it is, even if it's not the market leader. For my small project's APM needs Apache Skywalking is enough. For my CRUD database needs, something like MariaDB/MySQL will be okay until the time Sun burns out (or PostgreSQL if I'm feeling fancy, but even that's not one of the modern and hip solutions).

Ergo, those better options only become relevant once they're closer to being must haves than nice to haves. Same as how Docker Swarm might be enough for many, even if Kubernetes basically won in the "container wars" and has a way more active community. Swarm will only stop being an option for me once it hits EOL, at least for certain projects where simplicity is appreciated.

Then again, a counterpoint to my own argument here could be the story of LibreOffice and OpenOffice, where the latter was basically donated (instead of the rights to the name being given to the folks behind LibreOffice) and is now in decline while LibreOffice is flourishing - but at the same time they were so close to one another feature wise, that maybe it's not a good point, same as with Gogs and Gitea.

> Where's Java primarily used these days?

I've seen a lot of enterprise-y webdev projects use it for back end stuff (Dropwizard, Spring Boot, Vert.X, Quarkus) and in rare cases even front end (like Vaadin or JSF/PrimeFaces). The IDEs are pretty great, especially the ones by JetBrains, the tooling is pretty mature and boring, the performance is really good (memory usage aside) and the language itself is... okay.

Curiously, I wanted to run my own server for OIDC/OAuth2 authn/authz and to have common features like registration, password resets and social login available to me out of the box, for which I chose Keycloak: https://www.keycloak.org/

Surprise surprise, it's running Java under the hood. I wanted to integrate some of my services with their admin API, seems like the Java library is also updated pretty frequently: https://mvnrepository.com/artifact/org.keycloak/keycloak-adm... whereas ones I found for .NET feel like they're stagnating more: https://www.nuget.org/packages?q=keycloak (probably not a dealbreaker, though)

Then, I wanted to run an APM stack with Apache Skywalking (simpler to self-host than Sentry), which also turns out to be a Java app under the hood: https://skywalking.apache.org/

Also you occasionally see like bank auth libraries or e-signing libraries be offered in Java as well first and foremost, at least in my country (maybe PHP sometimes): https://www.eparaksts.lv/en/for_developers/Java_libraries and their app for getting certificates from the government issued eID cards also runs off of Java.

So while Java isn't exactly "hot" tech, it's used all over the place: even in some game engines, like jMonkeyEngine, or in infrastructure code where something like Go might actually be more comfortable to use.

> What should people use?

I recall Apache Skywalking being pretty good, especially for smaller/medium scale projects: https://skywalking.apache.org/

The architecture is simple, the performance is adequate, it doesn't make you spend days configuring it and it even supports various different data stores: https://skywalking.apache.org/docs/main/v9.0.0/en/setup/back...

The problems with it are that it isn't super popular (although has agents for most popular stacks), the docs could be slightly better and I recall them also working on a new UI so there is a little bit of churn: https://skywalking.apache.org/downloads/

Still better versus some of the other options when you need something that just works instead of spending a lot of time configuring something (even when that something might be superior in regards to the features): https://github.com/getsentry/self-hosted/blob/master/docker-...

Sentry is just the first thing that comes to mind (OpenTelemetry also isn't simpler due to how much it tries to do), but compare its complexity to Skywalking: https://github.com/apache/skywalking/blob/master/docker/dock...

I wish there was more self-hosted software like that out there, enough to address certain concerns in a simple way on day 1 and leave branching out to more complex options like OpenTelemetry once you have a separate team for that and the cash is rolling in.

Personally I've also used Apache Skywalking for a decent out of the box experience: https://skywalking.apache.org/

I've also heard good things about Sentry, though if you need to self-host it, then there's a bit of complexity to deal with: https://sentry.io/welcome/