I agree the metrics by themselves are not sufficient, which is why the KEP also adds kubectl warnings (for user visibility) and audit annotations (to let admins identify specific problematic clients).

> What would an administrator do about that if they get an alert for it?

I envision several ways admins could use this or respond to the metric:

• Requiring the metric to be clean after a CI run to ensure nothing is making use of deprecated APIs
• Adding a warning before upgrading to version X if requests to deprecated APIs removed in version X were made recently
• Using a cheap metric check to trigger a more expensive audit log sweep to identify/notify problematic clients

> Just looking at the metrics, I think I like the balance of 2 the most as well (not extending the existing request metrics, and not adding a whole lot of new series)

Sounds good.

> At the very least we should document how to go from the metric to the audit log entry

Definitely, I plan to add documentation for the following:

• Detecting if deprecated requests have been made to an API server
• Joining the deprecated request metric to the count metric to get more details about volume, read/write nature, scope, etc
• Filtering audit events to requests for deprecated APIs to locate clients