Мониторинг өлдүбү? — Жашасын мониторинг

2008-жылдан бери биздин компания биринчи кезекте инфраструктураны башкаруу жана веб-долбоорлорду күнү-түнү техникалык колдоо менен алектенет: бизде 400дөн ашык кардарлар бар, бул орусиялык электрондук коммерциянын 15% түзөт. Демек, абдан ар түрдүү архитектура колдоого алынат. Бир нерсе түшүп калса 15 мүнөттүн ичинде оңдоп коюуга милдеттүүбүз. Бирок кырсык болгонун түшүнүү үчүн долбоорду көзөмөлдөп, окуяларга жооп бериш керек. Муну кантип кылуу керек?

Туура мониторинг системасын уюштурууда көйгөй бар деп эсептейм. Эгер эч кандай кыйынчылык болбосо, анда менин сөзүм бир тезистен турмак: "Сураныч, Prometheus + Grafana жана 1, 2, 3 плагиндерин орнотуңуз." Тилекке каршы, ал мындан ары андай иштебейт. Ал эми негизги көйгөй - бардыгы 2008-жылы болгон бир нерсеге, программалык камсыздоонун компоненттерине ишене беришет.

Мониторинг системасын уюштуруу жөнүндө айта турган болсом... компетенттүү мониторинг жүргүзгөн долбоорлор жок. Ал эми абал ушунчалык начар болгондуктан, бир нерсе кулап калса, байкалбай калуу коркунучу бар - баары "баары көзөмөлдөнөт" деп ишенет.
Балким баары көзөмөлдөнүп жаткандыр. Бирок кантип?

Биз баарыбыз төмөнкүдөй окуяга туш болдук: белгилүү бир devops, белгилүү бир администратор иштеп жатат, аларга иштеп чыгуу тобу келип, "биз бошотулдук, азыр көзөмөлдөңүз" дейт. Эмне мониторинг? Бул кандай иштейт?

макул. Биз эски ыкманы көзөмөлдөйбүз. Ал эми азыртан эле өзгөрүп жатат жана сиз C кызматы менен өз ара аракеттенген В кызматына айланган А кызматына мониторинг жүргүздүңүз.

Анда эмне өзгөрдү? - Баары өзгөрдү!

2008 Баары сонун

Бир нече иштеп чыгуучулар, бир сервер, бир маалымат базасы сервери бар. Мунун баары ушул жерден кетет. Бизде маалымат бар, биз zabbix, Nagios, кактустарды орнотобуз. Анан биз CPU, дисктин иштеши жана диск мейкиндиги боюнча так эскертүүлөрдү койдук. Биз ошондой эле сайттын жооп беришин жана буйруктардын маалымат базасына келип жатканын текшерүү үчүн бир нече кол менен текшеребиз. Жана бул - биз аздыр-көптүр корголгонбуз.

Эгерде администратордун мониторингди камсыз кылуу үчүн аткарган ишинин көлөмүн салыштырсак, анда анын 98% автоматтык түрдө аткарылган: мониторинг жүргүзгөн адам Zabbixти кантип орнотууну, аны кантип конфигурациялоону жана эскертүүлөрдү конфигурациялоону түшүнүшү керек. Ал эми 2% - тышкы текшерүүлөр үчүн: сайт жооп берип, маалымат базасына суроо-талап кылат, жаңы заказдар келди деп.

2010 Жүк өсүүдө

Биз издөө системасын кошуп, интернетти масштабдай баштайбыз. Биз продукт каталогунда бардык продуктыларды камтыганына ынангыбыз келет. Жана бул продукт издөө иштейт. Маалымат базасы иштеп жаткандыгы, буйрутмалар жасалып жаткандыгы, сайт сырттан жооп берип, эки серверден жооп бергени жана башка серверге балансталганда колдонуучу сайттан чыгарылбаганы ж.б. Көбүрөөк субъекттер бар.

Мындан тышкары, инфраструктура менен байланышкан объект дагы деле жетекчинин эң чоңу бойдон калууда. Менин башымда дагы эле мониторинг жүргүзүп жаткан адам zabbixти орнотуп, аны конфигурациялай ала турган адам деген ой бар.

Бирок, ошол эле учурда, тышкы текшерүүлөрдү жүргүзүү, издөө индекстөөчү суроо скрипттеринин топтомун түзүү, индекстөө процессинде издөөнүн өзгөрүшүн текшерүү үчүн скрипттердин топтому, товарлардын жөнөтүлгөндүгүн текшерген скрипттердин топтому боюнча иштер пайда болот. жеткирүү кызматы ж.б. жана башка.

