🥇მიგრაცია ნაგიოსიდან ავსტრალიაში, Icinga2-ში

გაუმარჯოს ყველას.

მე Linux-ის სისტემური ადმინისტრატორი ვარ, რუსეთიდან ავსტრალიაში დამოუკიდებელი პროფესიული ვიზით 2015 წელს გადავედი საცხოვრებლად, მაგრამ ეს სტატია არ ეხება იმას, თუ როგორ შეუძლია ღორს ტრაქტორის დაქოქვა. უკვე საკმარისი ასეთი სტატია არსებობს (თუმცა, თუ ინტერესი იქნება, ამაზეც დავწერ), ამიტომ მინდა მოგიყვეთ, თუ როგორ დავიწყე ავსტრალიაში Linux-ops ინჟინრად მუშაობისას ერთი მონიტორინგის სისტემიდან მეორეზე მიგრაცია. კერძოდ - Nagios => Icinga2.

სტატია ნაწილობრივ ტექნიკური ხასიათისაა და ნაწილობრივ ეხება ადამიანებთან კომუნიკაციას და კულტურასა და სამუშაო მეთოდებში არსებულ განსხვავებებთან დაკავშირებულ პრობლემებს.

სამწუხაროდ, „code“ ტეგი არ ხაზს უსვამს Puppet-სა და yaml კოდს, ამიტომ მომიწია „plaintext“-ის გამოყენება.

21 წლის 2016 დეკემბრის დილით არანაირი პრობლემა არ შეინიშნებოდა. როგორც ყოველთვის, სამუშაო დღის პირველი ნახევარი საათის განმავლობაში ვკითხულობდი Habr-ს, როგორც არარეგისტრირებული ანონიმური მომხმარებელი, ყავას ვსვამდი და წავაწყდი... ამ მუხლის.

რადგან ჩემი კომპანია შემთხვევით იყენებდა Nagios-ს, Redmine-ში ბილეთის შექმნასა და ბმულის ზოგად ჩატში გაგზავნაზე ორჯერ არ მიფიქრია, რადგან მნიშვნელოვნად მივიჩნიე. ინიციატივა დასჯადია ავსტრალიაშიც კი, ამიტომ წამყვანმა ინჟინერმა პრობლემა მე დამაბრალა, რადგან მე აღმოვაჩინე.

ეკრანის ანაბეჭდი Redmine-დან მიგრაცია ნაგიოსიდან Icinga2-ში ავსტრალიაში

ჩვენს განყოფილებაში, სანამ თქვენს აზრს გამოთქვამთ, ჩვეულებრივ, ერთი ალტერნატივის შეთავაზებაა, თუნდაც არჩევანი აშკარა იყოს, ამიტომ დავიწყე Google-ში იმით, თუ რომელი მონიტორინგის სისტემებია ამჟამად აქტუალური, რადგან რუსეთში, ჩემს ბოლო სამუშაო ადგილზე, მქონდა ჩემივე ხელნაკეთი სისტემა, ძალიან პრიმიტიული, მაგრამ მიუხედავად ამისა, საკმაოდ ფუნქციონალური და ასრულებდა მისთვის დაკისრებულ ყველა დავალებას. Python, სანქტ-პეტერბურგის პოლიტექნიკური უნივერსიტეტი და მეტრო მართავენ. არა, მეტრო საშინელებაა. ეს პირადია (11 წლიანი მუშაობა) და ცალკე სტატიის ღირსია, მაგრამ ახლა არა.

ცოტა რამ ჩემს ამჟამინდელ ადგილას ინფრასტრუქტურის კონფიგურაციაში ცვლილებების შეტანის წესების შესახებ. კოდის პრინციპად Puppet-ს, Gitlab-სა და ინფრასტრუქტურას ვიყენებთ, ამიტომ:

ვირტუალურ მანქანებზე ფაილების ხელით შეცვლით SSH-ის საშუალებით ხელით ცვლილებების შეტანა შეუძლებელია. სამი წლის განმავლობაში ამდენი გამაკრიტიკეს, ბოლო ერთი კვირის წინ იყო და არამგონია ბოლო შემთხვევა ყოფილიყო. სერიოზულად, კონფიგურაციაში ერთი ხაზის შეცვლას, სერვისის გადატვირთვას და პრობლემის გადაჭრას 10 წამი სჭირდება. შექმენით ახალი ფილიალი Gitlab-ში, დააჭირეთ ცვლილებების შეტანას, დაელოდეთ r10k-ის გაშვებას Puppetmaster-ზე, გაუშვით Puppet --environment=mybranch და დაელოდეთ კიდევ რამდენიმე წუთი, სანამ ყველაფერი გაშვებული იქნება - მინიმუმ 5 წუთი.
ნებისმიერი ცვლილება ხორციელდება Gitlab-ში შერწყმის მოთხოვნის შექმნით და უნდა დამტკიცდეს გუნდის სულ მცირე ერთი წევრის მიერ. გუნდის ხელმძღვანელის მიერ გადაწყვეტილი მნიშვნელოვანი ცვლილებებისთვის საჭიროა ორი ან სამი დამტკიცება.
ყველა ცვლილება ამა თუ იმ გზით ტექსტურია (რადგან Puppet-ის მანიფესტები, სკრიპტები და Hiera მონაცემები ტექსტურია), ბინარული ფაილების გამოყენება მკაცრად აკრძალულია და მათი დასამტკიცებლად მყარი მიზეზია საჭირო.

