Apache Solr is an open source enterprise search service from the Lucene project. Solr is written in Java and runs as a standalone full-text search server within a servlet container such as Tomcat.

Like any service or component in your architecture, you’ll want to monitor it to ensure that it’s available and gather performance data to help with tuning.

In this post, we’ll look at how we can monitor Solr, what performance metrics we might want to gather and how we can easily achieve this with Opsview.

A check list for service checks

Solr is built on Lucene so follows the same layout, an index contains documents that are comprised of fields. As part of the search service value add over Lucene, Solr provides a number of useful ways of obtaining health status / monitoring metrics:

1. Health-check status using the /admin/ping handler
2. The admin statistics page /admin/stats.jsp (XML styled with XSL)
3. JMX MBeans

The list of applicable checks could be defined by whether it is a health check or a data gathering check – but this would lead to a lot of overlap. Instead the list is divided into the checks that can be performed remotely (without an installed agent on the server) and those that are best performed locally to the Solr server.

Remote (agent-less) checks

What should we look for over the network?

Firstly we can have a host-level check which may perform a network level ping. Next we can check TCP connectivity to the servlet container port and then make an HTTP GET request to the Solr ‘front page’ and check for a known string (e.g. Welcome to Solr).

Now we’ve made it up to the application layer so can start to perform Solr specific checks.

Items to monitor may include (delete as applicable):

1. Ping status
2. Number of docs
3. Number of queries / queries per second
4. Average response time
5. Number of updates
6. Cache hit ratios
7. Replication status
8. Synthetic queries

Agent-based checks

Installing an Opsview agent on the Solr server means we can run additional checks over NRPE (Nagios Remote Plugin Executor). This could be operating system level checks such as memory/disk utilisation or CPU load, or the following:

1. Java servlet container process is running
2. JMX checks e.g. heap memory or custom MBeans
3. File age
4. Log parsing for exceptions

The Solr wiki describes how to configure JMX support: http://wiki.apache.org/solr/SolrJmx.

Opsview configuration

For the rest of this article you’ll need to have Opsview installed (or the Opsview VMWare appliance) and have completed the Quick Start.

Solr-specific Plugin

Install the Solr plugin at https://github.com/rbramley/Opsview-solr-checks into /usr/local/nagios/libexec/

The check_solr plugin was developed using Perl, so that it could be contributed back to Opsview. It requires the CPAN XML::XPath module (sudo cpan -i XML::XPath).

The plugin includes usage instructions, check_solr -h which can also be viewed in Opsview by selecting the ‘Show Plugin Help‘ link beneath the Plugin drop down (see Figure 1). The -u option can be used to specify the URL path for multi-core set-ups.

Service check setup

Figure 1 gives an example of a service check configuration.

Figure 2 shows the agentless service check group with plugins and their arguments.

Host configuration

Figure 3 shows a simplistic host setup with a ping check.

Figure 4 is an extract from the Monitors tab, where we select the checks we want performed for the current host.

Viewing output

The check results shown in Figure 5 are visible by navigating through the host group hierarchy.

If you click on the graph icon of Solr Cache Hit Ratios this will drill down onto the graph shown in Figure 6.

Clicking on the graph icon for Solr Avg Response Time – standard will take you to the graphs in Figure 7.

If you shutdown Solr, then the check results will start to turn critical and show in red as per Figure 8.

Alternatives

There are a few other plugins available for monitoring Solr from Opsview, depending on your needs:

• http://code.google.com/p/nagios-plugins-shamil – provides ping, replication status and num docs
• http://code.google.com/p/solr-nagios-check – provides QPS, response time and num docs

Also, chapter 8 of the recently published Apache Solr 3 Enterprise Search Server book includes a section on Monitoring Solr Performance.

Summary

Using check_solr in conjunction with Opsview allows you to ensure that your Solr server is available and provides you with metrics that can help you tune your Solr configuration.

This can be complemented with additional agent-based operating system and JMX checks to give you a full picture view.

