Руководство администратора

Настоящее Руководство содержит описание и сценарии эксплуатации и администрирования TQE(MQ).

• Введение.
• Сценарии использования.

TQE(MQ) выступает в качестве брокера, ответственного за передачу сообщений потребителям. Потребители получают только те сообщения, на которые подписаны. Такой подход снижает избыточный трафик данных, повышает эффективность обработки и обеспечивает максимально высокую пропускную способность.

Каждое сообщение состоит из нескольких полей:

• id - идентификатор сообщения. Монотонно возрастающий уникальный ключ генерируемый мастером набора реплик. При асинхронной репликации монотонность и уникальность поддерживаются только на уровне одной реплики.
• sharding_key - ключ шардирования. Опциональное поле. Если оно указано, на его основе выбирается целевой шард для сообщения. Если поле не указано, система самостоятельно назначает ключ для равномерной загрузки шарда. При статическом шардировании sharding_key обязателен.
• routing_key - ключ фильтрации. Опциональное поле. Если оно указано, очередь отвечает на запрос только сообщениями с указанным routing_key.
• deduplication_key - ключ дедупликации. Опциональное поле. Если оно указано, перед каждой вставкой очередь проверяет наличие такого ключа в индексе. По умолчанию очередь отвечает ошибкой, если такой ключ уже существует.
• payload - содержимое сообщения.
• metadata - метаданные.
• timestamp - время вставки.

Система гарантирует строгий порядок сообщений в пределах одного шарда: сообщения с одинаковым ключом шардирования (sharding_key) обрабатываются строго друг за другом.

Публикация. На каждое опубликованное сообщение система возвращает уникальный идентификатор. Чтобы экономить сетевые ресурсы, можно отправлять сообщения пакетами. В этом случае для всего пакета указывается единый sharding_key, а запись в шард происходит транзакционно. Однако если хотя бы одно сообщение из пакета не проходит валидацию, то весь пакет не записывается. Система вернет ошибку с указанием идентификатора первого проблемного сообщения. В случае успеха вы получите список идентификаторов всех сообщений в том же порядке, в каком они отправлялись в запросе.

Чтение. Читать сообщения можно только в пределах одного шарда. Доступны три режима навигации:

• с самого первого сообщения.
• с указанного курсора.
• с последнего сообщения в очереди.

В ответе на запрос содержится поле cursor. Его можно использовать, чтобы возобновить чтение с последнего прочитанного сообщения, например для восстановления подписки.

Если задать таймаут ожидания polling_timeout (в миллисекундах), очередь будет ждать появления новых сообщений и ответит сразу, как только они появятся. Это избавляет от пустых опросов, когда сообщений временно нет.

Фильтрация и консистентность. При чтении можно указать routing_key, и очередь вернет только сообщения с этим ключом. Также поддерживается фильтрация по нескольким ключам sharding_key. Если реплика отстала от лидера и получила запрос на чтение с курсора, которого у нее еще нет, она задержит ответ до момента получения актуальных данных (в пределах указанного таймаута) — так обеспечивается консистентное чтение.

Подписка на сообщения (например, через gRPC) реализуется на уровне коннектора, а не самой очереди.

Шардирование. Система поддерживает два типа шардирования:

• Стандартное шардирование tarantool, реализованное через vshard.
• Статическое шардирование. Его настройка и принципы работы описаны ниже.

Отказоустойчивость. Используется стандартная процедура tarantool без дополнительных модификаций.

Журналирование. Настройка журналов ведется через параметры конфигурационного файла. См. подробнее.

Метрики. Система предоставляет набор метрик для мониторинга состояния. См. подробнее.

Сценарии использования в данном руководстве сгруппированы по компонентам TQE(MQ).

Сценарии охватывают следующие роли пользователей TQE(MQ):

• Инженер по эксплуатации.
• Администратор.

Инженер по эксплуатации выполняет следующие сценарии:

• Проверка статусов компонентов TQE(MQ).
• Операции с метриками.

Администратор выполняет следующие сценарии:

• Настройка параметров Tarantool.
• Установка компонентов TQE(MQ).
• Конфигурация компонентов TQE(MQ).
• Резервное копирование.
• Удержание сообщений.

Проверка статуса ядра выполняется с помощью команды:

 
$ curl localhost:8081/health

При штатном режиме работы ядра возвращается ответ:

 
app is OK

Проверка статуса модуля API выполняется с помощью команды:

 
$ curl localhost:18184/readyz

При штатном режиме работы модуля API возвращается ответ:

 
{    "consumer-tarantool": "OK",    "producer-tarantool": "OK",    "started": "OK"}

Где:

• started - обязательное значение. Показывает статус работы модуля API. Принимает значение "OK" или текст ошибки.
• consumer-tarantool - необязательное значение. Показывает статус подключения сервиса подписки на сообщения к ядру TQE(MQ). Принимает значение "OK" или текст ошибки.
• producer-tarantool - необязательное значение. Показывает статус подключения сервиса публикации сообщений к ядру TQE(MQ). Принимает значение "OK" или текст ошибки.

Для синхронных очередей перед установкой компонентов TQE укажите значение true для параметра use_mvcc_engine в конфигурации Tarantool для включения двухэтапной проверки дубликатов сообщений:

 
database:  use_mvcc_engine: true

На первом этапе проверки система ищет дубликаты среди сообщений, уже подтвержденных кластером. Если дубликат найден, действует согласно значению параметра deduplication_mode. Если дубликат не найден на первом этапе, на втором этапе система ищет дубликаты среди сообщений, записанных на мастер, но еще не подтвержденных кластером. При обнаружении дубликата система возвращает ошибку concurrent unconfirmed publish, retry и отклоняет весь пакет.

При use_mvcc_engine: false двухэтапная проверка не работает, и система выдает предупреждение.

Установка компонентов TQE(MQ) выполняется с помощью инструментов Ansible Tarantool Enterprise (ATE). Подготовка ATE к работе и процедуры установки компонентов TQE(MQ) описаны в документации ATE.

Конфигурация компонентов TQE(MQ) включает раздельные настройки для ядра и для модуля API. Настройки описываются в формате YAML.

Сначала настраивается ядро, затем модуль API.

Ядро конфигурируется стандартными средствами Tarantool 3: с помощью обновления файла конфигурации или конфигурации в etcd/Tarantool Config Storage. Подробнее о конфигурации в Tarantool 3 см. здесь

