Opsview can monitor and alert better than anyone, but that is only a piece of what it can do for your Enterprise (after all, you can write a script to ping and alert).

Opsview also provides expanded visibility of system resources that put administrators in control of solutions, not just emergencies.

This blog post takes a real world look at how Opsview’s monitoring and metrics of LAMP stack performance led to a proactive decision.

Monitor, Metrics, and Decisions

We built a site in the cloud based on specifications from past performance and traffic statistics. Like all other sites running the LAMP stack, we monitor important levels for each application and the OS. Linux checks include RAM utilization and CPU load, the Apache checks monitor the number of HTTPD processes and graph the page load speed, and the MySQL check monitors the number of concurrent connections.

The site ran well for several weeks with no complaints and no Opsview alerts. An internal user submitted a ticket that an external contact stated the site seemed slow. Checking the site repeatedly showed no signs of poor performance. Opsview’s historical graphs of the LAMP checks pinpointed when the issue occurred and gave clues to how the site would do with sudden bursts of activity.

The RAM on the server was always high and the CPU load was on the upper level of normal. Since the server was in the cloud with a use-based cost model, the current resources were cost effective and the site still performed well.



During the time the incident was reported (not the time when the ticket was created), the Opsview graphs reported a spike in HTTPD processes and MySQL connections.


The increase in Apache processes and MySQL connections had a direct impact on the page load.