Эскертүү: Мен "скрипттердин топтомун" 3 жолу жаздым. Башкача айтканда, мониторинг үчүн жооптуу адам мындан ары zabbixти жөн эле орноткон адам эмес. Бул коддоону баштаган адам. Бирок команданын оюнда азырынча эч нерсе өзгөрө элек.

Бирок дүйнө өзгөрүп, барган сайын татаалдашып баратат. Виртуалдаштыруу катмары жана бир нече жаңы системалар кошулду. Алар бири-бири менен өз ара аракеттене башташат. Ким айтты "микросервистердин жыты бар?" Бирок ар бир кызмат өзүнчө веб-сайтка окшош. Биз ага кайрылып, керектүү маалыматтарды берип, өз алдынча иштеп жатканын түшүнсөк болот. Ал эми сиз 5-7-10 жылдан бери өнүгүп келе жаткан долбоорго тынымсыз катышкан администратор болсоңуз, анда бул билимдер топтолот: жаңы деңгээл пайда болот - сиз аны түшүндүңүз, башка деңгээл пайда болот - сиз аны түшүндүңүз...

Бирок сейрек бирөө долбоорду 10 жыл коштоп жүрөт.

Мониторингчинин резюмеси

Сиз жаңы стартапка келдиңиз дейли, ал дароо 20 иштеп чыгуучуну жалдап, 15 микросервис жазган жана сиз администраторсуз: “CI/CD түзүңүз. Өтүнөмүн." Сиз CI/CD түздүңүз жана күтүлбөгөн жерден угуп жатасыз: "Бизге "кубдагы" өндүрүш менен иштөө кыйын, анда тиркеме кантип иштей турганын түшүнбөй. Бизди ошол эле "кубка" кумкора кылып бер.
Сиз бул кубтун ичинде кумкоргон жасайсыз. Алар дароо сизге: "Биз өндүрүштөн күн сайын жаңыланып турган сахналык маалымат базасын каалайбыз, андыктан анын маалымат базасында иштегенин түшүнөбүз, бирок ошол эле учурда өндүрүш маалымат базасын бузбасын".

Сиз мунун баарында жашайсыз. Чыгарууга 2 жума калды, алар: "Эми мунун баарын көзөмөлдөп көрөлү..." деп айтышат. кластердик инфраструктурага мониторинг жүргүзүү, микросервис архитектурасына мониторинг жүргүзүү, тышкы кызматтар менен иштөөгө мониторинг жүргүзүү...

Ал эми менин кесиптештерим кадимки схеманы баштарынан чыгарып: «Мына, бул жерде баары түшүнүктүү! Мунун баарын көзөмөлдөй турган программаны орнотуңуз». Ооба, ооба: Prometheus + Grafana + плагиндер.
Анан алар кошумчалайт: "Сизде эки жума бар, баары коопсуз экенине ынаныңыз."

Биз көрүп жаткан көптөгөн долбоорлордо мониторинг жүргүзүү үчүн бир адам бөлүнөт. Элестеткиле, биз 2 жумага мониторинг жүргүзүү үчүн адамды жалдагыбыз келет жана ага резюме жазабыз. Буга чейин айткандарыбызды эске алганда, бул адам кандай жөндөмгө ээ болушу керек?

• Ал темир инфраструктуранын иштешинин мониторингин жана өзгөчөлүктөрүн түшүнүшү керек.
• Ал Kubernetes мониторингинин өзгөчөлүктөрүн түшүнүшү керек (жана ар бир адам "кубка" барууну каалайт, анткени сиз бардыгынан абстракцияланып, жашыра аласыз, анткени админ калганы менен алектенет) - өзүн, анын инфраструктурасын жана тиркемелерди кантип көзөмөлдөө керектигин түшүнүшү керек. ичинде.
• Ал кызмат көрсөтүүлөр бири-бири менен өзгөчө жолдор менен байланышарын түшүнүшү керек жана кызматтардын бири-бири менен өз ара аракеттенүүсүнүн өзгөчөлүктөрүн билиши керек. Кээ бир кызматтар синхрондуу байланышта болгон долбоорду көрүүгө толук мүмкүн, анткени башка жол жок. Мисалы, бэкэнд REST аркылуу, gRPC аркылуу каталог кызматына барат, өнүмдөрдүн тизмесин алат жана аны кайра кайтарат. Бул жерде күтө албайсың. Ал эми башка кызматтар менен ал асинхрондуу иштейт. Заказды жеткирүү кызматына өткөрүп берүү, кат жөнөтүү ж.б.
  Сиз мунун баарын сүзүп алгандырсыз? Ал эми муну көзөмөлдөш керек болгон админ ого бетер баш аламан болуп калды.
