Vi fortsätter vår fördjupning i den fascinerande världen av gissningar ... felsökning med loggar. I vi enades om innebörden av de grundläggande termerna och tittade på Veeams övergripande struktur som en enda applikation med ett öga. Uppgiften för den här är att ta reda på hur loggfiler bildas, vilken typ av information som visas i dem och varför de ser ut som de ser ut.
Vad tror du att dessa "loggar" är? Enligt de flesta borde loggarna för vilken applikation som helst tilldelas rollen som en sorts allsmäktig enhet som för det mesta vegeterar någonstans på bakgården, men i rätt ögonblick dyker upp från ingenstans i lysande rustning och räddar alla. Det vill säga att de ska innehålla allt, från de minsta felen i varje komponent till enskilda databastransaktioner. Och så att det efter felet omedelbart skrevs hur man annars skulle fixa det. Och allt detta borde få plats på ett par megabyte, inte mer. Det är bara text! Textfiler kan inte ta tiotals gigabyte, jag hörde det någonstans!
Loggarna alltså
I den verkliga världen är loggar bara ett arkiv med diagnostisk information. Och vad som ska lagras där, var man ska få information för lagring och hur detaljerad den ska vara, är upp till utvecklarna själva att bestämma. Någon följer minimalismens väg genom att föra register över PÅ/AV-nivån, och någon håvar flitigt allt de kan nå. Även om det även finns ett mellanalternativ med möjlighet att välja den så kallade Loggningsnivån, när du själv anger hur detaljerad information du vill lagra och hur mycket extra diskutrymme du har =) VBR har förresten sex sådana nivåer. Och tro mig, du vill inte se vad som händer med den mest detaljerade loggningen med ledigt utrymme på din disk.
Bra. Vi förstod ungefär vad vi vill spara, men en berättigad fråga uppstår: var får man denna information ifrån? Självklart ingår vi i händelserna för att logga själva genom våra interna processer. Men vad ska man göra när det finns en interaktion med den yttre miljön? För att inte glida in i ett helvete av kryckor och cyklar, tenderar Veeam att inte uppfinna uppfinningar som redan har uppfunnits. Närhelst det finns ett färdigt API, inbyggd funktion, bibliotek etc., kommer vi att föredra färdiga alternativ innan vi börjar inhägna våra utrustningar. Även om det senare också räcker. När man analyserar loggar är det därför viktigt att förstå att lejonparten av felen faller på meddelanden från tredje parts API:er, systemanrop och andra bibliotek. I det här fallet handlar VBRs roll om att vidarebefordra dessa fel till loggfilerna som är. Och användarens huvuduppgift är att lära sig förstå vilken linje som kommer från vem och vad denna "vem" är ansvarig för. Så om en felkod från VBR-loggen tar dig till en MSDN-sida är det bra och korrekt.
Som vi kommit överens om tidigare: Veeam är en så kallad SQL-baserad applikation. Det betyder att alla inställningar, all information och i allmänhet allt som bara behövs för normal funktion – allt lagras i dess databas. Därav den enkla sanningen: det som inte finns i loggarna finns med största sannolikhet i databasen. Men det här är inte heller en silverkula: vissa saker finns inte i de lokala loggarna för Veeam-komponenter, inte heller i dess databas. Därför måste du lära dig hur du studerar värdloggarna, loggarna för den lokala maskinen och loggarna för allt som är inblandat i backup- och återställningsprocessen. Och det händer också att den nödvändiga informationen inte finns tillgänglig någonstans alls. Det är vägen.
Några exempel på sådana API:er
Denna lista syftar inte till att vara exceptionellt komplett, så det finns ingen anledning att leta efter den ultimata sanningen i den. Dess syfte ä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 på listan blir vSphere API. Används för autentisering, läsa hierarkin, skapa och ta bort ögonblicksbilder, begära information om maskiner och mycket (mycket) mer. Lösningens funktionalitet är mycket bred, så jag kan rekommendera VMware vSphere API Reference för versionen и . För mer aktuella versioner är allt bara googlat.
VIX API. Hypervisorns svarta magi, för vilken det finns en separat . VMware API för att arbeta med filer på värden utan att ansluta till dem över nätverket. Ett sista utvägsalternativ när du behöver lägga en fil i en maskin som det inte finns någon bättre kommunikationskanal till. Det är smärta och lidande om filen är stor och värden är laddad. Men här fungerar regeln att även 56,6 Kb/s är bättre än 0 Kb/s. I Hyper-V kallas den här saken PowerShell Direct. Men det var bara innan
vSpehere Web Services API Från och med vSphere 6.0 (ungefär sedan detta API först introducerades i version 5.5) används det för att arbeta med gästdatorer och har ersatt VIX nästan överallt. Faktum är att detta är ett annat API för att hantera vSphere. För den som är intresserad rekommenderar jag att studera manuell.
VDDK (Virtual Disk Development Kit). Biblioteket, som delvis diskuterades i detta . Används för att läsa virtuella diskar. En gång i tiden var det en del av VIX, men med tiden flyttades det till en separat produkt. Men som arvtagare använder den samma felkoder som VIX. Men av någon anledning finns det ingen beskrivning av dessa fel i själva SDK:n. Därför upptäcktes det empiriskt att VDDK-fel med andra koder bara är en översättning från binär till decimalkod. Den består av två delar - den första hälften är odokumenterad information om sammanhanget, och den andra delen är de traditionella VIX / VDDK-felen. Till exempel, om vi ser:
VDDK error: 21036749815809.Unknown error
Sedan konverterar vi djärvt detta till hex och får 132200000001. Vi förkastar helt enkelt den oinformativa början av 132200, och resten kommer att vara vår felkod (VDDK 1: Okänt fel). Om de vanligaste VDDK-felen fanns det nyligen en separat .
Låt oss nu titta på Windows.
Här finns allt som är viktigast och viktigast för oss i standarden Loggboken. Men det finns en hake: enligt en lång tradition loggar inte Windows hela feltexten utan bara dess nummer. Till exempel är fel 5 "Åtkomst nekad" och 1722 är "RPC-servern är inte tillgänglig" och 10060 är "Timeout för anslutning". Visst är det bra om du kommer ihåg de mest kända, men hur är det med de hittills osynliga?
Och för att livet inte alls ska verka som honung, lagras även fel i hexadecimal form, med prefixet 0x8007. Till exempel är 0x8007000e faktiskt 14, Minnet är slut. Varför och för vem detta gjordes är ett mysterium höljt i mörker. En komplett lista över fel kan dock laddas ner gratis och utan SMS från .
Förresten, ibland finns det andra prefix, inte bara 0x8007. I en sådan sorglig situation, för att förstå HRESULT ("resultathandtag"), måste du fördjupa dig ännu djupare i för utvecklare. I det vanliga livet råder jag dig inte att göra detta, men om du plötsligt tryckte mot väggen eller bara är nyfiken, nu vet du vad du ska göra.
Men kamraterna på Microsoft förbarmade sig lite över oss och visade världen en nytta . Det här är en liten bit av konsollycka som kan översätta felkoder till mänskliga utan att använda Google. Det fungerar så här.
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"En berättigad fråga uppstår: varför skriver vi inte omedelbart dekrypteringen till loggarna, utan lämnar dessa mystiska koder? Svaret finns i tredjepartsapplikationer. När du drar ett WinAPI-samtal själv är det inte svårt att tyda dess svar, eftersom det till och med finns ett speciellt WinAPI-anrop för detta. Men som redan nämnts, allt som bara kommer till oss i svar hamnar i våra loggar. Och här, för att dekryptera det, måste man ständigt övervaka denna medvetandeström, dra ut bitar med Windows-fel från den, dekryptera dem och klistra tillbaka dem. Låt oss vara ärliga, inte den mest spännande aktiviteten.
Windows File Management API används på alla möjliga sätt när man arbetar med filer. Skapa filer, ta bort, öppna för skrivning, arbeta med attribut och så vidare och så vidare.
nämnts ovan PowerShell Direct som en analog till VIX API i Hyper-V-världen. Tyvärr inte så flexibelt: många begränsningar på funktionalitet, det fungerar inte med alla versioner av värden och inte med alla gäster.
RPC (Remote Procedure Call) Jag tror inte att det finns en enda person som har arbetat med Windows som inte har sett RPC-relaterade fel. Trots den populära missuppfattningen är detta inte ett enda protokoll, utan vilket klient-serverprotokoll som helst som uppfyller ett antal parametrar. Men om det finns ett RPC-fel i våra loggar kommer det 90 % av tiden att vara ett fel från Microsoft RPC, som är en del av DCOM (Distributed Component Object Model). Du kan hitta en enorm mängd dokumentation om detta ämne på nätet, men lejonparten av den är ganska föråldrad. Men om det finns en akut önskan att studera ämnet, kan jag rekommendera artiklar , och lång lista .
De främsta orsakerna till RPC-fel i våra loggar är misslyckade försök att kommunicera mellan VBR-komponenter (server > proxy, till exempel) och oftast på grund av kommunikationsproblem.
Den översta toppen bland alla toppar är felet RPC-servern är inte tillgänglig (1722). Enkelt uttryckt kunde klienten inte upprätta en anslutning till servern. Hur och varför - det finns inget entydigt svar, men oftast är det problem med autentisering eller med nätverksåtkomst till port 135. Det senare är typiskt för infrastrukturer med dynamisk porttilldelning. På detta ämne finns det till och med . Och det har Microsoft för att hitta orsaken till felet.
Det näst mest populära felet: Det finns inga fler slutpunkter tillgängliga från slutpunktsmatteraren (1753). RPC-klienten eller servern kunde inte tilldela sig själv en port. Uppstår vanligtvis när servern (i vårt fall gästdatorn) har konfigurerats för att dynamiskt allokera portar från ett smalt intervall som har avslutats. Och om du loggar in från klientsidan (i vårt fall VBR-servern) betyder det att vår VeeamVssAgent antingen inte startade eller inte registrerades som ett RPC-gränssnitt. Det finns också om detta ämne .
Tja, för att slutföra de tre bästa RPC-felen, låt oss komma ihåg att RPC-funktionsanropet misslyckades (3). Visas om anslutningen har upprättats, men RPC-begäranden inte behandlas. Vi begär till exempel information om status för VSS (plötsligt just nu görs en skuggmina där, och vi försöker klättra), och som svar på oss tystnar och ignorerar.
Windows Tape Backup API behövs för att arbeta med bandbibliotek eller enheter. Som jag nämnde i början: vi har ingen glädje av att skriva våra egna drivrutiner och sedan lida med stöd av varje enhet. Därför har vim inga egna drivrutiner. Allt genom ett standard-API, vars stöd implementeras av hårdvaruleverantörerna själva. Så mycket mer logiskt, eller hur?
SMB / CIFS Av vana skriver alla dem sida vid sida, även om inte alla kommer ihåg att CIFS (Common Internet File System) bara är en privat version av SMB (Server Message Block). Så det är inget fel med att generalisera dessa begrepp. Samba är redan en LinuxUnix-implementering, och den har sina egna särdrag, men jag avviker. Vad som är viktigt här: när Veeam ber om att skriva något till UNC-sökvägen (serverkatalogen), använder servern hierarkin av filsystemdrivrutiner, inklusive mup och mrxsmb, för att skriva till bollen. Följaktligen kommer dessa drivrutiner också att generera fel.
Kan inte vara utan Winsock API. Om något behöver göras över nätverket fungerar VBR genom Windows Socket API, populärt känt som Winsock. Så om vi ser ett gäng IP:Port i loggen så är det här. Den officiella dokumentationen har en bra lista över möjliga .
nämnts ovan WMI (Windows Management Instrumentation) är ett slags allsmäktig API för att hantera allt och alla i Windows-världen. När man till exempel arbetar med Hyper-V går nästan alla förfrågningar till värden igenom den. Med ett ord, saken är absolut oersättlig och mycket kraftfull i sina förmågor. I ett försök att hjälpa till att ta reda på var och vad som är trasigt, hjälper det inbyggda WBEMtest.exe-verktyget mycket.
Och sist på listan, men inte minst i betydelse - VSS (Volym Shadow Storage). Ämnet är lika outtömligt och mystiskt som mycket dokumentation har skrivits om det. Shadow Copy förstås enklast som en speciell typ av ögonblicksbild, vilket det i huvudsak är. Tack vare honom kan du göra applikationskonsekventa säkerhetskopior i VMware, och nästan allt i Hyper-V. Jag har planer på att göra en separat artikel med lite kläm på VSS, men tills vidare kan du försöka läsa . Var bara försiktig, för. Att snabbt försöka förstå VSS kan leda till hjärnskada.
På detta kanske vi kan sluta. Jag anser att uppgiften att förklara de mest grundläggande sakerna är klar, så i nästa kapitel kommer vi redan att titta på loggarna. Men om du har några frågor, ställ dem gärna i kommentarerna.
Källa: will.com