Hi, we are using OSHI in Cassandra already. Check for example org.apache.cassandra.utils.SystemInfo and where it is used.
I do agree that this library is helpful. However, I think we should spend some time here to decide if we want to introduce this to Sidecar. What I would like to see is to have the current library in Cassandra utilised way more than it is now and we might just call some MBean method in Cassandra from Sidecar to get the information and eventually maybe expose it in the form of an endpoint if required. I think that if we enrich current SystemInfo in Cassandra, Cassandra itself might benefit from it in the future and make decisions based on that. If we delegate this to Sidecar only then we will lose the ability of Cassandra to "govern" and inspect the machine it runs at. There is nothing wrong with exposing the information Cassandra collected to Sidecar if Sidecar is interested in it. When Sidecar is running, it basically needs running Cassandra, running Sidecar alone without Cassandra is pretty much pointless, if I exaggerate. So there will be always a way how to get this information from Cassandra, no? Regards From: Venkata Harikrishna Nukala <[email protected]> Date: Sunday, 16 November 2025 at 10:00 To: [email protected] <[email protected]> Subject: [DISCUSS] Adding oshi-core dependency for system information to Cassandra Sidecar project EXTERNAL EMAIL - USE CAUTION when clicking links or attachments Hi devs, I'd like to propose adding the oshi-core library to the Cassandra Sidecar project for collecting system information. This information can be useful to operate Cassandra clusters better and can help capacity planning and operational troubleshooting. With CASSSIDECAR-366<https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CASSSIDECAR-366__;!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQzqv2VBkg$>, proposing to expose disk information via Sidecar that can help capacity planning. While CASSSIDECAR-366 focuses on disk metrics as the initial use case, I believe this dependency provides valuable capabilities we can leverage over time. Here are more details What is oshi-core? OSHI (Operating System and Hardware Information)<https://urldefense.com/v3/__https://github.com/oshi/oshi__;!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQztLP7L-g$> is a cross-platform JNA-based Java library for retrieving system and hardware information. It does not require the installation of any additional native libraries and aims to provide a cross-platform implementation to retrieve information including: * Disk/filesystem metrics (initial use case) * CPU utilization and load averages * Memory and swap usage * Network interface statistics * Process information * System uptime and boot time Why oshi-core instead of JDK's FileStore? JDK's FileStore API lacks mount point information - you can't tell which device (/dev/sda1, /dev/nvme0n1) corresponds to each store. This could be crucial from the operational perspective. This library provides information that JDK does not provide. oshi-core dependency analysis: * It supports Linux, MacOS, Windows & UNIX based platforms (AIX, Solaris, etc...) [ref<https://urldefense.com/v3/__https://github.com/oshi/oshi?tab=readme-ov-file*supported-platforms__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQx5cUqaPQ$>] * It internally uses the JNA library to interact with native OS. JNA supports all major processor architectures including x86, amd64, aarch64 and others [ref<https://urldefense.com/v3/__https://github.com/java-native-access/jna/blob/0deb54b46dc04f655e3c1d46e848fd26bf47c09a/native/Makefile*L10__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQxqcevCbA$>] * Cassandra is already using the JNA library * Found that Apache Flink is using oshi-core for system metrics [ref<https://urldefense.com/v3/__https://github.com/apache/flink/blob/master/pom.xml*L591__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQx4Ne8MGQ$>] [ref<https://urldefense.com/v3/__https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/metrics/util/SystemResourcesMetricsInitializer.java*L37__;Iw!!Nhn8V6BzJA!VNznqGtwsvYh8uy6mXtiRRQseGmidmfH8o1zCktKDMsWSCI_nFAo2hqiKdlYtFrjITudINAs5HYF6T-FpmbD26F-CQwGQge3Pg$>] * Uses MIT license I propose we add oshi-core 6.9.1 as a dependency to Sidecar. While we're starting with disk metrics (CASSSIDECAR-366), this positions us to add other system information endpoints as operational needs arise. Any thoughts or concerns? Thanks! Harikrishna