• Ал туура пландаштырып, пландай билиши керек – иш барган сайын күчөгөн сайын.
• Ошондуктан, ал атайын мониторинг жүргүзүү үчүн кантип түшүнүү үчүн түзүлгөн кызматтын стратегиясын түзүшү керек. Ал долбоордун архитектурасын жана анын өнүгүшүн + иштеп чыгууда колдонулган технологияларды түшүнүшү керек.

Абсолюттук бир учурду эстейли: кээ бир сервистер PHPде, кээ бир кызматтар Go, кээ бир кызматтар JSде. Алар кандайдыр бир жол менен бири-бири менен иштешет. Бул жерде "микросервис" термини келип чыккан: иштеп чыгуучулар долбоорду бүтүндөй түшүнө албаган көптөгөн жеке системалар бар. Команданын бир бөлүгү JSде өз алдынча иштеген кызматтарды жазат жана калган система кантип иштээрин билбейт. Башка бөлүгү Python кызматтарын жазат жана башка кызматтардын өз аймагында обочолонуп иштешине тоскоол болбойт; Үчүнчүсү - PHP же башка нерседе кызматтарды жазуу.
Бул 20 адамдын баары 15 кызматка бөлүнгөн, мунун баарын түшүнгөн бир гана админ бар. Токто! Биз жөн гана системаны 15 микросервиске бөлдүк, анткени 20 адам бүт системаны түшүнө албайт.

Бирок аны кандайдыр бир жол менен көзөмөлдөш керек...

Жыйынтыгы кандай болду? Натыйжада, иштеп чыгуучулардын бүт командасы түшүнө албаган нерселердин бардыгын ойлоп таба турган бир адам бар, ошол эле учурда ал биз жогоруда белгилеген нерсени - аппараттык инфраструктураны, Kubernetes инфраструктурасын ж.б.

Эмне дейм... Хьюстон, бизде проблемалар бар.

Заманбап программалык камсыздоо долбооруна мониторинг жүргүзүү өзүнчө программалык долбоор болуп саналат

Мониторинг программалык камсыздоо деген жалган ишенимден улам биз кереметтерге ишеним өрчүтөбүз. Бирок кереметтер, тилекке каршы, болбойт. Сиз zabbix орнотуп, бардыгынын иштешин күтө албайсыз. Grafana орнотуп, баары жакшы болот деп үмүттөнүүдөн эч кандай пайда жок. Көпчүлүк убакыт кызматтардын иштешин жана алардын бири-бири менен өз ара аракеттенүүсүн текшерүүнү уюштурууга, тышкы системалардын кантип иштешин текшерүүгө жумшалат. Чынында, убакыттын 90% сценарий жазууга эмес, программалык камсыздоону иштеп чыгууга жумшалат. Ал эми долбоордун ишин түшүнгөн команда менен алектениши керек.
Бул жагдайда бир адам мониторингге ыргытса, анда кырсык болот. Бул бардык жерде болот.

Мисалы, Кафка аркылуу бири-бири менен байланышып турган бир нече кызматтар бар. Заказ келди, Кафкага буйрук тууралуу кабар жөнөттүк. Буйрутма тууралуу маалыматты угуп, товарды жөнөтүүчү сервис бар. Буйрутма тууралуу маалыматты угуп, колдонуучуга кат жөнөтүүчү сервис бар. Анан дагы бир топ кызматтар пайда болуп, биз чаташа баштайбыз.

Эгерде сиз муну администраторлорго жана иштеп чыгуучуларга чыгарууга аз убакыт калган этапта берсеңиз, анда адам бул протоколду толугу менен түшүнүшү керек. Ошол. Мындай масштабдагы долбоор бир топ убакытты талап кылат жана бул системаны өнүктүрүүдө эске алынышы керек.
Бирок көп учурда, өзгөчө стартаптарда, биз мониторингдин кийинкиге калтырылганын көрөбүз. «Эми биз Концепциянын далилин жасайбыз, аны менен ишке киргизебиз, ал кулап кетсин - биз курмандыкка чалууга даярбыз. Анан баарын көзөмөлдөйбүз”. Долбоор акча алып келе баштаганда (же болсо), бизнес дагы көбүрөөк функцияларды кошкусу келет - анткени ал иштей баштады, демек, аны андан ары жайылтуу керек! Ал эми сиз алгач мурункулардын баарын көзөмөлдөп турушуңуз керек болгон жердесиз, бул убакыттын 1% эмес, андан да көптү талап кылат. Айтмакчы, иштеп чыгуучулар мониторинг үчүн керек болот жана аларга жаңы функциялардын үстүндө иштөөгө мүмкүнчүлүк берүү оңой. Натыйжада, жаңы функциялар жазылат, баары бузулат жана сиз чексиз туюкта турасыз.

