Ahh! Somehow I missed that Cassandra is already using the OSHI dependency. I will check and get back to you shortly about the questions.
On Sun, Nov 16, 2025 at 4:38 PM Štefan Miklošovič <[email protected]> wrote: > More context here: > > https://issues.apache.org/jira/browse/CASSANDRA-16565 > > On Sun, Nov 16, 2025 at 11:58 AM Miklosovic, Stefan via dev < > [email protected]> wrote: > >> 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 >> >
