Become a member!

Klau diesen Code: ExeWatch-Monitoring für Delphi, .NET, C++ & mehr

· 13 min read
ExeWatch Logo
🌐
Dieser Artikel ist auch in anderen Sprachen verfügbar:
🇬🇧 English  •  🇮🇹 Italiano  •  🇪🇸 Español  •  🇧🇷 Português

ExeWatch: Echtzeit-Anwendungs-Monitoring für Delphi, C++Builder, .NET, JavaScript und Python, mit integrierter KI-Engine und kostenlosem Hobby-Plan.

TL;DR: Das ExeWatch-Samples-Repository ist eine Sammlung lauffähiger Projekte, die zeigen, wie man ExeWatch in echte Anwendungen einbindet: Delphi (VCL, FMX, Android, WebBroker, DMVCFramework, Runtime Packages, Webhooks), .NET (Console, Windows Forms, Windows Service), JavaScript im Browser und C++Builder / MSVC / Python über die native DLL. Jedes Beispiel übt einen Ausschnitt des SDK, sodass du das passende Muster kopierst. Ein API-Key, kostenloser Hobby-Plan, und deine Events erscheinen innerhalb von Sekunden im Dashboard.

ExeWatch wächst, und die Community baut darauf auf

ExeWatch wächst weiter, schnell. In wenigen Monaten hat es hunderte registrierte Entwickler erreicht, die jetzt produktive Software in Delphi, C++Builder, .NET, JavaScript und Python überwachen: von Desktop-Apps und Windows-Diensten bis zu REST-APIs und kompletten Webanwendungen.

Wonach sie zuerst greifen, sagt viel darüber aus, warum sie bleiben:

  • Automatische Exception-Erfassung - unbehandelte Fehler werden abgefangen und gemeldet, mit Klasse, Nachricht und Stack.
  • Breadcrumb-Spuren - die genaue Abfolge der Aktionen, die zu einem Fehler geführt haben, automatisch an den Fehler angehängt.
  • Performance-Timings mit Avg / Min / Max / P95 - miss jede Operation und beobachte den Trend im Dashboard.
  • Nested Timing Traces - Wasserfälle im Profiler-Stil und ein aggregierter Calling-Context-Tree, um zu sehen, wohin die Zeit wirklich fließt.
  • Counter und Gauges - Geschäfts- und Laufzeitmetriken neben deinen Logs.
  • Hardware- und Geräte-Intelligenz - CPU, RAM, Festplatte, Betriebssystem, Monitore, Details mobiler Geräte.
  • Multi-Customer-Tracking - filtere jedes Log nach Kunden-ID.
  • E-Mail- und Timing-Alerts plus Webhooks - lass dich benachrichtigen oder steuere deine eigene Automatisierung, wenn etwas schiefgeht oder langsam wird.
  • Eine integrierte KI-Engine, die hilft, all das zu deuten.

Eine Funktion verdient besondere Erwähnung: die Nested Timing Traces, eine der meistgewünschten Ergänzungen und die, für die wir das meiste positive Feedback bekommen. Sie verwandelt eine flache Liste von Timings in einen Wasserfall im Profiler-Stil, der genau zeigt, wohin die Zeit geht, mit zusammengefassten Schleifen und avg/min/max/p95 pro Knoten. Jedes SDK im Repository liefert eine lauffähige Nested-Trace-Demo (GenerateInvoiceReport), sodass du einen solchen Baum in wenigen Minuten aus deiner eigenen App erzeugen kannst:

Wasserfall eines ExeWatch Nested Timing Trace für GenerateInvoiceReport: verschachtelte Operationen (LoadCustomers, Transform mit RenderRow x5, WriteFile, Flush) jeweils mit einem zur Gesamtzeit proportionalen Balken, Prozentsatz und Dauer, sowie avg/min/max/p95-Statistiken der zusammengefassten Schleifen

Wenn du die ganze Geschichte willst, wie Traces aufgebaut und visualisiert werden, lies den eigenen Artikel: ExeWatch 1.35: Nested Timing Traces.

Der schnellste Weg zu verstehen, wie das in deinem eigenen Code aussieht, ist das Samples-Repository. Gehen wir es durch.