ასე რომ, ჩემს მიერ განხილული ვარიანტები იყო:

მუნინი - თუ ინფრასტრუქტურაში 10-ზე მეტი სერვერია, ადმინისტრირება ჯოჯოხეთად იქცევა (დან ამ მუხლის. ამის გამოცდის განსაკუთრებული სურვილი არ მქონდა, ამიტომ მის სიტყვას დავუჯერე).
Zabbix — დიდი ხანია, რუსეთში ყოფნისას ვფიქრობდი მასზე, მაგრამ ჩემი ამოცანებისთვის ზედმეტი აღმოჩნდა. აქ — მომიწია მისი გაუქმება, რადგან Puppet-ს კონფიგურაციის მენეჯერად და Gitlab-ს ვერსიების კონტროლის სისტემად ვიყენებდი. იმ დროს, რამდენადაც მე გავიგე, Zabbix მთელ კონფიგურაციას მონაცემთა ბაზაში ინახავს, ამიტომ გაუგებარი იყო, თუ როგორ უნდა მემართა კონფიგურაცია მიმდინარე პირობებში და როგორ უნდა თვალყური ადევნებულიყო ცვლილებებს.
პრომეთეს შესახებ საბოლოოდ ვიმსჯელებთ, განყოფილებაში არსებული განწყობით, მაგრამ იმ დროს მე ის არ დავეუფლე და ვერ ვაჩვენე რეალური სამუშაო ნიმუში (კონცეფციის დამტკიცება), ამიტომ მისი მიტოვება მომიწია.
ასევე არსებობდა რამდენიმე სხვა ვარიანტი, რომლებიც ან სისტემის სრულ რედიზაინს მოითხოვდა, ან საწყის/მიტოვებულ მდგომარეობაში იყო და იმავე მიზეზით უარყოფილ იქნა.

საბოლოოდ, Icinga2-ზე შევჩერდი სამი მიზეზის გამო:

1 — თავსებადობა Nrpe-სთან (კლიენტის სერვისი, რომელიც ამოწმებს Nagios-ის ბრძანებებს). ეს ძალიან მნიშვნელოვანი იყო, რადგან იმ დროს ჩვენ გვქონდა 135 (ახლა 2019 წელს არის 165) ვირტუალური მანქანა უამრავი მორგებული სერვისით/შემოწმებით და ამ ყველაფრის ხელახლა გაკეთება ნამდვილი ტკივილი იქნებოდა.
2 - ყველა კონფიგურაციის ფაილი ტექსტია, რაც ამარტივებს ამ საკითხის რედაქტირებას, ქმნის შერწყმის მოთხოვნებს იმის სანახავად, თუ რა დაემატა ან წაიშალა.
3 არის ცოცხალი და მზარდი OpenSource პროექტი. ჩვენ გვიყვარს OpenSource და წვლილი შევიტანეთ მასში პრობლემების გადასაჭრელად Pull Requests-ისა და Issues-ის შექმნით.

მაშ ასე, დავიწყეთ, Icinga2.

პირველი, რასაც შევეჯახე, ჩემი კოლეგების ინერცია იყო. ყველა მიჩვეული იყო Nagios/Nadzhios-ს (თუმცა აქაც კი ვერ შეთანხმდნენ მის წარმოთქმაზე) და CheckMK ინტერფეისს. Icinga-ს ინტერფეისი სრულიად განსხვავებულად გამოიყურება (ეს მინუსი იყო), მაგრამ შესაძლებელია მოქნილად მოარგოთ ის, რაც გჭირდებათ ფილტრების გამოყენებით, ფაქტიურად ნებისმიერი პარამეტრისთვის (ეს პლიუსი იყო, მაგრამ მე ამისთვის დიდი ბრძოლა გავწიე).

ფილტრები მიგრაცია ნაგიოსიდან Icinga2-ში ავსტრალიაში

შეაფასეთ გადახვევის ზოლის ზომისა და გადახვევის ველის ზომის თანაფარდობა.

მეორეც, ყველა მიჩვეული იყო მთელი ინფრასტრუქტურის ერთ მონიტორზე ნახვას, რადგან CheckMk საშუალებას იძლეოდა იმუშაოს რამდენიმე Nagios ჰოსტთან, მაგრამ Icinga-ს ინტერფეისს ამის გაკეთება არ შეეძლო (სინამდვილეში, შეეძლო, მაგრამ ამაზე ქვემოთ მოგიყვებით). ალტერნატივა იყო Thruk-ის სახელით ცნობილი რამ, მაგრამ მისმა დიზაინმა გუნდის ყველა წევრი გააგიჟა, გარდა ერთისა - მისი შემოთავაზების (არა მე).

თრუკის ცეცხლში ჩაგდება - გუნდის ერთსულოვანი გადაწყვეტილება მიგრაცია ნაგიოსიდან Icinga2-ში ავსტრალიაში

