For most companies websites are their corporate face to the world. Any downtime can be costly especially if the sites are used for e-commerce. Web monitoring checks can be set up quickly and easily in Opsview giving you powerful alerting capabilities to check on crashed servers, website attacks and more. Here are 10 easy steps to set up website monitoring in Opsview:1. Login to Opsview and Go to CONFIGURATION > SERVICE CHECKS

2. Click on ‘ACTIONS > Create New Service Check’

3. You will see a blank template, ready for you to fill with data. Populate the template with information to create an appropriate service check, in the example below we’ve set it up to warn us when our SSL certificate is within 30 days of expiring.

4. Before adding the check into your template you can test the syntax of your argument on the command line:

nagios@ov-trn-s1:~$ check_http –H www.opsview.com –C 30
OK – Certificate will expire on 04/26/2012 10.23.

5. Once all the data is complete you need to assign the checks to a host. When you’ve got all your website checks setup it’s useful to summarise them in a viewport so that you can easily see all activity in one place. To do this you need to set up a dashboard view for your new checks.

6. Go to CONFIGURATION – KEYWORDS

7. Click on ACTIONS > CREATE NEW KEYWORD

8. Select your newly created service checks.

9. After clicking SUBMIT then RELOADING your Opsview configuration, you will see your website monitors appear on your dashboard.

10. Click through to Website Health Checks. You can change the view to suit your requirements, here we have selected a ‘performance’ view, allowing us to instantly see the key metrics.

Here is the same dashboard, but with a ‘Group by Service’ overview.

Website Monitoring Checks

There are lots of types of checks you can carry out to ensure the health of your website and webservers – here are a few you can try:

Web Server Check

This is checking the web server running on ‘ov-dev-61′. It performs a simple TCP connection on port 80 and ensures a valid HTTP response is received.

nagios@ov-trn-s1:~$ check_http –H ov-dev-61 –w 5 –c 10
HTTP OK HTTP/1.1 200 OK – 316 bytes in 0.003 second response time | time=0.003423s;5.000000;10.000000;0.000000 size=316B;;;0

If the webserver stops working, then we see this response:

nagios@ov-trn-s1:~$ check_http –H ov-dev-61 –w 5 –c 10
Connection refused
HTTP CRITICAL – Unable to open TCP socket

Content Serving Check

This is a really useful check, as it allows you to monitor both potential defacements to your website as well as performing an ‘application’ level check, i.e. ensuring that your webserver is serving meaningful content.

A check of Apache processes sometimes isn’t enough; Apache may be running, but it may not be serving the content you expect. This check addresses that.

nagios@ov-trn-s1:~$ check_http –H www.opsview.com –u /company –s “Based in Reading –w –c 10
HTTP OK HTTP/1.1 200 OK – 41439 bytes in 0.886 second response time | time=0.885759s;5.000000;10.000000;0.000000 size=41439B;;;0

Here we see the result of the check when a string (‘foobar’) is required, but not found.

nagios@ov-trn-s1:~$ check_http –H www.opsview.com –u /company –s “foobar” –w 5 –c 10
HTTP CRITICAL: HTTP/1.1 200 OK – string ‘foobar’ not found on ‘http://www.opsview.com:80/company’

Retrieve In-Time Check

Here’s an excellent monitor to ensure that your website is retrieved within an acceptable time-frame:

[nagios@vader ~j$ check_http –w 2 –c 4 –H www.opsview.com –f follow
HTTP OK: HTTP/1.1 200 OK – 49250 bytes in 0.777 second response time | time=0.777155s;2.000000;4.000000;0.000000 size=49250B;;;0

Find out how to configure Opsview to pro-actively respond to website attacks at our Webinar on 2nd February.

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.

Parenting is one of the many powerful network monitoring tools that can be deployed in Opsview. However parenting is quite often misunderstood or deployed incorrectly causing the intended goal (less notifications when detecting network failures) to be missed and flooding mailboxes with undesirable e-mail alerts. This blog post outlines the steps involved in setting up Basic Parenting in Opsview.

Before successfully deploying parenting it’s important to understand how it works:

1. Parenting is based on host states
2. It determines if a host is DOWN or UNREACHABLE
3. When assigning multiple parents all parents need to be DOWN for the host to be UNREACHABLE
4. Parenting can not be circular

opsview-slave nagios $ traceroute hostA
traceroute to hostA (192.168.1.2), 30 hops max, 40 byte packets
 1  hostA (192.168.1.2)  1.594 ms  0.590 ms  0.362 ms

opsview-slave nagios $ traceroute hostA
traceroute to hostA (192.168.1.2), 30 hops max, 40 byte packets
 1  coreA (192.168.1.1)  0.747 ms  0.582 ms  0.518 ms
 2  hostA (192.168.1.2)  1.594 ms  0.590 ms  0.362 ms

Checking for circular paths between hosts...

Error: The host 'CoreA' is part of a circular parent/child chain!
Error: The host 'HostA' is part of a circular parent/child chain!
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

1. Slave clusters and parenting
2. Multi-homed hosts and multiple parents
3. Circular parent child relationships
4. Common pitfalls for parenting
5. VPNs

Download Opsview Community edition or try out a demo of Opsview Enterprise edition.

This week’s post is a technical workaround, from Opsview Community edition user Matthew White, for anyone experiencing an ODW_Status Warning in Opsview due to heavy server load.

Over to you Matthew…

For a while I have been seeing a daily ODW_STATUS_WARNING about no updates since 03:59:59 on my master opsview server. I was 90% sure this was due to the load that I put on the server (load average sits around 6 and goes up to 13 at certain times of the day) but still got bored of running cleanup_import and then import_runtime -i 1.

I started off by manually clearing out all but 1 week of data from the runtime database (this is run as part of opsview_master_housekeep for various tables) and this didn’t resolve the issue. In the end I modified my cron table so that the rc.opsview cron_daily task runs 30 minutes later (at 41 minutes past the hour instead of 11 minutes past). Since changing that I seem to have had no further re-occurrences of the No update prompt.

I am aware that each time I update Opsview I am going to have to make this change until I manage to move the databases to their own host and rebuild the master server onto new hardware. But its a workaround for now!

For reference the crontab now looks like:

# OPSVIEW-START
# Do not remove comment above. Everything between OPSVIEW-START and OPSVIEW-END
# will be automatically installed as part of an Opsview install/upgrade
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/nagios/bin/mrtg_genstats.sh > /dev/null 2>&1
41 3 * * * /usr/local/nagios/bin/rc.opsview cron_daily > /dev/null 2>&1
22 2,6,10,14,18,22 * * * . /usr/local/nagios/bin/profile && /usr/local/nagios/bin/opsview_cronjobs 4hourly > /dev/null 2>&1
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/nagios/bin/call_nmis nmis.pl type=collect mthread=true > /dev/null 2>&1
34 0,4,8,12,16,20 * * * /usr/local/nagios/bin/call_nmis nmis.pl type=update mthread=true > /dev/null 2>&1
4 * * * * . /usr/local/nagios/bin/profile && /usr/local/nagios/bin/import_runtime -q
# NMIS reports
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day health
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day top10
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day outage
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day response
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day avail
0 0 * * * /usr/local/nagios/bin/call_nmis run-reports.sh day port
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week health
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week top10
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week outage
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week response
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week avail
0 0 * * 0 /usr/local/nagios/bin/call_nmis run-reports.sh week port
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month health
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month top10
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month outage
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month response
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month avail
0 0 1 * * /usr/local/nagios/bin/call_nmis run-reports.sh month port
# OPSVIEW-END

Do you have technical experience of using Opsview that you would like to share with Opsview’s community? We’d love to hear from you! Contact us at marketing@opsview.com or @opsview on Twitter.

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.

IT monitoring has become the most strategically important part of any enterprise process reliant on technology. Any network failure or server outage will impact an organisation’s ability to do business, and therefore, its bottom line.

Using the right tools to monitor your IT is vital not only to the continued health of your IT operations but also to the overall performance of your business. For this reason your monitoring solution must be stable and reliable with a track record of deployment in large scale production environments. This post outlines 10 reasons why choosing the right toolset is paramount to assuring overall business performance.

It’s not just IT that is affected by downtime

So many business tools rely on IT, without a means of monitoring there’s no way to know the reason why the phones don’t work or management reports can’t be produced because a database is offline. And, considering its significance in managing and mitigating enterprise security and compliance risk, IT monitoring is a key requirement for knowing who has access to what in any modern enterprise.

Monitoring is the heartbeat of your business

IT monitoring acts as your IT infrastructure’s nervous system. It senses operational issues and empowers your IT department to take not only remedial, but proactive action swiftly. IT monitoring is an organisation’s view on every aspect of its performance.

Mixing tools can hamper business effectiveness

Problems can start to occur when multiple monitoring systems are used to manage every layer of the IT infrastructure, including networks, servers and applications. Systemic complexity characterised by a mix of proprietary management tools and IT processes can slow reaction times and hamper overall monitoring effectiveness. Only a single system capable of deep visibility of an IT infrastructure can provide an effective solution that will improve business performance rather than detract from it.

Freeware systems aren’t scalable

Free software is often designed as a testing ground for enterprise applications or, in many cases, only meant for use in a simple monitoring environment. For any growing organisation, a scalable network monitoring application is a must in order to handle any growth in the IT estate over time.

It’s not just about internal customers

In our increasingly interconnected, “always on” world, detailed IT performance monitoring can help to minimise the costs of a poor user experience by alerting you when any part of your back-office or virtual storefront is slow or down. Web surfers, for example, have very little patience for badly performing websites. For every second a web store is down customers may be lost.

Prevention is better than cure

The idea behind monitoring an IT environment is “prevention is better than cure”. Businesses will operate far more effectively by spotting problems before they occur rather than being purely reactive. However when downtime does occur, you need the fastest route to addressing the issue possible. Opsview’s ‘Service Desk Connector’ module, for example, integrates monitoring with fault logging systems helping to streamline incident management.

Monitoring is your ‘Insurance Policy’

The value of monitoring enterprise IT systems is linked to their levels of availability, acting as a kind of insurance policy for a business’s bottom line. As the larger and more geographically distributed an enterprise becomes, so the strategic importance of monitoring and assuring performance increases in terms of delivering daily value by supporting ‘business as usual’.

Monitoring tools must integrate with your current systems

When considering monitoring tools it’s important to ensure the provider will be able to meet the levels of openness required for integrating with your own IT systems, while allowing the flexibility required to maximise the use of IT performance information at every level of the business. For corporate networks it is essential that the monitoring system has a scalable architecture in order to cover all systems and locations.

IT infrastructure is no longer restricted to ‘on-premise’

Due to the rise of ‘cloud-computing’, having a clear view of IT performance is all the more important, whether it’s of the server room next door or IT services hosted thousands of miles away through a third-party data centre or software provider. Only a system that can monitor on-premise, virtual and cloud-based servers can offer the management capabilities for an enterprise business to operate effectively.

Staff productivity can be affected

Considering how much pressure IT budgets are under nowadays, most enterprises don’t want to hire their own in-house software engineering staff to fix the source code of third-party applications. The ideal monitoring solution should include software maintenance to ensure that an organisation receives critical software fixes quickly and with minimum disruption business.

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.