Varifrån kommer loggar? Veeam Log Diving

Vi fortsätter vår djupdykning i den spännande världen av troubleshooting via loggar. den föregående artikeln Vi har kommit överens om betydelsen av grundläggande termer och fått en överblick över den övergripande strukturen av Veeam som en enhetlig applikation. Målet med detta avsnitt är att förstå hur loggfiler skapas, vilken information som visas i dem och varför de ser ut som de gör.

Vad tycker ni egentligen att dessa "loggar" är? Enligt de flesta borde loggarna för varje applikation spela rollen av en allsmäktig entitet som mestadels av tiden existerar i skuggan, men i rätt ögonblick dyker upp ur ingenstans i skinande rustning och räddar situationen. Det innebär att de borde innehålla allt från de minsta felen i varje komponent till enskilda databastransaktioner. Och efter ett fel bör det direkt skrivas hur man kan åtgärda det. Och allt detta måste få plats i ett par megabyte, högst. Det är ju bara text! Textfiler kan inte ta upp tiotals gigabyte, det har jag hört någonstans!

Så, loggar

I den verkliga världen är loggar bara ett arkiv av diagnostisk information. Vilken information som ska lagras, hur man hämtar informationen för lagring och hur detaljerad den ska vara, är upp till utvecklarna. Vissa går den minimalistiska vägen och lagrar endast på/av-poster, medan andra ivrigt samlar allt de kan få tag på. Det finns också ett mellanläge med möjlighet att välja så kallad Logging Level, där du själv anger hur detaljerad information du vill lagra och hur mycket överflödigt utrymme du har på disken =) VBR har faktiskt hela sex sådana nivåer. Och tro mig, du vill inte se vad som händer vid den mest detaljrika loggningen med fritt utrymme på din disk.

Bra. Vi har ungefär förstått vad vi vill spara, men det uppstår en legitim fråga: varifrån ska vi hämta denna information? En del av händelserna för loggning skapar vi givetvis själva genom våra interna processer. Men vad gör man när det sker interaktion med externa miljöer? För att inte falla ner i en mörk avgrund av provisoriska lösningar och uppfinningar har Veeam en tendens att inte uppfinna hjulet på nytt. Alltid, när det finns ett färdigt API, en inbyggd funktion i systemet, ett bibliotek osv., kommer vi att ge fördelar åt de befintliga alternativen innan vi börjar bygga våra egna smarta lösningar. Men det finns också gott om sådana. Därför är det viktigt att förstå vid analys av loggar att en stor del av felen kommer från meddelanden från tredjeparts-API:er, systemanrop och andra bibliotek. I det här fallet handlar VBR:s roll om att vidarebefordra dessa fel till loggfiler som de är. Och den grundläggande uppgiften för användaren är att lära sig förstå vilken rad som kommer från vem, och vad den ”vem” ansvarar för. Så om felkoden från VBR-loggen leder dig till en sida på MSDN, är det normalt och korrekt.

Som vi kom överens om tidigare: Veeam är en så kallad SQL-baserad applikation. Och det betyder att alla inställningar, all information och överhuvudtaget allt som krävs för normal funktion — allt lagras i dess databas. Här är den enkla sanningen: det som inte finns i loggarna finns förmodligen i databasen. Men detta är inte en silverkula: vissa saker finns varken i de lokala loggarna från Veeam-komponenterna eller i dess databas. Därför måste man lära sig att studera värdloggar, loggar från den lokala maskinen och loggar från allt som deltar i backup- och återställningsprocessen. Och ibland är det så att den nödvändiga informationen inte finns någonstans. Sådan är vägen. 

Några exempel på sådana API:er

Denna lista har inte som syfte att vara heltäckande, så sök inte i den efter sanning i sista instans. Dess uppgift är endast att visa de vanligaste tredjeparts-API:erna och teknologierna som används i våra produkter.

Låt oss börja med VMware. 

Först i listan kommer vSphere API. Används för autentisering, läsa hierarkier, skapa och ta bort snapshots, begära information om maskiner och mycket (mycket) mer. Lösningens funktionalitet är mycket bred, så jag rekommenderar alla intresserade att kolla in VMware vSphere API Reference för versionen 5.5 och 6.0. För mer aktuella versioner kan man enkelt googla.

VIX API. Den svarta magin hos hypervisorn, för vilken det finns en separat lista över fel. VMware API för att arbeta med filer på värden utan nätverksanslutning. En sista utväg när man behöver lägga en fil på en maskin som inte har bättre kommunikationskanaler. Det innebär en del smärta och lidande om filen är stor och värden är belastad. Men här gäller regeln att även 56,6 Kb/s är bättre än 0 Kb/s. I Hyper-V kallas en liknande funktion PowerShell Direct. Men så var det bara fram till introduktionen av

vSphere Web Services API . Från och med vSphere 6.0 (ungefär, eftersom detta API första gången introducerades i version 5.5) används det för att hantera gästmaskiner och har redan praktiskt taget ersatt VIX överallt. I grund och botten är det ännu ett API för att hantera vSphere. För den intresserade kan jag rekommendera att studera den utmärkta manualen. 

VDDK (Virtual Disk Development Kit). Ett bibliotek som delvis nämndes i denna artikeln. Används för att läsa virtuella diskar. För länge sedan var det en del av VIX, men med tiden flyttades det till en egen produkt. Men i egenskap av arvtagare använder det samma felkoder som VIX. Men av någon anledning finns det ingen beskrivning av dessa fel i själva SDK:n. Genom erfarenhet har det fastställts att VDDK-fel med andra koder — är bara en översättning från binär till decimal kod. Består av två delar - den första halvan är odokumenterad information om kontexten, och den andra delen är traditionella VIX/VDDK-fel. Till exempel, om vi ser:

VDDK error: 21036749815809.Unknown error

Så konverterar vi detta till hex och får 132200000001. Det oinformerande början 132200 avvisar vi, och resten blir vår felkod (VDDK 1: Okänt fel). Nyligen fanns det en separat diskussion om de vanligaste VDDK-felen artikeln.

Nu ska vi titta på Windows.

Här hittar vi allt som är nödvändigt och viktigt för oss i den standard Event Viewer. Men det finns en hake: enligt en gammal tradition loggar Windows inte hela felmeddelanden, utan bara deras nummer. Till exempel, felkod 5 är “Åtkomst nekad”, 1722 är “RPC-servern är otillgänglig”, och 10060 är “Anslutningen har tidsgräns”. Självklart är det bra om man kommer ihåg de mest kända, men hur gör man med de tidigare okända? 

För att livet inte ska kännas som en ren dröm förvaras även fel i hexadecimalt format, med prefixet 0x8007. Till exempel, 0x8007000e är egentligen 14, Out of Memory. Varför och för vem detta gjordes är en gåta. Dock kan du ladda ner hela listan över fel gratis och utan SMS från utvecklingscentret.

För övrigt förekommer ibland andra prefix än bara 0x8007. I en sådan olycklig situation måste man djupare förstå HRESULT ("result handle") dokumentationen för utvecklarna. I det normala livet rekommenderar jag dig inte att göra så här, men om du skulle bli pressad mot väggen eller bara är nyfiken, så vet du nu vad du ska göra.

Men killarna på Microsoft visade lite medkänsla och presenterade världen för ett verktyg ERR. Det är en liten del av konsolens lycka, som kan översätta felkoder till mänskligt språk utan att använda Google. Den fungerar ungefär så här.

C:UsersrootDesktop>err.exe 0x54f
# för hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Ett internt fel inträffade.
# som ett HRESULT: Allvarlighetsgrad: SUCCESS (0), FACILITY_NULL (0x0), Kod 0x54f
# för hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Ett internt fel inträffade.
# 2 träffar hittades för "0x54f"

Det väcker en giltig fråga: varför skriver vi inte direkt avkodningen i loggarna, utan lämnar dessa mystiska koder? Svaret ligger i tredjepartsapplikationer. När du själv kallar på något WinAPI-anrop är det inte svårt att avkoda svaret, eftersom det finns ett speciellt WinAPI-anrop för det. Men som redan nämnts hamnar allt i våra loggar som vi får i svaren. Här skulle vi dock behöva ständigt övervaka detta flöde av medvetande, plocka ut bitar med Windows-fel, avkoda dem och sätta tillbaka dem. Låt oss vara ärliga, det är inte särskilt spännande.

Windows Filhanterings-API används i hög grad när man arbetar med filer. Skapande av filer, radering, öppning för skrivning, arbete med attribut och så vidare.

Den ovan nämnda PowerShell Direct som ett alternativ till VIX API i Hyper-V världen. Tyvärr inte så flexibelt: många begränsningar i funktionaliteten, fungerar inte med varje version av värden och långt ifrån alla gäster.

