So verwenden Sie Ansible zum Einrichten der Systemüberwachung mit Prometheus

Im Sommer 2017 habe ich zwei How-to-Artikel über die Verwendung von Ansible geschrieben. Nach dem ersten Artikel wollte ich Beispiele für die copy zeigen , systemd , service , apt , yum , virt , und user Module. Aber ich habe mich entschieden, den Umfang des zweiten Teils zu verengen, um mich auf die Verwendung von yum zu konzentrieren und user Module. Ich habe erklärt, wie man einen einfachen Git-SSH-Server einrichtet, und den command untersucht , file , authorized_keys , yum , und user Module. In diesem dritten Artikel gehe ich auf die Verwendung von Ansible für die Systemüberwachung mit der Open-Source-Überwachungslösung Prometheus ein.

Wenn Sie diesen ersten beiden Artikeln gefolgt sind, sollten Sie Folgendes haben:

1. Einen Ansible-Steuerungshost installiert
2. Einen SSH-Schlüssel auf dem Ansible-Steuerungshost erstellt
3. Verbreiten Sie den SSH-Schlüssel an alle Computer, die Ansible verwalten soll
4. Eingeschränkter SSH-Zugriff auf allen Rechnern
5. Einen Git-SSH-Server installiert
6. Erstellte den git Benutzer, der zum Ein- und Auschecken von Code auf dem Git-SSH-Server verwendet wird

Aus geschäftlicher Sicht haben Sie jetzt:

1. Vereinfachte Hostverwaltung
2. Erstellte eine überprüfbare, wiederholbare, automatisierte Methode zur Verwaltung dieser Hosts
3. Beginn, einen Pfad für die Notfallwiederherstellung zu erstellen (über Ansible Playbooks)

Um die Fähigkeiten aufzubauen, die Unternehmen benötigen, müssen Sie in der Lage sein, Trends bei der Ressourcennutzung im Laufe der Zeit zu erkennen. Letztendlich bedeutet dies, eine Art Überwachungstool einzurichten. Es gibt eine große Auswahl, darunter Zabbix, Zenoss, Nagios, Prometheus und viele andere. Ich habe mit all diesen gearbeitet; Welche Lösung Sie wählen, hängt weitgehend von Folgendem ab:

• Budget
• Zeit
• Vertrautheit

Agentenlose Überwachungstools wie Nagios können etwas wie SNMP verwenden, um Hosts zu überwachen und Metriken offenzulegen. Dieser Ansatz kann viele Vorteile haben (z. B. dass kein Agent installiert werden muss). Ich habe jedoch festgestellt, dass Prometheus, obwohl es agentenbasiert ist, sehr einfach einzurichten ist und weitaus mehr Metriken sofort bereitstellt, also werde ich das in diesem Artikel verwenden.

Einrichten von Prometheus

Einführung in Rollen

Mehr zu Ansible

• Eine Schnellstartanleitung für Ansible
• Ansible-Spickzettel
• Kostenloser Online-Kurs:Grundlagen von Ansible
• Ansible herunterladen und installieren
• eBook:Das automatisierte Unternehmen
• eBook:Ansible für DevOps
• Kostenlose Ansible-eBooks
• Neueste Ansible-Artikel

Leider ist für Prometheus (außerhalb des Arch User Repository) kein Linux-Paketmanager-Repository verfügbar, oder zumindest sind keine auf der Prometheus-Downloadseite aufgeführt. Es ist ein Docker-Image verfügbar, das in einigen Fällen wünschenswert sein kann, aber es erfordert die Ausführung zusätzlicher Dienste, wenn Docker nicht bereits auf dem Zielcomputer vorhanden ist. Für diesen Artikel werde ich die vorkompilierten Binärdateien auf jedem Host bereitstellen. Dafür werden eigentlich nur zwei Dateien benötigt:das Binary selbst und ein systemd oder upstart init-Datei.

Aus diesem Grund kann ein einzelnes Prometheus-Installations-Playbook ziemlich kompliziert sein; Daher wäre es ein guter Zeitpunkt, den Übergang zu einer Ansible-Rolle zu diskutieren. Um es einfach auszudrücken, solange Sie können eine riesige YAML-Datei haben, sind Rollen eine Möglichkeit, eine Sammlung kleinerer Aufgaben zu haben, die in ein größeres Spiel aufgenommen werden können . Anhand von Beispielen lässt sich dies leichter erklären. Angenommen, Sie haben eine Benutzer-ID, die auf jedem Host vorhanden sein muss, einige der von Ihnen verwalteten Server benötigen jedoch einen Webserver, während auf anderen möglicherweise ein Spieleserver installiert ist. Möglicherweise haben Sie zwei verschiedene Playbooks, um dies zu handhaben. Betrachten Sie das folgende Playbook:

Beispiel 1:Create_user_with_ssh_key.yaml

- hosts:"{{ hostname }}"
  collect_facts:false
  task:
    - name:Passwort von {{ username}} erstellen und/oder ändern
 Benutzer:
        Name:"{{ Benutzername }}"
        Passwort:<
    - Name:SSH-Schlüssel kopieren
      Autorisierter_Schlüssel:
        Schlüssel:" {{ item }}"
        user:"{{ username }}"
        state:present
        exclusive:False
      with_file:
        - ../files/user1_ssh_key .pub
        - ../files/user2_ssh_key.pub

Zur Betrachtung dieses Problems stehen einige Optionen zur Verfügung.

1. Kopieren Sie diesen Code am Anfang jedes Playbooks, das zum Erstellen der verschiedenen Server verwendet wird
2. Führen Sie dieses Playbook vorher manuell aus Ausführen des Serverkonfigurations-Playbooks
3. Drehen Sie die create_user_with_ssh_key.yaml in eine Aufgabe, die dann unter Verwendung von Ansible-Standardverfahren in eine Rolle aufgenommen werden kann

Option 1 ist im Maßstab nicht handhabbar. Angenommen, Sie müssten das Passwort oder den Benutzernamen ändern, den Sie erstellt haben. Sie müssten alle Playbooks finden, die diesen Code enthalten.

Option 2 ist ein Schritt in die richtige Richtung. Es erfordert jedoch jedes Mal, wenn Sie einen Server erstellen, einen zusätzlichen manuellen Schritt. In einem Heimlabor kann dies ausreichend sein. In einer heterogenen Umgebung mit der Möglichkeit, dass mehrere Personen denselben Prozess zum Erstellen von Servern befolgen, hängt Option 2 jedoch davon ab, dass der Administrator alle Schritte dokumentiert und korrekt befolgt, die erforderlich sind, um einen funktionierenden Server mit genauen Spezifikationen zu erstellen.

Um diese Mängel auszugleichen, verwendet Option 3 die integrierte Lösung von Ansible. Es hat den Vorteil, dass es einen leicht reproduzierbaren Server-Build-Prozess verwendet. Auch beim Auditieren des Build-Prozesses (Sie sind Verwenden Sie die Quellcodeverwaltung, die wir zuvor eingerichtet haben, richtig?), kann der Prüfer möglicherweise eine einzelne Datei öffnen, um festzustellen, welche Aufgabendateien automatisch von Ansible verwendet wurden, um einen Server-Build zu erstellen. Letztendlich ist dies der beste langfristige Ansatz, und es ist eine gute Idee, den Umgang mit Rollen zu lernen und sich daran zu gewöhnen, sie früh und häufig zu verwenden.

Die Organisation Ihrer Rollen mit der richtigen Verzeichnisstruktur ist sowohl für die einfache Überprüfbarkeit als auch für Ihren eigenen Erfolg von entscheidender Bedeutung. Die Ansible-Dokumentation enthält einige Vorschläge zur Verzeichnisstruktur und zum Layout. Ich bevorzuge ein ähnliches Verzeichnislayout:

└── Produktion
    ├── Playbooks
    └── Rollen
        ├── gemeinsam
        │   ├── Standardeinstellungen
        │   ├─ Dateien
        ├── Dateien
       BR /> │ ├── Handler 
 │ ├── Tasks 
 │ └── Vars 
 ├── git_server 
 │ ├── Dateien 
 │ │─ ─ Handler 
 │ ├─── Tasks 
 │ └── ─ Vars 
 ├── Überwachung 
 │ ├── Files 
 │ ├── Handler 
 │   ├── Aufgaben
        │   ├── Vorlagen
        │   └── vars

Das Ansible-System zum Entwerfen von Rollen kann zunächst etwas verwirrend sein, zumal es mehrere Stellen gibt, an denen Variablen definiert werden können. In der obigen Situation könnte ich in dieser obigen Situation eine group_vars erstellen Verzeichnis im production Ordner wie folgt:

└── production/
    └── group_vars/
        └── all/
            └── vars.yaml

Das Platzieren von Variablen in dieser Datei macht sie für jede Rolle zugänglich, die in die production eingefügt wird Mappe. Sie könnten vars haben unter jeder Rolle (wie git_server ) und damit für alle Tasks einer bestimmten Rolle zur Verfügung stehen:

└── Umgebungen/
    └── Produktion/
        └── Rollen/
        └── git_server/
            └── vars/
                 ─ main.yaml

Schließlich können Sie im Spiel selbst Variablen angeben. Diese können lokal auf die spezifische Aufgabe oder auf das Spiel selbst begrenzt werden (wodurch mehrere Aufgaben im selben Spiel überspannt werden).

Zur Erinnerung:Sie können Variablen deklarieren:

1. Auf Rollenebene für alle Aufgaben in einer bestimmten Rolle
2. Auf Spielbuchebene für alle Aufgaben in einem Spiel
3. Innerhalb einzelner Aufgaben
4. In der Ansible-Hosts-Datei (auch bekannt als Inventory); dies wird hauptsächlich für Maschinenvariablen verwendet und in dieser Diskussion nicht behandelt

Die Entscheidung, in welchem ​​Bereich Variablen erstellt werden sollen, kann schwierig sein, insbesondere wenn sie gegen die einfache Wartbarkeit abgewogen wird. Sie könnten alle Ihre Variablen auf globaler Ebene platzieren, was sie leicht zu finden macht, aber möglicherweise nicht die beste Idee für große Umgebungen ist. Das Gegenteil davon ist, alle Variablen in einzelne Aufgaben zu platzieren, aber das kann zu echten Kopfschmerzen werden, wenn Sie viele Variablen haben. Es lohnt sich, die Kompromisse in Ihrer spezifischen Situation zu berücksichtigen.

Um auf das kleine Playbook in Beispiel 1 oben zurückzukommen, könnten wir unsere Dateien wie folgt aufteilen:

├── Produktion
│   ├── Playbooks
│   └── Rollen
│       ├── gemeinsam
│       │   ├── Dateien
│       │ │ ├── ─ user1_ssh_key.pub 
 │ │ │ │─ ─ user user user user └ └ ─ ─ user │ │ ├── Tasks 
 │ │ │ │─── │ │ │ │ ├── │ create_user.yaml 
 │ │ │ ├── copy_ssh_key.yaml

Der Inhalt der tasks Dateien sind identisch mit den Zeilen im einzelnen, monolithischen Playbook:

Beispiel 2:create_user.yaml

- Name:Passwort von {{ Nutzername}} erstellen und/oder ändern
  Nutzer:
    Name:"{{ Nutzername }}"
    Passwort:<> 

Beispiel 3:copy_ssh_key.yaml

- name:SSH-Schlüssel kopieren
  authorisierter_schlüssel:
    key:"{{ item }}"
    user:"{{ username }}"
    state:present
    exclusive:False
  with_file:
    - user1_ssh_key.pub
    - user2_ssh_key.pub

Was sich jedoch (möglicherweise) geändert hat, ist die Art und Weise, wie Variablen an Ansible übergeben werden. Sie können immer noch die --extra-vars verwenden Möglichkeit. Um jedoch einen anderen Ansatz zu demonstrieren, verwenden wir die vars/main.yaml Datei. Die vars/main.yaml Datei hat folgenden Inhalt:

Benutzername:'git'
Passwort:6$cmYTU26zdqOArk5I$WChA039bHQ8IXAo0W8GJxhk8bd9wvcY.DTUwN562raYjFhCkJSzSBm6u8RIgkaU8b3.Z3EmyxyvEZt8.OpCCN0

Das Passwort sollte ein Hash und kein Klartext-Passwort sein. Um unter den meisten Linux-Versionen einen Hash zu generieren, können Sie den folgenden Python-Befehl ausführen:

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

Im obigen Befehl wird das Passwort Salt in awerwass angegeben . Dies sind nur zufällige Zeichen, die ich auf die Tastatur gehämmert habe. VERWENDEN SIE NICHT DAS GLEICHE SALZ IN DER PRODUKTION.

Damit diese Aufgaben zusammen ausgeführt werden, müssen Sie eine main.yaml erstellen in den tasks Verzeichnis. Es sollte folgenden Inhalt haben:

---
- include:create_user.yaml
- include:copy_ssh_key.yaml

