Cara menggunakan Ansible untuk mengatur pemantauan sistem dengan Prometheus

Di musim panas 2017, saya menulis dua artikel tentang cara menggunakan Ansible. Setelah artikel pertama, saya berencana untuk menunjukkan contoh copy , systemd , service , apt , yum , virt , dan user modul. Namun saya memutuskan untuk memperketat cakupan bagian kedua untuk fokus menggunakan yum dan user modul. Saya menjelaskan cara menyiapkan server Git SSH dasar dan menjelajahi command , file , authorized_keys , yum , dan user modul. Dalam artikel ketiga ini, saya akan menggunakan Ansible untuk pemantauan sistem dengan solusi pemantauan sumber terbuka Prometheus.

Jika Anda mengikuti dua artikel pertama, Anda seharusnya memiliki:

1. Menginstal host kontrol yang memungkinkan
2. Membuat kunci SSH pada host kontrol yang memungkinkan
3. Menyebarkan kunci SSH ke semua mesin yang ingin Anda kelola
4. Akses SSH terbatas pada semua mesin
5. Memasang server Git SSH
6. Membuat git user, yang digunakan untuk memeriksa kode masuk dan keluar dari server Git SSH

Dari perspektif bisnis yang Anda miliki sekarang:

1. Pengelolaan host yang disederhanakan
2. Menghasilkan cara otomatis yang dapat diaudit, dapat diulang, untuk mengelola host tersebut
3. Mulai membuat jalur untuk pemulihan bencana (melalui buku pedoman Ansible)

Untuk membangun keterampilan yang dibutuhkan bisnis, Anda harus dapat melihat tren pemanfaatan sumber daya dari waktu ke waktu. Pada akhirnya, ini berarti menyiapkan semacam alat pemantauan. Ada banyak pilihan, termasuk Zabbix, Zenoss, Nagios, Prometheus, dan banyak lainnya. Saya telah bekerja dengan semua ini; solusi mana yang Anda pilih sebagian besar merupakan fungsi dari:

• Anggaran
• Waktu
• Keakraban

Alat pemantauan tanpa agen seperti Nagios dapat menggunakan sesuatu seperti SNMP untuk memantau host dan mengekspos metrik. Ada banyak keuntungan dari pendekatan ini (seperti tidak harus menginstal agen). Namun, saya telah menemukan bahwa Prometheus, meskipun berbasis agen, sangat mudah disiapkan dan menyediakan lebih banyak metrik, jadi itulah yang akan saya gunakan dalam artikel ini.

Menyiapkan Prometheus

Pengantar peran

Selengkapnya tentang Ansible

• Panduan memulai cepat untuk Ansible
• Lembar contekan yang memungkinkan
• Kursus online gratis:Kemungkinan penting
• Unduh dan instal Ansible
• eBook:Perusahaan otomatis
• eBuku:Memungkinkan untuk DevOps
• eBuku Gratis yang Memungkinkan
• Artikel terbaru yang memungkinkan

Sayangnya, tidak ada repositori manajer paket Linux yang tersedia untuk Prometheus (di luar Arch User Repository), atau setidaknya tidak ada yang terdaftar di halaman unduhan Prometheus. Ada gambar Docker yang tersedia, yang mungkin diinginkan dalam beberapa kasus, tetapi memerlukan menjalankan layanan tambahan jika Docker belum ada di mesin target. Untuk artikel ini, saya akan menyebarkan binari yang telah dikompilasi sebelumnya ke setiap host. Sebenarnya hanya ada dua file yang diperlukan untuk ini:biner itu sendiri dan systemd atau upstart init file.

Karena itu, satu buku pedoman instalasi Prometheus bisa sangat terlibat; oleh karena itu, ini akan menjadi saat yang tepat untuk membahas transisi ke Peran yang Mungkin. Sederhananya, selagi Anda bisa memiliki satu file YAML raksasa, peran adalah cara untuk memiliki kumpulan tugas yang lebih kecil yang dapat dimasukkan ke dalam permainan yang lebih besar . Ini lebih mudah dijelaskan melalui contoh. Misalnya, Anda memiliki ID pengguna yang harus ada di setiap host, namun beberapa server yang Anda kelola memerlukan server web, sementara yang lain mungkin memiliki server game. Anda mungkin memiliki dua pedoman berbeda untuk menangani ini. Perhatikan pedoman berikut:

Contoh 1:Create_user_with_ssh_key.yaml

- host:"{{ hostname }}"
  kumpulkan_fakta:false
  tugas:
    - nama:buat dan/atau ubah sandi {{ username}}
 user:
        name:"{{ username }}"
        password:<
    - name:copy ssh keys
      Authorized_key:
        key:" {{ item }}"
        pengguna:"{{ username }}"
        state:present
        eksklusif:False
      with_file:
        - ../files/user1_ssh_key .pub
        - ../files/user2_ssh_key.pub

Ada beberapa opsi yang tersedia saat mempertimbangkan masalah ini.

1. Salin kode ini ke awal setiap buku pedoman yang akan digunakan untuk membuat server yang berbeda
2. Jalankan buku pedoman ini secara manual, sebelum menjalankan pedoman konfigurasi server
3. Putar create_user_with_ssh_key.yaml menjadi tugas, yang kemudian dapat dimasukkan ke dalam peran menggunakan praktik standar Ansible

Opsi 1 tidak dapat dikelola dalam skala besar. Misalkan Anda harus mengubah kata sandi atau nama pengguna yang Anda buat. Anda harus menemukan semua pedoman yang menyertakan kode ini.

Opsi 2 adalah langkah ke arah yang benar. Namun, ini memerlukan langkah manual tambahan setiap kali Anda membuat server. Di laboratorium rumah, ini mungkin cukup. Namun, dalam lingkungan yang beragam dengan potensi beberapa orang untuk mengikuti proses yang sama untuk membuat server, opsi 2 bergantung pada administrator untuk mendokumentasikan dan dengan benar mengikuti semua langkah yang diperlukan untuk menghasilkan server yang berfungsi dengan spesifikasi yang tepat.

Untuk menutupi kekurangan tersebut, opsi 3 menggunakan solusi bawaan Ansible. Ini memiliki keuntungan menggunakan proses pembuatan server yang mudah direproduksi. Juga, saat mengaudit proses pembuatan (Anda adalah menggunakan kontrol sumber yang kami siapkan sebelumnya kan?), auditor berpotensi membuka satu file untuk menentukan file tugas apa yang secara otomatis digunakan oleh Ansible untuk menghasilkan server build. Pada akhirnya, ini akan menjadi pendekatan jangka panjang terbaik, dan merupakan ide bagus untuk mempelajari cara menggunakan peran dan membiasakan menggunakannya lebih awal dan sering.

Mengatur peran Anda dengan struktur direktori yang tepat sangat penting untuk kemampuan audit yang mudah dan kesuksesan Anda sendiri. Dokumentasi Ansible memiliki beberapa saran mengenai struktur dan tata letak direktori. Saya lebih suka tata letak direktori yang mirip dengan ini:

└── produksi
    ├── buku pedoman
    peran
        umum
        │   default
           file
        │   penangan
        │   tugas
           vars
        git_server
            
 penangan
           tugas
        │   vars
        pemantauan
        │   file
           penangan
 │   tugas
        │   template
        │   vars

Sistem Ansible untuk merancang peran dapat sedikit membingungkan pada awalnya, terutama karena ada banyak tempat di mana variabel dapat didefinisikan. Dalam situasi di atas, Dalam situasi di atas, saya bisa membuat group_vars direktori di production folder seperti ini:

└── produksi/
    group_vars/
        semua/
            vars.yaml

Menempatkan variabel dalam file ini akan membuatnya dapat diakses oleh peran apa pun yang dimasukkan ke dalam production map. Anda dapat memiliki vars di bawah setiap peran (seperti git_server ) dan dengan demikian membuatnya tersedia untuk semua tugas untuk peran tertentu:

└── lingkungan/
    produksi/
        peran/
        git_server/
            vars/
               main.yaml

Terakhir, Anda dapat menentukan variabel dalam permainan itu sendiri. Ini dapat dicakup secara lokal ke tugas tertentu atau ke permainan itu sendiri (sehingga mencakup beberapa tugas dalam permainan yang sama).

