Управление большим количеством файлов журналов, распределенных по многим машинам

Question

Мы начали использовать стороннюю платформу (GigaSpaces), которая помогает нам в распределенных вычислениях.Одна из основных проблем, которую мы пытаемся решить сейчас, - это управление файлами журналов в этой распределенной среде.В настоящее время мы имеем следующую настройку.

Наша платформа распределена по 8 машинам.На каждой машине у нас есть 12-15 процессов, которые регистрируют отдельные файлы журнала, используя java.util.logging.Помимо этой платформы у нас есть собственные приложения, которые используют log4j и log для разделения файлов.Мы также перенаправляем стандартный вывод в отдельный файл, чтобы перехватывать дампы потоков и тому подобное.

В результате получается около 200 различных файлов журнала.

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

• Устранение неполадок, когда мы заранее не знаем, в каком процессе возникла проблема.В этом случае мы в настоящее время подключаемся к каждой машине, используя ssh, и начинаем использовать grep.

• Пытаясь быть активными, регулярно проверяя журналы на наличие чего-то необычного.В этом случае мы также в настоящее время подключаемся ко всем машинам и просматриваем различные журналы, используя less и tail.

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

Сегодня у нас только около 5 событий журнала в секунду, но это будет увеличиваться по мере того, как мы все больше и больше кода переносим вновая платформа.

Я хотел бы задать сообществу следующие вопросы.

• Как вы справлялись с подобными случаями, когда многие файлы журналов распределялись по нескольким компьютерам, зарегистрированным в разных средах?
• Почему вы выбрали именно это решение?
• Как сработали ваши решения?Что вы нашли хорошего и что вы нашли плохого?

Большое спасибо.

Обновление

Мы закончили оценку пробной версииСплунка.Мы очень довольны тем, как это работает, и решили приобрести его.Простота установки, быстрый поиск и множество функций для технически склонных.Я могу порекомендовать кого-нибудь в подобных ситуациях, чтобы проверить это.

Answer 1

Я бы порекомендовал передать все ваши java-журналы в Simple Logging Facade для Java (SLF4J) и затем перенаправить все журналы из SLF4J в LogBack . SLF4J имеет специальную поддержку для обработки всех популярных устаревших API (log4j, commons-logging, java.util.logging и т. Д.), См. здесь .

Когда у вас есть журналы в LogBack, вы можете использовать один из множества дополнений для совокупности журналов на нескольких машинах, для получения подробной информации см. Руководство раздел об дополнениях . Сокет, JMS и SMTP кажутся наиболее очевидными кандидатами.

LogBack также имеет встроенную поддержку для мониторинга особых условий в файлах журналов и фильтрацию событий , отправляемых определенному аппендеру. Таким образом, вы можете настроить SMTP-приложение для отправки вам электронной почты каждый раз, когда в журналах появляется событие с ошибкой.

Наконец, чтобы облегчить устранение неполадок , обязательно добавьте requestID ко всем вашим входящим "запросам", см. Мой ответ на этот вопрос для подробности.

РЕДАКТИРОВАТЬ : вы также можете реализовать свой собственный пользовательский приложение LogBack и перенаправить все журналы на Scribe .

Answer 2

Интересным вариантом для изучения было бы запустить Hadoop Cluster на этих узлах и написать пользовательскую Map Reduce работу для поиска и агрегирования результатов, специфичных для ваших приложений.

Answer 3

Я бы посоветовал взглянуть на инструмент агрегации журналов, например Splunk или Scribe .

(Кроме того, я думаю, что это скорее вопрос ServerFault, поскольку он связан с администрированием вашего приложения и его данных, а не с созданием приложения.)

Answer 4

Я бы перенес файл на централизованный компьютер, чтобы запустить на нем механизм анализатора.Может быть, вы можете использовать кластер Hadoop, чтобы сделать это, и запускать карты / сокращать задания для анализа ... Скопируйте его всего за 5 минут в кластер haddop и т. Д. Я не уверен, что это соответствует вашим потребностям.В этих отношениях было бы неплохо взглянуть на Писца, как уже упоминалось.

Answer 5

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