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

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

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



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

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

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

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

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

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

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



Читати далі →

Маленька адмінських історія: як зловити OOM

    Адмінських загадка: На сервері сталося три oom kill'а, а моніторинг сказав тільки про два. Чому?
 
 Конфігурація Для моніторингу всього у нас налаштована зв'язка ganglia-shinken-logstash-elasticsearch-kibana. Повний опис досить широко , так що обмежуся лише частиною, що має відношення до проблеми.
 
У logstash надсилаються логи з усіх серверів. Він їх складає в elasticsearch. У конфіге logstash'а налаштована реакція на всякі дивні повідомлення, які свідчать про проблеми. Якщо повідомлення з'являється, надсилається event моніторингу (shinken), який різними методами починає турбувати адмінів.
 
Крім syslog'ов, які шлють повідомлення від більшості додатків, у нас налаштована ще і відправка netconsole від усіх ядер. Сама технологія проста до неможливості — ядро ​​крім dmesg'а посилає повідомлення у вигляді UDP-датаграм на вказаний IP і mac-адресу. MAC-адресу потрібен тому, що netconsole дуже низкоуровневая і займатися розгадуванням «як з IP зробити MAC» (тобто ARP) не збирається. Завдяки Низькорівневий повідомлення проходять навіть у ситуаціях повного катаклізму. Наприклад, якщо програмний комутатор перестав працювати (і мережа недоступна), повідомлення все одно будуть надсилатися. Більше того, вони будуть надсилатися, навіть якщо в iptables сказано-j drop_vsyo_nafig. І, найголовніше і цінне, ці повідомлення успішно будуть відправлені, якщо дискова підсистема повністю не працює. Тобто для post-mortem досліджень «що саме сталося з завислим сервером» — саме воно.
 
Очевидним кандидатом в «погані» повідомлення є повідомлення від oom-killer'а.
 
 
[517935.914380] ntpd invoked oom-killer: gfp_mask = 0x201da, order = 0, oom_score_adj = 0
[517935.914730] Call Trace:
[517935.914807] [<ffffffff816e14ce>] dump_header +0 x83/0xbb
[517935.914877] [<ffffffff816e155b>] oom_kill_process.part.6 +0 x55/0x2cf
...
з фінальним переможним:
[517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child
[517935.951203] Killed process 4550 (apache2) total-vm: 2610268kB, anon-rss: 2012696kB, file-rss: 3928kB
 
 
Отже, повертаємося до загадки. Йде пусконалагодження, предпродакшен, як, раптом, апач (точніше, wsgi-додаток) насасивается даних до непристойності, і його прибивають зі словами «go be fat somewhere else». Адмінам приходить повідомлення. Здавалося б все добре (ну, в адмінській сенсі «добре»). Але…
 
Сталося три oom'а, повідомлення прийшли про два. Моніторинг в порядку, netconsole в порядку. Загадка? Проблеми? Симптоми таємничої невідомої фігні? Звати придворного шамана з бубном?
 
Читати далі →