რამდენიმედღიანი იდეების გენერირების შემდეგ, გამიჩნდა კლასტერული მონიტორინგის იდეა, სადაც წარმოების ზონაში იქნება ერთი მთავარი ჰოსტი და ორი მონა - ერთი dev/test-ში და ერთი გარე ჰოსტი, რომელიც მდებარეობს სხვა პროვაიდერთან, ჩვენი სერვისების მონიტორინგის მიზნით კლიენტის ან გარე დამკვირვებლის თვალსაზრისით. ამ კონფიგურაციამ საშუალება მოგვცა, ყველა პრობლემა ერთ ვებ ინტერფეისში გვენახა და საკმაოდ კარგად მუშაობდა, მაგრამ Puppet... Puppet-ის პრობლემა ის იყო, რომ მთავარი ჰოსტი ახლა სისტემაში არსებული ყველა ჰოსტისა და სერვისის/შემოწმების შესახებ უნდა სცოდნოდა და მათი ზონებს შორის განაწილება უწევდა (dev-test, staging-prod, ext), მაგრამ ცვლილებების გაგზავნას Icinga API-ის საშუალებით რამდენიმე წამი სჭირდება, ხოლო Puppet-ის კატალოგის ყველა სერვისის შედგენას ყველა ჰოსტისთვის რამდენიმე წუთი სჭირდება. ამაში ისევ მე მადანაშაულებენ, თუმცა უკვე რამდენჯერმე ავხსენი, როგორ მუშაობს ეს ყველაფერი და რატომ სჭირდება ამდენ ხანს.

მესამე - ფიფქების თაიგული - ისეთი რამ, რაც ზოგადი სისტემიდან გამოირჩევა, რადგან მათ რაღაც განსაკუთრებული აქვთ, ამიტომ ზოგადი წესები მათზე არ ვრცელდება. ეს პრობლემა ფრონტალური შეტევით მოგვარდა - თუ სიგნალიზაციაა, მაგრამ სინამდვილეში ყველაფერი კარგადაა, მაშინ აქ უფრო ღრმად უნდა ჩაუღრმავდეთ და გაარკვიოთ, რატომ მაფრთხილებს, თუმცა არ უნდა მაფრთხილოს. ან პირიქით - რატომ ვარდება პანიკაში ნაგიოსი და რატომ არა იჩინგა.

მეოთხე, Nagios აქ ჩემზე სამი წლით ადრე მუშაობდა და თავდაპირველად უფრო მეტად ენდობოდნენ, ვიდრე ჩემს ახლადშექმნილ ჰიპსტერულ სისტემას, ამიტომ ყოველ ჯერზე, როცა Icinga პანიკას იწვევდა, არავინ არაფერს აკეთებდა, სანამ Nagios იმავე საკითხით არ აღფრთოვანდებოდა. თუმცა, Icinga ძალიან იშვიათად ავრცელებდა რეალურ განგაშს Nagios-მდე და ამას სერიოზულ ნაკლოვანებად მივიჩნევ, რომელსაც „დასკვნების“ განყოფილებაში განვიხილავ.

საბოლოოდ, ექსპლუატაციაში გაშვება 5 თვეზე მეტი ხნით გადაიდო (სინამდვილეში, დაგეგმილი იყო 28 წლის 2018 ივნისს - 3 წლის 2018 დეკემბერს), ძირითადად „პარიტეტის შემოწმების“ გამო - ეს სისულელეა, როცა Nagios-ში რამდენიმე სერვისია, რომელთა შესახებაც ბოლო რამდენიმე წლის განმავლობაში არავის არაფერი სმენია, მაგრამ ახლა, ჯანდაბა, უმიზეზოდ გამოსცეს კრიტიკა და მომიწია ახსნა, თუ რატომ არ არიან ისინი ჩემს პანელში და მომიწია მათი Icinga-ში დამატება, რათა „პარიტეტის შემოწმება დასრულებულიყო“ (Nagios-ში ყველა სერვისი/შემოწმება შეესაბამება Icinga-ში არსებულ სერვისებს/შემოწმებებს).

განხორციელება:
პირველი არის კოდისა და მონაცემების ომი, მაგალითად, Puppet Style-ში. ყველა მონაცემი, აბსოლუტურად ყველაფერი, უნდა იყოს Hiera-ში და სხვა არაფერი. ყველა კოდი .pp ფაილებშია. ცვლადები, აბსტრაქციები, ფუნქციები - ყველაფერი pp-ში მიდის.
შედეგად, ჩვენ გვაქვს ვირტუალური მანქანების ერთობლიობა (წერის მომენტისთვის 165) და 68 ვებ აპლიკაცია, რომელთა ფუნქციონირება და SSL სერთიფიკატების ვალიდურობა მონიტორინგს საჭიროებს. თუმცა, ისტორიული პრობლემების გამო, აპლიკაციების მონიტორინგის ინფორმაცია აღებულია ცალკე gitlab საცავიდან და მონაცემთა ფორმატი არ შეცვლილა Puppet 3-ის შემდეგ, რაც კონფიგურაციის დამატებით სირთულეებს ქმნის.

მარიონეტული კოდი აპლიკაციებისთვის, დაიცავით თვალები

