feat: 初始化前后端Node.js控制台项目基础架构
- 创建项目核心文件：package.json、vite.config.js、.gitignore - 添加前后端基础依赖和开发工具配置 - 完善OpenSpec模块，包括项目文档和核心能力规格 - 配置ESLint和Prettier代码规范 - 创建基本目录结构 - 实现前端Vue3应用框架和路由 - 添加后端Express服务器和基础路由 - 编写README项目说明文档
This commit is contained in:
111
openspec/specs/logging/design.md
Normal file
111
openspec/specs/logging/design.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Logging Capability Design
|
||||
|
||||
## Context
|
||||
This design document describes the technical implementation of the logging capability for the BLS Project Console, which allows the system to read log records from Redis queues and display them in the console interface.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
### Goals
|
||||
- Implement real-time log reading from Redis queues
|
||||
- Provide a user-friendly log display interface
|
||||
- Support log filtering by level and time range
|
||||
- Ensure high performance and low latency
|
||||
- Implement proper error handling and reconnection mechanisms
|
||||
|
||||
### Non-Goals
|
||||
- Log storage or persistence beyond memory
|
||||
- Log analysis or visualization (charts, graphs)
|
||||
- Advanced log search capabilities
|
||||
|
||||
## Decisions
|
||||
|
||||
### Decision: Redis Queue Implementation
|
||||
- **What**: Use Redis List as the queue data structure
|
||||
- **Why**: Redis Lists provide efficient push/pop operations with O(1) time complexity, making them ideal for message queues
|
||||
- **Alternatives considered**:
|
||||
- Redis Streams: More advanced but overkill for our use case
|
||||
- Redis Pub/Sub: No persistence, so logs would be lost if the server is down
|
||||
|
||||
### Decision: Real-time Updates
|
||||
- **What**: Use Server-Sent Events (SSE) for real-time log updates
|
||||
- **Why**: SSE is simpler than WebSockets for one-way communication, has better browser support, and is easier to implement
|
||||
- **Alternatives considered**:
|
||||
- WebSockets: More complex for one-way communication
|
||||
- Polling: Higher latency and more resource-intensive
|
||||
|
||||
### Decision: Log Storage
|
||||
- **What**: Store logs in memory with a configurable maximum size
|
||||
- **Why**: In-memory storage provides fast access times and avoids the complexity of database management
|
||||
- **Alternatives considered**:
|
||||
- Database storage: Adds complexity and latency
|
||||
- File system: Not suitable for real-time access
|
||||
|
||||
## Architecture
|
||||
|
||||
### Frontend Architecture
|
||||
```
|
||||
LogView Component
|
||||
├── LogList Component
|
||||
├── LogFilter Component
|
||||
└── LogService
|
||||
```
|
||||
|
||||
### Backend Architecture
|
||||
```
|
||||
Log Routes
|
||||
├── Log Service
|
||||
│ ├── Redis Client
|
||||
│ └── Log Manager
|
||||
└── SSE Controller
|
||||
```
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Redis Connection
|
||||
- Use the `redis` npm package to connect to Redis
|
||||
- Implement automatic reconnection with exponential backoff
|
||||
- Handle connection errors gracefully
|
||||
|
||||
### Log Reading
|
||||
1. Server establishes connection to Redis
|
||||
2. Server listens for new log records using `BLPOP` command (blocking pop)
|
||||
3. When a log record is received, it's added to the in-memory log store
|
||||
4. The log is then sent to all connected SSE clients
|
||||
|
||||
### Log Storage
|
||||
- Use an array to store log records in memory
|
||||
- Implement a circular buffer to limit memory usage
|
||||
- Default maximum log count: 10,000
|
||||
- Configurable via environment variable
|
||||
|
||||
### Log Display
|
||||
- Use a scrollable list to display logs
|
||||
- Implement virtual scrolling for large log sets to improve performance
|
||||
- Color-code logs by level (INFO: gray, WARN: yellow, ERROR: red, DEBUG: blue)
|
||||
|
||||
### Log Filtering
|
||||
- Implement client-side filtering for performance
|
||||
- Allow filtering by log level (INFO, WARN, ERROR, DEBUG)
|
||||
- Allow filtering by time range using a date picker
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
### Risk: Redis Connection Failure
|
||||
- **Risk**: If Redis connection is lost, logs won't be received
|
||||
- **Mitigation**: Implement automatic reconnection with exponential backoff, and notify users when connection is lost
|
||||
|
||||
### Risk: High Log Volume
|
||||
- **Risk**: Large number of logs could cause performance issues
|
||||
- **Mitigation**: Implement a circular buffer to limit memory usage, and use virtual scrolling in the frontend
|
||||
|
||||
### Risk: Browser Performance
|
||||
- **Risk**: Displaying thousands of logs could slow down the browser
|
||||
- **Mitigation**: Use virtual scrolling and limit the number of logs displayed at once
|
||||
|
||||
## Migration Plan
|
||||
No migration is required as this is a new feature.
|
||||
|
||||
## Open Questions
|
||||
- What is the expected maximum log volume per minute?
|
||||
- Should we add support for log persistence to disk?
|
||||
- Should we implement log search functionality?
|
||||
71
openspec/specs/logging/spec.md
Normal file
71
openspec/specs/logging/spec.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Logging Capability Specification
|
||||
|
||||
## Overview
|
||||
This specification defines the logging capability for the BLS Project Console, which allows the system to read log records from Redis queues and display them in the console interface.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Log Reading from Redis
|
||||
The system SHALL read log records from a Redis queue.
|
||||
|
||||
#### Scenario: Reading logs from Redis queue
|
||||
- **WHEN** the server starts
|
||||
- **THEN** it SHALL establish a connection to the Redis queue
|
||||
- **AND** it SHALL begin listening for new log records
|
||||
- **AND** it SHALL store log records in memory for display
|
||||
|
||||
### Requirement: Log Display in Console
|
||||
The system SHALL display log records in a user-friendly format.
|
||||
|
||||
#### Scenario: Displaying logs in the console
|
||||
- **WHEN** a log record is received from Redis
|
||||
- **THEN** it SHALL be added to the log list in the console
|
||||
- **AND** it SHALL display the log timestamp, level, and message
|
||||
- **AND** it SHALL support scrolling through historical logs
|
||||
|
||||
### Requirement: Log Filtering
|
||||
The system SHALL allow users to filter logs by level and time range.
|
||||
|
||||
#### Scenario: Filtering logs by level
|
||||
- **WHEN** the user selects a log level filter
|
||||
- **THEN** only logs with the selected level SHALL be displayed
|
||||
|
||||
#### Scenario: Filtering logs by time range
|
||||
- **WHEN** the user selects a time range
|
||||
- **THEN** only logs within the specified range SHALL be displayed
|
||||
|
||||
### Requirement: Log Auto-Refresh
|
||||
The system SHALL automatically refresh logs in real-time.
|
||||
|
||||
#### Scenario: Real-time log updates
|
||||
- **WHEN** a new log is added to the Redis queue
|
||||
- **THEN** it SHALL be automatically displayed in the console
|
||||
- **AND** the console SHALL scroll to the latest log if the user is viewing the end
|
||||
|
||||
## Data Model
|
||||
|
||||
### Log Record
|
||||
```json
|
||||
{
|
||||
"id": "string",
|
||||
"timestamp": "ISO-8601 string",
|
||||
"level": "string", // e.g., INFO, WARN, ERROR, DEBUG
|
||||
"message": "string",
|
||||
"metadata": "object" // optional additional data
|
||||
}
|
||||
```
|
||||
|
||||
## API Endpoints
|
||||
|
||||
### GET /api/logs
|
||||
- **Description**: Get log records
|
||||
- **Query Parameters**:
|
||||
- `level`: Filter logs by level
|
||||
- `startTime`: Filter logs from this timestamp
|
||||
- `endTime`: Filter logs up to this timestamp
|
||||
- `limit`: Maximum number of logs to return
|
||||
- **Response**: Array of log records
|
||||
|
||||
### GET /api/logs/live
|
||||
- **Description**: Establish a WebSocket connection for real-time log updates
|
||||
- **Response**: Continuous stream of log records
|
||||
Reference in New Issue
Block a user