Централизованное ведение журнала сети - syslog и альтернативы?
На работе мы создаем распределенное приложение (возможно, на нескольких компьютерах в локальной сети, возможно, позже на нескольких континентах в WAN + VPN). Мы не хотим, чтобы файлы журналов были локальными для каждой машины (заполнение диска и невозможность просмотра в совокупности), поэтому нам необходимо централизовать ведение журнала по сети. Большинство журналов не будут важны, поэтому UDP подходит для них, но некоторые из них теряют важные предупреждения и должны быть надежно доставлены, что подразумевает TCP. Мы беспокоимся о том, чтобы перегружать сеть, если протокол протоколирования слишком чат, или перетаскивая приложения в обход, если он не реагирует.
Некоторые возможности, которые я рассмотрел, следующие:
- syslog (это кажется идеальным, но у моего босса есть анимус против этого, поэтому я не могу его выбрать).
- scribe из facebook (но он кажется немного тяжеловесным с сервером на каждом компьютере - не каждое сообщение журнала нуждается в сверхнадежности).
- используя очередь сообщений, например rabbitmq, которая может иметь несколько очередей, настроенных на разные уровни безопасности транзакций.
- худший случай, я могу написать свой собственный с нуля.
Есть ли у вас другие предложения? Какие централизованные каротажные решения вы использовали и насколько хорошо они работали?
Изменить: Я наклонялся к писцу, потому что его дизайн "store-and-forward" отделяет запущенное приложение от сетевой латентности. Но после попытки установить его, я обнаружил, что (1) он недоступен в виде двоичного пакета - в настоящее время это непростительно - и (2) он тесно зависит от библиотеки (бережливости), которая также недоступна в виде бинарного пакета! И хуже всего, он даже не будет компилироваться должным образом. Это не код качества выпуска, даже в открытом исходном коде.
Ответы
Ответ 1
Мы успешно использовали ZeroMQ для журналов сценария распределенного приложения, такого как ваш. Он очень надежный и невероятно быстрый. Мы перешли в ZeroMQ после неудачной реализации с Spread. В нашей установке один сервер ZeroMQ способен обрабатывать более 70 разных журналов из распределенного приложения с высокой нагрузкой. Он получает данные из локальной сети и через Интернет.
Если вам требуется подробное сравнение сервера очередей, просмотрите эту страницу из вики-страницы Second Life.
Надеюсь, что это поможет!
Ответ 2
Syslog хорош, если вы намерены сосредоточиться только на журналах инфраструктуры (например, на системном уровне). Я слышал, что KIWI Syslog Server - хороший, хотя сам не пробовал. С другой стороны, если вы хотите зарегистрировать связанный с приложением материал, syslog, возможно, не самый лучший вариант для этого. Если вы используете службы регистрации apache (log4j, log4xxx и остальные), то logFaces будет хорошим решением, поскольку оно построено специально для агрегирования нескольких приложений в одном месте. Работает как с TCP, так и с UDP-соединениями и имеет достойный просмотр журнала и интеграцию с базой данных.
Раскрытие информации. Я являюсь автором этого продукта.
Ответ 3
В последнее время существует несколько альтернатив. Примечательно, что Scribe больше не поддерживается. Facebook разработал своего преемника по имени Caligraphus, и он не был открытым. Вот список альтернатив.
- syslog: установлен во всех дистрибутивах Linux
- Fluentd: легкий логгер на основе C + на рубинах, который обрабатывает журналы как поток JSON
- Flume: разработан в Cloudera, написанный на Java и хорошо работающий с экосистемами Hadoop.
- Apache Kafka: разработан в LinkedIn, основанной на тяге архитектуре
- Scribe: открытый с помощью Facebook, но не поддерживается больше
Отказ от ответственности: я являюсь участником проекта Fluentd.
Ответ 4
Другие примеры могут быть замечательными, но мне повезло с Syslog-NG. Он чрезвычайно гибкий и настраиваемый; хотя довольно легко поднять его и быстро сделать что-то полезное.
Ответ 5
Вы также можете использовать оповещения SNMP.
Ответ 6
Пересмотрены все альтернативы, рекомендованные в этом потоке. Посмотрел на что-то python. Googled больше и нашел часовую https://getsentry.com/welcome/ Открытый исходный код, хорошо документированный. Должен быть надежным для коммерческого, поскольку существует бизнес, основанный на этом.