Vi fortsætter vores fordybelse i den fascinerende verden af gætte ... fejlfinding ved hjælp af logfiler. I vi blev enige om betydningen af de grundlæggende udtryk og så på Veeams overordnede struktur som en enkelt applikation med ét øje. Opgaven for denne er at finde ud af, hvordan logfiler er dannet, hvilken slags information der vises i dem, og hvorfor de ser ud, som de ser ud.
Hvad tror du, disse "logfiler" er? Ifølge de fleste bør logfilerne for enhver applikation tildeles rollen som en slags almægtig entitet, der det meste af tiden vegeterer et sted i baghaven, men i det rigtige øjeblik dukker op ud af ingenting i skinnende rustning og redder alle. Det vil sige, at de skal indeholde alt fra de mindste fejl i hver komponent til individuelle databasetransaktioner. Og så der efter fejlen straks blev skrevet, hvordan man ellers skulle rette det. Og alt dette burde passe i et par megabyte, ikke mere. Det er bare tekst! Tekstfiler kan ikke tage snesevis af gigabyte, jeg hørte det et sted!
Så logfilerne
I den virkelige verden er logfiler kun et arkiv med diagnostisk information. Og hvad man skal gemme der, hvor man får information til opbevaring og hvor detaljeret den skal være, er op til udviklerne selv at bestemme. Nogen følger minimalismens vej ved at føre optegnelser over ON/OFF-niveauet, og nogen river flittigt alt, hvad de kan nå. Selvom der også er en mellemmulighed med mulighed for at vælge det såkaldte Logging Level, når du selv angiver, hvor detaljeret information du vil gemme og hvor meget ekstra diskplads du har =) VBR har i øvrigt seks sådanne niveauer. Og tro mig, du ønsker ikke at se, hvad der sker med den mest detaljerede logning med ledig plads på din disk.
Bøde. Vi forstod nogenlunde, hvad vi vil gemme, men et legitimt spørgsmål opstår: hvor skal man få disse oplysninger fra? Vi indgår naturligvis i begivenhederne for logning af os selv ved vores interne processer. Men hvad skal man gøre, når der er et samspil med det ydre miljø? For ikke at glide ind i et helvede af krykker og cykler, har Veeam en tendens til ikke at opfinde opfindelser, der allerede er opfundet. Når der er en færdiglavet API, indbygget funktion, bibliotek osv., vil vi give fortrinsret til færdige muligheder, før vi begynder at indhegne vores udstyr. Selvom det sidste også er nok. Når du analyserer logfiler, er det derfor vigtigt at forstå, at størstedelen af fejlene falder på meddelelser fra tredjeparts API'er, systemkald og andre biblioteker. I dette tilfælde kommer VBR's rolle til at videresende disse fejl til as is-logfilerne. Og brugerens hovedopgave er at lære at forstå, hvilken linje der er fra hvem, og hvad denne "hvem" er ansvarlig for. Så hvis en fejlkode fra VBR-loggen fører dig til en MSDN-side, er det fint og korrekt.
Som vi aftalte tidligere: Veeam er en såkaldt SQL-baseret applikation. Det betyder, at alle indstillinger, alle informationer og i det hele taget alt, hvad der kun er nødvendigt for normal funktion - alt er gemt i dens database. Derfor den simple sandhed: Hvad der ikke er i logfilerne, er højst sandsynligt i databasen. Men dette er heller ikke en sølvkugle: nogle ting er ikke i de lokale logfiler for Veeam-komponenter eller i dens database. Derfor skal du lære, hvordan du studerer værtslogfilerne, logfilerne på den lokale maskine og logfilerne for alt, hvad der er involveret i backup- og gendannelsesprocessen. Og det sker også, at den nødvendige information slet ikke er tilgængelig nogen steder. Det er vejen.
Nogle eksempler på sådanne API'er
Denne liste sigter ikke efter at være usædvanlig komplet, så der er ingen grund til at lede efter den ultimative sandhed i den. Dens formål er kun at vise de mest almindelige tredjeparts API'er og teknologier, der bruges i vores produkter.
Lad os begynde med VMware.
Først på listen bliver vSphere API. Bruges til godkendelse, læsning af hierarkiet, oprettelse og sletning af snapshots, anmodning om information om maskiner og meget (meget) mere. Løsningens funktionalitet er meget bred, så jeg kan anbefale VMware vSphere API Reference til versionen и . For mere aktuelle versioner er alt bare googlet.
VIX API. Den sorte magi af hypervisor, som der er en separat . VMware API til at arbejde med filer på værten uden at oprette forbindelse til dem over netværket. En sidste udvej mulighed, når du skal lægge en fil i en maskine, som der ikke er en bedre kommunikationskanal til. Det er smerte og lidelse, hvis filen er stor, og værten er indlæst. Men her virker reglen, at selv 56,6 Kb/s er bedre end 0 Kb/s. I Hyper-V kaldes denne ting PowerShell Direct. Men det var kun før
vSpehere Web Services API Fra vSphere 6.0 (cirka siden denne API blev introduceret i version 5.5) bruges den til at arbejde med gæstemaskiner og har fortrængt VIX næsten overalt. Faktisk er dette en anden API til at administrere vSphere. For dem, der er interesserede, anbefaler jeg at studere brugervejledning.
VDDK (Virtual Disk Development Kit). Biblioteket, som blev delvist omtalt i denne . Bruges til at læse virtuelle diske. Engang var det en del af VIX, men med tiden blev det flyttet til et separat produkt. Men som arving bruger den de samme fejlkoder som VIX. Men af en eller anden grund er der ingen beskrivelse af disse fejl i selve SDK'et. Derfor blev det empirisk fundet ud af, at VDDK-fejl med andre koder blot er en oversættelse fra binær til decimalkode. Den består af to dele - den første halvdel er udokumenteret information om konteksten, og den anden del er de traditionelle VIX / VDDK fejl. For eksempel, hvis vi ser:
VDDK error: 21036749815809.Unknown error
Så konverterer vi dristigt dette til hex og får 132200000001. Vi kasserer simpelthen den uinformative begyndelse af 132200, og resten vil være vores fejlkode (VDDK 1: Ukendt fejl). Om de hyppigste VDDK-fejl var der for nylig en separat .
Lad os nu se på Windows.
Her kan alt, hvad der er mest nødvendigt og vigtigt for os, findes i standarden Logbog. Men der er en hake: ifølge en lang tradition logger Windows ikke hele fejlteksten, men kun nummeret. For eksempel er fejl 5 "Adgang nægtet", og 1722 er "RPC-serveren er utilgængelig", og 10060 er "Forbindelse timeout". Det er selvfølgelig fantastisk, hvis du husker de mest kendte, men hvad med hidtil usete?
Og for at livet slet ikke skal virke som honning, gemmes fejl også i hexadecimal form med præfikset 0x8007. For eksempel er 0x8007000e faktisk 14, der mangler hukommelse. Hvorfor og for hvem dette blev gjort, er et mysterium indhyllet i mørke. En komplet liste over fejl kan dog downloades gratis og uden SMS fra .
Forresten, nogle gange er der andre præfikser, ikke kun 0x8007. I sådan en trist situation, for at forstå HRESULT ("resultathåndtag"), er du nødt til at dykke endnu dybere ned i for udviklere. I det almindelige liv råder jeg dig ikke til at gøre dette, men hvis du pludselig pressede dig mod væggen eller bare er nysgerrig, ved du nu, hvad du skal gøre.
Men kammeraterne hos Microsoft forbarmede sig lidt over os og viste verden en nytte . Dette er et lille stykke konsollykke, der kan oversætte fejlkoder til mennesker uden at bruge Google. Det fungerer sådan her.
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"Et legitimt spørgsmål opstår: hvorfor skriver vi ikke straks dekrypteringen til logfilerne, men efterlader disse mystiske koder? Svaret er i tredjepartsapplikationer. Når du selv trækker et WinAPI-kald, er det ikke svært at tyde dets svar, for der er endda et særligt WinAPI-kald til dette. Men som allerede nævnt, kommer alt, hvad der kun kommer til os i svar, ind i vores logfiler. Og her, for at dekryptere det, skulle man konstant overvåge denne strøm af bevidsthed, trække stykker med Windows-fejl ud fra den, dekryptere dem og indsætte dem tilbage. Lad os være ærlige, ikke den mest spændende aktivitet.
Windows File Management API bruges på alle mulige måder, når du arbejder med filer. Oprette filer, slette, åbne for skrivning, arbejde med attributter og så videre og så videre.
nævnt ovenfor PowerShell Direct som en analog til VIX API i Hyper-V-verdenen. Desværre ikke så fleksibel: mange begrænsninger på funktionalitet, det virker ikke med alle versioner af værten og ikke med alle gæster.
RPC (Remote Procedure Call) Jeg tror ikke, der er en eneste person, der har arbejdet med Windows, som ikke har set RPC-relaterede fejl. På trods af den populære misforståelse er dette ikke en enkelt protokol, men enhver klient-server protokol, der opfylder en række parametre. Men hvis der er en RPC-fejl i vores logfiler, vil det 90 % af tiden være en fejl fra Microsoft RPC, som er en del af DCOM (Distributed Component Object Model). Du kan finde en enorm mængde dokumentation om dette emne på nettet, men broderparten af den er ret forældet. Men hvis der er et akut ønske om at studere emnet, så kan jeg anbefale artikler , og lang liste .
Hovedårsagerne til RPC-fejl i vores logfiler er mislykkede forsøg på at kommunikere mellem VBR-komponenter (f.eks. server > proxy) og oftest på grund af kommunikationsproblemer.
Den øverste top blandt alle toppe er fejlen RPC-serveren er ikke tilgængelig (1722). Kort sagt kunne klienten ikke etablere en forbindelse med serveren. Hvordan og hvorfor - der er ikke et enkelt svar, men normalt er det et problem med autentificering eller med netværksadgang til port 135. Sidstnævnte er typisk for infrastrukturer med dynamisk porttildeling. Om dette emne er der endda . Og det har Microsoft at finde årsagen til fejlen.
Næstmest populære fejl: Der er ikke flere endepunkter tilgængelige fra endepunktsmapperen (1753). RPC-klienten eller serveren kunne ikke tildele sig selv en port. Opstår normalt, når serveren (i vores tilfælde gæstemaskinen) er blevet konfigureret til dynamisk at allokere porte fra et snævert område, der er afsluttet. Og hvis du logger ind fra klientsiden (i vores tilfælde VBR-serveren), betyder det, at vores VeeamVssAgent enten ikke startede eller ikke var registreret som et RPC-interface. Der er også om dette emne .
Nå, for at fuldføre de 3 bedste RPC-fejl, lad os huske, at RPC-funktionskaldet mislykkedes (1726). Vises, hvis forbindelsen er etableret, men RPC-anmodninger ikke behandles. For eksempel anmoder vi om oplysninger om status for VSS (pludselig lige nu bliver der lavet en skyggemine der, og vi forsøger at klatre), og som svar på os, tavs og ignorer.
Windows Tape Backup API nødvendige for at arbejde med båndbiblioteker eller drev. Som jeg nævnte i begyndelsen: vi har ingen fornøjelse af at skrive vores egne drivere og derefter lide med støtte fra hver enhed. Derfor har vim ingen egne drivere. Alt sammen gennem en standard API, hvis support implementeres af hardwareleverandørerne selv. Så meget mere logisk, ikke?
SMB / CIFS Af vane skriver alle dem side om side, selvom ikke alle husker, at CIFS (Common Internet File System) blot er en privat version af SMB (Server Message Block). Så der er ikke noget galt med at generalisere disse begreber. Samba er allerede en LinuxUnix-implementering, og den har sine egne ejendommeligheder, men jeg afviger. Hvad er vigtigt her: Når Veeam beder om at skrive noget til UNC-stien (serverdirectory), bruger serveren hierarkiet af filsystemdrivere, inklusive mup og mrxsmb, til at skrive til bolden. Følgelig vil disse drivere også generere fejl.
Kan ikke undvære Winsock API. Hvis noget skal gøres over netværket, fungerer VBR gennem Windows Socket API, populært kendt som Winsock. Så hvis vi ser en masse IP:Port i loggen, er dette det. Den officielle dokumentation har en god liste over mulige .
nævnt ovenfor WMI (Windows Management Instrumentation) er en slags almægtig API til at styre alt og alle i Windows-verdenen. For eksempel, når du arbejder med Hyper-V, går næsten alle anmodninger til værten igennem det. Med et ord, tingen er absolut uerstattelig og meget kraftfuld i sine muligheder. I et forsøg på at hjælpe med at finde ud af, hvor og hvad der er brudt, hjælper det indbyggede WBEMtest.exe-værktøj meget.
Og sidst på listen, men på ingen måde mindst i betydning - VSS (Volume Shadow Storage). Emnet er lige så uudtømmeligt og mystisk, som der er skrevet meget dokumentation om det. Shadow Copy forstås enklest som en speciel type snapshot, hvilket det i bund og grund er. Takket være ham kan du lave applikationskonsistente sikkerhedskopier i VMware og næsten alt i Hyper-V. Jeg har planer om at lave en separat artikel med lidt klem på VSS, men indtil videre kan du prøve at læse . Bare vær forsigtig, fordi. forsøg på at forstå VSS lynhurtigt kan føre til hjerneskade.
På dette kan vi måske stoppe. Jeg betragter opgaven med at forklare de mest basale ting som afsluttet, så i næste kapitel vil vi allerede se på loggene. Men hvis du har spørgsmål, er du velkommen til at stille dem i kommentarerne.
Kilde: www.habr.com