Opsview Community 3.11 - Free distributed monitoring
One of Opsview’s great features is distributed monitoring, which we’ve had for over 5 years now. From the web user interface, you can assign hosts to a slave system and Opsview will take care of all the configuration work for you: from the slave configuration files, to the slave results sent to the master, to the master configuration with freshness checking.
We do all the system integration work, so you don’t have to.
There are a number of ways you can monitor the progress of your Grails build: using the Hudson / Jenkins web app; or leveraging the API: from your IDE, bespoke API clients or even your enterprise monitoring client. We’ll look at all of them here and build a simple Grails taglib to display build status in the ‘Application Status’ panel.
The JNRPE server provides an open source Java implementation of the Nagios Remote Plugin Executor (NRPE). This is much more efficient for performing JMX checks than regular NRPE as you only need to start one JVM rather than a JVM instantiation per check (as performed by check_jmx invoking java -jar JMXQuery.jar).
I thought it might be interesting if I provided some insight into how we decide which features are included in each Opsview release cycle.
With Opsview, we’re always looking at how to improve performance. We have some users with really large systems, so getting the best out of Opsview is imperative to the user experience.
One thing we’ve done is to create post reload helper tables. As all status data is stored in a MySQL database – and our status views need to query the database – this is one part that needs to work fast and efficiently.
We tried some initial queries to get summarised status data across 10000 services, grouping results by host groups and separated out into handled and unhandled services. This used to take 30 seconds to run, which is clearly unacceptable. With our helper tables, this reduced the query time down to 0.4 seconds! Continue reading »
So, what’s up in the Opsview’s world?
We’re comparing APIs. A user was asking how Opsview’s API compares to Icinga’s API. We spent a bit of time investigating what the competition are up to.
This post is based on research we’ve undertaken to develop a pilot mash-up style, charting dashboard for our monitoring solution, Opsview Enterprise. However the concepts we discuss could be used when building a dashboard that displays information from many other enterprise solutions. The assumption we make is that the reader is familiar with Java and the Google Web Toolkit (GWT). For more information about GWT and the other libraries used in this blog please see the Resources section at the end. Continue reading »
Back in October 2008, Opsera acquired Altinity on the strength of the Opsview product and our customer and user base. It was a great marriage as Opsera were providing IT consultancy and wanted to expand into products, of which Opsview is now added with Ops Mail Manager. And there are some really smart people working at Opsera, which is always a good thing!
Opsview is a leading Open Source application and network monitoring suite. Labs is where our engineers discuss new projects, new approaches and new frameworks they’re using.
If you want to find out more about Opsview visit our corporate site.
Opsview documentation can be found on our Wiki
To get our latest updates, follow us on Twitter, sign-up to the Labs RSS Feed, join us on LinkedIn or like us on Facebook
Opsview and the Open Core Model
Opsview is the award winning Open Source application and infrastructure monitoring software from Opsera. It provides comprehensive system management capabilities used to monitor the health of today’s most complex data centres.
Opsera have recently adopted an Open Core business model for their Opsview software. This article explains why we decided to take this direction and the benefits to Opsview customers.
Continue reading »