We continue our plunge into the fascinating world of troubleshooting through logs. In we agreed on the meaning of basic terms and took a brief look at the overall structure of Veeam as a unified application. The task now is to understand how log files are formed, what information they display, and why they look the way they do.
What do you think these "logs" actually are? Most people believe that the logs of any application should serve as a sort of all-powerful entity, which mostly dwells somewhere on the sidelines but emerges from nowhere in shining armor to save the day when needed. In other words, they should contain everything from minor errors in each component to individual database transactions. And after an error occurs, there should be immediate guidance on how to fix it. Moreover, all of this should fit within a couple of megabytes, at most. It's just text! Text files can't take up tens of gigabytes; I've heard that somewhere!
So, logs
In the real world, logs are merely an archive of diagnostic information. Deciding what to store, where to obtain the information for storage, and how detailed it should be is up to the developers themselves. Some take the minimalist approach, storing only ON/OFF level records, while others diligently gather everything they can reach. There's also an intermediate option with the ability to select the so-called Logging Level, where you specify how detailed the information you want to store is and how much extra space you have on your disks. VBR has six such levels, by the way. And believe me, you don’t want to see what happens during maximum detailed logging when there is free space on your disk.
Goed. We hebben ongeveer begrepen wat we willen behouden, maar de legitieme vraag is: waar halen we deze informatie vandaan? Een deel van de logevenementen wordt natuurlijk door onze interne processen zelf gegenereerd. Maar wat te doen wanneer er interactie met de externe omgeving plaatsvindt? Om niet te vervallen in een chaos van tijdelijke oplossingen en herinventies, heeft Veeam de neiging om niet opnieuw uitvindingen uit te vinden die al uitgevonden zijn. Altijd wanneer er al een kant-en-klaar API, ingebouwde systeemfunctie, bibliotheek, enzovoort beschikbaar is, geven we de voorkeur aan deze oplossingen voordat we beginnen met het bouwen van onze eigen ingenieuze oplossingen. Hoewel er ook genoeg van die laatste zijn. Daarom is het bij het analyseren van logboeken belangrijk om te begrijpen dat een groot deel van de fouten voortkomt uit berichten van externe API's, systeemoproepen en andere bibliotheken. In dit geval is de rol van VBR het doorsturen van deze fouten naar logbestanden zoals ze zijn. De belangrijkste taak van de gebruiker is om te leren begrijpen welke regel van wie is, en waarvoor deze “wie” verantwoordelijk is. Daarom, als de foutcode uit het VBR-log u naar de MSDN-pagina leidt, is dat normaal en correct.
Zoals eerder afgesproken: Veeam is een zogenaamde SQL-gebaseerde applicatie. Dat betekent dat alle instellingen, alle informatie en eigenlijk alles wat nodig is voor een normale werking — alles wordt opgeslagen in zijn database. Hieruit volgt een eenvoudige waarheid: wat niet in de logs staat, staat hoogstwaarschijnlijk in de database. Maar dat is ook geen wondermiddel: sommige dingen zijn noch in de lokale logs van Veeam-componenten, noch in de database te vinden. Daarom moet je leren de logs van de host, de logs van de lokale machine en de logs van alles wat betrokken is bij het backup- en herstelproces te bestuderen. En soms is de benodigde informatie helemaal nergens te vinden. Dat is de weg.
Enkele voorbeelden van dergelijke API's
Deze lijst heeft niet de ambitie om volledig te zijn, dus zoek er alsjeblieft geen onbetwistbare waarheid in. Het doel ervan is enkel om de meest voorkomende externe API's en technologieën die in onze producten worden gebruikt, te tonen.
Laten we beginnen met VMware.
De eerste in de lijst zal zijn vSphere API. Wordt gebruikt voor authenticatie, het lezen van de hiërarchie, het maken en verwijderen van snapshots, het opvragen van informatie over machines en nog veel (heel veel) meer. De functionaliteit van deze oplossing is zeer breed, dus voor iedereen die geïnteresseerd is, kan ik de VMware vSphere API Reference voor versie aanbevelen en . Voor de meer actuele versies is alles eenvoudig te vinden via Google.
VIX API. Zwarte magie van de hypervisor, waarvoor er een aparte . VMware API voor het werken met bestanden op de host zonder deze via het netwerk te verbinden. Een laatste redmiddel wanneer je een bestand op een machine moet plaatsen waarvoor er geen betere verbinding meer mogelijk is. Het zorgt voor veel pijn en lijden als het bestand groot is en de host druk bezet. Maar er geldt de regel dat zelfs 56,6 Kb/s beter is dan 0 Kb/s. In Hyper-V wordt een soortgelijk iets PowerShell Direct genoemd. Maar dat was alleen zo tot de komst van
vSphere Web Services API . Sinds vSphere 6.0 (ongeveer, aangezien dit API voor het eerst werd gepresenteerd in versie 5.5) wordt het gebruikt voor het werken met gastmachines en heeft het VIX praktisch overal verdrongen. In wezen is dit weer een API voor het beheren van vSphere. Voor geïnteresseerden kan ik aanraden om handleiding te bestuderen.
VDDK (Virtual Disk Development Kit). Een bibliotheek waar deels in dit document omheen werd gesproken. Het wordt gebruikt voor het lezen van virtuele schijven. Vroeger maakte het deel uit van VIX, maar met de tijd is het in een apart product geplaatst. Als erfgenaam gebruikt het echter dezelfde foutcodes als VIX. Maar om een of andere reden staat er in de SDK zelf geen beschrijving van deze fouten. Daarom is door middel van ervaring vastgesteld dat VDDK-fouten met andere codes slechts een vertaling zijn van binaire naar decimale code. Het bestaat uit twee delen – de eerste helft bevat niet-gedocumenteerde informatie over de context, en de tweede helft zijn de traditionele VIX/VDDK-fouten. Bijvoorbeeld, als we zien: VDDK error: 21036749815809.Unknown error
Dan converteren we dit gerust naar hex en krijgen we 132200000001. Het niet-informatieve begin 132200 laten we gewoon vallen, en de rest zal onze foutcode zijn (VDDK 1: Onbekende fout). Onlangs was er een aparte
Nu kijken we naar .
Windows Hier is alles wat we nodig hebben en belangrijk is te vinden in de standaard.
Event Viewer . Maar er is één probleem: volgens een oude traditie logt Windows niet de volledige fouttekst, maar alleen het nummer. Bijvoorbeeld, fout 5 is ‘Toegang geweigerd’, en 1722 is ‘De RPC-server is niet beschikbaar’, en 10060 is ‘De verbinding is verlopen’. Natuurlijk is het geweldig als je de meest bekende codes onthoudt, maar hoe zit het met tot nu toe ongeziene fouten?. Er is echter één probleem: volgens een oude traditie registreert Windows niet de volledige fouttekst, maar alleen het foutnummer. Bijvoorbeeld, fout 5 staat voor “Toegang geweigerd”, fout 1722 betekent “De RPC-server is niet beschikbaar” en fout 10060 is “Verbindingstime-out”. Het is natuurlijk geweldig als je de meest bekende nummers uit je hoofd kent, maar hoe ga je om met foutmeldingen die je nog nooit eerder hebt gezien?
En om het leven niet te zoet te maken, worden fouten ook opgeslagen in hexadecimale vorm, met het prefix 0x8007. Bijvoorbeeld, 0x8007000e betekent eigenlijk 14, Out of Memory. Waarom en voor wie dit gedaan is, blijft een mysterie. Echter, de volledige lijst met fouten kan gratis en zonder SMS gedownload worden uit .
Overigens komen er soms ook andere prefixes voor, en niet alleen 0x8007. In zo'n trieste situatie moet je nog dieper graven om HRESULT ("result handle") te begrijpen voor ontwikkelaars. In het dagelijks leven raad ik je aan om dit niet te doen, maar als je echt in de knel zit of gewoon nieuwsgierig bent, weet je nu wat je moet doen.
Maar de vrienden bij Microsoft hebben ons een beetje genade getoond en presenteerden de utility . Dit is een klein stukje consolegeluk dat foutcodes naar menselijk leesbare tekst kan vertalen zonder Google. Het werkt ongeveer zo.
C:UsersrootDesktop>err.exe 0x54f
# voor hex 0x54f / decimaal 1359
ERROR_INTERNAL_ERROR winerror.h
# Een interne fout is opgetreden.
# als een HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# voor hex 0x54f / decimaal 1359
ERROR_INTERNAL_ERROR winerror.h
# Een interne fout is opgetreden.
# 2 overeenkomsten gevonden voor "0x54f"Er rijst een legitieme vraag: waarom schrijven we de verklaring niet meteen in de logs, maar laten we deze mysterieuze codes staan? Het antwoord ligt in externe applicaties. Wanneer je zelf een WinAPI-aanroep doet, is het niet moeilijk om de respons ervan te ontcijferen, want er is al een speciale WinAPI-aanroep voor. Maar zoals al gezegd, komt alles wat in de antwoorden naar ons toe komt in onze logs terecht. En voor het ontcijferen hiervan zou je constant deze stroom van bewustzijn moeten monitoren, stukken met Windows-fouten eruit moeten filteren, deze moeten ontcijferen en weer terug moeten invoegen. Laten we eerlijk zijn, het is geen boeiende bezigheid.
Windows File Management API wordt op verschillende manieren gebruikt bij het werken met bestanden. Het aanmaken van bestanden, verwijderen, openen voor schrijven, werken met attributen, en nog veel meer.
De eerder genoemde PowerShell Direct is vergelijkbaar met de VIX API in de wereld van Hyper-V. Helaas is het niet zo flexibel: er zijn veel functionele beperkingen, het werkt niet met elke versie van de host en zeker niet met alle gasten.
RPC (Remote Procedure Call) Ik denk dat er geen enkele persoon is die met Windows heeft gewerkt en nog nooit fouten heeft gezien die verband houden met RPC. Ondanks een wijdverbreid misverstand is dit geen enkel protocol, maar elk client-serverprotocol dat voldoet aan een aantal parameters. Echter, als we in onze logs een RPC-fout zien, is dit in 90% van de gevallen een fout van Microsoft RPC, dat onderdeel is van DCOM (Distributed Component Object Model). Er is een enorme hoeveelheid documentatie over dit onderwerp te vinden op het internet, maar het merendeel is behoorlijk verouderd. Maar als er een sterke wens is om het onderwerp te bestuderen, kan ik artikelen aanbevelen. , en een lange lijst .
De belangrijkste oorzaken van RPC-fouten in onze logs zijn mislukte pogingen tot interactie tussen VBR-componenten (server > proxy, bijvoorbeeld) en meestal door verbindingsproblemen.
De grootste van allemaal is de fout The RPC server is unavailable (1722). Simpel gezegd, de client kon geen verbinding maken met de server. Hoe en waarom - daar is geen eenduidig antwoord op, maar het is meestal een probleem met authenticatie of met netwerktoegang tot poort 135. Dit is typisch voor infrastructuren met dynamische poorttoewijzing. Over dit onderwerp is er zelfs een . En bij Microsoft is er een voor het vinden van de oorzaken van de storing.
De op één na meest voorkomende fout: There are no more endpoints available from the endpoint mapper (1753). De RPC-client of server kon geen poort toewijzen. Dit gebeurt meestal wanneer de server (in ons geval de gastmachine) is ingesteld op dynamische poorten uit een beperkt bereik, dat vol is. En als we vanuit de clientzijde (in ons geval de VBR-server) kijken, betekent dit dat onze VeeamVssAgent of niet is gestart, of niet is geregistreerd als RPC-interface. Ook over dit onderwerp is er .
En om de top 3 RPC-fouten af te ronden, herinneren we ons de RPC function call failed (1726). Dit verschijnt als de verbinding is gemaakt, maar de RPC-verzoeken niet worden verwerkt. Bijvoorbeeld, we vragen om informatie over de status van VSS (misschien wordt er op dat moment een schaduwkopie gemaakt), maar we krijgen stilte en negeren als antwoord.
Windows Tape Backup API is nodig voor het werken met tape bibliotheken of drives. Zoals ik aan het begin al zei: het schrijven van je eigen drivers en daarna worstelen met de ondersteuning van elk apparaat geeft ons absoluut geen plezier. Daarom heeft Veeam geen eigen drivers. Alles gaat via de standaard API, waarvan de ondersteuning door de hardwareleveranciers zelf wordt gerealiseerd. Dat is veel logischer, toch?
SMB/CIFS Iedereen schrijft ze uit gewoonte naast elkaar, hoewel niet iedereen zich herinnert dat CIFS (Common Internet File System) gewoon een privés versie van SMB (Server Message Block) is. Dus er is niets mis met het veralgemenen van deze concepten. Samba is de Linux/Unix-implementatie, en daar zijn eigen bijzonderheden, maar ik dwaal af. Wat belangrijk is: wanneer Veeam vraagt om iets te schrijven via het UNC-pad (serverdirectory), gebruikt de server de hiërarchie van filesystem-drivers, inclusief mup en mrxsmb, voor het schrijven naar de share. Dienovereenkomstig worden deze drivers ook de fouten genereren.
Kun je absoluut niet zonder Winsock API. Als er iets over het netwerk moet gebeuren, werkt VBR via de Windows Socket API, die in de volksmond bekend staat als Winsock. Dus als we in de log een combinatie van IP:Port zien, dan is dat het. In de officiële documentatie is er een goede lijst van mogelijke .
De eerder genoemde WMI (Windows Management Instrumentation) — dit is een soort almachtige API voor het beheren van alles en iedereen in de Windows-wereld. Bijvoorbeeld, wanneer we met Hyper-V werken, verlopen vrijwel alle verzoeken naar de host via deze API. Kortom, een onmisbare en zeer krachtige tool in zijn mogelijkheden. Bij de pogingen om te helpen achterhalen waar en wat er kapot is, helpt de ingebouwde tool WBEMtest.exe enorm.
En de laatste op de lijst, maar absoluut niet de minste — VSS (Volume Shadow Storage). Het onderwerp is zo onuitputtelijk en mysterieus als er documentatie over is geschreven. Shadow Copy is het gemakkelijkst te begrijpen als een soort snapshot, wat het in wezen ook is. Dankzij dit kunnen we in VMware application-consistente backups maken, en in Hyper-V eigenlijk bijna alles. Ik ben van plan een apart artikel te maken met een soort samenvatting over VSS, maar tot nu toe kun je proberen deze . Wees alleen voorzichtig, want de poging om VSS in één klap te begrijpen kan leiden tot hersentrauma.
Laten we hier maar mee stoppen. Ik beschouw de taak om de meest basale zaken uit te leggen als voltooid, dus in het volgende hoofdstuk zullen we naar de logs kijken. Maar als je nog vragen hebt, aarzel dan niet ze in de reacties te stellen.
Bron: habr.com
