Журнал событий технологических ролей Tarantool¶
События в TCF журналируются для двух технологических ролей. Технологическая роль – это Lua-модуль, реализующий определенные функции или логику.
roles.tcf-worker –- переключает статусы кластеров TCF (активный-пассивный), предоставляет базовое HTTP API для управления TCF;
Основные события, записываемые в журнал:
запуск и завершение работы модуля;
изменение состояния кластера (переключение активного и пассивного);
ошибки при получении состояния кластера;
roles.tcf-coordinator – отвечает за автоматическое переключение состояния. Чтобы обеспечить отказоустойчивость, в каждом кластере должно быть запущено два и более экземпляра Tarantool с этой ролью. Смотрите также: Смена состояния кластеров;
Основные события, записываемые в журнал:
отслеживание состояния кластеров;
автоматическое переключение кластеров;
предупреждения о возможных проблемах (задержки, нестабильность соединения);
ошибки в процессе переключения кластеров.
Конфигурация журналирования¶
Здесь описаны базовые настройки для управления журналированием, включая выбор места вывода, формат сообщений и уровень детализации. Журналирование настраивается в файле конфигурации кластера в YAML (Tarantool 3.x).
log.to— настройка места, куда будут отправляться логи. Возможные значения:stderr– вывод в стандартный поток ошибок (значение по умолчанию);file– вывод записей журнала файл;log: to: file file: var/log/{{ instance_name }}/instance.log
pipe– настройка, при которой записи журнала направляются в стандартный ввод (stdin) внешней программы. Это позволяет передавать записанные в журнал данные для дальнейшей обработки или анализа в реальном времени другой программой, вместо записи их в файл или вывода на экран. Пример:log: to: pipe pipe: 'cronolog tarantool.log'
syslog– отправка логов в системный журнал для централизованного сбора и хранения;
log.file– файл для назначения записей журнала. Необходимо установитьlog.toв значение file. В противном случаеlog.fileигнорируется;log.format– формат записей в журнал (plain– текст,json– JSON-объекты). Значение по умолчанию:plain;log.level– уровень детализации записей в журнал. Значение по умолчанию:info. Возможные значения см. в разделе Уровни журналирования.Пример:
log: to: file file: var/log/{{ instance_name }}/instance.log level: verbose format: plain
Полное описание параметров журналирования см. в разделе справочнике конфигурации Tarantool.
Формат записей журнала Tarantool¶
Формат записи в журнал технологических ролей Tarantool:
2025-02-20T12:52:15Z WARN src/roles/tcf/coordinator.lua:250 "Cluster response time is high"`
\__________________/\____/\_________________________________/\____________________________/
Дата и время Уровень Источник Сообщение
события журналирования
Уровни журналирования¶
Уровни журналирования технологических ролей:
ERROR – ошибка приложения, которая не критична, но требует исправления;
WARN – предупреждения о потенциальных проблемах, которые не влияют на работу приложения, но могут потребовать внимания;
INFO – информационные сообщения о нормальной работе приложения;
VERBOSE – подробная информация о работе приложения, полезная для диагностики;
DEBUG – максимально подробная информация, включая отладочную.
Далее приведена информация об уровнях WARN и ERROR как наиболее важных для администрирования:
Уровень |
Описание |
Пример |
|---|---|---|
WARN |
Предупреждения о потенциальных проблемах |
|
ERROR |
Ошибки, требующие внимания |
|
WARN (Предупреждение)¶
События журнала уровня WARN фиксируют события, которые могут быть потенциальными проблемами, но не влияют на нормальную работу системы на данный момент.
Эти события не являются критическими, но требуют внимания, поскольку могут привести к более серьезным проблемам в будущем. Важно отслеживать такие сообщения, чтобы предотвратить возможные сбои.
Возможные ошибки:
failed to get status of %q: %s¶
Не удалось получить состояние кластера из-за проблем с подключением к хранилищу состояния кластеров.
Пример
2025-03-10 14:30:29.456 [41234] src/roles/tcf/worker.lua:162 W> failed to get status of cluster_1: <error details>
Решение
Проверьте подключение к хранилищу состояния кластеров. Убедитесь, что кластер доступен и работает.
failed to get replicas status¶
Не удалось получить статус состояния репликации для конкретного набора реплик.
Пример
2025-03-10 14:30:30.567 [41234] src/roles/tcf/worker.lua:207 W> failed to get replicas status (cluster: %q, replicaset_id: %q): <error details>
Решение
Проверьте, существует ли набор реплик с указанным ID. Убедитесь, что база данных репликаций работает корректно.
failed to lock %q path¶
Не удалось заблокировать путь для кластера, возможно, из-за проблемы с конкурентным доступом.
Пример
2025-03-10 14:30:31.678 [41234] src/roles/tcf/worker.lua:239 W> failed to lock %q path: %s: <error details>
Решение
Проверьте настройки механизма блокировки путей. Убедитесь, что блокировки не конкурируют между собой и не нарушают целостность данных. Используйте механизмы повторных попыток (retry), если путь временно заблокирован.
failed to set is_active flag¶
Не удалось установить флаг состояния is_active для кластера.
Флаг состояния is_active предназначен для получения информации о текущем состоянии кластера.
Пример
2025-03-10 14:30:39.456 [41234] src/roles/tcf/worker.lua:365 W> failed to set is_active flag to true for %q: <error details>
Решение
Проверьте, корректно ли работает компонент, отвечающий за установку флагов состояния is_active, доступность и права на запись в хранилище состояния.
failed to delete is_active flag¶
Не удалось удалить флаг состояния is_active.
Флаг состояния is_active предназначен для получения информации о текущем состоянии кластера.
Пример
2025-03-10 14:30:40.567 [41234] src/roles/tcf/worker.lua:370 W> failed to delete is_active flag for %q: <error details>
Решение
Убедитесь, что путь или ключ для флага состояния is_active доступен и не заблокирован другими процессами. Проверьте права на удаление в хранилище состояния.
failed to update cluster status¶
Не удалось обновить состояние кластера.
Пример
2025-03-10 14:30:44.901 [41234] src/roles/tcf/coordinator.lua:210 W> failed to update cluster status: <error details>
Решение
Убедитесь, что кластер доступен для обновления состояния и нет конфликтующих операций.
failed to check toggle flag¶
Не удалось проверить флаг переключения toggle.
Флаг переключения toggle предназначен для переключения статусов кластеров, которые могут находиться в одном из двух состояний: активном или пассивном.
В штатном режиме один кластер является активным, а второй – пассивным. Вызов toggle на любом из кластеров приводит к смене их состояний: текущий активный кластер становится пассивным, а текущий пассивный – активным, при условии, что оба кластера находятся в исправном состоянии и отсутствуют препятствия для смены статуса.
Пример
2025-03-10 14:30:39.456 [41234] src/roles/tcf/worker.lua:1039 W> failed to check toggle flag: %s
Решение
Проверьте подключение к хранилищу состояния кластеров.
destination must be set to perform graceful status toggle¶
Секцию destination не задана, или задана некорректно.
Пример
2025-03-10 14:30:40.567 [41234] src/roles/tcf/worker.lua:1086 W> destination must be set to perform graceful status toggle
Решение
Для выполнения плавного переключения состояния задайте секцию destination в файле конфигурации межкластерных репликаторов.
destination is not in sync¶
Возникла проблема с синхронизацией компонента Destination.
Пример
2025-03-10 14:30:41.678 [41234] src/roles/tcf/worker.lua:1098 W> destination is not in sync: %s
failed to get toggle flag¶
Не удалось получить флаг переключения toggle. См. подробнее.
Пример
2025-03-10 14:30:42.789 [41234] src/roles/tcf/worker.lua:1118 W> failed to get toggle flag: %s
Решение
Проверьте подключение к хранилищу состояния кластеров.
destination signature not found for replicaset with uuid %s“, replicaset_uuid¶
Основной цикл проверки состояния TCF координатора завершился с ошибкой.
Пример
2025-03-10 16:32:19.142 [41234] src/roles/tcf/replication.lua:22 W> destination signature not found for replicaset with uuid rs-uuid-123
Решение
Убедитесь, что узлы destination инициализированы и содержат нужный набор реплик. Проверить корректность UUID и консистентность снимков данных.
failed to get target status¶
Ошибка получения целевого статуса кластера или набора реплик.
Пример
2025-03-10 13:22:16.142 [41234] src/roles/tcf/replication.lua:90 W> failed to get "cluster_1" target status
Решение
Проверьте подключение к хранилищу состояния кластеров.
failed to promote¶
Ошибка при попытке повысить приоритет кластера (promote), например, при восстановлении после отказа (failover).
Пример
2025-03-10 16:32:19.142 [41234] src/roles/tcf/replication.lua:22 W> failed to promote: %s'
Решение
Процедура promote может завершиться с ошибкой, если кластер нездоров или отсутствует доступ к хранилищу. Проверьте состояние кластера и доступность хранилища состояний.
ERROR (Ошибка)¶
Записи журнала уровня ERROR фиксируют более серьезные события, которые влияют на функциональность системы. Это проблемы, которые могут препятствовать выполнению определенных операций, однако система в целом может продолжать работать, несмотря на ошибки. Эти события требуют немедленного внимания и могут потребовать вмешательства для их устранения.
Возможные ошибки:
failed to set status¶
Ошибка при установке состояния для набора реплик или кластера.
Пример
2025-03-10 14:30:35.012 [41234] src/roles/tcf/worker.lua:283 E> failed to set status (cluster: %q, replicaset_id: %q) with value %q: <error details>
TCF coordinator health check loop failed: %s“, err¶
Основной цикл проверки состояния TCF координатора завершился с ошибкой.
Пример
2025-03-10 14:30:39.142 [41234] src/roles/tcf/coordinator.lua:69 E> TCF coordinator health check loop failed: %s
Решение
Кластер нездоров. Например, в каком-то из набора реплик хранилищ отсутствует мастер.
TCF system check failed(cluster: %q, replicaset_id: %q)¶
Фоновая проверка системного состояния завершилась ошибкой.
Пример
2025-03-10 14:30:39.142 [41234] src/roles/tcf/coordinator.lua:69 E> TCF coordinator health check loop failed: %s
Прочитайте сообщение ошибки в записи журнала и исправьте ее.