Hvor kommer loggene fra? Veeam Log Diving

Vi fortsetter vår reise inn i den fascinerende verdenen av feilsøking gjennom logger. I den forrige artikkelen har vi blitt enige om betydningen av grunnleggende begreper og fått et kort blikk på hovedstrukturen til Veeam som en helhetlig applikasjon. Oppgaven for denne gangen er å finne ut hvordan loggfilene dannes, hvilken informasjon de inneholder, og hvorfor de ser ut som de gjør.

Hva tenker du egentlig at disse «loggene» er? I følge mange skal logger for enhver applikasjon spille rollen som en allmektig entitet som stort sett tilbringer tiden et sted i bakgrunnen, men i et kritisk øyeblikk dukker opp fra ingenting i strålende rustning og redder alle. Det vil si at de bør inneholde alt fra de minste feilene i hver komponent til separate transaksjoner i databasen. Og etter en feil skal det straks skrives hvordan den kan rettes. Alt dette må få plass i et par megabyte, ikke mer. Det er jo bare tekst! Tekstfiler kan ikke ta opp titalls gigabyte, jeg har hørt noe om det!

Så, logger

I den virkelige verden er logger kun et arkiv av diagnostisk informasjon. Og hva som skal lagres, hvor informasjonen skal hentes fra for lagring, og hvor detaljert den skal være, må besluttes av utviklerne selv. Noen følger minimalistisk tilnærming, og lagrer bare på- og av-poster, mens andre flittig samler alt de kan komme over. Det finnes også en mellomløsning der du kan velge såkalt Logging Level, hvor du selv angir hvor detaljert informasjonen skal være, basert på hvor mye ledig plass du har på diskene =) VBR tilbyr faktisk hele seks nivåer av logger, bare så det er sagt. Og tro meg, du vil ikke se hva som skjer ved det mest detaljerte loggføringen med lite ledig plass på disken din.

Greit. Vi har forstått omtrent hva vi ønsker å lagre, men det reises et legitimt spørsmål: hvor skal vi hente denne informasjonen fra? En del hendelser for logging genererer vi selvsagt selv gjennom våre interne prosesser. Men hva gjør vi når det skjer en interaksjon med det eksterne miljøet? For å unngå å skli ned i et kaos av midlertidige løsninger og omveier, har Veeam en tendens til ikke å oppfinne allerede oppfunnede løsninger. Når det finnes et eksisterende API, en innebygd funksjon i systemet, et bibliotek osv., vil vi gi fordel til de ferdige alternativene før vi begynner å lage våre egne smarte løsninger. Selv om det også finnes mange av dem. Derfor er det viktig å forstå at størsteparten av feilene stammer fra meldinger fra tredjeparts API-er, systemkall og andre biblioteker. I dette tilfellet er rollen til VBR å videresende disse feilene til loggfiler som de er. Hovedoppgaven til brukeren er å lære å forstå hvilken linje som kommer fra hvem, og hva denne "hvem" er ansvarlig for. Derfor, hvis feilkoden fra VBR-loggen fører deg til en MSDN-side, er det normalt og riktig.

Som vi ble enige om tidligere: Veeam er et såkalt SQL-basert program. Det betyr at alle innstillinger, all informasjon og alt som er nødvendig for normal funksjonalitet lagres i databasen. Derav den enkle sannheten: det som ikke finnes i loggene, er sannsynligvis i databasen. Men dette er ikke en sølvkule: det finnes noen ting som ikke er i lokale logger for Veeam-komponenter eller i databasen. Derfor må man lære seg å studere vertens logger, logger fra den lokale maskinen og logger fra alt som deltar i sikkerhetskopierings- og gjenopprettingsprosessen. Og noen ganger er den nødvendige informasjonen ikke tilgjengelig noe sted. Slik er veien. 

Noen eksempler på slike API-er

Denne listen har ikke som mål å være uttømmende, så ikke forvent å finne den ultimate sannheten her. Målet er bare å vise de vanligste tredjeparts API-ene og teknologiene som brukes i våre produkter.

La oss begynne med VMware.. 

Først på listen er vSphere API. Det brukes til autentisering, lesing av hierarkiet, oppretting og sletting av øyeblikksbilder, forespørsel om informasjon om maskiner og veldig mye mer. Funksjonaliteten er veldig bred, så jeg kan anbefale VMware vSphere API Reference for versjonen 5.5 og 6.0. For nyere versjoner finner du det enkelt med litt Googling.

VIX API. Den svarte magien til hypervisoren, som har sin egen liste over feil. VMware API for å jobbe med filer på verten uten nettverkstilkobling. En siste utvei når man må legge en fil på en maskin som ikke har bedre forbindelser. Det blir smertefullt hvis filen er stor og verten er overbelastet. Men regelen gjelder her at 56,6 Kb/s er bedre enn 0 Kb/s. I Hyper-V kalles dette PowerShell Direct. Men dette var bare tilfelle før

