Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Поздрав свима!

Наша компанија се бави развојем софтвера и накнадном техничком подршком. Техничка подршка захтева не само исправљање грешака, већ и праћење перформанси наших апликација.

На пример, ако се нека од услуга срушила, онда морате аутоматски да снимите овај проблем и почнете да га решавате, а не да чекате да незадовољни корисници контактирају техничку подршку.

Имамо малу компанију, немамо ресурсе да проучавамо и одржавамо било каква сложена решења за праћење апликација, морали смо да пронађемо једноставно и ефикасно решење.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Стратегија праћења

Није лако проверити функционалност апликације, овај задатак је нетривијалан, могло би се рећи чак и креативан. Посебно је тешко верификовати сложен систем са више веза.

Како можете јести слона? Само у деловима! Овај приступ користимо за надгледање апликација.

Суштина наше стратегије праћења:

Подијелите своју апликацију на компоненте.
Направите контролне провере за сваку компоненту.

Компонента се сматра оперативном ако се све њене контролне провере врше без грешака. Апликација се сматра здравом ако су све њене компоненте функционалне.

Дакле, сваки систем се може представити као стабло компоненти. Сложене компоненте се деле на једноставније. Једноставне компоненте имају провере.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Мерила нису намењена за обављање функционалног тестирања, они нису јединични тестови. Контролне провере треба да провере како се компонента осећа у тренутном тренутку, да ли постоје сви ресурси неопходни за њено функционисање и да ли има проблема.

Нема чуда; већина провера ће морати да се развије независно. Али немојте се плашити, јер у већини случајева једна провера траје 5-10 редова кода, али можете применити било коју логику и јасно ћете разумети како провера функционише.

Мониторинг систем

Рецимо да смо поделили апликацију на компоненте, смислили и имплементирали провере за сваку компоненту, али шта да радимо са резултатима ових провера? Како да знамо да ли нека провера није успела?

Биће нам потребан систем за праћење. Она ће обављати следеће задатке:

  • Примите резултате тестова и користите их за одређивање статуса компоненти.
    Визуелно, ово изгледа као истицање стабла компоненти. Функционалне компоненте постају зелене, проблематичне постају црвене.
  • Извршите опште провере из кутије.
    Систем за надзор може сам да изврши неке провере. Зашто поново измислити точак, хајде да их искористимо. На пример, можете да проверите да ли се страница веб-сајта отвара или сервер пингује.
  • Шаљите обавештења о проблемима заинтересованим странама.
  • Визуелизација података праћења, обезбеђивање извештаја, графикона и статистике.

Кратак опис АСМО система

Најбоље је објаснити на примеру. Погледајмо како је организовано праћење перформанси АСМО система.

АСМО је аутоматизовани систем метеоролошке подршке. Систем помаже стручњацима за путеве да разумеју где и када је потребно третирати пут материјалима за одлеђивање. Систем прикупља податке са контролних тачака на путу. Контролна тачка на путу је место на путу где је инсталирана опрема: метеоролошка станица, видео камера итд. Да би предвидео опасне ситуације, систем прима временску прогнозу из спољних извора.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Дакле, састав система је прилично типичан: веб страница, агент, опрема. Почнимо са праћењем.

Разбијање система на компоненте

У АСМО систему се могу разликовати следеће компоненте:

1. Лични рачун
Ово је веб апликација. У најмању руку, потребно је да проверите да ли је апликација доступна на Интернету.

2. База података
База података складишти податке који су важни за извештавање и морате да обезбедите да су резервне копије базе података направљене успешно.

3. Сервер
Под сервером подразумевамо хардвер на коме се покрећу апликације. Неопходно је проверити статус ХДД, РАМ, ЦПУ.

4. Агент
Ово је Виндовс услуга која извршава много различитих задатака по распореду. У најмању руку, потребно је да проверите да ли је услуга покренута.

5. Задатак агента
Није довољно само знати да агент ради. Агент може да ради, али не и да обавља задатке који су му додељени. Хајде да поделимо компоненту агента на задатке и проверимо да ли сваки задатак агента ради успешно.

6. Контролне тачке на путу (контејнер свих МПЦ)
Постоји много контролних тачака на путу, па хајде да комбинујемо све МПЦ у једну компоненту. Ово ће учинити практичнијим читање података праћења. Када погледате статус компоненте „АСМО систем“, одмах ће бити јасно где су проблеми: у апликацијама, хардверу или у систему максималне контроле.