RPC (Remote Procedure Call) Jag tror att det inte finns en enda person som har arbetat med Windows som inte har sett fel kopplade till RPC. Trots den populära missuppfattningen är det inte en specifik protokoll, utan vilket klient-serverprotokoll som helst som uppfyller vissa kriterier. Men om vi har ett RPC-fel i våra loggar, är det i 90 % av fallen ett fel från Microsoft RPC, som är en del av DCOM (Distributed Component Object Model). Det finns en enorm mängd dokumentation om detta ämne på nätet, men mycket av den är ganska gammal. Men om det finns en stark önskan att studera ämnet, kan jag rekommendera artiklar. Vad är RPC?, Hur RPC fungerar och en lång lista RPC-fel.

De viktigaste orsakerna till RPC-fel i våra loggar är misslyckade försök till interaktion mellan VBR-komponenter (server > proxy, till exempel) och oftast på grund av kommunikationsproblem.

Toppen av alla toppar är felet The RPC server is unavailable (1722). Om vi ska tala enkelt, så kunde kunden inte upprätta en anslutning till servern. Varför och hur — det finns inget entydigt svar, men det är vanligtvis ett problem med autentisering eller nätverksåtkomst till port 135. Det senare är typiskt för infrastrukturer med dynamisk portallokering. Det finns till och med en separat KB. Och hos Microsoft finns det en omfattande guide för att hitta orsakerna till felet.

Det näst mest populära felet: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller servern kunde inte tilldela en port till sig själva. Det inträffar vanligtvis när servern (i vårt fall värdmaskinen) är inställd på dynamisk portallokering från ett smalt område som har tagit slut. Om vi ser det från klientens sida (i vårt fall VBR-servern) betyder det att vår VeeamVssAgent antingen inte startade eller inte registrerades som RPC-gränssnitt. Det finns också en separat KB.

Och för att avsluta topp-3 RPC-fel, låt oss minnas RPC function call failed (1726). Det inträffar om anslutningen har upprättats, men RPC-begärningarna inte genomförs. Till exempel, vi begär information om VSS-status (om det till exempel just nu görs shadow copy, och vi försöker gå in), och som svar får vi tystnad och ignorans.

Windows Tape Backup API Behövs för att arbeta med bandbibliotek eller enheter. Som jag nämnde i början: det är ingen nöje att skriva sina egna drivrutiner och sedan plåga sig med att stödja varje enhet. Därför har Veeam inga egna drivrutiner. Allt går via standard-API:n, vars stöd tillhandahålls av hårdvaruleverantörerna själva. Så mycket mer logiskt, eller hur?

SMB/CIFS Alla skriver dem av gammal vana bredvid varandra, även om långt ifrån alla minns att CIFS (Common Internet File System) bara är en privat version av SMB (Server Message Block). Så det finns inget dåligt med att sammanfoga dessa begrepp. Samba är en Linux/Unix-implementation, och där finns egna särdrag, men jag kommer ifrån ämnet. Det viktiga här är: när Veeam ber om att skriva något via en UNC-sökväg (serverdirectory), så använder servern hierarkin av filsystemets drivrutiner, inklusive mup och mrxsmb, för att skriva till delningen. Därmed kommer även dessa drivrutiner generera fel.

Det går inte att klara sig utan Winsock API. Om något behöver göras över nätverket arbetar VBR genom Windows Socket API, som allmänt kallas Winsock. Så om vi ser i loggen en koppling mellan IP:Port, då är det det. I den officiella dokumentationen finns en ganska bra lista över möjliga fel.

Den ovan nämnda WMI (Windows Management Instrumentation) - det är en sorts allsmäktig API för att hantera allt och alla inom Windows-världen. Till exempel, när man arbetar med Hyper-V sker nästan alla begärningar till värden just genom det. Så, det är helt enkelt en ovärderlig och mycket kraftfull resurs. I försök att hjälpa till att reda ut var och vad som har gått fel, är det mycket hjälpsamt att ha det inbyggda verktyget WBEMtest.exe.

Och den sista i listan, men långt ifrån den minst viktiga - VSS (Volume Shadow Storage). Ämnet är lika outtömligt och mystiskt som det finns mycket dokumentation skriven om det. Shadow Copy kan enklast förstås som en speciell typ av snapshot, vilket det i grunden är. Tack vare det kan man i VMware göra applikationskonsekventa säkerhetskopior, och i Hyper-V nästan allt. Jag planerar att göra en separat artikel med en sammanställning av VSS, men tills dess kan du försöka läsa denna beskrivning. Var försiktig, eftersom ett försök att förstå VSS på språng kan leda till hjärnskador.

Det här borde räcka. Jag anser att uppgiften att förklara de mest grundläggande sakerna är genomförd, så i nästa kapitel kommer vi att titta på loggarna. Men om du har några frågor, tveka inte att ställa dem i kommentarerna.

Källa: habr.com