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
>

Reply via email to