### Summary of Changes - Removed proxy configuration in `rsbuild.config.js` as the API Gateway is not running. - Added smooth transitions and gentle loading overlays in CSS for improved user experience during data loading. - Updated `Dashboard` component to conditionally display loading spinner and gentle loading overlay based on data fetching state. - Enhanced `useOfflineAwareServiceStatus` and `useOfflineAwareSystemData` hooks to manage loading states and service status more effectively. - Increased refresh intervals for service status and system data to reduce API call frequency. ### Expected Results - Improved user experience with smoother loading transitions and better feedback during data refreshes. - Enhanced handling of service status checks, providing clearer information when services are unavailable. - Streamlined code for managing loading states, making it easier to maintain and extend in the future.
4.4 KiB
Unified Logging Configuration
This document describes the unified logging setup and usage in the LabFusion Service Adapters.
Overview
The service adapters use Python's built-in logging module with a centralized configuration system that provides unified logging for both application logs and incoming request logs. All logs use the same format, handler, and configuration for consistency and easier monitoring.
Logging Levels
- DEBUG: Detailed information for debugging (status checker operations)
- INFO: General information about application flow
- WARNING: Warning messages for non-critical issues
- ERROR: Error messages for failed operations
- CRITICAL: Critical errors that may cause application failure
Configuration
Logging is configured in services/logging_config.py with unified settings:
- Root Level: INFO
- Status Checker: DEBUG (detailed health check logging)
- Routes: INFO (API endpoint logging)
- Request Logging: INFO (unified with application logs)
- HTTP Client: WARNING (reduced verbosity)
- Unified Handler: Single handler for all log types
Log Format
Unified Format (same for application and request logs):
2024-01-15 10:30:45,123 - services.status_checker - INFO - status_checker.py:140 - Starting health check for 4 services
2024-01-15 10:30:45,124 - uvicorn.access - INFO - logging_middleware.py:45 - Request started: GET /services from 192.168.1.100
2024-01-15 10:30:45,125 - routes.general - INFO - general.py:78 - Service status endpoint called - checking all services
2024-01-15 10:30:45,126 - uvicorn.access - INFO - logging_middleware.py:55 - Request completed: GET /services -> 200 in 0.123s
Format includes:
- Timestamp
- Logger name (unified across all log types)
- Log level
- Filename and line number
- Message
Usage Examples
Basic Logging
import logging
from services.logging_config import get_logger
logger = get_logger(__name__)
logger.debug("Debug information")
logger.info("General information")
logger.warning("Warning message")
logger.error("Error occurred")
Request Logging
from services.logging_config import get_request_logger
request_logger = get_request_logger()
request_logger.info("Custom request log message")
Application Logging
from services.logging_config import get_application_logger
app_logger = get_application_logger()
app_logger.info("Application-level log message")
Service Status Logging
The status checker automatically logs:
- Health check start/completion
- Individual service responses
- Response times
- Error conditions
- Authentication status
API Endpoint Logging
Routes log:
- Endpoint calls
- Request processing
- Response generation
Request Middleware Logging
The logging middleware automatically logs:
- Request start (method, path, client IP, user agent)
- Request completion (status code, processing time)
- Request errors (exceptions, processing time)
Debug Endpoint
A debug endpoint is available at /debug/logging to:
- Test unified log levels across all logger types
- View current configuration
- Verify unified logging setup
- Test request, application, and route loggers
Environment Variables
You can control logging behavior with environment variables:
# Set log level (DEBUG, INFO, WARNING, ERROR, CRITICAL)
export LOG_LEVEL=DEBUG
# Disable timestamps
export LOG_NO_TIMESTAMP=true
Log Files
Currently, logs are output to stdout. For production, consider:
- File logging with rotation
- Structured logging (JSON)
- Log aggregation (ELK stack, Fluentd)
- Log levels per environment
Troubleshooting
No Logs Appearing
- Check log level configuration
- Verify logger names match module names
- Ensure logging is initialized before use
Too Many Logs
- Increase log level to WARNING or ERROR
- Disable DEBUG logging for specific modules
- Use log filtering
Performance Impact
- Use appropriate log levels
- Avoid logging in tight loops
- Consider async logging for high-volume applications
Best Practices
- Use appropriate levels: DEBUG for development, INFO for production
- Include context: Service names, request IDs, user information
- Structured messages: Consistent format for parsing
- Avoid sensitive data: No passwords, tokens, or personal information
- Performance: Log asynchronously when possible
- Monitoring: Set up alerts for ERROR and CRITICAL levels