command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,12,10 -c 20,18,15

command[check_load]=/usr/lib/nagios/plugins/check_load -r -w 3,2.5,2 -c 5,4,3

Make load average check relative to the number of CPUs
Make load average check relative to the number of CPUs

Load average is a fuzzy indication of how responsive a computer feels.
The calculation takes into account both CPU and IO utilisation, so
even if the system feels responsive, if it's waiting for a lot of IO
the load can be high.

Roughly speaking, a load of 1 means that 1 CPU (core) has been 100%
busy.  Given that we have machines with different numbers of CPUs,
checking against absolute numbers isn't very meaningful.  In fact, we
doubled the number of CPUs in postgresql-primary-1.production in July
2018, but didn't change these thresholds.  So this commit makes the
thresholds relative.

The old thresholds were:

    warn: 15, 12, 10; critical: 20, 18, 15

With 4 cores the new thresholds are:

    warn: 12, 10, 8; critical: 20, 16, 12

With 8 cores the new thresholds are:

    warn: 24, 20, 16; critical: 40, 32, 24

So on 4 cores we'll have slightly lower thresholds, but on 8 cores
we'll have rather higher.  Given that our 8-core machine,
postgresql-primary-1, is mostly IO-bound, I think allowing larger
thresholds is fine.

When email-alert-api is migrated to AWS and gets its own database
server, perhaps we will want to reduce these thresholds again.

Arguably, load average isn't the right metric anyway, and we should
use something like query latency to determine if postgresql-primary-1
is overloaded.  In any case, we have this monitoring now, and get a
lot of alerts when, actually, everything is fine.  By increasing the
thresholds we'll be more likely to treat the alert as an indication of
an actual problem.
