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.

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

Distributed monitoring

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

Slave server clustering

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

Example Clustering Model

Master server clustering

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

Separate database server

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

Efficient configuration UI

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

‘Single pane of glass’ monitoring

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

Opsview's Host Group Hierarchy View

Distributed alerting

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

Automated APIs

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

Example use cases for Opsview's RESTful API

SNMP trap processing

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

Notification profiles

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

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

Distributed monitoring

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

Host attributes

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

Keywords

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

Cloning capability

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

SNMP discovery

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

Notification profiles

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

Configuration UI

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

APIs for Automation

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

SLA reporting

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

Service desk integration

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

Hindsight is a wonderful thing.

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

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

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

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

Now you can administer users in a much simpler way.

Hindsight – we wish we had more of it.

But the next best thing to hindsight – migratability.

Migratability?

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

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

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

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

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

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

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

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

In the light of the recent events at a BT network centre in Paddington (London, UK), where a series of compound failures caused a massive outage with huge knock-on effects, I’m sure many businesses are taking another look at their own (and their suppliers) availability with a view to beefing up business continuity. Within the spirit of continuous improvement this should be taken as an opportunity to improve the overall ’system’ rather than finger pointing.

What is business continuity?

Quite simply, business continuity is how you can stay in business (and meet your customers demands) in the wake of a disaster (whether a localised incident such as flooding or a further reaching issue like a terrorist attack). Your plan will typically cover all the business critical functions, systems and data.

So what is high availability?

High availability (or HA) is the way that system designers ensure ‘operational continuity’ of a system. This will typically involve ensuring that the system has no single point of failure (and for really fault tolerant systems there should also be no single point of recovery).

One of the common mistakes that people often make is getting confused between availability and scalability. Scaling is usually described in terms of vertical (bigger boxes) or horizontal (lots of boxes) scaling – horizontally scaled systems often have a degree of high availability whereas vertical scaling is potentially a bigger risk as you lose more capability when you lose a bigger box.

How do redundancy and diversity fit into the picture?

The phrase ‘belt & braces’ describes this nicely – two different ways of achieving the same goal.

One example might be having multiple (diverse) suppliers provide network connections to a building; in data centres it is common to have a (redundant) backup generator – though this is usually coupled with a battery-based UPS (uninterruptible power supply) to provide seamless failover.

But we’ve got this new fangled Cloud thing…

Let’s attempt to clarify what ‘cloud computing’ means – there are a number of different types of on-demand services that run ‘in the Cloud’:

• IaaS – Infrastructure as a Service
• PaaS – Platform as a Service
• SaaS – Software as a Service
• IaaS – Infrastructure as a Service

This category splits into:

• Virtual Private Server (VPS) providers such as Slicehost allow businesses to rent a fixed size virtual server on demand for a set monthly fee
• Elastic computing providers such as Amazon EC2 allow businesses to have a virtual machine image that can grow to meet requested demand (vertical scaling).

PaaS – Platform as a Service

Platform as a Service providers offer application-hosting platforms (again these can be of fixed-size or scalable) so that application developers can focus on adding business value rather than needing to worry about the underlying infrastructure. Google AppEngine is one example of this approach for Java & Python applications.

SaaS – Software-as-a-Service

Software-as-a-Service provides access to business software over the Internet for a set monthly fee. This can either be multi-tenanted, where multiple companies share a system, or with separate installations per customer. One of the major SaaS success stories is SalesForce.com who started with a CRM on-demand offering.

Public vs. private vs. hybrid clouds

We’ve already discussed public cloud offerings above; a private cloud is typically an on-premise or a dedicated outsourced managed cloud platform (e.g. using the open source Eucalyptus or VMWare vCloud). A hybrid cloud is where a private cloud is used in conjunction with one or more external cloud providers.

There is also the notion of community clouds with varying definitions:

1. whereby similar organisations pool resources into a shared multi-tenant cloud (though I prefer to describe this as a shared private cloud or a restricted cloud e.g. Google’s ‘GovCloud’)
2. a decentralised peer-to-peer cloud utilising spare computing power (and bandwidth) of internet-connected computers.

Deployment models

Assuming that your organisation can operate its business critical systems and store business critical data in the Cloud, then there are a number of possible deployment models to consider, chiefly:

1. Backup
2. Failover
3. Active-active
4. Cloud as a backup

Cloud as a backup

In this model, data plus the necessary software packages and configuration data (e.g. CMDB configuration data) for critical systems are backed up to 1 (or ideally more) hosts in the cloud. In the event of a disaster at the primary operating location, new virtual servers are commissioned and the configuration management tool (e.g. Puppet) is used to provision the servers with the appropriate software.

Recovery time is dependent upon the time taken to commission/provision the new virtual servers and perform any data transfer (or decryption). Database/file replication techniques can help to reduce the time to recover.

Failover to the cloud

For this model, there are pre-configured server instances in the cloud running the business critical systems combined with data replication. In the event of a disaster at the primary operating location, the systems are failed over to the cloud instance (this can be manual or use an automated ‘global load balancer’).

Active-active

This form of hybrid cloud is fundamentally the same as the failover option, however there are more complexities involved in the data synchronisation, session failover etc.

The Cloud

So how can the Cloud help with planning Business Continuity activities?

1 & 2: People & premises

For knowledge worker businesses, the Internet and widespread availability of broadband has increased the prevalence of distributed home workers. With a distributed workforce and cloud-based systems these two are items of less concern; it remains a practical option to have staff work from home (or indeed a temporary serviced office) in the event of a disaster accessing systems running in the cloud.

For a true ‘belt and braces’ approach, 3G/HSDPA mobile broadband dongles can be used to provide a secondary Internet connection for home workers should their main internet connection be unavailable.

3: Technology

Infrastructure-as-a-Service is very compelling for providing a Business Continuity strategy for data centre(s) using the deployment models outlined above. Furthermore, VoIP services can provide sufficient telephony cover for small-medium businesses.

4: Information

Cloud-based services (whether computing based or dedicated storage solutions e.g. Amazon S3) can aid your business in having current data stored confidentially and readily available in the event of a disaster. Some regulated organisations may have to consider whether the service provider can store data within the appropriate territory/jurisdiction. Data integrity is a further consideration for more complex system environments (particularly with the backup approach) – this needs to be taken into account for solution design / recovery procedures.

Conclusion

So we’ve established that cloud computing can alleviate some of the business continuity execution effort from your business, however you still need to plan properly (what happens if key personnel are unavailable; how will equipment & supplies be sourced) and perform due diligence on service providers to ensure that their SLAs and DR plans align with your needs.