Custom Logger Implementation

[Shourya742]

Custom Logger

Need for Custom Logger

• Security and Control: Third-party vulnerabilities can pose significant risks. External libraries, especially widely used logging frameworks, may introduce security flaws. Attackers could exploit these to inject malicious log entries, access sensitive data, or gain elevated privileges. By creating a custom logger, you gain full control over your logging system's security, minimizing exposure to external threats.
• Protocol-specific logging: Protocol-level projects often have unique logging requirements, such as detailed tracing or custom formats. A custom logger can be tailored to your protocol's specific needs, offering greater flexibility and performance.

Logging in Rust

Rust implements logging using the facade pattern, a design concept from the "Gang of Four." Here's how it works:

• You call functions provided by the facade crate (in Rust, this is the "log" crate).
• The facade then calls the actual logic from another crate (such as "log4rs" or "env_logger").

This approach allows for flexibility—you can change the logging crate without altering your main code.

When logging in Rust, you typically import two libraries:

• The facade ("log")
• The specific logging implementation

graph TD
    A["Source Code"] -->|"Uses"| B["log Crate (Facade)"]
    B -->|"Initializes"| C["Logging Implementation Crate"]
    C -->|"Implements"| D["Actual Logging Logic"]
    E["User's Application"] -->|"Calls"| B
    B -->|"Forwards Calls"| C

Loading

Custom Logger Implementation

Designing the Facade Log Crate

1. Level Enum

The Level enum represents the logger's verbosity levels, from lowest to highest priority:

#[derive(Copy, Clone, PartialEq, Eq, Debug, Hash)]
pub enum Level {
    Trace,  // Extremely verbose, lowest priority
    Debug,  // Low-priority information
    Info,   // General information
    Warn,   // Potential issues
    Error,  // Serious problems
}

2. LevelFilter Enum

The LevelFilter enum defines log level filters, which can be compared directly to a Level:

#[repr(usize)]
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Hash)]
pub enum LevelFilter {
    Off,    // Lower than all log levels
    Error,  // Matches Error level
    Warn,   // Matches Warn level
    Info,   // Matches Info level
    Debug,  // Matches Debug level
    Trace,  // Matches Trace level
}

3. Record Structure

The Record structure contains the log message "payload," passed to the Log trait's log method:

#[derive(Clone, Debug)]
pub struct Record<'a> {
    metadata: Metadata<'a>,
    args: fmt::Arguments<'a>,
    module_path: Option<MaybeStaticStr<'a>>,
    file: Option<MaybeStaticStr<'a>>,
    line: Option<u32>,
}

4. Record Implementation

The Record implementation provides methods to access and manipulate log record data:

impl<'a> Record<'a> {
    pub fn builder() -> RecordBuilder<'a> { /* ... */ }
    pub fn args(&self) -> &fmt::Arguments<'a> { /* ... */ }
    pub fn metadata(&self) -> &Metadata<'a> { /* ... */ }
    pub fn level(&self) -> Level { /* ... */ }
    pub fn target(&self) -> &'a str { /* ... */ }
    pub fn module_path(&self) -> Option<&'a str> { /* ... */ }
    pub fn module_path_static(&self) -> Option<&'static str> { /* ... */ }
    pub fn file(&self) -> Option<&'a str> { /* ... */ }
    pub fn file_static(&self) -> Option<&'static str> { /* ... */ }
    pub fn line(&self) -> Option<u32> { /* ... */ }
    pub fn to_builder(&self) -> RecordBuilder { /* ... */ }
}

5. RecordBuilder Structure

The RecordBuilder structure implements the Builder pattern for Record instances:

#[derive(Debug)]
pub struct RecordBuilder<'a> {
    record: Record<'a>,
}

6. Metadata Structure

The Metadata structure contains log message information, including severity and target:

#[derive(Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug)]
pub struct Metadata<'a> {
    level: Level,
    target: &'a str,
}

7. MetadataBuilder Structure

The MetadataBuilder structure implements the Builder pattern for Metadata instances:

#[derive(Eq, PartialEq, Ord, PartialOrd, Hash, Debug)]
pub struct MetadataBuilder<'a> {
    metadata: Metadata<'a>,
}

8. Log Trait

The Log trait defines the core operations required for a logger:

pub trait Log: Sync + Send {
    /// Determines if a log message with the specified metadata would be logged.
    fn enabled(&self, metadata: &Metadata) -> bool;

    /// Logs the `Record`.
    fn log(&self, record: &Record);

    /// Flushes any buffered records.
    fn flush(&self);
}

Designing the Custom Logger

Our custom logger implementation consists of two main components:

1. Custom Logger Structure

pub struct CustomLogger {
    pub(crate) id: String,
    pub lines: Mutex<HashMap<(&'static str, String), usize>>,
}

This structure defines our logger, with an ID and a thread-safe hash map to store log lines.

2. Log Trait Implementation

impl Log for CustomLogger {
    fn enabled(&self, metadata: &Metadata) -> bool {
        // Determine if logging is enabled for given metadata
    }

    fn log(&self, record: &Record) {
        // Process and store the log record
    }

    fn flush(&self) {
        // Flush any buffered log entries
    }
}

Relationship Diagram

classDiagram
    class Level {
        <<enumeration>>
        Trace
        Debug
        Info
        Warn
        Error
    }
    class LevelFilter {
        <<enumeration>>
        Off
        Error
        Warn
        Info
        Debug
        Trace
    }
    class Record {
        metadata: Metadata
        args: fmt::Arguments
        module_path: Option~MaybeStaticStr~
        file: Option~MaybeStaticStr~
        line: Option~u32~
    }
    class RecordBuilder {
        record: Record
    }
    class Metadata {
        level: Level
        target: &str
    }
    class MetadataBuilder {
        metadata: Metadata
    }
    class Log {
        <<interface>>
        enabled(metadata: &Metadata): bool
        log(record: &Record)
        flush()
    }
    class CustomLogger {
        id: String
        lines: Mutex~HashMap~
    }
    Record "1" *-- "1" Metadata
    RecordBuilder "1" *-- "1" Record
    MetadataBuilder "1" *-- "1" Metadata
    CustomLogger ..|> Log
    Log ..> Record
    Log ..> Metadata
    Metadata "1" *-- "1" Level
    LevelFilter ..> Level

Loading

[KnowWhoami]

@Shourya742
Thanks for explaining the logging implementation in rust.
One question from my side->
can you explain the reasoning behind selecting this struct:

pub struct CustomLogger {
    pub(crate) id: String,
    pub lines: Mutex<HashMap<(&'static str, String), usize>>,
}

All I know that any type that implements Log trait must also implement Send and Sync trait as well.

[Shourya742]

@Shourya742 Thanks for explaining the logging implementation in rust. One question from my side-> can you explain the reasoning behind selecting this struct:

pub struct CustomLogger {
    pub(crate) id: String,
    pub lines: Mutex<HashMap<(&'static str, String), usize>>,
}

All I know that any type that implements Log trait must also implement Send and Sync trait as well.

The custom Logger act as an inmemory data store for logs, the id here is a specific primary key for each log, used for later recollection, and the lines is a hashmap of, module path, log message, and the id. This act as a data store. As all the elements used inside are send + sync enabled primitives so the the whole struct becomes send +sync enabled.

[KnowWhoami]

The custom Logger act as an inmemory data store for logs, the id here is a specific primary key for each log

I guess you mean to say primary key for each CustomLogger instance.
and where each instance will consist of related logs which are produced by a single component or sub-system, right?

the lines is a hashmap of, module path, log message, and the id.

Here , the usize will be used to uniquely identify each log , so IMO, key should be usize:

pub struct CustomLogger {
    pub(crate) id: String,
    pub lines: Mutex<HashMap<usize,(&'static str, String)>>,
}

[KnowWhoami]

Though , I don't have any idea how the implementation of this CustomLogger will look like :)
But from its structure and the all the data structures that Log facade provides ->
It seems that each struct instance aims to store logs that comes from paritcular component or sub-system (ID field helps to indentify that which instance stores which set of related logs) to keep better track of all the logs, helpfull in case of debugging etc.

[Shourya742]

The logger instance will be created only once, like how we have for other logger instantiation. Id wont be simple numeric value, we will be using something like uuid for better search space.

[KnowWhoami]

The logger instance will be created only once ,like how we have for other logger instantiation

If such the case , then why we require to have Id field to uniquely indentify a single instance?