Файл конфигурации ядра в формате YAML называется config.yml и содержит несколько секций. Пример файла конфигурации ядра:

 
credentials:  # Роли tqe_producer и tqe_consumer и их привилегии описаны ниже, в разделе  # «Настройки ролей и пользователей». Доступ к каждой очереди разграничивается  # привилегиями read и write на её спейс queue_<имя_очереди>.  users:    tqe_producer_user:      password: pass      roles: [tqe_producer]      privileges:        - permissions: [read, write]          spaces: [queue_queue, queue_another_queue, queue_archive_queue, queue_queue_disabled_index]    tqe_consumer_user:      password: pass      roles: [tqe_consumer]      privileges:        - permissions: [read]          spaces: [queue_queue, queue_another_queue, queue_archive_queue, queue_queue_disabled_index]roles_cfg:  roles.tqe-storage:    features:      metrics_enabled: true      validation_enabled: true    queues:      - name: queue      - name: another_queue        deduplication_mode: basic      - name: archive_queue        storage: disk      - name: queue_disabled_index        disabled_filters_by: [routing_key, sharding_key]  roles.tqe-router:    sharding:      routing:        core-1:            buckets:            - 1            - [2,10]        core-2:            buckets:            - [11,20]        core-3:            buckets:            - [21,1000]

В Tarantool по умолчанию существуют два встроенных пользователя:

• admin — пользователь со всеми административными привилегиями, доступен только через порт admin-console (например, при локальном подключении через tt connect). Для удаленных подключений необходимо установить пароль.
• guest — пользователь с минимальными привилегиями, используется по умолчанию для удаленных бинарных подключений. Выдавать этому пользователю дополнительные права не рекомендуется. Подробнее о пользователях Tarantool см. по ссылке.

Для работы с TQE (MQ) необходимо в разделе credentials объявить роли tqe_producer и tqe_consumer и создать пользователей. Роли не содержат привилегий на очереди, поэтому очереди необходимо перечислить отдельно (см. ниже). Подробнее о настройке ролей в Tarantool см. по ссылке.

Конфигурация ролей в TQE (MQ) выглядит следующим образом:

 
credentials:  roles:    tqe_producer: {}    tqe_consumer: {}

Далее в разделе credentials.users необходимо создать пользователей и указать для них роли и привилегии:

• users - список пользователей системы.
• username_1 - имя пользователя. Для пользователя указываются следующие параметры:
  • password - пароль пользователя.
  • roles - список ролей.
  • privileges - список привилегий. Привилегии могут предоставлять права чтения read и записи write. read указывается для пользователя с ролью tqe_consumer. Для пользователя с ролью tqe_producer указываются привилегии read и write.
    • spaces - список очередей, на которые выдаются привилегии. Каждая очередь, на которую распространяются привилегии, должна указываться явно. Имена очередей должны соответствовать формату queue_<имя_очереди>, например, queue_orders.

Пример:

 
credentials:  ...  users:    tqe_producer_user:      password: "<producer_password>"      roles: [tqe_producer]      privileges:        - permissions: [read, write]          spaces: [queue_orders, queue_events]    tqe_consumer_user:      password: "<consumer_password>"      roles: [tqe_consumer]      privileges:        - permissions: [read]          spaces: [queue_orders, queue_events]

Раздел настроек features содержит параметры функций ядра. Настройка выполняется на уровне ролей roles.tqe-storage и roles.tqe-router.

Параметры раздела:

• metrics_enabled - включает или выключает сбор метрик для методов API ядра. Значение по умолчанию: true.
• validation_enabled - включает или выключает валидацию сообщений для методов API ядра. Значение по умолчанию: true.

Пример:

 
roles_cfg:  roles.tqe-storage:    features:      metrics_enabled: true      validation_enabled: false  roles.tqe-router:    features:      metrics_enabled: false      validation_enabled: true

Раздел настроек queues содержит описание используемых очередей сообщений и их параметры. Настройка выполняется на уровне ролей roles.tqe-storage и roles.tqe-router.

Параметры раздела:

• name - название очереди сообщений.
• latency - задержка в миллисекундах между оповещениями подписчика о новых сообщениях. Значение по умолчанию: 1.
• deduplication_mode - режим обработки отдельных дублированных сообщений и пакетов, их содержащих. Может принимать значения:
  • basic - если публикуемое сообщение или пакет сообщений содержит дубликат, публикация отменяется и система возвращает ошибку дедупликации. Используется по умолчанию.
  • extended - режим расширенной дедупликации.
  • keep_latest - если сообщение является дубликатом, оно публикуется, а ранее опубликованное удаляется.
  • keep_first - если сообщение является дубликатом, оно не публикуется. Вместо этого возвращается id ранее опубликованного сообщения, ошибка не возвращается.
• poll_max_batch – максимальное количество сообщений в пакете, возвращаемом очередью в ответ на один запрос потребителя. Сообщения сверх этого количества формируют следующий пакет. Значение по умолчанию: 100.
• poll_min_batch – целевое минимальное количество сообщений, возвращаемых очередью в ответ на один запрос потребителя. Если количество накопленных сообщений ниже poll_min_batch (включая 0), но время, указанное в poll_batch_timeout истекло, пакет отправляется в ответ на запрос потребителя. Значение не может превышать poll_max_batch. Значение по умолчанию: 10.
• poll_batch_timeout - время в секундах, отводимое на сбор сообщений в пакет после получения первого сообщения. Допускаются дробные значения (разделитель — точка). По истечении времени, указанного в параметре, очередь отправит пакет сообщений, даже если количество сообщений не достигло значения poll_min_batch. Значение по умолчанию: 0.500 (полсекунды).
• storage – движок хранения очереди. Допустимые значения:
  • memory - используется memtx;
  • disk - используется vinyl. Значение по умолчанию: memory.
• poll_yield_every – количество сообщений, после обработки которых обработчик передает управление другим задачам. Значение по умолчанию: 512.
• disabled_filters_by - список отключенных фильтров. Отключение фильтра делает невозможным подписку с фильтрацией по указанному полю. Изменение этой опции после создания очереди позволяет включить фильтрацию по полю, удалив его из списка, но не позволяет отключить ее. Значение по умолчанию: [] (фильтрация включена по всем полям). Возможные значения: routing_key, sharding_key.

Пример:

 
roles_cfg:  roles.tqe-storage:      queues:        - name: queue1          latency: 1          disabled_filters_by: [sharding_key]          deduplication_mode: basic        - name: queue2

Также существует другой, сокращенный вариант настройки параметров раздела queues:

 
roles_cfg:  roles.tqe-storage:    queues: ["queue1", "queue2"]

В результате такого запроса создадутся 2 очереди, queue1 и queue2, со значениями остальных параметров по умолчанию.

