Loki

timber_rust::service::loki

Trait Loki 

Source 
pub trait Loki: Fallback {
    // Provided methods
    fn work(&self, receiver: Receiver<LokiMessage>, data: Arc<LokiData>) { ... }
    fn work_batch(
        &self,
        level: &str,
        batch: &mut Vec<LokiMessage>,
        data: &Arc<LokiData>,
    ) -> Result<Response, ServiceError> { ... }
}
Expand description

The core logic provider for Loki interactions.

This trait defines how batches of logs are collected, formatted, and pushed. By implementing this trait, you can customize the batching strategy or adding custom logic (like GZIP compression) before sending.

§Required Hierarchy

Must implement LokiFallback to handle delivery failures.

Provided Methods§

Source

fn work(&self, receiver: Receiver<LokiMessage>, data: Arc<LokiData>)

Orchestrates the background worker loop.

This method is the entry point for the worker thread. It implements a double-buffer/drain strategy:

  1. It blocks on receiver.recv() until at least one message is available, ensuring zero CPU usage during idle periods.
  2. Once a message arrives, it performs a non-blocking try_recv loop to “drain” the channel and form a batch.
  3. It groups messages by their log level into a BTreeMap to maintain consistent stream ordering before calling work_batch.

This design assumes that network I/O is the bottleneck, allowing the in-memory collection of logs to be extremely fast.

Source

fn work_batch( &self, level: &str, batch: &mut Vec<LokiMessage>, data: &Arc<LokiData>, ) -> Result<Response, ServiceError>

Handles the transformation and transmission of a specific log batch.

This method performs the following steps:

  1. Serialization: Converts the batch of LokiMessage into a JSON payload compatible with the Loki Push API.
  2. Transmission: Sends the payload via a POST request.
  3. Retry Logic: If the request fails or returns a non-success status, it enters a retry loop up to the max_retries limit defined in LokiConfig.
  4. Safety Net: If all retries fail, it triggers the LokiFallback mechanism for every message in the batch.
  5. Cleanup: Clears the batch vector to prepare it for the next iteration, reusing the allocated memory capacity.
§Returns

Returns the last [Response] received from the server, or a ServiceError if the transmission was impossible.

Implementors§