Become a member!

ExeWatch 1.30: SDKs für C++Builder, MSVC und Delphi vor XE8, Global Tags und Alerts pro Kunde

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

TL;DR: ExeWatch 1.30 ergänzt native Unterstützung für C++Builder, Microsoft Visual C++ und die Delphi-Versionen 4 bis XE7 über ein neues DLL-basiertes SDK. Es führt Global Tags ein, die automatisch an jedes Log angehängt werden, sowie den Alert-Filter pro einzelnem Kunden. Hinzu kommen WaitForSending, um explizit auf den Versand der eingereihten Logs zu warten, Thread-lokale Timings, Isolation der File-Queue pro Anwendung und E-Mail-Benachrichtigungen bei 80% und 100% des monatlichen Event-Kontingents. Alles in jedem Plan enthalten. Jetzt ausprobieren auf exewatch.com

Highlights des Releases

  • 🆕 Neues DLL-basiertes SDK für C++Builder, Microsoft Visual C++ (MSVC), MinGW, Clang und Delphi 4–XE7
  • 🏷️ Global Tags: Schlüssel-Wert-Paare, automatisch an jedes Log der Sitzung angehängt (Delphi nativ + JavaScript)
  • 🎯 Alert-Filter pro Customer-ID: Log-Level- und Timing-Alert-Regeln, einschränkbar auf einen einzelnen Kunden
  • ⏱️ WaitForSending in allen SDKs: API zum expliziten Warten auf das Leeren der Log-Queue
  • 🧵 Thread-lokale Timings in Delphi, .NET und Python: jeder Thread führt seinen eigenen Timing-Stack
  • 📁 Isolation der File-Queue pro Anwendung: dediziertes Unterverzeichnis identifiziert durch den API-Key
  • 📧 E-Mail-Benachrichtigungen zum monatlichen Event-Kontingent: Warnung bei 80%, harte Grenze bei 100%
  • 🚀 DLL-ABI auf Version 3 angehoben, abgestimmt auf WaitForSending

Ein Release, das den Horizont erweitert

Seit ExeWatch vorgestellt wurde, hat die Reaktion der Community alle unsere Erwartungen übertroffen. Jede Woche erreichen uns Integrationsanfragen, Berichte zu Anwendungsszenarien, an die wir nicht gedacht hatten und vor allem Fragen der Art „Ist euer SDK auch für … verfügbar?". Das ist die direkteste Bestätigung, dass ein Produkt wie ExeWatch von Entwicklern benötigt und gefordert wurde, die Anwendungen schreiben, die „außerhalb des Browsers" laufen: an erster Stelle Delphi- und C++Builder-Entwickler, aber im Allgemeinen jeder, der Desktop-Software, Windows-Dienste, Industrieanwendungen und technisches Tooling entwickelt, also jene Welt, in der Produktions-Logs historisch schwer zu bekommen sind und in der cloud-native APMs, die für Microservices gedacht sind, sich einfach nicht eingliedern lassen.

Die Releases von ExeWatch sind einem klaren Bogen gefolgt: zuerst die Konsolidierung des Kerns (Logging, Timing, Breadcrumbs, Device Info), dann die Erweiterung um neue Sprachen (Delphi, dann .NET, JavaScript, Python) und schließlich die Reifung der „Produkt"-Funktionen (Custom Metrics, Health Monitoring, Usage Analytics).

Mit 1.30 machen wir einen weiteren wichtigen Schritt in zwei Richtungen, die sich verzahnen:

  1. Mehr nativ unterstützte Sprachen und Umgebungen: Die Unterstützung für C++Builder und Microsoft Visual C++ kommt über das neue DLL-basierte SDK. Derselbe Mechanismus öffnet ExeWatch auch für die Delphi-Versionen 4 bis XE7 (das native Delphi-SDK ExeWatchSDKv1.pas setzt weiterhin Delphi XE8 oder höher voraus).
  2. Feinere Kontrolle über bestehende Funktionen: Global Tags, die in jedem Log mitgeführt werden, Alert-Filter pro einzelnem Kunden, explizites Handling des Shutdowns, Isolation pro Anwendung.

Diese Neuerungen kommen größtenteils aus dem Feedback von Enterprise-Kunden, die ExeWatch auf umfangreichen Maschinenparks in Produktion einsetzen. Sobald integriert, stehen sie aber in allen Plänen zur Verfügung, vom kostenlosen Hobby bis Business.

