Christoph
58df73d330
Here is a detailed summary of the changes: ### 🚀 Frontend Telemetry Improvement (`src/lib/telemetry.ts` & `src/main.ts`) A dedicated module for robust, rate-limited error reporting has been added to the frontend application. * **Error Handling:** The new `installErrorReporting` function registers global listeners for `error` and `unhandledrejection` events on the window object. * **Stability Focus:** To prevent telemetry from interfering with the main user experience, the system implements a **rate limit** (`MAX_REPORTS_PER_SESSION = 25`) and checks to ensure duplicate messages are not sent repeatedly during a single session. * **Integration:** `src/main.ts` now calls `installErrorReporting()` upon application startup, ensuring that error monitoring is active from the moment the app loads. ### ⚙️ Backend Metrics & Logs Export Enhancement (Rust Code Block) The Rust code block significantly refactors and enhances the logic for exporting system metrics and application logs to an OpenTelemetry Collector endpoint. The structure now adheres much more closely to standard OTLP/JSON schemas, and unit tests are added for validation. #### 1. Metrics Export (`gauge` function & main loop) * **Comprehensive Data Collection:** The export loop is updated to refresh process information and calculate key metrics: * Process Memory Usage (`process.memory.usage`) * CPU Utilization (System-wide, normalized) (`process.cpu.utilization`) * System Memory Utilization (`system.memory.utilization`) * **Standardized Payload:** The `gauge` helper function correctly structures these metrics into the required OpenTelemetry JSON format, including resource attributes and time points. #### 2. Logs Export (`logs_payload`, `resource`, etc.) * **Structured Logging:** The `logs_payload` function provides a robust way to serialize application logs (`LogEvent`). It accurately maps log severity, body content, and custom attributes into the OTLP/JSON format. * **Resource Attributes:** Helper functions like `resource()` ensure that all telemetry payloads are correctly tagged with essential metadata (service name, version, OS type, architecture). #### 3. Testing * **Validation Added:** Comprehensive unit tests (`#[cfg(test)] mod tests`) have been added to validate the complex serialization logic for both metrics and logs, ensuring they match the expected OpenTelemetry schema structure. *** ### Summary of Impact These changes result in a much more observable and stable application: 1. **Improved Observability:** The system can now reliably capture detailed performance data (CPU/Memory) and structured event logs from the backend, while simultaneously capturing critical runtime errors from the frontend. 2. **Increased Stability:** Rate limiting on error reporting prevents telemetry failures from cascading into user-facing bugs. 3. **Code Quality:** The addition of unit tests for the complex serialization logic significantly increases confidence in the reliability of the data export pipeline.
1.5 KiB
1.5 KiB
SigNoz-Telemetrie
Gitty meldet Abstürze, Fehler und Ressourcenverbrauch an eine SigNoz-Instanz
(OTLP/HTTP, JSON). Implementierung: src-tauri/src/telemetry.rs plus
src/lib/telemetry.ts für Frontend-Fehler.
Konfiguration
Der Collector-Endpoint ist als Konstante OTLP_ENDPOINT in
src-tauri/src/telemetry.rs hinterlegt (http://telemetry.cbsk-tech.de,
analog zum fest eingetragenen Aptabase-Host in main.rs). Telemetrie ist
damit in jedem Build aktiv — auch im Dev-Modus.
Was gemeldet wird
- Abstürze: Ein Panic-Hook schickt Panics als
FATAL-Log mit Backtrace und Quellposition — synchron, bevor der Prozess stirbt (SigNoz: Logs, Filtererror.kind=panic). - Rust-Fehler/-Warnungen: Alles, was über das
log-Crate mitwarn!/error!geloggt wird, geht zusätzlich zur Konsole als Log-Record raus. - Frontend-Fehler: Uncaught Exceptions und unbehandelte Promise-Rejections
aus dem WebView (Attribut
component=frontend), pro Sitzung dedupliziert und auf 25 Meldungen gedeckelt. - Ressourcen (alle 60 s als Gauges):
process.memory.usage(Bytes),process.cpu.utilization(0–1, über alle Kerne normalisiert),system.memory.utilization(0–1).
Alle Daten tragen die Resource-Attribute service.name=gitty,
service.version (App-Version aus tauri.conf.json), os.type und
host.arch. Es werden keine Repository-Inhalte, Pfade oder Nutzerdaten
übertragen — nur Fehlermeldungstexte, Stacktraces und Prozessmetriken.
Fehlgeschlagene Exporte werden verworfen; Telemetrie darf den Git-Workflow
nie stören.