0x0i.prometheus

logo ansible

logo prometheus

Rola Ansible :fire: :straight_ruler: Prometheus

Galaxy Role GitHub release (latest by date) License: MIT

Spis treści

Rola Ansible, która instaluje i konfiguruje Prometheus: wielowymiarową, nierozproszoną bazę danych szeregów czasowych oraz zestaw narzędzi do monitorowania i powiadamiania.

Obsługiwane platformy:
* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Wymagania

Wymaga zainstalowania narzędzia unzip/gtar na docelowym hoście. Szczegóły można znaleźć w notatkach modułu ansible unarchive tutaj.

Zmienne roli

Zmienne są dostępne i zorganizowane według następujących etapów instalacji oprogramowania i maszyn:

  • instalacja
  • konfiguracja
  • uruchomienie
  • deinstalacja

Instalacja

prometheus oraz powiązany alertmanager mogą być zainstalowane za pomocą archiwów skompresowanych (.tar, .zip), pobranych i rozpakowanych z różnych źródeł.

Poniższe zmienne można dostosować, aby kontrolować różne aspekty procesu instalacji, takie jak wersja oprogramowania, lokalizacja źródłowa binariów oraz katalog instalacji:

managed_services: <lista-usług (prometheus | alertmanager)> (domyślnie: ['prometheus'])

  • lista usług zestawu Prometheus do zarządzania za pomocą tej roli

prometheus_user: <nazwa-użytkownika-serwisu> (domyślnie: prometheus)

  • dedykowany użytkownik i grupa serwisowa używana przez prometheus do separacji uprawnień (szczegóły tutaj)

install_dir: </ścieżka/do/katalogu/instalacji> (domyślnie: /opt/prometheus)

  • ścieżka na docelowym hoście, gdzie binaria prometheus powinny być rozpakowane

archive_url: <ścieżka-lub-url-do-archiwum> (domyślnie: zobacz defaults/main.yml)

  • adres skompresowanego tar lub zip archiwum zawierającego binaria prometheus. Ta metoda technicznie obsługuje instalację dowolnej dostępnej wersji prometheus. Linki do oficjalnych wersji można znaleźć tutaj.

archive_checksum: <ścieżka-lub-url-do-sumy-kontrolnej> (domyślnie: zobacz defaults/main.yml)

  • adres pliku sum kontrolnych do weryfikacji integralności danych określonego archiwum prometheus. Chociaż zalecane i ogólnie uważane za najlepszą praktykę, podanie sumy kontrolnej nie jest wymagane i można je wyłączyć, podając pusty ciąg ('') jako jego wartość.

checksum_format: <ciąg> (domyślnie: zobacz sha256)

  • algorytm haszujący używany do weryfikacji plików związanych z określoną sumą kontrolną archiwum. Szczegóły na temat sum kontrolnych/haszy kryptograficznych można znaleźć tutaj.

alertmgr_installdir: </ścieżka/do/katalogu/instalacji> (domyślnie: /opt/alertmanager)

  • ścieżka na docelowym hoście, gdzie binaria alertmanager powinny być rozpakowane

exporter_installdir: </ścieżka/do/katalogu/instalacji> (domyślnie: {{ install_dir }}/exporters)

  • ścieżka na docelowym hoście, gdzie binaria eksportera Prometheus powinny być rozpakowane

alertmgr_archive_url: <ścieżka-lub-url-do-archiwum> (domyślnie: zobacz defaults/main.yml)

  • adres skompresowanego tar lub zip archiwum zawierającego binaria alertmanager. Ta metoda technicznie obsługuje instalację dowolnej dostępnej wersji alertmanager. Linki do oficjalnych wersji można znaleźć tutaj.

alertmgr_archive_checksum: <ścieżka-lub-url-do-sumy-kontrolnej> (domyślnie: zobacz defaults/main.yml)

  • adres pliku sum kontrolnych do weryfikacji integralności danych określonego archiwum alertmanager. Chociaż zalecane i ogólnie uważane za najlepszą praktykę, podanie sumy kontrolnej nie jest wymagane i można je wyłączyć, podając pusty ciąg ('') jako jego wartość.

