PagerDuty, или защо отделът по експлоатация не може да спи през нощта

Колкото по-сложна е системата, толкова повече тя натрупва различни алерти. И възниква необходимост да реагираме на тези алерти, да ги агрегатираме и визуализираме. Мисля, че ситуацията е позната на много хора до нервен тик.

Решението, за което ще говорим, не е най-неочакваното, но търсенето на пълната статия по тази тема не дава резултати.

Затова реших да споделя опита на FunCorp и да разкажа как е организиран процесът на дежурства, кой звъни, защо и как всичко това може да се наблюдава.

Какво е PagerDuty?

И така, за да решим всички тези задачи, започнахме да търсим удобен инструмент. След кратки търсения, спряхме избора си на PagerDuty. PD ни се стори достатъчно пълно и лаконично решение с много интеграции и настройки. Какво всъщност представлява?

Ако накратко, PagerDuty е платформа за обработка на инциденти, която може да обработва постъпващите инциденти чрез различни интеграции, да настрои реда на дежурствата и след това да уведомява дежурния инженер в зависимост от нивото на инцидента (при високо ниво — телефонно обаждане, при ниско — уведомление от приложението/SMS).

Кой е дежурен?

Вероятно това е първото, с което трябва да започнете настройването на PD.

В FunCorp, както и в други компании, има почетната длъжност дежурен. Тя се предава от инженер на инженер веднъж на ден. Има така наречената първа и втора линия за реакция на алерта от PagerDuty. Да предположим, идва алерт с висок приоритет, и ако в рамките на 10 минути след обаждането до дежурния от първата линия няма реакция (т.е. статусът му не е променен на потвърден или решен), обаждането отива при втория дежурен инженер. Това се настройва в самия PagerDuty чрез Политики на ескалация.

Ако и вторият дежурен не отговори, уведомлението се връща обратно на главния дежурен.

По този начин, всеки постъпващ алерт с висок приоритет не може да остане необработен. 

Сега да видим откъде могат да идват инцидентите.

Какви интеграции използваме?

В PD постъпват много разнообразни инциденти от различни услуги. В момента имаме около 25 такива услуги и за тяхната обработка използваме някои от готовите интеграции.

• Prometheus

Основната система за събиране на метрики е Prometheus. За нея вече е писано много в Хабра, само ще спомена, че имаме няколко инстанции за различни среди: едната събира метрики от виртуални машини и контейнери, другата — от услуги на Amazon, третата — от „физически машини“. Основният експортьор на метрики е Telegraf.

• Email

Тук също мисля, че всичко е ясно от заглавието. Тази интеграция се използва за изпращане на известия от определени скриптове, изпълнявани по график. PD ви предоставя адрес, на който изпращате имейли. При създаване на услуга с такава интеграция можете да конфигурирате приоритетите, в какъв ред ще бъдат обработвани входящите инциденти, как точно да се създаде аларма (за всеки входящ имейл, за входящ имейл + определено правило и т.н.).

• Slack

На мен ми се струва, че това е много интересна интеграция. Има случаи, когато се случва нещо, но не се покрива от инциденти. Затова добавихме интеграция от Slack за създаване на инцидент. Тоест, в корпоративния Slack може да напишете /callofduty все тормозит и скоро сломается и PD ще обработи това и ще изпрати инцидент на дежурния инженер.

Правим:

Виждаме:

• API

HTTP интеграция. Тук всъщност няма нищо особено интересно, просто POST-запитване с тяло в JSON формат. Например, от интересното: използваме я за външен мониторинг с помощта на https://www.statuscake.com/. Тази услуга проверява наличността на нашите сайтове от различни точки по света. В случай, че получим неприемлив код за отговор (например, 502) се създава инцидент и всичко продължава по веригата, описана по-горе. В StatusCake има възможност за мониторинг на вътрешни URL адреси, изтичане на SSL сертификат или домейн.

• LibreNMS

Това е друга система за мониторинг, повече информация можете да прочетете на техния сайт https://www.librenms.org/. С нейната помощ осъществяваме мониторинг на мрежовите интерфейси и iDRAC на сървърите.

Имаше и такива интеграции, като Datadog, CloudWatch. Повече информация за това какво се случи с тях можете да видите са тук.

Визуализация

Основната система за информиране за инциденти е Slack. В специален чат се записват всички входящи инциденти в PD, и ако статусът им се променя, това също се отразява в чата.

Когато се появи възможност да покажем полезни данни на екрани, висящи от тавана, изведнъж осъзнахме, че нямаме какво да покажем (в devops отдела). Има страхотна Grafana, но тя не може да обхване всичко, а служителите реагират на аларми, а не на графики.

След внимателно, но безуспешно търсене в GitHub за лаконична и информативна "борда" за PD, решихме да напишем своя — само с това, от което имаме нужда. Първоначално беше идея да покажем екрана на самия интерфейс на PD, но това изглеждаше още по-неудобно.

За да я напишем, е достатъчно да получим ключ от PD с права само за четене.
И ето какво постигнахме:

На екрана се показват актуалните отворени инциденти, името на текущия дежурен инженер от избраното разписание и времето без инцидент с висок приоритет (панелът с инцидент с висок приоритет ще бъде обозначен с червен цвят).

Изходният код на тази реализация може да се види тук.

В крайна сметка получихме удобен дашборд за преглед на всички наши инциденти. Ще се радвам, ако опитът ни бъде полезен на някого от вас.

Източник: habr.com