Woher kommen die Logs? Veeam Log Diving

Wir setzen unser Eintauchen in die faszinierende Welt des Troubleshootings von Logs fort. In vorherigen Artikel haben wir uns auf die Bedeutung grundlegender Begriffe geeinigt und einen kurzen Blick auf die allgemeine Struktur von Veeam als einer einzigen Anwendung geworfen. Die Aufgabe besteht darin, zu verstehen, wie Logdateien erstellt werden, welche Informationen sie enthalten und warum sie so aussehen, wie sie aussehen.

Was denken Sie, was sind eigentlich diese "Logs"? Die meisten sind der Meinung, dass Logs jeder Anwendung die Rolle einer allmächtigen Entität zugewiesen werden sollten, die die meiste Zeit irgendwo im Hintergrund dahinvegetiert, aber im entscheidenden Moment aus dem Nichts in strahlender Rüstung erscheint und alle rettet. Das heißt, sie sollten alles enthalten, von den kleinsten Fehlern in jedem Bestandteil bis hin zu einzelnen Datenbanktransaktionen. Und nach einem Fehler sollte sofort vermerkt werden, wie man ihn behebt. Und all dies sollte in ein paar Megabyte passen, nicht mehr. Es ist doch nur Text! Textdateien können doch nicht Dutzende von Gigabyte in Anspruch nehmen, das habe ich irgendwo gehört!

So, Logs

Im realen Leben sind Logs lediglich Archive diagnostischer Informationen. Und was dort gespeichert wird, woher die Informationen für die Speicherung kommen und wie detailliert sie sein müssen, entscheiden die Entwickler selbst. Einige gehen den minimalistischen Weg und speichern nur Einträge auf dem Niveau EIN/AUS, während andere alles sorgfältig zusammentragen, was sie nur erreichen können. Es gibt jedoch auch eine Zwischenlösung mit der Möglichkeit, das sogenannte Logging Level auszuwählen, bei dem man selbst angibt, wie detailliert die Informationen, die man speichern möchte, sein sollen und wie viel Platz man auf den Festplatten hat =) VBR hat übrigens sechs solcher Stufen. Und glauben Sie mir, Sie möchten nicht sehen, was passiert, wenn man mit der maximalen Detailgenauigkeit loggt und gleichzeitig freien Speicherplatz auf Ihrer Festplatte hat.

Gut. Wir haben ungefähr verstanden, was wir speichern möchten, aber es stellt sich die berechtigte Frage: Woher nehmen wir diese Informationen? Einige Ereignisse für das Logging werden natürlich von unseren internen Prozessen selbst generiert. Aber was ist zu tun, wenn wir mit einer externen Umgebung interagieren? Um nicht in einen schrecklichen Strudel aus Notlösungen und Arbeit zu geraten, hat Veeam die Tendenz, bereits erfundene Lösungen nicht neu zu erfinden. Immer wenn eine bestehende API, eine integrierte Funktion im System, eine Bibliothek usw. verfügbar ist, geben wir den bevorzugten Lösungen den Vorzug, bevor wir unsere eigenen ausgeklügelten Lösungen entwickeln. Obwohl es davon auch genug gibt. Daher ist es beim Analysieren von Logs wichtig zu verstehen, dass der Löwenanteil der Fehler auf Meldungen von Drittanbieter-APIs, Systemaufrufen und anderen Bibliotheken zurückzuführen ist. In diesem Fall besteht die Rolle von VBR darin, diese Fehler so, wie sie sind, in die Logdateien weiterzuleiten. Die Hauptaufgabe des Benutzers besteht darin, zu lernen, welche Zeile von wem stammt und wofür dieses „wer“ verantwortlich ist. Daher ist es normal und richtig, wenn der Fehlercode aus dem VBR-Log auf eine MSDN-Seite verweist.

Wie bereits zuvor vereinbart: Veeam ist eine sogenannte SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und alles, was für ein normales Funktionieren erforderlich ist, in seiner Datenbank gespeichert wird. Daraus folgt eine einfache Wahrheit: Was nicht in den Logs ist, befindet sich sehr wahrscheinlich in der Datenbank. Aber das ist auch keine universelle Lösung: Einige Dinge sind weder in den lokalen Logs der Veeam-Komponenten noch in seiner Datenbank zu finden. 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 studieren. Manchmal gibt es auch gar keine benötigten Informationen irgendwo. So ist der Weg. 

