Come utilizzare Ansible per impostare il monitoraggio del sistema con Prometheus

Nell'estate 2017, ho scritto due articoli pratici sull'utilizzo di Ansible. Dopo il primo articolo, ho pianificato di mostrare esempi di copy , systemd , service , apt , yum , virt e user moduli. Ma ho deciso di restringere l'ambito della seconda parte per concentrarmi sull'utilizzo di yum e user moduli. Ho spiegato come configurare un server Git SSH di base ed ho esplorato il command , file , authorized_keys , yum e user moduli. In questo terzo articolo, parlerò di Ansible per il monitoraggio del sistema con la soluzione di monitoraggio open source Prometheus.

Se hai seguito questi primi due articoli, dovresti avere:

1. Installato un host di controllo Ansible
2. Creata una chiave SSH sull'host di controllo Ansible
3. Propagato la chiave SSH a tutte le macchine che vuoi che Ansible gestisca
4. Accesso SSH limitato su tutte le macchine
5. Installato un server Git SSH
6. Creato il git utente, che viene utilizzato per controllare il codice in entrata e in uscita dal server Git SSH

Dal punto di vista aziendale ora hai:

1. Gestione dell'host semplificata
2. Prodotto un modo verificabile, ripetibile e automatizzato per gestire quegli host
3. Ho iniziato a creare un percorso per il ripristino di emergenza (tramite i playbook Ansible)

Per sviluppare le competenze di cui le aziende hanno bisogno, devi essere in grado di vedere le tendenze di utilizzo delle risorse nel tempo. In definitiva, questo significa impostare una sorta di strumento di monitoraggio. Ci sono molte tra cui scegliere, tra cui Zabbix, Zenoss, Nagios, Prometheus e molti altri. Ho lavorato con tutti questi; la soluzione che scegli è in gran parte una funzione di:

• Bilancio
• Tempo
• Familiarità

Gli strumenti di monitoraggio senza agente come Nagios possono utilizzare qualcosa come SNMP per monitorare gli host ed esporre le metriche. Ci possono essere molti vantaggi in questo approccio (come non dover installare un agente). Tuttavia, ho scoperto che Prometheus, sebbene basato su agenti, è molto facile da configurare e fornisce molte più metriche predefinite, quindi è quello che userò in questo articolo.

Configurazione di Prometeo

Introduzione ai ruoli

Altro su Ansible

• Una guida rapida ad Ansible
• Cheat sheet di Ansible
• Corso online gratuito:Ansible essentials
• Scarica e installa Ansible
• eBook:l'impresa automatizzata
• eBook:Ansible for DevOps
• Ebook Ansible gratuiti
• Ultimi articoli Ansible

Sfortunatamente, non è disponibile un repository di gestione dei pacchetti Linux per Prometheus (al di fuori di Arch User Repository), o almeno nessuno è elencato nella pagina di download di Prometheus. È disponibile un'immagine Docker, che potrebbe essere desiderabile in alcuni casi, ma richiede l'esecuzione di servizi aggiuntivi se Docker non è già presente sul computer di destinazione. Per questo articolo, distribuirò i file binari precompilati su ciascun host. Ci sono davvero solo due file necessari per questo:il binario stesso e un systemd o upstart init.

Per questo motivo, un singolo playbook di installazione di Prometheus può essere abbastanza coinvolto; quindi sarebbe un buon momento per discutere del passaggio a un ruolo Ansible. Per dirla semplicemente, mentre tu puoi hanno un file YAML gigante, i ruoli sono un modo per avere una raccolta di attività più piccole che possono essere incluse in un gioco più ampio . Questo è più facilmente spiegato attraverso esempi. Ad esempio, supponiamo di avere un ID utente che deve essere presente su ogni host, ma alcuni dei server che gestisci richiedono un server web, mentre altri potrebbero avere un server di gioco su di essi. Potresti avere due diversi playbook per gestire questo. Considera il seguente playbook:

Esempio 1:Create_user_with_ssh_key.yaml

