Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add instrumentation for Cassandra: github.com/gocql/gocql #91

Closed
4 tasks done
MrAlias opened this issue Jun 18, 2020 · 6 comments
Closed
4 tasks done

Add instrumentation for Cassandra: github.com/gocql/gocql #91

MrAlias opened this issue Jun 18, 2020 · 6 comments
Assignees
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Milestone

Comments

@MrAlias
Copy link
Contributor

MrAlias commented Jun 18, 2020

https://github.com/gocql/gocql

Tasks

  • code complete with tests passing
  • Dockerfile with example app showing instrumentation
  • documentation updated
  • instrumentation added to the opentelemetry registry

Prior Art

@MrAlias MrAlias added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed area: instrumentation Related to an instrumentation package labels Jun 18, 2020
@reggiemcdonald
Copy link
Contributor

@MrAlias could I give this a try?

@reggiemcdonald
Copy link
Contributor

reggiemcdonald commented Jul 8, 2020

After a bit of research it appears that I can either:

  • Create an implementation of gocql.Tracer, which appears to be quite resource intensive with the multiple queries to the Database, but does not require the creation of a wrapper
  • Create a wrapper around gocql.Session or gocql.Query and avoid using the Tracer hook

Any suggestions which might be the better approach?

@Aneurysm9
Copy link
Member

The comment on the gocql.Tracer type says:

Gathering this information might be essential for debugging and optimizing queries, but this feature should not be used on production systems with very high load.

That would lead me to believe that creating a wrapper is the better approach. Ideally we'd be able to leave the instrumentation enabled at all times.

@reggiemcdonald
Copy link
Contributor

The comment on the gocql.Tracer type says:

Gathering this information might be essential for debugging and optimizing queries, but this feature should not be used on production systems with very high load.

That would lead me to believe that creating a wrapper is the better approach. Ideally we'd be able to leave the instrumentation enabled at all times.

Perfect that's what I thought. Thanks!

@reggiemcdonald
Copy link
Contributor

https://github.com/gocql/gocql

Tasks

  • code complete with tests passing
  • Dockerfile with example app showing instrumentation
  • documentation updated
  • instrumentation added to the opentelemetry registry

Prior Art

All tasks completed, ready to close

@MrAlias
Copy link
Contributor Author

MrAlias commented Jul 30, 2020

Awesome 🎉! Thanks for the help @reggiemcdonald

@MrAlias MrAlias closed this as completed Jul 30, 2020
plantfansam referenced this issue in plantfansam/opentelemetry-go-contrib Mar 18, 2022
* b3 propagator

* fix as per new api.

* add benchmark test.
@pellared pellared added this to the untracked milestone Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: instrumentation Related to an instrumentation package enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants