Настройка Подсистемы

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

Конфигурационный файл

Расположение файлов конфигурации:

  • конфигурация по умолчанию – $WORKING_DIR/conf/defaults.ini;
  • пользовательская конфигурация – $WORKING_DIR/conf/custom.ini;
  • путь к файлу пользовательской конфигурации может быть переопределен с помощью параметра "--config".

Переменные среды

Можно использовать интерполяцию переменных среды во всех трех типах конфигурации настройки. Допустимый синтаксис – $ENV_VAR_NAME или ${ENV_VAR_NAME}, и его можно использовать только для значений, а не для ключей или более крупных частей конфигурации. Если в значении переменной среды есть "$" (например, Pa$sw0rd), используют синтаксис $ENV_VAR_NAME во избежание двойного расширения. Он недоступен в файлах определения панели мониторинга, только в конфигурации настройки панели мониторинга.

Пример:

datasources:
– name: Graphite
url: http://localhost:$PORT
user: $USER
secureJsonData:
password: $PASSWORD

Можно использовать "$$", если в значении есть литерал "$" и требуется избежать интерполяции.

Источники данных

Можно управлять источниками данных в Подсистеме, добавляя файлы конфигурации YAML в директорию provisioning/datasources. Каждый файл конфигурации может содержать список datasources, который необходимо добавить или обновить во время запуска. Если источник данных уже существует, Подсистема перенастраивает его в соответствии с предоставленным файлом конфигурации.

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

Можно настроить Подсистему на автоматическое удаление подготовленных источников данных при их удалении из файла настройки. Для этого нужно добавить "prune: true" в начало файла настройки источника данных. При такой настройке Подсистема также удаляет подготовленные источники данных при полном удалении файла подготовки.

Если запускается несколько экземпляров Подсистемы, следует добавить номер версии для каждого источника данных в конфигурации и увеличивать его при обновлении конфигурации. Подсистема обновляет только источники данных с номером версии, равным или меньшим, чем указано в конфигурации. Это предотвращает перезапись старых конфигураций более новыми, если есть разные версии файла datasource.yaml, в которых не указаны номера версий, а затем перезапускать экземпляры одновременно.

Данные в формате JSON

Не все источники данных имеют одинаковые параметры конфигурации. Чтобы задать другие параметры источника данных, их указывают в виде JSON-объекта в поле jsonData.

Общие настройки во встроенных источниках основных данных включают параметры из таблицы 5.

Примечание – Источники данных, помеченные HTTP*, взаимодействуют по протоколу HTTP, который включает все основные плагины источников данных, кроме MySQL, PostgreSQL и MSSQL.

Защищенные данные в формате JSON

Защищенные данные JSON – это карта настроек, зашифрованных с помощью секретного ключа из конфигурации Подсистемы. Шифрование скрывает содержимое от пользователей приложения. Этот параметр следует использовать для хранения сертификата TLS и пароля, которые Подсистема добавляет к запросу на стороне сервера. Все эти параметры необязательны (таблица 6).

Плагины

Можно управлять приложениями-плагинами в Подсистеме, добавив один или несколько файлов конфигурации YAML в каталог provisioning/plugins. Каждый файл конфигурации может содержать список apps. Подсистема обновляет каждое приложение в соответствии с файлом конфигурации.

Примечание – Эта функция позволяет настраивать конфигурации плагинов, а не сами плагины. Плагины должны быть уже установлены в экземпляре Подсистемы.

Панели мониторинга

Можно управлять панелями мониторинга в Подсистеме, добавив один или несколько файлов конфигурации YAML в каталог provisioning/dashboards. Каждый файл конфигурации может содержать список dashboards providers, которые загружают панели мониторинга в Подсистему из локальной файловой системы.

При запуске Подсистема обновляет и вставляет все панели мониторинга, доступные по заданному пути. Затем Подсистема опрашивает этот путь каждые updateIntervalSeconds, ищет обновленные файлы JSON, обновляет их и вставляет в базу данных.

Примечание – Панели мониторинга настраиваются на корневом уровне, если параметр folder отсутствует или пуст.

Хотя и можно изменить подготовленную панель мониторинга в пользовательском интерфейсе Подсистемы, эти изменения нельзя сохранить в источнике настройки. Если allowUiUpdates установлено на true и вносятся изменения в подготовленную панель мониторинга, можно сохранить панель мониторинга, после чего изменения сохранятся в базе данных Подсистемы.

Примечание – Если подготовленная панель мониторинга сохраняется в пользовательском интерфейсе, а затем обновляется из исходного источника, панель мониторинга, сохраненная в базе данных, всегда будет перезаписываться. Свойство version в файле JSON не повлияет на это, даже если оно ниже версии существующей панели мониторинга.

Если подготовленная панель мониторинга сохраняется в пользовательском интерфейсе, а источник удаляется, панель мониторинга, хранящаяся в базе данных, удаляется, если только для параметра конфигурации disableDeletion не установлено значение true.

Если allowUiUpdates настроено на false, нельзя вносить изменения в подготовленную панель мониторинга. При нажатии Save в Подсистеме появляется диалоговое окно "Не удается сохранить подготовленную панель мониторинга". На рисунке 6 показано это поведение.

Подсистема предлагает несколько вариантов экспорта определения панели мониторинга в формате JSON. Оба варианта "Copy JSON to Clipboard" или "Save JSON to file" помогут синхронизировать изменения панели мониторинга с источником данных.

Примечание – В определении JSON в поле ввода при использовании "Copy JSON to Clipboard" или "Save JSON to file" поле id автоматически удаляется для упрощения процесса подготовки.

Рисунок 6 — Диалоговое окно с оповещением

Если панель мониторинга в файле JSON содержит UID, Подсистема принудительно вставляет/обновляет этот UID. Это позволяет переносить панели мониторинга между экземплярами Подсистемы и подготавливать их из конфигурации, не нарушая указанные URL-адреса, поскольку новый URL-адрес панели мониторинга использует UID в качестве идентификатора. При запуске Подсистемы обновляются и вставляются все панели мониторинга, доступные в настроенных папках. При изменении файла панель мониторинга также обновляется. По умолчанию Подсистема удаляет панели мониторинга в базе данных при удалении файла. Можно отключить это поведение с помощью параметра disableDeletion.

Примечание – Подготовка позволяет перезаписывать существующие панели мониторинга, что приводит к проблемам при повторном использовании настроек, которые должны быть уникальными. Следует быть осторожными, и не использовать один и тот же заголовок несколько раз в папке или uid в рамках одной установки, поскольку это приводит к непредсказуемому поведению.

Если панели мониторинга хранятся с использованием папок в репозитории git или в файловой системе, а также требуется иметь те же имена папок в меню Подсистемы, можно использовать опцию foldersFromFilesStructure.

Оповещения

В таблицах 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28-29 подробно описаны поддерживаемые настройки и безопасные настройки для каждого типа уведомлений. Безопасные настройки хранятся в зашифрованном виде в базе данных, и добавляются в secure_settings в файле YAML вместо settings.