define profiles::services::monitoring::docker_apps(
  Hash $app_list,
  Hash $apps_accessible_from,
  Hash $apps_access_list,
  Hash $webhost_defaults,
  Hash $webcheck_defaults,
  Hash $service_overrides,
  Hash $targets,
  Hash $app_checks,
  )
{
#### APPS ####
  $zone = $name
  $app_list.each | String $app_name, Hash $app_data |
  {

    $notify_group = { 'notify_group' => ($webcheck_defaults[$zone]['notify_group'] + pick($app_data['notify_group'], {} )) } # adds notifications for default group (systems) + any group defined in int/pm_docker_apps.eyaml

    $data = merge($webhost_defaults, $apps_accessible_from, $app_data)

    $site_domain = $app_data['site_domain']

    $regexp = pick($app_data['check_regex'], 'html')        # Pick a regex to check

    $check_url = $app_data['check_url'] ? {
      undef   => { 'http_uri' => '/' },
      default => { 'http_uri' => $app_data['check_url'] }
    }

    $check_regex = $regexp ?{
      'absent' => {},
      default  => {'http_expect_body_regex' => $regexp}
    }

    $site_domain.each | String $vhost, Hash $vdata | {        # Split an app by domains if there are two or more
      $vhost_name = {'http_vhost' => $vhost}

      $vars = $data['vars'] + $vhost_name + $check_regex + $check_url

      $web_ipaddress = is_array($vdata['web_ipaddress']) ? {  # Make IP-address an array if it's not, because askizzy has 2 ips and it's an array
        true  => $vdata['web_ipaddress'],
        false => [$vdata['web_ipaddress']],
      }

      $access_from_zones = [$zone] + $apps_access_list[$data['accessible_from']] # Merge default zone (where the app is defined) and extra zones if they exist
      $web_ipaddress.each | String $ip_address | {            # For each IP (if we have multiple)
        $suffix = length($web_ipaddress) ? {                  # If we have more than one - add IP as a suffix to this hostname to avoid duplicating resources
          1       => '',
          default => "_${ip_address}"
        }
        $octets = split($ip_address, '.')
        $ip_tag = "${octets[2]}.${octets[3]}" # Using last octet only causes a collision between nginx-vip 203.15.70.94 and ext. ip 49.255.194.94

        $access_from_zones.each | $zone_prefix |{
          $zone_target = $targets[$zone_prefix]

          $nginx_vip_name = "${zone_prefix}_nginx-vip-${ip_tag}" # If it's a host for ext - prefix becomes 'ext_' (ext_nginx-vip...)
          $nginx_host_vip = {
            $nginx_vip_name => {
              ensure        => present,
              target        => $zone_target,
              address       => $ip_address,
              check_command => 'hostalive',
              groups        => ['nginx_vip',],
            }
          }

          $ssl_vars = $app_checks['ssl']
          $regex_vars = $app_checks['http'] + $vars + $webcheck_defaults[$zone] + $notify_group

          if !defined( Profiles::Services::Monitoring::Host[$nginx_vip_name] ) {
          ensure_resources('profiles::services::monitoring::host', $nginx_host_vip)
          }

          if !defined( Icinga2::Object::Service["${nginx_vip_name}_ssl"] ) {
            icinga2::object::service {"${nginx_vip_name}_ssl":
              ensure         => $data['ensure'],
              assign         => ["host.name == $nginx_vip_name",],
              groups         => ['webchecks',],
              check_command  => 'ssl',
              check_interval => $service_overrides['ssl']['check_interval'],
              target         => $targets['services'],
              apply          => true,
              vars           => $ssl_vars
            }
          }
          if $regexp != 'absent'{
            if !defined(Icinga2::Object::Service["${vhost}${$suffix} regex"]){
              icinga2::object::service {"${vhost}${$suffix} regex":
                ensure          => $data['ensure'],
                assign          => ["match(*_nginx-vip-${ip_tag}, host.name)",],
                groups          => ['webchecks',],
                check_command   => 'http',
                check_interval  => $service_overrides['regex']['check_interval'],
                target          => $targets['services'],
                enable_flapping => true,
                apply           => true,
                vars            => $regex_vars
              }
            }
          }
        }
      }
    }
  }
}

მასპინძლისა და სერვისის კონფიგურაციის კოდიც საშინლად გამოიყურება:

მონიტორინგი/კონფიგურაცია.pp