Warum diese Beispiele zählen: echte Versionen, echte Sprachen

Dieses Repository ist nicht nur ein Marketing-Schaukasten. Es existiert, weil die Fragen real sind. Allein in den letzten Wochen bat mich ein Kunde, ExeWatch in eine Delphi-6-Anwendung einzubauen, ein anderer in ein C++Builder-10-Projekt, und ein weiterer wollte es aus einer Sprache ansteuern, die überhaupt nicht auf der üblichen Liste steht.

Auf jede dieser Anfragen gibt es hier eine Antwort, und genau das ist der Punkt: Die Beispiele sind der schnellste Weg zu sehen, welches SDK für welche Umgebung, und wie.

  • Modernes Delphi (XE8 und neuer) nutzt das native Pascal-SDK (ExeWatchSDKv1.pas + den VCL- oder FMX-Hook): die Beispiele VCL, FMX, Android, WebBroker und DMVCFramework folgen alle diesem Weg.
  • Legacy-Delphi (bis hinunter zu Delphi 6/7) und jede Version vor XE8 können die moderne Unit nicht kompilieren, also sprechen sie über die Pascal-Import-Unit ExeWatchSDKv1Imports.pas in DLLSDKCommons/ mit der nativen DLL. Dieselben Aufrufe, dasselbe Dashboard, nur an die DLL gebunden statt einkompiliert.
  • C++Builder (alt und neu) lädt dieselbe DLL dynamisch: Das Beispiel CPPBuilderWithDLLSDK/ kompiliert unverändert unter bcc32, bcc64 und bcc64x, sodass ein C++Builder-10-Projekt und ein 13er-Projekt identischen Code verwenden.
  • Andere Sprachen nutzen die DLL über ihre Standard-Windows-ABI: Die MSVC- und Python-ctypes-Beispiele belegen das Muster, das sich dann auf Rust, Go, MinGW, Clang und weiter überträgt.

Wenn also jemand fragt „Kann ich ExeWatch auf diesen alten Compiler / jene ungewöhnliche Sprache bringen?", lautet die ehrliche Antwort meist „Ja, und hier ist das Beispiel, das dir zeigt wie".

Bevor du startest: ein API-Key, keine Kreditkarte

Jedes Beispiel braucht einen gültigen API-Key. Registriere dich auf exewatch.com, lege eine Anwendung im Dashboard an und kopiere ihren Key (das Präfix hängt von der Zielplattform ab: ew_win_ Windows, ew_lin_ Linux, ew_mac_ macOS, ew_and_ Android, ew_ios_ iOS, ew_web_ Browser). Der kostenlose Hobby-Plan verlangt keine Kreditkarte und gibt dir eine Anwendung, 10.000 Events pro Monat, 7 Tage Aufbewahrung und zwei Alerts: mehr als genug, um alles hier auszuführen.

Danach ist der Ablauf immer derselbe: Projekt öffnen, deinen Key dort einsetzen, wo der Platzhalter steht, bauen, ausführen und die Events in Echtzeit im Dashboard eintreffen sehen.

Desktop- und Mobil-Clients

Das sind die Beispiele „Client auf dem Rechner eines anderen": GUI-Apps, bei denen Exception-Erfassung und Breadcrumbs am wichtigsten sind, weil du den Absturz lokal meist nicht reproduzieren kannst.

Delphi VCL (DelphiVCL/) ist der kanonische Ausgangspunkt. Ein Windows-Desktop-Formular mit einem Button pro Funktion: die fünf Log-Level, Timing, Breadcrumbs-dann-Fehler, Benutzeridentität, Tags, Counter und Gauges, plus automatische VCL-Exception-Erfassung über ExeWatchSDKv1.VCL. Logs werden vor dem Versand auf die Festplatte geschrieben, sodass nichts verloren geht, wenn die App abstürzt. Greif dazu, wenn du klassische Windows-Desktop-Software in Delphi entwickelst und den kürzesten Weg von null zu Daten willst.

uses ExeWatchSDKv1, ExeWatchSDKv1.VCL;   // VCL-Hook = automatische GUI-Exception-Erfassung

