Wir setzen unser Eintauchen in die faszinierende Welt des Troubleshootings durch Logs fort. In haben wir uns über die Bedeutung grundlegender Begriffe verständigt und einen kurzen Blick auf die allgemeine Struktur von Veeam als einer einzigen Anwendung geworfen. Die Aufgabe für diese Sitzung ist es, herauszufinden, wie Logdateien erstellt werden, welche Informationen sie enthalten und warum sie so aussehen, wie sie aussehen.
Was denken Sie, sind überhaupt diese "Logs"? Für die meisten sollten Logs einer Anwendung die Rolle einer allmächtigen Entität spielen, die die meiste Zeit irgendwo im Hintergrund vegetiert, aber im entscheidenden Moment aus dem Nichts in glänzenden Rüstungen erscheint und alle rettet. Das heißt, sie sollten alles enthalten, von den kleinsten Fehlern in jedem Bauteil bis hin zu einzelnen Datenbanktransaktionen. Und nach einem Fehler sollte sofort vermerkt werden, wie man es beheben kann. Und all das sollte in ein paar Megabyte passen, nicht mehr. Das ist doch nur Text! Textdateien können keine Dutzende Gigabyte wiegen, das habe ich irgendwo gehört!
Also, Logs
Im wirklichen Leben sind Protokolle lediglich Archive von Diagnosedaten. Die Entscheidung darüber, was dort gespeichert werden soll, woher die Informationen für die Speicherung stammen und wie detailliert sie sein sollten, liegt bei den Entwicklern selbst. Manche entscheiden sich für einen minimalistischen Ansatz und speichern nur Einträge über EIN/AUS, während andere alles, was erreichbar ist, gewissenhaft sammeln. Es gibt aber auch eine Zwischenlösung mit der Möglichkeit, das sogenannte Logging Level auszuwählen, bei dem man selbst angibt, wie detaillierte Informationen man speichern möchte und wie viel Speicherplatz auf den Festplatten verfügbar ist. Übrigens hat VBR sechs solcher Levels. Und glauben Sie mir, Sie möchten nicht sehen, was passiert, wenn bei maximal detaillierter Protokollierung der Speicherplatz auf Ihrer Festplatte nahezu erschöpft ist.
Okay. Wir haben ungefähr verstanden, was wir aufbewahren möchten, aber es stellt sich die berechtigte Frage: Woher beziehen wir diese Informationen? Ein Teil der Ereignisse zum Logging wird natürlich von uns selbst durch unsere internen Prozesse generiert. Aber was tun, wenn es zu einer Interaktion mit der Außenwelt kommt? Um nicht in ein Chaos aus Notlösungen und eigenen Erfindungen abzurutschen, hat Veeam die Tendenz, bereits erfundene Lösungen nicht neu zu erfinden. Immer wenn ein bestehendes API, eine integrierte Systemfunktion, eine Bibliothek usw. vorhanden ist, ziehen wir es vor, diese vorhandenen Optionen zu nutzen, bevor wir beginnen, unsere eigenen ausgeklügelten Lösungen zu entwickeln. Obwohl es davon auch genügend gibt. Daher ist es bei der Analyse von Logs wichtig zu verstehen, dass der Großteil der Fehler auf Nachrichten von Drittanbieter-APIs, Systemaufrufen und anderen Bibliotheken zurückzuführen ist. In diesem Fall besteht die Rolle von VBR darin, diese Fehler unverändert in die Logdateien weiterzuleiten. Die Hauptaufgabe des Benutzers ist es daher, zu lernen, welche Zeile von wem stammt und wofür dieser „jemand“ verantwortlich ist. Wenn der Fehlercode aus dem VBR-Log Sie auf eine MSDN-Seite führt, ist das normal und korrekt.
Wie bereits zuvor besprochen: Veeam ist eine sogenannte SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und alles, was für ein reibungsloses Funktionieren notwendig ist, in seiner Datenbank gespeichert werden. Daraus ergibt sich eine einfache Wahrheit: Was nicht in den Logs steht, ist höchstwahrscheinlich in der Datenbank vorhanden. Aber das ist keine Allheilmittel: Manches findet sich weder in den lokalen Logs der Veeam-Komponenten noch in seiner Datenbank. Daher muss man lernen, die Logs des Hosts, die Logs der lokalen Maschine und die Logs von allem, was am Backup- und Restore-Prozess beteiligt ist, zu analysieren. Es kann sogar vorkommen, dass die benötigten Informationen überhaupt nirgends zu finden sind. So ist der Weg.
Einige Beispiele für solche APIs
Diese Liste hat nicht das Ziel, vollständig zu sein, also suchen Sie darin bitte nicht nach der letzten Wahrheit. Ihr Zweck ist es lediglich, die häufigsten externen APIs und Technologien zu zeigen, die in unseren Produkten verwendet werden.
Lassen Sie uns beginnen mit VMware.
An erster Stelle steht vSphere API. Wird für die Authentifizierung, das Lesen von Hierarchien, das Erstellen und Löschen von Snapshots, das Abfragen von Informationen über Maschinen und vieles (sehr vieles) mehr verwendet. Die Funktionalität ist sehr umfangreich, deshalb kann ich allen Interessierten die VMware vSphere API Referenz für die Version empfehlen. und . Für aktuellere Versionen lässt sich alles einfach googeln.
VIX API. Schwarze Magie des Hypervisors, für die es eine separate . VMware API, um Dateien auf dem Host ohne Netzwerkverbindung zu bearbeiten. Eine letzte Rettung, wenn eine Datei auf eine Maschine übertragen werden muss, für die es keinen besseren Kommunikationskanal gibt. Es ist eine mühsame Angelegenheit, wenn die Datei groß ist und der Host stark ausgelastet. Aber hier gilt die Regel, dass selbst 56,6 kB/s besser sind als 0 kB/s. In Hyper-V nennt sich solch eine Funktion PowerShell Direct. Doch das war nur bis zum Erscheinen von
vSphere Web Services API . Seit vSphere 6.0 (ungefähr, da diese API erstmals in Version 5.5 vorgestellt wurde) wird sie zur Verwaltung von Gastmaschinen verwendet und hat mittlerweile praktisch die VIX abgelöst. Im Grunde genommen ist dies eine weitere API zur Verwaltung von vSphere. Interessierten kann ich empfehlen, sich das Handbuch anzusehen.
VDDK (Virtual Disk Development Kit). Eine Bibliothek, die teilweise bereits erwähnt wurde in dieser . Sie dient zum Lesen virtueller Festplatten. Ursprünglich war sie Teil von VIX, wurde jedoch im Laufe der Zeit in ein separates Produkt ausgegliedert. Als Erbe verwendet sie die gleichen Fehlercodes wie VIX. Aber aus irgendeinem Grund gibt es im SDK keine Beschreibung dieser Fehler. Daher wurde durch Erfahrung herausgefunden, dass VDDK-Fehler mit anderen Codes lediglich eine Translaterisierung von binär in dezimalen Code darstellen. Sie besteht aus zwei Teilen – die erste Hälfte ist nicht dokumentierte Informationen über den Kontext, und der zweite Teil sind die traditionellen VIX/VDDK-Fehler. Zum Beispiel, wenn wir sehen:
VDDK-Fehler: 21036749815809.Unknown error
Dann können wir das problemlos in hex konvertieren und erhalten 132200000001. Den uninformativ wirkenden Anfang 132200 lassen wir einfach weg, und der Rest ist unser Fehlercode (VDDK 1: Unknown error). Über die häufigsten VDDK-Fehler gab es kürzlich einen separaten .
Jetzt schauen wir uns Windows.
Hier finden wir alles Wichtige und Notwendige in der Standard- Ereignisanzeige. Aber es gibt einen Haken: Traditionell protokolliert Windows nicht den vollständigen Fehlertext, sondern nur die Nummer. Zum Beispiel, Fehler 5 steht für „Zugriff verweigert“, Fehler 1722 bedeutet „Der RPC-Server ist nicht verfügbar“ und 10060 steht für „Verbindung zeitüberschreitet“. Natürlich ist es hilfreich, wenn du die bekanntesten kennst, aber was ist mit den bisher unbekannten?
Und um das Leben nicht zu süß zu machen, werden die Fehler auch in hexadezimaler Form gespeichert, mit dem Präfix 0x8007. Zum Beispiel ist 0x8007000e tatsächlich 14, Ausnahmespeicher. Warum und für wen das gemacht wurde, bleibt ein Geheimnis. Den vollständigen Fehlercode kann man jedoch kostenlos und ohne SMS herunterladen von .
Übrigens gibt es manchmal auch andere Präfixe, nicht nur 0x8007. In so einem traurigen Fall muss man für das Verständnis von HRESULT („Result Handle“) noch tiefer in die Materie eintauchen für Entwickler. Im Alltag würde ich dir so etwas nicht empfehlen, aber falls du mal in der Klemme steckst oder einfach nur neugierig bist, weißt du jetzt, was zu tun ist.
Aber die Kollegen bei Microsoft haben ein wenig Mitleid mit uns gehabt und die Utility . Es ist ein kleines Stück Konsolen-Glück, das Fehlercodes in eine verständliche Sprache übersetzen kann, ohne Google verwenden zu müssen. Es funktioniert ungefähr so.
C:UsersrootDesktop>err.exe 0x54f
# für hex 0x54f / dezimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ein interner Fehler ist aufgetreten.
# als HRESULT: Schwere: ERFOLG (0), FACILITY_NULL (0x0), Code 0x54f
# für hex 0x54f / dezimal 1359
ERROR_INTERNAL_ERROR winerror.h
# Ein interner Fehler ist aufgetreten.
# 2 Übereinstimmungen für "0x54f" gefundenEs stellt sich die berechtigte Frage: Warum schreiben wir die Entschlüsselung nicht sofort in die Logs, sondern belassen es bei diesen mysteriösen Codes? Die Antwort liegt in externen Anwendungen. Wenn du selbst einen WinAPI-Aufruf machst, ist es einfach, die Antwort zu entschlüsseln, denn dafür gibt es sogar einen speziellen WinAPI-Aufruf. Aber wie bereits erwähnt, kommt alles, was wir in den Antworten erhalten, in unsere Logs. Und hier müsste man ständig diesen Fluss des Bewusstseins überwachen, die Fehlerteile herausfiltern, sie entschlüsseln und zurückfügen. Ehrlich gesagt, das ist nicht gerade eine fesselnde Aufgabe.
Windows Dateiverwaltungs-API wird bei der Arbeit mit Dateien vielfältig eingesetzt. Erstellung von Dateien, Löschung, Öffnung zum Schreiben, Arbeit mit Attributen und so weiter.
Oben erwähnt PowerShell Direct wie das VIX API in der Hyper-V-Welt. Leider nicht so flexibel: es gibt zahlreiche funktionale Einschränkungen, es funktioniert nicht mit jeder Hostversion und weit nicht mit allen Gästen.
RPC (Remote Procedure Call) Ich glaube, dass es keinen einzigen Menschen gibt, der mit Windows gearbeitet hat und nicht schon einmal auf RPC-Fehler gestoßen wäre. Trotz eines weit verbreiteten Missverständnisses ist es kein einheitliches Protokoll, sondern jedes Client-Server-Protokoll, das eine Reihe von Parametern erfüllt. Wenn jedoch in unseren Protokollen ein RPC-Fehler auftritt, handelt es sich in 90 % der Fälle um einen Microsoft RPC-Fehler, der Teil von DCOM (Distributed Component Object Model) ist. Im Netz findet man eine enorme Menge an Dokumentation zu diesem Thema, allerdings ist der größte Teil davon stark veraltet. Wenn jedoch ein drängendes Verlangen besteht, das Thema zu studieren, kann ich Artikel empfehlen. , und eine lange Liste .
Häufigste Ursachen für RPC-Fehler in unseren Protokollen sind fehlgeschlagene Interaktionen zwischen VBR-Komponenten (Server > Proxy, beispielsweise) und meist aufgrund von Kommunikationsproblemen.
Der Spitzenreiter unter den Fehlern ist der RPC-Server ist nicht verfügbar (1722). Einfach ausgedrückt bedeutet dies, dass der Client keine Verbindung zum Server herstellen konnte. Es gibt keine einheitliche Antwort auf das Wie und Warum, aber typischerweise handelt es sich um ein Authentifizierungsproblem oder ein Netzwerkproblem zum Port 135. Letzteres ist typisch für Infrastrukturen mit dynamischer Portzuweisung. Zu diesem Thema gibt es sogar . Microsoft hat einen zur Fehlersuche veröffentlicht.
Der zweithäufigste Fehler: Es sind keine weiteren Endpunkte vom Endpunkt-Mapper verfügbar (1753). Der RPC-Client oder -Server konnte keinen Port zuweisen. Dies tritt typischerweise auf, wenn der Server (in unserem Fall die virtuelle Maschine) so konfiguriert ist, dass er Ports aus einem engen Pool dynamisch zuweist, dessen Kapazität erschöpft ist. Und aus der Sicht des Clients (in unserem Fall des VBR-Servers) bedeutet das, dass unser VeeamVssAgent entweder nicht gestartet wurde oder nicht als RPC-Schnittstelle registriert wurde. Auch zu diesem Thema gibt es .
Um die Top-3-Fehler im RPC abzuschließen, erinnern wir uns an den Fehler "RPC function call failed (1726)". Dieser tritt auf, wenn die Verbindung hergestellt wurde, aber RPC-Anfragen nicht verarbeitet werden. Zum Beispiel, wenn wir Informationen über den Status von VSS anfragen (vielleicht wird gerade eine Schattenkopie erstellt und wir versuchen, darauf zuzugreifen), und stattdessen erhalten wir Stille und Ignoranz.
Windows Tape Backup API ist erforderlich, um mit Bandbibliotheken oder -laufwerken zu arbeiten. Wie ich zu Beginn erwähnte: Es macht uns keinen Spaß, eigene Treiber zu schreiben und dann mit der Unterstützung jedes Geräts zu kämpfen. Deshalb gibt es bei Vima keine eigenen Treiber. Alles erfolgt über die Standard-API, deren Unterstützung von den Hardwareanbietern selbst bereitgestellt wird. So ist es doch viel logischer, oder?
SMB/CIFS Es ist eine Gewohnheit, sie nebenbei zu schreiben, obwohl sich nicht viele daran erinnern, dass CIFS (Common Internet File System) einfach eine private Version von SMB (Server Message Block) ist. Daher ist es nicht falsch, diese Begriffe zu verallgemeinern. Samba hingegen ist die Linux/Unix-Implementierung und hat ihre eigenen Besonderheiten, aber ich schweife ab. Wichtig ist: Wenn Veeam darum bittet, etwas unter einem UNC-Pfad (serverdirectory) zu schreiben, verwendet der Server die Hierarchie der Dateisystemtreiber, einschließlich mup und mrxsmb, um auf die Freigabe zu schreiben. Folglich werden auch diese Treiber Fehler generieren.
Man kommt nicht umhin Winsock API. Wenn etwas über das Netzwerk gemacht werden muss, kommuniziert VBR über das Windows Socket API, allgemein bekannt als Winsock. Wenn wir also im Protokoll eine Verbindung IP:Port sehen, ist das es. In der offiziellen Dokumentation gibt es eine ganz passable Liste möglicher .
Oben erwähnt WMI (Windows Management Instrumentation) – das ist eine Art omnipotentes API zur Verwaltung von allem und jedem in der Windows-Welt. Beispielsweise erfolgen fast alle Anfragen an den Hyper-V-Host über dieses API. Das heißt, es ist ein völlig unersetzliches und sehr leistungsfähiges Tool. Bei dem Versuch zu helfen, herauszufinden, wo und was kaputt ist, hilft das integrierte Tool WBEMtest.exe enorm.
Und der letzte auf der Liste, aber keineswegs der Unwichtigste — VSS (Volume Shadow Storage). Das Thema ist so umfassend und mysteriös, wie die Menge an Dokumentation, die darüber geschrieben wurde. Shadow Copy lässt sich am besten als eine spezielle Art von Snapshot verstehen, und genau das ist es auch. Dank ihm können in VMware anwendungskonsistente Backups erstellt werden, und in Hyper-V ist es sogar fast alles möglich. Ich plane, einen separaten Artikel mit einem Überblick über VSS zu erstellen, aber bis dahin können Sie versuchen, zu lesen. Seien Sie jedoch vorsichtig, da der Versuch, VSS im Vorbeigehen zu verstehen, zu Gehirnverletzungen führen kann.
Damit können wir wohl auch aufhören. Ich betrachte die Aufgabe, die grundlegendsten Dinge zu erklären, als erfüllt, und im nächsten Kapitel werden wir uns die Protokolle ansehen. Wenn Sie jedoch Fragen haben, zögern Sie nicht, diese in den Kommentaren zu äußern.
Quelle: habr.com