- hosts: "{{ hostname }}"

  gather_facts: false

  tasks:

    - name: create and/or change {{ username}}'s password

      user:

        name: "{{ username }}"

        password: << some password hash>

    - name: copy ssh keys

      authorized_key:

        key: "{{ item }}"

        user: "{{ username }}"

        state: present

        exclusive: False

      with_file: 

        - ../files/user1_ssh_key.pub

        - ../files/user2_ssh_key.pub

Ci sono alcune opzioni disponibili quando si considera questo problema.

1. Copia questo codice all'inizio di ogni playbook che verrà utilizzato per creare i diversi server
2. Esegui manualmente questo playbook, prima eseguendo il playbook di configurazione del server
3. Ruota il create_user_with_ssh_key.yaml in un'attività, che può essere quindi inclusa in un ruolo utilizzando la pratica standard di Ansible

L'opzione 1 non è gestibile su larga scala. Supponiamo di dover cambiare la password o il nome utente che stavi creando. Dovresti trovare tutti i playbook che includono questo codice.

L'opzione 2 è un passo nella giusta direzione. Tuttavia, richiede un passaggio manuale aggiuntivo ogni volta che crei un server. In un laboratorio domestico, questo può essere sufficiente. Tuttavia, in un ambiente diversificato con la possibilità che più persone seguano lo stesso processo per creare i server, l'opzione 2 si basa sull'amministratore per documentare e seguire correttamente tutti i passaggi necessari per produrre un server funzionante secondo le specifiche esatte.

Per compensare queste carenze, l'opzione 3 utilizza la soluzione integrata di Ansible. Ha il vantaggio di utilizzare un processo di creazione del server facilmente riproducibile. Inoltre, durante l'audit del processo di compilazione (tu sei utilizzando il controllo del codice sorgente che abbiamo impostato in precedenza, giusto?), l'auditor può potenzialmente aprire un singolo file per determinare quali file di attività sono stati utilizzati automaticamente da Ansible per produrre una build del server. Alla fine, questo sarà il miglior approccio a lungo termine ed è una buona idea imparare a usare i ruoli e prendere l'abitudine di usarli presto e spesso.

Organizzare i tuoi ruoli con una struttura di directory adeguata è fondamentale sia per una facile verificabilità che per il tuo stesso successo. La documentazione di Ansible contiene alcuni suggerimenti riguardanti la struttura e il layout delle directory. Preferisco un layout di directory simile a questo:

└── production

    ├── playbooks

    └── roles

        ├── common

        │   ├── defaults

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   └── vars

        ├── git_server

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   └── vars

        ├── monitoring

        │   ├── files

        │   ├── handlers

        │   ├── tasks

        │   ├── templates

        │   └── vars

Il sistema Ansible per la progettazione dei ruoli all'inizio può creare un po' di confusione, soprattutto perché ci sono più posti in cui è possibile definire le variabili. Nella situazione sopra, in questa situazione sopra, potrei creare un group_vars directory nella production cartella in questo modo:

└── production/

    └── group_vars/

        └── all/

            └── vars.yaml

L'inserimento di variabili in questo file le renderà accessibili a qualsiasi ruolo inserito nella production cartella. Potresti avere vars sotto ogni ruolo (come git_server ) e quindi metterli a disposizione di tutti i compiti per un determinato ruolo:

└── environments/

    └── production/

        └── roles/

        └── git_server/

            └── vars/

                └── main.yaml

Infine, puoi specificare le variabili nella riproduzione stessa. Questi possono essere assegnati localmente all'attività specifica o alla riproduzione stessa (comprendendo così più attività nella stessa riproduzione).

Per ricapitolare, puoi dichiarare variabili:

1. A livello di ruolo per tutte le attività in un determinato ruolo
2. A livello di playbook per tutte le attività di una riproduzione
3. All'interno delle singole attività
4. All'interno del file hosts di Ansible (noto anche come inventario); questo è usato principalmente per le variabili macchina e non è trattato in questa discussione

Decidere quale ambito creare variabili può essere difficile, soprattutto se bilanciato con la facilità di manutenibilità. Potresti mettere tutte le tue variabili a livello globale, il che le rende facili da trovare ma potrebbe non essere l'idea migliore per ambienti di grandi dimensioni. Il contrario è posizionare tutte le variabili all'interno delle singole attività, ma questo può diventare un vero mal di testa se hai molte variabili. Vale la pena considerare i compromessi nella tua situazione specifica.

