Важная информация для понимания логики работы логов:
Каждую ночь текущие (с только что прошедшего дня) файлы логов изменяют своё название (к ним добавляется дата), и создаются новые файлы логов. Причём ко вчерашним логам добавляется СЕГОДНЯШНЯЯ дата. То есть, чтобы прочитать, например requests.log за 10 октября нужно смотреть файл с датой сохранения 11 октября: requests.log-20211011 , где 20211011 - 11 октября 2021 года. Логи за сегодняшний день сохраняются в файлы без даты (Пример requests.log).
Виды файлов логов:
- server.log - основной лог логики работы сервера и взаимодействия с внешними системами. Сюда пишется:
- отладочная информация обработки запроса от мобильного приложения на наш сервер
- Любая информация, которую разработчик или аналитик посчитали нужными добавить для понимания какого-либо процесса
- запросы во внешние системы (учётные, платёжные и тд)
Типичный кейс работы с данным файлом: «Не отображается расписание занятий» -> требуется найти в этом файле запрос расписания в учётную систему и посмотреть какой приходит ответ
- requests.log - сюда пишется:
- Все запросы и ответы от мобильного приложения на сервер с указанием всех параметров и кодов ошибок ответов
- крашлоги внутренних ошибок сервера
Типичные кейс анализа данного файла: просмотр крашлогов, если получаем 500 ошибки, либо анализ и проверка входных параметров от мобильного приложения.
- celery.log - лог работы с фоновыми задачами. Аналог server.log, только содержит логи, касаемо фоновых задач, выполняемых на celery.
Типичный кейс - не работает синхронизация новостей ВКонтакте или проблемы с синхронизацией заказа, когда мы НЕ используем уведомления об успешном платеже из платежных систем.
- requests_time.log - данный файл содержит время выполнения для каждого запроса на АПИ нашего сервера
Где скачать логи?
- Заходим в админку FitnessKit нужного клуба за пользователя техподдержки или разработчика
- Ищем раздел Log и заходим внутрь.
- Открывается список с файлами логов, либо пустой список. Рекомендуется перед скачиванием любого файла всегда сначала удалять все файлы, который видны (Сами файлы с логами при этом НЕ удаляются, удаляются лишь записи о них в админке)
- После чего нажимаем кнопку «Обновить», и появляются актуальные записи о существующих файлах логов.
- Выбираем нужный файл (с учётом даты) и качаем его.
По дефолту некоторые справочные запросы не печатаются в файл server.log, если его размер очень большой. Например расписание занятий или список тренеров. Вместо них в логах можно увидеть такую фразу: «Too big response». Если вдруг жизненно необходимо печатать полностью такие ответы, то можно в настройках сервера включить галочку «Печатать логи из внешних систем полностью». ВАЖНО отключать эту галочку после просмотра логов, иначе размеры файлов могут быть просто гигантскими.
Как читать логи?
В нашей системе присутствует несколько независимых друг от друга компонентов:
- мобильное приложение андроид
- мобильное приложение ios
- виджеты на сайт
- сервер FitnessKit
- учетные системы
- платёжные системы
- и другие внешние системы
Главная задача чтения логов - определить на каком компоненте возникает некорректное поведение. Далее информация передаётся соответствующим разработчикам. Для поиска нужных логов нужно хорошо представлять процесс отправки, обработки и получения ответа от мобильных приложений и виджетов на сервер FitnessKit. Ниже описан полный процесс на примере просмотра и оплаты долга пользователя в мобильном приложении:
- Клиент открывает список долгов в приложении. Приложение отправляет запрос accounts/get_debts на сервер
- Это отражается в файле requests.log, что пришёл такой запрос с входными параметрами.
- Сервер делает запрос в учетную систему на список долгов. для 1С и КлабИС это getDebtDetail
- Запрос и ответ учётной системы отражается в файле server.log
- Сервер FitnessKit формирует ответ и возвращает его мобильному приложению.
- Ответ со всем содержимым попадает в requests.log
- Клиент видит у себя на экране список долгов и нажимает кнопку оплатить долг.
- На наш сервер идёт запрос платёжной формы payment/request_payment_form_v2
- Это отражается в файле requests.log, но дополнительно пишется довольно много всякой информации по созданию заказа в server.log
- Наш сервер отправляет запрос в Сбербанк (или другую платежную систему) и обрабатывает ответ.
- Эта информация падает в server.log
- Далее аналогично сервер FitnessKit формирует ответ и возвращает клиенту, ответ фиксируется в requests.log
При чтении логов нужно проверять как отработал каждый компонент, чтобы выявить причину ошибки. На практике, ошибки чаще всего возникают как раз при работе с внешним системами, потому что взаимодействие сервера и мобильного приложения разрабатывает одна команда и здесь намного меньше проблем с коммуникацией и понимаем друг друга.
Некоторые частые кейсы:
- Заказ был успешно оплачен, но возникла Ошибка синхронизации этого заказа в учётную систему: в таком случае нужно в файле server.log поискать по идентификатору заказа и по запросу синхронизации заказа в учетную систему, скорее всего учётная система по каким-то причинам не приняла этот заказ.
- 500 ошибка сервера: произошла внутренняя ошибка сервера, нужно смотреть крашлог в файле requests.log. Если в крашлоге фигурирует ошибка парсинга json, то нужно еще заглянуть в server.log и посмотреть, что возвращает учётная система, вероятно приходит ошибка вместо нормального ответа c json, отсюда и краш сервера. Если крашлог непонятен, то нужно идти к backend разработчикам FitnessKit
- Не отображается платёжная форма в приложении: 500 ошибка - смотрим крашлог в requests.log, вероятнее всего не заполнен PaymentBackend для клуба. Если ошибка другая, то скорее всего платёжная система отвечает ошибкой, анализируем ее в server.log
Важный момент: некоторые справочные запросы сознательно не печатаются в requests.log (НЕ путать с галкой «Печатать логи из внешних систем полностью» и фразой: «Too big response» в файле server.log для запросов во внешние системы). И эти запросы не выйдет посмотреть в логах, но зато их можно спокойно выполнить в браузере и посмотреть ответ. К таким запросам относятся как минимум: новости, расписание, список сотрудников.