Puppet 和 Nagios：高级配置路线图
Puppet 长期以来一直提供内置的 Nagios 支持。当与导出的资源结合使用时，Puppet 非常适合管理智能的 Nagios 配置，其中节点会被自动盘点和监控。James Turnbull 撰写的优秀著作《Pro Puppet》相当完整地介绍了为了朝这个方向发展所需的安装和配置步骤，因此我不会在此重复这些信息。相反，本文重点介绍了 Nagios 类型的一些不太理想的默认行为，并详细介绍了我的解决方案，该解决方案可以实现更简洁的文件系统和更高的性能。
并非所有资源都应该被导出！我花了很长时间才弄明白这一点，这真令人尴尬。就像清单文件中定义的资源一样，导出的资源必须是唯一的。例如，假设我们有节点 foo 和 bar，我们想将它们归类到名为 "PMF" 的 Nagios 主机组中。乍一看，将以下代码添加到 foo 的清单文件中似乎是可行的方法
@@nagios_hostgroup { "PMF":
ensure => present,
hostgroup_members +> [ $::hostname ]
}
从理论上讲，当第一个节点编译其清单时，资源将被导出到数据库，但是下一个节点的编译将报错，提示资源重复错误。因此，我们将避免导出由此特定类型创建的资源。相反，我们将通过 nagios_host 类型的 hostgroup 参数来管理我们的主机组成员关系。
如果不是 Pieter Barrezeele 的博客 (http://pieter.barrezeele.be/2009/05/11/puppet-and-nagios)，我可能最终会屈服于 Puppet 相当低效的资源存储方法，该方法通过其 Nagios 类型进行管理。默认情况下，这些位被维护在根据所用类型硬编码的文件路径中。例如，所有基于 nagios_service 类型的资源都将被收集并存储在 /etc/nagios/nagios_service.cfg 等文件中。出于性能原因，我希望每个收集到的资源都存储在自己的文件路径中，命名约定如下
<base_directory>/<type>_<h3>_<hostname>.cfg
此外，我希望我的文件名由所有小写字母组成，空格替换为下划线。首先，让我们在清单文件中添加最少的代码片段，以便使用 nagios_host 类型导出和收集资源（列表 1 和 2）。
列表 1. modules/nagios/manifests/init.pp
# This class will be used by the nagios server
class nagios {
service { nagios:
ensure => running,
enable => true,
}
# Be sure to include this directory in your nagios.cfg
# with the cfg_dir directive
file { resource-d:
path => '/etc/nagios/resource.d',
ensure => directory,
owner => 'nagios',
}
# Collect the nagios_host resources
Nagios_host <<||>> {
require => File[resource-d],
notify => Service[nagios],
}
}
# All agents (including the nagios server) will use this
class nagios::export {
@@nagios_host { $::hostname:
address => $::ipaddress,
check_command => 'check_host_alive!3000.0,80%!5000.0,100%!10',
target => "/etc/nagios/resource.d/host_${::hostname}.cfg",
}
}
由于已发表文章固有的空间限制，所有代码都将尽可能保持简洁，同时符合 Puppet 模块的结构。但是，不会尝试重现能够管理 Nagios 实例的完整模块。相反，我专注于本文引言中定义的概念。如果您需要 Puppet 模块的介绍，请参阅 http://docs.puppetlabs.com。
让我们检查一下到目前为止我们定义的优缺点。从积极的方面来看，所有代理都将导出 nagios_host 资源。Nagios 服务器在编译其清单后，将收集每个资源，将其存储在唯一的文件中，并刷新 Nagios 服务。乍一看，似乎我们的工作已经完成。不幸的是，我们的解决方案存在以下问题和缺点
-
Nagios 将无法读取新创建的 .cfg 文件，因为 Puppet Agent 将在以 root 用户身份运行时创建它们。
-
nagios_host 类型的 target 参数需要太多的“协调”。我们不应该为了确保我们的 target 指向正确的文件并且没有空格和/或混合大小写等令人不快的东西而如此努力。
-
address 参数使用 ipaddress 事实的值进行硬编码。尽管这在某些环境中可能是可以接受的，但我们确实应该允许更大的灵活性。
-
无法利用 Nagios 主机组。
-
Puppet 将无法清除我们导出的资源，因为我们没有使用 target 参数的默认行为。
为了解决这些问题，让我们编写一个新的定义，作为我们计划使用的所有 Nagios 类型的包装器。在我们开始之前，让我们确保我们理解最重要的问题——新生成的 .cfg 文件的文件所有权和权限问题。由于这些文件是通过每个关联的 Nagios 类型的 target 参数创建的，因此它们将由 Puppet 运行的用户写入磁盘。这意味着它们将归 root 用户/组所有，并且 Nagios 将没有权限读取它们（因为我知道您没有以 root 身份运行 Nagios，对吗？）。尽管有些人选择通过 Puppet 的 exec 类型来 chown 这些文件来解决这个问题，但我们将做一些更简洁的事情，以保持 Puppet 最伟大的属性，即抽象。
在我经历了大量的失败的“好主意”和困惑之后，我清楚地认识到，如果每个新创建的 .cfg 文件都作为文件资源进行管理，那么控制每个文件的所有权和权限将非常简单。我们可以将这些文件资源的创建折叠到我们的包装器定义中，并像我们对 Nagios 类型所做的那样导出它们。然后可以轻松地定义每个文件资源，并具有适当的属性，以及要求它们对应的 Nagios 类型。当我们的 Nagios 服务器收集这些资源时，它将首先从收集的 Nagios 类型创建文件，然后再管理文件的属性。让我们检查一下新的和重构的代码。
nagios::params 类
首先，让我们在中心位置定义一些变量。这样做将有助于我们“偷懒”，而不必在清单文件的各个区域中匹配值（列表 3）。
列表 3. modules/nagios/manifests/params.pp
class nagios::params {
$resource_dir = '/etc/nagios/resource.d'
$user = 'nagios'
case $::operatingsystem {
debian: {
$service = 'nagios3'
}
solaris: {
$service = 'cswnagios'
}
default: {
fail("This module is not supported on $::operatingsystem")
}
}
}
nagios::resource 定义及其友元
我们的自定义资源定义将充当所有 Nagios 类型的包装器。由于空间限制，包含的代码仅涵盖 nagios_host 和 nagios_hostgroup 类型。当然，此定义可以并且应该扩展以支持我们计划使用的每个 Nagios 类型。每个受支持的类型都在其自己的适当命名的定义中表示，该定义位于 nagios::resource 命名空间下 1 级。还包括一个 nagios::resource::file 定义，它负责创建之前提到的 .cfg 文件（列表 4-7）。
列表 4. modules/nagios/manifests/resource.pp
define nagios::resource(
$export,
$type,
$host_use = 'generic-host',
$ensure = 'present',
$owner = 'nagios',
$address = '',
$hostgroups = '',
$check_command = ''
) {
include nagios::params
# figure out where to write the file
# replace spaces with an underscore and convert
# everything to lowercase
$target = inline_template("${nagios::params::resource_dir}
↪/${type}_<%=name.gsub(/\\s+/, '_').downcase %>.cfg")
case $export {
true, false: {}
default: { fail("The export parameter must be
↪set to true or false.") }
}
case $type {
host: {
nagios::resource::host { $name:
ensure => $ensure,
use => $host_use,
check_command => $check_command,
address => $address,
hostgroups => $hostgroups,
target => $target,
export => $export,
}
}
hostgroup: {
nagios::resource::hostgroup { $name:
ensure => $ensure,
target => $target,
export => $export,
}
}
default: {
fail("Unknown type passed to this define: $type")
}
}
# create or export the file resource needed to support
# the nagios type above
nagios::resource::file { $target:
ensure => $ensure,
export => $export,
resource_tag => "nagios_${type}",
requires => "Nagios_${type}[${name}]",
}
}
define nagios::resource::file(
$resource_tag,
$requires,
$export = true,
$ensure = 'present',
) {
include nagios::params
if $export {
@@file { $name:
ensure => $ensure,
tag => $resource_tag,
owner => $nagios::params::user,
require => $requires,
}
} else {
file { $name:
ensure => $ensure,
tag => $resource_tag,
owner => $nagios::params::user,
require => $requires,
}
}
}
define nagios::resource::host(
$address,
$hostgroups,
$export,
$target,
$check_command,
$use,
$ensure = 'present'
) {
include nagios::params
if $export {
@@nagios_host { $name:
ensure => $ensure,
address => $address,
check_command => $check_command,
use => $use,
target => $target,
hostgroups => $hostgroups ? {
'' => undef,
default => $hostgroups,
},
}
} else {
nagios_host { $name:
ensure => $ensure,
address => $address,
check_command => $check_command,
use => $use,
target => $target,
require => File[$nagios::params::resource_dir],
hostgroups => $hostgroups ? {
'' => undef,
default => $hostgroups,
},
}
}
}
define nagios::resource::hostgroup(
$target,
$ensure = 'present',
$hostgroup_alias = '',
$export = false
) {
include nagios::params
if $export {
fail("It is not appropriate to export the Nagios_hostgroup
↪type since it will result in duplicate resources.")
} else {
nagios_hostgroup { $name:
ensure => $ensure,
target => $target,
require => File[$nagios::params::resource_dir],
}
}
}
列表 8 显示了我们重构的 nagios::export 类，该类旨在供所有节点使用。请注意，我们不再直接利用 nagios_host 类型。相反，我们调用我们新创建的 nagios::resource 定义。address 和 hostgroups 参数都将使用合理的默认值，除非它们被节点范围的变量覆盖。另请注意，不再需要 target 参数，因为我们的 nagios::resource 定义为我们执行了繁重的工作。
列表 8. modules/nagios/manifests/export.pp
# All agents (including the nagios server) will use this
class nagios::export {
nagios::resource { $::hostname:
type => 'host',
address => inline_template("<%= has_variable?('my_nagios_interface') ?
↪eval('ipaddress_' + my_nagios_interface) : ipaddress %>"),
hostgroups => inline_template("<%= has_variable?('my_nagios_hostgroups') ?
↪$my_nagios_hostgroups : 'Other' %>"),
check_command => 'check_host_alive!3000.0,80%!5000.0,100%!10',
export => true,
}
}
如您所见，nagios::export 类已准备好扩展到 nagios::resource 定义支持的任何类型的资源。每当我们希望所有客户端都导出特定资源时，我们只需在此处添加它，只要满足以下要求即可
-
资源名称必须是唯一的。
-
必须设置 type 参数。
-
export 参数必须设置为 true 值。
现在我们的所有代理都在导出 nagios_host 资源，我们可以专注于收集方面。
提示：简明扼要的 Nagios 服务描述
Nagios 中高效的服务名称
当您扩展 nagios::resource 以支持 nagios_service 类型时，您可能需要考虑使用内联 ERB 模板来处理 service_description 参数。以下代码从 Nagios 中显示的描述中删除最后一个单词（应该是主机名）
service_description => inline_template("<%= name.gsub(/\\w+$/,
↪'').chomp(' ') %>"),
现在，以唯一标题定义的资源，例如 “Puppet Agent $::hostname”，在 Nagios 中显示为 “Puppet Agent”。
过期、收集和清除导出的资源到目前为止，我们的 Nagios 服务器的工作仅仅是收集导出的资源。在现实世界中，它监控的节点会因为各种原因而定期退役。当节点退役时，我想确保相关的 Nagios 对象被删除，并且相应的数据库记录被删除。根据 Puppet 的文档，只有在利用默认 target 位置时，才能从收集器中清除这些资源 (http://docs.puppetlabs.com/references/stable/type.html#nagioshost)。即便如此，我还是不乐意看到孤立的数据库记录被遗留下来，并决定通过一些 Puppet 函数和一些基本的类排序来解决这个问题。在我们深入探讨之前，必须理解一些工作流程和术语
-
过期：通过将其 "ensure" 参数的值设置为 "absent"，Nagios 资源将“过期”。
-
收集：由于其 "ensure" 参数的值，资源将从收集器中删除。
-
清除：所有与过期的主机关联的数据库记录都将被删除。
排序显然非常重要。为了确保每个任务的正确执行，我们将把每个工作单元分解为它自己的类，并混合使用 "include" 和 "require" 函数。使用 Puppet 术语，我们现在可以将此“过期、收集，然后清除”工作流程表示如下
-
nagios 类 require nagios::expire_resources 类。
-
nagios 类 include nagios::purge_resources 类。
-
nagios::purge_resources 类 require nagios::collect_resources 类。
现在，让我们看一下一些自定义函数，expire_exported 和 purge_exported。这些函数（为 PostgreSQL 编写）执行过期主机及其资源所需的数据库操作。它们都对节点范围的变量 $my_nagios_purge_hosts 进行操作，该变量应包含主机名数组。如果使用，则此变量应放置在 Nagios 服务器的节点定义中的某处。例如
node corona {
$my_nagios_purge_hosts = [ 'foo', 'bar', 'baz' ]
include nagios
}
定义了此节点范围的变量后，您的（深情地命名的）Nagios 服务器将在删除上述三个主机的所有资源后重新配置自身（列表 9 和 10）。
列表 9. nagios/lib/puppet/parser/functions/expire_exported.rb
Puppet::Parser::Functions::newfunction(
:expire_exported,
:doc => "Sets a host's resources to ensure =>
↪absent as part of a purge work-flow.") do |args|
require 'rubygems'
require 'pg'
require 'puppet'
raise Puppet::ParseError, "Missing hostname." if args.empty?
hosts = args.flatten
begin
conn = PGconn.open(:dbname => 'puppet', :user => 'postgres')
hosts.each do |host|
Puppet.notice("Expiring resources for host: #{host}")
conn.exec("SELECT id FROM hosts WHERE name =
↪\'#{host}\'") do |host_id|
raise "Too many hosts" if host_id.ntuples > 1
conn.exec("SELECT id FROM param_names WHERE name =
↪'ensure'") do |param_id|
conn.exec("SELECT id FROM resources WHERE host_id =
↪#{host_id.values.flatten[0].to_i}") do |results|
resource_ids = []
results.each do |row|
resource_ids << Hash[*row.to_a.flatten]
end
resource_ids.each do |resource|
conn.exec("UPDATE param_values SET VALUE =
↪'absent' WHERE resource_id = #{resource['id']} AND
↪param_name_id = #{param_id.values}")
end
end
end
end
end
rescue => e
Puppet.notice(e.message)
ensure
conn.close
end
end
# This function will be used by the exported
# resources collector (the nagios box)
Puppet::Parser::Functions::newfunction(:purge_exported,
↪:doc => "delete expired resources.") do |args|
require 'rubygems'
require 'pg'
require 'puppet'
raise Puppet::ParseError, "Missing hostname." if args.empty?
hosts = args.flatten
begin
conn = PGconn.open(:dbname => 'puppet', :user => 'postgres')
hosts.each do |host|
Puppet.notice("Purging expired resources for host: #{host}")
conn.exec("SELECT id FROM hosts WHERE name =
↪\'#{host}\'") do |host_id|
raise "Too many hosts" if host_id.ntuples > 1
conn.exec("SELECT id FROM resources WHERE host_id =
↪#{host_id.values.flatten[0].to_i}") do |results|
resource_ids = []
results.each do |row|
resource_ids << Hash[*row.to_a.flatten]
end
resource_ids.each do |resource|
conn.exec("DELETE FROM param_values WHERE
↪resource_id = #{resource['id']}")
conn.exec("DELETE FROM resources WHERE id =
↪#{resource['id']}")
end
end
conn.exec("DELETE FROM hosts WHERE id =
↪#{host_id.values}")
end
end
rescue => e
Puppet.notice(e.message)
ensure
conn.close
end
end
现在，让我们看看重构的 nagios 类和相关代码（列表 11-14）。
列表 11. modules/nagios/manifests/init.pp
# This class will be used by the nagios server
class nagios {
include nagios::params
require nagios::expire_resources
include nagios::purge_resources
service { $nagios::params::service:
ensure => running,
enable => true,
}
# nagios.cfg needs this specified via the cfg_dir directive
file { $nagios::params::resource_dir:
ensure => directory,
owner => $nagios::params::user,
}
# Local Nagios resources
nagios::resource { [ 'Nagios Servers', 'Puppet Servers', 'Other' ]:
type => hostgroup,
export => false;
}
}
class nagios::expire_resources {
if $my_nagios_purge_hosts {
expire_exported($my_nagios_purge_hosts)
}
}
class nagios::purge_resources {
require nagios::collect_resources
if $my_nagios_purge_hosts {
purge_exported($my_nagios_purge_hosts)
}
}
class nagios::collect_resources {
include nagios::params
Nagios_host <<||>> {
require => $nagios::params::resource_dir,
notify => Service[$nagios::params::service],
}
File <<| tag == nagios_host |>> {
notify => Service[$nagios::params::service],
}
}
基本构建块现在已就位。扩展 nagios::resources，将类插入到您的 nagios 模块中并放松。如果节点 MIA 并且需要清除，请将其放入您的 $my_nagios_purge_hosts 数组中即可完成。直到下次，愿您的 Nagios 仪表板保持绿色，警报少之又少。
