kennethreitz/12factor
1
0
Fork 0
mirror of https://github.com/kennethreitz/12factor.git synced 2026-06-05 23:10:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

logs tweaks

Browse Source
This commit is contained in:
Adam Wiggins
2011-06-05 00:50:51 -07:00
parent 6cf3383e02
commit fd640bb6df
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/logs.md
+5 -5
View File
@@ -1,12 +1,12 @@
## X. Logs
### Logs are event streams
Logs provide oversight and introspection of the behavior of a running app. Logs often appear as files on disk, but this is only one possible output format, not their true form.
*Logs* provide visibility into the behavior of a running app. While they are sometimes written to a file on disk, this is only an output format - not the essence of what logs really are.
Logs for a twelve-factor app are the aggregated, time-ordered output streams from all of the app's running processes and backing services. The logs have no fixed beginning or end, and can be thought of as a [stream of events](http://adam.heroku.com/past/2011/4/1/logs_are_streams_not_files/). This is typically represented as a text format with one event per line (though backtraces from exceptions may span multiple lines).
**Logs for a twelve-factor app are the [stream](http://adam.heroku.com/past/2011/4/1/logs_are_streams_not_files/) of aggregated, time-ordered events collected from the output streams of all its running processes and backing services.** Their raw form typically apepars as a text format with one event per line (though backtraces from exceptions may span multiple lines). The logs have no fixed beginning or end, but flow continously as long as the app is operating.
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its stream, unbuffered, to standard output (STDOUT). During local development, the developer will view this stream in the foreground of their terminal to observe the app's behavior.
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its stream, unbuffered, to `stdout`. During local development, the developer will view this stream in the foreground of their terminal to observe the app's behavior.
In deployment, each process' stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment.
In staging or production deploys, each process' stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment.
The event stream for an app can be routed to a file, or watched via realtime tail in a terminal. Most significantly, the stream can be sent to into an log indexing and analysis system such as Splunk, or a general-purpose data warehousing system such as Hadoop/Hive. These systems allow for great power and flexibility with introspecting the app's behavior over time: from finding specific events in the past, to large-scale graphing of trends (such as requests per minute), to active alerting according to user-defined heuristics (such as an alert when the quantity of errors per minute exceeds a certain threshold).
The event stream for an app can be routed to a file, or watched via realtime tail in a terminal. Most significantly, the stream can be sent to into an log indexing and analysis system such as [Splunk](http://www.splunk.com/), or a general-purpose data warehousing system such as [Hadoop/Hive](http://hive.apache.org/). These systems allow for great power and flexibility with introspecting the app's behavior over time: from finding specific events in the past, to large-scale graphing of trends (such as requests per minute), to active alerting according to user-defined heuristics (such as an alert when the quantity of errors per minute exceeds a certain threshold).