Расширенная дедупликация в TQE(MQ) — это режим, при котором проверяется не только уникальность deduplication_key сообщения, но и полное совпадение его содержимого. Если при одинаковом deduplication_key содержимое сообщений различается, система возвращает ошибку. Такой режим позволяет безопасно работать нескольким независимым публикаторам (основному и резервному): дублирование одинаковых сообщений допускается, а расхождение в данных обнаруживается сразу.

Для включения режима расширенной дедупликации добавьте параметр deduplication_mode: extended в конфигурацию очереди в роль roles.tqe-storage:

 
roles_cfg:  roles.tqe-storage:    queues:      - name: dedup        deduplication_mode: extended

При включенной расширенной дедупликации обнаружение дубликатов с разным содержимым в одиночном сообщении или при пакетной отправке приводит к ошибке failed to publish messages to tarantool: storage.produce error: id (*): payload may be corrupted.

TQE(MQ) использует механизм виртуального шардирования (vshard) для распределения данных. Базовой атомарной единицей в vshard является бакет - логический контейнер данных с уникальным идентификатором. Если два различных сообщения принадлежат одному бакету, то они гарантированно хранятся на одном наборе реплик с ролью storage.

В TQE(MQ) доступен режим статического шардирования — ручной настройки карты распределения бакетов по наборам реплик в кластере. Настройка задается в глобальной конфигурации кластера, после чего необходимо выполнить начальную загрузку. В результате в наборах реплик кластера создаются бакеты в соответствии с заданной картой.

Статическое шардирование настраивается через роль roles.tqe-router в разделе roles_cfg:

• в разделе sharding.routing укажите карту бакетов в формате replicaset-alias:bucket-range:
  • core-n - псевдоним набора реплик (replica set) из топологии.
  • buckets - диапазон обслуживаемых бакетов. Может принимать массив значений, где каждое - либо id одного бакета, либо диапазон бакетов "от и до".

Пример:

 
roles_cfg:  roles.tqe-router:    sharding:      routing:        core-1:            buckets:            - 1                # Можно задать идентификатор бакета точечно.            - 2            - [3,300]          # Можно указать диапазон бакетов.        core-2:            buckets:            - [301,500]        core-3:            buckets:            - [501,1000]

По окончании настройки выполните загрузку кластера стандартной командой tarantool:

 
$ tt replicaset vshard bootstrap .

Оркестратор — это компонент, который при инициализации разбивает бакеты каждого шарда в кластере на партиции — непрерывные диапазоны бакетов. Каждая партиция уникальна в рамках кластера. Количество партиций задается при установке экземпляра TQE(MQ) и не может быть изменено без его переустановки.

Оркестратор автоматически распределяет партиции между потребителями, если они объединены в группы. В результате один потребитель может обрабатывать несколько партиций, но каждая партиция обрабатывается не более чем одним потребителем. Оркестратор отслеживает состав групп и при подключении или отключении потребителя от группы запускает автоматическую перебалансировку: партиции перераспределяются между оставшимися потребителями в группе. Это исключает ручные перенастройки, предотвращает дублирование сообщений и обеспечивает непрерывность обработки сообщений потребителями.

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

Оркестратор настраивается для всего кластера на уровне роли roles.tqe-orchestrator:

• partitions - количество партиций, на которые разделяются все шарды в кластере. Рекомендуется использовать число, кратное общему количеству бакетов кластера.
• rebalance_timeout - задержка между изменением состава группы и запуском перераспределения партиций (в секундах).
• sync_timeout - таймаут активности потребителя (в секундах). Если оркестратор не получает от потребителя запрос синхронизации в течение этого времени, такой потребитель считается неактивным и исключается из группы. Исключенный потребитель может войти в группу повторно.

Пример:

 
roles:  roles.tqe-orchestrator:    partitions: 10    rebalance_timeout: 20    sync_timeout: 5

Параметры конфигурации компонента модуля API необходимо определить до его запуска и запуска TQE(MQ), чтобы избежать проблем с подключением к очереди сообщений и аварийного завершения работы модуля.

YAML-файл конфигурации модуля API называется config.service.yml и содержит несколько разделов. Полный перечень настроек представлен в следующем примере:

 
app_name: MESSAGE_QUEUE_EE_APIapp_version: testcore_host: 0.0.0.0core_port: 18184grpc_host: 0.0.0.0grpc_port: 18182producer:  enabled: true  tarantool:    user: tqe_producer_user    pass: pass    connections:      routers:        - "localhost:3301"consumer:  enabled: true  polling_timeout: 500ms  cursor_serilizer: 'yaml'  buffer: 12  concurrency: 2  access_mode: 'prefer_ro'  tarantool:    user: tqe_consumer_user    pass: pass    connections:      storage-1:        - "localhost:3301"log:  to: file  file: log.jsonl  format: json  level: info

Основные параметры задают адреса и порты для подключения модуля API:

• app_name - название приложения.
• app_version - версия приложения.
• core_host - адрес сбора метрик и проверки состояния модуля API.
• core_port - порт сбора метрик и проверки состояния модуля API.
• grpc_options - раздел конфигурации gRPC-сервера. См. подробнее. Установленные значения не изменяются после запуска gRPC-сервера:
  • initial_conn_window_size - начальный размер окна http2-соединения в байтах. Значение по умолчанию: 64kb.
  • initial_window_size - начальный размер окна http2-потока в байтах. Значение по умолчанию: 64kb.
  • header_table_size - размер динамической таблицы заголовков http2. Значение по умолчанию не задано (динамическая таблица не используется).
  • max_header_list_size - максимальный размер таблицы заголовков http2. Значение по умолчанию не задано.
  • max_concurrent_streams - количество одновременных http-потоков. Значение по умолчанию: 128.
  • num_stream_workers - количество обработчиков входящих запросов. Значение по умолчанию: 0 (под каждый http2-поток создается отдельная горутина).
  • max_recv_msg_size - максимальный размер входящего сообщения в байтах. Значение по умолчанию: 4mb.
  • max_send_msg_size - максимальный размер исходящего сообщения в байтах. Значение по умолчанию: 2mb.
  • read_buffer_size - размер буфера на чтение. Значение по умолчанию: 256kb.
  • write_buffer_size - размер буфера на запись. Значение по умолчанию: 256kb.
  • shared_write_buffer - позволяет переиспользовать буфер на запись, а не создавать новый для каждого подключения. Значение по умолчанию: false.
• grpc_listen - набор интрефейсов, на которых gRPC-сервер принимает подключения.
  • uri - адрес для прослушивания, например: unix:///tmp/tqe-mq.sock или tcp://localhost:18182.
• grpc_host - адрес модуля API (устарел после введения grpc_listen).
• grpc_port - порт модуля API (устарел после введения grpc_listen).

