Устранение ошибок
Введение
Цель документа
Обеспечить лучшее понимание сохранения функциональности механизма обработки данных в системе Accelera, представить ключевые моменты мониторинга и возможности Accelera для предотвращения сбоев и реагирования на нештатные ситуации.
Возможности мониторинга
Система Accelera может быть исследована с помощью двух взаимодополняющих элементов: логи системы, а также мониторинг системой Prometheus.
Логи системы могут быть собраны и проанализированы отдельной системой мониторинга (например logstash). Каждый компонент системы ведет журнал, который обычно помогает определить причину любого сбоя. Подробнее о работе с логированием Accelera.
Мониторинг системой Prometheus охватывает внутреннюю работу компонентов, позволяя анализировать потребление CPU, памяти, задержку внутреннего цикла событий. Подробнее о мониторинге см. здесь.
Архитектура системы
В обзоре основных компонентов системы можно ознакомиться с задачами каждого компонента, а также схему подключения компонент между собой.
В документе приведен обзор основных ошибок каждого компонента, их устранение и способы как избежать повторения таких ситуаций.
Структура лог-файла
Каждый компонент ведет свой независимый журнал. Для просмотра журнала всех компонент введите команду
docker-compose -f <путь к compose-файлу> logs -f --tail NГде N - количество последних строк, которые нужно вывести на экран. Вы получите вывод системных сообщений по всем компонентам. Лог отдельного компонента можно просматривать, если добавить к команде выше название сервиса:
docker-compose -f <путь к compose-файлу> logs -f --tail N <имя сервиса, например flows_engine>Журнал имеет примерно следующий вывод:
flows_actions | [06-11-2022 14:22:00.759] actions-/ INFO: Node 'flows-timers' connected.
flows_actions | [06-11-2022 14:22:00.760] actions-/ INFO: Node 'event-handler' connected.
flows_actions | [06-11-2022 14:22:00.761] actions-/ INFO: Node 'gateway' connected.
flows_engine | [06-11-2022 14:22:00.849] engine-a08ab0f596a3 INFO: '$node' service is registered.
flows_engine | [06-11-2022 14:22:00.849] engine-a08ab0f596a3 INFO: Service '$node' started.
flows_engine | [06-11-2022 14:22:00.850] engine-a08ab0f596a3 INFO: ✔ ServiceBroker with 1 service(s) is started successfully in 947ms.
flows_actions | [06-11-2022 14:22:00.855] actions-/ INFO: Node 'telegram-enginea08ab0f596a3' connected.
flows_timers | [06-11-2022 14:22:00.855] INFO: Node 'telegram-enginea08ab0f596a3' connected.
flows_engine | [06-11-2022 14:22:00.856] engine-a08ab0f596a3 INFO: Node 'telegram-enginea08ab0f596a3' connected.
flows_backoffice | [06-11-2022 14:22:00.856] INFO: Node 'telegram-enginea08ab0f596a3' reconnected.
flows_backoffice | [06-11-2022 14:22:00.858] INFO: Node 'telegram-enginea08ab0f596a3' reconnected.
flows_engine | [06-11-2022 14:22:00.869] engine-a08ab0f596a3 INFO: '$node' service is registered.
flows_engine | [06-11-2022 14:22:00.869] engine-a08ab0f596a3 INFO: 'triggers' service is registered.
flows_engine | [06-11-2022 14:22:00.869] engine-a08ab0f596a3 INFO: Service '$node' started.
flows_engine | [06-11-2022 14:22:00.869] engine-a08ab0f596a3 INFO: Service 'triggers' started.
flows_engine | [06-11-2022 14:22:00.870] engine-a08ab0f596a3 INFO: ✔ ServiceBroker with 2 service(s) is started successfully in 784ms.
flows_engine | [06-11-2022 14:22:00.874] engine-a08ab0f596a3 INFO: Node 'engine-a08ab0f596a3' connected.
flows_timers | [06-11-2022 14:22:00.874] INFO: Node 'engine-a08ab0f596a3' connected.
flows_actions | [06-11-2022 14:22:00.875] actions-/ INFO: Node 'engine-a08ab0f596a3' connected.
flows_backoffice | [06-11-2022 14:22:00.874] INFO: Node 'engine-a08ab0f596a3' reconnected.
flows_backoffice | [06-11-2022 14:22:00.874] INFO: Node 'engine-a08ab0f596a3' reconnected.В самом начале каждой строки указан сервис, в котором идет логирование. Далее - дата записи сообщения, затем идет уровень логирования (TRACE, DEBUG, INFO, WARN, ERROR, FATAL). У flows_engine и flows_actions перед уровнем логирования добавляется id контейнера, т.к. эти сервисы могут быть запущены во множестве экземпляров. Затем в логе идет само сообщение.
Сбой компонент
Ниже приведена таблица с описанием последствий выхода из строя конкретного компонента. Несмотря на критичность ситуации в зависимости от использования системы (real-time обработка событий, использование того или иного функционала) последствия сбоя того или иного компонента может оказать разное влияние на обработку данных.
| Компонент | Последствия выхода из строя |
|---|---|
| flows_frontend | Невозможность открыть интерфейс системы и изменить настройки. Если сбой затронул только данный компонент, то штатная обработка данных продолжится, но открыть интерфейс системы не получится. |
| flows_backoffice | Пользователи не смогут войти в систему, сохранять изменения и тд. Также модуль управляет расписанием кампаний, то есть при выходе из строя этого модуля кампании по расписанию не будут запускаться. |
| flows_engine | Обработка real-time событий будет остановлена, все поступающие события будут накапливаться в брокере. |
| flows_actions | Все действия в real-time сценариях не будут выполняться пока модуль отключен. |
| flows_cache | Аудитории, которые должны быть закэшированы в оперативной памяти для работы real-time сценариев не будут обновляться. |
| flows_bulk | Все аналитические события перестанут сохраняться в аналитическую БД. Также в модуле идет периодическое сохранение данных по сценариям в Redis, это также будет недоступно. |
| flows_timers | Все новые таймеры, которые создаются в момент простоя компонента не будут созданы (будут созданы позднее, при запуске). Также таймеры, которые должны были быть исполнены во время простоя не будут выполнены. Касается real-time сценариев. |
| flows_segments | Выполнение кампаний будет остановлено. Не будет возможности запустить как тестовые запуски кампаний, так и боевые. |
Устранение ошибок
Ошибки поделены на несколько основных частей, начиная от ошибок при установке и запуске, далее - ошибки во время выполнения, сортированные по критичности. В завершение - ошибки и предупреждения, которые не ведут к критичным сбоям, но должны быть исправлены или проигнорированы.
Основные ошибки при установке и запуске
Отсутствует образ в системе
| Компонента | Все |
| Симптом | ERROR: repository … not found: name unknown: Repository … not found Или docker.io connection timeout |
| Решение | Убедитесь, что для соответствующего компонента указан правильный образ в docker-compose файле (параметр image) |
| Совет | Доступные образы в системе можно проверить командой docker images, убедитесь, что запрашиваемый вами образ загружен. |
Ошибка подключения к Redis
| Компонента | Все |
| Симптом | ERROR: Operational DB exception: Error: getaddrinfo ENOTFOUND <host> Или Operational DB exception: Error: connect ECONNREFUSED 127.0.0.1:6379 |
| Решение | Приложение не может присоединиться к операционной БД Redis, убедитесь, что она доступна по указанному адресу. |
| Совет | Если Redis установлен локально, ознакомьтесь со статьей особенности подключения к Redis. Данная информация также актуальна, если компоненты Clickhouse или RabbitMQ установлены локально. |
Ошибка подключения к Broker
| Компонента | Все |
| Симптом | Connection to broker error OperationalError: connect ECONNREFUSED 127.0.0.1:5672 |
| Решение | Приложение не может присоединиться к брокеру RabbitMQ, убедитесь, что он доступен по указанному адресу. |
| Совет | Если компонент Broker установлен локально убедитесь, что сервис находится в одной сети с компонентой или у него активен режим network_mode: “host”. |
Ошибка авторизация в Broker
| Компонента | Все |
| Симптом | Connection is failed. Handshake terminated by server: 403 (ACCESS-REFUSED) with message "ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN. For details see the broker logfile.” ИЛИ Connection to broker error { err: OperationalError: Handshake terminated by server: 403 (ACCESS-REFUSED)… |
| Решение | Broker доступен, но приложение передает неверный логин/пароль. |
| Совет | Проверьте корректность пары логин/пароль или создайте нового пользователя согласно инструкции. |
Ошибка подключения к Clickhouse
| Компонента | Все |
| Симптом | ERROR: connect ECONNREFUSED 127.0.0.1:8123 |
| Решение | Приложение не может присоединиться к БД Clickhouse, убедитесь, что она доступна по указанному адресу. |
| Совет | Если компонент Clickhouse установлен локально убедитесь, что сервис находится в одной сети с компонентой или у него активен режим network_mode: “host”. |
Ошибка открытия порта
| Компонента | Все |
| Симптом | Bind for 0.0.0.0:3020 failed: port is already allocated |
| Решение | При запуске один из компонент пытается открыть порт, занятый другим приложением. Проверьте конфигурацию открытия портов компонентами. |
| Совет | При настройке метрик возможно пересечение портов (если не указали переменную METRICS_PORT для каждого контейнера или определили ее одинаково). Внимательно ознакомьтесь с руководством по настройке метрик для того, чтобы избежать случаев пересечения портов. |
Ошибки получения секретной информации
| Компонента | Все |
| Симптом | FATAL: Unable to create ServiceBroker. BrokerOptionsError: Invalid transporter type 'BROKER_CONNECTION'. |
| Решение | При запуске сервис пытается получить секретные данные из Docker Secret или HashiCorp Vault, однако не может этого выполнить. Ознакомьтесь с инструкцией по настройке Docker Secrets или HashiCorp Vault (в зависимости от того, какая настройка у вас активирована. |
| Совет | При настройке метрик возможно пересечение портов (если не указали переменную METRICS_PORT для каждого контейнера или определили ее одинаково). Внимательно ознакомьтесь с руководством по настройке метрик для того, чтобы избежать случаев пересечения портов. |
Ошибки во время выполнения
Нехватка оперативной памяти
Данная проблема ведет к немедленному завершению процесса (в зависимости от настройки модуль может не перезапускаться)
| Компонента | flows_engine |
| Симптом | FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory |
| Решение | Проблема возникает, когда в области оперативной памяти, выделенной приложению, отсутствует доступное место. По умолчанию приложение flows_engine занимает все доступное место на сервере. Если данных слишком много рекомендуется уменьшить объем хранимой информации (очистить данные по некоторым сценариям и тд), либо увеличить объем оперативной памяти. |
| Совет | По умолчанию сервис flows_engine запрашивает 128 Gb памяти, если такого объема на сервере нет - то в распоряжении процесса находится вся доступная память. Если вам, по каким-либо причинам, необходимо больше, свяжитесь с нами для выпуска более вместительной версии engine (эта операция входит в стандартную поддержку). |
Нехватка места на диске брокера RabbitMQ
| Компонента | Все компоненты |
| Симптом | WARN: AMQP connection is blocker. low on disk |
| Решение | При нехватке места на диске RabbitMQ начинает блокировать все входящие запросы. Таким образом страдает как коммуникация между модулями системы, так и потребление событий real-time. Для устранения ошибки очистите место на диске. Сразу после ошибки система восстановит все подключения и возобновит работу. Перезагрузка не потребуется. |
| Совет | Для избежания проблемы рекомендуется настроить мониторинг свободного места на диске используя для этого, например, node-exporter сервис для Prometheus. |
Недостаточно соединений в пуле
| Компонента | Flows Segments |
| Симптом | KnexTimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? |
| Решение | При большом количестве параллельных кампаний в сегменте вероятна ситуация нехватки свободных соединений в пуле. Для решения проблемы рекомендуется дождаться отработки текущих кампаний, определить кампании, которые не отработали (через интерфейс Accelera). Затем перезагрузить модуль сегментов, добавив максимальное количество соединений в пуле (параметр MAX_POOL). После этого выполните кампании с ошибкой повторно. |
| Совет | Для избежания проблемы рекомендуется заранее определить количество запущенных кампаний и умножить это число на 3. Например, для 60 кампаний укажите MAX_POOL = 180 или 200. |
Ошибки во время выполнения сегмента
| Компонента | flows_segments |
| Симптом | ERROR: Processing segment … error … |
| Решение | Ошибки в настройке сегмента часто ведут к возникновению ошибок во время его исполнения. Такие ошибки имеют общий шаблон, или содержат в себе коды ошибок Oracle (ORA-…). Для устранения этих ошибок необходимо исправить настройку сегмента. Пользователи видят такие ошибки в списке статусов. |
| Совет |
Ошибка синхронизации данных с Redis
| Компонента | flows_bulk |
| Симптом | ERROR: Synchronization error cause Error: Command failed with exit code 1 |
| Решение | flows_bulk с определенной периодичностью сохраняет данные состояния клиентов в сценарии и их контексты в Redis. Иногда может возникнуть ситуация сбоя подключения к Redis, приводящая к данной ошибке. Работоспособность и целостность данных остальных компонент сохраняется, но под угрозу ставится снимок данных в Redis. В этом случае необходимо убедиться, что данная ошибка не повторяется, т.е. последующие сохранения проходят успешно. В случае отсутствия повторений данной ошибки система продолжит сохранения данных. Если ошибка повторяется убедитесь, что компонент может успешно подключаться к Redis, сетевой доступ в наличие, логин и пароль подключения корректны.. |
| Совет | Переменная среды SYNC_INTERVAL отвечает за периодичность сохранения данных в Redis. По умолчанию она имеет значение - 30000 миллисекунд (30 секунд). Установите большее/меньшее значение для вашего потока данных. |
Ошибка записи данных в Clickhouse
| Компонента | flows_bulk |
| Симптом | Insert stream error cause Error: connect ECONNREFUSED 127.0.0.1:8123 Cant store clickhouse batch cause "connect ECONNREFUSED 127.0.0.1:8123” Failed batch appended to clickhouse_failed_requests.data |
| Решение | Ошибка возникает в случае недоступности clickhouse (сетевой сбой, падение компоненты и тд). В случае падения модуль flows_bulk сохраняет порцию данных, которую не смог записать, в файл /usr/src/clickhouse_failed_<table>.data. Восстановите компоненту clickhouse и система начнет сохранять данные. Обратите внимание, что файлы clickhouse_failed_*.data не будут загружены автоматически, для этого необходимо применить ручной процесс. |
| Совет | Для получения списка файлов, который нужно восстановить воспользуйтесь командойdocker exec -it <flows_bulk> ls -al /usr/srcГде <flows_bulk> - имя или ID контейнера flows_bulk. Нам необходимы файлы clickhouse_failed_* Для ручной загрузки скопируйте нужный failed-файл на диск командой docker cp <flows_bulk>:/usr/src/clickhouse_failed_<table>.data /path/to/fileГде <flows_bulk> - имя или ID контейнера flows_bulk. _Не забудьте удалить эти файлы внутри контейнера, чтобы новые возможные ошибки не добавлялись в уже скопированный файл и не приводили к появлению дубликатов. _Команда для удаления docker exec -it <flows_bulk> rm /usr/src/clickhouse_failed_<table>.data\n\nКопируйте файлы по одномуЕсли clickhouse запущен в виде контейнера: Далее скопируйте этот файл внутрь контейнера clickhouse: docker cp /path/to/file <clickhouse>:/tmp/clickhouse_failed_<table>.data\n\nГде <clickhouse> - название или ID контейнера clickhouseЗатем войдите внутрь контейнера clickhouse: docker exec -it <clickhouse> bin/bashГде <clickhouse> - также название или ID контейнера clickhouse Если clickhouse находится на отдельном сервере, скопируйте файл /path/to/file на данный сервер. Далее выполните команду cat /path/to/file | clickhouse-client —-host=<host> -—port=<port> —-user=<username> —-password=<password> —-database=<database> —-query="INSERT INTO <table> FORMAT JSONEachRow"\n\nЗатем можете удалить файлы /path/to/file |
Ошибка в репликации redis от master до replica
| Компонента | redis |
| Симптом | В логе redis встречается сообщение “psync scheduled to be closed ASAP for overcoming of output buffer limits” |
| Решение | Quickfix: повысить параметр client-output-buffer-limit на мастере: В redis-cli: config set client-output-buffer-limit "slave 4194990176 4194990176 0"В большинстве случаем этого хватит. |
| Совет | Redis master-replica — объяснение процесса синхронизации Давайте посмотрим, как выполняется процесс синхронизации: Реплика при старте или после отключения обращается к Мастеру и просит прислать ему базу данных Мастера Мастер отвечает на этот запрос и: создает дочерний процесс для создания дампа своей базы данных в файловой системе в виде файла dump.rdb В течение этого времени Мастер продолжит работу с подключенными в настоящий момент клиентами. и все данные, которые были изменены в его наборе данных во время создания дампа, будут сохранены в буфере репликации. Мастер отправляет реплике уведомление о том, что дамп готов, и реплика начинает копировать дамп по сети, чтобы сохранить его на диске хоста реплики. Ведомое устройство завершает копирование дампа, загружает его в память своего экземпляра Redis и отправляет мастеру уведомление о том, что подчиненное устройство готово обслуживать клиентов. Мастер в свою очередь проверяет свой буфер репликации и если данные есть — Мастер начинает отправлять измененные данные из буфера на реплику, чтобы она могла заменить данные в своей памяти на новые, актуализированные данные от Мастера. Реплика применяет эти изменения и начинает свою работу. |
Ошибка репликации redis от master до replica 2
| Компонента | redis |
| Симптом | В логе redis реплики встречается сообщение “Unable to partial resync with replica … for lack of backlog (Replica request was: …)” |
| Решение | Повысить параметр repl-backlog-size на мастере: В redis-cli: config set repl-backlog-size 2Gb |
| Совет | Размер параметра рассчитывайте исходя из объема поступаемых данных в redis. Самый простой вариант - посмотреть лог мастера redis и найти строки по типу RDB: 314 MB of memory used by copy-on-write Это - объем сохранения в дамп за последний период редактирования данных. Найдите максимальное значение, добавьте к нему 20% и укажите его. Если объем сложно оценить - начните с 100Mb. В случае повторения ошибки - увеличьте до 200 и тд. Имейте ввиду: этот буфер занимает место в RAM. Увеличивайте его только в случае, когда размер свободного пространства оперативной памяти позволяет это сделать. |