oshi and distant system monitoring

[afnanRhy]

Hello, I am Computer Engineering's student , as part of my end of study internship, I need to make a application to supervise a System (CPU, Memory, Disk)
I checked OSHI Librerie , What I'd like to know is if I can supervise a machine remotely from a set of information provided (port, IP ...) Can you give me a track to succeed my task,

[dbwiddis]

OSHI can monitor a local computer but it is not set up to be accessed remotely.

There are other libraries available that you could hook in to OSHI to record the values you need and make them available on a webserver or other port.

You could use JMX to set up a port, or use another library that is already set up to do that. One I have looked into is the Metrics library at http://metrics.dropwizard.io/3.1.0/

[hakanai]

I have been independently thinking it would be handy to have all the OSHI information available in JMX. Probably not as part of the OSHI project, but a separate module like oshi-json.

We use JMX as part of our system diagnostics dumps and having more information about the computer where a problem is happening is always better. :)

[dbwiddis]

Well, it's a long-term goal to integrate OSHI with Metrics (oshi-metrics module) which does that. Won't get to it for a while, though, so if you're interested in taking that task on sooner, we'd love the help. For an idea on what it'd look like, check out https://github.com/cb372/metrics-sigar

[dbwiddis]

Just for fun I did a simple test of getting OSHI info to JMX using Metrics.

import com.codahale.metrics.Gauge;
import com.codahale.metrics.JmxReporter;
import com.codahale.metrics.MetricRegistry;

import oshi.hardware.CentralProcessor;
import oshi.hardware.HardwareAbstractionLayer;
import oshi.util.Util;

public class Metrics {
    public static final MetricRegistry METRICS = new MetricRegistry();

    public static void main(String[] args) {
        SystemInfo si = new SystemInfo();
        HardwareAbstractionLayer hw = si.getHardware();
        CentralProcessor proc = hw.getProcessor();

        METRICS.register(MetricRegistry.name(Metrics.class, "test", "oshi.hardware.processor.cpu"),
                new Gauge<Double>() {
                    @Override
                    public Double getValue() {
                        return proc.getSystemCpuLoad();
                    }
                });

        final JmxReporter reporter = JmxReporter.forRegistry(METRICS).build();
        reporter.start();

        Util.sleep(100000);
    }

}

This sets up a JMX MBean ... here's a jconsole screenshot.

You can set this up for remote JMX by starting the above class using:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=12345
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

[hakanai]

I took a quick stab at trying to do this one the way I wanted it to work, where I can browse all information and not just gauges. Although I do see the point of gauges, for my own purposes, a tree dump of the entire bean structure would be perfectly OK and I don't care whether a given value can vary or not, only what it is right now.

Attempt 1: Just wrap up SystemInfo up and see how far JMX can introspect inside it. It gets as far as Enumeration (which is inside a NetworkInterface, which in turn is inside a NetworkIF) and dies. It seems like there is some kind of type conversion going on and I can't quite figure out how to override it without customising the conversion for the entire hierarchy.

Attempt 2: Stub out HardwareAbstractionLayer to see whether just OperatingSystem works. This version successfully starts up, but then when I go browsing, I can't get the data out, and no errors are being thrown from anywhere, so I can't see why it has failed.

But looking at the structure these sorts of approaches result in, it isn't great anyway. It winds up looking like this:

• oshi (a folder)
  
  
  
  • SystemInfo (a bean)
    
    
    
    
    
    • Attributes
      
      
      
      
      
      
      
      • OperatingSystem
      
      
      
      
      • Hardware
      
      
      
      
    
    
    
  
  

And then presumably the entire rest of the structure is inside the right-hand pane of JConsole. So it's not like I can navigate the structure as a tree using the left-hand pane.

I guess I'm going to have to think about how to best represent it. Maybe a better way would be:

• oshi (a folder)
  
  
  
  • SystemInfo (a folder)
    
    
    
    
    
    • HardwareAbstractionLayer (a folder)
      
      
      
      
      
      
      
      • NetworkIF-0 ...
      
      
      
      
      • NetworkIF-1 ...
      
      
      
      
    
    
    
  
  