DLL-basiertes SDK: Legacy-Delphi, C++Builder und Microsoft Visual C++

Mit großem Abstand die häufigste Anfrage, die wir seit dem Start von ExeWatch erhalten, ist: „Kann ich es auch mit Delphi-Versionen vor XE8 nutzen?". Das native SDK ExeWatchSDKv1.pas nutzt Sprachfeatures (Generics, Anonymous Methods, Namespaces mit Punkten), die in älteren Compilern nicht verfügbar sind, und Delphi 4, 5, 6, 7, 2007, 2009, 2010 sind heute noch in Produktion auf wichtigen Maschinenparks zu finden, insbesondere im industriellen, wirtschaftlichen und wissenschaftlichen Umfeld.

Die Antwort der 1.30 ist ein neues DLL-basiertes SDK, das die Kompilierung des Clients vollständig vom Compiler des Nutzerprojekts entkoppelt. Die Logik lebt in ExeWatchSDKv1DLL.dll (in zwei Varianten verteilt, 32 und 64 Bit) und das Nutzerprojekt verbindet sich damit über eine eigene Import-Unit, ExeWatchSDKv1Imports.pas, die ab Delphi 5 funktioniert. Die Import-Unit löst die Unterschiede zwischen AnsiString und WideString, zwischen alten und modernen Namespaces, zwischen IInterface und IUnknown intern auf.

// Delphi 5, 6, 7, 2007 und 2009: derselbe Code, dieselbe API
uses
  ExeWatchSDKv1Imports;

procedure InitMyApp;
begin
  ew_Initialize('ew_win_your_key', 'ACME-Corp', '1.0.0');
  ew_Info('App started', 'startup');
end;

Sobald der DLL-Mechanismus im Haus war, war die Erweiterung in eine zweite Welt ein natürlicher Schritt: C++Builder und Microsoft Visual C++ (MSVC). Die DLL ist eine Standard-Windows-Binärdatei, aufrufbar aus jeder Sprache, die C-Funktionen aufrufen kann. Wir kombinieren sie mit einem C-Header, der sowohl per Static Link als auch per dynamischem Laden via LoadLibrary nutzbar ist, und einem fertigen Loader, den man einfach ins Projekt aufnimmt:

// ExeWatchSDKv1.h: Static Link oder dynamisches Laden
#include "ExeWatchSDKv1.h"

int main(int argc, char** argv) {
    EWConfig cfg = {0};
    cfg.api_key      = "ew_win_your_key";
    cfg.customer_id  = "ACME-Corp";
    cfg.app_version  = "1.0.0";

    if (ew_Initialize(&cfg) != EW_OK) {
        fprintf(stderr, "ExeWatch init failed\n");
        return 1;
    }

    ew_Info("MSVC console starting", "startup");

    ew_StartTiming("invoice.generate", "pdf");
    // ... eigentliche Arbeit ...
    ew_EndTiming("invoice.generate");

    ew_WaitForSending(5);  // vor dem Beenden auf Flush warten (max. 5s)
    ew_Shutdown();
    return 0;
}

Derselbe Header mit demselben Loader funktioniert unter Windows ohne Unterschied mit C++Builder, MSVC, MinGW und Clang. Keine besonderen Build-Systeme oder externe Abhängigkeiten erforderlich: Die DLL ist autark, und auf Projektseite reicht eine einzelne .c-Datei (der Header ExeWatchSDKv1.h und die bereits mitgelieferte Loader-Implementierung).

Operativ wurde die DLL-ABI auf Version 3 angehoben, im Einklang mit der neuen WaitForSending-API. Wer auf Version 2 war, muss nur DLL und Import-Unit gemeinsam aktualisieren: Das Schema der bestehenden Aufrufe bleibt unverändert.

Global Tags: übergreifende Dimensionen in jedem Log

Die klassischen Tags in ExeWatch (tag beim Log, tag beim Timing) sind per Definition kontextuell: Sie beschreiben das einzelne Event. Aber viele Szenarien brauchen übergreifende Dimensionen, die für die gesamte Sitzung einer Anwendung gelten: den Tenant, für den sie läuft, die Region, das Build Flavor, die Umgebung, die Produktvariante.