InitializeExeWatch(EXEWATCH_API_KEY, 'SampleCustomer');
EW.Info('User logged in', 'auth');
ExeWatch Delphi VCL-Beispiel: ein Button pro SDK-Funktion (Logging, Timing, Breadcrumbs, Benutzeridentität, Tags, Metriken, Nested Trace) und ein Live-Activity-Log

Delphi FMX (DelphiFMX/) spiegelt das VCL-Beispiel Funktion für Funktion, aber auf FireMonkey, sodass es Windows, macOS, Linux, iOS und Android anvisieren kann. Der einzige echte Unterschied ist die uses-Klausel: ExeWatchSDKv1.FMX statt des VCL-Hooks. Greif dazu, wenn du eine plattformübergreifende FireMonkey-App auslieferst.

uses ExeWatchSDKv1, ExeWatchSDKv1.FMX;   // FMX-Hook statt des VCL-Hooks

InitializeExeWatch(EXEWATCH_API_KEY, 'SampleCustomer');
EW.Info('User logged in', 'auth');

Delphi Android (DelphiAndroid/) ist das FMX-SDK direkt auf ein Telefon ausgerichtet. Eine schmale, scrollbare, im Code aufgebaute UI übt jeden Einstiegspunkt, inklusive Nutzung aus einem Hintergrund-Thread und Flush, und geht auf mobilspezifische Themen ein: Android-typische Device-Info, das Erfassen einer unbehandelten Exception bevor der Prozess beendet wird, und der Nachweis der Thread-Sicherheit außerhalb des UI-Threads. Greif dazu, wenn du für Android entwickelst und die gesamte API auf einem echten Gerät oder Emulator durchklicken willst.

uses ExeWatchSDKv1, ExeWatchSDKv1.FMX;

InitializeExeWatch(EXEWATCH_API_KEY, 'AndroidSample');   // Android-Key: ew_and_
EW.Info('Info message from Android', 'test');

.NET Windows Forms (DotNetWindowsForms/) ist das C#-Gegenstück: eine GUI mit Tabs, in der du den API-Key zur Laufzeit einfügst (kein Neukompilieren) und Logging, verschachtelte und parallele Timings, Device-Info, Metriken und simulierte Versions-Upgrades erkundest. Sie installiert ExeWatch.WinForms, um Application.ThreadException automatisch zu erfassen. Greif dazu, wenn deine Desktop-App WinForms ist.

ExeWatchWinForms.Install();   // erfasst Application.ThreadException, vor Application.Run()

ExeWatchSdk.Initialize(new ExeWatchConfig(apiKey, customerId));
EW.Info("User logged in", "auth");
ExeWatch .NET Windows Forms-Beispiel: API-Key zur Laufzeit eingegeben, Tabs für Logging, Timing, Device Info, User/Tags, Metrics und Updates, sowie ein Log-Ausgabefenster, das das Verbinden und Initialisieren des SDK zeigt

Server, Dienste und Web-Apps

Langlaufender, headless oder serverseitiger Code, wo Timings, Counter und strukturierter Fehlerkontext zu operativer Sichtbarkeit werden.

Delphi WebBroker (DelphiWebBroker/) ist ein kleiner REST-Server, der jeden Request in einen einzigen HandleRequest-Helfer wickelt: einen Request-Counter erhöhen, einen Breadcrumb setzen, ein Timing starten, den Handler ausführen und dann Erfolg oder Fehler erfassen (und bei einem Fehler diesen zählen, die Exception loggen und HTTP 500 zurückgeben). Sechs Demo-Endpunkte, inklusive eines ?ms=-Delays zum Erzeugen langsamer Antworten. Greif dazu, wenn du einen WebBroker-Dienst hast und Monitoring auf Request-Ebene mit einem einzigen Wrapper willst.

InitializeExeWatch(TExeWatchConfig.Create(EXEWATCH_API_KEY, 'demo_customer'));
EW.SetTag('app', 'WebBrokerSample');

// im Wrapper pro Request:
EW.IncrementCounter('http.requests', 1);
EW.StartTiming(Endpoint);
try
  Handler;
  EW.EndTiming(Endpoint, nil, True);    // Erfolg