Einige Beispiele für solche APIs

Diese Liste hat nicht das Ziel, vollständig zu sein, weshalb man nicht die letzte Wahrheit darin suchen sollte. Ihre Aufgabe ist es, die häufigsten Drittanbieter-APIs und Technologien zu zeigen, die in unseren Produkten verwendet werden.

Lassen Sie uns beginnen mit VMware. 

Der erste in der Liste wird sein vSphere API. Wird verwendet für Authentifizierung, das Lesen der Hierarchie, das Erstellen und Löschen von Snapshots, das Abrufen von Informationen über Maschinen und vieles (sehr vieles) mehr. Die Funktionalität der Lösung ist sehr umfangreich, daher kann ich allen Interessierten empfehlen, die VMware vSphere API Referenz für die Version 5.5 und 6.0. Für aktuellere Versionen findet man alles leicht mit einer Google-Suche.

VIX API. Schwarze Magie des Hypervisors, für die es eine separate Fehlerliste. VMware API zur Arbeit mit Dateien auf dem Host ohne Netzwerkverbindung. Eine letzte Hoffnung, wenn man eine Datei auf einen Rechner legen muss, zu dem es keinen besseren Kommunikationskanal gibt. Das bringt Schmerzen und Leiden mit sich, wenn die Datei groß ist und der Host ausgelastet. Aber hier gilt die Regel, dass selbst 56,6 Kb/s besser ist als 0 Kb/s. In Hyper-V wird so etwas PowerShell Direct genannt. Aber das war nur bis zum Erscheinen

des vSphere Web Services API Seit vSphere 6.0 (ungefähr, da dieses API erstmals in Version 5.5 vorgestellt wurde) wird es zur Verwaltung von Gastmaschinen verwendet und hat VIX mittlerweile praktisch überall verdrängt. Im Grunde genommen ist es ein weiteres API zur Steuerung von vSphere. Interessierten kann ich empfehlen, das zu studieren eine ausgezeichnete Dokumentation. 

VDDK (Virtual Disk Development Kit). Eine Bibliothek, über die teilweise in diesem Artikel. Wird zur Lesung virtueller Festplatten verwendet. Vor langer Zeit war es Teil von VIX, wurde jedoch mit der Zeit in ein eigenständiges Produkt ausgelagert. Es nutzt jedoch als Erbe 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 Übersetzung von binär in dezimal sind. Es besteht aus zwei Teilen – die erste Hälfte enthält undokumentierte Informationen zum Kontext, während der zweite Teil die traditionellen VIX/VDDK-Fehler enthält. Zum Beispiel, wenn wir sehen:

VDDK-Fehler: 21036749815809.Unbekannter Fehler

Dann konvertieren wir das einfach in hex und erhalten 132200000001. Den wenig informativen Anfang 132200 lassen wir einfach weg, und der Rest ist unser Fehlercode (VDDK 1: Unbekannter Fehler). Zu den häufigsten VDDK-Fehlern gab es kürzlich eine separate Artikel.

Jetzt schauen wir uns das Windows.

Hier finden wir alles Wichtige und Notwendige im standardmäßigen Ereignisanzeiger. Aber es gibt ein Problem: Nach alter Tradition protokolliert Windows nicht den vollständigen Text des Fehlers, sondern nur die Fehlernummer. Zum Beispiel: Fehler 5 – „Zugriff verweigert“, und 1722 – „Der RPC-Server ist nicht verfügbar“, sowie 10060 – „Die Verbindung ist abgelaufen“. Natürlich ist es gut, wenn man die bekanntesten kennt, aber wie soll man mit noch nie gesehenen umgehen? 

Um sicherzustellen, dass das Leben nicht zu süß erscheint, werden die Fehler auch in hexadezimaler Form mit dem Präfix 0x8007 gespeichert. Zum Beispiel steht 0x8007000e tatsächlich für 14, Out of Memory. Warum und für wen das gemacht wurde, bleibt ein Geheimnis. Eine vollständige Liste der Fehler kann jedoch kostenlos und ohne SMS von devcenrum.