Bisher war die Standardlösung, diese Informationen in customer_id oder extra_data mit zu transportieren. Das funktionierte, war aber repetitiv und, vor allem, im Dashboard nicht strukturiert filterbar.

Mit 1.30 kommen die Global Tags, unterstützt im nativen Delphi-SDK und im JavaScript-SDK. Du deklarierst sie einmal bei der Initialisierung, und sie werden automatisch an jedes Log angehängt:

// Delphi
InitializeExeWatch(
  EXEWATCH_API_KEY,
  ACustomerId    := 'ACME-Corp',
  AGlobalTags    := [
    TPair<string, string>.Create('tenant',     'EU-North'),
    TPair<string, string>.Create('flavor',     'Pro-Edition'),
    TPair<string, string>.Create('deployment', 'kiosk')
  ]
);

// JavaScript
ExeWatch.init({
  apiKey: 'ew_web_your_key',
  customerId: 'ACME-Corp',
  globalTags: {
    tenant: 'EU-North',
    flavor: 'Pro-Edition',
    deployment: 'kiosk'
  }
});

Ab diesem Moment trägt jedes von der Anwendung gesendete Log die drei Tags mit. Auf der Logs-Seite des Dashboards findest du einen Global Tags-Filter, mit dem du zum Beispiel nur Logs vom Tenant EU-North mit Flavor Pro-Edition siehst:

Global-Tags-Filter auf der Logs-Seite von ExeWatch: Das Dropdown zeigt die von den Anwendungen erfassten Schlüssel/Wert-Paare (environment: abi-test, environment: staging, feature_flag: new_checkout), bereit zur Verwendung als Filter

Das Dropdown „Global Tags" auf der Logs-Seite von ExeWatch listet alle vom SDK empfangenen Schlüssel/Wert-Paare auf und erlaubt das Filtern der Timeline auf einen Blick.

Es ist genau die fehlende Dimension für alle, die Multi-Tenant-Installationen oder differenzierte Releases verwalten.

Alerts mit Filter pro Customer-ID

Im selben „Feinjustierungs"-Geist haben wir einen optionalen Customer-ID-Filter sowohl zu Log-Level-Alerts als auch zu Timing-Alerts hinzugefügt.

Das Szenario ist bekannt: Du hast eine Flotte von 500 Installationen, eine davon (vielleicht ein neuer Kunde mit besonderem Setup) erzeugt wiederkehrende Fehler. Senkst du den globalen Schwellenwert, bekommst du 20 Benachrichtigungen pro Tag aus dem Rest des Parks. Lässt du ihn hoch, verpasst du das Problem beim spezifischen Kunden.

Mit dem Filter pro Kunden kannst du beides haben: eine tolerante „globale" Regel und eine kundenspezifische Regel mit niedrigem Schwellenwert und kurzem Cooldown. Wenn du einen Alert anlegst oder bearbeitest, siehst du ein neues optionales Feld Filter by Customer: Belässt du es auf der Standardoption All Customers, gilt die Regel für die gesamte Flotte; wählst du eine bestimmte Customer-ID, löst die Regel nur für diesen Kunden aus.

ExeWatch-Dialog zum Erstellen eines Log Level Alert: Das optionale Feld Filter by Customer zeigt eine Dropdown-Liste aller von der Anwendung empfangenen Customer-IDs, darunter SampleCustomer, MsvcSmokeText, BreadcrumbsSample, madExceptSample, Sample C++ Customer und DEMO-CUSTOMER

Das neue Feld „Filter by Customer" im Dialog zum Erstellen eines Log Level Alert. Dasselbe Feld ist mit demselben Verhalten auch für Timing Alerts verfügbar.

Der Filter ist sowohl bei Log Level Alerts als auch bei Timing Alerts verfügbar, mit derselben Logik: Ist eine Customer-ID gesetzt, löst die Regel nur aus, wenn das Event (Fehler oder langsames Timing) von diesem Kunden stammt; ist die Standardoption All Customers gewählt, gilt die Regel für die gesamte Flotte. Nützlich ist sie auch für das umgekehrte Muster: Benachrichtigungen nur für Pilotkunden während eines schrittweisen Rollouts einer neuen Version.

WaitForSending: explizites Warten auf den Flush