Пример:

 
app_name: MESSAGE_QUEUE_EE_APIapp_version: 1.0core_host: 0.0.0.0core_port: 18184grpc_listen:  - uri: 'tcp://0.0.0.0:18182'grpc_host: 0.0.0.0grpc_port: 18182grpc_options:  initial_conn_window_size: 65535  initial_window_size: 65535  header_table_size: 16777216  max_header_list_size: 128  max_concurrent_streams: 128  num_stream_workers: 0  max_recv_msg_size: 4294967296  max_send_msg_size: 2147483647  read_buffer_size: 262144  write_buffer_size: 262144  shared_write_buffer: false

Параметры сетевого подключения клиента к очереди по протоколу зашифрованного канала связи TLS (Transport Layer Security) указываются в разделе настроек grpc_options файла config.service.yml:

• tls - раздел настроек подключения по протоколу зашифрованного канала связи TLS (Transport Layer Security).
  • enabled - включает или выключает подключение по TLS. Обязательный параметр. Принимает значения:
    • true - подключение по TLS включено.
    • false - подключение по TLS выключено. Используется по умолчанию.
  • cert_file - абсолютный или относительный путь к файлу с публичным сертификатом TLS (public_key). Параметр обязателен при enabled: true.
  • key_file - абсолютный или относительный путь к файлу с закрытым (приватным) ключом. Параметр обязателен при enabled: true.
  • ca_file - абсолютный или относительный путь к файлу с сертификатами доверенных удостоверяющих центров.
  • password - пароль для расшифровки файла закрытого ключа. Если указан одновременно с password_file, приоритетным считается путь в password_file.
  • password_file - абсолютный или относительный путь к файлу с паролем для расшифровки закрытого ключа. Если указан одновременно с password, то приоритетным считается путь в password_file.
  • ciphers - список алгоритмов шифрования, разрешенных при установке защищенного соединения. Подключение выполняется, только если клиент и сервер имеют хотя бы один общий алгоритм в списках разрешенных. Список поддерживаемых алгоритмов представлен в таблице ниже. Поддерживаются в том числе ГОСТ-алгоритмы (см. раздел «ГОСТ-шифры и сертификаты» ниже). Если параметр ciphers задан, версия протокола фиксируется на TLS 1.2.

Поддерживаемые алгоритмы шифрования.

Пример:

 
grpc_options:  tls:    enabled: true    cert_file: /path/to/server.crt    key_file: /path/to/server.key    ca_file: /path/to/ca.crt    password: "secret"    password_file: /path/to/passwords.txt      ciphers: 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256'

ГОСТ-шифры и сертификаты.

Терминация TLS в gRPC API выполняется через OpenSSL, поэтому поддерживаются ГОСТ-шифры (ГОСТ Р 34.12-2015) и ГОСТ-сертификаты (ГОСТ Р 34.10-2012) в формате PEM. ГОСТ-шифры задаются через параметр ciphers по их OpenSSL-именам:

Пример конфигурации с ГОСТ-шифрами и ГОСТ-сертификатами:

 
grpc_options:  tls:    enabled: true    cert_file: /path/to/gost-server.crt    key_file: /path/to/gost-server.key    ca_file: /path/to/gost-ca.crt    ciphers: 'GOST2012-GOST8912-GOST8912'

Ядро TQE(MQ) включает в себя маршрутизаторы, хранилища и оркестраторы.

Подключение к ядру может быть динамическим, когда обнаружение топологии ядра происходит через удаленную службу Tarantool configuration Storage (TcS) или распределенное хранилище etcd.

При необходимости можно использовать статическое подключение. Тогда адреса маршрутизаторов и хранилищ задаются в конфигурации модуля API по отдельности.

При динамическом подключении обнаружение топологии ядра происходит через удаленную службу TcS или распределенное хранилище etcd.

Настройки подключения к TcS указываются в разделе config.storage:

• endpoints - данные точек подключения в формате списка, содержащего:
  • uri - URI точки подключения.
  • login - логин для подключения.
  • password - пароль для подключения.
  • params - параметры подключения по протоколу зашифрованного канала связи TLS:
    • transport - включает или выключает подключение по TLS. Обязательный параметр. Принимает значения:
      • ssl - подключение по TLS включено.
      • plain - подключение по TLS выключено. Используется по умолчанию.
    • ssl_cert_file - абсолютный или относительный путь к файлу с публичным сертификатом TLS (public_key). Параметр обязателен при transport: ssl.
    • ssl_key_file - абсолютный или относительный путь к файлу с закрытым (приватным) ключом. Параметр обязателен при transport: ssl.
    • ssl_ca_file - абсолютный или относительный путь к файлу с сертификатами доверенных удостоверяющих центров.
    • ssl_password - пароль для расшифровки файла закрытого ключа. Если указан одновременно с ssl_password_file, приоритетным считается путь в ssl_password_file.
    • ssl_password_file - абсолютный или относительный путь к файлу с паролем для расшифровки закрытого ключа. Если указан одновременно с ssl_password, приоритетным считается путь в ssl_password_file.
    • ssl_ciphers - список алгоритмов шифрования, разрешенных при установке защищенного соединения. Подключение выполняется, только если клиент и сервер имеют хотя бы один общий алгоритм в списках разрешенных. См. список разрешенных алгоритмов.
• username - логин для подключения. Используется если логин (login) не задан в списке данных точки подключения в endpoints.
• password - пароль для подключения. Используется если пароль (password) не задан в списке данных точки подключения в endpoints.
• prefix - префикс для маршрутизации внутри удаленной службы.
• timeout - таймаут подключения в секундах.
• reconnect_after - интервал в секундах между повторными подключениями.
• max_reconnect_attempts - максимальное число попыток повторного подключения.

Пример настройки:

 
config:  storage:    endpoints:      - uri: "127.0.0.1:4401"        login: sampleuser        password: "123456"      - uri: "127.0.0.1:4440"        login: sampleuser        password: "123456"        params:          transport: "ssl"          ssl_cert_file: "examples/tls-full/certs/tcs/storage.crt"          ssl_key_file: "examples/tls-full/certs/tcs/storage.key"          ssl_ca_file: 'examples/tls-full/certs/ca/ca.crt'    username: sampleuser    password: "123456"    prefix: "/tarantool/tqe-mq"    timeout: 5s    reconnect_after: 5s    max_reconnect_attempts: 3

Настройки подключения к etcd указываются в разделе config.etcd:

• endpoints - HTTP-адреса точек подключения в формате списка.
• prefix - префикс для маршрутизации внутри удаленной службы.
• timeout - таймаут подключения в секундах.
• reconnect_after - интервал в секундах между повторными подключениями.
• max_reconnect_attempts - максимальное число попыток повторного подключения.
• ssl - параметры подключения по протоколу зашифрованного канала связи TLS:
  • ca_file - абсолютный или относительный путь к файлу с сертификатами доверенных удостоверяющих центров.
  • ca_path - абсолютный или относительный путь к каталогу, в котором хранятся файлы с сертификатами доверенных удостоверяющих центров.
  • ssl_cert - абсолютный или относительный путь к файлу с публичным сертификатом TLS (public_key).
  • ssl_key - абсолютный или относительный путь к файлу с закрытым (приватным) ключом.
  • verify_peer - включает проверку клиентом etcd цепочки сертификатов и имени хоста сервера etcd. Возможные значения:
    • true - проверка включена.
    • false - проверка выключена. Это значение используется по умолчанию.

Пример настройки:

 
config:  etcd:    endpoints:      - "http://localhost:2379"    prefix: "/tarantool/tqe-mq"    timeout: 5s    reconnect_after: 5s    max_reconnect_attempts: 3    ssl:      ca_file: "examples/tls-full/certs/ca/ca.crt"      ca_path: "examples/tls-full/certs/ca"      ssl_cert: "examples/tls-full/certs/tcs/storage.crt"      ssl_key: "examples/tls-full/certs/tcs/storage.key"      verify_peer: false

При статическом подключении к маршрутизаторам их адреса задаются пользователем вручную в разделе настроек producer. Изменение адресов или списка маршрутизаторов также выполняется вручную.

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

• enabled - включает или выключает режим публикации сообщений в очередь. Возможные значения:
  • true - публикация сообщений включена.
  • false - публикация сообщений выключена.
• tarantool - раздел настроек доступа к ядру TQE(MQ):
  • user - логин для доступа к очереди (задается в разделе credentials конфигурации ядра TQE(MQ)).
  • pass - пароль для доступа к очереди (задается в разделе credentials конфигурации ядра TQE(MQ)).
  • connections - перечень названий типов подключений. Не указывается в случае динамического подключения.

Пример:

 
producer:  enabled: true  tarantool:    user: tqe_producer_user    pass: pass    connections:      rs-1:        - "localhost:3301"

При статическом подключении к хранилищам их адреса задаются пользователем вручную в разделе настроек consumer. Изменение адресов или списка хранилищ также выполняется вручную.

Параметры статического подключения к хранилищам:

• enabled - включает или выключает режим потребления сообщений из очереди. Возможные значения:
  • true - потребление сообщений включено.
  • false - потребление сообщений выключено.
• polling_timeout - задержка между запросами на получение новых сообщений с указанием единиц измерения. Пример: 500ms - 500 миллисекунд.
• cursor_serializer - тип сериализатора курсора. По умолчанию пустое значение (используется сериализатор base64). Доступные значения: json, yaml.
• buffer_size - размер внутреннего буфера потребителя (в сообщениях). Значение по умолчанию: 8.
• concurrency - количество параллельных потоков потребления сообщений. Значение по умолчанию: 1.
• access_mode - режим взаимодействия с наборами реплик Tarantool. Значение по умолчанию: prefer_rw. Подробнее о возможных значениях см. по ссылке.
• tarantool - раздел настроек доступа к очереди TQE MQ:
  • user - логин логин для доступа к очереди (задается в разделе credentials конфигурации ядра TQE(MQ)).
  • pass - пароль длогин для доступа к очереди (задается в разделе credentials конфигурации ядра TQE(MQ)).
  • connections - раздел адресов хранилищ для подписки на сообщения. Не указываются в случае динамического подключения.
  • queues - опциональный раздел доступных очередей TQE(MQ).

Пример:

 
consumer:  enabled: true  polling_timeout: 500ms  cursor_serilizer: 'yaml'  buffer: 12  concurrency: 2  access_mode: 'prefer_ro'  tarantool:    user: tqe_consumer_user    pass: pass    queues:      queue:        connections:          storage-1:            - "localhost:3301"

Подключение к экземпляру TQE (MQ) для публикации и чтения сообщений может выполняться по протоколу зашифрованного канала связи TLS (Transport Layer Security). Для включения этого протокола необходимо указать настройки подключения в разделах tarantool.params сервисов producer и consumer:

 
producer:  ...  tarantool:    user: user    pass: pass    params:      transport: "ssl"      ssl_cert_file: server2.crt      ssl_key_file: server2.keyconsumer:  ...  tarantool:    user: user    pass: pass    params:      transport: "ssl"      ssl_cert_file: server.crt      ssl_key_file: server.key

Параметры подключения по протоколу зашифрованного канала связи TLS:

• transport - включает или выключает подключение по TLS. Обязательный параметр. Принимает значения:
  • ssl - подключение по TLS включено.
  • plain - подключение по TLS выключено. Используется по умолчанию.
• ssl_cert_file - абсолютный или относительный путь к файлу с публичным сертификатом TLS (public_key). Параметр обязателен при transport: ssl.
• ssl_key_file - абсолютный или относительный путь к файлу с закрытым (приватным) ключом. Параметр обязателен при transport: ssl.
• ssl_ca_file - абсолютный или относительный путь к файлу с сертификатами доверенных удостоверяющих центров.
• ssl_password - пароль для расшифровки файла закрытого ключа. Если указан одновременно с ssl_password_file, приоритетным считается путь в ssl_password_file.
• ssl_password_file - абсолютный или относительный путь к файлу с паролем для расшифровки закрытого ключа. Если указан одновременно с ssl_password, приоритетным считается путь в ssl_password_file.
• ssl_ciphers - список алгоритмов шифрования, разрешенных при установке защищенного соединения. Подключение выполняется, только если клиент и сервер имеют хотя бы один общий алгоритм в списках разрешенных. См. список разрешенных алгоритмов.

Параметры журналирования задаются в разделе log модуля API. Структура раздела аналогична разделу log ядра Tarantool.

Доступные параметры секции log:

• to - место сохранения записей журнала. Принимаемые значения:
  • stderr - вывод событий журнала в stderr. Используется по умолчанию, если модуль API запущен не в фоновом режиме.
  • file - запись в файл, указанный в параметре log.file. Используется по умолчанию, если модуль API запущен в фоновом режиме (с флагом -d).
  • syslog - отправка в системный журнал syslog. Параметры подключения задаются в секции syslog.
• file - абсолютный или относительный путь к файлу для записи событий журнала. Используется только при to: file. При запуске модуля API в фоновом режиме и пустом значении параметра в качестве файла записи используется server.jsonl.
• format - формат вывода событий. Принимаемые значения:
  • plain - простой текстовый формат. Используется по умолчанию при to: stderr и to: file.
  • json - структурированный формат JSON. Используется по умолчанию при to: syslog.
