-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
server: add node_id
label to _status/vars output
#98640
server: add node_id
label to _status/vars output
#98640
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.
I think you will have to update a bunch of tests with the new NodeID label (CI failures)
Reviewable status: complete! 1 of 0 LGTMs obtained
d9c0d1c
to
24fe9df
Compare
bors r=aadityasondhi |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed: |
bors r=aadityasondhi single on |
Build failed (retrying...): |
Build failed (retrying...): |
@dhartunian the batch seems to be failing on
|
bors r- |
Canceled. |
Sorry, I think my tsdb changes landed prior to this. The source fields now have the Tenant IDs in them. #98077 |
24fe9df
to
f57e9f6
Compare
Previously, the output of the prometheus metrics via `_status/ vars` did not include any node labels. This caused challenges for customers who want to monitor large clusters as it requires additional configuration on the scrape- side to ensure a node ID is added to the metrics. This can be challenging to deal with when nodes come and go in a cluster and the scrape configuration must change as well. This change adds a `node_id` prometheus label to the metrics we output that matches the current node's ID. Since `_status/vars` is output from a single node there is only ever one single value that's appropriate here. Secondary tenants will mark their metrics with either the nodeID of the shared- process system tenant, or the instanceID of the tenant process. Resolves: cockroachdb#94763 Epic: None Release note (ops change): Prometheus metrics available at the `_status/vars` path now contain a `node_id` label that identifies the node they were scraped from.
f57e9f6
to
2353a6a
Compare
bors r=aadityasondhi |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. Backport to branch 23.1.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Previously, the output of the prometheus metrics via
_status/ vars
did not include any node labels. This caused challenges for customers who want to monitor large clusters as it requires additional configuration on the scrape- side to ensure a node ID is added to the metrics. This can be challenging to deal with when nodes come and go in a cluster and the scrape configuration must change as well.This change adds a
node_id
prometheus label to the metrics we output that matches the current node's ID. Since_status/vars
is output from a single node there is only ever one single value that's appropriate here.Secondary tenants will mark their metrics with either the nodeID of the shared- process system tenant, or the instanceID of the tenant process.
Resolves: #94763
Epic: None
Release note (ops change): Prometheus metrics available at the
_status/vars
path now contain anode_id
label that identifies the node they were scraped from.