Kafka and Clarify 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 Clarify plugin allows users to publish Telegraf metrics directly to Clarify, enabling enhanced analysis and monitoring capabilities.
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.
Clarify
This plugin facilitates the writing of Telegraf metrics to Clarify, a platform for managing and analyzing time series data. By transforming metrics into Clarify signals, this output plugin enables seamless integration of collected telemetry data into the Clarify ecosystem. Users must obtain valid credentials, either through a credentials file or basic authentication, to configure the plugin. The configuration also provides options for fine-tuning how metrics are mapped to signals in Clarify, including the ability to specify unique identifiers using tags. Given that Clarify supports only floating point values, the plugin ensures that any unsupported types are effectively filtered out during the publishing process. This comprehensive connectivity aligns with use cases in monitoring, data analysis, and operational insights.
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"
Clarify
[[outputs.clarify]]
## Credentials File (Oauth 2.0 from Clarify integration)
credentials_file = "/path/to/clarify/credentials.json"
## Clarify username password (Basic Auth from Clarify integration)
username = "i-am-bob"
password = "secret-password"
## Timeout for Clarify operations
# timeout = "20s"
## Optional tags to be included when generating the unique ID for a signal in Clarify
# id_tags = []
# clarify_id_tag = 'clarify_input_id'
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.
Clarify
-
Automated Data Monitoring: By integrating the Clarify plugin with sensor data collection, organizations can automate the monitoring of environmental conditions, such as temperature and humidity. The plugin processes metrics in real-time, sending updates to Clarify where they can be analyzed for trends, alerts, and historical tracking. This use case makes it easier to maintain optimal conditions in data centers or production environments, reducing the risk of equipment failures.
-
Performance Metrics Analysis: Companies can leverage this plugin to send application performance metrics to Clarify. By transmitting key indicators such as response times and error rates, developers and operations teams can utilize Clarify’s capabilities to visualize and analyze application performance over time. This insight can drive improvements in user experience and help identify areas in need of optimization.
-
Sensor Data Aggregation: Utilizing the plugin to push data from multiple sensors to Clarify allows for a comprehensive view of physical environments. This aggregation is particularly beneficial in sectors such as agriculture, where metrics from various sensors can be correlated to decision-making about resource allocations, pest control, and crop management. The plugin ensures the data is accurately mapped and transformed for effective analysis.
-
Real-Time Alerts and Notifications: Implement the Clarify plugin to trigger real-time alerts based on predefined thresholds within the metrics being sent. For instance, if temperature readings exceed certain levels, alerts can be generated and sent to operational staff. This proactive approach allows for immediate responses to potential issues, enhancing operational reliability and safety.
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