• nonblock - включает или выключает неблокирующий режим записи журнала. В неблокирующем режиме данные отправляются в буфер и приложение не ждет завершения записи в журнал. В этом режиме данные могут быть потеряны, если буфер переполнен. Принимает значения:
  • false - неблокирующий режим выключен. Пока данные не записаны в журнал, приложение не продолжает работу. Используется по умолчанию.
  • true - неблокирующий режим включен. Значение параметра используется системой при:
    • to: file - система записывает события журнала в файл через буфер diode, который допускает потерю событий при переполнении.
    • to: syslog + server: unix - система переводит подключение на канал unixgram, работающий без установки соединения, и отбрасывает события при переполнении очереди ядра. Значение параметра игнорируется системой, и при загрузке конфигурации и запуске системы журналирования выводится предупреждение об этом, если:
    • to: stderr - буфер отсутствует, и события журнала выводятся мгновенно.
    • to: syslog + server: udp - для подключения по udp неблокирующий режим всегда принудительно включен.
    • to: syslog + server: tcp / server: tcp+tls - для подключения по tcp неблокирующий режим всегда принудительно выключен.
• level - уровень записи, определяющий важность события. Выбранное значение приводит к записи событий от этого значения и выше по приоритету. Принимаемые значения:
  • debug - детализированная диагностическая информация (самый низкий приоритет).
  • info - информационные сообщения о штатной работе. Используется по умолчанию.
  • warn - информация о потенциально опасных событиях, при которых работа приложения продолжается.
  • error - информация о серьезных ошибках, требующих внимания.
  • dpanic - информация о панике в режиме разработки.
  • panic - критическая ошибка, при которой приложение регистрирует панику и может завершить работу.
  • fatal- фатальная ошибка, которая привела к аварийной остановке приложения.
• syslog - параметры записи событий в системный журнал syslog. Используются только при to: syslog:
  • server - URL-адрес получателя событий журнала. Поддерживаемые типы подключения:
    • unix - например, unix:/dev/log. Тип канала регулируется параметром nonblock:
      • при nonblock: false используется канал unix.
      • при nonblock: true используется канал unixgram, работающий в режиме без установления соединения.
    • udp - например, udp://host:514.
    • tcp - например, tcp://host:514.
    • tcp+tls - например, tcp+tls://host:6514.
  • identity - идентификатор приложения. Значение по умолчанию: message-queue-ee.
  • facility - категория источника записи события для сохранения в системном журнале. Принимает значения:
    • kern - ядро системы.
    • user - пользовательские процессы.
    • mail - почтовые службы.
    • daemon - фоновая служба.
    • auth - служба авторизации.
    • syslog - внутренние сообщения журнала.
    • lpr - системы печати.
    • news - новостные серверы (NNTP).
    • uucp - UUCP-подсистема.
    • cron - планировщик задач.
    • authpriv - привилегированные сообщения безопасности.
    • ftp - FTP-серверы.
    • local0...local7 - пользовательские приложения. Значение по умолчанию: local7.
  • tls - параметры TLS. Используются только при схеме tcp+tls:
    • ca_file - абсолютный или относительный путь к файлу с сертификатами доверенных удостоверяющих центров.
    • cert_file - абсолютный или относительный путь к файлу с публичным сертификатом TLS (public_key).
    • key_file - абсолютный или относительный путь к файлу с закрытым (приватным) ключом.
    • server_name - имя сервера для проверки сертификата (SNI).
    • insecure_skip_verify - отключение проверки сертификата сервера. Значение по умолчанию: false.

Пример настройки записи событий журнала в файл:

 
log:  to: file  file: log.jsonl  format: json  level: info  nonblock: false

Пример настройки отправки событий в системный журнал syslog:

 
log:  to: syslog  level: info  syslog:    server: "unix:/dev/log"                    # также: udp://host:514 | tcp://host:514 | tcp+tls://host:6514    identity: "message-queue-ee"    facility: "local7"    tls:                                       # только для схемы tcp+tls      ca_file: /etc/ssl/syslog-ca.pem      cert_file: /etc/ssl/syslog-client.pem      key_file: /etc/ssl/syslog-client.key      server_name: ""      insecure_skip_verify: false

Для резервного копирования данных TQE(MQ) необходимо выполнить процедуру бэкапа ядра (кластерного приложения) c помощью инсталлятора Ansible Tarantool Enterprise.

Поскольку объем памяти, доступный для хранения сообщений, ограничен местом на диске, может потребоваться удаление ненужных сообщений. Для периодической очистки очереди сообщений TQE(MQ) использует модуль expirationd. Соблюдение условий для удаления сообщений контролируется функцией удержания сообщений (data retention).

Функция удержания работает согласно установленной политике очистки ненужных сообщений (policy) . Политика может быть включена (policy: cleanup) или отключена (policy: disabled).

При включенной политике сообщения удаляются в зависимости от параметров:

• time - допустимое время жизни сообщения в очереди (в секундах). Значение 0 или отсутствие параметра отключает проверку, сообщения могут находиться в очереди неограниченно долго.
• length - допустимая длина очереди. Значение 0 или отсутствие параметра отключает проверку — длина очереди не ограничена.
• consumers_required - включает очистку по прочитанным сообщениям. При включенной очистке политика сравнивает указанное значение с количеством персистентных подписчиков:
  • Если количество персистентных подписчиков не меньше значения сonsumers_required, то сообщение будет удалено только после того, как его прочтут все персистентные подписчики.
  • Если количество персистентных подписчиков меньше значения сonsumers_required, то сообщение не будет удалено очисткой по прочитанным сообщениям.
  • При consumers_required: 0 и наличии персистентных подписчиков очистка ожидает прочтения сообщения всеми подписчиками.
  • При consumers_required: 0 и отсутствии персистентных подписчиков все сообщения считаются прочитанными и удаляются сразу.

Политика очистки и смежные параметры настраиваются в разделе retention роли roles.tqe-storage. Раздел retention можно настраивать как на глобальном уровне, так и на уровне отдельной очереди. При расхождении параметров приоритет имеет настройка отдельной очереди. Подробнее о настройках раздела retention смотрите в документации по expirationd.

По умолчанию конфигурация для всех очередей выглядит так:

 
roles_cfg:  roles.tqe-storage:    retention:      time: 3153600000             # Допустимое время жизни сообщений всех очередей в секундах.      length: 0                    # Проверка на максимальную длину очереди не выполняется      policy: cleanup              # Политика очистки включена.      options:                     # Конфигурационные параметры для expirationd.start.        iteration_delay: 0         # Максимальное время в секундах для fiber.sleep между итерациями.

