0x0i.prometheus
Rola Ansible :fire: :straight_ruler: Prometheus
Spis treści
- Obsługiwane platformy
- Wymagania
- Zmienne roli
- Zależności
- Przykładowa książka
- Licencja
- Informacje o autorze
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 wersjiprometheus
. 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 wersjialertmanager
. 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 wykonawczegosystemd.
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.
Prometheus - a multi-dimensional time-series data monitoring and alerting toolkit
ansible-galaxy install 0x0i.prometheus