Подтвердить что ты не робот

Централизованная регистрация Java

Я ищу способ централизовать проблемы ведения журналов распределенного программного обеспечения (написанные на Java), что было бы довольно просто, так как у рассматриваемой системы есть только один сервер. Но имея в виду, что очень вероятно, что больше экземпляров конкретного сервера будет запущено в будущем (и для этого потребуется больше приложений), должно быть что-то вроде Logging-Server, который заботится о входящих журналах и делает их доступными для команды поддержки.

Ситуация прямо сейчас заключается в том, что несколько java-приложений используют log4j, который записывает данные в локальные файлы, поэтому, если проблемы с клиентами испытывают трудности, команда поддержки должна запрашивать журналы, что не всегда легко и требует много времени. В случае сбоя сервера проблема диагностики не такая большая, поскольку в любом случае есть дистанционный доступ, но даже несмотря на то, что мониторинг всего через Logging-Server все равно будет иметь большой смысл.

В то время как я рассмотрел вопросы, касающиеся "централизованного ведения журнала", я нашел еще один Question (фактически единственный, у которого (в данном случае) полезный ответ. все приложения работают в закрытой среде (в пределах одной сети), а рекомендации по безопасности не позволяют никому, что касается внутреннего программного обеспечения, выйти из сети окружения.

Я также нашел замечательную статью о том, как реализовать такой Logging-Server. Поскольку статья была написана в 2001 году, я бы подумал, что кто-то, возможно, уже решил эту конкретную проблему. Но мои поисковые результаты ничего не придумали.

Мой вопрос: Существует ли система ведения журнала, которая обрабатывает ведение журнала по сетям с централизованным сервером, доступ к которому может получить команда поддержки?

Спецификация:

  • Наличие
  • Сервер должен быть запущен нами.
  • Совместимость с Java 1.5
  • Совместимость с гетерогенной сетью.
  • Best-Case: протокол использует HTTP для отправки журналов (чтобы избежать проблем с брандмауэром)
  • Best-Case: использует log4j или LogBack или в основном что-либо, что реализует slf4j

Не нужно, но приятно иметь

  • Аутентификация и безопасность, конечно, являются проблемой, но могут быть восстановлены по крайней мере в течение некоторого времени (если это открытое программное обеспечение, мы распространим его на наши потребности OT: мы всегда возвращаем проекты).
  • Анализ и анализ данных - это то, что очень полезно для улучшения программного обеспечения, но это может быть и внешнее приложение.

Мой худший сценарий заключается в том, что у них нет такого программного обеспечения. В этом случае мы, вероятно, будем реализовывать это сами. Но если есть такое приложение Client-Server, я бы очень признателен, что не нужно делать это, в частности, проблемную часть работы.

Заранее спасибо

Обновление: Решение должно запускаться на нескольких платформах с поддержкой Java. (В основном Windows, Linux, некоторые HP Unix)

Обновление: После намного большего объема исследований мы нашли решение, которое мы смогли приобрести. clusterlog.net (в автономном режиме с середины 2015 года) предоставляет услуги регистрации для распределенного программного обеспечения и совместим с log4j и logback (который совместим с SLF4J). Это позволяет нам анализировать каждый пользовательский путь через приложение. Таким образом, очень легко воспроизвести сообщенные ошибки (или даже не сообщенные). Он также уведомляет нас о важных событиях по электронной почте и имеет систему отчетов, где журналы одного и того же происхождения суммируются в легкодоступный формат. Они развернули (что было безупречно) здесь всего пару дней назад, и он отлично работает.

Update (2016): этот вопрос по-прежнему получает много трафика, но сайт, о котором я говорил, больше не существует.

4b9b3361

Ответ 3

Посмотрите на logFaces, похоже, что ваши спецификации выполнены. http://www.moonlit-software.com/

  • Доступность (проверка)
  • Сервер должен управляться нами. (Проверка)
  • Совместимость с Java 1.5 (проверка)
  • Совместимость с гетерогенной сетью. (Проверка)
  • Best-Case: протокол использует HTTP для отправки журналов (чтобы избежать проблем с брандмауэром) (почти TCP/UDP)
  • Best-Case: использует log4j или LogBack или в основном что-либо, что реализует slf4j (check)
  • Аутентификация (проверка)
  • Анализ данных и анализ (возможно через расширение api)

Ответ 4

Там есть готовое к использованию решение от Facebook - Scribe - использование Apache Hadoop под капот. Тем не менее, большинство компаний, которых я знаю, по-прежнему имеют тенденцию разрабатывать собственные системы для этого. Я работал в одной такой компании и занимался журналами там около двух лет назад. Мы также использовали Hadoop. В нашем случае у нас была следующая настройка:

  • У нас был небольшой специализированный кластер машин для агрегации журналов.
  • Рабочие добывали журналы из производственного сервиса, а затем разбирали отдельные строки.
  • Тогда редукторы будут собирать необходимые данные и готовить отчеты.

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

Если вы не можете решить, какие анализы вы заинтересованы заранее, лучше хранить структурированные данные, подготовленные рабочими в HBase или какой-либо другой базе данных NoSQL (здесь, например, люди используют Mongo DB). Таким образом вам не нужно будет повторно агрегировать данные из необработанных журналов и будет иметь возможность запрашивать хранилище данных.

Существует ряд хороших статей о таких решениях агрегации каротажа, например с помощью Pig для запроса агрегированных данных. Pig позволяет запрашивать большие массивы данных на основе Hadoop с запросами, подобными SQL.