Переопределить конфигурацию для определенной очереди можно, указав раздел retention с отличными значениями параметров в разделе конфигурации конкретной очереди example_queue:

 
roles_cfg:  roles.tqe-storage:    queues:      - name: example_queue        retention:          time: 100                  # Допустимое время жизни сообщений конкретной очереди в секундах.          length: 1000               # Максимальная длина очереди указана.          policy: cleanup            # Политика очистки включена.          consumers_required: 2      # Количество постоянных подписчиков, после прочтения которыми сообщение может быть удалено.          options:            tuples_per_iteration: 512

Следующий пример конфигурации позволяет:

• Настроить глобальное время удержания сообщений во всех очередях в 120 секунд и указать максимальную длину очереди в 1024 сообщения.
• Для очереди input:
  • Переопределить время удержания - 60 секунд.
  • Увеличить максимальную длину очереди до 2048 сообщений.
• Для вызова expirationd.start:
  • Указать опцию full_scan_time.
• Для очереди output:
  • Отключить очистку очереди от устаревших сообщений.

При такой конфигурации раздел роли roles.tqe-storage выглядит так:

 
roles_cfg:  roles.tqe-storage:    retention:      time: 120      length: 1024    queues:      - name: input        retention:          time: 60          length: 2048          options:            full_scan_time: 1024      - name: output        retention:          policy: disabled # Политика очистки отключена.

Получение сообщений в TQE(MQ) возможно только при наличии подписки.

Для получения подписки выполните запрос SubscriptionRequest без указания consume_id.

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

Для получения персистентной подписки выполните запрос SubscriptionRequest с указанием параметра consume_id.

С каждым сообщением персистентным подписчикам приходит значение параметра cursor, соответствующее позиции сообщения в очереди. Значение cursor критически важно при восстановлении состояния подписки после отключения.

Восстановить состояние подписки можно при переподключении. Для этого после отключения выполните запрос SubscriptionRequest с теми же значениями параметров queue, routing_key, sharding_key, consume_id, которые использовались при инициализации подписки. В запросе обязательно укажите параметр cursor, который использовался непосредственно перед отключением.

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

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

После перезапуска сервер теряет состояние в памяти. Необходимо переподключиться и отправить запрос SubscriptionRequest, включающий consume_id и cursor последнего полученного сообщения. Сервер автоматически восстанавливает состояние из персистентного хранилища и возобновляет передачу сообщений.

При перезапуске реплики gRPC-сервер автоматически обнаруживает сбой, выбирает другую доступную реплику и возобновляет обработку запросов с последней известной позиции.

После переключения на новую мастер-реплику gRPC-сервер автоматически устанавливает соединение и проверяет состояние подписок. Состояние персистентных подписок полностью восстанавливается на новой реплике.

Встроенный инструментарий TQE(MQ) предоставляет метрики для оценки работы с сообщениями в очередях.

Эти метрики предоставляют диагностическую информацию для использования в стороннем ПО.

Метрики модулей предоставляются в формате Prometheus.

Метрики ядра TQE(MQ) соответствуют стандартному набору метрик tarantool. Перечень метрик приведен в справочнике метрик Tarantool.

Метрики доступны по HTTP-адресу:

 
$ curl localhost:8081/metrics

Пример частичного вывода метрик:

 
# HELP tnt_vinyl_disk_index_size Amount of index stored in files# TYPE tnt_vinyl_disk_index_size gaugetnt_vinyl_disk_index_size{alias="app"} 0# HELP tnt_read_only Is instance read only# TYPE tnt_read_only gaugetnt_read_only{alias="app"} 0# HELP tnt_vinyl_disk_data_size Amount of data stored in files# TYPE tnt_vinyl_disk_data_size gaugetnt_vinyl_disk_data_size{alias="app"} 0...

Метрики ядра предоставляют следующую диагностическую информацию, специфичную для TQE(MQ):

• mqee_tnt_duplicates_total – счетчик дубликатов.
• mqee_tnt_latency_seconds - время выполнения стадии обработки сообщения в модуле ядра:
  • point - стадия обработки сообщений. Может принимать значения:
    • publish-request-tnt-storage-persisted
    • broadcast-request-tnt-storage-persisted
  • queue - название очереди.
  • routing_key - значение параметра routing_key обрабатываемого сообщения ("" для пакетных запросов).
  • result - результат выполнения стадии:
    • success - стадия завершилась успешно.
    • fail - стадия завершилась с ошибкой.
• mqee_tnt_pollers_total - индикатор текущего количества поллеров:
  • queue - название очереди.
• mqee_tnt_consumer_lag_ms - отставание потребителя (в миллисекундах):
  • queue - название очереди.

Метрики модуля API доступны на HTTP-адресе /metrics:

 
$ curl localhost:18184/metrics

Ожидаемый ответ содержит перечень метрик, отражающих текущее состояние модуля API. Пример частичного вывода метрик модуля API:

 
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.# TYPE go_gc_duration_seconds summarygo_gc_duration_seconds{quantile="0"} 5.3002e-05go_gc_duration_seconds{quantile="0.25"} 7.574e-05go_gc_duration_seconds{quantile="0.5"} 9.047e-05go_gc_duration_seconds{quantile="0.75"} 0.000111856go_gc_duration_seconds{quantile="1"} 0.000338263go_gc_duration_seconds_sum 1.305067544go_gc_duration_seconds_count 11608...

Метрики модуля API предоставляют следующую диагностическую информацию:

• mqee_grpc_publishing_request_messages - гистограмма сообщений, опубликованных в очередь:
  • grpc_method - название удаленной процедуры.
  • queue - название очереди.
  • routing_key - значение параметра routing_key, по которому выполняется публикация ("" для пакетных запросов).
  • result - результат публикации:
    • success - сообщения успешно опубликованы.
    • fail - сообщения не опубликованы.
• mqee_grpc_requests_size_bytes_total - счетчик общего размера запросов в байтах:
  • grpc_method - название удаленной процедуры.
  • queue - название очереди.
  • routing_key - значение параметра routing_key обрабатываемого сообщения ("" для пакетных запросов).
• mqee_grpc_subscribers_count - индикатор текущего количества подписчиков:
  • queue - название очереди.
  • routing_key - значение параметра routing_key, по которому выполнена подписка.
• mqee_grpc_app_info - информация об очереди (mqee_grpc_app_info{app_name="MESSAGE_QUEUE_EE_API",app_version="test"} 1).
• mqee_grpc_gomaxprocs - индикатор текущего значения GOMAXPROCS.
• mqee_grpc_tuples_received - гистограмма количества сообщений, полученных от ядра или из кэша. Включает mqee_grpc_tuples_received_sum (суммарное количество полученных сообщений) и mqee_grpc_tuples_received_count (число запросов на получение сообщений в ядро или кэш):
  • queue - название очереди.
  • routing_key - значение параметра routing_key, по которому выполнена подписка.
