cloudalchemy.prometheus

ZANIECHANE

Ta rola została zastąpiona kolekcją prometheus-community/ansible.

Rola Ansible: prometheus

Opis

Zainstaluj system monitorowania Prometheus za pomocą ansible.

Powiadomienie o aktualizacji

Przy aktualizacji z wersji <= 2.4.0 tej roli do >= 2.4.1, proszę wyłączyć instancję prometheus. Więcej informacji w notatkach o wersji 2.4.1.

Wymagania

Ansible >= 2.7 (Może działać na wcześniejszych wersjach, ale nie możemy tego zagwarantować)
jmespath na maszynie wdrożeniowej. Jeśli używasz Ansible z wirtualnego środowiska Pythona, zainstaluj jmespath w tym samym wirtualnym środowisku za pomocą pip.
gnu-tar na hoście Mac do wdrożeń (brew install gnu-tar)

Zmienne roli

Wszystkie zmienne, które można nadpisać, są przechowywane w pliku defaults/main.yml oraz w poniższej tabeli.

Nazwa	Wartosc Domyślna	Opis
`prometheus_version`	2.27.0	Wersja pakietu Prometheus. Akceptuje także `latest` jako parametr. Tylko Prometheus 2.x jest obsługiwany.
`prometheus_skip_install`	false	Zadania instalacyjne Prometheus są pomijane, gdy ustawione na true.
`prometheus_binary_local_dir`	""	Umożliwia użycie lokalnych pakietów zamiast tych dostarczonych na githubie. Jako parametr przyjmuje katalog, w którym znajdują się binaria `prometheus` i `promtool`. Ta opcja nadpisuje parametr `prometheus_version`.
`prometheus_config_dir`	/etc/prometheus	Ścieżka do katalogu z konfiguracją prometheus.
`prometheus_db_dir`	/var/lib/prometheus	Ścieżka do katalogu z bazą danych prometheus.
`prometheus_read_only_dirs`	[]	Dodatkowe ścieżki, które Prometheus może odczytywać (przydatne dla certyfikatów SSL poza katalogiem konfiguracyjnym).
`prometheus_web_listen_address`	"0.0.0.0:9090"	Adres, na którym Prometheus będzie nasłuchiwać.
`prometheus_web_config`	{}	Konfiguracja WEB Prometheus w formacie yaml, do konfiguracji TLS i autoryzacji.
`prometheus_web_external_url`	""	Zewnętrzny adres, pod którym jest dostępny Prometheus. Przydatne, gdy jest za odwrotnym proxy. Przykład: `http://example.org/prometheus`.
`prometheus_storage_retention`	"30d"	Okres przechowywania danych.
`prometheus_storage_retention_size`	"0"	Okres przechowywania danych według rozmiaru.
`prometheus_config_flags_extra`	{}	Dodatkowe flagi konfiguracyjne przekazywane do binarnego pliku prometheus przy uruchamianiu.
`prometheus_alertmanager_config`	[]	Konfiguracja wskazująca, gdzie znajdują się alertmanagerzy. Powinna być określona jako lista w formacie yaml. Zgodna z oficjalną dokumentacją .
`prometheus_alert_relabel_configs`	[]	Reguły przetwarzania alertów. Powinna być określona jako lista w formacie yaml. Zgodna z oficjalną dokumentacją .
`prometheus_global`	{ scrape_interval: 60s, scrape_timeout: 15s, evaluation_interval: 15s }	Globalna konfiguracja Prometheus. Zgodna z oficjalną konfiguracją.
`prometheus_remote_write`	[]	Zdalne zapisywanie. Zgodne z oficjalną konfiguracją.
`prometheus_remote_read`	[]	Zdalne odczytywanie. Zgodne z oficjalną konfiguracją.
`prometheus_external_labels`	environment: "{{ ansible_fqdn	default(ansible_host)
`prometheus_targets`	{}	Cele, które będą monitorowane. Lepszy przykład znajduje się na naszej stronie demonstracyjnej.
`prometheus_scrape_configs`	defaults/main.yml#L58	Zadania skrapujące Prometheus w formacie zgodnym z oficjalnymi dokumentami.
`prometheus_config_file`	"prometheus.yml.j2"	Zmienna używana do przekazania niestandardowego pliku konfiguracyjnego prometheus w formie szablonu ansible.
`prometheus_alert_rules`	defaults/main.yml#L81	Pełna lista reguł alarmowych, które zostaną skopiowane do `{{ prometheus_config_dir }}/rules/ansible_managed.rules`. Reguły alarmowe można również podać w innych plikach znajdujących się w `{{ prometheus_config_dir }}/rules/` z rozszerzeniem `*.rules`.
`prometheus_alert_rules_files`	defaults/main.yml#L78	Lista folderów, w których ansible będzie szukać plików zawierających reguły alarmowe, które zostaną skopiowane do `{{ prometheus_config_dir }}/rules/`. Pliki muszą mieć rozszerzenie `*.rules`.
`prometheus_static_targets_files`	defaults/main.yml#L78	Lista folderów, w których ansible będzie szukać plików zawierających niestandardowe pliki konfiguracyjne statycznych celów, które zostaną skopiowane do `{{ prometheus_config_dir }}/file_sd/`.

Związek między `prometheus_scrape_configs` a `prometheus_targets`

Krótka wersja

prometheus_targets to po prostu mapa używana do tworzenia wielu plików znajdujących się w katalogu "{{ prometheus_config_dir }}/file_sd". Nazwy plików składają się z kluczy najpierwszego poziomu tej mapy z sufiksem .yml. Te pliki przechowują dane celów do skrapowania file_sd i muszą być odczytywane w prometheus_scrape_configs.

Długa wersja

Część pliku konfiguracyjnego prometheus.yml, która opisuje, co jest skrapowane przez prometheus, jest przechowywana w prometheus_scrape_configs. Dla tej zmiennej używane są te same opcje konfiguracyjne, jak opisano w dokumentacji prometheus.

Tymczasem prometheus_targets to nasz sposób na zaakceptowanie rodzaju skrapowania prometheus file_sd. Definiuje mapę plików z ich zawartością. Klucze najwyższego poziomu to nazwy bazowe plików, które muszą mieć swoje własne zadanie skrapowania w prometheus_scrape_configs, a wartości to zawartość tych plików.

Oznacza to, że możesz używać niestandardowych prometheus_scrape_configs z prometheus_targets ustawionym na {}. Jednak gdy ustawisz coś w prometheus_targets, musi być to powiązane z prometheus_scrape_configs. Jeśli nie będzie to poprawne, otrzymasz błąd w kontrolach wstępnych.

Przykład

Zobaczmy naszą domyślną konfigurację, która pokazuje wszystkie funkcje. Domyślnie mamy prometheus_targets:

prometheus_targets:
  node:  # To jest nazwa bazowa pliku. Plik znajduje się w "{{ prometheus_config_dir }}/file_sd/<<BASENAME>>.yml"
    - targets:              #
        - localhost:9100    # Cała ta sekcja to cele w formacie file_sd
      labels:               #
        env: test           #

Taka konfiguracja doprowadzi do utworzenia pliku o nazwie node.yml w katalogu {{ prometheus_config_dir }}/file_sd.

Następnie ten plik musi być załadowany do konfiguracji skrapowania. Oto zmodyfikowana wersja naszego domyślnego prometheus_scrape_configs:

prometheus_scrape_configs:
  - job_name: "prometheus"    # Niestandardowe zadanie skrapowania, tutaj używające `static_config`
    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" # Ten wiersz ładuje plik utworzony z `prometheus_targets`

Przykład

Playbook

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

Strona demonstracyjna

Organizacja Prometheus udostępnia stronę demonstracyjną pełnego rozwiązania monitorującego opartego na prometheus i grafana. Repozytorium z kodem i linkami do działających instancji jest dostępne na githubie.

Definiowanie plików reguł alarmowych

Reguły alarmowe są definiowane w zmiennej prometheus_alert_rules. Format jest prawie identyczny temu zdefiniowanemu w dokumentacji Prometheus 2.0. Ze względu na podobieństwo w silnikach szablonów, wszystkie szablony powinny być opakowane w instrukcje {% raw %} i {% endraw %}. Przykład znajduje się w pliku defaults/main.yml.

Testowanie lokalne

Preferowany sposób testowania roli lokalnie to użycie Dockera i molecule (v2.x). Musisz zainstalować Dockera na swoim systemie. Zobacz "Rozpocznij", aby znaleźć odpowiedni pakiet Dockera dla swojego systemu. Używamy tox, aby uprościć proces testowania na wielu wersjach ansible. Aby zainstalować tox, wykonaj:

pip3 install tox

Aby uruchomić testy na wszystkich wersjach ansible (OSTRZEŻENIE: może to zająć trochę czasu)

tox

Aby uruchomić niestandardowe polecenie molekuł w niestandardowym środowisku tylko z domyślnym scenariuszem testowym:

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

Aby uzyskać więcej informacji o molekule, zajrzyj do ich dokumentacji.

Jeśli chcesz uruchomić testy na zdalnym hoście dockerowym, po prostu określ zmienną DOCKER_HOST przed uruchomieniem testów tox.

CircleCI

Łączenie molekuły i CircleCI pozwala nam testować, jak nowe PR-y będą działać z wieloma wersjami ansible i wieloma systemami operacyjnymi. To pozwala nam również tworzyć scenariusze testowe dla różnych konfiguracji roli. W rezultacie mamy dość dużą matrycę testową, która zajmie więcej czasu niż testy lokalne, więc proszę być cierpliwym.