class profiles::services::monitoring::config(
  Array $default_config,
  Array $hostgroups,
  Hash $hosts = {},
  Hash $host_defaults,
  Hash $services,
  Hash $service_defaults,
  Hash $service_overrides,
  Hash $webcheck_defaults,
  Hash $servicegroups,
  String $servicegroup_target,
  Hash $user_defaults,
  Hash $users,
  Hash $oncall,
  Hash $usergroup_defaults,
  Hash $usergroups,
  Hash $notifications,
  Hash $notification_defaults,
  Hash $notification_commands,
  Hash $timeperiods,
  Hash $webhost_defaults,
  Hash $apps_access_list,
  Hash $check_commands,
  Hash $hosts_api = {},
  Hash $targets = {},
  Hash $host_api_defaults = {},
)
{

  # Profiles::Services::Monitoring::Hostgroup <<| |>> # will be enabled when we move to icinga completely
#### APPS ####
  case $location {
    'int', 'ext': {
      $apps_by_zone = {}
    }
    'pm': {
      $int_apps         = hiera('int_docker_apps')
      $int_app_defaults = hiera('int_docker_app_common')

      $st_apps          = hiera('staging_docker_apps')
      $srs_apps         = hiera('pm_docker_apps_srs')
      $pm_apps          = hiera('pm_docker_apps') + $st_apps + $srs_apps
      $pm_app_defaults  = hiera('pm_docker_app_common')

      $apps_by_zone = {
        'int' => $int_apps,
        'pm'  => $pm_apps,
      }

      $app_access_by_zone = {
        'int' => {'accessible_from' => $int_app_defaults['accessible_from']},
        'pm'  => {'accessible_from' => $pm_app_defaults['accessible_from']},
      }
    }

    default: {
      fail('Please ensure the node has $location fact set (int, pm, ext)')
    }
  }

  file { '/etc/icinga2/conf.d/':
    ensure  => directory,
    recurse => true,
    purge   => true,
    owner   => 'icinga',
    group   => 'icinga',
    mode    => '0750',
    notify  => Service['icinga2'],
  }

  $default_config.each | String $file_name |{
    file {"/etc/icinga2/conf.d/${file_name}":
      ensure => present,
      source => "puppet:///modules/profiles/services/monitoring/default_config/${file_name}",
      owner  => 'icinga',
      group  => 'icinga',
      mode    => '0640',
    }
  }

  $app_checks = {
    'ssl' => $services['webchecks']['checks']['ssl']['vars'],
    'http' => $services['webchecks']['checks']['http_regexp']['vars']
  }

  $apps_by_zone.each | String $zone, Hash $app_list | {
    profiles::services::monitoring::docker_apps{$zone:
      app_list             => $app_list,
      apps_accessible_from => $app_access_by_zone[$zone],
      apps_access_list     => $apps_access_list,
      webhost_defaults     => $webhost_defaults,
      webcheck_defaults    => $webcheck_defaults,
      service_overrides    => $service_overrides,
      targets              => $targets,
      app_checks           => $app_checks,
    }
  }

####    HOSTS    ####

  # Profiles::Services::Monitoring::Host <<| |>> # This is for spaceship invasion when it's ready.
  $hosts_has_large_disks = query_nodes('mountpoints.*.size_bytes >= 1099511627776')

  $hosts.each | String $hostgroup, Hash $list_of_hosts_with_settings | {           # Splitting site lists by hostgroups - docker_host/gluster_host/etc
    $list_of_hosts_in_group = $list_of_hosts_with_settings['hosts']
    $hostgroup_settings     = $list_of_hosts_with_settings['settings']
    $merged_hostgroup_settings = deep_merge($host_defaults, $list_of_hosts_with_settings['settings'])
    $list_of_hosts_in_group.each | String $host_name, Hash $host_settings |{  # Splitting grouplists by hosts
      # Is this host in the array $hosts_has_large_disks ? If so set host.vars.has_large_disks
      if ( $hosts_has_large_disks.reduce(false) | $found, $value| { ( $value =~ "^${host_name}" ) or $found } ) {
        $vars_has_large_disks = { 'has_large_disks' => true }
      } else {
        $vars_has_large_disks = {}
      }
      $host_data = deep_merge($merged_hostgroup_settings, $host_settings)
      $hostgroup_settings_vars = pick($hostgroup_settings['vars'], {})
      $host_settings_vars = pick($host_settings['vars'], {})
      $host_notify_group = delete_undef_values($host_defaults['vars']['notify_group'] + $hostgroup_settings_vars['notify_group'] + $host_settings_vars['notify_group'])
      $host_data_vars = delete_undef_values(deep_merge($host_data['vars'] , {'notify_group' => $host_notify_group}, $vars_has_large_disks)) # Merging vars separately

      $hostgroups = delete_undef_values([$hostgroup] + $host_data['groups'])

      profiles::services::monitoring::host{$host_name:
        ensure             => $host_data['ensure'],
        display_name       => $host_data['display_name'],
        address            => $host_data['address'],
        groups             => $hostgroups,
        target             => $host_data['target'],
        check_command      => $host_data['check_command'],
        check_interval     => $host_data['check_interval'],
        max_check_attempts => $host_data['max_check_attempts'],
        vars               => $host_data_vars,
        template           => $host_data['template'],
      }
    }
  }
  if !empty($hosts_api){                                                                # All hosts managed by API
    $hosts_api.each | String $zone, Hash $hosts_api_zone | {                            # Split api hosts by zones
      $hosts_api_zone.each | String $hostgroup, Hash $list_of_hosts_with_settings | {   # Splitting site lists by hostgroups - docker_host/gluster_host/etc
        $list_of_hosts_in_group = $list_of_hosts_with_settings['hosts']
        $hostgroup_settings     = $list_of_hosts_with_settings['settings']
        $merged_hostgroup_settings = deep_merge($host_api_defaults, $list_of_hosts_with_settings['settings'])
        $list_of_hosts_in_group.each | String $host_name, Hash $host_settings |{        # Splitting grouplists by hosts
          # Is this host in the array $hosts_has_large_disks ? If so set host.vars.has_large_disks
          if ( $hosts_has_large_disks.reduce(false) | $found, $value| { ( $value =~ "^${host_name}" ) or $found } ) {
            $vars_has_large_disks = { 'has_large_disks' => true }
          } else {
            $vars_has_large_disks = {}
          }
          $host_data = deep_merge($merged_hostgroup_settings, $host_settings)
          $hostgroup_settings_vars = pick($hostgroup_settings['vars'], {})

          $host_settings_vars = pick($host_settings['vars'], {})
          $host_api_notify_group = delete_undef_values($host_defaults['vars']['notify_group'] + $hostgroup_settings_vars['notify_group'] + $host_settings_vars['notify_group'])
          $host_data_vars = delete_undef_values(deep_merge($host_data['vars'] , {'notify_group' => $host_api_notify_group}, $vars_has_large_disks))
          $hostgroups = delete_undef_values([$hostgroup] + $host_data['groups'])

          if defined(Profiles::Services::Monitoring::Host[$host_name]){
            $hostname = "${host_name}_from_${zone}"
          }
          else
          {
            $hostname = $host_name
          }
          profiles::services::monitoring::host{$hostname:
            ensure             => $host_data['ensure'],
            display_name       => $host_data['display_name'],
            address            => $host_data['address'],
            groups             => $hostgroups,
            target             => "${host_data['target_base']}/${zone}/hosts.conf",
            check_command      => $host_data['check_command'],
            check_interval     => $host_data['check_interval'],
            max_check_attempts => $host_data['max_check_attempts'],
            vars               => $host_data_vars,
            template           => $host_data['template'],
          }
        }
      }
    }
  }

#### END OF HOSTS ####

####   SERVICES   ####

  $services.each | String $service_group, Hash $s_list |{             # Service_group and list of services in that group
    $service_list = $s_list['checks']                                 # List of actual checks, separately from SG settings
    $service_list.each | String $service_name, Hash $data |{

      $merged_defaults = merge($service_defaults, $s_list['settings']) # global service defaults + service group defaults
      $merged_data = merge($merged_defaults, $data)

      $settings_vars = pick($s_list['settings']['vars'], {})
      $this_service_vars = pick($data['vars'], {})
      $all_service_vars = delete_undef_values($service_defaults['vars'] + $settings_vars + $this_service_vars)

      # If we override default check_timeout, but not nrpe_timeout, make nrpe_timeout the same as check_timeout
      if ( $merged_data['check_timeout'] and ! $this_service_vars['nrpe_timeout'] ) {
        # NB: Icinga will convert 1m to 60 automatically!
        $nrpe = { 'nrpe_timeout' => $merged_data['check_timeout'] }
      } else {
        $nrpe = {}
      }

      # By default we use nrpe and all commands are run via nrpe. So vars.nrpe_command = $service_name is a default value
      # If it's server-side Icinga command - we don't need 'nrpe_command'
      # but there is no harm to have that var and the code is shorter

      if $merged_data['check_command'] == 'nrpe'{
        $check_command = $merged_data['vars']['nrpe_command'] ? {
          undef   => { 'nrpe_command' => $service_name },
          default => { 'nrpe_command' => $merged_data['vars']['nrpe_command'] }
        }
      }else{
        $check_command = {}
      }

      # Assembling $vars from Global Default service settings, servicegroup settings, this particular check settings and let's not forget nrpe settings.
      if $all_service_vars['graphite_template'] {
        $graphite_template = {'check_command' => $all_service_vars['graphite_template']}
      }else{
        $graphite_template = {'check_command' => $service_name}
      }
      $service_notify = [] + pick($settings_vars['notify_group'], []) + pick($this_service_vars['notify_group'], []) # pick is required everywhere, otherwise becomes "The value '' cannot be converted to Numeric"

      $service_notify_group = $service_notify ? {
        []      => $service_defaults['vars']['notify_group'],
        default => $service_notify
      } # Assing default group (systems) if no other groups are defined

      $vars = $all_service_vars + $nrpe + $check_command + $graphite_template + {'notify_group' => $service_notify_group}

      # This needs to be merged separately, because merging it as part of MERGED_DATA overwrites arrays instead of merging them, so we lose some "assign" and "ignore" values

      $assign = delete_undef_values($service_defaults['assign'] + $s_list['settings']['assign'] + $data['assign'])
      $ignore = delete_undef_values($service_defaults['ignore'] + $s_list['settings']['ignore'] + $data['ignore'])

      icinga2::object::service {$service_name:
        ensure             => $merged_data['ensure'],
        apply              => $merged_data['apply'],
        enable_flapping    => $merged_data['enable_flapping'],
        assign             => $assign,
        ignore             => $ignore,
        groups             => [$service_group],
        check_command      => $merged_data['check_command'],
        check_interval     => $merged_data['check_interval'],
        check_timeout      => $merged_data['check_timeout'],
        check_period       => $merged_data['check_period'],
        display_name       => $merged_data['display_name'],
        event_command      => $merged_data['event_command'],
        retry_interval     => $merged_data['retry_interval'],
        max_check_attempts => $merged_data['max_check_attempts'],
        target             => $merged_data['target'],
        vars               => $vars,
        template           => $merged_data['template'],
      }
    }
  }
#### END OF SERVICES ####

#### OTHER BORING STUFF ####

  $servicegroups.each | $servicegroup, $description |{
    icinga2::object::servicegroup{ $servicegroup:
      target       => $servicegroup_target,
      display_name => $description
    }
  }

  $hostgroups.each| String $hostgroup |{
    profiles::services::monitoring::hostgroup { $hostgroup:}
  }

  $notifications.each | String $name, Hash $settings |{

    $assign = pick($notification_defaults['assign'], []) + $settings['assign']
    $ignore = pick($notification_defaults['ignore'], []) + $settings['ignore']

    $merged_settings = $settings + $notification_defaults

    icinga2::object::notification{$name:
      target       => $merged_settings['target'],
      apply        => $merged_settings['apply'],
      apply_target => $merged_settings['apply_target'],
      command      => $merged_settings['command'],
      interval     => $merged_settings['interval'],
      states       => $merged_settings['states'],
      types        => $merged_settings['types'],
      assign       => delete_undef_values($assign),
      ignore       => delete_undef_values($ignore),
      user_groups  => $merged_settings['user_groups'],
      period       => $merged_settings['period'],
      vars         => $merged_settings['vars'],
    }
  }

  # Merging notification settings for users with other settings
  $users_oncall = deep_merge($users, $oncall)
  # Magic. Do not touch.
  create_resources('icinga2::object::user', $users_oncall, $user_defaults)
  create_resources('icinga2::object::usergroup', $usergroups, $usergroup_defaults)
  create_resources('icinga2::object::timeperiod',$timeperiods)
  create_resources('icinga2::object::checkcommand', $check_commands)
  create_resources('icinga2::object::notificationcommand', $notification_commands)

  profiles::services::sudoers { 'icinga_runs_ping_l2':
    ensure            => present,
    sudoersd_template => 'profiles/os/redhat/centos7/sudoers/icinga.erb',
  }

}

მე ჯერ კიდევ ვმუშაობ ამ ნუდლზე და ვცდილობ მის გაუმჯობესებას, რამდენადაც შემიძლია. თუმცა, სწორედ ამ კოდმა მომცა საშუალება გამომეყენებინა მარტივი და გასაგები სინტაქსი Hiera-ში:

მონაცემთა

profiles::services::monitoring::config::services:
  perf_checks:
    settings:
      check_interval: '2m'
      assign:
        - 'host.vars.type == linux'
    checks:
      procs: {}
      load: {}
      memory: {}
      disk:
        check_interval: '5m'
        vars:
          notification_period: '24x7'
      disk_iops:
        vars:
          notifications:
            - 'silent'
      cpu:
        vars:
          notifications:
            - 'silent'
      dns_fqdn:
        check_interval: '15m'
        ignore:
          - 'xenserver in host.groups'
        vars:
          notifications:
            - 'silent'
      iftraffic_nrpe:
        vars:
          notifications:
            - 'silent'
  logging:
    settings:
      assign:
        - 'logserver in host.groups'
    checks:
       rsyslog: {}
      nginx_limit_req_other: {}
      nginx_limit_req_s2s: {}
      nginx_limit_req_s2x: {}
      nginx_limit_req_srs: {}
     logstash: {}
      logstash_api:
        vars:
          notifications:
            - 'silent'

ყველა შემოწმება დაყოფილია ჯგუფებად, თითოეულ ჯგუფს აქვს ნაგულისხმევი პარამეტრები, როგორიცაა სად და რა სიხშირით ჩატარდეს ეს შემოწმებები, რა შეტყობინებები გაიგზავნოს და ვის მიმართ.

თითოეულ შემოწმებაში შეგიძლიათ ხელახლა განსაზღვროთ ნებისმიერი პარამეტრი და ეს ყველაფერი საბოლოოდ ყველა შემოწმების ნაგულისხმევ პარამეტრებს ემატება. სწორედ ამიტომ არის ასეთი არეულობა დაწერილი config.pp ფაილში - ხდება ყველა ნაგულისხმევი პარამეტრის შერწყმა ჯგუფურ პარამეტრებთან და შემდეგ თითოეულ ინდივიდუალურ შემოწმებასთან.

კიდევ ერთი ძალიან მნიშვნელოვანი ცვლილება იყო პარამეტრებში ფუნქციების გამოყენების შესაძლებლობა, მაგალითად, http_regex-ის შესამოწმებლად პორტის, მისამართისა და URL-ის შეცვლის ფუნქცია.

http_regexp:
  assign:
    - 'host.vars.http_regex'
    - 'static_sites in host.groups'
  check_command: 'http'
  check_interval: '1m'
  retry_interval: '20s'
  max_check_attempts: 6
  http_port: '{{ if(host.vars.http_port) { return host.vars.http_port } else { return 443 } }}'
  vars:
    notification_period: 'host.vars.notification_period'
    http_vhost: '{{ if(host.vars.http_vhost) { return host.vars.http_vhost } else { return host.name } }}'
    http_ssl: '{{ if(host.vars.http_ssl) { return false } else { return true } }}'
    http_expect_body_regex: 'host.vars.http_regex'
    http_uri: '{{ if(host.vars.http_uri) { return host.vars.http_uri } else { return "/" } }}'
    http_onredirect: 'follow'
    http_warn_time: 8
    http_critical_time: 15
    http_timeout: 30
    http_sni: true

