RFR: 8289711: Add container configuration data to mbeans [v2]

[Alan Bateman]

On Mon, 11 Jul 2022 09:30:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API?  I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management).
>
>> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR
> 
> It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any.
> 
> I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute.  There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported".  So I think there are a few things to think about there. 
> 
> Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing it here as something that could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad.

> @AlanBateman OperatingSystemMXBean makes the CPU and Memory related information for a process available regardless of whether that process is running in a native operating system environment or a containerized environment. It does not provide container configuration information such as its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be useful for monitoring and troubleshooting purposes.

Yes, I know this but I think there is a lot more thought required before deciding to augment this with another API for the container environment. There are a couple of things to explore.

-------------

PR: https://git.openjdk.org/jdk/pull/9372