alertmgr_checksum_format: <ciąg> (domyślnie: zobacz sha256)

  • algorytm haszujący używany do weryfikacji plików związanych z określoną sumą kontrolną archiwum. Szczegóły na temat sum kontrolnych/haszy kryptograficznych można znaleźć tutaj.

filesd_path: </ścieżka/do/plików-sd> (domyślnie: {{ install_dir }}/filesd)

  • ścieżka na docelowym hoście, gdzie pliki odkrywania plików prometheus powinny być przechowywane domyślnie

rules_path: </ścieżka/do/plików-reguł> (domyślnie: {{ install_dir }}/rules.d)

  • ścieżka na docelowym hoście, gdzie pliki reguł prometheus powinny być przechowywane domyślnie

templates_path: </ścieżka/do/plików-szablonów-alertmanager> (domyślnie: {{ alertmgr_installdir }}/templates)

  • ścieżka na docelowym hoście, gdzie pliki szablonów alertmanager powinny być przechowywane domyślnie

Konfiguracja

Używając tej roli, konfiguracja instalacji prometheus jest zorganizowana według następujących komponentów:

  • konfiguracja usługi prometheus (prometheus.yml)
  • odkrywanie usługi z plików (file_sd - *.[json|yml])
  • reguły nagrywania i powiadamiania (rule_files - *.[json|yml])
  • konfiguracja usługi alertmanager (alertmanager.yml)
  • pliki szablonów alertmanager (*.tmpl)

Każda konfiguracja może być wyrażona w poniższych zmiennych, aby dostosować zawartość i ustawienia wskazanych plików konfiguracyjnych:

config_dir: </ścieżka/do/katalogu/konfiguracji> (domyślnie: {{ install_dir }})

  • ścieżka na docelowym hoście, gdzie pliki konfiguracyjne prometheus powinny być generowane

data_dir: </ścieżka/do/katalogu/danych> (domyślnie: /var/data/prometheus)

  • ścieżka na docelowym hoście, gdzie prometheus przechowuje dane

alertmgr_configdir: </ścieżka/do/katalogu/konfiguracji> (domyślnie: {{ alertmgr_installdir }})

  • ścieżka na docelowym hoście, gdzie pliki konfiguracyjne alertmanager powinny być generowane

alertmgr_datadir: </ścieżka/do/katalogu/danych> (domyślnie: /var/data/alertmanager)

  • ścieżka na docelowym hoście, gdzie alertmanager przechowuje dane

Konfiguracja usługi Prometheus

Konfiguracja usługi Prometheus może być wyrażona w haszach prometheus_config, które zawiera zestaw par klucz-wartość reprezentujących różne cele skanowania (źródła, z których zbierane są metryki), mechanizmy odkrywania serwisów, reguły nagrywania/powiadamiania oraz konfiguracje do współpracy z systemami zdalnymi wykorzystywanymi przez usługę Prometheus.

Wartości tych kluczy są zazwyczaj słownikami lub listami słowników, które same zawierają zestaw par klucz-wartość przedstawiających odpowiednie specyfikacje/ustawienia (np. interwał skanowania lub częstotliwość, z jaką skanowane są cele pod kątem metryk globalnie). Poniżej przedstawiono przegląd i przykłady konfiguracji każdej z nich dla odniesienia.

:global

[prometheus_config:] global: <klucz: wartość,...> (domyślnie: zobacz defaults/main.yml)

  • określa parametry, które są ważne i pełnią funkcję domyślną w innych kontekstach konfiguracyjnych. Szczegóły tutaj.
Przykład
 prometheus_config:
   global:
     # Jak często skanować cele domyślnie.
     scrape_interval: 15s
     # Jak długo trwa timeout skanowania.
     scrape_timeout: 30s
     # Jak często oceniać reguły.
     evaluation_interval: 30s
     # Etykiety do dodawania do serii czasowych lub alertów podczas komunikacji z
     # systemami zewnętrznymi (federacja, zdalne przechowywanie, Alertmanager).
     external_labels:
       monitor: example
       foo: bar
:scrape_configs

