2.16. Конфигурация системы (config.yml)¶
config.yml
– основной файл конфигурации системы, в котором задана логика и
порядок обработки входящих запросов, а также настройки кластерных ролей
и других функций системы.
Файл загружается в систему при первоначальной конфигурации после установки системы и настройки кластера.
Рассмотрим структуру файла и логику настроек на примере. В примере в качестве справочной информации приведены все возможные настройки. В реальной ситуации в конфигурации задаются только те настройки, которые необходимы для решения текущих бизнес-задач.
---
types: {__file: model.avsc}
functions:
focus_decode: {__file: focus_decode.lua}
focus_routing: {__file: focus_routing.lua}
validate_coupon_payment: {__file: validate_coupon_payment.lua}
focus_classifier: {__file: focus_classifier.lua}
notification: {__file: notification.lua}
single_task: {__file: single_task.lua}
long_task: {__file: long_task.lua}
pipelines:
connect_input_handle:
- focus_routing
coupon_payment_handle:
- focus_decode
- validate_coupon_payment
focus_classifiers:
- focus_classifier
notification_filter:
- notification
single_task:
- single_task
long_task:
- long_task
connector:
input:
- name: soap
type: soap
wsdl: {__file: Connect.wsdl}
success_response_body: {__file: success_response_body.xml}
error_response_body: {__file: error_response_body.xml}
handlers:
- function: Connect
pipeline: connect_input_handle
- name: http
type: http
pipeline: connect_input_handle
- name: kafka
type: kafka
brokers:
- localhost:9092
topics:
- orders
- items
group_id: kafka
token_name: kafka_token
pipeline: connect_input_handle
output:
- name: to_input_processor
type: input_processor
- name: to_external_http_service
type: http
url: http://localhost:8021/test_json_endpoint
format: json
- name: to_external_soap_service
type: soap
url: http://localhost:8020/test_soap_endpoint
- name: to_kafka
type: kafka
brokers:
- localhost:9092
topic: objects
- name: to_smtp
type: smtp
url: localhost:2525
from: tdg@localhost
subject: TDG_Objects
timeout: 5
ssl_cert: ssl.crt
ssl_key: ssl.pem
- name: dummy
type: dummy
routing:
- key: input_processor
output: to_input_processor
- key: external_http_service
output: to_external_http_service
- key: external_soap_service
output: to_external_soap_service
- key: dummy
output: dummy
input_processor:
classifiers:
- name: focus
pipeline: focus_classifiers
routing:
- key: focus_couponpayment
pipeline: coupon_payment_handle
- key: focus_initiation
pipeline: focus_catchall_handle
- key: focus_ratechange
pipeline: focus_catchall_handle
storage:
- key: focus_couponpayment
type: CouponPayment
output_processor:
focus_couponpayment:
pipeline: notification_filter
output: to_external_http_service
unclassified:
pipeline: notification_filter
output: to_external_http_service
repair_queue:
on_object_added:
__unclassified__:
postprocess_with_routing_key: unclassified
logger:
rotate_log: true
max_msg_in_log: 500000
max_log_size: 10485760
delete_by_n_msg: 1000
audit_log:
enabled: true
severity: INFO
remove_older_than_n_hours: 12
tasks:
task_1:
kind: single_shot
pipeline: single_task
keep: 5
task_2:
kind: continuous
pipeline: long_task
pause_sec: 10
task_3:
kind: periodical
pipeline: long_task
schedule: "0 */5 * * * *"
task_runner:
running_count_threshold: 100
jobs:
max_jobs_in_parallel: 100
account_manager:
only_one_time_passwords: true
output:
name: to_smtp
options:
subject: "Registration"
password_change_timeout_seconds: 10
block_after_n_failed_attempts: 5
ban_inactive_more_seconds: 86400
password_policy:
min_length: 8
include:
lower: true
upper: true
digits: true
symbols: false
pepper: 2d60ec7f-e9f0-4018-b354-c54907b9423d
auth_external: {__file: auth.lua}
notifier:
mail_server:
url: 127.0.0.1:2525
from: TDG_repair_queue
username: user
password: passpass
timeout: 5
skip_verify_host: true
users:
- id: 1
name: Petrov
addr: petrov@mailserver.com
services:
get_price:
doc: "Get the item price by ID"
function: get_price_by_id
return_type: ItemPrice
args:
item_id: string
expiration:
- type: CouponPayment
lifetime_hours: 12
delay_sec: 1800
keep_version_count: 5
archivation:
- type: Quotation
lifetime_days: 7
schedule: "0 0 0 */1 * *"
dir: "/var/data"
file_size_threshold: 104857600
hard-limits:
scanned: 2000
returned: 100
force_yield_limits: 1000
graphql_query_chache_size: 1000
vshard_timeout: 2
maintenance:
clock_delta_threshold_sec: 5
gc:
forced: true
period_sec: 2
steps: 20
tracing:
base_url: localhost:9411/api/v2/spans
api_method: POST
report_interval: 0
spans_limit: 100
sequence_generator:
starts_with: 1
range_width: 100
frontend:
- name: myapp
files:
"index.html":
__file: app/index.html
test-soap-data: {__file: test_object.json}
libraries:
cache:
__file: cached.lua
utils:
__file: utils.lua
welcome-message: |
Hello! Let's start working with Tarantool Data Grid.
2.16.1. Секции¶
В файле конфигурации могут быть настроены следующие секции:
- types – описание модели данных.
- functions – описание функций.
- pipelines – описание конвейеров обработки объектов.
- connector – конфигурация роли
connector
. - input_processor – конфигурация роли
input_processor
. - output_processor – конфигурация роли
output_processor
. - repair_queue – настройки обработки объекта при попадании в ремонтную очередь.
- logger – настройки роли
logger
. - audit_log – настройки журнала аудита.
- tasks – конфигурация задач, выполняемых
при помощи ролей
scheduler
иtask_runner
. - task_runner – дополнительные настройки роли
task_runner
. - jobs – настройки выполнения отложенных работ (jobs).
- account_manager – настройки роли
account_manager
. - pepper – настройка, связанная с безопасностью паролей.
- auth_external – настройки внешней авторизации.
- notifier – настройки роли
notifier
. - services – конфигурация сервисов.
- expiration – настройки времени жизни объектов и ограничения количества версий объектов.
- archivation – настройки архивации объектов.
- hard-limits – настройки ограничений для GraphQL-запросов.
- force_yield_limits – ограничение на количество сканирований записей.
- graphql_query_chache_size – размер кэша запросов GraphQL.
- vshard_timeout – время ожидания запроса в
модуле
vshard
. - maintenance – настройки, связанные с обслуживанием и диагностикой.
- gc – настройки роли
garbage_collector
. - tracing – настройки роли
tracing
. - sequence_generator – настройки роли
sequence_generator
. - frontend – конфигурация роли
frontend
. - test-soap-data – текст запроса по умолчанию на вкладке Test.
- libraries – настройки подключения сторонних библиотек.
- welcome-message – текст приветственного сообщения.
2.16.1.1. types¶
Описание модели данных (типов объектов), которые будут сохраняться
в системе. В качестве языка описания модели используется Avro Schema
– см.
подробнее раздел «Разработка доменной модели».
Как правило,
описание делается в отдельном файле с расширением .avsc
, на который
делается ссылка в этой секции. Например:
types: {__file: model.avsc}
2.16.1.2. functions¶
Описание функций, которые будут выполняться в конвейерах обработки объектов (секция pipelines). Для каждой функции указывается имя функции и исполняемая часть – Lua-код функции, который также обычно выносится в отдельный файл. Например:
functions:
focus_routing: {__file: focus_routing.lua}
2.16.1.3. pipelines¶
Описание конвейеров обработки объектов (пайплайнов). Для каждого пайплайна указывается имя и входящие в него функции, заданные в секции functions. Например:
pipelines:
connect_input_handle:
- focus_routing
2.16.1.4. connector¶
Для кластерной роли connector
настраиваются:
input
Параметры коннекторов для получения и первоначальной обработки (parsing) входящих запросов. Ряд параметров есть у всех типов коннекторов:
name
– имя коннектора (произвольное).type
– тип коннектора. Поддерживаемые типы:http
– для запросов в формате JSON по HTTP;soap
– для запросов в формате XML (SOAP) по HTTP;kafka
– для интеграции с шиной данных Apache Kafka.
pipeline
– конвейер обработки входящих объектов, определенный в секции pipelines.
Помимо этих параметров, у некоторых типов коннекторов есть параметры, специфические только для них.
type: soap
wsdl
– схема WSDL, описывающая структуру входящего XML;success_response_body
– шаблон ответа в случае успешной обработки запроса;error_response_body
– шаблон ответа в случае ошибки;handlers
– обработчики входящего запроса.
Примечание
Шаблоны ответа опциональны (параметры success_response_body
и
error_response_body
).
Пользователь может задать шаблоны в нужном ему формате,
соответствующем системе, в которую отправляется ответ; сам TDG
ограничений на формат не накладывает. В шаблоне error_response_body
возможно использовать один спецификатор форматирования %s
,
чтобы передать в тело ответа текст ошибки.
Например:
connector:
input:
- name: soap
type: soap
wsdl: {__file: Connect.wsdl}
success_response_body: {__file: success_response_body.xml}
error_response_body: {__file: error_response_body.xml}
handlers:
- function: Connect
pipeline: connect_input_handle
type: kafka
brokers
– адреса (URL) брокеров сообщений;topics
– темы сообщений;group_id
– идентификатор группы подписчиков;token_name
– имя токена приложения. Необходимо вначале сгенерировать токен в системе (см. описание процедуры) и далее указать имя токена (name
) в качестве значения параметра. Токен будет использоваться для авторизации при обработке входящих сообщений, которые коннектор забирает из шины данных Apache Kafka. Поскольку формат сообщений шины не дает возможности передать токен в самом сообщении, токен указывается в конфигурации коннектора;options
– для передачи опций в librdkafka.
Например:
connector:
input:
- name: kafka
type: kafka
brokers:
- localhost:9092
topics:
- orders
- items
group_id: kafka
token_name: kafka_token
pipeline: connect_input_handle
output
Параметры коннекторов для отправки исходящих запросов. Ряд параметров есть у всех типов коннекторов:
name
– имя коннектора (произвольное).type
– тип коннектора. Поддерживаемые типы:input_processor
– для отправки объекта на рольinput_processor
;http
– для отправки объекта в формате JSON во внешнюю систему по HTTP;soap
– для отправки объекта в формате XML (SOAP) во внешнюю систему по HTTP;kafka
– для интеграции с шиной данных Apache Kafka;smtp
– для отправки запросов через SMTP-сервер;dummy
– для игнорирования объектов (пришедший объект никуда не отправляется).
Помимо этих параметров, у некоторых типов коннекторов есть параметры, специфические только для них.
type: http
url
– URL внешней системы, куда отправляется объект;format
– формат, в котором оправляется объект. Для коннектора типаhttp
формат – JSON.
Например:
connector:
output:
- name: to_external_http_service
type: http
url: http://localhost:8021/test_json_endpoint
format: json
type: soap
url
– URL внешней системы, куда отправляется объект.
Например:
connector:
output:
- name: to_external_soap_service
type: soap
url: http://localhost:8020/test_soap_endpoint
type: kafka
brokers
– адреса (URL) брокеров сообщений;topic
– тема сообщения;options
– для передачи опций в librdkafka.
Например:
connector:
output:
- name: to_kafka
type: kafka
brokers:
- localhost:9092
topic: objects
type: smtp
url
– URL сервера SMTP;from
– имя отправителя, которое будет показываться в поле «From» при получении сообщения;subject
– тема отправляемого сообщения;timeout
– тайм-аут запроса к серверу SMTP, секунды;ssl_cert
– путь к SSL-сертификату;ssl_key
– путь к приватному ключу для SSL-сертификата.
Например:
connector:
output:
- name: to_smtp
type: smtp
url: localhost:2525
from: tdg@localhost
subject: TDG_Objects
timeout: 5
ssl_cert: ssl.crt
ssl_key: ssl.pem
routing
Mаршрутизация объекта для отправки через определенный
output, который
определяется в зависимости от ключа маршрутизации key
. Ключ маршрутизации
объект получает в результате обработки в пайплайне, указанном в
input. Если в input пайплайн не указан, объект
обрабатывается пайплайном по умолчанию, которые превращает объект вида
{
"obj_type": { "field_1": 1 }
}
в объект
{
"field_1": 1
}
и задает значение ключа маршрутизации как routing_key = obj_type
.
Пример конфигурации:
connector:
routing:
- key: input_processor
output: to_input_processor
- key: external_http_service
output: to_external_http_service
- key: external_soap_service
output: to_external_soap_service
2.16.1.5. input_processor¶
Для кластерной роли input_processor
настраиваются:
classifiers
Определение пользовательского пайплайна, выполняющего
классификацию объектов. В результате классификации объекту
присваивается нужный ключ маршрутизации, по которому определяются дальнейшие
действия по его обработке. Если пайплайн не задан, объект никак не
обрабатывается и направляется на обработку пайплайном, указанным в секции
input_processor: routing
.
routing
Маршрутизация объекта в определенный пайплайн обработки по ключу
маршрутизации (параметр key
).
storage
Настройки сохранения объекта в роли storage
по ключу
маршрутизации (параметр key
). Параметр type
определяет тип
бизнес-объекта (агрегата).
Пример маршрута (порядка обработки) объекта
Рассмотрим порядок обработки объекта на примере конфигурации выше.
1. После попадания в систему на роль connector
, объект будет обработан в
соответствии с настройками конфигурации input в секции connector.
В нашем примере мы видим, что для всех возможных вариантов input (JSON via
HHTP, XML via SOAP, Kafka) конвейер обработки указан один и тот же:
pipeline: connect_input_handle
.
2. В секции pipelines находим этот конвейер – он состоит из выполнения одной функции.
pipelines:
connect_input_handle:
- focus_routing
3. В секции functions мы видим, что исполняемый код
этой функции находится в файле focus_routing.lua
.
functions:
...
focus_routing: {__file: focus_routing.lua}
Листинг кода:
local first = ...
local ret = {obj = first, priority = 1, routing_key = 'input_processor'}
return ret
Необработанный объект должен быть помещен в поле obj
. Объекту будет присвоен
ключ маршрутизации «input_processor».
4. Дальнейший маршрут объекта определяется настройками routing в секции
connector. Для объектов с ключом маршрутизации
«input_processor» это будет output: to_input_processor
:
connector:
routing:
- key: input_processor
output: to_input_processor
- В секции connector находим данный output:
connector:
output:
- name: to_input_processor
type: input_processor
Значение параметра type
означает, что объект будет направлен на инстанс
с ролью input_processor
.
6. При попадании на роль input_processor
объект прежде всего будет
обрабатываться в соответствии с настройками из секции ниже:
input_processor:
classifiers:
- name: focus
pipeline: focus_classifiers
В указанном здесь пайплайне будет выполняться следующий код из
focus_classifier.lua
:
local param = ...
local type_table =
{
["Initiation"] = "focus_initiation",
["Coupon Payment"] = "focus_couponpayment",
["Exercise"] = "focus_exercise",
["Rate Change"] = "focus_ratechange"
}
local node = lom.get_by_path(param.obj, 'message.header.routedata.event_type')
if node == nil then
return param.obj
end
local event_type = string.strip(node[1])
param.routing_key = type_table[event_type]
return param
где lom.get_by_path
– функция, которая берет значение из объекта по
указанному пути. При этом путь записывается с разделением при помощи точки.
Допустим, что после обработки на данном этапе наш объект получит ключ маршрутизации «focus_couponpayment».
7. Дальнейшая обработка объекта с таким ключом маршрутизации будет определяться следующими настройками в секции input_processor:
input_processor:
routing:
- key: focus_couponpayment
pipeline: coupon_payment_handle
storage:
- key: focus_couponpayment
type: CouponPayment
Это означает, что сначала объект будет обработан в еще одном пайплайне –
coupon_payment_handle
, а потом направлен на роль storage
как объект типа
«CouponPayment». Данный тип должен быть описан в модели данных, которая
определена в секции
types: {__file: model.avsc}
После успешной валидации по модели данных, объект будет сохранен на роли
storage
.
8. Если для данного ключа маршрутизации указаны еще какие-либо настройки в
других секциях config.yml
, объекты с этим ключом будут обработаны далее
(см. пример про секцию output_processor).
2.16.1.6. output_processor¶
Задается логика обработки объектов, которые будут реплицироваться во внешние
системы. Выполняется после успешного сохранения в объектов на инстансах с ролью
storage
.
Для объектов с определенным ключом маршрутизации определяется:
- каким пайплайном будет обработан объект;
- посредством какого
output
он будет отправляться во внешнюю систему.
В рассматриваемом примере:
output_processor:
focus_couponpayment:
pipeline: notification_filter
output: to_external_http_service
Данные настройки означают, что объекты, которые на более ранних этапах
обработки получили ключ маршрутизации «focus_couponpayment», будут вначале
обработаны функциями из пайплайна notification_filter
, а затем отосланы в
соответствии с настройками указанного здесь output (смотрим эти настройки
в секции connector):
connector:
output:
- name: to_external_http_service
type: http
url: http://localhost:8021/test_json_endpoint
format: json
Аналогично определяется поведение роли output_processor
в отношение объектов с
другими ключами маршрутизации.
2.16.1.7. repair_queue¶
repair_queue:
on_object_added:
__unclassified__:
postprocess_with_routing_key: unclassified
В данном примере настроен случай, когда определенные объекты, попавшие в ремонтную очередь, также должны быть реплицированы во внешнюю систему. В данном случае ранее на этапе классификации объект не удалось классифицировать, и ему было присвоено специальное значение ключа «__unclassified__», которым определяются неклассифицированные объекты.
При попадании такого объекта в ремонтную очередь, согласно настройкам
postprocess_with_routing_key: unclassified
, объекту присваивается другой ключ
маршрутизации «unclassified», и с этим ключом он направляется на роль
output_processor
. Дальнейшая обработка объекта будет выполняться в
соответствие с настройками в секции output_processor:
output_processor:
unclassified:
pipeline: notification_filter
output: to_external_http_service
2.16.1.8. logger¶
В этой секции определяются настройки для кластерной роли logger
.
rotate_log
– флаг (true
/false
), осуществлять ли ротацию лога;max_msg_in_log
– максимальной количество сообщений, сохраняемых в логе;max_log_size
– максимальный размер файла лога, в байтах;delete_by_n_msg
– количество одновременно удаляемых сообщений при ротации лога. При превышении значений параметровmax_msg_in_log
илиmax_msg_log_size
наиболее старыеn
сообщений в логе удаляются за раз, что повышает производительность по сравнению с режимом, когда старые сообщения удаляются по одному.
2.16.1.9. audit_log¶
В секции задаются следующие параметры для работы журнала аудита:
enabled
– включена (true
) или выключена (false
) запись событий в журнал аудита. По умолчанию:true
.severity
– уровень важности событий, которые будут записываться в журнал аудита. Возможные значения по возрастанию важности:VERBOSE
,INFO
,WARNINIG
,ALARM
. По умолчанию:INFO
. При указании определенного уровня в журнал аудита будут записываться события этого уровня и выше. Например, если заданоINFO
, будут записываться события, соответствующие уровнямINFO
,WARNINIG
иALARM
. Подробнее см. список событий, соответствующий каждому уровню.remove_older_than_n_hours
– максимальное время хранения записей в журнале аудита, часы. Записи старше указанного времени удаляются. Значения по умолчанию нет.
2.16.1.10. tasks¶
В этой секции настраивается конфигурация задач, выполняемых при помощи ролей
scheduler
и task_runner
. Например:
tasks:
task_1:
kind: single_shot
pipeline: single_task
keep: 5
task_2:
kind: continuous
pipeline: long_task
pause_sec: 10
task_3:
kind: periodical
pipeline: long_task
schedule: "0 */5 * * * *"
Параметры конфигурации:
task_N
– имя задачи;kind
– вид задачи: «single_shot», «continuous» или «periodical» (см. подробнее);pipeline
– пайплайн, определяющий, что именно делается в рамках задачи;keep
– количество завершенных экземпляров задачи, которые сохраняются в истории. По умолчанию: 10;pause_sec
– пауза в выполнении задачи вида «continuous», секунды;schedule
– расписание выполнения для задач вида «periodical». Задается в форматеcron
. Используется расширенный синтаксис, в котором минимальной величиной является секунда:
* * * * * *
| | | | | |
| | | | | ----- День недели (0-6) (Воскресенье = 0)
| | | | ------- Месяц (1-12)
| | | --------- День (1-31)
| | ----------- Час (0-23)
| ------------- Минута (0-59)
--------------- Секунда (0-59)
В примере выше значение параметра schedule: "0 */5 * * * *"
означает, что
задача будет запускаться периодически каждые 5 минут.
2.16.1.11. task_runner¶
running_count_threshold
– порог количества выполняемых пайплайнов для задач
(tasks) и отложенных работ (jobs). По умолчанию: 100.
Этот параметр не ограничивает количество запущенных пайплайнов: при превышении порога в журнале просто создается предупреждение «Too many running pipelines. Now running %d pipelines».
2.16.1.12. jobs¶
max_jobs_in_parallel
– максимальное количество отложенных работ (jobs),
которые могут выполняться одновременно. По умолчанию: 50.
Когда достигается указанное ограничение, отложенные работы сверх лимита устанавливаются в очередь и выполняются по мере возможности.
2.16.1.13. account_manager¶
Настройки кластерной роли account_manager
, которая обеспечивает работу
ролевой модели доступа и связанных с ней функций безопасности
(см. подробнее).
only_one_time_passwords
– флаг (true
/false
). По умолчанию:false
. Если указано значениеtrue
, будет запрещена возможность вручную задать пароль пользователя при его создании или импорте. TDG будет автоматически генерировать одноразовый пароль и высылать его на адрес электронной почты пользователя. Для отсылки пароля также необходимо иметь работающий сервер SMTP, описание его конфигурации в секции connector (output: type: smtp
) и указание на этотoutput
в секцииaccount_manager
:account_manager: only_one_time_passwords: true output: name: to_smtp options: subject: "Registration"
Опционально можно указать заголовок письма, в котором высылается одноразовый пароль (
options: subject:
).Если указано значение
only_one_time_passwords: false
, то автоматическая генерация пароля и отсылка его пользователю также будет выполняться в случае, когда полеPassword
при создании пользователя оставлено пустым.password_change_timeout_seconds
– минимальное время, которое должно пройти до следующей смены пароля, секунды. Значения по умолчанию нет.Примечание
Ограничение на смену пароля действует только для смены собственного пароля. При изменении пароля другому пользователю данное ограничение не действует.
block_after_n_failed_attempts
– количество неудачных попыток входа в систему, после которых пользователь будет заблокирован (статус пользователя станет «blocked»). Значения по умолчанию нет.ban_inactive_more_seconds
– максимальное время, в течение которого пользователь может быть неактивен в системе, секунды. По истечении этого времени пользователь будет заблокирован. Максимально возможное значение параметра – 45 дней. Если значение превышает 45 дней или параметр не задан, будет взято значение по умолчанию, равное 45 дням.password_policy
– настройки политики паролей. Эти настройки также можно задать через web-интерфейс.min_length
– минимальная допустимая длина пароля. По умолчанию: 8.include
– флаги (true
/false
), определяющие, какие категории символов должны обязательно входить в пароль:lower
– латинские буквы в нижнем регистре. По умолчанию:true
.upper
– латинские буквы в верхнем регистре. По умолчанию:true
.digits
– цифры от 0 до 9 включительно. По умолчанию:true
.symbols
– дополнительные символы!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~
. По умолчанию:false
.
2.16.1.14. pepper¶
Строка символов, которая в целях усиления безопасности добавляется к паролю перед его хэшированием. Если данный параметр не указан в конфигурации, добавляется строка по умолчанию, определенная в коде системы.
2.16.1.15. auth_external¶
В настройке задается
Lua-код или путь к файлу с Lua-кодом, в котором пользователь имеет
возможность самостоятельно задать логику для авторизации входящих запросов.
Код должен вернуть таблицу с параметром auth
, в котором лежит функция для
проверки входящих запросов в формате HTTP
.
Функция возвращает либо nil
, если доступ запрещен, либо в противном
случае – объект, содержащий аутентификационную информацию.
Примечание
В версии Tarantool Data Grid, сертифицированной по требованиям доверия ФСТЭК
России, использование параметра auth_external
запрещено.
2.16.1.16. notifier¶
Настройки кластерной роли notifier
.
mail_server
– секция настроек сервера SMTP, который используется для отправки нотификаций при попадании объекта в ремонтную очередь. Данные параметры также можно задать через web-интерфейс.url
– URL сервера SMTP;from
– имя отправителя, которое будет показываться в поле «From» при получении нотификации;username
– имя пользователя сервера SMTP;password
– пароль пользователя сервера SMTP;timeout
– тайм-аут запроса к серверу SMTP, секунды.skip_verify_host
– флаг (true
/false
): пропустить проверку хоста по протоколу TLS.
users
– секция, где задаются данные подписчиков (subscribers), которые будут получать нотификации. Подписчиков также можно создать через web-интерфейс.id
– идентификатор подписчика;name
– имя подписчика;addr
– e-mail подписчика.
2.16.1.17. services¶
Параметры, которые задаются для каждого из сервисов:
type
– тип запроса GraphQL для вызова сервиса:query
илиmutation
. Если тип –query
, параметр можно не указывать.function
– ссылка на функцию, которая выполняет данный сервис. Функция должна быть описанна в конфигурации в секции functions.doc
– произвольное описание сервиса.return_type
– тип данных, который возвращается в результате выполнения сервиса.args
– описание аргументов, передаваемых на вход при выполнении сервиса, в формате «имя_аргумента: тип_данных».
2.16.1.18. expiration¶
В секции задаются следующие параметры:
type
– тип объекта, в отношении которого задаются ограничения.lifetime_hours
– время жизни объекта в часах. Объекты старше этой величины будут считаться устаревшими и подлежащими удалению. Значение по умолчанию: 24.delay_sec
– интервал в секундах, через который запускается очередная проверка устаревших объектов и их удаление. Значение по умолчанию: 36000.keep_version_count
– ограничение количества версий для объектов данного типа. По умолчанию: не ограничено.
Данные настройки также можно задать через web-интерфейс.
2.16.1.19. archivation¶
Определенные типы объектов могут поступать в систему в большом количестве, но при этом иметь короткое время активного использования, после чего потребность в обращении к ним возникает редко. Для этого случая реализован механизм архивации, когда такие объекты выгружаются из TDG и сохраняются отдельно на жестком диске.
Объекты сохраняются в текстовом виде в файлах формата .jsonl
(формат имени – YYYY-MM-DDTHH:MM:SS.jsonl
). Объекты записываются в файл
построчно: один объект – одна строка вида {"TypeName": {... data ...}}
, где
TypeName
– тип сохраняемого объекта.
Настройки архивации в конфигурации TDG:
type
– тип объекта.lifetime_days
– время жизни объекта в TDG, дни. Объекты старше этой величины архивируется.schedule
– расписание запуска задачи на архивацию в форматеcron
.dir
– директория для хранения файлов с архивными данными.file_size_threshold
– максимальный размер файла с архивными данными, байты. По достижении этого размера запись архивируемых данных начинается в новый файл. По умолчанию: 104857600 (100 Мб).
2.16.1.20. hard_limits¶
Для контроля нагрузки на сервер задаются следующие ограничения на выполнение GraphQL-запросов:
scanned
– запрос не должен проходить больше заданного количества кортежей в спейсах. По умолчанию: 2000.returned
– запрос не должен возвращать больше заданного количества кортежей. По умолчанию: 100.
При превышения одного из ограничений выполнение запроса прекращается и возвращается ошибка.
2.16.1.21. force_yield_limits¶
force_yield_limits
– ограничение на количество сканирований записей в
спейсе. При достижении порога выполняется yield
. По умолчанию: 1000.
Актуально при выполнении map_reduce, чтобы избежать
зависаний на инстансах с ролью storage
. Также учитывается при работе
функций программного интерфейса репозитория.
2.16.1.22. graphql_query_chache_size¶
graphql_query_chache_size
– размер кэша запросов GraphQL. Измеряется в
количестве запросов, т.е. кэшируются N последних уникальных запросов в виде
полного текста каждого запроса. По умолчанию: 3000.
2.16.1.23. vshard_timeout¶
vshard_timeout
– время ожидания запроса, которое передается в
vshard.callro/callrw
, секунды. По умолчанию: 2.
Подробнее см. документацию по модулю vshard.
2.16.1.24. maintenance¶
clock_delta_threshold_sec
– порог рассинхронизации истинного времени
(CLOCK_REALTIME) на серверах, секунды. По умолчанию: 5.
При превышении порога в логе создается запись об ошибке «Time deviation threshold exceeded! Max clock delta is %s». Проверка синхронизации важна для операций, использующих метки времени, таких как логирование и аудит.
2.16.1.25. gc¶
Роль garbage_collector
принудительно
запускает сборку мусора в Lua. Роль включается неявно на всех инстансах.
Параметры:
forced
– включение (true
) или отключение (false
) принудительной сборки мусора. По умолчанию:false
.period_sec
– интервал, через который происходит запуск нового цикла сборки мусора, секунды.steps
– размер шага сборщика мусора.
2.16.1.26. tracing¶
Настройки коммуникации с трейсинг-системой (tracing system), куда передаются данные для анализа производительности выполнения кода. Подробнее про настройки модуля, используемого для организации трейсинга кода, см. здесь.
base_url
– эндпойнт программного интерфейса (API endpoint), куда отсылаются собранные для анализа спаны (spans).api_method
– тип HTTP-запроса для обращения кbase_url
. Для трейсинг-систем, поддерживающих протоколOpenZipkin
, –POST
.report_interval
– интервал, через который в трейсинг-систему отсылаются накопленные спаны, секунды.spans_limit
– размер буфера для накопления спанов перед отправкой в трейсинг-систему. Измеряется количеством спанов.
Например:
tracing:
base_url: localhost:9411/api/v2/spans
api_method: POST
report_interval: 5
spans_limit: 100
2.16.1.27. sequence_generator¶
Настройки, используемые при генерации последовательностей уникальных чисел:
starts_with
– число, с которого начинается последовательность. По умолчанию: 1.range_width
– диапазон последовательности. По умолчанию: 100.
См. подробнее про функцию работы с последовательностью.
2.16.1.28. frontend¶
Роль используется для статического расширения пользовательского интерфейса. Параметры, определяемые в конфигурации:
name
– произвольное имя расширения.file
– пути к файлам, реализующим расширение. Могут быть указаны файлы в формате.html
,.css
,.js
.
Например:
frontend:
- name: myapp
files:
"index.html":
__file: app/index.html
2.16.1.29. test-soap-data¶
Параметр позволяет задать текст, который будет по
умолчанию отображаться на закладке Test в web-интерфейсе.
Может использоваться для удобства
тестирования: в этой секции можно задать структуру тестового объекта в формате
XML
или JSON
для имитации входящего запроса.
2.16.1.30. libraries¶
Настройка подключения пользовательских библиотек, которые могут использоваться в коде функций пайплайнов (см. секции functions и pipelines). Указывается имя библиотеки, которое будет использоваться в коде, и путь к файлу библиотеки, который загружается вместе с конфигурацией системы.
Пример конфигурации:
libraries:
cache:
__file: cached.lua
utils:
__file: utils.lua
Пример вызова:
Если в указанной в конфигурации библиотеке (например, utils.lua
) определена
функция
local function timediff(value)
return (datetime.now() - value)
end
то в пользовательском коде функцию можно вызвать как utils.timediff(value)
.
2.16.1.31. welcome-message¶
Текст приветственного сообщения, которое будет появляться при входе в систему. Ограничения на количество символов в сообщении нет.