Jak podzielić pliki konfiguracyjne Prometheus?

10

Obecnie używamy Prometheusa do monitorowania i mamy dużo konfiguracji (nasz główny plik konfiguracyjny prometheus.yml ma ponad 1400 linii).

Chciałbym podzielić to na logiczne grupy (może DEV / TEST / PROD?), Ale nie mogę znaleźć żadnej dokumentacji dotyczącej użycia „włącza” (lub podobnego) w składni pliku konfiguracyjnego Prometheus.

Czy ktoś zrobił to ze swoim plikiem konfiguracyjnym Prometheus? Jeśli tak, jak to zrobiłeś?

configuration configuration-management prometheus

— srkiNZ84
źródło

Co ze skryptem łączącym wiele plików w jeden?

— gf_

Tak, myślę, że właśnie to muszę zrobić. Ale w najlepszym razie jest to „obejście”. Chciałem móc stworzyć mały plik konfiguracyjny, definiując „nazwa_zadania” do testowania konfiguracji (jak sądzę „rozwój” skrobania konfiguracji), a następnie po prostu wywołać „przeładuj”, aby go wypróbować.

— srkiNZ84,

8

Plik konfiguracyjny Prometheus (i inne pliki konfiguracyjne w ekosystemie) wyraźnie nie obsługują żadnej formy szablonów. Zamiast tego należy to do systemu zarządzania konfiguracją.

Dodatkowo brzmi to trochę nietypowo, że masz sekcje dev / test / prod w pliku konfiguracyjnym. Zwykle a) będziesz mieć Prometheus na środowisko ib) główna różnica między tymi serwerami Prometheus byłaby inną wartością dla envtwojej etykiety external_labels.

— brian-brazil
źródło

Czy to nie narusza idei „pojedynczej tafli szkła”? Jak moglibyśmy porównywać wskaźniki DEV z PROD, gdybyśmy mieli osobne wystąpienia dla każdego środowiska? Czy powinniśmy używać stowarzyszonego Prometheusa w tym przypadku użycia?

— srkiNZ84,

Przypadek użycia jest taki, że mamy osobne klastry Kubernetes DEV / TEST / PROD. W przypadku każdego klastra korzystamy z funkcji „wykrywania usług”, aby uzyskać wszystkie dane z obiektów usługi i zasobnika (kontenera).

— srkiNZ84,

1

Prometeusz nie ma idei pojedynczej tafli szkła, która nie nadaje się dobrze do niczego poza najmniejszymi systemami. Nawet metryki samego Prometeusza są zbyt duże dla jednej tafli szkła, to bardziej jak 4-5. Typowym podejściem byłoby użycie szablonów źródeł danych w Grafanie i można porównywać pulpity nawigacyjne obok siebie.

— brian-brazil

0

Możesz odciążyć swoje cele do innych plików lub użyć narzędzia do wykrywania usług, takiego jak consul.

  - job_name: yyy
    metrics_path: /probe
    scrape_interval: 10s
    scheme: https
    params:
      module:
        - http_2xx_LL
    static_configs:
      - targets: null
    file_sd_configs:
      - files:
          - prod-targets.yml
          - prod-misc-targets.yml
          - preprod-targets.yml
          - dev1-targets.yml
          - dev2-targets.yml
          - lab2-targets.yml
          - lab3-targets.yml
          - lab1-targets.yml
    relabel_configs:
      - source_labels:
          - __address__
    (...)

przykład pojedynczego YML

- targets:
    - https://example0.example.com:8443/studio/
    - https://example1.example.com:8443/studio/
    - https://example2.example.com:8443/studio/
    - https://example3.example.com:8443/studio/
    - https://example4.example.com:8443/studio/
    - https://example5.example.com:8443/studio/
    - https://example.example.com/studio/
  labels:
    service: Studio
    env: Prod
    team: Nullmean

— Iwanow
źródło