Kafka and Google BigQuery Integration
Powerful performance with an easy integration, powered by Telegraf, the open source data connector built by InfluxData.
5B+
Telegraf downloads
#1
Time series database
Source: DB Engines
1B+
Downloads of InfluxDB
2,800+
Contributors
Table of Contents
Powerful Performance, Limitless Scale
Collect, organize, and act on massive volumes of high-velocity data. Any data is more valuable when you think of it as time series data. with InfluxDB, the #1 time series platform built to scale with Telegraf.
See Ways to Get Started
Input and output integration overview
This plugin allows you to gather metrics from Kafka topics in real-time, enhancing data monitoring and collection capabilities within your Telegraf setup.
The Google BigQuery plugin allows Telegraf to write metrics to Google Cloud BigQuery, enabling robust data analytics capabilities for telemetry data.
Integration details
Kafka
The Kafka Telegraf plugin is designed to read data from Kafka topics and create metrics using supported input data formats. As a service input plugin, it listens continuously for incoming metrics and events, differing from standard input plugins that operate at fixed intervals. This particular plugin can utilize features from various Kafka versions and is capable of consuming messages from specified topics, applying configurations such as security credentials using SASL, and managing message processing with options for message offsets and consumer groups. The flexibility of this plugin allows it to handle a wide array of message formats and use cases, making it a valuable asset for applications relying on Kafka for data ingestion.
Google BigQuery
The Google BigQuery plugin for Telegraf enables seamless integration with Google Cloud’s BigQuery service, a popular data warehousing and analytics platform. This plugin facilitates the transfer of metrics collected by Telegraf into BigQuery datasets, making it easier for users to perform analyses and generate insights from their telemetry data. It requires authentication through a service account or user credentials and is designed to handle various data types, ensuring that users can maintain the integrity and accuracy of their metrics as they are stored in BigQuery tables. The configuration options allow for customization around dataset specifications and handling metrics, including the management of hyphens in metric names, which are not supported by BigQuery for streaming inserts. This plugin is particularly useful for organizations leveraging the scalability and powerful query capabilities of BigQuery to analyze large volumes of monitoring data.
Configuration
Kafka
[[inputs.kafka_consumer]]
## Kafka brokers.
brokers = ["localhost:9092"]
## Set the minimal supported Kafka version. Should be a string contains
## 4 digits in case if it is 0 version and 3 digits for versions starting
## from 1.0.0 separated by dot. This setting enables the use of new
## Kafka features and APIs. Must be 0.10.2.0(used as default) or greater.
## Please, check the list of supported versions at
## https://pkg.go.dev/github.com/Shopify/sarama#SupportedVersions
## ex: kafka_version = "2.6.0"
## ex: kafka_version = "0.10.2.0"
# kafka_version = "0.10.2.0"
## Topics to consume.
topics = ["telegraf"]
## Topic regular expressions to consume. Matches will be added to topics.
## Example: topic_regexps = [ "*test", "metric[0-9A-z]*" ]
# topic_regexps = [ ]
## When set this tag will be added to all metrics with the topic as the value.
# topic_tag = ""
## The list of Kafka message headers that should be pass as metric tags
## works only for Kafka version 0.11+, on lower versions the message headers
## are not available
# msg_headers_as_tags = []
## The name of kafka message header which value should override the metric name.
## In case when the same header specified in current option and in msg_headers_as_tags
## option, it will be excluded from the msg_headers_as_tags list.
# msg_header_as_metric_name = ""
## Set metric(s) timestamp using the given source.
## Available options are:
## metric -- do not modify the metric timestamp
## inner -- use the inner message timestamp (Kafka v0.10+)
## outer -- use the outer (compressed) block timestamp (Kafka v0.10+)
# timestamp_source = "metric"
## Optional Client id
# client_id = "Telegraf"
## Optional TLS Config
# enable_tls = false
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false
## Period between keep alive probes.
## Defaults to the OS configuration if not specified or zero.
# keep_alive_period = "15s"
## SASL authentication credentials. These settings should typically be used
## with TLS encryption enabled
# sasl_username = "kafka"
# sasl_password = "secret"
## Optional SASL:
## one of: OAUTHBEARER, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, GSSAPI
## (defaults to PLAIN)
# sasl_mechanism = ""
## used if sasl_mechanism is GSSAPI
# sasl_gssapi_service_name = ""
# ## One of: KRB5_USER_AUTH and KRB5_KEYTAB_AUTH
# sasl_gssapi_auth_type = "KRB5_USER_AUTH"
# sasl_gssapi_kerberos_config_path = "/"
# sasl_gssapi_realm = "realm"
# sasl_gssapi_key_tab_path = ""
# sasl_gssapi_disable_pafxfast = false
## used if sasl_mechanism is OAUTHBEARER
# sasl_access_token = ""
## SASL protocol version. When connecting to Azure EventHub set to 0.
# sasl_version = 1
# Disable Kafka metadata full fetch
# metadata_full = false
## Name of the consumer group.
# consumer_group = "telegraf_metrics_consumers"
## Compression codec represents the various compression codecs recognized by
## Kafka in messages.
## 0 : None
## 1 : Gzip
## 2 : Snappy
## 3 : LZ4
## 4 : ZSTD
# compression_codec = 0
## Initial offset position; one of "oldest" or "newest".
# offset = "oldest"
## Consumer group partition assignment strategy; one of "range", "roundrobin" or "sticky".
# balance_strategy = "range"
## Maximum number of retries for metadata operations including
## connecting. Sets Sarama library's Metadata.Retry.Max config value. If 0 or
## unset, use the Sarama default of 3,
# metadata_retry_max = 0
## Type of retry backoff. Valid options: "constant", "exponential"
# metadata_retry_type = "constant"
## Amount of time to wait before retrying. When metadata_retry_type is
## "constant", each retry is delayed this amount. When "exponential", the
## first retry is delayed this amount, and subsequent delays are doubled. If 0
## or unset, use the Sarama default of 250 ms
# metadata_retry_backoff = 0
## Maximum amount of time to wait before retrying when metadata_retry_type is
## "exponential". Ignored for other retry types. If 0, there is no backoff
## limit.
# metadata_retry_max_duration = 0
## When set to true, this turns each bootstrap broker address into a set of
## IPs, then does a reverse lookup on each one to get its canonical hostname.
## This list of hostnames then replaces the original address list.
## resolve_canonical_bootstrap_servers_only = false
## Strategy for making connection to kafka brokers. Valid options: "startup",
## "defer". If set to "defer" the plugin is allowed to start before making a
## connection. This is useful if the broker may be down when telegraf is
## started, but if there are any typos in the broker setting, they will cause
## connection failures without warning at startup
# connection_strategy = "startup"
## Maximum length of a message to consume, in bytes (default 0/unlimited);
## larger messages are dropped
max_message_len = 1000000
## Max undelivered messages
## This plugin uses tracking metrics, which ensure messages are read to
## outputs before acknowledging them to the original broker to ensure data
## is not lost. This option sets the maximum messages to read from the
## broker that have not been written by an output.
##
## This value needs to be picked with awareness of the agent's
## metric_batch_size value as well. Setting max undelivered messages too high
## can result in a constant stream of data batches to the output. While
## setting it too low may never flush the broker's messages.
# max_undelivered_messages = 1000
## Maximum amount of time the consumer should take to process messages. If
## the debug log prints messages from sarama about 'abandoning subscription
## to [topic] because consuming was taking too long', increase this value to
## longer than the time taken by the output plugin(s).
##
## Note that the effective timeout could be between 'max_processing_time' and
## '2 * max_processing_time'.
# max_processing_time = "100ms"
## The default number of message bytes to fetch from the broker in each
## request (default 1MB). This should be larger than the majority of
## your messages, or else the consumer will spend a lot of time
## negotiating sizes and not actually consuming. Similar to the JVM's
## `fetch.message.max.bytes`.
# consumer_fetch_default = "1MB"
## Data format to consume.
## Each data format has its own unique set of configuration options, read
## more about them here:
## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
data_format = "influx"
Google BigQuery
# Configuration for Google Cloud BigQuery to send entries
[[outputs.bigquery]]
## Credentials File
credentials_file = "/path/to/service/account/key.json"
## Google Cloud Platform Project
# project = ""
## The namespace for the metric descriptor
dataset = "telegraf"
## Timeout for BigQuery operations.
# timeout = "5s"
## Character to replace hyphens on Metric name
# replace_hyphen_to = "_"
## Write all metrics in a single compact table
# compact_table = ""
Input and output integration examples
Kafka
-
Real-Time Data Processing: Use the Kafka plugin to feed live data from a Kafka topic into a monitoring system. This can be particularly useful for applications that require instant feedback on performance metrics or user activity, allowing businesses to react more swiftly to changing conditions in their environments.
-
Dynamic Metrics Collection: Leverage this plugin to dynamically adjust the metrics being captured based on events occurring within Kafka. For instance, by integrating with other services, users can have the plugin reconfigure itself on-the-fly, ensuring relevant metrics are always collected according to the needs of the business or application.
-
Centralized Logging and Monitoring: Implement a centralized logging system using the Kafka Consumer Plugin to aggregate logs from multiple services into a unified monitoring dashboard. This setup can help identify issues across different services and improve overall system observability and troubleshooting capabilities.
-
Anomaly Detection System: Combine Kafka with machine learning algorithms for real-time anomaly detection. By constantly analyzing streaming data, this setup can automatically identify unusual patterns, triggering alerts and mitigating potential issues more effectively.
Google BigQuery
-
Real-Time Analytics Dashboard: Leverage the Google BigQuery plugin to feed live metrics into a custom analytics dashboard hosted on Google Cloud. This setup would allow teams to visualize performance data in real-time, providing insights into system health and usage patterns. By using BigQuery’s querying capabilities, users can easily create tailored reports and dashboards to meet their specific needs, thus enhancing decision-making processes.
-
Cost Management and Optimization Analysis: Utilize the plugin to automatically send cost-related metrics from various services into BigQuery. Analyzing this data can help businesses identify unnecessary expenses and optimize resource usage. By performing aggregation and transformation queries in BigQuery, organizations can create accurate forecasts and manage their cloud spending efficiently.
-
Cross-Team Collaboration on Monitoring Data: Enable different teams within an organization to share their monitoring data using BigQuery. With the help of this Telegraf plugin, teams can push their metrics to a central BigQuery instance, fostering collaboration. This data-sharing approach encourages best practices and cross-functional awareness, leading to collective improvements in system performance and reliability.
-
Historical Analysis for Capacity Planning: By using the BigQuery plugin, companies can collect and store historical metrics data essential for capacity planning. Analyzing trends over time can help anticipate system needs and scale infrastructure proactively. Organizations can create time-series analyses and identify patterns that inform their long-term strategic decisions.
Feedback
Thank you for being part of our community! If you have any general feedback or found any bugs on these pages, we welcome and encourage your input. Please submit your feedback in the InfluxDB community Slack.
Powerful Performance, Limitless Scale
Collect, organize, and act on massive volumes of high-velocity data. Any data is more valuable when you think of it as time series data. with InfluxDB, the #1 time series platform built to scale with Telegraf.
See Ways to Get Started
Related Integrations
Related Integrations
HTTP and InfluxDB Integration
The HTTP plugin collects metrics from one or more HTTP(S) endpoints. It supports various authentication methods and configuration options for data formats.
View IntegrationKafka and InfluxDB Integration
This plugin reads messages from Kafka and allows the creation of metrics based on those messages. It supports various configurations including different Kafka settings and message processing options.
View IntegrationKinesis and InfluxDB Integration
The Kinesis plugin allows for reading metrics from AWS Kinesis streams. It supports multiple input data formats and offers checkpointing features with DynamoDB for reliable message processing.
View Integration