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

otelgrpc: Implement grpc.StatsHandler for trace instrumentation #3002

Merged
merged 22 commits into from Sep 19, 2023

Conversation

fatsheep9146
Copy link
Contributor

@fatsheep9146 fatsheep9146 commented Nov 16, 2022

fixed #197
related #2840
Signed-off-by: Ziqi Zhao zhaoziqi9146@gmail.com

@fatsheep9146 fatsheep9146 changed the title [otlpgrpc] refactor otlpgrpc to use grpc.StatsHandler [otelgrpc] refactor otelgrpc to use grpc.StatsHandler Nov 16, 2022
@codecov
Copy link

codecov bot commented Nov 16, 2022

Codecov Report

Merging #3002 (256b144) into main (f44f5ad) will increase coverage by 0.1%.
The diff coverage is 95.3%.

Impacted file tree graph

@@           Coverage Diff           @@
##            main   #3002     +/-   ##
=======================================
+ Coverage   81.9%   82.1%   +0.1%     
=======================================
  Files        141     142      +1     
  Lines       9711    9818    +107     
=======================================
+ Hits        7963    8064    +101     
- Misses      1616    1619      +3     
- Partials     132     135      +3     
Files Changed Coverage
...n/google.golang.org/grpc/otelgrpc/stats_handler.go 95.3%

@fatsheep9146
Copy link
Contributor Author

@MrAlias @dashpole @dmathieu
Please help review this pr, thanks :)

@dashpole
Copy link
Contributor

Thanks for tackling this!

I have a few questions. Can you update the description with the answers?

  • Is this meant to have feature parity with the existing otelgrpc instrumentation, and eventually replace it? Or is it meant to be something you use instead of otelgrpc instrumentation? If it is replacing it, what is the plan for deprecating the old one?
  • Is there anything you were unable to implement with the stats handler interface?

One other question:

Is it possible to run the same unit tests against a stats-handler-based implementation and the current implementation? Or did you copy existing test cases when writing these tests?

@fatsheep9146
Copy link
Contributor Author

Sorry for my delay

Is this meant to have feature parity with the existing otelgrpc instrumentation, and eventually replace it? Or is it meant to be something you use instead of otelgrpc instrumentation? If it is replacing it, what is the plan for deprecating the old one?

I think this feature is not to replace the existing one, but to provide a new way to instrument the grpc library. But in this new way with stats handler, we are able to implement more cases that the interceptors do not, for example, a failure to decode the message which is mentioned in #197 (comment).

Is there anything you were unable to implement with the stats handler interface?

For now, I think stats handler has much more info about the grpc request, response and connection, so it definitely is a good place to add instrument logic. I can not answer this question based on what I know about the grpc stats handler.

Is it possible to run the same unit tests against a stats-handler-based implementation and the current implementation? Or did you copy existing test cases when writing these tests?

Yes, I already add the same test like interceptors in test directory.

@dashpole

@fatsheep9146
Copy link
Contributor Author

@open-telemetry/go-approvers hi, is anyone able to review this pr? Thanks a lot

@fatsheep9146 fatsheep9146 force-pushed the otelgrpc-use-statshandler branch 2 times, most recently from 45a26ea to c5ec7ae Compare May 21, 2023 04:50
Copy link
Member

@pellared pellared left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving a quick review feedback

CHANGELOG.md Outdated Show resolved Hide resolved
@fatsheep9146
Copy link
Contributor Author

I noticed that the stats handler misses the functionality you added here: #2700. Any reasons for that?

I was plan to implement the stats.handler step by step, cover the trace first, and then cover the metrics. Which is also convenient for review.

Do you think I should implement it in this pr or create another pr for metrics?

I'm open for both way. @pellared

@pellared
Copy link
Member

pellared commented Sep 18, 2023

I noticed that the stats handler misses the functionality you added here: #2700. Any reasons for that?

I was plan to implement the stats.handler step by step, cover the trace first, and then cover the metrics. Which is also convenient for review.

Do you think I should implement it in this pr or create another pr for metrics?

I'm open for both way. @pellared

During the SIG meetings we discussed that we would like to have a feature-parity before we deprecate interceptors as part of #3002 (review).

Still I think we can tackle it in a separate PR.

Are there any other features which are missing when comparing with the interceptors?

@fatsheep9146
Copy link
Contributor Author

fatsheep9146 commented Sep 18, 2023

I noticed that the stats handler misses the functionality you added here: #2700. Any reasons for that?

I was plan to implement the stats.handler step by step, cover the trace first, and then cover the metrics. Which is also convenient for review.
Do you think I should implement it in this pr or create another pr for metrics?
I'm open for both way. @pellared