Ошентип, башынан баштап долбоорду кантип мониторинг жүргүзүү керек, жана мониторинг жүргүзүү керек болгон долбоорду алып, бирок эмнеден баштоону билбей, эмне кылуу керек?

Биринчиден, сиз пландоо керек.

Лирикалык чегинүү: көбүнчө инфраструктуранын мониторинги менен башталат. Мисалы, бизде Kubernetes бар. Прометейди Grafana менен орнотуп, "кубду" көзөмөлдөө үчүн плагиндерди орнотуудан баштайлы. Иштеп чыгуучулардын гана эмес, администраторлордун да өкүнүчтүү тажрыйбасы бар: "Биз бул плагинди орнотобуз, бирок плагин муну кантип жасоону билет окшойт." Адамдар маанилүү иш-аракеттерден эмес, жөнөкөй жана жөнөкөйдөн баштоону жакшы көрүшөт. Ал эми инфраструктурага мониторинг жүргүзүү оңой.

Биринчиден, эмнени жана кантип көзөмөлдөгүңүз келгенин чечиңиз, анан куралды тандаңыз, анткени башка адамдар сиз үчүн ойлоно албайт. Анан алар керекпи? Башка адамдар универсалдуу система жөнүндө ойлошкон - же бул плагин жазылганда такыр ойлогон эмес. Жана бул плагиндин 5 миң колдонуучусу болгону анын эч кандай пайдасы жок дегенди билдирбейт. Балким, сен 5001чи болосуң, анткени ал жерде мурда 5000 адам болгон.

Эгер сиз инфраструктураны көзөмөлдөй баштасаңыз жана колдонмоңуздун сервери жооп бербей калса, бардык колдонуучулар мобилдик тиркеме менен байланышын жоготот. Ката пайда болот. Алар сизге келип, “Тиркеме иштебей жатат, бул жерде эмне кылып жүрөсүз?” деп айтышат. - Биз мониторинг жүргүзүп жатабыз. — "Эгер колдонмо иштебей жатканын көрбөсөңүз, кантип көзөмөлдөйсүз?!"

1. Мен колдонуучунун кирүү чекитинен так мониторинг баштоо керек деп ойлойм. Колдонуучу тиркеме иштеп жатканын көрбөсө, анда бүттү, бул ката. Ал эми мониторинг системасы бул тууралуу биринчи эскертиши керек.
2. Ошондо гана инфраструктураны көзөмөлдөй алабыз. Же параллелдүү кылыңыз. Инфраструктура менен оңой - бул жерде биз zabbixти жөн гана орното алабыз.
3. Ал эми азыр нерселер иштебей жаткан жерди түшүнүү үчүн колдонмонун тамырына барышыңыз керек.

Менин негизги оюм, мониторинг өнүгүү процесси менен параллелдүү жүрүшү керек. Эгерде сиз мониторинг тобун башка тапшырмаларга (CI/CD түзүү, кумбокс, инфраструктураны кайра уюштуруу) алаксытсаңыз, мониторинг артта кала баштайт жана сиз өнүгүүгө эч качан жете албай каласыз (же эртеби-кечпи аны токтотууга туура келет).

Баары деңгээли боюнча

Мониторинг системасын уюштурууну мен ушундай көрөм.

1) Колдонмо деңгээли:

• колдонмо бизнес логикасын көзөмөлдөө;
• кызматтардын ден соолук көрсөткүчтөрүнө мониторинг жүргүзүү;
• интеграциялык мониторинг.

2) инфраструктуранын деңгээли:

• оркестрдин деңгээлине мониторинг жүргүзүү;
• системалык программалык камсыздоонун мониторинги;
• темир көлөмүн көзөмөлдөө.

3) Кайрадан колдонуу деңгээли - бирок инженердик продукт катары:

• арыздардын журналдарын чогултуу жана мониторинг жүргүзүү;
• APM;
• издоо.

4) эскертүү:

• эскертүү системасын уюштуруу;
• нөөмөт системасын уюштуруу;
• инциденттерди иштетүү үчүн "билим базасын" жана иш процессин уюштуруу.

маанилүү: Биз эскертүүгө кийин эмес, дароо жетебиз! Мониторингди баштоонун жана "кандайдыр бир убакта" ким эскертүү алаарын аныктоонун кереги жок. Анткени, мониторингдин милдети эмнеде: системанын кайсы жеринде бир нерсе туура эмес иштеп жатканын түшүнүү жана бул тууралуу тийиштүү адамдарга кабарлоо. Эгер сиз муну аягына чейин калтырсаңыз, анда туура адамдар бир нерсе туура эмес болуп жатканын "бизге эч нерсе иштебей жатат" деп гана билишет.

Колдонмо катмары - Бизнес логикалык мониторинг

Бул жерде биз колдонмо колдонуучу үчүн иштээрин текшерүү жөнүндө сөз болуп жатат.

Бул деңгээл иштеп чыгуу баскычында жасалышы керек. Мисалы, бизде шарттуу Prometheus бар: ал текшерүүлөрдү жүргүзгөн серверге барат, акыркы чекитти тартат жана акыркы чекит барып APIди текшерет.

Сайттын иштеп жаткандыгына ынануу үчүн үй баракты көзөмөлдөөнү суранганда, программисттер API иштеп жаткандыгына ынануу үчүн керек болгон сайын тартыла турган тутканы беришет. Ал эми программисттер азыр деле /api/test/helloworld жазып алышат
Баары иштейт деп ынануу үчүн бир гана жолу? - Жок!

• Мындай текшерүүлөрдү түзүү негизинен иштеп чыгуучулардын милдети болуп саналат. Бирдик тесттерин кодду жазган программисттер жазышы керек. Себеби, эгер сиз аны администраторго чыгарсаңыз, "Досум, бул жерде бардык 25 функция үчүн API протоколдорунун тизмеси бар, баарын көзөмөлдөңүз!" - эч нерсе болбойт.
• Эгер сиз "салам дүйнөнү" басып чыгарсаңыз, API иштеши керек экенин эч ким билбейт. Ар бир API өзгөртүү текшерүүлөрдүн өзгөрүшүнө алып келиши керек.
• Эгер сизде мындай көйгөй бар болсо, функцияларды токтотуп, бул текшерүүлөрдү жаза турган иштеп чыгуучуларды бөлүңүз же жоготууларды кабыл алыңыз, эч нерсе текшерилбейт жана ишке ашпай калат деп кабыл алыңыз.

Техникалык кеңештер:

• Текшерүүнү уюштуруу үчүн тышкы серверди уюштурууну унутпаңыз - сиздин долбоор тышкы дүйнө үчүн жеткиликтүү экендигине ынанышыңыз керек.
• Жеке акыркы чекиттерди эле эмес, бүт API протоколу боюнча текшерүүлөрдү уюштуруңуз.
• Сыноонун натыйжалары менен прометейдик чекит түзүңүз.

Колдонмо катмары - ден соолук көрсөткүчтөрүн көзөмөлдөө

Азыр биз кызматтардын тышкы ден-соолук көрсөткүчтөрү жөнүндө сөз болуп жатат.

Биз тышкы мониторинг тутумунан чакырган тышкы текшерүүлөрдүн жардамы менен тиркеменин бардык "тутчаларын" көзөмөлдөйбүз деп чечтик. Бирок бул колдонуучу "көргөн" "туткалар". Биздин кызматтарыбыздын өзү иштешине ишенгибиз келет. Бул жерде жакшыраак окуя бар: K8s ден соолук текшерүүлөрү бар, ошондуктан, жок эле дегенде, "кубдун" өзү кызмат иштеп жатканына ынанышы мүмкүн. Бирок мен көргөн чектердин жарымы ошол эле "салам дүйнө" деген басылып чыккан. Ошол. Ошентип, ал жайгаштыргандан кийин бир жолу тартат, ал баары жакшы деп жооп берди - ушунча. Кызмат, эгерде ал өзүнүн API менен камсыз кылса, ошол эле API үчүн кирүү чекиттеринин көп саны бар, алар да көзөмөлдөнүшү керек, анткени биз анын иштегенин билгибиз келет. Ал эми биз буга чейин эле ичинен көзөмөлдөп жатабыз.

Муну кантип туура техникалык ишке ашыруу керек: ар бир кызмат өзүнүн учурдагы иштеши жөнүндө акыркы чекитти ачып берет жана Grafana (же башка тиркеме) графиктеринде биз бардык кызматтардын абалын көрөбүз.