Erstellen Sie abschließend ein Playbook mit folgendem Inhalt:

- hosts:git
  collect_facts:false
  roles:
    43- role:../roles/common

Ihre Verzeichnisstruktur sollte wie folgt aussehen:

├── Produktion
│   ├── Playbooks
│   │   ├── common.yaml
│   └── Rollen
│       ├── common
 │ │ ├── Files 
 │ │ │ │ ├── us us ® │ │ │ ├ │ │ │ │─ ─ │ │ └ └─ user user2_ssh_key.pub 
 │ │ ├── Handler 
 │ │ │ │ └ ─ ─ main.yaml 
 │ │ │── Tasks 
 │ │ │ │ ├── copy_ssh_key.yaml 
 │ │ │ │── ├ create_user.yaml 
 │ │ │ │ ├─ ─ main.yaml
│       │   └── vars
│       │       └── main.yaml

Einrichten einer Rolle für Prometheus

Nachdem wir nun die Grundlagen zum Erstellen einer Rolle behandelt haben, konzentrieren wir uns auf das Erstellen einer Prometheus-Rolle. Wie bereits erwähnt, sind nur zwei Dateien erforderlich, damit jeder Agent ausgeführt werden kann:eine Service- (oder Upstart-) Datei und die Prometheus-Binärdatei. Nachfolgend finden Sie jeweils Beispiele:

Beispiel 4:systemd prometheus-node-exporter.service-Datei

[Unit]
Description=Prometheus Exporter für Maschinenmetriken.
After=network.target

[Service]
ExecStart=/usr/bin/prometheus_node_exporter 

[Installieren]
WantedBy=multi-user.target

Beispiel 5:Upstart-Init-Datei

# prometheus_node_exporter ausführen

beim Start starten

Skript
/usr/bin/prometheus_node_exporter
Skript beenden

Beispiel 6:systemd-Datei prometheus.service (der Serverdienst)

[Dienst]
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
 
[Installieren]
WantedBy=multi-user.target

In meiner Umgebung mit Ubuntu-Rechnern (mit und ohne system ) und einer großen Anzahl von Red Hat- und Arch-Rechnern musste ich ein Playbook schreiben, um die richtigen Startskripte an die jeweiligen Boxen zu verteilen. Es gibt mehrere Möglichkeiten, um zu bestimmen, ob der upstart bereitgestellt werden soll oder systemd Dienstdateien. Ansible hat einen eingebauten Fakt namens ansible_service_mgr die verwendet werden können, um den zuständigen Service Manager zu finden.

Ich habe mich jedoch entschieden, während des Gather Facts zu demonstrieren, wie Skripte verwendet werden, um Ansible mit Fakten zu versorgen Bühne. Dies wird als Ansible Local Facts bezeichnet. Diese Fakten werden aus /etc/ansible/facts.d/ gelesen Verzeichnis. Dateien in diesem Verzeichnis können JSON-, INI- oder ausführbare Dateien sein, die JSON zurückgeben. Außerdem müssen sie die Dateiendung .fact haben . Das einfache Bash-Skript, das ich geschrieben habe, prüft auf systemd PID und gibt, falls gefunden, ein JSON mit dem Wert true zurück , wie in Beispiel 7 zu sehen:

Beispiel 7:systemd_check.fact

#!/bin/bash
# Auf systemd prüfen, falls vorhanden return { 'systemd':'true' } 

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

Vor diesem Hintergrund können wir damit beginnen, eine einfache Aufgabe zu erstellen, um die Bereitstellung des Prometheus-Agenten zu unterstützen. Dazu die lokalen facts Die Datei muss auf jeden Server kopiert, die Binär- und Startskripts bereitgestellt und der Dienst neu gestartet werden. Unten ist eine Aufgabe, die systemd_check.fact bereitstellt Skript.

Beispiel 8:copy_local_facts.yaml

- Name:Faktverzeichnis erstellen, falls nicht vorhanden
  Datei:
    Pfad:/etc/ansible/facts.d
    Status:Verzeichnis

- name:Kopieren Sie die systemd facts-Datei
  copy:
    src:systemd_check.fact
    dest:/etc/ansible/facts.d/systemd_check.fact
    mode:0755