Das Log-Shipping von ExeWatch ist konzeptionell asynchron: Das Logging blockiert nie den Aufrufer, und ein dedizierter Thread kümmert sich darum, die Batches im Hintergrund an den Server zu senden. Für VCL-, FMX-, WPF- und WinForms-Anwendungen oder lange laufende Dienste ist diese Wahl ideal: Der finale Flush wird in Shutdown automatisch erledigt, wenn die Main Loop kontrolliert beendet wird.

Es gibt jedoch Szenarien, in denen der Aufrufer wissen will, dass die Queue geleert wurde, bevor er weitermacht: CLI-Skripte, die direkt nach dem Loggen eines Fehlers beenden, nächtliche Batch-Jobs, E2E-Test-Sitzungen, die Logs vor dem Schließen des Browsers übertragen müssen, Beendigung eines Windows-Dienstes als Reaktion auf einen Stop-Request. In all diesen Fällen führt 1.30 eine einheitliche API über alle SDKs hinweg ein, namens WaitForSending:

// Delphi, am Ende einer Konsolenanwendung
EW.Fatal('Unrecoverable error: ' + E.Message, 'startup');
EW.WaitForSending(5);  // maximal 5 Sekunden warten
ExitCode := 1;

// C#, am Ende eines Windows Service
EW.Fatal("Service stopping due to fatal error", "lifecycle");
EW.WaitForSending(5);
ExeWatchSdk.Shutdown();

// JS, vor dem Schließen/Neuladen der Seite
ew.fatal("Unrecoverable client error", "ui");
await ew.waitForSending(5);

# Python, Ende eines CLI-Skripts
ew.fatal("Job failed", "batch")
ew.wait_for_sending(5)

Der Rückgabewert ist die Anzahl der noch in der Queue verbliebenen Items beim Ablauf des Timeouts: Null bedeutet „alles erfolgreich versendet".

Thread-lokale Timings

Die Timing-Messungen (StartTiming / EndTiming) zählen zu den am häufigsten verwendeten Features des SDK, weil sie Code in Produktion zu nahezu null Kosten profilen lassen. Bis 1.30 teilten sich in stark Multi-Thread-lastigen Anwendungen zwei Worker, die dieselbe timing id auf unterschiedlichen Threads verwendeten, denselben internen „Slot". In Grenzfällen konnten so weniger präzise Messungen entstehen, als man eigentlich erwartete.

Mit dieser Release verwaltet das SDK einen Timing-Stack pro Thread. Jeder Thread hat seine eigene unabhängige Map der ausstehenden Timer, und Timer mit derselben id auf verschiedenen Threads sind vollständig isoliert. Das interne Verhalten ändert sich; die API nicht. Die Änderung ist in Delphi, .NET und Python verfügbar (Browser-JavaScript ist von Natur aus single-threaded, und Web Worker haben bereits einen isolierten Kontext):

// Delphi: jeder Thread hat jetzt seinen eigenen Timing-Stack
// Hinweis: StartTiming/EndTiming immer in try..finally einbetten,
// damit der Timer auch dann geschlossen wird, wenn DoHeavyWork eine Exception wirft.
TThread.CreateAnonymousThread(
  procedure
  begin
    EW.StartTiming('worker.process', 'background');
    try
      DoHeavyWork;
    finally
      EW.EndTiming('worker.process');  // schließt den Timer dieses Threads
    end;
  end).Start;

TThread.CreateAnonymousThread(
  procedure
  begin
    EW.StartTiming('worker.process', 'background');  // OK, keine Kollision
    try
      DoHeavyWork;
    finally
      EW.EndTiming('worker.process');
    end;
  end).Start;

Die logische id des Timings bleibt identisch: Im Dashboard aggregiert worker.process weiterhin korrekt die Ausführungen beider Threads. Aber intern hält jeder Thread seinen eigenen „Slot", und die Timer kommen sich nicht in die Quere.

JavaScript-SDK: vollständige Erfassung von HTTP-Fehlern

Im JavaScript-SDK gibt es zwei Erweiterungen, die die Qualität der Fehlerinformationen in Produktion verändern.

Erstens: Jedes Mal, wenn ein fetch oder XMLHttpRequest einen Status >= 400 zurückgibt, erfasst das SDK automatisch den Body der Antwort und hängt ihn als extra_data an. Das heißt, neben dem Statuscode bekommst du auch die vom Backend gelieferte Fehlermeldung, die fast immer der Schlüssel ist, um zu verstehen, was passiert ist.