Not all open source IT monitoring systems are made equal. Just as IT infrastructures vary according to the size, location and type of business, so the systems that monitor and report on their performance must be flexible, easy to scale and configure to meet the demands of an ever changing business.

Opsview gives you the edge with open source monitoring by offering an easy to install and configure system that delivers enhanced functionality in a highly scalable, commercially supported system.

If you’re replacing your existing monitoring solution, or evaluating systems for implementation, here are 10 reasons why you should consider Opsview:

1. Flexibility

Opsview’s open source monitoring system is designed with ease of use and flexibility at its heart. Based on Nagios® Core, the installation, configuration and upgrade to Opsview doesn’t require highly specialised knowledge or additional investment into expensive specialist hardware or integration skills. It is essentially an enterprise IT window onto performance and availability, watching hosts and services, alerting users to problems or issues and allowing them to track their resolution.

2. A Single Tool for Monitoring all Environments

IT environments are becoming increasingly diverse with a mix of physical, virtual and cloud environments as IT departments continually strive to do more with less. Using a mix of proprietary IT management tools to monitor these environments causes unnecessary complexity which could lead to slower fault resolution times and hamper overall monitoring effectiveness. Opsview delivers a ‘single pane of glass’ view across this mix of layers, hosts and components helping ensure IT SLAs are met and keeping costs down by removing the need for multiple software licences or subscriptions.

3. Direct Access to Source Code

As an open source developed suite, and unlike more expensive proprietary alternatives, Opsview allows end users direct access to the source code, enabling IT departments to make changes to the root system. This enables a business to optimize individual IT monitoring requirements, for instance, tweaking status views so that they can be graphically represented in a way that delivers meaningful, at-a-glance information depending on the level of detail required.

However, considering how much pressure IT budgets are under nowadays, most enterprises don’t want to use their own in-house software engineering staff to tinker with the source code of third-party applications. So Opsview Enterprise edition includes software maintenance to ensure you receive critical software fixes quickly and with minimum disruption to business.

4. Strength in Numbers

Where proprietary software development is closed to all but the biggest enterprise customers, the Opsview community lies at the heart of our development model, supporting over 15,000 users. Their feedback is invaluable when developing and refining new features that continuously improve the suite. The variety of different environments monitored by the community enables the identification of the widest range of problems possible before any code is certified for inclusion in Opsview Enterprise edition.

5. Open Platform

Opsview is an open source application that encourages tight, two-way integration with other systems such as ticketing and help-desk consoles. In doing so, Opsview offers a cost-effective way to upgrade your core monitoring and performance management capabilities with minimal disruption to existing procedures and processes.

6. Easy Migration from Other Systems

Another key consideration for the value of any IT monitoring system is not just only how easy it is to use, but also how simple it is to take on in the first place. That’s why Opsview makes migration easy. The use of standard frameworks such as Catalyst and Perl DBI make development straightforward and developer documentation supported by the strong open source community is freely available online. Opsview’s integration and compatibility characteristics mean you don’t have to replace existing monitoring agents and that it will work with existing plug-ins. That way you don’t lose any of the value already invested in existing monitoring capabilities – you enhance and strengthen them.

Opsview also provides APIs for system configuration, monitoring data re-use, and the automatic population and update of host information. This is particularly useful for integrating Opsview Enterprise edition with other IT management tools.

7. Lower Costs

The open nature of Opsview locks down cost because your IT department is not supporting unique versions, nor is an army of consultants required to just carry out an upgrade. It also means display of system status information on everything from a company intranet or website, to the publishing of performance and availability metrics on a customer portal is possible from a single monitoring solution rather than multiple point solutions generating siloed reports and metrics.

8. No Vendor Lock-In

As well as on-going licence fees, using proprietary software often means being ‘locked-in’ with the vendor with no option to customize the software to fit your needs. Opsview gives you the flexibility and control of a home-grown system, perfectly tailored to your needs, but with commercial support, development roadmap and community feedback platform.

9. Field Tested for Monitoring Complex Infrastructures