vSphere Web Services API . Fra vSphere 6.0 (omtrent, ettersom dette APIet først ble introdusert i versjon 5.5) brukes det for å jobbe med gjestemaskiner og har allerede nesten helt utskiftet VIX. I bunn og grunn er dette et annet API for å administrere vSphere. Til de interesserte vil jeg anbefale å studere denne utmerkede manualen. 

VDDK (Virtual Disk Development Kit). Et bibliotek som ble delvis omtalt i denne artikkelen. Det brukes til å lese virtuelle disker. En gang var det en del av VIX, men ble etter hvert flyttet til et eget produkt. Som arving bruker det de samme feilkodene som VIX. Men av en eller annen grunn finnes det ingen beskrivelse av disse feilkodene i selve SDK-en. Derfor har det blitt kjent gjennom erfaring at VDDK-feil med andre koder bare er oversettelser fra binære til desimale koder. Den består av to deler – den første delen er u-dokumentert informasjon om konteksten, mens den andre delen er tradisjonelle VIX/VDDK-feil. For eksempel, hvis vi ser:

VDDK error: 21036749815809.Unknown error

, kan vi konvertere dette til hex og få 132200000001. Den ikke-informative starten 132200 blir bare kastet, og resten vil være vår feilkode (VDDK 1: Unknown error). Om de vanligste VDDK-feilene ble nylig laget en egen article.

Nå skal vi se på Windows.

. Her kan vi finne alt vi trenger i den standard Event Viewer. Men det er et problem: etter gammelt tradisjon logger Windows ikke en fullstendig feilmelding, men bare dens nummer. For eksempel er feil 5 – “Access denied”, mens 1722 – “The RPC server is unavailable”, og 10060 – “Connection timed out”. Selvfølgelig er det flott hvis du husker de mest kjente, men hvordan håndtere ukjente? 

Og for at livet ikke skulle virke for perfekt, lagres feil også i heksadesimal form, med prefikset 0x8007. For eksempel, 0x8007000e er faktisk 14, Out of Memory. Hvorfor og for hvem dette ble gjort er en gåte. Den fullstendige listen over feil kan imidlertid lastes ned gratis og uten SMS fra devsenter.

Forresten, noen ganger finner man også andre prefikser, ikke bare 0x8007. I en så trist situasjon, for å forstå HRESULT ("result handle"), må man gå enda dypere inn i dokumentasjonen for utviklere. I det daglige vil jeg ikke anbefale å gjøre dette, men hvis du plutselig blir presset mot veggen eller bare er nysgjerrig, vet du nå hva du skal gjøre.

Men gutta i Microsoft har vært litt snille mot oss og har presentert en verktøy ERR. Dette er et lite stykke konsolllykke, som kan oversette feilkoder til menneskelig språk uten å bruke Google. Det fungerer omtrent slik.

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# En intern feil oppstod.
# som en HRESULT: Alvorlighetsgrad: SUKSESS (0), FAGNULL (0x0), Kode 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# En intern feil oppstod.
# 2 treff funnet for "0x54f"

Det oppstår et legitimt spørsmål: hvorfor skriver vi ikke straks avkodingen inn i loggene, men lar disse mystiske kodene være? Svaret ligger i tredjepartsapplikasjoner. Når du selv kaller en WinAPI-funksjon, er det ikke vanskelig å dekode svaret, ettersom det til og med finnes et eget spesiallagt WinAPI-anrop for dette. Men som allerede nevnt, får våre logger inn alt som kommer tilbake i svarene våre. Og her måtte dekoding konstant overvåkes, for å plukke ut biter med Windows-feil, dekode dem og sette dem tilbake. La oss være ærlige, det er ikke den mest spennende oppgaven.

Windows File Management API bruken av dette i filbehandling er allsidig. Oppretting av filer, sletting, åpning for skriving, arbeid med attributter, og så videre.

Den nevnte PowerShell Direct som et alternativ til VIX API i Hyper-V. Dessverre ikke så fleksibel: mange begrensninger i funksjonaliteten, fungerer ikke med hver versjon av verten og langt fra med alle gjester.

RPC (Remote Procedure Call) Jeg tror ikke det finnes noen med erfaring fra Windows som ikke har sett feil relatert til RPC. Til tross for en vanlig misforståelse, er det ikke et enkelt protokoll, men enhver klient-server-protokoll som oppfyller en rekke kriterier. Men hvis vi ser en RPC-feil i loggene våre, er det i 90% av tilfellene en feil fra Microsoft RPC, som er en del av DCOM (Distributed Component Object Model). Det finnes et stort antall dokumenter om dette emnet på nettet, men mye av det er ganske utdaterte. Hvis det er et sterkt ønske om å lære mer, kan jeg anbefale artikler Hva er RPC?, Hvordan RPC fungerer og en lang liste av RPC-feil.

