But a better conceptual model is to treat logs as time-ordered streams: there is no beginning or end, but rather an ongoing, collated collection of events which we may wish to view in realtime as they happen (e.g. via tail -f or heroku logs –tail) or which we may wish to search in some time window (e.g. via grep or Splunk).
Work on an app with a couple dozen servers, a handful of databases, and several moving parts and you start to realize that logs are one of your best friends. They’re useful for troubleshooting, performance monitoring, and just knowing how your application works in reality, under real traffic.
I’ve tinkered with building deeper APIs for logging within applications and services, but I think Adam Wiggins is on the right path here (not the first time either). Logging should be as simple as possible in applications. All the smarts for aggregating, searching, and extracting interesting information should happen after the data is collected. Using standard out instead of files is a fantastic idea too.