Skip to content
This repository was archived by the owner on Apr 1, 2026. It is now read-only.

feat: added client side metric instrumentation to basic rpcs - #1188

Closed
daniel-sanche wants to merge 215 commits into
mainfrom
csm_2_instrumentation
Closed

feat: added client side metric instrumentation to basic rpcs#1188
daniel-sanche wants to merge 215 commits into
mainfrom
csm_2_instrumentation

Conversation

@daniel-sanche

@daniel-sanchedaniel-sanche commented Aug 11, 2025

Copy link
Copy Markdown
Contributor

This PR builds off of #1187 to add instrumentation to basic data client rpcs (check_and_mutate, read_modify_write, sample_row_keys, mutate_row)

Metrics are not currently being exported anywhere, just collected and dropped. A future PR will add a GCP exporter to the system

@daniel-sanchedaniel-sanche changed the title [DRAFT] feat: added client side metric instrumentation to data client[DRAFT] feat: added client side metric instrumentation to basic rpcsJan 15, 2026
@daniel-sanchedaniel-sanche changed the title [DRAFT] feat: added client side metric instrumentation to basic rpcsfeat: added client side metric instrumentation to basic rpcsJan 15, 2026
@daniel-sanche
daniel-sanche marked this pull request as ready for review January 15, 2026 21:13
@daniel-sanche
daniel-sanche requested review from a teamJanuary 15, 2026 21:13
@daniel-sanchedaniel-sanche added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jan 15, 2026
@yoshi-kokoroyoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jan 15, 2026
Base automatically changed from csm_1_data_model to mainJanuary 22, 2026 01:20
Comment threadtests/system/data/test_metrics_async.py Outdated
for i in range(num_retryable):
attempt = handler.completed_attempts[i]
assert isinstance(attempt, CompletedAttemptMetric)
assert attempt.end_status.name == "ABORTED"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Not related to the metrics, but ABORTED shouldn't be retried for mutate row?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

It doesn't look like it, and it's not listed as a retryable error in the service config. Is it in Java? It would be easy to add here

assert attempt.end_status.value[0] == 0
assert attempt.backoff_before_attempt_ns == 0
assert (
attempt.gfe_latency_ns > 0 and attempt.gfe_latency_ns < attempt.duration_ns

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

how is gfe_latency_ns injected to the header? this should be a number instead of a range since we can set it in the header.

@daniel-sanchedaniel-sancheJan 28, 2026

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

I think this is testing against the true backend response here, not a mocked value

These are system tests, so I was trying to limit the amount of mocking used here, although some other tests do inject fake exceptions into the stream to test retry logic

final_attempt = handler.completed_attempts[num_retryable]
assert isinstance(final_attempt, CompletedAttemptMetric)
assert final_attempt.end_status.name == "PERMISSION_DENIED"
assert final_attempt.gfe_latency_ns is None

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think as long as the request gets to the server, gfe_latency_ns should not be none. So this is probably related to the test setup ?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

It looks like this test is testing the case where we have multiple transient retryable errors, before encountering a terminal error. For the errors, I'm using a custom error_injector class, to control which errors are triggered in which sequence. So this test wouldn't ever be reaching the real backend

It's been a while since I looked at this, but I remember having issues fully controlling the backend errors in the way I needed for some of these tests, which is why I used the error_injector. There are other tests in this file that send unauthorized requests to trigger a real backend failure though.

@parthea

Copy link
Copy Markdown
Contributor

Closing stale PRs to prepare for the code migration to google-cloud-python

@daniel-sanche

Copy link
Copy Markdown
ContributorAuthor

Re-opening to see if we can get this in before the migration. If not, we can close and re-start this in the monorepo

@parthea

Copy link
Copy Markdown
Contributor

As per offline discussion with @daniel-sanche, closing PR to prepare for the code migration to google-cloud-python

Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

api: bigtableIssues related to the googleapis/python-bigtable API.size: xlPull request size is extra large.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@daniel-sanche@parthea@mutianf@yoshi-kokoro