Настройте удаленные наборы правил с Puppet - PullRequest
0 голосов
/ 17 ноября 2018

Я пытаюсь автоматизировать Prometheus node_exporter и мой сервер Prometheus.Для node_exporter я написал модуль для установки всех необходимых пакетов, установите $::ipaddress на основе facter и еще немного ..

Теперь я хотел бы убедиться, что собранныйинформация ($hostname, $job_name, [...]) из узла-приложения экспортируется в соответствующий удаленный файл конфигурации Prometheus, но я хочу, чтобы этот шаг выполнялся асинхронно, например, с последующим запуском агента Puppet наPrometheus Server.

Я пытался ориентировать классы по направлению к модулю puppetlabs/logrotate, который в основном делает следующее:

logrotate / init.pp

class logrotate (
  String $ensure              = present,
  Boolean $hieramerge         = false,
  Boolean $manage_cron_daily  = true,
  Boolean $create_base_rules  = true,
  Boolean $purge_configdir    = false,
  String $package             = 'logrotate',
  Hash $rules                 = {},
) {
  do some stuff
}    

logrotate / rules.pp

class logrotate::rules ($rules = $::logrotate::rules){
  #assert_private()
  create_resources('logrotate::rule', $rules)
}

logrotate / rule.pp

define logrotate::rule(
  Pattern[/^[a-zA-Z0-9\._-]+$/] $rulename           = $title,
  Enum['present','absent'] $ensure                  = 'present',
  Optional[Logrotate::Path] $path                   = undef,
  (...)
  ) {
    do some stuff
  } 

Сокращенный мой *Модули 1029 * (node_exporter) и ni_prometheus в настоящее время очень похожи на logrotate:

ni_trending / init.pp

class ni_trending (
  $hostname       = $::fqdn,
  $listen_address = $::ipaddress,
  $listen_port    = 51118,
) { 

) inherits ni_trending::params {

anchor { 'ni_trending::start': }
  ->class { 'ni_trending::package': }
  ->class { 'ni_trending::config':
    (...)
    listen_address => $listen_address,
    listen_port    => $listen_port,
    (...)
    }
  ->class { 'ni_trending::service': }
  ->class { ' ni_trending::prometheus':
    (...)
    hostname     => $hostname,
    listen_port  => $listen_port,
    (...)
    }
    ->anchor { 'ni_trending::end': }
}

ni_trending /prometheus.pp

class ni_trending::prometheus (
  Hash $options        = {},
) {

  ni_prometheus::nodeexporterrule { 'node_exporter' :
    ensure      => pick_default($options['ensure'], 'present'),
    hostname    => pick_default($options['hostname'], $ni_trending::hostname),
    listen_port => pick_default($options['hostname'], $ni_trending::listen_port),
    }
}

ni_prometheus / nodeexporterrules.pp

class ni_prometheus::nodeexporterrules ($rules = $::ni_prometheus::nodeexporterrules) {

  create_resources('ni_prometheus::nodeexporterrule', $nodeexporterrules)

}

ni_prometheus / nodeexporterrule.pp

define ni_prometheus::nodeexporterrule (
  $job_name                         = $title,
  Enum['present','absent'] $ensure  = 'present',
  $hostname                         = $hostname,
  $listen_port                      = $listen_port,
) {

  file_line { "prometheus-${job_name}" :
    path  => "/etc/prometheus/${job_name}.list",
    after => 'hosts:',
    line  => "${hostname}:${listen_port}",
  }
}

Но это будет работать только тогда, когда я локально применяю node_exporter на Prometheus Master - не в том случае, если на внешнем компьютере включен класс ni_trending::prometheus, что имеет смысл для меня - потому что он явно чувствует, что чего-то не хватает.:-) Как мне заставить это работать?

Спасибо!

1 Ответ

0 голосов
/ 17 ноября 2018

Это звучит как работа для экспортируемых ресурсов (что составляет два за один день!).Это средство для создания каталога одного узла для генерирования ресурсов, которые могут быть применены к другим узлам (а также, по желанию, к самому экспортирующему узлу).Я до сих пор не отслеживаю детали того, что и где вы хотите управлять, поэтому вот более общий пример: ведение файла локальных хостов.

Общий пример

Предположим, мы хотим автоматически управлятьФайл hosts, в котором перечислены все наши узлы под управлением.Puppet имеет встроенный ресурс Host, представляющий одну запись в файле hosts.Мы используем это, когда каждый узел под управлением экспортирует соответствующий хост-ресурс.Примерно так будет происходить внутри класса, включенного в каждый узел:

@@host { "$hostname": ip => $ipaddress; }

Префикс @@ помечает ресурс как экспортированный.Он не применяется к текущему целевому узлу, если только через механизм, который я опишу через минуту.$hostname и $ipaddress - это просто факты, представленные целевым узлом, и они разрешаются в этом контексте.Также обратите внимание, что заголовок ресурса является глобально уникальным: у каждого целевого узла есть свое имя хоста, поэтому все экспортированные ресурсы Host, которые применяются к разным целевым узлам, будут иметь разные заголовки.

Затем по отдельности каждыйузел, которому нужны все эти Host записи, примененные к нему, импортирует их в свой собственный каталог с помощью экспортированного сборщика ресурсов :

<<|Host|>>

узлов, которыеЭкспорт этих ресурсов также может собрать некоторые или все из них.Кроме того, есть способы быть более избирательными в отношении того, какие ресурсы собираются;см. ссылку выше.

...