forked from syntaxbullet/AuroraBot-discord
3.5 KiB
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
LogServiceor in-memory buffer to store recent "Activity" events for the dashboard history.
API / Interface
- Dashboard Route (
src/web/routes/dashboard.ts):- Replace
mockedActivityarray with a fetch from a real log buffer/source. - Replace
userCountapproximation with a precise count fromUserServiceorAuroraClient. - Replace "System Metrics" mock bars with real values (RAM usage, Uptime, CPU load if possible).
- Replace
- Log Source:
- Implement a mechanism (e.g., specific
Loggertransport orWebServerstatic 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.
- Implement a mechanism (e.g., specific
Real Data Integration
- Activity Feed: Must show actual commands executed, system errors, and startup events.
- Top Stats: Ensure
Servers,Users,Commands, andPingcome from the liveAuroraClientinstance. - Metrics: Display
process.memoryUsage().heapUsedconverted to MB. Displayprocess.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
setIntervalin 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
- The "Activity Feed" on the dashboard displays real, recent events that occurred in the application (e.g., "Bot started", "Command /ping executed").
- The "System Metrics" section displays a visual representation (or text) of actual memory usage and uptime.
- The hardcoded
mockedActivityarray is removed fromdashboard.ts. - Refreshing the dashboard page updates the metrics and feed with the latest data.
5. Implementation Plan
- Step 1: Create a simple in-memory
LogBufferinsrc/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.tsetc). - Step 3: Implement
getSystemMetrics()helper to return formatted RAM/CPU data. - Step 4: Update
src/web/routes/dashboard.tsto 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.tsexposinggetRecentLogs(). - Dashboard Update:
src/web/routes/dashboard.tsnow usesAuroraClientstats andprocessmetrics (Uptime, Memory) directly. - Tests: Added
src/lib/logger.test.tsto verify buffer logic.