Using ActiveSupport::ExecutionContext to improve Rails logging

2025-12-05T00:00:00+00:00

If you’ve ever tried to debug a complex user workflow in a modern Rails application, you know how difficult it can be. A single web request can spawn multiple background jobs, Turbo Stream updates, and a flurry of database queries. Answering the question “What was this user doing?” should be simple, but tracing the flow of events through a web of log files can be difficult and time consuming.

You can add custom log tags but that gets tedious and messy fast. Fortunately, Rails has a powerful, under-documented feature designed specifically to address this problem: ActiveSupport::ExecutionContext.

In this post, we’ll walk through what ExecutionContext is and how you can use it to add meaningful structure to your logs, making debugging a much more straightforward task.

The Problem: A Tangled Web of Logs

Imagine a user places an order on your site. The OrdersController#create action fires, which then enqueues a ReceiptJob and an InventoryUpdateJob. The controller also renders a Turbo Stream to update the UI. You have at least four separate units of work: the HTTP request and three background tasks.

Now, if the InventoryUpdateJob fails, your log might show an exception, but it won’t immediately tell you which user’s order triggered it. You’re left grepping for job IDs or tracing timestamps. ExecutionContext solves this problem by providing a shared context that is automatically shared across these different units of work.

How ExecutionContext Works

Think of ActiveSupport::ExecutionContext as a container for data that automatically gets passed along. When you store something in it during a web request, that data is bundled up and made available in any background jobs you start from that request without you having to manually send it.

It’s important to note that while ActiveSupport::ExecutionContext values are available within the same process (e.g., during the web request), they don’t automatically serialize and propagate to background jobs. For the context to be available in jobs, you’ll need to explicitly pass relevant values as job arguments. In our example, since we’re already passing the order object to both jobs, we can access order.user_id and order.id directly in the job. For contexts without such natural carriers consider extracting the relevant values and passing them explicitly as additional job arguments.

This is the magic that allows you to trace a chain of events.

A Practical Example: Tracing an Order

Let’s implement a solution for the ordering scenario. Our goal is to tag every log line related to this specific order with the user’s ID and the order ID.

First, we’ll set the context in an around_action in our ApplicationController:

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  around_action :set_execution_context

  private

  def set_execution_context
    # We only set the context if a user is logged in.
    if current_user
      ActiveSupport::ExecutionContext[:user_id] = current_user.id
      # We can also trace requests
      ActiveSupport::ExecutionContext[:request_id] = request.request_id
    end

    yield
  ensure
    # Ensure the context is cleared after the request is done.
    ActiveSupport::ExecutionContext.clear
  end
end

# app/controllers/orders_controller.rb
class OrdersController < ApplicationController
  def create
    @order = current_user.orders.create!(order_params)

    # Update the context with the real order_id
    ActiveSupport::ExecutionContext[:order_id] = @order.id

    ReceiptJob.perform_later(@order)
    InventoryUpdateJob.perform_later(@order)

    respond_to do |format|
      format.turbo_stream
    end
  end
end

Because we used perform_later, Active Job will automatically serialize our ExecutionContext (containing user_id and order_id) and make it available when the job runs.

Let’s look at the InventoryUpdateJob:

# app/jobs/inventory_update_job.rb
class InventoryUpdateJob < ApplicationJob
  def perform(order)
    logger.info "Updating inventory for order"

    # ... your business logic ...
  end
end

Making the Context Visible in Logs

Setting the context is only half the battle; we also need to see it in our logs. We can do this by customizing Rails’s log formatter.

Here’s a simple formatter that appends the execution context to every log line:

# config/initializers/log_formatting.rb
class ContextAwareFormatter < Logger::Formatter
  def call(severity, time, progname, msg)
    context = ActiveSupport::ExecutionContext.to_h

    tags = context.map { |key, value| "#{key}=#{value}" }.join(" ")
    tags = "[#{tags}] " unless tags.empty?

    "#{time.utc.iso8601(3)} #{severity} ##{Process.pid} #{tags}#{msg2str(msg)}\n"
  end
end

# Apply it to the Rails logger
Rails.logger.formatter = ContextAwareFormatter.new

With this in place, a log line from our InventoryUpdateJob might now look like this:

2025-12-01T15:33:01.123 INFO #123 [user_id=1001 order_id=998842] Updating inventory for order

If that job fails, the stack trace will be prefixed with the same [user_id=1001 order_id=998842] context. You can instantly see which user and order were affected.

