Industria evoluo de softvarsistemoj postulas grandan atenton al la faŭltoleremo de la fina produkto, same kiel rapidan respondon al fiaskoj kaj fiaskoj se ili okazas. Monitorado, kompreneble, helpas respondi al misfunkciadoj kaj malsukcesoj pli efike kaj rapide, sed ne sufiĉe. Unue, estas tre malfacile konservi trakon de granda nombro da serviloj - necesas granda nombro da homoj. Due, vi devas bone kompreni kiel funkcias la aplikaĵo por antaŭdiri ĝian staton. Tial ni bezonas multajn homojn, kiuj bone komprenas la sistemojn, kiujn ni disvolvas, ilia agado kaj funkcioj. Ni supozu, ke eĉ se vi trovas sufiĉe da homoj pretaj fari tion, necesas ankoraŭ multe da tempo por trejni ilin.
Kion fari? Jen kie artefarita inteligenteco venas al nia helpo. Pri la artikolo parolos (antaŭvida prizorgado). Ĉi tiu aliro aktive akiras popularecon. Granda nombro da artikoloj estis verkitaj, inkluzive pri Habré. Grandaj kompanioj plene uzas ĉi tiun aliron por konservi la agadon de siaj serviloj. Post studado de granda nombro da artikoloj, ni decidis provi ĉi tiun aliron. Kio venis el ĝi?
Enkonduko
La evoluinta softvarsistemo baldaŭ aŭ malfrue ekfunkcias. Gravas por la uzanto, ke la sistemo funkcias sen misfunkciadoj. Se krizo okazas, ĝi devus esti solvita kun minimuma prokrasto.
Por simpligi teknikan subtenon de programara sistemo, precipe se ekzistas multaj serviloj, oni kutime uzas monitorajn programojn, kiuj prenas metrikojn de funkcianta programara sistemo, ebligas diagnozi ĝian kondiĉon kaj helpas determini, kio ĝuste kaŭzis la fiaskon. Ĉi tiu procezo nomiĝas monitorado de programaro.
Figuro 1. Grafana monitora interfaco
Metriko estas diversaj indikiloj de softvarsistemo, ĝia ekzekutmedio, aŭ la fizika komputilo sub kiu la sistemo funkcias kun tempomarko de la momento kiam la metrikoj estis ricevitaj. En senmova analizo, ĉi tiuj metrikoj estas nomitaj temposerio. Por kontroli la staton de la programara sistemo, metrikoj estas montrataj en formo de grafikaĵoj: tempo estas sur la X-akso, kaj valoroj estas laŭ la Y-akso (Figuro 1). Plurmil metrikoj povas esti prenitaj de funkcianta softvarsistemo (de ĉiu nodo). Ili formas spacon de metriko (plurdimensia temposerio).
Ĉar granda nombro da metrikoj estas kolektitaj por kompleksaj programaj sistemoj, mana monitorado fariĝas malfacila tasko. Por redukti la kvanton de datumoj analizitaj de la administranto, monitoraj iloj enhavas ilojn por aŭtomate identigi eblajn problemojn. Ekzemple, vi povas agordi ellasilon por ekfunkciigi kiam libera diskospaco falas sub difinitan sojlon. Vi ankaŭ povas aŭtomate diagnozi servilhalton aŭ kritikan malrapidiĝon en servorapideco. Praktike, monitoraj iloj faras bonan laboron por detekti misfunkciojn kiuj jam okazis aŭ identigi simplajn simptomojn de estontaj fiaskoj, sed ĝenerale, antaŭdiri eblan fiaskon restas malfacila nukso por fendi por ili. Antaŭdiro per mana analizo de metrikoj postulas la implikiĝon de kvalifikitaj specialistoj. Ĝi estas malalta produktiveco. Plej multaj eblaj fiaskoj povas pasi nerimarkitaj.
Lastatempe, la tiel nomata prognoza prizorgado de programaraj sistemoj fariĝis ĉiam pli populara inter grandaj kompanioj pri programaro pri IT. La esenco de ĉi tiu aliro estas trovi problemojn kondukantajn al sistemo-degenero en la fruaj stadioj, antaŭ ol ĝi malsukcesas, uzante artefaritan inteligentecon. Ĉi tiu aliro ne tute ekskludas manan monitoradon de la sistemo. Ĝi estas helpa al la monitorada procezo kiel tutaĵo.
La ĉefa ilo por efektivigi prognozan prizorgadon estas la tasko serĉi anomaliojn en temposerio, ekde tiam kiam okazas anomalio en la datumoj estas alta probablo ke post iom da tempo estos malsukceso aŭ malsukceso. Anomalio estas certa devio en la agado de softvarsistemo, kiel ekzemple identigado de degenero en la ekzekutrapideco de unu speco de peto aŭ malkresko en la meza nombro da servitaj petoj ĉe konstanta nivelo de klientsesioj.
La tasko serĉi anomaliojn por programaj sistemoj havas siajn proprajn specifaĵojn. En teorio, por ĉiu programara sistemo necesas evoluigi aŭ rafini ekzistantajn metodojn, ĉar la serĉado de anomalioj tre dependas de la datumoj en kiuj ĝi estas farita, kaj la datumoj de programaraj sistemoj multe varias depende de la iloj por efektivigi la sistemon. , ĝis sur kiu komputilo ĝi funkcias.
Metodoj por serĉi anomaliojn dum antaŭdiro de fiaskoj de softvarsistemoj
Antaŭ ĉio, indas diri, ke la ideo antaŭdiri fiaskojn estis inspirita de la artikolo . Por testi la efikecon de la aliro kun aŭtomata serĉo de anomalioj, oni elektis la programaran sistemon Web-Consolidation, kiu estas unu el la projektoj de la kompanio NPO Krista. Antaŭe, mana monitorado estis farita por ĝi surbaze de la ricevitaj metrikoj. Ĉar la sistemo estas sufiĉe kompleksa, granda nombro da metrikoj estas prenitaj por ĝi: JVM-indikiloj (rubaĵkolektisto-ŝarĝo), indikiloj de la OS sub kiu la kodo estas ekzekutita (virtuala memoro, % OS CPU-ŝarĝo), retaj indikiloj (retoŝarĝo). ), la servilo mem (CPU-ŝarĝo, memoro), wildfly-metriko kaj la propra metriko de la aplikaĵo por ĉiuj kritikaj subsistemoj.
Ĉiuj metrikoj estas prenitaj de la sistemo uzante grafiton. Komence, la flustrodatumbazo estis utiligita kiel norma solvo por grafana, sed ĉar la klientbazo kreskis, grafito ne plu povis elteni, elĉerpinte la kapaciton de la DC-diska subsistemo. Post ĉi tio, oni decidis trovi pli efikan solvon. La elekto estis farita en favoro , kiu ebligis malpliigi la ŝarĝon sur la disksubsistemo je grandordo kaj redukti la okupatan diskspacon je kvin ĝis ses fojojn. Malsupre estas diagramo de la mekanismo por kolektado de metrikoj uzante grafito+clickhouse (Figuro 2).
Figuro 2. Skemo por kolektado de metrikoj
La diagramo estas prenita el interna dokumentaro. Ĝi montras la komunikadon inter grafana (la monitora UI, kiun ni uzas) kaj grafito. Forigo de metrikoj de aplikaĵo estas farita per aparta programaro - . Li metas ilin en grafiton.
La Web Consolidation-sistemo havas kelkajn funkciojn, kiuj kreas problemojn por antaŭdiri fiaskojn:
- La tendenco ofte ŝanĝiĝas. Diversaj versioj estas disponeblaj por ĉi tiu programara sistemo. Ĉiu el ili alportas ŝanĝojn al la programaro de la sistemo. Sekve, tiamaniere, programistoj rekte influas la metrikojn de donita sistemo kaj povas kaŭzi tendencan ŝanĝon;
- la efektiviga trajto, same kiel la celoj por kiuj klientoj uzas ĉi tiun sistemon, ofte kaŭzas anomaliojn sen antaŭa degenero;
- la procento de anomalioj relative al la tuta datumaro estas malgranda (< 5%);
- Povas esti mankoj en ricevado de indikiloj de la sistemo. En kelkaj mallongaj tempodaŭroj, la monitora sistemo ne sukcesas akiri metrikojn. Ekzemple, se la servilo estas troŝarĝita. Ĉi tio estas kritika por trejnado de neŭrala reto. Estas neceso plenigi la mankojn sinteze;
- Kazoj kun anomalioj ofte rilatas nur por specifa dato/monato/tempo (sezoneco). Ĉi tiu sistemo havas klarajn regularojn por sia uzo de uzantoj. Sekve, la metrikoj estas gravaj nur por specifa tempo. La sistemo ne povas esti uzata konstante, sed nur en kelkaj monatoj: selekteme depende de la jaro. Situacioj ekestas kiam la sama konduto de metrikoj en unu kazo povas konduki al fiasko de la programara sistemo, sed ne en alia.
Komence, metodoj por detekti anomaliojn en monitorado de datumoj de softvarsistemoj estis analizitaj. En artikoloj pri ĉi tiu temo, kiam la procento de anomalioj estas malgranda rilate al la resto de la datumaro, plej ofte estas proponite uzi neŭralaj retoj.
La baza logiko por serĉi anomaliojn uzante neŭralajn datumojn estas montrita en Figuro 3:
Figuro 3. Serĉado de anomalioj uzante neŭralan reton
Surbaze de la rezulto de la prognozo aŭ restarigo de la fenestro de la nuna fluo de metriko, la devio de tio ricevita de la kuranta programaro estas kalkulita. Se estas granda diferenco inter la metrikoj akiritaj de la programara sistemo kaj la neŭrala reto, ni povas konkludi, ke la nuna datumsegmento estas anomalia. La sekva serio de problemoj ekestas por la uzo de neŭralaj retoj:
- por funkcii ĝuste en fluanta reĝimo, la datumoj por trejnado de neŭralaj retaj modeloj devas inkluzivi nur "normalajn" datumojn;
- necesas havi ĝisdatigitan modelon por ĝusta detekto. Ŝanĝantaj tendencoj kaj sezoneco en metrikoj povas kaŭzi grandan nombron da falsaj pozitivoj en la modelo. Por ĝisdatigi ĝin, necesas klare determini la tempon, kiam la modelo estas malaktuala. Se vi ĝisdatigas la modelon poste aŭ pli frue, tiam, plej verŝajne, sekvos granda nombro da falsaj pozitivoj.
Ni ankaŭ ne devas forgesi pri serĉado kaj preventado de la ofta apero de falsaj pozitivoj. Oni supozas, ke ili plej ofte okazos en krizaj situacioj. Tamen, ili ankaŭ povas esti sekvo de neŭrala reto-eraro pro nesufiĉa trejnado. Necesas minimumigi la nombron da falsaj pozitivoj de la modelo. Alie, malveraj antaŭdiroj malŝparos multan administran tempon celitan kontroli la sistemon. Pli aŭ malpli frue la administranto simple ĉesos respondi al la "paranoja" monitora sistemo.
Ripetiĝanta neŭrala reto
Por detekti anomaliojn en temposerio, vi povas uzi kun LSTM-memoro. La nura problemo estas, ke ĝi povas esti uzata nur por antaŭviditaj temposerio. En nia kazo, ne ĉiuj metrikoj estas antaŭvideblaj. Provo apliki RNN LSTM al temposerio estas montrita en Figuro 4.
Figuro 4. Ekzemplo de ripetiĝanta neŭrala reto kun LSTM-memorĉeloj
Kiel povas esti vidita de Figuro 4, RNN LSTM povis trakti la serĉon de anomalioj en ĉi tiu tempoperiodo. Kie la rezulto havas altan prognozan eraron (averaĝan eraron), anomalio en la indikiloj efektive okazis. Uzi ununuran RNN LSTM klare ne sufiĉos, ĉar ĝi aplikeblas al malgranda nombro da metrikoj. Povas esti uzata kiel helpa metodo por serĉi anomaliojn.
Aŭtomata kodilo por malsukcesa prognozo
– esence artefarita neŭrala reto. La eniga tavolo estas kodilo, la eligotavolo estas malĉifrilo. La malavantaĝo de ĉiuj neŭralaj retoj de ĉi tiu tipo estas ke ili ne bone lokalizas anomaliojn. Sinkrona aŭtokodila arkitekturo estis elektita.
Figuro 5. Ekzemplo de operacio de aŭtokodilo
Aŭtokodigiloj estas trejnitaj sur normalaj datumoj kaj tiam trovas ion nenormalan en la datumoj provizitaj al la modelo. Ĝuste kion vi bezonas por ĉi tiu tasko. Restas nur elekti, kiu aŭtokodilo taŭgas por ĉi tiu tasko. La arkitekture plej simpla formo de aŭtokodilo estas antaŭen, nerevenanta neŭrala reto, kiu estas tre simila al (plurtavola perceptron, MLP), kun enirtavolo, produktaĵtavolo, kaj unu aŭ pluraj kaŝitaj tavoloj ligantaj ilin.
Tamen, la diferencoj inter aŭtokodiloj kaj MLPoj estas ke en aŭtokodilo, la produktaĵtavolo havas la saman nombron da nodoj kiel la enirtavolo, kaj ke anstataŭe de esti trejnita por antaŭdiri celvaloron Y donitan per enigaĵo X, la aŭtokodilo estas trejnita. por rekonstrui siajn proprajn Xs. Tial, Aŭtokodigiloj estas nekontrolitaj lernmodeloj.
La tasko de la aŭtokodilo estas trovi la tempajn indeksojn r0 ... rn respondajn al la anomaliaj elementoj en la eniga vektoro X. Ĉi tiu efiko estas atingita serĉante la kvadratan eraron.
Figuro 6. Sinkrona aŭtokodilo
Por la aŭtokodilo estis elektita . Ĝiaj avantaĝoj: la kapablo uzi fluantan pretigreĝimon kaj relative pli malgrandan nombron da neŭralaj retaj parametroj kompare kun aliaj arkitekturoj.
Mekanismo por minimumigi falsajn pozitivojn
Pro la fakto, ke aperas diversaj nenormalaj situacioj, kaj ankaŭ ebla situacio de nesufiĉa trejnado de la neŭrala reto, por la evoluiga modelo de detektado de anomalioj, oni decidis, ke necesas evoluigi mekanismon por minimumigi falsajn pozitivojn. Ĉi tiu mekanismo baziĝas sur ŝablona bazo, kiu estas klasifikita de la administranto.
(DTW-algoritmo, el la angla dynamic time warping) permesas trovi la optimuman korespondadon inter temposinsekvoj. Unue uzite en parolrekono: uzita por determini kiel du parolsignaloj reprezentas la saman originan parolitan frazon. Poste, aplikiĝo estis trovita por ĝi en aliaj areoj.
La ĉefa principo por minimumigi falsajn pozitivojn estas kolekti datumbazon de normoj kun la helpo de operatoro, kiu klasifikas suspektindajn kazojn detektitajn per neŭralaj retoj. Poste, la klasigita normo estas komparata kun la kazo kiun la sistemo detektis, kaj konkludo estas farita pri ĉu la kazo estas malvera aŭ kondukanta al fiasko. La DTW-algoritmo estas uzata ĝuste por kompari du temposerion. La ĉefa minimumiga ilo daŭre estas klasifiko. Estas atendite, ke post kolektado de granda nombro da referencaj kazoj, la sistemo komencos peti la operatoron malpli pro la simileco de plej multaj kazoj kaj la okazo de similaj.
Kiel rezulto, surbaze de la neŭralaj retaj metodoj priskribitaj supre, eksperimenta programo estis konstruita por antaŭdiri fiaskojn de la "Web-Consolidation" sistemo. La celo de ĉi tiu programo estis, uzante la ekzistantan arkivon de monitoraj datumoj kaj informoj pri antaŭaj fiaskoj, taksi la kompetentecon de ĉi tiu aliro por niaj programaj sistemoj. La skemo de la programo estas prezentita sube en Figuro 7.
Figuro 7. Malsukcesa prognozoskemo bazita sur metrika spaca analizo
En la diagramo, du ĉefaj blokoj povas esti distingitaj: la serĉo de nenormalaj tempodaŭroj en la monitora datumfluo (metriko) kaj la mekanismo por minimumigi falsajn pozitivojn. Notu: Por eksperimentaj celoj, la datumoj estas akiritaj per JDBC-konekto de la datumbazo en kiu grafito konservos ĝin.
La sekva estas la interfaco de la monitora sistemo akirita kiel rezulto de evoluo (Figuro 8).
Figuro 8. Interfaco de la eksperimenta monitora sistemo
La interfaco montras la procenton de anomalio bazita sur la ricevitaj metrikoj. En nia kazo, la kvitanco estas simulita. Ni jam havas ĉiujn datumojn dum pluraj semajnoj kaj ŝarĝas ĝin iom post iom por kontroli la kazon de anomalio kondukanta al fiasko. La pli malalta statusbreto montras la totalan procenton de datuma anomalio en antaŭfiksita tempo, kiu estas determinita per aŭtokodilo. Ankaŭ, aparta procento estas montrata por la antaŭviditaj metrikoj, kiu estas kalkulita de la RNN LSTM.
Ekzemplo de anomalia detekto bazita sur CPU-efikeco uzante la neŭralan reton RNN LSTM (Figuro 9).
Figuro 9. RNN LSTM-malkovro
Sufiĉe simpla kazo, esence ordinara eksterordinara, sed kondukanta al sistema fiasko, estis sukcese kalkulita uzante RNN LSTM. La anomaliindikilo en tiu tempodaŭro estas 85-95%; ĉio super 80% (la sojlo estis determinita eksperimente) estas konsiderita anomalio.
Ekzemplo de anomalia detekto kiam la sistemo ne povis starti post ĝisdatigo. Ĉi tiu situacio estas detektita de la aŭtokodilo (Figuro 10).
Figuro 10. Ekzemplo de aŭtokodilo-detekto
Kiel vi povas vidi de la figuro, PermGen estas blokita je unu nivelo. La aŭtokodilo trovis tion stranga ĉar ĝi neniam antaŭe vidis ion similan. Ĉi tie la anomalio restas 100% ĝis la sistemo revenas al funkcia stato. Anomalio estas montrata por ĉiuj metrikoj. Kiel menciite antaŭe, la aŭtokodilo ne povas lokalizi anomaliojn. La funkciigisto estas vokita por plenumi ĉi tiun funkcion en ĉi tiuj situacioj.
konkludo
Komputilo "Web-Consolidation" estas evoluinta dum pluraj jaroj. La sistemo estas en sufiĉe stabila stato, kaj la nombro da registritaj okazaĵoj estas malgranda. Tamen, estis eble trovi anomaliojn kondukantajn al fiasko 5 - 10 minutojn antaŭ ol la fiasko okazis. En iuj kazoj, sciigo pri malsukceso anticipe helpus ŝpari la planitan tempon, kiu estas asignita por plenumi "riparajn" laborojn.
Surbaze de la eksperimentoj kiuj estis faritaj, estas tro frue por eltiri finajn konkludojn. Ĝis nun, la rezultoj estas konfliktaj. Unuflanke, estas klare, ke algoritmoj bazitaj sur neŭralaj retoj kapablas trovi "utilajn" anomaliojn. Aliflanke, restas granda procento de falsaj pozitivoj, kaj ne ĉiuj anomalioj detektitaj de kvalifikita specialisto en neŭrala reto povas esti detektitaj. La malavantaĝoj inkluzivas la fakton, ke nun la neŭrala reto postulas trejnadon kun instruisto por normala funkciado.
Por plue evoluigi la malsukcesan prognozosistemon kaj alporti ĝin al kontentiga stato, pluraj manieroj povas esti antaŭviditaj. Ĉi tio estas pli detala analizo de kazoj kun anomalioj, kiuj kondukas al fiasko, pro ĉi tiu aldono al la listo de gravaj metrikoj, kiuj multe influas la staton de la sistemo, kaj la forĵeto de nenecesaj, kiuj ne influas ĝin. Ankaŭ, se ni moviĝas en ĉi tiu direkto, ni povas fari provojn specialigi algoritmojn specife por niaj kazoj kun anomalioj kiuj kondukas al fiaskoj. Estas alia maniero. Ĉi tio estas plibonigo en neŭralaj retaj arkitekturoj kaj tiel pliigas detektoprecizecon kun redukto de trejna tempo.
Mi esprimas mian dankon al miaj kolegoj, kiuj helpis min skribi kaj konservi la gravecon de ĉi tiu artikolo: kaj Sergej Finogenov.
fonto: www.habr.com