except
  on E: Exception do
    EW.EndTiming(Endpoint, nil, False); // Fehler
end;

Delphi DMVCFramework (DelphiDMVCFramework/) ist das vollständigste serverseitige Beispiel: eine echte Web-App mit TemplatePro und HTMX, Personen-CRUD mit Live-Suche und Batch-Import, schwere Reports mit verschachtelten Timings, simulierte externe Dienste mit realistischen Fehlermodi (Zahlungs-Timeouts, 429 Rate-Limits, 502er), strukturierte Extra-Daten, Breadcrumbs, Counter und periodische Gauges. Das Bemerkenswerte ist, wie wenig es braucht: drei Zeilen in der .dpr und keine Änderungen an den Controllern. Du leitest die LoggerPro-Ausgabe von DMVCFramework über einen Callback-Appender an ExeWatch, rufst InitializeExeWatch auf und zeigst mit dem eingebauten Action-Profiler des Frameworks auf den Logger. Ab da wird jeder Request gratis geloggt und gemessen. Greif dazu, wenn du APIs oder Web-Apps mit DMVCFramework baust und tiefe Sichtbarkeit für fast keinen Code willst.

// 1. die LoggerPro-Ausgabe von DMVCFramework an ExeWatch leiten
SetDefaultLogger(CreateLogBuilderWithDefaultConfiguration.WriteToCallback
  .WithCallback(procedure(const ALogItem: TLogItem; const AFormattedMessage: string)
  begin
    if ExeWatchIsInitialized and (ALogItem.LogType > TLogType.Debug) then
      EW.Log(TEWLogLevel(Ord(ALogItem.LogType)), ALogItem.LogMessage,
        ALogItem.LogTag, ALogItem.TimeStamp, ALogItem.ThreadID);
  end).Done.Build);

// 2. initialisieren, dann 3. den eingebauten Profiler auf den Logger zeigen lassen
InitializeExeWatch(TExeWatchConfig.Create(EXEWATCH_API_KEY, 'dmvc_sample_customer'));
Profiler.ProfileLogger := Log;        // jede Action gemessen, ohne Controller-Änderungen
Profiler.WarningThreshold := 500;     // warnen, wenn eine Action > 500 ms dauert

Delphi WebHook-Empfänger (DelphiWebHookSample/) dreht die Beziehung um: Statt Daten an ExeWatch zu senden, empfängt er ExeWatch-Alert-Webhooks. Ein DMVCFramework-Controller validiert das Webhook-Token und verarbeitet das Alert-Payload, und ein begleitender trace-demo-Endpunkt erzeugt auf Anfrage einen Nested Timing Trace. Greif dazu, wenn du willst, dass Alerts deine eigene Automatisierung auslösen (Chat-Benachrichtigungen, Ticketing, Auto-Remediation) und nicht nur eine E-Mail.

// das geteilte Secret prüfen, dann auf das Alert-Payload reagieren
if Context.Request.Headers['X-ExeWatch-Token'] <> EXEWATCH_WEBHOOK_TOKEN then
  Exit(UnauthorizedResponse('Invalid token'));

AlertType := Payload.S['alert_type'];   // 'log_level', 'timing', 'health_critical'...
LogI('ExeWatch [%s] %s: %s', [AlertType, Payload.S['app_name'], Payload.S['message']]);
Result := OKResponse('Webhook received');

.NET Windows Service (DotNetWindowsService/) ist ein Worker Service mit einem Verarbeitungszyklus alle 10 Sekunden. Er zeigt das empfohlene Muster für langlaufende Dienste: in StartAsync initialisieren, jeden Zyklus in ein äußeres Timing mit verschachtelten Sub-Timings wickeln, die try/catch-Timing-Konvention nutzen, damit fehlgeschlagene Zyklen als fehlgeschlagen markiert werden, ohne den Dienst abstürzen zu lassen, Counter und Gauges senden und in StopAsync flushen. Er kann als Konsolen-App laufen oder mit sc create installiert werden. Greif dazu, wenn du Hintergrunddienste oder Daemons betreibst.

