Vi fortsetter vår fordypning i den fascinerende verdenen av gjette ... feilsøking med logger. I vi ble enige om betydningen av de grunnleggende begrepene og så på den overordnede strukturen til Veeam som en enkelt applikasjon med ett øye. Oppgaven for denne er å finne ut hvordan loggfiler dannes, hva slags informasjon som vises i dem og hvorfor de ser ut som de ser ut.
Hva tror du disse "loggene" er? Ifølge de fleste bør loggene til enhver applikasjon tildeles rollen som en slags allmektig enhet som mesteparten av tiden vegeterer et sted i bakgården, men i rett øyeblikk dukker opp fra ingensteds i skinnende rustning og redder alle. Det vil si at de skal inneholde alt, fra de minste feilene i hver komponent til individuelle databasetransaksjoner. Og slik at etter feilen ble det umiddelbart skrevet hvordan ellers å fikse det. Og alt dette skal få plass i et par megabyte, ikke mer. Det er bare tekst! Tekstfiler kan ikke ta titalls gigabyte, jeg hørte det et sted!
Så loggene
I den virkelige verden er logger bare et arkiv med diagnostisk informasjon. Og hva som skal lagres der, hvor man får informasjon for lagring og hvor detaljert den skal være, er opp til utviklerne selv å bestemme. Noen følger minimalismens vei ved å holde oversikt over PÅ/AV-nivået, og noen rakker flittig alt de kan nå. Selv om det også finnes et mellomalternativ med mulighet for å velge såkalt Logging Level, når du selv angir hvor detaljert informasjon du vil lagre og hvor mye ekstra diskplass du har =) VBR har forresten seks slike nivåer. Og tro meg, du vil ikke se hva som skjer med den mest detaljerte loggingen med ledig plass på disken din.
Fint. Vi skjønte omtrent hva vi ønsker å spare, men et legitimt spørsmål dukker opp: hvor får vi denne informasjonen fra? Selvfølgelig er vi en del av hendelsene for logging selv ved våre interne prosesser. Men hva skal man gjøre når det er et samspill med det ytre miljø? For ikke å skli inn i et helvete av krykker og sykler, pleier Veeam ikke å finne opp oppfinnelser som allerede er oppfunnet. Når det er en ferdig API, innebygd funksjon, bibliotek, etc., vil vi foretrekke ferdige alternativer før vi begynner å gjerde innretningene våre. Selv om det siste også er nok. Derfor, når du analyserer logger, er det viktig å forstå at brorparten av feilene faller på meldinger fra tredjeparts APIer, systemanrop og andre biblioteker. I dette tilfellet kommer rollen til VBR ned på å videresende disse feilene til as is-loggfilene. Og hovedoppgaven til brukeren er å lære å forstå hvilken linje som er fra hvem, og hva denne "hvem" er ansvarlig for. Så hvis en feilkode fra VBR-loggen tar deg til en MSDN-side, er det greit og riktig.
Som vi ble enige om tidligere: Veeam er en såkalt SQL-basert applikasjon. Dette betyr at alle innstillinger, all informasjon og generelt alt som bare er nødvendig for normal funksjon - alt er lagret i databasen. Derav den enkle sannheten: det som ikke er i loggene er mest sannsynlig i databasen. Men dette er heller ikke en sølvkule: noen ting er ikke i de lokale loggene til Veeam-komponenter, og heller ikke i databasen. Derfor må du lære hvordan du studerer vertsloggene, loggene til den lokale maskinen og loggene for alt som er involvert i sikkerhetskopierings- og gjenopprettingsprosessen. Og det hender også at nødvendig informasjon ikke er tilgjengelig noe sted i det hele tatt. Det er veien.
Noen eksempler på slike APIer
Denne listen har ikke som mål å være eksepsjonelt komplett, så det er ikke nødvendig å lete etter den ultimate sannheten i den. Hensikten er kun å vise de vanligste tredjeparts APIene og teknologiene som brukes i produktene våre.
La oss begynne med VMware.
Først på listen blir vSphere API. Brukes til autentisering, lese hierarkiet, lage og slette øyeblikksbilder, be om informasjon om maskiner og mye (svært mye) mer. Funksjonaliteten til løsningen er veldig bred, så jeg kan anbefale VMware vSphere API Reference for versjonen и . For mer aktuelle versjoner er alt bare googlet.
VIX API. Den svarte magien til hypervisor, som det er en egen . VMware API for å jobbe med filer på verten uten å koble til dem over nettverket. En variant av siste utvei når du skal legge en fil i en maskin som det ikke finnes en bedre kommunikasjonskanal til. Det er smerte og lidelse hvis filen er stor og verten er lastet. Men her fungerer regelen at selv 56,6 Kb/s er bedre enn 0 Kb/s. I Hyper-V kalles denne tingen PowerShell Direct. Men det var bare før
vSpehere Web Services API Fra og med vSphere 6.0 (omtrent siden denne API-en først ble introdusert på versjon 5.5) brukes den til å jobbe med gjestemaskiner og har erstattet VIX nesten overalt. Faktisk er dette et annet API for å administrere vSphere. For de som er interessert anbefaler jeg å studere Håndbok.
VDDK (Virtual Disk Development Kit). Biblioteket, som ble delvis omtalt i denne . Brukes til å lese virtuelle disker. Det var en gang en del av VIX, men med tiden ble det flyttet inn i et eget produkt. Men som arving bruker den de samme feilkodene som VIX. Men av en eller annen grunn er det ingen beskrivelse av disse feilene i selve SDK-en. Derfor ble det empirisk funnet ut at VDDK-feil med andre koder bare er en oversettelse fra binær til desimalkode. Den består av to deler - den første halvdelen er udokumentert informasjon om konteksten, og den andre delen er de tradisjonelle VIX / VDDK-feilene. Hvis vi for eksempel ser:
VDDK error: 21036749815809.Unknown error
Så konverterer vi dette til hex og får 132200000001. Vi forkaster ganske enkelt den uinformative begynnelsen av 132200, og resten vil være feilkoden vår (VDDK 1: Ukjent feil). Om de hyppigste VDDK-feilene var det nylig en separat .
La oss se på Vinduer.
Her finner du alt som er mest nødvendig og viktig for oss i standarden event Viewer. Men det er en hake: I følge en lang tradisjon logger ikke Windows hele feilteksten, men bare nummeret. For eksempel er feil 5 "Access denied", og 1722 er "RPC-serveren er utilgjengelig", og 10060 er "Tidsavbrudd for tilkoblingen". Det er selvfølgelig flott om du husker de mest kjente, men hva med hittil usett?
Og for at livet ikke skal virke som honning i det hele tatt, lagres feil også i heksadesimal form, med prefikset 0x8007. For eksempel er 0x8007000e faktisk 14, tom for minne. Hvorfor og for hvem dette ble gjort er et mysterium innhyllet i mørke. En komplett liste over feil kan imidlertid lastes ned gratis og uten SMS fra .
Forresten, noen ganger er det andre prefikser, ikke bare 0x8007. I en så trist situasjon, for å forstå HRESULT ("resultathåndtak"), må du gå enda dypere inn i for utviklere. I det vanlige livet anbefaler jeg deg ikke å gjøre dette, men hvis du plutselig presset deg mot veggen eller bare er nysgjerrig, vet du nå hva du skal gjøre.
Men kameratene i Microsoft forbarmet seg litt over oss og viste verden en nytte . Dette er et lite stykke konsolllykke som kan oversette feilkoder til mennesker uten å bruke Google. Det fungerer slik.
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ørsmål oppstår: hvorfor skriver vi ikke umiddelbart dekrypteringen til loggene, men lar disse mystiske kodene ligge? Svaret er i tredjepartsapplikasjoner. Når du trekker et WinAPI-kall selv, er det ikke vanskelig å tyde svaret, for det er til og med et spesielt WinAPI-kall for dette. Men som allerede nevnt, kommer alt som bare kommer til oss i svar inn i loggene våre. Og her, for å dekryptere det, må man hele tiden overvåke denne bevissthetsstrømmen, trekke ut biter med Windows-feil fra den, dekryptere dem og lime dem tilbake. La oss være ærlige, ikke den mest spennende aktiviteten.
Windows File Management API brukes på alle mulige måter når du arbeider med filer. Opprette filer, slette, åpne for skriving, arbeide med attributter og så videre og så videre.
nevnt ovenfor PowerShell Direct som en analog av VIX API i Hyper-V-verdenen. Dessverre ikke så fleksibelt: mange begrensninger på funksjonalitet, det fungerer ikke med alle versjoner av verten og ikke med alle gjester.
RPC (Remote Procedure Call) Jeg tror ikke det er en eneste person som har jobbet med Windows som ikke har sett RPC-relaterte feil. Til tross for den populære misforståelsen, er dette ikke en enkelt protokoll, men enhver klient-server-protokoll som tilfredsstiller en rekke parametere. Men hvis det er en RPC-feil i loggene våre, vil det 90 % av tiden være en feil fra Microsoft RPC, som er en del av DCOM (Distributed Component Object Model). Du kan finne en enorm mengde dokumentasjon om dette emnet på nettet, men brorparten av det er ganske utdatert. Men hvis det er et akutt ønske om å studere emnet, kan jeg anbefale artikler , og lang liste .
Hovedårsakene til RPC-feil i loggene våre er mislykkede forsøk på å kommunisere mellom VBR-komponenter (server > proxy, for eksempel) og oftest på grunn av kommunikasjonsproblemer.
Den øverste toppen blant alle toppene er feilen RPC-serveren er utilgjengelig (1722). Enkelt sagt, klienten kunne ikke opprette en forbindelse med serveren. Hvordan og hvorfor - det finnes ikke et enkelt svar, men vanligvis er det et problem med autentisering eller med nettverkstilgang til port 135. Sistnevnte er typisk for infrastrukturer med dynamisk porttilordning. På dette emnet er det enda . Og det har Microsoft for å finne årsaken til feilen.
Den nest mest populære feilen: Det er ikke flere endepunkter tilgjengelig fra endepunktskartleggingen (1753). RPC-klienten eller serveren klarte ikke å tilordne seg selv en port. Oppstår vanligvis når serveren (i vårt tilfelle gjestemaskinen) er konfigurert til å dynamisk tildele porter fra et smalt område som er avsluttet. Og hvis du logger inn fra klientsiden (i vårt tilfelle VBR-serveren), betyr dette at vår VeeamVssAgent enten ikke startet eller ikke var registrert som et RPC-grensesnitt. Det er også om dette emnet .
Vel, for å fullføre de 3 beste RPC-feilene, la oss huske at RPC-funksjonskallet mislyktes (1726). Vises hvis tilkoblingen er opprettet, men RPC-forespørsler ikke behandles. For eksempel ber vi om informasjon om statusen til VSS (plutselig akkurat nå blir det laget en skyggegruve der, og vi prøver å klatre), og som svar på oss, stille og ignorere.
Windows Tape Backup API nødvendig for å jobbe med båndbiblioteker eller stasjoner. Som jeg nevnte i begynnelsen: vi har ingen glede av å skrive våre egne drivere og deretter lide med støtte fra hver enhet. Derfor har vim ingen egne drivere. Alt gjennom en standard API, som støttes av maskinvareleverandørene selv. Så mye mer logisk, ikke sant?
SMB / CIFS Av vane skriver alle dem side om side, selv om ikke alle husker at CIFS (Common Internet File System) bare er en privat versjon av SMB (Server Message Block). Så det er ikke noe galt med å generalisere disse begrepene. Samba er allerede en LinuxUnix-implementering, og den har sine egne særegenheter, men jeg avviker. Hva er viktig her: når Veeam ber om å skrive noe til UNC-banen (serverkatalog), bruker serveren hierarkiet av filsystemdrivere, inkludert mup og mrxsmb, for å skrive til ballen. Følgelig vil disse driverne også generere feil.
Klarer meg ikke uten Winsock API. Hvis noe må gjøres over nettverket, fungerer VBR gjennom Windows Socket API, populært kjent som Winsock. Så hvis vi ser en haug med IP:Port i loggen, er dette det. Den offisielle dokumentasjonen har en god liste over mulige .
nevnt ovenfor WMI (Windows Management Instrumentation) er en slags allmektig API for å administrere alt og alle i Windows-verdenen. For eksempel, når du arbeider med Hyper-V, går nesten alle forespørsler til verten gjennom den. Med et ord, tingen er absolutt uerstattelig og veldig kraftig i sine evner. I et forsøk på å finne ut hvor og hva som er ødelagt, hjelper det innebygde WBEMtest.exe-verktøyet mye.
Og sist på listen, men på ingen måte minst viktig - VSS (Volum Shadow Storage). Temaet er like uuttømmelig og mystisk som det er skrevet mye dokumentasjon om det. Shadow Copy forstås enklest som en spesiell type øyeblikksbilde, som det i hovedsak er. Takket være ham kan du lage applikasjonskonsistente sikkerhetskopier i VMware, og nesten alt i Hyper-V. Jeg har planer om å lage en egen artikkel med litt klem på VSS, men foreløpig kan du prøve å lese . Bare vær forsiktig, fordi. prøver å forstå VSS på et blunk kan føre til hjerneskade.
På dette kan vi kanskje stoppe. Jeg anser oppgaven med å forklare de mest grunnleggende tingene som fullført, så i neste kapittel skal vi allerede se på loggene. Men hvis du har spørsmål, spør dem gjerne i kommentarfeltet.
Kilde: www.habr.com