Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

У NOC довольно большое количество настроек. Настройки могут браться из разных источников и переопределятся на многих уровнях. Начальное конфигурирование делается в Tower и определяет порядок чтения настроек. По умолчанию настройки читаются в таком порядке legacy:///,yaml:///opt/noc/etc/settings.yml,env:///NOC Строка настроек читается с лева на право, настройки определенный в следующем источнике переопределяют предыдущий источник. Источники могут повторятся с указанием разных префиксов или суффиксов. В целом разбор строки производится по стандарту URI

Немного подробнее про каждый вариант. 

Источники настроек

legacy://

Как правило имеет смысл оставить этот источник данных первым. настройки для него делает tower. Текущая башня не способна сформировать полный список параметров. Опционально можно указать какой файл будет читаться вместо стандартного /opt/noc/etc/noc.yml Скорее всего в этом не очень много смысла.

yaml://

Файл с настройками определенными в ручную. Механика скорее всего выглядит так

  • ./noc config dump > /opt/noc/etc/settings.ymlа далее ручное редактирование полученного файла. 

consul://

Для крупного кластера удобнее когда настройки хранятся централизованно. Consul как раз годится на эту роль. формат определения consul:///<ip1>:<port>/<path>?token=<token>

Рекомендуемый вариант consul://consul:8500/noc. 

В дальнейшем настройки читаются из consul при помощи 

% consul kv get -recurse noc/language
noc/language:ru
noc/language_code:ru
# consul kv put noc/language en 
Success! Data written to: noc/language
% consul kv get noc/language   
en



или через штатный web ui consul, который расположен на хосте с NOC-ом по адресу http://noc:8500/

env://

Переопределять настройки конкретного демона, например loglevel удобнее через переменные окружения. Сейчас используется для переопределения настроек в supervisord.

не исключено появление других вариантов хранилищ конфигурации. пример варианта реализации можно посмотреть в core/config/proto/yml_proto.py

Как посмотреть какая конфигурация в конечном счете будет использована сервисами NOC? 

  • убедиться что сервис запускается через supervisord. сервисы определены в etc/noc_services.yml там нужно посмотреть секцию Environment скорее всего там будет что то не отличимое от 

    environment = LD_PRELOAD="/usr/lib64/libjemalloc.so.1",NOC_USER="noc",NOC_NODE="noc",NOC_CONFIG="legacy:///,yaml:///opt/noc/etc/settings.yml,env:///NOC",NOC_ENV="NOC",NOC_LOGLEVEL="info",NOC_DC="DC",NOC_ROOT="/opt/noc"
  • Убедится что вы используете порядок чтения настроек идентичный порядку чтения у демона. для применения выполнить

    export NOC_CONFIG="legacy:///,yaml:///opt/noc/etc/settings.yml,env:///NOC"
  • запустить команду ./noc config dump 

Вывод команды будет дан в формате совпадающем с читаемым протоколом yml://. 

Формат yml довольно капризно относится к некоторым спецсимволам см. YAML. Для конфигурации это означает, что возможны сложности с паролями начинающимися со спецсимволов *,%,@, #

Сервисы

Данные о связных системах таких как postgresql, mongo и прочие добываются из consul. Существует два типа сервисов 

  • near – при резолве будет выбран ближайший сервис. под ближайшим понимается сервис пинг до которого меньше. чаще всего это означает локальный сервис. 
  • обычный – при резолве будет выбран первый попавшийся сервис. 

Есть исключение. Если в сервисе будет встречено двоеточие например так вот NOC_NSQD_ADDRESSES=192.168.1.1:4150 резолв происходить не будет. будет взят указанный сервис

  • No labels