Untuk rekap, Anda dapat mendeklarasikan variabel:

1. Pada tingkat peran untuk semua tugas dalam peran tertentu
2. Pada level level buku pedoman untuk semua tugas dalam drama
3. Di dalam tugas individu
4. Di dalam file host Ansible (alias inventaris); ini digunakan terutama untuk variabel mesin dan tidak dibahas dalam diskusi ini

Memutuskan ruang lingkup mana untuk membuat variabel bisa jadi sulit, terutama bila diimbangi dengan kemudahan pemeliharaan. Anda dapat menempatkan semua variabel Anda di tingkat global, yang membuatnya mudah ditemukan tetapi mungkin bukan ide terbaik untuk lingkungan besar. Kebalikannya adalah menempatkan semua variabel di dalam tugas individu, tetapi ini bisa menjadi sakit kepala yang nyata jika Anda memiliki banyak variabel. Sebaiknya pertimbangkan kompromi dalam situasi khusus Anda.

Kembali ke buku pedoman kecil pada Contoh 1 di atas, kita mungkin membagi file kita seperti ini:

├── produksi
│   ├── buku pedoman
│   peran
│       umum
│       │   file
│        user1_ssh_key.pub
│       │   │   user2_ssh_key.pub
│       │   tugas
│           create_user.yaml         copy_ssh_key.yaml

Isi dari tasks file identik dengan baris dalam satu buku pedoman monolitik:

Contoh 2:create_user.yaml

- name:buat dan/atau ubah {{ username}}'s password
  user:
    name:"{{ username }}"
    password:<> 

Contoh 3:copy_ssh_key.yaml

- name:copy ssh keys
  Authorized_key:
    key:"{{ item }}"
    user:"{{ username }}"
    state:present
    eksklusif:Salah
  dengan_file:
    - user1_ssh_key.pub
    - user2_ssh_key.pub

Namun, apa yang telah berubah (berpotensi) adalah cara variabel diteruskan ke Ansible. Anda masih dapat menggunakan --extra-vars pilihan. Namun, untuk mendemonstrasikan pendekatan lain, kita akan menggunakan vars/main.yaml mengajukan. vars/main.yaml file memiliki konten berikut:

nama pengguna:'git'
sandi:6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt0
 Kata sandi harus berupa hash dan bukan kata sandi teks yang jelas. Untuk menghasilkan hash di sebagian besar versi Linux, Anda dapat menjalankan perintah Python berikut:
 
python2.7 -c 'import crypt,getpass; print crypt.crypt(getpass.getpass(), "$1$awerwass")' 
 

 Pada perintah di atas, garam sandi dilambangkan dengan awerwass . Ini hanya karakter acak yang saya tekan di keyboard. JANGAN GUNAKAN GARAM YANG SAMA DALAM PRODUKSI. 
 

 Agar tugas-tugas ini berjalan bersama, Anda perlu membuat main.yaml di tasks direktori. Itu harus memiliki konten berikut:
 
---
- termasuk:create_user.yaml
- termasuk:copy_ssh_key.yaml
 

 Terakhir, buat buku pedoman dengan konten berikut:
 
- host:git
  kumpulkan_fakta:false
  peran:
    43- peran:../roles/common
 

 Struktur direktori Anda akan terlihat seperti ini:
 
├── produksi
│   buku pedoman
│   │   common.yaml
│   peran
│       umum
        file
│       │   │   user1_ssh_key.pub
│         │   user2_ssh_key.pub
│           
│       │   tugas
│       │   │   copy_ssh_key.yaml
│           create_user.yaml
│        main.yaml
│       │   └── vars
│       │       main.yaml
 
Menyiapkan peran untuk Prometheus
 

 Sekarang setelah kita membahas dasar-dasar pembuatan peran, mari fokus pada pembuatan peran Prometheus. Seperti disebutkan sebelumnya, hanya dua file yang diperlukan untuk menjalankan setiap agen:file layanan (atau pemula), dan biner Prometheus. Berikut adalah contoh masing-masing:
 
Contoh 4:file systemd prometheus-node-exporter.service
 