During the SIG meetings we discussed that we would like to have a feature-parity before we deprecate interceptors as part of #3002 (review).

Still I think we can tackle it in a separate PR.

Are there any other features which are missing when comparing with the interceptors?

I think metric is the only missing feature, since I wrote a simple e2e test TestStatsHandler just like interceptors to make sure the trace related function is complete.
@pellared

Co-authored-by: Robert Pająk <pellared@hotmail.com>
@pellared pellared changed the title [otelgrpc] implement grpc.StatsHandler for grpc instrumentation otelgrpc: Implement grpc.StatsHandler Sep 18, 2023
@fatsheep9146
Copy link
Contributor Author

@pellared Thanks for creating the following issues!

@hanyuancheung
Copy link
Member

It seems that this PR could be merged first, and then we could continue the following work.

@pellared pellared changed the title otelgrpc: Implement grpc.StatsHandler otelgrpc: Implement grpc.StatsHandler for trace instrumentation Sep 19, 2023
@pellared pellared merged commit bf86b26 into open-telemetry:main Sep 19, 2023
25 checks passed
@pellared
Copy link
Member

@fatsheep9146 Merged 🎉 Thank you for your patience ❤️ You can follow-up with #4316 and #4317

@fatsheep9146
Copy link
Contributor Author

@fatsheep9146 Merged 🎉 Thank you for your patience ❤️ You can follow-up with #4316 and #4317

Thanks! I will solve the follow-up ASAP. @pellared

@mehdihadeli
Copy link

Hi,
When do you release new style of grpc otel? V0.44 doesn't have grpc metrics

@dmathieu
Copy link
Member

@pellared
Copy link
Member

0.45.0 was released a few hour ago. https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v1.20.0

@mehdihadeli Yet metrics are not supported yet. See #4316. We hope to implement it for the next release.

raphael added a commit to goadesign/clue that referenced this pull request Jan 2, 2024
This replaces the deprecated use of interceptors.
See open-telemetry/opentelemetry-go-contrib#3002.

Remove use of Goa request ID middleware. This is superseded by logging span IDs.
raphael added a commit to goadesign/clue that referenced this pull request Jan 2, 2024
This replaces the deprecated use of interceptors.
See open-telemetry/opentelemetry-go-contrib#3002.

Remove use of Goa request ID middleware. This is superseded by logging span IDs.
raphael added a commit to goadesign/clue that referenced this pull request Jan 8, 2024
This replaces the deprecated use of interceptors.
See open-telemetry/opentelemetry-go-contrib#3002.

Remove use of Goa request ID middleware. This is superseded by logging span IDs.
raphael added a commit to goadesign/clue that referenced this pull request Jan 8, 2024
* Switch to using OpenTelemetry for both tracing and metrics

This commit replaces the `metrics` and `trace` packages with a new `clue` package that leverages OpenTelemetry for instrumenting metrics and traces.

See the README for instructions on how to upgrade.

* Add tests

* Remove coupling on Goa middleware

* Use GRPC stat.handler for tracing in gRPC (#349)

This replaces the deprecated use of interceptors.
See open-telemetry/opentelemetry-go-contrib#3002.

Remove use of Goa request ID middleware. This is superseded by logging span IDs.

* Add example `tester` service to show API Integration Testing of a Goa System (#331)

* initial commit

* Empty-Commit

* add readme file (still need to fill out)

* tester readme update

* Trying out a workflow to run integration tests against local binaries

* Add proto install to /example/weather/scripts/setup

* fix integration.yaml

* disable mono on ubuntu

* move mono stop

* Try to find out what's running on 8084

* Trying to disable mono?

* trying to stop mono 2

* add a sleep after stop/disable?

* add some echo

* see if stop/disable mono fails

* add back in || true, change front ports to see if this even works at all

* oops forgot to change int test port

* try no send to dev null?

* sleep before testing

* take out netstat

* sleep longer? give time for docker to do work to get grafana?

* remove dev>null again... :\

* sleep 60 :(

* Implement review comment changes

* Fix runTests check for filtering if

* Empty-Commit

* try starting each service individually, check fo rmono

* just KILL mono?

* back to 8084, check all ports

* fix typo

* add flag to turn off grafana for services (for CI testing)

* clean up integration.yaml script

* review fixes

* Get Stack Trace to Err Log on Panic

* small fixes for style

* protoc -> 25.1, better wait in integration.yaml

* Add synchronous testing feature

* Make one of the synchronous as an example

* move func maps to service definition

* Remove use of legacy flag

---------

Co-authored-by: Jason Borneman <49321691+jasondborneman@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement grpc.StatsHandler for grpc instrumentation
9 participants