Datadog bringt RUM-Crash-Reporting für native C- und C++-Apps

Crash-Reporting mit zwei Handler-Optionen

Datadog zufolge zeigt ein Stack-Trace allein zwar den betroffenen Code, nicht aber, was der Nutzer vor dem Absturz getan hat oder ob andere Nutzer dasselbe Problem hatten. Das neue SDK soll diese Lücke schließen, indem es Abstürze mit RUM-Sitzungen verknüpft.

Unter Linux und macOS erfasst das SDK Signale wie SIGSEGV (Speicherzugriffsfehler) und SIGABRT (Abbrüche). Unter Windows erfasst es unbehandelte strukturierte Ausnahmen. Die daraus entstehenden Crash-Reports enthalten Stack-Traces. Sobald Entwickler ihre Debug-Symbole hochgeladen haben, übersetzt die Symbolikation die Adressen im Stack-Trace in lesbare Funktionsnamen und Quellcode-Positionen.

Das SDK bietet zwei Crash-Handler:

• In-Process-Handler: Er benötigt lediglich C++17 und keine zusätzliche ausführbare Datei. Er erfasst den Stack-Trace des abstürzenden Threads und lädt den Crash-Report beim nächsten Start der Anwendung hoch.
• Out-of-Process-Handler: Er nutzt Crashpad, das Open-Source-System für Crash-Reporting, das auch Chromium verwendet. Er läuft als separater Prozess crashpad_handler und kann daher Fehler wie Stack-Überläufe und Heap-Korruption erfassen, die der In-Process-Handler möglicherweise verpasst. Außerdem erfasst er die Stack-Traces aller Threads und lädt Reports sofort hoch.

Beide Handler melden RUM-Fehler, die mit dem aktuellen RUM-Kontext zum Zeitpunkt des Absturzes angereichert sind, darunter die Sitzung und die zuletzt aktive Ansicht.

Error Tracking und Sitzungskontext

Abstürze lassen sich im Error Tracking untersuchen, das zusammengehörige Fehler zu Issues bündelt. Laut Datadog hilft das Teams dabei, wiederkehrende Abstürze zu erkennen, Einzelfälle von weit verbreiteten Fehlern zu unterscheiden und nach Auswirkungen auf Nutzer und Sitzungen zu priorisieren. Die RUM-Sitzungszeitleiste zeigt zudem die Nutzeraktionen, Ansichtsaufrufe und Netzwerkanfragen, die dem Absturz vorausgingen.

Mit dem SDK können Entwickler auch behandelte Fehler melden, die die Anwendung nicht beenden, etwa wenn eine gespeicherte Datei nicht deserialisiert werden kann oder ein nativer Client bei der Datenverarbeitung eine unerwartete Antwort erhält. Durch die Verknüpfung mit RUM-Sitzungen lassen sich auch Probleme untersuchen, die Nutzer betreffen, obwohl die App weiterläuft.

Da das SDK nicht an ein bestimmtes UI-Framework gebunden ist, definieren Entwickler selbst die Ereignisse, die abbilden, wie Nutzer mit ihrer Anwendung interagieren. Das SDK ordnet sie RUM-Sitzungen zu. Datadog nennt diese Ereignistypen:

• Views: Bildschirme oder Zustände der Anwendung, etwa ein Dokumenteditor, eine Einstellungsseite oder ein Dateibrowser
• Actions: Nutzerinteraktionen, etwa das Auswählen einer Datei, das Klicken auf eine Schaltfläche oder das Starten eines Exports
• Resources: Netzwerkanfragen und ihre Ergebnisse, einschließlich Timeouts und anderer Fehler
• Operations: mehrstufige Abläufe, etwa das Öffnen eines Dokuments, die Authentifizierung eines Nutzers oder das Hochladen einer Datei
• Long Tasks: Blockaden, die den Hauptthread über längere Zeit anhalten

In Datadogs Beispiel kann ein Nutzer ein Dokument nicht öffnen. Das Team sieht dann die Ansicht, auf der sich der Nutzer befand, die Aktion, die den Ablauf ausgelöst hat, und etwaige zugehörige Resource-Fehler. RUM-Operations können zudem nachverfolgen, ob sich das Dokument öffnen lässt und wie lange das Laden dauert.

Integration und Bedeutung für Entwickler nativer Software

Das SDK bietet eine C++-API für Codebasen mit C++17 oder neuer sowie eine C99-konforme C-API. Beide funktionieren mit nativen Build-Umgebungen, darunter CMake-basierte Projekte. Die C-API lässt sich außerdem in FFI-Bindings (Foreign Function Interface) einbinden, um Anwendungen in anderen Sprachen und Laufzeitumgebungen zu instrumentieren.

Das SDK sendet RUM-Daten direkt an Datadog, ohne dass auf dem Gerät jedes Nutzers der Datadog Agent nötig ist. Datadog nennt als Beispiel ein PC-Spiel, das so instrumentiert ist, dass es Views, Nutzeraktionen, Fehler und Operations wie das Laden eines Levels oder den Verbindungsaufbau zu einem Spieleserver erfasst. Fehler lassen sich dann in RUM untersuchen, ohne ein Plug-in für die jeweilige Spiel-Engine. Mit Tracking-Consent-Kontrollen können Teams die lokale Speicherung und das Hochladen von RUM-Daten entsprechend den Einwilligungspräferenzen der einzelnen Nutzer steuern.

Für Teams, die Desktop-Software oder Spiele ausliefern, bedeutet die Veröffentlichung, dass sich native Abstürze zusammen mit Sitzungsdaten in derselben Plattform prüfen lassen, die auch für das übrige RUM-Monitoring genutzt wird. Für den Einstieg verweist Datadog auf die Dokumentation zur Einrichtung des C++ SDK und auf das Open-Source-C++-SDK auf GitHub. Neukunden bietet Datadog eine kostenlose 14-tägige Testphase an.