[Unit]
Description=Prometheus Eksportir untuk metrik mesin.
After=network.target

[Layanan]
ExecStart=/usr/bin/prometheus_node_exporter 

[Instal]
WantedBy=multi-user.target
 
Contoh 5:file init pemula
 
# Jalankan prometheus_node_exporter

mulai saat startup

script
/usr/bin/prometheus_node_exporter
akhiri skrip
 
Contoh 6:file systemd prometheus.service (layanan server)
 
[Layanan]
Pengguna=prometheus
Grup=prometheus
ExecStart=/usr/bin/prometheus -config.file=/etc/prometheus/prometheus.yaml -storage.local. path=/var/lib/prometheus/data -storage.local.retention=8928h -storage.local.series-file-shrink-ratio=0.3
ExecReload=/bin/kill -HUP $MAINPID
 
[Instal]
WantedBy=multi-user.target
 

 Di lingkungan saya, dengan mesin Ubuntu (dengan dan tanpa system ) dan sejumlah besar mesin Red Hat dan Arch, saya perlu menulis buku pedoman untuk mendistribusikan skrip startup yang benar ke kotak masing-masing. Ada beberapa cara Anda dapat menentukan apakah akan menerapkan upstart atau systemd file layanan. Ansible memiliki fakta bawaan yang disebut ansible_service_mgr yang dapat digunakan untuk menentukan manajer layanan yang sesuai.
 

 Namun, saya memutuskan untuk mendemonstrasikan cara menggunakan skrip untuk memberikan Ansible dengan fakta selama Gather Facts panggung. Ini dikenal sebagai Fakta Lokal yang Mungkin. Fakta-fakta ini dibaca dari /etc/ansible/facts.d/ direktori. File dalam direktori ini dapat berupa JSON, INI, atau file yang dapat dieksekusi yang mengembalikan JSON. Mereka juga harus memiliki ekstensi file .fact . Skrip Bash sederhana yang saya tulis memeriksa systemd PID, dan jika ditemukan, mengembalikan JSON dengan nilai true , seperti yang terlihat pada Contoh 7:
 
Contoh 7:systemd_check.fact
 
#!/bin/bash
# Periksa systemd if present return { 'systemd':'true' } 

systemd_pid=`pidof systemd` 
if [ - z "$systemd_pid" ]; lalu
  echo '{ "systemd":"false" }'
else
  echo '{ "systemd":"true" }'
fi
 

 Dengan pemikiran ini, kita dapat mulai membangun tugas sederhana untuk membantu menyebarkan agen Prometheus. Untuk mencapai ini, facts lokal file harus disalin ke setiap server, skrip biner dan startup perlu diterapkan, dan layanan harus dimulai ulang. Di bawah ini adalah tugas yang akan menerapkan systemd_check.fact naskah.
 
Contoh 8:copy_local_facts.yaml
 
- name:Buat direktori fakta jika tidak ada
  file:
    path:/etc/ansible/facts.d
    state:directory

- nama:Salin file fakta systemd
  salin:
    src:systemd_check.fact
    tujuan:/etc/ansible/facts.d/systemd_check.fact
    mode:0755
 

 Sekarang fakta kustom kami telah dikerahkan, kami sekarang dapat menyebarkan binari yang dibutuhkan. Tapi pertama-tama, mari kita lihat file variabel yang akan digunakan untuk tugas-tugas ini. Dalam contoh ini, saya telah memilih untuk menggunakan vars/ direktori yang dilokalkan ke peran individu. Saat ini terlihat seperti ini:
 
Contoh 9:vars/main.yaml
 
exporter_binary:'prometheus_node_exporter'
exporter_binary_dest:'/usr/bin/prometheus_node_exporter'
exporter_service:'prometheus-node-exporter.service'
exporter_service_dest:' /prometheus-node-exporter.service'
exporter_upstart:'prometheus-node-exporter.conf'
exporter_upstart_dest:'/etc/init/prometheus-node-exporter.conf'

server_binary:'prometheus'
server_binary_dest:'/usr/bin/prometheus'
server_service:'prometheus.service'
server_service_dest:'/etc/systemd/system/prometheus.service' 

