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
feat: add num_sessions_in_pool metric #128
feat: add num_sessions_in_pool metric #128
Conversation
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.
LGTM
My one concern is about removing metrics. Since we haven't had any metrics before, we don't have a process for it right now but open to hearing suggestions on how people do this in other products.
@@ -46,20 +55,20 @@ | |||
// The Metric name and description | |||
static final String MAX_IN_USE_SESSIONS = "cloud.google.com/java/spanner/max_in_use_sessions"; | |||
static final String MAX_ALLOWED_SESSIONS = "cloud.google.com/java/spanner/max_allowed_sessions"; | |||
static final String IN_USE_SESSIONS = "cloud.google.com/java/spanner/in_use_sessions"; |
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.
I'm worried for anyone relying on this metric already in their monitoring? What is the process for deprecating metrics in OpenCensus? Is there some monitoring to figure out if someone is exporting it?
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.
What is the process for deprecating metrics in OpenCensus?
In OC, (usually) we first mark the existing API as deprecated and keep it for 18 months before removing it. I think the feature is fairly new and looks safe to remove it with a note in the Changelog.
Is there some monitoring to figure out if someone is exporting it?
I think it is feasible to see the ingested metrics in stackdriver, but I haven't done it personally.
I'm worried for anyone relying on this metric already in their monitoring?
Another option is keep existing(IN_USE_SESSIONS
) metric along with new metric. In this case, in_use_sessions data will be accounted/exported twice.
WDYT?
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.
Ok, I think you're right that this is relatively new. We will mark this in the Changelog.
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.
If you can include something about this in the PR description, that would be great. Then we can copy it in when doing the release.
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.
done
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.
LGTM.
One thing we should keep in the back of our heads is that sum of these new metrics could vary a little bit, even in a situation where the actual number of sessions in the pool is steady. Each individual value is read independently of each other, and it is possible that a session is counted twice or not at all, for example when it is transferred from numSessionsBeingPrepared
to numWritePreparedSessions
. That could cause some confusion for users, especially when they have configured the session pool with MinSessions=MaxSessions
. In that case you would expect the number of sessions in the pool to always be constant.
google-cloud-spanner/src/main/java/com/google/cloud/spanner/MetricRegistryConstants.java
Show resolved
Hide resolved
@@ -1638,7 +1637,6 @@ public Void call() { | |||
.containsEntry(MetricRegistryConstants.NUM_ACQUIRED_SESSIONS, 3L); | |||
assertThat(record.getMetrics()) | |||
.containsEntry(MetricRegistryConstants.NUM_RELEASED_SESSIONS, 3L); | |||
assertThat(record.getMetrics()).containsEntry(MetricRegistryConstants.IN_USE_SESSIONS, 0L); |
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.
No test for new Gauges?
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.
Added test to validate newly added Metric. I had to modify MetricRegistryTestUtils
to support and test multiple timeseries entries. PTAL when you get a chance.
@mayurkale22 I just want to check what is latest status of this PR? any progress? |
Oops! This went off my radar due to other priorities. I'm going to rebase the PR and fix unresolved comments soon. Thanks for bringing this to my attention. |
@skuruppu @olavloite do you know why build is failing (Kokoro - Test: Integration), looks unrelated to my change. |
@mayurkale22 That is unfortunately an (infrastructure) problem that we are running into on a semi-regular basis. It has nothing to do with your change, and the only way to circumvent it at the moment is triggering a new build, for example by adding the kokoro:force-run label to the PR. |
Codecov Report
|
@olavloite, the latest failure is interesting:
would you be able to take a quick look? |
Hmmm... That's strange. There has been no changes to the test case lately, so my initial guess would be that the backend is now reacting differently. Up until now the backend accepted query options to be specified for DML statements, but seemed to ignore them. Now it seems that they are at least checked for a valid value. |
That's interesting. I also wondered why this suddenly came up given that we haven't touched this code in a couple of months. |
I think we should just remove this specific test case for now, and ask the backend team what the expected behavior of |
…s to v1.18.0 (googleapis#128) This PR contains the following updates: | Package | Update | Change | |---|---|---| | [com.google.api.grpc:proto-google-common-protos](https://togithub.com/googleapis/java-iam) | minor | `1.17.0` -> `1.18.0` | --- ### Renovate configuration :date: **Schedule**: At any time (no schedule defined). :vertical_traffic_light: **Automerge**: Disabled by config. Please merge this manually once you are satisfied. :recycle: **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. :no_bell: **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [WhiteSource Renovate](https://renovate.whitesourcesoftware.com). View repository job log [here](https://app.renovatebot.com/dashboard#googleapis/java-spanner-jdbc).
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Updates #53, this is based on the last discussion in the thread: #53 (comment)
This is how it looks in Stackdriver UI:
Breaking Note:
The
cloud.google.com/java/spanner/in_use_sessions
metric has been deprecated since v1.55.2, usecloud.google.com/java/spanner/num_sessions_in_pool
instead.