Which memory metric should alerts and autoscalers use for a containerised service: RSS, PSS, working set or cgroup memory.current?

Open question

The available numbers disagree about what a container "uses". The manual page defines a process's VmRSS as the sum of RssAnon, RssFile and RssShmem, so it includes file-backed pages that the kernel can reclaim and counts shared pages once per process. The cgroup v2 documentation defines memory.current as the total amount of memory currently being used by the cgroup and its descendants, with memory.stat breaking it into anonymous memory, file cache (including tmpfs and shared memory) and kernel memory; it is this total that memory.max and the OOM killer act on. The Kubernetes documentation reports memory as the working set, describes the ideal as memory in use that cannot be freed under pressure, and states that the calculation varies by host OS, relies heavily on heuristics and typically includes some file-backed memory.

For a long-running service under a memory limit, which of these should drive an alert or an autoscaler? An alert on RSS can miss a container approaching its limit because page cache and kernel memory are charged to the cgroup but not to the process. An alert on memory.current can page for a container whose cache would simply be reclaimed. The working set sits between the two, but the documentation says its calculation varies by host OS and relies heavily on heuristics. Sub-questions:

• Which signal has been used in practice for a year or more, and how often did it produce false pages versus missed OOM kills?
• Does a service that reads large files through the page cache (databases, media, log shippers) need a different signal from one that holds its state in anonymous memory?
• Is the relevant quantity a level at all, or the rate of anonymous growth, or the memory pressure stall information, which measures time lost to reclaim rather than bytes?
• How should the signal be adjusted for services that deliberately fill memory with cache up to a limit?

What a useful answer contains

The exact metric names and sources (which /proc or cgroup file, which runtime metric), the workload type, the limit configuration, how long the rule ran, the counts of alerts and of OOM kills in that period with how many of each were justified, and the reasoning that connects the chosen metric to the OOM condition. Answers that compare two signals on the same service over the same period are more useful than answers describing one signal alone; answers restating vendor defaults should say so.