• Ар бир API өзгөртүү текшерүүлөрдүн өзгөрүшүнө алып келиши керек.
• Ден соолук көрсөткүчтөрү менен дароо жаңы кызмат түзүңүз.
• Администратор иштеп чыгуучуларга келип, "баарын түшүнүшүм үчүн мага бир нече функцияларды кошуңуз жана мониторинг тутумума бул тууралуу маалымат кошуңуз" деп сурашы мүмкүн. Бирок иштеп чыгуучулар, адатта, "чыгарууга эки жума калганда эч нерсе кошпойбуз" деп жооп беришет.
  Мындай жоготуулар болорун өнүктүрүү менеджерлери билишсин, өнүктүрүү менеджерлеринин жетекчилиги да билсин. Анткени баары кулаганда, кимдир бирөө дагы эле чалып, "тынымсыз түшүп жаткан кызматты" көзөмөлдөөнү талап кылат (c)
• Баса, иштеп чыгуучуларды Grafana үчүн плагиндерди жазууга бөлүңүз - бул администраторлор үчүн жакшы жардам болот.

Колдонмо катмары - интеграциялык мониторинг

Интеграциялык мониторинг бизнес үчүн маанилүү системалардын ортосундагы байланыштарды көзөмөлдөөгө багытталган.

Мисалы, бири-бири менен байланышып турган 15 кызмат бар. Булар өзүнчө сайттар эмес. Ошол. биз кызматты өз алдынча тарта албайбыз, /helloworldду ала албайбыз жана кызмат иштеп жатканын түшүнөбүз. Анткени заказ берүүчү веб-сервис заказ жөнүндө маалыматты автобуска жөнөтүшү керек - автобустан, кампа кызматы бул билдирүүнү алып, аны менен андан ары иштеши керек. Жана электрондук почтаны бөлүштүрүү кызматы муну кандайдыр бир жол менен андан ары иштеп чыгышы керек, ж.б.

Демек, биз ар бир жеке кызматты карап туруп, анын баары иштейт деп түшүнө албайбыз. Анткени бизде белгилүү бир автобус бар, ал аркылуу баары байланышып, өз ара аракеттенет.
Ошондуктан, бул этап башка кызматтар менен өз ара аракеттенүү үчүн кызматтарды тестирлөө этабын белгилеши керек. Билдирүү брокерине мониторинг жүргүзүү менен байланыш мониторингин уюштуруу мүмкүн эмес. Маалыматтарды чыгарган кызмат жана аны кабыл алган кызмат болсо, брокерге мониторинг жүргүзүүдө биз бир тараптан экинчи тарапка учкан маалыматтарды гана көрөбүз. Эгерде биз кандайдыр бир жол менен бул маалыматтардын өз ара аракеттенүүсүн ички көзөмөлдөй алдык да - белгилүү бир продюсер маалыматтарды жайгаштырса, кимдир бирөө аны окуйт, бул агым Кафкага бара берет - эгерде бир кызмат билдирүүнү бир версияда жөнөтсө, бул бизге маалымат бербейт. , бирок башка кызмат бул версияны күткөн эмес жана аны өткөрүп жиберген. Биз бул тууралуу билбейбиз, анткени кызматтар бизге баары иштеп жатканын айтышат.

Мен эмнени сунуштайм:

• Синхрондуу байланыш үчүн: акыркы чекит тиешелүү кызматтарга суроо-талаптарды берет. Ошол. биз бул чекитти алып, кызматтын ичиндеги скриптти тартабыз, ал бардык пункттарга барып, "мен ал жакка тарта алам, ал жакка тарта алам, ал жакка тарта алам ..." дейт.
• Асинхрондук байланыш үчүн: кирүүчү кабарлар - акыркы чекит тесттик билдирүүлөр үчүн автобусту текшерет жана иштетүү статусун көрсөтөт.
• Асинхрондук байланыш үчүн: чыгуучу кабарлар - акыркы чекит тесттик билдирүүлөрдү автобуска жөнөтөт.