7. Контролна тачка на путу (један максимум)
Сматраћемо да је ова компонента употребљива ако су сви уређаји на овом МПЦ-у употребљиви.

8. Уређај
Ово је видео камера или метеоролошка станица која је инсталирана на граници максималне концентрације. Неопходно је проверити да ли уређај исправно ради.

У систему за праћење, стабло компоненти ће изгледати овако:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Надгледање веб апликација

Дакле, поделили смо систем на компоненте, сада треба да смислимо провере за сваку компоненту.

За праћење веб апликације користимо следеће провере:

1. Провера отварања главне странице
Ову проверу врши систем за надзор. Да бисмо га извршили, наводимо адресу странице, очекивани фрагмент одговора и максимално време извршења захтева.

2. Провера рока плаћања домена
Веома важна провера. Када домен остане неплаћен, корисници не могу да отворе сајт. Решавање проблема може потрајати неколико дана, јер... ДНС промене се не примењују одмах.

3. Провера ССЛ сертификата
Данас скоро све веб странице користе хттпс протокол за приступ. Да би протокол исправно функционисао, потребан вам је важећи ССЛ сертификат.

Испод је компонента „Лични налог“ у систему за праћење:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Све горе наведене провере ће радити за већину апликација и не захтевају кодирање. Ово је веома кул јер можете почети да надгледате било коју веб апликацију за 5 минута. Испод су додатне провере које се могу извршити за веб апликацију, али је њихова имплементација сложенија и специфична за апликацију, па их нећемо покривати у овом чланку.

Шта још можете да проверите?

Да бисте потпуније надгледали своју веб апликацију, можете извршити следеће провере:

  • Број ЈаваСцрипт грешака по периоду
  • Број грешака на страни веб апликације (позадина) за период
  • Број неуспешних одговора веб апликације (код одговора 404, 500, итд.)
  • Просечно време извршења упита

Надгледање Виндовс услуге (агент)

У АСМО систему, агент игра улогу планера задатака, који извршава заказане задатке у позадини.

Ако су сви задаци агента успешно завршени, агент ради исправно. Испоставило се да да бисте надгледали агента, морате пратити његове задатке. Стога компоненту „Агент“ делимо на задатке. За сваки задатак направићемо посебну компоненту у систему за праћење, где ће компонента „Агент“ бити „родитељ“.

Компоненту агента смо поделили на подређене компоненте (задатке):

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Дакле, разбили смо сложену компоненту на неколико једноставних. Сада морамо да смислимо провере за сваку једноставну компоненту. Имајте на уму да родитељска компонента „Агент“ неће имати никакве провере, јер ће систем за праћење израчунати њен статус независно на основу статуса њених подређених компоненти. Другим речима, ако су сви задаци успешно завршени, онда агент успешно ради.

У АСМО систему има више од стотину задатака, да ли је заиста потребно смислити јединствене провере за сваки задатак? Наравно, контрола ће бити боља ако смислимо и применимо сопствене посебне провере за сваки задатак агента, али у већини случајева довољно је користити универзалне провере.

АСМО систем користи само универзалне провере за задатке и то је довољно за праћење перформанси система.

Провера напретка
Најједноставнија и најефикаснија провера је провера извршења. Провера потврђује да је задатак завршен без грешака. Сви задаци имају ову проверу.

Алгоритам верификације

Након сваког извршења задатка, потребно је да пошаљете резултат провере УСПЕХА у систем за праћење ако је извршење задатка било успешно, или ГРЕШКА ако је извршење завршено са грешком.

Ова провера може открити следеће проблеме:

  1. Задатак се покреће, али не успева са грешком.
  2. Задатак је престао да ради, на пример, замрзнуо се.

Погледајмо како се ови проблеми решавају детаљније.

Проблем 1 – Задатак се покреће, али не успева са грешком
Испод је случај када се задатак покреће, али не успе између 14:00 и 16:00.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Слика показује да када задатак не успе, сигнал се одмах шаље систему за надзор и статус одговарајуће провере у систему за праћење постаје аларм.

