Getting AWS Elastic Load Balancer Logs into Honeycomb

To ingest AWS Elastic Load Balancer access logs (useful for visualizing questions such as “Which backend servers are taking the longest to answer requests?” or “Which calls to our app are returning non-200 HTTP status codes?”) Honeycomb provides a tool called honeyelb.

The source is available on Github and instructions for getting started are provided here.


Please use the following instructions to install honeyelb. It is available as part of the Honeycomb AWS Bundle or as a standalone binary.

wget -q && \
      echo 'c76cbc5636697ed39c17bc2a723eb4f4e1b01722030134bdaf0ae5955e51ff35  honeyaws_1.186_amd64.deb' | sha256sum -c && \
      sudo dpkg -i honeyaws_1.186_amd64.deb

honeyelb assumes access to an AWS access key ID and AWS secret access key with the proper permissions. It will attempt to obtain these via the default profile in ~/.aws/config, by the proper environment variables, or by an IAM EC2 instance profile. See the AWS guide on providing credentials for more details.

See the provided IAM policy JSON in the honeyelb repository for one example of a policy which has the proper permissions. This can be scoped down to more specific resources if desired.


honeyelb can be used interactively (meant for beginning exploration, debugging credential management, etc.) or as a daemon. Try running some commands interactively at first to get a feel for using the tool and then configure it to run as a proper system service when you’re ready to be ingesting continuously.


To show all ELBs, you can invoke honeyelb ls:

$ honeyelb ls

To ingest access logs from an ELB, use honeyelb ingest with one or more ELB names. The --writekey flag must be set to your write key (we have included yours in the examples below). By default the events will be sent to a dataset called aws-elb-access.

Note: If access logs are not configured for the ELB it will throw an error. Please see enable access logs for your Classic Load Balancers to enable this feature.

e.g. Ingesting logs from one ELB named frontend:

$ honeyelb --writekey=WRITEKEY \
  ingest frontend

You are currently logged in to the team, so we have populated the write key here to the first write key for that team.

Ingesting logs from multiple specific load balancers (named frontend, internal-service, and service-proxy):

$ honeyelb --writekey=WRITEKEY \
  ingest frontend internal-service service-proxy

honeyelb ingest without any arguments will use all available (“described”) load balancers in your configured AWS region. With arguments, it will ingest logs for the specified load balancer names.

$ honeyelb --writekey=WRITEKEY \
...ingesting logs from all LBs in DescribeLoadBalancers...

The agent will drop state files (to avoid sending duplicate events) in the current working directory where it is invoked by default. To modify where these files are kept, use the --statedir flag.


honeyelb, while supporting a interactive workflow for initial discovery and experimentation, is meant to be invoked as a long-running process by a system service manager.

To do this, edit the system init files (Upstart and systemd are supported) installed by the package manager to add the write key.

Exploration in Honeycomb

Once you receive data from honeyelb you will want to explore it. The descriptions of the sent fields is available in the AWS documentation for ELB access logs. There is one small difference: the client:port and backend:port keys from that guide are represented as client_authority and backend_authority in the Honeycomb events.

Here are some suggestions for things to try: