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.

With the likes of cloud computing and virtualisation starting to become staples for today’s business, IT environments are continuing to grow in complexity. Furthermore, there is growing pressure on many organisations to reduce the environmental impact of their IT systems.

In response to these developments, organisations need to change the way they manage and therefore monitor their IT infrastructure. For example, with the advent of virtualisation, organisations now have a fundamentally different infrastructure platform from which they are running business systems. This in turn requires a different monitoring approach.

If organisations can’t adapt their physical world approaches to monitoring, they could find that they aren’t made aware of systems problems until users start complaining about downtime.

When it comes to cloud they need to consider how they are going to monitor both the performance and use of cloud services. Finally, with it being unlikely that organisations will move all services to the cloud they need to find ways to monitor environmental factors such as the temperature of data centres and the CO2 emissions of IT.

This data will not only allow them to find ways to reduce energy costs, but also report back up the organisation when it comes to the environmental targets that have been set.

At the same time as being presented with an increasingly complex environment to monitor, IT departments are under pressure to dramatically reduce the cost of day to day operations. The result is a conundrum that requires new ways of thinking to solve.

Taking The Pain Out Of Virtualisation

Virtualisation has been utilised by many organisations looking to improve operational efficiency. Thus, with physical and virtual machines now present in many businesses, monitoring and managing both effectively is vital.

When implementing and monitoring virtualisation, businesses face a number of challenges – all of which add to the complexity of IT monitoring. Virtualisation allows you to improve server utilisation. Yet, when you increase the utilisation of a previously under-used server, it can be difficult to know how that server will manage the increased load.

Therefore, monitoring the performance of the VM host and all the virtual machines running on it is imperative otherwise organisations could find they suffer from performance slow downs or worse still, downtime. The problem is virtualisation doesn’t behave like, or conform to the same rules as physical hardware and therefore often traditional approaches to monitoring both infrastructure and applications don’t meet the grade.

You often find that the VM itself can be monitored, but there is no insight into what’s going on within it or into the applications it’s hosting.

A further challenge for a lot of organisations is staying on top of the growing sprawl of virtualisation, due to the ease of creating virtual machines. To date, this is something that many have struggled with using older proprietary IT monitoring and management tools.

To combat these potential issues, organisations need to update their approaches to IT monitoring. They need to use tools that can provide insight into virtualisation and that enables them to understand how every application on every virtual machine is running, what problems could occur and how they can be remedied.

Without this investment in IT monitoring, virtualisation will not bring the ROI expected and the increased complexity could in fact result in ongoing performance issues.

Up In The Air – The Cloud Effect

The acceptance of cloud computing has increased over the past few years. Now, the terms public, private and hybrid are understood by the majority of organisations, with data centre association Afcom citing that more than 70 per cent of UK businesses are already implementing cloud, or seriously considering it.

Adopting a cloud model allows businesses to move some applications and services off-premise, resulting in reduced costs, with less IT equipment required on-premise. However, cloud does potentially present a number of challenges when it comes to monitoring the overall performance of an organisation’s IT infrastructure.

With this in mind, organisations should start thinking about how they are going to monitor and assess cloud performance in the future, in order to guarantee IT performance. The difficulty at the moment is that there are not many standards around cloud when it comes to moving applications between public and private clouds, and consequently monitoring them.

Therefore, before choosing a monitoring tool, organisations need to ensure that the solution has the flexibility to adapt to any future changes once standards do eventually emerge.

Another challenge organisations should be looking out for as they begin to use cloud-based services, is that they could experience cloud sprawl. Although one of the benefits of the cloud model is that users can buy services on a pay-as-you-go basis, organisations will need to make sure they are controlling cloud deployments, as it can be very easy to continue paying for cloud services long after they have finished using them.

This is for the simple reason that people often forget to tell the cloud provider that they have finished using the service and therefore keep getting billed. Ultimately, businesses will need to have a consolidated view of all cloud services meaning they will then be able to monitor how much these are being used. This way, they can make sure they only pay for what they are actually using rather than paying for what they have deployed.

Going Green Without Feeling Blue – Green IT Made Simple

In addition to adopting new technologies or IT models to reduce costs, organisations are also under pressure to become greener. This pressure comes not just from the board as they look to achieve cost savings, but also through growing public and legislative pressure on them to reduce carbon emissions.

The UK Government has set a target of cutting CO2 emissions by 34% of 1990 levels by 2020. Businesses play a key part in this and the pressure is on to adhere to the new rules and regulations that aim to ensure we hit those targets.

The main challenge for many organisations however, is that they don’t know how much power is being consumed by their IT, especially as data centres are now often located away from an organisation’s main site. Organisations must be able to construct a better picture of energy usage in their data centres – building environmental factors into monitoring to identify areas where further energy savings can be made.

