Важная информация для понимания логики работы логов:

Каждую ночь текущие (с только что прошедшего дня) файлы логов изменяют своё название (к ним добавляется дата), и создаются новые файлы логов. Причём ко вчерашним логам добавляется СЕГОДНЯШНЯЯ дата. То есть, чтобы прочитать, например requests.log за 10 октября нужно смотреть файл с датой сохранения 11 октября: requests.log-20211011 , где 20211011 - 11 октября 2021 года. Логи за сегодняшний день сохраняются в файлы без даты (Пример requests.log). 

Виды файлов логов:

1. server.log - основной лог логики работы сервера и взаимодействия с внешними системами. Сюда пишется:
   - отладочная информация обработки запроса от мобильного приложения на сервер FitnessKit
   - Любая информация, которую разработчик или аналитик посчитали нужными добавить для понимания какого-либо процесса
   - запросы во внешние системы (учётные, платёжные и тд)
   
   Типичный кейс работы с данным файлом: «Не отображается расписание занятий»  -> требуется найти в этом файле запрос расписания в учётную систему и посмотреть какой приходит ответ
    
2. requests.log - сюда пишется:
   - Все запросы и ответы от мобильного приложения на сервер с указанием всех параметров и кодов ошибок ответов
   - крашлоги внутренних ошибок сервера
   
   Типичные кейс анализа данного файла: просмотр крашлогов, если получаем 500 ошибки, либо анализ и проверка входных параметров от мобильного приложения.
    
3. celery.log - лог работы с фоновыми задачами. Аналог server.log, только содержит логи, касаемо фоновых задач, выполняемых на celery.
   
   Типичный кейс - не работает синхронизация новостей ВКонтакте или проблемы с синхронизацией заказа, когда мы НЕ используем уведомления об успешном платеже из платежных систем.
    
4. requests_time.log - данный файл содержит время выполнения для каждого запроса на АПИ сервера FitnessKit
    

Где скачать логи?

1. Заходим в админку FitnessKit нужного клуба за пользователя техподдержки или разработчика
2. Ищем раздел Log и заходим внутрь.
3. Открывается список с файлами логов.
4. Выбираем нужный файл (с учётом даты) и качаем его.

По дефолту некоторые справочные запросы не печатаются в файл server.log, если его размер очень большой.  Например расписание занятий или список тренеров. Вместо них в логах можно увидеть такую фразу: «Too big response». Если вдруг жизненно необходимо печатать полностью такие ответы, то можно в настройках сервера включить галочку «Печатать логи из внешних систем полностью». ВАЖНО отключать эту галочку после просмотра логов, иначе размеры файлов могут быть просто гигантскими.

Как читать логи?

В системе присутствует несколько независимых друг от друга компонентов:

1. мобильное приложение андроид
2. мобильное приложение ios
3. виджеты на сайт
4. сервер FitnessKit
5. учетные системы
6. платёжные системы
7. и другие внешние системы

Главная задача чтения логов - определить на каком компоненте возникает некорректное поведение. Далее информация передаётся соответствующим разработчикам. Для поиска нужных логов нужно хорошо представлять процесс отправки, обработки и получения ответа от мобильных приложений и виджетов на сервер FitnessKit. Ниже описан полный процесс на примере просмотра и оплаты долга пользователя в мобильном приложении:

1. Клиент открывает список долгов в приложении. Приложение отправляет запрос accounts/get_debts на сервер
2. Это отражается в файле requests.log, что пришёл такой запрос с входными параметрами.
3. Сервер делает запрос в учетную систему на список долгов. для 1С и КлабИС это getDebtDetail
4. Запрос и ответ учётной системы отражается в файле server.log
5. Сервер FitnessKit формирует ответ и возвращает его мобильному приложению.
6. Ответ со всем содержимым попадает в requests.log
7. Клиент видит у себя на экране список долгов и нажимает кнопку оплатить долг.
8. На наш сервер идёт запрос платёжной формы payment/request_payment_form_v2
9. Это отражается в файле requests.log, но дополнительно пишется довольно много всякой информации по созданию заказа в server.log 
10. Наш сервер отправляет запрос в Сбербанк (или другую платежную систему) и обрабатывает ответ. 
11. Эта информация падает в server.log
12. Далее аналогично сервер FitnessKit формирует ответ и возвращает клиенту, ответ фиксируется в requests.log

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

Некоторые частые кейсы: 

1. Заказ был успешно оплачен, но возникла Ошибка синхронизации этого заказа в учётную систему: в таком случае нужно в файле server.log поискать по идентификатору заказа и по запросу синхронизации заказа в учетную систему, скорее всего учётная система по каким-то причинам не приняла этот заказ.
2. 500 ошибка сервера: произошла внутренняя ошибка сервера, нужно смотреть крашлог в файле requests.log. Если в крашлоге фигурирует ошибка парсинга json, то нужно еще заглянуть в server.log и посмотреть, что возвращает учётная система, вероятно, приходит ошибка вместо нормального ответа c json, отсюда и краш сервера. Если крашлог непонятен, то нужно идти к backend разработчикам FitnessKit.
3. Не отображается платёжная форма в приложении: 500 ошибка - смотрим крашлог в requests.log, вероятнее всего не заполнен PaymentBackend для клуба. Если ошибка другая, то скорее всего платёжная система отвечает ошибкой, анализируем ее в server.log

Важный момент: некоторые справочные запросы сознательно не печатаются в requests.log (НЕ путать с галкой «Печатать логи из внешних систем полностью» и фразой: «Too big response» в файле server.log для запросов во внешние системы). И эти запросы не выйдет посмотреть в логах, но зато их можно спокойно выполнить в браузере и посмотреть ответ. К таким запросам относятся как минимум: новости, расписание, список сотрудников.