Example: instrumenting a CRUD application

[pellared]

How about adding an example of using OTel Go in a CRUD application? Do you think it would be good to put something like this somewhere under https://github.com/open-telemetry/opentelemetry-go* (existing repo, new repo)?

Such an example could demonstrate a little more realistic scenario.

This is what I created for a Gophercon.pl talk: https://github.com/pellared/gopherconpl-opentelemetry-go. It can be used as a baseline).

[shivanshuraj1333]

I'm happy to work on this :)

[hanyuancheung]

I'm with you! This is an extraordinary idea that could show others what observability looks like with otel differently in such a convenient way, as well as a quick start to deploy the whole system including backends and storage.

May I join you and work on it? @pellared

[pellared]

@zhyChesterCheung @shivanshu1333

Thanks a lot for your feedback. The first thing we should do is to agree on some constraints (I feel that requirements could be defined as we go).

Here are some questions I have that could help us define the constraints.

1. Can we create a new repository for this? How should it be named? opentelemetry-go-demo?
2. Should we demonstrated only stable features or experimental as well?
3. Can we use instrumentation packages that live outside of https://github.com/open-telemetry such us https://github.com/XSAM/otelsql?
4. What telemetry backends should we use?
5. Should we also demonstrate the OTel Collector?
6. Should we try to align the approach across and share the proposal with other OTel ecosystems/languages?

I would love to get your points of view before I propose anything.

[joaopgrassi]

I like this initiative!

1. Can we create a new repository for this? How should it be named? opentelemetry-go-demo

What about something like opentelemetry-go-recipes? Then it could be a home for several sample projects.

2. Should we demonstrated only stable features or experimental as well?

I'm more inclined to demonstrate stable features, but the repo maybe could contain a "experimental" area where we could put samples that use these exp features?

3. Can we use instrumentation packages that live outside of @open-telemetry such us XSAM/otelsql?

If these cover "recipes" of common apps/setups I don't see why not? Actually that would be the whole point of it, IMHO.

4 What telemetry backends should we use? 5 Should we also demonstrate the OTel Collector?

I guess Having the collector + Jaeger would be best as it exposes people to both? But for simplicity Jaeger might be best.

[pellared]

1. Can we create a new repository for this? How should it be named? opentelemetry-go-demo?

I think it should be as few projects as possible. Maybe even one to reduce the maintenance cost.

2. Should we demonstrate only stable features or experimental as well?

I think we should rather demonstrate only stable features.

3. Can we use instrumentation packages that live outside of https://github.com/open-telemetry such us https://github.com/XSAM/otelsql?

Why not? Assuming the approvers and maintainers will approve 😉

4. What telemetry backends should we use?

Jaeger for traces.

5. Should we also demonstrate the OTel Collector?

I would start with just Jaeger and give guidance (links) on how to work with Collector. Why? Lower learning curve and lower maintenance cost.

[PalanQu]

@MrAlias Hi, Can i work on this?

[MrAlias]

@PalanQu @shivanshu1333 @hanyuancheung it sounds like you would all like to work on this.

I can assign it to all of you, but please coordinate in here on who is going to do what and make sure to not duplicate work.

Also, please let me know if you no longer are able to work on this.

[9bany]

Anyone working on this? If not, I will start and create a pull request. @PalanQu @shivanshu1333 @hanyuancheung ? cc @pellared @MrAlias

[pellared]

Closing per https://github.com/open-telemetry/opentelemetry-go/pull/4092#issuecomment-1929025059