Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Спасибо за статью.
Позвольте немного конструктивной критики:
Сервер для хранения логов действительно может быть недоступен по каким-либо причинам. И что тогда? Мы теряем логи? Если эта информация представляет для вас какую-то ценность, то такой подход неприемлем.
Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
За программы для анализа логов — спасибо, покопаюсь. Давно ищу что-нибудь удобное для анализа, правда больше интересуют программы, которые способны работать с архивами логов, а не с runtime потоком.
Вообще, я сам интересовался вопросом централизации логов с нескольких серверов и дальнейшим их анализом, но до конца построить готовый прототип руки так и не дошли. Буду очень благодарен, если кто-то опишет готовое надежное решение этой задачи.
Позвольте немного конструктивной критики:
SocketAppender создаёт подключение к удаленному лог серверу и отправляет события на этот сервер. Причем посылаются сериализованные LoggingEvent, т. е. передаётся вся информация о событии а не строка. В случае если удалённый сервер не доступен, сообщения будут отбрасываться, когда же сервер заработает вновь соеденение будет востановленно автоматически.
Сервер для хранения логов действительно может быть недоступен по каким-либо причинам. И что тогда? Мы теряем логи? Если эта информация представляет для вас какую-то ценность, то такой подход неприемлем.
Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
За программы для анализа логов — спасибо, покопаюсь. Давно ищу что-нибудь удобное для анализа, правда больше интересуют программы, которые способны работать с архивами логов, а не с runtime потоком.
Вообще, я сам интересовался вопросом централизации логов с нескольких серверов и дальнейшим их анализом, но до конца построить готовый прототип руки так и не дошли. Буду очень благодарен, если кто-то опишет готовое надежное решение этой задачи.
Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Полностью согласен не стоит складывать все яйца в одну корзину. Логи обязательно должны хранится в файловой системе как вы сказали. Центральный сервер в первую очередь нужен для удобства, в 99% случаев он работает и к нему можно подключиться что бы посмотреть логи, но если что-то пошло не так всегда есть локальные логи на сервере.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
В LoggingEvent есть информация о времени возникновения события. Те программы которые я описал сами выстраивают все в верном порядке. На более навороченные реализации сервера не натыкался.
А почему бы не использовать для этих целей готовое решение slf4j + logback + стандартные логбэковские аппендеры (SocketAppender, DBAppender)?
Log4j, как мне кажется, уже устарел. И его используют только по инерции.
Log4j, как мне кажется, уже устарел. И его используют только по инерции.
Есть такое решение:
при помощи flume и его exec source отправлять логи с серверов в HDFS.
Подключить Timestamp Interceptor и настроить Flume HDFS sink так, чтоб он писал с партиционированием по по часам:
/landing/source/mysuper_distirubuted_system/2013/03/08/12
Затем запускать pig и при помощи него выполнять аналитические операции над логами. Ведь мало собрать логи в одном месте, важно иметь способ быстро что-то по ним поискать.
при помощи flume и его exec source отправлять логи с серверов в HDFS.
Подключить Timestamp Interceptor и настроить Flume HDFS sink так, чтоб он писал с партиционированием по по часам:
/landing/source/mysuper_distirubuted_system/2013/03/08/12
Затем запускать pig и при помощи него выполнять аналитические операции над логами. Ведь мало собрать логи в одном месте, важно иметь способ быстро что-то по ним поискать.
У Log4J очень хорошо с расширяемостью. Когда-то работал над внутренним проектом одной компании: писали аппендер, который по сообщениям уровня ERROR автоматически заводил багрепорты в Jira.
Функциональность у Log4j и Logback практически идентичная. Logback в свое время «учился» на ошибках Log4j, исправлял их. Теперь, судя по заявлениям разработчиков Log4j2, они занимаются исправлением «ошибок» архитектуры Logback'а.
Блин, но вот за что нам это наказание?! Опять новый революционный логгер! )))
А в чем проблема то? Проект не должен зависеть от системы логирования. Сами по себе логгеры похожи. Не думаю, что в Log4j2 будет что то революционное. Возможно он будет незначительно быстрее… Возможно будет иметь несколько удобных, но не везде необходимых фич. Проблема перехода с одной системы логирования на другую — проблема конфигурирования. Затруднения могут вызвать только кастомные аппендеры — не частая встречающаяся задача.
То, что есть конкуренция — это хорошо. Технология не застаивается, есть альтернатива, можно выбрать именно то, что подойдет для твоего конкретного проекта.
То, что есть конкуренция — это хорошо. Технология не застаивается, есть альтернатива, можно выбрать именно то, что подойдет для твоего конкретного проекта.
Имхо, смотря какой проект. Если, к примеру, библиотека или фреймворк, то зависимости однозначно не должно быть. В противном случае получается проект, в котором для удовлетворения зависимостей одновременно приходится держать несколько библиотек логгирования. Ситуация, кстати, вполне реальная. Именно из-за этого я напрягаюсь когда слышу, что еще одним логгером стало больше. Ну а если конечное бизнес-приложение, то почему нет?
Библиотека уж тем более должна использовать slf4j, что бы не зависеть от конкретной системы логирования. Да и в любом проекте лучше через нее работать.
Боюсь что перестал понимать моего оппонента. Независимость библиотек от систем журналирования обеспечивается использованием библиотек-обёрток типа Apache Commons Logging. SLF4J — это конкретная реализация системы журналирования, равно как и Log4j, и Logback. Привязка Commons Logging к конкретному логгеру производится через файл commons-logging.properties. Пример привязки:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
Прописал такую строку, и вот уже Log4J рулит сообщениями Commons Logging.
Использование SLF4J в библиотеках противоречит тезису «Проект не должен зависеть от системы логирования». Хотя на практике оно случается. Могу привести реальный пример того, почему это плохо. SLF4J перестаёт вести журналирование, если приложение запускает само себя под управлением встроенной Jetty. Когда понял почему, хотел избавиться от SLF4J, но не мог, потому что от этой библиотеки зависит Apache Wicket. Если бы Wicket использовал Apache Commons Logging, то проблемы со сменой системы журналирования не возникло бы.
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
Прописал такую строку, и вот уже Log4J рулит сообщениями Commons Logging.
Использование SLF4J в библиотеках противоречит тезису «Проект не должен зависеть от системы логирования». Хотя на практике оно случается. Могу привести реальный пример того, почему это плохо. SLF4J перестаёт вести журналирование, если приложение запускает само себя под управлением встроенной Jetty. Когда понял почему, хотел избавиться от SLF4J, но не мог, потому что от этой библиотеки зависит Apache Wicket. Если бы Wicket использовал Apache Commons Logging, то проблемы со сменой системы журналирования не возникло бы.
SLF4J — это не конкретная реализация системы логирования, это фасад логирования. Под который можно легко подложить любую другую, конечную систему логирования, без каких либо конфигов со стороны slf4j. Чем этот подход отличается от Apache Commons Logging? Практически ничем. При этом, Apache Common Logging имеет ряд проблем, из-за которых многие отказываются от него в пользу slf4j.
Что касается описанной проблемы с Jetty, Wicket и вашим приложением… На вскидку могу предположить, что имели место конфигурационные проблемы, возможно не было необходимых slf4j бриджей. В моей практике slfj4 не доставлял проблем. Хотелось бы взглянуть на проблемный пример в живую.
Что касается описанной проблемы с Jetty, Wicket и вашим приложением… На вскидку могу предположить, что имели место конфигурационные проблемы, возможно не было необходимых slf4j бриджей. В моей практике slfj4 не доставлял проблем. Хотелось бы взглянуть на проблемный пример в живую.
Приношу извинения, я напутал, так как не использовал SLF4J уже много лет. Но суть проблемы в общих чертах помню. У SLF4J есть одна особенность, которая описана здесь:
www.slf4j.org/codes.html#multiple_bindings
SLF4J делает binding при первом запуске. Но если в приложение встроен Jetty, который запускает то же самое приложение, но уже как web-приложение, то это приводит к повторной инициализации SLF4J. Результат:
SLF4J: Class path contains multiple SLF4J bindings.
Надо сказать, это был полный fail. Но через некоторое время я выкинул Wicket, выкинул SLF4J, а позже Jetty заменил на еще более легковесный Winstone. И теперь я счастлив, используя старый добрый Log4J. Мне не шашечки, мне ехать.
www.slf4j.org/codes.html#multiple_bindings
SLF4J делает binding при первом запуске. Но если в приложение встроен Jetty, который запускает то же самое приложение, но уже как web-приложение, то это приводит к повторной инициализации SLF4J. Результат:
SLF4J: Class path contains multiple SLF4J bindings.
Надо сказать, это был полный fail. Но через некоторое время я выкинул Wicket, выкинул SLF4J, а позже Jetty заменил на еще более легковесный Winstone. И теперь я счастлив, используя старый добрый Log4J. Мне не шашечки, мне ехать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Агрегация логов с нескольких серверов средставами log4j