Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I saw a lot of monitoring tools and mostly show the same things. But I'm wondering if it's really necessary to watch all of these things.

I would like to know which metrics really matter for example a web server that mainly run a website, with PHP-FPM, Nginx and MySQL.

And also, I'm looking into graphics, but how to understand them and analyze them to prevent any future failure ?

share|improve this question
5  
i.stack.imgur.com/3sV1T.jpg –  ceejayoz Mar 5 '12 at 19:58
    
@ceejayoz I was expecting something like that ;-) –  yvan Mar 5 '12 at 22:54

4 Answers 4

The metrics that matter are those which:

  • Indicate a problem with the correct and proper operation of the services you provide; or
  • Indicate the root cause of a problem

What metrics matter to you depends on what you judge, in your professional opinion, to be the metrics that best fulfil those two criteria. If you don't have the expertise to be able to accurately judge that in advance, well... yeah. Collecting more data that you may never need is better than not collecting some data which you turn out to need later. (The caveat there is that if your monitoring is starting to interfere with the efficient operation of the service, you might need to turn it down a bit, or optimise the statistics collection).

If you're looking for a short-cut answer, I'm afraid I don't have one -- you're on a steep learning curve that speaks to the very heart of what it means to be a sysadmin. If you're in a situation where some downtime doesn't matter, great! you've got yourself a great learning opportunity. If you're going to end up getting sued or going out of business if this service doesn't run perfectly, you might want to find someone with more experience to give you one-on-one guidance and mentoring.

share|improve this answer
    
On my case, I've not problem without downtime, as it almost not possible in the current structure to be down for me. With this question I'm trying to find what really matters, I'm not sure to monitor everything will help you. I'm sure that you've some key metrics that can help you to understand where you're going. –  yvan Mar 5 '12 at 22:57
    
"as it almost not possible in the current structure to be down for me" <---- famous last words. –  EEAA Mar 6 '12 at 4:51
    
@ErikA as nothing its in production yet so it normal ;-) –  yvan Mar 6 '12 at 7:09
    
@yvan: No, actually, I monitor practically everything. I've got a set of about 40 metrics that get measured on every machine I comprehensively administer -- and that's before I start looking at monitoring user-facing services themselves. –  womble Mar 6 '12 at 7:51
    
@womble Well, can you tell me why these 40 metrics are import for you and how you use them ? Because it's what I'm looking for. I just don't want install a program that give me thousand metrics without understanding why I need them. –  yvan Mar 6 '12 at 13:43

I would recommend you take a look at collectd. It can be configured to log numerous measurements into RRD-files for later analysis. It requires very little CPU and will help you to understand how your performance changes with load.

I have not found a truly awesome tool to actually draw graphs from the generated RRDs, but unless you want to project them in realime, just using rrdgraph on command line is typically enough to periodically check for big changes.

share|improve this answer
    
Thanks, but I'm not looking for a tool, but more for best practices for monitoring. I would like to have a kind of list with must be monitored and why and how to understand what is going on –  yvan Mar 5 '12 at 22:58
    
"It requires very little CPU" -- I took it off a bunch of servers a while ago because it was taking half a core. pnp4nagios is a far more lightweight option, and does a better job of presenting the graphs, too. –  womble Mar 6 '12 at 7:53

Excellent advice above. But if you really just need to get started, watch the basics at first: CPU usage over time, memory usage over time, bandwidth usage and disk space use (or free disk space). Those four are very common because they pretty much define the capabilities of a computer.

Once you've monitored for a while and know what 'normal' is for a server, you'll be able to spot when something is abnormal. That's when you're ready to start digging deeper and find out the 'why' -- which will require additional more specific monitoring :)

share|improve this answer

The most basic is to keep an eye on amount of CPU load, free memory & swap, disk space, disk I/O, and network/bandwidth I/O. This can be done using tools like munin or collectd. Some people like to monitor a lot of things, but if you keep it simple at least you can get the overall picture. I also recommend that you configure the monitoring tools to send you email alerts when things start to go wrong (ie using "thresholds" or similar).

Another very useful thing is to keep an eye on the most important server logs for anything unusual, ie error messages or perhaps even warnings. But such messages can be very common depending on how the various softwares are configured to log. Usually, daemons have a config file where you can change the "LogLevel" from error (=only log when something is broken) to debug (=log anything). Check which demons you have running on your server, and change the log levels to error or warning. Then you can install a log file analysis tool such as OSSEC and train it to be silent when certain things are acceptable while it should alert when things are broken. These alerts can be sent via email to you.

For your specific services Nginx and Mysql, I recommend that you monitor their response time. This is good for two reasons: if you don't get a response at all, something is broken. ANd if you get a response that indicates an unusually high response time - especially if it's not temporary but over a period of say a few minutes or hours - then the service is struggling.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.