Tornando al piccolo playbook nell'Esempio 1 sopra, potremmo suddividere i nostri file in questo modo:

├── production

│   ├── playbooks

│   └── roles

│       ├── common

│       │   ├── files

│       │   │   ├── user1_ssh_key.pub

│       │   │   └── user2_ssh_key.pub

│       │   ├── tasks

│       │   │   ├── create_user.yaml

│       │   │   ├── copy_ssh_key.yaml

Il contenuto delle tasks i file sono identici alle righe nel playbook unico e monolitico:

Esempio 2:create_user.yaml

- name: create and/or change {{ username}}'s password

  user:

    name: "{{ username }}"

    password: << password hash >>

Esempio 3:copy_ssh_key.yaml

- name: copy ssh keys

  authorized_key:

    key: "{{ item }}"

    user: "{{ username }}"

    state: present

    exclusive: False

  with_file: 

    - user1_ssh_key.pub

    - user2_ssh_key.pub

Tuttavia, ciò che è cambiato (potenzialmente) è il modo in cui le variabili vengono passate ad Ansible. Puoi ancora usare --extra-vars opzione. Tuttavia, per dimostrare un altro approccio, utilizzeremo vars/main.yaml file. Il vars/main.yaml il file ha il seguente contenuto:

username: 'git'

password: 6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt8.OpCCN0

La password deve essere un hash e non una password in chiaro. Per generare un hash sulla maggior parte delle versioni di Linux, puoi eseguire il seguente comando Python:

python2.7 -c 'import crypt,getpass; print crypt.crypt(getpass.getpass(), "$1$awerwass")'

Nel comando precedente la password salt è indicata in awerwass . Questi sono solo caratteri casuali che ho battuto sulla tastiera. NON USARE LO STESSO SALE NELLA PRODUZIONE.

Per eseguire queste attività insieme, devi creare un main.yaml nelle tasks directory. Dovrebbe avere il seguente contenuto:

---

- include: create_user.yaml

- include: copy_ssh_key.yaml

Infine, crea un playbook con il seguente contenuto:

- hosts: git

  gather_facts: false

  roles:

    43- role: ../roles/common

La struttura della tua directory dovrebbe assomigliare a questa:

├── production

│   ├── playbooks

│   │   ├── common.yaml

│   └── roles

│       ├── common

│       │   ├── files

│       │   │   ├── user1_ssh_key.pub

│       │   │   └── user2_ssh_key.pub

│       │   ├── handlers

│       │   │   └── main.yaml

│       │   ├── tasks

│       │   │   ├── copy_ssh_key.yaml

│       │   │   ├── create_user.yaml

│       │   │   ├── main.yaml

│       │   └── vars

│       │       └── main.yaml

Impostazione di un ruolo per Prometheus

Ora che abbiamo coperto le basi della creazione di un ruolo, concentriamoci sulla creazione di un ruolo Prometheus. Come accennato in precedenza, sono necessari solo due file per l'esecuzione di ciascun agente:un file di servizio (o upstart) e il file binario di Prometheus. Di seguito sono riportati esempi di ciascuno:

Esempio 4:file systemd prometheus-node-exporter.service

[Unit]

Description=Prometheus Exporter for machine metrics.

After=network.target



[Service]

ExecStart=/usr/bin/prometheus_node_exporter



[Install]

WantedBy=multi-user.target

Esempio 5:avvio del file init

# Run prometheus_node_exporter



start on startup



script

/usr/bin/prometheus_node_exporter

end script

Esempio 6:file systemd prometheus.service (il servizio server)

[Service]

User=prometheus

Group=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



[Install]

WantedBy=multi-user.target

Nel mio ambiente, con macchine Ubuntu (con e senza system ) e un gran numero di macchine Red Hat e Arch, avevo bisogno di scrivere un playbook per distribuire gli script di avvio corretti alle rispettive scatole. Esistono diversi modi per determinare se distribuire upstart o systemd file di servizio. Ansible ha un fatto integrato chiamato ansible_service_mgr che può essere utilizzato per individuare il responsabile del servizio appropriato.