Zweitens: Eine neue Callback httpErrorExtractor, mit der du anpassen kannst, was angehängt wird:

ExeWatch.init({
  apiKey: 'ew_web_your_key',
  httpErrorExtractor: (body, contentType, status, url) => {
    if (contentType?.includes('json')) {
      try {
        const parsed = JSON.parse(body);
        return {
          message: parsed.detail || parsed.error || `HTTP ${status}`,
          extra: { trace_id: parsed.trace_id }
        };
      } catch (_) { /* fall through */ }
    }
    return null;  // standardmäßig den rohen Body verwenden
  }
});

Nützlich, wenn dein Backend eine strukturierte Fehler-Payload ausliefert (z. B. FastAPI mit {"detail": "...", "trace_id": "..."}) und du willst, dass ExeWatch sie im selben Format loggt, das du auch in deinem serverseitigen Observability-Dashboard verwendest.

Isolation der File-Queue pro Anwendung

Unsichtbares Detail, wichtige Konsequenz. Auf einem Rechner, auf dem mehrere ExeWatch-Anwendungen laufen (typischerweise eine primäre Benutzeranwendung plus ein zusätzlicher Windows-Dienst oder zwei Produktvarianten auf derselben Workstation), war das Verzeichnis für Offline-Speicher bisher standardmäßig einheitlich, und die Trennung erforderte das manuelle Übergeben unterschiedlicher Pfade in der Konfiguration jedes SDK.

Ab 1.30 erstellt jede Anwendung, die das SDK initialisiert, automatisch ein eigenes Unterverzeichnis, das durch den API-Key identifiziert wird. Mehrere Anwendungen können sicher dasselbe Speicherverzeichnis verwenden, ohne zusätzliche Konfiguration.

E-Mail-Benachrichtigungen zum Event-Kontingent

Der kostenlose Hobby-Plan enthält 5.000 Events pro Monat, Pro 100.000, Business 1.000.000. Ab 1.30 erhalten der Account-Inhaber und die Team-Mitglieder eine E-Mail beim Erreichen zweier Schwellen:

  • 80% des monatlichen Kontingents (Warnung): Es bleibt Zeit, vor dem Block zu reagieren
  • 100% des monatlichen Kontingents (Limit erreicht): Weitere Logs werden bis zum monatlichen Reset nicht angenommen

Das Kontingent selbst bleibt im Dashboard sichtbar, aber die E-Mail ist das Signal, auf das viele Nutzer gewartet haben: Sie erreicht dich dort, wo du jeden Tag hinsiehst, und gibt dir die Möglichkeit zu reagieren (das Mindest-Loglevel des SDK senken, Filter setzen oder das Upgrade planen), bevor das Problem zum Block wird.

Pricing und On Premise

Die Pricing-Seite wurde um einen vierten Plan neben Hobby, Pro und Business erweitert: On Premise. Es ist kein Self-Service-Plan und wird es nie sein: Jede On-Premise-Installation von ExeWatch hat spezifische Anforderungen an Sizing, Backup, Retention und Support. Deshalb führen wir hier ein direktes Gespräch mit denen, die ihn brauchen.

Die häufigsten Fälle sind die zu erwartenden: Unternehmen, die aufgrund interner Richtlinien keine Telemetriedaten an einen Managed Service senden dürfen, regulatorische Kontexte (GxP, Healthcare, Defense) oder einfach Latenz-Anforderungen, wenn die Anwendung geografisch weit von unserem europäischen Rechenzentrum entfernt ist.

Das On-Premise-Angebot umfasst alle Funktionen des Business (inklusive AI Engine Full) plus unbegrenzte Anwendungen, Events, Retention, Alerts und Team-Mitglieder, individuelle Integrationen, dediziertes Onboarding und ein verhandeltes SLA. Details: exewatch@bittime.it.

Videos und Webinare

