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

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

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

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

Какво е PagerDuty?

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

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

Кой е дежурният?

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

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

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

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

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

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

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

• Prometheus

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

• Имейл

Тук също, мисля, всичко е ясно от името. Тази интеграция се използва за изпращане на известия от някои скриптове, които се изпълняват по график. 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 и ако статусът им се променя, това също се отразява в чата.

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

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

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

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

Изходните кодове на тази реализация могат да бъдат намерени тук.

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

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