Имајте на уму да у систему за праћење статус компоненте зависи од статуса верификације. Статус аларма провере ће променити све компоненте вишег нивоа у аларм, погледајте слику испод.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Проблем 2 - Задатак је престао да се извршава (замрзнут)
Како ће систем за праћење схватити да је задатак заглављен?

Резултат провере има период важења, на пример, 1 сат. Ако прође сат времена и нема новог резултата теста, систем за надзор ће поставити статус теста на аларм.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

На горњој слици светла су угашена у 14 часова. У 00 часова систем за праћење ће открити да је резултат теста (од 15 часова) покварен, јер Време релевантности је истекло (један сат), али нема новог резултата и пребациће проверу у статус аларма.

У 16:00 светла су се поново упалила, програм ће завршити задатак и послати резултат извршења у систем за праћење, статус теста ће поново постати успешан.

Које време провере релевантности треба да користим?

Време релевантности мора бити дуже од периода извршења задатка. Препоручујем да подесите време релевантности 2-3 пута дуже од периода извршења задатка. Ово је неопходно да бисте избегли примање лажних обавештења када је, на пример, задатак трајао дуже него обично или је неко поново учитао програм.

Провера напретка

АСМО систем има задатак „Лоад Форецаст“, ​​који покушава да преузме нову прогнозу са спољног извора једном на сат. Тачно време када се нова прогноза појављује у екстерном систему није познато, али се зна да се то дешава 2 пута дневно. Испада да ако нема нове прогнозе неколико сати, онда је то нормално, али ако нема нове прогнозе дуже од једног дана, онда је негде нешто пукло. На пример, формат података у екстерном систему прогнозе може да се промени, због чега АСМО неће видети ново издање прогнозе.

Алгоритам верификације

Задатак шаље резултат провере УСПЕХА систему за праћење када успе да добије напредак (преузимање нове временске прогнозе). Ако нема напретка или дође до грешке, онда се ништа не шаље у систем за праћење.

Провера мора имати интервал релевантности тако да током овог времена гарантовано добија нови напредак.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Имајте на уму да ћемо о проблему сазнати са закашњењем, јер систем за праћење чека да истекне период важења последњег резултата скенирања. Стога, период важења провере не мора бити предуг.

Праћење базе података

Да бисмо контролисали базу података у АСМО систему, вршимо следеће провере:

  1. Провера прављења резервне копије
  2. Провера слободног простора на диску

Провера прављења резервне копије
У већини апликација, важно је имати ажуриране резервне копије базе података, тако да ако сервер не успе, можете да примените програм на новом серверу.

АСМО прави резервну копију једном недељно и шаље је у складиште. Када се ова процедура успешно заврши, резултат провере успеха се шаље у систем за праћење. Резултат верификације важи 9 дана. Оне. Да би се контролисало стварање резервних копија, користи се механизам „провере напретка“, о коме смо горе говорили.

Провера слободног простора на диску
Ако на диску нема довољно слободног простора, база података неће моћи правилно да функционише, па је важно контролисати количину слободног простора.

Погодно је користити метрику за проверу нумеричких параметара.

Метрицс је нумеричка променљива, чија се вредност преноси на систем за праћење. Систем за праћење проверава граничне вредности и израчунава метрички статус.

Испод је слика како изгледа компонента „База података“ у систему за праћење:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Надгледање сервера

За надгледање сервера користимо следеће провере и метрике:

1. Слободан простор на диску
Ако понестане простора на диску, апликација неће моћи да ради. Користимо 2 граничне вредности: први ниво је УПОЗОРЕЊЕ, други ниво је АЛАРМ.

2. Просечна вредност РАМ меморије у процентима по сату
Користимо сатни просек јер... не занимају нас ретке расе.

3. Просечан проценат процесора по сату
Користимо сатни просек јер... не занимају нас ретке расе.

4. Пинг провера
Проверава да ли је сервер онлајн. Систем за надзор може да изврши ову проверу; нема потребе за писањем кода.

Испод је слика како изгледа компонента „Сервер“ у систему за праћење:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Мониторинг опреме

Рећи ћу вам како се добијају подаци. За сваку контролну тачку пута (МПЦ) постоји задатак у планеру задатака, на пример, „Снимање МПЦ М2 км 200“. Задатак прима податке са свих МПЦ уређаја сваких 30 минута.

