Logging enhancements

[ksuderman]

This pull request adds several new features to enhance logging in Galaxy:

1. a new logging level TRACE to the Python logging framework,
2. a new API for managing logging levels at runtime,
3. new logging configuration options in the galaxy.yml file,
4. an admin panel in the user interface for managing logging levels at runtime.

See galaxyproject#19580

Claude Code is responsible for the user interface and the bulk of this readme. The rest was hand-coded before I discovered the magic of AI.

1. Backend Enhancements

New Logging API (lib/galaxy/webapps/galaxy/api/logging.py)

• GET /api/logging: Returns comprehensive logger information including:

  • Logger names
  • Current configured levels
  • Effective levels (inherited from parent loggers)
  • Hierarchical logger relationships

• POST /api/logging/{logger_name}: Sets logger levels with features:

  • Wildcard support (e.g., galaxy.* sets level for all Galaxy loggers)
  • Real-time level changes without server restart
  • Returns updated logger information for immediate UI feedback
  • Admin authentication required

New Logging Utilities (lib/galaxy/util/logging/__init__.py)

• TRACE logging level: Adds TRACE level (below DEBUG) for ultra-verbose logging
• get_log_levels(): Function to retrieve all configured loggers and their levels
• set_logging_levels_from_config(): Configuration-based logging level management
• Level management functions: Utilities for programmatic logger level control

New Logging Configuration Options (config/galaxy.yml)

The current methods of logging configuration are still supported and remain unchanged, but a new section has been added to galaxy.yml that allows administrators to quickly and easily set logging levels.

  logging_levels:
    main: INFO
    galaxy.*: INFO
    galaxy.datatypes.*: ERROR
    galaxy.jobs.*: DEBUG
    galaxy.jobs.manager.*: TRACE
    galaxy.managers.*: DEBUG
    galaxy.webapps.galaxy.api.*: DEBUG
    galaxy.webapps.galaxy.api.logging: TRACE

Groups of loggers can have their logging levels set by using a .* wildcard. The above configuration sets all of Galaxy's loggers to the INFO level and then changes other package's loggers as desired. For example, all loggers in the galaxy.webapps.galaxy.api package and below will use the DEBUG logging level, while the galaxy.webapps.galaxy.api.logging logger will use the TRACE level.

NOTE Full regular expressions are not supported. The .* syntax should be read as "starts with". When we set galaxy.*: INFO then any logger whose name starts with the string galaxy. will have its level set to INFO.

2. New Admin Logging Settings Interface

Files Added:

• client/src/components/admin/LoggingSettings.vue - New Vue component for logging management
• lib/galaxy/webapps/galaxy/api/logging.py - New API endpoints for logging management
• lib/galaxy/util/logging/__init__.py - New logging utilities and level management functions

Files Modified:

• client/src/entry/analysis/routes/admin-routes.js - Added import and route for LoggingSettings component
• client/src/components/admin/AdminPanel.vue - Added "Logging Settings" link to Server section menu

Features:

• Quick Set Form: Set log levels for individual loggers or multiple loggers using wildcards (e.g., galaxy.*)
• Logger Table: View all current loggers with their set and effective levels
• Search/Filter: Find specific loggers by name with real-time filtering
• Per-Logger Actions: Dropdown menus to change individual logger levels
• Color-coded Badges: Visual indication of log levels (DEBUG=secondary, INFO=info, WARNING=warning, ERROR/CRITICAL=danger)
• Real-time Updates: Changes take effect immediately and update the interface
• Error Handling: Graceful handling of API failures

API Integration:

• Uses new /api/logging endpoints:
  • GET /api/logging - Fetches all logger information with current and effective levels
  • POST /api/logging/{logger_name}?level={level} - Sets logger levels (supports wildcards)

Access:

The logging settings interface is accessible at /admin/logging in the Galaxy admin panel under the "Server" section.

3. Testing Notes

Admin Interface Testing:

-[x] Access Control: Verify only admin users can access /admin/logging
-[x] Logger Display: Confirm logger table loads showing all configured loggers
-[x] Individual Logger Management: Test setting levels for specific loggers
-[x] Wildcard Patterns: Test patterns like galaxy.* to set multiple logger levels
-[ ] Search/Filter: Verify real-time filtering of logger names works correctly
-[x] Dropdown Actions: Test per-logger level changes via dropdown menus
-[ ] Real-time Updates: Confirm level changes take effect immediately
-[x] Color-coded Display: Verify log level badges display with correct colors

API Testing:

-[x] GET /api/logging: Test endpoint returns complete logger information
-[x] POST /api/logging/{logger_name}: Test setting individual logger levels
-[x] Wildcard Support: Test POST with wildcard patterns (e.g., galaxy.*)
-[x] Authentication: Verify endpoints require admin authentication
-[ ] Error Handling: Test invalid logger names and levels

4. Backward Compatibility

• All changes are backward compatible
• Existing logging configurations continue to work
• No breaking changes to existing APIs or interfaces

5. Caveats and Limitations

This is a best effort implementation. We try no to break anything and remain backwards compatible, but if we miss a few edge cases que sera sera.

In particular, during startup, only loggers that have already been created will be configured. Similarly, any changes made using the API or Admin panel will only apply to currently running loggers. Any loggers created after the changes will not reflect the new settings.

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are above.

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jdavcs]

better absolute: from galaxy.util

[jdavcs]

this is very dangerous: it changes how this function behaves, and the function is part of a nontrivial path resolution algorithm.