Tuttavia, ho deciso di dimostrare come utilizzare gli script per fornire ad Ansible fatti durante il Gather Facts fase. Questo è noto come Ansible Local Facts. Questi fatti vengono letti da /etc/ansible/facts.d/ directory. I file in questa directory possono essere JSON, INI o file eseguibili che restituiscono JSON. Devono anche avere l'estensione del file .fact . Il semplice script Bash che ho scritto controlla il systemd PID e, se trovato, restituisce un JSON con il valore di true , come si vede nell'Esempio 7:

Esempio 7:systemd_check.fact

#!/bin/bash

# Check for systemd if present return { 'systemd': 'true' } 



systemd_pid=`pidof systemd` 

if [ -z "$systemd_pid" ]; then

  echo '{ "systemd": "false" }'

else

  echo '{ "systemd": "true" }'

fi

Con questo in mente, possiamo iniziare a creare una semplice attività per aiutare a distribuire l'agente Prometheus. Per ottenere ciò, i facts locali il file deve essere copiato su ciascun server, gli script binari e di avvio devono essere distribuiti e il servizio deve essere riavviato. Di seguito è riportata un'attività che distribuirà il systemd_check.fact copione.

Esempio 8:copy_local_facts.yaml

- name: Create the facts directory if does not exist

  file:

    path: /etc/ansible/facts.d

    state: directory



- name: Copy the systemd facts file

  copy:

    src: systemd_check.fact

    dest: /etc/ansible/facts.d/systemd_check.fact

    mode: 0755

Ora che i nostri fatti personalizzati sono stati distribuiti, ora possiamo distribuire i file binari necessari. Ma prima, diamo un'occhiata al file variabile che verrà utilizzato per queste attività. In questo esempio, ho scelto di utilizzare vars/ directory che è localizzata nel singolo ruolo. Attualmente si presenta così:

Esempio 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: '/etc/systemd/system/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'

    'ark': '192.168.195.2:9100'

    'kids-tv': '192.168.195.213:9100'

    'media-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'

Per ora, puoi ignorare il client_information_dict; che entrerà in gioco in seguito.

Esempio 10:task/setup_prometheus_node.yaml

---

- name: copy the binary to {{ exporter_binary_dest }}

  copy:

    src: "{{ exporter_binary }}"

    dest: "{{ exporter_binary_dest }}"

    mode: 0755



- name: put systemd service file in place

  copy:

    src: "{{ exporter_service }}"

    dest: "{{ exporter_service_dest }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'



- name: copy the upstart conf to {{ exporter_upstart_dest }}

  copy:

    src: "{{ exporter_upstart }}"

    dest: "{{ exporter_upstart_dest }}"

  when:

    - ansible_local.systemd_check.systemd == 'false'



- name: update systemd and restart exporter systemd

  systemd:

    daemon-reload: true

    enabled: true

    state: restarted

    name: "{{ exporter_service }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

   

- name: start exporter sysv service

  service:

    name: "{{ exporter_service }}"

    enabled: true

    state: restarted

  when:  

    - ansible_local.systemd_check.systemd == 'false'

La cosa più importante da notare nell'attività sopra è che fa riferimento a ansible_local.systemd_check.systemd . Questo si suddivide nella seguente convenzione di denominazione <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . Lo script Bash systemd_check.fact viene eseguito durante Gather Facts stage e quindi archiviato in ansible_local sezione di tutti i Gather Facts . Per prendere una decisione basata su questo fatto, controllo se è true o false . La clausola Ansible When dice ad Ansible di eseguire quell'attività specifica solo se vengono soddisfatte determinate condizioni. Il resto di questo compito dovrebbe essere abbastanza semplice. Utilizza sia il systemd che i moduli di servizio per garantire che il gestore di servizi appropriato sia configurato per avviare il prometheus_node_exporter .

Il compito per configurare il server è molto simile:

Esempio 11:task/setup_Prometheus_server.yaml

---

- name: copy the server binary to {{ server_binary_dest }}

  copy:

    src: "{{ server_binary }}"

    dest: "{{ server_binary_dest }}"

    mode: 0755

  when:

    - inventory_hostname = 'prometheus'



