В реальности, скорее всего, вы будете использовать четыре.

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

Большинство фреймворков и пакетов следуют стандарту PSR-3, который описывает, как работает система ведения логов. Это интерфейс, на который вы должны опираться при отправке логов в систему. В PHP чаще всего используют имплементацию Monolog, как очень гибкий и простой в понимании.

Реализация PSR-3 описывает 8 уровней логов. В порядке убывания «строгости»: Emergency, Alert, Critical, Error, Warning, Notice, Info и Debug. Попытка решить, какой из них выбрать, иногда сбивает с толку. Давайте разберём их на условном приложении.

Уровни логов

Давайте разберём их на условном приложении.

Это приложение фиксирует активность множества цифровых ключей (IoT) из стороннего хаба, которую затем можно увидеть на приборной панели. У каждого сотрудника есть своя карта и пароль для каждого ключа. Они будут отправлять события на хаб, который, в свою очередь, будет передавать данные в приложение с помощью простого HTTP-запроса.

8. DEBUG для разработки

Когда я закончил разработку, я запустил стейдж для внутреннего использования, где смотрю, как приложение себя ведет максимально детально. Множество отладочных сообщений со сгенерённой фейковой информации, но с валидной структурой было записано с помощью старого ключа, который мы использовали для тестирования.

В продакшене эти сообщения не пишутся, поскольку уровень логов равен 7, что означает, что в лог записывается все, что не является отладочным сообщением.

7. INFO для статистики

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

6. NOTICE что-то значит

Когда пользователь вводит код ключа от двери, мы регистрируем это событие как уведомление. Изменение кода ключа через некоторое время - это нормально, поскольку оно обязательно, но ненормально, когда сотрудники меняют его до этого срока.

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

5. WARNING нежелателен

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

Чаще всего это не ошибка, а значимое событие, которое может помочь в борьбе с несанкционированным доступом.

4. ERROR нестабилен

Некоторые старые модели ключей время от времени выдают мусор. Изношенная карточка выдала неправильные идентификаторы. Помехи в сигнале - тоже бывает. При возникновении любой из этих проблем хаб сообщал приложению об «ошибке», а оно, в свою очередь, записывало сообщение об ошибке в лог.

В сообщении указывается, какая дверь не работает. Позже будет отправлен техник для проверки ключа.

3. CRITICAL показвает состояние

Каждую минуту плюс несколько случайных секунд хаб шлёт «пинг» на каждый ключ, чтобы проверить его состояние. Я был почти уверен, что это работает с WebSockets через BLE, ну что ж.

Они редко не отвечали, но когда отвечали, то практически уходили в самоволку, так как хаб, вероятно, многократно убеждался, что это не ложное срабатывание. Любое событие, не отвечающее на код ключа, будет занесено в лог как критическое.

2. ALERT небезопасен

Если какой-либо код отправил приложению «заблокированный» ответ, например, когда кто-то пытается силой проникнуть внутрь, это событие будет записано в лог как тревога. Охрана немедленно отправлялась на осмотр комнаты. Редко кто случайно стучал в дверь, так что этот механизм был очень надежным. Я предполагаю, что ключ оснащен хорошо откалиброванными интеллектуальными датчиками и гироскопом.

Это также отправлялось, если приложение получало какой-нибудь странный или не ожидаемый запрос (например, «pong» от хаба). Не то чтобы хаб нельзя было взломать, но тем не менее.

1. EMERGENCY непригоден для использования

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

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

Просто использование четырех

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

DEBUG: Для всего, что показывает внутреннюю работу приложения.
ERROR: То, что не должно происходить, но произошло.
ALERT: Всё, что ставит под угрозу состояние приложения в краткосрочной перспективе.
EMERGENCY: Любая часть приложения перестала работать.

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