ეს ნიშნავს, რომ თუ მასპინძლის განმარტებაში არის ცვლადი http_პორტი — გამოიყენეთ იგი, სხვა შემთხვევაში 443. მაგალითად, jabber-ის ვებ ინტერფეისი 9090-ზეა გათიშული, ხოლო Unifi — 7443-ზე.
http_vhost ნიშნავს DNS-ის იგნორირებას და ამ მისამართის აღებას.
თუ მასპინძელი მიუთითებს uri-ს, მაშინ მიჰყევით მას, წინააღმდეგ შემთხვევაში გამოიყენეთ "/".

http_ssl-თან დაკავშირებით სასაცილო ამბავი მოხდა - ამ ინფექციას არ სურდა მოთხოვნის შემთხვევაში გათიშვა. დიდი ხნის განმავლობაში ამ ხაზზე ვიყავი გაჭედილი, სანამ არ მივხვდი, რომ ჰოსტის განმარტებაში არსებულ ცვლადში:

http_ssl: false

გამოსახულებაში ჩანაცვლებულია

if(host.vars.http_ssl) { return false } else { return true }

როგორც ყალბი და ბოლოს გამოდის, რომ

if(false) { return false } else { return true }

ანუ, ssl შემოწმება ყოველთვის აქტიურია. ეს პრობლემა მოგვარდა შემდეგი სინტაქსის შეცვლით:

http_ssl: no

დასკვნები:

დადებითი:

ახლა ჩვენ გვაქვს ერთი მონიტორინგის სისტემა და არა ორი, როგორც ბოლო 7-8 თვის განმავლობაში გვქონდა, ან ერთი, მოძველებული და დაუცველი.
hosts/services(checks) მონაცემთა სტრუქტურა ახლა (ჩემი აზრით) ბევრად უფრო იკითხება და გასაგებია. სხვებისთვის ეს ასე აშკარა არ იყო, ამიტომ ადგილობრივ ვიკიში რამდენიმე გვერდის გაკეთება მომიწია, რათა ამეხსნა, თუ როგორ მუშაობს ეს ყველაფერი და რა სად უნდა შემესწორებინა.
არსებობს შემოწმებების მოქნილი კონფიგურაციის შესაძლებლობა ცვლადებისა და ფუნქციების გამოყენებით, მაგალითად, http_regexp შემოწმებისთვის, მასპინძლის პარამეტრებში შეიძლება მითითებული იყოს საძიებო ნიმუში, დაბრუნების კოდი, URL და პორტი.
არსებობს რამდენიმე დაფა, რომელთაგან თითოეულისთვის შეგიძლიათ განსაზღვროთ ნაჩვენები სიგნალიზაციის საკუთარი სია და მართოთ ეს ყველაფერი Puppet-ისა და შერწყმის მოთხოვნების საშუალებით.

Cons:

გუნდის წევრების ინერცია - Nagios მუშაობდა, მუშაობდა და მუშაობდა, თქვენი ეს Isinga კი გამუდმებით ხარვეზებით მუშაობს და ანელებს. და როგორ შემიძლია აქ ისტორიის ნახვა? ჯანდაბა, ის არ განახლდება... (ნამდვილი პრობლემა ის არის, რომ სიგნალიზაციის ისტორია ავტომატურად არ განახლდება, მხოლოდ F5-ით)
სისტემის ინერცია - როდესაც ვებ ინტერფეისში ვაწკაპუნებ „განახლებაზე“ (შეამოწმე ახლა) - შესრულების შედეგი დამოკიდებულია მარსზე არსებულ ამინდზე, განსაკუთრებით რთულ სერვისებზე, რომელთა შესრულებას ათობით წამი სჭირდება. ასეთი შედეგი ნორმალურია.
ზოგადად, ორი სისტემის გვერდიგვერდ მუშაობის ნახევარწლიური სტატისტიკის მიხედვით, Nagios ყოველთვის უფრო სწრაფად მუშაობდა, ვიდრე Icinga და ეს ძალიან მაღიზიანებდა. მეჩვენება, რომ ტაიმერებთან დაკავშირებით რაღაც აურიეს და შემოწმება ყოველ ხუთ წუთში ერთხელ ხდება სინამდვილეში ყოველ 5:30-ზე ან რაღაც მსგავსში.
თუ სერვისს ნებისმიერ დროს გადატვირთავთ (systemctl restart icinga2) - ყველა შემოწმება, რომელიც იმ დროს მიმდინარეობდა, კრიტიკულ სიგნალიზაციას გამოიმუშავებს. ეკრანზე და გვერდიდან ისე ჩანს, თითქოს ყველაფერი ჩამოინგრა (დადასტურებული შეცდომა).

მაგრამ საერთო ჯამში, ეს მუშაობს.

წყარო: www.habr.com

მიგრაცია ნაგიოსიდან Icinga2-ში ავსტრალიაში

იური გაგარინი