- name: Ensure that /etc/prometheus exists

  file:

    state: directory

    path: /etc/prometheus

    owner: "{{ prometheus_user }}"

    group: "{{ prometheus_user }}"

    mode: 0755

  when:

    - inventory_hostname = 'prometheus'



- name: place prometheus config

  template:

    src: prometheus.yaml.j2

    dest: /etc/prometheus/prometheus.yaml

  when:

    - inventory_hostname = 'prometheus'



- name: create /var/lib/promtheus/data

  file:

    state: directory

    path: /var/lib/prometheus/data

    recurse: true

    owner: "{{ prometheus_user }}"

    group: "{{ prometheus_user }}"

    mode: 0755

  when:

    - inventory_hostname = 'prometheus'



- name: put systemd service file in place

  copy:

    src: "{{ server_service }}"

    dest: "{{ server_service_dest }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

    - inventory_hostname = 'prometheus'



- name: update systemd and restart prometheus server systemd

  systemd:

    daemon-reload: true

    enabled: true

    state: restarted

    name: "{{ server_service }}"

  when: 

    - ansible_local.systemd_check.systemd == 'true'

    - inventory_hostname = 'prometheus'



  notify: restart_prometheus_server

L'osservatore attento noterà un paio di cose nuove nell'attività del server.

1. Il notify: sezione
2. Il template: modulo

La notify la sezione è un modo per attivare tipi specifici di eventi quando vengono soddisfatti determinati criteri. Gli Ansible Handler vengono utilizzati più frequentemente per attivare i riavvii del servizio (che è esattamente ciò che sta accadendo sopra). I gestori sono archiviati in un handlers directory all'interno del ruolo. Il mio gestore è molto semplice:

Esempio 12:handler/main.yaml

- name: restart_iptables

  service:

    name: iptables

    state: restarted

    enabled: true



- name: restart_prometheus_server

  service:

    name: "{{ server_service }}"

    state: restarted

    enabled: true

Questo mi permette semplicemente di riavviare il prometheus.service sul server Prometheus.

Il secondo punto di interesse nel setup_prometheus_server.yaml è il template: sezione. La creazione di modelli in Ansible offre alcuni vantaggi molto interessanti. Ansible utilizza Jinja2 per il suo motore di creazione di modelli; tuttavia, una spiegazione completa di Jinja esula dallo scopo di questo tutorial. In sostanza, puoi utilizzare un modello Jinja2 per avere un file di configurazione con variabili i cui valori vengono calcolati e sostituiti durante una riproduzione di Ansible. Il modello di configurazione di Prometheus si presenta così:

Esempio 13:templates/prometheus.yaml.j2

global:

  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.

  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.



  external_labels:

      monitor: 'codelab-monitor'



scrape_configs:

  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.

  - job_name: 'prometheus'



    static_configs:

      - targets: ['localhost:9090']

  - job_name: 'nodes'

    static_configs:

{% for hostname, ip in client_information_dict.iteritems() %}

      - targets: ['{{ ip }}']

        labels: {'host': '{{ hostname }}' }

{% endfor %}

Quando la sezione del modello viene elaborata, il .j2 l'estensione viene rimossa automaticamente prima di posizionare il file sul sistema remoto. Il piccolo ciclo for nel modello scorre su client_information_dict , che ho definito in precedenza nel mio file di variabili. Crea semplicemente un elenco di macchine virtuali su cui voglio che Prometheus raccolga le metriche.

Nota:se vuoi che Prometheus visualizzi i nomi host e il tuo DNS sia impostato correttamente, usa invece questo:

{% for hostname, ip in client_information_dict.iteritems() %}

      - targets: ['{{ hostname }}:9100']

        labels: {'host': '{{ hostname }}' }

{% endfor %}

Mancano solo pochi ritocchi finali per completare la configurazione di Prometheus. Dobbiamo creare il prometheus utente, (potenzialmente) aggiusta iptables, collega tutto insieme nel main.yaml e crea un playbook da eseguire.

La configurazione del Prometheus user è abbastanza semplice e ti risulterà molto familiare se hai seguito i miei precedenti articoli su Ansible:

Esempio 14:task/create_prometheus_user.yaml

---