Übrigens gibt es manchmal auch andere Präfixe und nicht nur 0x8007. In solch einer bedauerlichen Situation muss man noch tiefer in die HRESULT-Interpretation („result handle“) eintauchen Dokumentation für Entwickler. Im normalen Leben würde ich Ihnen so etwas nicht raten, aber falls Sie einmal gegen die Wand gedrängt werden oder einfach nur neugierig sind, wissen Sie jetzt, was zu tun ist.

Aber die Leute bei Microsoft haben uns ein bisschen erbarmt und die Utility ERRherausgebracht. Es ist ein kleines Stück Konsolenfreude, das in der Lage ist, Fehlercodes in verständliche Sprache zu übersetzen, ohne Google zu benutzen. 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" gefunden

Es stellt sich die berechtigte Frage: Warum schreiben wir nicht sofort die Entschlüsselung in die Logs, sondern lassen diese geheimnisvollen Codes stehen? Die Antwort ist in Drittanbieteranwendungen zu finden. Wenn Sie selbst einen bestimmten WinAPI-Aufruf tätigen, ist es nicht schwierig, dessen Antwort zu entschlüsseln, denn dafür gibt es sogar einen speziellen WinAPI-Aufruf. Aber wie bereits erwähnt, gelangen in unsere Logs alles, was wir als Antworten erhalten. Und hier müsste man diesen Bewusstseinsstrom ständig überwachen, um Stücke mit Windows-Fehlern herauszufiltern, sie zu entschlüsseln und wieder einzufügen. Um es ehrlich zu sagen, das ist kein aufregendes Unterfangen.

Windows File Management API wird bei der Arbeit mit Dateien in sämtlicher Hinsicht verwendet. Dateierstellung, -löschen, -öffnen zum Schreiben, Arbeit mit Attributen und vieles mehr.

Das oben erwähnte PowerShell Direct ist das Äquivalent zum VIX API in der Welt von Hyper-V. Leider nicht so flexibel: Es gibt viele funktionale Einschränkungen, es funktioniert nicht mit jeder Host-Version und bei weitem nicht mit allen Gästen.

RPC (Remote Procedure Call) Ich denke, es gibt keinen Menschen, der mit Windows gearbeitet hat und nicht auf RPC-bezogene Fehler gestoßen ist. Trotz weit verbreiteter Missverständnisse handelt es sich hierbei nicht um ein einheitliches Protokoll, sondern um 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 Fehler von Microsoft RPC, das Teil von DCOM (Distributed Component Object Model) ist. Im Internet findet man eine riesige Menge an Dokumentationen zu diesem Thema, allerdings ist ein Großteil davon stark veraltet. Aber wenn der Wunsch besteht, das Thema zu lernen, kann ich Artikel empfehlen Was ist RPC?, Wie funktioniert RPC und eine endlose Liste von RPC-Fehlern.

Die Hauptursachen für das Auftreten von RPC-Fehlern in unseren Protokollen sind fehlgeschlagene Versuche der Interaktion zwischen VBR-Komponenten (Server > Proxy, zum Beispiel) und häufig aufgrund von Kommunikationsproblemen.

Der König unter allen Fehlern ist der Fehler The RPC server is unavailable (1722). Einfach gesagt konnte der Client keine Verbindung zum Server herstellen. Warum das passiert, hat keine einheitliche Erklärung, aber normalerweise handelt es sich um ein Problem mit der Authentifizierung oder dem Netzwerkzugang zum Port 135. Letzteres ist typisch für Infrastrukturen mit dynamischer Portzuweisung. Zu diesem Thema gibt es sogar ein separates KB. Und von Microsoft gibt es einen umfassenden Leitfaden zur Fehlersuche.

