Көптеген заманауи Java қосымшалары бөлінген және өзара тәуелді компоненттердің күрделі жиынтығын, сонымен қатар динамикалық құрылымды қамтиды. Сондықтан қолданбаның өнімділігі мен қолжетімділігі көптеген сыртқы факторларға ықтимал тәуелді болады. Тікелей эфирге шықпас бұрын сынақ ортасында мұндай тәуелділіктерді жоққа шығару немесе дәл модельдеу мүмкін емес. Сонымен, қолданба жұмыс істеп тұрғанда, барлық тосын сыйлар орын алуы мүмкін. Дегенмен, қолданбаңыз іске қосылған ортаны жан-жақты бақылау үшін жүйені құру және қолдау арқылы әсерді азайтып, қажетсіз оқиғалардың ұзақтығын қысқартуға болады.
Бұл үш мақаладан тұратын топтамада мұндай жүйені енгізудің кейбір принциптері мен тәсілдері талқыланады. Принциптердің өзі, сондай-ақ қолданылатын кейбір терминологиялар жалпы сипатта болады. Код мысалдарымен және иллюстрациялармен біріктірілген олар қолданба өнімділігін бақылауды тұжырымдамалауға көмектеседі. Мұндай сурет берілген мәселені шешу қажеттілігін көрсетеді және осы шешімді таңдауға көмектеседі (коммерциялық, ашық бастапқы код немесе бар жүйені кеңейту) немесе әсіресе ынталы оқырмандар үшін оны әзірлеуге нұсқаулық бола алады.
Бірінші бөлімде:
қолданбалы өнімділікті басқару жүйелерінің қасиеттері туралы әңгімелейді (Application Performance Management Systems — APM);
қолданбалы мониторингтің жалпы, бірақ қалаусыз тәсілдерін сипаттайды;
Java виртуалды машиналарының (JVM) өнімділігін бақылау әдістерін сипаттайды;
Қолданбаның бастапқы кодын тиімді құралдармен қамтамасыз ету опцияларын ұсынады
Екінші бөлімде бастапқы кодқа өзгертулер енгізбестен Java сыныптары мен қолданбалы ресурстарды құралдау әдістеріне назар аударылады. Үшінші бөлімде JVM-ден тыс орналастырылған бақылау ресурстары, соның ішінде негізгі компьютерлер мен олардың операциялық жүйелері, сондай-ақ дерекқорлар мен хабар алмасу жүйелері сияқты қашықтағы қызметтер қарастырылады. Мақаланың соңғы бөлігінде деректерді басқару және визуализация, есеп беру және сигнал беру сияқты ARM-ге қатысты қосымша аспектілер талқыланады.
Басында
APM енгізудің жалпы жетістіктері мен сәтсіздіктері
Болашақта шатастырмау үшін бірден айта кетейік, Java-ға қатысты материалдардың көпшілігі код пен қолданба өнімділігін профильдеуге ұқсас болғанымен, бұл мақаланың негізгі тақырыбы емес. Профильдеу Java кодының ауқымды, жылдам, тиімді және барлық жағынан мінсіз екеніне көз жеткізу (немесе сенімді емес) үшін қолдану алдындағы маңызды процесс болып табылады. Дегенмен, қолданбаны орналастырғаннан кейін кез келген нәрсе болуы мүмкін, сондықтан әзірлеу кезеңінде жұмыс істеген профиль жасаушының ешбір кепілдігі өндіріс кезеңінде мүмкін болатын мәселелерден қорғай алмайды.
Бұл мақаланың тақырыбы — өндіріс фазасында профильдеудің кейбір аспектілерін жүзеге асыру, сондай-ақ қолданбаны орындау кезінде нақты уақыттағы деректерді және ол тәуелді болатын барлық сыртқы компоненттерді жинау. Бұл деректер тұтас жүйе күйінің егжей-тегжейлі бейнесін қалыптастыру үшін құрамдастардың кең ауқымын қамтитын сандық өлшеу нәтижелерінің сериясы болып табылады. Бұған қоса, мұндай өлшемдердің тарихын сақтау арқылы ортаның қалыпты жұмыс істеп тұрғаны туралы қорытынды жасауға көмектесетін немесе нақты мәселелердің себебі мен дәрежесін көрсететін нақты жүйенің негізгі көрсеткіштерін алуға болады.
Мониторингтің жалпы кемшіліктері
Сирек қолданбада бақылау құралдары мүлде жоқ. Алайда, іс жүзінде келесі кемшіліктер жиі кездеседі:
Фрагменттелген мониторинг мәселелері
Жүйенің бірде-бір көрінісі аяқталмаған кезде пайда болатын мониторинг сейілтілген мониторинг деп аталады. Ең шатастыратын және диагностикасы қиын мәселелер, әдетте, бірнеше өзара байланысты компоненттерді қамтитын жағдайларда пайда болады. Қарапайым иллюстрация ретінде Java қолданбасының серверінде орналастырылған жүйені елестетіңіз, ол (сервер иелеріне белгісіз) барлық ашық қосылымдарды босатпайтын проблемалы JDBC қосылымын біріктіру сыныбын қамтиды.
Бақылау жүйесінен деректерді талдай отырып, қолданба иелері сервер жағынан 100 дерекқор қосылымдары ашық екенін көреді. Өз кезегінде, деректер қорының әкімшісі (DBA) басқару консолі арқылы осы компьютердің жағынан 120 қосылым ашық екенін және олардың саны тез өсіп келе жатқанын көреді. Біріктірілген APM жүйесі үшін осы суреттердің екеуін де салу қиын болмауы керек. Қосылымдар саны туралы деректер алшақтай бастаған кезде, графикке қарайтын кез келген адам, біріншіден, индикатордың қай мәні дұрыс екенін бірден түсінуі керек, екіншіден, себебі туралы жеткілікті дәл түсінік алуы керек. мәселенің.
Өлі аймақтар: қолданба тәуелді кейбір құрамдас бөліктер бақыланбайды немесе бақылау деректері қол жетімді емес. Мысалы, бақылау қолжетімді желіде емес, дерекқорда орындалуы мүмкін. Бұл жағдайда желідегі үзілістерді анықтау қиын болуы мүмкін, себебі ақауларды жоюшылар дерекқор өнімділігін және қолданба серверінің белгілерін зерттеумен айналысады.
Қара жәшіктер: қолданбаның өзі немесе сыртқы құрамдастардың бірі оның ішкі процестерін бақылауға мүмкіндік бермейді. JVM осындай қара жәшіктің мысалы болып табылады. Мысалы, операциялық жүйе статистикасын (процессор жүктемесі немесе процесс жадын пайдалану) қамтамасыз ететін JVM ішіндегі түсініксіз кідірісті зерттейтін адамдар қоқыс жинау немесе ағынды синхрондау мәселелерін анықтауда қиындықтарға тап болуы мүмкін.
Үйлесімсіз немесе ажыратылған бақылау жүйелері: Қолданба дерекқорлар, жоғары жылдамдықты сақтау аймағы желілері (SAN), сондай-ақ хабар алмасу жүйелері және әртүрлі аралық бағдарламалық қамтамасыз ету сияқты көптеген ортақ ресурстарға қол жеткізе отырып, үлкен деректер орталығының ішінде жұмыс істей алады. Сонымен қатар, компаниялар жиі күрделі құрылымға ие болады, онда әр топ өзінің жеке бақылау жүйелерін және APM пайдаланады («Фрагменттелген мониторинг мәселелері» ескертпесін қараңыз). Егер сіз сыртқы құрамдастардың әрқайсысының біріктірілген көрінісін бермесеңіз, онда әрбір топ қолданбаның жалпы суретінің шағын фрагментіне ғана қол жеткізе алады.