Going Beyond: Tagging Database Queries

One of the most powerful applications is tagging database queries. This is incredibly useful for identifying expensive queries related to a specific user in a production environment.

You can subscribe to the SQL event and include the context in the log:

# config/initializers/log_formatting.rb
ActiveSupport::Notifications.subscribe("sql.active_record") do |event|
  context = ActiveSupport::ExecutionContext.to_h
  next if context.empty?

  payload = event.payload
  sql_with_context = "/* #{context.map { |k, v| "#{k}:#{v}" }.join(', ')} */ #{payload[:sql]}"

  Rails.logger.debug("SQL: #{sql_with_context}")
end

Here is what that log line would look like:

DEBUG -- : SQL: /* user_id:1001, order_id:998842 */ SELECT "orders".* FROM "orders" WHERE "orders"."user_id" = $1 LIMIT $2  [["user_id", 1001], ["LIMIT", 1]]

The SQL notification subscriber will fire on every database query which in production could introduce noticeable overhead. Consider wrapping this functionality in a Rails.env.development? check or using feature flags to control its activation. Be mindful of this trade-off when adding context to high-volume SQL logging.

A Stitch in Time Saves Nine

ActiveSupport::ExecutionContext is a robust solution to a common problem in modern, event-driven Rails applications. It provides a clean, built-in mechanism for propagating context, which leads to more debuggable and observable systems.

The next time you find yourself lost in a sea of log files, remember this tool. By adding a few lines of code to set the context and customizing your log formatter, you can transform a chaotic log file into a well-organized story of what your application is doing for each and every user.

How to Analyze Application Logs and Extract Actionable Insights

2025-02-28T00:00:00+00:00

Photo by Timo C. Dinger on Unsplash

Logs often accumulate unnoticed—until something breaks. Then, they suddenly become vital tools for diagnosing issues. By combining just a few command-line techniques, you can quickly spot recurring problems, identify suspicious activity, and strengthen your application’s defenses.

Below is a sample error log we’ll reference in the examples:

[2025-01-01 12:34:56] [client 192.168.1.1:12345] PHP Notice: Undefined variable $foo in /var/www/html/index.php on line 45 | referer: http://example.com/index.php
[2025-01-01 12:34:56] [client 192.168.1.1:12345] PHP Notice: Undefined variable $foo in /var/www/html/index.php on line 45 | referer: http://example.com/index.php
[2025-01-01 12:34:57] [client 192.168.1.1:12345] PHP Notice: Undefined variable $foo in /var/www/html/index.php on line 45 | referer: http://example.com/index.php
[2025-01-01 12:35:00] [client 10.0.0.2:6789] PHP Warning: Division by zero in /var/www/html/script.php on line 23 | referer: http://example.com/script.php
[2025-01-01 13:35:01] [client 10.0.0.2:6789] PHP Warning: Division by zero in /var/www/html/script.php on line 23 | referer: http://example.com/script.php
[2025-01-01 13:36:10] [client 192.168.1.1:12345] PHP Fatal error: Call to undefined function baz() in /var/www/html/lib.php on line 78 | referer: http://example.com/index.php
[2025-01-01 14:36:11] [client 172.16.0.5:54321] PHP Fatal error: Call to undefined function baz() in /var/www/html/lib.php on line 78 | referer: http://example.com/index.php

A Note on Commands

Throughout this blog, you’ll notice repeated use of commands like awk, grep, sed, uniq, and sort. These tools are indispensable for log analysis, allowing you to filter, transform, and summarize data efficiently. Here are some tips for learning these tools:

Use man <command> (e.g., man awk) to access the manual and dive deeper into a specific command
Experiment with small examples to understand how commands like awk process patterns or how grep extracts data
For a broader look at how these commands enhance productivity, check out my blog post: Practical Linux Command Line Tips for Productivity and Efficiency

These commands are not just for log analysis—they’re powerful for any data manipulation task you encounter. With practice, they can become essential to your workflow.

1. Debugging Application Errors

1.1 Summarize Frequent Issues

sed -E 's/^\[.*\] //' error.log | sort | uniq -c | sort -nr

Purpose: Remove timestamps/client’s IP, then sort and count duplicates
Outcome: A quick snapshot of which errors appear most often

3 PHP Notice: Undefined variable $foo ...
2 PHP Warning: Division by zero ...
2 PHP Fatal error: Call to undefined function baz() ...

1.2 Categorize Errors by Type

