Централізоване логування, яке витримує розбір інциденту

Справжній тест централізованого логування не в тому, чи надходять повідомлення тихого дня. Він у тому, чи зможете ви наступного ранку після того, як щось пішло не так, за кілька хвилин зібрати повну, правильно впорядковану хронологію по routers, firewall, сховищах і серверах. Для цього потрібен конвеєр, побудований саме для цього. Ось як ми будуємо наш у Graylog і що варто скопіювати для власного.

Починайте з питання, яке ви ставитимете

Кожне архітектурне рішення в конвеєрі логування має служити одному питанню: «що сталося, всюди, між цими двома моментами часу?» Це питання провалюється чотирма передбачуваними способами. Повідомлення відсутні для частини вікна. Той самий пристрій з’являється під кількома іменами, тож пошук знаходить лише частину його історії. Годинники не збігаються, тож події потрапляють у неправильний порядок. Або все лежить в одній невпорядкованій купі, тож важливі рядки поховані. Кожен розділ нижче прибирає одну з цих відмов.

Пересилайте надійно і буферизуйте на диск

Класичний syslog через UDP працює за принципом «надіслав і забув»: відправник ніколи не дізнається, чи щось отримало повідомлення. Для серверів ми віддаємо перевагу пересиланню через TCP з чергою на диску, щоб перезапуск колектора або збій мережі затримував логи замість того, щоб їх губити. Мінімальна дія rsyslog:

action(type="omfwd" target="<collector>" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList" queue.filename="fwd_central"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

Шаблон надсилає структуровані повідомлення RFC 5424 з повною міткою часу і hostname. Черга тримає недоставлені повідомлення на диску і повторює спроби, доки колектор не повернеться. Перевірте за допомогою rsyslogd -N1, перш ніж перезапускати сервіс.

Мережеві пристрої зазвичай обмежені звичайним syslog, тож для них захист інший: надсилайте на колектор з адреси-джерела і routing instance, які завжди можуть до нього дістатися, і перевіряйте цей шлях щоразу, коли змінюється маршрутизація пристрою.

Дайте кожному пристрою рівно одне ім’я

Виробники не згодні щодо того, що йде в заголовок syslog. Деякі пристрої пропускають власний hostname, деякі надсилають коротке ім’я, деякі надсилають адресу, і той самий пристрій може змінити формат після оновлення програмного забезпечення. Якщо колектор зберігає те, що прибуває, один router опиняється розмазаним по трьох іменах джерела, і пошук по ньому повертає третину його історії.

Ми виправляємо це на вході. Правило pipeline у Graylog переписує джерело кожного повідомлення на одне канонічне ім’я пристрою, використовуючи таблицю пошуку за адресою відправника:

rule "normalise source name"
when
  has_field("gl2_remote_ip")
then
  let name = lookup_value("device_names", to_string($message.gl2_remote_ip));
  set_field("source", name);
end

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

Налаштуйте годинники правильно

Кожен пристрій має логувати в UTC або нести явне зміщення. Змішування місцевого часу та UTC між пристроями є класичним способом змусити інцидент виглядати так, ніби він стався в неправильному порядку. Дві швидкі перевірки на хості Linux:

chronyc tracking      # offset from the reference, should be tiny
timedatectl           # time zone and whether NTP is synchronised

На мережевому обладнанні перевірте еквівалентну команду статусу і переконайтеся, що мітка часу логування містить дату, мілісекунди й часовий пояс. Секунд не досить, коли два routers реагують на ту саму подію.

Маршрутизуйте повідомлення в потоки за ролями

Один суцільний потік нечитабельний. Ми маршрутизуємо повідомлення в потоки за ролями: core routing, fabric дата-центру, firewall, сховище, хости. Оскільки кожне джерело тепер має чисте ім’я, маршрутизація зводиться до зіставлення імен або поля ролі, встановленого тим самим pipeline. Кожен потік має своїми природними читачами людей, які експлуатують ці системи, і кожен може мати власне зберігання, спроєктоване відповідно до того, чого вимагають сервіс і будь-який аудитор.

Тривога на проблеми і на тишу

Тривога на те, що передує проблемам

Щойно логи чисті й у правильному місці, цінні рядки мають досягати людини, поки вони ще мають значення. Ми визначаємо події для повідомлень, які зазвичай передують збою: сесія BGP падає, лінія «блимає», BFD оголошує шлях мертвим, сесії шифрування перемішуються на backbone, апаратна несправність, помилка fibre channel на fabric сховища, пул адрес закінчується. Вони йдуть черговому інженеру в операційний чат у момент виникнення, тож лог стає раннім попередженням замість розтину.

Тривога і на тишу

Пристрій, який перестає надсилати, виглядає точно так само, як пристрій, якому немає чого сказати. Тож ставте тривогу на відсутність: подію, яка спрацьовує, коли джерело, що зазвичай говорить, мовчить довше, ніж будь-коли. Для природно тихих пристроїв дайте їм що сказати, наприклад рядок heartbeat, який таймер пише щогодини, щоб тиша стала сигналом. Після будь-якої зміни, яка може порушити шлях, надішліть тестове повідомлення і знайдіть його на дальньому кінці; наша мережева команда описує цю перевірку, і решту самотестування моніторингу, у Тестуйте шлях тривоги, а не dashboard.

Перевірте власний конвеєр

• Чи з’являється якийсь пристрій під більш ніж одним іменем джерела?
• Що станеться з логами сервера, якщо колектор лежатиме десять хвилин?
• Чи всі годинники синхронізовані з тими самими джерелами, з явними часовими поясами?
• Чи можете ви знайти повідомлення кожного firewall в одному потоці?
• Чи є тривога на джерело, яке затихло?

Якщо ви хочете логи, на які можна покластися під час розбору інциденту, ми радо допоможемо побудувати конвеєр і протестувати його. Поговоріть з інженером

Related

Пов’язане: Телеметрія мережі й живлення, логування, виявлення DDoS · Моніторинг парку та маршрутизація тривог