Лучший способ создать файлы yaml, которые имеют разделы с переменным номером в зависимости от хоста.

Я пытаюсь использовать ansible для развертывания файлов конфигурации на сотнях машин, на которых разные машины будут иметь несколько итераций определенных фрагментов конфигурации. В частности, я использую анализатор журнала promtail, и разные машины будут иметь разные местоположения файлов журнала для анализа с разными метками. В идеале я хочу, чтобы конфигурация ansible была довольно простой, чтобы я мог просто использовать запросы на вытягивание для внесения изменений в различные разделы.

Первоначально я собирался использовать group_vars и определить местоположение каждого файла журнала в group_var. Что отлично работает, пока я создаю только одно местоположение журнала. Как только мне нужно несколько местоположений журнала, он ломается, так как у меня будет только одно значение, возвращаемое из group_vars.

Проиллюстрировать.

хосты:
    
    LOGFILE1:
      хосты:
        приложение[15:16].qa2.example.com
    LOGFILE2:
      хозяева
        приложение[16:17].qa2.example.com



GROUP_VARS/LOGFILE1
GROUP_VARS/LOGFILE2

Я мог бы просто просмотреть каждую группу, а затем добавить вывод в файл конфигурации, но я не вижу способа сделать это с помощью функции шаблона. В идеале я мог бы просто перебрать все местоположения файла журнала, но я не уверен, как это сделать.

Или, может быть, я мог бы использовать внешний файл переменных, а затем использовать какое-то условие, чтобы определить, какие хосты получают какую конфигурацию?

Те же данные в group_vars...

файл: /opt/tomcat/fxcts/logs/gxxss.log
Комп: TX_Tomcat
приложение: Техас
модуль: GXX
pipe_regex: нет 
pipe_vars:
  - Никто
drop_expression: Нет
Многострочный: Нет

Вот шаблон джиндзя

scrape_configs:
- job_name: {{ модуль }}
    конвейер_этапы:
        - регулярное выражение:
            выражение: {{ pipe_regex }}
        - этикетки:
            {% для меток в pipe_vars -%}
            {{ метки }}:
            {% конец для %}
{#  Это тест #}
        - метка времени:
            источник: дата
            формат: 2006-01-01 15:00:00.000000
        - уронить:
            выражение: {{ drop_expression }}
        - многострочный:
            первая строка: ""
            max_wait_time: 3 с
            статические_конфигурации:
    статические_конфигурации:
    - цели:
        - локальный хост
      этикетки:
        приложение: {{приложение}}
        хост: {{ ansible_hostname }}
        компонент: {{комп.}}
        __path__: {{ файл }}

Вот пример реальной конфигурации yaml. Как я уже сказал, разные местоположения журналов могут различаться в зависимости от хоста.

сервер:
  http_listen_port: 9080
  grpc_listen_port: 0
позиции:
  имя файла: /tmp/positions.yaml
клиенты:
  - URL-адрес: http://хост:3100/loki/api/v1/push
scrape_configs:
- job_name: система
  статические_конфигурации:
  - цели:
      - локальный хост
    этикетки:
      работа: варлоги
      хост: ${HOSTNAME}
      __path__: /var/журнал/*журнал
- job_name: apps_ssi
  статические_конфигурации:
  - цели:
      - локальный хост
    этикетки:
      работа: сси
      хост: ${HOSTNAME}
      __path__: /opt/tomcat/ssi/logs/*log
- job_name: apps_fxcts
  статические_конфигурации:
  - цели:
      - локальный хост
    этикетки:
      работа: fxcts
      хост: ${HOSTNAME}
      __path__: /opt/tomcat/fxcts/logs/*log
- job_name: журнал
  журнал:
    json: ложь
    макс_возраст: 12 часов
    этикетки:
      работа: systemd-журнал
      хост: ${HOSTNAME}
  relabel_configs:
    - source_labels: ['__journal__systemd_unit']
      target_label: 'единица измерения'

Опять же, не уверен, что точно следую, но если ответ Романа не работает, я бы предложил использовать переменные хоста в структуре папок в вашем инвентаре и просто создав переменную с картой путей/меток. Затем вы можете перебрать эту переменную в своем шаблоне jinja.

Если существует так много вариантов путей и хостов, что это невозможно, учитывая количество машин, то я предлагаю вам либо попытаться стандартизировать местоположения/метки, либо использовать инструмент, отличный от promtail, способный обрабатывать отсутствующие файлы. Таким образом, вы можете просто управлять одним большим списком журналов для очистки и не беспокоиться об изменении чего-либо.

Последний вариант, который я могу предложить, — это обратный подход: найдите инструмент, который позволяет вам использовать папку для настройки, и добавляйте файлы для каждого инструмента, который нуждается в мониторинге. Я имею в виду, что у вас будет папка /etc/logscraper/conf.d который входит в конфиг. Затем каждый инструмент будет создавать файл внутри этого, например. /etc/logscraper/conf.d/10-tool.conf, и он будет определять, как анализировать журналы. Таким образом, вы можете развернуть это с помощью самого инструмента, а не инструмента ведения журнала. Это дает дополнительное преимущество, заключающееся в том, что конфигурация, связанная с продуктом/инструментом (например, apache), сохраняется в плейбуке, который развертывает продукт.

Извините, но это слишком много, чтобы прочитать и полностью понять, но по сути я понимаю, что вам нужно отправить разные конфигурации на разные хосты на основе некоторых местоположений файла журнала для анализа.

Мое решение для этого - поймать их всех - состояло бы в том, чтобы перебрать все пути, которые вам нужно отслеживать, через парсер журналов promtail и соответствующим образом настроить конфигурацию:

---
- name: "playbook для добавления определенных файлов конфигурации"
  хосты: локальный


  задачи:
  
  - имя: Блок для конфигурационных файлов парсера журналов promtail
    блокировать:
      - имя: проверить, существует ли путь к журналу
        стат:
          путь: "{{ item.path }}"
        регистр: reg_path
      - имя: отправить файл конфигурации, если путь существует
        шаблон:
          источник: "{{item.templ}}"
          место назначения: "/etc/promtal/независимо.d/"
        когда: reg_path.stat.exists
    петля:
      - {имя: 'syslog', путь: '/var/log/syslog', шаблон: 'syslog.cong.j2'}
      - {имя: 'сообщения', путь: '/var/log/messages', шаблон: 'messages.cong.j2'}
      - {имя: 'apache-acl', путь: '/var/log/httpd/access.log', templ: 'apache-acl.cong.j2'}

Этот код YAML не тестировался, и с конфигурацией promtail, возможно, придется манипулировать по-другому, но, надеюсь, вы поняли мою точку зрения.