Проработав год с кубом как разработчик и, даже пройдя The hard way, все равно не создается хорошего понимая как этот конструктор собирать по частям. Статья прекрасно заполняет эту нишу, итеративно повышая сложность создаваемой конструкции. Было бы здорово почитать как шаг за шагом дойти до полноценного окружения с DNS, полноценным Control plane и поддержкой сети для двух и более узлов (с ручными правилами в iptables и потом уже с сетевым плагином вроде Flannel).
SocketAppender создаёт подключение к удаленному лог серверу и отправляет события на этот сервер. Причем посылаются сериализованные LoggingEvent, т. е. передаётся вся информация о событии а не строка. В случае если удалённый сервер не доступен, сообщения будут отбрасываться, когда же сервер заработает вновь соеденение будет востановленно автоматически.
Сервер для хранения логов действительно может быть недоступен по каким-либо причинам. И что тогда? Мы теряем логи? Если эта информация представляет для вас какую-то ценность, то такой подход неприемлем.
Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
За программы для анализа логов — спасибо, покопаюсь. Давно ищу что-нибудь удобное для анализа, правда больше интересуют программы, которые способны работать с архивами логов, а не с runtime потоком.
Вообще, я сам интересовался вопросом централизации логов с нескольких серверов и дальнейшим их анализом, но до конца построить готовый прототип руки так и не дошли. Буду очень благодарен, если кто-то опишет готовое надежное решение этой задачи.
Проработав год с кубом как разработчик и, даже пройдя The hard way, все равно не создается хорошего понимая как этот конструктор собирать по частям. Статья прекрасно заполняет эту нишу, итеративно повышая сложность создаваемой конструкции. Было бы здорово почитать как шаг за шагом дойти до полноценного окружения с DNS, полноценным Control plane и поддержкой сети для двух и более узлов (с ручными правилами в iptables и потом уже с сетевым плагином вроде Flannel).
Жду продолжения :)
<hh user=users> необходимо заменить на @usersПозвольте немного конструктивной критики:
Сервер для хранения логов действительно может быть недоступен по каким-либо причинам. И что тогда? Мы теряем логи? Если эта информация представляет для вас какую-то ценность, то такой подход неприемлем.
Более надежный способ — хранение логов локально с ротацией по дням, скажем за последнюю неделю (один из стандартных appender-ов log4j) и ежедневная заливка данных на центральный сервер (log rotation). Если сервер недоступен, ну что же, зальем чуть позже. Логи не пропадут.
Что касается SimpleSocketServer: а есть что-нибудь посерьезнее? Скажем, реализация, которая выстраивает логи в правильном хронологическом порядке? Или такие вещи проще решить через консоль при помощи простого sort? :)
За программы для анализа логов — спасибо, покопаюсь. Давно ищу что-нибудь удобное для анализа, правда больше интересуют программы, которые способны работать с архивами логов, а не с runtime потоком.
Вообще, я сам интересовался вопросом централизации логов с нескольких серверов и дальнейшим их анализом, но до конца построить готовый прототип руки так и не дошли. Буду очень благодарен, если кто-то опишет готовое надежное решение этой задачи.