SRE (Site Reliability Engineering) бул веб-долбоорлордун жеткиликтүүлүгүн камсыз кылуу ыкмасы. Бул DevOps үчүн негиз болуп эсептелет жана DevOps тажрыйбаларын колдонууда ийгиликке кантип жетишүү керектиги жөнүндө айтылат. Бул макалада котормо китептер Google'дан. Мен бул котормону өзүм даярдадым жана мониторинг процесстерин түшүнүүдө өз тажрыйбама таяндым. Телеграм каналда и Мен ошондой эле кызмат деңгээлинин максаттары жөнүндө ошол эле китептин 4-бөлүмүнүн котормосуна шилтемени жарыяладым.
Которуу мышык. Окуудан ырахат алыңыз!
Google'дун SRE командаларында ийгиликтүү мониторинг жана билдирүү системаларын түзүү үчүн негизги принциптер жана мыкты тажрыйбалар бар. Бул бөлүмдө веб-баракчага кирген адам кандай көйгөйлөргө дуушар болушу мүмкүн жана веб-баракчаларды көрсөтүүнү кыйындаткан көйгөйлөрдү кантип чечүү керектиги боюнча көрсөтмөлөрдү берет.
аныктоо
Мониторингге байланыштуу темаларды талкуулоо үчүн колдонулган бирдиктүү лексика жок. Ал тургай, Google'да төмөндөгү терминдер көп колдонулбайт, бирок биз эң кеңири таралган чечмелөөлөрдү тизмектейбиз.
Мониторинг
Система жөнүндө реалдуу убакыт режиминде сандык маалыматтарды чогултуу, иштетүү, топтоо жана көрсөтүү: суроо-талаптардын саны жана сурамдардын түрлөрү, каталардын саны жана каталардын түрлөрү, суроо-талаптарды иштетүү убактысы жана сервердин иштөө убактысы.
Ак кутуга мониторинг
Системанын ички компоненттери, анын ичинде журналдар, Java Виртуалдык Машинасынын профилин түзүү көрсөткүчтөрү же ички статистиканы түзгөн HTTP иштеткичтеринин көрсөткүчтөрүнө негизделген мониторинг.
Кара кутуга мониторинг
Колдонмонун жүрүм-турумун колдонуучунун көз карашынан текшерүү.
Куралдар тактасы
Кызматтардын негизги ден соолук көрсөткүчтөрүн карап чыгууну камсыз кылган интерфейс (көбүнчө веб). Куралдар тактасында фильтрлер, көрсөтүлгөн индикаторлорду тандоо мүмкүнчүлүгү жана башкалар болушу мүмкүн. Интерфейс колдонуучулар үчүн эң маанилүү болгон индикаторлорду аныктоого арналган. Куралдар тактасы техникалык колдоо кызматкерлери үчүн маалыматты да көрсөтө алат: суроо-талаптардын кезеги, артыкчылыктуу каталардын тизмеси жана жоопкерчиликтин берилген чөйрөсү үчүн дайындалган инженер.
Эскертүү (билдирүү)
Каталардан же суроо кезегинин көбөйүшүнөн улам келип чыгышы мүмкүн болгон электрондук почта же башка ыкмалар аркылуу адам тарабынан кабыл алынууга арналган эскертмелер. Билдирмелер төмөнкүдөй классификацияланат: билеттер, электрондук почта эскертүүлөрү жана заматта кабарчы билдирүүлөрү.
Негизги себеп
Оңдолгондон кийин кайра кайталанбашы керек болгон программалык кемчилик же адамдык ката. Көйгөйдүн бир нече негизги себептери болушу мүмкүн: процессти автоматташтыруунун жетишсиздиги, программалык камсыздоонун бузулушу, колдонмо логикасынын жетишсиз иштелип чыгышы. Бул факторлордун ар бири негизги себеп болушу мүмкүн жана алардын ар бири жок кылынышы керек.
Түйүн жана машина (түйүн жана машина)
Физикалык серверде, виртуалдык машинада же контейнерде иштеп жаткан тиркеменин бир нускасына шилтеме кылуу үчүн алмаштырылуучу терминдер. Бир машина бир нече кызматтарды кабыл алат. Кызматтар болушу мүмкүн:
- бири-бири менен байланышкан: мисалы, кэш сервери жана веб-сервер;
- бир аппараттык бөлүктө байланышпаган кызматтар: мисалы, код репозиторий жана конфигурация системасы үчүн уста, мисалы же .
түртүү
Программанын конфигурациясындагы ар кандай өзгөртүү.
Эмне үчүн мониторинг керек?
Колдонмолорго мониторинг жүргүзүүнүн бир нече себептери бар:
Узак мөөнөттүү тенденцияларды талдоо
Маалымат базасы канчалык чоң жана ал канчалык ылдам өсүүдө? Колдонуучулардын күнүмдүк саны кандай өзгөрөт?
Ишти салыштыруу
Ajax DB 2.72 менен салыштырганда Acme Bucket of Bytes 3.14 боюнча суроо-талаптар тезирээк болобу? Кошумча түйүн пайда болгондон кийин сурамдар канчалык жакшыраак? Сайт өткөн аптага салыштырмалуу жайыраак иштеп жатабы?
Эскертүү
Бир нерсе бузулуп, кимдир бирөө аны оңдоого муктаж. Же жакында бир нерсе бузулуп, кимдир бирөө аны жакында текшериши керек.
Башкаруу такталарын түзүү
Куралдар такталары негизги суроолорго жооп берип, бир нерсени камтышы керек — кечигүү (кечүүлөр), трафик (трафик), каталар (каталар) жана жүктүн көлөмү (каныктыруу).
Ретроспективдүү талдоо жүргүзүү (мүчөлөрдү оңдоо)
Өтүнүчтү иштетүү кечигүү көбөйдү, бирок ошол эле учурда дагы эмне болду?
Мониторинг системалары бизнес чалгындоо системалары үчүн маалымат булагы катары жана коопсуздук инциденттерин талдоону жеңилдетүү үчүн пайдалуу. Бул китеп SRE тажрыйбасы бар инженердик тармактарга багытталгандыктан, биз бул жерде мониторинг жүргүзүү ыкмаларын талкуулабайбыз.
Мониторинг жана эскертүүлөр система качан бузулганын же бузулуу алдында турганын айтууга мүмкүндүк берет. Система өзүн автоматтык түрдө оңдой албаганда, биз адамдан эскертүүнү талдап, көйгөй дагы эле активдүү экендигин аныктап, аны чечип, түпкү себебин аныкташын каалайбыз. Эгер сиз тутум компоненттерин текшербесеңиз, сиз эч качан "бир аз кызыктай сезилгендиктен" эскертүү албайсыз.
Адамды эскертмелер менен жүктөө - кызматкердин убактысын бир топ кымбат пайдалануу. Эгерде кызматкер иштеп жатса, эскертүү иш процессин үзгүлтүккө учуратат. Кызматкер үйдө болсо, эскертүү жеке убакытты үзгүлтүккө учуратып, балким уктап калышы мүмкүн. Эскертүүлөр өтө тез-тез пайда болгондо, кызматкерлер аларды карап чыгып, аларды өчүрүп коюшат же келген эскертүүлөргө көңүл бурушпайт. Мезгил-мезгили менен алар ызы-чуу окуялары менен капталган чыныгы эскертүүгө көңүл бурушпайт. Кызматтын үзгүлтүккө учурашы узак убакытка созулушу мүмкүн, анткени ызы-чуу окуялар көйгөйдү тез аныктоого жана оңдоого тоскоол болот. Натыйжалуу эскертүү системалары жакшы сигнал-ызы-чуу катышы бар.
Мониторинг системасы үчүн негиздүү күтүүлөрдү коюу
Татаал колдонмо үчүн мониторингди орнотуунун өзү татаал инженердик милдет. Чогултуу, көрсөтүү жана эскертүү куралдарынын олуттуу инфраструктурасына карабастан, 10–12 мүчөдөн турган Google SRE командасы адатта бир же эки адамды камтыйт, алардын негизги максаты мониторинг системаларын куруу жана колдоо болуп саналат. Мониторинг инфраструктурасын бириктирип, борборлоштургандыктан, бул сан убакыттын өтүшү менен азайып кетти, бирок ар бир SRE командасында, адатта, мониторинг үчүн гана арналган жок дегенде бир адам бар. Мониторинг тутумунун инструменталдык такталарын көрүү абдан кызыктуу болгону менен, SRE топтору көйгөйлөрдү көзөмөлдөө үчүн кимдир-бирөөнүн экранды кароосун талап кылган кырдаалдардан этияттык менен качышат.
Жалпысынан, Google оптималдуу кийин талдоо куралдары менен жөнөкөй жана тез мониторинг системаларына өттү. Биз босоголорду алдын ала айтууга же түпкү себебин автоматтык түрдө аныктоого аракет кылган "сыйкырдуу" системалардан качабыз. Акыркы колдонуучунун суроо-талаптарында күтүлбөгөн мазмунду аныктаган сенсорлор бир гана каршы мисал болуп саналат; Бул сенсорлор жөнөкөй бойдон калса, алар олуттуу аномалиялардын себептерин тез аныктай алышат. Мониторинг маалыматтарын колдонуунун башка форматтары, мисалы, кубаттуулукту пландаштыруу же трафикти болжолдоо, татаалыраак. Төмөн тандап алуу ылдамдыгы (саат же күн) менен өтө узак убакыт аралыгында (айлар же жылдар) байкоо жүргүзүү узак мөөнөттүү тенденцияны ачып берет.
Google SRE командасы татаал көз карандылык иерархиялары менен аралаш ийгиликке жетишти. Биз "эгер мен маалымат базасы жай иштеп жатканын билсем, маалымат базасы жай иштеп жатат деген эскертүү алам, антпесе сайт жай иштеп жатат" деген сыяктуу эрежелерди сейрек колдонобуз. Көз карандылыкка негизделген эрежелер адатта биздин системанын өзгөрүлгүс бөлүктөрүнө, мисалы, маалымат борборуна колдонуучу трафигин чыпкалоо системасы сыяктуу. Мисалы, "эгер маалымат борборуна трафикти чыпкалоо конфигурацияланган болсо, колдонуучунун суроо-талаптарын иштетүүдөгү кечигүүлөр жөнүндө мага эскертпеңиз" бул маалымат борборунан эскертүүлөрдүн жалпы эрежеси. Google'дун бир нече командалары татаал көз карандылык иерархияларын колдойт, анткени биздин инфраструктурада үзгүлтүксүз рефакторинг туруктуу ылдамдыгы бар.
Бул бөлүмдө сүрөттөлгөн кээ бир идеялар актуалдуу бойдон калууда: өзгөчө дайыма өзгөрүп туруучу системаларда симптомдон негизги себепке тезирээк өтүү мүмкүнчүлүгү дайыма бар. Ошондуктан, бул бөлүмдө мониторинг системаларынын кээ бир максаттары жана ал максаттарга жетүү жолдору баяндалганы менен, мониторинг системалары командадагы бардык адамдар үчүн жөнөкөй жана түшүнүктүү болушу маанилүү.
Ошо сыяктуу эле, ызы-чуунун деңгээлин төмөн жана сигналдын деңгээлин жогору кармоо үчүн, эскертилген активдерге мониторинг жүргүзүү ыкмалары абдан жөнөкөй жана ишенимдүү болушу керек. Адамдар үчүн эскертүүлөрдү жараткан эрежелер түшүнүктүү жана так көйгөйдү көрсөтүүгө оңой болушу керек.
Симптомдор себептерге каршы
Мониторинг системаңыз эки суроого жооп бериши керек: "эмне бузулду" жана "эмне үчүн ал сынып кетти".
"Эмне сынды" симптом жөнүндө, ал эми "эмне үчүн сынды" себеби жөнүндө сөз кылат. Төмөндөгү таблицада мындай байланыштардын мисалдары көрсөтүлгөн.
Белги
акыл
HTTP катасы 500 же 404 алынууда
Берилиштер базасы серверлери байланыштарды четке кагат
Жай сервер жооптору
Жогорку CPU колдонуу же бузулган Ethernet кабели
Антарктидадагы колдонуучулар мышыктын GIF сүрөттөрүн алышпайт
Сиздин CDN илимпоздорду жана мышыктарды жек көрөт, ошондуктан кээ бир IP даректер кара тизмеге киргизилди
Жеке мазмун бардык жерден жеткиликтүү болуп калды
Жаңы программалык камсыздоонун релизинин чыгышы брандмауэрди бардык ACLлерди унутуп, бардыгына кирүүгө мүмкүнчүлүк берди
"Эмне" жана "эмне үчүн" максималдуу сигнал жана минималдуу ызы-чуу менен жакшы мониторинг системасын түзүү үчүн абдан маанилүү курулуш материалы болуп саналат.
Кара куту vs Ак куту
Биз кеңири White-box мониторинги менен критикалык көрсөткүчтөр үчүн жөнөкөй Black-box мониторингин бириктиребиз. Black-box менен White-boxту салыштыруунун эң оңой жолу - бул Black-box симптомдорго багытталган жана проактивдүү мониторингдин ордуна реактивдүү: "система азыр туура иштебей жатат". Ак куту системалардын ички текшерүү мүмкүнчүлүктөрүнөн көз каранды: окуялар журналдары же веб-серверлер. Ошентип, White-box күтүлүүчү көйгөйлөрдү, өтүнүчтү кайра жөнөтүү сыяктуу көрүнгөн мүчүлүштүктөрдү ж.б. аныктоого мүмкүндүк берет.
Көп катмарлуу системада бир инженердин жоопкерчилик чөйрөсүндөгү симптом башка инженердин жоопкерчилик чөйрөсүндөгү симптом экенине көңүл буруңуз. Мисалы, маалымат базасынын иштеши төмөндөдү. Жай маалымат базасы аларды аныктаган маалымат базасы SRE симптому болуп саналат. Бирок, жай веб-сайтты байкаган алдыңкы SRE үчүн, ошол эле жай маалымат базасынын окулушу жай маалымат базасы болуп саналат. Ошондуктан, ак кутуча мониторинги анын канчалык масштабдуу экендигине жараша кээде симптомдорго, кээде себеп-багытталган.
Мүчүлүштүктөрдү оңдоо үчүн телеметрияны чогултууда, White-box мониторинги талап кылынат. Эгерде веб-серверлер маалымат базасынын сурамдарына жай жооп берсе, анда веб-сервер маалымат базасы менен канчалык тез байланышат жана ал канчалык тез жооп берерин билишиңиз керек. Болбосо, маалымат базасынын жай серверин жана веб-сервер менен маалымат базасынын ортосундагы тармак көйгөйүн айырмалай албай каласыз.
Кара кутучанын мониторинги эскертүүлөрдү жөнөтүүдө негизги артыкчылыкка ээ: көйгөй мурунтан эле реалдуу симптомдор менен коштолгондо, сиз алуучуга эскертмени иштетесиз. Башка жагынан алганда, али пайда боло элек, бирок жакында боло турган Black-box көйгөйү үчүн мониторинг пайдасыз.
Төрт алтын сигнал
Төрт алтын мониторинг сигналдары - кечигүү, трафик, каталар жана каныккандык. Эгерде сиз төрт колдонуучу тутумунун көрсөткүчүн гана өлчөй алсаңыз, ошол төртөөнө көңүл буруңуз.
кармоо
Өтүнүчтү иштетүү үчүн талап кылынган убакыт. Ийгиликтүү жана ийгиликсиз суроо-талаптардын кечиктирилишин айырмалоо маанилүү. Мисалы, маалымат базасына же башка серверге туташуунун жоголушу менен шартталган HTTP 500 катасы абдан тез аныкталышы мүмкүн, бирок HTTP 500 катасы ишке ашпай калган суроону көрсөтүшү мүмкүн. 500 катасынын жалпы күтүү убактысына тийгизген таасирин аныктоо жаңылыш жыйынтыктарга алып келиши мүмкүн. Башка жагынан алганда, жай ката тез ката болуп саналат! Ошондуктан, каталарды жөн эле чыпкалоодон көрө, каталардын күтүү убактысын көзөмөлдөө маанилүү.
жол кыймылы
Сиздин тутумуңузга болгон суроо-талаптардын саны жогорку деңгээлдеги системалык көрсөткүчтөр менен ченелет. Веб кызматы үчүн бул өлчөө, адатта, суроо-талаптардын мүнөзүнө (мисалы, статикалык же динамикалык мазмун) бөлүнгөн секундасына HTTP сурамдарынын санын көрсөтөт. Аудио агым системасы үчүн бул өлчөө тармактын киргизүү/чыгаруу ылдамдыгына же бир убактагы сеанстардын санына көңүл бурушу мүмкүн. Негизги маанини сактоо тутуму үчүн бул өлчөө секундасына транзакциялар же издөө натыйжалары болушу мүмкүн.
укуктарынын каталары
Бул ачык (мисалы, HTTP 500), ачык эмес (мисалы, HTTP 200, бирок жараксыз мазмун менен айкалышкан) же саясат (мисалы, "Эгер сиз жоопту бир секунданын ичинде жазсаңыз, кайсы бир секунд ката болуп саналат") ишке ашпай калган сурамдардын ылдамдыгы. Эгерде HTTP жооп коддору бардык ката шарттарын билдирүү үчүн жетишсиз болсо, жарым-жартылай катаны аныктоо үчүн кошумча (ички) протоколдор талап кылынышы мүмкүн. Бардык мындай ишке ашпай калган суроо-талаптарга мониторинг жүргүзүү маалыматтык болбошу мүмкүн, ал эми системалык тесттер туура эмес мазмунду иштеп жатканыңызды аныктоого жардам берет.
Каныккандык
Метрика кызматыңыз канчалык интенсивдүү колдонулганын көрсөтөт. Бул эң чектелген ресурстарды аныктоочу тутумдун мониторингинин чарасы (мисалы, эс тутуму чектелген системада эстутумду көрсөтөт, киргизүү/чыгаруу чектелген системада I/O санын көрсөтөт). Көптөгөн системалар 100% колдонууга жеткенге чейин өндүрүмдүүлүгүн төмөндөтөт, андыктан пайдалануу максатына ээ болуу маанилүү.
Татаал системаларда каныктыруу жогорку деңгээлдеги жүк өлчөөлөрү менен толукталышы мүмкүн: сиздин кызматыңыз эки эселенген трафикти туура чече алабы, 10% гана көбүрөөк трафикти башкара алабы же азыркыдан азыраак трафикти иштете алабы? Сурамдын татаалдыгын өзгөрткөн параметрлери жок (мисалы, "Мага эч нерсе бербе" же "Мага уникалдуу бирдиктүү монотондуу бүтүн сан керек") конфигурацияны сейрек өзгөрткөн жөнөкөй кызматтар үчүн статикалык жүктөмдүн сыноо мааниси адекваттуу болушу мүмкүн. Бирок, мурунку абзацта талкуулангандай, көпчүлүк кызматтар белгилүү жогорку чеги бар CPU колдонуу же тармак өткөрүү жөндөмдүүлүгү сыяктуу кыйыр сигналдарды колдонушу керек. Кечигүүнүн көбөйүшү көбүнчө каныккандыктын негизги көрсөткүчү болуп саналат. Кичинекей терезеде 99-проценттиль жооп убактысын өлчөө (мисалы, бир мүнөт) каныккандыктын өтө эрте сигналын бере алат.
Акыр-аягы, каныккандык жакындап келе жаткан каныктыруу жөнүндө божомолдор менен да байланыштуу, мисалы: "Сиздин маалымат базаңыз катуу дискиңизди 4 сааттын ичинде толтурат окшойт."
Эгерде сиз бардык төрт алтын сигналды өлчөп көрсөңүз жана метрикалардын биринде көйгөй пайда болгондо (же каныккан учурда, жакын жердеги көйгөй) сиз адамга эскертүү бересиз, сиздин кызматыңыз аздыр-көптүр мониторинг менен камтылат.
"Куйругу" (же приборлор жана аткаруу) жөнүндө тынчсыздануу
Мониторинг системасын нөлдөн баштап түзүүдө, системаны орточо маанилердин негизинде иштеп чыгуу азгырыгы пайда болот: орточо кечигүү, түйүндөрдүн CPU орточо колдонулушу же маалымат базасынын орточо толуктугу. Акыркы эки мисалдын коркунучу айдан ачык: процессорлор жана маалымат базалары өтө күтүүсүз түрдө жок кылынат. Ошол эле кечигүүгө да тиешелүү. Эгер сиз секундасына 100 суроо менен 1000 мс орточо кечигүү менен желе кызматын иштетсеңиз, сурамдардын 1% 5 секундга созулушу мүмкүн. Эгер колдонуучулар бир нече веб-кызматтардан көз каранды болсо, бир бэкендинин 99-процентильи оңой эле фронтондун медианалык жооп берүү убактысы болуп калышы мүмкүн.
Сурамдардын жай орточо жана өтө жай куйругун айырмалоонун эң жөнөкөй жолу - чыныгы кечигүүлөрдүн ордуна статистикада көрсөтүлгөн суроо-талаптардын өлчөөлөрүн чогултуу (көрсөтүү үчүн жакшы курал гистограммалар) жана 0 мс, 10 мс менен 10 мс, 30 мс менен 30 мс, 100 мс менен 100 мс, ж.б.у.с. Гистограмманын чек араларын болжол менен экспоненциалдуу түрдө кеңейтүү (болжол менен 300 эсе) көбүнчө бөлүштүрүүнү визуалдаштыруунун жөнөкөй жолу. суроо-талаптардын.
Өлчөө үчүн деталдардын тиешелүү деңгээлин тандоо
Системанын ар кандай элементтери майда-чүйдөсүнө чейин ар кандай деңгээлде өлчөнгөн болушу керек. Мисалы:
- Белгилүү бир убакыттын ичинде CPU колдонууга мониторинг жүргүзүү жогорку кечигүүлөргө алып келген узак мөөнөттүү өсүүлөрдү көрсөтпөйт.
- Башка жагынан алганда, жылына 9 сааттан ашык иштебей турган веб-кызматы үчүн (жылдык иштөө убактысы 99,9%), HTTP 200 жоопту мүнөтүнө бир же эки жолудан ашык текшерүү керексиз тез-тез болушу мүмкүн.
- Ошо сыяктуу эле, катуу дисктеги мейкиндиктин 99,9% жеткиликтүүлүгүн 1-2 мүнөттө бир жолудан ашык текшерүү керек эмес.
Өлчөөлөрүңүздүн гранулярдуулугун кантип түзөөрүңүзгө көңүл буруңуз. CPU жүгүн секундасына бир жолу чогултуу кызыктуу маалыматтарды бере алат, бирок мындай тез-тез өлчөөлөрдү чогултуу, сактоо жана талдоо абдан кымбат болушу мүмкүн. Мониторинг максатыңыз жогорку деталдуулукту талап кылса жана жогорку жооптуулукту талап кылбаса, сиз серверде метрикаларды чогултууну орнотуу жана андан кийин бул көрсөткүчтөрдү чогултуу жана бириктирүү үчүн тышкы системаны орнотуу менен бул чыгымдарды азайта аласыз. Сиз:
- Ар бир секундада CPU жүгүн өлчөңүз.
- Деталдарды 5% чейин кыскартуу.
- Ар бир мүнөт сайын көрсөткүчтөрдү топтоо.
Бул стратегия сизге жогорку талдоо жана сактоо чыгымдарын талап кылбастан, маалыматтарды жогорку гранулдуулукта чогултууга мүмкүндүк берет.
Мүмкүн болушунча жөнөкөй, бирок жөнөкөй эмес
Ар кандай талаптардын бири-биринин үстүнө коюлушу өтө татаал мониторинг системасын алып келиши мүмкүн. Мисалы, сиздин системаңызда төмөнкү татаалдаткыч элементтер болушу мүмкүн:
- Ар кандай көрсөткүчтөрдүн бардык түрлөрү үчүн суроо-талаптарды иштетүү кечигүү үчүн ар кандай босогого ылайык эскертүүлөр.
- Мүмкүн болгон себептерди аныктоо жана аныктоо үчүн кошумча код жазуу.
- Көйгөйлөрдүн мүмкүн болгон себептеринин ар бири үчүн тиешелүү такталарды түзүңүз.
Потенциалдуу татаалдануунун булактары эч качан бүтпөйт. Бардык программалык камсыздоо системалары сыяктуу эле, мониторинг ушунчалык татаал болуп калышы мүмкүн, ал морт болуп калат жана өзгөртүү жана колдоо кыйын болуп калат.
Ошондуктан, мүмкүн болушунча жөнөкөйлөтүү үчүн мониторинг системасын иштеп чыгуу. Эмнеге көз салууну тандап жатканда, төмөнкүлөрдү эске алыңыз:
- Көбүнчө реалдуу окуяларды кармаган эрежелер мүмкүн болушунча жөнөкөй, болжолдуу жана ишенимдүү болушу керек.
- Маалыматтарды чогултуу, бириктирүү жана сейрек аткарылуучу эскертүү конфигурациясын (мисалы, кээ бир SRE командалары үчүн квартал сайын азыраак) алып салуу керек.
- Чогултулган, бирок алдын ала көрүү панелинде көрсөтүлбөгөн же кандайдыр бир эскертүү тарабынан колдонулбаган көрсөткүчтөр жок кылууга талапкерлер болуп саналат.
Google'да негизги көрсөткүчтөрдү чогултуу жана топтоо эскертүүлөр жана аспаптар такталары менен бирге салыштырмалуу өз алдынча система катары жакшы иштейт (Google'дун мониторинг системасы иш жүзүндө бир нече подсистемага бөлүнгөн, бирок адамдар адатта бул подсистемалардын бардык аспектилерин билишет). Мониторингди татаал системаларды изилдөөнүн башка ыкмалары менен айкалыштыруу азгырылышы мүмкүн: системанын деталдуу профилин түзүү, процессти оңдоо, өзгөчө учурлар же каталар жөнүндө деталдарды көзөмөлдөө, жүктөмдү текшерүү, журналдарды чогултуу жана талдоо, же трафикти текшерүү. Бул нерселердин көбү негизги мониторинг менен жалпылыктарга ээ болсо да, аларды аралаштыруу өтө көп натыйжаларга алып келет жана татаал жана морт системаны түзөт. Программалык камсыздоону иштеп чыгуунун башка көптөгөн аспектилери сыяктуу эле, так, жөнөкөй, эркин бириктирилген интеграция пункттары менен ар кандай системаларды колдоо эң жакшы стратегия (мисалы, узак убакыт бою ырааттуу бойдон кала турган форматта топтолгон маалыматтарды алуу үчүн веб API колдонуу) ).
Принциптерди бириктирүү
Бул бөлүмдө талкууланган принциптерди Google SRE топтору жактырган жана сактаган мониторинг жана эскертүү философиясына айкалыштырса болот. Мониторингдин бул философиясын кармануу эң жакшы, эскертүү методологияңызды түзүү же кайра карап чыгуу үчүн жакшы башталгыч чекит болуп саналат жана уюмуңуздун көлөмүнө же кызматтын же системанын татаалдыгына карабастан, операцияларыңыз боюнча туура суроолорду берүүгө жардам берет.
Мониторинг жана эскертүү эрежелерин түзүп жатканда, төмөнкү суроолорду берүү жалган позитивтерден жана керексиз эскертүүлөрдөн качууга жардам берет:
- Бул эреже шашылыш, аракетке чакырган жана колдонуучуга сөзсүз түрдө таасир этүүчү системанын башкача байкалбаган абалын аныктайбы?
- Мен бул эскертүүгө көңүл бурбай койсом болобу? Качан жана эмне үчүн бул эскертүүгө көңүл бурбайм жана бул сценарийден кантип кача алам?
- Бул эскертүү колдонуучуларга терс таасирин тийгизип жатканын билдиреби? Колдонуучуларга терс таасирин тийгизбеген жагдайлар барбы, мисалы, трафикти чыпкалоо аркылуу же эскертүүлөр чыпкаланышы керек болгон тесттик системаларды колдонууда?
- Бул эскертүүгө жооп катары чара көрө аламбы? Бул чаралар шашылышпы же таңга чейин күтө алабы? Ишти коопсуз автоматташтырууга болобу? Бул аракет узак мөөнөттүү чечим болобу же кыска мөөнөттүү чечүү болобу?
- Кээ бир адамдар бул маселе боюнча бир нече эскертүүлөрдү алып жатышат, андыктан эскертүүлөрдүн санын азайтуунун жолу барбы?
Бул суроолор эскертүүлөр жана эскертүү системалары боюнча негизги философияны чагылдырат:
- Ар бир эскертүү келгенде, мен дароо жооп беришим керек. Мен чарчаганга чейин күнүнө бир нече жолу шашылыш реакция кыла алам.
- Ар бир эскертүү тиешелүү болушу керек.
- Ар бир эскертүүгө жооп адамдын кийлигишүүсүн талап кылышы керек. Эгер эскертме автоматтык түрдө иштетилсе, ал келбеши керек.
- Эскертүүлөр мурда болбогон жаңы көйгөй же окуя жөнүндө болушу керек.
Бул ыкма айрым айырмачылыктарды бүдөмүктөйт: эгерде эскертүү мурунку төрт шартка жооп берсе, эскертүү White-box же Black-Box мониторинг системасынан жөнөтүлгөнү маанилүү эмес. Бул ыкма айрым айырмачылыктарды да бекемдейт: себептерге караганда симптомдорду аныктоого көбүрөөк күч жумшаган жакшы; себептери жөнүндө сөз болгондо, сиз сөзсүз себептери жөнүндө гана тынчсызданышыңыз керек.
Узак мөөнөттүү мониторинг
Бүгүнкү өндүрүмдүүлүк шарттарында мониторинг системалары өзгөрүп жаткан программалык камсыздоонун архитектурасы, жүктөмдүн мүнөздөмөлөрү жана аткаруу максаттары менен дайыма өнүгүп жаткан өндүрүш системасын көзөмөлдөйт. Учурда автоматташтыруу кыйын болгон эскертүүлөр көнүмүш болуп калышы мүмкүн, атүгүл көңүл бурууга арзырлык. Бул учурда, кимдир бирөө маселенин түпкү себептерин таап, жок кылышы керек; эгерде мындай чечим мүмкүн болбосо, эскертүүгө жооп берүү толук автоматташтырууну талап кылат.
Мониторинг чечимдери узак мөөнөттүү максаттарды эске алуу менен кабыл алынышы маанилүү. Бүгүн иштеп жаткан ар бир эскертүү адамды эртең системаны жакшыртуудан алаксытат, ошондуктан узак мөөнөттүү келечекте мониторинг тутумун жакшыртуу үчүн керектүү убакытка жемиштүү системанын жеткиликтүүлүгү же иштеши азаят. Бул көрүнүштү көрсөтүү үчүн эки мисалды карап көрөлү.
Bigtable SRE: Ашыкча эскертүү
Google'дун ички инфраструктурасы адатта камсыздалат жана кызмат деңгээлине (SLO) карата өлчөнөт. Көп жылдар мурун, Bigtable кызматынын SLO кызматы жандуу кардарды окшоштурган синтетикалык транзакциянын орточо көрсөткүчтөрүнө негизделген. Bigtableдеги көйгөйлөрдөн жана сактоо стекинин төмөнкү деңгээлдеринен улам, орточо өндүрүмдүүлүк "чоң" куйрук менен шартталган: сурамдардын эң начар 5% көбүнчө калгандарына караганда кыйла жайыраак болгон.
Электрондук почта эскертмелери SLO босогосуна жакындаганда, ал эми SLO чегинен ашканда мессенжер эскертүүлөрү жөнөтүлгөн. Эскертүүнүн эки түрү тең тез-тез жөнөтүлүп, инженердик убакыттын кабыл алынгыс көлөмүн сарптаган: команда иш жүзүндө актуалдуу болгон бир нече эскертүүлөрдү табуу үчүн бир топ убакытты сарптады. Биз көп учурда колдонуучуларга чындыгында таасир эткен маселени өткөрүп жиберчүбүз, анткени эскертүүлөрдүн айрымдары гана ошол конкреттүү маселеге тиешелүү. Көптөгөн эскертүүлөр инфраструктурадагы түшүнүктүү көйгөйлөрдөн улам шашылыш болгон эмес жана стандарттуу түрдө иштетилген же такыр иштетилген эмес.
Кырдаалды оңдоо үчүн команда үч багыттуу мамилени карманды: Bigtable программасынын иштешин жакшыртуу үчүн талыкпай иштеп жатып, биз убактылуу SLO максатыбызга суроо-жооптордун кечигүү үчүн 75-проценттиль болушун койдук. Ошондой эле электрондук почта эскертүүлөрүн өчүрүп койдук, анткени алардын саны абдан көп болгондуктан, диагностикалоого убакыт коротуу мүмкүн эмес болчу.
Бул стратегия бизге дем алуу бөлмөсүнө тактикалык маселелерди такай чечпестен, Bigtable жана сактоо стекинин төмөнкү деңгээлдериндеги узак мөөнөттүү маселелерди чече баштоого мүмкүндүк берди. Инженерлер иш жүзүндө ар дайым эскертүүлөр менен бомбаланбастан ишти бүтүрө алышкан. Акыр-аягы, эскертүү иштетүүнү убактылуу кийинкиге калтыруу бизге кызматыбыздын сапатын жакшыртууга мүмкүндүк берди.
Gmail: Болжолдуу, Адамдын Алгоритмдик Жооптору
Түзүлгөндө, Gmail өзгөртүлгөн Workqueue процессин башкаруу тутумунун негизинде курулган, ал издөө индексинин процесстик бөлүктөрүн партиялоо үчүн иштелип чыккан. Жумуш кезеги узакка созулган процесстерге ыңгайлаштырылган жана кийинчерээк Gmail'ге колдонулду, бирок бүдөмүк пландаштыргыч кодундагы кээ бир мүчүлүштүктөрдү оңдоо абдан кыйын болду.
Ал кезде Gmail мониторинги Workqueue аркылуу жеке тапшырмалар жокко чыгарылганда эскертүүлөр бериле тургандай структураланган. Бул ыкма идеалдуу эмес болчу, анткени ал убакта да Gmail миңдеген тапшырмаларды аткарган, алардын ар бири биздин колдонуучулардын пайызынын бир бөлүгүнө берилген. Биз Gmail колдонуучуларын жакшы колдонуу тажрыйбасы менен камсыз кылуудан абдан тынчсызданганбыз, бирок мынчалык көп эскертүүлөрдү иштетүү мүмкүн эмес болчу.
Бул көйгөйдү чечүү үчүн, Gmail SRE колдонуучуларга тийгизген таасирин азайтуу үчүн пландоочунун мүчүлүштүктөрүн мүмкүн болушунча жакшыраак оңдоого жардам берүүчү куралды түздү. Команда узак мөөнөттүү чечим табылганга чейин көйгөйдү табуудан баштап оңдоого чейин бүт циклди жөн гана автоматташтыруу керекпи же жокпу деген маселени талкуулады, бирок кээ бирлери мындай чечим көйгөйдү чындап чечүүнү кечеңдетет деп кооптонушкан.
Бул тирешүү командада кеңири таралган жана көп учурда өзүн-өзү тарбиялоого болгон ишенимдин жоктугун чагылдырган: команданын кээ бир мүчөлөрү туура оңдоого убакыт берүүнү кааласа, башкалары акыркы оңдоо унутулуп, убактылуу оңдоо түбөлүккө созулат деп кооптонушат. Бул маселе көңүл бурууга татыктуу, анткени абалды туруктуу кылуунун ордуна көйгөйлөрдү убактылуу оңдоо өтө оңой. Жетекчилер жана техникалык персонал узак мөөнөттүү оңдоолорду ишке ашырууда, алгачкы "оору" басылгандан кийин да мүмкүн болгон узак мөөнөттүү оңдоолорду колдоодо жана приоритеттөөдө негизги ролду ойношот.
Үзгүлтүксүз, кайталануучу эскертүүлөр жана алгоритмдик жооптор кызыл желек болушу керек. Командаңыздын бул эскертүүлөрдү автоматташтырууну каалабагандыгы команда алгоритмдерге ишене аларына ишенбестигин билдирет. Бул чечүүнү талап кылган олуттуу көйгөй.
Бул узак мөөнөттүү келечекте
Жалпы тема Bigtable жана Gmail мисалдарын байланыштырат: кыска мөөнөттүү жана узак мөөнөттүү жеткиликтүүлүктүн ортосундагы атаандаштык. Көбүнчө, күчтүү аракет морт системага жогорку жеткиликтүүлүккө жетүүгө жардам берет, бирок бул жол адатта кыска мөөнөттүү, команданын күйүп кетиши жана ошол эле баатыр команданын аз сандагы мүчөлөрүнө көз карандылык менен коштолот.
Жеткиликтүүлүктүн көзөмөлгө алынган, кыска мөөнөттүү кыскарышы көп учурда оор, бирок системанын узак мөөнөттүү туруктуулугу үчүн стратегиялык жактан маанилүү. Ар бир сигналды өзүнчө карап отурбоо маанилүү, бирок сигналдын көлөмүнүн жалпы деңгээли жашоого жөндөмдүү команда жана жагымдуу прогноз менен дени сак, туура жеткиликтүү системага алып келер-келбесин карап чыгуу керек. Чечим кабыл алуучуларга эскертүү тутумунун жүгүн жана жалпы команданын ден соолугун үзгүлтүксүз көрүүгө мүмкүнчүлүк берип, башкарууга кварталдык отчеттордо эскертүү жыштыгынын статистикасын (адатта инцидент бир нөөмөттөгү инциденттер катары көрсөтүлөт, анда инцидент бир нече байланыштуу инциденттерден турушу мүмкүн) талдайбыз.
жыйынтыктоо
дени сак мониторинг жана эскертүү жолу жөнөкөй жана түшүнүктүү. Ал эскертүүлөрдү пайда кылган көйгөйдүн белгилерине көңүл бурат жана себебин көзөмөлдөө көйгөйлөрдү оңдоого жардам берет. Мониторинг симптомдору сиз көзөмөлдөгөн стекте канчалык жогору болсоңуз, ошончолук жеңил болот, бирок маалымат базасынын жүктөмүнө жана иштешине мониторинг түздөн-түз маалымат базасынын өзүндө жүргүзүлүшү керек. Электрондук почта эскертмелери өтө чектелген пайдалуу жана оңой эле ызы-чуу болуп калат; Анын ордуна, сиз электрондук почта эскертүүлөрүн козгогон бардык учурдагы маселелерди көзөмөлдөгөн панелди колдонушуңуз керек. Тарыхый корреляцияларды талдоо үчүн инструменттер тактасын окуялар журналы менен жупташтырса болот.
Узак мөөнөттүү келечекте симптомдор жана жакын арада боло турган реалдуу көйгөйлөр жөнүндө эскертүүлөрдүн ийгиликтүү айлануусуна жетишүү, мониторинг тез диагнозду колдоо үчүн максаттарды ыңгайлаштыруу зарыл.
Котормону аягына чейин окуганыңыз үчүн рахмат. Мониторинг жөнүндө менин телеграм каналыма жазылыңыз и .
Source: www.habr.com