grep -oE 'PHP [^:]+' error.log | sort | uniq -c | sort -nr

Purpose: Extract error types (e.g., Notice, Warning, Fatal error)
Outcome: Know whether notices, warnings, or fatal errors dominate

3 Notice
2 Warning
2 Fatal error

1.3 Find Problematic Scripts

awk -F'in ' '{print $2}' error.log | awk '{print $1}' | sort | uniq -c | sort -nr

Purpose: Identify which files generate the most errors
Outcome: Pinpoint error hotspots for focused debugging

3 /var/www/html/index.php
2 /var/www/html/script.php
2 /var/www/html/lib.php

2. Monitoring System Behavior

2.1 Track Problematic IPs

awk -F'\[client ' '{print $2}' error.log | awk -F':' '{print $1}' | sort | uniq -c | sort -nr

Purpose: Count how many errors each IP triggers
Outcome: Identify suspicious or high-traffic IPs

4 192.168.1.1
2 10.0.0.2
1 172.16.0.5

2.2 Spot High-Error Time Periods

awk -F'[][]' '{split($2, time, ":"); print $1, time[1]":"time[2]":00"}' error.log | sort | uniq -c | sort -nr

Purpose: Group errors by minute, revealing spikes or trends
Outcome: Correlate error surges with deployments or traffic peaks

3 2025-01-01 12:34:00
1 2025-01-01 14:36:00
1 2025-01-01 13:36:00
...

2.3 Analyze IP–Referer Pairs

grep "referer:" error.log | awk -F'\\[client ' '{print $2}' | awk -F':| referer: ' '{print $1, $3}' | sort | uniq -c | sort -nr

Purpose: Match IP addresses with the URLs they refer from
Outcome: Detect repeat offenders or malicious traffic patterns

3 192.168.1.1 Undefined variable $foo ...
2 10.0.0.2 Division by zero ...
1 172.16.0.5 Call to undefined function baz() ...

3. Enhancing Security

3.1 Watch Sensitive URLs

grep -E "admin|login" script_error_frequency.txt | sort -nr

Purpose: Flag frequent hits on admin or login pages
Outcome: Gauge whether sensitive endpoints are under attack

2 /var/www/html/login.php
2 /var/www/html/admin.php

3.2 Pinpoint Critical Times

grep -E "admin|login" error.log | awk -F'[][]' '{split($2, time, ":"); print $1, time[1]":"time[2]":00"}' | sort | uniq -c | sort -nr

Purpose: Identify specific time windows for sensitive access
Outcome: Cross-reference suspicious activity with your security logs

2 2025-01-01 12:34:00
1 2025-01-01 13:35:00
1 2025-01-01 12:35:00

Conclusion

These commands demonstrate how quickly you can glean insights from logs. With a little creativity, you can expand them to track response times, detect performance bottlenecks, and safeguard critical endpoints. Whether you’re tackling PHP errors or any other type of log data, the same principles apply: filter, sort, count, and investigate.

Curious to learn more? Combine these strategies with automation tools, integrate them into CI/CD pipelines, or hook them up to visual dashboards. Your logs will become a gold mine of actionable information.

Keeping our Windows Server clean

2019-09-27T00:00:00+00:00

Photo by Shawn O’Neil, used under CC BY 2.0, cropped from original

Introduction

I have been running websites and web applications under Windows Server for years, for both work and personal purposes. Most of them were small websites with a few daily visitors, but one particular case (a weather website I originally created as a hobby) grew over time to around one million page views per month.

The website is mostly ASP.NET, with some services and components written in PHP and Python, and uses MySQL for persistence (as well as a bunch of XML/PNG files to cache weather forecasts and weather imagery). As months passed by, I’ve discovered that the default IIS and Windows log files will grow drastically so, while checking its content periodically to detect issues and vulnerabilities, we need to take action to preserve free disk space and server performance.

Internet Information Services log files

In our IIS public folder (by default C:\inetpub) we will have a path logs\LogFiles. Inside that folder, the IIS service will create a set of folders, one per HTTP/FTP service that is running under our instance. How fast it will grow depends on many things, mainly traffic, but also website visibility and bad requests. But it will start to sooner or later consume our free disk space.

To prevent this, we can create a batch file that can be run on a daily basis from a scheduled task.

CleanIISLogs.bat

forfiles /D -10 /P "C:\inetpub\logs\LogFiles" /S /C "cmd /c del /f /q @path"

