cloudalchemy.prometheus

VERALTET

Diese Rolle wurde zugunsten der prometheus-community/ansible Sammlung eingestellt.

Ansible Rolle: prometheus

Beschreibung

Bereitstellung des Monitoring-Systems Prometheus mit Ansible.

Upgrade-Hinweis

Beim Upgrade von Version <= 2.4.0 dieser Rolle auf >= 2.4.1 sollte Ihre Prometheus-Instanz abgeschaltet werden. Weitere Informationen in den 2.4.1 Veröffentlichungsnotizen.

Anforderungen

Ansible >= 2.7 (Es könnte in vorherigen Versionen funktionieren, aber wir können das nicht garantieren)
jmespath auf der Bereitstellungsmaschine. Wenn Sie Ansible aus einer Python-virtuellen Umgebung verwenden, installieren Sie jmespath mit pip in dieselbe virtuelle Umgebung.
gnu-tar auf Mac-Bereitstellungs-Host (brew install gnu-tar)

Rollenvariablen

Alle Variablen, die überschrieben werden können, sind in der Datei defaults/main.yml sowie in der folgenden Tabelle gespeichert.

Name	Standardwert	Beschreibung
`prometheus_version`	2.27.0	Version des Prometheus-Pakets. Akzeptiert auch `latest` als Parameter. Nur Prometheus 2.x wird unterstützt.
`prometheus_skip_install`	false	Installationsaufgaben für Prometheus werden übersprungen, wenn auf true gesetzt.
`prometheus_binary_local_dir`	""	Ermöglicht die Verwendung lokaler Pakete anstelle von GitHub-distribuierten. Erwartet ein Verzeichnis, in dem `prometheus` UND `promtool` Binaries auf dem Host gespeichert sind, auf dem Ansible ausgeführt wird. Überschreibt `prometheus_version`.
`prometheus_config_dir`	/etc/prometheus	Pfad zum Verzeichnis mit der Prometheus-Konfiguration.
`prometheus_db_dir`	/var/lib/prometheus	Pfad zum Verzeichnis mit der Prometheus-Datenbank.
`prometheus_read_only_dirs`	[]	Zusätzliche Pfade, die Prometheus lesen darf (nützlich für SSL-Zertifikate außerhalb des Konfigurationsverzeichnisses).
`prometheus_web_listen_address`	"0.0.0.0:9090"	Adresse, auf der Prometheus lauschen wird.
`prometheus_web_config`	{}	Eine Prometheus Web-Konfigurations-Yaml zur Konfiguration von TLS und Authentifizierung.
`prometheus_web_external_url`	""	Externe Adresse, unter der Prometheus verfügbar ist. Nützlich bei Verwendung eines Reverse Proxy. Z.B. `http://example.org/prometheus`.
`prometheus_storage_retention`	"30d"	Zeitraum der Datenspeicherung.
`prometheus_storage_retention_size`	"0"	Zeitraum der Datenspeicherung nach Größe.
`prometheus_config_flags_extra`	{}	Zusätzliche Konfigurationsflags, die beim Start an die Prometheus-Binärdatei übergeben werden.
`prometheus_alertmanager_config`	[]	Konfiguration, die angibt, wo die Alertmanager sind. Dies sollte als Liste im YAML-Format angegeben werden. Kompatibel mit der offiziellen .
`prometheus_alert_relabel_configs`	[]	Regeln zur Umbenennung von Warnungen. Dies sollte als Liste im YAML-Format angegeben werden. Kompatibel mit der offiziellen .
`prometheus_global`	{ scrape_interval: 60s, scrape_timeout: 15s, evaluation_interval: 15s }	Globale Prometheus-Konfiguration. Kompatibel mit offizieller Konfiguration.
`prometheus_remote_write`	[]	Remote Write. Kompatibel mit offizieller Konfiguration.
`prometheus_remote_read`	[]	Remote Read. Kompatibel mit offizieller Konfiguration.
`prometheus_external_labels`	environment: "{{ ansible_fqdn	default(ansible_host)
`prometheus_targets`	{}	Ziele, die abgerufen werden. Ein besseres Beispiel ist auf unserer Demoseite verfügbar.
`prometheus_scrape_configs`	defaults/main.yml#L58	Prometheus-Abrufjobs im selben Format wie in offiziellen Dokumenten.
`prometheus_config_file`	"prometheus.yml.j2"	Variable, die verwendet wird, um benutzerdefinierte Prometheus-Konfigurationsdateien in Form einer Ansible-Vorlage bereitzustellen.
`prometheus_alert_rules`	defaults/main.yml#L81	Vollständige Liste der Alarmierungsregeln, die in `{{ prometheus_config_dir }}/rules/ansible_managed.rules` kopiert werden. Alarmierungsregeln können auch von anderen Dateien bereitgestellt werden, die sich in `{{ prometheus_config_dir }}/rules/` befinden und die die Erweiterung `*.rules` haben.
`prometheus_alert_rules_files`	defaults/main.yml#L78	Liste von Ordnern, in denen Ansible nach Dateien mit Alarmierungsregeln sucht, die in `{{ prometheus_config_dir }}/rules/` kopiert werden. Dateien müssen die Erweiterung `*.rules` haben.
`prometheus_static_targets_files`	defaults/main.yml#L78	Liste von Ordnern, in denen Ansible nach Dateien sucht, die benutzerdefinierte statische Zielkonfigurationsdateien enthalten, die nach `{{ prometheus_config_dir }}/file_sd/` kopiert werden.

Beziehung zwischen `prometheus_scrape_configs` und `prometheus_targets`

Kurze Version

prometheus_targets ist nur eine Karte, die verwendet wird, um mehrere Dateien im Verzeichnis "{{ prometheus_config_dir }}/file_sd" zu erstellen. Die Dateinamen setzen sich aus den oberen Schlüsseln dieser Karte mit der Endung .yml zusammen. Diese Dateien speichern file_sd Abrufzieldaten und müssen in prometheus_scrape_configs gelesen werden.

Lange Version

Ein Teil der prometheus.yml Konfigurationsdatei, der beschreibt, was von Prometheus abgerufen wird, ist in prometheus_scrape_configs gespeichert. Für diese Variable werden dieselben Konfigurationsoptionen verwendet wie in den Prometheus-Dokumenten.

In der Zwischenzeit ist prometheus_targets unsere Möglichkeit, den Prometheus Aabruftyp file_sd zu adaptieren. Es definiert eine Karte von Dateien mit ihrem Inhalt. Obere Schlüssel sind die Basisnamen der Dateien, die ihren eigenen Abrufjob in prometheus_scrape_configs haben müssen, und die Werte sind der Inhalt dieser Dateien.

All dies bedeutet, dass Sie benutzerdefinierte prometheus_scrape_configs mit prometheus_targets auf {} setzen KÖNNEN. Wenn Sie jedoch etwas in prometheus_targets setzen, muss es mit prometheus_scrape_configs abgebildet werden. Wenn dies nicht der Fall ist, erhalten Sie einen Fehler bei den Vorabprüfungen.

Beispiel

Schauen wir uns unsere Standardkonfiguration an, die alle Funktionen zeigt. Standardmäßig haben wir diese prometheus_targets:

prometheus_targets:
  node:  # Dies ist ein Basisdateiname. Die Datei befindet sich in "{{ prometheus_config_dir }}/file_sd/<<BASENAME>>.yml"
    - targets:              #
        - localhost:9100    # All dies ist der Zielabschnitt im file_sd-Format
      labels:               #
        env: test           #

Eine solche Konfiguration führt zur Erstellung einer Datei mit dem Namen node.yml im Verzeichnis {{ prometheus_config_dir }}/file_sd.

Diese Datei muss dann in der Abrufkonfiguration geladen werden. Hier ist eine modifizierte Version unserer Standard prometheus_scrape_configs:

prometheus_scrape_configs:
  - job_name: "prometheus"    # Benutzerdefinierter Abrufjob, der hier `static_config` verwendet
    metrics_path: "/metrics"
    static_configs:
      - targets:
          - "localhost:9090"
  - job_name: "example-node-file-servicediscovery"
    file_sd_configs:
      - files:
          - "{{ prometheus_config_dir }}/file_sd/node.yml" # Diese Zeile lädt die Datei, die aus `prometheus_targets` erstellt wurde

Beispiel

Playbook

---
- hosts: all
  roles:
  - cloudalchemy.prometheus
  vars:
    prometheus_targets:
      node:
      - targets:
        - localhost:9100
        - demo.cloudalchemy.org:9100
        labels:
          env: demosite

Demoseite

Die Prometheus-Organisation bietet eine Demoseite für eine vollständige Monitoring-Lösung basierend auf Prometheus und Grafana. Das Repository mit Code und Links zu laufenden Instanzen ist auf GitHub verfügbar.

Definieren von Alarmierungsregeln-Dateien

Alarmierungsregeln sind in der Variablen prometheus_alert_rules definiert. Das Format ist fast identisch mit dem, das in Prometheus 2.0 Dokumentation definiert ist. Aufgrund der Ähnlichkeiten in den Template-Engines sollten alle Vorlagen in {% raw %} und {% endraw %}-Anweisungen eingeschlossen werden. Ein Beispiel ist in der Datei defaults/main.yml bereitgestellt.

Lokale Tests

Der bevorzugte Weg, die Rolle lokal zu testen, ist die Verwendung von Docker und Molecule (v2.x). Sie müssen Docker auf Ihrem System installieren. Siehe "Erste Schritte" für ein passendes Docker-Paket für Ihr System. Wir verwenden Tox, um den Prozess des Testens auf mehreren Ansible-Versionen zu vereinfachen. Um Tox zu installieren, führen Sie aus:

pip3 install tox

Um Tests auf allen Ansible-Versionen auszuführen (WARNUNG: Dies kann einige Zeit in Anspruch nehmen)

tox

Um einen benutzerdefinierten Molecule-Befehl in einer benutzerdefinierten Umgebung mit nur dem Standard-Test-Szenario auszuführen:

tox -e py35-ansible28 -- molecule test -s default

Für weitere Informationen zu Molecule besuchen Sie deren Dokumentation.

Wenn Sie Tests auf einem Remote-Docker-Host durchführen möchten, geben Sie einfach die Variable DOCKER_HOST vor dem Ausführen der Tox-Tests an.

CircleCI

Die Kombination von Molecule und CircleCI ermöglicht es uns, zu testen, wie neue PRs funktionieren, wenn sie mit mehreren Ansible-Versionen und verschiedenen Betriebssystemen verwendet werden. Dies ermöglicht es uns auch, Testszenarien für unterschiedliche Rollen-Konfigurationen zu erstellen. Als Ergebnis haben wir eine ziemlich große Testmatrix, die länger dauern wird als lokale Tests, also bitte haben Sie Geduld.