Транспорт і агрегація журналу в масштабі


14

Як ви аналізуєте файли журналів з машин UNIX / Linux? Ми запускаємо кілька сотень серверів, які генерують власні файли журналів, безпосередньо або через syslog. Я шукаю гідне рішення, щоб зібрати ці та вибрати важливі події. Ця проблема розпадається на 3 компоненти:

1) Транспорт повідомлень

Класичний спосіб - використовувати syslog для реєстрації повідомлень на віддаленому хості. Це добре працює для програм, які входять у syslog, але менш корисні для додатків, які записують у локальний файл. Рішення для цього можуть включати в себе запис журналу додатків у FIFO, підключений до програми для надсилання повідомлення за допомогою syslog, або написання чогось, що дозволить зірвати локальні файли та надіслати вихід на центральний хост syslog. Однак, якщо ми підемо на проблему написання інструментів для отримання повідомлень у syslog, чи краще нам замінити всю партію чимось на зразок Scribe у Facebook, який пропонує більшу гнучкість та надійність, ніж syslog?

2) Агрегація повідомлень

Записи журналу поділяються до одного з двох типів: за хостом та за послугу. Повідомлення на хост - це ті, які трапляються на одній машині; Подумайте про збої диска або підозрілі входи. Повідомлення за послугу трапляються на більшості або всіх хостах, які працюють із послугою. Наприклад, ми хочемо знати, коли Apache виявляє помилку SSI, але ми не хочемо тієї ж помилки на 100 машинах. У всіх випадках ми хочемо бачити лише одне із кожного типу повідомлень: ми не хочемо, щоб 10 повідомлень про те, що той самий диск вийшов з ладу, і ми не хочемо повідомлення кожного разу, коли пошкоджена SSI-адреса.

Один із підходів до вирішення цього питання полягає в об'єднанні декількох повідомлень одного типу в одне на кожному хості, відправлення повідомлень на центральний сервер, а потім об'єднання повідомлень одного типу в одну загальну подію. SER може це зробити, але це незручно використовувати. Навіть через пару днів неприємностей у мене працювали лише рудиментарні агрегації, і мені доводилося постійно шукати логіку використання СЕР для кореляції подій. Це потужний, але хитрий матеріал: мені потрібно щось, що мої колеги можуть забрати та використати в найкоротші терміни. Правила SER не відповідають цій вимозі.

3) Генерація сповіщень

Як ми повідомляємо своїх адміністраторів, коли трапляється щось цікаве? Надіслати групу вхідних повідомлень групи? Ін’єкції в Нагіос?

Отже, як ти вирішуєш цю проблему? Я не очікую відповіді на тарілці; Я можу опрацювати деталі самостійно, але було б чудово обговорити те, що, звичайно, є загальною проблемою. На даний момент ми використовуємо меш-мейд із роботи із крон, syslog і хто знає, що ще знайти події. Це не розширюється, не може бути гнучким або гнучким, і, як такий, ми пропускаємо багато чого, чого не повинні.

Оновлено: ми вже використовуємо Nagios для моніторингу, що чудово підходить для виявлених хостів / послуг тестування / тощо, але менш корисно для скреблінгу файлів журналів. Я знаю, що для Nagios є додатки для журналів, але мене цікавить щось більш масштабоване та ієрархічне, ніж сповіщення про кожного хоста.


Відповіді:


5

Я використовував три різні системи для централізації журналів:

  1. Переадресація Syslog / syslog-ng на один хост
  2. Zenoss для агрегування та оповіщення про події
  3. Спінк для агрегації журналу та пошуку

Для №3 я, як правило, використовую syslog-ng для пересилання повідомлень від кожного хоста безпосередньо в окно. Він також може безпосередньо проаналізувати файли журналів, але це може викликати біль.

Splunk досить приголомшливий для пошуку та категоризації ваших журналів. Я не використовував спленк для оповіщення журналу, але думаю, що це можливо.


+1 для Splunk. Ви можете мати зовнішні сценарії тригера Splunk, коли виявляються певні події; або надсилання пошти або SNMP-пастки.
Муралі Суріар

2

Ви можете подивитися OSSEC, повний HID з відкритим кодом, він робить аналіз журналу та може запускати дії або надсилати пошту на сповіщення. Сповіщення викликає набір простих правил на основі XML, включено безліч попередньо визначених для різних форматів журналів, і ви можете додати свої власні правила

http://www.ossec.net/


1

Погляньте на восьминога . Це повністю настроюється і, здається, відповідає всім вашим потребам ...

PS: Я розробник цього рішення.


1
Я б не хотів ризикувати розгортанням або навіть рекомендуванням продукту, який має назву "кицька". Це, мабуть, не вдасться переконатись у більшості компаній, особливо, якщо є жінки, які працюють в ІТ (досить поширене в ці дні).
Морська зірка

0

Вам потрібно заглянути в систему моніторингу, наприклад, Zenoss Core . Крім усього іншого, на сторінці вступу написано:

Моніторинг та управління подіями Zenoss надає можливість агрегувати інформацію про журнали та події з різних джерел, включаючи моніторинг доступності, моніторинг продуктивності, джерела системного журналу, джерела лову SNMP, журнал подій Windows.

Дивіться , що-інструмент-робити-ви-використання-на-монітор-ваші-сервера .


Я не знав, що у Zenoss є функції агрегації журналів. Я погляну - дякую.
Маркдрайтон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.