• mqee_grpc_sent_messages - гистограмма количества сообщений, отправленных потребителям gRPC-сервером. Включает mqee_grpc_sent_messages_sum (суммарное количество отправленных сообщений) и mqee_grpc_sent_messages_count (число отправленных ответов):
  • queue - название очереди.
  • routing_key - значение параметра routing_key, по которому выполнена подписка.
• grpc_server_started_total - счетчик полученных запросов на удаленную процедуру:
  • grpc_type - тип подключения (unary, client_stream, server_stream, bidi_stream).
  • grpc_service - название gRPC-сервиса.
  • grpc_method - название процедуры:
    • Produce
    • ProduceStream
    • Broadcast
    • ServerReflectionInfo
    • Subscribe
• grpc_server_handled_total - счетчик завершенных удаленных процедур:
  • grpc_type - тип подключения (unary, client_stream, server_stream, bidi_stream).
  • grpc_service - название gRPC-сервиса.
  • grpc_method - название процедуры (см. список в grpc_server_started_total).
  • grpc_code - код ответа gRPC-код.
• grpc_server_msg_received_total - счетчик полученных сообщений:
  • grpc_type - тип подключения (unary, client_stream, server_stream, bidi_stream).
  • grpc_service - название gRPC-сервиса.
  • grpc_method - название процедуры (см. список в grpc_server_started_total).
• grpc_server_msg_sent_total - счетчик отправленных сообщений:
  • grpc_type - тип подключения (unary, client_stream, server_stream, bidi_stream).
  • grpc_service - название gRPC-сервиса.
  • grpc_method - название процедуры (см. список в grpc_server_started_total).
• grpc_server_handling_seconds - гистограмма обработки gRPC-вызова (в секундах):
  • grpc_type - тип подключения (unary, client_stream, server_stream, bidi_stream).
  • grpc_service - название gRPC-сервиса.
  • grpc_method - название процедуры (см. список в grpc_server_started_total).
• go_gc_duration_seconds - сводная информация о длительности паузы на цикл сборки мусора в среде Go. Используемый диапазон (в секундах): 0, 0.25, 0.5, 0.75, 1.
• go_goroutines - индикатор текущего количества goroutine.
• go_info - информация о версии окружения Go.
• go_memstats - набор метрик для отслеживания использования памяти средой выполнения Go.
• go_threads - индикатор текущего количества потоков (threads) операционной системы, используемых средой выполнения Go.
• mqee_grpc_processing_time - время выполнения стадии обработки сообщения в модуле API:
  • point - стадия обработки сообщений. Может принимать значения:
    • produce-request-received
    • broadcast-request-received
    • produce-request-validated
    • broadcast-request-validated
    • produce-request-persisted
    • broadcast-request-persisted
    • subscribe-notifications-sent
  • queue - название очереди.
  • routing_key - значение параметра routing_key обрабатываемого сообщения (пустая строка, если сообщение без routing_key).
  • result - результат выполнения стадии:
    • success - стадия завершилась успешно.
    • fail - стадия завершилась с ошибкой.

Экспорт метрик компонентов TQE(MQ) осуществляется с помощью роли roles.metrics-export.

Для настройки экспорта метрик в Graphite укажите graphite в качестве цели роли и задайте следующие параметры:

• prefix - префикс для экспорта метрик в формате <prefix>.<metric_name>.
• host - IP-адрес сервера Graphite.
• port - номер порта сервера Graphite.
• send_interval - периодичность отправки метрик на сервер Graphite (в секундах). Необязательный параметр.

После настройки указанная цель получает все метрики компонентов TQE(MQ).

Пример настройки роли roles.metrics-export для экспорта метрик в Graphite:

 
roles_cfg:  roles.metrics-export:    graphite:    - prefix: 'tqe'      host: '127.0.0.1'      port: 2003      send_interval: 1    - prefix: 'master'      host: '127.0.0.2'      port: 4444

Используя роль roles.metrics-export, можно настроить предоставление метрик в формате Prometheus:

 
roles_cfg:    roles.metrics-export:        http:        - listen: 8081          endpoints:          - format: prometheus            path: '/metrics'

Больше информации о роли roles.metrics-export см. по ссылке.

Для мониторинга TQE(MQ) можно использовать базовый дашборд Tarantool Queue Enterprise (MQ) Overview. Дашборд находится в архиве поставки проекта, в директории ./monitoring. Для запуска дашборда необходимо выполнить команду:

 
docker compose -f ./monitoring/docker-compose.yml up -d

В базовый дашборд включены следующие группы панелей:

• gRPC server queue info - общее состояние очереди: количество сообщений, объем в байтах.
• Tarantool queue info - состояние очереди со стороны Tarantool: число задач в спейсе, время жизни сообщений, данные о дедупликации.
• gRPC server queue detailed info - детализация по каждой очереди: глубина, скорость приема и выдачи, задержка операций.
• gRPC server requests - интенсивность и длительность gRPC-вызовов, распределение по статусам и методам.
• gRPC server Go runtime - метрики среды выполнения Go для компонентов, реализованных на Go.
• gRPC server process info - системные метрики процесса: CPU, память и пр.
• Tarantool cluster overview - общая информация о кластере: состояние экземпляров, нагрузка, память, статус конфигурации, режим read-only и выборы лидера.
• Tarantool replication overview - информация о репликации: задержка, состояние, статистика синхронной очереди.
• Tarantool network activity - сетевая активность экземпляров: входящий/исходящий трафик, соединения, детализация запросов и потребление памяти.
• Tarantool memtx allocation overview - память memtx: выделение памяти для кортежей и индексов, краткая инструкция по мониторингу.
• Tarantool MVCC overview - статистика менеджера транзакций движка memtx.
• Tarantool space statistics - статистика по спейсам: количество кортежей, объем данных, операции чтения/записи, фрагментация.
• Tarantool vinyl statistics - память и дисковое пространство vinyl, планировщик и статистика транзакций.
• Tarantool CPU statistics - загрузка процессора по экземплярам (пользовательское и системное время).
• Tarantool runtime overview - метрики рантайма: память Lua и транзакций, статистика файберов, цикл событий.
• Tarantool LuaJit statistics - детальная информация о LuaJIT: выделение объектов, сборка мусора, потребление памяти, трассы JIT.
• Tarantool operations statistics - операции над спейсами (select, update и др.) и другие вызовы (eval, call, auth, ошибки, SQL).
• Tarantool expirationd overview - статистика задач expirationd: количество кортежей, число перезапусков, время работы.