Логирование

Logging.ru.md

Логирование

Это есть первая задача, которой я занялся, делая этот сервер.

Причина? Просто я солидарен с этим мнением:

Я твердо уверен, что внедрить логирование в уже готовую программу без изменения архитектуры приложения – невозможно . Точнее внедрить можно, но тогда лог будет настолько страшным и неудобочитаемым, что остается посочувствовать тем администраторам, которые будут с ним работать.[1]

Проблемы и решения. Причины логирования.

1. Поддержка сервера Решение проблем с разным серверным окружением, неудачное обновление пакетов зависимостей, нестандартные данные, поступающие в запрос, и проч.

2. Профилирование сервера под реальной нагрузкой При сдаче в эксплуатацию сервера проведенное функциональное (ab) тестирование может не предоставить реальной картины.

3. Дата аналитика.

4. Создание отчетов о работе сервера.

Манифест

Формально протокол действий приложения можно разделить на несколько частей... можно поделить все действия на системные (SYSTEM) , безопасности (SECURITY) и приложения (APPLICATION, BUSINESS)... [4]

В случае веб сервера:

• к системным действиям будут относится запросы к серверу и ответы на эти запросы.

• к действиям безопасности относятся проверки токенов / паролей / авторизация / регистрация.

• к действиям приложения относятся

  1. запросы к хранилищу данных на чтение
  2. транзакционные запросы к хранилищу данных на изменение
  3. http запросы к внешнему источнику данных
  4. сложная обработка внешних данных.

I. Логирование запросов к серверу.

Запись логов осуществляется в 4 разных транспорта:

1. Консоль Уровень: debug Когда используется: разработка в development окружении. Кем используется: разработчиком. В каком режиме включен: только в development режиме.

Не должно быть возможности запуска этого транспорта на production окружении.

2. Файл Уровень: info Когда используется: анализ статистики работы сервера (awstat), парсинг по регулярному выражению, поиск возможных DDOS атак (apachetop), подсчет запросов, удовлетворяющих определенному критерию и проч. Кем используется: разработчиком и администратором. В каком режиме включен: Всегда (основной транспорт)

Является основным хранилищем логов. Нет условия (флагов или режимов), при котором данный транспорт был бы выключен.

3. Хранилище (mongodb). Уровень: debug Когда используется: в development окружении, при профилировании или поиске возможных неисправностей. Кем используется: разработчиком. В каком режиме включен: в development режиме или при указании соответствующего флага в настройках ( storage_logs ). Хранятся наиболее подробные логи.

4. Почта. Уровень: error Когда используется: в production окружении, для обнаружения ошибок сервера (400+ ошибки). Кем используется: администратором. В каком режиме включен: в production режиме или при указании соответствующего флага в настройках ( email_logs ).

Так же как вариант возможно сделать отправку уведомления на почту посредством крон скрипта, который бы парсил лог файл и находил бы там новые ошибки со времени своего последнего запуска.

Материалы

1. Каким должен быть правильный лог-файл
2. Размышления о логировании
3. Принципы написания консистентного, идиоматического кода на JavaScript
4. Ведение лога приложения

Реализация

Важные мысли из материалов.

(1) Я считаю, что независимо от количества программистов, задействованных в разработке приложения, нужно стремиться к тому, чтобы минимизировать количество логов. В идеале должен быть только один лог-файл...

(3) Код в любом проекте должен выглядеть так, будто его писал один человек, неважно как много людей работали над ним. *** ...

(1) Я считаю, что лог в первую очередь предназначен для отражения хода выполнения программы, независимо от того идет все штатно или возникла ошибка...

Хочется особо отметить тот факт, что для решения проблемы администратору требуется информация не только верхнего, но и нижнего уровня.

Например, очень часто причиной сбоя становится банальная нехватка памяти или свободного места на диске. Если при наступлении подобного события в лог попадает информация только с уровня бизнес-логики, то администратору приходится гадать, а что же привело к этому сбою. А вот если в логе есть информация об ошибках и сообщениях, полученных от операционной системы (т.е. информация нижних уровней), то найти проблему становится значительно проще.

(2)

Вторая причина ведения логов - данные профилирования сервера под нагрузкой.

(1) Еще одна популярная проблема – это замедления в работе программы.

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