Der zweithäufigste Fehler: There are no more endpoints available from the endpoint mapper (1753). Der RPC-Client oder -Server konnte sich keinen Port zuweisen. Dies tritt normalerweise auf, wenn der Server (in unserem Fall die Gastmaschine) für die dynamische Portzuweisung aus einem engen Bereich konfiguriert war, der erschöpft ist. Wenn wir vom Client aus (in unserem Fall vom VBR-Server) betrachten, bedeutet das, dass unser VeeamVssAgent entweder nicht gestartet wurde oder nicht als RPC-Schnittstelle registriert wurde. Auch zu diesem Thema gibt es ein separates KB.

Und um die Top-3 der RPC-Fehler abzuschließen, erinnern wir an RPC function call failed (1726). Dieser tritt auf, wenn die Verbindung hergestellt wurde, aber die RPC-Anfragen nicht bearbeitet werden. Zum Beispiel fragen wir Informationen über den Status von VSS an (vielleicht wird gerade eine Schattenkopie erstellt, während wir versuchen darauf zuzugreifen), und wir erhalten nur Stille und Ignorieren als Antwort.

Windows Tape Backup API benötigt für die Arbeit mit Bandbibliotheken oder Laufwerken. Wie ich zu Beginn erwähnt habe: eigene Treiber zu schreiben und sich dann mit der Unterstützung jedes Geräts herumzuschlagen, macht uns keinen Spaß. Deshalb gibt es bei Veeam keine eigenen Treiber. Alles läuft über die standardmäßige API, deren Unterstützung die Hardwareanbieter selbst realisieren. Das ist doch viel logischer, oder?

SMB/CIFS Alle schreiben sie aus Gewohnheit nebeneinander, obwohl sich nicht alle daran erinnern, dass CIFS (Common Internet File System) nur eine private Version von SMB (Server Message Block) ist. Es gibt also nichts Schlechtes daran, diese Konzepte zu verallgemeinern. Samba – das ist bereits die LinuxUnix-Implementierung, und dort gibt es besondere Eigenschaften, aber ich schweife ab. Was hier wichtig ist: Wenn Veeam bittet, etwas über einen UNC-Pfad (serverdirectory) zu schreiben, verwendet der Server die Hierarchie der Dateisystemtreiber, einschließlich mup und mrxsmb, um auf die Freigabe zu schreiben. Dementsprechend werden auch diese Treiber Fehler erzeugen.

Lässt sich nicht umgehen Winsock API. Wenn etwas über das Netzwerk gemacht werden muss, arbeitet VBR über die Windows Socket API, allgemein bekannt als Winsock. Wenn wir also im Protokoll die Kombination IP:Port sehen, ist das es. In der offiziellen Dokumentation gibt es eine ganz ordentliche Liste möglicher Fehler.

Das oben erwähnte WMI (Windows Management Instrumentation) – das ist eine Art Alleskönner-API zur Verwaltung von allem und jedem in der Windows-Welt. Bei der Arbeit mit Hyper-V laufen praktisch alle Anfragen an den Host genau darüber. Kurz gesagt, ein äußerst unverzichtbares Werkzeug mit sehr mächtigen Möglichkeiten. In dem Versuch, herauszufinden, wo und was kaputtgegangen ist, hilft das eingebaute Tool WBEMtest.exe sehr.

Und der letzte in der Liste, aber bei weitem nicht der unwichtigste – VSS (Volume Shadow Storage). Das Thema ist so unergründlich und geheimnisvoll, wie viel darüber dokumentiert wurde. Shadow Copy lässt sich am besten als eine besondere Art von Snapshot verstehen, der im Grunde genau das ist. Dank ihm können in VMware anwendungskonsistente Backups erstellt werden, während in Hyper-V beinahe alles getan werden kann. Ich plane, einen eigenen Artikel mit einer Art Zusammenfassung zu VSS zu erstellen, aber bis dahin könnt ihr versuchen, diese Beschreibung. Seid nur vorsichtig, denn der Versuch, VSS aus dem Stegreif zu verstehen, kann zu Gehirnerschütterungen führen.

Damit können wir wohl auch aufhören. Ich betrachte die Aufgabe, die grundlegendsten Dinge zu erklären, als erfüllt, sodass wir im nächsten Kapitel bereits die Protokolle betrachten werden. Aber wenn noch Fragen offenbleiben, zögert nicht, sie in den Kommentaren zu äußern.

Quelle: habr.com