Refactor Logging Package to Use Interface-Based Design with Multiple Destinations

[zhuoyuan-liu]

Background

The current logging system in osctrl uses type switching and type assertions, making the code repetitive and difficult to maintain. It also doesn't properly support multiple logging destinations in a clean way.

We would like to send logs to different destinations. For example, s3 for long-term storage and the elastic or other tools for analysis.

Also, the current "logging" system in osctrl is primarily focused on exporting osquery data to various destinations (DB, Splunk, Kafka, etc.), not traditional application logging. I would like to rename them to exporter to avoid confusion.

Proposed Changes

1. Rename concepts to better reflect their purpose:

   • Change "Logger" to "Exporter"
   • Create a "ExportManager" instead of "LoggerTLS"

2. Define a clear interface with methods for different data types:

   • Status data
   • Result data
   • Query data

3. Implement a composite pattern to support multiple destinations

4. Use a factory pattern for creating specific exporter implementations

5. Remove type switching and assertions from the main code

Benefits

• Clearer naming that reflects actual purpose
• Cleaner, more maintainable code with less repetition
• Easier to extend with new export destinations
• Better testability through proper interface abstraction
• True support for multiple export destinations

Implementation Details

• Create new interfaces without breaking existing functionality
• Gradually migrate each exporter to implement the new interface
• Add tests for the new implementation

Acceptance Criteria

• All existing "logger" types implement the new exporter interface
• Composite exporter allows sending data to multiple destinations
• All tests pass with the new implementation
• No regression in functionality

---

Possible interface:

// DataExporter defines a destination for osquery data
type DataExporter interface {
    // IsEnabled returns whether this exporter is active
    IsEnabled() bool
    
    // Export sends data to the configured destination
    Export(logType string, data []byte, params ExportParams) error
}

// ExportParams contains all possible parameters for data export
type ExportParams struct {
    Environment string
    UUID        string
    QueryName   string
    Status      int
}

[javuto]

This is a great proposal and it will help to enable/disable those exporters without having to reload configuration files or environment variables. Also it will make it easier to keep adding more than the current loggers. Happy to help with the implementation!