অস্ট্রেলিয়ার Nagios থেকে Icinga2-তে মাইগ্রেশন

হাই সবাই

আমি একজন লিনাক্স সিস্টেম প্রশাসক, আমি 2015 সালে একটি স্বাধীন পেশাদার ভিসায় রাশিয়া থেকে অস্ট্রেলিয়ায় চলে এসেছি, তবে নিবন্ধটি কীভাবে একটি শূকরের জন্য একটি ট্র্যাক্টর শুরু করবেন সে সম্পর্কে থাকবে না। ইতিমধ্যেই পর্যাপ্ত এই ধরনের নিবন্ধ রয়েছে (তবুও, যদি আগ্রহ থাকে তবে আমি এটি সম্পর্কেও লিখব), তাই আমি কীভাবে অস্ট্রেলিয়ায় একজন লিনাক্স-অপস ইঞ্জিনিয়ার হিসাবে আমার কাজ করার সময়, একটি সিস্টেম মনিটরিং থেকে মাইগ্রেশন শুরু করেছি সে সম্পর্কে কথা বলতে চাই। অন্যের প্রতি. বিশেষ করে - Nagios => Icinga2.

নিবন্ধটি আংশিকভাবে প্রযুক্তিগত এবং আংশিকভাবে মানুষের সাথে যোগাযোগ এবং সংস্কৃতি এবং কাজের পদ্ধতির পার্থক্যের সাথে সম্পর্কিত সমস্যাগুলি সম্পর্কে।

দুর্ভাগ্যবশত, "কোড" ট্যাগটি পুতুল এবং ইয়ামল কোড হাইলাইট করে না, তাই আমাকে "প্লেনটেক্সট" ব্যবহার করতে হয়েছিল।

21শে ডিসেম্বর, 2016 এর সকালে কোন ঝামেলার লক্ষণ ছিল না। যথারীতি, আমি কাজের দিনের প্রথম আধ ঘন্টার মধ্যে একজন অনিবন্ধিত বেনামী ব্যবহারকারীর দ্বারা হাবর পড়ছিলাম, কফি পান করার সময়, এবং দেখতে পেলাম এই নিবন্ধটি.

যেহেতু আমার কোম্পানি Nagios ব্যবহার করেছে, দুবার চিন্তা না করে, আমি রেডমাইনে একটি টিকিট তৈরি করেছি এবং সাধারণ চ্যাটে লিঙ্কটি পাঠিয়েছি, কারণ আমি এটিকে গুরুত্বপূর্ণ বলে মনে করেছি। উদ্যোগটি এমনকি অস্ট্রেলিয়াতেও শাস্তিযোগ্য, তাই আমি এটি আবিষ্কার করার পর থেকে প্রধান প্রকৌশলী আমার উপর সমস্যাটি পিন করেছেন।

রেডমাইন থেকে স্ক্রিনশট

আমাদের বিভাগে, আপনার মতামত প্রকাশ করার আগে, পছন্দটি সুস্পষ্ট হলেও অন্তত একটি বিকল্প অফার করার প্রথা রয়েছে, তাই আমি গুগলিং করে শুরু করেছি বর্তমানে কোন ধরনের মনিটরিং সিস্টেমগুলি প্রাসঙ্গিক, যেহেতু রাশিয়ায় আমার শেষ কাজের জায়গায় আমি আমার নিজস্ব স্ব-লিখিত সিস্টেম ছিল, খুব আদিম, কিন্তু তা সত্ত্বেও বেশ কাজ করে এবং এটিতে নির্ধারিত সমস্ত কাজ সম্পাদন করে। পাইথন, সেন্ট পিটার্সবার্গ পলিটেকনিক এবং মেট্রোর নিয়ম। না, পাতাল রেল খারাপ. এটি ব্যক্তিগত (11 বছরের কাজ) এবং একটি পৃথক নিবন্ধের যোগ্য, কিন্তু এখন নয়।

আমার বর্তমান জায়গায় অবকাঠামো কনফিগারেশনে পরিবর্তন করার নিয়ম সম্পর্কে একটু। আমরা কোড নীতি হিসাবে পুতুল, গিটল্যাব এবং অবকাঠামো ব্যবহার করি, তাই:

• ভার্চুয়াল মেশিনে ম্যানুয়ালি কোনো ফাইল পরিবর্তন করে SSH-এর মাধ্যমে কোনো ম্যানুয়াল পরিবর্তন হয় না। তিন বছরের কাজের মধ্যে, আমি এর জন্য অনেকবার একটি টুপি দিয়ে আঘাত পেয়েছি, শেষ সময়টি এক সপ্তাহ আগে এবং আমি মনে করি না যে এটি শেষ সময় ছিল। ঠিক আছে, সত্যিই - কনফিগারে একটি লাইন সংশোধন করুন, পরিষেবাটি পুনরায় চালু করুন এবং দেখুন সমস্যাটি সমাধান হয়েছে কিনা - 10 সেকেন্ড। গিটল্যাবে একটি নতুন শাখা তৈরি করুন, পরিবর্তনগুলি করুন, পাপেটমাস্টারে কাজ করার জন্য r10k এর জন্য অপেক্ষা করুন, Puppet -environment=mybranch চালান এবং এটি সব কাজ না হওয়া পর্যন্ত আরও কয়েক মিনিট অপেক্ষা করুন - ন্যূনতম 5 মিনিট৷
• গিটল্যাবে একটি মার্জ রিকোয়েস্ট তৈরি করে যেকোনো পরিবর্তন করা হয় এবং কমপক্ষে একজন দলের সদস্য দ্বারা অনুমোদিত হতে হবে। দলের নেতৃত্ব দ্বারা সিদ্ধান্ত নেওয়া বড় পরিবর্তনের জন্য দুই বা তিনটি অনুমোদনের প্রয়োজন হয়।
• সমস্ত পরিবর্তনগুলি এক বা অন্যভাবে পাঠ্য (যেহেতু পুতুল প্রকাশ, স্ক্রিপ্ট এবং হিরা ডেটা পাঠ্য), বাইনারিগুলি অত্যন্ত নিরুৎসাহিত এবং এই জাতীয় ফাইলগুলি অনুমোদন করার জন্য একটি বাধ্যতামূলক কারণ থাকা দরকার।

সুতরাং, আমি বিবেচনা করা বিকল্পগুলি:

• মুনিন - যদি অবকাঠামোতে 10 টির বেশি সার্ভার থাকে তবে প্রশাসন নরকে পরিণত হয় (থেকে এই নিবন্ধটি এর. এটি পরীক্ষা করার আমার কোন বিশেষ ইচ্ছা ছিল না, তাই আমি এটির জন্য তার কথা নিয়েছিলাম)।
• জ্যাবিক্স - আমি রাশিয়ায় ফিরে এটিকে দীর্ঘদিন ধরে দেখছিলাম, কিন্তু তারপরে এটি আমার কাজের জন্য অপ্রয়োজনীয় ছিল। এখানে - কনফিগারেশন ম্যানেজার হিসাবে পাপেট এবং সংস্করণ নিয়ন্ত্রণ ব্যবস্থা হিসাবে গিটল্যাব ব্যবহারের কারণে বাতিল করতে হয়েছিল। সেই সময়ে, যতদূর আমি বুঝতে পেরেছি, Zabbix সমগ্র কনফিগারেশন ডাটাবেসে সঞ্চয় করে, এবং তাই বর্তমান অবস্থার অধীনে কনফিগারেশন কীভাবে পরিচালনা করা যায় এবং কীভাবে পরিবর্তনগুলি ট্র্যাক করা যায় তা পরিষ্কার ছিল না।
• ডিপার্টমেন্টের মেজাজ দ্বারা বিচার করে আমরা শেষ পর্যন্ত প্রমিথিউসের কাছে আসব, কিন্তু সেই সময়ে আমি এটি আয়ত্ত করিনি এবং সত্যিকারের কার্যকরী নমুনা (ধারণার প্রমাণ) প্রদর্শন করতে সক্ষম ছিলাম না, তাই আমাকে প্রত্যাখ্যান করতে হয়েছিল।
• এছাড়াও আরও বেশ কয়েকটি বিকল্প ছিল যেগুলির জন্য হয় সিস্টেমের সম্পূর্ণ পুনর্নির্মাণের প্রয়োজন ছিল, অথবা তাদের শৈশবকালে / পরিত্যক্ত ছিল এবং একই কারণে প্রত্যাখ্যান করা হয়েছিল।

শেষ পর্যন্ত, আমি তিনটি কারণে Icinga2 এ স্থির হয়েছি:

1 - Nrpe এর সাথে সামঞ্জস্য (একটি ক্লায়েন্ট পরিষেবা যা নাগিওস থেকে কমান্ড চেক চালায়)। এটি খুবই গুরুত্বপূর্ণ ছিল, কারণ সেই সময়ে আমাদের কাছে 135টি (এখন 2019 সালে 165টি আছে) কাস্টম-লিখিত পরিষেবা/চেকগুলির একটি গুচ্ছ সহ ভার্চুয়াল মেশিন ছিল, এবং এটিকে পুনরায় করা সত্যিই একটি কষ্টের বিষয় হবে৷
2 - সমস্ত কনফিগারেশন ফাইলগুলি পাঠ্য, যা এই বিষয়টিকে সম্পাদনা করা সহজ করে তোলে, কী যুক্ত বা মুছে ফেলা হয়েছে তা দেখার ক্ষমতা সহ মার্জ অনুরোধ তৈরি করে৷
3 একটি জীবন্ত ও উন্নয়নশীল ওপেনসোর্স প্রকল্প। আমরা সত্যিই ওপেনসোর্সকে ভালোবাসি এবং সমস্যা সমাধানের জন্য পুল রিকোয়েস্ট এবং ইস্যু তৈরি করে এতে সম্ভাব্য সব ধরনের অবদান রাখি।

সুতরাং, চলুন, Icinga2.

প্রথম যে বিষয়টির সম্মুখীন হতে হয়েছিল তা হল আমার সহকর্মীদের জড়তা। প্রত্যেকেই নাগিওস/নাগিওস (যদিও এখানেও তারা কীভাবে এটি উচ্চারণ করতে হয় সে বিষয়ে সমঝোতায় আসতে পারেনি) এবং চেকএমকে ইন্টারফেসে অভ্যস্ত। আইসিংগা ইন্টারফেসটি সম্পূর্ণ আলাদা দেখায় (এটি একটি বিয়োগ ছিল), তবে আক্ষরিক অর্থে যে কোনও প্যারামিটারের জন্য ফিল্টার ব্যবহার করে আপনার যা দেখতে হবে তা নমনীয়ভাবে কাস্টমাইজ করা সম্ভব (এটি একটি প্লাস ছিল, তবে আমি এটির জন্য অনেক লড়াই করেছি)।

ফিল্টার

স্ক্রল বারের আকারের সাথে স্ক্রোল ক্ষেত্রের আকারের অনুপাত অনুমান করুন।

দ্বিতীয়ত, প্রত্যেকেই একটি মনিটরে সম্পূর্ণ অবকাঠামো দেখতে অভ্যস্ত, কারণ CheckMk আপনাকে বেশ কয়েকটি Nagios হোস্টের সাথে কাজ করতে দেয়, কিন্তু Icinga ইন্টারফেস এটি করতে পারেনি (আসলে, এটি পারে, তবে নীচে আরও বেশি)। বিকল্পটি ছিল থ্রুক নামক কিছু, কিন্তু এটির ডিজাইন একজনকে ছাড়া সবাইকে দলে ঠেলে দিয়েছে - যিনি এটির পরামর্শ দিয়েছেন (আমি নয়)।

থ্রুক চুল্লিতে - দলের সর্বসম্মত সিদ্ধান্ত

কয়েকদিনের বুদ্ধিমত্তার পর, আমি ক্লাস্টার মনিটরিংয়ের ধারণাটি প্রস্তাব করেছি, যখন প্রোডাকশন জোনে একজন মাস্টার হোস্ট থাকে এবং দুটি স্লেভ থাকে - একটি ডেভ/টেস্টে এবং একটি বহিরাগত হোস্ট অন্য সরবরাহকারীতে থাকে যাতে আমাদের পর্যবেক্ষণ করা যায়। একটি ক্লায়েন্ট বা একটি বহিরাগত পর্যবেক্ষক দৃষ্টিকোণ থেকে সেবা. এই কনফিগারেশনটি একটি ওয়েব ইন্টারফেসে সমস্ত সমস্যা দেখা সম্ভব করেছে এবং বেশ ভাল কাজ করেছে, কিন্তু পাপেট... পাপেটের সমস্যা হল যে মাস্টার হোস্টকে এখন সিস্টেমের সমস্ত হোস্ট এবং পরিষেবা/চেক সম্পর্কে জানতে হবে এবং জোনগুলির মধ্যে তাদের বিতরণ করতে (dev-test, staging-prod, ext), কিন্তু Icinga API-এর মাধ্যমে পরিবর্তনগুলি পাঠাতে কয়েক সেকেন্ড সময় লাগে, কিন্তু সমস্ত হোস্টের জন্য সমস্ত পরিষেবার পাপেট ডিরেক্টরি সংকলন করতে কয়েক মিনিট সময় লাগে। এটি এখনও আমার উপর দোষারোপ করা হচ্ছে, যদিও আমি ইতিমধ্যেই বেশ কয়েকবার ব্যাখ্যা করেছি কিভাবে সবকিছু কাজ করে এবং কেন এটি এত সময় নেয়।

তৃতীয়ত, এখানে একগুচ্ছ স্নোফ্লেক্স রয়েছে - যেগুলি সাধারণ সিস্টেম থেকে আলাদা কারণ তাদের মধ্যে বিশেষ কিছু রয়েছে, তাই সাধারণ নিয়মগুলি তাদের ক্ষেত্রে প্রযোজ্য নয়। এটি একটি সম্মুখ আক্রমণ দ্বারা সমাধান করা হয়েছিল - যদি অ্যালার্ম থাকে তবে বাস্তবে সবকিছু ঠিকঠাক থাকে, তবে আমাকে আরও গভীরভাবে খনন করতে হবে এবং কেন এটি আমাকে সতর্ক করে তা খুঁজে বের করতে হবে, যদিও এটি উচিত নয়। বা তদ্বিপরীত - কেন নাগিওস আতঙ্কিত, কিন্তু আইসিংগা করে না।

চতুর্থত, নাগিওস এখানে আমার আগে তিন বছর কাজ করেছে এবং আমার নতুন ফ্যাংলাড হিপস্টার সিস্টেমের তুলনায় প্রাথমিকভাবে তার উপর বেশি আস্থা ছিল, তাই প্রতিবার আইসিঙ্গা আতঙ্কের জন্ম দিয়েছে, নাগিওস একই বিষয়ে উত্তেজিত না হওয়া পর্যন্ত কেউ কিছুই করেনি। কিন্তু খুব কমই Icinga Nagios এর চেয়ে আগে সত্যিকারের অ্যালার্ম তৈরি করেছে এবং আমি এটিকে একটি গুরুতর সমস্যা বলে মনে করি, যা আমি "উপসংহার" বিভাগে কথা বলব।

ফলস্বরূপ, কমিশনিং 5 মাসেরও বেশি সময় ধরে বিলম্বিত হয়েছিল (আসলে 28 জুন, 2018-এর জন্য পরিকল্পনা করা হয়েছিল - 3 ডিসেম্বর, 2018), প্রধানত "প্যারিটি চেক" এর কারণে - সেই বাজে কথা যখন নাগিওসে বেশ কয়েকটি পরিষেবা রয়েছে যা কেউ জানে না সম্পর্কে গত কয়েক বছর ধরে কিছুই শুনিনি, কিন্তু এখনই তারা বিনা কারণে সমালোচনা করেছে এবং আমাকে ব্যাখ্যা করতে হয়েছিল কেন তারা আমার প্যানেলে ছিল না এবং তাদের আইসিংগাতে যুক্ত করতে হয়েছিল যাতে "প্যারিটি চেক সম্পূর্ণ" (নাগিওসে সমস্ত পরিষেবা/চেক Icinga-এর পরিষেবা/চেকগুলির সাথে মিলে যায়)

বাস্তবায়ন:
প্রথমটি হল কোড বনাম ডেটা যুদ্ধ, যেমন পাপেট স্টাইল। সমস্ত ডেটা, একেবারে সবকিছু, অবশ্যই হিয়ারে থাকতে হবে এবং অন্য কিছু নয়৷ সমস্ত কোড .pp ফাইলে আছে। ভেরিয়েবল, বিমূর্ততা, ফাংশন - সবকিছু পিপিতে যায়।
ফলস্বরূপ, আমাদের কাছে একগুচ্ছ ভার্চুয়াল মেশিন রয়েছে (লেখার সময় 165টি) এবং 68টি ওয়েব অ্যাপ্লিকেশন রয়েছে যা কর্মক্ষমতা এবং SSL শংসাপত্রের বৈধতার জন্য নিরীক্ষণ করা প্রয়োজন৷ কিন্তু ঐতিহাসিক হেমোরয়েডের কারণে, নজরদারি অ্যাপ্লিকেশনের জন্য তথ্য একটি পৃথক গিটল্যাব সংগ্রহস্থল থেকে নেওয়া হয় এবং পাপেট 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
              }
            }
          }
        }
      }
    }
  }
}

হোস্ট এবং পরিষেবাগুলির জন্য কনফিগারেশন কোডটিও ভয়ানক দেখায়:

monitoring/config.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',
  }

}

আমি এখনও এই নুডলসগুলিতে কাজ করছি এবং যতটা সম্ভব উন্নত করছি। যাইহোক, এই কোডটিই আমাদের হিয়ারায় একটি সহজ এবং বোধগম্য সিনট্যাক্স ব্যবহার করার অনুমতি দেয়:

উপাত্ত

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_port — এটি ব্যবহার করুন, অন্যথায় 443। উদাহরণস্বরূপ, জ্যাবার ওয়েব ইন্টারফেস 9090 এ হ্যাং হয় এবং ইউনিফাই 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 }

অর্থাৎ, এসএসএল চেক সবসময় সক্রিয় থাকে। আমি সিনট্যাক্স প্রতিস্থাপন করে এটি সমাধান করেছি:

http_ssl: no

তথ্যও:

পেশাদাররা:

• আমাদের এখন একটি মনিটরিং সিস্টেম আছে, দুটি নয়, যেমনটি আমরা গত 7-8 মাস ধরে করেছি, অথবা একটি পুরানো এবং দুর্বল।
• হোস্ট/পরিষেবা(চেক) ডেটা স্ট্রাকচার এখন (আমার মতে) অনেক বেশি পঠনযোগ্য এবং বোধগম্য। অন্যদের জন্য, এটি এতটা সুস্পষ্ট ছিল না, তাই আমাকে স্থানীয় উইকিতে কয়েকটি পৃষ্ঠা পোস্ট করতে হয়েছিল যে এটি কীভাবে কাজ করে এবং কোথায় কী সম্পাদনা করতে হবে তা ব্যাখ্যা করতে।
• ভেরিয়েবল এবং ফাংশন ব্যবহার করে চেকগুলি নমনীয়ভাবে কনফিগার করা সম্ভব, উদাহরণস্বরূপ, http_regexp চেক করতে, কাঙ্ক্ষিত প্যাটার্ন, রিটার্ন কোড, url এবং পোর্ট হোস্ট সেটিংসে সেট করা যেতে পারে।
• বেশ কয়েকটি ড্যাশবোর্ড রয়েছে, যার প্রতিটির জন্য আপনি প্রদর্শিত অ্যালার্মগুলির আপনার নিজস্ব তালিকা নির্ধারণ করতে পারেন এবং পুতুল এবং মার্জ অনুরোধের মাধ্যমে এই সমস্ত পরিচালনা করতে পারেন।

কনস:

• দলের সদস্যদের জড়তা - নাগিওস কাজ করেছেন, কাজ করেছেন এবং কাজ করেছেন এবং আপনার এই ইসিঙ্গা ক্রমাগত বগি এবং ধীর। আপনি কিভাবে এখানে ইতিহাস দেখতে পারেন? ওহ, অভিশাপ, এটি আপডেট করা হয়নি... (আসল সমস্যা হল অ্যালার্ম ইতিহাস স্বয়ংক্রিয়ভাবে আপডেট হয় না, শুধুমাত্র F5 দ্বারা)
• সিস্টেমের জড়তা - যখন আমি ওয়েব ইন্টারফেসে "আপডেট" (এখনই চেক করুন) ক্লিক করি - এক্সিকিউশন ফলাফল মঙ্গল গ্রহের আবহাওয়ার উপর নির্ভর করে, বিশেষত জটিল পরিষেবাগুলির উপর যেগুলি চালানোর জন্য কয়েক সেকেন্ডের প্রয়োজন হয়৷ এমন ফলাফল স্বাভাবিক।
• সাধারণভাবে, পাশাপাশি দুটি সিস্টেমের অপারেশনের ছয় মাসের পরিসংখ্যান অনুসারে, নাগিওস সবসময় আইসিঙ্গার চেয়ে দ্রুত কাজ করেছে এবং এটি আমাকে সত্যিই বিরক্ত করেছে। আমার কাছে মনে হচ্ছে তারা টাইমারের সাথে কিছু গোলমাল করেছে এবং প্রতি পাঁচ মিনিটে চেক করা হয়, আসলে এটি প্রতি 5:30 বা এরকম কিছু ঘটে।
• আপনি যদি যেকোন সময়ে পরিষেবাটি পুনরায় চালু করেন (systemctl restart icinga2) - সেই সময়ে প্রগতিশীল সমস্ত চেক একটি গুরুতর অ্যালার্ম তৈরি করবে পর্দায় এবং বাইরে থেকে মনে হচ্ছে যেন সবকিছু পড়ে গেছে (নিশ্চিত বাগ).

কিন্তু সামগ্রিকভাবে, এটি কাজ করে।

উত্স: www.habr.com