Skip to content

Add the ability to configure a ratio of proxy metrics to be recorded #2772

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

Merged
merged 1 commit into from
Jun 27, 2025

Conversation

CydeWeys
Copy link
Member

@CydeWeys CydeWeys commented Jun 16, 2025

This ratio defaults to 1.0 (i.e. all metrics will be recorded), but we will set it much lower in sandbox and production, probably something closer to 0.01. This will reduce recorded metrics volume and thus StackDriver cost, while still retaining enough data for overall performance monitoring.

This is handled stochastically, so as to not require any coordination between Java threads or GKE pods/clusters, as alternative approaches would (i.e. using a counter and recording every Nth, or throttling to a max metrics qps).

BUG = http://b/364907042


This change is Reviewable

@CydeWeys CydeWeys requested a review from gbrodman June 16, 2025 21:26
@CydeWeys
Copy link
Member Author

Still a WIP; I need to get the tests working (by creating dummy proxy config objects for them).

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

lgtm so far but it needs test changes

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @CydeWeys)

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from 69c53e6 to be093b5 Compare June 20, 2025 15:00
Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed 6 of 6 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 85 at r2 (raw file):

  private static final Random random = new Random();

  double frontendMetricsRatio;

private?


proxy/src/main/java/google/registry/proxy/metric/BackendMetrics.java line 82 at r2 (raw file):

  private static final Random random = new Random();

  double backendMetricsRatio;

private?

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from be093b5 to b9cb719 Compare June 20, 2025 15:35
Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

PTAL, now with passing tests.

Reviewable status: 4 of 8 files reviewed, 2 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/metric/BackendMetrics.java line 82 at r2 (raw file):

Previously, gbrodman wrote…

private?

Can't be.


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 85 at r2 (raw file):

Previously, gbrodman wrote…

private?

Can't be.

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed all commit messages.
Reviewable status: 4 of 8 files reviewed, 1 unresolved discussion (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/metric/BackendMetrics.java line 82 at r2 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Can't be.

now that the tests are added, yeah


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 85 at r2 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Can't be.

now that the tests are added, yeah


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

  @NonFinalForTesting
  @VisibleForTesting
  Random random = new Random();

if you inject this, it doesn't need to be non-final-for-testing

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed 4 of 4 files at r3.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, gbrodman wrote…

if you inject this, it doesn't need to be non-final-for-testing

I don't know if we need to @Inject Random though; we don't do so anywhere else in our codebase. Adding dependency injection solely to modify it in a test seems unnecessary.

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

we don't do so anywhere else in our codebase

https://github.com/google/nomulus/blob/master/core/src/main/java/google/registry/tools/server/RefreshDnsForAllDomainsAction.java#L98 ?

ether way, it's probably the better pattern anyway

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, gbrodman wrote…

we don't do so anywhere else in our codebase

https://github.com/google/nomulus/blob/master/core/src/main/java/google/registry/tools/server/RefreshDnsForAllDomainsAction.java#L98 ?

ether way, it's probably the better pattern anyway

What's probably the better pattern?

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from b9cb719 to 7cd5db2 Compare June 20, 2025 16:23
Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

What's probably the better pattern?

injection -- plus, we inject SecureRandoms all over the place anyway so it's not unique

Comment on lines +141 to +143
@SuppressWarnings("unused")
ChannelFuture unusedFuture3 = channel3.close();

Check notice

Code scanning / CodeQL

Unread local variable Note test

Variable 'ChannelFuture unusedFuture3' is never read.
@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch 2 times, most recently from defbfaf to 1964cb6 Compare June 20, 2025 16:36
Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

Reviewable status: 2 of 8 files reviewed, 3 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, gbrodman wrote…

injection -- plus, we inject SecureRandoms all over the place anyway so it's not unique

Done.

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

PTAL

Reviewable status: 2 of 8 files reviewed, 3 unresolved discussions (waiting on @gbrodman)

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

PTAL

Reviewable status: 2 of 8 files reviewed, 3 unresolved discussions (waiting on @gbrodman)

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed 6 of 6 files at r5, all commit messages.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Done.

now these can both be private right?


proxy/src/test/java/google/registry/proxy/metric/FrontendMetricsTest.java line 37 at r5 (raw file):

  private static final String PROTOCOL = "some protocol";
  private static final String CERT_HASH = "abc_blah_1134zdf";
  private final FrontendMetrics metrics = new FrontendMetrics(1.0, new Random());

generally the pattern we use is mocking the random and creating the object in the beforeEach method


proxy/src/main/java/google/registry/proxy/ProxyModule.java line 415 at r5 (raw file):

  @Singleton
  @Provides
  static Random provideRandom() {

is it worth doing this vs just using the SecureRandom used / injected elsewhere ?

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/ProxyModule.java line 415 at r5 (raw file):

Previously, gbrodman wrote…

is it worth doing this vs just using the SecureRandom used / injected elsewhere ?

SecureRandom is much more resource-intensive and could possibly even become a bottleneck when QPS starts hitting four digits. It's not worth it.


proxy/src/test/java/google/registry/proxy/metric/FrontendMetricsTest.java line 37 at r5 (raw file):

Previously, gbrodman wrote…

generally the pattern we use is mocking the random and creating the object in the beforeEach method

Not worth doing here, as it only needs to be overridden for one test. Overriding it for every test doesn't make sense, as there's no common set of return values that would work for all tests.

Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @gbrodman)


proxy/src/main/java/google/registry/proxy/metric/FrontendMetrics.java line 86 at r3 (raw file):

Previously, gbrodman wrote…

now these can both be private right?

No, because they're being overridden in tests.

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @CydeWeys)


