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

xds: Add counter and gauge metrics #11661

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

DNVindhya
Copy link
Contributor

This PR implements xDS client defined in A78.

Counters

  • grpc.xds_client.server_failure
  • grpc.xds_client.resource_updates_valid
  • grpc.xds_client.resource_updates_invalid

Gauges

  • grpc.xds_client.connected
  • grpc.xds_client.resources

The grpc.xds.authority label is missing, and will be added in a later PR.

Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

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

Sending what I have.

ref = new RefCountedXdsClientObjectPool(bootstrapInfo, target);
MetricRecorder metricRecorderForTarget = targetToMetricRecorderMap.get(target);
metricRecorder =
metricRecorderForTarget != null ? metricRecorderForTarget : metricRecorder;
Copy link
Member

Choose a reason for hiding this comment

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

Don't store the metric recorder. Always use metricRecorder here; if we used to use a different value, that's fine. We actually can't store the MetricRecorders in targetToMetricRecorderMap as that would retain memory of old channels even when all channels for a target have been shut down. We need the MetricRecorder to be released in that case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed targetToMetricRecorderMap and found similar issue of retaining memory in targetToXdsClientMap. Removed the entry for corresponding target key from targetToXdsClientMap when there are no channels for target.

@@ -38,16 +38,19 @@
import io.grpc.SynchronizationContext.ScheduledHandle;
import io.grpc.internal.BackoffPolicy;
import io.grpc.internal.TimeProvider;
import io.grpc.xds.XdsClientMetricReporter;
Copy link
Member

Choose a reason for hiding this comment

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

XdsClientImpl can't depend on io.grpc.xds. It needs to be usable stand-alone. The Reporter should be defined in io.grpc.xds.client.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved to io.grpc.xds.client.

@@ -31,5 +32,8 @@ interface XdsClientPoolFactory {

ObjectPool<XdsClient> getOrCreate(String target) throws XdsInitializationException;
Copy link
Member

Choose a reason for hiding this comment

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

Can you easily delete the old method? (I see the Internal* class that exposes the same signature; that's fine as it is used some other places. But the method here should only be used in our code and I'd hope there are only a few callers.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Deleted the old method.

@@ -118,13 +125,15 @@ public XdsClientImpl(
this.timeProvider = timeProvider;
this.messagePrinter = messagePrinter;
this.securityConfig = securityConfig;
this.target = target;
this.metricReporter = metricReporter;
metricReporter.setXdsClient(this);
Copy link
Member

Choose a reason for hiding this comment

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

We should move this and close() out of XdsClientImpl and into SharedXdsClientPoolProvider. The caller is in control of the XdsClientImpl lifecycle, so it doesn't have to have XdsClientImpl tell it when things happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

* Interface for reporting metrics through callback.
*
*/
interface CallbackMetricReporter {
Copy link
Member

Choose a reason for hiding this comment

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

Since these methods are tightly coupled to methods in XdsClient, I suggest having one interface for each of the methods and defining the method in XdsClient. You also then wouldn't have default implementation. That is more clear, and in our modern Java lambda world is more typical.

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