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