- name: Ensure that the prometheus user exists

  user:

    name: "{{ prometheus_user }}"

    shell: /bin/false

L'unica grande differenza qui è che sto impostando la shell su /bin/false in modo che l'utente possa eseguire i servizi ma non accedere.

Se stai eseguendo iptables, dovrai assicurarti di aprire la porta 9100 in modo che Prometheus possa raccogliere le metriche dai suoi client. Ecco un semplice compito per farlo:

Esempio 15:task/iptables.yaml

---

- name: Open port 9100

  lineinfile:

    dest: /etc/sysconfig/iptables

    insertbefore: "-A INPUT -j OS_FIREWALL_ALLOW"

    line: "-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"

  notify: restart_iptables

  when: 

    - ansible_os_family == "RedHat" 

Nota:sto eseguendo iptables solo sulla mia famiglia di macchine virtuali Red Hat. Se esegui iptables su tutte le tue VM, rimuovi when: sezione.

Il main.yaml assomiglia a questo:

Esempio 16:task/main.yaml

--- 

- include: create_prometheus_user.yaml

- include: setup_prometheus_node.yaml

- include: setup_prometheus_server.yaml

- include: prometheus_iptables.yaml

L'ultimo pezzo consiste nel creare un playbook che comprenda i ruoli necessari per completare il tuo compito:

Esempio 17:playbooks/monitoring.yaml

- hosts: all

  roles:

    - role: ../roles/common

    - role: ../roles/monitoring

Legare tutto insieme

So che sembra molto testo da leggere, ma i concetti per l'utilizzo di Ansible sono abbastanza semplici. Di solito è solo questione di sapere come portare a termine l'attività che ti sei prefissato di svolgere e quindi trovare i moduli Ansible appropriati per aiutarli a realizzarli. Se hai seguito questa procedura dettagliata, dovresti avere un layout simile a questo:

├── playbooks

│   ├── git_server.yaml

│   ├── monitoring.yaml

└── roles

    ├── common

    │   ├── files

    │   │   ├── systemd_check.fact

    │   │   ├── user1_ssh_key.pub

    │   │   └── user2_ssh_key.pub

    │   ├── handlers

    │   │   └── main.yaml

    │   ├── tasks

    │   │   ├── copy_systemd_facts.yaml

    │   │   ├── main.yaml

    │   │   ├── push_ssh_key.yaml

    │   │   ├── root_ssh_key_only.yaml

    │   └── vars

    │   └── main.yaml

    ├── monitoring

    │   ├── files

    │   │   ├── prometheus

    │   │   ├── prometheus_node_exporter

    │   │   ├── prometheus-node-exporter.conf

    │   │   ├── prometheus-node-exporter.service

    │   │   ├── prometheus.service

    │   │   └── systemd_check.fact

    │   ├── handlers

    │   │   └── main.yaml

    │   ├── tasks

    │   │   ├── create_prometheus_user.yaml

    │   │   ├── main.yaml

    │   │   ├── prometheus_iptables.yaml

    │   │   ├── setup_prometheus_node.yaml

    │   │   └── setup_prometheus_server.yaml

    │   ├── templates

    │   │   └── prometheus.yaml.j2

        └── vars

            └── main.yaml

Per eseguire il tuo playbook, inserisci:

[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 

Ora dovresti essere in grado di creare utenti, premere ssh-keys, verificare l'esistenza di systemd e distribuisci il prometheus_node_exporter o il binario del server Prometheus ai server appropriati. Prometheus dovrebbe essere inizializzato con una configurazione di base che includa l'elenco degli host specificati in vars/main. yaml file nel ruolo di monitoraggio.

Congratulazioni! Ora hai automatizzato l'installazione e la configurazione di un server Prometheus di base e hai configurato i tuoi host per iniziare a trasmettere i dati. Come piacevole effetto collaterale, hai anche documentato in modo efficace tutti i passaggi necessari per raggiungere i tuoi obiettivi.

Addendum:Quando ho concepito questa serie, stavo lavorando all'installazione di Prometheus in OpenShift; tuttavia, esaminando la documentazione per il programma di installazione di Ansible per OpenShift, ho scoperto che è già contenuto in un playbook ed è un'opzione nel programma di installazione.