prometheus_user:'prometheus'
prometheus_server_name:'prometheus'

client_information_dict:
    'conan':'192.168.195.124:9100'
    'confluence':'192.168.195.170:9100'
    'smokeping':'192.168.195.120:9100'
    '7-repo':'192.168.195.157:9100'
    'server ':'192.168.195.9:9100'
    'bahtera':'192.168.195.2:9100'
    'kids-tv':'192.168.195.213:9100'
    'medi a-centre':'192.168.195.15:9100'
    'nas':'192.168.195.195:9100'
    'nextcloud':'192.168.199.117:9100'
    'git':'192.168.195.126:9100'
    'nuc':'192.168.195.90:9100'
    'desktop':'192.168.195.18:9100'
 

 Untuk saat ini, Anda dapat mengabaikan client_information_dict; yang akan ikut bermain nanti.
 
Contoh 10:tugas/setup_prometheus_node.yaml
 
---
- nama:salin biner ke {{ eksportir_biner_dest }}
  salin:
    src:"{{ eksportir_biner }}"
    tujuan:"{{ eksportir_biner_dest }}"
    mode:0755

- name:letakkan file layanan systemd pada tempatnya
  salin:
    src:"{{ export_service }}"
    tujuan:"{{ eksportir_layanan_dest }}"
  saat:
    - ansible_local.systemd_check.systemd =='true'

- name:salin conf pemula ke {{ eksportir_upstart_dest }}
  salin:
    src:"{{ eksportir_pemula }}"
    tujuan:"{{ eksportir_upstart_dest }}"
  saat:
    - ansible_local.systemd_check.systemd =='false'

- nama:perbarui systemd dan mulai ulang eksportir systemd
  systemd:
    daemon-reload:true
    diaktifkan:true
    status:dimulai ulang
    name:"{{ export_service }}"
  ketika:
    - ansible_local.systemd_check.systemd =='true'
   
- name:start eksportir sysv service 
  layanan:
    nama:"{{ exp orter_service }}"
    diaktifkan:true
    status:dimulai ulang
  saat: 
    - ansible_local.systemd_check.systemd =='false'
 

 Hal terpenting yang harus diperhatikan dalam tugas di atas adalah merujuk pada ansible_local.systemd_check.systemd . Ini dipecah menjadi konvensi penamaan berikut <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . Skrip Bash systemd_check.fact dijalankan selama Gather Facts panggung dan kemudian disimpan di ansible_local bagian dari semua Gather Facts . Untuk membuat keputusan berdasarkan fakta ini, saya memeriksa apakah itu true atau false . Klausa Ansible When memberi tahu Ansible untuk menjalankan tugas spesifik itu hanya jika kondisi tertentu terpenuhi. Sisa tugas ini harus cukup mudah. Ini menggunakan systemd dan modul layanan untuk memastikan bahwa manajer layanan yang sesuai dikonfigurasi untuk memulai prometheus_node_exporter .
 

 Tugas untuk menyiapkan server sangat mirip:
 
Contoh 11:tugas/setup_Prometheus_server.yaml
 
---
- name:salin biner server ke {{ server_binary_dest }}
  salin:
    src:"{{ server_binary }}"
    tujuan:"{ { server_binary_dest }}"
    mode:0755
  ketika:
    - inventory_hostname ='prometheus'

- name:Pastikan /etc/prometheus ada
 file:
    state:directory
    path:/etc/prometheus
    owner:"{{ prometheus_user }}"
    group:"{{ prometheus_user }}"
    mode :0755
  ketika:
    - inventory_hostname ='prometheus'

- name:place prometheus config
  template:
    src:prometheus.yaml.j2
    tujuan:/etc/prometheus/prometheus.yaml
  ketika:
    - inventory_hostname ='prometheus'

- nama:buat /var/lib/promtheus/data
  file:
    state:directory
    path:/var/lib/prometheus/data
    recurse:true
    owner:"{{ prometheus_user }}"
 grup:"{{ prometheus_user }}"
    mode:0755
  saat:
    - in ventory_hostname ='prometheus'

- name:letakkan file layanan systemd pada tempatnya
  copy:
    src:"{{ server_service }}"
    tujuan:"{{ server_service_dest }}"
  saat:
    - ansible_local.systemd_check.systemd =='true'
    - inventory_hostname ='prometheus'

- nama:perbarui systemd dan mulai ulang prometheus server systemd
  systemd:
    daemon-reload:true
    diaktifkan:true
    state:restart
    name:"{{ server_service }}"
  when :
    - ansible_local.systemd_check.systemd =='true'
    - inventory_hostname ='prometheus'

  notify:restart_prometheus_server
 

 Pengamat yang jeli akan melihat beberapa hal baru dalam tugas server.
 
 
notify: bagian
 
template: modul
 
 

 notify bagian adalah cara untuk memicu jenis peristiwa tertentu ketika kriteria tertentu terpenuhi. Ansible Handler paling sering digunakan untuk memicu restart layanan (yang persis seperti yang terjadi di atas). Handler disimpan dalam handlers direktori dalam peran. Handler saya sangat mendasar:
 
Contoh 12:handler/main.yaml
 
- name:restart_iptables
  service:
    name:iptables
    state:restart
    diaktifkan:true

- name:restart_prometheus_server
 service:
    name:"{{ server_service }}"
    status:dimulai ulang
    diaktifkan:true
 

 Ini memungkinkan saya untuk memulai kembali prometheus.service di server Prometheus.
 

 Poin kedua yang menarik di setup_prometheus_server.yaml adalah template: bagian. Templat di Ansible menawarkan beberapa keuntungan yang sangat bagus. Ansible menggunakan Jinja2 untuk mesin templatingnya; namun, penjelasan lengkap tentang Jinja berada di luar cakupan tutorial ini. Pada dasarnya, Anda dapat menggunakan template Jinja2 untuk memiliki satu file konfigurasi dengan variabel yang nilainya dihitung dan diganti selama pemutaran Ansible. Template konfigurasi Prometheus terlihat seperti ini:
 
Contoh 13:templates/prometheus.yaml.j2
 
global:
  scrape_interval:    15s # Setel interval scrape ke setiap 15 detik. Defaultnya adalah setiap 1 menit.
  evaluation_interval:15s # Evaluasi aturan setiap 15 detik. Defaultnya adalah setiap 1 menit.

  external_labels:
      monitor:'codelab-monitor'

scrape_configs:
  # Nama pekerjaan ditambahkan sebagai label `job=` ke deret waktu apa pun yang diambil dari konfigurasi ini.
  - job_name:'prometheus'

    static_configs:
      - target:['localhost:9090'] 
  - job_name:'nodes'
    static_configs:
{% for hostname, ip in client_information_dict.iteritems() %}
      - target:['{{ ip }}'] 
        labels:{'host':'{{ hostname }}' }
{% endfor %}
 

 Saat bagian template diproses, .j2 ekstensi secara otomatis dihapus sebelum menempatkan file pada sistem jarak jauh. For-loop kecil di template mengulangi client_information_dict , yang saya definisikan dalam file variabel saya sebelumnya. Itu hanya membuat daftar mesin virtual tempat saya ingin Prometheus mengumpulkan metrik.
 

 Catatan:Jika Anda ingin Prometheus menampilkan nama host dan DNS Anda diatur dengan benar, gunakan ini sebagai gantinya:
 
{% for hostname, ip in client_information_dict.iteritems() %}
      - target:['{{ hostname }}:9100']
        labels:{'host':'{{ hostname }}' }
{% endfor %}
 

 Hanya ada beberapa sentuhan akhir yang tersisa untuk menyelesaikan penyiapan Prometheus. Kita perlu membuat prometheus pengguna, (berpotensi) sesuaikan iptables, ikat semuanya di main.yaml , dan buat buku pedoman untuk dijalankan.
 

 Pengaturan Prometheus pengguna cukup mudah, dan akan sangat familiar jika Anda mengikuti artikel Ansible saya sebelumnya:
 
Contoh 14:tugas/create_prometheus_user.yaml
 
