Здраво на сите!
Нашата компанија се занимава со развој на софтвер и последователна техничка поддршка. Техничката поддршка не бара само поправање на грешки, туку и следење на перформансите на нашите апликации.
На пример, ако една од услугите се урна, тогаш треба автоматски да го снимите овој проблем и да започнете да го решавате, а не да чекате незадоволните корисници да контактираат со техничка поддршка.
Имаме мала компанија, немаме ресурси да проучуваме и одржуваме какви било сложени решенија за следење на апликациите, ни требаше да најдеме едноставно и ефективно решение.
Стратегија за следење
Не е лесно да се провери функционалноста на апликацијата; оваа задача е нетривијална, може да се каже дури и креативна. Особено е тешко да се потврди сложениот систем со повеќе врски.
Како можете да јадете слон? Само во делови! Овој пристап го користиме за следење на апликациите.
Суштината на нашата стратегија за мониторинг:
Поделете ја вашата апликација на компоненти.
Креирајте контролни проверки за секоја компонента.
Компонентата се смета за оперативна ако сите нејзини контролни проверки се вршат без грешки. Апликацијата се смета за здрава ако сите нејзини компоненти се функционални.
Така, секој систем може да се претстави како дрво на компоненти. Комплексните компоненти се поделени на поедноставни. Едноставните компоненти имаат проверки.
Реперите не се наменети да вршат функционално тестирање, тие не се единечни тестови. Контролните проверки треба да проверат како се чувствува компонентата во тековниот момент во времето, дали ги има сите ресурси потребни за нејзино функционирање и дали има некакви проблеми.
Нема чуда; повеќето проверки ќе треба да се развијат независно. Но, не плашете се, бидејќи во повеќето случаи за една проверка се потребни 5-10 линии код, но можете да спроведете каква било логика и јасно ќе разберете како функционира проверката.
Систем за следење
Да речеме дека ја поделивме апликацијата на компоненти, смисливме и имплементиравме проверки за секоја компонента, но што да правиме со резултатите од овие проверки? Како да знаеме дали некоја проверка не успеала?
Ќе ни треба систем за следење. Таа ќе ги извршува следните задачи:
- Добијте резултати од тестот и користете ги за да го одредите статусот на компонентите.
Визуелно, ова изгледа како да се истакнува дрвото на компонентата. Функционалните компоненти стануваат зелени, проблематичните стануваат црвени. - Извршете општи проверки надвор од кутијата.
Системот за следење може самиот да изврши некои проверки. Зошто повторно да го измислиме тркалото, ајде да ги искористиме. На пример, можете да проверите дали се отвора страница на веб-локација или дали серверот ѕвони. - Испратете известувања за проблеми до заинтересираните страни.
- Визуелизација на податоците од мониторингот, обезбедување на извештаи, графикони и статистики.
Краток опис на системот ASMO
Најдобро е да се објасни со пример. Ајде да погледнеме како е организирано следењето на перформансите на системот ASMO.
ASMO е автоматизиран систем за метеоролошка поддршка. Системот им помага на специјалистите за патни услуги да разберат каде и кога е потребно да се третира патот со материјали за одмрзнување. Системот собира податоци од контролните точки на патиштата. Контролна точка на патот е место на патот каде што е инсталирана опрема: метеоролошка станица, видео камера итн. За да предвиди опасни ситуации, системот добива временски прогнози од надворешни извори.
Значи, составот на системот е сосема типичен: веб-страница, агент, опрема. Да почнеме да следиме.
Разложување на системот на компоненти
Следниве компоненти може да се разликуваат во системот ASMO:
1. Лична сметка
Ова е веб апликација. Најмалку, треба да проверите дали апликацијата е достапна на Интернет.
2. База на податоци
Базата на податоци складира податоци кои се важни за известување и мора да се погрижите успешно да се креираат резервни копии на базата на податоци.
3. Сервер
Под сервер мислиме на хардверот на кој работат апликациите. Неопходно е да се провери статусот на HDD, RAM, CPU.
4. Агент
Ова е услуга на Windows која извршува многу различни задачи на распоред. Најмалку, треба да проверите дали услугата работи.
5. Задача за агент
Не е доволно само да се знае дека агентот работи. Агентот може да работи, но да не ги извршува своите доделени задачи. Ајде да ја поделиме компонентата на агентот на задачи и да провериме дали секоја задача на агент работи успешно.
6. Патни контролни точки (контејнер со сите MPC)
Има многу контролни точки на патот, па ајде да ги комбинираме сите MPC во една компонента. Ова ќе го направи поудобно читањето на податоците од мониторингот. Кога го гледате статусот на компонентата „ASMO system“, веднаш ќе биде јасно каде се проблемите: во апликациите, хардверот или во системот за максимална контрола.
7. Патна контролна точка (една максимална граница)
Оваа компонента ќе ја сметаме за услужлива доколку сите уреди на овој MPC се сервисираат.
8. Уред
Ова е видео камера или метеоролошка станица што е инсталирана на максималната граница на концентрација. Неопходно е да се провери дали уредот работи правилно.
Во системот за следење, дрвото на компонентите ќе изгледа вака:
Следење на веб-апликации
Значи, го поделивме системот на компоненти, сега треба да излеземе со проверки за секоја компонента.
За следење на веб-апликација ги користиме следните проверки:
1. Проверка на отворањето на главната страница
Оваа проверка ја врши мониторинг системот. За да го извршиме, ја означуваме адресата на страницата, очекуваниот фрагмент за одговор и максималното време за извршување на барањето.
2. Проверка на рокот за плаќање на доменот
Многу важна проверка. Кога доменот останува неплатен, корисниците не можат да ја отворат страницата. Решавањето на проблемот може да потрае неколку дена, бидејќи ... Промените на DNS не се применуваат веднаш.
3. Проверка на SSL сертификатот
Во денешно време, речиси сите веб-локации го користат протоколот https за пристап. За протоколот да работи правилно, потребен ви е валиден SSL сертификат.
Подолу е компонентата „Лична сметка“ во системот за следење:
Сите горенаведени проверки ќе работат за повеќето апликации и не бараат кодирање. Ова е многу кул бидејќи можете да започнете со следење на која било веб-апликација за 5 минути. Подолу се дадени дополнителни проверки што можат да се извршат за веб-апликација, но нивната имплементација е посложена и специфична за апликацијата, па затоа нема да ги опфатиме во оваа статија.
Што друго можете да проверите?
За поцелосно следење на вашата веб-апликација, можете да ги извршите следните проверки:
- Број на грешки во JavaScript по период
- Број на грешки на страната на веб-апликацијата (заден крај) за периодот
- Број на неуспешни одговори на веб-апликации (шифра за одговор 404, 500, итн.)
- Просечно време на извршување на барањето
Следење на услуга на Windows (агент)
Во системот ASMO, агентот ја игра улогата на распоредувач на задачи, кој ги извршува закажаните задачи во позадина.
Ако сите задачи на агентот се завршат успешно, агентот работи правилно. Излегува дека за да следите агент, треба да ги следите неговите задачи. Затоа, компонентата „Агент“ ја делиме на задачи. За секоја задача, ќе создадеме посебна компонента во системот за следење, каде што компонентата „Агент“ ќе биде „родител“.
Ја поделивме компонентата Агент на детски компоненти (задачи):
Значи, ние разложивме сложена компонента на неколку едноставни. Сега треба да излеземе со проверки за секоја едноставна компонента. Имајте предвид дека матичната компонента „Агент“ нема да има никакви проверки, бидејќи системот за следење ќе го пресметува неговиот статус независно врз основа на статусот на неговите детски компоненти. Со други зборови, ако сите задачи се успешно завршени, тогаш агентот работи успешно.
Има повеќе од сто задачи во системот ASMO, дали е навистина потребно да се смисли уникатни проверки за секоја задача? Се разбира, контролата ќе биде подобра ако смислиме и спроведеме свои посебни проверки за секоја задача на агентот, но во повеќето случаи доволно е да користиме универзални проверки.
Системот ASMO користи само универзални проверки за задачи и тоа е доволно за следење на перформансите на системот.
Проверка на напредокот
Наједноставната и најефективната проверка е проверката на извршувањето. Проверката потврдува дека задачата е завршена без грешки. Сите задачи ја имаат оваа проверка.
Алгоритам за проверка
По секое извршување на задачата, треба да го испратите резултатот од проверката SUCCESS до системот за следење ако извршувањето на задачата било успешно или ERROR ако извршувањето е завршено со грешка.
Оваа проверка може да ги открие следниве проблеми:
- Задачата работи, но не успева со грешка.
- Задачата престана да работи, на пример, замрзна.
Ајде да погледнеме како овие проблеми се решаваат подетално.
Прашање 1 - Задачата работи, но не успева со грешка
Подолу е случај кога задачата работи, но не успева помеѓу 14:00 и 16:00 часот.
Сликата покажува дека кога задачата не успее, веднаш се испраќа сигнал до системот за следење и статусот на соодветната проверка во системот за следење станува аларм.
Ве молиме имајте предвид дека во системот за следење, статусот на компонентата зависи од статусот на верификација. Статусот на алармот на проверката ќе ги промени сите компоненти на повисоко ниво во аларм, видете ја сликата подолу.
Задача 2 - Задачата престана да се извршува (замрзната)
Како системот за следење ќе разбере дека задачата е заглавена?
Резултатот од проверката има период на важност, на пример, 1 час. Ако помине еден час и нема нов резултат од тестот, системот за следење ќе го постави статусот на тестот на аларм.
На сликата погоре, светлата беа исклучени во 14:00 часот. Во 15:00 часот, системот за следење ќе открие дека резултатот од тестот (од 14:00 часот) е скапан, бидејќи Времето на важност истече (еден час), но нема нов резултат и проверката ќе се префрли на статус на аларм.
Во 16:00 часот светлата повторно се вклучија, програмата ќе ја заврши задачата и ќе го испрати резултатот од извршувањето до системот за следење, статусот на тестот повторно ќе стане успешен.
Кое време на важност за проверка треба да користам?
Времето на релевантност мора да биде поголемо од периодот на извршување на задачата. Препорачувам да го поставите времето на важност 2-3 пати подолго од периодот на извршување на задачата. Ова е неопходно за да се избегне примање лажни известувања кога, на пример, некоја задача траела подолго од вообичаеното или некој повторно ја вчитал програмата.
Проверка на напредокот
Системот ASMO има задача „Прогноза на оптоварување“, која се обидува да преземе нова прогноза од надворешен извор еднаш на час. Точното време кога се појавува нова прогноза во надворешниот систем не е познато, но се знае дека тоа се случува 2 пати на ден. Излегува дека ако нема нова прогноза неколку часа, тогаш ова е нормално, но ако нема нова прогноза повеќе од еден ден, тогаш нешто некаде се скршило. На пример, форматот на податоци во надворешен систем за прогнозирање може да се промени, поради што ASMO нема да види ново издание на прогнозата.
Алгоритам за проверка
Задачата го испраќа резултатот од проверката УСПЕХ до системот за следење кога ќе успее да постигне напредок (преземање нова временска прогноза). Ако нема напредок или се појави грешка, тогаш ништо не се испраќа до системот за следење.
Проверката мора да има интервал на релевантност така што за тоа време се гарантира дека ќе добие нов напредок.
Имајте предвид дека ќе дознаеме за проблемот со задоцнување, бидејќи системот за следење чека додека не истече периодот на важност на последниот резултат од скенирањето. Затоа, периодот на важност на проверката не треба да се прави предолг.
Следење на бази на податоци
За да ја контролираме базата на податоци во системот ASMO, ги извршуваме следните проверки:
- Се потврдува создавањето резервна копија
- Проверка на слободен простор на дискот
Се потврдува создавањето резервна копија
Во повеќето апликации, важно е да имате ажурирани резервни копии на базата на податоци, така што ако серверот не успее, можете да ја распоредите програмата на нов сервер.
ASMO создава резервна копија еднаш неделно и ја испраќа во складиште. Кога оваа постапка е успешно завршена, резултатот од проверката на успехот се испраќа до системот за следење. Резултатот од верификацијата важи 9 дена. Оние. За контрола на создавањето резервни копии, се користи механизмот „проверка на напредок“, за кој разговаравме погоре.
Проверка на слободен простор на дискот
Ако нема доволно слободен простор на дискот, базата на податоци нема да може да функционира правилно, па затоа е важно да се контролира количината на слободен простор.
Удобно е да се користат метрики за проверка на нумеричките параметри.
Метрика е нумеричка променлива, чија вредност се пренесува до системот за следење. Системот за следење ги проверува вредностите на прагот и го пресметува метричкиот статус.
Подолу е слика за тоа како изгледа компонентата „База на податоци“ во системот за следење:
Следење на серверот
За следење на серверот ги користиме следните проверки и метрика:
1. Слободен простор на дискот
Ако истече просторот на дискот, апликацијата нема да може да работи. Ние користиме 2 праг вредности: првото ниво е ПРЕДУПРЕДУВАЊЕ, второто ниво е АЛАРМ.
2. Просечна вредност на RAM меморијата во проценти на час
Го користиме просекот на час бидејќи ... не сме заинтересирани за ретки трки.
3. Просечен процент на процесорот на час
Го користиме просекот на час бидејќи ... не сме заинтересирани за ретки трки.
4. Пинг проверка
Проверува дали серверот е онлајн. Системот за следење може да ја изврши оваа проверка, нема потреба да пишува код.
Подолу е слика за тоа како изгледа компонентата „Сервер“ во системот за следење:
Следење на опремата
Ќе ви кажам како се добиваат податоците. За секоја контролна точка на патот (MPC) има задача во планерот на задачи, на пример, „Истражување MPC M2 km 200“. Задачата прима податоци од сите MPC уреди на секои 30 минути.
Проблем со каналот за комуникација
Поголемиот дел од опремата се наоѓа надвор од градот, за пренос на податоци се користи GSM мрежа, која не работи стабилно (има мрежа или ја нема).
Поради честите неуспеси на мрежата, на почетокот, проверката на истражувањето на MPC при мониторинг изгледаше вака:
Стана јасно дека ова не е работна опција, бидејќи имаше многу лажни известувања за проблеми. Потоа беше одлучено да се користи „проверка на напредок“ за секој уред, т.е. Само сигналот за успех се испраќа до системот за следење кога уредот се анкетира без грешка. Релевантното време беше поставено на 5 часа.
Сега мониторингот испраќа известувања за проблеми само кога уредот не може да се анкетира повеќе од 5 часа. Со висок степен на веројатност, ова не се лажни аларми, туку реални проблеми.
Подолу е слика за тоа како изгледа опремата во системот за следење:
Важно!
Кога GSM мрежата ќе престане да работи, сите MDC уреди не се анкетирани. За да го намалат бројот на е-пошта од системот за следење, нашите инженери се претплатуваат на известувања за проблеми со компонентата со типот „MPC“ наместо „Уред“. Ова ви овозможува да добивате едно известување за секој MPC, наместо да добивате посебно известување за секој уред.
Конечна шема за следење на ASMO
Ајде да составиме сè и да видиме каква шема за следење имаме.
Заклучок
Да резимираме.
Што ни даде следењето на работата на АСМО?
1. Времето за отстранување на дефектот е намалено
Претходно сме слушнале за дефекти од корисници, но не сите корисници пријавуваат дефекти. Се случи да дознаеме за дефект на системската компонента една недела откако се појави. Сега системот за следење нè известува за проблеми веднаш штом ќе се открие проблем.
2. Стабилноста на системот е зголемена
Бидејќи дефектите почнаа да се елиминираат порано, системот како целина почна да работи многу постабилно.
3. Намалување на бројот на повици до техничка поддршка
Многу проблеми сега се поправени пред корисниците воопшто да знаат за нив. Корисниците почнаа да контактираат со техничка поддршка поретко. Сето ова добро влијае на нашата репутација.
4. Зголемување на лојалноста на клиентите и корисниците
Клиентот забележа позитивни промени во стабилноста на системот. Корисниците наидуваат на помалку проблеми со користење на системот.
5. Намалете ги трошоците за техничка поддршка
Престанавме да вршиме какви било рачни проверки. Сега сите проверки се автоматизирани. Претходно, дознавме за проблемите од корисниците; честопати беше тешко да се разбере за каков проблем зборува корисникот. Сега, повеќето проблеми ги пријавува системот за следење; известувањата содржат технички податоци, кои секогаш јасно покажуваат што тргнало наопаку и каде.
Важно!
Не можете да го инсталирате системот за следење на истиот сервер каде што работат вашите апликации. Ако серверот се исклучи, апликациите ќе престанат да работат и нема да има кој да известува за тоа.
Системот за следење мора да работи на посебен сервер во друг центар за податоци.
Ако не сакате да користите посветен сервер во нов центар за податоци, можете да користите систем за следење облак. Нашата компанија го користи системот за следење облак Zidium, но можете да користите кој било друг систем за следење. Цената на системот за следење облак е пониска од изнајмувањето нов сервер.
Препораки:
- Разложете ги апликациите и системите во форма на дрво на компоненти што е можно повеќе детали, така што ќе биде погодно да се разбере каде и што е скршено, а контролата ќе биде поцелосна.
- За да ја проверите функционалноста на компонентата, користете тестови. Подобро е да користите многу едноставни проверки отколку една сложена.
- Конфигурирајте ги метричките прагови на страната на системот за следење, наместо да ги пишувате во код. Ова ќе ве спаси од потребата да ја прекомпајлирате, реконфигурирате или рестартирате апликацијата.
- За приспособени проверки, користете маргина на важност за да избегнете примање лажни известувања бидејќи на некои проверки им требаше малку подолго од вообичаеното.
- Обидете се да направите компонентите во системот за следење да станат црвени само кога дефинитивно има проблем. Ако за џабе станат црвени, тогаш ќе престанете да обрнувате внимание на известувањата на системот за следење, неговото значење ќе се изгуби.
Ако сè уште не користите систем за следење, почнете! Не е толку тешко како што изгледа. Добијте удар од гледањето на дрвото зелени состојки што сами го израснавте.
Со среќа.
Извор: www.habr.com