feat: MetricsTracer implementation

[ddixit14]

This PR adds framework-neutral MetricsTracer to Gax. This class adds logics during the start and end of an RPC call to calculate the latencies and count the number of RPC calls. Metric recording responsibilities are delegated to the MetricsRecorder, providing flexibility for diverse observability frameworks.
Unit tests are added for every implemented method, including tests for MetricsTracerFactory (class responsible for creating one MetricsTacer per operation).

[lqiu96]

Thanks @ddixit14, I think it's looking good. I have a general question about the recording the attempts.
Is there a reason why attemptStarted() doesn't record/ increment the number of attempts (i.e. runs metricsRecorder.recordAttemptCount(1, attributes);). I would assume that starting the attempt would record an attempt count.
I'm guessing there is a reason and I'm not too familiar with why, but it seems like that might be a better spot than having to do that in attemptSucceeded and attemptCancelled and attemptFailed, etc.

According to me, if we record the attempt count when the attempt started, we cannot deduce its attributes (did it succeed/fail/got cancelled?). Attributes should be recorded only when we know the final status of the attempt. If we do it in attemptStarted(), there would be no "status" attributes to record. Does it make sense?

I see. I think given the current interface of MetricsRecorder this makes sense. I wonder if MetricsRecorder should be enhanced with some methods like:

1. recordOperationResult
2. recordAttemptResult

I don't have a list of pro/cons with this, but it seems cleaner (?) or at least makes sense in my head. I think that recording the attempt should occur when the attempt started and not be dependent on getting a result. Given that we need to record the status, maybe that can be done separately from recording the attempt count?

This probably doesn't need to be fixed now (or fixed at all), but just throwing some thoughts out.
CC: @blakeli0

[ddixit14]

Thanks @ddixit14, I think it's looking good. I have a general question about the recording the attempts.
Is there a reason why attemptStarted() doesn't record/ increment the number of attempts (i.e. runs metricsRecorder.recordAttemptCount(1, attributes);). I would assume that starting the attempt would record an attempt count.
I'm guessing there is a reason and I'm not too familiar with why, but it seems like that might be a better spot than having to do that in attemptSucceeded and attemptCancelled and attemptFailed, etc.

According to me, if we record the attempt count when the attempt started, we cannot deduce its attributes (did it succeed/fail/got cancelled?). Attributes should be recorded only when we know the final status of the attempt. If we do it in attemptStarted(), there would be no "status" attributes to record. Does it make sense?

I see. I think given the current interface of MetricsRecorder this makes sense. I wonder if MetricsRecorder should be enhanced with some methods like:

1. recordOperationResult
2. recordAttemptResult

I don't have a list of pro/cons with this, but it seems cleaner (?) or at least makes sense in my head. I think that recording the attempt should occur when the attempt started and not be dependent on getting a result. Given that we need to record the status, maybe that can be done separately from recording the attempt count?

This probably doesn't need to be fixed now (or fixed at all), but just throwing some thoughts out. CC: @blakeli0

That's exactly what came to my mind when I thought about multiple attempts for a successful operation, should we keep a track of attempt_count somehow, with a counter maybe? But then I realized that we are calculating the metrics for each attempt, so keeping a track of number of attempts is irrelevant for us. For every attempt that resulted in something, we just increment the count by 1 with the corresponding attributes.

[blakeli0]

We don't have to mention OpenTelemetry in the title, as this implementation is framework neutral. Please add more details to the description as well.

[ddixit14]

We don't have to mention OpenTelemetry in the title, as this implementation is framework neutral. Please add more details to the description as well.

Understood, changed title and added a detailed description.

[lqiu96]

LGTM. I left a few nits if you could take a quick look at.

[ddixit14]

LGTM. I left a few nits if you could take a quick look at.

All changed and pushed. thank you.

[sonarqubecloud]

Quality Gate failed for 'gapic-generator-java-root'

Failed conditions

0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[sonarqubecloud]

Quality Gate failed for 'java_showcase_integration_tests'

Failed conditions

0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud