Monitoring Sistemlerinize Sadece Mail attırmayın!! Zabbix ile Alarm Üreten Sensörler için Ansible Üzerinden Otomasyon Nasıl Yapılır ?

Aylar sonra bulduğum ilk fırsatta uzun zamandır gözlemlediğim ve herkesin işine yarayacağını düşündüğüm bir konu hakkın da yazmak istedim. İzleme sistemleri özelinde Zabbix, Otomasyon tarafında ise Ansible kullanarak monitör ettiğimiz sistemler tarafından üretilen alarmlar için nasıl otomatik aksiyon alabiliriz üzerine bir yazı olacak. Amacım olabildiğince detaya inerek hayatınızı kolaylaştırmak.

Bana göre izleme sistemlerin kullanımı hususunda dünya genelinde birçok haber alma teşkilatı ile yarışır durumdayız J O kadar çok Device monitör ediliyor ki sensör sayıları yüz binleri bulan ortamlar mevcut. Bu kadar çok sistemi izliyoruz da başımız göğe mi eriyor diye düşünenlerdenseniz o fikri aklınızdan çıkartın. Ummadığınız anda geriye dönük ya da anlık aldığınız bir metrik verisi sürekli yaşadığınız yada ileriye dönük yaşanma ihtimali olan X bir problemi tespit etmek ve çözümlemek açısından oldukça kritik. Genelde (çok güzel işler yapan yerler de var) monitoring sistemleri üzerinden alınan 2 temel aksiyon mevcut;

1. Set edilen threshold değerini geçen sensörler için mail, SMS ile bildirim
2. Service Manager entegrasyonları ile alarmı kayıt altına alarak otomatik ticket açtırma (Bir çok yerde bu da kullanılmıyor)

Bu yazının amacı ise buraya 3 ncü bir opsiyon eklemek

Set edilen threshold değerini geçen sensörler için önceden tanımlanmış otomatik aksiyon aldırmak.

Resim-1

Sistem Gereksinimleri neler ?

Öncelikle bütün uygulamalarınız Open Source yani ücretsiz.

• Zabbix Monitoring Uygulaması
• Ansible Tower yada AWX (Tower’ın Open Source Versiyonu)
• Tower-cli paketi

Alacağınız aksiyonu belirleme

İlk olarak üretilen hangi alarma karşılık nasıl bir aksiyon almak istiyorsanız bunun dizaynını yaparak playbook hazırlamanız gerekiyor. Ben örnek olması açısından en çok üretilen alarmlar dan biri olan CPU Utilizasyonunun %90’ı geçtiği senaryosunu seçtim ve buna göre bir playbook hazırlayacağım.

Hazırladığımız playbook ne yapacak ?

• Alarm üretildiğinde action trigger ederek sunucuya bağlanacak.
• Anlık olarak çalışan process lerin utilizasyon verilerini alacak
• Çıktıları bize mail olarak gönderecek

Farklı senaryolar için farklı playbook’lar hazırlamanız gerekiyor fakat hazırladığınız playbook’u farklı bir çok device üzerindeki aynı sensör için uygulayabilirsiniz.

Playbook Hazırlanması

Bu senaryoda client tarafındaki cihazı Windows olarak seçtim. Buna göre ilk önce cihaz üzerinde o anda çalışan process lerin ne kadarlık bir CPU tüketimi var onu almamız gerekiyor. Bunun için powershell kullanabiliriz.

Aşağıdaki script bize o anda çalışan process lerin CPU ve Memory utilizasyonun veriyor. Bu script’i cpu_mem_process_check.ps1 olarak kaydediyoruz ve Ansible Tower\AWX sunucumuz üzerinde bir yere koyuyoruz.

Ben /var/lib/awx/cpu_mem_process_check.ps1 altına attım.

