You'll notice Timber offers a variety of methods for sending logs to Timber. While flexible, this can be confusing, and often it's hard to understand which method is best. This guides serves to help in that process, helping you to walk away with the best integration method for your scenario.
Timber attempts to be as flexible as possible, attempting to integrate with a variety of platforms, systems and languages. You can send log data to Timber by choosing your preferred integration method. To better understand which method you should use please continue reading.
In-app log delivery refers to the process of sending application log data to Timber directly within your app. For example, using Timber's Ruby library, you can send your Ruby app's logs directly to Timber without writing to
STDOUT or a file. While simple, this method has a number of drawbacks:
Simple to setup.
Does not require system level changes or installations.
If you're using one of Timber's libraries we'll automatically capture context and structure your logs.
Potential for data loss. The Timber libraries build a small in-memory buffer of data in order to send log data in batches. Our libraries are configured to flush at 950kb or after 2 seconds. If your app crashes unexpectedly, we'll attempt a final delivery, but it is not guaranteed depending on the crash reason. Therefore, it is possible to lose up to 2 seconds of data immediately before the crash.
Less reliable. Delivery failures are retried 3 times and then discarded to handle back-pressure. This ensures Timber does not disrupt your application's performance, but it also means that this log data is lost.
Less stable. Because you're coupling log delivery with your application there is the possibility that log delivery will disrupt your application's stability. While Timber has taken every measure possible to prevent this, many times it it outside of our control.
Platform & system log delivery refers to the process of sending log data to Timber outside of an application, such as tailing a file or forwarding Syslog logs to Timber.
Durable. If you configure your application to write to disk your log data is durable. It will survive application crashes and restarts.
Reliable. Log delivery is more reliable since you're writing log data to disk and using that as a buffer. Failures can be indefinitely retried until they succeed, allowing you to continue processing through the remaining buffer on disk.
Stable. Log delivery is decoupled from your application removing the risk that it could affect application stability.
Follows the 12 factor methodology best practices.
Difficult. This method involves more steps and requires system-level operational experience to connect all of the pieces.
Slower. This method is slower since there are more steps and configuration.
For serious production systems we highly recommend shipping logs external from your application by integrating directly with your platform or system. It is worth the time and effort to invest in this method to ensure you have log data when you need it.
For everyone else, our language libraries should be sufficient, especially for applications just starting out. This allows you to get up and running with very little effort and time.