Nagios is used by thousands of organisation worldwide however using it to monitor complex network, server and application installations can be quite a challenge. This blog post takes the basic capabilities of Nagios and shows how you can scale...
Opsview Development Team
Nagios is used by thousands of organisation worldwide however using it to monitor complex network, server and application installations can be quite a challenge. This blog post takes the basic capabilities of Nagios and shows how you can scale them with Opsview for use in enterprise environments.
Building and managing a complex distributed monitoring environment with Nagios 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 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 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
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.
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 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.
With Nagios 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.