1. Docs
2. Send Data to Honeycomb
3. Other Integrations
4. Databases
5. MySQL
6. RDS MySQL

Getting RDS logs for MySQL into Honeycomb

Amazon’s Relational Database Service (RDS) lets you use a number of databases without having to administer them yourself. The Honeycomb RDS connector gives you access to the same data as if you were running MySQL on your own server.

The Honeycomb RDS connector surfaces attributes like:

• The normalized query shape
• Time spent waiting to acquire lock
• Number of rows examined to execute the query
• Number of rows returned by MySQL
• … and more!

Honeycomb allows you to calculate metrics and statistics on the fly while retaining the full-resolution log lines (and the original MySQL query that started it all).

Once you’ve got data flowing, be sure to take a look at our starter queries; our entry points provide our recommendations for comparing lock retention by normalized query, scan efficiency by collection, or read vs. write distribution by host.

rdslogs CLI integration  🔗

rdslogs is a CLI tool that polls the RDS API for database instance logs, parses them, and submits them to Honeycomb.

Download the RDS connector (rdslogs)  🔗

rdslogs will stream the MySQL slow query log from RDS or download older log files. It can stream them to STDOUT or directly to Honeycomb. You can view the rdslogs source here.

Get and verify the current Linux version of rdslogs:

wget -q https://honeycomb.io/download/rdslogs/rdslogs_1.108_amd64.deb && \
      echo 'f289b871552170a88e8f5a545d4587343acda1e208a73ef92ae4dda8aa477a5d  rdslogs_1.108_amd64.deb' | sha256sum -c && \
      sudo dpkg -i rdslogs_1.108_amd64.deb

wget -q https://honeycomb.io/download/rdslogs/rdslogs-1.108-1.x86_64.rpm && \
      echo 'e48cdf912d803f97716ffe0dc89b61b9ac75b3d4489d22a022362323fecc93ab  rdslogs-1.108-1.x86_64.rpm' | sha256sum -c && \
      sudo rpm -i rdslogs-1.108-1.x86_64.rpm

wget -q -O rdslogs https://honeycomb.io/download/rdslogs/1.108 && \
      echo '0ec262bb22b5b3f26e17237c9f16d880684346cd2f28d0a505572714eb7c0489  rdslogs' | sha256sum -c && \
      chmod 755 ./rdslogs

Before you run the RDS connector  🔗

Before running the RDS connector, configure MySQL running on RDS to output the slow query log to a file. Refer to Amazon’s documentation on setting Parameter Groups to get started, and find more detail about the configuration options below in the MySQL docs for the slow query log.

Set the following options in the Parameter Group:

• log_output to FILE
• slow_query_log to 1
• long_query_time to 0
• log_queries_not_using_indexes to 1 (optional)

If you switch to a new Parameter Group when you make these changes, make sure you restart the database.

Stream current logs to Honeycomb  🔗

Use the rdslogs command with the --output flag set to honeycomb to connect to RDS and send data from the current log to Honeycomb.

You will need the following information:

• Your RDS instance identifier (from the instances page of the RDS Console)
• Your AWS region code (such as “us-west-1”)
• Your Honeycomb API key (from your Honeycomb account page)
  
  

rdslogs \
    -i <instance-identifier> \
    --region=<region-code> \
    --output=honeycomb \
    --writekey=YOUR_API_KEY \
    --dataset='RDS MySQL'

Use --sample_rate to send a subset (1/N log lines, defaults to N=1) of your data. Sampling in Honeycomb is described in detail in Sampling high volume data.

Backfill existing logs  🔗

If you’re getting started with Honeycomb, you can load the past 24 hours of logs into Honeycomb to start finding interesting things right away. Launch this command to run in the background (it will take some time) while you hook up the live stream. (However, if you just now enabled the slow query log, you won’t have the past 24 hours of logs. You can skip this step and go straight to streaming.)

The following command will download all available slow query logs to a newly created slow_logs directory and then start up honeytail to send the parsed events to Honeycomb. You’ll need your RDS instance identifier (from the instances page of the RDS Console) and your Honeycomb API key (from your Honeycomb account page).

mkdir slow_logs && \
    rdslogs \
    -i <instance-identifier> \
    --download --download_dir=slow_logs && \
    honeytail \
    --writekey=YOUR_API_KEY \
    --dataset='RDS MySQL' \
    --parser=mysql \
    --file='slow_logs/*' \
    --backfill

Once you’ve finished backfilling your old logs, we recommend transitioning to the default streaming behavior to stream current logs.

Scrub personally identifiable information  🔗

We believe strongly in the value of being able to track down the precise query causing a problem, but we also understand the concerns of exporting log data which may contain sensitive user information, so you have the option of hashing the contents of the data returned by a query.

To hash the concrete query, add the flag --scrub_query. The normalized_query attribute will still be representative of the shape of the query and identifying patterns (including specific queries) will still be possible, but the sensitive information will be completely obscured before leaving your servers.

For more information about dropping or scrubbing sensitive fields, see “Dropping or scrubbing fields” in the Agent documentation section.

Agentless Integration for MySQL Logs  🔗

As an alternative to using the rdslogs CLI tool, you can configure your RDS instance to mirror its logs to Cloudwatch Logs, then install the Agentless Integration for MySQL Logs. This integration is a Lambda function subscribed to your instance’s RDS Log Group. It parses log events as they arrive and submits them to Honeycomb. Note that configuring your RDS instance to send its logs to Cloudwatch will incur additional AWS costs - see the Cloudwatch Pricing docs for details.

Before you install the Agentless Integration  🔗

Before installing the integration, configure MySQL running on RDS to output the slow query log to a file. Refer to Amazon’s documentation on setting Parameter Groups to get started, and find more detail about the configuration options below in the MySQL docs for the slow query log.

Set the following options in the Parameter Group:

• log_output to FILE
• slow_query_log to 1
• long_query_time to 0
• log_queries_not_using_indexes to 1 (optional)

If you switch to a new Parameter Group when you make these changes, make sure you restart the database.

Next, enable publishing of MySQL slow query logs to AWS Cloudwatch Logs. You can do this in the RDS console in the instance configuration. See the AWS docs for full details.

This change can be done without instance downtime. Once you’ve made the above changes, verify that logs are being received by Cloudwatch Logs via the Cloudwatch Logs Console.

Install the Agentless Integration for Mysql Logs  🔗

The MySQL integration exists as an AWS Lambda function deployed in your AWS account. It subscribes to the Cloudwatch Log Group created by RDS, parses log lines, and submits them as events to Honeycomb. You can view the source here.

To install the integration, you will need:

• Access to your AWS account’s CloudFormation console
• Permission to create an IAM role in your AWS account
• Your Honeycomb API key

To get started, click this AWS quick-create link. This will launch the Cloudformation Stack creation wizard and will prompt you for a few key inputs:

• The MySQL Cloudwatch Log Group(s) you wish to monitor for events.
• Your Honeycomb API key (optionally encrypted).
• The dataset that will be the destination for log events.

Scrub personally identifiable information  🔗

To hash the concrete query, set the ScrubQuery parameter to true when installing the integration. The normalized_query attribute will still be representative of the shape of the query and identifying patterns (including specific queries) will still be possible, but the sensitive information will be completely obscured before being submitted to our API.