Ваш моніторинг теж є системою: тестуйте шлях, а не дашборд

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

Тиша не є доказом

Більшість дизайнів моніторингу ретельно перевіряють те, що моніториться, і приймають на віру сам моніторинг. Switch налаштовано надсилати syslog, тож вважається, що його логи надходять. Правило тривоги існує, тож вважається, що сповіщення когось досягає. Завдання backup заплановане, тож вважається, що копія конфігурації існує. Жодне з цих припущень не є вимірюванням.

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

Перевірка перша: чи справді чують кожен пристрій?

Погляд пристрою (show logging перелічує сервер і каже, що логування ввімкнено) є твердженням. Погляд колектора є доказом. Розверніть це і запитайте колектор: коли кожен пристрій востаннє щось надсилав?

У Graylog пошук, згрупований за джерелом за останню добу, показує кожен пристрій, який говорив; порівняйте цей список з вашим інвентарем, і все, чого бракує, є вашою знахідкою. Простий наскрізний тест із самого пристрою знімає всі сумніви. На Cisco IOS і NX-OS згенеруйте нешкідливе повідомлення і шукайте його на колекторі протягом секунд:

send log 6 "monitoring path test from this device"

На хості з Linux:

logger -p user.notice "monitoring path test from $(hostname)"

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

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

Перевірка друга: чи доходить тривога до людини?

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

У Zabbix достатньо тестового елемента на моніторюваному хості плюс тригера на тій критичності, за якої ви викликаєте людину. Надішліть значення і спостерігайте, як воно подорожує:

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Потім підтвердьте три речі: проблема з’явилася, сповіщення доставлено, і відновлення доставлено, коли ви скинули значення.

Перевірка третя: чи чесні критичності?

Перегляньте, які події доходять до людини, а які ні. Короткий, явний список сигнатур, які завжди викликають людину (сусід маршрутизації впав, лінк впав, BFD впав, збої криптографії VPN, несправності живлення, вентиляторів і температури, помилки мережі storage, таблиці станів firewall біля своєї межі), легше захистити, ніж поріг, який хтось задав роки тому.

Тут допомагає друга думка. Правила спочатку відфільтровують відомий шум, а потім усе, що залишилося, аналізується в реальному часі моделями AI на наших власних GPU NVIDIA A100, усередині нашого датацентру. Аналіз читає тривогу разом з її недавньою історією та пов’язаними подіями і пропонує інженерам другу думку про те, що, ймовірно, відбувається. Дані тривог ніколи не залишають нашу інфраструктуру, і рішення все одно ухвалює інженер.

Перевірка четверта: подивіться ззовні

Кожен погляд зсередини вашої мережі ділить сліпі плями вашої мережі. Глобальна платформа вимірювань, як-от RIPE Atlas, з anchor або пробами, що вимірюють у ваш бік, показує, як реальні місця в інтернеті дістаються до вас: затримка, втрати і зміни шляху. Коли оператор проводить обслуговування, погляд ззовні каже вам, скільки тривало повторне сходження і чи міг хтось це помітити, чого не може жоден внутрішній лічильник.

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

Перевірка п’ята: обходьте, коли нічого не зламано

Проводьте read-only обходи стану за розкладом, а не лише після тривоги. Умови середовища, стан маршрутизації та overlay, узгодженість резервування між парами, рівні оптики та лічильники помилок інтерфейсів змінюються повільно, а повільна зміна є саме тим, що пропускають порогові тривоги. Оптика, що дрейфує до своєї нижньої межі світла, є спокійною заміною цього тижня або простоєм наступного місяця.

Ваш чекліст самоперевірки моніторингу

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

Ми моніторимо нашу мережу за допомогою Zabbix, Graylog, Observium і anchor RIPE Atlas, і виконуємо ці перевірки на ній за розкладом. Якщо ви хочете провайдера, який відповідає вимірюваннями, або допомогу в тестуванні власного ланцюга, поговоріть з нами.

Поговоріть з інженером

Related (rows[1])

Пов’язане: Моніторинг мережі та докази · Як ми змінюємо речі: дисципліна змін у мережі · Наша власна мережа: дві ASN, багато операторів, peering