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.

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.

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.

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.

There are just as many explanations to cloud services these days as there are cloud service providers. Regardless of the definition and the type of service (IaaS, SaaS, PaaS), the end result for IT is the same: infrastructure is extended off-premise. IT departments have another functionality requirement for their monitoring system as enterprises expand and resources become more dynamic.

As the uptake of cloud services increases, so does the pressure on IT to manage them. In a recent survey carried out by Opsview, 67% of organisations were concerned about the threat of cloud-sprawl. Fortunately, Opsview is ready to tackle any challenges presented by cloud monitoring.

Here are five ways to use Opsview in conjunction with cloud services.

Tune Applications, Reduce Costs

Servers in the cloud should be monitored just like servers on-site, but evaluated in finer detail especially since elastic computing provides a tuning opportunity. System resources can be added or reduced based on application needs.

Opsview graphs present historical data of monitored services to allow administrators to confidently tune dynamic resources. Certainly a powerful benefit, but reducing resources to lower costs shouldn’t compromise stability. Keeping a close eye on resource statistics allow administrators to understand events and distinguish between anomalies and patterns.

Performance trending for applications is paramount for cloud servers since the ability to turn down resources like RAM and CPU actually affects the bottom line with providers charging on a usage basis.

Extend any component into the cloud

Enterprises look to the cloud to position business critical applications, taking advantage of top tiered data centres and ease of availability to employees traveling around the world. Isn’t your monitoring system a business critical application? With Opsview’s distributed architecture, any component can be extended into the cloud. On-site slave servers can report to a master in the cloud. Slave servers can be placed in each cloud environment, serving as a backup to other slaves spread across cloud regions or different providers. The Opsview master could also stay on-site and remotely monitor cloud environments.

The ease of building in the cloud doesn’t limit how Opsview works, rather it extends its ability to monitor the “big picture” for any enterprise.

Provide Limitied Access

With so many cloud offerings, the decision on which provider to use can be time consuming. Sometimes for business reasons (fortunate or not) the decision is made for us and we have to “make it work.” A business unit may strongly suggest their servers be placed with a recognized provider while another division looks at the cheapest solution on the market.

As a result, each cloud environment may have certain users interested in only those servers. Use Opsview to give them visibility to resources and performance metrics without showing them all servers monitored. Create a Role that limits them to the Host Group for servers hosted by their cloud provider of choice. Opsview can continue to be the centralised solution to monitoring and alerting for servers in the cloud, making proprietary add-on cloud offerings unnecessary.

Use libcloud to Enhance Opsview Checks

Many cloud providers have an API as a value add to their services to help administrators manage multiple instances. Libcloud from Apache provides a way to interface multiple providers, giving IT a common platform to develop checks that span environments. Opsview includes Service Provider checks for Amazon and Slicehost, with more on the way with future updates, and easily incorporates custom scripts and checks seamlessly as administrators discover important metrics to monitor with cloud servers. Since cloud interfaces allow for quick provisioning of instances but not a detailed audit trail of who created the server, create a check and alert when new instances are added so everyone on the team is aware of additional servers in the environment.

How much impact is the cloud having on your business? We’d love to hear your thoughts…

It is often the case that hosts on your network will be similar, but differ in subtle ways depending on their exact purpose. For example some servers may have two internal disks whilst some may have just one, and some servers may have multiple ethernet cards where others do not. Opsview provides attributes to deal with situations like this, as they are a way of associating metadata with a host – here is an example of how to configure Opsview to use them.

Let’s assume we have a Linux host that has three ethernet cards – eth0, eth1 and eth2. Rather than create three service checks which reference these interfaces explicitly, we’ll configure a single Interface Throughput check that will be duplicated for each network card that a host has.

1. Create the attribute

First we’ll create an attribute called “NIC” so that we can store this metadata against the host. Go to Advanced -> Attributes -> Actions -> Create new attribute and enter a name of NIC, then save it.

2. Define the attribute for one or more hosts

Now that the attribute is known to the system, it can be applied to some hosts. In this example, we edit the Linux host, and under the “Attributes” tab, add three entries all with a label of NIC, with the values eth0, eth1 and eth2.

3. Create a service check which uses the attribute

Now that we have some metadata about the host, we can create a service check that uses it. The screenshot shows the configured service check – the “Multiple” prefix indicates that we have selected “NIC” as the value for Create Multiple Services under the Advanced section of the check configuration, and so at reload time Opsview will create three service checks, replacing %NIC% with each of the three values.

4. Apply the new check to the host

The check can either be applied directly on the Monitors tab of the host configuration, or using a Host Template. Once the check has been applied, reload Opsview and navigate to the host status. You should now see three services, one for each ethernet card that you have defined for the host.

5. Apply to more hosts

This new service check can now be applied to any number of hosts you wish, and you simply need to define as many NIC attributes as you need for that particular host.

This example really just scratches the surface of how host attributes can help you better organise your server monitoring. You can find out more about attributes on our documentation site and try it out for yourself by downloading Opsview Community Edition.