Get-WmiObject Win32_PerfFormattedData_PerfProc_Process `
    | Where-Object { $_.name -inotmatch '_total|idle' } `
    | ForEach-Object { 
        "Process={0,-25} CPU_Usage={1,-12} Memory_Usage_(MB)={2,-16}" -f `
            $_.Name,$_.PercentProcessorTime,([math]::Round($_.WorkingSetPrivate/1Mb,2))   
    }

Artık playbook’umuzu yazmaya başlayalım.

Bağlanacağımız host bilgisini giriyoruz. Aynı playbook’u belki yüzlerce farklı server için kullanacağımız için hosts kısmına değişken ekliyoruz. Bu değişkeni bize zabbix verecek ve her seferinde hangi sunucuda CPU tüketimi arttıysa ona bağlanacağız. Buraya statik bir değişken atarsak izlediğiniz her host için ayrı ayrı plabook hazırlamak zorunda kalabilirsiniz.

---
# 
- name: Aksiyon_Al
  hosts: "{{ hosts }}"
  gather_facts: false

Sonrasında ise ilk aksiyonumuz daha önceden oluşturup “/var/lib/awx/” atına attığımız Powershell dosyasımızı sunucuya kopyalamak ve çalıştırmak. Win_copy ve Win_command modüllerini kullanıyoruz.

  tasks:
  - name: powershell_kopyala
    win_copy: src=/var/lib/awx/cpu_mem_process_check.ps1 dest=C:\cpu_mem_process_check.ps1
  - name: powersell_run
    win_command: powershell.exe -ExecutionPolicy ByPass -File C:\cpu_mem_process_check.ps1

Register diyerek Powershell çıktısını saklıyoruz ve copy content ile çıktıyı var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt altında sunucu adı ile kayıt altına alıyorux.

    register: exportfile1
  - local_action: copy content={{ exportfile1.stdout }} dest=/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt

4- Artık elimizde CPU ve Memory Tüketim verileri mevcut. Sıra bu çıktıları kendimize mail attırmakta. Ansible üzerindeki mail modülünü kullanarak dışarıdaki bir SMPT sunucusu üzerinden mail gönderimi yapabiliriz.

Local Host üzerinden mail modülünü çağırıyoruz

- name: Email Gonder
  hosts: localhost
  gather_facts: false

Playbook üzerinden tanımladığımız SMTP server üzerinden bir önceki task ile aldığımız CPU verisini maile attach ederek gönderiyoruz.

  tasks:
  - name: SMTP Mail Gönder
    mail: host=mail.farukterzioglu.net port=25 from="Ansible Bilgilendirme <ansible@farukterzioglu.net>" to="Faruk Terzioglu <faruk@farukterzioglu.net>" secure=never subject="Process List" body="Kaynak tüketimine sebep olan Process listesi ekteki gibidir" attach="/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt"
  - name: Dosyası Sil
    file: path=/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt state=absent

Playbook ‘umuzun son hali aşağıdaki gibi.

---
# 
- name: Aksiyon_Al
  hosts: "{{ hosts }}"
  gather_facts: false

  tasks:
  - name: powershell_kopyala
    win_copy: src=/var/lib/awx/cpu_mem_process_check.ps1 dest=C:\cpu_mem_process_check.ps1
  - name: powersell_run
    win_command: powershell.exe -ExecutionPolicy ByPass -File C:\cpu_mem_process_check.ps1
    register: exportfile1
  - local_action: copy content={{ exportfile1.stdout }} dest=/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt
 
- name: Email Gonder
  hosts: localhost
  gather_facts: false

  tasks:
  - name: SMTP Mail Gönder
    mail: host=mail.farukterzioglu.net port=25 from="Ansible Bilgilendirme <ansible@farukterzioglu.net>" to="Faruk Terzioglu <faruk@farukterzioglu.net>" secure=never subject="Process List" body="Kaynak tüketimine sebep olan Process listesi ekteki gibidir" attach="/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt"
  - name: Dosyası Sil
    file: path=/var/lib/awx/tmp/{{ hosts }}_cpu_mem.txt state=absent

Ansible Tower\AWX Üzerinde Template Oluşturma

Ansible’a bağlanarak yeni bir template create ederek Playbook kısmında oluşturduğumuz playbook’umuzu seçiyoruz.

Resim-2

Edit Survey üzerinden zabbix tarafından gelen host bilgisi değişkenini alabilmek için “hosts” adında bir değişken ekleyerek kaydediyoruz.

Resim-3

Template’i run edebilmemiz için adres çubuğu üzerinde yazan Template ID’sini not ediyoruz.

http://ansible.farukterzioglu.net/templates/job_template/336?template_search=page_size:20;order_by:name;type:workflow_job_template,job_template

Zabbix Server Üzerinden Ansible Üzerindeki Playbook’ları Yönetmek

Bunun için ilk önce zabbix sunucusu üzerine tower-cli paketini kuruyoruz. Action’ı run ederken zabbix sunucusu üzerinde komut çalıştıracağız. Zabbix sunucum Centos üzerinde çalışıyor. Paketi yüklemeden önce Epel repo sunu enable ediyorum.

yum install epel-release

tower-cli paketini yüklüyorum.

yum install ansible-tower-cli

tower-cli –version komutu ile kontrol ediyorum.

Resim-4

tower-cli üzerinden plabook çağırmadan önce cli üzerinden bağlanılacak olan ansible tower server host , username ve password bilgilerini girmeniz gerekiyor. Eğer bu tanımlamaları direk root kullanıcısı ile bağlı iken yaparsanız zabbix üzerinden action trigger ettiğinizde hata alacaksınız. Bunun sebebi zabbix’in kendi üzerinde bir komut çalıştırırken zabbix kullanıcısını kullanıyor olması.

cat /etc    /passwd diyerek check ettiğinizde zabbix kurulumu sırasında oluşturulan ve nologin olarak set edilmiş zabbix kullanıcısını görebilirsiniz.

Resim-5

Tower-cli üzerindeki config tanımlamalarını bu user üzerinden sunucuda yapmalıyız. Ilk önce konfig dosyamızı oluşturalım.

mkdir /var/lib/zabbix
touch /var/lib/zabbix/.tower_cli.cfg
chmod 777 /var/lib/zabbix/.tower_cli.cfg

Aşağıdaki komut ile zabbix kullanıcısına geçiş yapalım

su - zabbix -s /bin/bash

Konfigürasyon bilgilerini girelim

tower-cli config host http://ansibleserveradresiniz.com
tower-cli config insecure True
tower-cli config verify_ssl False
tower-cli config username ansible tower kullanıcı adınız
tower-cli config password ansible tower şifreniz

Artık cli üzerinden kontrol sağlayabiliyormuyuz diye test edebiliriz. Aşağıdaki komutu çalıştırdığınızda user’ların listesinin karşınıza gelmesi gerekiyor.

tower-cli user list

Zabbix Üzerinden Action Trigger Set Etmek

Bu kadar emek verdikten sonra sıra ne kolay aşamaya geldi. Zabbix üzerinden actions kısmına giriyoruz.

Configuration altından Actions’a girerek sağ üst köşedeki “Create Action” ‘a tıklıyoruz

Resim-6

Alacağımız aksiyona bir isim veriyoruz.

Resim-7

Conditions altında “add” diyerek ilk condition’ ınımızı ekliyoruz ve alarm üretildiğinde aksiyon alınmasını istediğimiz, monitör edilen sunucumuzu seçiyoruz.

Resim-8

İkinci bir condition ekleyerek “Type” kısmında “Trigger” ‘ı seçerek “High CPU Utilization (Over 90% for 5m) diyerek 5 dk’dan fazla uzun süren ve %90 CPU utilizasyonu yapıldığında alarm üreten sensörü seçiyoruz ve “Add” diyoruz.

Resim-9

Operations sekmesi altında Add butonuna basarak alıncak aksiyonu giriyoruz. Operation Type kısmı “Remote Command” olarak seçili durumda iken Current Host’u tıklayarak Execute on Zabbix Server yada Zabbix Server (Proxy) server’ı seçerek (Bizde tek zabbix mevcut bu yüzden farketmiyor) commands kısmına aşağıdaki komutu giriyoruz.

Tower-cli yada awx-cli farketmeksiniz her iki komutu da kullanabilirsiniz. Ben tanımları tower-cli ile yaptım fakat komutu fark olmadığını yani çalışacağını göstermek için awx-cli ile gönderiyorum.

Buraki önemli noktalardan biri “hosts={HOST.NAME}” kısmı. Daha önce bahsettiğim gibi çalıştıracağımız playbook içerisindeki hosts değişkenine veriyi Zabbix üzerindenki {HOST.NAME} değişkeni ile iletiyoruz ki her bir sunucu için ayrı ayrı playbook oluşturmak zorunda kalmayalım.

awx-cli job launch –job-template=336 –extra-vars=”hosts={HOST.NAME}”

Resim-10

Kontrol ettiğimizde aksiyonumuzun başarılı bir şekilde oluşturulduğunu görüyoruz.

Resim-11

Artık sıra test etmekte. Sunucumuz üzerinde kontrolleri bir CPU utilizasyonu yaratarak test edelim.

Resim-12

Zabbix dashboard üzerinden kontrol ettiğimizde alarm’ın oluştuğunu ve action’ın başarılı bir şekilde trigger edildiğini görüyoruz.

Resim-13

Ansible üzerinden de kontrol ederek başarılı bir şekilde çalıştığıdan emin oluyoruz.

Resim-14

Email’imizi kontrol ettiğimizde beklediğimiz mailin geldiğini gördükten sonra

Ekteki dökümanı açarak hangi process’ler CPU tüketimine sebep olmuş artık görebiliriz.

Resim-15

TAGs: Ansible, Ansible Tower, AWX, Playbook, Ansible Modules, Zabbix, Monitoring , Sensor