// StartAsync - einmalig beim Start des Dienstes
ExeWatchSdk.Initialize(new ExeWatchConfig(ApiKey, CustomerId) { AppVersion = "1.0.0-service-demo" });
EW.SetTag("service_name", "ExeWatchDemoService");
EW.Info("Service started", "lifecycle");

// jeder Zyklus - gemessen, Fehler markiert ohne den Dienst abstürzen zu lassen
EW.StartTiming("process_cycle", "worker");
try { /* ... Arbeit ... */ EW.EndTiming("process_cycle"); }
catch (Exception ex) {
    EW.EndTiming("process_cycle", new Dictionary<string, object> { ["error"] = ex.Message }, false);
}

.NET Console (DotNetConsole/) durchläuft die gesamte SDK-Oberfläche sequenziell, inklusive 20 gemessener Iterationen mit zufälligen Fehlern, damit das Dashboard sofort realistische Avg / Min / Max / P95 und eine Erfolgsrate zeigt. Greif dazu, wenn du einen 60-Sekunden-Smoke-Test des .NET-SDK willst, oder einen zu instrumentierenden CLI-/Batch-Job.

var config = new ExeWatchConfig(ApiKey, CustomerId) { AppVersion = "1.0.0-console-demo" };
ExeWatchSdk.Initialize(config);
EW.SetTag("environment", "development");
EW.Info("Configuration loaded successfully", "config");

Im Browser

JavaScript (JS/) ist ein einziges index.html: kein npm, kein Build-Schritt. Setze window.ewConfig mit deinem ew_web_-Key, lade das SDK vom CDN und klicke die Buttons für Logging, Timing, Breadcrumbs-dann-Fehler, Benutzeridentität, Tags und Metriken. Greif dazu, wenn du Frontend-Fehler- und Performance-Tracking auf einer einfachen Webseite oder innerhalb einer bestehenden Website willst.

<script>
  window.ewConfig = { apiKey: 'ew_web_...', customerId: 'SampleCustomer', appVersion: '1.0.0' };
</script>
<script src="https://exewatch.com/static/js/exewatch.v1.min.js"></script>
<script>
  ew.info('User signed in', 'auth');   // das globale 'ew' ist bereit, sobald das SDK geladen ist
</script>

C, C++ und jede Sprache, die eine DLL aufrufen kann

ExeWatch liefert eine native DLL, die eine bewusst langweilige Windows-ABI exportiert: extern "C" + __stdcall + wchar_t* + #pragma pack(1). Das macht sie aus fast allem nutzbar. Alle diese Beispiele laden sie dynamisch mit LoadLibrary + GetProcAddress, was den klassischen .lib-vs-.a-Import-Library-Konflikt umgeht und die App auch dann sauber starten lässt, wenn die DLL fehlt.

C++Builder (CPPBuilderWithDLLSDK/) ist eine VCL-App, die die DLL über das gemeinsame Paar ExeWatchSDKv1.h + ExeWatchSDKv1.dynload.c ansteuert. Ein einziges #define EW_DYNAMIC_LOAD macht aus jedem ew_* einen Funktionszeiger, und derselbe Quellcode kompiliert unter bcc32, bcc64 und bcc64x. Greif dazu, wenn du in C++Builder arbeitest und Kämpfe mit dem Linker vermeiden willst.

#define EW_DYNAMIC_LOAD          // jedes ew_* wird zum Funktionszeiger
#include "ExeWatchSDKv1.h"

if (ew_LoadSDK() != EW_OK) { /* DLL fehlt: eine klare Meldung anzeigen */ }
ew_Initialize(EXEWATCH_API_KEY, L"Sample C++ Customer", L"");
ew_Info(L"This is an INFO message", L"sample");
ExeWatch C++Builder VCL-Beispiel mit dem DLL SDK: dasselbe Ein-Button-pro-Funktion-Layout wie das Delphi-Beispiel, mit dem Activity-Log, das das über DLL initialisierte SDK und die sich vor einem Fehler ansammelnden Breadcrumbs zeigt

Microsoft Visual C++ (MSVCWithDLLSDK/) beweist, dass das DLL SDK keine Grenzen und keine Abhängigkeiten hat und überall und von jedem genutzt werden kann, ohne irgendetwas aus dem Embarcadero-Ökosystem: eine reine cl.exe-Konsolen-App mit einem run_msvc.cmd, das vcvars64.bat findet, kompiliert und ausführt. Sie durchläuft die gemeinsame Oberfläche (Init, Benutzer, Tags, Breadcrumbs, Timing, Counter, Gauge, Fehler mit automatisch angehängten Breadcrumbs, Flush, Shutdown). Greif dazu, wenn deine Codebasis MSVC ist, oder du einfach einen eigenständigen Quickstart willst.

#define EW_DYNAMIC_LOAD
#include "ExeWatchSDKv1.h"

ew_LoadSDK();
ew_Initialize(EXEWATCH_API_KEY, CUSTOMER_ID, APP_VERSION);
ew_SetTag(L"environment", L"dev");
ew_Info(L"Sample app started", L"startup");

Die DLL aus anderen Sprachen (SpecificScenarios/DllFromOtherLanguages/) ist die Ecke der bewiesenen Portabilität. Ein reiner Python-ctypes-Smoke-Test validiert alle fünf ABI-Achsen (Aufrufkonvention, undekorierte Namen, UTF-16-Marshalling, Struct-Packing und Callback-ABI) ohne jede Embarcadero-Spur. Das README ist eindeutig: Für eine echte Python-App solltest du das native Python-SDK-Modul nutzen, das du von der Integration-Seite des Dashboards genauso herunterlädst wie die Delphi-Units (es ist noch nicht auf PyPI, also gibt es kein pip install); dieses Beispiel existiert als Portierungsreferenz für Rust, Go, MinGW, Clang und andere FFI-fähige Laufzeitumgebungen. Greif dazu, wenn du ExeWatch aus einer ungewöhnlichen Toolchain aufrufen musst und eine verlässliche Vorlage willst.

dll = ctypes.WinDLL(dll_path)                 # stdcall-ABI, undekorierte Namen
cfg = TEWDLLConfig(); cfg.StructSize = sizeof(TEWDLLConfig)
cfg.ApiKey = EXEWATCH_API_KEY; cfg.CustomerId = CUSTOMER_ID; cfg.SampleRate = 1.0
dll.ew_InitializeEx(byref(cfg))
dll.ew_Info('Hello from Python ctypes', 'smoke')

Architektur und gezielte How-to-Szenarien

Die letzte Gruppe beantwortet konkrete Fragen, die auftauchen, sobald die Grundlagen funktionieren.

Runtime Packages (DelphiVCLWithPackages/) zeigt, dass ExeWatch mit dynamisch über LoadPackage geladenen Delphi-BPLs funktioniert. Der Trick ist, das SDK in ein eigenes Package (ExeWatchSDKPkg.bpl) zu kompilieren, sodass die globale EW-Instanz, Breadcrumbs, Tags und Benutzeridentität wirklich zwischen der Host-EXE und jeder Modul-BPL geteilt werden. Zwei Demo-Module (Customers, Orders) loggen, messen und erfassen Fehler über genau dieselbe API wie eine normale App. Greif dazu, wenn du eine modulare, Plugin-artige Delphi-Anwendung hast.

// HostApp: einmal initialisieren; das SDK lebt in ExeWatchSDKPkg.bpl, geteilt mit jedem Modul
InitializeExeWatch(TExeWatchConfig.Create(APP_API_KEY, APP_CUSTOMER_ID));
EW.SetTag('app_type', 'runtime_packages');

// in einer dynamisch geladenen Modul-BPL - dieselbe globale EW, kein zusätzliches Setup
EW.Info('Customer added: ' + CustomerName, 'customers');

Breadcrumbs-Nutzung (SpecificScenarios/BreadcrumbsUsage/) klärt in einem einzigen Projekt die drei häufigsten Breadcrumb-Fragen: Verteile Breadcrumbs dort, wo die Aktionen passieren (bündele sie nicht), unbehandelte Exceptions hängen sie automatisch an, während gefangene deinen EW.Error-Aufruf brauchen, und nur Error- und Fatal-Logs tragen Breadcrumbs (Info / Warning / Debug nicht). Vier Buttons machen jede Regel im Dashboard sichtbar. Greif dazu, wenn du Breadcrumbs auf Anhieb richtig machen willst.

