Files
AuroraBot-discord/tickets/2026-01-07-replace-mock-dashboard-data.md
2026-01-07 13:47:02 +01:00

3.5 KiB

2026-01-07-replace-mock-dashboard-data.md: Replace Mock Dashboard Data with Live Telemetry

Status: Done Created: 2026-01-07 Tags: dashboard, telemetry, logging, database

1. Context & User Story

  • As a: Bot Administrator
  • I want to: see actual system logs, real-time resource usage, and accurate database statistics on the web dashboard
  • So that: I can monitor the true health and activity of the Aurora application without checking the terminal or database manually.

2. Technical Requirements

Data Model Changes

  • No strict database schema changes required, but may need a cohesive LogService or in-memory buffer to store recent "Activity" events for the dashboard history.

API / Interface

  • Dashboard Route (src/web/routes/dashboard.ts):
    • Replace mockedActivity array with a fetch from a real log buffer/source.
    • Replace userCount approximation with a precise count from UserService or AuroraClient.
    • Replace "System Metrics" mock bars with real values (RAM usage, Uptime, CPU load if possible).
  • Log Source:
    • Implement a mechanism (e.g., specific Logger transport or WebServer static buffer) to capture the last ~50 distinct application events (commands, errors, warnings) for display.
    • (Optional) If "Docker Compose Logs" are strictly required, implement a file reader for the standard output log file if accessible, otherwise rely on internal application logging.

Real Data Integration

  • Activity Feed: Must show actual commands executed, system errors, and startup events.
  • Top Stats: Ensure Servers, Users, Commands, and Ping come from the live AuroraClient instance.
  • Metrics: Display process.memoryUsage().heapUsed converted to MB. Display process.uptime().

3. Constraints & Validations (CRITICAL)

  • Performance: Fetching logs or stats must not block the event loop. Avoid heavy DB queries on every dashboard refresh; cache stats if necessary (e.g., via setInterval in background).
  • Security: Do not expose sensitive data (tokens, raw SQL) in the activity feed.
  • Fallbacks: If data is unavailable (e.g., client not ready), show "Loading..." or a neutral placeholder, not fake data.

4. Acceptance Criteria

  1. The "Activity Feed" on the dashboard displays real, recent events that occurred in the application (e.g., "Bot started", "Command /ping executed").
  2. The "System Metrics" section displays a visual representation (or text) of actual memory usage and uptime.
  3. The hardcoded mockedActivity array is removed from dashboard.ts.
  4. Refreshing the dashboard page updates the metrics and feed with the latest data.

5. Implementation Plan

  • Step 1: Create a simple in-memory LogBuffer in src/lib/logger.ts (or similar) to keep the last 50 logs.
  • Step 2: Hook this buffer into the existing logging system (or add manual pushes in command.handler.ts etc).
  • Step 3: Implement getSystemMetrics() helper to return formatted RAM/CPU data.
  • Step 4: Update src/web/routes/dashboard.ts to import the log buffer and metrics helper.
  • Step 5: Replace the HTML template variables with these real data sources.

Implementation Notes

  • Log Buffer: Added a 50-item rolling buffer in src/lib/logger.ts exposing getRecentLogs().
  • Dashboard Update: src/web/routes/dashboard.ts now uses AuroraClient stats and process metrics (Uptime, Memory) directly.
  • Tests: Added src/lib/logger.test.ts to verify buffer logic.