///
In Zario, **Transports** are the mechanisms responsible for sending your log messages to their final destinations. Whether you want to output logs to the console, write them to files, or send them to
41 views
~41 views from guests
Guest views are estimated from total page views. These include anonymous visitors and users who weren't logged in when they viewed the page.
In Zario, Transports are the mechanisms responsible for sending your log messages to their final destinations. Whether you want to output logs to the console, write them to files, or send them to a remote server, transports handle the actual I/O operations.
A single Logger instance can be configured with multiple transports, allowing each log message to be processed and emitted by all attached transports simultaneously.
Transport InterfaceAll Zario transports adhere to the [Transport Interface], ensuring a consistent contract for how log data is processed and written.
write(data: LogData, formatter: Formatter): void: This method is called by the Logger when logging in synchronous mode (asyncMode: false). It's responsible for immediately writing the formatted log data to its destination.writeAsync?(data: LogData, formatter: Formatter): Promise<void>: This optional method is called when logging in asynchronous mode (asyncMode: true). If implemented, the transport performs its write operation non-blocking, returning a promise. If a transport does not implement writeAsync, Zario falls back to using setImmediate with the synchronous write method.TransportConfig Union TypeWhen configuring a Logger, the transports option ([Configuration Options - transports]) expects an array of TransportConfig. This is a [union type] that allows for flexibility in how transports are defined:
While Zario supports a LegacyTransportOptions object for backward compatibility (where you specify a type like "console" or "file"), the recommended modern approach is to directly provide instances of transport classes. This allows for full TypeScript safety, direct access to transport-specific options, and better extensibility.
All examples below will demonstrate the recommended approach of instantiating transport classes directly.
ConsoleTransportThe ConsoleTransport is the simplest and most common transport, designed for outputting log messages directly to the Node.js console (stdout/stderr).
It's ideal for development environments, debugging, and situations where immediate, human-readable feedback is crucial. It intelligently uses console.log, console.warn, and console.error based on the log level.
ConsoleTransportOptions)colorize?: boolean
colorize setting of the logger specifically for this console transport. This allows you to have colored console output even if your file or HTTP transports are configured for non-colored, structured JSON.trueconsole methods.console.error for error level, console.warn for warn level, and console.log for all other levels.colorize setting.FileTransportThe FileTransport enables writing log messages to a local file system. It's a robust solution for persisting logs, especially useful in production environments where you need a record of application events.
It's designed to handle large volumes of logs efficiently, with built-in features for file rotation, cleanup of old files, and optional compression, preventing log files from consuming excessive disk space.
FileTransportOptions)path: string (Required)
maxSize?: number
10 * 1024 * 1024 (10 MB)maxFiles?: number
5compression?: CompressionType
'none''gzip', 'deflate', 'none'batchInterval?: number
0 means logs are written immediately (no batching). Batching can improve performance for high-volume logging by reducing file I/O frequency.0 (no batching)compressOldFiles?: boolean
compression is enabled.truemaxSize, preventing single files from becoming too large.maxFiles.gzip and deflate compression for rotated files, significantly reducing storage requirements.batchInterval.asyncMode, minimizing blocking I/O operations.destroy() Method: Provides a way to gracefully shut down the transport and flush any remaining batched logs.HttpTransportThe HttpTransport is designed for sending structured log data to a remote HTTP(S) endpoint, typically a log aggregation service (e.g., ELK Stack, Splunk, custom logging APIs).
It facilitates centralized log collection, enabling advanced analytics, monitoring, and alerting across distributed systems.
HttpTransportOptions)url: string (Required)
method?: string
'POST'headers?: Record<string, string>
Authorization tokens, X-API-Key).{ 'Content-Type': 'application/json' }timeout?: number
5000 (5 seconds)retries?: number
3method, headers, and timeout.asyncMode: true.FilterableTransportThe FilterableTransport acts as a wrapper around another transport, allowing you to apply specific filters to logs before they are passed to the underlying transport. This enables fine-grained control over which log messages reach a particular destination.
It's useful for scenarios where you want a subset of your logs to go to a specific destination. For example, sending only error logs to a monitoring service, or only debug logs from a specific module to a file.
FilterableTransport Constructor)The FilterableTransport itself doesn't have options beyond its constructor parameters:
transport: Transport (Required)
ConsoleTransport, FileTransport, HttpTransport).filters: Filter[] (Required)
true for the log message to be passed to the wrapped transport. If any filter returns false, the log is discarded by the FilterableTransport.Transport implementation.