DEV Community

Cover image for Go RabbitMQ to Kafka ETL with zero lines of Go!

Go RabbitMQ to Kafka ETL with zero lines of Go!

rubenwap profile image Ruben Sanchez ・4 min read

I think that for a big percentage of cases, ETL pipelines are a solved problem. Unless you have very special needs, there are many tools in the market that can remove the hassle of setting up irrelevant minutia, and let you focus on the business logic instead, because anyone can create a function that connects to a Rabbit MQ exchange, but only you can work on the task of how your business logic should handle the received messages. However, I am aware of the value that "reinventing the wheel" might have in some business aspects, when the off the shelf tools won't cut it. But in the event that off the shelf tools are good for you, let me introduce you to Benthos.

Captura de pantalla 2021-01-16 a las 19.40.18

What is Benthos

Benthos it's a tool that can perform streaming ETL tasks, so to speak, it can grab your stream source (Extract), apply some transformations (Transform) and send it to your desired sink/destination (Load). It's written in Go, and sorry for the clickbait title, sure it has a lot of Golang lines of code! But the whole point of this exercise is that it doesn't require you to write any in order to set your pipelines. It uses a yaml config file which is executed by the main binary.

Benthos handles for you some boring stuff such as parallelism, or creation of metrics in Prometheus, Influx, Cloudwatch, etc.. We are going to see how it behaves with the following task:

  • Getting a message from a Rabbit queue
  • Manipulating the payload
  • Sending the new payload to a Kafka topic

Getting started

For this exercise I have needed a docker-compose file so I could test Rabbit and Kafka in my local environment. If you were to deploy a Benthos job in an environment with an already existing instance of Rabbit and Kafka, you wouldn't worry about this, but let me share my docker-compose.yml file just in case

version: "3.6"

    image: 'rabbitmq:3.7-management-alpine'
    hostname: rabbitmq
      - 5672
      - 15672
      - "5672:5672"
      - "15672:15672"

    image: zookeeper:3.4.9
    hostname: zoo1
      - "2181:2181"
        ZOO_MY_ID: 1
        ZOO_PORT: 2181
        ZOO_SERVERS: server.1=zoo1:2888:3888

    image: confluentinc/cp-kafka:5.5.1
    hostname: kafka1
      - "9091:9091"
      KAFKA_ZOOKEEPER_CONNECT: "zoo1:2181"
      KAFKA_LOG4J_LOGGERS: "kafka.controller=INFO,kafka.producer.async.DefaultEventHandler=INFO,state.change.logger=INFO"
      - zoo1

    image: obsidiandynamics/kafdrop
    restart: "no"
      - "9000:9000"
      KAFKA_BROKERCONNECT: "kafka1:19091"
      - kafka1

    image: jeffail/benthos
      - 4195
      - "4195:4195"
      - ./pipeline:/pipeline
Enter fullscreen mode Exit fullscreen mode

Do a docker-compose up -d and let it start as long as needed, Rabbit is notoriously slow starting off. In the meantime let's create our Benthos pipeline.

The pipeline

You might have seen how in the previous docker compose file we mounted ./pipeline:/pipeline in the Benthos image. This is just because that's where I am going to store my pipeline file. Feel free to mount a different directory if you need.

So here are the contents of pipeline/benthos.yml

    url: amqp://guest:guest@rabbitmq:5672
    queue: "ruben"

    - sleep:
        duration: 500ms
    - bloblang: |
        root.original_event = this
        root.new_attr = "abc"
        root.new_attr2 = 123

      - kafka1:19091
    topic: ruben
    client_id: benthos_kafka_output
    key: ""
    partitioner: fnv1a_hash
    compression: none
    static_headers: {}
    max_in_flight: 1
      count: 0
      byte_size: 0
      period: ""
      check: ""
Enter fullscreen mode Exit fullscreen mode

The input and output sections are self explanatory, they just define the configuration of the brokers we are using. The middle section (pipeline) is a bit more involved, because it requires the usage of the custom Benthos components to manipulate messages. See all the available processors here

In my case, I am using the bloblang processor. You can see the details here. I am getting the input messages and applying a manipulation to their payload.

So that's it, that's the pipeline. I understand this is a toy example, but if you look at the documentation you can see how Benthos seems to be ready to tackle pretty serious cases.

Running the example

Let's start with Rabbit. I didn't really add a custom json configuration to this docker compose stack, so there are no custom queues when initializing. We can simply go to and create one (in my example, it's called ruben, as you can see in the benthos.yml file)

Captura de pantalla 2021-01-16 a las 19.43.12

Now we can do the same in Kafka. Open Kafdrop at and create a topic (I also named it ruben)

Captura de pantalla 2021-01-16 a las 19.44.17

Now we can now run Benthos with our config file:

docker-compose run benthos -c ./pipeline/benthos.yml
Enter fullscreen mode Exit fullscreen mode

If everything goes well, Benthos will start listening. Now,
send a message (or as many as you want) via the Rabbit interface. Remember that your processor in Benthos is now ready to handle json objects.

Captura de pantalla 2021-01-16 a las 19.47.47

Go to the Kafdrop interface and observe your messages arriving. Indeed, you have the original message, plus the two extra attributes that we have defined in our pipeline.

Captura de pantalla 2021-01-16 a las 19.48.51


While perhaps it doesn't match everyone's use case, Benthos looks like a pretty nice and easy to use alternative to create ETL pipelines in the Golang universe.

The entirety of the code is in this article, but if you need it to be in a GitHub repo, here it is

Discussion (0)

Editor guide