Kinesis and Zabbix Integration

Input and output integration overview

The Kinesis plugin enables you to read from Kinesis data streams, supporting various data formats and configurations.

This plugin sends metrics to Zabbix via traps, allowing for efficient monitoring of systems and applications. It supports automated configuration and data sending based on dynamic metrics collected by Telegraf.

Integration details

Kinesis

The Kinesis Telegraf plugin is designed to read from Amazon Kinesis data streams, enabling users to gather metrics in real-time. As a service input plugin, it operates by listening for incoming data rather than polling at regular intervals. The configuration specifies various options including the AWS region, stream name, authentication credentials, and data formats. It supports tracking of undelivered messages to prevent data loss, and users can utilize DynamoDB for maintaining checkpoints of the last processed records. This plugin is particularly useful for applications requiring reliable and scalable stream processing alongside other monitoring needs.

Zabbix

The Telegraf Zabbix plugin is designed to send metrics to Zabbix, an open-source monitoring solution, using the trap protocol. It supports various versions from 3.0 to 6.0, ensuring compatibility with recent updates. The plugin facilitates easy integration with the Zabbix ecosystem, allowing users to send collected metrics and monitor system performance seamlessly. Key functionalities include the ability to define the address and port of the Zabbix server, options for prefixing keys, determining the type of data sent (active vs. trapper), and features for low-level discovery (LLD) enabling dynamic item creation based on the metrics observed. Configuration options also allow for autoregistration and resending intervals for LLD data, ensuring that the metrics are up-to-date and relevant. Additionally, the trap format used for sending metrics is structured to facilitate efficient data transfer and processing in Zabbix.

Configuration

Kinesis

# Configuration for the AWS Kinesis input.
[[inputs.kinesis_consumer]]
  ## Amazon REGION of kinesis endpoint.
  region = "ap-southeast-2"

  ## Amazon Credentials
  ## Credentials are loaded in the following order
  ## 1) Web identity provider credentials via STS if role_arn and web_identity_token_file are specified
  ## 2) Assumed credentials via STS if role_arn is specified
  ## 3) explicit credentials from 'access_key' and 'secret_key'
  ## 4) shared profile from 'profile'
  ## 5) environment variables
  ## 6) shared credentials file
  ## 7) EC2 Instance Profile
  # access_key = ""
  # secret_key = ""
  # token = ""
  # role_arn = ""
  # web_identity_token_file = ""
  # role_session_name = ""
  # profile = ""
  # shared_credential_file = ""

  ## Endpoint to make request against, the correct endpoint is automatically
  ## determined and this option should only be set if you wish to override the
  ## default.
  ##   ex: endpoint_url = "http://localhost:8000"
  # endpoint_url = ""

  ## Kinesis StreamName must exist prior to starting telegraf.
  streamname = "StreamName"

  ## Shard iterator type (only 'TRIM_HORIZON' and 'LATEST' currently supported)
  # shard_iterator_type = "TRIM_HORIZON"

  ## 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

  ## 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"

  ##
  ## The content encoding of the data from kinesis
  ## If you are processing a cloudwatch logs kinesis stream then set this to "gzip"
  ## as AWS compresses cloudwatch log data before it is sent to kinesis (aws
  ## also base64 encodes the zip byte data before pushing to the stream.  The base64 decoding
  ## is done automatically by the golang sdk, as data is read from kinesis)
  ##
  # content_encoding = "identity"

  ## Optional
  ## Configuration for a dynamodb checkpoint
  [inputs.kinesis_consumer.checkpoint_dynamodb]
    ## unique name for this consumer
    app_name = "default"
    table_name = "default"

Zabbix

[[outputs.zabbix]]
  ## Address and (optional) port of the Zabbix server
  address = "zabbix.example.com:10051"

  ## Send metrics as type "Zabbix agent (active)"
  # agent_active = false

  ## Add prefix to all keys sent to Zabbix.
  # key_prefix = "telegraf."

  ## Name of the tag that contains the host name. Used to set the host in Zabbix.
  ## If the tag is not found, use the hostname of the system running Telegraf.
  # host_tag = "host"

  ## Skip measurement prefix to all keys sent to Zabbix.
  # skip_measurement_prefix = false

  ## This field will be sent as HostMetadata to Zabbix Server to autoregister the host.
  ## To enable this feature, this option must be set to a value other than "".
  # autoregister = ""

  ## Interval to resend auto-registration data to Zabbix.
  ## Only applies if autoregister feature is enabled.
  ## This value is a lower limit, the actual resend should be triggered by the next flush interval.
  # autoregister_resend_interval = "30m"

  ## Interval to send LLD data to Zabbix.
  ## This value is a lower limit, the actual resend should be triggered by the next flush interval.
  # lld_send_interval = "10m"

  ## Interval to delete stored LLD known data and start capturing it again.
  ## This value is a lower limit, the actual resend should be triggered by the next flush interval.
  # lld_clear_interval = "1h"

Input and output integration examples

Kinesis

1. Real-Time Data Processing with Kinesis: This use case involves integrating the Kinesis plugin with a monitoring dashboard to analyze incoming data metrics in real-time. For instance, an application could consume logs from multiple services and present them visually, allowing operations teams to quickly identify trends and react to anomalies as they occur.

2. Serverless Log Aggregation: Utilize this plugin in a serverless architecture where Kinesis streams aggregate logs from various microservices. The plugin can create metrics that help detect issues in the system, automating alerting processes through third-party integrations, enabling teams to minimize downtime and improve reliability.

3. Dynamic Scaling Based on Stream Metrics: Implement a solution where stream metrics consumed by the Kinesis plugin could be used to adjust resources dynamically. For example, if the number of records processed spikes, corresponding scale-up actions could be triggered to handle the increased load, ensuring optimal resource allocation and performance.

4. Data Pipeline to S3 with Checkpointing: Create a robust data pipeline where Kinesis stream data is processed through the Telegraf Kinesis plugin, with checkpoints stored in DynamoDB. This approach can ensure data consistency and reliability, as it manages the state of processed data, enabling seamless integration with downstream data lakes or storage solutions.

Zabbix

1. Dynamic Monitoring of Containerized Applications: Integration of the Zabbix plugin can be leveraged to monitor Docker containers dynamically. As containers are created and removed, the plugin can automatically update Zabbix with the appropriate metrics, ensuring that monitoring stays current without manual configuration. This enhances visibility into resource usage and performance metrics for microservices orchestrated with Kubernetes or Docker Swarm.

2. Real-Time Performance Monitoring with Auto-registration: By enabling the autoregister feature, the plugin can automatically register hosts in Zabbix based on the metrics received. This scenario provides a streamlined approach to add new hosts to monitoring without manual setup, which is particularly useful in environments where hosts may frequently spin up and down, such as serverless architectures or cloud-based deployments.

3. Leveraging Low-level Discovery for Flexible Metric Capture: Using low-level discovery, this plugin allows Zabbix to adaptively create items for metrics that are not predefined. In a scenario involving multiple network devices reporting different performance metrics, the plugin can dynamically inform Zabbix about new metrics as they appear, thus ensuring comprehensive monitoring capabilities that evolve with the monitored systems.

4. Centralized Monitoring of Distributed Systems: The Zabbix plugin can be utilized in a centralized monitoring setup for distributed systems where multiple Telegraf instances are running across different geographical locations. By sending all metrics to a central Zabbix server, organizations can achieve a holistic view of their infrastructure’s performance and make informed operational 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.