Ошибки системы можно выявить в технических логах, которые идентифицируют внутренние события системы:
передача данных между контейнерами Docker;
взаимодействие сервисов мобильной платформы между собой;
выполнение операций над базами данных через контейнеры Docker, например: открытие, запись, закрытие базы данных.
Для централизованного логирования компонентов мобильной платформы используйте файл docker-compose.metrics.yml, а также предустановленные приложения:
fluentd. Позволяет собирать технические логи в хранилище Elasticsearch, которое встроено в «Форсайт. Мобильная платформа»;
Kibana. Позволяет получать и экспортировать информацию о технических логах в файл *.csv.
Для выявления ошибок системы в технических логах:
Включите логирование компонентов мобильной платформы на кластере, если при установке продукта «Форсайт. Мобильная платформа» развёрнут кластер на основе Kubernetes, Deckhouse или OKD/OCP.
Получите список технических логов одним из способов:
с помощью команды:
kubectl logs -n <пространство имён сервера мобильной платформы> <наименование пода>
в приложении Kibana. Для получения подробной информации обратитесь к подразделу «Просмотр технических логов».
После выполнения действий в списке технических логов могут содержаться ошибки.
Для определения возможной причины возникновения ошибки выделяются следующие признаки классификации ошибок:
Признак | Описание | Возможная причина |
Разрыв соединения | После отправки запроса к серверу мобильной платформы возвращается ошибка «504» или «499». Ответ, содержащий запрашиваемые данные, не приходит. | Некорректные таймауты или недостаточный объём потребления ресурсов центрального процессора (CPU) и оперативной памяти (RAM) |
Зависание соединения | После отправки запроса к серверу мобильной платформы соединение остаётся открытым и не закрывается в течение продолжительного времени. Ответ, содержащий запрашиваемые данные, не приходит. | Недоступен источник данных |
Недоступность сервера мобильной платформы | Периодически или постоянно не отправляется запрос к серверу мобильной платформы. | Недоступен сервер мобильной платформы |
Для диагностики и устранения ошибок используйте следующие приложения:
Grafana. Позволяет анализировать объём потребления системных ресурсов (шаг 2);
OKD. Позволяет анализировать работу кластера на основе OKD/OCP (шаги 2, 3, 4, 6);
Kibana. Позволяет анализировать статистическую информацию о системе с помощью визуального представления данных (шаг 7).
Порядок выполнения действий отсортирован от простого к сложному. При необходимости порядок может быть изменён:
Отфильтруйте журнал с системными логами по статусу «Ошибка» в разделе «Системные логи». При необходимости укажите диапазоны дат и время начала/окончания событий.
Проверьте объём потребления ресурсов центрального процессора (CPU) и оперативной памяти (RAM) контейнерами и узлами кластера. Для этого обратитесь к подразделам:
«Просмотр объёма потребления системных ресурсов контейнерами» в OKD. Актуально для кластера OKD/OCP;
«Просмотр объёма потребления системных ресурсов контейнерами» в Grafana. Актуально для кластера Kubernetes, Deckhouse или OKD/OCP;
«Просмотр объёма потребления системных ресурсов узлами кластера» в Grafana. Актуально для кластера Kubernetes, Deckhouse или OKD/OCP.
Совет. Оптимальный объём потребления ресурсов CPU и RAM не должен превышать 70%.
Проверьте работу подов на каждом узле кластера OKD/OCP. Для этого обратитесь к подразделу «Проверка работы подов на каждом узле кластера и аудит их логов» в OKD.
Проверьте доступ к источнику данных при использовании кластера OKD/OCP. Для этого обратитесь к подразделу «Проверка доступа к источнику данных» в OKD.
Проверьте таймауты на прокси-сервере и фреймворке, а также установленные таймауты:
на прокси-сервере до кластера;
на кластере (Ingress Controller);
на источнике данных.
Примечание. Таймауты должны соответствовать реальному времени выполнения запроса.
Проанализируйте события кластера OKD/OCP. Для этого обратитесь к подразделу «Проверка событий кластера» в OKD.
Проанализируйте статистическую информацию о системе с помощью визуального представления данных. Для этого обратитесь к подразделу «Просмотр статистической информации о системе» в Kibana.
Восстановление системы производится при возникновении следующих аварийных ситуаций:
Недоступен сервер мобильной платформы. Данная ситуация характеризуется сбоями при аутентификации пользователя API и недоступностью консоли администратора в браузере. Для получения подробной информации обратитесь к разделу «Восстановление доступности сервера мобильной платформы»;
Недоступна среда. Данная ситуация характеризуется сбоями при аутентификации пользователя API и отсутствием добавленной ранее среды в консоли администратора. Для получения подробной информации обратитесь к разделу «Восстановление доступности среды»;
Недоступен проект в среде. Данная ситуация характеризуется сбоями при аутентификации пользователя API и отсутствием добавленного ранее проекта в консоли администратора. Для получения подробной информации обратитесь к разделу «Восстановление доступности проекта в среде»;
Некорректная работа кэширования данных. Данная ситуация характеризуется отображением неактуальных данных на мобильных устройствах пользователей относительно источника данных, нерабочей кнопкой «Обновить» при просмотре сохранённых кэшей по параметрам, ошибками и зависанием системы в процессе обновления кэша, неизменной версией кэша при успешном обновлении. Для получения подробной информации обратитесь к разделу «Восстановление работы кэширования данных»;
Некорректное взаимодействие сервера мобильной платформы с внешней LDAP-системой. Данная ситуация характеризуется сбоями при аутентификации пользователей из каталога LDAP. Для получения подробной информации обратитесь к разделу «Восстановление взаимодействия сервера мобильной платформы с внешней LDAP-системой»;
Некорректное ведение журнала с системными логами. Данная ситуация характеризуется отсутствием последних записей о событиях в разделе «Системные логи». Для получения подробной информации обратитесь к разделу «Восстановление ведения журнала с системными логами»;
Сбой в работе виртуальной машины, которая используется сервером мобильной платформы. Данная ситуация характеризуется недоступностью аутентификации пользователей API и консоли администратора в браузере. Для получения подробной информации обратитесь к разделу «Восстановление работы виртуальной машины»;
Некорректная работа консоли администратора. Данная ситуация характеризуется отсутствием ответных действий после нажатия кнопок в консоли администратора. Для получения подробной информации обратитесь к разделу «Восстановление работы консоли администратора»;
Недоступна консоль администратора. Данная ситуация характеризуется возникновением ошибки «403» при открытии консоли администратора по протоколу HTTPS. Для получения подробной информации обратитесь к разделу «Восстановление доступности консоли администратора»;
Примечание. Актуально только для продукта «Форсайт. Мобильная платформа» версии 23.12.
Недоступна реплика базы данных. Данная ситуация характеризуется увеличением времени или отсутствием ответа от базы данных при выполнении запросов на чтение, состоянием пода базы данных. Для получения подробной информации обратитесь к разделу «Восстановление доступности реплики базы данных». Пример восстановления доступности реплики базы данных приведён для кластера OKD/OCP;
Некорректная работа узлов кластера OKD/OCP после их перезапуска. Данная ситуация характеризуется отсутствием отображения количества контейнеров подов, выделенной памяти, получением ошибки «/var/run/openvswitch/db.sock: connection attempt failed (No such file or directory)» при запуске сервиса opensvwitch. Проблема может быть связана с некорректным выключением узла кластера и возникновением ошибки на дисковой подсистеме. Для решения проблемы переустановите узел кластера. В дальнейшем для предотвращения такого поведения выключайте узлы кластера в соответствии с инструкцией из документации на приложение OKD.
Для резервного копирования и восстановления системы обратитесь к разделу «Резервное копирование и восстановление системы».
См. также: