Become a member!

ExeWatch 1.8: SDK .NET para WPF y WinForms, Custom Metrics, Health Monitoring y On Premise

· 8 min read
ExeWatch Logo
🌐
Este artículo también está disponible en otros idiomas:
🇬🇧 English  •  🇮🇹 Italiano  •  🇩🇪 Deutsch

TL;DR: ExeWatch 1.8 marca un paso importante: llega el SDK .NET/C# (WPF, WinForms, servicios), las custom metrics con gráficos temporales, el health monitoring automático con notificaciones, el uso compartido de aplicaciones en solo lectura y — a petición de varias empresas — la posibilidad de deployment on premise. Pruébalo en exewatch.com

ExeWatch más allá del mundo Delphi

Cuando presenté ExeWatch por primera vez, lo describía como una herramienta de monitoreo para aplicaciones Delphi. Era verdad, pero también era una visión parcial. Los fundamentos que ExeWatch ofrece — logging estructurado, timing, breadcrumbs, device info, anomaly detection — no son específicos de un lenguaje. Son necesidades universales de cualquiera que desarrolle software que corre “fuera del navegador”, donde los logs de producción han sido históricamente difíciles de obtener.

En las últimas semanas recibimos solicitudes concretas de equipos que desarrollan en C# y que buscaban algo con las mismas características de ExeWatch pero para el mundo .NET. No herramientas genéricas de APM pensadas para microservicios cloud, sino algo orientado a aplicaciones desktop, servicios Windows, WPF y WinForms.

En vez de decir “no es nuestro target”, escribimos el SDK.

SDK .NET / C#

El SDK .NET ya está disponible con feature parity respecto al de Delphi. Soporta .NET 8.0+ en Windows y cubre todos los escenarios comunes:

  • Console, WPF, WinForms, Windows Service — un único paquete base, más un hook opcional para WinForms (ExeWatch.WinForms) que captura las excepciones del thread UI
  • Zero dependencias NuGet — como el SDK Delphi, ninguna dependencia externa
  • Misma API — quien conoce el SDK Delphi se sentirá inmediatamente en casa
  • Offline persistence — los logs se guardan en disco antes del envío, con retry automático
  • Configuración server-side — flush interval, batch size y sampling rate controlables desde el dashboard sin redistribuir la aplicación

La inicialización es idéntica a la de Delphi:

using ExeWatch;

ExeWatchSdk.Initialize(new ExeWatchConfig
{
    ApiKey = "ew_win_your_key",
    CustomerId = "ACME-Corp"
});

EW.Info("Application started", "startup");

A partir de ese momento, la API es la misma. Timing, breadcrumbs, métricas:

// Timing con categoría
EW.StartTiming("invoice.generate", "pdf");
// ... genera el PDF ...
EW.EndTiming("invoice.generate");

// Breadcrumb para rastrear el recorrido del usuario
EW.AddBreadcrumb("Clicked Export", "ui");

// Counter y gauge
EW.IncrementCounter("invoices.generated", 1);
EW.RecordGauge("queue.size", pendingJobs.Count);

Para WinForms basta agregar una línea para capturar las excepciones del thread UI:

using ExeWatch;
using ExeWatch.WinForms;

ExeWatchSdk.Initialize(config);
ExeWatchWinForms.Install();  // captura Application.ThreadException

El repositorio de ejemplos incluye tres samples .NET completos: una console app, una aplicación WinForms interactiva y un Windows Service.

Custom Metrics

Hasta la versión anterior, ExeWatch recolectaba las métricas (counter y gauge) pero las mostraba solo como valores agregados. Con la 1.8 las métricas tienen una página dedicada con gráficos temporales.

En la práctica, esto significa que puedes rastrear magnitudes específicas de tu dominio aplicativo y visualizarlas en el tiempo junto a los logs y los timings:

// Delphi — rastrea métricas de negocio
EW.IncrementCounter('orders.processed', 1);
EW.IncrementCounter('orders.failed', 1);
EW.RecordGauge('queue.pending', FPendingQueue.Count);

// Gauge periódico — muestreado automáticamente cada 30 segundos
EW.RegisterPeriodicGauge('memory_mb',
  function: Double
  begin
    Result := GetCurrentMemoryMB;
  end);

// C# — misma API
EW.IncrementCounter("orders.processed", 1);
EW.RecordGauge("connections.active", pool.ActiveCount);

Desde la página Metrics también puedes eliminar los datos de una métrica específica directamente desde la modal de detalle, útil durante el desarrollo o para limpiar datos de prueba.

Health Monitoring

Una de las preguntas más frecuentes que recibíamos era: "¿Cómo sé si mi aplicación está funcionando bien sin mirar el dashboard cada 5 minutos?"

La respuesta es el health monitoring. Cada aplicación tiene ahora un Health Score calculado automáticamente en base a tres parámetros: error rate, crashes y operaciones lentas en las últimas 24 horas. El estado resultante es uno entre Healthy, Degraded y Unhealthy.

El sistema incluye una lógica anti-flapping: no basta un solo error para provocar un cambio de estado. Esto evita las notificaciones innecesarias y reduce el ruido.

Cuando el estado de salud cambia, ExeWatch envía notificaciones vía email y, si está configurado, vía Discord a través de webhook. Discord fue agregado porque muchos equipos lo usan como canal operativo y prefieren recibir las notificaciones donde ya trabajan.

El nivel de detalle del health monitoring depende del plan: el plan Hobby ofrece monitoreo básico, el Pro agrega monitoreo basado en errores, el Business incluye análisis completo con timing y tendencias.

Uso compartido de aplicaciones

Una funcionalidad que no habíamos previsto pero que nos fue solicitada por varios usuarios: la posibilidad de compartir una aplicación en solo lectura con usuarios externos.

El escenario típico: tienes un cliente que quiere ver el estado de su instalación sin que tengas que enviarle capturas de pantalla o reportes periódicos. Con el uso compartido read-only, le das acceso directo al dashboard de su aplicación — logs, timing, health — sin conceder permisos de modificación ni acceso a otras aplicaciones de la cuenta.

Integración con DMVCFramework

Para quienes desarrollan aplicaciones servidor con DMVCFramework, publicamos un sample completo que muestra cómo integrar ExeWatch en una aplicación web TemplatePro + HTMX.

La integración aprovecha dos mecanismos que DMVCFramework ofrece nativamente. El primero es el callback appender de LoggerPro: todas las LogI, LogW, LogE del framework — incluidas las internas — se reenvían automáticamente a ExeWatch.

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);

El segundo es el profiler integrado de DMVCFramework. Dado que el logger ya está conectado a ExeWatch, el timing de cada controller action se rastrea automáticamente:

Profiler.ProfileLogger := Log;
Profiler.WarningThreshold := 500;           // warning si action > 500ms
Profiler.LogsOnlyIfOverThreshold := False;  // loguea siempre, no solo los lentos

Con estas pocas líneas en el .dpr, toda la aplicación está monitoreada sin tocar los controllers. El sample luego muestra las funcionalidades avanzadas donde realmente aportan valor — por ejemplo, extra data estructurados cuando un batch import falla parcialmente:

// Cada fila fallida se loguea con contexto estructurado
LRowExtra := TJSONObject.Create;
LRowExtra.AddPair('row_number', TJSONNumber.Create(I + 1));
LRowExtra.AddPair('first_name', LFirstName);
LRowExtra.AddPair('last_name', LLastName);
LRowExtra.AddPair('error', LReason);
EW.Log(llWarning, Format('Import failed for row %d: %s %s (%s)',
  [I + 1, LFirstName, LLastName, LReason]), 'people', LRowExtra);

// El summary incluye el array completo de las filas fallidas
LExtra := TJSONObject.Create;
LExtra.AddPair('total_rows', TJSONNumber.Create(10));
LExtra.AddPair('imported', TJSONNumber.Create(LImported));
LExtra.AddPair('failed', TJSONNumber.Create(LFailed));
LExtra.AddPair('failed_rows', LFailedRows);  // TJSONArray con el detalle
EW.Log(llWarning, 'Batch import: 7 imported, 3 failed', 'people', LExtra);

