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

Improve apiserver storage size metric #118812

Merged
merged 1 commit into from Jul 12, 2023

Conversation

serathius
Copy link
Contributor

@serathius serathius commented Jun 22, 2023

/kind feature

Replace `apiserver_storage_db_total_size_in_bytes` with `apiserver_storage_size_bytes` metric

/cc @mborsz @logicalhan @dgrisonnet

Most names are just temporary stand-ins, for now I wanted to confirm that making the metric on demand is even possible.

Goal of this PR is make changes to apiserver_storage_db_total_size_in_bytes necessary to graduate it in the future:

  • Change name to make it compliant with prometheus guidelines.
  • Calculate it on demand instead of periodic to comply with prometheus standards.
  • Replace "endpoint" with "instance" label to make it semantically consistent with storage factory
    for ix, cfg := range s.storageFactory.Configs() {
    serversToValidate[fmt.Sprintf("etcd-%d", ix)] = &componentstatus.EtcdServer{Config: cfg}
    }

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. kind/feature Categorizes issue or PR as related to a new feature. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. area/apiserver area/test sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. sig/testing Categorizes an issue or PR as relevant to SIG Testing. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jun 22, 2023
@serathius
Copy link
Contributor Author

/cc @dgrisonnet

@@ -238,6 +239,21 @@ func (s *EtcdOptions) ApplyWithStorageFactoryTo(factory serverstorage.StorageFac
return err
}

metrics.SetStorageMonitorGetter(func() (monitors []metrics.Monitor, err error) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need this monster to avoid dependency cycle

@serathius serathius force-pushed the storage-metric branch 11 times, most recently from da7ffff to 64d761e Compare June 22, 2023 10:26
@serathius
Copy link
Contributor Author

/retest

@serathius
Copy link
Contributor Author

/assign @jpbetz

@serathius
Copy link
Contributor Author

ping @deads2k @jpbetz @logicalhan

@serathius
Copy link
Contributor Author

ping @dgrisonnet

Comment on lines 74 to 82
dbTotalSize = compbasemetrics.NewGaugeVec(
&compbasemetrics.GaugeOpts{
Subsystem: "apiserver",
Name: "storage_db_total_size_in_bytes",
Help: "Total size of the storage database file physically allocated in bytes.",
StabilityLevel: compbasemetrics.ALPHA,
},
[]string{"endpoint"},
)
Copy link
Member

Choose a reason for hiding this comment

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

Removing this metric will be breaking change for some users, it would be safer if we leave a 1 release deprecation period before removing it completely.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Although this is what was decided when api stability was designed, we've been careful when removing old metrics without giving a grace period to the users.

IMO, we will need to continue being careful when removing alpha metrics and apply deprecation periods until we start moving metrics to beta.

I leave it up to @logicalhan to make a decision here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, but I would argue that old metrics are treated more like Beta and not Alpha. SIG instrumentation should make it explicit and just move them to Beta to avoid making exceptions. For now I treat this as an Alpha metric, thus removing.

Copy link
Member

Choose a reason for hiding this comment

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

I would deprecate it, people likely depend on this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do

}

for i, m := range monitors {
server := fmt.Sprintf("etcd-%d", i)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we will be able to correlate this label with any other one from the other metrics since AFAIK this is the only place we have something like that. So wouldn't having an endpoint like before be easier to use?

Copy link
Contributor Author

@serathius serathius Jul 5, 2023

Choose a reason for hiding this comment

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

No, it's third place to do that. It's also done by apiserver health probes and apiserver component status. As for usefulness of endpoints, it's worse as apiserver will expose all etcd members it connects to. For etcd HA clusters thats a 3 endpoints with the same value (+/- time shift). For each API override that's additional 3 endpoints.

The semantic meaning of server is:

  • etcd-0 the default etcd
  • etcd-1 the first API Resource override, based on order of flags provided to apiserver.
  • etcd-2 the second API Resource override, and so forth.

Of cause it should be documented. Maybe I can include it in metric description.

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense, thank you for the clarification 👍

@serathius
Copy link
Contributor Author

ping @deads2k @jpbetz @logicalhan

@k8s-ci-robot k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 12, 2023
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Jul 12, 2023
@serathius serathius force-pushed the storage-metric branch 2 times, most recently from 03a59b0 to 70312fe Compare July 12, 2023 12:31
Change name to make it compliant with prometheus guidelines.
Calculate it on demand instead of periodic to comply with prometheus standards.
Replace "endpoint" with "server" label to make it semantically consistent with storage factory
@serathius
Copy link
Contributor Author

/retest

Copy link
Member

@logicalhan logicalhan left a comment

Choose a reason for hiding this comment

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

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 12, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 7676176268460083184f1d9be59c3ab83caff518

@jpbetz
Copy link
Contributor

jpbetz commented Jul 12, 2023

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jpbetz, logicalhan, serathius

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 12, 2023
@k8s-ci-robot k8s-ci-robot merged commit 2ec4e14 into kubernetes:master Jul 12, 2023
13 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.28 milestone Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/apiserver area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants