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

У 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 резолв происходить не будет. будет взят указанный сервис

Сервисы ускорения (pgbouncer, memcached)

С некоторого количества оборудования встает проблема производительности и масштабируемости. Pgbouncer призван решать вопрос с колвом коннектов к postgres. по умолчанию кол-во коннектов к postgres 302 этого достаточно примерно на 250-500 устройств. Дальше колво коннектов придется расширять и после 5000 потребление памяти postgres станет неприлично большим. Pgbouncer позволяет снизить колво реальных коннектов к Postgres, мультиплексируя их на себе.

Memcached хранит данные целиком в памяти и решает проблему с откликом из postgres и mongo. Проблема начинает быть заметной примерно на 50 000 устройств.

Что бы использовать pgbouncer и memcached надо явно указать их использование. Для этого где-то в цепочке конфигурации надо задать два параметра.

pg:
  addresses: "pgbouncer"
cache:
  cache_class: "noc.core.cache.memcached.MemcachedCache"

По умолчанию параметры выглядят так 

pg:
  addresses: "postgres"
cache:
  cache_class: "noc.core.cache.mongo.MongoCache"

То есть для postgres обращение будет происходить напрямую в postgres, а вместо memcached будет использован cache в mongodb. 

Memcached, хотя быстрее кеширования в mongo не предоставляет отказоустойчивой конфигурации.

Proxy

Для некоторый сервисов например tgsender бывает нужно задать прокси сервер. Сделать это можно через тот же settings.yml

proxy:
  http_proxy: http://192.168.1.1:3128 
  https_proxy: http://192.168.1.1:3128
  ftp_proxy: http://192.168.1.1:3128

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


  • No labels