---
- name:Pastikan bahwa pengguna prometheus ada
  pengguna:
    name:"{{ prometheus_user }}"
    shell:/bin/false 

 Satu-satunya perbedaan utama di sini adalah saya menyetel shell ke /bin/false sehingga pengguna dapat menjalankan layanan tetapi tidak untuk login.
 

 Jika Anda menjalankan iptables, Anda harus memastikan untuk membuka port 9100 sehingga Prometheus dapat mengumpulkan metrik dari kliennya. Berikut adalah tugas sederhana untuk melakukannya:
 
Contoh 15:tugas/iptables.yaml
 
---
- name:Open port 9100
  lineinfile:
    dest:/etc/sysconfig/iptables
    insertbefore:"-A INPUT -j OS_FIREWALL_ALLOW"
    baris:"-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"
  notify:restart_iptables
  ketika:
    - ansible_os_family =="RedHat" 
 

 Catatan:Saya hanya menjalankan iptables di keluarga VM Red Hat saya. Jika Anda menjalankan iptables di semua VM Anda, hapus when: bagian.
 

 main.yaml terlihat seperti ini:
 
Contoh 16:tugas/main.yaml
 
--- 
- termasuk:create_prometheus_user.yaml
- termasuk:setup_prometheus_node.yaml
- termasuk:setup_prometheus_server.yaml
- termasuk:prometheus_iptables.yaml
 

 Bagian terakhir adalah membuat buku pedoman yang mencakup peran yang Anda butuhkan untuk menyelesaikan tugas Anda:
 
Contoh 17:playbooks/monitoring.yaml
 
- host:semua
  peran:
    - peran:../roles/common
    - peran:../roles/monitoring
 
Mengikat semuanya menjadi satu
 

 Saya tahu sepertinya banyak teks yang harus dilalui, tetapi konsep untuk menggunakan Ansible cukup mudah. Biasanya hanya masalah mengetahui bagaimana menyelesaikan tugas yang Anda tetapkan, dan kemudian menemukan modul Ansible yang sesuai untuk membantu menyelesaikannya. Jika Anda telah mengikuti panduan ini sepenuhnya, Anda harus memiliki tata letak yang mirip dengan ini:
 
├── buku pedoman
│   ├── git_server.yaml
│   monitoring.yaml
└── peran
    umum
    │ file
    │      systemd_check.fact
    │      user1_ssh_key.pub
    │      user2_ssh_key.pub
    │   penangan
       │   main.yaml
    │   tugas
    │      copy_systemd_facts.yaml
          main.yaml
    │  push_ssh_key.yaml
    │   │   root_ssh_key_only.yaml
    │   vars
       main.yaml
    pemantauan
 │   file
    │   │   prometheus
    │      prometheus_node_exporter
    │      prometheus-node-exporter.conf
    │  prometheus-node-exporter.service
    │   │   prometheus.service
          systemd_check.fact
       penangan
       │   utama .yaml
    │   tugas
    │      create_prometheus_user.yaml
    │     main.yaml
    │   │   ├── prometheus_iptables.yaml
          setup_prometheus_node.yaml
          setup_prometheus_server.yaml
    │ />    │   │   prometheus.yaml.j2
        └── vars
            └── main.yaml
 

 Untuk menjalankan buku pedoman Anda, masukkan:
 
[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 
 
 

 Anda sekarang harus dapat membuat pengguna, tekan ssh-keys, periksa keberadaan systemd , dan terapkan prometheus_node_exporter atau biner server Prometheus ke server yang sesuai. Prometheus harus diinisialisasi dengan konfigurasi dasar termasuk daftar host yang ditentukan di vars/main. yaml file dalam peran pemantauan.
 

 Selamat! Anda sekarang telah mengotomatiskan instalasi dan konfigurasi server Prometheus dasar dan mengonfigurasi host Anda untuk mulai mentransmisikan data. Sebagai efek samping yang menyenangkan, Anda juga telah secara efektif mendokumentasikan semua langkah yang diperlukan untuk mencapai tujuan Anda.
  

 Tambahan:Ketika saya menyusun seri ini, saya akan bekerja dengan menginstal Prometheus di OpenShift; namun, dalam meninjau dokumentasi untuk penginstal Ansible untuk OpenShift, saya menemukan bahwa itu sudah terkandung dalam buku pedoman dan merupakan opsi dalam penginstal.