This script traverses through all files on the folder passed by parameter that are more than 10 days old, and for each file, it executes the del command in quiet mode. This script will search for all files within the folder and all subfolders that are more than 10 days old and delete them. After running the task, we should confirm that the used space was reduced:

HTTP Error logs

There is another location where different operating system logs are stored: C:\Windows\System32\LogFiles. And when we navigate there, we will find an HTTPERR folder which will also start consuming free space as our websites are visited. The log files in that folder will save information regarding HTTP errors from any API/Service running on our IIS instance.

So depending on the web traffic our applications have, it will grow faster or slower. But in any case, I recommend creating a batch file to clean old log files using the del command, and to run that file on a daily basis by configuring a scheduled task.

CleanHTTPERRLogs.bat

forfiles /D -10 /P "C:\Windows\System32\LogFiles\HTTPERR" /C "cmd /c del /f /q @path"

This script, just as the previous one, will search for all files more than 10 days old and delete them. We don’t need to search for subfolders in this case because of Windows storing all HTTPERR logs at the same level. After running the task, we can open the folder properties and check that the used space will be the roughly the same over the days:

(I know, still 1 GB after cleanup, gotta do something about those bad requests!)

Compressing files

If we need to comply with strict security/auditing policies, and if we don’t have a backup device with enough capacity, deleting old files might not be an option. If that’s the case, we can compress the files to save space on disk.

So an alternative would be to create a script to compress the files instead of deleting them using the compact command. This is an example of a batch file that will compress all files in the IIS LogFiles folder that are more than 10 days old.

CompressIISLogs.bat

forfiles /D -10 /P "C:\inetpub\logs\LogFiles" /S /C "cmd /c compact @path"

And of course, we can create more scripts for other locations, like the C:\Windows\Temp folder for example. I mentioned earlier that my website creates a lot of XML and PNG files: I have another script whose mission is keeping those folders at bay, deleting forecast files that haven’t been used for more than one day (the local forecast will be outdated and would need to refresh it from the external web service anyway).

More resources from Microsoft

Logstash: Removing fields with empty values

2017-11-22T00:00:00+00:00

The Elastic stack is a nice toolkit for collecting, transporting, transforming, aggregating, searching, and reporting on log data from many sources. It was formerly known as the ELK stack, after its main components Elasticsearch, Logstash, and Kibana, but with the addition of Beats and other tools, the company now calls it simply the Elastic stack.

We are using it in a common configuration, on a central log server that receives logs via rsyslog over TLS, which are then stored in local files and processed further by Logstash.

When conservation is recommended

When forwarding logs on to SaaS log services such as Logentries, SumoLogic, etc., we have a limited amount of data transfer and storage allotted to us. So we need to either economize on what we send them, pay for a more expensive plan, or retain a shorter period of history.

For some very busy logs (nginx logs in JSON format) we decided to delete fields with empty values from the log event during the filter phase in Logstash. This removes a lot of data from the log message we send to the log service over the wire, and reduces the size of each log event stored in their system.

I expected this to be simple, but that expectation sometimes proves to be false. :)

Trying the prune filter

The most obvious way would be to use the Logstash prune filter, which is designed for just such a use case. However, the prune filter doesn’t handle nested keys, as explained in the documentation:

NOTE: This filter currently only support operations on top-level fields, i.e. whitelisting and blacklisting of subfields based on name or value does not work.

That is too bad.

Pruning with custom Ruby code

Several people have posted alternative solutions to this in the past. A representative recipe to have Logstash delete empty fields looked like this:

# This doesn’t work in Logstash 5 and newer ...
filter {
  ruby {
    code => "event.to_hash.delete_if {|field, value| value == '' }"
  }
}

And sadly, it doesn’t work.

Logstash 5 event API changes

It used to work with older versions of Logstash, but no longer. Logstash was originally written in Ruby, specifically JRuby for running on the JVM. But for Logstash 5 it was rewritten in Java, and though JRuby extensions are still possible, the Ruby event API has changed so that the log data is no longer provided as a mutable hash that the above code expects. (See also the Logstash event API documentation.)

Custom Ruby code to prune in Logstash 5+

So I came up with Ruby code that works using the new Logstash event API. It is more complicated , but it is still pretty straightforward:

