Я пытаюсь найти лучший способ настроить центральное место для хранения и опроса журналов сервера. syslog, Apache, MySQL и т. д.
Я нашел несколько разных вариантов, но не уверен, что будет лучше. Я ищу то, что легко установить и постоянно обновлять на многих виртуальных машинах. Я могу добавить его в шаблон виртуальной машины в будущем, но я также хотел бы, чтобы его было легко установить, чтобы снизить сложность виртуальной машины.
На данный момент я нашел следующие варианты:
И всякие перестановки из вышеперечисленного.
Что является наиболее устойчивым и легким с точки зрения «клиента» журнала?
Я бы хотел избежать ситуации, когда «клиенты» журналов зависают, потому что они не могут отправить свои журналы на сервер журналов. Также я хотел бы сохранить локальное ведение журнала и ротацию / сохранение, обеспечиваемую logrotate.
Есть идеи / предложения или причины за или против любого из вышеперечисленного?
Или предложения совсем другой структуры?
Я думаю, что лучшим является syslog-ng, простой в настройке, очень простой в обслуживании, красивый и мощный инструмент. Кстати, если у вас не более 500 миллионов журналов в день, вы можете заглянуть в splunk, все, что вам нужно, это добавить сервер пересылки журналов к образу машины и настроить несколько файлов, это будет работать как волшебство :) В нем много приложение для разных типов логов, красивый парсинг и т. д. Все зависит от того, что вам нужно.
Я бы сказал, что лучший надежный вариант на данный момент (за исключением коммерческих программных решений) - чистый syslog-ng
Недавний rsyslog, вероятно, будет одним из самых быстрых и легких вариантов. Вы получаете дисковые буферы и буферы памяти бесплатно, а также можете выводить данные в Elasticsearch через omelasticsearch. Вот сообщение в блоге, которое может помочь вам начать что-то вроде этого:
http://blog.sematext.com/2013/07/01/recipe-rsyslog-elasticsearch-kibana/
До недавнего времени мы использовали rsyslog с Graylog для централизованного ведения журнала. Это сработало очень и очень хорошо. При этом используется протокол GELF, который также имеет преимущество наличия библиотек на различных языках программирования.
Тем не менее, мы переходим на Loggly поскольку это дешевле, чем поддерживать собственный централизованный сервер регистрации. Поскольку Loggly рекомендует syslog-ng, мы оцениваем возможность перехода на него, хотя rsyslog кажется немного лучше - например. Рецепты rsyslog для таких вещей, как кэширование журналов при потере сети и поддержка GELF.