Чим складніша система, тим більше вона обростає всілякими алертами. І виникає потреба на ці алерти реагувати, агрегувати їх і візуалізувати. Думаю, ситуація, знайома багатьом до нервового тику.
Рішення, про яке піде мова, не найнесподіваніше, але повноцінної статті на цю тему пошук не видає.
Тому я вирішив поділитися досвідом FunCorp і розповісти про те, як збудований процес чергувань, хто дзвонить, чому і як на це все можна дивитися.
Що таке PagerDuty?
Отже, щоб вирішити ці завдання, ми почали шукати зручний інструмент. Після недовгих пошуків ми зупинили свій вибір на PagerDuty. PD здалася нам досить повним та лаконічним рішенням з великою кількістю інтеграцій та налаштувань. Що вона собою являє?
Якщо коротко, PagerDuty — це платформа для обробки інцидентів, яка вміє обробляти інциденти через різні інтеграції, налаштовувати порядок чергувань і далі здійснювати алертинг черговому інженеру в залежності від рівня інциденту (при високому рівні — дзвінок, при низькому — пуш від програми/смс) .
Хто такий черговий?
Напевно, це перше, з чого треба розпочинати налаштування PD.
У FunCorp, як і інших компаніях, є почесна посада чергового. Вона передається від інженера до інженера щодня. Є так звана перша та друга лінія реагування на алерт від PagerDuty. Припустимо, приходить алерт високого пріоритету, і якщо через 10 хвилин після дзвінка черговому з першої лінії на нього немає реакції (тобто він не переведений у статус acknowledge або resolved), дзвінок йде другому черговому інженеру. Це налаштовується у самому PagerDuty через Escalation Policies.
Якщо і другий черговий не відповідає, то оповіщення повертається до головному черговому.
Таким чином, будь-який алерт високого пріоритету не може залишитися необробленим.
Тепер побачимо, звідки можуть приходити інциденти.
Які інтеграції використовуємо?
У PD сипається багато різноманітних інцидентів від різноманітних сервісів. У нас зараз таких сервісів близько 25 і для їх обробки ми використовуємо деякі готові інтеграції.
- Прометей
Основною системою збору метрик є Prometheus. Про неї вже багато написано на Хабрі, я тільки скажу, що у нас їх дещо під різні середовища: одне збирає метрики з віртуалок і докерів, інше — із сервісів амазону, третє — із «залізних машин». В основному, як експортер метрик використовується Telegraf.
- Електронна адреса
Тут теж, гадаю, все зрозуміло з назви. Ця інтеграція використовується для надсилання повідомлень від деяких скриптів, які виконуються по крону. PD видає вам якусь адресу, на яку ви надсилаєте листи. При створенні сервісу такою інтеграцією ви можете налаштувати пріоритети, в якому порядку будуть оброблятися вхідні інциденти, як саме створювати алерт (на кожний лист, на лист + певне правило і т.д.).
- Млявий
На мою думку, дуже цікава інтеграція. Трапляються випадки, коли відбувається щось, але не покривається інцидентами. Тому ми додали інтеграцію із Slack для створення інциденту. Т. е. в корпоративний Slack можна написати /callofduty все гальмує і скоро зламається і PD обробить це та відправить інцидент черговому інженеру.
Робимо:
Бачимо:
- API
Інтеграція з HTTP. Тут, насправді, немає особливо нічого цікавого, просто POST-запит із тілом у JSON-форматі. Наприклад, з цікавого: ми використовуємо її для зовнішнього моніторингу за допомогою . Цей сервіс перевіряє доступність наших сайтів із різних точок світу. У випадку, коли ми отримуємо неприйнятний код відповіді (наприклад, 502) створюється інцидент і далі йде по ланцюжку, описаному вище. У самому StatusCake є можливість моніторингу внутрішніх урлів, закінчення терміну SSL-сертифіката або домену.
- LibreNMS
Це ще одна система моніторингу, детальніше про неї можна почитати на їхньому сайті . З її допомогою ми здійснюємо моніторинг мережевих інтерфейсів та iDRAC із серверів.
Існували ще такі інтеграції, як Datadog, CloudWatch. Докладніше про те, що з ними стало, можна переглянути .
Візуалізація
Основною системою інформування про інцидент є Slack. У спеціальний чат пишуться всі інциденти, що приходять в PD, і якщо змінюється їх статус, це також відображається в чаті.
Коли з'явилася можливість вивести корисні дані на екрани моніторів, що висять під стелею, ми раптово зрозуміли, що нам (в devops-відділі) нічого на них виводити. Є чудова Grafana, але їй не охопити, та й співробітники реагують на алерти, а не на графіки.
Після ретельного, але безуспішного пошуку GitHub лаконічної та інформативної «борди» для PD, ми вирішили написати свою — тільки з тим, що потрібно нам. Хоча спочатку була ідея вивести на екран сам інтерфейс PD, але це виглядало ще незручнішим.
Щоб написати її, вистачає лише отримання ключа від PD з read-only правами.
І ось що в нас вийшло:
На екрані виводяться актуальні відкриті інциденти, ім'я поточного чергового інженера з вибраного розкладу та час без інциденту високого пріоритету (панель з інцидентом високого пріоритету буде виділена червоним кольором).
.
У результаті ми отримали зручний дашборд для перегляду всіх інцидентів. Буду радий, якщо комусь із вас стане у нагоді наш досвід.
Джерело: habr.com