Opsview is used in all types of monitoring environments because it’s easy to install and configure and delivers an open platform with a large, active community of contributors and enthusiasts. However, mission critical business applications and services demand high performance and availability. This is where Opsview Enterprise edition comes in to its own. From Airports to Banks, Service Providers and even the Military, Opsview Enterprise stands its ground in the most rigorous monitoring environments. With integrated redundancy, high availability and scalable architecture, Opsview Enterprise edition is designed to help organisations toward uninterrupted business operations.

10. Fair Pricing on Commercial Products

Unlike proprietary solutions, the commercial version of Opsview offers entry points for all types and sizes of business. SME and large enterprise IT estates can get professionally supported, total monitoring coverage for disparate systems without having to part with hundreds of thousands a year for the privilege.

Discover Opsview today – download Opsview Community edition or view a live demo of Opsview Enterprise edition.

Setting up distributed monitoring in mission critical production environments is a complex task; configuration can be challenging and mistakes costly. Opsview Enterprise edition and Opsview Syncmaster module make deploying an enterprise monitoring system easy and reduce the risks associated with migrating configuration objects from development to production environments. Here’s how:

1. Get everything done in one place

Opsview’s configuration User Interface makes it quick and easy to get things done.  Any configuration you need to make is carried out in one place, no jumping between screens or applications required. All the complex processing is kept ‘under the hood’ so you can focus on what’s important to you – configuring your monitoring environment the way you want it.

2. Maintain consistent configurations with host templates

Templates in Opsview can help you maintain consistent monitoring configurations throughout your system.  Pre-defined templates are included for many hardware, operating systems and applications such as Cisco kit, Drupal CMS or the MySQL database.  Any changes you make to a template will affect the whole configuration, giving you a quick way to make consistent, controlled changes to your distributed monitoring system.

3. Reduce configuration errors with cloning

In Opsview you can quickly configure identical objects by using the clone function. In large environments chances are you will have lots of identical pieces of equipment such as network devices. Rather than having to manually enter configuration information for each one you can simply clone an existing device as many times as you need, saving time and reducing errors.

4. Speed up configurations with embedded SNMP capabilities

Opsview’s embedded SNMP polling and trapping detects SNMP interfaces so you don’t have to. This takes away much of the time consuming configuration involved with a complex distributed monitoring system and reduces the chances of input errors which could, in some other systems, cause a malfunction.

5. Manage complex configurations with attributes

Attributes In Opsview help you maintain checks on complex configurations. Instead of configuring service checks for individual hosts you can create one check and use attributes to carry out checks on each host.  For example you might want a check on VMhosts which could be running 20 or 30 virtual machines. With attributes you can set up one service check on a guest VM and use attributes to reference all the virtual machines on the host.

Find out more about setting up attributes in Opsview.

6. Get Notified

Notification profiles help you keep on top of your distributed monitoring by making sure your team get the notifications they need when they need them.  You can decide who gets notified, why they get notified and how. For example you can set up your profile to get e-mail notifications during normal working hours if your system is in a warning state, but for more critical notifications, such as a system outage, an SMS can be sent to an onsite-engineer.

7. Get industrial strength change management with Opsview Syncmaster

Opsview Syncmaster module helps you follow change management procedures and takes away the risk of errors caused by untested system configurations. With Opsview Syncmaster you eliminate costly downtime and speed up system configuration, all from one single point of control.

8. View status and configure hosts

Start off by using Opsview Syncmaster to see which hosts are being monitored. From the Opsview Syncmaster interface you can see detailed summary information about your monitored systems, such as current status, which slave servers are configured for monitoring, if configurations are up to date or even the performance latency of the monitoring system. From here you can also directly access the configuration UI of each host.

9. Easily move objects

Opsview Syncmaster enables you to easily move objects between environments, whether on-premise, off-site, or virtualised, by dragging and dropping from one environment to another, e.g. drag a slave between slave clusters or drag hosts between host groups.

10. Synchronise objects between servers and safely deploy

One of the key strengths of Opsview Syncmaster is the ability to synchronise objects between servers. You can synchronise one or multiple objects, either by using an existing profile or by creating a new one. For example you may have created a new user and want to synchronise the user across all systems or to migrate an application in a test environment across to production. Simply select the source system and the target system and decide which configuration object(s) you want to synchronise.  Opsview Syncmaster then safely migrates the chosen settings between environments with just a click of a mouse.

Find out more about distributed monitoring with Opsview Enterprise edition – check out our Live Demo.

So you followed the steps in the previous post about enabling SNMP traps on ESX4. Now you probably want to pick those up by something useful. Opsview can be configured to handle the traps quite easily. Just follow the steps below and your server will be listening to those pesky traps. After that, you’ll need to write a couple of service check handlers in Opsview to make sense of the traps. More on that later. This post is just about picking them up.

This was done on an Ubuntu 10.04 LTS server. The steps are probably the same on Debian systems.

1. Make sure you have snmpd installed. If you don’t, install it! Easy as pie.

aptitude install snmpd

2. Edit /etc/snmp/snmpd.conf and uncomment “master agentx”.

3. Edit /etc/default/snmpd (or /etc/snmp/snmptrapd.conf on newer systems):

TRAPDRUN=yes
TRAPDOPTS='-t -m ALL -M /usr/share/snmp/mibs:/usr/local/nagios/snmp/load -p /var/run/snmptrapd.pid'
SNMPDOPTS='-u nagios -Lsd -Lf /dev/null -p/var/run/snmpd.pid'

4. Edit /etc/snmp/snmptrapd.conf and add the following lines:

traphandle default /usr/local/nagios/bin/snmptrap2nagios
disableAuthorization yes

Please note that this will make the server listen to and handle any SNMP traps it receives, regardless of source.

5. Restart snmpd and snmptrapd:

/etc/init.d/snmpd restart

6. Edit the /etc/sudoers file to allow Opsview to restart snmpd and snmptrapd:

nagios ALL=NOPASSWD:/usr/local/nagios/bin/snmpd reload

7. Test the permissions:

su - nagios
sudo /usr/local/nagios/bin/snmpd reload

8. Exit back to the root user and restart opsview-web:

/etc/init.d/opsview-web restart

That’s all. Opsview should now be able to handle traps sent to it.

This post outlines how to get SNMP traps from ESX hosts and monitor them in Opsview. The first part deals with configuring SNMP traps to get them working correctly with ESX hosts, part 2 tells you how to monitor them with Opsview.

The following steps worked on ESX 4.1. Depending on versions you may have different results. For simplicity, I used 10.0.0.1 as IP for my ESX host, and 10.0.0.99 for my SNMP trap handler.

1. Download and install the vSphere CLI. Keep in mind that you need an account to access it. Check BugMeNot if you’re not in the mood for registering.

The vSphere CLI will give you a host of useful tools to control your ESX environment with without having to resport to SSH or console access.

2. Check if you already have an active SNMP agent on your host with the following command:

vicfg-snmp --show --server 10.0.0.1

3. If no traps are configured (why would you even be reading this if they were?). Add your SNMP target like this (By default, vicfg-snmp.pl is located in the C:\Program Files\VMware\VMware vSphere CLI\bin directory):

vicfg-snmp.pl --server 10.0.0.1 --username root --password qwerty1234 -t 10.0.0.99@162/communitystring

4. Enable the SNMP service:

vicfg-snmp.pl --server 10.0.0.1 --username root --password qwerty1234 --enable

5. Check that you have a working configuration by using the –show command like this:

vicfg-snmp.pl --server 10.0.0.1 --username root --password qwerty1234 --show

Your output should look something like this:

Current SNMP agent settings: Enabled : 1 UDP port : 162 Communities : communitystring Notification targets : 10.0.0.99@162/communitystring

6. If you’d like, you can send a test trap to your target to make sure you’re on the right path. If you’re just testing, you can send them to your own client PC. I use the freeware application SNMP Trap Watcher for this.

Sending the following command through the vSphere CLI will generate a Warm Start trap:

vicfg-snmp.pl --server 10.0.0.1 --username root --password qwerty1234 --test

You should receive a report in your trap watcher:

If you’re not getting anything, chances are the ESX firewall isn’t allowing SNMP traffic. I had to allow this using the vSphere Client (connect to the ESX server, not a vCenter host). Click the tab “Configuration”, and select “Security Profile” in the menu on your left. Click “Properties” and enable SNMP:

The outgoing port will be the one you configured when you added a trap handler in step 4.

That’s it. You have an ESX host sending SNMP traps properly. Now all you need to do is get your monitoring software to understand what it’s saying. We’ll cover that in the next post.

Alerts happen. They are the reason why monitoring applications were created: to alert us when servers need attention. The difference between an effective network monitoring system and an annoying one is a fine line between information and noise. Alerts should be descriptive and prompt an administrative action, not elicit a huff of frustration. Here are a few ways to keep your Opsview installation (and you) effective and relevant in your company.

Use a Smartphone

A smartphone should be a tool on every system administrator’s bat belt. The more mobile you are, the more time you spend away from the Operations Center. Why not take Opsview with you? With Opsview Mobile for Android, you can do just that. There is an ambitious roadmap to the mobile app including support for other devices, but if you have an Android there is no reason to wait getting it installed.

The app handles basic needs very well, including a real-time overview of all hosts and services and alert acknowledgement. If you are away from the office (like at the beach!) and get an alert on your phone, acknowledge it and then make a call to your backup (hopefully you have one!) who can begin corrective action. If you don’t have a backup, you at least have a heads-up to an issue at work and can go back to sipping a drink from a coconut.

Use a Real Email Address

Create an email address that can be dedicated to your mobile. For example, create a Gmail address and configure your smartphone for an audible notification on new messages to that address. Smartphone text messages don’t give you the entire story, only a few characters to let you know a host or service is having a problem. There may be more to it that is detailed in the Additional Information section of the alert. A disk utilization error of 95% may be something that can wait until you get back to your office to debug where as 100% would prompt you to boot your laptop to resolve as soon as possible. The only way to know is to have all the alert information in hand (literally).

Modify Alert Templates

