Part 1 - The Snowplow Collector

Part 1 - The Snowplow Collector

Scroll Down

In the previous post, we discussed the benefits of using Snowplow Analytics and why it's important for modern businesses to own their analytics data.

In this post we're going to jump into setting up a Snowplow Collector through Terraform. We're going to be using the Scala Stream Collector to do this and we'll be securing our collector behind SSL to keep our customer's data safe.

It may be helpful to check out the Github repo associated with this series, while following along!

If you're just starting with this chapter, it may also be helpful to check out the other Snowplow Analytics tutorials or learn more about using Terraform.

If you're interested in topics like this, why not subscribe to the blog?

What is a collector?

The collector is an HTTP endpoint that your apps can communicate with to store analytics data. It is designed to be reliable and to store large quantities of data that are thrown at it.

For example: If a user clicks a link on your website, that'd be an event. This event will be sent by your application to a collector that will hand it over to your backend analytics system for further processing.

Which collector are we using?

There a number of Snowplow Collectors to choose from. In this post, we'll be setting up a Scala Stream Collector.

The reason we're choosing this collector, is that it takes away some of the moving parts in Snowplow, that would need to be configured. The less moving parts, the most stable our analytics system and the more time we can spend doing what matters.

We're also going to use the Scala Stream Collector because of the fact that it can be used for real-time analytics. In the future, I might write a post about how to make use of these real-time aspects of it. But in the meantime, it's a feature that can't quite be reached through the batch-processing techniques used historically and it can be really nice.

Our final directory structure will look like this:

- iam-users
- kinesis-stream
- snowplow-collector

Let's jump into this!

I think it's best to start out with the and files. They're how the whole thing can be configured and will lead you being able to use Terraform to deploy the rest of the infrastructure.

Here's the code from our file:

aws_access_key, aws_secret, aws_region are all pretty self-explanatory. If they aren't, you can check out my introduction to AWS.

key_pair_name is the name of the Key Pair that's stored in AWS that we'll use to SSH into the machine

key_pair_location is where on the hard drive we can find the private key associated with the Key Pair name we used earlier.

ssl_acm_arn is the ARN of the ACM (Amazon Certificate Manager) we'd like to use for SSL. This will make it so we can use HTTPS in our load balancer. This is important because of the fact that we want user usage data to remain encrypted in-transit to our servers.

The file is dedicated to connecting to AWS and creating the resources we're about to define.

Run terraform init to download the proper AWS provider files.

IAM User

Now let's create the user that our collector will run as. We will do so by defining an IAM users module in our configuration. By putting this into a module, we ensure that we can expand upon it later without cluttering up the root directory.

The directory structure will look like this:

- iam-users

Let's break down what each of those files do.

This file essentially follows these steps:

  1. Create the IAM user (snowplow-operator-datapipeline)

  2. Attach an Access Key to the user

  3. Attach a policy to the user that allows them to manipulate Kinesis streams

Really the only thing we care about for this user is their Access Key ID and their Secret Access Key. Using these keys, our collector will be able to identify as this user when speaking to the AWS API. Through identifying as the user, the collector will have access to our Kinesis streams.

Kinesis Streams

We're going to turn Kinesis streams into a module because it has some unnecessary information that we can abstract out, to prevent duplication. In this case, the fact that we want shard-level metrics.

The directory structure is going to look like this:

- kinesis-stream

Shard-level metrics are nice to have because they will let us keep track of how much data we're sending through the system. But it it can clutter up the configuration and distract from its main purpose.

The only inputs we care about for now are name, shard_count and retention_period. All of them (besides name) have some sane defaults.

Let's define the AWS Kinesis Stream resource with the variables we just created and shard-level metrics enabled.

The only output we care about is the stream's name. We'll use this to identify it and connect it with other resources.

Snowplow Collector Module

Now that we've set up the foundational modules, we can jump into writing our Snowplow collector module. This'll be the largest of our modules.

The directory structure will look like this:

- snowplow-collector
    - config.hocon.tpl

This module is going to take in a decent number of variables. Let's go through what each of them represent:

machine_ip - The IP of the machine that's running Terraform. The configuration keeps track of this in order to set up a very specific SSH rule that allows us to provision the instance after it is created.

key_pair_name and key_pair_loc - Details of the key pair that will allow us to SSH into the machine.

aws_region - The region in which we are creating these resources

good-stream-name - The stream in which our collector will place the good events. The events that aren't too large and follow the correct format.

bad-stream-name - The stream in which our collector will place bad events. These events are either too large or in an unknown format.

collector-version - The version of the Scala Stream Collector that we'd like to install on the machine

operator_access_key and operator_secret_key - We created a Snowplow Operator IAM User in an earlier part of this post. We need the access key for that user in order to allow the collector to operate on Kinesis streams.

ssl_acm_arn - The ARN at which we can find our SSL key (stored in Amazon Certificate Manager) for the domain on which the collector will sit.

We've gone through this configuration before. This data source will find the most recent AMI for Ubuntu 16.04 that's available.

Here we create the rules governing inbound and outbound communication for the collector server:

  • We're allowing inbound SSH connections from our computer's IP to help us provision the server after creation

  • We're allowing inbound HTTP connections from all machines

  • We're allowing all outbound connections so that we can download the proper packages and snowplow collector files

Here's where it all comes together for this module. Let's break this down slightly further, by resource:


This data source represents our configuration file. It loads config.hocon.tpl and replaces variable placeholders in the file (like ${good-stream-name} with the proper values from Terraform. In this context, this is often referred to as string interpolation.

Template files like this are extremely powerful because they allow us to configure software on the machine with contents we couldn't have known in advance. This ability is displayed here when we fill in ${access-key} and ${secret-key} with the values from the IAM user that we created earlier in the configuration.

We'll use this file in the next step!

This entire module is brought together in this one resource.
  • We use the AWS AMI (Ubuntu) that we found with the data source in for the operating system.

  • We add the key pair that we defined in to set up SSH access.

  • The security groups we defined in will be used to allow us to SSH into the machine, open up port 8080 to the public and open outbound connections for package installation

  • We're adding a Name tag to easily identify what this EC2 instance is doing, when looking through EC2 instances.

We're going to add two provisioning steps to this EC2 instance. We could later package these into the AMI once they become more widely used. But that wouldn't allow us to easily keep track and change them. It also wouldn't make for a very good, explanatory tutorial.

aws_instance.collector Provisioning

The provisioners are remote-exec provisioners. They will use the SSH details we've set up (in the connection attribute) to log into the machine after it has been created.

The inline attribute of the provisioners represent a list of commands to execute on the machine once an SSH connection has been established.

The first provisioner is going to log into the machine and install unzip and openjdk-8-jdk. These are needed to unzip and run the Scala Stream Collector, respectively.

The second provisioner does a few things:

  • Writes the configuration file to the server, with the template file we specified earlier.

  • Downloads the Scala Stream Collector zip file and unzips it into the home directory

  • Adds a reboot command to the crontab file so that whenever the machine is rebooted, it will restart the collector

  • Starts the collector with the configuration file (via nohup so it can leave SSH and the collector will remain running)

That's it for installing and running the collector!

This is the final configuration for this module. It sets up the ELB (Elastic Load Balancer) and points it at your instance.

We want a load balancer here for a couple reasons:

  1. The Elastic Load Balancer maintains stats on requests that go through it. Including how many of them are successful and how many of them fail. We can keep an eye on it to make sure the collector is working properly.

  2. If traffic gets too high, we can create more instances of the collector and put it behind the same load balancer to split the traffic up between the instances.

  3. The ELB gives us HTTPS easily and for free. We don't need to modify the collector at all and we can benefit from in-transit encryption. Due to the sensitive information analytics can contain, it'd be a good rule to always have HTTPS on your collector endpoint.

Here's the Terraform configuration file:

We give it a name and set up some availability zones to which it will route connections.

We create a listener that will listen on port 443, with an SSL-encrypted listener and point it at the HTTP port for our collector instance (port 8080). This will encrypt traffic through the internet but use HTTP within our own VPC.

Then we set up a health_check configuration. This health check will constantly ping our collector to make sure that it's still online. If it's not online, it will stop routing traffic to it.

Lastly, we connect up the the instances we've created for our collector.

Bringing it all together

In the root directory, we'll use all of these modules we've just created to complete our Snowplow Collector infrastructure.

After all of the modules we've created, this file is pretty self-explanatory!

Because the collector will essentially run itself from now on, all we should really need to care about is the Elastic Load Balancer's DNS name.

After you run terraform apply, you should get some output like the following:

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.


collector-elb-cname =

Final Step

The final step to setting up your collector is to point a CNAME record at it in your DNS settings.

To point at my collector, you would create a CNAME record for with analytics as the name and as the value.

We could then check that the collector is working by going to:

The https is important because we only opened port 443 on the machine. Going to the non-HTTPS port would time out. We did this to prevent our code from accidentally pointing at the insecure collector, in the future.

Moving forward

In future posts, I'll detail how to set up a streaming enrichment process and a data storage sink for our new collector, in Terraform!

If you'd like to be notified of future posts in this series, you can subscribe! You can also take a look at the Github page for this Terraform configuration we're working on.

  • Cory Finger
    About the Author

    Cory Finger

    I've been programming for 15 years and love making tutorials to help others to learn more about the practice. Topics ranging from Programming, Architecture, DevOps, Machine Learning, to Analytics!

View Comments

I Am Cory Finger

A professional programmer

Cory Finger

I've been programming professionally for 13 years and can still feel completely overwhelmed by the breadth and depth of all the technologies out there. I've composed a list of tips along the way, to help anyone who feels similarly!

Also, I live in Seattle and work at Crystal

Stay informed with our newsletter