Comment diviser les fichiers de configuration de Prometheus?

10

En ce moment, nous utilisons Prometheus pour notre surveillance et nous avons beaucoup de configuration (notre fichier de configuration principal prometheus.yml fait plus de 1400 lignes).

Je voudrais diviser cela en groupes logiques (peut-être DEV / TEST / PROD?) Mais je n'arrive pas à trouver de documentation sur la façon d'utiliser "comprend" (ou similaire) dans la syntaxe du fichier de configuration Prometheus.

Quelqu'un a-t-il fait cela avec son fichier de configuration Prometheus? Si oui, comment avez-vous fait?

configuration configuration-management prometheus

— srkiNZ84
source

Qu'en est-il d'un script réunissant plusieurs fichiers en un seul?

— gf_

Ouais, je pense que c'est ce que je vais devoir faire. Mais au mieux, c'est une "solution de contournement". Je voulais pouvoir créer un petit fichier de configuration, en définissant un "nom_travail" pour tester la configuration ("développement" des configurations de scraping je suppose), puis appeler simplement "recharger" pour l'essayer.

— srkiNZ84

8

Le fichier de configuration Prometheus (et les autres fichiers de configuration de l'écosystème) ne prennent explicitement en charge aucune forme de modèle. Au lieu de cela, cela est laissé à votre système de gestion de configuration à gérer.

De plus, il semble un peu inhabituel que vous ayez des sections dev / test / prod dans votre fichier de configuration. Généralement a) vous auriez un Prometheus par environnement et b) la principale différence entre ces serveurs Prometheus serait une valeur différente pour l' envétiquette dans votre external_labels.

— brian-brésil
source

Cela ne viole-t-il pas l'idée de "vitre unique"? Comment serions-nous prêts à comparer les mesures DEV à PROD si nous avions des instances distinctes par environnement? Devrions-nous utiliser Prometheus fédéré pour ce cas d'utilisation?

— srkiNZ84

Le cas d'utilisation est que nous avons des clusters Kubernetes DEV / TEST / PROD séparés. Pour chaque cluster, nous utilisons la "découverte de service" pour obtenir toutes les métriques des objets Service et Pod (conteneur).

— srkiNZ84

1

Prometheus n'a pas une seule idée de vitre, qui ne s'adapte pas bien à quoi que ce soit au-delà du plus petit des systèmes. Même les métriques de Prometheus lui-même sont trop grandes pour une seule vitre, elles ressemblent plus à 4-5. L'approche habituelle serait d'utiliser des modèles de source de données dans Grafana, et vous pouvez comparer les tableaux de bord côte à côte.

— brian-brazil

0

Vous pouvez décharger vos cibles vers des fichiers différents ou utiliser un outil de découverte de service comme 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__
    (...)

exemple d'un YML individuel

- 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

— Ivanov
source