The more information you put in the alert, the better chance you can delegate action. Modify the default alert templates to include more information that can help other people, such as a help desk, route tickets more effectively. Since Opsview has Nagios under the hood, all Nagios macros are available. (A complete macro list can be found on Sourceforge.

An example would be inserting comments using the Opsview UI on a host group or individual host, then changing the template to include the macro output for $HOSTGROUPNOTES$ or $HOSTNOTES$. Comments could include where to route tickets or links to documents to solve common problems that first level support can handle. If the issue to too complex, level one support will know which direction to escalate the ticket. The default template is located in /usr/local/nagios/libexec/notifications/com.opsview.notificationmethods.email.tt.

It’s a good idea to keep a backup of any changes you make since the file will be overwritten with each Opsview upgrade.

Set up Layered Email Profiles with Time Periods

The rub with any server monitoring system is no one wants a critical alert at three in the morning, but proper administration can’t be done without notifications. Administrators should embrace alerts, specifically warning alerts since they allow for proactive work to be done preventing critical alerts. That being said, no one wants a warning alert at three in the morning. Fortunately, each Contact in Opsview can have multiple Profiles which can have different layers of alerts. For your work email, create profiles for warning and critical to be sent 24×7. For your Gmail that your phone accesses, create profiles for warning alerts 8×5 and another profile for critical alerts 24×7. Be sure to name your profiles logically for easier administration, such as EmailPhoneWarning or EmailWorkCritical.

Send Alerts to Host and Service Administrators

An IT shop may have specific administrators, such as Windows or Linux admins. Windows administrators may not care to get alerts when Apache is down and Linux admins may not want to be woken up because a Windows server blue-screened.

Digging deeper into the Contact Profile, notifications can be set up for Host Groups and Service Groups. Configure each user to get alerts for their responsible services. Anytime someone gets an alert that they ignore because it is someone else’s responsibility, noise is created and alerts are assumed and disregarded, lowering the value of the entire monitoring system. If you want people to feel your pain, correct the issue and send out an email to work addresses that you were up all night dealing with your problem. It’s not a bad idea to show people that the system is working as it should, notifying only the responsible parties of critical issues (plus it gets you off the hook for coming in late the next morning).

Test New Checks Before Enabling Notifications

New checks are rolled out constantly in a changing environment. But new checks put immediately in production may produce false alarms that annoy other administrators and the help desk. Since Opsview includes built-in features to help monitor and trend check results, every addition should go through a testing period with notifications disabled. After a week, check the Service Graph to find the highest and lowest values to appropriately tune warning and critical thresholds.

Using the Alert Summary, you can determine if time periods should be used for a check. For example, a service may become unavailable during a nightly backup. The check_interval must remain the same, but checks need to be suspended for two hours each night while the backup occurs. You will be able to confidently tune the time period rather than make an uninformed guess at a black out range. Making accurate adjustments before a check “goes live” with notifications enabled greatly reduces unnecessary alerts and allows administrators to maintain faith in the system.

Find out more about Opsview alerts.

Over the last couple of years we have seen an increase in port-density on server-hardware and currently the quad-nic (4 port network interface card) seems to be the standard. These cards allow for some great features like bonding (on *nix) or nic-teaming (on Windows) where multiple interfaces are bundled together or setup as fail-overs. It also allows you to nicely split your networks into multiple segments like management and production with each network connected over dedicated NICs as shown below…

However, this does pose the question which network should we use to monitor our hosts?

As always we need to consider the users point of view so we need to monitor the services used by our customers using the production network (web-interfaces, SQL etc).

But we also need to monitor our management services (like ssh, NRPE etc).

Therefore, our objective is to come up with network monitoring model to determine which service-checks will run over our production network and which will run over the management network.

Prerequisites

Ensure you have the following:

• 1 x Opsview Master (or Slave) connected to both (or more) networks.

Step 1

Create a monitoring model in which you divide your host into smaller chunks.

These chunks (or building blocks) represent the various parts of the system (e.g. hardware, network, operating system, applications and application interfaces).

Each chunk can then be assigned to either the management network or the production network.

Below is an example on how you can use these chunks to assign them to a network segment.

In this model we have defined that hardware, network, OS and applications (processes) are monitored through the management network (in general any check we use check_nrpe for).

Any check we run to confirm a service is reachable and usable (WWW, SQL etc) will be run over the production network (so we can confirm our customers can reach our services).

Step 2

Update the host to reflect the various addresses it has.

Using the Opsview WebUI go to the Configuration > Hosts and select Action > Create new host.

In the Other Hostnames/IP’s field we can add our other IP’s of FQDN’s (as shown also adding the primary IP is good practice) in a comma-separated list for each IP you wish to assign to this host.

Save the host (later on we will assign host-templates and service checks).

Step 3

Confirm from the commandline that you can reach your host using the addresses listed in the “Other Hostnames/IPs” by running one check for a management service and one for a production service.

Check_nrpe –H primary-ip
Check_tcp –H secondary-ip –p 80 (for a webserver)

Step 4

Set up the service checks.

Now to use the defined “Other Hostnames/IPs” we need to change some of our service-checks.

The easiest way is to clone a check you already use and give it a new name (e.g. SSH to SSH Management).

As you see from the arguments line, the check will run against the macro know as $HOSTADDRESS$ which is the equivalent of the “Primary Hostname/IP”.

To use the “Other Hostnames/IPs” we have to change this to the macro that represents the IP or Hostname we want.

Opsview will automatically place all entries for the “Other Hostnames/IPs” in the macro $ADDRESS1$, $ADDRESS2$ and so on.

In this case we want to use our Primary-IP which we also registered as the first “Other address” so it is stored in $ADDRESS1$. This allows us to change our check to have the following arguments:

Using the described method you can now create service-checks and based on your model assign them to the correct $ADDRESS$ value.

Step 5

Create new host-templates for the checks we created in Step 4 and assign them to your multi-homed host.

Postscript

The “Other Hostnames/IPs” is a very powerful feature in Opsview and there are many things you can do with this functionality (for instance creating inter-host dependencies).

But in case your Opsview slave is not allowed to access the production network due to firewall policies or security restrictions, not all is lost. If you have an Opsview slave in the production network (and one in the management network) you can apply split-monitoring which will be discussed in a later blog-post.

Freeware IT monitoring tools are used by thousands of organisation worldwide however using them to monitor complex network, server and application installations can be quite a challenge. This blog post takes the basic capabilities of one such tool, Nagios® Core, and shows how you can scale it with Opsview for use in enterprise environments.

Distributed monitoring

Building and managing a complex distributed monitoring environment with Nagios Core is no mean feat. With Opsview you get distributed monitoring that’s easy to setup and simple to maintain. You can monitor your devices and applications from a central location and grow the system without growing the monitoring complexity.

Slave server clustering

Opsview can automatically load-balance across multiple slaves and reallocate monitoring duties if a slave server fails, giving you high availability and scalability without additional overhead.

Example Clustering Model

Master server clustering

Management of Opsview is performed on a single master server, however master servers can be clustered giving you the high availability and redundancy needed for mission critical monitoring.

Separate database server

Opsview can be run on a separate database server so you can move intensive reporting activity to a dedicated machine and fine tune the server for better performance.

Efficient configuration UI

Nagios Core is capable of monitoring thousands of devices, but maintaining configuration on expanding systems can quickly become a problem. Opsview handles this with an easy to use interface and middleware layer which tackles the complexity of configuring individual software components.

‘Single pane of glass’ monitoring

Unlike Nagios Core where data may be gathered from a number of systems and presented in different ways, Opsview’s intuitive web interface displays all your monitoring information in one place, with a top down view on system status. Devices and applications can be easily grouped by business process and their status displayed using simple ‘traffic lights’ so you can easily see the health of critical and non-critical groups. This makes monitoring and maintaining large, complex systems less time consuming and more efficient with a scalable architecture to cover all your systems and locations.

Opsview's Host Group Hierarchy View

Distributed alerting

Slave servers monitored by Opsview can handle their own notifications, allowing autonomy if communication is lost between master and slave servers. Alerts can be sent by the Master server or slave server by email / sms so you’re always in touch with the health of your system, no matter the location or your systems.

Automated APIs

Opsview APIs speed up system configuration by automatically populating and updating host information saving you time and effort as your system grows.

Example use cases for Opsview's RESTful API

SNMP trap processing

Nagios Core has no native support for SNMP trap processing. Opsview’s SNMP engine accepts incoming traps, analyses the data and decides how to handle them. In-built SNMP discovery allows SNMP objects to be detected and monitored easily and rules can be configured through the management UI.

Notification profiles

With Nagios Core you can be inundated with monitoring information, not all of it useful. In Opsview you can set-up notification profiles so the right people get the right information at the right time. Only want to know about email server status during business hours? No problem. Need SMS alerts about your webstore? It’s covered. Notification profiles can also combined with Opsview’s service desk module to automatically assign support tasks to engineers, helping streamline incident management.

Many freeware IT monitoring tools are great but using them to manage complex systems can be a real challenge. It can also be unforgiving on anyone less than expert in configuring the system with mistakes being punished by a complete stop in monitoring activity.

Distributed monitoring

Opsview takes the complexities of its core engine, Nagios® Core, and makes distributed monitoring simple. All management is performed on a single master server and communication with slaves is handled by Opsview’s middleware layer. Provision is included for geographically diverse monitoring and to cope with potentially unreliable WAN connections between servers.

Host attributes

A feature you won’t find in Nagios Core, host attributes help simplify configurations by allowing you to create multiple services based on a set of pre-defined attributes. You can assign one or many attributes to a host and set service checks to use the attributes for a host to then create multiple services for monitoring.

Keywords

Opsview’s keyword function gives you a flexible way of grouping hosts and services. You can tag devices, business processes and applications giving you a convenient way of seeing the status of the groups, e.g. critical IT systems, network circuits or business users and customers.

Cloning capability

Chances are when you’re configuring or adding devices and services to your network many of them will be quite similar. To save time you can simply choose to clone an existing device or service monitored with Opsview and add it to the network.

SNMP discovery

Nagios Core provides support for SNMP via its plugin project, but it doesn’t provide support for processing SNMP traps. Opsview does this automatically. A powerful processing engine accepts incoming traps, analyses the data and then decides how they should be processed. In-built SNMP discovery also means SNMP objects can be detected and monitored with ease without the need for human intervention.

Notification profiles

Opsview helps you avoid information overload by easily creating complex business rules that define who gets alerts, how they get them and why. Combined with the Opsview service desk module you get a powerful notification tool that helps speed up mean time to repair and streamline workflows.

Configuration UI

Configuring and maintaining a system with Nagios Core can become difficult the bigger and more complex the monitoring environment gets. Opsview’s configuration UI means you don’t need to be a Nagios Core expert to get your monitoring up and running. All the software processes are kept ‘under the hood’ and presented via an intuitive interface so you can see the information that makes a difference to your business without getting caught up with software.

APIs for Automation

Opsview includes automated APIs for configuration, monitoring and notification which makes system set-up pain-free and scaling simple. The APIs also make integrating with other IT Management tools easy.

SLA reporting

Opsview’s Reports Module can automatically generate custom reports in line with business requirements. If you have to produce regular reports for your management or customers, this module will save you hours by generating the reports you need when you need them. The reports can be sent out automatically on email in PDF, HTML, Excel, ODT or XML to your chosen distribution list.

Service desk integration

When you integrate your service desk with Opsview you get a powerful tool for automating incident reporting. Tickets can be created in your system based on alerts generated by Opsview, saving time and freeing up resources. Out of-the-box support is included for Service-Now.com, Bestpractical’s Request Tracker and Atlassian JIRA.

Hindsight is a wonderful thing.

In hindsight, Opsview would have always had access controls for objects at the role level – since roles also define which parts of the Opsview application you can get to, it would make sense to also put all the host and service objects into this definition.

(In our defence, we wanted to make it as obvious as possible for a contact when you were changing access information.)

The downside of our design decision many years ago is that Opsview administrators who have lots of their users – or contacts in Opsview terms – with the same sort of access and were having to change each user individually. This was painful and error prone if you had 40 “similar” users.

So Opsview Enterprise 3.12.0 now has access information in the role definition. You change access at the role level and it automatically affects all users of that role. Even better, we ensure that a user’s notification profile only has references to the objects they are allowed – change the role definitions and object references will be automatically removed from all aspects of that contact.

Now you can administer users in a much simpler way.

Hindsight – we wish we had more of it.

But the next best thing to hindsight – migratability.

Migratability?

The Opsview configuration database is normalised and models the data as it is. Some application designers like to use key-value pairs to describe their data, which is nice from an expandable point of view, but rubbish when it comes to actually accessing that data in a meaningful way. When it comes to modelling our data, we model it – we don’t “meta-model” it.

We care a lot about people’s data because we build up a trust with our users that they can upgrade and bring their platform right up to date with the latest versions of Opsview. So we spend a lot of time getting the upgrade scripts just right.

If you are upgrading to Opsview 3.12, here’s what the upgrade scripts do:

• for each contact, it will see if this contact’s role has access information applied
• if it hasn’t, it will use this contact’s access information to populate the role
• if the role already has access information (from another contact), then it will compare all the current roles with their access information and if there is a match, this role is used
• if it isn’t exactly the same, then a new role is created called “old role name – contact”

So for example, let’s say you have 4 contacts – John, Paul, George and Ringo – all using the “Liverpool administrators” role.

The first three have their access information the same, but Ringo has missed out the Production – Slicehost Servers host group he should have had access to.

After the upgrade, the first three would still have the role of Liverpool administrators, but Ringo would have the role of a newly created Liverpool administrators – ringo. You could easily tell from this that Ringo should belong to the Liverpool administrators, so you can set him to this. Otherwise, maybe he is different after all, so you can rename the role to Liverpool drummers.

This means that most of the configuration for this new functionality is done for you automatically and you can think of your users in their role groups, rather than individually. Another step to making Opsview easier to use.