Ang pang-industriya na pag-unlad ng mga sistema ng software ay nangangailangan ng malaking atensyon sa fault tolerance ng huling produkto, pati na rin ang mabilis na pagtugon sa mga pagkabigo at pagkabigo kung mangyari ang mga ito. Ang pagsubaybay, siyempre, ay nakakatulong upang tumugon sa mga pagkabigo at pagkabigo nang mas mahusay at mabilis, ngunit hindi sapat. Una, napakahirap subaybayan ang isang malaking bilang ng mga server - isang malaking bilang ng mga tao ang kailangan. Pangalawa, kailangan mong magkaroon ng isang mahusay na pag-unawa sa kung paano gumagana ang application upang mahulaan ang estado nito. Samakatuwid, kailangan namin ng maraming tao na may mahusay na pag-unawa sa mga system na aming binuo, ang kanilang pagganap at mga tampok. Ipagpalagay natin na kahit na makakita ka ng sapat na mga taong handang gawin ito, nangangailangan pa rin ng maraming oras upang sanayin sila.
Anong gagawin? Dito tumulong ang artificial intelligence. Ang artikulo ay pag-uusapan (predictive maintenance). Ang diskarte na ito ay aktibong nakakakuha ng katanyagan. Ang isang malaking bilang ng mga artikulo ay naisulat, kabilang ang sa HabrΓ©. Ginagamit ng mga malalaking kumpanya ang diskarteng ito upang mapanatili ang pagganap ng kanilang mga server. Matapos pag-aralan ang isang malaking bilang ng mga artikulo, nagpasya kaming subukan ang diskarteng ito. Ano ang nanggaling nito?
Pagpapakilala
Maaga o huli, ang binuong software system ay gagana. Mahalaga para sa gumagamit na gumagana ang system nang walang mga pagkabigo. Kung may nangyaring emerhensiya, dapat itong lutasin nang may kaunting pagkaantala.
Upang pasimplehin ang teknikal na suporta ng isang software system, lalo na kung maraming mga server, karaniwang ginagamit ang mga programa sa pagsubaybay na kumukuha ng mga sukatan mula sa isang tumatakbong software system, ginagawang posible na masuri ang kondisyon nito at tumulong na matukoy kung ano ang eksaktong sanhi ng pagkabigo. Ang prosesong ito ay tinatawag na software system monitoring.
Figure 1. Grafana monitoring interface
Ang mga sukatan ay iba't ibang indicator ng isang software system, kapaligiran ng pagpapatupad nito, o ang pisikal na computer kung saan tumatakbo ang system na may timestamp ng sandali kung kailan natanggap ang mga sukatan. Sa static na pagsusuri, ang mga sukatang ito ay tinatawag na serye ng oras. Upang subaybayan ang estado ng software system, ang mga sukatan ay ipinapakita sa anyo ng mga graph: ang oras ay nasa X axis, at ang mga halaga ay nasa kahabaan ng Y axis (Figure 1). Ilang libong sukatan ang maaaring kunin mula sa isang tumatakbong software system (mula sa bawat node). Bumubuo sila ng espasyo ng mga sukatan (multidimensional time series).
Dahil ang isang malaking bilang ng mga sukatan ay nakolekta para sa mga kumplikadong sistema ng software, ang manu-manong pagsubaybay ay nagiging isang mahirap na gawain. Upang bawasan ang dami ng data na sinusuri ng administrator, ang mga tool sa pagsubaybay ay naglalaman ng mga tool upang awtomatikong matukoy ang mga posibleng problema. Halimbawa, maaari mong i-configure ang isang trigger upang paganahin kapag ang libreng puwang sa disk ay bumaba sa ilalim ng isang tinukoy na threshold. Maaari mo ring awtomatikong masuri ang isang pagsara ng server o isang kritikal na paghina sa bilis ng serbisyo. Sa pagsasagawa, ang mga tool sa pagsubaybay ay gumagana ng isang mahusay na trabaho ng pag-detect ng mga pagkabigo na naganap na o pagtukoy ng mga simpleng sintomas ng mga pagkabigo sa hinaharap, ngunit sa pangkalahatan, ang paghula ng isang posibleng pagkabigo ay nananatiling isang mahirap na pag-crack para sa kanila. Ang hula sa pamamagitan ng manu-manong pagsusuri ng mga sukatan ay nangangailangan ng paglahok ng mga kwalipikadong espesyalista. Ito ay mababa ang pagiging produktibo. Karamihan sa mga potensyal na pagkabigo ay maaaring hindi napapansin.
Kamakailan lamang, ang tinatawag na predictive maintenance ng mga software system ay lalong naging popular sa mga malalaking kumpanya ng IT software development. Ang kakanyahan ng diskarteng ito ay upang makahanap ng mga problema na humahantong sa pagkasira ng system sa mga unang yugto, bago ito mabigo, gamit ang artificial intelligence. Ang diskarte na ito ay hindi ganap na nagbubukod ng manu-manong pagsubaybay sa system. Ito ay pantulong sa proseso ng pagsubaybay sa kabuuan.
Ang pangunahing tool para sa pagpapatupad ng predictive maintenance ay ang gawain ng paghahanap ng mga anomalya sa serye ng oras, dahil kapag may naganap na anomalya sa data ay may mataas na posibilidad na pagkatapos ng ilang oras magkakaroon ng kabiguan o kabiguan. Ang anomalya ay isang tiyak na paglihis sa pagganap ng isang software system, tulad ng pagtukoy ng pagkasira sa bilis ng pagpapatupad ng isang uri ng kahilingan o pagbaba sa average na bilang ng mga naserbisyuhan na kahilingan sa pare-parehong antas ng mga session ng kliyente.
Ang gawain ng paghahanap ng mga anomalya para sa mga sistema ng software ay may sariling mga detalye. Sa teorya, para sa bawat sistema ng software kinakailangan na bumuo o pinuhin ang mga umiiral na pamamaraan, dahil ang paghahanap para sa mga anomalya ay nakasalalay sa data kung saan ito isinasagawa, at ang data ng mga sistema ng software ay nag-iiba-iba depende sa mga tool para sa pagpapatupad ng system , hanggang sa kung saang computer ito tumatakbo.
Mga pamamaraan para sa paghahanap ng mga anomalya kapag hinuhulaan ang mga pagkabigo ng mga sistema ng software
Una sa lahat, ito ay nagkakahalaga ng pagsasabi na ang ideya ng paghula ng mga pagkabigo ay inspirasyon ng artikulo . Upang subukan ang pagiging epektibo ng diskarte na may awtomatikong paghahanap para sa mga anomalya, napili ang Web-Consolidation software system, na isa sa mga proyekto ng kumpanya ng NPO Krista. Dati, isinagawa ang manu-manong pagsubaybay para dito batay sa mga natanggap na sukatan. Dahil ang system ay medyo kumplikado, isang malaking bilang ng mga sukatan ang kinuha para dito: Mga tagapagpahiwatig ng JVM (load ng kolektor ng basura), mga tagapagpahiwatig ng OS kung saan isinasagawa ang code (virtual memory, % OS CPU load), mga tagapagpahiwatig ng network (load ng network ), ang server mismo (CPU load , memory), wildfly metrics at ang sariling sukatan ng application para sa lahat ng kritikal na subsystem.
Ang lahat ng mga sukatan ay kinuha mula sa system gamit ang graphite. Sa una, ang database ng bulong ay ginamit bilang isang karaniwang solusyon para sa grafana, ngunit habang lumalaki ang base ng kliyente, ang grapayt ay hindi na makayanan, na naubos ang kapasidad ng DC disk subsystem. Pagkatapos nito, napagpasyahan na maghanap ng mas epektibong solusyon. Ang pagpili ay ginawa pabor , na naging posible upang bawasan ang pag-load sa subsystem ng disk sa pamamagitan ng isang pagkakasunud-sunod ng magnitude at bawasan ang sinasakop na espasyo sa disk ng lima hanggang anim na beses. Nasa ibaba ang isang diagram ng mekanismo para sa pagkolekta ng mga sukatan gamit ang graphite+clickhouse (Figure 2).
Figure 2. Scheme para sa pagkolekta ng mga sukatan
Ang diagram ay kinuha mula sa panloob na dokumentasyon. Ipinapakita nito ang komunikasyon sa pagitan ng grafana (ang monitoring UI na ginagamit namin) at graphite. Ang pag-alis ng mga sukatan mula sa isang application ay ginagawa ng hiwalay na software - . Inilalagay niya ang mga ito sa graphite.
Ang sistema ng Web Consolidation ay may ilang mga tampok na lumilikha ng mga problema para sa paghula ng mga pagkabigo:
- Madalas nagbabago ang uso. Iba't ibang bersyon ang magagamit para sa software system na ito. Ang bawat isa sa kanila ay nagdadala ng mga pagbabago sa software na bahagi ng system. Alinsunod dito, sa ganitong paraan, direktang naiimpluwensyahan ng mga developer ang mga sukatan ng isang partikular na system at maaaring magdulot ng pagbabago ng trend;
- ang tampok na pagpapatupad, pati na rin ang mga layunin kung saan ginagamit ng mga kliyente ang sistemang ito, ay kadalasang nagdudulot ng mga anomalya nang walang nakaraang pagkasira;
- ang porsyento ng mga anomalya na nauugnay sa buong set ng data ay maliit (< 5%);
- Maaaring may mga gaps sa pagtanggap ng mga indicator mula sa system. Sa ilang maikling panahon, nabigo ang monitoring system na makakuha ng mga sukatan. Halimbawa, kung overloaded ang server. Ito ay kritikal para sa pagsasanay ng isang neural network. May pangangailangan na punan ang mga puwang sa synthetically;
- Ang mga kaso na may mga anomalya ay kadalasang may kaugnayan lamang para sa isang partikular na petsa/buwan/oras (seasonality). Ang sistemang ito ay may malinaw na mga regulasyon para sa paggamit nito ng mga gumagamit. Alinsunod dito, ang mga sukatan ay may kaugnayan lamang para sa isang partikular na oras. Ang sistema ay hindi maaaring gamitin nang palagian, ngunit sa ilang buwan lamang: pili depende sa taon. Lumilitaw ang mga sitwasyon kapag ang parehong gawi ng mga sukatan sa isang kaso ay maaaring humantong sa pagkabigo ng software system, ngunit hindi sa isa pa.
Upang magsimula, ang mga pamamaraan para sa pag-detect ng mga anomalya sa pagsubaybay sa data ng mga software system ay nasuri. Sa mga artikulo sa paksang ito, kapag ang porsyento ng mga anomalya ay maliit na nauugnay sa iba pang set ng data, kadalasang iminumungkahi na gumamit ng mga neural network.
Ang pangunahing lohika para sa paghahanap ng mga anomalya gamit ang data ng neural network ay ipinapakita sa Figure 3:
Figure 3. Paghahanap ng mga anomalya gamit ang isang neural network
Batay sa resulta ng pagtataya o pagpapanumbalik ng window ng kasalukuyang daloy ng mga sukatan, kinakalkula ang paglihis mula sa natanggap mula sa tumatakbong software system. Kung may malaking pagkakaiba sa pagitan ng mga sukatan na nakuha mula sa software system at sa neural network, maaari nating tapusin na ang kasalukuyang segment ng data ay maanomalya. Ang mga sumusunod na serye ng mga problema ay lumitaw para sa paggamit ng mga neural network:
- upang gumana nang tama sa streaming mode, ang data para sa pagsasanay ng mga modelo ng neural network ay dapat na kasama lamang ang "normal" na data;
- kinakailangang magkaroon ng up-to-date na modelo para sa tamang pagtuklas. Ang pagbabago ng mga trend at seasonality sa mga sukatan ay maaaring magdulot ng malaking bilang ng mga maling positibo sa modelo. Upang i-update ito, kinakailangan upang malinaw na matukoy ang oras kung kailan ang modelo ay hindi na napapanahon. Kung i-update mo ang modelo sa ibang pagkakataon o mas maaga, kung gayon, malamang, maraming maling positibo ang susunod.
Hindi rin natin dapat kalimutan ang tungkol sa paghahanap at pagpigil sa madalas na paglitaw ng mga maling positibo. Ipinapalagay na ang mga ito ay kadalasang nangyayari sa mga emergency na sitwasyon. Gayunpaman, maaari rin silang resulta ng isang error sa neural network dahil sa hindi sapat na pagsasanay. Kinakailangang bawasan ang bilang ng mga maling positibo ng modelo. Kung hindi, ang mga maling hula ay mag-aaksaya ng maraming oras ng administrator na nilayon upang suriin ang system. Maaga o huli ang administrator ay hihinto na lamang sa pagtugon sa "paranoid" na sistema ng pagsubaybay.
Paulit-ulit na neural network
Para makakita ng mga anomalya sa time series, maaari mong gamitin may LSTM memory. Ang problema lang ay magagamit lang ito para sa nahulaang serye ng oras. Sa aming kaso, hindi lahat ng sukatan ay mahuhulaan. Ang pagtatangkang ilapat ang RNN LSTM sa isang time series ay ipinapakita sa Figure 4.
Figure 4. Halimbawa ng paulit-ulit na neural network na may LSTM memory cells
Tulad ng makikita mula sa Figure 4, ang RNN LSTM ay nakayanan ang paghahanap ng mga anomalya sa panahong ito. Kung saan ang resulta ay may mataas na error sa hula (mean error), isang anomalya sa mga indicator ang aktwal na naganap. Ang paggamit ng isang RNN LSTM ay malinaw na hindi sapat, dahil naaangkop ito sa isang maliit na bilang ng mga sukatan. Maaaring gamitin bilang pantulong na paraan para sa paghahanap ng mga anomalya.
Autoencoder para sa paghula ng pagkabigo
- mahalagang isang artipisyal na neural network. Ang input layer ay encoder, ang output layer ay decoder. Ang kawalan ng lahat ng mga neural network ng ganitong uri ay hindi nila na-localize nang maayos ang mga anomalya. Napili ang isang kasabay na arkitektura ng autoencoder.
Larawan 5. Halimbawa ng pagpapatakbo ng autoencoder
Ang mga autoencode ay sinanay sa normal na data at pagkatapos ay nakahanap ng isang bagay na maanomalya sa data na ipinadala sa modelo. Kung ano lang ang kailangan mo para sa gawaing ito. Ang natitira na lang ay piliin kung aling autoencoder ang angkop para sa gawaing ito. Ang pinakasimpleng anyo ng arkitektura ng isang autoencoder ay isang pasulong, hindi bumabalik na neural network, na halos kapareho sa (multilayer perceptron, MLP), na may input layer, output layer, at isa o higit pang nakatagong layer na nagkokonekta sa kanila.
Gayunpaman, ang mga pagkakaiba sa pagitan ng mga autoencoder at MLP ay na sa isang autoencoder, ang output layer ay may parehong bilang ng mga node gaya ng input layer, at na sa halip na sanayin upang mahulaan ang isang target na halaga Y na ibinigay ng isang input X, ang autoencoder ay sinanay. upang muling buuin ang sarili nitong mga X. Samakatuwid, ang mga Autoencoder ay mga modelo ng hindi pinangangasiwaang pag-aaral.
Ang gawain ng autoencoder ay hanapin ang mga indeks ng oras r0 ... rn na tumutugma sa mga maanomalyang elemento sa input vector X. Ang epektong ito ay nakakamit sa pamamagitan ng paghahanap para sa squared error.
Figure 6. Synchronous na autoencoder
Para sa autoencoder ang napili . Mga kalamangan nito: ang kakayahang gumamit ng streaming processing mode at medyo mas maliit na bilang ng mga parameter ng neural network kumpara sa iba pang mga arkitektura.
Mekanismo para sa pagliit ng mga maling positibo
Dahil sa ang katunayan na ang iba't ibang mga abnormal na sitwasyon ay lumitaw, pati na rin ang isang posibleng sitwasyon ng hindi sapat na pagsasanay ng neural network, para sa modelo ng pagtuklas ng anomalya, napagpasyahan na kinakailangan na bumuo ng isang mekanismo para sa pagliit ng mga maling positibo. Ang mekanismong ito ay batay sa isang template base na inuri ng administrator.
(DTW algorithm, mula sa English na dynamic na time warping) ay nagbibigay-daan sa iyo na mahanap ang pinakamainam na pagsusulatan sa pagitan ng mga pagkakasunud-sunod ng oras. Unang ginamit sa speech recognition: ginagamit upang matukoy kung paano kinakatawan ng dalawang speech signal ang parehong orihinal na sinasalitang parirala. Kasunod nito, natagpuan ang aplikasyon para dito sa ibang mga lugar.
Ang pangunahing prinsipyo ng pagliit ng mga maling positibo ay ang pagkolekta ng database ng mga pamantayan sa tulong ng isang operator na nag-uuri ng mga kahina-hinalang kaso na nakita gamit ang mga neural network. Susunod, ang classified standard ay inihambing sa kaso na nakita ng system, at isang konklusyon ay ginawa tungkol sa kung ang kaso ay mali o humahantong sa isang pagkabigo. Ang DTW algorithm ay ginamit nang tumpak upang ihambing ang dalawang serye ng oras. Ang pangunahing tool sa pag-minimize ay pag-uuri pa rin. Inaasahan na pagkatapos mangolekta ng isang malaking bilang ng mga reference na kaso, ang sistema ay magsisimulang magtanong sa operator nang mas kaunti dahil sa pagkakapareho ng karamihan sa mga kaso at ang paglitaw ng mga katulad na mga kaso.
Bilang resulta, batay sa mga pamamaraan ng neural network na inilarawan sa itaas, isang pang-eksperimentong programa ang binuo upang mahulaan ang mga pagkabigo ng sistemang "Web-Consolidation". Ang layunin ng program na ito ay, gamit ang umiiral na archive ng monitoring data at impormasyon tungkol sa mga nakaraang pagkabigo, upang suriin ang kakayahan ng diskarteng ito para sa aming mga software system. Ang scheme ng programa ay ipinakita sa ibaba sa Figure 7.
Figure 7. Failure prediction scheme batay sa metric space analysis
Sa diagram, dalawang pangunahing bloke ang maaaring makilala: ang paghahanap para sa mga maanomalyang yugto ng panahon sa stream ng data ng pagsubaybay (mga sukatan) at ang mekanismo para sa pagliit ng mga maling positibo. Tandaan: Para sa mga layuning pang-eksperimento, ang data ay nakuha sa pamamagitan ng isang JDBC na koneksyon mula sa database kung saan ito ise-save ng graphite.
Ang sumusunod ay ang interface ng sistema ng pagsubaybay na nakuha bilang resulta ng pag-unlad (Figure 8).
Figure 8. Interface ng experimental monitoring system
Ipinapakita ng interface ang porsyento ng anomalya batay sa mga natanggap na sukatan. Sa aming kaso, ang resibo ay kunwa. Mayroon na kaming lahat ng data sa loob ng ilang linggo at unti-unti itong nilo-load upang suriin ang kaso ng isang anomalya na humahantong sa pagkabigo. Ipinapakita ng mas mababang status bar ang kabuuang porsyento ng anomalya ng data sa isang partikular na oras, na tinutukoy gamit ang isang autoencoder. Gayundin, ang isang hiwalay na porsyento ay ipinapakita para sa mga hinulaang sukatan, na kinakalkula ng RNN LSTM.
Isang halimbawa ng pagtuklas ng anomalya batay sa pagganap ng CPU gamit ang RNN LSTM neural network (Larawan 9).
Larawan 9. Pagtuklas ng RNN LSTM
Ang isang medyo simpleng kaso, mahalagang isang ordinaryong outlier, ngunit humahantong sa pagkabigo ng system, ay matagumpay na nakalkula gamit ang RNN LSTM. Ang tagapagpahiwatig ng anomalya sa panahong ito ay 85β95%; lahat ng higit sa 80% (natukoy ang threshold sa eksperimentong paraan) ay itinuturing na isang anomalya.
Isang halimbawa ng pagtuklas ng anomalya kapag hindi nakapag-boot ang system pagkatapos ng isang update. Ang sitwasyong ito ay nakita ng autoencoder (Larawan 10).
Figure 10. Halimbawa ng autoencoder detection
Tulad ng nakikita mo mula sa figure, ang PermGen ay natigil sa isang antas. Natagpuan ito ng autoencoder na kakaiba dahil hindi pa ito nakakita ng katulad nito dati. Dito nananatiling 100% ang anomalya hanggang sa bumalik ang system sa isang gumaganang estado. Isang anomalya ang ipinapakita para sa lahat ng sukatan. Gaya ng nabanggit kanina, hindi ma-localize ng autoencoder ang mga anomalya. Tinatawagan ang operator na gawin ang function na ito sa mga sitwasyong ito.
Konklusyon
Ang PC "Web-Consolidation" ay nasa pagbuo ng ilang taon. Ang sistema ay nasa isang medyo matatag na estado, at ang bilang ng mga naitalang insidente ay maliit. Gayunpaman, posible na makahanap ng mga anomalya na humahantong sa pagkabigo 5 - 10 minuto bago mangyari ang pagkabigo. Sa ilang mga kaso, ang abiso ng isang pagkabigo nang maaga ay makakatulong sa pag-save ng naka-iskedyul na oras na inilalaan para sa pagsasagawa ng "pagkukumpuni" na trabaho.
Batay sa mga eksperimento na isinagawa, masyadong maaga upang makagawa ng mga pangwakas na konklusyon. Sa ngayon, ang mga resulta ay magkasalungat. Sa isang banda, malinaw na ang mga algorithm batay sa mga neural network ay may kakayahang makahanap ng mga "kapaki-pakinabang" na anomalya. Sa kabilang banda, nananatili ang malaking porsyento ng mga maling positibo, at hindi lahat ng anomalya na natukoy ng isang kwalipikadong espesyalista sa isang neural network ay maaaring matukoy. Kasama sa mga disadvantage ang katotohanan na ngayon ang neural network ay nangangailangan ng pagsasanay sa isang guro para sa normal na operasyon.
Upang higit pang mabuo ang sistema ng paghula ng kabiguan at dalhin ito sa isang kasiya-siyang estado, maraming paraan ang maaaring maisip. Ito ay isang mas detalyadong pagsusuri ng mga kaso na may mga anomalya na humahantong sa kabiguan, dahil sa pagdaragdag na ito sa listahan ng mga mahahalagang sukatan na lubos na nakakaimpluwensya sa estado ng system, at ang pagtatapon ng mga hindi kailangan na hindi nakakaapekto dito. Gayundin, kung lilipat tayo sa direksyong ito, maaari tayong gumawa ng mga pagtatangka na magpakadalubhasa sa mga algorithm partikular para sa ating mga kaso na may mga anomalya na humahantong sa mga pagkabigo. May isa pang paraan. Ito ay isang pagpapabuti sa mga arkitektura ng neural network at sa gayon ay tumataas ang katumpakan ng pagtuklas na may pagbawas sa oras ng pagsasanay.
Ipinapahayag ko ang aking pasasalamat sa aking mga kasamahan na tumulong sa akin sa pagsulat at pagpapanatili ng kaugnayan ng artikulong ito: at Sergei Finogenov.
Pinagmulan: www.habr.com