For example, organisations need to be able to tell when and where they can power down servers that are not in use. They also need to monitor data centre temperature very carefully – ensuring cooling systems are working efficiently and keeping their servers at optimum temperature.

Furthermore, IT monitoring can also help organisations build a picture to help them decide which old systems can be decommissioned if they are not performing sufficiently. Being green does not need to be difficult. The right tools will indicate the right processes to improve your environmental credentials without the need for more investment or even more IT complexity.

As the IT landscape continues to change, it is becoming increasingly clear that the monitoring tools and techniques that worked in the past simply don’t suit the modern environment. More flexibility and agility is needed in IT monitoring, while reducing the overall cost. Overall, IT monitoring can help organisations improve their business and environmental performance. The challenge is now to ensure they have the right tools and techniques in place to do this.

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.

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.

Opsview gives you lots of standard options for receiving status notifications, but with a bit of custom scripting you can also get status messages from Opsview and post them to a Twitter account. This could be useful if you want to keep all your status messages in one place with a timeline. Plus you can also set up an account for other members of your team to follow so they can also see the updates. However it’s probably best that the Twitter account is kept within your organisation unless you want the world to see the status of your servers!

This article tells you how to configure Opsview to send messages to Twitter. For configuring this you need to have access to the shell of your Opsview server.

To access Twitter from Opsview, you’ll need to install Tweepy. Tweepy is a Python library for accessing the Twitter API. It requires Python 2.5 or later. If you need to install Python 2.6 you can follow the instructions on this blog.

# wget http://dagobah.ftphosting.net/yum/smartfile.repo -O /etc/yum.repos.d/smartfile.repo

Then you can use YUM to install python26 package:

# yum install python26 python26-distribute

To get a list of installed packages, do:

# yum list *python26* | grep -i installed

Installed Packages
python26.x86_64             2.6.5-6.el5   installed
python26-distribute.noarch  0.6.10-4.el5  installed
python26-libs.x86_64        2.6.5-6.el5   installed

Install Tweepy

/usr/bin/easy_install-2.6 tweepy

Next you’ll need to authenticate Twitter from the command line. This blog tells you how.

At this point you’ll need to create a new Twitter account which will be used to post the notifications.

Make sure you enable Tweet Privacy under Settings, in the Twitter account, so that posts are not made public (unless you want them to be!)

After creating the Twitter account, you’ll need to register a new client app with Twitter.

Select “Connect the app to your Twitter account” with a minor change in the first line.. write python26 instead of python

#!/usr/bin/env python26

Import tweepy

CONSUMER_KEY = 'paste your Consumer Key here'
CONSUMER_SECRET = 'paste your Consumer Secret here'
auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth_url = auth.get_authorization_url()
print 'Please authorize: ' + auth_url
verifier = raw_input('PIN: ').strip()
auth.get_access_token(verifier)
print "ACCESS_KEY = '%s'" % auth.access_token.key
print "ACCESS_SECRET = '%s'" % auth.access_token.secret

Again, in  “Create the command line script”, change to python26. Don’t forget to add your own keys.

#!/usr/bin/env python26

import sys
import tweepy

CONSUMER_KEY = 'paste your Consumer Key here'
CONSUMER_SECRET = 'paste your Consumer Secret here'
ACCESS_KEY = 'paste your Access Key here'
ACCESS_SECRET = 'paste your Access Secret here'
auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
api = tweepy.API(auth)
api.update_status(sys.argv[1])

Then “Send a test tweet from the command line” and if the test is successful, do the following:

1.	Move the script to /usr/local/nagios/libexec/notifications/.

(call the script ‘connect_twitter’, hence script is at /usr/local/nagios/libexec/notifications/connect_twitter)

2.	chown nagios:nagios /usr/local/nagios/libexec/notifications/connect_twitter
3.	chmod +x /usr/local/nagios/libexec/notifications/connect_twitter

Create another script to be used by Opsview:

/usr/local/nagios/libexec/notifications/notify-by-twitter

The script:

dt=`date '+%H:%M %d%b%y'`
if [ -n "$NAGIOS_SERVICEDESC" ]
then
msg=`echo @$NAGIOS__CONTACTTWITTERID Time:$dt. $NAGIOS_SERVICEDESC @ $NAGIOS_HOSTNAME,$NAGIOS_HOSTADDRESS is $NAGIOS_SERVICESTATE. $NAGIOS_SERVICEOUTPUT | cut -c 0-140`
/usr/local/nagios/libexec/notifications/connect_twitter "$msg"
unset msg
else
msg=`echo @$NAGIOS__CONTACTTWITTERID Time:$dt. $NAGIOS_HOSTNAME,$NAGIOS_HOSTADDRESS is $NAGIOS_HOSTSTATE. $NAGIOS_HOSTOUTPUT| cut -c 0-140`
/usr/local/nagios/libexec/notifications/connect_twitter "$msg"
unset msg
fi

