Для чего на самом деле нужен оператор журнала? Почему вы должны беспокоиться?
Если вы занимались программированием, вы, вероятно, сталкивались с оператором «log». Возможно, вы использовали его как средство отладки; чтобы ваш код выдавал некоторую информацию в проблемной точке. Но для этого ли они на самом деле? Какой смысл заставлять ваше приложение выводить кучу информации в консоль, если оно будет работать на веб-сервере, к которому у пользователя нет доступа?
В этой статье я объясню: что такое ведение журнала, чем оно отличается от связанной с ним концепции мониторинга и как хорошо делать и то, и другое.
Мониторинг против ведения журнала
Ведение журнала и мониторинг обычно выполняются с помощью приложений SaaS (программное обеспечение как услуга). Как и тестирование, они отделены от основной инженерной работы, которая добавляет функциональности приложению, но по-прежнему имеет решающее значение для создания чего-то высокого качества.
«Ведение журнала» относится к управлению данными журнала, созданными вашим приложением. Данные журнала могут выглядеть по-разному в зависимости от приложения, но в целом они должны состоять из информации, к которой будет полезно вернуться, если в вашем приложении что-то пойдет не так. Все данные журнала обычно должны быть связаны с некоторым идентификатором трассировки/запроса/корреляции, чтобы вы могли изолировать конкретный сеанс/запрос/событие. Данные журнала также должны куда-то идти, выплевывание их на консоль больше не поможет. На рынке существует множество решений, которые сохранят ваши данные и предоставят интерфейс для удобного поиска по ним.
«Мониторинг» относится к задачам, необходимым для обеспечения доступности и работоспособности приложения. Современные глобально доступные приложения получают слишком много трафика, чтобы люди могли отслеживать, что происходит в любой момент времени. Инструменты мониторинга обрабатывают все эти данные и производят совокупную статистику, которая гораздо полезнее. Опять же, это будет выглядеть по-разному в зависимости от того, что вы отслеживаете. Для REST API мониторинг может означать отслеживание задержки каждой конечной точки, чтобы убедиться, что она остается в допустимых пределах. Другими атрибутами, которые мы можем отслеживать, являются доступность, пропускная способность, частота отказов, количество активных пользователей и т. д. Обычно команды определяют целевые регионы для этих показателей. Возможно, вы видели, как люди говорят о «3 девятках безотказной работы»; это означает, что их приложение доступно 99,9% времени.
Знать, что отслеживать
Часть проблемы хорошего мониторинга и ведения журнала заключается в том, чтобы определить, что следует регистрировать и отслеживать. Для мониторинга это немного проще; каждое приложение хочет быть максимально доступным и успешным. Другие меры могут быть обусловлены интересами бизнеса. В зависимости от вашего продукта могут быть важны такие вещи, как ежедневные активные пользователи или активные часы.
Ведение журнала сложнее, потому что трудно предсказать, какая информация поможет вам решить проблемы заранее. Некоторые хорошие первые шаги могут состоять в том, чтобы сделать следующее. Регистрируйте всякий раз, когда возникает необработанное исключение, записывайте его сообщение, вы знаете, что что-то определенно пошло не так. Регистрируйте каждый раз, когда ваше приложение обращается к внешней службе, это может помочь вам диагностировать, когда проблема находится в другом месте. Вы также можете добавить больше журналов, как только вы определили проблему, чтобы помочь вам понять, что происходит.
Антикризисный контроль
Даже с лучшей в мире командой разработчиков в вашем коде будут ошибки, развертывание будет неудачным, а оборудование будет ненадежным. Когда что-то пойдет не так, усилия, затраченные на мониторинг и ведение журнала, должны помочь вам обнаружить проблему и быстро ее исправить.
Когда ошибка обнаружена и зарегистрирована разработчиком или пользователем, вы должны (если вы все сделали правильно) иметь возможность использовать идентификатор трассировки/запроса, который они предоставляют, для чтения журналов их взаимодействия с вашим приложением. Исходя из этого, вы можете легче диагностировать проблему.
Команды обычно настраивают оповещения, которые запускаются, когда отслеживаемый показатель выходит за пределы допустимого диапазона. Некоторые из разработчиков будут «дежурны», и в зависимости от серьезности проблемы им может автоматически позвонить по телефону с просьбой исправить то, что пошло не так. Я знаю многих разработчиков, чей спокойный ночной сон был прерван оповещением. Это, конечно, не весело, но иногда необходимо, и многие компании предлагают дополнительные праздничные дни для тех, кто терпит это.
Закрытие
Команде легко пренебречь тестированием, мониторингом и ведением журнала. Я надеюсь, что эта статья показала, почему они важны. Мониторинг поможет вашей команде понять, когда что-то идет не так, а ведение журнала должно помочь вам понять, почему.
Если вам понравилась эта статья, вам может понравиться мой TikTok. Кроме того, ознакомьтесь с некоторыми другими моими статьями здесь, на Medium, и рассмотрите возможность подписаться на меня.