I think that to get this, each thing directly underneath the HAL has to be a separate MBean. This makes it fiddly though, because at runtime the number of network interfaces might change, and there is no way to get notified about that happening.

So I dunno, maybe it's just Too Hard to hook all this in. Or at least too hard for a quick Friday afternoon attempt.

[YoshiEnVerde]

Why not just use oshi-json? I mean, it's right there, implemented and working.

You would just need to wrap the output from that module inside whatever protocol/framework you want to use for remote access.

JMX? Just create one single element, something like "OshiJsonFullDump" and drop the whole JSON string in there.
Then, on the other side of the remote access, you grab that string, parse the JSON out and do whatever magic you want on in

[dbwiddis]

Agreed that if you only want a single value you should just stick JSON in an attribute.

My intention for Metrics was (is, if I ever get to it) to have historical averages available... producing a graphical view like task manager, etc.

[hakanai]

The reason I want to build on existing JMX is twofold:

1. The rest of our own system diagnostics stuff already pulls from JMX.
2. People using JConsole will complain at me, saying that they shouldn't have to parse JSON while using a GUI.

I might still build on oshi-json because it has done some of the hard work of breaking things into a tidier tree structure, which I would otherwise have to reimplement.

As far as getting the tree to look right, I managed to do this:

server.registerMBean(new Dummy(), new ObjectName("oshi:00=SystemInfo,01=Hardware,02=ComputerSystem"));
server.registerMBean(new Dummy(), new ObjectName("oshi:00=SystemInfo,01=Hardware,02=ComputerSystem,03=Baseboard"));
server.registerMBean(new Dummy(), new ObjectName("oshi:00=SystemInfo,01=Hardware,02=ComputerSystem,03=Firmware"));

And JConsole will nest it like this:

• oshi
  
  
  
  • SystemInfo
    
    
    
    
    
    • Hardware
      
      
      
      
      
      
      
      • ComputerSystem
        
        
        
        
        
        
        
        
        
        • Attributes
        
        
        
        
        
        • Baseboard
          
          
          
          
          
          
          
          
          
          
          
          • Attributes
          
          
          
          
          
          
        
        
        
        
        
        • Firmware
          
          
          
          
          
          
          
          
          
          
          
          • Attributes
          
          
          
          
          
          
        
        
        
        
        
      
      
      
      
    
    
    
  
  

So the dynamic stuff is the only open issue with implementing this at the moment... if a network adapter appears dynamically, I'd want an additional node to appear. I guess I could run a timer...

[dbwiddis]

I'd be very interested in your comments on #310 and the design of the next version and how it can support the model you're using.

[hakanai]

The idea of an update() method would be an OK model for the direction I'm going in, since it would allow for (potentially) the number of sub-nodes to change, if called at the top level. If I end up going with oshi-json then I'll probably update the entire tree and then ask for the entire JSON tree, and then merge the changes into my local JMX tree, creating/deleting beans to match.

For the bean's attributes I would just have it update every time someone asks for the data for that bean, so the caller chooses.

For the sub-nodes, JMX doesn't appear to have any kind of way to dynamically get the children of a node (or rather, it doesn't really have the concept of sub-nodes at all - it's a flat hierarchy where the client is rendering it to look like a tree), so whatever I do to integrate with JMX will probably have to be done by way of a timer anyway.

That is, unless OSHI eventually gets some kind of event listeners to listen for changes at each node. Event listeners seem like the perfect fit, since I could register new beans in response to the event. But implementing a way to detect changes is hard stuff which is going to be different per-platform and maybe not worth the work.

[dbwiddis]

I hope you'll consider contributing your code to the project when you're done!

[hakanai]

That's the plan If I can get it to work. Deliberately chipping away at it outside work hours. :)

[arikbidny]

I tried matrics and still cant connect to remote computer,
what the default port of jmx ?
I need a user name and password for connection ?