De viktigste årsakene til RPC-feil i loggene våre er mislykkede forsøk på interaksjon mellom VBR-komponenter (server > proxy, for eksempel), og oftest på grunn av kommunikasjonsproblemer.

Toppen av alle topper er feilen The RPC server is unavailable (1722). For å si det enkelt, klarte ikke klienten å opprette en forbindelse med serveren. Hvordan og hvorfor — det finnes ikke noe entydig svar, men vanligvis skyldes det autentiseringsproblemer eller nettverksadgang til port 135. Det er karakteristisk for infrastruktur med dynamisk tildeling av porter. Det er til og med en egen KB. Og hos Microsoft — en omfattende guide for å finne årsakene til feilen.

Den nest mest populære feilen: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller serveren klarte ikke å tildele seg en port. Dette skjer vanligvis når serveren (i vårt tilfelle gjeste-maskinen) var konfigurert for dynamisk tildeling av porter fra et smalt område som tok slutt. Hvis vi ser fra klientens side (i vårt tilfelle VBR-serveren), betyr det at vår VeeamVssAgent enten ikke startet eller ikke ble registrert som RPC-grensesnitt. Det finnes også en egen KB.

Og for å avslutte Topp-3 RPC-feilene, la oss huske RPC function call failed (1726). Dette skjer hvis forbindelsen ble opprettet, men RPC-forespørslene blir ikke behandlet. For eksempel, vi ber om informasjon om VSS-status (hvis det tilfeldigvis blir laget skyggkopi akkurat nå, og vi prøver å få tilgang), men i svaret får vi stillhet og ignoreres.

Windows Tape Backup API er nødvendig for å arbeide med båndbiblioteker eller stasjoner. Som jeg nevnte i begynnelsen: å skrive egne drivere og slite med å støtte hver enhet gir oss ingen glede. Derfor har Veeam ingen egne drivere. Alt skjer via standard API, som støttes av maskinvareleverandørene selv. Det er jo mye mer logisk, ikke sant?

SMB/CIFS Alle skriver dem som vanlig sammen, selv om ikke alle husker at CIFS (Common Internet File System) bare er en privat versjon av SMB (Server Message Block). Så det er egentlig ikke noe galt med å generalisere disse begrepene. Samba er allerede en Linux/Unix-implementering, og der er det spesifikke detaljer, men jeg kom litt ut av temaet. Hva som er viktig her: når Veeam ber om å skrive noe via UNC-sti (serverdirectory), bruker serveren hierarkiet av filsystemdrivere, inkludert mup og mrxsmb, for å skrive til delingen. Følgelig vil også feil bli generert av disse driverne.

Kan ikke klare seg uten Winsock API. Hvis noe skal gjøres over nettverket, fungerer VBR gjennom Windows Socket API, kjent som Winsock. Så hvis vi ser i loggen en kobling mellom IP:Port, så er det dette. Den offisielle dokumentasjonen har en ganske god liste over mulige feil.

Den nevnte WMI (Windows Management Instrumentation) er et såkalt allmektig API for å administrere alt og alle i Windows-verdenen. For eksempel skjer nesten alle forespørslene til verten når man arbeider med Hyper-V nettopp via dette. Med andre ord, en helt uunnværlig ting og veldig kraftig i sine muligheter. I forsøk på å hjelpe med å finne ut hvor og hva som har blitt ødelagt, er det innebygde verktøyet WBEMtest.exe til stor hjelp.

Og den siste på listen, men absolutt ikke den minste i betydning — VSS (Volume Shadow Storage). Temaet er like uendelig og mystisk som det er skrevet mye dokumentasjon om. Shadow Copy kan enklest forstås som en spesiell type snapshot, som det i bunn og grunn er. Takket være det er det mulig å lage applikasjonskonsistente sikkerhetskopier i VMware, og i Hyper-V nesten alt. Jeg har planer om å lage en egen artikkel med en slags oppsummering om VSS, men inntil videre kan du prøve å lese denne beskrivelsen. Vær forsiktig, da et forsøk på å forstå VSS i en fei kan føre til hodeskader.

På dette punktet kan vi kanskje stoppe. Jeg anser oppgaven med å forklare de mest grunnleggende tingene som fullført, så i neste kapittel vil vi se på loggene. Men hvis du har spørsmål, ikke nøl med å komme med dem i kommentarfeltet.

Kilde: habr.com