Усім прывітанне!
Наша кампанія займаецца распрацоўкай праграмнага забеспячэння і наступнай тэхнічнай падтрымкай. У рамках тэхнічнай падтрымкі патрабуецца не проста выпраўляць памылкі, а сачыць за працаздольнасцю нашых прыкладанняў.
Напрыклад, калі "упаў" адзін з сэрвісаў, то трэба аўтаматычна зафіксаваць дадзеную праблему і прыступіць да яе вырашэння, а не чакаць зваротаў у тэхнічную падтрымку незадаволеных карыстальнікаў.
У нас невялікая кампанія, няма рэсурсаў вывучаць і змяшчаць нейкія складаныя рашэнні для маніторынгу прыкладанняў, трэба было знайсці простае і эфектыўнае рашэнне.
Стратэгія маніторынгу
Выканаць праверку працаздольнасці дадатку не проста, гэтая задача нетрывіяльная, можна нават сказаць творчая. Асабліва складана выканаць праверку складанай шматзвенных сістэмы.
Як можна з'есці слана? Толькі па частках! Выкарыстоўваны дадзены падыход для маніторынгу прыкладанняў.
Сутнасць нашай стратэгіі маніторынгу:
Разбіце дадатак на кампаненты.
Для кожнага кампанента прыдумайце кантрольныя праверкі.
Кампанент лічыцца спраўным, калі ўсе яго кантрольныя праверкі выконваюцца без памылак. Прыкладанне лічыцца спраўным, калі спраўныя ўсе яго кампаненты.
Такім чынам любую сістэму можна ўявіць у выглядзе дрэва кампанентаў. Складаныя кампаненты разбіваюцца на прасцейшыя. Простыя кампаненты маюць праверкі.
Кантрольныя праверкі не павінны выконваць функцыянальнае тэсціраванне, гэта не юніт-тэсты. Кантрольныя праверкі павінны правяраць як адчувае сябе кампанент у бягучы момант часу, ці ёсць усе неабходныя для яго функцыянавання рэсурсы, ці ёсць якія праблемы.
Цудаў не бывае, большасць праверак трэба будзе распрацаваць самастойна. Але не варта палохацца, таму што ў большасці выпадкаў адна праверка займае 5-10 радкоў кода, але затое вы зможаце рэалізаваць любую логіку і вам будзе дакладна зразумела, як адпрацоўвае праверка.
Сістэма маніторынгу
Дапусцім мы разбілі дадатак на кампаненты, прыдумалі і рэалізавалі для кожнага кампанента праверкі, але што рабіць з вынікамі гэтых праверак? Як мы даведаемся аб тым, што нейкая праверка выканалася з памылкай?
Нам спатрэбіцца сістэма маніторынгу. Яна будзе выконваць наступныя задачы:
- Атрымліваць вынікі праверак і па іх вызначаць статут кампанентаў.
Візуальна гэта выглядае як падсвятленне дрэва кампанентаў. Спраўныя кампаненты становяцца зялёнымі, праблемныя - чырвонымі. - Выконваць агульныя праверкі «са скрынкі».
Некаторыя праверкі сістэма маніторынгу ўмее выконваць сама. Навошта вынаходзіць ровар, будзем іх выкарыстоўваць. Напрыклад, можна праверыць што старонка сайта адчыняе ці сервер пінгуецца. - Адпраўка апавяшчэнняў аб праблемах зацікаўленым асобам.
- Візуалізацыя дадзеных маніторынгу, прадастаўленне справаздач, графікаў і статыстыкі.
Кароткае апісанне сістэмы АСМА
Лепш за ўсё тлумачыць на прыкладзе. Давайце паглядзім, як арганізаваны маніторынг працаздольнасці сістэмы АСМА.
АСМА - гэта аўтаматызаваная сістэма метэаралагічнага забеспячэння. Сістэма дапамагае спецыялістам дарожных службаў зразумець, дзе і калі неабходна апрацоўваць дарогу супрацьгалалёднымі матэрыяламі. Сістэма збірае даныя з пунктаў дарожнага кантролю. Пункт дарожнага кантролю - гэта месца на дарозе, дзе ўстаноўлена абсталяванне: метэастанцыя, відэакамера і іншае. Для прагназавання небяспечных сітуацый сістэма атрымлівае прагнозы надвор'я са знешніх крыніц.
Такім чынам, склад сістэмы дастаткова тыпавы: вэб-сайт, агент, абсталяванне. Прыступім да маніторынгу.
Разбіваем сістэму на кампаненты
У сістэме АСМО можна вылучыць наступныя кампаненты:
1. Асабісты кабінет
Гэта вэб-дадатак. Прынамсі трэба правяраць, што прыкладанне даступна ў Інтэрнэце.
2. База дадзеных
У базе даных захоўваюцца важныя для справаздачнасці даныя, неабходна правяраць, што рэзервовыя копі базы даных паспяхова ствараюцца.
3. Сервер
Пад серверам маецца на ўвазе жалеза, на якім працуюць прыкладанні. Неабходна правяраць стан HDD, RAM, CPU.
4. Агент
Гэта windows-служба, якая выконвае шмат розных задач па раскладзе. Прынамсі неабходна правяраць, што служба працуе.
5. Задача агента
Проста ведаць, што агент працуе - недастаткова. Агент можа працаваць, але не выконваць ускладзеныя на яго задачы. Разаб'ем кампанент агента на задачы і будзем правяраць ці паспяхова працуе кожная задача агента.
6. Пункты дарожнага кантролю (кантэйнер усіх ГДК)
Пунктаў дарожнага кантролю шмат, таму аб'яднаем усе ГДК у адным кампаненце. Гэта дазволіць больш зручна чытаць даныя маніторынгу. Пры праглядзе стану кампанента "сістэма АСМО" адразу будзе зразумела дзе праблемы: у прыкладаннях, жалезе або ў ГДК.
7. Пункт дарожнага кантролю (адзін ГДК)
Дадзены кампанент будзем лічыць спраўным, калі спраўныя ўсе прылады на дадзеным ГДК.
8. Прылада
Гэта відэакамера або метэастанцыя, якія ўстаноўлены на ГДК. Неабходна правяраць, што прылада спраўна працуе.
У сістэме маніторынгу дрэва кампанентаў будзе выглядаць так:
Маніторынг вэб-прыкладанні
Такім чынам, мы разбілі сістэму на кампаненты, зараз трэба прыдумаць для кожнага кампанента праверкі.
Для маніторынгу вэб-прыкладанні мы выкарыстоўваем наступныя праверкі:
1. Праверка адкрыцця галоўнай старонкі
Гэтую праверку выконвае сістэма маніторынгу. Для яе выканання ўказваем адрас старонкі, чаканы фрагмент адказу і максімальны час выканання запыту.
2. Праверка тэрміну аплаты дамена
Вельмі важная праверка. Калі дамен застаецца без аплаты, карыстачы не могуць адкрыць сайт. Рашэнне праблемы можа заняць некалькі дзён, т.я. змены ДНС прымяняюцца не адразу.
3. Праверка SSL сертыфіката
Цяпер амаль усе сайты выкарыстоўваюць для доступу пратакол https. Для карэктнай працы пратаколу патрэбен валідны SSL сертыфікат.
Ніжэй прадстаўлены кампанент "Асабісты кабінет" у сістэме маніторынгу:
Усе праверкі вышэй падыдуць для большасці прыкладанняў і не патрабуюць напісання кода. Гэта вельмі выдатна, таму што можна пачаць маніторынг любога вэб-прыкладанні за 5 хвілін. Ніжэй прыведзены дадатковыя праверкі, якія можна выканаць для вэб-прыкладанні, але іх рэалізацыя больш складаная і спецыфічная для розных прыкладанняў, таму мы не будзем разбіраць іх у гэтым артыкуле.
Што яшчэ можна праверыць?
Для больш поўнага маніторынгу вэб-прыкладанні можна выканаць наступныя праверкі:
- Колькасць памылак JavaScript за перыяд
- Колькасць памылак на баку вэб-прыкладанні (back-end) за перыяд
- Колькасць не паспяховых адказаў вэб-прыкладанні (код адказу 404, 500 і г.д.)
- Сярэдні час выканання запыту
Маніторынг windows-службы (агента)
У сістэме АСМО агент выконвае ролю планавальніка задач, які ў фонавым рэжыме выконвае задачы па раскладзе.
Калі ўсе задачы агента выконваюцца паспяхова, значыць агент працуе спраўна. Атрымліваецца, каб выканаць маніторынг агента, трэба выканаць маніторынг яго задач. Таму разбіваем кампанент "Агент" на задачы. Створым для кожнай задачы асобны кампанент у сістэме маніторынгу, дзе кампанент "Агент" будзе "бацькам".
Разбіваем кампанент "Агент" на даччыныя кампаненты (задачы):
Такім чынам, мы разбілі складаны кампанент на некалькі простых. Цяпер трэба для кожнага простага кампанента прыдумаць праверкі. Звярніце ўвагу, што бацькоўскі кампанент "Агент" не будзе мець ні адной праверкі, таму што яго стан сістэма маніторынгу вылічыць самастойна па статусе яго даччыных кампанентаў. Іншымі словамі, калі ўсе задачы выконваюцца паспяхова, значыць і агент працуе паспяхова.
У сістэме АСМО больш за сто задач, няўжо для кожнай задачы трэба прыдумляць унікальныя праверкі? Вядома, кантроль будзе лепш, калі для кожнай задачы агента мы прыдумаем і рэалізуем свае спецыяльныя праверкі, але ў большасці выпадкаў дастаткова выкарыстоўваць універсальныя праверкі.
У сістэме АСМО выкарыстоўваюцца толькі ўніверсальныя праверкі для задач і гэтага дастаткова, каб сачыць за працаздольнасцю сістэмы.
Праверка выканання
Самая простая і эфектыўная праверка - гэта праверка выканання. Праверка правярае, што задача выконваецца, прычым без памылак. Дадзеная праверка ёсць ва ўсіх задач.
алгарытм праверкі
Пасля кожнага выканання задачы трэба адправіць у сістэму маніторынгу вынік праверкі SUCCESS, калі выкананне задачы прайшло паспяхова, ці ERROR, калі выкананне завяршылася з памылкай.
Дадзеная праверка дазваляе выявіць наступныя праблемы:
- Задача выконваецца, але завяршаецца памылкай.
- Задача перастала выконвацца, напрыклад, завісла.
Разгледзім, як вырашаюцца дадзеныя праблемы больш падрабязна.
Праблема 1 - Задача выконваецца, але завяршаецца памылкай
Ніжэй намаляваны выпадак, калі задача выконваецца, але з 14:00 да 16:00 завяршаецца памылкай.
Па малюнку відаць, што калі задача завяршаецца памылкай, то адразу адпраўляецца сігнал у сістэму маніторынгу і статут якая адпавядае праверкі ў сістэме маніторынгу становіцца alarm.
Звярніце ўвагу, што ў сістэме маніторынгу ад статусу праверкі залежыць і статус кампанента. Статус alarm праверкі перавядзе ў alarm усе вышэйстаячыя кампаненты, гл. малюнак ніжэй.
Праблема 2 - Задача перастала выконвацца (завісла)
Як сістэма маніторынгу зразумее, што задача завісла?
Вынік праверкі мае час актуальнасці, напрыклад, 1 гадзіну. Калі праходзіць гадзіна, а новага выніку праверкі няма, то сістэма маніторынгу ўсталюе праверцы статут alarm.
На малюнку вышэй а 14:00 выключылі святло. У 15:00 сістэма маніторынгу выявіць, што вынік праверкі (ад 14:00) пратух, т.я. скончыўся час актуальнасці (адна гадзіна), а новага выніку няма, і перавядзе праверку ў статус alarm.
У 16 святло зноў уключылі, праграма выканае задачу і адправіць вынік выканання ў сістэму маніторынгу, статус праверкі зноў стане success.
Які час актуальнасці праверкі выкарыстоўваць?
Час актуальнасці павінен быць большы за перыяд выканання задачы. Рэкамендую ўстанаўліваць час актуальнасці ў 2-3 разы больш, чым перыяд выканання задачы. Гэта трэба, каб не атрымліваць ілжывыя апавяшчэнні, калі, напрыклад, задача выконвалася даўжэй, чым звычайна, ці хтосьці перазагружаў праграму.
Праверка прагрэсу
У сістэме АСМО ёсць задача "Загрузка прагнозу", якая раз у гадзіну спрабуе загрузіць новы прагноз з знешняй крыніцы. Дакладны час, калі ў знешняй сістэме з'яўляецца новы прагноз не вядома, але вядома, што гэта адбываецца 2 разы на дзень. Атрымліваецца, што калі новага прагнозу няма некалькі гадзін, то гэта нармальна, але калі новага прагнозу няма ўжо больш за суткі, то значыць недзе нешта зламалася. Напрыклад, у знешняй сістэме прагнозаў можа змяніцца фармат даных, з-за чаго АСМА не ўбачыць новага рэлізу прагнозу.
алгарытм праверкі
Задача адпраўляе ў сістэму маніторынгу вынік праверкі SUCCESS, калі атрымоўваецца атрымаць прагрэс (загрузіць новы прагноз надвор'я). Калі прагрэсу няма ці здарылася памылка, то нічога ў сістэму маніторынгу не адпраўляецца.
Праверка павінна мець інтэрвал актуальнасці такі, каб за гэты час гарантавана атрымаць новы прагрэс.
Звярніце ўвагу, што аб праблеме мы даведаемся з затрымкай, таму што сістэма маніторынгу чакае, калі скончыцца час актуальнасці апошняга выніку праверкі. Таму час актуальнасці праверкі не трэба рабіць занадта вялікім.
Маніторынг базы дадзеных
Для кантролю базы даных у сістэме АСМО мы выконваем наступныя праверкі:
- Праверка стварэння рэзервовых копій
- Праверка вольнага месца на дыску
Праверка стварэння рэзервовых копій
У большасці прыкладанняў важна мець актуальныя рэзервовыя копіі базы даных, каб у выпадку паломкі сервера можна было разгарнуць праграму на новым серверы.
АСМО раз у тыдзень стварае рэзервовую копію і адпраўляе яе ў сховішча. Калі гэтая працэдура паспяхова завяршаецца ў сістэму маніторынгу адпраўляецца вынік праверкі success. Рэзультат праверкі мае час актуальнасці 9 дзён. Г.зн. для кантролю за стварэннем рэзервовых копій выкарыстоўваецца механізм "праверка прагрэсу", які мы разбіралі вышэй.
Праверка вольнага месца на дыску
Калі на дыску не будзе дастаткова вольнага месца, то база дадзеных не зможа нармальна працаваць, таму важна кантраляваць памер вольнага месца.
Для праверкі лікавых параметраў зручна выкарыстоўваць метрыкі.
Метрыка - Гэта лічбавая пераменная, значэнне якой перадаецца ў сістэму маніторынгу. Сістэма маніторынгу правярае парогавыя значэнні і вылічае статус метрыкі.
Ніжэй прадстаўлены малюнак як выглядае кампанент "База дадзеных" у сістэме маніторынгу:
Маніторынг сервера
Для маніторынгу сервера мы выкарыстоўваем наступныя праверкі і метрыкі:
1. Вольнае месца на дыску
Калі месца на дыску скончыцца, то дадатак не зможа працаваць. У нас выкарыстоўваецца 2 парогавых значэння: першае ўзроўню WARNING, другое ўзроўню ALARM.
2. Сярэдняе значэнне RAM у працэнтах за гадзіну
Мы выкарыстоўваем сярэдняе значэнне за гадзіну, т.я. нас не цікавяць рэдкія скокі.
3. Сярэдняе значэнне CPU у працэнтах за гадзіну
Мы выкарыстоўваем сярэдняе значэнне за гадзіну, т.я. нас не цікавяць рэдкія скокі.
4. Праверка ping
Правярае, што сервер у сетцы. Дадзеную праверку ўмее выконваць сістэма маніторынгу, не трэба пісаць код.
Ніжэй прадстаўлены малюнак як выглядае кампанент "Сервер" у сістэме маніторынгу:
Маніторынг абсталявання
Раскажу, як адбываецца атрыманне даных. Для кожнага пункта дарожнага кантролю (ГДК) у планавальніку задач ёсць задача, напрыклад, «Апытанне ГДК М2 км 200». Задача раз у 30 хвілін атрымлівае дадзеныя з усіх прылад ГДК.
Праблема канала сувязі
Вялікая частка абсталявання стаіць за горадам, для перадачы дадзеных выкарыстоўваецца GSM сетка, якая працуе не стабільна (сетка гэта значыць, тое яе няма).
З-за частых збояў сеткі першы час праверка апытання ГДК у маніторынгу выглядала так:
Стала зразумела, што гэта не працоўны варыянт, таму што атрымлівалася шмат ілжывых апавяшчэнняў аб праблемах. Тады было прынята рашэнне для кожнай прылады выкарыстоўваць "праверку прагрэсу", г.зн. у сістэму маніторынгу адпраўляецца толькі сігнал success, у выпадку, калі прылада апытваецца без памылкі. Час актуальнасці паставілі 5 гадзін.
Цяпер маніторынг дасылае апавяшчэнне аб праблемах, толькі калі прылада не атрымоўваецца апытаць больш за 5 гадзін. З высокай дзеллю верагоднасці гэта не ілжывыя трывогі, а рэальныя праблемы.
Ніжэй прадстаўлены малюнак як выглядае абсталяванне ў сістэме маніторынгу:
Важна!
Калі GSM сетка перастае працаваць, то не апытваюцца ўсе прылады ГДК. Каб паменшыць колькасць лістоў ад сістэмы маніторынгу, нашы інжынеры падпісваюцца на апавяшчэнні аб праблемах кампанентаў з тыпам «ГДК», а не «Прылада». Гэта дазваляе атрымаць адно апавяшчэнне па кожным ГДК, а не атрымліваць асобнае апавяшчэнне па кожным прыладзе.
Выніковая схема маніторынгу АСМА
Давайце збяром усё разам і паглядзім якая схема маніторынгу ў нас атрымалася.
Заключэнне
Давайце падвядзем вынікі.
Што нам даў маніторынг працаздольнасці АСМА?
1. Зменшыўся час ухілення дэфектаў
Раней мы даведваліся аб дэфектах ад карыстачоў, але не ўсе карыстачы паведамляюць аб дэфектах. Бывала так, што аб няспраўнасці які-небудзь кампанента сістэмы мы даведваліся праз тыдзень пасля яго з'яўлення. Цяпер сістэма маніторынгу паведамляе нам аб праблемах адразу, як толькі праблема выяўлена.
2. Павялічылася стабільнасць працы сістэмы
Бо дэфекты сталі ўхіляцца раней, то і сістэма ў цэлым стала працаваць значна стабільней.
3. Зніжэнне колькасці зваротаў у тэхнічную падтрымку
Многія праблемы зараз устараняюцца да таго, як пра іх даведаюцца карыстальнікі. Карыстальнікі сталі менш звяртацца ў тэхнічную падтрымку. Усё гэта добра адбіваецца на нашай рэпутацыі.
4. Павелічэнне лаяльнасці заказчыка і карыстальнікаў
Замовец заўважыў дадатныя змены ў стабільнасці працы сістэмы. Карыстальнікі менш сутыкаюцца з праблемамі ў рабоце з сістэмай.
5. Скарачэнні выдаткаў на тэхнічную падтрымку
Мы перасталі ўручную выконваць якія-небудзь праверкі. Цяпер усе праверкі аўтаматызаваны. Раней мы даведваліся аб праблемах ад карыстачоў, часта было складана зразумець, пра якую праблему кажа карыстач. Зараз аб большасці праблем паведамляе сістэма маніторынгу, апавяшчэнні ўтрымліваюць тэхнічныя дадзеныя, па якіх заўсёды зразумела, што і дзе зламалася.
Важна!
Нельга ўсталёўваць сістэму маніторынгу на той жа сервер, дзе працуюць вашыя прыкладанні. Калі сервер выйдзе са строю, то прыкладанні перастануць працаваць, і няма каму будзе адправіць пра гэта апавяшчэнне.
Сістэма маніторынгу павінна працаваць на асобным серверы ў іншым ЦАД.
Калі вы не жадаеце выкарыстоўваць выдзелены сервер у новым ЦАД, можна скарыстацца хмарнай сістэмай маніторынгу. У нашай кампаніі выкарыстоўваецца хмарная сістэма маніторынгу Zidium, але вы можаце выкарыстоўваць любую іншую сістэму маніторынгу. Кошт хмарнай сістэмы маніторынгу ніжэй арэнды новага сервера.
Рэкамендацыі:
- Разбівайце прыкладанні і сістэмы ў выглядзе дрэва кампанентаў як мага падрабязней, так будзе зручна разумець, дзе і што зламалася, а кантроль будзе больш поўны.
- Каб праверыць працаздольнасць кампанента выкарыстоўвайце праверкі. Лепш выкарыстоўваць шмат простых праверак, чым адну складаную.
- Парогавыя значэнні метрык настройвайце на баку сістэмы маніторынгу, а не прапісвайце ў кодзе. Гэта пазбавіць вас ад перакампілявання, пераканфігуравання або перазапуску прыкладання.
- Для карыстацкіх праверак выкарыстоўвайце час актуальнасці з запасам, каб не атрымліваць ілжывыя апавяшчэнні з-за таго, што нейкая праверка выконвалася крыху даўжэй, чым звычайна.
- Паспрабуйце зрабіць так, каб кампаненты ў сістэме маніторынгу станавіліся чырвонымі толькі тады, калі праблема сапраўды ёсць. Калі яны будуць станавіцца чырвонымі па дробязях, тыя вы перастанеце зважаць на апавяшчэнні сістэмы маніторынгу, яе сэнс будзе згублены.
Калі вы яшчэ не карыстаецеся сістэму маніторынгу, пачынайце! Гэта не так складана, як падаецца. Атрымайце кайф, разглядаючы зялёнае дрэва кампанентаў, якое вы выгадавалі самі.
Ўдачы.
Крыніца: habr.com