Тривога є повідомленням людині, а не рядком у лозі

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

Виявлення дешеве, увага дорога

Більшість налаштувань моніторингу провалюються не тому, що пропускають проблему. Вони провалюються тому, що ніхто не читає те, що вони видають. Поштові сповіщення падають у теку, яка наповнюється швидше, ніж хтось може її спорожнити. Dashboards стають червоними і лишаються червоними тижнями, доки червоне не перестане означати хоч щось. Інженер, який нарешті помічає, зазвичай реагує на клієнта, а не на монітор.

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

Вирішіть, чому дозволено досягати людини

Почніть із рівня важливості й будьте суворими. Кожен тригер Zabbix несе рівень, від information до disaster. Ми маршрутизуємо черговому інженеру лише два верхні, high і disaster, і кожен тригер на цьому рівні має пройти один тест: якщо це спрацює вночі, чи потрібно комусь діяти до ранку? Якщо чесна відповідь ні, це warning. Warnings належать dashboards і щоденному огляду, а не чиїйсь кишені.

У Zabbix це рішення живе у двох місцях: в умовах action (рівень тригера більший або дорівнює High) і у фільтрі рівня на media користувача. Встановіть обидва і зробіть так, щоб вони збігалися. Action, який збігається з усім, у поєднанні з фільтром media, який тихо відкидає половину, є конфігурацією, про яку ніхто не може міркувати о третій ночі.

Потім придушіть відлуння. Коли падає комутатор, кожен хост за ним також стає недосяжним. Залежності тригерів кажуть Zabbix, що тривоги хостів залежать від тривоги комутатора, тож інженер отримує одну тривогу, яка називає причину, замість сорока, які називають симптоми.

Доставляйте туди, де інженер уже є

Наші тривоги виходять із Zabbix через webhook у виділений операційний канал у Mattermost, чат, у якому наші інженери працюють цілий день і носять на телефонах уночі. Чат б’є пошту для тривог із практичних причин. Це місце, куди люди вже дивляться. Він показує, хто бачив повідомлення. І розмова про виправлення відбувається в гілці під тривогою, тож гілка стає записом того, що було зроблено і коли.

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

Зробіть відповідальність видимою

Тривога, яку бачили троє і ніхто не взяв, така ж погана, як та, яку не бачив ніхто. Підтвердження закриває цю прогалину. Коли черговий інженер підтверджує проблему в Zabbix з короткою нотаткою, усі інші бачать, що вона має власника, а нотатка є першим рядком запису. Якщо ваша команда має другу лінію, крок ескалації в action (додаткове сповіщення, коли проблема високого рівня все ще не підтверджена через задану кількість хвилин) перетворює «хтось, мабуть, подивиться» на правило.

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

Доведіть, що це працює

Доводьте ланцюжок після кожної зміни

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

Налаштовуйте на хост, ніколи не глушіть наосліп

Спільні шаблони є місцем, де народжується втома від тривог. Один сервер бази даних легітимно працює гаряче, хтось підіймає поріг CPU у шаблоні, щоб його втихомирити, і кожен інший хост у парку щойно втратив корисну тривогу. Ми ніколи не редагуємо спільний шаблон, щоб налаштувати одну машину. Пороги, які мають відрізнятися, встановлюються як перевизначення макросів на рівні хоста, наприклад власне значення цього хоста для {$CPU.UTIL.CRIT}, щоб налаштування однієї машини ніколи не змінювало тривоги на іншій.

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

Стежте за тим, хто стежить

Монітор, який зупинився, гірший за жодного, бо ви довіряєте його тиші. Дві перевірки покривають більшу частину ризику. Усередині Zabbix тригер nodata на кожному агенті, такий як nodata(/<host>/agent.ping,5m)=1, ловить хост, який перестав звітувати, що є іншою й тихішою відмовою, ніж хост, який звітує про проблеми. Поза Zabbix щось незалежне має помітити, коли сама платформа затихає: heartbeat, який сервер надсилає за розкладом в окрему систему, яка підіймає власну тривогу, коли heartbeat перестає надходити.

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

Друга думка, перш ніж інженер прочитає

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

Якщо ви будуєте щось подібне, тримайте ту саму межу. AI анотує тривогу. Людина володіє рішенням.

Перевірте власний ланцюжок

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

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

Related

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