Thermostat/Why

From IcedTea

Jump to: navigation, search

Thermostat has been designed from the beginning with scalability and extensibility in mind. Let me talk about scalability first.

We support collecting monitoring data from potentially many individual hosts to a single repository of information. This immediately allows a client user to easily monitor multiple hosts simultaneously. But the really compelling reason for this is so that we can eventually implement monitoring data analysis that integrates data from multiple hosts. The idea here is to help identify and diagnose issues that result from interactions between system components that do not reside on the same machine. At this stage I must confess we have not implemented such features. But, when we begin to implement things like this, we would like it to work just as good with a system involving hundreds of hosts or more, as it does with two workstations on a LAN, or within a single machine. Actually, this philosophy extends to all of Thermostat development, not just those features that examine interactions between hosts. When researching existing Java tools, we did not find one with a design supporting this.

A big part of development on Thermostat at this stage is centred around API. It should be relatively painless for anyone to add custom monitoring data collection to Thermostat, and add views or command line interfaces to access that data. In this sense, Thermostat can in be looked at as a framework rather than just a tool unto itself. In the long run, we aim to include collectors as part of the core of Thermostat that cover the stack vertically (from OS to JVM to middleware to application), and this view of thermostat as framework will help us get there. Already we do present some information about the host system; so it is not only a JVM monitoring tool, but a system monitoring tool with the goal and focus of examining the behaviour and health of the Java processes running on that system. Perhaps an example of the type of stuff we might have in mind; if some process being monitoring is observed to do more i/o waiting than expected, then we would like to be able to examine this from the perspective of the application, maybe some framework application is using, the JDK networking libraries, and of course the OS networking stack. Our goal is to allow a user to do all of this from within one tool.

Personal tools