Адаттагыдай эле: бизде автобуска маалыматтарды ыргыткан кызмат бар. Биз бул кызматка келип, анын интеграциялык ден соолугу жөнүндө айтып берүүңүздү суранабыз. Ал эми эгер кызмат мындан ары бир жерде (WebApp) билдирүү чыгарышы керек болсо, анда ал бул сыноо билдирүүсүн чыгарат. Эгер биз OrderProcessing жагында кызматты иштетсек, анда ал адегенде көз карандысыз эмнелерди жайгаштырса болорун жарыялайт жана эгер кандайдыр бир көз каранды нерселер болсо, анда ал автобустан тесттик билдирүүлөрдүн топтомун окуп, аларды иштеп чыга аларын түшүнүп, кабарлайт жана , керек болсо, аларды андан ары жайгаштырыңыз жана бул жөнүндө ал айтат - баары жакшы, мен тирүүмүн.

Көбүнчө биз "муну согуштук маалыматтарда кантип сынай алабыз?" деген суроону угабыз. Мисалы, биз ошол эле заказ кызматы жөнүндө айтып жатабыз. Буйрук товарлар эсептен чыгарылган кампага билдирүүлөрдү жөнөтөт: биз муну согуштук маалыматтар боюнча сынай албайбыз, анткени "менин товарларым эсептен чыгарылат!" Чечим бул тестти башынан эле пландаштыруу. Сизде шылдыңдоочу бирдик тесттери да бар. Ошентип, муну тереңирээк деңгээлде жасаңыз, анда сизде бизнестин иштешине зыян келтирбеген байланыш каналы бар.

Инфраструктуранын деңгээли

Инфраструктуранын мониторинги – бул көптөн бери эле мониторинг деп эсептелген нерсе.

• Инфраструктуранын мониторинги өзүнчө процесс катары ишке ашырылышы мүмкүн жана ишке ашырылышы керек.
• Сиз чындап кааласаңыз дагы, иштеп жаткан долбоордо инфраструктурага мониторинг жүргүзүү менен баштабашыңыз керек. Бул бардык динчилдер үчүн азап. "Биринчи мен кластерге мониторинг жасайм, мен инфраструктураны көзөмөлдөйм" - б.а. Биринчиден, ал төмөндө эмне болгонун көзөмөлдөйт, бирок колдонмого кирбейт. Анткени тиркеме devops үчүн түшүнүксүз нерсе. Бул ага агып кеткен, ал кантип иштээрин түшүнбөйт. Бирок ал инфраструктураны түшүнүп, андан баштайт. Бирок жок - сиз ар дайым биринчи колдонмону көзөмөлдөө керек.
• Эскертүүлөрдүн саны менен чектен чыкпаңыз. Заманбап системалардын татаалдыгын эске алганда, эскертүүлөр тынымсыз учуп турат жана сиз кандайдыр бир жол менен бул сигналдар менен жашашыңыз керек. Чакырыктагы адам жүздөгөн кийинки эскертүүлөрдү карап чыгып, "мен бул жөнүндө ойлонгум келбейт" деп чечет. Эскертүүлөр маанилүү нерселер жөнүндө гана билдирүүгө тийиш.

Бизнес бирдиги катары колдонуу деңгээли

Негизги учурлар:

• ELK. Бул өнөр жай стандарты болуп саналат. Эгер кандайдыр бир себептерден улам сиз журналдарды топтобой жатсаңыз, анда дароо жасай баштаңыз.
• APM. Тышкы APMs колдонмо мониторингин тез жабуунун жолу катары (NewRelic, BlackFire, Datadog). Бул нерсени кандайдыр бир жол менен сиз менен эмне болуп жатканын түшүнүү үчүн убактылуу орното аласыз.
• Издөө. Ондогон микросервистерде сиз бардыгын байкашыңыз керек, анткени сурам мындан ары өз алдынча жашабайт. Аны кийинчерээк кошуу абдан кыйын, андыктан иштеп чыгууда издөөнү дароо пландаштыруу жакшы - бул иштеп чыгуучулардын иши жана пайдалуулугу. Эгер сиз аны ишке ашыра элек болсоңуз, анда аны ишке ашырыңыз! Jaeger/Zipkin караңыз

Эскертүү

• Кабарлоо системасын уюштуруу: бир топ нерселерди көзөмөлдөө шарттарында билдирүүлөрдү жөнөтүүнүн бирдиктүү системасы болушу керек. Сиз Grafana болот. Батышта бардыгы PagerDuty колдонот. Эскертүүлөр так болушу керек (мисалы, алар кайдан келген...). Ал эми эскертмелердин дегеле кабыл алынышын контролдоо максатка ылайыктуу
• Нөөмөттөө системасын уюштуруу: эскертүүлөр бардыгына жөнөтүлбөшү керек (же элдин баары реакция кылат, же эч ким реакция кылбайт). Иштеп чыгуучулар да чакырыкта болушу керек: жоопкерчилик чөйрөсүн аныктап, так көрсөтмөлөрдү берип, ага дүйшөмбү жана шаршемби күндөрү кимге чалыш керектигин, шейшемби жана жума күндөрү кимге чалыш керектигин жазыңыз (антпесе алар эч кимге телефон чала албайт. чоң көйгөй болгон окуя - алар сизди ойготуудан же тынчыңызды алуудан коркушат: адамдар көбүнчө башка адамдарга телефон чалганды жана ойготкону жактырышпайт, айрыкча түнкүсүн). Жардам суроо компетентсиздиктин көрсөткүчү эмес экенин түшүндүрүңүз («Мен жардам сурайм, бул мен жаман жумушчумун»), жардам сурап кайрылууга түрткү бериңиз.
• “Билимдер базасын” уюштуруу жана инциденттерди кайра иштетүү боюнча иш процесси: ар бир олуттуу инцидент үчүн өлүмдөн кийинки иш пландалып, убактылуу чара катары инцидентти жөнгө салуучу иш-аракеттер жазылууга тийиш. Жана кайра-кайра эскертүү күнөө экенин адатка айлантыңыз; алар код же инфраструктуралык иштерде бекитилиши керек.

Технологиялык стек

Биздин стек төмөнкүчө экенин элестетип көрөлү:

• маалыматтарды чогултуу - Prometheus + Grafana;
• лог анализи - ELK;
• APM же Tracing үчүн - Jaeger (Zipkin).

Опцияларды тандоо маанилүү эмес. Себеби, башында сиз системаны кантип көзөмөлдөө керектигин түшүнүп, план жазсаңыз, анда сиз өз талаптарыңызга ылайыктуу куралдарды тандап баштайсыз. Суроо сиз биринчи кезекте мониторинг жүргүзүү үчүн тандап алган. Анткени, балким, сиз башында тандаган курал сиздин талаптарга такыр туура келбейт.

Мен акыркы убакта бардык жерде көргөн бир нече техникалык пункттар:

Прометейди Кубернетестин ичине түртүп жатышат - муну ким ойлоп тапты?! Эгер кластериңиз бузулса, эмне кыласыз? Эгерде сизде комплекстүү кластер болсо, кластердин ичинде кандайдыр бир мониторинг системасы болушу керек, ал эми кластердин ичинен маалыматтарды чогулта турган сыртында.

Кластердин ичинде биз журналдарды жана башка нерселерди чогултабыз. Бирок мониторинг системасы сыртта болушу керек. Көбүнчө, Promtheus ичинде орнотулган кластерде сайттын иштешин тышкы текшерүүлөрдү жүргүзгөн системалар да бар. Эгер тышкы дүйнө менен байланышыңыз үзүлүп, колдонмо иштебей калсачы? Көрсө, ичинде баары жакшы, бирок бул колдонуучулар үчүн ишти жеңилдете албайт.

табылгалары

• Өнүктүрүүнүн мониторинги - бул коммуналдык кызматтарды орнотуу эмес, программалык продуктуну иштеп чыгуу. Бүгүнкү мониторингдин 98% коддоо болуп саналат. Кызматтарда коддоо, тышкы текшерүүлөрдү коддоо, тышкы кызматтарды текшерүү жана мунун баары.
• Мониторингге иштеп чыгуучулардын убактысын текке кетирбеңиз: бул алардын ишинин 30% га чейин созулушу мүмкүн, бирок бул татыктуу.
• Devops, сиз бир нерсени көзөмөлдөй албайм деп кабатыр болбоңуз, анткени кээ бир нерселер таптакыр башкача ой жүгүртүү ыкмасы. Сиз программист болгон эмессиз жана мониторинг иши так алардын иши.
• Эгерде долбоор иштеп жаткан болсо жана көзөмөлдөнбөсө (жана сиз менеджер болсоңуз), мониторинг үчүн ресурстарды бөлүңүз.
• Эгерде продукт мурунтан эле өндүрүштө болсо жана сиз "мониторингди орнотуңуз" деп айтылган девопист болсоңуз - мен мунун бардыгын эмне деп жазганымды жетекчиликке түшүндүрүп көрүңүз.

Бул Saint Highload++ конференциясындагы баяндаманын кеңейтилген версиясы.

Эгер сизди менин идеяларым жана ага байланыштуу ойлорум жана ага байланыштуу темалар кызыктырса, анда бул жерде болот каналды оку 🙂

Source: www.habr.com