Question

上一节主要介绍了如何通过数据抽取脚本从 Ganglia 中抽取数据，然后通过脚本的判断最终实现在 Centreon 上的报警通知。这个过程看似很完美，其实隐藏着一些问题，比如，从给出的两个数据抽取文件中，脚本每次只能检测一台主机的一个服务状态，如果要检测多台主机的多个服务状态，就需要多次重复执行这个脚本。例如，要检测 100 台主机的磁盘最大占用率，脚本就要重复执行 100 次，同理，要检测 100 台主机中的 10 个服务状态，脚本就要执行 1000 次，在 Centreon 平台中，脚本检测是定期执行的，如果每小时执行一次检测，那么每小时就要执行脚本 1000 次。由此可知，这种脚本执行方式效率低下，严重浪费服务器资源，在监控主机较少的环境中，监控效率还勉强能够接受，但是当监控的主机超过 500 台或更多，监控的服务超过 100 或更多时，监控效率将更加低下，监控脚本从 Ganglia 抽取数据的时间也将变得很长，可能还会发生获取监控数据超时的情况，对于要求监控精度很高、报警及时性强的监控报警平台来说，这是不可容忍的。

如果能减少监控脚本重复执行检查的次数，或者让脚本一次检查多台服务器的多个服务状态，那么脚本的执行效率将大大提升。在上节介绍的第二个脚本中，是通过读取 Ganglia Web 的页面信息来获取监控数据的，既然通过此脚本能一次获取某台主机的信息，那么也能一次获取多台主机的数据。非常幸运，Ganglia 本身已经实现了这个功能，这里只需稍作修改拿过来使用即可。在 Ganglia Web 的程序目录下有一个 nagios 目录，其中有多个 shell 脚本和 PHP 脚本，这里重点介绍下 check_host_regex.sh 和 check_host_regex.php 这两个脚本，其他脚本的使用方法与此类似。

经过修改后的 check_host_regex.sh 脚本内容如下：

GANGLIA_URL="http://localhost/ganglia/nagios/check_host_regex.php"
# Build the rest of the arguments into the arg string for the URL.
CHECK_ARGS=''
if [ "$#" -gt "0" ]
then
  CHECK_ARGS=$1
  shift
  for ARG in "$@"
  do
    CHECK_ARGS=${CHECK_ARGS}"&"${ARG}
  done
else
   echo "Sample invocation $0 hreg=web|apache checks=load_one,more,1:load_five,
more,2 ignore_unknowns=0"
   echo "   Set ignore_unknowns=1 if you want to ignore hosts that don't posses
a particular metric."
   echo "   This is useful if you want to use a catchall regex e.g. .* however
 some hosts lack a metric"
   exit 1
fi
RESULT=`curl -s "${GANGLIA_URL}?${CHECK_ARGS}"`
EXIT_CODE=`echo $RESULT | cut -f1 -d'|'`
REST=`echo $RESULT | cut -f2 -d'|'`
for x in $EXIT_CODE; do
  case $x in
  OK)
    echo $REST
    exit 0;;
  WARNING)
    echo $REST
    exit 1;;
  CRITICAL)
    echo $REST
    exit 2;;
  *)
    echo $REST
    exit 1;;
  esac
done

这里主要看下此文件第一行“GANGLIA_URL”的内容，这个变量用于指定 HTTP 方式访问 check_host_regex.php 脚本的路径，后面跟的 URL 只要服务器本身能够访问即可。从脚本内容看，check_host_regex.sh 主要用于对获取的监控数据进行判断，而 check_host_regex.php 脚本主要用来获取监控数据。check_host_regex.php 脚本获取数据的方式与上节介绍的 check_ganglia_metric.php 脚本实现原理完全相同，实现起来非常简单，这里不再讲述。

下面介绍 check_host_regex.sh 脚本的用法。

直接在命令行执行 check_host_regex.sh 脚本，即可显示详细用法，例如：

[root@centreonserver plugins]# ./check_host_regex.sh
Sample invocation ./check_host_regex.sh hreg=Hostname checks=load_one,more,1:
load_five,more,2 ignore_unknowns=0
   Set ignore_unknowns=1 if you want to ignore hosts that don't posses a 
   particular metric.

下面介绍其中各个参数的意义。

- hreg：后面跟主机名或主机名标识。这个参数的含义与 check_ganglia_metric.php 脚本中“hostname”参数的含义相同，但用法稍有不同。如果在 hreg 后面指定一个完整的主机名，那么就收集这台主机的状态信息。同时，hreg 参数还支持正则表达式，只需提供一个主机名的标识，就可以批量检测包含此标识的所有主机，例如，有 800 台主机，主机名都包含有“bestjob”这个字符，那么只需设置“hreg=bestjob”即可实现一个脚本一次检查 800 台主机的服务状态。

