Автор оригинала: Vlad Mihalcea.
Я думаю, что журналированию должно уделяться больше внимания, чем мы уделяем ему в настоящее время. При разработке приложения много усилий уходит на моделирование бизнес-логики клиента, чтобы убедиться, что все варианты использования охвачены и обработаны должным образом. Бизнес-модель сопоставляется с хранилищем постоянной памяти (лучше, чем СУБД или решение NoSQL), выбираются платформы: веб, среднее программное обеспечение, пакетные задания и, возможно, SLF4J с log4j или logback.
Так было почти со всеми приложениями, с которыми я имел дело, и ведение журнала всегда было гражданином второго сорта, полагаясь для этого на старые добрые структуры ведения журнала строк.
Но недавно я пришел к пониманию, что ведение журнала-это гораздо больше, чем современные системы ведения журнала на основе строк. Особенно если моя система будет развернута в облаке и воспользуется преимуществами автоматического масштабирования, то сбор текстовых файлов и их объединение в общее место пахнет хакерством.
В моем последнем приложении мы реализовали механизм уведомлений, который содержит более сложную информацию, поскольку журнала на основе строк было недостаточно. Я должен поблагодарить одного из моих коллег, с которыми я работаю, который открыл мне глаза, сказав: “Уведомления лежат в основе нашего приложения”. Я никогда не думал о ведении журнала как о сердце любого приложения. Бизнес-логика-это сердце приложения, а не ведение журнала. Но в его словах много правды, поскольку вы не можете развернуть что-то без хорошего механизма, позволяющего узнать, действительно ли ваша система делает то, для чего она предназначалась.
Таким образом, мои уведомления-это сложные объекты (отладочные, в которых меньше данных, чем в сообщениях об ошибках), а база данных документов NoSQL-идеальное хранилище для наших журналов. Уведомление содержит все виды данных: – выполняемое в данный момент задание, – источник данных, – компонент, из которого был создан журнал, – создаваемые исключения, – входные аргументы, – история сообщений сообщения Spring Integration, содержащего наш запрос.
Поэтому, поскольку я могу хранить сложные объекты без схемы, я также могу запрашивать журналы, и не имеет значения порядок их поступления, поскольку я могу упорядочить их по источнику и времени создания. У меня может быть запланированное задание, генерирующее предупреждения и отчеты при обнаружении слишком большого количества записей об ошибках.
Это специально разработанная реализация ведения журнала, поскольку мы не использовали специальную платформу для наших уведомлений, но я получаю от нее больше пользы, чем от классических файлов журналов на основе строк.
Я все еще думаю, что log4j и logback являются очень хорошими реализациями, и мы не заменили их, мы только добавили дополнительную функцию ведения журнала, чтобы преодолеть их ограничения, но даже с новыми приложениями для ведения журнала я все еще думаю, что текущие журналы на основе строк слишком просты для требований производственных систем. И если вы используете их больше для целей отладки, имея при этом дополнительные решения для мониторинга производственных сред, то, возможно, пришло время использовать интеллектуальное решение для ведения журнала, которое также работает как для сред разработки, так и для производственных сред.
Если это было трудно реализовать 10 лет назад, когда СУБД управляли миром хранения, и ведение журнала на основе файлов было хорошим компромиссом, я думаю, что сейчас у нас есть средства для внедрения более совершенных систем ведения журнала. Текущая модель ведения журнала файлов на основе строк могла бы быть достаточной, особенно когда наш сервер масштабировался вертикально на одной машине, но в мире множества горизонтально распределенных серверов эта модель требует дополнительной обработки.
Крупные игроки уже используют такие системы ведения журнала нового поколения Facebook Scribe и Обработка журналов Кафки .
Мне очень понравилось решение LinkedIn, и оно вдохновляет меня на размышления о новой системе ведения журнала, работающей в стиле CQRS , где записи в журнале представляют собой события, хранящиеся в базе данных журналов, и каждое событие проходит через цепочку обработчиков, обновляющих текущее состояние системы. Это сочетает в себе как ведение журнала, так и мониторинг, и команды мониторинга переходят непосредственно в представление состояния системы cachedlatest, которое содержит:
- оповещения,
- отчеты о состоянии
- мониторинг представлений текущего состояния системы
Как вам кажется, стоит ли внедрять такое решение, стоит ли нам начинать новый проект ведения журнала нового поколения с открытым исходным кодом?