Збір логів з rsyslog, іменами файлів в тегах, багаторядковими повідомленнями і відмовостійкість

image
зображення з сайту oxygen-icons.org
Завдання
Передавати лог-файли на центральний сервер. Коли сервер не втрачати повідомлення, а накопичувати і передавати при його появу в мережі. Коректно передавати багаторядкові повідомлення.
Додатково:
  • не потрібно зміна конфігурації сервера при появі нових лог-файлів, досить перенастроювання клієнта.
  • можна передавати вміст всіх лог-файлів з відповідним шаблоном ім'ям, причому на сервері їх вміст буде зберігатися роздільно у файли з таким же ім'ям.
Умови: в інфраструктурі використовуються тільки Linux-сервера.
Читати далі →

Моніторинг системних викликів Linux



Якщо ви інженер в організації, що використовує Linux промислової експлуатації, у мене до вас два невеличких питання.
  1. Скільки унікальних вихідних TCP-з'єднань встановили ваші сервери за останню годину?
  2. Які процеси та користувачі ініціювали встановлення цих сполук?
Якщо ви в змозі відповісти на обидва питання, відмінно — далі можете не читати. А якщо відповіді немає, то отримати цю інформацію допоможе go-audit.
Читати далі →

Спосіб змусити Iptables писати в свій лог і не дублювати у системний

У замітці розповідається про налаштування журналювання iptables в окремий файл. Більшість посібників пропонують два підходи, але, на жаль, у мене на Debian вони так і не заробили. Точніше, логи писалися
/var/log/iptables.log
, але продовжували дублюватися в
/var/log/messages
та
/var/log/syslog
, що дуже дратувало і завдання була незавершеною. Знайшовши спосіб не дублювати повідомлення у системні, вирішив опублікувати отримані результати.

Читати далі →

Зручний моніторинг Syslog повідомлень c мережевих залозок у Zabbix

Невід'ємною частиною мережевого моніторингу є збір логів з контрольованих серверів та інших залозок. Адже скільки б ми не створили окремих елементів даних і тригерів до них, в якийсь момент виникне ситуація, що щось важливе ми випустили з уваги і не контролюємо. Підсумок: «У нас нічого не працює», а система моніторингу каже, що все добре.

Тому перше, що хотілося зробити — збирати всі логи в заббиксе, згрупувавши їх по вузлу мережі для того, щоб завжди можна було пробігтися за повідомленнями очима, не витрачаючи час на доступ на обладнання.
Другий — звернути увагу і на ті події, про які й не підозрюєш.

Як це зробити на серверах і комп'ютерах, де встановлено заббикс-агент, багато знають — є вбудовані елементи даних log[], logrt[].

Але як бути, коли треба збирати логи з мережевого обладнання, на яке ніяк не поставити Zabbix-agent? Взагалі-то можна, звичайно, налаштувати syslog-сервер на тому ж ПК, на якій є заббикс-агент, а далі за допомогою log[] переносити ці дані в заббикс. Ось тільки елементи даних і тригери з нього будуть прикріплені до вузла мережі з заббикс-агентом, що інтуїтивно малозрозуміло. А можна прикріпити ці дані безпосередньо до мережного пристрою? Можна.

Для цього нам знадобиться zabbix_sender, Zabbix API і rsyslog на машині з заббикс-сервером або заббикс-проксі. В якості бонусу також отримаємо швидкий контекстний перехід в журнал syslog-повідомлень з карти мережі.
Як буде виглядати результат? Ну, приблизно ось так:
Контекстний дзвінок:



Читати далі →