Cel mai bun mod de a crea fișiere yaml care au un număr variabil de secțiuni bazate pe gazdă

Încerc să folosesc ansible pentru a implementa fișiere de configurare pe sute de mașini în care diferite mașini vor avea mai multe iterații ale fragmentelor de configurare specifice. În mod specific, folosesc analizatorul de jurnal promtail și diferite mașini vor avea locații diferite ale fișierelor de jurnal pentru a le analiza cu etichete diferite. În mod ideal, vreau să păstrez configurația ansible destul de simplu, astfel încât să pot folosi cererile de extragere pentru a face modificări diferitelor secțiuni.

Inițial, urma să folosesc group_vars și să definesc fiecare locație a fișierului jurnal în group_var. Ceea ce funcționează bine atâta timp cât construiesc doar o singură locație de jurnal. Odată ce am nevoie de mai multe locații de jurnal, se întrerupe deoarece voi avea o singură valoare returnată de la group_vars.

Pentru a ilustra.

gazde:
    
    LOGFILE1:
      gazde:
        aplicație[15:16].qa2.example.com
    LOGFILE2:
      gazde
        aplicație[16:17].qa2.example.com



GROUP_VARS/LOGFILE1
GROUP_VARS/LOGFILE2

Aș putea să caut să iterez prin fiecare grup și apoi să atașez rezultatul la fișierul de configurare, dar nu văd o modalitate de a face asta cu funcția șablon. În mod ideal, aș putea să repet prin toate locațiile fișierelor jurnal, dar nu sunt sigur cum să fac asta.

Sau poate aș putea folosi un fișier variabil extern și apoi să folosesc un anumit fel de condițional pentru a determina care gazde primesc ce configurație?

Aceleași date în grupul_vars...

fișier: /opt/tomcat/fxcts/logs/gxxss.log
comp: TX_Tomcat
aplicație: TX
modul: GXX
pipeline_regex: Nici unul 
pipeline_vars:
  - Nici unul
drop_expression: Niciuna
Multilinie: niciuna

Iată șablonul jinja

scrape_configs:
- job_name: {{ module }}
    pipeline_stages:
        - regex:
            expresie: {{ pipeline_regex }}
        - etichete:
            {% pentru etichete în pipeline_vars -%}
            {{ etichete }}:
            {% endfor %}
{#  Acesta este un test #}
        - timestamp-ul:
            sursa: data
            format: 2006-01-01 15:00:00.000000
        - cădere brusca:
            expresie: {{ drop_expression }}
        - multilinie:
            prima linie: ""
            max_wait_time: 3s
            static_configs:
    static_configs:
    - tinte:
        - gazdă locală
      etichete:
        aplicație: {{ aplicație }}
        gazdă: {{ ansible_hostname }}
        componentă: {{ comp }}
        __path__: {{ fișier }}

Iată o mostră de configurație reală yaml. După cum am spus, diferitele locații ale jurnalului pot varia în funcție de gazdă.

Server:
  http_listen_port: 9080
  grpc_listen_port: 0
pozitii:
  nume de fișier: /tmp/positions.yaml
clienti:
  - url: http://host:3100/loki/api/v1/push
scrape_configs:
- job_name: system
  static_configs:
  - tinte:
      - gazdă locală
    etichete:
      job: varlogs
      gazdă: ${HOSTNAME}
      __cale__: /var/log/*log
- job_name: apps_ssi
  static_configs:
  -tinte:
      - gazdă locală
    etichete:
      job: ssi
      gazdă: ${HOSTNAME}
      __path__: /opt/tomcat/ssi/logs/*log
- job_name: apps_fxcts
  static_configs:
  - tinte:
      - gazdă locală
    etichete:
      job: fxcts
      gazdă: ${HOSTNAME}
      __path__: /opt/tomcat/fxcts/logs/*log
- job_name: journal
  jurnal:
    json: fals
    varsta maxima: 12 ore
    etichete:
      job: systemd-journal
      gazdă: ${HOSTNAME}
  relabel_configs:
    - etichete_sursă: ['__journal__systemd_unit']
      target_label: „unitate”

Îmi pare rău, dar este prea mult de citit și de înțeles complet, dar în esență înțeleg că trebuie să împingeți configurații diferite către diferite gazde pe baza unor locații ale fișierelor jurnal pentru a le analiza.

Soluția mea la asta - să le prind pe toate - ar fi să parcurg toate căile pe care trebuie să le monitorizez parser de jurnal promtail și ajustați configurația în consecință:

---
- nume: „playbook pentru a adăuga anumite fișiere de configurare”
  gazde: localhost


  sarcini:
  
  - nume: bloc pentru fișierele de configurare a analizatorului de jurnal promtail
    bloc:
      - nume: Verificați dacă există calea jurnalului
        stat:
          cale: „{{ item.path }}”
        înregistrare: reg_path
      - nume: Push fișierul de conf dacă există calea
        șablon:
          src: „{{ item.templ }}”
          dest: „/etc/promtal/whatever.d/”
        când: reg_path.stat.exists
    buclă:
      - { nume: „syslog”, calea: „/var/log/syslog”, templ: „syslog.cong.j2”}
      - { nume: „mesaje”, calea: „/var/log/messages”, templ: „messages.cong.j2”}
      - { nume: 'apache-acl', cale: '/var/log/httpd/access.log', templ: 'apache-acl.cong.j2'}

Acest cod YAML nu este testat și configurația promtail poate trebui să fie manipulată diferit, dar sper să înțelegeți punctul meu de vedere.

Din nou, nu sunt sigur că urmez exact, dar dacă răspunsul lui Roman nu funcționează, atunci aș sugera să utilizați vars gazdă într-o structură de foldere din inventarul dvs. și pur și simplu creând o variabilă cu o hartă a căii/etichetelor. Apoi puteți parcurge acea variabilă în șablonul jinja.

Dacă există atât de multe variații de căi și gazde încât acest lucru este imposibil, având în vedere numărul de mașini, atunci vă sugerez să vă uitați fie să încercați să standardizați locații/etichete, fie să utilizați un alt instrument decât promtail, care este capabil să gestioneze fișierele lipsă. În acest fel, puteți gestiona doar o listă mare de jurnale de răzuit și să nu vă faceți griji cu privire la schimbarea nimicului.

Ultima opțiune pe care o pot sugera este să inversați abordarea: găsiți un instrument care vă permite să utilizați un folder pentru configurare și să introduceți fișiere pentru fiecare instrument care necesită monitorizare. Ce vreau să spun prin asta este că ai avea un folder /etc/logscraper/conf.d care este inclus în config. Apoi fiecare instrument ar crea un fișier în interiorul acestuia, de ex. /etc/logscraper/conf.d/10-tool.conf, și ar defini modul de analizare a jurnalelor. În acest fel, puteți implementa asta cu instrumentul în sine, nu cu instrumentul de înregistrare. Acest lucru are avantajul suplimentar de a păstra configurația legată de un produs/instrument (de exemplu, apache) în manualul de joc care implementează produsul.