Again,

chown nagios:nagios /usr/local/nagios/libexec/notifications/notify-by-twitter
chmod +x /usr/local/nagios/libexec/notifications/notify-by-twitter

Log in to Opsview as a user with admin privileges.

Go to Advanced then Notification Methods from the drop down menu.

On the top right, click Actions and then Create new Notification Method as following:

Next, go to Configuration on the Opsview Menu bar, then Contacts. Click on the contact you want to set Twitter alerts for. Click the Notifications button. Add your Twitter ID (this ID will receive the Tweets).

Click on Submit and edit Notification Profiles.

Click Actions, and create new Notification Profile for user.

Create the profile and submit changes.

Reload your configuration (click on Configuration Status, top right, then Reload Configuration).

Reboot one of your servers or stop a service which is added in Opsview. Note that Twitter allows 250 direct messages per day, do not cross this limit as tweets won’t come in after you exceed this number.

The Tweets should now start coming in!

Try this out for yourself by downloading Opsview Community edition and get our latest tips and updates by following us on Twitter!

Uprooting the Opsview Master server is probably last on every administrator’s to-do list. But it’s not a perfect world and extenuating circumstances may require the master to be positioned elsewhere.

Here are 10 steps to move an Opsview master server and limit downtime during the relocation of your IT monitoring system.

Keep in mind in this scenario we have the luxury of moving the server while maintaining the same architecture and OS version, so we have the ability to copy files from the old server to the new server. We are not restoring the master server. (check out Opsview documentation on backups and restores to find out which databases and files are backed up by a nightly cron job).

The process can be broken down into three sections: components, configuration, and communication.

Components

1. On the new server, follow the documentation to install Opsview for your Linux distribution. Also install MySQL and Apache in the same fashion as your original server, whether it is with a package manager or custom compile.

2. Opsview does daily backups that can be used for a restore. In this case, we are doing a migration so we can manually copy all the data required. We will treat Opsview like any other web application and rsync the entire /usr/local/nagios directory to the new server and do a mysqldump of all MySQL databases, capturing odw, opsview, reports, runtime, and the database called mysql with all users and their permissions.

nagios@< oldserver >$  rsync –arolptv /usr/local/nagios/ :/usr/local/nagios/

root@< oldserver >#  mysqldump –-routines –u’dbuser’ -p’dbpass’ –-all-databases > /tmp/alldbs.dmp

3. Copy and import the MySQL databases on the new server. Also, verify the nagios user has the correct (and recursive) permissions on /usr/local/nagios.

4. Time is crucial between the master and slave servers and you will get an error if the time is only seconds apart. Be sure all slaves and the master server are using the same time server and they are synced before turning on Opsview for the first time.

Configuration

(For this section, don’t start up Opsview yet)

5. On the slave servers, the master server is listed in /usr/local/nagios/etc/opsview-slave.conf either by IP address or fully qualified domain name. Change the IP address here or change /etc/hosts to have the new IP address and keep the FQDN in the configuration file. We want to control how the slaves access the master and not rely on any other DNS source.

6. If you use Apache as a proxy server, copy over /etc/httpd/conf.d/opsview.conf from the old server to the new server.

7. If you use the rsync method to copy all files as the nagios user, permissions on the file /usr/local/nagios/libexec/check_icmp (and check_dhcp) may be changed to an incorrect value. Set the correct ownership and access permissions.

chown root:nagios /usr/local/nagios/libexect/check_icmp
chmod 4550 /usr/local/nagios/libexec/check_icmp

Communication

(Wait for it…SSH connections must work before Opsview can be started).

8. Since we have the old server, copy all the SSH keys from the nagios home directory (probably under /var/log/nagios/.ssh/) to the new server. On the slaves, remove the entry for the master in the known_hosts file under the nagios user and establish a connection to the new master server to verify SSH works correctly with shared keys.

9. Use the send2slaves command to test the master communicating with the slaves.

/usr/local/nagios/bin/send2slaves –t 

10. When you have all components installed and started, all configuration files in place, and communication established from master to slaves (and vice versa), start Opsview and Opsview-web on the master server.

/etc/init.d/opsview start
/etc/init.d/opsview-web start
Start Opsview on all the slave servers.

/etc/init.d/opsview-agent start
/etc/init.d/opsview-slave start