[prometheus_config:] scrape_configs: <lista-słowników> (domyślnie: zobacz defaults/main.yml)

  • określa zestaw celów oraz parametrów opisujących sposób ich skanowania zorganizowanych w obiekty

Cele mogą być skonfigurowane statycznie lub dynamicznie odkrywane przy użyciu jednego z obsługiwanych mechanizmów odkrywania serwisów. Szczegóły tutaj oraz tutaj można znaleźć listę obsługiwanych metod odkrywania serwisów.

Przykład
 prometheus_config:
   scrape_configs:
     - job_name: static-example
       static_configs:
       - targets: ['localhost:9090', 'localhost:9191']
         labels:
           example: label
     - job_name: kubernetes-example
       kubernetes_sd_configs:
       - role: endpoints
         api_server: 'https://localhost:1234'
         namespaces:
           names:
             - default
:rule_files

[prometheus_config:] rule_files: <lista> (domyślnie: zobacz defaults/main.yml)

  • określa listę globów wskazującą nazwy plików i ścieżki

Reguły i powiadomienia są odczytywane ze wszystkich dopasowanych plików. Reguły dzielą się na dwie kategorie: reguły nagrywania i reguły powiadamiania. Szczegóły dotyczące reguł nagrywania można znaleźć tutaj oraz szczegóły dotyczące reguł powiadamiania tutaj.

Przykład
 prometheus_config:
   rule_files:
   - "example.yml"
   - "example_rules/*"
:remote_read

[prometheus_config:] remote_read: <lista-słowników> (domyślnie: zobacz defaults/main.yml)

  • określa ustawienia związane z funkcją zdalnego odczytu

Szczegóły tutaj. Aby zapoznać się z listą dostępnych wtyczek/integracji do zdalnego odczytu/przechowywania, można odwiedzić ten link.

Przykład
 prometheus_config:
   remote_read:
   - url: http://remote1/read
     read_recent: true
     name: default
   - url: http://remote2/read
     read_recent: false
     name: read_special
     required_matchers:
       job: special
     tls_config:
       cert_file: valid_cert_file
       key_file: valid_key_file
:remote_write

[prometheus_config:] remote_write: <lista-słowników> (domyślnie: zobacz defaults/main.yml)

  • określa ustawienia związane z funkcją zdalnego zapisu

Szczegóły tutaj. Aby zapoznać się z listą dostępnych wtyczek/integracji do zdalnego zapisu/przechowywania, można odwiedzić ten link.

Przykład
 prometheus_config:
   remote_write:
   - name: drop_expensive
     url: http://remote1/push
     write_relabel_configs:
     - source_labels: [__name__]
       regex: expensive.*
       action: drop
   - name: rw_tls
     url: http://remote2/push
     tls_config:
       cert_file: valid_cert_file
       key_file: valid_key_file
:alerting

[prometheus_config:] alerting: <klucz: wartość,...> (domyślnie: zobacz defaults/main.yml)

  • wskazuje ustawienia związane z Alertmanagerem, a także instancje Alertmanagera, do których Prometheus wysyła powiadomienia

Ten sekcja zawiera parametry do skonfigurowania komunikacji z tymi Alertmanagerami. Alertmanagerzy mogą być skonfigurowani statycznie za pomocą parametru konfiguracji statycznej lub dynamicznie odkrywani przy użyciu jednego z obsługiwanych mechanizmów odkrywania serwisów. Szczegóły tutaj.

Przykład
 prometheus_config:
   alerting:
     alertmanagers:
     - scheme: https
       static_configs:
     - targets:
       - "1.2.3.4:9093"
       - "1.2.3.5:9093"

Odkrywanie usługi za pomocą plików

Odkrywanie usług oparte na plikach dostarcza bardziej ogólny sposób na skonfigurowanie statycznych celów i służy jako interfejs do podłączania niestandardowych mechanizmów odkrywania usług. Odczytuje zestaw plików zawierających listę zero lub więcej <static_config>. Zmiany we wszystkich zdefiniowanych plikach są wykrywane za pomocą obserwacji dysku i stosowane natychmiast. Pliki można podać w formacie YAML lub JSON. Tylko zmiany prowadzące do prawidłowo sformowanych grup celów są stosowane. Szczegóły tutaj.

prometheus_file_sd: <lista-słowników> (domyślnie: [])

  • określa konfiguracje prometheus file_sd do generowania

Używając tej roli, ustawienia konfiguracji oparte na plikach mogą być wyrażone w haszu prometheus_file_sd, który zawiera listę słowników encapsulujących ścieżkę, nazwę i zawartość konfiguracji pliku yaml lub json, który ma być załadowany przez prometheus do odkrywania usług na podstawie plików.

[prometheus_file_sd : <element>:] name: <ciąg> (domyślnie: BRAK - wymagane)

  • nazwa pliku file_sd do wygenerowania

[prometheus_file_sd : <element>:] path: <ciąg> (domyślnie: {{ install_dir }}/file_sd)

  • ścieżka pliku file_sd do wygenerowania

[prometheus_file_sd : <element>:] config: <lista-słowników> (domyślnie: BRAK - wymagane)

  • lista słowników reprezentujących ustawienia określające zestaw statycznych celów do określenia w pliku file_sd
Przykład
 prometheus_file_sd:
 - name: example-file.slow.json
   config:
   - targets: ["host1:1234"]
     labels:
       test-label: example-slow-file-sd
 - name: file.yml
   path: /etc/prometheus/file_sd
   config:
   - targets: ["host2:1234"]

NB: Przy użyciu file_sd oczekiwany jest odpowiedni obiekt scrape_config w pliku prometheus.yml, aby umożliwić pomyślne ładowanie.

Pliki reguł

Prometheus obsługuje dwa typy reguł, które mogą być skonfigurowane i następnie oceniane w regularnych odstępach: reguły nagrywania i reguły powiadamiania. Reguły nagrywania pozwalają na wstępne obliczenie często potrzebnych lub wymagających obliczeń wyrażeń i zapisanie ich wyniku jako nowego zestawu serii czasowych. Reguły powiadamiania pozwalają na definiowanie warunków powiadamiania na podstawie wyrażeń języka programowania Prometheus i wysyłanie powiadomień o aktywujących się alertach do zewnętrznych usług. Szczegóły tutaj.

prometheus_rule_files: <lista-słowników> (domyślnie: [])

  • określa pliki reguł prometheus do wygenerowania

Używając tej roli, zarówno reguły nagrywania, jak i reguły powiadamiania mogą być wyrażone w hashu prometheus_rule_files, który zawiera listę słowników encapsulujących ścieżkę, nazwę i zawartość konfiguracji pliku yaml lub json, który ma być załadowany przez prometheus do ustawienia reguł.

[prometheus_rule_files : <element>:] name: <ciąg> (domyślnie: BRAK - wymagane)

  • nazwa pliku reguł do wygenerowania

[prometheus_rule_files : <element>:] path: <ciąg> (domyślnie: {{ install_dir }}/rules.d)

  • ścieżka pliku reguł do wygenerowania

[prometheus_rule_files : <element>:] config: <lista-słowników> (domyślnie: BRAK - wymagane)

  • lista słowników reprezentujących ustawienia wskazujące zestaw grup reguł do określenia w pliku reguł
Przykład
prometheus_rule_files:
- name: example-rules.yml
 config:
   groups:
   - name: recording rule example
     rules:
     - record: job:http_inprogress_requests:sum
       expr: sum(http_inprogress_requests) by (job)
- name: nondefault-path-example-rules.yml
 path: /etc/prometheus/rules.d
 config:
   groups:
   - name: alerting rule example
     rules:
     - alert: HighRequestLatency
       expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
       for: 10m
       labels:
         severity: page
       annotations:
         summary: Wysoka latencja żądania

NB: Oczekiwany jest odpowiedni obiekt rule_files w pliku prometheus.yml, aby umożliwić pomyślne ładowanie.

Konfiguracja usługi Alertmanager

Konfiguracja usługi Alertmanager może być wyrażona w haszach alertmanager_config, które zawierają zestaw par klucz-wartość, reprezentujący jeden z sekcji wskazujących różne trasy, odbiorniki, szablony i konfiguracje tłumienia alertów.

Wartości tych kluczy są zazwyczaj słownikami lub listami słowników, które same zawierają zestaw par klucz-wartość przedstawiających odpowiednie specyfikacje/ustawienia (np. adres URL API do użycia dla powiadomień Slack) dla każdej sekcji. Poniżej przedstawiono przegląd i przykłady konfiguracji każdej z nich dla odniesienia.

:global

[alertmanager_config:] global: <klucz: wartość,...> (domyślnie: zobacz defaults/main.yml)

  • określa parametry, które są ważne i pełnią funkcję domyślną w innych kontekstach konfiguracyjnych. Szczegóły tutaj.
Przykład
 alertmanager_config:
   global:
     # Smarthost i nadawca SMTP używany do powiadomień e-mail.
     smtp_smarthost: 'localhost:25'
     smtp_from: 'alertmanager@example.org'
     smtp_auth_username: 'alertmanager'
     smtp_auth_password: 'password'
     # Token uwierzytelniający dla Hipchat.
     hipchat_auth_token: '1234556789'
     # Alternatywny host dla Hipchat.
     hipchat_api_url: 'https://hipchat.foobar.org/'
:route

[alertmanager_config:] route: <klucz: wartość,...> (domyślnie: zobacz defaults/main.yml)

  • definiuje węzeł w drzewie routingu i jego dzieci

Każdy alert wchodzi do drzewa routingu na skonfigurowanej trasie głównej, która musi pasować do wszystkich alertów (tj. nie może mieć skonfigurowanych matcherów). Następnie przeszukuje węzły potomne. Jeśli ustawiono kontynuację na fałsz, zatrzymuje się po pierwszym dopasowanym węźle. Jeśli kontynuacja jest prawdziwa w dopasowanym węźle, alert będzie kontynuowany podczas dopasowywania do kolejnych rodzeństwa. Szczegóły tutaj.

Przykład
 alertmanager_config:
   route:
     receiver: 'default-receiver'
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 4h
     group_by: [cluster, alertname]
     # Wszystkie alerty, które nie pasują do poniższych tras dzieci,
     # pozostaną w węźle głównym i będą kierowane do 'default-receiver'.
     routes:
       # Wszystkie alerty z service=mysql lub service=cassandra
       # są kierowane do dzwonka bazy danych.
     - receiver: 'database-pager'
       group_wait: 10s
       match_re:
         service: mysql|cassandra
     # Wszystkie alerty z etykietą team=frontend pasują do tej podtrasy.
     # Są grupowane według produktu i środowiska zamiast cluster
     # i alertname.
     - receiver: 'frontend-pager'
       group_by: [product, environment]
       match:
         team: frontend
:receivers

[alertmanager_config:] inhibit_rules: <lista-słowników> (domyślnie: zobacz defaults/main.yml)

  • określa listę odbiorników powiadomień

Odbiorniki to nazwane konfiguracje jednego lub więcej integracji powiadomień. Szczegóły tutaj.

Przykład
 alertmanager_config:
   receivers:
   - name: 'team-X-mails'
     email_configs:
     - to: 'team-X+alerts@example.org'
     pagerduty_configs:
     - service_key: <team-X-key>
     hipchat_configs:
     - auth_token: <auth_token>
       room_id: 85
       message_format: html
       notify: true
:inhibit_rules

[alertmanager_config:] inhibit_rules: <lista-słowników> (domyślnie: zobacz defaults/main.yml)

  • określa listę reguł tłumienia

Reguła tłumienia wycisza alert (cel) pasujący do zestawu matcherów, gdy istnieje alert (źródło), który pasuje do innego zestawu matcherów. Szczegóły tutaj.

Przykład
 alertmanager_config:
   inhibit_rules:
   - source_match:
       severity: 'critical'
     target_match:
       severity: 'warning'
     # Stosować wyciszenie, jeśli nazwa alertu jest taka sama.
     equal: ['alertname', 'cluster', 'service']
:templates

[alertmanager_config:] templates: <lista> (domyślnie: zobacz defaults/main.yml)

  • określa pliki i katalogi, z których odczytywane są szablony powiadomień

Ostatni komponent może używać pasera wildcard, np. templates/*.tmpl. Szczegóły tutaj dla odniesienia szablonów powiadomień oraz ten link dla przykładów.

Przykład
 alertmanager_config:
   templates:
   - '/etc/alertmanager/template/*.tmpl'

Szablony Alertmanager

Prometheus tworzy i wysyła alerty do Alertmanagera, który następnie wysyła powiadomienia do różnych odbiorników na podstawie ich etykiet. Powiadomienia wysyłane do odbiorników są konstruowane za pomocą szablonów. Alertmanager ma domyślne szablony, ale można je również dostosować. Szczegóły tutaj.

altermanager_templates: <lista-słowników> (domyślnie: [])

  • określa konfiguracje szablonów powiadomień alertmanager.

Używając tej roli, ustawienia konfiguracji szablonów alertmanager mogą być wyrażone w haszu alertmanager_templates, który zawiera listę słowników reprezentujących i encapsulujących ścieżkę, nazwę i zawartość konfiguracji pliku tmpl, który ma być załadowany przez alertmanager.

[alertmanager_templates : <element>:] name: <ciąg> (domyślnie: BRAK - wymagane)

  • nazwa pliku szablonu do wygenerowania

[alertmanager_templates : <element>:] path: <ciąg> (domyślnie: {{ alertmgr_installdir }}/templates)

  • ścieżka pliku szablonu do wygenerowania

[alertmanager_templates : <element>:] config: <lista-słowników> (domyślnie: BRAK - wymagane)

  • lista słowników reprezentujących ustawienia wskazujące zestaw konfiguracji szablonów do wygenerowania
Przykład
 alertmanager_templates:
 - name: test
   config:
   - define: "myorg.test.guide"
     template: 'https://internal.myorg.net/wiki/alerts/\{\{ .GroupLabels.app \}\}/\{\{ .GroupLabels.alertname \}\}'
 - name: test2
   path: /etc/alertmanager/templates
   config:
   - define: "myorg.test.text"
     template: 'summary: \{\{ .CommonAnnotations.summary \}\}\ndescription: \{\{ .CommonAnnotations.description \}\}'

NB: Oczekiwany jest odpowiedni obiekt templates w pliku alertmanager.yml, aby umożliwić pomyślne ładowanie.

Uruchomienie

Ta rola obsługuje uruchamianie wszystkich komponentów ekosystemu monitorowania i powiadamiania Prometheus. Składa się to zarówno z usług Prometheus, jak i Alertmanager, oraz różnych eksporterów metryk. Uruchomienie każdej z nich odbywa się z wykorzystaniem narzędzia zarządzania usługami systemd, które zarządza usługami jako procesami w tle lub demonami, zgodnie z konfiguracją i możliwościami wykonawczymi zapewnianymi przez jego podstawową strukturę zarządzania.

Poniższe zmienne można dostosować, aby zarządzać systemd [Service] definicją jednostki i profilem/zasadą wykonania:

Prometheus

extra_run_args: <opcje-cli-prometheus> (domyślnie: [])

  • lista argumentów wiersza poleceń prometheus, które mają być przekazywane do binariów podczas uruchamiania w celu dostosowania uruchomienia.

Pełne wyrażenie prometheus's cli, ta zmienna umożliwia dostosowanie uruchomienia zgodnie z specyfikacją użytkownika.

custom_unit_properties: <hasz-ustawień-systemd-serwisu> (domyślnie: [])

  • hasz ustawień używanych do dostosowania konfiguracji jednostki [Service] i środowiska wykonawczego usługi Prometheus systemd.
Alertmanager

extra_alertmgr_args: <opcje-cli-alertmanager> (domyślnie: [])

  • lista argumentów wiersza poleceń alertmanager, które mają być przekazywane do binariów podczas uruchamiania w celu dostosowania uruchomienia.

Pełne wyrażenie alertmanager's cli, ta zmienna umożliwia dostosowanie uruchomienia zgodnie z specyfikacją użytkownika.

custom_alertmgr_properties: <hasz-ustawień-systemd-serwisu> (domyślnie: [])

  • hasz ustawień używanych do dostosowania konfiguracji jednostki [Service] i środowiska wykonawczego usługi Alertmanager systemd.
Eksporterzy

prometheus_exporters: <lista-słowników> (domyślnie: [])

  • określa eksporterów prometheus do zainstalowania, uruchomienia i zarządzania jako usługi systemd.

Każdy wpis w słowniku eksportera powinien wskazywać kilka właściwości, w tym nazwę, adres URL i adres nasłuchu eksportera, aby zapewnić prawidłowe ustawienie i komunikację z serwerem Prometheus. Inne właściwości używane do dostosowania działania eksportera mogą być opcjonalnie określone za pomocą zmiennej extra_args, która dodaje podane argumenty wiersza poleceń do ustawienia ExecStart jednostki eksportera. Szczegóły tutaj dla odniesienia i lista wtyczek eksportera.

[prometheus_exporters : <element>:] name: <ciąg> (domyślnie: BRAK - wymagane)

  • nazwa eksportera Prometheus do zainstalowania

[prometheus_exporters : <element>:] url: <ciąg> (domyślnie: BRAK - wymagane)

  • adres URL eksportera Prometheus do zainstalowania

[prometheus_exporters : <element>:] description: <ciąg> (domyślnie: <nazwa-eksportera>)

  • opis lub dokumentacja eksportera Prometheus, dołączana do pliku jednostki eksportera w formacie Systemd

[prometheus_exporters : <element>:] unit_properties: <hasz> (domyślnie: {})

  • hasz ustawień używanych do dostosowania konfiguracji jednostki [Service] i środowiska wykonawczego systemd.
Przykład
 prometheus_exporters:
   - name: node_exporter
     url: https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
     description: https://github.com/prometheus/node_exporter
     unit_properties:
       User: exporter
       Group: exporter
     extra_args:
       - '--web.listen-address=0.0.0.0:9110'
       - '--log.level=debug'

Deinstalacja

Wsparcie dla deinstalacji i usuwania artefaktów potrzebnych do wdrożenia pozwala użytkownikom/operatorom przywrócić docelowy host do stanu, w którym był przed zastosowaniem tej roli. Może to być przydatne do recyklingu węzłów i ról oraz być może zapewnić bardziej łagodne/zarządzane przejścia między aktualizacjami narzędzi.

Poniższa zmienna(y) mogą być dostosowane do zarządzania tym procesem deinstalacji:

perform_uninstall: <true | false> (domyślnie: false)

  • czy deinstalować i usuwać wszystkie artefakty i resztki tej instalacji prometheus na docelowym hoście (zobacz: handlers/main.yml dla szczegółów)

Zależności

  • 0x0i.systemd

Przykładowa książka

domyślny przykład:

- hosts: all
  roles:
  - role: 0x0I.prometheus

tylko zainstalować i zarządzać usługą Prometheus (wyłączyć konfigurację alertmanagera):

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      managed_services: ['prometheus']

zainstalować konkretna wersję Prometheus:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      archive_url: https://github.com/prometheus/prometheus/releases/download/v2.15.0/prometheus-2.15.0.linux-amd64.tar.gz
      archive_checksum: 1c2175428e7a70297d97a30a04278b86ccd6fc53bf481344936d6573482203b4

dostosować lokacje instalacji, konfiguracji i danych Prometheus oraz Alertmanager:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      install_dir: /usr/local
      config_dir: /etc/prometheus
      data_dir: /var/lib/prometheus
      alertmgr_installdir: /usr/local
      alertmgr_configdir: /etc/alertmanager
      alertmgr_datadir: /var/lib/alertmanager

dostosować globalne ustawienia interwałów skanowania i oceny:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        global:
          scrape_interval: 30s
          scrape_timeout: 30s
          evaluation_interval: 30s

dostosować konfigurację alertów Prometheus/Alermanager:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        alerting:
          alertmanagers:
          - scheme: https
            static_configs:
            - targets:
              - "1.2.3.4:9093"

utworzyć reguły nagrywania i powiadamiania:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        rule_files:
        - /etc/prometheus/rules.d/*
      prometheus_rule_files:
      - name: example-rules.yml
        path: /etc/prometheus/rules.d/*
        config:
          groups:
            - name: recording rule example
              rules:
                - record: job:http_inprogress_requests:sum
                  expr: sum(http_inprogress_requests) by (job)
      - name: another-example.yml
        path: /etc/prometheus/rules.d
        config:
          groups:
            - name: alerting rule example
              rules:
                - alert: HighRequestLatency
                  expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
                  for: 10m
                  labels:
                    severity: page
                  annotations:
                    summary: Wysoka latencja żądania

static konfiguracja celów z nadpisanym skanowaniem i oceną:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: static-example
           static_configs:
           - targets: ['localhost:9090', 'localhost:9191']
             labels:
               my:   label
               your: label
          scrape_interval: 10s
          scrape_timeout: 10s
          evaluation_interval: 10s

konfiguracja file_sd z nadpisanymi skanowaniem i oceną:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: file-sd-example
            file_sd_configs:
            - files:
              - foo/*.slow.json
              - single/file.yml
              refresh_interval: 10m
            - files:
             - bar/*.yml
      prometheus_file_sd:
      - name: example-file.slow.json
        path: foo
        config:
        - targets: ["host1:1234"]
          labels:
            test-label: example-slow-file-sd
      - name: foo.yml
        path: bar
        config:
        - targets: ["host2:1234"]
      - name: file.yml
        path: single
        config:
        - targets: ["host3:1234"]

konfiguracja celów oparta na dns:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: dns-example
          dns_sd_configs:
          - refresh_interval: 15s
            names:
            - first.dns.address.domain.com
            - second.dns.address.domain.com
          - names:
            - third.dns.address.domain.com

konfiguracja celów kubernetes z ustawieniami TLS i uwierzytelnieniem podstawowym:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: kubernetes-example
          kubernetes_sd_configs:
          - role: endpoints
            api_server: 'https://localhost:1234'
            tls_config:
              cert_file: valid_cert_file
              key_file: valid_key_file
            basic_auth:
              username: 'myusername'
              password: 'mysecret'

konfiguracja celów ec2:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: ec2-example
          ec2_sd_configs:
          - region: us-east-1
            access_key: access
            secret_key: mysecret
            profile: profile
            filters:
            - name: tag:environment
              values:
              - prod
            - name: tag:service
              values:
              - web
              - db

konfiguracja celów openstack:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: openstack-example
          openstack_sd_configs:
          - role: instance
            region: RegionOne
            port: 80
            refresh_interval: 1m

konfiguracja celów azure:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: azure-example
          azure_sd_configs:
    -       environment: AzurePublicCloud
            authentication_method: OAuth
            subscription_id: 11AAAA11-A11A-111A-A111-1111A1111A11
            tenant_id: BBBB222B-B2B2-2B22-B222-2BB2222BB2B2
            client_id: 333333CC-3C33-3333-CCC3-33C3CCCCC33C
            client_secret: mysecret
            port: 9100

konfiguracja celów marathon:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: marathon-example
          marathon_sd_configs:
          - servers:
            - 'https://marathon.example.com:443'
            auth_token: "mysecret"

konfiguracja celów consul:

- hosts: all
  roles:
  - role: 0x0I.prometheus
    vars:
      prometheus_config:
        scrape_configs:
        - job_name: consul-example
          consul_sd_configs:
          - server: 'localhost:1234'
            token: mysecret
            services: ['nginx', 'cache', 'mysql']
            tags: ["canary", "v1"]
            node_meta:
              rack: "123"
            allow_stale: true
            scheme: https

Licencja

MIT

Informacje o autorze

Rola ta została stworzona w 2019 roku przez O1.IO.

O projekcie

Prometheus - a multi-dimensional time-series data monitoring and alerting toolkit

Zainstaluj
ansible-galaxy install 0x0i.prometheus
Licencja
Unknown
Pobrania
923
Właściciel