Я очень впечатлен Splunk, особенно версии 4. Красивые графики, предупреждения (только для Enterprise) и быстрый, точный поиск. Это отличный продукт.
Однако цена слишком высока, чтобы ее можно было рассматривать для полноценного производственного использования нашей компании. Все, что нам действительно нужно, это иметь возможность индексировать различные журналы в одном месте и вести разумный поиск по ним. Также приятно иметь предупреждения, основанные на сохраненном поиске. На самом деле мы не идем дальше этого.
Фактически, больше всего мы использовали для развертывания новых приложений. Все регистрируется через log4net либо в журнале событий в Windows, либо в текстовом файле в Linux. Splunk позволяет довольно легко выполнять быстрый поиск по ним, чтобы убедиться, что все части приложения работают нормально - это сэкономило нам массу времени по сравнению с поиском отдельных источников журналов.
Какие альтернативы существуют на этом рынке? У меня ужасное предчувствие, что цены на Splunk настолько высоки, потому что у них самый лучший продукт, и они это знают. Мы хотим, чтобы сервер работал в Windows.
Я был бы открыт для разделенной модели, используя один продукт для общих журналов (сбор через syslog / Snare) и специальный продукт для наших пользовательских приложений (например, Панель управления Log4Net).
Будет ли работать простой сервер системного журнала, такой как Kiwi, отправленный на SQL Server (возможно, с включенным полным текстом)?
Я надеюсь, что стоимость будет меньше пятизначной, долларов США. (И да, я знаю, мы дешевы. Мы начинаем с небольшими деньгами, и BizSpark берет на себя все наши лицензии на MS.)
Изменить: я должен добавить, у нас около 10 физических серверов, 20 виртуальных машин и пара межсетевых экранов и коммутаторов. 90% это винда.
Примечание: все это касается Linux и бесплатно программное обеспечение, поскольку это то, что я в основном использую, но вы должны быть в порядке с клиентом системного журнала в Windows для отправки журналов на сервер системного журнала Linux.
Вход на SQL-сервер: Имея всего около 30 машин, вы должны быть в порядке практически с любыми централизованными системными журналами, такими как бэкэнд SQL. я использую syslog-ng и MySQL в Linux именно для этого.
Симпатичные интерфейсы для построения графиков - основная проблема. Похоже, что существует множество взломанных интерфейсов, которые захватывают элементы из журналов и показывают, сколько обращений, предупреждений и т. д., но я не нашел ничего интегрированного и чистого. По общему признанию, это главное, что вы ищете ... (Если я найду что-нибудь хорошее, я обновлю этот раздел!)
Предупреждение: Я использую SEC на сервере Linux, чтобы найти в журналах происходящие плохие вещи и предупредить меня различными способами. Он невероятно гибкий и не такой щелкающий, как Splunk. Есть хороший учебник здесь который описывает множество возможных функций.
Я также использую Nagios для графиков различной статистики и некоторых предупреждений, которые я не получаю из журналов (например, когда службы не работают и т. д.). Это можно легко настроить, чтобы добавить графики чего угодно. Я добавил графики таких элементов, как количество обращений к http-серверу, заставив агент использовать check_logfiles плагин для подсчета количества попаданий в журналы (он сохраняет позицию, до которой он попадает для каждого периода проверки).
В общем и целом, это зависит от того, сколько у вас будет времени на настройку, поскольку есть много опций, которые вы можете использовать, но они не так интегрированы, как Splunk, и, вероятно, потребуют больше усилий, чтобы сделать то, что вы хотите. Графики Nagios просты в настройке, но они не предоставляют вам исторические данные до того, как вы добавите график, тогда как с Splunk (и, предположительно, с другими интерфейсами) вы можете просмотреть прошлые журналы и построить графики того, что вы только что думал смотреть с них.
Также обратите внимание, что формат базы данных SQL и индексация будут иметь огромный влияет на скорость запросов, поэтому ваша идея полнотекстового индексирования значительно повысит скорость поиска. Я не уверен, что MySQL или PostgreSQL будут делать что-то подобное.
редактировать : MySQL будет выполнять полнотекстовую индексацию, но только в таблицах MyISAM до MySQL 5.6. В версии 5.6 была добавлена поддержка InnoDB.
редактировать: Postgresql, конечно, может выполнять полнотекстовый поиск: http://www.postgresql.org/docs/9.0/static/textsearch.html
Больше нацелено на * nix, чем на окна, но осьминог поддерживает окна и, похоже, стремится к тому же, что и splunk.
Я сейчас пробую несколько решений для мониторинга, но в основном хочу отслеживать окна. Большинство систем ориентированы на мониторинг по протоколу SNMP, который позволяет получать значительный объем информации без использования агентов.
Вот некоторые из систем, которые я пробовал до сих пор:
Nagios - Открытый исходный код. Свинья для настройки, но с высокими оценками и кажется очень гибкой. Похоже, что это, по сути, регистратор счетчиков, который не позволяет удаленно выполнять скрипты и поэтому не может использоваться для обнаружения проблем с конфигурацией, например, системного центра MS или Kaseya. Без агента, но по существу бесполезен без инструмента NSclient, установленного на каждом клиенте.
Cacti - Красивый и простой инструмент для построения графиков, основанный на извлечении статистики snmp. Без агента.
OpsView - основан на Nagios, но проще в настройке и имеет лучший интерфейс.
HypericHQ - Легко установить и запустить под Windows. Базовая версия бесплатна и имеет много возможностей. Есть коммерческое предприятие HypericHQ. Агент должен быть установлен на каждом клиенте.
Zabbix - еще один хороший инструмент для мониторинга. Его проще использовать, чем нагиос. Имеет агент, который можно установить на Windows и клиентские машины. Я пока лишь немного исследовал это.
Zenoss - Открытый исходный код. Я был очень впечатлен профессионализмом Зеносса. Это монитор на основе SNMP и множество расширений, позволяющих отслеживать пролианты HP, службы Windows, сервер ms sql, mysql. Все расширения работают через SNMP, поэтому на клиентские машины ничего устанавливать не нужно. Я еще не исследовал все это, и, похоже, есть много функций, которые мне еще предстоит использовать. Он основан на Zope, поэтому, если вы не разбираетесь в установке Zope, я бы рекомендовал загрузить заранее подготовленную виртуальную машину - она работает как мечта прямо из коробки.
На коммерческом фронте вы можете взглянуть на несколько инструментов:
Kaseya - стоит около 6 тысяч в год за 250 узлов, если я правильно помню, но это превосходный инструмент с очень активным сообществом пользователей. Он нацелен на рынок msp и позволяет отслеживать системы нескольких компаний. Его можно без проблем использовать внутри.
GFI Hounddog - проще, чем Kaseya, но на данный момент очень дешево. Определенно стоит посмотреть.
Есть ряд решений, которые продаются как системы MSP, но по сути представляют собой мониторы + удаленное администрирование вместе.
Ян
Для централизованного системного журнала с множеством замечательных функций я не могу не рекомендовать rsyslog достаточно. Это сервер системного журнала с открытым исходным кодом, который может успешно работать в качестве замены для обычного syslogd, который вы знаете и любите. Теперь это демон системного журнала для Ubuntu, и я думаю, что Red Hat и Fedora также могут пойти по этому пути. Я обнаружил, что его намного проще приступить к работе и делать то, что вы хотите, это syslog-ng.
В настоящее время в нашем магазине есть два центральных сервера rsyslog (по одному на каждом сайте), которые получают журналы для сотен серверов. У меня есть автоматические уведомления по электронной почте, когда что-то в системном журнале вызывает предупреждение или выше (с некоторыми настройками, конечно, некоторые приложения немного паникуют). Я, вероятно, мог бы сделать еще кое-что, например, заставить его отправлять вещи на nagios или тому подобное, но на данный момент он покрывает нас достаточно для наших нужд.
Все это также входит в базу данных mysql (есть также поддержка Oracle или postgresql, если вы так катаетесь).
Также есть веб-интерфейс и агент Windows для отправки журналов журнала событий на сервер rsyslog. Веб-интерфейс явно не такой приятный, как splunk, но он выполняет свою работу за 0 долларов.
Взгляни на http://www.codeplex.com/polymon
Его открытый исходный код, использует SQL Server на бэкэнде и имеет красивый интерфейс.
Я согласен, что Splunk потрясающий. Однако для небольших сред с преобладанием Linux вы можете посмотреть что-то вроде эпилог.
Мы использовали его в одном из мест, где я работал, и он отлично подходил для того, что мы хотели.
Не уверен, насколько хорошо он будет обрабатывать сообщения системного журнала Windows, которые отправляются сборщику системного журнала Linux, но, возможно, стоит попробовать.
Просто ссылка на мой ответ еще где:
Splunk фантастически дорогой: какие есть альтернативы?
Изменить (новые проекты):
Что-то вроде GFI EventsManager может помочь примерно за 4 тыс. долларов.
Если вы ищете замену SysLog, вы также можете рассмотреть коммерческую замену syslog / rsyslog, такую как LogLogic, http://loglogic.com. У нас (там, где я работаю) есть полнофункциональный набор устройств для ведения журналов, хранения и отчетности. По сути, это способность собирать 100000 сообщений в секунду, обрабатывать и индексировать их, чтобы можно было выполнять поиск.
Вы можете попробовать logscape от liquidlabs - он очень похож на splunk, но также имеет несколько других функций .... http://www.liquidlabs-cloud.com/products/logscape.html
Я делал бэкэнд SQL на предыдущей работе (кстати, это был MySQL), в комплекте со сценариями, интерфейсом Drupal с настраиваемыми сценариями PHP, работой.
Честно говоря, на это ушло слишком много человеко-часов, и это все же не Спланк.
В настоящее время я тестирую Splunk. Да, это не бесплатно, но, глядя на картину в целом, это может быть дешевле.
Вы пробовали php-syslog-ng? http://code.google.com/p/php-syslog-ng/
Я опубликовал ветку обмана: Splunk фантастически дорогой: какие есть альтернативы?
xpolog и все серьезные коммерческие решения - БОЛЬШИЕ $ (даже если меньше, чем splunk, большинство легко 5-значные!)
Ооооо, что мы наконец сделали (потому что splunk стоил слишком дорого):
1) Нам нужен простой системный журнал для конвейера sql db
2) Мы попробовали kiwi syslog. Это отлично работало неделю, перестало работать, и служба поддержки kiwi не смогла это исправить. Итак, мы уронили киви
3) Мы пробовали winsyslog. Старое приложение, мы не хотели его изучать.
4) Мы использовали это бесплатное приложение .net: http://www.aonaware.com/syslog.htm
Вуаля. У нас есть сообщения системного журнала в нашей базе данных.
Мы очень счастливы. $ 0 потрачено, несколько часов, но не слишком много.
Здесь мы используем Splunk, и я немного шокирован ценами, которые они вам сказали. Базовая разбивка, которую нам дали, составила где-то около 1 тыс. Долларов США на 1 ГБ данных. Это дорого, но очень мощно и очень быстро в разработке. В зависимости от ваших источников данных и того, что вы хотите с ними делать, некоторые скрипты на Python и Perl могут предоставить вам много похожих данных. Большая разница будет во времени и в том, чтобы научиться действительно владеть языком для обработки текста. Вы также не сможете получать IP-информацию в реальном времени (например, системный журнал), хотя вы можете исправить это, установив системный журнал и выведя информацию в текстовый файл. Извините, я не могу указать вам какое-либо конкретное решение; то, что мы не можем использовать splunk, мы используем скрипты python, perl и bash.
ELSA - поиск и архив корпоративных журналов
Основные особенности:
Детали производительности:
Для спецификации системы в порядке важности: размер диска, RAM, скорость диска, количество процессоров. Основным фактором производительности является индексатор и демон поиска Sphinx, поэтому документацию можно найти на sphinxsearch.com. Приведенная мной статистика взята из больших систем (16 ЦП, 144 ГБ ОЗУ, 12 ТБ жесткого диска), но вы получите такую же производительность в системе с 4 ЦП, 8 ГБ ОЗУ и жестким диском любого размера, поскольку все масштабируется линейно. Система сначала работала на блейд-серверах IBM с 4 ГБ ОЗУ и медленными дисками SAN и работала примерно с той же скоростью, но 4 ГБ - это немного меньше.
Подробная информация о производительности и список основных функций, а также описание архитектуры: http://ossectools.blogspot.com/2011/03/fighting-apt-with-open-source-software.html
Код: https://code.google.com/p/enterprise-log-search-and-archive/
ВМ: http://ossectools.blogspot.com/2011/07/elsa-vmware-appliance-available.html
Подробности о проекте: http://ossectools.blogspot.com/2011/03/comprehensive-log-collection.html
Если вы ищете гораздо более доступную альтернативу Splunk - попробуйте LogZilla (http://www.logzilla.pro). Он масштабируется так же или лучше, чем Splunk (вы можете искать более 300 метров журналов примерно за 1-2 секунды) и легко составляет 1/10 стоимости. У них есть демо-версия http://demo.logzilla.pro