- checks：后面跟检测服务的指标值、检查条件和告警阈值。常见的服务指标有 load_one、disk_free、swap_free、part_max_used 等，检查条件有 more（大于）、less（小于）、equal（等于）、notequal（不等于）四种，告警阈值根据实际应用环境来设置。这个参数还有个功能就是可以一次设置多个服务状态，每个服务之间用“：”进行分割即可。有了这个功能，就可以通过一个脚本一次检测多个服务的运行状态，大大提高了脚本检测的效率。

- ignore_unknowns：此参数用来设置是否忽略 UNKNOWN 状态的服务。设置此参数为 1 表示忽略 UNKNOWN 状态的服务，反之，设置为 0 表示不忽略。

下面演示一下此脚本的用法，这里以检测主机名含有“bestjob”标识的主机为例，操作过程如下：

[root@centreonserver plugins]# ./check_host_regex.sh \ 
> hreg=bestjob checks=load_one,more,15         
Services OK = 796, CRIT/UNK = 4 ; 
CRITICAL host0089.bestjob.com load_one = 16.96,
CRITICAL host0133.bestjob.com load_one = 22.91,
CRITICAL host0028.bestjob.com load_one = 15.02,
CRITICAL host0329.bestjob.com load_one = 16.68

此命令用来检测主机名含有“bestjob”标识的主机 1 分钟内的负载状态，当负载超过 15 时进行告警通知。从输出可知，主机名含有“bestjob”标识的主机共有 800 台，其中 4 台主机在 1 分钟内的负载状态超过 15，并给出了超载主机的主机名和当前的负载状态值。

下面是一个脚本检测多台主机的多个服务的用法，操作过程如下：

[root@centreonserver plugins]# ./check_host_regex.sh \
> hreg=bestjob checks=load_one,more,15:disk_free,less,900 ignore_unknowns=1
Services OK = 787, CRIT/UNK = 13 ; 
CRITICAL host0081.bestjob.com load_one = 25.51 , 
CRITICAL host0246.bestjob.com load_one = 16.86 , 
CRITICAL host0003.bestjob.com disk_free = 576.318 GB, 
CRITICAL dbmysql.bestjob.com disk_free = 520.721 GB, 
CRITICAL webapp.bestjob.com disk_free = 461.966 GB, 
CRITICAL host0200.bestjob.com disk_free = 852.420 GB, 
CRITICAL host0055.bestjob.com disk_free = 279.465 GB, 
CRITICAL dbdata.bestjob.com disk_free = 636.190 GB, 
CRITICAL webui.bestjob.com disk_free = 525.538 GB, 
CRITICAL server0232.bestjob.com disk_free = 861.330 GB, 
CRITICAL server0159.bestjob.com disk_free = 801.443 GB, 
CRITICAL host0080.bestjob.com disk_free = 739.467 GB, 
CRITICAL etlserver.bestjob.com disk_free = 826.477 GB

此命令检测含有“bestjob”标识在主机 1 分钟内的负载状态和剩余空闲磁盘空间情况，并忽略 UNKNOWN 状态的服务。从检测结果中可以发现，在 800 台主机中，有 13 台主机出现负载或磁盘空闲空间告警问题，并输出了详细的告警信息。

最后，还需要将此脚本集成到 Centreon 平台上，以实现主机和服务的批量监控与批量报警。集成方法与上节介绍的集成 check_ganglia_metric.php 的方法完全相同，这里不过多介绍。

在完成脚本集成后，重启 Centreon 服务，即可实现主机和服务的批量监控与报警，通过批量的方式监控主机状态。对于 500 台以上主机的运维环境来说，如果需要监控 100 个服务，那么每个脚本监控 20 个服务，脚本执行 5 次即可完成所有主机服务状态的监控，大大减少了脚本的执行次数，同时每个脚本的执行时间也不会显著增加。实践证明，通过批量监控的方式基本解决了大运维环境下的监控报警性能问题。

图 9-9 是 Centreon 在批量监控下的一个运行状态截图，通过此图可以清晰地看出哪些主机出现了告警问题，以及服务上次检测的时间和下次检测的时间。

图 9-9 Centreon 在批量监控服务下的运行状态图

由图 9-9 可知，此服务批量监控了 800 台主机的“part_max_used”指标，其中，799 台主机的“part_max_used”状态正常，主机 dbmysql.bestjob.com 的磁盘最大占用率超过了指定的告警阈值。

如果对服务故障设置了发送邮件的报警通知，那么此时就会收到邮件报警通知，收到的邮件内容类似如下：

*****centreon Notification *****
Notification Type: PROBLEM
Service: part_max_used
Host: Centreon-Server
Address: 192.168.20.98
State: CRITICAL
Date/Time: Thu Feb 13 18:20:54 CST 2014
Additional Info:
Services OK = 799, CRIT/UNK = 1:
CRITICAL dbmysql.bestjob.com part_max_used=96.8%

如果要修改邮件报警的内容，就需要在 Centreon 中修改 service-notify-by-email 命令，具体修改方式在 8.5.5 节中已经做过详细介绍，这里不再说明。

至此，在 Centreon 中实现批量数据收集和监控报警的方法已经介绍完毕。总体来说，都是借助现有的脚本稍作修改实现的，整个过程比较简单。