Wer ExeWatch „in Bewegung" sehen will, bevor er es ausprobiert, findet auf YouTube drei Videos, je nach Sprache und Stack:

  • 🇮🇹 ExeWatch: Proactive Software Monitoring (auf Italienisch): Gespräch zwischen Daniele Teti und Fabrizio Bitti über die Entstehung des Produkts, die Design-Entscheidungen und die typischen Einsatzszenarien. Die „menschliche" Vorstellung des Projekts, nützlich, bevor man die Hände schmutzig macht.

  • 🇬🇧 ExeWatch: Stop Waiting for Crash Reports and Start Solving Problems (auf Englisch): die internationale Version, gedacht für alle, die einen knappen englischsprachigen Überblick über die Vorteile eines proaktiven Monitorings gegenüber dem klassischen Modell „auf den Anruf des Kunden warten" suchen.

  • 🇮🇹 Cosa succede alla tua app .NET in produzione? Scoprilo con ExeWatch! (Live Coding) (auf Italienisch), Live von Marco Breveglieri, explizit für .NET / C#-Entwickler: Schritt-für-Schritt-Integration von ExeWatch in eine C#-Solution direkt aus Visual Studio, mit Code live. Der schnellste Einstieg, wenn dein Stack Windows + .NET ist.

Für das spanischsprachige Publikum ist bereits ein ExeWatch-Webinar auf Spanisch für Mittwoch, den 20. Mai 2026 terminiert, organisiert in Zusammenarbeit mit Delphi Studio. Zur Anmeldung einfach dieses Anmeldeformular ausfüllen.

Warum ExeWatch so weiterwächst

Was mir bei jedem Release mit so vielen Features auffällt: Keine dieser Neuerungen entstand „im stillen Kämmerlein" vor einem leeren Blatt. Jede ist das Ergebnis eines konkreten Gesprächs mit jemandem, der ExeWatch in Produktion einsetzt.

Die C++Builder- und MSVC-Unterstützung kam von Industrie-Kunden mit kritischem Legacy-C++-Code in Produktion. Die Global Tags kamen von einem Kunden mit Multi-Tenant-Installationen. Der Per-Customer-Alert-Filter kam nach einem Telefonat, in dem ein Kunde sagte: „Ich habe einen großen Nutzer, der mich mit Alerts überschüttet, aber ich kann den Schwellenwert für die anderen nicht anheben". WaitForSending entstand aus Gesprächen mit jemandem, der nächtliche Batch-Jobs auf der CLI verwaltet.

Genau deshalb sind all diese Funktionen (auch die von Enterprise-Kunden „gesponserten") ebenso im kostenlosen Hobby-Plan verfügbar. Muster, die sich im Großen zeigen, erreichen früher oder später auch kleinere Projekte: Besser, sie sind dann schon da, wenn man sie braucht.

Was kommt als Nächstes

Erwähnenswert: Das native Delphi-SDK kompiliert und läuft schon jetzt auf Delphi für Windows, Delphi für Linux und Delphi für Android, wer also FireMonkey-Anwendungen für die Mobile-Welt baut, hat ExeWatch ab sofort zur Verfügung, ohne auf ein separates SDK warten zu müssen. Der nächste Schritt in diese Richtung ist es, den Kreis mit nativen SDKs zu schließen, die unabhängig von der Delphi-Toolchain sind, für Entwickler, die mit anderen Stacks mobil entwickeln (Kotlin/Java für natives Android, Swift für iOS).

Auf der Backend-Seite arbeiten wir daran, die AI Engine um eine dritte Analysedimension zu erweitern: nicht nur Fehler und Timings, sondern auch Nutzungsmuster (Sitzungen, Traffic-Wellen, Nutzungsspitzen). Ziel ist, dass dir das Dashboard auch dann sagt „etwas hat sich geändert", wenn die Änderung kein Fehler ist, sondern eine anomale Abweichung in der Art, wie deine Kunden das Produkt nutzen.

Wenn du ExeWatch bereits nutzt, sind alle Neuerungen der 1.30 in deinem Account schon aktiv: serverseitig ist nichts zu tun. Um WaitForSending, Global Tags und das neue C/C++-SDK zu nutzen, aktualisierst du einfach das SDK auf Anwendungsseite über die Integration-Seite des Dashboards.

Wenn du es noch nicht ausprobiert hast: Der Hobby-Plan ist kostenlos und ohne Kreditkarte. Fünf Minuten genügen für die erste Integration, und meist treffen die ersten Logs im Dashboard ein, bevor du die Anleitung zu Ende gelesen hast.

ExeWatch: Application Performance Monitoring für Server-, Desktop- und Webanwendungen, mit integrierter Artificial Intelligence Engine. Entwickelt von bit Time Professionals.

Tags

Comments

comments powered by Disqus