filter {
  # remove fields with empty values
  ruby {
    code => "
      def walk_hash(parent, path, hash)
        path << parent if parent
        hash.each do |key, value|
          walk_hash(key, path, value) if value.is_a?(Hash)
          @paths << (path + [key]).map {|p| '[' + p + ']' }.join('')
        end
        path.pop
      end

      @paths = []
      walk_hash(nil, [], event.to_hash)

      @paths.each do |path|
        value = event.get(path)
        event.remove(path) if value.nil? || (value.respond_to?(:empty?) && value.empty?)
      end
    "
  }
}

We first recursively walk through the whole data structure that the API converts to a Ruby hash for us. We get all nested field names and store in an array their Logstash-style paths like "[nginx][access][upstream_addr]" that the API expects. Then we walk through the paths and use the API to check for empty values, and remove them. This way we also avoid changing the hash while still walking through it.

With that configuration and code in a file in /etc/logstash/conf.d/ (this is on CentOS 7 using the logstash RPM from Elastic) all the fields with empty values are removed.

Some other log event trimming

In addition we added a few other filters to remove or limit the size of fields that we are happy to have on our own central log server for archival or forensic purposes, but that we don’t need to send to our paid log service for the kinds of reporting we are doing there:

mutate {
  remove_field => [
    "@version", "beat", "host", "input_type", "offset", "source", "type",
    "[geoip][location]",
    "[nginx][access][pipe]",
    "[nginx][access][remote_port]",
    "[nginx][access][ssl_session_id]",
    "[nginx][access][ssl_session_reused]",
    "[nginx][access][upstream_bytes_received]",
    "[nginx][access][upstream_connect_time]",
    "[nginx][access][upstream_response_length]",
    "[nginx][access][upstream_status]"
  ]
}

if "beats_input_codec_plain_applied" in [tags] {
  mutate {
    remove_tag => ["beats_input_codec_plain_applied"]
  }
}

truncate {
  length_bytes => 1024
}

For example, sometimes the client sends an absurdly long HTTP Referer request header, or the URI requested is very long—we see plenty longer than 5000 characters. We are happy to truncate those to save space.

We also do not need to waste space in our paid log service with the repetitive tag beats_input_codec_plain_applied or the same Filebeat version in every single log event.

Finis

This is working for us on Logstash 5.6.3, but should work on Logstash 5.0 and newer.

Dear PostgreSQL: Where are my logs?

2014-11-12T00:00:00+00:00

Photo by Jitze Couperus

When debugging a problem, it’s always frustrating to get sidetracked hunting down the relevant logs. PostgreSQL users can select any of several different ways to handle database logs, or even choose a combination. But especially for new users, or those getting used to an unfamiliar system, just finding the logs can be difficult. To ease that pain, here’s a key to help dig up the correct logs.

Where are log entries sent?

First, connect to PostgreSQL with psql, pgadmin, or some other client that lets you run SQL queries, and run this:

foo=# show log_destination ;
 log_destination 
-----------------
 stderr
(1 row)

The log_destination setting tells PostgreSQL where log entries should go. In most cases it will be one of four values, though it can also be a comma-separated list of any of those four values. We’ll discuss each in turn.

Syslog

Syslog is a complex beast, and if your logs are going here, you’ll want more than this blog post to help you. Different systems have different syslog daemons, those daemons have different capabilities and require different configurations, and we simply can’t cover them all here. Your syslog may be configured to send PostgreSQL logs anywhere on the system, or even to an external server. For your purposes, though, you’ll need to know what ident and facility you’re using. These values tag each syslog message coming from PostgreSQL, and allow the syslog daemon to sort out where the message should go. You can find them like this:

foo=# show syslog_facility ;
 syslog_facility 
-----------------
 local0
(1 row)

foo=# show syslog_ident ;
 syslog_ident 
--------------
 postgres
(1 row)

Syslog is often useful, in that it allows administrators to collect logs from many applications into one place, to relieve the database server of logging I/O overhead (which may or may not actually help anything), or any number of other interesting rearrangements of log data.

Event Log

For PostgreSQL systems running on Windows, you can send log entries to the Windows event log. You’ll want to tell Windows to expect the log values, and what “event source” they’ll come from. You can find instructions for this operation in the PostgreSQL documentation discussing server setup.

stderr

This is probably the most common log destination (it’s the default, after all) and can get fairly complicated in itself. Selecting stderr instructs PostgreSQL to send log data to the “stderr” (short for “standard error”) output stream most operating systems give every new process by default. The difficulty is that PostgreSQL or the applications that launch it can then redirect this stream to all kinds of different places. If you start PostgreSQL manually with no particular redirection in place, log entries will be written to your terminal:

[josh@eddie ~]$ pg_ctl -D $PGDATA start
server starting
[josh@eddie ~]$ LOG:  database system was shut down at 2014-11-05 12:48:40 MST
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  statement: select syntax error;
ERROR:  column "syntax" does not exist at character 8
STATEMENT:  select syntax error;

In these logs you’ll see the logs from me starting the database, connecting to it from some other terminal, and issuing the obviously erroneous command “select syntax error”. But there are several ways to redirect this elsewhere. The easiest is with the pg_ctl -l option, which essentially redirects stderr to a file, in which case the startup looks like this:

[josh@eddie ~]$ pg_ctl -l logfile -D $PGDATA start
server starting

Finally, you can also tell PostgreSQL to redirect its stderr output internally, with the logging_collector option (which older versions of PostgreSQL named redirect_stderr). This can be on or off, and when on, collects stderr output into a configured log directory.

So if you see a log_destination set to stderr, a good next step is to check logging_collector:

foo=# show logging_collector ;
 logging_collector 
-------------------
 on
(1 row)

In this system, logging_collector is turned on, which means we have to find out where it’s collecting logs. First, check log_directory. In my case, below, it’s an absolute path, but by default it’s the relative path pg_log. This is relative to the PostgreSQL data directory. Log files are named according to a pattern in log_filename. Each of these settings is shown below:

foo=# show log_directory ;
      log_directory      
-------------------------
 /home/josh/devel/pg_log
(1 row)

foo=# show data_directory ;
       data_directory       
----------------------------
 /home/josh/devel/pgdb/data
(1 row)

foo=# show log_filename ;
          log_filename          
--------------------------------
 postgresql-%Y-%m-%d_%H%M%S.log
(1 row)

Documentation for each of these options, along with settings governing log rotation, is available in the PostgreSQL Error Reporting and Logging documentation.

If logging_collector is turned off, you can still find the logs using the /proc filesystem, on operating systems equipped with one. First you’ll need to find the process ID (pid) of a PostgreSQL process, which is simple enough:

foo=# select pg_backend_pid() ;
 pg_backend_pid 
----------------
          31950
(1 row)

Then, check /proc/YOUR_PID_HERE/fd/2, which is a symlink to the log destination:

[josh@eddie ~]$ ll /proc/31113/fd/2
lrwx------ 1 josh josh 64 Nov  5 12:52 /proc/31113/fd/2 -> /var/log/postgresql/postgresql-9.2-local.log

CSV log

The csvlog mode creates logs in CSV format, designed to be easily machine-readable. In fact, this section of the PostgreSQL documentation even provides a handy table definition if you want to slurp the logs into your database. CSV logs are produced in a fixed format the administrator cannot change, but it includes fields for everything available in the other log formats. For these to work, you need to have logging_collector turned on; without logging_collector, the logs simply won’t show up anywhere.

But when configured correctly, PostgreSQL will create CSV format logs in the log_directory, with file names mostly following the log_filename pattern. Here’s my example database, with log_destination set to stderr, csvlog and logging_collector turned on, just after I start the database and issue one query:

[josh@eddie ~/devel/pg_log]$ ll
total 8
-rw------- 1 josh josh 611 Nov 12 16:30 postgresql-2014-11-12_162821.csv
-rw------- 1 josh josh 192 Nov 12 16:30 postgresql-2014-11-12_162821.log

The CSV log output looks like this:

[josh@eddie ~/devel/pg_log]$ cat postgresql-2014-11-12_162821.csv 
2014-11-12 16:28:21.700 MST,,,2993,,5463ed15.bb1,1,,2014-11-12 16:28:21 MST,,0,LOG,00000,"database system was shut down at 2014-11-12 16:28:16 MST",,,,,,,,,""
2014-11-12 16:28:21.758 MST,,,2991,,5463ed15.baf,1,,2014-11-12 16:28:21 MST,,0,LOG,00000,"database system is ready to accept connections",,,,,,,,,""
2014-11-12 16:28:21.759 MST,,,2997,,5463ed15.bb5,1,,2014-11-12 16:28:21 MST,,0,LOG,00000,"autovacuum launcher started",,,,,,,,,""
2014-11-12 16:30:46.591 MST,"josh","josh",3065,"[local]",5463eda6.bf9,1,"idle",2014-11-12 16:30:46 MST,2/10,0,LOG,00000,"statement: select 'hello, world!';",,,,,,,,,"psql"

Using ActiveSupport::​ExecutionContext to improve Rails logging