Здравейте на всички!
Нашата компания се занимава с разработка на софтуер и последваща техническа поддръжка. Техническата поддръжка изисква не само коригиране на грешки, но и наблюдение на ефективността на нашите приложения.
Например, ако една от услугите се е сринала, тогава трябва автоматично да запишете този проблем и да започнете да го решавате, а не да чакате недоволните потребители да се свържат с техническата поддръжка.
Имаме малка компания, нямаме ресурси да изучаваме и поддържаме сложни решения за приложения за мониторинг, трябваше да намерим просто и ефективно решение.
Стратегия за наблюдение
Не е лесно да се провери функционалността на дадено приложение, тази задача е нетривиална, дори може да се каже творческа. Особено трудно е да се провери сложна система с много връзки.
Как можеш да ядеш слон? Само на части! Използваме този подход за наблюдение на приложения.
Същността на нашата стратегия за мониторинг:
Разбийте приложението си на компоненти.
Създайте контролни проверки за всеки компонент.
Един компонент се счита за работещ, ако всички негови контролни проверки са извършени без грешки. Едно приложение се счита за здравословно, ако всички негови компоненти са функционални.
Така всяка система може да бъде представена като дърво от компоненти. Сложните компоненти се разделят на по-прости. Простите компоненти имат проверки.
Бенчмарковете не са предназначени за извършване на функционално тестване, те не са единици тестове. Контролните проверки трябва да проверят как се чувства компонентът в текущия момент, дали има всички необходими ресурси за функционирането му и дали има проблеми.
Няма чудеса; повечето проверки ще трябва да бъдат разработени независимо. Но не се плашете, защото в повечето случаи една проверка отнема 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 за период
- Брой грешки от страна на уеб приложението (back-end) за периода
- Брой неуспешни отговори на уеб приложение (код на отговор 404, 500 и т.н.)
- Средно време за изпълнение на заявката
Наблюдение на услуга на Windows (агент)
В системата ASMO агентът играе ролята на планировчик на задачи, който изпълнява планираните задачи във фонов режим.
Ако всички задачи на агента са изпълнени успешно, агентът работи правилно. Оказва се, че за да наблюдавате агент, трябва да следите задачите му. Затова разделяме компонента „Агент“ на задачи. За всяка задача ще създадем отделен компонент в системата за мониторинг, където компонентът „Агент“ ще бъде „родител“.
Разделяме компонента Agent на дъщерни компоненти (задачи):
И така, разделихме един сложен компонент на няколко прости. Сега трябва да измислим проверки за всеки прост компонент. Моля, обърнете внимание, че родителският компонент „Агент“ няма да има никакви проверки, тъй като системата за наблюдение ще изчисли състоянието му независимо въз основа на състоянието на неговите дъщерни компоненти. С други думи, ако всички задачи са изпълнени успешно, тогава агентът работи успешно.
В системата ASMO има повече от сто задачи, наистина ли е необходимо да се измислят уникални проверки за всяка задача? Разбира се, контролът ще бъде по-добър, ако измислим и приложим наши собствени специални проверки за всяка задача на агента, но в повечето случаи е достатъчно да използваме универсални проверки.
Системата ASMO използва само универсални проверки за задачи и това е достатъчно, за да се следи ефективността на системата.
Проверка на напредъка
Най-простата и ефективна проверка е проверката на изпълнението. Проверката потвърждава, че задачата е изпълнена без грешки. Всички задачи имат тази проверка.
Алгоритъм за проверка
След всяко изпълнение на задача трябва да изпратите резултата от проверката SUCCESS на системата за мониторинг, ако изпълнението на задачата е било успешно, или ERROR, ако изпълнението е завършило с грешка.
Тази проверка може да открие следните проблеми:
- Задачата се изпълнява, но се проваля с грешка.
- Задачата е спряла да се изпълнява, например е замръзнала.
Нека разгледаме по-подробно как се решават тези проблеми.
Проблем 1 – Задачата се изпълнява, но се проваля с грешка
По-долу е даден случай, при който задачата се изпълнява, но се проваля между 14:00 и 16:00.
Фигурата показва, че когато дадена задача е неуспешна, незабавно се изпраща сигнал към системата за наблюдение и състоянието на съответната проверка в системата за наблюдение става аларма.
Моля, обърнете внимание, че в системата за наблюдение статусът на компонента зависи от статуса на проверка. Състоянието на алармата на проверката ще промени всички компоненти от по-високо ниво на аларма, вижте фигурата по-долу.
Проблем 2 - Задачата спря да се изпълнява (замразена)
Как системата за наблюдение ще разбере, че дадена задача е блокирана?
Резултатът от проверката има период на валидност, например 1 час. Ако измине един час и няма нов резултат от теста, системата за мониторинг ще настрои статуса на теста на аларма.
На снимката по-горе осветлението е изгасено в 14:00 часа. В 15:00 системата за наблюдение ще установи, че резултатът от теста (от 14:00) е гнил, т.к. Времето за уместност е изтекло (един час), но няма нов резултат и ще превключи проверката към състояние на аларма.
В 16:00 часа светлините бяха включени отново, програмата ще изпълни задачата и ще изпрати резултата от изпълнението на системата за мониторинг, статусът на теста отново ще бъде успешен.
Какво време за уместност на проверката трябва да използвам?
Времето за релевантност трябва да е по-голямо от периода на изпълнение на задачата. Препоръчвам да зададете времето за релевантност 2-3 пъти по-дълго от периода на изпълнение на задачата. Това е необходимо, за да се избегне получаването на фалшиви известия, когато например дадена задача отне повече време от обикновено или някой презареди програмата.
Проверка на напредъка
Системата ASMO има задача “Load Forecast”, която се опитва да изтегли нова прогноза от външен източник веднъж на час. Точното време, когато се появява нова прогноза във външната система, не е известно, но е известно, че това се случва 2 пъти на ден. Оказва се, че ако няма нова прогноза за няколко часа, това е нормално, но ако няма нова прогноза за повече от ден, значи нещо се е счупило някъде. Например, форматът на данните във външна система за прогнозиране може да се промени, поради което ASMO няма да види нова версия на прогнозата.
Алгоритъм за проверка
Задачата изпраща резултата от проверката SUCCESS към системата за мониторинг, когато успее да получи напредък (изтегляне на нова прогноза за времето). Ако няма напредък или възникне грешка, нищо не се изпраща до системата за наблюдение.
Проверката трябва да има интервал на релевантност, така че през това време да е гарантирано получаването на нов напредък.
Моля, имайте предвид, че ще научим за проблема със закъснение, тъй като системата за наблюдение изчаква да изтече срокът на валидност на последния резултат от сканирането. Следователно срокът на валидност на чека не трябва да бъде твърде дълъг.
Мониторинг на бази данни
За да контролираме базата данни в системата ASMO, извършваме следните проверки:
- Проверка на създаването на резервно копие
- Проверка на свободното дисково пространство
Проверка на създаването на резервно копие
В повечето приложения е важно да имате актуални резервни копия на база данни, така че ако сървърът се повреди, можете да разположите програмата на нов сървър.
ASMO създава резервно копие веднъж седмично и го изпраща в хранилището. Когато тази процедура приключи успешно, резултатът от проверката за успех се изпраща на системата за наблюдение. Резултатът от проверката е валиден 9 дни. Тези. За да контролирате създаването на резервни копия, се използва механизмът „проверка на напредъка“, който обсъдихме по-горе.
Проверка на свободното дисково пространство
Ако на диска няма достатъчно свободно място, базата данни няма да може да функционира правилно, така че е важно да контролирате количеството свободно пространство.
Удобно е да се използват метрики за проверка на числови параметри.
Метрика е числова променлива, чиято стойност се предава на системата за мониторинг. Системата за мониторинг проверява праговите стойности и изчислява състоянието на показателя.
По-долу има снимка на това как изглежда компонентът „База данни“ в системата за наблюдение:
Мониторинг на сървъра
За да наблюдаваме сървъра, използваме следните проверки и показатели:
1. Свободно дисково пространство
Ако дисковото пространство свърши, приложението няма да може да работи. Ние използваме 2 прагови стойности: първото ниво е ПРЕДУПРЕЖДЕНИЕ, второто ниво е АЛАРМА.
2. Средна стойност на RAM в проценти на час
Използваме средната стойност за час, защото... ние не се интересуваме от редки раси.
3. Среден процент CPU на час
Използваме средната стойност за час, защото... ние не се интересуваме от редки раси.
4. Проверка на пинг
Проверява дали сървърът е онлайн. Системата за наблюдение може да извърши тази проверка; няма нужда да пишете код.
По-долу има снимка на това как изглежда компонентът „Сървър“ в системата за наблюдение:
Мониторинг на оборудването
Ще ви кажа как се получават данните. За всяка пътна контролна точка (MPC) има задача в плановика на задачите, например „Проучване MPC M2 km 200“. Задачата получава данни от всички MPC устройства на всеки 30 минути.
Проблем с комуникационния канал
По-голямата част от оборудването се намира извън града, за предаване на данни се използва GSM мрежа, която не работи стабилно (има мрежа или я няма).
Поради честите мрежови повреди, първоначално проверката на MPC проучването в мониторинга изглеждаше така:
Стана ясно, че това не е работещ вариант, защото има много фалшиви известия за проблеми. Тогава беше решено да се използва „проверка на напредъка“ за всяко устройство, т.е. Само сигналът за успех се изпраща към системата за наблюдение, ако устройството е анкетирано без грешка. Времето за релевантност беше зададено на 5 часа.
Сега мониторингът изпраща известия за проблеми само когато устройството не може да бъде анкетирано повече от 5 часа. С голяма степен на вероятност това не са фалшиви аларми, а реални проблеми.
По-долу има снимка на това как изглежда оборудването в системата за наблюдение:
Важно!
Когато GSM мрежата спре да работи, всички MDC устройства не се анкетират. За да намалим броя на имейлите от системата за мониторинг, нашите инженери се абонират за известия за проблеми с компоненти с типа „MPC“, а не „Устройство“. Това ви позволява да получавате едно известие за всеки MPC, вместо да получавате отделно известие за всяко устройство.
Окончателна схема за мониторинг на ASMO
Нека съберем всичко и да видим каква схема за мониторинг имаме.
Заключение
Нека да обобщим.
Какво ни даде наблюдението на ефективността на ASMO?
1. Времето за отстраняване на дефекта е намаляло
По-рано сме чували за дефекти от потребители, но не всички потребители съобщават за дефекти. Случвало се е да научим за неизправност на системен компонент седмица след появата му. Сега системата за мониторинг ни уведомява за проблеми веднага щом бъде открит проблем.
2. Стабилността на системата се е увеличила
Тъй като дефектите започнаха да се отстраняват по-рано, системата като цяло започна да работи много по-стабилно.
3. Намаляване на обажданията до техническа поддръжка
Много проблеми вече са отстранени, преди потребителите дори да разберат за тях. Потребителите започнаха да се свързват по-рядко с техническата поддръжка. Всичко това се отразява добре на нашата репутация.
4. Повишаване на лоялността на клиентите и потребителите
Клиентът забеляза положителни промени в стабилността на системата. Потребителите срещат по-малко проблеми при използването на системата.
5. Намалете разходите за техническа поддръжка
Спряхме да извършваме ръчни проверки. Сега всички проверки са автоматизирани. Преди научавахме за проблеми от потребителите; често беше трудно да разберем за какъв проблем говори потребителят. Сега повечето проблеми се докладват от системата за мониторинг; известията съдържат технически данни, които винаги показват какво се е объркало и къде.
Важно!
Не можете да инсталирате системата за наблюдение на същия сървър, където се изпълняват вашите приложения. Ако сървърът падне, приложенията ще спрат да работят и няма да има кого да уведомите за това.
Системата за наблюдение трябва да работи на отделен сървър в друг център за данни.
Ако не искате да използвате специален сървър в нов център за данни, можете да използвате облачна система за наблюдение. Нашата компания използва облачната система за наблюдение Zidium, но можете да използвате всяка друга система за наблюдение. Цената на облачна система за наблюдение е по-ниска от наемането на нов сървър.
Препоръки:
- Разбийте приложенията и системите под формата на дърво от компоненти възможно най-подробно, така че ще бъде удобно да разберете къде и какво е счупено и контролът ще бъде по-пълен.
- За да проверите функционалността на даден компонент, използвайте тестове. По-добре е да използвате много прости проверки, отколкото една сложна.
- Конфигурирайте праговете на показателите от страната на системата за мониторинг, вместо да ги записвате в код. Това ще ви спести необходимостта от повторно компилиране, преконфигуриране или рестартиране на приложението.
- За персонализирани проверки използвайте време за релевантност, за да избегнете получаването на фалшиви известия, тъй като изпълнението на някои проверки отнема малко повече време от обикновено.
- Опитайте се да накарате компонентите в системата за наблюдение да светят в червено само когато определено има проблем. Ако те станат червени за нищо, тогава ще спрете да обръщате внимание на известията на системата за наблюдение, смисълът му ще бъде загубен.
Ако все още не използвате система за наблюдение, започнете! Не е толкова трудно, колкото изглежда. Насладете се на дървото със зелени съставки, което сте отгледали сами.
Късмет.
Източник: www.habr.com