Done! The Opsview UI should be accessible (after a DNS change or an edit to your local hosts file to verify).

Moving the master server shouldn’t be a frequent task, but with Opsview’s portable architecture, it can easily be accomplished.

Want to learn more about configuring and implementing IT monitoring with Opsview? Check out our training courses.

The adoption of virtual IT systems is growing rapidly, offering lower costs and improved availability. However virtualization’s inherent flexibility brings with it significant management challenges that can’t be solved using multiple monitoring tools.

Opsview provides a single, consolidated view of all your virtual systems and guests allowing for easier event correlation and rapid time to fix. Combined with native network, enterprise application and Cloud support Opsview offers unparalleled coverage of your entire infrastructure.

Here are 10 benefits of choosing Opsview to monitor your virtualized systems:

1. Build up a complete picture of your virtual system’s performance.

Opsview gives you complete visibility of the health of your systems, physical and virtual. If you’ve invested heavily in virtualizing servers, you need to ensure that those servers are performing at optimum levels to maximise staff productivity and customer satisfaction.

Opsview gives you insight and tools to identify trends, pre-empt problems and plan future capacity, all from one screen.

2. Get notified before problems impact end-users.

Poor user experience costs you money. Customers walk away from systems that lag and staff efficiency is severely impacted by slow business applications. Opsview enables you to fully track the health of your virtual systems and provides an array of rich alerting options that allow you to focus your effort where it’s needed most.

3. Easily group your virtualized hosts/guests by business process.

Opsview makes it easy to manage virtual servers by grouping them in ways that are meaningful to you. By applying keywords to virtual hosts, you can group them together to form business process views and display their status using simple ‘traffic lights’ to all users in real-time. From Opsview’s user interface you can quickly see the status of groups of virtualized servers and take action if required.

4. Understand the business impact of virtual host/guest issues and resolve them quickly.

Tracking the health and availability of your virtual systems is a significant challenge; reacting quickly to events requires the right information at the right time and with a clear path to implement fault resolution. Opsview Enterprise edition offers enhanced modules to enable you to act on monitoring issues quickly and in a controlled way to reduce the delay between fault and response.

5. Monitor end-to-end performance, not just a single component.

Monitoring any kind of infrastructure whether virtual, physical or cloud is not just about focusing on one component of that infrastructure. That’s why Opsview gives you a fully integrated solution to provide an overall picture of system health and performance to make informed business decisions.

6. Critical monitoring tasks can be automated.

Opsview’s Puppet module allows virtualized hosts managed by Puppet to be added automatically into your Opsview monitoring helping ensure availability, provide efficient service and reduce manual errors, cost and complexity.

7. Support for a wide range of virtualization technologies.

Opsview has been designed to work with a wide range of virtual machines and systems including VMware, KVM, Microsoft Hyper-V and Citrix XenServer.

8. Performance can be Benchmarked.

Reports, available with Opsview Enterprise editon, provide insight into the availability, performance and capacity of your virtual systems for better forward planning and reduced downtime. If you’re providing virtualized servers as a managed service and need to benchmark performance, these reports can be invaluable in helping keep to agreed SLAs. Reports can be customized and automatically distributed to business managers or customers, saving you time and ensuring stakeholders get the information they need.

9. Scales with your infrastructure.

Opsview provides a single, consolidated view of your virtualized servers, cloud environments, or mobile devices, allowing for easier event correlation and rapid time to fix. Opsview’s enterprise architecture is inherently scalable no matter the mix or geography of the systems to be monitored.

10. Industry Recognised.

Opsview are committed to providing technical solutions that are aligned with the demands of the modern enterprise. In recognition to our commitment, Opsview are a VMware Technology Alliance Partner, Open Virtualization Alliance member and have recently joined the Openstack Ecosystem.

Try out virtualization monitoring with Opsview by downloading the Opsview Community edition virtual appliance.

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.

Our latest release, Opsview Enterprise 3.14 edition, is out today!

As well as fixes and major enhancements, configuration changes are applied in half the time compared to previous releases for complex Opsview deployments.

Updates and improvements include:

• Reload times on systems with a large number of contacts (> 50) halved
• Configuration generation speed improvement of 60% when using lots of keywords
• Opsview Mobile for Android is now available in Opsview Enterprise 3.14 edition
• Red Hat Enterprise Linux 6 and Debian Linux 6.0 (Squeeze) are now officially supported platforms
• IE9 is now an officially supported web browser
• Rest API status information now summarised by host group, host, service and viewport

For a full list of improvements in 3.14 edition visit our documentation wiki.

Want to find see some of the new dashboard features coming up in Opsview Enterprise 4.0 edition? Join our webinar on 3rd November 2011.