EW.AddBreadcrumb(btClick, 'ui', 'Clicked "Save" button');
try
  FakeSaveToDatabase;   // löst eine Exception aus
except
  on E: Exception do
    EW.ErrorWithException(E, 'settings');  // Breadcrumbs hängen sich an diesen Error an
end;

Initiale Custom-Device-Info (SpecificScenarios/InitialCustomDeviceInfo/) beantwortet ein subtiles Startup-Problem: Wie hängst du Tags und Umgebungs-Metadaten (RDP-Sitzung, Terminal Server, Desktop-Modus) an das allererste Event an, das während der Initialisierung gesendet wird? Die Antwort sind zwei Konfigurationsfelder, GlobalTags für Daten, nach denen du Logs filterst, und InitialCustomDeviceInfo für Details, die das Gerät beschreiben. Greif dazu, wenn du den Kontext schon ab der ersten Log-Zeile brauchst.

Config := TExeWatchConfig.Create(EXEWATCH_API_KEY, 'SampleCustomer');
Config.GlobalTags := [TPair<string, string>.Create('session_type', SessionType)];
Config.InitialCustomDeviceInfo := [
  TPair<string, string>.Create('screen_res',  DetectScreenResolution),
  TPair<string, string>.Create('color_depth', DetectColorDepth)];
InitializeExeWatch(Config);   // die Tags schon ab dem ersten Event vorhanden

madExcept-Integration (SpecificScenarios/madExceptIntegration/) ist für alle, die bereits madExcept nutzen. Eine einzige Bridge-Unit registriert einen madExcept-Callback und leitet jede Exception an ExeWatch weiter, mit dem bereits von madExcept symbolisierten Stack (Unit-Namen und Zeilennummern) statt der rohen Adressen, die das SDK in einem Release-Build erfassen würde. Sie zeigt auch das EurekaLog-Äquivalent. Greif dazu, wenn du durchsuchbare, lesbare Stacks im Dashboard willst und die Symbolisierung ohnehin schon zur Link-Zeit bezahlst.

procedure ExeWatchMadExceptHandler(const ExceptIntf: IMEException; var Handled: Boolean);
var ExtraData: TJSONObject;
begin
  ExtraData := TJSONObject.Create;
  ExtraData.AddPair('stack_trace', ExceptIntf.BugReport);  // von madExcept aufgelöster Stack
  EW.Log(llError, ExceptIntf.ExceptMessage, 'exception', ExtraData);
end;

initialization
  RegisterExceptionHandler(ExeWatchMadExceptHandler, stDontSync);
ExeWatch und madExcept im Zusammenspiel: der madExcept-Bugreport-Dialog läuft weiterhin für die abgefangene Exception
Dieselbe Exception im ExeWatch-Dashboard, mit dem von madExcept aufgelösten Stack Trace (Unit-Namen und Zeilennummern) statt roher Adressen

Eine API, viele Laufzeiten

Der Grund, warum eine Tour wie diese kurz bleibt, ist, dass die API überall bewusst dieselbe ist. Initialize, Info / Warning / Error, AddBreadcrumb, StartTiming / EndTiming, SetUser, SetTag, IncrementCounter / RecordGauge, und automatische Exception-Erfassung: die Schreibweise verschiebt sich ein wenig zwischen Delphi, C#, JavaScript und der C-DLL, aber die Konzepte und das Dashboard sind identisch. Lern sie in einem Beispiel, und du kennst sie in allen.

Klone das Repo, wähle das Projekt, das deinem Stack am nächsten ist, setze deinen Key ein, und du hast in ein paar Minuten echte Daten vor dir.

ExeWatch: Application Performance Monitoring für Server-, Desktop- und Webanwendungen, mit einer integrierten Engine für Künstliche Intelligenz. Erstellt von bit Time Professionals.

Tags

Comments

comments powered by Disqus