-
Notifications
You must be signed in to change notification settings - Fork 1
grpc metrics and minor refactoring #62
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
Conversation
* refactor: example * upgrade grpc-utils lib to the latest Co-authored-by: Laxman Ch <laxman@traceable.ai>
This comment has been minimized.
This comment has been minimized.
Codecov Report
@@ Coverage Diff @@
## main #62 +/- ##
=========================================
Coverage 69.50% 69.50%
+ Complexity 106 105 -1
=========================================
Files 15 15
Lines 564 564
Branches 32 33 +1
=========================================
Hits 392 392
Misses 153 153
Partials 19 19
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
Example metrics Server metrics Client metrics |
| @Test | ||
| public void testMetricInitialization() { | ||
| PlatformService service = getService(Map.of("service.name", "test-service", | ||
| PlatformService service = getService(Map.of("service.name", "sample-app", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason for the changes in here? The default tag change should be transparent (And is, if I'm reading the test changes correctly)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With new changes, these tests are failing when they are tested with different default tags.
These tests are simulating a reload (lifecycle stop and start) kind of scenario. However, for commonTags there is no provision for cleanup/destroy. We need to destroy the registry itself and recreate it.
By using the same app name we are bypassing the test order dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that a caught regression though? In the prior implementation, it reset its state on start/stop and it no longer does. Seems like it would be easy enough to reset the meter registry, right?
| if (tags == null || tags.isEmpty()) { | ||
| return DEFAULT_TAGS; | ||
| private static Iterable<Tag> toIterable(Map<String, String> tags) { | ||
| Set<Tag> newTags = new HashSet<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any concern about replicable ordering? Could just as easily use a list
This comment has been minimized.
This comment has been minimized.
| Set<MeterRegistry> registries = new HashSet<>(METER_REGISTRY.getRegistries()); | ||
| registries.forEach(METER_REGISTRY::remove); | ||
| meterRegistry.getRegistries().forEach(MeterRegistry::close); | ||
| meterRegistry.forEachMeter(meterRegistry::remove); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit - a lot of this code - 430-434 I believe - is redundant now that we're just replacing the whole registry. We don't need to go through and clear stuff out any more.
Description
Added grpc server/client metrics monitoring.
Testing
Tested manually
Checklist:
Documentation
NA