Document metrics exposed by the library

[dgrisonnet]

We should add a documentation that would easily be consumable by our users.

We could do something similar to Kubernetes in https://kubernetes.io/docs/reference/instrumentation/metrics/ and reuse their static analysis tool that generates the doc.

[olivierlemasle]

/assign

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[dashpole]

/triage accepted
@olivierlemasle are you still interested in taking this on?

[hjet]

@dashpole happy to grab this one, will have time to work on this in the coming days. i'll aim to follow the approach described above by @dgrisonnet (found the tool here)

[hjet]

so from what i can tell, only one metric is exposed by this library.

would it be okay to create a doc (manually) in docs/ following the same structure as this doc, or should i write a quick script that copies the tool and runs it on this repo to generate the doc?

edit: i see now that there are inherited metrics from apiserver and ../component-base/.../workqueue -- i don't think that tool performs deep analysis into imported packages so would essentially have to feed it this repo, as well as apiserver and workqueue metric defs... not the cleanest solution but likely better than nothing. let me know if this approach makes sense.