Менин атым Антон Бадерин. Мен Жогорку технологиялар борборунда иштейм жана системаны башкаруу менен алектенем. Бир ай мурун биздин корпоративдик конференциябыз аяктады, анда биз топтогон тажрыйбабызды шаарыбыздын IT коомчулугу менен бөлүштүк. Мен веб-тиркемелерди көзөмөлдөө жөнүндө айттым. Материал бул процессти нөлдөн баштап курбаган кенже же орто деңгээлге арналган.
Ар кандай мониторинг системасынын негизи бизнес көйгөйлөрүн чечүү болуп саналат. Мониторинг үчүн мониторинг жүргүзүү эч кимди кызыктырбайт. Бизнес эмнени каалайт? Ошентип, баары тез жана катасыз иштейт. Кызматтагы көйгөйлөрдү биз өзүбүз аныктап, аларды мүмкүн болушунча тезирээк оңдоп алышыбыз үчүн бизнес активдүү болгусу келет. Бул, чынында, мен өткөн жылы биздин кардарлардын биринин долбоору боюнча чечкен көйгөйлөр.
долбоор жөнүндө
Долбоор өлкөдөгү эң чоң лоялдуулук программаларынын бири болуп саналат. Биз чекене соода түйүндөрүнө бонустук карталар сыяктуу ар кандай маркетинг куралдары аркылуу сатуунун жыштыгын көбөйтүүгө жардам беребиз. Жалпысынан долбоор он серверде иштеген 14 тиркемени камтыйт.
Маектешүү процессинде мен администраторлор веб-тиркемелерди көзөмөлдөөгө дайыма эле туура мамиле кыла бербестигин бир нече жолу байкадым: көбү дагы эле операциялык тутумдун метрикасына көңүл бурушат жана кээде кызматтарга көз салышат.
Менин учурда, кардардын мониторинг системасы мурда Icinga негизделген. Жогорудагы көйгөйлөрдү эч кандай чечкен жок. Көбүнчө кардар өзү бизге көйгөйлөр жөнүндө кабарлады, жана көбүнчө себебин түшүнүү үчүн бизде жетиштүү маалымат жок болчу.
Мындан тышкары, аны андан ары енуктуруунун пайдасыздыгын ачык-айкын тушунду. Исинга менен тааныштар мени түшүнөт деп ойлойм. Ошентип, биз долбоор үчүн веб-тиркемелердин мониторинг системасын толугу менен кайра иштеп чыгууну чечтик.
Prometheus
Биз Прометейди үч негизги көрсөткүчтүн негизинде тандадык:
- Жеткиликтүү көрсөткүчтөрдүн көп саны. Биздин учурда алардын 60 миңи бар. Албетте, биз алардын басымдуу көпчүлүгүн (балким 95%ке жакын) колдонбой жатканыбызды белгилей кетүү керек. Башка жагынан алып караганда, алардын баары салыштырмалуу арзан. Биз үчүн бул мурда колдонулган Icinga менен салыштырганда башка экстремалдуу. Анда метрикаларды кошуу өзгөчө азап болгон: учурдагылары кымбат болгон (каалаган плагиндин баштапкы кодун карасаңыз). Ар кандай плагин Bash же Python тилдериндеги скрипт болгон, анын ишке кириши сарпталган ресурстар боюнча кымбат.
- Бул система салыштырмалуу аз өлчөмдөгү ресурстарды керектейт. 600 МБ оперативдүү эс тутум, бир ядронун 15% жана ондогон IOPS биздин бардык көрсөткүчтөрүбүз үчүн жетиштүү. Албетте, сиз метрикаларды экспорттоочуларды иштетишиңиз керек, бирок алардын бардыгы Go программасында жазылган жана ошондой эле электр энергиясына абдан муктаж эмес. Мен азыркы реалдуулукта бул көйгөй деп ойлобойм.
- Kubernetes көчүрүү мүмкүнчүлүгүн камсыз кылат. Кардардын пландарын эске алганда, тандоо ачык.
ELK
Мурда биз журналдарды чогултчу эмеспиз. Кемчиликтер бардыгына тушунуктуу. Биз ELKти тандап алдык, анткени бул система боюнча тажрыйбабыз бар болчу. Биз ал жерде колдонмо журналдарын гана сактайбыз. Негизги тандоо критерийлери толук текстти издөө жана анын ылдамдыгы болгон.
Сlickhouse
Башында, тандоо InfluxDBга түштү. Биз Nginx журналдарын, pg_stat_statements статистикасын чогултуу жана Prometheus тарыхый маалыматтарын сактоо зарылдыгын түшүндүк. Influx бизге жаккан жок, анткени ал мезгил-мезгили менен көп көлөмдөгү эстутумду жеп, кыйроого учурай баштады. Кошумчалай кетсек, мен сурамдарды remote_addr боюнча топтогум келди, бирок бул DBMSте топтоштуруу тегдер боюнча гана. Тегдер кымбат (эстутум), алардын саны шарттуу түрдө чектелген.
Биз кайрадан издөөбүздү баштадык. Минималдуу ресурс керектелген аналитикалык маалымат базасы керек болчу, эң жакшысы дискте маалыматтарды кысуу менен.
Clickhouse бул критерийлердин баарына жооп берет жана биз тандообузга эч качан өкүнгөн эмеспиз. Биз ага эч кандай өзгөчө көлөмдөгү маалыматтарды жазбайбыз (киргизүүлөрдүн саны мүнөтүнө беш миңге жакын).
NewRelic
NewRelic тарыхтан биз менен болгон, анткени ал кардардын тандоосу болгон. Биз аны APM катары колдонобуз.
Апенди
Биз Zabbix'ти ар кандай API'лердин Black Box'ун көзөмөлдөө үчүн гана колдонобуз.
Мониторинг ыкмасын аныктоо
Биз тапшырманы бөлүп, ошону менен мониторинг жүргүзүү ыкмасын системалаштырууну кааладык.
Бул үчүн, мен биздин системаны төмөнкү деңгээлдерге бөлдүм:
- аппараттык жана VMS;
- операциондук система;
- системалык кызматтар, программалык стек;
- арыз;
- бизнес логикасы.
Эмне үчүн бул ыкма ыңгайлуу:
- биз ар бир деңгээлдеги иш үчүн ким жооптуу экенин билебиз жана анын негизинде эскертүүлөрдү жөнөтө алабыз;
- биз эскертүүлөрдү басууда структураны колдоно алабыз - виртуалдык машина бүтүндөй иштебей турганда, маалымат базасынын жеткиликтүү эместиги жөнүндө эскертүү жөнөтүү кызыктай болмок.
Биздин милдет системанын иштөөсүндөгү бузууларды аныктоо болгондуктан, биз ар бир деңгээлде эскертүү эрежелерин жазууда көңүл бурууга арзырлык көрсөткүчтөрдүн белгилүү бир топтомун бөлүп көрсөтүшүбүз керек. Андан кийин, келгиле, "VMS", "Операциялык система" жана "Системалык кызматтар, программалык камсыздоо стекти" деңгээлдеринен өтөлү.
Виртуалдык машиналар
Хостинг бизге процессорду, дискти, эстутумду жана тармакты бөлүп берет. Ал эми биринчи экөөбүздө кыйынчылыктар болду. Ошентип, көрсөткүчтөр:
CPU уурдалган убакыт - сиз Amazonдан виртуалдык машинаны сатып алганыңызда (мисалы, t2.micro), сизге процессордун өзөгү бүтүндөй эмес, анын убактысынын квотасы гана бөлүнгөнүн түшүнүшүңүз керек. Ал эми аны түгөткөндө процессор сенден тартып алынат.
Бул метрика ушундай учурларды байкоого жана чечим кабыл алууга мүмкүндүк берет. Мисалы, майлуураак тарифти алуу керекпи же фондо тапшырмаларды жана API сурамдарын иштеп чыгууну ар кандай серверлерге бөлүштүрүү керекпи?
IOPS + CPU iowait убактысы - кандайдыр бир себептерден улам, көптөгөн булут хостингдери IOPSти жетишсиз камсыз кылуу менен күнөө кылышат. Мындан тышкары, IOPS төмөн график алар үчүн аргумент эмес. Ошондуктан, CPU iowait чогултуу арзырлык. Бул жуп графиктер менен - төмөн IOPS жана жогорку I/O күтүү менен - сиз хостинг менен сүйлөшүп, көйгөйдү чече аласыз.
Операциондук система
Операциялык системанын көрсөткүчтөрү:
- жеткиликтүү эстутумдун көлөмү % менен;
- swap колдонуу аракети: vmstat swapin, swapout;
- жеткиликтүү иноддордун саны жана файл тутумундагы бош орун % менен
- орточо жүк;
- tw абалындагы байланыштардын саны;
- conntrack столдун толуктугу;
- Тармактын сапатын ss утилитасынын, iproute2 пакетинин жардамы менен көзөмөлдөөгө болот - анын чыгышынан RTT туташууларынын көрсөткүчүн алыңыз жана аны дест порту боюнча топтоңуз.
Ошондой эле операциялык системанын деңгээлинде бизде процесстер сыяктуу объект бар. Системада анын иштешинде маанилүү роль ойногон процесстердин комплексин аныктоо маанилүү. Эгер, мисалы, сизде бир нече pgpool болсо, анда алардын ар бири үчүн маалымат чогултушуңуз керек.
Метрикалардын жыйындысы төмөнкүдөй:
- CPUs;
- эс биринчи кезекте резидент болуп саналат;
- IO - жакшыраак IOPSте;
- FileFd - ачуу жана чектөө;
- олуттуу барак каталары - ушундай жол менен сиз кандай процесс алмаштырылып жатканын түшүнө аласыз.
Биз Dockerдеги бардык мониторингди орнотобуз жана метрикалык маалыматтарды чогултуу үчүн Advisor колдонобуз. Башка машиналарда биз процесс-экспортторду колдонобуз.
Системалык кызматтар, программалык камсыздоо стек
Ар бир тиркеме өзүнүн өзгөчөлүктөрүнө ээ жана белгилүү бир көрсөткүчтөрдү бөлүп көрсөтүү кыйын.
универсалдуу топтому болуп саналат:
- суроо-талап баасы;
- каталардын саны;
- күтүү;
- каныктыруу.
Бул деңгээлдеги мониторингдин эң айкын мисалдары Nginx жана PostgreSQL болуп саналат.
Биздин системадагы эң көп жүктөлгөн кызмат бул маалымат базасы. Мурда биз көп учурда маалымат базасы эмне кылып жатканын түшүнбөй кыйналчубуз.
Биз дисктерде жогорку жүктү көрдүк, бирок жай журналдар чындыгында эч нерсе көрсөткөн жок. Биз бул маселени pg_stat_statements, суроо статистикасын чогултуучу көрүнүш аркылуу чечтик.
Админге ушул гана керек.
Биз окуу жана жазуу сурамдарынын активдүүлүгүнүн графиктерин түзөбүз:
Баары жөнөкөй жана түшүнүктүү, ар бир суроонун өзүнүн түсү бар.
Ушундай эле айкын мисал - Nginx журналдары. Аларды талдап же сөзсүз болушу керектердин тизмесинде эскерген адамдар аз экени таң калыштуу эмес. Стандарттык формат өтө маалыматтуу эмес жана аны кеңейтүү керек.
Жеке мен суроо_убакыт, жогорку_жооп_убакыт, дене_байт_жөнөтүлгөн, суроо_узундугу, суроо_идентификаторун коштум. Жооп убактысын жана каталардын санын түзөбүз:
Биз жооп убактысынын жана каталардын санынын графиктерин түзөбүз. Эсиңиздеби? Мен бизнес милдеттери жөнүндө айттымбы? Тез жана катасыз үчүн? Бул маселелерди биз буга чейин эки диаграмма менен чагылдырганбыз. Аларды колдонуп дежурный администраторлорго чалса болот.
Бирок дагы бир көйгөй - окуянын себептерин тез арада жоюуну камсыз кылуу.
Окуяны чечүү
Көйгөйдү аныктоодон баштап чечүүгө чейинки бүт процессти бир нече кадамдарга бөлүүгө болот:
- көйгөйдү аныктоо;
- дежурный администраторго билдирүү;
- окуяга жооп берүү;
- себептерин жоюу.
Муну биз мүмкүн болушунча тезирээк жасашыбыз маанилүү. Ал эми көйгөйдү аныктоо жана билдирүү жөнөтүү этаптарында биз көп убакытка ээ боло албасак - кандай болгон күндө да аларга эки мүнөт сарпталат, андан кийинкилери - жакшыртуу үчүн жөн эле айдалбаган талаа.
Элестетип көрөлү, нөөмөтчүнүн телефону шыңгырап калды. Ал эмне кылат? Суроолорго жооп издеңиз - эмне сынды, кайда сынды, кандай реакция кылуу керек? Бул суроолорго кантип жооп беребиз:
Биз жөн гана бул маалыматтын баарын эскертменин текстине киргизип, ага бул көйгөйгө кантип жооп берүү, аны чечүү жана аны көтөрүү жолдорун сүрөттөгөн вики-баракчага шилтеме беребиз.
Мен дагы эле колдонмо катмары жана бизнес логикасы жөнүндө эч нерсе айткан жокмун. Тилекке каршы, биздин тиркемелерибиз азырынча метрикаларды чогултууну ишке ашыра элек. Бул деңгээлдердеги ар кандай маалыматтын жалгыз булагы журналдар болуп саналат.
Бир-эки пункт.
Биринчиден, структураланган журналдарды жаз. Билдирүүнүн текстине контекстти киргизүүнүн кереги жок. Бул аларды топтоого жана талдоону кыйындатат. Мунун баарын нормалдаштыруу үчүн Logstash көп убакытты талап кылат.
Экинчиден, оордук даражасын туура колдонуңуз. Ар бир тилдин өзүнүн стандарты бар. Жеке мен төрт деңгээлди бөлөм:
- эч кандай ката;
- кардар тараптын катасы;
- ката биз тарапта, биз акча жоготпойбуз, тобокелчиликти көтөрбөйбүз;
- Ката биз тарапта, биз акча жоготуп жатабыз.
Мен кыскача айтып берейин. Сиз бизнес логикасына негизделген мониторинг курууга аракет кылышыңыз керек. Тиркеменин өзүн көзөмөлдөөгө аракет кылыңыз жана сатуулардын саны, жаңы колдонуучу каттоолордун саны, учурда активдүү колдонуучулардын саны ж.б.у.с.
Эгерде сиздин бүт бизнесиңиз браузердин бир баскычы болсо, анда анын чыкылдатылып, туура иштеп жаткандыгына көз салышыңыз керек. Калганынын баары маанилүү эмес.
Эгер сизде бул жок болсо, биз кылгандай, аны тиркеме журналдарынан, Nginx журналдарынан ж.б. Колдонмого мүмкүн болушунча жакын болушуңуз керек.
Операциялык системанын көрсөткүчтөрү, албетте, маанилүү, бирок бизнес аларга кызыкдар эмес, алар үчүн бизге акы төлөнбөйт.
Source: www.habr.com