proxy/src/main/java/google/registry/proxy/ProxyModule.java line 415 at r5 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

SecureRandom is much more resource-intensive and could possibly even become a bottleneck when QPS starts hitting four digits. It's not worth it.

oh interesting, good to know


proxy/src/test/java/google/registry/proxy/metric/FrontendMetricsTest.java line 37 at r5 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Not worth doing here, as it only needs to be overridden for one test. Overriding it for every test doesn't make sense, as there's no common set of return values that would work for all tests.

what i see in other tests, what i think tends to be the cleanest, is to create the default state of the object (with 1.0 and a real Random) in the BeforeEach method and then create a new object in each test method where the default state is not valid (say, with a different threshold or a mocked Random)

or we just have the action be only a local variable each test case to be explicit (since that wouldn't take any longer than creating it as an instance variable here).

if we're not going to do that, then I think the initial approach (non-final-for-testing variable) was probably better

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from 1964cb6 to eb378d1 Compare June 23, 2025 23:41
Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

PTAAL

Reviewable status: 4 of 8 files reviewed, 3 unresolved discussions (waiting on @gbrodman)


proxy/src/test/java/google/registry/proxy/metric/FrontendMetricsTest.java line 37 at r5 (raw file):

Previously, gbrodman wrote…

what i see in other tests, what i think tends to be the cleanest, is to create the default state of the object (with 1.0 and a real Random) in the BeforeEach method and then create a new object in each test method where the default state is not valid (say, with a different threshold or a mocked Random)

or we just have the action be only a local variable each test case to be explicit (since that wouldn't take any longer than creating it as an instance variable here).

if we're not going to do that, then I think the initial approach (non-final-for-testing variable) was probably better

Done.

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from eb378d1 to 913f4ce Compare June 24, 2025 00:00
Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

:lgtm:

Reviewed 4 of 4 files at r6, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)

@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from 913f4ce to 8fbdf1d Compare June 26, 2025 21:27
This ratio defaults to 1.0 (i.e. all metrics will be recorded), but we will set
it much lower in sandbox and production, probably something closer to 0.01. This
will reduce recorded metrics volume and thus StackDriver cost, while still
retaining enough data for overall performance monitoring.

This is handled stochastically, so as to not require any coordination between
Java threads or GKE pods/clusters, as alternative approaches would (i.e. using a
counter and recording every Nth, or throttling to a max metrics qps).
@CydeWeys CydeWeys force-pushed the reduce-proxy-metrics branch from 8fbdf1d to bd6526f Compare June 26, 2025 21:30
Copy link
Member Author

@CydeWeys CydeWeys left a comment

Choose a reason for hiding this comment

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

PTAL, needs approval re-upped because I had to format a file.

Reviewable status: 7 of 8 files reviewed, 2 unresolved discussions (waiting on @gbrodman)

Copy link
Collaborator

@gbrodman gbrodman left a comment

Choose a reason for hiding this comment

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

Reviewed 1 of 1 files at r7, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @CydeWeys)

@CydeWeys CydeWeys added this pull request to the merge queue Jun 27, 2025
Merged via the queue into google:master with commit 0e8cd75 Jun 27, 2025
8 of 9 checks passed
@CydeWeys CydeWeys deleted the reduce-proxy-metrics branch June 27, 2025 05:55
CydeWeys added a commit to CydeWeys/nomulus that referenced this pull request Jun 30, 2025
This is necessary so that the total number of requests/responses adds up
correctly even though some fraction of them are only being recorded. It uses
stochastic rounding so that the totals add up correctly even when the reciprocal
of the ratio isn't an integer.

This is a follow-up to PR google#2772.
CydeWeys added a commit to CydeWeys/nomulus that referenced this pull request Jun 30, 2025
This is necessary so that the total number of requests/responses adds up
correctly even though some fraction of them are only being recorded. It uses
stochastic rounding so that the totals add up correctly even when the reciprocal
of the ratio isn't an integer.

This is a follow-up to PR google#2772.
CydeWeys added a commit to CydeWeys/nomulus that referenced this pull request Jun 30, 2025
This is necessary so that the total number of requests/responses adds up
correctly even though some fraction of them are only being recorded. It uses
stochastic rounding so that the totals add up correctly even when the reciprocal
of the ratio isn't an integer.

This is a follow-up to PR google#2772.
github-merge-queue bot pushed a commit that referenced this pull request Jul 2, 2025
This is necessary so that the total number of requests/responses adds up
correctly even though some fraction of them are only being recorded. It uses
stochastic rounding so that the totals add up correctly even when the reciprocal
of the ratio isn't an integer.

This is a follow-up to PR #2772.
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.

2 participants