Restore log level functionality with LOG_LEVEL_V2 support

[jkebinger]

Summary

This PR restores dynamic log level functionality from the predecessor project (prefab-cloud-ruby) with a modernized approach using LOG_LEVEL_V2 config evaluation.

Changes

New Files

• lib/reforge/log_level.rb - Public LogLevel enum (:trace, :debug, :info, :warn, :error, :fatal)
• lib/reforge/log_level_client.rb - Client for managing dynamic log levels with SemanticLogger and stdlib Logger support
• test/test_log_level_client.rb - Comprehensive test coverage (12 tests, 35 assertions)

Modified Files

• lib/reforge/client.rb - Added log_level_client accessor
• lib/reforge/options.rb - Added logger_key option (defaults to 'log-levels.default')
• lib/sdk-reforge.rb - Added requires for new log level modules, made semantic_logger optional
• Gemfile - Moved semantic_logger from runtime to development dependency
• sdk-reforge.gemspec - Updated dependencies to make semantic_logger optional
• README.md - Added documentation for both SemanticLogger and stdlib Logger integration
• lib/prefab_pb.rb - Protobuf update (from previous commit)

Key Features

1. LogLevel Enum

Public API for log levels that abstracts away the protobuf implementation:

Reforge::LogLevel::TRACE  # :trace
Reforge::LogLevel::DEBUG  # :debug
Reforge::LogLevel::INFO   # :info
Reforge::LogLevel::WARN   # :warn
Reforge::LogLevel::ERROR  # :error
Reforge::LogLevel::FATAL  # :fatal

2. LogLevelClient Methods

• get_log_level(logger_name) - Evaluates LOG_LEVEL_V2 config and returns the appropriate log level
• should_log?(severity, path) - Compares numeric severity against configured level
• semantic_filter(log) - SemanticLogger integration for automatic filtering (optional)
• stdlib_formatter(logger_name) - Ruby stdlib Logger integration via custom formatter

3. Context-Based Evaluation

Log levels are evaluated with the following context:

{
  "reforge-sdk-logging" => {
    "lang" => "ruby",
    "logger-path" => logger_name  # e.g., "my_app.my_class"
  }
}

4. Flexible Logger Integration

SemanticLogger (optional dependency):

client = Reforge::Client.new
SemanticLogger.add_appender(
  io: $stdout,
  formatter: :json,
  filter: client.log_level_client.method(:semantic_filter)
)

Ruby stdlib Logger:

client = Reforge::Client.new
logger = Logger.new($stdout)
logger.formatter = client.log_level_client.stdlib_formatter('MyApp')

5. Optional Dependencies

• semantic_logger is now a development dependency, not required at runtime
• The SDK gracefully handles missing SemanticLogger with appropriate warnings
• Customers can integrate with their preferred logging framework

Key Differences from Predecessor

Unlike the predecessor implementation that walked up a tree of logger names (e.g., log-level.my_app, log-level.my_app.my_class), this implementation:

• Uses a single LOG_LEVEL_V2 config evaluation
• Evaluates with Reforge context for targeted criteria
• Provides a simpler, more explicit approach to log level management
• Does not include log path aggregator (telemetry collection)
• Supports multiple logging frameworks (SemanticLogger, stdlib Logger)
• Reduces required dependencies for easier customer integration

Testing

All tests pass:

12 tests, 35 assertions, 0 failures, 0 errors, 0 skips

Test coverage includes:

• Basic get_log_level functionality
• Criteria-based evaluation (different log levels per logger path)
• All log level types (trace, debug, info, warn, error, fatal)
• Edge cases (nil key, empty key, wrong config type)
• should_log? with different severities
• Helper method conversions (class_path_name, underscore)
• SemanticLogger level mapping

Configuration

In Reforge Launch, create a LOG_LEVEL_V2 config that can use criteria on the reforge-sdk-logging.logger-path property to set different log levels for different classes/modules.

🤖 Generated with Claude Code

[jdwyah]

thanks