Abriendo el log en el dashboard ExeWatch, el extra data es visible en formato estructurado — ya no un mensaje de texto a interpretar, sino datos navegables.

Repositorio público con todos los ejemplos

Publicamos un repositorio GitHub con ejemplos de integración para todos los SDKs y para los distintos tipos de aplicación: github.com/danieleteti/ExeWatchSamples.

Sample Tipo Qué muestra
Delphi VCL Desktop Windows Logging, timing, breadcrumbs, user identity, tags, métricas, captura excepciones VCL
Delphi WebBroker Server REST Timing automático de request HTTP, error tracking, contadores
Delphi DMVCFramework Web app (TemplatePro + HTMX) Integración LoggerPro + profiler, CRUD, nested timing, extra data
.NET Console Console app Todas las features con iteraciones timed y fallos aleatorios
.NET WinForms Desktop Windows GUI interactiva, API key en runtime, timing anidados, métricas
.NET Windows Service Servicio Windows Ciclo processing, nested timing, counter, gauge, shutdown limpio
JavaScript Browser Página HTML única, SDK desde CDN, sin build tools

Cada ejemplo incluye un README detallado y puede ser compilado y ejecutado en pocos minutos. La API es deliberadamente uniforme entre los SDKs, por lo que pasar de un lenguaje a otro es inmediato:

// Delphi
EW.Info('User logged in', 'auth');
EW.StartTiming('db.query', 'database');
EW.AddBreadcrumb('Search: "invoice 2024"', 'search');

// C# — misma estructura
EW.Info("User logged in", "auth");
EW.StartTiming("db.query", "database");
EW.AddBreadcrumb("Search: \"invoice 2024\"", "search");

// JavaScript — misma estructura
ew.info("User logged in", "auth");
ew.startTiming("db.query", "database");
ew.addBreadcrumb("Search: \"invoice 2024\"", "search");

On Premise

Varias empresas nos contactaron para preguntar si era posible instalar ExeWatch en su propia infraestructura. Las motivaciones son las previsibles: políticas corporativas que impiden el envío de datos de telemetría a servicios externos, requisitos de compliance sectorial, necesidades de latencia o simplemente la preferencia por el control directo de la infraestructura.

Agregamos la opción On Premise a la página de pricing. No es un plan self-service: requiere una negociación directa porque cada instalación tiene necesidades diferentes en términos de sizing, backup, actualizaciones y soporte. Los interesados pueden escribirnos a exewatch@bittime.it.

Webinar e ITDevCon

El 24 de marzo a las 15:00 CET realizaré un webinar dedicado a ExeWatch y a las aplicaciones Delphi VCL. Después del primer video de presentación en inglés, este será en italiano y pensado para quienes desarrollan aplicaciones desktop con Delphi. Veremos la integración paso a paso, las funcionalidades avanzadas y cómo aprovechar al máximo el dashboard. Próximamente habrá webinars en inglés y español.

Para inscribirte: Registro webinar ExeWatch

En la próxima ITDevCon 2026 Spring Edition (en italiano) daré una charla sobre ExeWatch donde entraré en detalle sobre integraciones y funcionalidades avanzadas — esas que una vez descubiertas no querrás dejar de usar.

Qué viene después

El trabajo avanza en dos frentes. En el backend estamos mejorando el anomaly detection para hacerlo más granular. En el frente SDK, el próximo candidato es Python — muchas aplicaciones desktop usan PyQt o Tkinter y tienen las mismas necesidades de monitoreo.

Si ya usas ExeWatch, todas las novedades de la 1.8 ya están disponibles en tu cuenta. Si aún no lo has probado, el plan Hobby es gratuito y no requiere tarjeta de crédito.

ExeWatch — Monitoreo para aplicaciones servidor, desktop y web. Creado por bit Time Professionals.

Tags

Comments

comments powered by Disqus