Nachdem unsere benutzerdefinierten Fakten bereitgestellt wurden, können wir nun die benötigten Binärdateien bereitstellen. Aber zuerst werfen wir einen Blick auf die Variablendatei, die für diese Aufgaben verwendet wird. In diesem Beispiel habe ich mich für die Verwendung von vars/ entschieden Verzeichnis, das für die einzelne Rolle lokalisiert ist. Derzeit sieht es so aus:

Beispiel 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'
    'medi a-center':'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'

Im Moment können Sie das client_information_dict ignorieren; das wird später ins Spiel kommen.

Beispiel 10:task/setup_prometheus_node.yaml

---
- name:kopieren Sie die Binärdatei nach {{ exporter_binary_dest }}
  copy:
    src:"{{ exporter_binary }}"
    dest:"{{ exporter_binary_dest }}"
    mode:0755

- name: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:systemd aktualisieren und exporter systemd neu starten
  systemd:
    daemon-reload:true
    enabled:true
    state:neu gestartet
    name:"{{ exporter_service }}"
  when:
    - ansible_local.systemd_check.systemd =='true'
   
- name:start exporter sysv service 
  Dienst:
    Name:"{{ exp orter_service }}"
    aktiviert:wahr
    Zustand:neu gestartet
  wenn: 
    - ansible_local.systemd_check.systemd =='false'

Das Wichtigste, was bei der obigen Aufgabe zu beachten ist, ist, dass sie auf ansible_local.systemd_check.systemd verweist . Dies gliedert sich in die folgende Namenskonvention <how Ansible generates the fact> . <the name of the fact file> . <the key inside the fact to retrieve> . Das Bash-Skript systemd_check.fact wird während der Gather Facts ausgeführt Stufe und dann in ansible_local gespeichert Abschnitt aller Gather Facts . Um eine Entscheidung basierend auf dieser Tatsache zu treffen, überprüfe ich, ob sie true ist oder false . Die Ansible When-Klausel weist Ansible an, diese bestimmte Aufgabe nur dann auszuführen, wenn bestimmte Bedingungen erfüllt sind. Der Rest dieser Aufgabe sollte ziemlich einfach sein. Es verwendet sowohl das Systemd- als auch das Dienstmodul, um sicherzustellen, dass der entsprechende Dienstmanager so konfiguriert ist, dass er den prometheus_node_exporter startet .

Die Aufgabe zum Einrichten des Servers ist sehr ähnlich:

Beispiel 11:task/setup_Prometheus_server.yaml

---
- name:Kopieren Sie die Server-Binärdatei nach {{ server_binary_dest }}
  copy:
    src:"{{ server_binary }}"
    dest:"{ { server_binary_dest }}"
    Modus:0755
  wann:
    - Inventory_Hostname ='prometheus'

- Name:Stellen Sie sicher, dass /etc/prometheus existiert
 Datei:
    Status:Verzeichnis
    Pfad:/etc/prometheus
    Eigentümer:"{{ prometheus_user }}"
    Gruppe:"{{ prometheus_user }}"
    Modus :0755
  when:
    - Inventory_hostname ='prometheus'

- name:place prometheus config
  template:
    src:prometheus.yaml.j2
    Ziel:/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 }}"
 Gruppe:"{{ prometheus_user }}"
    Modus:0755
  wann:
    - in ventory_hostname ='prometheus'

- name:systemd service file in place
  copy:
    src:"{{ server_service }}"
    dest:"{{ server_service_dest }}"
  when:
    - ansible_local.systemd_check.systemd =='true'
    - Inventory_hostname ='prometheus'

- name:systemd aktualisieren und neu starten Prometheus-Server systemd
  systemd:
    daemon-reload:true
    enabled:true
    state:restarted
    name:"{{ server_service }}"
  when :
    - ansible_local.systemd_check.systemd =='true'
    - Inventory_hostname ='prometheus'

  Benachrichtigung:restart_prometheus_server

Dem aufmerksamen Beobachter werden einige neue Dinge in der Servertask auffallen.

1. Der notify: Abschnitt
2. Die template: Modul

Die notify Abschnitt ist eine Möglichkeit, bestimmte Arten von Ereignissen auszulösen, wenn bestimmte Kriterien erfüllt sind. Ansible Handler werden am häufigsten verwendet, um Dienstneustarts auszulösen (genau das passiert oben). Handler werden in einem handlers gespeichert Verzeichnis innerhalb der Rolle. Mein Handler ist sehr einfach:

Beispiel 12:handler/main.yaml

- Name:restart_iptables
  Dienst:
    Name:iptables
    Status:neu gestartet
    aktiviert:wahr

- Name:restart_prometheus_server
 Dienst:
    Name:"{{ server_service }}"
    Status:neu gestartet
    aktiviert:wahr

Dadurch kann ich einfach den prometheus.service neu starten auf dem Prometheus-Server.

Der zweite interessante Punkt in der setup_prometheus_server.yaml ist die template: Sektion. Templating in Ansible bietet einige sehr schöne Vorteile. Ansible verwendet Jinja2 für seine Templating-Engine; Eine vollständige Erklärung von Jinja würde jedoch den Rahmen dieses Tutorials sprengen. Im Wesentlichen können Sie eine Jinja2-Vorlage verwenden, um eine Konfigurationsdatei mit Variablen zu haben, deren Werte während einer Ansible-Wiedergabe berechnet und ersetzt werden. Die Prometheus-Konfigurationsvorlage sieht folgendermaßen aus:

Beispiel 13:templates/prometheus.yaml.j2

global:
  scrape_interval:    15s # Stellen Sie das Scrape-Intervall auf alle 15 Sekunden ein. Standard ist alle 1 Minute.
  evaluation_interval:15s # Regeln alle 15 Sekunden auswerten. Der Standardwert ist alle 1 Minute.

  external_labels:
      monitor:'codelab-monitor'

scrape_configs:
  # Der Jobname wird als hinzugefügt Kennzeichnen Sie `job=` für alle Zeitreihen, die von dieser Konfiguration gekratzt wurden.
  - job_name:'prometheus'

    static_configs:
      - Ziele:['localhost:9090'] 
  - job_name:'nodes'
    static_configs:
{% für Hostname, IP in client_information_dict.iteritems() %}
      - Ziele:['{{ ip }}'] 
        label:{'host':'{{ hostname }}' }
{% endfor %}

Wenn der Vorlagenabschnitt verarbeitet wird, wird der .j2 wird automatisch entfernt, bevor die Datei auf dem Remote-System abgelegt wird. Die kleine for-Schleife im Template iteriert über das client_information_dict , die ich zuvor in meiner Variablendatei definiert habe. Es erstellt einfach eine Liste virtueller Maschinen, für die Prometheus Metriken sammeln soll.

Hinweis:Wenn Sie möchten, dass Prometheus Hostnamen anzeigt und Ihr DNS korrekt eingerichtet ist, verwenden Sie stattdessen Folgendes:

{% für Hostname, IP in client_information_dict.iteritems() %}
      - Ziele:['{{ Hostname }}:9100']
        Labels:{'Host':'{{ Hostname }}' }
{% endfor %}

Es fehlen nur noch ein paar letzte Handgriffe, um das Prometheus-Setup abzuschließen. Wir müssen den prometheus erstellen Benutzer, (möglicherweise) iptables anpassen, alles in der main.yaml zusammenbinden , und erstellen Sie ein auszuführendes Playbook.

Die Einrichtung des Prometheus user ist ziemlich unkompliziert und wird Ihnen sehr vertraut vorkommen, wenn Sie meinen vorherigen Ansible-Artikeln gefolgt sind:

Beispiel 14:Tasks/create_prometheus_user.yaml

---
- name:Stellen Sie sicher, dass der prometheus-Benutzer existiert
  user:
    name:"{{ prometheus_user }}"
    shell:/bin/false 

 Der einzige große Unterschied hier ist, dass ich die Shell auf /bin/false setze damit der Nutzer Dienste ausführen, sich aber nicht anmelden kann.
 

 Wenn Sie iptables ausführen, müssen Sie sicherstellen, dass Port 9100 geöffnet ist, damit Prometheus Metriken von seinen Clients sammeln kann. Hier ist eine einfache Aufgabe, um das zu tun:
 
Beispiel 15:Tasks/iptables.yaml
 
---
- name:Open port 9100
  lineinfile:
    destination:/etc/sysconfig/iptables
    insertbefore:"-A INPUT -j OS_FIREWALL_ALLOW"
    Zeile:"-A INPUT -p tcp -m state --dport 9100 --state NEW -j ACCEPT"
 benachrichtigen:restart_iptables
  when:
    - ansible_os_family =="RedHat" 
 

 Hinweis:Ich führe iptables nur auf meinen VMs der Red Hat-Familie aus. Wenn Sie iptables auf allen Ihren VMs ausführen, entfernen Sie when: Abschnitt.
 

 Die main.yaml sieht so aus:
 
Beispiel 16:task/main.yaml
 
--- 
- Einschließen:create_prometheus_user.yaml
- Einschließen:setup_prometheus_node.yaml
- Einschließen:setup_prometheus_server.yaml
- Einschließen:prometheus_iptables.yaml
 

 Der letzte Teil besteht darin, ein Playbook zu erstellen, das die Rollen umfasst, die Sie zum Abschließen Ihrer Aufgabe benötigen:
 
Beispiel 17:Playbooks/monitoring.yaml
 
- hosts:all
  roles:
    - role:../roles/common
    - role:../roles/monitoring
 
Alles zusammenbinden
 

 Ich weiß, dass es wie eine Menge Text aussieht, aber die Konzepte für die Verwendung von Ansible sind ziemlich einfach. In der Regel geht es nur darum, zu wissen, wie Sie die Aufgabe erledigen können, die Sie sich vorgenommen haben, und dann die geeigneten Ansible-Module zu finden, um sie zu erfüllen. Wenn Sie diese exemplarische Vorgehensweise bis zum Ende befolgt haben, sollten Sie ein ähnliches Layout wie dieses haben:
 
├── Playbooks
│   ├── git_server.yaml
│   ├── monitoring.yaml
└── Rollen
    ├── häufig
    │ ├── Files 
 │ │ │─── systemd_check.fact 
 │ │ ├─ ─ user user user user │ │─ user /> │ │ └─ ─ user2_ssh_key.pub 
 │ ├── Handler 
    │   │   └── main.yaml
    │   ├── Aufgaben
    │   │   ├── copy_systemd_facts.yaml
    │   │   ├>── main.yaml
    │   │   ├>── main.yaml
    │   │   ├>── main.yaml
    │   │   ├>── ├── push_ssh_key.yaml
    │   │   ├── root_ssh_key_only.yaml
    │   └── vars
    │   └── main.yaml
   > ├ Überwachung─.
   > │ ├── Files 
 │ │ ├─ ─ Prometheus 
 │ │ │ ├─ ─ ├ ├ ├ ├ ├ ├ ├ ├ │ │ │─ ─ │ │─ ─ │─ ─ │─ ─ │ │ ├─ ─ │ │ ├ ├ │─ ─ │ │ │ │ │ │ │ ├ ├─ │ │ │ │ │─── prometheus-node-exporter.service
    │   │   ├── prometheus.service
    │   │   └── systemd_check.fact
    │   ├── Handler
    │   │ .yaml
    │   ├── Aufgaben
    │   │   ├── create_prometheus_user.yaml
    │   │   ├── main.yaml 
 │ │ │── │ │ ─ ─ ─ ─ │ │ │ ├── setup_prometheus_node.yaml 
 │ │ └── setup_prometheus_server.yaml 
 │ ├── Templates 
    │   │   └── prometheus.yaml.j2
        └── vars
            └── main.yaml
 

 Geben Sie Folgendes ein, um Ihr Playbook auszuführen:
 
[root@ansible-host production]# ansible-playbook -i <path to host file> playbooks/monitoring.yaml 
 
 

 Sie sollten jetzt in der Lage sein, Benutzer zu erstellen, SSH-Tasten zu drücken und auf die Existenz von systemd zu prüfen , und stellen Sie entweder den prometheus_node_exporter bereit oder die Prometheus-Server-Binärdatei auf die entsprechenden Server. Prometheus sollte mit einer Grundkonfiguration initialisiert werden, einschließlich der Liste der Hosts, die in vars/main. angegeben wurden yaml Datei in der Überwachungsrolle.
 

 Herzliche Glückwünsche! Sie haben jetzt die Installation und Konfiguration eines einfachen Prometheus-Servers automatisiert und Ihre Hosts so konfiguriert, dass sie mit der Datenübertragung beginnen. Als angenehmer Nebeneffekt haben Sie zudem alle Schritte zur Zielerreichung wirkungsvoll dokumentiert.
 
 

 Nachtrag:Als ich diese Serie konzipierte, wollte ich die Installation von Prometheus in OpenShift durcharbeiten; Beim Durchsehen der Dokumentation für das Ansible-Installationsprogramm für OpenShift habe ich jedoch festgestellt, dass dies bereits in einem Playbook enthalten ist und eine Option im Installationsprogramm darstellt.