Wy geane troch mei ús ûnderdompeling yn 'e fassinearjende wrâld fan fortune telling ... troubleshooting fia logs. YN Wy binne it iens oer de betsjutting fan 'e basisbegripen en hawwe rap sjoen nei de algemiene struktuer fan Veeam as ien applikaasje. De taak hjirfoar is om te begripen hoe't logtriemmen wurde foarme, hokker soarte ynformaasje deryn wurdt werjûn en wêrom't se derút sjogge sa't se dogge.
Wat tinke jo dat dizze "logs" dochs binne? Neffens de mearderheid moatte de logs fan elke applikaasje de rol wurde tawiisd fan in soarte fan almachtige entiteit dy't meastentiids earne op 'e eftergrûn vegetearret, mar op it juste momint út it neat ferskynt yn glânzjend harnas en elkenien rêdt. Dat is, se moatte alles befetsje, fan 'e minste flaters yn elke komponint oant yndividuele databanktransaksjes. En sa dat der nei in flater daliks skreaun wurdt hoe't it oars kin reparearje. En dit alles moat passe yn in pear megabytes, net mear. It is gewoan tekst! Tekstbestannen kinne gjin tsientallen gigabytes opnimme, dat hearde ik earne!
Dus, de logs
Yn 'e echte wrâld binne logs gewoan in argyf fan diagnostyske ynformaasje. En wat te bewarjen dêr, wêr te krijen de ynformaasje foar opslach en hoe detaillearre it moat wêze, is oan de ûntwikkelders sels te besluten. Guon minsken folgje it paad fan minimalisme, bewarje records op it ON / OFF-nivo, wylst oaren foarsichtich alles oppakke wêr't se har hannen op kinne krije. Hoewol't der ek in tuskenlizzende opsje mei de mooglikheid om te selektearjen de saneamde Logging Level, as jo sels oanjaan hoe detaillearre ynformaasje jo wolle opslaan en hoefolle ekstra skiif romte jo hawwe =) VBR hat seis sokke nivo, troch de wei. En leau my, jo wolle net sjen wat der bart mei de meast detaillearre logging mei de frije romte op jo skiif.
Moai. Wy begripe rûchwei wat wy wolle bewarje, mar in legitime fraach ûntstiet: wêr te krijen dizze ynformaasje út? Guon fan 'e barrens foar logging wurde fansels troch ús sels generearre fia ús ynterne prosessen. Mar wat te dwaan as der ynteraksje is mei de eksterne omjouwing? Om net yn in folsleine hel fan krukken en fytsen del te fallen, hat Veeam de neiging om gjin útfinings út te finen dy't al útfûn binne. Wannear't der in klearmakke API, funksje, biblioteek, ensfh yn it systeem ynboud is, sille wy de foarkar jaan oan klearmakke opsjes foardat wy begjinne mei it bouwen fan ús eigen tûke oplossingen. Hoewol't de lêste binne ek genôch. Dêrom, by it analysearjen fan logs, is it wichtich om te begripen dat it liuwendiel fan flaters komt fan berjochten fan API's fan tredden, systeemoproppen en oare biblioteken. Yn dit gefal wurdt de rol fan VBR fermindere om dizze flaters troch te stjoeren nei de logtriemmen lykas is. En de wichtichste taak fan de brûker is om te learen om te begripen hokker line is fan wa, en wat dizze "wa" is ferantwurdlik foar. Dêrom, as de flaterkoade fan it VBR-log jo nei de MSDN-side liedt, is dit normaal en korrekt.
Lykas wy earder ôfpraat hawwe: Veeam is in saneamde SQL-basearre applikaasje. Dit betsjut dat alle ynstellings, alle ynformaasje en, yn it algemien, alles dat nedich is foar normaal funksjonearjen - alles wurdt opslein yn syn databank. Dêrfandinne de ienfâldige wierheid: wat net yn 'e logs stiet is it meast wierskynlik yn' e databank. Mar dit is gjin sulveren kûgel: guon dingen binne net yn 'e lokale logs fan Veeam-komponinten of yn har databank. Dêrom moatte jo leare hoe't jo host-logs, lokale masine-logs, en logs yn 't algemien kinne studearje fan alles dat belutsen is by it backup- en restauraasjeproses. En it komt ek foar dat de nedige ynformaasje hielendal net beskikber is. Dit is de wei.
Ferskate foarbylden fan sokke APIs
Dizze list is net fan doel om útsûnderlik kompleet te wêzen, dus it is net nedich om de ultime wierheid yn te sykjen. It doel dêrfan is allinich om de meast foarkommende API's en technologyen fan tredden te sjen dy't brûkt wurde yn ús produkten.
Lit ús begjinne Omrop.
Earst op 'e list sil wêze vSphere API. Wurdt brûkt foar autentikaasje, it lêzen fan hierargy, it meitsjen en wiskjen fan snapshots, it oanfreegjen fan ynformaasje oer masines en folle (hiel folle) mear. De funksjonaliteit fan de oplossing is hiel breed, dus ik kin riede VMware vSphere API Reference foar ferzje и . Foar mear aktuele ferzjes, Google gewoan alles.
VIX API. Swarte magy fan de hypervisor, dêr't der in apart . VMware API foar wurkjen mei triemmen op de host sûnder ferbining mei harren oer it netwurk. In opsje fan lêste ynstânsje, as jo in bestân yn in masine moatte pleatse dy't net berikber is troch in better kommunikaasjekanaal. Stelt pine en lijen foar as it bestân grut is en de host dwaande is. Mar de regel hjir is dat sels 56,6 Kb/s better is as 0 Kb/s. Yn Hyper-V wurdt in ferlykber ding PowerShell Direct neamd. Mar dat wie allinnich oant de ferskining
vSpehere Web Services API Begjinnend mei vSphere 6.0 (sawat, sûnt dizze API waard earst yntrodusearre yn ferzje 5.5) wurdt brûkt om te wurkjen mei gast masines en hat al ferfongen VIX hast oeral. Yn essinsje is dit in oare API foar it behearen fan vSphere. Ik kin belangstellenden advisearje om te studearjen hantlieding
VDDK (Virtual Disk Development Kit). De bibleteek, dêr't foar in part yn besprutsen waard . Wurdt brûkt om firtuele skiven te lêzen. Eartiids wie it diel fan 'e VIX, mar nei ferrin fan tiid waard it makke yn in apart produkt. Mar as erfgenamt brûkt it deselde flater koades as VIX. Mar om ien of oare reden is d'r gjin beskriuwing fan dizze flaters yn 'e SDK sels. Dêrom waard eksperiminteel fûn dat VDDK-flaters mei oare koades gewoan in oersetting binne fan binêre nei desimale koade. Bestiet út twa dielen - de earste helte is net dokumintearre kontekstynformaasje, en de twadde helte is tradisjonele VIX / VDDK-flaters. Bygelyks, as wy sjogge:
VDDK error: 21036749815809.Unknown error
Dan konvertearje wy dit frijmoedich nei hex en krije 132200000001. Wy ferwiderje gewoan it ûnynformative begjin 132200, en de rest sil ús flaterkoade wêze (VDDK 1: Unbekende flater). D'r wie koartlyn in apart artikel oer de meast foarkommende VDDK-flaters. .
No litte wy sjen nei Windows.
Hjir binne alle needsaaklike en wichtige dingen foar ús te finen yn 'e standert Event Viewer. Mar d'r is ien fangen: neffens in lange tradysje logt Windows net de folsleine tekst fan 'e flater, mar allinich it nûmer. Bygelyks, flater 5 is "Tagong wegere", en 1722 is "De RPC-tsjinner is net beskikber", en 10060 is "Ferbining time-out". Fansels is it geweldich as jo de meast ferneamde ûnthâlde, mar wat oer de oant no ta net sjoen?
En sadat it libben net folslein miserabel liket, wurde flaters ek opslein yn heksadesimale foarm, mei it foarheaksel 0x8007. Bygelyks, 0x8007000e is eins 14, Out of Memory. Wêrom en foar wa't dit dien is, is in mystearje yn tsjuster omhuld. De folsleine list mei flaters kin lykwols fergees downloade wurde en sûnder SMS fan .
Trouwens, soms binne d'r oare foarheaksels, net allinich 0x8007. Yn sa'n tryste situaasje moatte jo om HRESULT ("resultaathandtak") te begripen noch djipper yngean foar ûntwikkelders. Yn it gewoane libben ried ik jo net oan om dit te dwaan, mar as jo ynienen tsjin 'e muorre drukke fine of gewoan nijsgjirrich binne, wite jo no wat te dwaan.
Mar ús kameraden by Microsoft namen meilijen oer ús en lieten de wrâld in nut sjen . Dit is in lyts stikje konsole-gelok dat flaterkoades kin oersette yn minsklike sûnder Google te brûken. It wurket sa'n ding.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"In legitime fraach ûntstiet: wêrom skriuwe wy net fuortendaliks in ûntsifering yn 'e logs, mar litte dizze mysterieuze koades? It antwurd is yn applikaasjes fan tredden. As jo sels in WinAPI-oprop meitsje, is it net dreech om syn antwurd te ûntsiferjen, om't d'r sels in spesjale WinAPI-oprop foar is. Mar sa't al neamd, alles dat komt nei ús yn antwurden einiget yn ús logs. En hjir, om te ûntsiferjen, soe men dizze stream fan bewustwêzen hieltyd yn 'e gaten hâlde moatte, der mei Windows-flaters stikken út lûke, se ûntsiferje en weromsette. Litte wy earlik wêze, it is net de meast spannende aktiviteit.
Windows File Management API brûkt op alle mooglike manieren by it wurkjen mei triemmen. Bestannen oanmeitsje, wiskje, iepenje foar skriuwen, wurkje mei attributen, ensfh., ensfh.
Sa as hjirboppe neamd PowerShell Direct as analoog fan 'e VIX API yn' e Hyper-V wrâld. Spitigernôch is it net sa fleksibel: d'r binne in protte beheiningen op funksjonaliteit, it wurket net mei elke ferzje fan 'e host en net mei alle gasten.
CPR (Remote Proseduere Call) Ik tink dat der net ien persoan dy't hat wurke mei WIndows dy't hat net sjoen flaters ferbûn mei RPC. Nettsjinsteande de populêre misfetting is dit net ien protokol, mar elk client-tsjinner protokol dat foldocht oan in oantal parameters. As d'r lykwols in RPC-flater is yn ús logs, sil 90% fan 'e tiid in flater wêze fan Microsoft RPC, dy't diel is fan DCOM (Distributed Component Object Model). Jo kinne fine in enoarme hoemannichte dokumintaasje oer dit ûnderwerp op it ynternet, mar it liuw syn oandiel is frij ferâldere. Mar as jo in sterke winsk hawwe om it ûnderwerp te studearjen, kin ik artikels oanbefelje , en in lange list .
De wichtichste redenen foar RPC-flaters yn ús logs binne mislearre besykjen om te kommunisearjen tusken VBR-komponinten (server> proxy, bygelyks) en meastentiids troch kommunikaasjeproblemen.
De boppeste top ûnder alle toppen is de flater De RPC-tsjinner is net beskikber (1722). Om it gewoan te sizzen, koe de kliïnt gjin ferbining meitsje mei de tsjinner. Der is gjin inkeld antwurd op hoe en wêrom, mar it is meastal in probleem mei autentikaasje of netwurk tagong ta haven 135. Dat lêste is typysk foar ynfrastruktuer mei dynamyske haven opdrachten. Der is sels in tried oer dit ûnderwerp . En by Microsoft - om de oarsaken fan de funksje te finen.
De twadde meast populêre flater: D'r binne gjin einpunten mear beskikber fan 'e einpuntmapper (1753). De RPC-kliïnt of tsjinner koe gjin poarte oan himsels tawize. Typysk bart as de tsjinner (yn ús gefal de gastmasine) is konfigurearre om dynamysk havens te allocearjen fan in smel berik dat út is. En as wy ynlogge fan 'e kliïntside (yn ús gefal, de VBR-tsjinner), betsjut dit dat ús VeeamVssAgent of net begon of net registrearre wie as in RPC-ynterface. Der is ek in tried oer dit ûnderwerp .
No, om de Top 3 RPC-flaters te foltôgjen, lit ús ûnthâlde dat RPC-funksjeoprop mislearre (1726). Ferskynt as de ferbining is oprjochte, mar RPC-oanfragen wurde net ferwurke. Bygelyks, wy freegje ynformaasje oer de status fan VSS (ynienen is der in skaadmyn geande dêr rjochts no, en wy besykje te klimmen), en as antwurd krije wy stilte en ûnwittendheid.
Windows Tape Reservekopy API nedich om te wurkjen mei tapebiblioteken of driuwfearren. Lykas ik oan it begjin neamde: wy hawwe gjin wille om ús eigen sjauffeurs te skriuwen en dan wrakselje mei it stypjen fan elk apparaat. Dêrom hat Vim gjin eigen bestjoerders. Alles wurdt dien fia in standert API, stipe troch de hardwareferkeapers sels. Dat it is folle logysker, krekt?
SMB / CIFS Elkenien skriuwt se njonken inoar út gewoante, hoewol net elkenien ûnthâldt dat CIFS (Common Internet File System) gewoan in privee ferzje is fan SMB (Server Message Block). Der is dus neat mis mei it generalisearjen fan dizze begripen. Samba is al in LinuxUnix ymplemintaasje, en it hat syn eigen eigenaardichheden, mar ik digress. Wat hjir wichtich is: as Veeam freget om wat te skriuwen nei in UNC-paad (serverdirectory), brûkt de tsjinner in hiërargy fan triemsysteembestjoerders, ynklusyf mup en mrxsmb, om nei it diel te skriuwen. Dêrtroch sille dizze bestjoerders ek flaters generearje.
It is ûnmooglik om te dwaan sûnder Winsock API. As der wat dien wurde moat oer it netwurk, wurket VBR fia de Windows Socket API, populêr bekend as Winsock. Dus as wy de IP:Port-keppeling yn it log sjogge, is dit it. De offisjele dokumintaasje hat in goede list fan mooglike .
Sa as hjirboppe neamd WMI (Windows Management Instrumentation) is in soarte fan almachtige API foar it behearen fan alles en elkenien yn 'e Windows-wrâld. Bygelyks, by it wurkjen mei Hyper-V, komme hast alle oanfragen nei de host dêrtroch. Yn ien wurd, it ding is folslein ûnferfangber en tige machtich yn syn mooglikheden. As jo besykje te helpen út te finen wêr't en wat is brutsen, is it ynboude ark WBEMtest.exe tige behelpsum.
En as lêste op 'e list, mar wis net it minste yn belang - VSS (Volume Shadow Storage). In ûnderwerp is like ûnútputlik en mysterieus as der in protte dokumintaasje oer skreaun is. Shadow Copy wurdt it maklikst begrepen as in spesjale soarte snapshot, dat is wat it yn wêzen is. Mei tank oan it kinne jo applikaasje-konsistente backups meitsje yn VMware, en hast alles yn Hyper-V. Ik haw plannen om in apart artikel te meitsjen mei wat gearfetting oer VSS, mar foar no kinne jo besykje te lêzen . Wês gewoan foarsichtich, want ... Besykje te begripen VSS yn ien kear kin liede ta harsens blessueres.
Miskien kinne wy hjir stopje. Ik beskôgje de taak om de meast basale dingen te ferklearjen foltôge, dus yn it folgjende haadstik sille wy nei de logs sjen. Mar as jo fragen hawwe, aarzel dan net om se yn 'e kommentaren te stimmen.
Boarne: www.habr.com