Чым складаней сістэма, тым больш яна абрастае разнастайнымі алертамі. І ўзнікае запатрабаванне на гэтыя самыя алерты рэагаваць, агрэгаваць іх і візуалізаваць. Думаю, сітуацыя, знаёмая шматлікім да нервовага ціка.
Рашэнне, пра якое пойдзе гаворка, не самае нечаканае, але паўнацэннага артыкула па гэтай тэме пошук не выдае.
Таму я вырашыў падзяліцца досведам 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