Notes on getting data into InfluxDB from Kafka with Kafka Connect

You can download the InfluxDB connector for Kafka Connect here. Documentation for it is here.

When a message from your source Kafka topic is written to InfluxDB the InfluxDB values are set thus:

Timestamp is taken from the Kafka message timestamp (which is either set by your producer, or the time at which it was received by the broker)
Tag(s) are taken from the tags field in the message. This field must be a map type - see below
Value fields are taken from the rest of the message, and must be numeric or boolean
Measurement name can be specified as a field of the message, or hardcoded in the connector config.

Jan 22, 2020

Kafka Connect and Schemas

Here’s a fun one that Kafka Connect can sometimes throw out:

java.lang.ClassCastException: 
java.util.HashMap cannot be cast to org.apache.kafka.connect.data.Struct

HashMap? Struct? HUH?

Jan 21, 2020

Monitoring Sonos with ksqlDB, InfluxDB, and Grafana

I’m quite a fan of Sonos audio equipment but recently had some trouble with some of the devices glitching and even cutting out whilst playing. Under the covers Sonos stuff is running Linux (of course) and exposes some diagnostics through a rudimentary frontend that you can access at http://<sonos player IP>:1400/support/review: Whilst this gives you the current state, you can’t get historical data on it. It felt like the problems were happening "all the time", but were they actually?

Jan 16, 2020

Changing the Logging Level for Kafka Connect Dynamically

Logs are magical things. They tell us what an application is doing—or not doing. They help us debug problems. As it happens, they also underpin the entire philosophy of Apache Kafka, but that’s a story for another day. Today we’re talking about logs written by Kafka Connect, and how we can change the amount of detail written. By default, Kafka Connect will write logs at INFO and above. So when it starts up, the settings that it’s using, and any WARN or ERROR messages along the way - a missing configuration, a broken connector, and so on.

Jan 8, 2020

Streaming messages from RabbitMQ into Kafka with Kafka Connect

This was prompted by a question on StackOverflow to which I thought the answer would be straightforward, but turned out not to be so. And then I got a bit carried away and ended up with a nice example of how you can handle schema-less data coming from a system such as RabbitMQ and apply a schema to it. Note This same pattern for ingesting bytes and applying a schema will work with other connectors such as MQTT What?

Dec 20, 2019

Analysing network behaviour with ksqlDB and MongoDB

In this post I want to build on my previous one and show another use of the Syslog data that I’m capturing. Instead of looking for SSH attacks, I’m going to analyse the behaviour of my networking components. Note You can find all the code to run this on GitHub. Getting Syslog data into Kafka As before, let’s create ourselves a syslog connector in ksqlDB: CREATE SOURCE CONNECTOR SOURCE_SYSLOG_UDP_01 WITH ( 'tasks.

Dec 18, 2019

Detecting and Analysing SSH Attacks with ksqlDB

I’ve written previously about ingesting Syslog into Kafka and using KSQL to analyse it. I want to revisit the subject since it’s nearly two years since I wrote about it and some things have changed since then. ksqlDB now includes the ability to define connectors from within it, which makes setting things up loads easier. You can find the full rig to run this on GitHub. Create and configure the Syslog connector To start with, create a source connector:

Nov 29, 2019

Kafka Connect - Request timed out

A short & sweet blog post to help people Googling for this error, and me next time I encounter it.

The scenario: trying to create a connector in Kafka Connect (running in distributed mode, one worker) failed with the curl response

HTTP/1.1 500 Internal Server Error
Date: Fri, 29 Nov 2019 14:33:53 GMT
Content-Type: application/json
Content-Length: 48
Server: Jetty(9.4.18.v20190429)

{"error_code":500,"message":"Request timed out"}

Nov 22, 2019

Common mistakes made when configuring multiple Kafka Connect workers

Kafka Connect can be deployed in two modes: Standalone or Distributed. You can learn more about them in my Kafka Summit London 2019 talk. I usually recommend Distributed for several reasons: It can scale It is fault-tolerant It can be run on a single node sandbox or a multi-node production environment It is the same configuration method however you run it I usually find that Standalone is appropriate when:

Nov 20, 2019

Streaming data from SQL Server to Kafka to Snowflake ❄️ with Kafka Connect

Snowflake is the data warehouse built for the cloud, so let’s get all ☁️ cloudy and stream some data from Kafka running in Confluent Cloud to Snowflake! What I’m showing also works just as well for an on-premises Kafka cluster. I’m using SQL Server as an example data source, with Debezium to capture and stream and changes from it into Kafka. I’m assuming that you’ve signed up for Confluent Cloud and Snowflake and are the proud owner of credentials for both.