Проблем са комуникационим каналом
Већина опреме се налази ван града, за пренос података се користи ГСМ мрежа, која не ради стабилно (мрежа постоји, или је нема).

Због честих кварова на мрежи, у почетку је провера МПЦ анкете у мониторингу изгледала овако:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Постало је јасно да ово није функционална опција, јер је било много лажних обавештења о проблемима. Тада је одлучено да се користи „провера напретка“ за сваки уређај, тј. Систему за надзор се шаље само сигнал успеха када се уређај анкетира без грешке. Време релевантности је постављено на 5 сати.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Сада надгледање шаље обавештења о проблемима само када уређај не може да се испита дуже од 5 сати. Са великим степеном вероватноће, то нису лажни аларми, већ стварни проблеми.

Испод је слика како опрема изгледа у систему за праћење:

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Важно!
Када ГСМ мрежа престане да ради, сви МДЦ уређаји се не прозивају. Да би смањили број е-порука од система за надзор, наши инжењери се претплате на обавештења о проблемима са компонентама типа „МПЦ“ уместо „Уређај“. Ово вам омогућава да примите једно обавештење за сваки МПЦ, уместо да примате засебно обавештење за сваки уређај.

Коначна АСМО шема праћења

Хајде да све саставимо и видимо какву шему мониторинга имамо.

Једемо слона у деловима. Стратегија праћења здравља апликација са примерима

Закључак

Хајде да сумирамо.
Шта нам је дало праћење учинка АСМО?

1. Време отклањања кварова се смањило
Раније смо чули за недостатке од корисника, али сви корисници не пријављују недостатке. Дешавало се да смо за квар неке системске компоненте сазнали недељу дана након што се појавио. Сада нас систем за праћење обавештава о проблемима чим се проблем открије.

2. Стабилност система је повећана
Пошто су кварови почели да се отклањају раније, систем је у целини почео да ради много стабилније.

3. Смањење броја позива техничкој подршци
Многи проблеми су сада решени пре него што корисници уопште сазнају за њих. Корисници су почели ређе да контактирају техничку подршку. Све ово добро утиче на нашу репутацију.

4. Повећање лојалности купаца и корисника
Купац је приметио позитивне промене у стабилности система. Корисници наилазе на мање проблема при коришћењу система.

5. Смањите трошкове техничке подршке
Престали смо да обављамо било какве ручне провере. Сада су све провере аутоматизоване. Раније смо о проблемима учили од корисника; често је било тешко разумети о ком проблему корисник говори. Сада већину проблема пријављује систем за праћење; обавештења садрже техничке податке, који увек јасно показују шта је пошло по злу и где.

Важно!
Не можете инсталирати систем за надзор на истом серверу на коме се покрећу ваше апликације. Ако се сервер поквари, апликације ће престати да раде и неће бити никога да обавести о томе.

Систем за надзор мора да ради на посебном серверу у другом центру података.

Ако не желите да користите наменски сервер у новом центру података, можете користити систем за праћење у облаку. Наша компанија користи систем за праћење облака Зидиум, али можете користити било који други систем за праћење. Цена система за праћење облака је нижа од изнајмљивања новог сервера.

Препоруке:

  1. Разбијте апликације и системе у облику стабла компоненти што је могуће детаљније, тако да ће бити згодно разумети где и шта је покварено, а контрола ће бити потпунија.
  2. Да бисте проверили функционалност компоненте, користите тестове. Боље је користити више једноставних провера него једну сложену.
  3. Конфигуришите метричке прагове на страни система за праћење, уместо да их пишете у коду. Ово ће вас уштедети од потребе да поново компајлирате, поново конфигуришете или поново покренете апликацију.
  4. За прилагођене провере користите временску маргину релевантности да бисте избегли примање лажних обавештења јер је за неке провере било потребно мало дуже него обично.
  5. Покушајте да компоненте у систему за праћење постану црвене само када дефинитивно постоји проблем. Ако за ништа поцрвене, онда ћете престати да обраћате пажњу на обавештења система за праћење, његово значење ће бити изгубљено.

Ако још увек не користите систем за праћење, почните! Није тако тешко као што се чини. Опустите се гледајући дрво зелених састојака које сте сами узгајали.

Срећно.

Извор: ввв.хабр.цом

Додај коментар